Infrastructure as Code : IaC et automatisation

Pendant des décennies, monter un serveur consistait à suivre un document Word de quarante étapes manuelles, à cliquer dans des consoles web et à prier pour que l'environnement de production ressemble à celui de test. Le résultat était le syndrome du « flocon de neige » : chaque serveur unique, irreproductible et terrifiant à toucher. L'infrastructure as code (IaC) brise ce cercle en décrivant serveurs, réseaux, équilibreurs de charge et bases de données dans des fichiers texte versionnés qu'un outil applique de façon automatique et reproductible. L'infrastructure cesse d'être un artisanat et devient du logiciel : révisable, testable et reconstructible à partir de zéro. Cet article explique les concepts qui soutiennent l'IaC, compare les outils dominants et concrétise les bonnes pratiques qui séparent un projet solide d'un champ de mines.

Déclaratif contre impératif : la distinction qui change tout

Il existe deux philosophies pour automatiser l'infrastructure. L'approche impérative décrit les étapes à exécuter (« crée une machine, puis installe le paquet, puis ouvre le port »). L'approche déclarative décrit l'état final souhaité (« je veux trois serveurs web avec ce paquet et ce port ouvert ») et laisse l'outil calculer quelles actions sont nécessaires pour y parvenir depuis l'état actuel. La plupart des outils modernes sont déclaratifs, et pour une bonne raison : si vous exécutez deux fois le même fichier déclaratif, le résultat est identique parce que l'outil n'applique que les différences. Cette propriété s'appelle l'idempotence et constitue le cœur de l'IaC. Un script impératif exécuté deux fois peut créer des ressources en double ou échouer ; un manifeste déclaratif idempotent converge toujours vers le même état.

Les outils dominants : Terraform, Ansible, CloudFormation et Pulumi

L'écosystème se répartit entre quatre grands noms aux finalités distinctes qu'il convient de ne pas confondre. Terraform (et sa bifurcation open source OpenTofu) est l'outil de provisionnement déclaratif multicloud par excellence : il utilise le langage HCL et un système de providers pour gérer des ressources sur AWS, Azure, Google Cloud et des centaines d'autres services. AWS CloudFormation fait la même chose mais reste exclusivement lié à l'écosystème d'Amazon. Ansible brille dans la gestion de configuration et le provisionnement logiciel à l'intérieur des serveurs déjà créés, sans nécessité d'agent. Pulumi permet d'écrire l'infrastructure dans de vrais langages de programmation (TypeScript, Python, Go) plutôt que dans un DSL spécifique. En pratique, une architecture mature combine Terraform pour créer l'infrastructure de base et Ansible pour configurer ce qui vit à l'intérieur.

L'état : le concept le plus délicat de Terraform

Pour savoir quelles différences appliquer, Terraform tient à jour un fichier d'état (terraform.tfstate) qui enregistre la correspondance entre ce que vous avez déclaré et ce qui existe réellement dans le cloud. C'est là que se concentrent les problèmes les plus graves d'un projet IaC. Conserver l'état sur l'ordinateur portable d'un ingénieur est une recette pour la catastrophe : si deux personnes appliquent des changements en même temps, l'état se corrompt ; si le portable est perdu, Terraform perd la notion de ce qu'il gère. La bonne pratique obligatoire est l'état distant avec verrouillage : le stocker dans un backend partagé (par exemple un bucket S3 avec verrouillage, ou un backend géré) qui empêche les exécutions simultanées. De plus, le fichier d'état contient souvent des secrets en clair (mots de passe de bases de données, clés), il doit donc être chiffré au repos et ne jamais être versionné dans un dépôt Git.

Flux de travail : plan, revue et application en CI/CD

