L'IA couvre les 70 % faciles d'un projet à grande vitesse, mais les 30 % finaux — cas limites, gestion des erreurs, architecture, robustesse — continuent d'exiger un jugement humain et décident si le logiciel survit en production. La leçon : l'IA effondre le coût de commencer, pas celui de terminer.
Il y a un moment magique et traître dans chaque projet construit avec l'IA : il est vingt-trois heures, tu lui as demandé une app, et en vingt minutes tu as quelque chose qui fonctionne, qui a fière allure et qui semble même terminé. Tu as l'impression d'avoir gagné. Le lendemain tu essaies de lui faire gérer un utilisateur qui fait quelque chose de bizarre, un paiement qui échoue à mi-parcours, une donnée vide, deux personnes appuyant sur le même bouton, et la magie se transforme en marécage. Bienvenue dans le problème des 70 % : le phénomène le mieux documenté — et le moins avoué — de l'ère du code assisté par l'IA. L'IA t'offre 70 % du chemin à une vitesse qui tient de la sorcellerie, puis elle te lâche la main pile dans les 30 % qui décident si ton logiciel est un jouet ou un produit.
Qui l'a nommé et pourquoi le chiffre compte
Le nom n'est pas de nous. Addy Osmani, ingénieur chez Google, l'a baptisé « le problème des 70 % » après avoir observé motif après motif chez des gens construisant avec l'IA. Sa thèse est d'une précision inconfortable : l'IA couvre sans peine la partie balisée et prévisible d'un projet — le scaffolding, le CRUD, le bel écran, ce qu'elle a vu un million de fois durant son entraînement — mais les 30 % restants continuent d'exiger un jugement d'ingénieur senior. Ces 30 % ne sont pas davantage de code : c'est une autre nature de travail. Ce sont les cas limites que personne n'a demandés, la gestion des erreurs qui ne compte que lorsque quelque chose casse, les décisions architecturales qui ne se voient pas mais soutiennent tout, la robustesse qui sépare la démo du déploiement. Et l'observation la plus tranchante d'Osmani porte sur qui survit là-dedans : les seniors modèlent et bornent la sortie de l'IA comme on taille un arbre ; les débutants restent piégés dans une boucle infinie de débogage, demandant à la machine de réparer un bug qu'ils ne comprennent pas, générant trois nouveaux bugs pour chacun qu'ils colmatent.
Le poisson et la canne : pourquoi les 30 % sont d'une autre matière
La meilleure façon de le comprendre, c'est une vieille image retournée. L'IA ne t'apprend pas à pêcher ; elle te livre le poisson déjà cuit, servi, avec la table mise. C'est un festin instantané. Le problème, c'est que la production n'est pas un dîner : c'est une tempête en haute mer. Et quand le filet se déchire, quand le moteur lâche, quand l'eau entre par un côté que personne n'avait prévu, tu n'as pas besoin de plus de poisson — tu as besoin de savoir pêcher. Ce savoir, ce sont les 30 %. Il ne se génère pas, il s'exerce. Voilà pourquoi le senior et le débutant vivent le même moment de façons opposées : pour le senior, les 70 % de l'IA sont un brouillon rapide sur lequel il applique son jugement ; pour le débutant, ces mêmes 70 % sont une boîte noire qui fonctionne presque, et « fonctionne presque » en logiciel est l'endroit le plus dangereux du monde, parce qu'il paraît terminé et ne l'est pas.
Pourquoi la démo brille et la production trébuche
Ici se noue quelque chose que nous disons depuis un moment. Le vibe coding — construire au pur instinct conversationnel avec l'IA — est spectaculaire en démo précisément parce que la démo vit dans les 70 % : le chemin heureux, l'utilisateur qui fait exactement ce que tu attendais, les données propres. La production, c'est l'inverse : ce sont les 30 % multipliés par des milliers d'utilisateurs réels faisant des choses que tu n'as jamais imaginées. Nous avions déjà mis des chiffres sur l'écart entre la démo et la réalité dans notre essai sur les mathématiques des 27 % — de combien la performance s'effondre entre le laboratoire et le monde — ; le problème des 70 % est l'autre face de la même pièce, vue depuis le côté de la construction plutôt que de la performance. L'un mesure de combien l'IA chute en sortant du laboratoire ; l'autre explique exactement à quel endroit du travail elle chute. Les deux pointent le même abîme : la distance entre « ça marche sur mon écran » et « ça tient dans le monde ».
Ce qu'Osmani propose vraiment (et ce qu'il ne propose pas)
Il convient d'être honnête avec la source, car sur internet on attribue à Osmani des remèdes qu'il n'a pas prescrits. Sa réponse au problème des 70 % n'est pas une méthodologie rigide de spécifications en amont ; c'est une poignée d'habitudes de cohabitation avec l'IA. La première, traiter la sortie de l'IA comme un « premier brouillon », jamais comme la version finale. La deuxième, la « conversation constante » : itérer dans le dialogue, corriger le cap tour après tour au lieu d'accepter le premier output. Et la troisième, celle qui résume tout : « fais confiance mais vérifie ». Fais confiance à la vitesse des 70 %, mais vérifie chaque centimètre des 30 %, car c'est là que l'IA est à la fois la plus convaincante et la plus erronée. Si tu cherches une discipline plus formelle de spécifier avant de générer, elle existe — Spec Kit et le spec-driven development vont dans ce sens — mais c'est une autre conversation, pas celle d'Osmani. Sa leçon à lui est plus simple et plus portable : la vitesse de l'IA ne te dispense pas de la vérification ; elle la rend plus urgente.
La leçon que tu peux emporter et partager
Retiens ce cadre mental, car il ne périme pas même si les modèles changent : l'IA effondre le coût de commencer et ne touche pas au coût de terminer. Commencer n'a jamais été le problème difficile du logiciel ; terminer, si. Les 70 % que l'IA fait gratuitement ont toujours été la partie bon marché — celle qu'un bon développeur faisait vite aussi. Les 30 % où elle te laisse seul ont toujours été la partie chère, celle qui coûtait du temps et du jugement, et qui continue de le coûter. Alors la bonne question face à n'importe quel outil qui promet de construire des apps à ta place n'est pas « à quelle vitesse atteint-il les 70 % ? » — tous y arrivent vite, cette course est gagnée et elle est ennuyeuse. La question, c'est « qu'est-ce qu'il fait des 30 % ? ». Qui te vend les 100 % automatiques te vend la démo et te cache la tempête.
Comment nous le voyons
Chez NeuralOS nous ne faisons pas semblant que les 30 % n'existent pas ; nous construisons autour d'eux. C'est pourquoi la plateforme ne s'arrête pas où s'arrête la génération : le moteur d'Automations est reprenable, avec des attentes durables et des checkpoints, précisément parce que les processus réels tombent en panne à mi-chemin et qu'il faut les reprendre sans rien corrompre — c'est le territoire des 30 %. C'est pourquoi les intégrations gardent leurs identifiants dans un vault chiffré par-tenant au lieu de les laisser à l'air libre, et c'est pourquoi nous travaillons avec une discipline de vérification et des tests de fumée sur les routes qui manient de l'argent : non parce que c'est glamour, mais parce que c'est exactement les 30 % où le logiciel vit ou meurt. Notre pari est l'inverse de celui de la poudre aux yeux : l'IA te mène en volant jusqu'au prototype, et nous prenons au sérieux le tronçon ennuyeux et décisif qui vient après. Fais confiance à la vitesse. Mais le jugement — poser des limites, vérifier, faire que ça tienne en production — cela ne se délègue pas. Cela se systématise. Et c'est toute la différence entre une démo qu'applaudit ton cercle et un produit qui survit à tes utilisateurs.