Projet IA assurance : cadrer le problème avant les données

Ce qu’il faut retenir

sélectionner un problème assez précis pour déterminer quelles données sont réellement nécessaires.
formuler le problème en une phrase testable : c’est le premier résultat à rendre mesurable.
nommer l’utilisateur et la décision améliorée : la qualité moyenne ne suffit pas à démontrer la maîtrise.
mesurer la friction actuelle : le contrôle doit être conçu dans le parcours, pas ajouté à la fin.
Le passage à l’échelle dépend autant des règles, des droits et de l’exploitation que du modèle utilisé.

Format : Tribune méthodologique. Public : dirigeants, directions des opérations, innovation, DSI, responsables IA, courtiers, assureurs et assurtechs.

« Nos données ne sont pas prêtes » est parfois un diagnostic juste, mais souvent une manière de reporter le choix du problème. Sans parcours, population, sortie et critère de réussite, un grand programme de nettoyage optimise des tables sans savoir quelles erreurs comptent. Le cadrage réduit au contraire le besoin aux données qui influencent une action identifiée.

Ce dossier propose une méthode pour sélectionner un problème assez précis pour déterminer quelles données sont réellement nécessaires. L’ambition n’est pas d’ajouter une couche d’IA à un processus inchangé. Elle est de redessiner le travail de façon à rendre la proposition de la machine vérifiable, l’intervention humaine utile et le résultat observable dans les opérations.

1. Partir du problème métier, pas de la démonstration

Dans l’assurance, un même résultat technique peut avoir des conséquences très différentes. Une erreur de formulation dans une note interne est corrigeable ; une mauvaise information envoyée au client, une pièce rattachée au mauvais contrat ou une décision non contestable ne le sont pas au même coût. Le cadrage doit donc décrire la chaîne de valeur complète : événement d’entrée, personnes concernées, données disponibles, action produite, contrôle, sortie utilisable et conséquence d’une erreur.

Le premier atelier doit reconstruire le travail réel. Il faut observer les doubles saisies, les recherches, les attentes, les fichiers parallèles, les règles mémorisées par quelques experts et les cas que la procédure officielle traite mal. Cette observation empêche d’optimiser une étape visible tout en déplaçant la charge vers l’étape suivante.

Les sept questions de cadrage

Qui réalise la tâche aujourd’hui et qui répond du résultat final ?
Quel événement déclenche le traitement et quand considère-t-on qu’il est terminé ?
Quel volume, quelle saisonnalité et quelle proportion de cas atypiques faut-il absorber ?
Quelles données sont nécessaires, disponibles, licites et suffisamment fraîches ?
Quelle erreur est tolérable, laquelle impose une abstention et laquelle interdit l’autonomie ?
Comment l’utilisateur vérifie-t-il la preuve et corrige-t-il la proposition ?
Quel indicateur autorisera une extension, une correction ou un arrêt du pilote ?

Les objectifs à rendre explicites

formuler le problème en une phrase testable
nommer l’utilisateur et la décision améliorée
mesurer la friction actuelle
choisir les données à partir du cas d’usage
noter valeur, faisabilité, risque et adoption avant de financer

Une formulation exploitable peut prendre cette forme : « Pour telle population et tel parcours, aider telle équipe à produire telle sortie, en réduisant tel délai ou telle reprise, sans dépasser tel niveau d’erreur critique. » Cette phrase est volontairement exigeante : elle oblige à nommer les bénéficiaires, les limites et la preuve attendue.

2. Le modèle opérationnel cible

La robustesse vient de la décomposition. Une demande globale adressée à un modèle mélange souvent reconnaissance, recherche, règles, rédaction et décision. En séparant ces fonctions, l’entreprise peut tester chaque maillon, choisir son niveau de contrôle et changer un composant sans rendre tout le système inexplicable.

