{"id":1468,"date":"2026-02-24T13:25:08","date_gmt":"2026-02-24T12:25:08","guid":{"rendered":"https:\/\/regulated-devsecops.com\/architecture-2\/"},"modified":"2026-03-26T07:04:04","modified_gmt":"2026-03-26T06:04:04","slug":"architecture","status":"publish","type":"page","link":"https:\/\/regulated-devsecops.com\/fr\/architecture\/","title":{"rendered":"Architecture"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\"><strong>Le CI\/CD comme syst\u00e8me r\u00e9glement\u00e9<\/strong><\/h2>\n\n\n\n<p>Dans les environnements r\u00e9glement\u00e9s, les pipelines CI\/CD ne sont pas de simples outils d&rsquo;automatisation.<br>Ce sont des <strong>syst\u00e8mes d&rsquo;application<\/strong>.<\/p>\n\n\n\n<p>L&rsquo;architecture d\u00e9termine si :<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Les contr\u00f4les de s\u00e9curit\u00e9 sont <strong>obligatoires<\/strong> ou optionnels<\/li>\n\n\n<li>Les politiques sont document\u00e9es ou <strong>appliqu\u00e9es<\/strong><\/li>\n\n\n<li>Evidence is manual or <strong>system-generated<\/strong><\/li>\n\n\n<li>Compliance is reactive or <strong>continuous<\/strong><\/li>\n<\/ul>\n\n\n\n<p>This is the foundational insight for auditors: <strong>architecture is where compliance becomes technical reality.<\/strong> A well-designed pipeline makes non-compliance structurally difficult. A poorly designed one makes it structurally inevitable.<\/p>\n\n\n\n<p><em>New to these concepts? See our <a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/\">Glossary<\/a> for plain-language definitions of CI\/CD terms.<\/em><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Why Architecture Comes First<\/strong><\/h2>\n\n\n\n<p>Before discussing tools, frameworks, or audits, one principle must be clear:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>If your architecture does not enforce controls, no checklist will save you.<\/p>\n<\/blockquote>\n\n\n\n<p>A secure CI\/CD architecture:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Emp\u00eache<\/strong> les changements non approuv\u00e9s en production \u2014 via le <a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/#rbac\">RBAC<\/a> obligatoire et les gates d&rsquo;approbation<\/li>\n\n\n<li><strong>Bloque<\/strong> automatiquement les violations de politique \u2014 via l&rsquo;application du <a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/#policy-as-code\">policy-as-code<\/a><\/li>\n\n\n<li><strong>G\u00e9n\u00e8re<\/strong> des journaux tra\u00e7ables \u2014 pour chaque ex\u00e9cution de pipeline, approbation et d\u00e9ploiement<\/li>\n\n\n<li><strong>Pr\u00e9serve<\/strong> les preuves pour les r\u00e9gulateurs \u2014 avec des enregistrements immuables et horodat\u00e9s<\/li>\n\n\n<li><strong>Soutient<\/strong> les exigences de sortie et de r\u00e9silience \u2014 essentielles pour <a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora\/\">DORA<\/a> et <a href=\"https:\/\/regulated-devsecops.com\/compliance\/nis2\/\">NIS2<\/a><\/li>\n<\/ul>\n\n\n\n<p>Les contr\u00f4les doivent \u00eatre int\u00e9gr\u00e9s <strong>dans<\/strong> le syst\u00e8me \u2014 pas superpos\u00e9s.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Ce que les auditeurs doivent \u00e9valuer dans l&rsquo;architecture CI\/CD<\/strong><\/h2>\n\n\n\n<p>Lors de l&rsquo;examen de l&rsquo;architecture CI\/CD, les auditeurs doivent \u00e9valuer cinq questions cl\u00e9s :<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th><strong>Question<\/strong><\/th><th><strong>Ce \u00e0 quoi ressemble une bonne pratique<\/strong><\/th><th><strong>Signal d&rsquo;alerte<\/strong><\/th><\/tr><\/thead><tbody><tr><td>Les \u00e9tapes de s\u00e9curit\u00e9 peuvent-elles \u00eatre ignor\u00e9es ?<\/td><td>Toutes les \u00e9tapes obligatoires ; aucun contournement sans exception gouvern\u00e9e<\/td><td>Les \u00e9tapes peuvent \u00eatre comment\u00e9es ou d\u00e9sactiv\u00e9es par les d\u00e9veloppeurs<\/td><\/tr><tr><td>Qui peut d\u00e9ployer en production ?<\/td><td>D\u00e9ploiement restreint \u00e0 des r\u00f4les sp\u00e9cifiques ; diff\u00e9rent des auteurs du code<\/td><td>Toute personne ayant acc\u00e8s au d\u00e9p\u00f4t peut d\u00e9clencher un d\u00e9ploiement en production<\/td><\/tr><tr><td>Les configurations de pipeline sont-elles prot\u00e9g\u00e9es ?<\/td><td>D\u00e9finitions de pipeline dans le contr\u00f4le de version avec approbation des changements<\/td><td>Configurations de pipeline modifiables sans revue ni piste d&rsquo;audit<\/td><\/tr><tr><td>Les preuves sont-elles g\u00e9n\u00e9r\u00e9es par le syst\u00e8me ?<\/td><td>Journaux, r\u00e9sultats de scan, enregistrements d&rsquo;approbation produits automatiquement<\/td><td>Preuves compil\u00e9es manuellement avant les audits<\/td><\/tr><tr><td>Les exceptions sont-elles tra\u00e7ables ?<\/td><td>Chaque contournement a une approbation document\u00e9e, une raison et une expiration<\/td><td>Aucun processus de gestion des exceptions ; suppressions non gouvern\u00e9es<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>Pour une approche d&rsquo;\u00e9valuation compl\u00e8te, consultez <a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/how-auditors-actually-review-ci-cd-pipelines\/\">Comment les auditeurs examinent r\u00e9ellement les pipelines CI\/CD<\/a>.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Core Architectural Domains<\/strong><\/h2>\n\n\n\n<p>Modern regulated CI\/CD architectures rely on four foundational domains. Each domain addresses a distinct control objective that auditors verify independently.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>1. Enforcement Layer<\/strong><\/h3>\n\n\n\n<p>The enforcement layer is the <strong>control engine<\/strong> of the pipeline. It determines whether security is advisory or mandatory.<\/p>\n\n\n\n<p>It ensures:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Mandatory approval workflows \u2014 no deployment without authorised review<\/li>\n\n\n<li>Blocking policy gates \u2014 critical <a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/#sast\">SAST<\/a>\/<a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/#dast\">DAST<\/a>\/<a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/#sca\">SCA<\/a> findings prevent release<\/li>\n\n\n<li>Secure build and <a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/#artifact\">artifact<\/a> validation \u2014 signed, verified, traceable<\/li>\n\n\n<li>Role-based deployment permissions \u2014 <a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/#segregation-of-duties\">segregation of duties<\/a> enforced by design<\/li>\n\n\n<li>Exception governance with audit trails \u2014 every override documented and time-limited<\/li>\n<\/ul>\n\n\n\n<p><strong>Without enforcement, CI\/CD becomes advisory. With enforcement, CI\/CD becomes regulated.<\/strong><\/p>\n\n\n\n<p><em>Auditor insight:<\/em> Ask to see a recent deployment that was <strong>blocked<\/strong> by a policy gate. If the organisation cannot produce one, enforcement may not be real.<\/p>\n\n\n\n<p>Deep dives:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/ci-cd-governance\/ci-cd-enforcement-layer\/\">CI\/CD Enforcement Layer<\/a><\/li>\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/ci-cd-governance\/ci-cd-based-enforcement-models\/\">CI\/CD-Based Enforcement Models<\/a><\/li>\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/ci-cd-governance\/core-ci-cd-security-controls\/\">Core CI\/CD Security Controls<\/a><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>2. Secure SDLC Integration<\/strong><\/h3>\n\n\n\n<p>Architecture must integrate security from plan to runtime \u2014 the <a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/#shift-left\">shift-left<\/a> principle embedded in pipeline design.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th><strong>SDLC Phase<\/strong><\/th><th><strong>Security Control<\/strong><\/th><th><strong>Evidence Produced<\/strong><\/th><\/tr><\/thead><tbody><tr><td>Plan<\/td><td>Threat modelling, security requirements<\/td><td>Threat model documents, security stories<\/td><\/tr><tr><td>Code<\/td><td><a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/#sast\">SAST<\/a>, secrets scanning, code review<\/td><td>Scan logs, review approval records<\/td><\/tr><tr><td>Build<\/td><td><a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/#sca\">SCA<\/a>, <a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/#sbom\">SBOM<\/a> generation, artifact signing<\/td><td>Dependency reports, SBOM files, signatures<\/td><\/tr><tr><td>Test<\/td><td><a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/#dast\">DAST<\/a>, penetration testing<\/td><td>DAST reports, test evidence<\/td><\/tr><tr><td>Release<\/td><td>Policy gate evaluation, approval workflows<\/td><td>Gate pass\/fail logs, approval records<\/td><\/tr><tr><td>Deploy<\/td><td>Configuration validation, environment parity<\/td><td>Deployment logs, config checksums<\/td><\/tr><tr><td>Monitor<\/td><td>Runtime protection, incident detection<\/td><td>Alert logs, incident records<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>Secure SDLC is not a compliance slogan \u2014 it is an <strong>architectural pattern<\/strong>.<\/p>\n\n\n\n<p>Deep dives:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/application-security-governance\/secure-sdlc-fundamentals\/\">Secure SDLC Fundamentals<\/a><\/li>\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/application-security-governance\/secure-sdlc-auditor-perspective\/\">Secure SDLC from the Auditor&rsquo;s Perspective<\/a><\/li>\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/how-auditors-assess-application-security-controls\/\">How Auditors Assess Application Security Controls<\/a><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>3. Continuous Compliance Model<\/strong><\/h3>\n\n\n\n<p>Regulated environments require compliance that is <strong>continuous, not periodic<\/strong>. The architecture must produce evidence automatically on every pipeline execution.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Repeatable control execution<\/strong> \u2014 same controls, every time, every pipeline<\/li>\n\n\n<li><strong>Evidence-by-design<\/strong> \u2014 logs, reports, and approval records generated as a byproduct of normal operations<\/li>\n\n\n<li><strong>Automated traceability<\/strong> \u2014 every deployment traceable to a specific commit, review, scan, and approval<\/li>\n\n\n<li><strong>Framework mapping<\/strong> \u2014 controls mapped to <a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora\/\">DORA<\/a>, <a href=\"https:\/\/regulated-devsecops.com\/compliance\/nis2\/\">NIS2<\/a>, <a href=\"https:\/\/regulated-devsecops.com\/compliance\/iso-27001\/\">ISO 27001<\/a>, <a href=\"https:\/\/regulated-devsecops.com\/compliance\/soc-2\/\">SOC 2<\/a>, <a href=\"https:\/\/regulated-devsecops.com\/compliance\/pci-dss\/\">PCI DSS<\/a><\/li>\n<\/ul>\n\n\n\n<p>A mature architecture produces compliance continuously \u2014 not quarterly.<\/p>\n\n\n\n<p>Deep dives:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/continuous-compliance-via-ci-cd\/\">Continuous Compliance via CI\/CD<\/a><\/li>\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/audit-evidence\/continuous-auditing-vs-point-in-time-audits\/\">Continuous Auditing vs Point-in-Time Audits<\/a><\/li>\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/dual-compliance-architecture-explained\/\">Dual-Compliance Architecture \u2014 Explained<\/a><\/li>\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/audit-evidence\/building-evidence-repository-continuous-compliance\/\">Building an Evidence Repository for Continuous Compliance<\/a><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>4. Security Domain Separation<\/strong><\/h3>\n\n\n\n<p>Confusion often arises between overlapping security domains. Clear architecture prevents duplication and control gaps.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th><strong>Domain<\/strong><\/th><th><strong>Focus<\/strong><\/th><th><strong>Key Concern for Auditors<\/strong><\/th><th><strong>Hub Page<\/strong><\/th><\/tr><\/thead><tbody><tr><td><strong>CI\/CD Governance<\/strong><\/td><td>Pipeline controls, enforcement, access<\/td><td>Are controls mandatory and non-bypassable?<\/td><td><a href=\"https:\/\/regulated-devsecops.com\/fr\/ci-cd-security\/\">Explore<\/a><\/td><\/tr><tr><td><strong>Application Security<\/strong><\/td><td>Code-level controls (SAST, DAST, SCA)<\/td><td>Is security testing integrated and enforced?<\/td><td><a href=\"https:\/\/regulated-devsecops.com\/fr\/application-security\/\">Explore<\/a><\/td><\/tr><tr><td><strong>DevSecOps<\/strong><\/td><td>Operating models, roles, governance<\/td><td>Who owns security? How are decisions escalated?<\/td><td><a href=\"https:\/\/regulated-devsecops.com\/fr\/devsecops\/\">Explore<\/a><\/td><\/tr><tr><td><strong>Regulatory Frameworks<\/strong><\/td><td>Compliance mapping and assurance<\/td><td>Do controls satisfy regulatory requirements?<\/td><td><a href=\"https:\/\/regulated-devsecops.com\/fr\/compliance\/\">Explore<\/a><\/td><\/tr><tr><td><strong>Audit &amp; Evidence<\/strong><\/td><td>Evidence validation, assessment<\/td><td>Is evidence trustworthy, complete, and retained?<\/td><td><a href=\"https:\/\/regulated-devsecops.com\/fr\/audit-governance\/\">Explore<\/a><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>Understanding these domains prevents duplication and control gaps. Architecture ensures each domain has clear boundaries and responsibilities.<\/p>\n\n\n\n<p>Deep dive: <a href=\"https:\/\/regulated-devsecops.com\/fr\/resources\/security-domains-explained\/\">Security Domains Explained<\/a><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Architectural Maturity Model<\/strong><\/h2>\n\n\n\n<p>Regulated CI\/CD systems typically evolve across four stages. Auditors can use this model to quickly assess an organisation&rsquo;s maturity level.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th><strong>Level<\/strong><\/th><th><strong>Name<\/strong><\/th><th><strong>Characteristics<\/strong><\/th><th><strong>Regulatory Readiness<\/strong><\/th><\/tr><\/thead><tbody><tr><td>1<\/td><td><strong>Automation<\/strong><\/td><td>Pipelines automate builds and deployments. Controls are optional. No evidence generation.<\/td><td>Not audit-ready. Significant gaps across all frameworks.<\/td><\/tr><tr><td>2<\/td><td><strong>Security Integration<\/strong><\/td><td>Security tools integrated (SAST\/DAST\/SCA). Results advisory, not blocking. Some logging.<\/td><td>Partially compliant. Evidence exists but enforcement is inconsistent.<\/td><\/tr><tr><td>3<\/td><td><strong>Enforced Controls<\/strong><\/td><td>Critical controls block non-compliant releases. Segregation of duties. Systematic evidence.<\/td><td>Audit-ready for most frameworks. Meets DORA\/NIS2\/ISO 27001 minimums.<\/td><\/tr><tr><td>4<\/td><td><strong>Regulated System<\/strong><\/td><td>Full traceability. Policy-as-code. Continuous compliance. Exit readiness. Predictive risk.<\/td><td>Exceeds requirements. Continuous assurance model.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p><strong>Regulated environments must operate at Level 3 or higher.<\/strong> Most regulatory frameworks (DORA, NIS2, ISO 27001) effectively require Level 3 as a minimum for certification or compliance.<\/p>\n\n\n\n<p>For a structured self-assessment tool, see the <a href=\"https:\/\/regulated-devsecops.com\/fr\/audit-evidence\/devsecops-maturity-assessment-framework\/\">DevSecOps Maturity Assessment Framework<\/a>.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Architecture vs Tooling<\/strong><\/h2>\n\n\n\n<p><strong>Tools do not create architecture.<\/strong> Architecture defines how tools are governed.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th><strong>Architecture Decides<\/strong><\/th><th><strong>Tools Implement<\/strong><\/th><\/tr><\/thead><tbody><tr><td>Which controls are mandatory<\/td><td>How scans are executed<\/td><\/tr><tr><td>Where enforcement occurs in the pipeline<\/td><td>Which vulnerabilities are detected<\/td><\/tr><tr><td>Which failures block releases<\/td><td>How results are reported<\/td><\/tr><tr><td>How evidence is retained and protected<\/td><td>Where logs are stored<\/td><\/tr><tr><td>Who can override policies<\/td><td>How exceptions are technically processed<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>A strong architecture can change tools without losing control. A weak architecture depends entirely on vendor defaults.<\/p>\n\n\n\n<p>For auditor guidance on tool governance, see <a href=\"https:\/\/regulated-devsecops.com\/fr\/ci-cd-governance\/ci-cd-security-tooling-overview\/\">CI\/CD Security Tooling \u2014 Auditor&rsquo;s Guide to Tool Categories and Controls<\/a>.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Architecture &amp; Regulatory Alignment<\/strong><\/h2>\n\n\n\n<p>A well-designed CI\/CD architecture supports multiple regulatory frameworks simultaneously. Rather than adapting architecture per regulation, <strong>design architecture once \u2014 map controls many times<\/strong>.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th><strong>Framework<\/strong><\/th><th><strong>Architectural Requirement<\/strong><\/th><th><strong>Key Articles\/Controls<\/strong><\/th><th><strong>Deep Dive<\/strong><\/th><\/tr><\/thead><tbody><tr><td><strong><a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora\/\">DORA<\/a><\/strong><\/td><td>ICT risk management, third-party control, resilience testing<\/td><td>Art. 9, 21, 28<\/td><td><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/dora-article-21-deep-dive-enforcing-ict-risk-controls-via-ci-cd\/\">Art. 21 Deep Dive<\/a><\/td><\/tr><tr><td><strong><a href=\"https:\/\/regulated-devsecops.com\/compliance\/nis2\/\">NIS2<\/a><\/strong><\/td><td>Supply chain security, incident readiness, risk management<\/td><td>Art. 21<\/td><td><a href=\"https:\/\/regulated-devsecops.com\/fr\/ci-cd-governance\/nis2-article-21-ci-cd-controls-mapping\/\">Art. 21 Controls Mapping<\/a><\/td><\/tr><tr><td><strong><a href=\"https:\/\/regulated-devsecops.com\/compliance\/iso-27001\/\">ISO 27001<\/a><\/strong><\/td><td>Change management, access control, secure development<\/td><td>A.8.25, A.8.28, A.8.29<\/td><td><a href=\"https:\/\/regulated-devsecops.com\/fr\/ci-cd-governance\/iso-27001-annex-a-controls-mapped-to-ci-cd-pipelines\/\">Annex A Mapping<\/a><\/td><\/tr><tr><td><strong><a href=\"https:\/\/regulated-devsecops.com\/compliance\/soc-2\/\">SOC 2<\/a><\/strong><\/td><td>Logical access, system operations, change management<\/td><td>CC6, CC7, CC8<\/td><td><a href=\"https:\/\/regulated-devsecops.com\/fr\/ci-cd-governance\/soc-2-trust-service-criteria-mapped-to-pipeline-controls\/\">TSC Mapping<\/a><\/td><\/tr><tr><td><strong><a href=\"https:\/\/regulated-devsecops.com\/compliance\/pci-dss\/\">PCI DSS<\/a><\/strong><\/td><td>Secure development, access control, logging, testing<\/td><td>Req. 6, 7, 8, 10, 11<\/td><td><a href=\"https:\/\/regulated-devsecops.com\/fr\/ci-cd-governance\/pci-dss-v4-0-software-delivery-requirements-requirement-6-deep-dive\/\">Req. 6 Deep Dive<\/a><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>For cross-framework analysis, see the <a href=\"https:\/\/regulated-devsecops.com\/fr\/cross-regulation-comparisons\/iso-27001-vs-dora-vs-nis2-controls-overlap-matrix\/\">ISO 27001 vs DORA vs NIS2 Controls Overlap Matrix<\/a>.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Related Architecture Deep Dives<\/strong><\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/ci-cd-governance\/ci-cd-only-architecture-pipeline-evidence-approvals\/\">CI\/CD Only Architecture \u2014 Pipeline, Evidence &amp; Approvals<\/a><\/li>\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/ci-cd-governance\/ci-cd-enforcement-layer\/\">CI\/CD Enforcement Layer<\/a><\/li>\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/ci-cd-governance\/ci-cd-based-enforcement-models\/\">CI\/CD-Based Enforcement Models<\/a><\/li>\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/continuous-compliance-via-ci-cd\/\">Continuous Compliance via CI\/CD<\/a><\/li>\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/application-security-governance\/secure-sdlc-fundamentals\/\">Secure SDLC Fundamentals<\/a><\/li>\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/ci-cd-governance\/core-ci-cd-security-controls\/\">Core CI\/CD Security Controls<\/a><\/li>\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/dora-compliance-architecture-ci-cd-as-a-regulated-ict-system\/\">DORA Compliance Architecture \u2014 CI\/CD as a Regulated ICT System<\/a><\/li>\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/nis2-security-architecture-explained\/\">NIS2 Security Architecture Explained<\/a><\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Final Principle<\/strong><\/h2>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>In regulated environments, delivery speed and control are not opposites. The right architecture makes them compatible.<\/p>\n<\/blockquote>\n\n\n\n<p>If your pipeline is not designed as a control system, compliance will always be reactive. If your architecture enforces policy by design, compliance becomes continuous.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Related for Auditors<\/strong><\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/glossary\/\">Glossary<\/a> \u2014 Plain-language definitions of technical terms<\/li>\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/regulatory-frameworks\/how-auditors-actually-review-ci-cd-pipelines\/\">How Auditors Actually Review CI\/CD Pipelines<\/a><\/li>\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/audit-evidence\/common-audit-findings-ci-cd-top-10-failures\/\">Common Audit Findings \u2014 Top 10 CI\/CD Failures<\/a><\/li>\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/fr\/audit-evidence\/devsecops-maturity-assessment-framework\/\">DevSecOps Maturity Assessment Framework<\/a><\/li>\n<\/ul>\n\n\n\n<p><em>New to CI\/CD auditing? Start with our <a href=\"https:\/\/regulated-devsecops.com\/fr\/start-here\/\">Auditor&rsquo;s Guide<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Le CI\/CD comme syst\u00e8me r\u00e9glement\u00e9 Dans les environnements r\u00e9glement\u00e9s, les pipelines CI\/CD ne sont pas de simples outils d&rsquo;automatisation.Ce sont des syst\u00e8mes d&rsquo;application. L&rsquo;architecture d\u00e9termine si : This is the foundational insight for auditors: architecture is where compliance becomes technical reality. A well-designed pipeline makes non-compliance structurally difficult. A poorly designed one makes it structurally &#8230; <a title=\"Architecture\" class=\"read-more\" href=\"https:\/\/regulated-devsecops.com\/fr\/architecture\/\" aria-label=\"En savoir plus sur Architecture\">Lire la suite<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-1468","page","type-page","status-publish"],"_links":{"self":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/pages\/1468","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/comments?post=1468"}],"version-history":[{"count":0,"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/pages\/1468\/revisions"}],"wp:attachment":[{"href":"https:\/\/regulated-devsecops.com\/fr\/wp-json\/wp\/v2\/media?parent=1468"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}