La parallélisation fonctionne quand vous savez découper la tâche à l’avance. Mais parfois le découpage lui-même dépend de l’entrée — quels fichiers toucher, quelles sources consulter. Voici le pattern orchestrateur-ouvriers : un LLM chef analyse la tâche, décide des sous-tâches, et délègue chacune à un appel ouvrier.

L’analogie

Le chef de chantier. Sur une rénovation, il inspecte, puis décide : « le plombier dans la salle de bain, l’électricien dans la cuisine, le peintre à l’étage. » Chaque artisan travaille avec sa propre caisse à outils, puis fait son rapport. Le chef ne tient jamais un pinceau — son travail, c’est la décomposition, la répartition et l’inspection finale.

Le principe

flowchart TB
    O["LLM : orchestrateur — planifie & délègue"] --> W1[ouvrier 1] & W2[ouvrier 2] & W3[ouvrier 3] --> M["orchestrateur : fusion & contrôle"]

• L’orchestrateur voit la vue d’ensemble ; il rédige des consignes précises pour les ouvriers.
• Chaque ouvrier tourne dans un contexte neuf avec sa seule consigne — pas de pollution des autres, toute la fenêtre de contexte pour sa sous-tâche.
• Contrairement à la parallélisation fixe, les sous-tâches sont décidées à l’exécution, selon l’entrée.

Un exemple concret

« Renomme ce concept dans toute notre base de code » :

orchestrateur → analyse la structure du dépôt
              → « ouvrier 1 : mets à jour /api (7 fichiers) »
              → « ouvrier 2 : mets à jour /web (12 fichiers) »
              → « ouvrier 3 : mets à jour docs + changelog »
ouvriers      → chacun modifie sa zone, remet un résumé
orchestrateur → relit les rapports, vérifie la cohérence, terminé

La base de code entière noierait un seul contexte ; chaque ouvrier ne voit jamais que sa tranche.

Quand l’utiliser

• La décomposition ne peut pas être codée en dur — elle dépend de chaque entrée.
• La tâche est trop grosse pour un seul contexte et se découpe en morceaux autonomes.
• Les sous-tâches demandent des outils ou des focales différentes (chercher vs rédiger vs vérifier).

Quand l’éviter

• La tâche tient confortablement dans un appel — l’orchestrateur n’est alors que du surcoût.
• Les sous-tâches sont étroitement imbriquées : les ouvriers ne peuvent pas partager leurs découvertes en vol ; le montage ne marche que si les consignes sont vraiment séparables.

Le piège classique

Les consignes floues. Un ouvrier ne sait que ce que l’orchestrateur écrit dans sa consigne — « corrige la partie API » produit du chaos, « renomme X en Y dans ces 7 fichiers, ne touche pas aux tests » produit des résultats. Le vrai talent du chef de chantier, c’est rédiger de bons ordres de mission.