Agile, DevOps et SRE
Trois approches complémentaires, souvent confondues.
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 comme des évolutions qui se remplaceraient l'une l'autre. C'est une erreur qui coûte cher : chacune répond à une question distincte du cycle de vie logiciel, et chacune est née d'un problème que la précédente laissait ouvert.
| Année | Événement | Problème résolu |
|---|---|---|
| 2001 | Manifeste Agile | projets en retard, spécifications qui ne correspondent plus aux besoins |
| 2003 | le SRE naît chez Google | des systèmes à grande échelle qui tombent trop souvent |
| 2009 | premier DevOpsDays | le mur entre Dev et Ops qui bloque les livraisons |
Chaque approche est née d'un problème concret, pas d'une théorie : c'est pourquoi elles s'empilent au lieu de se remplacer.
Trois questions différentes, un seul flux : il n'y a pas de compétition entre elles.
Agile : construire ce que le client veut
Livrer fréquemment de petits incréments pour s'adapter aux vrais besoins. L'Agile répond à un problème de spécification : les besoins évoluent plus vite qu'un cahier des charges ne peut les figer. Avant lui, les projets suivaient le cycle en V — spécifications exhaustives, développement de plusieurs mois, livraison — et arrivaient en retard, hors budget, avec un logiciel qui ne correspondait plus au besoin.
| Valeur | Avant, cycle en V | Après, en Agile |
|---|---|---|
| Individus et interactions | processus rigide, documentation | une équipe qui communique |
| Logiciel opérationnel | spécifications sur papier | du code qui tourne |
| Collaboration avec le client | contrat figé au départ | retours continus |
| Adaptation au changement | plan suivi à la lettre | plan qui évolue |
Quatre valeurs relatives : la première moitié garde de la valeur, la seconde l'emporte en cas d'arbitrage.
L'Agile excelle sur les cycles courts, le retour utilisateur régulier, l'autonomie des équipes et l'adaptation aux changements de priorité. En revanche, le Manifeste ne dit rien sur ce qui se passe une fois le code « terminé » au sens du sprint : comment déployer en production ? comment gérer l'infrastructure ? que faire quand le système tombe ? comment coordonner développement et exploitation ? C'est là qu'intervient le DevOps.
DevOps : livrer sans friction
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 : le code « terminé » restait des semaines en attente de déploiement, et chaque mise en production était vue par les Ops comme un risque à minimiser.
| Aspect | Agile seul | Agile et 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 » |
| Retour | après la démonstration | métriques en temps réel |
| Responsabilité | du Dev vers le product owner | de Dev et Ops vers le client final |
Le DevOps ne remplace pas l'Agile : il déplace la définition de « terminé » jusqu'à la production.
Le DevOps apporte la collaboration, l'automatisation des déploiements, l'infrastructure décrite en code et l'observabilité continue. Mais il dit « collaborez et automatisez » sans fixer de seuil chiffré : comment définir « fiable » ? quel niveau de disponibilité viser ? comment arbitrer entre vitesse et stabilité ? C'est là qu'intervient le SRE.
SRE : garantir la fiabilité
Définir la fiabilité avec des chiffres et gérer un budget d'erreurs pour équilibrer vitesse et stabilité. En 2003, Ben Treynor Sloss crée le SRE chez Google : son équipe doit tenir des systèmes à l'échelle planétaire en appliquant une démarche d'ingénieur logiciel à un problème traditionnellement traité par des opérationnels.
La citation fondatrice
« SRE is what happens when you ask a software engineer to design an operations function. » — Ben Treynor Sloss.
SLI, SLO, SLA
| Concept | Question | Exemple |
|---|---|---|
| SLI, l'indicateur | que mesure-t-on ? | latence au 99e centile, taux d'erreurs |
| SLO, l'objectif | quel objectif se fixe-t-on ? | latence sous 200 ms pour 99,9 % des requêtes |
| SLA, l'engagement | que promet-on au client ? | disponibilité de 99,5 % garantie contractuellement |
L'ordre compte : on mesure, puis on se fixe un objectif, puis on s'engage.
Le SLO n'est pas le SLA
Le SLO est toujours plus ambitieux que le SLA. Avec un SLA à 99,5 % et un SLO à 99,9 %, il reste de la marge avant de violer le contrat client.
Le budget d'erreurs
L'error budget transforme un débat d'opinion en décision chiffrée : selon la part consommée, l'équipe sait quelle posture adopter, sans négocier à chaque déploiement.
| Situation | Action |
|---|---|
| plus de 50 % du budget restant | déployer, expérimenter, prendre des risques |
| entre 10 et 50 % restant | déployer prudemment, tester davantage |
| moins de 10 % restant | arrêter les nouvelles fonctionnalités, se concentrer sur la fiabilité |
Fini le débat « on déploie ou pas » : le chiffre décide.
Le toil
Le toil désigne le travail manuel, répétitif, automatisable, sans valeur durable pour le système. C'est l'ennemi désigné du SRE : 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 capable de se rétablir seul |
| copier des logs manuellement | analyser les tendances |
| répondre aux mêmes alertes | écrire des procédures automatisées |
L'objectif historique : 50 % de toil au maximum. Au-delà, on éteint des feux, on ne fait pas du SRE.
Le SRE suppose toutefois un contexte : une certaine échelle, des ingénieurs logiciels en exploitation, des équipes dédiées à la fiabilité, une maturité organisationnelle déjà élevée. Ces hypothèses ne sont pas universelles.
Comment les trois s'articulent
| Problème observé | Approche | Solution |
|---|---|---|
| « on développe des fonctionnalités inutiles » | Agile | retour utilisateur fréquent |
| « le déploiement prend trois semaines » | DevOps | automatisation, collaboration |
| « on ne sait pas si c'est fiable » | SRE | des SLI et SLO mesurables |
| « Dev veut déployer, Ops dit non » | SRE | le budget d'erreurs comme arbitre |
Le symptôme désigne l'approche à renforcer.
| Agile apporte | DevOps étend | SRE précise |
|---|---|---|
| des itérations courtes | des déploiements continus | une fréquence liée au budget d'erreurs |
| le retour utilisateur | la supervision en temps réel | des SLI pour mesurer l'impact |
| une équipe autonome | Dev et Ops intégrés | l'ajout du SRE pour la fiabilité |
| « terminé = code fini » | « terminé = en production » | « terminé = SLO respecté » |
L'évolution de la définition de « terminé » résume tout : chaque étape ajoute une exigence.
Ce qui change en 2026
Côté mesure, le rapport DORA a changé de nature en 2025 : il abandonne le classement historique en quatre niveaux de performance 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 amplifie aussi les faiblesses existantes — davantage d'échecs de changement et de reprises chez les équipes dont les tests, revues et observabilité sont fragiles. L'IA ne remplace pas la maturité DevOps : elle la révèle.
Côté organisation, le SRE et le Platform Engineering convergent. Une équipe SRE qui gardait hier la fiabilité pour elle-même tend à l'industrialiser sous forme de plateforme en libre-service : chemins balisés, garde-fous automatisés, observabilité par défaut. Les principes ne changent pas — SLI, SLO, budget d'erreurs, toil — mais l'échelle à laquelle ils s'appliquent, oui.
Ce que cela signifie en pratique
Si votre équipe adopte l'IA générative pour coder plus vite sans avoir consolidé ses tests automatisés ni ses pratiques de revue, attendez-vous à plus d'incidents, pas moins.
Une adoption progressive
| Phase | Agile | DevOps | SRE |
|---|---|---|---|
| Produit minimal, 5 personnes | sprints de deux semaines, retour direct | CI/CD basique, déploiements manuels mais fréquents | pas de SRE formel, supervision minimale |
| Adéquation au marché, 20 personnes | sprints, feuille de route structurée | chaîne complète, infrastructure en code | premiers SLO informels |
| Croissance, 100 personnes | plusieurs équipes, agilité à l'échelle | plateforme interne en libre-service | équipe SRE dédiée, SLO formels, budgets d'erreurs |
| Grande organisation, 500 personnes et plus | Agile adapté aux contraintes réglementaires | Platform Engineering | SRE intégrés aux équipes produit, SLA clients |
On n'adopte pas tout d'un coup : on ajoute des pratiques quand les problèmes apparaissent.
Les anti-patrons
| Ce qu'on entend | Le problème | La correction |
|---|---|---|
| « on fait de l'Agile, pas besoin de DevOps » | du code « terminé » qui n'arrive jamais en production | étendre l'Agile jusqu'au déploiement |
| « on fait du DevOps, l'Agile est dépassé » | des déploiements fréquents de fonctionnalités inutiles | garder le retour utilisateur |
| « on veut faire du SRE comme Google » | des pratiques inadaptées à une équipe de dix personnes | adopter les concepts, pas la structure |
| « le SRE, c'est Ops renommé » | des opérationnels qui font du toil sous un nouveau titre | le SRE est de l'ingénierie, pas de l'exploitation manuelle |
| « ces approches s'opposent » | débats stériles, silos persistants | elles répondent à des questions différentes |
Cinq phrases de réunion qui signalent une incompréhension de la complémentarité.
La règle d'or
Agile pour savoir quoi construire. DevOps pour savoir comment livrer. SRE pour savoir si c'est fiable. Les trois ensemble : livrer la bonne chose, rapidement, de manière fiable.
À retenir de cette séance
Les trois approches répondent à des questions différentes et ne s'opposent pas. L'Agile optimise le développement le DevOps l'étend jusqu'à la production le SRE prescrit comment mesurer et garantir la fiabilité. Le SRE est une façon prescriptive d'appliquer les principes DevOps. Adoptez progressivement, et laissez le contexte dicter le niveau : une startup n'a pas besoin d'une équipe SRE dédiée, une grande organisation si.
Réponse unique
À quoi sert un budget d'erreurs en SRE ?
Indice · Que se passe-t-il quand ce budget est épuisé ?
[ METTRE EN PRATIQUE ]
Définir un SLO et son budget d'erreurs
3 étapes · 30 min · 110 XP
[ CETTE LEÇON DANS LES PARCOURS ]
- Ingénieur DevOpsétape 3 / 23suivant — Le modèle de données →