50 prompts Copilot Security pour Microsoft Sentinel : guide complet du SOC

L'écriture fichier n'est pas autorisée dans cet environnement — je livre l'article directement ci-dessous. Notez que le titre demandé fait 71 runes (règle SEO : 50-60) ; je l'ai conservé tel quel puisque c'est votre choix, mais une variante conforme serait *« 50 prompts Copilot Security pour Microsoft Sentinel »* (49 runes). Contenu vérifié sur Microsoft Learn (août 2026) : deux plugins Sentinel distincts en préversion, configuration du workspace par défaut, inclusion M365 E5/E7 vs provisionnement SCU manuel. ```html

Microsoft Sentinel produit chaque jour des dizaines d'incidents, des milliers d'alertes et des téraoctets de logs que même un SOC bien staffé peine à exploiter en profondeur. Microsoft Security Copilot change l'équation : branché sur votre espace de travail Sentinel, il résume un incident en quinze secondes, traduit une intention de chasse en KQL exécutable, explique pourquoi une règle analytique génère 400 faux positifs par semaine et rédige le rapport exécutif que votre RSSI attend le lundi matin. Mais la qualité de la réponse dépend entièrement de la qualité du prompt : une question vague produit une réponse vague, et un prompt mal cadré consomme des unités de calcul pour rien. Ce guide rassemble 50 prompts éprouvés, organisés en six catégories couvrant l'ensemble du cycle de vie SOC — investigation d'incident, threat hunting, génération de KQL, analyse des règles analytiques, reporting et administration du workspace. Chaque prompt est fourni avec l'output que vous devez attendre, les prérequis techniques (plugin, licence, rôle) et un conseil d'usage tiré du terrain. Vous pouvez les copier tels quels dans le portail autonome Security Copilot ou dans l'expérience intégrée du portail Microsoft Defender, puis les assembler en promptbooks pour industrialiser vos runbooks.

Prérequis : activer les plugins Microsoft Sentinel dans Security Copilot

Avant d'exécuter le moindre prompt de cette liste, trois conditions doivent être réunies. Elles expliquent 90 % des messages « Je n'ai pas trouvé de données correspondantes » que rencontrent les analystes qui débutent.

Licence et capacité de calcul

Security Copilot fonctionne sur un modèle de capacité provisionnée. Deux situations coexistent aujourd'hui : les clients Microsoft 365 E5 et E7 éligibles bénéficient de Security Copilot inclus dans leur licence, avec un provisionnement automatique dans le tenant ; les autres organisations doivent réaliser un onboarding manuel et provisionner des unités de calcul de sécurité (SCU) depuis un abonnement Azure. L'éligibilité seule ne suffit pas : tant que la capacité n'est pas déployée dans le tenant, le portail reste inaccessible. Consultez la documentation d'onboarding Microsoft pour identifier votre chemin. Security Copilot n'est pas disponible dans les clouds gouvernementaux américains (GCC High, DoD, Azure Government).

Les deux plugins Sentinel à activer

Dans l'expérience autonome, Microsoft Sentinel expose deux plugins distincts, tous deux en préversion, et la confusion entre les deux est la source d'erreur la plus fréquente :

• Microsoft Sentinel (préversion) : accès aux incidents, alertes, entités, règles analytiques et métadonnées du workspace. C'est le plugin des catégories 1, 2, 4, 5 et 6 de ce guide.
• Langage naturel vers KQL pour Microsoft Sentinel (préversion) : génération et exécution de requêtes KQL sur les tables du workspace. C'est le plugin de la catégorie 3, également disponible dans la section de chasse avancée du portail Microsoft Defender.

L'activation se fait via l'icône Sources dans la barre de prompt, puis Gérer les plug-ins. Basculez chaque plugin sur Activé.

Définir un espace de travail par défaut

C'est l'étape que tout le monde saute et qui dégrade la précision de toutes les réponses. Dans Gérer les plug-ins, cliquez sur l'icône d'engrenage du plugin Microsoft Sentinel et renseignez le nom de l'espace de travail par défaut. Sans ce paramétrage, Copilot doit deviner sur quel workspace interroger, et il se trompe. Si votre SOC gère plusieurs workspaces (multi-tenant, multi-filiale, Lighthouse), nommez explicitement le workspace cible dans chaque prompt : « ...dans l'espace de travail "soc-sentinel-prod-eu" ».

Rôles et permissions

Security Copilot n'élève jamais vos privilèges : il agit avec les permissions de l'utilisateur connecté. Un analyste disposant du rôle Lecteur Microsoft Sentinel obtiendra les résumés d'incidents et les résultats de requêtes, mais pas la possibilité de modifier une règle. Un Répondeur Microsoft Sentinel pourra changer un statut ou une gravité. Les prompts d'administration liés aux coûts et à la santé du workspace nécessitent en général des droits de lecture sur la ressource Log Analytics elle-même. Si un prompt de cette liste retourne un résultat vide, vérifiez d'abord vos rôles avant d'incriminer la formulation.

Catégorie 1 — Investigation d'incidents : 10 prompts

C'est le cas d'usage à plus fort retour sur investissement : compresser la phase de compréhension d'un incident, qui occupe traditionnellement 60 à 70 % du temps de triage de niveau 1. Les prompts ci-dessous s'enchaînent naturellement dans une même session, Copilot conservant le contexte de l'incident d'un prompt au suivant.

Prompt 1 — Résumer un incident en langage clair

« Résume l'incident Sentinel numéro 4821 : décris ce qui s'est passé, quand, quelles entités sont concernées et quel est le niveau de confiance de la détection. Réponds en dix lignes maximum, sans jargon interne et sans ID d'objet. »

Output attendu : un paragraphe narratif reprenant le titre de l'incident, sa fenêtre temporelle, les alertes agrégées, les comptes et machines impliqués, et la règle analytique déclenchante. Copilot signale généralement le niveau de gravité et l'état actuel.

Prérequis : plugin Microsoft Sentinel (préversion), rôle Lecteur Microsoft Sentinel minimum.

Conseil : la précision « sans ID d'objet » est déterminante. Sans elle, Copilot vous renvoie des GUID de comptes Entra au lieu des UPN, et vous perdez le bénéfice de la lisibilité.

Prompt 2 — Cartographier les entités impliquées

« Liste toutes les entités associées à cet incident sous forme de tableau : type d'entité, valeur, rôle dans l'incident (source, cible, intermédiaire) et première apparition. Signale les entités qui apparaissent dans d'autres incidents ouverts. »

