Patterns Infrastructure as Code : outils, état et conception multi-comptes
L'Infrastructure as Code (IaC) est la pratique de gérer l'infrastructure via des definitions declaratives ou imperatives stockées dans le contrôle de version. En 2026, la question n'est plus de savoir s'il faut utiliser l'IaC mais quel outil, pattern et modèle organisationnel correspond a votre contexte.
Comparaison des outils
| Dimension | Terraform / OpenTofu | Pulumi | AWS CDK | Azure Bicep | Crossplane |
|---|---|---|---|---|---|
| Langage | HCL | TypeScript, Python, Go, C# | TypeScript, Python, Go | Bicep DSL | YAML (CRDs K8s) |
| Paradigme | Declaratif | Imperatif + Declaratif | Imperatif → CloudFormation | Declaratif | Declaratif (GitOps) |
| Multi-cloud | Excellent (1000+ providers) | Bon (en croissance) | AWS uniquement | Azure uniquement | Bon (providers) |
| Gestion d'état | Backend distant (S3, GCS, TFC) | Pulumi Cloud ou auto-géré | Stack CloudFormation | Azure Resource Manager | etcd (cluster K8s) |
| Courbe d'apprentissage | Moyenne (HCL unique) | Faible (langages familiers) | Moyenne | Faible (devs Azure) | Haute (K8s requis) |
| Licence (2026) | BSL (TF) / MPL (OpenTofu) | Apache 2.0 | Apache 2.0 | MIT | Apache 2.0 |
| Ideal pour | Multi-cloud, grandes équipes | Équipes orientées dev | Shops AWS-natives | Shops Azure-natives | Plateformes K8s |
Comparaison gestion d'état
| Stratégie | Avantages | Inconvenients | Ideal pour |
|---|---|---|---|
| État local | Simple, pas de setup | Pas de collaboration, pas de verrou | Apprentissage, prototypage |
| Backend distant (S3+DynamoDB) | Verrouillage, accès équipe, versionne | Auto-géré, pas d'UI | Équipes AWS |
| Terraform Cloud / HCP | UI, historique, RBAC, intégration VCS | Coût, vendor lock-in | Équipes entreprise |
| Pulumi Cloud | Integre a Pulumi, gestion des secrets | Lie a l'écosystème Pulumi | Utilisateurs Pulumi |
| GitOps (Crossplane) | K8s-natif, détection de derive | Nécessite un cluster K8s | Équipes platform engineering |
Règle critique : Les fichiers d'état contiennent des secrets. Chiffrer au repos, restreindre l'accès, jamais de commit dans git.
Patterns de conception de modules
Patterns de Modules IaC
├── Pattern Composition
│ ├── Module racine appelle des modules enfants
│ ├── Chaque module = un groupe logique de ressources
│ └── Exemple : module réseau + module compute + module base de données
│
├── Pattern Wrapper
│ ├── Wrapper leger autour d'une ressource provider
│ ├── Applique les standards org (tags, nommage, chiffrement)
│ └── Exemple : module "aws-s3-bucket" activant toujours le versioning
│
├── Pattern Scaffold / Template
│ ├── Template d'environnement complet
│ ├── Parametre pour dev/staging/prod
│ └── Exemple : module "environment" creant VPC + EKS + RDS
│
└── Pattern Bibliotheque
├── Modules partages dans un registre central
├── Versionnes, testes, documentes
└── Exemple : registre prive Terraform ou tags Git
Stratégie de tests
| Niveau de test | Ce qu'il validé | Outil | Vitesse | Quand exécuter |
|---|---|---|---|---|
| Analyse statique | Syntaxe, bonnes pratiqués, sécurité | tflint, checkov, tfsec | Secondes | Chaque commit |
| Tests unitaires | Logique des modules, validation des variables | tftest, tests unitaires Pulumi | Secondes | Chaque PR |
| Tests de contrat | Les sorties correspondent au schema attendu | Assertions personnalisees | Secondes | Chaque PR |
| Tests d'intégration | L'infra réelle se deploie et fonctionne | Terratest | Minutes | Nightly ou par PR |
| Tests E2E / Smoke | La stack complete est fonctionnelle | Tests applicatifs | Minutes | Post-déploiement |
| Détection de derive | L'état réel correspond au desire | terraform plan (programmé) | Minutes | Quotidien (cron) |
Principes clés
Traitez les modules comme des bibliotheques. Versionnez-les, testez-les, documentez leurs interfaces. Les breaking changes doivent suivre le versioning semantique.
Isolation de l'état par environnement. Ne partagez jamais un fichier d'état entre dev et prod. Un mauvais plan en dev ne doit jamais risquer les ressources de production.
Plan avant apply, toujours. Chaque changement passé par plan en CI. apply ne se fait qu'après revue humaine ou vérification automatisee des politiques (OPA/Sentinel).