Bilan : ce que ça apporte, ce que ça coûte, et la recette à réutiliser

Série « Vibe coding avec Claude Code » · Article 5/5. Le dernier. On a montré le résultat (article 1), le fonctionnel produit par l’IA (article 2), le socle et la gouvernance (article 3), la méthode en action (article 4). Place au bilan : les points forts, les limites assumées, les chiffres réels (coût, effort, qualité), et une recette à réutiliser sur votre prochain projet.

Sommaire de la série :

1. J’ai vibe-codé une application e-commerce complète avec Claude Code
2. Avant le code : faire produire le fonctionnel par l’IA
3. Préparer le terrain : doc, archi et gouvernance avant la première ligne
4. La méthode au quotidien : comment Claude code, et comment je garde le contrôle
5. Bilan : ce que ça apporte, ce que ça coûte, et la recette à réutiliser (cet article)

Quatre articles durant, j’ai raconté comment on construit une vraie application en dirigeant une IA. Cet article répond à la question qui reste : est-ce que ça en valait la peine, et à quel prix ? Pas de storytelling ici, des chiffres. Combien de temps, combien d’argent, quelle qualité mesurée, ce qui a bien marché et ce qui a coincé. Et, pour finir, ce que je garderais pour la prochaine fois. Mon fil rouge, une dernière fois :

Je dirige, l’IA exécute.

C’est ce fil qui se referme ici. Parce que le bilan ne dit pas « l’IA a construit une application ». Il dit : un architecte a dirigé une IA, et voici ce que ça produit, ce que ça coûte, et pourquoi le pilote compte autant que l’outil.

1. Ce que ça apporte

Commençons par le positif, parce qu’il est réel et mesurable.

La vélocité. Le cœur de l’application (dix incréments fonctionnels, sept contextes métier, une saga de paiement avec compensation, de l’event sourcing, des projections, deux fronts) a été construit en moins d’une semaine de temps actif. Pas une démo jetable : une application production-grade, cadrée et testée. Cette vitesse n’est pas magique, on y revient au chapitre coût, mais elle est indéniable.

La cohérence. Grâce au cadre (les règles encodées, le contrat gelé, les ADR), l’application est cohérente d’un bout à l’autre : le module 10 respecte les mêmes principes que le module 1. Une IA dirigée par un cadre stable ne dérive pas de style ni d’architecture au fil des semaines, là où une équipe humaine, elle, le ferait probablement.

L’IA touche tout le cycle. C’est le point que je veux marteler, parce qu’il est sous-estimé. Claude n’a pas seulement écrit du code. Il a été analyste (le fonctionnel, article 2), architecte de support (les options d’archi, les ADR, article 3), développeur (le code, article 4), documentaliste (les ADR, les lessons, les diagrammes), et testeur (TDD, tests d’intégration). Un seul outil, dirigé, sur toute la chaîne, du besoin flou à la note pédagogique.

Une documentation transversale, toujours à jour. Parce qu’elle est produite et maintenue au fil de l’eau, la doc ne décroche jamais du code. ADR, lessons, diagrammes C4 et UML : environ 22 000 lignes de documentation et de modèles, dont le Markdown seul (près de 17 000 lignes) dépasse tout le code front. Cette doc n’est pas un sous-produit : c’est un actif d’onboarding et de montée en compétence (apprendre l’event sourcing sur Order, pas sur des slides).

Un outillage maison d’observabilité. La page Simulation / Lab de l’article 1 n’est pas un gadget : c’est un vrai banc d’essai pour rendre les patterns distribués visibles et manipulables (injecter une panne de paiement, regarder la compensation, suivre le retard des projections). L’IA, dirigée, ne s’arrête pas au fonctionnel : elle outille aussi la compréhension du système.

La preuve chiffrée du « production-grade dirigé »

Quand je dis « production-grade », je ne demande pas qu’on me croie sur parole : le projet se mesure. L’article 4 a montré l’outil (une commande qui lance tout l’arsenal qualité et sécurité, écrit un ledger versionné et un tableau de bord). Voici maintenant les chiffres du dernier run complet.

