Entretien blanc DevOps Engineer — pratique avec l'IA

Les entretiens DevOps sont trompeusement larges. Les recruteurs cherchent un généraliste capable de tenir un module Terraform d'une main et un runbook de l'autre — et ils sonderont précisément les instants où l'infrastructure se heurte à la réalité. La plupart des candidats perdent des points non pas sur la trivia des outils, mais sur les questions de second ordre : « l'apply a expiré, que faites-vous ensuite ? » Ce guide explique comment utiliser les entretiens blancs IA pour répéter les conversations qui décident des offres DevOps.

Les tours d'entretien typiques pour les DevOps engineers

Un loop DevOps typique compte quatre ou cinq tours. Screening recruteur pour le fit, puis un screening technique (45–60 minutes) couvrant CI/CD, infra-as-code, les bases des conteneurs et un deep-dive sur un cloud provider. Vient ensuite un tour scénario ou incident — vous déroulez une vraie panne et comment vous la débuggeriez. Puis un tour de coding ou scripting (Bash, Python ou Go — généralement parser des logs, écrire un petit CLI ou réparer un pipeline cassé) et un tour behavioral plus systèmes où on vous remet une architecture à moitié cassée et on vous demande de la durcir.

Le tour scénario est celui où les entretiens blancs IA rapportent le plus. Les vrais recruteurs improvisent — ils inventent la panne, poussent sur votre raisonnement et vous appâtent vers des conclusions hâtives. L'entretien blanc IA reproduit ce schéma fidèlement : énoncé ouvert, relances qui montent en pression, notation sur votre façon de réduire les causes. Le tour de coding est mieux servi par une pratique de scripting concrète, mais les explications verbales d'échecs de pipeline ont parfaitement leur place dans un entretien blanc IA.

Les principaux sujets techniques

Infrastructure as code

Terraform domine le vivier d'annonces. Soyez prêt à parler de la gestion du state file (remote backends, locking, découpage du state par environnement), du design de modules (quand composer, quand inliner), de la différence entre count et for_each, et de comment refactorer un root module monolithique sans casser la production. Pulumi et CDK apparaissent dans 15 à 20 % des annonces — connaissez le compromis (vrai langage vs HCL déclaratif) même si vous ne l'écrivez pas au quotidien. Les questions Ansible apparaissent encore pour les rôles de config-management ; attendez-vous à l'idempotence des playbooks et à l'inventaire dynamique.

Kubernetes

La barre a monté. « J'ai utilisé kubectl » ne suffit plus. Attendez-vous à : comment un pod est scheduled, ce qui se passe quand un node passe NotReady, pourquoi votre service renvoie des 502 (indice : endpoint absent de l'objet Endpoints), la différence entre requests et limits et ce qui évince un pod, quand vous utiliseriez un DaemonSet plutôt qu'un Deployment, comment les rolling updates interagissent avec les PodDisruptionBudgets. Les loops senior ajoutent les operators, les custom controllers et les admission webhooks. Si vous savez croquer le control plane sur une serviette et expliquer ce que contient etcd, vous avez une longueur d'avance.

Pipelines CI/CD

GitHub Actions, GitLab CI et Jenkins sont les trois plus courants. Attendez-vous à des questions sur les stratégies de cache, l'exécution de tests en parallèle, la gestion des secrets à l'intérieur des pipelines, et comment fail fast sur un build de 20 minutes. Un scénario favori : « le deploy job réussit mais les nouveaux pods crashloop — déroulez-moi le debugging. » Les bonnes réponses enchaînent logs, exit codes, image SHAs et stratégie de rollback sans sauter d'étape.

Observabilité

Prometheus + Grafana + Loki + un système de tracing (Tempo, Jaeger) est la stack open-source canonique. Datadog et New Relic dominent les offres payantes. Soyez prêt à définir des SLOs, des error budgets, et à quoi devrait ressembler une alerte (symptôme et non cause). Attendez-vous à : « votre dashboard est vert mais les clients se plaignent — où est le problème ? » Les réponses qui mentionnent le biais d'échantillonnage, les fenêtres d'agrégation et le monitoring synthétique vs real-user notent bien.

