J’ai vibe-codé une application e-commerce complète avec Claude Code

Série « Vibe coding avec Claude Code » · Article 1/5. Un retour d’expérience honnête sur la
construction from-scratch d’une vraie application, dirigée par un architecte, exécutée par l’IA.

Sommaire de la série :

1. J’ai vibe-codé une application e-commerce complète avec Claude Code (cet article)
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

En quelques jours, j’ai construit une application e-commerce complète. Pas une banale démo jetable, mais une application event-driven, production-grade : modules découplés, bus de messages, saga de paiement avec compensation, event sourcing, projections, télémétrie, tests d’intégration. Le tout from-scratch, en dialogue avec Claude Code.

Le mot qui fâche, c’est « vibe coding ». Il évoque l’image du développeur (ou de n’importe qui) qui lâche les commandes et laisse l’IA pondre du code au feeling, du moment que le simple rendu visuel soit satisfaisant. Ce n’est pas ce que j’ai fait, et c’est tout le sujet de cette série. Mon fil rouge tient en quatre mots :

Je dirige, l’IA exécute.

Dans ce premier article, je pose le pari, le contexte, et je vous fais visiter ce qu’on a réellement
livré. Les articles suivants ouvriront le capot : le fonctionnel, l’architecture, la méthode, et le
bilan (vélocité, limites, coût).

🤖 Quel outil, et pourquoi ? J’ai utilisé Claude Code (Anthropic) : un assistant agentique en ligne de commande, pas de la simple complétion dans l’éditeur (à la Copilot). Il lit le dépôt, lance builds et tests, édite plusieurs fichiers, délègue à des sous-agents et appelle des outils externes : exactement ce qu’exige un mode « je dirige, il exécute ». D’autres outils sont agentiques (GitHub Copilot, Cursor, OpenAI Codex) ; mon choix tient à sa tenue sur les tâches longues et complexes et à son écosystème (agents, skills, hooks, MCP). Au-delà de ce projet, au quotidien et en cadre professionnel, Claude est très performant pour mon métier. Le coût réel (abonnement contre équivalent API) est disséqué à l’article 5.

1. Le vibe coding, c’est quoi, et ce que ce n’est pas

Le « vibe coding », popularisé début 2025, désigne une façon de programmer où l’on décrit son intention en langage naturel et où l’IA génère le code, qu’on accepte et qu’on itère. Dans sa version la plus brute « au feeling » on regarde à peine le résultat tant que « ça marche ».

Cette version-là est séduisante mais surtout dangereuse. Le code généré a l’air propre, passe les tests basiques… et cache des cas limites manqués, de la sur-ingénierie, parfois des failles. La dette
technique devient invisible et s’accumule de manière incontrôlée. (On chiffrera ce risque, études à l’appui, dans l’article 5 ; pour l’instant, retenez l’intuition.)

Ce que j’ai fait est à l’opposé de « l’IA dans son coin » :

• Je décide l’architecture. Modular monolith event-driven, hexagonal, DDD, CQRS, un seul agrégat event-sourced… ces choix sont co-décidés en dialogue, pas subis. L’IA propose des options et me challenge ; je tranche.
• Je cadre avant de coder. Une documentation socle, un contrat d’API gelé, des règles
  d’architecture encodées une fois pour toutes. L’IA code vers ce cadre.
• Je conserve les garde-fous. Tests d’intégration, revues automatisées par des agents dédiés
  (correction, sécurité), check de couverture. L’IA n’a jamais le dernier mot sur « c’est bon ».

🧭 Ça porte un nom. Cette discipline de spécifier d’abord, dériver le plan, puis générer le code s’est imposée en 2025-2026 sous le nom de spec-driven development, précisément en réponse aux dérives du vibe coding « au feeling ». On y reviendra en détail (articles 3 à 5). L’idée à retenir dès maintenant : le résultat est robuste parce qu’il est dirigé, pas malgré le fait qu’il soit généré.

