Choisir son modèle IA selon la tâche, le plus gros perd

Le 7 août 2026, une équipe menée par Tao Feng a publié LLMRouter, avec son code en accès libre. L’objet est simple. Comparer, sur un même terrain, les façons de choisir quel modèle traite quelle demande.

L’ouverture du résumé pose déjà le sujet. Aucun modèle de langage n’est optimal sur toutes les demandes et sous toutes les contraintes de budget.

Le terrain s’appelle xRouteBench. Il compte 4767 cas de test et un vivier de 18 modèles ouverts, de 7 à 671 milliards de paramètres. Plus de 16 stratégies de routage sont fournies dans la bibliothèque, dont 12 sont comparées sur le tronc commun.

LES CHIFFRES, ET CE QU'ILS COMPARENT EXACTEMENT

  45,46   Le meilleur routeur, en moyenne sur les
          4 pistes du banc d'essai.
  38,72   Le plus gros modele appele a chaque fois.
  -> soit +17,4 % pour le routage.

  +14,6 % Le chiffre du resume. Il porte sur la
          seule piste des taches generiques, ou le
          meilleur routeur fait 80,56 contre 70,29.

  ⚠ Ce sont 2 comparaisons differentes. Beaucoup
    d'articles vont melanger les 3 nombres. Le
    +14,6 % ne se deduit PAS de 45,46 et 38,72.

  ⚠ Ces scores viennent du reglage ou seule la
    qualite compte, le cout y pese zero. L'argument
    du prix vient d'ailleurs, de la frontiere
    qualite-cout de l'etude.

La phrase des auteurs sur le plus gros modèle mérite d’être donnée en entier, parce que sa seconde moitié est le vrai argument. Appeler toujours le plus gros modèle coûte le plus cher pour une performance médiocre, puisque beaucoup de demandes qu’il rate sont résolues par des modèles plus petits et moins chers.

Dans le même tableau, il y a une ligne dont on parle peu, et c’est la plus parlante.

Le vivier va de 7 à 671 milliards de paramètres, soit un facteur 96 entre le plus petit et le plus gros modèle.

LE PLUS GROS CONTRE LE PLUS PETIT

  38,72   Toujours appeler le PLUS GROS des 18.
  37,94   Toujours appeler le PLUS PETIT des 18.

  ECART   0,78 point. Moins de 2 pour cent.

  ⚠ Entre le geant et le nain, appeles aveuglement,
    il n'y a presque rien. C'est la meilleure
    preuve que la puissance brute n'est pas ce qui
    decide du resultat.

Il n’y a pas de paradoxe. Un très gros modèle est le meilleur en moyenne. Sur une demande donnée, il ne l’est pas forcément, et il est toujours le plus cher. Additionnez ces 2 faits sur des milliers de demandes, et l’écart s’efface.

⚠ Une idée reçue que l’étude contredit au passage. On lit partout que les gros modèles restent imbattables sur le raisonnement. Sur les 2 épreuves de raisonnement visuel du banc d’essai, le plus gros modèle fait 37,70 quand le routage fait 42,62, et 33,00 quand le routage fait 50,00. Même sur le difficile, appeler le plus gros n’est pas la bonne stratégie.

C’est la mesure derrière une intuition que nous écrivions déjà sans preuve dans ce qui fait qu’un agent IA tient. Un modèle moyen bien encadré rend un meilleur service qu’un modèle excellent laissé sans outils.

Ici je sépare nettement ce que l’étude mesure de ce que nous en déduisons, parce que la nuance est facile à écraser.

Ce que l’étude observe. Quand la contrainte de coût se resserre, le classement des routeurs s’inverse en faveur des conceptions les plus légères. Un mécanisme de choix très simple, dernier du classement quand seule la qualité compte, devient le meilleur dès que le budget pèse dans la note.

