DORA

Digital Operational Resilience Act (DORA) — CI/CD et risque ICT dans les environnements réglementés

Le Digital Operational Resilience Act (DORA) établit un cadre unifié pour la gestion du risque ICT dans le secteur financier européen.

Il s’applique aux :

  • Banques
  • Compagnies d’assurance
  • Sociétés d’investissement
  • Établissements de paiement
  • Prestataires de services sur crypto-actifs
  • Fournisseurs tiers critiques de services ICT

DORA ne réglemente pas le code.
Il réglemente la résilience opérationnelle.

Les pipelines CI/CD, l’infrastructure cloud et les services ICT tiers relèvent directement de son périmètre.

Pourquoi DORA est important pour le CI/CD

Dans les environnements financiers réglementés, les pipelines CI/CD font partie du système ICT.
Cela signifie qu’ils doivent :

  • Appliquer des contrôles d’accès
  • Séparer les responsabilités
  • Protéger les environnements de production
  • Générer des preuves d’audit
  • Gérer le risque tiers
  • Soutenir la réponse aux incidents et la reprise d’activité

DORA transforme le CI/CD d’un outil de livraison en un système de contrôle réglementé.

Les deux piliers critiques de DORA pour le CI/CD

Bien que DORA contienne plusieurs chapitres, deux domaines sont particulièrement pertinents pour le CI/CD et les architectures cloud :

1. Article 21 — Gestion du risque ICT et cadre de contrôle

L’article 21 exige des entités financières qu’elles mettent en œuvre des contrôles robustes de gestion du risque ICT.

Pour le CI/CD, cela se traduit par :

  • Gestion sécurisée des changements
  • Déploiements contrôlés
  • Séparation des responsabilités
  • Gouvernance des accès
  • Journalisation et traçabilité
  • Conservation des preuves
  • Application du cycle de développement sécurisé

Le CI/CD doit permettre :

  • Des approbations basées sur le risque
  • Des portes de politique obligatoires
  • Des contrôles de sécurité bloquants
  • Un historique des changements traçable

🔎 Guides associés :

2. Article 28 — Gestion du risque tiers ICT

L’article 28 porte sur les prestataires tiers de services ICT.

Pour les écosystèmes CI/CD modernes, cela inclut :

  • Les plateformes d’hébergement Git
  • Les fournisseurs SaaS de CI/CD
  • Les registres d’artefacts
  • Les environnements d’exécution cloud
  • Les plugins et intégrations de marketplace

L’article 28 exige :

  • Une évaluation formelle des risques fournisseurs
  • Des clauses contractuelles de sécurité
  • Des droits d’audit
  • Des stratégies de sortie
  • Des tests de résilience
  • Un suivi continu

Si votre pipeline fonctionne sur une infrastructure SaaS, vous gérez un risque tiers ICT.

🔎 Guides associés :

DORA et architecture CI/CD

Une architecture conforme à DORA doit :

  • Imposer des workflows d’approbation obligatoires
  • Empêcher l’accès direct à la production
  • Bloquer les builds non conformes
  • Signer et tracer les artefacts
  • Conserver les logs de déploiement
  • Surveiller les événements en production
  • Isoler les accès privilégiés

La conformité DORA ne s’obtient pas par la documentation seule.
Elle nécessite une application architecturale.

DORA et conformité continue

DORA attend que les contrôles fonctionnent en continu — et non périodiquement.

Le CI/CD peut y contribuer en :

  • Automatisant l’application des politiques
  • Générant des logs inviolables
  • Enregistrant les chaînes d’approbation
  • Préservant la traçabilité des déploiements
  • Suivant l’utilisation des services tiers

Lorsqu’il est correctement conçu, le pipeline devient un moteur de conformité.

DORA vs autres référentiels

DORA chevauche :

  • ISO 27001 (contrôles Annexe A)
  • SOC 2 (accès logique et gestion des changements)
  • NIS2 (résilience de la chaîne d’approvisionnement)
  • PCI DSS (développement sécurisé et contrôle d’accès)

Cependant, DORA est une réglementation — pas une certification volontaire.
Il introduit des attentes de supervision et des mécanismes d’application.

Idées reçues courantes sur DORA

❌ « DORA ne concerne que la cybersécurité. »

DORA couvre la résilience opérationnelle, y compris la gouvernance, la surveillance et la gestion des tiers.

❌ « Les fournisseurs cloud gèrent la conformité DORA. »

Les entités financières restent responsables, même lorsqu’elles utilisent des prestataires ICT tiers.

❌ « Avoir des outils de sécurité équivaut à la conformité. »

Sans gouvernance appliquée et preuves, les outils seuls sont insuffisants.

Modèle de maturité DORA pour le CI/CD

Les organisations se situent généralement dans l’une des quatre catégories suivantes :

Niveau 1 — Contrôles informels

Approbations manuelles, journalisation incohérente.

Niveau 2 — Sécurité basée sur les outils

Outils de sécurité intégrés mais non bloquants.

Niveau 3 — Contrôles CI/CD appliqués

Les portes de politique bloquent les releases non conformes.

Niveau 4 — Système ICT réglementé

Séparation complète des responsabilités, traçabilité, conservation des preuves et gouvernance des tiers.

Les institutions financières devraient viser le niveau 3 ou le niveau 4.

Ressources pratiques DORA

Architecture :

Article 21 :

Article 28 :

Audit et gouvernance :

Principe final

DORA n’est pas un exercice de documentation.
C’est un mandat de résilience opérationnelle.

Dans les institutions financières modernes, les pipelines CI/CD font partie du périmètre ICT réglementé.

Si votre architecture applique les contrôles et génère des preuves dès la conception, DORA devient gérable.
Si les contrôles sont manuels ou informels, DORA devient un risque systémique.