Évaluer les fournisseurs et arbitrer entre build et buy

Trois fournisseurs entrent dans une réunion d'achat. Tous trois affirment que leur IA sait détecter les opportunités de subrogation, ces dossiers où votre assureur a payé un sinistre alors qu'un tiers (un conducteur négligent, un artisan, un fabricant de produit) devrait au final en supporter le coût. Tous trois présentent une démo avec des chiffres de recall impressionnants. Un seul s'est déjà connecté à un système de gestion de sinistres aussi désordonné que le vôtre. Cette leçon vous donne la checklist pour les distinguer.

Pourquoi la détection de subrogation est un bon cas de test

La subrogation est le processus par lequel un assureur ayant payé un sinistre demande remboursement à la partie réellement responsable. Une subrogation manquée est une perte de marge pure : le sinistre est payé, le dossier est clos, et personne ne revient jamais encaisser. Les estimations du secteur (à date de 2024, les sources varient) suggèrent que les assureurs dommages américains récupèrent bien moins de la moitié des montants théoriquement récupérables en subrogation, souvent cités dans une fourchette de 30 à 50 % selon la branche.

Les modèles d'IA peuvent signaler des candidats à la subrogation en lisant les notes des gestionnaires, les rapports de police et les métadonnées du sinistre (type de sinistre, codes de blessure, indicateurs de responsabilité) pour faire remonter des schémas qu'un gestionnaire surchargé pourrait manquer. Cela en fait un cas d'usage réaliste et circonscrit pour comparer des fournisseurs, pas un pari sur l'avenir.

L'exercice de scoring à trois fournisseurs

Imaginez que vous notez le Fournisseur A (une startup insurtech spécialisée), le Fournisseur B (un module greffé sur une grande plateforme de gestion de sinistres établie) et le Fournisseur C (un cabinet de conseil IA/analytics généraliste proposant un développement sur mesure). Notez chacun de 1 à 5 sur les critères ci-dessous.

Critère 1 : accès aux données et effort d'intégration

