Un chef de quai local pour mille lots : écrire le prompt avant le code

TL;DR

L'objectif : un orchestrateur local, servi par LM Studio, qui voit tous les dépôts. Il lance les agents codeurs via leurs interfaces en ligne de commande — Claude Code, Codex, Kimi, et plus tard Cursor et OpenCode. Et il affiche en continu ce qui tourne, depuis combien de temps, avec quelle complexité, quelle priorité et ce que ça touche. L'interface de contrôle : le module d'administration de la messagerie maison.

La demande explicite était : pas de code. Le livrable est donc un prompt système, une spécification exécutable par un modèle. Cinq choix le structurent :

1. Le chef de quai ne code jamais. Il mesure, découpe, lance, vérifie, rend compte.
2. Mille projets, c'est mille lots en file, pas mille processus. Le débit est borné par des slots, eux-mêmes bornés par la machine.
3. Quatre portes décident qui agit. Les gestes de production et de secrets restent humains, sans exception.
4. Un verdict vient d'un runner, jamais de la parole d'un agent — ni de celle du chef de quai.
5. Un seul format de vérité, la fiche de lot en JSON, que le tableau de bord lit et que FG pilote.

1. Pourquoi un modèle local comme chef d'orchestre

L'orchestration d'un parc d'agents est surtout du travail de bureau :

• lire des états ;
• comparer des horodatages ;
• classer par priorité ;
• vérifier qu'un slot est libre ;
• écrire une fiche ;
• relancer une commande de test.

Rien de tout cela ne demande le meilleur modèle du marché. Cela demande en revanche d'être toujours disponible, gratuit à l'usage et sur la machine où sont les dépôts.

Un modèle servi localement coche ces trois cases. Deux modèles sont présents dans LM Studio au moment de la mesure : un modèle de 27 milliards de paramètres compressé (4,7 Go) pour l'orchestrateur, et un modèle de 12 milliards en repli rapide. Les agents coûteux sont réservés à ce qui le mérite : écrire et vérifier du code, juger, trancher l'architecture.

C'est la même répartition que celle observée lors de la méta-analyse précédente :

• le léger pour le mécanique, à condition qu'un plus fort vérifie derrière ;
• le fort pour le jugement ;
• l'humain pour l'irréversible.

2. Mesurer ce qui existe avant de prescrire

Avant d'écrire une ligne du prompt, une vérification : quelles interfaces en ligne de commande sont réellement installées ?

Deux des cinq agents cités dans la demande ne sont donc pas lançables aujourd'hui. Le prompt ne fait pas semblant : il les déclare indisponibles.

Seconde règle, plus subtile : ne jamais inventer un drapeau de ligne de commande. Chaque outil a son mode non interactif, ses options de sortie JSON, ses noms d'arguments, et ils changent d'une version à l'autre. Le prompt oblige l'orchestrateur à lancer --help avant le premier usage de chaque agent et à noter dans un registre le mode exact constaté. Un petit modèle qui devine un drapeau, c'est un lot qui échoue pour une raison absurde — ou pire, qui réussit en faisant autre chose.

3. Mille projets : la file, pas la foule

La demande parle de « mille projets simultanés ». Sur un poste de travail, c'est physiquement impossible : chaque agent codeur consomme mémoire, disque, quota d'API, et surtout un dossier de travail exclusif. Le jour de la mesure, le disque système avait 6,7 Go libres.

Le prompt traduit donc l'ambition en une architecture qui tient :

• mille lots en file, chacun décrit, estimé, priorisé ;
• un nombre de slots plafonné par agent (trois par défaut pour chaque agent distant, deux pour le local) ;
• une porte de capacité : pas de nouveau slot sous 15 Go libres ou 4 Go de mémoire. Sous le seuil, l'orchestrateur descend à un seul slot et le signale ;
• un seul lot par dépôt à la fois. C'est la règle « un agent, un worktree » étendue au niveau du dépôt.

Le choix du prochain lot est déterministe :

1. la priorité P0 d'abord ;
2. puis le lot qui débloque le plus d'autres lots ;
3. puis le plus court.

Pas d'intuition, pas de préférence.

4. Les quatre portes

Le cœur du prompt est une table de quatre lignes. Elle décide, pour chaque lot, qui a le droit d'agir :

Deux détails comptent :

• Il n'existe pas de commande « valider R3 » dans le tableau de bord. Un bouton qui déclenche un push ou une rotation de secret serait exactement la surface d'attaque qu'on veut éviter. FG exécute lui-même, puis signale « fait par FG » avec la preuve.
• Une fiche de lot qui déclare toucher la production ou un secret passe automatiquement en R3, quel que soit le niveau annoncé par ailleurs.

