Scorecard Site Reliability Engineer
Voici comment évaluer un Site Reliability Engineer en entretien : les compétences à noter, les questions à poser et les signaux d'alerte. Une grille de base, à ajuster selon votre contexte et vos priorités.
Un exemple à adapter. Cette scorecard est un modèle, pas une grille à appliquer telle quelle. Gardez les critères qui correspondent à votre poste et à votre équipe, ajustez ou retirez les autres. Le bon profil dépend de votre contexte.
Site Reliability Engineer
La mission en une phrase
Tenir les objectifs de service
Définit des SLO réalistes avec les équipes produit, suit le budget d'erreur et déclenche les arbitrages quand il se consomme trop vite.
Rendre les systèmes observables
Met en place métriques, logs et traces utiles, des tableaux de bord lisibles et des alertes qui se déclenchent sur des symptômes réels plutôt que sur du bruit.
Réduire le toil par l'automatisation
Identifie les tâches répétitives à faible valeur et les supprime par du code, libérant du temps pour l'amélioration de fond des plateformes.
Maîtriser les incidents et en tirer des leçons
Conduit la résolution sous pression, rétablit le service vite et anime des post-mortems sans recherche de coupable qui débouchent sur des actions suivies.
✗ Faible · Parle de disponibilité de façon vague, vise le cent pour cent partout et ne relie jamais ses objectifs à un budget d'erreur.
✓ Excellent · Sait traduire une attente de qualité de service en SLI puis en SLO, et utilise le budget d'erreur comme outil d'arbitrage entre fiabilité et vitesse de livraison.
✗ Faible · Se limite à quelques graphiques de CPU, multiplie les alertes redondantes et peine à diagnostiquer une latence sans accès direct aux serveurs.
✓ Excellent · Instrumente les services avec les trois piliers, construit des tableaux de bord exploitables et conçoit des alertes basées sur des symptômes orientés utilisateur.
✗ Faible · Improvise pendant les incidents, cherche un responsable et clôt les post-mortems sans plan d'action ni suivi.
✓ Excellent · Structure la réponse à incident avec des rôles clairs, communique pendant la crise et rédige des post-mortems factuels qui aboutissent à des actions correctives.
✗ Faible · Accepte les tâches répétitives comme une fatalité et propose surtout des procédures manuelles documentées plutôt que des solutions logicielles.
✓ Excellent · Code des scripts et des outils pour supprimer les opérations manuelles, mesure le toil et arbitre ce qui mérite d'être automatisé.
✗ Faible · Reste à un niveau de bricolage de scripts ponctuels, sans tests ni versionnement, et évite tout développement un peu structuré.
✓ Excellent · Écrit du code propre dans au moins un langage adapté à l'exploitation et aborde l'infrastructure avec les standards d'ingénierie logicielle, tests inclus.
✗ Faible · Confond les concepts d'orchestration, ne sait pas expliquer comment un service se rétablit après la perte d'une instance.
✓ Excellent · Connaît le fonctionnement d'un orchestrateur de conteneurs et d'un fournisseur cloud, et sait raisonner sur la résilience et la montée en charge des déploiements.
✗ Faible · Considère les tests de panne comme trop risqués et n'a jamais éprouvé volontairement la robustesse d'un système.
✓ Excellent · A déjà injecté des pannes contrôlées pour valider la résilience et utilise ces tests pour révéler les points faibles avant qu'ils ne touchent la production.
Sang-froid en situation de crise
✗ Faible · Se disperse dès que la tension monte, agit dans le désordre et coupe la communication pendant la résolution.
✓ Excellent · Garde une pensée claire sous pression, hiérarchise les actions et tient les parties prenantes informées sans céder à la panique.
Collaboration avec les équipes de développement
✗ Faible · Se pose en frein qui bloque les mises en production et entretient une frontière rigide entre exploitation et développement.
✓ Excellent · Travaille en partenariat avec les développeurs, partage la responsabilité de la fiabilité et fait passer ses messages sans posture de gardien.
Rigueur et culture du factuel
✗ Faible · Avance des hypothèses non vérifiées, néglige la documentation et tranche au feeling sur des sujets de fiabilité.
✓ Excellent · Appuie ses décisions sur des données, documente clairement et privilégie l'analyse des causes plutôt que les impressions.
Sens de la priorisation
✗ Faible · Traite tout avec le même degré d'urgence, se laisse happer par les petites tâches et perd de vue les risques structurels.
✓ Excellent · Distingue ce qui menace réellement le service de ce qui peut attendre, et sait dire non à des demandes qui dégraderaient la fiabilité.
Compétences techniques
Comment définissez-vous un SLO et à quoi vous sert le budget d'erreur au quotidien ?
→ Évalue la capacité à relier objectif de service et arbitrage entre fiabilité et vitesse de livraison.
Une latence se dégrade sur un service sans erreur visible. Comment vous y prenez-vous pour la diagnostiquer ?
→ Vérifie l'usage des métriques, logs et traces et une démarche de diagnostic structurée plutôt que des suppositions.
Donnez un exemple de toil que vous avez supprimé. Comment l'avez vous repéré et qu'avez vous automatisé ?
→ Évalue la réduction du travail répétitif par du code et la capacité à mesurer le gain.
Réalisations & expérience
Racontez un système dont vous aviez la charge en production. Comment en mesuriez-vous la fiabilité et quel était son niveau de disponibilité attendu ?
→ Cherche une expérience réelle de la production et une définition concrète de la fiabilité, pas une description théorique.
Mise en situation
Décrivez un incident majeur que vous avez géré. Quel a été votre rôle pendant la crise et qu'avez vous changé après ?
→ Cherche du sang-froid, une réponse organisée et un post-mortem qui a réellement débouché sur des actions.
Motivation & fit
Qu'est-ce qui vous attire dans le métier de SRE plutôt que dans un poste de développement ou d'exploitation classique ?
→ Cherche une attirance assumée pour la fiabilité traitée comme un problème d'ingénierie, pas un choix par défaut.
Savoir-être & collaboration
Une équipe de développement veut livrer alors que le budget d'erreur est épuisé. Comment gérez vous cette conversation ?
→ Teste la collaboration et la fermeté factuelle sans se transformer en frein arbitraire.
Vise systématiquement le cent pour cent de disponibilité
Trahit une incompréhension du budget d'erreur et une approche qui paralyse la livraison sans gain réel de fiabilité.
Cherche un coupable lors des post-mortems
Une culture de la sanction empêche l'apprentissage collectif et pousse les équipes à masquer les vrais problèmes.
Refuse de coder et privilégie toujours les procédures manuelles
L'approche logicielle de l'exploitation est le cœur du métier ; sans elle le toil s'accumule et le poste dérive vers du support.
Se positionne comme le gardien qui bloque les mises en production
Le rôle repose sur le partenariat avec les développeurs ; une posture de blocage casse la responsabilité partagée de la fiabilité.
Ne sait pas distinguer une alerte sur symptôme d'une alerte sur cause
Conduit à des alertes bruyantes et à une fatigue d'astreinte qui finit par masquer les incidents réellement critiques.
Lecture du score
Notez chaque compétence et savoir-être de 1 à 5. Repère de décision : moyenne supérieure ou égale à 4 sur les must-have et aucun red flag majeur = go ; 3 à 4 avec réserves = à challenger en second tour ; un must-have sous 3 ou un red flag majeur = no-go. Un nice-to-have faible ne doit jamais éliminer un bon profil.
Qu'est-ce qu'une scorecard pour recruter un Site Reliability Engineer ?
Une scorecard site reliability engineer est une grille d'évaluation structurée : elle liste les compétences et savoir-être à noter de 1 à 5, les questions d'entretien à poser et les signaux d'alerte. Elle permet de comparer les candidats sur des critères objectifs plutôt que sur une impression. On parle aussi de scorecard sre, scorecard ingénieur fiabilité, scorecard site reliability engineer.
Comment utiliser cette scorecard Site Reliability Engineer ?
Téléchargez-la en PDF, Excel ou Notion, notez chaque critère de 1 à 5 pendant l'entretien, puis additionnez les scores du panel pour décider sur des faits. La version Excel calcule la moyenne et la décision automatiquement.
Quelle différence entre un Site Reliability Engineer et un DevOps ?
Le DevOps désigne d'abord une culture de collaboration entre développement et exploitation, portée par l'automatisation des chaînes de livraison. Le SRE en est une mise en œuvre concrète et plus exigeante : il fixe des objectifs de service chiffrés, pilote un budget d'erreur et applique des méthodes d'ingénierie logicielle à la fiabilité. Là où une démarche DevOps cherche surtout à fluidifier le passage en production, le SRE est garant mesurable de la disponibilité et de la performance une fois le service en ligne.
Quelle différence entre un Site Reliability Engineer et un Platform Engineer ?
Le Platform Engineer construit la plateforme interne et les outils en libre service qui permettent aux développeurs de déployer et d'exploiter leurs services de façon autonome. Le SRE se concentre sur la fiabilité de ces services en production : SLO, observabilité, gestion des incidents et réduction du toil. Les deux rôles se complètent et se recouvrent parfois, mais le Platform Engineer raisonne en producteur d'outils tandis que le SRE raisonne en garant du bon fonctionnement de ce qui tourne.