Avec les assistants IA, le logiciel naît aujourd'hui à un rythme impensable il y a trois ans : décrire, générer, voir tourner. Ce vibe coding est productif et plaisant, et c'est précisément là que réside le risque. Le code a l'air fini, semble fini et souvent ne l'est pas. Cet article résume ce que la recherche dit réellement du code généré par IA et montre comment les entreprises peuvent profiter de la vitesse sans importer en production les problèmes de demain.
Ce que le vibe coding fait bien et où cela bascule
Les assistants IA excellent à transformer rapidement une description claire en code qui fonctionne : formulaires, accès aux données, rapports, prototypes entiers. Pour des services métier qui veulent numériser leurs propres processus, c'est un vrai levier. Le point de bascule arrive quand le prototype devient discrètement un système de production : le code fonctionne sur le chemin de démonstration, mais personne n'a regardé les cas d'erreur, les droits d'accès ni la maintenabilité.
Le problème central n'est pas que l'IA écrive du mauvais code. Le problème central est qu'elle écrit du code convaincant. La plausibilité remplace l'examen, et c'est exactement cette brèche que les processus doivent fermer.
La recherche : la sécurité reste le maillon faible
Le GenAI Code Security Report 2025 de Veracode a testé plus de 100 modèles de langage sur 80 tâches de programmation réalistes. Résultat : dans 45 pour cent des cas, le code généré contenait une faille de sécurité connue, et même environ 70 pour cent en Java. Les modèles n'ont pas paré le cross-site scripting dans 86 pour cent des tâches concernées. Fait notable : les modèles plus récents et plus grands écrivaient du code fonctionnellement meilleur mais pas plus sûr. Le taux de sécurité est resté quasi constant à travers les générations de modèles.
La maintenabilité souffre aussi de façon mesurable. GitClear a analysé 211 millions de lignes de code modifiées entre 2020 et 2024 : la part de lignes copiées a fortement augmenté, les blocs dupliqués se sont multipliés, et en 2024 le copier-coller a dépassé le refactoring pour la première fois. Dans le même temps, la part de code retouché dans les deux semaines est passée de 5,5 à 7,9 pour cent. Le code IA s'écrit vite, mais il est aussi retouché anormalement vite.
La vitesse ressentie n'est pas la vitesse mesurée
Le rapport DORA 2024 de Google a trouvé un motif remarquable chez plus de 39 000 répondants : 75 pour cent déclarent des gains de productivité grâce à l'IA, mais au niveau des équipes, une adoption de l'IA supérieure de 25 pour cent allait de pair avec environ 1,5 pour cent de débit de livraison en moins et 7,2 pour cent de stabilité de livraison en moins. Plus de code s'écrit, mais des lots de changements plus gros et moins d'examen fragilisent la chaîne de livraison.
Une expérience randomisée de l'institut de recherche METR en 2025 va dans le même sens : des développeurs open source expérimentés étaient en moyenne 19 pour cent plus lents avec les outils IA, tout en croyant avoir été 20 pour cent plus rapides. Un suivi de 2026 a ramené l'effet à peu près au neutre, mais le constat d'erreur de perception est resté. Le résumé honnête : le gain de productivité est réel selon les situations, et notre propre jugement à son sujet n'est pas fiable. D'où l'importance de contrôles objectifs plutôt que du ressenti.
Ce qui en découle : la relecture n'est pas un frein, c'est la condition de la vitesse
La conclusion de la recherche n'est pas d'interdire le vibe coding. La conclusion est de le traiter comme toute autre source de code, simplement avec un débit plus élevé : ce qui part en production est contrôlé. Automatiquement là où les machines sont bonnes, et par des humains là où le contexte compte.
- Des contrôles qualité automatiques avant chaque soumission : scan de secrets, audit des dépendances, scan de vulnérabilités des conteneurs, vérification des migrations de base de données et de leurs règles d'accès.
- Des garde-fous d'architecture que l'IA lit avec le code : la logique métier appartient au backend, les règles d'accès à la base de données, les secrets jamais dans le code. Ces règles peuvent être transmises à l'IA comme instructions de travail contraignantes.
- Une relecture humaine avant la mise en service : un regard expérimenté sur les accès aux données, les cas d'erreur et la question de savoir si le code résout vraiment le problème et pas seulement le chemin de démonstration.
- Des unités petites et traçables : une application, un objectif, un responsable, un journal d'audit. Le retour arrière planifié plutôt qu'espéré.
- L'exploitation comme partie du processus : supervision, sauvegardes et scans de sécurité continus, car une relecture à la mise en service ne remplace pas l'observation en production.
Comment nous mettons cela en œuvre avec Kinster
Dans notre plateforme d'applications Kinster, ce processus est intégré et non rapporté : les services métier décrivent leur application et la développent assistés par IA dans VS Code dans le navigateur, à l'intérieur de garde-fous que l'IA lit comme instructions de travail. Une version ne peut être soumise que si les contrôles automatiques la laissent passer, et elle ne part en production qu'après la relecture par needful-apps. Les déploiements se font sans interruption, la version précédente reste prête pour le retour arrière, et chaque décision figure dans le journal d'audit.
Ainsi se conserve le meilleur du vibe coding, à savoir la vitesse et la proximité du service métier avec son processus. Et les chiffres des études ci-dessus restent ce qu'ils doivent être : un avertissement sur le chemin non contrôlé, pas votre réalité opérationnelle.
Questions fréquentes
Qu'est-ce que le vibe coding ?
Une programmation assistée par IA dans laquelle on décrit en langage naturel ce qui doit être construit, un assistant IA produisant de grandes parties du code. Le terme souligne le flux de cette façon de travailler : décrire vite, générer, essayer. Le résultat ne devient prêt pour la production que par les contrôles et la relecture.
Les scans automatiques ne suffisent-ils pas, pourquoi une relecture humaine en plus ?
Les scanners trouvent des motifs connus : secrets divulgués, dépendances vulnérables, failles typiques. Savoir si une application montre les bonnes données aux bonnes personnes, si les cas d'erreur sont traités sensément et si la solution correspond au processus, aucun scanner ne le voit. La combinaison est le point clé : les machines contrôlent large, les humains contrôlent en profondeur.
La relecture n'annule-t-elle pas l'avantage de vitesse de l'IA ?
Non, elle le déplace là où il doit être. Une relecture coûte des heures ; un incident de sécurité ou un système inmaintenable coûte des semaines. Les données DORA montrent que la vitesse IA non contrôlée rend la livraison moins stable, et une livraison instable est la forme de lenteur la plus chère.
Cela vaut-il aussi pour les petits outils internes sans exposition externe ?
Justement là. Les outils internes traitent souvent les données les plus sensibles (RH, calculs, clients) et sont les moins contrôlés. L'effort peut être moindre que pour un produit public, mais règles d'accès, sauvegardes et une courte relecture avant la mise en service restent le minimum, là aussi.