DORA 2025 : pourquoi votre IA doit rester dans votre infrastructure
DORA est entré en vigueur. Depuis janvier 2025, les établissements de crédit, compagnies d'assurance, sociétés de gestion, et l'ensemble des entités financières supervisées dans l'Union européenne sont soumis au Digital Operational Resilience Act. Les équipes de conformité ont passé deux ans à interpréter ses exigences. Aujourd'hui, la question n'est plus théorique : un système d'IA souveraine déployé en mode cloud standard satisfait-il aux obligations que DORA impose sur la gestion du risque tiers ICT ?
La réponse, pour la grande majorité des architectures cloud actuelles, est non. Pas en raison d'une lacune technique ou d'un manque de bonne volonté des fournisseurs, mais parce que DORA a été conçu précisément pour corriger les vulnérabilités structurelles que le recours massif aux grands cloud providers américains crée dans le système financier européen.
Ce que DORA impose concrètement
DORA impose aux entités financières de gérer leur risque de concentration vis-à-vis des prestataires ICT tiers. L'article 28 exige une politique formalisée de gestion des tiers ICT critiques. L'article 29 impose une surveillance continue de ces prestataires. L'article 30 définit les clauses contractuelles minimales que doivent contenir les contrats avec des prestataires ICT jugés critiques.
Pour l'IA déployée en mode cloud, trois exigences ont des implications directes sur le choix architectural :
L'auditabilité. DORA exige que les entités financières puissent auditer leurs prestataires ICT critiques — soit directement, soit via des tiers habilités. Pour un système d'IA cloud, cela signifie avoir la capacité de vérifier, au niveau du prestataire, comment les données sont traitées lors de l'inférence, où elles sont stockées, et qui peut y accéder. La plupart des grands fournisseurs cloud ne permettent pas ce niveau d'audit pour leurs services d'IA.
La résilience. DORA impose des exigences de continuité opérationnelle qui s'appliquent aux systèmes ICT critiques. Un système d'IA dont le fonctionnement dépend d'une API externe crée une dépendance opérationnelle sur un tiers dont vous ne contrôlez pas la disponibilité. Si l'API d'un fournisseur cloud connaît une interruption, votre capacité opérationnelle est affectée — et c'est DORA qui vous demande de documenter et de maîtriser ce risque.
Le risque de concentration. DORA cible explicitement le risque systémique que crée la concentration de services critiques chez un petit nombre de fournisseurs. Si votre IA, votre infrastructure cloud principale, et vos outils de collaboration reposent tous sur le même fournisseur américain, vous êtes exposé à un risque de concentration que les équipes de conformité DORA doivent désormais documenter et justifier.
Le problème du cloud standard
Les architectures d'IA en mode cloud standard — qu'il s'agisse d'appels API directs à des services d'IA publics ou de déploiements sur des cloud providers de premier plan — présentent des caractéristiques structurelles incompatibles avec les exigences DORA les plus strictes.
Premièrement, les données quittent votre périmètre lors de chaque inférence. Chaque requête adressée à un système d'IA cloud envoie des données — le contenu de la requête, les documents récupérés pour y répondre — vers l'infrastructure d'un tiers. DORA exige que vous identifiiez, qualifiiez, et contractualisiez ce flux. C'est faisable en théorie. En pratique, pour des systèmes d'IA utilisés intensivement par des équipes opérationnelles, cela représente des milliers de transferts de données par jour, chacun potentiellement concerné par les obligations DORA.
Deuxièmement, les droits d'audit sont limités. Les grands cloud providers permettent des audits dans un cadre défini — typiquement, des audits de conformité standardisés (ISO 27001, SOC 2) réalisés par des tiers accrédités, avec publication d'un rapport de synthèse. Ils n'accordent généralement pas aux clients un accès direct aux systèmes pour réaliser leurs propres audits. DORA exige des droits d'accès complets, y compris la possibilité d'effectuer des tests de pénétration et des audits sur site. Cette exigence est en tension directe avec les conditions de service des grands providers cloud.
Troisièmement, les plans de sortie posent problème. DORA exige que les entités financières maintiennent des plans de sortie documentés pour chaque prestataire ICT critique. Pour un système d'IA cloud dont toute la base documentaire est indexée dans l'infrastructure d'un fournisseur, la portabilité des données — notamment des représentations vectorielles et des index documentaires — n'est pas garantie. La sortie peut être techniquement complexe et opérationnellement coûteuse.
Le CLOUD Act : le risque résiduel que l'hébergement européen ne suffit pas à couvrir
La réponse habituelle des équipes ICT face aux préoccupations de souveraineté est de spécifier un hébergement en région européenne. C'est une condition nécessaire, mais insuffisante, lorsque le fournisseur est une entreprise soumise au droit américain.
Le Clarifying Lawful Overseas Use of Data Act (CLOUD Act), adopté en 2018 aux États-Unis, autorise les autorités américaines à exiger d'une entreprise de droit américain la production de données stockées à l'étranger, y compris en Europe, dans le cadre d'enquêtes légales. Cette obligation s'applique indépendamment de la localisation physique des serveurs.
En pratique, cela signifie qu'un système d'IA hébergé dans un datacenter en France ou en Allemagne par un fournisseur américain reste potentiellement accessible aux autorités américaines. Pour des données financières sensibles, des analyses stratégiques, ou des communications soumises au secret professionnel, cette exposition résiduelle n'est pas acceptable dans un cadre DORA ou NIS2 strict. Comme l'analyse l'article sur la sécurité des IA d'entreprise, la conformité contractuelle ne garantit pas la protection architecturale — et c'est la distinction que les juristes spécialisés en droit des données soulignent aujourd'hui systématiquement.
Le Conseil d'État français et la CNIL ont tous deux exprimé des préoccupations relatives au CLOUD Act dans le contexte de l'utilisation de services cloud américains pour des données sensibles. Pour les données soumises à un secret légal ou réglementaire, l'hébergement européen chez un fournisseur américain ne constitue pas une garantie de souveraineté au sens où DORA et NIS2 l'entendent.
Le cas pour l'IA on-premise dans le secteur financier
L'alternative architecturale qui répond structurellement aux exigences DORA est le déploiement on-premise ou en infrastructure privée isolée. Cette approche résout les trois problèmes identifiés ci-dessus.
L'auditabilité est complète. L'ensemble du pipeline — indexation des documents, génération des représentations sémantiques, recherche, reranking cross-encoder, génération des réponses — s'exécute sur votre infrastructure. Vous pouvez auditer chaque composant, tester chaque couche de sécurité, et produire des logs d'audit complets sans dépendre de la coopération d'un tiers. La piste d'audit que DORA exige est disponible parce qu'elle est produite par des systèmes que vous opérez directement.
La résilience est maîtrisée. Un système d'IA on-premise n'a pas de dépendance externe lors de l'inférence. Sa disponibilité est déterminée par votre propre infrastructure, sous vos propres plans de continuité. Les plans de sortie DORA sont simples : les données restent dans votre infrastructure, les index sont portables parce qu'ils sont dans vos systèmes.
Le risque de concentration est éliminé. Un déploiement on-premise sans dépendance à des API de fournisseurs cloud tiers supprime la contribution de l'IA au risque de concentration que DORA vous demande de gérer. L'IA devient un composant de votre infrastructure propre, sujet aux mêmes contrôles que vos autres systèmes critiques.
L'argument qui s'opposait historiquement au déploiement on-premise — la supériorité des modèles cloud sur les modèles exécutables localement — est en train de s'éroder. L'écosystème des modèles open-weight a évolué au point que les capacités disponibles en infrastructure privée sont suffisantes pour la grande majorité des cas d'usage d'entreprise. Comme le détaille l'article sur le déploiement IA en mode air-gap, la question n'est plus "peut-on obtenir une qualité suffisante en on-premise?" mais "le gain marginal des services cloud justifie-t-il l'exposition réglementaire et le risque de concentration que DORA vous demande désormais de gérer ?"
Pour les établissements financiers, les assureurs, et les entités soumises à DORA, cette question a une réponse de plus en plus claire. L'IA souveraine — déployée sur votre infrastructure, sans dépendance à des API externes, avec une piste d'audit complète sous votre contrôle — n'est plus un luxe de RSSI prudents. C'est l'architecture que la réglementation rend nécessaire. Scabera est conçu pour s'intégrer dans une infrastructure privée sans appel à des API cloud externes lors de l'inférence, et pour produire des réponses citées et auditables qui répondent directement aux exigences d'explicabilité que les superviseurs financiers commencent à formaliser.
Pour voir comment Scabera aborde le déploiement d'IA souveraine pour les établissements financiers soumis à DORA, demandez une démonstration.