Qu’est-ce que l’Infrastructure as Code ? Guide visuel pour débutants

J’ai passé un vendredi après-midi entier à cliquer dans la console AWS pour monter un environnement de production. VPC, sous-réseaux, groupes de sécurité, une instance RDS, un load balancer, deux EC2. Quatre heures de travail. Je me sentais plutôt fier. Documenté : rien.

Trois semaines plus tard, le client demande un environnement de staging identique. J’ouvre la console et je réalise que j’ai oublié la moitié des paramètres. Les plages CIDR des sous-réseaux ? Envolées. Les règles de sécurité ? Vaguement. Le parameter group RDS ? Aucune chance.

J’ai donc passé quatre nouvelles heures à tout reconstruire en devinant la moitié de la config. L’environnement de staging était “à peu près” comme la production. Vous imaginez la suite.

Avant et après : manuel vs code

Voici à quoi ressemble la gestion d’infrastructure sans IaC :

1. Ouvrir la console cloud
2. Naviguer à travers quinze écrans
3. Choisir les paramètres de mémoire (ou depuis une page wiki à moitié obsolète)
4. Espérer n’avoir oublié aucune règle de sécurité
5. Recommencer pour chaque environnement, à chaque fois
6. Prier pour que personne ne modifie quelque chose manuellement sans prévenir

Et voici la même chose avec l’Infrastructure as Code :

1. Écrire un fichier de configuration décrivant ce qu’on veut
2. Lancer une commande
3. L’environnement complet apparaît, identique à chaque fois
4. Stocker le fichier dans Git comme n’importe quel code
5. Revoir les changements en pull request avant qu’ils touchent la production
6. Dormir tranquille

C’est tout. On décrit son infrastructure dans des fichiers texte, et un outil la construit. Même entrée, même sortie, à chaque fois.

Ce qu’est réellement l’Infrastructure as Code

L’Infrastructure as Code consiste à gérer serveurs, réseaux, bases de données et ressources cloud via des fichiers de configuration lisibles par une machine, plutôt que par des processus manuels. Au lieu de cliquer sur des boutons dans une console web, on écrit du code qui décrit l’état souhaité de l’infrastructure.

Le mot clé ici, c’est état. On n’écrit pas “crée un serveur”. On écrit “il doit y avoir un serveur avec ces propriétés”. L’outil se charge des étapes. Si le serveur existe déjà et correspond, il ne fait rien. Si quelque chose a dérivé, il corrige.

C’est ce qu’on appelle la configuration déclarative — on décrit le quoi, pas le comment. C’est la différence entre dire au GPS “emmène-moi à l’aéroport” et donner les indications virage par virage de mémoire.

Il existe aussi une approche impérative, où l’on écrit des instructions étape par étape. Ansible penche de ce côté. Les deux fonctionnent. Le déclaratif tend à être plus facile à appréhender à grande échelle.

Pourquoi tout ça importe ? Trois raisons :

Reproductibilité. Même code, même infrastructure. Dev, staging, production — tous identiques. Plus de “ça marche sur ma machine”, mais pour les serveurs.

Versionnement. L’infrastructure vit dans Git. On voit qui a changé quoi, quand, et pourquoi. On peut revenir en arrière. On peut revoir les modifications avant qu’elles passent en production.

Rapidité. Monter un nouvel environnement passe de “une journée de clics” à “lance cette commande”. Le démonter est tout aussi rapide. Ça change complètement la façon de penser l’infrastructure.

Les grands outils (et à quoi ils servent)

Quatre noms dominent cet espace. Ils ne font pas tous la même chose, même s’ils sont constamment mis dans le même panier.

Terraform

L’outil IaC généraliste le plus populaire. Créé par HashiCorp. Fonctionne avec AWS, Azure, GCP et des centaines d’autres fournisseurs. On écrit des fichiers .tf dans un langage appelé HCL (HashiCorp Configuration Language), et Terraform détermine comment créer, mettre à jour ou supprimer les ressources.

