« Le code écrit par l'IA, c'est de la camelote » ? Les critiques ont à moitié raison — et le mot qui manque, c'est « phase »

En 2026, « vibe coding » est devenu l’un de ces mots qui coupent une salle en deux dès qu’on les prononce. D’un côté, ceux qui y voient la transformation la plus importante depuis le cloud. De l’autre, ceux qui le décrivent comme « une façon polie d’enrober de la camelote générée par l’IA dans un vernis d’artisanat ».

Les débats sont vifs. Et ce que je veux dire, c’est : les deux camps ont raison — mais chacun oublie un mot.

Les critiques méritent d’être écoutés

Soyons clairs d’emblée : ceux qui critiquent le vibe coding ne tirent pas dans le vide.

Leur préoccupation centrale, c’est la sécurité et la maintenabilité. De nombreuses applications construites « prompt en tête » n’ont jamais subi le moindre audit de sécurité. Dès que votre produit touche à de l’argent, des identités ou des données tierces, cette inquiétude devient immédiatement valide — et potentiellement fatale.

Cette partie de la critique, tout professionnel sérieux du produit devrait l’intégrer sans réserve. Un démo qui tourne, et un système capable de tenir face à de vrais utilisateurs, de vraies attaques et de vraies données, c’est deux choses séparées par une rivière très large.

Mais il leur manque un mot : phase

Où se trompent les critiques ? Ils mettent tout dans le même sac.

« Le code généré par l’IA est peu sûr et difficile à maintenir » — cette affirmation est vraie pour les systèmes en production, mais largement exagérée pour les prototypes. Ce sont deux phases fondamentalement différentes, et les mesurer avec le même étalon, c’est la recette pour un débat sans fin.

• Phase prototype : l’objectif est de valider une intention — est-ce que ça vaut la peine d’être construit ? Est-ce que les utilisateurs le reconnaissent ? L’expérience est-elle juste ? À ce stade, la question de savoir si le code peut tenir en production n’existe tout simplement pas, parce que ce code n’ira jamais en production.
• Phase production : l’objectif est de tenir face au monde réel — sécurité, performance, conformité, maintenabilité. Là, chaque argument des critiques est fondé.

Utiliser le bon outil, c’est savoir à quelle phase on se trouve. Exiger des standards de production d’un prototype, c’est de l’irresponsabilité dans l’autre sens — c’est se tirer une balle dans le pied.

doaipm sépare ces deux choses depuis le début

C’est exactement ce que doaipm a toujours défendu. Nous ne disons jamais « ce que l’IA fait en une phrase peut aller directement en production » — nous disons deux choses distinctes :

Premièrement, haute fidélité d’abord, pour valider plus vite. Sauter les wireframes et construire directement quelque chose qui tourne, ce n’est pas livrer du code de production — c’est parce qu’un prototype qui fonctionne est le document de spécification le plus précis qu’une équipe engineering puisse recevoir. Sa mission : répondre à « est-ce qu’on a fait le bon truc ? » en quelques heures, pas en quelques semaines.

Deuxièmement, le filet de sécurité est la réponse directe aux critiques. Le filet de sécurité doaipm est écrit noir sur blanc :

• Pas de vraies clés API ni de données de production dans les prototypes — données fictives, données anonymisées ;
• Les boutons irréversibles (publier, supprimer, payer) sont actionnés par un humain ;
• On ne touche pas à la production — les prototypes tournent uniquement en local ou en environnement de test ;
• Ce qui est incertain (conformité, paiement, vie privée, choix technique) est soumis à décision humaine ;
• Le prototype est un document de spécification, la version de production est reconstruite par l’engineering.

Vous le voyez : chaque inquiétude des critiques — l’argent, les identités, les données des autres, le passage direct en ligne — le filet de sécurité y répond point par point.

Alors, « le code de l’IA, c’est de la camelote » — vrai ou faux ?

Ça dépend de ce que vous en faites.

• Utiliser un prototype haute fidélité jetable pour valider une idée — c’est l’investissement le plus rentable de cette décennie, sans concurrence.
• Déployer en production une application construite « prompt en tête » sans audit de sécurité, en la laissant toucher à l’argent et aux données de vos utilisateurs — là, les critiques ont raison, vous créez activement un risque.

Même outil, deux résultats opposés. La ligne de partage, c’est le mot « phase ».

La maturité, ce n’est pas choisir un camp — c’est savoir à quelle phase on est

Le vrai signal de ce débat : ne choisissez pas un camp, distinguez les phases.

Et « à quelle phase est-on maintenant, et quel étalon faut-il utiliser » — ce jugement, c’est précisément le travail du product manager. L’IA a rendu le « faire » presque gratuit ; en conséquence, la capacité à faire la bonne chose à la bonne phase est devenue la compétence la plus précieuse. C’est Andrej Karpathy qui l’a dit d’une autre façon : l’IA amplifie le jugement, elle ne le remplace pas.

Haute fidélité d’abord — mais un prototype ne sera jamais une mise en production. Faites confiance à la vitesse de l’IA, et tenez la ligne de la production.

Le workflow en cinq phases de doaipm et son filet de sécurité sont conçus exactement pour « utiliser le bon outil à la bonne phase ». Commencez par le centre de méthode et le manuel opératoire 言出法随.

Pour aller plus loin

• Vibe Coding — The Vibe Coding Debate 2026: Both Sides, Sourced
• Smashing Magazine — When “Production-Ready” Becomes a Design Deliverable
• Userpilot — Product Management in 2026: Is AI Product Management a Lie?