Réversibilité d’un fournisseur IA en assurance : la tester avant de signer

Un fournisseur d’intelligence artificielle peut sembler remplaçable parce que son service est accessible par API. Pourtant, l’API n’est souvent que la surface. Autour d’elle se construisent des instructions, des formats, une base de connaissances, des évaluations, des outils, des règles de sécurité, des tableaux de bord, des procédures et des habitudes opérationnelles. Le changement devient difficile non parce qu’une donnée est prisonnière, mais parce que le service réel n’a jamais été décrit indépendamment du fournisseur.

La clause de réversibilité est nécessaire. Elle peut obtenir une assistance, un délai, un export et des droits d’audit. Elle ne garantit pas que les fichiers seront exploitables, que les traces permettront de répondre à une réclamation, que le modèle de remplacement passera les cas critiques ou que les équipes sauront continuer pendant la transition.

Avant de signer, l’assureur doit donc demander une preuve concrète : pouvons-nous maintenir la fonction métier, récupérer nos actifs et expliquer les décisions si ce fournisseur devient indisponible ou inadéquat ? Le test transforme cette question en opérations observables et en exigences négociables.

La vraie question : que faut-il préserver ?

« Changer de modèle » n’est pas une finalité métier. L’objectif peut être de continuer à classer les courriers entrants, de préparer les dossiers de souscription ou de rechercher une clause avec un niveau de qualité acceptable. La première étape consiste donc à définir le service minimal à préserver, ses utilisateurs, ses volumes, ses dépendances et ses risques.

Un plan sérieux distingue quatre résultats :

• continuité : la fonction essentielle continue, éventuellement en mode dégradé ;
• portabilité : les actifs récupérés sont complets, documentés et lisibles ;
• substituabilité : une autre solution produit un résultat acceptable sur les cas pertinents ;
• preuve : l’organisation conserve les éléments nécessaires pour expliquer le passé et contrôler le futur.

Fixez aussi l’unité de comptage avant l’exercice : dossier, document, appel, décision ou action confirmée. Elle permet de rapprocher l’inventaire de départ, ce qui a été exporté, ce qui a été importé et ce qui reste en attente. Sans ce dénominateur commun, chaque équipe peut annoncer une migration complète à partir d’un périmètre différent.

Ces résultats peuvent diverger. Un export complet n’assure pas la substituabilité. Une seconde API peut être disponible sans savoir reprendre l’historique. Un mode manuel peut préserver la continuité quelques heures mais pas absorber durablement le volume. Le test doit rendre ces écarts visibles.

La décision « construire, acheter ou assembler » est approfondie dans la grille de choix d’une IA assurance. La réversibilité ajoute un critère souvent sous-estimé : la solution retenue reste-t-elle gouvernable le jour où les conditions changent ?

Les sept couches de la réversibilité IA

Tableau — Les sept couches à éprouver dans un test de réversibilité

Couche	Actifs à récupérer ou recréer	Test révélateur
1. Données	Documents, index, métadonnées, annotations, droits et historique utile	Importer un échantillon exporté dans un environnement neutre et rapprocher les comptes
2. Modèle	Version, paramètres, capacités attendues et limites connues	Rejouer les cas critiques sur un candidat de remplacement
3. Instructions	Prompts, gabarits, règles, vocabulaires et configurations	Reconstituer le comportement sans console propriétaire
4. Évaluations	Jeux de test, critères, annotations, résultats et seuils de décision	Exécuter la même recette et comparer erreur par erreur
5. Outils	Schémas, connecteurs, identités, politiques et mécanismes d’approbation	Faire passer un parcours de bout en bout avec des interfaces substituées
6. Exploitation	Alertes, support, déploiement, procédures, capacité et coûts complets	Opérer un créneau réel contrôlé avec l’équipe cible
7. Preuves	Traces, décisions, versions, incidents, consentements et éléments d’audit	Répondre à une demande d’explication sur un dossier historique

La propriété juridique et la disponibilité technique doivent être examinées séparément. L’assureur peut posséder un jeu d’évaluation sans disposer du format d’export, ou obtenir les journaux sans leur schéma. À l’inverse, un format documenté n’est utile que si les droits permettent de réutiliser les données et si les éléments personnels ou confidentiels sont traités conformément aux finalités.

Abstraire ce qui doit rester stable

Une couche d’adaptation peut normaliser les demandes, les réponses, les erreurs et les appels d’outils. Elle réduit le couplage, mais ne rend pas les modèles équivalents. Des fournisseurs différents ne gèrent pas les mêmes formats, longueurs, outils ou politiques de sécurité. Chercher le plus petit dénominateur commun peut aussi sacrifier une capacité utile.

