Terraform et Ansible ne répondent pas exactement au même problème. Dans la plupart des cas, Terraform sert d’abord à créer et faire évoluer des ressources via des APIs, alors qu’Ansible sert d’abord à configurer et maintenir ce qui tourne dessus. Les opposer comme si l’un devait remplacer l’autre produit surtout de mauvais cadrages : playbooks qui tentent de devenir un inventaire complet d’infrastructure, ou code Terraform surchargé avec des tâches fines d’administration système.
Le bon réflexe consiste à poser une frontière simple. Si votre question est “quelles ressources doivent exister ?”, vous êtes le plus souvent dans le terrain naturel de Terraform. Si votre question est “comment cette machine ou cette application doit-elle être configurée ?”, vous êtes généralement dans le terrain naturel d’Ansible.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- distinguer clairement le rôle principal de Terraform et celui d’Ansible ;
- comprendre dans quels cas les deux outils se complètent ;
- éviter les erreurs de cadrage qui créent vite de la dette technique.
Un exemple concret de découpage
Section intitulée « Un exemple concret de découpage »Imaginez que vous deviez ouvrir un nouvel environnement pour une application web.
Avec un partage sain des rôles :
- Terraform crée le réseau, la VM, le stockage et éventuellement le DNS ou le load balancer.
- Ansible installe le serveur web, déploie les fichiers de configuration, crée les utilisateurs techniques et démarre les services.
- L’équipe sait ensuite quel outil relancer selon le type d’écart observé.
Cet exemple paraît simple, mais il résume bien la frontière utile : Terraform pilote surtout la topologie et les ressources. Ansible pilote surtout le contenu et le comportement des systèmes.
Le partage le plus lisible tient souvent dans ce schéma minimal :
Pourquoi ce faux duel revient si souvent
Section intitulée « Pourquoi ce faux duel revient si souvent »Dans la pratique, un même projet crée une machine, puis installe dessus des paquets, des fichiers, des services et des règles de sécurité. Comme ces étapes s’enchaînent, beaucoup d’équipes ont l’impression qu’un seul outil devrait tout faire.
Le problème est que les deux outils n’ont pas le même centre de gravité.
- Terraform raisonne autour d’une configuration déclarative, d’un plan, d’un state et d’un graphe de ressources.
- Ansible raisonne autour de playbooks, d’un inventaire, de modules orientés système et d’exécutions répétables sur des machines cibles.
Ils peuvent parfois recouvrir une partie des usages de l’autre, mais ce n’est pas là qu’ils sont les plus solides.
Recommandation rapide selon votre cas
Section intitulée « Recommandation rapide selon votre cas »| Votre besoin principal | Point de départ le plus naturel |
|---|---|
| Créer des réseaux, VM, buckets, bases ou services managés | Terraform |
| Installer des paquets, gérer des fichiers et des services | Ansible |
| Préparer une nouvelle plateforme puis configurer les hôtes | Terraform + Ansible |
| Corriger une dérive dans l’OS ou la configuration applicative | Ansible |
| Revoir un changement d’infrastructure avant exécution | Terraform |
Le rôle principal de Terraform
Section intitulée « Le rôle principal de Terraform »Terraform est particulièrement adapté quand vous devez décrire et faire évoluer des ressources d’infrastructure :
- machines virtuelles ;
- réseaux, subnets et règles réseau ;
- load balancers ;
- buckets et volumes ;
- bases managées ;
- objets SaaS ou cloud pilotés par API.
Son point fort est de comparer un état désiré à l’état réel connu via le provider et le state, puis de produire un plan expliquant ce qu’il créera, modifiera ou supprimera.
Exemple typique côté Terraform
Section intitulée « Exemple typique côté Terraform »Une équipe veut ajouter un nouveau sous-réseau, rattacher deux machines à ce sous-réseau et ajuster la règle d’un load balancer. Ce travail concerne des objets d’infrastructure durables, connus par des APIs et relus via un plan. C’est exactement le terrain où Terraform est à l’aise.
Le rôle principal d’Ansible
Section intitulée « Le rôle principal d’Ansible »Ansible est particulièrement adapté quand vous devez configurer et maintenir des systèmes :
- installer des paquets ;
- déposer des fichiers de configuration ;
- créer des utilisateurs et groupes ;
- gérer des services ;
- appliquer des règles de durcissement ;
- orchestrer des séquences d’administration sur un parc.
Sa force est de décrire un état attendu sur une machine au moyen de modules idempotents et de le rejouer facilement, souvent via SSH sans agent supplémentaire.
Exemple typique côté Ansible
Section intitulée « Exemple typique côté Ansible »Une fois la machine créée, il faut installer Nginx, poser un fichier de configuration, activer le service, créer un utilisateur applicatif et appliquer un durcissement de base. Ce type de besoin relève davantage d’Ansible, car il s’agit de piloter le système et les services à l’intérieur de la machine.
La frontière la plus utile
Section intitulée « La frontière la plus utile »| Question | Outil le plus naturel |
|---|---|
| Quelles ressources doivent exister ? | Terraform |
| Comment configurer l’OS ou l’application ? | Ansible |
| Comment préparer un réseau, une VM et un disque ? | Terraform |
| Comment installer Nginx, Docker ou PostgreSQL ? | Ansible |
| Comment appliquer une configuration répétable sur un parc ? | Ansible |
| Comment produire un plan lisible avant modification d’infrastructure ? | Terraform |
Cette frontière n’est pas morale. Elle sert à limiter les zones grises.
Là où Terraform s’arrête le plus souvent
Section intitulée « Là où Terraform s’arrête le plus souvent »Terraform sait très bien qu’une instance, un réseau ou un bucket existent, car ces objets sont pilotés via un provider et représentés dans le state. En revanche, il n’est pas naturellement fait pour suivre tout ce qui se passe à l’intérieur d’un système après sa création.
Par exemple, si un paquet est installé manuellement dans une VM ou si la configuration d’un service change à l’intérieur du système, ce n’est généralement pas le bon périmètre de Terraform. Ce type de dérive relève davantage d’un outil de configuration comme Ansible.
Autrement dit, Terraform sait très bien décrire qu’une machine existe avec certaines caractéristiques. Il n’est pas conçu pour devenir la vérité unique sur chaque détail de l’OS de cette machine.
Là où Ansible s’arrête le plus souvent
Section intitulée « Là où Ansible s’arrête le plus souvent »Ansible peut appeler des modules cloud et créer certaines ressources. Mais si vous lui demandez de devenir la source principale de vérité d’une infrastructure durable avec beaucoup de ressources, de dépendances et de plans de changement relus, vous lui demandez souvent de jouer contre son centre de gravité.
Le risque est alors de multiplier :
- des playbooks très procéduraux ;
- des responsabilités floues ;
- des reprises manuelles difficiles ;
- une lecture moins claire des changements de topologie.
En pratique, Ansible peut créer des ressources, mais ce n’est pas toujours là qu’il donne la meilleure lisibilité pour une infrastructure durable, surtout quand le nombre de ressources et de dépendances augmente.
Quand les deux se complètent bien
Section intitulée « Quand les deux se complètent bien »La combinaison la plus naturelle est souvent celle-ci :
- Terraform prépare les ressources.
- Ansible configure les machines ou les services.
Exemple typique : Terraform crée une VM, son réseau et son stockage. Ensuite, Ansible installe les paquets, déploie les fichiers, active les services et applique le durcissement attendu.
Ce découpage aide à savoir :
- quel dépôt détient la vérité sur la topologie ;
- quel dépôt détient la vérité sur la configuration système ;
- quel outil doit être relancé pour corriger quel type d’écart.
Ce que voit une équipe mature
Section intitulée « Ce que voit une équipe mature »Une équipe qui sépare bien les couches gagne en clarté pendant les revues.
- un changement Terraform annonce surtout une évolution de topologie ou de ressources ;
- un changement Ansible annonce surtout une évolution de configuration système ou applicative.
Cette lisibilité réduit beaucoup les malentendus pendant les validations.
Les erreurs de cadrage les plus fréquentes
Section intitulée « Les erreurs de cadrage les plus fréquentes »Transformer Terraform en outil d’administration système
Section intitulée « Transformer Terraform en outil d’administration système »Quand Terraform sert à piloter trop de tâches fines dans l’OS, le code devient plus fragile, plus difficile à rejouer proprement et moins clair sur sa responsabilité réelle.
Transformer Ansible en source unique de topologie durable
Section intitulée « Transformer Ansible en source unique de topologie durable »Quand Ansible devient le point principal de création et de suivi d’un grand ensemble de ressources durables, la lecture des changements et la séparation des responsabilités deviennent souvent plus difficiles.
Laisser les deux outils modifier le même périmètre sans frontière claire
Section intitulée « Laisser les deux outils modifier le même périmètre sans frontière claire »C’est la cause classique des incompréhensions sur la dérive, des effets de bord et des débats sans fin sur “l’outil qui a raison”.
Le critère le plus utile pour décider
Section intitulée « Le critère le plus utile pour décider »Quand vous hésitez, posez simplement cette question : voulez-vous surtout piloter une ressource ou un système ? Cette formulation fonctionne très bien pour les débutants, car elle évite de partir trop tôt dans les détails d’implémentation.
Comment décider vite
Section intitulée « Comment décider vite »Si vous hésitez encore, utilisez ce test simple.
- Si vous parlez d’API cloud, de réseaux, de volumes, de VMs, de clusters ou de ressources managées, commencez par Terraform.
- Si vous parlez de paquets, services, fichiers, utilisateurs, conformité ou durcissement, commencez par Ansible.
- Si les deux apparaissent, ne choisissez pas forcément un gagnant. Séparez les couches.
À retenir
Section intitulée « À retenir »- Terraform est le plus naturel pour créer et faire évoluer des ressources d’infrastructure.
- Ansible est le plus naturel pour configurer et maintenir des systèmes.
- Les deux outils se complètent mieux qu’ils ne se remplacent.
- Le vrai danger n’est pas d’utiliser les deux, mais de leur faire piloter le même périmètre sans frontière claire.
- Une bonne séparation réduit la dérive, clarifie les responsabilités et simplifie les relances.