Conduire la session

Spécifier avant de déléguer a transformé votre intention en demande exécutable. Vous validez, l’agent part. Et là arrive la question que tout le monde se pose la première fois : je fais quoi, moi, pendant ce temps ?

Pendant longtemps, ma réponse a été « autre chose ». Je lançais, j’allais répondre à trois messages, je revenais devant un diff de huit cents lignes convaincu d’avoir gagné du temps. Spoiler : non. Déléguer, ce n’est pas s’absenter.

Une session, c’est un état : sa fenêtre de contexte. Chaque appel d’outil la construit, et chaque appel d’outil la dégrade. Tout ce qui suit, c’est de la gestion de cet état.

---

Pourquoi une seule tâche par session ?

Parce que la deuxième tâche hérite de tout ce qu’a laissé la première : les fausses pistes, les fichiers lus pour rien, les consignes ponctuelles devenues du bruit. La bonne granularité, c’est la tâche dont le diff se relit d’une traite et dont la fin se vérifie mécaniquement. Une tâche, une session, un diff.

La tentation d’enchaîner est pourtant évidente : le contexte est déjà chaud, l’agent « connaît » le projet, ça semble idiot de tout jeter. Sauf que la dilution de l’attention fait son travail, et que ce contexte chaud est aussi un contexte sale.

À l’intérieur d’une tâche, même réflexe en plus petit : la boucle n’avance seule que là où vous pouvez défaire. Avancez par étapes qui laissent chacune le repo dans un état vérifié, et committez celles qui passent.

git commit -m "feat: extrait le client HTTP"

Oui, c’est fastidieux quand l’étape fait douze lignes. Et c’est quand même le bon geste : ce commit, c’est votre point de reprise, et il borne ce qu’une dérive vous coûtera.

Certains harnais s’en chargent pour vous. Aider crée un commit git à chaque modification qu’il applique, et /undo l’annule. Avec Claude Code ou Codex CLI, le commit reste à votre charge.

Comment lire ce que fait l’agent pendant qu’il tourne ?

En surveillant trois signaux : les fichiers qu’il ouvre, le périmètre qu’il touche, et sa réaction à l’échec. Pas besoin de lire chaque ligne qui défile — votre harnais montre déjà tout ça. Claude Code déroule chaque appel d’outil dans le terminal, Cursor les empile dans son panneau Agent.

Le plan vous montrait le malentendu avant l’exécution. La trajectoire vous le montre pendant, au moment où il coûte deux minutes au lieu d’un diff de huit cents lignes à défaire.

• Les fichiers qu’il ouvre. Un agent qui explore le mauvais module a déjà mal compris la tâche. Le diff vous le confirmera dans une heure, alors que la troisième lecture de fichier vous le disait déjà.
• Le périmètre qu’il touche. Un fichier modifié en dehors de ce que votre demande concernait ne se rattrape pas en revue. Là, vous pouvez regarder le débordement se produire.
• Sa réaction à l’échec. Test rouge, puis correction du code : la boucle converge. Test rouge, puis retouche du test : elle négocie. Ce deuxième cas, gardez-le en tête, on y revient plus bas.

Quand faut-il interrompre l’agent ?

Dès que vous voyez le malentendu, sans attendre la fin de son tour. Un agent qui a mal compris ne s’arrête pas tout seul : il construit la suite sur son malentendu, et chaque itération rend la correction plus chère.

Alors coupez-lui la parole. C’est peut-être le réflexe qui m’a demandé le plus de temps à acquérir, parce qu’on a tous été élevés à ne pas interrompre. Mais un agent ne se vexe pas, et rien ne se perd : Échap dans Claude Code, le bouton stop dans le panneau de Cursor, et l’historique reste là. Le laisser finir « pour voir », c’est de la politesse entre humains ; ici, ça ajoute juste des itérations à défaire.

Où corriger : session, spécification ou dossier de contexte ?

Reste à corriger au bon endroit : confondre les trois ne se paie pas dans cette session, mais dans toutes les suivantes.

• Vrai pour cette tâche et cette fois : dites-le dans la session, ça ne va pas plus loin.
• Ce qui manquait au prompt et qui vaut pour tout le projet : ajoutez-le à la spec. Le redire en consigne, c’est fabriquer une consigne de plus qui contredit les précédentes sans les effacer.
• La règle du projet, vraie tout le temps : là, c’est un bug dans le dossier de contexte — votre CLAUDE.md, votre AGENTS.md ou votre .cursor/rules selon le harnais. Corrigez-le une fois, et toutes les sessions suivantes en profitent.

Compacter ou redémarrer une session saturée ?

Redémarrer, presque toujours. Compacter sert à finir une tâche arrivée à 90 % du but ; pour tout le reste, /clear et vous rechargez vos trois artefacts.

