L’erreur la plus coûteuse que nous voyons dans les systèmes d’IA en production est d’utiliser un seul modèle pour tout.
Une équipe choisit un modèle phare, comme GPT-5.5 ou Claude Opus 4.8, puis construit toute son application autour de ce modèle. Ses factures mensuelles atteignent cinq chiffres. Le routage des demandes vers différentes catégories de modèles réduit généralement une grande partie de cette facture — environ 70 à 75 % dans l’exemple modélisé ci-dessous — tout en améliorant souvent la latence.
C’est l’orchestration multi-modèle : utiliser le bon modèle pour chaque tâche dans un système. C’est la différence entre l’IA amateur et l’IA en production.
Cet article couvre les modèles, la logique de routage, les compromis et un guide étape par étape pour l’implémentation.
Pourquoi un seul modèle n’est pas optimal
Les modèles disponibles en 2026 se regroupent en catégories approximatives :
Catégorie des modèles de raisonnement phares (modes de raisonnement de GPT-5.5, Claude Opus 4.8, Gemini 3.1 Pro et DeepSeek R1) : excellents pour le raisonnement complexe, coûteux (3 à 30 dollars par million de jetons en entrée et 15 à 50 dollars en sortie pour les modèles phares courants ; les offres professionnelles spécialisées sont nettement plus chères) et lents (5 à 30 secondes en moyenne).
Modèles généraux phares (GPT-5.5, Claude Sonnet 5 et Gemini 3.1 Pro) : excellents pour la plupart des tâches liées aux connaissances, d’un coût modéré (2 à 5 dollars par million de jetons en entrée et 12 à 30 dollars en sortie) et raisonnablement rapides (2 à 5 secondes).
Catégorie intermédiaire (Claude Haiku 4.5, Gemini 3.5 Flash et l’offre intermédiaire d’OpenAI) : adaptée aux tâches simples à modérées, peu coûteuse (1 à 2,50 dollars par million de jetons en entrée et 5 à 15 dollars en sortie) et rapide (1 à 2 secondes).
Petits modèles (les offres les plus légères des fournisseurs, comme Gemini 3 Flash Preview, et les petits modèles open source) : adaptés aux tâches structurées simples, très peu coûteux (0,50 à 1 dollar par million de jetons en entrée) et très rapides (moins d’une seconde).
Modèles spécialisés (représentations vectorielles, reclassement, vision et voix) : optimisés pour des tâches précises et souvent très peu coûteux grâce à leur spécialisation.
(Prix vérifiés le 7 juillet 2026 contre les pages de tarification des fournisseurs ; vérifier à nouveau avant de citer.)
Une application d’IA classique effectue de nombreux appels à des grands modèles de langage. Chacun répond à des exigences propres :
- Classer l’intention utilisateur : nécessite une classification simple, une réponse rapide. Un modèle intermédiaire est parfait.
- Extraire des données structurées à partir de documents : nécessite une fiabilité sur la sortie structurée, une complexité modérée. Modèle intermédiaire ou général phare.
- Produire la réponse réelle à une requête utilisateur : nécessite une qualité, une gestion du contexte. Modèle général phare ou modèle de raisonnement phare.
- Générer des résumés de conversations passées : résumé simple. Modèle intermédiaire ou petit.
- Traitement en arrière-plan par lots : non sensible à la latence, mais le volume compte. Modèle petit ou intermédiaire.
Employer un modèle phare pour toutes ces opérations est inutilement coûteux. La classification et le résumé n’en ont pas besoin ; l’extraction structurée s’en passe souvent. Seule la réponse destinée à l’utilisateur en bénéficie réellement.
Les économies de coûts sont réelles
Une application typique d’IA pour le travail de connaissance pourrait avoir une répartition des demandes comme suit :
- 60 % des appels LLM : classification simple, extraction, résumé. Meilleur avec des modèles intermédiaires ou petits.
- 30 % des appels : complexité modérée. Modèle intermédiaire ou général phare.
- 10 % des appels : raisonnement complexe ou réponse finale à l’utilisateur. Modèle phare.
Si vous utilisez un modèle phare pour tout, vous supportez 100 % de son coût. Avec un routage adapté :
- 60 % au coût du petit modèle (1/30e du modèle phare) : 2 % du coût initial.
- 30 % au coût intermédiaire (1/5e du modèle phare) : 6 % du coût initial.
- 10 % au coût du modèle phare : 10 % du coût initial.
Total : 18 % du coût initial, soit une réduction de 82 %. Sur une facture mensuelle de 10 000 euros, l’économie atteint 8 200 euros par mois.
Ces chiffres dépendent de la répartition de votre trafic, mais le principe reste constant : la plupart des applications combinent des demandes dont le coût moyen est nettement inférieur à celui de l’appel le plus cher. Le routage exploite cette différence.
Les modèles d’orchestration de base
Quelques modèles récurrents dans les systèmes multi-modèles en production :
Modèle 1 : Routage basé sur la tâche
Différents types de tâches vont vers différents modèles. C’est le modèle le plus simple.
# Model IDs verified 2026-07-07; SMALL_TIER is your provider's current
# small model — check the live model list rather than hard-coding blindly.
def route_request(task_type):
if task_type == "classification":
return SMALL_TIER
elif task_type == "extraction":
return "claude-haiku-4-5"
elif task_type == "summarization":
return "claude-haiku-4-5"
elif task_type == "user-facing-response":
return "claude-sonnet-5"
elif task_type == "complex-reasoning":
return "claude-opus-4-8"
Les tâches sont classifiées par le code appelant (il sait ce qu’il demande). Le routage est déterministe et facile à déboguer.
Modèle 2 : Routage basé sur la complexité
Le système estime la complexité de chaque demande et route en conséquence.
def route_by_complexity(request):
complexity = estimate_complexity(request)
if complexity < 3:
return "small"
elif complexity < 7:
return "mid"
else:
return "flagship"
L’estimation de complexité peut être heuristique (longueur de la demande, détection de mots-clés) ou basée sur un modèle (un classificateur peu coûteux évalue la demande). Ce modèle gère les cas où le même type de tâche varie en difficulté.
Modèle 3 : Routage en cascade
Essayez d’abord un modèle peu coûteux. Si la sortie est bonne, utilisez-la. Sinon, escaladez vers un modèle plus coûteux.
def cascade(request):
cheap_response = call_model("small", request)
if is_acceptable(cheap_response):
return cheap_response
return call_model("flagship", request)
Cela fonctionne lorsque “acceptable” est détectable — par des scores de confiance, des validateurs, ou un LLM distinct pour le contrôle de qualité. C’est puissant : la plupart des demandes simples sont répondues par le modèle peu coûteux ; seules les demandes difficiles atteignent le modèle coûteux.
Modèle 4 : Routage spécialisé
Utilisez des modèles spécialisés pour des tâches spécialisées :
- Représentations vectorielles : utilisez un modèle dédié, bien moins cher qu’un modèle conversationnel détourné pour cette tâche.
- Reclassement : utilisez un modèle dédié de reclassement.
- Vision : utilisez un modèle spécialisé en vision pour l’analyse d’images.
- Voix : utilisez un modèle de voix pour la transcription/synthèse.
- Code : utilisez un modèle spécialisé en code pour les tâches de code.
Les modèles spécialisés sont généralement plus rapides, moins chers et meilleurs à leur tâche spécifique qu’un modèle général essayant de faire la même chose.
Modèle 5 : Routage par fournisseur
Utilisez des modèles de plusieurs fournisseurs pour la redondance et la flexibilité tarifaire.
providers = ["openai", "anthropic", "google"]
preferred = "anthropic" # primary
fallback = "openai" # fallback
def call_with_failover(request):
try:
return call(preferred, request)
except (RateLimit, ProviderError):
return call(fallback, request)
Cela offre une résilience contre les pannes d’un seul fournisseur et les limites de débit. Cela permet également d’exploiter les changements tarifaires — lorsque un fournisseur réduit ses prix, déplacez plus de trafic vers lui.
Un exemple concret : IA de support client
Pour rendre les choses concrètes, voici comment une IA de support client pourrait utiliser l’orchestration multi-modèle.
Le système a ces étapes par ticket :
Étape 1 : Classer l’intention. Qu’est-ce que le client demande ? (5 à 10 catégories.)
Routage : un petit modèle. Il s’agit d’une classification simple. Coût : environ 0,0005 dollar par ticket, pour quelque 500 jetons au tarif de cette catégorie.
Étape 2 : Déterminer l’urgence et le sentiment. Le client est frustré ? C’est urgent ?
Routage : le même petit modèle. Il s’agit d’une autre classification simple. Coût : environ 0,0005 dollar par ticket.
Étape 3 : Récupérer des connaissances pertinentes.
Routage : modèle de représentation vectorielle et modèle de reclassement, soit des outils spécialisés pour une tâche spécialisée. Coût : environ 0,002 dollar par ticket, principalement dû au reclassement facturé autour de 2 dollars pour 1 000 recherches.
Étape 4 : Déterminer si l’IA peut répondre ou si une escalade humaine est nécessaire.
Routage : Claude Haiku 4.5. Une classification légèrement plus sophistiquée étant donné le contexte récupéré. Coût : ~0,002 dollar par ticket (≈2 000 tokens de contexte).
Étape 5 (si l’IA peut répondre) : Générer la réponse destinée à l’utilisateur.
Routage : Claude Sonnet 5. La qualité compte ici — c’est ce que lit l’utilisateur. Coût : ~0,015 dollar par ticket (≈3 000 tokens d’entrée / 400 tokens de sortie).
Étape 6 (si l’IA ne peut pas répondre) : Générer un résumé pour l’agent humain.
Routage : un modèle intermédiaire. Un résumé utile, non destiné à l’utilisateur. Coût : ~0,004 dollar par ticket.
Étape 7 : Vérification de qualité. La réponse a-t-elle respecté nos normes ?
Routage : Claude Haiku 4.5 en tant que juge rapide. Coût : ~0,002 dollar par ticket.
Ce sont des chiffres modélisés — les volumes de tokens supposés sont indiqués par étape afin que vous puissiez les recalculer avec votre propre trafic.
Pour les tickets que l’IA répond (disons 70 %) : ~0,022 dollar par ticket. Pour les tickets escaladés vers les humains (30 %) : ~0,009 dollar par ticket. Moyenne pondérée : ~0,018 dollar par ticket.
Si chaque étape fonctionnait sur un tier de raisonnement phare au lieu de cela (mêmes volumes de tokens à ~5 dollars/M d’entrée, ~25 dollars/M de sortie) : environ 0,06 à 0,08 dollar par ticket. L’approche multi-modèle réduit environ 70 à 75 % de la facture.
À 1 000 tickets par jour, cela représente ~50 dollars par jour → environ 18 000 dollars par an d’économies. Significatif, bien que la plus grande victoire opérationnelle soit généralement la latence : le pipeline routé répond aux tickets simples en une seconde au lieu de trente.
La logique de routage
Quelques approches pour implémenter le routage :
Approche 1 : Codée en dur par type de tâche
La plus simple. Vous savez quel type de tâche vous appelez, vous choisissez le modèle.
def classify(text):
return openai_client.chat.completions.create(
model=SMALL_TIER, # your provider's current small model
messages=[{"role": "user", "content": f"Classify: {text}"}],
)
def respond(context, query):
return claude_client.messages.create(
model="claude-sonnet-5", # ID verified 2026-07-07
max_tokens=1024,
messages=[{"role": "user", "content": f"Context: {context}\n\nQuery: {query}"}]
)
Avantages : Transparent, facile à déboguer, facile à modifier. Inconvénients : Ne s’adapte pas à la complexité des demandes à l’intérieur d’un type de tâche.
Approche 2 : Modèle de routage
Un petit modèle classe chaque demande et la route.
ROUTER_PROMPT = """
Classify this request as: trivial, moderate, or complex.
Output one word.
Request: {request}
"""
def route(request):
classification = small_model_call(ROUTER_PROMPT.format(request=request))
return MODEL_BY_COMPLEXITY[classification]
Avantages : S’adapte à la complexité à l’intérieur d’une catégorie. Inconvénients : Ajoute de la latence (l’appel de routage), ajoute un point de défaillance, nécessite un réglage.
Approche 3 : Routage fondé sur les représentations vectorielles
Pour les demandes qui correspondent à des schémas connus, comparez leur représentation vectorielle à celle d’exemples antérieurs.
def route(request):
embedding = embed(request)
closest = find_nearest_example(embedding)
return closest.suggested_model
Avantages : Rapide (juste une recherche vectorielle), devient plus intelligent avec plus de données. Inconvénients : Nécessite la construction d’un ensemble étiqueté d’exemples.
Approche 4 : Cascade
Essayez d’abord le moins coûteux ; escaladez si nécessaire.
def cascade(request):
cheap = small_model_call(request)
if validates(cheap):
return cheap
return flagship_call(request)
Avantages : Adaptatif, coût moyen bas. Inconvénients : Lent pour les cas nécessitant l’escalade (deux appels), nécessite une validation fiable.
En pratique, de nombreux systèmes en production utilisent une approche hybride : routage codé en dur pour les principaux types de tâches, avec des cascades pour les sous-types à forte variance.
Les pièges
Quelques erreurs à éviter :
Piège 1 : Optimiser les coûts tout en dégradant la qualité
Il est facile de router tout vers des petits modèles et de voir les coûts baisser. Il est plus difficile de remarquer que la qualité a également baissé. Associez toujours les changements de routage à une surveillance de la qualité.
Une discipline utile : lorsque vous déplacez une tâche vers un modèle moins coûteux, faites un test A/B pendant une semaine avec des métriques de qualité. Ne déployez pas le changement sans preuve que la qualité a tenu.
Piège 2 : Concevoir un routage excessivement complexe
Un routage qui gère 100 types de tâches avec une logique sophistiquée est plus difficile à maintenir que le routage qu’il remplace. Commencez simple. Si la version simple est 80 % aussi bonne que la version sophistiquée, déployez la version simple.
Un modèle courant : un routage de 50 lignes gérant 5 à 10 types de tâches couvre 90 % du bénéfice. Au-delà, les retours sont décevants.
Piège 3 : Ignorer la latence
Les modèles moins coûteux sont également généralement plus rapides — ce qui est bon. Mais si vous cascadez (essayez le moins coûteux, puis le phare), vous pouvez doubler la latence pour les cas difficiles. Pour les flux destinés aux utilisateurs, cela compte.
Un modèle utile : pour les réponses destinées aux utilisateurs sensibles à la latence, utilisez par défaut le phare et acceptez le coût. Réservez la cascade pour le traitement en arrière-plan ou asynchrone.
Piège 4 : Ne pas gérer les défaillances des fournisseurs
Lorsque vous dépendez de plusieurs modèles, vous avez plusieurs façons de défaillir. Un modèle phare tombe en panne, une limite de débit est déclenchée, une clé API expire. Votre logique de routage doit avoir des secours.
Minimum : chaque modèle “principal” doit avoir un modèle “secours” d’un fournisseur différent. Même si la qualité diminue en cas de secours, le système reste opérationnel.
Piège 5 : Ne pas mesurer la qualité par route
Vous devez savoir quelles routes fonctionnent bien et lesquelles ne fonctionnent pas. Cela implique une évaluation, idéalement automatisée.
Une configuration utile consiste à enregistrer, pour chaque appel en production, le modèle utilisé, la demande, la réponse et, lorsque c’est possible, un signal de qualité tel qu’un retour utilisateur, un indicateur en aval ou une évaluation automatisée. Regroupez les indicateurs par route afin de détecter une baisse de qualité avant les plaintes des utilisateurs.
Où cela va
Quelques tendances à attendre :
Le routage automatique en tant que service. Des outils comme OpenRouter, Helicone, Portkey et d’autres offrent de plus en plus de “routage intelligent” — ils choisissent le modèle pour vous selon des règles configurables. Attendez-vous à ce que cela mûrisse significativement.
La spécialisation par modèle augmentant. Des modèles spécialisés pour le code, les mathématiques, des domaines spécifiques. Le routage inclura de plus en plus de modèles spécialisés.
Les coûts continueront à baisser. Les modèles de 2026 sont 10 fois moins chers que la qualité équivalente de 2024. D’ici 2028, attendez-vous à un autre facteur 10. L’économie de l’orchestration multi-modèle continuera à s’améliorer.
Les modèles exécutés sur l’appareil. Les téléphones et ordinateurs portables dotés de capacités d’IA locales offriront une catégorie « gratuite » pour certaines demandes. La logique de routage intégrera de plus en plus la règle « rester sur l’appareil si possible ».
API standardisées entre fournisseurs. Les API compatibles avec OpenAI (déjà largement adoptées) signifient que le changement de fournisseur devient de plus en plus trivial. Attendez-vous à plus de standardisation, ce qui rend les stratégies multi-fournisseurs plus faciles.
Liste de vérification de départ
Si vous construisez un système multi-modèle à partir de zéro ou migrez d’un seul modèle :
-
Cartographiez vos tâches. Quels types d’appels LLM fait votre application ? À quelle fréquence approximative ? À quel coût approximatif ?
-
Classez les tâches par complexité. Pour chaque type, choisissez le niveau trivial, modéré ou complexe, puis associez-lui une catégorie de modèle.
-
Construisez un routeur. Commencez par un routage basé sur les tâches codé en dur. Ne sur-ingénieriez pas.
-
Ajoutez des secours. Chaque modèle principal doit avoir un modèle de secours (d’un fournisseur différent).
-
Mesurez la qualité par route. Configurez un enregistrement et une évaluation de base. Vous devez savoir si la qualité tient.
-
Itérez. Déplacez les tâches vers des modèles moins coûteux là où la qualité tient. Déplacez les tâches vers des modèles plus coûteux là où la qualité se dégrade. Ajustez au fil du temps.
-
Poursuivez les ajustements. Les modèles et les prix évoluent, tandis que de nouvelles offres apparaissent. Une configuration de routage optimale en mai 2026 peut ne plus l’être en novembre.
Arrêtez d’utiliser un seul modèle pour tout
L’orchestration multi-modèle est l’une des modifications à plus haut rendement sur un système d’IA en production. Bien faite, elle réduit les coûts de 60 à 90 % tout en améliorant souvent la qualité (car chaque tâche utilise un modèle adapté).
La barrière technique est faible : une logique de routage élémentaire tient en quelques dizaines de lignes de code. L’exigence de rigueur est plus élevée, car vous devez mesurer continuellement la qualité pour vérifier la pertinence durable des décisions de routage.
Arrêtez d’utiliser un seul modèle pour tout. Cartographiez vos tâches. Choisissez le bon modèle pour chaque. Mesurez le résultat. Itérez. Les économies sont réelles et les améliorations de qualité sont généralement un bonus.
