Prompter n'est pas rédiger. C'est converser.

L’autre matin, j'attaque le ticket E-5201.

Je tape /ship-feature E-5201 dans mon terminal.

Et c'est parti !

À partir de là, aucune balise XML, pas de markdown bien rangé dans mon terminal. Juste une conversation en langage naturel avec Claudio. Éventuellement quelques screenshots.

C'est tout.

Pourtant, si je suis les recommandations de mon fil LinkedIn, je devrais être en train de peaufiner un prompt de 600 lignes, avec des sections, des sous-sections, des balises sémantiques et un schéma JSON en pièce jointe. À en croire certains "experts", le bon prompting, c'est ça.

Sauf que non.

Un narratif persistant dans l'agentique défend la thèse selon laquelle plus tes prompts sont structurés, balisés, hiérarchisés, plus l'agent serait performant. Templates partageables, prompts soi-disant magiques, check-lists d'éléments à ne surtout pas oublier.

Tu as dû en croiser des posts du genre « 10 prompts qui ont changé ma vie de dev. » « Le seul template dont tu auras besoin en 2026. » « La structure XML qui rend Claude 10x plus efficace. »

C'est la nouvelle carotte du contenu tech.

Elle marche bien, cette carotte. Pour au moins trois raisons.

Le problème, c'est qu'à la première vraie tâche un peu sérieuse, le template ne suffit jamais. Il manque le contexte. Il manque la réaction. Il manque le retour en arrière quand on s'aperçoit, à mi-chemin, qu'il faut tout reprendre. Le template t'amène au point A. Mais ton problème, c'est d'aller au point F, en passant par B, C, D, et de réaliser à mi-parcours qu'il faut repartir de B'.

La carotte t'a fait avancer en ligne droite. Le vrai chemin n'est jamais droit.

Alors c'est quoi, le vrai prompting ?

C'est ce qui se passe quand tu mets le template au placard et que tu commences à parler.

Dans ma recette j'utilise cinq ingrédients que j'injecte dans cet ordre, à chaque session sérieuse.

C'est le geste fondateur. Celui qui ouvre la session et qui cadre tout ce qui suit.

Pour un ticket, je tape /ship-feature E-5201. Pour un incident, /fix-bug.

Pour une exploration libre, rien du tout, j'entame directement une discussion.

Mais ces deux skills là, je les invoque d'emblée quand j'ai à développer une feature ou fixer un bug. C'est moi qui les ai créés, pour mon besoin, ma façon de coder. Ce sont en fait des orchestrateurs qui vont savoir utiliser d'autres skills et les invoquer quand nécessaire.

Et là, soyons précis : le skill, lui, est un markdown structuré. Rédigé. Sectionné. Versionné dans un repo. Il fait plusieurs centaines de lignes. Il oriente l'agent vers un pattern précis. Pour moi c'est récupérer le ticket Linear, brainstormer, écrire un plan, valider, coder en TDD, ouvrir la PR, gérer la review CodeRabbit. Tout ça, encodé une fois pour toutes.

C'est précisément parce que ce cadre existe, écrit, rangé, rejoué à l'infini, que la conversation qui s'ouvre derrière peut rester libre. Je n'ai pas à expliquer à Claudio comment on bosse chez Catalog. Le skill s'en charge. Je n'ai qu'à parler du problème.

Le markdown bien rangé existe. Il est dans mes skills. Pas dans mes prompts user.

Une fois le cadre posé, j'explique le problème. En langage naturel, comme je l'expliquerais à un collègue.

Et là, je trouve préférable de partir sur un :

« On a un user qui veut faire A, aujourd'hui il galère parce que B. Je veux que ça devienne C. »

plutôt que :

« Implémente une fonction qui prend X et retourne Y. »

La nuance a l'air bête.

Elle ne l'est pas.

Quand tu donnes directement une solution, l'agent l'exécute. Quand tu donnes le problème, il peut proposer mieux que ce que tu avais en tête. Et accessoirement, il évite de partir dans une mauvaise direction parce que tu avais mal pré-mâché la solution.

Un besoin clairement exprimé désamorce 80% des allers-retours. L'agent ne devine pas. Il déduit. Si la déduction part d'une intention floue, le code part dans une direction floue.

Depuis quelques jours, je pousse le curseur encore plus loin.

Je teste Whisprflow. Je dicte mes prompts au lieu de les taper. Usage encore léger, mais l'effet est déjà notable. Quand tu parles, tu n'es plus tenté de structurer. Tu déroules ta pensée comme tu le ferais à voix haute devant un collègue, avec des hésitations, des « non, en fait », des reformulations.

Et ce que je remarque c’est que l'agent s'en sort mieux comme ça. Pas malgré le côté décousu. Mais plutôt grâce à lui. Il capte le fil de la pensée, pas juste l'instruction finale. Ce que l'écrit a tendance à gommer, la voix le laisse intact.

C'est exactement le même geste qu'un bon brief produit. La compréhension produit, dont je te parlais dans le numéro 1, c'est le socle.

