DevOps

 DevOps
Fondations et Principes
Apprendre DevOps à partir de situations concrètes : des problèmes d'entreprise aux pratiques qui changent la donne.
DevOps, pour vous, c'est quoi ? 🤔
💡 Prenez 5 minutes
Envoyez-moi sur Teams: vos mots-clés, concepts, outils qui vous viennent
Objectif : Faire émerger vos représentations mentales
💬 Ce que vous avez dit...
Outils
Docker
Kubernetes
Jenkins
GitLab CI
Ansible
Terraform
Pratiques
CI/CD
Automatisation
Infrastructure as Code
Monitoring
Culture
Collaboration
Dev+Ops
Agilité
Communication
DevOps est bien plus qu'une collection d'outils ou de pratiques isolées. C'est une transformation de la manière dont nous produisons de la valeur (logicielle).
❓ Pourquoi DevOps existe ?
DevOps n'est pas né d'une mode technologique
C'est une réponse à un problème rencontré en entreprise avec la place de plus en plus grande qu'a pris l'informatique dans les processus métier sur les dernières décennies.
📊 Stat : En 2013, 70% des projets IT échouent ou dépassent budget/délais (Standish Group Chaos Report)
Case Study: 🏢 Parts Unlimited
nous sommes en 2014
L'entreprise
Secteur: Pièces automobiles (Manufacturing + Retail)
💰 CA: 4 milliards $ / an
👥 4000 employés
💻 IT: 150 personnes
La crise
La concurrence écrase Parts Unlimited
La concurrence sort des fonctionnalités innovantes chaque mois
Parts Unlimited: enlisé dans sa "boule de boue"
Projet Phoenix:
Modernisation complète du SI/ERP
Censé sauver l'entreprise
Budget explosé, deadline dépassée
🚨 3 ans de retard
Diagnostic du Board:
⏰ Dans 6 mois: faillite
🎯 Dernière chance: livrer Phoenix avant cette date
👥 Organigramme IT & Business
Organigrammes et documents d'entreprise
🎯 Notre promotion en tant que VP of IT
📧 Email de Steve (CEO)
Hello,
Nous avons viré tes 2 boss. Je te nomme VP IT Operations.
Ta mission: Mener à bien le projet Phoenix. C'est notre priorité absolue.
Si on échoue, dans 6 mois c'est la faillite.
J'ai besoin de quelqu'un de confiance pour faire les bonnes choses au bon moment.
— Steve
✅ Notre Objectif
Rendre les systèmes IT fiables et disponibles
Permettre à l'entreprise de se concentrer sur le projet Phoenix
Réduire les perturbations au strict minimum
Sortir du mode pompier permanent dans lequel est Parts Unlimited
🚨 Case Study #1: La Panne du système de paie
⏰ Jour de notre promotion (mardi matin) :
💥 Mardi matin 8h27 - Email du CFO
URGENT: Système de paie crashé.
526 employés ne pourront pas être payés.
Les syndicats vont nous clouer au pilori
Réunion dans 30 minutes. - Le CFO (Dick)
Le paradoxe:
🎯 Priorité #1: Phoenix
🔥 Réalité: Éteindre le feu du système de paie
Que faire ? Par quoi commencer ?
Planifier & Audit
Planifier
Il faut résoudre le problème avant 17h - sinon l'entreprise n'aura pas le temps de rémunérer tous les employés
Sinon plan B (solution palliative):
L'entreprise se basera sur les heures travaillées du mois précédent pour payer les travailleurs horaires
Audit: se construire une vue d'ensemble
"Aller voir les logs à l'échelle de l'entreprise"
Interview avec les protagonistes pour reconstituer les évènements
⏰ Timeline des événements (vue des Ops)
⏰ Timeline des événements (Lundi-Mardi)
1
Lundi soir 19h 🔧
L'admin système senior (Brent) lance la mise à jour firmware du SAN (Storage Area Network) après que tout le monde soit parti
L'upgrade prend beaucoup plus de temps que prévu
2
Lundi soir ~19h15 💥
PANNE: Le payroll run (traitement de paie) échoue
Emails d'alerte commencent à arriver pendant que l'admin système travaille encore sur le SAN
3
Lundi soir ~19h30 💀
L'admin système suspecte que l'upgrade SAN a corrompu les données
Tentative de rollback du SAN
Le rollback bloque le SAN → Crash complet, les serveurs de données tombent
4
Mardi matin (2 septembre) 😰
Notre premier jour comme VP IT Operations
Toutes les heures travaillées pour les employés horaires sont perdues
Escalade massive au CFO (la paie doit être traitée aujourd'hui)
Investigations 
Mardi matin/midi 🔍
Enquête avec les responsables Ops (Wes - Directeur IT, Patty - Resp. Changements, Brent - Tech Lead Ops)
Entretien avec les métiers : la service comptabilité nous remonte que les heures travaillées dans leur logiciel de paie contiennent des caractères spéciaux. Uniquement cette colonne-là.
→ Piste #1 : la mise à jour du SAN a corrompu les données de la BDD (c'est la piste privilégiée par Brent, en charge de la migration du SAN)
On demande ensuite la liste des changements sur le système de paie à La responsable des changements (Patty)
→ La responsable des changements est incapable de donner la liste des changements effectués sur le système de paie: personne n'utilise son processus.
Elle effectue donc une série d'entretiens avec les équipes techniques pour lister les modifications récentes sur le système de paie :
→ 37 changements non-tracés découverts rien que la semaine précédent l'incident, qui peuvent impacter le système de paie
Brouillard total sur ce qui a été fait, il va falloir scruter à la loupe les 37 changements
💡 Le Flash de Brent
"Vendredi soir, un dev' de l'équipe du CISO (Chief Information Security Officer) m'a posé une question bizarre sur une structure de table pour l'app timekeeping - je l'ai rembaré parce que je lançais la migration du SAN, mais c'était une histoire d'encodage"
L'événement manquant
1
Vendredi précédent - 18h 🔐
Le CISO (John) déploie la tokenisation des données personnelles en production pour pallier à une reco d'un Audit de sécurité
Déploiement de l'update sur le logiciel de timesheet (gestion de feuilles de temps) en production
"Vite fait bien fait, Ça n'a pris que 30 minutes, aucun problème"
Personne n'a prévenu les Ops, qui étaient trop occupés par la migration
2
Mardi midi 💡
Suite au flash de l'admin système : Investigation auprès du développeur
Découverte du coupable : la tokenisation a chiffré les colonnes de l'application de timesheet utilisées également par le logiciel de paie
Le logiciel de paie ne peut plus lire les heures travaillées et retourne des caractères spéciaux
⚖️ Résolution de la Crise
Mardi 14h ⚖️
→ Nous annonçons au CFO (Dick) : Plan B obligatoire (deadline 17h manquée)
→ Utiliser les données du mois précédent (imprécis mais mieux que rien)
Mardi 19h 🔧
→ Application timekeeping restaurée sans l'encodage
Mardi 23h ✅
→ Le SAN est restauré à partir de backup
Mardi minuit+ 🏠
→ Nous rentrons chez nous après minuit
⏱️ 28 heures de crise (Lundi soir → Mardi 23h) causées par 30 min de déploiement non tracé le vendredi
🔍 Analyse Post-Mortem
Question au CISO (John):
Pourquoi avez-vous eu besoin de déstabiliser la prod' un vendredi soir ?
Nous devions traiter des problèmes RGPD depuis des mois. Mais comme personne ne priorise mes demandes sur la sécurité, elles n'ont jamais été traitées. Nous avons le cabinet d'audit qui vient nous contrôler la semaine prochaine. Si nous ne corrigions pas les points remontés, nous nous exposions à de grosses sanctions financières doublé d'une très mauvaise pub
Vous aviez testé avant de déployer en production ?
Tester où ? On n'a pas d'environnement de test.
Nous demandons aux Ops: "Pourquoi pas d'environnement de test ?"
Wes (Directeur Ops): Jamais eu le budget pour le mettre en place.
Demandé 3 fois ces 2 dernières années
Refusé à chaque fois (priorités business)
🔍 Analyse Post-Mortem
3. Et pourquoi ne pas avoir tracké ce changement quelque part ?
Le CISO (John) :
Avec le système de gestion des changements de Patty ? 40 minutes pour déclarer un changement
Formulaires interminables
"Trop lourd pour un fix de 30 min"
La responsable des changements (Patty):
"Le processus existe, mais personne ne l'utilise..."
Conçu pour les gros projets
Inadapté aux petits changements
"Pas incroyable comme performance pour notre premier jour en tant que VP of IT Operations."
🎯Les causes du Fiasco
Exercice: Identifiez 3 problèmes et axes d'améliorations du département IT (organisation ou techniques) que révèle cet épisode
🚨 Case Study #1 : Les problèmes
Problème #1 : Brouillard total
Symptôme observable:
Impossible de corréler panne ↔ changement
Causes racines:
❌ Pas de change management
❌ Communication par email
❌ "Ticketing trop complexe"
❌ 37 changements non documentés
❌ Déploiements non coordonnés
Conséquence:
→ Contournement systématique
→ Diagnostic erroné (SAN au lieu de tokenisation)
→ 2 jours perdus à chercher
→ Rollback du mauvais système
Problème #2: Déploiement cow-boy
Symptôme observable:
Changement vendredi 18h → panne lundi soir 19h15
Causes racines:
❌ Pas d'environnement de test
❌ Déploiement direct en prod
❌ "Ça devait prendre 30 min"
❌ Aucune analyse d'impact
❌ Personne n'est prévenu (silos)
Conséquence:
→ Impact imprévu sur système critique
→ Aucun plan de rollback testé
→ 5 serveurs crashés en tentant de réparer
Problème #3: Silos
Symptôme observable:
Brent rollback le mauvais système (il n'avait pas l'info)
Causes racines:
❌ Sec déploie sans prévenir Ops
❌ Chaque équipe dans son silo
❌ "Throwing over the wall"
❌ Pas d'ownership end-to-end
❌ L'info ne circule pas naturellement
Conséquence:
→ Diagnostic à l'aveugle
→ Mauvaise décision (rollback SAN au lieu de tokenisation)
→ 200 serveurs crashés
→ 28h de crise pour un problème de 30 min
Le Cercle Vicieux
Pas de visibilité → Déploiement cow-boy → Panne → Silos (personne n'a l'info) → Diagnostic à l'aveugle → Mauvaise décision → Aggravation → Encore moins de confiance...
🔧 Comment résoudre ces problèmes ?
🌫️
Brouillard total
↓
#1 Visibilité
🎲
Déploiement cow-boy
↓
#2 Build Quality In
🧱
Silos / Pas d'ownership
↓
#3 You build it, you run it
🌫️ Le travail invisible crée le chaos
Le problème:
Dans une usine : on VOIT les pièces circuler
En IT : le travail est invisible
Circule par email, Teams, mémoire des gens
Impossible de savoir ce qui est en cours
Impossible de corréler panne ↔ changement
Chez Parts Unlimited:
"37 changements cette semaine sur le système de paie. Personne ne sait lesquels."
Résultat : 28h à chercher le coupable
Conséquences:
❌ On ne peut pas gérer ce qu'on ne voit pas
❌ Diagnostic à l'aveugle
❌ Priorisation impossible
❌ Décisions basées sur des suppositions
"Si vous ne pouvez pas le voir, vous ne pouvez pas le gérer"
👁️ Rendre le travail visible : Kanban
Le principe
Une carte = Un changement
Tout le monde voit :
Ce qui est en cours (WIP)
Ce qui est bloqué
Qui fait quoi
Application au Use Case
Si la tokenisation de John était sur le board :
✅ Brent l'aurait vue
✅ Corrélation immédiate : "encodage" pas "SAN"
✅ Pas de rollback destructeur
📋 Exemple de Board
Règles simples :
Si ce n'est pas sur le board → ça n'existe pas
WIP limit (ex: max 3 en "Doing")
Code couleur par urgence/type
Résultat : Corrélation panne ↔ changement en minutes, pas en jours
✅ Build Quality In (Shift-Left)
Le problème du Use Case:
John (CISO) : "On n'a pas d'environnement de test"
Résultat :
Test directement en production
Découverte du bug par les utilisateurs (paie cassée)
Coût de correction : 28 heures de crise
Contrôles PRÉVENTIFS > Contrôles RÉACTIFS
Shift-Left = Déplacer les vérifications vers la GAUCHE (plus tôt)
[Dev] → [Test] → [Staging] → [Prod]
←←←← Shift-Left ←←←←
Deming : "Cessez de dépendre de l'inspection pour atteindre la qualité. Construisez la qualité dans le produit dès le départ."
💸 La dette technique : les intérêts composés
Le raccourci de John:
Vendredi 18h :
"Pas le temps de tester, pas d'env de dev, ça devait prendre 30 minutes..."
Gain perçu : 30 min
Coût réel :
28h de crise
200 serveurs crashés
Paie de 526 employés retardée
Réputation IT détruite
L'effet "intérêts composés"
Comme une dette financière :
Chaque raccourci non remboursé génère du travail non planifié
Phoenix Project : "La dette technique se matérialise sous forme de travail non planifié, qui désorganise et ne prévient pas."
🔑 Ownership : "You build it, you run it"
Le problème du logiciel de paie:
Vendredi 18h :
John (Sec) déploie la tokenisation
Brent (Ops) n'est pas prévenu
Lundi soir :
Brent voit une panne, diagnostique avec son champ de vision
Suspecte le SAN (sa seule variable connue)
Rollback destructeur → 200 serveurs down
Cause racine : Personne n'est responsable end-to-end
Le principe DevOps:
"You build it, you run it"
— Werner Vogels (Amazon)
L'équipe qui construit :
✅ Déploie
✅ Monitore
✅ Gère les incidents
✅ Est d'astreinte
Effet :
L'info circule naturellement
Plus de "throwing over the wall"
Incentives alignés
Si John devait gérer l'incident de sa tokenisation à 3h du matin, il aurait testé avant.
✅ Use Case #1: Les Principes DevOps
Principe #1: Rendre le travail visible
Résout: Mécanisme #1 (Brouillard)
Pratiques concrètes:
✅ Change Management
Kanban Board des changements
Ticketing obligatoire (une carte = un changement)
Change Advisory Board (CAB)
Code couleur (critique/standard/urgent)
✅ Visibilité des dépendances
Cartographie des impacts
Communication proactive
Timeline des changements
Résultat mesuré:
→ Corrélation panne ↔ changement en minutes
→ Diagnostic précis immédiatement
→ Plus de rollback du mauvais système
Principe #2: Build Quality In (Shift-Left)
Résout: Mécanisme #2 (Cow-boy)
Pratiques concrètes:
✅ Environnements de test
Dev → Staging → Prod
Tests automatisés obligatoires
Validation avant déploiement
✅ Analyse d'impact
Revue des dépendances
"Qui sera impacté par ce changement?"
Coordination multi-équipes
✅ Rollback safe
Infrastructure as Code
Déploiement reproductible
Rollback testé régulièrement
Résultat mesuré:
→ Détection problèmes avant la prod
→ Rollback en confiance (pas d'empirage)
→ Change Failure Rate: 60% → 15%
Principe #3: Ownership end-to-end
Résout: Mécanisme #3 (Silos / Pas d'ownership)
Pratiques concrètes:
✅ "You build it, you run it"
L'équipe qui construit est responsable du run
Déploiement, monitoring, incidents, astreinte
Plus de "throwing over the wall"
✅ Équipes cross-fonctionnelles
Dev + Ops + Sec dans la même équipe
L'info circule naturellement
Pas besoin de "penser à prévenir"
✅ Incentives alignés
Si tu gères les incidents, tu codes mieux
Responsabilité partagée = collaboration naturelle
Objectifs communs (pas Dev vs Ops)
Résultat mesuré:
→ Incidents mieux anticipés (ownership)
→ Temps de diagnostic: 28h → minutes
→ Communication inter-équipes: naturelle
→ Plus de rollback du mauvais système
🔑 Takeaway
Les principes DevOps transforment le chaos invisible en système maîtrisé et prévisible
Visibilité + Qualité dès le début + Ownership end-to-end = Sortie du mode réactif ("pompiers")
Case Study #2: Guerre Tribale Dev vs Ops
Réunion d'état des lieux avec le Board concernant le projet Phoenix
Chris (Responsable Dev) annonce:
"Si l'IT nous fournit les environnements virtualisés pour nos tests... on livre vendredi."
sans consulter Wes (Director Ops)
Le Clash : Dev vs Ops
14h20 😤 Bill (Ops) explose : "Tu jettes une patate chaude par-dessus le mur!"
Sarah (VP Retail) rétorque : "On est date-driven, faut livrer, satisfaire les actionnaires"
14h30 ⚖️ Steve (CEO) tranche sans appel : "Date maintenue — 9 jours"
Ops et Dev doivent "se débrouiller"
🎯 Dev : "On a fini!" 
Ops : "On ne peut même pas commencer"
Dysfonctionnements
Les Mécanismes qui Cassent Tout
🏢 Silos organisationnels
Dev et Ops travaillent en isolation totale
Communication uniquement en mode crise
Ops invités 1 jour avant les réunions
Brent (seul pont) toujours coincé en prod
⚡ Objectifs contradictoires
Dev dit "fini", Ops dit "impossible"
Dev mesuré sur : vitesse de livraison
Ops mesuré sur : stabilité système
Résultat : guerre permanente
🧱 Handoff chaotique
"Patate chaude par-dessus le mur"
Dev "jette le code" à Ops
Planning sans temps Ops
Tests et déploiement non budgétés
💀 Le Cercle Vicieux : Silos → Objectifs opposés → Handoff tardif → Projet raté → Blame game → Silos renforcés...
Solution #1
🎯 Objectifs Partagés : Les Métriques DORA
Le problème
Chez Parts Unlimited :
Dev mesuré sur : features livrées
Ops mesuré sur : stabilité, uptime
Résultat : Chacun optimise SON métrique → Conflit structurel
La solution DevOps
4 métriques DORA — tout le monde responsable :
Deployment Frequency — Combien de fois on livre
Lead Time — Temps commit → prod
MTTR — Temps de restauration
Change Failure Rate — % déploiements qui cassent
Effet : Dev ET Ops partagent les mêmes objectifs → Plus de "c'est pas mon problème"
Solution #2
✅ "Done" = En Production
Chez Parts Unlimited
Chris (Dev) : "On a fini ! Le code est prêt."
Wes (Ops) : "Impossible à déployer. Pas de specs infra, pas d'env de test."
2 definitions of done = conflit garanti
La Definition of Done unique
"Done" signifie :
Code écrit et reviewé
Tests passent (unit, integration)
Infrastructure définie (IaC)
Déployable en staging
Monitoring configuré
Documentation à jour
Pas "Done" si pas déployable
"Done means released. You can't call something done until it's delivering value to users in production."
⬅️ Shift-Left : Ops Dès le Design
Chez Parts Unlimited
Timeline projet Phoenix :
Mois 1-5 : Dev code les features
Mois 6 : "Au fait, on a besoin de serveurs"
Ops : "3 semaines minimum"
Ops découvre les besoins à la fin → Aucune marge → Raccourcis forcés
La solution DevOps
Shift-Left = Impliquer Ops dès le début
Architecture reviews avec Ops
NFRs (perf, sécu, scalabilité) dès le design
Infrastructure as Code dans le repo
Environnements créés en même temps que le code
Résultat : Provisionning 3 semaines → 5 min
Principes DevOps
Use Case #2 : Les Principes en Action
01
Collaboration Dev+Ops
Résout : Mécanisme #1 (Silos)
Équipes cross-fonctionnelles
Communication continue
Shared on-call : "You build it, you run it"
Résultat : Lead Time 14 jours → 2 jours
02
Objectifs partagés
Résout : Mécanisme #2 (Objectifs opposés)
Métriques DORA communes à tous
Definition of Done unique
Incentives alignés sur métriques équipe
Résultat : Deployment Frequency 1×/trimestre → 10×/jour
03
Shift-Left Operations
Résout : Mécanisme #3 (Handoff tardif)
Ops dès la conception
Environnements automatisés (IaC)
Intégration continue avec feedback immédiat
Résultat : Délai provisionning 3 semaines → 5 min
🔑 Takeaway : DevOps = Supprimer le mur entre Dev et Ops, créer une équipe unique avec objectifs partagés
Use Case #3
🦸 Le Syndrome du Héros : Brent
60%
Projets IT
en attente de Brent
42
Emails/jour
adressés à Brent
15
Interruptions
par jour pour incidents
Le paradoxe
🎯 Brent devrait être sur Phoenix (priorité #1)
🔥 Réalité : Brent éteint des feux toute la journée
Le problème systémique
Seul à maîtriser les systèmes critiques
Aucune documentation
Personne ne peut le remplacer
🦸 1 personne = Goulot d'étranglement de toute l'IT
⏰ Une Journée Typique de Brent
8h00 — 42 emails urgents
6 executives ont escaladé : "J'ai besoin de Brent!"
8h15 — Problème prod Phoenix
Tel sonne → Sort de sa réunion planning
9h00 — 2ème incident (network down)
Seul à pouvoir le résoudre
10h00 — Sarah escalade
"Brent DOIT livrer env test vendredi" → Brent dit oui (comme toujours)
10h30 — 3ème incident (BDD corruption)
15 projets en attente de Brent
12h00 — Mange à son bureau
Continue de coder pendant le déjeuner
14h00 — Réunion d'archi Phoenix
Interrompu 3× pendant la réunion
16h00 — Bilan de journée
0 projet avancé, que du pompier. Aucune doc.
18h00 — 60% projets bloqués
Toujours en attente de Brent
20h00 — Rentre épuisé
Tel continue de sonner...
Mécanismes Destructeurs
Les Racines du Problème Brent
🧠 Knowledge Silo (SPOF humain)
Si Brent part en vacances → panique totale
Savoir concentré dans une seule tête
Aucune documentation écrite
Un humain ne peut pas être une stratégie
Impossible de scaler (on ne clone pas Brent)
Conséquence : Connaissance perdue à chaque action. Personne ne peut reproduire son travail.
❄️ Serveurs Snowflake
"Ça marche sur le serveur de Brent, mais pas ailleurs"
Chaque serveur configuré manuellement
Pas d'Infrastructure as Code
Configurations ad-hoc, non versionnées
"Serveurs pets, pas cattle"
Conséquence : Dev ≠ Staging ≠ Prod. Provisionning serveur : 3 semaines
🔄 Cercle vicieux de l'expertise
Plus on sollicite Brent, plus il devient expert
Chaque intervention → Brent +1% expert
Plus expert → Plus sollicité
Plus sollicité → Moins de temps pour automatiser
Culture du "héros" glorifiée
Conséquence : Reste de l'équipe de moins en moins autonome. Impossible de sortir du cercle
Solution #3
🔧 Infrastructure as Code
La config dans Git, pas dans la tête
Chez Parts Unlimited
Brent configure manuellement :
Installations ad-hoc
Configs "à la main"
Aucune trace écrite
Résultat : Serveurs "Snowflake"
Chaque serveur unique
Impossible de reproduire
Provisionning : 3 semaines
La solution DevOps
"Cattle, not Pets"
IaC = Terraform, Ansible, Pulumi
Config = code versionné (Git)
Reproductible à 100%
Self-service : plus besoin de Brent
🚌 Bus Factor > 1
Personne n'est indispensable
Le "Bus Factor"
Définition : Nombre de personnes qui peuvent se faire renverser par un bus avant que le projet soit paralysé.
Chez Parts Unlimited :
Bus Factor = 1 (Brent)
60% des projets bloqués
Si Brent en vacances → panique
La solution DevOps
Distribuer la connaissance :
✅ Pair programming / Mob programming — Jamais seul sur du code critique
✅ Code reviews obligatoires — 2+ personnes connaissent chaque changement
✅ Documentation vivante — Runbooks, ADRs, README à jour
Objectif : Bus Factor ≥ 3
"Chaque incident résolu par Brent le rend un peu plus intelligent, mais rend le reste du système plus bête et dépendant."
Solution #4
🛡️ Protéger la Contrainte
Brent doit améliorer, pas exécuter
1
Theory of Constraints (TOC)
Brent = Goulot d'étranglement — Toute l'IT dépend de lui. 15 interruptions/jour, 0 temps pour améliorer.
2
Le cercle vicieux
Brent sollicité → Résout manuellement → Devient + indispensable → + sollicité → Retour à 1.
3
Protéger Brent pour qu'il améliore
WIP Limit sur Brent — Max 2 sujets parallèles
Level 3 Support — Brent ne résout pas 2× le même problème
20% temps amélioration — IaC, documentation, formation
4
Résultat
Interruptions : 15/jour → 2/jour | Projets bloqués : 60% → 10%
"Améliorer le travail quotidien est encore plus important que de l'effectuer."
Use Case #4
📅 Projet Phoenix Date-Driven
Le désastre du lancement
Vendredi soir — Jour J du lancement
Prévu (4PM) : Site Phoenix en ligne, magasins opérationnels, paiements fonctionnels
Samedi matin — Catastrophe
✅ Site en ligne... mais inutilisable (trop lent)
💀 Caisses magasins HS → Encaissement manuel sur papier
💳 Paiements CB : débits multiples ou perdus
Dimanche — Fuite de données
🔒 Fuite de données CB (panier affiche CB des autres clients) — Avocats + CISO convoqués d'urgence
Lundi — Steve rouge de colère
😡 "Pays du tiers monde avec papier-crayon!"
🔄 Reboot frontend toutes les heures (memory leaks)
📊 Réputation en miettes, clients perdus
⏰ Timeline : Les 6 Mois du Projet
1
Mois -6 (Janvier)
📅 Annonce publique Wall Street : "Livraison juillet" — Marketing lance campagnes — Date NON NÉGOCIABLE
Planning initial : 5 mois dev + 2 semaines tests + 1 semaine deploy
2
Mois -5 à -1
💻 Dev utilise les 6 mois complets (au lieu de 5) — Features ajoutées en cours — "On verra les tests plus tard"
3
Semaine -2
😰 QA : 0 jour de tests restant — Ops : Aucune spec d'infra — Date inchangée
4
Semaine -1
🔥 "Livrer quand même" — Tests zappés, déploiement improvisé
5
Vendredi 16h — Deadline
⏰ Dev fait encore des fixes à 7:30PM — "Ça marche sur ma machine"
6
Vendredi 23h
🚀 Déploiement nocturne mode pompier — Conversion BDD : 1000× trop lente
7
Samedi-Dimanche
💥 Catastrophe opérationnelle — Fuite CB, magasins paralysés
📅 Date respectée, qualité sacrifiée, réputation détruite
Mécanismes Dysfonctionnels
Phoenix : Pourquoi Ça a Cassé ?
📆 Date-driven vs Quality-driven
Symptôme : La date est sacrée, la qualité est sacrifiée
Engagement Wall Street non négociable
Marketing lance pubs AVANT que l'IT soit prête
"On verra les bugs après le lancement"
Pression business > raison technique
Conséquence : Livraison coûte que coûte → Tests zappés → Dette technique exponentielle
⚖️ Tests & Ops = Variables d'ajustement
Symptôme : Dev planifié 5 mois, Tests 2 semaines (4% du temps!)
Dev consomme TOUT le temps
Tests "on trouvera bien un moment"
QA et Ops invoqués la veille
Definition of Done = "code écrit" (pas "en prod")
Conséquence : QA n'a pas le temps de tester → Déploiements samedi 3h du matin
💸 Dette technique exponentielle
Symptôme : Code non testé en prod, memory leaks, fuite CB
Raccourcis pris sous pression
Pas de tests, docs, monitoring
NFR jamais développés
"On corrigera après la release"
Conséquence : Système fragile → Reboot toutes les heures → Dette = travail futur obligatoire
Comment Résoudre Ces Dysfonctionnements ?
3 mécanismes identifiés → 3 axes de solution
📆 Date-driven
↓
Build Quality In
⚖️ Tests sacrifiés
↓
Deployment Pipeline
💸 Dette technique
↓
Observability + Kaizen
Solution #5
✅ Build Quality In
Construire la qualité dès le départ
Le problème Phoenix
Approche traditionnelle : "On développe d'abord, on testera après"
Résultat :
Tests = 4% du temps (2 sem / 6 mois)
Bugs découverts en production
Coût de correction : 100× plus cher
La révélation Deming
"Cessez de dépendre de l'inspection pour atteindre la qualité. Construisez la qualité dans le produit dès le départ."
❌ Inspection (après)
Tests manuels en fin
QA découvre les bugs
Coût correction élevé
Feedback en semaines
✅ Prévention (avant)
Tests auto à chaque commit
Dev écrit les tests
Coût correction minimal
Feedback en minutes
Pratiques clés : TDD (Test-Driven Development) • Code reviews obligatoires • Quality gates automatiques • "Done" = testé + déployable
Solution #6
🎚️ Feature Toggles
Découpler déploiement et activation
Le problème Phoenix
Lancement Big Bang :
Tout déployé d'un coup
0 test en conditions réelles
Si bug → catastrophe totale
Le principe
Déploiement ≠ Activation
Le code est en prod mais désactivé
On active progressivement (1% → 10% → 100%)
Si problème → toggle OFF instantané
01
Dev merge (toggle OFF)
02
Code déployé en prod
03
QA teste avec ?flag=newFeature
04
OK → Toggle ON pour 1% users
05
Métriques OK → 10% → 100%
06
Bug → Toggle OFF (1 sec)
Avantages : ✅ Rollback en 1 seconde • ✅ Test en prod avec vrais users • ✅ A/B testing natif • ✅ Merge continu sur main
🐤 Canary Releases
Déploiement progressif
Pourquoi "Canary" ?
Origine : Canaris dans les mines de charbon
Détectent le danger avant les humains
Si le canari meurt → évacuation
En DevOps :
1% des users = "canaris"
Détectent les bugs avant 100%
Si problème → rollback avant catastrophe
Stratégies de déploiement
Métriques surveillées
📈 Taux d'erreur (< 1%)
⏱️ Latency P99 (< 200ms)
💔 Taux de conversion
🔥 Alertes Prometheus
Si dégradation → Rollback auto
Solution #7
🔄 Le Deployment Pipeline
Du commit à la production
Every commit = release candidate
Build once, deploy everywhere
If any stage fails, stop the line
Commit stage < 10 minutes
Quality Gates automatiques : 🚫 Tests échouent → Bloqué • 🚫 Coverage < 80% → Bloqué • 🚫 Vulnérabilités critiques → Bloqué
🔺 La Pyramide des Tests
Structure optimale
E2E Tests (5-10%) — Lents, fragiles, coûteux
Integration Tests (20-30%) — Moyens, base de données
Unit Tests (60-70%) — Rapides, isolés, nombreux
⚠️ Règle d'or : Plus le test est haut dans la pyramide, plus il est lent et fragile
Exemple Phoenix corrigé
Avant : 0 unit, 0 integration, 5 tests manuels
Après : 500 unit, 50 integration, 20 E2E
Temps total : 3 min (vs 2 semaines manuel)
Coverage : 85%
Unit
~1ms | 1 fonction | 1000+
Integration
~100ms | Composants | 100+
E2E
~10s | Système entier | 10-50
⚙️ CI/CD Pipeline en Action
name: CI/CD Pipeline
on:
 push:
 branches: [main]
 pull_request:

jobs:
 build-and-test:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 
 - name:
Solution #8
⬅️ Shift-Left Testing
Les tests dès le développement
Le problème Phoenix
Cascade classique :
[Dev 5 mois] → [Test 2 sem] → [Deploy 1 sem]
↑ Découverte bugs : Coût max, temps min
Shift-Left = Décaler à gauche
[Dev + Test continu] → [Deploy continu]
↑ Découverte bugs : Coût min, temps max
Coût de correction d'un bug
01
🔴 RED — Écrire un test qui échoue
02
🟢 GREEN — Code minimal pour passer
03
🔄 REFACTOR — Améliorer sans casser
Bénéfices TDD : ✅ Design émerge des tests • ✅ Code testable par construction • ✅ Documentation vivante • ✅ Refactoring sans peur
Solution #9
📊 Les 3 Piliers de l'Observability
Pour détecter les memory leaks et fuites CB avant la prod
📝 Logs
Quoi : Événements textuels horodatés
Exemple :
2024-01-15 14:23:45 ERROR PaymentService: Card declined user=123
Outils : ELK Stack, Loki + Grafana, Seq
Usage : Debugging, Audit trail, Analyse post-incident
📈 Metrics
Quoi : Valeurs numériques agrégées
Exemple :
http_requests_total{status="500"} 42
memory_usage_bytes 1073741824
Outils : Prometheus + Grafana, Datadog, InfluxDB
Usage : Dashboards temps réel, Alertes (CPU > 90%), Tendances
🔗 Traces
Quoi : Parcours d'une requête
Exemple :
Request #abc123
├─ API Gateway (2ms)
├─ Auth Service (15ms)
├─ Payment (200ms) ← LENT
Outils : Jaeger, Zipkin, OpenTelemetry
Usage : Identifier goulots, Debugging distribué
Phoenix aurait détecté : Memory leak (metrics), Requêtes lentes (traces), Erreurs CB (logs) — avant la mise en prod
🚨 Monitoring Proactif
Alertes avant l'incident
Prometheus + Grafana
# prometheus.yml
scrape_configs:
  - job_name: 'phoenix-app'
    static_configs:
      - targets: ['app:8080']
    metrics_path: /metrics
# alert-rules.yml
groups:
  - name: phoenix
    rules:
      - alert: HighMemoryUsage
        expr: memory_usage_percent > 80
        for: 5m
        labels:
          severity: warning
        
      - alert: HighErrorRate
        expr: rate(http_errors_total[5m]) > 0.05
        for: 2m
        labels:
          severity: critical
Métriques essentielles
🚨 ALERT: HighMemoryUsage
Service: payment-service
Current: 85% (threshold: 80%)
Duration: 5 minutes
→ Action: Investigate memory leak
📏 SLO / SLI / SLA
Définir la fiabilité acceptable
📊 SLI — Service Level Indicator
Quoi : La métrique mesurée
Exemples :
Latency P99 : 250ms
Availability : 99.95%
Error rate : 0.1%
Throughput : 1000 req/s
Formule type :
SLI = (good events / total events) × 100
Ex: 9950 succès / 10000 requêtes = 99.5%
🎯 SLO — Service Level Objective
Quoi : L'objectif interne
Exemples :
Latency P99 < 300ms
Availability ≥ 99.9%
Error rate < 1%
Error Budget :
99.9% SLO = 0.1% error budget = 43 min downtime / mois
Usage : Si budget consommé → stop features, fix
📜 SLA — Service Level Agreement
Quoi : Le contrat client
Exemples :
Availability ≥ 99.5%
Support réponse < 4h
Compensation si non-respect
Relation :
SLO (interne) > SLA (externe)
Ex: SLO 99.9% → SLA 99.5%
Marge de sécurité
Conséquences si violé : Pénalités financières, Crédits clients
Phoenix n'avait aucun SLO défini → Impossible de savoir si le système était "assez bon" → Découverte en prod que non
Solution #10
🟢 20% Temps Amélioration
Les Green Cards
Le problème Phoenix
Répartition temps IT :
🔴 75% Unplanned Work (incidents)
🟡 15% Changes (déploiements)
🔵 8% Business Projects
🟢 2% Amélioration ← Quasi rien !
Conséquence : Dette technique s'accumule → Systèmes fragiles → Plus d'incidents → Cercle vicieux
La solution : Sanctuariser 20%
Green Cards = Projets d'amélioration IT
🟢 20% du temps réservé
🟢 Non négociable (comme les vacances)
🟢 Visible sur le Kanban
Automatiser déploiements
Lead time ÷10
Ajouter tests auto
Bugs prod -50%
Documenter runbooks
MTTR ÷5
Refactorer module legacy
Incidents -30%
Monitoring
Détection proactive
"Il importe peu de ce que vous améliorez, tant que vous améliorez quelque chose." — Mike Rother
Principes DevOps
Use Case #4 : Les Principes en Action
🎯 Principe #10 : Quality-First
Résout : Mécanisme #1 (Date vs Quality)
Pratiques : Definition of Done stricte • No trade-off vitesse/stabilité • Feature toggles
Résultat : Change Failure Rate 60% → 15% | Bugs prod -80%
🎯 Principe #11 : Continuous Testing
Résout : Mécanisme #2 (Tests sacrifiés)
Pratiques : Tests automatisés à tous niveaux • CI/CD Pipeline • Tests budgétés dès le début • TDD
Résultat : Test coverage 10% → 80% | Lead Time 6 mois → 1 heure
🎯 Principe #12 : Réduire dette technique
Résout : Mécanisme #3 (Dette exponentielle)
Pratiques : 20% temps amélioration • Monitoring & Observability (Prometheus, Grafana) • NFRs dès le design • Chaos Engineering
Résultat : Dette technique -70% | Incidents -80% | MTTR 3 jours → 1 heure
🔑 Takeaway : DevOps permet de livrer plus vite ET plus stable (pas de trade-off!) — "Les high performers excellent sur TOUTES les métriques DORA simultanément" — Accelerate
📋 Les 12 Principes DevOps
Résumé des 4 Use Cases
#1 Visibilité
Rendre le travail visible
#2 Quality-First
Build Quality In (Shift-Left)
#3 Blameless
Culture d'apprentissage
#4 Collaboration
Dev+Ops = DevOps
#5 Objectifs partagés
Métriques communes
#6 Shift-Left Ops
Ops dès la conception
#7 IaC
Infrastructure as Code
#8 Documentation
Knowledge Sharing
#9 Protéger contrainte
Limiter WIP, Kaizen
#10 Quality-First
Pas de trade-off vitesse/qualité
#11 Testing
Continuous Testing (Shift-Left)
#12 Dette tech
20% amélioration continue
Les 3 Ways du DevOps
Les 3 Voies de la Transformation
1
Flow — Le Flux
Visibilité, Shift-Left, IaC
Principes : #1, #2, #6, #7, #11
Rendre le travail visible (Kanban)
Limiter le WIP
Automatiser (IaC, CI/CD)
Shift-Left (Tests, Ops)
2
Feedback — Le Retour
Testing, Monitoring, Blameless
Principes : #3, #10, #11, #12
Tests automatisés à tous niveaux
Monitoring & Observability
Blameless postmortems
Feedback rapide (< 10 min)
3
Continuous Learning — L'Apprentissage
Documentation, Kaizen, Collaboration
Principes : #4, #5, #8, #9
Culture d'expérimentation
20% temps amélioration
Documentation & Knowledge Sharing
Collaboration Dev+Ops
Principe Fondateur
🔁 "If It Hurts, Do It More Often"
Principe fondateur du DevOps et de la Continuous Delivery
❌ Phoenix (début) : Le cercle vicieux
🔥 Déploiements = Douloureux
Fréquence : 1× par trimestre (tous les 3-4 mois)
Conséquence :
Gros batch de changements (300+ tickets)
Complexité exponentielle
Tests manuels interminables
Rollback impossible
Symptômes :
🌙 Déploiement le vendredi soir
😰 Toute l'équipe en alerte
📞 Astreintes obligatoires
🙏 "Pray and deploy"
Résultat : 60-80% de taux d'échec → Panique, blame game
✅ Phoenix (fin) : Le cercle vertueux
🚀 "If It Hurts, Do It More Often"
Fréquence : 10 déploiements/jour (déploiements continus)
Conséquence :
Petits changements incrémentaux (1-5 commits)
Complexité linéaire
Tests automatisés (< 30 min)
Rollback trivial (git revert)
Pratiques :
☀️ Déploiement n'importe quand (même 15h un mardi)
😌 Dev peut déployer seul (self-service)
🤖 Pipeline automatisé
🎯 Feature toggles
Résultat : 0-15% de taux d'échec → Zéro stress
🤔 Réaction Logique (mais Fausse)
"Les déploiements sont dangereux...
→ Déployons moins souvent !"
1
⏰ Déploiements encore plus rares
2
📦 Batches encore plus gros
3
💥 Échecs encore plus catastrophiques
4
🔄 Cercle vicieux infernal
💡 Révélation (contre-intuitive)
"Les déploiements sont dangereux...
→ Déployons plus souvent !"
🔁 Automatisation forcée
📉 Réduction du risque par changement
🧪 Feedback rapide
🔄 Cercle vertueux
🎯 Autres Exemples : Do It More Often
🔧 Provisionning serveurs
Avant :
Provisioning manuel (Brent)
🕐 3 semaines par serveur
Configuration divergente
"Pets, not cattle"
Après (IaC) :
Terraform + Ansible
⚡ 5 minutes par serveur
Configuration identique
"Cattle, not pets"
Principe : Provisionner 100× plus souvent → Force l'automatisation
🔀 Merges de branches
Avant :
Branches long-lived (6 mois)
🕐 2 semaines de merge hell
500+ conflits
"Integration nightmare"
Après (Trunk-Based Dev) :
Merge sur main plusieurs fois/jour
⚡ 0 conflit
Toujours déployable
Feature toggles
Principe : Merger 100× plus souvent → Force les petits commits
🧪 Tests de régression
Avant :
Tests manuels (QA team)
🕐 2-4 semaines de testing
Jamais exhaustifs
Erreurs humaines
Après (CI/CD) :
Tests automatisés (pipeline)
⚡ < 30 minutes à chaque commit
80%+ coverage
Toujours identiques
Principe : Tester 1000× plus souvent → Force l'automatisation
📊 Phoenix vs Unicorn
Le pouvoir de "Do It More Often"
🔥 Phoenix (Low Performers)
Stratégie : "C'est douloureux → Évitons-le"
Résultat : Encore plus douloureux
🦄 Unicorn (High Performers)
Stratégie : "C'est douloureux → Faisons-le plus souvent"
Résultat : Plus de douleur du tout
🎯 Takeaway : "If it hurts, do it more often, and bring the pain forward" — Jez Humble
Déployer 100×/jour est 100× moins risqué que déployer 1×/trimestre
Parce que chaque déploiement contient 300× moins de changements
La haute fréquence force l'automatisation, la simplicité, et la fiabilité.
✅ Synthèse : Ce Qui Ne Marche Pas
Cochez ce que vous avez déjà vu en entreprise 👇
🔧 Gestion des Changements & Déploiements
☐ Déploiements rares, stressants, hors horaires (nuit, week-end)
☐ Changements non tracés (tout par email, pas de ticketing)
☐ Déploiement direct en production sans validation ni tests
☐ Pas de plan de rollback (tentatives qui empirent la situation)
👥 Organisation & Silos
☐ Dev / Ops / Sec qui se renvoient la faute
☐ Communication tardive entre équipes
☐ "Patate chaude par-dessus le mur" (handoffs chaotiques)
☐ Sécurité perçue comme bloquante, jamais invitée aux réunions
🦸 Hero Syndrome & Knowledge Silos
☐ 1-2 experts indispensables qui détiennent la connaissance
☐ 60% des projets bloqués en attente de l'expert
☐ Escalades directes, expert sollicité 24/7
☐ Aucune documentation ("Il fait, mais ne sait pas comment")
📅 Planification & Priorisation
☐ Projets toujours "presque prêts" (jamais finis)
☐ Personne ne sait où en est le travail (flux invisible)
☐ Priorisation de l'urgence au détriment de l'important
☐ 105 projets / 150 personnes = multitasking destructeur
🔥 Unplanned Work (Mode Pompier)
☐ 75% du temps IT consumé par l'Unplanned Work
☐ Incidents imprévus qui bloquent tout
☐ Mode pompier permanent (impossibilité de planifier)
☐ Raccourcis sous pression → Dette technique accumulée
🏗️ Qualité & Dette Technique
☐ Tests directement en production
☐ Documentation inexistante ou obsolète
☐ Code qui "casse des trucs à chaque nouvelle version"
☐ NFR jamais développés (sécurité, scalabilité, monitoring)
💬 Pause discussion : Partagez vos anecdotes (2-3 min)
🏭 L'IT est un Système de Production
Comprendre cette analogie change tout
Mêmes flux, mêmes goulots, mêmes solutions
Analogie Fondamentale
🏭 Le Value Stream : Du Besoin à la Valeur
Dans une usine
1
Input → Matières premières
2
Transformation → Assemblage, peinture, QC
3
Output → Voiture livrée au client
Valeur créée : Quand le client paie
Dans l'IT
1
Input → User story
2
Transformation → Dev, Build, Test, Deploy
3
Output → Feature en production
Valeur créée : Quand l'utilisateur l'utilise
🏭 Usine vs IT : Même Structure
🔑 Principe clé : Si ce n'est pas en production, ça ne crée pas de valeur
⚙️ Mêmes Problématiques
Une ligne de production mal optimisée souffre de :
📦 Inventaire (WIP)
Pièces qui s'accumulent entre les postes
= Coût caché
⏰ Temps d'attente
Files d'attente devant chaque poste
= Lead Time explosif
🚧 Goulots
Un poste lent bloque toute la chaîne
= Capacité limitée
💡 L'IT a exactement les mêmes problématiques
Concept #1
📦 Le WIP Tue la Productivité
Work In Progress = Travail commencé mais pas terminé
🏭 Dans une usine
Pièces entre les postes de travail
Immobilise du capital
Cache les problèmes de qualité
Plus de WIP = Plus de temps pour finir quoi que ce soit
💻 Dans l'IT
Code non déployé (branches, commits, PRs)
Features "presque prêtes" mais pas en prod
Tickets "en cours" mais bloqués
Plus de WIP = Plus de Lead Time
⚠️ Règle d'or : Limiter le WIP améliore le débit (contre-intuitif mais mathématiquement prouvé)
Concept #2
⏰ Le Temps d'Attente Explose
Plus une ressource est utilisée, plus le temps d'attente croît exponentiellement
🏭 Exemple usine : Poste de peinture
Ressource occupée à 50% → Attente faible
Ressource occupée à 90% → Attente = 9× le temps de travail
Ressource occupée à 99% → Système s'effondre
Conséquence : Impossible de maximiser l'utilisation ET minimiser l'attente
💻 Exemple IT : Brent (notre héros)
Brent occupé à 95%
→ 19 jours d'attente pour 1 jour de travail
60% des projets bloqués en attente de Brent
Vouloir utiliser Brent à 100% = Catastrophe garantie
💡 Il faut de la capacité libre (slack) pour absorber la variabilité
Concept #3
🚧 La Contrainte Dicte Tout
Theory of Constraints (TOC) : Dans tout système, UNE ressource limite le débit global
🏭 Dans une usine
Exemple : Ligne de production automobile
Poste soudure : 10 voitures/heure
Poste peinture : 8 voitures/heure ← CONTRAINTE
Poste assemblage : 12 voitures/heure
Débit global : 8 voitures/heure (dicté par la peinture)
Conséquence : Optimiser la soudure ou l'assemblage = Gaspillage (ne change rien au débit). Seule la peinture compte !
💻 Dans l'IT
Si Brent est la contrainte → Tout l'IT dépend de lui
Si les tests manuels sont la contrainte → Automatiser est prioritaire
Si les déploiements sont la contrainte → Simplifier/Automatiser les déploiements
📐 Les 5 Étapes de la Theory of Constraints
1️⃣ Identifier
La contrainte du système
2️⃣ Exploiter
Optimiser 100% de son temps
3️⃣ Subordonner
Tout le reste s'adapte à la contrainte
4️⃣ Élever
Augmenter sa capacité
5️⃣ Répéter
Nouvelle contrainte apparaît
⚠️ Erreur fatale :
Une minute perdue sur la contrainte = Une minute perdue pour le système ENTIER (irrécouvrable)
Une minute gagnée sur une non-contrainte = Zéro gain pour le système
📊 Formules de Référence
Loi de Little
Lead\ Time = \frac{WIP}{Débit}Interprétation :
Plus de WIP → Lead Time augmente proportionnellement
Améliorer le débit → Lead Time diminue
Exemple IT :
WIP = 30 tickets en cours
Débit = 10 tickets/semaine
Lead Time = 30/10 = 3 semaines
Queue Theory
Attente = \frac{\% Occupation}{\% Inactivité}Interprétation :
Ressource à 90% → Attente = 90/10 = 9×
Ressource à 95% → Attente = 95/5 = 19×
Ressource à 99% → Attente = 99/1 = 99×
Exemple IT :
Serveur CI occupé à 90% du temps
Build prend 10 min
Attente moyenne = 90 min 😱
Ces formules mathématiques expliquent pourquoi limiter le WIP et éviter la sur-utilisation améliorent la performance
💬 Activité MIRO #1
Cartographiez votre Value Stream actuel
Consigne : En binôme, dessinez le flux de travail d'une feature de votre dernier projet :
De la user story à la production
Identifiez les étapes (Dev, Review, Test, Deploy...)
Estimez le temps d'attente vs temps de travail effectif
Où se trouve votre goulot d'étranglement ?
Durée : 10 minutes
Work Centers
⚙️ Les Work Centers de l'IT
Chaque étape récurrente du pipeline = un "atelier"
Règle des 4M : Machine (outils) + Man (compétences) + Method (procédure) + Measure (métriques)
💡 Standardiser les Work Centers permet de mesurer et donc améliorer
Métriques DORA
📏 Standardiser → Mesurer
Une fois le pipeline standardisé... On peut enfin mesurer la performance !
🚀 Tempo (Vitesse)
Deployment Frequency
Combien de déploiements par jour
Lead Time for Changes
Temps de commit → production
🛡️ Stabilité (Qualité)
Mean Time To Restore (MTTR)
Temps pour restaurer le service après incident
Change Failure Rate
% de déploiements qui causent des incidents
DORA (DevOps Research and Assessment) : métriques scientifiquement validées
📊 Métriques DORA : Avant / Après
Comparaison Low Performers vs High Performers
🎯 Révélation clé : Il n'existe PAS de trade-off entre vitesse et stabilité
Les high performers excellent sur TOUTES les métriques simultanément
Amélioration Continue
🔄 Le Cœur de DevOps
Mesurer n'est qu'un moyen. Le but : améliorer continuellement par itérations.
01
📋 Plan — Planifier
Identifier le problème • Définir l'objectif • Planifier l'action
02
⚙️ Do — Faire
Implémenter le changement (à petite échelle)
03
📊 Check — Vérifier
Mesurer les résultats • Comparer aux objectifs
04
🚀 Act — Ajuster
Standardiser si succès • Ajuster sinon • Répéter
💡 Basé sur les métriques DORA, on identifie où améliorer et on itère
🛤️ Les 3 Phases de Transformation
1️⃣ VISUALISER — 1ère Voie : Flow
Kanban board
Value Stream Mapping
WIP limits
Identifier les goulots
Résultat : Lead Time ÷ 10-20
2️⃣ AUTOMATISER — 2ème Voie : Feedback
Infrastructure as Code
Tests automatisés
CI/CD pipeline
Monitoring
Résultat : Lead Time ÷ 10-50
3️⃣ OPTIMISER — 3ème Voie : Learning
Déploiements multiples/jour
Feature flags
Blameless postmortems
Chaos Engineering
Résultat : Lead Time ÷ 10-100
⚠️ Ces phases sont itératives, pas séquentielles (amélioration continue)
💬 Activité MIRO #2
Où en êtes-vous dans les 3 phases ?
Consigne : En binôme, positionnez votre dernier projet sur la timeline :
Phase 1 (Visualiser)
Avez-vous un Kanban ? Connaissez-vous votre WIP ?
Phase 2 (Automatiser)
CI/CD en place ? Tests automatisés ? IaC ?
Phase 3 (Optimiser)
Déploiements fréquents ? Feature flags ? Blameless culture ?
Identifiez : Quelle est votre prochaine étape d'amélioration ?
Durée : 10 minutes
Construction Pipeline
🏗️ Construction d'un Pipeline DevOps
Les étapes de progression
Progression typique pour passer de manuel à pipeline optimisé
🚀 Objectif Final
2 heures → < 1 minute
De Lead Time
"If it hurts, do it more often"
→ Vous allez déployer 100× plus souvent !
Récapitulatif
✨ Ce Que Vous Avez Appris
Les 12 Principes DevOps
Visibilité, Collaboration, Quality-First, IaC, Amélioration continue
Les 3 Ways (Flow, Feedback, Learning)
Les voies de la transformation DevOps
Les Métriques DORA
Deployment Frequency, Lead Time, MTTR, Change Failure Rate
L'IT comme système de production
WIP, Goulots, Theory of Constraints
"If It Hurts, Do It More Often"
La haute fréquence force l'automatisation et réduit le risque
🎯 Prochaines Actions
01
Cartographier votre Value Stream
Identifiez où se trouvent vos goulots d'étranglement
02
Mesurer vos métriques DORA
Deployment Frequency, Lead Time, MTTR, Change Failure Rate
03
Choisir UNE amélioration
Automatiser les tests ? Implémenter IaC ? Mettre en place CI/CD ?
04
Cycle PDCA (Plan-Do-Check-Act)
Itérer et améliorer continuellement
📚 Pour Aller Plus Loin
The Phoenix Project
Gene Kim, Kevin Behr, George Spafford
Roman IT qui raconte la transformation DevOps
Accelerate
Nicole Forsgren, Jez Humble, Gene Kim
Recherche scientifique sur les pratiques DevOps
The DevOps Handbook
Gene Kim, Jez Humble, Patrick Debois, John Willis
Guide pratique de mise en œuvre DevOps
Continuous Delivery
Jez Humble, David Farley
Bible du déploiement continu
🛠️ Outils Recommandés
Version Control
Git, GitHub, GitLab, Gitea
CI/CD
GitHub Actions, GitLab CI, Jenkins, Gitea Actions
Containerization
Docker, Podman
Orchestration
Kubernetes, K3s, Docker Compose
IaC
Terraform, Ansible, Pulumi
GitOps
ArgoCD, Flux
Monitoring
Prometheus, Grafana, ELK Stack
Testing
xUnit, Jest, pytest, Testcontainers, Playwright
💡 Citations Inspirantes
"Améliorer le travail quotidien est encore plus important que de l'effectuer."
— The Phoenix Project
"If it hurts, do it more often, and bring the pain forward."
— Jez Humble
"Done means released. You can't call something done until it's delivering value to users in production."
— Continuous Delivery
"High performers understand that they don't have to trade speed for stability — by building quality in, they get both."
— Accelerate
🙏 Merci !
Des Questions ?
N'hésitez pas à partager vos retours d'expérience et vos défis DevOps
Bonne Chance
🚀 À Vous de Jouer !
Transformez Votre Pipeline
Commencez petit, itérez, améliorez continuellement
"Il importe peu de ce que vous améliorez, tant que vous améliorez quelque chose."
— Mike Rother
Revisitez cette présentation