Agile, DevOps, SRE… ces trois termes reviennent sans cesse dans les offres d'emploi et les conférences, souvent présentés comme des étiquettes interchangeables ou des évolutions qui se remplacent l'une l'autre. C'est une erreur qui coûte cher : chacune répond à une question distincte du cycle de vie logiciel. Cette page s'adresse à toute personne qui débute en DevOps et se demande comment situer ces trois approches les unes par rapport aux autres. Vous y trouverez leurs origines respectives, un exemple concret d'adoption progressive dans une startup qui grandit, et l'état de leur pratique en 2026, notamment l'évolution du rapport DORA et la convergence entre SRE et Platform Engineering.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Distinguer les questions auxquelles répondent Agile, DevOps et SRE
- Situer chronologiquement l'apparition de chaque approche et le problème qu'elle a résolu
- Reconnaître les signaux qui indiquent quelle approche renforcer dans votre contexte
- Éviter les anti-patterns classiques ("on fait de l'Agile, pas besoin de DevOps")
- Comprendre comment ces trois approches évoluent en 2026 avec l'IA générative et le Platform Engineering
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 »Pour comprendre pourquoi ces trois approches coexistent sans se concurrencer, imaginez que vous construisez une maison. Trois questions bien distinctes se posent, et aucune ne remplace les deux autres.
- 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 un projet logiciel durable.
La chronologie : d'où viennent-elles ?
Section intitulée « La chronologie : d'où viennent-elles ? »Chaque approche est apparue à un moment précis pour résoudre un problème concret rencontré par l'industrie, pas comme une théorie abstraite sortie d'un livre blanc. Comprendre cette chronologie aide à saisir pourquoi elles s'empilent plutôt qu'elles ne se substituent.
| 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. C'est ce qui explique qu'elles se complètent naturellement : elles n'ont jamais visé le même périmètre.
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 du client.
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, puis vous livre 3 heures plus tard. L'entrée est froide, le plat principal n'est pas ce que vous imaginiez, mais il est trop tard pour changer quoi que ce soit.
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 »Le Manifeste Agile ne décrit pas une méthode précise (Scrum et Kanban viendront plus tard formaliser des pratiques), mais quatre valeurs relatives : dans chaque paire, la première partie garde de la valeur, mais la seconde est privilégiée en cas d'arbitrage. Le tableau ci-dessous confronte l'ancien modèle (cycle en V) au modèle agile pour chacune.
| 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 »L'Agile excelle sur tout ce qui touche à la relation avec le client et à l'organisation du travail de développement en petites boucles. Voici ses forces principales :
- Cycles courts, sprints de 2 à 4 semaines
- Feedback utilisateur régulier
- Équipes de développement autonomes
- Adaptation rapide aux changements de priorités
Ce que l'Agile ne couvre pas
Section intitulée « Ce que l'Agile ne couvre pas »En revanche, le Manifeste Agile ne dit strictement rien sur ce qui se passe après que le code est "terminé" au sens du sprint. Cette zone d'ombre concerne des questions très concrètes :
- Comment déployer en production ?
- Comment gérer l'infrastructure ?
- Que faire quand le système tombe en panne ?
- Comment coordonner les équipes de développement et les équipes opérationnelles ?
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 ensuite des semaines en attente de déploiement. Les Ops, de leur côté, considéraient chaque mise en production comme un risque à minimiser à tout prix.
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 seulement du code "terminé" au sens du backlog.
L'analogie : la course de relais
Section intitulée « L'analogie : la course de relais »Sans DevOps : le coureur Dev sprinte 100 mètres 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. Dix minutes d'attente pour dix secondes de course.
Avec DevOps : les deux coureurs s'entraînent ensemble. Le passage de relais est fluide et automatisé. Aucune attente.
DevOps étend l'Agile
Section intitulée « DevOps étend l'Agile »Le tableau suivant montre comment le DevOps ne remplace pas l'Agile mais en déplace la définition de "terminé" vers la production réelle, avec des conséquences directes sur la fréquence de déploiement et la gestion des incidents.
| 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 vers Product Owner | Dev + Ops vers client final |
Les piliers DevOps (rappel)
Section intitulée « Les piliers DevOps (rappel) »Le DevOps repose sur trois piliers popularisés par le cadre Three Ways, détaillé dans Three Ways et CALMS : accélérer le flux, raccourcir la boucle de feedback, et institutionnaliser l'apprentissage continu. Le tableau ci-dessous les résume.
| 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 »Le DevOps comble précisément le trou laissé par l'Agile : tout ce qui concerne le passage du code du poste du développeur jusqu'à la production, de façon fiable et répétable.
- Collaboration renforcée entre Dev et Ops
- Automatisation des déploiements via le CI/CD
- Infrastructure as Code pour reproduire les environnements
- Monitoring et observabilité en continu
Ce que DevOps ne prescrit pas
Section intitulée « Ce que DevOps ne prescrit pas »Le DevOps dit "collaborez et automatisez", mais il ne fixe aucun seuil chiffré. Il laisse ouvertes des questions d'arbitrage qui, sans réponse claire, tournent vite au conflit :
- 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é.
Le 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, qui veut déployer, et Ops, qui juge cela 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, les 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 »Prenons un exemple parlant : vous avez 500 euros 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 fonctionne exactement pareil :
- Votre objectif de disponibilité, ou SLO, est fixé à 99,9 %
- Votre budget d'erreurs autorise 0,1 % d'indisponibilité, soit environ 43 minutes par mois
- Budget disponible : vous pouvez déployer, expérimenter
- Budget épuisé : vous vous concentrez sur la stabilité, pas de nouvelles fonctionnalités
D'où vient le SRE ?
Section intitulée « D'où vient le SRE ? »Le SRE trouve son origine dans un contexte bien précis, celui d'une entreprise confrontée à des volumes que peu d'organisations connaissaient à l'époque.
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, en appliquant une démarche d'ingénieur logiciel à un problème traditionnellement traité par des opérationnels.
Les concepts clés du SRE
Section intitulée « Les concepts clés du SRE »Trois concepts structurent la pratique quotidienne du Site Reliability Engineering : la mesure objective de la fiabilité, l'arbitrage par error budget entre vitesse et stabilité, et l'élimination méthodique du toil. Cette page les présente sous l'angle de la comparaison avec Agile et DevOps ; pour une présentation complète du SRE en tant que discipline à part entière, voir Introduction au Site Reliability Engineering (SRE).
SLI, SLO, SLA : la pyramide de la fiabilité
Section intitulée « SLI, SLO, SLA : la pyramide de la fiabilité »Ces trois sigles se ressemblent et se confondent souvent, mais ils désignent trois niveaux distincts d'une même chaîne de mesure. Le tableau ci-dessous les distingue par la question à laquelle chacun répond.
| Concept | Question | Exemple |
|---|---|---|
| SLI (Indicator) | Que mesure-t-on ? | Latence p99, taux d'erreurs |
| SLO (Objective) | Quel objectif se fixe-t-on ? | "Latence p99 inférieure à 200 ms pour 99,9 % des requêtes" |
| SLA (Agreement) | Quel engagement envers le client ? | "Disponibilité 99,5 % garantie contractuellement" |
L'ordre est important : on mesure avec le SLI, on se fixe un objectif avec le SLO, puis on s'engage avec le SLA. Pour aller plus loin sur ces trois notions et leur calcul, voir SLO, SLI et Error Budgets.
Error Budget : l'arbitre entre Dev et Ops
Section intitulée « Error Budget : l'arbitre entre Dev et Ops »L'error budget transforme un débat d'opinion en décision chiffrée : selon la part du budget consommée, l'équipe sait exactement quelle posture adopter, sans négociation à chaque déploiement.
| Situation | Action |
|---|---|
| Error budget disponible, plus de 50 % restant | Déployez, expérimentez, prenez des risques |
| Error budget serré, entre 10 et 50 % restant | Déployez prudemment, testez davantage |
| Error budget épuisé, moins de 10 % restant | Stop aux nouvelles fonctionnalités, focus fiabilité |
Pourquoi c'est puissant : fini les débats "on déploie ou pas ?". Le chiffre décide, ce qui désamorce une bonne partie des tensions Dev/Ops.
Toil : le travail à éliminer
Section intitulée « Toil : le travail à éliminer »Le toil désigne le travail manuel, répétitif, automatisable, qui n'apporte aucune valeur durable au système. C'est l'ennemi désigné du SRE, car il consomme du temps d'ingénierie sans jamais réduire le risque à long terme.
| Toil, à éliminer | Travail utile, à garder |
|---|---|
| Redémarrer un serveur à la main | Concevoir un système auto-réparant |
| Copier des logs manuellement | Analyser les tendances |
| Répondre aux mêmes alertes | Créer des runbooks automatisés |
Objectif historique du SRE : maximum 50 % de toil. Si vous passez plus de temps à éteindre des feux qu'à améliorer le système, vous n'êtes pas en train de faire du SRE. Pour une méthode complète de réduction du toil, voir Éliminer le Toil.
Ce que SRE fait bien
Section intitulée « Ce que SRE fait bien »Le SRE apporte précisément ce qui manquait au DevOps : des critères objectifs pour trancher les débats vitesse contre stabilité.
- Définition précise de la fiabilité via SLI et SLO
- Arbitrage objectif entre vitesse et stabilité grâce à l'error budget
- Réduction méthodique du travail manuel, le toil
- Pratiques prescriptives et mesurables, pas seulement des principes
Ce que SRE suppose
Section intitulée « Ce que SRE suppose »Le SRE version Google part d'hypothèses qui ne sont pas universelles. Avant de vouloir "faire du SRE comme Google", vérifiez que votre contexte s'en rapproche, au moins un peu :
- Un contexte de grande échelle avec des ingénieurs software en opérations
- Des équipes dédiées à la fiabilité
- Une maturité organisationnelle déjà é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 permet d'identifier rapidement quelle approche renforcer selon le symptôme observé sur le terrain. En pratique, la plupart des organisations ont besoin des trois, mais pas au même niveau de maturité au même moment.
| Problème | Approche | Solution |
|---|---|---|
| "On développe des fonctionnalités 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 et 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 de garanties successives.
| 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 et Ops intégrés | Ajout du SRE pour la fiabilité |
| "Terminé = code fini" | "Terminé = en production" | "Terminé = SLO respecté" |
L'évolution de la définition de "terminé" 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, elle ne remplace pas la précédente.
Ce qui change en 2026 : DORA, IA générative et Platform Engineering
Section intitulée « Ce qui change en 2026 : DORA, IA générative et Platform Engineering »Ces trois approches ne sont pas figées depuis leur création : elles évoluent avec les outils et les usages. Deux tendances récentes méritent d'être connues avant de choisir comment les appliquer dans votre organisation.
Côté mesure, le rapport DORA sur l'état du DevOps a changé de nature en 2025 : il abandonne le classement historique en équipes "elite / high / medium / low performers" au profit de sept archétypes d'équipes qui combinent performance de livraison et facteurs humains, comme le risque d'épuisement professionnel. Le constat central : l'intelligence artificielle générative accélère l'écriture de code, mais elle amplifie aussi les faiblesses existantes, davantage d'échecs de changement et de reprises de travail chez les équipes dont les fondations, tests, revues, observabilité, sont fragiles. Autrement dit, l'IA ne remplace pas la maturité DevOps : elle la révèle. Pour le détail des 4 métriques historiques et leur usage, voir Les métriques DORA.
Côté organisation, le SRE et le Platform Engineering convergent de plus en plus. Une équipe SRE qui, hier, gardait la fiabilité pour elle-même, tend aujourd'hui à l'industrialiser sous forme de plateforme en libre-service : golden paths, garde-fous automatisés, observabilité par défaut. C'est le rôle décrit dans Platform Engineering. Cette évolution ne change rien aux principes de base, SLI, SLO, error budget, toil, restent identiques, mais elle change l'échelle à laquelle ils s'appliquent : d'une équipe à toute l'organisation.
Cas concret : une startup qui grandit
Section intitulée « Cas concret : une startup qui grandit »Pour rendre ces notions moins abstraites, suivons une startup fictive mais réaliste sur quatre phases de croissance. À chaque phase, le niveau d'exigence sur Agile, DevOps et SRE évolue, sans jamais qu'une approche ne soit abandonnée au profit d'une autre.
-
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 et SLO formels, error budgets
-
Phase 4 : Enterprise, 500 personnes et plus
- Agile : Agile adapté aux contraintes réglementaires
- DevOps : Platform Engineering, plateforme interne pour développeurs
- 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, pas par anticipation théorique. Pour structurer ce type de croissance d'équipe, voir Structurer ses équipes DevOps.
Grille de diagnostic : quelle approche renforcer ?
Section intitulée « Grille de diagnostic : quelle approche renforcer ? »Face à un symptôme précis sur le terrain, il est souvent plus utile de se demander "quelle approche dois-je renforcer" que de chercher une solution générique. Le tableau suivant relie chaque symptôme observable à l'approche la plus pertinente et à une première action concrète.
| Si vous observez | Approche à renforcer | Action |
|---|---|---|
| Fonctionnalités 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 contre Ops | DevOps (Culture) | Objectifs partagés, responsabilité commune |
Deux lignes de ce tableau, incidents fréquents et conflits Dev/Ops, méritent un approfondissement dédié : voir Incidents et Postmortems pour transformer chaque panne en apprentissage exploitable.
Les anti-patterns à éviter
Section intitulée « Les anti-patterns à éviter »Certaines phrases, entendues en réunion, signalent presque toujours une incompréhension de la complémentarité entre ces trois approches. Le tableau ci-dessous les recense avec le problème réel qu'elles masquent et la correction à apporter.
| Anti-pattern | Problème | Solution |
|---|---|---|
| "On fait de l'Agile, pas besoin de DevOps" | Code "terminé" qui n'arrive jamais en production | Étendre l'Agile jusqu'au déploiement |
| "On fait du DevOps, l'Agile c'est dépassé" | Déploiements fréquents de fonctionnalités inutiles | Garder le feedback utilisateur de l'Agile |
| "On veut faire du SRE comme Google" | Pratiques inadaptées à une équipe de 10 personnes | Adopter les concepts, SLO, sans la structure |
| "SRE, c'est juste Ops renommé" | Des Ops qui font du toil avec un nouveau titre | Le SRE, c'est de l'ingénierie, pas des opérations manuelles |
| "Ces approches s'opposent" | Débats stériles, silos persistants | Comprendre qu'elles répondent à des questions différentes |
Ces cinq anti-patterns concernent spécifiquement la confusion entre Agile, DevOps et SRE. Pour un catalogue plus large des pièges d'adoption DevOps, recrutement magique, blâme après incident, automatisation aveugle par IA, voir Anti-patterns DevOps : les pièges à éviter.
À retenir
Section intitulée « À retenir »- Agile, DevOps et SRE répondent à des questions différentes : ils ne s'opposent pas, ils 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 grande entreprise si
- En 2026, l'IA générative révèle la maturité DevOps plutôt qu'elle ne la remplace, et SRE et Platform Engineering convergent vers des plateformes en libre-service
Références
Section intitulée « Références »Ces lectures permettent d'approfondir chacune des trois approches à partir des sources originales, plutôt que de s'arrêter aux résumés qui en circulent.
- Manifeste Agile, les 4 valeurs et 12 principes fondateurs
- Scrum Guide, le framework Scrum officiel
- The DevOps Handbook (2016, 2ᵉ édition 2021), le guide pratique DevOps
- The Phoenix Project (2013), le roman qui vulgarise DevOps
- Accelerate (2018), la recherche scientifique DORA
- DORA, état du DevOps 2025, l'édition qui introduit les archétypes d'équipes et l'impact de l'IA générative
- 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