Chapitre 7 — Patrons collaboratifs et dynamiques avancés

Septième billet de la tournée chapitre par chapitre de LLM Primer IV : Concevoir la cognition de l'IA avec MCP. Quand la topologie ne peut pas être dessinée au temps de conception — quand la bonne étape suivante dépend de ce que l'étape précédente a trouvé — les patrons du Chapitre 6 cessent de suffire.

Pourquoi ce chapitre existe

Les patrons du Chapitre 6 partagent une caractéristique architecturale qui devient une responsabilité pour les tâches plus dures : la topologie est fixée au temps de conception. L'ingénieur dessine le pipeline, nomme les étapes, décide qui nourrit qui, et l'exécution ne reconsidère jamais. Pour les tâches dont la forme est connue d'avance, c'est une force. Pour les tâches dont la forme est véritablement émergente — quand le bon spécialiste dépend de ce que l'utilisateur a vraiment demandé, quand le plan lui-même doit être bâti à mesure que le travail avance — la topologie fixe devient une cage.

Ce chapitre parcourt les patrons dynamiques : tables rondes où les agents itèrent vers un consensus, routeurs qui délèguent à des spécialistes choisis à l'exécution, et orchestration magentique qui bâtit les plans à mesure que la tâche se déploie. Chacun achète une capacité que les patrons plus simples ne peuvent offrir. Chacun introduit des modes de défaillance — non-terminaison, mauvais routage, planification emballée — que les patrons plus simples évitent.

7.1 Groupe et table ronde : maker-checker, consensus multi-participants

L'orchestration en groupe place plusieurs agents dans un contexte conversationnel partagé et les laisse parler à tour de rôle. La forme la plus simple est la boucle maker-checker à deux agents : le maker produit un candidat, le checker l'évalue contre une grille, le maker révise sur le retour, et la boucle se termine sur approbation ou sur un budget de tours. Les modèles de langage sont mesurablement meilleurs à l'évaluation qu'à la production quand les deux sont bien cadrés — un modèle à qui on demande d'écrire et de s'auto-évaluer dans le même appel tend à défendre sa première tentative ; le même modèle à qui on tend la même sortie dans un contexte frais avec une grille claire est nettement plus critique.

Les modes de défaillance honnêtes sont au nombre de trois. Collusion — quand maker et checker partagent un modèle et un prompt, le checker approuve tout. La défense, c'est une vraie différenciation de rôle, idéalement des modèles différents. Non-terminaison — un checker strict rejette chaque candidat ; l'orchestrateur doit accepter le meilleur vu ou escalader. Dérive du checker — dans une table ronde partagée, le checker se met à approuver des choses qu'il aurait rejetées plus tôt parce que les justifications du maker s'accumulent. Une constatation de terrain de fin 2025 est contre-intuitive : les systèmes maker-checker les plus fiables empêchent le checker de voir comment le candidat a été produit. Les checkers sans état — à qui l'on ne tend que le candidat et la grille — augmentent les rejets corrects de 30 à 50 %. Le contexte partagé est un outil, pas un défaut.

Les tables rondes multi-participants étendent le patron à plusieurs spécialistes et un modérateur. Le coût grandit vite : la dépense de tokens grandit avec la transcription partagée, la latence grandit avec les tours, et l'on observe en production des agents qui s'enlisent dans des tangentes. Les disciplines qui font fonctionner cela — tokens bornés par tour, sorties de tour structurées, grilles de terminaison explicites — sont la différence entre une réunion productive et une réunion qui aurait dû être un e-mail.

7.2 Handoff et routage : délégation dynamique

L'orchestration par handoff prend une autre approche : un agent à la fois traite la conversation, et l'agent actif peut transmettre quand son travail est fini ou quand la requête glisse vers une autre spécialité. Le routeur — lui-même un LLM, en général — lit l'état de conversation et produit une décision de routage : « rester avec l'actuel » ou « transmettre au spécialiste X avec ce résumé de contexte ». Le résumé est le contrat entre la couche de routage et le spécialiste.

Le problème d'ingénierie le plus dur est de reconnaître quand un handoff est nécessaire. Le mauvais routage est l'échec le plus commun : le routeur envoie une question de facturation au support technique, le support fait de son mieux, et l'utilisateur obtient une réponse confuse qui n'aborde aucune de ses préoccupations. Les défenses s'empilent : un seuil de confiance en dessous duquel le routeur s'en remet à un humain, des actions explicites « ce n'est pas mon domaine » que les spécialistes peuvent prendre, et la journalisation de chaque décision de routage pour revue.

