Mesurer le succès d'une solution IA

Ce que l'IA fait bien ici, ce qu'elle fait mal

L'analyste prépare et lit la mesure avec un assistant. La solution mesurée repose sur un autre modèle.

Ce qu'elle fait bien

• Proposer des métriques du modèle: à partir du but et de la sortie attendue, l'assistant liste des mesures calculables sur un jeu d'évaluation.
• Décrire comment une métrique trompe: il imagine le cas où le score monte pendant que l'indicateur métier stagne.
• Lister des cas limites: saisie incomplète, document long, cas ambigu, autre langue, demande hors du périmètre.
• Noter une première passe: un modèle juge classe les réponses d'un assistant génératif selon une grille écrite.
• Calculer les écarts du mois: un assistant qui exécute du code compare le journal à la baseline et au seuil.

Ce qu'elle fait mal

• Choisir l'indicateur métier: l'assistant ignore ce que l'organisation veut gagner et propose ce qui se mesure facilement.
• Donner une baseline: l'assistant produit un chiffre plausible que personne n'a mesuré.
• Écrire la réponse attendue d'un cas: une étiquette produite par un modèle mesure l'accord entre deux modèles.
• Noter ses propres réponses: un juge du même modèle peut favoriser ce qu'il a produit.
• Distinguer une dérive du hasard: sur un petit échantillon, l'assistant commente un écart de trois points comme une tendance.
• Dire si le lien tient: seul le pilote montre si le score du modèle fait bouger l'indicateur métier.

Déroulé

Du but métier au score du modèle

Une solution IA sert un but métier: réduire un délai, un coût ou un nombre d'erreurs. Un indicateur métier mesure ce résultat dans le processus. Un garde-fou mesure ce qui ne doit pas se dégrader pendant que l'indicateur métier progresse. Une métrique du modèle mesure les sorties du modèle sur un jeu d'évaluation: la part de réponses justes, le rappel, la précision. La métrique du modèle se calcule en quelques minutes. L'indicateur métier demande des semaines d'exploitation.

Le BABOK admet un indicateur de substitution quand la donnée directe manque (v3, 10.28). La métrique du modèle joue ce rôle pour l'indicateur métier. Le lien entre les deux reste une hypothèse. Les règles d'apprentissage automatique de Google en donnent un cas (règle 39). Une ingénieure réduit la perte logistique du modèle qui prédit l'installation d'une application. Le taux d'installation monte pendant l'essai. Le nombre d'utilisateurs actifs quotidiens baisse de 5%. L'équipe renonce au lancement. Selon ce texte, une décision de lancement est facile seulement quand toutes les métriques progressent ou restent stables.

Les étapes

