Pourquoi les logiciels générés par l'IA nécessitent encore une revue d'ingénierie

Andrej Karpathy a forgé l'expression vibe coding en février 2025 pour décrire un mode de développement où l'on décrit ce que l'on veut, on accepte ce que l'IA produit, et l'on ne lit pas le code. Sa formulation était indulgente : un mode de loisir du week-end pour des projets personnels. La suite ne l'a pas été. À mi-2025, une vague de non-ingénieurs avait livré des applications SaaS en production construites entièrement avec Cursor, Replit Agent, v0 et bolt.new, sans jamais comprendre ce qu'ils avaient construit. Les applications étaient convaincantes en démo. Certaines s'effondrent en production.

Ce qu'est réellement le vibe coding

La description originale de Karpathy est précise : on est « dans la zone », on dit à l'IA ce que l'on veut, elle produit du code, on appuie surtout sur accepter, et l'on ne comprend pas vraiment ce qui tourne. Il l'a reconnu explicitement : « Je ne lis pas le code, je me laisse porter par l'ambiance. » Pour un outil personnel ou un prototype jetable, cela convient. Le vibe coder ne prétend pas être ingénieur. Le problème vient de l'écosystème d'outils : « lancez votre startup en un week-end » de Replit Agent, les déploiements en un clic de v0, la génération full-stack instantanée de bolt.new, qui ont présenté ce mode comme un chemin légitime vers un logiciel de production.

La dette technique qui en résulte est qualitativement différente du mauvais code ordinaire.

Pourquoi le code issu du vibe coding est pire que du mauvais code écrit à la main

Quand un développeur junior écrit du mauvais code, il comprend ce qu'il voulait faire. On peut s'asseoir avec lui, tracer la logique et corriger. Quand une IA génère du mauvais code que l'opérateur n'a jamais lu, il n'y a aucun modèle mental à récupérer. Le développeur ne peut pas expliquer pourquoi l'authentification est structurée ainsi, parce qu'il ne l'a jamais lue. Il ne peut pas dire quelle bibliothèque tierce gère les paiements, parce qu'il a accepté le fichier sans l'ouvrir. Le code est une boîte noire qu'il possède mais sur laquelle il ne peut pas raisonner.

Les schémas d'échec que l'on observe régulièrement dans les applications de production générées par l'IA :

• Des contournements d'authentification intégrés dans un scaffold ; des secrets JWT présents dans des exemples de variables d'environnement commités dans des dépôts publics : ce sont des constats fréquents lors des revues de code de projets assistés par l'IA sans supervision d'ingénierie. Le code d'authentification généré par l'IA copie souvent des patterns issus des données d'entraînement sans comprendre le modèle de sécurité. La sécurité au niveau des lignes désactivée « temporairement » pendant le développement, laissée en production. Des vérifications de rôle qui comparent des littéraux de chaînes et se cassent dès qu'un champ est renommé.
• Aucune gestion des erreurs au-delà du chemin nominal. L'IA a écrit le cas de succès. Que se passe-t-il quand le fournisseur de paiement retourne un 402 ? Que se passe-t-il quand la connexion à la base de données tombe en pleine transaction ? Dans les applications issues du vibe coding, la réponse est généralement un rejet de promesse non géré qui se traduit par un écran blanc.
• Dépendance aux patterns générés par l'IA. Quand l'IA a choisi de structurer le modèle de données d'une certaine façon, le vibe coder a accepté. L'ensemble de l'application est maintenant construit autour de cette structure. S'en éloigner exige de comprendre un code que le développeur n'a jamais lu.
• Aucun test. Les tests sont absents parce que le vibe coder ne les a jamais demandés et que l'IA ne les a pas proposés. Quand quelque chose casse en production, il n'y a aucune suite de tests pour détecter les régressions dans le correctif.

L'écart entre la démo et la production

Les outils IA sont réellement efficaces pour générer du code qui fonctionne sur le chemin nominal, avec des entrées propres, un réseau coopératif et un seul utilisateur simultané. C'est exactement la condition dans laquelle une démo tourne. La production est l'inverse : entrées malformées, connexions interrompues, écritures concurrentes, cas limites qui n'ont jamais été spécifiés dans le prompt.

Le schéma se déroule de façon prévisible. Une application issue du vibe coding est lancée, semble soignée, attire les premiers utilisateurs. Puis : un utilisateur dont le nom contient un caractère non-ASCII brise la requête en base de données. Un utilisateur mobile sur une connexion lente déclenche une condition de concurrence dans la gestion d'état. Des scenarios existent où des endpoints API exposent des données entre comptes utilisateurs parce que les vérifications d'autorisation étaient absentes ou incomplètes : conséquence directe de la livraison d'un code jamais relu pour l'application côté serveur. Aucun de ces échecs n'est exotique. Ce sont les conséquences élémentaires de livrer un code qu'on n'a jamais lu.

