+150 XP

Là où les modèles d'IA cassent silencieusement en production

En septembre 2022, quelques jours après l'arrivée de l'ouragan Ian en Floride, les modèles de fraude et de sévérité de plusieurs assureurs ont commencé à classer à tort des sinistres légitimes comme suspects. Rien n'avait changé dans le code. Ce qui avait changé, c'est le monde : après une catastrophe, les schémas de déclaration ressemblent statistiquement à des schémas de fraude (déclaration rapide, montants élevés, localisations regroupées) même quand ils n'en sont pas. Les modèles n'avaient pas été réentraînés pour ce régime. Ce n'est pas un bug. C'est une catégorie de risque qui n'apparaît jamais dans un rapport d'accuracy standard.

Cette leçon construit une taxonomie opérationnelle des endroits où les modèles d'IA en assurance échouent après déploiement, et des contrôles qui détectent chaque type d'échec avant qu'il ne coûte de l'argent ou ne déclenche une observation réglementaire.

Pourquoi « l'accuracy » est la mauvaise première question

Un modèle peut atteindre 95 % d'accuracy en validation et rester dangereux. L'accuracy est une moyenne sur une distribution qui n'existe plus dès que le modèle passe en production. Trois modes de défaillance propres à l'assurance l'expliquent :

1. Feature drift après un événement de choc. Les événements catastrophiques (ouragans, incendies, pandémies) modifient la relation statistique entre les inputs et les résultats. Un modèle de fraude entraîné sur une vélocité de déclaration « en temps normal » traite un afflux légitime post-ouragan comme une anomalie. On appelle cela un covariate shift : la distribution des inputs change alors que la logique de labellisation sous-jacente n'a pas été réenseignée au modèle.

