Le problème des 70 % est le constat que la génération tend à mener une construction logicielle jusqu'à un état presque fonctionnel, puis bute sur un reste qui résiste à l'automatisation. Cette dernière fraction n'est pas davantage du même code à plus petite échelle. C'est un travail qualitativement différent : intégration, cas limites, durcissement en production, et la part que personne n'a pris la peine de spécifier. Le premier tronçon récompense la fluidité ; le dernier récompense le jugement, et le jugement ne se comprime pas comme le code répétitif.
- Les premiers 70 % sont une surface bien spécifiée ; le reste est l'intérieur non spécifié.
- Une démo prouve le parcours heureux et cache les conditions qui le font échouer.
- Les cas limites se multiplient plus vite qu'aucune invite ne peut les énumérer.
- Les frictions d'intégration vivent entre les systèmes, là où aucun générateur unique ne peut voir.
- Le durcissement en production consiste surtout à se défendre contre des entrées que personne n'a décrites.
- Le chiffre bouge avec le temps, mais la forme de la difficulté ne change pas.
Pourquoi le dernier tronçon diffère-t-il qualitativement du premier ?
Le premier tronçon d'une construction est dense en structures décrites des milliers de fois. Formulaires, listes, routage, état, une forme de données aux champs prévisibles. La génération est forte ici parce que les motifs sont courants et l'intention lisible. Il y a peu d'ambiguïté sur ce qu'une table triable ou un formulaire validé doit faire.
Le reste est différent en nature. C'est la propriété d'un système où la spécification s'arrête et où la réalité continue. Que se passe-t-il quand deux écritures se concurrencent ? Quand une surface amont renvoie une forme qu'elle avait promis de ne jamais renvoyer ? Quand un utilisateur fait la chose raisonnable mais imprévue ? Ces questions ne sont pas des versions plus dures des premières. Elles forment une catégorie à part, définie moins par l'écriture de code que par la décision de ce que le code doit signifier dans des conditions que la demande d'origine n'a jamais nommées.
Il y a aussi un effet de rétroaction. Le code précoce est généré vite, donc il s'accumule vite, et le volume lui-même devient un terrain à traverser. Une construction qui matérialise en minutes doit encore être comprise en heures. Le lecteur arrive face à une structure qu'il n'a pas écrite, avec des conventions qu'il n'a pas choisies, et le coût de compréhension tombe exactement au moment où commencent les décisions difficiles.
C'est pourquoi le pourcentage est glissant. À mesure que les modèles s'améliorent, la frontière tend à se déplacer, mais elle se déplace le long de la même ligne de faille : partout où la spécification explicite s'arrête, l'automatisation ralentit. La pente s'accentue précisément là où la description s'amincit. Un chiffre qui se lit comme un progrès est en réalité un marqueur sur une frontière qui continue de glisser vers les parties qui furent toujours les moins lisibles.
Que cache une démo que la production révèle ?
Une démo est une performance contrôlée. Elle suit un seul chemin, avec des entrées choisies, sur un réseau indulgent, devant un public qui veut qu'elle réussisse. La production est l'inverse adversatif : tous les chemins à la fois, des entrées hostiles, des défaillances partielles, et personne aux commandes. La distance entre ces deux états est l'écart démo-production, et c'est là que va réellement l'essentiel de l'effort du dernier kilomètre.
L'écart est large parce qu'une démo qui marche et un système qui marche partagent une apparence mais pas une structure. La démo optimise pour le visible. Le système doit rendre compte de l'invisible — les nouvelles tentatives, l'idempotence, le délai d'attente qui se déclenche une fois par semaine, la migration qui doit tourner pendant que le trafic continue. Rien de tout cela n'apparaît dans un enregistrement d'écran.
Un arbitrage qui apparaît est la vitesse contre la durabilité. La génération achète un artefact rapide et plausible. Transformer cet artefact en quelque chose qui survit au contact d'une charge réelle est plus lent, et cela ressemble rarement à générer davantage de code. Cela ressemble à lire, tracer et contraindre ce qui existe déjà.
L'écart a aussi un coût perceptuel. Une démo convaincante crée l'attente que le travail est presque terminé, ce qui fait ressentir l'effort restant comme une régression plutôt que comme le gros du travail. Les parties prenantes l'ont vu fonctionner. La distance entre ce moment et un système fiable est réelle, mais elle est difficile à défendre parce qu'elle est invisible pour quiconque n'a regardé que la performance.
Pourquoi le reste le plus dur vit-il dans ce que personne n'a spécifié ?
Le reste non spécifié désigne le comportement qu'un système doit avoir et qui n'a jamais été écrit dans aucune demande. C'est la plus grande source de coût du dernier kilomètre parce qu'il ne peut pas être généré à partir d'une invite qui ne le contient pas. Un générateur répond à la question qu'on lui pose. La partie difficile est la question à laquelle personne n'a pensé.
La spécification est coûteuse précisément là où elle compte le plus. Personne ne spécifie ce que fait le paiement lorsque la surface de paiement confirme mais que l'écriture de la commande échoue, parce que personne ne veut y penser avant que cela arrive. Ainsi l'écart entre l'intention déclarée et le comportement requis devient le travail. Quelqu'un doit remarquer l'absence, la nommer et décider.
Remarquer est la compétence sous-estimée ici. Un générateur remplit ce qu'on lui donne et se tait sur ce qu'on ne lui donne pas, et ce silence se lit comme une complétude pour quiconque ne vérifie que le parcours heureux. Le reste est invisible par construction. Le faire apparaître, c'est imaginer le système sous stress avant que le stress n'arrive — une habitude d'attention plutôt qu'une fonctionnalité qu'un outil livrerait.
- Parcours heureux
- La seule séquence d'événements qu'une démo est construite pour montrer, où chaque dépendance se comporte bien.
- Reste non spécifié
- Comportement que le système doit présenter et qu'aucune demande, invite ou ticket n'a jamais décrit.
- Jointure d'intégration
- La frontière entre deux systèmes, où les hypothèses de chacun sur l'autre restent non dites.
- Durcissement en production
- Le travail qui consiste à faire survivre une structure générée à des entrées, des défaillances et une charge qu'on ne lui a pas montrées.
Où se déplace l'effort humain lorsque la génération absorbe les premiers 70 % ?
L'effort ne disparaît pas ; il migre. Lorsque la masse précoce et bien spécifiée d'une construction est générée en quelques minutes, les heures humaines qui allaient autrefois à la frappe se dirigent vers les activités où la génération est la plus faible. Lire du code inconnu devient une compétence première. Décider ce qu'un système doit faire à ses bords devient la contribution rare.
Ce déplacement change la forme d'une journée. Moins de temps à produire des premiers jets, plus de temps à les interroger. Le goulot passe de la création à la vérification — confirmer que la chose plausible est aussi la chose correcte dans des conditions que le générateur n'a jamais testées. Le jugement, le goût pour les modes de défaillance, et la patience de traquer un bug une-fois-par-semaine deviennent le travail qui pèse.
Cela change aussi ce que vaut l'expérience. La valeur d'avoir vu échouer de nombreux systèmes ne se transfère pas à un générateur ; elle vit chez la personne qui reconnaît une odeur familière dans un code inconnu. Cette reconnaissance est ce qui permet de jeter un œil à un flux généré et de sentir, avant tout test, où il pliera. Le code précoce se commoditise ; l'instinct pour ses bords, non.
| Propriété | Premiers 70 % (générés) | Derniers 30 % (humains) |
|---|---|---|
| Spécification | Explicite, courante, lisible | Implicite, rare, contestée |
| Activité dominante | Produire de la structure | Contraindre le comportement |
| Visibilité des échecs | Évidente dans une démo | Cachée jusqu'à la production |
| Facteur de coût | Volume de code | Profondeur de jugement |
| Compressibilité | Élevée | Faible |
Comment les équipes franchissent-elles le dernier tronçon délibérément ?
Franchir le dernier kilomètre tend à suivre un ordre, non parce qu'une recette existe, mais parce que les échecs arrivent dans une séquence prévisible. La discipline consiste à traiter l'artefact généré comme une hypothèse et le travail restant comme une falsification.
- Cartographier les jointures : lister chaque frontière où la construction touche un système qu'elle ne contrôle pas.
- Énumérer les entrées que la démo n'a jamais utilisées, surtout les malformées, vides et dupliquées.
- Tracer chaque chemin d'échec jusqu'à une décision : réessayer, rejeter, dégrader ou remonter.
- Rendre l'implicite explicite en écrivant le comportement que personne n'a spécifié, puis en le choisissant.
- Mettre le résultat sous pression avec une concurrence et un volume réels avant de le déclarer terminé.
Chaque étape convertit un inconnu en une intention déclarée. Les 70 % générés vous donnent un corps à interroger ; cette procédure est l'interrogatoire. Elle est plus lente que la génération par conception, parce que son produit est la certitude plutôt que la surface.
L'ordre compte plus que chaque étape prise isolément. Cartographier d'abord les jointures évite l'erreur courante de durcir l'intérieur pendant que les frontières restent sans défense. Énumérer les entrées avant de tracer les échecs ancre le travail dans ce qui arrive réellement plutôt que dans ce qu'on avait imaginé. La séquence est une façon de dépenser l'attention là d'où viendra le plus probablement le prochain échec, plutôt que là où le code est le plus confortable à lire.
Que devient la frontière du dernier kilomètre à mesure que la génération s'améliore ?
La frontière ne se dissout pas ; elle se déplace vers le haut. À mesure que la génération gère davantage du milieu bien spécifié, la frontière humaine avance vers les parties qui furent toujours les moins descriptibles — les appels au jugement, la sémantique des défaillances, les décisions sur ce qu'un système doit à ses utilisateurs quand quelque chose casse. Le pourcentage peut monter. Le caractère du reste devient plus dur, non plus facile, parce que ce qui reste est le résidu de tout ce qui a résisté à la spécification.
Ce qui se raréfie, alors, n'est pas la capacité à coder mais celle de tenir les bords d'un système à l'esprit et de décider bien à leur sujet. Le champ tend à récompenser ceux qui lisent vite, doutent de façon productive, et terminent. Le dernier tronçon d'une construction générée restera humain aussi longtemps qu'une part de chaque système restera non spécifiée — c'est-à-dire pour longtemps encore.
Il y a une implication plus discrète pour l'organisation des équipes. Si le milieu généré continue de croître, le travail qui distingue un système terminé d'un système plausible se concentre dans des heures moins nombreuses et plus denses. Cela tend à récompenser la profondeur plutôt que le débit, et rend la capacité à dire ce qu'un système doit faire en cas de défaillance plus précieuse que celle d'en produire davantage. La frontière bouge ; elle ne se ferme pas.
FAQ