Pendant deux ans, le secteur n’a mesuré ses progrès qu’à une seule aune : qui alignait le plus gros modèle. Sur la plupart des benchmarks, les meilleurs ne se tiennent plus qu’à quelques points, et les équipes qui font vraiment tourner l’IA en production sont passées à autre chose. La question n’est plus de savoir quel modèle l’emporte, mais comment en faire travailler plusieurs de concert, et comment démontrer que le résultat justifiait l’effort.
Ce virage porte un nom : l’orchestration de l’IA, c’est-à-dire l’assemblage de modèles et d’outils spécialisés en un seul système, sous la conduite d’une couche dont l’unique métier est de décider ce qui s’exécute, et à quel moment. Moins spectaculaire que la sortie d’un modèle de pointe, le sujet touche pourtant de bien plus près à la valeur et au risque.
Le sujet concerne celui qui signe autant que ceux qui construisent. L’orchestration ne rend pas un système plus intelligent par miracle. Elle multiplie les rouages, et chaque rouage est un endroit où l’on décide à votre place. Les études sur l’échec des projets d’IA sont sans appel, et ce ne sont pas les modèles qu’elles accusent.
Selon certaines estimations, plus de 80 % des projets d’IA échouent, un taux d’échec à peu près double de celui des projets informatiques sans IA.
RAND Corporation, The Root Causes of Failure for Artificial Intelligence Projects · août 2024
RAND a interrogé soixante-cinq spécialistes de la donnée et ingénieurs justifiant chacun d’au moins cinq ans d’expérience. Verdict : la technologie tenait le plus souvent ; c’est l’organisation autour d’elle qui flanchait. La vague générative n’a guère amélioré le tableau.
Environ 95 % des organisations n’ont tiré de leurs pilotes d’IA générative aucun bénéfice mesurable au compte de résultat.
MIT Project NANDA, The GenAI Divide : State of AI in Business · 2025
L’orchestration, c’est l’architecture qui mène un système au-delà de la démonstration. Conduite sans soin, c’est aussi le moyen d’enfouir cinq nouveaux points de décision dans un schéma que personne ne gouverne. Cet article montre comment obtenir le premier résultat sans subir le second. Chaque chiffre est daté là où il est cité, et revérifié chaque trimestre.
Trois couches, chacune sa décision
Tout système orchestré parvenu en production se décompose selon les trois mêmes couches. Laissez un instant les étiquettes de côté : l’important est la question que chacune vous oblige à trancher.
| Couche | Ce qu’elle recouvre | La question qu’elle impose |
|---|---|---|
| Modèle | Les modèles eux-mêmes, généralistes et spécialisés | Quel modèle pour quelle tâche, et qui surveille la facture |
| Outil | Ce qui permet à un modèle d’agir : recherche, bases de données, code, API | Ce qu’il peut toucher, et si l’on peut revenir en arrière |
| Orchestration | La couche qui décide de ce qui s’exécute, et quand | Qui pourra relire la décision après coup |
Un modèle raisonne, mais ne peut rien accomplir seul. Ce sont les outils qui lui permettent d’agir. La couche d’orchestration, elle, attribue chaque tâche à un modèle, décide quand appeler un outil et ce qu’il advient en cas d’échec. C’est dans cette dernière couche que loge vraiment l’intelligence du système, et c’est aussi celle où les équipes investissent le moins.
Un seul modèle, des talents inégaux
L’attrait d’un modèle unique saute aux yeux : une seule intégration, une seule facture, un seul objet à maîtriser. La réalité s’est montrée moins accommodante.
Prenez un service d’assistance. Il doit cerner la tonalité d’un message, retrouver la bonne information, rédiger une réponse et la contrôler avant qu’elle parte. Un modèle de pointe peut s’attaquer aux quatre. Mais ce sont quatre métiers, chacun avec sa façon d’échouer, et un modèle réglé pour bien rédiger n’arbitre pas comme un modèle réglé pour bien classer. Voilà pourquoi les systèmes qui tiennent en production répartissent la charge entre plusieurs modèles au lieu de tout miser sur un seul.
Un second argument parle d’abord au directeur financier : mobiliser votre modèle le plus puissant pour chaque tâche coûte cher, alors que la plupart n’en demandent pas tant. Et l’écart n’a rien d’une erreur d’arrondi.
Entre les modèles de production les moins chers et les modèles phares de pointe, le prix par jeton varie désormais dans un rapport de plus de 1 à 100, et l’écart se creuse encore sur certaines tâches réelles.
Analyse de l’auteur, grilles tarifaires des API publiées par les principaux fournisseurs de modèles · mi-2026
Aiguiller le travail facile vers les modèles bon marché et garder les plus chers pour les cas ardus n’a plus rien d’une optimisation. C’est ce qui sépare un système qui se rembourse d’un système qui perd de l’argent à bas bruit, et c’est en bonne partie pour cela que les équipes orchestrent.
En une seule année, la part des entreprises renonçant à la plupart de leurs initiatives d’IA est passée de 17 % à 42 %.
S&P Global Market Intelligence, Voice of the Enterprise · octobre 2025
Un mot sur les noms de modèles, car ils font un bon test. À l’heure où ces lignes sont écrites, le peloton de tête est serré (Claude Opus, GPT-5, Gemini, Grok), avec derrière lui de solides options meilleur marché. Ce classement se rebat à peu près tous les mois, et tout article qui vous livre un vainqueur unique se démode sans le dire. L’enseignement durable ne tient pas au leader du moment. Il tient à ceci : construisez de manière à pouvoir remplacer un modèle, car vous le ferez. Un système arrimé à un seul fournisseur est une décision qu’il faudra tôt ou tard défaire.
Quand l’action des modèles se standardise
Le modèle de langage pense ; l’outil lui permet d’agir. Cette couche rassemble tout ce vers quoi un modèle tend la main pour toucher le monde extérieur : recherche sur le web, requête dans une base de données, appel d’API, bac à sable pour exécuter du code, système de fichiers. Chaque fois qu’un assistant fait une recherche en ligne ou lance du code, c’est dans cette couche qu’il puise.
Pendant l’essentiel des deux dernières années, brancher un modèle sur un outil relevait du travail d’artisan, à recommencer pour chaque modèle et chaque outil. L’arithmétique a vite viré au casse-tête : dix modèles multipliés par cent outils, cela fait mille intégrations à construire puis à entretenir. Un standard a changé la donne.
- Avant : 10 × 100 = 1 000 intégrations. Chaque modèle branché sur chaque outil, à la main.
- Après : MCP = 1 standard. Tout modèle rejoint tout outil par un point de raccordement unique.
Le Model Context Protocol a été présenté par Anthropic le 25 novembre 2024 : un standard ouvert destiné à relier les systèmes d’IA aux outils et aux sources de données externes.
Anthropic, annonce du MCP · novembre 2024
Le MCP n’est pas un schéma d’orchestration à proprement parler. C’est la plomberie qui court sous les schémas : une voie commune par laquelle tout modèle atteint tout outil, si bien que remplacer l’un ou l’autre n’oblige plus à refaire le raccordement.
Son adoption dit assez combien le besoin était réel. OpenAI et Google l’ont pris en charge dans le courant de 2025. En décembre 2025, Anthropic a ensuite remis le protocole à l’Agentic AI Foundation, rattachée à la Linux Foundation : il se trouve désormais en terrain neutre, hors de la tutelle d’un éditeur unique, comme le HTTP qui n’appartient à personne. Pour un dirigeant, la leçon est circonscrite mais concrète. La couche de connexion se banalise, et c’est une bonne nouvelle : moins de budget part dans le raccordement, davantage peut financer le travail qui vous distingue.
Trois schémas, à chacun son usage
Les outils passent. Les schémas qui les sous-tendent, eux, sont stables depuis assez longtemps pour qu’on bâtisse une stratégie dessus. Trois méritent d’être connus. Il ne s’agit pas de les classer, mais de retenir celui qui épouse votre problème.
| Schéma | Enchaînement | Description | Adapté à |
|---|---|---|---|
| Séquentiel | Question → Recherche → Génération → Vérification | Le plus simple des trois. Chaque étape nourrit la suivante : prendre la question, aller chercher le contexte, générer la réponse, la vérifier. Le flux se comprend et se débogue étape par étape. Son point faible : la rigidité. Si l’étape deux établit que la question est sans réponse, la séquence n’en déroule pas moins les étapes trois et quatre. Convient au travail prévisible, découpé en étapes nettes. | Un travail prévisible, en étapes nettes |
| La recherche d’abord | Recherche → Ancrage → Génération | Celui-ci est né d’un problème précis : privés d’information, les modèles inventent des faits. Le remède : aller chercher d’abord l’information pertinente, puis générer une réponse qui s’y adosse. Sur le fond, l’idée est de séparer les rôles : au modèle le raisonnement, à une base distincte la mémoire. Plutôt que de réentraîner le modèle sur des faits nouveaux, on lui remet exactement le contexte voulu, au moment où il en a besoin. Le problème de génération se mue en problème de recherche et de synthèse, et la recherche est plus fiable que la génération. | Des faits à sourcer, pas à inventer |
| Multi-agents | Planification → Recherche → Rédaction → Vérification | Le plus sophistiqué, et le plus survendu. Plutôt qu’un flux unique, on monte des agents spécialisés qui se passent le relais. L’un planifie et découpe la mission ; les autres cherchent, rédigent et vérifient, chacun dans un périmètre étroit. Le pari : la compétence naît de la coordination entre spécialistes, et non d’un généraliste qui s’essaie à tout. Le revers : un graphe d’agents qui se parlent se surveille plus mal, se borne plus mal, et part plus facilement en boucle. N’y recourir que si le travail exige réellement des spécialités distinctes d’une étape à l’autre, et non parce que l’approche paraît plus avancée. | Des spécialités réellement distinctes à chaque étape |
La plupart des systèmes en production combinent les trois : une structure multi-agents où chaque agent mène ses propres recherches et où les agents communiquent en séquence. Aucun nom de framework ici, et c’est voulu. Dans ce domaine, les cartes sont sans cesse rebattues : les frameworks à base de graphes qui mènent les nouveaux projets cette année n’étaient pas en tête il y a dix-huit mois, et toute présélection établie aujourd’hui aura pris un coup de vieux le jour où vous agirez. Quels que soient les outils retenus, faites-y passer un vrai processus, puis confiez-le à quelqu’un qui ne l’a pas construit, et regardez ce qui se passe.
Le routeur, clé de voûte
Comprendre les schémas est une chose. Mais quand on cherche ce qui permet à un système orchestré de battre un modèle unique, un composant ressort, qui fait l’essentiel du travail. Si vous ne devez lire qu’une partie de cet article avant de recevoir un fournisseur, lisez celle-ci.
Appelons-le le routeur. Il lit chaque requête qui arrive et choisit le chemin qu’elle empruntera dans votre système. Une réponse parfaite aiguillée sur la mauvaise voie ne sert à personne : voilà pourquoi c’est ce composant, bien plus que les modèles placés derrière lui, qui décide le plus souvent si le système valait la peine d’être bâti. Tout dépend de la précision du routage : soit le système mérite sa complexité, soit il n’est qu’un moyen plus lent et plus coûteux d’obtenir ce qu’un modèle unique vous aurait fourni.
| Type de problème | Chemin | Remarque |
|---|---|---|
| Erreur de syntaxe | Analyseur léger | Un spécialiste rapide et peu coûteux, que les cas difficiles n’atteignent jamais. |
| Erreur d’exécution | Inspection de l’état du programme → Modèle de raisonnement | Un outil relève l’état du programme en cours d’exécution, puis transmet ses constats à un modèle qui raisonne dessus. |
| Erreur de logique | Recherche de solutions antérieures → Récupération du contexte → Synthèse | Un chemin encore différent : se rappeler ce qui a déjà fonctionné, puis bâtir dessus. |
Chaque spécialiste ne reçoit que les problèmes où il excelle : le routeur a tenu les autres à distance.
Prenons un assistant de programmation qui aide les développeurs à déboguer. La version à modèle unique soumet le code et l’erreur à un seul modèle, et croise les doigts. La version orchestrée commence par identifier la nature du problème. 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 et confie ses constats à un modèle de raisonnement. Une erreur de logique prend encore une autre voie : recherche de solutions antérieures, récupération du contexte, puis synthèse. Chaque spécialiste ne reçoit que les problèmes où il excelle : le routeur a tenu les autres à distance.
Comment le routeur tranche-t-il ? Trois approches dominent. La correspondance sémantique rapproche la requête d’exemples propres à chaque chemin et retient le plus proche : c’est rapide quand les catégories sont bien distinctes. La correspondance par mots-clés guette des signaux explicites : c’est simple, et étonnamment robuste quand on dispose d’indicateurs fiables. Confier le routage lui-même à un petit modèle rapide offre plus de souplesse que les mots-clés et plus de fiabilité que la seule correspondance sémantique, moyennant un peu de latence. En production, on les combine le plus souvent en cascade : la méthode rapide d’abord, la suivante en renfort quand la confiance est faible, et toujours un chemin par défaut pour les cas véritablement ambigus.
Voici ce qu’il faut emporter en réunion budgétaire. Les équipes se tourmentent sur le choix du modèle de génération et délaissent discrètement le routeur. C’est le monde à l’envers. Une réponse convenable bien aiguillée l’emporte à tous les coups sur une réponse brillante mal aiguillée. Dans nos missions, nous tenons la précision du routage pour l’indicateur qui annonce si un système orchestré sera rentable, en précisant qu’il s’agit de notre lecture et non d’une loi établie par la mesure : la qualité des modèles en aval pèse bien moins que l’aptitude du routeur à envoyer chaque requête au bon modèle. Mieux vaut un routeur simple qui tranche juste qu’un routeur astucieux qui se trompe souvent. Si l’argument porte, la première étape concrète vous attend plus bas, et elle coûte moins cher que n’importe quel outil du marché.
Coordonner n’est pas maîtriser
Il reste, au cœur de tout cela, un vide qu’aucun framework ne comblera à votre place, et c’est précisément là-dessus que le conseil d’administration vous interrogera.
Toutes les comparaisons sérieuses de frameworks d’orchestration parues cette année aboutissent à la même conclusion, peu confortable : ces outils coordonnent ce que font les agents, mais aucun ne décide nativement si une action risquée doit seulement avoir lieu. Ils relaieront sans sourciller la décision d’un modèle d’envoyer un e-mail, de déplacer un enregistrement ou de déclencher un paiement. L’action était-elle autorisée ? Peut-on l’annuler ? Quelqu’un pourra-t-il l’examiner après coup ? Ce n’est pas la couche d’orchestration qui tranche. C’est vous, ou personne.
Concrètement, cette couche de décision tient en trois éléments, tous laissés à votre charge par les frameworks.
- Périmètre d’autorisation : les actions qu’un agent peut mener seul, et celles qui requièrent d’abord le feu vert d’une personne.
- Piste d’audit : la trace de ce que chaque agent a décidé, et pourquoi.
- Point de contrôle : dès qu’il y a de l’argent en jeu ou un client concerné, une personne signe avant que le système n’agisse.
Rien d’exotique dans tout cela. Mais tout relève de votre responsabilité, et c’est précisément le travail dont la plupart des équipes ne découvrent l’absence qu’une fois le mal fait.
Et l’enjeu grandit avec le nombre d’agents. Une automatisation isolée peut tourner n’importe où et se surveiller à vue. Dès que des dizaines fonctionnent en parallèle, chacune prenant ses propres décisions, il faut un seul endroit qui les montre toutes : ce qui a tourné, ce qui a échoué, ce que chacune a décidé, et pourquoi. Ce besoin surgit du jour au lendemain, et l’installer après coup sur une flotte d’agents développés au cas par cas est un chantier à part entière.
Disons-le franchement : un système orchestré disperse ses décisions entre de nombreux composants, et une décision éparpillée se perd vite de vue. La panne bruyante, celle où un processus s’interrompt en sonnant l’alarme, est réparée d’ici mardi. Redoutez plutôt la panne silencieuse : un agent glisse vers la mauvaise décision, et rien, nulle part, ne le signale. Journalisation, garde-fous et point de contrôle humain sur les actions qui touchent à l’argent ou aux clients ne sont pas des options à ajouter après le lancement. Ce sont eux qui distinguent un système automatisé d’un passif, et ce sont les premiers sacrifiés quand le calendrier dérape.
Quand orchestrer, et quand s’en passer
Nombre d’applications peuvent s’en passer. Un bot qui répond aux questions fréquentes : un modèle. Un classifieur qui trie les tickets : un modèle. Un outil qui rédige des fiches produits : un modèle. Leur greffer une couche d’orchestration ne vous apporte que de la complexité.
L’orchestration se justifie dès que l’une de ces conditions est remplie.
| Quand | Pourquoi |
|---|---|
| Plusieurs compétences, qu’aucun modèle seul ne sert bien | Mieux vaut coordonner que forcer un seul modèle sur des tâches qu’il réussit inégalement |
| Besoin de vraies données ou de vraies actions externes | Une couche qui pilote les appels d’outils vaut mieux qu’un prompt qui demande au modèle de faire illusion |
| Le coût varie fortement d’une tâche à l’autre | Envoyer le travail simple aux modèles bon marché réserve les plus chers aux cas difficiles |
| La fiabilité exige une solution de repli | Un modèle rapide et peu coûteux fait le premier tri et n’envoie que les cas difficiles à un modèle plus puissant |
La règle est simple. Partez d’un seul modèle. Tenez-vous-y jusqu’à rencontrer une limite nette. N’orchestrez que si la complexité se rembourse : un meilleur résultat, une facture allégée, ou une capacité hors de portée autrement. Une complexité injustifiable n’a rien d’une architecture. C’est une facture de maintenance signée par mégarde.
Si vous avez franchi ce seuil et que la réponse est oui, la première étape concrète ne consiste pas à choisir un framework, mais à rédiger la carte de routage : les types de requêtes que le système recevra, le chemin que chacun doit suivre, et le modèle le moins cher capable de traiter chaque chemin. Une demi-journée de travail, aucune dépense hormis l’attention, et vous en apprendrez davantage sur la solidité du projet qu’avec n’importe quelle évaluation d’outils. Vous n’arrivez pas à la remplir ? Le système n’est pas prêt à être construit, et vous venez d’économiser le prix des licences.
Fixer le critère d’arrêt avant de construire
Tout ce qui précède part du principe que ce système doit voir le jour. Ce n’est pas toujours le cas, et l’unique moment honnête pour le dire, c’est maintenant, tant que la salle est encore optimiste et que personne n’a rien à défendre.
L’orchestration multiplie les points de décision, et chacun permet de poser une question à laquelle on peut répondre d’avance. Avant de choisir un schéma, consignez par écrit le résultat qui vous fera arrêter. Pas « si ça ne marche pas » : un chiffre, assorti d’une date. Dans notre méthode, il prend le plus souvent la même forme, en trois critères :
- Plancher de qualité : le système doit l’atteindre au plus tard à la semaine fixée
- Plafond de coût : par exécution, une fois les volumes réels atteints
- Test de passation : à une date fixée, n’importe qui hors de l’équipe de développement sait ouvrir l’outil et en suivre la logique
Le troisième est le plus souvent escamoté, et c’est pourtant le plus révélateur. Si seule la personne qui a écrit la logique de routage sait la lire, ce que vous avez appris n’est pas qu’il faut davantage d’ingénierie. Vous avez appris quelque chose sur celui qui en aura la charge dans un an, et aucun supplément d’ingénierie n’y remédiera.
C’est la phase Cap d’AZIMUTH, la méthode exposée sur la page Méthode. Les clients la contestent plus que toute autre, jusqu’au trimestre où elle arrête un projet avant qu’il ne s’arrête tout seul. Abandonner à dessein un pari isolé coûte bien moins cher que de laisser dériver tout un programme jusqu’à ce qu’un dirigeant perde patience et le supprime en bloc ; et le conseil qui vous a vu trancher net approuvera plus vite votre demande suivante.
À quelles conditions arrêterions-nous ? Une équipe incapable d’écrire noir sur blanc la réponse n’est pas prête à construire, quel que soit l’outil retenu.
Traitez donc la question de l’architecture avec soin : elle compte. Simplement, répondez d’abord à l’autre, par écrit, tant que chacun croit encore à la réussite du projet.
Dernière relecture : juillet 2026. Ces pages sont relues tous les trimestres, et chaque correction est consignée, jamais faite en silence. Si un chiffre a vieilli, c’est un bogue : signalez-le à hello@bearingbridge.com.
