Le workflow designer-développeur avec Claude Code qui ship vraiment

La plupart des teams bolt Claude Code sur un process existant et s'étonnent que ça sous-performe. Le workflow designer-développeur avec Claude Code casse, pas parce que Claude ne sait pas coder. C'est parce que le handoff est un bordel. Des specs vagues, du contexte design manquant, des sessions qui partent en vrille dans du stale state. L'IA n'est pas le bottleneck. Le protocole autour, si.

Voilà mon process exact.

Le problème de contexte dont personne ne parle

Claude commence à dégrader la qualité de ta session à 20-40 % de son context window. Pas à la fin, au premier tiers. Le mécanisme d'attention sous-pèse les instructions plus anciennes à mesure que du nouveau contenu s'accumule. Au moment où tu as trois cycles d'implémentation de profondeur, Claude opère sur une version floutée de ta spec d'origine.

L'auto-compaction kick autour de 83,5 % du context window et retient à peu près 20-30 % des détails de session. Ce qui veut dire que si tu as pompé tes specs Figma, tes edge cases et tes décisions design dans une seule longue session, la majeure partie de ce contexte est partie avant que tu t'en rendes compte.

Ça compte parce que la plupart des gens traitent une session de coding comme un long fil unique. Ils démarrent avec la brief design, itèrent, corrigent, étendent. Au bout de deux heures, ils ne debug pas un problème Claude. Ils debug un problème de contexte. L'IA fait de son mieux avec la moitié des infos avec lesquelles elle a démarré.

Le fix, ce n'est pas un CLAUDE.md plus gros. J'ai essayé. Tous ceux qui recommandent un CLAUDE.md de 500 lignes n'ont soit jamais touché la limite, soit n'ont pas remarqué quand ça a arrêté de marcher. Les docs de résumé ont le même souci : chiants à maintenir et ils ne survivent pas vraiment à la compaction de contexte comme tu t'y attends. J'ai cramé un après-midi complet à l'apprendre sur un projet récent avant d'arrêter de me battre avec l'outil et de changer le process.

Le fix, c'est traiter le contexte comme périssable. Chaque tâche a droit à une conversation fraîche.

Structurer le workflow designer-développeur avec Claude Code

Mon pipeline a trois gates distinctes avant que la moindre ligne de code ne soit écrite.

Le protocole Figma-vers-code qui marche vraiment

Quand un nouvel écran atterrit dans ma boîte, je n'ouvre pas mon éditeur. Je lance une skill.

J'ai écrit cette skill Claude Code une fois. Elle me guide à travers chaque phase de la transformation d'un design Figma en code de production, et la première chose qu'elle fait, ce n'est pas écrire du code. C'est construire du contexte.

Phase 1 : Discovery

La skill traverse les designs Figma et produit une design registry, un fichier Markdown avec une ligne par composant à implémenter. Nom du frame, URL Figma, description, état (nouveau / refine un existant / remplace), statut. Claude construit ça. Pas moi.

Puis la décomposition : chaque design est cassé en atoms, molecules et templates. La skill mappe la structure, identifie quelles pièces existent déjà dans la codebase, et note ce qu'elles remplacent. À la fin de cette phase, Claude sait ce qu'il faut build, ce qui existe déjà, et comment les deux se relient, sans toucher un seul fichier de l'app.

Ça compte plus que ça en a l'air. Si tu files un lien Figma à Claude en disant « implémente cet écran », il va essayer de tenir tout le design en contexte tout en lisant ta codebase, en mappant la data et en écrivant du code. Il va dériver. Il va poser des hypothèses. Il va casser. La phase de discovery existe pour empêcher ça : tous les appels Figma chers se font une fois, upfront, et l'output est un set de fichiers structurés que Claude peut référencer proprement pour le reste du travail.

Phase 2 : Storybook d'abord

Chaque composant est implémenté dans Storybook avant de toucher l'app. C'est délibéré. Le but à ce stade est purement visuel : match pixel-perfect avec le design Figma, pas de logique métier, pas de connexions de data.

Claude implémente le composant, puis ouvre Playwright et compare le rendu Storybook contre le frame Figma. Si ça match, on avance. Si ça ne match pas, on fix avant d'aller plus loin. Catcher un souci visuel ici ne coûte presque rien. Le catcher après que tu as câblé le state management et les appels API coûte cher.

Phase 3 : Intégration

Une fois que le composant passe dans Storybook, il entre dans l'app. Le scope est volontairement étroit : comment ce composant parle au reste de l'application ? Quelles props reçoit-il ? Quels callbacks expose-t-il ? Quelles actions ses boutons déclenchent-ils ?

Rien d'autre. Pas de nouvelle logique. Pas de nouveau data fetching. Le composant est fait : cette phase n'est que la couche de connexion.

