Vibe Coding et Slopsquatting : Les Dangers Cachés des Assistants de Codage IA

Claude Code et OpenAI Codex CLI : Des Outils Prometteurs Mais Aux Usages Limités

Le développement logiciel voit apparaître de nouveaux assistants de codage basés sur l’intelligence artificielle. Parmi eux, deux outils ont récemment attiré l’attention : Claude Code d’Anthropic et Codex CLI d’OpenAI, deux solutions lancées en 2025 qui proposent une approche différente de l’écriture de code.

« Les développeurs cherchent à faire fonctionner les choses, pas nécessairement à empêcher ce qui ne devrait pas se produire. » — Casey Ellis, Fondateur de Bugcrowd ¹

Claude Code est un outil de codage agentique qui s’intègre dans le terminal et vise à comprendre votre base de code pour faciliter certaines tâches routinières, expliquer du code complexe ou gérer des workflows git via des commandes en langage naturel. Actuellement en version bêta comme aperçu de recherche, Claude Code utilise par défaut le modèle claude-3-7-sonnet-20250219, avec un coût relativement élevé d’environ 6 dollars par jour par développeur, ce qui limituser-content-fn-1e son adoption à grande échelle.

De son côté, OpenAI Codex CLI propose aux développeurs d’utiliser les capacités de raisonnement des modèles d’OpenAI pour manipuler du code, des fichiers et itérer sur leurs projets. Lancé en avril 2025 parallèlement aux modèles o3 et o4-mini d’OpenAI, Codex CLI a l’avantage d’être plus simple à configurer, mais reste confronté aux mêmes limitations que Claude Code en termes d’adoption.

Ces outils, bien que prometteurs, ne constituent pas une révolution dans le monde du développement. Leur utilisation reste limitée par plusieurs facteurs :

• Des coûts d’utilisation élevés
• Des limitations techniques face à des bases de code complexes
• Une efficacité qui se manifeste principalement sur des projets de petite envergure

Leur intégration dans les workflows de développement professionnels demeure donc encore marginale.

La principale différence entre ces deux outils réside dans leur modèle de licence : Codex CLI est disponible sous une licence Apache 2.0 qui permet la distribution et l’utilisation commerciale, tandis que Claude Code est lié à la licence commerciale d’Anthropic, ce qui a suscité quelques débats au sein de la communauté des développeurs.

Le Phénomène du « Vibe Coding« 

Ces outils s’inscrivent dans l’émergence d’une approche de programmation parfois appelée « vibe coding« , un terme proposé par Andrej Karpathy en février 2025. Cette méthode décrit une façon de coder où l’on « s’abandonne aux vibrations » et où l’on « oublie presque que le code existe ».

Dans son article sur le sujet, Simon Willison ² explore comment le vibe coding diffère des autres formes de programmation assistée par IA, et examine ses forces et ses limites dans des contextes réels de développement.

Il s’agit essentiellement d’une approche plus conversationnelle de la programmation, où l’IA prend en charge une partie du travail technique.

Le vibe coding consiste à exprimer son intention en langage courant pour que l’IA transforme cette intention en code exécutable. Cette approche est rendue possible par des outils basés sur le terminal comme Claude Code et OpenAI Codex CLI, même si leur efficacité reste variable selon les contextes d’utilisation.

Avantages potentiels du vibe coding

Parmi les avantages potentiels du vibe coding :

• ✅ Facilitation de certaines tâches routinières : Ces outils peuvent accélérer les tâches répétitives comme la mise en place de tests basiques ou la génération de documentation.
• ✅ Charge cognitive réduite pour certaines opérations : L’approche conversationnelle peut rendre certaines phases de programmation moins exigeantes sur le plan cognitif.
• ✅ Prototypage plus fluide : Le vibe coding permet d’explorer des idées rapidement sur des projets simples, ce qui peut être utile dans les phases exploratoires.
• ✅ Interface en langage naturel : L’interaction conversationnelle offre une alternative intéressante pour certains développeurs, notamment les débutants.

Cependant, ces avantages se manifestent principalement sur des projets simples et bien délimités. Pour des bases de code complexes ou des systèmes critiques, ces outils montrent rapidement leurs limites.

