Assureurs : en 2027, il ne suffira plus d’être conforme. Il faudra pouvoir le prouver.

Trois réglementations, un même changement de nature

Les directions risques et conformité des assureurs n'ont pas attendu 2026 pour vivre avec la réglementation. Solvabilité II, les exigences de l'ACPR, les obligations de contrôle interne ou les règles relatives à l'externalisation font depuis longtemps partie du paysage.

Ce qui arrive est pourtant différent.

Sur une fenêtre particulièrement courte se superposent la révision de Solvabilité II, la mise sous supervision effective de DORA et la montée en puissance des obligations relatives à l'intelligence artificielle. Ce n'est pas nécessairement l'ampleur de chacun de ces textes qui constitue la difficulté. 

C'est leur simultanéité et, surtout, ce qu'ils ont en commun : ils déplacent progressivement l'exigence réglementaire de la documentation vers la preuve.

• Une politique existe ? Très bien.

• Un contrôle est décrit ? Très bien.

• Une responsabilité est attribuée ? Très bien.

Mais le superviseur, l'auditeur ou demain l'organisme chargé de vérifier certains éléments du dispositif posera une question supplémentaire : montrez-moi.

Montrez-moi que le contrôle a été exécuté. Quand. Par qui. Sur quelles données. Avec quel résultat. Qui a revu l'anomalie. Quelle décision a été prise. Et ce qui s'est passé lorsque le contrôle n'a pas fonctionné.

C'est une différence considérable.

Solvabilité II : quand la cohérence devient auditable

La révision de Solvabilité II illustre parfaitement ce déplacement.

Avec l'audit du bilan prudentiel, la chaîne qui relie gouvernance, ORSA, reporting réglementaire et données sources devient beaucoup plus directement exposée à une revue externe.

Et cette revue risque de révéler moins des absences de procédures que des ruptures dans la chaîne de preuve.

Un retraitement manuel dont personne n'a conservé l'origine. Un contrôle actuariel parfaitement réel, mais insuffisamment formalisé. Une donnée critique dont la responsabilité est diffuse. Une documentation reconstruite au moment de l'audit. Un écart entre ce que raconte l'ORSA et les décisions effectivement prises.

Beaucoup d'organisations savent aujourd'hui expliquer leur dispositif.

La question de 2027 sera : peuvent-elles le démontrer de bout en bout ?

DORA : un contrat n'est pas un contrôle

Le même raisonnement vaut pour le risque informatique.

DORA fait entrer très explicitement le risque TIC et le risque tiers dans la gouvernance. Gestion des incidents, cadre de gestion du risque TIC, contrats avec les prestataires, tests de résilience, registre d'information : le dispositif doit fonctionner dans la réalité, et pas seulement exister sur le papier.

Prenons un exemple très simple : le droit d'audit d'un prestataire.

On peut avoir négocié une excellente clause contractuelle. Mais si elle n'a jamais été exercée, si aucun rapport d'assurance n'a été analysé, si les contrôles restant à la charge de l'assureur ne sont pas identifiés et si la stratégie de sortie n'a jamais été testée, la clause démontre essentiellement qu'on avait pensé au problème.

Elle ne démontre pas qu'on le maîtrise.

Et plus la chaîne s'allonge — délégataire, éditeur SaaS, cloud, sous-traitants — plus cette distinction devient importante.

L'IA va rendre cette question encore plus inconfortable

L'intelligence artificielle ajoute une difficulté supplémentaire : une partie croissante du dispositif de décision peut être située chez un tiers.

Un assureur peut utiliser un score, un moteur de détection de fraude, une fonction de souscription ou un modèle fourni par un éditeur sans avoir construit lui-même l'algorithme.

Cela ne fait pas disparaître la responsabilité de gouvernance.

Les exigences qui montent portent précisément sur la gestion des risques, les données, la documentation, la journalisation, la transparence et la surveillance humaine. Le document souligne également la superposition des exigences horizontales de l'AI Act et des attentes sectorielles du superviseur.

