Optimiser CI/CD avec GitHub Actions et Terraform sur AWS

Introduction

GitHub Actions + Terraform + AWS, c'est le trio que j'ai déployé chez F2R2, TEKYN et Earny SA avec des résultats mesurables à chaque fois. Cette combinaison offre un pipeline CI/CD complet et sécurisé : GitHub Actions orchestre les workflows, Terraform provisionne l'infrastructure de manière déclarative, et AWS héberge le tout avec ses services managés. Voici le retour d'expérience détaillé de ces trois missions.

L'architecture F2R2 : 25 modules Terraform, 19% d'économies AWS

La mission F2R2 est l'une des plus ambitieuses que j'ai menées sur ce trio. Tout a commencé par un audit de 15 jours de l'infrastructure AWS existante : des ressources créées manuellement en console, des security groups trop permissifs, des instances surdimensionnées, et aucune traçabilité des changements. L'audit a identifié 19% d'économies possibles sur la facture AWS, rien qu'en rightsizing et en supprimant les ressources orphelines.

J'ai ensuite conçu une architecture AWS Multi-Compte avec 25 modules Terraform : VPC (subnets publics/privés, NAT Gateway, flow logs), EKS Fargate, Aurora PostgreSQL (avec réplication multi-AZ), S3 (avec versioning et lifecycle policies), CloudFront (CDN avec WAF intégré), GuardDuty (détection de menaces), CloudTrail (audit trail), IAM cross-account avec le principe du moindre privilège, et les Security Groups avec des règles strictes. Chaque module est autonome, documenté avec terraform-docs, et versionné dans un registry Terraform privé. Créer un nouvel environnement complet (dev, staging ou prod) prend 45 minutes au lieu de 3 jours en configuration manuelle.

OIDC : éliminer les credentials statiques pour de bon

L'authentification GitHub Actions vers AWS via OIDC (OpenID Connect) est un changement fondamental en matière de sécurité. Avant, chez la plupart de mes clients, les AWS Access Keys étaient stockées en secrets GitHub. Le risque : une fuite de ces credentials (dans un log, dans un fork public, via un collaborateur malveillant) donne un accès permanent au compte AWS.

Avec OIDC, GitHub Actions s'authentifie auprès d'AWS avec un token éphémère de 15 minutes, sans aucun secret stocké. La configuration côté AWS : un Identity Provider GitHub dans IAM, un rôle avec une trust policy limitée au repo exact et à la branche autorisée. Chez F2R2, chaque compte AWS (dev, staging, prod) avait son propre OIDC provider et son IAM role dédié avec des permissions minimales. Le role de prod ne pouvait que mettre à jour les services EKS et les task definitions, pas créer de nouvelles ressources. Chez Earny SA, cette approche a été adoptée dès le premier jour de la migration GCP vers AWS. C'est devenu mon standard non négociable.

Pipeline Terraform dans GitHub Actions : le workflow éprouvé

Mon pipeline Terraform dans GitHub Actions suit un pattern que j'ai affiné sur 5 ans et une dizaine de projets. Le job "plan" s'exécute sur chaque pull request : il initialise Terraform, exécute tflint pour détecter les mauvaises pratiques HCL, tfsec pour l'analyse de sécurité, puis terraform plan. Le plan est posté en commentaire de la PR pour review par l'équipe. Les reviewers voient exactement quelles ressources seront créées, modifiées ou détruites.

Le job "apply" s'exécute uniquement après merge sur la branche main, via l'environment GitHub "production" qui nécessite une approbation manuelle chez F2R2. Il récupère le plan sauvegardé en artefact et l'applique. Le state Terraform est stocké dans S3 avec DynamoDB pour le locking (empêcher les apply concurrents) et versioning S3 activé pour le backup. Chez F2R2, j'ai détecté une fois un apply concurrent lancé manuellement par un développeur impatient : le locking DynamoDB l'a bloqué et a évité une corruption de state qui aurait pu prendre des heures à résoudre.

Du Terraform au déploiement applicatif sur EKS

Une fois l'infrastructure Terraform en place, le pipeline applicatif prend le relais. La séparation entre le pipeline infra (Terraform) et le pipeline applicatif (Docker + ArgoCD) est essentielle : l'infrastructure change rarement (quelques fois par mois), les applications changent plusieurs fois par jour. Mélanger les deux dans un seul pipeline crée de la complexité inutile.

Chez F2R2, le pipeline applicatif dans GitHub Actions construit l'image Docker avec Buildx, la pousse sur ECR avec le tag SHA du commit, puis met à jour les Helm values dans le repo GitOps. ArgoCD détecte le changement et déploie sur EKS Fargate. Le tout en 8 minutes. Chez TEKYN, l'architecture était plus simple : pas de Kubernetes, GitHub Actions mettait à jour directement le task definition ECS Fargate avec la nouvelle image, et ECS orchestrait le rolling update. Le déploiement prenait 6 minutes. L'outil s'adapte à la complexité du projet : pas besoin d'ArgoCD et Kubernetes pour un monolithe qui tourne bien sur ECS.

Monitoring post-déploiement : boucler la boucle

Le pipeline ne s'arrête pas au déploiement. Le monitoring post-déploiement est la boucle de feedback qui ferme le cycle CI/CD et détecte les régressions que les tests n'ont pas attrapées. Chez F2R2, CloudWatch collectait les métriques applicatives et les logs, avec des alertes CloudWatch Alarms vers SNS puis un webhook Discord. GuardDuty surveillait les menaces de sécurité en temps réel (tentatives de brute force, accès suspects aux API AWS, communications avec des IPs malveillantes). AWS Config vérifiait en continu que les ressources respectaient les règles de conformité (S3 buckets chiffrés, security groups restrictifs, logs activés).

Chez TEKYN, CloudFront fournissait les métriques de performance CDN (hit ratio, latence P95), et ECS les métriques de santé des conteneurs (CPU, mémoire, health checks). Un dashboard CloudWatch unifié donnait une vue d'ensemble de l'état de la plateforme. Cette observabilité post-déploiement a permis de détecter un problème de performance dès le premier déploiement sur la nouvelle infrastructure : une latence anormale sur les requêtes API causée par un security group qui forçait le trafic à passer par un NAT Gateway inutile.

Conclusion

GitHub Actions, Terraform et AWS forment un trio que j'ai éprouvé sur des missions très différentes : architecture multi-compte complexe (F2R2), e-commerce avec ECS Fargate (TEKYN), et migration cloud (Earny SA). Les clés du succès : séparer les pipelines infra et applicatif, adopter OIDC pour l'authentification sans credentials, valider le Terraform dans la CI avec tflint et tfsec, et monitorer après chaque déploiement. Cette architecture est reproductible, sécurisée et adaptable à tout projet AWS.