5. La fiche de lot, seul format de vérité

Chaque lot est un objet JSON. C'est le seul format que l'orchestrateur écrit et le seul que le tableau de bord lit. Il porte précisément ce que la demande voulait voir :

Une règle sur la complexité : un lot XL ne se lance pas, il se découpe. C'est la leçon la plus constante des semaines précédentes : un agent à qui l'on confie trop large revient avec beaucoup de prose et peu de code.

Le cycle de vie est court et explicite :

file → pret → en_cours → verification → fait
                                      ↘ echec
              (à tout moment) → pause | bloque_fg | annule

6. La boucle

Toutes les soixante secondes environ, le chef de quai fait huit gestes.

1. Mesurer :
   • le manifeste ;
   • l'état vivant du workspace ;
   • git par worktree (avec numstat, jamais le statut seul) ;
   • la vue live ;
   • les serveurs MCP.
2. Réconcilier :
   • un lot « en cours » dont le processus est mort passe en échec, avec sa dernière sortie ;
   • un worktree modifié sans lot connu signale un agent inconnu. Rien ne se lance alors sur ce dépôt.
3. Vérifier la capacité.
4. Choisir le prochain lot prêt.
5. Lancer : créer le worktree selon le gabarit, envoyer le prompt de lot, journaliser.
6. Vérifier : relancer soi-même la commande de test. Code 0, le lot est fait. Sinon, il est en échec.
7. Publier l'état.
8. Tout arrêter :
   • sur ordre de FG ;
   • sur fuite de secret détectée ;
   • si deux agents touchent le même dépôt.

La réconciliation du point 2 vient directement de l'audit du même matin : un autre agent committait pendant la mesure. Un orchestrateur qui ne voit pas les agents qu'il n'a pas lancés finira par en lancer un second au même endroit.

7. Le tableau de bord : la messagerie comme poste de commande

La messagerie maison a déjà un module d'administration, côté interface et côté serveur. Le prompt ne lui demande rien de neuf côté protocole. L'orchestrateur écrit trois fichiers :

• un état complet, réécrit atomiquement à chaque tick : slots, capacité, lots, alertes, actions en attente ;
• un journal d'événements en ajout seul : une ligne par transition de lot ;
• une file de commandes que le tableau de bord remplit et que l'orchestrateur lit.

Les commandes disponibles :

• pause, reprise, arrêt (le worktree est conservé) ;
• changement de priorité ;
• validation d'une décision R2 ;
• rejet ;
• ajout de lot ;
• réglage d'un plafond ;
• arrêt global.

À l'écran, l'intention est celle d'un jeu de gestion :

• une carte par lot, colorée par état ;
• une colonne « Action FG » qui rassemble tout ce qui attend un humain ;
• une jauge de capacité ;
• un fil d'événements.

Les notifications vers le téléphone sont rationnées : uniquement quand un lot est bloqué sur FG, quand un P0 échoue, quand un secret fuit, ou sur arrêt global.

La télémétrie est fail-open : si l'écriture de l'état échoue, le travail continue. L'action est fail-closed : si un contrôle de sécurité échoue, rien ne part.

8. Les garde-fous qui viennent de constats réels

Aucune règle du prompt n'est théorique. Chacune répond à un incident mesuré :

9. Ce qui manque pour que le prompt tourne

Écrire la spécification avant le code a l'avantage de rendre visibles les trous :

• Un modèle dans LM Studio n'exécute rien tout seul. Il lui faut des outils branchés en MCP : shell restreint, lecture de fichiers, accès aux serveurs du parc (feed, passerelle, documentation, et le serveur GitHub distant ajouté le jour même, en lecture).
• Le module du tableau de bord qui lit l'état et écrit les commandes reste à construire dans la messagerie.
• Deux agents sur cinq demandent une installation (mode sans interface de Cursor, OpenCode).
• Le disque système doit être libéré pour sortir du mode « un seul slot ».
• Le bus d'événements du parc est figé depuis juin. Les transitions de lots iront d'abord dans des fichiers locaux, et sur le bus quand il reviendra.

Prochaine étape

• Brancher les outils MCP nécessaires dans LM Studio (shell restreint en lecture d'abord).
• Premier démarrage en mode R0 seul : l'orchestrateur transforme le plan d'état des lieux en fiches de lot et les soumet à FG, sans rien lancer d'autre.
• Spécifier le module « quai » du tableau de bord de la messagerie à partir de la fiche de lot.