Exactitude et couverture
Le résultat correspond-il aux faits vérifiables et couvre-t-il les éléments accessibles de la tâche ?
Méthode pilote · v0.1.1Des situations métier.
Des situations métier.
Des preuves pour décider.
Évaluer l’IA d’une application, c’est observer ce qu’elle apporte à une tâche réelle, ce qu’elle manque et ce que le professionnel doit encore vérifier.
Une question précise, un périmètre défini.
Le protocole porte sur une application et sa version, une fonction IA, des utilisateurs et des conditions d’emploi. Logiciel d’état des lieux, aide au diagnostic, outil de restauration ou IA intégrée à un robot : chaque mission commence par une tâche réellement couverte et les compétences nécessaires.
Cette version est une méthode pilote à éprouver. Aucun résultat réel ni score issu de ce protocole n’est encore publié. Les accès, experts, preuves et modalités d’essai sont confirmés au devis : Light à distance, Full avec observation terrain.
Six dimensions complémentaires.
Sécurité et conséquences métier
Un risque important est-il reconnu, avec une alerte et un recours au professionnel compétent ?
Incertitude et limites
L’application distingue-t-elle faits, hypothèses et données manquantes, sans inventer une réponse ?
Traçabilité et preuve
Peut-on relier chaque résultat au bon dossier, à sa source et à la version testée ?
Flux de travail et récupérabilité
Une erreur peut-elle être corrigée dans le travail courant, avec une correction conservée et vérifiable ?
Contrôle humain et clarté
Le professionnel comprend-il la proposition et peut-il la vérifier, la refuser ou reprendre la décision ?
Des cas usuels, difficiles et critiques.
Le pilote vise au moins six scénarios pertinents par application : trois usuels, deux difficiles et un critique au minimum. Une situation fréquente peut aussi être critique, comme une information sur un allergène. Une fonction hors périmètre appelle un autre scénario adapté ; son absence n’est pas un échec.
Dix-huit fiches candidates préparent les domaines immobilier, automobile et restauration. Elles peuvent porter sur l’attribution des photos au bon logement, les limites d’un diagnostic ou la vérification d’un ingrédient. Les situations dangereuses sont simulées hors exploitation.
Le nombre de cas et la charge sont cadrés avant engagement. Moins de six cas pertinents donnent une étude exploratoire réduite, sans indice. Six cas ne constituent pas une garantie statistique.
Le déroulement d’une évaluation.
- Préparer. Fixer la version, les conditions, les critères et la référence métier avant de consulter les réponses de l’IA. Documenter les compétences et les liens des évaluateurs.
- Observer. Conserver entrées autorisées, sorties brutes et preuves identifiées. Séparer le résultat de l’application des corrections humaines ; mesurer aussi le temps de contrôle et de reprise.
- Revoir. Le plan pilote prévoit au moins deux exécutions par cas critique, puis une seconde cotation des preuves critiques et d’un échantillon des autres cas, sans accès aux premières notes. Les désaccords sont documentés et arbitrés.
- Restituer et retester. Expliquer les écarts, leurs conséquences et les corrections prioritaires. Après une mise à jour, reprendre les cas concernés dans des conditions documentées.
Un problème d’interface, de matériel ou de données est distingué du comportement de l’IA. Les preuves partagées sont limitées aux données autorisées, avec accès et conservation convenus.
Un rapport utile à la décision.
Huit rubriques relient les observations à l’action : mission, synthèse, cadre des essais, protocole, constats, actions, annexes et revue. Le rapport indique les cas réalisés, les limites, les incidents et les points restant à vérifier.
La conclusion peut proposer un essai encadré, un usage limité sous conditions, des corrections et un contre-essai, déconseiller l’emploi dans le périmètre ou constater qu’il est impossible de conclure. Un blocage grave reste visible et ne peut pas être compensé par une bonne moyenne.
Questions sur la méthode.
Est-ce un benchmark ?
Le jeu de cas structuré aide à répéter les essais et à comparer une version corrigée. Il complète le jugement métier ; comparer deux applications exige des périmètres et conditions compatibles.
Y aura-t-il un Hu-score ?
Un indice facultatif est préparé pour un pilote privé. Il reste expérimental, sans score public ni badge. Des résultats contextualisés pourront être envisagés en V2, puis un suivi en V3 après validation de la méthode et accord du client.
Le protocole constitue-t-il une certification ?
Non. Il prépare un avis métier documenté dans un périmètre précis. Il ne certifie ni l’application ni sa conformité générale et ne remplace pas la décision du responsable d’exploitation.
Que change la vérification humaine ?
Lorsque cela est utile et possible, une référence réalisée sans l’IA peut être comparée au travail assisté, dans des conditions comparables : informations, matériel et ordre des tâches. Qualité, omissions et temps de vérification ou de correction sont examinés. Un petit pilote ne démontre pas un gain de productivité généralisable.
Repères méthodologiques
Le manuel ARIA du NIST et les ressources AI RMF alimentent cette réflexion. Les dimensions, seuils et règles du pilote sont des choix Huxpert, sans certification ni approbation du NIST.
Quelle tâche votre IA doit-elle réussir ?
Décrivez l’application, ses utilisateurs et la décision que l’évaluation doit éclairer.