Infrastructure as Code (IaC) : définition, outils et exemple

L'Infrastructure as Code consiste à traiter l'infrastructure comme du logiciel : elle s'écrit, se versionne, se relit, se teste et se déploie automatiquement.

Avant l'IaC, créer un environnement signifiait enchaîner des dizaines d'opérations manuelles : commander un serveur, installer le système, configurer le réseau, ouvrir des ports, créer une base de données. Ces étapes étaient au mieux décrites dans une documentation vite obsolète, au pire connues d'une seule personne. Chaque environnement finissait par diverger des autres, et reconstruire la production après un incident relevait de l'archéologie. L'IaC remplace ces procédures par des fichiers qu'un outil sait exécuter, autant de fois que nécessaire, avec le même résultat.

La pratique s'est d'abord développée avec les outils de gestion de configuration comme Puppet, Chef puis Ansible, conçus pour configurer des parcs de serveurs. L'essor du Cloud public, dont toutes les ressources sont pilotables par API, a ensuite fait naître les outils de provisionnement : AWS CloudFormation, puis Terraform de HashiCorp, devenu le standard multi-cloud, et plus récemment Pulumi, OpenTofu et Crossplane.

L'IaC est un pilier du DevOps : elle permet d'appliquer à l'infrastructure les mêmes pipelines CI/CD que pour le code applicatif, et constitue le prérequis du GitOps.

À retenir : avec l'IaC, la vérité sur l'infrastructure n'est plus dans une console ou dans la mémoire d'un administrateur, mais dans un dépôt Git que toute l'équipe peut lire et relire.

Déclaratif ou impératif

Une approche déclarative décrit le résultat attendu : « je veux trois serveurs de telle taille derrière un équilibreur de charge ». L'outil calcule lui-même les actions nécessaires pour y parvenir à partir de la situation actuelle. Terraform, OpenTofu, CloudFormation et Crossplane fonctionnent ainsi.

Une approche impérative décrit la suite d'actions à exécuter : « crée un serveur, puis installe ce paquet, puis redémarre ce service ». Les scripts Bash ou les appels directs à une API Cloud en sont l'exemple type. Ansible occupe une position intermédiaire : ses playbooks décrivent des tâches ordonnées, mais chaque module cherche à atteindre un état donné.

Idempotence

Un outil idempotent peut être exécuté plusieurs fois sans effet indésirable. Si le serveur existe déjà avec la bonne configuration, une nouvelle exécution ne fait rien. C'est ce qui permet de lancer le code d'infrastructure dans un pipeline automatique à chaque modification, sans craindre de créer des doublons.

L'état

Pour savoir quoi modifier, un outil comme Terraform conserve un fichier d'état qui associe chaque ressource du code à son identifiant chez le fournisseur Cloud. Ce fichier doit être stocké dans un backend partagé, verrouillé pendant chaque exécution et protégé, car il peut contenir des valeurs sensibles. Les outils sans état, comme Ansible, interrogent directement les machines à chaque exécution.

Voici un extrait de code Terraform qui crée un bucket S3 versionné et chiffré pour stocker des journaux d'application, avec un état distant partagé.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 5.0"
    }
  }

  # État partagé et centralisé pour toute l'équipe
  backend "s3" {
    bucket = "acme-terraform-state"
    key    = "production/journaux.tfstate"
    region = "eu-west-3"
  }
}

provider "aws" {
  region = "eu-west-3"
}

variable "environnement" {
  type    = string
  default = "production"
}

resource "aws_s3_bucket" "journaux" {
  bucket = "acme-${var.environnement}-journaux"

  tags = {
    Environnement = var.environnement
    GerePar       = "terraform"
  }
}

resource "aws_s3_bucket_versioning" "journaux" {
  bucket = aws_s3_bucket.journaux.id

  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "journaux" {
  bucket = aws_s3_bucket.journaux.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

Le cycle d'exécution tient en trois commandes :

terraform init                    # télécharge le provider et configure le backend
terraform plan -out=plan.tfplan   # affiche et enregistre les changements prévus
terraform apply plan.tfplan       # applique exactement le plan relu

Le code ne dit jamais « crée » ni « modifie » : il décrit le résultat. Si le bucket existe déjà avec cette configuration, terraform plan n'annonce aucun changement. Si quelqu'un désactive le versionnement à la main dans la console, le plan suivant le détecte et propose de le réactiver. En pratique, ces commandes sont exécutées par un pipeline : le plan est publié en commentaire de la merge request, et l'application n'a lieu qu'après fusion.

Les outils d'IaC ne se concurrencent pas tous : certains provisionnent les ressources, d'autres configurent les machines.

Le couple le plus fréquent reste Terraform pour créer les ressources et Ansible pour configurer les machines qui en ont besoin. Les équipes déjà très investies dans Kubernetes se tournent vers Crossplane, qui réconcilie en continu les ressources Cloud comme n'importe quel objet du cluster. Pour les machines virtuelles, Packer complète l'ensemble en produisant des images préconfigurées : on remplace alors un serveur plutôt que de le modifier, c'est l'infrastructure immuable.

Une infrastructure décrite en code peut et doit être testée. Les contrôles s'organisent du plus rapide au plus complet :

• Validation : terraform fmt -check et terraform validate vérifient le format et la cohérence du code.
• Analyse statique : des outils comme Checkov ou Trivy repèrent un bucket public, un port ouvert à tout Internet ou une base non chiffrée avant toute création.
• Revue du plan : le plan d'exécution est relu en merge request, avec une attention particulière aux suppressions et remplacements.
• Tests d'intégration : Terratest ou la commande terraform test déploient réellement les ressources dans un compte de test, vérifient leur comportement puis les détruisent.

La dérive de configuration est l'autre risque majeur. Elle apparaît dès qu'une ressource est modifiée hors du code, souvent en urgence pendant un incident. Pour la maîtriser, on restreint les droits d'écriture dans la console, on exécute un plan planifié chaque nuit pour détecter les écarts, et on reporte systématiquement les corrections d'urgence dans le code.