Moteur d'orchestration IA : router chaque requête vers le bon modèle

Une plateforme IA d'entreprise n'a jamais un seul modèle. Elle en a un économique et prompt à répondre, un lent qui raisonne, un qui code, et parfois une API externe pour ce qui n'est pas confidentiel. Ce qui décide, requête par requête, s'appelle le moteur d'orchestration, et c'est là que se jouent le coût, la latence et la confidentialité.

Par QDNA · Publié le 28 août 2026 · 10 min de lecture

Pourquoi un seul modèle est un mauvais défaut

La première version d'une application d'IA en entreprise appelle toujours un modèle unique, par une bibliothèque cliente, avec une clé dans une variable d'environnement. Cette approche fonctionne, et elle contracte trois dettes que l'organisation paie plus tard.

Une dette de coût s'installe d'abord, parce que la distribution des requêtes est fortement déséquilibrée. Reformuler une phrase, classer un document, extraire un champ d'un formulaire ou résumer un paragraphe représentent l'essentiel du volume sans réclamer la moindre capacité de raisonnement long, si bien que les adresser au modèle le plus onéreux revient à payer le tarif du raisonnement pour des opérations qui ne raisonnent pas.

Une dette de latence s'y ajoute, puisque les modèles à raisonnement produisent des tokens de réflexion avant de formuler leur réponse. Sur une tâche de classification, ce préambule constitue du temps perdu, et il se voit : une interface qui met huit secondes à cocher une case est perçue comme défaillante, quelle que soit la justesse du résultat.

Une dette de confidentialité. C'est la plus coûteuse. Quand l'appel est câblé en dur, il n'existe aucun endroit dans le code où l'on puisse écrire « ce document ne sort pas ». La décision a été prise une fois, à l'écriture, pour toutes les requêtes à venir : y compris celles que personne n'avait imaginées.

Le gain n'est pas seulement théorique, et il est mesuré depuis 2024. Les auteurs de RouteLLM, publié à ICLR 2025 par une équipe de Berkeley et d'Anyscale, entraînent un routeur sur des données de préférence pour arbitrer entre un modèle fort et un modèle faible, et rapportent une réduction de coût supérieure à un facteur deux dans certains cas, sans dégradation de la qualité des réponses. RouterBench, qui rassemble plus de quatre cent mille résultats d'inférence, fournit depuis un cadre d'évaluation commun à ces travaux.

Sources : Ong et al., RouteLLM: Learning to Route LLMs with Preference Data, et RouterBench. Ces résultats portent sur des paires de modèles et des jeux d'évaluation précis : ils établissent que la technique fonctionne, pas le gain que vous obtiendrez sur votre trafic, dont la distribution vous est propre.

Les trois pièces d'un moteur d'orchestration

L'architecture qui répond à ces trois dettes tient en trois couches successives, dont chacune remplit une fonction et une seule, ce qui rend le système lisible pour qui doit l'auditer.

1. Le classifieur

Le classifieur répond à une seule question, celle de la nature de la requête, et deux familles de réponses coexistent pour y parvenir, qu'une plateforme aboutie emploie conjointement plutôt que d'en choisir une.

Le routage par règles décide sur des critères explicites : l'identité de l'appelant, l'application d'origine, la longueur du contexte, la présence d'un motif dans le texte, l'étiquette de classification portée par un document. C'est déterministe, lisible et auditable : trois propriétés qui comptent quand un délégué à la protection des données demande pourquoi telle requête est partie où elle est partie.

Le routage sémantique calcule un vecteur de la requête avec un modèle d'embeddings, et le compare à des exemples de référence. Il reconnaît une intention qu'aucune règle n'avait prévue : « résume-moi ça » et « fais-moi une synthèse en trois points » tombent au même endroit sans qu'on ait listé les formulations. Le prix à payer est qu'il se trompe parfois, et qu'il faut décider ce qui se passe quand la confiance est basse.

La combinaison qui tient en production place les règles en premier, comme coupe-circuit, pour tout ce qui doit rester déterministe, puis le sémantique en second pour affiner le choix parmi les destinations que les règles ont autorisées, et jamais dans l'ordre inverse.

2. La politique de routage

La politique de routage traduit la qualification en destination, et quatre critères suffisent à couvrir la plupart des situations, à condition de voir qu'ils ne sont pas de même nature : le premier constitue une contrainte, les trois autres relèvent de l'optimisation.

L'ordre compte. La sensibilité s'évalue en premier et élimine des destinations ; les trois autres critères choisissent parmi ce qui reste. Une politique qui optimise le coût avant d'évaluer la sensibilité finira, un jour, par envoyer un contrat vers une API parce que c'était moins cher.

3. La passerelle

La troisième couche ne décide de rien puisqu'elle se borne à exécuter et à enregistrer, ce qui constitue le rôle d'une passerelle LLM, laquelle expose une interface commune aux applications tout en dialoguant avec chaque runtime dans son propre protocole.

• Identifiants virtuels et quotas : chaque équipe, chaque application reçoit sa clé, avec son budget. Une boucle d'agent qui part en vrille consomme son quota, pas celui de la production.
• Bascule et repli : si un runtime ne répond pas, la requête part vers une destination de secours : à condition que la politique de sensibilité l'autorise. C'est le point de rupture le plus courant, nous y revenons plus bas.
• Journalisation : qui a demandé quoi, à quel modèle, pour quel coût. Sans cette trace, aucune des décisions précédentes n'est démontrable.
• Alias stables : les applications appellent un nom de rôle, pas un nom de modèle. Changer de modèle derrière un alias ne demande alors aucun déploiement applicatif.

