La méthode au quotidien : comment Claude code, et comment je garde le contrôle

Série « Vibe coding avec Claude Code » · Article 4/5. Le cadre est posé (articles 2 et 3). Maintenant il tourne. Voici la boucle d’un incrément, le contrat qui synchronise le front et le back, l’équipe d’agents qui produit et qui relit, et le garde-fou qui a vraiment compté : les tests d’intégration.

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 (cet article)
5. Bilan : ce que ça apporte, ce que ça coûte, et la recette à réutiliser

Dans les trois premiers articles, j’ai montré le résultat, le fonctionnel produit par l’IA, puis le socle technique et la gouvernance. Tout ça, c’était la mise en place. Cet article entre dans le moteur : à quoi ressemble, concrètement, une journée de construction. Comment un incrément naît, mûrit, est testé, relu et livré. Et surtout, où je garde la main. Mon fil rouge ne bouge pas :

Je dirige, l’IA exécute.

L’article 3 a présenté les agents, le skill, les commandes, les hooks. Ici, on ne les présente plus : on les voit travailler. La différence entre « j’ai des agents » et « mes agents produisent du code de qualité, en parallèle, sous contrôle » est exactement ce que je veux rendre tangible.

1. La boucle d’un incrément : penser avant de frapper

Un incrément, ce n’est pas « demander une fonctionnalité et regarder le code apparaître ». C’est une boucle ordonnée, la même à chaque fois, où le code arrive en avant-dernier. Cette boucle est même encodée dans une commande maison (/new-increment) : une session fraîche la lit et déroule les étapes dans l’ordre, sans que j’aie à les redicter.

La boucle d’un incrément. Les trois premières étapes sont du design (on décide, on modélise, on fige l’interface) ; le code n’arrive qu’en étape 5, une fois les tests écrits. Diagramme et code avancent ensemble et sont livrés dans le même commit.

Le détail qui change tout est l’ordre. On écrit d’abord la décision (l’ADR), puis on modélise le domaine en UML, puis seulement on dérive le contrat d’API de ce modèle. Les formes de données suivent le domaine, on ne les invente jamais à l’avance. Ensuite on écrit les tests qui échouent (TDD), et c’est seulement là que le code est produit, pour faire passer ces tests. Vient enfin la note pédagogique (la lesson), puis la revue par des agents dédiés, puis la vérification (build, tests, couverture, contrat) et le commit.

Pourquoi tant de cérémonie ? Parce que c’est exactement ce qui sépare un POC robuste d’un tas de code plausible. L’étape de design force la réflexion avant la frappe ; les tests d’abord forcent à définir « correct » avant d’écrire ; la lesson force à comprendre ce qu’on vient de faire. À chaque étape, l’IA exécute, mais le cadre l’oblige à le faire dans le bon ordre.

2. Le contrat d’API, point de synchro entre le front et le back

Une application, ici, c’est deux mondes qui doivent se parler : un back-end .NET et deux fronts SvelteKit. Le risque classique, quand on génère du code des deux côtés, c’est qu’ils divergent sans qu’on s’en aperçoive : le back renvoie une forme, le front en attend une autre, et ça casse à l’exécution, en production.

La parade tient en un fichier : un contrat d’API (au format OpenAPI), écrit à la main et gelé avant le code. C’est la loi. Et les deux côtés s’y plient de façon dissymétrique :

• Le back implémente vers le contrat : il doit exposer exactement les routes et les formes décrites, ni plus ni moins.
• Le front génère son client depuis le contrat : un outil (Orval) lit le contrat et produit automatiquement les types TypeScript et les fonctions d’appel. Le front ne réécrit jamais une forme à la main.

Le code généré du front est un artefact de build : jamais édité à la main, jamais versionné, régénéré à la commande (pnpm gen:api). Et c’est là qu’est la beauté du dispositif : si le contrat change d’une manière qui casse ce que le front consomme, ça ne passe pas inaperçu, ça casse la compilation du front. La dérive devient une erreur de build, pas un bug de production. Une commande maison (/verify-contract) vérifie d’ailleurs les deux côtés d’un coup : le verdict est CONTRACT OK ou la liste des dérives, avec le côté qui doit s’aligner.

🧭 Ça porte un nom (suite). Ce contrat gelé dont on dérive le code, c’est du spec-driven development appliqué à l’interface : une spécification exécutable. Elle ne décrit pas seulement l’API, elle la contraint. Tout écart est rattrapé mécaniquement, à la compilation, des deux côtés. C’est le même esprit que la doc-source de l’article 3, descendu au niveau de la couture entre deux équipes.

