Traiter le CI/CD comme un système réglementé d’application et d’audit
Introduction
Dans les environnements réglementés, les pipelines CI/CD sont souvent perçus à tort comme des outils de productivité pour développeurs.
En réalité, ce sont des systèmes d’application des contrôles.
Lorsqu’il est correctement conçu, un pipeline CI/CD devient :
- L’unique voie autorisée vers la production
- Le moteur d’application des politiques de sécurité
- Le générateur de preuves d’audit continues
- La mise en œuvre technique de la séparation des tâches
Cet article présente un modèle d’architecture « CI/CD uniquement », où le pipeline lui-même est traité comme un système réglementé chargé d’appliquer les contrôles, les approbations et la traçabilité.
1. Pourquoi le « CI/CD uniquement » est important
Dans de nombreuses organisations, les contrôles de sécurité et de conformité sont fragmentés entre :
- Des systèmes de tickets
- Des approbations par courriel
- Des outils de gouvernance distincts
- Des processus de validation manuels
Cette fragmentation crée des lacunes :
- Une application incohérente
- Des possibilités de contournement
- Des pistes de preuves faibles
- Une complexité d’audit
Une architecture « CI/CD uniquement » consolide l’application dans un système unique et contrôlé.
Ce qui ne passe pas par le pipeline n’atteint pas la production.
2. Principes fondamentaux d’une architecture « CI/CD uniquement »
2.1 Une voie unique vers la production
Tous les changements en production doivent :
- Provenir de dépôts sous gestion de versions
- Passer par le pipeline CI/CD
- Être approuvés au sein de portes de flux contrôlées
- Générer des journaux traçables
L’accès direct à la production est minimisé ou éliminé.
2.2 Application intégrée des politiques
Les politiques de sécurité et de conformité sont mises en œuvre sous forme de :
- Vérifications automatisées
- Portes de politique
- Contrôles bloquants
- Seuils configurables
Les exemples incluent :
- L’application du SAST et du DAST
- La conformité aux politiques de dépendances
- Les exigences de génération de SBOM
- Des flux d’approbation obligatoires
Les contrôles sont obligatoires et déterministes, non consultatifs.
2.3 La séparation des tâches par la conception des flux
Une architecture CI/CD réglementée applique :
- Un développeur ne peut pas approuver sa propre livraison
- Des rôles distincts pour le build et le déploiement
- Des processus de contournement contrôlés
- Une gestion des exceptions journalisée
La séparation est appliquée techniquement — et non documentée comme une intention.
2.4 Génération de preuves par défaut
Chaque exécution du pipeline produit :
- Des journaux d’exécution
- Des résultats de scans de sécurité
- Des enregistrements d’approbation
- Des métadonnées d’artefacts
- Des marqueurs de traçabilité
Les preuves sont :
- Générées par le système
- Horodatées
- Conservées
- Corrélables
Le pipeline devient une usine à preuves d’audit.
3. Les couches architecturales
Un modèle « CI/CD uniquement » comprend généralement trois couches logiques :
Couche 1 : contrôles de gouvernance
- Gestion des identités et des accès (IAM)
- Autorisations basées sur les rôles
- Séparation des tâches
- Policy-as-code
- Gouvernance des exceptions
Cette couche assure le contrôle sur qui peut agir et dans quelles conditions.
Couche 2 : application par le pipeline
- Validation du code source
- Tests statiques et dynamiques
- Analyse des dépendances
- Portes de politique
- Flux d’approbation
- Signature des artefacts
Cette couche assure le contrôle sur ce qui est livré et comment.
Couche 3 : preuves et conservation
- Stockage centralisé des journaux
- Enregistrements d’audit immuables
- Historique des approbations
- Cartographie de la traçabilité (commit → build → artefact → production)
- Conservation alignée sur les exigences réglementaires
Cette couche assure le contrôle sur ce qui pourra être prouvé ultérieurement.
4. Le modèle de traçabilité
Une architecture CI/CD réglementée établit une traçabilité complète :
- Identifiant de commit
- Revue de pull request
- Exécution du pipeline
- Artefact de build
- Décision d’approbation
- Événement de déploiement
- Surveillance à l’exécution
Chaque étape est reliée par des identifiants cohérents.
Les auditeurs échantillonnent fréquemment un changement en production et demandent :
« Montrez-moi la chaîne complète du code à la production. »
Dans un modèle « CI/CD uniquement », cela est reproductible et déterministe.
5. Ce que cette architecture empêche
Un modèle « CI/CD uniquement » correctement conçu empêche :
- Les déploiements hors circuit
- Les livraisons en production non approuvées
- Les échecs silencieux de contrôles de sécurité
- Une application incohérente des contrôles
- L’absence de preuves lors des audits
Il supprime la dépendance à la mémoire, aux courriels ou aux flux de travail non documentés.
6. Alignement avec les référentiels réglementaires
Cette architecture soutient directement :
- DORA (gestion du risque TIC et supervision des tiers)
- ISO 27001 (contrôle des changements et développement sécurisé)
- SOC 2 (accès logique et gestion des changements)
- NIS2 (résilience opérationnelle et sécurité de la chaîne d’approvisionnement)
- PCI DSS (développement sécurisé et gestion des vulnérabilités)
Plutôt que de construire la conformité séparément, l’architecture produit la conformité en continu.
7. Idées reçues courantes
« Nous avons des outils de sécurité dans le CI/CD, donc nous sommes conformes. »
Les outils ne garantissent pas l’application.
Les auditeurs examinent :
- Si les échecs bloquent le déploiement
- Si les contrôles peuvent être contournés
- Si les journaux sont conservés
- Si les approbations sont séparées par rôle
La conformité exige une application systémique.
« Les approbations par courriel suffisent. »
Les approbations externes créent :
- Une fragmentation des preuves
- Une traçabilité faible
- Des lacunes de gouvernance
Les approbations doivent être intégrées au flux de travail du pipeline.
8. Quand le CI/CD devient un système TIC réglementé
Dans les environnements financiers réglementés, les pipelines CI/CD devraient être :
- Inclus dans les inventaires d’actifs TIC
- Couverts par des évaluations des risques
- Gouvernés par la gestion des changements
- Soumis à des revues d’accès
- Testés selon des scénarios d’incident
À ce niveau de maturité, le CI/CD n’est pas un support d’infrastructure — c’est un système de contrôle réglementé.
9. Niveaux de maturité de l’application par le CI/CD
Niveau 1 — consultatif
Les contrôles de sécurité existent mais ne bloquent pas les livraisons.
Niveau 2 — application partielle
Certains contrôles sont bloquants, d’autres facultatifs.
Niveau 3 — application réglementée
Tous les contrôles critiques sont obligatoires et auditables.
Niveau 4 — gouvernance fondée sur les preuves
Traçabilité complète, reporting automatisé, tests de résilience et préparation à la sortie.
Les environnements réglementés devraient fonctionner au niveau 3 ou au-dessus.
10. Les preuves qu’un modèle « CI/CD uniquement » doit produire
Le test pratique de cette architecture est de savoir si chaque étape laisse derrière elle une preuve qu’un auditeur peut échantillonner sans demander à quiconque de la reconstituer manuellement. Le tableau ci-dessous met en correspondance les étapes du pipeline avec les artefacts qu’elles doivent générer et ce que chaque artefact démontre lors d’une évaluation.
| Étape du pipeline | Artefact de preuve | Ce qu’il démontre à un auditeur |
|---|---|---|
| Gestion du code source | Commits signés et enregistrements de revue de pull request | Le changement a été rédigé sous une identité connue et relu par un pair avant la fusion |
| Tests de sécurité | Rapports SAST, DAST et SCA avec statut de réussite ou d’échec | Les contrôles se sont réellement exécutés et leurs résultats ont conditionné le build |
| Build | SBOM et signature ou empreinte de l’artefact | L’intégrité et la provenance de l’artefact déployé |
| Approbation | Enregistrement d’approbation du flux avec identité et horodatage | La séparation des tâches a été appliquée, et non simplement voulue |
| Déploiement | Journal de déploiement relié à l’identifiant du build approuvé | Seuls les artefacts autorisés ont atteint la production |
| Conservation | Stockage de journaux immuable avec une politique de conservation définie | Les preuves subsistent pendant toute la période réglementaire |
11. Constats d’audit typiques dans les environnements centrés sur le pipeline
Même les organisations qui ont consolidé la livraison dans un pipeline unique attirent couramment des constats. Les schémas récurrents tiennent moins à des outils manquants qu’à des lacunes d’application qui n’apparaissent que lorsqu’un auditeur teste le contrôle plutôt que d’en lire la description :
- Des portes de sécurité configurées pour avertir plutôt que bloquer, si bien qu’un scan en échec est tout de même livré
- Des chemins de contournement d’urgence (break-glass) techniquement disponibles mais non journalisés ni revus par la suite
- Des comptes de service disposant d’un accès permanent à la production qui contournent entièrement le pipeline
- Des étapes d’approbation présentes dans le flux mais attribuables à l’auteur du changement
- Une conservation des journaux plus courte que l’exigence réglementaire, ou des preuves stockées dans des systèmes modifiables
- Aucun lien démontrable entre un changement en production échantillonné et son commit d’origine
Chacun de ces éléments transforme une architecture par ailleurs solide en un contrôle qui ne peut pas être étayé par des preuves — ce qui, en termes d’audit, est un contrôle qui n’existe pas.
12. Les questions que les auditeurs posent sur le pipeline
Les responsables de contrôles peuvent anticiper une évaluation en répétant les questions qu’un auditeur est le plus susceptible de poser sur le pipeline lui-même :
- Le pipeline est-il l’unique voie vers la production, et comment l’accès direct est-il empêché et surveillé ?
- Qu’advient-il d’une livraison lorsqu’un contrôle obligatoire échoue — le blocage est-il absolu, et qui peut le lever ?
- Qui peut modifier la définition du pipeline elle-même, et ces modifications sont-elles revues et sous gestion de versions ?
- Combien de temps les preuves du pipeline sont-elles conservées, et peuvent-elles être altérées après leur génération ?
- Pouvez-vous démontrer la séparation des tâches pour une livraison en production récente et précise ?
13. Construire l’argumentaire de la consolidation
Le passage à un modèle « CI/CD uniquement » suscite souvent des résistances au motif qu’il ralentirait les équipes. En pratique, on observe l’inverse pendant la saison des audits. Lorsque l’application, les approbations et les preuves résident dans un seul système, une évaluation qui consommerait autrement des semaines de collecte manuelle de preuves se résume à échantillonner le pipeline. La consolidation se rentabilise non pas dans la livraison quotidienne, mais par des audits plus courts, moins de constats et un coût réduit pour démontrer la conformité — un argument qui résonne à la fois auprès de la direction de l’ingénierie et de la fonction risque.
Conclusion
Une architecture « CI/CD uniquement » redéfinit le pipeline comme :
- Un moteur d’application de la sécurité
- Un mécanisme de gouvernance
- Une mise en œuvre de la séparation des tâches
- Un générateur de preuves de conformité
Dans les environnements réglementés, la vitesse de livraison et le contrôle réglementaire ne sont pas opposés.
Lorsqu’il est correctement conçu, le CI/CD devient l’épine dorsale technique d’une conformité continue et auditable.
Articles associés
- Modèles d’application fondés sur le CI/CD
- Comment les auditeurs évaluent l’application par le CI/CD
- Fondamentaux du SDLC sécurisé
- Conformité continue via CI/CD au titre de DORA
