Infrastructure as Code (IaC) : Automatiser le provisionnement réseau et système avec Terraform et Ansible

Pourquoi l’infrastructure as code (IaC) change vraiment la façon de gérer l’infra

On l’a tous fait. Tu arrives sur une console cloud, tu cliques un peu partout, tu ajustes une règle firewall « vite fait », tu crées un subnet à la main, tu lances une VM. Et ça marche. Jusqu’au jour où ça ne marche plus.

Le « clicops » a un côté rassurant au début. On voit ce qu’on fait. Sur improvise. On dépanne. Sauf que l’infra, elle, n’oublie rien. Et elle finit toujours par te rappeler que tu as bricolé.

L’IaC, au fond, c’est l’idée inverse. On décrit l’environnement en code, on le versionne, on le rejoue, on le revoit comme n’importe quel logiciel. Et ce que ça couvre est beaucoup plus large que « créer une VM ».

• Provisionnement : VPC/VNet, sous-réseaux, VM, équilibreurs de charge, DNS, IAM.
• Configuration : OS, paquets, utilisateurs, services, durcissement.
• Réseau et sécurité : segmentation, règles ingress/egress, routes.
• Versioning : historique Git, pull requests, tags de version, rollback.

Et les bénéfices sont mesurables, pas juste « c’est plus propre » :

• Vitesse : recréer un env en minutes, pas en jours.
• Cohérence : mêmes paramètres, mêmes dépendances, même résultat.
• Auditabilité : qui a changé quoi, quand, via quelle PR.
• Rollback : revenir à une version connue.
• Moins d’erreurs humaines : moins d’oubli, moins de « je pensais que... ».

Dans cet article, on va prendre une approche pragmatique, celle qui marche dans la vraie vie : Terraform pour créer et brancher l’infrastructure, Ansible pour configurer le système et les services. Deux outils, deux rôles clairs. Et une infra qui devient reproductible.

Le vrai problème du provisionnement manuel (et ce que l’IaC corrige)

Le problème du manuel n’est pas que tu es mauvais. Le problème, c’est que le manuel est un processus sans mémoire fiable.

Premier classique : la dérive de configuration, le fameux configuration drift. Deux serveurs « identiques » au départ. Puis un patch appliqué sur l’un mais pas l’autre. Une règle SSH modifiée ici. Un param sysctl là. Trois mois plus tard, ils ne se ressemblent plus. Et évidemment, la prod tombe toujours sur celui qui est différent.

Ensuite, la reconstruction d’un environnement. Refaire une préprod identique à la prod, ou remonter un environnement dev clean pour tester une migration. Si tout a été cliqué, noté dans un wiki à moitié à jour, ou pire dans la tête de quelqu’un, tu vas reconstruire un truc « proche ». Pas identique.

Et la traçabilité... faible, voire inexistante. Qui a changé cette route ? Pourquoi ce port est ouvert depuis Internet ? Quand est apparu ce user local ? Souvent, tu as un début de réponse dans les logs du provider. Souvent, tu n’as pas le contexte. Et sans contexte, c’est juste du bruit.

Côté sécurité, c’est encore plus sensible :

• Règles firewall modifiées sans revue.
• Identifiants qui traînent en clair dans un fichier ou un terminal.
• Erreurs de routage entre sous-réseaux.
• Accès trop larges « temporairement », qui deviennent permanents.

L’IaC introduit une discipline parce qu’elle force un chemin : du code, une revue, un historique Git, un pipeline CI/CD, des standards. Pas forcément lourd. Juste… rigoureux.

Tu ne « changes pas un truc ». Tu proposes un changement, tu le fais relire, tu le testes, tu le déploies. Et tu peux prouver ce qui a été fait.

Terraform vs Ansible : rôles, limites, et pourquoi les combiner

Terraform et Ansible sont souvent comparés. En pratique, ils sont complémentaires. Et quand tu les utilises chacun pour ce qu’il fait le mieux, tu gagnes en simplicité.

Terraform est déclaratif. Tu écris l’état désiré de l’infrastructure : « je veux un VPC, trois subnets, un NAT gateway, deux instances, un load balancer ». Puis Terraform calcule la différence entre ce que tu veux et ce qui existe. Et applique.

