Aller au contenu principal

Providers, ressources, modules : la trinité Terraform

Résumé : trois mots reviennent en permanence dans tout code Terraform, et il faut les distinguer clairement. Le provider est le pont entre Terraform et une plateforme (AWS, GCP, Azure, GitHub, Datadog, etc.). La ressource est une brique d'infrastructure concrète créée par Terraform (VM, base de données, DNS). Le module est un ensemble de ressources empaqueté et réutilisable. Cette leçon décortique la trinité, ajoute un quatrième concept clé — la data source — et montre où les trouver dans le Terraform Registry.

1. Vue d'ensemble de l'architecture Terraform​

En une phrase : votre code déclare un provider, qui vous donne accès à des ressources, que vous pouvez organiser en modules partageables via le Registry.

2. Les providers — les ponts vers chaque plateforme​

Un provider est un plugin téléchargé par Terraform qui sait parler à l'API d'une plateforme donnée.

2.1 · Ce qu'apporte un provider​

2.2 · Combien de providers existent ?​

Plus de 3500 providers sont disponibles dans le Terraform Registry en 2026. Ils couvrent :

Ce qui rend Terraform si puissant : vous pouvez provisionner votre serveur AWS, votre DNS Cloudflare, votre repo GitHub et votre alerte Datadog dans un seul fichier HCL. C'est cette unification multi-plateformes qui a bâti la domination de Terraform.

2.3 · Les types de providers​

Bonne pratique : privilégiez toujours les providers officiels ou partenaires. Les providers communautaires peuvent être excellents, mais leur maintenance peut s'arrêter du jour au lendemain.

3. Les ressources — les briques concrètes​

Une ressource Terraform représente une entité créable dans une plateforme : une machine virtuelle, un bucket S3, un enregistrement DNS, un utilisateur IAM, un repo GitHub, une alerte Datadog.

3.1 · Anatomie d'une ressource​

Rappel de la syntaxe :

resource "TYPE_DE_RESSOURCE" "NOM_LOGIQUE" {
  attribut_1 = valeur
  attribut_2 = valeur
}

Exemples concrets :

Bloc de ressourceCe qu'il crée
resource "aws_instance" "web"Une VM EC2 sur AWS
resource "google_compute_instance" "web"Une VM Compute Engine sur GCP
resource "azurerm_virtual_machine" "web"Une VM sur Azure
resource "kubernetes_deployment" "app"Un Deployment Kubernetes
resource "github_repository" "docs"Un repo GitHub
resource "cloudflare_record" "www"Un enregistrement DNS Cloudflare
resource "datadog_monitor" "cpu"Une alerte Datadog

3.2 · Ressources composées et dépendances​

Les ressources se composent en cascade pour bâtir des architectures complètes.

Chose remarquable : Terraform détecte automatiquement ces dépendances à partir des références (aws_vpc.main.id). Vous n'avez jamais à préciser l'ordre, il l'infère.

3.3 · Les meta-arguments — pilotage fin du comportement​

Certains attributs sont spéciaux — ils ne représentent pas une propriété de la ressource cloud, mais une instruction pour Terraform lui-même.

Ces meta-arguments sont la salle des machines de Terraform — ils permettent de moduler très finement le comportement.

4. Les data sources — lire sans créer​

Il y a un cousin des ressources qu'il faut connaître : les data sources.

Différence fondamentale :

  • Une resource — crée une nouvelle entité.
  • Une data — lit une entité existante.

Exemple : vous voulez utiliser l'AMI Ubuntu la plus récente dans votre région, sans écrire son identifiant en dur (qui change à chaque mise à jour).

data "aws_ami" "ubuntu_latest" {
  most_recent = true
  owners      = ["099720109477"]  # Canonical

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-*"]
  }
}

resource "aws_instance" "web" {
  # On utilise l'ID trouvé par la data source
  ami           = data.aws_ami.ubuntu_latest.id
  instance_type = "t3.micro"
}

Ce que ça permet :

Data sources = lecture seule. Aucun changement n'est apporté à l'infrastructure. C'est votre outil pour connecter Terraform à ce qui existe déjà.

5. Les modules — l'unité de réutilisation​

Un module Terraform est un ensemble structuré de fichiers .tf empaquetés pour être réutilisés.

5.1 · Anatomie d'un module​

Un module peut être local (dans un sous-dossier de votre projet) ou distant (téléchargé depuis le Terraform Registry, GitHub, GitLab, S3…).

5.2 · Utiliser un module distant — l'exemple magique​

En 5 lignes de HCL, vous pouvez créer un VPC AWS complet grâce à un module communautaire réputé :

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.0.0"

  name = "mon-vpc-production"
  cidr = "10.0.0.0/16"

  azs             = ["eu-west-1a", "eu-west-1b", "eu-west-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway = true
  single_nat_gateway = false
}

Ce que ça crée réellement : un VPC, 6 subnets, 3 NAT Gateways, une table de routage, une IGW, plusieurs security groups par défaut… environ 25 ressources AWS. Et vous n'avez écrit que 10 lignes.

C'est là toute la magie des modules : la communauté a construit et testé les patterns d'infrastructure standards, et vous les consommez comme des briques Lego.

5.3 · Le Terraform Registry — le catalogue mondial​

Le Terraform Registry est la place de marché où tout le monde publie ses modules et providers.

Les modules stars à connaître :

ModuleCe qu'il fait
terraform-aws-modules/vpc/awsVPC AWS complet avec subnets, NAT, routing
terraform-aws-modules/eks/awsCluster Kubernetes EKS clé en main
terraform-aws-modules/rds/awsBase de données RDS avec réplication
hashicorp/consul/awsConsul cluster en HA
cloudposse/vpc/awsVPC AWS variante Cloud Posse

Toujours vérifier :

  • Le nombre de téléchargements (indicateur d'adoption).
  • La date de dernière mise à jour (moins de 6 mois idéalement).
  • La licence (MPL, Apache 2, MIT sont fiables).
  • Le repo GitHub — issues actives, contributeurs multiples.

6. Cycle complet — mettre tout ensemble​

Voici comment ces quatre briques (provider, resource, data, module) s'articulent dans un projet réel.

Un projet Terraform mature utilise ces quatre briques ensemble, et 80 % de son code consiste à assembler des modules existants plutôt qu'à écrire des ressources brutes.

7. Les erreurs classiques du débutant​

Un débutant fait typiquement les erreurs suivantes.

Le Cours Premium Terraform insiste beaucoup sur les bonnes pratiques de structure et évite ces pièges.

Retenir en 30 secondes​

  • Provider = plugin qui parle à une API (AWS, GCP, GitHub, Datadog). Plus de 3500 disponibles.
  • Ressource = entité créable par Terraform (VM, base de données, DNS). Le cœur de tout code Terraform.
  • Data source = lecture seule d'une entité existante — sert à interroger sans modifier.
  • Module = paquet réutilisable de ressources, avec variables et sorties. Le secret de la scalabilité.
  • Terraform Registry = catalogue mondial avec 15 000+ modules publics.
  • Bonne pratique : ne jamais réinventer un module qui existe déjà dans le Registry.

Suivant : Le state file : le fichier qui rend Terraform intelligent →