Bibliothèque complète des promptbooks Microsoft Copilot Security

La permission d'écriture sur `/tmp` n'a pas été accordée (session non interactive), donc je livre l'article directement ici. ```html

Dans un SOC, la qualité d'une investigation dépend rarement de l'outillage : elle dépend de la rigueur avec laquelle l'analyste enchaîne ses questions. C'est exactement le problème que résolvent les promptbooks de Microsoft Security Copilot. Plutôt que de laisser chaque analyste improviser sa séquence de prompts face à un incident, un utilisateur à risque ou un script suspect, le promptbook fige une méthodologie d'investigation sous forme de série d'invites enchaînées, exécutées automatiquement, où chaque réponse alimente la suivante. Le gain est double : un gain de temps immédiat, puisqu'un analyste ne reformule plus manuellement six ou sept prompts pour chaque cas, et surtout un gain de cohérence, puisqu'un analyste N1 produit désormais le même périmètre d'investigation qu'un analyste N3 sur un incident comparable. Cette réutilisabilité transforme le prompt engineering, activité artisanale et non capitalisable, en actif documenté et versionnable au même titre qu'un playbook SOAR. Cet article passe en revue les dix promptbooks de référence, leurs prompts exacts, leurs plugins requis et les optimisations qui font la différence en production.

Qu'est-ce qu'un promptbook dans Copilot Security ?

Un promptbook est une séquence ordonnée de prompts prédéfinis, regroupés pour accomplir une tâche de sécurité précise. Microsoft les décrit explicitement comme l'équivalent conversationnel des playbooks de sécurité : des workflows prêts à l'emploi qui automatisent des étapes répétitives d'investigation ou de réponse à incident. Chaque promptbook prédéfini attend une entrée spécifique — un UPN, un identifiant d'incident, un extrait de code, un numéro CVE — et l'injecte dans l'ensemble de la chaîne.

La différence avec un prompt ponctuel est structurelle, pas cosmétique. Un prompt isolé produit une réponse ; un promptbook produit une investigation. Trois mécanismes l'expliquent :

• L'enchaînement : Security Copilot exécute les invites l'une après l'autre et s'appuie sur chaque réponse pour construire la suivante. Le prompt n°4 « Comment investiguer plus loin ? » n'a de sens que parce que les prompts 1 à 3 ont déjà établi le contexte de risque.
• Les variables : la valeur saisie au lancement (la zone d'entrée affiche par exemple SENTINEL_INCIDENT_ID, SNIPPET ou CVEID) est propagée à toutes les invites qui la référencent. Un seul point de saisie, zéro copier-coller.
• Le contexte persistant : l'exécution se déroule dans une session unique. Les entités extraites, les verdicts de réputation et les résultats de plugins restent disponibles pour les invites suivantes, y compris pour la synthèse finale.

On accède à la bibliothèque via l'icône Requêtes (l'icône « sparkle ») de la barre d'invite, puis Afficher tous les guides. Les promptbooks prédéfinis publiés par Microsoft couvrent l'analyse de script suspect, l'enquête sur les incidents Sentinel et Defender XDR, le profil d'acteur de menace, l'évaluation de l'impact sur les vulnérabilités, l'analyse des utilisateurs Microsoft, la vérification de l'impact d'une menace externe et le rapport Threat Intelligence 360 basé sur un article MDTI. À cette base officielle s'ajoute un écosystème communautaire important, dont le dépôt de référence rod-trent/Security-Copilot, qui publie des promptbooks additionnels directement importables dans un tenant.

Les 10 promptbooks officiels décryptés

1. Risky User — investigation d'un utilisateur à risque

Objectif : qualifier en quelques minutes un utilisateur remonté par Microsoft Entra ID Protection, comprendre pourquoi le moteur de risque l'a classé ainsi, et décider entre remédiation, escalade et faux positif.

