ChatGPT vs Claude vs Gemini : comment choisir son LLM en 2026

Un tableau qui classe trois modèles sur cinq critères a une durée de vie de quelques semaines. Entre sa rédaction et votre lecture, un éditeur a publié une version, un autre a baissé ses tarifs, un troisième a élargi sa fenêtre de contexte. Nous avons maintenu ce genre de tableau sur cette page même : il était faux moins de trois mois plus tard, prix compris.

Ce qui ne périme pas, c’est la méthode. Choisir un modèle est une décision d’architecture ordinaire : des critères explicites, un test sur votre propre matière, un coût complet, des contraintes réglementaires et un plan de sortie. Cet article donne cette grille, plus la comparaison qualitative des trois familles — celle qui reste vraie quand les versions changent.

Précision d’emblée : ni prix ni numéro de version ici. Les tarifs et les catalogues bougent trop vite pour être gravés dans un article. Les seules sources qui font foi sont les pages de tarification officielles des éditeurs et la console de votre fournisseur cloud.

Les écarts de score sur les classements publics se resserrent à chaque génération et se retournent d’une version à l’autre. Les différences de culture produit, elles, sont stables et expliquent mieux ce que vous observerez en mission.

OpenAI — l’écosystème le plus large

• La gamme la plus étendue : généralistes, modèles de raisonnement, petits modèles économiques, voix, image. L’outillage tiers suit — la plupart des bibliothèques et des SaaS parlent d’abord ce dialecte d’API.
• Une distribution en entreprise portée par Microsoft, qui compte quand la DSI est déjà sur Azure. Revers : une gamme large est une gamme qui bouge.

Anthropic — l’exécution des consignes

• Le point fort constant de la famille Claude est le respect des instructions et des contraintes de format — ce qui compte dans une chaîne automatisée, où la sortie est consommée par du code, pas lue par un humain.
• Solide sur les documents longs et sur le code appliqué à un dépôt existant, y compris en usage agentique.
• Accessible en direct comme via Amazon Bedrock et Google Vertex AI : plusieurs voies contractuelles, plusieurs régions. Revers : une gamme plus étroite, et rarement le moins cher.

Google — le contexte et la donnée

• Google a fait de la fenêtre de contexte un argument produit et propose parmi les plus larges du marché, avec un multimodal natif, vidéo comprise, sans équivalent direct chez les deux autres.
• Intégration serrée avec Vertex AI et BigQuery : si vos données sont déjà là, le trajet est court. Revers : des sorties parfois moins régulières d’un appel à l’autre, que corrigent un prompt plus contraint et une validation de schéma.

Le quatrième candidat

Les modèles à poids ouverts — Mistral côté français, Llama, Qwen — ne sont pas un lot de consolation. Sur des tâches cadrées, ils tiennent la comparaison et se déploient dans votre propre réseau : souvent la seule réponse acceptable quand la donnée ne peut pas sortir. Le coût se déplace simplement du token vers le GPU et l’exploitation.

Écrire un prix dans un article revient à le rendre faux. Voici les régularités structurelles, qui tiennent d’une génération à l’autre.

• Deux à trois paliers par éditeur. Un petit modèle rapide, un intermédiaire qui absorbe la majorité des usages, un haut de gamme. L’écart entre le bas et le haut se compte en ordre de grandeur, pas en pourcentage — et l’intermédiaire suffit dans la plupart des cas d’entreprise.
• La sortie coûte plusieurs fois l’entrée. Une consigne qui impose des réponses courtes a un effet direct sur la facture, souvent plus fort qu’un changement de modèle.
• Les modèles de raisonnement facturent leur réflexion. Les tokens intermédiaires sont comptés en sortie : deux modèles affichés au même tarif peuvent différer d’un facteur important sur la même tâche.
• Le cache de prompt et le traitement par lots changent l’économie. Les trois éditeurs en proposent. Sur un système RAG qui réenvoie le même contexte à chaque requête, c’est le premier levier d’optimisation — conditions exactes à vérifier chez chacun.
• À qualité constante, les prix baissent. N’architecturez pas autour d’un tarif du moment, et n’abandonnez pas un cas d’usage au seul motif qu’il coûte aujourd’hui trente pour cent de trop.

