Prompts généraux Copilot Security : administration, formation et productivité SOC

Écriture fichier refusée elle aussi (session non-interactive, aucune approbation possible). Voici l'article complet — ~4 600 mots, 40 prompts, 16 H2, 5 H3 FAQ interrogatives, encadré `.a-retenir`, 5 liens internes / 3 externes : ```html

Microsoft Security Copilot ne tient pas ses promesses avec des questions vagues. Un analyste qui écrit « analyse cet incident » obtient une paraphrase ; celui qui écrit « résume l'incident 4821 en trois lignes pour un manager non technique, en précisant le vecteur initial, les comptes touchés et l'action de confinement déjà réalisée » obtient un livrable directement copiable dans un ticket. L'écart entre les deux ne tient pas au modèle : il tient à la qualité du prompt. Ce guide rassemble quarante prompts prêts à l'emploi, testés dans des contextes SOC réels, couvrant cinq usages transverses souvent négligés au profit du seul triage d'alertes : l'administration de la plateforme, la formation des analystes, la production documentaire, le reporting vers la direction et la productivité quotidienne. Chaque prompt est accompagné de l'output que vous devez réellement obtenir et des prérequis techniques — plugin activé, licence, périmètre de permissions — sans lesquels la réponse sera vide ou incomplète. L'objectif est opérationnel : que vous puissiez ouvrir Security Copilot, coller un prompt, ajuster deux variables et disposer d'un résultat exploitable en moins de cinq minutes.

Pourquoi un référentiel de prompts généraux, et pas seulement des prompts de détection

La documentation Microsoft et la majorité des ressources communautaires se concentrent sur un cas d'usage : l'investigation. C'est légitime — c'est là que le retour sur investissement est le plus visible. Mais dans un SOC de dix personnes, l'investigation représente rarement plus de 40 % du temps de travail. Le reste se répartit entre la production documentaire, le reporting, l'administration des outils, la formation continue et un ensemble de micro-tâches répétitives qui grignotent les journées sans jamais figurer dans un KPI.

Ces activités « périphériques » sont précisément celles où un assistant génératif produit le gain le plus net, pour une raison simple : elles sont textuelles, structurées, et le coût d'une erreur y est faible et détectable. Un runbook mal formulé se corrige en relecture ; une décision de confinement erronée coûte beaucoup plus cher. Commencer par ces usages permet aussi d'installer l'outil dans les habitudes de l'équipe sans engager la responsabilité opérationnelle dès le premier jour.

Ce guide part donc du principe inverse de l'approche habituelle : on couvre d'abord ce qui entoure l'investigation. Pour les prompts spécifiques à chaque produit — Defender XDR, Sentinel, Intune, Entra, Purview — référez-vous à la référence des prompts Copilot Security par produit, qui traite le sujet plugin par plugin. Pour l'industrialisation des séquences décrites ici, la page dédiée aux promptbooks Security Copilot explique comment transformer un enchaînement manuel en actif partagé.

Anatomie d'un prompt exploitable : la structure en quatre blocs

Avant les quarante prompts, une grille de lecture. Tous ceux qui suivent respectent la même structure, et c'est cette structure — plus que le vocabulaire employé — qui détermine la qualité de la réponse.

Le rôle et l'objectif. On indique à Security Copilot ce qu'il produit et pour qui. « Rédige une procédure destinée à un analyste N1 qui vient d'arriver » ne donne pas le même texte que « rédige une procédure destinée au RSSI ». Le niveau de détail, le vocabulaire et la longueur s'ajustent automatiquement.

Le contexte de données. On précise la source : un identifiant d'incident, un nom d'utilisateur, une plage temporelle, un nom de politique. Sans ancrage, le modèle produit du générique — utile pour de la formation, inutile pour de l'opérationnel.

Les contraintes de format. Nombre de lignes, tableau, liste numérotée, présence ou absence de jargon. C'est le bloc le plus rentable : il évite deux ou trois allers-retours de reformulation.

Le critère de qualité. On indique ce qui rend la réponse acceptable : « signale explicitement les points que tu ne peux pas vérifier avec les données disponibles », « n'inclus aucune recommandation qui nécessiterait un changement de licence ». Cette dernière phrase est ce qui distingue un prompt d'amateur d'un prompt de production.

Catégorie 1 — Administrer Security Copilot au quotidien (8 prompts)

L'administration de la plateforme est le parent pauvre des guides de prompting, alors que c'est là que les blocages surviennent le plus souvent. Un analyste dont le prompt renvoie « je n'ai pas accès à ces données » perdra confiance dans l'outil s'il n'a pas les moyens de diagnostiquer lui-même la cause : plugin désactivé, rôle insuffisant, ou consommation de SCU épuisée.

Prompt 01 — Inventorier les plugins actifs et leur portée

« Liste les plugins actuellement activés dans mon environnement Security Copilot. Pour chacun, indique le produit source, le type de données auxquelles il donne accès, et s'il est activé au niveau du tenant ou uniquement pour mon compte. Présente le résultat sous forme de tableau à quatre colonnes. »

Output attendu : un tableau recensant les plugins Microsoft activés (Defender XDR, Sentinel, Entra, Intune, Purview, Threat Intelligence, EASM selon votre configuration), avec pour chacun la portée des données interrogeables. Security Copilot distingue les plugins activés par l'owner pour tout le tenant de ceux qu'un contributeur a activés pour sa seule session — cette distinction explique la majorité des différences de résultats entre deux analystes.

Prérequis : accès à Security Copilot (expérience autonome) ; le détail « tenant vs utilisateur » n'apparaît de façon fiable que pour un compte disposant du rôle owner. Aucun plugin tiers requis.

Prompt 02 — Diagnostiquer un plugin qui ne répond pas

« Le plugin Microsoft Sentinel ne retourne aucun résultat pour mes requêtes. Liste les causes possibles par ordre de probabilité : configuration du plugin, permissions RBAC sur l'espace de travail, absence de données sur la période interrogée, ou formulation du prompt. Pour chaque cause, indique la vérification concrète à effectuer et où la faire dans le portail. »

