CI/CD Terraform avec GitLab et GitHub Actions — workflows complets 2026

📍 Article principal : Terraform Associate 004 — guide complet. Ce tutoriel automatise les déploiements Terraform via GitLab CI et GitHub Actions avec workflow complet : fmt, validate, plan en pull request, apply automatique en merge.

L’apply manuel Terraform depuis le laptop d’un développeur reste acceptable pour le prototype mais inacceptable en production. Trois problèmes : pas de traçabilité (qui a fait quoi quand), pas de revue par les pairs, risque d’erreurs humaines (apply sur le mauvais workspace, oubli de mise à jour du state). Le pipeline CI/CD résout ces trois problèmes en automatisant le workflow Terraform — chaque modification passe par une pull request avec plan automatique, l’apply ne se déclenche qu’après validation et merge. Ce tutoriel détaille les workflows GitLab CI et GitHub Actions, intégration HCP Terraform, sécurité des credentials.

Prérequis

• Projet Terraform avec backend remote (voir Hetzner, backend, modules)
• Compte GitLab ou GitHub avec dépôt Git initialisé
• Notions GitLab CI ou GitHub Actions
• Niveau : avancé
• Temps estimé : 4 à 5 heures

Workflow type pour Terraform en CI/CD

Le workflow standardisé suit cinq étapes. Étape 1, sur push vers une branche feature : lint et validate du code. Étape 2, sur pull request vers main : terraform fmt vérifié, validate, plan exécuté avec output dans la PR pour revue. Étape 3, revue humaine du plan par un pair. Étape 4, sur merge vers main : apply automatique du plan validé. Étape 5, notification de l’équipe sur le succès ou l’échec via Slack/Telegram/email.

Cette discipline simple transforme Terraform d’un outil opérationnel risqué en pipeline industrialisé. Chaque modification est tracée par commit Git, validée par revue, déployée par CI. Les retours arrière deviennent triviaux via revert Git. La gouvernance s’enrichit naturellement : branches protégées qui exigent revue, code owners pour les fichiers sensibles, signed commits pour les modules critiques.

Workflow GitLab CI complet

GitLab CI utilise un fichier .gitlab-ci.yml à la racine du dépôt qui définit les stages et jobs du pipeline. Configuration type pour Terraform : image hashicorp/terraform officielle, stages validate/plan/apply, jobs déclenchés selon les règles de branche. Variables sensibles (token Hetzner, credentials AWS) stockées dans GitLab CI/CD Variables avec flag protected pour limiter l’accès aux branches protégées.

stages:
  - validate
  - plan
  - apply

image: hashicorp/terraform:1.7

before_script:
  - terraform init -backend-config="bucket=tf-state-masociete-2026"

validate:
  stage: validate
  script:
    - terraform fmt -check -diff
    - terraform validate

plan:
  stage: plan
  script:
    - terraform plan -out=tfplan
  artifacts:
    paths: [tfplan]
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

apply:
  stage: apply
  script:
    - terraform apply tfplan
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual

Le job apply en mode manual exige un clic explicite dans l’interface GitLab — protection supplémentaire contre les apply accidentels. Pour les organisations qui veulent un apply automatique post-merge, retirer le when: manual mais garder une protection via approbations multiples sur la PR. La règle : trade-off entre vitesse de déploiement et sécurité opérationnelle, à arbitrer selon le contexte.

Workflow GitHub Actions équivalent

GitHub Actions utilise des fichiers YAML dans .github/workflows/. La structure diffère légèrement de GitLab CI mais les concepts restent identiques : jobs déclenchés sur événements (push, pull_request), steps qui exécutent des commandes ou actions de la marketplace. L’action officielle hashicorp/setup-terraform simplifie l’installation et la configuration. Les secrets sont gérés via GitHub Secrets, accessibles uniquement aux workflows autorisés.

Pour le commentaire automatique du plan dans la PR, l’action hashicorp/terraform-github-actions ou un script avec gh CLI poste le plan en commentaire. Cette visibilité immédiate accélère la revue — le reviewer voit immédiatement l’impact des changements sans avoir à pull la branche localement et exécuter le plan. Cette amélioration UX simple transforme l’expérience de revue Terraform en équipe.

Intégration HCP Terraform pour CI/CD avancée

Pour les organisations qui ont déjà HCP Terraform, déléguer le run au backend HCP simplifie radicalement la CI. Le workflow GitLab ou GitHub se réduit à : déclencher un run HCP via API, attendre le résultat, marquer le statut de la PR en succès ou échec. HCP gère lui-même fmt, validate, plan, apply selon ses propres workflows. Les outputs sont accessibles via API pour publication dans la PR.

