Qu'est-ce que Infrastructure as Code (IaC) ?

L'idée centrale

L'Infrastructure as Code (IaC) traite l'infrastructure sur laquelle tournent vos applications comme un artefact logiciel. Au lieu de cliquer dans les consoles cloud ou de lancer des commandes shell ad-hoc, les ingénieurs écrivent des fichiers déclaratifs ou impératifs qui décrivent l'état désiré, VPC, sous-réseaux, rôles IAM, namespaces Kubernetes, alertes de monitoring, et un outil réconcilie la réalité avec cette description.

Le glissement paraît modeste. Les conséquences ne le sont pas :

• Chaque changement est relisible. Diffs dans des merge requests, avant que quoi que ce soit ne touche la production.
• Chaque environnement est reproductible. Cloner un staging en 15 minutes, pas en 15 jours.
• La dérive est détectable. Quand quelqu'un corrige quelque chose à 3h du matin en cliquant dans la console, le prochain plan le signale.
• La reprise sur sinistre est plus simple. Reconstruire toute la région depuis Git, avec une seule commande.

Les deux variantes

IaC déclarative (Terraform, OpenTofu, Pulumi, Crossplane, manifests rendus par ArgoCD) décrit ce à quoi le système doit ressembler. L'outil détermine les étapes pour y arriver. La plupart des installations en production utilisent cette approche parce qu'elle passe à l'échelle et converge.

IaC impérative (playbooks Ansible, scripts SDK cloud bruts) décrit comment modifier le système, étape par étape. Utile pour des tâches ponctuelles comme un redémarrage en rolling ou des patchs coordonnés, mais plus difficile à raisonner dans la durée.

Dans nos missions concrètes, nous combinons généralement les deux : Terraform pour le squelette du compte cloud, Helm/Kustomize pour ce qui tourne dans Kubernetes, Ansible pour les rares situations où nous touchons encore directement à une VM.

Où les équipes trébuchent

Quelques patterns tuent les projets IaC :

• Stocker les fichiers d'état sur le laptop de quelqu'un. L'état doit vivre dans un stockage partagé, versionné, verrouillé (S3 + lock DynamoDB, Terraform Cloud, Spacelift). Sinon, deux ingénieurs qui lancent plan en même temps corrompent leur travail mutuel.
• Traiter les secrets comme de la config. Mots de passe, clés API et certificats ne doivent jamais être dans Git. Utiliser Vault, AWS KMS, sealed-secrets, tout ce qui découple le plaintext du contrôle de version.
• Fichiers d'état monolithiques. Un seul état Terraform avec 5 000 ressources prend 20 minutes pour planifier et une erreur pour casser. Le découper par cycle de vie : compte, réseau, services, applications.
• Pas de tests automatisés. terraform plan en CI attrape 90 % des erreurs. Sans ça, l'IaC c'est juste du clic versionné.

Angle conformité

Pour les industries suisses régulées, l'IaC est la façon la moins chère de satisfaire les exigences de change management : chaque modification est dans Git, signée, relue et horodatée. Les auditeurs cessent de demander des captures d'écran et commencent à demander l'accès au dépôt, ce qui est plus rapide pour tout le monde.

Services Hidora associés

• Consulting : design de modules Terraform, séparation des comptes, stratégie d'état.
• Managed Services : exploitation de l'infrastructure IaC une fois construite.