Terraform Cloud : Collaborer en Équipe sur votre Infrastructure as Code

Introduction

Vous utilisez Terraform en local depuis quelques mois, et tout fonctionne parfaitement… tant que vous êtes seul. Mais dès qu'une équipe de plusieurs développeurs ou ingénieurs DevOps doit intervenir sur la même infrastructure, les problèmes surgissent : conflits sur le state file, absence de traçabilité, exécutions concurrentes qui corrompent l'état, secrets partagés de manière non sécurisée. Terraform Cloud est la réponse officielle de HashiCorp à ces défis.

Dans cet article, nous allons explorer en profondeur Terraform Cloud : ce qu'il apporte par rapport à Terraform OSS, comment le configurer pas à pas, et comment en tirer parti pour une collaboration fluide et sécurisée au sein de votre équipe. Que vous soyez une startup de 3 personnes ou une entreprise de 300 ingénieurs, ce guide vous donnera toutes les clés pour adopter Terraform Cloud avec succès.

Diagramme - Terraform Cloud : Collaborer en Équipe sur votre Infrastructure as Code

Terraform OSS vs Terraform Cloud vs Terraform Enterprise

Avant de plonger dans Terraform Cloud, il est essentiel de comprendre les trois offres de l'écosystème Terraform et leurs différences fondamentales.

Terraform OSS (Open Source)

C'est l'outil en ligne de commande que vous connaissez probablement déjà. Gratuit, open source, il s'exécute sur votre machine locale ou dans vos pipelines CI/CD. Le state est stocké localement par défaut, ou dans un backend distant (S3, GCS, Azure Blob…). Il n'y a aucune fonctionnalité native de collaboration multi-utilisateurs.

Terraform Cloud

C'est une plateforme SaaS gérée par HashiCorp qui ajoute une couche de collaboration, de gouvernance et d'automatisation au-dessus de Terraform. Elle est gratuite pour les petites équipes (jusqu'à 5 utilisateurs) et propose des plans payants pour les fonctionnalités avancées. Le state est géré de manière centralisée, les exécutions se font à distance, et les politiques de sécurité peuvent être appliquées automatiquement.

Terraform Enterprise

C'est la version auto-hébergée de Terraform Cloud, destinée aux grandes entreprises ayant des contraintes de conformité ou de réseau strictes. Elle offre les mêmes fonctionnalités que Terraform Cloud, avec en plus le contrôle total de l'infrastructure d'hébergement, le support SSO/SAML avancé, et des fonctionnalités d'audit renforcées.

Créer un Compte et une Organisation

La mise en route de Terraform Cloud est rapide et ne nécessite aucune infrastructure préalable.

Étape 1 : Inscription

Rendez-vous sur app.terraform.io et créez un compte avec votre adresse e-mail professionnelle ou votre compte GitHub/GitLab. L'inscription est gratuite et ne nécessite pas de carte bancaire.

Étape 2 : Créer une Organisation

Une organisation est le conteneur principal qui regroupe vos workspaces, vos équipes et vos politiques. Choisissez un nom représentatif de votre entreprise ou de votre projet.

# Vous pouvez aussi interagir via l'API
curl \
  --header "Authorization: Bearer $TF_CLOUD_TOKEN" \
  --header "Content-Type: application/vnd.api+json" \
  --request POST \
  --data '{
    "data": {
      "type": "organizations",
      "attributes": {
        "name": "codeclan-fr",
        "email": "admin@codeclan.fr"
      }
    }
  }' \
  https://app.terraform.io/api/v2/organizations

Étape 3 : Configurer le CLI

Pour connecter votre Terraform CLI local à Terraform Cloud, exécutez la commande suivante :

# Se connecter à Terraform Cloud depuis le CLI
terraform login

# Le navigateur s'ouvre pour générer un token API
# Collez le token dans le terminal quand demandé

Cette commande génère un fichier ~/.terraform.d/credentials.tfrc.json contenant votre token d'authentification.

Les Workspaces dans Terraform Cloud

