Infrastructure en tant que code et infrastructure immuable

Ce qu’est l’infrastructure en tant que code

L’infrastructure en tant que code (IaC) consiste à définir les réseaux, les machines virtuelles, les clusters, les bases de données, les files d’attente, les enregistrements DNS, les autorisations et tous les autres éléments d’infrastructure dans des fichiers texte conservés sous gestion de versions, et à laisser des outils créer et modifier les ressources réelles à partir de ces fichiers. Au lieu qu’un ingénieur clique dans une console cloud, un changement est un commit : relu dans une pull request, testé dans un pipeline, appliqué automatiquement et enregistré pour toujours.

L’idée est plus ancienne que le cloud public. CFEngine de Mark Burgess (1993) gérait des machines Unix à partir de politiques déclaratives ; Puppet (2005), Chef (2009) et Ansible (2012) ont popularisé la gestion de configuration. Le cloud l’a rendue indispensable, car l’infrastructure elle-même est devenue accessible par des API : AWS CloudFormation (2011) et Terraform de HashiCorp (2014) décrivent des environnements entiers, et pas seulement le logiciel installé sur les serveurs. Le livre de Kief Morris Infrastructure as Code, aujourd’hui dans sa troisième édition (2025), est l’ouvrage de référence sur cette pratique et ses principes.

Les bénéfices sont ceux du génie logiciel appliqué à l’infrastructure. Les environnements deviennent reproductibles : le staging peut être construit à partir des mêmes définitions que la production, et une région peut être reconstruite après un sinistre à partir du code plutôt que de mémoire. Les changements deviennent vérifiables et auditables, ce que les régulateurs et les équipes de sécurité apprécient. Le savoir cesse de vivre dans la tête d’un seul ingénieur. Et la rapidité augmente, car créer un environnement pour un nouveau service de la plateforme de livraison de repas devient une pull request plutôt qu’un ticket qui attend deux semaines.

Déclaratif ou impératif

Une approche impérative énumère les étapes : créer un réseau, puis un sous-réseau, puis une base de données, puis ouvrir tel port. Exécuter le script deux fois tente de tout créer deux fois. Une approche déclarative décrit l’état final, l’état souhaité de la section 10.2 : un réseau avec ces sous-réseaux, une base de données de cette taille, un pare-feu qui autorise ce port. L’outil compare la description avec ce qui existe et en déduit les étapes, si bien que l’appliquer deux fois ne change rien la seconde fois. Cette propriété, l’idempotence, est ce qui permet d’exécuter du code d’infrastructure de façon répétée et en automatisation sans risque.

La plupart des outils matures sont déclaratifs au fond, mais ils diffèrent par le langage utilisé pour écrire la déclaration et par l’entité qui tient le registre de ce qui existe. Le tableau résume les principales familles.

Les outils et le fork OpenTofu

Terraform est devenu l’outil multicloud le plus utilisé parce qu’un seul langage et un seul flux de travail couvrent des milliers de providers : AWS, Azure, Google Cloud, Cloudflare, Kubernetes, GitHub, des services de supervision et bien d’autres. Le 10 août 2023, HashiCorp a fait passer Terraform de la licence open source Mozilla Public License 2.0 à la Business Source License 1.1, qui autorise l’usage interne et commercial mais interdit de le proposer dans des produits concurrents de ceux de HashiCorp. La version 1.5.7 a été la dernière publiée sous l’ancienne licence.

La communauté a répondu par un fork. Un manifeste appelant à un retour à l’open source est paru en quelques jours ; en septembre 2023, la Linux Foundation a accepté le fork sous le nom d’OpenTofu ; sa première version stable, la 1.6.0, a suivi en janvier 2024 ; et en 2025, il a été accepté à la CNCF comme projet sandbox. IBM a finalisé son acquisition de HashiCorp en février 2025. Les deux outils restent largement compatibles par le langage et les providers, mais leurs fonctionnalités divergent : OpenTofu a par exemple ajouté le chiffrement de l’état côté client, tandis que la plateforme commerciale de Terraform a ajouté ses propres capacités. Pour un architecte, l’épisode rappelle que la licence et la gouvernance d’un outil font partie de son profil de risque, et que des standards ouverts et une alternative crédible gardent ce risque maîtrisable.

