Optimisation des Déploiements avec GitHub Actions et Terraform
Introduction
Terraform et GitHub Actions forment un duo redoutable pour l'Infrastructure as Code en pipeline. Chez F2R2, j'ai construit une architecture AWS multi-comptes entière (25 modules Terraform, EKS Fargate, Aurora, WAF, GuardDuty) déployée exclusivement via GitHub Actions. Aucune modification d'infrastructure ne passait en dehors du pipeline. Voici les enseignements de cette approche.
Le workflow Terraform en PR : plan, review, apply
Le pattern fondamental que j'applique systématiquement : chaque modification Terraform passe par une PR. Le pipeline exécute terraform plan et poste le résultat en commentaire sur la PR. Le reviewer vérifie le plan avant d'approuver. Le merge déclenche terraform apply. Chez F2R2, ce workflow a été déployé sur les 25 modules avec des protections de branche strictes : au moins 1 approbation requise, pipeline vert obligatoire, et un label infra-approved posé par un SRE senior. Cette rigueur peut sembler lourde, mais sur un projet avec Aurora PostgreSQL, WAF et GuardDuty, une erreur Terraform peut avoir des conséquences catastrophiques. Le plan commenté sur la PR a intercepté 12 modifications potentiellement destructives en 4 mois.
La gestion du state Terraform
Le state Terraform est la pièce la plus critique de l'infrastructure. Je le stocke toujours dans un backend distant avec locking. Chez F2R2, le state de chaque module était dans un bucket S3 dédié avec versioning activé, chiffrement SSE-KMS, et un DynamoDB table pour le locking. Le pipeline GitHub Actions assumait un rôle IAM spécifique via OIDC (pas de clés d'accès statiques stockées en secrets). Cette approche OIDC est un game-changer en sécurité : pas de rotation de clés à gérer, des sessions éphémères, et une traçabilité via CloudTrail. Chez Metronome avec Terraform sur OVH, le state était dans un bucket S3 compatible OVH avec le même pattern de locking.
Les modules Terraform réutilisables
La factorisation du code Terraform en modules est essentielle pour la maintenabilité. Chez F2R2, les 25 modules étaient organisés en couches : modules de base (VPC, IAM, S3), modules de compute (EKS, Fargate profiles), modules applicatifs (Aurora, ElastiCache), et modules de sécurité (WAF, GuardDuty, Security Hub). Chaque module avait ses propres tests (terraform validate + plan sur un workspace de test) et une documentation générée automatiquement par terraform-docs. Un changement dans un module de base déclenchait les tests de tous les modules qui en dépendaient. Cette architecture modulaire a permis de construire l'infrastructure de 4 comptes AWS (dev, staging, prod, shared-services) avec un minimum de duplication.
Les tests Terraform dans le pipeline
Tester l'infrastructure dans un pipeline CI est un défi. Chez F2R2, j'ai mis en place trois niveaux de tests. Premier niveau : terraform validate et tflint sur chaque PR (30 secondes). Deuxième niveau : terraform plan avec analyse automatique des changements destructifs (2 minutes). Troisième niveau : déploiement sur un environnement éphémère (workspace Terraform dédié) suivi de tests d'intégration Terratest qui vérifiaient que les ressources créées correspondaient aux spécifications (15 minutes, exécuté uniquement sur les merges dans main). Le troisième niveau coûtait environ 5 euros par exécution en ressources AWS éphémères, mais a détecté des erreurs de configuration qui n'auraient été visibles qu'en production.
La gestion des drift et la réconciliation
Le drift (écart entre l'état réel de l'infrastructure et le state Terraform) est un problème insidieux. Chez Earny SA, lors de la migration GCP vers AWS, des modifications manuelles d'urgence avaient créé des drifts dans le state Terraform. J'ai mis en place un CronJob GitHub Actions qui exécutait terraform plan quotidiennement sur chaque module. Si un drift était détecté, une issue GitHub était créée automatiquement avec le détail des écarts. Cette surveillance proactive a détecté 3 drifts en 2 mois : un Security Group modifié manuellement, un tag ajouté par AWS Config, et un changement de policy IAM fait via la console par erreur. Sans cette surveillance, ces drifts auraient causé des surprises lors du prochain apply.
Conclusion
Terraform et GitHub Actions permettent de traiter l'infrastructure avec la même rigueur que le code applicatif : review, tests, déploiement automatisé, et surveillance continue. Les clés du succès sont un state sécurisé avec OIDC, des modules réutilisables bien testés, un workflow de PR strict, et une détection proactive des drifts. Cette approche, éprouvée sur des architectures AWS complexes, transforme l'infrastructure d'un risque en un actif maîtrisé.