arrow_backRetour aux notes de terrain
BLUE TEAM Publié 13 Jul 2026

Survivre à vos 90 premiers jours en tant qu'analyste SOC

Une feuille de route pratique pour les nouveaux analystes SOC couvrant l'intégration, le triage des alertes, les outils et les habitudes qui construisent rapidement la crédibilité.

Débuter un rôle d'analyste SOC est excitant et désorientant à la fois. Vous avez accès à une douzaine d'outils, une file d'attente d'alertes et des attentes vagues sur la vitesse à laquelle vous devriez détecter les menaces réelles. Les 90 premiers jours définissent la trajectoire de toute votre carrière dans ce rôle, donc il vaut mieux les aborder délibérément plutôt que de simplement les traverser.

Semaines 1-2 : Assimilez avant d'agir

Résistez à l'envie de commencer immédiatement à fermer des tickets comme un vétéran. Au départ, votre travail consiste à comprendre l'environnement : à quoi ressemble le trafic normal, quels sont les actifs critiques, quel est le chemin d'escalade et qui possède quoi. Lisez les runbooks même s'ils sont obsolètes — les runbooks obsolètes vous en disent beaucoup sur les lacunes de connaissances tribales que vous devrez combler plus tard.

Passez du temps dans le SIEM en interrogeant simplement, pas en triant. Familiarisez-vous avec les sources de données qui l'alimentent : les journaux de pare-feu, la télémétrie EDR, les journaux DNS, les journaux d'authentification. Si vous ne savez pas où se trouve une source de journal ou comment elle est normalisée, demandez maintenant. Personne ne s'attend à la maîtrise la première semaine, et les questions posées tôt sont perçues comme de la diligence, pas comme de l'incompétence.

Semaines 3-5 : Observez, puis triez sous supervision

C'est à ce moment que vous commencez à traiter les alertes réelles, mais en étant jumelé à un analyste senior ou avec un partenaire d'escalade clair. Concentrez-vous sur la construction d'une habitude de triage répétable :

  • Confirmez que l'alerte s'est déclenchée correctement — vérifiez le journal brut, pas seulement le résumé de l'alerte.
  • Établissez le contexte — est-ce que cet actif est une station de travail, un serveur, un compte de service ? Quel est son comportement de base ?
  • Évaluez le rayon d'explosion — est-ce que cela a touché d'autres hôtes, d'autres comptes, d'autres périodes ?
  • Documentez au fur et à mesure — vos notes d'aujourd'hui sont la connaissance institutionnelle sur laquelle quelqu'un d'autre s'appuiera dans six mois.

Une erreur courante à ce stade est de fermer les alertes trop rapidement pour paraître efficace. La vitesse compte finalement, mais la précision et le raisonnement comptent plus pour le moment. Un analyste senior peut vous enseigner des raccourcis plus tard ; il ne peut pas facilement défaire les mauvaises habitudes.

Semaines 6-8 : Développez votre instinct de playbook personnel

À ce stade, vous devriez gérer les types d'alertes courants — signalements de phishing, tentatives de brute-force, exécution PowerShell suspecte — avec moins d'aide. Commencez à remarquer les motifs que les règles de détection existantes manquent. Peut-être qu'une alerte particulière se déclenche toujours sur une tâche de sauvegarde bénigne. Peut-être qu'une technique réelle continue de passer à travers parce que la logique de la règle est trop étroite. Apportez ces observations à votre équipe ; proposer des suggestions de tuning à ce stade signale de l'initiative. C'est aussi le moment de vous familiariser avec les recherches de menaces de base — vérifier les IPs, les hashes et les domaines par rapport à des sources comme VirusTotal ou la plateforme de renseignements sur les menaces de votre organisation — et de comprendre comment ce contexte change la gravité d'une alerte.

Semaines 9-12 : Prenez la responsabilité et demandez des commentaires

Dans la dernière ligne droite, cherchez plus d'autonomie sur votre poste tout en confirmant les escalades avant de fermer quoi que ce soit d'ambigu. Commencez à suivre vos propres métriques de manière informelle : combien d'alertes vous avez traitées, combien étaient des faux positifs, combien de fois vous avez dû rouvrir quelque chose. Ce n'est pas une question de prouver la productivité — c'est une question de remarquer où votre jugement est solide et où il a encore besoin d'ajustement.

Demandez directement à votre supérieur : « Qu'est-ce que j'oublie qu'un analyste plus expérimenté détecterait ? » La plupart des responsables SOC respectent bien plus une demande directe de commentaires qu'une incertitude silencieuse. C'est aussi un bon moment pour identifier un intérêt de spécialisation — ingénierie de détection, threat hunting, réponse aux incidents, analyse de malware — car le travail SOC ouvre de nombreuses portes, et montrer de la curiosité pour un chemin spécifique aide à façonner la façon dont votre responsable vous assigne des tâches d'apprentissage.

Habitudes à cultiver dès le premier jour

Quelques éléments sont utiles quel que soit l'outillage ou le niveau de maturité de votre SOC :

  • Écrivez des notes claires, horodatées sur chaque investigation, même les fermées.
  • Apprenez la topologie du réseau, pas seulement les champs des journaux — savoir ce qui est censé communiquer avec quoi rend les anomalies évidentes plus rapidement.
  • Pratiquez la rédaction de résumés d'incidents qu'un responsable non technique pourrait comprendre ; cette compétence se multiplie tout au long de votre carrière.
  • Restez curieux au sujet des faux positifs — ajuster les mauvaises détections est souvent plus utile que de fermer rapidement les tickets.

Les 90 premiers jours ne consistent pas à devenir un expert. Ils consistent à développer le jugement, les habitudes et les relations qui vous permettront d'en devenir un au cours des prochaines années.

Si vous souhaitez affiner les fondamentaux techniques derrière le travail SOC — l'analyse des journaux, les fondamentaux du réseau ou les flux de travail de réponse aux incidents — explorez les segments Blue Team et Digital Forensics connexes sur Korra Studio.

Rédigé avec l'aide de l'IA, relu et publié par Michal Pilch (CISSP), Korra Studio.

Prêt à aller plus loin ?

Ceci est une note de la base de connaissances de Korra Studio — la plateforme associe chaque sujet à un mentorat individuel.

Commencer gratuitementarrow_forward