# Infrastructure as Code > Infrastructure as Code (IaC) : gestion et provisionnement de l'infrastructure via des fichiers déclaratifs versionnés, traités comme du code applicatif — reproductible, auditable, testable. - **Catégorie** : Technique - **URL** : https://www.romaindelfosse.fr/glossary/infrastructure-as-code/ --- L'**Infrastructure as Code** (IaC) désigne la pratique consistant à gérer et provisionner l'infrastructure informatique via des fichiers de configuration versionnés, traités comme du code applicatif. Plutôt que de configurer manuellement des serveurs, des réseaux ou des services via des interfaces graphiques ou des commandes ad hoc, l'IaC décrit l'état cible de l'infrastructure dans des fichiers lisibles par une machine — typiquement YAML, HCL (Terraform) ou JSON — qui sont stockés dans un dépôt Git, reviewés en pull request, testés en CI et appliqués via des outils d'automatisation. ## Définition technique ### Déclaratif vs impératif L'approche moderne de l'IaC est **déclarative** : le fichier décrit *ce qu'on veut* (trois instances EC2 en `t3.medium`, un load balancer devant, une base RDS en multi-AZ), pas *comment y arriver*. L'outil d'exécution (Terraform, Pulumi, Kubernetes controller) compare l'état réel à l'état souhaité et applique les changements nécessaires. Cette approche garantit l'**idempotence** : appliquer le même fichier dix fois produit le même résultat qu'une seule fois. L'approche impérative (scripts bash, Ansible playbooks mal conçus) décrit une suite d'étapes. Elle est plus intuitive pour un administrateur système, mais fragile : un script qui crée une ressource casse si la ressource existe déjà. ### Les trois niveaux d'IaC 1. **Provisionnement** — créer les ressources de base (VMs, réseaux, bases de données). Outils typiques : Terraform, Pulumi, CloudFormation. 2. **Configuration** — installer et paramétrer les logiciels sur les ressources provisionnées. Outils typiques : Ansible, Chef, Puppet, cloud-init. 3. **Orchestration** — déployer et gérer des applications qui s'exécutent sur l'infrastructure. Outils typiques : Kubernetes manifests, Helm, ArgoCD, FluxCD. ## Enjeux actuels ### Reproductibilité et parité environnements Le principal bénéfice de l'IaC, c'est la **reproductibilité**. Un environnement de staging peut être créé à l'identique de la production en quelques minutes — ce qui élimine toute une catégorie de bugs de type "ça marche chez moi". Dans un contexte où la conformité exige de prouver qu'un environnement a été déployé selon une procédure approuvée, l'IaC versionné dans Git fournit la trace d'audit naturelle : qui a changé quoi, quand, pourquoi (via le message de commit et la PR associée). ### Sécurité et auditabilité L'IaC transforme la posture de sécurité d'une organisation : la configuration n'est plus dans la tête d'un administrateur ou dans l'interface graphique d'un provider cloud, elle est dans Git. Des outils comme **Checkov**, **tfsec** ou **Open Policy Agent (OPA)** scannent les fichiers IaC en pipeline CI pour détecter les mauvaises pratiques avant déploiement : secrets en dur, permissions trop larges, chiffrement désactivé. C'est la logique du *shift left* appliquée à l'infrastructure. ### Dérive de configuration Le principal risque de l'IaC, c'est la **dérive** : quelqu'un modifie une ressource directement dans la console du provider, et l'état réel diverge de l'état décrit dans le code. Les outils modernes (`terraform plan`, `pulumi preview`) détectent cette dérive et proposent de la corriger — mais cela suppose une discipline opérationnelle stricte : interdire les modifications hors IaC, ou les tracer immédiatement dans un commit. ## Applications pratiques ### Hébergement d'applications web Un PaaS comme Upsun, Fly.io ou Render repose entièrement sur un fichier IaC versionné (`.upsun/config.yaml`, `fly.toml`, `render.yaml`) qui décrit les services, leurs ressources, leurs variables d'environnement, leurs routes. Chaque push sur une branche déclenche un déploiement reproductible — et un rollback ne demande qu'un revert de commit. ### Sécurité périmétrique L'IaC permet de remonter les contrôles de sécurité au niveau le plus bas : règles de firewall, headers HTTP, WAF, politiques IAM. Plutôt que de confier ces contrôles à des plugins applicatifs, on les décrit dans un fichier versionné et on les review en PR. C'est l'approche que je détaille dans [mon article sur la sécurisation de WordPress sans plugins](/blog/securiser-wordpress-sans-plugins-infrastructure-as-code/). ## Questions fréquentes ### Quelle différence entre Infrastructure as Code et scripts shell d'administration ? Un script shell est impératif : il décrit une séquence d'étapes à exécuter, et peut produire un résultat différent selon l'état initial de la machine. L'IaC moderne est déclarative : on décrit l'état cible souhaité (3 serveurs web, 1 base de données, ces règles réseau), et l'outil se charge de converger vers cet état — qu'il faille créer, modifier ou supprimer des ressources.Cette différence est fondamentale : un fichier Terraform ou un manifest Kubernetes peut être appliqué cent fois sans effet secondaire (idempotence), alors qu'un script shell peut casser s'il est relancé sur une machine déjà configurée. ### Quels sont les outils d'Infrastructure as Code les plus utilisés ? Côté provisionnement multi-cloud : Terraform (HashiCorp, OpenTofu pour le fork open source), Pulumi (IaC dans un vrai langage de programmation). Côté configuration : Ansible, Chef, Puppet. Côté Kubernetes : Helm, Kustomize, ArgoCD (GitOps). Côté PaaS : Upsun/Platform.sh, Fly.io, Render utilisent tous un fichier YAML versionné qui décrit l'infrastructure de l'application. ### L'Infrastructure as Code est-elle uniquement pour le cloud ? Non. L'IaC s'applique à toute infrastructure descriptible : serveurs physiques (via Ansible), VMs on-premise (via Terraform + vSphere), équipements réseau (via NAPALM ou Nornir), certificats TLS (via cert-manager), et même des règles de firewall. Le principe est le même : décrire l'état cible dans un fichier versionné, appliquer via un outil qui converge vers cet état. ## Ressources - [Infrastructure as Code — Martin Fowler](https://martinfowler.com/bliki/InfrastructureAsCode.html?utm_source=romaindelfosse&utm_medium=glossaire&utm_campaign=iac) — Martin Fowler - [Terraform Documentation](https://developer.hashicorp.com/terraform/docs?utm_source=romaindelfosse&utm_medium=glossaire&utm_campaign=iac) — HashiCorp - [The DevOps Handbook — Gene Kim et al.](https://itrevolution.com/product/the-devops-handbook-second-edition/?utm_source=romaindelfosse&utm_medium=glossaire&utm_campaign=iac) — IT Revolution