La variable
manquante

39 400 lignes de TypeScript applicatif. 17 100 lignes de CSS — quatre thèmes, architecture @layer, animations, accessibilité. 633 tests unitaires. Sept fournisseurs LLM intégrés. Une base SQLite avec undo/redo, multi-canvas, persistance complète. Un système de scoring cognitif en temps réel. Un design system modulaire avec douze fichiers composants.

72 000 lignes au total. 33 jours de développement. Un seul développeur.

L'outil s'appelle KAIROS. C'est une application Electron de cartographie cognitive assistée par IA. Je l'ai construite presque entièrement en vibe coding avec Claude Code.

Estimation d'un développeur senior solo, sans IA, pour le même périmètre : 12 à 18 mois à temps plein. Le facteur d'accélération se situe entre x10 et x15.

D'un côté, les enthousiastes brandissent la vitesse : des prototypes en quelques heures, des MVP en un week-end, des démos spectaculaires. De l'autre, les développeurs expérimentés pointent — à raison — les dégâts : du code fragile, des architectures incohérentes, des produits qui s'effondrent dès qu'on pousse au-delà de la démo.

Ce qui manque, ce n'est pas un arbitre. C'est une variable.

Le débat pose la question « est-ce que le vibe coding fonctionne ? » comme s'il s'agissait d'une propriété de l'outil. Oui ou non. Mais le vibe coding n'est pas une méthode unique — c'est un spectre. À une extrémité, un prompt vague lancé dans le vide, itéré par essai-erreur jusqu'à ce que quelque chose tienne. À l'autre, une architecture documentée, des contraintes explicites, un contexte structuré qui nourrit chaque interaction.

Les résultats entre ces deux pôles n'ont rien en commun. Les mettre dans la même catégorie revient à comparer un croquis sur un coin de table et un plan d'architecte sous prétexte que les deux utilisent un crayon.

17 000 lignes de CSS cohérent. Quatre thèmes (Obsidian, Porcelain, Aurora, Kraft), chacun avec ses tokens de couleur, ses variantes de composants, ses adaptations au mode sombre et clair. Une architecture @layer en sept niveaux — reset, tokens, thèmes, base, composants, modes, pages, utilitaires. Le support prefers-reduced-motion. Les animations Bézier sur les connexions SVG.

Un humain ferait ce travail. Il le ferait bien. Il le ferait en quatre à six semaines, parce que le CSS à cette échelle est un travail de moine : répétitif dans sa structure, exigeant dans ses détails, punitif à la moindre incohérence. Claude Code l'a fait en trois jours. Pas parce qu'il est meilleur — parce que la répétition structurée est exactement ce que le modèle accélère.

Même constat sur le boilerplate. Les handlers IPC entre le processus principal et le renderer, les repositories CRUD, les types TypeScript, les migrations de base de données — du code nécessaire, souvent identique dans sa forme, variable dans ses détails. L'IA génère, l'humain vérifie. Le ratio s'inverse par rapport au développement classique : au lieu d'écrire 80% et relire 20%, on relit 80% et on écrit 20%.

Les tests, aussi. 633 tests, 22 fichiers, avec les bons mocks, les edge cases, les scénarios de régression. Écrire des tests est un acte de discipline que la plupart des développeurs solo repoussent indéfiniment. L'IA ne repousse rien — elle n'a pas de préférence. Tu demandes, elle écrit.

Et le refactoring. Quand une décision d'architecture change, les conséquences cascadent sur dix, quinze, vingt fichiers. En développement classique, c'est le moment où tu hésites à faire le changement, parce que le coût de propagation est élevé. Avec l'IA, le coût chute. Tu changes l'architecture parce que c'est la bonne décision, pas parce que c'est la décision compatible avec l'état actuel du code. Cette différence est plus importante qu'elle n'en a l'air.

KAIROS repose sur des concepts qui n'existent dans aucun dataset d'entraînement. Un système de scoring cognitif en temps réel, des postures d'interaction adaptatives, des mécaniques de friction qui forcent la pensée à se repositionner quand la conversation tourne en rond. Tout cela vient d'un cerveau humain qui a passé des mois à observer ce que personne ne mesurait.

Et puis il y a l'autre face invisible : ce qui n'a pas été construit. Deux features avaient été conçues, prototypées, parfois même partiellement codées. F057 — les vignettes latentes — et F060 — le signal surprise. Elles ont été abandonnées. Pas par manque de temps. Par décision. Parce qu'après analyse, elles traitaient des symptômes et non des causes. L'IA aurait construit les deux sans sourciller. C'est l'humain qui a dit non.

KAIROS a été développé avec une documentation structurée maintenue en continu : un registre technique à jour, des guides d'architecture, des conventions explicites (IDs en crypto.randomUUID(), jamais Date.now() ; CSS emoji en UTF-8 littéral, jamais en escape hex ; hooks centralisés, jamais de fonctions locales directes). Chaque session de développement commence avec un contexte chargé — pas un prompt en roue libre.

La différence entre le vibe coding qui produit du bruit et celui qui produit un système tient dans ce que l'humain apporte avant que l'IA écrive la première ligne. L'architecture posée sur papier. Les contraintes nommées. Les erreurs passées documentées pour ne pas les reproduire. Ce n'est pas du prompt engineering — c'est de l'ingénierie tout court, appliquée à un outil différent.

Les développeurs seniors qui critiquent le vibe coding ont raison quand ils décrivent des projets construits sans cette rigueur. Le code est fragile, l'architecture est incohérente, le produit s'effondre. Mais la conclusion qu'ils en tirent — que le vibe coding est intrinsèquement déficient — confond l'absence de méthode avec une limite de l'outil.

Un marteau ne construit pas de maison. Un marteau dans la main de quelqu'un qui sait lire un plan, si.

Ce qui change vraiment

Le métier ne disparaît pas. Il se déplace.

En 33 jours, j'ai écrit peut-être 5% du code de KAIROS à la main. Les 95% restants ont été générés, revus, parfois régénérés, parfois jetés. Mon travail n'a pas été d'écrire — il a été de décider. Décider quoi construire, dans quel ordre, avec quelles contraintes. Décider quand le résultat était suffisant et quand il fallait recommencer. Décider ce qu'il ne fallait pas construire du tout.

C'est un changement de nature, pas de degré. Le développeur qui refuse le vibe coding protège un savoir-faire réel — écrire du code propre, maintenable, testé — mais ce savoir-faire migre. Il ne s'exerce plus dans l'écriture. Il s'exerce dans le cadrage, la relecture, la décision d'architecture. Les mêmes compétences, un autre point d'application.

Ce n'est pas l'outil qui fait la différence. C'est ce que tu sais avant de l'ouvrir.