Choisir un modèle IA avec ses propres evals, pas seulement les classements

Un classement est un bon signal de départ, mais une mauvaise décision finale. Le modèle en tête peut briller dans des préférences publiques et échouer sur vos emails support, revues de code, feuilles de calcul, workflows agents, coûts ou contraintes de latence. LM Arena et Chatbot Arena sont utiles, mais ils ne remplacent pas vos tâches réelles.

Les leaderboards compressent prompts, utilisateurs, méthodes de jugement et interfaces produit en un score. Votre cas est plus précis : ton de marque, risque acceptable, budget, vitesse, confidentialité, outils et types d'erreurs. Pour une orientation générale, lisez notre guide Claude vs GPT, puis testez votre propre travail.

Construire un eval set représentatif

Un eval set personnel est une petite collection de tâches réelles, de critères de qualité et de règles de notation. Un individu peut apprendre beaucoup avec 20 prompts bien choisis; une petite équipe voit souvent les écarts avec 50 à 100 cas.

Collectez du travail récent : tickets support, emails commerciaux, commentaires de code review, specs produit, nettoyage de tableurs, questions de recherche, comptes rendus et workflows agents. Supprimez les données privées, mais gardez la difficulté : contexte long, instructions ambiguës, texte multilingue, entrées médiocres et limites de sécurité. Pour les développeurs, complétez avec notre guide IA pour développeurs et le playbook de migration GPT-5.

Écrire la grille avant de comparer

Ne notez pas après avoir vu le nom du modèle. Définissez d'abord : réussite de tâche de 0 à 3, fiabilité factuelle de 0 à 3, respect des consignes de 0 à 3, utilisabilité de 0 à 3, puis pénalité pour action dangereuse, invention, fuite privée ou confiance excessive.

Pour le subjectif, ajoutez ton, concision et adéquation à la marque. Pour le code, utilisez des tests si possible. Pour les outils, observez si le modèle choisit le bon outil, demande les informations manquantes et s'arrête au bon moment. Pour l'architecture outil, voir MCP, CLI et function calling.

Prompts d'exemple

Recherche : résumer cinq extraits, lister les questions ouvertes et marquer les affirmations à vérifier.

Support : répondre à un client mécontent après deux échecs d'export, sans promettre de date, en demandant un diagnostic utile sous 140 mots.

Code : avec un test en échec, une fonction et un diff, proposer le plus petit correctif probable et les vérifications avant changement.

Achat : comparer trois outils d'écriture IA avec les notes fournies seulement, en séparant faits et hypothèses.

Agent : avec calendrier, brouillon d'email et CRM, identifier les étapes qui exigent confirmation avant de reprogrammer un appel.

Sources utiles : Anthropic sur testing and evaluation, OpenAI sur custom evals and graders et Hamel Husain sur LLM evals.

Coût, latence et régression

Un modèle 5 % meilleur mais trois fois plus lent peut être pire. Un modèle moins cher qui échoue silencieusement sur les cas risqués peut coûter cher en support. Suivez modèle, date, version du prompt, latence, coût estimé, taux de réussite, échecs sévères et notes.

Regardez les catégories plutôt que la moyenne. Un modèle peut gagner en rédaction, un autre en extraction, un autre en usage sûr des outils. Cela suggère du routage, pas un champion unique. Pour les agents navigateur, voir notre guide du stack d'automatisation IA.

Quand relancer les evals

Relancez lors de nouveaux modèles, prix, changements de routage, gros prompts, nouveaux droits d'outils, corpus de retrieval mis à jour ou changement métier. Un individu peut tester dix prompts par mois; un indie hacker doit relancer les cas risqués avant de changer le modèle par défaut; une équipe achat teste avant achat, avant déploiement et après usage réel.

Le but n'est pas de devenir chercheur en évaluation. Il s'agit d'utiliser les classements pour réduire le choix, puis vos tâches pour décider.