L’abstraction doit porter sur le contrat métier : les champs nécessaires, les preuves attendues, les états d’erreur, l’abstention et les actions autorisées. Les particularités des fournisseurs restent isolées dans des adaptateurs versionnés et testés. Le routage entre modèles peut alors soutenir la continuité, à condition qu’il soit évalué sous contrainte de qualité et de risque, pas seulement de disponibilité.

Ce que le cadre européen change

Pour les entités financières relevant de son champ, le règlement DORA intègre le risque lié aux prestataires de services TIC dans le cadre de gestion du risque. Son article 28 demande, pour les services TIC soutenant une fonction critique ou importante, des stratégies de sortie tenant compte notamment d’une défaillance, d’une dégradation, d’une interruption ou d’une fin de contrat. Les plans doivent être documentés, suffisamment testés et revus périodiquement, avec des solutions alternatives et des plans de transition.

Le règlement délégué (UE) 2024/1773 précise la politique applicable aux accords concernant des services TIC soutenant des fonctions critiques ou importantes. Son article 10 prévoit un plan de sortie documenté par accord, revu et testé périodiquement, fondé sur des scénarios plausibles et des hypothèses raisonnables. Il demande aussi un calendrier compatible avec les conditions contractuelles de sortie.

Les chaînes de sous-traitance comptent autant que le fournisseur visible. Le règlement délégué (UE) 2025/532 précise les éléments à déterminer et évaluer lorsque des services TIC soutenant des fonctions critiques ou importantes sont sous-traités. Il traite notamment le suivi de la chaîne, la localisation, la continuité, les droits d’accès et d’audit, les changements matériels et certaines conditions de résiliation.

Ces textes ne signifient pas que tout abonnement à un modèle est une fonction critique ou importante, ni que toutes les organisations du marché de l’assurance relèvent exactement du même périmètre. La fonction soutenue, l’entité, les dépendances et l’impact doivent être qualifiés avec les équipes juridique, risque et conformité.

Le règlement (UE) 2023/2854, dit Data Act, contient par ailleurs des dispositions sur le changement entre services de traitement de données et sur les conditions contractuelles associées. Leur applicabilité à un service IA précis, ainsi que les éventuelles exclusions, doit être analysée. Elles ne dispensent pas du test métier : la possibilité légale de changer ne prouve pas que le remplaçant satisfait les critères d’assurance.

La grille de due diligence avant contrat

1. Décrire le service réel

• Quelle fonction métier dépend du service et quel serait l’effet d’une indisponibilité ?
• Quels composants appartiennent au fournisseur, à ses sous-traitants et à l’assureur ?
• Quelles versions peuvent changer, avec quel préavis et quelle période de coexistence ?
• Quelles fonctionnalités sont standard, spécifiques ou construites dans une console non exportable ?
• Quels volumes, pointes, langues, formats et régions doivent être maintenus ?

2. Inventorier les actifs et leurs droits

Demandez un dictionnaire d’export, pas le mot « export ». Pour chaque actif : propriétaire, format, fréquence, historique, chiffrement, canal de transfert, coût, délai, volume, intégrité vérifiable et procédure d’effacement. Clarifiez le sort des données dérivées : annotations, index, embeddings, configurations, feedbacks, évaluations et journaux.

Un export doit préserver les relations indispensables. Dix mille fichiers sans identifiant de dossier, version, habilitation ou source ne constituent pas une restitution opérationnelle. Un test par échantillon compare nombre d’objets, identifiants, sommes de contrôle, métadonnées et droits d’accès.

3. Prouver la substitution

Le fournisseur doit expliquer les dépendances propriétaires ; l’assureur doit maintenir un jeu de recette indépendant. Ce jeu couvre les cas fréquents, critiques, ambigus et dégradés, sans se limiter à une moyenne. Le remplaçant est évalué sur le même contrat métier : qualité des champs, fidélité aux sources, abstention, sécurité, latence de bout en bout et coût par dossier utilisable.

Pour les modèles avancés, l’article choisir un modèle de pointe pour l’assurance rappelle qu’un nom ou un score public ne remplace pas l’évaluation sur le corpus et les risques propres au service. La réversibilité doit accepter qu’un remplaçant nécessite un autre découpage, tout en conservant la promesse métier et les contrôles.

4. Vérifier l’exploitation

