Entretien DevOps / SRE : questions et préparation

L’entretien DevOps / SRE ne ressemble à aucun autre entretien technique. On ne te demande pas seulement si tu connais Kubernetes ou Terraform : on veut savoir comment tu raisonnes quand la production tombe, comment tu arbitres entre vélocité et fiabilité, et si tu sais transformer un incident en apprentissage. Ce guide passe en revue les questions entretien DevOps / SRE les plus fréquentes, les pièges classiques et la méthode pour préparer des réponses solides et chiffrées.

Les questions fréquentes en entretien DevOps / SRE

Ces questions ouvrent presque tous les entretiens. Elles servent à cartographier ton expérience et ta façon de penser un système.

« Explique ta pipeline CI/CD idéale, du commit jusqu’à la production. » Le recruteur veut voir si tu maîtrises l’enchaînement complet : build, tests automatisés, analyse de sécurité, artefacts, déploiement progressif (canary, blue-green), rollback. Ne récite pas une liste d’outils. Décris les étapes, les garde-fous à chaque étape et ce qui déclenche un retour arrière.

« Comment construis-tu une stratégie d’observabilité ? » On attend les trois piliers : logs, métriques, traces. Montre que tu sais relier un symptôme utilisateur à une cause technique. Le bon réflexe : partir du parcours utilisateur, définir ce que tu dois mesurer, puis instrumenter — pas l’inverse.

« Quelle est la différence entre un SLI, un SLO et un SLA ? » C’est la question la plus discriminante de l’entretien SRE. Le SLI est la mesure (ex. taux de requêtes en moins de 300 ms). Le SLO est la cible interne que tu vises (ex. 99,9 % sur 30 jours). Le SLA est l’engagement contractuel envers le client, souvent assorti de pénalités. Confondre les trois te disqualifie immédiatement auprès d’un interlocuteur SRE expérimenté.

« Comment réduis-tu le toil ? » Le toil, c’est le travail manuel, répétitif et sans valeur durable. Montre que tu sais l’identifier, le mesurer et l’automatiser pour libérer du temps d’ingénierie.

Questions comportementales (méthode STAR)

Les questions comportementales pèsent autant que la technique. Sur un poste d’astreinte, l’équipe veut savoir comment tu te comportes sous pression. Structure chaque réponse avec la méthode STAR pour structurer tes réponses : Situation, Tâche, Action, Résultat.

« Raconte-moi un incident majeur que tu as géré. » C’est la question reine. Choisis un incident réel avec un vrai enjeu. Pose le contexte (quel service, quel impact utilisateur), ta responsabilité, puis le déroulé précis : détection, mitigation, communication, résolution. Termine toujours par le résultat chiffré et le post-mortem : MTTR réduit, cause racine identifiée, action de prévention mise en place.

« Décris un désaccord avec une équipe de développement. » Le poste DevOps / SRE vit à la frontière dev-ops. On teste ta capacité à dire non à un déploiement risqué sans bloquer la vélocité. Montre que tu argumentes avec des données (budget d’erreur consommé, historique d’incidents), pas avec de l’autorité.

« Parle-moi d’une fois où tu as automatisé quelque chose qui t’a fait gagner du temps. » Quantifie : combien d’heures d’astreinte économisées, combien d’erreurs humaines évitées. Le résultat chiffré transforme une anecdote en preuve de valeur.

Questions techniques

Le cœur de l’entretien. Le niveau d’exigence dépend de la séniorité visée, mais les thèmes reviennent toujours.

« Comment dimensionnes-tu et sécurises-tu un cluster Kubernetes en production ? » Aborde les ressources (requests/limits), l’autoscaling (HPA, cluster autoscaler), la résilience (réplication, pod disruption budgets), et la sécurité (RBAC, network policies, secrets). On ne te demande pas toutes les commandes kubectl par cœur, mais une compréhension opérationnelle et des arbitrages assumés.

« Infrastructure as Code : comment structures-tu tes modules Terraform ? » Parle de modularité, de gestion d’état (state remote, verrouillage), d’environnements isolés et de revue de plan avant apply. Le recruteur cherche quelqu’un qui traite l’infra comme du code : versionné, testé, revu.

« Comment debugges-tu une latence qui grimpe en production ? » Décris ta démarche méthodique : tu pars des métriques et des traces, tu isoles le maillon (réseau, base de données, application, dépendance externe), tu formules une hypothèse, tu la valides. Ce qu’on évalue, c’est ta capacité à raisonner sous incertitude, pas à deviner la bonne réponse du premier coup.

Selon le poste, tu peux aussi tomber sur des questions de scripting, de réseau (DNS, load balancing, TLS) ou de sécurité — pour ce dernier point, l’entretien ingénieur cybersécurité recoupe utilement le périmètre SRE. Si ton profil penche côté applicatif, les questions entretien développeur back-end complètent bien ta préparation.

Les pièges à éviter

Réciter des outils sans expliquer pourquoi. Citer dix technologies ne prouve rien. À chaque outil, le recruteur attend : pourquoi ce choix, quelles limites, que fais-tu quand il tombe ? Un outil maîtrisé vaut mieux que dix survolés.

Oublier le facteur humain de l’incident. Le DevOps / SRE n’est pas qu’une affaire de machines. Si tu décris un post-mortem en cherchant un coupable, c’est rédhibitoire. La culture attendue est blameless : on corrige le système, pas les personnes.

Sous-estimer les questions de fiabilité côté SRE. Beaucoup de candidats arrivent en pensant « DevOps = outils ». Sur un poste SRE, l’absence de réflexe SLO, budget d’erreur et gestion d’astreinte se voit en deux questions.

Se laisser déborder par le stress de l’astreinte simulée. Certains entretiens te mettent en situation d’incident fictif pour observer ta réaction. Garde une démarche structurée même quand la question est volontairement vague — apprends à gérer le stress en entretien pour rester clair sous pression.

Comment te préparer

La préparation d’un entretien DevOps / SRE tient en trois chantiers.

Solidifie tes fondamentaux. Linux, réseau, CI/CD, conteneurs, orchestration, IaC, observabilité : tu dois pouvoir expliquer chaque brique simplement, avec un exemple concret tiré de ton expérience. La clarté d’explication compte autant que la profondeur.

Prépare tes histoires d’incidents. Identifie 4 à 5 situations réelles (incident majeur, automatisation marquante, désaccord tranché, migration risquée) et structure-les en STAR avec des résultats chiffrés. Ce sont elles qui feront la différence sur les questions comportementales.

Entraîne-toi à voix haute, en conditions. Savoir une réponse dans sa tête ne suffit pas : il faut la dérouler clairement, à l’oral, sans tics ni hésitation. Avec PitchBrew, tu peux passer l’entretien blanc avant le vrai : tu charges ton CV et l’offre, tu choisis l’étape (Filtre initial, Entretien technique, Entretien managérial, Fit & Valeurs), et tu reçois un Rapport avec un score sur 100 et tes axes prioritaires. C’est le meilleur moyen de t’entraîner en conditions réelles avec PitchBrew avant de passer le vrai entretien.