Optimiser le Déploiement Continu avec GitHub Actions et Terraform
Introduction
L'optimisation d'un pipeline GitHub Actions + Terraform est un travail continu. Sur les projets F2R2 et TEKYN, j'ai itéré sur ces pipelines pendant des mois pour atteindre un niveau de fiabilité et de performance satisfaisant. Voici les meilleures pratiques que j'ai consolidées.
Performance du pipeline : chaque seconde compte
Un pipeline lent est un pipeline contourné. Chez F2R2, le terraform plan initial prenait 4 minutes sur 25 modules. En parallélisant les plans par module avec des matrices GitHub Actions, je l'ai réduit à 90 secondes. L'utilisation de terraform init avec un backend S3 et le cache des providers (via l'action actions/cache) a encore gagné 20 secondes. Chez TEKYN, le cache des couches Docker dans GitHub Actions (via docker/build-push-action avec cache-from/cache-to) a réduit le temps de build de 6 à 2 minutes. Ces optimisations paraissent mineures individuellement, mais elles s'additionnent sur des dizaines de builds quotidiens.
Terraform : structurer pour scaler
La structure du code Terraform détermine la maintenabilité à long terme. Chez F2R2, j'ai adopté une structure modulaire stricte : un module par ressource logique (VPC, EKS, Aurora, WAF...), un répertoire par environnement, des variables partagées via Terragrunt. Chaque module avait un README, des exemples d'utilisation, et des tests. Chez Bloomflow, sur 5 ans, la structure a évolué d'un monolithe Terraform à des modules séparés par domaine fonctionnel. Cette refactoring progressive a permis à différentes équipes de travailler sur l'infrastructure en parallèle sans conflits de state.
GitHub Actions : les workflows réutilisables
Les reusable workflows de GitHub Actions sont un game changer pour les organisations multi-repos. Chez Bloomflow, j'ai créé un workflow réutilisable (terraform-plan-apply.yml) dans un repo central, appelé par tous les repos d'infrastructure. Modifier le workflow central mettait à jour le processus sur tous les repos. Chez TEKYN, les composite actions encapsulaient des séquences d'étapes communes (setup AWS credentials, setup Terraform, plan, commentaire PR). Cette factorisation réduit la duplication et les divergences entre repos.
Bonnes pratiques de sécurité consolidées
La sécurité des pipelines Terraform est critique. Voici ma checklist, consolidée après 15 ans d'expérience. Premièrement : OIDC (OpenID Connect) plutôt que des access keys statiques pour l'authentification AWS depuis GitHub Actions. Chez F2R2, cette approche éliminait le risque de fuite de credentials. Deuxièmement : rôles IAM avec permissions minimales, une pour le plan (lecture seule) et une pour l'apply (écriture ciblée). Troisièmement : terraform plan systématique en PR pour review. Quatrièmement : prevent_destroy sur les ressources critiques. Cinquièmement : state chiffré (S3 + KMS) avec verrouillage (DynamoDB).
Monitoring et alerting post-déploiement
Le pipeline ne s'arrête pas au terraform apply. Chez F2R2, un step final vérifiait que les endpoints créés étaient accessibles (health check HTTP). Si un endpoint ne répondait pas, le pipeline échouait avec une notification Slack. Chez Metronome, le workflow incluait un step qui déclenchait un scan Prometheus après chaque déploiement, vérifiant que les métriques clés n'avaient pas dégradé. Ces vérifications post-déploiement ont attrapé des problèmes de configuration (security group mal configuré, DNS non propagé) qui auraient été découverts bien plus tard sans elles.
Conclusion
L'optimisation d'un pipeline GitHub Actions + Terraform est un investissement continu qui paie sur le long terme. Performance, structure, réutilisabilité, sécurité et monitoring post-déploiement sont les 5 piliers d'un pipeline d'infrastructure fiable. C'est cette approche itérative qui m'a permis de gérer des architectures AWS complexes sans incident majeur.