La question devient alors redoutablement concrète.

Comment prouver une décision dont une partie du raisonnement a été produite par un système que l'on n'a pas construit ?

C'est probablement l'un des prochains grands sujets du contrôle interne.

Le problème n'appartient donc plus à une seule fonction

On pourrait confier Solvabilité II à la direction des risques, DORA à la DSI, l'AI Act à la conformité et le bilan prudentiel à la finance.

Ce serait précisément manquer le sujet.

Car la preuve traverse les fonctions.

La direction financière doit fiabiliser la chaîne produisant les chiffres. Les risques doivent relier ORSA, risque TIC, risque tiers et désormais modèles. La conformité doit maîtriser les usages d'IA et les décisions automatisées. L'audit interne doit pouvoir tester tout cela, y compris lorsque les compétences nécessaires sont technologiques ou liées aux données.

Autrement dit, on ne peut plus avoir quatre dispositifs de contrôle qui se rencontrent une fois par an dans un PowerPoint.

Ils doivent partager quelque chose.

Ce quelque chose, c'est un socle de preuve

Ce n'est pas nécessairement un nouvel outil.

C'est d'abord une architecture commune du contrôle :

un risque identifiable de la même manière par les différentes fonctions ; un contrôle associé à ce risque ; un responsable ; une fréquence ; les données sur lesquelles il s'exécute ; une preuve conservée ; les anomalies détectées ; leur traitement ; et des indicateurs permettant de savoir si le dispositif fonctionne réellement.

Le document résume ce socle autour d'un référentiel de contrôles unique, de preuves horodatées et conservées, d'une traçabilité des décisions et d'indicateurs communs de couverture et d'efficacité.

C'est là que la GRC change de nature.

Pendant longtemps, beaucoup de projets GRC ont consisté à mettre la documentation du contrôle dans un outil.

La prochaine génération devra permettre de mettre la preuve dans le contrôle.

La nuance paraît mince. Elle change presque tout.

Faites le test avec dix contrôles

Il existe un moyen assez simple d'évaluer où en est une organisation.

Choisissez dix contrôles critiques au hasard.

Et demandez qu'on vous fournisse leur dernière exécution complète : donnée source, horodatage, responsable, résultat, éventuelle anomalie, revue et action corrective.

Puis chronométrez.

Si les éléments arrivent immédiatement et sont cohérents, le dispositif est probablement déjà largement démontrable.

S'il faut appeler quatre personnes, rechercher trois tableurs, reconstituer des captures d'écran et demander à quelqu'un ce qu'il avait fait ce jour-là, le contrôle existe peut-être.

Mais sa preuve n'existe pas encore réellement.

C'est d'ailleurs l'une des questions de maturité proposées dans notre travail : combien de temps faut-il pour produire la preuve d'exécution de dix contrôles critiques ? La grille distingue cinq stades : absent, déclaratif, formalisé, testé et enfin démontré — lorsque la preuve peut être produite à la demande et pilotée par des indicateurs.

2026 est donc moins une année de conformité qu'une année de répétition générale

La tentation serait de traiter chaque échéance réglementaire comme un projet séparé.

Nous pensons qu'il faut faire l'inverse.

Prendre quelques processus critiques. Identifier les exigences qui vont converger sur eux. Exécuter réellement les contrôles. Produire les preuves. Tester leur récupération. Identifier les ruptures entre les données, les équipes, les prestataires et les systèmes.

Puis recommencer.

Parce qu'une inspection ne cherche finalement pas à savoir si une organisation avait de bonnes intentions lorsqu'elle a rédigé sa politique.

Elle cherche à savoir ce qui s'est réellement passé.

Le programme de travail présenté dans le document converge d'ailleurs vers six objets très opérationnels : externalisation, risques TIC, usages de l'IA, valeur pour le client, efficacité des fonctions clés et qualité/cohérence des données.

2026 est l'année où il faut apprendre à produire la preuve.
2027 sera celle où l'on commencera sérieusement à la demander.