Automatisation des changements¶

Passer du changement manuel au changement code-driven — pipelines, approbations automatisees et intégration IaC.

Change as Code¶

Le Change as Code est une approche dans laquelle le changement lui-même est décrit dans du code versionne — et non exécuté manuellement via une interface ou une CLI. Toute modification d'infrastructure passe par un commit, une merge request et un pipeline.

Avantages¶

Avantage	Détail
Traceabilite	Chaque changement a un commit, un auteur, une date, un contexte — l'historique git est l'audit trail
Reproductibilite	Le même code produit le même état, quel que soit l'environnement
Peer review	Une MR permet une revue technique du changement avant exécution, sans CAB
Rollback	Revenir à l'état précédent = `git revert` + pipeline
Détection de dérivé	Un pipeline de drift détection alerte quand l'état réel diverge du code

Automatisation du processus vs automatisation de l'exécution

Ces deux niveaux sont distincts et complementaires. L'automatisation du processus remplacé le ticket CAB par une MR avec approbations — la gouvernance reste, la friction diminue. L'automatisation de l'exécution remplacé l'opérateur qui tape des commandes par un pipeline — le changement technique s'exécuté sans intervention manuelle. On peut avoir l'un sans l'autre, mais les deux ensemble donnent le change management le plus efficace.

Pipeline de changement type¶

Un pipeline de changement code-driven suit le même workflow que le processus manuel, mais exécuté automatiquement les étapes deterministes.

graph LR
    A["Commit / PR"] --> B["Validation<br/>lint + format"]
    B --> C["Plan / dry-run<br/>terraform plan"]
    C --> D["Review<br/>peer approbation"]
    D --> E["Approbation<br/>policy check"]
    E --> F["Apply<br/>terraform apply"]
    F --> G["Verification<br/>smoke tests"]
    G --> H["Cloture<br/>tag + notification"]

Étapes automatisables¶

Étape	Automatisation	Outil
Validation syntaxique	Lint, format check	`terraform validate`, `ansible-lint`
Plan / dry-run	Aperçu des changements sans appliquer	`terraform plan`, `ansible --check`
Tests pre-application	Tests d'intégration sur env de staging	Terratest, Molecule
Application	Exécution du changement	`terraform apply`, `ansible-playbook`
Vérification	Health checks, smoke tests	Scripts, k6, curl
Notification	Slack, email, ticket	Webhooks, API ServiceNow

Approbations automatisees¶

Toutes les approbations ne necessitent pas un humain. Les policy as code permettent d'automatiser l'approbation des changements à faible risque et de bloquer les changements qui violent des règles définies.

Types d'approbation¶

Niveau	Condition	Mecanique
Auto-approuve	Changement standard, score de risque < seuil	Pipeline continue sans attente
Peer review	Changement normal, score moyen	MR bloquee jusqu'à 1 approbation
Multi-approbation	Changement a fort impact	MR bloquee jusqu'à N approbations définies
Bloque par policy	Violation d'une règle (ex: production le vendredi soir)	Pipeline échoué avec message explicite

Règles d'auto-approbation typiques¶

le changement ne touche pas les environnements de production
la cible est un service de faible criticite (non-critique)
le changement est défini dans une liste blanche de types connus
le score de risque calcule est inférieur à un seuil défini
le pipeline tourne en dehors d'une freeze period

Intégration IaC¶

L'Infrastructure as Code est le socle technique du Change as Code. Les outils IaC offrent nativement des mécanismes de dry-run et de plan qui rendent le processus de changement transparent.

Terraform¶

terraform plan produit un diff declaratif avant toute application : ressources créées, modifiées, detruites. Ce plan peut être soumis en review comme un diff de code, et l'apply ne peut s'exécuter que si le plan a été approuve.

Ansible¶

ansible-playbook --check simule l'exécution sans appliquer de changements. --diff affiche les modifications de fichiers prévues. Ces modes permettent de valider le comportement attendu avant la fenêtre de maintenance.

Open Policy Agent (OPA)¶

OPA permet de définir des règles de politique sous forme de code (Rego) evaluees automatiquement dans le pipeline. Exemples : interdire la suppression de ressources de base de données sans backup, bloquer les changements en production le week-end, exiger un tag de ticket sur chaque ressource.

Stack de référence¶

Composant	Rôle	Outil
VCS + MR	Versionning et peer review	GitLab, Gitea
IaC	Description de l'infrastructure	Terraform, OpenTofu
Orchestration	Configuration et provisioning	Ansible
Policy as Code	Approbation automatisee	OPA / Conftest
Pipeline	Orchestration du workflow	GitLab CI, Gitea Actions
Registry d'état	État Terraform centralise	Terraform Cloud, GitLab-managed state

Limites et points de vigilance¶

La vitesse n'est pas l'objectif premier : automatiser pour éliminer les frictions inutiles, pas pour contourner la gouvernance
Les dry-runs ne sont pas parfaits : terraform plan peut donner un résultat différent de apply dans certains cas (ressources externes, providers bugges)
L'audit trail est dans le git : il faut s'assurer que les logs du pipeline sont conserves et accessibles pour les audits de conformité
Les pipelines peuvent être bypasses : la policy as code doit egalement couvrir les accès directs aux APIs cloud (guardrails IAM, SCPs AWS)

Outils¶

Outil	Description	Lien
Terraform / OpenTofu	IaC declaratif, plan + apply	opentofu.org
Ansible	Automatisation de configuration avec check mode	ansible.com
Open Policy Agent	Policy as Code pour approbations automatisees	openpolicyagent.org
GitLab CI	Pipelines avec approbations de déploiement natives	gitlab.com
Atlantis	Runner Terraform spécifique pour les MR GitLab/GitHub	runatlantis.io