[🛠] J’ai vraiment relié un coordinateur et plusieurs workers

✨ Résumé de GPT-5.6 Sol

Le récit d’un objectif découpé en plusieurs Work Items, confiés à différents workers, puis vérifiés et intégrés par un coordinateur.

Des workers répétitifs aux workers fondés sur des Work Items

Dans un précédent projet de collecte de données, j’avais déjà séparé les workers du coordinateur. À l’époque, les workers répétaient le même batch selon un goal fixe, tandis que le coordinateur organisait périodiquement les résultats accumulés.

Cette fois, le fonctionnement était différent. J’ai donné au coordinateur un objectif en langage naturel. Il a défini les conditions de fin et les Work Items, puis réparti les fichiers et le périmètre entre les workers.

Chaque worker -W- a terminé et vérifié sa tâche avant de transmettre un commit. Le coordinateur -C- a examiné ces résultats, les a intégrés un par un, puis a de nouveau vérifié l’état complet.

Le coût d’intégration a augmenté avec le nombre de workers

Le flux lui-même était simple.

Transmettre l'objectif
→ Le découper en Work Items
→ Exécuter et vérifier dans chaque worker
→ Transmettre les commits
→ Le coordinateur examine et intègre
→ Vérifier de nouveau l'état complet

Le principal avantage était la clarté de la responsabilité. Si une tâche échouait, les autres ne vacillaient pas avec elle, et je pouvais examiner chaque résultat sous forme de commit.

Le problème est lui aussi apparu immédiatement. En lançant trop de workers, tous les rapports sont arrivés d’un coup. Les sessions en double ont encore compliqué la gestion. Davantage de parallélisme n’était pas automatiquement préférable. Il fallait limiter le découpage à ce que le coordinateur pouvait réellement absorber.

Ce jour-là, j’ai aussi remis à niveau les baselines d’Orchestrator et d’Acceptance, les Workflows et Skills communs, ainsi que les règles d’exploitation des sessions de workers et de coordinateur.

Ce que je veux automatiser dans OpenClaw

Je ne cherche pas à reproduire exactement dans le produit les sessions, Worktrees et Branches utilisées aujourd’hui. Je veux automatiser les décisions qui se trouvent derrière.

• jusqu’où découper un objectif
• qui possède chaque résultat
• ce qu’il faut vérifier avant de considérer une tâche comme terminée
• où reprendre après un échec

Dans OpenClaw, l’enjeu n’était pas le nombre de workers, mais un coordinateur capable de gérer la propriété des résultats, leur vérification et les points de reprise.