Parmi les outils propres à un seul cloud, AWS CloudFormation (2011) et Bicep de Microsoft (introduit en 2020, compilé en modèles Azure Resource Manager) sont exécutés par le fournisseur, qui tient le registre de ce qui existe : il n’y a donc pas de fichier d’état à gérer, au prix d’une dépendance à un seul cloud. Pulumi (2018) et l’AWS CDK permettent aux développeurs d’écrire l’infrastructure dans des langages généralistes ; Crossplane étend Kubernetes pour gérer les ressources cloud par réconciliation. Le bon choix dépend des clouds que vous utilisez, des compétences de votre équipe, de la maturité des providers dont vous avez besoin, de la politique en matière de licences et de ce que le reste de l’organisation utilise déjà ; la cohérence entre les équipes vaut généralement plus que les mérites marginaux d’un outil donné.

terraform {
  required_version = ">= 1.6"
  backend "gcs" {                 # remote state; this backend locks natively
    bucket = "fd-infra-state"
    prefix = "orders/prod"
  }
}

variable "environment" { type = string }

module "orders_db" {
  source      = "git::https://git.example.com/modules/postgres.git?ref=v3.2.0"
  name        = "orders-${var.environment}"
  size        = var.environment == "prod" ? "large" : "small"
  high_avail  = var.environment == "prod"   # standby in a second zone
  backup_days = 14
}

output "orders_db_host" {
  value = module.orders_db.host
}

Exécuter tofu plan (ou terraform plan) montre ce qui changerait avant que quoi que ce soit ne se produise. Le plan est l’artefact le plus important du flux de travail : les relecteurs le lisent dans la pull request, à côté du code, et c’est lui qui est appliqué.

  # module.orders_db.google_sql_database_instance.this will be updated in-place
  ~ resource "google_sql_database_instance" "this" {
      ~ settings {
          ~ tier = "db-custom-2-8192" -> "db-custom-4-16384"
        }
    }

Plan: 0 to add, 1 to change, 0 to destroy.

État, verrouillage et dérive

Les outils déclaratifs doivent savoir quelles ressources réelles correspondent à quelles définitions. Terraform et OpenTofu conservent cette information dans l’état : un fichier qui associe chaque ressource du code à l’identifiant de l’objet réel, avec ses derniers attributs connus. La planification compare trois choses : le code (ce qui devrait exister), l’état (ce que l’outil a créé) et l’infrastructure réelle, lue via l’API du fournisseur (ce qui existe vraiment).

L’état demande du soin parce qu’il est à la fois critique et sensible. Il doit être stocké à distance (dans un stockage objet ou un service managé), pas sur un portable, afin que toute l’équipe et le pipeline partagent une seule version. Il doit être verrouillé pendant les modifications, pour que deux apply ne puissent pas s’entremêler et le corrompre. Il doit être sauvegardé et versionné, car un fichier d’état perdu laisse l’outil dans l’ignorance des ressources qu’il a créées. Et c’est un secret : l’état contient souvent des mots de passe de bases de données et des clés en clair, donc son accès doit être restreint, et il doit être chiffré au repos (OpenTofu peut aussi le chiffrer côté client).

La dérive de configuration (drift) est toute différence entre le code et la réalité, généralement due à des modifications manuelles faites dans l’urgence, à un autre outil qui touche la même ressource, ou à un échec partiel pendant un apply. La dérive est dangereuse, car le prochain apply peut annuler silencieusement un changement dont quelqu’un dépendait, ou échouer en production sur une différence dont personne ne soupçonnait l’existence. Les équipes la détectent en exécutant un plan à intervalles réguliers (par exemple chaque nuit) et en alertant sur tout changement proposé, et la préviennent en limitant l’accès en écriture à la console à une procédure d’urgence (break-glass) enregistrée.

