100k lignes en 75 jours

Il y a trois mois, j'ai démarré un projet de zéro pour répondre à une question : que peut-on raisonnablement attendre d'un développement entièrement agentique sur un vrai projet ?

Pas un TodoMVC. Pas une démo pour conférence. Un vrai projet, avec de vrais utilisateurs, de vraies règles métier tordues, et une mise en production au bout.

Il est en prod depuis la semaine dernière. Voici ce que j'ai appris.

Le cadre de l'expérience

Pour que le test vaille quelque chose, il me fallait trois conditions.

• Un projet complexe.
  Une application de gestion de ligues sportives, c'est de la règle métier en couches : classements, calculs de progression de joueurs, arbitrage de calendriers, des cas particuliers partout. Le genre de domaine qui casse les prototypes.
• Un vrai besoin.
  L'application remplace un outil existant utilisé par une communauté de jeu. Une petite centaine d'utilisateurs actifs aujourd'hui, sur un potentiel de quelques milliers, qui ne me feront aucun cadeau si un classement est faux. C'est exactement ce que je voulais : un juge de paix qui ne soit pas moi.
  
• Et surtout, pas un projet client. Sur un projet client, on ne joue pas. On ne pousse pas une méthode dans ses retranchements pour voir où elle craque. Ici, si ça cassait, ça cassait chez moi.

Le projet est open source, développé le soir et le week-end, seul, avec Claude Code. Le modèle utilisé est majoritairement Opus 4.8.
La stack : Rust, Axum, PostgreSQL, HTMX avec Askama pour les templates. Un seul repo.
Zéro framework JavaScript.

Les chiffres bruts

Trois mois de calendrier, environ 75 jours de travail effectif.

A l'arrivée : 100 000 lignes de Rust, 55 écrans, 1 500 tests unitaires, environ 200 tests e2e Playwright. Et à peu près 150 000 lignes de documentation, générée et maintenue au fil de l'eau, parce qu'un agent qui documente ne soupire pas.

Ce qui commence à faire.

La qualité, d'abord

Parlons bugs, parce que c'est la première objection, et elle est légitime. On m'annonce depuis deux ans que le code généré est un champ de mines.

Bilan après une semaine de prod et trois mois de développement : assez peu de bugs, et surtout aucun purement technique. Pas de fuite mémoire, pas de race condition, pas de requête N+1 monstrueuse. Ce que je corrige, ce sont des oublis et des incompréhensions. Une règle métier mal comprise parce que je l'avais mal spécifiée. Un cas limite que je n'avais pas mentionné.

Dit autrement : des bugs de spécification, pas des bugs d'exécution. Rien que je pourrais honnêtement mettre sur le compte d'une hallucination.

Le taux est plutôt en dessous de ce que j'aurais eu en codant à la main. Je le dis avec prudence, je n'ai pas de groupe de contrôle. Mais après 90 projets livrés en agence, j'ai une idée assez précise de ce à quoi ressemble une première semaine de prod. Celle-ci était calme.

Il faut dire que Rust aide. Le compilateur est un relecteur non négociable, et un agent qui doit satisfaire borrow checker et clippy avant de rendre sa copie produit mécaniquement moins de surprises qu'un agent qui pousse du JavaScript ou du python.

Le moment où ça devient débile

Maintenant, la productivité.

La mesure de la productivité d'un développeur a toujours été sujette à caution. La ligne de code est un étalon détestable, tout le monde le sait depuis Brooks. Mais admettons, pour l'exercice, qu'elle en vaille un autre.

100 000 lignes en 75 jours, ça fait 1 333 lignes par jour.

Pour situer : la littérature classique (Brooks donc, ou Capers Jones) place un développeur sur un projet mature entre 10 et 50 lignes nettes par jour. Nettes, c'est à dire ce qui reste après relecture, refactoring, suppression. Pas le premier jet.

On est donc quelque part entre 25x et 100x le rythme historique. Sans compter les 2 000 lignes de documentation quotidiennes venues avec. Sans compter non plus le temps passé à faire autre chose pendant que les agents infèrent, parce que c'est peut-être le plus étrange dans cette affaire : une partie de ces lignes a été écrite pendant que je préparais le dîner.