Output attendu : une liste ordonnée de quatre à six hypothèses, chacune assortie d'un point de contrôle localisé (paramètres du plugin, attribution de rôle sur le workspace, requête KQL de vérification de volumétrie). Security Copilot ne teste pas lui-même vos permissions : il produit une checklist de diagnostic que vous exécutez.

Prérequis : aucun plugin particulier pour obtenir la checklist ; pour exécuter les vérifications, un rôle lecteur sur l'espace de travail Sentinel concerné.

Prompt 03 — Vérifier les permissions effectives d'un utilisateur

« Quels rôles Microsoft Entra et quelles permissions RBAC sont nécessaires pour qu'un analyste puisse utiliser Security Copilot avec les plugins Defender XDR et Sentinel en lecture seule ? Distingue ce qui relève du rôle Security Copilot lui-même de ce qui relève des permissions sur les produits sources. »

Output attendu : une réponse en deux volets. Premier volet : le rôle applicatif Security Copilot (owner ou contributor) qui conditionne l'accès à la plateforme et la capacité à modifier les paramètres. Second volet : le principe fondamental selon lequel Security Copilot n'élargit jamais les droits — un analyste ne voit à travers Copilot que ce qu'il verrait dans le portail source. La réponse doit expliciter cette double condition, qui est la source de confusion la plus fréquente.

Prérequis : accès à Security Copilot. Pour appliquer les recommandations, un rôle d'administration Entra permettant l'attribution de rôles.

Prompt 04 — Auditer les sessions des trente derniers jours

« Résume l'activité Security Copilot de mon organisation sur les trente derniers jours : nombre de sessions, utilisateurs les plus actifs, plugins les plus sollicités et répartition des usages par grande catégorie. Signale toute anomalie, notamment une concentration inhabituelle de sessions sur un compte unique ou en dehors des heures ouvrées. »

Output attendu : une synthèse quantitative accompagnée d'une lecture qualitative. L'intérêt réel n'est pas le comptage — disponible dans le tableau de bord d'utilisation — mais la mise en évidence de motifs : un compte de service qui génère des sessions, ou un pic nocturne qui mérite une vérification.

Prérequis : rôle owner sur Security Copilot pour accéder aux données d'utilisation à l'échelle du tenant ; journalisation d'audit Microsoft Purview active pour disposer de l'historique complet.

Prompt 05 — Analyser la consommation de SCU et identifier les gaspillages

« Explique comment la consommation d'unités de calcul de sécurité (SCU) est facturée dans Security Copilot, quels types de prompts consomment le plus, et donne-moi cinq pratiques concrètes pour réduire la consommation sans dégrader la qualité des réponses. »

Output attendu : une explication du modèle de provisionnement horaire des SCU, suivie de recommandations exploitables : privilégier les prompts précis aux formulations exploratoires, éviter de relancer une session complète pour une reformulation mineure, utiliser les promptbooks pour éliminer les tâtonnements, et calibrer la capacité provisionnée sur les heures de forte activité plutôt que sur un pic ponctuel.

Prérequis : accès à Security Copilot ; le suivi effectif de la consommation nécessite le rôle owner et l'accès à la page de gestion de la capacité.

Prompt 06 — Préparer l'activation d'un plugin personnalisé

« Je souhaite créer un plugin personnalisé pour interroger notre référentiel d'actifs interne via son API REST. Décris les étapes de création d'un manifeste de plugin, les informations que je dois collecter auprès de l'équipe qui gère l'API, et les points de sécurité à valider avant activation en production. »

Output attendu : une procédure en étapes couvrant la structure du manifeste, le mode d'authentification retenu, la définition des compétences exposées, et une liste de contrôles de sécurité — gestion des secrets, périmètre minimal des données exposées, traçabilité des appels. Attendez-vous à un cadre méthodologique, pas à un manifeste prêt à déployer : la génération de fichiers de configuration exacts demande une validation manuelle systématique.

Prérequis : rôle owner pour le téléversement d'un plugin personnalisé ; accès à la documentation de l'API cible.

Prompt 07 — Rédiger la politique interne d'usage de Security Copilot

« Rédige une politique interne d'usage de Security Copilot pour une équipe SOC de douze personnes. Couvre : les usages autorisés et interdits, la règle de validation humaine avant toute action, le traitement des données sensibles dans les prompts, la conservation de l'historique des sessions et les responsabilités de l'owner. Format : document structuré en sections numérotées, ton normatif. »

