DevOps est mort, est-ce grave docteur ?

Bonne année 2025 à toutes et à tous 🎉. Commençons cette nouvelle année avec une rétrospective sur le mouvement DevOps.

Il existe déjà de nombreux articles et billets de blog¹ qui expliquent en détail ce qu’est ce mouvement mais je vais quand même passer rapidement dessus afin d'être sûr nous soyons sur la même longueur d'onde pour le reste de l'article.

Pour faire simple, DevOps est une sorte d'alignement stratégique entre les parties prenantes qui développent un produit et ses fonctionnalités (le build) et celles qui maintiennent la production (le run). On est censé mesurer la bonne application du DevOps par le fait de réussir à briser les frontières (ou silos) qu'il peux exister entre le build et le run dans une entreprise ou organisation.

Depuis un certain temps, le mot DevOps est dévoyé de son sens d’origine, notamment par les recruteurs, afin de désigner directement un ensemble de compétences techniques² parfois utilisées dans sa mise en œuvre. C’est pourquoi on peut lire beaucoup d’évangélistes DevOps qui martèlent que "DevOps n’est pas un rôle, c’est un ensemble de bonnes pratiques pour briser les silos", et ils ont raison d'une certaine manière.

Cependant, en tant que responsable technique souhaitant fournir des outils et des compétences précises, je pense que nous n'avons pas d'autres choix qu'accepter et s’adapter à l'usage du terme d'aujourd’hui. C’est pourquoi je n’ai aucun problème à ajouter le mot DevOps sur des CVs ou des offres d’emploi quand il s’agit de sélectionner des profils dont le rôle correspond davantage à des SRE³ ou des Platform Engineers. C’est pareil pour les outils que nous développons comme CWCloud. Ce qui compte le plus, c’est de répondre aux besoins des clients et utilisateurs et non pas pinailler sur l'origine d'un éthymologique d'un mot qui vient d'un mouvement qui n'adresse plus réellement les problèmes d'échelles rencontrés par les entreprises. Donc, si les clients et recruteurs pensent que DevOps est un ensemble de compétences et pratiques techniques, ce n’est pas un problème fondamentalement grave. Commençons par les approcher parce que nous sommes pertinents pour les aider, plutôt que de les corriger de manière dogmatique et irrévérencieuse.

Pour illustrer davantage le fait qu'il ne sert à rien de lutter contre le sens du courant, voyons par exemple comment GitLab se présente :

GitLab: The most-comprehensive AI-powered DevSecOps platform

Ce qui peux se traduire comme ceci :

GitLab : la plateforme DevSecOps alimentée par l’IA la plus complète

Avant le battage médiatique autour de l’IA, GitLab se définissait pendant des années comme la chaîne d’outils DevOps complète, malgré le fait que ses fonctionnalités (dépôts git, pipelines CI/CD et les fonctionnalités GitOps) n'impliquent pas nécéssairement que l'organisation soit DevOps. Beaucoup d’entreprises qui utilisent GitLab ne suivent pas du tout les principes DevOps. Personnellement, je pense qu’il en va de même pour les personnes capables d’automatiser des déploiements avec des compétences techniques comme ansible, terraform, helm, etc.

Cela étant, revenons au sujet principal de cet article : je pense personnellement que le mouvement DevOps en lui-même est mort et que nous revenons aux silos. C'est un phénomène récurrent qui se produit chaque décennie dans toutes les industries en croissance, et dans le cas de l'IT, ce dernier retour aux silos est la conséquence directe du passage au cloud moderne.

Définissons d’abord ce qu’est le cloud moderne : c’est essentiellement une couche d’abstraction de la complexité des infrastructures via des API ou interfaces simples à consommer pouvant être directement par des product owners, des développeurs, des data scientists... bref, des parties prenantes qui ne sont pas expertes en hébergement d'infrastructure et gestion d'applications en production. Et ces API, avec différents niveaux d’abstraction, sont fournies As a Service⁴.

Le cloud moderne peut être délégué à des hébergeurs ou hyperscalers et c'est ce qu'on appelera le cloud public (fournisseurs comme AWS, GCP, Azure, Scaleway...) ou mis en place dans des infrastructures privées (on parlera donc de cloud privé) via des outils d'IaaS comme OpenStack, OpenShift, Kubernetes, des plateformes FaaS... bref, tout ce qui permet de donner de l’autonomie aux équipes de développement pour le déploiement de leur code.

