Les entretiens DevOps évaluent votre capacité à livrer des logiciels de manière fiable : comment le code passe d'un ordinateur portable à la production, comment vous savez qu'il est en bonne santé, et ce que vous faites quand ce n'est pas le cas. Voici 20 questions avec réponses, des bases aux questions de mise en situation qui décident de la plupart des entretiens. Lorsqu'une commande est indiquée, il s'agit d'une commande standard que vous pouvez vérifier dans la documentation de l'outil concerné.
Fondamentaux
1. Qu'est-ce que le DevOps ?
Une façon de travailler qui rassemble le développement et les opérations afin que le logiciel soit construit, testé, publié et exploité par un même processus partagé. Les objectifs sont des releases plus rapides et plus sûres, et un rétablissement plus rapide en cas de panne. C'est une culture et un ensemble de pratiques, avec des outils en support, et non un simple intitulé de poste.
2. Quelle est la différence entre l'intégration continue, la livraison continue et le déploiement continu ?
| Pratique | Ce que cela signifie |
|---|---|
| Intégration continue | Les développeurs fusionnent souvent de petites modifications, et chaque fusion déclenche une compilation et une exécution de tests automatisées |
| Livraison continue | Chaque modification qui passe le pipeline est prête à être publiée, et une personne décide du moment |
| Déploiement continu | Chaque modification qui passe le pipeline est publiée automatiquement en production |
3. Quels sont les indicateurs clés pour la livraison logicielle ?
Quatre sont largement utilisés, issus du programme de recherche DORA : la fréquence de déploiement, le délai de livraison des modifications, le taux d'échec des changements et le temps de rétablissement du service. Les deux premiers mesurent la vitesse, les deux derniers mesurent la stabilité. Une bonne réponse explique que vous suivez les quatre afin de ne pas améliorer la vitesse au détriment de la stabilité.
4. À quoi ressemble un bon pipeline CI ?
- Récupérer le code et restaurer les dépendances mises en cache.
- Compiler.
- Exécuter d'abord les tests rapides (tests unitaires), puis les plus lents.
- Lancer les vérifications statiques, comme le linting et une analyse des vulnérabilités des dépendances.
- Construire un artefact (une image de conteneur ou un paquet) une seule fois et l'étiqueter avec le commit.
- Le publier, et déployer le même artefact dans chaque environnement.
L'idée clé est de construire une fois et de promouvoir le même artefact, afin que ce que vous avez testé soit ce que vous livrez.
Gestion de versions et releases
5. Comment gérez-vous les branches et les releases ?
Deux approches courantes. Le développement basé sur le tronc (trunk-based) fusionne souvent de petites modifications sur la branche principale, avec des feature flags pour masquer le travail inachevé. Les workflows basés sur les branches, comme GitFlow, utilisent des branches de longue durée pour les releases. Le développement basé sur le tronc s'associe généralement mieux à la livraison continue, car les fusions sont petites et fréquentes.
6. Que sont les déploiements blue-green et canary ?
| Stratégie | Comment ça marche | Retour arrière |
|---|---|---|
| Blue-green | Deux environnements identiques. Déployer sur celui qui est inactif, le tester, puis basculer le trafic | Rebasculez le trafic |
| Canary | Envoyer une petite part du trafic vers la nouvelle version, surveiller les métriques et augmenter progressivement | Ramenez la part à zéro |
| Rolling | Remplacer les instances quelques-unes à la fois | Avancez ou inversez le déploiement |
Le blue-green coûte de la capacité supplémentaire. Le canary nécessite de bonnes métriques, car vous décidez à partir des données.
7. Qu'est-ce qu'un feature flag, et pourquoi en utiliser un ?
Un interrupteur dans la configuration qui active ou désactive une fonctionnalité sans déploiement. Il sépare le déploiement du code de la mise à disposition d'une fonctionnalité, vous permet de tester avec un petit groupe et vous offre un moyen rapide de désactiver en cas de problème. Le coût, c'est que les anciens flags s'accumulent, alors supprimez-les une fois une fonctionnalité stabilisée.
8. Comment effectuer un retour arrière en toute sécurité ?
Gardez l'artefact précédent disponible, rendez les déploiements reproductibles et assurez la compatibilité ascendante des modifications de base de données, afin que l'ancienne version fonctionne toujours avec le nouveau schéma. Un plan de retour arrière qui ignore la base de données n'est pas un plan. Pour les changements risqués, préférez avancer avec un correctif lorsqu'un retour arrière entraînerait une perte de données.
Infrastructure et conteneurs
9. Qu'est-ce que l'infrastructure as code ?
Définir les serveurs, les réseaux et les permissions dans des fichiers versionnés plutôt que de cliquer dans une console. Cela rend les environnements reproductibles, vérifiables et faciles à reconstruire. Les outils courants incluent Terraform, Pulumi et les templates propres aux fournisseurs cloud. Voir nos questions d'entretien sur Terraform.
10. Quelle est la différence entre un conteneur et une machine virtuelle ?
Une machine virtuelle embarque un système d'exploitation invité complet au-dessus d'un matériel virtualisé. Un conteneur partage le noyau de l'hôte et n'emballe que l'application et ses dépendances, ce qui le rend plus rapide à démarrer et moins gourmand en mémoire. Les conteneurs offrent un niveau d'isolation inférieur à celui d'une machine virtuelle.
11. Que contient un bon Dockerfile ?
Utiliser une image de base petite et précise, ordonner les couches pour que celles qui changent le moins arrivent en premier (afin de profiter du cache de build), copier les fichiers de dépendances et les installer avant de copier le code source, exécuter le conteneur avec un utilisateur non root, et ne pas intégrer de secrets dans l'image. Les builds multi-étapes permettent de garder les outils de build hors de l'image finale.
12. Pourquoi Kubernetes ?
Il planifie les conteneurs sur plusieurs machines, redémarre ceux qui échouent, les met à l'échelle et gère les mises à jour progressives ainsi que la découverte de services. Il ajoute aussi beaucoup de complexité, donc une bonne réponse indique quand on ne l'utiliserait pas, par exemple pour une petite application qui tient sur quelques serveurs ou sur une plateforme managée. Voir nos questions d'entretien sur Kubernetes.
13. Comment gérer les secrets ?
Ne jamais les mettre dans le contrôle de source ni dans les images. Utiliser un gestionnaire de secrets ou le coffre-fort de secrets de la plateforme, donner à chaque service le minimum d'accès nécessaire, faire tourner les secrets et éviter de les afficher dans les logs. Expliquer ce que vous feriez en cas de fuite : le révoquer, le faire tourner et vérifier les logs pour détecter toute utilisation.
Fiabilité et exploitation
14. Que sont le monitoring, le logging et le tracing ?
| Signal | Ce qu'il vous apprend |
|---|---|
| Métriques | Comment le système se comporte dans le temps, comme le taux d'erreur et la latence |
| Logs | Ce qui s'est passé lors d'un événement précis |
| Traces | Comment une requête a circulé à travers plusieurs services |
Alertez sur les symptômes que ressentent les utilisateurs, comme les erreurs et les réponses lentes, plutôt que sur les causes, comme un CPU élevé sur une machine.
15. Que sont les SLI, SLO et SLA ?
Un service level indicator est une mesure, comme la part de requêtes qui réussissent. Un service level objective est l'objectif associé, comme 99,9 % sur 30 jours. Un service level agreement est une promesse faite aux clients, souvent assortie de conséquences en cas de manquement. L'écart entre 100 % et le SLO constitue un budget d'erreur : la marge dont vous disposez pour le risque et le changement.
16. Un service en production est lent. Que faites-vous ?
- Vérifier si le problème est réel et qui est touché, à l'aide des dashboards et des taux d'erreur.
- Regarder ce qui a changé récemment : un déploiement, un changement de configuration, un pic de trafic.
- Circonscrire le problème : un endpoint, une région ou une dépendance en particulier.
- Examiner les ressources (CPU, mémoire, connexions) et les services en aval.
- Si un changement récent est la cause probable, revenir en arrière d'abord et enquêter ensuite.
- Communiquer sur l'état d'avancement pendant que vous travaillez.
Les recruteurs écoutent une démarche calme et ordonnée, et le fait d'atténuer l'incident avant de chercher la cause racine.
17. Qu'est-ce qu'un postmortem sans blâme ?
Une analyse écrite après un incident qui se concentre sur la façon dont le système et le processus ont permis la défaillance, et non sur la personne qui a commis une erreur. Elle couvre la chronologie, l'impact, les causes et des actions de suivi concrètes avec des responsables. L'objectif est d'apprendre et de rendre la même défaillance plus difficile à reproduire.
18. Quelle est la différence entre le scaling horizontal et vertical ?
Le scaling vertical donne plus de ressources à une machine. Le scaling horizontal ajoute davantage de machines. Le vertical est simple mais plafonne et constitue un point de défaillance unique. L'horizontal monte plus loin et survit à la perte d'une machine, mais nécessite des services sans état ou un état partagé.
Pratique
19. Comment sécuriser un pipeline ?
Limiter qui peut modifier le pipeline et qui peut déployer en production. Scanner les dépendances et les images à la recherche de vulnérabilités connues, signer et vérifier les artefacts, garder des identifiants à durée de vie courte et à portée restreinte, et relire les modifications des fichiers de pipeline comme du code. Un agent de build disposant de permissions étendues est une cible de choix.
20. Parlez-moi d'un déploiement qui s'est mal passé.
C'est une question comportementale au sein d'un entretien technique. Racontez une histoire courte : ce qui a changé, comment vous l'avez remarqué, ce que vous avez fait en premier (généralement atténuer, souvent en revenant en arrière), ce que vous avez découvert, et ce que vous avez changé ensuite pour que cela ne se reproduise pas. Un vocabulaire sans blâme et un suivi concret sont ce que recherchent les recruteurs.
Comment se préparer
- Mettez en place un petit pipeline de bout en bout : un dépôt, un build, une exécution de tests, un conteneur et un déploiement vers quelque chose d'accessible.
- Préparez-vous à raconter un incident ou une release ratée que vous avez vécu.
- Entraînez-vous à répondre à la question « le service est lent » à voix haute, jusqu'à ce que votre réponse devienne une liste calme et ordonnée.
- Maîtrisez bien un outil dans chaque domaine, comme le CI, les conteneurs, l'infrastructure as code et la supervision, plutôt que de citer une longue liste de noms.
Pour vous entraîner sur des sujets proches, consultez nos guides sur les questions d'entretien AWS, les questions d'entretien Terraform, les questions d'entretien Kubernetes et les questions d'entretien en réseaux informatiques.
Entraînez-vous à voix haute et avec vos propres mots. Une transcription par la suite vous montre où vous avez divagué ou manqué l'essentiel. Respectez les règles de l'employeur concernant les outils d'IA lors de tout entretien ou test en direct.
Entraînez vos réponses avec YesToTheOffer
Répétez à voix haute, obtenez des réponses construites à partir de votre propre CV, et consultez votre transcription ensuite. 30 minutes gratuites, sans abonnement.
