SynergetikIntégration d'IA agentique

Quel modèle brancher, sur quelle tâche, à quel prix.

Grille de décision pour le choix des modèles, dans deux contextes qui n'obéissent pas aux mêmes règles : nos agents internes, routés via OpenRouter, et le delivery client, où l'accès se fait en direct chez l'éditeur ou sur des poids que nous servons nous-mêmes. Choisissez le contexte et le cas d'usage, la grille classe les modèles selon l'arbitrage coût d'abord, qualité ensuite, latence en dernier recours. Tarifs en dollars par million de tokens.

01 · Cas d'usage

Sur quelle tâche ?

02 · Échelle de prix

Position sur l'échelle de prix échelle logarithmique · hauteur = adéquation au cas retenu

Survolez un repère pour voir le modèle correspondant.

Un écart de cent contre un sépare le plancher du marché du haut de gamme. Le choix du modèle reste le premier levier de budget, avant toute optimisation de prompt ou de cache.

03 · Réglages

Contexte et filtres

04 · Verdict

Pour ce cas d'usage

05 · Classement

Sélection filtrée

# Modèle Adéquation Entrée Sortie Prix moyen $ / mois Contexte Vitesse Commentaire

06 · Catalogue

Tous les modèles tous les modèles de la base, hors filtres de sélection

Cliquez sur un en-tête pour trier. La colonne souveraineté porte la licence des poids en seconde ligne, et le nom de l'éditeur renvoie vers sa page tarifaire officielle. Ce tableau ignore les filtres de palier, de poids ouverts, d'origine, de souveraineté et d'adéquation minimale du bloc 3. Il reprend en revanche la même convention de prix moyen et la même option de frais OpenRouter, pour rester cohérent avec le classement ci-dessus.

07 · Limites

Ce que la grille ne dit pas

Le prix affiché n'est pas le prix payé

Quatre écarts systématiques entre la ligne tarifaire et la facture réelle :

  • Les tokens de raisonnement sont facturés en sortie. Sur un modèle à réflexion, la partie invisible dépasse souvent la réponse visible. C'est la première cause de sous-estimation d'un budget.
  • Le contexte est refacturé à chaque tour. Une boucle d'agent renvoie tout l'historique à chaque itération. Une tâche de dix tours coûte bien plus que dix fois le premier appel.
  • Le cache change les classements. Lecture à 0,1x chez Anthropic et DeepSeek, 0,25x chez Google et xAI, 1 $ sur GPT-6 Astra. En revanche l'écriture coûte 1,25x à 2x : le cache ne devient rentable qu'à partir de la deuxième relecture, et il casse silencieusement si le préfixe stable change d'ordre.
  • Le paramètre max_price est votre garde-fou. Posé sur chaque requête de production, il refuse l'appel au lieu de laisser filer la note.

Le mélange entrée / sortie décide du classement

Le prix moyen n'a de sens que rapporté à la forme réelle du trafic, et cette forme change radicalement d'un usage à l'autre. Quatre sessions OpenCode mesurées sur agent-factory-os donnent la mesure du phénomène :

  • Session agentique sur MiniMax M3 : 171 225 tokens d'entrée pour 493 de sortie, soit 0,3 % de sortie.
  • Session de création de tâches : 42 556 contre 671, soit 1,6 % de sortie.
  • Session Claude Opus 5 avec raisonnement lourd : 86 902 contre 9 510, soit 9,9 % de sortie, le maximum observé.
  • Session Claude Opus 5 de revue : 112 058 contre 791, soit 0,7 % de sortie.

Autrement dit, une boucle d'agent est un usage d'entrée à 90 ou 99 %, pas à 75 %. À l'inverse, rédiger un post à partir d'un brief de trois lignes inverse complètement le rapport. C'est pourquoi le curseur couvre désormais toute l'amplitude, de 100 % entrée à 100 % sortie, et pourquoi il se règle par défaut sur la valeur attendue du cas d'usage retenu. Décochez l'automatique pour tester votre propre profil de trafic : sur un usage d'entrée pur, ce sont les modèles à entrée bon marché qui remontent, et l'écart de prix de sortie entre Grok 4.6 et Claude Fable 5.1 cesse d'avoir la moindre influence.

