Qu'est-ce qu'un Site Reliability Engineer ?
Un Site Reliability Engineer veille à ce qu'un service en ligne réponde vite et sans panne, pour ses utilisateurs. Il y parvient avec du code et des mesures plutôt qu'avec des interventions manuelles.
Il se place entre les équipes produit, qui livrent des fonctionnalités, et l'infrastructure qui les fait tourner. Il ne décide pas de ce que fait le produit. Il décide à quel niveau de fiabilité il doit fonctionner, et il s'assure qu'on le tient.
| Rôle | Avant l'incident | Pendant et après |
|---|---|---|
| Développeur de l'équipe produit | Écrit le code et ses tests | Corrige le bug une fois la cause trouvée |
| Site Reliability Engineer | Définit les SLO, les alertes et les procédures | Coordonne la réponse, puis anime le post-mortem |
| Platform Engineer | Fournit les outils de déploiement et d'environnement | Améliore la plateforme si elle a joué un rôle |
| Responsable produit | Arbitre entre nouvelles fonctionnalités et fiabilité | Informe les clients concernés |
Développeur de l'équipe produit
- Avant l'incident
- Écrit le code et ses tests
- Pendant et après
- Corrige le bug une fois la cause trouvée
Site Reliability Engineer
- Avant l'incident
- Définit les SLO, les alertes et les procédures
- Pendant et après
- Coordonne la réponse, puis anime le post-mortem
Platform Engineer
- Avant l'incident
- Fournit les outils de déploiement et d'environnement
- Pendant et après
- Améliore la plateforme si elle a joué un rôle
Responsable produit
- Avant l'incident
- Arbitre entre nouvelles fonctionnalités et fiabilité
- Pendant et après
- Informe les clients concernés
D'où vient le métier : Google, 2003
Le livre de Google sur le sujet raconte que Ben Treynor Sloss a pris la tête d'une équipe de production de sept ingénieurs en 2003. Cette équipe est devenue la fonction SRE de Google. Sa définition est restée célèbre : le SRE, c'est ce qui arrive quand on demande à un ingénieur logiciel de concevoir une équipe d'exploitation.
Google a ensuite publié ses pratiques dans plusieurs livres, lisibles gratuitement sur sre.google. Ils restent la référence citée dans presque toutes les offres françaises.
SRE en français
La traduction littérale donne « ingénieur fiabilité des sites », que personne n'emploie. On lit parfois « ingénieur en fiabilité » ou « ingénieur de production », mais ce dernier titre désigne souvent un poste d'exploitation plus classique. Le sigle SRE s'est imposé.
Qui recrute des SRE en France ?
Ceux dont chaque minute de panne coûte cher. On les trouve dans le e-commerce, la fintech, le SaaS, les médias et le jeu vidéo. Les banques et les opérateurs créent aussi des équipes SRE, parfois en renommant leurs équipes de production.
Sur nos missions de recrutement de SRE, nous vérifions toujours ce point. Certaines offres parlent de SRE pour un poste d'administrateur d'astreinte, sans SLO ni temps réservé à l'automatisation.
Les missions d'un Site Reliability Engineer
Le livre de Google plafonne le travail d'exploitation à 50 % du temps d'un SRE. Le reste doit servir à des projets d'ingénierie qui rendent le service plus fiable. Cette règle donne la forme des missions.
Définir ce qu'est un service fiable
Avec l'équipe produit, le SRE choisit les indicateurs qui comptent pour l'utilisateur et fixe les objectifs à tenir. Il écrit ensuite les alertes qui se déclenchent quand ces objectifs sont menacés, et seulement dans ce cas.
Tenir l'astreinte et gérer les incidents
À tour de rôle, il est joignable la nuit et le week-end. Quand une alerte sonne, il diagnostique, limite les dégâts, puis rétablit le service. Sur un incident sérieux, il prend le rôle de coordinateur pendant que d'autres réparent.
Automatiser l'exploitation
Chaque tâche manuelle répétée est une candidate à l'automatisation : redémarrer un service, agrandir un disque, renouveler un certificat. Le SRE écrit ces outils en Go ou en Python, et décrit l'infrastructure en code avec Terraform.
Préparer la montée en charge
Avant un pic prévisible, soldes ou lancement, il estime la charge, teste les limites et prévoit la capacité nécessaire. Il vérifie aussi que le service se dégrade proprement au lieu de tomber d'un coup.
Rendre les déploiements plus sûrs
La plupart des pannes suivent un changement. Le SRE met en place des déploiements progressifs, des retours arrière automatiques et des tests de charge. Il revoit aussi l'architecture des nouveaux services avant leur mise en production.
Une semaine type
Lundi, la revue des SLO de la semaine passée avec deux équipes produit. Mardi et mercredi, du code sur un outil qui supprime une intervention manuelle récurrente. Jeudi, l'animation du post-mortem d'une panne de paiement.
Vendredi, la passation d'astreinte au collègue suivant, avec la liste des alertes bruyantes à corriger. Si une alerte réveille quelqu'un deux nuits de suite, elle remonte en tête des priorités.
SLI, SLO, budget d'erreur : la méthode SRE expliquée
Ces trois sigles reviennent dans toutes les offres. Les candidats les récitent souvent, mais peu savent les appliquer. Voici ce qu'ils recouvrent, avec un exemple chiffré.
| Notion | Définition | Exemple sur une API de paiement |
|---|---|---|
| SLI (indicateur) | Une mesure de ce que vit l'utilisateur | Part des requêtes servies sans erreur en moins de 300 ms |
| SLO (objectif) | Le niveau visé pour cet indicateur, sur une période | 99,9 % des requêtes réussies sur 30 jours glissants |
| SLA (contrat) | Un engagement envers un client, avec pénalités | 99,5 % promis au contrat, en dessous du SLO interne |
SLI (indicateur)
- Définition
- Une mesure de ce que vit l'utilisateur
- Exemple sur une API de paiement
- Part des requêtes servies sans erreur en moins de 300 ms
SLO (objectif)
- Définition
- Le niveau visé pour cet indicateur, sur une période
- Exemple sur une API de paiement
- 99,9 % des requêtes réussies sur 30 jours glissants
SLA (contrat)
- Définition
- Un engagement envers un client, avec pénalités
- Exemple sur une API de paiement
- 99,5 % promis au contrat, en dessous du SLO interne
Le budget d'erreur, avec un exemple
Le budget d'erreur vaut 100 % moins le SLO. Avec un objectif de 99,9 % sur 30 jours, il reste 0,1 % de marge. Sur un mois de 43 200 minutes, cela fait 43 minutes d'indisponibilité autorisées.
Le même calcul marche en requêtes. Si l'API traite 10 millions d'appels dans le mois, 10 000 peuvent échouer sans trahir l'objectif. Une panne de vingt minutes un mardi consomme donc près de la moitié du budget.
À quoi sert ce budget
Tant qu'il reste du budget, l'équipe produit livre à son rythme. Quand il est épuisé, les nouvelles fonctionnalités attendent et l'effort passe sur la fiabilité. Le budget transforme un débat d'opinions entre développeurs et exploitants en règle partagée.
Un objectif à 100 % n'a pas de sens : il interdirait tout changement. Le bon SLO correspond au niveau à partir duquel l'utilisateur remarque vraiment la gêne.
L'astreinte
En France, une période d'astreinte doit être compensée, en argent ou en repos, selon l'article L3121-9 du Code du travail. Les interventions comptent comme du temps de travail effectif. Les modalités dépendent de l'accord de chaque entreprise : posez la question dès le premier entretien.
Une bonne organisation compte au moins six à huit personnes dans la rotation, pour ne pas être d'astreinte plus d'une semaine sur six ou huit. Nous voyons encore des équipes de trois, ce qui épuise vite les meilleurs.
Le post-mortem sans blâme
Après chaque incident sérieux, l'équipe rédige un post-mortem : chronologie, impact, causes, actions correctives datées. Google insiste sur une culture sans blâme : on cherche ce qui a permis l'erreur, pas qui l'a commise. Un ingénieur qui craint la sanction cache les signaux faibles.
Le toil
Google appelle toil le travail d'exploitation manuel, répétitif, automatisable et sans valeur durable, qui grossit avec le trafic. Relancer à la main un traitement bloqué chaque matin en est l'exemple type. Un SRE mesure ce temps et le réduit, sinon son équipe finit par ne faire que ça.
Les compétences que nous vérifions en recrutement
Un CV de SRE aligne vite une dizaine d'outils. En entretien, nous cherchons surtout la manière de raisonner face à un système qui se comporte mal.
- Linux et réseau : processus, mémoire, DNS, TCP, équilibreurs de charge. Un candidat doit savoir pourquoi un service répond lentement alors que le processeur est au repos.
- Code en Go ou en Python pour écrire de vrais outils, pas seulement des scripts de dix lignes.
- Kubernetes et un grand cloud public, AWS, GCP ou Azure, avec l'infrastructure décrite en Terraform.
- Observabilité : métriques avec Prometheus, traces avec OpenTelemetry, logs, et des alertes fondées sur les SLO.
- Gestion d'incident : rester calme, communiquer, décider de revenir en arrière avant de comprendre la cause.
- Écrit : un post-mortem clair et un document de conception lisible par des non-spécialistes.
Ce que nous faisons en entretien
Nous décrivons un service dont la latence monte depuis dix minutes, sans erreur visible, juste après un déploiement. Le candidat pose ses questions et dit quelles courbes il ouvre, dans quel ordre. Les meilleurs proposent un retour arrière très tôt, puis cherchent la cause à froid. Ensuite, nous lui demandons de fixer un SLO pour ce service et de justifier le chiffre.
Salaire d'un Site Reliability Engineer en 2026
Notre baromètre place un SRE confirmé à 42 à 55 K€ de fixe brut annuel à Paris. Le senior, avec six à dix ans de métier, se situe à 56 à 72 K€, et le palier Expert démarre à 74 K€. Le secteur, la taille de l'entreprise, le diplôme et le parcours font varier ces repères.
Salaire fixe brut annuel à Paris, hors variable
Junior
0-2 ans
35-46 K€
Confirmé
3-5 ans
42-55 K€
Médian : 49 K€
Senior
6-10 ans
56-72 K€
Expert / Lead
10 ans et +
74-91 K€ et plus
Et après ? Au-delà, un Staff SRE ou un Head of SRE dans une plateforme à fort trafic dépasse souvent le haut du palier Expert. Voir le baromètre des salaires
Paris et régions
En région, la grille recule de 10 à 15 %. L'écart avec Lyon tourne autour de 10 %, celui d'un contrat entièrement à distance autour de 8 %. Le télétravail complet est assez répandu sur ce métier, ce qui rapproche les écarts.
| Niveau | Paris | Hors Paris |
|---|---|---|
| Junior (0-2 ans) | 35-46 K€ | 30-41 K€ |
| Confirmé (3-5 ans) | 42-55 K€ | 36-50 K€ |
| Senior (6-10 ans) | 56-72 K€ | 48-65 K€ |
| Expert / Lead (10 ans et +) | 74-91 K€ et plus | 63-82 K€ et plus |
Junior (0-2 ans)
- Paris
- 35-46 K€
- Hors Paris
- 30-41 K€
Confirmé (3-5 ans)
- Paris
- 42-55 K€
- Hors Paris
- 36-50 K€
Senior (6-10 ans)
- Paris
- 56-72 K€
- Hors Paris
- 48-65 K€
Expert / Lead (10 ans et +)
- Paris
- 74-91 K€ et plus
- Hors Paris
- 63-82 K€ et plus
Ce que disent les salariés sur Glassdoor
Sur Glassdoor, 69 salaires de SRE déclarés à Paris donnent un fixe moyen de 60 K€. La rémunération totale moyenne atteint 65 000 €, et le quart le mieux payé dépasse 71 500 €. Ces chiffres recoupent notre palier Senior.
Astreinte et variable
Le variable pèse peu sur ce métier : prime annuelle sur objectifs, intéressement, parfois des BSPCE en start-up ou des actions chez les éditeurs cotés. L'astreinte ajoute une compensation propre à chaque entreprise, qui compte dans la comparaison de deux offres.
Et en freelance ?
Des missions SRE existent en freelance, surtout pour monter une démarche de fiabilité ou migrer vers Kubernetes. Nous n'avons pas trouvé de tarif journalier moyen publié de façon fiable pour ce métier, donc nous n'en donnons pas.
Sources : grille SRE de notre baromètre, en fixe brut parisien puis écart par région ; Glassdoor, salaires de Site Reliability Engineer à Paris, relevé du 23 octobre 2026.
Comment devenir Site Reliability Engineer
Les formations
Une école d'ingénieurs, un master en informatique ou une école de développement comme Epitech ou 42 mènent au métier. Aucun diplôme ne forme directement au SRE : le poste demande d'avoir déjà vécu la production.
Les passerelles
- DevOps qui veut passer de la chaîne de livraison à la fiabilité du service. C'est la passerelle la plus fréquente sur nos missions.
- Développeur back-end qui a pris goût aux incidents et aux performances.
- Administrateur système qui a appris à coder et à travailler avec Kubernetes et le cloud.
Se former par soi-même
Les livres de Google, gratuits en ligne, donnent la méthode. Les certifications CKA pour Kubernetes et les certifications des grands clouds sont souvent demandées. Rien ne remplace toutefois une première rotation d'astreinte sur un vrai service.
Évolutions de carrière
Un SRE accumule une vision transverse rare : il connaît tous les services et leurs points faibles. Plusieurs voies s'ouvrent après quelques années.
| Voie | Postes | Fixe à Paris |
|---|---|---|
| Expertise | Senior SRE, Staff SRE, Staff Engineer | 74-91 K€ et plus après dix ans |
| Management | Lead SRE, Head of SRE, Engineering Manager | Au-delà de la grille Expert selon la taille de l'équipe |
| Architecture | Architecte infrastructure, architecte cloud | Voir les fiches correspondantes |
| Plateforme | Platform Engineer, Head of Platform | Proche de la grille SRE |
Expertise
- Postes
- Senior SRE, Staff SRE, Staff Engineer
- Fixe à Paris
- 74-91 K€ et plus après dix ans
Management
- Postes
- Lead SRE, Head of SRE, Engineering Manager
- Fixe à Paris
- Au-delà de la grille Expert selon la taille de l'équipe
Architecture
- Postes
- Architecte infrastructure, architecte cloud
- Fixe à Paris
- Voir les fiches correspondantes
Plateforme
- Postes
- Platform Engineer, Head of Platform
- Fixe à Paris
- Proche de la grille SRE
La voie de l'expertise est décrite sur la fiche Staff Engineer, celle de l'architecture sur la fiche Architecte infrastructure. Pour le management, voir Engineering Manager.
SRE, DevOps ou Platform Engineer : les différences
Le livre de Google résume la relation par une formule de développeur : la classe SRE implémente l'interface DevOps. Autrement dit, DevOps décrit une culture, et le SRE en est une mise en pratique avec des règles chiffrées.
| Critère | SRE | DevOps | Platform Engineer |
|---|---|---|---|
| Question centrale | Le service tient-il ses objectifs ? | Le code arrive-t-il vite et sûrement en production ? | Les développeurs ont-ils des outils simples ? |
| Outils typiques | SLO, alertes, post-mortems | CI/CD, conteneurs, Terraform | Portail interne, modèles de déploiement |
| Client principal | L'utilisateur final | Les équipes de développement | Les équipes de développement |
| Astreinte | Au cœur du poste | Fréquente | Plus rare |
Question centrale
- SRE
- Le service tient-il ses objectifs ?
- DevOps
- Le code arrive-t-il vite et sûrement en production ?
- Platform Engineer
- Les développeurs ont-ils des outils simples ?
Outils typiques
- SRE
- SLO, alertes, post-mortems
- DevOps
- CI/CD, conteneurs, Terraform
- Platform Engineer
- Portail interne, modèles de déploiement
Client principal
- SRE
- L'utilisateur final
- DevOps
- Les équipes de développement
- Platform Engineer
- Les équipes de développement
Astreinte
- SRE
- Au cœur du poste
- DevOps
- Fréquente
- Platform Engineer
- Plus rare
Dans une petite entreprise, une seule personne porte souvent les trois casquettes. Les fiches DevOps et Platform Engineer détaillent les deux autres métiers. Notre article sur la méthodologie DevOps revient sur la culture commune.
Les outils d'un Site Reliability Engineer
Sa boîte à outils couvre trois besoins : observer le service, faire tourner l'infrastructure et gérer les incidents. Le choix exact dépend du cloud et de la taille de l'entreprise.
PrometheusCollecter les métriques temps réel, base de l'observabilité moderne
GrafanaDashboards de monitoring, alerting, corrélation logs et métriques
DatadogMétriques, traces, logs, APM dans une seule plateforme
PagerDutyGérer les astreintes, escalades, post-mortems
KubernetesFaire tourner les charges de production avec HPA, PDB, probes
Jaeger / OpenTelemetrySuivre une requête à travers vingt microservices
TerraformProvisionner l'infra de production, gérer les états critiques
SlackSalons incident, runbooks intégrés, statut public
