Que testent vraiment les entretiens DevOps ?

À qui vous parlez vraiment

Pour la plupart des postes DevOps, vous ne rencontrerez pas de recruteur généraliste pour les tours techniques. Après un premier filtrage (souvent un talent partner qui vérifie le préavis, le salaire, le droit de travailler), les personnes qui posent les questions difficiles sont généralement celles avec qui vous travailleriez : un responsable plateforme ou SRE, un ingénieur DevOps senior, parfois le responsable technique qui gère l'astreinte. Dans les environnements réglementés — finance, santé, tout ce qui touche PCI ou SOC 2 — un ingénieur sécurité assiste souvent à au moins un tour, parce que le contrôle d'accès et les pistes d'audit font partie du métier, pas d'une préoccupation annexe.

C'est important parce que ces intervieweurs ont généralement été réveillés à 3h du matin pour quelque chose que vous seriez censé réparer. Ils ne testent pas si vous savez définir « CI/CD » ou lister les services AWS. Ils testent s'ils vous feraient confiance avec un accès production.

L'écran technique : à quoi il ressemble vraiment

La plupart des processus pour ce rôle comprennent l'un de ces trois formats, parfois deux :

Un exercice à faire chez soi ou en direct impliquant une vraie infrastructure cassée. Vous pourriez recevoir un dépôt avec un module Terraform qui échoue à s'appliquer, un Dockerfile qui construit une image de 2 Go alors qu'elle devrait faire 200 Mo, ou un pipeline GitHub Actions/GitLab CI qui passe en local mais échoue dans le runner. On vous demande de le réparer et d'expliquer votre raisonnement, pas seulement de coller un diff fonctionnel. Les intervieweurs font attention à si vous vérifiez la sortie du plan avant d'appliquer, si vous regardez les codes de sortie et les logs avant de deviner, et si vous expliquez pourquoi la correction fonctionne plutôt que le fait qu'elle fonctionne.

Une session de débogage ou de pair programming en direct. Vous partagez votre écran, ils vous donnent un cluster Kubernetes (souvent kind ou minikube) avec un pod bloqué en CrashLoopBackOff, ou un service qui renvoie des 502 derrière un load balancer, et vous expliquez votre diagnostic en temps réel : kubectl describe pod, vérifier les limites de ressources, lire les événements avant de lire les logs, vérifier si c'est l'app ou l'ingress. La valeur est entièrement dans la narration. Le silence pendant que vous tapez est un pire signal qu'une première hypothèse fausse suivie d'une prochaine étape sensée.

Un tour de conception système au tableau ou verbal. Concevoir un pipeline de déploiement pour un service avec une exigence stricte de disponibilité, ou concevoir comment vous déploieriez une migration de schéma sans interruption, ou concevoir la supervision d'un ensemble de microservices. Ceux-ci sont jugés sur les compromis : blue-green versus canary, pourquoi vous choisiriez une politique d'autoscaling plutôt qu'une autre, ce que vous mettriez dans un tableau de bord versus ce sur quoi vous alerteriez, comment vous définiriez un SLO et ce que vous feriez quand le budget d'erreur est épuisé.

Les questions qui sondent vraiment la compétence

Quelques questions reviennent dans presque tous les entretiens DevOps, et chacune a une version qui sépare les gens qui ont fait le travail de ceux qui ont lu à ce sujet.

« Décrivez-moi un incident que vous avez géré. » Une vraie réponse nomme le symptôme, les étapes de diagnostic dans l'ordre, la cause racine réelle, la correction immédiate, et — crucial — ce qui a changé après : une nouvelle alerte, un runbook, un changement dans une porte de déploiement. Elle inclut aussi généralement quelque chose qui a mal tourné dans la réponse elle-même, parce que les incidents se passent rarement proprement. Si l'histoire n'a pas de postmortem ni d'action de suivi, l'intervieweur demandera ce qui a changé, et il faut avoir une réponse.

« Comment gérez-vous les secrets ? » Ils écoutent si vous distinguez entre les secrets dans le contrôle de version (un échec), les secrets dans les variables d'environnement (une réponse partielle), et les secrets récupérés à l'exécution depuis quelque chose comme Vault, AWS Secrets Manager, ou SSM Parameter Store avec des rôles IAM scopés et rotation. Points bonus, sans qu'on le demande, pour mentionner comment vous roteriez une credential déjà divulguée, parce que c'est la question derrière la question.