Une limite assumée de la grille sur ces mêmes sessions : trois d'entre elles passent 94 à 99,9 % de leur entrée en lecture de cache, facturée entre 10 et 25 % du tarif plein selon l'éditeur. Le prix moyen affiché ici est donc un plafond, pas une prévision. Sur une boucle d'agent bien cachée, la facture réelle peut tomber au quart.

Ce qui décide vraiment sur OpenRouter

  • Le markup par token est nul. Le coût est de 5,5 % au rechargement par carte, 5 % en crypto, et zéro en BYOK sous 25 000 $ de consommation mensuelle. Dès que vous détenez une clé éditeur, passez en BYOK : vous gardez le routage, les bascules et les statistiques, sans les frais.
  • Le routage par défaut trie par prix et pondère en inverse du carré : un hébergeur trois fois moins cher est neuf fois plus susceptible d'être choisi. Sur les modèles à poids ouverts c'est un avantage, sur un modèle sensible c'est un risque de quantification non documentée. Utilisez only ou ignore pour verrouiller.
  • Trois modes de routage existent désormais : équilibré, :nitro pour le débit, et un mode orienté précision d'appel d'outils. Sur un agent qui enchaîne des outils, la précision d'appel pèse plus lourd que le prix du token.
  • data_collection: "deny" exclut les hébergeurs susceptibles d'entraîner sur vos prompts. À poser par défaut sur toute mission client. Attention : zdr: true échoue sur les modèles Anthropic, qui n'offrent pas de rétention zéro.
  • Les variantes :batch sont à moitié prix chez Anthropic, OpenAI et Google. Tout ce qui tolère un délai de 24 heures doit y passer.

Deux contextes, deux grilles de lecture

Le sélecteur en tête du bloc 3 ne fait pas que changer un calcul de frais, il change ce que le tableau signifie.

  • Agents internes. OpenRouter est l'hypothèse par défaut. Ce qui compte : le prix effectif après routage, la disponibilité de variantes par lot, la bascule automatique quand un hébergeur tombe. Le plancher à 0,05 $ obtenu sur DeepSeek via des hébergeurs tiers est un vrai gain ici, à condition de tester la qualité, aucune quantification n'étant documentée par hôte.
  • Delivery client, API directe. OpenRouter sort du schéma. Un intermédiaire américain de plus dans la chaîne est difficile à défendre devant un client qui pose des questions de conformité, et impossible à défendre devant un client souverain. Les tarifs de la grille restent valables, mais comme base de négociation d'un contrat de gré à gré, pas comme prix final. Deux postes qui n'apparaissent pas dans le tableau et qui se négocient en même temps : les limites de débit, qui conditionnent le dimensionnement, et le SLA, qui décide de ce que vous pouvez vous engager à tenir.
  • Delivery client, poids auto-hébergés. Le prix par token disparaît. Le coût devient une facture GPU, fixe, indépendante du volume, et la question n'est plus combien coûte le token mais quelle machine il faut. Les quatre colonnes tarifaires sont donc remplacées par la taille du modèle, sa part active, l'empreinte du checkpoint et le matériel minimum. Le classement bascule d'office sur l'adéquation pure, et la sélection se limite aux modèles à poids ouverts.

Le piège de l'auto-hébergé

Un modèle à poids ouverts n'est pas un modèle gratuit, c'est un modèle dont le coût change de nature. En dessous de quelques centaines de millions de tokens par mois, une API en direct revient presque toujours moins cher qu'un nœud GPU amorti, et sans l'astreinte d'exploitation. L'auto-hébergement se justifie par la souveraineté, par la prévisibilité de la facture, ou par un volume qui remplit vraiment la machine, rarement par le prix seul.

Deuxième piège, propre aux architectures MoE : la part active détermine la vitesse, le total détermine la mémoire. GLM-5.3 n'active que 39 des 744 milliards de paramètres, ce qui le rend rapide par token, mais les 744 doivent tenir en mémoire, soit 756 Go en FP8 et un nœud de huit cartes. La colonne « actifs » ne dit rien du matériel nécessaire, la colonne « paramètres » si.

Les quatre classes retenues : poste de travail pour ce qui tourne sur une carte grand public, une carte 80 Go pour le palier au-dessus, nœud multi-GPU pour deux à huit cartes dans une même machine, cluster multi-nœuds au-delà. L'écart est brutal : Ministral 3 8B tient sur un poste de travail, Kimi K3 réclame 1,56 To de poids et au moins soixante-quatre accélérateurs. Les deux sont pourtant étiquetés « poids ouverts ».

