La saga DevOps : lorsque le monde informatique s’est transformé au bénéfice de l’utilisateur final – Partie 2

Partager sur facebook
Partager sur google
Partager sur twitter
Partager sur linkedin

Nos articles récents

2. Quand 1+1=3

En reprenant le problème depuis le fondement, on se rendit compte que les objectifs des développeurs d’un côté, et des opérateurs (les administrateurs systèmes) de l’autre, étaient naturellement, essentiellement, épidermiquement, ontologiquement différents.

Non seulement les DSI étaient conçues en silos, avec les deux équipes dans deux aquariums étanches – puisque les objectifs étaient différents, n’était-ce pas logique ?

Des silos tels que les silos en informatique

Mais de plus, d’un côté, un métier était spécialisé dans le logiciel, le software. Comme tel, ceci induit une philosophie de l’amélioration continue, et donc du changement perpétuel. Il n’existe aucune application qui reste en version 1.0 toute sa vie d’application, chacun sait cela.

De l’autre, le métier était spécialisé dans la maintenance, à savoir la stabilité, l’immutabilité permettant la fiabilité et la continuité de service.

C’est dire si les développeurs et les administrateurs systèmes n’étaient pas sur la même planète conceptuelle. Ceci paraît sans doute anodin, mais certaines situations issues de ces deux pans irréconciliables de la chose informatique ont pu couler certaines entreprises n’ayant su dépasser ces deux visions du monde pour les réconcilier. Même les ressources humaines étaient impuissantes à calmer le phénomène, incapables de créer des flux permettant de concilier changement et immutabilité. Les processus étaient fantastiques sur le papier, inopérants dans la vraie vie.

Le constat…

On fit alors le constat d’un dysfonctionnement inhérent à la substance même de l’informatique. Et nous ne parlons pas ici de l’informatique des années 80, ni même des années 2000. On en était encore dans ce gouffre philosophique jusqu’en 2007 où, en Belgique, Patrick Debois, ingénieur programmeur, trouve une solution qu’il nomme d’abord ‘Agile Administration System’, qu’il va contracter en ‘DevOps’ parce que c’était plus facile à prononcer. Objectif avoué : dépasser la polarisation entre ‘dèvs’ d’un côté, et ‘ops’ de l’autre, pour créer une troisième voie, à savoir… une DSI performante au service de son organisme.

Des équations difficiles à résoudre

Nous rappelons ici les points de l’équation en des termes triviaux : concilier la stabilité, la qualité, le temps et les coûts en créant une méthodologie novatrice ressoudant tout le monde autour d’un projet commun qui fonctionne tout de suite, sans retard, et sans qu’aucun métier ne blâme l’autre soit de sa légèreté ultrarapide entraînant des bugs, soit de sa lenteur maladive entraînant des retards. Par ailleurs, d’un point de vue humain, l’objectif fut de réconcilier deux visions du monde, voire deux cultures qui étaient devenues presque aussi irréconciliables que l’écart existant entre la force de vente, le marketing et la communication.

Mais comme bien souvent, l’informatique est en avance sur les processus de travail et d’intégration des tâches, et en 2007, DevOps fit pour la première fois sauter les silos. C’est ici que la fusion entre Devs et Ops donna naissance à un nouveau type de méthodologie ne ressemblant strictement pas à l’adjonction artificielle de deux mondes. On venait au contraire d’inventer l’équation 1+1=3, équation qui rejaillirait aussi dans d’autres milieux que l’informatique selon certains aspects.