Ansible, lui, est un outil de configuration et d’orchestration. Il s’occupe très bien de l’OS et des services : packages, fichiers de config, users, clés SSH, hardening, démarrage de services, règles firewall au niveau hôte.

L’idée clé, celle à garder en tête :

• Terraform crée les ressources.
• Ansible rend les machines prêtes applicativement.

Les limites typiques aident à trancher :

• Terraform n’est pas idéal pour configurer finement l’OS. Oui, tu peux faire du cloud-init, des provisioners, des scripts. Mais à grande échelle, ça devient vite pénible à maintenir.
• Ansible n’est pas fait pour « créer » un réseau cloud complet avec gestion de dépendances, state, diff, etc. Il peut appeler des modules cloud, mais ce n’est pas sa force principale.

Schéma mental simple, avec un exemple concret :

• Terraform : créer un réseau 3 tiers (public, app, db), créer des VM dans app, exposer un load balancer dans public.
• Ansible : installer Nginx sur les VM app, configurer SSH, activer UFW ou firewalld, poser des configs, démarrer les services.

Tu sépares ce qui bouge souvent (config) de ce qui doit être stable (infra), sans mélanger les responsabilités.

Les prérequis pour un workflow propre (avant d’écrire la moindre ligne)

Avant le code, il y a l’organisation. Et c’est souvent là que les projets IaC se plantent. Pas sur Terraform. Sur « comment on travaille ».

D’abord, la cible. Cloud public (AWS, Azure, GCP) ou on prem (VMware, Proxmox). Peu importe, l’approche reste la même. Ce qui compte, c’est de rester agnostique dans ta manière de structurer. Des modules réseau, des modules compute, un dossier par environnement.

Ensuite, le dépôt.

Deux organisations courantes, et les deux peuvent fonctionner :

• Par environnement : dev, staging, prod. Utile quand les environnements sont vraiment séparés.
• Par domaines modulaires : network, compute, security. Utile quand tu veux réutiliser et composer.

Les secrets. On pose la règle tout de suite : on ne commit jamais de secrets. Ni en clair, ni « juste pour tester ». Ça finit toujours par fuiter.

Options réalistes :

• Vault (HashiCorp Vault).
• Secrets manager cloud (SSM Parameter Store, Key Vault, Secret Manager).
• Ansible Vault pour chiffrer des variables, quand c’est le bon niveau.

Normes d’équipe :

• terraform fmtterraform validate
• conventions de nommage, tags systématiques.
• doc minimale, même une page, mais une page vraie.

Contrôle d’accès :

• comptes IAM ou service principals dédiés.
• principe du moindre privilège.
• séparation nette entre dev et prod.

Tu veux que le workflow survive à l’équipe, pas l’inverse.

Terraform pour le réseau : automatiser VPC/VNet, sous-réseaux, routage et sécurité

Le réseau, c’est le meilleur candidat pour démarrer en IaC. Parce que c’est pénible à faire à la main, et critique à bien faire.

Composants typiques à coder :

• VPC/VNet.
• subnets publics et privés.
• route tables, associations.
• NAT, internet gateway, peering éventuel.
• gateways selon cloud.

Sécurité réseau :

• security groups ou NSG.
• règles ingress et egress.
• segmentation par tiers : public, app, db.
• pas de « 0.0.0.0/0 partout », même si c’est tentant à 23h.

DNS et IP :

• IP publiques si besoin.
• private DNS, zones internes.
• enregistrements essentiels, surtout pour les services internes.

Bonnes pratiques Terraform ici :

• variables pour CIDR, régions, naming.
• outputs propres : IDs, CIDR, noms de subnets, etc.
• envownercost_centerapp
• séparation réseau vs compute : le réseau change moins souvent, et ça aide à isoler le blast radius.

Mini scénario : un réseau 3 tiers prêt pour accueillir des VM.

Tu décris :

• 1 réseau.
• 1 subnet public (load balancer, bastion éventuel).
• 1 subnet app privé (serveurs applicatifs).
• 1 subnet db privé (bases).
• routes : le public sort direct, les privés sortent via NAT.
• règles : le public reçoit du 80/443, l’app reçoit seulement depuis le LB, la db reçoit seulement depuis l’app.