⚠ Attention au vocabulaire, il piège. Un routeur léger, c’est le petit mécanisme qui choisit, pas le petit modèle qui répond. Ce sont 2 choses différentes, et beaucoup d’articles vont les confondre.

Notre lecture, et elle nous engage. L’étude ne compare jamais router à ne pas router selon le budget. Elle ne dit donc pas que le routage rapporte plus quand on est petit. En revanche, elle montre que les mécanismes simples suffisent sous contrainte. Nous en concluons qu’une table de routage écrite à la main est le bon niveau d’investissement pour une PME, et qu’il n’y a pas besoin d’un système appris pour prendre l’essentiel du gain.

Un second effet, moins évident, joue dans le même sens. Un modèle plus léger répond plus vite. Sur un agent qui traite 200 messages par jour, la différence de délai se voit à l’usage bien avant de se voir sur la facture, et le sujet rejoint ce que coûte réellement un agent IA.

La logique va plus loin depuis septembre 2026. Des modèles ont été conçus pour ne faire que choisir, sans jamais rédiger. C’est le cas de Jev, le modèle de décision de TypeSafe AI, qui trie ou classe à une fraction du prix d’un modèle généraliste. Ses propres chiffres de vitesse restent à prendre avec prudence, et les mesures indépendantes disent autre chose.

Le prix bas a parfois une contrepartie qui n’apparaît pas sur la facture. En septembre 2026, Muse Code de Meta propose un palier contributeur 12,5 à 21 fois moins cher que son tarif standard, en échange de l’usage de vos échanges pour entraîner ses modèles, et avec un débit bridé. Son modèle reste derrière Claude Opus 5 sur les 3 tests publiés par Meta elle-même. Un modèle bon marché se choisit pour les tâches simples et non confidentielles, pas pour le code ou les données sensibles. Voir Meta Muse, l’agent IA personnel de Meta.

C’est le résultat le plus contre-intuitif de l’étude, et celui qu’il faut lire avec le plus de soin.

Les routeurs qui procèdent en plusieurs tours obtiennent des scores très inférieurs à ceux qui décident en un seul.

UN SEUL TOUR CONTRE PLUSIEURS TOURS

  41,03   Moyenne des 9 routeurs a un seul tour.
          45,46 pour le meilleur d'entre eux.
  22,62   Moyenne des 3 routeurs a plusieurs tours.

  ⚠ Un facteur 1,8, pas un facteur 2. Et parmi les
    routeurs a un tour, le moins bon fait 36,32,
    donc MOINS que le plus gros modele seul. Tous
    les routages ne se valent pas.

Les 2 causes données par les auteurs, et la seconde est décisive. D’abord, les tours supplémentaires ajoutent de l’information redondante et un surcoût de calcul. Ensuite, et c’est ce qui change tout, ces montages s’appuient sur un modèle de base de 3 milliards de paramètres chargé de découper les demandes puis de recoller les réponses. Leur performance dépend donc des capacités de ce petit modèle.

⚠ Ce que l’étude conclut vraiment. Elle écrit que le routage à plusieurs tours ne surpasse pas systématiquement le routage à un tour. C’est une absence de gain démontré, pas une défaite démontrée. La nuance compte, et beaucoup vont la perdre.

⚠⚠ Et surtout, ne confondez pas 2 choses très différentes. Ce qui est mesuré ici, ce sont des tours où l’on repasse la même demande sans que chaque étape ait un rôle propre. Un relais à rôles écrits, un qui rédige, un qui critique sans réécrire, un qui tranche avec une condition d’arrêt, n’a rien à voir et n’est pas mesuré par cette étude. Nous le détaillons dans plusieurs IA en relais. La ligne de partage n’est pas le nombre de modèles, c’est de savoir si chaque étape a une consigne à elle.

Pas besoin d’un système de routage appris pour prendre l’essentiel. Une table écrite suffit, et elle se relit.