Le mutation testing mérite un mot, parce que c’est le chiffre le plus honnête de la liste. La couverture (« 92 % des lignes sont exécutées par un test ») peut mentir : un test qui exécute du code sans rien vérifier compte quand même. Le mutation testing répond à la vraie question : si j’injecte délibérément une faute (j’inverse un <, je supprime une ligne), un test échoue-t-il ? À 77,9 %, oui, dans plus de trois cas sur quatre. C’est la mesure que les tests prennent au sérieux ce qu’ils prétendent garder.

Le tableau de bord du sweep qualité / sécurité (trend.html), ici comme preuve chiffrée du « production-grade dirigé ». Build, couverture, mutation, dépendances, secrets, Sonar, scan dynamique : chaque run ajoute une ligne, et l’évolution est suivie dans le temps. Ce que je retiens, c’est qu’aucun de ces chiffres n’est tombé du ciel : ils sont bons parce que le cadre les a exigés, incrément après incrément, pas parce que l’IA serait magiquement propre.

🧭 Notre méthode porte un nom : le spec-driven development. Spécifier d’abord (un document-source unique, un contrat d’API gelé, des ADR), dériver le plan, puis générer le code, c’est exactement ce que l’industrie a baptisé spec-driven development en 2025-2026, précisément en réponse aux dérives du vibe coding « au feeling ». On n’a pas inventé une méthode : on a appliqué (et parfois redécouvert seul) une best practice qui se généralise. Tous les grands outils ont désormais leur variante, de GitHub Spec Kit à AWS Kiro. La nôtre était faite main, mais elle relève de la même famille.

2. Ce que ça coûte : les limites assumées

Tout n’est pas vert, et c’est tant mieux pour la crédibilité. Voici ce qui a coincé.

Les gros dispatches débordent. Un agent à qui on demande de construire un module entier d’un coup atteint la limite de contexte et échoue. C’est la leçon apprise « à la dure » de l’article 4, dont la cascade de six bugs de la saga de checkout est la cicatrice la plus parlante (je n’y reviens pas, elle est racontée là-bas). La parade existe, c’est le scoping serré, mais il faut l’appliquer dès le départ, pas l’apprendre en cours de route.

L’IA se trompe sur les API précises. Là où le modèle excelle sur les patterns généraux, il se trompe régulièrement sur les détails pointus d’une bibliothèque : la gestion des identifiants fortement typés de Marten, le mapping des noms de colonnes Postgres vers les propriétés C#, une politique de résolution de dépendances de Wolverine, des surcharges obsolètes de Hangfire. À chaque fois, c’est sa mémoire d’entraînement (parfois périmée) qui se trompe. La réponse a été systématique : faire vérifier la version courante et la signature réelle dans la documentation à jour (via les connecteurs MCP) avant d’écrire, jamais de mémoire.

Ce que le build et les tests unitaires ne voient pas. C’est le risque central du code généré : il a l’air propre, il passe les tests basiques, et il cache des défauts sur les cas limites. Seuls les tests d’intégration sur une vraie infrastructure les ont révélés (article 4). Le build vert ne prouve presque rien sur un système distribué.

L’IA ne remplace pas l’architecte. C’est la limite la plus importante, et elle est structurelle, pas conjoncturelle. Les choix qui ont fait la qualité du projet (le modèle de cohérence par interaction, les frontières de transaction, les quinze règles, la stratégie de portabilité cloud) ont été décidés par un humain. L’IA a proposé, challengé, exécuté. Elle n’a jamais tranché à ma place les arbitrages qui comptent.

Le coût d’amorçage de la gouvernance. Construire le cadre (les agents, les commandes, le skill, les hooks, le contrat, le document-source, les premiers C4) avant de coder est un vrai investissement initial, front-loaded, comme je l’annonçais à l’article 3. Sur un petit projet jetable, il ne se rentabilise pas. Il ne se justifie que parce que le projet est ambitieux et durable.

Une limite de vérification honnête. Faute d’abonnement Azure, l’incrément « Azure-readiness » prouve le code et la sélection d’adaptateurs par configuration, mais le passage réel sur le cloud reste un résidu documenté, pas un fait vérifié.

Et les verrues, assumées

La revue qualité ne sert à rien si elle cache ce qui ne va pas. Donc, franchement :