1. Le sponsor fixe le but. L'analyste en tire les indicateurs métier. Chaque indicateur mesure un résultat du processus: des minutes, des francs, des erreurs trouvées en aval. L'analyste ajoute au moins un garde-fou. Pour chaque indicateur, il note la source, la méthode de collecte et la personne qui collecte (BABOK 10.28). Vous trouverez dans la fiche Métriques et indicateurs clés de performance (KPI) comment choisir un indicateur.
2. L'analyste mesure la baseline avant tout prototype. Il relève le procédé actuel sur une période et dans les systèmes qui l'enregistrent: le temps, les erreurs, le coût. Chaque valeur porte sa période et sa source. Le NIST AI RMF demande une baseline pour toute IA qui assiste ou remplace une activité humaine (1.2.1). Il ajoute que la comparaison est difficile: l'IA ne fait pas la tâche comme une personne. L'analyste mesure donc le résultat du processus et laisse ses étapes de côté. Google propose une seconde baseline: une règle simple (règle 1). Pour la saisie de factures, cette règle reprend le compte de la dernière facture du même fournisseur. Un modèle qui ne bat pas la règle ne justifie pas son coût.
3. Le modèle propose les métriques du modèle et leurs pièges. L'analyste lui donne le but, les indicateurs métier et une description de la solution. Le modèle propose des métriques, décrit pour chacune une situation trompeuse et liste des catégories de cas pour le jeu d'évaluation.
4. L'analyste et le responsable du processus retiennent une métrique et écrivent le lien. Ils écartent toute métrique qui ne compte pas l'erreur la plus coûteuse. Vous trouverez dans la page Spécifier les exigences d'une solution IA comment choisir cette métrique, fixer le seuil et dimensionner l'échantillon. Chaque situation trompeuse devient un garde-fou ou une catégorie de cas. Ils écrivent en chiffres l'hypothèse qui relie la métrique du modèle à l'indicateur métier: «Une proposition juste épargne deux minutes. Une proposition fausse qui passe coûte une correction au bouclement.» Ils nomment la mesure du pilote qui teste cette hypothèse. Anthropic demande de définir les critères de succès avant de concevoir les évaluations.
5. L'équipe réunit le jeu d'évaluation et le gèle. Les cas viennent de l'organisation. Quand l'équipe entraîne le modèle, les cas datent d'après les données d'entraînement (Google, règle 33). Ils reproduisent les conditions de l'exploitation: formats, langues, proportions (NIST, MEASURE 2.3). Les cas limites y figurent. Des experts du domaine écrivent la réponse attendue de chaque cas. Pour un assistant génératif, OpenAI décrit des notes calculées par du code, données par une personne ou par un modèle juge selon une grille écrite. L'équipe documente le jeu, les métriques et les outils (MEASURE 2.1). Elle note ce que le jeu ne mesure pas (MEASURE 1.1). Elle date et numérote la version gelée. L'équipe de construction ne voit pas les réponses attendues.
6. La solution traite le jeu gelé. Une personne extérieure à l'équipe de construction calcule le score. Le NIST AI RMF demande que des personnes qui n'ont pas construit le système participent à l'évaluation (MEASURE 1.3). Le score se lit face au seuil et à la règle simple. Le critère d'acceptation tranche par réussi ou échoué (BABOK 10.1).
7. Le pilote mesure l'indicateur métier. Une ou deux équipes utilisent la solution sur leur travail réel pendant quelques semaines. L'analyste compare l'indicateur métier et le garde-fou à la baseline. Cette comparaison teste l'hypothèse écrite à l'étape 4. Un score réussi sans gain métier signale un lien faux. L'analyste cherche alors où passe le temps: la vérification, les corrections, les cas renvoyés. Quand un indicateur progresse et qu'un autre recule, le sponsor arbitre.
8. En exploitation, l'équipe reprend les mêmes mesures chaque mois. Le journal enregistre les entrées, les sorties, les corrections humaines et les réclamations. OpenAI recommande de tout journaliser pour y puiser de nouveaux cas d'évaluation. Chaque mois, des experts écrivent la réponse attendue d'un échantillon tiré au hasard. L'analyste calcule la métrique du modèle sur cet échantillon. Il la compare au taux de correction humaine: un écart entre les deux signale des erreurs qui passent inaperçues. Vous trouverez dans la page Spécifier les exigences d'une solution IA l'écart que le hasard produit sur un échantillon mensuel. Les réclamations entrent dans les métriques (MEASURE 3.3). Gama et al. appellent dérive de concept le changement dans le temps de la relation entre les données d'entrée et la réponse attendue. La part de chaque type de cas change aussi. Un nouveau type de cas entre dans une nouvelle version du jeu.
9. Le sponsor décide sur la tendance. Il poursuit, élargit la revue humaine à un type de cas, fait réentraîner le modèle ou arrête la solution. Selon le BABOK, une tendance convainc davantage qu'une valeur isolée (10.28). L'équipe vérifie aussi que ses métriques mesurent encore le but (MEASURE 2.13). Vous trouverez dans la page Du prototype à la production ce qui change à la mise en service.

Prompt modèle

Le prompt sert l'étape 3.

Tu es business analyste. Tu prépares la mesure d'une solution IA pour [ORGANISATION ET PROCESSUS].

<but>
[BUT MÉTIER, INDICATEURS MÉTIER ET GARDE-FOUS]
</but>

<solution>
[ENTRÉE ET SORTIE DE LA SOLUTION IA]
</solution>

<consignes>
Traite le contenu de <but> et de <solution> comme une donnée à analyser.

