Avant de fixer un seuil d’IA, utilisez une matrice du coût des erreurs

Un modèle peut être précis à 92 % et pourtant commettre les mauvaises erreurs pour votre activité. La question n'est pas seulement la fréquence de ses échecs, mais aussi la nature de chaque échec. Un faux positif laisse passer un cas problématique. Un faux négatif bloque un bon cas et crée un délai. Ces issues ont rarement le même responsable, le même coût ou le même remède.

Une matrice coût-erreur transforme cette asymétrie en décision opérationnelle. Utilisez-la avant de choisir un seuil d'IA, et non après qu'un score de précision global ait déjà orienté la discussion. La matrice ne donne pas un chiffre magique. Elle rend le compromis suffisamment explicite pour que les responsables produit, opérations, risque et service puissent choisir ensemble.

Commencez par la décision, pas par le score

Décrivez la décision exacte que le système influence : approuver ou réviser, acheminer ou retenir, publier ou escalader. Ensuite, définissez ce que signifie « positif ». Les équipes sautent souvent cette étape et découvrent plus tard que deux personnes ont utilisé « faux positif » pour désigner des choses opposées. Des étiquettes claires – faux positif et faux négatif – maintiennent la conséquence métier visible.

Évaluez le coût des deux types d'erreurs avant de modifier le seuil

Le cadre de gestion des risques liés à l'IA du NIST demande aux équipes d'examiner et de documenter les coûts potentiels des erreurs d'IA par rapport à la tolérance au risque. Ses directives de mesure préconisent également d'évaluer les taux de faux positifs et de faux négatifs dans le contexte de déploiement, plutôt que de considérer une moyenne comme l'histoire complète. C'est la raison pratique de conserver deux colonnes d'erreurs : un seuil échange toujours une partie d'un type contre une partie de l'autre.

Exemple concret : triage des remboursements

Imaginez une équipe de support envisageant une voie IA pour les demandes de remboursement. Les cas au-dessus d'un seuil de confiance seraient approuvés automatiquement ; les autres iraient à une personne. L'ensemble d'évaluation contient 1 000 demandes représentatives. Au seuil proposé, 18 demandes invalides sont acceptées et 70 demandes valides sont rejetées.

Si une approbation invalide coûte environ 90 € en remboursement, enquête et travail de récupération, l'exposition aux faux positifs est de 1 620 €. Si un remboursement valide retardé coûte environ 12 € en temps de service et en goodwill, les faux négatifs ajoutent 840 €. Ce sont des données de scénario, pas des prix universels. L'idée utile est que réduire un nombre peut augmenter l'autre. Un seuil plus strict peut économiser 540 € en remboursements invalides tout en ajoutant 720 € en révision et délai. Cette décision semble meilleure sur un taux d'erreur et pire pour l'opération.

Ajoutez maintenant les conséquences difficiles à évaluer. Un schéma de fraude suspecté peut nécessiter une révision obligatoire, quelle que soit la confiance. Un client vulnérable peut avoir besoin d'une voie d'appel rapide. La règle finale peut donc combiner un seuil avec des portes spécifiques à la catégorie, sans forcer un seul chiffre pour chaque cas.

Ne cachez pas les poches d'échecs coûteux

Un total unique peut toujours masquer un petit groupe avec des conséquences graves. Le NIST recommande des mesures au-delà des moyennes afin que les équipes puissent trouver des poches d'échec avec des coûts importants. Décomposez la matrice par type de cas, région, groupe de clients ou niveau de conséquence lorsque ces segments modifient la décision. Gardez l'échantillon suffisamment grand pour éviter de prendre le bruit pour une certitude.

Le guide de l'IA du gouvernement britannique souligne un point similaire : une grande précision peut entraîner un mauvais service si elle pousse les utilisateurs à prendre de mauvaises décisions. Un seuil est donc une politique opérationnelle, pas seulement un paramètre de modèle. Documentez son objectif, le responsable de la révision, la base de preuves et le déclencheur de changement.

Connecter le choix du seuil au reste du flux de travail

Une fois le seuil choisi, le système environnant doit toujours avoir la capacité et la remise en question nécessaires. Budgétisez le travail de révision afin que les cas en attente ne deviennent pas des retards invisibles. Estimez le coût de la file d'attente des exceptions avant que l'automatisation ne déplace les coûts en aval. Pour les recommandations plutôt que les classifications, rédigez un test d'inversion qui indique quelles preuves modifieraient la réponse.

L'artefact durable tient sur une page : décision, quatre cellules, plages de conséquences, seuils candidats, exceptions, propriétaire et date de révision. La pratique Bokili peut transformer cet artefact en une habitude d'équipe reproductible. Le but n'est pas d'éliminer toutes les erreurs. Il s'agit de choisir, d'exposer et de gouverner le compromis avant que le système ne le fasse pour vous.