⚠️ Plus important encore, derrière cette apparente simplicité se cache une menace de sécurité émergente : le « slopsquatting ».

🚨 Slopsquatting : Une Nouvelle Menace de Sécurité

Le terme « slopsquatting » a été inventé par Seth Michael Larson, développeur de sécurité en résidence à la Python Software Foundation. Il le décrit comme:

« Une forme de typosquatting où des variations ou des fautes d’orthographe de termes courants issus des résultats de modèles d’IA (‘slop’ ou ‘bouillie’ en anglais) sont utilisées pour tromper les développeurs. » — Seth Larson, Python Software Foundation ³

Comment fonctionne le slopsquatting

Contrairement au typosquatting traditionnel, qui compte sur les erreurs de frappe humaines, le slopsquatting repose entièrement sur les défauts de l’IA et la confiance excessive des développeurs dans les suggestions automatisées. L’attaque suit ce schéma :

1. Les assistants de codage IA comme Claude Code ou Codex CLI « hallucinent » parfois des noms de packages qui n’existent pas
2. Les développeurs utilisant les méthodes de vibe coding font confiance à ces suggestions et tentent d’installer ces packages inexistants
3. Les attaquants enregistrent ces noms de packages hallucinés sur des dépôts publics et y insèrent du code malveillant
4. Lorsque les développeurs installent les packages, ils introduisent involontairement des logiciels malveillants dans leurs systèmes

Ampleur du problème

Une étude de recherche complète a révélé des statistiques alarmantes sur cette vulnérabilité :

Un nombre significatif de packages, s’élevant à 19,7% (205 000 packages), recommandés dans les échantillons de test se sont avérés être des faux. Les modèles open-source hallucinaient plus fréquemment (21,7% en moyenne) par rapport aux modèles commerciaux (5,2% comme GPT-4).

L’étude a également noté des différences entre les modèles :

• CodeLlama 7B et 34B avaient les taux d’hallucination les plus élevés, dépassant 30%
• GPT-4 Turbo avait le taux le plus bas à 3,59%

Ce qui rend ce phénomène particulièrement dangereux est la cohérence de ces hallucinations. Les chercheurs ont découvert que 58% des packages hallucinés étaient répétés plus d’une fois sur dix essais, indiquant que la majorité des hallucinations ne sont pas simplement du bruit aléatoire, mais des artefacts répétables de la façon dont les modèles répondent à certaines requêtes.

Pourquoi le vibe coding augmente le risque

Le risque de slopsquatting est amplifié par l’approche du « vibe coding », où les développeurs décrivent ce qu’ils veulent et l’IA génère l’implémentation. Dans ce flux de travail, les développeurs passent du statut d’auteurs de code à celui de conservateurs, en sautant potentiellement la vérification manuelle des noms de packages.

« Le vibe coding introduit une vulnérabilité fondamentale : plus nous faisons confiance au code généré automatiquement, moins nous le vérifions, créant ainsi une opportunité idéale pour les attaques par slopsquatting. » — Joe Spracklen, chercheur en sécurité, Université du Texas ⁴

Cette approche repose fortement sur la confiance – les développeurs copient et collent souvent la sortie de l’IA sans tout vérifier. Dans cet environnement, les packages hallucinés deviennent des points d’entrée faciles pour les attaquants, surtout lorsque les développeurs sautent les étapes de révision manuelle.

🔒 Implications pour la sécurité de Claude Code et OpenAI Codex CLI

Les deux outils, Claude Code et OpenAI Codex CLI, peuvent être vulnérables à ce problème, mais avec quelques différences :

1. 📊 Précision du modèle Selon les recherches, les modèles commerciaux comme ceux qui alimentent Claude Code ont tendance à avoir moins d’hallucinations que les modèles open-source, mais le risque existe toujours.
2. 🌡️ Paramètres de température Des recherches ont montré que réduire les paramètres de « température » de l’IA (moins d’aléatoire) réduit les hallucinations, ce qui est un facteur important à prendre en compte lors de l’utilisation du codage assisté par IA.
3. 🤖 Niveaux d’autonomie Les deux outils offrent différents niveaux d’autonomie, avec des modes « entièrement automatiques » qui augmentent potentiellement le risque s’ils installent automatiquement des dépendances sans vérification.
4. 🔐 Protection par bac à sable Les fonctionnalités de sandbox dans les deux outils peuvent aider à atténuer les risques, mais ne peuvent pas éliminer complètement la possibilité d’installer des packages hallucinés.

