Questions d'entretien DevOps : infrastructure, CI/CD et ce qu'ils testent vraiment

Les entretiens DevOps ont la réputation d'être difficiles à préparer. L'une des raisons est que « ingénieur DevOps » couvre un éventail énorme de rôles — des postes SRE à forte composante infrastructure dans les grandes entreprises tech, aux spécialistes de pipelines CI/CD dans les entreprises SaaS de taille moyenne, en passant par les ingénieurs de migration cloud dans les entreprises qui quittent leurs systèmes legacy. Les outils et priorités varient considérablement.

Mais il y a quelque chose de plus cohérent que les recruteurs DevOps cherchent à évaluer : comment vous raisonnez sur les systèmes. Pouvez-vous retracer un incident jusqu'à sa cause fondamentale ? Pouvez-vous réfléchir à un pipeline de déploiement de bout en bout ? Comprenez-vous les compromis entre fiabilité et vélocité ? Savez-vous quand automatiser et quand laisser quelque chose manuel ? Ces schémas de raisonnement apparaissent dans chaque entretien DevOps, quelle que soit la pile technologique spécifique.

Ce guide couvre les questions que vous recevrez réellement, ce qu'elles testent vraiment et comment répondre d'une manière qui démontre les schémas de pensée qu'exhibent les ingénieurs DevOps expérimentés.

Ce que les recruteurs DevOps évaluent réellement

Avant de plonger dans des questions spécifiques, il est utile de comprendre les axes d'évaluation que les recruteurs DevOps utilisent.

Pensée systémique : Comprenez-vous comment les composants interagissent ? Quand quelque chose se casse, remontez-vous le problème en amont et en aval, ou réparez-vous le symptôme évident et passez à autre chose ? Les recruteurs testent cela avec des questions sur des scénarios d'incident et des discussions de style post-mortem.

Maturité opérationnelle : Avez-vous livré des choses dont d'autres personnes dépendent ? Avez-vous été d'astreinte et géré de vrais incidents ? Les candidats qui n'ont travaillé que dans des contextes purement greenfield ou purement de développement ont souvent du mal avec les questions opérationnelles — ce qui casse à l'échelle, comment vous gérez la toil, à quoi ressemble une bonne alerte.

Collaboration et communication : DevOps est intrinsèquement transversal. Travaillez-vous efficacement avec des développeurs qui ne connaissent pas beaucoup l'infrastructure ? Pouvez-vous expliquer une architecture de déploiement à une partie prenante non technique ? Comment gérez-vous la tension entre la vélocité des développeurs et la stabilité de l'infrastructure ?

Instinct d'automatisation : Le cœur culturel de DevOps est l'automatisation de la toil. Les recruteurs veulent voir que vous demandez réflexivement « est-ce que cela peut être automatisé ? » en décrivant des processus manuels — non pas comme un mot à la mode, mais comme un véritable instinct opérationnel.

Questions sur l'infrastructure et les systèmes

« Expliquez-moi ce qui se passe quand un pod Kubernetes plante. »

C'est une question diagnostique. Le recruteur ne teste pas si vous connaissez par cœur la séquence de crash loop backoff — il veut voir si vous pouvez raisonner sur le comportement d'un système de bout en bout.

Une bonne réponse couvre : le conteneur sort (avec quel code de sortie, et pourquoi les codes de sortie sont importants pour distinguer les erreurs d'application des kills OOM des échecs de healthcheck), le kubelet détecte le changement d'état, le pod entre dans un cycle de redémarrage, le crash loop backoff s'enclenche (backoff exponentiel jusqu'à cinq minutes par défaut), les sondes de vivacité sont pertinentes ici, et les outils d'observabilité que vous utiliseriez (kubectl describe, kubectl logs --previous, événements dans le namespace).

Le recruteur observe également si vous posez des questions de clarification : « Quel type de pod — déploiement stateless, statefulset ? Est-ce en production ou en dev ? Y a-t-il des limites de ressources définies ? » Cet instinct de recentrage est un signal d'expérience réelle de dépannage.

« Comment concevriez-vous le réseau pour une application web à trois niveaux sur AWS ? »

C'est une question d'architecture qui teste comment vous réfléchissez simultanément à la sécurité, la disponibilité et le flux de trafic. Une réponse bien structurée couvre :

