On pensait que l’IA codait mieux que nous : un développeur a lu ce qu’elle produit vraiment et le constat fait froid dans le dos

Le constat est brutal : 45 % des tâches de codage confiées à une IA introduisent des vulnérabilités de sécurité. Pas quelques cas isolés, pas un outil mal configuré. Quand on lit vraiment ce que les modèles produisent, quand des chercheurs s’assoient pour l’analyser ligne par ligne, le tableau est franchement inconfortable pour ceux qui ont misé toute leur stack sur le « vibe coding ».

Ce que les chiffres disent vraiment

Une étude a analysé 80 tâches de codage réalisées à l’aide de plus de 100 grands modèles de langage, révélant que si l’IA génère du code fonctionnel, elle introduit des vulnérabilités de sécurité dans 45 % des cas. Ce chiffre sort du rapport Veracode publié en 2025, et il y a un détail encore plus dérangeant : lorsqu’ils ont le choix entre une méthode sécurisée et une méthode non sécurisée pour écrire du code, les modèles d’IA générative choisissent l’option la moins sécurisée dans 45 % des cas.

ce n’est pas seulement que l’IA ignore parfois la sécurité. C’est qu’elle choisit activement la voie risquée quand les deux options sont sur la table. Et le pire dans tout ça ? Les grands modèles ne sont pas beaucoup plus performants que les petits, ce qui suggère qu’il s’agit d’un problème systémique plutôt que d’un problème de mise à l’échelle. Les performances en matière de sécurité n’ont pas suivi les progrès syntaxiques et sont restées inchangées au fil du temps. Peu importe si vous balancez un GPT-4 turbo ou un modèle plus modeste, la réalité du terrain reste la même.

L’analyse de CodeRabbit sur 470 pull requests open source est tout aussi révélatrice. Le code généré par l’IA n’ajoute pas seulement des problèmes mineurs : les défauts critiques et majeurs sont jusqu’à 1,7 fois plus fréquents dans les modifications apportées par l’IA que dans les demandes de modification effectuées uniquement par des humains. Et côté performances, les inefficacités ont connu la plus forte augmentation relative, avec des problèmes tels que des opérations d’entrée/sortie excessives apparaissant près de huit fois plus fréquemment dans les soumissions générées par l’IA que dans les pull requests humaines.

Le problème de fond : l’IA est entraînée sur du mauvais code

Lorsqu’un LLM génère du code, celui-ci peut inclure des bugs ou des failles de sécurité. Ces modèles sont entraînés à partir de données accessibles au public sur Internet, y compris des milliers d’exemples de code de mauvaise qualité. C’est l’angle mort de toute la hype autour de GitHub Copilot et consorts : l’alimentation de ces modèles, c’est GitHub dans son état réel, avec toute la dette technique, les copier-coller de Stack Overflow mal adaptés, et les projets abandonnés à mi-chemin.

Le code généré avec l’IA se révèle moins sécurisé que celui produit par les seuls développeurs, un phénomène risquant d’entraîner un cercle vicieux, les LLM étant entraînés avec ce code de moins bonne qualité. Un serpent qui se mord la queue. Pire, les dépôts de code issus d’un développement assisté par l’IA sont 40 % plus susceptibles de contenir des clés d’API, des mots de passe ou des jetons.

La question des packages halluccinés mérite une mention spéciale. Une étude a révélé que 19,7 % des packages recommandés par les LLM étaient fabriqués et inexistants. 58 % de ces packages halluccinés se répètent à travers plusieurs requêtes, les rendant exploitables par des attaquants qui n’ont qu’à enregistrer les noms de packages fictifs. Ce n’est plus un bug, c’est un vecteur d’attaque en kit.

Les développeurs le savent, mais ne vérifient pas

C’est là où ça devient psychologiquement fascinant. Moins de la moitié des développeurs indiquent vérifier systématiquement le code généré par l’IA avant de le valider, et près de quatre sur dix estiment que la relecture de ce code exige plus d’efforts que celle du code écrit par leurs collègues. La conscience du risque est présente, l’effort de vérification ne suit pas.

À mesure que la qualité des assistants de codage s’améliore, les développeurs ont plus de mal à détecter les erreurs, bien que ces dernières soient toujours présentes. « On se retrouve face à un problème similaire à la recherche d’une aiguille dans une botte de foin : même si le nombre de problèmes diminue ces problèmes peuvent engendrer une faille de sécurité majeure, bien dissimulée et difficile à détecter. »

La tendance dite du « vibe coding » aggrave structurellement le problème. L’essor du vibe coding, où les développeurs s’appuient sur l’IA pour générer du code généralement sans définir explicitement les exigences de sécurité, représente un changement fondamental. La principale préoccupation est que les développeurs n’ont pas besoin de spécifier les contraintes de sécurité pour obtenir le code qu’ils souhaitent, laissant les décisions de codage sécurisé aux LLM.

Une étude de Stanford a révélé que, dans 4 tâches sur 5, les participants assistés par l’IA écrivaient un code moins sécurisé que ceux sans IA, soit une augmentation de 80 % par rapport aux programmeurs sans assistance. Pire encore, ils étaient beaucoup plus susceptibles de surestimer la sécurité de leur code, avec une augmentation de 3,5 fois de la fausse confiance. La confiance excessive est peut-être le vrai danger, plus que les failles elles-mêmes.

Ce que ça change concrètement dans vos projets

La bonne nouvelle, si on peut appeler ça ainsi, c’est que les solutions existent et sont connues. La dernière étape consiste à traiter le code généré par l’IA avec la même rigueur que le code écrit par des développeurs humains, et pas n’importe quel développeur : comme lorsque vous examinez une PR d’un collègue aux compétences discutables. Cette formulation est brutale mais juste.

L’un des aspects les plus troublants est que lorsque les chercheurs ont demandé au LLM de corriger des vulnérabilités spécifiques dans le code, l’IA a parfois introduit de nouveaux bugs au lieu de corriger les originaux. Ce n’est pas une anecdote isolée, c’est une propriété fondamentale de la façon dont ces modèles raisonnent sur le code : ils optimisent pour la cohérence syntaxique locale, pas pour l’exactitude globale du système.

La prolifération du code généré par l’IA bouleverse la répartition des responsabilités : qui doit valider, tester et assumer les conséquences d’un bug ? La moitié des développeurs pensent être tenus pour responsables en cas de brèche. C’est un angle mort organisationnel que peu d’entreprises ont commencé à traiter sérieusement. Le vibe coding a démocratisé la production de code, mais personne n’a encore vraiment répondu à la question de la gouvernance qui va avec.

Sources : businesswire.com | intelligence-artificielle.developpez.com