{"id":1237,"date":"2026-01-21T07:39:09","date_gmt":"2026-01-21T06:39:09","guid":{"rendered":"https:\/\/regulated-devsecops.com\/uncategorized\/ci-cd-based-enforcement-models-2\/"},"modified":"2026-07-07T10:54:04","modified_gmt":"2026-07-07T09:54:04","slug":"ci-cd-based-enforcement-models","status":"publish","type":"post","link":"https:\/\/regulated-devsecops.com\/fr\/ci-cd-governance\/ci-cd-based-enforcement-models\/","title":{"rendered":"Mise en application par le CI\/CD \u2014 mod\u00e8les, couche d’enforcement et \u00e9valuation par les auditeurs"},"content":{"rendered":"\n

Pourquoi l’application compte plus que l’intention dans les environnements r\u00e9glement\u00e9s<\/strong><\/h2>\n\n\n\n

Dans de nombreuses organisations, les politiques de s\u00e9curit\u00e9 existent sur le papier mais \u00e9chouent en pratique. Les contr\u00f4les sont document\u00e9s, les standards sont publi\u00e9s et les attentes sont d\u00e9finies \u2014 pourtant des changements non s\u00e9curis\u00e9s atteignent encore la production.<\/p>\n\n\n\n

Dans les environnements r\u00e9glement\u00e9s, cet \u00e9cart entre l’intention de la politique<\/strong> et la r\u00e9alit\u00e9 op\u00e9rationnelle<\/strong> est inacceptable. La conformit\u00e9 ne s’obtient pas par la seule documentation ; elle s’obtient par l’application<\/strong>.<\/p>\n\n\n\n

Les auditeurs n’\u00e9valuent pas ce que les organisations ont l’intention<\/em> de faire.
Ils \u00e9valuent ce que les syst\u00e8mes appliquent r\u00e9ellement<\/strong>.<\/p>\n\n\n\n

C’est l\u00e0 que l’application par le CI\/CD<\/strong> devient critique. Plut\u00f4t que de s’appuyer sur des revues manuelles, des processus informels ou une conformit\u00e9 au mieux des efforts, les pipelines CI\/CD agissent comme des m\u00e9canismes d’application d\u00e9terministes<\/strong> qui rendent les contr\u00f4les de s\u00e9curit\u00e9 obligatoires, coh\u00e9rents et auditables.<\/p>\n\n\n\n

Cet article r\u00e9unit trois perspectives connexes sur cette id\u00e9e. Il commence par les mod\u00e8les d’application<\/strong> que les organisations adoptent, examine ensuite la couche d’application<\/strong> qui met en \u0153uvre ces mod\u00e8les \u00e0 l’int\u00e9rieur du pipeline, et explique enfin comment les auditeurs \u00e9valuent<\/strong> si cette application est r\u00e9elle. Ensemble, elles d\u00e9crivent comment un pipeline de livraison devient un syst\u00e8me de contr\u00f4le fiable et producteur de preuves.<\/p>\n\n\n\n

\n\n\n\n

Qu’est-ce qu’un mod\u00e8le d’application fond\u00e9 sur le CI\/CD ?<\/strong><\/h2>\n\n\n\n

Un mod\u00e8le d’application fond\u00e9 sur le CI\/CD est une approche architecturale o\u00f9 les contr\u00f4les de s\u00e9curit\u00e9, de conformit\u00e9 et de gouvernance sont appliqu\u00e9s directement par le pipeline CI\/CD<\/strong>, et non par des individus ou des revues en aval.<\/p>\n\n\n\n

Dans ce mod\u00e8le :<\/p>\n\n\n\n

    \n
  • Tous les changements en production doivent passer par le pipeline<\/li>\n\n\n\n
  • Les contr\u00f4les de s\u00e9curit\u00e9 sont obligatoires et non contournables<\/li>\n\n\n\n
  • Les d\u00e9cisions de politique sont automatis\u00e9es et journalis\u00e9es<\/li>\n\n\n\n
  • Les approbations et les exceptions sont explicitement enregistr\u00e9es<\/li>\n<\/ul>\n\n\n\n

    Le pipeline lui-m\u00eame devient un syst\u00e8me de contr\u00f4le r\u00e9glement\u00e9<\/strong>, et non un simple outil de livraison.<\/p>\n\n\n\n

    \n\n\n\n

    Des contr\u00f4les consultatifs aux contr\u00f4les appliqu\u00e9s<\/strong><\/h2>\n\n\n\n

    Les mod\u00e8les de s\u00e9curit\u00e9 traditionnels s’appuient souvent sur des m\u00e9canismes consultatifs :<\/p>\n\n\n\n

      \n
    • Des scans de s\u00e9curit\u00e9 qui g\u00e9n\u00e8rent des rapports mais ne bloquent pas les livraisons<\/li>\n\n\n\n
    • Des directives que les d\u00e9veloppeurs peuvent suivre ou non<\/li>\n\n\n\n
    • Des approbations manuelles qui peuvent \u00eatre b\u00e2cl\u00e9es ou saut\u00e9es<\/li>\n\n\n\n
    • Des revues apr\u00e8s d\u00e9ploiement<\/li>\n<\/ul>\n\n\n\n

      L’application par le CI\/CD remplace les contr\u00f4les consultatifs par une application stricte<\/strong>.<\/p>\n\n\n\n

      Si un contr\u00f4le \u00e9choue, le pipeline \u00e9choue.
      S’il manque une preuve, la livraison ne se poursuit pas.
      Si les approbations sont absentes, le d\u00e9ploiement est bloqu\u00e9.<\/p>\n\n\n\n

      Ce basculement est fondamental dans les contextes r\u00e9glement\u00e9s.<\/p>\n\n\n\n

      \n\n\n\n

      Principes fondamentaux de l’application par le CI\/CD<\/strong><\/h2>\n\n\n\n

      1. Le pipeline comme unique voie vers la production<\/strong><\/h3>\n\n\n\n

      Un principe fondateur est qu’aucun changement en production ne contourne le pipeline CI\/CD<\/strong>.<\/p>\n\n\n\n

      Cela inclut :<\/p>\n\n\n\n

        \n
      • Le code applicatif<\/li>\n\n\n\n
      • L’infrastructure as code<\/li>\n\n\n\n
      • Les changements de configuration<\/li>\n\n\n\n
      • Les mises \u00e0 jour de d\u00e9pendances<\/li>\n\n\n\n
      • Les politiques d’ex\u00e9cution<\/li>\n<\/ul>\n\n\n\n

        L’acc\u00e8s direct aux syst\u00e8mes de production est restreint ou \u00e9limin\u00e9. Le pipeline devient l’unique m\u00e9canisme de changement autoris\u00e9<\/strong>.<\/p>\n\n\n\n

        \n\n\n\n

        2. Le policy-as-code au lieu des documents de politique<\/strong><\/h3>\n\n\n\n

        Les politiques exprim\u00e9es uniquement dans des documents sont difficiles \u00e0 appliquer de mani\u00e8re coh\u00e9rente.<\/p>\n\n\n\n

        Les mod\u00e8les fond\u00e9s sur le CI\/CD s’appuient sur le policy-as-code<\/strong>, o\u00f9 les r\u00e8gles sont :<\/p>\n\n\n\n

          \n
        • Lisibles par la machine<\/li>\n\n\n\n
        • Versionn\u00e9es<\/li>\n\n\n\n
        • Test\u00e9es<\/li>\n\n\n\n
        • Ex\u00e9cut\u00e9es automatiquement<\/li>\n<\/ul>\n\n\n\n

          Les exemples incluent :<\/p>\n\n\n\n

            \n
          • Des seuils de s\u00e9curit\u00e9 pour les constats SAST ou DAST<\/li>\n\n\n\n
          • Des listes d’autorisation de licences de d\u00e9pendances<\/li>\n\n\n\n
          • La g\u00e9n\u00e9ration obligatoire de SBOM<\/li>\n\n\n\n
          • Des exigences d’approbation des changements<\/li>\n<\/ul>\n\n\n\n

            Cela garantit que les politiques sont appliqu\u00e9es uniform\u00e9ment \u00e0 travers les \u00e9quipes et les projets.<\/p>\n\n\n\n

            \n\n\n\n

            3. Des contr\u00f4les de s\u00e9curit\u00e9 obligatoires \u00e0 des \u00e9tapes d\u00e9finies<\/strong><\/h3>\n\n\n\n

            Les contr\u00f4les de s\u00e9curit\u00e9 sont int\u00e9gr\u00e9s \u00e0 des \u00e9tapes sp\u00e9cifiques du pipeline :<\/p>\n\n\n\n

              \n
            • Code<\/strong> : SAST, d\u00e9tection des secrets, protection des branches<\/li>\n\n\n\n
            • Build<\/strong> : analyse des d\u00e9pendances, SBOM, signature des artefacts<\/li>\n\n\n\n
            • Test<\/strong> : DAST, IAST, v\u00e9rifications de validation<\/li>\n\n\n\n
            • Livraison<\/strong> : portes d’approbation, application du contr\u00f4le des changements<\/li>\n\n\n\n
            • D\u00e9ploiement<\/strong> : chemins de d\u00e9ploiement prot\u00e9g\u00e9s<\/li>\n\n\n\n
            • Ex\u00e9cution<\/strong> : int\u00e9gration de la s\u00e9curit\u00e9 \u00e0 l’ex\u00e9cution et points d’ancrage de surveillance<\/li>\n<\/ul>\n\n\n\n

              Les contr\u00f4les ne sont ni optionnels ni conditionn\u00e9s \u00e0 la maturit\u00e9 de l’\u00e9quipe. Ils font partie du contrat du pipeline.<\/p>\n\n\n\n

              \n\n\n\n

              4. Approbations explicites et s\u00e9paration des t\u00e2ches<\/strong><\/h3>\n\n\n\n

              Les environnements r\u00e9glement\u00e9s exigent une s\u00e9paration claire entre les r\u00f4les<\/strong>.<\/p>\n\n\n\n

              Les mod\u00e8les d’application fond\u00e9s sur le CI\/CD mettent en \u0153uvre :<\/p>\n\n\n\n

                \n
              • Des approbations bas\u00e9es sur les r\u00f4les<\/li>\n\n\n\n
              • Une s\u00e9paration entre l’autorit\u00e9 de d\u00e9veloppement et l’autorit\u00e9 de livraison<\/li>\n\n\n\n
              • Un double contr\u00f4le pour les changements \u00e0 haut risque<\/li>\n\n\n\n
              • Des flux d’approbation int\u00e9gr\u00e9s au pipeline<\/li>\n<\/ul>\n\n\n\n

                Les approbations sont explicites, journalis\u00e9es et reli\u00e9es au changement sp\u00e9cifique en cours de livraison. Cela remplace les validations informelles par des points de d\u00e9cision auditables<\/strong>.<\/p>\n\n\n\n

                \n\n\n\n

                5. G\u00e9n\u00e9ration de preuves par conception<\/strong><\/h3>\n\n\n\n

                Un avantage critique de l’application par le CI\/CD est la g\u00e9n\u00e9ration automatique de preuves<\/strong>.<\/p>\n\n\n\n

                Chaque ex\u00e9cution du pipeline produit :<\/p>\n\n\n\n

                  \n
                • Des journaux des contr\u00f4les ex\u00e9cut\u00e9s<\/li>\n\n\n\n
                • Des r\u00e9sultats de scan et des d\u00e9cisions de politique<\/li>\n\n\n\n
                • Des enregistrements d’approbation<\/li>\n\n\n\n
                • La provenance et la tra\u00e7abilit\u00e9 des artefacts<\/li>\n<\/ul>\n\n\n\n

                  Les preuves sont g\u00e9n\u00e9r\u00e9es par le syst\u00e8me, horodat\u00e9es, r\u00e9sistantes \u00e0 l’alt\u00e9ration et format\u00e9es de mani\u00e8re coh\u00e9rente. Cela r\u00e9duit consid\u00e9rablement l’effort requis lors des audits.<\/p>\n\n\n\n

                  \n\n\n\n

                  Mod\u00e8les d’application CI\/CD courants<\/strong><\/h2>\n\n\n\n

                  Les principes ci-dessus peuvent \u00eatre organis\u00e9s de diff\u00e9rentes mani\u00e8res selon la taille, la structure et le profil de risque de l’organisation. Trois mod\u00e8les d’application sont courants.<\/p>\n\n\n\n

                  Mod\u00e8le d’application centralis\u00e9<\/strong><\/h3>\n\n\n\n

                  Dans ce mod\u00e8le, les contr\u00f4les de s\u00e9curit\u00e9 et de conformit\u00e9 sont d\u00e9finis de mani\u00e8re centralis\u00e9e et appliqu\u00e9s \u00e0 travers tous les pipelines.<\/p>\n\n\n\n

                  Caract\u00e9ristiques :<\/p>\n\n\n\n

                    \n
                  • Des mod\u00e8les de pipeline partag\u00e9s<\/li>\n\n\n\n
                  • Des d\u00e9p\u00f4ts de politiques centraux<\/li>\n\n\n\n
                  • Une application coh\u00e9rente \u00e0 travers les \u00e9quipes<\/li>\n<\/ul>\n\n\n\n

                    Ce mod\u00e8le offre une forte coh\u00e9rence mais exige une gouvernance de plateforme mature.<\/p>\n\n\n\n

                    \n\n\n\n

                    Mod\u00e8le d’application f\u00e9d\u00e9r\u00e9<\/strong><\/h3>\n\n\n\n

                    Les \u00e9quipes conservent une certaine autonomie tout en respectant des contr\u00f4les minimaux d\u00e9finis de mani\u00e8re centralis\u00e9e.<\/p>\n\n\n\n

                    Caract\u00e9ristiques :<\/p>\n\n\n\n

                      \n
                    • Des contr\u00f4les de base obligatoires<\/li>\n\n\n\n
                    • Des extensions sp\u00e9cifiques aux \u00e9quipes<\/li>\n\n\n\n
                    • Une visibilit\u00e9 et un reporting centralis\u00e9s<\/li>\n<\/ul>\n\n\n\n

                      Ce mod\u00e8le \u00e9quilibre l’\u00e9volutivit\u00e9 et le contr\u00f4le dans les grandes organisations.<\/p>\n\n\n\n

                      \n\n\n\n

                      Mod\u00e8le d’application fond\u00e9 sur le risque<\/strong><\/h3>\n\n\n\n

                      Les contr\u00f4les et les exigences d’approbation varient selon la classification du risque.<\/p>\n\n\n\n

                      Exemples :<\/p>\n\n\n\n

                        \n
                      • Des portes plus strictes pour les changements en production<\/li>\n\n\n\n
                      • Des contr\u00f4les plus l\u00e9gers pour les environnements \u00e0 faible risque<\/li>\n\n\n\n
                      • Des flux d’acceptation explicite du risque<\/li>\n<\/ul>\n\n\n\n

                        Les mod\u00e8les fond\u00e9s sur le risque exigent une gouvernance forte pour \u00e9viter les abus.<\/p>\n\n\n\n

                        \n\n\n\n

                        L’application par le CI\/CD et les attentes r\u00e9glementaires<\/strong><\/h2>\n\n\n\n

                        Du point de vue de l’audit, l’application par le CI\/CD soutient directement des exigences telles que :<\/p>\n\n\n\n

                          \n
                        • La tra\u00e7abilit\u00e9 des changements<\/li>\n\n\n\n
                        • Des processus de d\u00e9ploiement contr\u00f4l\u00e9s<\/li>\n\n\n\n
                        • La preuve des tests de s\u00e9curit\u00e9<\/li>\n\n\n\n
                        • Une s\u00e9paration des t\u00e2ches d\u00e9montrable<\/li>\n\n\n\n
                        • Des contr\u00f4les reproductibles et coh\u00e9rents<\/li>\n<\/ul>\n\n\n\n

                          Les auditeurs examinent g\u00e9n\u00e9ralement les d\u00e9finitions de pipeline, les journaux d’ex\u00e9cution, les enregistrements d’approbation et les m\u00e9canismes de gestion des exceptions. Le pipeline lui-m\u00eame devient un artefact d’audit principal<\/strong>.<\/p>\n\n\n\n

                          \n\n\n\n

                          Ce que l’application par le CI\/CD n’est pas<\/strong><\/h2>\n\n\n\n

                          Il est important de clarifier ce que l’application par le CI\/CD ne signifie pas<\/em> :<\/p>\n\n\n\n

                            \n
                          • Elle n’\u00e9limine pas le besoin d’\u00e9quipes de s\u00e9curit\u00e9<\/li>\n\n\n\n
                          • Elle ne remplace pas la gouvernance ni la gestion des risques<\/li>\n\n\n\n
                          • Elle ne garantit pas l’absence totale de vuln\u00e9rabilit\u00e9s<\/li>\n<\/ul>\n\n\n\n

                            Elle garantit plut\u00f4t que les contr\u00f4les sont appliqu\u00e9s de mani\u00e8re coh\u00e9rente et visible<\/strong>, quelles que soient la pression sur l’\u00e9quipe ou les d\u00e9lais de livraison.<\/p>\n\n\n\n

                            \n\n\n\n

                            Pourquoi l’application par le CI\/CD est une capacit\u00e9 strat\u00e9gique<\/strong><\/h2>\n\n\n\n

                            Les organisations qui adoptent des mod\u00e8les d’application fond\u00e9s sur le CI\/CD obtiennent :<\/p>\n\n\n\n

                              \n
                            • Des r\u00e9sultats de s\u00e9curit\u00e9 pr\u00e9visibles<\/li>\n\n\n\n
                            • Des audits plus rapides et plus fluides<\/li>\n\n\n\n
                            • Une d\u00e9pendance r\u00e9duite aux revues manuelles<\/li>\n\n\n\n
                            • Un meilleur alignement entre l’ing\u00e9nierie et la conformit\u00e9<\/li>\n<\/ul>\n\n\n\n

                              Dans les environnements r\u00e9glement\u00e9s, l’application par le CI\/CD n’est pas une am\u00e9lioration de maturit\u00e9 \u2014 c’est une exigence fondamentale<\/strong> pour une livraison logicielle durable. Mais un mod\u00e8le n’a d’importance que s’il est r\u00e9ellement mis en \u0153uvre dans le pipeline. Cette mise en \u0153uvre, c’est la couche d’application<\/strong>.<\/p>\n\n\n\n

                              \n\n\n\n

                              La couche d’application CI\/CD<\/strong><\/h2>\n\n\n\n

                              Un mod\u00e8le d’application d\u00e9crit ce qui<\/em> doit \u00eatre contr\u00f4l\u00e9. La couche d’application CI\/CD<\/strong> est le moteur de contr\u00f4le technique qui le rend possible \u2014 l’ensemble des portes, moteurs de politiques, restrictions bas\u00e9es sur les r\u00f4les, m\u00e9canismes de blocage et flux de preuves int\u00e9gr\u00e9s directement dans le pipeline. Sans cette couche, le CI\/CD reste un outil de livraison. Avec elle, le mod\u00e8le devient une r\u00e9alit\u00e9 op\u00e9rationnelle.<\/p>\n\n\n\n

                              La question \u00e0 laquelle la couche d’application doit r\u00e9pondre<\/strong><\/h3>\n\n\n\n

                              La couche d’application r\u00e9pond \u00e0 une question unique et d\u00e9cisive :<\/p>\n\n\n\n

                              \n

                              Qu’est-ce qui emp\u00eache techniquement un changement non conforme d’atteindre la production ?<\/p>\n<\/blockquote>\n\n\n\n

                              Si la r\u00e9ponse est \u00ab revue manuelle \u00bb ou \u00ab document de politique \u00bb, l’application est faible. Si la r\u00e9ponse est \u00ab le pipeline bloque le d\u00e9ploiement \u00bb, l’application est syst\u00e9mique.<\/p>\n\n\n\n

                              Pourquoi l’application doit \u00eatre technique<\/strong><\/h3>\n\n\n\n

                              Dans les environnements r\u00e9glement\u00e9s, les contr\u00f4les doivent \u00eatre d\u00e9terministes, reproductibles, r\u00e9sistants \u00e0 l’alt\u00e9ration, journalis\u00e9s et testables. L’application manuelle \u00e9choue \u00e0 ces tests car elle est incoh\u00e9rente, ne peut pas passer \u00e0 l’\u00e9chelle, cr\u00e9e de l’ambigu\u00eft\u00e9 \u00e0 l’audit et introduit un biais humain. C’est l’application technique qui assure la coh\u00e9rence \u00e0 chaque d\u00e9ploiement.<\/p>\n\n\n\n

                              \n\n\n\n

                              Composants fondamentaux de la couche d’application<\/strong><\/h3>\n\n\n\n

                              Une couche d’application CI\/CD mature est construite \u00e0 partir de cinq domaines de contr\u00f4le. Chacun transforme un principe des mod\u00e8les ci-dessus en un m\u00e9canisme op\u00e9rationnel, producteur de preuves.<\/p>\n\n\n\n

                              1. Acc\u00e8s et s\u00e9paration des t\u00e2ches<\/strong><\/h3>\n\n\n\n

                              La couche d’application contr\u00f4le qui peut d\u00e9clencher les pipelines, qui peut approuver les livraisons, qui peut passer outre les politiques et qui peut d\u00e9ployer en production.<\/p>\n\n\n\n

                              M\u00e9canismes cl\u00e9s :<\/p>\n\n\n\n

                                \n
                              • Contr\u00f4le d’acc\u00e8s bas\u00e9 sur les r\u00f4les (RBAC)<\/li>\n\n\n\n
                              • Approbations multipartites obligatoires<\/li>\n\n\n\n
                              • Autorisations de contournement restreintes<\/li>\n\n\n\n
                              • \u00c9l\u00e9vation de privil\u00e8ges journalis\u00e9e<\/li>\n<\/ul>\n\n\n\n

                                Point crucial : la s\u00e9paration des t\u00e2ches est mise en \u0153uvre dans la conception des flux de travail \u2014 et non dans la seule politique RH.<\/p>\n\n\n\n

                                \n\n\n\n

                                2. Portes de politique<\/strong><\/h3>\n\n\n\n

                                Les portes de politique bloquent la progression lorsque des contr\u00f4les \u00e9chouent. Les exemples incluent des constats SAST au-dessus d’un seuil de gravit\u00e9, des vuln\u00e9rabilit\u00e9s de d\u00e9pendances d\u00e9passant l’app\u00e9tence au risque, une g\u00e9n\u00e9ration de SBOM manquante, une signature d’artefact en \u00e9chec et des flux d’approbation incomplets.<\/p>\n\n\n\n

                                Une porte de politique doit \u00eatre automatique, bloquante, journalis\u00e9e et capable de prendre en charge des flux d’exception contr\u00f4l\u00e9s. Si les contr\u00f4les peuvent \u00eatre ignor\u00e9s sans journalisation, l’application est incompl\u00e8te.<\/p>\n\n\n\n

                                \n\n\n\n

                                3. Ex\u00e9cution des contr\u00f4les de s\u00e9curit\u00e9<\/strong><\/h3>\n\n\n\n

                                La couche d’application orchestre les contr\u00f4les de s\u00e9curit\u00e9 eux-m\u00eames :<\/p>\n\n\n\n

                                  \n
                                • Analyse statique (SAST)<\/li>\n\n\n\n
                                • Analyse dynamique (DAST)<\/li>\n\n\n\n
                                • Analyse des d\u00e9pendances (SCA)<\/li>\n\n\n\n
                                • Analyse des conteneurs<\/li>\n\n\n\n
                                • Validation de l’infrastructure as code<\/li>\n<\/ul>\n\n\n\n

                                  Il y a ici une distinction critique : les outils seuls ne constituent pas une application. La couche d’application est ce qui d\u00e9termine si leurs r\u00e9sultats sont consultatifs ou bloquants.<\/p>\n\n\n\n

                                  \n\n\n\n

                                  4. Gouvernance des exceptions<\/strong><\/h3>\n\n\n\n

                                  Les environnements r\u00e9glement\u00e9s exigent de la flexibilit\u00e9 \u2014 mais une flexibilit\u00e9 gouvern\u00e9e. La couche d’application doit prendre en charge les exceptions temporaires, les contournements fond\u00e9s sur le risque, les dates d’expiration des approbations, la documentation obligatoire et une approbation secondaire pour les contournements.<\/p>\n\n\n\n

                                  Toutes les exceptions doivent g\u00e9n\u00e9rer des enregistrements auditables. Les contournements non contr\u00f4l\u00e9s figurent parmi les constats d’audit les plus courants.<\/p>\n\n\n\n

                                  \n\n\n\n

                                  5. G\u00e9n\u00e9ration et conservation des preuves<\/strong><\/h3>\n\n\n\n

                                  Chaque d\u00e9cision d’application doit produire une preuve : journaux horodat\u00e9s, enregistrements d’approbation, r\u00e9sultats d’\u00e9valuation des politiques, identifiants de tra\u00e7abilit\u00e9 et confirmation de d\u00e9ploiement.<\/p>\n\n\n\n

                                  Cette preuve doit \u00eatre immuable, conserv\u00e9e, corr\u00e9lable et accessible pour l’audit. Une application sans preuve n’est pas auditable.<\/p>\n\n\n\n

                                  \n\n\n\n

                                  O\u00f9 se situe la couche d’application<\/strong><\/h3>\n\n\n\n

                                  La couche d’application s’\u00e9tend g\u00e9n\u00e9ralement sur toute la cha\u00eene de livraison \u2014 code source, build, test, livraison et d\u00e9ploiement. Elle intercepte chaque \u00e9tape et d\u00e9termine si le changement peut se poursuivre, s’il satisfait aux exigences de politique, si les approbations sont compl\u00e8tes et si le risque est dans la tol\u00e9rance. En pratique, elle agit comme un syst\u00e8me de points de contr\u00f4le sur l’ensemble de la cha\u00eene de livraison<\/strong>.<\/p>\n\n\n\n

                                  \n\n\n\n

                                  Application ou surveillance<\/strong><\/h3>\n\n\n\n

                                  L’application et la surveillance sont des concepts diff\u00e9rents. L’application<\/strong> emp\u00eache les changements non conformes avant la livraison. La surveillance<\/strong> d\u00e9tecte les probl\u00e8mes apr\u00e8s le d\u00e9ploiement. Les environnements r\u00e9glement\u00e9s exigent les deux, mais la pr\u00e9vention est plus forte que la d\u00e9tection \u2014 et les auditeurs consid\u00e8rent g\u00e9n\u00e9ralement les contr\u00f4les pr\u00e9ventifs comme plus robustes que les contr\u00f4les d\u00e9tectifs.<\/p>\n\n\n\n

                                  \n\n\n\n

                                  Un mod\u00e8le de maturit\u00e9 de l’application<\/strong><\/h3>\n\n\n\n

                                  La maturit\u00e9 de l’application progresse g\u00e9n\u00e9ralement \u00e0 travers quatre niveaux :<\/p>\n\n\n\n