DevOps échoue, DevOps échoue énormément…

Je le confesse, je suis un bien piètre élève. Ayant eu la chance de passer par quasiment toutes les couches du SI, j’ai au fil des ans été amené à me confronter à de nombreux problèmes, leurs solutions, les problèmes causés par ces solutions etc. Si cela vous forge un homme, l’expérience du terrain a tendance à vous éloigner des livres. Et si je suis très enclin à la veille technologique, elle repose plus sur la consultation d’autres professionnels et de StackOverflow que des papiers blancs émis par les instituts de consulting et l’impact bien trop grand qu’ils ont sur les sphères de décision en entreprise.

Aussi n’ai-je pas été étonné lorsque, lors d’une récente mission de transformation digitale, j’ai appris l’abandon d’un produit d’accompagnement au changement et d’estimation de la maturité des équipes sur Agile et les organisations product-centric (ou customer-centric ou business first, appelez ça comme vous voulez). Un produit basé sur une approche et des outils promulgués par Gartner (Apply Gartner’s Product Management Maturity Model to Uplift Business Impact). Je ne suis pas un grand fan de cette société pour un certain nombre de raisons (le « magic quadrant » biaisé et trop lourd dans son impact sur le marché, le manque de transparence dans les calculs et la réalisation de ses analyses, des prises de position douteuses suivis de retournements de veste…).

Une chose à laquelle je porte bien plus de crédit, en revanche, c’est DevOps. Confronté aux limites du cycle en V, aux silos fonctionnels et techniques ainsi qu’à la frustration face à l’inefficacité (on naît informaticien ou on ne l’est pas), je n’ai pas attendu l’avènement de ce mot pour me passionner pour l’automatisation, la centralisation des opérations, la création d’outils destinés aux métiers de l’informatique etc.  Etant passé par le monde du développement full-stack et ayant eu la joie immense de leader ma propre équipe de développement pendant quelques années, j’ai pu voir tous les enjeux de ce paradigme, les avantages et les difficultés du « you build it, you run it ».

DevOps est un sujet jeune, vaste (trop pour son propre nom), en perpétuelle évolution. Loin d’en faire un Graal, j’ai extrêmement conscience de ses faiblesses et de sa position de « solution parmi d’autres » plutôt que de « solution miracle ». Mener de profonds changements dans une organisation est complexe. Lorsque ceux-ci s’accompagnent d’une forte couche technique et qu’ils sont poussés par des gens qui n’en conçoivent pas les briques élémentaires, cette complexité augmente considérablement. C’est donc avec grands regrets mais sans surprise que je vois des implémentations échouer régulièrement.

Et puis il y a quelques temps, j’ai été interloqué à la lecture d’un article. On y lit en introduction un extrait d’analyse de Gartner indiquant que d’ici 2023, « 90% des initiatives DevOps échoueront » (DevOps Failure. Why DevOps Fails?). Et puis, en fouillant un peu plus loin, j’ai retrouvé l’article de Gartner dont était extrait ce chiffre (The Secret to DevOps Success). Et là, qu’elle ne fut ma surprise de réaliser que j’étais en accord avec Gartner. Non seulement d’accord, mais en plus les arguments présentés reflètent ma propre expérience et les limites auxquelles nous nous confrontons bien trop souvent sur le terrain.

Alors, après mûres réflexions, j’ai décidé de crier la même vérité que Gartner pousse auprès de ses fidèles. En effet, DevOps échoue. DevOps échoue énormément. Pas parce que la méthode est mauvaise. Pas parce qu’elle n’est qu’une poudre aux yeux technologique. DevOps échoue car les personnes qui la comprennent n’ont pas de position de pouvoir. DevOps échoue car les problèmes de fond qu’elle est censée résoudre sont ignorés au profit de promesses de ROI ridicule et de productivité fantasmée. Donc oui, aujourd’hui, il est important que les gens sachent que DevOps échoue, pourquoi et comment faire pour que ce ne soit pas le cas.

Car il ne suffit pas de déployer des outils pour transformer des organisations. Il ne suffit pas de donner un nouveau titre à une personne pour transformer son métier et ses habitudes. Ces choses prennent du temps. DevOps, comme je l’ai dit plus haut, est un changement profond qui s’accompagne de changements technologiques. Mener à bien une telle tâche demande du temps pour :

–          Se plonger dans une structure et en comprendre l’ADN pour mieux la modifier

–          Appréhender les besoins techniques et deviser des solutions pertinentes

–          Découvrir et analyser des problématiques uniques, spécifiques à chaque contexte

Hors, cet effort indispensable, ce temps de préparation, ce coût initial qui donne à DevOps sa (juste) réputation de « méthode onéreuse » est trop souvent négligé. Et sans surprise, cette implémentation échoue.

Comment faire pour que ce ne soit pas le cas ?

–          Arrêtez d’attendre un calcul de ROI pour vous lancer dedans. Si j’avais un euro chaque fois que quelqu’un dans un SI quelconque balançait des chiffres au hasard pour illustrer les bénéfices potentiels d’un investissement, je serais plus riche que tous ces bénéfices cumulés. Calculer le ROI dans DevOps est un challenge en soi (How to measure DevOps ROI) qui ne devrait pas conditionner son adoption. Foncez, tentez, concentrez-vous sur l’essentiel (The ROI of DevOps: 5 Key Metrics) et vous ferez ce calcul plus tard.

–          Comprenez que DevOps, à cœur, est une façon d’unifier des métiers (et donc des hommes) qui ont trop longtemps travaillé chacun de leur côté, sans sentiment d’appartenance et d’unité. Comprenez qu’il s’agit de la redéfinition complète d’un modèle de fonctionnement ancien et profondément ancré dans les organisations, du management aux techniciens. Investissez votre temps et vos ressources dans la réalisation de ce changement, quitte à commencer petit. Faites tâches d’huile. Ne tentez pas un déploiement en masse à l’aveugle basé sur des méthodes génériques. L’approche DevOps est tout SAUF générique.

Enfin, par pitié, écoutez vos équipes, vos métiers, donnez-leur le crédit et le pouvoir de se transformer, et ne croyez pas aveuglément Gartner. Enfin, sauf cette fois peut-être…

Julien Alves

DevOps Advocate