Vous avez codé votre MVP par ambiance. Maintenant tu es coincé.

Vous avez construit quelque chose de réel. Vous avez ouvert Lovable ou Bolt.new, décrit votre idée dans un anglais simple et vu une application fonctionnelle apparaître en quelques minutes. Vous avez cliqué sur les écrans. Vous l'avez montré à des amis. Vous l'avez posté sur X et avez reçu vos premières réponses "c'est malade". C'est impressionnant et vous devriez vous sentir bien.

Mais maintenant, cela fait trois semaines et l'élan s'est arrêté. Vous passez plus de temps à réparer les fonctionnalités défectueuses qu’à en créer de nouvelles. Votre tableau de bord Supabase contient des tableaux que vous ne comprenez pas entièrement. Votre authentification fonctionne sur ordinateur mais échoue sur mobile. Vous avez besoin de l'intégration de Stripe, et chaque invite que vous essayez produit un code qui entre en conflit avec ce qui existe déjà.

Vous avez heurté le mur. Et vous n'êtes pas seul.

Le mur 80/20 : là où le vibe coding s'effondre

Les outils de codage Vibe comme Lovable, Bolt.new, Replit Agent et v0 sont extraordinaires dans les premiers 80 % d'un produit. Ils génèrent des composants d’interface utilisateur, connectent des bases de données, créent des flux d’authentification et produisent quelque chose qui ressemble à une véritable application. Pour le prototypage et la validation, il s'agit du chemin le plus rapide qui ait jamais existé entre l'idée et la démonstration.

Le problème, ce sont les 20 % restants. C'est là que vivent les cas extrêmes. C’est là que le traitement des paiements doit gérer les échecs de paiement, les remboursements partiels et les tentatives de webhook. C'est là que votre formulaire en plusieurs étapes doit enregistrer la progression, valider toutes les étapes et récupérer après un crash du navigateur. C'est là que votre application doit fonctionner lorsque deux utilisateurs modifient le même enregistrement en même temps.

L’IA gère le chemin du bonheur avec brio. Il se bat avec les chemins malheureux, et les logiciels de production sont à 80 % des chemins malheureux. Que se passe-t-il lorsque le réseau s'interrompt en cours de transaction ? Lorsqu'un utilisateur soumet un formulaire deux fois ? Lorsque votre requête de base de données renvoie 50 000 lignes au lieu de 50 ? Ce sont les questions qui séparent une démo d’un produit, et ce sont les questions auxquelles les outils de codage d’ambiance ne peuvent pas répondre à partir d’une seule invite.

Les développeurs appellent cela le mur 80/20. Les premiers 80 % représentent 20 % de l'effort. Les 20 % restants représentent 80 % de l’effort. Les outils de codage Vibe compressent ces premiers 80 % de quelques semaines à quelques heures. Mais ils ne compressent pas du tout les 20 % restants. Ils rendent les choses plus difficiles, car le code qu'ils ont généré n'a pas été conçu pour le gérer.

Le problème de sécurité dont personne ne parle

Voici la partie qui devrait vous empêcher de dormir la nuit. Une analyse de sécurité des applications générées par Lovable a révélé que10,3 % présentaient des failles critiques de sécurité au niveau des lignes (RLS)dans leurs bases de données Supabase. Cela signifie qu'une application sur dix disposait de tables de base de données dans lesquelles tout utilisateur authentifié pouvait lire, modifier ou supprimer les données des autres utilisateurs. Pas un risque théorique. Un exploit fonctionnel.

Cela ne se limite pas à Lovable. Une analyse CodeRabbit de 470 pull request a révélé que le code généré par l'IA aTaux de vulnérabilité de sécurité 2,74 fois plus élevéspar rapport au code écrit par l'homme. La même analyse a trouvé1,7 fois plus de problèmes majeursdans l'ensemble. L'IA écrit du code qui fonctionne. Il n'écrit pas de code sûr.

Les conséquences concrètes sont déjà là. Moltbook, un réseau social construit par l'IA, lancé avec sa base de données Supabase accessible au public. Le résultat :1,5 million de clés API et 35 000 e-mails d'utilisateurs exposés. Un audit indépendant a révélé que11 % des URL de lancement indépendantes exposent les informations d'identification Supabase dans leur code frontend. Ce ne sont pas des cas extrêmes. Ce sont des modèles.

Les outils de codage Vibe ne vous expliquent pas la sécurité parce que vous n'avez pas posé de questions sur la sécurité. Vous avez demandé un formulaire d’inscription d’utilisateur et vous en avez obtenu un. Vous n'avez pas demandé « assurez-vous que les utilisateurs ne peuvent pas accéder aux données des autres via des appels API directs », donc l'outil n'a pas configuré cela. Politiques RLS, portée des clés API, nettoyage des entrées, limitation du débit ; ce sont des éléments que les ingénieurs expérimentés ajoutent par défaut car ils ont vu ce qui se passe lorsque vous ne le faites pas.

Le piège du crédit

