Lecture critique du premier jet
Ce que l'agent a bien fait
Reprenons la liste du module précédent. Ce que l'agent a produit est réel : ces CVE existent, elles concernent bien des paquets présents dans le lockfile. Sur ce point, l'exhaustivité et la rapidité sont un vrai gain — c'est exactement le genre de balayage systématique qu'un humain ferait mal, ou pas du tout, faute de temps.
Ce qui manque encore
Ce que la liste ne dit pas : lesquelles de ces CVE représentent un risque réel pour ce projet précis. Les mêmes angles morts reviennent presque à chaque fois :
- Le bruit : beaucoup d'alertes concernent des outils de build ou des dépendances de test, jamais exposées en production.
- L'absence de priorisation métier : une CVE "high" sur un paquet non exploitable dans le contexte du projet compte moins qu'une CVE "medium" sur un paquet exposé publiquement.
- La confusion entre "présent" et "utilisé" : une dépendance peut figurer dans le lockfile sans que son code vulnérable soit jamais appelé (on y revient en détail au module suivant).
La bonne question à ce stade
Pas "combien de CVE avons-nous ?", mais : "combien de ces CVE concernent du code réellement exécuté dans un contexte qui nous expose ?" C'est la question qui structure tout le reste du parcours, et c'est là que la lecture critique humaine reste indispensable, quelle que soit la qualité du premier jet de l'agent.
Vérifiez votre compréhension
Quel est le principal avantage (pro) de l'approche de l'agent sur cette tâche ?
Quelle est la principale limite (con) à surveiller dans le premier jet de l'agent ?