Il décide quel niveau de fiabilité un service doit réellement garantir, quels risques de production l’organisation accepte et quand la stabilité doit prendre le pas sur la vitesse de changement.
Le poste ne se résume ni à surveiller des tableaux de bord, ni à intervenir pendant les incidents, ni à automatiser les opérations répétitives. Le SRE transforme la fiabilité en une propriété pilotable du produit : il définit les indicateurs qui représentent réellement le service rendu, établit des objectifs de service, mesure leur respect et utilise ces données pour arbitrer entre nouvelles fonctionnalités, dette de fiabilité, capacité et risque opérationnel.
La frontière avec les métiers voisins est volontairement stricte. Le Cloud Infrastructure Engineer construit les fondations. Le DevOps Engineer fluidifie et automatise le passage du code à la production. Le Platform Engineer transforme des capacités techniques en produit interne. Le SRE s’appuie sur ces fondations, mais son objet principal est différent : il protège la fiabilité et la performance des services en production, du point de vue de leurs utilisateurs.
Celui qui exécute sait traiter une alerte ou redémarrer un composant. Celui qui tient le poste sait déterminer si l’alerte représente une dégradation réelle, si le service peut continuer en mode dégradé et quel niveau d’indisponibilité l’organisation accepte pour conserver sa capacité à livrer. La tension centrale du métier oppose fiabilité et vitesse d’évolution.
Repères marché
Le titre SRE recouvre encore des réalités très différentes. Certaines organisations l’utilisent pour désigner une exploitation modernisée ou une équipe DevOps orientée production ; d’autres ont réellement installé des objectifs de service, des budgets d’erreur et une responsabilité partagée avec les équipes produit.
Les profils capables de combiner ingénierie logicielle, jugement d’exploitation, gestion d’incident et arbitrage avec le produit restent rares. La maîtrise d’un écosystème d’observabilité situe une expérience, mais elle prédit mal la capacité à définir un objectif utile ou à rendre une astreinte soutenable.
Contexte
En ESN, l’évaluation insiste sur la capacité à intervenir dans un patrimoine hérité, avec des objectifs contractuels parfois déconnectés de l’architecture réelle et une marge de décision limitée. Le SRE doit rendre le risque visible, distinguer l’engagement contractuel de la fiabilité réellement atteignable et transmettre un dispositif exploitable après la mission.
Niveau 1
Junior
Intervient sur un service dont les objectifs, les alertes et les procédures d’exploitation sont déjà définis. Il sait lire les signaux disponibles, qualifier une dégradation, appliquer une mesure de stabilisation et solliciter une aide lorsque l’impact dépasse son périmètre. La différence avec un simple opérateur tient à sa capacité à vérifier l’effet de son action sur le service rendu, plutôt qu’à constater seulement le retour au vert d’un composant.
Cliquer pour lire
Niveau 2
Confirmé
Prend en charge la fiabilité d’un service de bout en bout. Il relie les indicateurs techniques à l’expérience utilisateur, améliore l’observabilité, prépare les comportements dégradés, analyse les incidents récurrents et réduit les opérations manuelles qui consomment l’astreinte. Il rend les défaillances compréhensibles, la capacité mesurable et la reprise vérifiable.
Cliquer pour lire
Niveau 3
Sénior
Arbitre entre objectifs de service, rythme de changement, capacité disponible, coût d’infrastructure et charge humaine. Il sait distinguer une dégradation acceptable d’un risque structurel, utiliser le budget d’erreur pour rendre les décisions explicites et remettre en cause un objectif de disponibilité disproportionné par rapport à la valeur du service. Il pense en fiabilité globale, en dépendances et en rayon d’impact.
Cliquer pour lire
Niveau 4
Expert
Ne se distingue pas par un plus grand catalogue d’outils de supervision. Il tranche les arbitrages les plus coûteux et nomme ce qu’il accepte de perdre : ralentir temporairement les mises en production, réduire le périmètre fonctionnel d’un service, accepter un objectif de disponibilité moins ambitieux, ou interrompre une fonctionnalité pour préserver l’intégrité du système.
Cliquer pour lire
Sans indicateurs représentatifs, objectifs de service et budget d’erreur, la fiabilité reste une impression subjective, invoquée après chaque incident mais inutilisable pour décider avant le suivant.
Le SRE doit pouvoir qualifier une dégradation, stabiliser le service et conduire une investigation sous pression. Ce poids mesure la qualité du raisonnement et des signaux disponibles, jamais la vitesse de redémarrage d’un composant.
La fiabilité se conçoit avant l’incident : modes de panne, dépendances, saturation, latence, reprise et comportements dégradés doivent être compris au niveau du service.
L’automatisation compte lorsqu’elle retire une opération répétitive, risquée ou sans valeur durable. Automatiser une mauvaise pratique ne la transforme pas en ingénierie de fiabilité.
La fiabilité est une responsabilité partagée avec les équipes de développement et de produit. Cette catégorie vérifie que le candidat sait rendre l’astreinte soutenable sans créer une équipe SRE qui absorbe seule toutes les conséquences.
La méthode en action
La scorecard en un regard — survoler un axe
Cloud, plateforme et fiabilité