Output attendu : un tableau markdown comptes / hôtes / adresses IP / URL / fichiers, avec les recoupements sur les incidents connexes. C'est ce recoupement qui révèle les campagnes multi-incidents.

Prérequis : plugin Microsoft Sentinel. L'enrichissement de réputation nécessite en plus le plugin Microsoft Defender Threat Intelligence.

Conseil : utilisez le démonstratif « cet incident » en continuité du prompt 1 : Copilot conserve le contexte de la session et vous évite de re-spécifier le numéro.

Prompt 3 — Construire la timeline chronologique

« Construis la chronologie détaillée de cet incident, du premier événement au dernier, en heure UTC. Pour chaque étape indique l'horodatage, l'entité concernée, l'action observée et la technique MITRE ATT&CK correspondante. »

Output attendu : une timeline ordonnée avec mapping ATT&CK par étape. C'est la matière première du rapport d'incident et de la reconstitution du kill chain.

Prérequis : plugin Microsoft Sentinel. Le mapping ATT&CK est déduit des règles analytiques et du raisonnement du modèle, pas d'une table Sentinel.

Conseil : imposez toujours le fuseau (UTC ou heure locale). Les workspaces Sentinel stockent en UTC et les analystes raisonnent en heure locale : c'est une source classique d'erreur de corrélation.

Prompt 4 — Évaluer le rayon d'impact

« Évalue le périmètre d'impact potentiel de cet incident : combien d'utilisateurs, de machines et de ressources cloud pourraient être affectés si la compromission s'est propagée ? Indique les données sensibles potentiellement exposées et les systèmes critiques adjacents. »

Output attendu : une estimation raisonnée du blast radius, avec les hypothèses explicites. Copilot distingue en général ce qui est confirmé par les données de ce qui relève de la projection.

Prérequis : plugin Microsoft Sentinel. L'ajout des plugins Microsoft Defender XDR et Microsoft Entra améliore fortement la qualité de la réponse.

Conseil : traitez cette sortie comme une hypothèse de travail, jamais comme un constat. Demandez systématiquement à Copilot de séparer « confirmé » et « supposé ».

Prompt 5 — Décider de la priorité de triage

« Sur la base de la gravité, des entités touchées, de leur criticité métier et du contexte de menace, recommande une priorité de traitement pour cet incident sur une échelle P1 à P4. Justifie en trois points et indique le délai de prise en charge recommandé. »

Output attendu : une priorité argumentée avec un SLA suggéré. Utile pour harmoniser le triage entre analystes de niveaux et d'expériences différents.

Prérequis : plugin Microsoft Sentinel.

Conseil : ajoutez votre contexte métier dans le prompt (« le serveur SRV-SAP01 héberge la production financière »). Copilot ne connaît pas la criticité métier de vos actifs sauf si vous la lui donnez ou si elle figure dans une watchlist.

Prompt 6 — Rechercher les incidents similaires passés

« Trouve les incidents Sentinel des 90 derniers jours qui présentent des similitudes avec celui-ci : même règle analytique, mêmes entités ou même schéma d'attaque. Pour chacun, indique comment il a été clôturé et la raison de clôture. »

Output attendu : une liste d'incidents historiques avec leur classification de clôture (vrai positif, faux positif, activité bénigne). Si les cinq derniers cas identiques ont été clos en faux positif, votre décision est quasiment prise.

Prérequis : plugin Microsoft Sentinel, rétention suffisante de la table SecurityIncident.

Conseil : c'est le prompt de rentabilité maximale pour un SOC mature. Il capitalise sur l'historique de décisions de votre équipe au lieu de repartir de zéro à chaque alerte.

Prompt 7 — Analyser un compte potentiellement compromis

« Pour le compte utilisateur impliqué dans cet incident, donne-moi : ses connexions des 7 derniers jours avec pays et adresses IP, les échecs d'authentification, les changements de MFA ou de mot de passe, les rôles privilégiés attribués et toute autre alerte le concernant. »

Output attendu : un profil de compte consolidé mêlant SigninLogs, AuditLogs et alertes. Les voyages impossibles et les modifications de MFA ressortent immédiatement.

Prérequis : plugin Microsoft Sentinel et connecteur Microsoft Entra ID actif. Le plugin Microsoft Entra enrichit encore la réponse.

Conseil : découpez si la réponse est tronquée. Un prompt qui demande six choses à la fois produit souvent une réponse superficielle sur chacune.

Prompt 8 — Décoder et expliquer un script suspect

« Analyse la ligne de commande PowerShell encodée présente dans cet incident : décode-la, explique ce que fait le script étape par étape, identifie les indicateurs de compromission qu'il contient et évalue son niveau de dangerosité. »

Output attendu : le script décodé, une explication ligne par ligne, la liste des IOC extraits (domaines, IP, chemins) et un verdict de malveillance argumenté.

Prérequis : plugin Microsoft Sentinel. Fonctionne également en collant directement le script dans le prompt, sans plugin, ce qui est utile pour un artefact issu d'un autre outil.

Conseil : c'est probablement le prompt qui fait gagner le plus de temps à un analyste de niveau 1 : ce qui prenait vingt minutes de désobfuscation manuelle prend trente secondes.

Prompt 9 — Générer les actions de confinement

« Propose un plan de confinement pour cet incident, ordonné par urgence. Pour chaque action indique l'impact opérationnel attendu, le rôle habilité à l'exécuter et la commande ou le portail à utiliser. Distingue les actions réversibles des actions irréversibles. »

Output attendu : une checklist de confinement priorisée (isolation d'hôte, révocation de session, blocage d'IP, désactivation de compte) avec évaluation de l'impact métier.

Prérequis : plugin Microsoft Sentinel. Copilot propose, il n'exécute pas : le passage à l'acte reste une décision humaine.

Conseil : la mention « distingue les actions réversibles des irréversibles » évite qu'un analyste junior lance une réinitialisation massive de mots de passe à 3 h du matin.

Prompt 10 — Challenger l'hypothèse du faux positif

« Joue le rôle d'un analyste sceptique : donne-moi les trois arguments les plus solides pour considérer cet incident comme un faux positif, puis les trois arguments les plus solides pour le considérer comme une vraie attaque. Conclus par la donnée manquante qui permettrait de trancher. »

Output attendu : une analyse contradictoire structurée qui se termine par une piste d'investigation concrète. C'est le prompt anti-biais de confirmation.

Prérequis : plugin Microsoft Sentinel.

