Notre grille de décision pour choisir un LLM en 2026, par cas d'usage

La question "quel LLM choisir ?" revient à chaque nouveau projet. Et la réponse honnête est : ça dépend du cas d'usage, du volume, des contraintes de données, et du budget opérationnel. Voilà comment nous structurons cette décision.

Les dimensions qui comptent vraiment

Avant d'ouvrir un benchmark, nous identifions quatre variables de décision :

• Nature de la tâche : extraction, génération, classification, raisonnement, chat.
• Contrainte de données : peut-on envoyer les données à une API externe ?
• Volume et budget : combien d'appels par mois, quel coût marginal acceptable ?
• Latence cible : interaction temps-réel (<1s) ou traitement batch (sans contrainte) ?

Ces quatre variables orientent 80% du choix. Les 20% restants viennent des spécificités du domaine.

Cas d'usage 1 : Extraction structurée à volume

Profil : extraire des champs JSON depuis des documents, formulaires, e-mails. Volume élevé (>10 000 docs/mois).

Recommandation : Claude Sonnet (via API Anthropic) ou Mistral Small, selon la contrainte de localisation.

Pourquoi : le mode tool use / structured output de Claude Sonnet est fiable sur les schémas complexes. Le coût est raisonnable à volume. Si les données sont sensibles et doivent rester en Europe, Mistral Small via La Plateforme est l'alternative.

Ne pas utiliser : GPT-4o ou Claude Opus sur ce cas, la précision marginale ne justifie pas le coût.

Cas d'usage 2 : RAG sur documentation interne

Profil : Q&A sur corpus interne de 10 000 à 500 000 chunks. Utilisateurs internes ou clients.

Recommandation : modèle de génération moyen (Claude Sonnet, Mistral Large, GPT-4o-mini), combiné à un embedding dédié (text-embedding-3-small d'OpenAI ou Mistral Embed).

Pourquoi : le modèle de génération n'est pas le premier levier de qualité d'un RAG, c'est le retrieval. Investir dans la qualité des chunks, des métadonnées et des filtres produit plus d'impact que de monter d'un modèle.

# Routing simple selon complexité estimée de la question
def select_model(question: str, context_tokens: int) -> str:
    if context_tokens > 4000 or requires_reasoning(question):
        return "claude-sonnet-4-7"  # modèle puissant pour cas complexes
    return "mistral-small-latest"   # modèle économique pour cas simples

def requires_reasoning(question: str) -> bool:
    reasoning_signals = ["compare", "explique pourquoi", "analyse", "quelles sont les différences"]
    return any(signal in question.lower() for signal in reasoning_signals)

Cas d'usage 3 : Agent avec outils et boucles

Profil : agent qui exécute des outils (recherche web, appels API, code), avec des boucles de réflexion.

Recommandation : Claude Opus ou GPT-4o. Pas de compromis sur la puissance du modèle ici.

Pourquoi : les agents avec boucles de réflexion nécessitent un modèle capable de maintenir la cohérence de l'objectif sur plusieurs étapes, de détecter ses propres erreurs, et de gérer des instructions d'outils complexes. Les modèles de taille moyenne dégradent significativement sur ce cas.

Attention au coût : un agent peut consommer 10 à 50x plus de tokens qu'une requête simple. Dimensionner le budget en conséquence ou implémenter un circuit breaker sur le nombre d'itérations.

Cas d'usage 4 : Génération de contenu formel en français

Profil : rédaction de documents légaux, administratifs, ou commerciaux en français. Volume modéré.

Recommandation : Mistral Large 2, surtout si les données doivent rester en Europe.

Pourquoi : avantage mesurable sur le français natif dans les contextes formels. Coût inférieur à Claude Opus ou GPT-4o sur l'output.

Cas d'usage 5 : Classification et routage

Profil : classifier des textes en entrée (intention, sentiment, catégorie). Volume très élevé (>100 000/mois).

Recommandation : petit modèle open-source fine-tuné (Qwen2.5-7B, Phi-4), hébergé en self-hosted ou via Groq.

Pourquoi : coût 10 à 50x inférieur aux API cloud. Un modèle fine-tuné sur 1 000 à 5 000 exemples atteint une précision supérieure à GPT-4o zero-shot sur un domaine fermé. L'investissement initial est rentabilisé rapidement à fort volume.

Cas d'usage 6 : Chat utilisateur grand public

Profil : chatbot ou assistant conversationnel avec des utilisateurs finaux non techniques. Interaction en temps-réel.

Recommandation : GPT-4o-mini ou Claude Haiku pour les interactions courantes, avec escalade vers un modèle plus puissant sur les questions complexes détectées.

Pourquoi : la latence est critique pour l'expérience utilisateur. Les modèles légers répondent en <1s là où les modèles lourds prennent 3 à 8 secondes. L'escalade automatique permet de tenir les deux exigences.

Ce que la grille ne décide pas à votre place

La grille donne un point de départ. Elle ne remplace pas :

• Une évaluation sur vos données réelles (pas sur des benchmarks génériques).
• Une analyse des conditions contractuelles du fournisseur vis-à-vis de vos données.
• Un suivi du coût en production sur les 3 premiers mois (les volumétries réelles s'écartent souvent des estimations initiales).

Nous recommandons systématiquement de construire un jeu de test de 50 à 200 cas représentatifs avant de figer le choix de modèle. C'est 2 à 3 jours d'effort qui évitent souvent une migration en production 6 mois plus tard.

La question que cette grille ne tranche pas : comment anticiper les évolutions de pricing et de capacité des fournisseurs sur la durée du projet ? Le marché LLM évolue vite, et un modèle optimal aujourd'hui peut ne plus l'être dans 6 mois. C'est une raison supplémentaire de concevoir l'orchestration de manière à pouvoir changer de modèle sans refactoring majeur.