Le slopsquatting est une attaque qui exploite une erreur fréquente des assistants de code IA : ils recommandent parfois d'installer une bibliothèque qui n'existe pas. Un attaquant qui repère ce nom inventé peut publier un paquet malveillant sous ce nom. Le prochain développeur, ou le prochain agent IA, qui suit la suggestion installe alors le code de l'attaquant dans votre application.
Le risque est documenté par la recherche. Une étude publiée à la conférence USENIX Security 2025 a analysé 576 000 extraits de code produits par 16 modèles et relevé plus de 200 000 noms de paquets inventés différents (Spracklen et al.).
Vous n'avez pas besoin de comprendre le code pour vous protéger. Il suffit de savoir quelles questions poser et quels contrôles exiger. C'est l'objet de cet article.
Le slopsquatting, expliqué sans jargon
Une application moderne n'est presque jamais écrite entièrement à la main. Elle s'appuie sur des dizaines, parfois des centaines de paquets (aussi appelés bibliothèques ou dépendances) : des briques de code publiées par d'autres, pour gérer les paiements, envoyer des e-mails, générer des PDF... Ces paquets sont téléchargés depuis des registres publics : Packagist pour PHP et Laravel, npm pour JavaScript, PyPI pour Python.
N'importe qui peut publier un paquet sur ces registres, sous n'importe quel nom encore libre. C'est ce qui rend l'attaque possible :
- un assistant IA, en écrivant du code, invente un nom de paquet plausible mais inexistant ;
- un attaquant repère ce nom, par exemple en posant lui-même des questions similaires aux modèles, et publie un paquet piégé sous ce nom ;
- un développeur ou un agent IA suit la suggestion, installe le paquet, et le code malveillant s'exécute dans votre application ou sur la machine du développeur.
Le terme, contraction de slop (la production bâclée de l'IA) et de typosquatting (enregistrer des noms proches de paquets connus), est décrit dans un article Wikipédia dédié.
Ce que dit la recherche sur les paquets inventés par l'IA
L'étude de référence s'intitule We Have a Package for You!. Ses auteurs ont fait générer du code en Python et JavaScript à 16 modèles et vérifié si les paquets cités existaient. D'après le résumé de l'article :
- la part moyenne de paquets inventés était d'au moins 5,2 % pour les modèles commerciaux et de 21,7 % pour les modèles open source ;
- 205 474 noms de paquets inventés uniques ont été relevés ;
- les auteurs décrivent le phénomène comme persistant et systémique, tout en indiquant que certaines mesures le réduisent nettement.
Ces taux portent sur les modèles testés à l'époque de l'étude. Les modèles plus récents peuvent faire mieux ou différemment, mais rien n'indique que le problème ait disparu.
Le risque n'est pas que théorique. Le chercheur Bar Lanyado (Lasso Security) avait remarqué que des modèles recommandaient d'installer un paquet Python nommé huggingface-cli, qui n'existait pas sous ce nom. Il a publié un paquet vide sous ce nom pour mesurer l'effet : d'après son compte rendu, il a reçu plus de 30 000 téléchargements authentiques en trois mois. Le paquet était inoffensif ; un attaquant aurait pu y mettre n'importe quoi.
Votre application est-elle exposée ?
Le risque augmente avec la façon dont l'IA est utilisée sur votre projet. Vous êtes plus exposé si :
- un agent IA (Claude Code, Cursor, Replit, Lovable...) peut installer des paquets lui-même, sans validation humaine ;
- personne ne relit la liste des dépendances ajoutées lors des dernières modifications ;
- les versions des paquets ne sont pas figées, si bien que chaque nouvelle installation peut récupérer autre chose que la précédente ;
- l'application a été construite rapidement en vibe coding et n'a jamais été auditée.
À l'inverse, une application où chaque nouvelle dépendance est relue et où les versions sont verrouillées est beaucoup moins exposée, même si le code est en grande partie écrit avec l'IA.
Le slopsquatting fait partie d'un ensemble plus large de risques propres au code généré. Pour avoir une vue d'ensemble, voyez notre article sur la dette technique du code généré par IA.
Les contrôles à mettre en place
Aucun de ces contrôles n'est compliqué. Le plus important est qu'ils soient systématiques, et pas laissés à la bonne volonté de chacun.
Verrouiller les versions
Les gestionnaires de paquets produisent un fichier de verrouillage (composer.lock pour PHP, package-lock.json pour npm) qui enregistre la version exacte de chaque dépendance installée. Ce fichier doit être versionné avec le code et utilisé lors des déploiements. Ainsi, la production installe exactement ce qui a été testé.
Vérifier chaque nouvelle dépendance
Quand une modification ajoute un paquet, quelqu'un doit vérifier qu'il existe vraiment, qu'il s'agit bien de celui attendu, qu'il est maintenu et utilisé ailleurs. Un paquet très récent, peu téléchargé, avec un nom proche d'une bibliothèque connue, mérite une vraie vérification.
Automatiser les contrôles dans la chaîne de déploiement
La chaîne d'intégration continue (CI, l'ensemble des vérifications automatiques lancées à chaque modification) peut signaler tout ajout de dépendance et lancer les outils d'audit comme composer audit ou npm audit. Attention : ces outils détectent surtout les vulnérabilités déjà connues et répertoriées. Un paquet malveillant tout juste publié peut passer entre les mailles du filet. C'est pourquoi la relecture des nouvelles dépendances reste nécessaire.
Encadrer ce que l'agent IA peut installer
Si un agent IA travaille sur votre code, configurez-le pour qu'il demande une confirmation avant d'installer un paquet. Et faites-le travailler dans un environnement qui ne contient pas les secrets de production : si un paquet piégé s'exécute sur ce poste, il ne trouvera rien d'intéressant. Si des secrets ont pu être exposés, notre article sur la clé API exposée explique quoi faire.
Ce que vous pouvez exiger de votre développeur
Sans être technique, vous pouvez poser ces questions à votre prestataire ou à votre équipe :
- « Le fichier de verrouillage des dépendances est-il versionné et utilisé en production ? »
- « Qui valide l'ajout d'un nouveau paquet, et comment ? »
- « L'agent IA peut-il installer des paquets sans confirmation ? »
- « Un contrôle automatique des dépendances tourne-t-il à chaque modification ? Que se passe-t-il s'il signale un problème ? »
- « Avez-vous la liste des dépendances ajoutées ces trois derniers mois ? »
Des réponses précises et rapides sont bon signe. Des réponses vagues indiquent que personne ne surveille vraiment ce qui entre dans votre application.
Questions fréquentes
Le slopsquatting concerne-t-il les applications Laravel ?
Le mécanisme vaut pour tout registre public où n'importe qui peut publier : Packagist pour PHP, npm pour la partie JavaScript d'une application Laravel. L'étude citée a porté sur Python et JavaScript, mais le principe ne dépend pas du langage.
Un antivirus ou un outil d'audit suffit-il ?
Non. Les outils d'audit repèrent les failles déjà répertoriées. Un paquet malveillant récent peut ne pas encore y figurer. La relecture humaine des nouvelles dépendances reste le contrôle principal.
Faut-il arrêter d'utiliser l'IA pour coder ?
Non. Il faut contrôler ce qu'elle ajoute à votre application, comme on le ferait pour le travail d'un développeur junior.
Verrouillage des versions, contrôles automatiques à chaque modification, relecture par des agents IA de contrôle qualité : c'est ce que couvre le socle technique Autopilote, avec l'hébergement, les sauvegardes et le monitoring. Si vous voulez savoir où en est votre application sur ce point, écrivez-moi : on peut regarder ensemble la liste de vos dépendances.