Agents orchestrés vs mélange d'experts : quelle architecture d'IA choisir

Ceux qui introduisent aujourd’hui l’automatisation basée sur l’IA dans l’entreprise se retrouvent confrontés à un choix architectural qui, jusqu’à il y a un an, n’existait tout simplement pas. En principe, il n'y avait qu'une seule voie : prendre le plus grand modèle disponible et l'utiliser uniquement là où les dépenses énormes à engager étaient viables. Les architectures agentiques et le mélange d'experts (MoE) ont brisé cette linéarité, permettant d'atteindre des performances élevées avec des modèles à faible coût.

La première stratégie d'optimisation est l'orchestration externe, qui est un modèle petit, léger et axé sur la coordination qui décide quel outil ou modèle verticalisé invoquer pour chaque étape d'une tâche complexe. Le second est le MoE interne : un énorme modèle unique qui n’active cependant qu’une petite partie de ses paramètres pour chaque jeton généré, réduisant ainsi le coût de calcul sans sacrifier la capacité globale.

Choisir la bonne architecture pour un contexte opérationnel spécifique est une tâche extrêmement verticale. Il est nécessaire de connaître les forces et les faiblesses des deux architectures et d'adapter ces évaluations au type d'automatisation à activer, aux éventuelles méthodes de formation et aux données dont vous disposez.

L’efficacité des architectures agents orchestrées

Les modèles frontières utilisés comme acteurs uniques dans une automatisation sont l’équivalent informatique d’un manager qui ne délègue jamais. La grande capacité d’abstraction et de généralisation des très grands modèles est gaspillée dans de nombreux scénarios opérationnels. Certaines tâches peuvent être résolues par des modèles spécialisés en moins de temps et avec une fraction du coût de calcul requis par les grands réseaux de neurones.

Le résultat publié par Nvidia Research avec le framework ToolOrchestra a clairement démontré l'efficacité de l'approche spécialisée. Les chercheurs ont formé un orchestrateur à partir de seulement 8 milliards de paramètres qui, sur le benchmark Humanity's Last Exam, ont surpassé les modèles monolithiques du calibre de GPT-5, qui s'étaient arrêtés à 35,1 %, dépensant environ 70 % de moins.

ToolOrchestra répond au problème d'optimisation en entraînant un modèle dédié exclusivement au routage, optimisé avec un apprentissage par renforcement. L'intelligence artificielle est capable de s'auto-évaluer en fonction de trois paramètres : la précision du résultat (la tâche a-t-elle été résolue ?), l'efficacité (combien cela a-t-il coûté et combien de temps cela a-t-il pris ?) et le respect des préférences de l'utilisateur (si l'utilisateur a indiqué qu'il préférait certains outils, le système les a-t-il respectés ?).

La clé du succès d’un système orchestré est une répartition équilibrée de la charge de travail, et atteindre cet équilibre n’est pas coûteux ; en fait, la formation de l'orchestrateur Nvidia n'a nécessité que 552 problèmes synthétiques et 1 296 invites. Cela signifie qu'une équipe MLOps interne, dotée des compétences appropriées, peut reproduire l'approche et former un orchestrateur personnalisé pour ses charges de travail spécifiques, en choisissant le modèle de base et les outils qu'elle préfère.

Mélange d'experts : routage au sein du modèle

Les architectures mixtes d'experts apportent l'intelligence de routage dans le modèle, au niveau le plus bas possible : l'opération d'inférence unique sur un jeton. Dans un Transformer traditionnel, chaque jeton passe par tous les paramètres du modèle : chaque couche d'attention, chaque réseau de rétroaction. Dans une architecture MoE, les couches de rétroaction sont remplacées par une batterie d'experts (sous-réseaux spécialisés) et un routeur interne (la porte) qui décide quels experts activer. Les experts non activés restent éteints, sans consommer de ressources informatiques.

DeepSeek V3, toujours parmi les modèles à poids ouvert les plus performants aujourd'hui, en est l'exemple canonique. Il possède 671 milliards de paramètres au total, mais pour chaque jeton, il n'en active que 37 milliards, soit environ 5,5 %. Chaque couche MoE contient un expert partagé, activé pour tous les tokens et dédié au savoir commun, ainsi que 256 experts routés, dont 8 sont sélectionnés par token. Le modèle a été pré-entraîné sur 14 800 milliards de jetons sur les GPU H800, ce qui en fait l’un des modèles les moins chers à entraîner dans sa gamme de performances.

