Le problème des 70 % : pourquoi votre app générée par IA plafonne, et comment mesurer ce qui reste

Le premier week-end avec Lovable, Bolt ou v0 donne une impression de vitesse rare : des écrans, une connexion, une base de données, un tableau de bord qui ressemble à un vrai produit. Puis la progression ralentit. Chaque demande prend plus de temps, chaque correction en casse une autre, et l’application semble toujours à deux prompts d’être terminée sans jamais l’être.

Ce ralentissement a un nom dans la communauté des développeurs : le « problème des 70 % ». L’expression circule beaucoup, souvent déformée. Cet article remonte à sa source, explique pourquoi l’outil plafonne à cet endroit précis, et surtout vous donne une méthode pour estimer ce qui reste sur votre application, avant de choisir quoi faire. La liste détaillée de ce qu’on corrige dans le code est dans un autre article, ce qu’il faut reprendre sur un MVP codé par IA ; ici, on parle de l’écart, de sa forme et de sa taille.

D’où vient l’expression

Elle vient d’Addy Osmani, ingénieur chez Google, dans un essai publié le 4 décembre 2024 sur sa newsletter : « The 70% problem: Hard truths about AI-assisted coding » (consulté en octobre 2026). Le constat tient en une phrase : les non-développeurs arrivent à 70 % « surprisingly quickly », puis les 30 % restants deviennent « an exercise in diminishing returns », un exercice à rendements décroissants.

Trois points de l’essai sont souvent oubliés quand on le cite.

Il vise nommément les outils de démarrage. Osmani range Bolt et v0 parmi les outils qui transforment la façon de lancer un projet, et raconte avoir vu un développeur passer d’une maquette Figma à une application web en très peu de temps avec Bolt. Lovable n’est pas cité, mais il appartient à la même famille.

Il décrit une boucle, pas un mur. Il appelle ce schéma « two steps back » : on corrige un petit bug, l’IA propose une modification raisonnable, cette modification casse autre chose, on demande de corriger le nouveau problème, et cela en crée deux autres. Sans connaissances de développement, écrit-il, on joue au « whack-a-mole » avec du code qu’on ne comprend pas entièrement.

Il définit les 30 % par leur fonction. Ce n’est pas un reste de fonctionnalités : c’est la partie qui rend un logiciel « production-ready, maintainable, and robust », et qui demande encore de vraies connaissances d’ingénierie. Dans la partie qu’il consacre au piège de la « qualité démo », il cite les messages d’erreur incompréhensibles pour un utilisateur normal, les cas limites qui font planter l’application, l’accessibilité oubliée, les lenteurs sur les appareils modestes.

Osmani a repris le sujet depuis sur son site, dans une fiche de son glossaire « agentic engineering » (consultée en octobre 2026). Il y ajoute deux nuances utiles. De meilleurs prompts, spécifications et contexte peuvent faire passer l’outil de 70 % à « maybe 80-85% », mais combler tout l’écart demande un jugement humain. Et pour un prototype, les 70 % peuvent suffire : le problème concerne le code qu’on met en production.

L’idée n’est pas neuve. La « règle des 90-90 », attribuée à Tom Cargill des Bell Labs et publiée par Jon Bentley dans sa chronique Programming Pearls des Communications of the ACM en septembre 1985, disait déjà que les derniers 10 % du code prennent autant de temps que les 90 premiers. Ce que l’IA change, c’est la vitesse à laquelle on arrive au point où le reste commence.

Un dernier avertissement : 70 % n’est pas une mesure. Personne n’a chronométré le pourcentage d’une application terminé par un outil. C’est une image, et sa valeur est de rappeler que le travail restant n’est pas proportionnel à ce que vous voyez à l’écran.

Pourquoi l’outil plafonne à cet endroit

Le plafond n’est pas un hasard, et il n’est pas seulement dû à la qualité du modèle. Il tient à la façon dont vous travaillez avec l’outil.

Les 70 % se voient, les 30 % ne se voient pas. Un écran, un bouton, un formulaire : vous pouvez les demander, les regarder et juger qu’ils sont finis. Une règle d’accès, un paiement qui échoue, un e-mail filtré comme indésirable, une requête qui ralentit à dix mille lignes : rien de cela n’apparaît dans l’aperçu. L’outil progresse vite sur ce que vous pouvez évaluer d’un coup d’œil, et le reste attend.

On ne demande que ce qu’on sait nommer. Un prompt décrit ce que l’application doit faire quand tout va bien. Les 30 % décrivent ce qu’elle doit faire quand quelque chose va mal, et la liste de ces situations n’est écrite nulle part tant que personne ne l’a dressée. L’outil ne sait pas que votre client B2B aura deux administrateurs qui modifient la même fiche au même moment. Vous non plus, tant que ce n’est pas arrivé.