Pour les chiffres, une seule règle : la page de tarification officielle de l’éditeur, ou la console Azure OpenAI, Vertex AI ou Amazon Bedrock selon votre voie d’accès — les tarifs et les conditions y diffèrent parfois de l’API directe.

Les classements publics mesurent des tâches génériques sur des jeux de données que les modèles ont, au moins en partie, croisés pendant leur entraînement. Ils disent qu’un modèle est bon en général, rien de sa tenue sur vos contrats, votre nomenclature interne ou vos tickets de support.

Le protocole que nous mettons en place tient en une semaine, métier compris.

1. Constituer 50 à 200 cas réels, pris dans le vrai flux. Y inclure délibérément les cas tordus : documents mal numérisés, questions ambiguës, demandes hors périmètre.
2. Écrire le résultat attendu avec le métier. Pas « une bonne réponse » : un critère d’acceptation vérifiable. C’est l’étape que tout le monde saute, et celle qui décide de la valeur du test.
3. Automatiser la notation. Comparaison exacte quand la sortie est structurée, grille de notation sinon. Un modèle juge peut noter à l’échelle, à condition de l’avoir calibré une fois sur une cinquantaine de cas notés à la main.
4. Mesurer quatre chiffres par candidat : taux de réussite, taux de reprise humaine, latence au 95e centile, coût par cas traité.
5. Rejouer avec un prompt adapté à chaque modèle. Un prompt n’est pas portable : comparer trois modèles sur le prompt optimisé pour le premier ne compare rien.

Ce harnais n’est pas jetable : il devient votre suite de non-régression, rejouée avant chaque bascule de version. C’est le seul moyen de répondre à « peut-on passer à la suivante ? » autrement que par une intuition.

Le prix au million de tokens est la partie visible, et généralement la plus faible. Le coût qui décide est celui d’une tâche réellement résolue.

• Le taux de reprise. Un modèle deux fois moins cher qui impose une relecture humaine sur un cas sur cinq revient plus cher dès que l’on valorise le temps de celui qui relit. Le calcul se fait en euros par dossier.
• Les tentatives. Sortie invalide, appel d’outil mal formé, schéma non respecté : chaque reprise automatique double le coût et la latence de la requête. C’est là que la régularité de format vaut de l’argent.
• La latence, surtout en agent. Dans un enchaînement de cinq à dix appels, une seconde de plus par appel devient une minute d’attente. Sur un usage interactif, l’abandon arrive avant la facture.
• L’ingénierie autour. Prompts, évaluation, garde-fous, observabilité, supervision. Poste dominant la première année, largement indépendant du modèle retenu.

C’est la discipline du FinOps appliquée à l’IA : un coût unitaire ne veut rien dire sans son dénominateur métier. Nous instrumentons un coût par requête et par cas résolu avant d’arbitrer. Le volet exploitation est détaillé dans notre guide de déploiement de LLM en production.

Pour un DSI français, ce chapitre tranche souvent avant les benchmarks. Trois questions suffisent à cadrer la discussion.

1. Mes données servent-elles à l’entraînement ? Sur les offres API et entreprise des trois éditeurs, la réponse est non par défaut — ce qui n’est pas nécessairement vrai des applications grand public. Exigez la clause contractuelle, pas la page marketing.
2. Combien de temps sont-elles conservées ? Une rétention de quelques jours à des fins de détection d’abus est courante. Des options de rétention nulle existent selon l’offre : elles se demandent explicitement.
3. Où sont-elles traitées ? Les trois familles sont accessibles depuis des régions européennes via Azure OpenAI, Vertex AI ou Amazon Bedrock. Mais la disponibilité d’un modèle donné dans une région donnée varie et change : à vérifier modèle par modèle, au moment du choix.

Sur les transferts hors Union européenne, gardez en tête que le cadre juridique applicable a déjà été invalidé deux fois par la Cour de justice. Concevez comme s’il pouvait l’être encore : sachez quelles données sortent, et ce que vous feriez si elles ne le pouvaient plus. Pour les traitements les plus sensibles, un modèle à poids ouverts hébergé chez vous reste la réponse la plus simple à défendre devant un DPO.