3. Une architecture qui mûrit : les ADR au fil de l’eau

L’article 3 a montré comment les fondations sont verrouillées une fois pour toutes, pour ne pas les re-débattre à chaque session. Mais « verrouillé » ne veut pas dire « figé ». Le socle est stable ; le design, lui, s’étoffe incrément par incrément, en co-décision, quand le besoin réel apparaît.

L’exemple le plus parlant est la saga de paiement. Au départ, le checkout était simple. Puis il est devenu vraiment transverse : passer une commande touche la commande, le stock, le paiement, l’expédition. Quatre modules, quatre stores. À ce moment précis, une question d’architecture s’est imposée : comment coordonner un processus qui traverse plusieurs modules, sans en faire une seule grosse transaction (ce que les règles interdisent) ? La réponse a été tranchée en dialogue, puis figée dans une nouvelle décision d’architecture (l’ADR sur la saga). Elle n’existait pas au début du projet. Elle est née quand le besoin est arrivé.

C’est ça, une architecture dirigée plutôt que subie : on rouvre le design quand un incrément l’exige, on pèse les options avec l’IA, on décide, et on trace la décision. Le résultat n’est pas une archi pondue d’un bloc au jour un, mais une archi qui mûrit avec l’architecte, chaque ADR capturant le pourquoi du moment où elle a été prise.

💡 La nuance qui compte. Re-décider quand le besoin l’exige, ce n’est pas re-débattre les fondations à chaque session. Le fondamental est verrouillé ; ce qui s’ouvre, ce sont les questions nouvelles qu’un incrément fait émerger. La saga n’a pas remis en cause le monolithe modulaire : elle a répondu à une question que seul le checkout transverse pouvait poser.

La saga ne s’appelle pas en chaîne : elle envoie des messages sur un bus (RabbitMQ), et chaque module y réagit indépendamment. C’est la chorégraphie (R13), et le broker absorbe la contre-pression (R12).

La console RabbitMQ de la stack lancée : 35 files durables, une par type d’événement d’intégration (ProductCatalogedV1, OrderPlacedV1, StockReservedV1, PaymentConfirmedV1, UserLoggedInV1…) et par commande de saga. Chacune route vers une file de messages morts (le badge DLX) : c’est la chorégraphie (R13) et la contre-pression (R12), pour de vrai.

4. L’équipe d’agents en action

Voici le cœur du « au quotidien ». Les six agents de l’article 3 (architecte, lead back, lead front, relecteur de code, analyste sécurité, DBA) ne travaillent pas chacun leur tour dans un coin. Ils s’orchestrent, souvent en parallèle, dans une chorégraphie que j’ai affinée incrément après incrément.

L’orchestration qui a marché. L’architecte sert de porte d’entrée (il décide, il n’écrit pas le code applicatif). Puis le back et le front avancent en parallèle, dans des répertoires séparés, tous deux reliés au même contrat gelé. Puis les relecteurs passent en parallèle, chacun en contexte frais. Un seul agent applique les corrections par tour de revue. Je garde la main sur les étapes humaines : lesson, vérification finale, commit.

Deux idées rendent cette orchestration efficace, et elles recoupent les recommandations officielles d’Anthropic.

Le parallélisme là où c’est sûr. Le back vit dans src/, le front dans apps/. Comme ils touchent des répertoires disjoints et qu’ils sont tous deux contraints par le même contrat gelé, ils peuvent travailler en même temps sans se marcher dessus. Pendant qu’ils produisent, le thread principal reste libre.

La revue en contexte frais. Un relecteur qui ne voit que le diff, pas le raisonnement qui l’a produit, juge mieux. C’est documenté par Anthropic (Building Effective Agents) : un sous-agent en contexte séparé relit sans être contaminé par les justifications de celui qui a écrit. Mes relecteurs sont explicitement contradictoires : ils cherchent le problème avant que la production ne le trouve, sans complaisance. Le verdict est binaire et chiffré, par exemple :

VERDICT: FIX-FIRST (0 blockers, 3 majors, 1 minor)
  [major] R2 : un effet post-commit en mémoire pourrait être perdu au crash ; passer par l'outbox.
  [major] le tri du endpoint accepte une colonne hors liste blanche → risque d'injection ; restreindre.
  [major] un même message redélivré ré-applique l'effet ; rendre le handler idempotent.
  [minor] message d'erreur 500 là où un 409 serait plus juste.
