Vous découvrez Ansible et vous vous demandez pourquoi tout le monde parle aussi de Terraform, Puppet, Chef, Salt — et lequel choisir. La bonne nouvelle : ces outils ne sont pas concurrents, ils répondent à des besoins distincts. La mauvaise : la presse technique les mélange souvent, et un mauvais choix initial coûte cher en réécriture. Cette page vous donne un tableau de décision clair pour situer Ansible et choisir le bon outil par cas d’usage.
Analogie : si on construit une maison, Terraform est l’architecte qui pose les fondations et la structure (l’infrastructure : VMs, réseaux, disques). Ansible est l’électricien-plombier qui équipe les pièces (configuration : paquets, services, fichiers, utilisateurs). Puppet est l’inspecteur permanent qui repasse vérifier que tout reste conforme (agent permanent, drift correction). Vous avez besoin des trois rôles, mais à des moments différents — pas du même outil pour tout.
Recommandation rapide
Section intitulée « Recommandation rapide »Avant le détail technique, voici la décision en une ligne par cas typique. Lisez la colonne « Si vous voulez » et l’outil de la colonne « Choisissez » est votre point de départ.
| Si vous voulez… | Choisissez | Pourquoi |
|---|---|---|
| Créer une infra cloud (EC2, Azure VM, OVH bare-metal) | Terraform | State + plan + dépendances entre ressources |
| Configurer des serveurs déjà créés (paquets, services, secrets) | Ansible | Push SSH, agentless, déclaratif |
| Préparer la certification RHCE | Ansible | Seule certification Red Hat sur ce périmètre |
| Maintenir une fleet 1000+ serveurs avec correction continue | Puppet ou Salt | Modèle pull avec agent permanent et drift correction |
| Automatiser un homelab / projet perso | Ansible | Courbe d’apprentissage la plus douce |
| Débuter en IaC sans rien casser | Terraform ou Ansible | Les deux ont une excellente documentation francophone |
La conclusion pratique : pour 80 % des sysadmins Linux français qui démarrent en 2026, Terraform + Ansible forment le couple gagnant — Terraform crée l’infrastructure, Ansible la configure. Puppet, Chef, Salt sont d’excellents outils mais leur écosystème entreprise et leur courbe d’apprentissage les rendent moins accessibles en première approche.
Critères de comparaison
Section intitulée « Critères de comparaison »Quatre dimensions structurent la comparaison. Comprendre ces dimensions vous évite de comparer deux outils sur le mauvais critère et d’arriver à une mauvaise conclusion.
Le paradigme distingue le déclaratif (« je veux cet état ») de l’impératif (« fais ces actions dans cet ordre »). Terraform, Ansible, Puppet, Chef et Salt sont tous déclaratifs en sortie, mais leur ressenti côté écriture varie. Le code Ansible ressemble à de l’impératif (une suite de tâches), alors que le code Terraform est franchement déclaratif (une description de ressources). Voir le détail dans Déclaratif vs impératif.
Le mode de communication distingue le push (le control node se connecte aux cibles à la demande) du pull (un agent permanent sur la cible contacte le master à intervalle régulier). Ansible est purement push. Puppet et Chef sont purement pull. Salt fait les deux. Le push est plus simple à démarrer, le pull est plus adapté aux fleets de 10 000+ serveurs où le master ne peut pas joindre toutes les cibles en parallèle.
L’agent est le programme qui tourne sur la cible. Ansible n’en a pas (juste sshd + Python). Puppet, Chef ont un agent à installer et maintenir partout. Cette différence a un coût opérationnel : l’agent doit être déployé, mis à jour, surveillé, et chiffrer ses échanges avec le master via une PKI. C’est un cost-center sur 1000 serveurs ; c’est de l’overhead pour 50.
L’état (state) est la connaissance que l’outil garde de l’infrastructure. Terraform maintient un fichier terraform.tfstate qui mappe ce qui devrait exister à ce qui existe réellement — c’est ce qui permet terraform plan de calculer le diff. Ansible ne maintient aucun état ; il vérifie tout à chaque run. Puppet maintient un catalog compilé par le master. Chacune de ces approches a ses forces : le state Terraform donne du plan précis ; l’absence de state d’Ansible évite les corruptions de fichier ; le catalog Puppet permet l’audit centralisé.
Comparatif détaillé
Section intitulée « Comparatif détaillé »Le tableau ci-dessous compare les six outils les plus pertinents en 2026 sur huit dimensions techniques. Lisez les colonnes : à gauche le critère, à droite la valeur pour chaque outil. Les cellules en gras sont les points forts marquants.
| Critère | Ansible | Terraform | Puppet | Chef | Salt | PyInfra |
|---|---|---|---|---|---|---|
| Périmètre principal | Configuration | Provisioning | Configuration | Configuration | Config + provisioning | Configuration |
| Paradigme | Déclaratif (procédural en surface) | Déclaratif pur | Déclaratif | Impératif (Ruby DSL) | Déclaratif | Déclaratif |
| Mode | Push (SSH) | API providers | Pull (agent) | Pull (agent) | Push ou pull | Push (SSH) |
| Agent côté cible | Aucun | N/A | Oui (puppet-agent) | Oui (chef-client) | Oui (minion) | Aucun |
| Langage | YAML + Jinja2 | HCL | Puppet DSL | Ruby DSL | YAML + Python | Python |
| Idempotence | Portée par les modules | Native | Native | Native | Native | Native |
| État (state) | Aucun | terraform.tfstate | Catalog côté master | Cookbook côté server | Pillar côté master | Aucun |
| Communauté | Très large (Galaxy) | Très large (Registry) | Mature, en érosion | En érosion | Active mais niche | Petite, croissance |
| Certification éditeur | RHCE EX294 | Associate, Professional | Pas active 2026 | Discontinuée | Aucune | Aucune |
| Langue ressources FR | Excellent | Excellent | Modéré | Limité | Limité | Limité |
| Force principale | Agentless, simple | State, plan, multi-cloud | Drift correction continue | Flexibilité Ruby | Performance fleet 10k+ | Vrai code Python |
| Faiblesse principale | Performance >1000 nœuds | Pas de config OS | Agent à maintenir | Adoption en baisse | Communauté niche | Écosystème limité |
La conclusion qui ressort de ce tableau : Ansible et Terraform dominent l’usage en 2026 grâce à leur courbe d’apprentissage douce, leur communauté large et leurs ressources francophones abondantes. Puppet, Chef, Salt restent excellents techniquement mais leur écosystème entreprise les rend moins accessibles aux sysadmins individuels et aux équipes en démarrage.
Quel outil pour quel cas concret
Section intitulée « Quel outil pour quel cas concret »Vous voilà avec le panorama théorique. Passons aux scénarios concrets que vous rencontrerez. Pour chaque cas, l’outil principal est en gras, les outils complémentaires en italique.
« Je veux déployer une infra cloud (EC2, Azure VM, GCP, Outscale) avec mes premiers serveurs Ansible » : c’est le couple le plus standard. Vous utilisez Terraform pour provisionner les VMs, le réseau, les volumes, les groupes de sécurité. Une fois les VMs up, Terraform sort un fichier d’inventaire (output inventory.yml) que Ansible consomme pour configurer les OS, déployer les applications, gérer les secrets. Cette répartition est le pattern de référence chez tous les hébergeurs en 2026.
« Je dois durcir 50 serveurs RHEL selon ANSSI-BP-028 » : Ansible seul. Terraform n’est pas adapté (vous ne créez pas l’infra, juste vous la configurez). Vous écrivez un rôle anssi-bp-028 qui applique les paramètres sysctl, les permissions de fichiers, les profils SELinux, les règles firewalld. Ce rôle s’exécute en quelques minutes sur la fleet et reste idempotent — vous pouvez le rejouer mensuellement pour vérifier la conformité.
« Je veux une infra qui se reconfigure automatiquement si quelqu’un la modifie à la main » : c’est le terrain de Puppet. L’agent permanent contacte le master toutes les 30 minutes par défaut, télécharge le catalog, et réapplique l’état désiré en corrigeant toute dérive. C’est plus rigide qu’Ansible mais plus protecteur. Chef offre la même mécanique pull avec un DSL Ruby plutôt que le DSL Puppet. Salt couvre aussi ce besoin avec un compromis push/pull différent.
« J’automatise mon homelab Proxmox / KVM » : Ansible est le bon point de départ. Vous définissez un inventaire dynamique (plugin community.general.proxmox), vous écrivez quelques playbooks pour vos VMs (Pi-hole, NextCloud, Vault), et vous les rejouez à chaque besoin. Ajouter Terraform plus tard si vous voulez automatiser la création des VMs (cf. notre lab kubeadm-kvm qui utilise ce pattern).
« Je veux préparer une certification reconnue pour valider mes compétences » : RHCE EX294 côté Ansible, Terraform Associate 003 ou Terraform Professional côté HashiCorp. Puppet a eu des certifications mais leur statut 2026 est flou. Chef ne propose plus de certification active. Pour un sysadmin Linux qui veut une preuve officielle reconnue par les employeurs francophones, RHCE est l’investissement le plus rentable en 2026.
Combiner Ansible et Terraform : le pattern qui marche
Section intitulée « Combiner Ansible et Terraform : le pattern qui marche »Ce n’est pas une dichotomie. La combinaison Terraform + Ansible est tellement courante qu’il y a même un module Terraform qui invoque Ansible (ansible.terraform.local-exec). Le pattern fonctionne en trois étapes.
D’abord, Terraform crée l’infrastructure : VMs, réseau, disques, DNS, certificats. Le state Terraform mémorise quelles ressources existent et leurs IDs cloud. Vous obtenez en sortie une liste de hosts avec leurs IPs et leurs labels (« web1.lab », « db1.lab »).
Ensuite, Terraform produit un inventaire Ansible via un fichier de template ou un plugin d’inventaire dynamique. C’est typiquement un inventory.yml qui liste les groupes (webservers, dbservers) avec les IPs Terraform.
Enfin, Ansible consomme cet inventaire pour configurer les VMs : installation paquets, hardening OS, déploiement applicatif. Les rôles Ansible ne savent même pas que les VMs viennent de Terraform — ils ne voient qu’un inventaire standard.
Cette répartition vous évite la tentation d’utiliser le mauvais outil. Vous ne créez pas une VM avec Ansible (le module community.libvirt.virt existe mais c’est anti-pattern : pas de plan, pas de state, pas de gestion fine des dépendances). Vous ne configurez pas un OS avec Terraform (le provisioner existe mais HashiCorp recommande explicitement de ne pas s’en servir).
À retenir
Section intitulée « À retenir »- Ansible = configuration, push SSH, agentless, déclaratif. Brille sur 10 à 1000 serveurs.
- Terraform = provisionnement, API providers, state. Indispensable pour créer de l’infrastructure cloud.
- Puppet / Chef / Salt = configuration avec agent et drift correction. Excellents techniquement, écosystème en érosion 2026.
- PyInfra = équivalent Ansible en Python pur. Niche mais croissance.
- Le couple Terraform + Ansible est le pattern le plus courant en 2026. Terraform crée, Ansible configure.
- Côté certification reconnue : RHCE EX294 (Ansible), Terraform Associate / Professional (HashiCorp). Les autres outils n’ont plus de programme actif majeur.