Le cas contre l'orchestration magique
The graph that looked intelligent
The orchestration diagram was beautiful in the way dangerous diagrams often are. Rounded boxes, graceful arrows, a planner, a researcher, a verifier, a tool executor, a memory layer, a human approval node, and a final response. The demo moved with theatrical confidence. A user asked for an analysis, the planner decomposed the task, tools were called, intermediate notes appeared, and the final answer arrived with the calm of a system that had never met production traffic.
Then the first real exceptions arrived. A tool returned partial data. The planner retried with a different query and lost the earlier reason. The verifier checked style but not the source conflict. Memory brought back an old assumption because it looked relevant. A human approval step approved the final text without seeing the failed branch. The trace existed, but reading it felt like inspecting a suitcase packed by a committee during a fire drill. The graph had not failed dramatically. It had hidden the shape of responsibility.
This is the case against magical orchestration. Not against orchestration itself. Complex AI systems need coordination. They need to call tools, route tasks, manage context, ask humans, recover from failure, split work, and combine evidence. The argument is against the style of orchestration that treats a clever graph or agent loop as a substitute for explicit state, contracts, ownership, limits, and records. Magic is impressive in a demo because it hides the mechanism. Engineering is useful in production because it exposes the mechanism enough to repair it.
AI orchestration is where probability meets workflow. That junction is unforgiving. A model may choose a plan. A tool may return a result. A policy may allow an action. A retry may change context. A human may approve. A downstream system may act. If those transitions are not named, bounded, and recorded, the organisation gets an intelligent-looking system whose behaviour is difficult to reproduce and harder to govern. It is not autonomous. It is just evasive with better branding.
Orchestration is not intelligence dust
The word orchestration can make ordinary engineering sound newly enchanted. A sequence becomes a chain. A conditional becomes a router. A function call becomes a tool. A while loop becomes an agent. A queue becomes memory if the lighting is right. Some of this vocabulary is useful because AI systems do introduce new coordination problems. Some of it is packaging. Packaging is not evil. It becomes expensive when teams forget what is inside the box.
At its core, orchestration is the management of state, decisions, resources, and transitions. What is the task. What is the current state. Which inputs are allowed. Which tool may be called. Which output shape is expected. What happens on failure. Which retries are permitted. Which actions require approval. What evidence must be kept. Which step can be replayed. Which step is irreversible. These questions existed before generative AI. Models make them more important, not obsolete.
L'orchestration magique évite ces questions en laissant le modèle ou le framework déduire trop de choses à l'exécution. Le planificateur décide de la décomposition. Le modèle choisit les outils. La sortie de l'outil devient du contexte. L'étape suivante l'interprète. La mémoire ajoute de l'historique. Un vérificateur approuve. La réponse finale apparaît. Cela peut fonctionner pour des tâches exploratoires à faible enjeu. C'est fragile lorsque le flux de travail touche aux dossiers, à l'argent, à la sécurité, à la conformité, aux engagements clients, aux infrastructures ou à d'autres systèmes qui n'apprécient pas le théâtre d'improvisation.
Une conception d'orchestration disciplinée ne supprime pas la flexibilité. Elle la place à l'intérieur de rails. Le modèle peut proposer un plan, mais la sortie du planificateur a un schéma. Le système peut appeler des outils, mais les outils ont des portées et des budgets. Le flux de travail peut réessayer, mais les raisons de nouvelle tentative sont classifiées. La mémoire peut aider, mais l'état faisant autorité vit ailleurs. Un humain peut approuver, mais l'approbation voit les branches et les preuves pertinentes. La flexibilité survit. Le mystère ne prend pas le volant.
Le problème de l'état caché
La défaillance d'orchestration la plus courante est l'état caché. L'état apparaît dans les invites, les blocs-notes, les magasins de mémoire, les sorties d'outils, les messages intermédiaires, les résumés de modèles, les résultats en cache, les commentaires humains et les internals du framework. Chaque couche contient une vérité partielle. Aucune n'est l'enregistrement durable. Quand quelque chose tourne mal, l'équipe demande ce que le système croyait à l'étape sept. La réponse est un collage.
L'état caché rend le débogage misérable. Un modèle a choisi un outil différent parce qu'un résumé antérieur utilisait un verbe plus fort. Une nouvelle tentative a omis une contrainte. Un élément de mémoire d'une tâche antérieure a influencé le plan. Un résultat d'outil a été tronqué. Un vérificateur a vu la réponse finale mais pas la branche rejetée. Le système s'est comporté de manière plausible, et un comportement plausible est le type le plus agaçant à investiguer car il refuse de sembler cassé jusqu'à ce que vous connaissiez le fait manquant.
L'état de tâche durable doit être explicite. Il doit inclure l'intention de la tâche, la portée autorisée, l'ensemble des sources, la version du plan, les appels d'outils, les sorties d'outils, les raisons de nouvelle tentative, les décisions humaines, les contrôles de politique, les coûts, les délais d'attente et les actions appliquées. Toute interaction à faible enjeu n'a pas besoin d'un grand registre, mais toute orchestration qui peut affecter un travail réel a besoin d'un modèle d'état au-delà de la transcription. La transcription est un récit utile. Ce n'est pas le système d'exploitation.
L'état explicite améliore aussi la conception du produit. Les utilisateurs peuvent voir si le système planifie, attend un outil, est bloqué par une politique, demande une révision, réessaie après une erreur transitoire ou est prêt à appliquer des changements. Les opérateurs peuvent suspendre ou reprendre. Les développeurs peuvent tester les transitions. Les auditeurs peuvent rejouer. Le système devient moins magique et plus utile, un compromis que certaines démos résistent et que la plupart des équipes d'exploitation apprécient profondément.
Les appels d'outils ne sont pas anodins
L'utilisation d'outils donne des mains aux systèmes d'IA. C'est utile et dangereux. Lire un calendrier, rechercher des documents, interroger une base de données, envoyer un e-mail, ouvrir un ticket, modifier un enregistrement, déployer du code ou transférer de l'argent ne sont pas des actions équivalentes. Un orchestrateur magique peut les traiter comme des outils dans une liste. Un système sérieux les traite comme des capacités avec des portées, des effets secondaires, des permissions, des budgets et des exigences de preuve.
Chaque appel d'outil a besoin d'un contrat. Les entrées doivent être typées et validées. Les sorties doivent être vérifiées. Les erreurs doivent être classifiées. Les effets secondaires doivent être déclarés. L'idempotence doit être comprise. Les délais d'attente doivent être bornés. Les nouvelles tentatives doivent être sûres. Les autorisations doivent découler de l'utilisateur, de la tâche et de la politique, et non de l'enthousiasme du modèle. Le système doit savoir si un outil lit seulement, rédige un brouillon, modifie un enregistrement, notifie une personne ou déclenche une obligation externe. Un marteau et un virement bancaire ne devraient pas partager la même ambiance.
La sortie d'un outil doit aussi être traitée comme une entrée. Elle peut être partielle, obsolète, non autorisée, ambiguë ou hostile. Un résultat de recherche n'est pas une preuve tant que le système ne connaît pas la source, la fraîcheur et l'autorisation. Un résultat de base de données peut omettre des lignes en raison du contrôle d'accès. Une erreur d'API peut renvoyer un message qui ne devrait pas devenir une instruction. Un outil peut échouer poliment et échouer quand même. L'orchestrateur ne doit pas renvoyer chaque réponse d'outil au modèle comme si renvoyer du texte revenait à dire la vérité.
Les effets secondaires méritent une prudence particulière. Un plan généré par le modèle peut être jeté. Un courriel envoyé ne peut pas être désenvoyé avec la même confiance. Un enregistrement modifié peut déclencher des systèmes en aval. Un déploiement peut affecter les utilisateurs. Un remboursement peut déplacer de l'argent. L'orchestration doit séparer la proposition de l'action et exiger des portes explicites pour les étapes irréversibles ou conséquentes. Si un système peut faire des choses réelles, il lui faut plus qu'une boucle d'agent. Il lui faut des freins, des clés et quelqu'un qui sait où se trouve la pièce de rechange.
Les nouvelles tentatives sont une politique déguisée
Les nouvelles tentatives ressemblent à de la colle d'ingénierie jusqu'à ce qu'un orchestrateur IA commence à faire des choix. Si un outil échoue, réessayez. Si la sortie du modèle est malformée, demandez à nouveau. Si le vérificateur rejette la réponse, révisez. Si le plan stagne, refaites le plan. Cela peut être sensé. Cela peut aussi changer le résultat, masquer l'incertitude, augmenter les coûts ou effacer la preuve de pourquoi le premier chemin a échoué. Une nouvelle tentative n'est pas simplement une seconde tentative. C'est une décision sur le type d'échec que le système est autorisé à lisser.
La politique de nouvelle tentative doit être explicite. Les erreurs d'infrastructure transitoires peuvent être retentées différemment des conflits de politique. Un JSON malformé peut être réparé différemment d'une preuve manquante. Une faible confiance peut déclencher une révision plutôt qu'un autre échantillon. Un conflit de source ne devrait pas être résolu en demandant au modèle de sembler plus décisif. Un délai d'attente d'outil ne devrait pas devenir la permission d'utiliser une source plus faible sans marquer le changement. Le système doit savoir pourquoi il retente, ce qui est préservé, ce qui change et quand s'arrêter.
Sans cette discipline, l'orchestration crée des boucles polies. Le système continue d'essayer parce qu'essayer est peu coûteux en code. Cela peut brûler le budget, remplir les journaux, confondre les utilisateurs et finalement produire une réponse qui semble meilleure surtout parce que les preuves antérieures d'instabilité sont cachées. En production, une boucle qui cache ses propres tentatives échouées n'est pas de la persévérance. C'est de l'amnésie avec une barre de progression.
Les nouvelles tentatives devraient produire des enregistrements. Nombre de tentatives, raison, entrées modifiées, plan modifié, preuves préservées, coût, latence et disposition finale. Cela donne aux opérateurs un moyen de voir si un flux de travail est sain ou simplement persistant. Cela aide aussi à décider s'il faut corriger la qualité des entrées, la fiabilité des outils, le formatage du modèle, la clarté de la politique ou les attentes des utilisateurs. Une nouvelle tentative sans classification est un haussement d'épaules sous forme exécutable.
La vérification n'est pas un nœud décoratif
De nombreux diagrammes d'orchestration incluent un vérificateur. Très bien. On demande ensuite à ce vérificateur de contrôler si la réponse est plausible, bien formée ou conforme aux instructions. Moins bien. Un vérificateur qui ne lit que la réponse finale peut manquer les erreurs qui comptent : une source faible, une entrée interdite, un outil défaillant, un conflit de politique, une action dangereuse ou un plan modifié sans approbation. Il peut polir la façade pendant que la cuisine brûle.
La vérification doit être liée aux contrats et aux conséquences. Si la tâche est une extraction, vérifiez par rapport aux segments de la source. Si la tâche est une classification, vérifiez les étiquettes autorisées et les preuves. Si la tâche est une exécution d'outil, vérifiez les autorisations, les arguments, les effets secondaires et le retour arrière. Si la tâche est une aide à la décision, vérifiez la politique, la fraîcheur de la source, l'incertitude et les exigences de révision. Si la tâche est une communication, vérifiez le public, les affirmations, le ton et la divulgation. Un vérificateur générique vaut mieux que rien. Un vérificateur spécifique à la tâche vaut mieux qu'un théâtre.
Une partie de la vérification doit être déterministe. Les schémas, les valeurs autorisées, les autorisations, les budgets, les seuils, la fraîcheur de la source et les champs obligatoires n'ont pas besoin du jugement poétique d'un modèle. Utilisez des règles là où les règles sont nettes. Utilisez des modèles là où l'ambiguïté est réelle. Utilisez des humains là où les conséquences et les sens contestés exigent une responsabilité. L'orchestration magique demande souvent à un modèle de vérifier un autre modèle parce que cela semble symétrique. La symétrie est agréable dans les diagrammes d'architecture. Elle n'est pas automatiquement un contrôle.
Le vérificateur doit voir la trace dont il a besoin. Le texte final seul est rarement suffisant. Il lui faut les entrées, l'ensemble des sources, les sorties d'outils, les tentatives échouées, les transformations, les contrôles de politique et l'action planifiée. Il doit aussi avoir l'autorité de bloquer, de demander plus de preuves, de rediriger vers un examen humain ou de signaler des limites. Un vérificateur qui ne peut pas arrêter le flux de travail est un relecteur déguisé.
La mémoire ne doit pas usurper l'autorité
La mémoire d'un agent est utile lorsqu'elle porte des préférences, un contexte antérieur et des connaissances récurrentes sur les tâches. Elle est dangereuse lorsqu'elle se fait passer pour un état faisant autorité. Une préférence mémorisée n'est pas une politique. Une réponse précédente n'est pas un enregistrement. Un résumé d'un cas n'est pas le cas. Un plan passé réussi ne prouve pas que la prochaine tâche autorise les mêmes outils. La mémoire aide à la continuité. Elle ne doit pas être autorisée à faire passer l'autorité d'hier dans aujourd'hui.
La mémoire a besoin de types. Une préférence personnelle, un état de tâche, une politique organisationnelle, une preuve de source, un modèle appris, un résultat d'outil mis en cache et une décision historique sont des choses différentes. Elles nécessitent des portées, des expirations, des autorisations et des affichages différents. Si un orchestrateur récupère simplement les mémoires pertinentes et les ajoute au contexte, la pertinence devient la seule porte d'entrée. La pertinence n'est pas une autorisation. Une note privée peut être pertinente. Elle peut tout de même être interdite.
La mémoire a aussi besoin de suppression et de correction. Une hypothèse erronée ne doit pas persister parce qu'elle a été utile une fois. Une condition temporaire de projet doit expirer. Une correction de l'utilisateur doit s'appliquer dans un cadre défini. Un changement de politique doit invalider l'ancienne mémoire. Un résumé généré par un modèle ne doit pas devenir le raccourci qui remplace une source primaire. Le système doit montrer quelle mémoire a influencé un plan et permettre aux utilisateurs de la contester. Sinon, la mémoire devient une hantise polie.
La règle est simple : l'état faisant autorité vit dans des magasins gouvernés. La mémoire peut aider à la planification, mais elle ne doit pas décider en silence. Si l'orchestrateur utilise la mémoire, enregistrez quelle mémoire, pourquoi elle a été autorisée et comment elle a affecté le plan. Cela semble lourd uniquement si la mémoire fait un travail important. Si la mémoire fait un travail important, la lourdeur est précisément le but.
Le simple bat le magique plus souvent que les équipes ne le pensent
Chaque workflow d'IA n'a pas besoin d'agents. Certains nécessitent un pipeline déterministe avec une étape de modèle. D'autres ont besoin de récupération, d'un classifieur et d'une file de révision humaine. Certains ont besoin d'un formulaire qui appelle un modèle pour la rédaction. D'autres ont besoin d'une évaluation par lots. Certains ont besoin d'un planificateur. D'autres ont besoin d'une utilisation d'outils en plusieurs étapes. L'architecture doit suivre la tâche, et non l'enthousiasme actuel pour les schémas en forme d'agents.
L'alternative ennuyeuse gagne souvent. Une séquence fixe est plus facile à tester qu'une boucle ouverte. Une passerelle d'outils typée est plus sûre qu'un choix d'outil libre. Une file avec des états explicites est plus facile à exploiter qu'un agent récursif. Un garde-fou basé sur des règles est moins cher qu'un juge modèle lorsque la règle est claire. Un chemin d'escalade humain est préférable à une nouvelle tentative lorsque les conséquences sont élevées. Ce ne sont pas des positions anti-IA. Ce sont des positions pro-système.
Il y a un compromis. Une orchestration plus flexible peut gérer l'ambiguïté et les routes imprévues. Elle augmente aussi la variance, la charge de preuve, le coût et la complexité de débogage. Une orchestration plus explicite peut sembler rigide. Elle améliore aussi la reproductibilité, la responsabilité et la récupération. Le bon point dépend de l'ambiguïté de la tâche, des conséquences, du volume et de la tolérance à l'échec. La pensée magique prétend que l'extrémité flexible donne tout gratuitement. La production envoie la facture plus tard, avec des lignes détaillées.
Une question de conception utile est : qu'est-ce qui ne devrait jamais être choisi par le modèle. L'autorité de la source. Les permissions des utilisateurs. Les limites budgétaires. Les actions irréversibles. Les obligations de conservation. La base légale. Les seuils de sécurité. Certains de ces éléments peuvent être proposés ou expliqués par les modèles. Ils ne devraient pas être définis silencieusement par eux. Un modèle peut aider à naviguer dans un workflow. Il ne devrait pas devenir la constitution parce qu'il était pratique de tout mettre dans le contexte.
Concevoir l'orchestration comme un modèle d'exploitation
Une orchestration sérieuse commence par le contrat de tâche. Quel est l'objectif. Quelles données sont autorisées. Quelles sorties sont acceptables. Quels outils peuvent être utilisés. Quelles actions sont interdites. Quel budget s'applique. Quelle latence est tolérable. Quelles preuves doivent être conservées. Quels rôles humains existent. Quels états d'échec sont possibles. Quels chemins de récupération existent. Si l'équipe ne peut pas répondre à ces questions, elle n'a pas besoin d'un graphe plus magique. Elle a besoin d'une tâche plus claire.
Ensuite, définissez les transitions d'état. Planifié, en attente d'entrée, récupération, outil en attente, outil échoué, conflit de preuves, politique bloquée, revue humaine, approuvé, appliqué, compensé, annulé. Ces états peuvent sembler banals parce qu'ils le sont. Ils permettent au système d'être exploité. Ils permettent à une personne de savoir si elle doit attendre, intervenir, approuver ou réparer. Ils permettent aux tests d'affirmer le comportement. Ils permettent aux incidents de partir des faits plutôt que des impressions.
Ensuite, définissez les limites. Les modèles rédigent des plans. Les passerelles exécutent des outils. Les règles appliquent des contraintes précises. Les vérificateurs contrôlent les contrats. Les humains décident des conséquences contestées. Les journaux préservent les preuves. Les files gèrent les retards. Le stockage conserve l'état durable. Chaque limite devrait être assez ennuyeuse pour être expliquée. Si le modèle fait plusieurs de ces choses parce que c'était plus facile, nommez le risque et décidez si la tâche est suffisamment peu risquée pour le tolérer. Parfois, c'est le cas. De nombreux assistants internes peuvent être légers. Le problème est de prétendre qu'une conception légère est une base pour une automatisation à haute conséquence.
Enfin, un échec de test. L'outil renvoie des données partielles. Les sources sont en conflit. Le modèle produit une sortie invalide. La mémoire est obsolète. L'utilisateur n'a pas la permission. La limite de coût est atteinte. La revue humaine n'est pas disponible. Le réseau est lent. Le plan change après approbation. L'action réussit partiellement. Si l'orchestrateur ne peut pas vous dire ce qui se passe dans ces cas, le graphe n'est que décoratif. C'est peut-être un joli graphe. Placez-le près d'une plante, pas près de la production.
La leçon
L'argument contre l'orchestration magique est un argument en faveur de la discipline d'ingénierie. Les systèmes d'IA ont besoin de coordination, et les modèles peuvent rendre la coordination plus adaptative. Mais l'adaptation sans état explicite, contrats d'outils, politique de nouvelle tentative, vérification, limites de mémoire, barrières d'action et chemins de récupération n'est pas de l'intelligence. C'est un système qui demande aux futurs opérateurs de découvrir sa conception en lisant des traces après qu'un événement coûteux se soit produit.
Une bonne orchestration est moins mystique et plus utile. Elle nomme les états. Elle limite les outils. Elle enregistre les preuves. Elle sépare la proposition de l'action. Elle classe les nouvelles tentatives. Elle vérifie par rapport aux contrats de tâche. Elle traite la mémoire comme un soutien, pas comme une autorité. Elle donne aux humains des états vérifiables au lieu de transcriptions opaques. Elle choisit des pipelines simples quand des pipelines simples suffisent. Elle ajoute des agents là où l'ambiguïté justifie le coût opérationnel.
La magie cache le mécanisme. Une IA sérieuse a besoin de mécanismes qui peuvent être inspectés, mis en pause, corrigés et améliorés. L'objectif n'est pas de retirer l'émerveillement du logiciel. L'objectif est de garder l'émerveillement hors du rapport d'incident.