SECURITY: PASS (1 medium URL-escaping → corrigé)

Ces verdicts ne sont pas décoratifs. Sur plusieurs incréments, les relecteurs ont sorti des FIX-FIRST avec des majors réels, corrigés avant le commit. Le relecteur n’a jamais le dernier mot sur « c’est bon » (un relecteur trouve toujours des « gaps »), mais il déplace la barre : on ne commite pas un diff que personne d’adversarial n’a regardé.

Une revue d’incrément réelle. Les agents tournent en contexte frais, ne voient que le diff, et rendent un verdict binaire et chiffré. Ici un FIX-FIRST avec trois majors (tous corrigés avant le commit), suivi d’un PASS sécurité. Pas de complaisance, pas d’élargissement du périmètre.

🔍 Le pattern Anthropic derrière tout ça. La doc d’Anthropic (Best practices, Effective harnesses for long-running agents) insiste sur deux choses que j’ai appliquées sans le savoir au début, puis sciemment : donner à Claude un moyen de vérifier son travail (tests, build, capture) et séparer l’écriture de la relecture (writer / reviewer). Mes agents de revue sont la version « équipe » de ce principe. La revue adversariale avant de déclarer « fini » est une étape, pas une option.

5. Le vrai garde-fou : les tests d’intégration

S’il y a une seule chose à retenir de cet article, c’est celle-ci. Le build qui passe et les tests unitaires verts ne prouvent presque rien sur un système distribué. Le vrai garde-fou, c’est l’intégration.

L’anecdote qui l’a gravée dans le projet : la cascade de six bugs de la saga de checkout. Voici le décor. Le checkout suit ce chemin :

Le flux de checkout, simplifié. Une commande passe par réservation du stock, paiement par l’acheteur, confirmation, puis expédition. En cas d’échec de paiement ou d’abandon, la compensation relâche le stock réservé et annule la commande. Ce n’est pas une transaction unique : c’est une suite d’étapes coordonnées, chacune réversible par une action compensatoire.

Ce chemin avait été codé, et tous les tests unitaires de la saga étaient verts. Pourtant, en l’exécutant pour la première fois de bout en bout contre une vraie infrastructure (Postgres, RabbitMQ, l’event store), il était mort. La commande restait bloquée. Le diagnostic a révélé non pas un bug, mais six défauts latents indépendants, empilés dans un chemin qui n’avait jamais tourné en conditions réelles :

1. Les événements produits par la commande n’étaient jamais ajoutés au flux de l’event store.
2. L’état de la saga était rangé dans le mauvais schéma de base.
3. Une façon d’enregistrer une dépendance était rejetée par le bus de messages.
4. Une clé technique mal choisie transformait un INSERT en UPDATE (zéro ligne).
5. La corrélation des messages de la saga échouait (un type d’identifiant contre un autre).
6. La lecture d’une table ne mappait pas les noms de colonnes.

Aucun de ces six défauts n’était visible au build. Aucun n’était attrapé par les tests unitaires, et pour cause : un test unitaire exerce les fonctions de la saga comme des fonctions. Il ne voit ni le graphe de découverte du bus, ni le schéma du store, ni le vrai sérialiseur, ni la vraie base. Seul un test d’intégration, qui démarre deux processus et une vraie infrastructure, pouvait faire passer une commande jusqu’à un état terminal et exposer toute la pile. La leçon, écrite noir sur blanc dans la note de l’incrément :

Une saga, c’est autant du câblage que de la logique ; seul un test de bout en bout prouve que les messages circulent vraiment.

C’est exactement le risque que l’industrie associe au code généré par IA : il a l’air propre, il passe les tests basiques, et il cache des défauts sur les cas limites (on y revient, chiffres à l’appui, à l’article 5). Ma réponse n’est pas de faire confiance, c’est de donner à l’IA, et à moi, un moyen de vérifier sur du réel. D’où une suite de tests à deux étages : des tests unitaires rapides pour le domaine (sans Docker), et des tests d’intégration qui démarrent de vrais conteneurs. Les seconds sont le filet qui attrape ce que les premiers ne peuvent pas voir.

Mieux : certains tests provoquent volontairement la panne. Pour prouver qu’une commande survit à un crash, j’ai des tests qui induisent le crash à l’instant précis qui fait mal, et vérifient l’état final. Leurs noms disent tout :

