Pattern Worker / Orchestrator

De quoi on parle

Le pattern Worker / Orchestrator, c’est confier un gros chantier à un orchestrateur qui le découpe en sous-tâches, délègue chacune à un worker (un sous-agent), puis recompose leurs résultats. Là où le pipeline multi-étapes enchaîne des étapes en séquence, l’orchestration vise des sous-tâches qu’on peut traiter en parallèle.

L’orchestrateur ne fait pas le travail de détail : il coordonne. Il planifie le découpage, distribue (le fan-out), surveille, puis intègre (le fan-in). Chaque worker se concentre sur une seule sous-tâche dans son propre contexte.

Point clé : Même instinct qu’un service applicatif qui orchestre des opérations : il coordonne le flux, mais la logique de détail vit dans les composants qu’il appelle. L’orchestrateur reste mince.

Le worker démarre à vide

Un worker (sous-agent) ne voit pas la conversation de l’orchestrateur, ni celle de ses workers frères. Il démarre avec un contexte neuf et ne dispose que de ce que son brief contient. C’est une force — un contexte propre, focalisé — mais ça impose une discipline : le brief doit être explicite et auto-suffisant.

Point clé : Comme un port hexagonal : tu décris ce que le worker doit produire (le contrat), pas comment il s’y prend. Le worker est une boîte que l’on pilote par son interface.

Attention — brief implicite. « Continue le travail » ne veut rien dire pour un worker qui démarre à vide. Il faut pointer les fichiers concernés, rappeler les contraintes, et dire précisément quelle sortie est attendue. Un worker mal briefé invente, et son invention contamine l’intégration.

Paralléliser n’est gratuit que si les tâches sont indépendantes

Le gain de l’orchestration parallèle suppose des sous-tâches indépendantes : la sortie d’un worker ne doit pas être l’entrée d’un autre. Sinon, ce n’est pas du parallèle, c’est du séquentiel déguisé — et il faut revenir à un pipeline ordonné.

Autre piège : l’état partagé. Deux workers qui modifient le même fichier en parallèle se télescopent — conflit de merge ou écrasement silencieux. La parade : partitionner le travail pour que chaque worker ait sa zone d’écriture à lui.

Point clé : Pense frontières d’agrégat en DDD : on découpe pour que deux unités de travail concurrentes ne touchent pas le même état. Un worker = une partition claire.

PITER : distribuer les rôles

Une grille utile pour organiser plusieurs agents est le modèle PITER. Chaque rôle peut être un agent séparé, ou le même agent appelé avec un prompt différent.

Concrètement, dans un outil comme Claude Code, le plan mode joue le rôle P, et le Task tool permet de lancer des sous-agents pour les rôles I, T, E, R.

Le fan-in : là où tout se joue

Distribuer le travail (fan-out) est facile. Le recomposer (fan-in) est l’étape difficile. Chaque worker peut avoir validé sa pièce isolément, et l’ensemble casser quand même : interfaces qui ne s’emboîtent pas, hypothèses incompatibles, logique dupliquée. Personne n’a validé les coutures.

Point clé : « Chaque partie est verte donc le tout est vert » est un sophisme de composition. La correction locale ne se compose pas toute seule : il faut un contrôle d’intégration de bout en bout — des tests aux frontières, pas seulement par sous-partie.

Attention — sur-orchestration. Multiplier les agents multiplie le coût en tokens et la coordination. Avant de monter une orchestration PITER, vérifie qu’un seul agent bien briefé ne suffit pas. Et si une boucle de revue (Evaluate → Implement) peut se déclencher, borne-la : critères finis, budget d’allers-retours, escalade humaine au-delà. Une boucle sans condition de sortie ne converge jamais.