Deux ans durant, le secteur n’a jaugé ses progrès qu’à l’aune d’un seul chiffre : la taille du modèle. Sur la plupart des bancs d’essai, les meilleurs modèles ne se départagent plus qu’à quelques points, et les équipes qui font réellement tourner l’IA en production ont changé de question. Elles ne se demandent plus quel modèle est le meilleur, mais comment en faire travailler plusieurs ensemble, et comment prouver que le résultat valait l’effort.
Ce basculement a un nom : l’orchestration de l’IA, c’est-à-dire la coordination de modèles et d’outils spécialisés au sein d’un même système, sous l’autorité d’une couche dont la seule fonction est de décider ce qui s’exécute, et à quel moment. Le sujet a moins d’éclat que le lancement d’un modèle de pointe, mais c’est là que se logent réellement la valeur et le risque.
L’enjeu ne concerne pas seulement ceux qui construisent : il concerne d’abord celui qui signe. L’orchestration ne rend pas un système plus intelligent par enchantement. Elle multiplie les rouages, et chaque rouage est un lieu où l’on décide à votre place. La recherche sur l’échec des projets d’IA est sans appel, et ce ne sont pas les modèles qu’elle met en cause.
Selon certaines estimations, plus de 80 % des projets d’IA échouent, soit à peu près le double du taux d’échec 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, tous forts d’au moins cinq ans d’expérience. Conclusion : la technologie fonctionnait le plus souvent ; c’est l’organisation qui l’entourait qui péchait. La vague générative n’a guère arrangé les choses.
Environ 95 % des organisations n’ont constaté aucun effet mesurable de leurs pilotes d’IA générative sur leur compte de résultat.
MIT Project NANDA, The GenAI Divide : State of AI in Business · 2025
L’orchestration, c’est l’architecture qui fait passer un système au-delà de la démonstration. Menée à la légère, elle permet aussi d’enfouir cinq nouveaux points de décision dans un schéma que personne ne gouverne. Cet article montre comment obtenir le premier sans subir le second. Chaque chiffre cité est daté et revérifié tous les trimestres.
Trois couches, trois décisions
Tout système orchestré parvenu en production s’organise selon les trois mêmes couches. Laissez un instant les étiquettes de côté : ce qui compte, c’est la question que chacune vous pose.
| Couche | Définition | La question à trancher |
|---|---|---|
| Modèle | Les modèles eux-mêmes, généralistes ou spécialisés | Quel modèle pour quelle tâche, et qui contrôle la facture |
| Outils | Ce qui permet à un modèle d’agir : recherche, bases de données, code, API | Ce qu’il peut toucher, et si c’est réversible |
| Orchestration | La couche qui décide quoi exécuter, et quand | Qui pourra relire la décision une fois prise |
Un modèle sait raisonner, mais il ne peut rien faire seul ; les outils lui donnent prise sur le réel. La couche d’orchestration, elle, décide quel modèle traite quelle tâche, à quel moment appeler un outil et que faire en cas d’échec. C’est dans cette dernière couche que loge vraiment l’intelligence du système, et c’est celle où les équipes investissent le moins.
Un modèle, des tâches qu’il maîtrise inégalement
L’attrait du modèle unique se comprend : une intégration, une facture, un seul objet à maîtriser. La réalité s’est montrée moins docile.
Prenons un service d’assistance. Il doit saisir la tonalité d’un message, retrouver la bonne information, rédiger une réponse et la contrôler avant envoi. Un modèle de pointe peut s’essayer aux quatre. Mais chacune de ces tâches est un métier à part, avec ses propres façons d’échouer, et un modèle réglé pour bien rédiger ne fait pas les mêmes arbitrages qu’un modèle réglé pour bien classer. Voilà pourquoi les systèmes qui tiennent en production répartissent le travail entre plusieurs modèles au lieu de tout miser sur un seul.
Une seconde raison 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 de marginal.
Entre les modèles de production les moins chers et les modèles phares, l’écart de prix par token dépasse désormais un facteur 100, et il se creuse davantage encore sur certaines tâches réelles.
Analyse de l’auteur, grilles tarifaires publiques des API des principaux fournisseurs de modèles · mi-2026
Orienter le travail simple vers les modèles bon marché et réserver les plus chers aux cas ardus ne relève plus de l’optimisation. C’est la ligne de partage entre un système qui se rentabilise et un autre qui perd de l’argent à bas bruit, et c’est l’une des principales raisons pour lesquelles les équipes orchestrent.
En un an, la part des entreprises qui abandonnent l’essentiel 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 c’est un bon révélateur. À l’heure où ces lignes sont écrites, le peloton de tête est serré (Claude Opus, GPT-5, Gemini, Grok), talonné par des options moins chères mais solides. Le classement change à peu près chaque mois, et tout article qui vous désigne un vainqueur se périme déjà sans le dire. Ce qui reste vrai, ce n’est pas le nom du leader du jour. C’est qu’il faut construire de façon à pouvoir changer de modèle, car vous en changerez. Un système lié à un seul fournisseur est une décision qu’il faudra défaire tôt ou tard.
Un standard pour faire agir les modèles
Le modèle de langage pense, l’outil agit. Cette couche réunit tout ce dont un modèle se sert pour agir sur le monde extérieur : recherche web, requête en base de données, appel d’API, bac à sable pour exécuter du code, système de fichiers. Chaque fois qu’un assistant cherche sur le web ou lance du code, il puise dans cette couche.
Pendant l’essentiel des deux dernières années, brancher un modèle sur un outil relevait de l’artisanat, à recommencer pour chaque modèle et chaque outil. L’arithmétique est vite devenue intenable : dix modèles multipliés par cent outils, cela fait mille intégrations à bâtir et à entretenir. Un standard a tout changé.
- Avant : 10 × 100 = 1 000 intégrations. Chaque modèle relié à chaque outil, à la main.
- Après : MCP = 1 standard. Tout modèle accède à tout outil par une jonction unique.
Anthropic a présenté le Model Context Protocol le 25 novembre 2024, comme un standard ouvert destiné à relier les systèmes d’IA à des outils et à des sources de données externes.
Anthropic, annonce du MCP · novembre 2024
Le MCP n’est pas un schéma d’orchestration en soi. C’est la plomberie qui court sous les schémas : un moyen commun, pour n’importe quel modèle, d’atteindre n’importe quel outil, si bien que changer l’un ou l’autre ne contraint plus à refaire la jonction.
Son adoption dit combien le besoin était réel. OpenAI et Google l’ont intégré au cours de 2025. En décembre 2025, Anthropic a ensuite confié le protocole à l’Agentic AI Foundation, rattachée à la Linux Foundation : le voilà en terrain neutre, hors du contrôle d’un seul éditeur, à l’image du HTTP, qui n’appartient à personne. Pour un dirigeant, la leçon est étroite mais concrète. La couche de connexion se banalise, et c’est une bonne nouvelle : moins de budget englouti dans le raccordement, davantage pour le travail qui vous différencie.
Trois schémas, chacun son terrain
Les outils passent. Les schémas sous-jacents, eux, n’ont pas bougé depuis assez longtemps pour qu’on bâtisse dessus. Trois valent d’être connus, et il ne s’agit pas de les classer, mais de choisir celui qui correspond à votre problème.
| Schéma | Déroulé | Description | Indiqué pour |
|---|---|---|---|
| Séquentiel | Question → Recherche → Génération → Vérification | Le plus simple. Chaque étape nourrit la suivante : recevoir la question, récupérer le contexte, générer la réponse, la vérifier. Le flux se lit et se débogue étape par étape. Son défaut : la rigidité. Si l’étape deux établit que la question est sans réponse, la séquence déroule malgré tout les étapes trois et quatre. Indiqué pour un travail prévisible aux étapes bien délimitées. | Travail prévisible aux étapes bien délimitées |
| Recherche préalable | Recherche → Ancrage → Génération | Ce schéma répond à un problème précis : faute d’information, les modèles inventent des faits. Le remède consiste à aller chercher d’abord l’information pertinente, puis à générer une réponse qui s’y appuie. Le principe sous-jacent est une séparation des rôles : au modèle le raisonnement, à une base distincte la mémoire. On ne réentraîne pas le modèle sur des faits nouveaux ; on lui fournit précisément le contexte dont il a besoin, au moment où il en a besoin. Un problème de génération devient un problème de recherche et de synthèse, et la recherche est plus fiable que la génération. | 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 construit des agents spécialisés qui se transmettent le travail. 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 capacité naît de la coordination entre spécialistes, non d’un généraliste qui prétend tout faire. Le prix : un graphe d’agents qui se parlent est plus difficile à surveiller, plus difficile à borner, et plus enclin à tourner en boucle. À réserver aux travaux qui exigent vraiment des spécialités distinctes d’une étape à l’autre, et non parce que cela fait moderne. | Des spécialités vraiment distinctes à chaque étape |
La plupart des systèmes en production combinent les trois : une architecture multi-agents où chaque agent mène ses propres recherches et communique en séquence. Aucun nom de framework ici, à dessein. Le paysage se redessine sans cesse : les frameworks à base de graphes qui mènent les nouveaux projets cette année ne dominaient pas il y a dix-huit mois, et toute liste restreinte établie aujourd’hui aura vieilli le jour où vous passerez à l’acte. Quel que soit l’outil retenu, faites-y passer un vrai processus, puis confiez-le à quelqu’un qui ne l’a pas construit, et regardez ce qui se passe.
Tout se joue au routeur
Comprendre les schémas est une chose. Mais à examiner ce qui fait qu’un système orchestré l’emporte ou non sur un modèle unique, on découvre qu’un seul composant porte l’essentiel. Si vous ne devez lire qu’une section de cet article avant de recevoir un fournisseur, lisez celle-ci.
Appelons-le le routeur. Il lit chaque requête entrante et décide du chemin qu’elle suivra dans le système. Une réponse parfaite engagée sur le mauvais chemin ne sert à rien : voilà pourquoi c’est ce composant, plus que les modèles placés derrière lui, qui détermine le plus souvent si le système valait la peine d’être construit. La justesse du routage fait toute la différence entre un système qui mérite sa complexité et un autre qui n’offre, plus lentement et plus cher, que ce qu’un modèle unique aurait fourni.
| Type de problème | Chemin | Remarque |
|---|---|---|
| Erreur de syntaxe | Analyseur léger | Un spécialiste rapide et peu coûteux, qui ne voit jamais passer les cas difficiles. |
| Erreur d’exécution | Inspection de l’état du programme → Modèle de raisonnement | Un outil relève l’état du programme en cours, puis transmet ses constats au modèle chargé du raisonnement. |
| Erreur de logique | Recherche de solutions antérieures → Récupération du contexte → Synthèse | Un chemin encore différent : retrouver ce qui a fonctionné, puis s’en servir comme base. |
Chaque spécialiste ne reçoit que les problèmes qu’il sait résoudre : le routeur a écarté tous les autres.
Prenons un assistant de code qui aide les développeurs à déboguer. La version à modèle unique soumet le code et l’erreur à un modèle, et croise les doigts. La version orchestrée commence par qualifier le problème. Une erreur de syntaxe est dirigée vers un analyseur léger. Une erreur d’exécution déclenche un outil qui inspecte l’état du programme, puis confie ses constats à un modèle de raisonnement. Une erreur de logique suit encore un autre chemin : recherche de solutions antérieures, récupération du contexte, synthèse. Chaque spécialiste ne reçoit que les problèmes qu’il sait résoudre : le routeur a écarté tous les autres.
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, ce qui va vite quand les catégories sont nettement distinctes. La correspondance par mots-clés repère des signaux explicites : une méthode simple, étonnamment robuste quand on dispose d’indicateurs fiables. Enfin, confier le routage à un petit modèle rapide offre plus de souplesse que les mots-clés et plus de fiabilité que la seule correspondance sémantique, au prix d’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 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 pèsent et soupèsent le choix du modèle de génération, et délaissent sans bruit le routeur. C’est le monde à l’envers. Une réponse correcte bien aiguillée l’emporte toujours sur une réponse brillante mal aiguillée. Dans nos propres missions, nous tenons la justesse du routage pour l’indicateur qui annonce si un système orchestré sera rentable, et nous le présentons comme notre lecture, non comme une loi mesurée : la qualité des modèles en aval pèse bien moins que la capacité du routeur à envoyer chaque requête au bon modèle. Un routeur simple qui tranche juste vaut mieux qu’un routeur astucieux qui se trompe souvent. Si l’argument vous convainc, 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 contrôler
Au centre de tout cela, il reste un vide qu’aucun framework ne comble pour vous, et c’est précisément sur ce point que le conseil d’administration vous interrogera.
Toutes les comparaisons sérieuses de frameworks d’orchestration parues cette année arrivent à la même conclusion, peu confortable : les frameworks coordonnent l’action des agents, mais aucun ne décide nativement si une action risquée doit seulement avoir lieu. Ils relaieront sans broncher 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-elle être annulée, quelqu’un pourra-t-il l’examiner ensuite ? La couche d’orchestration ne tranche pas ces questions pour vous. Soit vous les tranchez, soit personne.
Concrètement, cette couche de décision se résume à trois éléments dont les frameworks vous laissent la charge.
- Périmètre d’autorisation : ce qu’un agent peut faire seul, et ce qui requiert d’abord l’accord d’un humain.
- Piste d’audit : la trace de ce que chaque agent a décidé, et des raisons de sa décision.
- Point de contrôle : pour tout ce qui engage de l’argent ou touche un client, une personne signe avant que le système n’agisse.
Rien d’exotique là-dedans. Mais tout cela vous incombe, et c’est le travail que la plupart des équipes découvrent avoir négligé une fois le mal fait.
L’enjeu croît avec le nombre d’agents. Une automatisation isolée peut tourner n’importe où et se surveiller à vue. Quand des dizaines fonctionnent en parallèle, chacune prenant ses décisions, il faut un lieu unique qui les montre toutes : ce qui a tourné, ce qui a échoué, ce que chacune a décidé et pourquoi. Cette exigence surgit du jour au lendemain, et l’ajouter après coup à une flotte d’agents développés au cas par cas constitue un chantier à part entière.
Disons-le sans détour : 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 et sonne l’alarme, est corrigée dans la semaine. Craignez plutôt la panne silencieuse, celle où un agent glisse vers la mauvaise décision sans que rien, nulle part, ne le signale. Journalisation, garde-fous et validation humaine des actions qui touchent à l’argent ou aux clients ne sont pas des options à ajouter après le lancement. Ce sont elles qui séparent un système automatisé d’une source de risques, et ce sont les premières sacrifiées quand le calendrier glisse.
Quand orchestrer, et quand s’abstenir
Toutes les applications n’en ont pas besoin. 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 leur apporte que de la complexité.
L’orchestration trouve sa place lorsque l’une de ces conditions est réunie.
| Quand | Pourquoi |
|---|---|
| Plusieurs capacités, dont aucune n’est bien servie par un seul modèle | Coordonner vaut mieux qu’étirer un modèle unique sur des tâches qu’il maîtrise inégalement |
| Besoin de données ou d’actions externes réelles | Une couche qui pilote les appels d’outils vaut mieux qu’un modèle sommé de faire semblant |
| Des coûts très variables selon la tâche | Envoyer le travail simple vers des modèles bon marché libère les plus chers pour les cas ardus |
| Une fiabilité qui exige un plan de repli | Un modèle rapide et peu coûteux filtre en amont et ne fait remonter que les cas difficiles vers un modèle plus puissant |
La règle de décision est simple. Partez d’un 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é inaccessible autrement. Une complexité injustifiable n’est pas de l’architecture. C’est une facture de maintenance signée par inadvertance.
Si vous avez franchi ce seuil et que la réponse est oui, la première étape concrète n’est pas de choisir un framework, mais d’écrire la carte de routage : les types de requêtes que le système recevra, le chemin que chacun doit emprunter et le modèle le moins cher capable de traiter chaque chemin. Une demi-journée de travail, aucun coût 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.
Décider du critère d’arrêt avant de construire
Tout ce qui précède suppose que ce système doit voir le jour. Ce n’est pas toujours le cas, et c’est maintenant le seul moment où l’on peut le dire en toute honnêteté, tant que la salle est encore optimiste et que personne n’a encore rien à défendre.
L’orchestration multiplie les points de décision. Chacun est l’occasion de poser une question à laquelle on peut répondre d’avance. Avant de choisir un schéma, écrivez le résultat qui vous fera arrêter. Pas « si ça ne marche pas » : un chiffre, assorti d’une date. Dans notre méthode, on retrouve presque toujours les trois mêmes critères :
- Seuil de qualité : le système doit le franchir avant une semaine fixée d’avance
- Plafond de coût : par exécution, une fois les volumes réels atteints
- Test de passation : à une date fixée, toute personne extérieure à l’équipe de développement sait ouvrir le système et en suivre la logique
Ce troisième critère est le plus souvent escamoté, et c’est pourtant le plus révélateur. Si la seule personne capable de lire la logique de routage est celle qui l’a écrite, vous n’avez pas appris qu’il vous faut davantage d’ingénierie. Vous avez appris quelque chose sur la personne 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 présentée sur la page Méthode. Nos clients la contestent plus que toute autre, jusqu’au trimestre où elle arrête un projet avant que le projet ne s’arrête de lui-même. Renoncer délibérément à un pari isolé coûte bien moins cher que de laisser dériver tout un programme jusqu’à ce qu’un haut dirigeant perde patience et l’annule en bloc. Et le conseil qui vous a vu trancher net approuvera plus vite votre prochaine demande.
Que faudrait-il constater pour que nous arrêtions ? Une équipe incapable d’écrire cette phrase n’est pas prête à construire, quel que soit l’outil choisi.
Traitez donc la question de l’architecture avec soin, car elle compte. Mais répondez d’abord à l’autre, par écrit, tant que chacun croit encore que le projet va réussir.
Dernière relecture : juillet 2026. Ces pages sont relues chaque trimestre ; les corrections sont consignées, jamais effacées en silence. Si un chiffre a vieilli, c’est une erreur à corriger : écrivez-nous à hello@bearingbridge.com.
