Malgré les progrès des modèles de fondation, l’adoption sereine en production repose surtout sur des pratiques d’évaluation rigoureuses.
Des évaluations bien conçues aident les chefs de produit, responsables de la gouvernance de l’IA et directeurs techniques à déployer des agents d’IA à grande échelle et en toute sécurité, transformant l’IA d’un gadget isolé en avantage concurrentiel.
Cette confiance vient de l’évaluation du comportement des agents d’IA face à de vraies requêtes d’utilisateurs, à des cas limites et à des scénarios propres au domaine qui reflètent votre contexte métier réel, et non d’un benchmark public affirmant « ce modèle est le meilleur ».
L’objectif est de justifier cette confiance par des résultats mesurables. Réussir consiste à définir concrètement et de façon mesurable ce qui est « bon », en accord avec vos besoins métier et votre tolérance au risque, qu’il s’agisse d’exactitude factuelle, de ton approprié, de rapidité ou de rentabilité.
En intégrant l’évaluation à l’ensemble du système (instrumentation, journalisation, tests A/B, garde-fous) et en conciliant rigueur et efficacité, les équipes accélèrent les déploiements et renforcent la robustesse.
La plupart des entreprises acceptent que leurs employés expérimentent avec ChatGPT ou Gemini. Mais l’utilisation des LLM dans des processus ou environnements à fort enjeu reste moins courante.
Les raisons ont souvent été légitimes : qualité inégale et risques d’hallucinations ou de comportements indésirables supérieurs aux avantages potentiels de la technologie.
Cet équilibre entre risques et bénéfices a sensiblement évolué au cours de l’année écoulée. Si les progrès des modèles de fondation y ont contribué, cette évolution tient en grande partie à la rigueur croissante des évaluations (ou « evals »). Les évaluations nous donnent, ainsi qu’à nos clients, la confiance nécessaire pour déployer en quelques semaines des agents à grande échelle et destinés aux clients.
Ce guide présente les fondements des évaluations, ainsi que leur conception, leur mise en œuvre et leur exploitation pour des cas d’usage en production.
L’objectif de l’évaluation n’est pas de trouver un modèle parfait, mais d’établir une confiance justifiée dans le fait que votre modèle se comporte conformément à vos besoins métier, aux attentes de vos utilisateurs et à la tolérance au risque de votre organisation.
Toute stratégie d’évaluation repose sur une question simple : À quoi reconnaît-on ce qui est « bon » ? La réponse doit être précise. Pour une organisation, être « bon » peut signifier garantir une exactitude factuelle selon des tolérances strictes ; pour une autre, privilégier la rapidité, la rentabilité ou un ton distinctif. Chaque contrainte, des données utilisables aux obligations réglementaires applicables, façonne cette définition.
Surtout, ce qui est « bon » doit comporter des éléments réellement mesurables. Si réussir signifie fournir des conseils financiers utiles, cette utilité doit être exprimée par des attributs : exactitude factuelle, avertissements appropriés, raisonnement personnalisé et limites de sécurité. Une fois ce qui est « bon » défini en termes mesurables, il faut déterminer comment analyser et interpréter les résultats. C’est l’exploitation de ces résultats qui fait de l’évaluation une méthode plutôt qu’une simple succession de jugements.
Chaque pipeline d’évaluation repose sur trois piliers interdépendants :
Entrées/benchmarks : exemples représentatifs du monde réel pour les performances générales et jeux de données internes sélectionnés pour tester la viabilité dans le domaine.
Comportement du modèle : manière dont le modèle est sollicité (génération augmentée par récupération, synthèse, récupération d’informations structurées, utilisation d’outils).
Métriques : manière de mesurer et d’interpréter les performances.
Les entrées doivent représenter le monde auquel votre système sera confronté. Les enseignements les plus pertinents viennent d’exemples réels : requêtes de vos clients, scénarios financiers ou cas propres à votre secteur. Seuls des tests sur ces exemples permettent de savoir si le modèle saisit réellement les nuances attendues par vos utilisateurs et répond au besoin métier.
Le comportement du modèle — formulation des prompts, orchestration de la récupération ou des outils, apport du contexte — compte autant que le modèle lui-même. Deux modèles identiques peuvent se comporter très différemment selon leur mode de déploiement. Cette couche doit donc être intégrée à la conception de votre évaluation.
Enfin viennent les métriques. Les chiffres seuls racontent rarement toute l’histoire, mais des métriques bien choisies rendent le comportement du système interprétable. Latence, exactitude, sécurité, cohérence, biais, coût et satisfaction des utilisateurs forment ensemble une vision multidimensionnelle d’un système en production. Tout l’art consiste à choisir des métriques alignées sur les KPI de votre projet ou entreprise et révélant les qualités les plus importantes pour vos utilisateurs. Les métriques simples sont souvent plus exactes et moins coûteuses, tandis que de mauvais choix peuvent induire les équipes en erreur. Voici comment aborder le choix des métriques :
Exemples de bons choix de métriques :
Chatbot de service client : taux de résolution au premier contact (le problème de l’utilisateur a-t-il été résolu sans escalade ?), durée moyenne de traitement, score de satisfaction, taux de transfert vers des agents humains
Outil de recherche financière : exactitude des citations (% d’affirmations correctement sourcées), précision factuelle validée par rapport à une vérité terrain, pertinence de la récupération (les bons documents ont-ils été trouvés ?), cohérence du raisonnement évaluée par des experts du domaine
Assistant de génération de code : validité syntaxique, taux de réussite des tests, nombre de vulnérabilités de sécurité, délai d’obtention d’une solution fonctionnelle
Exemples de mauvais choix de métriques :
Utiliser uniquement la longueur de la réponse comme indicateur de qualité (plus long ≠ meilleur)
Mesurer la vitesse sans tenir compte des compromis sur l’exactitude
Suivre les scores de confiance du modèle sans les confronter à l’exactitude réelle
Se fier uniquement à la perplexité interne du modèle sans validation auprès des utilisateurs
Pièges courants à éviter avec les métriques :
Métriques contradictoires : optimiser simultanément la vitesse et l’exhaustivité sans reconnaître le compromis
Surapprentissage des benchmarks : obtenir 95 % sur le jeu de test, mais échouer en production parce que les vrais utilisateurs se comportent différemment
Pour l’un de nos clients du secteur financier, fortement réglementé, l’exactitude de sa solution de recherche approfondie était primordiale. Nous avons combiné des jeux de questions-réponses créés par des experts et des jeux générés par des outils afin d’évaluer la précision, la sélection des bons outils et la récupération des bonnes informations, obtenant ainsi une vision équilibrée de l’exactitude et de la qualité du raisonnement. L’essentiel était de mesurer plusieurs dimensions : exactitude factuelle (validation par des experts), qualité de récupération (précision/rappel des documents pertinents) et cohérence du raisonnement (évaluation structurée de la logique).
Quand utiliser un LLM comme juge pour évaluer une qualité nuancée
L’approche du LLM comme juge utilise un second modèle d’IA comme évaluateur, remplaçant l’examen humain par une notation automatisée et évolutive de la qualité. Le LLM comme juge est souvent utilisé à tort lorsque des métriques plus simples fourniraient l’exactitude requise. Il peut être utile lorsque des contrôles déterministes ne saisissent pas la qualité, notamment pour une métrique sémantique (utilité, ancrage factuel, qualité du raisonnement, ton, interprétation des règles) impossible à noter de façon déterministe. Vous pouvez avoir besoin de retours évolutifs sur de nombreuses variantes de prompts et de modèles, ainsi que d’un barème clair et d’un schéma de sortie structurée. Pour que cela fonctionne, suivez ces étapes :
Définissez explicitement les dimensions du barème : exactitude, ancrage factuel, conformité aux règles, caractère exploitable et ton.
Utilisez des sorties structurées (schéma JSON) pour les réponses du juge.
Consignez à la fois les scores binaires de validation et le texte de diagnostic pour analyser les échecs.
Étalonnez les résultats du juge par rapport à des échantillons annotés par des humains à chaque cycle de publication.
Pour les domaines à fort enjeu, utilisez deux juges ou des contrôles périodiques de consensus.
Suivez dans le temps la dérive du juge et le taux de désaccord.
Un jeu de données de benchmark est un ensemble fixe et sélectionné d’exemples de test aux réponses connues, utilisé pour évaluer les modèles de manière cohérente et comparer équitablement les résultats entre versions. Il comprend généralement des entrées (par exemple, des requêtes utilisateur), des sorties attendues ou des jugements de référence, ainsi que des critères ou libellés d’évaluation pour la notation. Les tests de benchmarks publics servent à comparer les performances des modèles de pointe et peuvent fournir une première indication, lors de la conception de votre système, sur les modèles qu’il serait pertinent d’exploiter.
Pour votre propre système, vous ne pouvez toutefois pas utiliser ces benchmarks comme indicateurs des performances dans votre contexte métier, car ils présentent des problèmes connus :
Contamination : les modèles peuvent avoir été entraînés sur les données du benchmark ; les évaluer avec ce même jeu revient à les noter avec une antisèche.
Saturation : les meilleurs modèles atteignent déjà les scores maximaux. L’amélioration ou la dégradation se limite donc à quelques points de pourcentage, souvent dans la variabilité naturelle des résultats des tests.
Périmètre restreint : les données des benchmarks ne reflètent pas vos tâches réelles ; elles sont fortement sélectionnées et nettoyées. Certaines sont même générées par des LLM et ne reflètent ni la complexité ni les cas limites de vos données (fautes de frappe, formulations inhabituelles, images bruitées).
Un élève demande à l’application de l’aider à résoudre des problèmes écrits.
Exemple de benchmark public utilisable : GSM8K (raisonnement mathématique de niveau primaire)
Jeu plus difficile facultatif : MATH.
Pourquoi ce benchmark est utile :
Comparer rapidement les modèles en matière de raisonnement mathématique général,
Bon premier filtre avant d’investir dans des évaluations complètes du produit.
Pourquoi votre propre jeu de données reste nécessaire :
Votre application a des exigences que GSM8K ne teste pas :
La formulation et l’ordre des sujets de votre programme,
Le style d’explication adapté à votre tranche d’âge,
La gestion des questions d’élèves ambiguës ou comportant de nombreuses fautes,
Les règles applicables (par exemple, quand donner des indices plutôt que la réponse complète).
Une validation efficace dépend de la création de benchmarks d’évaluation propres à votre application. Ces jeux de données doivent provenir d’interactions réelles, de cas limites courants et de modes de défaillance plausibles. Cette tâche peut être difficile lors de la mise en œuvre d’un nouveau produit ou processus. Toutefois, il est généralement possible de recueillir des données auprès d’un produit existant ou au plus tôt, même pendant une phase de test initiale. Après le développement de votre application, ces benchmarks doivent évoluer avec votre produit et devenir progressivement plus riches et représentatifs.
Étude de cas : création d’un benchmark personnalisé pour un assistant de banque de détail
Un chatbot bancaire répond aux questions sur les budgets, les dépenses et les transactions. Les benchmarks publics de questions-réponses et de conversion de texte en SQL ne couvraient pas les principaux risques bancaires, comme l’injection SQL, les fuites de données ou la conservation du contexte entre plusieurs échanges. Nous avons créé un benchmark personnalisé reproduisant le pipeline d’agents de ce produit.
Composants du benchmark personnalisé dans cette base de code :
Suite de red teaming composée de prompts malveillants pour tester l’injection SQL, l’extraction de données à caractère personnel, le contournement du prompt et les fuites entre sessions
Tolérance zéro en matière de sécurité : toute injection SQL, extraction de données à caractère personnel ou fuite entre sessions doit être rejetée.
Exactitude de la conservation du contexte : les requêtes reformulées doivent préserver l’intention de l’utilisateur et les entités.
À retenir : considérez la création du benchmark comme une fonctionnalité du produit. Le harnais actuel prouve que l’évaluation de bout en bout est bien intégrée, mais la couverture et la taille des échantillons doivent augmenter pour refléter les risques bancaires réels (attaques à intentions multiples, contournement des garde-fous et requêtes dépendantes du contexte). Le benchmark doit s’étendre parallèlement aux nouveaux agents et garde-fous.
Le lien entre le benchmark propre à votre application et le choix du modèle est essentiel. Votre benchmark indique non seulement si une solution fonctionne, mais aussi quelle combinaison de taille de modèle et de techniques de post-entraînement fournit les performances requises au meilleur coût. Les améliorations les plus puissantes des modèles préentraînés (le « PT » de ChatGPT) ne viennent pas d’un nouvel entraînement, mais de méthodes de « post-entraînement ».
Ces méthodes visent à déterminer les informations auxquelles le modèle accède, leur structure et la manière dont le modèle est guidé et orchestré pendant l’inférence. Parmi les techniques de post-entraînement :
Prompts de raisonnement détaillé (« chain-of-thought ») et allocation dynamique des ressources de calcul (raisonner davantage sur les problèmes difficiles)
Autocohérence, qui consiste à générer plusieurs sorties et à sélectionner la meilleure
Construction et orchestration du contexte, par exemple génération augmentée par récupération (RAG), exemples few-shot et workflows agentiques
Utilisation d’outils et accès à des connaissances externes, permettant au modèle d’agir au-delà de ses paramètres internes
Stratégies de représentation et de stockage des connaissances, conçues pour récupérer efficacement les données structurées et non structurées et raisonner à partir de celles-ci
Si ces techniques de post-entraînement peuvent nettement améliorer les performances du système, elles introduisent aussi des compromis. Chaque couche supplémentaire d’orchestration, de récupération ou de raisonnement accroît la complexité du système, le temps d’inférence et les coûts d’exploitation. Bien appliquée, la bonne combinaison de techniques de post-entraînement permet souvent d’utiliser des modèles plus petits, plus rapides et moins coûteux tout en satisfaisant les exigences de performance. Au lieu d’augmenter la taille du modèle, on obtient les performances grâce à une meilleure conception du système.
Cet équilibre est propre à chaque application et doit s’appuyer sur ses évaluations spécifiques afin de déterminer la combinaison optimale de techniques. Elles permettent de repérer le point où une orchestration supplémentaire n’apporte plus de gains significatifs et de choisir le niveau minimal de complexité post-entraînement nécessaire aux performances visées.
Une solution d’IA doit être envisagée comme un système complet : bases de données, API, interfaces utilisateur, couches d’orchestration, infrastructure de surveillance, etc. L’évaluation doit donc couvrir toute la pile technologique. Surveillez les composants clés du système pour détecter les problèmes potentiels et accélérer de façon responsable.
Surveiller les composants clés du système implique de :
Instrumenter vos pipelines afin d’obtenir des résultats mesurables.
Journaliser les expériences pour observer l’effet de chaque ajustement.
Effectuer de simples comparaisons A/B avant de déployer des changements majeurs afin de détecter d’éventuelles régressions.
L’itération fondée sur les données raccourcit le passage du prototype à la production, sans angles morts. La journalisation et la surveillance permettent aussi de comprendre l’utilisation réelle de l’application. Voici un exemple pour garantir l’observabilité :
Étape 1 : la requête utilisateur arrive avec request_id, user_segment, intent.
Étape 2 : la trace journalise la version du modèle, la version du prompt, les documents récupérés et les appels d’outils.
Étape 3 : le LLM juge note la réponse (exactitude, ancrage factuel, policy_risk).
Étape 4 : le moteur de règles évalue les seuils.
Étape 5 : si un seuil est dépassé, déclencher une alerte et rediriger vers la solution de repli ou l’examen humain.
Étape 6 : l’échec est ajouté à la file de triage, puis au backlog du benchmark.
Les vrais utilisateurs se comportent rarement exactement comme le prévoient les concepteurs. Certains comprendront mal les instructions. D’autres chercheront délibérément les points faibles. Ces cas limites ne sont pas des anomalies, mais des signaux précieux. Un pipeline d’évaluation bien mis en œuvre les capture, les analyse et les intègre aux futurs tests. Itérer rapidement sans angles morts n’est possible que si l’évaluation est intégrée au système, et non ajoutée après le développement.
Nous recommandons d’intégrer des garde-fous et une surveillance dès le premier jour :
Suivez régulièrement les métriques et les régressions du modèle grâce au benchmark propre à votre application.
Capturez et examinez les cas limites ou les entrées adverses, puis ajoutez-les au jeu de données du benchmark propre à votre application.
Veillez à aligner ces métriques d’évaluation sur vos KPI principaux.
Remettez régulièrement en question votre jeu de données et votre benchmark afin de ne pas ignorer de nouveaux risques ni subir de biais.
Mettez en place des alertes automatiques en cas de dégradation des métriques (par exemple, déclenchez un examen si l’exactitude passe sous 85 %).
Conservez un processus d’examen humain pour les décisions à fort enjeu (conseils juridiques, recommandations médicales, transactions financières).
Chaque exécution d’un benchmark consomme des ressources de calcul et de l’énergie. Chaque expérience redondante augmente les coûts. Une évaluation responsable doit concilier rigueur et efficacité.
Plusieurs mesures pratiques permettent d’éviter l’envolée de la consommation d’énergie et des coûts :
Utilisez si possible de petits modèles : réalisez les premières expériences sur des modèles moins coûteux et ne passez à l’échelle supérieure qu’après validation de l’approche.
Mettez en cache les prompts et les appels d’API.
Planifiez les traitements en tenant compte de l’énergie (traitement par lots, instances ponctuelles, priorité flexible).
Suivez l’utilisation des ressources de calcul en parallèle des performances.
Restez également attentif aux nouvelles réglementations sur l’IA. Même sans loi dédiée, les cadres existants et les mesures nécessaires restent applicables, notamment :
Protection des données :
Vérifiez que les jeux de données des benchmarks ne contiennent aucune donnée à caractère personnel sans consentement approprié
Mettez en œuvre des politiques de conservation des données pour les requêtes journalisées
Proposez des mécanismes permettant de demander la suppression des données
Égalité et biais :
Testez les performances auprès de différents groupes démographiques
Assurez une représentation diversifiée lors de la création des benchmarks
Droits humains et transparence :
Documentez clairement les limites du modèle à l’intention des utilisateurs
Expliquez les décisions à fort enjeu
Permettez un contrôle humain pour les applications critiques
L’évaluation n’est pas un événement ponctuel, mais un système évolutif. Dans un domaine en mutation rapide, votre avantage dépend de votre capacité à tester, apprendre et vous adapter vite afin de déployer plus efficacement modèles et nouvelles solutions.
En faisant de l’évaluation une activité d’ingénierie et de gestion de produit centrale, les équipes peuvent innover plus vite et plus sûrement. Commencez par définir ce qui est bon dans le contexte de votre application d’IA, mettez en place une plateforme d’évaluation, puis faites-la évoluer pour disposer d’un benchmark propre à l’application qui confirme, à chaque itération, son aptitude à la production.