« La fonctionnalité est utilisée par 80 % de l'équipe. » Très bien. Et parmi ces usages, combien de propositions sont reprises à la main avant validation ? Personne ne sait. C'est la conversation type d'un comité de pilotage trois mois après une mise en production : un indicateur d'adoption qui rassure, et rien pour dire si l'outil fait gagner du temps ou en fait perdre.
Une fonctionnalité IA se mesure avec six indicateurs. Aucun ne coûte cher à instrumenter, et ils se lisent ensemble.
1. L'adoption
Combien de personnes éligibles l'utilisent, à quelle fréquence, et depuis combien de temps.
Regarde la rétention plutôt que le cumul. Le chiffre qui compte : parmi ceux qui ont essayé le premier mois, combien utilisent encore la fonctionnalité le troisième. Une adoption qui monte puis retombe raconte une histoire précise — la curiosité a été satisfaite, la valeur non.
Segmente par équipe ou par rôle. Une adoption forte dans un service et nulle dans un autre pointe presque toujours vers une différence de processus, pas de motivation.
2. Le taux d'acceptation des suggestions
Sur les propositions faites, combien sont retenues telles quelles.
Attention au piège : un taux très haut n'est pas forcément une bonne nouvelle. S'il dépasse largement ce que la qualité observée en évaluation laisse attendre, c'est souvent que refuser coûte trop cher à l'utilisateur, ou qu'un contrôle en aval absorbe silencieusement les erreurs. Croise toujours ce chiffre avec ton jeu d'évaluation.
3. Le taux de correction
C'est l'indicateur central, celui que je regarde en premier.
Parmi les propositions acceptées, quelle proportion est modifiée avant validation, et sur quels champs. Ce chiffre te dit à la fois la qualité perçue et l'endroit exact où travailler.
Sa force est dans le détail. Un taux de correction global de 30 % est illisible. Le même chiffre décomposé par champ montre souvent que quatre-vingts pour cent des corrections portent sur un seul élément — une date mal interprétée, un fournisseur mal identifié. Tu tiens ton chantier d'amélioration, et il est petit.
C'est aussi l'indicateur qui dérive en silence quand le modèle change de version ou quand les documents d'entrée évoluent. Suis-le dans le temps, pas ponctuellement.
4. Le temps de tâche avant et après
Le seul indicateur qui parle vraiment au métier, et le seul qui demande un peu de travail.
Il faut une mesure avant. Une demi-journée d'observation chronométrée sur une quinzaine de cas suffit — pas une estimation déclarative, qui se trompe systématiquement dans le même sens.
Après, mesure la même chose de la même manière. Compte le temps complet : la lecture de la proposition, la vérification, la correction. Une fonctionnalité qui divise par deux le temps de saisie mais ajoute cinq minutes de relecture par dossier n'a rien fait gagner.
5. Le coût par usage
Le coût total de la période divisé par le nombre d'unités métier traitées. Coût par dossier, par demande, par document — jamais en jetons.
Deux lectures utiles : la tendance dans le temps, et la comparaison au gain estimé. Ajoute une alerte sur un plafond mensuel. C'est banal, et ça évite la facture surprise d'un traitement parti en boucle.
6. Le taux d'escalade
Quelle proportion des cas sort du chemin automatique : refus du système, passage à un traitement manuel, reprise par un collègue plus expérimenté.
Un taux d'escalade nul est suspect. Ça veut dire que le système ne dit jamais « je ne sais pas », donc qu'il répond aussi quand il ne devrait pas. Un taux qui grimpe soudainement signale un changement dans les entrées, souvent avant que la qualité perçue ne baisse.
Comment lire ces chiffres ensemble
Aucun de ces indicateurs ne se lit seul. Les combinaisons parlantes :
- Adoption haute + correction haute : les gens s'en servent parce qu'ils y sont obligés, ou parce qu'un brouillon imparfait vaut mieux que la page blanche. À creuser en entretien, pas en tableau de bord.
- Adoption basse + acceptation haute : la fonctionnalité marche bien pour ceux qui l'ont trouvée. C'est un problème de découverte ou de placement dans le parcours, pas de qualité.
- Acceptation haute + temps de tâche inchangé : le gain est ailleurs que là où tu le crois, ou il n'y en a pas. Le cas le plus fréquent, et le plus inconfortable à présenter.
- Escalade en hausse + correction stable : les entrées changent. Va regarder les nouveaux cas avant que ça se dégrade.
Instrumenter sans data team
C'est l'objection que j'entends le plus, et elle ne tient pas.
Une table, cinq colonnes : horodatage, identifiant de cas, valeur proposée, valeur validée, décision de l'utilisateur. Une ligne écrite à chaque validation. Le taux de correction se calcule ensuite par simple comparaison entre les deux valeurs — tu n'as même pas besoin de demander quoi que ce soit à l'utilisateur.
Ajoute la version du modèle et celle du prompt dans deux colonnes supplémentaires. Ça coûte dix minutes de développement, et ça permet plus tard d'attribuer une variation de qualité à un changement précis. Sans ça, tu constateras une dérive sans jamais pouvoir l'expliquer.
Pour le temps de tâche, un chronomètre et un cahier valent mieux qu'un projet d'instrumentation qui ne verra jamais le jour. Quinze mesures avant, quinze après, la même personne les fait.
Et la revue humaine par échantillon reste indispensable à côté des chiffres : une heure par semaine, vingt cas tirés au hasard, une personne qui note ce qui la surprend. Les indicateurs disent qu'il se passe quelque chose. La revue dit quoi.
Le tableau à monter en premier
Si tu ne mets qu'une chose en place ce mois-ci, mets la table à cinq colonnes. Le taux de correction par champ qui en sortira te dira en trois semaines où est le vrai problème de ta fonctionnalité — probablement pas là où l'équipe le cherche aujourd'hui.