• Sous-réseau public pour l'équilibreur de charge (ALB) avec passerelle internet
• Sous-réseaux privés pour le niveau application (ECS, EKS ou EC2), de préférence sur plusieurs zones de disponibilité
• Sous-réseaux privés pour le niveau données (RDS avec Multi-AZ pour la haute disponibilité)
• Groupes de sécurité comme couche principale de contrôle d'accès — principe du moindre privilège, n'autorisant que le trafic de la couche au-dessus
• VPC flow logs pour l'observabilité
• Passerelle NAT pour internet sortant depuis les sous-réseaux privés si nécessaire

Puis ajoutez de la nuance : « Dans une implémentation réelle, je réfléchirais également aux points de terminaison VPC pour éviter que le trafic quitte le réseau AWS pour les appels S3 et DynamoDB, et si nous avons besoin d'un WAF devant l'ALB. »

Les candidats forts construisent la réponse de manière incrémentielle et mentionnent les compromis. Les candidats faibles récitent une liste de services AWS sans expliquer pourquoi ils sont utilisés ou quelles sont les alternatives.

« Quelle est la différence entre un déploiement rolling et un déploiement blue-green ? »

Une question déceptivement simple qui teste si vous comprenez les stratégies de déploiement et quand chacune est appropriée.

Déploiement rolling : remplace progressivement les instances de l'ancienne version par la nouvelle version. À tout moment pendant le déploiement, une partie du trafic touche l'ancienne version et une partie touche la nouvelle. Plus simple à implémenter, utilise moins de ressources, mais risque des états de versions mixtes qui peuvent causer des problèmes avec les migrations de base de données ou les changements d'API avec rupture.

Déploiement blue-green : faire fonctionner deux environnements identiques (bleu = actuel, vert = nouveau). Basculer le trafic d'un seul coup (ou progressivement via un routage pondéré). Rollback instantané (rebascule sur bleu), pas d'état de versions mixtes, mais nécessite le double des ressources d'infrastructure pendant la fenêtre de bascule.

La canary release est une troisième option qui vaut la peine d'être mentionnée : router un petit pourcentage du trafic (1 %, 5 %) vers la nouvelle version, surveiller, étendre progressivement. Meilleure pour la gestion des risques mais plus complexe à implémenter et surveiller.

La bonne réponse inclut également quand choisir chacune : « Blue-green quand un basculement propre est critique et que vous pouvez vous permettre le coût en ressources. Rolling quand vous devez économiser sur les ressources d'infrastructure et que les changements sont rétrocompatibles. Canary quand vous faites un changement avec une forte incertitude et voulez une validation avec du trafic réel avant le déploiement complet. »

Questions sur les pipelines CI/CD

« Parlez-moi d'un pipeline CI/CD que vous avez construit ou significativement amélioré. »

Question comportementale, mais à contenu technique. Le recruteur veut savoir : quel était l'état de départ, qu'avez-vous changé, quels ont été les résultats, et qu'avez-vous appris ?

