---
title: Gardez la session de l’agent à côté du code
description: Les agents écrivent du code plus vite que quiconque ne peut le relire, et le raisonnement derrière chaque changement meurt avec la fenêtre de chat. Notes sur la keynote de Thomas Dohmke à AGNTCon + MCPCon et son interview en coulisses, sur le checkpoint d’Entire qui relie le journal d’une session à son commit dans Git, et sur pourquoi mes propres sessions expirent bien avant les pull requests qu’elles ont écrites.
date: 2026-10-27
tags: agents de code IA, revue de code, Git, Claude Code, Entire
---

La session de l’agent vaut autant que le diff qu’elle a produit, alors elle doit vivre dans Git, à côté du code. C’est la thèse de Thomas Dohmke, et sa société Entire la construit : un checkpoint qui relie les prompts, les appels d’outils et les approches rejetées d’une session au commit où elle a abouti. La transcription ne prouve pas que le code est juste. C’est la preuve que le diff correspond à ce que vous vouliez.

Thomas a dirigé GitHub comme CEO et dirige maintenant [Entire](https://github.com/entireio/cli). Il a donné cette conférence le deuxième jour d’AGNTCon + MCPCon North America, le 23 octobre, puis a continué en coulisses. J’ai mergé 830 pull requests sur mes dépôts depuis le 1er octobre. La plupart des sessions qui les ont écrites sont déjà en train de quitter mon disque, alors celle-ci m’a touché.

## La file de revue grossit dans deux sens

Il a ouvert sur un aveu que je reconnais. Le matin, il prend une idée, demande à un agent de la planifier et de la construire, revient sur du code qui marche, ouvre une pull request en bon coéquipier, et se rend compte qu’il n’a aucune idée de ce que fait tout ce code.

Les slides y mettent des chiffres. Un graphique de The Pragmatic Engineer : les équipes qui utilisent des agents de code atteignent 57 pull requests par semaine, contre environ 10 pour les équipes classiques. Un graphique de Cursor : ces pull requests deviennent aussi beaucoup plus grosses. La file grossit donc dans deux sens à la fois, plus de changements et plus de code dans chaque changement.

Une pull request arrive toujours avec la même attente : quelqu’un va la lire et la comprendre. Quelque chose doit céder, et sa slide suivante montrait quoi : de plus en plus de changements écrits par l’IA acceptés sans revue humaine.

Il l’a fait lui-même. On est vendredi, 16 ou 17 heures, l’agent dit que tout marche, la CI est verte et le diff ne dit pas ce qui aurait pu mal tourner. Il vous reste trois pull requests. Les approuver, les laisser attendre lundi, ou merger en mode YOLO.

<figure class="fd-fig es es-f1" aria-labelledby="es1-cap" data-desc="La file de revue, d’après les slides de Thomas Dohmke. Barres à l’échelle : les équipes qui utilisent des agents de code ouvrent 57 pull requests par semaine, les équipes classiques environ 10, d’après un graphique de The Pragmatic Engineer. Une deuxième slide, de Cursor, montrait que les pull requests grossissent aussi : la file grandit en nombre et en taille. Puis le vendredi après-midi, à 16 ou 17 heures, avec trois pull requests restantes, l’agent qui dit que tout marche et la CI verte : les approuver, les laisser attendre lundi, ou merger en mode YOLO. Son propos : il nous faut une meilleure façon de gagner la confiance que ce qu’on merge est bien ce qu’on voulait.">
<div class="rp-bars">
<p class="rp-bars-h">Pull requests par semaine</p>
<p class="rp-bar rp-bar-win"><span>Équipes avec agents de code</span><i class="es-w" style="--w:57"></i><b>57</b></p>
<p class="rp-bar"><span>Équipes classiques</span><i class="es-w" style="--w:10"></i><b>~10</b></p>
<p class="es-plus"><span class="rp-k">Et chacune</span>plus grosse qu’avant, d’après Cursor</p>
</div>
<ol class="ea-rows es-fri" aria-label="Vendredi, 16 heures, trois pull requests restantes">
<li><b>1</b><span class="ea-who">Approuver</span><span>L’agent dit que tout marche, et la CI est verte.</span></li>
<li><b>2</b><span class="ea-who">Attendre</span><span>Les laisser jusqu’à lundi.</span></li>
<li class="ea-row-no"><b>3</b><span class="ea-who">YOLO</span><span>Merger, en espérant que le diff ne cachait rien.</span></li>
</ol>
<p class="mp-strip"><b>Ce qui cède</b><span>De plus en plus de changements de l’IA acceptés sans revue humaine.</span></p>
<figcaption id="es1-cap">Les barres sont à l’échelle, d’après sa slide de The Pragmatic Engineer. La slide de Cursor montrait une tendance, pas un chiffre, donc pas de barre pour elle.</figcaption>
</figure>

## La boucle était construite autour d’une personne

Sa phrase la plus piquante : le cycle de vie du développement logiciel, tel qu’on le connaît, est mort.

Vous avez déjà vu le symbole infini. Écrire, compiler et tester, c’est la boucle intérieure. Intégrer, publier, déployer et observer, c’est la boucle extérieure. Pendant vingt ans, DevOps et l’agilité ont rendu ces boucles plus rapides et les lots plus petits, et ça marchait parce qu’un développeur portait le contexte, l’intention et l’idée tout autour du cercle.

Maintenant, c’est un agent qui roule sur ces rails, et nous, à chaque gare, on lui donne une nouvelle direction. Le travail continue d’avancer. La question, c’est de savoir si l’intention du départ voyage avec lui.

En coulisses, il a inversé l’ancien objectif. On rendait les boucles plus petites pour qu’une personne puisse suivre. Maintenant, il faut les rendre plus grandes, pour que les agents continuent de travailler pendant qu’il est sur la scène d’une keynote, en rendez-vous client ou endormi, et construisent quand même ce qu’on voulait sans gaspiller de tokens. Son moment le plus frustrant : ouvrir l’appli Codex sur son téléphone le matin et découvrir qu’un run s’est arrêté cinq minutes après qu’il est allé se coucher.

Le coût joue aussi dans l’autre sens. Il a dit à des étudiants, lors d’un hackathon, que ce n’est pas un exploit de gagner un prix de 10 000 dollars si on y a dépensé 50 000 dollars en tokens.

<figure class="fd-fig es es-f2" aria-labelledby="es2-cap" data-desc="Le cycle de vie du développement logiciel sous la forme d’une boucle infinie. La boucle intérieure, à gauche : écrire, compiler, tester. La boucle extérieure, à droite : intégrer, publier, déployer, observer. Un jeton parcourt les deux boucles. L’étiquette passe par trois états. Avant : une personne porte l’intention tout autour de la boucle, alors DevOps et l’agilité ont rendu les boucles plus rapides et les lots plus petits. Maintenant : un agent conduit la boucle et on lui donne une nouvelle direction à chaque gare, et l’intention risque de ne pas voyager avec le travail. Ensuite : des boucles plus grandes qui tournent pendant que vous êtes sur scène, en réunion ou endormi, avec l’intention à bord. La phrase de Thomas Dohmke : le cycle de vie du développement logiciel, tel qu’on le connaît, est mort.">
<p class="ea-now ea-say3" aria-hidden="true"><span>Avant : une personne porte l’intention</span><span>Maintenant : un agent conduit la boucle</span><span>Ensuite : de grandes boucles, l’intention à bord</span></p>
<svg class="es-loop" viewBox="0 0 440 180" aria-hidden="true">
<path class="es-track" d="M220,90 C260,30 390,30 390,90 C390,150 260,150 220,90 C180,30 50,30 50,90 C50,150 180,150 220,90 Z"/>
<g class="fd-token"><rect x="-6" y="-6" width="12" height="12"><animateMotion dur="9s" repeatCount="indefinite" path="M220,90 C260,30 390,30 390,90 C390,150 260,150 220,90 C180,30 50,30 50,90 C50,150 180,150 220,90 Z"/></rect></g>
<text class="fd-t" x="135" y="96" text-anchor="middle">Intérieure</text>
<text class="fd-t" x="305" y="96" text-anchor="middle">Extérieure</text>
</svg>
<div class="es-key">
<p><span class="rp-k">Boucle intérieure</span>Écrire, compiler, tester</p>
<p><span class="rp-k">Boucle extérieure</span>Intégrer, publier, déployer, observer</p>
</div>
<p class="mp-strip"><b>Sa phrase</b><span>Le cycle de vie du développement logiciel, tel qu’on le connaît, est mort.</span></p>
<figcaption id="es2-cap">La boucle infinie de sa slide, redessinée. Le carré jaune, c’est celui qui conduit : avant, c’était vous.</figcaption>
</figure>

## Le dépôt montre ce qui a changé, jamais pourquoi

Slide suivante : la page d’accueil qu’a chaque dépôt GitHub. Des dossiers et des fichiers, un README quelque part en bas, quelques métadonnées sur le côté. On pouvait lire le code et reconstituer le raisonnement à partir des issues, des pull requests et des messages de commit.

Plus souvent qu’on ne veut l’admettre, a-t-il dit, on allait sur Slack, sur Discord ou sur un canal IRC demander à la personne qui avait écrit cette ligne ce qu’elle voulait dire. Le dépôt montrait ce qui avait changé. Le pourquoi n’est jamais venu avec.

Puis la dernière interface qu’on partageait tous s’est tue. Il a montré un titre de Cursor du 5 avril 2026 : l’éditeur est devenu la solution de repli. Il l’ouvre encore pour vérifier un fichier qu’un agent a écrit. Ses interfaces standard, maintenant, ce sont Claude Code dans un terminal, Codex dans une appli Mac, ou un environnement tmux qu’un développeur a fait sien.

C’est là que la réflexion se passe désormais. La session garde l’approche que vous avez rejetée, et le moment où vous avez dit à l’agent « c’est correct, mais ce n’est pas ce que je voulais ». Quand la session se termine, cet apprentissage compte encore. Dans trois ans, c’est le seul moyen de remonter le temps et de voir ce que vous vouliez vraiment.

<figure class="fd-fig es es-f3" aria-labelledby="es3-cap" data-desc="Deux endroits où un changement laisse une trace. La page du dépôt : des dossiers et des fichiers, un README en bas, des messages de commit, des issues et des pull requests. Elle montre ce qui a changé. Le pourquoi vivait ailleurs, sur Slack, Discord ou IRC, dans un message à la personne qui avait écrit la ligne. La session de l’agent : les prompts, le plan, les appels d’outils, l’approche rejetée, et le moment où vous avez dit à l’agent c’est correct, mais ce n’est pas ce que je voulais. Elle garde le pourquoi. Depuis un titre de Cursor du 5 avril 2026, l’éditeur est devenu la solution de repli : la session, dans le terminal ou l’appli, est là où la réflexion se passe.">
<div class="mp-two-row">
<div class="mp-two-card">
<p class="mp-two-who">La page du dépôt</p>
<p class="mp-two-name">Ce qui a changé</p>
<p class="mp-two-line">Dossiers et fichiers</p>
<p class="mp-two-line">Un README en bas</p>
<p class="mp-two-line">Commits, issues, pull requests</p>
<p class="mp-two-line es-gone">Le pourquoi : sur Slack, Discord ou IRC</p>
</div>
<p class="mp-two-vs">vs</p>
<div class="mp-two-card mp-two-peter">
<p class="mp-two-who">La session de l’agent</p>
<p class="mp-two-name">Pourquoi ça a changé</p>
<p class="mp-two-line">Les prompts et le plan</p>
<p class="mp-two-line">Chaque appel d’outil</p>
<p class="mp-two-line">L’approche rejetée</p>
<p class="mp-two-line">« Correct, mais pas ce que je voulais »</p>
</div>
</div>
<p class="mp-strip"><b>5 avril 2026</b><span>Cursor : l’éditeur est devenu la solution de repli.</span></p>
<figcaption id="es3-cap">La ligne barrée, c’est la partie qui n’est jamais arrivée dans le dépôt.</figcaption>
</figure>

## Un checkpoint relie la session au commit

Voici le mécanisme. Sur sa slide, le journal de session est à gauche : les appels d’outils, les réponses du modèle, ce qu’il voulait. Le commit Git est à droite, avec son diff et son SHA. Au milieu, il y a ce qu’Entire appelle un checkpoint, qui relie les deux dans Git.

Git, parce que c’est le système open source qu’on utilise depuis plus de vingt ans, donc les journaux de session y ont leur place en tant qu’objets Git. Ça veut dire aussi que ses coéquipiers peuvent lire ses sessions, et quiconque rejoindra l’équipe dans trois ans aussi.

La [CLI d’Entire](https://github.com/entireio/cli), open source, est sous licence MIT et écrite en Go. D’après son README et sa doc, elle fonctionne ainsi :

```bash
entire enable --agent claude-code   # installe les hooks de l'agent et les hooks Git du dépôt
git commit -m "..."                 # le hook demande : relier ce commit au contexte de session ?
entire checkpoint explain <id>      # le prompt, la transcription et les fichiers derrière un commit
entire session resume <branch>      # reprendre les sessions dans votre agent
```

- Les hooks de l’agent capturent la session pendant que vous travaillez : prompts, transcription, activité des outils, fichiers modifiés et consommation de tokens quand elle est disponible.
- Un checkpoint a besoin à la fois du contexte capturé et d’un commit. Les hooks Git ajoutent un trailer `Entire-Checkpoint` au message de commit, et c’est ça, le lien.
- Le checkpoint est stocké dans sa propre ref, sous `refs/entire/checkpoints/`, pas comme un commit sur votre branche. Votre branche reste propre.
- Une session peut produire plusieurs checkpoints, et un checkpoint peut réunir plusieurs sessions.

Elle prend en charge Claude Code, Codex, Cursor, Copilot CLI, OpenCode et quelques autres. Par-dessus, il y a la plateforme hébergée d’Entire, où un Trail regroupe le résultat voulu, les changements sur plusieurs dépôts, les sessions, les retours de revue, les résultats de CI et les approbations humaines, avec des barrières qui disent quand un changement est prêt à être mergé.

Le piège est dans le même README. Par défaut, les checkpoints sont poussés avec votre code, donc un dépôt public expose ses transcriptions. Le masquage des secrets tourne avant l’écriture d’un checkpoint, et ils le qualifient eux-mêmes de « best effort ». Ils suggèrent de prévisualiser avec `entire checkpoint list --outgoing`, un dépôt de checkpoints privé à part, ou `--skip-push-sessions`.

<figure class="fd-fig es es-f4" aria-labelledby="es4-cap" data-desc="Comment un checkpoint d’Entire relie une session à un commit, en trois cases. À gauche, le journal de session : prompts, transcription, appels d’outils, fichiers touchés et consommation de tokens, capturés par les hooks de l’agent pendant que vous travaillez. À droite, le commit Git : le diff, le SHA, et un trailer dans son message, Entire-Checkpoint suivi d’un identifiant. Au milieu, le checkpoint, stocké dans sa propre ref Git sous refs/entire/checkpoints, pas sur votre branche. L’étiquette passe en boucle : l’agent travaille et les hooks capturent ; vous committez et un checkpoint est écrit ; le trailer les relie. En dessous, son propos : la transcription n’est pas la preuve que le code est correct, c’est la preuve que le diff correspond à l’intention. Et l’avertissement du README : par défaut, les checkpoints sont poussés avec le code, donc un dépôt public expose ses transcriptions.">
<p class="ea-now ea-say3" aria-hidden="true"><span>L’agent travaille, les hooks capturent</span><span>Vous committez, un checkpoint s’écrit</span><span>Le trailer les relie</span></p>
<div class="es-link" aria-hidden="true">
<div class="ea-box ea-box-sv es-b1"><p class="ea-box-k">Session</p><p class="ea-box-n">Pourquoi</p></div>
<span class="es-arr">→</span>
<div class="ea-box ea-box-sb es-b2"><p class="ea-box-k">Checkpoint</p><p class="ea-box-n">Le lien</p></div>
<span class="es-arr">←</span>
<div class="ea-box es-b3"><p class="ea-box-k">Commit Git</p><p class="ea-box-n">Quoi</p></div>
</div>
<ol class="ea-rows es-parts" aria-label="Ce que contient chaque partie">
<li><b>1</b><span class="ea-who">Session</span><span>Prompts, transcription, appels d’outils, fichiers touchés, tokens consommés.</span></li>
<li><b>2</b><span class="ea-who">Checkpoint</span><span>Sa propre ref sous <code>refs/entire/checkpoints/</code>, pas un commit sur votre branche.</span></li>
<li><b>3</b><span class="ea-who">Commit</span><span>Le diff, le SHA, et un trailer : <code>Entire-Checkpoint: &lt;id&gt;</code>.</span></li>
</ol>
<p class="mp-strip"><b>Son propos</b><span>Pas la preuve que le code est correct. La preuve que le diff correspond à l’intention.</span></p>
<p class="mp-strip es-warn"><b>Le piège</b><span>Poussé avec le code par défaut. Un dépôt public expose ses transcriptions.</span></p>
<figcaption id="es4-cap">Sa slide, redessinée, avec les détails de stockage tirés du README et de la doc de la CLI. L’identifiant est schématique.</figcaption>
</figure>

## L’idée de Git, appliquée au serveur

L’autre pression, c’est la charge. Il a montré un graphique des commits de Claude Code à lui seul qui grimpent vite, puis un graphique de GitHub d’août 2026, avec les pull requests, les commits et les dépôts multipliés par dix ou plus.

Si chaque production d’agent attend qu’un humain la relise, c’est nous le goulot d’étranglement. Et si l’infrastructure ne passe pas à l’échelle aussi vite que les agents, c’est elle le suivant.

Sa réponse, c’est l’idée qu’avait Linus en créant Git, poussée un cran plus loin. Git est distribué sur nos portables : chacun a sa propre copie du dépôt. Puis on renvoie tous tout vers un hub central. Selon lui, ça ne passe pas à l’échelle, ce n’est pas résilient, et ça ne vous laisse pas choisir dans quel pays ou quelle région votre code est hébergé.

Il appelle le logiciel le plus grand sport d’équipe de la planète. Des millions de personnes en entreprise, dans l’open source, la recherche, les écoles et les hackathons, qui se moquent du pays où sont les autres et souvent n’utilisent même pas leur vrai nom. Cette communauté mérite une infrastructure décentralisée, open source et indépendante, comme Git et Linux eux-mêmes.

<figure class="fd-fig es es-f5" aria-labelledby="es5-cap" data-desc="Deux formes d’hébergement Git. Aujourd’hui : chaque développeur a une copie complète du dépôt sur sa machine, mais tous poussent vers un seul hub central ; Thomas Dohmke dit que ça ne passe pas à l’échelle, que ce n’est pas résilient et que ça ne permet pas de choisir le pays ou la région qui héberge votre code. Sa demande : rendre les serveurs distribués eux aussi, comme Git a rendu les clients distribués, pour que l’infrastructure passe à l’échelle aussi vite que les agents produisent du code. Au-dessus, la charge tirée de ses slides : un graphique de GitHub d’août 2026, avec les pull requests, les commits et les dépôts multipliés par dix ou plus.">
<div class="mp-two-row">
<div class="mp-two-card">
<p class="mp-two-who">Git aujourd’hui</p>
<p class="mp-two-name">Un seul hub</p>
<svg class="es-net" viewBox="0 0 160 110" aria-hidden="true"><g class="es-edge"><line x1="80" y1="55" x2="22" y2="18"/><line x1="80" y1="55" x2="138" y2="18"/><line x1="80" y1="55" x2="14" y2="68"/><line x1="80" y1="55" x2="146" y2="68"/><line x1="80" y1="55" x2="48" y2="100"/><line x1="80" y1="55" x2="112" y2="100"/></g><rect class="es-hub" x="66" y="41" width="28" height="28"/><g class="es-node"><circle cx="22" cy="18" r="8"/><circle cx="138" cy="18" r="8"/><circle cx="14" cy="68" r="8"/><circle cx="146" cy="68" r="8"/><circle cx="48" cy="100" r="8"/><circle cx="112" cy="100" r="8"/></g></svg>
<p class="mp-two-line">Chaque portable a une copie complète</p>
<p class="mp-two-line">Chaque push va au même endroit</p>
<p class="mp-two-line">Vous ne choisissez pas la région</p>
</div>
<p class="mp-two-vs">vs</p>
<div class="mp-two-card mp-two-peter">
<p class="mp-two-who">Sa demande</p>
<p class="mp-two-name">Des serveurs distribués aussi</p>
<svg class="es-net" viewBox="0 0 160 110" aria-hidden="true"><g class="es-edge es-edge-ag"><line x1="22" y1="18" x2="80" y2="10"/><line x1="80" y1="10" x2="138" y2="18"/><line x1="22" y1="18" x2="14" y2="68"/><line x1="138" y1="18" x2="146" y2="68"/><line x1="14" y1="68" x2="48" y2="100"/><line x1="146" y1="68" x2="112" y2="100"/><line x1="48" y1="100" x2="112" y2="100"/><line x1="80" y1="10" x2="80" y2="58"/><line x1="80" y1="58" x2="14" y2="68"/><line x1="80" y1="58" x2="112" y2="100"/></g><g class="es-node es-node-ag"><circle cx="22" cy="18" r="8"/><circle cx="80" cy="10" r="8"/><circle cx="138" cy="18" r="8"/><circle cx="14" cy="68" r="8"/><circle cx="80" cy="58" r="8"/><circle cx="146" cy="68" r="8"/><circle cx="48" cy="100" r="8"/><circle cx="112" cy="100" r="8"/></g></svg>
<p class="mp-two-line">Un hébergement aussi distribué que les clients</p>
<p class="mp-two-line">Qui suit la production des agents</p>
<p class="mp-two-line">Vous choisissez le pays et la région</p>
</div>
</div>
<p class="mp-strip"><b>Août 2026</b><span>GitHub : pull requests, commits et dépôts multipliés par dix ou plus.</span></p>
<figcaption id="es5-cap">Schématique : le nombre de machines et de liens est inventé. Le carré, c’est le hub central.</figcaption>
</figure>

## Un conflit de merge est une question d’intention

En coulisses, l’animateur a ressorti une opinion tranchée que Thomas lui avait donnée plus tôt : les conflits de merge, c’est un problème de compétences. Thomas l’a expliquée.

Les conflits de merge sont devenus faciles. Vous prévenez votre agent, ou vous laissez la CI s’en charger : la PR a un conflit, corrige-le. Les agents sont très bons sur le cas courant, quand quelqu’un a mis à jour main pendant que votre pull request était ouverte et qu’il faut faire un rebase.

L’autre cas, c’est quand deux personnes ont modifié la même chose. Là, la question n’est plus textuelle. Est-ce mon intention ou celle de Stefan qui est la bonne ? Il faut encore une personne pour ça.

Il voit la même chose dans la CI. Plus personne n’écrit les workflows GitHub Actions en YAML à la main, c’est l’agent qui le fait. Puis un run prend une demi-heure, puis une heure, et il faut quand même savoir à quoi ressemble la normale avant de lui demander d’optimiser.

<figure class="fd-fig es es-f6" aria-labelledby="es6-cap" data-desc="Deux sortes de conflits de merge, d’après l’interview de Thomas Dohmke en coulisses. Premier cas : quelqu’un a mis à jour main pendant que ma pull request était ouverte, il faut donc faire un rebase. Un agent le résout, à la demande ou automatiquement dans la CI. Deuxième cas : deux personnes ont modifié la même chose. La question devient alors de savoir quelle intention est la bonne, la mienne ou celle de Stefan, et une personne doit encore trancher. Pareil pour la CI : les agents écrivent maintenant le YAML de GitHub Actions, mais il faut toujours savoir quelle est la durée normale d’un run.">
<div class="mp-two-row">
<div class="mp-two-card mp-two-peter">
<p class="mp-two-who">Main a bougé sous ma PR</p>
<p class="mp-two-name">L’agent fait le rebase</p>
<p class="mp-two-line">À la demande, ou par la CI</p>
<p class="mp-two-line">Textuel, pas une décision</p>
</div>
<p class="mp-two-vs">vs</p>
<div class="mp-two-card">
<p class="mp-two-who">On a modifié la même chose</p>
<p class="mp-two-name">Une personne tranche</p>
<p class="mp-two-line">Mon intention ou celle de Stefan ?</p>
<p class="mp-two-line">L’agent a le contexte, pas la décision</p>
</div>
</div>
<p class="mp-strip"><b>Pareil en CI</b><span>L’agent écrit le YAML. Il faut toujours savoir quelle est la durée normale d’un run.</span></p>
<figcaption id="es6-cap">Ses deux cas, tels qu’il les a racontés. Stefan est son exemple, pas un vrai conflit.</figcaption>
</figure>

## Le code et la prose vont en sens inverse

Les cinq meilleures minutes en coulisses ne parlaient pas de code. Il a dit que quand on laisse l’IA écrire un article de blog, il a l’air génial à la première lecture. À la deuxième, il sonne comme un article de recherche écrit pour un public qui n’est pas celui du blog.

Et on ne s’en sort pas en corrigeant. Ce qu’on lit de l’IA se mêle tellement à ce qu’on a en tête que retoucher les phrases ne le rend pas écrit par un humain. Pour le texte, il faut travailler dans l’autre sens : écrire d’abord le brouillon, puis se servir de l’agent comme d’un relecteur, qui fait des retours mais n’écrit jamais le texte.

Le code est allé dans la direction opposée. L’IA écrit tout et on vérifie. Chez Entire, un de leurs ingénieurs a construit un agent appelé slop cop, qui traque la bouillie dans votre code. C’est une éval sur leur plateforme : orange ou rouge, et vous n’avez pas le droit de merger. Ensuite, vous dites à votre agent de traiter les retours du slop cop et il reconstruit, testé avec les mêmes tests unitaires et d’intégration. Réécrire du code est facile comme ça. Réécrire de la prose, non.

L’animateur a ajouté son conseil préféré : lancer toute skill de revue dans un sous-agent, parce qu’un contexte pollué par l’agent qui a écrit le code ne peut pas le juger. Thomas a mis en garde contre l’excès inverse, des skills de revue qui écrivent des milliers de lignes de tests pour un changement de cinq lignes, sur des minutes de CI que vous payez.

<figure class="fd-fig es es-f7" aria-labelledby="es7-cap" data-desc="Le code et la prose vont en sens inverse. Pour le code, l’agent écrit le premier jet ; slop cop, une éval sur la plateforme d’Entire construite par un de leurs ingénieurs, le passe au crible, et orange ou rouge bloque le merge ; puis l’agent réécrit, avec les mêmes tests unitaires et d’intégration. Pour la prose, vous écrivez vous-même le premier jet ; l’agent le relit comme un pair et fait des retours mais n’écrit jamais le texte ; puis vous réécrivez. Sa raison : on ne s’en sort pas en corrigeant un texte d’IA, parce qu’une fois lu, il oriente vos propres mots.">
<div class="mp-two-row">
<div class="mp-two-card mp-two-peter">
<p class="mp-two-who">Code</p>
<p class="mp-two-name">L’agent écrit</p>
<p class="mp-two-line"><span class="rp-k">1</span>L’agent l’écrit</p>
<p class="mp-two-line"><span class="rp-k">2</span>Slop cop : orange ou rouge, pas de merge</p>
<p class="mp-two-line"><span class="rp-k">3</span>L’agent réécrit, mêmes tests</p>
</div>
<p class="mp-two-vs">vs</p>
<div class="mp-two-card">
<p class="mp-two-who">Prose</p>
<p class="mp-two-name">Vous écrivez</p>
<p class="mp-two-line"><span class="rp-k">1</span>Vous l’écrivez</p>
<p class="mp-two-line"><span class="rp-k">2</span>L’agent relit, comme un pair</p>
<p class="mp-two-line"><span class="rp-k">3</span>Vous réécrivez. Il n’écrit jamais le texte</p>
</div>
</div>
<p class="mp-strip"><b>Pourquoi</b><span>On ne s’en sort pas en corrigeant un texte d’IA.</span></p>
<figcaption id="es7-cap">Les deux sens, tels qu’il les a décrits en coulisses.</figcaption>
</figure>

## Mes sessions expirent avant mes PR

C’est la partie qui m’a touché. Mon setup : le travail part dans une issue GitHub, un agent construit dans son propre worktree, un modèle d’un autre fournisseur relit le changement, et chaque changement finit en pull request que je merge moi-même. Depuis le 1er octobre, ça fait 830 pull requests mergées sur mes dépôts.

Les pull requests resteront pour toujours. Les sessions derrière elles, non. Sur le Mac mini, en ce moment, il y a 739 fichiers de session Claude Code, 4,7 Go de JSONL, et le plus ancien date du 28 septembre. Ce n’est pas un hasard : Claude Code supprime les transcriptions locales au bout de 30 jours par défaut, via son réglage `cleanupPeriodDays`. Mi-novembre, le raisonnement derrière chaque PR du début d’octobre aura disparu.

Ce qui survit, c’est ce que j’ai fait écrire aux agents. L’issue dit ce qu’il fallait, le corps de la PR dit ce qui a changé et `Closes #N` relie les deux, et un fragment de changelog voyage dans la même PR. C’est le pourquoi en quelques lignes. L’approche rejetée et les moments « correct, mais pas ce que je voulais » n’y arrivent pas.

Je n’ai pas encore lancé Entire, et une chose m’arrêterait sur certains dépôts : ce site est public, et les checkpoints sont poussés avec le code par défaut. Pour un dépôt public, je les voudrais dans un dépôt de checkpoints privé, ce que le README suggère déjà.

<figure class="fd-fig es es-f8" aria-labelledby="es8-cap" data-desc="Mes propres chiffres au 27 octobre 2026. Depuis le 1er octobre, 830 pull requests mergées sur mes dépôts. Sur le Mac mini, 739 fichiers de session Claude Code, 4,7 Go de JSONL, le plus ancien du 28 septembre. Une frise du 28 septembre au 27 octobre montre la fenêtre de 30 jours : Claude Code supprime les transcriptions locales au bout de 30 jours par défaut, via son réglage cleanupPeriodDays, donc les sessions sortent par le bord gauche pendant que les pull requests qu’elles ont produites restent dans Git. Ce qui survit du pourquoi : l’issue GitHub, le corps de la pull request avec Closes N, et un fragment de changelog. Ce qui ne survit pas : l’approche rejetée, et les moments correct, mais pas ce que je voulais.">
<div class="mp-stats">
<p><b>830</b><span>pull requests mergées depuis le 1er octobre</span></p>
<p><b>739</b><span>fichiers de session Claude Code sur le mini, 4,7 Go</span></p>
<p><b>30 jours</b><span>avant que Claude Code supprime une transcription, par défaut</span></p>
</div>
<div class="es-win">
<p class="rp-bars-h">Ce qui reste sur le disque</p>
<p class="es-span"><i class="es-gone-w"></i><i class="es-kept-w"></i></p>
<p class="es-ends"><span>Avant le 28 sept. : supprimé</span><span>Du 28 sept. au 27 oct. : gardé</span></p>
</div>
<div class="mp-two-row">
<div class="mp-two-card mp-two-peter">
<p class="mp-two-who">Survit dans Git</p>
<p class="mp-two-line">L’issue : ce qu’il fallait</p>
<p class="mp-two-line">Le corps de la PR et <code>Closes #N</code></p>
<p class="mp-two-line">Un fragment de changelog</p>
</div>
<p class="mp-two-vs">vs</p>
<div class="mp-two-card">
<p class="mp-two-who">Disparaît après 30 jours</p>
<p class="mp-two-line">L’approche que j’ai rejetée</p>
<p class="mp-two-line">« Correct, mais pas ce que je voulais »</p>
<p class="mp-two-line">Chaque appel d’outil entre les deux</p>
</div>
</div>
<figcaption id="es8-cap">Mon setup le jour où j’ai écrit ceci. La frise montre la fenêtre de conservation, pas mon historique de sessions à l’échelle.</figcaption>
</figure>

## À essayer

La keynote dure environ onze minutes, et la partie en coulisses à peu près onze de plus. Regardez le passage « le SDLC est mort », puis lisez la section du README d’Entire sur l’endroit où sont stockés les checkpoints avant de l’activer sur quoi que ce soit de public.

Pour aller plus loin :

- [La keynote de Thomas Dohmke](https://youtu.be/eB9I4Ixx2wc?t=3391) à AGNTCon + MCPCon North America, le 23 octobre 2026, en anglais ([la partie sur les journaux de session commence ici](https://youtu.be/eB9I4Ixx2wc?t=3630), [les coulisses ici](https://youtu.be/eB9I4Ixx2wc?t=6523))
- [entireio/cli](https://github.com/entireio/cli), la CLI open source, sous licence MIT
- [Capture checkpoints](https://docs.entire.com/guides/checkpoints/capture-checkpoints), le guide d’Entire sur la façon dont un commit reçoit son checkpoint (en anglais)
- [Relisez le plan, pas la pull request](/fr/notes/review-the-plan-not-the-pull-request.html), la réponse de Dylan Ratcliffe à la même file de revue, à la même conférence
- [Comment l’équipe Claude Code relit le code qu’écrit Claude](/fr/notes/claude-code-team-code-review.html), six couches de vérifications avant qu’une personne lise quoi que ce soit
- [L’usine logicielle agentique, c’est celle de 2022 avec une seule case changée](/fr/notes/software-factory-2022-to-lights-off.html), où ma propre file de revue apparaît

Si vous gardez vos sessions d’agent quelque part qui survit à la fenêtre de chat, dites-moi où. J’aimerais savoir si quelqu’un les relit après le merge.