Les workspaces sont le concept central de Terraform Cloud. Contrairement aux workspaces locaux de Terraform OSS (qui ne sont que des state files séparés), les workspaces de Terraform Cloud sont des environnements complets avec leur propre configuration, variables, permissions et historique.

Créer un Workspace

Il existe trois types de workspaces dans Terraform Cloud :

VCS-driven : Connecté à un dépôt Git, les plans se déclenchent automatiquement à chaque push ou pull request.
CLI-driven : Vous lancez les commandes depuis votre terminal, mais l'exécution se fait à distance sur Terraform Cloud.
API-driven : Piloté entièrement par des appels API, idéal pour l'intégration avec des outils tiers.

Configuration d'un Workspace CLI-driven

Pour utiliser un workspace CLI-driven, ajoutez le bloc cloud à votre configuration Terraform :

terraform {
  cloud {
    organization = "codeclan-fr"

    workspaces {
      name = "production-aws"
    }
  }

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

provider "aws" {
  region = "eu-west-3"
}

Ensuite, initialisez votre configuration :

terraform init
# Terraform se connecte à Terraform Cloud
# Le state sera stocké dans le workspace distant

terraform plan
# Le plan s'exécute sur les runners de Terraform Cloud
# mais le résultat s'affiche dans votre terminal

terraform apply
# L'apply s'exécute aussi à distance

Variables et Variables d'Environnement

Terraform Cloud permet de définir des variables à deux niveaux :

Variables Terraform : Les variables que vous passeriez normalement avec -var ou dans un fichier .tfvars.
Variables d'environnement : Les variables d'environnement disponibles pendant l'exécution, comme AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY.

Les variables peuvent être marquées comme sensibles, ce qui les chiffre et les masque dans l'interface et les logs.

# Définir des variables via l'API
curl \
  --header "Authorization: Bearer $TF_CLOUD_TOKEN" \
  --header "Content-Type: application/vnd.api+json" \
  --request POST \
  --data '{
    "data": {
      "type": "vars",
      "attributes": {
        "key": "AWS_ACCESS_KEY_ID",
        "value": "AKIA...",
        "category": "env",
        "sensitive": true
      }
    }
  }' \
  https://app.terraform.io/api/v2/workspaces/$WORKSPACE_ID/vars

Intégration VCS : GitHub, GitLab et autres

L'intégration VCS est l'une des fonctionnalités les plus puissantes de Terraform Cloud. Elle permet de lier un workspace à un dépôt Git pour automatiser entièrement le workflow plan/apply.

Configurer l'intégration GitHub

Dans votre organisation Terraform Cloud, allez dans Settings > VCS Providers.
Cliquez sur Add a VCS Provider et sélectionnez GitHub.
Suivez les instructions pour installer l'application GitHub de Terraform Cloud sur votre organisation GitHub.
Autorisez l'accès aux dépôts souhaités.

Workflow VCS-driven

Une fois l'intégration configurée, voici comment fonctionne le workflow :

Push sur une branche : Un terraform plan est automatiquement déclenché.
Pull Request : Le résultat du plan apparaît comme un commentaire ou un check dans la PR.
Merge sur main : Un terraform apply est déclenché (selon la configuration).

Ce workflow garantit que chaque changement d'infrastructure est revu par l'équipe avant d'être appliqué, exactement comme pour le code applicatif.

Configuration avancée du workspace VCS

# Structure de dépôt recommandée
# terraform-infrastructure/
# ├── environments/
# │   ├── production/
# │   │   ├── main.tf
# │   │   ├── variables.tf
# │   │   └── terraform.tf
# │   ├── staging/
# │   │   ├── main.tf
# │   │   ├── variables.tf
# │   │   └── terraform.tf
# │   └── development/
# │       ├── main.tf
# │       ├── variables.tf
# │       └── terraform.tf
# └── modules/
#     ├── networking/
#     ├── compute/
#     └── database/

Chaque répertoire d'environnement peut correspondre à un workspace Terraform Cloud différent, avec le Working Directory configuré en conséquence. Ainsi, un changement dans environments/production/ ne déclenche un plan que dans le workspace de production.

Remote Execution : Exécution à Distance