Crash_before_commit_rolls_back_both_the_order_stream_and_the_integration_event
An_in_memory_post_commit_side_effect_is_lost_on_crash_but_the_outbox_survives
Redelivery_after_a_lost_ack_appends_exactly_one_audit_row
A_crashed_checkout_worker_is_resumed_by_another_instance_from_durable_saga_state

Le deuxième est le plus instructif : il démontre la perte de données d’un raccourci interdit (un effet en mémoire après le commit), juste à côté de la version durable qui, elle, survit. On ne se contente pas d’affirmer que l’architecture est sûre : on le prouve, panne par panne.

Et quand le flux tourne pour de vrai, on peut le suivre de bout en bout. Chaque checkout porte un identifiant de corrélation qui relie tous ses fragments (la requête HTTP, les requêtes SQL, les messages du bus), à travers l’API et le Worker, dans un seul écran de télémétrie.

Un vrai checkout dans Seq, filtré sur un seul identifiant de corrélation. Les trois requêtes (ajout au panier, commande, paiement) apparaissent reliées, avec leurs requêtes SQL et la publication de l’événement PaymentConfirmedV1 sur le bus. Ce même identifiant se propage ensuite au Worker (R5), si bien que tout le flux distribué partage une seule trace, à la façon d’un APM.

On peut même s’en convaincre sans écrire la moindre ligne de test. La page Simulation / Lab permet de déclencher cette compensation à la main : son bouton « rejeter le paiement » force l’échec, et la branche de compensation du diagramme se joue sous vos yeux dans le navigateur. Tests d’intégration, trace corrélée, injection manuelle dans le Lab : trois angles pour vérifier le même comportement, au lieu de le supposer.

Deux interrupteurs de la page Simulation / Lab. « Payment outcome » sur Fail force l’échec du paiement : la saga compense, relâche la réservation de stock et annule la commande. « Stock reservation outcome » sur FAIL fait échouer la réservation avant tout paiement. On provoque la panne d’un clic, et on regarde la compensation se dérouler en direct dans les métriques juste au-dessus.

Mesurer la qualité, et en faire un garde-fou

Au-delà des tests et des revues, j’ai outillé la mesure elle-même. Une seule commande (fonctionnant sans Claude) lance tout l’arsenal qualité et sécurité du projet :

pwsh quality/run-quality.ps1

Derrière cette ligne : le build strict (zéro warning, sinon échec), la couverture de tests, le mutation testing (qui vérifie que les tests attrapent vraiment des fautes injectées, pas seulement qu’ils exécutent des lignes), le scan des dépendances vulnérables, la recherche de secrets dans tout l’historique git, le lint du front, l’analyse SonarQube, et même un scan dynamique du storefront. Chaque exécution écrit ses rapports bruts horodatés, ajoute une ligne à un ledger versionné, et régénère un tableau de bord autonome qui trace l’évolution, run après run.

Le tableau de bord du sweep qualité / sécurité (trend.html). Cartes de synthèse, table des runs, blocs détaillés (couverture, mutation, supply-chain, Sonar, scan dynamique). La qualité n’est pas une impression, c’est une série de mesures suivies dans le temps. Les chiffres détaillés sont à l’article 5 ; ici, c’est l’outil qui compte.

Le principe auquel je tenais absolument est une question d’honnêteté : un scanner non installé est marqué « non exécuté », jamais maquillé en zéro. Un faux zéro se lirait « propre » alors qu’il veut dire « pas mesuré », et c’est précisément le genre de mensonge confortable qu’on veut bannir d’un projet production-grade. La transparence vaut aussi pour les défauts : ce sweep est manuel, déclenché à la main. En équipe, il aurait sa place dans la CI, au même titre que les feature branches et les PR obligatoires (section 8).

⚖️ Honnêteté. La qualité ici n’est pas « l’IA propre par magie ». Elle est bonne parce que le cadre l’a exigée, incrément après incrément : build strict, couverture sous garde, revue adversariale, tests d’intégration, mesure suivie. Les chiffres (couverture du domaine, score de mutation, vulnérabilités, et les verrues assumées) sont disséqués à l’article 5. Ce qui compte ici, c’est la mécanique qui les produit.

6. Les lessons : documenter pour transmettre

