Le DevOps n'est pas qu'une collection de bonnes intentions ou d'outils à la mode. Deux modèles complémentaires structurent sa philosophie et guident sa mise en œuvre : les Three Ways de Gene Kim et le modèle CALMS. Cette page s'adresse à toute personne qui découvre le DevOps (développeur, ops, manager) et veut comprendre ce qui se cache derrière le mot avant de choisir des outils. Vous y trouverez l'origine de chaque modèle, une explication accessible de leurs composants, des exemples concrets tirés de situations d'équipe réelles, et une grille de diagnostic pour repérer ce qui bloque dans votre organisation.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Distinguer les Three Ways (processus) et CALMS (culture), et comprendre pourquoi les deux sont nécessaires.
- Expliquer les 5 piliers de CALMS avec une analogie simple pour chacun.
- Décrire les 3 lois qui régissent le Flow, le Feedback et le Learning selon Gene Kim.
- Relier chaque Three Way à un ou plusieurs piliers CALMS pour diagnostiquer un problème d'équipe.
- Repérer les anti-patterns fréquents qui trahissent une adoption superficielle du DevOps.
Pourquoi deux approches ?
Section intitulée « Pourquoi deux approches ? »Avant de plonger dans les détails, clarifions la différence fondamentale entre ces deux approches. Ces deux modèles sont nés à quelques années d'intervalle, portés par des auteurs différents, mais poursuivent le même objectif : transformer la façon dont les équipes IT collaborent et livrent de la valeur.
| Approche | Origine | Focus | Question à laquelle il répond |
|---|---|---|---|
| Three Ways | Gene Kim (2013) | Principes de flux et d'amélioration | "Comment organiser le travail pour livrer de la valeur ?" |
| CALMS | John Willis, Damon Edwards, Jez Humble (2010-2012) | Piliers culturels et organisationnels | "Quels sont les prérequis culturels pour réussir ?" |
En résumé :
- Les Three Ways décrivent comment le travail doit circuler dans une organisation DevOps.
- CALMS décrit les conditions culturelles qui permettent ce flux.
Les deux se complètent. On peut voir CALMS comme les fondations (culture, valeurs) et les Three Ways comme l'architecture (processus, flux). Un projet qui applique l'un sans l'autre finit toujours par buter sur un mur : soit un flux théorique que la culture d'équipe empêche d'exister, soit une culture bienveillante sans discipline de flux pour la traduire en résultats.
Le modèle CALMS
Section intitulée « Le modèle CALMS »CALMS en une image
Section intitulée « CALMS en une image »CALMS est un acronyme qui résume les 5 conditions culturelles jugées nécessaires à une transformation DevOps réussie. Avant de détailler chaque pilier, le schéma ci-dessous les pose côte à côte pour montrer qu'aucun d'eux ne fonctionne isolément : retirez-en un et l'édifice se déséquilibre.
D'où vient CALMS ?
Section intitulée « D'où vient CALMS ? »Le nom CALMS n'est pas apparu d'un coup : c'est le résultat de deux ajouts successifs par des praticiens différents, qui affinaient une même intuition sur ce qu'il fallait pour réussir une transformation DevOps.
- 2010 : John Willis et Damon Edwards créent CAMS (sans le L), un acronyme pour décrire les piliers d'une culture DevOps naissante.
- 2012 : Jez Humble ajoute le L de Lean → CALMS, pour intégrer explicitement la chasse au gaspillage héritée du Toyota Production System.
Les 5 piliers expliqués simplement
Section intitulée « Les 5 piliers expliqués simplement »Culture, "Comment on travaille ensemble"
Section intitulée « Culture, "Comment on travaille ensemble" »L'analogie : l'équipe de sport
Une équipe de foot où chaque joueur optimise ses statistiques personnelles (buts marqués) perd face à une équipe qui joue collectif. En entreprise, c'est pareil : Dev qui optimise la vitesse, Ops qui optimise la stabilité, Sécu qui bloque tout, personne ne gagne si chacun reste dans son silo.
Les 3 règles de la culture DevOps définissent les comportements attendus dans une organisation mature. Le passage d'un mode "silos" à un mode "DevOps" représente un changement de mentalité profond qui ne se décrète pas, mais se construit progressivement :
| Règle | Avant (silos) | Après (DevOps) |
|---|---|---|
| Objectif commun | Chacun ses KPIs | "Livrer de la valeur au client" |
| Responsabilité partagée | "C'est pas mon problème" | "You build it, you run it" |
| Droit à l'erreur | On cache les problèmes | On apprend des erreurs |
Automation, "Comment gagner du temps"
Section intitulée « Automation, "Comment gagner du temps" »L'analogie : la machine à laver
Personne ne lave ses vêtements à la main alors qu'une machine le fait mieux. Pareil en IT : si une tâche est répétitive, automatisez-la plutôt que de la refaire manuellement à chaque fois.
Le paradoxe : plus une tâche est rare et critique, plus elle doit être automatisée. Pourquoi ? Un humain qui exécute une procédure une fois par an oublie des étapes. Un script exécuté une fois par an reste fiable à 100 %, à condition d'être testé.
Tout n'est pas bon à automatiser immédiatement. Concentrez vos efforts sur les tâches à forte valeur ajoutée et faible variabilité : c'est là que le retour sur investissement est le plus rapide.
| Automatiser | Ne pas automatiser (tout de suite) |
|---|---|
| Déploiements | Processus qui changent souvent |
| Tests | Processus que personne ne comprend |
| Provisioning | Cas rares et sans risque |
Pour aller plus loin sur ce pilier, la page Éliminer le Toil détaille comment distinguer le travail répétitif sans valeur (le toil) du travail qui mérite d'être fait à la main.
Lean, "Où perd-on du temps ?"
Section intitulée « Lean, "Où perd-on du temps ?" »L'analogie : la file d'attente
Vous commandez un café. Le barista met 2 minutes à le préparer, mais vous avez attendu 8 minutes dans la file. Le temps de travail réel représente donc 20 % du temps total. Le reste est du gaspillage, une notion centrale du Lean qui désigne toute activité qui n'ajoute aucune valeur perçue par le client.
En IT, c'est pareil. Une fonctionnalité prend 3 jours de développement... mais 3 semaines entre l'idée et la production. Où passe le temps ?
Les 7 gaspillages IT sont adaptés des 7 mudas du Toyota Production System. Identifier ces gaspillages dans votre flux de travail est la première étape pour les éliminer :
| Gaspillage | Exemple |
|---|---|
| Features inutiles | Code que personne n'utilise |
| Attente | Attendre une approbation, un environnement |
| Transferts | Passer de Dev à QA puis à Ops |
| Processus excessifs | Documentation que personne ne lit |
| Travail partiel | Fonctionnalités commencées, jamais finies |
| Changement de contexte | Interruptions, réunions |
| Bugs | Retravail, corrections |
Ce pilier trouve sa suite logique dans la page Value Stream et Flow, qui montre comment cartographier ces gaspillages sur un flux de valeur réel.
Measurement, "Comment savoir si ça marche ?"
Section intitulée « Measurement, "Comment savoir si ça marche ?" »L'analogie : le tableau de bord de voiture
Vous ne conduisez pas sans compteur de vitesse. En DevOps, les métriques DORA jouent ce rôle de tableau de bord. Issues de la recherche du programme DevOps Research and Assessment (racheté par Google en 2018), elles permettent de mesurer objectivement la performance de livraison d'une organisation, plutôt que de se fier à des impressions.
Historiquement, DORA classait les équipes en 4 paliers (Elite, High, Medium, Low) sur 4 métriques : Deployment Frequency, Lead Time for Changes, Change Failure Rate et MTTR. Le rapport 2025 a fait évoluer cette méthode : DORA ne classe plus les équipes uniquement par ces paliers, mais identifie 7 profils d'équipe qui combinent la performance de livraison avec des facteurs humains comme le burn-out ou la friction ressentie. L'objectif reste le même : sortir des débats d'opinion pour s'appuyer sur des données. Le détail des métriques, des seuils actuels et de la méthode de collecte est couvert dans la page dédiée Les métriques DORA.
Le piège : trop de métriques et personne ne les regarde. Limitez-vous à 4-5 métriques clés, affichées quelque part où l'équipe les voit vraiment.
Sharing, "Comment diffuser les connaissances ?"
Section intitulée « Sharing, "Comment diffuser les connaissances ?" »L'analogie : le bus factor
Si "seul Jean sait faire ça" et que Jean est malade, part, ou change de poste, c'est un problème. Le partage est une assurance contre ce risque, appelé le bus factor, mais c'est aussi un accélérateur d'apprentissage pour toute l'équipe.
Les pratiques de partage doivent être ritualisées à différentes fréquences pour créer une culture d'apprentissage continu :
| Fréquence | Pratique |
|---|---|
| Quotidien | Pair programming |
| Hebdomadaire | Guildes, communautés de pratique |
| Mensuel | REX, post-mortems publics |
| Continu | Documentation as code |
Les pages Incidents et Postmortems et Former les équipes à la sécurité détaillent comment mettre ces rituels en place concrètement.
Récapitulatif : CALMS
Section intitulée « Récapitulatif : CALMS »Ce tableau synthétise les 5 piliers du modèle CALMS. Pour chaque pilier, posez-vous la question clé et vérifiez que vous n'êtes pas tombé dans l'anti-pattern correspondant :
| Pilier | Question clé | Anti-pattern |
|---|---|---|
| Culture | Comment travaille-t-on ensemble ? | Silos, blâme |
| Automation | Qu'est-ce qui peut être automatisé ? | Tout faire à la main |
| Lean | Où perd-on du temps ? | Gaspillages invisibles |
| Measurement | Comment sait-on si ça marche ? | Pas de métriques ou trop de métriques |
| Sharing | Comment diffuse-t-on les connaissances ? | "Seul Jean sait faire ça" |
Les Three Ways : origine et contexte
Section intitulée « Les Three Ways : origine et contexte »D'où viennent les Three Ways ?
Section intitulée « D'où viennent les Three Ways ? »Les Three Ways ont été introduits par Gene Kim dans le roman "The Phoenix Project" (2013). Ils ont ensuite été détaillés dans "The DevOps Handbook" (2016, 2e édition 2021). Ces principes ne sont pas nés dans l'IT : ils viennent de l'industrie manufacturière, en particulier de Toyota et de la théorie des contraintes d'Eliyahu Goldratt.
Les Three Ways en une image
Section intitulée « Les Three Ways en une image »Imaginez une usine qui fabrique des voitures : chaque poste de travail reçoit des pièces, les transforme, puis les transmet au poste suivant. Le DevOps applique la même logique au travail logiciel.
En DevOps, c'est pareil : le code circule du développement vers la production (Flow), on détecte les problèmes le plus tôt possible (Feedback), et on apprend de chaque incident (Learning).
Premier Way : Flow, faire circuler le travail
Section intitulée « Premier Way : Flow, faire circuler le travail »L'idée en une phrase
Section intitulée « L'idée en une phrase »Livrer de la valeur au client le plus vite possible, sans embouteillages.
L'analogie : l'autoroute
Section intitulée « L'analogie : l'autoroute »Pensez à une autoroute. Quand est-ce qu'elle est la plus efficace ?
- Saturée à 100 % : embouteillages, personne n'avance.
- À 70-80 % de capacité : le trafic est fluide, tout le monde avance.
C'est pareil pour une équipe. Si tout le monde a 10 tâches en parallèle, personne ne finit rien. Si on limite le travail en cours (le WIP, ou Work In Progress), on finit plus vite, même si ça semble contre-intuitif au premier abord.
Les 3 règles du Flow
Section intitulée « Les 3 règles du Flow »Ces trois règles constituent le cœur du First Way. Elles sont issues de la théorie des contraintes d'Eliyahu Goldratt et du système de production Toyota :
| Règle | Pourquoi | Comment |
|---|---|---|
| Limiter le travail en cours | Trop de tâches en parallèle créent des embouteillages | Maximum 2-3 tickets "In Progress" par personne |
| Petits lots, souvent | Un petit changement représente un petit risque | Commits fréquents, déploiements quotidiens |
| Automatiser | Les humains sont lents et font des erreurs | CI/CD, tests automatisés, Infrastructure as Code |
L'ennemi du Flow : le goulot d'étranglement
Section intitulée « L'ennemi du Flow : le goulot d'étranglement »Si votre équipe de développement livre 50 fonctionnalités par mois mais que la QA ne peut en valider que 20, vous avez un goulot d'étranglement. Recruter plus de développeurs ne fera qu'empirer le problème : il faut d'abord débloquer la QA, sinon le travail s'accumule simplement plus vite en amont.
Deuxième Way : Feedback, détecter les problèmes tôt
Section intitulée « Deuxième Way : Feedback, détecter les problèmes tôt »L'idée en une phrase
Section intitulée « L'idée en une phrase »Plus on détecte un problème tôt, moins il coûte cher à corriger.
L'analogie : la visite médicale
Section intitulée « L'analogie : la visite médicale »- Une douleur au genou détectée tôt entraîne du repos et de la kinésithérapie : 2 semaines.
- La même douleur ignorée pendant 6 mois entraîne une opération : 3 mois d'arrêt.
En développement logiciel, c'est pareil. Un bug détecté en 5 minutes par un test automatique coûte largement moins cher qu'un bug découvert en production par un client furieux.
Les boucles de feedback
Section intitulée « Les boucles de feedback »L'objectif est de créer des boucles de rétroaction à plusieurs niveaux, du plus rapide (secondes) au plus lent (jours). Plus la boucle est courte, plus le coût de correction est faible :
| Quand | Mécanisme | Temps |
|---|---|---|
| En écrivant le code | Tests unitaires | Secondes |
| Avant de merger | Revue de code, intégration continue | Minutes |
| Après déploiement | Monitoring, alertes | Temps réel |
| En continu | Analytics, retours utilisateurs | Heures, jours |
La règle d'or : si le build est cassé, on arrête tout et on répare. Un build cassé bloque l'ensemble du flux, pas seulement la tâche en cours. La page Boucle de rétroaction approfondit ce mécanisme avec des exemples de mise en œuvre.
Troisième Way : Learning, apprendre de ses erreurs
Section intitulée « Troisième Way : Learning, apprendre de ses erreurs »L'idée en une phrase
Section intitulée « L'idée en une phrase »Les erreurs sont des opportunités d'amélioration, pas des fautes à punir.
L'analogie : l'aviation
Section intitulée « L'analogie : l'aviation »Pourquoi l'avion est-il l'un des transports les plus sûrs ? Parce que chaque incident est analysé sans blâme, et les leçons sont partagées avec toute l'industrie, pas seulement avec la compagnie concernée.
En DevOps, c'est le post-mortem sans blâme : on ne cherche pas "qui a fait l'erreur", mais "comment le système a permis cette erreur".
Les pratiques clés
Section intitulée « Les pratiques clés »Trois pratiques emblématiques incarnent le Third Way. Elles nécessitent toutes un prérequis : la sécurité psychologique, c'est-à-dire la certitude que personne ne sera puni pour avoir signalé un problème :
| Pratique | Principe |
|---|---|
| Post-mortem sans blâme | Analyser les incidents pour améliorer le système, pas pour punir |
| Chaos Engineering | Provoquer des pannes contrôlées pour découvrir les faiblesses avant qu'elles ne causent un vrai incident |
| Game Days | S'entraîner aux incidents comme les pompiers s'entraînent aux incendies |
Pour aller plus loin sur ce Way, la page Incidents et Postmortems détaille la conduite d'un post-mortem de bout en bout.
Three Ways + CALMS : la synergie
Section intitulée « Three Ways + CALMS : la synergie »Pourquoi combiner les deux ?
Section intitulée « Pourquoi combiner les deux ? »L'analogie : la voiture
- Les Three Ways représentent le moteur (comment ça avance).
- CALMS représente le carburant (ce qui fait tourner le moteur).
Un moteur sans carburant ne démarre pas. Du carburant sans moteur ne sert à rien. Les deux sont indispensables, et c'est souvent l'un des deux qui manque quand une transformation DevOps stagne.
En pratique :
- Vous pouvez avoir un pipeline CI/CD parfait (Flow), mais si les équipes ne collaborent pas (Culture), le code restera bloqué dans des approbations interminables.
- Vous pouvez avoir une culture de partage excellente (Sharing), mais sans automatisation, vous partagerez des procédures manuelles pleines d'erreurs.
Comment les deux frameworks s'articulent
Section intitulée « Comment les deux frameworks s'articulent »Ce tableau montre comment chaque Three Way s'appuie sur les piliers CALMS pour être mis en œuvre concrètement. C'est la carte de correspondance entre les deux modèles, utile pour ne pas les traiter comme deux théories séparées :
| Three Way | Ce qu'il faut faire | Ce que CALMS apporte |
|---|---|---|
| Flow | Accélérer le flux de travail | Automation : éliminer les tâches manuelles |
| Lean : supprimer les gaspillages et les attentes | ||
| Feedback | Détecter les problèmes tôt | Measurement : métriques pour voir ce qui se passe |
| Sharing : diffuser les alertes et les enseignements à tous | ||
| Learning | Apprendre des erreurs | Culture : sécurité psychologique pour avouer les erreurs |
| Sharing : capitaliser et diffuser les leçons apprises |
Cas concret : diagnostiquer un problème
Section intitulée « Cas concret : diagnostiquer un problème »Scénario : votre équipe met 3 semaines à livrer une fonctionnalité simple. Pourquoi ?
-
Analysez avec les Three Ways
- Flow : où sont les blocages ? La QA est saturée, 15 tickets en attente.
- Feedback : quand découvre-t-on les bugs ? En recette, 2 semaines après le développement.
- Learning : a-t-on déjà eu ce problème ? Oui, mais aucun post-mortem n'a été fait.
-
Identifiez les piliers CALMS manquants
Symptôme (Three Ways) Pilier CALMS défaillant Action QA saturée Automation Automatiser les tests de régression Bugs découverts tard Measurement Ajouter des tests et des métriques de qualité Pas de post-mortem Culture Instaurer les REX sans blâme Leçons non partagées Sharing Documenter et diffuser les apprentissages -
Priorisez par impact
Commencez par le goulot principal (ici : l'automatisation des tests QA). Les autres améliorations suivront naturellement une fois ce verrou levé.
La grille de diagnostic rapide
Section intitulée « La grille de diagnostic rapide »Utilisez ce tableau comme un outil de diagnostic pour identifier rapidement ce qui manque dans votre organisation. Partez du symptôme observable (colonne de gauche) pour remonter vers la cause structurelle, plutôt que de traiter le symptôme isolément :
| Si vous observez... | Three Way impacté | Pilier CALMS à renforcer |
|---|---|---|
| Déploiements longs et risqués | Flow | Automation, Lean |
| Bugs découverts en production | Feedback | Measurement, Automation |
| Mêmes incidents qui se répètent | Learning | Culture, Sharing |
| Équipes qui se renvoient la balle | Flow + Feedback | Culture |
| "On n'a pas le temps de documenter" | Learning | Sharing, Lean |
| Métriques que personne ne regarde | Feedback | Measurement, Culture |
Les anti-patterns de la synergie
Section intitulée « Les anti-patterns de la synergie »Ces anti-patterns sont des pièges fréquents dans lesquels tombent les organisations qui adoptent le DevOps de manière partielle ou superficielle. Reconnaître ces schémas permet de les corriger avant qu'ils ne s'installent durablement :
| Anti-pattern | Problème | Solution |
|---|---|---|
| "On a automatisé, c'est bon" | Automation sans Culture : personne n'utilise les outils | Former, accompagner, montrer la valeur |
| "On fait des post-mortems" | Learning sans Sharing : les leçons restent dans un tiroir | Publier les post-mortems, créer une base de connaissances |
| "On a des dashboards" | Measurement sans Flow : on mesure mais on n'agit pas | Lier les métriques à des actions concrètes |
| "On collabore bien" | Culture sans Automation : on collabore sur des tâches manuelles | Automatiser pour libérer du temps de collaboration utile |
Cette même logique de diagnostic irrigue les choix d'organisation d'équipe : les pages Structurer ses équipes DevOps et Platform Engineering montrent comment le pilier Culture et le First Way (Flow) se traduisent concrètement dans la façon de découper les équipes et les plateformes internes.
À retenir
Section intitulée « À retenir »-
Les Three Ways structurent la philosophie : Flow (accélérer le flux), Feedback (créer des boucles rapides), Learning (apprendre continuellement).
-
CALMS définit les piliers culturels : Culture, Automation, Lean, Measurement, Sharing.
-
Les deux viennent de l'industrie : théorie des contraintes, Toyota Production System, Total Quality Management. Le DevOps n'invente rien, il adapte.
-
Flow = petits lots fréquents : la loi de Little explique pourquoi réduire le travail en cours accélère le flux.
-
Feedback = détecter tôt : le coût de correction augmente fortement avec le temps écoulé avant détection.
-
Learning = échouer en sécurité : les post-mortems sans blâme transforment les incidents en améliorations.
-
La culture est le fondement : les outils sans changement culturel, c'est du "DevOps washing".
-
Measurement a évolué : DORA est passé d'un classement en 4 paliers à 7 profils d'équipe en 2025, mais l'objectif reste le même, mesurer plutôt que supposer (détail dans Les métriques DORA).
-
CALMS + Three Ways = diagnostic complet : utilisez les deux pour évaluer et améliorer votre organisation.
Références
Section intitulée « Références »Ouvrages fondateurs
Section intitulée « Ouvrages fondateurs »- The Phoenix Project (2013), Gene Kim, Kevin Behr, George Spafford : le roman qui introduit les Three Ways.
- The DevOps Handbook (2016, 2e édition 2021), Gene Kim, Jez Humble, Patrick Debois, John Willis : le guide de référence pratique.
- Accelerate (2018), Nicole Forsgren, Jez Humble, Gene Kim : la recherche scientifique derrière les métriques DORA.
Lean et théorie des contraintes
Section intitulée « Lean et théorie des contraintes »- The Goal (1984), Eliyahu Goldratt : le roman fondateur de la théorie des contraintes.
- Toyota Production System (1988), Taiichi Ohno : le livre qui définit le TPS.
- Lean Software Development (2003), Mary et Tom Poppendieck : l'adaptation du Lean au logiciel.
Articles et ressources en ligne
Section intitulée « Articles et ressources en ligne »- The Three Ways: Principles Underpinning DevOps, Gene Kim, IT Revolution.
- Blameless PostMortems and a Just Culture, John Allspaw, Etsy Code as Craft.
- DORA Research, les rapports State of DevOps annuels, dont l'édition 2025 qui introduit les 7 profils d'équipe.