Les outils de codage par IA ont un problème de confiance, et une étude à l’échelle de Reddit vient de le quantifier
Les développeurs sont de plus en plus convaincus que les outils de codage par IA constituent un risque, et il existe désormais un jeu de données de la taille d’une étude évaluée par les pairs pour étayer ce constat. Une nouvelle étude a passé au crible 1,1 million de messages Reddit pour recenser précisément la façon dont les IDE natifs LLM (LIDE), comme Cursor, Claude Code, GitHub Copilot et Codex d’OpenAI, brisent la confiance, de la suppression silencieuse de fichiers à la mise en production de code non autorisé.
L’étude, intitulée Impossible de cacher un secret …, a été rédigée par Mostafijur Rahman Akhond, Md Afif Al Mamun et Gias Uddin de l’université York, avec Song Wang de l’université de Calgary. Elle est publiée sur arXiv sous l’identifiant 2607.26390 et a été acceptée pour présentation à l’ASE, la conférence sur le génie logiciel automatisé de l’IEEE/ACM, plus tard cette année. The Register a rendu compte de ces travaux le 8 août.
Ce que les chercheurs ont fait
L’équipe a passé au crible 1,1 million de messages dans 29 subreddits consacrés aux LIDE, puis s’est concentrée sur 446 fils de discussion regroupant plus de six mille commentaires décrivant des incidents de sécurité ou de confidentialité. À partir de ces signalements, elle a construit une taxonomie des modes de défaillance, avec un résultat principal frappant : la plupart des problèmes proviennent de la conception de ces produits et des autorisations qui leur sont accordées, et non des modèles de langage sous-jacents.
Les défaillances de sécurité, en chiffres
Parmi les messages liés à la sécurité, les opérations non autorisées sur les fichiers dominent, représentant 43,1 % des signalements. Dans cette catégorie, la plainte la plus courante (28,3 %) concerne l’outil qui supprime des dossiers ou des fichiers du projet que l’utilisateur ne lui a jamais demandé de toucher ; 8,8 % décrivent des fichiers modifiés sans consentement explicite, et 5,7 % signalent un outil qui lit du contenu au-delà de l’espace de travail actif.
Les problèmes de sécurité opérationnelle suivent à 23,9 % : des incidents aux conséquences réelles en production. Des développeurs ont décrit Replit supprimant une base de données SaaS de production, et Cursor poussant du code en production malgré une instruction explicite de ne pas le faire. La génération de code non sûr représente 18,2 % des signalements, dont un cas où un logiciel écrit par Cursor a déclenché neuf détections VirusTotal, et des exemples de modifications issues d’hallucinations qui s’infiltrent dans la base de code. 16,5 % supplémentaires concernent l’outil qui ignore les instructions de l’utilisateur, les listes d’autorisation, les barrières de permissions ou les fichiers .ignore, et 4,7 % impliquent des intégrations tierces.
Les cas les plus graves sont rares, mais leur impact est disproportionné : lors d’un incident, Claude Code a exécuté chmod +x sur des scripts sans consentement, une modification des permissions de fichiers signalée dans seulement 0,6 % des messages, mais exactement le genre d’action qui peut compromettre un environnement entier.
Le volet confidentialité
Les plaintes relatives à la confidentialité, tirées de 194 messages, suivent un schéma similaire. La catégorie la plus importante (45,9 %) est le manque de transparence : les utilisateurs ont rapporté ne pas pouvoir savoir quelles données un outil collectait, combien de temps elles étaient conservées, où elles étaient envoyées, si elles alimentaient des cycles d’entraînement, ni ce que les administrateurs pouvaient voir. L’accès non autorisé aux données apparaît dans 23,7 % des cas, les atteintes à la confidentialité par fuite de données dans 15,5 %, la collecte ou la transmission non autorisée de données dans 11,9 %, et les ruptures d’intégrité du contexte dans 8,8 %, cette dernière catégorie incluant un utilisateur de Claude Desktop qui a reçu des messages de discussion provenant de la session de quelqu’un d’autre.
Des mécanismes d’adaptation plutôt que des garanties
Le constat le plus révélateur est peut-être ce que font les développeurs en réponse. L’étude documente 13 stratégies d’atténuation distinctes, avec la gestion de la configuration (33 %) et la gouvernance du code (31 %) en tête de liste : sandboxing, revue manuelle et sélection rigoureuse de ce que l’outil peut toucher. Autrement dit, les développeurs traitent ces produits comme des logiciels non fiables et construisent leurs propres garde-fous autour d’eux. Ce n’est pas le schéma d’adoption que les éditeurs commercialisent.
Ce que les fabricants d’outils devraient changer
L’article se termine par six recommandations : des contrôles de sécurité et de confidentialité adéquats ; des garde-fous imposés au niveau de l’architecture plutôt qu’après coup ; une couche de vérification qui contrôle le code produit par l’IA par rapport aux exigences de sécurité et de confidentialité ; un protocole formel pour évaluer la fiabilité des outils tiers ; une protection des fichiers sensibles ; et, la demande phare, une sécurité stricte par défaut.
Les chercheurs soutiennent que la prévention vaut mieux que la guérison : les mécanismes de sécurité devraient être intégrés avant qu’un outil ne soit autorisé à accéder profondément aux fichiers, aux données et aux systèmes d’un développeur. Des configurations sûres par défaut, affirment-ils, constituent l’amélioration la plus précieuse que ces outils pourraient apporter. Les développeurs ne devraient pas découvrir, seulement après un incident, qu’un outil disposait d’une latitude plus grande qu’ils ne le supposaient. Les utilisateurs devraient toujours pouvoir assouplir les contraintes, mais la configuration sûre devrait être le point de départ, et non une corvée de configuration.
L’étude arrive à un moment délicat pour le secteur. Tous les grands éditeurs poussent des agents dotés d’un accès système plus large et de chaînes autonomes plus longues, précisément la surface d’exposition que cet article a identifiée comme la source de la plupart des incidents. Si les développeurs votent déjà avec des sandbox et des barrières de revue, la prochaine génération d’outils devra regagner cette confiance au niveau de l’architecture.
Traduit par Lydie