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
- Pattern de composition
- Le module racine appelle des modules enfants
- Chaque module = un groupe logique de ressources
- Exemple : module réseau + module calcul + module base de données
- Pattern wrapper
- Fine enveloppe autour d'une ressource du provider
- Impose les standards de l'organisation (tags, nommage, chiffrement)
- Exemple : module « aws-s3-bucket » qui active toujours le versioning
- Pattern scaffold / template
- Template d'environnement complet
- Paramétré pour dev / staging / prod
- Exemple : module « environment » qui crée VPC + EKS + RDS
- Pattern bibliothèque
- Modules partagés dans un registre central
- Versionnés, testés, documentés
- Exemple : registre privé Terraform ou tags Git
- modules/ — reusable, tagged modules/vX.Y.Z
- s3-data
- versioning, KMS, lifecycle to Glacier for old snapshots
- ecr
- immutable tags, scan on push, lifecycle policy
- eks
- cluster, CPU + GPU node groups, Pod Identity
- sagemaker / iam
- domain, execution roles, least-privilege policies
- s3-data
- envs/ — one state per environment
- test
- main.tf, test.tfvars, backend key test/
- staging
- same modules, staging.tfvars
- prod
- separate AWS account, prod.tfvars
- test
Extrait de la fiche « Infrastructure as Code for ML (Terraform on AWS) » · Demander la fiche complète
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) |
Extrait de la fiche « SAP-C02 Org Complexity 1: Multi-Account Governance » · Demander la fiche complète
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).
Extrait de la fiche « Infrastructure as Code for ML (Terraform on AWS) » · Demander la fiche complète