Comment concevoir sa propre évaluation d’IA : du cas d’usage à un seuil de déploiement vérifiable

Les benchmarks publics constituent un signal initial, pas une décision de déploiement

Un tableau de benchmarks répond, au mieux, à une question circonscrite : comment un modèle a-t-il performé selon un protocole précis, avec un ensemble de tâches, une version et des règles de notation déterminés ? Il ne répond pas à lui seul à la question de savoir si un assistant sera utile, sûr, suffisamment rapide ou acceptable en termes de coût dans un processus réel. Cette distinction est importante, car un produit ne se compose pas uniquement d’un modèle. Il comprend des instructions, des outils, la récupération de documents, des formats de sortie, des contrôles d’accès, une interface, des personnes chargées de la supervision et des procédures d’exception.

Les benchmarks peuvent aider à réduire le nombre de candidats et à formuler des hypothèses. Par exemple, un test public orienté programmation peut être pertinent lorsque le travail ressemble à la résolution d’incidents logiciels ; un test en terminal peut apporter des informations lorsque l’agent doit opérer dans des terminaux et des environnements réels ; et un autre centré sur les interfaces peut être plus proche du besoin lorsque la tâche exige l’utilisation d’interfaces graphiques. Toutefois, cette similarité apparente ne supprime pas la nécessité de tester son propre flux, avec les contraintes et les données que le système rencontrera réellement.

La littérature pratique sur les benchmarks de modèles souligne des limites telles que la contamination des données, les différences de configuration et des résultats qui ne capturent ni la latence ni l’intégration d’outils. Ces limites n’invalident pas les tests publics : elles délimitent le type d’inférence qu’ils autorisent. L’approche recommandée consiste à utiliser leurs résultats comme contexte externe et à réserver la décision produit à une évaluation locale, répétable et documentée.

Pour explorer cette différence, il convient d’inclure dans le cluster éditorial la ressource « Ce que les benchmarks publics peuvent apporter — et ce qu’ils ne peuvent pas apporter ». Ce guide doit également être relié depuis la page matrice d’apprentissage, dans le bloc « Guides pour mettre en œuvre et vérifier », et recevoir un lien depuis la découverte via le module « Avant de choisir un modèle : évaluez-le avec votre cas d’usage ». La publication doit dépendre de la mise en œuvre ou de la planification de ces destinations et de leur navigation au sein du même cluster.

Traduire le problème en une hypothèse évaluable

Le point de départ ne devrait pas être « quel modèle obtient le plus de points ? », mais une description vérifiable de la tâche. Identifiez qui utilise le système, quelle entrée il fournit, quel résultat il attend, quelles actions ultérieures dépendent de ce résultat et ce qui se produit lorsque le système échoue. Une mauvaise classification d’une demande commerciale peut exiger une correction ; une réponse qui attribue à tort une affirmation à un document interne peut entraîner une mauvaise décision ; une action externe non autorisée peut avoir des conséquences plus graves. La métrique et le seuil doivent refléter cette différence.

Une hypothèse utile prend une forme conditionnelle : pour un segment défini d’utilisateurs et de tâches, le système produit un résultat qui satisfait à des critères explicites, avec un niveau de qualité, de temps et de coût compatible avec le processus, sans dépasser un budget d’erreurs. Cette formulation oblige à définir ce que signifie « satisfait ». Dans une extraction structurée, cela peut signifier que les champs sont valides et corrects. Dans un résumé, cela peut exiger la couverture des points pertinents, l’absence d’inventions et l’attribution aux sources disponibles. Dans un agent, il peut s’agir d’achever une tâche sans violer les autorisations ni nécessiter davantage d’intervention humaine que prévu.

