Registre des systèmes IA : le modèle opérationnel pour l’assurance

Un tableur intitulé « inventaire IA » peut contenir cent noms de modèles et rester inutilisable. Il ne dira pas qu’un même modèle prépare un e-mail sans effet dans un service, mais propose une décision engageante dans un autre. Il ne montrera pas que l’outil a changé de fournisseur, qu’une population nouvelle est entrée dans le périmètre ou qu’un connecteur peut désormais écrire dans le SI.

Le registre utile répond à une question de direction : quels systèmes contribuent à quelles décisions, qui en répond, sur quelles données, avec quels contrôles et quelle preuve de retrait ? Cette cartographie soutient la gestion des risques, les achats, la sécurité, la conformité, l’audit et l’exploitation. Elle ne remplace aucun de ces dispositifs et ne constitue pas, à elle seule, une mise en conformité.

Choisir la bonne unité : le système en contexte

Le règlement (UE) 2024/1689 sur l’intelligence artificielle raisonne sur des rôles et des systèmes placés sur le marché, mis en service ou utilisés dans une finalité. Pour piloter les usages d’assurance, la ligne de registre doit donc dépasser le nom technique du modèle.

Un modèle produit une prédiction, une représentation ou une génération. Un outil l’expose dans une interface. Un système en contexte réunit le modèle, les données, les règles, les intégrations, les utilisateurs, les contrôles et l’action qui en résulte. C’est à ce dernier niveau que l’organisation peut évaluer l’impact.

Un fournisseur de bureautique peut, par exemple, activer la même fonction générative pour plusieurs équipes. Dans la communication, elle reformule un brouillon relu. Dans les sinistres, elle synthétise des pièces. Dans la souscription, elle prépare une appréciation de risque. Ces usages ne partagent ni la même finalité, ni les mêmes données, ni le même coût d’erreur. Ils peuvent partager une fiche composant ou fournisseur, mais nécessitent des fiches système ou cas d’usage distinctes.

Distinguer pilotage interne et registres réglementaires

Au 7 septembre 2026, le règlement sur l’IA est entré en vigueur le 1er août 2024 et son régime s’applique selon un calendrier échelonné. La Commission européenne tient une présentation officielle du calendrier d’application, mise à jour avec les étapes et exceptions. Certaines obligations — par exemple celles relatives aux pratiques interdites, à la culture IA, aux modèles d’IA à usage général ou à la transparence de l’article 50 — ont leurs propres dates. Les règles concernant les systèmes à haut risque suivent également le calendrier officiel alors en vigueur. Toute fiche réglementaire doit donc contenir une date de qualification et la source de droit utilisée.

Le règlement prévoit une base de données de l’Union pour certains systèmes à haut risque et des enregistrements par des acteurs déterminés, notamment dans ses articles 49 et 71. Cette base n’est pas synonyme du registre interne proposé ici. Elle répond à des conditions, des rôles et des champs légaux précis. À l’inverse, un registre de pilotage peut utilement couvrir des systèmes qui ne sont pas soumis à cet enregistrement européen, sans leur appliquer artificiellement toutes les obligations des systèmes à haut risque.

L’opinion de l’EIOPA du 6 août 2025, destinée aux autorités nationales de contrôle, expose pour son périmètre des attentes de haut niveau en matière de gouvernance et de gestion du risque IA. Elle précise qu’elle ne crée pas de nouvelles exigences et ne vise pas à étendre le champ du règlement IA. Elle met notamment l’accent sur une approche proportionnée, les responsabilités, la gouvernance des données, l’explicabilité, la supervision humaine, l’exactitude, la robustesse, la cybersécurité, la documentation et la tenue de dossiers.

Enfin, le règlement DORA demande aux entités financières de tenir un registre d’informations portant sur leurs accords contractuels d’utilisation de services TIC fournis par des prestataires tiers, selon son champ et ses modalités. Ce registre contractuel n’est pas un registre IA. Une application d’IA fournie par un tiers peut apparaître dans les deux, avec des identifiants reliés : le registre IA décrit l’usage et ses contrôles ; le registre DORA décrit la dépendance et l’accord TIC.