Les outils de codage Vibe facturent par crédits, jetons ou temps de calcul. Le pitch est simple : décrivez ce que vous voulez, obtenez du code fonctionnel, itérez. La réalité est différente.

Rapport sur les utilisateurs adorablesbrûler 400 crédits en moins d'une heurelors du débogage d’une fonctionnalité complexe. Les utilisateurs de Bolt.new décrivent s'être fait prendreboucles d'erreur sans finoù l'IA casse une chose tout en en réparant une autre. Sur toutes les plateformes, les utilisateurs déclarent leurs dépenses30 à 40 % de leurs invites corrigent les problèmes cassés par l'IAdans les invites précédentes.

Pensez à ce ratio. Pour trois invites faisant avancer votre produit, une ou deux invites servent à réparer les dommages. Vous payez pour progresser et payez encore pour nettoyer les dégâts. L’outil qui était censé vous faire économiser de l’argent est désormais un coût récurrent aux rendements décroissants.

La consommation de crédit s'accélère à mesure que votre base de code se développe. Il est facile pour l’IA de raisonner sur une application de 500 lignes. Une application de 5 000 lignes avec plusieurs pages, un état partagé, des routes API et des migrations de bases de données ne l'est pas. L'IA commence à perdre son contexte. Il réécrit les composants que vous avez déjà corrigés. Il introduit des modèles qui entrent en conflit avec les modèles utilisés il y a trois invites. Vous dépensez plus de crédits pour moins de progrès, et l’écart se creuse à chaque séance.

La spirale de la qualité du code

Les bases de code générées par l’IA partagent un ensemble spécifique de problèmes qui s’aggravent avec le temps.

Duplication de codes.L'analyse des projets codés par ambiance montre unAugmentation de 8x de la duplication de codepar rapport aux projets d’ingénierie humaine. L'IA ne se souvient pas qu'elle a déjà écrit une fonction de formatage de date il y a trois fichiers. Il en écrit un nouveau. Puis un autre. Puis un légèrement différent. Vous disposez désormais de quatre formateurs de date, chacun avec un comportement différent, et modifier l'affichage de la date dans votre application signifie rechercher et mettre à jour les quatre.

Des modèles incohérents.Le développement invite par invite produit du code sans cohérence architecturale. Une page récupère les données dans un hook useEffect. Un autre utilise le rendu côté serveur. Un troisième appelle l'API directement depuis un gestionnaire onClick. Aucune de ces approches n'est mauvaise isolément, mais le mélange des trois dans une seule application crée une base de code sur laquelle personne ne peut raisonner ; pas l'IA, ni un développeur humain que vous embaucherez plus tard.

Gestion des erreurs manquante.Le code généré par l’IA gère le cas de réussite. Il restitue les données lorsque l'API renvoie 200. Il ne gère pas ce qui se passe lorsque l'API renvoie 500, expire ou renvoie un JSON mal formé. Les utilisateurs de production déclenchent quotidiennement ces modes de défaillance. Sans gestion des erreurs, votre application affiche des écrans vides, des compteurs infinis ou des messages d'erreur énigmatiques qui renvoient les utilisateurs directement à votre concurrent.

Aucun test.Les outils de codage Vibe génèrent rarement des tests, sauf si vous le demandez spécifiquement. Et lorsque vous le demandez, les tests ont tendance à vérifier que le code fait ce qu'il fait (tests tautologiques) plutôt que de tester la logique métier et les cas extrêmes. Lorsque vous devez modifier une fonctionnalité ultérieurement, vous n’avez aucun filet de sécurité. Chaque changement est un pari.

Ces problèmes s’aggravent. Le code dupliqué rend les bogues plus difficiles à trouver. Des modèles incohérents rendent les changements risqués. La gestion des erreurs manquantes crée des échecs face à l’utilisateur. Aucun test ne signifie que vous ne pouvez pas refactoriser en toute sécurité. Chaque problème amplifie les autres jusqu'à ce que la base de code atteigne un point où les agences estiment qu'il fautplus de temps pour corriger le code d'ambiance existant que pour repartir de zéro.

Quand arrêter le vibe coding et embaucher des ingénieurs

Tous les projets codés par ambiance n’ont pas besoin d’être sauvés. Certains prototypes valident une idée et sont jetés. C'est très bien. Mais si votre réponse est « oui » à trois de ces questions ou plus, il est temps de faire appel à des ingénieurs :

• Vous passez plus de temps à déboguer qu'à créer de nouvelles fonctionnalités
• Vous gérez des données utilisateur réelles (e-mails, paiements, informations personnelles)
• Vous avez besoin d'un traitement de paiement, d'une facturation d'abonnement ou de transactions financières
• Votre application doit fonctionner de manière fiable pour plus de 100 utilisateurs simultanés
• Vous intégrez des API tierces qui nécessitent des webhooks ou OAuth
• Vous avez épuisé votre budget de crédit deux fois et votre liste de fonctionnalités n'a pas changé
• Vous ne pouvez pas répondre avec assurance : « qui peut accéder à ces données ? » pour chaque table de votre base de données
• Vous envisagez de lever des fonds et les investisseurs vous poseront des questions sur votre architecture technique
• Vous avez rencontré un bug que vous ne pouvez pas corriger après plus de 20 invites