Même sans écrire une ligne ici, l’objectif est clair : tu peux recréer ça à l’identique, et tu peux relire les règles comme on relit un code.

Terraform pour le compute : VM/instances, load balancer et dépendances

Une fois le réseau posé, le compute devient plus simple. Et tu veux rester discipliné : Terraform crée, Ansible configure.

Création de VM/instances :

• image (AMI, image Azure, template VMware).
• taille.
• disques et types de volumes.
• labels ou tags.
• cloud-init si pertinent, mais minimal.

Attachement au réseau :

• choix du subnet.
• security groups.
• IP privée, IP publique si nécessaire.
• health checks si load balancer.

Éléments fréquents :

• load balancer (L4 ou L7).
• groupes d’instances.
• auto scaling, au moins conceptuellement, même si tu ne l’actives pas au début.

Outputs utiles pour la suite :

• IP privées et publiques.
• noms DNS.
• IDs des instances.
• adresses du load balancer.

Point important : limiter la config OS dans Terraform.

Le bon « bootstrap » Terraform ressemble à :

• un user initial,
• une clé SSH,
• éventuellement l’installation d’un agent minimal (SSM, Cloud Init de base),
• et c’est tout.

Si tu commences à mettre des dizaines de lignes de scripts bash dans Terraform, tu vas le sentir passer au premier changement de config.

State Terraform : le point qui fait réussir (ou échouer) un projet IaC

planapply

À quoi sert le state :

• savoir quelles ressources sont gérées.
• calculer un diff fiable.
• gérer les dépendances.

Le state distant est recommandé presque tout le temps. Backend typiques :

• S3 avec verrouillage (DynamoDB) côté AWS.
• Azure Storage avec lock.
• GCS côté GCP.

apply

Séparation des states :

• par environnement, toujours.
• networkapp

Risques :

• corruption.
• suppression accidentelle.
• drift.

Réduction du risque :

• versioning et backups du backend.
• plan
• accès restreint au state, pas en lecture publique, jamais.

Routine de travail saine :

• terraform init
• terraform plan
• terraform apply

Modules Terraform : factoriser sans se perdre

La modularisation, c’est le moment où ton projet devient maintenable. Ou devient une usine à gaz, si tu vas trop loin.

Pourquoi modulariser :

• réutilisation.
• cohérence entre environnements.
• moins de copier coller.
• corrections centralisées.

Un module contient :

• variables (son API).
• ressources.
• outputs.
• README minimal : inputs, outputs, exemple.

Exemples de modules pertinents :

• network
• compute
• security_baseline

Versionner les modules :

• registry interne si tu es équipe.
• tags Git.
• pinning de versions : ne jamais « pointer sur main » en prod.

Pièges fréquents :

• modules trop génériques : 40 variables, personne ne sait quoi mettre.
• abstraction excessive : tu ne comprends plus ce qui est créé.
• API instable : changements cassants tout le temps.

Garde une API simple. Un module doit rendre la chose facile, pas plus compliquée.

Ansible pour la configuration système : rendre les machines prêtes et cohérentes

Ansible brille quand tu veux des machines cohérentes, rejouables, et auditées.

Inventaire :

• statique si tu as peu de machines.
• dynamique si tu es dans le cloud et que les instances bougent.
• webappdb

Playbooks et rôles :

• un playbook orchestrateur, léger.
• commonhardeningnginxdocker

Idempotence : c’est non négociable. Tu dois pouvoir rejouer un playbook sans « casser » le système, et sans effets de bord. L’état final doit être prévisible.

Tâches courantes, très concrètes :

• gestion des users, clés SSH, sudoers.
• packages et mises à jour.
• firewall hôte (UFW, firewalld).
• sysctl, limites, kernel params.
• services : enable, start, restart via handlers.
• logs, rotation, time sync (chrony).

Bonnes pratiques :

• handlers pour redémarrer proprement.
• group_vars/devgroup_vars/prod
• templates Jinja2 pour configs.
• ansible-playbook --syntax-checkansible-lint