• Le front traîne 68 erreurs de lint (31 côté boutique, 37 côté admin), non résolues. Le back-end est à zéro warning, le front non. La raison est que cette vérification a été ajoutée en cours de route, et non pas en début de projet.
• SonarQube remonte un gros volume d’observations (2 667 sur la maintenabilité), mais la quasi-totalité (2 527) sont de niveau info, et le taux de maintenabilité reste A. Zéro blocker. Un grand nombre concerne aussi le style, des vérifications ou des faux-positifs. Ces règles n’ont pas été dictées à Claude en amont, sinon elles seraient moindres.
• Huit défauts de configuration (Trivy) sur les fichiers Docker et Compose de dev : acceptables en POC local, à traiter avant une vraie mise en production. Encore une fois, ces vérifications ont été mises en place post-développement.
• Pas de CI câblée. Le sweep est manuel, déclenché à la main. En équipe, il aurait sa place dans la pipeline (j’y reviens à la fin).

Le risque du vibe coding, enfin chiffré

À l’article 1, je promettais de chiffrer le risque. Le voici, avec ses sources, parce que c’est exactement la dérive contre laquelle tout mon cadre a été bâti.

D’abord l’adoption : selon l’enquête Stack Overflow 2025 (plus de 49 000 développeurs), 84 % utilisent ou comptent utiliser des outils d’IA, en hausse depuis 76 % un an plus tôt. Mais, et c’est le paradoxe, la confiance dans leur exactitude est au plus bas : seuls 29 à 33 % font confiance aux réponses de l’IA (contre 40 % l’an passé), 46 % s’en méfient activement, et 66 % citent comme principale gêne « des solutions presque justes, mais pas tout à fait ».

Ensuite le risque concret. Le rapport GenAI Code Security 2025 de Veracode, qui a testé plus de cent modèles sur 80 tâches de code, conclut que 45 % du code généré par IA introduit une vulnérabilité de l’OWASP Top 10, soit 2,74 fois plus que le code écrit par un humain. Détail qui glace : les modèles plus récents et plus gros ne font pas mieux, ce qui suggère un problème structurel dans la façon dont l’IA génère du code, pas une limite passagère qui disparaîtra à la prochaine version.

Mettez les deux bout à bout : une adoption massive, une confiance en chute, et près d’une génération de code sur deux porteuse d’une faille. C’est la définition même du multiplicateur qui amplifie le manque de rigueur. Tout ce que cette série décrit (le contrat gelé, les tests d’intégration, les agents de revue et de sécurité, les règles encodées, le sweep mesuré) n’est pas de la coquetterie d’architecte : c’est la réponse directe à ces chiffres. L’IA « au feeling » produit précisément le code que ces études décrivent. L’IA dirigée produit ce que mesure mon tableau de bord.

3. Les chiffres

Place aux compteurs. Tout est mesuré sur le projet ecom uniquement (les autres projets menés en parallèle sont exclus par construction), reproductible, et rien n’est inventé.

Le coût, vraiment expliqué

C’est le point pédagogique central de cet article, parce qu’il est presque toujours mal compris. Voici le chiffre qui circule, puis la vérité derrière.

Au tarif catalogue de l’API, en pay-as-you-go, la compute consommée par tout le projet vaudrait environ 1 500 à 1 700 dollars (ordre de grandeur 1 550, à plus ou moins 10-15 %). Et tout de suite l’avertissement le plus important de l’article :

⚠️ Ce n’est PAS ce qui a été payé. Ce montant matérialise ce que la compute brute vaudrait au tarif liste de l’API. En réalité, tout a été fait via un abonnement Claude Team Premium à environ 90 € par mois, dont les quotas n’ont jamais été atteints, et sur lequel d’autres projets tournaient en parallèle. Pour ce profil d’usage intensif et soutenu, l’abonnement est de l’ordre de 15 à 20 fois moins cher que l’API à l’usage. C’est le vrai enseignement économique : pour qui code beaucoup, le forfait écrase le pay-as-you-go.

Maintenant, pourquoi ce coût catalogue, et d’où vient-il ? La réponse surprend tout le monde : il est dominé non pas par ce que l’IA écrit, mais par ce qu’elle relit.