Autrement dit : le vibe coding n’est pas un interrupteur « on/off » sur le cerveau de l’ingénieur.
C’est un multiplicateur, et un multiplicateur amplifie aussi le manque de rigueur. La rigueur,
c’est mon travail. La vélocité, c’est le sien.

2. Le contexte : démontrer l’event-driven, et pousser l’IA au-delà du CRUD

Je suis architecte .NET / Azure, une vingtaine d’années de développement et d’architecture derrière moi. Les architectures distribuées, event-driven, hexagonales, je les conçois, je les défends en réunion et je les livre en production. L’objectif de ecom n’était donc pas de les apprendre, mais d’en faire deux choses.

Les démontrer. Event sourcing, saga avec compensation, cohérence éventuelle, projections : ces patterns restent abstraits pour beaucoup de développeurs tant qu’ils n’en ont pas vu un vrai exemple tourner. Je voulais un support concret et réaliste pour les transmettre : du code que des pairs peuvent lire, exécuter et manipuler, doublé de lessons pédagogiques écrites sur ce code-là, pas sur de la théorie. Faire monter des développeurs en compétence sur du tangible plutôt que sur des slides.

Et pousser l’IA là où c’est difficile. N’importe quel assistant génère un CRUD. La vraie question d’architecte, c’est : tient-elle la route sur du production-grade ? J’ai donc délibérément mis sur la table quatre comportements qui séparent une vraie architecture distribuée d’une application jouet, et qui ne deviennent parlants qu’une fois qu’on les voit tourner :

1. Un changement dans un module qui en affecte un autre, sans couplage direct.
2. Le mécanisme de communication entre modules : en mémoire vs. via un broker (RabbitMQ).
3. Quel modèle de cohérence pour quelle interaction : transactionnel, eventual, ou
   saga/compensation ?
4. La synchro d’un tiers (Elasticsearch) et son eventual consistency.

Tout le reste de l’application n’est qu’un véhicule pour rendre ces quatre choses visibles et
manipulables. D’où une règle d’or que je me suis fixée, et que j’ai répétée à l’IA à chaque incrément :

« Le domaine est la seule chose simplifiée. Tout le reste est production-grade. Pas de TODO, pas
d’exceptions avalées, pas de raccourcis. Le bon correctif l’emporte sur le correctif rapide,
toujours. »

Concrètement, le domaine fonctionnel est volontairement banal, un e-commerce que tout le monde comprend : des produits, un panier, des commandes, du stock, de l’expédition, un paiement (factice), des e-mails, une recherche. Banal exprès : l’intérêt n’est pas le métier, c’est la plomberie autour.

💡 Claude me connaissait déjà. Mon profil (architecte .NET / Azure) est renseigné dans sa
configuration globale. Résultat : il pose des questions de niveau pair et ne me fait pas de cours sur les bases. Détail révélateur : connaissant ma stack, il me proposait spontanément du React pour le front. J’ai délibérément choisi Svelte pour m’observer le diriger sur une techno que je maîtrise moins bien (là où .NET, je le maîtrise parfaitement). On verra à l’article 5 pourquoi le profil de celui qui dirige change tout.

3. Ce qu’on a réellement livré : le tour visuel

Assez de concepts. Voici l’application. Trois surfaces.

La boutique (storefront)

Un front public en SvelteKit (SSR, Server-Side Rendering) : catalogue, fiche produit avec images et cross-selling, panier, checkout, paiement, suivi de commande. Connexion via Keycloak.

La boutique côté acheteur : catalogue, images, catégories.

Fiche produit avec cross-selling.

La recherche est servie par Elasticsearch, avec facettes (catégorie, prix, disponibilité) et elle
est eventually consistent : quand l’admin modifie un produit, la recherche se met à jour en arrière-plan, via un événement, pas dans la même transaction. C’est l’objectif n°4 rendu tangible.