2. Discrimination par proxy. Un modèle de tarification ou de souscription évite d'utiliser explicitement l'origine ethnique ou une catégorie protégée, mais une variable corrélée (score d'assurance basé sur le crédit, code postal, niveau d'éducation) reconstruit le même signal. Les régulateurs américains (départements d'assurance des États, dans le cadre des bulletins-modèles de la NAIC, National Association of Insurance Commissioners) et européens (AI Act, entré en vigueur en 2024, dont la classification à haut risque couvre probablement de nombreux usages de tarification et de gestion de sinistres) le signalent explicitement. Les scores basés sur le crédit sont un risque de proxy connu, car l'historique de crédit est corrélé à l'origine ethnique et au revenu d'une manière que les assureurs ne recherchent pas mais ne peuvent pas totalement neutraliser. Voir les documents de la NAIC sur le bulletin-modèle IA pour le cadrage réglementaire.

3. Dégradation silencieuse. La performance d'un modèle se dégrade progressivement, pas d'un coup. Un modèle de scoring de fraude perd en précision sur 18 mois à mesure que les techniques de fraude évoluent (nouveaux montages d'accidents mis en scène, identités synthétiques), mais personne ne le remarque parce que le modèle renvoie toujours des scores et que les sinistres continuent d'être traités. Aucune alerte ne se déclenche parce que rien ne « casse » au sens informatique.

Une taxonomie opérationnelle du risque de modèle

Regroupez ces défaillances en quatre catégories, empruntées et adaptées des frameworks de model risk management (MRM) utilisés en banque (voir la guidance SR 11-7 de la Réserve fédérale, standard de référence même en dehors du secteur bancaire) :

Type de risqueÀ quoi cela ressemble en assuranceSignal de détection
Risque de donnéesFeature drift post-catastrophe, données de crédit obsolètes, trous dans les capteurs/télématiquesDécalage de distribution des features d'entrée vs. baseline d'entraînement
Risque d'équité/proxyScore de crédit, code postal ou profession reconstruisant un signal de catégorie protégéeRatio d'impact disparate, audits de résultats par sous-groupe
Risque de dégradation de performanceModèle de fraude perdant en précision à mesure que les techniques évoluent ; modèle de churn obsolète après un changement de produitPrécision/rappel glissants dans le temps, dérive de calibration
Risque de gouvernance/processusAucun owner documenté, aucun déclencheur de réentraînement, modèle éditeur traité comme une boîte noireAbsence d'entrée dans l'inventaire de modèles ou de cadence de revue

Chaque catégorie exige un contrôle différent. Les métriques d'accuracy seules ne captent (partiellement) que la catégorie 3, et seulement une fois les dégâts faits.

Exemple concret : la discrimination par proxy dans le scoring basé sur le crédit

Les scores d'assurance basés sur le crédit sont largement utilisés en souscription auto et habitation aux États-Unis, interdits ou restreints dans certains États (la Californie, le Massachusetts et Hawaï interdisent leur usage dans la tarification auto, selon la législation récente de ces États ; vérifiez l'état actuel État par État, cela bouge). Le mécanisme :

  • L'historique de crédit est corrélé au revenu, et le revenu est corrélé à l'origine ethnique pour des raisons historiques et structurelles sans rapport avec le risque de conduite.
  • Un modèle entraîné à minimiser le loss ratio va capter le signal crédit parce qu'il est prédictif, sans « savoir » qu'il s'agit d'un proxy.
  • Résultat : une variable neutre en apparence produit un impact disparate sur des groupes protégés, attaquable au titre des équivalents du fair lending appliqués à l'assurance par les régulateurs des États et, en principe, au titre du droit européen de la non-discrimination.

Un contrôle simple, appliqué : la règle des quatre cinquièmes (empruntée au droit américain de la discrimination à l'emploi, guidance de l'EEOC) comme premier filtre.

selection_rate(group_A) = approved_A / applicants_A
selection_rate(group_B) = approved_B / applicants_B
impact_ratio = min(selection_rate_A, selection_rate_B) / max(selection_rate_A, selection_rate_B)

# Règle empirique : un impact_ratio < 0,80 déclenche une revue d'équité approfondie

C'est une heuristique de screening, pas un safe harbor juridique. Elle vous dit où regarder, pas si vous êtes conforme. Un ratio de 0,78 sur un palier tarifaire doit déclencher un audit complet par sous-groupe avant déploiement, et non un verdict binaire.

Le problème du drift catastrophe, mécaniquement

Pourquoi un modèle de fraude casse-t-il spécifiquement après un ouragan ? Parce que ses données d'entraînement encodent un monde où :

  • Une forte vélocité de déclaration sur une courte fenêtre = suspect
  • Plusieurs sinistres issus du même regroupement géographique = suspect
  • Des sinistres déclarés en masse par des experts d'assuré = suspect

Après Ian, Ida ou toute catastrophe majeure, ces trois signaux deviennent *normaux*. Le modèle n'a aucune notion de « zone de catastrophe déclarée », sauf si quelqu'un a explicitement créé cette feature et réentraîné le modèle.

Les contrôles qui détectent cela avant le déploiement ou avant les dégâts :

  1. Stress-testing par scénarios. Avant la mise en production, faites tourner le modèle sur une distribution synthétique de sinistres post-catastrophe, pas seulement sur les données de validation historiques.
  2. Monitoring des features avec alarmes de drift. Suivez la distribution statistique (pas seulement la moyenne) des inputs clés chaque semaine ; déclenchez une alarme quand elle sort d'une tolérance définie (ex. : population stability index supérieur à 0,25).
  3. Un override « mode catastrophe ». Beaucoup d'assureurs matures intègrent désormais un flag catastrophe explicite qui modifie le comportement du modèle ou route les sinistres vers une revue humaine pendant les événements déclarés, plutôt que de faire confiance au modèle de base.

Vérification des acquis

1. Après un ouragan, un modèle de fraude commence à signaler comme suspects de nombreux sinistres légitimes alors qu'aucune ligne de code n'a changé. Quelle est la meilleure explication de cette défaillance ?

2. Pourquoi un score d'accuracy élevé en validation ne suffit-il pas à garantir qu'un modèle est sûr en production ?

3. Un assureur retire l'origine ethnique de son modèle de souscription mais continue d'utiliser des scores d'assurance basés sur le crédit et le code postal en inputs. Pourquoi les régulateurs y voient-ils un problème potentiel ?

CHOIX MULTIPLES

4. Sélectionnez TOUTES les bonnes réponses expliquant pourquoi la défaillance du modèle de fraude après l'ouragan est décrite comme « pas un bug ».

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les bonnes réponses concernant le risque de discrimination par proxy dans les modèles d'assurance.

Sélectionnez toutes les réponses correctes.

Garde-fous avant déploiement : une checklist opérationnelle

En assurance, le model risk management converge vers quelques gates non négociables avant déploiement, repris dans les principes de gouvernance de modèles de la NAIC et dans les exigences de l'AI Act européen pour les systèmes à haut risque (documentation, supervision humaine, journalisation, tests d'accuracy et de robustesse) :

  • Entrée dans l'inventaire de modèles : tout modèle en production a un owner nommé, une finalité documentée et une date de revue. Aucune exception pour les modèles éditeurs ou boîtes noires (c'est là que beaucoup d'assureurs utilisant des outils tiers de scoring fraude ou télématique ont des trous).
  • Audit de performance par sous-groupe : testez l'accuracy, le taux de faux positifs et le taux d'acceptation ventilés par catégories protégées et quasi-protégées, pas seulement en agrégé.
  • Plan de monitoring du drift : définissez à quoi ressemble une distribution d'inputs « normale », et ce qui déclenche un réentraînement ou une revue humaine.
  • Artefact d'explicabilité : un gestionnaire de sinistres ou un régulateur peut obtenir une raison en langage clair pour un score ou une décision donnés (pertinent au regard des obligations de transparence de l'AI Act européen et des exigences de notification d'adverse action au niveau des États américains, qui précèdent largement l'IA et proviennent du droit des pratiques de crédit équitables).
  • Kill switch / plan de rollback : un moyen documenté et testé de revenir au modèle précédent ou à un processus manuel si le nouveau modèle dérape après le lancement.