L'IA rend les bons ingénieurs meilleurs. Elle ne rend pas les mauvais ingénieurs inutiles.

C'est l'affirmation que le discours sur le vibe coding inverse. Les outils sont réels et les gains de productivité le sont aussi. Chez webvise, j'utilise Claude Code, Cursor et l'orchestration multi-agents sur chaque projet livré. Des ingénieurs utilisant Claude Code rapportent des gains de temps significatifs sur des tâches qui prendraient autrement des jours. Les mêmes outils entre les mains de quelqu'un sans fondamentaux en ingénierie produisent une démo qui ne survit pas à son premier vrai utilisateur.

C'est l'ingénieur qui fait la différence avec l'outil. Les fondamentaux de l'ingénierie portent sur la compréhension des frontières système, des modes de défaillance, des modèles de sécurité et de l'intégrité des données. Un ingénieur utilisant Claude Code lit le code d'authentification généré et reconnaît quand il est incorrect. Un développeur inexpérimenté accepte la suggestion et la livre.

Le risque spécifique pour les logiciels métier

Les applications grand public peuvent absorber les modes de défaillance du vibe coding. Si un gestionnaire de finances personnelles perd quelques données, c'est gênant. En revanche, si un B2B SaaS gérant des dossiers clients, des flux de paiement ou des workflows internes est livré avec les problèmes d'authentification et de gestion des erreurs décrits ci-dessus, les conséquences sont juridiques, contractuelles et réputationnelles. La responsabilité GDPR s'applique quelle que soit la façon dont le code a été généré ; le code de traitement des données exige une revue.

Plusieurs produits SaaS récents assistés par l'IA ont suivi un schéma similaire : impressionnants en démo, ils ont acquis leurs premiers clients sur la promesse, puis ont heurté un mur quand le premier prospect entreprise a mené une revue de sécurité ou quand le premier jour à fort trafic a exposé la gestion des erreurs manquante. Les fondateurs ne sont pas des fraudeurs : ils ne savaient genuinement pas ce qu'ils avaient construit.

Ce qu'il faut chercher chez un partenaire de développement augmenté par l'IA

Si vous évaluez un partenaire de développement qui affirme utiliser des outils IA, posez ces questions :

• Exécutent-ils des tests automatisés sur le code généré par l'IA ? Si la réponse est « nous faisons confiance à la sortie de l'IA », passez votre chemin. La couverture de tests est ce qui permet de détecter la gestion des erreurs que l'IA a omise.
• Effectuent-ils des revues de sécurité sur le code d'authentification et d'autorisation généré ? Les outils IA copient des patterns d'authentification issus des données d'entraînement. Ces patterns incluent de vraies vulnérabilités tirées de vraies bases de code.
• Peuvent-ils expliquer l'architecture de ce qu'ils ont construit ? Si un développeur ne peut pas vous parcourir le modèle de données et expliquer pourquoi il est structuré ainsi, c'est qu'il ne l'a pas conçu : il l'a accepté.
• Versionnent-ils leurs prompts aux côtés du code ? Appliquer la discipline d'ingénierie aux outils IA, c'est traiter le prompt comme une partie de la base de code, et non comme une entrée jetable.
• Ont-ils un processus pour gérer les hallucinations de l'IA ? Les outils IA génèrent en toute confiance des appels API incorrects, des méthodes dépréciées et des fonctions de bibliothèque inexistantes. Une équipe expérimentée dispose d'une boucle de revue pour cela. Un vibe coder le découvre au moment de l'exécution.

Le bon cadre : l'IA comme multiplicateur de force, non comme substitut

Le discours sur le vibe coding est séduisant parce qu'il est partiellement vrai. Les outils IA ont réellement abaissé le seuil pour construire des logiciels. Un non-ingénieur motivé peut livrer un prototype fonctionnel en un week-end. C'est précieux pour la validation, pour les MVP, pour l'outillage interne à faibles enjeux. L'erreur est de confondre le plancher avec le plafond : supposer que parce qu'on peut faire tourner quelque chose, on peut le faire tourner de façon fiable à grande échelle, de manière sécurisée et maintenable.

Les ingénieurs qui ont le plus bénéficié des outils de codage IA sont ceux qui les utilisent pour éliminer les parties fastidieuses de l'ingénierie, boilerplate, scaffolding, refactorings répétitifs, tout en appliquant leur jugement aux parties qui comptent : l'architecture, la sécurité, la gestion des erreurs et la préparation à la production. L'IA accélère le travail. L'ingénieur s'assure qu'il est correct.

webvise utilise le développement augmenté par l'IA sur chaque projet, avec Claude Code, Cursor et des pipelines multi-agents, mais avec la discipline d'ingénierie qui rend le résultat prêt pour la production. Si vous construisez un logiciel qui doit survivre à de vrais utilisateurs, de vrais cas limites et de vraies exigences de sécurité, prenez contact pour voir comment le processus fonctionne.