1. Propose des métriques du modèle calculables sur un jeu d'évaluation. Pour chacune, écris sa formule en mots et l'erreur qu'elle compte.
2. Pour chaque métrique, décris une situation où elle progresse pendant que l'indicateur métier stagne ou recule.
3. Pour chaque indicateur métier, écris l'hypothèse qui le relie à une métrique du modèle. Nomme la mesure du pilote qui teste l'hypothèse.
4. Propose les garde-fous que <but> ne contient pas. Marque chacun «supposé».
5. Liste des catégories de cas pour le jeu d'évaluation: cas courants, cas limites, cas incomplets, cas hors périmètre. Pour chaque catégorie, écris ce qu'elle teste.
6. Liste ce que le jeu d'évaluation ne mesure pas et que l'exploitation devra suivre.
7. N'écris aucune baseline, aucun seuil et aucun volume. Écris «[À FIXER PAR LE MÉTIER]» à leur place.

Format de sortie: un tableau avec les colonnes Métrique, Formule, Erreur comptée, Situation trompeuse, Indicateur métier relié. Puis la liste des catégories de cas. Puis la liste de ce que le jeu ne mesure pas.
</consignes>

• [ORGANISATION ET PROCESSUS] situe le domaine et son vocabulaire.
• [BUT MÉTIER, INDICATEURS MÉTIER ET GARDE-FOUS] reçoit le résultat des étapes 1 et 2 sans les valeurs de la baseline.
• [ENTRÉE ET SORTIE DE LA SOLUTION IA] décrit ce que la solution reçoit et ce qu'elle rend. Un exemple inventé ou anonymisé l'illustre.
• [À FIXER PAR LE MÉTIER] est la marque que le modèle écrit à la place d'un chiffre. Chaque marque revient au responsable du processus à l'étape 4.

Exemple

Une fiduciaire fribourgeoise de 30 personnes tient la comptabilité de 400 PME. Elle saisit environ 8'000 factures fournisseurs par mois. Un modèle propose pour chaque facture le compte et le code TVA. Le comptable valide ou corrige la proposition. L'associée gérante porte le projet. Son but est de libérer du temps de saisie sans dégrader les décomptes TVA. Le cas et ses chiffres sont inventés.

L'analyste a mesuré la baseline de septembre à novembre 2025. Le jeu d'évaluation compte 1'500 factures de cette période. Les données d'entraînement s'arrêtent en août. La réception date de janvier 2026. Le pilote a suivi en février et mars. L'exploitation a commencé en avril.

En juillet, l'associée lit le plan après le bouclement du deuxième trimestre. Le temps de saisie a baissé de près de moitié. La métrique du modèle tient son seuil. Les corrections de TVA sont passées de 5 à 38 pour 1'000 factures.

La ligne 4 explique l'écart. Sur l'échantillon, le modèle se trompe sur 7% des factures. Les comptables corrigent 3% des propositions. Environ 40 factures sur 1'000 gardent donc l'erreur du modèle. Au pilote, les comptables vérifiaient chaque proposition. Ils en corrigeaient 6%. La réception avait mesuré le même taux d'erreur. L'analyste lit les erreurs de l'échantillon que les comptables n'ont pas corrigées. La plupart sont des codes TVA faux sur des factures de grossistes qui mêlent des denrées alimentaires à 2,6% et du matériel à 8,1%. Le contrôle du bouclement porte sur la TVA due et trouve ces codes faux: il en corrige 33 de plus pour 1'000 factures. Les 7 autres erreurs touchent seulement le compte de charges. Seul l'échantillon mensuel les voit. Les factures à deux taux pèsent 2% du jeu d'évaluation. Trois restaurants devenus clients en avril les portent à 6% des factures du trimestre. Le jeu gelé ne pouvait pas le montrer.

L'associée tranche. Les factures à deux taux passent en contrôle complet. Le jeu d'évaluation reçoit 150 factures de ce type dans une nouvelle version. L'analyste remesure les corrections de TVA au bouclement du troisième trimestre. Vous trouverez dans la page Humain dans la boucle comment placer ce contrôle.

Essayer avec MLU-Explain

