Faux paquets générés par les LLM : le risque caché du vibe coding

Un assistant d’IA peut produire en quelques secondes une fonction, un script ou l’ébauche d’une application. Mais lorsqu’il recommande une bibliothèque à installer, sa réponse ne doit jamais être considérée comme une preuve que cette bibliothèque existe, ni qu’elle est sûre. En avril 2025, la question des « faux paquets » s’impose comme un risque concret pour les développeurs qui utilisent les grands modèles de langage, ou LLM, pour écrire du code.

Le problème ne tient pas uniquement à une ligne erronée qui ferait échouer un programme. Un modèle peut inventer le nom crédible d’un module Python ou d’un paquet JavaScript, puis expliquer avec assurance comment l’utiliser. Si ce nom est ensuite publié dans un registre par une personne malveillante, le développeur qui suit aveuglément la recommandation peut installer un composant contenant du code indésirable. C’est un risque pour toute la chaîne d’approvisionnement logicielle, c’est-à-dire l’ensemble des outils et dépendances qui composent une application.

Quand un LLM invente une dépendance

Les LLM sont entraînés à prédire la suite la plus vraisemblable d’un texte ou d’un morceau de code. Ils n’interrogent pas nécessairement, au moment de répondre, un catalogue à jour des bibliothèques disponibles. Ils peuvent donc associer des mots courants, reprendre des structures de noms fréquentes ou extrapoler à partir de fonctions existantes. Le résultat paraît cohérent, mais le paquet recommandé peut être introuvable.

Ce comportement relève des hallucinations des modèles : des informations formulées de façon plausible, mais fausses. Dans le code, elles peuvent prendre plusieurs formes : une fonction qui n’existe pas, une option de commande incorrecte, une API imaginaire ou une dépendance inventée. Le terme anglais gibberish, parfois employé dans les discussions techniques, désigne cette production qui semble avoir du sens sans être exploitable telle quelle.

Les écosystèmes dotés de gestionnaires de paquets sont particulièrement concernés. Dans l’univers JavaScript, npm télécharge les modules demandés par un projet Node.js. Côté Python, PyPI centralise une grande partie des paquets distribués publiquement. Ces outils sont essentiels au développement moderne : plutôt que de réécrire une fonction de chiffrement, de traitement de données ou d’accès à une API, un programmeur peut intégrer une bibliothèque existante.

Cette commodité implique toutefois une règle élémentaire : un nom de paquet n’est pas un simple détail de syntaxe. Il désigne du code tiers qui sera téléchargé, installé et parfois exécuté dans un environnement de développement, de test ou de production.

Comment un faux paquet peut devenir une attaque

Le scénario décrit par les chercheurs est inquiétant parce qu’il ne suppose pas de compromettre directement un assistant d’IA ni de pirater le poste d’un développeur. L’attaquant peut attendre qu’un modèle recommande régulièrement un paquet inexistant, puis publier un paquet portant exactement ce nom dans le registre concerné.

Le développeur demande par exemple à un LLM quelle bibliothèque installer pour accomplir une tâche. L’assistant répond avec un nom vraisemblable et fournit une commande d’installation. Si cette personne ne consulte ni le registre ni la documentation, elle peut ajouter la dépendance à son projet. Le paquet malveillant se retrouve alors dans le processus de construction de l’application.

Cette logique se rapproche de menaces déjà connues dans les dépendances logicielles. Un paquet peut tromper par un nom très proche de celui d’une bibliothèque réputée, c’est le principe du typosquatting. Il peut aussi exploiter la manière dont un outil choisit entre plusieurs sources de paquets, un risque souvent associé à la confusion de dépendances. Les hallucinations des LLM ajoutent une voie nouvelle : l’attaquant ne mise plus seulement sur une faute de frappe humaine, mais sur une suggestion erronée formulée par un assistant réputé utile.

Les conséquences possibles vont de l’erreur bénigne, quand le paquet n’existe pas et que l’installation échoue, à une compromission plus sérieuse. Un composant malveillant peut chercher à dérober des identifiants présents dans l’environnement de travail, modifier des fichiers, exfiltrer des données ou introduire une porte dérobée. La gravité dépend du code du paquet, des droits dont il dispose et de la façon dont il est utilisé.

Ce que montrent les travaux sur les hallucinations de paquets

Des recherches menées par Joe Spracklen et ses collègues se sont intéressées à cette vulnérabilité des assistants de programmation. Elles montrent que les erreurs de recommandation de paquets ne sont pas seulement une hypothèse théorique. Les modèles testés peuvent générer des dépendances inexistantes dans leurs réponses de code.

Le constat important est que le phénomène n’est pas limité à un seul outil. D’après les résultats rapportés, CodeLlama est le modèle identifié comme le plus problématique dans ce domaine. Des modèles plus performants ne sont pas exempts du risque : ChatGPT-4 affiche lui aussi un taux de génération de faux paquets supérieur à 5 %.

Ce chiffre ne signifie pas que plus de 5 % de tous les paquets recommandés par ChatGPT-4 seraient dangereux. Il décrit la fréquence de recommandations de paquets inexistants dans le cadre de l’évaluation évoquée. La différence est essentielle : une hallucination devient une menace opérationnelle seulement si un attaquant a publié le nom correspondant, puis si une personne installe le paquet sans contrôle. Mais dans la sécurité des chaînes logicielles, une faible probabilité répétée à grande échelle peut suffire à créer de nombreuses occasions d’abus.

