« Quel est le meilleur modèle ? » est la mauvaise question. Elle suppose qu’il existe une réponse unique, valable pour tous les cas, qu’un classement suffirait à trancher. En production, on ne fonctionne presque jamais ainsi. On ne choisit pas un modèle, on route chaque tâche vers le modèle qui lui convient.
Les modèles Claude se déclinent en plusieurs familles, du plus rapide et léger au plus puissant. La bonne pratique n’est pas de tout envoyer vers le plus capable par précaution, ni vers le moins cher par économie, mais d’assortir chaque tâche au bon profil. Voici comment nous raisonnons ce choix de modèle IA en production.
Le piège du benchmark unique
Un benchmark mesure une capacité moyenne sur un ensemble de tâches génériques. Votre production, elle, est faite de tâches précises : classer une alerte, extraire un champ, rédiger une synthèse, diagnostiquer un incident complexe. Le meilleur modèle au classement général peut être surdimensionné pour la moitié d’entre elles, et le plus rapide peut suffire là où on croyait avoir besoin de puissance.
Se fier à un benchmark unique conduit à deux erreurs opposées : payer un modèle lourd pour des tâches triviales, ou confier à un modèle léger un raisonnement qui le dépasse. Le routage LLM consiste à éviter les deux, tâche par tâche.
Trois profils de tâches, trois réponses
Le triage rapide et à haut volume
Beaucoup de tâches sont simples, répétitives et massives : classer, filtrer, router, extraire une information bien définie. Elles se comptent en milliers d’appels, et ce qui compte est la latence et le coût unitaire, pas la profondeur de raisonnement. C’est le terrain de la famille la plus rapide et la plus économique, Haiku. Un modèle léger, bien cadré par un prompt précis, traite ces cas en une fraction de seconde et pour une fraction du coût.
La tâche de production courante
Entre les deux extrêmes se trouve le gros du travail réel : rédiger une réponse structurée, appeler des outils, suivre une procédure en plusieurs étapes, produire du code correct. Ces tâches demandent un bon équilibre entre qualité, vitesse et coût. C’est la place de la famille intermédiaire, Sonnet, qui atteint aujourd’hui un niveau proche du haut de gamme sur le code et les tâches agentiques, sans le coût du modèle le plus puissant. Pour la majorité des agents en production, c’est le point de départ raisonnable.
Le raisonnement long et les cas difficiles
Restent les tâches où la qualité prime sur tout : un diagnostic multi-sources, une analyse longue, un plan d’action complexe, un raisonnement qui doit tenir sur de nombreuses étapes sans se perdre. Là, le modèle le plus capable, Opus, justifie son coût. On y active un raisonnement approfondi, on lui laisse le temps et les tokens nécessaires, et on réserve cet usage aux cas qui le méritent réellement.
Un quatrième critère traverse ces trois profils : la latence. Un assistant interactif, avec lequel un humain dialogue en direct, ne tolère pas les mêmes temps de réponse qu’un traitement de fond exécuté la nuit. À qualité égale, un modèle plus rapide améliore l’expérience perçue autant qu’il réduit le coût. Le routage tient donc compte de trois axes à la fois : la difficulté de la tâche, son volume, et son exigence de temps de réponse.
Router n’est pas choisir une fois
Le routage n’est pas une décision figée prise au démarrage. C’est une logique qui s’exécute à chaque tâche. Un même agent peut trier une alerte avec un modèle rapide, puis, si le cas se révèle complexe, escalader vers un modèle plus puissant pour le diagnostic. On route selon la nature de la tâche, pas selon une préférence globale.
Cette escalade suppose de savoir reconnaître, tôt, qu’une tâche dépasse le modèle courant. C’est un critère de conception à part entière, au même titre que ceux d’un bon cadre d’évaluation : on ne route bien que ce que l’on sait mesurer. Sans mesure de la qualité par modèle et par type de tâche, on route à l’intuition, ce qui revient à ne pas router.
Attention toutefois : un prompt affiné pour une famille ne se transpose pas toujours tel quel sur une autre. Changer un modèle de route demande de revérifier son comportement sur des cas réels, comme n’importe quelle modification en production. La table de routage elle-même se gère comme une configuration versionnée, pas comme une constante.
Le routage, un levier de coût et de qualité
Bien routé, un parc d’agents coûte une fraction de ce qu’il coûterait si tout passait par le modèle le plus puissant, à qualité perçue égale. C’est l’un des leviers les plus efficaces du FinOps de l’IA agentique : le bon modèle au bon endroit réduit la facture sans que l’utilisateur s’en aperçoive.
Tous ces modèles étant disponibles sur Amazon Bedrock, le routage se fait au sein d’un même socle, avec la même gouvernance et la même traçabilité, ce qui le rend simple à exploiter. Cette discipline s’inscrit dans notre méthodologie d’industrialisation : choisir le modèle n’est pas un réglage ponctuel, mais une décision de conception, mesurée et révisable.
Vous voulez ajuster le coût et la qualité de vos services IA en routant mieux vos modèles ? Parlons-en.