Cette semaine, j'ai modifié mon Claude.md trois fois.

À mesure que j'échange avec Claudio, je me rends compte qu'il y a des choses que je dois lui répéter. Des patterns que j'avais oublié de lui faire intégrer.

Parfois, des consignes contradictoires qui trainent.

Donc j'affine.

En permanence.

Et il y a memory.md, le second fichier qui sert à acter les règles qu'on fixe au fil des sessions. « Souviens-toi qu'à chaque fois que tu crées une PR, ta branche doit être rebased sur origin/main. » Tu donnes une fois, l'agent retient, tu n'y reviens plus.

Tu vas voir à quoi ressemble ma stack au moment où j'écris ces lignes. Un truc vivant qui bouge toutes les semaines, pour ne pas dire tous les jours.

Je vais te la présenter quand même. Pas pour que tu la copies. Mais parce que ce qui compte n'est pas la stack, c'est le flow.

La stack, c'est l'inventaire à un instant T. Le flow, c'est ta façon de faire bouger cet inventaire à mesure que tes outils évoluent et que ta confiance en eux grandit.

La stack se périme. Le flow, lui, se construit.

Sers-toi de cet article comme d'une boîte à idées. Pour t'inspirer, tester, comparer avec ce que tu fais déjà. Le but du jeu, c'est que tu construises ton propre flow. Et que tu l'affines.

Tout le temps.

Mon setup agentique est un ensemble d'outils et de configurations qui me permettent d'accélérer ma production tout en augmentant ma confiance dans ce que je livre.

Mon agent, c'est Claude Code.

Je suis utilisateur de la première heure.

Après avoir testé les principaux agents du marché, c'est celui avec lequel j'ai développé le meilleur flow et la plus grande confiance. Je l'utilise dans mon IDE Cursor (version gratuite, ça pourrait tout à fait être VS Code). Parfois dans l'extension officielle VS Code, parfois directement dans le terminal. Au gré de mes humeurs.

Un point très important : je l'utilise dans un monorepo de submodules qui réunit tous les repos Catalog. Ça donne un pouvoir gigantesque à Claudio. Si on le guide bien, il est capable de récupérer tout le contexte dont il a besoin pour comprendre une feature et les interactions entre nos services.

C'est crucial : nos features touchent fréquemment plusieurs repos. Cette architecture nous permet aussi de tirer parti des sub-agents (on y revient dans un instant avec Superpowers), pour faire bosser plusieurs instances en parallèle sur différentes parties d'une même feature, en gardant la cohérence de l'ensemble.

Sur ce socle, je donne à Claudio des outils et des compétences.

Les outils, ce sont les MCP. J'utilise principalement ceux qui servent à glaner du contexte. MCP Linear pour les tickets, les projets, situer mon ticket par rapport aux autres dans son cycle. MCP Notion, où vit notre documentation technique, business et produit. Très utile pour enrichir la compréhension d'une feature. J'en utilise d'autres : Playwright quand je fais du front, Mongo pour vérifier des données en base.

Et puis Datadog. Celui-là, attention, il crame du token.

Mais il est d'une puissance redoutable pour le debug.

Datadog est complet et puissant, mais aller y chercher rapidement les logs et les traces qui nous intéressent est souvent fastidieux. Claudio, lui, fait des requêtes ciblées et précises. Quelques instants pour mettre le doigt sur ce qui, dans le monde d'avant, demandait plusieurs minutes voire plusieurs heures d'investigation.

En plus des outils, j'ai doté Claudio de compétences spécifiques : les skills.

Deux types : ceux qui existent déjà et que j'installe via plugin, et ceux que je crée pour répondre à un besoin précis.

Côté skills tout prêts, je suis fan absolu de Superpowers.

Superpowers, c'est plutôt une biblothèque de skills qui, utilisés ensemble, proposent une méthodologie complète. Quelque chose que j'avais intuitivement essayé de bricoler avec mes skills maison avant de les découvrir.

