MD · Souveraineté des Infrastructures · 2026
Module MD — Souveraineté Numérique
Contrôler
son socle
technique.
On-premise · Cloud · Edge · DORA Art. 28 · Plan de résilience
Droits fondamentaux n°1 & n°3 — ORBii Framework

"Choisir ses technologies et pouvoir changer : la souveraineté des infrastructures garantit que l'organisation garde la main sur son socle technique, peut le faire évoluer et peut en sortir sans dommage excessif."

Ce que couvre ce module

Cartographie des dépendances infrastructure, critères de décision cloud/on-premise/edge, DORA opérationnel, plan de résilience et stratégie de sortie.

Public cible

CIO, architectes d'entreprise, responsables infra & cloud, CISO, équipes résilience et continuité, CDO office.

Réglementation centrale

DORA Art. 28-30 (concentration TIC), NIS2 Art. 21 (mesures techniques), Data Act Art. 23-35 (portabilité), BCBS 239 (continuité).

Durée recommandée

½ journée (3h30) — 2 séquences théoriques + 1 atelier cartographie des dépendances.

ORBii.Academy — Souveraineté Numérique & IAMD · P.01
MD · Souveraineté des Infrastructures
Cartographie des dépendances

Anatomie d'une infrastructure souveraine.

La souveraineté des infrastructures repose sur la capacité à cartographier précisément les dépendances, à les classifier par criticité DORA, et à disposer d'une stratégie de continuité sans dépendance excessive à un tiers unique.

Tier 1 — On-premise

Infrastructure propre, datacenter interne ou co-localisé. Contrôle total. Investissement CAPEX élevé.

Usages : données critiques, clés de chiffrement, core banking, DORA-critique
Souveraineté max
Tier 2 — Cloud souverain

Cloud certifié SecNumCloud ou HDS, opérateur UE, sans exposition juridiction étrangère.

Usages : données confidentiel, plateformes data, workloads IA, applications métier
Souveraineté forte
Tier 3 — Cloud hyperscaler

Cloud public international. Agilité maximale. Exposition Cloud Act selon fournisseur. Risque concentration DORA.

Usages : données publiques/internes, dev/test, outils collaboratifs, non-critiques
Risque à gérer

Matrice de classification des workloads

WorkloadCriticité DORAClassification donnéesTier recommandéCertification requise
Core banking & paiements CritiqueCritiqueOn-premise / Tier 1PCI-DSS, ISO 27001
Plateforme data & reporting BCBS CritiqueCritiqueOn-premise ou SecNumCloudHDS si santé, ISO 27001
Systèmes IA haut risque (scoring) CritiqueConfidentielCloud souverain / Tier 1SecNumCloud ou équiv.
Détection de fraude & AML ImportantConfidentielCloud souverain UEISO 27001, SOC2
Analytics & BI internes StandardInterneCloud UE (hyperscaler)RGPD + DPA
Outils collaboratifs & productivité FaibleInterneCloud internationalPolitique sécurité interne
ORBii.Academy — Souveraineté Numérique & IAMD · P.02
MD · Souveraineté des Infrastructures
DORA — Risque de concentration

Le risque de concentration TIC — la menace systémique.

DORA introduit un nouveau concept : le risque de concentration TIC. Trop dépendre d'un seul fournisseur d'infrastructure crée un risque systémique pour le secteur financier dans son ensemble.

DORA Art. 28 — Obligations
  • Art. 28.2 : Identifier et évaluer régulièrement les risques de concentration sur les tiers prestataires TIC
  • Art. 28.3 : Clauses contractuelles minimales obligatoires incluant le droit d'audit, les indicateurs de performance, la réversibilité documentée
  • Art. 28.4 : Stratégie de sortie pour tous les prestataires TIC critiques, testée annuellement
  • Art. 28.8 : Notification à l'autorité compétente des concentrations systémiques identifiées