La répartition du coût équivalent API. La lecture de cache (835 $) domine tout le reste. La sortie, ce que Claude écrit vraiment, ne pèse que 304 $.

L’explication tient à une propriété de l’API : elle est sans état. À chaque message, tout le préfixe de la conversation (les instructions, les outils, l’historique complet, le contenu des fichiers déjà lus) est renvoyé et relu par le modèle. Sur ce projet, cela représente 1,67 milliard de tokens relus. Le prompt caching facture cette relecture à un dixième du prix de l’entrée normale : très bon marché au token, mais relu des milliards de fois. Résultat : 1,67 milliard de tokens à 0,50 $ le million, soit 835 $. Ce n’est pas un calcul gratuit, c’est un service facturé (fortement subventionné, pas offert).

À noter que, puisque je n’atteignais pas les limites de Claude, je ne me suis pas concentré outre mesure sur l’optimisation des tokens. Sur un projet réel, il faudrait dès les premiers incréments rendre la consommation progressivement plus efficiente : optimisation du CLAUDE.md, skills, compression du contexte, modèle adapté à la tâche, niveau de réflexion adaptatif. On réduit ainsi la facture, et on gagne aussi en rapidité de traitement. Je n’ai pas non plus travaillé à temps plein sur les incréments : mes conversations se sont étalées sur plusieurs sessions, ce qui a sensiblement augmenté les coûts (chaque reprise relit le préfixe complet).

À l’inverse, la sortie ne pèse que 304 $, parce que Claude écrit environ 140 fois moins qu’il ne relit (12 millions de tokens écrits contre 1,67 milliard relus). La sortie est chère au token, mais à faible volume. Le reste de la facture (de l’ordre de 400 $) se partage entre l’écriture du cache (mettre un préfixe en cache la première fois coûte plus cher que de le relire) et les entrées fraîches pas encore mises en cache : 835 + 304 + ~400, soit l’ordre de grandeur des 1 550 $ annoncés.

Et sans cache, l’addition serait environ six fois plus salée (de l’ordre de 9 000 $) : les 1,67 milliard de tokens relus seraient au plein tarif d’entrée. La leçon : le cache rend l’agentique abordable, il ne la rend pas gratuite.

🔍 Reproduisez-le vous-même. L’outil npx ccusage (site officiel) ventile votre propre usage par modèle et par jour, aux prix de l’API, en tenant compte des durées de vie du cache (il agrège tous vos projets ; pour isoler un seul il faut filtrer). C’est avec ce type d’analyse, appliqué aux seuls logs du projet, que les chiffres ci-dessus ont été établis. Comprendre la consommation permet d’optimiser et de rendre le tout beaucoup plus efficient.

L’effort et le modèle

• Environ 40 heures de temps actif, réparties sur 33 conversations, du 7 au 24 juin (environ 17 jours calendaires). Le temps « actif » est la somme des intervalles entre messages, les pauses de plus de cinq minutes retirées (lecture, nuit, PC en pause). Le cumulé (40,0 h) colle à l’effectif (39,4 h), ce qui veut dire que les conversations étaient séquentielles : le parallélisme réel venait des sous-agents à l’intérieur d’une conversation. Claude Code s’exécute en local, pas dans le cloud, donc lorsque le PC n’est plus en ligne le fonctionnement s’arrête.
• Environ 100 % du travail en Claude Opus 4.8, sous-agents inclus (ils héritent du modèle de la session). Le choix d’Opus partout, plutôt qu’un modèle moins cher pour les agents, est assumé : un agent qui échoue par manque de contexte coûte plus cher qu’un agent haut de gamme qui réussit du premier coup, et la barre de qualité du POC (la règle d’or : le bon correctif plutôt que le rapide) prime sur le coût en tokens. Je pense qu’Opus est nécessaire pour bien poser les premières briques, en revanche par la suite le modèle Sonnet (bien moins cher, voire Haiku) serait amplement suffisant pour un résultat final très proche. En effet, les erreurs qu’un Haiku pourrait effectuer seraient détectées par les autres agents et pipelines (qualité/sécurité/dba) puis corrigées.

Le volume produit

