Le vibe coding s’arrête à « ça marche ». Vous décrivez ce que vous voulez, l’IA l’écrit, l’app démarre, la démo a l’air correcte. Personne ne demande ce qui est venu avec.
Ce qui est venu avec, c’est généralement quelques centaines de paquets. Chaque npm install ou pip install suggéré par l’assistant télécharge du code écrit par des inconnus et l’exécute avec vos permissions : sur votre portable, dans votre chaîne de build, sur votre serveur. Pendant des années, c’était un pari raisonnable. Depuis douze mois, c’est devenu la façon préférée d’entrer dans une entreprise.
Comment une app d’une page finit avec 800 dépendances
Un assistant IA résout les problèmes comme le fait la moyenne de ses données d’entraînement, et la moyenne des projets JavaScript ou Python prend un paquet pour tout : les dates, les couleurs dans le terminal, les appels HTTP, la lecture d’un fichier de configuration. Chacun de ces paquets dépend d’autres paquets, qui dépendent d’autres encore. Une app web modeste en installe couramment plusieurs centaines. Personne dans l’équipe n’en a lu un seul.
Pire : beaucoup de paquets exécutent du code dès leur installation, avant même que votre app démarre : les scripts preinstall et postinstall de npm, les hooks de build et les fichiers .pth en Python. Installer, c’est exécuter. Si un seul de ces centaines de paquets est empoisonné, l’attaquant est déjà à l’intérieur et lit votre fichier .env, vos clés infonuagiques et vos clés SSH.
Les faits
Ce ne sont pas des paquets obscurs avec une faute de frappe dans le nom. Ce sont parmi les bibliothèques les plus téléchargées au monde, détournées via leurs mainteneurs ou leur chaîne de publication :
| Quand | Paquet | Ce qui s'est passé | Portée |
|---|---|---|---|
| Mai 2026 | TanStack, Mistral AI, UiPath (npm, PyPI) | « Mini Shai-Hulud » : une chaîne de build compromise a publié des versions malveillantes signées, avec attestation de provenance, qui volent les identifiants et se republient d’elles-mêmes | 169 paquets npm et 2 paquets PyPI |
| Mars 2026 | Axios (npm) | Le compte du mainteneur principal a été pris ; deux versions installaient un cheval de Troie d’accès à distance sur macOS, Windows et Linux | Plus de 100 millions de téléchargements par semaine |
| Mars 2026 | LiteLLM (PyPI) | Des versions malveillantes récoltaient les identifiants AWS, GCP, Azure et Kubernetes ; l’une s’exécutait à chaque démarrage de Python, même sans import | Environ 3,4 millions de téléchargements par jour, en ligne trois heures |
| Novembre 2025 | Shai-Hulud 2.0 (npm) | Un ver autoréplicant : il vole les jetons de la victime, puis se publie dans chaque paquet qu’elle maintient | Plus de 700 paquets, plus de 25 000 dépôts |
| Septembre 2025 | chalk, debug (npm) | Un mainteneur a mordu à un faux courriel « réinitialisez votre 2FA » ; 18 paquets de base ont distribué du code qui détournait les transactions de portefeuilles crypto | 2,6 milliards de téléchargements par semaine |
| Août 2025 | Nx "s1ngularity" (npm) | Le maliciel demandait aux propres assistants de code IA des victimes, lancés sans garde-fous, de fouiller le disque à la recherche de secrets | 2 180 comptes, 7 200 dépôts exposés |
Deux détails ressortent. D’abord la vitesse : les versions piégées d’Axios et de LiteLLM ont été retirées en trois heures environ, et ça n’a rien changé, parce que les pipelines automatisés et les développeurs pressés les avaient installées en quelques minutes. Ensuite, l’attaque Nx n’a pas apporté ses propres outils. Elle a utilisé l’assistant IA déjà installé sur la machine du développeur, avec les permissions que celui-ci lui avait données. C’est l’installation typique du vibe coding, retournée contre lui.
Slopsquatting : quand l’IA invente le paquet
Il existe un truc plus récent, qui n’existe qu’à cause du code écrit par IA. Les modèles de langage recommandent parfois des paquets qui n’existent pas : un nom plausible, importé avec assurance. Une étude présentée à USENIX Security 2025 sur 576 000 extraits de code produits par 16 modèles a montré que près de 20 % des paquets suggérés étaient inventés, et que les mêmes noms inventés reviennent encore et encore.
C’est cette répétition qui rend la chose exploitable. Un attaquant pose aux modèles les mêmes questions que vous, récolte les noms qu’ils inventent et les enregistre sur npm ou PyPI avec une charge malveillante. La prochaine fois qu’un assistant suggère ce nom et que quelqu’un lance l’installation, le paquet existe — et c’est celui de l’attaquant. Le milieu de la sécurité appelle ça le slopsquatting. La victime n’a pas besoin de faire une faute de frappe : l’IA la fait pour elle.
Pourquoi le vibe coding aggrave les choses
Aucune de ces attaques ne vise spécialement les adeptes du vibe coding. Elles n’en ont pas besoin. Les habitudes qui rendent le vibe coding rapide sont les mêmes qui transforment une version empoisonnée en brèche :
- Rien n’est figé. Les versions suivent « latest », les fichiers de verrouillage manquent ou sont régénérés à chaque fois, et une version publiée il y a dix minutes entre directement dans le build.
- Personne ne lit le diff. Quand l’app marche, la nouvelle dépendance ajoutée par l’assistant est acceptée avec tout le reste.
- L’agent installe tout seul. Les agents de code lancent eux-mêmes
npm installetpip install, souvent avec les confirmations désactivées pour sauver des clics. - Les secrets sont à côté du code. Mots de passe de la base de production, clés infonuagiques et jetons d’API vivent dans le même dossier que les scripts d’installation peuvent lire.
- Personne n’est responsable du résultat. Si personne ne comprend le code, personne ne remarque qu’une dépendance change de comportement.
Pour être juste envers les outils : le développement assisté par IA, entre des mains expérimentées, c’est ma façon de travailler tous les jours, et c’est excellent. Le problème n’est pas le modèle. C’est du code que personne de qualifié n’a relu, livré par quelqu’un qui ne sait pas distinguer une dépendance normale d’une dépendance suspecte.
Quoi faire
Vous ne pouvez pas vérifier chaque ligne de chaque paquet. Vous pouvez devenir une cible beaucoup plus difficile :
- Moins de dépendances. Une fonction de dix lignes qui vous appartient vaut mieux qu’un paquet dont vous n’avez jamais entendu parler. Demandez pourquoi chaque dépendance est là ; retirez celles qui ne méritent pas leur place.
- Figez et verrouillez. Versionnez le fichier de verrouillage, installez avec
npm ciou des requirements avec empreintes, et mettez à jour volontairement, pas par accident. - Attendez avant de mettre à jour. La plupart des versions empoisonnées sont repérées en quelques heures. Un délai de quelques jours avant d’adopter une nouvelle version (
minimumReleaseAgede pnpm,exclude-newerde uv) en évite la majorité. - Désactivez les scripts d’installation quand c’est possible (
--ignore-scripts), et ne les permettez que pour les rares paquets qui en ont vraiment besoin. - Vérifiez avant d’installer. Le paquet existe-t-il, qui le publie, depuis quand, combien de gens l’utilisent ? Un nom suggéré par l’IA n’est pas une recommandation.
- Gardez les secrets de production hors des postes de développement et des tâches CI qui n’en ont pas besoin. Ce qu’un script d’installation ne peut pas lire, il ne peut pas le voler.
- Un humain qui comprend le code donne son accord. À chaque changement, pour chaque nouvelle dépendance. C’est la partie que l’IA ne peut pas faire à votre place.
Construit vite, oui. Construit à l’aveugle, non.
Je ne plaide pas contre le logiciel écrit par IA ; je bâtis des apps sur mesure avec, et elles coûtent moins cher et sont mieux testées que ce que j’écrivais il y a cinq ans. Je plaide pour que la vitesse vienne avec quelqu’un qui sait ce qui entre dans le build, garde les dépendances peu nombreuses et à jour, et surveille les alertes quand le prochain Shai-Hulud frappe.
Si votre entreprise fait déjà tourner une app vibe-codée — un outil interne, un portail client, un prototype devenu discrètement la production — ça vaut une heure pour savoir ce qu’elle installe et ce qu’elle pourrait laisser fuir. Ça coûte bien moins cher que de l’apprendre de l’attaquant.