L'exécution à distance est un changement fondamental dans la façon de travailler avec Terraform. Au lieu d'exécuter les commandes sur votre machine locale, elles s'exécutent sur les serveurs de Terraform Cloud.

Avantages de l'exécution à distance

Cohérence : Tout le monde utilise le même environnement d'exécution, éliminant les problèmes de "ça marche sur ma machine".
Sécurité : Les credentials ne quittent jamais Terraform Cloud. Les développeurs n'ont pas besoin d'avoir les clés AWS sur leur poste.
Traçabilité : Chaque exécution est enregistrée avec son auteur, ses logs et son résultat.
Verrouillage : Impossible d'avoir deux apply concurrents sur le même workspace.

Mode Execution

Vous pouvez configurer le mode d'exécution par workspace :

Remote : Plan et apply s'exécutent sur Terraform Cloud (recommandé).
Local : L'exécution se fait localement, seul le state est stocké dans Terraform Cloud.
Agent : L'exécution se fait sur un agent auto-hébergé dans votre réseau (utile pour accéder à des ressources privées).

Sentinel : Politiques de Gouvernance

Sentinel est le framework de policy-as-code de HashiCorp. Il permet de définir des règles que chaque plan Terraform doit respecter avant d'être appliqué. C'est un outil extrêmement puissant pour la gouvernance d'infrastructure.

Exemples de Politiques Sentinel

# Politique : Interdire les instances EC2 trop grandes en production
import "tfplan/v2" as tfplan

allowed_instance_types = [
  "t3.micro",
  "t3.small",
  "t3.medium",
  "t3.large",
]

ec2_instances = filter tfplan.resource_changes as _, rc {
  rc.type is "aws_instance" and
  (rc.change.actions contains "create" or rc.change.actions contains "update")
}

main = rule {
  all ec2_instances as _, instance {
    instance.change.after.instance_type in allowed_instance_types
  }
}

# Politique : Exiger des tags obligatoires sur toutes les ressources
import "tfplan/v2" as tfplan

required_tags = ["Environment", "Project", "Owner", "CostCenter"]

taggable_resources = filter tfplan.resource_changes as _, rc {
  rc.change.after.tags is not null and
  (rc.change.actions contains "create" or rc.change.actions contains "update")
}

main = rule {
  all taggable_resources as _, resource {
    all required_tags as tag {
      resource.change.after.tags contains tag
    }
  }
}

Niveaux d'application

Sentinel propose trois niveaux d'application :

Advisory : La violation est signalée mais n'empêche pas l'apply.
Soft mandatory : La violation empêche l'apply, mais un administrateur peut passer outre.
Hard mandatory : La violation empêche absolument l'apply, sans exception.

Estimation des Coûts

Terraform Cloud peut estimer le coût mensuel des ressources que vous êtes sur le point de créer ou modifier. Cette fonctionnalité est disponible pour les principaux fournisseurs cloud (AWS, Azure, GCP).

L'estimation de coûts apparaît directement dans le résultat du plan, avant l'apply. Elle montre le coût actuel estimé, le coût après les changements, et la différence. Combinée avec des politiques Sentinel, vous pouvez par exemple empêcher tout changement qui augmenterait le coût mensuel de plus de 500 euros sans approbation managériale.

# Politique Sentinel pour contrôler les coûts
import "tfrun"

delta_monthly_cost = tfrun.cost_estimate.delta_monthly_cost

main = rule {
  delta_monthly_cost < 500
}

Private Module Registry

Le registre privé de modules est une fonctionnalité clé pour les équipes qui souhaitent standardiser leurs pratiques. Il fonctionne comme le registre public de Terraform, mais pour vos modules internes.

Publier un Module Privé

Pour publier un module dans le registre privé, votre dépôt Git doit suivre la convention de nommage terraform-<PROVIDER>-<NAME>. Par exemple : terraform-aws-vpc-codeclan.

# Structure du module
# terraform-aws-vpc-codeclan/
# ├── main.tf
# ├── variables.tf
# ├── outputs.tf
# ├── README.md
# └── examples/
#     └── complete/
#         ├── main.tf
#         └── outputs.tf

