Ansible vs Salt vs Puppet : Comparatif des Outils de Configuration Management

Introduction au Configuration Management

Le Configuration Management (gestion de configuration) est une discipline fondamentale du DevOps qui consiste à automatiser la mise en état, le maintien et le contrôle de l'infrastructure informatique. Plutôt que de configurer manuellement chaque serveur — un processus lent, sujet aux erreurs et impossible à reproduire de manière fiable — les outils de configuration management permettent de décrire l'état souhaité de l'infrastructure dans du code, puis d'appliquer cet état de manière automatique et répétable.

Les bénéfices sont considérables : reproductibilité des environnements, traçabilité des changements via le versionnement, réduction des erreurs humaines, et capacité à gérer des centaines ou des milliers de serveurs comme s'il n'y en avait qu'un seul.

Architecture en un coup d'œil

Trois outils dominent ce marché depuis plus d'une décennie : Ansible (Red Hat), SaltStack (VMware) et Puppet (Perforce). Chacun adopte une philosophie différente, avec ses forces et ses compromis. Dans cet article, nous allons les comparer en profondeur sur plus de quinze critères pour vous aider à faire le choix le plus éclairé possible pour votre organisation.

Présentation de chaque outil

Ansible : la simplicité avant tout

Créé en 2012 par Michael DeHaan et racheté par Red Hat en 2015 (qui fait lui-même partie d'IBM depuis 2019), Ansible s'est imposé comme l'outil de configuration management le plus populaire du marché. Sa philosophie repose sur trois piliers : la simplicité, l'absence d'agent, et l'utilisation de YAML comme langage de description.

Ansible fonctionne en mode push : depuis une machine de contrôle, il se connecte aux serveurs cibles via SSH (ou WinRM pour Windows), exécute les tâches définies dans des playbooks, puis se déconnecte. Il n'y a rien à installer sur les machines gérées, hormis Python (généralement déjà présent sur les systèmes Linux).

L'écosystème Ansible est vaste, avec Ansible Galaxy qui propose des milliers de rôles et collections réutilisables, et Ansible Automation Platform (anciennement Ansible Tower/AWX) qui ajoute une interface web, un contrôle d'accès basé sur les rôles, et une API REST pour l'automatisation à l'échelle de l'entreprise.

SaltStack (Salt) : la performance à grande échelle

Créé en 2011 par Thomas Hatch et racheté par VMware en 2020, SaltStack (souvent simplement appelé Salt) est conçu pour la vitesse et la scalabilité. Son architecture repose sur un bus de messages ZeroMQ (ou optionnellement RAET) qui permet une communication ultra-rapide entre le maître (Salt Master) et les agents (Salt Minions) installés sur les machines cibles.

Salt utilise principalement YAML (avec le moteur de template Jinja2) pour ses fichiers d'état (State files), mais offre également la possibilité d'écrire de la logique en Python. L'une de ses forces distinctives est son système d'exécution à distance (remote execution) qui permet d'envoyer des commandes à des milliers de machines simultanément en quelques secondes.

Salt propose aussi un mode agentless (Salt SSH) pour les cas où l'installation d'un agent n'est pas souhaitée, bien que ce mode soit moins performant que l'architecture avec agents.

Puppet : la rigueur de l'entreprise

Créé en 2005 par Luke Kanies, Puppet est le doyen des outils de configuration management modernes. Racheté par Perforce en 2022, il reste très utilisé dans les grandes entreprises, particulièrement dans les secteurs réglementés (finance, santé, gouvernement).

Puppet utilise son propre langage déclaratif (Puppet DSL), basé sur Ruby, pour décrire l'état souhaité des ressources. Son architecture est de type pull : un agent Puppet installé sur chaque machine interroge régulièrement le serveur Puppet (Puppet Server) pour obtenir le catalogue de configuration à appliquer, puis l'applique localement.

Le Puppet Forge est l'un des dépôts de modules les plus riches et les plus matures de l'écosystème. Puppet est particulièrement apprécié pour sa rigueur dans la gestion de la conformité et son modèle déclaratif strict qui garantit que les machines convergent toujours vers l'état désiré.

Architecture : agentless vs agent-based

L'architecture est l'une des différences les plus fondamentales entre ces trois outils. Elle impacte la mise en place initiale, la maintenance, la sécurité et les performances.

Ansible : architecture agentless (sans agent)

Ansible ne nécessite aucun logiciel spécifique sur les machines cibles. Il se connecte via SSH (Linux/macOS) ou WinRM (Windows), transfère les modules nécessaires, les exécute, puis nettoie derrière lui. Seul Python est requis sur les hôtes distants.

• Avantage : déploiement instantané, aucune infrastructure à maintenir sur les cibles, surface d'attaque réduite.
• Inconvénient : chaque exécution nécessite une connexion SSH, ce qui peut être lent à grande échelle. Pas de daemon qui garantit la conformité en continu.

Salt : architecture agent-based avec option agentless

Salt utilise par défaut des agents (Minions) qui maintiennent une connexion persistante avec le Salt Master via un bus de messages ZeroMQ. Cette architecture permet des communications quasi instantanées.

• Avantage : performances exceptionnelles grâce à ZeroMQ, communication bidirectionnelle, event-driven architecture.
• Inconvénient : nécessite l'installation et la maintenance d'un agent sur chaque machine, ainsi qu'un Salt Master robuste.

Puppet : architecture agent-based

Puppet fonctionne avec un agent (Puppet Agent) sur chaque noeud géré, qui communique avec le Puppet Server via HTTPS. L'agent s'exécute périodiquement (toutes les 30 minutes par défaut) pour vérifier et appliquer la configuration.

• Avantage : convergence automatique et continue, le système se corrige de lui-même si quelqu'un modifie manuellement une configuration.
• Inconvénient : infrastructure agent/serveur à déployer et maintenir, overhead réseau et CPU des vérifications périodiques.

Langage de configuration

Le choix du langage de configuration a un impact direct sur la courbe d'apprentissage, la lisibilité du code et la productivité des équipes.

Ansible : YAML pur

Ansible utilise YAML pour ses playbooks et Jinja2 pour les templates. Le langage est intentionnellement simple et lisible par des non-développeurs :

# Playbook Ansible : installer et configurer Nginx
---
- name: Configuration du serveur web
  hosts: webservers
  become: true

  vars:
    nginx_port: 80
    server_name: example.com

  tasks:
    - name: Installer Nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true

    - name: Déployer la configuration Nginx
      ansible.builtin.template:
        src: templates/nginx.conf.j2
        dest: /etc/nginx/sites-available/default
        owner: root
        group: root
        mode: "0644"
      notify: Redémarrer Nginx

    - name: Activer et démarrer Nginx
      ansible.builtin.systemd:
        name: nginx
        state: started
        enabled: true

    - name: Ouvrir le port dans le firewall
      community.general.ufw:
        rule: allow
        port: "{{ nginx_port }}"
        proto: tcp

  handlers:
    - name: Redémarrer Nginx
      ansible.builtin.systemd:
        name: nginx
        state: restarted

Salt : YAML + Jinja2 (ou Python)

Salt utilise également YAML et Jinja2 pour ses State files (fichiers SLS), mais offre plus de flexibilité en permettant d'intégrer de la logique Python directement :

# State file Salt : installer et configurer Nginx
# /srv/salt/webserver/init.sls

nginx_install:
  pkg.installed:
    - name: nginx

nginx_config:
  file.managed:
    - name: /etc/nginx/sites-available/default
    - source: salt://webserver/files/nginx.conf.j2
    - template: jinja
    - user: root
    - group: root
    - mode: '0644'
    - require:
      - pkg: nginx_install
    - watch_in:
      - service: nginx_service

nginx_service:
  service.running:
    - name: nginx
    - enable: True
    - require:
      - pkg: nginx_install

firewall_http:
  cmd.run:
    - name: ufw allow {{ pillar['nginx_port'] }}/tcp
    - unless: ufw status | grep "{{ pillar['nginx_port'] }}/tcp.*ALLOW"

Puppet : Puppet DSL (Ruby-based)

Puppet utilise son propre langage déclaratif (Domain Specific Language), inspiré de Ruby. Ce langage est plus strict et plus structuré que YAML :

# Manifest Puppet : installer et configurer Nginx
# /etc/puppetlabs/code/environments/production/modules/webserver/manifests/init.pp

class webserver (
  Integer $nginx_port = 80,
  String  $server_name = 'example.com',
) {

  package { 'nginx':
    ensure => installed,
  }

  file { '/etc/nginx/sites-available/default':
    ensure  => file,
    content => template('webserver/nginx.conf.erb'),
    owner   => 'root',
    group   => 'root',
    mode    => '0644',
    require => Package['nginx'],
    notify  => Service['nginx'],
  }

  service { 'nginx':
    ensure => running,
    enable => true,
    require => Package['nginx'],
  }

  exec { 'firewall_http':
    command => "/usr/sbin/ufw allow ${nginx_port}/tcp",
    unless  => "/usr/sbin/ufw status | /bin/grep '${nginx_port}/tcp.*ALLOW'",
  }
}

Comme vous pouvez le constater, les trois outils accomplissent la même tâche, mais avec des syntaxes et des philosophies très différentes. Ansible est le plus lisible pour un débutant, Salt offre un bon compromis entre simplicité et puissance, et Puppet impose une rigueur structurelle plus forte.

Courbe d'apprentissage

La courbe d'apprentissage est un facteur déterminant dans le choix d'un outil, surtout pour les équipes qui découvrent le configuration management.

Ansible : la plus douce

Ansible est unanimement reconnu comme l'outil le plus facile à apprendre. Quelques heures suffisent pour écrire un premier playbook fonctionnel. Les raisons :

• YAML est un format que la plupart des développeurs et administrateurs connaissent déjà.
• L'architecture agentless ne nécessite aucune infrastructure préalable.
• La documentation officielle est excellente et très bien structurée.
• L'immense communauté signifie que la plupart des questions ont déjà été posées et répondues.
• La logique est procédurale (les tâches s'exécutent dans l'ordre), ce qui est intuitif.

Salt : modérée

Salt est un peu plus complexe qu'Ansible en raison de son architecture agent/maître et de concepts spécifiques comme les Grains (informations statiques sur les Minions), les Pillars (données sensibles côté serveur) et les Reactors (système événementiel). Cependant, la syntaxe YAML/Jinja2 est familière et la documentation est correcte.

Puppet : la plus raide

Puppet a la courbe d'apprentissage la plus raide des trois. Le Puppet DSL est un langage à part entière qu'il faut apprendre, le modèle déclaratif peut dérouter les habitués de la programmation impérative, et l'architecture (Puppet Server, PuppetDB, agents, certificats SSL) demande un effort de mise en place conséquent. Comptez plusieurs semaines pour être productif avec Puppet, contre quelques jours pour Ansible.

Performance et scalabilité

C'est sur ce critère que les différences architecturales se font le plus sentir.

Salt : le champion de la performance

Grâce à son bus de messages ZeroMQ, Salt peut communiquer avec des dizaines de milliers de machines en quelques secondes. Le protocole ZeroMQ maintient des connexions persistantes et utilise un modèle de publication/abonnement extrêmement efficace. LinkedIn, par exemple, a utilisé Salt pour gérer plus de 100 000 serveurs.

Les commandes de type remote execution sont quasi instantanées :

# Exécuter une commande sur 10 000 machines en quelques secondes
salt '*' cmd.run 'uptime'

# Cibler par grain (caractéristique du minion)
salt -G 'os:Ubuntu' pkg.install nginx

# Cibler par expression composée
salt -C 'G@os:CentOS and E@web[0-9]+' state.apply webserver

Puppet : excellent à grande échelle

Puppet gère très bien les grandes infrastructures grâce à son modèle pull. Chaque agent est autonome et applique sa configuration indépendamment, ce qui répartit la charge. PuppetDB (base de données des faits et catalogues) permet des requêtes complexes sur l'état de l'infrastructure. Des organisations gèrent des dizaines de milliers de noeuds avec Puppet sans difficulté majeure.

Ansible : le plus lent à grande échelle

Ansible, avec son modèle push via SSH, est structurellement plus lent lorsqu'il faut atteindre un grand nombre de machines. Chaque exécution ouvre des connexions SSH, transfère des modules, et attend les résultats. Cependant, plusieurs mécanismes atténuent ce problème :

• Forks : parallélisme configurable (par défaut 5, souvent monté à 20-50).
• Pipelining : réduit le nombre d'opérations SSH.
• Mitogen : plugin de connexion alternatif qui accélère significativement les exécutions.
• Pull mode : ansible-pull permet aux machines de récupérer elles-mêmes leur configuration.
• Ansible Automation Platform : distribution de la charge sur plusieurs noeuds d'exécution.

# ansible.cfg - Optimisations de performance
[defaults]
forks = 50
pipelining = True
gathering = smart
fact_caching = jsonfile
fact_caching_connection = /tmp/ansible_facts_cache
fact_caching_timeout = 3600

[ssh_connection]
ssh_args = -o ControlMaster=auto -o ControlPersist=60s -o PreferredAuthentications=publickey
pipelining = True

En pratique, Ansible reste performant jusqu'à quelques milliers de machines avec une bonne optimisation. Au-delà, il faut envisager une architecture distribuée avec Ansible Automation Platform ou se tourner vers Salt.

Idempotence

L'idempotence — la capacité d'appliquer la même opération plusieurs fois sans changer le résultat après la première application — est un concept central en configuration management.

• Puppet est idempotent par nature. Son modèle purement déclaratif décrit l'état final souhaité, et l'agent calcule les actions nécessaires pour y parvenir. Si le système est déjà dans l'état souhaité, rien ne se passe. C'est le plus strict des trois sur ce point.
• Ansible est idempotent pour la majorité de ses modules intégrés (apt, yum, file, service...). Cependant, les modules command, shell et raw ne sont pas idempotents par défaut, et il revient au développeur d'ajouter des conditions (creates, when, changed_when) pour garantir l'idempotence.
• Salt adopte une approche similaire à Ansible. Les state modules sont idempotents, mais les modules d'exécution (cmd.run) ne le sont pas intrinsèquement. Les directives unless et onlyif permettent d'ajouter de l'idempotence aux commandes brutes.

Communauté et écosystème

Ansible

• GitHub Stars : ~63 000 (le projet open-source le plus populaire des trois).
• Ansible Galaxy : des milliers de rôles et collections prêts à l'emploi.
• Communauté : la plus large et la plus active. Forums, Slack, meetups, conférences (AnsibleFest).
• Emploi : Ansible est la compétence la plus demandée en configuration management sur le marché de l'emploi.

Salt

• GitHub Stars : ~14 000.
• Salt Formulas : collection de formules (équivalent des rôles Ansible) sur GitHub.
• Communauté : plus petite mais techniquement compétente. Slack actif, documentation complète.
• Emploi : demande plus niche, souvent dans des environnements à très grande échelle.

Puppet

• GitHub Stars : ~7 500.
• Puppet Forge : l'un des dépôts de modules les plus matures avec des modules très bien testés et documentés.
• Communauté : historiquement forte, en déclin relatif face à Ansible. PuppetConf reste un événement majeur.
• Emploi : encore demandé dans les grandes entreprises traditionnelles et les environnements régulés.

Intégration cloud

Les trois outils supportent les principaux fournisseurs cloud, mais avec des niveaux de maturité différents.

• Ansible propose des collections officielles pour AWS, Azure, GCP, DigitalOcean, Linode, et bien d'autres. Les modules cloud sont très complets et permettent de créer des instances, configurer des réseaux, gérer des bases de données managées, etc. L'intégration avec Terraform est également naturelle.
• Salt offre des modules cloud via Salt Cloud, un outil intégré pour le provisionnement d'instances cloud. Il supporte AWS, Azure, GCP, OpenStack, VMware et d'autres. Salt Cloud est particulièrement efficace pour le provisionnement de masse.
• Puppet fournit des modules pour les principaux clouds via le Puppet Forge. L'intégration est correcte mais moins native et moins complète que celle d'Ansible. Puppet brille davantage dans la gestion post-provisionnement que dans le provisionnement lui-même.

Pricing : Open-source vs Enterprise

Ansible

• Gratuit : Ansible Core et AWX (version communautaire de Tower) sont entièrement open-source.
• Payant : Ansible Automation Platform (Red Hat) — tarification par noeud géré, à partir d'environ 5 000 €/an pour une souscription de base. Inclut le support Red Hat, Automation Hub, EDA Controller, et des collections certifiées.

Salt

• Gratuit : Salt Open (anciennement Salt Open Source) est disponible sous licence Apache 2.0.
• Payant : VMware Aria Automation Config (anciennement vRealize Automation SaltStack Config) — tarification enterprise, souvent bundlée avec la suite VMware. Les prix varient significativement selon les accords commerciaux.

Puppet

• Gratuit : Puppet Open Source est disponible sous licence Apache 2.0.
• Payant : Puppet Enterprise — tarification par noeud géré, à partir d'environ 112 $/noeud/an (tarifs publics). Inclut une console web, l'orchestration, le reporting de conformité, et le support.

Tableau comparatif détaillé

Le tableau suivant résume les différences entre les trois outils sur plus de quinze critères :

La même tâche dans les trois outils : un exemple concret

Pour bien comprendre les différences de syntaxe et de philosophie, voyons comment réaliser la même tâche — déployer un utilisateur avec sa clé SSH et configurer sudo — dans chacun des trois outils.

Avec Ansible

# roles/users/tasks/main.yml
---
- name: Créer le groupe deployer
  ansible.builtin.group:
    name: deployer
    state: present

- name: Créer l'utilisateur deploy
  ansible.builtin.user:
    name: deploy
    group: deployer
    groups: sudo
    shell: /bin/bash
    create_home: true
    state: present

- name: Déployer la clé SSH autorisée
  ansible.posix.authorized_key:
    user: deploy
    key: "{{ lookup('file', 'files/deploy_id_rsa.pub') }}"
    state: present
    exclusive: true

- name: Configurer sudo sans mot de passe
  ansible.builtin.copy:
    content: "deploy ALL=(ALL) NOPASSWD: ALL\n"
    dest: /etc/sudoers.d/deploy
    owner: root
    group: root
    mode: "0440"
    validate: "visudo -cf %s"

- name: Sécuriser le répertoire .ssh
  ansible.builtin.file:
    path: /home/deploy/.ssh
    state: directory
    owner: deploy
    group: deployer
    mode: "0700"

Avec Salt

# /srv/salt/users/init.sls

deployer_group:
  group.present:
    - name: deployer

deploy_user:
  user.present:
    - name: deploy
    - gid: deployer
    - groups:
      - sudo
    - shell: /bin/bash
    - createhome: True
    - require:
      - group: deployer_group

deploy_ssh_key:
  ssh_auth.present:
    - user: deploy
    - source: salt://users/files/deploy_id_rsa.pub
    - require:
      - user: deploy_user

deploy_ssh_dir:
  file.directory:
    - name: /home/deploy/.ssh
    - user: deploy
    - group: deployer
    - mode: '0700'
    - require:
      - user: deploy_user

deploy_sudoers:
  file.managed:
    - name: /etc/sudoers.d/deploy
    - contents: "deploy ALL=(ALL) NOPASSWD: ALL"
    - user: root
    - group: root
    - mode: '0440'
    - check_cmd: visudo -cf
    - require:
      - user: deploy_user

Avec Puppet

# modules/users/manifests/deploy.pp

class users::deploy {

  group { 'deployer':
    ensure => present,
  }

  user { 'deploy':
    ensure     => present,
    gid        => 'deployer',
    groups     => ['sudo'],
    shell      => '/bin/bash',
    managehome => true,
    require    => Group['deployer'],
  }

  file { '/home/deploy/.ssh':
    ensure  => directory,
    owner   => 'deploy',
    group   => 'deployer',
    mode    => '0700',
    require => User['deploy'],
  }

  ssh_authorized_key { 'deploy_key':
    ensure  => present,
    user    => 'deploy',
    type    => 'ssh-rsa',
    key     => 'AAAAB3NzaC1yc2EAAAADAQAB...(clé publique)...',
    require => File['/home/deploy/.ssh'],
  }

  file { '/etc/sudoers.d/deploy':
    ensure   => file,
    content  => "deploy ALL=(ALL) NOPASSWD: ALL\n",
    owner    => 'root',
    group    => 'root',
    mode     => '0440',
    validate_cmd => '/usr/sbin/visudo -cf %',
    require  => User['deploy'],
  }
}

On observe que les trois approches sont assez similaires dans la structure, mais diffèrent dans la syntaxe et les conventions. Ansible est le plus proche du langage naturel, Salt est compact et efficace, et Puppet est le plus structuré avec sa syntaxe de type Ruby.

Quand choisir chaque outil ?

Choisissez Ansible si...

• Vous débutez en configuration management et cherchez l'outil le plus simple à apprendre.
• Votre équipe est majoritairement composée de sysadmins ou d'ops sans background développement avancé.
• Vous gérez une infrastructure de taille petite à moyenne (jusqu'à quelques milliers de machines).
• Vous avez besoin d'un outil polyvalent qui fait aussi du provisionnement cloud, de l'orchestration et du déploiement applicatif.
• Vous ne souhaitez pas installer d'agent sur vos machines cibles.
• Vous gérez des équipements réseau (switches, routeurs, firewalls).
• Vous voulez maximiser l'employabilité des compétences acquises par votre équipe.
• Vous êtes déjà dans un écosystème Red Hat (RHEL, OpenShift).

Choisissez Salt si...

• Vous gérez une infrastructure massive (dizaines de milliers de serveurs) et la performance est critique.
• Vous avez besoin d'exécution à distance ultra-rapide sur un grand parc de machines.
• L'automatisation event-driven est un besoin central (réaction à des événements en temps réel).
• Votre équipe a des compétences Python et souhaite exploiter la flexibilité de Salt.
• Vous êtes dans un écosystème VMware et pouvez bénéficier de l'intégration Aria Automation.
• Vous avez besoin à la fois de configuration management et de remote execution performante.

Choisissez Puppet si...

• Vous êtes dans une grande entreprise avec des exigences strictes de conformité et d'audit.
• Vous avez besoin d'une convergence continue garantie (les machines se corrigent automatiquement).
• Votre équipe a des compétences Ruby ou est prête à investir dans l'apprentissage du Puppet DSL.
• Vous gérez un parc de machines hétérogène (Linux, Windows, macOS) et avez besoin d'une abstraction de haut niveau.
• Vous avez une infrastructure existante déjà gérée par Puppet et pas de raison impérieuse de migrer.
• Le reporting et la visualisation de la conformité sont des priorités (Puppet Enterprise excelle dans ce domaine).

Cas d'usage recommandés par scénario

Startup / PME avec infrastructure cloud

Recommandation : Ansible. Sa simplicité, son absence d'agent et sa polyvalence en font le choix idéal pour les petites structures qui veulent aller vite sans investir massivement dans l'outillage. Combiné à Terraform pour le provisionnement et à des playbooks bien structurés, Ansible couvre 95% des besoins.

Grande entreprise avec parc legacy et exigences de conformité

Recommandation : Puppet. Le modèle de convergence continue, le reporting de conformité intégré et la maturité de l'outil en font un choix solide pour les environnements réglementés. La courbe d'apprentissage plus raide est compensée par la rigueur qu'il impose.

Infrastructure massive avec besoin de réactivité temps réel

Recommandation : Salt. Aucun autre outil ne peut rivaliser avec les performances de Salt à très grande échelle. Le système de Reactors et Beacons permet une automatisation event-driven que ni Ansible ni Puppet ne proposent avec le même niveau de maturité.

Environnement DevOps moderne avec CI/CD

Recommandation : Ansible. L'intégration naturelle dans les pipelines CI/CD (Jenkins, GitLab CI, GitHub Actions), la syntaxe YAML cohérente avec le reste de l'écosystème DevOps, et la facilité d'écriture de tests avec Molecule font d'Ansible le choix le plus adapté.

Gestion multi-cloud hybride

Recommandation : Ansible + Terraform. Terraform pour le provisionnement de l'infrastructure, Ansible pour la configuration post-provisionnement. Cette combinaison est devenue un standard de l'industrie grâce à la complémentarité des deux outils.

Mention spéciale : Chef comme alternative

Il serait incomplet de parler de configuration management sans mentionner Chef, créé en 2009 par Adam Jacob. Chef utilise Ruby comme langage de configuration (les "recipes" et "cookbooks"), dispose d'une architecture client-serveur, et offre des fonctionnalités avancées de compliance avec Chef InSpec.

Chef a connu son apogée entre 2010 et 2016, mais son utilisation a décliné face à la montée d'Ansible. En 2019, Chef a fait le choix controversé de passer à un modèle 100% commercial, avant de revenir partiellement à l'open-source sous la pression de la communauté (le projet a été forké sous le nom Cinc). Progress Software a racheté Chef en 2020.

Aujourd'hui, Chef reste pertinent dans les organisations qui l'utilisent déjà, mais il est rarement choisi pour de nouveaux projets en raison de sa complexité (Ruby), de l'incertitude autour de sa licence, et de la diminution de sa communauté active.

Tendances et évolution du marché

Le marché du configuration management évolue rapidement, influencé par plusieurs tendances :

• Infrastructure as Code (IaC) : la frontière entre provisionnement (Terraform, Pulumi) et configuration management (Ansible, Puppet) tend à s'estomper. Ansible joue de plus en plus sur les deux tableaux.
• Containers et Kubernetes : avec l'adoption massive des conteneurs, une partie du configuration management se déplace vers les Dockerfiles et les manifestes Kubernetes. Cependant, il reste indispensable pour les machines hôtes, les environnements bare-metal et les workloads qui ne sont pas conteneurisés.
• GitOps : le modèle GitOps (ArgoCD, Flux) s'impose pour la gestion des applications Kubernetes, mais le configuration management reste nécessaire pour l'infrastructure sous-jacente.
• Event-driven automation : Salt est en avance sur ce créneau, mais Ansible rattrape son retard avec l'Event-Driven Ansible (EDA) Controller intégré à l'Automation Platform.
• Consolidation des acteurs : les rachats successifs (Ansible par Red Hat/IBM, Salt par VMware/Broadcom, Puppet par Perforce, Chef par Progress) montrent que le marché se consolide autour de grands éditeurs.

Peut-on combiner plusieurs outils ?

Absolument, et c'est même une pratique courante dans les grandes organisations. Voici des combinaisons fréquentes :

• Terraform + Ansible : Terraform provisionne l'infrastructure (instances, réseaux, load balancers), Ansible configure les machines et déploie les applications. C'est la combinaison la plus populaire aujourd'hui.
• Puppet + Ansible : Puppet assure la convergence continue de la configuration de base (sécurité, conformité), Ansible est utilisé pour les déploiements applicatifs et les tâches ad-hoc.
• Salt + Ansible : Salt gère le parc de serveurs à grande échelle avec son bus ZeroMQ, Ansible est utilisé pour les playbooks de déploiement et l'orchestration CI/CD.

L'essentiel est de définir clairement les responsabilités de chaque outil pour éviter les chevauchements et la confusion.

Conclusion

Le choix entre Ansible, Salt et Puppet n'est pas une question de "meilleur outil" dans l'absolu, mais de meilleur outil pour votre contexte. Chacun excelle dans son domaine :

• Ansible gagne par sa simplicité, sa polyvalence et sa communauté massive. C'est le choix par défaut pour la majorité des organisations, et c'est celui que nous recommandons si vous partez de zéro.
• Salt est imbattable en termes de performance brute et d'automatisation événementielle. Si vous gérez un parc de dizaines de milliers de machines et que la vitesse d'exécution est critique, Salt est votre meilleur allié.
• Puppet offre la rigueur et la maturité nécessaires dans les environnements d'entreprise réglementés. Son modèle de convergence continue et ses capacités de reporting de conformité sont sans équivalent.

Dans tous les cas, l'important est de commencer. L'automatisation de votre infrastructure, quel que soit l'outil choisi, sera toujours un progrès immense par rapport à la gestion manuelle. Et si vous hésitez encore, commencez par Ansible : sa courbe d'apprentissage douce vous permettra d'être productif rapidement, et les compétences acquises (YAML, Jinja2, concepts d'idempotence et de déclaratif) seront transférables si vous décidez de migrer vers un autre outil plus tard.

L'essentiel est d'adopter une approche Infrastructure as Code, de versionner votre configuration dans Git, de tester vos modifications avant de les appliquer en production, et de documenter vos choix architecturaux. Ce sont ces pratiques, bien plus que le choix de l'outil, qui feront la différence dans la fiabilité et la maintenabilité de votre infrastructure.