Profondeur spécifique au cloud

Choisissez AWS, GCP ou Azure selon la fiche de poste. Les questions AWS gravitent autour de IAM (cause la plus fréquente du « pourquoi ça ne marche pas »), du routing VPC, des particularités d'EKS et de la consistance S3. Les loops GCP privilégient IAM et la hiérarchie de projets, GKE et la structure de coût de BigQuery. Azure se concentre sur AAD, AKS et Azure DevOps Pipelines. Un cloud en profondeur vaut mieux que trois clouds en surface.

Questions de scénario courantes

• « Le Terraform apply vient d'expirer après 40 minutes. Quelle est la première chose que vous vérifiez ? » (La réponse devrait mentionner le state lock, les rate limits du provider et les dependency graphs.)
• « Les pods de production sont OOMKilled chaque lundi à 9 h. Déroulez-moi votre investigation. » (Attendu : patterns de trafic, memory limits, comportement du GC, déploiements récents, corrélation avec le retard de l'autoscaling.)
• « Vous héritez d'un pipeline de déploiement qui prend 45 minutes. Que changez-vous en premier ? » (Couches de cache, sharding parallèle des tests, jobs conditionnels, puis des décalages architecturaux plus profonds.)
• « Une équipe veut gérer son propre cluster EKS. Expliquez-moi si c'est une bonne idée. » (Coût, blast radius, expertise, compromis services partagés vs isolation.)
• « La moitié des alertes dans PagerDuty sont du bruit. Comment réglez-vous ça sans rater de vrais incidents ? » (Alerting basé sur les symptômes, seuils pilotés par les SLO, qualité des runbooks, corrélation d'alertes.)

Axes behavioral — ce que les recruteurs recherchent

Les recruteurs DevOps recherchent trois signaux au-delà de la profondeur technique. D'abord, l'appropriation de l'échec — savez-vous raconter une histoire d'incident sans blâmer l'équipe dev, le précédent lead DevOps ou le cloud provider ? Les bonnes histoires suivent le fil : chronologie → mauvaise hypothèse → découverte → correctif → prévention, et elles assument le « j'aurais dû le détecter en code review » sans broncher. Ensuite, la communication à travers les couches organisationnelles — le DevOps se situe entre les développeurs et la direction, attendez-vous donc à des questions sur l'explication d'un coût d'infrastructure à un CFO ou sur le fait de pousser contre une deadline serrée. Enfin, le pragmatisme vs la pureté — les recruteurs veulent quelqu'un capable de livrer un correctif bricolé mais monitoré à 2 h du matin, pas quelqu'un qui exige l'architecture parfaite avant de débloquer l'équipe.

Comment utiliser l'entraînement IA pour ce poste

Réglez le type d'entretien sur « Tech Screening » et collez la vraie fiche de poste si vous en avez une. L'IA extrait la stack d'outils (Terraform vs Pulumi, AWS vs GCP) et pondère les questions en conséquence. Sans fiche de poste, partez sur « AWS + Terraform + Kubernetes, séniorité middle, 10 questions » — ce profil couvre environ 60 % des annonces DevOps.

Pour la pratique de gestion d'incident, basculez en mode « Scénario » et demandez à l'IA de piloter une panne qui se déroule en direct. La session continue 15 à 20 minutes pendant que vous triez. La note récompense votre façon de réduire l'espace de recherche, pas le fait d'arriver à la « bonne » root cause — parce que les vrais incidents en ont rarement une seule.

Un exercice sous-utilisé : « Je veux cinq questions de refactoring Terraform à la suite. » L'IA générera des scénarios où vous découpez un root module, migrez du state ou éliminez du drift. Cinq répétitions dans une session et le vocabulaire cesse de sembler étranger.

Questions fréquentes