L’état définit aussi le rayon d’impact (blast radius). Un état géant pour toute une entreprise signifie que chaque plan est lent, que chaque apply met tout en jeu et qu’un seul verrou bloque toutes les équipes. Découper l’état par composant et par environnement (réseau, cluster partagé, ressources de chaque service ; production séparée du staging) garde les plans rapides et les défaillances contenues, au prix de devoir transmettre des sorties, comme les identifiants réseau, d’un état à l’autre. La refactorisation est prise en charge : les blocs moved renomment des ressources sans les détruire, et import place sous gestion des ressources existantes créées à la main.

Modules et environnements

Un module est une unité réutilisable de code d’infrastructure, avec des entrées et des sorties : une base de données PostgreSQL avec sauvegardes et supervision, le réseau et l’équilibreur de charge d’un service, un namespace Kubernetes standard avec ses quotas et ses politiques. Un bon module applique le masquage de l’information du chapitre 3 : une interface réduite (nom, taille, haute disponibilité ou non) devant les nombreux détails propres au fournisseur qu’une équipe de service ne devrait pas avoir à connaître. Les modules sont versionnés et publiés comme des bibliothèques, et les environnements font référence à une version précise, comme le ref=v3.2.0 de l’exemple, afin qu’un changement de module n’atteigne la production que lorsque quelqu’un en fait délibérément la mise à niveau.

Les environnements doivent être construits à partir des mêmes modules avec des entrées différentes, et non à partir de code copié. Une organisation courante consiste en un répertoire (ou un dépôt) par environnement et par composant, chacun avec son propre état, qui appelle des modules partagés et versionnés ; un changement est promu en mettant à jour la version du module ou les entrées en staging, puis en production. Les environnements copiés-collés divergent en quelques mois, jusqu’à ce que le staging ne permette plus de prédire la production. Les workspaces, qui donnent plusieurs états à une même configuration, conviennent mieux aux copies éphémères, comme les environnements de test par branche, qu’au staging et à la production, qui durent.

Méfiez-vous de la sur-abstraction. Un module avec quarante entrées booléennes qui essaie de servir toutes les équipes est aussi difficile à modifier que le code qu’il a remplacé. Préférez quelques modules aux choix affirmés qui encodent les standards de l’organisation : c’est exactement ce qu’une équipe plateforme propose sous forme de golden path à la section 10.7.

Infrastructure immuable ou gestion de configuration

Les outils de gestion de configuration maintiennent des serveurs à longue durée de vie dans un état décrit : Ansible se connecte par SSH et pousse les changements sans agent ; Chef et Puppet font tourner des agents qui récupèrent leur configuration et y convergent périodiquement. Ils fonctionnent, mais chaque serveur accumule un historique : paquets installés pendant un incident, fichiers modifiés à la main, mises à jour appliquées à moitié. Martin Fowler a appelé le résultat un snowflake server (serveur flocon de neige), unique et impossible à reproduire, et a proposé comme remède le phoenix server (serveur phénix), régulièrement brûlé et reconstruit de zéro.

L’infrastructure immuable, terme popularisé par Chad Fowler en 2013, pousse ce remède jusqu’au bout : ne jamais modifier un serveur en fonctionnement. Chaque changement, qu’il s’agisse d’une mise en production applicative ou d’un correctif du système d’exploitation, passe par la construction d’une nouvelle image (une image de conteneur, ou une image de machine avec un outil comme Packer), son test et le remplacement des anciennes instances, généralement par un déploiement progressif ou bleu-vert. Les conteneurs sur Kubernetes sont immuables par défaut. Les avantages sont l’absence de dérive, des instances identiques, des environnements trivialement reproductibles et un retour arrière par redéploiement de l’image précédente ; les coûts sont un pipeline d’images, le besoin de processus jetables et sans état (section 10.3) et un délai plus long pour un changement urgent isolé.

