La méthode par lots : un objectif mesurable par session d’agent

Pourquoi un agent dérive

Un agent de code reçoit une demande, la comprend en partie, puis remplit les blancs avec ses propres hypothèses. Sur une petite tâche, ce n’est pas grave. Sur un besoin réel, les hypothèses s’empilent : l’agent livre quelque chose qui compile, passe ses propres tests, et ne correspond pas à ce que vous vouliez.

Le second problème est la mémoire. Une session longue s’alourdit et l’agent oublie les décisions du début ; une session neuve repart de zéro et vous réexpliquez tout. La méthode par lots répond aux deux : un cadrage avant de coder, et un document qui garde le fil d’une session à l’autre.

Cadrer avant de coder

Tout commence par un entretien court. Le skill de cadrage, grill-me, pose ses questions par séries : ce qu’il faut livrer, pour qui, ce qui est hors sujet, comment on saura que c’est fini. Il s’arrête dès que les décisions importantes sont prises, puis résume ; vous confirmez ou corrigez.

Le résultat est écrit, pas gardé en mémoire : l’intention du besoin va dans sa feuille de route, et chaque étape devient un lot avec sa propre fiche. Rien de ce qui a été décidé ne dépend du souvenir d’une session.

Un lot : une branche, une session, un objectif

Un lot est la plus petite livraison utile : une branche, une session d’agent, un objectif. Sa fiche contient l’objectif en une ligne, le périmètre et ce qui en est exclu, les critères de fin mesurables, les étapes, les risques, puis un journal tenu pendant le travail.

Un critère de fin se vérifie par une commande ou une observation : « la suite de tests sort sans erreur et la page affiche un seul titre principal », pas « la page est bien faite ». C’est ce qui permet à l’agent de savoir qu’il a fini, et à vous de le vérifier sans relire tout le code.

Au lancement, lab launch reconstruit l’objectif depuis la fiche et le transmet à l’agent : rien à recopier, rien à taper, et aucune troncature en route.

Bien découper un besoin

Un bon lot se livre seul : une fois fusionné, il laisse le projet dans un état cohérent, même si les lots suivants n’arrivent jamais. Il tient dans une session d’agent sans que son contexte déborde, et ses critères de fin se vérifient en quelques commandes.

Les premiers lots posent ce dont les autres dépendent ; le dernier rend le résultat essayable. Quand un lot révèle une surprise, l’ordre des suivants change dans la feuille de route, pas dans la tête de l’agent : la prochaine session lit la version à jour.

Un lot trop gros se reconnaît vite : un objectif qui tient en plusieurs phrases, des critères qui commencent par « et aussi », un journal qui s’allonge sans preuve. Mieux vaut le couper en deux que laisser l’agent improviser la fin.

Exécuter : tester, journaliser, prouver

Pendant le lot, l’agent avance par petites étapes, chacune avec son test. Pour chaque correction de bug, il écrit d’abord le test et le regarde échouer : un test jamais vu rouge ne prouve rien.

Il tient un journal court dans la fiche : ce qui est prouvé, avec la commande et son résultat, ce qui reste, ce qu’il a décidé de ne pas faire et pourquoi. Les mesures et les captures vont dans un rapport de preuve rangé avec le lot, que la fiche cite au lieu de le recopier.

$lab status project-2SLUG=feature-4BRANCH=feat/admin-overridesBATCH=lot-03-admin-overridesBATCH_STATE=in progressLANE_PHASE=workLAST_BATCH=yes$lab next project-2 feature-4lab: Last planned batch — a check together will follow.$lab plan project-1lab: 3 lanesLane              Presence   Done/total   Current batchfeature-1         alive      1/2          lot-02-search-results-page · Search…feature-2         alive      0/1          lot-01-feature-2 · Export orders as…feature-3         alive      1/1          —

Reprendre sans réexpliquer

Quand le contexte s’alourdit, l’agent n’attend pas de saturer. Il écrit la Reprise : où il en est, ce qui reste, la prochaine action. lab next ouvre alors une session neuve dans le même onglet, qui repart de la fiche et non de zéro.

La même commande sert entre deux lots : elle lit où en est le besoin et lance ce qu’il faut, exécuter ou reprendre le lot, ouvrir le suivant après une livraison, ou préparer votre essai final. Elle ne fusionne ni ne supprime rien.

Clôturer : revue indépendante et vérification réelle

Un lot ne se clôt qu’après les contrôles de votre dépôt : tests, style et types au vert. Puis un agent qui n’a pas écrit le code relit le diff contre la fiche, en revue indépendante, et ne remonte que les écarts de correction ou de périmètre.

Enfin, chaque critère de fin est prouvé par une exécution réelle, et les écrans listés sont vérifiés dans un vrai navigateur. Ce n’est qu’ensuite que lab merge livre le lot, après avoir vérifié le bilan et les contrôles de la demande de fusion.

La méthode ne garantit pas un code sans défaut : elle rend visibles les preuves qui manquent, avant qu’elles ne manquent chez vous.

Claude Code et Codex : la même méthode

La méthode est livrée sous forme de skills et d’agents identiques pour les deux outils. Claude Code les appelle par une commande slash, Codex par leur nom précédé d’un dollar ; le contenu est le même. Chaque worktree garde l’agent choisi à sa création, et lab next le relance.

Codex demande une approbation unique des hooks par /hooks ; lab doctor vérifie qu’ils sont bien actifs. Treelab est un produit indépendant : Claude Code et Codex sont cités sans affiliation.

Pour voir chaque commande en action, lisez la page fonctionnalités. Pour isoler chaque besoin, le guide sur les worktrees ; pour garder la décision, celui sur la main gardée sur l’agent.