Terraform est déclaratif et cloud-agnostique. Ce deuxième point est important — on peut gérer AWS, Cloudflare et Datadog depuis la même base de code.

Idéal pour : provisionner l’infrastructure cloud. Serveurs, réseaux, bases de données, DNS, CDN. La partie structurelle.

Ansible

Créé par Red Hat. Ansible est principalement un outil de gestion de configuration et d’automatisation. Il se connecte aux serveurs via SSH et exécute des tâches dans l’ordre. Aucun agent nécessaire sur les machines cibles.

Ansible utilise des playbooks YAML et penche vers l’impératif — on définit des étapes, pas juste des états finaux. Il excelle pour installer des logiciels, configurer des services, déployer des applications.

Idéal pour : configurer les serveurs après leur création. Installer des paquets, paramétrer des services, lancer des déploiements.

AWS CloudFormation

L’outil IaC natif d’AWS. Des templates JSON ou YAML décrivant des ressources AWS. Intégration profonde avec chaque service AWS, supportant souvent les nouvelles fonctionnalités dès le premier jour.

Le hic : ça ne fonctionne qu’avec AWS. Si on est entièrement sur AWS et qu’on compte y rester, CloudFormation est solide. Si on envisage le multi-cloud, on se heurte à un mur.

Idéal pour : les équipes 100% AWS qui veulent une intégration native avec l’écosystème.

Pulumi

Le challenger récent. Au lieu d’un langage dédié, on écrit l’IaC dans de vrais langages de programmation — TypeScript, Python, Go, C#. Le même modèle déclaratif que Terraform sous le capot, mais avec toute la puissance d’un langage de programmation.

Idéal pour : les équipes qui veulent des boucles, des conditions et des abstractions sans apprendre HCL. Également très bien si l’équipe vit déjà en TypeScript ou Python.

Quand utiliser quoi

Voici un modèle mental qui m’a bien servi :

• Besoin de créer des ressources cloud (serveurs, bases de données, réseaux) ? Terraform ou CloudFormation.
• Besoin de configurer ce qu’il y a sur ces serveurs (installer des logiciels, modifier des fichiers de config) ? Ansible.
• AWS uniquement avec intégration native ? CloudFormation.
• Envie d’utiliser un vrai langage de programmation ? Pulumi.
• Débuter et viser le plus grand marché de l’emploi ? Terraform. Sans hésitation.

Beaucoup d’équipes utilisent Terraform et Ansible ensemble — Terraform crée l’infrastructure, Ansible la configure. Ils sont complémentaires, pas concurrents.

Si vous êtes encore en train de construire vos bases cloud, notre guide pour apprendre le cloud computing en partant de zéro couvre les concepts fondamentaux à maîtriser avant de plonger dans les outils IaC.

Votre premier fichier Terraform

Voici une configuration Terraform complète qui crée un bucket S3 sur AWS. C’est à peu près le plus simple que l’IaC puisse être :

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

resource "aws_s3_bucket" "mon_premier_bucket" {
  bucket = "mon-premier-bucket-iac-12345"

  tags = {
    Environment = "learning"
    ManagedBy   = "terraform"
  }
}

Ce qui se passe ici :

• Le bloc terraform dit “j’ai besoin du provider AWS.”
• Le bloc provider dit “connecte-toi à AWS dans us-east-1.”
• Le bloc resource dit “il doit y avoir un bucket S3 avec ce nom et ces tags.”

Pour l’exécuter :

terraform init      # Télécharger le provider AWS
terraform plan      # Prévisualiser ce qui sera créé
terraform apply     # Créer réellement les ressources

terraform plan est le filet de sécurité. Il montre exactement ce qui va se passer avant que quoi que ce soit ne change. Prenez l’habitude de lire la sortie du plan. À chaque fois. Sans exception.

Une fois l’expérimentation terminée :

