Un historique ne devient pas neutre parce qu’on l’appelle maintenant un jeu d’entraînement.

Plus je creuse l’apprentissage automatique, plus ce point revient. Les données gardent des faits, mais aussi les habitudes, les oublis et les limites du processus qui les a produites. Le modèle apprend tout ça ensemble parce qu’il optimise une cible; il ne sait pas quelles colonnes décrivent le monde et lesquelles décrivent une ancienne décision humaine.

Comment le biais entre dans la table

Imaginons un système qui suggère quels clients rappeler. Pour produire la cible, on marque 1 lorsqu’un ancien appel a mené à une vente et 0 autrement. Le pipeline extrait ensuite le type de compte, la région, les achats passés et le résultat de l’appel.

Le problème apparaît avant même l’algorithme :

1. l’équipe choisissait déjà qui appeler;
2. seuls les clients appelés ont un résultat observable;
3. le code de résultat mélange parfois refus, absence et numéro invalide;
4. le modèle apprend sur cet échantillon incomplet;
5. ses recommandations influencent les prochains appels, donc le prochain historique.

Les personnes qu’on n’appelait jamais ne sont pas des exemples négatifs. Leur résultat est inconnu. Si je les retire, le modèle ne connaît que l’ancienne sélection. Si je les marque 0, j’invente qu’elles n’auraient pas acheté. Dans les deux cas, un bon score peut cacher le trou.

Une même moyenne, deux expériences différentes

Supposons que le test contient deux régions de 100 clients chacune. Le modèle obtient 80 bonnes réponses sur 100 dans les deux régions, donc 80 % d’exactitude partout. Ça semble rassurant. La matrice de confusion montre pourtant autre chose :

Région	Ventes réelles	Ventes détectées	Ventes manquées	Faux rappels
A	40	36	4	16
B	20	8	12	8

Dans la région A, le rappel trouve 90 % des ventes possibles (36 / 40). Dans la région B, il n’en trouve que 40 % (8 / 20). L’exactitude globale ne montrait pas cette différence parce que les clients sans vente dominent le calcul.

Je veux donc mesurer au minimum la précision et le rappel pour les groupes qui ont un sens opérationnel, puis regarder la taille des échantillons. Une différence sur cinq cas ne se lit pas comme une différence sur cinq mille. Les groupes servent à trouver un problème; ils ne prouvent pas automatiquement sa cause.

Étiquette, proxy et moment de mesure

Le code « non intéressé » peut signifier que le client a refusé. Il peut aussi vouloir dire que personne n’a réussi à le joindre. C’est la même valeur dans la colonne, mais ça ne mène pas du tout à la même prochaine action. Je séparerais plutôt refus, injoignable, numéro_invalide et non_évalué, avec une définition compréhensible par la personne qui saisit l’appel.

Certaines variables deviennent aussi des proxies. Le code postal peut indirectement représenter le revenu, la langue ou l’accès à un service. Retirer une colonne sensible n’enlève pas nécessairement toute l’information corrélée ailleurs. Je testerais le modèle avec et sans ces variables, puis j’examinerais quelles features déplacent le score et si elles ont une justification dans la décision.

Le temps compte également. Une information ajoutée après l’appel ne doit pas servir à prédire cet appel. Une politique commerciale modifiée en janvier peut rendre les données précédentes moins comparables. Le jeu d’entraînement devrait donc garder la date, la version des règles et la provenance de l’étiquette.

Pour démêler ça, il faut parler aux personnes qui produisent et utilisent les données. Elles savent si un champ sert réellement, s’il est rempli automatiquement ou s’il devient le tiroir où on place tous les cas bizarres. Le notebook ne raconte pas cette partie-là.

Vérifier le système après son lancement

Une validation humaine ne fait pas disparaître les biais. Elle peut au moins créer une trace utile : recommandation du modèle, décision finale, raison d’un changement et résultat observé. Avec cette boucle, on peut comparer les erreurs par période, groupe et type de dossier, puis arrêter l’usage si un écart devient important.

Je garderais aussi un petit échantillon traité en dehors des recommandations, quand le contexte et l’éthique le permettent. Sans exploration, le système continue de choisir les mêmes profils et n’apprend presque rien sur les autres. C’est un compromis à encadrer, pas une raison pour expérimenter n’importe comment sur les gens.

Quand j’entends « le modèle l’a dit », je veux maintenant retrouver la cible, l’échantillon, la matrice de confusion et la version des règles qui ont produit cette réponse. Un modèle optimise ce qu’on lui montre. Notre job est de vérifier ce que cette table a laissé de côté avant que l’ancienne décision se remette à tourner automatiquement.