DevOps : définition, principes CALMS et métriques DORA

Le DevOps désigne une manière de concevoir, livrer et exploiter un logiciel dans laquelle les développeurs et les opérationnels ne forment plus deux mondes séparés, mais une seule chaîne de valeur partagée.

Pendant longtemps, les deux équipes ont eu des objectifs contradictoires. Les développeurs étaient évalués sur leur capacité à livrer des nouveautés, les équipes d'exploitation sur la stabilité de la production. Résultat : des mises en production rares, volumineuses et redoutées, suivies d'incidents dont chacun rejetait la responsabilité sur l'autre. Le DevOps propose de casser ce mur en partageant les objectifs, les outils et la responsabilité du logiciel en production.

Le mouvement prend forme à la fin des années 2000. En 2009, John Allspaw et Paul Hammond présentent à la conférence Velocity leur talk « 10+ Deploys per Day: Dev and Ops Cooperation at Flickr ». La même année, le consultant belge Patrick Debois organise à Gand les premiers DevOpsDays, qui donnent son nom au mouvement. Le roman The Phoenix Project (2013) puis le livre Accelerate (2018), fondé sur les données du programme de recherche DORA, achèvent de le populariser.

Concrètement, le DevOps s'outille par l'automatisation : CI/CD pour tester et déployer chaque modification, Infrastructure as Code pour décrire les serveurs et les réseaux, conteneurs et orchestration pour rendre les environnements reproductibles, observabilité pour savoir ce qui se passe en production.

À retenir : le DevOps n'est pas une équipe ni un outil. C'est une organisation du travail dans laquelle ceux qui construisent le logiciel partagent la responsabilité de son fonctionnement en production.

Pour évaluer la maturité DevOps d'une organisation, on utilise souvent le modèle CALMS. Il dérive de l'acronyme CAMS proposé par John Willis et Damon Edwards, auquel Jez Humble a ajouté le L du Lean.

• Culture : des objectifs communs entre Dev et Ops, une responsabilité partagée et des analyses d'incident sans recherche de coupable (« blameless postmortems »).
• Automation : tout ce qui est répétitif est automatisé, des tests au provisionnement de l'infrastructure, en passant par le déploiement.
• Lean : travailler en petits lots, limiter les tâches en cours, éliminer les attentes et les gaspillages dans la chaîne de livraison.
• Measurement : mesurer la performance de livraison, la santé de la production et l'usage réel pour décider sur des faits.
• Sharing : partager les connaissances, les outils, la documentation et les retours d'expérience entre équipes.

Le modèle rappelle un point essentiel : l'automatisation n'est qu'un pilier sur cinq. Une organisation qui installe une chaîne CI/CD sans changer sa culture ni ses indicateurs n'obtient qu'une partie des bénéfices.

Le programme DevOps Research and Assessment (DORA), fondé par Nicole Forsgren, Jez Humble et Gene Kim puis racheté par Google en 2018, a étudié des milliers d'équipes. Ses travaux ont identifié quatre indicateurs qui distinguent les organisations les plus performantes.

Le principal enseignement de ces études est contre-intuitif : vitesse et stabilité ne s'opposent pas. Les équipes qui déploient le plus souvent sont aussi celles qui ont le moins d'incidents et qui les résolvent le plus vite, parce que chaque changement est petit, testé et facile à annuler.

Bon usage : ces métriques servent à piloter l'amélioration d'une équipe dans le temps, pas à comparer ou classer des équipes entre elles.

Prenons une équipe qui doit corriger un bug sur une API de commande. Dans une organisation DevOps, le parcours ressemble à ceci :

1. Code : le développeur corrige le bug, ajoute un test qui le reproduit et ouvre une merge request.
2. Intégration continue : le pipeline exécute les tests, analyse la qualité et la sécurité du code, puis construit une image Docker.
3. Revue : un pair relit le code ; la fusion dans la branche principale déclenche la suite.
4. Déploiement : l'image est déployée en préproduction, puis progressivement en production sur un cluster Kubernetes.
5. Surveillance : les tableaux de bord Prometheus confirment que le taux d'erreur baisse ; une alerte aurait déclenché un retour arrière automatique.

L'ensemble prend moins d'une heure, sans ticket transmis à une autre équipe ni intervention manuelle sur un serveur. Si une faille avait été détectée dans une dépendance, le pipeline l'aurait bloquée : c'est le terrain du DevSecOps.

Ces trois termes sont souvent confondus. Ils partagent les mêmes valeurs, mais n'ont pas le même périmètre.

Le Platform Engineering répond à une limite observée dans les grandes organisations : demander à chaque équipe de tout maîtriser, du code à l'infrastructure, crée une charge cognitive excessive. Une équipe plateforme fournit alors des chemins balisés (modèles de pipelines, environnements prêts à l'emploi) que les équipes produit consomment en autonomie.

Si le DevOps est une culture, le marché a vu émerger un métier dédié : le DevOps Engineer. Son rôle est d'outiller la démarche, en construisant et en maintenant les pipelines CI/CD, l'infrastructure en code, les clusters de conteneurs et la supervision.

Ses compétences couvrent un large spectre : administration Linux et réseau, scripting, au moins un fournisseur Cloud, Docker et Kubernetes, Terraform ou Ansible, et une bonne compréhension du développement logiciel. Les qualités relationnelles comptent autant : le DevOps Engineer travaille à l'interface de plusieurs équipes et doit faire adopter de nouvelles pratiques. Notre article DevOps Engineer : tout savoir sur ce métier détaille les missions, les salaires et les parcours possibles.