Dans quels cas optimiseriez-vous le rappel plutôt que la précision, et comment fixez-vous concrètement le seuil ?

Optimisez le rappel quand un positif manqué coûte plus cher qu'une fausse alerte, comme en détection de fraude ou en dépistage médical, où un humain examine de toute façon chaque alerte. Optimisez la précision quand agir sur un positif est coûteux ou agaçant, comme envoyer des offres ou bloquer des comptes. Fixez le seuil à partir du coût attendu plutôt que de garder 0,5 par défaut, en balayant les seuils et en prenant celui qui minimise la perte attendue.

Je commence par demander ce qui se passe pour chaque type d'erreur. Sur une file de fraude, un faux négatif, c'est de l'argent qui part plus une rétrofacturation, alors qu'un faux positif coûte trente secondes du temps d'un analyste : le rappel l'emporte et je baisse le seuil. Sur un modèle de notification push, ça s'inverse : un faux positif agace un vrai utilisateur et peut vous coûter une désinstallation, donc je veux de la précision même si je touche moins de monde. Pour choisir le chiffre réel, je mets un coût approximatif sur chaque type d'erreur, je balaie le seuil sur le jeu de validation, et je trace le coût attendu. Il y a en général une cuvette nette, et je prends le milieu de la cuvette plutôt que le minimum exact, parce que le minimum saute d'un pli à l'autre. La contrainte qu'on oublie, c'est la capacité. Sur un projet de fraude, la courbe de coût disait de signaler environ quatre pour cent des transactions, mais l'équipe de revue pouvait traiter à peu près mille cas par jour, donc le vrai seuil était celui qui produisait mille alertes. Je l'ai dit franchement plutôt que de faire semblant que le choix était purement statistique.