Qwen3 suit la même philosophie, avec 235 milliards de paramètres au total et 22 milliards de paramètres actifs par jeton. GPT-5 lui-même utilise une architecture clairsemée, bien qu'OpenAI n'ait jamais publié tous les détails techniques. En pratique, trois des modèles frontières les plus utilisés sont tous, à des degrés divers, des architectures MoE.

Comparaison directe : orchestration externe vs routage interne

À ce stade, il est utile de mettre les deux paradigmes côte à côte, en se concentrant sur les variables importantes pour prendre des décisions éclairées. Il n’est pas possible d’établir a priori quelle est la meilleure approche, mais il est possible de comprendre dans quels contextes chaque approche excelle et où elle démontre ses limites.

Coût par requête. Les architectures mixtes d'experts réduisent le coût au niveau de l'inférence unique : puisque seule une fraction des paramètres est active, le calcul par jeton est proportionnellement inférieur. L’orchestration externe, en revanche, réduit le coût au niveau du système, et non au niveau des appels individuels. En choisissant le bon modèle pour chaque sous-tâche, vous évitez de faire appel au modèle le plus cher alors qu’un spécialiste bon marché suffit. Sur Tau Bench, Orchestrator-8B a résolu les tâches à 30 % du coût du GPT-5 utilisé seul. Les deux mécanismes d'optimisation fonctionnent à des niveaux différents et peuvent se chevaucher.

Latence. Un modèle MoE effectue une inférence en une seule passe directe. Le routage entre experts s'effectue au sein du GPU, avec des latences de l'ordre de la microseconde pour la fonction de gate. Un système orchestré, en revanche, introduit une latence multi-shift, avec des temps de réseau, de sérialisation et de désérialisation. Cette latence n'est cependant pas décisive dans certains contextes : en effet, l'Orchestrator-8B susmentionné prend en moyenne 8,2 minutes pour résoudre un problème sur le dernier examen de l'humanité, soit moins de la moitié du GPT-5 utilisé de manière monolithique, car il choisit des outils plus rapides. Toutefois, pour les charges de travail en temps réel, la latence de l’orchestration reste une contrainte structurelle.

Verrouillage du fournisseur. Un modèle MoE est un artefact logiciel unique lié à son fournisseur. Utiliser DeepSeek, par exemple, signifie dépendre de l'infrastructure et des API de DeepSeek, et utiliser GPT-5 signifie dépendre d'OpenAI. Si le fournisseur modifie ses prix, modifie ses conditions de service ou arrête le support d'une version, l'entreprise est directement impactée. Un système orchestré est structurellement indépendant des modèles sous-jacents. Si un modèle devient trop cher ou devient obsolète, l’orchestrateur peut le remplacer par un autre sans avoir à reconcevoir l’intégralité du pipeline. ToolOrchestra a démontré explicitement cette flexibilité : lors de l'évaluation, les chercheurs ont remplacé les modèles de formation par des modèles jamais vus auparavant par l'IA, et le système a continué à fonctionner, en maintenant le meilleur compromis entre performances et coûts.

Adaptabilité aux nouvelles tâches. L’orchestrateur, par définition, n’exécute pas la tâche, mais coordonne ceux qui l’exécutent. Lorsqu’un nouveau domaine ou un nouveau type de tâche émerge, il suffit d’ajouter un nouvel outil ou un nouveau modèle spécialisé à la boîte à outils, sans avoir à recycler l’orchestrateur, qui a déjà appris à généraliser à des outils inconnus. Cependant, un modèle du MoE code ses connaissances en pondérations expertes ; par conséquent, s’adapter à un nouveau domaine nécessite généralement un réglage précis ou un recyclage, ce qui entraîne des coûts et du temps considérables. Pour les domaines déjà couverts par la formation, MoE propose des réponses immédiates sans aucune configuration supplémentaire.

Complexité opérationnelle. Un modèle MoE est un déploiement unique, avec un point de terminaison, un modèle et un ensemble de pondérations. La complexité du routage est encapsulée dans le modèle lui-même et ne nécessite aucune gestion externe. Un système orchestré implique plutôt la gestion de plusieurs services, plusieurs API, plusieurs modèles, plusieurs versions. Chaque outil de la boîte à outils est un point de défaillance potentiel. Les compétences MLOps requises sont proportionnellement plus élevées : il ne suffit pas de savoir appeler une API, mais il faut savoir surveiller, équilibrer et mettre à jour toute une constellation de services.

