L'IA pour la détection de la fraude et la détermination de l'éligibilité
# L'IA pour la détection de la fraude et la détermination de l'éligibilité
Quand la machine a accusé 40 000 personnes
Entre 2013 et 2015, le système automatisé d'assurance chômage du Michigan a signalé pour fraude environ 40 000 résidents. Le système s'appelait MiDAS (Michigan Integrated Data Automated System). Il fonctionnait avec une revue humaine minimale, présumait la culpabilité à partir d'incohérences de données et imposait des pénalités allant jusqu'à quatre fois le montant des allocations perçues.
Des examens ultérieurs ont montré que le système se trompait dans la grande majorité des cas. Un audit de l'État a conclu qu'environ 93 % des décisions de fraude prises sans intervention humaine étaient erronées. Des personnes ont perdu leurs remboursements d'impôts, ont subi des saisies sur salaire, et certaines ont déposé le bilan pour de l'argent qu'elles ne devaient pas.
MiDAS est le contre-exemple qui structure toute cette leçon. Il montre exactement ce qui se passe quand on optimise un système de prestations sociales pour attraper la fraude sans tenir compte du coût de l'erreur.
À lire : la couverture de MiDAS par ProPublica.
Deux missions, un système, des modes de défaillance opposés
Les programmes de prestations publiques (assurance chômage, aide alimentaire SNAP, Medicaid, aides au logement) demandent à l'IA deux missions liées mais distinctes.
Détermination de l'éligibilité : ce demandeur a-t-il droit à la prestation ? C'est un problème de classification très encadré par des règles, souvent piloté par des seuils de revenu, la taille du foyer et les pièces justificatives.
Détection de la fraude : cette demande ou ce demandeur déforme-t-il les faits pour obtenir des prestations indues ? C'est un problème d'anomalie et de pattern, généralement avec très peu de vrais positifs dissimulés dans une large population.
L'insight décisif : ces deux missions ont des modes de défaillance opposés, et c'est en les confondant que MiDAS a dérapé.
- Un refus d'éligibilité injustifié pénalise une personne légitime qui a besoin d'aide.
- Un cas de fraude non détecté gaspille de l'argent public.
On ne peut pas maximiser les deux à la fois. Chaque choix de conception du modèle arbitre l'un contre l'autre.
La matrice de confusion, en clair
Tout modèle de fraude ou d'éligibilité produit quatre résultats. Les comprendre n'est pas négociable pour quiconque supervise ces systèmes.
| | Le modèle dit fraude/inéligible | Le modèle dit légitime/éligible |
|---|---|---|
| Réellement fraude/inéligible | Vrai positif (détecté) | Faux négatif (manqué) |
| Réellement légitime/éligible | Faux positif (refus injustifié) | Vrai négatif (correct) |
MiDAS était réglé de façon catastrophique vers la case en bas à gauche : les faux positifs, c'est-à-dire les accusations à tort de personnes innocentes.
Deux métriques comptent ici :
Précision : parmi toutes les personnes signalées par le modèle, quelle proportion était réellement en fraude ? Une précision faible signifie que beaucoup d'innocents sont pris dans le filet.
Recall : sur l'ensemble des fraudes réelles, quelle proportion le modèle a-t-il détectée ? Un recall faible signifie que de vraies fraudes passent au travers.
MiDAS a de fait poussé le recall vers le haut (signaler tout ce qui est suspect) au détriment de la précision (justesse de ces signalements). Résultat : des dizaines de milliers d'accusations infondées.
Pourquoi « récupérer l'argent » est le mauvais objectif
Si vous dites à une équipe d'ingénierie « récupérez le maximum d'argent mal dépensé », elle construira un système qui sur-signale. Signaler plus de dossiers permet de récupérer plus d'euros à court terme, même si la plupart des signalements sont faux, parce que les pénalités et les recouvrements génèrent des recettes.
C'est une fonction objectif mal alignée. La fonction objectif est la grandeur unique que le modèle est entraîné à optimiser. Si cette grandeur est « euros récupérés », le modèle n'a aucune raison de se soucier des refus injustifiés.
Un meilleur objectif pondère le coût réel de chaque type d'erreur. Dans les prestations publiques, le coût d'un faux positif est généralement bien supérieur à celui d'une fraude non détectée, parce que :
- Un refus injustifié peut provoquer une expulsion, la faim ou une faillite personnelle.
- Il frappe de manière disproportionnée les personnes vulnérables.
- Il crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →ée un risque juridique (le Michigan a versé un règlement estimé à environ 20 millions de dollars).
- Il érode la confiance du public dans l'ensemble du programme.
On encode cela en attribuant un coût explicite à chaque case de la matrice de confusion, puis en choisissant le seuil de décision qui minimise le coût total attendu, au lieu de maximiser les montants récupérés.
# Illustrative cost-sensitive threshold selection
# Costs reflect that wrongful denial is far more damaging than missed fraud
cost_false_positive = 100 # refus injustifié : préjudice, risque juridique, perte de confiance
cost_false_negative = 5 # fraude non détectée : fonds publics perdus
def expected_cost(threshold, y_true, fraud_scores):
flagged = fraud_scores >= threshold
fp = ((flagged) & (y_true == 0)).sum()
fn = ((~flagged) & (y_true == 1)).sum()
return fp * cost_false_positive + fn * cost_false_negative
# Balayer les seuils ; retenir celui au coût total le plus faible, pas au recouvrement le plus élevéL'intérêt de cet extrait n'est pas le code. C'est que quelqu'un doit décider consciemment ces deux valeurs de coût. Dans MiDAS, personne ne l'a fait, donc le système a implicitement fixé à près de zéro le coût d'un refus injustifié.
Les principes de conception qui auraient évité MiDAS
1. Garder un humain dans la boucle pour les décisions défavorables
MiDAS statuait automatiquement sur la fraude sans aucune revue humaine. Toute décision qui porte préjudice à une personne (refus, recouvrement, pénalité) devrait exiger une validation humaine. L'IA peut hiérarchiser les dossiers ; elle ne doit pas prononcer la culpabilité.
2. Signaler pour enquête, ne pas conclure à la fraude
Reformulez la sortie du modèle. Il ne détecte pas la fraude. Il identifie des dossiers qui méritent un regard humain. Une incohérence de données (un employeur déclare des salaires différents de ceux du demandeur) est une question, pas une preuve.
3. Ajuster la charge de la preuve au préjudice
Des pénalités plus lourdes devraient exiger une confiance plus élevée et davantage de preuves. MiDAS appliquait des pénalités quadruples sur des signaux automatisés ténus. C'est l'inverse de ce qu'il faut faire.
4. Tester l'impact différencié
Un modèle peut être globalement précis et se tromper bien plus souvent pour un groupe donné. Dans les programmes de prestations, cela recoupe souvent l'origine, le handicap ou la langue. Mesurez les taux d'erreur par sous-groupe avant le déploiement, pas après un procès.
5. Offrir une véritable voie de recours
Beaucoup de victimes de MiDAS n'ont pas pu joindre un humain ni comprendre pourquoi elles avaient été signalées. Un droit à l'explication et une procédure d'appel rapide et fonctionnelle sont une exigence de conception, pas une politesse.
Vérification des acquis
1. Pourquoi la leçon décrit-elle la détermination de l'éligibilité et la détection de la fraude comme ayant des « modes de défaillance opposés » ?
2. Le cas MiDAS est présenté avant tout comme une mise en garde contre quel défaut de conception ?
3. La détection de la fraude est caractérisée dans la leçon comme quel type de problème ?
4. Sélectionnez TOUTES les bonnes réponses expliquant pourquoi traiter la détection de fraude comme une classification d'éligibilité de routine (ce qu'a fait MiDAS de fait) est dangereux.
Sélectionnez toutes les réponses correctes.
5. Sélectionnez TOUTES les bonnes réponses qui distinguent correctement la détermination de l'éligibilité de la détection de la fraude.
Sélectionnez toutes les réponses correctes.
Construire le volet éligibilité de façon responsable
L'éligibilité est souvent plus simple que la fraude, parce que les règles sont écrites dans la loi. C'est un avantage : vous pouvez en construire l'essentiel sous forme de logique transparente et auditable plutôt que d'un modèle opaque.
Privilégiez les règles quand la loi est claire. Si l'éligibilité au SNAP dépend d'un revenu inférieur à un seuil défini pour une taille de foyer donnée, encodez cette règle directement. Elle est explicable, testable et défendable en appel. N'utilisez pas un modèle boîte noire pour reproduire une règle qui tient en une ligne.
Utilisez les modèles pour assister les agents, pas pour les remplacer. Le machine learning est utile pour le tri (quels dossiers semblent complets, lesquels nécessitent des pièces complémentaires) et pour repérer les erreurs de saisie. Il doit remonter de l'information à un agent, pas exclure une personne.
Concevez pour des données manquantes et sales. Beaucoup de refus injustifiés viennent de mauvaises données, pas de fraude : un numéro de sécurité sociale non concordant, une déclaration tardive d'employeur, un nom orthographié de deux façons. Traitez un conflit de données comme une invitation à interroger le demandeur, pas comme un verdict.
Vérifiez avec précaution auprès des sources faisant autorité. Le croisement avec des bases de données salariales ou des registres de décès est courant. Mais ces sources contiennent elles aussi des erreurs. Le GAO américain a documenté des problèmes de fiabilité récurrents dans les bases mêmes sur lesquelles les administrations s'appuient pour vérifier. Ne considérez jamais une correspondance unique comme une vérité terrain.
Une checklist de gouvernance opérationnelle
Avant la mise en production de toute IA de prestations publiques, une instance de supervision devrait confirmer que :
- La fonction objectif pondère explicitement les refus injustifiés, pas seulement les montants récupérés.
- Toute décision défavorable exige une revue humaine.
- Les taux d'erreur par sous-groupe ont été mesurés et publiés.
- Une explication en langage clair est disponible pour chaque personne concernée.
- Une procédure d'appel existe et a été testée en charge sur le volume attendu.
- Le système est surveillé après le lancement, avec un kill switch si les taux d'erreur s'envolent.
Le Michigan n'avait presque rien de tout cela. La technologie n'était pas la cause profonde de l'échec. C'est l'absence de gouvernance autour d'elle.
À retenir
- La détection de fraude et l'éligibilité sont deux problèmes différents, aux modes de défaillance opposés. Un refus injustifié nuit à une personne ; une fraude non détectée gaspille de l'argent. Concevez pour les deux, et sachez lequel votre objectif favorise en silence.
- « Récupérer l'argent » est une fonction objectif dangereuse. Elle récompense le sur-signalement. Attribuez un coût explicite, plus élevé, aux refus injustifiés et réglez le seuil de décision pour minimiser le préjudice total.
- L'IA doit signaler des dossiers à des humains, pas trancher. Toute action qui porte préjudice à une personne exige une revue humaine et une charge de la preuve proportionnée à la sanction.
- Ce sont de mauvaises données, pas la fraude, qui causent beaucoup d'accusations infondées. Traitez les incohérences de données comme des questions à résoudre avec le demandeur, pas comme la preuve d'une faute.
- La gouvernance est le vrai garde-fou. Tests d'erreur par sous-groupe, explications en langage clair, recours qui fonctionnent et suivi post-lancement : c'est ce qui sépare un outil de triage utile du prochain MiDAS.