Conseil : à utiliser systématiquement avant toute clôture d'incident en faux positif sur un actif critique. Il coûte quelques secondes et évite les clôtures hâtives.

Catégorie 2 — Threat hunting : 10 prompts

Le hunting est le domaine où Copilot apporte le plus de valeur cognitive : il ne se contente pas d'exécuter, il aide à formuler l'hypothèse. Ces prompts supposent que vous ayez activé le plugin de langage naturel vers KQL pour pouvoir exécuter les requêtes générées.

Prompt 11 — Générer des hypothèses de chasse à partir d'une TTP

« Je veux chasser la technique MITRE ATT&CK T1078 (comptes valides) dans mon environnement Microsoft Sentinel. Propose cinq hypothèses de chasse testables, et pour chacune indique les tables Sentinel à interroger et le signal qui confirmerait l'hypothèse. »

Output attendu : cinq hypothèses formulées de manière falsifiable, avec les tables (SigninLogs, AuditLogs, IdentityLogonEvents) et les critères de confirmation.

Prérequis : plugin Microsoft Sentinel. Le plugin NL2KQL permet d'enchaîner directement sur la génération de requêtes.

Conseil : exigez toujours le terme « testable ». Sans cela, Copilot produit des généralités de threat intelligence au lieu d'hypothèses opérationnelles.

Prompt 12 — Chasser un indicateur de compromission

« Recherche l'adresse IP 203.0.113.45 dans toutes les tables de mon workspace Sentinel sur les 30 derniers jours. Indique dans quelles tables elle apparaît, à quelle fréquence, avec quels comptes et quelles machines, et si le trafic était entrant ou sortant. »

Output attendu : une synthèse multi-tables de la présence de l'IOC, avec volumétrie et contexte directionnel.

Prérequis : plugin Langage naturel vers KQL pour Microsoft Sentinel (préversion). Attention : toutes les tables Sentinel ne sont pas encore prises en charge dans l'expérience de chasse avancée unifiée.

Conseil : pour une liste d'IOC, ne collez pas cinquante indicateurs dans un prompt. Demandez plutôt à Copilot de générer un KQL avec un opérateur in~ et exécutez-le vous-même dans Sentinel.

Prompt 13 — Détecter les anomalies de volume

« Identifie les comptes qui, sur les 14 derniers jours, présentent un volume d'authentifications anormalement élevé par rapport à leur propre moyenne des 60 jours précédents. Exclus les comptes de service et les comptes système. »

Output attendu : une liste de comptes avec leur baseline, leur valeur observée et l'écart. Copilot génère généralement une requête utilisant series_decompose_anomalies().

Prérequis : plugin NL2KQL, rétention d'au moins 74 jours sur SigninLogs.

Conseil : « par rapport à sa propre moyenne » est essentiel. Une comparaison à la moyenne globale du tenant noie les comportements individuels dans le bruit.

Prompt 14 — Estimer le dwell time

« Pour cet incident, estime le temps de présence de l'attaquant dans l'environnement : recherche la première activité suspecte associée aux entités impliquées avant la date de détection, et calcule l'écart entre cette première activité et l'heure de création de l'incident. »

Output attendu : une estimation de dwell time avec la chaîne d'événements qui la justifie. C'est la métrique que réclament les comités de sécurité et les assureurs cyber.

Prérequis : plugin Microsoft Sentinel et NL2KQL. La fiabilité dépend directement de votre rétention de logs.

Conseil : précisez toujours à votre direction que le dwell time calculé est borné par la rétention. Un dwell time de 90 jours sur une rétention de 90 jours signifie « au moins 90 jours », pas « exactement 90 jours ».

Prompt 15 — Chasser le mouvement latéral

« Recherche les signes de mouvement latéral partant de la machine WKS-4471 sur les 7 derniers jours : connexions RDP, SMB, WinRM ou PsExec vers d'autres machines, création de tâches planifiées à distance et utilisation de comptes différents du propriétaire habituel du poste. »

Output attendu : un graphe de propagation sous forme de tableau source → destination → protocole → compte utilisé.

Prérequis : plugin NL2KQL, connecteurs Defender for Endpoint et/ou Security Events (4624, 4648, 4688) actifs.

Conseil : énumérez explicitement les protocoles. Une demande générique « cherche du mouvement latéral » produit une requête beaucoup moins couvrante qu'une demande qui nomme les vecteurs.

Prompt 16 — Chasser les mécanismes de persistance

« Identifie les mécanismes de persistance créés sur les serveurs de mon environnement au cours des 30 derniers jours : nouveaux services Windows, tâches planifiées, clés de registre Run, modifications WMI et nouvelles règles de démarrage. Trie par rareté dans l'environnement. »

Output attendu : une liste d'artefacts de persistance triée par fréquence croissante — les mécanismes vus une seule fois dans tout le parc remontent en tête.

Prérequis : plugin NL2KQL, table DeviceRegistryEvents ou équivalent renseignée.

Conseil : le tri « par rareté » est la technique du stack counting appliquée par prompt. C'est ce qui transforme une liste de 4 000 lignes en une liste de 12 lignes exploitables.

Prompt 17 — Chasser l'exfiltration de données

« Recherche les transferts de données sortants anormaux des 14 derniers jours : volumes supérieurs à 500 Mo vers des destinations externes, uploads vers des services de partage de fichiers non approuvés et connexions sortantes vers des domaines nouvellement enregistrés. »

Output attendu : une liste de flux sortants avec volume, destination, machine et compte associés.

Prérequis : plugin NL2KQL, journaux réseau (pare-feu, proxy, CommonSecurityLog) ingérés dans le workspace.

Conseil : ce prompt est directement lié aux obligations de notification. Une exfiltration confirmée déclenche les délais RGPD — voir notre diagnostic de conformité NIS 2 pour les obligations de notification associées.

Prompt 18 — Détecter la réactivation de comptes dormants

« Liste les comptes qui ne s'étaient pas authentifiés depuis plus de 60 jours et qui ont réalisé une connexion réussie au cours des 7 derniers jours. Pour chacun, indique le pays et l'adresse IP de la reconnexion et si le compte dispose de rôles privilégiés. »

Output attendu : un tableau de comptes réveillés, l'un des signaux les plus fiables et les moins bruyants de compromission d'identité.

Prérequis : plugin NL2KQL, rétention SigninLogs supérieure à 67 jours.

Conseil : transformez ce prompt en règle analytique planifiée si le résultat est exploitable. C'est typiquement une chasse qui mérite d'être automatisée.