Le but n’est pas d’écrire des playbooks « intelligents ». Le but est d’écrire des playbooks fiables.

Ansible pour la couche applicative (sans transformer Ansible en « tout en un »)

Ansible peut aller plus haut que l’OS. Installer Nginx, configurer un reverse proxy, déployer un agent de monitoring, poser un runtime Java. Oui.

Tu peux faire des déploiements simples :

• copier une config.
• .env
• redémarrer le service.
• faire une validation basique : port ouvert, endpoint health.

Gestion de la configuration :

• templates + variables.
• secrets chiffrés (Ansible Vault) ou récupérés depuis un secret manager.
• debug

Quand s’arrêter, parce que c’est important :

• si tu fais du déploiement applicatif complexe, des rollbacks applicatifs, du canary, du blue green, tu vas probablement vouloir un outil dédié (ou une plateforme). Ansible n’a pas besoin de tout porter.

Trace et contrôle :

• exécutions en CI.
• logs archivés.
• --check--diff

Ansible est très bon pour standardiser. Il est moins bon comme plateforme de déploiement universelle. Et c’est ok.

Le workflow « Terraform + Ansible » étape par étape (exemple de bout en bout)

Voici un déroulé simple, celui que tu peux vraiment adopter dès maintenant.

Étape 1 : Terraform

1. terraform init
2. terraform plan
3. terraform apply

Étape 2 : récupérer les outputs Terraform Tu exposes dans Terraform des outputs : IP, DNS, IDs, etc. Puis tu alimentes Ansible avec ces outputs.

Deux façons simples :

• générer un fichier d’inventaire à partir des outputs.
• utiliser un inventaire dynamique, et ne garder que les tags.

Étape 3 : exécuter Ansible

• durcissement OS.
• configuration SSH.
• installation des dépendances.
• configuration des services.

Étape 4 : validation

• test SSH.
• health checks sur le LB.
• vérif des ports.
• vérif des règles : pas d’accès direct à la db, etc.

Étape 5 : itérations propres Tu modifies le code. Tu ouvres une PR. Tu relis le plan. Tu applies. Tu rejoues Ansible.

Tu veux une boucle courte, reproductible, et pas une soirée « je clique jusqu’à ce que ça marche ».

Exemple de structure de projet (simple, mais maintenable)

Une structure classique qui tient bien dans le temps :

text / terraform/ modules/ network/ compute/ security_baseline/ envs/ dev/ main.tf backend.tf dev.tfvars staging/ main.tf backend.tf staging.tfvars prod/ main.tf backend.tf prod.tfvars

ansible/ playbooks/ site.yml roles/ common/ hardening/ nginx/ inventories/ dev/ hosts.ini group_vars/ staging/ hosts.ini group_vars/ prod/ hosts.ini group_vars/

Variables par environnement :

• *.tfvars
• group_varshost_vars

Convention de nommage et tagging :

• noms prévisibles, pas de « test2 final final ».
• tags pour l’audit et la facturation.

Documentation minimum :

• un README « comment lancer ».
• prérequis : versions, accès, variables.
• planapplyansible-playbook

Stratégie de branches :

• PR obligatoires.
• revues.
• politique de merge claire.

Ce n’est pas du luxe. C’est ce qui évite que l’IaC devienne un dépôt incompréhensible dans 6 mois.

Bonnes pratiques sécurité et gouvernance (pour éviter les mauvaises surprises)

C’est souvent le moment où on se dit « on sécurisera après ». Mauvaise idée. L’IaC rend les erreurs plus rapides aussi. Donc autant mettre les garde fous.

Secrets :

• stockage sécurisé et injection au runtime.
• rotation.
• moindre privilège.
• séparation dev et prod.

Contrôles avant déploiement :

• terraform fmtterraform validate
• ansible-lint
• scanning IaC si tu peux (policies, règles de sécurité).

Politiques :

• pas d’apply en local sur prod si vous êtes plusieurs.
• approbations obligatoires.
• journaux : plans, applies, runs Ansible archivés.

Réseau et accès :

• bastion ou accès via SSM équivalent.
• limitation stricte des ports entrants.
• segmentation : public, app, db.

Traçabilité :

