Votre prochaine faille de sécurité ne viendra peut-être pas d’une dépendance npm douteuse, mais d’un prompt mal ficelé. Les agents IA, les prompts et les outils MCP (Model Context Protocol) participent désormais à la fabrication du logiciel. Résultat : la traçabilité ne peut plus se limiter aux paquets et au code généré. Il faut suivre à la trace ce qui a produit ce code, et avec quelles instructions.
Points clés
- Les agents IA, prompts et outils MCP deviennent des maillons de la chaîne d’approvisionnement logicielle.
- La provenance ne se limite plus aux dépendances : il faut tracer modèles, prompts et outils.
- Le SBOM classique ne couvre plus le code écrit par l’IA.
La supply chain logicielle déborde du cadre
Pendant des années, sécuriser la chaîne d’approvisionnement logicielle revenait à surveiller les dépendances, vérifier les signatures et tenir un inventaire des composants (le fameux SBOM). Le périmètre était clair. L’arrivée d’agents IA capables d’écrire, de modifier et d’assembler du code fait voler ce cadre en éclats.
Désormais, un build peut intégrer du code qu’aucun humain n’a tapé, généré à partir d’un prompt qu’il faudrait pouvoir retracer, via des outils MCP qui connectent les modèles à des sources de données et à des actions externes. Autant de nouveaux maillons, autant de nouveaux points d’entrée pour les ennuis.
La provenance devient le vrai chantier
La question centrale n’est plus seulement « d’où vient ce paquet ? » mais « quel modèle, quel prompt et quel outil ont produit cette portion de code ? ». Sans réponse, impossible d’auditer sérieusement un incident ou de reproduire un build à l’identique.
Les équipes qui prennent le sujet au sérieux devront tracer la provenance au-delà des paquets, en documentant les prompts, les versions de modèles et les outils MCP mobilisés. Le SBOM ne suffit plus : il faudra y ajouter la mémoire de ce que l’IA a fabriqué, et comment.
La promesse de productivité de l’IA a un revers rarement affiché sur la brochure marketing : chaque ligne générée sans traçabilité est une dette de sécurité en sursis. Documenter le rôle de la machine n’est plus une coquetterie de puriste, c’est la condition pour garder la main sur son propre code.