Posez la question concrètement : le fournisseur lit-il uniquement des données de sinistres structurées, ou aussi du texte non structuré (notes de gestionnaires, PDF, transcriptions d'appels) ? Les signaux de subrogation se cachent souvent dans le texte libre : un modèle limité aux champs structurés sera moins performant.

• Fournisseur A (startup) : a construit des connecteurs APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → pour les principaux systèmes de gestion de sinistres (par ex. Guidewire, Duck Creek) mais n'a jamais touché à votre extract mainframe legacy. Effort d'intégration : moyen à élevé, risque de calendrier.
• Fournisseur B (module de l'acteur en place) : déjà intégré à votre plateforme existante, effort d'intégration quasi nul, mais le modèle sous-jacent est un add-on générique non calibré spécifiquement pour la subrogation.
• Fournisseur C (cabinet de conseil) : construira un pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète → sur mesure sur vos données exactes, mais cela signifie des mois de data engineering avant le moindre résultat de modèle.

Critère 2 : exigences d'explicabilité

L'explicabilité, c'est la capacité à montrer, en termes humains, pourquoi un modèle a produit un résultat donné. En assurance, ce n'est pas optionnel. De nombreux États américains exigent que les décisions défavorables affectant les assurés soient explicables, et des régulateurs comme la NAIC (National Association of Insurance Commissioners) ont publié des orientations de gouvernance des modèles sur l'usage de l'IA en assurance. Les signalements de subrogation alimentent des décisions qui touchent au traitement des sinistres : si le signalement influence le provisionnement ou la stratégie contentieuse, vos équipes juridiques et compliance demanderont « pourquoi le modèle a-t-il dit cela ».

• Fournisseur A : fournit des explications au niveau des features (quels mots ou champs ont déclenché le signalement), piste d'audit correcte.
• Fournisseur B : score en boîte noire avec un pourcentage de confiance générique, explicabilité faible.
• Fournisseur C : entièrement sur mesure, donc l'explicabilité est celle que vous spécifiez au contrat, mais ce travail de spécification vous incombe.

Critère 3 : antécédents et validation

Demandez un client de référence actif dans votre branche (auto, workers' comp, dommages aux biens), pas juste un logo sur une slide. Demandez comment le fournisseur a mesuré la précision : sur un jeu de données historique mis de côté, ou seulement sur ses propres données d'entraînement (un signal d'alerte de performance surévaluée).

Un tableau de scoring simple

Calcul détaillé (score pondéré, sur 5) :

• Fournisseur A : (3×0,3) + (4×0,3) + (3×0,2) + (3×0,2) = 0,9 + 1,2 + 0,6 + 0,6 = 3,3
• Fournisseur B : (5×0,3) + (2×0,3) + (4×0,2) + (4×0,2) = 1,5 + 0,6 + 0,8 + 0,8 = 3,7
• Fournisseur C : (2×0,3) + (3×0,3) + (2×0,2) + (1×0,2) = 0,6 + 0,9 + 0,4 + 0,2 = 2,1

Le Fournisseur B gagne avec cette pondération, mais seulement parce que l'intégration et le coût pèsent 50 % à eux deux. Si votre équipe juridique impose une pondération minimale de 40 % sur l'explicabilité (fréquent dans les cas d'usage adjacents aux sinistres), le Fournisseur A dépasse B. L'intérêt de l'exercice n'est pas l'arithmétique, c'est d'obliger votre équipe à énoncer les pondérations explicitement *avant* de voir les démos, pour que le discours commercial ne fixe pas vos priorités à votre place.

Build versus buy : les vrais arbitrages

« Build » signifie rarement construire un large language modellarge language modelUn Large Language Model est un système d'IA entraîné sur d'énormes volumes de texte pour prédire et générer du langage, ce qui permet de rédiger, résumer ou répondre à des questions.Voir la définition complète → de zéro, presque aucun assureur ne le fait. Cela signifie construire un pipeline sur mesure (extraction de données, feature engineering, un modèle fine-tuné ou piloté par prompt, un workflow de revue) à partir d'infrastructures IA existantes (API de cloud providers, modèles open-source).

Le buy a du sens quand :

• Le cas d'usage est répandu dans le secteur (détection de subrogation, triage des déclarations de sinistre) et que les fournisseurs l'ont déjà affiné sur les données de nombreux clients.
• Votre équipe n'a pas la capacité d'ingénierie ML en interne pour maintenir un modèle dans le temps.
• Le time to value compte plus que l'adéquation parfaite ; un outil médiocre en production au T2 vaut mieux qu'un outil parfait en production au T4 de l'année suivante.

Le build a du sens quand :

• Vos données ou votre processus sont réellement atypiques (une branche de niche, une taxonomie de sinistres propriétaire).
• Le cas d'usage est au cœur de l'avantage concurrentielavantage concurrentielUn avantage durable sur les concurrents : une ressource, une capacité ou une position qu'ils ne peuvent pas répliquer facilement, et qui permet à une entreprise de dégager des rendements supérieurs à la moyenne dans la durée.Voir la définition complète →, pas une fonction de commodité.
• Vous disposez déjà d'une capacité MLOpsMLOpsMachine Learning Operations : combinaison des pratiques ML et DevOps pour industrialiser, déployer, monitorer et réentraîner les modèles de façon fiable en production.Voir la définition complète → (machine learning operations, les pratiques de déploiement et de monitoring des modèles en production) issue d'autres projets.

Une voie intermédiaire fréquente : acheter le modèle de base d'un fournisseur, mais négocier l'accès au fine-tuningfine-tuningLe fine-tuning adapte un modèle pré-entraîné à une tâche ou un domaine précis en poursuivant son entraînement sur un jeu de données plus petit et ciblé, ce qui améliore la précision et le style pour ce cas d'usage.Voir la définition complète → sur vos propres données historiques de sinistres. Vous gagnez en rapidité avec une part de personnalisation, au prix d'une complexité contractuelle supplémentaire.

Un contrôle technique minimal

Même des évaluateurs non techniques devraient demander aux fournisseurs de montrer une matrice de confusion sur un jeu de test mis de côté, pas seulement un chiffre global de précision. Exemple de ce qu'il faut demander :

                Predicted: Subrogation   Predicted: No Subrogation
Actual: Subrogation         420 (TP)             180 (FN)
Actual: No Subrogation      90 (FP)             9,310 (TN)

D'où : precision = TP/(TP+FP) = 420/510 ≈ 82 %. Recall = TP/(TP+FN) = 420/600 = 70 %. Un fournisseur qui n'annonce que « 95 % de précision » sur un jeu de données où les cas de subrogation sont rares (un classique problème de déséquilibre de classes) cache probablement un recall faible derrière un chiffre d'accroche trompeur. Demandez toujours precision et recall séparément.

Checklist gouvernance et achats

Avant de signer, vérifiez que le fournisseur peut répondre à ces points, par écrit :

1. Où sont stockées les données d'entraînement et d'inférenceinférenceLe moment où un modèle d'IA entraîné se met au travail : il reçoit une donnée nouvelle et produit une réponse, une prédiction ou un contenu.Voir la définition complète →, et franchissent-elles des frontières ? Pertinent pour le RGPDRGPDRèglement de l'UE encadrant la collecte, le stockage et l'usage des données personnelles, avec des amendes indexées sur le chiffre d'affaires mondial.Voir la définition complète → (Règlement général sur la protection des données, UE) si vous opérez en Europe, et pour les lois de protection des données des États américains.
2. Qui détient les outputs du modèle et les améliorations du modèle dérivées de vos données ?
3. Quel est le processus pour contester ou surcharger un signalement de subrogation du modèle ?
4. Le fournisseur peut-il démontrer des tests de biais selon les caractéristiques démographiques des demandeurs ? Des régulateurs, dont plusieurs départements d'assurance d'États américains, ont commencé à exiger des audits de biais pour les IA liées aux sinistres.

Pour une base plus large sur les frameworks de gestion des risques IA applicables à l'évaluation des fournisseurs, le NIST AI Risk Management Framework est une référence solide et gratuite, utilisée bien au-delà de l'assurance.

🎬 [VIDEO: "How Insurers Are Using AI for Claims and Fraud Detection" - youtube.com - cherchez des tables rondes sectorielles récentes sur le déploiement de l'IA dans les sinistres, utiles pour voir des démos de fournisseurs discutées de façon critique et non dans un contexte commercial]

Points clés

• Notez les fournisseurs sur des critères explicites et pondérés (accès aux données, effort d'intégration, explicabilité, antécédents) fixés *avant* les démos, pas après.
• L'explicabilité n'est pas un bonus dans l'IA liée aux sinistres ; régulateurs et équipes juridiques internes l'exigeront.
• Demandez toujours precision et recall séparément, pas un chiffre unique de précision, surtout pour la détection d'événements rares comme la subrogation.
• Achetez pour les cas d'usage de commodité, déjà bien balisés ; construisez (ou personnalisez) quand vos données ou votre processus sont réellement différenciants.
• Une voie hybride, acheter un modèle de base et le fine-tuner sur vos propres données, est souvent le compromis réaliste en 2026.