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

3. Développeur certes, opérateurs soit, mais humains avant tout !

Il faut souvent le vivre pour le croire, et le sujet est tabou. Mais comme nous sommes entre nous, nous pouvons ne serait-ce qu’évoquer la question complexe des dissentions internes à un service, pour savoir les difficultés psychosociales que ceci peut engendrer.

Dans ces années 2005, il existait une réelle mésentente entre développeurs et administrateurs systèmes, à cause de cultures difficilement conciliables, au grand désespoir des chefs de projet, des maîtres d’ouvrage et autres donneurs d’ordres, puisque le projet était, lui, globalement parfaitement cohérent. Un applicatif a besoin d’une machine pour fonctionner, il a besoin d’évoluer sur des machines stables en temps et en heure sans bug.

L’analyse des dissensions entre les deux groupes en dit long sur les problématiques sous-jacentes : les opérateurs souhaitaient accompagner les développeurs dans leur travail, pour que le codage et les concepts soient compatibles avec les machines cibles. Mais les développeurs n’acceptaient pas nécessairement que d’autres s’introduisent dans leur périmètre métier, ce qui peut aussi parfaitement se comprendre.

Dans l’autre sens, les développeurs considéraient qu’il manquait des passerelles techniques permettant de coder selon les spécificités de telles ou telles machines, ces spécificités complexes et profondes n’étant pas explicitées par les administrateurs systèmes qui avaient, quant à eux, des horaires complexes, devant intervenir H24 en cas de souci. Et souvent, les opérateurs devaient savoir gérer des problèmes de hardware, des problèmes de techniciens.

Donc chacun se plaignait de l’éloignement de l’autre camp, tout en souhaitant un rapprochement stratégique devenu nécessaire à tous. Or, c’est sans doute l’une des grandes raisons qui induisit un changement profond dans l’approche DSI.

La clef est avant tout dans l’humain

La clef n’était pas cachée dans la technique ou le codage, mais avant tout dans l’humain. Il fallut trouver une méthode pour que chacun puisse comprendre l’autre. Le comprendre : comprendre ses méthodes, ses contraintes, ses obligations métier, les problèmes d’exploitation, d’horaires décalés, les tempos différents.

Et comme toujours, lorsque l’on détaille ces visions du monde et ces pratiques, on y trouve les substrats du changement. Les Ops passaient pour des ‘geeks’ plutôt avares en paroles, enfermés dans leur bulle, lents à déployer des solutions permettant de s’adapter à des applications conçues par des développeurs à l’image d’excités travaillant trop vite et sans coordination, chacun dans son coin.

Ces images d’Épinal disparurent quand les deux mondes se comprirent pour ce qu’ils étaient réellement. Ils virent que ce qui leur manquait était une passerelle, un intermédiaire permettant de trouver des solutions communes pour développer sur des machines aux spécificités intégrées dans le code, et des machines prêtes à recevoir ce code sans en transformer les spécificités et donc sans générer de bug.

Le DevOps fut d’abord une sensibilisation très forte des développeurs aux problèmes et contraintes métiers des administrateurs systèmes, et réciproquement.