Au-delà du grand modèle unique. L’architecture qui passe en production.

Tout système orchestré qui passe en production se range dans les mêmes trois couches. Laissez les étiquettes de côté un instant. Ce qui compte, c’est la question que chaque couche vous met sous les yeux.

Un modèle sait raisonner, mais il ne peut rien faire seul. Les outils lui donnent les mains. La couche d’orchestration, elle, décide quel modèle prend quelle tâche, à quel moment appeler un outil, et ce qu’on fait quand tout casse. C’est là, dans cette dernière couche, que se loge vraiment l’intelligence du système ; et c’est celle où les équipes investissent le moins.

L’attrait du modèle unique saute aux yeux. Une intégration, une facture, une seule chose à suivre. La réalité, elle, s’est révélée moins nette.

Prenez un service client. Il faut lire l’humeur d’un message, retrouver la bonne information, rédiger une réponse, puis la relire avant qu’elle parte. Un modèle de pointe peut s’y essayer sur les quatre fronts. Mais chacun est un métier à part, avec ses propres façons de dérailler, et un modèle réglé pour bien écrire n’arbitre pas comme un modèle réglé pour classer juste. D’où le réflexe des systèmes qui tiennent en production : répartir le travail sur plusieurs modèles au lieu de tout jouer sur un seul.

Une deuxième raison touche d’abord un directeur financier. Faire tourner votre modèle le plus puissant sur chaque tâche coûte cher, et la plupart des tâches n’en ont aucun besoin. Et l’écart n’a rien d’anecdotique.

Envoyer les modèles bon marché sur le travail simple et réserver les modèles coûteux aux cas difficiles n’est plus une optimisation. C’est la ligne de partage entre un système qui se rembourse et un système qui perd de l’argent en silence, et c’est une bonne part de la raison d’orchestrer.

Un mot sur les noms de modèles, car le test est parlant. À l’heure où nous écrivons, la pointe tient en un groupe resserré : Claude Opus, GPT-5, Gemini, Grok, avec de solides options moins chères juste derrière. Ce classement se rebat presque tous les mois, et tout article qui vous sacre un vainqueur unique se démode à bas bruit. Ce qui dure, ce n’est pas de savoir quel modèle mène aujourd’hui. C’est qu’il faut construire de manière à pouvoir en changer, parce que vous en changerez. Un système soudé à un seul fournisseur est une décision qu’il faudra défaire un jour.

Les modèles de langage pensent. Les outils, eux, leur permettent d’agir. Cette couche rassemble tout ce vers quoi un modèle se tourne pour toucher le monde extérieur : recherche web, requête en base, appel d’API, bac à sable de code, système de fichiers. Quand un assistant cherche sur le web ou exécute du code, c’est là qu’il puise.

Pendant presque deux ans, brancher un modèle sur un outil relevait du sur-mesure, à refaire pour chaque modèle et chaque outil. Le calcul tourne vite au vinaigre : dix modèles par cent outils, cela fait mille intégrations à construire et à maintenir. Une norme a changé la donne.

MCP n’est pas un pattern d’orchestration en soi. C’est la plomberie sous les patterns : une manière commune, pour n’importe quel modèle, d’atteindre n’importe quel outil, si bien que changer l’un ou l’autre côté n’oblige plus à refaire la jonction.

Son adoption dit assez la réalité du besoin. OpenAI et Google l’ont tous deux adopté en 2025. Puis, en décembre 2025, Anthropic a confié le protocole à l’Agentic AI Foundation de la Linux Foundation : le voilà en terrain neutre, hors du contrôle d’un seul acteur, comme HTTP n’appartient à personne. Pour un dirigeant, la leçon est simple et concrète.La couche de connexion se banalise, et c’est une bonne nouvelle : moins de budget file dans la colle d’intégration, plus peut aller à ce qui vous distingue.

Les outils vont et viennent. Les patterns qui les sous-tendent, eux, sont stables depuis assez longtemps pour qu’on bâtisse dessus. Il y en a trois à connaître, et choisir entre eux, c’est une affaire d’adéquation à votre problème, pas de palmarès.

