Terraform, Ansible, IaC déclaratif, drift detection, CI/CD : maîtrisez l'Infrastructure as Code pour industrialiser votre infrastructure. Guide complet Smile.
Une infrastructure configurée manuellement est une infrastructure dont personne ne connaît vraiment l'état. Un serveur modifié en urgence sans documentation. Une différence entre staging et production que personne ne sait expliquer. Un déploiement qui fonctionne sur un environnement et échoue sur un autre pour des raisons obscures.
L'infrastructure as code résout ces problèmes à la racine. En codant l'infrastructure plutôt qu'en la cliquant, elle devient versionnée, reproductible, testable et déployable en une commande.
Ce guide vous explique les fondamentaux, les deux outils de référence (Terraform et Ansible) et les bonnes pratiques pour mettre en place l'IaC dans votre organisation.
Qu'est-ce que l'Infrastructure as Code ?
L'infrastructure as code (IaC) est la pratique qui consiste à décrire, provisionner et gérer l'infrastructure informatique (serveurs, réseaux, bases de données, règles de sécurité) via du code versionné dans un dépôt Git, plutôt que via des configurations manuelles ou des interfaces graphiques.
L'infrastructure devient ainsi un actif logiciel comme un autre : elle est révisée, testée, versionnée et déployée avec les mêmes pratiques que le code applicatif.
IaC et DevOps : un binôme indissociable
L'IaC est l'une des pratiques fondamentales du DevOps. Elle comble le fossé historique entre les développeurs qui livrent du code et les équipes Ops qui gèrent l'infrastructure sur laquelle ce code s'exécute. Quand l'infrastructure est codée, les développeurs peuvent contribuer à sa définition, les équipes Ops peuvent la réviser comme du code et tout le monde partage la même vision de l'état de l'environnement.
Les bénéfices fondamentaux
Trois bénéfices justifient l'adoption de l'IaC dans toute organisation qui opère une infrastructure en production.
La reproductibilité est le premier. Un environnement décrit en IaC peut être recréé à l'identique en quelques minutes, sur n'importe quel cloud ou datacenter. Plus de "ça marchait sur mon environnement".
Le versionning est le deuxième. Chaque modification de l'infrastructure est tracée dans Git avec un auteur, une date et un message de commit. L'historique complet est consultable, le rollback est possible.
La collaboration est le troisième. Les modifications d'infrastructure passent par des pull requests, sont reviewées par les pairs et validées avant d'être appliquées. Fini les modifications non documentées en production.
IaC déclaratif vs impératif
Il existe deux approches de l'IaC.
L'approche déclarative consiste à décrire l'état final désiré de l'infrastructure. L'outil se charge de calculer les actions nécessaires pour atteindre cet état. Terraform utilise cette approche. Avantage : idempotence naturelle et lisibilité.
L'approche impérative consiste à décrire les actions à exécuter pour atteindre l'état désiré. Ansible peut fonctionner en mode impératif, bien qu'il privilégie l'idempotence. Avantage : flexibilité et contrôle fin sur l'ordre d'exécution.
Terraform : l'IaC multi-cloud de référence
Terraform est l'outil de provisioning d'infrastructure déclaratif développé par HashiCorp et open source depuis sa création. Il est devenu le standard de facto pour provisionner des ressources cloud sur AWS, Azure, GCP et des dizaines d'autres providers.
Les concepts clés
- Provider : le connecteur qui permet à Terraform d'interagir avec une API cloud ou un service tiers (AWS, Azure, GCP, Kubernetes, GitHub)
- Resource : la ressource infrastructure à créer ou gérer (une instance EC2, un groupe de sécurité, un bucket S3)
- State : le fichier qui contient l'état actuel de l'infrastructure gérée par Terraform. C'est la mémoire de Terraform, qui lui permet de calculer les différences entre l'état désiré et l'état réel
- Module : un ensemble de ressources réutilisables, packagées pour être partagées entre projets ou équipes
Le workflow Terraform
Un déploiement Terraform suit quatre étapes.
- terraform init : initialise le projet, télécharge les providers et les modules nécessaires
- terraform plan : calcule et affiche les changements qui seront appliqués sans les exécuter. C'est l'étape de revue avant toute modification
- terraform apply : applique les changements planifiés et met à jour le state
- terraform destroy : supprime toutes les ressources gérées par le projet
Terraform Cloud et les alternatives
Terraform Cloud (HashiCorp) est la plateforme SaaS qui gère le state à distance, orchestre les plans et applys, et intègre les workflows de validation. OpenTofu est le fork open source de Terraform maintenu par la Linux Foundation, né après le changement de licence de HashiCorp en 2023. Pulumi est une alternative qui permet d'écrire l'infrastructure en langages de programmation classiques (Python, TypeScript, Go) plutôt qu'en HCL.
Ansible : l'automatisation de configuration
Ansible est un outil d'automatisation open source développé par Red Hat. Son positionnement est complémentaire à Terraform : là où Terraform provisionne l'infrastructure, Ansible configure les systèmes et déploie les applications sur cette infrastructure.
Les concepts clés
- Inventaire : la liste des machines cibles (serveurs, VMs, conteneurs) sur lesquelles Ansible va opérer, définie en YAML ou en fichier INI
- Playbook : le fichier YAML qui décrit les tâches à exécuter sur les machines de l'inventaire, dans l'ordre défini
- Rôle : un ensemble de tâches, variables et fichiers organisés de manière réutilisable et partageable
- Module : la brique élémentaire qui exécute une action précise (installer un package, copier un fichier, redémarrer un service)
L'idempotence : le principe fondamental
L'idempotence signifie qu'exécuter un playbook Ansible plusieurs fois sur la même machine produit toujours le même résultat. Si le package est déjà installé, Ansible ne le réinstalle pas. Si le fichier est déjà en place, Ansible ne le réécrit pas.
C'est ce principe qui rend Ansible fiable en production : on peut exécuter un playbook sans craindre d'altérer un système déjà correctement configuré.
Ansible vs Puppet vs Chef
OutilApprocheAgent requisLangageCourbe d'apprentissageAnsibleAgentless, SSHNonYAMLFaiblePuppetAgentbasedOuiDSL PuppetÉlevéeChefAgentbasedOuiRuby/DSLÉlevéeSaltStackHybrideOptionnelYAML/PythonMoyenne
[tableau dans le gsheet à copier ci]
Ansible s'impose dans la majorité des nouveaux projets grâce à son architecture agentless (pas de daemon à installer sur les machines cibles) et à sa simplicité de prise en main.
Terraform vs Ansible : quand utiliser l'un ou l'autre ?
Critère | Terraform | Ansible |
Rôle principal | Provisioning d'infrastructure | Configuration et déploiement |
Approche | Déclarative | Déclarative et impérative |
State management | Oui (state file) | Non |
Idempotence | Native | Dépend des modules |
Gestion du cloud | Excellente | Limitée |
Configuration OS | Limitée | Excellente |
Courbe d'apprentissage | Moyenne | Faible |
La combinaison gagnante
Terraform et Ansible ne sont pas concurrents. Ils couvrent deux couches distinctes.
Terraform crée l'infrastructure : les VMs, les réseaux, les groupes de sécurité, les bases de données managées. Ansible configure ce que Terraform a créé : installe les packages, déploie les applications, configure les services, gère les certificats.
Ensemble, ils couvrent l'intégralité du cycle de vie de l'infrastructure as code, du provisioning initial à la maintenance continue.
IaC en production : bonnes pratiques
1. Versionner et réviser comme du code applicatif
Tout le code IaC vit dans Git. Chaque modification passe par une pull request reviewée par au moins un pair. Les branches de fonctionnalités isolent les changements en cours. Les tags marquent les versions stables.
2. Tester l'infrastructure
Des outils comme Terratest (Go) ou Kitchen-Terraform permettent d'écrire des tests automatisés qui vérifient le comportement réel de l'infrastructure après un apply. C'est l'équivalent des tests unitaires pour le code IaC.
3. Détecter et corriger le drift de configuration
Le drift de configuration survient quand l'état réel de l'infrastructure s'éloigne de l'état décrit dans le code. Terraform détecte ce drift lors de chaque plan. Des outils de drift detection comme driftctl permettent de surveiller en continu l'écart entre le code et la réalité.
4. Intégrer l'IaC dans le CI/CD
Chaque modification du code IaC déclenche automatiquement un terraform plan dans le pipeline CI/CD, dont le résultat est affiché dans la pull request pour review. L'apply est déclenché automatiquement ou manuellement après approbation, selon le niveau de risque du changement.
5. Gérer les secrets correctement
Les mots de passe, tokens et clés API ne doivent jamais apparaître en clair dans le code IaC. Utiliser HashiCorp Vault, AWS Secrets Manager ou Azure Key Vault pour externaliser les secrets et les injecter dynamiquement lors de l'exécution.
Smile et l'IaC : notre expertise DevOps
Chez Smile, nous pratiquons et accompagnons l'adoption de l'infrastructure as code depuis ses premières heures. Notre expertise couvre Terraform pour le provisioning multi-cloud (AWS, Azure, GCP, cloud souverain), Ansible pour la configuration et le déploiement, et l'intégration de ces pratiques dans des pipelines CI/CD complets.
Nous accompagnons aussi bien les équipes qui démarrent avec l'IaC (audit de l'existant, mise en place des premiers modules Terraform, formation des ingénieurs) que celles qui cherchent à industrialiser leurs pratiques existantes (testing, drift detection, gestion des secrets, GitOps).
Notre conviction : une infrastructure codée est une infrastructure maîtrisée. Tout le reste est de l'espoir.
Vous souhaitez adopter l'Infrastructure as Code dans votre organisation ? Découvrez notre approche DevOps et IaC.
Questions fréquentes sur l'Infrastructure as Code
Faut-il choisir entre Terraform et Ansible ?
Non. Les deux outils sont complémentaires et couvrent des périmètres différents. Terraform excelle pour provisionner les ressources cloud (VMs, réseaux, bases de données). Ansible excelle pour configurer les systèmes et déployer les applications sur ces ressources. La combinaison des deux couvre l'intégralité du cycle de vie de l'infrastructure. La majorité des équipes DevOps matures utilisent les deux en pipeline.
Que faire si le state Terraform est corrompu ?
Un state Terraform corrompu est l'un des incidents les plus stressants pour une équipe IaC. La prévention passe par trois mesures : stocker le state dans un backend distant sécurisé (S3, Azure Blob, Terraform Cloud) avec versioning activé, activer le locking du state pour éviter les modifications concurrentes, et ne jamais modifier le state manuellement sauf en dernier recours avec terraform state commands. En cas de corruption, les snapshots du backend distant permettent de restaurer une version antérieure.
L'IaC fonctionne-t-elle avec des infrastructures on-premise ?
Oui. Terraform dispose de providers pour VMware, Proxmox, Nutanix et la plupart des solutions de virtualisation on-premise. Ansible est encore plus adapté aux environnements on-premise car il ne nécessite qu'une connectivité SSH vers les machines cibles. L'IaC on-premise est souvent le point de départ des organisations qui souhaitent ensuite migrer vers le cloud de manière progressive et maîtrisée.
Comment former une équipe à l'IaC rapidement ?
Trois étapes permettent une montée en compétences rapide. D'abord, commencer par Ansible dont la courbe d'apprentissage est faible grâce à la syntaxe YAML. Ensuite, introduire Terraform sur un périmètre cloud limité (un environnement de développement) pour que l'équipe apprenne à gérer le state et les plans sans risque. Enfin, industrialiser avec du testing et du CI/CD une fois que les bases sont maîtrisées. Des formations certifiantes HashiCorp et Red Hat sont disponibles pour les équipes qui veulent structurer leur apprentissage.