La gestion de configuration n’a pas disparu. Elle reste le bon outil pour les parcs qui ne peuvent pas être remplacés en bloc : serveurs sur site, équipements réseau, bases de données sur du matériel dédié, et les images de base elles-mêmes, souvent construites en exécutant Ansible pendant la construction de l’image. La règle d’architecture est de repousser la mutabilité aussi bas et aussi tôt que possible : configurer pendant la construction des images, puis traiter ce qui tourne comme étant en lecture seule.

GitOps

GitOps applique la boucle de réconciliation de la section 10.2 à des environnements entiers. Le terme a été forgé en 2017 par Alexis Richardson, de Weaveworks, l’entreprise à l’origine de l’outil Flux. Le projet OpenGitOps, un groupe de travail de la CNCF, définit quatre principes : l’état souhaité est déclaratif ; il est versionné et immuable, avec un historique complet ; il est récupéré automatiquement par des agents logiciels ; et il est réconcilié en continu, des agents observant l’état réel et appliquant l’état souhaité. Les deux principaux agents, Argo CD et Flux, sont tous deux des projets diplômés (graduated) de la CNCF ; Flux a continué comme projet communautaire après la fermeture de Weaveworks en 2024.

Le modèle pull a un avantage de sécurité sur un pipeline qui pousse les changements dans le cluster : le système de CI n’a besoin d’aucun identifiant pour la production, car l’agent à l’intérieur du cluster va chercher ce qu’il doit exécuter. Git devient le journal d’audit et l’interface du changement, y compris pour l’exploitation : mettre un service à l’échelle ou revenir en arrière est un commit relu ou un revert. La dérive est corrigée automatiquement, si bien qu’un kubectl edit manuel ne dure que jusqu’à la synchronisation suivante.

GitOps soulève ses propres questions de conception. Les secrets ne doivent pas se trouver en clair dans Git ; les équipes les chiffrent (SOPS, Sealed Secrets) ou stockent des références que l’External Secrets Operator résout à partir d’un gestionnaire de secrets. La promotion entre environnements demande une convention, par exemple un répertoire par environnement, avec des pull requests qui copient un nouveau digest d’image du staging vers la production. La correction automatique de la dérive doit être délibérément suspendue lors de certaines urgences, et la structure du dépôt doit refléter la responsabilité, afin que les équipes puissent modifier leurs propres services sans toucher à ceux des autres. GitOps est le plus naturel pour Kubernetes, mais les mêmes principes s’appliquent à l’infrastructure cloud via Crossplane ou via des pipelines qui planifient et appliquent le code d’infrastructure à partir de commits fusionnés.

Politique en tant que code (policy as code)

La politique en tant que code (policy as code) exprime les règles sur l’infrastructure sous forme de code vérifiable par machine au lieu d’une page de wiki : les buckets de stockage ne doivent pas être publics, les bases de données doivent être chiffrées et sauvegardées, chaque ressource doit porter une étiquette de responsable et de centre de coûts, seules les régions approuvées peuvent être utilisées, les conteneurs ne doivent pas s’exécuter en root, les images de production doivent provenir du registre de l’entreprise. Les vérifications s’exécutent à plusieurs moments : sur le plan dans la pull request (Open Policy Agent avec Conftest, Checkov, HashiCorp Sentinel dans ses produits commerciaux), à l’admission dans un cluster Kubernetes (OPA Gatekeeper, Kyverno) et en continu sur les ressources en fonctionnement (services de politiques des fournisseurs cloud).

La politique en tant que code fait passer la gouvernance d’une réunion de revue à un garde-fou rapide et cohérent qui s’explique de lui-même dans la pull request. Elle fonctionne au mieux quand les politiques sont peu nombreuses, clairement justifiées, versionnées et testées comme n’importe quel code, quand elles commencent en mode avertissement avant de bloquer, et quand il existe un processus d’exception documenté. Le chapitre 11 explique comment ces vérifications automatisées s’intègrent à la gouvernance de l’architecture (la gouvernance dans les organisations agiles).