LLM en production : Claude 4.6, GPT-5, Mistral Large 3 — comment choisir en grande entreprise

Choisir un LLM en 2026 n'a plus rien à voir avec l'exercice de 2023. À l'époque, GPT-4 dominait sans contestation, le coût était secondaire et la décision tenait en deux questions : « est-ce qu'il sait faire ce qu'on lui demande ? » et « est-ce qu'on l'héberge sur Azure ? ». Aujourd'hui, quatre modèles frontier se tiennent à quelques points sur la plupart des benchmarks publics, les écarts de prix vont de un à dix selon les générations, et la latence est devenue un critère de premier ordre dès qu'on parle d'agent ou d'application temps réel.

Ce qui rend l'arbitrage difficile, c'est que la réponse change tous les six mois. La génération qui sortait il y a un an est aujourd'hui obsolète, ou disponible à 20% de son prix de lancement. Cet article ne tranche pas la question de la souveraineté — qui a son propre traitement. Ici, on regarde uniquement les critères techniques qui doivent guider une décision d'architecture en grande entreprise : performance brute, coût d'inférence, latence, capacités multimodales, et qualité du tool-use.

Le marché des LLM frontier en 2026 : qui est qui

Quatre fournisseurs structurent aujourd'hui le marché des modèles frontier accessibles via API. Au-delà, on entre dans le domaine des modèles spécialisés (DeepSeek, Cohere, xAI) et des modèles open-source à auto-héberger.

OpenAI — GPT-5. Lancé fin 2025, GPT-5 a unifié la gamme : plus de distinction entre modèles « réasoning » et « non-réasoning », tout passe par un seul modèle qui module en interne son effort de raisonnement. Référence sur le raisonnement complexe et le code, intégration native poussée avec l'écosystème Microsoft. Coût d'API en milieu de tableau, latence correcte mais pas la meilleure.

Anthropic — Claude 4.6 Sonnet. La documentation officielle positionne Sonnet comme le « workhorse » de la gamme : qualité élevée, coût raisonnable, latence très bonne. Claude excelle particulièrement sur la génération de code, le suivi d'instructions complexes et le tool-use multi-étapes — c'est le modèle qu'on retrouve le plus souvent en production sur les agents.

Mistral — Mistral Large 3. Le frontier européen, hébergeable de manière souveraine via La Plateforme, AWS Bedrock, Azure AI Foundry ou en self-hosted. Performances comparables aux frontiers américains sur la plupart des benchmarks classiques, avec un avantage net sur le coût et la disponibilité d'un déploiement souverain.

Meta — Llama 4. Le seul modèle open-weights vraiment frontier. Performances dans le peloton de tête, à condition d'avoir l'infrastructure GPU pour le faire tourner correctement (les versions fines tournent sur 1-2 H100, les versions complètes demandent un cluster). Avantage : contrôle total sur l'inférence, le fine-tuning, le coût marginal très bas en stationnaire. Inconvénient : l'investissement initial en MLOps n'est pas marginal.

Les cinq critères de choix techniques

Avant de regarder les modèles individuellement, fixons le cadre. En production, cinq critères pèsent vraiment dans la décision — par ordre d'importance variable selon le cas d'usage :

1. Qualité de sortie sur la classe de tâches qu'on lui confie. Les benchmarks publics donnent une idée, mais c'est l'évaluation interne qui tranche.
2. Coût d'inférence mesuré en €/M tokens, en distinguant input, output, et coût de cache. Sur des volumes importants, le ratio input/output change beaucoup la facture.
3. Latence — le temps jusqu'au premier token (TTFT) et le débit en sortie (tokens/seconde). Critère décisif pour le streaming et les agents.
4. Multimodalité — vision, audio, parfois vidéo. Plus le cas d'usage manipule des documents scannés, des plans, des photos terrain, plus ce critère devient bloquant.
5. Tool-use et function calling — la capacité à utiliser des outils externes de manière fiable, et à enchaîner plusieurs appels en mode agent.