{
  "extraction_facture": {
    "modele": "petit",
    "pourquoi": "reponse contrainte et verifiable",
    "repli": "moyen"
  },
  "tri_des_messages": {
    "modele": "petit",
    "pourquoi": "categorie dans une liste connue",
    "repli": "moyen"
  },
  "redaction_reponse_client": {
    "modele": "moyen",
    "pourquoi": "ton et nuance, pas de calcul",
    "repli": "gros"
  },
  "analyse_de_contrat": {
    "modele": "gros",
    "pourquoi": "raisonnement en plusieurs etapes",
    "repli": null
  }
}

Le champ repli est celui qui compte le plus, et c’est celui qu’on oublie. Il dit vers quoi basculer quand le modèle choisi échoue. Sans lui, une table de routage devient une source de pannes silencieuses.

La logique qui lit cette table tient en quelques lignes.

# routage.py -- choisir le modele selon la tache
import json

TABLE = json.load(open("routage.json"))
PRIX = {"petit": 1, "moyen": 6, "gros": 30}  # relatif

def modele_pour(tache, deja_echoue=False):
    regle = TABLE.get(tache)
    if regle is None:
        return "moyen"          # defaut prudent
    if deja_echoue and regle["repli"]:
        return regle["repli"]
    return regle["modele"]

def cout_relatif(tache):
    return PRIX[modele_pour(tache)]

⚠ Le défaut prudent est important. Une tâche que personne n’a classée ne part pas vers le modèle le plus cher par sécurité, elle part vers le modèle moyen. Sinon, chaque oubli de classement devient une ligne sur la facture.

Choisir le bon modèle ne règle que la moitié du problème. Les modèles récents portent un second bouton, le niveau d’effort, qui fixe combien le modèle raisonne avant de répondre. Il va de low à max, et presque personne ne le touche.

Le dernier exemple en date le montre bien. Anthropic a sorti Claude Opus 5.5 le 22 septembre 2026, à 4 dollars par million de jetons en entrée et 20 dollars en sortie. Son effort par défaut est medium, un cran sous celui d’Opus 5. Et Anthropic écrit qu’à cet effort par défaut, il bat GPT-6 Astra réglé à l’effort maximal, pour environ un cinquième du coût par tâche.

⚠ Ce sont les chiffres de l’éditeur, et ils ne disent pas tout. Opus 5.5 atteint 66,4 % sur Terminal-Bench 4.0, mais en effort xhigh, pas en effort par défaut. Et sur Terminal-Bench-Science, GPT-6 Astra reste devant, 64,6 % contre 58,7 %. La page d’Anthropic reconnaît elle-même qu’à ce niveau, les écarts de banc d’essai deviennent un guide moins fiable des différences réelles.

Les premiers testeurs rapportent une observation plus utile que le classement, et nous la donnons comme leur lecture, pas comme une mesure officielle. Sur le code, passé high, le score ne progresse plus au-delà de la marge d’erreur. Sur l’analyse de documents et la recherche, il continue de monter jusqu’en haut de l’échelle.

D’où la règle. Réglez l’effort selon la nature de la tâche, pas selon son importance. Un correctif urgent sur un site en panne n’a pas besoin de max, il a besoin de high. Une synthèse de 40 contrats, même sans enjeu immédiat, gagne à monter plus haut.

| Tâche | Effort conseillé | Pourquoi | |---|---|---| | Tri de messages, extraction, classement | low | réponse courte et vérifiable | | Rédaction courante, réponse client | medium | le défaut d’Opus 5.5 suffit | | Code, correction de bug | high | au-delà, gain dans la marge d’erreur selon les testeurs | | Analyse de documents longs, recherche | xhigh ou max | le score continue de monter |

Ce tableau est notre point de départ, pas une vérité. Mesurez-le sur vos cas avec la méthode de la section suivante, effort par effort, comme vous le feriez modèle par modèle.

