« Terraform ou Ansible ? » revient souvent comme une question de choix, alors que les deux outils répondent à des questions différentes : Terraform décide quelles ressources existent, Ansible décide comment ce qui existe est configuré. La confusion vient d’un chevauchement réel mais partiel, pas d’une vraie concurrence.

Ce que chacun décrit

Terraform, outil déclaratif d’infrastructure as code, décrit un état cible de ressources (serveurs, réseaux, bases de données managées) et calcule les opérations pour l’atteindre depuis l’état actuel. Ansible décrit des étapes à exécuter sur des machines déjà existantes : installer un paquet, copier un fichier de configuration, redémarrer un service. La différence n’est pas de degré, elle est de nature : Terraform répond à « quoi doit exister », Ansible répond à « comment ce qui existe doit être configuré ».

# Terraform : la machine doit exister, avec ce type
# et cette image, rien de plus
resource "aws_instance" "web" {
  ami           = "ami-12345"
  instance_type = "t3.medium"
}
# Ansible : une fois la machine là, ces paquets et
# cette configuration doivent être appliqués
- name: Install nginx
  apt:
    name: nginx
    state: present

Le chevauchement qui crée la confusion

Les deux outils peuvent techniquement provisionner une machine cloud (Ansible a des modules cloud), et Terraform peut techniquement exécuter des scripts de configuration via provisioner "remote-exec". Ce chevauchement fonctionnel entretient l’illusion d’un vrai choix à trancher, alors que chaque usage hors de son domaine naturel est généralement déconseillé par la documentation même des deux outils : les provisioners Terraform sont un dernier recours documenté comme tel, pas un pattern à adopter par défaut.

# Techniquement possible, déconseillé par Terraform
# lui-même : ce n'est pas son métier
provisioner "remote-exec" {
  inline = ["apt-get install -y nginx"]
}

Le pattern qui les combine, le plus courant en pratique

L’usage le plus répandu ne choisit pas entre les deux, il les enchaîne : Terraform provisionne les machines et publie leurs adresses IP en sortie, Ansible consomme cette sortie comme inventaire dynamique pour configurer les machines fraîchement créées. Chaque outil reste sur son terrain naturel, la frontière entre les deux est le moment précis où la machine existe mais n’est pas encore configurée.

# La sortie Terraform devient l'inventaire Ansible,
# la frontière entre "provisionner" et "configurer"
terraform output -json instance_ips > inventory.json
ansible-playbook -i inventory.json site.yml

Là où Kubernetes change la question

Sur un cluster Kubernetes, la question se pose différemment : Terraform provisionne le cluster lui-même (nœuds, réseau), mais la configuration de ce qui tourne dessus passe généralement par des manifests Kubernetes ou des Helm charts, pas par Ansible. Ansible garde sa pertinence pour ce qui reste en dehors du cluster : configuration système des nœuds eux-mêmes, bootstrap avant qu’un nœud ne rejoigne le cluster, ou gestion d’une infrastructure hybride qui mélange VM classiques et Kubernetes.

À retenir

Terraform et Ansible ne sont pas des concurrents malgré la question fréquente : Terraform décide quelles ressources existent, Ansible décide comment ce qui existe est configuré, une distinction de nature, pas de degré. Le chevauchement fonctionnel existe mais reste marginal et déconseillé par les deux outils eux-mêmes hors de leur domaine naturel. Le pattern le plus courant les enchaîne plutôt que de choisir : Terraform provisionne, sa sortie alimente l’inventaire Ansible qui configure, une frontière nette qui structure la plupart des pipelines d’industrialisation CI/CD qui gèrent encore de l’infrastructure hors Kubernetes.