Vous cherchez une alternative à Ansible : parce qu'il rame sur un gros parc, parce que vos playbooks YAML sont devenus illisibles, ou parce que vous avez besoin d'une infrastructure qui réagit aux événements. Cette page compare les quatre alternatives sérieuses (Salt, Chef, Puppet, Rudder), donne un tableau de décision, et dit aussi quand rester sur Ansible reste le bon choix. Public visé : administrateurs et DevOps qui ont déjà pratiqué Ansible et se posent la question.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Identifier la vraie raison de chercher une alternative.
- Comparer Salt, Chef, Puppet et Rudder sur des critères objectifs.
- Choisir l'outil adapté à votre contexte.
- Savoir quand rester sur Ansible.
Recommandation rapide
Section intitulée « Recommandation rapide »Avant les détails, la réponse dans la plupart des cas :
| Votre situation | Ce que je conseille |
|---|---|
| Ansible « lent » sur quelques dizaines de serveurs | Restez sur Ansible, le problème est ailleurs (voir plus bas) |
| Des milliers de nœuds, exécution trop lente | Salt (bus permanent, quasi temps réel) |
| Vous voulez une infra réactive (auto-remédiation) | Salt (bus d'événements + Reactor) |
| Logique de configuration complexe, équipe de développeurs | Chef (Ruby, vrai langage) |
| Grand parc hétérogène, besoin de reporting et de dérive | Puppet |
| Conformité réglementaire, audit, interface web | Rudder |
| Vous voulez provisionner des VM, pas les configurer | Ce n'est pas le même métier : Terraform |
En clair : dans la majorité des cas, Ansible reste le bon outil et le problème vient de son usage, pas de l'outil. Les alternatives se justifient sur des besoins précis : l'échelle, la réactivité, ou la conformité.
D'abord : votre problème est-il vraiment Ansible ?
Section intitulée « D'abord : votre problème est-il vraiment Ansible ? »Avant de migrer un parc entier, vérifiez que vous ne vous trompez pas de coupable. Trois symptômes attribués à Ansible viennent presque toujours d'ailleurs.
« Ansible est lent. » Sur un parc modeste, la lenteur vient rarement de l'outil
mais du nombre de tâches, des gather_facts systématiques, du forks laissé
à 5 par défaut, ou de modules qui appellent des commandes shell coûteuses. Un
forks: 50, la désactivation des facts inutiles et le pipelining SSH
divisent souvent le temps par cinq, sans changer d'outil.
« Nos playbooks sont illisibles. » Le YAML n'est pas en cause : un playbook de 800 lignes sans rôles, sans variables structurées et sans découpage serait illisible dans n'importe quel langage. Le problème est architectural, et il vous suivra chez le concurrent.
« On voudrait de l'auto-remédiation. » Là, en revanche, c'est une vraie limite : Ansible est un outil de push ponctuel, il n'observe rien en continu. Aucun réglage ne comblera ce manque.
Les critères qui comptent vraiment
Section intitulée « Les critères qui comptent vraiment »Les comparatifs listent souvent vingt lignes de fonctionnalités. En pratique, cinq critères décident du choix.
Agent ou sans agent. Ansible est agentless : rien à installer sur les cibles, il pousse par SSH. C'est sa force (adoption immédiate) et sa limite (chaque tâche rouvre une connexion). Un outil à agent (Chef, Puppet, Salt en master/minion) garde un processus qui écoute : plus rapide à l'échelle, mais un agent à déployer et maintenir.
Le modèle d'exécution : push ou pull. Ansible pousse quand vous le lancez. Puppet et Chef fonctionnent en pull : l'agent réveille tout seul et se réaligne, ce qui corrige la dérive sans intervention. Salt sait faire les deux.
La réactivité. Un outil peut-il réagir seul à un événement (service tombé, fichier modifié) ? Seul Salt le propose nativement, avec son bus d'événements et son Reactor. C'est sa vraie signature, et le seul argument qui rend une migration depuis Ansible vraiment décisive.
Le langage. YAML (Ansible, Salt), Ruby (Chef), DSL déclaratif (Puppet), interface web (Rudder). Un vrai langage donne de la puissance et coûte en accessibilité : vos administrateurs système devront devenir un peu développeurs.
L'écosystème et le marché. Ansible domine largement les offres d'emploi et la documentation disponible. Choisir une alternative, c'est accepter une communauté plus étroite et un recrutement plus difficile. Ce coût est réel et il faut le mettre dans la balance.
Salt : l'alternative pour l'échelle et la réactivité
Section intitulée « Salt : l'alternative pour l'échelle et la réactivité »Salt (anciennement SaltStack) est l'alternative la plus proche d'Ansible dans l'esprit : même YAML, même approche déclarative et idempotente. La différence est architecturale.
En mode master/minion, un agent écoute en permanence sur un bus de messages.
Une commande atteint des milliers de serveurs en quelques secondes, là où
Ansible ouvrirait autant de connexions SSH. Salt garde d'ailleurs un mode sans
agent (Salt SSH) pour les machines où l'on ne peut rien installer, mais il
paie alors le même prix : sur notre lab, un simple test.ping prend 5 secondes
en agentless contre 0,49 seconde avec un minion.
Sa vraie signature reste le bus d'événements : les minions publient ce qui leur arrive, et le Reactor transforme un événement en action. Un service qui tombe peut être relevé automatiquement en moins d'une seconde, sans supervision externe. Aucun autre outil de cette liste ne le fait nativement.
Le revers : un écosystème plus étroit, et un avenir qui interroge depuis le rachat de VMware par Broadcom. Le projet reste open source (Apache 2.0), la série 3008 est active, mais c'est un pari de niche assumé, pas la valeur par défaut du marché.
Chef : la puissance d'un vrai langage
Section intitulée « Chef : la puissance d'un vrai langage »Chef décrit la configuration en Ruby. Là où Ansible vous fait contourner les limites du YAML à coups de filtres Jinja alambiqués, Chef vous laisse écrire de la vraie logique : conditions, boucles, abstractions, ressources personnalisées.
C'est l'outil des équipes qui ont une logique de configuration complexe et des gens à l'aise avec la programmation. Ses Policyfiles verrouillent les versions de cookbooks de façon reproductible, et son écosystème de tests (ChefSpec, InSpec) est le plus mature de tous.
Le prix à payer est la courbe d'apprentissage : vos administrateurs doivent apprendre Ruby, et un cookbook mal écrit devient vite un programme à déboguer. La distribution libre CINC permet aujourd'hui d'utiliser Chef sans licence commerciale, ce qui lève le principal frein historique.
Puppet : la référence du grand parc géré en dérive
Section intitulée « Puppet : la référence du grand parc géré en dérive »Puppet est le vétéran du modèle agent-serveur en pull. L'agent se réveille périodiquement, compare l'état réel à l'état voulu et corrige la dérive, sans que personne ne lance quoi que ce soit.
C'est ce qui en fait un bon choix pour les grands parcs hétérogènes que l'on veut maintenir alignés dans la durée, avec un reporting solide sur ce qui a changé et ce qui a divergé. Son DSL déclaratif est plus rigoureux que le YAML, au prix d'une syntaxe de plus à apprendre.
Le modèle pull permanent est aussi sa contrainte : vous perdez le contrôle explicite du « je déploie maintenant » qu'offre Ansible, ce qui déroute les équipes habituées au push.
Rudder : quand la conformité prime
Section intitulée « Rudder : quand la conformité prime »Rudder joue dans une autre catégorie : c'est un outil français qui combine gestion de configuration et contrôle de conformité continu, avec une interface web et des rapports détaillés.
Son argument n'est pas la puissance d'expression, mais la preuve. Si vous devez démontrer à un auditeur que 400 serveurs respectent un référentiel (CIS, ANSSI), Rudder produit ce rapport nativement, là où il faudrait le construire vous-même avec les autres. Il gère aussi les CVE et les campagnes de correctifs.
C'est le choix des organisations soumises à des normes strictes, et son interface le rend accessible à des équipes moins scriptantes.
Ce qui n'est pas une alternative à Ansible
Section intitulée « Ce qui n'est pas une alternative à Ansible »Trois outils reviennent constamment dans les listes d'« alternatives » alors qu'ils ne font pas le même métier. La confusion coûte cher.
Terraform provisionne l'infrastructure (créer une VM, un réseau, un bucket). Ansible configure ce qui tourne dedans. Les deux sont complémentaires, pas concurrents : on crée la machine avec Terraform, on la configure ensuite.
Les conteneurs ne remplacent pas la gestion de configuration, ils déplacent
le problème : l'image est construite une fois, et c'est le Dockerfile qui devient
votre configuration. Sur un parc de VM, la question reste entière.
Les scripts shell ne sont pas une alternative : ils ne sont pas idempotents, ne décrivent aucun état, et laissent la dérive s'installer. C'est précisément ce que ces outils sont venus corriger.
Quel outil pour quel cas
Section intitulée « Quel outil pour quel cas »Résumons par le besoin, pas par l'outil :
| Votre besoin réel | L'outil |
|---|---|
| Piloter des milliers de nœuds en quasi temps réel | Salt |
| Une infra qui se répare seule (auto-remédiation) | Salt |
| Une logique complexe, une équipe de développeurs | Chef |
| Maintenir un grand parc aligné, corriger la dérive en continu | Puppet |
| Prouver une conformité à un auditeur | Rudder |
| Créer l'infrastructure (VM, réseau, cloud) | Terraform |
| Tout le reste | Ansible |
À retenir
Section intitulée « À retenir »- Dans la majorité des cas, le problème n'est pas Ansible mais son usage :
forks, facts inutiles, absence de rôles. - Une migration ne se justifie que par un besoin qu'Ansible ne couvre pas par conception : échelle, réactivité, ou conformité.
- Salt est l'alternative pour l'échelle et la réactivité (bus d'événements, Reactor), au prix d'un écosystème plus étroit.
- Chef apporte un vrai langage (Ruby) pour les logiques complexes, avec une courbe d'apprentissage réelle.
- Puppet excelle sur le grand parc en pull, corrigeant la dérive en continu.
- Rudder répond à la conformité et à l'audit, avec interface et rapports.
- Terraform, les conteneurs et les scripts ne sont pas des alternatives : ils font autre chose.