30 questions d’entretien DevOps et leurs réponses en 2026

Que signifie concrètement le DevOps pour vous ?

Le DevOps est une culture et un ensemble de pratiques qui réduisent le délai entre l’écriture du code et son exécution fiable en production, en automatisant le pipeline et en partageant la responsabilité entre le développement et les opérations. Il s’agit de livrer rapidement, de manière sûre et reproductible — pas d’utiliser un outil particulier.

Ce qui est évalué : une réponse axée sur la culture et les pratiques, pas une liste d’outils

Qu’est-ce que la CI/CD et que doit faire un bon pipeline ?

La CI (intégration continue) compile et teste automatiquement le code à chaque modification ; la CD (livraison ou déploiement continu) l’achemine automatiquement vers la production ou jusque dans celle-ci. Un bon pipeline détecte rapidement les problèmes, exécute les mêmes étapes à chaque fois et rend les mises en production prévisibles et réversibles.

Ce qui est évalué : l’automatisation du build, des tests et du déploiement — au-delà de la simple définition de l’acronyme

Quel problème les conteneurs résolvent-ils ?

Ils regroupent une application et tout ce dont elle a besoin pour fonctionner, afin qu’elle se comporte de la même façon sur n’importe quelle machine — et mettent fin au fameux « ça marche sur ma machine ». Cette reproductibilité rend les déploiements prévisibles et les environnements cohérents, de l’ordinateur portable à la production.

Ce qui est évalué : la reproductibilité et la compréhension de son importance

Quelle est la différence entre un conteneur et une machine virtuelle ?

Une VM virtualise une machine complète, y compris son propre système d’exploitation ; elle est donc plus lourde et plus lente à démarrer. Un conteneur partage le kernel du système hôte et isole uniquement l’application, ce qui le rend léger et rapide. Les conteneurs offrent un peu moins d’isolation en échange d’une bien meilleure efficacité.

Ce qui est évalué : la maîtrise des fondamentaux, qui met souvent les candidats mal préparés en difficulté

Qu’est-ce que le contrôle de version et comment utilisez-vous les branches ?

Le contrôle de version suit les modifications du code au fil du temps et permet à une équipe de collaborer sans écraser le travail des autres. Les branches permettent de développer une fonctionnalité de manière isolée, puis de la fusionner — généralement via une branche éphémère et une pull request relue avant la fusion.

Ce qui est évalué : la maîtrise de base de Git et un workflow cohérent

Quelle est la différence entre une image Docker et un conteneur ?

Une image est le modèle statique construit — le plan de référence. Un conteneur est une instance en cours d’exécution de cette image. Vous construisez une image une fois et pouvez lancer plusieurs conteneurs à partir de celle-ci, comme une classe et ses instances.

Ce qui est évalué : la distinction entre la phase de build et la phase d’exécution

Que signifie « idempotent » et pourquoi est-ce important en automatisation ?

Une opération idempotente produit le même résultat, qu’elle soit exécutée une seule fois ou plusieurs. C’est important, car les automatisations et les déploiements sont parfois relancés : des étapes idempotentes peuvent être réexécutées après un échec sans créer de doublons ni de dérive.

Ce qui est évalué : la capacité à relancer une opération sans risque — un concept central des opérations

Décrivez ce qui se passe entre un `git push` et l’exécution du code en production.

Le push déclenche la CI, qui compile le code, exécute les tests et produit un artefact ou une image. Si tout réussit, le pipeline le déploie — souvent d’abord en staging, puis en production — avec une stratégie de type rolling ou canary. Des contrôles de santé confirment la réussite avant le transfert du trafic.

Ce qui est évalué : la compréhension de l’ensemble du pipeline de livraison, de bout en bout

Qu’est-ce que l’Infrastructure as Code et pourquoi la préférer à une configuration manuelle ?