À la fin de chaque incrément, j’écris (avec l’IA) une lesson : une note pédagogique qui explique une notion sur le code réel qu’on vient d’écrire, pas sur de la théorie. Ce n’est pas de la documentation de complaisance. C’est l’un des actifs les plus précieux du projet.

Chaque lesson suit la même trame : le concept (en clair), dans cette base de code (les vrais fichiers, les vraies méthodes), les compromis, et les alternatives écartées et pourquoi. Un exemple, tiré de la lesson sur la saga, qui montre le lien direct entre une notion et le code qui l’incarne :

Le concept. Un processus métier qui traverse plusieurs modules ne peut pas être une seule transaction de base de données. Deux formes le coordonnent : la chorégraphie (chacun réagit à l’événement du précédent, sans chef d’orchestre) et l’orchestration (un gestionnaire de processus tient l’état et décide de l’étape suivante).

Dans cette base de code. CheckoutSaga est une saga avec état, corrélée par l’identifiant de commande, qui tourne dans le Worker (l’API ne l’exécute jamais). Le checkout est orchestré parce qu’il a un vrai état de processus (une réservation à relâcher si le paiement échoue) ; l’expédition, qui ne fait que réagir à « la commande est confirmée », est chorégraphiée. Le même système utilise les deux, exprès, pour que le contraste soit visible.

Le lecteur apprend la différence entre orchestration et chorégraphie en lisant le fichier sur le code qu’il va devoir maintenir. C’est la différence entre un cours abstrait et un savoir situé. Pour une équipe, ces lessons sont un onboarding et une montée en compétence contextualisée : un nouveau développeur n’apprend pas l’event sourcing sur des slides, il l’apprend sur Order. Et fait notable, ces notes consignent aussi les pièges rencontrés, y compris la fameuse cascade de six bugs : la mémoire du projet inclut ses propres cicatrices.

Un extrait de la lesson sur la saga. La notion (orchestration contre chorégraphie) est expliquée, puis ancrée sur les vrais fichiers du dépôt (les chemins mis en évidence), et le piège rencontré est consigné. On apprend la notion sur le code qu’on va maintenir.

7. L’art de guider

Tout ce qui précède repose sur une compétence qui ne s’automatise pas : savoir guider. Quelques pratiques qui ont fait la différence au quotidien.

Des points de contrôle humains. Je ne lance pas un incrément et je ne reviens pas une heure plus tard. Je valide le design avant le code, je lis les verdicts de revue, je décide des corrections, je tampone la lesson et le commit. L’IA produit en continu ; l’humain ponctue.

Le scoping des tâches. C’est la leçon apprise à la dure (la cascade de six bugs en est née en partie). Un agent à qui on demande de construire un module entier d’un coup déborde : il atteint la limite de contexte et échoue. La parade est de scoper serré : une tranche, un endpoint, un handler et son test. Plus petit l’incrément, plus bornée la tâche, moins cher l’échec quand il arrive, et plus facile la revue.

Le brainstorming en début d’incrément. Avant d’écrire la moindre ADR, je rouvre la discussion : qu’est-ce que cet incrément doit prouver, quelles options, quels pièges. L’IA est un excellent partenaire de réflexion à ce stade, à condition de lui donner le cap. C’est l’esprit Explore puis Plan puis Code recommandé par Anthropic : ne pas résoudre le mauvais problème.

Le graphe de connaissance du code. Plutôt que de laisser l’IA scanner tout le dépôt à chaque question (lent et coûteux en tokens), un graphe structurel du code, tenu à jour automatiquement, répond aux questions « qui appelle quoi », « quel est l’impact de ce changement », « quels tests couvrent ce code ». L’agent interroge le graphe avant de toucher au code. Au quotidien, c’est moins de tokens brûlés et des réponses plus justes que grep à l’aveugle.

🔌 Diriger, ce n’est pas micro-manager. Je ne relis pas chaque ligne au moment où elle est tapée. Je conçois le cadre (le contrat, les règles, les agents, les tests) pour que les écarts deviennent visibles tout seuls : une dérive de contrat casse le build, un effet non durable est attrapé par un test de crash, un raccourci est levé par le relecteur. C’est ça, garder le contrôle d’une IA rapide : pas la surveiller en continu, mais rendre ses erreurs bruyantes.

8. Les garde-fous de versioning (une best-practice à ne pas zapper)