Chaîne de traitement proposée pour le cadrage d’un projet IA d’assurance avant le chantier de données
Étape	Travail attendu	Contrôle indispensable
Observer le travail	Suivre des dossiers réels, les attentes, reprises et contournements.	Ne pas confondre procédure théorique et activité effective.
Formuler le problème	Décrire qui fait quoi, sur quelle population, avec quel résultat.	Bannir les formulations centrées sur une technologie.
Établir la référence	Mesurer volume, délai, effort, qualité et variabilité.	Documenter les segments qui rendent la moyenne trompeuse.
Identifier les données	Lister uniquement les entrées nécessaires à l’hypothèse.	Qualifier disponibilité, qualité, droits et coût d’accès.
Évaluer le risque	Étudier conséquence d’une erreur, contrôle et réversibilité.	Réduire le périmètre si la preuve disponible est insuffisante.
Dessiner le pilote	Définir population, durée, seuils et décision de sortie.	Prévoir l’arrêt comme un résultat possible et utile.

Définir un contrat de sortie

Chaque étape doit produire une sortie structurée : valeur, source, date, niveau d’incertitude, règle appliquée et action recommandée. Ce contrat rend le système testable. Il évite qu’une phrase éloquente remplace des champs dont l’équipe a réellement besoin.

L’abstention fait partie de ce contrat. Elle doit préciser pourquoi le système ne conclut pas : document illisible, identité ambiguë, version absente, contradiction, règle inconnue ou niveau de risque trop élevé. Une abstention bien orientée est une fonction productive, parce qu’elle concentre l’attention humaine là où elle apporte de la valeur.

Concevoir le rôle humain

« Un humain valide » ne décrit pas un contrôle. Il faut préciser ce qu’il voit, combien de temps il possède, ce qu’il peut modifier, s’il peut refuser, et comment sa correction sera enregistrée. La preuve doit être accessible au même endroit que la proposition. Une validation qui oblige à ouvrir quatre applications sera rapidement contournée.

3. Trois cas concrets dans les opérations d’assurance

Les exemples suivants sont des scénarios de conception, pas des promesses chiffrées ni des références clients. Ils montrent comment traduire le cadre dans des situations observables.

Cas 1 — Souscription professionnelle

« Utiliser l’IA pour la souscription » devient « réduire le temps de contrôle de complétude sans manquer une pièce critique sur tel produit ».

Dans ce scénario, la bonne question n’est pas « le modèle a-t-il répondu ? », mais « l’équipe peut-elle comprendre la proposition, retrouver sa preuve et choisir la prochaine action sans reconstruire tout le dossier ? ». Le test doit intégrer un cas normal, un cas ambigu et un cas où le système doit s’abstenir.

Cas 2 — Service client

« Répondre avec un chatbot » devient « préparer une réponse sourcée aux demandes de statut, relue par le gestionnaire, sur les dossiers actifs ».

Cas 3 — Sinistres

« Détecter la fraude » devient d’abord « prioriser pour revue les dossiers présentant des incohérences définies, sans retarder les autres assurés ».

Ce que ces cas ont en commun

Le système utile ne cherche pas à remplacer le jugement par une réponse globale. Il réduit la partie mécanique, rassemble les preuves, met en évidence les incohérences et prépare la prochaine action. Plus l’impact potentiel augmente, plus la restitution doit séparer le fait, la règle, l’interprétation et la décision.

4. Architecture, données et intégration

Une architecture viable sépare six responsabilités : accès aux sources, préparation des données, moteurs de recherche ou de prédiction, règles métier, orchestration des actions et interface de contrôle. Cette séparation facilite la sécurité, l’évaluation, la réversibilité et le remplacement d’un modèle.

Les sources à cartographier

La cartographie ne se limite pas au CRM. Elle inclut documents, e-mails, référentiels produit, contrats et avenants, procédures, tâches, décisions antérieures et journaux techniques. Pour chaque source, documentez propriétaire, finalité, fraîcheur, qualité, base d’accès, durée de conservation et population autorisée.

Le principe de minimisation reste concret : ne transmettre au composant que les données nécessaires à l’étape. Le fait qu’une information soit accessible dans le système d’origine ne signifie pas qu’elle doive entrer dans chaque prompt, index ou journal.

Identité, droits et cloisonnement