L’IaC décrit vos serveurs, réseaux et services dans des fichiers versionnés plutôt que par des clics dans des consoles. Elle rend l’infrastructure reproductible, révisable et cohérente entre les environnements, tout en éliminant la dérive et le problème du « personne ne se souvient de la façon dont cela a été configuré ».

Ce qui est évalué : la reproductibilité, le contrôle de version et la gestion de la dérive

Comment gérez-vous les secrets et la configuration entre les environnements ?

Les secrets doivent rester totalement en dehors du code : utilisez des variables d’environnement, un gestionnaire de secrets ou un vault, puis injectez-les au moment du déploiement. La configuration varie selon l’environnement grâce à des sources distinctes ; le même artefact peut ainsi être exécuté partout avec des paramètres différents.

Ce qui est évalué : la maturité en matière de sécurité ; une approche concrète vaut mieux que des généralités

Que fait Kubernetes et dans quels cas en avez-vous réellement besoin ?

Kubernetes orchestre des conteneurs sur plusieurs machines : il les planifie, les met à l’échelle, les répare automatiquement et gère leur réseau. Il devient utile lorsque vous exécutez de nombreux services à grande échelle qui ont besoin de ces fonctionnalités ; pour une petite application, il est généralement disproportionné par rapport à des solutions plus simples.

Ce qui est évalué : la compréhension de l’orchestration et la capacité à ne pas sur-architecturer

Comment réaliser un déploiement sans interruption de service ?

Lancez de nouvelles instances en parallèle des anciennes, attendez que les contrôles de santé et de disponibilité réussissent, puis transférez le trafic avant de retirer les anciennes — avec une approche rolling ou blue-green. L’essentiel est de ne jamais diriger du trafic vers une instance dont l’état sain n’est pas confirmé.

Ce qui est évalué : les déploiements rolling, les contrôles de santé et les readiness probes

Que surveillez-vous en production et sur quels éléments déclenchez-vous des alertes ?

Surveillez les signaux qui reflètent l’expérience utilisateur — taux d’erreur, latence, trafic et saturation — ainsi que la santé du système. Ne déclenchez des alertes que pour les situations nécessitant une intervention humaine : alerter sur tout crée un bruit qui finit par être ignoré au moment où cela compte vraiment.

Ce qui est évalué : la différence entre collecter des données et disposer de signaux réellement exploitables

Expliquez la différence entre un déploiement blue-green et un déploiement canary.

Le blue-green fait fonctionner deux environnements complets et transfère tout le trafic de l’ancien vers le nouveau en une fois, avec un rollback immédiat en revenant en arrière. Le canary expose d’abord la nouvelle version à un faible pourcentage du trafic, l’observe, puis augmente progressivement sa part. Le canary limite l’étendue d’un problème ; le blue-green est plus simple, mais fonctionne selon une logique tout ou rien.

Ce qui est évalué : les compromis entre les stratégies de livraison et leur contexte d’utilisation

Quels sont les concepts Terraform essentiels que vous utilisez au quotidien ?

Vous écrivez les ressources dans des fichiers de configuration, exécutez `plan` pour prévisualiser les changements et `apply` pour les appliquer. Le state suit ce qui existe réellement, les modules regroupent des composants réutilisables et un backend distant stocke le state afin que l’équipe partage une source de vérité de manière sûre.

Ce qui est évalué : le state, les modules, les backends distants et le fonctionnement de plan/apply

Comment fonctionne un load balancer et pourquoi en avez-vous besoin ?

Il répartit le trafic entrant entre plusieurs instances de votre service et évite celles qui ne sont pas saines grâce aux contrôles de santé. Il est utile pour garantir la disponibilité et absorber la charge : aucune instance unique ne devient un goulot d’étranglement ou un point de défaillance unique.

Ce qui est évalué : la répartition du trafic, les contrôles de santé et la disponibilité

Quelle est la différence entre la mise à l’échelle horizontale et verticale ?