Plugins requis : Microsoft Entra (obligatoire), Microsoft Defender XDR et Microsoft Threat Intelligence (recommandés pour l'enrichissement).

Séquence exacte :

1. Check if <USER_UPN> is a risky user?
2. Give me detailed context as to why the user is risky
3. Does the user have a risky sign in device?
4. How should I investigate further this risky user?
5. What additional security methods can be invoked to take down the user from the risky user list?

Variable à adapter : <USER_UPN>, sous forme d'UPN complet ([email protected]) et non d'alias SAM.

Cas d'usage : alerte « Utilisateur à risque élevé » déclenchée à 3 h du matin. L'analyste N1 lance le promptbook, obtient en une passe le niveau de risque, les détections sous-jacentes (voyage impossible, adresse IP anonymisée, identifiants divulgués), l'état des appareils utilisés et la liste des actions correctives disponibles.

Sortie attendue : un verdict de risque (élevé / moyen / faible), le détail des risk detections horodatées avec IP et localisation, le statut de conformité des appareils de connexion, puis une liste d'actions — réinitialisation de mot de passe, révocation des sessions, exigence de réauthentification MFA, confirmation de compromission.

Optimisation : ajoutez un sixième prompt maison demandant les rôles Entra ID privilégiés portés par le compte. Un utilisateur à risque disposant d'un rôle Administrateur d'application ne se traite pas comme un utilisateur standard, et cette information conditionne l'escalade immédiate.

2. Suspicious Script Analysis — analyse de script potentiellement malveillant

Objectif : désobfusquer et qualifier un script PowerShell ou une ligne de commande Windows récupérée sur un poste, extraire ses indicateurs et produire une recommandation de durcissement.

Plugins requis : Microsoft Threat Intelligence (MDTI) pour la réputation et les articles, Microsoft Defender XDR pour la corrélation avec la télémétrie.

Séquence exacte :

1. Coller le script dans la zone SNIPPET, puis explain this script step by step and what is its intent
2. Is this script malicious?
3. Check the reputation of any IPs or hostnames found
4. Look for any threat intelligence articles related to these indicators
5. Find profiles of any related threat actors
6. What policy changes should be made to protect against it?
7. Write an executive summary of your findings

Variable à adapter : SNIPPET — le corps du script. Retirez les secrets internes avant soumission et conservez l'obfuscation d'origine : c'est précisément ce que le moteur doit décoder.

Cas d'usage : un one-liner powershell -enc détecté sur un serveur de fichiers. Le promptbook décode le Base64, identifie un téléchargement de charge secondaire, extrait le domaine C2 et remonte les articles MDTI associés.

Sortie attendue : décomposition ligne par ligne avec intention, verdict argumenté (malveillant / suspect / bénin), table des IOC avec scores de réputation, articles de renseignement liés, profil d'acteur éventuel, puis recommandations de politiques (contraintes AMSI, mode de langage contraint PowerShell, règles ASR, blocage sortant).

Optimisation : demandez systématiquement en prompt final une requête KQL de recherche rétroactive sur les IOC extraits. Vous transformez une analyse statique en chasse effective sur trente jours de journaux.

3. Incident Prioritization (Defender XDR) — priorisation des incidents critiques

Objectif : construire la file de traitement de la journée en croisant sévérité des incidents, risque utilisateur et faiblesses de posture, au lieu de dépiler la console dans l'ordre chronologique.

Plugins requis : Microsoft Defender XDR, Microsoft Entra ID Protection.

Séquence exacte :

1. Give me the top 5 high severity incidents from Microsoft Defender XDR that I should prioritize today
2. Show me risky user sign-ins in the past week for users connected to those incidents
3. What other suspicious behaviors are associated with those users?
4. Summarize all findings about user activities, incidents and security weaknesses
5. What are your prioritized recommendations to mitigate these threats?

Variables à adapter : le nombre d'incidents (5 par défaut) et la fenêtre temporelle (past week). Sur un tenant à fort volume, montez à 10 incidents et réduisez la fenêtre à 48 heures.

Cas d'usage : rituel de prise de poste du matin. Le promptbook remplace la revue manuelle de la file d'incidents et fournit un ordre de traitement argumenté au shift lead.

Sortie attendue : liste ordonnée des incidents avec titre, sévérité, entités impactées et raison de priorisation ; tableau des connexions à risque associées ; corrélation comportementale ; synthèse consolidée ; plan d'action hiérarchisé.

Optimisation : ajoutez un filtre métier explicite dans le premier prompt — « limité aux incidents touchant les comptes du périmètre Finance ou les serveurs Tier 0 ». La priorisation devient contextualisée à votre modèle de risque plutôt qu'à la seule sévérité produit.

4. Vulnerability Assessment — évaluation de l'impact d'une CVE

Objectif : déterminer si une vulnérabilité publiée a été divulguée ou exploitée publiquement, si des acteurs de menace l'utilisent dans leurs campagnes, et produire une recommandation d'atténuation avec un résumé exploitable par la direction.

Plugins requis : Microsoft Threat Intelligence, Microsoft Defender Vulnerability Management (pour l'exposition interne).

Séquence exacte :

1. Summarize <CVEID>
2. What technologies and systems are affected?
3. Find related threat intelligence articles
4. What threat actors are associated with this vulnerability?
5. What mitigation strategies are recommended?
6. Write an executive summary for stakeholders

Variable à adapter : <CVEID> au format canonique CVE-2026-XXXXX. Le promptbook accepte également un nom de vulnérabilité usuel.

Cas d'usage : lendemain de Patch Tuesday, une CVE critique d'élévation de privilèges Windows fait la une. Le promptbook produit en dix minutes la note d'exposition attendue par le RSSI.

Sortie attendue : résumé technique avec vecteur et score CVSS, périmètre des produits et versions affectés, articles de renseignement associés, acteurs exploitant la faille, stratégies d'atténuation (correctif, contournement, détection), et résumé exécutif non technique.

Optimisation : intercalez un prompt d'exposition interne — « Combien d'appareils de mon organisation sont affectés par cette CVE ? ». Sans cette étape, vous produisez une fiche de veille ; avec elle, vous produisez une décision de patch management.

5. Threat Actor Profile — profil d'un groupe APT

Objectif : obtenir un dossier consolidé sur un acteur — TTP, outillage, secteurs et zones ciblés, indicateurs — et le traduire en recommandations défensives applicables.

Plugins requis : Microsoft Threat Intelligence (MDTI).

Séquence exacte :

1. Give me a profile summary of <THREATACTORNAME>
2. What are the known TTPs of this threat actor?
3. Find threat intelligence articles about this actor with summaries and references
4. What defensive recommendations can I take based on that intelligence?
5. Write a non-technical executive summary of your findings

Variable à adapter : <THREATACTORNAME>. Privilégiez la taxonomie Microsoft actuelle (noms météorologiques : Midnight Blizzard, Storm-1811) ; les alias historiques fonctionnent mais dégradent la couverture.

Cas d'usage : un rapport sectoriel attribue une campagne à un acteur donné. L'équipe threat intelligence produit une fiche de posture défensive en une session au lieu d'une demi-journée de lecture.

Sortie attendue : profil (origine présumée, motivations, cibles), matrice de TTP mappées MITRE ATT&CK, bibliographie MDTI référencée, recommandations défensives par technique, puis synthèse dirigeants.

Optimisation : demandez une requête de chasse par technique ATT&CK majeure. Cette approche est détaillée dans notre guide sur les prompts de threat hunting alignés MITRE, et se prolonge naturellement par une validation offensive de la chaîne d'attaque en pentest Active Directory.

6. Sentinel Investigation — investigation d'un incident Microsoft Sentinel

Objectif : dérouler une investigation complète d'incident Sentinel, de la synthèse initiale au rapport exécutif, en couvrant entités, réputation, posture d'authentification et conformité des appareils.

Plugins requis : Microsoft Sentinel et Microsoft Intune. Sans Intune, les deux dernières étapes retournent des réponses vides.

Séquence exacte :

1. Summarize Sentinel incident <INCIDENTID>
2. Tell me about the entities associated with that incident
3. Check the IP reputation of all IPv4 addresses in that incident
4. What authentication methods do the involved users have — are they MFA-enabled?
5. What devices did those users access and what's their compliance status?
6. Check OS update status via Intune for the most recently active device
7. Write an executive summary

Variable à adapter : <INCIDENTID> — le numéro d'incident Sentinel, saisi dans la zone d'entrée SENTINEL_INCIDENT_ID. Vérifiez que l'espace de travail ciblé est bien celui configuré dans le plugin.

Cas d'usage : incident « Connexion suspecte suivie d'une création de règle de boîte aux lettres ». Le promptbook établit la chronologie, qualifie les IP sources, révèle que l'utilisateur ne dispose que de la MFA par SMS et que son poste accuse trois mois de retard de correctifs.

Sortie attendue : résumé d'incident avec alertes constitutives et chronologie, inventaire des entités (comptes, hôtes, IP, URL), scores de réputation, tableau des méthodes d'authentification par utilisateur, état de conformité Intune, niveau de mise à jour de l'OS, et rapport exécutif final.

Optimisation : voir notre analyse dédiée à l'investigation d'incidents Sentinel avec Copilot Security. En pratique, remplacez l'étape 6 par une boucle sur tous les appareils non conformes lorsque l'incident implique plus de deux comptes.

7. 365 Defender Investigation — investigation d'un incident Defender XDR

Objectif : équivalent du précédent pour les incidents nativement Defender XDR, avec une meilleure profondeur sur la télémétrie endpoint et identité.

Plugins requis : Microsoft Defender XDR et Microsoft Intune.

Séquence exacte :

1. Summarize Defender incident <INCIDENTID>
2. Check the IP reputation of all IPv4 addresses
3. Show authentication methods for each user in the incident — MFA enabled?
4. What devices did those users access and what's their compliance?
5. Check Intune for OS patch status on most active device
6. Write an executive summary for leadership

Variable à adapter : <INCIDENTID>, l'identifiant numérique visible dans le portail Microsoft Defender.

Cas d'usage : incident multi-étapes classé « Élevé » impliquant un phishing suivi d'une exécution locale. Le promptbook consolide en une session ce qui demanderait sinon la navigation entre trois portails distincts.

Sortie attendue : synthèse d'incident avec arbre d'attaque, réputation des IP, posture MFA par compte, inventaire et conformité des appareils, état de patch, rapport de direction.

Optimisation : lancez ce promptbook après le promptbook de priorisation, en lui passant les identifiants qu'il a remontés. Vous obtenez une chaîne priorisation → investigation entièrement guidée. Attention à un écueil récurrent : si l'incident agrège plus d'une dizaine d'entités, la synthèse finale tronque. Découpez alors l'investigation par entité.

8. KQL Request Template — génération de requêtes KQL en langage naturel

Objectif : produire des requêtes KQL syntaxiquement correctes et correctement typées sans maîtriser le schéma des tables, en cadrant strictement la demande.

Plugins requis : aucun plugin externe pour la génération ; Sentinel ou Defender XDR pour l'exécution directe.

Template de référence :

Use the following information to generate a proper KQL query for <PRODUCT_NAME> :
Table: <TABLE>
Time range: <RANGE>
Query: <WHAT_TO_SEARCH>
Display: <HOW_TO_DISPLAY>

Variables à adapter : <PRODUCT_NAME> (Microsoft Sentinel, Microsoft Defender XDR, Azure Log Analytics), <TABLE>, <RANGE>, <WHAT_TO_SEARCH>, <HOW_TO_DISPLAY>.

Trois exemples opérationnels. Pour Sentinel : table SigninLogs, plage 7 jours, recherche des connexions réussies depuis des pays hors zone d'activité, affichage par utilisateur et pays avec compteur. Pour Defender XDR : table DeviceProcessEvents, plage 24 heures, recherche des processus enfants de winword.exe, affichage horodaté avec ligne de commande. Pour Log Analytics : table Heartbeat, plage 1 heure, détection des agents silencieux, affichage de la liste des machines manquantes.

Sortie attendue : la requête KQL commentée, l'explication des opérateurs employés et, fréquemment, des suggestions de filtres complémentaires.

Optimisation : la précision du champ Display détermine la qualité du résultat. « Afficher en table triée par nombre décroissant, colonnes UserPrincipalName, Location, count » produit une requête directement exploitable ; « afficher les résultats » produit un project approximatif. Validez toujours la requête générée avant de l'intégrer à une règle analytique.

9. Service Now Enrichment — enrichissement d'incidents ITSM

Objectif : sortir un ticket ServiceNow de son silo ITSM en l'enrichissant de renseignement sur les menaces et de contexte identitaire avant traitement.

Plugins requis : plugin ServiceNow (configuration d'instance et d'identifiants requise), Microsoft Threat Intelligence, Microsoft Entra.

Séquence exacte :

1. Analyze Service Now incident <IncidentID>
2. Show me work notes and comments
3. Show high priority incidents from the past 7 days
4. Cross-reference with known vulnerabilities and threat actors
5. Check MFA status for involved users
6. Write executive summary with incident details, intel, and remediation

Variable à adapter : <IncidentID> au format ServiceNow (INC0012345). La fenêtre de 7 jours de l'étape 3 se règle selon le volume de tickets.

Cas d'usage : un ticket support « poste lent, comportement anormal » ouvert par le helpdesk. L'enrichissement révèle une corrélation avec deux autres tickets de la même semaine et une CVE activement exploitée sur la version applicative concernée.

Sortie attendue : description et état du ticket, historique des notes de travail, incidents prioritaires corrélés, croisement vulnérabilités et acteurs, posture MFA des utilisateurs impliqués, et résumé exécutif avec plan de remédiation.

Optimisation : c'est le promptbook au plus fort retour sur investissement dans les organisations où le SOC et le support N1 ne partagent pas d'outil. Restreignez le compte de service ServiceNow en lecture seule sur les tables d'incidents : le promptbook n'a besoin d'aucun droit d'écriture.

10. Power of Use — démonstration des capacités

Objectif : ce promptbook n'a pas de finalité d'investigation. Il sert de bac à sable pédagogique pour explorer la combinaison de plugins, la profondeur d'analyse et les formats de restitution disponibles.

Plugins requis : le maximum de plugins activés — c'est précisément l'objet de l'exercice.

Cas d'usage : phase d'onboarding d'un nouvel analyste, ou atelier d'évaluation avant décision d'achat de SCU (Security Compute Units). L'équipe teste des combinaisons multi-plugins — corréler un article MDTI avec la télémétrie Defender, puis générer la requête de chasse et le ticket associé — et mesure la consommation de capacité réelle.

Sortie attendue : variable par construction. L'intérêt est ailleurs : identifier quels enchaînements produisent une valeur réelle dans votre contexte, puis les figer dans un promptbook personnalisé.

Optimisation : imposez une discipline de journalisation. Chaque session d'exploration concluante doit se solder par la création d'un promptbook nommé et documenté, sinon la connaissance reste dans la tête de celui qui a fait le test.

Comment créer son propre promptbook

La création s'effectue depuis l'interface Security Copilot. Depuis une session dont vous êtes satisfait, ou depuis la bibliothèque de promptbooks, vous enregistrez la séquence sous forme de promptbook personnalisé. Les champs demandés sont systématiquement les mêmes : un nom, une description expliquant ce que le promptbook accomplit, des tags pour la recherche dans la bibliothèque, la liste ordonnée des prompts, les entrées (variables) avec leur libellé d'affichage, et le périmètre de partage — privé, partagé avec l'organisation, ou restreint à un groupe.

Les variables se déclarent en majuscules avec des séparateurs explicites : <USER_UPN>, <INCIDENT_ID>, <TIME_RANGE>. Le libellé que vous donnez à l'entrée est celui que l'analyste verra dans la zone de saisie — écrivez « UPN de l'utilisateur à investiguer (format [email protected]) » plutôt que « USER ». Une variable référencée dans plusieurs prompts n'est saisie qu'une seule fois.

La documentation Microsoft décrit la création et l'exécution via l'interface ; il n'existe pas de format d'échange YAML publié officiellement pour les promptbooks. En revanche, la communauté partage couramment les promptbooks sous forme de fichiers texte structurés que l'on recopie dans l'interface. Une convention interne du type suivant reste très utile pour le versionnage dans Git, à condition de la considérer comme une représentation documentaire et non comme un format d'import natif :

name: SOC-INV-EntraRiskyUser-v2
description: Investigation utilisateur a risque Entra ID Protection
tags: [entra, identite, N1]
inputs:
  - name: USER_UPN
    label: UPN de l'utilisateur ([email protected])
prompts:
  - Check if <USER_UPN> is a risky user?
  - Give me detailed context as to why the user is risky
  - ...

Côté nommage, adoptez un schéma <ÉQUIPE>-<DOMAINE>-<OBJET>-v<N>. Avec cinquante promptbooks en bibliothèque, un nom explicite et versionné évite qu'un analyste exécute une version obsolète. La création d'agents et de promptbooks personnalisés est approfondie dans notre article dédié aux agents et promptbooks personnalisés Copilot Security. La procédure officielle d'exécution est documentée sur Microsoft Learn.

Promptbooks vs prompts ponctuels : quand utiliser quoi ?

Les deux modes ne s'opposent pas, ils couvrent des moments différents de l'investigation. Le promptbook excelle sur le connu et le répétitif ; le prompt ponctuel excelle sur l'exploration et l'imprévu.

Critère	Promptbook	Prompt ponctuel
Cas d'usage	Investigation standardisée, récurrente	Question exploratoire, cas atypique
Reproductibilité	Élevée — même séquence pour tous	Faible — dépend de l'analyste
Temps de mise en œuvre	Une saisie, exécution automatique	Reformulation à chaque étape
Souplesse	Limitée à la séquence figée	Totale, pivot immédiat
Consommation de SCU	Prévisible et mesurable	Variable, difficile à budgéter
Niveau d'analyste	N1 et N2 sans perte de qualité	N2 et N3 expérimentés
Traçabilité	Séquence auditable, versionnable	Historique de session uniquement

En pratique, le schéma le plus efficace est hybride : promptbook pour établir la base factuelle de l'investigation, puis prompts ponctuels pour creuser l'anomalie que le promptbook a fait apparaître. Un analyste qui n'utilise que des promptbooks passe à côté des signaux faibles ; un analyste qui n'utilise que des prompts libres produit des investigations non comparables entre elles.

Optimiser ses promptbooks pour le SOC

Injecter le contexte organisationnel. Les promptbooks officiels sont génériques par nécessité. Le premier levier d'amélioration consiste à leur ajouter vos propres invariants : périmètre Tier 0, plages IP des sites, noms des groupes d'administration, fenêtres de maintenance, comptes de service légitimes. Un prompt final du type « Exclus de l'analyse les connexions provenant des plages du VPN d'entreprise et les activités des comptes de service listés » supprime une part importante des faux positifs traités manuellement.

Intégrer aux playbooks existants. Le promptbook ne remplace pas le SOAR, il l'alimente. Le schéma qui fonctionne : le playbook Logic Apps effectue les actions déterministes (isolation, révocation de session, création de ticket), le promptbook produit l'analyse et la synthèse humainement lisible qui justifie ces actions. Documentez explicitement dans chaque procédure d'investigation quel promptbook s'exécute à quelle étape.

Versionner sérieusement. Conservez les promptbooks personnalisés dans un dépôt Git au même titre que les règles analytiques. Chaque modification de séquence doit être tracée avec son motif : un promptbook qui change de comportement sans que personne ne sache pourquoi devient un risque de qualité. Prévoyez une revue trimestrielle — les plugins évoluent, les noms d'acteurs changent, certaines formulations perdent en efficacité.

Former l'équipe. Le principal frein observé n'est pas technique : c'est l'ignorance de l'existence des promptbooks disponibles. Publiez un catalogue interne accessible depuis la procédure d'astreinte, avec pour chaque entrée le cas d'usage, les plugins requis et le temps d'exécution moyen. Et surveillez la consommation : un promptbook de sept prompts consomme mécaniquement plus de SCU qu'une question isolée. Mesurez le coût par investigation avant de généraliser l'usage à l'ensemble du SOC.

Questions fréquentes sur les promptbooks

Quelle est la différence entre un promptbook et un agent Security Copilot ?

Un promptbook est une séquence de prompts déclenchée manuellement par un analyste, avec une entrée qu'il fournit au lancement. Un agent s'exécute de façon autonome et déclenchée par événement, sans intervention humaine à chaque cycle. Le promptbook reste sous contrôle de l'analyste et convient aux investigations à la demande ; l'agent convient aux tâches continues comme le tri d'alertes de phishing. Les deux se complètent : un agent peut préparer le terrain qu'un promptbook approfondira.

Les promptbooks consomment-ils plus de SCU que des prompts isolés ?

Oui, mécaniquement : un promptbook de sept invites consomme davantage qu'une invite unique. Mais la comparaison pertinente n'est pas prompt contre promptbook, elle est promptbook contre la séquence complète de prompts que l'analyste aurait saisie manuellement. Sur ce plan, le promptbook est généralement plus économe car il évite les reformulations et les prompts de rattrapage. Mesurez votre consommation réelle sur un mois avant de dimensionner votre capacité provisionnée.

Peut-on partager un promptbook personnalisé avec toute l'organisation ?

Oui. Au moment de l'enregistrement, vous choisissez le périmètre de partage : usage privé, partage avec l'organisation, ou diffusion restreinte. Un promptbook partagé devient visible dans la bibliothèque de tous les utilisateurs habilités du tenant. Attention toutefois : le partage transmet la séquence de prompts, pas les droits. Un analyste sans accès au plugin Intune obtiendra des réponses vides sur les étapes concernées.

Que se passe-t-il si un plugin requis n'est pas activé ?

Le promptbook s'exécute quand même, mais les invites dépendant du plugin manquant retournent une réponse incomplète ou une indication d'absence de données. Le risque réel est l'interprétation : une réponse vide sur l'état de conformité d'un appareil peut être lue à tort comme « aucun problème ». Vérifiez toujours la liste des plugins activés avant de lancer un promptbook multi-sources comme les investigations Sentinel ou Defender XDR.

Comment adapter un promptbook communautaire à son environnement ?

Commencez par exécuter la séquence originale sur un cas connu dont vous maîtrisez déjà les conclusions : vous mesurez ainsi l'écart entre la sortie attendue et la sortie réelle. Adaptez ensuite les fenêtres temporelles à votre volumétrie, remplacez les noms de tables si votre schéma diffère, et ajoutez vos exclusions organisationnelles. Renommez enfin le promptbook selon votre convention interne avec un numéro de version, et documentez la source d'origine.

``` Points à connaître avant publication : - **Longueur** : ~4 000 mots (estimation — le `Write` ayant été refusé, je n'ai pas pu faire le comptage exact par script). Au-dessus du plancher de 3 500. - **Vérification source** : j'ai consulté la page Microsoft Learn imposée. Elle ne documente **aucun format YAML** d'export/import de promptbook — uniquement le parcours UI. La section « créer son propre promptbook » présente donc le YAML explicitement comme convention interne de versionnage Git, pas comme un schéma officiel. Ne le requalifiez pas en « format Microsoft ». - **Ratio H2/mots** : la structure imposée compte 6 H2 pour ~4 000 mots, dont un H2 « Les 10 promptbooks » qui pèse à lui seul ~2 300 mots. Le contrôle SEO ≤350 mots/H2 échouera. Je n'ai pas ajouté de H2 hors structure ; à arbitrer si le score compte plus que la structure demandée. - **Liens** : 6 internes (4 imposés + `/audit-infrastructure` + `/contact`), 2 externes. Conforme. - **Publication** : rien n'a été inséré en base ni déployé — vous ne l'aviez pas demandé. Dites-moi la catégorie et le slug cible si vous voulez que je l'intègre en PROD.