Les runtimes servent enfin le modèle en bout de chaîne, qu'il s'agisse de vLLM pour un service à forte concurrence, de llama.cpp pour un poste de travail ou d'une API externe pour ce qui n'est pas sensible, sachant que le moteur d'orchestration ne les remplace pas mais choisit entre eux.

Les trois pannes qu'on voit vraiment

Un moteur d'orchestration échoue rarement de façon bruyante : il échoue en continuant de répondre, ce qui rend la défaillance beaucoup plus difficile à détecter qu'une interruption franche.

La bascule qui trahit la politique constitue la défaillance la plus grave et la plus banale à la fois. Le runtime local tombe, la passerelle bascule vers l'API de secours exactement comme elle est configurée pour le faire, et des documents confidentiels partent chez un tiers pendant toute la durée de l'incident sans que personne ne le remarque, puisque le service n'a pas été interrompu. La règle qui l'évite est simple à énoncer et à oublier : sur un flux marqué sensible, une panne doit produire une erreur, jamais un repli hors du périmètre.

Le cache qui traverse les cloisons vient ensuite, car une passerelle qui met les réponses en cache accélère le service et en réduit le coût. Si la clé de cache n'intègre pas l'identité de l'appelant et son périmètre d'habilitation, la réponse calculée pour un utilisateur autorisé sera resservie à un autre qui ne l'était pas, ce qui impose de cloisonner le cache selon les mêmes frontières que les données elles-mêmes.

Le classifieur qui dérive. Les exemples de référence d'un routeur sémantique ont été choisis à un moment donné, sur les usages de ce moment. Six mois plus tard, les utilisateurs posent d'autres questions, le taux de confiance baisse, et le routeur envoie de plus en plus de requêtes vers sa destination par défaut : souvent la plus chère. Il faut mesurer la distribution des décisions dans le temps, pas seulement leur justesse au départ.

Le routage est le point d'application de la souveraineté

Cet argument justifie l'investissement à lui seul, et il porte davantage qu'un raisonnement fondé sur le coût, dont le gain reste conjoncturel.

Une politique de confidentialité, un engagement contractuel, une analyse d'impact : tout cela décrit ce qui doit arriver aux données. Le routeur est le seul endroit du système où cette description devient une décision exécutée, pour chaque requête, et journalisée. Tant qu'une règle n'est pas implémentée là, elle reste une intention, et personne ne peut démontrer qu'elle a été respectée.

Cela a une conséquence pratique sur l'architecture : le classifieur de sensibilité doit être local, y compris quand la requête finira chez un fournisseur externe. Faire évaluer par une API la question « cette donnée a-t-elle le droit de partir vers une API ? » revient à l'avoir déjà envoyée. C'est le même raisonnement que celui développé dans IA générative et RGPD : le contrôle se joue sur le chemin de la donnée, pas dans les conditions générales.

Un agent IA souverain n'est donc pas un agent qui s'interdirait tout service externe, mais un agent dont chaque sortie vers l'extérieur a été autorisée par une règle explicite et laisse derrière elle une trace exploitable.

Ce qu'il faut mesurer

Un moteur d'orchestration qui n'est pas instrumenté ne se pilote pas, et quatre indicateurs suffisent pourtant à savoir s'il accomplit le travail qu'on attend de lui.

• La distribution des décisions : quelle part du volume va vers chaque destination. C'est le premier chiffre à regarder, et celui qui révèle une dérive du classifieur.
• Le coût par requête et par équipe, pas le coût total. Le total baisse toujours au début ; ce qui compte est de savoir quelle application consomme quoi.
• La latence au premier token, par destination. C'est elle que l'utilisateur perçoit, et elle est très différente d'un modèle de raisonnement à un petit modèle. Voir prefill, decode et cache KV.
• Le taux de repli, et son motif. Un repli fréquent est soit une panne masquée, soit une politique trop stricte ; dans les deux cas c'est une information.

Par où commencer

La séquence de mise en œuvre qui fonctionne ne commence pas par le classifieur, contrairement à ce que suggère l'intuition.

Posez d'abord la passerelle avec un seul modèle derrière elle : elle n'apporte encore aucun routage, mais elle fournit les identifiants virtuels, les quotas et la journalisation, et surtout elle révèle la distribution réelle des requêtes, que personne ne connaît avant de l'avoir mesurée. Deux semaines de traces valent mieux que six réunions d'estimation.

Ajoutez ensuite une deuxième destination et une règle isolée, celle de la sensibilité, articulée en deux branches : c'est la règle qui apporte le plus de valeur et qui demande le moins d'arbitrage. Le routage sémantique et l'arbitrage fin sur le coût n'interviennent qu'en troisième position, lorsque vous savez enfin ce que vous routez.

Nous détaillons les briques de cette chaîne dans la section orchestration multi-agents, qui couvre la passerelle, le routeur sémantique, le harness d'agent, les serveurs MCP privés et la mémoire. Pour poser la vôtre, un échange sans engagement suffit à cadrer le premier jalon.