La mise à l’échelle verticale consiste à renforcer une machine — davantage de CPU ou de RAM — tandis que la mise à l’échelle horizontale ajoute des machines. L’horizontale permet d’aller plus loin et apporte de la redondance, mais exige une application stateless ; la verticale est plus simple, mais possède une limite et conserve un point de défaillance unique.

Ce qui est évalué : la stratégie de mise à l’échelle et le contexte adapté à chacune

Un pod Kubernetes reste bloqué en CrashLoopBackOff. Expliquez-moi votre méthode de débogage.

Je commencerais par décrire le pod pour consulter les événements, puis je vérifierais ses logs afin d’identifier la cause du crash — souvent une mauvaise configuration, une variable d’environnement manquante, une dépendance défaillante ou un contrôle de santé qui échoue. Je partirais du symptôme pour remonter vers sa cause : le problème vient-il de l’image, de la configuration, de la readiness probe ou d’une ressource dont l’application a besoin et qui manque ?

Ce qui est évalué : un triage systématique — description, logs, événements — plutôt qu’une supposition

Votre Terraform apply a échoué à mi-parcours. Que faites-vous ensuite ?

Terraform enregistre dans le state ce qu’il a réussi à terminer. Je lirais donc l’erreur, examinerais le state pour vérifier ce qui a réellement changé, puis corrigerais la cause racine — souvent un problème de dépendance ou d’autorisation — avant de relancer apply, qui réconciliera l’infrastructure avec l’état souhaité. J’éviterais les modifications manuelles susceptibles de créer un écart entre le state et la réalité.

Ce qui est évalué : la compréhension du state et la capacité à récupérer sereinement après une modification partielle

Comment concevez-vous un pipeline CI/CD pour une équipe qui déploie plusieurs fois par jour ?

Je prévois des tests rapides et parallélisés pour obtenir un retour immédiat, des règles claires pour la fusion, des déploiements automatisés avec un rollback simple et suffisamment de self-service pour que les ingénieurs n’aient pas à attendre mon intervention. L’objectif est de rendre les mises en production sûres et routinières, le pipeline détectant les problèmes plutôt qu’un gardien humain.

Ce qui est évalué : le parallélisme, les règles de validation, le rollback et le self-service

Parlez-moi d’une panne que vous avez provoquée ou gérée, ainsi que de son post-mortem.

Je décrirais un cas concret : ce qui est tombé en panne, comment nous l’avons détecté, comment nous avons rétabli le service et, surtout, le post-mortem sans recherche de coupable qui a identifié la cause racine et les changements ayant empêché une récidive. La leçon tirée et la prévention comptent davantage que la recherche d’un responsable.

Ce qui est évalué : la séniorité, la capacité à assumer un échec et à en tirer des enseignements

Comment gérez-vous la dérive de configuration dans votre infrastructure ?

Je gère tout via l’Infrastructure as Code afin que l’état souhaité soit défini et versionné, je détecte la dérive en comparant l’état réel à cet état de référence, puis je réconcilie l’ensemble en réappliquant la configuration plutôt qu’en corrigeant manuellement. La solution consiste à faire des modifications manuelles l’exception, et non la règle.

Ce qui est évalué : la détection et la réconciliation

Comment Terraform s’intègre-t-il à votre CI/CD et qui approuve un apply ?

En général, le pipeline exécute automatiquement `plan` lorsqu’une modification est proposée et publie le diff pour revue ; `apply` ne s’exécute qu’après approbation, souvent avec une protection sur la branche ou une étape manuelle. Les changements d’infrastructure restent ainsi relus et audités, plutôt que lancés ponctuellement depuis l’ordinateur portable de quelqu’un.

Ce qui est évalué : l’intégration au pipeline et le contrôle des changements

Comment concevez-vous l’observabilité pour détecter les problèmes avant les utilisateurs ?

Je combine métriques, logs et traces, et je déclenche des alertes sur les indicateurs précurseurs — hausse de la latence ou du taux d’erreur, saturation des ressources — plutôt que d’attendre les pannes franches. De bons tableaux de bord et des alertes pertinentes permettent de voir la dégradation se développer et d’agir avant qu’elle ne se transforme en incident.

