« Quel est le meilleur modèle ? » est la question de celui qui n'en a pas encore mis un en production
La conversation commence toujours pareil. Quelqu'un ouvre un classement, montre la première place et demande si on construit l'agent avec celui-là. C'est une question légitime et elle est mal posée, parce qu'elle suppose qu'un agent utilise un modèle. Les agents qui tiennent en production n'en utilisent pas un : ils en utilisent plusieurs. Et la décision qui compte vraiment n'est pas lequel, c'est la répartition.
La raison est architecturale et ennuyeuse. Un agent ne fait pas une tâche : il fait une chaîne. Il lit un e-mail et détermine de quoi il s'agit. Il cherche dans ta documentation et en sort trois passages. Il rédige une réponse que va lire un de tes clients. Il décide si ça part seul ou si ça passe par une personne. Quatre étapes, quatre exigences différentes : classer un e-mail en six catégories est un problème résolu depuis des années ; rédiger ce que lit ton client, c'est là que tu joues ta réputation. Payer le modèle le plus cher pour les quatre étapes, c'est mettre ton meilleur avocat à faire des photocopies.
Ce n'est pas notre avis. Le guide d'OpenAI pour construire des agents le dit sans détour : les modèles ont des forces et des compromis différents en complexité de tâche, latence et coût, et toutes les tâches n'ont pas besoin du modèle le plus intelligent. Leur exemple est exactement celui du dessus : une simple récupération ou une classification d'intention peut être traitée par un modèle plus petit et plus rapide, tandis que décider d'approuver un remboursement bénéficie d'un modèle plus capable. Et ils recommandent d'envisager plusieurs modèles pour différentes tâches du même flux plutôt qu'un seul pour tout. Source : A practical guide to building agents, OpenAI, consulté le 12 septembre 2026.
Ce guide parle de prendre cette décision avec méthode : les trois axes qui décident vraiment, l'ordre dans lequel on les parcourt, comment se fait la répartition et quelle couche il faut monter pour qu'un changement de modèle ne soit pas un chantier. Ce qu'il n'est pas : un tableau des « meilleurs LLM de 2026 » — celui-là périme avant qu'on le publie — ni la facture de l'IA en production, qui est une autre conversation avec d'autres chiffres.
Les trois axes qui décident vraiment
Une fois le bruit écarté, le choix repose sur trois questions. Aucune des trois ne se règle en lisant la fiche du modèle : les trois se règlent en mesurant chez toi.
| Axe | La question à laquelle il répond | Comment le mesurer chez toi |
|---|---|---|
| Justesse sur ta tâche | Combien de mes cas réels sont bien traités ? | Une batterie de 30 à 50 cas à toi, avec la bonne réponse écrite à côté |
| Latence | Tient-il dans le canal où vit l'agent ? | Le 95e centile du temps de réponse, jamais la moyenne |
| Coût par cas résolu | Combien coûte la résolution de bout en bout ? | Coût du flux complet divisé par les cas résolus, pas le prix au million de tokens |
La justesse est l'axe que la plupart des gens sautent, parce que c'est celui qui demande du travail. « Justesse » n'est pas une note générale : c'est le pourcentage de TES cas qui sortent bien. L'obtenir demande la partie ennuyeuse — trente ou cinquante cas réels, de vrais e-mails avec leurs fautes et leurs pièces jointes bizarres, avec la bonne réponse écrite à côté. Sans cette batterie, tu ne choisis pas un modèle : tu as un avis sur les modèles, ce qui est autre chose et ne tient pas en réunion.
La latence n'est pas un nombre absolu : c'est un nombre face à un canal. Un chat sur ton site a un budget de quelques secondes parce qu'il y a quelqu'un devant l'écran. Un traitement nocturne qui rapproche des factures a toute la nuit. Le même modèle est rapide dans l'un et lent dans l'autre, donc « est-il rapide ? » ne veut rien dire tant que tu ne dis pas où. Anthropic le présente pour ce que c'est, un échange : les systèmes agentiques échangent souvent latence et coût contre de meilleures performances sur la tâche, et il faut décider quand cet échange en vaut la peine. Source : Building effective agents, Anthropic, 19 décembre 2024, consulté le 12 septembre 2026.
Le prix au million de tokens est un prix catalogue, pas ta facture. Un modèle pas cher qui a besoin de trois tentatives, laisse la moitié des champs vides et finit par escalader à une personne te revient plus cher qu'un modèle cher qui réussit du premier coup. La bonne unité est le cas résolu : coût total du flux — tous les appels, toutes les reprises, y compris celles de l'étape qui a échoué — divisé par les cas sortis corrects sans que personne n'y touche.
Le classement public ne sait rien de ton travail
Avec les trois axes sur la table, on comprend pourquoi le classement ne décide pas. Un classement public mesure un examen standardisé : questions de quiz, problèmes de code jouets, énigmes de logique. Ta tâche, ce n'est pas ça. Ta tâche, ce sont les e-mails de tes clients, ton jargon interne, tes PDF mal scannés et ta politique de retours, et aucune de ces quatre choses n'apparaît dans un tableau. On l'a développé en son temps : les benchmarks de LLM ne prédisent pas ton résultat.
Ce à quoi sert un classement public est l'inverse de ce qu'on en fait : il sert à écarter, pas à choisir. Il te dit quels modèles sont dans la conversation et lesquels sont restés deux générations en arrière, et ça t'évite d'en évaluer quinze. Ensuite, la liste courte — deux, trois — se classe avec ta batterie de cas. Cet ordre coïncide rarement avec le classement, et quand il coïncide, c'est une coïncidence sur laquelle tu ne peux pas parier la fois suivante.
La répartition : pas cher pour classer, cher pour décider
Le motif a un nom et il est documenté. Anthropic l'appelle le routage : une première étape classe l'entrée et la dirige vers le traitement spécialisé qui lui revient. Son intérêt, expliquent-ils, est de séparer les responsabilités et de pouvoir écrire des prompts plus spécialisés, car sans cette répartition, optimiser pour un type d'entrée dégrade les performances sur les autres. Et l'un des exemples qu'ils donnent est littéralement la répartition par coût : envoyer les questions faciles et courantes vers des modèles petits et économiques, et les difficiles ou inhabituelles vers des modèles plus capables. Source : Building effective agents, Anthropic, 19 décembre 2024, consulté le 12 septembre 2026.
Traduit aux étapes d'un agent typique, la répartition tombe en général comme ça. La colonne de droite est un point de départ, pas une loi :
| Étape de l'agent | Ce qu’elle exige vraiment | Où ça tombe en général |
|---|---|---|
| Classer l'entrée et router | Constance et vitesse sur un ensemble fermé de catégories | Petit modèle |
| Extraire des champs d'un document | Format stable ; l'erreur se détecte par validation | Petit modèle avec contrat de sortie |
| Chercher et résumer dans tes documents | Fidélité à la source ; la qualité de la récupération domine | Modèle intermédiaire |
| Décider sur l'argent, les personnes ou des données régulées | Jugement et nuance ; l'erreur se paie en euros ou en réputation | Modèle le plus capable |
| Rédiger ce que va lire un client | Ton, précision et zéro invention | Modèle le plus capable |
Le seul juge de ce tableau, c'est ton ensemble de cas. Il y a des classifications à vingt catégories qui se chevauchent où le petit modèle coule, et des rédactions si cadrées — un accusé de réception à trois variables — que le petit est surdimensionné. C'est pour ça que la répartition se décide en mesurant, et se revoit quand le catalogue de modèles change ou quand ton volume change.
Une nuance qui évite des ennuis : le routage ne vaut le coup que si les catégories sont réellement distinctes et si la classification peut être faite avec précision. C'est la condition qu'Anthropic pose à ce motif, et c'est celle qui casse quand quelqu'un glisse un routeur là où il n'en fallait pas. Si le classifieur se trompe, tu n'as rien économisé : tu as mis un nouveau point de défaillance devant tout le reste, et un point silencieux, parce qu'une entrée mal routée ne renvoie pas une erreur — elle renvoie une réponse assurée du mauvais type.
Le bon ordre : commence par le cher et descends jusqu'à ce que ça se voie
La répartition claire, reste le comment. Le guide d'OpenAI propose une recette qui va contre l'instinct de tout le monde : construire le prototype avec le modèle le plus capable pour chaque tâche afin d'établir une ligne de base de performance, puis essayer d'y substituer des modèles plus petits pour voir s'ils donnent encore un résultat acceptable. Ses principes, dans cet ordre : mettre en place des évaluations pour établir la ligne de base, atteindre l'objectif de justesse avec les meilleurs modèles disponibles, et seulement ensuite optimiser coût et latence en remplaçant les grands par des petits là où c'est possible. Source : A practical guide to building agents, OpenAI, consulté le 12 septembre 2026.
- Monte la batterie de cas avant de toucher à l'agent. Trente ou cinquante, réels, avec la bonne réponse à côté. C'est l'étape que tout le monde saute et celle qui décide si le reste sert à quelque chose.
- Construis l'agent entier avec le modèle le plus capable à chaque étape. Tu n'optimises pas encore : tu vérifies si ton objectif de justesse est seulement atteignable.
- Mesure contre la batterie. Si tu n'y arrives pas ici, le problème n'est pas le modèle : c'est le prompt, tes données, la récupération ou la tâche — et descendre de modèle ne fera que le cacher.
- L'objectif atteint, descends d'un cran à la fois et repasse la batterie. Un changement, une mesure. Deux changements d'un coup et tu ne sais plus lequel.
- Arrête-toi au cran d'avant celui qui casse. Et écris quelle étape utilise quel modèle et avec quelle justesse mesurée, parce que dans trois mois personne ne s'en souviendra.
La raison de ne pas faire l'inverse est diagnostique, pas dogmatique. Si tu commences par le modèle pas cher et que l'agent ne marche pas, tu as quatre suspects et aucun moyen de les séparer : ça peut être le modèle, le prompt, tes données, ou une tâche qui n'a jamais été bien définie. En partant du haut, quand quelque chose casse en descendant tu sais exactement ce qui l'a cassé, parce que tu n'as changé qu'une chose.
La couche qui te permet de changer de modèle sans toucher à l'agent
Tout ce qui précède a une date de péremption. Le catalogue de modèles tourne tous les quelques mois, les prix bougent et les fournisseurs déprécient des versions. Si la décision d'aujourd'hui est écrite dans l'agent — le nom du modèle répété à sept endroits du code —, dans six mois tu ne pourras pas la refaire, et tu finiras avec le problème qu'on décrit dans changer de modèle sans casser tes automatisations : le flux ne casse pas avec une erreur, il casse avec un autre format et un autre ton, en silence.
La couche qui l'évite, c'est cinq pièces, et aucune n'est sophistiquée :
- Une seule fonction qui appelle le modèle. Tous les appels y passent. S'il y a sept endroits dans le code avec un nom de modèle dedans, tu as déjà de la dette.
- L'identifiant du modèle, en configuration. Un fichier avec le modèle de chaque étape. Changer de modèle doit être changer une ligne, pas ouvrir l'agent.
- Un contrat de sortie validé. Avant que le résultat ne touche un système, on vérifie qu'il a la forme convenue. C'est ce qui transforme un changement de format silencieux en erreur visible.
- La batterie de cas, exécutable en une commande. Si tester un nouveau modèle coûte une demi-matinée de travail manuel, personne ne le testera.
- Un journal de quel modèle a traité quel cas. Sans ça, tu ne peux ni comparer l'avant et l'après d'un changement, ni expliquer pourquoi la semaine dernière ça marchait mieux.
Ce n'est pas une optimisation facultative qu'on renvoie en phase deux. C'est la différence entre choisir un modèle aujourd'hui et pouvoir rechoisir dans six mois. Quand cette couche n'existe pas, la décision de modèle se prend une fois et s'hérite pour toujours, exactement la mauvaise forme pour un système qui vit dans un marché qui bouge chaque trimestre.
Le tableau de répartition : une page, avec un propriétaire et une date
La fin est la même que dans les instructions d'un agent IA : si la décision n'est pas écrite, elle n'existe pas. Une page suffit, et elle doit répondre à ces cinq choses.
- Quel modèle utilise chaque étape, avec une ligne de pourquoi et la justesse mesurée contre la batterie le jour de la décision.
- Ce qui a été testé et écarté. Le candidat qui n'est pas passé et la raison. Sans ça, quelqu'un le retestera de zéro dans quatre mois.
- Qui signe. Une personne avec un nom. Un tableau sans propriétaire n'est jamais revu.
- Ce qui déclenche une revue : l'arrivée d'un modèle nouveau et pertinent, la dépréciation par le fournisseur de celui que tu utilises, un volume qui change d'ordre de grandeur, ou une justesse mesurée qui baisse.
- Prochaine revue. Une date, même s'il ne s'est rien passé. La décision périme toute seule et personne ne prévient.
Si ton agent est déjà en production et que cette page n'existe pas, commence par les étapes qui touchent à l'argent : quel modèle décide un remboursement, quel modèle rédige ce que lit ton client, et avec quelle justesse mesurée. Le reste peut attendre une semaine.
Nous montons cette couche avant l'agent : appel isolé, modèle en configuration, contrat de sortie et batterie de cas exécutable, dans le cadre de l'infrastructure d'IA pour l'entreprise sur laquelle se construisent ensuite les employés IA. C'est la partie que personne ne montre en démo et la seule qui décide si, dans un an, tu changes de modèle en un après-midi ou tu refais le système. La logique complète est dans créer un agent IA qui tient en production.