En bref
Le pattern Wave structure une orchestration multi-agents en vagues séquentielles plutôt qu’en un seul envoi parallèle. La vague 1 produit une matière intermédiaire (données, sources, extraits) ; la vague 2 la transforme en livrables finaux. Entre les deux, une étape d’ajustement analyse les résultats de la vague 1 pour calibrer la vague 2 — en l’amputant, en la réorientant ou en l’enrichissant.
En clair : au lieu de lancer tous les agents d’un coup, on les lance en deux temps — ceux qui collectent d’abord, ceux qui rédigent ensuite — en vérifiant entre les deux que la matière suffit.
Imaginez les vagues qui arrivent sur une plage : chaque vague porte plus loin ce que la précédente a déposé sur le sable. Le pattern Wave orchestre les agents par vagues successives — chaque vague consolide ce que la précédente a produit, puis lance la suivante sur cette base plus solide. Entre deux vagues, un observateur regarde ce qui a été déposé et décide s’il faut relancer la même vague, passer à la suivante, ou abandonner certaines tâches faute de matière.
Pourquoi une seule vague ne suffit pas
Dans un batch d’agents homogènes — tous soumis à la même tâche, tous indépendants — un envoi parallèle unique (le pattern dit fire-and-consolidate) est suffisant. Chaque agent travaille en silo, les résultats sont aggrégés à la fin.
Mais certaines tâches ne sont pas homogènes. La rédaction d’un article nécessite des sources. L’analyse comparative nécessite des données collectées en amont. Si on soumet les agents rédacteurs avant d’avoir les sources, ils produisent du contenu sans matière — ou ils hallucinent cette matière.
Le problème fondamental est une dépendance séquentielle entre deux classes de tâches. Le pattern Wave le résout en les séparant explicitement dans le temps.
En clair : si un agent qui rédige dépend d’un agent qui collecte, il ne faut pas les lancer en même temps — sinon le premier invente ce que le second n’a pas encore trouvé.
La mécanique du pattern
Une orchestration Wave se déroule en trois étapes :
Vague 1 — exécution amont. Un premier batch d’agents est lancé en parallèle. Leur rôle est de produire de la matière : collecter des sources, extraire des données, résumer des documents. Ils ne produisent pas le livrable final.
Étape inter-vagues — analyse et ajustement. L’orchestrateur examine les outputs de la vague 1. Il évalue la couverture, la qualité, les lacunes. Sur cette base, il décide comment configurer la vague 2 : quels agents lancer, combien, avec quel contexte. Il peut aussi décider de sauter certaines tâches si la matière collectée est insuffisante pour les alimenter.
Vague 2 — exécution aval. Un second batch d’agents est lancé, cette fois nourris des outputs de la vague 1. Ils produisent les livrables finaux.
Le pattern peut s’étendre à trois ou quatre vagues si les dépendances sont plus profondes — par exemple : collecte → recherche complémentaire → synthèse → rédaction. Dans ce cas, chaque transition inter-vagues joue le même rôle d’ajustement. En pratique, deux vagues couvrent la majorité des cas ; au-delà de quatre, la latence cumulée devient souvent dissuasive [ordre de grandeur estimé].
En clair : la vague 1 ramasse le matériau, la vague 2 le transforme en livrable, et l’orchestrateur regarde entre les deux ce qui manque avant de relancer.
L’ajustement inter-vagues : la valeur réelle du pattern
La séquence collecte → rédaction existe déjà dans n’importe quel pipeline automatisé. Ce qui distingue le pattern Wave est l’ajustement conditionnel entre les vagues.
Sans ajustement, la vague 2 est simplement planifiée à l’avance, quels que soient les résultats de la vague 1. Si un agent de collecte a échoué ou renvoyé une matière pauvre, la tâche correspondante en vague 2 sera lancée quand même — et produira un livrable de mauvaise qualité ou un échec.
Avec ajustement, l’orchestrateur peut :
- Skiper une tâche si la matière de vague 1 est insuffisante pour la nourrir.
- Augmenter le contexte d’un agent de vague 2 si vague 1 a produit plus que prévu.
- Ajouter des agents de vague 2 si vague 1 a découvert des angles non anticipés.
- Corriger des paramètres (par exemple : un slug erroné, une catégorie mal assignée) avant que les agents de vague 2 ne les propagent.
En pratique, cette phase d’ajustement permet de corriger des erreurs de configuration avant qu’elles ne contaminent la production, et d’éviter de lancer des agents sur une matière trop pauvre pour produire un résultat exploitable. Sur une orchestration de ~20 agents en deux vagues, il n’est pas rare que 1 à 3 tâches de vague 2 soient abandonnées ou reconfigurées à cette étape [ordre de grandeur estimé].
En clair : la vraie plus-value du pattern, ce n’est pas d’enchaîner deux vagues — c’est de regarder entre les deux et de décider quoi faire du résultat.
Quand utiliser le pattern Wave
Le pattern Wave n’est pas universellement supérieur à un batch simple. Il introduit une latence (la vague 2 ne peut démarrer qu’après la fin de la vague 1) et une complexité de coordination (l’étape inter-vagues doit être implémentée explicitement).
Il est justifié quand au moins deux conditions sont réunies :
| Condition | Explication |
|---|---|
| Dépendance entre tâches | Les tâches de type B consomment les outputs des tâches de type A |
| Volume suffisant | Au moins 3-5 agents par vague ; en dessous, le batch simple est moins coûteux |
| Qualité matière variable | La vague 1 peut échouer partiellement → l’ajustement a de la valeur |
Si les tâches sont homogènes et indépendantes, le pattern fire-and-consolidate suffit. Le Wave s’impose dès que des classes de tâches hétérogènes doivent s’enchaîner.
En clair : pas la peine de découper en vagues si 5 agents peuvent faire la même chose en parallèle — le Wave n’a du sens que quand certains dépendent des autres.
Limites et points de vigilance
Latence cumulée. Chaque vague ajoute un temps d’attente incompressible. Une orchestration à quatre vagues est séquentiellement contrainte même si chaque vague est massivement parallèle. Si chaque vague dure typiquement 3 à 5 minutes, une orchestration à quatre vagues ne peut pas terminer en moins de ~15 minutes, même avec une parallélisation totale à l’intérieur de chaque vague [ordre de grandeur estimé].
Complexité de l’ajustement. L’étape inter-vagues est la plus délicate. Si l’orchestrateur se trompe dans son analyse (surestimer la qualité de la matière, sous-estimer les lacunes), la vague 2 est mal calibrée. Une logique d’ajustement trop simple peut rater des cas limites.
Dépendance aux outils. En pratique, certains agents de collecte peuvent rencontrer des blocages d’accès réseau qui n’étaient pas prévisibles à la conception. Une vague de collecte dégradée peut limiter la vague de production — même avec un bon ajustement inter-vagues [NON VÉRIFIÉ : cette sensibilité aux défaillances d’outils externes varie selon l’environnement d’exécution].
Propagation d’erreurs. Si la logique d’ajustement n’est pas assez stricte, une erreur de vague 1 peut être transmise telle quelle à vague 2. L’ajustement doit inclure des seuils de qualité minimaux sous lesquels une tâche est abandonnée plutôt que transmise dégradée.
En clair : chaque vague ajoute au moins le temps d’une vague — et si on ne met pas de seuil de qualité entre les deux, une erreur au début contamine tout ce qui suit.
Ce qu’il faut retenir
- Le pattern Wave sépare une orchestration en vagues séquentielles pour gérer les dépendances entre tâches hétérogènes.
- La valeur distincte du pattern est l’ajustement inter-vagues : l’orchestrateur recalibre la vague suivante selon les résultats de la précédente.
- L’ajustement permet de skiper, enrichir ou corriger avant que les erreurs ne se propagent.
- Le pattern introduit une latence cumulée : chaque transition inter-vagues est un point d’attente séquentiel.
- Il est justifié dès qu’il existe une dépendance réelle entre deux classes de tâches et que la qualité de la matière de vague 1 est variable.