Plan de sortie DORA (Article 28.8) : documenter la réversibilité d'un système d'IA vers l'on-premise pour l'ACPR et la BCE
Dans le secteur financier européen, l’entrée en application du règlement DORA (Digital Operational Resilience Act - Règlement UE 2022/2554) a radicalement transformé la gestion des risques technologiques. L’Autorité de Contrôle Prudentiel et de Résolution (ACPR) et la Banque Centrale Européenne (BCE) ne se contentent plus de déclarations d’intention : elles exigent des preuves matérielles de résilience.
L’article 28, paragraphe 8 du règlement DORA pose une obligation impérative qui met en difficulté la majorité des institutions financières :
“Les entités financières doivent veiller à pouvoir résilier les accords contractuels sans que cette résiliation n’entrave la continuité et la qualité de leurs services financiers (…). À cette fin, elles mettent en place des stratégies de sortie globales prévoyant des plans de sortie complets, documentés et suffisamment testés.”
Si votre banque ou votre établissement de paiement s’appuie sur une API d’intelligence artificielle hébergée chez un hyperscaler américain (OpenAI, Microsoft Azure, AWS Bedrock ou Google Cloud Vertex AI) pour instruire des crédits, analyser des transactions ou détecter la fraude, l’absence d’un plan de bascule éprouvé vers une infrastructure locale constitue un motif de non-conformité majeure passible de sanctions financières directes.
Ce dossier détaille comment formaliser votre dossier de réversibilité IA, documenter les tests de bascule et intégrer l’architecture souveraine Yevi Core v1.0 comme solution de secours opposable aux régulateurs.
flowchart TD A[Système IA en Production Bancaire] --> B{Déclencheur Plan de Sortie DORA} B -->|Défaillance Prestataire / Sanction / Rupture Contrat| C[Activation Procédure de Réversibilité Art. 28.8] C --> D[1. Rapatriement Instantané des Embeddings & Vectorstores] C --> E[2. Bascule du Trafic Inférence vers vLLM On-Premise] C --> F[3. Isolation Réseau Totale en Enclave Air-Gapped] D & E & F --> G[Reprise d'Activité < 2 Heures : RTO Garanti] G --> H[Rapport d'Audit Soumis à l'ACPR / BCE]
style B fill:#f87171,stroke:#b91c1c,color:#fff style C fill:#f59e0b,stroke:#b45309,color:#fff style G fill:#10b981,stroke:#047857,color:#fff1. Les 4 causes de déclenchement d’un plan de sortie imposées par DORA
Section intitulée « 1. Les 4 causes de déclenchement d’un plan de sortie imposées par DORA »L’ACPR et l’Autorité Européenne des Marchés Financiers (ESMA) exigent que le plan de sortie détaille précisément les événements déclencheurs (Triggers) :
1. La défaillance opérationnelle prolongée du tiers (RTO & RPO)
Section intitulée « 1. La défaillance opérationnelle prolongée du tiers (RTO & RPO) »Une panne d’infrastructure de plus de 4 heures chez l’éditeur cloud ou une rupture de connectivité transatlantique ne peut pas paralyser l’octroi de crédits ou le filtrage des transactions. Votre Objectif de Temps de Récupération (RTO - Recovery Time Objective) doit être inférieur à 2 heures.
2. La modification substantielle des conditions contractuelles ou tarifaires
Section intitulée « 2. La modification substantielle des conditions contractuelles ou tarifaires »Une hausse unilatérale des coûts de l’API de +50 %, une modification des conditions de rétention des données ou un changement de juridiction applicable imposé par le fournisseur cloud légitime la rupture immédiate sans pénalité.
3. La mise en péril de la conformité juridique (CLOUD Act & FISA 702)
Section intitulée « 3. La mise en péril de la conformité juridique (CLOUD Act & FISA 702) »Une injonction d’une juridiction étrangère ordonnant la communication de données financières protégées par le secret bancaire impose la suspension sans délai du sous-traitant (analyser les conflits légaux liés au CLOUD Act).
4. La faillite ou le rachat de l’éditeur par un tiers non conforme
Section intitulée « 4. La faillite ou le rachat de l’éditeur par un tiers non conforme »L’absorption du prestataire par une entité sous embargo ou non autorisée par les autorités bancaires de l’Union.
2. Le piège du verrouillage technologique (Vendor Lock-in)
Section intitulée « 2. Le piège du verrouillage technologique (Vendor Lock-in) »Pour que l’ACPR valide votre dossier d’homologation DORA, vous devez démontrer que votre code applicatif n’est pas “prisonnier” d’une technologie propriétaire.
Les points de blocage fréquemment sanctionnés par les régulateurs :
- L’usage d’embeddings fermés (ex:
text-embedding-ada-002) dont les poids ne sont pas téléchargeables. Si vous devez quitter le fournisseur, vous devez réindexer toute votre base documentaire, ce qui prend plusieurs semaines. - Les fonctions de recherche vectorielle propriétaires intégrées aux clouds managés (Azure AI Search, AWS OpenSearch Serverless).
- Les formats de prompts non portables exploitant des balises spécifiques à un seul modèle commercial.
La solution : le socle ouvert Yevi Core v1.0
Section intitulée « La solution : le socle ouvert Yevi Core v1.0 »En adoptant Yevi Core v1.0 (Licence MIT), vous éliminez tout verrouillage :
- Embeddings ouverts et pérennes : Modèles multilingues BAAI/bge-m3 ou Nomic téléchargeables et exécutables localement en local-first.
- Base vectorielle portable : ChromaDB ou Qdrant déployable indifféremment sur votre serveur interne ou en conteneur sécurisé.
- Standard d’API universel : Spécification d’API compatible
/v1/chat/completions, permettant de basculer d’une source à une autre en changeant une simple variable d’environnement (voir notre guide de migration cloud).
3. Matrice documentaire exigée par les auditeurs ACPR / BCE
Section intitulée « 3. Matrice documentaire exigée par les auditeurs ACPR / BCE »Votre classeur d’audit DORA doit contenir les 5 sections suivantes :
[ DOSSIER DE RÉVERSIBILITÉ DORA - VOLET IA (ART. 28.8) ]├── Section 1 : Cartographie des flux et inventaire des modèles déployés├── Section 2 : Analyse d'impact des scénarios de rupture (BIA)├── Section 3 : Procédure opérationnelle de bascule (Runbook de secours)├── Section 4 : Procès-verbaux des exercices de test annuels à blanc└── Section 5 : Attestation de disponibilité de l'infrastructure de secours (BYOH)Extrait type de clause contractuelle de sortie à imposer à vos intégrateurs :
Section intitulée « Extrait type de clause contractuelle de sortie à imposer à vos intégrateurs : »“Le Titulaire s’engage irrévocablement à fournir à l’Établissement, sur simple demande écrite et sous un préavis maximal de quarante-huit (48) heures : 1. La restitution intégrale, sous format ouvert standard (Parquet / JSONL chiffré AES-256), de l’ensemble des vecteurs, index et historiques de requêtes sans frais de transfert (zéro frais d’egress) ; 2. Les scripts d’exportation automatisée et les manifestes d’environnement Docker / Kubernetes permettant le redéploiement autonome de la solution sur l’infrastructure interne de l’Établissement (Mode On-Premise) ; 3. Une assistance technique renforcée sans surcoût pendant une période de transition de six (6) mois garantissant la stricte continuité d’activité.”
4. Protocole d’exercice de bascule à blanc (Disaster Recovery Test)
Section intitulée « 4. Protocole d’exercice de bascule à blanc (Disaster Recovery Test) »DORA ne tolère aucun plan de secours purement théorique. Vous devez mener au moins un exercice annuel de simulation de panne totale et en consigner les résultats dans un registre d’audit.
Scénario de test recommandé pour les banques :
Section intitulée « Scénario de test recommandé pour les banques : »- T0 (09h00) : Coupure simulée de l’accès réseau externe vers l’API cloud au niveau du pare-feu périmétrique.
- T0 + 5 min : Détection de l’erreur HTTP 503 par le Health Check interne de la passerelle d’API.
- T0 + 12 min : Basculement automatique du routeur de charge vers l’instance de secours locale Yevi Core v1.0 hébergée sur vos serveurs internes (architecture matérielle on-premise).
- T0 + 20 min : Exécution d’un lot de 500 requêtes d’analyse de conformité AML et vérification de l’ancrage strict (
is_grounded: true). - T0 + 35 min : Clôture de l’exercice et génération du rapport de performance horodaté.
5. Comment Odoun AI sécurise votre homologation DORA
Section intitulée « 5. Comment Odoun AI sécurise votre homologation DORA »Pour accompagner les directions de la conformité, du risque opérationnel et les DSI bancaires :
- Architecture BYOH (Bring Your Own Host) : Nous déployons Yevi Core v1.0 directement sur votre baie serveurs existante au sein de votre réseau interne sans dépendance externe.
- Réversibilité Clé en Main : Nous rédigeons pour vous le chapitre technique du Plan de Sortie DORA opposable aux autorités de tutelle.
- Support MCO & Maintien en Conditions Opérationnelles : Assistance 24/7 et mises à jour de sécurité des modèles open-source durcis (découvrir nos prestations bancaires).
🛠️ Ressources & Documentation Prudentielle
Section intitulée « 🛠️ Ressources & Documentation Prudentielle »Réservez votre audit de souveraineté
30 minutes pour évaluer votre exposition aux fuites de données vers des API externes.
Réserver mon audit gratuit