Recherche Elasticsearch à facettes, alimentée par événements, en cohérence éventuelle.

Le back-office (admin)

Un front d’administration en SvelteKit (SPA, Single-Page Application) : gestion du catalogue, des stocks, de l’expédition, des acheteurs et de leurs commandes, des comptes admin.

Le back-office : point d’entrée vers chaque surface (catalogue, stock, expédition, reporting, acheteurs, comptes admin, page Lab).

Le clou du spectacle : la page Simulation / Lab

C’est la surface qui justifie tout le POC. Une page d’administration dédiée qui rend les patterns
visibles et manipulables :

• Des indicateurs techniques en direct : profondeur de l’outbox, retard des projections (projection lag), file de messages morts (DLQ), états des sagas en cours, concurrence des consommateurs.
• Des scénarios à injecter : rejeter un paiement et regarder la compensation se déclencher
  (le stock réservé est relâché, la commande passe à Cancelled) ; casser un stock ; lancer un
  import en masse ou un rebuild à chaud d’un index.

En d’autres termes : on provoque les situations difficiles d’une architecture distribuée et on les
observe se résoudre, en temps réel, dans le navigateur. C’est la différence entre lire un schéma de
saga et voir la saga compenser sous ses yeux.

La page Simulation / Lab, la capture signature : indicateurs en direct (profondeur d’outbox, retard de projection, DLQ, sagas en vol, concurrence), injection de pannes (paiement, stock), et triggers (import de masse, rebuild à chaud).

🔍 Domaine simple, plomberie puissante. Le métier est trivial, la surface technique, elle, ne l’est pas : recherche plein-texte à facettes (Elasticsearch), event sourcing, saga avec
compensation, projections, télémétrie. C’est délibéré : pour vraiment juger ce qu’une IA sait faire, il faut un terrain réaliste et des cas d’usage qu’on croise en production, pas un CRUD de tâches todo.

4. Le chiffre qui interpelle

Voici ce que représente l’application aujourd’hui (chiffres vérifiés dans le dépôt, pas estimés) :

Et le chiffre qui surprend le plus : le cœur de l’application a été construit en moins d’une semaine.

⚠️ À lire avec la bonne grille. Ces chiffres mesurent du volume produit, pas une preuve de
perfection. Et « moins d’une semaine » n’est ni un record ni une promesse universelle : c’est le rythme d’un architecte expérimenté, en immersion, qui investit d’abord dans un cadre (on chiffrera cet investissement initial à l’article 3). Le but n’est pas de vous vendre de la vitesse magique mais de montrer ce qu’un humain discipliné + une IA bien dirigée produisent ensemble.

La qualité, elle, n’est pas un angle mort de cette série : build sans warning, couverture sous garde, et des analyses qualité / sécurité automatisées et quantifiées (rapports à l’appui, suivies dans le temps). On ouvre le capot aux articles 4 et 5.

L’important n’est pas la vitesse seule. C’est que ce qui a été produit est cadré, testé et documenté :
38 décisions tracées, 30 diagrammes, 17 notes d’apprentissage, ~22 000 lignes de documentation et d’UML : le Markdown seul (~17 k) dépasse tout le code front. On construira sur ce point dans toute la série.

5. Le fil rouge et le plan de la série

Si vous ne deviez retenir qu’une phrase de ces cinq articles : on n’a pas remplacé l’architecte par
l’IA mais on a démultiplié l’architecte avec l’IA. L’IA a touché tout le cycle : le fonctionnel,
l’architecture, le code, la documentation, les diagrammes, les tests. Mais à chaque étape, un humain dirige, challenge et valide.

• Article 2 : Avant le code : faire produire le fonctionnel par l’IA. Recueil des besoins, affinage,
  découpage en incréments, et le rôle de Claude comme analyste / PO, pas seulement développeur.
