“Notre LLM a atteint 90 % sur MMLU et 87 % sur HumanEval.” Ces chiffres, omniprésents dans les communiqués de presse des éditeurs IA, ne vous disent rien sur la façon dont ce modèle va performer sur vos emails commerciaux, vos contrats, vos tickets de support. Voici comment évaluer un LLM pour votre contexte spécifique.
Pourquoi les benchmarks publics ne suffisent pas
Les problèmes avec MMLU, HumanEval, et consorts
MMLU (Massive Multitask Language Understanding) mesure les connaissances académiques sur 57 domaines (médecine, droit, histoire, etc.). Pertinent pour un assistant de recherche généraliste. Peu pertinent pour évaluer si le modèle rédige bien des emails B2B en français.
HumanEval mesure la capacité à écrire du code Python sur des exercices académiques. Utile pour un outil de coding assistant. Pas pour un chatbot service client.
MT-Bench / Chatbot Arena mesure la qualité des réponses conversationnelles par comparaison humaine. Plus proche des usages enterprise, mais encore trop généraliste.
Le “benchmark gaming”
Les éditeurs optimisent leurs modèles pour performer sur les benchmarks publics — parfois en incluant des données similaires dans l’entraînement. Des modèles très performants sur les benchmarks peuvent décevoir sur des tâches réelles.
Conclusion pratique : les benchmarks publics servent à éliminer les mauvais candidats. Seuls vos propres tests sur vos propres tâches permettent de choisir le bon modèle.
Les critères d’évaluation enterprise
1. Performance sur les tâches métier (le plus important)
Définissez 5 à 10 tâches représentatives de vos cas d’usage principaux. Par exemple :
Pour un service commercial :
- Rédiger une proposition commerciale à partir d’un brief (3 points clés, format professionnel)
- Répondre à une objection client type
- Résumer un compte-rendu de réunion en 5 actions
Pour un service RH :
- Analyser un CV et identifier les points de correspondance avec une fiche de poste
- Rédiger une annonce de recrutement
- Synthétiser les réponses d’une enquête satisfaction
Pour une équipe technique :
- Écrire des tests unitaires pour un service Python donné
- Expliquer un bug à partir d’une stack trace
- Refactorer une fonction pour respecter les principes SOLID
2. Qualité en langue française
Les modèles varient significativement sur leur maîtrise du français :
| Modèle | Qualité globale FR | Nuances et registres | Termes techniques |
|---|---|---|---|
| GPT-4o | ★★★★½ | Excellent | Très bon |
| Claude Sonnet 3.5 | ★★★★½ | Excellent | Très bon |
| Mistral Large 2 | ★★★★★ | Excellent | Excellent |
| Gemini 1.5 Pro | ★★★★ | Très bon | Bon |
| Llama 3 70B | ★★★½ | Bon | Moyen |
Pour des communications en français avec des clients ou prospects, Mistral Large 2 a souvent une légère avance sur les nuances culturelles françaises.
3. Cohérence et fiabilité
Le problème de la variance : certains modèles donnent des résultats excellents 80 % du temps et très mauvais 20 % du temps. Pour une application en production, une performance moyenne mais cohérente vaut souvent mieux qu’une performance brillante mais erratique.
Comment mesurer : exécutez chaque tâche test 5 fois et évaluez la variance des résultats, pas seulement la moyenne.
4. Capacités de formatage et de structuration
Pour les applications qui nécessitent un output structuré (JSON, tableaux, listes), vérifiez :
- La fiabilité du JSON mode (est-ce que le JSON est toujours valide ?)
- La cohérence du respect des contraintes de format dans le prompt
- La gestion des tokens spéciaux et du markdown
5. Fenêtre de contexte et gestion des longs documents
| Modèle | Fenêtre de contexte | Performance sur longs docs |
|---|---|---|
| GPT-4o | 128k tokens | Bonne jusqu’à ~50k, décline |
| Claude 3.5 Sonnet | 200k tokens | Très bonne |
| Gemini 1.5 Pro | 1M tokens | Meilleure pour très longs docs |
| Mistral Large 2 | 128k tokens | Bonne jusqu’à ~50k |
Pour analyser de très longs contrats, rapports ou bases de connaissances, Gemini 1.5 Pro ou Claude sont plus adaptés.
6. Vitesse (latence)
La latence varie beaucoup selon le modèle et la longueur de la réponse :
- GPT-4o-mini : ~1-3 secondes pour des réponses courtes
- GPT-4o : 3-8 secondes
- Claude Sonnet 3.5 : 3-7 secondes
- o3 : 30 secondes à plusieurs minutes
Pour des interactions temps réel avec des utilisateurs, la latence est un critère critique.
Protocole d’évaluation : méthode pratique
Étape 1 : Définir les tâches de test (1 semaine)
Travaillez avec les équipes utilisatrices pour identifier 5 à 10 tâches représentatives. Pour chaque tâche, préparez :
- 3 à 5 exemples d’inputs réels (anonymisés si nécessaire)
- Un critère d’évaluation clair : qu’est-ce qui rend une réponse bonne ?
- Un exemple de “bonne réponse” de référence si disponible
Étape 2 : Construire l’éval (1 semaine)
Créez un script d’évaluation simple qui :
- Envoie chaque input aux modèles testés via leur API
- Stocke les outputs
- Permet l’évaluation humaine (notation 1-5 sur chaque critère)
Outils utiles :
- Evals (OpenAI) : framework d’évaluation open source
- LangSmith (LangChain) : traçabilité et évaluation des chains
- Braintrust : plateforme dédiée à l’évaluation de LLMs
- Promptfoo : open source, idéal pour comparer des prompts et modèles
Étape 3 : Exécuter les tests (2-3 jours)
Testez 3 à 5 modèles candidats sur toutes vos tâches. Pour chaque test :
- Utilisez le même prompt pour tous les modèles
- Exécutez chaque test 3 fois pour capturer la variance
- Notez chaque output par deux évaluateurs humains indépendants
Étape 4 : Analyser les résultats
Compilez les scores par tâche et par modèle. Identifiez :
- Le modèle le plus performant en moyenne
- Les modèles qui excellent sur certaines tâches spécifiques
- Les modèles à éliminer (performance insuffisante ou trop erratique)
Étape 5 : Test de charge et coûts réels
Pour le ou les modèles finalistes :
- Estimez le volume de tokens en production
- Calculez le coût mensuel réel (pas le coût de test)
- Testez la latence en conditions de charge (plusieurs requêtes simultanées)
Les critères non-fonctionnels : souvent décisifs
Sécurité et conformité
Questions à poser à chaque fournisseur :
- Où sont hébergées les données ? (région UE disponible ?)
- Les données sont-elles utilisées pour l’entraînement ? (opt-out possible ?)
- Quel est le contrat de traitement des données (DPA) proposé ?
- Y a-t-il des certifications de sécurité ? (ISO 27001, SOC 2)
- L’offre enterprise inclut-elle des SLA de disponibilité ?
Notre évaluation rapide (début 2025) :
| Fournisseur | Hébergement EU | Non-entraînement | DPA RGPD | SOC 2 |
|---|---|---|---|---|
| OpenAI Enterprise | ✅ (via Azure) | ✅ | ✅ | ✅ |
| Anthropic Claude for Work | ✅ | ✅ | ✅ | ✅ |
| Google Vertex AI | ✅ | ✅ | ✅ | ✅ |
| Mistral API Enterprise | ✅ (France) | ✅ | ✅ | En cours |
| Meta Llama (self-hosted) | ✅ | N/A | N/A | N/A |
Intégrations et écosystème
- Intégration native avec vos outils existants (Slack, Notion, CRM…) ?
- Support de MCP (Model Context Protocol) pour les agents ?
- SDK disponibles dans votre stack (Python, Node.js, Java…) ?
- Documentation et support technique de qualité ?
Support et SLA
Pour les usages critiques :
- Quel est le SLA de disponibilité (99.9 % ? 99.99 % ?) ?
- Y a-t-il un support enterprise avec délai de réponse garanti ?
- Comment sont gérées les migrations de version quand un modèle est déprécié ?
Notre recommandation par type d’usage
Pour débuter (< 3 mois d’expérience IA)
GPT-4o ou Claude Sonnet 3.5 — les meilleurs équilibres de performance, facilité d’utilisation, et documentation.
Pour un usage intensif en français
Mistral Large 2 — meilleures performances sur le français, souveraineté des données, tarif compétitif.
Pour les très longs documents
Gemini 1.5 Pro ou Claude 3 Opus — fenêtres de contexte les plus grandes et meilleures performances sur les longs textes.
Pour le code
GPT-4o, Claude Sonnet 3.5 — les plus performants sur les tâches de développement. Codestral (Mistral) pour les équipes qui veulent un modèle code dédié.
Pour les raisonnements complexes
o3-mini ou o4-mini (OpenAI) — pour les tâches analytiques complexes : analyse financière, revue juridique, débogage difficile.
Pour le déploiement on-premise (souveraineté totale)
Llama 3 70B ou Mistral 7B/Mixtral 8x7B — les modèles open source les plus performants en auto-hébergé.
Questions fréquentes
Combien de temps prend une évaluation sérieuse ? Avec un protocole structuré, comptez 3 à 5 semaines : 1 semaine de définition des tâches, 1 semaine de construction de l’éval, 1 semaine de tests, 1 semaine d’analyse. Pour une décision rapide (< 1 semaine), testez au moins 3 tâches sur 3 modèles manuellement.
Doit-on refaire l’évaluation quand les modèles sont mis à jour ? Oui, surtout pour les mises à jour majeures. Les comportements peuvent changer significativement. Planifiez une réévaluation annuelle ou après chaque mise à jour majeure de votre modèle principal.
Notre prompt fonctionne sur un modèle mais pas un autre — est-ce normal ? Oui. Les modèles ont des “préférences” de style de prompt différentes. Un prompt optimisé pour GPT-4 peut sous-performer sur Claude, et vice versa. Lors de la migration entre modèles, prévoyez une phase de ré-optimisation des prompts.
Conclusion
Choisir un LLM est une décision stratégique qui mérite un processus rigoureux. Les benchmarks publics vous donnent un point de départ, mais seuls vos propres tests sur vos propres tâches vous donnent la réponse correcte pour votre organisation.
La bonne nouvelle : ce travail d’évaluation vous apprend énormément sur vos cas d’usage, vos besoins réels, et la façon d’optimiser vos prompts — même si vous finissez par choisir le modèle que vous utilisiez déjà.
BetterPeople accompagne les équipes dans la conception et l’exécution de protocoles d’évaluation LLM. Planifiez un atelier d’évaluation.
Prêt à transformer votre organisation avec l'IA ?
Réservez un diagnostic gratuit de 30 minutes avec notre équipe.