Les droits doivent être appliqués avant la recherche et avant l’action, pas seulement masqués dans l’interface. Un utilisateur ne doit pas pouvoir faire apparaître un dossier hors portefeuille par une formulation détournée. Les tests incluent donc homonymes, changements d’affectation, délégations temporaires et suppression d’un droit.

Versions et traçabilité

Pour reproduire une sortie, il faut connaître les versions du modèle, du prompt, des règles, du corpus, de l’index et des connecteurs. Le journal doit aussi conserver les sources proposées, l’action humaine et le résultat final. Cette traçabilité sert l’audit, mais surtout le diagnostic quotidien : sans elle, une baisse de qualité devient une discussion d’opinions.

Mode dégradé

La production doit continuer lorsque le modèle, l’index ou un connecteur tombe. Le mode dégradé définit les fonctions désactivées, le retour au parcours manuel, les messages aux utilisateurs, la file d’attente et les critères de reprise. Il est testé avant le lancement, comme une fonction du produit.

5. Les principaux risques et leurs contrôles

Registre initial des risques
Risque	Conséquence possible	Contrôle de départ
solution cherchant un problème	Erreur silencieuse ou traitement du mauvais périmètre.	Preuve visible, abstention et contrôle ciblé.
nettoyage sans finalité	Décision difficile à expliquer, corriger ou contester.	Journalisation, seuil d’alerte et revue par le propriétaire métier.
problème trop large	Dégradation progressive non visible dans un score global.	Preuve visible, abstention et contrôle ciblé.
utilisateur non impliqué	Erreur silencieuse ou traitement du mauvais périmètre.	Journalisation, seuil d’alerte et revue par le propriétaire métier.
absence de baseline	Décision difficile à expliquer, corriger ou contester.	Preuve visible, abstention et contrôle ciblé.
confusion entre disponibilité et droit d’usage	Dégradation progressive non visible dans un score global.	Journalisation, seuil d’alerte et revue par le propriétaire métier.

Tester les bords, pas seulement le centre

Le jeu d’évaluation doit contenir des dossiers incomplets, contradictoires, anciens, rares et difficiles à lire. Il doit aussi tester les demandes hors périmètre, les formulations ambiguës et les tentatives d’accès non autorisé. Ce sont ces cas qui révèlent la capacité du système à s’abstenir et celle de l’organisation à reprendre la main.

Observer le risque cumulé

Une erreur apparemment faible peut devenir importante à grande échelle. Une mauvaise priorité sur 1 % des messages, une relance inutile ou une source obsolète répétée plusieurs milliers de fois crée un coût, une irritation et parfois un risque de conformité. La revue doit donc combiner gravité unitaire, fréquence et détectabilité.

6. Mesurer la valeur et la maîtrise

La mesure commence avant le pilote. Sans référence du processus actuel, l’équipe compare la solution à une impression. Il faut mesurer plusieurs semaines, distinguer temps d’attente et temps actif, puis segmenter par complexité, produit, canal et équipe.

Tableau de bord pour le cadrage d’un projet IA d’assurance avant le chantier de données
Indicateur	Méthode	Rythme
1. clarté de l’unité de travail	Mesurer le flux de bout en bout, avec une référence antérieure au pilote.	Hebdomadaire pendant le pilote, puis mensuel.
2. volume réellement adressable	Mesurer le flux de bout en bout, avec une référence antérieure au pilote.	À chaque revue de performance et après changement majeur.
3. temps et coût du processus actuel	Segmenter par produit, complexité et niveau de risque ; examiner les dispersions, pas seulement la moyenne.	Hebdomadaire pendant le pilote, puis mensuel.
4. disponibilité des données nécessaires	Segmenter par produit, complexité et niveau de risque ; examiner les dispersions, pas seulement la moyenne.	À chaque revue de performance et après changement majeur.
5. part des cas réversibles	Segmenter par produit, complexité et niveau de risque ; examiner les dispersions, pas seulement la moyenne.	Hebdomadaire pendant le pilote, puis mensuel.
6. capacité à construire une vérité de référence	Suivre dans le temps et relier toute variation à un changement de corpus, de règle, de modèle ou d’usage.	À chaque revue de performance et après changement majeur.
7. délai jusqu’à une décision de pilote	Suivre dans le temps et relier toute variation à un changement de corpus, de règle, de modèle ou d’usage.	Hebdomadaire pendant le pilote, puis mensuel.