Pour ceux qui ne visualisent pas l'ordre de grandeur, prenons une analogie, qui vaut ce qu'elle vaut. Un romancier professionnel conserve, une fois relu et coupé, environ 25 à 30 lignes définitives par jour. Stephen King vise 2 000 mots bruts quotidiens et passe pour un stakhanoviste. Hemingway se contentait de 500. Ici, on parle de 1 333 lignes qui compilent, testées, en production. L'équivalent d'un roman de 90 000 mots tous les trois jours.

Côté interface, même punition : 55 écrans en 75 jours, soit un écran complet, maquette comprise, toutes les 30 heures de travail.

Je ne tire pas de conclusion définitive de ces chiffres. Ils sont bancals, comme toutes les métriques de productivité, et je serais le premier à démonter quelqu'un qui les brandirait pour dimensionner une équipe.

Mais l'ordre de grandeur, lui, est clairement là.

Et un ordre de grandeur pareil, ça ne se discute pas en pourcentage d'amélioration. Ça change la nature économique de ce qu'est un projet logiciel.

Ce que les chiffres ne disent pas

Voilà pour la partie brochure. Maintenant, la partie qui m'intéresse vraiment : pourquoi ça a marché, alors que tant de projets agentiques finissent en tas de spaghettis générés à grande vitesse.

La réponse tient en une phrase : ce n'est pas l'IA qui a rendu ça possible, c'est l'architecture posée avant.

Concrètement, sur Kreek :

Architecture hexagonale stricte, avec DDD, CQRS et event sourcing. Une dizaine de bounded contexts, que j'isolerais à terme dans leur propre crate cargo. Un agent ne pourra pas importer le domaine d'un contexte voisin : ça ne compilera pas.

Des garde-fous outillés qui vérifient chaque commit. Un script d'architecture contrôle huit axes de conformité, appuyé sur ast-grep, Dylint et cargo-archtest. Si un agent tente un raccourci, une dépendance directe vers l'infrastructure, une logique métier dans un handler, le commit est refusé. Pas par moi. Par la machine.

Une base de tests qui tourne vite. 1 500 tests unitaires et 200 tests e2e ne servent à rien s'ils prennent quarante minutes : l'agent arrête de les lancer, et vous aussi. Ici, l'isolation des tests d'intégration repose sur le clonage de templates PostgreSQL, ce qui permet de tout paralléliser. Il faudra que je détaille ça un de ces quatre tiens.

Voilà pour moi, le point que la plupart des retours d'expérience ratent.

Un agent est un développeur extraordinairement rapide, raisonnablement compétent, et totalement dépourvu de honte.

Il ne ressent aucune gêne à dupliquer une logique, à contourner une couche, à empiler un hack sur un hack. Ce qui retient un développeur humain de saboter sa propre base de code, c'est en partie la compétence, et en grande partie la honte devant ses collègues. Même si on a tous connu des contre exemples.

L'agent n'a pas de collègues. Il faut donc remplacer la honte par des contraintes exécutables.

Sans ça, un agent produit du code vite. Et du chaos encore plus vite. La vélocité ne pardonne rien : elle amplifie ce qui existe. Une bonne architecture est amplifiée. Une absence d'architecture aussi.

La conséquence économique

Si un développeur seul, le soir et le week-end, sort en trois mois ce qui aurait occupé une petite équipe pendant un an, la question n'est plus de savoir si l'IA va changer le métier. La question est de savoir ce que vaut, demain, une équipe qui n'a pas fait ce travail d'architecture.

Parce que le différentiel ne se joue pas sur l'accès aux modèles. Tout le monde a accès aux mêmes modèles, au même prix. Le différentiel se joue sur la capacité à poser un cadre dans lequel ces modèles restent productifs au centième jour comme au premier. C'est un savoir-faire d'architecte, pas un savoir-faire de prompteur. Et il se paie, ou se paiera très cher en dette.

C'est exactement ce qu'on applique chez WEDGE sur les projets clients. Les outils changent tous les six mois. La rigueur, elle, prend de la valeur à chaque changement d'outil.

La suite

Le projet continue de vivre, les utilisateurs remontent des demandes, et l'expérience se poursuit avec une question de plus long terme : est-ce que la base de code reste saine au sixième mois, au douzième ? C'est là que la plupart des projets générés meurent, et c'est là que les garde-fous montreront ce qu'ils valent vraiment.

Rendez-vous dans trois mois pour le deuxième retex, basé celui là sur les performances d'execution, sur un raspberry pi.
On va rire.
Le repo est ouvert, les curieux savent où me trouver, et peuvent vérifier les chiffres avancés, tout est public.