Three Ways et CALMS
Les deux cadres qui structurent la pratique DevOps.
Le DevOps n'est pas qu'une collection de bonnes intentions ou d'outils à la mode. Deux modèles complémentaires structurent sa philosophie : les Three Ways de Gene Kim et le modèle CALMS. Nés à quelques années d'intervalle, portés par des auteurs différents, ils poursuivent le même objectif — transformer la façon dont les équipes livrent de la valeur — mais ne répondent pas à la même question.
| Approche | Origine | Objet | Question |
|---|---|---|---|
| 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 prérequis culturels pour réussir ? |
Deux modèles, deux niveaux : CALMS pose les fondations, les Three Ways dessinent l'architecture.
En bref
Les Three Ways décrivent comment le travail doit circuler CALMS décrit les conditions culturelles qui permettent ce flux. Appliquer l'un sans l'autre bute toujours sur un mur : soit un flux théorique que la culture empêche d'exister, soit une culture bienveillante sans discipline de flux pour la traduire en résultats.
Le modèle CALMS
CALMS résume les cinq conditions culturelles jugées nécessaires à une transformation réussie. Le nom n'est pas apparu d'un coup : en 2010, John Willis et Damon Edwards créent CAMS en 2012, Jez Humble ajoute le L de Lean, pour intégrer explicitement la chasse au gaspillage héritée du système de production Toyota. Aucun pilier ne fonctionne isolément : retirez-en un, l'édifice se déséquilibre.
Culture — comment on travaille ensemble
Une équipe de football où chaque joueur optimise ses statistiques personnelles perd contre une équipe qui joue collectif. En entreprise, c'est pareil : si Dev optimise la vitesse, Ops la stabilité et la sécurité le blocage, personne ne gagne.
| Règle | Avant, en silos | Après, en DevOps |
|---|---|---|
| Objectif commun | chacun ses indicateurs | livrer de la valeur au client |
| Responsabilité partagée | « ce n'est pas mon problème » | you build it, you run it |
| Droit à l'erreur | on cache les problèmes | on apprend des erreurs |
Un changement de mentalité qui ne se décrète pas : il se construit.
Le piège du *DevOps washing*
Acheter des outils sans changer la culture, c'est du DevOps washing : vous aurez une chaîne CI/CD parfaite…\ et toujours des silos et du blâme.
Automation — comment gagner du temps
Personne ne lave ses vêtements à la main alors qu'une machine le fait mieux. Si une tâche est répétitive, automatisez-la. Le paradoxe : plus une tâche est rare et critique, plus elle doit être automatisée. Un humain qui exécute une procédure une fois par an oublie des étapes un script testé reste fiable.
| À automatiser | À ne pas automatiser tout de suite |
|---|---|
| les déploiements | les processus qui changent souvent |
| les tests | les processus que personne ne comprend |
| le provisionnement | les cas rares et sans risque |
Concentrez l'effort sur les tâches à forte valeur et faible variabilité.
Lean — où perd-on du temps
Vous commandez un café : le barista met deux minutes à le préparer, mais vous avez attendu huit minutes dans la file. Le temps de travail réel représente 20 % du total le reste est du gaspillage — toute activité sans valeur perçue par le client. En informatique, c'est pareil : une fonctionnalité demande trois jours de développement, mais trois semaines entre l'idée et la production.
| Gaspillage | Exemple |
|---|---|
| Fonctionnalités inutiles | du code que personne n'utilise |
| Attente | attendre une approbation, un environnement |
| Transferts | passer de Dev à la recette, puis à Ops |
| Processus excessifs | de la documentation que personne ne lit |
| Travail partiel | des fonctionnalités commencées, jamais finies |
| Changement de contexte | interruptions, réunions |
| Défauts | retravail, corrections |
Les sept gaspillages informatiques, adaptés des sept mudas du système Toyota.
Measurement — comment savoir si ça marche
On ne conduit pas sans compteur de vitesse. Les métriques DORA jouent ce rôle de tableau de bord. Historiquement, DORA classait les équipes en quatre paliers sur quatre métriques : fréquence de déploiement, délai de livraison, taux d'échec des changements et temps de restauration. Le rapport 2025 a fait évoluer la méthode : plutôt qu'un classement, il identifie sept profils d'équipe qui combinent performance de livraison et facteurs humains, comme le risque d'épuisement professionnel. L'objectif reste le même : sortir des débats d'opinion pour s'appuyer sur des données.
Le piège de la mesure
Trop de métriques, et personne ne les regarde. Limitez-vous à quatre ou cinq indicateurs clés, affichés là où l'équipe les voit vraiment.
Sharing — comment diffuser les connaissances
Si « seul Jean sait faire ça » et que Jean est malade, part ou change de poste, c'est un problème — le bus factor. Le partage est une assurance contre ce risque, et un accélérateur d'apprentissage.
| Fréquence | Pratique |
|---|---|
| Quotidienne | programmation en binôme |
| Hebdomadaire | guildes, communautés de pratique |
| Mensuelle | retours d'expérience, post-mortems publics |
| Continue | documentation traitée comme du code |
Le partage se ritualise : sans rythme, il n'a pas lieu.
| Pilier | Question clé | Anti-patron |
|---|---|---|
| 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 |
| Sharing | comment diffuse-t-on les connaissances ? | « seul Jean sait faire ça » |
Récapitulatif : cinq questions, cinq pièges.
Les Three Ways
Introduits par Gene Kim dans The Phoenix Project (2013) puis détaillés dans The DevOps Handbook, les Three Ways ne sont pas nés dans l'informatique : ils viennent de l'industrie manufacturière, de Toyota et de la théorie des contraintes d'Eliyahu Goldratt. Le vocabulaire de la chaîne de production n'est donc pas une image, c'est une filiation revendiquée.
Le travail circule vers la droite, l'information vers la gauche, l'apprentissage boucle sur l'ensemble.
Premier Way — Flow
Livrer de la valeur au client le plus vite possible, sans embouteillages.
| Règle | Pourquoi | Comment |
|---|---|---|
| Limiter le travail en cours | trop de tâches en parallèle créent des embouteillages | deux à trois tickets en cours par personne, au maximum |
| Petits lots, souvent | un petit changement, un petit risque | commits fréquents, déploiements quotidiens |
| Automatiser | les humains sont lents et faillibles | CI/CD, tests automatisés, infrastructure en code |
Trois règles issues de la théorie des contraintes et du système Toyota.
L'ennemi du flux est le goulot d'étranglement. Si l'équipe de développement livre cinquante fonctionnalités par mois mais que la recette n'en valide que vingt, recruter des développeurs ne fera qu'empirer le problème : le travail s'accumulera simplement plus vite en amont.
Loi de Little
Délai de livraison = travail en cours / débit. Pour livrer plus vite, réduisez le travail en cours : c'est plus facile et plus rapide que d'augmenter le débit.
Deuxième Way — Feedback
Plus on détecte un problème tôt, moins il coûte cher à corriger. L'objectif est d'installer des boucles de rétroaction à plusieurs échelles de temps.
| Quand | Mécanisme | Délai |
|---|---|---|
| en écrivant le code | tests unitaires | secondes |
| avant de fusionner | revue de code, intégration continue | minutes |
| après déploiement | supervision, alertes | temps réel |
| en continu | mesures d'usage, retours utilisateurs | heures, jours |
La règle d'or : si la construction est cassée, on arrête tout et on répare — elle bloque le flux entier.
Troisième Way — Learning
Les erreurs sont des occasions d'amélioration, pas des fautes à punir.
| Pratique | Principe |
|---|---|
| Post-mortem sans blâme | analyser l'incident pour améliorer le système, pas pour punir |
| Ingénierie du chaos | provoquer des pannes contrôlées pour découvrir les faiblesses avant l'incident réel |
| Journées d'exercice | s'entraîner aux incidents comme les pompiers s'entraînent aux incendies |
Ces trois pratiques ont un prérequis commun : la sécurité psychologique.
Le piège du blâme
Si les gens craignent d'être punis, ils cacheront les problèmes — et les mêmes erreurs se répéteront. La sécurité psychologique n'est pas un supplément d'âme optionnel : c'est la condition d'existence du troisième Way.
La synergie des deux modèles
| 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 gaspillages et attentes |
| Feedback | détecter les problèmes tôt | Measurement : des métriques pour voir Sharing : diffuser alertes et enseignements |
| Learning | apprendre des erreurs | Culture : la sécurité psychologique pour les avouer Sharing : capitaliser les leçons |
La carte de correspondance entre les deux modèles.
Un cas concret de diagnostic
Votre équipe met trois semaines à livrer une fonctionnalité simple. Pourquoi ? On analyse d'abord avec les Three Ways : où sont les blocages (la recette est saturée, quinze tickets en attente) ? Quand découvre-t-on les défauts (en recette, deux semaines après le développement) ? A-t-on déjà eu ce problème (oui, mais aucun post-mortem n'a été fait) ? On identifie ensuite les piliers CALMS défaillants.
| Symptôme | Pilier défaillant | Action |
|---|---|---|
| recette saturée | Automation | automatiser les tests de non-régression |
| défauts découverts tard | Measurement | ajouter tests et métriques de qualité |
| pas de post-mortem | Culture | instaurer les retours d'expérience sans blâme |
| leçons non partagées | Sharing | documenter et diffuser les apprentissages |
On commence par le goulot principal — ici l'automatisation des tests le reste suit.
Grille de diagnostic rapide
| Si vous observez… | Three Way touché | Pilier à renforcer |
|---|---|---|
| des déploiements longs et risqués | Flow | Automation, Lean |
| des défauts découverts en production | Feedback | Measurement, Automation |
| les mêmes incidents qui se répètent | Learning | Culture, Sharing |
| des équipes qui se renvoient la balle | Flow et Feedback | Culture |
| « on n'a pas le temps de documenter » | Learning | Sharing, Lean |
| des métriques que personne ne regarde | Feedback | Measurement, Culture |
Partir du symptôme observable pour remonter à la cause structurelle.
Les anti-patrons de la synergie
| Ce qu'on entend | Le problème réel | La correction |
|---|---|---|
| « 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, construire une base de connaissances |
| « on a des tableaux de bord » | Measurement sans Flow : on mesure sans agir | lier chaque métrique à une action |
| « on collabore bien » | Culture sans Automation : on collabore sur des tâches manuelles | automatiser pour libérer du temps utile |
Quatre phrases rassurantes qui trahissent une adoption partielle.
La règle des trois questions
Devant un problème DevOps, demandez-vous toujours : quel Three Way est bloqué (Flow, Feedback ou Learning) ? Quel pilier CALMS manque ? Et quelle est la plus petite action qui aurait le plus grand impact ?
À retenir de cette séance
Les Three Ways structurent la philosophie — Flow, Feedback, Learning CALMS définit les piliers culturels. Les deux viennent de l'industrie : théorie des contraintes, système Toyota, qualité totale — le DevOps n'invente rien, il adapte. Flow : de petits lots fréquents, la loi de Little explique pourquoi réduire le travail en cours accélère tout. Feedback : détecter tôt, car le coût de correction croît avec le délai. Learning : échouer en sécurité. La culture est le fondement : les outils sans changement culturel, c'est du DevOps washing.
Réponse unique
D'après la loi de Little, comment raccourcir le délai de livraison sans toucher au débit ?
Indice · Le délai est un rapport. Si le dénominateur ne bouge pas, que reste-t-il ?
[ METTRE EN PRATIQUE ]
Mesurer son travail en cours
3 étapes · 30 min · 120 XP
[ CETTE LEÇON DANS LES PARCOURS ]
- Ingénieur DevOpsétape 2 / 23suivant — Agile, DevOps et SRE →