Le point de transition n’est pas une question d’échec. Il s’agit de reconnaître où les outils d’IA cessent d’être le bon outil et où les ingénieurs expérimentés commencent à être le bon outil. Un fondateur qui a codé un MVP et validé la demande a fait quelque chose que la plupart des conseils de startup vous disent de faire : expédier vite, apprendre vite. La prochaine étape consiste à transformer ce prototype validé en logiciel de production.

Ce qu'une agence fait différemment

Une réaction courante face au mur 80/20 est : « J'apprendrai à coder et à le réparer moi-même ». Respectez cette énergie, mais considérez les mathématiques. Apprendre suffisamment de React, de conception de bases de données, d'authentification et de déploiement pour terminer une application de production prend 6 à 12 mois d'étude ciblée. L'embauche d'un ingénieur senior pour terminer cela prend 3 à 6 semaines. Si votre startup dispose d'une fenêtre de marché, le parcours d'apprentissage de 6 mois ferme cette fenêtre.

Chez Savi, nos ingénieurs seniors utilisent également des outils d'IA. Nous utilisons quotidiennement Cursor, Claude et Copilot. La différence est que nous les utilisons comme accélérateurs en plus de 5 à 10 ans d’expérience en ingénierie, et non comme des substituts. Nous savons quoi demander et, plus important encore, quoi vérifier dans le résultat. Nous détectons les erreurs de configuration RLS, les limites d'erreur manquantes, les vecteurs d'injection SQL et les conditions de concurrence avant qu'ils n'atteignent vos utilisateurs.

Voici à quoi ressemble le processus lorsqu'un fondateur nous apporte un prototype codé en ambiance :

Audit (1-2 jours).Nous examinons votre base de code, votre schéma de base de données et votre infrastructure existants. Nous identifions les vulnérabilités de sécurité, les problèmes architecturaux et le code à remplacer. Nous vous donnons une évaluation honnête : cela peut-il être résolu ou devons-nous repartir à zéro ? Parfois, une application codée en ambiance possède des composants d'interface utilisateur solides et un schéma de base de données raisonnable, et nous pouvons construire dessus. D’autres fois, la fondation présente trop de problèmes structurels et commencer à nettoyer est plus rapide et moins cher.

Architecture (2-3 jours).Nous concevons l'architecture de production. Schéma de base de données avec index appropriés, politiques RLS et stratégie de migration. Couche API avec authentification, limitation de débit et gestion des erreurs. Structure frontale avec des modèles de récupération de données, une gestion de l'état et une organisation des composants cohérents. C'est l'aspect que les outils de codage d'ambiance de travail ignorent complètement.

Construire (2-5 semaines).Nous écrivons du code de production. Chaque fonctionnalité bénéficie d'une gestion des erreurs, des états de chargement et d'une couverture des cas extrêmes. Chaque table de base de données obtient des politiques RLS. Chaque route API obtient une validation d'entrée. Nous écrivons des tests pour la logique métier. Nous mettons en place des pipelines CI/CD qui détectent les régressions avant le déploiement. Vous parlez directement à l'ingénieur qui construit votre produit ; pas de chefs de projet relayant des messages, pas d'appels de statut hebdomadaires qui auraient pu être un message Slack.

Lancement et transfert.Nous déployons en production, surveillons les problèmes la première semaine et vous remettons une base de code avec une documentation que vous pouvez apporter à n'importe quel ingénieur dans le monde. Pas de dépendance envers un fournisseur. Pas de framework propriétaire. Des outils standards, du code propre, votre référentiel, votre infrastructure.

Nous proposons des devis à prix fixe. Vous connaissez le coût avant d’écrire une ligne de code. Pas de facturation horaire qui gonfle lorsque le débogage prend plus de temps que prévu. Aucun supplément de « demande de modification » lorsque vous clarifiez une fonctionnalité en cours de construction.

Le prototype a été la partie la plus difficile. La finition est la partie intelligente.

Vous avez fait quelque chose que la plupart des gens ne font jamais : vous avez pris une idée, ouvert un outil et construit quelque chose que vous pouviez montrer à de vraies personnes. Ce prototype a prouvé que votre idée avait du sens. Cela a prouvé que vous aviez le goût et la volonté de créer un produit.

La prochaine étape n’est pas plus invitante. C'est de l'ingénierie. Ce sont le renforcement de la sécurité, la gestion des cas extrêmes, l'optimisation des performances et les décisions d'infrastructure qui transforment un prototype en logiciel pour lequel les gens paient et font confiance à leurs données.

Vous n'avez pas besoin de devenir ingénieur pour créer une entreprise de logiciels. Vous devez en embaucher quelqu’un qui sait quand utiliser l’IA et quand écrire le code à la main. C'est la différence entre une démo et un produit.

Questions fréquemment posées