Un modèle indique qu’un client risque de partir. La personne qui doit intervenir ne va probablement pas demander quel algorithme a été choisi. Elle veut surtout comprendre pourquoi ce client ressort aujourd’hui.

C’est souvent à ce moment-là que la démo devient un vrai projet. Un score ne sort pas d’une boîte noire par magie : le pipeline transforme le dossier en variables, le modèle combine ces valeurs, puis une règle décide si le résultat mérite une action.

Du dossier client au score

Prenons une régression logistique très simple. Le pipeline calcule trois features normalisées : le temps depuis la dernière commande, la baisse des achats et le nombre de plaintes. Le modèle multiplie chaque valeur par un poids appris, ajoute un biais, puis transforme la somme en probabilité avec une fonction logistique.

score brut = biais
           + 1,2 × jours_sans_commande
           + 0,8 × baisse_achats
           + 0,5 × plaintes

score brut = -1,0 + 1,2×0,9 + 0,8×0,6 + 0,5×0,2
           = 0,66

probabilité = 1 / (1 + e^-0,66) ≈ 0,66

Si le seuil d’intervention est 0,60, ce client entre dans la file d’appels. L’explication locale peut montrer que l’inactivité a ajouté +1,08, la baisse des achats +0,48 et les plaintes +0,10, pendant que le biais retirait -1,0. La personne comprend alors ce qui a poussé le score au-dessus du seuil.

Cette contribution n’est pas une cause. Elle dit comment le modèle a calculé sa réponse avec ses données. Une longue période sans commande peut être liée au départ du client, mais l’explication ne prouve pas pourquoi il est parti. La différence est importante quand quelqu’un doit agir.

Choisir le seuil avec les erreurs

Un taux d’exactitude global peut paraître excellent sans aider le workflow. Sur 1 000 clients, imaginons 100 départs réels. Avec un seuil donné, le modèle signale 160 personnes :

• 70 sont de vrais départs détectés;
• 90 sont de faux positifs qui auraient peut-être reçu une offre inutile;
• 30 départs sont manqués;
• 810 clients sont correctement laissés tranquilles.

La précision des alertes est 70 / 160, environ 44 %. Le rappel est 70 / 100, donc 70 %. Baisser le seuil détectera probablement plus de départs, mais ajoutera des appels. Le bon seuil dépend de la capacité de l’équipe, du coût de l’offre, de la valeur d’un client retenu et du tort causé par une intervention mal ciblée.

Je testerais au moins trois scénarios de seuil avec les opérations. Une équipe capable de rappeler 50 clients par semaine ne peut pas utiliser une file de 500 sans priorité. Le système doit aussi enregistrer la version du modèle et le seuil qui ont produit la recommandation; sinon, on ne peut pas reconstruire une décision plus tard.

Expliquer, contester et s’abstenir

Pour chaque dossier, l’écran pourrait montrer :

1. le score et le seuil appliqué;
2. les trois features qui ont le plus déplacé ce score;
3. la fraîcheur et la provenance de ces données;
4. les cas semblables où le modèle s’est trompé;
5. une action pour accepter, corriger ou ignorer la recommandation.

Le niveau d’explication dépend du risque. Classer une photo et influencer l’accès à un service, ce n’est pas la même chose. Plus la conséquence est importante, plus il faut pouvoir comprendre le calcul, contester les données et faire réviser la décision.

Je ne crois pas non plus au raccourci « modèle complexe opaque, modèle simple honnête ». On peut approximer localement les contributions d’un système complexe. Et une régression très lisible peut donner une explication propre basée sur une mauvaise étiquette, une fuite de données ou une variable proxy. L’explication du calcul ne remplace pas l’audit du jeu d’entraînement.

Il faut aussi prévoir l’abstention. Un dossier peut contenir trop de valeurs manquantes, être très différent de l’entraînement ou produire un score collé au seuil. Dans ces cas, le système devrait dire « révision manuelle » au lieu d’inventer une confiance. Une règle simple pourrait refuser l’automatisation lorsque plus de 30 % des features manquent ou lorsque le dossier est hors des plages observées.

Après l’appel, l’équipe conserve la décision, la raison d’une correction et le résultat. Cette boucle permet de mesurer les erreurs, de trouver une feature devenue périmée et de voir si les explications aident réellement la personne plutôt que de simplement décorer l’écran.

Avant d’étendre l’usage, je veux donc être capable de partir d’un dossier, refaire ses transformations, expliquer ce qui a franchi le seuil et montrer le coût des erreurs autour de ce seuil. Si on ne peut pas reconstruire cette chaîne, je ne mettrais pas encore le modèle dans les mains de quelqu’un qui doit agir.