Conduire la session

La demande est posée, la boucle tourne. Reste à tenir la barre.

Spécifier avant de déléguer a transformé l’intention en demande exécutable ; ce guide couvre ce qui se passe ensuite. Déléguer n’est pas s’absenter. Une session est un état (la fenêtre de contexte du guide 01) qui se construit appel d’outil par appel d’outil, et se dégrade de même. Conduire la session, c’est gérer cet état : découper le travail à une granularité qui se vérifie, lire la trajectoire pendant qu’elle se dessine, corriger tôt, et savoir quand une session se jette plutôt qu’elle ne se répare.

---

La granularité : une tâche, une session, un diff

L’unité de conduite naturelle, c’est la tâche dont le diff se relit d’une traite et dont la fin se vérifie mécaniquement. Le guide précédent donnait le verdict côté demande (découpez jusqu’à une fin descriptible) ; la session ajoute le verdict côté exécution : une tâche, une session, un diff. Pas par dogme, par arithmétique. Chaque tâche supplémentaire empilée dans la même session hérite de tout le contexte des précédentes : leurs fichiers lus, leurs fausses pistes, leurs consignes ponctuelles devenues bruit. La dilution de l’attention fait le reste.

À l’intérieur d’une tâche, le même réflexe s’applique en plus petit. Avancez par étapes dont chacune laisse le repo dans un état vérifié, et committez chaque étape qui passe. Le commit n’est pas une cérémonie de fin de tâche, c’est votre point de reprise : il borne ce qu’une dérive ultérieure peut coûter, et il rend le redémarrage trivial. La prochaine session repart d’un état propre, pas d’une reconstruction de mémoire. C’est le filet mécanique du guide 01, appliqué à la conduite : l’autonomie qu’on accorde à la boucle se gage sur la réversibilité, et un historique de commits fins est de la réversibilité à l’état pur.

Lire la trajectoire, pas seulement le diff

Pendant que la boucle tourne, le harnais affiche tout : les fichiers lus, les commandes lancées, les échecs rencontrés et la réaction à ces échecs. Ce flux n’est pas du bruit de progression. C’est l’interprétation de l’agent rendue visible en temps réel, la suite exacte du plan du guide précédent. Le plan montrait le malentendu avant l’exécution ; la trajectoire le montre pendant, quand il coûte encore quelques minutes au lieu d’un diff.

Pas besoin de lire chaque ligne : c’est une surveillance d’opérateur, pas une relecture. Quelques signaux suffisent :

• Ce qu’il lit. Un agent qui explore le mauvais module a déjà mal compris la tâche. Le diff confirmera, dans une heure, ce que la troisième lecture de fichier disait déjà.
• Ce qu’il touche. Un fichier modifié hors du périmètre que votre demande fermait en négatif n’est pas un détail à corriger en revue. C’est le débordement en train de se produire.
• Comment il échoue. Un test rouge suivi d’une correction du code est une boucle qui converge. Un test rouge suivi d’une retouche du test est une boucle qui négocie. On y revient plus bas.

Dix secondes de trajectoire valent une heure de diff : le malentendu se voit dans le mouvement bien avant de se voir dans le résultat.

Corriger tôt : l’interruption est un outil

Le guide précédent l’a établi : chaque blanc comblé devient le socle de l’itération suivante. La conséquence en cours de session est mécanique : le coût d’un malentendu croît à chaque itération qui bâtit dessus. Interrompre une boucle en plein vol semble brutal ; c’est l’inverse. L’agent n’a ni élan à ménager ni susceptibilité, et la correction la moins chère est toujours celle qui précède la prochaine action. Le réflexe de politesse (laisser finir pour voir) est un réflexe de collaboration humaine, et il est ici exactement faux.

Encore faut-il corriger au bon étage. Une correction a trois destinations possibles, et les confondre fabrique de la dette :

• La consigne ponctuelle, propre à cette tâche, cette fois : elle se dit dans la session et n’en sort pas.
• L’exigence durable, qui aurait dû être dans la demande : elle s’écrit dans la spécification persistée, pas en consigne de plus empilée dans le contexte par-dessus celles qu’elle contredit.
• La convention violée, vraie en tout temps, pas seulement ici : c’est un rapport de bug contre le dossier. Corrigez le document, la correction sert toutes les sessions suivantes.