Ce qui est évalué : les métriques, les logs, les traces et la pertinence des alertes

Comment sécurisez-vous une image de conteneur et sa chaîne d’approvisionnement ?

Je pars d’une image de base minimale et fiable, j’installe uniquement ce qui est nécessaire, j’analyse les images à la recherche de vulnérabilités connues dans le pipeline, je fige les dépendances et j’exécute les conteneurs avec un utilisateur non root et le principe du moindre privilège. L’objectif est de réduire la surface d’attaque, tout en la maintenant connue et régulièrement mise à jour.

Ce qui est évalué : les images de base minimales, l’analyse de vulnérabilités et le moindre privilège

Il est 3 heures du matin. Le CPU d’un service sature et les requêtes expirent. Décrivez votre réaction.

Je commence par stabiliser la situation : je consulte les tableaux de bord et les changements récents et, si un déploiement est à l’origine du problème, je fais un rollback. Je diagnostique ensuite : s’agit-il d’un pic de trafic, d’un chemin de code coûteux, d’une dépendance ralentie ou d’une fuite de ressources ? Je prends des mesures pour rétablir le service — scale-out, réduction de charge ou rollback — je communique l’état de la situation et je réserve l’analyse approfondie de la cause racine au post-mortem.

Ce qui est évalué : un triage calme et structuré sous pression

Concevez une stratégie de déploiement et de rollback pour un service de paiement qui ne doit jamais perdre de données.

J’utiliserais une mise en production progressive et sûre, comme canary ou blue-green, avec des contrôles de santé. Je rendrais les opérations idempotentes afin que les tentatives répétées ne débitent pas deux fois le client, et je veillerais à ce que les changements de base de données restent rétrocompatibles lorsque les anciennes et nouvelles versions fonctionnent simultanément. Le rollback doit être immédiat et préserver les données, jamais improvisé dans l’urgence.

Ce qui est évalué : la fiabilité, l’idempotence et la sécurité du rollback sous fortes contraintes

Concevez des workflows de déploiement en self-service pour que 80 ingénieurs n’aient pas besoin de vous à chaque mise en production.

Je fournirais un pipeline standard suivant un parcours balisé, avec des garde-fous — tests automatisés, règles de validation et valeurs par défaut sûres — afin que les équipes puissent se déployer sans expertise particulière de la plateforme. Mon rôle évolue alors vers la conception et la maintenance de cette plateforme, plutôt que de rester le goulot d’étranglement manuel de chaque livraison.

Ce qui est évalué : la réflexion plateforme et la capacité à sortir du chemin critique

Une modification de configuration a provoqué une dégradation en cascade dans plusieurs régions. Comment réagissez-vous et comment évitez-vous que cela se reproduise ?

Je commence par annuler la modification pour stopper l’aggravation, puis j’analyse pourquoi une seule configuration a pu affecter plusieurs régions. Pour prévenir une récidive, je déploierais les changements de configuration progressivement plutôt que partout en même temps, je limiterais leur blast radius et je les validerais avant leur propagation — une modification de configuration doit être traitée avec autant de précautions qu’un déploiement de code.

Ce qui est évalué : la prise en compte de l’étendue d’impact et la prévention après incident

Concevez le monitoring et l’astreinte d’un système où chaque minute d’interruption coûte de l’argent.

Je définirais des SLO clairs, je ne déclencherais des alertes que lorsqu’ils sont menacés afin de ne pas noyer l’astreinte sous le bruit, et je mettrais en place une véritable procédure d’escalade. J’ajouterais de la redondance pour réduire les points uniques de défaillance et organiserais des exercices de réponse aux incidents : lorsqu’un problème survient, la réaction doit être maîtrisée plutôt qu’improvisée.

Ce qui est évalué : les SLO, la discipline en matière d’alertes et l’escalade