Governance-as-Code : quand la conformité vient de Git

← Tous les articles

Governance-as-Code : quand la politique rencontre le contrôle de version

La conformité classique repose sur des documents Word, des PDF et des dossiers SharePoint. Personne ne les lit. Personne ne sait quelle version est actuelle. Les audits se transforment en cauchemar.

Governance-as-Code résout ce problème de manière structurelle.

Qu’est-ce que le Governance-as-Code ?

Toutes les directives, politiques, seuils et logiques d’approbation sont versionnés sous forme de fichiers lisibles par machine (YAML, JSON) dans Git :

# HITL-BOUNDARY-POLICY.yaml
rules:
  - action: production-deploy
    decision: HITL
    reason: Irréversible, impact en production
  - action: read-only-query
    decision: AUTO
    reason: Aucun risque, entièrement réversible

Pourquoi c’est mieux

Classique	Governance-as-Code
PDF dans SharePoint	YAML dans Git
Mis à jour manuellement	Versionné, comparable (diff)
Ignoré	Appliqué par la machine
Préparation d’audit : semaines	Rapport d’audit : automatique

La mise en œuvre chez IIO

Le framework IIO comporte plus de 400 fichiers de gouvernance dans Git :

• Politiques d’approbation (HITL Boundary Policy)
• Règles de protection des données (niveaux CDT)
• Contrôles de coûts (Cost Control Policy)
• Preuves de conformité (piste de preuves)

Chaque modification est traçable. Chaque décision est auditable.

Mise en œuvre de la gouvernance pour votre entreprise →

Ce que signifie concrètement le Governance-as-Code

La gouvernance IT traditionnelle vit dans des documents Word, des dossiers SharePoint et des fils d’e-mails. Le Governance-as-Code applique les mêmes principes au code :

# Exemple : définition d'une porte HITL en YAML
gate_id: gate.production-deploy
title: Approbation du déploiement en production
risk_level: HIGH
approvers:
  - role: operator_admin
auto_conditions:
  - infra_mode: standard
  - branch: feature/*
block_conditions:
  - actor_trust: L0
  - infra_mode: storm

Les quatre principes

1. Versionnable — les modifications de gouvernance sont traçables dans le journal Git. Qui a modifié quelle règle, et quand ?

2. Testable — les tests de politique s’exécutent dans le pipeline CI/CD. Aucun déploiement sans contrôle de gouvernance.

3. Auditable — des fichiers de preuves lisibles par machine pour chaque point de décision. Les auditeurs reçoivent des dossiers complets sans préparation manuelle.

4. Applicable automatiquement — les politiques sont automatiquement bloquées en cas de violation — pas seulement documentées.

Exemple concret : approbation de la paie

Sans Governance-as-Code : tableau Excel → approbation par e-mail → comptabilisation manuelle. Avec Governance-as-Code : le calcul s’exécute automatiquement → la porte HITL s’ouvre → le relecteur voit le diff → un clic → le fichier SEPA est généré.

Résultat : 70 % d’étapes manuelles en moins, 100 % de piste d’audit.

Architecture de la plateforme IIO →