Microsoft décrit, pour la priorisation des cas d’usage, un cadre qui combine faisabilité commerciale, expérience et commodité, ainsi que faisabilité technologique. Il s’agit d’un cadre de priorisation, non d’un test de qualité de modèle ; il permet néanmoins d’éviter une omission fréquente : évaluer la capacité technique sans vérifier que le cas dispose d’un processus, d’un responsable, de données, d’une expérience utilisateur et d’un bénéfice opérationnel plausibles.

Délimiter et versionner le système dans son ensemble

La reproductibilité impose de déclarer ce qui a été comparé. Enregistrez le fournisseur et la version ou l’identifiant du modèle lorsqu’ils sont disponibles, la date d’exécution, les paramètres de génération, le modèle d’instructions, le message système, les outils disponibles, leurs versions, le schéma de sortie, l’index de récupération, la version des documents et les règles d’autorisation. Ajoutez la logique de nouvelle tentative, de validation, de repli et d’escalade humaine. Si cette configuration ne peut pas être reconstruite, une différence de résultat entre deux exécutions sera difficile à interpréter.

Tous les composants ne changent pas à la même fréquence. Un fournisseur peut mettre à jour un service, les documents internes peuvent changer chaque jour et une équipe peut modifier une instruction pour résoudre une défaillance. L’enregistrement n’empêche pas ces changements, mais il permet de savoir ce qui a changé avant d’attribuer une amélioration ou une régression au modèle. Il est particulièrement important de ne pas comparer une alternative avec une récupération mise à jour à une autre utilisant un index antérieur, ni d’attribuer à une variante de modèle un résultat produit par un prompt différent.

Le gel ne signifie pas l’immobilisation du produit. Pendant un cycle d’évaluation, il consiste à fixer une configuration candidate et un jeu de tests avant d’observer les résultats. Une fois le cycle terminé, une nouvelle version peut être proposée, mais elle doit être réévaluée par rapport à la même référence ou à une référence explicitement mise à jour. Cette discipline réduit le risque de sélectionner rétrospectivement le prompt qui a eu de la chance sur le test.

Construire un jeu d’évaluation représentatif et séparé

Un jeu d’évaluation doit représenter les décisions et les conditions d’exploitation, et non seulement des exemples faciles ou mémorables. Commencez par échantillonner des tâches historiques, en observant les segments pertinents : langue, longueur, type de document, canal d’entrée, niveau d’ambiguïté, cas fréquents et cas à fort impact. Ajoutez ensuite délibérément des cas difficiles : instructions contradictoires, informations incomplètes, documents obsolètes, entrées mal formées, demandes hors périmètre et situations dans lesquelles la bonne réponse est de s’abstenir ou de demander des précisions.

Séparez au minimum deux partitions : développement et test. Celle de développement sert à concevoir les prompts, les règles, les outils et les grilles d’évaluation. Celle de test est réservée à une comparaison finale ou à des jalons définis. La raison méthodologique est simple : si le système est ajusté à plusieurs reprises après l’observation des résultats sur les mêmes cas, ces observations cessent de mesurer la généralisation et deviennent une partie du développement. Une troisième partition de validation peut être utile dans les projets disposant de suffisamment de données, mais ce n’est pas une exigence universelle ; l’essentiel est de documenter l’usage de chaque cas.

Les données privées introduisent des obligations pratiques supplémentaires. Réduisez au minimum les données personnelles et les secrets inclus dans l’évaluation, appliquez des contrôles d’accès et évitez de transporter du contenu sensible vers des environnements non autorisés. Le présent guide ne détermine pas à lui seul la licéité d’un traitement ni les exigences contractuelles applicables aux fournisseurs. Avant d’intégrer des documents privés, il est recommandé d’utiliser la ressource prévue « Exemple de matrice d’évaluation pour des documents sensibles » et de valider les conditions applicables avec les fonctions juridique, sécurité et protection des données.