Séparer « build le composant » et « intégre le composant » en deux tâches distinctes, c'est ce qui rend ça scalable. Fais les deux en même temps et tu debug des incohérences visuelles et des bugs de state simultanément. Garde-les séparés et chaque étape a un seul failure mode.

Tout tourne dans une loop

Le tout tourne dans une Ralph Loop : Claude traverse la registry en autonomie, composant par composant. Quand il a fini, il me file un recap : ce qui a été implémenté, ce qui a été validé, ce qui a encore besoin de review humaine. Puis je teste.

Ce n'est pas plus rapide parce que Claude est plus smart. C'est plus rapide parce que le protocole retire les conditions sous lesquelles Claude casse.

Gate 2 : le plan mode comme checkpoint, pas comme feu vert.

Je fais tourner Claude en plan mode pour tout ce qui n'est pas trivial. Mais le plan mode te file un point de départ, pas des instructions complètes. Les edge cases émergent pendant l'implémentation. Les specs ambiguës deviennent visibles quand Claude essaie de les interpréter. Je traite l'output du plan mode comme un draft structuré que je vais corriger en review, pas comme un ticket pour m'en aller.

La règle que je suis : si Claude fail la même chose deux fois, je ne corrige pas une troisième. Je fais /clear, je réécris le prompt initial avec ce que j'ai appris, et je repars de zéro. C'est la recommandation officielle d'Anthropic et elle est correcte. Corriger dans un contexte pollué est presque toujours plus lent que de repartir avec une brief plus propre. L'instinct de sunk-cost va te dire de pousser. Ignore-le.

Si tu essaies de monter ce genre de workflow sur ta propre codebase, c'est exactement ce avec quoi j'aide les teams, contacte-moi.

Ce qui reste humain

Les gens me demandent en boucle quelles parties de tout ça peuvent être « fully déléguées ». La réponse : moins que ce que les pitchs suggèrent.

Ce que je délègue à Claude Code : l'implémentation de composants clairement speccés, les patterns UI répétitifs, le câblage de state quand le data model est stable, la génération de tests pour du comportement défini, le refactoring quand l'état cible est explicite.

Ce que je garde : chaque décision UX où la spec est ambiguë. Les choix d'architecture quand plusieurs approches valides existent. Le jugement sur la cohérence de l'output de Claude avec le reste du produit, pas juste le composant isolé, mais tout le système visuel à l'échelle de la page. La décision de push vs. iterate.

Le principe auquel je reviens toujours : les humains designent les templates de diagnostic, l'IA gère l'exécution. Ce n'est pas une question de ce que Claude peut faire. C'est ce qui demande le raisonnement qui vient du fait de shipper ce produit précis depuis des mois. Ce raisonnement ne vit pas dans un prompt. Il vit dans celui qui possède le produit.

Il y a aussi une catégorie de jugement qui est invisible jusqu'à ce qu'elle remonte en QA. Un composant qui passe la review isolé mais casse la hiérarchie visuelle à l'échelle de la page. Un pattern qui marche dans le happy path mais crée un mental model confus pour l'utilisateur. Claude ne catchera pas ça sauf si tu lui donnes assez de contexte pour l'évaluer, et je ne veux presque jamais payer ce coût de contexte. C'est plus rapide de review l'output moi-même et de trancher.

Les teams que je vois galérer le plus sont ceux qui essaient de se retirer entièrement de la loop. Ça, ce n'est pas de l'agentic coding. C'est de la délégation wishful. Le but, c'est la précision, pas l'absence.

La discipline, pas l'outil

L'erreur que je vois le plus souvent : traiter Claude Code comme une version plus rapide du process existant. Ça ne l'est pas. C'est un process différent avec des failure modes différents.

Le process existant faille sur la vitesse d'implémentation. Claude Code faille sur l'intégrité du contexte et le scope creep. Si tu ne manages pas activement ce qui entre dans chaque session, tu te retrouves avec une IA confiante qui produit de l'output subtilement faux. Les erreurs se composent plus vite qu'avec du codage manuel parce que la vitesse d'itération est plus haute. La vélocité sans discipline crée de la dette à une autre échelle.

Ce qui marche, c'est traiter chaque session d'implémentation comme un petit contrat borné : voilà la spec, voilà le fichier cible, voilà le comportement. Ship ça. Done. Contrat suivant.

Cette discipline, contexte scoppé, fresh starts, checkpoints humains aux bons moments, c'est ce qui rend le workflow designer-développeur avec Claude Code réellement replicable à travers une team. Pas la config de l'outil. Le protocole autour.

---

Si ta team perd des heures dans les handoffs design-vers-code, ce workflow est transférable. Je consulte exactement là-dessus. Parlons-en.