Dans l’API de Claude, l’effort se règle par le champ effort, placé dans output_config. Sur Opus 5.5, le raisonnement ne se coupe plus, c’est donc le seul bouton qui reste pour doser la dépense.

# effort.py -- regler l'effort selon la nature de la tache
import anthropic

client = anthropic.Anthropic()  # lit ANTHROPIC_API_KEY

EFFORT = {
    "tri_des_messages": "low",
    "redaction_reponse_client": "medium",
    "correction_de_code": "high",
    "analyse_de_documents": "xhigh",
}

def demander(tache, texte):
    reponse = client.messages.create(
        model="claude-opus-5-5",
        max_tokens=16000,
        output_config={"effort": EFFORT.get(tache, "medium")},
        messages=[{"role": "user", "content": texte}],
    )
    if reponse.stop_reason == "refusal":
        return None
    return next(b.text for b in reponse.content if b.type == "text")

⚠ Le défaut vaut medium, pour la même raison que le modèle moyen dans la table de routage. Une tâche que personne n’a classée ne doit pas partir au prix fort. Et si vous passez d’Opus 5 à Opus 5.5 sans rien régler, vous descendez d’un cran sans le savoir, parce que le défaut n’est plus le même.

Pour situer Opus 5.5 parmi les sorties de l’année, notre frise de l’évolution des modèles d’IA les range par date, avec ce que chacune a changé.

Un classement générique ne vous dira jamais quel modèle convient à votre travail. Il faut mesurer, et c’est plus rapide qu’on ne croit.

La méthode tient en 4 étapes. Prenez 20 demandes réelles, représentatives de ce que vous faites. Faites-les traiter par 2 ou 3 modèles. Notez la qualité de chaque réponse. Relevez le coût et le délai.

#!/usr/bin/env bash
# comparer-modeles.sh
# Rejoue 20 demandes reelles sur plusieurs modeles
# et ecrit un journal comparable.
# Fournissez votre propre appeler-modele.sh, qui
# prend un modele et un fichier, et rend le cout.
set -euo pipefail

MODELES="petit moyen gros"
: > comparaison.csv
echo "demande;modele;cout;duree_ms" >> comparaison.csv

for d in demandes/*.txt; do
  for m in $MODELES; do
    debut=$(date +%s%3N)
    cout=$(./appeler-modele.sh "$m" "$d")
    fin=$(date +%s%3N)
    echo "$(basename "$d");$m;$cout;$((fin-debut))" \
      >> comparaison.csv
  done
done

echo "Fait. Notez maintenant la QUALITE a la main,"
echo "une colonne de plus, de 0 a 3. C'est la seule"
echo "partie que la machine ne peut pas faire."

⚠ La dernière ligne du script est la plus importante. La qualité se note à la main. Un modèle qui juge un autre modèle introduit exactement le biais dont on cherche à se protéger, et vous obtiendrez le classement qui vous arrange.

Ce que vous cherchez dans le tableau final n’est pas le meilleur modèle. C’est la plus petite marche qui suffit pour chaque type de tâche.

Un mot d’honnêteté pour finir, parce que ce genre de résultat se déforme vite.

C’est un banc d’essai, pas votre activité. Les 4767 cas de xRouteBench couvrent du raisonnement, de la mémoire longue, de la vision et des préférences personnelles. Votre mélange à vous est différent. Les 17,4 pour cent sont un ordre de grandeur crédible, pas une promesse.

Tous les routages ne se valent pas. Le moins bon des mécanismes testés fait moins bien que le plus gros modèle appelé aveuglément. Router mal est pire que ne pas router.

Et le résultat ne dit pas que la puissance ne compte plus. Il dit qu’elle ne se paie pas au même prix partout, et que 0,78 point sépare le géant du nain quand on les appelle sans réfléchir.

Pour une PME, la traduction est immédiate. Vous n’avez pas besoin du meilleur modèle du moment. Vous avez besoin de savoir lequel envoyer où, et de pouvoir le prouver sur vos propres cas.