Introduction
DORA Article 28 exige des entités financières qu’elles gèrent les risques liés aux fournisseurs de services ICT tiers.
Dans la livraison logicielle moderne, ces fournisseurs ne sont pas périphériques — ils sont intégrés directement dans les pipelines CI/CD et les environnements d’exécution cloud.
Cet article présente une vue architecturale pratique de DORA Article 28, montrant :
- où les fournisseurs tiers interviennent dans le cycle de vie CI/CD,
- quels contrôles doivent être appliqués pour rester conforme,
- et comment les preuves doivent être produites pour satisfaire les auditeurs.
L’objectif n’est pas de décrire des outils, mais de clarifier les limites de contrôle, les points d’application et les attentes d’audit.
Il comble également l’écart de perspective entre auditeurs et ingénieurs — deux audiences qui lisent la même architecture très différemment, et dont l’alignement est essentiel pour une conformité réussie.
La véritable chaîne d’approvisionnement CI/CD sous DORA
Un pipeline CI/CD d’entreprise typique repose sur de multiples fournisseurs ICT externes, souvent sans être explicitement traités comme tels.
Sous DORA Article 28, les composants suivants doivent être considérés comme des services ICT tiers :
- Hébergement du code source (Git SaaS / Git managé)
- Orchestration CI/CD (SaaS ou plateforme CI managée)
- Runners / exécution des builds (runners auto-hébergés ou managés)
- Registres d’artefacts et de conteneurs
- Écosystème de dépendances (packages, miroirs, générateurs SBOM)
- Runtime cloud / plateformes managées
- Observabilité (logs, traces, SIEM)
- Outils ITSM / ticketing / approbations (gestion des changements)
L’Article 28 s’applique car chacun de ces fournisseurs peut affecter :
- la confidentialité et l’intégrité du code source et des artefacts,
- la disponibilité des pipelines de livraison,
- la traçabilité et l’auditabilité des changements.
Tout composant tiers impliqué dans la construction, le test, le déploiement ou l’exécution de logiciel est dans le périmètre de l’Article 28.
Deux perspectives sur la même architecture
DORA Article 28 exige des entités financières qu’elles gèrent le risque tiers ICT de manière vérifiable, applicable et auditable. Cependant, les auditeurs et les ingénieurs ne lisent pas les architectures de la même manière.
Vue auditeur (prisme gouvernance et preuves)
Un auditeur examinant la conformité DORA Article 28 n’évalue pas les outils ou pipelines directement. Il vérifie que le risque est contrôlé, documenté et géré continuellement.
Du point de vue de l’auditeur, l’architecture doit répondre à :
- Disposez-vous d’un inventaire complet des fournisseurs ICT tiers ?
- Les fournisseurs sont-ils classés par criticité ?
- Les contrats sont-ils applicables et incluent-ils des droits d’audit, la notification d’incidents et des clauses de sortie ?
- Les preuves sont-elles produites continuellement et conservées ?
- Pouvez-vous quitter les fournisseurs critiques sous pression ?
Vue ingénieur (prisme implémentation et application)
Un ingénieur regardant la même architecture voit un plan de contrôle — un ensemble de mécanismes d’application qui doivent être construits, configurés et maintenus.
Leur focus inclut :
- Où les services tiers sont-ils intégrés dans les pipelines ?
- Comment les contrôles d’accès, approbations et l’isolation sont-ils appliqués techniquement ?
- Comment les SBOM, la signature et la provenance sont-ils générés ?
- Comment les logs, métriques et alertes sont-ils collectés des plateformes tierces ?
- Que se passe-t-il si un fournisseur tombe en panne ou doit être remplacé ?
Même architecture, deux lectures
| Aspect | Vue auditeur | Vue ingénieur |
|---|---|---|
| Focus | Risque, gouvernance, conformité | Automatisation, application, fiabilité |
| Question principale | « Pouvez-vous prouver le contrôle ? » | « Où est-ce que j’applique le contrôle ? » |
| Pipeline CI/CD | Surface de risque | Plan de contrôle |
| Fournisseurs tiers | Fournisseurs à gouverner | Plateformes à intégrer de manière sécurisée |
| Preuves | Exigence explicite | Sortie automatique |
| Stratégie de sortie | Obligatoire | Souvent négligée |
DORA Article 28 exige que les deux perspectives soient satisfaites simultanément.
Principes architecturaux pour la conformité Article 28
1. Traiter les outils tiers comme des actifs de niveau production
Les plateformes CI/CD et les registres doivent suivre les règles de production : durcissement, contrôle d’accès, journalisation, surveillance et continuité testée.
Ce ne sont pas des outils de développement — ce sont des systèmes ICT réglementés.
2. Faire appliquer les contrôles par les contrats
Les clauses contractuelles doivent permettre (ou au moins soutenir) : les droits d’audit, la notification d’incidents, la rétention des preuves, la transparence du traitement des données et les stratégies de sortie.
Les contrats seuls ne suffisent pas sous DORA Article 28. Les politiques définies contractuellement doivent être appliquées techniquement :
- approbations obligatoires,
- portes de sécurité,
- chemins d’exécution restreints,
- capacités d’audit et d’inspection.
Les pipelines CI/CD sont la couche d’application naturelle pour ces politiques.
3. Les preuves doivent être conçues, pas « collectées plus tard »
Les preuves doivent être générées par la plateforme et conservées automatiquement : logs, approbations, SBOM/provenance, enregistrements d’accès, chronologies d’incidents et tests de sortie.
Si les preuves nécessitent un assemblage manuel pendant un audit, elles ne satisferont probablement pas les attentes des auditeurs en matière d’objectivité et de continuité.
Couches de contrôle dans le cycle de vie CI/CD
Contrôle d’accès et isolation
Sous DORA Article 28, les organisations doivent démontrer que les plateformes tierces ne peuvent pas être utilisées à mauvais escient ou avoir des privilèges excessifs.
Les principes clés incluent :
- le contrôle d’accès basé sur les rôles,
- la séparation des fonctions entre développement, approbation et déploiement,
- l’accès au moindre privilège pour les pipelines et l’automatisation.
L’isolation d’accès s’applique à :
- les dépôts Git,
- les pipelines CI/CD et les runners,
- les dépôts d’artefacts,
- les environnements d’exécution cloud.
Les preuves doivent démontrer qu’aucun acteur ou système unique ne peut contourner les contrôles de bout en bout.
Application des politiques contractuelles
Les politiques définies contractuellement doivent être appliquées techniquement via les pipelines CI/CD :
- les approbations sont appliquées avant la mise en production,
- le policy-as-code empêche les changements non autorisés,
- les plateformes tierces opèrent sous des contraintes définies et auditables.
Intégrité de la chaîne d’approvisionnement
DORA Article 28 exige une visibilité sur la chaîne d’approvisionnement logicielle, particulièrement lorsque des composants tiers sont impliqués.
This includes:
- le suivi des dépendances et l’analyse de la composition logicielle (SCA),
- la génération de nomenclature logicielle (SBOM),
- la signature des artefacts et la vérification de provenance,
- le scan des images de conteneurs et les vérifications d’intégrité.
Les auditeurs attendent la preuve que les artefacts produits via les systèmes CI/CD tiers n’ont pas été altérés.
Surveillance et réponse aux incidents
Les services tiers doivent être surveillés continuellement :
- les indicateurs de disponibilité et de performance,
- la détection et l’escalade des incidents,
- l’intégration avec la journalisation centralisée ou le SIEM.
Les auditeurs vérifient que la surveillance s’applique aux fournisseurs tiers, pas seulement aux systèmes internes. Les workflows d’incidents doivent référencer les fournisseurs tiers affectés et démontrer une escalade traçable.
Stratégie de sortie et continuité
La planification de sortie est une exigence réglementaire sous l’Article 28, pas un exercice optionnel.
Les auditeurs vérifieront :
- si des plans de sortie documentés existent pour les fournisseurs critiques,
- si ces plans ont été testés ou exercés,
- si l’organisation pourrait réalistement effectuer une transition sous pression.
Les ingénieurs soutiennent les stratégies de sortie en :
- évitant le verrouillage fournisseur strict,
- documentant les chemins de remplacement ou de repli,
- maintenant la reproductibilité de l’infrastructure-as-code,
- participant aux tests DR, BCP et de sortie.
Ce que les auditeurs demandent généralement
Sous DORA Article 28, les auditeurs attendent des preuves dans cinq domaines :
- Inventaire des fournisseurs — liste complète des fournisseurs ICT tiers, classés par criticité, mappés aux composants CI/CD et cloud
- Clauses contractuelles — droits d’audit, SLA d’incidents, rétention des preuves, visibilité des sous-traitants, obligations de sortie
- Preuves de contrôle CI/CD — logs d’accès, enregistrements d’approbation, SBOM/provenance, définitions de politiques pipeline
- Preuves de surveillance — tableaux de bord, tickets d’incidents référençant les fournisseurs tiers, intégration SIEM
- Preuves de stratégie de sortie — plans de sortie documentés, résultats de tests DR/BCP, documentation de remplacement des dépendances
Les preuves doivent être :
- Traçables → liées à un fournisseur ou contrôle spécifique
- Reproductibles → générées de manière constante par les systèmes
- Temporellement bornées → montrant quand les contrôles étaient actifs
- Résistantes à la falsification → les logs et preuves sont protégés
Les tableurs manuels seuls satisfont rarement ces critères.
Lacunes courantes et schémas de désalignement
De nombreuses organisations échouent aux revues DORA Article 28 non pas parce que les contrôles manquent, mais parce que :
- les ingénieurs ont implémenté des contrôles sans support contractuel,
- les preuves existent mais ne sont pas clairement attribuables,
- les stratégies de sortie n’existent que sur papier,
- les dépendances tierces sont implicitement considérées comme fiables,
- les plateformes CI/CD SaaS sont exclues du périmètre fournisseurs,
- les logs sont disponibles mais pas conservés assez longtemps.
En séparant explicitement la vue auditeur et la vue ingénieur, vous assurez que :
- chaque contrôle est adossé à une base contractuelle,
- chaque application technique correspond à une piste de preuves auditable,
- la préparation à la sortie est validée, pas supposée.
Conclusion
L’architecture DORA Article 28 ne consiste pas à lister des outils — il s’agit de définir où réside le risque tiers ICT, comment il est contrôlé et comment la conformité est prouvée.
L’architecture doit soutenir à la fois le besoin de preuves de l’auditeur et le besoin de contrôles applicables et automatisés de l’ingénieur. Lorsque les deux vues sont alignées, la conformité Article 28 devient une propriété structurelle du système de livraison — pas un exercice périodique.
Ressources connexes
- DORA Article 28 — Pack de preuves (vues auditeur et ingénieur)
- DORA Article 28 — Checklist auditeur
- Risque tiers dans les pipelines CI/CD sous DORA Article 28
- Conformité continue via les pipelines CI/CD