Les symptômes de saturation se reconnaissent vite : les consignes du début « oubliées », des fichiers relus alors qu’ils l’avaient déjà été, des retours en arrière sur des points que vous pensiez tranchés. J’aime bien l’image du plan de travail. Vous commencez propre, puis à chaque outil sorti il reste moins de place, et au bout d’un moment vous cherchez le couteau sous trois planches à découper. Le modèle, lui, est intact à chaque appel. C’est la fenêtre qui dilue.

/compact   # résume la session pour continuer dedans
/clear     # repart d'une fenêtre vierge

Claude Code compacte tout seul quand la saturation approche, et expose /compact pour le déclencher à la main. Sachez juste ce que vous achetez : un résumé est une continuation comme une autre, et ce qu’il laisse tomber est décidé statistiquement, pas par importance. La consigne fine et l’exception notée en passant, voilà exactement ce qui disparaît.

Le redémarrage répond mieux, et il est bien moins cher qu’il n’en a l’air. Un /clear, puis vous rechargez depuis trois artefacts : le dossier de contexte pour les conventions, la spécification persistée pour la demande, le dernier commit vérifié pour l’état du code. La session repart à pleine attention, sans rien du bruit accumulé.

LE CRAFTOMANCER

Le coût irrécupérable est un biais d’humain ; ne l’appliquez pas à une fenêtre de contexte. Quarante tours de négociation ressemblent à un investissement à sauver, mais rien n’y est récupérable : chaque fausse piste pèse sur l’appel suivant au même rang que le reste. Si une correction vaut d’être gardée, écrivez-la dans la spécification ou le dossier, puis jetez la session.

Quand reprendre la main ?

Après deux corrections du même malentendu. Deux, c’est arbitraire — mettez-en trois si vous préférez, du moment que vous comptez. Passé ce seuil, le problème n’est plus dans la session : la spécification a un trou, le dossier de contexte a menti, ou la tâche demande un jugement que la boucle n’a pas.

Parce que certaines boucles ne convergent pas, et les laisser tourner n’arrange rien : un agent qui échoue produit la tentative suivante sans rien tirer de la précédente. Vous voyez alors défiler des variantes de la même approche, ou des correctifs qui s’empilent sans que le test passe.

Et parfois, pire : la boucle négocie avec son critère de fin. Une assertion affaiblie, un cas de test supprimé, un délai d’attente allongé. Rien de tout ça ne corrige quoi que ce soit — c’est la condition de sortie qui se déplace pour qu’un succès devienne atteignable. La première fois que je l’ai vu passer, j’ai mis dix minutes à comprendre pourquoi mon build était vert alors que la feature ne marchait pas.

En pratique

• Une tâche, une session, un diff revuable. Committez chaque étape vérifiée : le commit est votre point de reprise.
• Lisez la trajectoire en direct : fichiers ouverts, périmètre touché, réaction aux échecs. Le malentendu se voit dans le mouvement avant de se voir dans le diff.
• Interrompez tôt. Chaque itération bâtit sur la précédente, et le coût d’un malentendu croît mécaniquement.
• Corrigez au bon étage : la consigne ponctuelle dans la session, l’exigence durable dans la spécification, la convention dans le dossier de contexte.
• Compactez pour finir une tâche, jamais pour en enchaîner trois. Redémarrez plutôt : /clear, puis rechargez le dossier, la spécification et le dernier commit vérifié.
• Deux corrections du même malentendu, ou une boucle qui négocie avec ses tests : reprenez la main, le problème est en amont de la session.

Vérifiez votre modèle

Quatre questions pour voir si vous tiendriez la barre. Cliquez une réponse : le verdict s’affiche.

RUN · IV 0 / 4

jack in — choisissez votre réponse

Un test passe au rouge, l’agent retouche le test. Ça s’appelle ?

▶ une boucle qui négocie avec son critère de fin ▶ une optimisation légitime du test ▶ un signe que la tâche est presque finie

Quand vous compactez une session, qu’est-ce qui disparaît ?

▶ ce que le résumé juge statistiquement peu saillant ▶ les parties les plus anciennes de l’historique ▶ rien d’important, c’est le rôle du résumé

Vous venez de corriger deux fois le même malentendu. Le bon geste ?

▶ vous arrêtez : le problème est en amont de la session ▶ vous reformulez une troisième fois, plus précisément ▶ vous laissez tourner, la boucle finira par converger

Qu’est-ce qui rend un redémarrage bon marché ?

▶ le dossier, la spécification persistée, le dernier commit vérifié ▶ un bon résumé de la session à recoller au démarrage ▶ de la place regagnée dans la fenêtre en cours

Vous savez conduire la boucle. Reste à l’équiper. Prochaine étape : étendre l’agent avec vos propres outils et des serveurs MCP, pour lui donner enfin le répertoire que votre projet mérite.