Entretien DevOps : réussir l'exercice d'incident et de mise en situation
· 8 min
Sur un poste DevOps, la mise en situation d'incident est l'exercice le plus révélateur — et le plus mal préparé. On vous annonce une panne, et on vous regarde réfléchir. L'ordre dans lequel vous faites les choses en dit plus long que la solution que vous trouvez.
Quel est le bon ordre des réflexes ?
Rétablir d'abord, comprendre ensuite. Beaucoup de candidats se jettent sur la cause racine alors que le service est encore à terre. Un exploitant expérimenté commence par mesurer l'impact, communiquer, puis chercher le retour arrière le plus rapide — un déploiement précédent, un basculement, une désactivation de fonctionnalité. L'analyse vient après, à froid.
- Constater : que voit l'utilisateur, depuis quand, et sur quel périmètre.
- Prévenir : qui doit savoir, avant même que la cause soit connue.
- Stabiliser : revenir à un état connu, quitte à perdre la dernière livraison.
- Comprendre : une fois le service rétabli, et pas avant.
- Corriger durablement : le correctif, puis ce qui empêchera la récidive.
Que révèle votre façon de chercher la cause ?
Votre méthode. « Je regarde les logs » est une réponse faible. « Je regarde ce qui a changé dans les dernières heures — déploiement, configuration, certificat expiré, montée de charge — parce que 80 % des pannes suivent un changement » montre que vous avez vécu la situation. Nommer où vous regardez, dans quel ordre, et pourquoi, vaut mieux que citer des outils.
La question de suivi que presque personne n’anticipe
« Et si le retour arrière ne fonctionne pas ? » C'est là que l'entretien se joue vraiment. On teste votre capacité à ne pas rester bloqué sur un plan unique : avez-vous un plan B, savez-vous dégrader le service plutôt que de le laisser tomber entièrement, savez-vous à quel moment escalader plutôt que de continuer seul ? Préparez cette réponse-là aussi.
Faut-il parler de post-mortem ?
Oui, et sans en faire un mot-clé. Ce qui compte est la culture que vous décrivez : un post-mortem sans blâme, où l'on cherche ce que le système a permis plutôt que qui s'est trompé. Si vous ajoutez ce qui a réellement changé après — une alerte ajoutée, un test de non-régression, une procédure simplifiée — vous démontrez que vous fermez la boucle.
Comment répondre si vous n’avez jamais géré d’incident majeur ?
Dites-le, puis racontez le plus proche que vous ayez vécu, même modeste : un environnement de test cassé, un déploiement raté, un certificat expiré. Le raisonnement se démontre à petite échelle. Prétendre une expérience d'astreinte que vous n'avez pas est le meilleur moyen de vous faire démonter par deux questions de suivi.
En incident, on n'attend pas de vous que vous sachiez. On attend que vous sachiez quoi faire quand vous ne savez pas.
Les questions techniques classiques restent à préparer par ailleurs : nous les détaillons dans entretien DevOps, et l'angle architecture est traité dans l'entretien ingénieur cloud.