DevOps, SRE et IT Production se recouvrent partiellement, mais ne décrivent pas exactement la même chose. DevOps relie développement et exploitation ; SRE applique une démarche d’ingénierie à la fiabilité ; IT Production désigne le fonctionnement opérationnel des services informatiques. Les intitulés et les périmètres varient selon les organisations.
La bonne question n’est pas de choisir une étiquette, mais de savoir qui prend les décisions, qui les exécute et comment le résultat du service est observé.
DevOps : relier la livraison et le fonctionnement
DevOps met l’accent sur la collaboration et les pratiques qui rapprochent la construction du logiciel de son exploitation. Un pipeline CI/CD peut soutenir cette approche, mais son existence ne prouve pas que les responsabilités sont partagées ou que le retour de production influence le développement.
La présentation d’Atlassian sur DevOps et SRE décrit leur complémentarité. Dans une équipe, une question pratique consiste à demander comment une dégradation observée en production modifie le prochain changement, plutôt que de seulement inventorier les outils utilisés.
Une organisation peut automatiser ses déploiements tout en conservant une séparation rigide entre ceux qui livrent et ceux qui subissent les incidents. Le problème est alors la boucle de responsabilité, pas seulement l’outillage.
SRE : faire de la fiabilité une décision d’ingénierie
SRE apporte notamment des objectifs de service, des budgets d’erreur et des travaux visant à réduire les opérations répétitives ou les fragilités. Ces éléments rendent les arbitrages plus explicites : jusqu’où améliorer la fiabilité, quels changements accepter et quelles causes d’incident traiter ?
Le livre Google SRE expose cette démarche. Une équipe appelée SRE mais chargée uniquement de recevoir toutes les alertes ne met pas nécessairement en œuvre ce modèle.
L’article SRE et systèmes critiques développe le choix des indicateurs et leurs limites. Un SLO n’est pas une décoration de tableau de bord : il doit avoir un lien avec une action possible.
IT Production : assurer le fonctionnement opérationnel
IT Production désigne généralement les activités qui permettent aux services de fonctionner : exploitation, surveillance, incidents, changements, capacité et coordination. Ce périmètre n’est pas identique dans toutes les entreprises et peut être réparti entre équipes applicatives, infrastructure et plateformes.
Il ne s’oppose pas à l’automatisation. Une équipe de production peut utiliser Python, Ansible ou des pipelines pour rendre ses opérations plus fiables. Elle peut également adopter des objectifs de service et travailler selon des pratiques DevOps.
La différence se situe donc dans les responsabilités attribuées et les pratiques réellement exercées. Renommer une équipe ne retire aucune dépendance et ne corrige aucune procédure.
Comparer par les décisions
| Dimension | DevOps | SRE | IT Production |
|---|---|---|---|
| Question centrale | Comment livrer et exploiter ensemble ? | Quelle fiabilité viser et comment l’obtenir ? | Comment maintenir le fonctionnement du service ? |
| Pratiques possibles | Intégration, livraison, retour de production | SLO, budgets d’erreur, ingénierie de fiabilité | Supervision, incidents, changements, capacité |
| Preuve utile | Changement livré et retour exploitable | Objectif mesuré et politique associée | Service observé et intervention organisée |
| Risque de caricature | Réduire DevOps au pipeline | Réduire SRE à l’astreinte | Réduire la production aux tâches manuelles |
Ce tableau est une synthèse de lecture, pas une définition contractuelle de postes. Une équipe peut porter plusieurs de ces dimensions.
Un même incident, plusieurs contributions
Exemple pédagogique : un déploiement introduit une hausse d’erreurs sur un parcours. La chaîne de livraison doit permettre d’identifier la version et de limiter la propagation. Les responsables de fiabilité évaluent le signal par rapport au service attendu. L’exploitation coordonne le diagnostic et la restauration selon l’organisation retenue.
Les contributions peuvent être assurées par une même équipe. Le point décisif est que les interfaces soient claires : qui arrête le déploiement, qui décide de la reprise, qui informe les utilisateurs concernés et qui traite la cause après l’incident ?
Si chacun suppose que l’autre décide, trois équipes spécialisées peuvent produire une réponse moins efficace qu’une responsabilité partagée bien définie.
Éviter la bataille des outils
Ansible n’appartient pas à une seule approche ; Terraform ne transforme pas une équipe en DevOps ; un outil d’observabilité ne crée pas une pratique SRE. Les outils doivent être choisis selon l’opération, son état et son mode de contrôle.
Automatiser l’infrastructure sans perdre le contrôle propose une grille de conception applicable à ces différents contextes. Elle porte sur les effets et les reprises, plutôt que sur l’étiquette de l’équipe.
Clarifier son organisation en une séance de travail
Choisir un changement réel ou un incident représentatif, puis cartographier les décisions. Identifier la personne responsable de chaque décision, les preuves qu’elle reçoit et le chemin d’escalade. Repérer les sujets sans propriétaire et les validations qui ne changent rien au risque.
À partir de cette carte, décider quels outils ou compétences manquent. Cette séquence évite de recruter un intitulé de poste en espérant qu’il résolve un défaut de coordination non décrit.
Pour cette coordination, lire le rôle de Technical Project Leader. Les dossiers Infrastructure & Reliability et DevOps & Automation complètent la comparaison.