1. L’oeuf ou la poule ?
Il est un mythe qui a la peau dure : il s’agit de l’envers du décor des directions des systèmes d’information. Cet endroit représente souvent le summum de l’ésotérisme technologique et technique, grouillant de têtes bien faites et de doigts qui courent sur des claviers de machines aux mille petites lumières clignotantes.
La réalité est aujourd’hui plus connue et triviale. Une DSI est un service aux missions multiples et adaptées à chaque organisme, mais on peut sans risque d’erreur prétendre qu’il y existe deux grands types de taches :
- celles dédiées au développement des programmes et autres applicatifs. Ces développeurs représentent sans doute le métier le plus connu du grand public. Ce sont, en réalité, des personnes aux compétences et savoir-faire spécifiques qui codent des applications, et bien souvent des morceaux d’applications dans un cadre conceptuel et fonctionnel coordonné. Une part significative du travail consiste également à ce que les applications développées fonctionnent, et donc ne possèdent pas de ‘bug’, ces défauts qui peuvent être parfois gênants, parfois catastrophiques. Une bonne équipe de développeurs peut se targuer d’un produit fini le plus parachevé possible, conforme au cahier des charges, qui fonctionne de manière fluide et sans erreur, grâce à un code parfaitement structuré et qui sera amélioré au fur et à mesure à travers des processus de mises à jour.
- De l’autre côté du miroir, au sein de la DSI, il existe des équipes moins connues du grand public, mais dont les tâches sont également fondamentales. Il s’agit du monde des administrateurs systèmes (les opérateurs). Leur mission : préparer, paramétrer, maintenir et mettre à jour les machines et les programmes de bas niveau, comme les serveurs, permettant ainsi d’accueillir les applications développées par les développeurs. Les administrateurs systèmes sont donc moins visibles par le grand public, sont plus proches des entrailles machines, mais il va de soi que sans eux, aucune application ne peut fonctionner convenablement si le paramétrage ne correspond pas.
Et c’est ici que le bât blesse : ceci est un petit secret, mais qu’on se le dise, le monde des DSI n’était pas un long fleuve tranquille. D’un côté, les développeurs créaient de petits bijoux d’applicatifs puissants, débuggés et parfaitement structurés. De l’autre, les administrateurs systèmes veillaient à ce que les machines bourdonnent parfaitement sans accroc à 100 % de continuité de service. Mais, phénomène parfaitement étrange : lorsqu’on installait une application parfaite sur une machine de production, c’est-à-dire une « vraie » machine de la « vraie » vie du « vrai » business, souvent, rien ne fonctionnait plus. Des dizaines de bugs apparaissaient, des comportements inattendus rendant l’applicatif inutilisable, ou le serveur inopérant, malgré tout le soin préalablement passé à rendre l’application conforme.
La faute à qui ? Depuis la question consistant à savoir qui, de l’œuf ou de la poule, est apparu le premier, la question de savoir si une application ne fonctionne pas à cause des administrateurs systèmes ou à cause des développeurs tarauda le monde de l’informatique avec force. Pour des raisons métaphysiques, certes. Mais surtout pour des raisons de coût. Une application de plusieurs millions de lignes à reprendre entièrement avec une équipe de 40 développeurs tout en respectant des délais de livraison et la conformité au cahier des charges sans pénalité de retard était une gageure. Les directeurs des DSI se cognaient la tête contre les murs, d’autant que l’ambiance du service pouvait devenir sinon massacrante, du moins très tendue… sans compter l’humeur du client.
Et la guerre entre développeurs et opérateurs aurait pu continuer jusqu’à la fin des temps jusqu’à ce que…