Deux autres modes de défaillance façonnent la conception de production. Boucles de handoff — le spécialiste A envoie à B, B renvoie à A — défendues en détectant des handoffs répétés et en forçant une résolution différente. Perte de contexte — chaque résumé de handoff est avec pertes, et le spécialiste suivant peut redemander une information que l'utilisateur a déjà fournie — défendue en stockant la conversation complète en dehors du contexte de tout spécialiste, le résumé étant la charge utile principale et l'historique complet disponible sur demande. À mesure que le nombre de spécialistes croît, les routeurs plats deviennent fragiles ; le patron qui a émergé en 2025 est le routage hiérarchique — un routeur grossier choisit une catégorie, un routeur spécifique à la catégorie choisit le spécialiste. Deux niveaux, c'est le sweet spot en production.

7.3 Orchestration magentique : des plans bâtis en marchant

Pour les tâches dont la décomposition n'est pas connue au départ — enquêter sur la lenteur d'une base de données, déboguer un système inconnu, faire de la recherche sur un sujet complexe — aucun des patrons précédents ne suffit. L'orchestration magentique, nommée d'après le framework Magentic-One de Microsoft, est la famille de patrons où un agent manager tient un registre de tâches et le met à jour à mesure que le travail avance. Le registre a des emplacements explicites : le but initial, la compréhension actuelle (qui peut s'affiner), les sous-tâches ouvertes avec priorités, les sous-tâches terminées avec résultats, les découvertes qui peuvent exiger une révision du plan, et une condition d'arrêt. Le manager lit le registre à chaque étape, décide du prochain envoi, et réintègre les résultats.

La force, c'est une véritable ouverture. « Enquêter sur pourquoi la base est lente » ne peut pas être décomposée d'avance — la sous-tâche suivante dépend de savoir si le goulot est le réseau, le plan de requête, ou une ligne chaude. Aucun pipeline fixe ne pourrait gérer cela ; aucune topologie de handoff statique ne pourrait router correctement sans savoir d'avance quelles spécialités seraient pertinentes.

Le coût est le plus sévère de ce chapitre sur toutes les dimensions : latence, tokens, effort d'ingénierie, risque opérationnel. La dépense de tokens grandit superlinéairement parce que le registre est lu à chaque tour. Les modes de défaillance catalogués sont nets. Planification emballée — le manager ouvre les sous-tâches plus vite qu'il ne les ferme, le registre grandit sans borne. Dérive de but — en apprenant, le manager reformule le but loin de l'intention de l'utilisateur. Churn de plan — chaque nouvelle découverte déclenche une révision de plan, aucun engagement n'est tenu assez longtemps pour faire des progrès. Le patron qui a émergé est la boucle magentique bornée : budgets sur les sous-tâches ouvertes, le total d'invocations de workers et le temps horloge, avec escalade quand n'importe quelle borne est atteinte. Les systèmes magentiques de production sans bornes brûlent occasionnellement des centaines de dollars en tokens sur des tâches que le manager n'aurait pas pu résoudre dans un budget raisonnable.

7.4 Choisir parmi les patrons

Trois questions sélectionnent parmi eux. La topologie est-elle connue d'avance ? Si oui, restez avec les patrons statiques du Chapitre 6. Le travail bénéficie-t-il d'une itération contre une vérification externe ? Si oui, une boucle maker-checker est le bon ajout — encastrable à l'intérieur de tout autre patron. Quelle est l'ouverture de la planification ? S'il y a des bornes claires, le handoff ou le séquentiel suffit ; si c'est véritablement émergent, le magentique est le patron nécessaire, accepté avec ses coûts.

Un cas de 2025 d'une société de services financiers est le récit édifiant : un workflow d'onboarding client magentique, choisi parce que l'équipe était enthousiasmée par la flexibilité du framework, a été remplacé par un pipeline séquentiel fixe. Le coût par onboarding est tombé d'environ sept dollars à quatre-vingts cents ; les taux de complétion se sont améliorés. Le patron de tendre la main vers l'outil le plus général quand un plus spécifique ferait l'affaire n'est pas nouveau en génie logiciel, et il se manifeste fortement dans l'orchestration multi-agents parce que la généralité se paie en tokens.

Ce que prépare le Chapitre 7

Les Chapitres 6 et 7 spécifient comment les agents se coordonnent. Ils ne spécifient pas où les agents tournent, comment le modèle de langage est colocalisé avec les outils, ni à quoi ressemble la topologie de déploiement au niveau des processus, des machines et des frontières réseau. Deux systèmes aux patrons d'orchestration identiques peuvent être déployés de façons dramatiquement différentes — profils de latence différents, structures de coûts différentes, postures de sécurité différentes. Le Chapitre 8 couvre cette dimension.

Prochaine étape — Chapitre 8 : Topologies de déploiement. Trois manières largement différentes dont MCP peut être physiquement déployé — modèle-avec-serveur, modèle-dans-le-client, hybride — avec les arbitrages réels en latence, coût, complexité opérationnelle, et les genres d'échecs que chacune rend probables.