Superpowers force Claudio à suivre un cadre pro. Pas de production de code tête baissée. On discute, l'agent me questionne jusqu'à ce qu'il sorte des specs précises qu'on valide ensemble. Une fois validées, il transforme ces specs en plan d'implémentation détaillé, qu'il dispatche, après nouvelle validation, à une armée de sub-agents. TDD imposé, principes YAGNI et DRY respectés (j'y ajoute en général le KISS). J'ai toujours obtenu une grande satisfaction du code qui sort de cette méthode. Quand la phase de brainstorming est menée avec rigueur, on obtient du code qualitatif et l'objet de la feature est parfaitement respecté.

Et c'est là qu'on entre dans ma phase préférée.

Le brief, le brainstorming. C'est à ce moment que mes compétences tech sont les plus sollicitées. Mais aussi mes compétences produit. Parce qu'il faut expliquer à Claudio ce qu'on doit coder, pourquoi, et pour qui. Le ticket Linear et la doc Notion font une partie du job. Mais parfois, le ticket se résume à un titre et il n'y a pas de doc. À toi de préciser l'enjeu.

Cette semaine, j'ai bossé sur un sujet qui illustre parfaitement le propos.

On a récemment refondu chez Catalog les pages les plus importantes pour nos utilisateurs. La section où ils valident, vérifient et complètent les commandes ou devis arrivés dans leur boîte mail, avant de les envoyer dans leur ERP. Dans la vue legacy, on avait un debug mode avec des tooltips qui s'affichaient au survol de certaines sections. Pratique pour voir rapidement ce que renvoyait notre backend.

J'aurais pu me contenter de recréer ce système de tooltips dans la nouvelle vue. Un petit prompt : « analyse le debug mode de la vue legacy ; il affiche le retour du backend dans des tooltips ; reproduis ce comportement dans la nouvelle vue. » Simple, moche, mais ça aurait fait le job.

Sauf que la phase de brief a permis de poser un tout autre pattern.

D'abord, on a exploré les standards du marché en matière de debug mode. Claudio m'a proposé plusieurs solutions, documentées (à chaque fois que je lui demande de l'information sur l'état de l'art, j'exige les sources : c'est non négociable). De mon côté, j'avais déjà mon idée de ce qui serait vraiment plus utile, à nous développeurs comme aux Ops qui doivent parfois répondre vite aux clients. D'une option facile (copier-coller des tooltips), on est passés à un side panel en right push, géré avec un store global Zustand et un wrapper assez flexible pour être réutilisé partout dans l'application.

En quoi mes qualités produit ont été importantes ? Cette feature est typiquement une feature de developer experience. Elle répond à une problématique que je vis tous les jours : faciliter le debug. Bien prompter ce besoin était simple parce que j'en suis l'utilisateur final.

Et mes qualités de dev ? J'ai dû guider l'agent sur les choix d'implémentation. Store global Zustand plutôt que contexts React et prop drilling. Définition des layouts et des comportements de la vue à l'ouverture et à la fermeture du panel. Veiller à ce que Claude réutilise ce qui devait l'être, et écrive du code pouvant être réutilisé à son tour.

Et là, attention au contre-sens facile. Sur le papier, on est passés d'un tooltip simple à un side panel architecturé : ça pourrait ressembler à de l'over-engineering.

Ce n'en est pas.

L'over-engineering, c'est de la complexité technique qui n'apporte rien à la feature : trois contextes imbriqués pour gérer trois tooltips, des wrappers d'abstractions qui s'enchaînent. Ici, la complexité est fonctionnelle. La feature elle-même est meilleure. Et l'implémentation reste simple : un store, un wrapper, un panel.

Surtout, le calcul économique a changé. Sans Claudio, on ne se serait jamais permis trois jours pour un debug mode léché. On aurait copié les tooltips legacy et serait passé à autre chose. Là, on a livré la version chiadée en moins d'une demi-journée.

Le seuil d'acceptabilité de la sophistication a baissé.

Ce n'est pas qu'on est devenus plus rigoureux, c'est qu'on peut désormais aller chercher la qualité parce qu'elle ne coûte plus le même prix.

Ce long brainstorming a débouché sur un plan d'implémentation que j'ai validé. Alors seulement Claudio s'est mis à coder. Avec le MCP Playwright, il a pu lancer un navigateur, faire des screenshots du rendu, itérer sur les ajustements CSS, le redimensionnement de la page, l'animation du panel.

Résultat : 20 commits TDD granulaires, 30 nouveaux tests, un wrapper réutilisable. Et surtout, on est passés d'un truc un peu foireux à un véritable inspector panel très classe, très pratique, évolutif.

En moins d'une demi-journée.

Inconcevable avant Claudio.

Et c'est précisément parce que je passe autant de temps sur le brief que je peux me permettre de tendre vers le …

J'aurais écrit cet article il y a trois semaines, je t'aurais expliqué comment j'interrompais Claudio toutes les 5 minutes.

Parce qu'il serait parti en vrille.

Parce qu'il aurait pris des libertés avec le plan.

Parce qu'il aurait créé trois contextes et cinq couches d'abstraction pour un formulaire à trois champs.

Sauf qu'aujourd'hui, je le laisse sereinement aller jusqu'à la PR.

Quand je suis vraiment satisfait de la phase de brief, j'ai désormais assez confiance en mon outil pour que les corrections se jouent à la review. Et la review, ce sera l'objet d'un prochain numéro.

Peut-être même le prochain.

Car au train où vont les choses, j'imagine que la review elle-même finira par disparaître, à mesure que la confiance dans l'agent grandira.

Oui, les choses changent.

Vite.

Pendant que Claude code, c'est le moment de piloter d'autres agents. Lancer un brainstorming sur un autre sujet. Traiter un bug en parallèle. Souvent, je génère pas mal de doc.

J'adore la doc.

Surtout depuis qu'on a des agents pour la générer !

Du coup je me suis créé des skills perso pour ça. /knowledge et /deep-knowledge produisent, selon le degré de détail que je vise, une documentation plus ou moins exhaustive d'une feature ou d'un repo.

Un de mes préférés, c'est /teachme. Je l'utilise après mes sessions de brainstorming, quand Claudio m'a suggéré un pattern ou une lib que je ne connais pas. /teachme me produit alors un cours structuré, avec des exemples extérieurs et des exemples puisés chez Catalog pour m'aider à intégrer le concept dans mon propre contexte.

Exemple récent : on réfléchit en ce moment à comment optimiser nos patterns d'access control. N'étant pas sachant dans le domaine, j'ai demandé un /teachme sur les modèles ReBAC vs RBAC vs ABAC.

Bilan : des bases solides, sourcées (toujours sourcées) pour pouvoir creuser et vérifier qu'il n'a rien inventé.

J'ai d'autres skills perso, mais en parler en deux lignes en fin d'article ne leur rendrait pas hommage. Chacun mérite un numéro entier.

Aujourd'hui sur LinkedIn, la grande mode c'est de promettre une stack, un skill, une méthode de travail en échange d'un commentaire. « Poste 'Claude' en commentaire et je t'envoie ma stack. »

Sauf que ta stack est déjà périmée, mec.

Ce qu'on doit apprendre, ce n'est pas une stack. C'est à faire confiance à l'agent. À se construire un flow qui déplace le curseur de confiance, à chaque fois un peu plus, vers le lâcher prise. Ça paraît contre-intuitif. Mais laisser faire n'est pas de la négligence. C'est le résultat d'un brief solide.

Tu as un aperçu de la façon dont je travaillais avec Claude.

J'emploie bien l'imparfait.

Au mieux, tu lis cet article quelques heures après que je l'ai écrit. Mais tu peux aussi le lire dans plusieurs jours, plusieurs mois, voire plusieurs années (longue vie au Rebase !). Et à ce moment-là, je ne travaillerai déjà plus du tout de la même façon.

C'est pour ça que je te le redis : ne copie pas la stack, construis ton flow. Le flow, c'est cette gymnastique qui te permet de faire évoluer ta confiance en l'agent à mesure que tu l'apprivoises. C'est ce qui te conduit, étape par étape, à ce moment où tu peux le laisser dérouler jusqu'à la PR sans t'inquiéter.

L'important n'est pas la stack, c'est le flow.

Ma conviction : la part technique pure (code, algo) va continuer à s'amenuiser, pour laisser place au brief. Or briefer correctement exige une vraie connaissance technique. Ce renversement, je t'invite à le suivre dans les prochains numéros du Rebase.

Si cette vision te parle, transfère ce mail à un dev que ça pourrait intéresser. C'est le meilleur moyen de faire grandir Le Rebase. Merci.