Ce qu’il faut retenir
- Un service d’IA acheté à un fournisseur n’est pas une ligne unique. Il peut mobiliser hébergement, modèle, recherche documentaire, observabilité, filtrage, stockage et support, avec plusieurs sous-traitants et régions.
- DORA impose aux entités financières de maîtriser le risque lié aux prestataires tiers de services TIC et de tenir un registre d’informations pour leurs accords contractuels. Le périmètre exact dépend du statut de l’entité et des services réellement fournis.
- Le règlement d’exécution (UE) 2024/2956 définit des modèles normalisés pour le registre. Une cartographie technique ou un inventaire achats ne les remplace pas ; les trois sources doivent être rapprochées.
- La chaîne de sous-traitance doit être reliée aux fonctions soutenues, à leur caractère critique ou important, aux contrats, aux données, aux lieux de prestation et aux conditions de changement.
- La qualité du registre se juge lors d’un événement : changement de modèle, nouvel hébergeur, incident, concentration, sortie ou demande du superviseur. Il doit alors permettre de savoir qui fait quoi, pour quelle fonction et sous quelle preuve.
Une direction peut croire acheter « un modèle ». L’architecture réelle comporte souvent une passerelle, plusieurs modèles activables, un cloud, une base vectorielle, un outil de filtrage, une plateforme d’observabilité et un service de support. Le contrat principal ne raconte pas toujours cette chaîne. Or une indisponibilité, une violation ou un changement de fournisseur peut se propager jusqu’à un processus de souscription, de gestion ou de relation client.
Le registre d’informations prévu par DORA transforme ce paysage en données gouvernables. Il n’est pas un catalogue marketing et ne doit pas être reconstruit quelques jours avant une demande. Sa valeur vient de la correspondance entre réalité technique, responsabilités contractuelles et fonctions de l’entreprise.
Qualifier l’entité, le service TIC et la fonction
Le règlement (UE) 2022/2554 sur la résilience opérationnelle numérique du secteur financier, dit DORA, s’applique depuis le 17 janvier 2025 aux entités financières énumérées par le texte. Il inclut notamment les entreprises d’assurance et de réassurance ainsi que certains intermédiaires d’assurance, avec des exclusions et un principe de proportionnalité à analyser. Il serait donc inexact d’affirmer que tout courtier, mandataire ou prestataire d’un assureur est soumis de manière identique à toutes ses dispositions.
La première fiche du dossier établit le statut de l’entité, les éventuelles exclusions, les règles de groupe et les responsabilités internes. Pour une filiale, un registre consolidé peut répondre à certains besoins, mais il doit permettre d’identifier les accords et fonctions de l’entité concernée. Le choix organisationnel ne doit pas effacer le périmètre juridique.
DORA définit les services TIC largement comme des services numériques et de données fournis de façon continue par l’intermédiaire de systèmes TIC, y compris matériels et services de support associés, avec les limites du texte. Un service d’inférence, une plateforme de développement, un hébergement ou une base utilisée par un système d’IA peuvent donc relever du registre selon leur fonctionnement contractuel. L’étiquette « IA » ne décide pas à elle seule.
Il faut ensuite relier le service à la fonction de l’entité. Une même API peut soutenir un prototype interne sans effet client, puis être étendue au traitement quotidien de documents. Le fournisseur n’a pas changé, mais la fonction, le volume, les données et le risque ont changé. Le cadre acheter ou construire une IA d’assurance aide à rendre explicites ces dépendances dès la décision d’architecture.
Décomposer un service IA en composants contractuels
Commencez par un diagramme d’exécution réel : lorsqu’un utilisateur envoie une requête, quels composants reçoivent des données, effectuent un calcul, conservent une trace ou décident du routage ? Pour chaque composant, notez l’entité juridique qui fournit le service, le contrat qui l’autorise et les sous-traitants annoncés.
Une architecture générative peut comprendre :
- l’application métier ou le portail utilisé par les collaborateurs ;
- la passerelle qui authentifie, filtre et dirige les requêtes ;
- un ou plusieurs fournisseurs de modèles ;
- un hébergeur ou une infrastructure d’exécution ;
- un stockage d’objets et une base de données ;
- un moteur de recherche ou une base vectorielle ;
- un fournisseur de journalisation, de sécurité ou d’observabilité ;
- une équipe de support, parfois distincte du fournisseur logiciel ;
- des composants open source opérés en interne ou par un tiers.
Tout composant technique n’est pas nécessairement un accord contractuel distinct. Inversement, un seul contrat-cadre peut couvrir plusieurs services TIC. La cartographie doit préserver les deux niveaux : la réalité de l’exécution et la structure juridique. Ne créez pas artificiellement un prestataire là où l’entité opère elle-même un logiciel ; documentez plutôt la composante interne et les tiers qui la soutiennent.
Le cas d’une passerelle multi-modèle illustre cette discipline. Le dossier sur Stripe, OpenRouter et le routage multi-modèle montre que le choix dynamique d’un fournisseur peut modifier coût, disponibilité, lieux de traitement et dépendances. Le registre et les contrats doivent refléter les fournisseurs effectivement autorisés, pas une catégorie vague comme « modèles du marché ».
Comprendre la logique du registre d’informations
L’article 28 de DORA demande aux entités financières de gérer le risque lié aux prestataires tiers de services TIC comme une composante du risque TIC et de maintenir, au niveau individuel, sous-consolidé et consolidé selon le cas, un registre d’informations sur tous les accords contractuels concernant l’utilisation de services TIC fournis par des tiers. Il prévoit une distinction entre les accords couvrant des services qui soutiennent des fonctions critiques ou importantes et les autres.
Le règlement d’exécution (UE) 2024/2956 établit les modèles normalisés de ce registre. Il organise des ensembles liés : entité, succursale, accord contractuel, prestataire, chaîne d’approvisionnement, fonction, service TIC, évaluation et définitions. La conformité n’est donc pas obtenue par un tableur libre contenant seulement le nom du fournisseur, le montant et la date de renouvellement.
L’EIOPA publie un espace officiel consacré à DORA, avec une rubrique sur le registre d’informations et les ressources de collecte pertinentes pour le secteur assurance. Ces ressources doivent être consultées pour le format et le canal applicables au moment de la remise. Un fichier techniquement valide peut rester matériellement faux si les fonctions, contrats ou chaînes sont incomplets.
La conception du registre repose sur trois principes :
- unicité : une entité, un accord, un fournisseur et une fonction disposent d’identifiants stables ;
- relation : les tables permettent de relier accord, service, fonction et sous-traitance sans recopier des textes divergents ;
- traçabilité : chaque donnée importante a une source, un propriétaire et une date de vérification.
Stabiliser identifiants, contrats et hiérarchie
Les erreurs commencent souvent par les noms. Une marque commerciale, une filiale contractante et une société mère peuvent être confondues. La chaîne doit utiliser la personne morale qui fournit le service au niveau concerné, avec les identifiants demandés par les modèles lorsque disponibles. Les alias restent utiles pour les opérations mais ne remplacent pas l’identité juridique.
Chaque accord reçoit un identifiant interne stable. Les annexes, bons de commande, conditions en ligne et avenants sont rattachés à l’accord plutôt que traités comme des fournisseurs indépendants. La hiérarchie doit permettre de voir un contrat-cadre, ses accords d’exécution et les services couverts. Un renouvellement ne doit pas casser l’historique ni faire disparaître les anciennes conditions applicables à un incident antérieur.
Pour un service acheté via un intégrateur, distinguez :
- la contrepartie contractuelle directe ;
- le fournisseur de la technologie ou du service sous-jacent ;
- les sous-traitants qui soutiennent la fonction ;
- les parties responsables du support, de l’incident et de la sortie.
La question n’est pas de qualifier juridiquement toute relation en cascade sans preuve. Il s’agit de représenter la chaîne requise par les modèles et pertinente pour le risque. Lorsque le fournisseur refuse une information, l’écart est enregistré, escaladé et intégré à la décision de risque ; une cellule vide silencieuse est trompeuse.
Cartographier la chaîne de sous-traitance
DORA encadre les accords contractuels et la gestion des sous-traitants, en particulier lorsque des services soutiennent une fonction critique ou importante. Le registre doit permettre d’identifier la chaîne telle que demandée par les modèles normalisés. Pour l’IA, cette chaîne peut changer vite : nouveau modèle, nouvelle région, nouvelle plateforme d’inférence ou transfert du support.
Demandez au fournisseur une liste structurée, pas une page web sans date. Pour chaque maillon : entité juridique, service rendu, pays, fonction soutenue, données accessibles, date d’effet, droit de modification et source contractuelle. Conservez la version reçue. Une URL publique peut compléter la preuve, mais son contenu peut évoluer sans laisser l’état applicable au contrat.
| Niveau | Question | Preuve | Alerte |
|---|---|---|---|
| Prestataire direct | Quelle entité signe et assume les obligations ? | Contrat, commande, identifiant juridique | Marque sans contrepartie identifiable |
| Sous-traitant essentiel à la prestation | Quel service exécute-t-il et pour quelle fonction ? | Annexe, liste versionnée, architecture | Catégorie générique sans nom ni lieu |
| Fournisseur de modèle | Le routage peut-il changer automatiquement ? | Configuration autorisée, journal de routage, conditions | Catalogue ouvert non maîtrisé |
| Infrastructure | Où le service est-il opéré et repris ? | Régions, plan de continuité, sous-traitance | Lieu du siège utilisé comme lieu de traitement |
La réponse officielle EIOPA DORA149-3210 précise que le registre inclut les sous-traitants lorsque le service fourni soutient effectivement un service TIC qui soutient une fonction critique ou importante, ou une partie substantielle de celle-ci. Les questions-réponses de supervision éclairent un point précis ; elles doivent être lues avec le règlement et les normes, sans en extrapoler une règle générale au-delà de leur objet.
Relier services, fonctions et criticité
Un fournisseur n’est pas « critique » par nature pour tous ses services. Une fonction critique ou importante est qualifiée au regard de l’entité, de ses obligations, de la continuité et des effets d’une perturbation. Un même cloud peut soutenir une fonction centrale et un espace de test secondaire. Le registre doit préserver cette relation.
Pour chaque service IA, décrivez la fonction soutenue en termes métier : recevoir une demande, extraire une pièce, préparer une proposition, surveiller une fraude, répondre à un client. Évitez les libellés « IA générative » ou « API » qui ne disent rien de l’impact. Puis documentez l’analyse de criticité, la décision, sa date et son propriétaire.
Les critères peuvent inclure :
- l’effet d’une indisponibilité sur les assurés et obligations contractuelles ;
- la possibilité et le délai de bascule vers un mode manuel ;
- le volume et la concentration des processus dépendants ;
- la sensibilité, l’intégrité et la disponibilité des données ;
- la réversibilité d’une sortie erronée déjà utilisée ;
- la substituabilité du prestataire ou du composant ;
- les dépendances communes avec d’autres fonctions.
Un mode manuel annoncé doit être testé. Si le personnel, les accès ou les données nécessaires ne sont pas disponibles, la substituabilité est fictive. La criticité n’est pas réduite par une simple phrase contractuelle.
Localisation, données et modalités de prestation
Le registre demande des informations sur les lieux de prestation et de traitement selon les modèles applicables. Pour un service distribué, ne confondez pas siège social, région de compte, lieu de stockage, lieu d’inférence, support et reprise. Les conditions peuvent autoriser plusieurs lieux ; le dossier distingue ce qui est utilisé, autorisé et activable.
La cartographie de données complète le registre sans le surcharger. Par service : catégories de données, niveau de sensibilité, chiffrement, rétention, utilisation éventuelle pour améliorer le service, accès de support et transferts. Les libellés restent cohérents avec l’inventaire de traitements et la sécurité.
Un système de recherche augmentée peut envoyer au fournisseur de modèle seulement un extrait, tandis que le corpus reste chez un autre hébergeur. Cela réduit certaines expositions mais crée une dépendance supplémentaire. Le registre doit permettre de reconstruire les deux flux. Le dossier sur la preuve et l’observabilité des systèmes génératifs aide à définir les traces qui confirment le fournisseur et la région réellement utilisés.
La minimisation des données ne se présume pas parce que le contrat promet de ne pas entraîner le modèle. Elle se vérifie dans la configuration, les journaux, les droits et les tests. Réciproquement, le registre DORA n’est pas un registre détaillé de toutes les données personnelles : il renvoie vers les inventaires compétents tout en conservant les informations exigées et utiles au risque TIC.
Gouverner les changements et les écarts
La chaîne évolue plus vite que la campagne annuelle de collecte. Le contrat doit prévoir l’information sur les changements pertinents, surtout pour les services qui soutiennent une fonction critique ou importante. L’organisation doit transformer cette notification en événement interne.
Un workflow de changement comprend :
- réception et horodatage de l’information ;
- identification des services, fonctions et entités affectés ;
- analyse des données, lieux, concentration, sécurité et continuité ;
- décision d’accepter, tester, limiter, contester ou sortir ;
- mise à jour du contrat, du registre et de l’inventaire technique ;
- vérification après la date d’effet.
Les changements non notifiés peuvent être détectés par les journaux, factures, en-têtes techniques, tests de performance ou annonces publiques. Une détection ne prouve pas à elle seule une violation contractuelle ; elle déclenche une enquête. L’écart entre configuration observée et information déclarée est conservé jusqu’à résolution.
Le routage multi-modèle exige une règle particulière : toute destination possible doit être préalablement autorisée selon des critères documentés. En cas d’incident, désactiver un modèle ne doit pas envoyer automatiquement les données vers un fournisseur non évalué. Le routeur de modèles pour l’assurance détaille les contrôles techniques et métiers nécessaires.
Contrôler qualité, cohérence et preuve
La qualité du registre ne se mesure pas seulement au nombre de champs remplis. Un contrôle en trois couches est plus utile.
Contrôles de structure
Ils vérifient les formats, identifiants, références, listes de valeurs, dates et relations obligatoires. Ils détectent un contrat orphelin, une fonction absente ou un fournisseur non relié. Ces contrôles peuvent être automatisés sans générer la vérité métier.
Contrôles de cohérence
Ils rapprochent registre, achats, comptes fournisseurs, inventaire cloud, outils de sécurité, architecture et registre des systèmes d’IA. Une API observée sans contrat ou un contrat payé sans service déclaré déclenche une revue. La différence peut être légitime : environnement de test, contrat de groupe, logiciel inutilisé. Elle doit être expliquée.
Contrôles de substance
Un propriétaire de fonction confirme que le service, la criticité, la sortie et la continuité décrites correspondent à la réalité. Les achats confirment l’accord ; la technique confirme la chaîne ; risques confirme l’analyse. Un échantillon est reconstruit de bout en bout avec les pièces.
| Indicateur | Unité | Responsable | Limite |
|---|---|---|---|
| Accords sans fonction reliée | Nombre et part, mensuels | Propriétaire du registre | Une fonction générique peut masquer un mauvais lien |
| Prestataires non vérifiés | Nombre par date de dernière preuve | Achats/risques tiers | Une preuve récente peut être incomplète |
| Écarts technique–registre | Nombre ouverts, âge médian | Architecture et gouvernance | Les outils ne voient pas les contrats hors ligne |
| Changements traités à temps | Part avant date d’effet | Gestion fournisseur | Le délai dépend de la qualité de notification |
Tester concentration, continuité et sortie
La cartographie révèle les concentrations invisibles : plusieurs applications utilisent la même passerelle, plusieurs fournisseurs reposent sur le même cloud ou un seul outil conserve les traces indispensables. La diversification apparente des modèles ne protège pas si tous dépendent d’un même intermédiaire.
Pour les services soutenant une fonction critique ou importante, la stratégie de sortie doit être documentée et testée selon le cadre applicable. Elle précise les données à récupérer, les formats, les configurations, les connaissances, les délais, les coûts et les responsables. La méthode de réversibilité d’un fournisseur IA propose un exercice concret : reconstruire un service minimal sans dépendre de la coopération improvisée du fournisseur sortant.
Un test de sortie ne nécessite pas toujours une migration complète. Il peut vérifier l’export, le redéploiement d’un jeu de sondes, la rotation des secrets, la bascule d’une route et le fonctionnement du mode dégradé. Les résultats doivent déclarer les limites : volume partiel, fonctions non migrées, délai simulé ou coût estimé.
La décision de concentration distingue fait et scénario. « Trois services déclarent le même cloud » est un fait du registre. « Une panne régionale les indisponibiliserait simultanément » est une hypothèse à tester avec l’architecture et les engagements. « Migrer le composant X » est une recommandation soumise à coût, risque et faisabilité.
Plan de mise en œuvre en douze étapes
- Qualifier le périmètre : entités, exclusions, niveaux de consolidation et propriétaires.
- Importer le modèle : utiliser les modèles officiels en vigueur et leur taxonomie.
- Créer les identifiants : entités, fonctions, accords, services et fournisseurs.
- Rapprocher les sources : achats, juridique, comptes, architecture, sécurité et registre IA.
- Décomposer les services IA : application, routage, modèles, données, observabilité et support.
- Tracer la chaîne : prestataires directs, sous-traitants pertinents, lieux et preuves datées.
- Relier les fonctions : finalité métier, criticité ou importance, volumes et mode dégradé.
- Compléter les contrats : droits d’audit, incidents, changements, accès, coopération et sortie selon le cas.
- Contrôler les données : règles structurelles et rapprochements de cohérence.
- Faire confirmer : attestations de propriétaires fonctionnels, techniques et contractuels.
- Tester un événement : changement de sous-traitant, incident ou sortie sur un service prioritaire.
- Organiser la mise à jour : événements, fréquence, preuve et gouvernance des écarts.
Le résultat attendu n’est pas seulement un fichier déposable. C’est la capacité de répondre rapidement : quelles fonctions seraient affectées si ce fournisseur ou sous-traitant changeait ? Quels contrats, données et responsables sont concernés ? Quelle solution de continuité a été testée ? Quelles lignes du registre doivent être mises à jour ?
Cette capacité demande un modèle de données stable et une responsabilité distribuée. Le propriétaire central maintient la cohérence ; les métiers, la technique et les achats maintiennent leur vérité. Un registre central alimenté par personne devient obsolète. Des inventaires locaux sans modèle commun deviennent impossibles à consolider.
Sources officielles
- EUR-Lex — règlement (UE) 2022/2554 sur la résilience opérationnelle numérique, notamment articles 2 et 28 à 30.
- EUR-Lex — règlement d’exécution (UE) 2024/2956, modèles normalisés pour le registre d’informations.
- EIOPA — Digital Operational Resilience Act (DORA), espace officiel comprenant la rubrique et les ressources du registre d’informations.
- EIOPA Q&A DORA149-3210, réponse officielle relative aux sous-traitants à inclure dans le registre d’informations.
Faire du registre DORA un outil de décision
Un atelier de reconstruction sur un service IA prioritaire permet de tester les identifiants, la chaîne, la fonction, les preuves et le scénario de sortie avant d’étendre la méthode. Échangeons sur votre cartographie des prestataires IA.