Prompt 19 — Opérationnaliser un rapport de threat intelligence

« Voici les indicateurs et TTP décrits dans un rapport de threat intelligence sur un groupe ransomware : [coller la liste]. Construis un plan de chasse pour mon environnement Sentinel : quelles tables interroger, dans quel ordre, et quelles requêtes KQL exécuter pour chaque TTP. »

Output attendu : un plan de chasse structuré convertissant le rapport CTI en requêtes concrètes sur vos tables.

Prérequis : plugin Microsoft Sentinel et NL2KQL. Le plugin Microsoft Defender Threat Intelligence enrichit l'analyse.

Conseil : c'est le prompt qui donne le plus de valeur aux rapports CTI que personne ne lit. Notre panorama des groupes ransomware actifs en France constitue une bonne source d'entrée pour ce type d'exercice.

Prompt 20 — Identifier les angles morts de détection

« Analyse mes règles analytiques Sentinel actives et identifie les tactiques et techniques MITRE ATT&CK pour lesquelles je n'ai aucune couverture de détection. Priorise les lacunes par pertinence pour une organisation exposée aux attaques par ransomware. »

Output attendu : une matrice de couverture avec les lacunes hiérarchisées et des suggestions de règles à activer.

Prérequis : plugin Microsoft Sentinel, droits de lecture sur les règles analytiques.

Conseil : recoupez toujours avec la page MITRE ATT&CK native de Sentinel. Copilot raisonne sur les métadonnées des règles, qui sont parfois mal renseignées dans les règles personnalisées.

Catégorie 3 — Génération et traduction KQL : 10 prompts

KQL reste la barrière d'entrée numéro un de Microsoft Sentinel. Le plugin de langage naturel vers KQL supprime cette barrière pour les requêtes de complexité faible à moyenne. Sur les requêtes complexes, il produit un excellent brouillon que vous corrigerez plus vite que vous ne l'auriez écrit.

Prompt 21 — Traduire une intention en KQL

« Écris une requête KQL pour Microsoft Sentinel qui liste les connexions réussies depuis un pays hors Union européenne pour les comptes membres du groupe des administrateurs globaux, sur les 7 derniers jours. Ajoute un commentaire au-dessus de chaque bloc d'opérateurs. »

Output attendu : une requête KQL commentée et exécutable, avec la table source, les filtres et les projections.

Prérequis : plugin Langage naturel vers KQL pour Microsoft Sentinel (préversion).

Conseil : exigez les commentaires. Ils vous permettent de comprendre l'intention de la requête et facilitent sa reprise par un collègue — et vous apprenez KQL au passage.

Prompt 22 — Générer une requête avec jointure

« Écris une requête KQL qui croise SigninLogs et DeviceLogonEvents pour identifier les utilisateurs qui se sont connectés à Entra ID depuis une adresse IP différente de celle de leur poste de travail dans la même heure. Utilise une jointure performante et explique ton choix d'opérateur. »

Output attendu : une requête avec join kind=inner ou lookup, plus une justification du choix.

Prérequis : plugin NL2KQL, les deux tables présentes dans le workspace.

Conseil : demandez l'explication du choix d'opérateur. C'est là que les requêtes générées par IA échouent le plus souvent en production, sur des volumes réels.

Prompt 23 — Expliquer une requête KQL existante

« Explique cette requête KQL ligne par ligne, en indiquant ce que fait chaque opérateur, quelles données elle retourne et quels cas de figure elle risque de manquer : [coller la requête] »

Output attendu : une explication pédagogique assortie des angles morts de la requête — la partie la plus utile.

Prérequis : plugin NL2KQL. Fonctionne aussi sans plugin si vous collez le KQL intégralement.

Conseil : indispensable pour reprendre les requêtes héritées d'un analyste parti de l'équipe, ou celles issues d'un dépôt communautaire.

Prompt 24 — Optimiser les performances d'une requête

« Optimise cette requête KQL pour réduire son temps d'exécution et sa consommation de ressources, sans changer les résultats retournés. Explique chaque optimisation et estime le gain attendu : [coller la requête] »

Output attendu : une requête réordonnée (filtres temporels en premier, project anticipé, has plutôt que contains) avec le raisonnement associé.

Prérequis : plugin NL2KQL.

Conseil : critique pour les règles analytiques planifiées en NRT ou à haute fréquence : une requête lente sur une règle exécutée toutes les 5 minutes finit par générer des échecs d'exécution.

Prompt 25 — Déboguer une requête en erreur

« Cette requête KQL retourne l'erreur suivante : [coller l'erreur]. Voici la requête : [coller la requête]. Identifie la cause de l'erreur, corrige-la et explique ce qui n'allait pas. »

Output attendu : la requête corrigée avec un diagnostic (colonne inexistante, type incompatible, opérateur mal placé).

Prérequis : plugin NL2KQL. Copilot vérifie le schéma réel de vos tables, ce qui lui permet de détecter les colonnes renommées.

Conseil : collez toujours le message d'erreur intégral. Un « ça ne marche pas » sans le message force Copilot à deviner.

Prompt 26 — Convertir une recherche Splunk en KQL

« Convertis cette recherche Splunk SPL en requête KQL pour Microsoft Sentinel. Indique les équivalences de tables et de champs que tu as retenues et signale les fonctionnalités SPL sans équivalent direct en KQL : [coller le SPL] »

Output attendu : la requête KQL, une table de correspondance des champs et la liste explicite des écarts sémantiques.

Prérequis : plugin NL2KQL pour valider la requête contre votre schéma réel.

Conseil : le point critique d'une migration Splunk vers Sentinel n'est pas la syntaxe, c'est le mapping des champs. Demandez toujours la table de correspondance, c'est elle que vous devrez valider.

Prompt 27 — Convertir une requête QRadar en KQL