terraform destroy   # Supprimer tout ce que Terraform a créé

Voilà du vrai IaC. Quinze lignes, une commande, et vous avez une infrastructure versionnée, reproductible et supprimable. Essayez de faire ça en cliquant dans la console.

Erreurs fréquentes des débutants

Je les ai toutes faites. Certaines plus d’une fois.

Ne pas utiliser un state distant. Terraform stocke son état dans un fichier local par défaut. C’est bien pour apprendre. En équipe, c’est un désastre — deux personnes qui lancent Terraform en même temps vont corrompre le state. Utilisez un backend S3 (ou équivalent) dès le début de tout vrai projet.

Tout coder en dur. Le premier réflexe sera de mettre les valeurs directement dans les blocs resource. Noms de région, tailles d’instance, noms de bucket. Utilisez des variables à la place. Le vous du futur sera reconnaissant quand il faudra la même config pour trois environnements.

Sauter terraform plan. Lancer apply sans lire le plan, c’est comme pousser sur main sans lire le diff. Ça marche bien jusqu’au jour où ça ne marche plus, et ce jour-là, c’est généralement quelque chose qui se fait détruire.

Vouloir tout apprendre d’un coup. L’IaC a une surface d’apprentissage importante. N’essayez pas d’apprendre Terraform, Ansible, Docker, Kubernetes et le CI/CD en même temps. Choisissez un outil, construisez quelque chose de concret avec, puis élargissez. Quinze minutes par jour battent un marathon du week-end — on a écrit un article sur le sujet.

Modifier l’infrastructure manuellement après l’avoir déployée avec du code. C’est ce qu’on appelle le “drift”, et c’est l’équivalent IaC de modifier directement une base de données de production. L’outil pense que l’infrastructure est dans un état ; la réalité dit le contraire. Tout casse au prochain apply. Si c’est géré par du code, ne le modifiez que par le code.

FAQ

Faut-il savoir programmer pour apprendre l’Infrastructure as Code ?

Pas vraiment. Le HCL de Terraform est plus proche d’un format de configuration que d’un langage de programmation. Si vous savez écrire du JSON ou du YAML, vous pouvez écrire du HCL. Ansible utilise du YAML, qui est encore plus simple. Pas besoin de connaître Python ou JavaScript pour commencer. Cela dit, comprendre les concepts de base comme les variables, les boucles et les conditions aide une fois que les configurations grandissent.

Terraform est-il gratuit ?

Le CLI Terraform est open-source et gratuit. On peut l’utiliser pour tout ce qui est décrit dans cet article sans payer quoi que ce soit. HashiCorp propose Terraform Cloud avec des fonctionnalités d’équipe (state distant, collaboration, politiques), qui a un palier gratuit et des plans payants. La plupart des individus et petites équipes s’en sortent très bien avec le CLI et un backend S3 pour le state.

Faut-il apprendre Terraform ou Ansible en premier ?

Terraform, si vous vous lancez dans l’infrastructure cloud. Il résout le problème le plus fondamental — créer les ressources. Ansible est plus utile une fois qu’on a des serveurs à configurer. Si votre travail consiste surtout à “monter des environnements AWS”, Terraform est la réponse. Si c’est plutôt “déployer et configurer des applications sur des serveurs existants”, commencez par Ansible.

Combien de temps faut-il pour devenir productif avec l’IaC ?

On peut créer de vraies ressources cloud avec Terraform en un après-midi. Être à l’aise prend deux à quatre semaines de pratique régulière. Se sentir confiant avec les modules, la gestion du state et les configurations multi-environnements prend quelques mois. La courbe d’apprentissage est chargée au début — la première semaine est la plus dure. Après, c’est surtout apprendre de nouveaux types de ressources, qui suivent les mêmes patterns que ceux déjà connus.

Prêt à construire de vraies compétences cloud en partant de zéro ? Commencez avec SkillRealm Learn —>