Accueil / Gestes courants

Pièges d'écriture : fichiers, edits parallèles et livrables perdus

Un rapport de succès écrit par un sous-agent ne prouve rien sur l'état réel des fichiers, puisqu'il démarre dans un contexte isolé sans accès à ce que l'agent principal a déjà lu ou écrit, et la seule preuve fiable reste un diff vérifié après coup, pas le texte du rapport.

Un sous-agent démarre avec un contexte isolé et neuf à chaque appel, sauf pour un fork, qui hérite au contraire de toute la conversation en cours. Il ne voit ni l'historique de la conversation principale, ni les skills déjà invoquées, ni les fichiers que l'agent principal a déjà lus. Cette isolation ne l'empêche pas de consulter lui-même le disque : il dispose des mêmes outils de lecture et d'exécution que la conversation principale, et peut très bien lancer un git diff ou relire un fichier pour vérifier son propre travail. Ce qui manque, c'est un regard extérieur : un rapport de succès reste un texte produit par le même agent qui vient d'agir, jamais une vérification indépendante, et rien ne garantit qu'il corresponde à une écriture réelle sur le disque tant que personne d'autre ne l'a contrôlé.

Le rapport de texte n'est pas la preuve

La bonne pratique documentée consiste à demander un diff vérifiable plutôt que de faire confiance au texte du rapport. Un diff montre les lignes réellement changées dans un fichier réel, un rapport de succès n'est qu'une phrase générée par le même agent qui affirme avoir réussi.

mkdir -p /tmp/demo-diff
echo "version initiale" > /tmp/demo-diff/avant.txt
echo "version modifiee" > /tmp/demo-diff/apres.txt
diff /tmp/demo-diff/avant.txt /tmp/demo-diff/apres.txt
# resultat : la ligne modifiee apparait, la preuve est dans le diff, pas dans une phrase

Un rapport en texte affirmant qu'apres.txt a été mis à jour n'apporte rien de plus que ce diff, et sans lui, rien ne distingue une écriture réelle d'une phrase inventée. Pour un script passé d'un shell à un autre, voir la leçon sur les commandes shell.

Deux écritures sur le même fichier ne sont jamais indépendantes

Deux modifications envoyées ensemble sur le même fichier, que ce soit par deux sous-agents ou par deux appels de l'outil d'édition dans le même tour, s'appliquent l'une après l'autre sur le contenu que l'outil trouve au moment où il agit, jamais sur deux copies séparées fusionnées ensuite. La seconde modification peut donc échouer à trouver le texte qu'elle cherchait, parce que la première l'a déjà changé. Envoyer les deux modifications en séquence, en relisant le fichier entre les deux, réduit ce risque et rend chaque étape vérifiable pour elle-même.

Le même principe de preuve vérifiable s'applique à un livrable long : un contenu de plusieurs paragraphes qui n'existe que dans la réponse affichée disparait avec elle dès que la conversation continue. L'écrire dans un fichier réel avant de l'afficher, comme pour une sortie structurée en mode headless, garantit qu'il reste consultable indépendamment du fil de conversation.

Un dossier temporaire par agent

Des agents lancés en parallèle qui partagent un dossier temporaire s'écrasent leurs scripts et leurs rendus. Un agent ne voit ni les fichiers temporaires des autres, ni les corrections faites hors de son brief : il peut valider du périmé. Le brief nomme donc un dossier propre à l'agent pour ses scripts et ses rendus, et après chaque passe sur un fichier que le parent a corrigé, relancez le grep des formulations retirées.

Ce que les outils d'écriture refusent

Depuis octobre 2026, Edit et NotebookEdit refusent un fichier dans un encodage ancien comme Windows-1252 ou Shift-JIS ; Write peut remplacer un tel fichier, mais il enregistre le nouveau contenu en UTF-8 et l'encodage d'origine est perdu : convertissez-le d'abord, le refus d'Edit est un signal et non une panne. Read ne lit plus en texte les fichiers binaires comme .xlsm, .parquet, .epub ou .heic.