L'Art de l'Automatisation: Ansible et Terraform en Action
Introduction
Ansible et Terraform sont deux outils que j'ai utilisés intensivement, souvent ensemble. Terraform pour le provisionnement cloud, Ansible pour la configuration des machines. Chez Epiconcept, Ansible était l'outil principal pendant 4 ans pour gérer toute l'infrastructure. Chez F2R2, Terraform a pris le lead. Voici mon retour d'expérience sur la complémentarité de ces deux outils.
Ansible : 4 ans chez Epiconcept
Chez Epiconcept, j'ai géré l'infrastructure de projets pour l'INSERM et les Armées avec Ansible pendant 4 ans. Les playbooks Ansible configuraient les serveurs de bout en bout : installation de Docker, configuration de MariaDB avec réplication, déploiement des applications via GitHub Actions qui déclenchait Ansible, configuration du monitoring Prometheus/Node Exporter, et hardening sécurité (fail2ban, iptables, SSH hardening). L'inventaire Ansible était dynamique, généré depuis l'API du provider cloud. Au total, environ 40 rôles Ansible maintenus et 200 serveurs gérés. La force d'Ansible : son idempotence (on peut relancer un playbook sans risque) et sa simplicité (SSH + YAML, pas d'agent à installer).
Terraform : l'architecture AWS multi-comptes chez F2R2
Chez F2R2, Terraform a été l'outil central pour construire une architecture AWS complète de zéro. 25 modules Terraform organisés en couches : réseau (VPC, subnets, NAT gateways), compute (EKS Fargate, Fargate profiles), données (Aurora PostgreSQL, ElastiCache), sécurité (WAF, GuardDuty, Security Hub, IAM), et observabilité (CloudWatch, prometheus-stack). L'audit initial de 15 jours avait identifié des ressources manuelles sur la console AWS qui coûtaient 19% de trop. Tout a été codé dans Terraform, optimisé, et déployé via GitHub Actions. Le résultat : une infrastructure 100% reproductible, documentée par le code, et optimisée en coûts.
La complémentarité en pratique
Sur mes projets récents, la répartition est claire. Terraform gère les ressources cloud (VPC, clusters K8s, bases de données, DNS, certificats, IAM) et Ansible gère la configuration des machines non-Kubernetes (bastions, runners CI, serveurs legacy). Chez Metronome, Terraform provisionnait le cluster OVH Kubernetes et les buckets S3, tandis qu'Ansible configurait les runners Gitlab CI et le bastion SSH. Chez Bloomflow, avec l'adoption massive de Kubernetes, Ansible n'était plus utilisé que pour les quelques VMs restantes (monitoring central, backup). La tendance est claire : plus l'infrastructure est containerisée, moins Ansible est nécessaire.
Les erreurs courantes et comment les éviter
La première erreur est d'utiliser Ansible pour provisionner des ressources cloud. C'est techniquement possible (module amazon.aws), mais Ansible ne gère pas le state comme Terraform. Si vous supprimez une tâche Ansible, la ressource n'est pas détruite. Terraform détruit ce qui n'est plus dans le code. La deuxième erreur est de stocker l'inventaire Ansible dans le code sans le chiffrer. Chez Epiconcept, j'utilisais ansible-vault pour chiffrer les variables sensibles et les inventaires contenant des IPs privées. La troisième erreur est de ne pas versionner les rôles Ansible avec des versions spécifiques. Un requirements.yml sans version fixe peut casser un playbook du jour au lendemain si un rôle Galaxy est mis à jour.
L'avenir : Terraform prend l'avantage
La tendance que j'observe sur le marché est un glissement vers Terraform au détriment d'Ansible. Avec Kubernetes, la configuration des applications se fait via des manifestes YAML dans le cluster, pas via SSH sur des machines. Les Helm charts remplacent les rôles Ansible pour la gestion des applications. Terraform couvre de plus en plus de cas d'usage via ses providers (provider Helm, provider Kubernetes, provider Datadog). Chez mes clients récents, Ansible est de moins en moins présent. Mais il reste indispensable pour les environnements legacy (serveurs bare-metal, VMs non-containerisées) et pour les configurations post-provisionnement complexes (hardening de kernel, configuration réseau avancée).
Conclusion
Ansible et Terraform ne sont pas concurrents mais complémentaires. Terraform pour créer et gérer les ressources cloud, Ansible pour configurer les machines. La part de chacun dépend de votre degré de containerisation : 100% Kubernetes signifie quasiment 100% Terraform, tandis qu'un environnement mixte VM/containers nécessite les deux. Mon conseil : maîtrisez Terraform en priorité (c'est l'avenir), gardez Ansible dans votre boîte à outils pour les cas où la configuration SSH est nécessaire.