# Utilisation du module depuis le registre privé
module "vpc" {
  source  = "app.terraform.io/codeclan-fr/vpc-codeclan/aws"
  version = "~> 2.0"

  vpc_cidr           = "10.0.0.0/16"
  availability_zones = ["eu-west-3a", "eu-west-3b", "eu-west-3c"]
  environment        = "production"
  project            = "api-platform"
}

module "database" {
  source  = "app.terraform.io/codeclan-fr/rds-postgresql/aws"
  version = "~> 1.5"

  vpc_id            = module.vpc.vpc_id
  subnet_ids        = module.vpc.private_subnet_ids
  instance_class    = "db.r6g.large"
  engine_version    = "15.4"
  database_name     = "api_production"
  environment       = "production"
}

Versionnage Sémantique

Chaque release Git (tag) correspond à une version du module. Utilisez le versionnage sémantique (SemVer) pour communiquer clairement les changements :

Patch (1.0.x) : Corrections de bugs, pas de changement de comportement.
Minor (1.x.0) : Nouvelles fonctionnalités rétrocompatibles.
Major (x.0.0) : Changements non rétrocompatibles, migration nécessaire.

Teams et Permissions

Terraform Cloud offre un système de gestion d'équipes et de permissions granulaire qui permet de contrôler précisément qui peut faire quoi.

Niveaux de Permissions

Read : Voir les workspaces, les plans et les states.
Plan : Déclencher des plans (mais pas des applies).
Write : Déclencher des plans et des applies.
Admin : Gérer les paramètres du workspace, les variables, les permissions.

Organisation des Équipes

# Exemple de configuration d'équipe via l'API ou l'interface
# Organisation: codeclan-fr
#
# Équipe "platform-admins"
#   - Accès Admin à tous les workspaces
#   - Peut gérer les politiques Sentinel
#   - Peut gérer le registre de modules
#
# Équipe "backend-devs"
#   - Accès Write aux workspaces de développement et staging
#   - Accès Plan aux workspaces de production
#   - Ne peut pas modifier les variables sensibles
#
# Équipe "data-team"
#   - Accès Write aux workspaces liés aux données
#   - Accès Read aux autres workspaces
#
# Équipe "security"
#   - Accès Read à tous les workspaces
#   - Peut gérer les politiques Sentinel
#   - Reçoit les notifications sur les violations de politique

Cette séparation des responsabilités garantit que les développeurs peuvent travailler de manière autonome tout en respectant les garde-fous définis par les équipes platform et sécurité.

Workflows API-driven

Terraform Cloud expose une API REST complète qui permet d'automatiser tous les aspects de la plateforme. C'est particulièrement utile pour les intégrations avec des outils tiers ou pour des workflows personnalisés.

Déclencher un Run via l'API

# Créer un run (plan + apply) via l'API
curl \
  --header "Authorization: Bearer $TF_CLOUD_TOKEN" \
  --header "Content-Type: application/vnd.api+json" \
  --request POST \
  --data '{
    "data": {
      "attributes": {
        "message": "Déploiement API v2.3.1 - Mise à jour des instances",
        "auto-apply": false
      },
      "type": "runs",
      "relationships": {
        "workspace": {
          "data": {
            "type": "workspaces",
            "id": "ws-xxxxxxxxxx"
          }
        }
      }
    }
  }' \
  https://app.terraform.io/api/v2/runs

Vérifier le statut d'un Run

# Récupérer le statut d'un run
curl \
  --header "Authorization: Bearer $TF_CLOUD_TOKEN" \
  https://app.terraform.io/api/v2/runs/$RUN_ID | jq '.data.attributes.status'

# Statuts possibles : pending, planning, planned, cost_estimating,
# policy_checking, policy_override, confirmed, apply_queued,
# applying, applied, discarded, errored, canceled

Intégration avec Slack ou Microsoft Teams

Terraform Cloud supporte nativement les notifications vers Slack, Microsoft Teams, ou tout webhook générique. Configurez des notifications pour être alerté quand un plan nécessite une approbation, quand un apply réussit ou échoue, ou quand une politique Sentinel est violée.

