Par Thales (Juste Gnimavo) — CEO et fondateur, ZeroSuite, Inc.
Note client : lorsqu'un projet client est évoqué, il apparaît sous le pseudonyme KASSIA. Le vrai nom de l'entreprise et son domaine sont tenus confidentiels à la demande du client, le temps que son site public soit finalisé.
La question qu'on me pose plus que toute autre est une variante de : « Comment je tire le meilleur de Claude ? »
Les gens qui la posent cherchent presque toujours un meilleur prompt. Une formulation magique. Un system prompt qui débloquerait un palier caché du modèle. Et je comprends l'instinct, mais c'est le mauvais cadre, et le poursuivre est précisément la raison pour laquelle la plupart des gens plafonnent au stade de l'« autocomplétion impressionnante ».
Voici la vraie réponse, et il m'a fallu seize mois et sept produits en production pour y arriver : le meilleur de Claude, ce n'est pas un génie dans un seul chat. Ce sont trois surfaces Claude spécialisées, pilotées comme une équipe, sur un seul fil d'état partagé qui survit au fait qu'aucune d'elles ne se souvient de quoi que ce soit.
Cette phrase a deux moitiés, et les deux comptent. La première moitié — le trio — consiste à utiliser la bonne surface pour la bonne tâche. La seconde — le fil partagé et validé — porte sur le problème dont personne ne vous prévient : les trois surfaces ne partagent aucune mémoire, et sans correctif délibéré, chaque passation entre elles fuit. Le correctif est un petit protocole open source que j'ai construit, appelé CASP. Cet article explique comment les deux moitiés s'emboîtent en un seul système d'exploitation.
Le système d'exploitation en une image : trois surfaces Claude, chacune un contexte scellé sans mémoire des autres, reliées par un seul fil d'état validé. La stratégie s'écoule vers le design puis vers l'implémentation ; chaque passation lit et écrit les mêmes fichiers CASP — et casp check bloque le push dès que cet état cesse de correspondre à git.
Le trio : trois surfaces, trois métiers
Claude n'est pas un produit unique auquel vous parlez. C'est au moins trois contextes opérationnels distincts, et ceux qui en tirent le plus sont ceux qui ont cessé de les traiter comme interchangeables.
Claude Web (claude.ai, le chat) est le stratège et cofondateur. C'est là que je tiens des conversations stratégiques longues, sur plusieurs jours : positionnement produit, raisonnement marché, les documents SPEC, le copywriting, l'arbitrage d'architecture. Claude Web tient un argumentaire long sur de nombreux tours, revient sur des choses que j'ai dites une heure plus tôt et — quand je l'ai correctement configuré — me contredit quand mon cadrage dérive. Je l'ai déjà vu me citer mon propre message antérieur et refuser de valider un pivot tant que je n'avais pas produit un signal de marché. Ça, c'est un conseiller stratégique, pas une barre de recherche.
Claude Design (claude.ai/design) est le lead designer. Il détient tout le système visuel et UX de bout en bout — les tokens, une bibliothèque de composants typés, des UI kits cliquables, le langage de design des fonctionnalités IA à l'intérieur du produit. Pas des maquettes : un système de design versionné, de qualité production, produit à partir d'un brief. J'ai écrit un article entier rien que sur cette surface, parce que c'est la plus sous-estimée des trois : Claude Design est le membre le plus sous-estimé de mon équipe IA.
Claude Code (la CLI) est l'ingénieur senior avec une équipe de sous-agents. Tickets structurés, branches Git parallèles, graphes de dépendances, boucles d'audit multi-agents, commits sûrs face aux régressions. C'est là que les décisions deviennent du code livré. Tout le système d'ingénierie autour de cette surface — la constitution CLAUDE.md, l'architecture de session, la boucle de double audit, l'autorité de dire non — fait l'objet de son propre long article : Le workflow complet et sans filtre que j'utilise pour que Claude produise du logiciel de niveau production.
Chaque surface a ses propres forces, son propre format d'entrée et sa propre exigence de qualité. Bien piloter Claude Web n'est pas la même compétence que bien piloter Claude Code. Piloter le trio, c'est la compétence d'un CEO qui dirige trois spécialistes — un stratège, un designer, un ingénieur — pas celle d'un amateur qui demande à un bot d'écrire du code. Cette partie-là, la plupart des bâtisseurs sérieux finissent par la comprendre.
Voici celle qu'ils ne comprennent pas.
Le problème dont personne ne vous prévient : le trio est amnésique
Les trois surfaces ne partagent aucune mémoire. Aucune.
La conversation stratégique que j'ai eue avec Claude Web lundi — celle qui a fixé tout le positionnement d'une fonctionnalité — n'existe pas pour Claude Code mardi. Le système de design produit par Claude Design vit dans son espace de travail ; la session d'ingénierie qui doit le porter démarre aveugle à la façon dont il a été raisonné. Et Claude Code lui-même n'a aucune persistance entre les sessions : chaque session démarre avec zéro contexte, par conception, parce qu'il n'y a aucune mémoire entre elles.
Ce que vous avez donc réellement, quand vous pilotez le trio, ce sont trois spécialistes brillants enfermés dans trois pièces séparées, chacun frappé d'une amnésie totale sur ce qui se passe dans les autres pièces — et sur ce qu'il a lui-même fait hier. Le stratège oublie. Le designer oublie. L'ingénieur oublie. Chaque passation entre eux est une porte par laquelle le contexte tombe par terre.
C'est le vrai goulot d'étranglement quand on veut tirer le meilleur de Claude à l'échelle. Ce n'est pas la qualité des modèles — les modèles sont extraordinaires. C'est que plus chaque surface devient capable, plus l'amnésie devient dévastatrice. Les nouveaux modèles tournent pendant des heures, voire des jours, exécutant phase après phase. Une surface qui fait davantage entre vos points de contrôle est une surface dont l'état enregistré peut discrètement cesser de correspondre à la réalité sur un écart de plus en plus long. La capacité aggrave le problème de mémoire, elle ne le résout pas.
Les gens colmatent ça avec des tableaux, des cartes, des pages Notion, un fichier STATE.md qu'ils mettent à jour à la main. Rien de tout ça ne fonctionne, pour deux raisons. D'abord, c'est manuel, donc ça pourrit — vous arrêtez de le mettre à jour le jour où vous êtes débordé, c'est-à-dire tous les jours. Ensuite, et c'est pire : l'agent ne peut pas le lire de façon fiable, et il ne peut pas prouver qu'il est vrai. Un fichier d'état qui dit « suivant : construire la fonctionnalité caméra » alors que la caméra a été livrée la semaine dernière ne se contente pas d'être inutile — il rend votre agent confiant et faux. Il démarre un travail qui existe déjà. Vous perdez un après-midi à le défaire. Un fichier d'état périmé est le mode d'échec le plus coûteux du développement assisté par IA, parce que vous ne le détectez qu'une fois le travail en double terminé.
CASP : la mémoire que le trio n'a pas — et qui ne peut pas mentir
J'ai donc construit la couche manquante et l'ai mise en open source : CASP — le Coding-Agent State Protocol (npx @justethales/casp · casp.sh · MIT, zéro télémétrie, pas de SaaS, rien ne quitte votre machine).
CASP est le fil partagé et validé que les trois surfaces Claude n'ont pas par elles-mêmes. Il est délibérément minuscule — trois fichiers ordinaires qu'un agent peut lire dès la première ligne de n'importe quelle session, échafaudés dans un répertoire casp/ par casp init :
state.json— la source de vérité lisible par la machine : phase actuelle, le next-prompt exact à exécuter, phases livrées, migrations appliquées, dernier commit, dernier identifiant de session. C'est ce que chacune des trois surfaces lit pour savoir où en est réellement le projet.now.md— le « où j'en suis là tout de suite » sur un seul écran, pour les humains. Vous l'ouvrez, vous récupérez le fil en cinq secondes.roadmap.md— les trois prochaines choses à livrer, dans l'ordre, plus un tableau de bord des phases.
Tout cela, à lui seul, ne serait qu'un STATE.md mieux rangé. Ce qui rend CASP important, c'est un verbe : casp check. Tout le monde stocke du contexte — tableaux, outils de mémoire, notes. CASP le valide. Le check lit votre état stocké et le vérifie contre la vérité-terrain de git : un next_prompt qui pointe vers une phase déjà livrée, un last_commit absent de l'historique, une liste de migrations qui contredit le répertoire des migrations — tout est attrapé, de façon déterministe, avec un pass/fail tranché. Un état propre sort avec le code zéro. Une dérive sort avec un code non nul et bloque le push. Placez-le dans la CI et un fichier d'état menteur ne peut jamais atteindre votre dépôt distant.
yaml# .github/workflows/ci.yml — la dérive ne peut pas être mergée
jobs:
state-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with: { fetch-depth: 0 }
- run: npx @justethales/casp check
casp check sur un état dérivé (en haut) face à un état propre (en bas). Il valide l'état stocké contre la vérité-terrain de git et renvoie un pass/fail tranché — pour que le fil partagé dont dépendent les trois surfaces ne puisse jamais se mettre à mentir en silence.
C'est la propriété qui le fait fonctionner comme mémoire partagée du trio : le fil n'est pas seulement partagé, il est prouvablement vrai. Les outils de mémoire stockent et rappellent par similarité floue ; CASP exécute un check synchrone et déterministe contre git et vous arrête quand l'état ment. Une mémoire partagée qui peut elle-même dériver ne vaut rien — vous revenez au « confiant et faux », d'un cran au-dessus. Une mémoire partagée verrouillée contre la vérité-terrain est la chose sur laquelle vous pouvez réellement bâtir un workflow multi-surfaces. (CASP n'est pas une couche de mémoire IA au sens de Mem0 / Letta — celles-ci se souviennent de qui vous êtes ; CASP suit où en est le projet et le prouve. Artefact différent, échec différent évité. J'ai écrit l'article dédié ici : CASP : la petite CLI qui a corrigé mon workflow IA.)
Comment le trio tourne sur un seul fil CASP — une journée concrète
Voici à quoi ressemble une vraie journée quand les trois surfaces et la couche d'état fonctionnent comme un seul système. Ce n'est pas le schéma d'un idéal ; c'est la boucle que je fais réellement tourner.
La stratégie, dans Claude Web. J'ouvre une conversation longue pour décider de ce qui se livre ensuite et pourquoi. On débat du positionnement, on pèse les arbitrages, on fige la décision. La sortie n'est pas du code — c'est un spec figé et un prochain pas clair. Cette décision atterrit dans le projet comme la prochaine phase de roadmap.md et un prompt de session rédigé à partir du modèle canonique (casp new prompt — les modèles sont des verrous, pas des suggestions, donc chaque prompt a la même forme).
Le design, dans Claude Design. Si la phase comporte une surface, Claude Design produit ou étend le système pour elle — les tokens, le composant, l'écran d'UI kit — et rend un artefact de qualité production : des contrats typés et une référence fidèle au pixel près. Cet artefact est le contrat que la surface d'ingénierie consommera. La décision de design est désormais écrite noir sur blanc, pas piégée dans un espace de travail que personne d'autre ne peut lire.
L'ingénierie, dans Claude Code. La session s'ouvre sur une seule commande : casp next. Claude Code lit state.json dès la première ligne, connaît la phase exacte et le next-prompt exact — pas de redécouverte, pas de « rappelle-moi où on en était » — et exécute. Il porte l'artefact de design contre son contrat, déroule le travail en phases structurées et déclenche la boucle d'audit indépendante. À la fin, la session écrit son propre journal de session, rédige le prompt de la session suivante et met à jour l'état — puis casp check valide l'ensemble contre git avant que quoi que ce soit ne soit poussé. Il est impossible de livrer une dérive.
Remarquez ce qui vient de se passer. La décision du stratège a atteint l'ingénieur sans qu'aucun des deux ne partage une fenêtre de contexte. L'artefact du designer a atteint celui qui le porte sous forme de contrat explicite, pas d'un vague « fais en sorte que ça ressemble à la maquette ». Et la session de demain — une autre instance Claude Code vierge — ouvrira state.json et saura précisément où en est le projet, parce que le projet se souvient désormais de lui-même, sous une forme lisible par la machine et prouvée vraie. L'amnésie est toujours là. CASP a simplement fait en sorte qu'elle cesse d'avoir de l'importance.
C'est toute l'astuce. Vous ne réparez pas la mémoire d'une surface isolée. Vous donnez aux trois surfaces un seul fil externe qui ne ment pas, et les passations cessent de fuir.
Comment démarrer — cette semaine
Vous n'avez pas besoin de sept produits pour faire tourner ça. Vous avez besoin des deux moitiés.
Moitié un — pilotez le trio, arrêtez de chasser le prompt magique. Pour votre prochain vrai chantier, répartissez-le délibérément sur les trois surfaces. Faites la stratégie et le spec dans une longue conversation Claude Web, et donnez-lui la permission de vous contredire. Faites le système de design — les tokens d'abord, puis les composants avec leurs contrats — dans Claude Design avant tout code de production (l'article Design est le manuel). Faites l'implémentation dans Claude Code avec des phases structurées et au moins une session d'audit indépendante. Trois surfaces, trois métiers, un seul directeur : vous.
Moitié deux — donnez-leur un seul fil validé. npx @justethales/casp init dans votre dépôt le plus actif. Remplissez state.json honnêtement, une fois. Terminez votre prochaine session en laissant l'agent rédiger le prompt de la session suivante et mettre à jour l'état. Lancez casp check avant de pousser — et mettez-le dans la CI la semaine même. À partir de là, chaque surface ouvre chaque session en sachant exactement où en est le projet, et un fichier d'état menteur ne peut jamais atteindre votre dépôt distant.
Le basculement de posture, c'est tout l'enjeu : arrêtez d'essayer d'extraire davantage d'un seul Claude. Commencez à en piloter trois, et donnez-leur une mémoire qui ne peut pas dériver. Le levier n'est pas dans le prompt. Il est dans l'orchestration.
La vue d'ensemble
Je construis depuis Abidjan, avec un abonnement Claude Max, comme seul ingénieur sur sept produits en production. Rien de tout ça n'est possible en jouant au plus malin avec une seule fenêtre de chat. C'est possible parce que j'ai cessé de demander « comment je tire le meilleur de Claude » et que j'ai commencé à demander « comment je pilote une équipe virtuelle de spécialistes Claude pour que le projet ne s'oublie jamais lui-même ».
Le modèle tient le contexte. Le trio fait le travail — stratégie, design, ingénierie, chacun sur la surface conçue pour lui. Et CASP prouve que l'état est vrai, pour que trois surfaces sans mémoire partagée puissent quand même se comporter comme une seule équipe qui ne perd jamais le fil.
C'est comme ça qu'on tire le meilleur de Claude. Pas un meilleur prompt. Un meilleur système d'exploitation.
À lire ensuite :
- Claude Design est le membre le plus sous-estimé de mon équipe IA — l'analyse approfondie de la surface de design et du processus en six étapes.
- Le workflow complet et sans filtre que j'utilise pour que Claude produise du logiciel de niveau production — le système d'ingénierie complet à sept piliers autour de Claude Code.
- CASP : la petite CLI qui a corrigé mon workflow IA — l'histoire dédiée de la couche d'état. Source sur GitHub, npx @justethales/casp init.
Un fondateur. Trois surfaces Claude. Un fil validé. Sept produits.