Notes · Article
Gardez la session de l’agent à côté du code
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. 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.
- 1ApprouverL’agent dit que tout marche, et la CI est verte.
- 2AttendreLes laisser jusqu’à lundi.
- 3YOLOMerger, en espérant que le diff ne cachait rien.
Ce qui cèdeDe plus en plus de changements de l’IA acceptés sans revue humaine.
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.
Boucle intérieureÉcrire, compiler, tester
Boucle extérieureIntégrer, publier, déployer, observer
Sa phraseLe cycle de vie du développement logiciel, tel qu’on le connaît, est mort.
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.
La page du dépôt
Ce qui a changé
Dossiers et fichiers
Un README en bas
Commits, issues, pull requests
Le pourquoi : sur Slack, Discord ou IRC
vs
La session de l’agent
Pourquoi ça a changé
Les prompts et le plan
Chaque appel d’outil
L’approche rejetée
« Correct, mais pas ce que je voulais »
5 avril 2026Cursor : l’éditeur est devenu la solution de repli.
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, open source, est sous licence MIT et écrite en Go. D’après son README et sa doc, elle fonctionne ainsi :
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-Checkpointau 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.
- 1SessionPrompts, transcription, appels d’outils, fichiers touchés, tokens consommés.
- 2CheckpointSa propre ref sous
refs/entire/checkpoints/, pas un commit sur votre branche. - 3CommitLe diff, le SHA, et un trailer :
Entire-Checkpoint: <id>.
Son proposPas la preuve que le code est correct. La preuve que le diff correspond à l’intention.
Le piègePoussé avec le code par défaut. Un dépôt public expose ses transcriptions.
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.
Git aujourd’hui
Un seul hub
Chaque portable a une copie complète
Chaque push va au même endroit
Vous ne choisissez pas la région
vs
Sa demande
Des serveurs distribués aussi
Un hébergement aussi distribué que les clients
Qui suit la production des agents
Vous choisissez le pays et la région
Août 2026GitHub : pull requests, commits et dépôts multipliés par dix ou plus.
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.
Main a bougé sous ma PR
L’agent fait le rebase
À la demande, ou par la CI
Textuel, pas une décision
vs
On a modifié la même chose
Une personne tranche
Mon intention ou celle de Stefan ?
L’agent a le contexte, pas la décision
Pareil en CIL’agent écrit le YAML. Il faut toujours savoir quelle est la durée normale d’un run.
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.
Code
L’agent écrit
1L’agent l’écrit
2Slop cop : orange ou rouge, pas de merge
3L’agent réécrit, mêmes tests
vs
Prose
Vous écrivez
1Vous l’écrivez
2L’agent relit, comme un pair
3Vous réécrivez. Il n’écrit jamais le texte
PourquoiOn ne s’en sort pas en corrigeant un texte d’IA.
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à.
830pull requests mergées depuis le 1er octobre
739fichiers de session Claude Code sur le mini, 4,7 Go
30 joursavant que Claude Code supprime une transcription, par défaut
Avant le 28 sept. : suppriméDu 28 sept. au 27 oct. : gardé
Survit dans Git
L’issue : ce qu’il fallait
Le corps de la PR et Closes #N
Un fragment de changelog
vs
Disparaît après 30 jours
L’approche que j’ai rejetée
« Correct, mais pas ce que je voulais »
Chaque appel d’outil entre les deux
À 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 à AGNTCon + MCPCon North America, le 23 octobre 2026, en anglais (la partie sur les journaux de session commence ici, les coulisses ici)
- entireio/cli, la CLI open source, sous licence MIT
- 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, 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, 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, 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.
Texte brut: agent-session-next-to-the-code.md · Flux Atom · Toutes les notes