Le DevOps n’est pas qu’une collection de bonnes intentions ou d’outils à la mode. Deux appreoches complémentaires structurent sa philosophie et guident sa mise en œuvre : les Three Ways et le modèle CALMS. Comprendre ces approches, c’est comprendre l’essence du DevOps — au-delà des pipelines CI/CD et des containers.
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).
Le modèle CALMS
Section intitulée « Le modèle CALMS »CALMS en une image
Section intitulée « CALMS en une image »
D’où vient CALMS ?
Section intitulée « D’où vient CALMS ? »- 2010 : John Willis et Damon Edwards créent CAMS (sans le L)
- 2012 : Jez Humble ajoute le L de Lean → CALMS
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 stats 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.
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.
Le paradoxe : plus une tâche est rare et critique, plus elle doit être automatisée. Pourquoi ? Un humain qui fait une procédure 1x/an oublie des étapes. Un script exécuté 1x/an est 100% fiable.
Tout n’est pas bon à automatiser immédiatement. Concentrez vos efforts sur les tâches à forte valeur ajoutée et faible variabilité.
| 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 |
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 10 minutes dans la file. Le temps de travail réel = 20%. Le reste = gaspillage.
En IT, c’est pareil. Une feature prend 3 jours de dev… 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 env |
| Transferts | Passer de Dev → QA → Ops |
| Processus excessifs | Docs que personne ne lit |
| Travail partiel | Features commencées, jamais finies |
| Changement de contexte | Interruptions, réunions |
| Bugs | Retravail, corrections |
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 4 métriques DORA sont votre tableau de bord. Issues de la recherche de Google’s DevOps Research and Assessment, ces métriques permettent de mesurer objectivement la performance de votre organisation :
| Métrique | Question | Cible “elite” |
|---|---|---|
| Deployment Frequency | À quelle fréquence déployez-vous ? | Plusieurs fois/jour |
| Lead Time | Combien de temps du commit à la prod ? | < 1 heure |
| Change Failure Rate | Quel % de déploiements causent des incidents ? | < 15% |
| MTTR | Combien de temps pour restaurer le service ? | < 1 heure |
Le piège : trop de métriques = personne ne regarde. Limitez-vous à 4-5 métriques clés.
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 / gagne au loto → problème. Le partage est une assurance contre ce risque, 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 |
| Hebdo | Guildes / communautés de pratique |
| Mensuel | REX, post-mortems publics |
| Continu | Documentation as code |
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 / 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). Ces principes ne sont pas nés dans l’IT — ils viennent de l’industrie manufacturière (Toyota, théorie des contraintes).
Les Three Ways en une image
Section intitulée « Les Three Ways en une image »Imaginez une usine qui fabrique des voitures :
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 (WIP), on finit plus vite.
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 = embouteillages | Max 2-3 tickets “In Progress” par personne |
| Petits lots, souvent | 1 petit changement = 1 petit risque | Commits fréquents, déploiements quotidiens |
| Automatiser | Les humains sont lents et font des erreurs | CI/CD, tests auto, 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 Dev livre 50 features/mois mais que la QA ne peut en valider que 20, vous avez un goulot. Recruter plus de devs ne fera qu’empirer le problème — il faut d’abord débloquer la QA.
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 »- Douleur au genou détectée tôt → repos + kiné = 2 semaines
- Douleur ignorée pendant 6 mois → opération = 3 mois d’arrêt
En développement, c’est pareil. Un bug détecté en 5 minutes par un test automatique coûte 100x 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, CI | 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 tout le flux.
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 le transport le plus sûr ? Parce que chaque incident est analysé sans blâme, et les leçons sont partagées avec toute l’industrie.
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 |
| Game Days | S’entraîner aux incidents comme les pompiers s’entraînent aux incendies |
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 = le moteur (comment ça avance)
- CALMS = 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.
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 :
| 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 attentes | ||
| Feedback | Détecter les problèmes tôt | Measurement : métriques pour voir ce qui se passe |
| Sharing : diffuser les alertes et insights à 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 feature 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 dev
- 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 + 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 : automatisation des tests QA). Les autres améliorations suivront naturellement.
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 :
| 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 DevOps de manière partielle ou superficielle. Reconnaître ces patterns permet de les corriger avant qu’ils ne s’installent :
| 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 |
À 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 WIP accélère le flux
-
Feedback = détecter tôt : Le coût de correction augmente exponentiellement avec le temps
-
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”
-
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, 2nd ed. 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 & 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