Il faut être honnête sur un point précis. Sur ce POC, j’étais seul, et j’ai commité directement sur main, par feature, sans pull request. C’est assumé pour un projet solo, et c’est même écrit dans la configuration du projet. Mais c’est exactement ce qu’il ne faut PAS reproduire en équipe.

Dès qu’on laisse une IA committer, la question devient : comment garde-t-on le pouvoir de vérifier ? La réponse est un garde-fou de versioning classique, mais d’autant plus crucial quand l’auteur du code est une IA rapide :

• Protéger main : interdire les poussées directes sur la branche critique.
• Imposer des feature branches : tout changement passe par une branche dédiée. Il faut le dire explicitement à Claude (sinon, par défaut, il commite là où on est).
• Rendre les PR obligatoires, avec reviewers et approbation requise avant merge. C’est ce que permet, par exemple, une branch policy Azure DevOps : exiger un nombre minimum de relecteurs, des relecteurs auto-assignés, un build vert, avant qu’un merge soit possible.
• Garder les commits petits : une fonctionnalité peu complexe (ou découpée quand c’est possible, ce qui ne l’est pas toujours) rend la revue faisable. Un énorme commit illisible défait l’intérêt du gate.

Le principe est simple : si on laisse Claude committer, il faut pouvoir vérifier, et le couple PR plus relecteur humain est ce qui le garantit. Microsoft le formule bien dans ses recommandations : garder une branche main toujours saine via une politique de branche qui exige une PR et un build propre. Mes agents de revue inline sont une bonne première barrière, mais en équipe, ils ne remplacent pas un gate de merge où un humain approuve. Les deux sont complémentaires : l’agent attrape tôt, le gate empêche tard.

9. À retenir

La qualité, dans cette méthode, ne vient pas de l’IA. Elle vient de trois choses combinées : un cadre (la boucle, le contrat, les règles encodées), des tests (et surtout les tests d’intégration, le vrai garde-fou), et des décisions gardées par l’humain (le design, les arbitrages, les commits). L’IA exécute vite et bien ; le contrôle, c’est mon travail, et il est conçu pour que les erreurs se signalent toutes seules.

✅ À retenir

• Un incrément suit une boucle ordonnée où le code arrive en avant-dernier : décision, modèle, contrat, tests, code, lesson, revue, commit.
• Le contrat d’API gelé synchronise le front et le back : le back implémente vers lui, le front génère son client depuis lui, et toute dérive casse le build.
• Les agents produisent et relisent en parallèle : implémentation back/front en répertoires disjoints, revue adversariale en contexte frais, un agent de fix par tour.
• Le vrai garde-fou, c’est l’intégration : une cascade de six bugs, invisible au build et aux tests unitaires, n’a été révélée que par les tests d’intégration sur une vraie infrastructure.
• La qualité se mesure (une commande, un ledger versionné, un tableau de bord), avec une règle d’or : un scan non exécuté est « non mesuré », jamais maquillé en zéro.
• En équipe, protéger main + PR obligatoires + reviewers : si l’IA commite, il faut pouvoir vérifier.

➡️ Article suivant (le dernier) : « Bilan : ce que ça apporte, ce que ça coûte, et la recette à réutiliser ». Les points positifs et les limites assumées, le coût réel (en tokens, et pourquoi l’abonnement écrase le tarif à l’usage), la qualité technique chiffrée (couverture, mutation, vulnérabilités, et les verrues), et une checklist actionnable pour votre prochain projet.

🛠️ À améliorer (transparence)

• Scoper serré dès le départ. J’ai appris « à la dure » que les gros dispatches d’agents débordent. La cascade de six bugs en est en partie l’illustration. La prochaine fois, je cadrerais des tranches plus petites dès le premier incrément, au lieu de l’apprendre en cours de route.
• Des worktrees plutôt que des répertoires disjoints. Mon parallélisme back/front reposait sur une séparation de dossiers. Anthropic recommande plutôt les git worktrees : une vraie isolation des copies de travail, donc moins de collisions et moins de débordements.
• Le mode headless en CI. Claude Code peut tourner en ligne de commande non-interactive (claude -p). On pourrait automatiser certaines revues, certaines migrations ou le sweep qualité dans une pipeline, plutôt que de tout déclencher à la main, en interactif.
• Évaluer les agents et les skills comme du code. Je n’ai pas mis en place d’évals (des tests qui mesurent si un agent ou un skill se comporte comme attendu). C’est une pratique émergente, et c’est la prochaine marche : un agent de revue, ça se teste aussi.