Migrer de Terraform Local vers Terraform Cloud

Si vous utilisez déjà Terraform avec un backend local ou S3, la migration vers Terraform Cloud est relativement simple. Voici le processus étape par étape.

Étape 1 : Préparer la Configuration

# AVANT : backend S3
terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "production/terraform.tfstate"
    region = "eu-west-3"
  }
}

# APRÈS : Terraform Cloud
terraform {
  cloud {
    organization = "codeclan-fr"

    workspaces {
      name = "production-aws"
    }
  }
}

Étape 2 : Migrer le State

# 1. S'assurer que le state actuel est à jour
terraform plan
# Vérifier qu'aucun changement n'est détecté

# 2. Modifier la configuration backend (voir ci-dessus)

# 3. Initialiser avec migration
terraform init -migrate-state

# Terraform détecte le changement de backend et propose
# de migrer le state. Répondez "yes".

# 4. Vérifier la migration
terraform plan
# Doit afficher "No changes" - le state a été migré avec succès

Étape 3 : Configurer les Variables

Après la migration, vous devez configurer les variables d'environnement dans Terraform Cloud (credentials AWS, variables Terraform, etc.) via l'interface web ou l'API, car elles ne sont pas migrées automatiquement.

Étape 4 : Mettre à Jour les Workflows de l'Équipe

Assurez-vous que tous les membres de l'équipe exécutent terraform login.
Mettez à jour la documentation interne.
Supprimez les anciens pipelines CI/CD qui géraient le plan/apply (Terraform Cloud s'en charge désormais).
Configurez les notifications pour l'équipe.

Bonnes Pratiques pour Terraform Cloud

Organisation des Workspaces

Adoptez une convention de nommage claire pour vos workspaces. Par exemple : <projet>-<environnement>-<région> comme api-production-eu-west-3 ou frontend-staging-us-east-1.

Sécurité

Utilisez des credentials dynamiques plutôt que des clés statiques quand c'est possible (OIDC avec AWS, Azure, GCP).
Marquez toutes les variables sensibles comme telles.
Activez l'authentification à deux facteurs pour tous les utilisateurs.
Utilisez des Variable Sets pour partager des credentials communs entre workspaces sans les dupliquer.

Performance

Découpez votre infrastructure en workspaces ciblés plutôt qu'un seul workspace monolithique.
Utilisez des run triggers pour chaîner des workspaces dépendants (ex : le workspace réseau déclenche le workspace compute après apply).
Activez le Structured Run Output pour des logs plus lisibles.

Variable Sets

# Les Variable Sets permettent de partager des variables
# entre plusieurs workspaces

# Exemple : Variable Set "AWS Production Credentials"
# Appliqué à : production-*, api-production, db-production
#
# Variables :
#   AWS_ACCESS_KEY_ID     (env, sensitive)
#   AWS_SECRET_ACCESS_KEY (env, sensitive)
#   AWS_DEFAULT_REGION    (env) = "eu-west-3"
#
# Exemple : Variable Set "Common Tags"
# Appliqué à : tous les workspaces
#
# Variables :
#   company    (terraform) = "CodeClan"
#   managed_by (terraform) = "terraform"

Conclusion

Terraform Cloud transforme Terraform d'un outil individuel en une véritable plateforme de collaboration pour les équipes. Avec la gestion centralisée du state, l'exécution à distance, les politiques Sentinel, l'estimation des coûts et le registre privé de modules, il apporte des réponses concrètes aux défis du travail en équipe sur l'Infrastructure as Code.

La migration depuis un usage local est progressive et réversible. Vous pouvez commencer par le plan gratuit, migrer un premier workspace de développement, et étendre progressivement à toute votre infrastructure. L'investissement en temps est minime comparé aux gains en sécurité, traçabilité et productivité.

Dans le prochain article, nous explorerons comment mettre en place un pipeline CI/CD complet pour Terraform, avec des exemples concrets utilisant GitHub Actions et GitLab CI. Restez connectés sur CodeClan !