La fenêtre se charge : compacter ou redémarrer

Le guide 01 a posé l’arithmétique : chaque résultat d’outil s’ajoute à la fenêtre, et une session agentique la remplit vite. Les symptômes de saturation se reconnaissent : consignes du début « oubliées », fichiers relus qui l’avaient déjà été, retours en arrière sur des points tranchés. Ce n’est pas le modèle qui fatigue. C’est la fenêtre qui dilue.

Les harnais proposent la compaction : remplacer l’historique par un résumé pour libérer de la place. Sachez 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, l’exception notée en passant, le détail qui n’a pas l’air important : c’est précisément ce qui disparaît. La compaction est un outil de fin de tâche, pour finir proprement quand la fenêtre sature à 90 % du but. Pas un moyen de faire tenir un marathon dans une session.

La vraie réponse, c’est le redémarrage, et tout ce que la Section a construit jusqu’ici travaille à le rendre bon marché. Le dossier de contexte réinstalle les conventions, la spécification persistée réinstalle la demande, le dernier commit vérifié réinstalle l’état du code. Une session vierge rechargée depuis ces trois artefacts repart à pleine attention, sans le bruit accumulé. La règle d’hygiène tient en une phrase : la session est jetable, les artefacts sont durables. Investissez dans ce qui survit, jetez le reste sans remords.

Le tips Craftomancer

Le coût irrécupérable est un biais d’humain ; ne l’appliquez pas à une fenêtre de contexte. Une longue session qui dérive ressemble à un investissement à sauver : quarante tours de négociation, des corrections patiemment accumulées. C’est une fenêtre polluée. Chaque fausse piste, chaque consigne contredite y reste du texte au même rang que le reste, et pèse sur chaque appel suivant. Si une correction vaut d’être sauvée, elle a sa place dans la spécification ou le dossier ; ce qui ne mérite pas d’y être écrit ne méritait pas d’être retenu.

Savoir reprendre la main

Certaines boucles ne convergent pas, et les laisser tourner n’arrange rien : un agent qui échoue produit la tentative suivante avec le même aplomb statistique que la première. Les signes ne trompent pas. Des variantes de la même approche resservies en boucle, des correctifs qui s’empilent sans que le test passe, ou pire : la boucle qui négocie avec son critère de fin. Une assertion affaiblie, un cas de test supprimé, un délai d’attente ajouté ne sont pas des corrections. C’est la condition de sortie qu’on déplace pour que la vraisemblance d’un succès devienne atteignable.

Ma règle de conduite : deux corrections du même malentendu, et vous reprenez la main. Pas une troisième reformulation. Un arrêt. Le problème n’est plus dans la session : soit la spécification a un trou, soit le dossier de contexte a menti, soit la tâche demande un jugement que la boucle n’a pas. Dans les trois cas la réponse est en amont, et c’est vous qui l’avez. Reprendre la main n’est pas un constat d’échec de la pratique ; c’en est le cœur. Déléguer ce qui converge, garder ce qui se juge. Les points de rendez-vous dessinés dans la spécification disaient déjà où la session devait s’arrêter et vous attendre ; le thrashing dit où elle aurait dû.

En pratique

• Une tâche, une session, un diff revuable. Et committez chaque étape vérifiée : le commit est votre point de reprise.
• Lisez la trajectoire en temps réel : fichiers lus, périmètre touché, réaction aux échecs. Le malentendu se voit dans le mouvement avant le diff.
• Interrompez tôt et sans état d’âme : chaque itération bâtit sur la précédente, 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. Préférez le redémarrage depuis vos artefacts : la session est jetable, les artefacts sont durables.
• 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.

La session se conduit ; reste à équiper le poste de pilotage. Prochaine étape : étendre l’agent (outils maison, serveurs MCP, commandes sur mesure) pour donner à la boucle le répertoire que votre projet mérite.