Les fondamentaux de la supervision que les recruteurs attendent
Avant toute chose, un recruteur veut vérifier que vous comprenez à quoi sert la supervision. La bonne réponse n’est pas « collecter des données » — c’est transformer l’état d’un système en signal exploitable par des humains. Sachez expliquer la différence entre la supervision d’hôtes (CPU, disque, mémoire), la supervision de services (l’API répond-elle, la chaîne batch est-elle à l’heure) et la supervision métier (les commandes passent-elles). Un bon candidat présente la supervision comme un moyen de réduire le temps moyen de détection (MTTD), pas seulement de remplir des tableaux de bord.
Attendez-vous à une question sur le cycle de vie de la supervision : collecter → stocker → visualiser → alerter → agir. Savoir nommer chaque étape et donner un exemple par étape montre que vous avez pratiqué, pas seulement lu un glossaire. Cela rejoint directement le quotidien d’un Spécialiste supervision.
Métriques, logs et traces — et quand utiliser chacun
Une question classique vous demande de distinguer les trois piliers de l’observabilité. Restez concret : les métriques sont des nombres dans le temps (CPU à 92 %, latence p95 à 340 ms) et peu coûteuses à stocker ; les logs sont des événements discrets et coûteux à grande échelle, donc on les échantillonne ou on les indexe ; les traces suivent une requête à travers les services et expliquent où le temps passe. Le recruteur enchaîne souvent avec « comment décidez-vous quoi instrumenter en premier ? » — une bonne réponse est de commencer par les métriques qui reflètent le comportement vu par l’utilisateur, puis d’ajouter des logs là où il faut du contexte, et des traces sur les chemins les plus lents.
- Métriques : agrégées, peu coûteuses, idéales pour les dashboards et l’alerting sur des seuils ou des taux.
- Logs : contexte détaillé, coûteux en volume, à rechercher quand une métrique signale un problème.
- Traces : liées à une requête, l’outil qu’on sort quand la latence est le symptôme.
L’alerting et la qualité des alertes
La fatigue d’alerte est le sujet que les recruteurs adorent. Sachez expliquer à quoi ressemble une bonne alerte : elle est actionnable (il y a quelque chose à faire), spécifique (on sait quel système) et orientée symptôme quand c’est possible (alerter sur « les utilisateurs ne peuvent pas se connecter » plutôt que sur « le CPU est haut »). Discutez seuils contre taux, le danger d’alerter sur des compteurs bruts, et l’intérêt du regroupement d’alertes et des fenêtres de maintenance. Si vous savez expliquer pourquoi alerter sur la saturation sans contexte génère des pages à 3 h du matin auxquelles personne ne réagit, vous parlez la langue du métier.
Relance fréquente : « Comment réduiriez-vous le nombre d’alertes sans perdre de signal ? » Bonne réponse : régler les seuils à partir de l’historique, regrouper les alertes liées, supprimer les alertes qui n’ont jamais conduit à une action, et privilégier les alertes symptôme aux alertes de ressource bas niveau.
Incidents, escalade et communication
Les entretiens d’exploitation incluent presque toujours une mise en situation : « Une alerte critique se déclenche à 2 h du matin — décrivez-moi ce que vous faites. » On ne cherche pas la réponse technique parfaite ; on cherche une méthode. Une structure fiable : prendre en compte et trier → consulter le dashboard et les changements récents → formuler une hypothèse → agir ou escalader → communiquer le statut → documenter. Mentionner que vous vérifieriez le journal des changements et les déploiements récents avant de supposer un problème de capacité montre de vrais réflexes de production.
Explorer les métiers liés
L’escalade est un sujet à part. Sachez expliquer quand vous escaladez (quand l’incident dépasse votre niveau d’accès, quand le délai de réponse convenu est dépassé, quand une seconde alerte critique survient) et comment — avec du contexte, pas juste « c’est cassé ». La communication claire pendant un incident est une compétence très pondérée par les recruteurs, car un Analyste salle d’exploitation ou un Manager run vit ou meurt par elle.
Bases Linux et troubleshooting
Même dans un rôle centré sur la supervision, attendez-vous à des questions pratiques sur Linux : comment vérifier ce qui consomme le CPU (top, htop, pidstat), l’utilisation disque (df, du), la mémoire (free, vmstat) et la connectivité réseau (ss, ping, dig). On peut vous demander de lire une ligne de log et de l’expliquer, ou de décrire comment trouver le processus qui écoute sur un port. Ce sont les mêmes fondamentaux que dans notre guide Compétences Linux essentielles pour l’exploitation IT — si vous êtes fragile dessus, révisez avant l’entretien.
Les mises en situation et comment y répondre
Les mises en situation testent la pensée structurée. Utilisez un cadre simple : clarifiez la situation, posez vos hypothèses, décrivez vos étapes dans l’ordre, et dites ce que vous communiqueriez et à qui. Dire « je vérifierais X avant de faire Y » est tout à fait acceptable — cet ordre est précisément ce qu’on veut voir. Deux scénarios à répéter :
- La latence d’une API exposée aux clients augmente mais aucune erreur n’est loguée. Parcourez métriques → changements récents → dépendances → traces.
- Un batch qui se termine d’habitude à 03:10 tourne encore à 04:30. Comment décidez-vous de le tuer, d’attendre ou d’escalader ?
Concepts d’observabilité qui complètent un bon profil
Si le poste penche moderne, soyez prêt à discuter SLI (indicateur de niveau de service), SLO (objectif de niveau de service) et budgets d’erreur à un niveau général. Vous n’avez pas besoin d’être SRE, mais savoir qu’un SLO est une cible et qu’un budget d’erreur est la marge restante montre de la maturité. Mentionner OpenTelemetry comme standard émergent pour instrumenter métriques, logs et traces de façon neutre vis-à-vis des éditeurs est un signal sûr et exact. De là, l’étape naturelle est le rôle décrit sur la fiche Spécialiste supervision, puis l’ingénierie de fiabilité.
Comment préparer dans les jours qui précèdent l’entretien
- Relisez la fiche de poste et reliez chaque exigence à un exemple concret de votre expérience.
- Ouvrez un outil de supervision que vous connaissez et expliquez un dashboard à voix haute, comme à un nouveau collègue.
- Préparez deux courts récits d’incident au format situation–action–résultat.
- Révisez les commandes Linux que vous lanceriez réellement pendant un incident en direct.
Prochaines étapes
Associez cette préparation au guide carrière complet Comment devenir Monitoring Specialist et au guide pratique Compétences Linux essentielles pour l’exploitation IT. Quand vous serez prêt à prouver les compétences sur papier, notre panorama Quelles certifications pour une carrière en exploitation IT ? explique quelles certifications valent votre temps pour une carrière en exploitation.