[🛠] AI Orchestration #5: J’ai repensé la séparation coordinateur–workers que j’avais abandonnée

✨ Résumé de GPT-5.6 Sol

Le récit d’une division du travail abandonnée quand les messages ont fait perdre son contexte au coordinateur, puis repensée autour de rapports sur fichiers et de commits réservés au coordinateur après le goulot d’étranglement d’une session unique.

J’avais renoncé à séparer le coordinateur et les workers

Le mois dernier, j’ai réellement relié un coordinateur à plusieurs workers. Un objectif était divisé en plusieurs tâches, puis le coordinateur examinait et intégrait ce que les workers avaient implémenté.

La division du travail elle-même était rapide. Les fonctions indépendantes pouvaient être développées simultanément, tandis que le coordinateur ne s’occupait que de la direction générale du produit et de l’intégration. Le problème venait de la manière dont les workers transmettaient leurs résultats.

Chaque fois qu’ils terminaient ou se retrouvaient bloqués, ils envoyaient un rapport dans la session du coordinateur. Cela me paraissait naturel au début. Mais plus leur nombre augmentait, plus les rapports s’accumulaient dans la conversation, et chaque nouveau message interrompait le travail en cours pour attirer l’attention vers une autre tâche.

Je lisais le résultat de test d’un worker, passais au conflit de Git index d’un autre et recevais un troisième rapport juste au moment de revenir à l’implémentation initiale. La conversation s’allongeait rapidement. À mesure que les compactages se répétaient, il fallait davantage de temps pour reconstruire l’objectif, les interdictions de déploiement et l’état actuel du stage. Le coordinateur ressemblait finalement moins à un intégrateur qu’à un guichet chargé de traiter les messages des workers.

J’ai fini par abandonner la séparation elle-même. J’ai même supprimé impulsivement la Skill de coordination que j’avais créée. Je pensais qu’en faisant tout dans une seule session principale, le contexte ne serait au moins plus tiré dans plusieurs directions.

Revenir à une seule session a montré pourquoi la division était nécessaire

Pourtant, en poursuivant un grand travail produit dans une session unique, le goulot d’étranglement opposé est apparu immédiatement.

Implémentation, tests, cohérence documentaire, vérification sur appareils physiques et préparation du Runtime devaient être traités successivement par la même session. Si une question de priorité ou une transmission provenant d’une autre session arrivait en chemin, il fallait d’abord reconstruire l’état du travail en cours. Finir soigneusement une tâche allongeait l’ensemble ; traiter l’urgence d’abord exigeait de décider jusqu’où clore le travail existant.

Le problème n’était pas la division du travail. Garder même des tâches indépendantes dans une seule session était inefficace. Séparer coordinateur et workers restait la solution la plus efficace, mais rétablir la structure où les workers entraient directement dans la conversation actuelle du coordinateur ne ferait que répéter l’échec.

Cette fois, au lieu d’abandonner la division, j’ai décidé de supprimer la voie de transmission qui interrompait le contexte du coordinateur.

Une notification d’une ligne ouvrait la même porte

J’ai d’abord pensé qu’un worker pouvait envoyer une ligne courte plutôt qu’un long rapport.

READY task-042: chemin du rapport

Mais la longueur n’était pas le problème. Dès qu’un message entrait dans la conversation du coordinateur, Codex pouvait facilement le traiter comme un contexte plus récent que le travail en cours. Même une seule ligne conservait la même porte d’entrée vers un changement de tâche.

Les workers n’envoient donc plus de message au coordinateur. Les états de fin, de blocage et d’échec sont écrits uniquement dans des fichiers de rapport. Le coordinateur ne consulte l’inbox qu’après avoir amené son propre travail jusqu’à un checkpoint ou un commit sûr.

L’arrivée d’un rapport n’est pas un événement qui interrompt le travail actuel. Elle ajoute simplement un fichier à la prochaine file d’examen.

Les Worktrees étaient propres, mais s’éloignaient de l’état le plus récent

