Optimisation de la chaîne CI/CD avec Github Actions et Terraform
Introduction
Optimiser une chaine CI/CD ne se fait pas en un jour. Chez F2R2, l'architecture AWS Multi-Compte avec 25 modules Terraform et un pipeline GitHub Actions complet a été construite itérativement sur plusieurs semaines. Voici les optimisations concrètes qui font la différence entre un pipeline médiocre et un pipeline industriel.
Accélérer GitHub Actions avec le cache et la parallélisation
Le temps de pipeline est le premier levier d'optimisation. Chez TEKYN, le pipeline initial prenait 25 minutes — inacceptable pour du e-commerce. En parallélisant les jobs (lint et tests en parallèle, build séquentiel après), on a gagné 40%. En ajoutant le cache des dépendances pnpm et des layers Docker, encore 30%. Résultat : 7 minutes. Sur WizOps.fr, le cache du store pnpm économise 45 secondes par run. L'utilisation de runners self-hosted apporte un gain supplémentaire sur les builds Docker lourds. Mon conseil : mesurez le temps de chaque étape, identifiez le goulot d'étranglement, et optimisez en priorité.
Terraform : modularisation et state management
Chez F2R2, les 25 modules Terraform étaient organisés par responsabilité : network/ (VPC, subnets, NAT), compute/ (EKS, node groups), database/ (Aurora), security/ (WAF, GuardDuty, IAM). Chaque module avait son propre state S3 avec DynamoDB locking. Cette séparation permet a plusieurs ingénieurs de travailler en parallèle sur différentes parties de l'infrastructure sans conflit. Chez Bloomflow, la meme organisation permettait de déployer la couche réseau indépendamment de la couche applicative. L'utilisation de terraform_remote_state data sources connectait les modules entre eux de manière déclarative.
Le workflow PR-based : review d'infrastructure
Le pattern PR-based pour Terraform est fondamental. Chez F2R2, chaque modification d'infrastructure passait par une PR avec terraform plan automatique posté en commentaire. L'équipe reviewait le plan visuellement : ajout de 2 security groups, modification d'un scaling policy, etc. Chez KNDS dans le secteur défense, cette review était obligatoire et archivée pour l'audit. Le merge déclenchait terraform apply automatiquement. Ce workflow a éliminé 100% des modifications manuelles via la console cloud — une source majeure d'incidents et de drift. La traçabilité Git couvrait chaque changement d'infrastructure.
Sécurité et conformité du pipeline
Chez F2R2, le pipeline incluait checkov pour scanner les configurations Terraform contre les benchmarks CIS et les bonnes pratiques AWS. Chez KNDS, tfsec détectait les security groups trop ouverts ou les buckets S3 non chiffrés. Les credentials IAM du pipeline avaient des permissions minimales (principe du moindre privilège). Chez Bloomflow avec ISO 27001, chaque exécution du pipeline était loggée et auditable. Sur GitHub Actions, les permissions du workflow limitaient l'accès du token GITHUB_TOKEN au strict nécessaire. La sécurité du pipeline est aussi importante que la sécurité de l'infrastructure qu'il déploie.
Retour d'expérience : les gains mesurés
Chez F2R2, l'audit AWS de 15 jours a identifié 19% d'économies budgétaires. Le pipeline Terraform/GitHub Actions a ensuite implémenté ces optimisations de manière automatisée et reproductible. Chez Bloomflow, le temps de provisionning d'un nouvel environnement complet est passé de 2 jours (manuel) a 30 minutes (Terraform + GitHub Actions). Chez Metronome, la standardisation des déploiements OVH Cloud via Terraform a éliminé les divergences entre environnements. Le feedback continu — revue du plan, logs d'apply, surveillance post-déploiement — permet d'itérer constamment sur le pipeline.
Conclusion
L'optimisation de la chaine CI/CD avec GitHub Actions et Terraform est un processus itératif. Cache, parallélisation, modularisation Terraform, workflow PR-based, sécurité intégrée — chaque amélioration contribue a un pipeline plus rapide, plus fiable et plus sécurisé. Les gains sont mesurables : temps réduit, couts optimisés, incidents évités. C'est cette approche incrémentale que j'applique chez chaque client WizOps.