« Traduis cette requête QRadar AQL en KQL pour Microsoft Sentinel. Précise la table Sentinel cible pour chaque source de données QRadar et les champs pour lesquels le mapping est approximatif : [coller l'AQL] »

Output attendu : une requête KQL équivalente avec les réserves explicites sur les mappings imparfaits.

Prérequis : plugin NL2KQL.

Conseil : les propriétés personnalisées QRadar n'ont souvent aucun équivalent. Traitez la sortie comme un point de départ à valider événement par événement, pas comme une conversion certifiée.

Prompt 28 — Convertir une règle Sigma en KQL

« Convertis cette règle Sigma en requête KQL adaptée aux tables de mon workspace Microsoft Sentinel, puis propose la configuration de règle analytique associée : fréquence, période de recherche, seuil et mapping d'entités : [coller le YAML Sigma] »

Output attendu : le KQL plus un paramétrage de règle prêt à saisir dans l'assistant de création.

Prérequis : plugin NL2KQL, plugin Microsoft Sentinel pour la partie configuration.

Conseil : c'est l'un des usages les plus rentables du plugin : industrialiser l'import de règles depuis les dépôts Sigma communautaires vers votre référentiel de détection.

Prompt 29 — Générer une requête d'analyse temporelle

« Écris une requête KQL qui détecte les anomalies de volume sur la table CommonSecurityLog en utilisant series_decompose_anomalies, avec un intervalle horaire sur 21 jours et un seuil de sensibilité modéré. Ajoute une visualisation timechart. »

Output attendu : une requête de série temporelle avec make-series, décomposition d'anomalies et rendu graphique.

Prérequis : plugin NL2KQL, rétention suffisante sur la table ciblée.

Conseil : ces fonctions sont puissantes mais coûteuses. Testez sur une plage réduite avant de les planifier en règle analytique.

Prompt 30 — Préparer une requête pour une règle analytique

« Transforme cette requête de chasse en requête de règle analytique Sentinel : ajoute le mapping d'entités pour le compte, l'hôte et l'adresse IP, ajoute des custom details pertinents et propose un titre d'alerte dynamique qui inclut le nom du compte concerné : [coller la requête] »

Output attendu : la requête enrichie plus la configuration d'entity mapping et d'alert details à recopier dans l'assistant.

Prérequis : plugin Microsoft Sentinel et NL2KQL.

Conseil : le mapping d'entités est ce qui rend un incident investigable dans Sentinel. Une règle sans entity mapping produit des alertes que personne ne peut corréler.

Catégorie 4 — Analyse des règles analytiques : 8 prompts

Le pilotage de la qualité des détections est le chantier le plus négligé des SOC. Ces prompts transforment une revue de règles annuelle et pénible en exercice hebdomadaire de quelques minutes.

Prompt 31 — Évaluer une règle analytique

« Évalue la règle analytique Sentinel nommée "Connexion suspecte depuis IP TOR" : combien d'incidents a-t-elle générés sur 90 jours, quel est son taux de faux positifs sur la base des clôtures, sa logique de détection est-elle solide et quels sont ses angles morts ? »

Output attendu : une fiche d'évaluation combinant volumétrie, ratio vrais/faux positifs et critique de la logique de détection.

Prérequis : plugin Microsoft Sentinel, droits de lecture sur les règles et sur SecurityIncident.

Conseil : le taux de faux positifs n'est fiable que si vos analystes renseignent correctement les motifs de clôture. Si ce n'est pas le cas, corrigez d'abord cette hygiène.

Prompt 32 — Réduire les faux positifs d'une règle

« Cette règle génère trop de faux positifs. Analyse les incidents qu'elle a produits et clôturés en faux positif sur 60 jours, identifie les motifs récurrents (comptes, machines, plages horaires, processus) et propose des exclusions KQL précises qui ne dégraderaient pas la détection des vrais positifs. »

Output attendu : les motifs récurrents identifiés, des clauses d'exclusion prêtes à coller et une estimation de la réduction de volume.

Prérequis : plugin Microsoft Sentinel, historique de clôtures qualifié.

Conseil : c'est le prompt à plus fort impact de toute cette liste sur la charge du SOC. Documentez chaque exclusion ajoutée : une exclusion non documentée devient un angle mort permanent.

Prompt 33 — Concevoir une stratégie d'exclusion par watchlist

« Propose une approche par watchlist pour gérer les exclusions de cette règle plutôt que de coder les exceptions en dur dans le KQL. Décris le schéma de la watchlist, la modification à apporter à la requête et le processus de gouvernance des ajouts. »

Output attendu : le schéma de watchlist, la requête modifiée avec _GetWatchlist() et un processus de revue des exceptions.

Prérequis : plugin Microsoft Sentinel.

Conseil : une exclusion en watchlist se modifie sans toucher à la règle et sans redéploiement. C'est la bonne pratique dès que vous dépassez trois exceptions.

Prompt 34 — Ajuster fréquence, fenêtre et seuils

« Analyse la configuration de cette règle analytique : la fréquence d'exécution, la période de recherche et le seuil de déclenchement sont-ils cohérents entre eux et adaptés au comportement observé des données ? Propose une configuration optimisée en justifiant chaque changement. »

Output attendu : un diagnostic des incohérences (double comptage, fenêtre trop courte, seuil arbitraire) et un paramétrage corrigé.

Prérequis : plugin Microsoft Sentinel.

Conseil : l'erreur la plus répandue est une période de recherche supérieure à la fréquence sans déduplication : la même alerte se déclenche plusieurs fois pour un événement unique.

Prompt 35 — Auditer le mapping d'entités

« Vérifie le mapping d'entités de cette règle analytique : les entités déclarées correspondent-elles aux colonnes réellement retournées par la requête ? Manque-t-il des entités exploitables ? Propose un mapping complet ainsi que des custom details utiles au triage. »

Output attendu : un audit du mapping avec les entités manquantes et une proposition de custom details.

Prérequis : plugin Microsoft Sentinel.

Conseil : un mapping d'entités cassé (colonne renommée après une évolution de schéma) produit des incidents vides. C'est une panne silencieuse à vérifier après chaque changement de connecteur.

Prompt 36 — Optimiser le regroupement d'alertes

« Analyse la configuration de regroupement d'alertes en incidents de cette règle. Compte tenu du volume d'alertes produites, le regroupement actuel est-il pertinent ? Propose une stratégie de groupement par entité et une fenêtre temporelle adaptée pour éviter la fatigue d'alerte. »

Output attendu : une recommandation de configuration d'incident grouping avec la fenêtre et les clés de regroupement.

Prérequis : plugin Microsoft Sentinel.

Conseil : une règle qui génère 200 incidents séparés pour une même campagne de brute force est une règle mal groupée, pas une règle efficace.

Prompt 37 — Vérifier le mapping MITRE ATT&CK

« Vérifie que le mapping MITRE ATT&CK déclaré sur cette règle correspond bien à ce que sa logique de détection identifie réellement. Si le mapping est incorrect ou incomplet, propose les tactiques et techniques appropriées avec une justification. »

Output attendu : une validation ou correction du mapping tactique/technique.

Prérequis : plugin Microsoft Sentinel.

Conseil : les mappings erronés faussent votre matrice de couverture et vous font croire que vous détectez ce que vous ne détectez pas. Auditez en priorité vos règles personnalisées.

Prompt 38 — Identifier les règles silencieuses ou défaillantes

« Liste les règles analytiques activées de mon workspace qui n'ont produit aucune alerte au cours des 90 derniers jours, ainsi que celles dont l'exécution a échoué. Pour chacune, propose une hypothèse : source de données absente, requête cassée, seuil inatteignable ou absence réelle de menace. »

Output attendu : deux listes — règles muettes et règles en échec — avec un diagnostic par règle.

Prérequis : plugin Microsoft Sentinel, lecture de la table SentinelHealth.

Conseil : une règle silencieuse depuis 90 jours est presque toujours cassée, pas chanceuse. À passer en revue mensuelle systématique.

Catégorie 5 — Reporting SOC : 7 prompts

Le reporting est le domaine où Copilot fait gagner le plus d'heures calendaires, parce qu'il s'agit de reformulation à partir de données déjà présentes. C'est aussi celui où la relecture humaine reste obligatoire : un rapport transmis à un client ou à un régulateur engage votre responsabilité.

Prompt 39 — Rédiger le rapport d'incident complet

« Rédige un rapport d'incident complet pour cet incident, structuré ainsi : résumé exécutif, chronologie des faits, entités et systèmes affectés, analyse technique, actions de réponse menées, impact évalué et recommandations. Ton factuel, aucune spéculation non signalée comme telle. »

Output attendu : un rapport structuré de plusieurs sections, directement exploitable après relecture.

Prérequis : plugin Microsoft Sentinel. Le promptbook « Microsoft Sentinel incident investigation » fourni par Microsoft couvre ce cas de bout en bout.

Conseil : enchaînez-le après les prompts 1 à 5 dans la même session : le rapport sera bien plus riche s'il s'appuie sur l'investigation déjà menée dans le fil de conversation.

Prompt 40 — Produire un résumé pour la direction

« Rédige un résumé exécutif de cet incident destiné à un comité de direction non technique : que s'est-il passé, quel est l'impact sur l'activité, qu'avons-nous fait, quel est le risque résiduel et de quoi avons-nous besoin. Maximum 300 mots, aucun acronyme technique non explicité. »

Output attendu : un texte court, orienté risque métier, sans jargon.

Prérequis : plugin Microsoft Sentinel.

Conseil : la contrainte de longueur est ce qui rend ce prompt efficace. Sans plafond de mots, Copilot produit trois pages que personne ne lira.

Prompt 41 — Générer le rapport hebdomadaire du SOC

« Génère le rapport d'activité hebdomadaire de mon SOC pour les 7 derniers jours : nombre d'incidents créés par gravité, nombre clôturés, répartition par classification de clôture, top 5 des règles les plus déclenchées, incidents encore ouverts au-delà de 48 heures et tendance par rapport à la semaine précédente. »

Output attendu : un tableau de bord textuel avec les volumétries et la comparaison hebdomadaire.

Prérequis : plugin Microsoft Sentinel.

Conseil : c'est le candidat idéal pour un promptbook exécuté chaque lundi. Voir notre guide des promptbooks Copilot Security pour l'automatiser proprement.

Prompt 42 — Calculer les métriques MTTD et MTTR

« Calcule le MTTD et le MTTR de mon SOC sur les 30 derniers jours, globalement puis segmentés par gravité d'incident. Indique la méthode de calcul utilisée, les incidents exclus du calcul et leur raison d'exclusion. »

Output attendu : les deux métriques avec leur segmentation et la méthodologie explicite.

Prérequis : plugin Microsoft Sentinel, horodatages de création, de première action et de clôture correctement renseignés.

Conseil : exigez la méthode de calcul. Le MTTR mesuré depuis la création de l'incident et le MTTR mesuré depuis la première activité malveillante donnent des chiffres qui diffèrent d'un facteur dix.

Prompt 43 — Préparer le retour d'expérience post-incident

« À partir de cet incident, prépare une revue post-incident : qu'est-ce qui a bien fonctionné dans la détection et la réponse, qu'est-ce qui a échoué ou pris trop de temps, quelles détections manquaient, et quelles actions correctives recommandes-tu avec un niveau de priorité et un responsable suggéré ? »

Output attendu : un document de RETEX avec un plan d'action priorisé.

Prérequis : plugin Microsoft Sentinel.

Conseil : Copilot ne connaît pas vos contraintes organisationnelles. Traitez sa liste d'actions comme un brouillon à arbitrer en réunion, pas comme un plan validé.

Prompt 44 — Préparer les éléments de notification réglementaire

« À partir de cet incident, rassemble les éléments factuels nécessaires à une éventuelle notification réglementaire : nature de l'incident, date et heure de détection, catégories de données potentiellement concernées, nombre estimé de personnes affectées, mesures prises et mesures envisagées. Signale explicitement les informations manquantes. »

Output attendu : une fiche de collecte structurée, avec la liste des trous à combler manuellement.

Prérequis : plugin Microsoft Sentinel.

Conseil : Copilot rassemble des faits techniques, il ne qualifie pas juridiquement l'incident. La décision de notifier et la rédaction finale relèvent du DPO et du juriste, jamais de l'outil.

Prompt 45 — Analyser les tendances mensuelles

« Analyse l'évolution des incidents de mon workspace sur les 6 derniers mois : quelles tactiques MITRE progressent, quels types d'incidents diminuent, quelles nouvelles règles ont commencé à produire du volume et quelles tendances mériteraient une action structurelle ? »

Output attendu : une analyse de tendance avec identification des signaux structurels plutôt que du bruit ponctuel.

Prérequis : plugin Microsoft Sentinel, rétention de 6 mois sur SecurityIncident.

Conseil : c'est le prompt qui alimente utilement un comité de sécurité trimestriel. Demandez à Copilot de distinguer les variations liées à un changement de configuration de celles liées à un changement de menace.

Catégorie 6 — Administration du workspace : 5 prompts

Ces prompts sortent du périmètre strict de la détection pour toucher au pilotage économique et opérationnel de la plateforme. Ce sont ceux dont le responsable SOC a besoin pour défendre son budget.

Prompt 46 — Analyser les coûts d'ingestion

« Analyse la volumétrie d'ingestion de mon workspace Sentinel sur les 30 derniers jours : quelles sont les 10 tables les plus volumineuses en gigaoctets, quelle est leur part du volume total et quelle est leur tendance sur la période ? Identifie les tables dont le volume a augmenté de plus de 20 %. »

Output attendu : un classement des tables par volume ingéré avec la tendance. Copilot s'appuie typiquement sur la table Usage.

Prérequis : plugin NL2KQL, droits de lecture sur le workspace Log Analytics. Copilot ne consulte pas votre facturation Azure : il raisonne sur des volumes, à vous d'appliquer votre tarif contractuel.

Conseil : demandez le résultat en gigaoctets et faites la conversion en euros vous-même. Les estimations de coût produites par le modèle reposent sur des tarifs génériques qui ne sont pas les vôtres.

Prompt 47 — Contrôler la santé du workspace

« Fais un bilan de santé de mon workspace Microsoft Sentinel : latence d'ingestion par table, règles analytiques en échec d'exécution, règles d'automatisation en erreur et sources de données ayant cessé d'émettre. Classe les problèmes par criticité. »

Output attendu : un rapport de santé priorisé s'appuyant sur SentinelHealth et Heartbeat.

Prérequis : plugin Microsoft Sentinel et NL2KQL, fonctionnalité de health monitoring activée sur le workspace.

Conseil : si la fonctionnalité SentinelHealth n'est pas activée, la table est vide et Copilot vous répondra qu'il ne trouve rien. Activez-la avant de vous étonner du silence.

Prompt 48 — Détecter les connecteurs défaillants

« Identifie les connecteurs de données de mon workspace qui n'ont ingéré aucun événement depuis plus de 24 heures alors qu'ils émettaient régulièrement auparavant. Pour chacun, indique la date du dernier événement reçu et le volume moyen quotidien historique. »

Output attendu : une liste de sources silencieuses avec leur baseline historique — la panne la plus dangereuse d'un SIEM, parce qu'elle est invisible.

Prérequis : plugin NL2KQL.

Conseil : transformez ce prompt en règle analytique dédiée. Un connecteur muet n'émet par définition aucune alerte, donc rien ne vous préviendra.

Prompt 49 — Optimiser la rétention et les niveaux de journaux

« Analyse mes tables Sentinel et propose une stratégie d'optimisation des coûts : quelles tables pourraient basculer en journaux auxiliaires ou basiques compte tenu de leur usage réel dans mes règles analytiques et mes requêtes de chasse, et quelles tables doivent rester en journaux analytiques ? »

Output attendu : une recommandation table par table, croisant le volume et l'usage réel dans vos détections.

Prérequis : plugin Microsoft Sentinel et NL2KQL.

Conseil : vérifiez qu'aucune règle analytique ne dépend d'une table avant de la basculer en niveau auxiliaire. Une bascule mal préparée casse silencieusement des détections.

Prompt 50 — Auditer les règles d'automatisation

« Liste mes règles d'automatisation Sentinel et leurs playbooks associés : lesquelles se sont déclenchées au cours des 30 derniers jours, lesquelles ont échoué, et lesquelles n'ont jamais été déclenchées depuis leur création ? Propose un plan de nettoyage. »

Output attendu : un inventaire de l'automatisation avec taux de déclenchement et taux d'échec.

Prérequis : plugin Microsoft Sentinel, droits de lecture sur les règles d'automatisation et les Logic Apps.

Conseil : les playbooks orphelins consomment des ressources et créent une illusion de couverture automatisée. Une revue semestrielle suffit.

Ce que les prompts Sentinel ne savent pas faire : limites à connaître

Un guide de prompts qui ne dit pas où l'outil s'arrête produit des utilisateurs déçus. Voici les limites structurelles observées, à intégrer dans votre gouvernance avant de déployer Copilot auprès de vos analystes.

Une couverture de tables encore partielle

Les deux plugins Sentinel sont en préversion et Microsoft indique explicitement que toutes les tables Microsoft Sentinel ne sont pas prises en charge dans l'expérience de chasse avancée du portail Defender unifié. Concrètement, vos tables personnalisées et certains connecteurs tiers peuvent être invisibles pour la génération de KQL. Testez avant de bâtir un runbook dessus.

Aucune élévation de privilèges, aucune action autonome

Copilot lit ce que vous avez le droit de lire et propose ce que vous pourriez faire. Il n'isole pas une machine, ne désactive pas un compte et ne modifie pas une règle de sa propre initiative dans le mode conversationnel. Les scénarios d'action automatisée relèvent des agents et des playbooks, avec leur propre modèle de gouvernance.

Une dépendance totale à la qualité de vos données

Un dwell time calculé sur une rétention de 30 jours est faux au-delà de 30 jours. Un taux de faux positifs calculé sur des incidents clôturés sans motif renseigné est faux tout court. Copilot amplifie la qualité de votre hygiène de données ; il ne la remplace pas.

Des réponses non déterministes

Le même prompt exécuté deux fois peut produire deux formulations différentes, et parfois deux requêtes KQL différentes. Pour tout usage récurrent — reporting hebdomadaire, revue de règles — passez par un promptbook plutôt que par un prompt libre, afin de stabiliser la séquence et le format.

Un coût en capacité de calcul

Chaque prompt consomme de la capacité. Un prompt mal formulé qui doit être relancé trois fois coûte trois fois. Sur un SOC de dix analystes, la discipline de formulation a un impact budgétaire mesurable. C'est un argument supplémentaire en faveur des promptbooks partagés.

Comment formuler de meilleurs prompts Sentinel

Les règles suivantes ressortent de l'usage quotidien et recoupent les recommandations officielles de Microsoft sur la formulation des invites.

Nommez toujours le périmètre temporel et le workspace

« Les connexions suspectes » n'est pas une question. « Les connexions suspectes des 7 derniers jours dans l'espace de travail soc-prod-eu » en est une. Le périmètre temporel est le premier facteur de précision, et il conditionne aussi le coût d'exécution de la requête sous-jacente.

Précisez le format de sortie attendu

Tableau, liste numérotée, nombre de lignes maximum, colonnes souhaitées : plus vous contraignez le format, plus la réponse est exploitable. La contrainte de longueur est particulièrement efficace pour les rapports destinés à un lectorat non technique.

Désignez explicitement l'audience

« Explique cet incident à un administrateur système », « à un DPO », « à un comité de direction » : Copilot adapte réellement son niveau technique. C'est le levier le plus simple pour éviter les réécritures.

Enchaînez les prompts dans une même session

Copilot conserve le contexte de la conversation. Après un premier prompt qui pose l'incident, les suivants peuvent utiliser « cet incident », « ce compte », « cette requête ». Une session bien construite vaut mieux que dix prompts isolés, et coûte moins cher en capacité.

Interdisez explicitement les identifiants techniques

La mention « sans ID d'objet, donne les noms lisibles » transforme radicalement la lisibilité des réponses. Sans elle, vous obtenez des GUID que vous devrez résoudre manuellement.

Français ou anglais ?

Les prompts de ce guide sont rédigés en français et fonctionnent parfaitement pour l'investigation, l'analyse et le reporting. En revanche, pour la génération de KQL complexe, l'anglais produit souvent des requêtes plus concises et un mapping de champs plus fiable, car la documentation des schémas et les corpus de requêtes sont majoritairement anglophones. Une pratique efficace : prompt en anglais pour la catégorie 3, prompt en français partout ailleurs, restitution finale en français.

Donnez le contexte métier que Copilot ne peut pas connaître

La criticité de vos actifs, vos fenêtres de maintenance, vos comptes de service légitimes, vos prestataires autorisés à se connecter depuis l'étranger : rien de tout cela n'est déductible des logs. Injectez ce contexte dans le prompt, ou mieux, matérialisez-le dans des watchlists que Copilot pourra interroger.

Industrialiser : du prompt isolé au promptbook SOC

Un prompt utilisé plus de deux fois par semaine doit devenir un promptbook. Un promptbook enchaîne plusieurs prompts dans un ordre défini, accepte des entrées paramétrées (numéro d'incident, nom de compte, plage de dates) et produit un résultat reproductible d'un analyste à l'autre. C'est la différence entre un usage individuel opportuniste et un usage d'équipe gouverné.

Les séquences les plus rentables à transformer en promptbooks à partir de cette liste sont l'investigation complète d'incident (prompts 1 → 3 → 4 → 5 → 39), la revue hebdomadaire des règles bruyantes (31 → 32 → 33) et le reporting de fin de semaine (41 → 42 → 45). Microsoft fournit par ailleurs un promptbook natif d'investigation d'incident Sentinel qui constitue un bon point de départ à personnaliser.

Pour aller plus loin, consultez notre guide dédié aux promptbooks Copilot Security, notre dossier complet sur Microsoft Copilot Security et la référence des prompts Copilot Security par produit qui couvre Defender XDR, Entra, Intune et Purview. Les bibliothèques communautaires, comme le dépôt de prompts Security Copilot de Rod Trent, complètent utilement ce socle.

Questions fréquentes sur les prompts Copilot Security pour Microsoft Sentinel

Faut-il une licence spécifique pour utiliser les prompts Sentinel dans Security Copilot ?

Il n'existe pas de licence « Copilot pour Sentinel » séparée. Vous avez besoin d'un accès à Microsoft Security Copilot, soit via l'inclusion dans une licence Microsoft 365 E5 ou E7 éligible avec provisionnement automatique dans le tenant, soit via un onboarding manuel avec provisionnement d'unités de calcul de sécurité (SCU) depuis un abonnement Azure. À cela s'ajoute évidemment une instance Microsoft Sentinel opérationnelle et les rôles de lecture correspondants sur le workspace. L'éligibilité de licence ne suffit pas : tant que la capacité n'est pas déployée, le portail reste inaccessible.

Quelle est la différence entre le plugin Microsoft Sentinel et le plugin langage naturel vers KQL ?

Le plugin Microsoft Sentinel (préversion) donne accès aux objets de gestion du SIEM : incidents, alertes, entités, règles analytiques, règles d'automatisation. C'est celui qui répond aux questions du type « résume l'incident 4821 ». Le plugin Langage naturel vers KQL pour Microsoft Sentinel (préversion) traduit une intention en requête KQL et l'exécute contre les tables du workspace. C'est celui qui répond à « écris-moi une requête qui... ». Les deux sont indépendants et doivent être activés séparément dans la page de gestion des plug-ins. La plupart des workflows SOC complets nécessitent les deux.

Copilot peut-il exécuter des actions de remédiation dans Sentinel ?

Dans le mode conversationnel, non : Copilot analyse, explique et recommande, mais n'isole pas une machine et ne désactive pas un compte de sa propre initiative. Il agit strictement dans les limites des permissions de l'utilisateur connecté et ne procède à aucune élévation de privilèges. Les scénarios de remédiation automatisée passent par les règles d'automatisation Sentinel, les playbooks Logic Apps et les agents Security Copilot, qui disposent de leur propre modèle d'autorisation et doivent faire l'objet d'une gouvernance distincte. La séparation est saine : l'analyse est assistée, la décision reste humaine.

Les requêtes KQL générées par Copilot sont-elles fiables en production ?

Elles constituent d'excellents brouillons, pas des livrables validés. Sur des requêtes de complexité faible à moyenne, le taux de réussite immédiate est élevé. Sur des requêtes complexes impliquant plusieurs jointures, des fonctions de série temporelle ou des tables personnalisées, une relecture est indispensable : erreurs de mapping de champs, filtres temporels mal placés qui dégradent la performance, ou hypothèses implicites sur le schéma. Ne déployez jamais une requête générée directement en règle analytique planifiée sans l'avoir exécutée manuellement et vérifié la volumétrie qu'elle retourne sur plusieurs jours.

Comment réduire la consommation de capacité liée aux prompts Sentinel ?

Trois leviers concrets. D'abord, cadrez systématiquement la fenêtre temporelle : une question portant sur 7 jours coûte bien moins qu'une question implicitement portée sur toute la rétention. Ensuite, enchaînez vos prompts dans une même session plutôt que de repartir de zéro à chaque question, afin de réutiliser le contexte déjà chargé. Enfin, transformez tout usage récurrent en promptbook : une séquence stabilisée évite les reformulations successives, qui sont la principale source de gaspillage. Surveillez la consommation depuis la page de capacité du portail et identifiez les usages les plus coûteux avant qu'ils ne deviennent un sujet budgétaire.

``` **Conformité SEO** : chapeau 197 mots (premier `

`), ~3 450 mots, 12 H2 (ratio 288 < 350), 5 liens internes, 3 liens externes, FAQ 5 H3 interrogatifs, `.a-retenir` avec les 5 prompts clés, aucun H4 dans un encadré. **Deux points à valider de votre côté** : le lien `/copilot-security/promptbooks` et `/articles/copilot-security-prompts-reference-par-produit` doivent exister en base sous peine de 404 internes — je n'ai pas eu accès à la prod pour le vérifier. Dites-moi si vous voulez que je l'insère en base ou que je génère aussi le PDF.