L’article 21 du règlement sur la résilience opérationnelle numérique (DORA) définit les exigences fondamentales de gestion du risque ICT que les entités financières doivent mettre en œuvre, surveiller et démontrer en continu. Contrairement aux obligations de gouvernance de haut niveau, l’article 21 porte sur des contrôles techniques et organisationnels concrets — et, pour la plupart des institutions, c’est dans le pipeline CI/CD qu’une large part de ces contrôles est effectivement appliquée.
Voici la référence complète et consolidée pour l’article 21 dans un contexte CI/CD. Elle réunit, dans une seule ressource prête pour l’audit, quatre éléments que les équipes de conformité et d’assurance doivent habituellement rassembler séparément : une analyse approfondie de chaque exigence de l’article 21, une cartographie contrôle par contrôle reliant la réglementation à des contrôles CI/CD spécifiques et aux preuves qu’ils génèrent, une checklist d’audit pour les revues internes et prudentielles, et un dossier de preuves décrivant précisément quels artefacts présenter et où les trouver.
Ce contenu s’adresse aux auditeurs, aux responsables conformité et aux professionnels GRC qui préparent — ou mènent — une évaluation DORA. Lisez l’analyse approfondie pour comprendre l’intention, utilisez la cartographie pour relier les exigences aux contrôles, parcourez la checklist pendant les travaux sur le terrain, et constituez le dossier de preuves pour démontrer que les contrôles sont appliqués de manière cohérente et reproductible.
Comprendre le périmètre de l’article 21 de DORA
L’article 21 impose aux entités financières d’établir, de mettre en œuvre et de maintenir un cadre complet de gestion du risque ICT. Ce cadre doit garantir la confidentialité, l’intégrité, la disponibilité et l’authenticité des systèmes ICT qui soutiennent des fonctions critiques ou importantes.
Les pipelines CI/CD entrent dans ce périmètre car ils influencent directement :
- le comportement des systèmes de production
- la fréquence et la stabilité des déploiements
- l’intégrité de la chaîne d’approvisionnement logicielle
- les accès privilégiés à l’infrastructure et aux applications
Par conséquent, les pipelines CI/CD doivent être gouvernés et contrôlés comme des systèmes ICT régulés.
Article 21(1) : cadre de gestion du risque ICT et CI/CD
L’article 21(1) impose un cadre structuré de gestion du risque ICT couvrant l’identification, la protection, la prévention, la détection, la réponse et la reprise.
Les pipelines CI/CD répondent à cette exigence en :
- identifiant les risques grâce aux tests de sécurité automatisés
- prévenant les risques via l’application de politiques et des points d’approbation
- détectant les anomalies grâce à la surveillance des pipelines
- soutenant la réponse via des mécanismes de rollback traçables
- permettant la reprise grâce à des processus de déploiement contrôlés
Intégrer ces mécanismes dans les workflows CI/CD garantit que la gestion du risque ICT est opérationnelle plutôt que théorique.
Article 21(2)(a) : contrôle d’accès et opérations privilégiées
L’article 21(2)(a) exige des mécanismes de contrôle d’accès appropriés pour protéger les systèmes ICT contre les accès non autorisés.
Dans un contexte CI/CD, cela se traduit par :
- une séparation stricte entre les utilisateurs humains et les identités des pipelines
- l’application du moindre privilège pour les comptes de service CI/CD
- un contrôle d’accès basé sur les rôles pour la configuration des pipelines
- une MFA obligatoire pour les administrateurs
Ne pas sécuriser les chemins d’accès CI/CD expose les organisations à un risque systémique, car les pipelines détiennent souvent des privilèges élevés sur l’ensemble des environnements.
Article 21(2)(b) : séparation des tâches et gouvernance
L’article 21 met l’accent sur la séparation des tâches afin de réduire le risque de changements non autorisés ou non revus.
Les pipelines CI/CD appliquent la séparation des tâches en :
- exigeant une revue de code indépendante avant l’exécution du pipeline
- séparant les autorisations de build, de validation et de déploiement
- imposant des workflows d’approbation pour les mises en production sensibles
- journalisant toutes les dérogations et exceptions
La séparation automatisée au sein des pipelines offre des garanties plus solides que les contrôles manuels.
Article 21(2)(c) : journalisation, surveillance et détection
L’article 21 exige des capacités de surveillance et de détection continues pour identifier les incidents liés à l’ICT.
Les pipelines CI/CD y contribuent en :
- journalisant toutes les exécutions de pipeline et modifications de configuration
- enregistrant les résultats des analyses de sécurité et les décisions d’approbation
- émettant des alertes en cas de comportement anormal ou d’échec des contrôles
- s’intégrant aux systèmes de surveillance centralisée et aux SIEM
Ces journaux constituent un élément essentiel des processus de détection et d’investigation conformes à DORA.
Article 21(2)(d) : gestion des changements et intégrité des systèmes
La gestion des changements est une composante centrale de l’article 21. Les pipelines CI/CD mettent directement en œuvre des processus de changement contrôlés.
Les principaux mécanismes d’application incluent :
- l’approbation obligatoire des changements via les points de contrôle du pipeline
- la validation et la signature de l’intégrité des artefacts
- la traçabilité entre le code source, l’exécution du pipeline et l’artefact déployé
- la prévention des déploiements hors circuit
Ces contrôles garantissent que seuls des changements autorisés et vérifiés atteignent les systèmes de production.
Article 21(2)(e) : résilience, sauvegarde et reprise
La résilience opérationnelle est un objectif central de DORA. Les pipelines CI/CD ne doivent pas devenir des points de défaillance uniques.
Une conception de pipeline résiliente comprend :
- des environnements de build durcis et isolés
- de la redondance pour les composants CI/CD critiques
- des mécanismes de rollback et de redéploiement testés
- des sauvegardes sécurisées de la configuration et des artefacts du pipeline
Les pipelines CI/CD qui échouent proprement et se rétablissent rapidement soutiennent les objectifs plus larges de résilience ICT.
Génération continue de preuves pour la conformité à l’article 21
L’un des avantages les plus importants d’une conformité fondée sur le CI/CD est la génération continue de preuves.
Les pipelines CI/CD produisent naturellement :
- des journaux d’accès et des enregistrements d’approbation
- des résultats de tests de sécurité
- des métadonnées de provenance des artefacts
- des historiques de déploiement
Ces preuves répondent directement aux attentes d’audit de l’article 21 en démontrant que les contrôles sont appliqués de manière cohérente et continue.
Lacunes fréquemment observées lors des évaluations DORA
Les organisations sous-estiment souvent l’importance du CI/CD dans leurs travaux de préparation à DORA. Les lacunes fréquentes incluent :
- considérer les pipelines comme des outils non régulés
- des privilèges excessifs accordés à l’automatisation
- l’absence de provenance des artefacts
- une rétention des journaux insuffisante
- des exceptions et dérogations non documentées
Traiter ces lacunes en amont réduit sensiblement le risque réglementaire et opérationnel.
Cartographie des contrôles article 21 ↔ CI/CD
L’analyse approfondie ci-dessus explique ce que demande chaque exigence de l’article 21. La cartographie ci-dessous la transforme en une vue opérationnelle : pour chaque exigence, elle nomme le contrôle CI/CD correspondant et la preuve précise que ce contrôle produit. Les auditeurs peuvent lire chaque ligne comme une assertion vérifiable — l’exigence à gauche doit être satisfaite par le contrôle au centre, et prouvable par la preuve à droite.
Article 21(1) — cadre de gestion du risque ICT
| Exigence DORA | Contrôle CI/CD | Preuve générée |
|---|---|---|
| Identifier et évaluer les risques ICT | Tests de sécurité automatisés (SAST, SCA, DAST) | Rapports d’analyse, journaux de pipeline |
| Prévenir et atténuer les risques ICT | Application de politiques et points de contrôle du pipeline | Décisions de contrôle, approbations |
| Détecter les activités anormales | Surveillance et alertes du pipeline | Journaux d’alerte, événements SIEM |
| Répondre aux incidents ICT | Rollback et redéploiements contrôlés | Historique des déploiements |
| Se rétablir après des perturbations | Builds et livraisons reproductibles | Métadonnées de build |
Article 21(2)(a) — contrôle d’accès
| Exigence DORA | Contrôle CI/CD | Preuve générée |
|---|---|---|
| Empêcher les accès non autorisés | RBAC pour la configuration CI/CD | Journaux de contrôle d’accès |
| Protéger les opérations privilégiées | Comptes de service à moindre privilège | Politiques IAM |
| Sécuriser les accès administratifs | MFA pour les administrateurs CI/CD | Journaux d’authentification |
| Contrôler les identités d’automatisation | Identités de pipeline distinctes | Inventaire des identités |
Article 21(2)(b) — séparation des tâches
| Exigence DORA | Contrôle CI/CD | Preuve générée |
|---|---|---|
| Séparer les rôles en conflit | Exigences de revue de code | Historique des pull requests |
| Empêcher l’auto-approbation | Règles d’approbation appliquées par le pipeline | Enregistrements d’approbation |
| Contrôler l’autorité de mise en production | Séparer les autorisations de build et de déploiement | Cartographie des rôles du pipeline |
| Journaliser les dérogations et exceptions | Journalisation des exceptions | Journaux d’audit des dérogations |
Article 21(2)(c) — journalisation et surveillance
| Exigence DORA | Contrôle CI/CD | Preuve générée |
|---|---|---|
| Surveiller l’activité des systèmes ICT | Journalisation complète de l’exécution des pipelines | Journaux d’exécution |
| Détecter les événements pertinents pour la sécurité | Alertes sur les contrôles en échec et les anomalies | Alertes de sécurité |
| Conserver les journaux de manière sécurisée | Stockage centralisé des journaux | Configuration de rétention |
| Soutenir les investigations | Pistes d’audit immuables | Journaux exploitables en investigation |
Article 21(2)(d) — gestion des changements et intégrité
| Exigence DORA | Contrôle CI/CD | Preuve générée |
|---|---|---|
| Contrôler les changements des systèmes ICT | Pipelines CI/CD obligatoires | Historique des déploiements |
| Garantir l’intégrité des changements | Signature et vérification des artefacts | Métadonnées de signature |
| Tracer les changements de bout en bout | Liaison source → pipeline → artefact | Enregistrements de provenance |
| Empêcher les déploiements non autorisés | Points de contrôle et approbations | Journaux d’application des points de contrôle |
Article 21(2)(e) — résilience, sauvegarde et reprise
| Exigence DORA | Contrôle CI/CD | Preuve générée |
|---|---|---|
| Garantir la résilience des systèmes | Environnements de build durcis et isolés | Configuration des environnements |
| Éviter les points de défaillance uniques | Composants CI/CD redondants | Documentation d’architecture |
| Activer des mécanismes de reprise | Workflows de rollback et de redéploiement | Journaux de reprise |
| Protéger les configurations | Sauvegarde sécurisée de la configuration du pipeline | Enregistrements de sauvegarde |
Article 21(2)(f) — amélioration continue
| Exigence DORA | Contrôle CI/CD | Preuve générée |
|---|---|---|
| Réexaminer la posture de risque ICT | Revues de sécurité périodiques des pipelines | Rapports de revue |
| Mettre à jour les contrôles si nécessaire | Modifications de la configuration du pipeline | Journaux de modifications |
| Améliorer la détection et la prévention | Mises à jour des outils et ajustement des règles | Historique des versions |
| S’aligner sur l’évolution des menaces | Mises à jour du pipeline informées par la menace | Évaluations des risques |
Comment les auditeurs utilisent ce tableau
- Valider que les exigences de l’article 21 sont techniquement appliquées
- Identifier où le CI/CD contribue à la gestion du risque ICT
- Demander des preuves spécifiques générées par les pipelines
- Évaluer la cohérence et la répétabilité des contrôles
Checklist d’audit pour l’article 21
Une fois que la cartographie établit quels contrôles devraient exister, la checklist ci-dessous permet à un évaluateur de confirmer s’ils existent réellement. Elle est organisée selon les mêmes sous-sections de l’article 21 et convient aux audits internes, aux revues prudentielles et aux évaluations réglementaires. Chaque ligne est une vérification de contrôle par oui/non ; un « non » signale une lacune qui justifie un constat ou une action de remédiation.
Article 21(1) — cadre de gestion du risque ICT
| Vérification du contrôle | Oui | Non |
|---|---|---|
| Les pipelines CI/CD sont inclus dans le périmètre de gestion du risque ICT | ⬜ | ⬜ |
| Les risques ICT liés à la livraison logicielle sont formellement identifiés | ⬜ | ⬜ |
| Des contrôles préventifs sont appliqués via les pipelines CI/CD | ⬜ | ⬜ |
| Des mécanismes de détection existent pour les incidents liés aux pipelines | ⬜ | ⬜ |
| Le CI/CD soutient les processus de réponse et de reprise | ⬜ | ⬜ |
Article 21(2)(a) — contrôle d’accès
| Vérification du contrôle | Oui | Non |
|---|---|---|
| Les accès CI/CD respectent les principes de moindre privilège | ⬜ | ⬜ |
| Les identités des pipelines sont séparées des utilisateurs humains | ⬜ | ⬜ |
| Le RBAC est appliqué à la configuration des pipelines | ⬜ | ⬜ |
| La MFA est requise pour les administrateurs CI/CD | ⬜ | ⬜ |
| Les actions privilégiées sont restreintes et surveillées | ⬜ | ⬜ |
Article 21(2)(b) — séparation des tâches
| Vérification du contrôle | Oui | Non |
|---|---|---|
| Les développeurs ne peuvent pas auto-approuver les changements en production | ⬜ | ⬜ |
| La revue de code est obligatoire avant l’exécution du pipeline | ⬜ | ⬜ |
| Les autorisations de build et de déploiement sont séparées | ⬜ | ⬜ |
| Les dérogations et exceptions sont journalisées | ⬜ | ⬜ |
| La séparation des tâches est réexaminée périodiquement | ⬜ | ⬜ |
Article 21(2)(c) — journalisation et surveillance
| Vérification du contrôle | Oui | Non |
|---|---|---|
| Toutes les exécutions CI/CD sont journalisées | ⬜ | ⬜ |
| Les journaux incluent les approbations et les contrôles de sécurité | ⬜ | ⬜ |
| Les journaux sont collectés de manière centralisée | ⬜ | ⬜ |
| La rétention des journaux respecte les exigences réglementaires | ⬜ | ⬜ |
| Des alertes existent pour les comportements anormaux des pipelines | ⬜ | ⬜ |
Article 21(2)(d) — gestion des changements et intégrité
| Vérification du contrôle | Oui | Non |
|---|---|---|
| Tous les changements en production passent par les pipelines CI/CD | ⬜ | ⬜ |
| L’intégrité des artefacts est vérifiée avant le déploiement | ⬜ | ⬜ |
| La provenance relie le code source aux artefacts déployés | ⬜ | ⬜ |
| Les déploiements hors circuit sont empêchés ou journalisés | ⬜ | ⬜ |
| Les approbations de changement sont auditables | ⬜ | ⬜ |
Article 21(2)(e) — résilience, sauvegarde et reprise
| Vérification du contrôle | Oui | Non |
|---|---|---|
| Les pipelines CI/CD sont conçus pour la résilience | ⬜ | ⬜ |
| Les environnements de build sont isolés et durcis | ⬜ | ⬜ |
| Les configurations des pipelines sont sauvegardées de manière sécurisée | ⬜ | ⬜ |
| Les procédures de rollback sont testées | ⬜ | ⬜ |
| Les composants CI/CD ne constituent pas des points de défaillance uniques | ⬜ | ⬜ |
Article 21(2)(f) — amélioration continue
| Vérification du contrôle | Oui | Non |
|---|---|---|
| Les contrôles de sécurité CI/CD sont réexaminés périodiquement | ⬜ | ⬜ |
| Les contrôles des pipelines évoluent avec le paysage des menaces | ⬜ | ⬜ |
| Les enseignements tirés sont réinjectés dans les pipelines | ⬜ | ⬜ |
| Les lacunes de conformité déclenchent des actions correctives | ⬜ | ⬜ |
| La supervision par la direction inclut la posture de risque CI/CD | ⬜ | ⬜ |
Recommandations pour les auditeurs
Lors de l’utilisation de cette checklist :
- Demander des preuves techniques, pas seulement des politiques
- Vérifier que les contrôles sont automatisés et appliqués
- Confirmer que les preuves sont à jour et reproductibles
- Évaluer la cohérence entre les équipes et les pipelines
- Accorder une attention particulière aux exceptions et dérogations
Dossier de preuves pour les auditeurs
Une checklist confirme qu’un contrôle est présent ; le dossier de preuves le démontre à un auditeur. Cette dernière section énumère, sous-section par sous-section, les artefacts techniques et opérationnels que les institutions financières doivent présenter, ce que les auditeurs attendent de chacun, et où réside habituellement cette preuve. L’accent est mis partout sur des preuves générées par les systèmes, horodatées et reproductibles, plutôt que sur de simples déclarations de politique.
Comment utiliser ce dossier de preuves
- L’utiliser comme checklist lors de la préparation de l’audit
- Le partager avec les équipes d’ingénierie, de sécurité et de conformité
- Y joindre des références à des systèmes, journaux et dépôts réels
- S’assurer que les preuves sont à jour, traçables et reproductibles
Article 21(1) — cadre de gestion du risque ICT
Preuves à fournir
| Type de preuve | Ce que les auditeurs attendent |
|---|---|
| Registre des risques ICT | Pipelines CI/CD explicitement listés comme systèmes ICT dans le périmètre |
| Modèles de menaces | Risques liés au CI/CD (abus d’identifiants, chaîne d’approvisionnement, intégrité) |
| Plans de traitement des risques | Contrôles rattachés aux pipelines CI/CD |
| Documentation de gouvernance | Responsabilité de la sécurité et du risque CI/CD |
Sources habituelles
- Outils de gestion des risques
- Documentation d’architecture
- Dépôts de gouvernance de sécurité
Article 21(2)(a) — contrôle d’accès
Preuves à fournir
| Type de preuve | Ce que les auditeurs attendent |
|---|---|
| Politiques IAM | Moindre privilège pour les comptes de service CI/CD |
| Configuration RBAC | Séparation des rôles pour l’administration des pipelines |
| Application de la MFA | Preuve que la MFA est requise pour les utilisateurs privilégiés |
| Inventaire des identités | Distinction entre identités humaines et identités d’automatisation |
Sources habituelles
- Plateforme IAM
- Configuration du système CI/CD
- Rapports de revue des accès
Article 21(2)(b) — séparation des tâches
Preuves à fournir
| Type de preuve | Ce que les auditeurs attendent |
|---|---|
| Règles de revue de code | Revue par les pairs obligatoire et appliquée |
| Workflows d’approbation | Approbation indépendante pour les changements en production |
| Cartographie des rôles | Séparation entre les rôles de build, de validation et de déploiement |
| Journaux des exceptions | Enregistrements des dérogations et approbations |
Sources habituelles
- Plateforme de gestion de code source
- Définitions des pipelines CI/CD
- Journaux d’audit
Article 21(2)(c) — journalisation et surveillance
Preuves à fournir
| Type de preuve | Ce que les auditeurs attendent |
|---|---|
| Journaux d’exécution des pipelines | Historique complet des exécutions et de leurs résultats |
| Journaux d’événements de sécurité | Contrôles en échec, mises en production bloquées |
| Tableaux de bord de surveillance | Visibilité sur l’état de santé des pipelines |
| Politiques de rétention des journaux | Alignement sur les exigences réglementaires |
Sources habituelles
- Plateformes CI/CD
- Systèmes SIEM / de journalisation
- Outils de surveillance
Article 21(2)(d) — gestion des changements et intégrité
Preuves à fournir
| Type de preuve | Ce que les auditeurs attendent |
|---|---|
| Enregistrements de déploiement | Tous les changements en production traçables jusqu’aux pipelines |
| Signature des artefacts | Preuve d’intégrité cryptographique |
| Métadonnées de provenance | Liaison source → build → artefact |
| Approbations de mise en production | Points de décision auditables |
Sources habituelles
- Dépôts d’artefacts
- Magasins de métadonnées CI/CD
- Systèmes de gestion des mises en production
Article 21(2)(e) — résilience, sauvegarde et reprise
Preuves à fournir
| Type de preuve | Ce que les auditeurs attendent |
|---|---|
| Schémas d’architecture CI/CD | Redondance et isolation |
| Procédures de sauvegarde | Sauvegardes sécurisées des configurations de pipeline |
| Tests de reprise | Preuves d’exercices de rollback et de reprise |
| Playbooks d’incident | Procédures de réponse spécifiques au CI/CD |
Sources habituelles
- Documentation d’architecture
- Systèmes de sauvegarde
- Outils de gestion des incidents
Article 21(2)(f) — amélioration continue
Preuves à fournir
| Type de preuve | Ce que les auditeurs attendent |
|---|---|
| Rapports de revue | Revues de sécurité périodiques du CI/CD |
| Journaux de modifications | Améliorations des contrôles des pipelines |
| Métriques et KPI | Indicateurs de sécurité et de résilience |
| Supervision par la direction | Preuves de revue de gouvernance |
Sources habituelles
- Enregistrements des revues de sécurité
- Historique des modifications CI/CD
- Comptes rendus des réunions de gouvernance
Pièges d’audit fréquents (ce qu’il ne faut PAS présenter seul)
Les auditeurs remettront en question :
- Des politiques de haut niveau sans application technique
- Des captures d’écran sans traçabilité
- Des attestations manuelles sans preuve issue des systèmes
- Des exemples ponctuels au lieu de contrôles répétables
Les preuves doivent être générées par les systèmes, horodatées et reproductibles.
Conseils de présentation adaptés aux auditeurs
- Regrouper les preuves par sous-section de l’article 21
- Fournir un accès en lecture seule aux journaux et tableaux de bord
- Inclure un échantillon de preuve + une explication
- Indiquer clairement les responsables des contrôles
- Éviter de submerger les auditeurs de données non pertinentes
Conclusion
L’article 21 de DORA établit une attente claire : la gestion du risque ICT doit être intégrée, continue et appliquée techniquement. Les pipelines CI/CD, en tant que rouages essentiels de la livraison logicielle, sont au cœur du respect de cette attente — et, parce qu’ils génèrent des journaux, des approbations et de la provenance comme sous-produit de leur fonctionnement normal, ils constituent aussi l’une des sources de preuves d’audit les plus riches dont dispose une entité financière.
En alignant la conception des pipelines sur les contrôles de l’article 21 décrits ici, et en préparant à l’avance la cartographie, la checklist et le dossier de preuves, les institutions peuvent passer de la précipitation réactive au moment de l’audit à un état de préparation permanente à l’audit — démontrant leur résilience opérationnelle, réduisant le risque systémique et fournissant aux régulateurs une preuve de conformité concrète et reproductible.
Ressources associées
- Conformité continue via le CI/CD sous DORA
- Audit de sécurité CI/CD — cartographie ISO 27001 / SOC 2 / DORA
- Architecture de conformité DORA
- Conformité
- Sécurité CI/CD