Les cas synthétiques peuvent étendre la couverture lorsque les exemples manquent, mais ils ne remplacent pas automatiquement la réalité opérationnelle. Ils doivent être étiquetés comme synthétiques, révisés et maintenus séparés dans les rapports. Si seuls les cas créés pour la démonstration fonctionnent, l’évaluation ne fournit pas d’éléments de preuve suffisants sur le comportement en production.

Choisir des métriques correspondant à la tâche et au risque

Il n’existe pas de métrique unique pour les systèmes génératifs. La correspondance littérale peut être raisonnable lorsqu’une sortie est une étiquette fermée ou une valeur exacte, mais elle est généralement insuffisante pour des résumés, des réponses ouvertes ou des plans d’action. Dans ces cas, une grille d’évaluation humaine peut apprécier séparément plusieurs aspects : exactitude factuelle, couverture, clarté, respect des instructions, usage approprié des sources et reconnaissance de l’incertitude. L’évaluation automatisée peut compléter ce travail avec des validateurs de schéma, des règles métier, la vérification des champs obligatoires et des tests de sécurité ; elle ne devrait pas masquer les propriétés qu’elle ne peut pas vérifier.

Pour la génération augmentée par récupération avec sources, mesurez séparément la récupération et la génération. Parmi d’autres signaux, vous pouvez examiner si des éléments de preuve pertinents ont été récupérés, si les affirmations importantes sont étayées par les éléments disponibles, si les citations ou références correspondent au contenu et si le système s’abstient lorsque les preuves sont insuffisantes. Une réponse fluide ne démontre pas la fidélité. La ressource prévue « Comment évaluer la fidélité, la couverture et les citations dans les systèmes RAG » peut approfondir ces critères.

Dans les sorties structurées, mesurez la validité du schéma, la présence des champs, l’exactitude sémantique de chaque champ et la récupération après une erreur. Un JSON formellement valide peut continuer à classer incorrectement ; une classification correcte peut être inutilisable si un champ requis manque. Pour concevoir ces tests, la ressource « Comment mesurer la validité du schéma et la récupération après erreur » est prévue.

Ajoutez des métriques opérationnelles : latence par percentiles et par segment, coût par tâche achevée, fréquence des nouvelles tentatives, taux de repli, intervention humaine et réussite de bout en bout. Présentez des distributions en plus des moyennes lorsque cela est possible, car une moyenne peut masquer des queues de latence ou des segments aux résultats systématiquement moins bons. Les seuils ne se déduisent pas d’un chiffre universel : ils dépendent du processus, du volume, du préjudice et de la capacité de supervision.

Concevoir la grille d’évaluation et contrôler les désaccords humains

Une grille d’évaluation transforme des jugements généraux en décisions observables. Au lieu de demander « la réponse est-elle bonne ? », définissez des dimensions, des échelles et des exemples. Pour l’assistant de retours clients, une dimension de fidélité pourrait distinguer : toutes les affirmations pertinentes sont étayées par le texte ; de petites inférences acceptables sont signalées ; des affirmations ne sont pas étayées ; et des attributions sont manifestement fausses. Une autre dimension peut évaluer si la catégorie et la priorité respectent les définitions opérationnelles de l’équipe.

Certains contrôles peuvent être automatisés de manière déterministe : analyse d’un schéma, limites de longueur, champs interdits, correspondance avec une liste d’autorisations ou présence de références requises. D’autres exigent une interprétation. Un évaluateur fondé sur un autre modèle peut accélérer le tri, mais il doit être calibré par rapport à des annotations humaines sur un échantillon représentatif, et ses erreurs doivent être analysées. Il ne convient pas de le considérer comme un arbitre indépendant ni de l’utiliser pour remplacer la revue humaine dans les cas aux conséquences élevées.