Deux corrections importantes issues de cette passe de vérification. Mistral Large 3 est sous Apache 2.0, 675 milliards de paramètres dont 41 actifs : il était classé à tort comme propriétaire, c'est en réalité le meilleur candidat souverain auto-hébergeable du tableau. Et GLM-5.3 n'est plus sous MIT, contrairement à sa variante Flash, mais sous une licence propre à Z.ai qu'il faut lire avant tout déploiement client.

Souveraineté : deux axes, pas une échelle

Le mot recouvre deux exigences distinctes, et un client qui dit « souverain » ne précise presque jamais laquelle il vise. Posez la question avant de proposer.

  • Qui opère le traitement. C'est l'axe juridique, celui de la doctrine cloud de confiance et de la qualification SecNumCloud. Un éditeur établi dans l'Union, un contrat de droit européen, aucune exposition au CLOUD Act. Sur cet axe, un modèle que vous servez vous-même bat encore l'API de l'éditeur, puisqu'il n'y a plus de tiers du tout.
  • D'où viennent les poids. C'est l'axe industriel. Mistral gagne partout, un Qwen ou un GLM perd même exécuté à Roubaix. Certains acheteurs publics refusent l'origine indépendamment du lieu d'exécution, d'autres ne regardent que le flux de données.

D'où le seul point du marché qui gagne sur les deux axes à la fois : les modèles Mistral à poids ouverts, servis sur une infrastructure française. Mistral Small 4, Ministral 3 8B et Devstral 2 couvrent respectivement le généraliste, l'embarqué et le code, sans coût par token. C'est le socle de l'offre souveraine.

Le filtre propose donc deux niveaux. Souverain strict ne garde que les éditeurs établis dans l'Union, sept modèles, tous Mistral. Souverain élargi y ajoute les poids ouverts déployables sur votre infrastructure, dix-neuf modèles au total, en acceptant une provenance hors UE. Tout le reste est hors périmètre : Azure, Vertex et Bedrock offrent des régions européennes, ce qui donne une résidence des données, pas une souveraineté, l'opérateur restant soumis au droit américain. Présentez-le comme tel, la nuance se retourne vite contre celui qui l'efface.

Dernier point sur les poids ouverts : la licence décide de ce que vous avez le droit de faire. La colonne du catalogue la donne et signale par « a verifier » les modèles dont la licence n'est pas sourcée au niveau de la version. À trancher avant tout engagement contractuel.

Architecture de routage recommandée

Aucun agent sérieux ne tourne sur un seul modèle. Le schéma qui tient en production sépare trois étages : un modèle micro qui trie et pré-traite, un intermédiaire qui exécute la majorité des tours, un frontière appelé uniquement sur les décisions difficiles ou après deux échecs. Sur un volume de 240 M tokens d'entrée et 90 M de sortie par mois, l'écart entre le haut et le bas du tableau dépasse un facteur soixante, à trafic identique.

Ce découpage en trois étages vaut dans les deux contextes. En interne il s'implémente avec les règles de routage d'OpenRouter. En delivery il devient une décision d'architecture : trois fournisseurs à contractualiser, ou un modèle auto-hébergé pour les deux premiers étages et une API en direct pour le troisième. Sur ce dernier schéma, Mistral Large 3 à 0,50 $ / 1,50 $ reste le meilleur compromis souveraineté-prix du marché.

08 · Données

Mise à jour des données

Les données vivent dans un repo GitHub dédié, data-routeo, dans un fichier unique modeles.json. L'application les charge en direct à chaque visite (GitHub raw, CORS natif) : aucune reconstruction du site n'est nécessaire quand les tarifs bougent. Le JSON embarque trois objets qui rendent la mise à jour autonome :

  • meta.schema liste les valeurs autorisées de chaque champ énuméré, définit les trois niveaux de souveraineté, sépare les champs libres des champs verrouillés et énonce les règles à respecter.
  • meta.sources_editeurs donne l'URL de la page tarifaire officielle de chacun des douze éditeurs. L'agent va directement à la source au lieu de chercher.
  • meta.changelog accumule un enregistrement par passage. Un agent qui reprend le fichier six mois plus tard sait ce qui a bougé, quand, et sur la foi de quelle source.