L’avantage : HCP centralise tous les runs avec historique, drift detection automatique, Sentinel policies pour valider les plans avant apply (par exemple interdire les ressources publiques sans tags compliance). L’inconvénient : dépendance à HCP qui peut tomber. Pour les organisations qui veulent maximum d’autonomie, garder GitLab CI ou GitHub Actions en autonomie reste le choix par défaut. Pour celles qui valorisent les fonctionnalités avancées HCP, l’intégration s’amortit rapidement sur la productivité gagnée.

Sécurité des credentials

Les credentials Terraform sont les clés du royaume — leur fuite expose toute l’infrastructure. Quatre disciplines impératives. Première : ne jamais committer de credentials dans Git, même temporairement. Utiliser .gitignore strict et gitleaks en pre-commit hook pour détecter les fuites accidentelles. Deuxième : stocker les credentials dans le système de secrets de la CI (GitLab Variables, GitHub Secrets) avec flag masked qui les obfuscation dans les logs.

Troisième : utiliser des credentials short-lived quand possible. AWS supporte les rôles IAM assumables qui génèrent des credentials temporaires (1 heure) à chaque run CI — bien plus sûr que des access keys permanents. Quatrième : rotation périodique des credentials longs (tous les 90 jours minimum). Documenter cette politique dans le runbook sécurité de l’organisation. Pour les organisations matures, intégrer Vault dynamic secrets qui génère des credentials valides uniquement pendant le run CI puis les révoque automatiquement.

Drift detection et reconciliation

Le drift désigne la divergence entre ce que Terraform pense gérer (le state) et la réalité (l’infrastructure). Causes typiques : modification manuelle dans la console cloud, suppression accidentelle d’une ressource par un autre outil, changement automatique par le provider cloud. Sans détection, le drift s’accumule et le prochain terraform apply produit des changements inattendus.

Mettre en place un job CI nocturne qui exécute terraform plan -detailed-exitcode. Si le plan détecte des changements (exit code 2), notifier l’équipe via Slack ou email. Cette surveillance proactive identifie le drift avant qu’il ne devienne problématique. HCP Terraform et certains outils tiers (env0, Spacelift, Scalr) proposent cette fonctionnalité native — investissement valorisé pour les organisations qui gèrent beaucoup de ressources.

Sentinel policies en bref

Sentinel est le langage de policy-as-code de HashiCorp. Permet de définir des règles qui valident les plans Terraform avant apply. Exemples typiques : interdire les S3 buckets publics, exiger des tags spécifiques sur toutes les ressources, limiter les types d’instance autorisés. Les policies sont écrites en Sentinel HCL puis attachées aux workspaces HCP Terraform. À chaque plan, les policies sont évaluées — toute violation bloque l’apply.

Pour la certification Terraform Associate 004, connaître l’existence et le rôle de Sentinel est suffisant — les questions ne demandent pas d’écrire des policies. En production réelle, les Sentinel policies deviennent stratégiques pour les organisations qui veulent industrialiser leur gouvernance IaC. Investissement initial de quelques jours pour les premières policies, retour sur investissement immédiat en termes de prévention d’incidents et de conformité.

Atlantis : alternative open source pour le workflow Terraform

Atlantis est un service open source qui automatise les workflows Terraform avec une approche orientée pull request. Quand un développeur ouvre une PR, Atlantis exécute terraform plan et poste le résultat en commentaire. Pour appliquer, le développeur poste un commentaire atlantis apply. Le service gère le locking, la traçabilité, l’enchaînement de plusieurs PRs sur le même workspace. Auto-hébergé sur Coolify ou Kubernetes, Atlantis offre les fonctionnalités d’HCP Terraform pour zéro coût mensuel.

Pour les PME ouest-africaines qui veulent autonomie totale et budget minimal, Atlantis est un excellent compromis. La maintenance opérationnelle reste contenue (un VPS modeste suffit), l’expérience utilisateur est proche d’HCP, l’intégration avec GitLab et GitHub est native. Plusieurs cabinets de conseil ouest-africains ont adopté Atlantis comme standard pour leurs missions IaC : l’argument coût zéro plus contrôle total séduit les clients sensibles aux dépenses cloud récurrentes.

Notifications et observabilité du pipeline

Un pipeline CI/CD sans notifications est aveugle. Configurer trois canaux essentiels. Premier : notifications Slack ou Telegram sur succès et échec des apply, avec lien direct vers le run. Deuxième : alertes email en cas d’échec critique (apply échoué après merge sur main). Troisième : dashboard Grafana qui affiche les statistiques temporelles — fréquence d’apply, taux de succès, temps moyen, ressources créées vs détruites.