Output attendu : un document de deux à trois pages, directement adaptable, avec des formulations normatives (« l'analyste doit », « il est interdit de »). La section sur les données sensibles est celle à relire le plus attentivement : elle doit refléter votre classification interne, que Security Copilot ne connaît pas.

Prérequis : aucun plugin. Fonctionne en connaissance générale.

Prompt 08 — Construire un plan d'onboarding pour un nouvel analyste

« Construis un plan d'onboarding Security Copilot sur deux semaines pour un analyste N2 rejoignant l'équipe. Semaine 1 : prise en main et usages sans risque. Semaine 2 : usages opérationnels supervisés. Pour chaque jour, indique un objectif, une activité pratique et un critère de validation observable. »

Output attendu : un planning jour par jour, avec progression du sans-risque (documentation, formation) vers l'opérationnel supervisé (triage assisté avec revue). Les critères de validation sont le point fort de cet output : ils transforment un plan de formation en dispositif évaluable.

Prérequis : aucun. Le plan produit suppose en revanche que le nouvel analyste dispose déjà des accès aux produits sources.

Catégorie 2 — Former les analystes : expliquer, illustrer, ancrer (5 prompts)

Security Copilot est un excellent formateur pour une raison contre-intuitive : il ne se lasse jamais d'expliquer trois fois la même chose à trois niveaux différents. Un analyste junior qui hésite à demander une quatrième explication à son mentor la demandera sans réserve à un assistant. Cet usage ne consomme aucune donnée sensible et constitue le meilleur point d'entrée pour une équipe qui découvre l'outil.

Prompt 09 — Expliquer un concept à trois niveaux de profondeur

« Explique le concept de Kerberoasting à trois niveaux : d'abord en trois phrases pour un manager non technique, ensuite en un paragraphe pour un analyste N1, enfin en détail technique pour un analyste N3 incluant le mécanisme protocolaire exact et les artefacts observables. »

Output attendu : trois blocs distincts et réellement différenciés. Le niveau N3 doit mentionner le type de ticket concerné, l'algorithme de chiffrement exploité et les identifiants d'événements Windows pertinents. Si les trois blocs se ressemblent, c'est que la question portait sur un concept trop simple pour justifier cette structure.

Prérequis : aucun plugin. Le plugin Microsoft Defender Threat Intelligence enrichit la réponse avec des observations de campagnes réelles.

Prompt 10 — Générer un quiz d'évaluation calibré

« Génère un quiz de dix questions à choix multiples sur la détection des mouvements latéraux en environnement Active Directory, destiné à évaluer des analystes N1 après trois mois de poste. Quatre propositions par question, une seule correcte. Après chaque question, fournis la réponse et une explication de deux phrases indiquant pourquoi les autres propositions sont fausses. »

Output attendu : un quiz exploitable tel quel, avec des distracteurs plausibles — c'est le critère de qualité déterminant. Un quiz dont les mauvaises réponses sont grossières n'évalue rien. Précisez toujours le niveau et l'ancienneté visés : c'est ce qui calibre la difficulté.

Prérequis : aucun plugin.

Prompt 11 — Créer un cas pratique d'investigation fictif

« Crée un cas pratique d'investigation pour un exercice de formation : une compromission de compte à privilèges détectée par une connexion depuis un pays inhabituel. Fournis le contexte initial, cinq artefacts d'investigation cohérents entre eux (logs, alertes, événements), trois fausses pistes plausibles, et la chronologie réelle des faits que seul le formateur connaît. »

Output attendu : un scénario pédagogique complet en deux parties — le dossier remis aux stagiaires et la clé de correction. La cohérence entre les artefacts est le point à vérifier en relecture : horodatages, noms de comptes et adresses IP doivent concorder d'un artefact à l'autre.

Prérequis : aucun plugin. Utiliser exclusivement des données fictives pour ce type d'exercice.

Prompt 12 — Traduire une technique MITRE ATT&CK en exercice concret

« Prends la technique MITRE ATT&CK T1078 (comptes valides). Explique-la, puis conçois un exercice pratique de trente minutes permettant à un analyste de s'entraîner à la détecter : ce qu'il doit chercher, dans quelles sources de données, et quels indicateurs distinguent un usage légitime d'un usage malveillant. »

Output attendu : une fiche technique suivie d'un déroulé d'exercice minuté. La partie la plus utile est la dernière : la distinction légitime/malveillant, qui est exactement le point de bascule où les analystes juniors se trompent. Le référentiel MITRE ATT&CK reste la source à consulter en parallèle pour vérifier les sous-techniques mentionnées.

Prérequis : aucun plugin obligatoire ; le plugin Defender XDR permet d'ancrer l'exercice sur des sources de données réellement disponibles chez vous.

Prompt 13 — Décoder un script pour un analyste junior

« Voici un script PowerShell obfusqué extrait d'une alerte de test : [coller le script]. Explique ligne par ligne ce qu'il fait, dans un langage accessible à un analyste N1. Termine par les trois indicateurs qui auraient dû alerter dès la lecture des premières lignes. »

Output attendu : un décodage commenté ligne par ligne, puis une synthèse des signaux d'alerte. Cet usage est l'un des plus rentables de Security Copilot en formation : il transforme un artefact opaque en support pédagogique en quelques secondes.

Prérequis : aucun plugin. Attention à ne coller que des scripts issus d'échantillons de test ou d'incidents déjà clos et anonymisés.

Catégorie 2 (suite) — Évaluer et faire progresser l'équipe (5 prompts)

Prompt 14 — Concevoir une matrice de compétences SOC

« Conçois une matrice de compétences pour une équipe SOC de dix personnes, avec quatre niveaux de maîtrise (notions, autonome, expert, référent) sur huit domaines : triage, investigation endpoint, investigation identité, analyse réseau, forensics, threat intelligence, automatisation et communication. Pour chaque croisement, décris en une phrase le comportement observable attendu. »

Output attendu : une matrice de trente-deux cellules décrivant des comportements, pas des connaissances — « sait rédiger une requête KQL multi-tables sans assistance » plutôt que « connaît KQL ». C'est cette formulation comportementale qui rend la matrice utilisable en entretien annuel.

Prérequis : aucun plugin.

Prompt 15 — Préparer un exercice de simulation de crise

« Prépare le scénario d'un exercice de crise de trois heures simulant un ransomware avec exfiltration préalable, pour une organisation de 800 collaborateurs. Structure en quatre injections successives, avec pour chacune : l'information communiquée aux participants, les décisions attendues, et les questions pièges que l'animateur doit poser. »

Output attendu : un déroulé d'exercice minuté avec escalade progressive de la pression. Les questions pièges sont la valeur ajoutée : elles portent typiquement sur la communication externe, la décision de paiement et la coordination avec le juridique — trois points où les équipes techniques improvisent. Pour le contexte réglementaire français, croisez avec les recommandations de l'ANSSI.

Prérequis : aucun plugin.

Prompt 16 — Débriefer un incident réel à des fins pédagogiques

« À partir de l'incident [identifiant], produis un support de retour d'expérience destiné à l'équipe : chronologie factuelle, décisions prises et leur justification, ce qui a bien fonctionné, ce qui a retardé la résolution, et trois enseignements actionnables. Ton neutre, sans désignation de responsabilité individuelle. »

Output attendu : un document de REX structuré, exploitable en réunion d'équipe. La consigne de neutralité est essentielle : sans elle, la chronologie peut prendre une tournure accusatoire qui rend le document impubliable en interne.

Prérequis : plugin Microsoft Defender XDR ou Microsoft Sentinel selon la source de l'incident ; permissions de lecture sur l'incident concerné.

Prompt 17 — Comparer deux approches de détection

« Compare la détection par signature et la détection comportementale pour identifier une exfiltration de données : principe, avantages, limites, taux de faux positifs attendu, et type d'attaquant que chaque approche laisse passer. Conclus par une recommandation de combinaison des deux. »

Output attendu : un comparatif structuré, idéalement tabulaire, se terminant sur une recommandation argumentée. Ce format de prompt — comparer deux approches sur des critères imposés — se transpose à des dizaines de sujets et constitue un excellent modèle réutilisable.

Prérequis : aucun plugin.

Prompt 18 — Construire un parcours de certification interne

« Construis un parcours de montée en compétences de six mois pour faire passer un analyste N1 au niveau N2, en environnement Microsoft Defender et Sentinel. Découpe en trois phases de deux mois, avec pour chacune : compétences visées, ressources de formation, exercices pratiques et évaluation de fin de phase. »

Output attendu : un parcours progressif avec jalons évaluables. Attendez-vous à des recommandations de certifications Microsoft ; vérifiez leur intitulé exact et leur disponibilité actuelle sur la documentation officielle Microsoft Learn, le catalogue évoluant régulièrement.

Prérequis : aucun plugin.

Catégorie 3 — Produire la documentation opérationnelle : procédures et runbooks (5 prompts)

La documentation est le gisement de productivité le plus évident et le plus sous-exploité. Un runbook prend une demi-journée à rédiger de zéro ; il prend quarante minutes à produire et relire avec un prompt correctement structuré. La condition est la même dans tous les cas : ne jamais publier un document sans passage par un expert du domaine, car le modèle produit une structure crédible même quand un détail technique est faux.

Prompt 19 — Rédiger une procédure de réponse à incident complète

« Rédige une procédure de réponse à incident pour une compromission de messagerie professionnelle (BEC) dans un environnement Microsoft 365. Structure en six phases : détection, qualification, confinement, éradication, restauration, retour d'expérience. Pour chaque phase : actions numérotées, rôle responsable, durée cible et critère de passage à la phase suivante. Précise les actions techniques exactes dans les portails Microsoft. »

Output attendu : une procédure de quatre à six pages, avec des actions techniques localisées (révocation de sessions, réinitialisation d'authentification, recherche de règles de boîte aux lettres malveillantes, purge de messages). Les critères de passage entre phases sont ce qui distingue une vraie procédure d'une liste de bonnes intentions.

Prérequis : aucun plugin pour la rédaction. Les plugins Microsoft Defender XDR et Microsoft Purview permettent d'adapter la procédure à votre configuration réelle en enchaînant un second prompt.

Prompt 20 — Produire un runbook d'astreinte

« Produis un runbook d'astreinte de nuit pour un analyste seul face à une alerte critique de type ransomware. Format : arbre de décision. Chaque nœud pose une question binaire vérifiable en moins de deux minutes et mène soit à une action, soit à une escalade nominative. Le document doit tenir sur deux pages et être lisible à 3 heures du matin. »

Output attendu : un arbre de décision compact, sans paragraphes explicatifs. La contrainte « lisible à 3 heures du matin » n'est pas un effet de style : elle produit concrètement des phrases plus courtes et des décisions binaires. Nos analyses des chaînes d'attaque récentes, détaillées dans le panorama ransomware France, confirment que le temps de décision nocturne est le facteur déterminant du périmètre final de compromission.

Prérequis : aucun plugin.

Prompt 21 — Documenter une règle de détection existante

« Voici une règle de détection analytique Sentinel : [coller la requête KQL]. Produis sa fiche de documentation : objectif de détection, techniques MITRE ATT&CK couvertes, sources de données requises, logique de la requête expliquée en français, faux positifs connus, et procédure de triage recommandée pour l'analyste qui reçoit l'alerte. »

Output attendu : une fiche de détection complète et normalisée. C'est l'un des usages où le gain est le plus spectaculaire : documenter rétroactivement un parc de cent règles devient un projet de quelques jours au lieu de plusieurs semaines. Vérifiez systématiquement le mapping MITRE proposé, qui est parfois approximatif sur les sous-techniques.

Prérequis : plugin Microsoft Sentinel pour que Security Copilot puisse contextualiser la requête avec vos tables réelles ; sans le plugin, la fiche reste produite mais sans vérification de l'existence des tables.

Prompt 22 — Rédiger un plan de communication de crise

« Rédige le volet communication d'un plan de réponse à incident pour une fuite de données personnelles touchant 15 000 clients. Couvre : les parties prenantes à informer et dans quel ordre, les délais réglementaires applicables en droit français et européen, un modèle de notification à l'autorité de contrôle et un modèle de message aux personnes concernées. »

Output attendu : un plan de communication avec matrice des parties prenantes, rappel du délai de notification de 72 heures prévu par le RGPD, et deux modèles de courrier. Faites impérativement relire le volet juridique : les formulations réglementaires produites sont plausibles mais doivent être validées par le DPO.

Prérequis : aucun plugin.

Prompt 23 — Générer une checklist de durcissement

« Génère une checklist de durcissement pour les comptes à privilèges dans Microsoft Entra ID, classée en trois niveaux : indispensable, recommandé, avancé. Pour chaque point : la mesure, l'impact utilisateur attendu, l'effort de mise en œuvre estimé et le risque couvert. Format tableau. »

Output attendu : une trentaine de points classés par priorité, avec l'estimation d'impact qui permet d'arbitrer. La colonne « impact utilisateur » est celle qui rend la checklist défendable devant une DSI réticente.

Prérequis : aucun plugin pour la checklist générique. Le plugin Microsoft Entra permet d'enchaîner avec une évaluation de votre configuration réelle.

Catégorie 3 (suite) — Politiques et référentiels de sécurité (5 prompts)

Prompt 24 — Rédiger une politique de gestion des accès

« Rédige une politique de gestion des accès aux systèmes d'information pour une organisation de 500 personnes soumise à la directive NIS 2. Couvre : principe du moindre privilège, cycle de vie des comptes, comptes à privilèges, revues d'accès périodiques, accès des prestataires. Ton normatif, sections numérotées, avec pour chaque exigence une indication de la preuve d'application attendue en audit. »

Output attendu : une politique structurée où chaque exigence est assortie d'une preuve auditable — c'est l'élément qui manque à 90 % des politiques rédigées en interne. Pour situer votre organisation par rapport aux obligations NIS 2, notre diagnostic NIS 2 permet un premier cadrage du périmètre applicable.

Prérequis : aucun plugin.

Prompt 25 — Traduire une exigence normative en contrôles techniques

« Prends l'exigence de journalisation et de supervision de la directive NIS 2. Traduis-la en contrôles techniques concrets implémentables dans un environnement Microsoft : quelles sources journaliser, quelle durée de rétention, quelles alertes configurer, et quelle preuve produire pour démontrer la conformité. »

Output attendu : un tableau de correspondance exigence → contrôle technique → preuve. Ce format de prompt est réutilisable pour toute exigence de tout référentiel ; c'est probablement le prompt le plus rentable de cette catégorie pour une équipe conformité.

Prérequis : aucun plugin obligatoire ; les plugins Microsoft Sentinel et Purview permettent de vérifier ensuite ce qui est déjà en place.

Prompt 26 — Produire une matrice de classification des incidents

« Produis une matrice de classification des incidents de sécurité à quatre niveaux de gravité. Pour chaque niveau : définition, exemples concrets, délai de prise en charge, niveau d'escalade, et personnes à notifier. Ajoute trois cas limites avec la justification du classement retenu. »

Output attendu : une matrice opérationnelle complétée de cas limites arbitrés. Les cas limites sont la partie la plus utile : ils préviennent les débats récurrents en cellule de crise sur la qualification d'un incident.

Prérequis : aucun plugin.

Prompt 27 — Rédiger une charte d'usage de l'IA générative en sécurité

« Rédige une charte encadrant l'usage des assistants génératifs par les équipes sécurité : données pouvant ou non figurer dans un prompt, obligation de validation humaine, traçabilité des sessions, propriété des contenus produits, et sanctions en cas de manquement. Ton normatif, deux pages maximum. »

Output attendu : une charte signable. La section sur les données interdites en prompt doit être adaptée manuellement à votre classification interne — c'est le point où un texte générique devient dangereux s'il est publié tel quel.

Prérequis : aucun plugin.

Prompt 28 — Auditer un document de sécurité existant

« Voici notre politique de sauvegarde actuelle : [coller le document]. Identifie les lacunes par rapport aux bonnes pratiques de résilience face au ransomware : immuabilité, isolation, tests de restauration, couverture des données SaaS. Pour chaque lacune, propose la formulation exacte du paragraphe à ajouter. »

Output attendu : une liste de lacunes assortie de paragraphes rédigés prêts à insérer. Ce mode « audit puis correction rédigée » est nettement plus rentable qu'un simple audit : il supprime l'étape de reformulation.

Prérequis : aucun plugin. Vérifiez la classification du document avant de le coller dans une session.

Catégorie 4 — Reporting et communication vers les décideurs (7 prompts)

Le reporting est l'activité où l'écart entre le temps consacré et la valeur perçue est le plus défavorable au SOC. Une équipe passe deux jours par mois à produire un bulletin que trois personnes lisent en diagonale. Security Copilot ne résout pas le problème de fond — la pertinence du contenu — mais il divise par trois le temps de mise en forme, à condition d'être très directif sur l'audience.

Prompt 29 — Produire un rapport exécutif mensuel

« Produis le rapport de sécurité mensuel destiné au comité de direction, à partir de l'activité des trente derniers jours. Structure : une synthèse de cinq lignes lisible sans contexte technique, trois indicateurs clés avec leur évolution, les deux incidents marquants et leur impact métier, et deux décisions attendues du comité. Aucun acronyme technique non explicité. Une page maximum. »

Output attendu : un rapport d'une page centré sur l'impact métier et les décisions. La contrainte « deux décisions attendues » transforme un rapport passif en document d'aide à la décision — c'est ce qui fait la différence en comité.

Prérequis : plugins Microsoft Defender XDR et Microsoft Sentinel pour l'accès aux données d'incidents ; permissions de lecture sur les incidents de la période.

Prompt 30 — Rédiger un bulletin de veille mensuel

« Rédige le bulletin de veille sécurité du mois pour un lectorat interne mixte (IT et métiers). Structure : trois menaces marquantes expliquées en langage accessible, leur pertinence pour une organisation de notre secteur, et une action concrète recommandée pour chacune. Ton informatif, sans alarmisme, 600 mots. »

Output attendu : un bulletin publiable après relecture. Précisez toujours votre secteur d'activité : sans cette information, la sélection de menaces reste générique et le bulletin perd son intérêt.

Prérequis : plugin Microsoft Defender Threat Intelligence pour ancrer le bulletin sur des campagnes réellement observées ; sans lui, le contenu s'appuie sur la connaissance générale du modèle et peut être décalé dans le temps.

Prompt 31 — Préparer une présentation COMEX en dix diapositives

« Prépare le plan d'une présentation de dix diapositives pour le comité exécutif, sur l'état de la posture de sécurité et la demande d'un budget complémentaire de 200 000 euros. Pour chaque diapositive : titre, trois messages clés, et la donnée ou le visuel à afficher. La diapositive de conclusion doit formuler la demande de façon explicite et chiffrée. »

Output attendu : un storyboard complet suivant une progression constat → risque → arbitrage → demande. L'erreur classique que ce prompt évite est de noyer la demande budgétaire dans la technique : en imposant une conclusion explicite, on force la structure argumentative.

Prérequis : aucun plugin pour le plan ; les plugins de données permettent d'alimenter ensuite chaque diapositive avec des chiffres réels.

Prompt 32 — Traduire un incident technique pour un dirigeant

« Traduis l'incident [identifiant] en une note de trois paragraphes pour le directeur général : ce qui s'est passé en langage courant, ce que cela signifie concrètement pour l'activité, et ce que nous faisons maintenant. Aucun terme technique. Réponds à la question implicite : "est-ce grave et suis-je exposé ?" »

Output attendu : une note courte répondant directement à l'inquiétude du dirigeant. La dernière consigne du prompt est celle qui change le résultat : sans elle, l'output reste descriptif au lieu d'être rassurant ou alertant.

Prérequis : plugin Microsoft Defender XDR ou Sentinel ; permissions de lecture sur l'incident.

Prompt 33 — Construire un tableau de bord d'indicateurs

« Propose un jeu de huit indicateurs de performance pour un SOC, équilibré entre efficacité opérationnelle et réduction du risque. Pour chaque indicateur : définition précise, mode de calcul, source de données, fréquence de mesure, et le comportement pervers qu'il pourrait induire s'il devenait un objectif. »

Output attendu : huit indicateurs documentés, dont la colonne « comportement pervers » est la plus instructive : elle révèle par exemple qu'un objectif de réduction du temps moyen de résolution incite mécaniquement à clore les incidents trop vite.

Prérequis : aucun plugin.

Prompt 34 — Répondre à un questionnaire de sécurité client

« Voici un extrait de questionnaire de sécurité envoyé par un client : [coller les questions]. Pour chacune, propose une réponse factuelle, précise et non engageante au-delà de ce qui est vérifiable, en signalant explicitement les questions auxquelles je ne peux pas répondre sans information interne complémentaire. »

Output attendu : des réponses formulées avec la prudence contractuelle appropriée, et surtout une liste explicite des questions nécessitant une vérification interne. Cette dernière liste est ce qui évite l'engagement contractuel non tenu.

Prérequis : aucun plugin. Vérifiez chaque réponse avant envoi : un questionnaire client engage juridiquement.

Prompt 35 — Rédiger une note de sensibilisation ciblée

« Rédige une note de sensibilisation de 300 mots destinée aux collaborateurs du service comptabilité, sur la fraude au président et la fraude au faux fournisseur. Inclus deux exemples de messages frauduleux réalistes, les trois signaux à vérifier systématiquement, et la conduite à tenir en cas de doute. Ton direct, sans culpabilisation. »

Output attendu : une note courte et concrète, avec des exemples suffisamment réalistes pour être reconnaissables. Le ciblage sur un service précis rend le message nettement plus efficace qu'une communication générale à toute l'organisation.

Prérequis : aucun plugin.

Catégorie 5 — Productivité SOC au quotidien (5 prompts)

Cette dernière catégorie regroupe les prompts les plus courts et les plus utilisés. Ce sont ceux qu'un analyste emploie dix fois par jour, souvent sans réfléchir, et qui représentent au total le gain de temps le plus important — précisément parce qu'ils sont répétés.

Prompt 36 — Résumer une alerte en trois lignes

« Résume l'alerte [identifiant] en exactement trois lignes : ce qui a été détecté, sur quel actif et quel utilisateur, et le niveau d'urgence justifié en une demi-phrase. Pas d'introduction, pas de conclusion, pas de recommandation. »

Output attendu : trois lignes brutes, collables directement dans un ticket ou un canal d'équipe. Les consignes négatives — pas d'introduction, pas de conclusion — sont indispensables : sans elles, la réponse est systématiquement encadrée de phrases de politesse inutiles.

Prérequis : plugin Microsoft Defender XDR ou Microsoft Sentinel selon l'origine de l'alerte ; permissions de lecture sur l'alerte.

Prompt 37 — Prioriser une file d'alertes

« Voici les alertes ouvertes de mon équipe sur les dernières 24 heures. Classe-les par ordre de traitement en tenant compte de la criticité de l'actif, du privilège du compte concerné et de la probabilité de faux positif. Présente un tableau : rang, alerte, justification en une phrase, temps de traitement estimé. »

Output attendu : une file ordonnée avec justification par ligne. Le critère « probabilité de faux positif » est ce qui différencie cette priorisation d'un simple tri par sévérité : il fait remonter les alertes de sévérité moyenne mais très fiables au-dessus des alertes critiques historiquement bruyantes.

Prérequis : plugins Microsoft Defender XDR et Microsoft Sentinel ; permissions de lecture sur l'ensemble de la file, faute de quoi la priorisation ne portera que sur un sous-ensemble sans que ce soit signalé.

Prompt 38 — Générer les notes de clôture d'un ticket

« Génère les notes de clôture de l'incident [identifiant] au format attendu par notre outil de ticketing : classification finale, cause racine, actions réalisées avec horodatage, actions de suivi restantes avec responsable, et durée totale de traitement. Style factuel, à la voix active. »

Output attendu : des notes de clôture normalisées. L'intérêt principal est l'homogénéité : dix analystes produisent des notes de qualité comparable, ce qui rend enfin exploitables les statistiques de causes racines.

Prérequis : plugin Microsoft Defender XDR ou Sentinel ; permissions de lecture sur l'incident et son historique.

Prompt 39 — Identifier les tâches automatisables

« Voici les dix tâches les plus fréquentes de mon équipe SOC : [liste]. Pour chacune, évalue le potentiel d'automatisation (fort, moyen, faible), la technologie adaptée dans l'écosystème Microsoft, l'effort de mise en œuvre et le risque introduit par l'automatisation. Classe par ratio gain/effort décroissant. »

Output attendu : un classement des chantiers d'automatisation par rentabilité. La colonne « risque introduit » évite l'erreur classique consistant à automatiser une action de confinement sans garde-fou humain.

Prérequis : aucun plugin pour l'analyse ; la mise en œuvre suppose les droits appropriés sur Microsoft Sentinel et les connecteurs concernés.

Prompt 40 — Préparer la passation entre équipes

« Prépare la note de passation de mon service vers l'équipe suivante : incidents en cours avec leur état d'avancement et la prochaine action attendue, alertes non traitées classées par priorité, points de vigilance pour les prochaines heures. Format liste, une ligne par élément, lisible en deux minutes. »

Output attendu : une note de relève compacte. La contrainte « lisible en deux minutes » est ce qui garantit qu'elle sera réellement lue — une note de passation d'une page ne l'est jamais.

Prérequis : plugins Microsoft Defender XDR et Microsoft Sentinel ; permissions de lecture sur l'ensemble des incidents de l'équipe.

Être spécifique sur le contexte : la règle des cinq ancrages

Le principal défaut des prompts produits spontanément est l'absence d'ancrage. Avant d'envoyer un prompt, vérifiez qu'il contient au minimum trois des cinq ancrages suivants : qui (l'audience du livrable), quoi (l'objet précis, identifiant à l'appui), quand (la fenêtre temporelle), comment (le format attendu) et jusqu'où (la limite ou le critère de qualité).

Un prompt sans ancrage temporel sur un environnement Sentinel volumineux produira soit une réponse tronquée, soit une consommation de SCU disproportionnée. Un prompt sans ancrage d'audience produira un texte de niveau moyen qui ne conviendra ni au dirigeant ni à l'expert. Un prompt sans critère de qualité produira une réponse confiante là où un « je ne dispose pas de cette information » aurait été la bonne réponse.

Ce dernier point mérite une insistance particulière. Ajouter systématiquement « signale explicitement ce que tu ne peux pas vérifier avec les données disponibles » à vos prompts d'investigation change la nature de l'output : vous passez d'une réponse à valider intégralement à une réponse partiellement auto-évaluée, dont vous savez où concentrer votre relecture.

Enchaîner les prompts : construire une session plutôt que poser une question

Security Copilot conserve le contexte au sein d'une session. C'est la propriété la plus sous-exploitée de l'outil. Plutôt que de rédiger un prompt monolithique de quinze lignes, décomposez en trois ou quatre prompts successifs, chacun s'appuyant sur le précédent.

Une séquence typique de production documentaire : (1) « établis le plan détaillé d'une procédure de réponse aux compromissions d'identité » ; (2) « développe la section confinement en actions numérotées avec les manipulations exactes dans le portail Entra » ; (3) « ajoute pour chaque action le rollback en cas d'erreur » ; (4) « reformule l'ensemble pour un analyste N1 qui découvre ces portails ».

Chaque étape est courte, vérifiable et corrigeable. Si l'étape 2 dérape, vous la relancez sans perdre le plan validé à l'étape 1. Avec un prompt monolithique, une seule erreur invalide l'ensemble et vous relancez tout — en consommant à nouveau les ressources correspondantes.

L'enchaînement fonctionne aussi en investigation : partir large (« résume l'incident »), puis restreindre (« détaille uniquement la phase d'accès initial »), puis pivoter (« ce compte a-t-il été utilisé ailleurs sur les sept derniers jours ? »). Cette progression entonnoir reproduit exactement la démarche d'un analyste expérimenté, et c'est celle que les promptbooks figent en séquences réutilisables.

Valider les outputs : le protocole en trois questions

Aucun output ne doit être utilisé sans validation. Le protocole minimal tient en trois questions, applicables en moins d'une minute.

Première question : d'où vient cette information ? Security Copilot indique généralement ses sources lorsqu'il exploite un plugin. Si une affirmation factuelle n'est rattachée à aucune source — un nom de groupe d'attaquants, une date de campagne, un identifiant de vulnérabilité — traitez-la comme une hypothèse à vérifier, pas comme un fait.

Deuxième question : cette information est-elle vérifiable en un clic ? Pour les données issues de vos propres produits, la réponse est oui : ouvrez le portail source et confirmez. Pour tout ce qui concerne une correspondance MITRE, un identifiant CVE ou une exigence réglementaire, la vérification externe est obligatoire.

Troisième question : quelle décision cet output va-t-il déclencher ? C'est le calibrage de l'effort de relecture. Un support de formation interne mérite une relecture rapide ; une procédure de confinement automatisé ou une réponse à un questionnaire client mérite une relecture ligne à ligne par un expert du domaine. L'erreur n'est pas de faire confiance, c'est de faire confiance uniformément.

Partager en équipe : du prompt individuel au promptbook

Un prompt qui fonctionne et reste dans le fichier texte d'un analyste est une valeur perdue. Le mécanisme des promptbooks existe exactement pour cela : figer une séquence validée en un actif réutilisable, paramétrable par des variables d'entrée, et exécutable par n'importe quel membre de l'équipe sans connaissance du prompting.

Le critère de promotion est simple : dès qu'un enchaînement de prompts a été utilisé trois fois avec un résultat satisfaisant, il doit devenir un promptbook. En dessous de trois usages, le coût de formalisation n'est pas amorti ; au-delà, chaque exécution manuelle est une perte de temps et une source de variabilité.

Trois candidats évidents à la promotion parmi les quarante prompts ci-dessus : la séquence de rapport exécutif mensuel (prompts 29 et 33), la séquence de documentation de règle de détection (prompt 21, appliqué en boucle sur un parc de règles), et la note de passation (prompt 40, exécutée deux à trois fois par jour). La mécanique complète de création, de paramétrage et de partage est détaillée dans notre guide des promptbooks Security Copilot.

Une pratique complémentaire à instaurer dès le départ : la revue de prompts. Un créneau de trente minutes toutes les deux semaines où chaque analyste présente un prompt qui lui a fait gagner du temps. C'est le mécanisme de diffusion le plus efficace observé en équipe, bien devant la documentation écrite que personne ne consulte.

Les cinq anti-patterns qui ruinent un prompt

Le prompt-conversation. Écrire « bonjour, j'aimerais savoir si tu pourrais m'aider à comprendre… » consomme des ressources sans rien apporter. Security Copilot n'est pas un interlocuteur : allez directement à l'instruction.

Le prompt sans format. Ne pas préciser le format de sortie garantit deux ou trois reformulations. Une phrase de contrainte de format économise systématiquement plus qu'elle ne coûte.

Le prompt à question multiple. Poser quatre questions distinctes dans un même prompt produit quatre réponses superficielles. Une question par prompt, en enchaînement.

Le prompt qui présuppose la réponse. « Confirme que cet incident est un faux positif » oriente le modèle vers la confirmation. Préférez « cet incident est-il un faux positif ? Argumente dans les deux sens avant de conclure ».

Le prompt jetable. Un bon prompt trouvé et non sauvegardé sera reconstruit de mémoire la fois suivante, en moins bien. Tenez un fichier partagé, même rudimentaire, en attendant la formalisation en promptbook.

Questions fréquentes sur le prompting Security Copilot

Faut-il rédiger ses prompts en français ou en anglais ?

Les deux fonctionnent, mais avec une nuance opérationnelle. Le français convient parfaitement aux prompts de documentation, de formation et de reporting, où le livrable est destiné à des lecteurs francophones. Pour les prompts d'investigation qui manipulent des noms de tables, des noms de champs ou des intitulés de produits, l'anglais réduit les risques de mauvaise interprétation, car les schémas de données sous-jacents sont en anglais. La pratique la plus efficace consiste à rédiger l'instruction en français tout en conservant les termes techniques dans leur forme d'origine : « liste les événements DeviceLogonEvents des dernières 24 heures ».

Pourquoi deux analystes obtiennent-ils des réponses différentes au même prompt ?

Trois causes, par ordre de fréquence. D'abord les permissions : Security Copilot n'élargit jamais les droits d'un utilisateur, donc un analyste avec un périmètre RBAC restreint verra moins de données sans que la réponse le signale toujours explicitement. Ensuite la configuration des plugins, qui peut différer entre un réglage au niveau du tenant et un réglage individuel. Enfin le contexte de session : un prompt envoyé après cinq échanges hérite de ce contexte, alors que le même prompt en session neuve part de zéro. En cas de divergence inexpliquée, rejouez le prompt dans une session vierge avant toute autre hypothèse.

Peut-on coller des données sensibles dans un prompt ?

Techniquement oui, et les données traitées par Security Copilot restent dans le périmètre de service défini par Microsoft, sans être utilisées pour l'entraînement des modèles de fondation. Opérationnellement, la règle de prudence reste de coller le minimum nécessaire : préférez systématiquement un identifiant d'incident que le plugin ira résoudre plutôt qu'un export complet collé dans le prompt. Cette approche limite l'exposition, réduit la consommation de ressources et produit de meilleures réponses puisque le contexte est récupéré à la source. Pour les documents internes, appliquez votre classification habituelle : un document non diffusable en externe mérite une réflexion avant d'être collé.

Combien de prompts faut-il pour rentabiliser une capacité provisionnée ?

La question est mal posée : la facturation repose sur une capacité provisionnée à l'heure, pas sur un décompte de prompts. Le raisonnement pertinent porte sur le taux d'usage de la capacité déployée. Une équipe de dix analystes qui n'utilise l'outil que pour un rapport mensuel gaspille sa capacité ; la même équipe qui intègre trois ou quatre prompts quotidiens par analyste — résumé d'alerte, priorisation, passation, notes de clôture — atteint un taux d'usage qui justifie l'investissement. C'est précisément pourquoi les prompts de la catégorie productivité, apparemment les plus modestes, sont ceux qui déterminent la rentabilité globale.

Comment savoir si Security Copilot s'est trompé ?

Il n'existe pas de signal fiable dans la réponse elle-même : le modèle formule une information erronée avec la même assurance qu'une information exacte. Trois réflexes compensent cette limite. Vérifiez la présence de références aux sources : une réponse qui cite les incidents ou requêtes exploités est nettement plus fiable qu'une réponse sans ancrage. Recoupez toute donnée factuelle externe — identifiant de vulnérabilité, correspondance ATT&CK, exigence réglementaire — auprès de la source d'origine. Enfin, ajoutez à vos prompts sensibles la consigne « indique ton niveau de confiance et ce que tu n'as pas pu vérifier » : la réponse ne sera pas infaillible, mais elle vous indiquera où porter votre relecture en priorité.

Passer à l'échelle

Quarante prompts constituent une base de départ, pas une bibliothèque. Le vrai actif se construit sur trois à six mois, par accumulation de variantes adaptées à votre environnement, votre secteur et votre vocabulaire interne. Le point de bascule intervient lorsque l'équipe cesse de rédiger des prompts pour exécuter des promptbooks — à ce moment, le prompting devient une compétence de conception, exercée par deux ou trois personnes, et non plus une compétence quotidienne exigée de tous.

Pour poursuivre, deux directions complémentaires. Les prompts spécialisés par produit, couverts dans la référence par produit, apportent la profondeur technique sur Defender XDR, Sentinel, Entra, Intune et Purview. L'industrialisation en séquences réutilisables est traitée dans le guide des promptbooks. L'ensemble de nos ressources sur la plateforme est regroupé sur la page Copilot Security.

``` **Points à vérifier avant publication :** - **Liens internes** — `/copilot-security`, `/copilot-security/promptbooks` et `/articles/copilot-security-prompts-reference-par-produit` viennent de votre brief ; `/diagnostic-nis-2` et `/panorama-ransomware-france` viennent de la mémoire projet. Je n'ai pas pu grepper `routes.go` (commande refusée) — à confirmer. - **Le libellé « 40 prompts »** : votre brief global disait 20-25, la demande spécifique 8+10+10+7+5 = 40. J'ai suivi le décompte détaillé. - **Titre proposé** (50-60 runes) : « Prompts Copilot Security : 40 modèles pour le SOC » (49 runes) ou « Copilot Security : 40 prompts prêts à l'emploi pour le SOC » (57 runes). - Ratio H2/mots : 16 H2 pour ~4 600 mots → ~290, sous le seuil de 350. Dites-moi si vous voulez que je le pousse en base prod (insertion article + slug + meta description), je le ferai en commandes séparées.