4 indicateurs de concentration à surveiller
% CA versé au fournisseur principal Seuil : < 40%
% systèmes critiques chez 1 fournisseur Seuil : < 30%
Délai de bascule estimé (plan de continuité) Seuil : < 72h
Nb de fournisseurs alternatifs qualifiés Seuil : ≥ 2
Le scénario "single point of failure" que DORA veut éviter

Si une entité financière héberge 100% de ses workloads critiques chez un seul fournisseur cloud, une panne, une violation de sécurité ou une mesure réglementaire (ex: suspension de licences) peut rendre l'entité incapable d'opérer. DORA considère que c'est un risque systémique, pas seulement opérationnel. L'ABE (Autorité Bancaire Européenne) peut désigner un fournisseur TIC comme "critique" et lui imposer des inspections directes.

ORBii.Academy — Souveraineté Numérique & IAMD · P.03
MD · Souveraineté des Infrastructures
Plan de résilience

Construire une infrastructure résiliente et souveraine.

La résilience opérationnelle numérique (DORA) et la souveraineté des infrastructures convergent : les deux exigent diversification, plan de sortie documenté et tests réguliers.

Étape 1 — Cartographier
  • Inventaire exhaustif des fournisseurs TIC
  • Classification par criticité DORA
  • Identification des single points of failure
  • Calcul des indicateurs de concentration
Étape 2 — Diversifier
  • Multi-cloud strategy sur les critiques
  • Fournisseur de continuité identifié pour chaque TIC critique
  • Contrats de réservation capacité en cas de bascule
  • Architecture de portabilité (containers, IaC)
Étape 3 — Tester
  • TLPT (Threat-Led Penetration Testing) DORA annuel
  • Test de bascule vers fournisseur de continuité
  • Exercice de sortie de contrat simulé
  • Rapport de résilience au COMEX et au régulateur

Stratégie de sortie documentée — exigences DORA Art. 28.4

ComposanteContenu obligatoireDélai de validation
Plan de migration documentéÉtapes, ressources requises, délai estimé, risques identifiésAvant signature contrat
Fournisseur de substitution qualifiéAu moins 1 alternatif testé et contractuellement disponibleDans les 6 mois
Portabilité technique assuréeFormat standard, API ouverte, export des données certifiéAvant déploiement en production
Test de bascule annuelSimulation de migration partielle avec rapport d'incidentAnnuel
RTO/RPO définisObjectifs de temps de reprise et de point de reprise par systèmeDans le contrat
ORBii.Academy — Souveraineté Numérique & IAMD · P.04
MD · Souveraineté des Infrastructures
Synthèse du module MD
Infrastructure
souveraine =
résilience certifiée.
01 — DORA IMPOSE LA DIVERSIFICATION

Le risque de concentration TIC n'est plus théorique : DORA Art. 28.8 impose de le déclarer au régulateur. Concentrer plus de 30% des systèmes critiques chez un seul fournisseur est désormais un risque réglementaire documenté.

02 — TROIS TIERS, TROIS NIVEAUX

On-premise pour le critique, cloud souverain pour le confidentiel, hyperscaler pour le reste. Cette segmentation n'est pas idéologique — c'est la réponse pragmatique aux exigences combinées de DORA, RGPD et EU AI Act.

03 — LA STRATÉGIE DE SORTIE EST OBLIGATOIRE

DORA Art. 28.4 : pas de contrat TIC critique sans stratégie de sortie documentée et testée. Cette clause doit être rédigée avant la signature, pas après une crise.

04 — 3 LIVRABLES DU MODULE

① Inventaire TIC classifié DORA (criticité + indicateurs concentration) ② Plan de résilience 3 tiers avec RTO/RPO ③ Template stratégie de sortie conforme DORA Art. 28.4 pour contrats TIC critiques.

"Une infrastructure dont on ne peut pas sortir sans dommage excessif n'est pas une infrastructure choisie — c'est une infrastructure subie."

ORBii.Academy — Souveraineté Numérique & IAMD · P.05 — Module complet