La démonstration ne teste qu’un chemin. Vous testez avec votre compte, vos données, votre connexion fibre et votre navigateur. Les cas limites, par définition, arrivent avec les comptes, les données et les appareils des autres.

Chaque prompt peut défaire le précédent. Plus l’application grandit, plus une modification locale a de chances de toucher une règle posée ailleurs. C’est la boucle « two steps back » : le coût d’une correction augmente avec la taille du projet, alors que le coût d’un nouvel écran reste à peu près constant.

Vérifier devient le travail. Sur la fiche de son glossaire, Osmani résume le déplacement : le métier passe d’écrire du code à l’évaluer. Pour un founder qui ne lit pas le code, c’est précisément l’étape qu’il ne peut pas faire seul, et c’est là que la progression s’arrête.

De quoi sont faits les 30 %

Voici les dix familles de travail qu’on retrouve dans l’écart. La colonne de droite est la plus importante : c’est ce qui vous permet de savoir, sans lire le code, si la famille est traitée sur votre application.

Deux remarques sur ce tableau.

Les familles ne pèsent pas le même poids. Une faille de permission expose les données de vos clients dès le premier jour ; une lenteur sur mobile vous coûte des inscriptions. Les permissions ont leur propre méthode de vérification dans notre check-list de sécurité Lovable et Supabase, et les e-mails, paiements, sauvegardes et supervision dans la check-list de mise en production.

Pour les paiements, Stripe publie des numéros de carte de test qui simulent les situations difficiles, par exemple 4000 0000 0000 0002 pour un refus générique ou 4000 0025 0000 3155 pour une carte qui exige une authentification (vérifié en octobre 2026). Si votre application ne sait pas quoi faire de ces deux cartes en mode test, la famille « paiements » n’est pas traitée.

Estimer l’écart sur votre application

Le pourcentage d’Osmani est une image ; sur votre application, il faut une mesure. Elle ne vous donnera pas un nombre de jours, mais elle vous dira où est l’écart, s’il est concentré ou diffus, et ce qui bloque l’ouverture.

Étape 1 : lister les parcours qui comptent

Ne partez pas des écrans, partez de ce qui fait vivre le produit. Trois à six parcours suffisent en général : l’inscription, l’action principale pour laquelle on vous paie, le paiement, l’invitation d’un collègue si vous vendez à des équipes, l’export ou la suppression des données.

Étape 2 : noter chaque parcours sur les dix familles

Pour chaque croisement d’un parcours et d’une famille, une note sur trois niveaux :

• 0 : absent, ou vous ne savez pas ;
• 1 : fonctionne dans le cas normal, constaté à la main ;
• 2 : vérifié dans les cas difficiles, et rejouable sans vous (un test automatisé, une alerte qui se déclenche).

« Je ne sais pas » vaut 0. C’est la règle la plus importante de la grille : une case inconnue est une case à traiter, ne serait-ce que pour la vérifier.

Parcours          Cas  Err  Perm  Don  Perf  Paie  Mail  Test  Obs  Maint
Inscription        1    0    1     -    1     -     1     0     0    0
Action principale  1    0    0     0    1     -     -     0     0    0
Paiement           1    0    1     -    1     1     0     0     0    0
Invitation         0    0    0     -    1     -     1     0     0    0

Le tiret marque une famille sans objet pour ce parcours. L’exemple est fictif ; il montre l’allure typique d’une application sortie d’un générateur : des 1 sur ce qui se voit, des 0 sur tout ce qui ne se voit pas.

Étape 3 : lire la grille

Trois lectures, dans cet ordre.

Les zéros bloquants. Un 0 en permissions, en paiements ou en données réelles sur un parcours qui manipule des données clients bloque l’ouverture, quel que soit le reste. Cette colonne décide de la date de lancement.

La forme de l’écart. Si les zéros sont concentrés sur une ou deux familles, par exemple e-mails et observabilité, l’écart est un chantier délimité. S’ils sont répartis partout, et surtout si les colonnes tests, observabilité et maintenance sont entièrement à 0, chaque correction future coûtera plus cher, parce que personne ne pourra vérifier qu’elle ne casse rien.

Les colonnes à 0 de haut en bas. Une famille absente de tous les parcours n’est pas un oubli local : c’est une fondation qui manque, et elle se pose une fois pour toute l’application.

Étape 4 : repérer les signaux qui agrandissent l’écart