Pour mesurer l’accord, deux évaluateurs peuvent être comparés au moyen d’un pourcentage de concordance sur des critères simples ou d’une mesure d’accord tenant compte de la concordance attendue par hasard, telle que le kappa, à condition que l’échelle et la distribution le permettent. Il n’existe pas de niveau universel de désaccord qui invalide une évaluation. Comme règle opérationnelle, revoyez la grille si le désaccord touche des cas qui décideraient du déploiement, s’il se concentre sur une dimension critique ou si les évaluateurs interprètent le critère de manière incompatible. Documentez la révision et, si les règles changent, réévaluez les cas concernés.

Comparer équitablement et décider avec des seuils explicites

Définissez les seuils avant d’exécuter la comparaison finale. Établissez des bloqueurs absolus, des minima par segment et des objectifs opérationnels. Un bloqueur peut être une sortie révélant des informations non autorisées, une action exécutée sans confirmation requise, une violation d’autorisation ou une affirmation critique non étayée dans un contexte où le système se présente comme fondé sur des sources. Un minimum par segment évite qu’un résultat global acceptable masque un comportement inacceptable pour une langue, un type de document ou un groupe d’utilisateurs.

Une décision peut avoir trois issues : déployer avec des contrôles, itérer ou écarter. Le déploiement avec contrôles n’est approprié que si les bloqueurs sont nuls dans la couverture évaluée, si les minima convenus sont atteints et si une supervision compatible avec le risque résiduel existe. Itérer implique d’identifier ce qui changera et la manière dont cela sera mesuré à nouveau. Écarter peut être la conclusion responsable s’il n’existe aucune configuration qui atteigne le seuil dans les limites de coût, de latence ou de sécurité.

Dans les agents exécutant des actions externes, l’évaluation doit tester explicitement les autorisations, les confirmations, le périmètre et la réversibilité. Il ne suffit pas que la tâche se termine avec succès. La ressource prévue « Tests des autorisations, confirmations et de la réversibilité avant de donner des actions à l’agent » doit couvrir ce type de validation. Ce guide ne fixe pas d’exigences réglementaires précises de l’AI Act européen : les sources vérifiées fournies ne constituent pas un texte normatif primaire suffisant pour déterminer les articles, les dates ou les obligations applicables. Cet examen doit être mené à partir de sources juridiques en vigueur et avec des conseils spécialisés.

Surveiller après le déploiement et conserver le registre de décision

Le déploiement ne transforme pas l’évaluation en une formalité close. Les entrées des utilisateurs, les documents récupérés, les modèles des fournisseurs, les outils et les schémas d’abus changent. Instrumentez des traces avec une minimisation appropriée des données afin de relier une sortie à sa configuration, à la récupération, aux outils, au temps de réponse, au coût, aux validations, au repli et à l’intervention humaine. La ressource prévue « Comment instrumenter les traces, la latence et le coût par tâche » peut servir de suite opérationnelle.

Définissez des signaux d’alerte : hausse des erreurs de schéma, baisse de la réussite par segment, croissance des abstentions ou des nouvelles tentatives, retards dans les percentiles élevés, augmentation du coût par tâche, réclamations examinées et événements d’autorisation. Échantillonnez des résultats de production pour une évaluation humaine, avec des procédures respectant les contrôles de données applicables. Planifiez des réévaluations après des changements significatifs, ainsi que périodiquement, même lorsqu’aucun changement n’est déclaré, car une dépendance externe peut varier.

Le modèle final doit réunir une fiche d’évaluation, la matrice de résultats et un registre de décision. La fiche comprend l’objectif, les segments, les risques, la configuration versionnée, la provenance des données et les métriques. La matrice présente les résultats agrégés et par segment, avec les cas critiques. Le registre explique quels éléments de preuve ont été examinés, quels seuils ont été appliqués, quelles limites subsistent, qui a approuvé la décision et quand le test doit être répété. Comme navigation de clôture, ajoutez « Étape suivante » vers un modèle téléchargeable ou un article connexe sur l’observabilité. Cette clôture ne doit pas être publiée comme lien actif si la destination n’existe pas ou n’est pas planifiée dans le cluster.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.