Qui dispose des compétences, des comptes et de la documentation pour déclencher la sortie ? Où sont les configurations ? Peut-on déployer sans l’équipe du fournisseur ? Le support de transition est-il inclus ? Les équipes savent-elles traiter le stock pendant la migration ? Une architecture portable sans opérateur disponible n’est pas une capacité.

Un exercice de sortie chronométré

L’exercice ne consiste pas à résilier le contrat. Il crée un périmètre sûr, limité et représentatif dans lequel l’équipe exécute les opérations de sortie. Les objectifs de temps et de qualité sont décidés avant l’essai à partir du besoin métier. Ils ne constituent ni une exigence réglementaire universelle ni une promesse commerciale.

1. Déclencher : choisir un scénario plausible — retrait de version, dégradation persistante, désaccord contractuel ou indisponibilité — et activer la gouvernance prévue.
2. Geler : figer les versions et limiter les nouvelles dépendances pendant l’exercice.
3. Exporter : demander les actifs convenus par le canal contractuel ; enregistrer délais, écarts et interventions.
4. Vérifier : rapprocher l’inventaire, contrôler intégrité, schémas, liens, droits, historique et lisibilité.
5. Transformer : appliquer les adaptations nécessaires vers le format cible, en mesurant ce qui reste manuel.
6. Rejouer : exécuter le jeu de recette et comparer par risque, pas seulement par moyenne.
7. Opérer : faire traiter un lot limité par l’équipe cible, avec supervision et possibilité de retour arrière.
8. Réconcilier : vérifier les dossiers traités, les actions en vol, les traces et les différences de résultat.
9. Décider : classer les écarts en bloqueurs, corrections contractuelles, dette acceptée ou changement d’architecture.

Chronométrez séparément le délai d’obtention, le temps machine, le temps humain et l’attente de décision. Un fournisseur peut livrer vite un export qui exige des semaines de nettoyage. À l’inverse, un transfert volumineux peut être long mais parfaitement automatisé. La ventilation révèle la vraie contrainte.

Le compte rendu doit conserver les preuves reproductibles : versions, volumes, résultats, écarts, scripts, tickets et décisions. Il ne doit pas embarquer des données personnelles inutiles. Les jeux de test peuvent être minimisés ou synthétiques si leur représentativité et leurs limites sont documentées.

Traduire les preuves dans le contrat

Tableau — Clauses contractuelles et preuves attendues pour rendre la sortie exécutable

Sujet	Clause à rendre précise	Preuve associée
Périmètre	Services, versions, régions, sous-traitants et fonctions couvertes	Cartographie validée et tenue à jour
Restitution	Actifs, formats, schémas, historique, canal, intégrité et assistance	Export échantillon importé avec succès
Changement	Préavis, documentation, coexistence et critères de changement matériel	Rejeu d’une migration de version
Transition	Continuité, capacité, support, responsabilités et période applicable	Exercice de bascule limité
Audit	Accès aux informations, preuves, sites et sous-traitants selon le droit applicable	Demande d’information exécutée
Effacement	Données, copies, sauvegardes, dérivés, délais et attestation	Procès-verbal et contrôles définis
Coûts	Export, assistance, trafic, prolongation, licences et litiges	Estimation sur volumes représentatifs

Les termes « standard », « raisonnable » ou « dans les meilleurs délais » doivent être reliés à des livrables, des responsabilités et une procédure. Une clause très détaillée peut pourtant rester inopérante si elle exige un outil que l’assureur ne possède pas. Négociation, architecture et exploitation doivent être menées ensemble.

Les changements de sous-traitants méritent une attention particulière. Le fournisseur de modèle peut dépendre d’un hébergeur, d’un service de filtrage, d’une base vectorielle ou d’un opérateur de support. Le contrat doit permettre d’identifier les dépendances matérielles, d’évaluer leur changement et de préserver les droits nécessaires dans la chaîne, sous réserve du cadre applicable.

Scénario hypothétique : changer un service de tri de courriers

Imaginons un assureur qui utilise un service externe pour classer les courriers entrants, extraire le numéro de contrat et orienter les documents vers une file. Le scénario est entièrement hypothétique. Le service ne décide ni de la garantie ni du paiement, mais une mauvaise orientation peut retarder un dossier.

Avant le contrat, l’équipe construit un lot représentatif, avec documents lisibles, scans dégradés, plusieurs produits et pièces ambiguës. Elle conserve ses annotations et critères. Le fournisseur exporte la configuration, les résultats et les traces convenues. Un second service reçoit le même contrat d’entrée et de sortie via un adaptateur.