J’ai ensuite envisagé un Worktree et une Branch distincts pour chaque worker. Le Git index et les changements non commités ne se mélangeaient pas ; en apparence, c’était la solution la plus propre.

Mais un problème plus important surgissait dans les vrais projets. Plusieurs fonctions modifiaient continuellement la même API, le même schema et le même écran. Les améliorations terminées dans une session n’étaient pas immédiatement visibles dans les autres Worktrees. Chacun travaillait proprement, mais l’intégration révélait une pile de modifications construites sur d’anciennes structures. Le volume de retouches devenait alors franchement pénible.

J’ai donc choisi la structure opposée.

Un seul main Working Tree
├─ Plusieurs workers voient ensemble les changements les plus récents
├─ Les workers ne modifient que les fichiers et hunks attribués
├─ Les workers ne font ni stage ni commit
└─ Seul le coordinateur examine, stage et commit

Un Working Tree partagé s’emmêle aussi immédiatement sans limites. Par défaut, un fichier n’a qu’un writer ; les modifications parallèles du même fichier ne sont permises que si les hunks sont clairement séparés. Les schemas communs, le nettoyage des imports, les formatters et les changements qui déplacent le code environnant sont sérialisés.

Les tests exécutés par un worker ne constituent pas non plus une preuve finale. Ils peuvent avoir été lancés en présence des changements non commités d’un autre worker. Chaque worker vérifie son périmètre ; le coordinateur gèle l’ensemble des changements puis exécute une fois la régression complète et le build.

Les rapports sont devenus des contrats de revue

J’ai reconstruit la Skill de coordination supprimée selon ces principes. La nouvelle Skill custom-coordinate-parallel-workers contient ce flux.

Le coordinateur attribue un task id, le résultat attendu par l’utilisateur et les chemins accessibles en écriture. Le worker termine l’implémentation, la vérification ciblée et le nettoyage des processus temporaires, puis crée atomiquement un rapport et s’arrête. Ce rapport liste les fichiers réellement modifiés, les résultats des contrôles, les chevauchements, le périmètre inachevé et un commit proposé.

Le coordinateur ne relit pas toutes les conversations. Il consulte d’abord dans l’inbox le task id, l’état, le titre et le résumé des contrôles, puis choisit une tâche à intégrer. Il confirme que le rapport correspond au diff réel avant de stage et commit uniquement les hunks exacts.

Lorsqu’un candidat de release est choisi, un freeze bloque les nouvelles mutations des workers. Au lieu de répéter les tests complets tandis que les changements continuent d’arriver, la documentation du current state, la régression complète, le build et la vérification du déploiement commencent lorsque l’ensemble de release ne bouge plus.

Le rapport n’est plus un simple journal de travail. Il est devenu le contrat de revue qui permet au coordinateur de faire confiance au changement et de le faire passer à l’état suivant.

Il faut maintenant le faire fonctionner sur un vrai travail

J’ai testé les outils de gestion d’état de la Skill dans un environnement temporaire isolé. La fin normale, les conflits de chemins accessibles en écriture, la reprise après une demande de modification, le refus d’un freeze pendant l’exécution et le report au batch suivant ont tous fonctionné.

Je n’ai toutefois pas encore exploité plusieurs vraies sessions Codex de cette manière. La prochaine tâche parallèle devra montrer si les rapports uniquement sur fichiers perturbent moins le contexte du coordinateur et si la propriété des chemins dans le Working Tree partagé est respectée comme prévu.

La conclusion ressemble à mon point de départ, mais la raison est désormais plus claire. Il faut séparer le coordinateur des workers. Ce n’est pas la division du travail qui a échoué, mais l’envoi en temps réel de chaque rapport dans la conversation actuelle du coordinateur.

Le changement attendu n’est pas simplement de lancer davantage de workers. Il consiste à laisser le coordinateur préserver son contexte jusqu’à la fin de son propre travail. La vitesse du travail parallèle dépendait moins du nombre de workers que du nombre de fois où la personne chargée d’intégrer leurs résultats était détournée.