A mes débuts dans les banques on ne disait pas « le service informatique », mais on parlait de « L’informatique ». Le service était bicéphale : la production et le bureau des études.
A la production où régnait une odeur de café, était le pupitre, opérateur technique qui contrôlait, vérifiait, parfois procédait à des relances principalement motivées par les retards des partenaires. Les incidents étaient extrêmement rares, et dans ce cas, le pupitre analysait l’historique, en s’appuyant sur le code source. Après quoi il s’adaptait pour résorber le souci et procédait à une démarche assez simple qui consistait à prendre un papier, un stylo, et le couloir.
Au bureau des études où régnait une odeur de mélange de thés, étaient les études, fonctionnels soucieux des standards de production qui inventaient, préparaient, développaient les processus de demain. Et à de rares occasions, accueillaient le pupitre pour voir avec lui l’incident rencontré et surtout comment le résoudre au plus vite.

Découvert au petit matin, l’incident était pris en charge rapidement par les études. Une nouvelle version du programme était livrée en recette avant midi pour qu’à 14H00 le batch quotidien de recette le valide pour 18H00. La mise en production était effectuée après les sauvegardes de 19H00.
A noter que ce batch quotidien de recette de 6 heures en avance sur la production était une garantie de détecter et anticiper d’éventuels problèmes à venir.
Cette organisation réactive qui n’avait pas de nom serait qualifiée aujourd’hui d’agile et continuous something.

Et puis un jour, un bien-pensant s’est mis en tête de structurer tout ça !..

Ainsi Le service informatique est devenu une direction des systèmes d’informations.
A la direction où régnait une odeur de stress, était l’open-space. Le poste de pupitre a été éclaté en trois postes : Le pilote, l’analyste d’exploitation et l’ingénieur de production. Quant au bureau d’études, c’est un peu plus complexe puisqu’il a été découpé en maitrise d’œuvre et maitrise d’ouvrage, parfois on trouvait aussi un service qualité, ont été créés plein de postes d’architecte, de développeurs, de business analyst, des project managers, des quality managers, des acceptance managers, bref, plein de managers et anglais s’il vous plait.
Face à cette débauche de titres, la production a joué sa carte en ajoutant des responsables en tout genre, responsable de la sécurité, responsable infrastructure, responsable des sauvegardes…
Bref, à ce moment-là nous sommes passés d’un service bicéphale à une direction multicéphale, du dialogue nous sommes passés au brouhaha.

Et puis un jour, un bien-pensant s’est mis en tête d’organiser tout ça !..

Ainsi naquirent les tickets. Pour structurer le flux de travail et pour coordonner tout ce petit monde au-delà du papier, stylo, couloir. La meilleure huile dans cette mécanique est ITIL. Un petit exemple pour les profanes :

1. Un couac intervient en production.
2. Le pilote le relève et récupère l’historique. Il ouvre un ticket nommé incident avec une description du couac et lie l’historique.
3. L’analyste d’exploitation ouvre le ticket incident et, devinez-quoi, l’analyse. A la suite de quoi, il ouvre un ticket nommé problème avec une description de ces analyses et les propositions de résolution.
4. L’ingénieur de production ouvre le ticket problème et analyse les propositions, il les complète, Ensuite il ouvre un ticket nommé demande d’aménagement/correction avec tout le toutim.
5. Un chef de projet ouvre le ticket et prend son bâton de pèlerin –entendre ici le trio papier, stylo, couloir- pour consulter :
   • Le service obsolescence parce que parfois le couac s’appuie sur une vieillerie inutile
   • Le service qualité pour vérifier que les propositions restent dans les standards
   • Le business analyst qui fournira les impacts fonctionnels
   • Le développeur pour coder les aménagements
   • Le service de recette pour procéder aux tests des aménagements
6. Le chef de projet ouvre un ticket nommé changement rattaché au problème et comportant les analyses d’impact, les précautions à prendre, les actions à mener, et j’en passe.
7. Le change manager va vérifier la teneur de ce changement et le valider
8. Le chef de projet pourra donc lui raccrocher des tickets nommés demandes de service auprès des différentes équipes qui devront opérées.
9. La nouvelle version corrigée est livrée en production.
10. Le service qualité vérifiera enfin que la correction répond bien au problème.
    Tout simplement. Ca a plus d’allure que le pupitre au café qui visite les buveurs de thé !

Et puis un jour, un bien-pensant s’est mis en tête de sous-traiter tout ça !..

Force est de constater que ça coûte très cher une si belle organisation. Ainsi il a été choisi de sous-traiter auprès de sociétés de service une partie de ces tâches. Puis il a été choisi que les tâches à peu de valeur ajoutée seraient délocalisées dans des pays à main d’œuvre peu qualifiée donc peu chère. Qui l’Inde, qui les Philippines, qui Singapour.
Sans entrer dans les détails de l’exemple précédent, imaginez les allers-retours induits par un couac détecté à Singapour, analysé en Europe, redéveloppé en Inde, validé en Europe, et déployé aux Philippines. Et tout ça sans papier, stylo, couloir.
Aux latences dues à la gestion des 5 qualités de tickets s’ajoutent les latences de décalage horaires. Et pendant ce temps, le même incident s’empile comme des perles, ce qui induit des interruptions de services coûteuses. Le taylorisme de la spécialisation de chacun devait réduire les perles, il n’a qu’accéléré le renouvellement du personnel, érodant la connaissance de l’environnement.

Et puis un jour, un bien-pensant se mettra en tête qu’en devops il faut repenser tout ça !..