Introduction
L’article 28 de DORA impose aux entités financières réglementées de démontrer une maîtrise effective des risques liés aux tiers TIC.
Cette obligation va bien au-delà des questionnaires fournisseurs ou des déclarations contractuelles. Les auditeurs n’évaluent pas les intentions : ils évaluent les preuves.
Cet article propose un dossier de preuves pratique pour l’article 28 de DORA, centré sur ce que les auditeurs demandent généralement, sur l’origine des preuves et sur la manière dont les systèmes CI/CD et de livraison cloud doivent soutenir la gestion du risque TIC tiers.
Il fait le pont entre deux perspectives complémentaires :
- Les auditeurs raisonnent en termes d’objectifs de contrôle, de preuves et de responsabilité.
- Les ingénieurs raisonnent en termes de systèmes, de pipelines, de configurations et d’automatisation.
Les deux visions sont valables, mais elles ne sont pas interchangeables. Cet article montre ce que les auditeurs cherchent réellement à vérifier, comment les ingénieurs doivent mettre en œuvre les contrôles pour répondre à ces attentes, et où surviennent habituellement les malentendus.
Ce que les audits de l’article 28 recouvrent réellement
Du point de vue de l’audit, l’article 28 répond à quatre questions fondamentales :
- Connaissez-vous les tiers TIC dont vous dépendez ?
- Les obligations contractuelles sont-elles applicables dans la pratique ?
- Pouvez-vous surveiller en continu les risques liés aux tiers ?
- Pouvez-vous quitter un prestataire en toute sécurité s’il défaille ou devient non conforme ?
Les preuves doivent être opérationnelles, traçables et vérifiables, et pas uniquement documentaires.
Comment les auditeurs abordent une revue de l’article 28
Les auditeurs ne commencent pas par les outils ou les schémas d’architecture. Ils commencent par des questions de risque :
- Les prestataires TIC tiers introduisent-ils un risque opérationnel non maîtrisé ?
- Les contrôles sont-ils applicables au-delà des systèmes internes ?
- L’organisation peut-elle démontrer une surveillance continue ?
- Les preuves sont-elles objectives et horodatées ?
Les preuves sont évaluées comme la démonstration d’une maîtrise opérationnelle, et non comme une confirmation documentaire.
| Perspective | Objet |
|---|---|
| Vision auditeur | Cette organisation peut-elle démontrer une maîtrise effective du risque TIC tiers ? |
| Vision ingénieur | Comment appliquer les contrôles et générer des preuves via les systèmes CI/CD et cloud ? |
Vue d’ensemble du dossier de preuves
Un dossier de preuves au titre de l’article 28 de DORA couvre généralement cinq domaines de preuves :
- Inventaire des fournisseurs & criticité
- Contrôles contractuels & droits d’audit
- Application des contrôles CI/CD et cloud
- Preuves de surveillance & d’incidents
- Preuves de stratégie de sortie & de résilience
Chaque domaine ci-dessous explique ce qu’attendent les auditeurs, quelles preuves présenter et d’où elles doivent provenir, à la fois selon la vision auditeur et la vision ingénieur.
1. Inventaire des fournisseurs & criticité
Ce qu’attendent les auditeurs
Les auditeurs veulent la preuve que vous avez :
- identifié tous les prestataires TIC tiers,
- classé ces prestataires par criticité,
- relié ces prestataires aux services métier et aux pipelines de livraison.
Ils attendent l’inclusion des plateformes SaaS CI/CD (et pas seulement des fournisseurs traditionnels), une visibilité sur les services cloud, les registres et l’hébergement du code, ainsi qu’un lien entre les fournisseurs et les systèmes réellement utilisés.
Preuves à fournir
- Inventaire centralisé des fournisseurs TIC
- Classification par criticité (critique / important / non critique)
- Correspondance entre fournisseurs, outillage CI/CD et composants du runtime cloud
Artefacts de preuve types
- Registre d’inventaire des fournisseurs (exportable)
- Méthodologie de classification des risques
- Table de correspondance : Fournisseur → composant CI/CD / cloud
Vision auditeur
Les auditeurs demandent :
- Disposez-vous d’un inventaire complet des prestataires TIC tiers ?
- Les prestataires sont-ils classés par criticité ?
- Cette classification est-elle reliée aux services métier et aux systèmes de livraison ?
Ce qu’ils vérifient : l’exhaustivité de l’inventaire, sa cohérence avec les systèmes réellement utilisés et sa traçabilité vers les décisions de gestion des risques.
Vision ingénieur
Les ingénieurs doivent s’assurer que :
- les plateformes CI/CD, l’hébergement Git, les registres, les exécuteurs et les services cloud sont explicitement enregistrés comme fournisseurs,
- les métadonnées des fournisseurs (criticité, responsable, usage) sont maintenues à jour par rapport à l’usage réel,
- les pipelines ne référencent que des fournisseurs approuvés.
Mise en œuvre type :
- CMDB ou registre des fournisseurs relié à l’outillage CI/CD,
- contrôles automatisés empêchant l’usage de services non approuvés,
- documentation générée à partir des configurations réelles.
2. Contrôles contractuels & droits d’audit
Ce qu’attendent les auditeurs
Les contrats doivent rendre le contrôle possible, et pas seulement le décrire. Les auditeurs recherchent des clauses applicables couvrant :
- les droits d’audit,
- les délais de notification des incidents,
- la conservation des preuves,
- la transparence sur les sous-traitants,
- les obligations de sortie et de transition.
Plus important encore, ils vérifient que ces clauses sont applicables sur le plan opérationnel.
« Vous disposez de droits d’audit dans le contrat : comment les exercez-vous en pratique ? »
Preuves à fournir
- Extraits de contrats montrant les droits d’audit, l’accès de surveillance et les clauses de notification d’incident
- Preuve que les contrats s’appliquent aux prestataires réellement utilisés
Artefacts de preuve types
- Extraits de clauses contractuelles
- Registre des contrats fournisseurs
- Notes de revue juridique reliant les clauses aux exigences de l’article 28
Vision auditeur
Les auditeurs recherchent :
- des droits d’audit applicables,
- des obligations de notification d’incident,
- des engagements de conservation des preuves,
- une visibilité sur les sous-traitants,
- des clauses de sortie définies.
Ils ne présument pas qu’un contrat est efficace du seul fait qu’il existe.
Vision ingénieur
Les ingénieurs doivent :
- connaître les obligations contractuelles qui pèsent sur les contrôles techniques,
- s’assurer que les plateformes peuvent réellement produire les preuves requises,
- soutenir les audits sans collecte de données ad hoc.
Mise en œuvre type :
- correspondance clauses contractuelles → contrôles techniques,
- conservation suffisamment longue des journaux, SBOM et approbations,
- accès d’audit techniquement possible (lecture seule, à périmètre restreint).
3. Application des contrôles CI/CD & cloud
Ce qu’attendent les auditeurs
Les auditeurs vérifient que l’outillage tiers est maîtrisé dans la pratique, et non utilisé en confiance aveugle. Cela inclut les plateformes d’hébergement du code source, les services d’orchestration CI/CD, les exécuteurs et environnements d’exécution, ainsi que les registres d’artefacts et les écosystèmes de dépendances.
Preuves à fournir
- Configuration du contrôle d’accès (IAM, rôles, SoD)
- Règles de protection des branches et d’approbation
- Isolation des builds et gouvernance des exécuteurs
- Intégrité des artefacts (SBOM, signature)
Artefacts de preuve types
- Captures d’écran ou exports de configuration de la plateforme CI/CD
- Définitions des politiques de pipeline (Policy as Code)
- Rapports de SBOM et de signature d’artefacts
- Journaux d’accès des plateformes Git / CI/CD
Vision auditeur
Les auditeurs veulent la preuve que :
- l’accès est contrôlé et séparé,
- les approbations sont appliquées,
- les artefacts sont protégés contre l’altération,
- l’outillage tiers ne contourne pas les contrôles internes.
Ils testent si les contrôles sont systématiques, et non manuels.
Vision ingénieur
Les ingénieurs mettent en œuvre :
- l’IAM, la séparation des rôles, les protections de branches,
- les approbations de pipeline et les points de contrôle de politique,
- la génération de SBOM et la signature des artefacts,
- l’isolation des exécuteurs et la limitation de portée des jetons.
Changement d’état d’esprit clé :
« Sécurisé par défaut » ne suffit pas : les contrôles doivent être démontrables.
4. Surveillance & gestion des incidents
Ce qu’attendent les auditeurs
DORA exige une surveillance continue, et non des vérifications ponctuelles. Les auditeurs vérifient que les services tiers sont surveillés, que les incidents sont détectés et que les preuves sont conservées et traçables.
Ils recherchent :
- des données de surveillance en temps réel ou historiques,
- des alertes liées aux services tiers,
- une visibilité sur la disponibilité et l’intégrité de la plateforme CI/CD.
Les preuves de surveillance doivent démontrer qu’une dégradation d’un tiers serait détectée et que les incidents seraient escaladés dans les délais définis. Les évaluations de risque statiques ne suffisent pas à elles seules.
Preuves à fournir
- Tableaux de bord de surveillance (signaux de disponibilité, d’intégrité)
- Journaux d’incidents impliquant des services tiers
- Preuves d’escalade et de notification des incidents
Artefacts de preuve types
- Journaux et métriques des plateformes CI/CD et cloud
- Tickets d’incident référençant des prestataires tiers
- Preuves d’intégration SIEM ou d’observabilité
Vision auditeur
Les auditeurs évaluent si :
- les services tiers sont surveillés en continu,
- les incidents impliquant des fournisseurs sont détectables,
- le traitement des incidents est documenté et traçable.
Ils rejettent les évaluations de risque annuelles dépourvues de surveillance opérationnelle.
Vision ingénieur
Les ingénieurs s’assurent que :
- les plateformes CI/CD, les registres et les runtimes cloud émettent des journaux,
- la surveillance alimente un SIEM ou une journalisation centralisée,
- les incidents référencent les prestataires tiers concernés.
Mise en œuvre type :
- pipelines d’observabilité,
- tickets d’incident reliés aux journaux et aux métriques,
- alertes sur la dégradation ou la défaillance d’un fournisseur.
SLA de notification d’incident : éprouvés dans la réalité
Les auditeurs vérifient que :
- des SLA de notification d’incident existent contractuellement,
- les processus internes peuvent recevoir les notifications et y donner suite,
- les délais sont réalistes et éprouvés.
Ils demandent souvent des exemples d’incidents passés, des horodatages montrant les délais de notification, et des preuves d’escalade et de réponse. Un SLA jamais mis à l’épreuve est considéré comme non prouvé.
5. Stratégie de sortie & résilience
Ce qu’attendent les auditeurs
Les stratégies de sortie doivent être réalistes et éprouvées. Les auditeurs cherchent à savoir si des plans de sortie existent, s’ils s’appliquent aux prestataires critiques et s’ils ont déjà été testés.
Preuves à fournir
- Stratégies de sortie documentées par prestataire critique
- Preuves de tests de sortie ou de repli
- Résultats de tests PRA / PCA impliquant des dépendances tierces
Artefacts de preuve types
- Plans de sortie et procédures de transition
- Rapports de tests ou résultats d’exercices sur table
- Documentation de remplacement ou de repli des dépendances
Vision auditeur
Les auditeurs demandent :
- Des stratégies de sortie existent-elles pour les fournisseurs critiques ?
- Ont-elles été testées ?
- Pourriez-vous réellement quitter le prestataire sous pression ?
Un plan de sortie au format PDF ne suffit pas à lui seul.
Vision ingénieur
Les ingénieurs soutiennent les stratégies de sortie en :
- évitant une forte dépendance à un fournisseur,
- documentant les voies de remplacement ou de repli,
- participant aux tests de PRA et de sortie.
Mise en œuvre type :
- portabilité des artefacts,
- reproductibilité via l’infrastructure-as-code,
- procédures de sauvegarde et de restauration éprouvées.
Qualité des preuves : comment les auditeurs jugent leur crédibilité
Les auditeurs évaluent les preuves au regard de quatre critères implicites :
- Objectivité – générées par le système, non éditées manuellement
- Traçabilité – reliées à un fournisseur ou à un contrôle précis
- Continuité – produites de façon régulière dans le temps
- Intégrité – protégées contre toute altération
Une preuve qui échoue à l’un de ces critères affaiblit l’ensemble du dossier. Les tableurs manuels seuls remplissent rarement ces critères.
Constats d’audit fréquents sur l’article 28 (signaux d’alerte)
Les auditeurs relèvent fréquemment des constats lorsqu’ils observent :
- des inventaires de fournisseurs non reliés à l’outillage CI/CD,
- des contrats sans application opérationnelle,
- une surveillance limitée à des revues annuelles,
- aucune preuve de visibilité sur les sous-traitants,
- des plans de sortie jamais testés.
| Situation | Réaction de l’auditeur |
|---|---|
| « Nous faisons confiance à ce prestataire SaaS » | ❌ Non acceptable |
| Preuves collectées manuellement avant l’audit | ⚠️ Contrôle faible |
| Les journaux existent mais ne sont pas conservés | ❌ Non conforme |
| Plan de sortie jamais testé | ❌ Constat à haut risque |
D’après l’expérience d’audit, les dossiers de preuves échouent souvent parce que :
- les plateformes SaaS CI/CD sont exclues du périmètre fournisseurs,
- les preuves existent mais ne peuvent être reliées à un contrôle,
- les journaux sont disponibles mais pas conservés assez longtemps,
- les SLA d’incident existent mais n’ont jamais été testés,
- les stratégies de sortie sont documentées mais non étayées par la réalité technique.
Ces problèmes apparaissent généralement pendant l’audit, et non pendant la préparation. Intégrer les preuves dès la conception des pipelines évite ces lacunes.
Comment l’architecture CI/CD facilite la conformité à l’article 28
La conformité moderne à l’article 28 dépend fortement de l’architecture CI/CD et cloud :
- les pipelines appliquent les accès et les approbations,
- les SBOM apportent la transparence sur la chaîne d’approvisionnement,
- les journaux et pistes d’audit génèrent des preuves automatiquement,
- les systèmes de surveillance détectent les défaillances des tiers.
Sans preuves au niveau du CI/CD, la conformité à l’article 28 reste fragile.
Concevoir pour les deux visions
Les organisations les plus matures :
- conçoivent les contrôles une seule fois,
- répondent à la fois aux besoins d’audit et d’ingénierie,
- génèrent des preuves en continu via les plateformes CI/CD et cloud.
C’est le fondement de la conformité continue au titre de DORA.
À retenir
L’article 28 de DORA n’est pas un exercice documentaire : c’est un problème de maîtrise opérationnelle.
Les dossiers de preuves les plus solides :
- intègrent la gouvernance du CI/CD, du cloud et des fournisseurs,
- génèrent des preuves en continu,
- alignent architecture, contrats et surveillance.
Si les auditeurs peuvent vérifier les contrôles sans dépendre d’explications, votre posture au regard de l’article 28 est solide.
Lectures associées recommandées
- Architecture de l’article 28 de DORA — expliquée
- La conformité continue via les pipelines CI/CD
- Signaux d’alerte des audits CI/CD