La plupart des systèmes en production combinent les trois : une architecture multi-agents où chaque agent récupère en interne et dialogue en séquence. Aucun nom de framework ici, à dessein. Les outils du domaine se rebattent sans cesse, les frameworks à base de graphes qui tiennent la corde cette année n’étaient nulle part il y a dix-huit mois, et toute liste dressée aujourd’hui aura vieilli le jour où vous passerez à l’acte. Quelle que soit votre sélection, faites-y passer un vrai processus, puis confiez-le à quelqu’un qui ne l’a pas construit et regardez ce qui se passe.

Comprendre les patterns, c’est une chose. Mais ce qui décide qu’un système orchestré l’emporte sur un modèle unique tient à un composant, un seul, qui abat le gros du travail. Si vous ne lisez qu’une section avant un rendez-vous fournisseur, que ce soit celle-ci.

Appelons-le le routeur. Il lit chaque requête entrante et choisit le chemin qu’elle prendra dans votre système. Une réponse parfaite lancée sur le mauvais chemin ne sert à rien : voilà pourquoi ce composant, et non les modèles derrière lui, décide le plus souvent si tout le système valait la peine. La justesse du routage sépare le système qui mérite sa complexité de celui qui n’est qu’une manière plus lente et plus chère d’obtenir ce qu’un modèle unique vous aurait donné.

Prenez un assistant de code qui aide à déboguer. La version à modèle unique envoie le code et l’erreur à un seul modèle, et croise les doigts. La version orchestrée commence par demander à quel type de problème on a affaire. Une erreur de syntaxe file vers un analyseur léger. Une erreur d’exécution déclenche un outil qui inspecte l’état du programme, puis passe ses constats à un modèle de raisonnement. Une erreur de logique prend un tout autre chemin : chercher des solutions passées, récupérer le contexte, puis synthétiser. Chaque spécialiste ne voit jamais que les problèmes qu’il traite bien, parce que le routeur a tenu le reste à distance.

Sur quoi le routeur se décide-t-il ? Trois approches dominent. La correspondance par le sens rapproche la requête d’exemples de chaque route et retient le plus proche : rapide quand les catégories se distinguent bien. La correspondance par mots-clés guette des signaux explicites : simple, et étonnamment solide dès qu’on a des indicateurs fiables. Confier le routage à un petit modèle rapide offre plus de souplesse que les mots-clés et plus de fiabilité que le sens seul, contre un peu de latence. En production, on les empile le plus souvent : la méthode rapide d’abord, la suivante en repli quand la confiance faiblit, et toujours un chemin par défaut pour les cas vraiment ambigus.

Voici ce qu’il faut emporter en réunion budgétaire. Les équipes se tourmentent sur le modèle de génération et négligent le routeur sans le dire. C’est l’inverse qu’il faudrait. Une réponse correcte bien routée bat une réponse brillante mal routée, à tous les coups. Dans nos missions, nous traitons la justesse du routage comme l’indicateur qui prédit la rentabilité d’un système orchestré ; et nous le donnons pour notre lecture, pas pour une loi établie : la qualité de vos modèles en aval pèse bien moins que l’aptitude du routeur à envoyer chaque requête au bon endroit. Un routeur simple qui vise juste bat un routeur malin qui se trompe souvent. Si l’idée fait mouche, la première étape concrète vient plus bas, et elle coûte moins cher que n’importe quel outil du marché.

Au milieu de tout cela subsiste un trou qu’aucun framework ne comble à votre place, et c’est celui sur lequel un conseil d’administration vous attendra.

Toute comparaison sérieuse des frameworks d’orchestration parue cette année tombe sur le même constat gênant : ils coordonnent ce que font les agents, mais aucun ne tranche, en natif, si une action risquée doit avoir lieu ou non. Ils achemineront sans broncher la décision d’un modèle : envoyer un e-mail, déplacer un enregistrement, déclencher un paiement. Savoir si l’action était permise, si on peut la défaire, et si quelqu’un pourra l’examiner après coup, la couche d’orchestration ne le décide pas à votre place. C’est vous qui tranchez, ou personne.

Concrètement, cette couche de décision tient en trois choses que les frameworks vous laissent sur les bras.

