Le métier de Site Reliability Engineer

Culture de la fiabilité et SLO

La compétence fondatrice du métier. Le SRE pense en SLO, SLI, error budget.

Il sait construire un SLO réaliste à partir des attentes utilisateur. Pas du 99,99% partout, mais 99,9% sur le chemin critique et 99% sur les fonctionnalités secondaires.

Il sait calculer un error budget mensuel et négocier avec les équipes produit l'utilisation de ce budget. Quand on consomme 80% du budget en deux semaines, on gèle les déploiements et on stabilise.

Cette culture vient des SRE Books de Google. Beaucoup de boîtes en parlent, peu l'appliquent vraiment.

Le SRE qui sait l'incarner dans une boîte qui n'a pas la culture devient un atout stratégique. C'est plus politique que technique.

Observabilité avancée

Trois piliers à maîtriser. Métriques avec Prometheus et son écosystème, Thanos pour le long terme, Cortex ou Mimir pour le multi-tenant.

Logs avec Loki, Elastic, ou Datadog. Tracing distribué avec Jaeger, Tempo, ou OpenTelemetry collector.

Le SRE sait quand utiliser quoi. Une métrique pour mesurer un taux d'erreur global.

Un log pour comprendre le détail d'une requête échouée. Une trace pour suivre une requête à travers quinze microservices et trouver le service lent.

La compétence réelle se mesure à la capacité de débugger un incident à 3h du matin avec ces outils. Pas à savoir les installer.

Beaucoup d'ingénieurs déploient Prometheus sans savoir tirer une analyse utile sous pression.

Incident response et post-mortems

Le SRE anime l'incident. Quand la prod casse, c'est lui qui prend la coordination.

Salon Slack dédié, identification du commander, séparation entre investigation et communication, mise à jour de la page de statut publique. Le métier exige du sang-froid.

Un incident SEV1 dans une boîte SaaS B2B coûte de l'argent par minute. La pression monte vite.

Après l'incident, post-mortem sans blame. Timeline reconstituée, root cause analysis avec 5 whys ou fishbone, plan d'action concret avec owners.

Le SRE qui anime des post-mortems honnêtes installe une culture saine. Celui qui cherche des coupables casse la culture en six mois.

Cette compétence ne s'apprend pas en formation. Elle se forge en gérant des dizaines d'incidents.

Code et compréhension produit

Un SRE doit savoir coder. Pas au niveau d'un senior backend, mais assez pour lire le code des services qu'il opère, écrire des outils internes, contribuer aux applis pour les rendre opérables.

Python, Go, Bash dominent. Le SRE doit aussi comprendre le métier de la boîte.

Un SRE sur une plateforme de paiement raisonne différemment d'un SRE sur un SaaS de gestion de projet. Les contraintes ne sont pas les mêmes : PCI DSS pour le premier, performance pure pour le second.

Le SRE qui apprend les enjeux business gagne en pertinence. Il sait prioriser les SLO selon l'impact réel sur les clients, pas selon des conventions abstraites.

Les parcours classiques

Pas de cursus SRE dédié en France. La majorité des SRE viennent du DevOps, du développement backend, ou de l'administration système.

Les écoles d'ingénieurs forment souvent des candidats sérieux : Telecom Paris, INSA, EPITA, Polytech. Mais le titre de SRE ne s'attribue qu'après plusieurs années de pratique production.

Les certifications utiles incluent CKA et CKS pour Kubernetes, Prometheus Certified Associate, certifications cloud orientées opération. La référence culturelle reste les SRE Books de Google, lecture obligatoire pour tout candidat sérieux.

Le SRE Workbook complète la théorie par des cas concrets. Beaucoup de boîtes demandent en entretien si le candidat les a lus.

Mentir là-dessus se voit en cinq minutes de discussion technique.

Combien d'années avant d'y prétendre ?

Sur Paris en 2026, on ne recrute pas de SRE junior. Le marché demande quatre à six ans minimum, dont au moins deux ans à gérer de la production sous contrainte.

Pour le titre de SRE confirmé, comptez cinq à sept ans. Pour le senior, huit ans et plus.

Le métier exige une maturité face à la pression que les juniors n'ont pas développée. Gérer un incident SEV1 à 4h du matin sans paniquer, ça demande de l'expérience.

Les recruteurs filtrent dur sur ce point. Une seule expérience d'astreinte sérieuse pèse plus que trois certifications.

Les candidats sans expérience d'astreinte se voient proposer du DevOps ou du Platform, pas du SRE.

Les passerelles depuis le backend

La passerelle la plus solide. Un dev backend senior qui a passé trois ans sur un service avec du vrai trafic bascule SRE en six à douze mois.

Il connaît déjà le code, les pièges des systèmes distribués, les patterns de résilience. Il apprend l'infra et l'observabilité.

Sa connaissance code reste un atout face aux SRE issus pure ops. Quand un service plante, il sait lire le stack trace, comprendre la mémoire, raisonner sur les goroutines bloquées.

Beaucoup de SRE des grandes boîtes tech viennent de ce chemin. Le salaire passe en général de 70K à 80K, parfois 85K, sur la transition.

Pour un dev senior qui veut sortir du code pur, c'est l'une des évolutions les plus rentables du marché.

Reconversion possible ?

La reconversion vers SRE pure depuis l'extérieur de la tech reste très difficile. Le métier exige trop de prérequis : cloud, code, systèmes distribués, culture incident.

Pour un sysadmin Linux expérimenté, comptez deux ans de bascule progressive vers cloud puis SRE. Pour un dev web avec peu d'expérience prod, un à deux ans pour atteindre un niveau juste suffisant.

Les bootcamps SRE n'existent pas vraiment en France. Quelques formations ponctuelles chez OctoPerf, Octo Technology, ou en interne dans les grandes scale-ups.

Le métier se transmet plus en compagnonnage qu'en formation. Trouver un mentor SRE confirmé dans sa boîte actuelle accélère plus que n'importe quel cursus payant.