--- title: Relisez le plan, pas la pull request description: Overmind ne relit plus ses propres pull requests : la revue par les pairs porte désormais sur un plan d’une page et demie, écrit avant que l’agent ne code. Notes sur la conférence de Dylan Ratcliffe, la boucle until derrière, et un lead time passé de 3,2 à 1,3 jour. date: 2026-10-15 tags: agents de code IA, revue de code, planification, MCP --- Overmind ne relit plus ses propres pull requests. Presque tout le code que l’entreprise met en production n’est plus lu par aucun humain, auteur compris. La revue n’a pas disparu pour autant. Elle s’est déplacée vers un plan d’environ une page et demie, dont on débat avant qu’un agent écrive la moindre ligne, et dans les trois semaines qui ont suivi le changement, l’équipe a fermé trois fois plus d’issues, tandis que le lead time tombait de 3,2 jours à 1,3. La conférence, c’est [Pull Requests Are Dead, Long Live Peer Review](https://www.youtube.com/watch?v=5lq5zp6wYbQ), de Dylan Ratcliffe, fondateur et CEO d’[Overmind](https://overmind.tech/), donnée à AGNTCon + MCPCon North America 2026. Overmind utilise l’IA pour simuler les changements sur de grosses infrastructures back-end. Dans ma [note sur l’usine logicielle](/fr/notes/software-factory-2022-to-lights-off.html), la partie lente de ma propre installation, c’est ma file de revue. Cette conférence, c’est la réponse d’une équipe à ce problème. ## La revue remplissait quatre rôles Comme la plupart des équipes, Overmind comptait sur la revue de code pour bien plus que les bugs. Elle attrapait les bugs, elle couvrait la conformité SOC 2 et ISO 27001, elle formait les ingénieurs juniors, et elle construisait une vision partagée de la façon dont le système fonctionne vraiment. Ce qui faisait marcher tout ça, c’est qu’un humain tenait à chaque ligne. Commentez la pull request d’une personne, et il en sort quelque chose de bon dans tous les cas. Si vous avez raison, elle apprend et le produit s’améliore. Si elle conteste, c’est qu’il existe une contrainte que vous ignoriez, et maintenant vous la connaissez. Commentez la pull request d’un bot qui traite lui-même les commentaires de revue, et vous obtenez le même acquiescement empressé, que vous ayez entièrement raison ou entièrement tort. C’est sa première leçon : l’IA n’est pas votre pair, donc la revue par les pairs ne s’applique pas à son travail.
  1. 1Attraper les bugs
  2. 2Conformité SOC 2 et ISO 27001
  3. 3Former les ingénieurs juniors
  4. 4Une vision partagée du fonctionnement du système

L’auteur est une personne

Votre commentaire de revue

Si vous aviez raisonElle apprend, et le produit s’améliore

Si elle avait raisonVous découvrez une contrainte que vous ignoriez

vs

L’auteur est un bot

Votre commentaire de revue

Si vous aviez raisonAcquiesce et applique

Si vous aviez tortAcquiesce et applique

Leçon 1L’IA n’est pas votre pair, donc la revue par les pairs ne s’applique pas à son travail.

Les quatre rôles, puis un même commentaire envoyé à deux auteurs. Seule la personne vous donne une réponse qui dépend de qui avait raison.
## Deux personnes ont livré plus que toute l’entreprise En début d’année, Overmind comptait environ 80 % d’ingénieurs. Le produit, c’était Dylan et un product manager. Ils trouvaient l’idée, faisaient la recherche et posaient le cadrage, c’est-à-dire l’architecture de haut niveau. Venaient ensuite une réunion de passation, une série de questions, puis les ingénieurs planifiaient et construisaient avec l’IA. Le hic : une fois que Dylan avait tout fait jusqu’au cadrage, confier directement le travail à un agent allait plus vite que le confier à une personne. Il vit à San Francisco, une bonne partie de ses ingénieurs sont en Europe, et l’agent ne dort jamais. Une semaine, le product manager et lui ont donc produit plus que toutes les autres personnes de l’entreprise réunies, sur chaque indicateur qu’ils suivaient : lignes de code, pull requests, tickets fermés et story points. Ça ne fait que six personnes, mais ce sont deux personnes qui abattent le travail de six ingénieurs à plein temps. « Aucun de nous deux n’est ingénieur », a-t-il dit. Il reconnaît ouvertement avoir sérieusement envisagé de licencier la moitié des ingénieurs pour les remplacer par des product managers. Il ne l’a pas fait. À la place, il a fait venir tout le monde en France pendant une semaine pour remettre le process à plat.

Dylan et le product managerqui confient le travail directement aux agents

Les six autrestout le reste de l’entreprise

Devant sur chaque indicateurlignes de codepull requeststickets fermésstory points

EnvisagéLicencier la moitié des ingénieurs, embaucher des product managers

FaitFaire venir tout le monde en France une semaine

Dylan« Aucun de nous deux n’est ingénieur. »

La production d’une semaine, telle que Dylan l’a racontée. Il n’a donné aucun chiffre, seulement « plus que tous les autres réunis » : la bascule montre quel côté l’a emporté, pas de combien.
## Le travail s’est déplacé vers la gauche Voici la slide que j’ai retenue de la conférence, redessinée. Avant, le produit avait l’idée, la recherche et le cadrage, et l’ingénierie avait le plan, la construction et la livraison. Désormais, le produit garde l’idée, l’ingénierie prend la recherche, le cadrage et le plan, et un agent construit et livre.

une personne sur le travaille travail s’est déplacé à gauche

Leçon 2Si votre métier consiste à transformer des specs détaillées en code de qualité, vous n’avez plus de métier. C’est vrai depuis janvier et Opus 4.5, dit-il.

Redessiné d’après la slide. Sa légende : « Une fois le plan écrit, le confier à un agent allait plus vite que le confier à une personne. »
Sa deuxième leçon est sortie de cette semaine-là : si vous pensez que votre métier consiste à transformer des specs détaillées en code de qualité, vous n’avez plus de métier. Selon lui, c’est vrai depuis janvier et Opus 4.5. ## Une page, 24 heures, aucune question Déplacer les ingénieurs vers la gauche s’est accompagné d’une règle. Le produit remet un document d’une page. L’ingénieur qui le reçoit montre une démo sous 24 heures, et n’a le droit de poser aucune question pendant ce temps. Un document d’une page est plein de trous, et c’est tout l’intérêt. Est-ce que ça doit marcher sur mobile ? Allez vérifier si les gens utilisent ce genre d’app sur mobile. Obligés de lever l’ambiguïté eux-mêmes, les ingénieurs avaient le plus souvent raison. Personne ne peut absorber toute cette nouvelle ambiguïté et continuer à tenir à chaque ligne de code, cela dit. Le détail ligne par ligne est donc passé aux agents.

  1. 1Une page

    Venue du produit, pleine de trous exprès

  2. 224 heures

    Aucune question autorisée

  3. 3Une démo

    Chaque trou comblé selon le jugement de l’ingénieur

RésultatLaissés seuls face à l’ambiguïté, les ingénieurs avaient le plus souvent raison.

La règle de la semaine en France. Les traits en pointillés du document sont les trous que l’ingénieur doit combler seul.
## Toutes les boucles d’agents ne se valent pas Quand l’équipe a étudié comment les gens construisent des « usines logicielles » et des « usines lumières éteintes » agentiques, la plupart faisaient tourner ce qu’il appelle une boucle do-while. L’agent prend un ticket, décide de l’approche, fait les compromis, écrit le code et les tests, enregistre parfois une vidéo de démo, et ouvre une pull request tout à la fin. Ensuite, un humain doit reconstituer chaque décision à partir du code. L’idée que l’IA lui prenne son travail l’inquiète un peu. Ce qui l’inquiète davantage, c’est que l’IA lui prenne la partie intéressante et qu’on le paie pour valider des décisions prises sans lui. L’équipe a donc construit une boucle until. Des agents explorent la base de code, par exemple pour vérifier s’il existe déjà une pratique pour ce genre de changement. Des humains décident de l’approche, font les compromis et écrivent un plan d’implémentation, qu’un pair relit. Puis un agent écrit le code et un second agent le compare au plan. Le moindre écart renvoie le code, et la boucle tourne jusqu’à ce que code et plan correspondent.

La plupart des usines d’agents

do-while

  1. AgentPrend un ticket
  2. AgentDécide de l’approche et des compromis
  3. AgentÉcrit le code et les tests, parfois une vidéo de démo
  4. AgentOuvre une pull request
  5. HumainRelit : reconstitue chaque décision à partir du code

vs

Ce que fait tourner Overmind

until

  1. AgentExplore la base de code
  2. HumainDécide de l’approche et des compromis
  3. HumainÉcrit le plan
  4. HumainRelit : un pair lit le plan
  5. Se répète jusqu’à ce que le code corresponde au plan
    1. AgentÉcrit le code
    2. AgentCompare le code au plan
  6. ProdLivre, sans qu’aucun humain lise le code
Les deux boucles, de haut en bas. La ligne surlignée marque l’endroit où un humain relit : à la fin dans l’une, avant que le code existe dans l’autre.
Une fois que la boucle ressemble à ça, la place de la revue par les pairs saute aux yeux : avant que la boucle démarre. ## Relisez le plan, puis arrêtez de lire Les plans ont droit à une vraie revue, parce que les gens y tiennent de nouveau. Quand quelqu’un commente aujourd’hui une pull request de Dylan, sa réaction honnête, c’est : « Je n’ai même pas lu ce code. Si ça se trouve, vous êtes le premier à l’avoir lu. » Quand quelqu’un commente son plan, il argumente, parce qu’il en a écrit chaque ligne et sait pourquoi chacune est là. Il traite un plan approuvé comme un changement pré-approuvé. La plupart des dispositifs de conformité connaissent déjà l’idée : un changement bien défini peut être approuvé à l’avance, tant que vous faites exactement ça. La boucle ne peut pas se terminer tant que le code ne correspond pas à un plan approuvé, donc le code part en production sans seconde revue humaine. Deux contrôles gardent le système honnête : - Des humains vérifient par sondage un petit pourcentage des comparaisons entre plan et code, pour s’assurer que l’agent de revue ne se trompe pas. - Si l’agent de code trouve une meilleure idée, ou une vraie raison de ne pas suivre le plan, il consigne un écart, et un humain en prend acte. Overmind était en plein audit au moment de la conférence. Dylan est convaincu que le process est conforme, et il le saura à la fin de l’audit. L’outillage n’a aucune interface utilisateur. Les plans s’écrivent dans Claude Code ou dans n’importe quel harnais (harness), et envoyer un plan, le récupérer ou laisser une revue, ce sont tous des appels MCP.

Humains

Plan approuvé

  • Environ une page et demie
  • Les compromis et leurs raisons
  • Un changement pré-approuvé

Agents

La boucle until

  • L’un écrit le code
  • L’autre le compare au plan
  • Pas de sortie tant qu’ils diffèrent

Pas de seconde revue

Production

  • Du code qu’aucun humain n’a lu
  • Conforme à un plan approuvé

SondageDes humains vérifient un petit pourcentage des comparaisons entre plan et code

Un écartL’agent consigne pourquoi il a quitté le plan, et un humain en prend acte

Sans UILes plans s’écrivent dans Claude Code ou dans n’importe quel harnais. Les envoyer, les récupérer et les relire, ce sont des appels MCP.

Le changement pré-approuvé, de bout en bout, avec les deux contrôles en dessous. L’audit était encore en cours au moment de la conférence.
## Trois semaines plus tard L’équipe a changé de process en une semaine, puis a comparé les trois semaines suivantes aux trois précédentes. Le nombre d’issues terminées a triplé, celui des commits aussi. Le lead time, entre le moment où un ticket est pris et celui où il tourne en production, est tombé de 3,2 jours à 1,3. Ce sont les chiffres d’une petite équipe, trois semaines contre trois semaines, mesurés par l’entreprise elle-même. Et Overmind vend désormais un produit construit sur exactement cette idée : prenez la conférence comme un argument solide, venant de quelqu’un qui a un intérêt dans l’affaire.

3×issues terminées

3×commits

1,3 jourde lead time, contre 3,2

Lead time, du ticket pris au code en production

Les trois semaines d’avant3,2 jours

Les trois semaines d’après1,3 jour

Les propres chiffres d’Overmind pour sa propre équipe, tels que Dylan les a donnés sur scène. Les deux barres sont à l’échelle.
## Le goulot d’étranglement, c’était l’attention L’équipe n’a jamais passé 90 % de ses journées en revue de code, donc le facteur 3 ne vient pas du temps de revue économisé. Sa réponse : l’attention. Les pull requests obligeaient à jongler avec trop de balles à la fois et à changer de contexte en permanence. L’ancienne chronologie d’un changement : environ 3 heures à écrire le code, 15 minutes à ouvrir la pull request, une journée et demie à attendre un relecteur débordé, puis une heure d’allers-retours. Vous ne pouvez rien en oublier, parce que vous êtes le seul à comprendre le code. Le temps qu’un commentaire revienne, il avait écrit 15 000 lignes de plus et ne se souvenait plus de ce qu’il essayait de faire, au point qu’abandonner le changement pouvait être plus simple que de s’y replonger. Environ quatre heures et demie de travail ont vécu dans sa tête pendant une quarantaine d’heures. Un plan s’écrit plus vite, et se relit beaucoup plus vite, que 3 000 lignes de Go. Une fois approuvé, vous le retenez comme la description du fonctionnement du système. Le code n’existe pas encore, mais il existera dans trois heures environ, parce qu’il n’y a pas d’autre sortie de la boucle. Ça coûte deux heures d’attention, à peu près.
Les durées de son exemple, à l’échelle. Il n’a pas détaillé les « deux heures environ » du plan, donc elles sont dessinées en un seul bloc.
## Une recette se refuse plus facilement qu’un plat Debout dans la cuisine, au moment de décider quoi préparer, c’est facile de dire « Je n’ai pas envie de salade. » Une fois la salade faite, vous ne pouvez plus. Demander à quelqu’un de refaire un plat demande une énergie à la Gordon Ramsay, et c’est exactement ça, rejeter une pull request. C’est dur émotionnellement, et c’est pourquoi c’étaient en général les ingénieurs les plus seniors qui s’en chargeaient. Les plans ont changé ça. Overmind a désormais 2,8 fois plus de chances de rejeter un plan qu’elle n’en a jamais eu de rejeter une pull request, et les rejets viennent de toute l’équipe, produit compris. C’est aussi bien moins cher : un plan rejeté ajoute environ 40 minutes de lead time, alors que le moindre commentaire sur une pull request ajoutait 16 heures. Sa grande crainte au départ, c’était de voir des agents écrire les plans et d’autres agents les relire, sans personne pour rien lire. Il dit que les chiffres montrent que ce n’est pas arrivé. Les plans sont assez courts pour que les gens les lisent, et ils y tiennent. Ça ouvre aussi une porte aux juniors. Un junior qui ne comprend pas un plan peut en discuter avec son agent jusqu’à ce qu’il le comprenne, et rejeter ce qui n’a toujours pas de sens. Le product manager de Dylan relit les plans d’ingénierie exactement comme ça, et quand il conteste, il a raison environ 80 % du temps. Dylan voit une victoire dans les 8 % de plans abandonnés. Le quoi semblait bon, le comment a montré que ça n’en valait pas la peine, et personne n’a eu à le construire juste parce que c’était déjà dans le sprint.

Avant la cuisson

Une recette

« Pas envie de salade », c’est facile à dire

Le plan : tout le monde en rejette désormais

vs

Une fois cuisiné

Un plat

Le renvoyer demande une énergie à la Gordon Ramsay

La pull request : les seniors s’en chargeaient

Lead time ajouté par une objection

Un plan est rejeté+40 min

Une pull request reçoit un commentaire+16 h

2,8×plus de chances de rejeter un plan qu’une pull request

80 %des objections du product manager étaient justes

8 %des plans abandonnés avant toute ligne de code

La salade, puis les chiffres de la conférence. Les deux barres d’objection sont à l’échelle : 40 minutes contre 16 heures.
## Le comment compte toujours Il a conclu en contredisant une phrase de Paul Graham : « Quand n’importe qui peut fabriquer n’importe quoi, ce qui fait la différence, c’est ce que vous choisissez de fabriquer. » Pour Dylan, ce qui fait la différence, c’est toujours la façon dont vous le fabriquez. Deux ordinateurs portables peuvent avoir exactement la même fiche technique et être des produits complètement différents. La différence, ce sont des centaines de décisions sur le comment, prises en cours de route, et ce sont elles qui décident si un produit est performant, s’il tient la charge et s’il reste facile à déboguer. Son conseil : ne restez pas en bas d’une boucle où l’agent prend ces décisions à votre place, et refusez les outils qui vous y mettent. Ce qui change, c’est le niveau auquel vous y répondez. Vous ne vous souciez plus de l’organisation des fichiers ni du nom des fonctions. Vous décidez toujours de la façon dont les données circulent, dont l’authentification fonctionne et dont le système gère les pannes.

Un produitMême fiche techniqueUn autre produit

Vous décidez toujours, dans le planle flux des donnéesle fonctionnement de l’authentificationla gestion des pannes

Les agents décident, dans le codel’organisation des fichiersle nommage des fonctions

DylanNe restez pas en bas de la boucle, et refusez les outils qui vous y mettent.

Même fiche technique, deux produits : la différence, c’est le comment. Les questions de comment ne disparaissent pas, elles remontent dans le plan.
## Essayez Overmind a publié son outil interne sous le nom d’[until](https://until.dev/), « des tickets adossés à git, pour les humains et les agents ». Vous écrivez le plan, quelqu’un le valide, chaque section du plan devient une tâche que vos agents prennent en charge, et un agent de revue compare le code au plan, si bien que tout ce qui manque ou dépasse vous revient sous forme de décision. Pour l’instant, c’est sur liste d’attente uniquement, et le site cite Claude Code, Cursor, Codex, Pi, Factory Droid, Amp et OpenCode. L’argument existe aussi sous forme de manifeste, [AI Is Not Your Peer](https://notyourpeer.com/), signé Dylan Ratcliffe, James Lane et David Schmitt. Sa phrase clé : « L’artefact qui mérite une revue, c’est le plan que nous avons écrit avant que l’agent écrive quoi que ce soit. »

  1. 01Vous écrivez le plan

    Chaque fonctionnalité commence par un plan, et le plan vous appartient

  2. 02Quelqu’un le valide

    Aucun agent ne démarre tant qu’une personne n’a pas dit oui

  3. 03Les agents prennent les tâches

    Chaque section du plan devient une tâche nommée

  4. 04Vérifier l’écart

    Tout ce qui manque ou dépasse vous revient sous forme de décision

Harnais citésClaude CodeCursorCodexPiFactory DroidAmpOpenCode

Liste d’attenteDes tickets adossés à git, pour les humains et les agents.

Les quatre étapes telles que until.dev les décrit. Les deux premières reviennent aux humains, les deux dernières aux agents.
Pour aller plus loin : - [Pull Requests Are Dead, Long Live Peer Review](https://www.youtube.com/watch?v=5lq5zp6wYbQ), la conférence, 25 minutes - [AI Is Not Your Peer](https://notyourpeer.com/), le manifeste - [until](https://until.dev/), l’outil de revue de plan, sur liste d’attente - [L’usine logicielle agentique, c’est celle de 2022 avec une seule case changée](/fr/notes/software-factory-2022-to-lights-off.html), là où la revue est devenue mon goulot d’étranglement - [Ce qui casse quand un agent IA gère un vrai commerce](/fr/notes/what-breaks-when-an-agent-runs-a-business.html), une autre conférence d’AGNTCon + MCPCon Regardez [la conférence](https://www.youtube.com/watch?v=5lq5zp6wYbQ), puis essayez de relire votre prochaine tâche d’agent sous forme de plan, avant que le moindre code existe. Dites-moi si votre lead time bouge.