CALMS, les 3 voies, DORA
Le modèle CALMS est un acronyme proposé par Jez Humble, John Willis et d'autres leaders du mouvement DevOps autour de 2010–2011, dans le but de définir ce qu’est une organisation réellement DevOps.
Face à la multiplication des discours marketing (souvent centrés sur les outils), CALMS a été pensé comme un cadre d’évaluation qualitatif, combinant culture, pratiques et outils.
Pourquoi ce modèle ?
DevOps n'est pas un simple changement technologique : c’est une transformation qui touche la culture, l’organisation, les processus et les comportements.
Le modèle CALMS a donc été conçu pour aider les équipes à se situer, diagnostiquer leurs forces et faiblesses, et guider leur progression.
Que signifie CALMS ?
| Lettre | Signification | Ce que cela évalue |
|---|---|---|
| C | Culture | La confiance, la collaboration, l’alignement |
| A | Automation | Le niveau d’automatisation des tâches clés |
| L | Lean | L’optimisation du flux de travail |
| M | Measurement | La capacité à mesurer et piloter par la donnée |
| S | Sharing | Le partage de connaissances et de responsabilités |
Une approche équilibrée
L’intérêt du modèle est qu’il met en évidence une réalité :
On ne “fait pas” du DevOps simplement en automatisant.
Si la culture n’évolue pas, si l’organisation reste en silos, si les pratiques restent opaques, l’impact restera limité.
CALMS permet donc de construire un DevOps “holistique”, qui associe les bons outils aux bonnes pratiques dans un contexte humain et organisationnel sain. """
Culture
Définition : Climat de confiance, droit à l’erreur, collaboration forte
Exemples :
- Post-mortems sans blâme
- Pair programming
- Inclusion des Ops en amont
Symptômes négatifs :
- Culture du blâme
- Hiérarchie verrouillée
- "Héros" centralisateurs
Questions à poser :
- Peut-on échouer sans être blâmé ?
- Qui participe aux décisions de mise en prod ?
Automation
Définition : Automatiser les tâches répétitives et critiques
Exemples :
- CI/CD
- Tests automatisés
- Provisioning (Ansible, Terraform)
Symptômes négatifs :
- Déploiement manuel
- Scripts locaux
- Aucun test automatique
Questions à poser :
- Peut-on livrer sans intervention manuelle ?
- Peut-on reconstruire un environnement de test facilement ?
Lean
Définition : Optimiser le flux, limiter le gaspillage
Exemples :
- Value Stream Mapping
- Limitation du WIP
- Réduction des réunions inutiles
Symptômes négatifs :
- Attentes longues entre les étapes
- Travail en parallèle non terminé
- Validation en cascade
Questions à poser :
- Quelle est la durée moyenne entre commit et prod ?
- Où est le goulot d’étranglement ?
Measurement
Définition : Collecter, suivre, analyser des données
Exemples :
- Métriques DORA
- Logs, dashboards
- Monitoring automatisé
Symptômes négatifs :
- Pas de mesure de performance
- Logs incomplets
- Absence de tableau de bord partagé
Questions à poser :
- Connaît-on le lead time moyen ?
- Dispose-t-on d’alertes pertinentes ?
Sharing
Définition : Partager la connaissance, les outils, les échecs
Exemples :
- Wiki collaboratif
- Revues de code ouvertes
- Retours d’expérience (REX) réguliers
Symptômes négatifs :
- Connaissance concentrée
- Documentation obsolète
- Peu d’interactions transverses
Questions à poser :
- Un nouveau peut-il être onboardé sans "expert local" ?
- Peut-on accéder aux bonnes pratiques en autonomie ?
Les 3 voies de Gene Kim
Les trois voies forment le socle philosophique du DevOps, tel que défini par Gene Kim dans The Phoenix Project et The DevOps Handbook.
Elles décrivent le flux de travail, les boucles de feedback et les conditions de l’apprentissage organisationnel. Toutes les pratiques DevOps (CI/CD, monitoring, IaC, etc.) en sont des déclinaisons.
Le flux
Objectif
Accélérer le passage des changements (code, infrastructure, configuration) du développement vers la production, sans créer de dette opérationnelle ni augmenter le risque.
Concepts clés
- Travail en petits lots
- Réduction des files d’attente
- Automatisation des étapes manuelles
- Visualisation et maîtrise du pipeline
- Priorité à la vitesse de livraison contrôlée
Signes d’un mauvais flux
- Merge massifs en fin de sprint
- Goulots d’étranglement entre équipes
- Trop peu de déploiements
- Dépendances non maîtrisées
Pratiques associées
- Intégration et livraison continues (CI/CD)
- Feature toggles pour déployer sans activer
- Automatisation des tests et déploiements
- Infrastructure as Code (Terraform, Ansible...)
Exemples concrets
- Une organisation remplace sa revue mensuelle des versions par un pipeline GitLab CI : chaque commit déployé automatiquement en staging et prod après validation.
- Les tests d’intégration, les builds et le packaging sont exécutés en moins de 10 minutes à chaque push.
Le feedback
Objectif
Créer des boucles de rétroaction rapides, afin de détecter les problèmes le plus tôt possible dans le cycle de vie, et de permettre des ajustements immédiats.
Concepts clés
- Principe de “shift left” : détecter en amont
- Feedback permanent, de l’utilisateur au code
- Visibilité sur les systèmes
- Prise de décision rapide et collective
Signes de feedback insuffisant
- Bugs découverts en production
- Aucune alerte lors des incidents
- Retours utilisateurs ignorés ou très tardifs
- Absence de supervision applicative
Pratiques associées
- Tests automatisés dès le commit (unitaires, intégration, end-to-end)
- Monitoring et visualisation (Grafana, Prometheus)
- Alerting structuré, couplé à des dashboards
- Revue de code collaborative et continue
Exemples concrets
- Mise en place d’un dashboard Prometheus pour surveiller la latence d’une API. Une régression est repérée dans la minute, rollback enclenché sans impact utilisateur.
- Slack intégré à la CI : chaque build cassé notifie l’équipe en temps réel, permettant une réaction dans l’heure.
L’apprentissage continu
Objectif
Ancrer une culture de l’expérimentation, du partage et de l’amélioration continue, afin de bâtir des systèmes résilients et des équipes responsables.
Concepts clés
- Tolérance à l’échec, culture sans blâme
- Apprentissage post-incident
- Partage de la connaissance
- Capitalisation des bonnes pratiques
- Innovation incrémentale
Symptômes d’absence d’apprentissage
- Les incidents se répètent
- Aucun post-mortem n’est produit
- Les juniors dépendent d’experts "historiques"
- Les pratiques sont orales, non documentées
Pratiques associées
- Post-mortems documentés et diffusés
- Revues de code régulières et constructives
- Documentation vivante dans les dépôts ou wikis
- Journées d’innovation (hackdays, refacto days)
Exemples concrets
- Un incident majeur donne lieu à une restitution interne ouverte à tous les pôles techniques, avec une fiche de recommandations exploitables.
- Mise en place d’un “Jeudi Tech” toutes les 2 semaines où chacun peut partager un apprentissage ou une nouvelle pratique.
Résumé transversal
| Voie | Objectif principal | Focalisation sur... | Outils & leviers |
|---|---|---|---|
| Flux | Aller vite vers la production | Vitesse, automatisation, pipeline | CI/CD, IaC, versioning |
| Feedback | Réagir vite aux anomalies et améliorations | Visibilité, réaction rapide, correction | Monitoring, tests, observabilité |
| Apprentissage continu | S’améliorer en continu et collectivement | Culture, transparence, transmission | Post-mortems, documentation, REX |
Les métriques DORA
Lead Time for Changes (LT)
Définition : Temps entre un commit et sa mise en production.
Pourquoi :
- Réactivité
- Flexibilité
- Adaptation rapide aux besoins
Exemple :
- Commit lundi → déploiement jeudi → LT = 3 jours
Deployment Frequency (DF)
Définition : Fréquence de mise en production
Pourquoi :
- Valeur continue
- Petits lots = moins de risques
Exemple :
- 3 déploiements/jour → haut niveau
- 1 déploiement/mois → faible niveau
Change Failure Rate (CFR)
Définition : Taux de déploiements causant un incident
Pourquoi :
- Qualité des livraisons
- Corrélée à la maturité CI/CD
Exemple :
- 3 incidents sur 10 déploiements → CFR = 30%
Mean Time to Restore (MTTR)
Définition : Temps moyen pour restaurer après un incident
Pourquoi :
- Résilience opérationnelle
- Capacité à diagnostiquer et corriger vite
Exemple :
- Incident à 9h, résolu à 10h30 → MTTR = 1h30
📊 Tableau récapitulatif
| Métrique | Ce qu’elle mesure | Cible (équipes élites) |
|---|---|---|
| Lead Time (LT) | Rapidité de livraison | Moins d’1 jour |
| Deployment Frequency | Fréquence de livraison | Plusieurs / jour |
| Change Failure Rate | Taux d’échec des déploiements | Moins de 15% |
| MTTR | Temps de restauration | Moins d’1 heure |
Pourquoi ces métriques ?
- 🔍 Mesurables et comparables
- 📈 Actionnables
- 💡 Indépendantes de la stack technique
Les métriques DORA
| 📊 Métrique | Objectif |
|---|---|
| Lead Time for Changes | Rapidité d’intégration |
| Deployment Frequency | Fréquence de livraison |
| Mean Time to Restore | Temps de rétablissement |
| Change Failure Rate | Qualité des changements |
Explication :
- Ces 3.métriques sont issues des recherches DORA (DevOps Research & Assessment)
- Elles permettent de mesurer l'efficacité et la résilience d’une organisation DevOps