Acheter ou construire une IA assurance : grille de décision

Ce qu’il faut retenir

choisir couche par couche ce qui doit être acheté, configuré, construit ou gardé réversible.
réserver la construction à la différenciation métier : c’est le premier résultat à rendre mesurable.
évaluer la maîtrise des données et des droits : la qualité moyenne ne suffit pas à démontrer la maîtrise.
inclure intégration, supervision et sortie dans le coût total : 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 : Benchmark et grille de décision. Public : dirigeants, directions des opérations, innovation, DSI, responsables IA, courtiers, assureurs et assurtechs.

Une solution IA n’est pas un bloc. Elle combine modèles, OCR, recherche, règles, orchestration, connecteurs, identité, interface, évaluation et supervision. Acheter l’ensemble peut créer une dépendance et un ajustement médiocre ; tout construire immobilise des équipes sur des composants banalisés. L’arbitrage doit porter sur l’architecture réelle.

Ce dossier propose une méthode pour choisir couche par couche ce qui doit être acheté, configuré, construit ou gardé réversible. 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

réserver la construction à la différenciation métier
évaluer la maîtrise des données et des droits
inclure intégration, supervision et sortie dans le coût total
tester la capacité du fournisseur à produire des preuves
concevoir une architecture hybride remplaçable

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 l’arbitrage entre achat et construction d’une solution IA d’assurance
Étape	Travail attendu	Contrôle indispensable
Cartographier les couches	Séparer modèle, données, règles, orchestration, interface et exploitation.	Refuser un prix global impossible à rattacher aux fonctions critiques.
Identifier la différenciation	Repérer ce qui encode la manière propre de souscrire, gérer ou conseiller.	Un composant standard ne mérite pas toujours une équipe interne.
Évaluer le risque	Analyser données, décisions, dépendance et réversibilité par couche.	Les garanties contractuelles complètent mais ne remplacent pas les tests.
Comparer le coût total	Additionner licence, usage, intégration, contrôle, exploitation et sortie.	Projeter plusieurs volumes et scénarios de prix.
Tester sur un corpus réel	Comparer candidats sur les mêmes cas, y compris les échecs.	Conserver les résultats et les versions pour une décision auditable.
Négocier la réversibilité	Prévoir export, portabilité, délais, assistance et propriété des artefacts.	Tester une sortie avant que la dépendance devienne critique.

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 — OCR et extraction

Acheter un moteur générique est souvent rationnel ; les règles de rapprochement, les contrôles et la restitution peuvent porter la singularité métier.

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 — Assistant documentaire

Le modèle peut être substituable alors que le corpus versionné, les filtres d’accès et le banc d’évaluation doivent rester maîtrisés.

Pour approfondir le choix entre modèle frontière, modèle léger et règles déterministes, consultez notre guide sur les frontier models en assurance.

Cas 3 — Orchestration de souscription

Les connecteurs et décisions propres au produit peuvent justifier une construction interne, posée sur des briques de marché.

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
verrouillage fournisseur	Erreur silencieuse ou traitement du mauvais périmètre.	Preuve visible, abstention et contrôle ciblé.
données réutilisées sans maîtrise	Décision difficile à expliquer, corriger ou contester.	Journalisation, seuil d’alerte et revue par le propriétaire métier.
personnalisation assimilée à du sur-mesure	Dégradation progressive non visible dans un score global.	Preuve visible, abstention et contrôle ciblé.
coût variable non plafonné	Erreur silencieuse ou traitement du mauvais périmètre.	Journalisation, seuil d’alerte et revue par le propriétaire métier.
banc de test appartenant au vendeur	Décision difficile à expliquer, corriger ou contester.	Preuve visible, abstention et contrôle ciblé.
compétence interne insuffisante pour piloter	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 l’arbitrage entre achat et construction d’une solution IA d’assurance
Indicateur	Méthode	Rythme
1. coût total sur trois scénarios de volume	Mesurer le flux de bout en bout, avec une référence antérieure au pilote.	Hebdomadaire pendant le pilote, puis mensuel.
2. délai jusqu’au premier usage réel	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. part du système remplaçable sans réécriture	Segmenter par produit, complexité et niveau de risque ; examiner les dispersions, pas seulement la moyenne.	Hebdomadaire pendant le pilote, puis mensuel.
4. couverture des exigences de preuve	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. effort d’intégration et de maintien	Segmenter par produit, complexité et niveau de risque ; examiner les dispersions, pas seulement la moyenne.	Hebdomadaire pendant le pilote, puis mensuel.
6. temps de résolution d’un incident fournisseur	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. coût et durée de réversibilité	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

Un grand fournisseur est-il nécessairement moins risqué ?

Non. Sa pérennité peut être meilleure, mais la dépendance, l’opacité tarifaire ou un changement de produit restent des risques à tester et contractualiser.

Faut-il héberger le modèle soi-même ?

Seulement si les exigences de données, de latence, de contrôle ou de coût le justifient. L’auto-hébergement ajoute une responsabilité d’exploitation importante.

Comment comparer deux offres ?

Imposez un corpus, des scénarios, des métriques et un format de restitution communs. Une démonstration préparée par chaque vendeur n’est pas comparable.

Que faut-il garder en interne ?

Au minimum la finalité, les règles de décision, l’évaluation, la gouvernance des données, le suivi des risques et la capacité à contester le fournisseur.

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 l’arbitrage entre achat et construction d’une solution IA d’assurance, 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.