Optimiser votre pipeline CI/CD avec GitHub Actions et Terraform
Introduction
Après avoir optimisé des dizaines de pipelines CI/CD chez mes clients, je constate que la combinaison GitHub Actions + Terraform est la plus demandée et la plus efficace. Chez F2R2, ce duo gère 25 modules Terraform et une architecture AWS Multi-Compte complète. Voici le guide d'optimisation que j'aurais aimé avoir quand j'ai commencé.
GitHub Actions : performances et flexibilité
La performance du pipeline conditionne l'adoption par l'équipe. Chez TEKYN, un pipeline de 25 minutes était ignoré par les développeurs. Après optimisation (parallélisation, cache, runners adaptés), 7 minutes. Sur WizOps.fr, le pipeline complet tourne en moins de 5 minutes. Les leviers principaux : actions/cache pour les dépendances (gain de 45 secondes par run), jobs parallèles pour lint/typecheck/tests, runners self-hosted pour les builds Docker lourds (2x plus rapides). Chez Bloomflow, la stratégie matrix testait sur 3 versions de Node.js en parallèle. Le marketplace GitHub offre des actions préfabriquées pour Terraform, Docker, Kubernetes — pas besoin de réinventer la roue.
Terraform : les modules qui scalent
Chez F2R2, les 25 modules Terraform sont organisés par domaine : network/ (VPC, subnets), compute/ (EKS Fargate), database/ (Aurora), security/ (WAF, GuardDuty), monitoring/ (CloudWatch). Chaque module a son propre state S3 et peut etre appliqué indépendamment. Cette granularité permet de modifier le réseau sans toucher au compute, et vice versa. Chez Bloomflow, les memes modules étaient réutilisés entre AWS et Outscale avec des ajustements mineurs de providers. La modularisation est le facteur clé pour passer de quelques ressources a des centaines sans perdre en lisibilité.
L'intégration qui fait la différence
Le workflow type que j'implémente : sur PR Terraform, GitHub Actions exécute terraform fmt -check, terraform validate, tflint, checkov (scan sécurité), et poste le terraform plan en commentaire de PR. L'équipe review visuellement les changements. Au merge, terraform apply -auto-approve s'exécute. Chez F2R2, ce workflow a éliminé 100% des modifications manuelles via la console AWS — source de 35% des incidents avant mon arrivée. Chez KNDS, la traçabilité Git de chaque changement d'infrastructure était exigée pour les audits de sécurité.
Meilleures pratiques testées en production
Segmentez les workflows : un pour les tests applicatifs, un pour Terraform, un pour le déploiement Docker/Kubernetes. Sur WizOps.fr, le workflow de tests est séparé du workflow de build Docker. Utilisez les GitHub Environments avec required reviewers pour la production : chez Bloomflow, le déploiement prod nécessitait l'approbation d'un lead. Testez dans un staging avant la prod : chez F2R2, le terraform apply en staging précédait toujours la prod de 24h. Documentez chaque workflow : chez Epiconcept, le README du projet détaillait le pipeline. Et surtout, mesurez : temps moyen de pipeline, taux de succès, fréquence de déploiement.
Surveillance et amélioration continue
Un pipeline non surveillé se dégrade. Chez Bloomflow, un dashboard Grafana montrait le temps moyen de pipeline par semaine et par repo. Toute dérive était investiguée. Les logs GitHub Actions s'intègrent avec Prometheus via des exporters pour une analyse avancée. Les dépendances (actions tierces, providers Terraform, versions Node.js) doivent etre mises a jour régulièrement — Renovate automatise ca sur WizOps.fr. Les audits trimestriels de sécurité (vérification des permissions, rotation des secrets, revue des actions utilisées) sont essentiels, surtout dans les contextes réglementaires comme chez KNDS et Bloomflow.
Conclusion
Optimiser un pipeline CI/CD avec GitHub Actions et Terraform, c'est un travail continu. Les fondamentaux : performances (cache, parallélisation), modularité Terraform (modules indépendants), workflow PR-based (review avant apply), sécurité intégrée (scans, permissions minimales) et surveillance du pipeline lui-meme. Ces pratiques, forgées sur des projets exigeants (défense, santé, fintech, e-commerce), sont applicables a toute échelle. C'est exactement l'accompagnement que je propose chez WizOps.