Même un skill bien fait ne sait pas tout. Il connaît la mécanique, pas le ticket. À moi de lui poser les contraintes invisibles.

Là encore j'insiste : il ne s'agit pas de donner la solution mais de poser quelques cadres.

Quel repo. Quels patterns en vigueur. Ce qu'on a déjà essayé et qui n'a pas marché. Les modules qu'il ne faut pas casser parce que d'autres services en dépendent. Souvent le CLAUDE.md joue en partie ce rôle. Mais il faut toujours apporter plus de contexte.

Je parlais dans le numéro précédent de mon /ship-log, le fameux skill qui me permet de rédiger une synthèse de tout ce qu'on a fait pour la réalisation d'un ticket.

L'agent va fouiller dans les ship-logs pour détecter ce qui a déjà été fait et pourquoi on l'a fait. Ce recueil de ship-log devient un corpus très précieux pour l'agent.

Un agent sans contexte produit du code générique. Techniquement correct, mais avec le risque de tomber à côté sur l'aspect fonctionnel. Le contexte n'est pas optionnel, c'est la moitié du brief.

C'est l'ingrédient le plus sous-estimé. Et c'est probablement celui qui sépare un prompteur moyen d'un bon prompteur.

Reprenons depuis le début : on a posé le cadre avec un skill, on a expliqué le besoin en langage naturel, on a apporté du contexte. À ce stade, Claudio est armé pour proposer. Et il faut le laisser faire. C'est même tout l'intérêt.

Mais.

Claudio a tendance à flatter, à proposer des alternatives parce qu'il a été entraîné à être utile. Si tu laisses faire jusqu'au bout, il te détourne parfois de ce que tu sais être juste.

Il y a une dizaine de jours, je bossais sur un wizard multi-step. Claudio est parti spontanément sur un React Context. Solution classique, défendable, qui marche. Sauf que chez Catalog, on a une règle stable : state UI = Zustand, state backend = React Query. J'ai dit non. Il a insisté. J'ai redit non, en expliquant. On a tranché sur Zustand. À l'arrivée, c'était la bonne décision.

Le principe : on laisse l'agent proposer, on écoute, on évalue. Mais quand on sait, on tranche. Et on retranche s'il insiste. Le dernier mot revient au dev.

À l'intérieur du cadre posé par /ship-feature, il y a des sous-skills qui s'enchaînent : brainstorming, writing-plans, TDD, verification-before-completion, code-review. Je ne les récite pas par cœur. Je sais qu'ils existent, qu'ils ont chacun leur logique, et surtout je sais à quel moment les sortir.

Ça, ce n'est pas du markdown. C'est du timing. C'est savoir, dans le fil de la conversation, qu'il est temps de basculer du brainstorm vers le plan. Que cette phase mérite un sous-agent dédié. Que là il faut une vérification avant de continuer.

Il y a une distinction qu'il faut poser, parce que c'est elle qui résout le malentendu.

Les system prompts, les skills, les CLAUDE.md sont statiques. Écrits une fois, mis à jour régulièrement, rejoués des centaines de fois. Et c'est là que le markdown structuré a sa place : sections, balises, conventions.

Tout ce que je moquais en début d'article est légitime ici.

Parce qu'ici, c'est durable, partagé, versionné.

La conversation, elle, est l'inverse. Vivante, contextuelle, réactive. Elle se joue une fois, sur ce contexte précis. Elle n'a pas vocation à être rejouée.

Un bon dev DAA passe beaucoup de temps à soigner ses skills. Très peu à formater ses prompts.

Mes skills sont du markdown structuré.

Et c'est la seule chose, dans mon workflow, qui l'est. C'est ce qui me dispense d'en écrire ailleurs.

Si tu veux investir quelque part, investis sur tes skills. C'est là que se cache l'effet de levier. Les prompts user, eux, se musclent par la pratique. Pas par la lecture de templates.

Voilà la thèse, posée nettement : le bon prompteur n'écrit pas. Il parle. Sa compétence n'est pas dans le document, elle est dans la conduite de la conversation. Tenir le cap, ajuster, retoquer, repartir, savoir quand sortir tel skill, savoir quand insister.

Et cette compétence ne s'apprend pas en lisant des templates. Elle s'apprend en pratiquant la conversation. En se trompant. En ajustant. En tenant ses positions.

En tant que dev, notre métier consistait à écrire du code propre.

On découvre qu'il consiste maintenant à mener des conversations claires.

Mais n'est-ce pas ce qu'on faisait déjà dans les revues de PR, les sessions d'archi, les workshops, les pair-codings ?

La transformation, c'est un renversement d'échelle. Ce qui occupait l'essentiel de notre temps est passé à l'agent. Et tout ce temps libéré, on le réinvestit enfin là où on apporte vraiment de la valeur : à résoudre des problèmes.

Si cette idée résonne, transfère ce mail à un dev qui s'épuise à écrire des prompts plutôt qu'à les vivre. C'est le meilleur moyen de faire grandir Le Rebase.