Cadrer la mission

Périmètre : quoi scanner, et jusqu'où

Un brief flou produit un résultat flou. Avant de lancer l'agent, il faut trancher :

• Quelles dépendances : uniquement les dépendances de production, ou aussi celles de développement/build ? Le niveau de risque n'est pas le même selon qu'un paquet vulnérable tourne réellement en production ou sert uniquement à compiler le projet.
• Quelle profondeur : dépendances directes seulement, ou aussi transitives ? La plupart des vulnérabilités réelles se cachent dans les dépendances transitives, plusieurs niveaux en dessous de ce qu'on a explicitement ajouté.
• Quel dépôt, quelle branche : la main en production, une branche de dev, un monorepo entier ?

Critères de succès explicites

Le brief doit dire précisément ce que l'agent doit produire en sortie : une liste de CVE avec leur sévérité, un verdict d'exposition réelle pour chacune (module 6), et une proposition de correctif (module 7) — pas juste "regarde s'il y a des problèmes".

Interdictions explicites

C'est la partie qu'on oublie le plus souvent d'écrire, et c'est la plus importante :

• Pas de commit ni de push direct.
• Pas de modification de code sans validation humaine.
• Pas d'exécution automatique d'un correctif (upgrade de version, patch) sans revue.

Exemple de brief

Mission : scanner les dépendances de production du dépôt (pnpm-lock.yaml).
Sortie attendue : liste des CVE ouvertes, triées par sévérité, avec verdict
d'exposition réelle pour chacune, et proposition de correctif.
Interdictions : aucun commit, aucune modification de version sans validation.

Ce brief tient en quatre lignes. C'est suffisant — et c'est déjà beaucoup plus que ce que la plupart des équipes écrivent avant de lancer un agent.