Certains symptômes ne se notent pas dans une case, mais ils changent la taille de tout le reste :

• vous êtes déjà dans la boucle « two steps back » : une correction sur deux en casse une autre ;
• le code n’est pas synchronisé dans un dépôt Git à votre nom ;
• vous ne savez pas dire où est vérifiée une règle métier importante, par exemple qui a le droit de supprimer une fiche ;
• des clés secrètes ont déjà été collées dans un prompt ou dans le code ;
• l’application a changé de modèle de données en cours de route, et des tables anciennes traînent encore ;
• vous ne savez pas sur quelle base technique repose votre projet. Pour Lovable, par exemple, les projets créés depuis le 13 mai 2026 génèrent du TanStack Start, les plus anciens restent en React et Vite, et cela change où vit la logique serveur.

Chaque case cochée signifie que l’écart mesuré par la grille est probablement sous-estimé.

Ce que la grille ne fait pas

Elle ne convertit pas l’écart en jours. Un 0 en permissions peut se corriger en une règle bien placée ou demander de revoir le modèle de données, si l’application n’a jamais eu de notion d’organisation alors que vous vendez à des entreprises. Les deux situations produisent la même case. Seule la lecture du code et de la base les distingue, et c’est pourquoi aucun chiffrage honnête ne se fait à partir d’une démo. Ce qui fait varier ce chiffrage est détaillé dans ce que coûte la reprise d’une app Lovable, Bolt ou v0.

Les options qui s’offrent à vous

La grille remplie, cinq options sont réalistes. Aucune n’est la bonne par défaut.

Rester volontairement à 70 %

Si l’application sert à valider une idée, à montrer un parcours à des prospects ou à lever des fonds sur une démonstration, les 70 % suffisent souvent. Osmani le dit lui-même : le problème concerne la production. La condition est de ne pas y faire entrer de vraies données clients ni de vrais paiements, et de le décider plutôt que de le subir.

Continuer avec l’outil, avec méthode

Si l’écart est concentré sur quelques familles, sans zéro bloquant en permissions ni en paiements, vous pouvez le réduire vous-même. Traitez une famille à la fois, demandez un cas difficile par prompt, testez après chaque modification, et gardez le code dans Git pour pouvoir revenir en arrière. Les conseils d’Osmani vont dans ce sens, mais l’un d’eux, « Review every line of generated code », suppose de savoir lire le code. Si ce n’est pas votre cas, c’est cette relecture-là qui vous manque, pas un meilleur prompt.

Ajouter un développeur à côté de l’outil

Un développeur qui connaît la stack peut prendre les familles invisibles, permissions, paiements, tests, pendant que vous continuez à faire évoluer l’interface. Cela demande de convenir de qui modifie quoi, pour qu’une nouvelle génération ne défasse pas une correction. Les critères pour choisir entre continuer seul, un freelance ou un studio sont dans cet article dédié.

Faire auditer, puis reprendre

Si la grille montre des zéros bloquants, des colonnes entières à 0 ou plusieurs signaux cochés, la priorité est de savoir ce que vaut le code avant d’y investir davantage. C’est l’objet de notre audit de reprise d’application Lovable, Bolt ou v0 : un forfait, un verdict écrit sous 48 h, garder et renforcer ou refaire, et ce qui manque pour la production, poste par poste. Nous l’avons construit à partir d’une douzaine d’applications générées par IA reprises et mises en production, dont une application RH et une messagerie chiffrée interne d’entreprise où il a fallu corriger de nombreuses failles de sécurité.

Refaire les fondations sous l’interface

Quand le modèle de données ne correspond plus au produit, ou que chaque correction en déclenche d’autres, refaire coûte parfois moins cher que réparer. On ne repart pas de zéro pour autant : les écrans, le parcours validé par vos utilisateurs et ce que vous avez appris se gardent. Ce sont les 30 % qu’on reconstruit, pas les 70 %.

Ce qu’il faut retenir

Le problème des 70 % n’est pas une limite technique qui disparaîtra au prochain modèle. Son auteur lui-même estime qu’un meilleur cadrage repousse le plafond sans le supprimer. C’est une différence de nature entre ce qu’on voit en démo et ce qu’exige un service ouvert à des clients : les cas limites, les erreurs, les droits, les données, l’argent, les e-mails, les tests, la supervision et la maintenance.

La prochaine action ne demande aucune compétence technique : listez vos parcours, remplissez la grille, et regardez la colonne des permissions. Si elle contient un 0 sur un parcours qui touche des données clients, vous savez par quoi commencer, et vous savez que la date d’ouverture en dépend.