« Quelle est la différence entre votre supervision et vos alertes ? » Cela teste si vous pensez en SLI et SLO ou juste en tableaux de bord. Une bonne réponse sépare ce que vous regarderiez pendant une investigation (métriques, traces, logs — idéalement nommés : Prometheus/Grafana, Datadog, la stack ELK ou Loki) de ce qui devrait vraiment réveiller quelqu'un, et explique pourquoi la fatigue d'alertes est un échec de conception, pas une fatalité.

« Comment feriez-vous un rollback ? » Posée sur presque n'importe quel scénario de déploiement. La réponse nécessite un mécanisme concret — un tag d'image précédent, une révision Helm, une migration de base de données réversible ou au moins compatible vers l'avant — pas « on redéploierait juste l'ancienne version », qui suppose que l'ancienne version est encore compilable et que le rollback lui-même ne cassera rien d'autre.

« Pourquoi Terraform/Ansible/Puppet plutôt que l'alternative ? » Moins sur l'outil et plus sur si vous comprenez la gestion d'état déclarative versus impérative, ce qu'est la dérive, et comment vous la détectez et la réconciliez. Si votre équipe utilise GitOps (ArgoCD, Flux), attendez-vous à une question sur ce qui se passe quand quelqu'un change quelque chose directement dans le cluster au lieu de passer par Git, parce que c'est la friction quotidienne réelle du modèle.

À quoi ressemble une réponse superficielle

Pour quelqu'un qui fait ce métier, une réponse superficielle a une forme spécifique. Elle nomme des outils sans nommer une décision : « nous utilisions Kubernetes et Terraform et Jenkins » ne dit rien à l'intervieweur sur ce que vous avez réellement choisi ou pourquoi. Elle saute le mode d'échec : décrire un processus de déploiement sans mentionner ce qui se passe quand il échoue, ou une configuration de supervision sans mentionner ce que vous ne surveillez pas actuellement. Elle traite « je le redémarrerais » comme un diagnostic plutôt qu'un palliatif — redémarrer un pod peut effacer un symptôme, mais si vous ne pouvez pas dire ce qui a causé le crash, l'intervieweur sait que vous seriez de retour à 3h du matin à le refaire. Et elle répond aux questions de conception système avec une seule architecture et aucune alternative considérée, ce qui se lit comme avoir mémorisé un diagramme plutôt qu'avoir pesé des compromis sur un vrai système avec de vraies contraintes — coût, taille de l'équipe, outillage existant.

L'inverse est aussi vrai et vaut la peine d'être connu : sur-expliquer chaque acronyme, ou réciter une définition de manuel du déploiement blue-green quand on vous demande comment vous déploieriez un service spécifique, se lit de la même façon. L'intervieweur veut votre raisonnement appliqué à son scénario, pas un cours général.

Que faire avant l'entretien

Revenez sur vos deux ou trois derniers vrais incidents, migrations ou changements d'infrastructure et écrivez, dans l'ordre : symptôme, étapes de diagnostic, correction, et ce qui a changé après. Si vous ne pouvez pas remplir la dernière partie, ça vaut la peine de le remarquer avant l'entretien, pas pendant.

Si l'annonce du poste mentionne des outils spécifiques — Terraform plutôt que Pulumi, EKS plutôt que Kubernetes auto-géré, Datadog plutôt que Prometheus open-source — vérifiez honnêtement votre propre expérience par rapport à cette stack. Quand vous avez utilisé l'équivalent mais pas l'outil exact, dites-le et expliquez la correspondance ; les intervieweurs respectent généralement « j'ai utilisé Chef, pas Puppet, mais le modèle est le même » bien plus qu'une vague prétention de familiarité qui s'effondre à la première question de suivi.

Et si vous envoyez un grand volume de candidatures et n'entendez rien, ça vaut la peine de vérifier si les exigences spécifiques de l'annonce apparaissent assez tôt dans votre CV pour vous amener à ce stade — l'entretien teste seulement ce que vous savez déjà ; il ne peut pas réparer un CV qui enterre l'expérience Kubernetes et Terraform que l'annonce demandait en page deux.