Maximiser l'efficacité DevOps avec Ansible et Terraform
Introduction
Ansible et Terraform sont deux outils que j'utilise depuis le début de ma carrière DevOps, mais pour des usages fondamentalement différents. Ansible gère la configuration de ce qui existe, Terraform crée et détruit ce qui doit exister. En 15 ans, j'ai vu la frontière entre les deux évoluer avec l'adoption de Kubernetes et du cloud managé. Comprendre quand utiliser l'un, l'autre, ou les deux ensemble, c'est la clé pour maximiser l'efficacité sans créer de complexité inutile. Voici le retour d'expérience honnête de leurs forces respectives et de leur complémentarité.
Ansible chez Epiconcept : 200+ serveurs, 4 ans, 0 dérive
Ma plus longue mission avec Ansible : 4 ans chez Epiconcept, au service de l'INSERM et des Armées. Ansible gérait plus de 200 serveurs -- des serveurs physiques, des VM sur plusieurs hyperviseurs, des environnements variés. L'inventaire dynamique était organisé par rôle (web, database, worker, monitoring) et par environnement (production, staging, développement). Des dizaines de rôles Ansible couvraient l'intégralité de la configuration : la stack LAMP (Apache, PHP-FPM, MariaDB), les certificats TLS via Let's Encrypt, le monitoring Nagios, les backups automatisés vers un stockage distant, et le hardening sécurité (SSH, fail2ban, firewall, mises à jour de sécurité automatiques).
L'idempotence d'Ansible -- sa capacité à appliquer un état désiré sans effets de bord si l'état est déjà atteint -- était la garantie fondamentale. Un ansible-playbook site.yml hebdomadaire en cron détectait et corrigeait automatiquement les dérives de configuration : un fichier modifié manuellement, un package manquant, un service qui ne démarre pas au boot. En 4 ans, zéro dérive non détectée. La force d'Ansible dans ce contexte : sa simplicité (YAML lisible par tout le monde, connexion SSH, pas d'agent à installer sur les serveurs) et sa fiabilité éprouvée sur des centaines de serveurs.
Terraform chez F2R2 : l'IaC à grande échelle sur AWS
Chez F2R2, le contexte était radicalement différent : pas de serveurs à configurer, mais une infrastructure cloud AWS complète à provisionner de zéro. Terraform gérait l'intégralité des ressources AWS : VPC avec subnets publics/privés multi-AZ, NAT Gateway, EKS Fargate (cluster Kubernetes serverless), Aurora PostgreSQL multi-AZ, buckets S3 avec lifecycle policies et chiffrement, distributions CloudFront avec WAF, GuardDuty pour la détection de menaces, CloudTrail pour l'audit trail, et les IAM roles/policies avec le principe du moindre privilège.
25 modules Terraform, chacun autonome et versionné dans un registry privé. Trois environnements (dev, staging, prod) instanciaient les mêmes modules avec des variables différentes (taille des instances, nombre de replicas, budget d'alerte). Un nouvel environnement complet en 45 minutes au lieu de 3 jours de ClickOps en console. Le state dans S3 avec DynamoDB locking. L'intégration dans GitHub Actions : terraform plan sur chaque PR avec le plan posté en commentaire pour review, terraform apply après merge et approbation. La force de Terraform ici : le plan prévisible avant apply, la gestion complète du cycle de vie (create, update, destroy), et la portabilité multi-cloud.
La complémentarité en pratique : quand les deux cohabitent
Chez Bloomflow, pendant mes 5 ans en CDI, j'ai utilisé les deux outils ensemble dans une architecture hybride. Terraform créait les instances EC2, les target groups ALB, les security groups et les bases de données RDS. Un provisioner local-exec dans la configuration Terraform déclenchait Ansible post-création pour configurer les instances : installation de Docker Engine, configuration du daemon Docker (log rotation, cgroup driver), montage des volumes EBS, configuration du monitoring agent, et enregistrement dans le cluster Docker Swarm (avant la migration vers Kubernetes).
Quand Kubernetes a remplacé Docker Swarm chez Bloomflow, le rôle d'Ansible a naturellement reculé. Les containers n'ont pas besoin de configuration système -- le Dockerfile et les Helm values décrivent tout. Mais Ansible restait utile pour des tâches spécifiques : provisionnement et hardening des bastions SSH (les points d'entrée vers le cluster), rotation des certificats sur les services legacy non-containerisés, mise à jour des agents CloudWatch sur les instances EC2 de monitoring, et exécution de scripts one-shot de migration de données. L'évolution naturelle est claire : plus on containerise et plus on adopte le cloud managé, plus Terraform gagne en importance et Ansible se spécialise sur des tâches ciblées.
Le guide de décision : choisir le bon outil pour le bon contexte
Mon guide de décision, affiné sur 15 ans et validé chez chaque client :
Si vous provisionnez de l'infrastructure cloud (VM, réseau, clusters K8s, bases de données managées, CDN, DNS, IAM) : Terraform. C'est son domaine naturel, et aucun autre outil ne fait mieux le plan/apply/destroy avec gestion de state.
Si vous configurez des serveurs existants (packages, fichiers de configuration, services systemd, utilisateurs, clés SSH) : Ansible. Sa simplicité YAML + SSH, l'absence d'agent, et son idempotence en font l'outil idéal pour la gestion de configuration.
Si vous faites du Kubernetes natif : Terraform pour le cluster et les dépendances cloud, Helm/ArgoCD pour les workloads applicatifs. Ansible devient optionnel, limité aux bastions et aux tâches legacy. Chez KNDS, le cluster OVH Kubernetes était provisionné par Terraform, les workloads déployés par ArgoCD, et Ansible ne servait qu'à configurer les jump hosts d'accès au cluster. Chez Epiconcept, sans Kubernetes, Ansible restait l'outil central pour tout. Le contexte dicte le choix, pas la mode.
L'erreur classique : utiliser le mauvais outil
L'erreur que je vois le plus souvent chez mes nouveaux clients : utiliser Ansible pour provisionner de l'infrastructure cloud (créer des VM, des réseaux, des load balancers). Ansible peut le faire via ses modules cloud, mais il le fait mal : pas de state management (Ansible ne sait pas qu'il a créé une VM la semaine dernière), pas de plan prévisible (pas de ansible plan), et pas de gestion du cycle de vie (comment détruire proprement ?). Chez un client avant ma mission F2R2, l'infra AWS était gérée avec des playbooks Ansible qui appelaient les modules ec2_instance, ec2_vpc, rds_instance. Le résultat : des ressources orphelines impossibles à tracker, des conflits quand deux personnes lançaient le playbook en même temps, et aucune visibilité sur l'état réel de l'infrastructure.
L'erreur inverse existe aussi : utiliser Terraform pour configurer des serveurs (installer des packages, écrire des fichiers de configuration). Les provisioners Terraform (remote-exec, file) sont limités, non-idempotents, et déconseillés par HashiCorp eux-mêmes dans la documentation officielle. Chaque outil dans son domaine d'excellence, c'est la règle d'or.
Conclusion
Ansible et Terraform ne sont pas concurrents, ils sont complémentaires. Ansible excelle dans la configuration de systèmes existants (200+ serveurs chez Epiconcept pendant 4 ans), Terraform dans le provisionnement d'infrastructure cloud (25 modules AWS chez F2R2). Ensemble, ils couvrent l'intégralité du cycle de vie d'une infrastructure. Avec l'adoption croissante de Kubernetes et du cloud managé, la frontière évolue : Terraform prend le relais d'Ansible pour de plus en plus de tâches. La clé reste de choisir le bon outil pour le bon usage, et cette complémentarité est au coeur de l'offre WizOps.