Tableau — Trois objets à ne pas confondre

Objet	Finalité	Périmètre	Lien recommandé
Registre interne des systèmes IA	Piloter les usages, risques, propriétaires, contrôles et changements	Défini par l’organisation selon son modèle de gouvernance	Identifiant système stable
Base européenne du règlement IA	Enregistrement et transparence pour les situations prévues par le texte	Systèmes et acteurs visés par les articles applicables	Référence d’enregistrement lorsque requise
Registre d’informations DORA	Cartographier les accords contractuels avec les prestataires de services TIC	Entités, services et contrats couverts par DORA	Identifiant contrat et prestataire

Pour situer les étapes applicables et les preuves attendues, le dossier AI Act au 2 août 2026 : feuille de route pour l’assurance fournit une lecture par rôle, système et horizon.

Le modèle de fiche : socle obligatoire en interne et enrichissements proportionnés

Les mots « obligatoire » et « facultatif » désignent ici le standard interne recommandé pour qu’une fiche soit exploitable, non une liste universelle d’obligations légales. Un champ peut devenir juridiquement requis dans un dossier particulier ; la matrice de conformité doit alors le relier au texte, au rôle et à la date applicables.

Champs du socle : aucune fiche active sans eux

Tableau — Socle opérationnel d’une fiche système IA

Bloc	Champs	Pourquoi ils commandent une action
Identité	Identifiant stable, nom, description, statut, date d’entrée, dernière revue	Retrouver et suivre la fiche sans dépendre d’un nom commercial
Finalité	Problème, processus, population, utilisateur, décision ou action assistée	Détecter une extension d’usage et évaluer l’impact réel
Propriété	Propriétaire métier, responsable technique, exploitation, risques/conformité associés	Attribuer décision, correction, surveillance et retrait
Rôle et qualification	Rôles possibles au sens des textes, niveau de risque, obligations de transparence, justification et date	Relier la qualification aux contrôles et échéances
Architecture	Modèles, versions, règles, outils, interfaces, hébergement, identités et capacité d’action	Mesurer le rayon d’action et l’impact d’un changement
Données	Sources, catégories, données personnelles ou particulières, destinataires, localisation, conservation et droits	Appliquer minimisation, accès, sécurité et obligations de protection
Tiers	Fournisseur, sous-traitants connus, contrat, niveau de service, dépendances, réversibilité et lien DORA	Traiter concentration, changement, audit et sortie
Risques	Impacts, mésusages prévisibles, populations affectées, sécurité, biais, erreur et criticité	Déterminer la profondeur des contrôles
Contrôles	Jeu d’évaluation, seuils, supervision humaine, abstention, journalisation, alertes, mode dégradé	Vérifier que les mesures existent et fonctionnent
Cycle de vie	Version approuvée, changements déclencheurs, prochaine revue, incidents, décision et preuve de retrait	Empêcher une validation éternelle d’un système qui évolue

Champs facultatifs ou conditionnels

Ajoutez selon la finalité et le risque : coût complet, latence, consommation, volume, langues, accessibilité, licences, propriété intellectuelle, tests environnementaux, métriques d’adoption, référence de l’analyse d’impact, enregistrement européen, information des personnes, mécanisme de recours, plan de surveillance post-déploiement ou dépendances de quatrième partie. Le registre pointe vers les dossiers détaillés ; il ne doit pas les recopier intégralement.

Certains champs structurés doivent accepter « inconnu » avec un propriétaire et une échéance, plutôt qu’une valeur supposée. D’autres doivent bloquer le passage à l’état actif : absence de finalité, de propriétaire, de périmètre de données ou de mécanisme de retrait. La liste de valeurs est versionnée et les changements conservent un historique.

Découvrir les usages visibles et cachés

Une campagne annuelle par questionnaire produit une photographie incomplète. La découverte combine des signaux réguliers, chacun avec ses limites :

