Agile, DevOps, SRE… Ces termes sont souvent présentés comme des alternatives ou des évolutions qui se remplacent. C’est une erreur. Ces trois approches répondent à des questions différentes et fonctionnent ensemble.
Pourquoi ces trois approches existent
Section intitulée « Pourquoi ces trois approches existent »L’analogie : construire une maison
Section intitulée « L’analogie : construire une maison »Imaginez que vous construisez une maison :
- Agile répond à : “Comment travailler avec le client pour construire ce qu’il veut vraiment ?” → Montrer des pièces finies régulièrement, adapter le plan selon ses retours
- DevOps répond à : “Comment livrer la maison au client sans délai entre la construction et l’emménagement ?” → Coordonner maçons, électriciens, plombiers pour qu’ils travaillent ensemble
- SRE répond à : “Comment s’assurer que la maison reste habitable dans le temps ?” → Définir des standards de qualité, prévoir la maintenance
Aucune de ces questions n’en remplace une autre. Vous avez besoin des trois réponses pour réussir.
La chronologie : d’où viennent-elles ?
Section intitulée « La chronologie : d’où viennent-elles ? »| Année | Événement | Problème résolu |
|---|---|---|
| 2001 | Manifeste Agile | Projets en retard, specs qui ne correspondent pas aux besoins |
| 2003 | SRE chez Google | Systèmes à grande échelle qui tombent trop souvent |
| 2009 | Premier DevOpsDays | Mur entre Dev et Ops qui bloque les livraisons |
Le point clé : chaque approche est née d’un problème concret, pas d’une théorie abstraite.
Agile : comment développer ce que le client veut
Section intitulée « Agile : comment développer ce que le client veut »L’idée en une phrase
Section intitulée « L’idée en une phrase »Livrer fréquemment de petits incréments pour s’adapter aux vrais besoins.
Avant l’Agile, les projets informatiques suivaient le cycle en V : on rédigeait des spécifications exhaustives, on développait pendant des mois (voire des années), puis on livrait. Résultat ? Des projets en retard, hors budget, et surtout des logiciels qui ne correspondaient plus aux besoins — car ces besoins avaient évolué entre-temps.
Le Manifeste Agile (2001) a proposé une alternative radicale : au lieu de tout planifier à l’avance, livrer régulièrement des petits morceaux fonctionnels et s’adapter en fonction des retours.
L’analogie : le restaurant
Section intitulée « L’analogie : le restaurant »Avant l’Agile (cycle en V) : Vous commandez un menu 7 plats. Le chef cuisine tout, vous livre 3 heures plus tard. L’entrée est froide, le plat principal n’est pas ce que vous imaginiez, mais c’est trop tard pour changer.
Avec l’Agile : Le chef vous apporte chaque plat un par un. “L’entrée vous convient ? Trop salé ? Je corrige pour le plat suivant.”
Les 4 valeurs du Manifeste Agile
Section intitulée « Les 4 valeurs du Manifeste Agile »| Valeur | Avant (cycle en V) | Après (Agile) |
|---|---|---|
| Individus et interactions | Process rigide, documentation | Équipe qui communique |
| Logiciel opérationnel | Spécifications sur papier | Code qui tourne |
| Collaboration client | Contrat figé au départ | Feedback continu |
| Adaptation au changement | Plan suivi à la lettre | Plan qui évolue |
Ce que l’Agile fait bien
Section intitulée « Ce que l’Agile fait bien »- ✅ Cycles courts (sprints de 2-4 semaines)
- ✅ Feedback utilisateur régulier
- ✅ Équipes de dev autonomes
- ✅ Adaptation aux changements de priorités
Ce que l’Agile ne couvre pas
Section intitulée « Ce que l’Agile ne couvre pas »- ❌ Comment déployer en production ?
- ❌ Comment gérer l’infrastructure ?
- ❌ Que faire quand ça tombe en panne ?
- ❌ Comment coordonner Dev et Ops ?
C’est là qu’intervient DevOps.
DevOps : comment livrer en production sans friction
Section intitulée « DevOps : comment livrer en production sans friction »L’idée en une phrase
Section intitulée « L’idée en une phrase »Casser le mur entre Dev et Ops pour livrer de la valeur en continu.
L’Agile a résolu le problème du développement, mais un nouveau mur est apparu : celui entre les développeurs et les opérationnels. Les équipes Dev livraient du code “terminé”… qui restait des semaines en attente de déploiement. Les Ops, de leur côté, considéraient chaque mise en production comme un risque à minimiser.
Le DevOps (2009) propose de casser ce mur en faisant collaborer Dev et Ops autour d’un objectif commun : livrer de la valeur au client final, pas juste du code “terminé”.
L’analogie : la course de relais
Section intitulée « L’analogie : la course de relais »Sans DevOps : Le coureur Dev sprinte 100m avec le code, arrive à la zone de passage… et attend. Le coureur Ops n’est pas prêt, il faut remplir des formulaires, attendre une approbation, vérifier que le bâton (le code) est conforme. 10 minutes d’attente pour 10 secondes de course.
Avec DevOps : Les deux coureurs s’entraînent ensemble. Le passage de relais est fluide, automatisé. Aucune attente.
DevOps étend l’Agile
Section intitulée « DevOps étend l’Agile »| Aspect | Agile seul | Agile + DevOps |
|---|---|---|
| Fin du sprint | ”Code terminé" | "Code en production” |
| Déploiement | Événement rare et risqué | Plusieurs fois par jour |
| Incident | ”Problème des Ops" | "On résout ensemble” |
| Feedback | Après la démo | Métriques temps réel |
| Responsabilité | Dev → Product Owner | Dev + Ops → Client final |
Les piliers DevOps (rappel)
Section intitulée « Les piliers DevOps (rappel) »Pour approfondir, voir Three Ways et CALMS.
| Pilier | Principe |
|---|---|
| Flow | Accélérer le flux du code vers la production |
| Feedback | Détecter les problèmes le plus tôt possible |
| Learning | Apprendre de chaque incident |
Ce que DevOps fait bien
Section intitulée « Ce que DevOps fait bien »- ✅ Collaboration Dev/Ops
- ✅ Automatisation des déploiements (CI/CD)
- ✅ Infrastructure as Code
- ✅ Monitoring et observabilité
Ce que DevOps ne prescrit pas
Section intitulée « Ce que DevOps ne prescrit pas »- ❌ Comment définir “fiable” ?
- ❌ Quel niveau de disponibilité viser ?
- ❌ Comment arbitrer entre vitesse et stabilité ?
C’est là qu’intervient SRE.
SRE : comment garantir la fiabilité
Section intitulée « SRE : comment garantir la fiabilité »L’idée en une phrase
Section intitulée « L’idée en une phrase »Définir la fiabilité avec des chiffres et gérer un “budget d’erreurs” pour équilibrer vitesse et stabilité.
DevOps a permis d’accélérer les livraisons, mais une nouvelle question est apparue : comment savoir si le système est assez fiable ? Les débats entre Dev (“on veut déployer”) et Ops (“c’est trop risqué”) persistaient, faute de critères objectifs.
Le SRE (Site Reliability Engineering) apporte une réponse quantifiée : au lieu de débattre, on définit des objectifs mesurables (SLO) et on utilise un error budget comme arbitre. Si le budget le permet, on déploie. Sinon, on stabilise.
L’analogie : le budget familial
Section intitulée « L’analogie : le budget familial »Vous avez 500€ de budget loisirs par mois. Tant qu’il vous en reste, vous pouvez aller au restaurant, au cinéma, faire des achats plaisir. Budget épuisé ? Vous arrêtez les dépenses non essentielles.
Le error budget SRE, c’est pareil :
- Votre objectif de disponibilité (SLO) = 99,9%
- Votre budget d’erreurs = 0,1% d’indisponibilité autorisée (~43 min/mois)
- Budget disponible → vous pouvez déployer, expérimenter
- Budget épuisé → focus stabilité, pas de nouvelles features
D’où vient le SRE ?
Section intitulée « D’où vient le SRE ? »2003 : Ben Treynor Sloss crée le SRE chez Google. Son équipe doit gérer des systèmes à l’échelle planétaire avec une fiabilité maximale.
Les concepts clés du SRE
Section intitulée « Les concepts clés du SRE »SLI, SLO, SLA : la pyramide de la fiabilité
Section intitulée « SLI, SLO, SLA : la pyramide de la fiabilité »| Concept | Question | Exemple |
|---|---|---|
| SLI (Indicator) | Que mesure-t-on ? | Latence p99, taux d’erreurs |
| SLO (Objective) | Quel objectif se fixe-t-on ? | ”Latence p99 < 200ms pour 99,9% des requêtes” |
| SLA (Agreement) | Quel engagement envers le client ? | ”Disponibilité 99,5% garantie contractuellement” |
L’ordre est important : on mesure (SLI) → on se fixe un objectif (SLO) → on s’engage (SLA).
Error Budget : l’arbitre entre Dev et Ops
Section intitulée « Error Budget : l’arbitre entre Dev et Ops »| Situation | Action |
|---|---|
| Error budget disponible (>50%) | Déployez, expérimentez, prenez des risques |
| Error budget serré (10-50%) | Déployez prudemment, testez plus |
| Error budget épuisé (<10%) | Stop aux features, focus fiabilité |
Pourquoi c’est puissant : Fini les débats “on déploie ou pas ?”. Le chiffre décide.
Toil : le travail à éliminer
Section intitulée « Toil : le travail à éliminer »Le toil = travail manuel, répétitif, automatisable, sans valeur durable.
| Toil (à éliminer) | Travail utile (à garder) |
|---|---|
| Redémarrer un serveur à la main | Concevoir un système auto-réparant |
| Copier des logs | Analyser les tendances |
| Répondre aux mêmes alertes | Créer des runbooks automatisés |
Objectif SRE : max 50% de toil. Si vous passez plus de temps à éteindre des feux qu’à améliorer le système, vous n’êtes pas SRE.
Ce que SRE fait bien
Section intitulée « Ce que SRE fait bien »- ✅ Définition précise de la fiabilité (SLI/SLO)
- ✅ Arbitrage objectif vitesse/stabilité (error budget)
- ✅ Réduction du travail manuel (toil)
- ✅ Pratiques prescriptives et mesurables
Ce que SRE suppose
Section intitulée « Ce que SRE suppose »- Le contexte Google (grande échelle, ingénieurs software)
- Des équipes dédiées à la fiabilité
- Une maturité organisationnelle élevée
Comment les trois s’articulent
Section intitulée « Comment les trois s’articulent »La vision d’ensemble
Section intitulée « La vision d’ensemble »
Ce schéma illustre le point essentiel : chaque approche répond à une question différente. Il n’y a pas de compétition entre elles, mais une complémentarité naturelle :
- Agile vous aide à construire le bon produit en impliquant le client
- DevOps vous aide à livrer ce produit rapidement et de manière fiable
- SRE vous aide à garantir que ce produit reste disponible et performant
Chaque approche résout un problème différent
Section intitulée « Chaque approche résout un problème différent »Le tableau ci-dessous montre comment identifier quelle approche renforcer selon le symptôme observé. En pratique, la plupart des organisations ont besoin des trois — mais pas au même niveau de maturité.
| Problème | Approche | Solution |
|---|---|---|
| ”On développe des features inutiles” | Agile | Feedback utilisateur fréquent |
| ”Le déploiement prend 3 semaines” | DevOps | Automatisation, collaboration |
| ”On ne sait pas si c’est fiable” | SRE | SLI/SLO mesurables |
| ”Dev veut déployer, Ops dit non” | SRE | Error budget comme arbitre |
Le tableau de synergie
Section intitulée « Le tableau de synergie »Ce tableau montre comment les concepts de chaque approche s’enrichissent mutuellement. Chaque colonne “étend” ou “précise” la précédente — ce n’est pas un remplacement, c’est un empilement.
| Agile apporte | DevOps étend | SRE précise |
|---|---|---|
| Itérations courtes | Déploiements continus | Fréquence liée à l’error budget |
| Feedback utilisateur | Monitoring temps réel | SLI pour mesurer l’impact |
| Équipe autonome | Dev + Ops intégrés | + SRE pour la fiabilité |
| ”Done = code fini" | "Done = en production" | "Done = SLO respecté” |
L’évolution de la définition de “Done” est particulièrement révélatrice : en Agile, le code est “fini” quand il passe les tests. En DevOps, il est “fini” quand il est en production. En SRE, il est “fini” quand il respecte les objectifs de fiabilité. Chaque étape ajoute une exigence, pas un remplacement.
Cas concret : une startup qui grandit
Section intitulée « Cas concret : une startup qui grandit »-
Phase 1 : MVP (5 personnes)
- Agile : Sprints de 2 semaines, feedback direct des premiers utilisateurs
- DevOps : CI/CD basique, déploiements manuels mais fréquents
- SRE : Pas de SRE formel, monitoring basique
-
Phase 2 : Product-Market Fit (20 personnes)
- Agile : Toujours en sprints, roadmap plus structurée
- DevOps : Pipeline CI/CD complet, Infrastructure as Code
- SRE : Premiers SLO informels (“on vise 99% de dispo”)
-
Phase 3 : Scale-up (100 personnes)
- Agile : Plusieurs équipes, framework d’agilité à l’échelle
- DevOps : Plateforme interne, self-service pour les équipes
- SRE : Équipe SRE dédiée, SLI/SLO formels, error budgets
-
Phase 4 : Enterprise (500+ personnes)
- Agile : Agile adapté aux contraintes réglementaires
- DevOps : Platform Engineering, Internal Developer Platform
- SRE : SRE embarqués dans chaque équipe produit, SLA clients
Le point clé : vous n’adoptez pas tout d’un coup. Vous ajoutez des pratiques au fur et à mesure que les problèmes apparaissent.
Grille de diagnostic : quelle approche renforcer ?
Section intitulée « Grille de diagnostic : quelle approche renforcer ? »| Si vous observez… | Approche à renforcer | Action |
|---|---|---|
| Features qui ne correspondent pas aux besoins | Agile | Plus de feedback utilisateur, démos régulières |
| Déploiements longs et risqués | DevOps | Automatiser le pipeline, réduire la taille des lots |
| Incidents fréquents sans amélioration | DevOps (Learning) | Post-mortems, amélioration continue |
| Débats “on déploie ou pas ?” | SRE | Définir des SLO et error budgets |
| Trop de temps passé à éteindre des feux | SRE | Réduire le toil, automatiser |
| Conflits Dev vs Ops | DevOps (Culture) | Objectifs partagés, responsabilité commune |
Les anti-patterns à éviter
Section intitulée « Les anti-patterns à éviter »| Anti-pattern | Problème | Solution |
|---|---|---|
| ”On fait de l’Agile, pas besoin de DevOps” | Code “terminé” qui n’arrive jamais en prod | Étendre l’Agile jusqu’au déploiement |
| ”On fait du DevOps, l’Agile c’est dépassé” | Déploiements fréquents de features inutiles | Garder le feedback utilisateur Agile |
| ”On veut faire du SRE comme Google” | Pratiques inadaptées à une équipe de 10 personnes | Adopter les concepts (SLO) sans la structure |
| ”SRE = Ops renommé” | Ops qui font du toil avec un nouveau titre | SRE = ingénierie, pas opérations manuelles |
| ”Ces approches s’opposent” | Débats stériles, silos persistants | Comprendre qu’elles répondent à des questions différentes |
À retenir
Section intitulée « À retenir »-
Agile, DevOps et SRE répondent à des questions différentes — elles ne s’opposent pas, elles se complètent
-
Agile optimise le développement — itérations courtes, feedback utilisateur, adaptation au changement
-
DevOps étend l’Agile jusqu’à la production — collaboration Dev/Ops, automatisation, livraison continue
-
SRE prescrit comment mesurer et garantir la fiabilité — SLI/SLO, error budgets, réduction du toil
-
SRE implémente DevOps — c’est une façon prescriptive d’appliquer les principes DevOps
-
Adoptez progressivement — commencez par Agile, ajoutez DevOps, puis les pratiques SRE selon vos besoins
-
Le contexte dicte le niveau — une startup n’a pas besoin d’une équipe SRE dédiée, une enterprise si
-
Error budget = arbitre objectif — fini les débats “on déploie ou pas ?”, le chiffre décide
Références
Section intitulée « Références »- Manifeste Agile — Les 4 valeurs et 12 principes fondateurs
- Scrum Guide — Le framework Scrum officiel
- The DevOps Handbook (2016, 2nd ed. 2021) — Le guide pratique DevOps
- The Phoenix Project (2013) — Le roman qui vulgarise DevOps
- Accelerate (2018) — La recherche scientifique DORA
- Site Reliability Engineering — Le livre SRE de Google (gratuit en ligne)
- The Site Reliability Workbook — Le guide pratique SRE (gratuit en ligne)
- Implementing Service Level Objectives — Guide complet sur les SLO