De la capacité libérée à la valeur économique

Du temps gagné n’est pas automatiquement une économie. Il peut réduire un stock, absorber une croissance, améliorer un délai client ou libérer une expertise rare. Le business case doit dire lequel de ces effets est recherché, comment il sera capturé et quel coût complet lui est opposé : licences, appels, intégration, contrôle, support, supervision et changement.

Fixer les seuils avant les résultats

Les critères d’extension et d’arrêt sont décidés avant la lecture des scores. Cette discipline évite d’abaisser un seuil pour sauver un projet déjà visible. Les indicateurs critiques doivent être bloquants ; d’autres peuvent donner lieu à une itération. La décision finale documente les bénéfices, les risques résiduels et les conditions de maintien.

7. Une feuille de route réaliste en 90 jours

Jours 1 à 20 — cadrer et mesurer

Nommer le propriétaire métier, observer le flux, écrire la finalité, établir la baseline, cartographier les données et dresser le registre initial des risques. Sélectionner un périmètre assez étroit pour être évalué et assez fréquent pour produire des observations.

Jours 21 à 45 — construire la référence

Constituer un jeu d’évaluation stratifié, faire annoter les cas ambigus par plusieurs experts, définir le contrat de sortie et les seuils. Prototyper l’intégration minimale et le chemin de preuve ; ne pas attendre la fin pour découvrir que l’utilisateur ne peut pas vérifier le résultat.

Jours 46 à 70 — tester en mode silencieux

Faire tourner le système en parallèle sans modifier les décisions. Comparer aux résultats réels, analyser les désaccords, mesurer coût et latence et tester les scénarios adverses. Corriger d’abord le corpus, les règles et le parcours avant d’attribuer toute faiblesse au seul modèle.

Jours 71 à 90 — assister un groupe limité

Ouvrir à un petit groupe formé, avec support court, journal des corrections, mode dégradé et points de revue fréquents. À la fin, décider : arrêter, recadrer, prolonger avec une hypothèse précise ou étendre à un nouveau segment. Une extension générale n’est jamais la conséquence automatique d’une démonstration réussie.

8. Gouvernance, RGPD, AI Act et attentes du secteur

La gouvernance ne consiste pas à produire un dossier à la veille de la mise en service. Elle commence avec la finalité et accompagne tout le cycle de vie. L’EIOPA retient une approche proportionnée au risque et insiste notamment sur les responsabilités, la gouvernance des données, la traçabilité, l’équité, la cybersécurité, l’explicabilité, la supervision humaine et la robustesse.

Le RGPD reste applicable dès qu’il existe un traitement de données personnelles. La finalité, la minimisation, l’information, les droits et la sécurité doivent être conçus dans l’architecture. L’article 22 appelle une attention particulière lorsqu’une décision est exclusivement automatisée et produit un effet juridique ou affecte significativement une personne. Une présence humaine nominale ne suffit pas : l’intervention doit être réelle.

Le règlement européen sur l’intelligence artificielle impose de qualifier le rôle de l’organisation et le niveau de risque du système, puis d’appliquer les obligations selon le calendrier et le cas. Cette analyse doit être menée avec le juridique et la conformité sur le système précis ; le mot « copilote » ou « assistant » ne détermine pas, à lui seul, le régime.

Un RACI minimal

Le propriétaire métier répond de la finalité, des règles, des seuils et du résultat opérationnel.
La donnée répond des sources, de la qualité, des accès, des versions et de la conservation.
La technologie répond de l’architecture, des changements, de la disponibilité et de la réversibilité.
La sécurité analyse les menaces, les secrets, les fournisseurs, la journalisation et les incidents.
La conformité et le DPO qualifient les exigences, les droits, l’information et les contrôles.
Les utilisateurs contribuent à l’évaluation, signalent les limites et gardent une capacité de contestation.

