25 Questions d’Entretien DevOps Incontournables en 2026
Les entretiens DevOps ne ressemblent à rien d’autre en tech. On ne te demandera pas d’inverser un arbre binaire ou de débattre sur les mérites de REST vs GraphQL. On va te demander comment tu déploierais en production un vendredi à 15h, ce qui se passe quand le pipeline casse en plein release, et si tu as déjà été réveillé à 2h du mat’ par une alerte sur un service que tu as construit toi-même.
J’ai passé et fait passer des dizaines de ces entretiens. Le schéma est toujours le même : les recruteurs ne testent pas ce que tu as mémorisé. Ils testent ce que tu as opéré. Les pipelines cassés, les tests instables, les conteneurs qui refusent de démarrer, les alertes qui sonnent au pire moment. C’est ça, le vrai programme.
Ces 25 questions reviennent systématiquement dans les entretiens DevOps — en startup, en scale-up, dans les grands groupes. Elles sont groupées par domaine pour que tu puisses cibler tes lacunes. Pour chacune, je t’explique ce que le recruteur cherche vraiment et comment structurer une réponse qui fait mouche.
CI/CD — Le Pipeline, c’est le Produit
S’il y a un domaine qui sort à chaque entretien DevOps, c’est le CI/CD. Pas juste “tu sais ce que ça veut dire” — mais est-ce que tu peux concevoir, débugger et défendre un pipeline sous pression.
1. Quelle est la différence entre intégration continue, livraison continue et déploiement continu ?
Ce que le recruteur cherche : Si tu comprends le spectre, pas juste les acronymes. CI signifie merger et tester le code fréquemment. La livraison continue veut dire que l’artefact est toujours déployable mais qu’un humain appuie sur le bouton. Le déploiement continu signifie que ça part en production automatiquement.
Conseil de réponse : Ne te contente pas de les définir. Dis lequel tu as réellement pratiqué et pourquoi. “On faisait de la livraison continue parce que notre équipe conformité exigeait une validation manuelle avant la prod” vaut dix fois plus qu’une définition de manuel.
2. Comment concevrais-tu un pipeline CI/CD from scratch pour un nouveau microservice ?
Ce que le recruteur cherche : Une pensée structurée. Est-ce que tu sais raisonner par étapes — lint, tests unitaires, build, tests d’intégration, scan de sécurité, push de l’artefact, déploiement en staging, smoke tests, déploiement en prod ?
Conseil de réponse : Déroule-le séquentiellement. Mentionne ce qui bloque le pipeline à chaque étape. Les recruteurs adorent entendre parler de conception fail-fast : “Si le lint échoue, rien d’autre ne se lance. Aucun intérêt à builder un artefact cassé.”
3. Un déploiement vient d’échouer en production. Explique-moi ta stratégie de rollback.
Ce que le recruteur cherche : De la maturité opérationnelle. Tu paniques ou tu as un plan ? Blue-green, canary, feature flags, rollback de migrations de base de données — il veut du concret.
Conseil de réponse : Décris un vrai rollback que tu as fait. Plus c’est chaotique, mieux c’est. “On avait une migration de BDD irréversible, donc on a utilisé un feature flag pour désactiver le nouveau chemin de code pendant qu’on écrivait un forward-fix.” Ce genre d’histoire, ça reste.
4. Comment gères-tu les secrets dans un pipeline CI/CD ?
Ce que le recruteur cherche : Ta conscience sécurité. Les secrets en dur dans les fichiers YAML, c’est encore effroyablement courant. Il veut entendre parler d’intégrations vault, de variables scopées par environnement, de politiques de rotation.
Conseil de réponse : Nomme les outils spécifiques que tu as utilisés — les secrets GitHub Actions, HashiCorp Vault, AWS Secrets Manager. Puis mentionne ce que tu ne ferais jamais : commiter des secrets dans git, les afficher dans les logs du pipeline, les passer en build arguments dans Docker.
5. Comment gères-tu les tests flaky dans un pipeline ?
Ce que le recruteur cherche : Du pragmatisme. Tout le monde a des tests flaky. La question, c’est si tu les mets en quarantaine, si tu suis des métriques de flakiness, si tu fais des retry avec précaution, ou si tu relances juste le pipeline en croisant les doigts.
Conseil de réponse : “On taguait les tests flaky connus et on les faisait tourner dans un stage séparé non bloquant pendant qu’on corrigeait les causes racines. On suivait le taux de flake chaque semaine. Si un test était flaky depuis plus de deux sprints, on le corrigeait ou on le supprimait.” Ça montre de la maturité processuelle.
Conteneurs & Orchestration — Là où la Théorie Rencontre le Terrain
Docker et Kubernetes dominent cette section. Si tu n’as fait que des tutoriels, c’est ici que ça va se voir.
6. Que se passe-t-il quand tu lances docker run ?
Ce que le recruteur cherche : De la profondeur. Tu connais les couches d’image, le runtime de conteneur, les namespaces, les cgroups ? Ou tu connais juste la commande ?
Conseil de réponse : Déroule couche par couche. “Le daemon Docker pull l’image si elle n’est pas en cache, crée une couche conteneur en écriture au-dessus des couches d’image, configure les namespaces pour l’isolation des processus et les cgroups pour les limites de ressources, puis lance le processus d’entrypoint.” Ce niveau de détail sépare les opérateurs des suiveurs de tutos.
7. Quelle est la différence entre une image Docker et un conteneur ?
Ce que le recruteur cherche : Un modèle mental clair. Une image est un template en lecture seule. Un conteneur est une instance en cours d’exécution de ce template avec une couche en écriture par-dessus.
Conseil de réponse : Utilise une analogie si ça aide — “Une image c’est une classe, un conteneur c’est une instance” — mais enchaîne immédiatement avec du concret. “Je peux lancer cinq conteneurs depuis la même image, chacun avec son propre état, ses logs et son identité réseau.”
8. Explique comment fonctionne le scheduling Kubernetes.
Ce que le recruteur cherche : Si tu comprends le control plane. L’API server accepte le spec du pod, etcd le stocke, le scheduler évalue l’adéquation des nœuds (ressources, taints, tolerations, règles d’affinité), et le kubelet sur le nœud choisi pull l’image et démarre le conteneur.
Conseil de réponse : Mentionne un vrai problème de scheduling que tu as rencontré. “On avait des pods bloqués en Pending parce que notre node pool n’avait pas assez de marge mémoire. Ajouter des requests et limits a corrigé le scheduling, mais ça a aussi révélé qu’on sur-provisionnait le CPU et sous-provisionnait la mémoire depuis des mois.”
9. Comment débuggerais-tu un pod en CrashLoopBackOff ?
Ce que le recruteur cherche : Une approche de debug systématique. Pas juste “regarde les logs” — mais une séquence : kubectl describe pod, vérifier les events, kubectl logs (y compris le conteneur précédent), exec dans un sidecar, vérifier les probes readiness/liveness, revoir les resource limits.
Conseil de réponse : Présente ça comme une checklist que tu suis réellement. Les recruteurs veulent voir que tu ne vas pas paniquer quand quelque chose casse en prod. Bonus si tu mentionnes que CrashLoopBackOff signifie souvent que l’application plante, pas Kubernetes.
10. Quand est-ce que tu n’utiliserais PAS Kubernetes ?
Ce que le recruteur cherche : Du jugement. Kubernetes est puissant mais coûteux en complexité. Si tu fais tourner trois services avec une petite équipe, ECS ou même Docker Compose peut être le bon choix.
Conseil de réponse : C’est une question de maturité. “Kubernetes a du sens quand tu as assez de services et assez de membres d’équipe pour justifier la charge opérationnelle. Pour une petite équipe qui shippe deux services, je prendrais ECS Fargate ou Cloud Run. Moins à gérer, plus rapide à livrer.” Les recruteurs adorent les candidats qui savent quand ne pas sortir l’artillerie lourde.
Infrastructure as Code — Reproductibilité ou Regrets
Les questions IaC testent si tu as subi la douleur des changements d’infra manuels et si tu en es sorti avec de la discipline.
11. Pourquoi l’Infrastructure as Code est-elle importante ?
Ce que le recruteur cherche : Pas un argumentaire de vente pour Terraform. Il veut entendre parler de reproductibilité, de traçabilité, de collaboration, de détection de drift, et de reprise après sinistre.
Conseil de réponse : Raconte une histoire d’horreur. “On avait un environnement configuré manuellement pendant deux ans. Quand on a dû le répliquer pour un audit de conformité, ça a pris trois ingénieurs et deux semaines. Après le passage à Terraform, monter un nouvel environnement prenait 20 minutes.” Ce genre d’histoire, c’est la raison d’être de l’IaC.
12. Comment gères-tu le state Terraform, et qu’est-ce qui peut mal tourner ?
Ce que le recruteur cherche : De la profondeur opérationnelle. State locking, backends distants (S3 + DynamoDB, Terraform Cloud), corruption de state, import de ressources créées manuellement, exposition de secrets dans le fichier state.
Conseil de réponse : Mentionne un problème de state que tu as rencontré. “On a eu deux ingénieurs qui ont lancé terraform apply en même temps avant qu’on mette en place le state locking. Un apply a écrasé les changements de l’autre. On a perdu une NAT gateway et on a dû la réimporter manuellement.” C’est ce genre de cicatrice que les recruteurs respectent.
13. Quelle est la différence entre Terraform et Ansible ?
Ce que le recruteur cherche : Ta compréhension du déclaratif vs impératif, du provisionnement vs la gestion de configuration. Terraform crée l’infrastructure. Ansible configure ce qui tourne dessus. Ils se chevauchent, mais le point fort n’est pas le même.
Conseil de réponse : “Terraform dit au cloud ce qui doit exister. Ansible dit aux machines comment être configurées. J’ai utilisé les deux ensemble — Terraform provisionne les instances EC2, Ansible installe et configure l’application. Ils sont complémentaires, pas concurrents.”
14. Comment structures-tu Terraform pour plusieurs environnements ?
Ce que le recruteur cherche : Des compétences d’organisation concrètes. Workspaces vs structure de répertoires. Modules pour la réutilisabilité. Fichiers de variables par environnement. State distant avec des backends spécifiques par environnement.
Conseil de réponse : Décris ton vrai layout de dossiers. “On utilisait une structure répertoire-par-environnement — environments/dev, environments/staging, environments/prod — chacun appelant les mêmes modules racine avec des tfvars différents. Les workspaces nous semblaient trop implicites pour la taille de notre équipe.”
15. Comment gères-tu les breaking changes dans Terraform ?
Ce que le recruteur cherche : La conscience du risque. Renommer une ressource la détruit et la recrée. Changer une version de provider peut introduire du drift. Les state moves, les imports et les targeted applies ont tous des pièges.
Conseil de réponse : “terraform plan est sacré. On n’appliquait jamais sans avoir reviewé le plan. Et quand on devait renommer des ressources, on utilisait terraform state mv d’abord pour éviter la destruction. Un jour, quelqu’un a renommé une instance RDS dans le code sans déplacer le state — Terraform a essayé de détruire et recréer la base de données de production. La review du plan l’a rattrapé.”
Monitoring & Observabilité — Parce que Déployer n’est que la Moitié du Travail
Livrer du code sans monitoring, c’est comme conduire sans phares. Les recruteurs le savent, et ils vont tester si toi aussi.
16. Quelle est la différence entre monitoring et observabilité ?
Ce que le recruteur cherche : De la nuance. Le monitoring te dit quand quelque chose ne va pas (alertes, dashboards). L’observabilité te dit pourquoi — en utilisant logs, métriques et traces ensemble pour diagnostiquer des problèmes que tu n’avais pas anticipés.
Conseil de réponse : “Le monitoring, c’est le détecteur de fumée. L’observabilité, c’est avoir le plan de l’immeuble, des capteurs de chaleur et une caméra pour comprendre où le feu a démarré et pourquoi.” Puis ancre-le dans le réel : “On avait des dashboards pour la latence et les taux d’erreur, mais on ne pouvait pas débugger les pannes inter-services tant qu’on n’avait pas ajouté du tracing distribué avec Jaeger.”
17. Comment décides-tu sur quoi alerter ?
Ce que le recruteur cherche : De la discipline. Alerter sur tout crée du bruit. Alerter sur rien crée de l’aveuglement. Il veut entendre parler de SLOs, de budgets d’erreur, et d’alertes basées sur les symptômes vs les causes.
Conseil de réponse : “On alertait sur les symptômes visibles par l’utilisateur — taux d’erreur au-dessus de 1%, p99 de latence au-dessus de 500ms — pas sur des métriques internes comme le CPU. Un CPU élevé n’est pas un problème si les utilisateurs ne sont pas impactés. On a cramé notre équipe d’astreinte une fois avec des alertes bruyantes avant d’apprendre cette leçon.”
18. Explique les concepts de SLO, SLI et SLA.
Ce que le recruteur cherche : Si tu peux relier des concepts abstraits à des opérations réelles. Le SLI est la métrique (latence des requêtes), le SLO est l’objectif (99,9% des requêtes sous 200ms), le SLA est le contrat business avec des conséquences.
Conseil de réponse : Reste concret. “Notre SLI c’était les réponses API réussies divisées par le total des réponses. Notre SLO était 99,95% sur une fenêtre de 30 jours. Ça nous donnait un budget d’erreur d’environ 22 minutes de downtime par mois. Quand on a consommé la moitié du budget en un seul incident, on a pausé le développement de features pour stabiliser.”
19. Comment abordes-tu le logging dans une architecture microservices ?
Ce que le recruteur cherche : Logging structuré, agrégation centralisée, correlation IDs, niveaux de log, politiques de rétention. Pas juste “on utilise ELK.”
Conseil de réponse : “Chaque service émet des logs JSON structurés avec un correlation ID qui traverse tous les appels downstream. On envoie tout dans un système centralisé — on utilisait Loki, mais ELK ou Datadog marchent aussi. L’essentiel, c’est de pouvoir rechercher par correlation ID et reconstruire le parcours complet d’une requête à travers les services.”
20. Qu’est-ce que le tracing distribué et quand l’utiliserais-tu ?
Ce que le recruteur cherche : Ta compréhension de la propagation du contexte de trace, des spans, et de quand le tracing apporte de la valeur vs quand c’est excessif. Le tracing brille en microservices quand une requête traverse cinq services ou plus.
Conseil de réponse : “On a ajouté du tracing OpenTelemetry quand on cherchait à débugger un pic de latence que les logs seuls ne pouvaient pas expliquer. Il s’est avéré qu’un service downstream faisait un appel synchrone à une API tierce qui prenait parfois 3 secondes. Sans tracing, on aurait blâmé le mauvais service pendant des semaines.”
Culture & Process — La Partie qui Définit Vraiment le DevOps
Le DevOps est une culture avant d’être une toolchain. Les recruteurs qui posent ces questions testent si tu as compris ça.
21. Que signifie le DevOps pour toi ?
Ce que le recruteur cherche : Pas une définition de dictionnaire. Il veut entendre parler de responsabilité partagée, de boucles de feedback rapides, d’automatisation comme principe, et de décloisonnement entre développement et opérations.
Conseil de réponse : “Pour moi, le DevOps c’est la pratique qui rend toute l’équipe responsable de ce qui se passe après que le code est écrit — pas seulement avant. Si je l’écris, je dois pouvoir le déployer, le monitorer, et être appelé quand ça casse. Cette responsabilité change ta façon d’écrire du code.”
22. Comment gères-tu un incident de production ?
Ce que le recruteur cherche : Du process. Tu as un framework d’incident ? Des rôles (incident commander, communicant, debugger) ? Une classification de sévérité ? Des revues post-incident ?
Conseil de réponse : Déroule un vrai incident. “On a eu un SEV-1 quand notre service de paiement est tombé. J’étais incident commander. On a ouvert une war room, assigné les rôles, communiqué le statut toutes les 15 minutes aux stakeholders, identifié la cause racine en 40 minutes — un pool de connexions mal configuré — et rédigé un postmortem blameless le lendemain.”
23. Qu’est-ce qu’un postmortem blameless et pourquoi c’est important ?
Ce que le recruteur cherche : Si tu comprends la sécurité psychologique en ingénierie. Le blâme pousse à cacher. L’absence de blâme pousse à apprendre.
Conseil de réponse : “Un postmortem blameless se concentre sur ce que le système a permis de se produire, pas sur qui l’a fait. On demande ‘pourquoi le système a laissé ce déploiement passer sans canary ?’ et pas ‘pourquoi tu as poussé ce code cassé ?’ L’objectif, c’est de corriger le process, pas de punir la personne. Les équipes qui blâment arrêtent de remonter les incidents. Les équipes qui apprennent de leurs incidents deviennent plus résilientes.”
24. Comment équilibres-tu la vitesse de livraison avec la fiabilité du système ?
Ce que le recruteur cherche : Le concept SRE des budgets d’erreur. On shippe vite quand on a du budget. On ralentit et on stabilise quand on n’en a plus.
Conseil de réponse : “Les budgets d’erreur sont le mécanisme. Si on est dans notre SLO, on shippe les features agressivement. Si on a consommé la majorité de notre budget d’erreur, on pause et on investit dans la fiabilité — meilleurs tests, monitoring amélioré, corrections architecturales. C’est une façon data-driven de régler l’éternel débat ‘shipper vs stabiliser’.“
25. Comment évalues-tu s’il faut construire un outil en interne ou utiliser une solution existante ?
Ce que le recruteur cherche : Du jugement et de la conscience des coûts. Build vs buy, ce n’est pas qu’une question d’argent — c’est une question de charge de maintenance, de coût d’opportunité, et d’expertise de l’équipe.
Conseil de réponse : “Je pars du principe qu’on utilise une solution existante sauf s’il y a une raison forte de ne pas le faire. Le coût de maintenance de l’outillage interne est presque toujours sous-estimé. On a un jour construit un outil de déploiement custom parce que ‘aucun outil existant ne colle à notre workflow.’ Deux ans plus tard, trois ingénieurs passaient 30% de leur temps à le maintenir. On a migré vers ArgoCD et on a récupéré ces ingénieurs.”
Comment Structurer tes Réponses
Un schéma que j’ai vu marcher en entretien DevOps, encore et encore :
- Énonce ta compréhension du concept. Une ou deux phrases. Ne fais pas un cours.
- Donne un exemple concret de ton expérience. Vrai projet, vraie conséquence. “Dans ma boîte précédente, on…” pèse plus que “En théorie, il faudrait…”
- Mentionne les trade-offs. Chaque décision DevOps en a. Si ta réponse n’inclut pas un inconvénient ou un “ça dépend,” elle sonne probablement répétée.
- Conclus sur ce que tu recommanderais et pourquoi. Montre que tu sais prendre une décision, pas juste lister des options.
Les recruteurs DevOps sont eux-mêmes des opérateurs. Ils sentent une réponse scriptée à des kilomètres. L’expérience opérationnelle — y compris les échecs — c’est ce qui sépare les candidats qui reçoivent des offres de ceux qui reçoivent des refus polis.
FAQ
Combien d’outils DevOps faut-il connaître pour un entretien ?
La profondeur bat la largeur. Connais un outil CI/CD en profondeur (GitHub Actions ou GitLab CI sont les plus courants), un orchestrateur de conteneurs (Kubernetes), un outil IaC (Terraform), et une stack de monitoring (Prometheus + Grafana ou Datadog). Si tu maîtrises ces quatre-là, tu peux apprendre les alternatives en quelques jours.
Les entretiens DevOps incluent-ils des challenges de code ?
Souvent, oui. Attends-toi à des questions de scripting en Bash ou Python — parser des logs, automatiser une tâche, écrire un simple health check. Certaines entreprises incluent aussi des rounds de system design où tu architectures un pipeline de déploiement ou un système de monitoring. C’est moins du LeetCode et plus de la résolution de problèmes pratiques.
Faut-il passer des certifications avant de postuler en DevOps ?
Des certifications comme l’AWS DevOps Professional ou le CKA (Certified Kubernetes Administrator) aident à passer les filtres RH, surtout dans les grandes entreprises. Mais elles ne porteront pas l’entretien. J’ai vu des candidats certifiés incapables d’expliquer comment terraform plan fonctionne en pratique. La certif’ ouvre des portes. Ce sont les histoires opérationnelles qui te font avancer.
Quel est le plus gros red flag dans une réponse d’entretien DevOps ?
Dire “on” pour tout sans pouvoir expliquer ta contribution spécifique. Les recruteurs vont relancer avec “et toi, c’était quoi ton rôle là-dedans ?” Si tu ne peux pas répondre clairement, ils supposeront que tu as regardé quelqu’un d’autre faire le travail.
Tu veux le plan de préparation complet ? Les questions DevOps ne sont qu’une tranche. Pour le coding, le system design, les rounds comportementaux et un plan d’étude semaine par semaine, lis comment préparer un entretien technique en 2026.
Tu révises le cloud en parallèle du DevOps ? Ces questions se combinent bien avec nos questions d’entretien cloud pour AWS, Azure et GCP.
Prêt à commencer ? Rejoins l’accès anticipé —>