Pour aller plus loin, instrumenter les jobs CI avec des métriques Prometheus exposées via webhook. Cette télémétrie permet de détecter les régressions de performance (un terraform plan qui devient progressivement plus lent indique souvent un state surchargé), les patterns d’usage (heures de pic des applys), et la santé globale de la plateforme IaC. Investissement minime pour une visibilité opérationnelle considérable, particulièrement appréciée par les directeurs techniques qui veulent piloter par les données.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Pour les PME ouest-africaines, GitLab CI ou GitHub Actions en plan gratuit couvre les premiers besoins (2 000 minutes par mois CI). Au-delà, les plans payants restent abordables — environ 4 USD par utilisateur et par mois. Pour les organisations qui veulent une CI auto-hébergée, GitLab CE installable sur Coolify offre une solution complète à coût zéro hors infrastructure VPS. Cette autonomie totale est appréciée pour les déploiements souverains et les organisations qui veulent réduire les dépendances cloud étrangères.

Pipeline avancé multi-environnements

Pour les organisations qui gèrent dev, staging, prod, le pipeline se complexifie. Pattern recommandé : une seule base de code, plusieurs workspaces ou dossiers terraform.tfvars. Le pipeline détecte la branche cible et applique le plan correspondant — push sur develop déclenche l’apply staging, push sur main déclenche l’apply prod (avec approbation manuelle). Cette structure mono-repo facilite la cohérence entre environnements et accélère les promotions de code.

Pour les ETI qui veulent isoler totalement les environnements (différents comptes cloud, différentes équipes), basculer en multi-repo. Chaque environnement a son propre dépôt avec son propre pipeline et ses propres credentials. Plus de cloisonnement mais coût opérationnel supérieur. La règle de décision : mono-repo jusqu’à 30 développeurs ou 100 ressources, multi-repo au-delà.

Coût opérationnel et ROI du pipeline

Décomposition du coût opérationnel d’un pipeline Terraform CI/CD pour une PME ouest-africaine. GitLab CI ou GitHub Actions plan gratuit suffit jusqu’à 2 000 minutes par mois — environ 100 apply par mois si chaque apply prend 1 minute. Au-delà, plan payant à 4 USD par utilisateur et par mois. Backend S3+DynamoDB : quelques centimes par mois. Stockage Storage Box pour artifacts CI : 4 EUR par mois. Total mensuel typique pour 5 développeurs : moins de 30 EUR.

ROI mesurable. Avant pipeline : chaque modification d’infrastructure prend 30 à 60 minutes (review manuelle, apply local, vérification, communication). Après pipeline : 5 à 10 minutes par modification (push, revue PR, merge automatique). Économie de 30 minutes par modification, multiplié par 50 modifications par mois pour une équipe active, soit 25 heures de gain mensuel — équivalent à environ 600 000 XOF mensuel à TJM moyen ouest-africain. ROI atteint en moins d’un mois sur le coût d’infrastructure CI.

Patterns avancés : OIDC pour credentials sans secret

Une avancée majeure 2025-2026 : l’authentification OIDC (OpenID Connect) entre la CI et les providers cloud. Au lieu de stocker des credentials AWS dans GitHub Secrets, configurer un trust relationship qui authentifie chaque run CI via son identité OIDC unique. Plus de credentials longs à gérer ni à roter — chaque run obtient des credentials temporaires valides uniquement pendant son exécution. AWS, GCP, Azure et HCP supportent tous OIDC depuis 2024.

Cette approche élimine une classe entière de risques sécuritaires. Plus de credentials qui fuitent, plus de rotation à gérer, plus de credentials orphelins après le départ d’un développeur. La configuration initiale prend deux à trois heures la première fois, puis devient un standard pour tous les nouveaux pipelines. Pour les organisations matures, c’est désormais le pattern par défaut — l’usage de credentials statiques devient progressivement obsolète et déconseillé par les guides de sécurité cloud.

L’industrialisation complète de Terraform via CI/CD constitue désormais le standard de fait des organisations techniques sérieuses, et son adoption par les PME ouest-africaines marque leur entrée dans l’écosystème DevOps mature mondialement reconnu.

Cette adoption méthodique du CI/CD Terraform marque le passage symbolique d’une organisation tech amateure à une organisation tech mature et compétitive sur le marché international.

Pour aller plus loin

🔝 Retour à l’article principal : Terraform Associate 004. Tutoriels précédents : Hetzner, backend, modules. Documentation Atlantis (alternative open source) : runatlantis.io, GitLab Terraform integration : docs.gitlab.com/iac.

L’industrialisation de Terraform via CI/CD constitue le passage à l’âge mature de l’IaC dans une organisation. Les PME qui adoptent cette discipline construisent des plateformes infrastructure reproductibles, traçables, et auditables — fondation des organisations techniques modernes. Cette transformation prend quelques semaines de mise en place initiale, mais le bénéfice opérationnel se mesure en années — moins d’incidents, accélération du delivery, montée en compétence de l’équipe par exposition au workflow industrialisé.