Hier soir, on a mis un chef d’orchestre devant nos agents, avec cinq patterns en poche. Mais un chef d’orchestre suit une partition qui va de gauche à droite — et le réel, lui, ne va pas de gauche à droite. Si les tests échouent, reviens en arrière. Si le dossier est sensible, appelle un humain. Attends que ces deux-là aient fini avant de continuer. Une partition ne sait pas écrire ça.
Vous savez qui sait ? Le réseau ferroviaire : des gares, des rails, des aiguillages qui envoient le train à gauche ou à droite selon la charge, des boucles de retour, des passages obligés en gare de contrôle. Décrire l’orchestration comme un réseau de rails, c’est le graph-driven agent orchestration — l’approche vers laquelle tous les frameworks convergent. Montez à bord — c’est pas sorcier.
Ce que la partition ne sait pas écrire
Reprenez les patterns d’hier : le pipeline est une ligne droite, le fan-out un éventail. Tant que le trajet est connu d’avance, tout va bien. Mais dès que le flux réel s’invite, la ligne casse :
- la condition : « si la revue trouve un problème critique → retour au développeur ; sinon → déploiement » ;
- la boucle : « régénère tant que les tests échouent — mais pas plus de trois fois » ;
- la jonction : « la synthèse ne part que quand les trois relecteurs ont rendu leur copie » ;
- l’arrêt en gare : « avant de merger, un humain valide » — le checkpoint d’avant-hier, devenu un citoyen du flux.
Vous pouvez enfouir tout ça dans le prompt d’un agent-chef et espérer. Ou vous pouvez le poser sur des rails : c’est exactement le choix qu’on va outiller.
Le réseau, pièce par pièce
Un graphe d’orchestration, c’est la même grammaire que le graphe de connaissances d’hier — nœuds et arêtes — mais avec un sens tout différent :
- Un nœud = une gare, c’est-à-dire une étape. Et surprise : tout peut être une gare — un agent (probabiliste), une fonction classique (déterministe : parser, valider, compter), ou un humain (la gare de contrôle où le train attend le feu vert).
- Une arête = un rail, la transition d’une étape à l’autre. L’arête peut être inconditionnelle (toujours ce rail) ou porter un aiguillage : une condition, évaluée sur ce que le train transporte.
- L’état = le wagon de marchandises. Ce qui circule de gare en gare : le diff à relire, les verdicts accumulés, le compteur d’essais. Chaque gare lit le wagon, le complète, le renvoie sur les rails.
- La boucle = le rail de retour — autorisée, mais bornée (trois tours max), sinon vous venez de construire un manège.
- Le checkpoint = la photo du wagon en gare. L’état est persisté à chaque étape : si le réseau tombe à la gare 7, on reprend à la gare 7 — pas au dépôt.
Les cinq patterns d’hier, vus du ciel
Prenez de l’altitude, et regardez les patterns d’hier comme des formes de réseau : le pipeline est une ligne droite ; le fan-out, une étoile qui diverge puis converge en jonction ; l’orchestrateur-ouvriers, une étoile dont les branches se décident en route ; le handoff, un aiguillage dont la décision appartient à la gare ; le panel de juges, une étoile qui converge vers une gare de vote.
C’est le déclic de l’article : les cinq patterns ne sont pas cinq outils différents — ce sont cinq formes du même graphe. Voilà pourquoi les frameworks convergent : offrir le graphe, c’est offrir tous les patterns, plus tous ceux que vous dessinerez vous-même.
Pourquoi les rails changent tout
Le bénéfice profond tient en une phrase : le déterminisme reprend la structure, le probabiliste reste confiné dans les gares.
- La structure devient du code : versionnée, relue en PR, testable — et dessinable. Un graphe d’orchestration se donne en diagramme as code : la doc et l’exécution sont la même chose.
- L’observabilité est offerte : chaque arête franchie se journalise. Le débogage « à l’oreille » d’hier devient une lecture de trajet : le train est passé par ces gares, dans cet ordre, avec ce wagon.
- La reprise est native : grâce aux checkpoints, un incident ne coûte que l’étape en cours — précieux quand le trajet complet se compte en heures et en tokens.
- L’humain a une gare à son nom : le human-in-the-loop n’est plus un « pense à demander » dans un prompt, c’est un nœud — le train ne peut pas passer sans le feu vert.
Côté outils : c’est le modèle de LangGraph — qui a popularisé le nom — et, dans notre monde .NET, des workflows de Microsoft Agent Framework : des exécuteurs (les gares) reliés par des arêtes conditionnelles (les aiguillages), avec état et checkpoints. Les sous-agents de Copilot, vus ce matin, sont l’étoile simple ; le graphe est la généralisation.
Deux graphes, ne les confondez pas
La semaine vous a fait croiser deux graphes — et la confusion serait facile :
| Graphe de connaissances (hier) | Graphe d’orchestration (aujourd’hui) | |
|---|---|---|
| Les nœuds sont | des entités (Paiement, ACME) | des étapes (agents, code, humains) |
| Les arêtes sont | des relations (dépend de) | des transitions (si échec, retour) |
| Le graphe décrit | ce que l’IA sait | ce que les agents font |
| On le parcourt pour | répondre | exécuter |
Et ils s’emboîtent naturellement : dans une gare du graphe d’exécution, un agent peut très bien interroger le graphe de connaissances — le détective consulte son mur pendant que le train roule. Deux mécaniques, deux rôles, zéro concurrence.
Le mot d’honnêteté
Les rails ont un prix, et le billet n’est pas donné :
- La sur-ingénierie guette. Trois gares en ligne droite = un pipeline = trente lignes de script. Le graphe ne commence à payer qu’avec des aiguillages, des boucles ou des reprises. Dessiner une cathédrale ferroviaire pour un aller simple, c’est le piège classique du premier projet.
- L’état partagé est un métier. Le wagon que tout le monde lit et modifie, c’est le problème des systèmes distribués — les conflits d’écriture et les schémas d’état qui gonflent n’ont pas disparu parce qu’on a dit « agent ».
- Les rails figent. Un agent sur rails ne prendra jamais le raccourci génial que sa liberté lui aurait permis. C’est un arbitrage assumé : de la souplesse contre de la prévisibilité. Pour un flux de production, c’est presque toujours le bon échange — mais dites-le avec les yeux ouverts, et mesurez-le.
Le conseil pratique : dessinez d’abord sur papier. Si votre feutre ne trace ni losange (condition) ni flèche de retour (boucle), rangez le framework — un script suffit.
En résumé
- Le graphe d’orchestration = gares (agents, code, humains), rails (transitions), aiguillages (conditions), wagon (état), photos du wagon (checkpoints).
- Les cinq patterns d’hier sont cinq formes du même graphe — l’apprendre, c’est tous les avoir.
- Le gain profond : structure déterministe, jugement confiné — traçable, reprennable, dessinable, avec l’humain comme vraie gare.
- Ne confondez pas les deux graphes de la semaine : l’un sait (connaissances), l’autre fait (exécution) — et ils s’emboîtent.
- Le graphe paie quand il y a conditions, boucles ou reprise — sinon, un script honnête fait l’affaire.
Le chef d’orchestre d’hier improvisait avec talent ; aujourd’hui, il a un plan de réseau sous les yeux — et vous savez désormais lire les deux cartes de la semaine : celle du savoir, celle du travail. La prochaine fois qu’un train d’agents déraille à 3 h du matin, vous saurez exactement à quelle gare regarder. Et ça, franchement… c’est pas sorcier.
