Infrastructure as Code : IaC et automatisation

Pendant des décennies, configurer un serveur signifiait suivre un document Word avec 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 » (snowflake) : chaque serveur unique, irreproductible et terrifiant à toucher. L'Infrastructure as Code (IaC) rompt ce cycle en décrivant serveurs, réseaux, répartiteurs de charge et bases de données dans des fichiers texte versionnés qu'un outil applique automatiquement et de façon répétable. 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 sous-tendent l'IaC, compare les outils dominants et présente 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éer une machine, puis installer le paquet, puis ouvrir 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 déterminer quelles actions sont nécessaires pour y parvenir depuis l'état actuel. La plupart des outils modernes sont déclaratifs, et pour de bonnes raisons : si vous exécutez le même fichier déclaratif deux fois, le résultat est identique, car 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 objectifs distincts qu'il ne faut pas confondre. Terraform (et son fork open source OpenTofu) est l'outil de provisionnement déclaratif multi-cloud par excellence : il utilise le langage HCL et un système de providers pour gérer les ressources sur AWS, Azure, Google Cloud et des centaines d'autres services. AWS CloudFormation fait la même chose mais reste lié exclusivement à l'écosystème Amazon. Ansible excelle dans la gestion de configuration et le provisionnement de logiciels à l'intérieur de serveurs déjà créés, sans agent requis. 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 (state) : le concept le plus délicat de Terraform

Pour savoir quelles différences appliquer, Terraform maintient 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 le désastre : si deux personnes appliquent des changements en même temps, l'état se corrompt ; si l'ordinateur portable est perdu, Terraform perd la trace 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 managé) 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 poussé vers un dépôt Git.

Workflow : plan, revue et apply en CI/CD

Le grand avantage de traiter l'infrastructure comme du code est qu'elle hérite du workflow de développement logiciel. Le cycle recommandé est : écrire le changement dans une branche, ouvrir une pull request, exécuter automatiquement terraform plan pour que l'équipe puisse examiner exactement quelles ressources vont être créées, modifiées ou détruites avant d'approuver, et exécuter terraform apply seulement après approbation, 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, une traçabilité complète (chaque modification a un auteur, une date et une raison dans l'historique Git) et la capacité d'annuler un changement dommageable en revenant à une version antérieure du code.

Sécurité et conformité en tant que 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 IaC analysent les manifestes à la recherche de configurations dangereuses (un bucket de stockage ouvert sur 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'articule directement avec les référentiels de conformité : le contrôle des changements et la traçabilité qu'exige l'ISO/IEC 27001 pour la gestion de la sécurité de l'information sont satisfaits naturellement dès lors que chaque changement d'infrastructure passe par une revue dans une pull request. Et lorsque l'infrastructure traite des données personnelles, le principe de protection des données dès la conception du RGPD (article 25) se concrétise en codant le chiffrement, la segmentation réseau et les contrôles d'accès directement dans les manifestes, plutôt qu'en les ajoutant après coup.

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 modèle 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 seule fois comme module paramétré et on l'invoque avec différentes valeurs. Cela applique le principe « ne pas se répéter » à l'infrastructure et réduit drastiquement les erreurs de copier-coller. Concernant les environnements, la bonne pratique consiste à garder développement, staging et production avec le même code mais des fichiers de variables différents, garantissant que ce qui est testé en staging est structurellement identique à ce qui s'exécutera en production. Cette parité des environnements élimine la classique excuse du « ça marchait sur mon poste ».

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 faits « juste cette fois » en urgence. Le drift est dangereux car le prochain apply peut annuler ce correctif d'urgence sans prévenir, ou échouer de façon confuse. La défense est double : d'une part, exécuter périodiquement une détection automatisée du drift qui compare l'état et la réalité et vous alerte des différences ; d'autre part, une discipline culturelle non négociable selon laquelle chaque changement passe par le code, sans exception. Lorsqu'une urgence impose un changement manuel, la règle est de le refléter immédiatement dans le code avant de clore l'incident, afin que le dépôt reste la source unique de vérité pour l'infrastructure.

Erreurs courantes qui ruinent un projet IaC

• État local ou non verrouillé : la source 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 annuler ce correctif ou échouer.
• Secrets dans le dépôt : mettre des mots de passe ou des clés dans les fichiers .tf ou dans un état versionné. Il faut utiliser un gestionnaire de secrets.
• Un état monolithique unique : mettre toute l'infrastructure dans un seul état rend chaque changement lent et risqué. Il est préférable de segmenter par environnement et par domaine.
• Appliquer sans examiner le plan : approuver aveuglément équivaut à cliquer en production sans regarder.

Questions fréquentes

Quelle est la 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 sur plusieurs clouds. 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 l'aménage.

Qu'est-ce que l'idempotence et pourquoi est-ce important ?

C'est la propriété selon laquelle appliquer le même manifeste plusieurs fois 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ù faut-il conserver 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 managé). 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 à la conformité ISO 27001 ou RGPD ?

Oui. Le contrôle des changements, révisable et traçable, qu'elle fournit répond aux exigences de l'ISO/IEC 27001, et coder le chiffrement, la segmentation et le contrôle d'accès dans les manifestes concrétise le principe de protection des données dès la conception de l'article 25 du RGPD.

Conclusion : une infrastructure reconstructible est une infrastructure résiliente

L'épreuve de vérité d'un projet IaC bien construit est brutalement simple : si toute une région de votre fournisseur cloud disparaissait demain, pourriez-vous reconstruire l'intégralité de votre environnement à partir du code en quelques heures, sans que personne n'ait à se souvenir de 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 effet de mode, 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 workflow plan-revue-apply en CI/CD et la sécurité codée dès la conception ne sont pas des ornements : ce sont eux qui transforment un ensemble 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.