Le piège des 80-20 du vibecoding (et comment en sortir)

L'IA génère les premiers 80 % d'une app à une vitesse déconcertante : structure du projet, CRUD, écrans standards, formulaires, navigation. Les 20 % restants — gestion fine des erreurs, performances sous charge, cas limites, cohérence d'architecture — résistent aux prompts. Et ce sont eux qui décident si ton projet devient un produit utilisé ou reste une belle démo.

La bonne nouvelle : franchir ces 20 % ne demande pas dix ans de métier. Ça demande une méthode. La voici en résumé :

découpe le travail en petites tâches fermées, vérifiables une par une ;
fige tes interfaces et tes contrats de données avant de générer le code qui s'y branche ;
écris des tests sur les chemins critiques (argent, données, authentification) ;
fais une seule demande à la fois à l'IA ;
relis toi-même tout ce qui touche à l'argent, aux données et à l'auth.

La suite explique pourquoi ces 20 % coincent, ce qu'est la « dette technique instantanée », ce que l'expérience publique de Pieter Levels nous apprend, et comment appliquer la méthode dès aujourd'hui.

Pourquoi les premiers 80 % vont si vite

Un CRUD, un formulaire de connexion, une liste paginée, un dashboard : ces motifs, les modèles d'IA les ont vus sous toutes les formes pendant leur entraînement. Tu décris, ils assemblent.

Résultat : en un week-end, tu as une app qui ressemble à un produit. Écrans propres, base de données branchée, navigation fluide. Ce n'est pas une illusion — ça fonctionne vraiment.

Le piège est là : cette vitesse initiale te fait croire que la fin du projet ira au même rythme. Elle n'ira pas. Les 20 % restants ne sont pas « plus de la même chose ». Ce sont des problèmes d'une autre nature.

Les 20 % qui résistent aux prompts

Quatre familles de problèmes reviennent systématiquement :

La gestion fine des erreurs. Que se passe-t-il quand l'API de paiement ne répond pas ? Quand deux personnes modifient la même donnée en même temps ? Le code généré gère le cas nominal ; la production est faite de cas non nominaux.
Les performances sous charge. La requête instantanée avec cinquante lignes de test peut s'écrouler face aux données réelles. Rien ne te prévient tant que le vrai trafic n'arrive pas.
Les cas limites. L'utilisateur qui double-clique sur « Payer ». Le fichier énorme. Le nom avec un emoji. Chacun est trivial isolément ; leur somme fait la robustesse.
La cohérence d'architecture. Chaque prompt produit du code localement correct mais globalement incohérent : trois façons de gérer les erreurs, deux conventions de nommage, des logiques dupliquées.

Le point commun : aucun de ces problèmes n'est visible dans une démo. Et tous exigent une vision d'ensemble du projet — précisément ce que l'IA perd quand le code grossit.

La dette technique instantanée

La dette technique, classiquement, s'accumule sur des années : raccourcis pris sous pression, code hérité de gens partis, conventions qui dérivent. Le vibecoding compresse ce cycle. Un code généré en une semaine peut présenter les problèmes de maintenance d'un vieux système hérité : logique dupliquée, conventions incohérentes, dépendances que personne ne maîtrise, zéro test.

C'est la dette technique instantanée. Elle ne vient pas d'une IA « qui code mal ». Elle vient du fait que chaque génération repart de ce que le modèle voit dans son contexte à cet instant — pas de la vision globale que tu as en tête. Sans garde-fous, chaque prompt ajoute une couche légèrement différente de la précédente.

Conséquence pratique : la difficulté d'un projet vibecodé ne se mesure pas au temps passé, mais au nombre de couches générées sans contrat commun.

Ce que montre fly.pieter.com

Pieter Levels a créé un simulateur de vol, fly.pieter.com, presque entièrement par prompts. Il a documenté publiquement le résultat : environ 38 000 $ de revenus en dix jours. Preuve que le vibecoding fonctionne, y compris commercialement.

Mais Levels a documenté l'autre face avec la même transparence : au-delà d'environ 800 lignes de code, son IA réintroduisait des bugs déjà corrigés et oubliait des contraintes posées plus tôt, la fenêtre de contexte saturant.

C'est exactement le mur des 20 %. L'outil qui t'amène à la démo en quelques jours commence à défaire ton propre travail à mesure que tu approches de la production. Le problème n'est ni toi ni ton prompt : c'est une limite structurelle, qu'on contourne par la méthode. (Sur le passage démo → production, voir aussi Du proto au produit.)

La méthode pour franchir les 20 %

Cinq règles, dans l'ordre.

1. Découpe en petites tâches fermées. « Ajoute un retry avec backoff sur l'appel Stripe, et loggue chaque échec » plutôt que « rends l'app plus fiable ». Une tâche fermée a un périmètre, une fin, et un critère de réussite que tu peux vérifier toi-même.

2. Fige les interfaces avant de générer. Écris — ou fais écrire, puis valide — tes contrats : types, schémas de données, signatures de fonctions. Ensuite seulement, demande le code qui les implémente.

// Contrat figé AVANT de générer l'implémentation
interface PaymentResult {
  status: "paid" | "failed" | "pending";
  orderId: string;
  failureReason?: string;
}

Un contrat figé est un point d'ancrage que l'IA ne peut pas « oublier » : tu le recolles dans chaque prompt concerné, et tout code qui le viole est refusé.

3. Écris des tests sur les chemins critiques. Pas besoin de viser 100 % de couverture. Cible les chemins qui touchent l'argent, les données et l'auth. Un test qui passe est une contrainte que l'IA ne peut plus casser sans que tu le voies immédiatement. Pour la démarche complète, voir Tester une app vibecodée.

4. Une seule demande à la fois. Les prompts fourre-tout (« corrige le bug, ajoute la feature et améliore le design ») produisent du code fourre-tout. Une demande, une vérification, un commit. Tu sais toujours quel changement a produit quel effet.

5. Relis ce qui touche argent, données, auth. Tu n'es pas obligé de tout relire. Mais ces trois zones-là, oui, ligne par ligne. Si une ligne t'échappe, demande à l'IA de l'expliquer, puis de la simplifier jusqu'à ce qu'elle soit évidente.

Par où commencer aujourd'hui

Concrètement, dans l'ordre, sur ton projet actuel :

Liste les trois chemins critiques de ton app (paiement, données utilisateur, connexion).
Écris ou fais générer un test pour chacun, et vérifie qu'ils passent.
Extrais tes contrats existants (types, schémas) dans un fichier de référence que tu recolles dans tes prompts.
Reformule ta prochaine grosse demande à l'IA en trois tâches fermées ou plus.
Relis intégralement le code qui touche à l'argent — aujourd'hui, pas « bientôt ».
Adopte le rythme : une demande, une vérification, un commit.

Les 80 % t'ont prouvé que tu peux construire. Les 20 % te prouvent que tu peux livrer. C'est plus lent, plus exigeant — et c'est là que ton projet se joue.