• Article 3 : Préparer le terrain : doc, archi et gouvernance avant la première ligne. Le
  brainstorming d’architecture décidé ensemble, la doc socle multi-équipes, et le différenciant : la
  gouvernance Claude (agents, commandes, règles encodées).
• Article 4 : La méthode au quotidien : comment Claude code, et comment je garde le contrôle. Le cycle d’un incrément, le contrat d’API comme point de synchro, l’équipe d’agents (dont revue de code et sécurité automatisées), et l’anecdote d’une cascade de 6 bugs invisibles au build.
• Article 5 : Bilan : ce que ça apporte, ce que ça coûte, et la recette à réutiliser. Les positifs,
  les limites assumées, le coût en tokens, la qualité technique mesurée et suivie dans le temps (build, couverture, scans sécurité, le tout quantifié, preuves à l’appui), et une checklist actionnable pour votre prochain projet.

🧪 Essayez vous-même

Le projet est open-source et public. Le plus simple : tout lancer avec Docker, en une seule
commande : aucun autre outil à installer (ni .NET, ni Node).

1. Installer Docker Desktop (Windows : winget install -e --id Docker.DockerDesktop ;
   macOS/Linux : voir le guide), puis le démarrer.
2. Récupérer le projet :

   git clone https://github.com/glautrou/ecom
   cd ecom
   

3. Tout construire et démarrer (1ʳᵉ fois : ~5 à 15 min, le temps de construire les images) :

   docker compose -f docker-compose.demo.yml up --build -d
   

4. Ouvrir la boutique sur http://localhost:3000 ou l’admin sur http://localhost:4000,
   et se connecter avec un compte de démo.

Cette unique commande lance tout : l’infrastructure, la création de la base, le chargement d’un
catalogue de démo, les services back-end et les deux interfaces.

👉 Guide pas-à-pas (Docker) : démarrage rapide
· Pour les développeurs (build manuel) : guide local

Comptes de démo : buyer / DevPass!1 (acheteur) · admin / DevPass!2 (admin : 2FA à scanner au 1er login). 🔒 Identifiants dev-only / local (POC), pas des secrets réels.

✅ À retenir

• Le vibe coding utile n’est pas « l’IA code à ma place » mais « je dirige, l’IA exécute ».
• Une vraie application event-driven, production-grade a été construite from-scratch en moins
  d’une semaine pour le cœur : cadrée, testée, documentée (38 ADR, 30 UML, 17 lessons, build 0 warning).
• Le domaine est simplifié exprès ; tout le reste (fiabilité, tests, télémétrie) est sérieux.
• La page Simulation/Lab est la vitrine : elle rend les patterns distribués visibles et
  manipulables.
• La qualité technique n’est pas un angle mort : build sans warning, couverture, scans sécurité,
  mesurés, quantifiés et suivis dans le temps (détaillés aux articles 4-5).

➡️ Article suivant : « Avant le code : faire produire le fonctionnel par l’IA ». Comment décrire un domaine en langage naturel et laisser Claude le structurer, le reformuler et le découper : l’IA dans le rôle de l’analyste, bien avant la première ligne de code.

🛠️ À améliorer (transparence)

Cet article est une accroche : il montre le résultat, pas encore la méthode ni ses ratés. Pour
rester honnête dès le départ :

• Les chiffres impressionnent mais mesurent du volume, pas la qualité absolue. La suite assumera les limites (gros contextes qui débordent, ce que les tests unitaires ratent, là où l’IA se trompe).
• La vélocité affichée n’inclut pas le coût d’amorçage de la gouvernance (agents, contrat, règles,
  doc socle). Cet investissement initial est réel ; on le quantifiera à l’article 3.
• « Quelques jours » dépend fortement de l’opérateur (architecte expérimenté) et n’est pas une
  promesse transposable telle quelle. La recette réutilisable (article 5) vise justement à rendre la
  démarche reproductible.