Optimiser le Déploiement Continu avec GitHub Actions et Terraform
Introduction
Après avoir optimisé des dizaines de pipelines GitHub Actions + Terraform, j'ai développé des patterns récurrents qui fonctionnent quel que soit le projet. De la startup TEKYN à l'architecture Multi-Compte F2R2, ces optimisations se sont affinées au fil des missions. Voici les techniques avancées que j'applique.
GitHub Actions : optimisation du temps d'exécution
Le temps d'exécution est l'ennemi du développeur. Sur WizOps.fr, le build Docker multi-plateforme avec Buildx prenait initialement 8 minutes sur un runner GitHub-hosted. Trois optimisations ont fait la différence : runner self-hosted (cache Docker local persistant), Buildx avec cache registry (layers partagées entre builds), et optimisation du Dockerfile (ordonnancement des layers pour maximiser le cache). Résultat : 2 minutes. Chez F2R2, la parallélisation des terraform plan par module via les matrices GitHub Actions a réduit le temps total de 4 minutes à 90 secondes. L'action actions/cache pour le cache des providers Terraform a encore gagné 20 secondes.
Terraform : patterns avancés
Au-delà des bases, certains patterns Terraform font la différence. Les data sources pour référencer des ressources existantes sans les gérer (utile en migration). Les moved blocks pour refactorer sans détruire de ressources. Les import blocks pour ramener des ressources créées manuellement sous gestion Terraform. Chez Earny SA, lors de la migration GCP vers AWS, les import blocks ont permis d'intégrer progressivement les ressources AWS existantes dans Terraform sans interruption. Chez F2R2, les modules Terraform utilisaient des for_each sur les comptes AWS pour éviter la duplication de code : un seul module VPC déployé sur 3 comptes.
Cas concret : pipeline TEKYN
Chez TEKYN (e-commerce), le pipeline complet orchestrait : checkout du code, linting, tests unitaires, build Docker, push ECR, terraform plan (pour les changements d'infra), mise à jour de la task definition ECS, déploiement Fargate, health check post-déploiement. Le tout en 8 minutes. Le secret : chaque étape était optimisée individuellement. Les tests en parallèle du build Docker (deux jobs indépendants). Le push ECR avec cache de layers. Le déploiement ECS avec l'action aws-actions/amazon-ecs-deploy-task-definition. Si le health check échouait, un rollback automatique restaurait la version précédente de la task definition.
Sécurité avancée des pipelines
La sécurité des pipelines a évolué avec les menaces. L'attaque par supply chain (action GitHub malveillante) est un risque réel. Ma protection : pinger les actions par SHA, pas par tag. Utiliser OIDC pour l'authentification AWS au lieu de secrets statiques. Chez F2R2, le workflow utilisait aws-actions/configure-aws-credentials avec OIDC : zéro credential stocké, le token est éphémère et scopé à la durée du job. Chez KNDS, les runners self-hosted étaient dans un réseau isolé, avec accès limité aux registries d'images et aux API cloud nécessaires. Le principe de moindre privilège s'applique aussi aux runners.
Cas concret : architecture AWS Multi-Compte F2R2
Le pipeline F2R2 est mon exemple le plus complet. GitHub Actions orchestrait le déploiement sur 3 comptes AWS (management, workload, security) avec 25 modules Terraform. Chaque PR déclenchait un terraform plan sur les modules modifiés (détection via git diff). Le plan était posté en commentaire PR pour review. Après merge, les modules étaient appliqués dans l'ordre des dépendances (VPC avant EKS, EKS avant les workloads). Les environnements de production nécessitaient une approbation manuelle via GitHub Environments. Le state de chaque module était isolé dans un bucket S3 dédié avec verrouillage DynamoDB. Ce pipeline a tourné pendant 6 mois sans incident d'infrastructure.
Conclusion
L'optimisation des pipelines GitHub Actions + Terraform est un art qui se perfectionne avec l'expérience. Les techniques avancées (cache, parallélisation, OIDC, patterns Terraform modernes) font la différence entre un pipeline fonctionnel et un pipeline excellent. C'est cet investissement continu dans la qualité du pipeline qui permet de gérer des architectures complexes sereinement.