9. Check-list avant décision

Le problème tient en une phrase avec population, action, résultat et contrainte.
Une baseline documente volume, délai, temps actif, reprise et erreurs actuelles.
Chaque sortie critique renvoie vers une source ou une règle vérifiable.
L’abstention et l’escalade sont conçues, testées et orientées vers une personne nommée.
Les droits sont appliqués avant recherche et avant exécution.
Le jeu d’évaluation représente les cas difficiles et les segments sensibles.
Les seuils de réussite, d’arrêt et de retour arrière sont écrits.
Le coût complet inclut intégration, vérification, exploitation et réversibilité.
Un mode dégradé a été joué avec les utilisateurs.
Les versions et changements peuvent être reliés aux résultats observés.
Les responsabilités après le projet figurent dans les fiches de rôle.
Le comité peut choisir l’arrêt sans que celui-ci soit présenté comme un échec.

10. Ce qui va évoluer dans les prochains mois

Les modèles vont changer plus vite que les processus d’assurance. La capacité durable ne résidera donc pas dans un prompt isolé, mais dans le corpus gouverné, les évaluations, les règles explicites, l’intégration et la faculté de remplacer un composant. Les organisations qui investissent dans ces actifs pourront tester de nouveaux modèles sans reprendre tout le projet.

La supervision deviendra aussi plus continue. Les revues annuelles ne suffisent pas pour un système dont le corpus, les utilisateurs et les modèles évoluent. Les tableaux de bord devront relier changements techniques, changements métier, qualité par segment, incidents et décisions de gouvernance.

Enfin, le débat se déplacera de « l’IA sait-elle répondre ? » vers « l’organisation sait-elle prouver pourquoi cette réponse ou cette action était acceptable dans ce dossier précis ? ». C’est ce passage de la performance spectaculaire à la maîtrise opérationnelle qui distingue un outil testé d’une capacité d’entreprise.

11. Questions fréquentes

Quand un chantier de données doit-il venir en premier ?

Lorsqu’une obligation, une dépendance stratégique ou plusieurs cas prioritaires exigent le même socle. Même alors, des usages concrets doivent guider les critères de qualité.

Comment choisir entre plusieurs cas d’usage ?

Notez valeur, faisabilité, risque, mesurabilité et capacité d’adoption. Écartez les cas séduisants dont personne ne possède le processus.

Qui doit écrire le problème ?

Le propriétaire métier avec les utilisateurs, aidé par la donnée, l’IT, la conformité et les risques. Un prestataire peut faciliter, pas posséder la finalité.

Quel niveau de précision faut-il ?

Assez pour définir une population, une entrée, une sortie, une baseline, un coût d’erreur et un protocole d’évaluation.

Quelle équipe faut-il réunir ?

Un propriétaire du processus, deux ou trois utilisateurs expérimentés, la donnée, l’IT, la sécurité, la conformité et les risques. Pour le cadrage d’un projet IA d’assurance avant le chantier de données, chacun doit avoir un livrable précis plutôt qu’un simple rôle consultatif.

Comment éviter un pilote sans lendemain ?

Inclure dès le cadrage l’intégration, l’exploitation, les droits d’accès, le coût récurrent et la personne qui possédera le service après le projet. La décision de passage à l’échelle doit être préparée avant le premier test.

Que documenter pour l’audit ?

La finalité, le périmètre, les versions, le jeu d’évaluation, les résultats par segment, les corrections, les incidents, les droits, les décisions de revue et les critères de retrait.

À quelle fréquence réévaluer ?

Après tout changement significatif et selon un rythme proportionné au risque. Un suivi mensuel peut convenir à un pilote ; les alertes critiques, elles, doivent être continues.

12. Pour approfondir

Ce sujet gagne à être lu avec les dimensions de cadrage, de mesure, d’architecture et de contrôle développées dans les dossiers suivants :

13. Sources et références

Ces références fournissent le cadre institutionnel. Leur application dépend du rôle de l’organisation, de la finalité, des données et du système considéré ; l’article ne constitue pas un avis juridique.