Les modèles de code hallucinent de façon prévisible des noms de paquets inexistants (19,7 % du code, et 43 % des noms se répètent), ce qui permet à un attaquant de les enregistrer d'abord avec une charge malveillante. La défense : vérifier que tout paquet suggéré par l'IA existe et est légitime avant de l'installer.
Imaginez que vous demandiez à un assistant de vous rapporter une vis d'une quincaillerie, et qu'au lieu d'admettre qu'il ne sait pas laquelle, il invente le nom d'une marque au son parfaitement plausible : « Vis Kraften M8 ». Confiant, vous allez la demander. Et il se trouve que quelqu'un, anticipant précisément cette invention, a déjà ouvert une boutique sous ce nom et rempli la boîte d'explosifs. Transposé au logiciel, cela a un nom depuis 2025 : slopsquatting. Votre IA invente une librairie qui n'existe pas, et un attaquant l'enregistre avant vous pour y glisser du code malveillant. C'est le vecteur d'attaque de chaîne d'approvisionnement le plus élégant et silencieux qu'ait apporté l'ère de la programmation assistée, et presque personne dans votre équipe ne sait qu'il existe.
L'hallucination a cessé d'être une blague pour devenir une surface d'attaque
Pendant des années, nous avons traité les hallucinations de l'IA comme une anecdote amusante : le modèle invente une citation, une donnée, une date. Agaçant, mais inoffensif. Avec le code, l'hallucination change de nature. Quand un modèle écrit `import requestz` au lieu de `requests`, ou invente un `pandas-utils-pro` qui n'a jamais existé, il ne lâche pas une blague : il signe un chèque qu'un autre pourra encaisser. Car contrairement à une fausse citation, un nom de paquet est une adresse. Et les adresses peuvent être occupées. Le jour où l'hallucination a eu une adresse postale enregistrable sur npm ou PyPI, elle a cessé d'être une erreur de style pour devenir une porte.
Le chiffre brut : près d'1 fragment de code sur 5 suggérait un paquet fantôme
Une étude présentée à USENIX Security 2025 l'a mesuré à l'échelle industrielle : 2,23 millions d'échantillons de code générés par 16 modèles différents. Le résultat est celui que vous devriez avoir collé sur votre écran : 19,7 % des échantillons incluaient au moins un paquet halluciné — un paquet qui n'existe tout simplement pas. Et le biais selon la famille de modèle est brutal : les modèles open-source ont inventé des paquets 21,7 % du temps, contre 5,2 % pour les modèles commerciaux. Traduction : près d'une fois sur cinq où un modèle vous tend la main avec une dépendance, il vous en tend une qui n'existe pas. Multipliez-le par les millions de `pip install` et `npm install` exécutés chaque jour dans la foi aveugle du « si c'est l'IA qui l'a écrit, ça existe », et vous obtenez la surface d'attaque.
Ce qui est vraiment dangereux, ce n'est pas qu'il invente : c'est qu'il invente TOUJOURS LA MÊME CHOSE
Si les hallucinations étaient du bruit aléatoire, l'attaque serait inviable : un attaquant devrait enregistrer des millions de noms au hasard pour en toucher un. Le constat qui transforme cela en problème réel est autre : 43 % des noms hallucinés réapparaissent à chaque exécution. Ce n'est pas du bruit, c'est une signature. Le modèle, face au même prompt, tend à inventer le même nom faux encore et encore. C'est de l'or pour l'attaquant : il lui suffit d'observer ce qu'invente le modèle, de garder les noms qui se répètent, de les enregistrer avec une charge malveillante, et d'attendre. Il n'a besoin de rien pirater. C'est vous qui lui avez tendu le piège, et votre propre agent l'installe avec les permissions de votre build. Seth Larson, de la Python Software Foundation, a baptisé le schéma : slopsquatting — le cousin du typosquatting, mais où l'erreur n'est pas commise par votre doigt, elle l'est par votre modèle.
Pourquoi la programmation par agents multiplie le risque au lieu de le contenir
Un développeur humain qui voit `import fastapi-turbo` dans une suggestion hausse en général un sourcil : « ça existe, ça ? ». Un agent autonome ne hausse pas de sourcil. Vous lui avez dit « fais que ça marche », il bute sur un import qui échoue, et son réflexe entraîné est de résoudre : il exécute le `install`, et si le paquet existe (parce que l'attaquant l'a enregistré), il l'installe sans friction et poursuit. La boucle qui rend la programmation agentique magique — essayer, échouer, corriger, continuer — est exactement celle qui saute la seule barrière qui nous protégeait : le doute humain. Plus l'agent est autonome, moins il y a d'yeux entre l'hallucination et le `install`. L'autonomie sans vérification n'est pas de la vitesse, c'est de la vitesse vers le précipice, phares éteints.
La leçon : à l'ère de l'IA, la confiance en un nom est une décision de sécurité
Le cadre mental que vous pouvez emporter et partager est celui-ci : un nom de paquet suggéré par une IA n'est pas un fait, c'est une hypothèse. Et toute hypothèse qui va exécuter du code avec les permissions de votre build mérite d'être vérifiée avant, pas après. L'action concrète tient en une phrase : avant d'installer toute dépendance suggérée par un modèle, confirmez que le paquet existe vraiment, que c'est bien celui que vous croyez, et qu'il n'est pas né la semaine dernière avec zéro historique. Un lockfile avec des hashes figés, une allowlist de dépendances, et un coup d'œil de deux secondes à « ce paquet a-t-il des années et des téléchargements, ou est-il apparu mardi ? » désactivent complètement cette attaque. Pas besoin d'un pare-feu d'IA : il faut cesser de traiter la sortie du modèle comme parole sacrée. La même discipline, d'ailleurs, qui sépare une démo d'un produit — on en parle dans la mathématique des 27 %.
Comment nous le voyons
Chez NeuralOS, nous partons d'un axiome inconfortable : l'IA est un collaborateur brillant et un menteur occasionnel, et il faut concevoir pour les deux à la fois. C'est pourquoi nous pensons la sécurité non comme une couche qu'on colle à la fin, mais comme le sol sur lequel on construit. Certaines pièces de ce sol sont déjà tangibles : les secrets sont expurgés par valeur dans chaque log, et les identifiants vivent dans un Vault chiffré par-tenant qui n'est jamais exposé au modèle. D'autres sont une direction déclarée, pas une promesse tenue : dans la même veine, nous avons créé et offert Sentinel, un gardien de sécurité de code open source qui attrape le bug avant qu'il n'atteigne la production. Nous ne pouvons pas empêcher un modèle d'halluciner un nom — personne ne le peut, c'est la physique du système. Ce que nous poursuivons, en revanche, pièce par pièce et avec honnêteté sur ce qui existe déjà et sur ce qui reste du chemin, c'est de creuser le fossé entre cette hallucination et votre build : que le doute que l'agent n'a plus, la plateforme l'ait pour vous. Parce qu'à l'ère de construire avec l'IA sans être programmeur, votre avantage n'est pas de faire confiance plus vite : c'est que la vérification ne dépende pas seulement de votre bonne foi.