Le test révèle les écarts utiles à négocier : certaines règles n’existent que dans une interface, les libellés de confiance ne sont pas comparables, l’historique des corrections n’a pas de format d’export et le routage vers les files dépend d’identifiants propriétaires. Aucun de ces constats ne prouve que le fournisseur est inadéquat. Ils montrent ce qui doit être rendu portable, documenté ou accepté consciemment.

Le lot pilote est traité en parallèle, sans action automatique sur les dossiers clients. Les équipes comparent les erreurs par conséquence métier, puis simulent une interruption et utilisent la file manuelle. Le comité peut alors arbitrer entre plusieurs options : investir dans l’adaptateur, renforcer le contrat, conserver une double capacité limitée ou accepter une dépendance avec un plan de continuité.

Décider avec une scorecard, pas une promesse

Attribuez une appréciation documentée à chaque dimension, avec un bloqueur lorsque l’échec rend la sortie impossible :

• complétude et intégrité des actifs restitués ;
• lisibilité et stabilité des formats ;
• couverture des cas critiques par la solution de repli ;
• écart de qualité par segment et type de document ;
• continuité du service pendant la transition ;
• capacité à expliquer les dossiers historiques ;
• temps humain et compétences nécessaires ;
• coût complet de sortie et d’exploitation temporaire ;
• dépendances de second rang ;
• écarts contractuels non résolus.

La moyenne ne doit pas masquer un échec critique. Un excellent export de documents ne compense pas l’impossibilité de rapprocher les actions déjà engagées. Une substitution légèrement moins performante en moyenne peut être acceptable si les cas à fort impact sont protégés ; l’inverse ne l’est pas nécessairement.

Limites et arbitrages honnêtes

Une absence totale de verrouillage n’existe pas. Toute solution crée des coûts d’apprentissage, d’intégration et de changement. La réversibilité vise à connaître et maîtriser ces coûts, pas à rendre tous les fournisseurs interchangeables. Une capacité propriétaire peut être choisie si sa valeur justifie une dépendance explicitement gouvernée.

Maintenir en permanence deux fournisseurs complets peut doubler les contrôles, les contrats et les surfaces de risque. Une solution de repli peut être dégradée : règles simples, traitement manuel priorisé ou modèle secondaire réservé aux fonctions essentielles. Le bon niveau dépend de l’impact d’une interruption et de la durée supportable.

Enfin, un test vieillit. Les versions, volumes, sous-traitants, formats et équipes changent. Définissez les événements qui imposent un nouveau test : changement matériel, extension de périmètre, hausse de criticité, incident, modification de chaîne ou résultat de surveillance. La périodicité fixe complète ces déclencheurs ; elle ne les remplace pas.

Questions fréquentes

Un export JSON suffit-il à prouver la réversibilité ?

Non. Il faut vérifier le schéma, la complétude, les relations, l’historique, les droits et la capacité d’import. Puis il faut démontrer la continuité et la qualité du service de remplacement.

Faut-il contractualiser un fournisseur de secours ?

Pas toujours. Cela dépend de la criticité, du temps de bascule et de la capacité manuelle. Mais une simple liste de fournisseurs possibles n’est pas un plan si aucun n’a été évalué sur le contrat métier.

La réversibilité doit-elle couvrir les prompts ?

Oui, si les instructions contribuent au service. Conservez-les dans un espace maîtrisé, versionné et testable, en distinguant les éléments propres au fournisseur des règles métier stables.

Qui doit posséder l’exercice ?

Le propriétaire de la fonction métier en porte la continuité. Achats, juridique, DSI, sécurité, data, risque et opérations apportent chacun une partie de la preuve. La coordination ne doit pas être abandonnée au seul fournisseur.

Sources et références

• Règlement (UE) 2022/2554 sur la résilience opérationnelle numérique du secteur financier (DORA), notamment articles 28 et 30 ; texte officiel consulté le 7 septembre 2026.
• Règlement délégué (UE) 2024/1773, notamment article 10 sur les plans de sortie.
• Règlement délégué (UE) 2025/532 sur les éléments à déterminer et évaluer pour certaines chaînes de sous-traitance TIC.
• Autorités européennes de surveillance, informations sur les modèles du registre DORA, page institutionnelle tenue par l’EBA.
• Règlement (UE) 2023/2854 sur des règles harmonisées concernant l’accès équitable aux données et leur utilisation (Data Act), notamment le chapitre relatif au changement de services de traitement de données ; applicabilité à qualifier au cas par cas.