L'Automatisation des Déploiements avec Terraform et Ansible
Introduction
Automatiser les déploiements cloud, ce n'est pas juste écrire des scripts : c'est construire un système reproductible, testable et auditable. Chez F2R2, j'ai bâti une architecture AWS complète en Terraform. Chez Epiconcept, Ansible a géré la configuration de serveurs pendant 4 ans. Voici les leçons tirées de ces expériences.
Terraform : pourquoi le déclaratif change tout
L'approche déclarative de Terraform est sa force principale. Vous décrivez l'état souhaité, Terraform calcule le chemin pour y arriver. Chez F2R2, quand le client a demandé d'ajouter une troisième zone de disponibilité au VPC, j'ai modifié 3 lignes dans le module Terraform. Le terraform plan a montré exactement les 12 ressources qui allaient être créées. Pas de surprise. Comparez avec un script bash impératif où il faut gérer chaque cas de figure manuellement. Sur TEKYN, Terraform gérait l'Organisation AWS complète : les comptes, les politiques SCPs, les rôles cross-account. Un terraform apply sur le module Organization appliquait les changements de gouvernance sur tous les comptes en une seule commande.
Ansible : la configuration sans agent
Chez Epiconcept, les serveurs tournaient sous Debian et hébergeaient des applications sensibles (INSERM, Armées). Installer un agent de configuration n'était pas envisageable pour des raisons de sécurité. Ansible, basé sur SSH, était la solution idéale. Mes playbooks géraient l'installation de MariaDB avec réplication, la configuration de Docker, le déploiement des applications via docker-compose, et les backups automatisés. En 4 ans, pas une seule configuration manuelle n'a été nécessaire. Chaque modification passait par un playbook versionné dans Git, reviewé en PR, puis exécuté depuis la CI GitHub Actions.
L'intégration dans le pipeline CI/CD
L'automatisation des déploiements prend tout son sens quand elle s'intègre dans la CI/CD. Chez F2R2, chaque PR qui touche un module Terraform déclenche automatiquement un terraform plan affiché en commentaire de la PR. Le reviewer voit exactement ce qui va changer. Après merge, le terraform apply s'exécute automatiquement pour les environnements non-production. Pour la production, une approbation manuelle est requise dans le workflow GitHub Actions. Chez Metronome, les playbooks Ansible étaient déclenchés par des pipelines CI après le provisionnement Terraform, assurant une chaîne complète du terraform apply au serveur configuré.
Cas réel : architecture AWS Multi-Compte
Le projet F2R2 est l'illustration parfaite. L'audit initial de 15 jours a révélé des ressources surdimensionnées et des services inutilisés, résultant en une économie de 19% sur la facture cloud. Ensuite, j'ai construit l'architecture cible avec 25 modules Terraform : VPC avec subnets publics/privés, EKS Fargate (pas de noeuds à gérer), Aurora PostgreSQL multi-AZ, WAF pour la protection applicative, GuardDuty pour la détection d'intrusions, CloudTrail pour l'audit. Chaque module avait ses variables, ses outputs, et ses tests. L'ensemble était orchestré par un module racine Terragrunt qui gérait les dépendances entre modules.
Les erreurs qui coûtent cher
La plus coûteuse que j'ai vue : un terraform destroy lancé par accident sur l'environnement de production. Depuis, j'applique systématiquement le prevent_destroy lifecycle sur les ressources critiques (bases de données, buckets S3 avec données). Autre erreur classique : ne pas verrouiller le state Terraform. Sans verrouillage DynamoDB (sur AWS), deux terraform apply simultanés peuvent corrompre l'état. Côté Ansible, le piège classique est de ne pas tester les playbooks avec --check avant de les exécuter. Chez Bloomflow, chaque playbook Ansible passait par un dry-run en CI avant exécution réelle.
Conclusion
Terraform et Ansible sont des outils matures et complémentaires pour automatiser les déploiements cloud. Le secret de la réussite : modularité, tests, et intégration CI/CD. Ces outils m'ont permis de livrer des architectures complexes sur AWS, GCP, OVH et Scaleway en quelques semaines au lieu de mois.