Par Thales (CEO, ZeroSuite) & Claude Fable 5 — instance Claude Code
Le 12 juin 2026, quelques minutes après minuit heure d'Abidjan, le fondateur a tapé une seule phrase dans une session Claude Code : « execute this docs/plan/sessions/PHASE-VITRINE-WEBSITE.md use a workflow or ultracode ». Quarante-trois minutes d'exécution du workflow plus tard, un site web de production complet de sept pages existait — rédigé, intégré, finalisé côté SEO, vérifié visuellement sur deux viewports par un navigateur headless, audité en performance et audité en sécurité — accompagné d'un nouvel endpoint backend, d'une migration de base de données et d'une exécution de tests bout en bout à 18/18. La session s'est conclue sur un seul commit : 44 fichiers, 6 109 insertions, poussé sur main, auto-déployé en production.
Deux premières ont eu lieu dans cette session. C'était la première fois que cette équipe faisait tourner Claude Fable 5, le premier modèle de la famille Claude 5 d'Anthropic, dans un vrai build. Et c'était la première fois que l'orchestration elle-même n'était pas improvisée par le modèle tour après tour, mais exécutée depuis un script JavaScript déterministe par le nouveau Workflow tool de Claude Code — phases, fan-outs, barrières et sorties structurées déclarées d'avance, puis exécutées jusqu'au bout en arrière-plan pendant que le fondateur regardait un arbre de progression.
Ce billet est le journal de build de cette session : ce qu'est le Workflow tool, à quoi ressemblait le script, pourquoi le pattern d'injection de contrat entre les phases est l'astuce porteuse, ce que les chiffres par agent disent de l'économie des builds parallèles, et ce qui s'est passé quand la limite de session du fondateur a atteint 92 % avec trois agents encore en cours.
Partie 1 — Le travail à accomplir
Le client est SENEBA Transport & Logistique, une compagnie de flotte à Abidjan exploitant une centaine de taxis-compteurs. Son ERP anti-fraude — construit au cours de la semaine précédente et documenté plus tôt dans les journaux frères de cette série — était en production sur seneba.ci. Mais l'entreprise n'avait aucune présence web publique. L'URL racine de son propre domaine redirigeait directement vers un écran de connexion. Le formulaire de candidature chauffeur existait à /candidature mais n'était lié nulle part. Le client avait fourni un PDF de présentation d'entreprise de neuf pages, et le projet disposait déjà d'un design system maison complet. Tout ce qu'il fallait pour un site marketing crédible existait ; personne ne l'avait assemblé.
La veille, le fondateur et l'agent s'étaient affrontés sur l'architecture — et le fondateur avait gagné. La première recommandation de l'agent était celle des manuels : un projet de site statique séparé sur un sous-domaine, avec une bascule DNS. Le fondateur a répliqué avec une seule question : pourquoi pas dans la même app, exactement comme les pages publiques existantes ? Une revue de code a tranché en sa faveur. L'app n'avait pas de groupes de routes ; son composant shell était importé page par page ; les pages publiques étaient déjà autonomes. Les pages marketing suivraient le même pattern, avec un ajout : export const prerender = true sur chaque route, de sorte que le build émette du HTML statique et que les arguments SEO et vitesse en faveur d'un projet séparé s'évaporent. Cette décision — même dépôt, même app, zéro travail DNS — a été gelée dans le prompt de session avec chaque fait d'entreprise tiré du PDF, sept spécifications de pages et un plan d'orchestration par sous-agents.
La session que ce billet documente partait donc d'une position inhabituellement forte : le quoi était entièrement spécifié, et le comment était explicitement délégué à l'orchestration multi-agents. Le « use a workflow or ultracode » du fondateur était l'opt-in. Il restait à traduire un plan markdown en orchestration exécutable.
Partie 2 — Ce qu'est réellement le Workflow tool
Jusqu'à cette session, le travail multi-agents de cette équipe passait par des fan-outs artisanaux : la boucle principale de Claude Code lançant des sous-agents via l'Agent tool, plusieurs par message, puis collectant leurs rapports comme résultats d'outils. Ça fonctionne, et plusieurs billets antérieurs de cette série décrivent des sessions construites ainsi. Mais la logique d'orchestration — quels agents tournent quand, qu'est-ce qui dépend de quoi, que se passe-t-il si l'un échoue — vit dans la mémoire de travail du modèle, redérivée tour après tour. Ça coûte du contexte, ça ne peut pas boucler de façon déterministe, et si la session meurt en plein fan-out, l'état de l'orchestration meurt avec elle.
Le Workflow tool inverse cela. L'orchestration est un script JavaScript, écrit une fois, exécuté par le harnais :
jsphase('Fondation')
const [fondation, backendContact] = await parallel([
() => agent(P0_FRONTEND_PROMPT, { schema: FOUNDATION_SCHEMA }),
() => agent(P0_BACKEND_PROMPT, { schema: BACKEND_SCHEMA }),
])
phase('Pages')
const pageResults = await parallel(PAGES.map((p) => () =>
agent(buildPagePrompt(p, fondation.contract), { schema: PAGE_SCHEMA })))
phase('Intégration')
const integration = await agent(INTEGRATION_PROMPT, { schema: REPORT_SCHEMA })Trois propriétés comptent. Le déterminisme — les phases, les dépendances et la gestion des échecs sont du code, pas de l'improvisation ; le même script avec les mêmes entrées produit la même orchestration. Les sorties structurées — chaque appel agent() porte un schéma JSON, et le sous-agent est contraint de retourner un objet validé, si bien que le script compose les résultats sans parser de la prose. Un journal de reprise — chaque appel agent() terminé est journalisé, et un workflow tué peut être relancé avec resumeFromRunId : les agents terminés rejouent leurs résultats en cache instantanément, à coût zéro en tokens, et seule la queue inachevée est réexécutée. Cette dernière propriété n'a finalement pas été nécessaire dans cette session, mais elle a façonné une décision sous pression — la Partie 6 raconte cette histoire.
Quand l'appel d'outil se déclenche, Claude Code montre au fondateur une boîte de dialogue de permission avec le plan des phases et un avertissement sans détour sur la consommation de tokens avant que quoi que ce soit ne tourne :
Le fondateur a choisi « Yes, run it ». Le workflow s'est détaché en arrière-plan, et la conversation est restée libre pour la suite — qui s'est trouvée être une discussion sur des captures d'écran de blog et une alerte de limite d'usage.
Partie 3 — Le script : cinq phases, une astuce porteuse
L'orchestration reflétait le squelette du plan : fondation séquentielle, pages en parallèle, intégration séquentielle, vérification en parallèle, audit en lecture seule. Treize agents au total. L'ingénierie intéressante se trouve dans les coutures.
Phase 1 — Fondation, deux agents en parallèle sur des fichiers disjoints. Le plan prévoyait une fondation séquentielle, mais la scinder était sans risque parce que les deux moitiés ne touchent jamais le même fichier : un agent a construit la coquille marketing frontend (header, footer, primitives de section, helper SEO) plus le stub de la page d'accueil à la route racine ; l'autre a construit le backend — une table messages_contact avec sa migration Alembic, un endpoint public POST /contact cloné depuis le pattern éprouvé des candidatures publiques (champ honeypot, rate limit Redis à fenêtre glissante réutilisant le mécanisme anti-bombardement de l'OTP, notification WhatsApp au siège), et le seul fichier frontend que l'agent de la coquille avait explicitement interdiction de toucher : le helper API. Les deux ont terminé en moins de neuf minutes, 86,1k et 88,5k tokens respectivement.
L'astuce porteuse : l'injection de contrat. La sortie structurée de l'agent de fondation incluait un champ nommé contract — une spécification écrite complète des quatre composants qu'il venait de construire : chemins d'import, chaque prop avec son type et sa valeur par défaut, variables CSS exposées, le pattern exact d'une page hero, les règles (« ne jamais réimplémenter le header », « toujours passer tone explicitement », « utiliser le WebP de 154 KB, jamais le PNG de 1,1 MB »). Le script du workflow a pris cette chaîne et l'a injectée telle quelle dans les prompts des sept agents de pages. Les agents de pages n'ont jamais eu à deviner l'API de la coquille ni à lire son code source pour en inférer l'intention — le producteur a documenté l'interface, et les consommateurs ont reçu la documentation dans leur briefing. Sept agents ont consommé un contrat avec zéro incohérence d'intégration. C'est le pattern qui a rendu la phase parallèle sûre : composants partagés gelés et documentés avant le fan-out, chaque agent de page n'écrivant que dans son propre répertoire de route, pas de worktrees nécessaires parce qu'aucun duo d'agents ne pouvait toucher le même fichier.
Phase 2 — Pages, sept agents en parallèle, une route chacun. Accueil, À propos, Services, Flotte, Technologie, Carrières, Contact. Chaque prompt portait le contexte commun (règles de design, typographie française avec espaces insécables, zéro emoji, mobile-first), les faits d'entreprise du PDF, la carte de navigation, le contrat de fondation — et pour la page Contact uniquement, le contrat de l'agent backend, pour que le formulaire se câble lui-même sur la signature réelle de l'endpoint.
L'économie de cette capture d'écran mérite une phrase. Les sept agents de pages ont consommé entre 53,2k et 63,8k tokens et entre 4m11s et 6m01s chacun — environ 34 minutes de temps d'agent cumulé. Coût en temps réel : six minutes, la durée de l'agent le plus lent (Carrières, qui avait le plus de travail de liens croisés). C'est tout l'argument du fan-out en un seul nombre : une journée de travail en mode « une page à la fois » est devenue le temps d'un café, sans conflit de fichiers partagés parce que les frontières avaient été tracées avant la naissance des agents.
Phase 3 — Intégration, un agent, accès complet en écriture. Après la barrière, un agent unique a vérifié la navigation contre les sept routes désormais existantes, complété le SEO par page en cartes Open Graph et Twitter complètes, généré une image de partage brandée de 1200×630, créé le sitemap.xml prérendu et le robots.txt (site marketing indexable, routes ERP interdites), ajouté une page d'erreur brandée, exécuté la passe d'accessibilité et de typographie française, et mené pnpm check et pnpm build jusqu'au vert. Il a aussi attrapé un vrai bug préexistant que personne ne lui avait demandé de chercher : le template HTML de l'app codait en dur un <title> avant le point d'injection du head de SvelteKit, ce qui signifiait que chaque page prérendue partait avec deux balises title et que les crawlers auraient gardé la mauvaise. Il a retiré le titre statique et ajouté un fallback conditionnel pour les routes ERP. Cette correction à elle seule aurait justifié la phase.
Phase 4 — Vérification, deux agents en lecture seule en parallèle. L'un a piloté un vrai navigateur à travers les sept routes en 390×844 et 1280×800 avec le harnais Playwright établi du projet : vérifications de débordement de scroll-width, présence du header/footer/nav, chaque lien interne récupéré, capture des erreurs console, et — la partie qu'aucune vérification statique ne remplace — la lecture effective des captures mobiles une par une. Verdict : 7/7 PASS, avec deux constats cosmétiques. L'autre agent a audité la sortie du build : les sept routes prérendues, aucun asset au-dessus de 200 KB chargé par une page marketing, le JavaScript initial de la page d'accueil à environ 94 KB gzippé, des titres et descriptions uniques sur les sept pages, zéro lien mort. Verdict : GO.
Phase 5 — Audit, un agent Explore en lecture seule. La règle permanente de ZeroSuite : chaque session qui livre un nouveau module ou touche un endpoint public reçoit un audit briefé et en lecture seule avant le commit. Le briefing pointait l'auditeur vers la classe de bugs qui avait déjà brûlé l'équipe — une barrière localhost sur un autre produit avait un jour fait confiance à request.client.host derrière un reverse proxy et authentifié l'IP privée du proxy comme étant le fondateur. L'auditeur a vérifié le nouvel endpoint public contre ce précédent, la migration, le chemin de notification, la discipline de prérendu et la conformité aux spécifications. Verdict : GO-WITH-FIXES — quatre constats, deux moyens et deux faibles, aucun critique, tous relevant de l'hygiène de déploiement plutôt que de défauts de code.
Partie 4 — Ce que disent les chiffres
Le workflow terminé a rapporté : 13 agents, 857 383 tokens de sous-agents, 388 appels d'outils, 42m58s du lancement à la valeur de retour finale.
Une décomposition approximative. Les deux agents de fondation ont coûté ~175k tokens et tourné en concurrence pendant 8,5 minutes. Les sept agents de pages ont coûté ~410k tokens et tourné en concurrence pendant 6 minutes. L'intégration, les deux vérificateurs et l'auditeur ont consommé les ~270k restants sur environ 28 minutes — l'intégration à elle seule est le chemin critique, parce qu'elle porte le cycle complet de pnpm build et la boucle correction-rebuild.
Trois observations face à l'ancienne façon de travailler :
- La compression du temps réel est réelle et importante. L'exécution séquentielle des mêmes charges d'agents aurait pris environ deux heures et demie. Le workflow a livré en 43 minutes — et l'attention du fondateur n'a été requise pour rien après le clic de permission.
- La facture en tokens est le prix de la compression. 857k tokens de sous-agents, c'est l'essentiel d'un budget de session dépensé en trois quarts d'heure. L'avertissement jaune de la boîte de dialogue de permission n'est pas décoratif. C'est un outil qu'on pointe sur du travail bien spécifié, pas sur de l'exploration — l'exploration en parallèle multiplie le gaspillage, l'exécution en parallèle multiplie le débit.
- La qualité de la spécification est le multiplicateur. Chacun des treize agents a reçu un briefing mesuré en milliers de mots : faits gelés, décisions d'architecture gelées, contrats de composants gelés, frontières de zones d'écriture explicites, attentes de vérification explicites. Zéro agent n'a retourné de travail inutilisable. La session précédant celle-ci — la session de cadrage où le fondateur a contesté l'architecture et où le plan a été écrit — est l'endroit où la vitesse de cette session a réellement été fabriquée.
Partie 5 — Ce qui a survécu au contact de la vérification
Le registre honnête de ce que les phases en lecture seule ont trouvé, parce qu'un fan-out qui se note lui-même « tout vert » sans contrôles externes, c'est du théâtre.
Les deux constats cosmétiques du vérificateur visuel étaient réels : le composant de statistique rendait son unité collée au nombre (« 566 963 100FCFA » au lieu de « 566 963 100 FCFA » — une subtilité de suppression d'espaces de Svelte à une frontière de bloc), et sur trois pages le sous-titre du hero reposait sur la partie la plus lumineuse de la photo de fond en 390 px, lisible mais limite. L'auditeur de performance a ajouté une note hors périmètre mais précieuse : les propres pages publiques de l'ERP — y compris le formulaire de candidature chauffeur vers lequel le nouveau site pointe dix fois — chargeaient encore le PNG hero de 1,1 MB alors que la session venait de créer un WebP de 154 KB de la même image. Les points principaux de l'auditeur sécurité étaient des notes de déploiement : épingler le numéro de téléphone du siège dans une variable d'environnement explicite plutôt que de s'appuyer sur la valeur par défaut codée, et surveiller le chemin fail-open documenté du rate limiter pour qu'une panne Redis soit visible plutôt que silencieuse.
Les trois corrections au niveau du code ont été appliquées en ligne par la session principale après le retour du workflow — un espace en nœud texte explicite dans le composant de statistique, un voile navy plus fort sur les trois heros signalés, le remplacement par le WebP sur les deux pages ERP — suivies d'un pnpm check frais (0 erreur sur 492 fichiers) et d'un pnpm build (vert) avant le commit. Les notes de déploiement sont allées dans la checklist de déploiement du journal de session, où il s'est avéré que l'inquiétude sur la migration se dissolvait à l'inspection : l'entrypoint du conteneur backend exécute déjà alembic upgrade head à chaque déploiement, donc la nouvelle table s'est créée d'elle-même quand le push est arrivé.
Une chose de plus que la phase de vérification a changée : le vérificateur du workflow lui-même a lu les captures mobiles avec la vision, pas seulement des mesures du DOM. « Regarde les captures d'écran » est la différence entre scrollWidth ≤ 392 et le sous-titre est techniquement lisible mais inconfortable sur le ciel lumineux — seul le second type de constat améliore le site d'une marque premium.
Partie 6 — Le suspense de la limite
Trente-trois minutes après le lancement, avec neuf agents terminés et l'intégration encore au travail, le fondateur a rapporté ce que disait la bannière de son compte : 92 % de la limite de session utilisée, réinitialisation à 2h10.
Le calcul à ce moment-là : le workflow avait dépensé environ 600k tokens, les phases restantes en demandaient peut-être 250k de plus, et 8 % d'un budget de session pouvait suffire ou non. La partie intéressante est que la conception du Workflow tool a rendu le pire scénario ennuyeux. Les agents éditent les fichiers directement dans le dépôt, donc tout ce que les neuf agents terminés avaient écrit était déjà sur le disque et ne pouvait pas être perdu. Le journal avait chaque appel agent() terminé en cache, donc une relance avec resumeFromRunId rejouerait la fondation et les sept pages instantanément et gratuitement, ne réexécutant que la queue inachevée. L'arbre de décision s'est effondré en : le laisser tourner, mettre la boucle principale en veille pour n'affamer rien, et si la limite coupe le workflow en plein vol, taper « resume » après 2h10 et ne perdre que quelques minutes.
La limite n'a jamais frappé. Le workflow s'est achevé avec les treize agents dans le budget, le « limit not reached, lets go, continue » du fondateur est arrivé, et la séquence de clôture s'est déroulée : triage des rapports, les trois corrections en ligne, vérifications, journal de session, mises à jour de la roadmap et du tracker de revue, commit 08acfcc, push, auto-déploiement, et la notification de session par SMS + WhatsApp sur le téléphone du fondateur. Mais l'épisode mérite d'être consigné parce que c'est la première fois qu'une interruption d'infrastructure en plein build était un risque chiffré plutôt qu'une menace : le journal de reprise convertit « la session pourrait mourir » d'un scénario tout-réécrire en un scénario relancer-un-appel-d'outil. Cette propriété comptera sur des workflows plus gros que celui-ci.
Partie 7 — Ce que chacun de nous a bien fait
C'est Claude Code qui écrit.
Là où la nouvelle machinerie a gagné sa place :
- La couture d'injection de contrat entre la fondation et les pages. Forcer l'agent de fondation à retourner son API de composants sous forme de document structuré, puis templater ce document dans sept prompts, c'est ce qui a fait que sept rédacteurs parallèles ont produit un seul site cohérent. L'alternative — chaque agent de page lisant le code source de la coquille et inférant l'usage prévu — produit sept interprétations légèrement différentes.
- Les retours forcés par schéma partout. Treize agents ont retourné des objets JSON validés, pas des rapports en prose. Le script a filtré, branché et composé sur des champs. Pas une seule regex n'a été écrite contre la sortie d'un agent.
- L'audit briefé, encore une fois. La détection du double
<title>par l'agent d'intégration et la vérification de l'IP de proxy par l'auditeur sont toutes deux venues de checklists écrites dans les prompts par une session qui se souvenait des échecs passés. Le pattern du billet CASP tient toujours : la checklist est la valeur ; l'agent est l'exécutant. - La reconnaissance avant l'orchestration. Vingt minutes de reconnaissance en ligne avant le lancement du workflow — extraire les vraies photos de flotte du PDF du client avec
pdfimageset les compresser en WebP, lire les patterns des pages publiques, les helpers API, le hub de notification — ont fait que les briefings d'agents contenaient des faits plutôt que des instructions d'aller chercher des faits. Treize agents qui ne redécouvrent pas chacun les conventions du dépôt, c'est une économie large et invisible.
Là où j'ai eu besoin de Thales :
- L'architecture, tranchée la veille. Mon premier réflexe avait été un projet statique séparé avec une bascule DNS. Le défi du fondateur — « pourquoi pas la même app, comme les pages qui existent déjà ? » — a survécu à la revue de code et produit un résultat strictement plus simple : pas de seconde cible de déploiement, pas de duplication de tokens, pas de travail DNS, le prérendu à l'intérieur de l'app existante. Le workflow a exécuté son architecture, pas la mienne. Un fan-out aussi rapide pointé sur la mauvaise architecture aurait livré la mauvaise chose sept pages à la fois.
- L'opt-in lui-même. Le Workflow tool est conditionné à une intention utilisateur explicite pour une raison : 857k tokens en 43 minutes est une décision de dépense, pas une décision technique. Le fondateur l'a prise avec le plan complet sous les yeux, sur un prompt de session gelé la veille. Une orchestration aussi agressive ne devrait pas être la décision du modèle.
- Le nom du modèle. Le fondateur a demandé un billet de blog sur « claude blade 5 ». C'est Fable 5. Il a aussi demandé le billet en anglais alors que chaque livrable de la session devait être en français irréprochable — code, commits, journal de session, et sept pages de copy marketing avec espaces insécables avant les deux-points. La discipline bilingue au sein d'une même session est exactement le genre de contrainte qu'un humain fixe et qu'un modèle suit.
Là où vivent les réserves honnêtes :
- C'était une charge de travail idéale pour le fan-out : sept unités véritablement indépendantes derrière une interface gelée, entièrement spécifiées d'avance. La plupart du travail d'ingénierie ne se décompose pas aussi proprement. L'outil ne rend pas le travail parallèle ; il exploite le parallélisme que la spécification a déjà créé.
- La facture en tokens a acheté de la vitesse, pas de la qualité. Les mêmes agents exécutés séquentiellement auraient produit le même site en deux heures et demie pour les mêmes tokens. Ce que le fondateur a payé, c'est les 43 minutes de temps réel et sa propre attention libérée — un échange manifestement juste à minuit avant une revue client, et manifestement mauvais pour du travail sans urgence sur un budget serré.
- Une vraie classe de bugs a glissé à travers chaque phase automatisée et n'a été attrapée par aucun des treize agents : aucune. Mais revendiquer un sans-faute après une seule session serait exactement le genre de déclaration que cette série existe pour éviter. La revue manuelle des sept pages par le CEO sur son téléphone — le tracker compte sept nouvelles lignes non cochées — reste la vérification qui compte.
Conclusion
La session a livré un site web de production de sept pages, un backend de capture de leads et toute la surface SEO de la présence publique d'une entreprise en un seul commit, construit par treize agents en 43 minutes sous un script déterministe, vérifié par un vrai navigateur et un auditeur briefé avant qu'un humain n'y pose les yeux. La contribution du Workflow tool n'est pas que les agents puissent travailler en parallèle — les fan-outs artisanaux le faisaient depuis des mois. C'est que l'orchestration est devenue un artefact : un script qui déclare les phases, encode les dépendances, valide les sorties, journalise la progression et survit à l'interruption. L'orchestration-comme-artefact est aux sessions multi-agents ce que le CASP était aux projets multi-sessions — la structure qui permet à la production unitaire de s'accumuler en un tout cohérent plutôt qu'en un tas de pièces.
La continuité profonde avec cette série est la même leçon sous un nouvel outil. La vélocité a été fabriquée la veille, dans une session de cadrage où un humain a contesté une architecture, où un plan a gelé les faits, et où sept spécifications de pages ont été écrites. Le workflow a passé 43 minutes à récolter ce que cette discipline avait planté. Des modèles plus rapides et une meilleure orchestration continuent d'élever le plafond de l'exécution ; ils ne font rien pour la spécification. Cette partie-là reste le métier.
Ce billet a été écrit en collaboration par Thales (CEO de ZeroSuite, qui construit depuis Abidjan, Côte d'Ivoire) et Claude Fable 5 — instance Claude Code, le premier modèle de la famille Claude 5 en usage de production dans cette équipe. La session qu'il décrit est consignée dans session-logs/26-06-12-001-vitrine-build-workflow-fable5.md dans le dépôt SENEBA (privé) ; le prompt de session qu'elle a exécuté est docs/plan/sessions/PHASE-VITRINE-WEBSITE.md, gelé la veille et documenté dans le journal de la session précédente. Le workflow a tourné sous le run wf_0f062e64-b70 : 13 agents, 857 383 tokens de sous-agents, 388 appels d'outils, 42m58s, zéro agent en échec. Le commit livré est 08acfcc — 44 fichiers, 6 109 insertions — auto-déployé sur seneba.ci. Les captures d'écran sont celles du fondateur : la boîte de dialogue de permission, la vue de progression /workflows en direct pendant les phases Fondation et Pages, et la conversation sur la limite de session à 92 % du quota. La décision d'architecture que le workflow a exécutée — les pages marketing comme routes prérendues à l'intérieur de l'app existante plutôt qu'un projet séparé — était celle du fondateur, prise contre la recommandation initiale de l'agent et confirmée par revue de code, une histoire racontée dans le journal de session SENEBA du 11 juin.