Rien de tout cela ne remplace les tests actuariels ou d'accuracy. Cela vient à côté.

🎬 [VIDEO: « Algorithmic Bias in Insurance Pricing » - youtube.com/results?search_query=algorithmic+bias+insurance+pricing+NAIC - cherchez des tables rondes récentes de la NAIC ou du secteur de l'assurance sur la discrimination par proxy dans les modèles de souscription, une explication visuelle utile de la formation des proxys]

Points clés

  • Les métriques d'accuracy mesurent le passé, pas le risque en production. Un modèle peut passer la validation et échouer en déploiement à cause du feature drift, de la discrimination par proxy ou d'une dégradation silencieuse : aucun de ces phénomènes n'apparaît dans un chiffre unique d'accuracy.
  • Le feature drift après un événement catastrophique est un schéma de défaillance connu et récurrent dans les modèles de fraude et de sinistres ; la réponse est le stress-testing par scénarios et un traitement explicite en « mode catastrophe », pas seulement un réentraînement après coup.
  • La discrimination par proxy se cache dans des variables apparemment neutres comme les scores basés sur le crédit ou les codes postaux ; la règle des quatre cinquièmes est une heuristique de screening utile, pas une garantie de conformité, d'où la nécessité d'audits par sous-groupe approfondis.
  • La dégradation silencieuse n'émet aucun signal de panne. Elle exige un monitoring actif et glissant de la performance (précision, rappel, calibration dans le temps), car rien ne vous alerte par défaut.
  • La gouvernance est un gate de déploiement, pas de la paperasse : inventaire de modèles, audits par sous-groupe, monitoring du drift, explicabilité et plans de rollback doivent tous exister avant la mise en production, en cohérence avec la guidance de la NAIC aux États-Unis et les exigences de l'AI Act européen sur les systèmes à haut risque.