• journaliser les changements, pas seulement les résultats.
• lier PR, plan, apply, run Ansible. Tu veux pouvoir raconter l’histoire.

Erreurs fréquentes (et comment les éviter dès le début)

Quelques erreurs que je vois tout le temps. Et qui coûtent cher, en temps et en confiance.

Tout mettre dans Terraform, y compris la config OS. Résultat : scripts énormes, difficiles à relire, changements non idempotents, debugging pénible. Solution : bootstrap minimal, le reste dans Ansible.

Ignorer le state distant et le verrouillage. Résultat : collisions, incohérences, applies qui marchent « parfois ». Solution : backend distant + lock dès le début, même en dev.

Variables et secrets en clair. Résultat : fuite d’identifiants, rotation en panique. Solution : secret manager, Ansible Vault, et discipline Git.

Pas de modularisation. Résultat : duplication, divergence entre environnements, maintenance impossible. Solution : modules Terraform, rôles Ansible.

ansible --check

Conclusion : la combinaison la plus pragmatique pour automatiser réseau + système

Terraform construit l’infrastructure. Ansible la rend opérationnelle. Et la combinaison est franchement difficile à battre quand ton objectif est d’automatiser réseau plus système, sans te perdre dans une plateforme trop lourde.

Le conseil d’adoption le plus réaliste : commence petit. Un réseau. Une VM. Un playbook Ansible « common + hardening ». Puis tu factorises en modules et en rôles au fur et à mesure, quand la répétition apparaît.

Et surtout, garde les fondamentaux :

• Git et PR.
• state distant.
• secrets bien gérés.
• revue du plan.
• idempotence Ansible.

terraform planapply

Questions fréquemment posées

Qu'est-ce que l'infrastructure as code (IaC) et comment change-t-elle la gestion de l'infrastructure ?

L'IaC est une méthode qui consiste à décrire l'environnement d'infrastructure en code, permettant de versionner, rejouer et revoir l'infrastructure comme un logiciel. Elle couvre le provisionnement, la configuration, le réseau et la sécurité, offrant ainsi vitesse, cohérence, auditabilité, rollback et réduction des erreurs humaines dans la gestion de l'infrastructure.

Quels sont les principaux problèmes liés au provisionnement manuel de l'infrastructure ?

Le provisionnement manuel souffre d'un manque de mémoire fiable, causant la dérive de configuration entre serveurs, des difficultés à reconstruire des environnements identiques et une faible traçabilité des changements. Cela peut entraîner des erreurs humaines, des failles de sécurité comme des règles firewall non revues ou des accès trop larges laissés en place.

Quels bénéfices tangibles apporte l'utilisation de l'IaC par rapport aux méthodes manuelles ?

L'IaC permet de recréer un environnement en minutes plutôt qu'en jours, garantit la cohérence des paramètres et dépendances, offre une auditabilité complète via Git (qui a changé quoi et quand), permet un rollback facile vers une version connue et réduit significativement les erreurs humaines.

Pourquoi combiner Terraform et Ansible dans une approche IaC pragmatique ?

Terraform est un outil déclaratif idéal pour le provisionnement d'infrastructures (VPC, subnets, VM), tandis qu'Ansible excelle dans la configuration des systèmes d'exploitation et services (packages, utilisateurs, durcissement). Leur combinaison permet une gestion claire avec deux rôles distincts pour une infrastructure reproductible et simplifiée.

Comment l'IaC améliore-t-elle la sécurité dans la gestion de l'infrastructure ?

L'IaC impose une discipline rigoureuse avec du code versionné, des revues de changements via pull requests et un pipeline CI/CD. Cela évite les modifications non contrôlées comme les règles firewall modifiées sans revue ou les identifiants exposés. Chaque changement est tracé et justifié, renforçant ainsi la sécurité globale.

Qu'est-ce que le 'configuration drift' et comment l'IaC y remédie ?

Le 'configuration drift' désigne la divergence progressive entre plusieurs serveurs initialement identiques suite à des modifications manuelles non synchronisées. L'IaC élimine ce problème en décrivant toute l'infrastructure en code versionné garantissant que chaque environnement est construit selon les mêmes paramètres exacts sans dérive.