Pour une entreprise disposant d’une petite équipe d’IA, cette surcharge opérationnelle peut être un facteur décisif.

Quand chaque approche est-elle appropriée : scénarios d’utilisation commerciale

Les architectures MoE sont un choix naturel lorsque le profil de travail est homogène, avec un volume élevé et une faible variabilité. Un bon exemple d’application serait un chatbot de support client qui gère des milliers de conversations par jour sur un domaine limité. Le modèle reçoit des textes similaires, produit des réponses similaires, et ce qui compte est de minimiser le coût par jeton et la latence de réponse. Il en va de même pour la classification automatique des documents ou la génération de textes commerciaux standards.

Dans tous ces cas, la force du MoE réside dans l’efficacité du passage unique, avec une faible latence, des coûts contrôlables et une complexité opérationnelle minimale.

L'orchestration externe devient supérieure lorsque le pipeline est complexe, en plusieurs étapes et implique des outils hétérogènes. L’exemple le plus immédiat est l’analyse documentaire approfondie, dans laquelle l’intelligence artificielle doit lire des documents dans des formats variables, vérifier les clauses basées sur la base de connaissances, vérifier les données financières citées dans le texte, générer un résumé critique et mettre le tout en forme dans un rapport. Aucun modèle, quelle que soit sa taille, n’effectue à lui seul toutes ces étapes de manière optimale. Un orchestrateur choisit le bon outil pour chaque phase, négociant de manière dynamique le compromis entre qualité, coût et délai. Due diligence, audits de conformité, recherche scientifique assistée, pipelines d’ingénierie de données avec validation, sont autant de scénarios dans lesquels la qualité globale ne dépend pas des compétences d’un seul modèle, mais de la capacité à coordonner différents spécialistes.

Rendre ce choix binaire est cependant une simplification excessive. Les deux paradigmes ne s’excluent pas mutuellement. Rien ne vous empêche d'utiliser un modèle MoE comme l'un des outils de la boîte à outils de l'orchestrateur. En fait, c'est exactement ce que fait le framework ToolOrchestra de Nvidia. L'orchestrateur décide quand les invoquer, pour quelles sous-tâches et quel budget allouer à chacune. Dans ce scénario hybride, le MoE fournit l’efficacité informatique sur une seule inférence, l’orchestrateur fournit l’intelligence de routage au niveau du système. Les deux niveaux d'optimisation s'additionnent.

La décision opérationnelle

Pour ceux qui doivent décider quelle architecture adopter, ou dans quelle combinaison, il est nécessaire de prendre en compte tous les facteurs évoqués lors de la comparaison directe. Outre les aspects purement pragmatiques, il faut également prendre en compte le besoin d’auditabilité et de contrôle des décisions d’acheminement. Un système orchestré produit un journal explicite de chaque décision, expliquant quel outil a été invoqué, pour quelle raison et à quel prix.

Ceci est crucial dans les secteurs réglementés, où chaque décision doit être traçable et explicable. Un modèle MoE, bien qu’il dispose d’un routeur interne, n’expose pas ses décisions de routage de manière facilement interprétable. Les experts qui ont été activés pour un jeton donné constituent des informations qui résident dans le modèle et ne sont pas conçues pour être facilement lues par un auditeur externe.

Conclusions

L’état de l’art évolue à une vitesse incroyable et l’évolution des architectures et des modèles est encore en pleine phase expansionniste. Tout choix architectural doit être réévalué régulièrement, en comparant les coûts et les performances réelles. En outre, il faut tenir compte du fait que le coût de l’infrastructure d’IA ne se limite pas au prix par jeton. Les coûts d'intégration, de maintenance, de surveillance, de mise à jour et de formation sont souvent supérieurs au coût informatique pur.

Un modèle MoE qui coûte deux fois moins cher par jeton mais nécessite le double d'heures de travail pour l'intégrer n'est pas nécessairement moins cher.

Un orchestrateur qui généralise à des outils inédits, mais nécessite une équipe DevOps dédiée, n’est pas forcément plus flexible en pratique. Le bon choix est celui qui minimise le coût total pour le profil spécifique de l’entreprise, dans le contexte spécifique où l’automatisation sera utilisée.