Le piège classique consiste à arbitrer uniquement sur la qualité (parce qu'on est impressionné par les démos) ou uniquement sur le coût (parce qu'on optimise un cas d'usage à 50% qui ne le justifie pas). Le bon arbitrage dépend de la nature du cas d'usage, qu'on examinera section par section.

Performance : où chaque modèle excelle

La LMSYS Chatbot Arena et les benchmarks agrégés d'Artificial Analysis donnent une bonne photo macro, mais ils gomment les écarts qui comptent vraiment en production. Quelques observations qui ressortent à la lecture des benchmarks publics et de nos propres évaluations clients :

Raisonnement complexe long (analyse juridique, M&A, recherche). GPT-5 et Claude 4.6 Sonnet se détachent. GPT-5 est légèrement supérieur sur les chaînes de raisonnement très longues (math, problèmes formels). Claude 4.6 reste le plus fiable sur le raisonnement non-formel : argumentation juridique, synthèse de documents stratégiques, analyse contractuelle. Mistral Large 3 et Llama 4 sont en retrait, sans être disqualifiés.

Génération de code. Claude 4.6 Sonnet a creusé l'écart en 2025 — les benchmarks SWE-Bench Verified et les retours terrain convergent. GPT-5 reste très bon, surtout sur les tâches de debug complexe. Mistral Codestral est très compétitif sur la génération de code court (autocomplétion, boilerplate) mais en deçà sur le raisonnement architectural. Llama 4 dépend fortement du fine-tuning maison.

Suivi d'instructions et formatage strict (JSON, XML, schémas contraints). Claude 4.6 et GPT-5 sont au coude-à-coude. Le mode « structured output » d'OpenAI est un peu plus mature côté outillage. Mistral a fait de gros progrès sur la dernière version mais reste légèrement plus capricieux sur les schémas complexes.

Multilinguisme et corpus français. Mistral Large 3 conserve un avantage subtil mais réel sur le français nuancé — terminologie juridique française, références culturelles, formules administratives. L'écart est petit en moyenne, mais visible sur des cas spécifiques (rédaction de courriers formels, analyse de jurisprudence).

Coût d'inférence : la vraie comparaison

Les écarts de prix entre frontiers sont devenus structurants. Voici une lecture comparative à fin avril 2026, sur les tarifs publics directs (les tarifs négociés en volume peuvent réduire de 20 à 50%) :

Critère	GPT-5	Claude 4.6 Sonnet	Mistral Large 3	Llama 4
Raisonnement complexe	Excellent	Excellent	Très bon	Très bon
Génération de code	Très bon	Excellent	Très bon	Bon
Tool-use / function calling	Excellent	Excellent	Très bon	Bon
Multimodalité (vision)	Mature	Mature	Pixtral Large	En progrès
Fenêtre de contexte	~400k	~1M (beta)	~256k	~1M
Latence (TTFT)	Moyen	Très bon	Excellent	Variable (self-host)
Coût input ($/M tokens)	~$10-15	~$3	~$2-3	Marginal (self-host)
Cache prompt	Oui (auto)	Oui (explicite, -90%)	Oui	N/A
Hébergement souverain (UE)	Azure EU (limité)	AWS EU (limité)	Natif	Self-host
Fine-tuning	Oui (managé)	Limité	Oui	Total (open-weights)

Synthèse comparative — tarifs et capacités publics fournisseurs, avril 2026. Ordres de grandeur, à revérifier au moment de l'arbitrage.

Au-delà du prix au million de tokens, deux mécanismes changent radicalement la facture en production. Le cache prompt — disponible chez tous les frontiers maintenant — permet de réutiliser un préfixe (system prompt, contexte RAG, exemples few-shot) à environ 10% du prix nominal. Sur un agent qui partage un long system prompt, le coût effectif peut être divisé par cinq. La tarification batch, qui tolère un délai de réponse de quelques heures, donne typiquement 50% de remise — utile pour les pipelines d'enrichissement de données qui ne sont pas synchrones.

Latence et débit : le critère oublié pour les apps temps réel

Pendant deux ans, on a regardé la qualité et le coût. La latence, on s'y intéresse vraiment depuis qu'on construit des agents qui enchaînent dix appels avant de répondre, et des chatbots où l'utilisateur attend les premiers tokens en moins de 800 ms.

Deux métriques comptent : le TTFT (time to first token) et le débit en tokens par seconde une fois la génération lancée. Sur des prompts courts, c'est le TTFT qui domine ; sur des sorties longues, c'est le débit. Pour un agent multi-étapes, c'est la somme des deux multipliée par le nombre d'appels — une réalité que les benchmarks « single-call » masquent totalement.

Ordres de grandeur observés en avril 2026 sur des prompts moyens (~5k tokens d'input, prompt cache actif) :

• Mistral Large 3 — TTFT autour de 400-600 ms, débit ~80-100 tok/s. Le plus rapide en moyenne, surtout en hébergement européen.
• Claude 4.6 Sonnet — TTFT ~600-900 ms, débit ~60-80 tok/s. Bon compromis.
• GPT-5 — TTFT ~800-1200 ms (plus si le mode raisonnement étendu est activé), débit ~50-70 tok/s. Le mode raisonnement peut ajouter plusieurs secondes avant le premier token visible.
• Llama 4 self-hosted — entièrement dépendant de l'infrastructure GPU. Sur 4×H100 bien optimisés (vLLM, sglang), on dépasse 150 tok/s, mais l'investissement initial pèse.

Pour un cas d'usage temps réel (agent vocal, chatbot interactif, copilote IDE), Mistral et Claude prennent l'avantage. Pour un usage batch ou async, la latence est secondaire — c'est la qualité et le coût qui dominent.

Tool-use et function calling : Claude vs GPT vs Mistral

C'est le critère qui sépare un POC d'un agent en production. Tous les frontiers savent désormais appeler des fonctions, mais leur fiabilité varie considérablement quand on enchaîne plusieurs appels, qu'on gère des erreurs, qu'on demande des appels parallèles ou qu'on travaille avec une vingtaine d'outils dans le contexte.

Claude 4.6 Sonnet reste, à notre lecture, la référence pour les agents en production. Le suivi d'instructions complexes, la cohérence sur plusieurs tours d'outils, la gestion explicite des erreurs et le mode « extended thinking » pour les décisions ambiguës en font le choix par défaut sur les agents critiques. C'est aussi le seul modèle qui propose un mode d'usage natif d'ordinateur (computer use).

GPT-5 s'est beaucoup amélioré sur le tool-use multi-étapes. Les appels parallèles fonctionnent bien, le mode « structured output » garantit le format de retour, et l'écosystème SDK (Responses API) est mature. Léger handicap : le modèle a tendance à être plus verbeux dans ses réflexions internes, ce qui augmente la facture sur les agents longs.

Mistral Large 3 a fait des progrès notables sur le function calling depuis Mistral Large 2. Sur des cas simples (1-3 outils, 2-3 tours), les performances sont équivalentes aux frontiers américains. Sur des agents complexes (10+ outils, raisonnement long), un écart subsiste mais se réduit à chaque génération.

Llama 4 dépend complètement du framework. Avec un prompting bien fait et un parser robuste (XML, JSON Schema), c'est utilisable en production. Sans, c'est plus capricieux que les frontiers managés.

Si le cas d'usage est un agent autonome (recherche, automation, exécution de tâches métier), Claude est généralement le bon choix. Si c'est un assistant interactif où l'utilisateur valide chaque action, les quatre modèles font le travail — et l'arbitrage glisse vers le coût et la latence. Pour aller plus loin sur la conception, voir notre article dédié à la création d'agents IA en entreprise.

L'architecture multi-modèles : la recommandation finale

L'erreur classique consiste à choisir un modèle, le déployer partout, et redécouvrir au bout de six mois que sur 30% des cas d'usage on paie trois fois trop cher, et sur 10% on n'a pas la qualité. La bonne architecture en grande entreprise est multi-modèles, avec un router qui aiguille les appels selon la nature de la requête.

Architecture cible — pattern observé sur les déploiements LityLabs en grande entreprise

Les briques techniques de cette architecture sont aujourd'hui matures. LiteLLM, OpenRouter, Portkey, Vercel AI Gateway proposent des couches de routing toutes faites — l'arbitrage entre solution commerciale et implémentation maison dépend du niveau d'intégration souhaité (logging custom, audit interne, conformité AI Act). Sur les déploiements que nous accompagnons, le pattern qui marche le mieux est :

• Routing par cas d'usage codé dans la couche application : un cas d'usage = un modèle par défaut + un fallback. Pas de routing dynamique « intelligent » — on contrôle, on logue, on mesure.
• Observabilité unifiée : un seul endroit où on voit la consommation par modèle, par cas d'usage, par équipe. Décisif pour les arbitrages budgétaires et la conformité.
• Eval continu : un jeu de tests représentatif par cas d'usage, qu'on rejoue à chaque montée de version d'un modèle. C'est ce qui permet de basculer de Claude 4.6 à Claude 4.7 (ou de GPT-5 à GPT-5.1) sans surprise — et de challenger les choix tous les six mois.
• Cost cap par appel et par utilisateur : indispensable pour éviter les dérives sur les agents qui partent en boucle.

Cette architecture rejoint le travail qu'on fait sur les déploiements RAG en entreprise, où le choix du modèle de génération est rarement le facteur limitant — la qualité du retrieval, du chunking et de l'évaluation pèse beaucoup plus. Mais avoir un router propre permet de tester en quelques heures un modèle alternatif sur un cas d'usage existant, ce qui change la dynamique de l'optimisation.

Comment nous intervenons sur ces sujets

Nous accompagnons des grandes entreprises françaises sur le choix et le déploiement de LLM en production depuis 2023. Trois formats d'intervention reviennent régulièrement : le benchmark interne sur un cas d'usage réel pour trancher entre deux ou trois modèles candidats ; la conception d'architecture multi-modèles avec router, observabilité et eval continu ; et l'optimisation de stack existante, où on identifie les cas d'usage sur-payés et on bascule ce qui peut l'être vers un modèle moins cher sans perte de qualité.

Le sujet recoupe nos expertises GenAI et data engineering — l'arbitrage technique sur les modèles ne tient qu'avec une couche d'évaluation et d'observabilité solide en dessous.

Ce qui change vraiment l'arbitrage

Les écarts entre modèles frontier se sont resserrés. Pour la grande majorité des cas d'usage en entreprise, les quatre modèles examinés ici font le travail — l'arbitrage tient dans le coût, la latence et la latitude opérationnelle (souveraineté, fine-tuning, hébergement). Le piège est de raisonner « un modèle pour tout » : on perd à la fois sur le coût (en payant trop cher sur les cas simples) et sur la qualité (en manquant le bon outil sur les cas exigeants).

L'investissement le plus rentable en 2026, pour une DSI qui structure sa stack IA, n'est pas de choisir le « meilleur » modèle. C'est de construire la couche d'orchestration qui rend le choix de modèle réversible — pour pouvoir basculer en quelques jours quand la prochaine génération sortira, ce qui arrivera dans six mois.