Optimisez vos Déploiements avec GitHub Actions et Terraform
Introduction
Le combo GitHub Actions + Terraform est devenu mon standard pour le déploiement d'infrastructure cloud. Chez F2R2, cette stack gère 25 modules Terraform sur une architecture AWS Multi-Compte. Chez TEKYN, elle pilote l'AWS Organization complète. Voici les patterns avancés et les erreurs à éviter, tirés de l'expérience terrain.
Pattern n°1 : le terraform plan dans la PR
C'est la base, mais c'est transformateur. Sur chaque PR qui modifie du Terraform, un workflow GitHub Actions exécute terraform init, terraform validate et terraform plan, puis poste le résultat en commentaire. Le reviewer voit exactement les ressources qui vont être créées, modifiées ou détruites. Chez Bloomflow, cette pratique a empêché au moins 5 incidents potentiels en un an : des Security Groups ouverts par erreur, des instances surdimensionnées, un bucket S3 public. Le plan dans la PR, c'est la revue de code de l'infrastructure.
Pattern n°2 : les modules Terraform réutilisables
Chez F2R2, les 25 modules Terraform sont versionnés dans un repo dédié avec des tags sémantiques. Chaque module a son README, ses variables documentées, ses outputs, et un exemple d'utilisation. Les environnements (dev, staging, prod, shared-services) consomment ces modules avec des versions épinglées. Quand un module est mis à jour, une PR est ouverte automatiquement sur les repos consommateurs (via Renovate). Cette approche a permis de provisionner 4 comptes AWS avec une cohérence parfaite et un effort de maintenance minimal.
Pattern n°3 : l'authentification OIDC
Stocker des clés AWS dans les GitHub Secrets, c'est un anti-pattern de sécurité. Chez Bloomflow, j'utilise OIDC : GitHub Actions s'authentifie directement auprès d'AWS via un trust relationship, sans aucune clé statique. Le workflow assume un rôle IAM avec des permissions minimales et une durée de session limitée. Cette approche est aussi implémentée chez Earny SA (migration GCP vers AWS) et chez KNDS. Bonus : pas de rotation de clés à gérer, pas de risque de fuite de credentials.
Monitoring post-déploiement Terraform
Terraform déploie l'infra, mais il faut aussi surveiller qu'elle reste dans l'état attendu. Le drift detection est un problème réel : quelqu'un fait un changement en console AWS, et l'état réel diverge de l'état Terraform. Chez F2R2, un job GitHub Actions nightly exécute terraform plan et alerte sur Slack si des changements non planifiés sont détectés. Chez Bloomflow, Terraform Cloud gère nativement le drift detection. En parallèle, Prometheus + Grafana surveillent les métriques de l'infra déployée : CPU des instances, IOPS des disques, latence des load balancers.
Sécurité et conformité as code
Chez KNDS, les policies de sécurité sont codées dans le pipeline. Checkov scanne les fichiers Terraform pour détecter les configurations non conformes (S3 public, RDS sans chiffrement, Security Group en 0.0.0.0/0). tfsec complète l'analyse avec des règles plus fines. Ces checks tournent dans le pipeline GitHub Actions sur chaque PR, et le merge est bloqué si une violation critique est détectée. Chez Bloomflow (ISO 27001), ces contrôles automatisés font partie de l'evidence pack pour les audits de conformité. L'auditeur voit que chaque changement d'infra a été validé par les policies avant d'être appliqué.
Conclusion
GitHub Actions + Terraform, c'est l'Infrastructure as Code avec la rigueur du software engineering : revue de code, tests automatisés, sécurité intégrée, déploiement automatisé. Les patterns présentés ici (plan dans la PR, modules réutilisables, OIDC, drift detection, policies as code) sont issus de l'expérience terrain sur des projets critiques. Adoptez-les progressivement, et votre gestion d'infrastructure passera à un autre niveau.