Chaque modèle porte en plus son propre champ verifie_le, ce qui permet de rafraîchir ligne par ligne plutôt qu'en bloc et de repérer les entrées qui ont décroché.

Le flux automatisé : réconciliation machine

Un workflow GitHub Actions tourne chaque jour à 06h00 UTC dans le repo de données. Il interroge l'API publique d'OpenRouter (tarifs et contextes de tous les modèles), fournit cet extrait machine au modèle de réconciliation avec le jeu de données courant, puis valide strictement la réponse (valeurs autorisées, prix numériques, champs verrouillés inchangés, aucun modèle supprimé, entrée de changelog datée du jour) avant écriture. Le résumé de chaque run liste les écarts — modèle, champ, ancienne valeur, nouvelle valeur — et les modèles sans correspondance OpenRouter. En cas d'échec de validation, rien n'est écrit. Un appel d'API n'ayant pas d'accès web, le modèle ne visite aucune page : il réconcilie des données qu'on lui fournit — si une source manque, il doit refuser plutôt qu'inventer.

Cadence : quotidienne. Sur le seul trimestre écoulé, GPT-5.6 Luna a baissé de 80 %, Terra de 20 %, Sonnet 5 a vu une hausse programmée annulée, DeepSeek a introduit une tarification heure pleine et heure creuse, et deux modèles frontière sont sortis à 50 $ de tokens de sortie. Une grille non datée est une grille fausse.

La passe éditoriale

Le rapprochement machine couvre les prix et les contextes, pas les nuances : statuts promotionnels, notes, licences, modèles absents d'OpenRouter (les Mistral du catalogue, par exemple). Une passe humaine hebdomadaire est conseillée : le panneau en haut de page (bouton « Mettre à jour les données ») copie la consigne ci-dessous et les données actuelles, à coller dans une conversation avec un agent qui a accès au web — lui, visite réellement les pages des éditeurs. Le JSON renvoyé est ensuite poussé dans le repo de données, par commit ou par PR.

Voici un jeu de données JSON de suivi tarifaire de modèles LLM. Lis d'abord meta.schema, qui donne les valeurs autorisées, les champs verrouillés et les règles, puis meta.sources_editeurs, qui donne la page tarifaire officielle de chaque éditeur. Pour chaque modèle, vérifie prix_entree, prix_sortie, contexte, statut et licence sur la page de son éditeur, recoupe avec openrouter.ai/models, puis mets son champ verifie_le à la date du jour. Respecte strictement les valeurs autorisées et écris toutes les valeurs sans accents. Ne touche ni aux scores, ni à souverainete, ni aux champs de dimensionnement sans source datée. Mets à jour meta.date_verification, incrémente meta.version et ajoute une entrée dans meta.changelog. Renvoie le JSON complet et valide, rien d'autre avant ni après. Puis, dans un second message, liste les écarts constatés : modèle, champ, ancienne valeur, nouvelle valeur, URL source.

Échéances déjà connues

  • 16/10/2026 : retrait de Gemini 2.5 Flash-Lite.
  • 21/11/2026 : fin de la garantie de prix sur GPT-5.6 Sol. Ce n'est pas une expiration, c'est la première date à laquelle OpenAI se réserve le droit de bouger. Aucun tarif postérieur n'est publié.
  • 31/12/2026 : fin du tarif introductif de la famille Gemini Flash, doublement au 1er janvier.

09 · Sources

Benchmarks et pages tarifaires

  • openrouter.ai/models et documentation OpenRouter (frais, routage, cache, BYOK, limites)
  • platform.claude.com, pages tarifaires Anthropic
  • developers.openai.com/api/docs/pricing
  • ai.google.dev/gemini-api/docs/pricing et Google Cloud Agent Platform
  • api-docs.deepseek.com (tarification heure pleine et heure creuse)
  • docs.x.ai, platform.kimi.ai, z.ai, mistral.ai/pricing
  • artificialanalysis.ai, Intelligence Index v4.3
  • SWE-bench Verified et SWE-bench Pro, Terminal-Bench 4.0
  • BFCL v4, MCP Atlas, Tau-Bench, Toolathlon (tool use)
  • LongBench v2, MRCRv2, RULER (long contexte)
  • OSWorld 2.0, ScreenSpot-Pro (computer use)
  • MMLU-ProX, MGSM (multilingue)