# Ton agent IA a installé des dizaines de paquets que tu n'as jamais choisis. Faut-il s'en inquiéter ?
Mik Bry · 2026-08-25 · lecture ~9 min · KB · Prêt à lancer
Quand ton outil d'IA ajoute une connexion, un export PDF ou un paiement, il ne réécrit généralement pas tout depuis zéro. Il s'appuie sur des paquets déjà publiés par d'autres développeurs. Ce sont des dépendances. Ça peut vite représenter des dizaines de paquets directs, et bien plus de transitifs.
Cela, en soi, n'a rien d'inhabituel — la plupart des applications modernes reposent largement sur des paquets tiers, qu'elles soient développées par un humain ou avec un agent IA. Un développeur peut s'arrêter pour regarder qui maintient un paquet, s'il est encore actif ou largement utilisé. Avec un agent, ce choix peut se faire au fil de la tâche sans qu'il y ait de revue explicite. C'est ce que veut dire « non revu » ici : pas que le code soit mauvais, mais que personne n'a jamais tranché la question.
Ce que couvre cet article
1. [C'est quoi, concrètement ?](#s1)
2. [Pourquoi s'en soucier si tu ne codes pas ?](#s2)
3. [À quoi ressemble un projet bien structuré ?](#s3)
4. [Que peux-tu demander sans risque à ton agent IA ?](#s4)
01 — C'est quoi, concrètement ?
Imagine les dépendances de ton app comme des ingrédients qu'on achète, pas qu'on cultive. Une cuisine de restaurant ne cultive pas sa propre farine — elle commande à des fournisseurs de confiance, et une bonne cuisine vérifie quand même la livraison avant que ça n'atterrisse dans un plat. Ton app fonctionne pareil : du code que tu n'as pas écrit n'est pas automatiquement du code utilisable sans vérifier.
Il faut distinguer deux niveaux, dont le second reste souvent invisible pour un non-développeur. Les **dépendances directes** sont les paquets que ton agent a explicitement ajoutés. Les **dépendances transitives** sont tout ce dont ces paquets ont besoin à leur tour, installé automatiquement, parfois sur plusieurs niveaux, sans que personne ne l'ait choisi. Vingt dépendances directes peuvent facilement en porter plusieurs centaines de transitives en dessous — invisibles tant que personne n'est allé regarder.
Dans les deux cas, il peut ne jamais y avoir de moment où quelqu'un s'arrête pour vérifier le choix. C'est exactement l'écart dont parle cet article.
02 — Pourquoi s'en soucier si tu ne codes pas ?
Parce que c'est une catégorie reconnue de défaillance réelle, pas une préoccupation marginale. L'[édition 2025 de l'OWASP Top 10](https://owasp.org/Top10/) — la liste la plus partagée des façons dont les applications se font compromettre — a renommé et élargi une catégorie de 2021 (« Composants vulnérables et obsolètes »). **A03:2025 Software Supply Chain Failures fait partie des catégories de l'OWASP Top 10.** Le nom de 2021 ne mérite d'être connu qu'à titre historique.
Source : OWASP Top 10:2025, catégorie A03 — Software Supply Chain Failures, owasp.org/Top10. Citée ici comme le cadre actuel ; A06:2021 Vulnerable and Outdated Components en est le prédécesseur historique, pas une catégorie distincte encore d'actualité.
Il existe aussi un risque propre à l'IA, qui n'existait pas avant que des agents n'écrivent eux-mêmes des commandes d'installation : le **slopsquatting**. Un modèle d'IA suggère parfois avec assurance un nom de paquet qui sonne juste et qui n'existe pas — le nom est plausible, pas réel. Si un attaquant remarque quels noms inventés les modèles suggèrent régulièrement et les enregistre le premier, le prochain agent qui installe ce paquet en croyant bien faire récupère ce que l'attaquant y a mis.
Ce n'est pas hypothétique. En janvier 2026, un chercheur chez Aikido a trouvé un paquet nommé `react-codeshift` — un nom inventé par une IA fusionnant deux paquets réels sans rapport (`jscodeshift` et `react-codemod`), qui n'existait pas encore dans le registre npm. Déjà propagé à 237 dépôts via des instructions pour agents de code générées par IA, copiées sans vérifier si le paquet était réel, il continuait de recevoir de vraies tentatives d'installation même après que le chercheur l'ait enregistré lui-même pour empêcher un attaquant de le faire. Personne n'a rien planté ici — une IA a inventé un nom, d'autres IA ont continué d'essayer de l'installer.
Source : Aikido Security, « Slopsquatting: The AI Package Hallucination Attack Already Happening », aikido.dev/blog.
À noter séparément, pour ne pas confondre les deux : un autre incident de septembre 2025, un ver auto-propageant nommé **Shai-Hulud**, a compromis des centaines de vrais paquets npm en piégeant par phishing les identifiants d'un mainteneur — pas en inventant un nom. Mécanisme différent, même leçon : une dépendance déjà présente dans ton projet peut devenir dangereuse sans qu'aucun nouveau choix explicite ne soit fait.
Source : Unit 42 (Palo Alto Networks), « "Shai-Hulud" Worm Compromises npm Ecosystem in Supply Chain Attack », unit42.paloaltonetworks.com/fr.
03 — À quoi ressemble un projet bien structuré ?
Pas besoin de lire du code pour vérifier l'essentiel. Cherche :
- **Des dépendances directes que tu peux nommer** — pas « demande à l'agent, il sait », mais une liste qui existe quelque part.
- **Un lockfile commité avec le code** — `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock` ou l'équivalent — enregistre les versions résolues des dépendances, ce qui rend les installations beaucoup plus reproductibles d'une machine ou d'un déploiement à l'autre.
- **Une idée, même approximative, de l'état de chaque dépendance directe** — qui la maintient et quand elle a été mise à jour pour la dernière fois. Les ingrédients vieillissent comme du lait, pas comme du sel : un paquet délaissé depuis des années n'est pas automatiquement cassé, mais il ne reçoit pas non plus de correctif si un problème y est découvert.
- **Le cadre OWASP A03:2025 en tête, pas comme du jargon** — « politique de dépendances floue » n'est pas un constat pointilleux. Ça nomme une catégorie de l'OWASP Top 10, pas un détail.
Sources : npm Docs — package-locks, sur ce qu'un lockfile fige réellement ; Snyk — gérer les dépendances open source, sur le fait de traiter les dépendances comme une responsabilité continue plutôt qu'un choix ponctuel.
Rien de tout ça ne demande de revoir chaque paquet à la main. Ça demande de savoir que la liste existe, et de poser ces deux ou trois questions — exactement ce que fait le prompt ci-dessous.
04 — Que peux-tu demander sans risque à ton agent IA ?
Tu n'as besoin de vérifier aucun de ces points toi-même. Demande à ton outil d'IA de le faire pour toi — et ne le laisse pas deviner. Une recherche qui ne peut rien vérifier n'affirme pas la même chose qu'un paquet confirmé sain ; si ton agent ne peut pas vérifier un paquet à partir de données fiables du registre, la réponse honnête est « je n'ai pas pu le vérifier », pas une supposition déguisée. Copie-colle ce prompt tel quel :
Le prompt à coller dans ton outil d'IA
> Liste les dépendances directes de ce projet. Pour chacune, montre toute alerte de sécurité connue et la date de dernière publication que tu peux vérifier à partir des données de gestionnaire de paquets ou de registre disponibles, et cite la source. Si tu ne peux pas vérifier quelque chose, dis-le — ne devine pas. Ne mets rien à jour.
Lis la réponse avant d'agir dessus. Une liste de dépendances nommées, chacune avec une date de dernière publication vérifiable et un « aucune alerte trouvée » ou « impossible à vérifier » clair, ça correspond aux signaux recherchés dans la section 3. Un résumé vague, ou un agent qui met discrètement quelque chose à jour pendant qu'il « vérifie juste », c'est ton vrai point de départ — à comprendre avant de construire une semaine de plus dessus.
Cet article fait partie de la série Launch Readiness KB : un concept à la fois pour comprendre ce que le Trust Report vérifie avant de lancer ton app, d'embaucher ou de lever des fonds. Chaque article se termine par quelque chose que tu peux demander à ton agent sans modifier le code.