Le grand avantage de traiter l'infrastructure comme du code est qu'elle hérite du flux du développement logiciel. Le cycle recommandé est le suivant : écrire le changement dans une branche, ouvrir une pull request, exécuter automatiquement terraform plan pour que l'équipe examine exactement quelles ressources vont être créées, modifiées ou détruites avant d'approuver, et seulement après l'approbation exécuter terraform apply depuis un pipeline d'intégration continue. Cette discipline apporte trois garanties que le clic manuel n'a jamais offertes : la revue par les pairs de chaque changement d'infrastructure, la traçabilité complète (chaque modification a un auteur, une date et un motif dans l'historique de Git) et la capacité de revenir sur un changement nuisible en restaurant une version antérieure du code.

Sécurité et conformité as code

L'IaC ne fait pas qu'automatiser ; elle permet d'auditer la sécurité avant le déploiement. Les outils de policy as code et les scanners d'IaC analysent les manifestes à la recherche de configurations dangereuses — un bucket de stockage ouvert à internet, un groupe de sécurité avec le port 22 exposé au monde entier, le chiffrement désactivé — et bloquent le déploiement s'ils enfreignent les règles. Cela s'imbrique directement avec les cadres de conformité : la maîtrise des changements et la traçabilité qu'exige l'ISO/IEC 27001 pour la gestion de la sécurité de l'information sont satisfaites de façon naturelle dès lors que chaque changement d'infrastructure passe par une revue en pull request. Et lorsque l'infrastructure traite des données à caractère personnel, le principe de protection des données dès la conception du RGPD (article 25) se matérialise en codant le chiffrement, la segmentation réseau et les contrôles d'accès directement dans les manifestes, et non en les ajoutant a posteriori.

Modules, environnements et la lutte contre le drift

À mesure que le projet grandit, l'organisation du code devient aussi importante que la justesse de chaque ressource. Le schéma recommandé consiste à encapsuler l'infrastructure répétitive dans des modules réutilisables : au lieu de copier-coller la définition d'un réseau privé dans chaque projet, on la définit une fois comme module paramétré et on l'invoque avec différentes valeurs. Cela applique le principe « ne te répète pas » à l'infrastructure et réduit considérablement les erreurs de copie. Concernant les environnements, la bonne pratique consiste à maintenir développement, préproduction et production avec le même code mais des fichiers de variables différents, en garantissant que ce qui est testé en préproduction est identique en structure à ce qui tournera en production. Cette parité des environnements élimine la classique excuse du « sur mon environnement ça marchait ».

L'ennemi silencieux de tout projet mature est le drift : la divergence entre ce que dit le code et ce qui existe réellement dans le cloud, causée par des changements manuels effectués « juste cette fois » dans l'urgence. Le drift est dangereux parce que le prochain apply peut défaire ce correctif d'urgence sans prévenir, ou échouer de façon déroutante. La défense est double : d'une part, exécuter périodiquement une détection de drift automatisée qui compare état et réalité et alerte sur les différences ; d'autre part, une discipline culturelle non négociable selon laquelle tout changement passe par le code, sans exception. Lorsqu'une urgence oblige à intervenir à la main, la règle est de refléter immédiatement ce changement dans le code avant de clore l'incident, de sorte que le dépôt demeure l'unique source de vérité de l'infrastructure.

Erreurs courantes qui ruinent un projet d'IaC

• État local ou sans verrouillage : l'origine de 80 % des désastres. L'état doit être distant, chiffré et avec verrouillage de concurrence.
• Changements manuels hors du code (drift) : toucher une ressource à la main dans la console web rompt la correspondance avec le code ; le prochain apply peut défaire ce correctif ou échouer.
• Secrets dans le dépôt : placer des mots de passe ou des clés dans les fichiers .tf ou dans l'état versionné. Il faut utiliser un gestionnaire de secrets.
• Un unique état monolithique : mettre toute l'infrastructure dans un seul état rend chaque changement lent et risqué. Il convient de segmenter par environnement et par domaine.
• Appliquer sans relire le plan : approuver à l'aveugle équivaut à cliquer en production sans regarder.

Foire aux questions

Quelle différence entre Terraform et Ansible ?

Terraform provisionne l'infrastructure (crée serveurs, réseaux, bases de données) de façon déclarative et multicloud. Ansible configure ce qui vit à l'intérieur de ces serveurs (installe des paquets, ajuste des services). Ils se complètent : Terraform construit la maison, Ansible la meuble.

Qu'est-ce que l'idempotence et pourquoi importe-t-elle ?

C'est la propriété par laquelle appliquer plusieurs fois le même manifeste produit toujours le même état final, sans dupliquer de ressources ni rien casser. C'est ce qui rend l'IaC prévisible et sûre à réexécuter.

Où doit être conservé le fichier d'état de Terraform ?

Dans un backend distant partagé avec verrouillage de concurrence et chiffrement au repos (par exemple un bucket avec verrouillage ou un backend géré). Jamais sur l'ordinateur portable d'un ingénieur ni dans le dépôt Git, car il contient généralement des secrets.

L'IaC aide-t-elle à respecter ISO 27001 ou le RGPD ?

Oui. La maîtrise des changements révisable et traçable qu'elle apporte s'imbrique avec les exigences d'ISO/IEC 27001, et coder le chiffrement, la segmentation et le contrôle d'accès dans les manifestes matérialise le principe de protection des données dès la conception de l'article 25 du RGPD.

Conclusion : l'infrastructure reconstructible est l'infrastructure résiliente

L'épreuve du feu d'un projet d'IaC bien fait est brutalement simple : si demain une région entière de votre fournisseur cloud était perdue, pourriez-vous reconstruire tout votre environnement à partir du code en quelques heures, sans que personne n'ait à se rappeler de mémoire ce qui avait été configuré à la main ? Quand la réponse est oui, vous avez éliminé le syndrome du flocon de neige et transformé la reprise après sinistre d'un cauchemar improvisé en une procédure exécutable. Chez Summum Sistemas, nous défendons l'IaC non par modernité, mais parce qu'elle transforme l'infrastructure en un actif qui se révise comme du code, s'audite comme du code et se reconstruit comme du code. L'état distant et verrouillé, le flux plan-revue-application en CI/CD et la sécurité codée dès la conception ne sont pas des ornements : ce sont eux qui transforment un tas de serveurs fragiles en une plateforme que votre équipe ose modifier sans crainte. Et une équipe qui ne craint pas sa propre infrastructure est une équipe qui livre plus vite et dort mieux.