Et c’est pour cela que nous assistons à un retour des silos :

• des équipes de Platform Engineers qui fournissent les outils pour aider les développeurs à déployer leur code (registries d’images, CI/CD, moteurs serverless, observabilité...)
• des équipes de SRE⁵ qui sont souvent d’anciens développeurs gérant les incidents en production et apportant des solutions à court et long terme, parfois en corrigeant directement le code
• des équipes consommatrices (développeurs, product owners, data scientists...) de la plateforme⁶
• des équipes OPS qui s’occupent de l’infrastructure physique : matériel, réseau, administration système de bas niveau

La seule différence entre le cloud public et le cloud privé est que certains des intervenants de ces silos travaillent directement comme employés de l'hébergeur. Il s’agit d’une mutualisation des ressources humaines dans de grandes organisations qui n’ont jamais réellement adopté le mouvement DevOps d'ailleurs.

Mais du coup, cela ne ressemble t-il pas à ce que nous avions avant l'ère DevOps ? Quelle est la différence ?

La principale différence réside dans le fait que les SLA⁷ et le time to market étaient très mauvais pour plusieurs raisons :

• manque d’agilité dans la planification entre les équipes non-alignées en terme d'objectifs
• certaines personnes étaient des goulets d’étranglement par manque d’automatisation et d’abstraction de leurs interventions
• d’anciens cadres méthodologiques comme ITIL ou CMMI qui géraient tout via l’ITSM⁸

Comme pour les méthodologies agiles avant lui, DevOps était trop axé sur la suppression des silos, ce qui est impossible dans les grandes organisations. Et puisque le but de toute entreprise est de croître, ce n’était pas une solution durable. Une méthodologie non scalable n’est pas durable à long terme.

Alors est-ce vraiment un problème si nous revenons aux anciens silos ? Je ne pense pas. Comme pour Agile (et même ITIL, CMMI, COBIT, DDD, TDD, etc.), nous progressons en piochant les principes qui nous intéressent au moment opportun. Bien sûr, nous continuerons à améliorer l’automatisation, la CI/CD, l’observabilité, nos SLA dans la résolution d’incidents et notre time to market pour les évolutions via l’ingénierie pragmatique, pas en suivant religieusement une méthodologie. Le dogmatisme et le pragmatisme sont souvent opposés, et en tant qu’ingénieurs, nous devrions rester pragmatiques et chercher la meilleure solution avec le meilleur ROI⁹.

Donc encore une fois, bonne année, et espérons que 2025 soit une nouvelle ère d’amélioration de nos pratiques et produits de gestion des déploiements et infrastructures. Nous avons plein de surprises qui arrivent en matière d’observabilité et d’automatisation (peut-être avec de l’IA 😱).

---

Footnotes

1. J’aime beaucoup cet article de Katia Himeur Talhi pour définir ce qu'est DevOps ↩

2. Pipelines CI/CD, automatisation des déploiements, observabilité, scripting... ↩

3. System Reliability Engineer. Si vous ne connaissez pas bien le concept, je vous conseille encore une fois l’article de Katia ↩

4. C’est ce dont on parle souvent avec les termes IaaS, PaaS, DaaS, CaaS, FaaS... ↩

5. On constate souvent que cette équipe est constituée des mêmes personnes qui font aussi de l’ingénierie de plateforme. Deux rôles différents mais compétences similaires, donc souvent mêmes personnes. ↩

6. Dans un monde idéal, ces personnes sont censées consommer directement les API de la plateforme : écrire les Dockerfiles, configurer les pipelines CI/CD... Mais c’est parfois délégué aux équipes plateformes pour diverses raisons (manque de temps, complexité...). Je pense que cela sera résolu par plus d’abstraction, d’automatisation et d’IA, car ces configurations sont souvent répétitives. C’est aussi pour cela qu’on développe CWCloud 😜 ↩

7. Service Level Agreement ↩

8. Information Technology Service Management. En gros, gérer toute l’organisation avec des outils à tickets comme Jira, Asana, Mantis, etc. ↩

9. Return on Investment ↩