🛡️ Stratégies d’atténuation

Pour les développeurs qui souhaitent expérimenter avec ces outils tout en minimisant les risques de slopsquatting, voici quelques stratégies d’atténuation :

1. 🔍 Vérifier manuellement tous les noms de packages Les utilisateurs doivent vérifier que les packages qu’ils installent sont des packages connus existants, n’ont pas de fautes de frappe dans le nom, et que le contenu a été examiné avant l’installation.
2. 🌡️ Réduire les paramètres de température Ajustez les paramètres de température des modèles d’IA pour réduire l’aléatoire et les taux d’hallucination.
3. 🛠️ Utiliser des scanners de dépendances Mettez en œuvre des outils qui analysent les dépendances pour détecter les risques avant l’installation. « La vérification automatisée des dépendances est essentielle pour détecter les packages malveillants avant qu’ils ne soient intégrés à votre projet. » — Feross Aboukhadijeh, CEO de Socket ⁵
4. 🔒 Créer des miroirs de packages internes Les organisations devraient cataloguer les logiciels open-source dans un miroir privé, où les packages sont examinés pour détecter les activités malveillantes et les vulnérabilités par les équipes de sécurité.
5. 👁️ Ne jamais faire aveuglément confiance à la sortie de l’IA Toujours examiner et comprendre le code avant de l’exécuter, surtout lorsqu’il implique des installations de packages.

Conclusion

Le vibe coding facilité par des outils comme Claude Code et OpenAI Codex CLI propose une approche intéressante pour certains aspects du développement, particulièrement pour des projets de petite taille ou des tâches bien délimitées. Bien qu’il offre des avantages en termes de fluidité pour certaines opérations, il comporte aussi des limitations importantes :

• Des coûts d’utilisation élevés
• Une précision variable
• Une applicabilité limitée aux projets complexes

Le slopsquatting représente une menace émergente significative dans cet écosystème en évolution. Avec les bonnes précautions et une vigilance appropriée, les développeurs peuvent explorer les possibilités offertes par ces outils tout en minimisant les risques de sécurité associés.

« L’objectif n’est pas de remplacer le développeur, mais de lui offrir de nouveaux moyens d’interagir avec le code, tout en maintenant une vigilance appropriée face aux risques émergents. » — Raj Kesarapalli, directeur de la gestion des produits chez Black Duck ⁶

L’approche ne consiste pas à remplacer les compétences de programmation traditionnelles, mais plutôt à offrir une modalité complémentaire d’interaction avec le code pour certains contextes spécifiques. Dans la pratique, ces outils trouvent leur place dans une boîte à outils plus large, mais ne constituent pas une solution miracle pour tous les défis de développement.

Pour l’avenir, l’évolution de ces technologies dépendra de leur capacité à :

• Réduire les coûts d’utilisation
• Améliorer leur précision sur des bases de code complexes
• Renforcer leurs mécanismes de sécurité intégrés face à des menaces comme le slopsquatting

À retenir : L’équilibre entre productivité et sécurité reste le défi principal dans l’adoption de ces nouvelles méthodes de développement assistées par IA.

---

Références

1. Citation tirée d’une déclaration de Casey Ellis dans l’article « New ‘Slopsquatting’ Threat Emerges from AI-Generated Code Hallucinations », Hackread, avril 2025. ↩
2. Simon Willison, « Not all AI-assisted programming is vibe coding (but vibe coding rocks) », mars 2025. ↩
3. Propos de Seth Larson rapportés dans « AI code suggestions sabotage software supply chain », The Register, avril 2025. ↩
4. Joe Spracklen et al., « We Have a Package for You! Package Hallucination Attack in LLM-based Code Generation », Université du Texas, mars 2025 ↩
5. Feross Aboukhadijeh, cité dans « AI code suggestions sabotage software supply chain », The Register, avril 2025. ↩
6. Raj Kesarapalli, cité dans « AI-Generated Code Packages Can Lead to ‘Slopsquatting' », DevOps.com, avril 2025. ↩