Mac Giver

Dédicacé à Didier de C et Serge S.

arbre réseauVotre projet d’une nouvelle application avance bien. Il est temps d’aller voir l’ingénieur système.
Il est responsable du fonctionnement d’ensemble du système d’information de l’entreprise dans lequel votre application va s’inscrire. Sa collaboration est indispensable.

Des merveilles technologiques

Un système d’information ce sont des applications, des bases de données, des sites internet ou intranet , de la messagerie, des télétraitements. Pour le commun des mortels et les autres concepteurs-développeurs, ce sont des moyens de communiquer, de traiter et de stocker des informations nécessaires à des utilisateurs.
Pour l’ingénieur système, le SI est d’abord un bijou technologique, entre centrale nucléaire et fusée Ariane. C’est un enchevêtrement de serveurs, de logiciels d’exploitation, de réseaux, de périphériques divers (imprimantes, scanners, terminaux de saisie portables), tout un ensemble d’équipements qui sont des merveilles de sophistication, mais dont surtout le client ne veut pas entendre parler. Cet ensemble doit fonctionner tous les jours sans anomalies, sans rupture de fonctionnement, sans contrainte d’utilisation. La qualité première des ingénieurs système et des responsables d’application est d’être ignorés du reste de l’entreprise, peu intéressé par leurs problèmes. Leur seule satisfaction, c’est de parvenir à faire fonctionner cet ensemble comme une horloge suisse.
Or, ce système d’exploitation doit évoluer : obsolescence technique des serveurs, arrivée des nouvelles versions des logiciels. En permanence il y a quelque chose de nouveau dans le monde merveilleux du numérique. Pour les fournisseurs, la nouveauté est un argument indispensable pour acquérir de nouveaux clients. Ils vous demandent donc régulièrement des changements de versions.
Et tout changement suppose de tester à nouveau l’ensemble du système pour s’assurer que qu’il marche toujours et qu’aucune fonctionnalité n’a été perdue. C’est donc une activité ingrate de vérification.

« Même les paranoïaques ont de vrais ennemis » (Topor)

Par sa position en surplomb de tout le système d’information, l’ingénieur système a aussi la responsabilité sur la sécurité de ce système. Cette sécurité a trois aspects : la sécurité de fonctionnement, la sécurité d’accès, la sécurité contre l’intrusion.
D’abord il faut garantir la continuité de service. Le système a été prévu pour fonctionner sur une certaine plage horaire et un certain nombre de jours dans l’année, si possible 24/24 et 7/7. Les clients sont sourcilleux sur le respect de ces engagements. Rien ne doit interrompre le fonctionnement, ni la coupure d’un câble par un ouvrier négligeant, ni une anomalie sur un logiciel, ni l’incendie d’un immeuble ou son écrasement par un avion de ligne. A tous ces risques, il doit y avoir une parade qui assure la sacro-sainte continuité de service. Ce fonctionnement doit aussi permettre le meilleur niveau de service. Pas de ralentissement, pas de risque de devoir attendre à coté de la machine à café avant d’avoir le résultat d’une requête.
Ensuite, l’ingénieur système se charge de sécuriser l’accès au système, gestion codes utilisateurs et des mots de passe, délais d’ouverture. Il doit vérifier aussi que ce système ne devienne pas un labyrinthe kafkaïen où l’utilisateur doit donner un mot de passe toutes les minutes.
Enfin il est responsable de la DMZ (demilitarized zone) terme délicieusement militariste désignant toutes les procédures et équipements qui empêchent l’intrusion extérieure sur le réseau propre de l’entreprise. Banquiers, industriels, commerçants, militaires deviennent hystériques à l’idée que quelqu’un puisse pénétrer leur SI, voler (au sens propre comme figuré) des informations, de l’argent et des biens grâce à cette intrusion.
Vu les responsabilités qu’on lui a donné, l’ingénieur système regarde avec suspicion l’arrivée d’une nouvelle application. C’est un nouveau logiciel à tester en cas de montée de version, de nouvelles contraintes d’exploitation, de nouveaux utilisateurs, et s’il y a besoin de dialoguer avec l’extérieur, de nouveaux risques d’intrusion dans la DMZ.
Il accueille donc le chef de projet sans plaisir et le soumettra à un interrogatoire serré. Il veut que vous prouviez l’intérêt de l’application. C’est une occasion pour lui de démontrer qu’un coursier à vélo transmet plus d’information que l’outil que vous devez développer. Si vous avez résisté à cette première salve, vous passerez aux questions concernant la continuité de service et la sécurité. Si vos réponses ne correspondent pas aux normes de l’entreprise, il vous présente la facture, toujours avec un nombre surprenant de zéros. Même chose, si votre application nécessite une installation (serveurs, système d’exploitation, périphériques) qui n’entre pas dans les standards.

Mac Gyver, le roi de la débrouille

Des explications précédentes vous retiendrez peut-être que l’ingénieur système est un grincheux, un conservateur ronchon et rébarbatif. Ce serait une erreur. Pour passer sa vie dans la technologie de pointe il faut être un ingénieur passionné, Ce sont des amateurs de nouveauté, toujours prêts à se colleter avec des problèmes inédits.
Un exemple pour l’illustrer. J’avais été nommé chef de projet pour un nouveau progiciel à l’algorithme complexe, à la pointe des recherches mathématiques. Son implantation accompagnait un changement organisationnel dans l’entreprise. Donc je prends contact avec l’ingénieur système pour étudier le substrat technique. Il me propose une solution novatrice, basée sur une génération de serveurs plus rapides, plus évolutifs.
Je fais remarquer que j’avais déjà ma part de nouveauté avec l’algorithme à mettre en place et le changement d’organisation. Une solution technique robuste, même un peu ancienne me semblait préférable. Il me démontra l’avantage financier, m’assura qu’une autre application avait déjà pris la décision d’utiliser ces serveurs, et qu’un projet spécifique aux procédures d’installation et d’exploitation avait été lancé. Il restait huit mois avant la mise ne place des serveurs pour mon projet, tout serait rodé d’ici là. J’acceptais donc, et j’accompagnais l’ingénieur système au Comité d’Architecture pour validation du dossier technique. Tout le monde se félicita que l’entreprise entre enfin dans le XXIème siècle.
Huit mois plus tard, le premier projet utilisateur avait été annulé faute de financement. Le projet concernant la gestion de ces serveurs avait arrêté aussi et nous nous retrouvions à essuyer les plâtres. En même temps les serveurs avaient été commandés et le changement de configuration faisait prendre quelques mois de retard.
En tant que chef de projet, je provoquais donc une réunion de crise entre les ingénieurs qui avaient conçu la solution technique et les responsables de l’exploitation. Nous étions entre gens qui se connaissaient bien et qui évitaient la langue de bois. Les injures volaient bas, et le vocabulaire technique me passait au dessus de la tète. Les uns défendaient leur solution, les autres demandaient de revenir aux outils et procédures habituelles. Au bout d’une heure d’échange, je risquais deux questions :
– Si je comprends bien vous ne savez pas installer Windows sur ces serveurs ?
-…oui.
– Croyez-vous que c’est à moi de résoudre le problème ?
Je n’ai plus entendu parler de la question et nous avons tenu les délais du projet.
Le contact avec l’ingénieur système peut être rugueux, mais vous pouvez compter sur son aide.

Cet article, publié dans developpement, système d'information, est tagué , , , . Ajoutez ce permalien à vos favoris.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

w

Connexion à %s