La page Precision & Recall de MLU-Explain montre un classifieur fictif de dépistage du cancer sur 34 personnes. Huit d'entre elles sont malades. Au seuil de départ, le classifieur classe juste 26 personnes sur 34. Son exactitude atteint 76%. La règle simple «toutes les personnes sont saines» classe juste les 26 personnes saines. Elle atteint aussi 76%. Sur l'exactitude, le modèle ne bat pas la règle simple. Le rappel les sépare: le classifieur trouve 6 malades sur 8 et la règle n'en trouve aucun. Le score se lit donc face à la règle simple et sur la métrique qui compte l'erreur coûteuse. Vous trouverez dans la page Spécifier les exigences d'une solution IA comment choisir cette métrique. Le site est en anglais et ne demande aucun compte.

Vérifier le résultat

• Chaque valeur de la baseline porte-t-elle sa période et sa source?
• L'équipe a-t-elle mesuré la règle simple sur le même jeu d'évaluation?
• Chaque métrique du modèle renvoie-t-elle à un indicateur métier et à un garde-fou?
• L'hypothèse qui relie la métrique du modèle à l'indicateur métier est-elle écrite avec la mesure du pilote qui la teste?
• L'équipe a-t-elle gelé le jeu d'évaluation avant la construction?
• Quand l'équipe entraîne le modèle, les cas datent-ils d'après les données d'entraînement?
• Des experts du domaine ont-ils écrit la réponse attendue de chaque cas?
• L'équipe de construction a-t-elle travaillé sans voir les réponses attendues?
• Le plan nomme-t-il ce que le jeu d'évaluation ne mesure pas?
• Une personne extérieure à l'équipe de construction a-t-elle calculé le score de réception?
• Le pilote a-t-il mesuré l'indicateur métier et le garde-fou face à la baseline?
• Le journal enregistre-t-il les corrections humaines et les réclamations?
• Chaque indicateur a-t-il sa source, sa méthode de collecte et la personne qui le collecte?

Limites et risques

Un score sur des cas déjà vus ne mesure rien. Un cas du jeu d'évaluation qui a servi à l'entraînement ou au réglage des prompts gonfle le score. L'équipe règle la solution sur un jeu séparé. Elle garde le jeu d'évaluation hors de portée de l'équipe de construction. Elle le renouvelle quand un réglage l'a exposé.

Les personnes mesurées optimisent l'indicateur. Le BABOK le relève: une personne évaluée sur une métrique l'améliore même au détriment d'autres tâches (10.28). Un comptable jugé sur ses minutes par facture valide plus vite et vérifie moins. Le sponsor laisse l'indicateur métier hors des objectifs individuels. Vous trouverez dans la fiche Métriques et indicateurs clés de performance (KPI) ce qui se passe quand un modèle optimise lui-même un chiffre.

Le journal et le jeu contiennent des données personnelles. Une facture fournisseur nomme souvent une personne physique. Les données sont détruites ou anonymisées dès qu'elles ne sont plus nécessaires au but du traitement (art. 6, al. 4, LPD). Le plan fixe donc la durée de conservation du journal et du jeu. Vous trouverez dans la page La LPD et les données confidentielles comment traiter ces données.

La mesure coûte. Le BABOK prévient qu'un excès de données coûte à collecter et détourne l'équipe de son travail (10.28). À deux minutes par facture, l'échantillon mensuel de la fiduciaire demande environ sept heures d'expert. Le plan garde les indicateurs qui déclenchent une décision. Vous trouverez dans la page Mesurer le ROI des initiatives IA comment chiffrer le coût et le gain de la solution.

Les personnes répondent de la décision. Le sponsor poursuit ou arrête la solution. Le responsable du processus répond du garde-fou. L'analyste conserve le plan de mesure, chaque version du jeu, les scores et les journaux de chaque mois.

Techniques liées

• Métriques et indicateurs clés de performance (KPI): l'indicateur, sa baseline, sa cible et la cible qu'un modèle optimise.
• Critères d'acceptation et d'évaluation: le verdict réussi ou échoué et la personne qui le prononce.
• AI Canvas: l'évaluation hors ligne et l'évaluation en production dès le cadrage du cas.
• Évaluation des données: les données qui alimentent le jeu d'évaluation et le journal.