Le code arrive plus vite, la faille aussi

Un développeur construit un SaaS entier en un week-end. Il maîtrise mal le framework, n'a pratiquement pas de formation en sécurité et personne ne relit vraiment le code. L'application fonctionne, l'interface est propre, la démonstration impressionne. Puis vient le détail qui change tout : les clés d'API de chaque utilisateur sont exposées sur internet.

C'est là que se loge le paradoxe du vibe coding en 2026. On n'a jamais livré du logiciel aussi vite. On n'a jamais eu autant de chances de livrer en même temps des vulnérabilités prêtes à être exploitées.

Le code qui compile n'est pas le code qui protège

La donnée la plus lourde vient de Veracode, qui a testé plus de 100 modèles de langage sur 80 tâches de programmation en conditions réelles. Résultat : 45 % du code généré par IA échoue aux tests de sécurité et introduit des vulnérabilités relevant de l'OWASP Top 10 dans des systèmes proches de la production. Java s'est révélé le plus mauvais élève, avec plus de 70 % d'échec. Python, C# et JavaScript se situent entre 38 % et 45 %.

Le point troublant tient au décalage entre qualité apparente et sûreté réelle. Il y a deux ans, moins de 20 % des échantillons de code IA s'exécutaient correctement. Aujourd'hui, environ 90 % compilent dès la première tentative. Les modèles sont donc devenus nettement meilleurs pour produire du code fonctionnel. Mais ils n'ont presque pas progressé en sécurité. C'est aussi ce que souligne la reprise du rapport Veracode par Help Net Security : l'amélioration porte sur l'exactitude du code, non sur sa robustesse face aux attaques.

Et l'idée selon laquelle un modèle plus gros réglerait la question ne tient pas. Les LLM récents n'écrivent pas un code sensiblement plus sûr.

Chaque itération ajoute une feature et retire un peu de contrôle

C'est sans doute la mécanique la plus mal comprise. Vous demandez une première version. Puis vous ajoutez une fonctionnalité, une exception, un rôle, une intégration, une permission supplémentaire. Vu du produit, cela ressemble à un raffinement naturel. Vu de la sécurité, c'est souvent une détérioration silencieuse. La recherche de Kaspersky montre qu'après cinq itérations de prompt, le code contenait 37 % de vulnérabilités critiques en plus par rapport à la génération initiale. Sur l'ensemble des tests, les prompts centrés sur les fonctionnalités ont créé 158 nouvelles vulnérabilités, dont 29 critiques.

Le mécanisme est assez clair. Chaque révision ajoute de la complexité sans réévaluation architecturale. Le modèle optimise pour la question « est-ce que cela marche ? », beaucoup moins pour « est-ce que l'ensemble reste cohérent, cloisonné et défendable ? ». C'est ainsi que s'accumulent des risques proches des vulnérabilités de sécurité observées dans l'infrastructure des agents IA : chaque pièce semble acceptable, mais l'assemblage devient fragile.

On croit enrichir l'application. On fragilise parfois son comportement le plus critique.

Les pires failles ne sont plus forcément les plus connues

Il faut ici apporter une nuance importante. Une étude de décembre 2025, relayée par CSO Online à partir du travail de Tenzai, a testé cinq outils majeurs, dont Claude Code, Codex, Cursor, Replit et Devin, en construisant trois applications identiques avec chacun d'eux. Les chercheurs ont trouvé 69 vulnérabilités sur 15 applications.

Le plus intéressant n'est pas seulement le nombre, mais la nature des défauts. Les outils n'ont pas surtout produit des SQL injections ou des failles XSS exploitables dans leur forme classique. Ces schémas sont aujourd'hui largement documentés et partiellement neutralisés dans l'entraînement des modèles. Le vrai danger se situe davantage dans les vulnérabilités de logique métier.

Un tunnel de paiement où l'utilisateur peut fixer lui-même son prix. Un endpoint d'API qui fait confiance à une autorisation côté client. Un système propre sur le plan syntaxique, mais faux sur le plan du comportement attendu. C'est précisément ce que les entreprises sans défense réelle contre les exploits liés à l'IA continuent de manquer, parce que cela demande du contexte et du jugement, non simplement du code valide.

Les 81 % de vitesse gagnée peuvent devenir une dette composée

Oui, l'accélération existe. Le problème est qu'on la mesure souvent au mauvais moment. InfoQ, en reprenant l'analyse d'Ox Security, décrit ce code comme très fonctionnel, mais structurellement faible en discernement architectural. Dans 80 % à 90 % des projets examinés, les mêmes anti-patterns reviennent : commentaires excessifs, refus implicite de refactoriser, surspécification et bugs récurrents qui auraient dû disparaître une bonne fois pour toutes.

L'analyste Ana Bildea parle à ce sujet de dette technique exponentielle. La dette classique s'accumule de façon linéaire. La dette IA se compose. Pendant quelques mois, la vitesse de livraison semble formidable. Puis les correctifs de sécurité, les réécritures et la réponse aux incidents absorbent l'avance. C'est la même logique que celle des gains de productivité IA qui se dissolvent ensuite dans le retravail.

L'étude METR citée dans l'article source illustre parfaitement cet écart de perception. Les développeurs se sentaient 20 % plus rapides, alors que la mesure dans des bases de code réelles les montrait 19 % plus lents. Le bénéfice psychologique est immédiat. Le coût, lui, arrive plus tard.

La solution marche, mais elle ruine le fantasme de simplicité

La conclusion la moins séduisante est pourtant la plus utile. Le prompting orienté sécurité améliore réellement les résultats. D'après Kaspersky, une consigne aussi générale que demander le respect des bonnes pratiques de secure coding divise déjà par deux le taux de vulnérabilité. Des consignes plus précises, adaptées au langage, réduisent encore davantage le risque.

Mais c'est justement là que le rêve du vibe coding se fissure. Dire « construis-moi un système de paiement » est rapide. Dire « construis-moi un système de paiement avec validation des autorisations côté serveur, nettoyage des entrées, limitation de débit et conformité OWASP » demande déjà la même compréhension que celle que l'on cherchait à éviter.

Les entreprises qui s'en sortent le mieux traitent donc le code généré par IA comme un premier jet, jamais comme un remplacement du jugement d'ingénierie. On retrouve ici la même logique que dans l'écart entre entreprises qui utilisent l'IA et celles qui en profitent réellement : l'outil accélère, mais la responsabilité de l'architecture et du risque reste humaine.

Vibe coding permet de livrer vite. La vraie question est seulement de savoir si vous pourrez ensuite réparer, à un coût acceptable, tout ce qui a été livré avec cette vitesse.