• Achats et contrats. Ils voient les nouveaux fournisseurs, mais pas toujours l’IA ajoutée après signature à un produit existant.
• SSO, catalogue applicatif et gestion des identités. Ils montrent les accès gérés, mais pas les comptes individuels ni les fonctions embarquées.
• Registre DORA et cartographie des tiers. Ils identifient les services TIC contractuels, pas nécessairement chaque cas d’usage IA.
• Catalogues data et flux réseau. Ils révèlent des intégrations, mais demandent une interprétation et une base de contrôle adaptée.
• Dépenses et cartes professionnelles. Elles détectent certains abonnements locaux sans expliquer l’usage.
• Revues de processus et enquêtes métier. Elles captent les outils gratuits, tests locaux et usages non intégrés, à condition d’éviter une logique punitive qui pousserait à la dissimulation.
• Gestion des changements et incidents. Elle détecte qu’un système connu a acquis une nouvelle fonction, population ou capacité d’action.

Chaque signal crée une candidature, pas automatiquement un système actif. Une file de qualification vérifie s’il existe une composante IA, une finalité organisationnelle, un traitement de données ou une influence sur une décision. Les doublons sont rattachés à un même composant ou contrat sans effacer leurs contextes distincts.

La découverte doit aussi offrir un chemin simple de déclaration. Un manager qui teste une fonction de synthèse doit pouvoir enregistrer un usage en quelques minutes, recevoir un niveau de triage et savoir ce qui est permis pendant l’examen. Un formulaire de cinquante champs dès le signal initial encourage les contournements.

Qualifier, attribuer, revoir et retirer

1. Qualifier avec une équipe restreinte

Le métier décrit la finalité et l’action. L’IT identifie architecture et fournisseurs. La data décrit les sources. Sécurité, conformité, DPO et risques interviennent selon les signaux. La qualification sépare ce qui est avéré, ce qui est analysé et ce qui reste inconnu. Elle ne déduit pas le niveau juridique du mot « copilote » ou du type de modèle.

2. Attribuer la propriété avant l’activation

Le propriétaire métier accepte la finalité, les seuils et le risque résiduel dans sa délégation. Le responsable technique maintient versions, intégrations et disponibilité. L’exploitation surveille et exécute le mode dégradé. Les fonctions de deuxième ligne cadrent et contrôlent ; l’audit conserve son indépendance. Une ligne sans propriétaire ne doit pas passer en production.

3. Revoir par date et par événement

Une fréquence planifiée dépend du risque, mais elle ne suffit pas. Déclenchez une revue lors d’un changement de modèle, de fournisseur, de finalité, de population, de donnée, d’outil, de permission, de contrat, de doctrine ou après un incident. La revue peut maintenir, restreindre, replacer en mode silencieux ou retirer.

4. Fermer le cycle de vie

Le statut « retiré » exige une preuve : accès révoqués, connecteurs désactivés, tâches automatiques arrêtées, données exportées ou supprimées selon les règles, contrats traités, utilisateurs informés et mode de remplacement opérationnel. Les éléments nécessaires à l’audit sont conservés selon une durée justifiée. Une date saisie dans le tableur sans vérification ne retire pas le système.

La décision d’acheter, d’assembler ou de construire les couches techniques est traitée dans la grille de choix IA pour l’assurance. Le registre doit refléter cette architecture réelle, notamment les composants que l’organisation peut remplacer séparément.

Transformer le registre en file de décisions

Un registre devient opérationnel lorsque des règles simples créent du travail attribué :

Tableau — Exemples de déclencheurs de gouvernance

Signal	Action	Preuve de clôture
Propriétaire absent	Bloquer activation ou renouvellement	Acceptation nominative du rôle
Nouvelle capacité d’écriture	Réévaluer impact, permissions, supervision et tests	Architecture, jeu de recette et décision mis à jour
Version fournisseur modifiée	Rejouer non-régression et observer en silence si nécessaire	Résultats comparés et décision signée
Contrat critique proche de l’échéance	Tester sortie, export, alternative et continuité	Exercice de réversibilité documenté
Incident ou seuil dépassé	Restreindre, arrêter ou revenir au mode précédent	Cause, correction, tests et autorisation de reprise
Revue échue	Relancer le propriétaire puis escalader selon criticité	Revue achevée ou retrait confirmé