Une bonne réponse est spécifique sur les outils (GitHub Actions, Jenkins, GitLab CI, CircleCI, ArgoCD, etc.), les problèmes spécifiques que vous avez résolus (builds lents, tests instables, étapes de déploiement manuelles, manque de parité d'environnement) et les résultats mesurables (temps de build réduit de 45 à 12 minutes, fréquence de déploiement augmentée de hebdomadaire à quotidienne, temps de rollback de 2 heures à 5 minutes).

Ce qui rend la réponse forte n'est pas les outils spécifiques — c'est de démontrer que vous compreniez suffisamment bien le système pour diagnostiquer les goulots d'étranglement, que vous aviez le jugement pour prioriser les bonnes améliorations et que vous avez mesuré les résultats en termes qui se connectent à l'expérience développeur et à la vélocité des affaires.

« Comment gérez-vous les secrets dans un pipeline CI/CD ? »

C'est à la fois une question de sécurité et une question pratique. Approches courantes : variables d'environnement injectées au moment de l'exécution, HashiCorp Vault avec des secrets dynamiques, AWS Secrets Manager ou GCP Secret Manager avec accès basé sur IAM, Kubernetes secrets (avec la mise en garde qu'ils ne sont qu'encodés en base64, pas chiffrés, par défaut — le chiffrement ETCD au repos est une étape séparée).

Les bonnes réponses couvrent également ce qu'il ne faut pas faire : des secrets dans des variables d'environnement qui sont journalisées, des secrets dans des dépôts de code, des secrets passés comme arguments de build qui sont intégrés dans les couches d'image Docker.

La question de suivi est souvent : « Que se passe-t-il si un secret est accidentellement commis dans le dépôt ? » Une bonne réponse couvre : rotation immédiate, analyse de l'historique git (git-secrets, truffleHog, le scan de secrets natif de GitHub), vérification si le secret a été utilisé dans des journaux de build, et une brève revue d'incident pour comprendre comment cela s'est produit et prévenir la récurrence.

Questions sur Linux et les scripts

« Un serveur fonctionne lentement. Comment le diagnostiquez-vous ? »

La question de méthodologie de diagnostic. La réponse démontre si vous avez une approche systématique ou si vous essayez juste des choses au hasard.

Une approche structurée : commencer par les quatre principales catégories de ressources — CPU, mémoire, E/S disque, réseau. Commandes pour chacun :

• CPU : top, htop, mpstat, vmstat — y a-t-il un processus spécifique consommant du CPU ? Est-ce dans l'espace utilisateur ou noyau ? Y a-t-il du CPU steal (courant sur les instances cloud partagées) ?
• Mémoire : free -h, vmstat, /proc/meminfo — y a-t-il une pression mémoire ? Utilisation du swap ? L'OOM killer est-il actif (dmesg | grep -i oom) ?
• Disque : iostat -x 1, iotop — attente E/S élevée ? Quels processus font les E/S ? Sont-ce des lectures ou des écritures ?
• Réseau : netstat -s, ss -s, iftop — y a-t-il des problèmes d'épuisement de la table de connexions ? Des pertes de paquets ? Des retransmissions ?

Puis : « Une fois que j'ai identifié le goulot d'étranglement de ressources, je regarderais les journaux d'application aux côtés de la chronologie des ressources pour corréler le ralentissement avec des requêtes ou événements spécifiques. »

« Écrivez un script pour trouver les 10 premiers processus par utilisation mémoire. »

Les questions de script testent si vous pouvez écrire du code fonctionnel rapidement, pas du code parfaitement optimisé. Une réponse correcte : ps aux --sort=-%mem | head -11 (ou awk avec ps aux pour plus de contrôle). Points bonus pour mentionner que les snapshots ps pourraient ne pas refléter les pics transitoires et que vous préféreriez peut-être top -b -n 1 pour une sortie batch en une seule passe ou /proc/<pid>/status pour plus de détails.

Les questions sur les incidents et la fiabilité

« Parlez-moi d'un incident que vous avez géré. Que s'est-il passé, et qu'avez-vous fait ? »

La question comportementale la plus importante dans un entretien DevOps. Le recruteur évalue : comment vous diagnostiquez sous pression, comment vous communiquez pendant un incident, la profondeur de votre compréhension technique et vos habitudes post-incident.

Une bonne histoire d'incident comporte : une chronologie claire (quand vous avez remarqué pour la première fois, quels étaient les symptômes initiaux, quel était l'impact sur les affaires), un récit de diagnostic (ce que vous avez vérifié, ce que vous avez exclu, quelle était la cause fondamentale), une résolution (atténuation temporaire vs. correction permanente) et une rétrospective (ce que l'incident a révélé sur les faiblesses du système et ce qui a changé par la suite).

Les meilleurs candidats montrent qu'ils ont appris quelque chose de l'incident qui a changé la façon dont ils construisent ou opèrent les systèmes. Cette boucle d'apprentissage — incident → compréhension → amélioration systémique — est la signature d'un ingénieur DevOps mature.

Préparer la composante conception de système

De nombreux entretiens DevOps seniors incluent une question de conception de système spécifique à l'infrastructure : « Concevez un système de journalisation et de surveillance pour une architecture de microservices » ou « Comment concevriez-vous l'infrastructure pour une API distribuée mondialement avec un SLA de 99,99 % ? »

Ces questions ne portent pas principalement sur la connaissance des bonnes réponses exactes. Elles portent sur la démonstration d'un processus de pensée structuré : clarifier d'abord les exigences (volume de trafic, distribution géographique, SLA de latence, contraintes de coût), identifier les décisions de conception clés et les compromis, construire à partir des fondamentaux et être explicite sur ce que vous optimisez.

Préparer votre CV pour refléter ce type de pensée systémique — pas seulement la maîtrise des outils — est la base de ces conversations. Des outils comme NextCV peuvent vous aider à formuler votre expérience en termes de résultats et de schémas de raisonnement que les recruteurs DevOps recherchent, plutôt qu'en termes de liste de technologies que vous avez utilisées.

La vérité sous-jacente des entretiens DevOps est que les outils sont largement interchangeables — Kubernetes vs. ECS, Jenkins vs. GitHub Actions, Prometheus vs. Datadog. Ce qui n'est pas interchangeable, c'est l'état d'esprit : propriété opérationnelle, pensée systémique et la discipline de construire des choses qui sont observables, fiables et maintenables.