18 août 2026
Choisir son modèle LLM en 2026 : GPT, Claude, Gemini, open-source — comment je décide
Mon cadre concret pour choisir GPT, Claude, Gemini ou un modèle open-source en production : fit tâche, latence, coût, evals, contexte et contraintes UE.
Je ne choisis jamais un modèle dans l'abstrait
Quand on me demande quel est le meilleur modèle LLM en 2026, je réponds rarement par un nom. Je réponds par une question : pour quel geste métier, dans quel produit, avec quelle tolérance à l'erreur, quelle latence acceptable et quel budget par action réussie ? GPT, Claude, Gemini et les modèles open-source progressent tous vite. La bonne décision ne consiste donc pas à suivre le classement du moment, mais à choisir le modèle qui rend un système précis fiable, rapide et maintenable.
Je travaille comme ingénieur IA très orienté produit. Mon réflexe est de ramener le débat au terrain : l'utilisateur clique, attend, relit, corrige, valide, ou abandonne. Un modèle impressionnant dans une démo peut être mauvais pour une tâche fréquente si ses réponses sont trop longues, si son appel d'outil est fragile, ou si son coût pousse l'équipe à limiter les usages. À l'inverse, un modèle moins spectaculaire peut devenir le meilleur choix s'il tient le format, répond vite et s'intègre proprement au workflow.
Je pars toujours du job à faire
Ma première grille est le type de travail demandé. Pour résumer des documents longs, je regarde la tenue du contexte, la capacité à citer les bonnes sources et la stabilité du format. Pour générer du code, je regarde la compréhension d'un repo, la qualité des diffs et la facilité à corriger après un échec de build. Pour un agent qui manipule des outils, je regarde moins la beauté du texte que la discipline : appeler le bon outil, avec les bons paramètres, au bon moment, puis expliquer sobrement ce qui a été fait.
Chez Brut, un assistant éditorial n'avait pas besoin du même modèle qu'un agent de recherche interne. Le premier devait produire une proposition claire, dans un ton précis, très vite, avec peu de friction pour une équipe habituée à travailler sous contrainte de temps. Le second pouvait accepter quelques secondes de plus si le raisonnement et les sources étaient meilleurs. Chez Ellipse, les usages autour de bibles narratives, personnages, épisodes et cohérence de production demandaient encore autre chose : mémoire, nuances, reformulation et respect d'un univers créatif.
Le meilleur modèle est souvent un portefeuille
Je vois encore beaucoup d'équipes chercher un modèle unique pour tout faire. En production, je préfère presque toujours un portefeuille. Un modèle rapide et économique traite les classifications simples, les extractions courtes, les reformulations et les contrôles de forme. Un modèle plus robuste intervient sur les arbitrages difficiles, les longues synthèses, le raisonnement multi-étapes ou les conversations à fort enjeu. Un modèle spécialisé peut compléter l'ensemble pour l'embedding, le reranking, la vision ou la génération structurée.
Cette approche protège le produit. Elle permet d'améliorer la qualité sans exploser les coûts et d'adapter le niveau d'intelligence au risque réel de la tâche. Un commentaire automatique dans un back-office ne mérite pas forcément le modèle le plus cher. Une recommandation qui influence une décision client importante mérite davantage de contexte, de validations et parfois un second passage. Je pense donc en chaînes de décision : quel modèle au premier tour, quel modèle en vérification, quel fallback si la confiance descend ?
La latence est une fonctionnalité produit
Je mesure la latence comme une sensation utilisateur, pas seulement comme un chiffre serveur. Un modèle peut être acceptable à huit secondes dans un rapport asynchrone, et beaucoup trop lent à deux secondes dans une interface conversationnelle qui demande plusieurs tours. Je regarde le p50, le p95, les timeouts, les retries, le streaming, et surtout le moment où l'utilisateur reçoit la première valeur utile. La vitesse perçue compte autant que la vitesse brute.
C'est souvent là que le choix change. Un modèle très puissant devient le bon moteur pour préparer un plan en arrière-plan, tandis qu'un modèle plus léger répond dans l'interface et maintient le rythme. À Brut, cette question est très concrète : une équipe contenu ne veut pas attendre un raisonnement invisible si elle a seulement besoin d'une variation de titre ou d'un angle alternatif. À l'inverse, pour analyser un corpus plus lourd avant une réunion éditoriale, attendre un peu plus peut être un excellent échange.
Le coût se décide par résultat, pas par token
Je regarde bien sûr le prix des tokens, mais je le considère comme un indicateur incomplet. Le vrai coût est le coût par action réussie. Si un modèle bon marché échoue plus souvent, impose plus de retries, demande plus de prompts défensifs ou augmente le temps de revue humaine, il peut coûter plus cher qu'un modèle premium. À l'inverse, si une tâche est très cadrée, un modèle compact avec un bon schéma de sortie peut produire une économie massive sans perte visible pour l'utilisateur.
Mon calcul inclut aussi les coûts cachés : observabilité, cache, stockage des traces, evals, routage, supervision, incidents, support et temps d'ingénierie. Les modèles open-source ou open-weight peuvent être excellents quand le volume, la confidentialité ou la personnalisation justifient l'infrastructure. Mais l'hébergement, les GPU, l'optimisation, les upgrades et l'astreinte font partie de la facture. La bonne comparaison est donc API managée contre système total opéré par l'équipe, pas gratuit contre payant.
Le contexte long ne remplace pas une bonne architecture
Les grandes fenêtres de contexte sont très utiles, mais elles ne suppriment pas le besoin de design. Mettre tout le dossier dans le prompt rassure au début, puis devient fragile : bruit, coûts, latence, sources contradictoires, consignes diluées. J'utilise le contexte long quand il sert réellement l'expérience, par exemple pour comparer plusieurs documents, relire un historique complet, ou garder une conversation complexe. Pour le reste, je préfère un RAG propre, un résumé d'état, des outils déterministes et des objets métier explicites.
La question n'est pas seulement combien de tokens le modèle accepte. La question est ce qu'il fait de l'information importante au milieu du bruit. Dans une production comme Ellipse, où l'on manipule des personnages, des arcs narratifs et des contraintes créatives, le modèle doit respecter les détails qui donnent de la cohérence. Je teste donc la récupération, la hiérarchie des sources et la capacité à dire qu'une information manque. Le contexte est une matière première ; l'architecture transforme cette matière en décision fiable.
Les outils et les evals départagent les finalistes
Quand deux modèles semblent proches, je les départage avec des evals de production. Je construis un petit jeu d'exemples réels : cas faciles, cas limites, mauvais documents, consignes ambiguës, demandes hors périmètre, sorties structurées, appels d'outils et attentes métier. Je mesure la réussite, la précision des sources, la stabilité JSON, les erreurs d'outil, la latence, le coût et la qualité de récupération après un échec. Cette suite vaut plus qu'une impression après dix conversations réussies.
La fiabilité du tool calling est souvent décisive. Un agent peut écrire un texte très élégant et pourtant créer une mauvaise action si le schéma est mal suivi. Je teste donc les paramètres obligatoires, les enums, les formats de dates, les retries, les refus utiles et les chemins de fallback. Le modèle que je choisis est celui qui respecte le contrat du produit. Les evals ne retirent pas le jugement humain ; elles rendent ce jugement répétable, partageable et défendable devant l'équipe.
Les contraintes européennes font partie du design
En France et en Europe, je mets les contraintes de données dans la discussion très tôt. Certaines tâches peuvent partir vers une API publique avec anonymisation, politique de rétention claire et contrat adapté. D'autres demandent une région précise, un cloud particulier, un traitement sans données personnelles, ou un modèle hébergé dans un environnement contrôlé. Ce n'est pas un frein à l'innovation. C'est une façon de construire un produit que l'entreprise peut réellement adopter.
Mon choix final ressemble donc à une matrice simple : fit tâche, qualité observée, latence, coût par succès, fenêtre de contexte, fiabilité des outils, contraintes de données, effort d'exploitation et trajectoire produit. Je garde GPT, Claude, Gemini et l'open-source dans la conversation, puis je choisis le plus petit système qui livre le bon niveau de confiance. C'est moins spectaculaire qu'un débat de fan club, mais c'est comme cela que je vois les bons produits IA arriver en production et y rester.