L4 / IC3 · 3 à 6 ans
Préparation entretien Site Reliability Engineer, ce qui vous attend
Si vous préparez un process SRE (en France les postes s'affichent aussi sous « SRE » ou « Ingénieur DevOps »), attendez-vous à un cadrage très orienté systèmes : moins de coding algorithmique pur que pour un SWE, et davantage de debugging, d'observabilité et d'exploitation en production. La barre, ce n'est pas seulement savoir construire un système distribué complexe, c'est savoir le garder debout.
Un process SRE L4 typique se déroule ainsi : pré-screen recruteur, un round de coding (souvent un mix algos et scripting / systèmes), un round de debugging en live, un round de system design centré fiabilité (multi-région, observabilité, modes de défaillance), puis un comportemental avec le hiring manager. Les loops FAANG enchaînent 5 à 7 rounds et restent proches de la barre coding SWE ; les scale-ups françaises compressent souvent à 3 ou 4 rounds avec plus de discussion ouverte.
La barre L4, c'est porter la santé opérationnelle d'un service ou d'un sous-système : rotation d'astreinte, gestion d'incident, observabilité, automatisation.
Version personnalisée
Ce guide couvre la barre générale pour SRE. L'extension Chrome applique la même préparation à chaque offre que vous ouvrez, questions prédites pour cette entreprise précise, entraînement vocal avec votre coach IA sur chaque réponse, benchmark de salaire, analyse des écarts, plus brouillons de lettre de motivation et d'auto-présentation. Premier rapport gratuit ; plans payants à partir de 3,99 $. Ou lancez un scan unique sur une offre, sans installer.
Mise à jour 2026
Ce guide couvre la barre générale pour SRE. Quelques choses ont changé en France en 2026, l'AI Act encadre le recrutement IA à partir du 2 août, 31 % des candidats utilisent déjà l'IA pour préparer (APEC), les mises en situation remplacent les tests classiques, et le cycle de recrutement reste à 12 semaines. Lire ce qui a changé en 2026 →
Ce qui sera attendu de vous
- Porter la fiabilité d'un service ou d'un sous-système : définir les SLO, construire l'observabilité, faire baisser le toil
- Participer aux rotations d'astreinte et piloter la réponse à incident quand le pager sonne
- Écrire de l'infrastructure-as-code de qualité production (Terraform, Pulumi, manifests Kubernetes) et automatiser les opérations manuelles
- Travailler avec les équipes produit sur les décisions d'architecture qui touchent à la fiabilité
- Rédiger les postmortems et mener les actions de remédiation jusqu'au bout
- Améliorer les pipelines CI / CD, la sécurité de déploiement et les mécanismes de rollback de votre service
Process d'entretien typique
La plupart des entreprises suivent une trame similaire pour les entretiens SRE. Délai calendaire total : 4 à 6 semaines du pré-screen recruteur jusqu'à l'offre.
Questions types à anticiper
Représentatives de ce que les entreprises demandent à ce niveau, pas une liste exhaustive. Lancez le scan gratuit ci-dessus pour des questions prédites liées à une offre d'emploi précise. L'extension Chrome ajoute l'entraînement vocal avec coaching IA sur chaque réponse (technique, design système, comportemental, motivation).
- “La p99 d'un service vient de doubler, sans corrélation évidente avec un déploiement. Détaillez vos 15 premières minutes : par où vous commencez et pourquoi.”
- “À partir d'un flux de lignes de log structurées, expliquez comment vous calculeriez le taux d'erreur par endpoint sur une fenêtre glissante de 5 minutes. Choisissez votre langage ; dites ce qui change à 100k événements par seconde.”
- “Implémentez un rate limiter sous forme de classe en Python. Puis expliquez comment vous l'étendriez pour gérer un rate-limiting distribué sur 50 instances du service.”
- “Designez la stack d'observabilité d'une architecture microservices à 100 services. Couvrez métriques, logs, traces et le framework de SLO.”
- “Designez un système de déploiement qui permet aux équipes de livrer en prod 50 fois par jour sans casse. Couvrez canaries, rollbacks, feature flags et l'histoire du blast radius.”
- “Designez un service actif-actif multi-région avec une p99 sous 100 ms. Détaillez la réplication, le failover et ce qui lâche quand une région tombe.”
- “Parlez-moi d'un incident dont vous avez piloté la réponse. Déroulez détection, diagnostic, mitigation, postmortem.”
- “Décrivez une fois où vous avez tenu tête à une équipe produit qui voulait livrer un truc que vous jugiez dangereux. Comment la discussion s'est passée ?”
- “Parlez-moi d'une situation à fort toil dans un poste précédent. Qu'avez-vous fait pour le réduire ?”
Benchmark de salaire
Salaire médian pour SRE dans les grandes boîtes tech US, chiffres principaux en USD. Paris / Berlin / Singapour paient typiquement 30 à 50 % de moins en base ; les ratios d'equity varient selon le stade de l'entreprise.
Chez les FAANG, la total comp d'un SRE L4 au 50e percentile tourne autour de 260–340 k$. Le SRE suit généralement la grille SWE au même level, parfois avec une petite prime là où c'est une filière distincte (Google, où le SRE est une voie à part entière). À Paris, un SRE mid se situe plutôt vers 55–75 k€ de base selon l'employeur (OVHcloud, Scaleway, Datadog, Doctolib, Criteo, Qonto, BlaBlaCar), l'astreinte étant souvent indemnisée à part. Gardez le chiffre US comme benchmark, pas comme attente locale.
Comment se préparer, cinq conseils tactiques
Ouvrez vos réponses comportementales avec la méthode STAR, Situation, Tâche, Action, Résultat. Les conseils tactiques ci-dessous s'appuient sur cette structure pour ce rôle précis.
- Faites 50+ LeetCode mediums centrés sur hashmaps, graphes et flux : la barre coding SRE est plus proche du SWE que du Data Engineer
- Lisez le Google SRE Book (gratuit en ligne) de bout en bout, c'est la langue commune des entretiens SRE et il est cité directement par les intervieweurs
- Entraînez-vous à lire vite les logs et les métriques. Montez une stack Prometheus + Grafana en local et cassez des choses exprès pour bâtir l'intuition de debugging
- Maîtrisez à fond un outil d'IaC (Terraform ou Pulumi) et un orchestrateur de conteneurs (Kubernetes) au niveau « je pourrais écrire les manifests de zéro »
- Préparez 5 à 6 récits STAR avec des détails d'incident concrets : temps de détection, temps de mitigation, périmètre d'impact, ce qui a changé au postmortem
Les pièges fréquents au niveau SRE
Quelques erreurs fréquentes qui font recaler les candidats SRE même quand ils sont par ailleurs solides. Mieux vaut les repérer en mock interview avant qu'elles n'apparaissent en vrai.
Designer une solution de fiabilité sans jamais nommer les SLO, les error budgets ou ce que veut dire « assez bon ».
Pourquoi ça rate
Le system design SRE est noté explicitement sur votre capacité à raisonner la fiabilité comme un budget, pas comme un absolu. « Cinq neufs » n'est pas une réponse ; la réponse, c'est « trois neufs de dispo, p99 à 200 ms, error budget de X minutes par trimestre, voilà comment on le dépense ». Un candidat qui designe pour 100 % d'uptime donne l'impression de ne pas penser en termes de SLO.
Comment rattraper
Ouvrez chaque design de fiabilité en nommant les SLO que vous viseriez et pourquoi. Puis cadrez les trade-offs face à l'error budget : « si on consomme la moitié du budget sur ce lancement de feature, il faut verrouiller tout le reste ce trimestre. » Le cadrage SLO, c'est ça le signal SRE.
Aborder le round de debugging en devinant les causes au lieu de formuler des hypothèses à partir des données.
Pourquoi ça rate
Les rounds de debugging au niveau SRE notent si vous lisez le signal avant de sauter sur une cause. Lancer « c'est sûrement la base de données » sans regarder les métriques, les logs ou les changements récents donne l'image de quelqu'un qui perdrait une heure pendant un vrai incident à courir après la mauvaise piste. Le réflexe senior, c'est : vérifier le signal évident d'abord (déploiements, dashboards, taux d'erreur par endpoint), puis resserrer.
Comment rattraper
Structurez vos réponses de debugging comme une checklist : qu'est-ce qui a changé récemment (déploiements, config), où le signal est-il le plus net (quel endpoint, quelle région, quelle version), qu'est-ce qui réfuterait chaque hypothèse. Même une ou deux minutes de triage structuré au début montrent à l'intervieweur que vous avez vécu de vrais incidents.
Décrire son astreinte passée par « je réponds aux pages et je règle les soucis », sans aucun détail d'incident précis.
Pourquoi ça rate
Les intervieweurs SRE calibrent contre l'ownership d'incident. Une description d'astreinte générique ne leur dit rien. « On a eu une panne de 40 minutes le mois dernier : l'alerte a sonné à 02h14, j'ai diagnostiqué à 02h28 via le dashboard de request-rate, mitigé en basculant sur la région us-east-2, et le RCA du lendemain a pointé un push de config » leur permet de vous situer tout de suite.
Comment rattraper
Pour vos 3 ou 4 meilleurs récits d'incident, accrochez quatre chiffres : temps de détection (quand l'alerte a sonné), temps de diagnostic (quand vous avez identifié le problème), temps de mitigation, et périmètre d'impact (utilisateurs touchés, manque à gagner, SLA cassé). Des chiffres approximatifs valent mieux que pas de chiffres.
Ressources recommandées
Livres, cours et outils qui reviennent le plus dans la préparation SRE. Sans lien d'affiliation.
- 01Google SRE Book →La référence canonique, gratuite en ligne. Lisez les chapitres 3 (Embracing Risk), 4 (SLOs) et 14 (Managing Incidents) avant tout process SRE.
- 02Google SRE Workbook →Le pendant pratique du SRE Book. Le chapitre 2 (SLOs) et le chapitre 9 (Incident Response) sont les plus rentables.
- 03Brendan Gregg, Systems Performance →La référence pour le round de debugging et d'analyse de performance. Les internes de Linux à la profondeur utile pour un SRE.
- 04Documentation Kubernetes →À pratiquer jusqu'à savoir écrire les manifests de zéro. La plupart des stacks SRE françaises (Doctolib, Qonto, BlaBlaCar) tournent sur K8s.
- 05Documentation Terraform →L'outil d'IaC attendu sur la quasi-totalité des postes. Sachez raisonner state, modules et plan / apply, pas juste copier des exemples.
Scénarios courants
Je suis admin sys / DevOps dans une ESN (Capgemini, Sopra Steria, Devoteam) depuis 5 ans, surtout sur du Ansible, des pipelines GitLab CI et de l'astreinte infra. Comment je passe SRE dans une scale-up (Qonto, BlaBlaCar, Doctolib) alors que je n'ai jamais fait de LeetCode ?
C'est la transition SRE la plus courante en France, et le piège est toujours le même : le round de coding. Beaucoup de profils admin sys / DevOps arrivent en pensant « SRE = bash + Terraform + Kubernetes » et se font filtrer au coding screen, qui est bien plus proche de la barre SWE que du scripting d'ops. Votre force, c'est l'infra : Ansible, GitLab CI, l'astreinte, vous connaissez. Votre angle mort, c'est l'algo. Comptez 6 à 10 semaines de prep : 50+ LeetCode mediums centrés sur hashmaps, graphes et manipulation de flux (le scripting de log que vous faites déjà aide pour cette partie). En parallèle, structurez le vocabulaire qui vous manque côté méthode SRE : SLO, error budget, blast radius, le Google SRE Book est fait pour ça et il est cité directement en entretien. Côté system design, vous partez avec un avantage réel : vous avez vu de la prod, des pannes, des migrations. Présentez-le, mais reformulez en langage fiabilité plutôt qu'en langage exploitation pure.
On me dit que le round de coding SRE est « light » par rapport au SWE. C'est vrai ? Je viens de l'ops et j'ai peur de me planter là-dessus.
C'est une idée reçue qui coûte des offres. Sur la plupart des loops SRE sérieux (filiales FAANG en France, Datadog, Criteo, scale-ups bien financées), le coding round est au niveau LeetCode-medium, parfois doublé d'une question systèmes du type « parse ce format de log et calcule un taux d'erreur en fenêtre glissante ». Ce n'est pas un quiz bash. La nuance, c'est qu'on attend du code propre et raisonné, pas la résolution de problèmes algos exotiques façon concours, mais un profil ops qui n'a jamais ouvert LeetCode se fait quand même filtrer. Si vos missions actuelles sont à 70 % de la config et du YAML, comptez large, 10 semaines et plus. Drillez en priorité les structures de données que le scripting de log mobilise naturellement (hashmaps, files, tableaux), puis élargissez. Et entraînez-vous à coder en parlant à voix haute : sur un round SRE comme SWE, le raisonnement narré compte autant que la réponse.
L'offre SRE mentionne de l'astreinte « rémunérée » et un roulement. À quoi je dois m'attendre concrètement en France, et qu'est-ce qu'on attend de moi en entretien là-dessus ?
En France, l'astreinte est encadrée par le Code du travail et la convention collective (souvent Syntec) : elle est en principe indemnisée, et les interventions de nuit ou de week-end comptent comme du temps de travail. Concrètement, attendez-vous à un roulement (par exemple une semaine sur quatre ou cinq selon la taille de l'équipe), un pager, et des objectifs de temps de réponse. En entretien, le hiring manager veut surtout savoir si vous avez déjà vécu une vraie nuit d'astreinte : une alerte à 2h, un diagnostic sous pression, une mitigation, un postmortem le lendemain. Préparez 2 ou 3 récits d'incident avec des chiffres précis (heure de l'alerte, temps de diagnostic, temps de mitigation, périmètre touché). C'est aussi le bon moment, côté candidat, pour poser vos propres questions : fréquence du roulement, volume d'alertes par semaine, politique sur le toil. Une équipe SRE saine sait répondre sans gêne ; une équipe qui élude le sujet vous dit quelque chose.
Je suis développeur backend (Java / Go) dans une boîte produit française et je veux basculer vers un poste SRE. Mon coding est solide, mais je n'ai jamais porté d'astreinte. C'est rédhibitoire ?
Non, et vous partez même avec une bonne moitié du chemin faite. La transition SWE vers SRE a le profil inverse de la transition ops vers SRE : vous tenez le coding round sans souci, mais vous devez construire l'intuition fiabilité et opérationnelle. Les intervieweurs vont chercher ça précisément. Avant le loop, ancrez le vocabulaire et les réflexes : SLO et error budget (le Google SRE Book, chapitres 3 et 4), modes de défaillance, blast radius, le déroulé détection / diagnostic / mitigation / postmortem. Côté pratique, montez une stack Prometheus + Grafana en local, cassez votre propre service exprès et entraînez-vous à lire les métriques sous contrainte de temps : c'est exactement le round de debugging. Pour le behavioral, même sans astreinte formelle, vous avez sûrement géré des bugs en prod, des déploiements ratés, des rollbacks : reformulez ces histoires en langage incident. Et apprenez un outil d'IaC à fond (Terraform) plus Kubernetes au niveau manifests, c'est l'autre attendu où un backend pur peut être un peu juste.
Questions fréquentes
Je suis actuellement Software Engineer (L3 / IC2). Dois-je lire ce guide ou celui de Software Engineer en premier ?
Lisez d'abord le guide Software Engineer. Les entreprises calibrent les candidats L4 / IC3 contre la barre L3 / IC2, en ciblant clairement l'écart de scope, elles veulent voir où vous êtes aujourd'hui, puis creuser le gap jusqu'au L4 / IC3. Lisez ce guide APRÈS avoir compris la baseline L3 / IC2, comme ça vous saurez exactement quels signaux démontrer pour le step-up.
Combien de temps prévoir avant un onsite SRE ?
Le process prend 4 à 6 semaines du pré-screen à l'offre. Ajoutez 6 à 8 semaines de prep : LeetCode mediums, le Google SRE Book et un deep-dive observabilité sont les plus rentables. Ne sous-estimez surtout pas le round de coding.
Quelle est l'erreur la plus fréquente des candidats au niveau SRE ?
Sous-investir le round de coding. Beaucoup de profils venus de l'admin sys / DevOps ont d'excellentes compétences infra mais se font filtrer au coding screen parce qu'ils ont cru que SRE = bash + Terraform. La barre coding est plus proche du SWE que du DevOps : drillez les LeetCode mediums pendant 4 semaines au minimum.
Et si mon process d'entretien diffère de celui décrit ici ?
L'essentiel de la variation est marginal. Les grandes boîtes tech (FAANG, scale-ups, SaaS mid-size) suivent un process à 1–2 rounds près de ce qui est décrit. Les petites startups tournent souvent sur moins de rounds (3 à 4) mais la barre par round reste similaire ; les boîtes moins matures tech sautent parfois system design ou comportemental. Lisez l'offre et demandez au recruteur lors du pré-screen, il vous dira ce qui vient.
Comment ce guide se compare-t-il au scan gratuit ?
Ce guide couvre la barre générale au niveau L4 / IC3. Le scan gratuit lit votre offre d'emploi spécifique et renvoie les questions prédites pour ce poste + cette entreprise, un benchmark de salaire calibré et (avec votre CV) une analyse des écarts d'expérience et un passage ATS de CV. PDF par e-mail.
Prêt à préparer un vrai poste ?
Collez n'importe quelle offre SRE, découvrez votre coach en moins de 30 secondes.
Déposez une URL LinkedIn, Greenhouse, Lever ou Levels.fyi, ou collez le texte de l'offre. Votre coach prédit les questions pour cette entreprise, fait ressortir vos écarts d'expérience, et calibre un benchmark de salaire pour le poste et la localisation. PDF par e-mail. L'entraînement vocal avec retour IA sur chaque réponse vit dans l'extension Chrome.
Installation libre · Aperçu sur chaque offre · Plans payants à partir de 3,99 $