Pour savoir si un SLM vaut mieux qu'un LLM sur votre tâche métier, il n'y a qu'une réponse fiable : tester sur vos propres données, avec vos propres critères de succès. Les benchmarks publics comme MMLU mesurent des connaissances académiques sur 57 matières - ils ne prédisent pas si un modèle saura extraire correctement un montant TTC de vos factures ou classer un email d'un client mécontent. Les études de déploiement publiées en 2025 documentent un écart médian de 37 points entre le score d'un modèle sur les benchmarks publics et ses performances réelles en production.
Cet article donne la méthode complète : pourquoi les benchmarks génériques trompent, comment construire un jeu de test représentatif avec vos données propriétaires, quelles métriques choisir selon le type de tâche (classification, extraction, génération), comment mesurer coût et latence, et comment rendre votre benchmark reproductible pour prendre une décision durable entre SLM et LLM.
Pourquoi MMLU et les benchmarks publics ne s'appliquent pas à votre tâche
MMLU (Massive Multitask Language Understanding) est le benchmark le plus cité dans les fiches produit des LLM. Il mesure la capacité d'un modèle à répondre correctement à des questions à choix multiples sur 57 matières académiques : droit, biologie, histoire, mathématiques. Un modèle qui score 88 % sur MMLU a prouvé une chose : il a assimilé une vaste encyclopédie générale.
Votre tâche métier, elle, ressemble rarement à un QCM de terminale. Elle ressemble plutôt à ceci :
- Extraire les références article, quantités et prix unitaires d'un bon de commande PDF, même quand le format varie d'un fournisseur à l'autre.
- Classer chaque ticket entrant dans l'une de vos 15 catégories internes, en respectant la définition précise que votre équipe support a construite en 5 ans.
- Rédiger une réponse de relance client dans le ton de votre marque, en 80 mots maximum, sans inventer d'informations que vous n'avez pas communiquées.
Ces tâches mobilisent du vocabulaire propriétaire, des règles métier non écrites, des formats spécifiques à votre secteur. Aucun benchmark public ne les couvre. Et le problème est structurel : les top modèles atteignent 88 à 94 % sur MMLU en 2026, ce qui en fait un indicateur saturé, incapable de différencier les modèles entre eux sur des marges réelles.
Repère empirique
Un modèle qui score 88 % sur MMLU peut scorer 52 % ou 91 % sur votre tâche selon son entraînement. La variance est trop grande pour que le benchmark public serve de décision. Testez sur votre tâche, avec vos données : c'est la seule mesure qui compte.
La conséquence pratique : avant de dépenser du temps à comparer des classements en ligne, construisez votre propre jeu de test. C'est la seule façon d'obtenir un chiffre actionnable.
Construire un jeu de test représentatif avec vos données propriétaires
C'est l'étape la plus importante - et la moins glamour. Un bon jeu de test est aussi précieux qu'un bon jeu d'entraînement : il représente votre avantage durable sur les fournisseurs de modèles génériques.
Volume et composition du jeu de test
Le minimum pratique : 200 à 500 exemples tirés de votre production réelle, avec labels validés. En dessous de 200 exemples, les intervalles de confiance sont trop larges pour qu'une différence de 3 à 5 points de pourcentage soit statistiquement significative. En dessus de 1000 exemples, le gain marginal en précision statistique diminue rapidement - mieux vaut investir le temps restant à affiner les métriques.
Ajoutez à ce jeu principal 50 à 100 exemples de cas limites : erreurs connues remontées par votre équipe, entrées ambiguës, formulations atypiques, cas rares mais critiques. Ces cas limites révèlent souvent des différences de robustesse que les exemples standard ne montrent pas.
Qualité des labels
Le label doit être produit par un expert métier, pas par un autre modèle IA. Si vous utilisez un LLM pour annoter votre jeu de test, vous mesurez la distance entre les modèles évalués et le modèle annotateur - pas la qualité réelle. Idéalement, deux annotateurs humains valident chaque exemple et vous calculez le taux d'accord inter-annotateurs (kappa de Cohen) pour quantifier l'ambiguité de la tâche. Un kappa inférieur à 0,6 signale que la définition de la tâche elle-même doit être clarifiée avant de benchmarker quoi que ce soit.
Représentativité temporelle
Tirez vos exemples sur une fenêtre temporelle récente (3 à 6 derniers mois). Les distributions de données changent : le vocabulaire de vos clients évolue, vos produits changent, vos processus internes aussi. Un jeu de test construit sur des données de 2023 mesure des performances sur une réalité qui n'existe plus.
Versionner dès le départ
Nommez votre jeu de test avec une date et un numéro de version (ex. eval_tickets_support_v1_2026-06.csv). Ne le modifiez jamais après le premier run : toute correction crée un nouveau jeu de test. C'est la base de la reproductibilité.
Les métriques par type de tâche
Il n'existe pas de métrique universelle. Le bon indicateur dépend de ce que vous demandez au modèle.
Classification : accuracy, F1 et matrice de confusion
Pour les tâches de classification (router des tickets, trier des documents, qualifier des leads), utilisez en priorité le F1 macro plutôt que la simple accuracy. L'accuracy peut être trompeuse sur des classes déséquilibrées : un modèle qui classe tout dans la catégorie majoritaire obtient une bonne accuracy sans être utile. Le F1 macro pondère équitablement chaque classe, même les rares.
Complétez avec la matrice de confusion : elle révèle quelles classes sont confondues entre elles. Un modèle qui confond "plainte client" et "demande de devis" est un problème opérationnel que le F1 global ne capture pas.
Extraction structurée : exact match et partial match
Pour l'extraction (entités nommées, montants, dates, clauses contractuelles, données en JSON), le critère principal est l'exact match : le champ extrait correspond-il exactement au label de référence ? Pour les champs numériques, une tolérance peut être définie (ex. montant à 1 % près). Pour les champs textuels, un partial match basé sur la similarité de chaîne (token overlap) complète l'exact match quand les formulations peuvent varier légèrement.
Sur les sorties JSON structurées, vérifiez séparément la validité du format (JSON parseable, champs obligatoires présents) et la précision des valeurs. Un modèle qui produit un JSON valide mais avec des valeurs fausses est différent d'un modèle qui produit une valeur juste dans un format cassé - les deux erreurs n'ont pas le même impact opérationnel.
Génération de texte : LLM-as-judge
Pour la génération libre (emails, résumés, synthèses, réponses clients), les métriques automatiques classiques BLEU et ROUGE sont insuffisantes : elles pénalisent les reformulations pertinentes et ne capturent pas la qualité réelle. La méthode qui s'impose en 2026 est le LLM-as-judge : un modèle frontier (GPT-4o ou Claude 3.7 Sonnet) note les sorties du modèle évalué sur un rubric structuré.
Un rubric efficace pour la génération métier couvre en général :
- Fidélité : le contenu généré n'invente-t-il pas d'information absente du contexte fourni ?
- Complétude : tous les points demandés sont-ils traités ?
- Format : la structure de sortie respecte-t-elle les contraintes (longueur, titres, balises) ?
- Ton : le registre correspond-il au canal et à votre ligne éditoriale ?
Chaque critère est noté de 1 à 5 par le juge, avec un commentaire justificatif. Calibrez le juge sur un échantillon humain de 30 à 50 exemples : comparez les notes du juge et celles de vos experts, ajustez le rubric jusqu'à obtenir une corrélation de Pearson supérieure à 0,8 avant d'industrialiser.
Pour aller plus loin sur les métriques et l'instrumentation de l'évaluation, notre guide évaluer un LLM en entreprise : métriques et benchmarks détaille les outils et les workflows de bout en bout.
Mesurer coût et latence : les deux dimensions oubliées
Un modèle peut avoir les meilleures métriques qualité et rester le mauvais choix si son coût ou sa latence sont incompatibles avec votre usage réel.
Mesurer la latence
Deux indicateurs distincts à mesurer :
- Time To First Token (TTFT) : le délai entre l'envoi de la requête et la réception du premier token de réponse. Critique pour les interfaces utilisateur où le ressenti de rapidité dépend de ce délai.
- Débit total (tokens/seconde) : la vitesse de génération une fois le premier token reçu. Critique pour les traitements en batch ou les réponses longues.
Mesurez sous charge réaliste : simulez la concurrence de requêtes équivalente à votre pic de production. Un SLM auto-hébergé de 7B peut afficher une latence 3 à 10 fois plus faible qu'un appel API LLM frontier sur des requêtes unitaires. Sous forte concurrence, l'écart peut s'inverser si votre infrastructure self-hosting n'est pas dimensionnée pour absorber les pics. Pour aller plus loin sur les techniques de réduction de latence, l'article optimisation de la latence LLM avec speculative decoding et vLLM couvre les leviers infrastructure.
Mesurer le coût
Pour une API LLM : le coût se calcule en nombre de tokens d'entrée x prix input + nombre de tokens de sortie x prix output. Comptez séparément les tokens du système prompt, du contexte et de la réponse - sur des tâches avec de longs contextes, le prompt peut représenter 80 à 90 % du coût total.
Pour un SLM auto-hébergé : le coût se décompose en amortissement du matériel GPU (ou coût cloud GPU) + électricité, divisé par le nombre de requêtes traitées. Un SLM de 7B paramètres auto-hébergé sur GPU revient typiquement 10 à 30 fois moins cher par token qu'un appel à un modèle frontier via API, à condition que le volume justifie l'investissement initial.
| Dimension | SLM self-hosted (7B) | LLM frontier API (GPT-4o) |
|---|---|---|
| Latence TTFT | 50-200 ms (local) | 300-800 ms (reseau) |
| Cout par million tokens | 0,05-0,30 $ (electricite/GPU) | 2,50-10 $ (input/output) |
| Confidentialite donnees | On-premise, zero sortie | Transfert vers serveur tiers |
| Maintenance | Equipe MLOps requise | Zero (gere par le fournisseur) |
| Customisation | Fine-tuning possible | Limité (prompt engineering) |
Arbitrer entre SLM et LLM : la grille de décision
Une fois que vous avez les chiffres - score qualité, latence, coût par requête - la décision se structure autour de trois questions.
L'ecart de qualite est-il tolerable ?
Un SLM fine-tuné qui score 87 % contre 91 % pour le LLM frontier sur votre classification : est-ce un problème ? Cela dépend du coût d'une erreur. Sur un routage de tickets support, 4 points de différence représentent 4 tickets mal routés sur 100 - acceptable si le routage manuel de ces 4 tickets est facile. Sur une extraction de données contractuelles ou une décision de crédit, 4 % d'erreurs supplémentaires peut être inacceptable.
Chiffrez le coût d'une erreur dans votre contexte. C'est cette donnée qui transforme un écart de benchmark en décision économique.
Le volume justifie-t-il l'infrastructure SLM ?
En dessous de quelques milliers de requêtes par jour, l'API LLM reste souvent moins chère quand on intègre le coût de l'infrastructure, de la maintenance et de la compétence MLOps. Le seuil de basculement varie selon les configurations, mais il se situe généralement entre 100 000 et 500 000 tokens traités par jour. En dessous, payez l'API. Au-dessus, calculez le ROI du self-hosting.
Vos donnees proprietaires sont-elles un avantage durable ?
C'est le point le plus sous-estimé. Un SLM fine-tuné sur vos données propriétaires - vos catégories internes, votre vocabulaire produit, vos règles métier non écrites - crée un avantage que les modèles génériques ne peuvent pas répliquer sans vos données. Les benchmarks publics évolueront, les modèles frontier progresseront : votre jeu de test et vos données d'entraînement, eux, restent votre propriété. C'est une barrière concurrentielle.
Pour comprendre quand le fine-tuning est la bonne réponse et quand il est prématuré, lisez notre analyse SLM vs LLM : quel modele choisir pour votre PME. Et pour l'angle technique du structured output, l'article structured output JSON et constrained decoding pour SLM couvre les techniques qui améliorent la fiabilité de l'extraction sur des modèles légers.
Reproductibilite : les 4 regles non negociables
Un benchmark non reproductible est un chiffre inutilisable. Si vous ne pouvez pas recréer le même résultat six mois plus tard avec un autre modèle ou une autre version du vôtre, vous ne pouvez pas décider en confiance.
- Fixer la temperature. Passer la temperature à 0 (ou au minimum permis par le modèle) supprime la variance stochastique. Sur les tâches déterministes (classification, extraction), c'est non négociable. Sur la génération, une temperature fixe assure que deux runs successifs donnent le même résultat.
- Versionner le snapshot du modèle. Enregistrez le nom exact du modèle, sa version, son niveau de quantification (bf16, int8, int4) et ses paramètres d'inférence (max tokens, top_p). Un même nom de modèle peut recouvrir des versions différentes selon les fournisseurs - surtout pour les API cloud où les mises à jour sont silencieuses.
- Figer le prompt. Le texte exact du system prompt et du user prompt fait partie du résultat. Un changement de virgule peut modifier le score de plusieurs points. Versionnez le prompt dans le même dépôt que le jeu de test.
- Ne jamais modifier le jeu de test apres le premier run. Si vous corrigez un label ou ajoutez des exemples, créez un nouveau jeu de test (v2) et conservez le v1. La comparaison n'est valide qu'entre des runs sur le même jeu figé.
Pour les outils d'observabilité et de tracking des évaluations dans le temps, notre comparatif top outils d'évaluation et d'observabilité LLM passe en revue les solutions open source et SaaS disponibles.
Besoin d'un avis externe ?
Faites valider votre methode de benchmark et votre choix SLM/LLM par un expert avant de deployer en production.
Pour aller plus loin
- Evaluer un LLM en entreprise : metriques et benchmarks - workflows complets et outils recommandes.
- SLM vs LLM : quel modele choisir pour votre PME - arbre de decision et criteres operationnels.
- Structured output JSON et constrained decoding pour SLM - fiabiliser l'extraction sur des modeles legers.
- Optimiser la latence LLM avec speculative decoding et vLLM - reduire le TTFT en self-hosting.
- SLM en entreprise : guide complet des petits modeles de langage - panorama 2026 des SLM disponibles.
- Top outils d'evaluation et d'observabilite LLM - comparatif des solutions pour suivre la qualite en production.
- Fine-tuning LLM en PME : quand ca vaut le coup - les conditions pour qu'un SLM specialise soit rentable.
- Expert IA generative LLM/NLP sur mesure - cadrage et deploiement de solutions SLM ou LLM adaptes a votre tache.
- GEO : Generative Engine Optimization (arXiv 2311.09735) - recherche sur la citabilite du contenu par les moteurs IA.
- LLM Benchmarking for Enterprise Production - TrueFoundry - guide pratique de reference en anglais.