Côté conformité, les obligations européennes sur l’IA se traduisent en pratique par une exigence de traçabilité : savoir quel modèle, quelle version et quel prompt ont produit une sortie donnée, et pouvoir le prouver. Cela se prépare dans le code, dès le premier appel, pas au moment de l’audit — c’est le volet que notre pratique cybersécurité et conformité traite avec l’architecture.

Choisir un modèle unique pour toute une plateforme est un pari inutile : les usages n’ont ni les mêmes exigences de qualité, ni les mêmes contraintes de latence, ni les mêmes volumes.

• Router par tâche. Un petit modèle pour la classification, l’extraction et le routage ; un intermédiaire pour la majorité des réponses ; le haut de gamme réservé aux cas que le premier niveau n’a pas su traiter. Le gain se mesure dans le harnais d’évaluation.
• Abstraire, mais fin. Une interface interne — un prompt, des outils, un schéma de sortie, une politique de reprise — et un adaptateur par fournisseur. Le piège inverse est la couche universelle qui ne retient que le plus petit dénominateur commun et vous prive de ce qui fait la différence : appel d’outils, sortie structurée, cache de prompt.
• Traiter les prompts comme du code. Versionnés, testés, avec une variante par modèle. C’est le vrai coût de portage : les sémantiques d’appel d’outils et de sortie structurée diffèrent davantage d’un éditeur à l’autre que la qualité des réponses.
• Ne pas construire la passerelle le premier jour. Démarrez avec un seul fournisseur, mais isolez l’appel derrière cette frontière et instrumentez-la dès le départ.

L’enfermement ne vient presque jamais de l’API de complétion, qui se réécrit en quelques jours. Il vient toujours des mêmes endroits.

• Les embeddings. En changer impose de réindexer tout le corpus. Gardez les documents source et le pipeline de découpage dans votre propre stockage : la réindexation devient un traitement par lots d’une nuit, pas un projet de trimestre.
• Le fine-tuning. Un modèle affiné n’est pas transportable. Conservez le jeu d’entraînement et sa recette comme un actif de premier rang : c’est lui, et non les poids, qui est réutilisable ailleurs.
• Les briques propriétaires. Magasins de fichiers gérés, mémoire d’agent, orchestration hébergée : pratiques, et rarement exportables. À accepter en connaissance de cause, jamais par défaut.
• L’obsolescence des versions. Le risque d’exploitation le plus concret : les modèles sont retirés du catalogue, et le vôtre le sera. Épinglez une version explicite, suivez les annonces de dépréciation, gardez le harnais prêt à requalifier la suivante.

Côté contrat, trois lignes couvrent l’essentiel : suppression et export des données sur demande, préavis en cas de retrait d’un modèle, engagement de réversibilité au terme. Le reste se joue dans le code.

Critère	Question à trancher	Comment le vérifier
Qualité sur votre corpus	Tient-il vos cas réels, y compris les cas tordus ?	Harnais de 50 à 200 cas, notation calibrée avec le métier
Régularité de format	La sortie est-elle exploitable par du code sans reprise ?	Taux de sortie invalide sur quelques centaines d’appels
Latence	Le 95e centile tient-il l’usage, seul puis en chaîne d’agent ?	Mesure sous charge réelle, pas dans la console
Coût par cas résolu	Combien coûte un dossier traité de bout en bout ?	Tokens, plus reprises automatiques, plus minutes humaines
Hébergement et conformité	Où la donnée est-elle traitée, et conservée combien de temps ?	Contrat, clauses de sous-traitance, région — modèle par modèle
Intégration au socle	Joignable depuis votre réseau et votre CI ?	Un POC d’une journée sur l’infrastructure cible
Réversibilité	Que coûte le changement dans six mois ?	Inventaire des embeddings, fine-tunes et briques propriétaires

Reste la question qui revient toujours : « lequel des trois ? ». La qualité étant proche sur la majorité des tâches d’entreprise, le modèle est rarement le facteur limitant. Ce qui fait échouer un projet, c’est l’absence d’évaluation, une donnée mal préparée et une production sans supervision. Le choix du fournisseur arrive loin derrière.

Nous menons ce cadrage en quelques semaines : harnais d’évaluation sur votre corpus, chiffrage du coût par cas résolu, revue de conformité et architecture cible. Voir notre expertise Intelligence Artificielle, ou nous décrire votre cas en 45 minutes.