Les réponses des LLM doivent ainsi être évaluées comme celles d’un outil d’assistance. Elles peuvent accélérer la recherche, rédiger un exemple ou rappeler une commande, mais elles ne remplacent pas la vérification technique. Leur ton affirmatif est particulièrement trompeur : un modèle ne signale pas toujours clairement son incertitude lorsqu’il invente une référence.

Pourquoi le vibe coding accentue le risque

L’expression vibe coding désigne une pratique dans laquelle une personne s’appuie largement sur les suggestions d’une IA pour programmer, en privilégiant la rapidité et le résultat apparent plutôt que la compréhension détaillée de chaque ligne. Dans sa forme la plus risquée, elle consiste à accepter du code, des commandes et des bibliothèques parce que l’ensemble « semble fonctionner ».

Cette approche peut aider à prototyper une idée ou à découvrir un langage. Elle devient dangereuse lorsqu’elle court-circuite les réflexes du développement professionnel : lire la documentation, tester, relire le code, isoler les secrets et contrôler les dépendances. Les discussions entre développeurs reflètent cette tension. Certains voient dans les LLM des outils très utiles, d’autres les comparent à des « internes d’été » rapides mais susceptibles de commettre des erreurs élémentaires.

La bonne question n’est donc pas de savoir s’il faut interdire toute assistance par IA. Elle est de déterminer quelles décisions peuvent être déléguées à un outil probabiliste. Générer un brouillon de fonction n’a pas les mêmes conséquences qu’ajouter un nouveau paquet à un service qui manipule des données sensibles.

Les contrôles à appliquer avant d’installer une dépendance

La première mesure consiste à vérifier le nom suggéré directement dans le registre adapté. Il faut s’assurer que le paquet existe réellement, que sa description correspond au besoin et que la documentation officielle mentionne bien les fonctions proposées par le LLM. Une recherche sur le Web peut compléter ce contrôle, mais ne remplace pas l’examen de la page du paquet et de son code lorsque celui-ci est disponible.

Une dépendance récemment créée, très peu documentée ou sans signaux d’adoption mérite une prudence accrue, surtout si elle est proposée par une IA sous un nom que le développeur ne connaît pas. Il ne s’agit pas de rejeter systématiquement les nouveaux projets, mais d’adapter la vérification au niveau de confiance et à la sensibilité de l’application.

Les équipes peuvent intégrer ces contrôles dans leur méthode de travail :

• Vérifier la documentation et l’usage réel du paquet avant de copier une commande proposée par un LLM.
• Examiner le mainteneur, les versions et les dépendances du composant, plutôt que de se fier au seul nom.
• Soumettre chaque nouvelle dépendance à une revue de code, particulièrement dans les projets professionnels.
• Verrouiller les versions utilisées par le projet afin de rendre les installations reproductibles et de mieux maîtriser les changements.
• Tester dans un environnement séparé avant d’introduire un nouveau composant dans une application ou un système sensible.

Les gestionnaires de paquets, les fichiers de verrouillage et les outils d’analyse des dépendances ne remplacent pas la vigilance humaine. Ils apportent néanmoins des traces et des garde-fous précieux : ils permettent de savoir quelle version exacte a été installée, de repérer les changements et d’éviter qu’une résolution automatique des dépendances ne modifie discrètement un projet.

La formation des modèles ne suffira pas à elle seule

Réduire les hallucinations à la source est une piste de mitigation évidente. Des modèles mieux entraînés, capables d’indiquer leur incertitude ou de s’appuyer sur des informations vérifiées, pourraient diminuer le nombre de références imaginaires. Cela suppose toutefois une surveillance continue : les catalogues de paquets évoluent sans cesse, des projets apparaissent, changent de nom ou cessent d’être maintenus.

Une autre voie consiste à mieux relier les assistants de code aux données fiables du contexte de développement. Dans un environnement contrôlé, un outil peut par exemple être conçu pour vérifier qu’un paquet recommandé figure bien dans les sources autorisées avant de proposer une commande d’installation. Cette approche ne dispense pas d’un contrôle, mais elle réduit l’écart entre une suggestion statistiquement plausible et une dépendance effectivement disponible.

Le sujet dépasse donc les seuls modèles. Les plateformes de distribution, les gestionnaires de paquets, les équipes de sécurité et les développeurs ont chacun un rôle. Une chaîne logicielle sûre repose sur plusieurs barrières successives, pas sur la promesse qu’un seul outil ne commettra jamais d’erreur.

Ce qu’il faut surveiller

À mesure que les assistants de programmation se généralisent, la sécurité des suggestions de dépendances deviendra un enjeu plus visible. Les recherches sur les faux paquets invitent à mesurer non seulement la qualité du code généré, mais aussi la fiabilité des références externes qu’il contient. Un programme peut être syntaxiquement correct tout en introduisant un risque par une simple commande d’installation.

Les organisations qui encouragent l’usage des LLM ont intérêt à définir des règles claires : quels outils sont autorisés, quelles vérifications sont obligatoires, qui valide les nouvelles dépendances et comment réagir lorsqu’un paquet suspect a été intégré. Pour les développeurs individuels, le principe reste simple : traiter toute recommandation de bibliothèque fournie par une IA comme un début de recherche, jamais comme un feu vert.

Cette discipline ne retire rien à l’utilité des LLM. Elle rappelle seulement qu’en cybersécurité, la fluidité d’une réponse ne constitue pas une garantie. Face aux faux paquets, quelques minutes de vérification peuvent éviter qu’une hallucination ne se transforme en incident logiciel.