Pour mémoire (le détail était à l’article 1) : environ 38 600 lignes de code applicatif (24 400 de C# back-end, le reste en TypeScript et Svelte), 16 800 lignes de Markdown et 5 800 lignes d’UML. Soit une cinquantaine de projets .NET, 38 ADR, 30 diagrammes, 17 lessons, et les 15 règles d’architecture. Mesuré au commit, sur les fichiers réellement versionnés.

⚖️ Honnêteté sur le global. La couverture globale affichée par l’outil est de 57,8 %, et ce chiffre est trompeur : l’infrastructure et les hosts sont couverts par la suite d’intégration (avec de vrais conteneurs), qui est exclue du run unitaire. Ce n’est pas du code non testé, c’est du code testé ailleurs. Le chiffre qui compte est la couverture du domaine (91,8 %), là où vivent les règles métier.

4. La recette réutilisable

Si vous voulez tenter la même chose sur votre prochain projet from-scratch, voici la recette, condensée en six gestes. Aucun n’est propre à ecom : c’est le squelette transposable.

La recette en six gestes. Chacun renvoie à un article de la série : spécifier (2 et 3), gouverner (3), le cycle (4), les garde-fous (4), le versioning (4), le scoping (4).

1. Spécifier avant de coder. Un document-source unique, un contrat d’API gelé, des ADR pour tracer le pourquoi. C’est du spec-driven development : le « quoi » est figé et validé par un humain avant que la première ligne soit générée.
2. Outiller la gouvernance. Un skill qui encode vos règles (chargé à la demande, pas noyé dans un fichier trop long), des agents spécialisés en contexte séparé, des hooks déterministes (ce qui doit arriver à coup sûr, pas une consigne advisory), des connecteurs MCP pour vérifier les API et explorer le code sans tout rescanner.
3. Un cycle design-first, à chaque incrément. La décision, puis le modèle, puis le contrat, puis les tests, puis le code, puis la note pédagogique. Le code arrive en avant-dernier, exprès.
4. Des garde-fous qui crient. Les tests d’intégration sur une vraie infrastructure (le seul filet qui attrape ce que le build rate) et un sweep qualité mesuré, avec une règle d’or : un scan non exécuté est « non mesuré », jamais maquillé en zéro.
5. Protéger le versioning. En équipe : bloquer main, imposer les feature branches et les pull requests avec reviewers, garder les commits petits. Si l’IA commite, il faut pouvoir vérifier.
6. Scoper serré. Une tranche, un endpoint, un handler et son test. Jamais un module entier d’un coup. C’est la leçon la plus rentable de tout le projet.

Le cœur de cette recette, c’est le geste 3 : le cycle qu’on répète à chaque incrément. Le voici déroulé, avec ses deux boucles. La boucle externe (le cycle complet de huit étapes) se rejoue à chaque incrément ; la boucle interne (le TDD : rouge, vert, refactor) tourne à l’intérieur, autour des étapes Tests et Code.

Le cycle d’un incrément, déroulé. On amorce une fois (spec, contrat, gouvernance), puis on répète ce cycle de huit étapes (ADR, UML, contrat, tests, code, lesson, revue, commit) autant de fois qu’il y a d’incréments, avec le TDD en boucle interne autour des tests et du code, et on livre. C’est ce qui rend la vélocité sûre : une mécanique répétable, pas de l’improvisation.

5. Conclusion : un multiplicateur pour un architecte discipliné

On revient au tout début. Le vibe coding « au feeling », celui qui fait peur (et qui le mérite, vu les 45 % de code vulnérable), n’est pas ce que j’ai pratiqué. Ce que j’ai pratiqué, c’est un multiplicateur pour un architecte discipliné. L’IA apporte la vélocité ; la rigueur, c’est mon travail. Retirez la rigueur, le multiplicateur amplifie le chaos. Gardez-la, il amplifie la qualité.

Et c’est là que se referme la thèse de la série : un profil non technique n’aurait pas atteint ce niveau. Pas parce qu’il serait moins intelligent, mais parce que les décisions qui ont fait la qualité de ecom ne sont pas des décisions de code, ce sont des décisions d’architecte. Le choix d’hébergement et de portabilité cloud. Les compromis de performance et de scalabilité. L’architecture globale et ses frontières. Le choix des technologies et des bibliothèques (et leur vérification). La sécurité des données et le RGPD. À chacun de ces carrefours, l’IA proposait des options crédibles ; il fallait quelqu’un pour trancher en connaissance de cause. Un opérateur qui ne sait pas pourquoi une transaction unique sur quatre modules est une mauvaise idée n’aurait jamais demandé la saga. Il aurait eu un e-commerce qui marche, et une dette technique abyssale dessous.

Car c’est ça, le « résultat » que je visais, et ce n’est pas l’UX ni l’UI. C’est la maintenabilité et l’évolutivité dans le temps. Une application qu’une équipe peut reprendre, comprendre (grâce à la doc et aux lessons), faire évoluer (grâce aux frontières nettes) et exploiter (grâce à l’observabilité), sans hériter d’un château de cartes. Le vibe coding dirigé ne produit pas du code jetable plus vite : il produit du code durable, plus vite, à condition d’être dirigé par quelqu’un qui sait ce que « durable » veut dire.

« Je dirige, l’IA exécute. » Cinq articles plus tard, la formule tient toujours. C’était le pari ; les chiffres le valident.

✅ À retenir (et fin de la série)

• Le vibe coding dirigé est un multiplicateur : vélocité réelle, cohérence, doc transversale toujours à jour, et une IA qui touche tout le cycle (fonctionnel, archi, code, doc, tests).
• La qualité se mesure et elle est bonne parce que le cadre l’a exigée : build 0 warning, domaine à 91,8 %, mutation testing à 77,9 %, zéro CVE critique, zéro secret en clair, Quality Gate Sonar OK. Avec des verrues assumées (68 erreurs de lint front, pas de CI).
• Le coût annoncé (environ 1 500 à 1 700 $ équivalent API) n’est pas ce qui a été payé : l’abonnement écrase le tarif à l’usage (15 à 20 fois moins cher pour cet usage), et c’est la lecture de cache qui domine la facture catalogue, pas ce que l’IA écrit.
• Le risque du vibe coding est réel et chiffré (45 % de code IA vulnérable, 84 % d’adoption pour une confiance au plus bas) : nos garde-fous en sont la réponse directe.
• Un profil non technique n’aurait pas atteint ce niveau : le vrai livrable n’est pas l’UX, c’est la maintenabilité sans dette abyssale, et elle vient des décisions d’architecte.

🧪 À vous de jouer. Le projet est open-source et public : github.com/glautrou/ecom. Vous pouvez tout lancer en une commande Docker (voir le bloc « Essayez vous-même » de l’article 1), explorer le code, lire les ADR et les lessons, et manipuler la page Simulation / Lab. La meilleure façon de juger un retour d’expérience, c’est de mettre les mains dedans.

Merci de m’avoir suivi sur ces cinq articles.

🛠️ À améliorer (la synthèse de toute la série)

Pour rester honnête jusqu’au bout, voici ce que je ferais différemment, rassemblé une dernière fois :

• Scoper serré dès le premier incrément, au lieu de l’apprendre « à la dure » (la cascade de six bugs). Des tranches plus petites, tout de suite.
• Utiliser GitHub spec-kit, largement populaire, plutôt que de créer mes propres commandes Spec-Driven Development.
• Des git worktrees plutôt que des répertoires disjoints pour le parallélisme d’agents : une vraie isolation des copies de travail, moins de collisions, moins de débordements (recommandation Anthropic).
• Plus de hooks déterministes et des gates de CI. Le sweep qualité, le lint, le scan de sécurité devraient casser une build en équipe, pas rester des consignes advisory. Une violation doit faire mal toute seule.
• Le mode headless (claude -p) pour automatiser revues, migrations et sweep qualité dans une pipeline, au lieu de tout déclencher en interactif.
• Évaluer les agents et les skills comme du code (des évals) : un agent de revue, ça se teste aussi. Pratique émergente que je n’ai pas mise en place.
• Protéger main + PR obligatoires + reviewers dès qu’on est en équipe (par exemple via une branch policy bloquante). Notre POC committait direct sur main : assumé en solo, à ne pas reproduire à plusieurs.