Le registre n’a pas besoin de devenir une application complexe au départ. Il a besoin d’identifiants stables, de champs contrôlés, d’un historique, de droits et d’un mécanisme de tâches. L’automatisation vient ensuite : rapprochement avec le SSO, alertes de changement fournisseur, contrôle des échéances et tableaux de bord. Toute détection automatique doit laisser une revue humaine, car un appel réseau ou une dépense ne prouve pas à lui seul un usage IA.

Deux scénarios hypothétiques d’assurance

Scénario 1 — Assistant de réponse aux assurés

Cette illustration est hypothétique. Un service client teste un assistant fourni dans une suite SaaS. La fiche composant contient fournisseur, modèle disponible, sous-traitants déclarés et contrat. La fiche système précise que l’assistant prépare un brouillon à partir du CRM, sans envoi automatique. Les données incluent identité, contrat et historique d’échanges ; l’accès est limité au dossier ouvert.

Une nouvelle version ajoute la possibilité d’envoyer le message. Ce changement ne relève pas d’une simple mise à jour logicielle : il modifie la capacité d’action. Le registre déclenche une revue des permissions, du contrôle humain, de la journalisation et du mode dégradé. Tant que la validation n’est pas close, la permission d’envoi reste désactivée. La capacité du système et son niveau de contrôle peuvent être documentés avec le cadre des trois niveaux d’automatisation d’une décision d’assurance.

Scénario 2 — Outil interne de préparation tarifaire

Cette seconde illustration est également hypothétique. Une équipe construit un système qui extrait des variables d’un dossier professionnel et propose un dossier de calcul à un moteur de règles. Le modèle d’extraction, le moteur déterministe et l’interface sont trois composants ; la fiche système décrit leur chaîne, le rôle du souscripteur et les sorties interdites.

Lorsqu’une nouvelle gamme est ajoutée, la population, les documents et la doctrine changent. La revue vérifie la qualification juridique à cette date, le jeu d’évaluation, les écarts par segment et la supervision. Si la qualité sur les nouveaux documents n’est pas démontrée, le registre limite le statut actif à l’ancienne gamme. Il évite ainsi qu’une validation d’un composant soit interprétée comme une autorisation universelle du système.

Mesurer la qualité du registre

Évitez le seul indicateur « nombre de lignes ». Suivez plutôt :

• la part des systèmes actifs avec finalité, propriétaire, données, qualification, contrôles et prochaine revue complets ;
• le délai entre détection et qualification, puis entre changement et décision ;
• les systèmes découverts après incident ou renouvellement, signe d’une couverture insuffisante ;
• les revues échues pondérées par criticité ;
• les liens cohérents avec achats, contrats, SSO, registre DORA et analyses de données ;
• la proportion de retraits assortis d’une preuve technique et organisationnelle ;
• les décisions réellement déclenchées : restrictions, tests, corrections, exercices de sortie.

Effectuez aussi un contrôle par échantillon : partez d’un processus métier et remontez vers le registre, puis partez d’une ligne et vérifiez le système sur le terrain. Cette double lecture révèle les usages absents et les fiches qui ne correspondent plus à la réalité.

Un registre fiable n’est jamais « terminé ». Il est suffisamment actuel pour orienter une décision, suffisamment proportionné pour être maintenu et suffisamment relié aux opérations pour détecter un changement. Sa réussite ne se mesure pas à la beauté de la cartographie, mais à la capacité de l’organisation à répondre rapidement : qui peut arrêter ce système, sur quelle preuve et avec quelle continuité ?

Sources et références

Références consultées le 7 septembre 2026. Les calendriers, lignes directrices et qualifications peuvent évoluer ; vérifier les textes et publications officielles applicables au moment de chaque revue. Cet article ne constitue pas un avis juridique.

• EUR-Lex — Règlement (UE) 2024/1689 sur l’intelligence artificielle.
• Commission européenne — AI Act, cadre et calendrier d’application.
• Commission européenne — Navigating the AI Act, questions-réponses sur les rôles, obligations et enregistrements.
• EIOPA — Opinion on Artificial Intelligence governance and risk management, 6 août 2025.
• EUR-Lex — Règlement (UE) 2022/2554 sur la résilience opérationnelle numérique du secteur financier (DORA).
• NIST — Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023.