Kreek: L'app que j'ai vraiment fait avec une IA

A l'heure ou j'écris ces lignes, avec l'arrivée de l'IA, le développement logiciel vit sa plus grande révolution depuis l'apparition des compilateurs.

Pas la version publicitaire, ou on code une application en un week-end en claquant des doigts. Pas non plus la version grincheuse, ou tout ce que produit une IA serait du déchet inutilisable.

Comme souvent la vérité est plus intéressante que les deux caricatures ci-dessus.

Et plutôt que d'en discuter dans l'abstrait, j'ai voulu expérimenter moi-même, et partager le voyage.
J'ai donc construit une vraie application, en production, avec l'aide massive d'un assistant IA - claude code en l'occurrence. L'appli est un moteur de gestion de ligue sportive, écrit en Rust, avec une vraie architecture : event sourcing, CQRS, une douzaine de contextes métier étanches.

Une partie de ce blog raconte cette histoire. En détail, sans filtre, avec les réussites et les casseroles. Et comme toute histoire, elle a une structure, en trois temps.
Le début, le milieu et la fin.

Premier temps : la vitesse

Commençons par ce qui saute aux yeux, parce que c'est vrai et c'est spectaculaire.

C'est allé vite. Très vite.

Pour vous donner une idée, mon dépôt a passé plus d'un an quasiment a l'arrêt. Le premier commit date du 7 janvier 2025. Le deuxième, de mars. Et puis plus rien pendant des mois. Le genre de projet perso qu'on traîne, qu'on aime, et qu'on n'avance jamais.

Et puis le 1er mai 2026, un commit qui dit tout : « reboot du projet pour event sourcing ». A partir de la, tout bascule. 64 commits en mai. 258 en juin. 183 en juillet. L'application sort de terre, se structure, passe en production. La bascule est nette, elle est datée, elle est dans l'historique git, vérifiable ligne par ligne.

Et un détail que je trouve parlant : ces commits, ils tombent le soir. Le gros du travail entre 22h et minuit, avec le dimanche comme jour le plus chargé. Ce n'est pas un projet financé a plein temps. C'est un projet de soirées et de week-ends.

Voila pour la vitesse. Si je m'arrêtais la, je serais exactement comme tous les posts que vous avez déja lus. "Regardez comme l'IA m'a rendu rapide."

Sauf que la vitesse toute seule ne veut rien dire. La vitesse toute seule, c'est même un piège.

Car l'appli dont je vous parle, nom de code kreek, est la refonte d'une appli en prod depuis 10ans, avec un petit milliers d'utilisateurs, suffisamment pour construire un cadre de test grandeur nature, avec l'exigence qui va avec.

Deuxième temps : la maîtrise

Parce que voila ce que personne ne raconte.

Le code produit vite par une IA, sans cadre, s'effondre. Pas tout de suite. C'est ça le piége. Il marche le premier jour, il marche la première semaine, et il vous explose a la figure trois mois plus tard, quand la complexité a dépassé ce que l'outil arrive a tenir en tête.

J'en ai fait l'expérience. Ce blog est plein de ces moments. Des tests qui passaient au vert depuis des mois sans rien tester du tout. Une régression sournoise après un refacto pourtant propre. Une unité de mesure qui se balade entre trois contextes et sème des bugs sur son passage.

Ces cicatrices, je ne les cache pas. Je les documente. Parce que ce sont elles qui racontent la vraie histoire.

La vitesse n'est pas devenue soutenable par magie. Elle l'est devenue parce que je l'ai gouvernée. J'ai construit, autour de l'assistant, tout un appareil de règles : des conventions vérifiées automatiquement, des garde-fous qui bloquent un commit non conforme, un carnet ou j'écris chaque leçon apprise pour qu'elle survive a l'oubli.

C'est ça, le vrai sujet. Pas "l'IA code vite", mais "comment on garde le contrôle quand l'IA code vite".

Et ce contrôle, il ne s'improvise pas. Il vient de vingt ans passés a construire des logiciels complexes, 20 ans a comprendre et a remettre en questions les "bonne pratiques" et les concepts d'architectures techniques, pour atteindre ce que je pense être le meilleur compromis entre robustesse, prix et go-to-market. Je vous partagerais les pratiques de harnais auxquelles je suis arrivés, par itération.

Troisième temps : la preuve

Reste une question. Celle qu'on n'ose jamais poser dans les articles enthousiastes.

Ce code produit vite, même bien gouverné, il vaut quoi ?

Rapide a écrire, d'accord. Mais rapide a l'exécution ? Sobre en ressources ? Ou est-ce juste un truc qui marche sur ma machine et qui s'écroule des qu'on le pousse un peu ?

C'est la que je refuse de me contenter d'affirmer. Un adjectif comme "performant" ne vaut rien sans chiffres derrière.

Alors je vais mesurer. Le même binaire, sur un Raspberry Pi et sur un serveur de production. Sur des cas métier différents, du plus gourmand en calcul au plus gourmand en acces disque. Et je publierai les résultats, méthode comprise, pour que vous puissiez les critiquer.

Pourquoi ce blog existe

Voila le voyage. Vite, maîtrisé, mesuré.

Trois mots qui, mis bout a bout, racontent quelque chose de plus honnête que le discours ambiant. Oui, l'IA change la donne. Non, ce n'est pas magique. Et entre les deux, il y a un métier, une méthode, et des preuves.

Ce blog va détailler chacun de ces trois temps. Comment ça a été vite. Comment je l'ai gardé sous contrôle. Ce que le code vaut, mesures a l'appui. Avec le code ouvert, public, consultable - parce qu'ici on ne vous demande pas de me croire sur parole. On vous montre.

Bienvenue dans l'atelier W, on va découvrir le projet Kreek.