Rien d’exotique là-dedans. Tout cela tombe de votre côté de la ligne, et c’est le travail que la plupart des équipes s’aperçoivent avoir sauté seulement une fois que quelque chose est déjà parti.

Et cela pèse davantage à mesure que les agents se multiplient, pas l’inverse. Une automatisation isolée peut vivre n’importe où et se surveiller à la main. Dès que des dizaines tournent en parallèle, chacune tranchant dans son coin, il vous faut un seul endroit qui les montre toutes : ce qui a tourné, ce qui a échoué, ce que chacune a décidé et pourquoi. Le besoin surgit d’un coup, et l’ajouter après coup sur une flotte d’agents sur-mesure, c’est un projet à soi seul.

Disons-le tout net : un système orchestré disperse ses décisions sur quantité de composants, et une décision dispersée se perd vite de vue. La panne bruyante, celle où un processus s’arrête et hurle, sera réglée d’ici mardi. Redoutez plutôt la panne silencieuse, celle où un agent glisse vers le mauvais choix sans que rien, nulle part, ne le signale. La journalisation, les garde-fous et un contrôle humain sur les actions qui touchent à l’argent ou aux clients ne s’ajoutent pas après le lancement. Ce sont elles qui séparent un système automatisé d’un passif, et les premières qu’on sacrifie quand le calendrier dérape.

Toutes les applications n’ont pas besoin de tout cela. Un bot qui répond à une FAQ, c’est un modèle. Un classifieur qui trie des tickets, c’est un modèle. Un outil qui rédige des fiches produit, c’est un modèle. Leur ajouter une couche d’orchestration vous achète de la complexité, rien de plus.

L’orchestration gagne sa place dès que l’un de ces signaux est là.

La règle de décision n’a rien de compliqué. Commencez avec un modèle. Restez-y jusqu’à buter sur une limite nette. N’ajoutez de l’orchestration que si la complexité se paie d’un meilleur résultat, d’une facture plus basse, ou d’une capacité autrement hors d’atteinte.Une complexité que vous ne savez pas justifier, ce n’est pas de l’architecture. C’est une facture de maintenance signée par mégarde.

Si vous avez passé cette ligne et que la réponse est oui, la première étape concrète n’est pas de choisir un framework. C’est d’écrire la carte de routage : la liste des types de requêtes que verra le système, le chemin que chacune devrait suivre, et le modèle le moins cher capable de tenir chaque chemin. Cette carte, c’est une demi-journée de travail, elle ne coûte que de l’attention, et elle en dit plus long sur la réalité du projet que n’importe quelle évaluation d’outil. Incapable de la remplir ? Le système n’est pas prêt à être construit, et vous venez de vous épargner les frais de licence.

Tout ce qui précède suppose que ce système doive exister. Parfois, non. Et c’est le seul moment honnête pour le dire : tant que tout le monde, dans la pièce, est encore optimiste et n’a rien à défendre.

L’orchestration ajoute des points de décision. Chacun est un endroit où poser une question à laquelle on peut répondre d’avance. Avant de choisir un pattern, écrivez le résultat qui déclenche l’arrêt. Pas « si ça ne marche pas ». Un chiffre, avec une date. Dans notre méthode, la forme revient presque toujours, en trois points :

C’est le troisième qu’on saute le plus, et c’est le plus prédictif. Si la seule personne capable de lire la logique de routage est celle qui l’a écrite, la leçon n’est pas qu’il vous faut plus d’ingénierie. C’est une leçon sur qui portera cela dans un an, et aucune ingénierie de plus n’y changera rien.

C’est la phase Relèvement d’AZIMUTH, la méthode décrite sur lapage Méthode. Les clients la contestent plus que toute autre, jusqu’au trimestre où elle arrête un projet avant que le projet ne s’arrête tout seul. Arrêter un pari isolé à dessein coûte bien moins cher que de laisser un programme entier dériver jusqu’à ce qu’un dirigeant, à bout de patience, annule tout ; et le conseil qui vous a vu trancher net est celui qui approuvera votre prochaine demande plus vite.

Alors soignez votre réponse à la question de l’architecture, car elle compte. Mais répondez d’abord à l’autre, par écrit, tant que tout le monde croit encore que le projet va réussir.