Claude en banque et assurance : ce que change un secteur régulé

Dans la plupart des entreprises, un projet d’IA démarre par un cas d’usage : automatiser une tâche, gagner du temps sur un processus. Dans la banque et l’assurance, il démarre ailleurs — par la question du régulateur. Avant même de choisir un premier périmètre, la DSI et la conformité veulent savoir ce qui est auditable, ce qui reste sous contrôle humain, et ce qui peut, ou non, quitter le système d’information. Ce n’est pas de la prudence excessive : c’est la structure même du secteur, et elle change la manière dont un projet Claude doit être cadré dès le premier jour.

Le secteur financier n’a pas besoin d’un discours différent sur l’IA. Il a besoin que l’architecture réponde, avant l’usage, aux questions que le régulateur posera de toute façon.

Un secteur qui commence par la conformité, pas par l’usage

Banques et assureurs opèrent sous la supervision de l’ACPR et, pour les activités de marché, de l’AMF, avec des exigences de gestion du risque qui s’étendent désormais explicitement aux outils numériques. Depuis janvier 2025, le règlement européen DORA (résilience opérationnelle numérique) impose aux entités financières un cadre formel de gestion des risques liés aux prestataires technologiques tiers — dont, de fait, les fournisseurs de modèles d’IA utilisés dans des processus métier.

Concrètement, cela signifie qu’un projet Claude dans ce secteur ne peut pas rester une initiative isolée d’une direction métier. Il doit pouvoir répondre, dès le départ, à des questions simples et précises : quelles données sont envoyées, où sont-elles traitées, qui peut consulter les échanges, et comment une décision assistée par l’IA peut-elle être reconstituée a posteriori si un auditeur le demande.

Trois contraintes structurantes

Ces contraintes ne sont pas spécifiques à Claude — elles s’appliquent à tout outil numérique dans le secteur. Mais elles doivent être résolues dans l’architecture avant le premier déploiement, pas ajoutées après coup :

• Traçabilité : chaque réponse générée doit pouvoir être reliée à ses sources et, si elle influence une décision, laisser une trace exploitable en cas de contrôle.
• Périmètre de données : ce que l’IA peut consulter doit être défini processus par processus (dossier client, référentiel produit, documentation réglementaire), jamais laissé ouvert par défaut.
• Validation humaine sur les décisions engageantes : octroi de crédit, indemnisation d’un sinistre, conseil réglementé — l’IA prépare et documente, un humain habilité tranche.

Ce que Claude apporte structurellement à ce cadre

Claude Enterprise propose une console d’administration, du SSO et des contrôles de rétention indépendants de tout éditeur bureautique — un point qui compte pour des DSI bancaires souvent multi-systèmes plutôt qu’ancrées sur un unique écosystème. Le protocole MCP (Model Context Protocol) permet de connecter Claude à des sources internes de façon contrôlée : un assistant peut être limité au référentiel produit assurance, sans accès au dossier client complet, par exemple. Et la fenêtre de contexte de 200 000 tokens permet de traiter un contrat, une police d’assurance ou un rapport réglementaire long en une seule requête, avec les sources visibles dans la réponse plutôt que dans un système opaque.

Rien de tout cela ne remplace la gouvernance du secteur. Cela donne simplement les briques pour la respecter : sources citées par construction, périmètres définis dans l’architecture plutôt que dans une charte d’usage, et un point de contrôle humain placé exactement là où le coût d’une erreur est le plus élevé.

Cas d’usage typiques, sans franchir la ligne rouge

Les déploiements qui fonctionnent dans ce secteur partagent un point commun : ils commencent par des tâches à forte volumétrie documentaire et à faible risque de décision engageante, avant d’aborder les processus qui touchent directement le client ou le contrat.

• Synthèse de veille réglementaire (évolutions ACPR, AMF, DORA) à partir de sources internes, avec citation systématique.
• Rédaction assistée de premiers jets de courriers ou de réponses client, relus avant envoi.
• Support à l’analyse de dossiers de souscription ou de sinistres : l’IA structure et signale, un gestionnaire habilité décide.
• Recherche documentaire dans des contrats ou procédures internes longues, avec passages sourcés plutôt qu’un résumé libre.

Le point de départ concret

Le bon premier projet dans ce secteur n’est presque jamais le plus visible ni le plus ambitieux. C’est celui qui permet à la conformité, à la sécurité et au métier de voir, sur un périmètre restreint, que le dispositif tient ses promesses : sources visibles, données cantonnées, contrôle humain là où il compte. Une fois ce premier périmètre validé et audité, l’extension à d’autres processus se négocie beaucoup plus vite — parce que la question n’est plus « est-ce que ça marche » mais « où l’étend-on ensuite ». C’est le chantier que couvre le Programme Autonomie Claude quand l’architecture doit être pensée pour un secteur régulé dès le premier jour, plutôt que corrigée après coup.