Agentless et idempotence : les deux principes fondateurs
Résumé : deux choix radicaux ont fait le succès d'Ansible face à ses concurrents. Agentless : rien à installer sur les serveurs pilotés. Idempotence : lancer plusieurs fois le même playbook donne toujours le même résultat. Cette leçon décortique ces deux principes et compare Ansible à Puppet, Chef et SaltStack pour bien comprendre en quoi ils sont stratégiques, pas juste techniques.
1. Agentless — le principe qui a tout changé
Ansible est agentless : il n'installe rien sur les machines qu'il pilote. Pour beaucoup, c'est la raison principale d'avoir choisi Ansible face à ses concurrents historiques.
1.1 · Comment Ansible se connecte
Ce qui est nécessaire sur la machine cible :
| OS ou équipement | Prérequis Ansible |
|---|---|
| Linux, macOS, BSD | SSH activé + Python 3 (déjà présent sur toutes les distributions modernes) |
| Windows Server | WinRM activé (fonctionnalité native) ou SSH activé |
| Équipements Cisco, Juniper, Arista | API réseau activée (native) |
| API cloud AWS, GCP, Azure | Rien du tout — c'est l'API cloud qui est interrogée |
Aucun logiciel Ansible ne réside sur les cibles. Ansible transfère temporairement du code Python à chaque exécution, le lance, récupère le résultat, et efface. Pas d'agent, pas de service tournant en permanence, pas de mise à jour à faire.
1.2 · Bénéfices concrets du sans-agent
Point stratégique : ces bénéfices ne sont pas juste techniques. Ils sont politiques. Une équipe qui propose Ansible face à son département sécurité obtient beaucoup plus facilement le feu vert qu'une équipe qui propose Puppet ou Chef.
1.3 · La contrepartie honnête du sans-agent
Ne cachons pas les inconvénients — ils existent.
En pratique, ces limites sont largement compensées par les bénéfices — d'où l'adoption massive. Mais elles expliquent pourquoi certaines très grandes infrastructures conservent Puppet ou combinent Ansible avec d'autres outils.
2. Idempotence — le mot savant, le concept simple
Idempotence est un mot qui vient des mathématiques et qui fait peur au premier abord. En réalité, le concept est simple.
Définition : une opération est idempotente si l'exécuter une fois ou plusieurs fois donne exactement le même résultat.
2.1 · Un exemple non-idempotent (à éviter)
Un script bash traditionnel qui installe nginx :
apt-get update
apt-get install -y nginx
useradd webadmin
Que se passe-t-il si vous relancez ce script deux fois ?
- Premier
apt-get install: installe nginx. OK. - Deuxième
apt-get install: nginx est déjà là. Petit warning, mais pas grave. - Premier
useradd webadmin: crée l'utilisateur. OK. - Deuxième
useradd webadmin: erreur — l'utilisateur existe déjà. Le script s'arrête.
Ce script est non-idempotent. On ne peut pas le relancer en toute sécurité.
2.2 · Le même code Ansible, idempotent par défaut
Le playbook Ansible équivalent :
- name: Configuration serveur web
hosts: web
tasks:
- name: Installer nginx
apt:
name: nginx
state: present
update_cache: true
- name: Créer l'utilisateur webadmin
user:
name: webadmin
state: present
Que se passe-t-il si vous relancez ce playbook trois fois ?
C'est l'idempotence en action. Vous décrivez l'état souhaité (« nginx doit être installé »), pas les étapes pour y arriver (« exécute apt install nginx »). Ansible se charge de comparer l'état actuel à l'état souhaité, et n'agit que si nécessaire.
2.3 · Pourquoi c'est révolutionnaire
L'idempotence change fondamentalement la façon de gérer une infrastructure.
Comparez à un script bash classique : chaque relance devient une roulette russe. Avec Ansible, chaque relance est une opération sûre et prévisible.
3. Push vs pull — le modèle Ansible face aux autres
Il y a deux grands modèles pour propager la configuration à des serveurs.
Avantages du push (Ansible) :
- Contrôle immédiat — on lance et on voit le résultat tout de suite.
- Zéro agent à installer et maintenir.
- Simple à comprendre pour un admin sys.
Avantages du pull (Puppet, Chef) :
- Scalable — un serveur maître peut piloter des dizaines de milliers d'agents.
- Auto-correction continue — l'agent applique la configuration toutes les 30 minutes, même sans action de l'admin.
- Résilient — un serveur qui redémarre applique automatiquement sa config.
En 2026, le modèle push d'Ansible domine pour les configurations ponctuelles et les déploiements applicatifs. Le modèle pull garde une pertinence dans les très gros parcs et pour la correction automatique de dérive.
Certains combinent les deux : Ansible Pull existe aussi — chaque serveur cible télécharge périodiquement son propre playbook depuis Git et l'applique en local.
4. Ansible face à ses concurrents en 2026
Tableau comparatif des grands outils de gestion de configuration.
| Critère | Ansible | Puppet | Chef | SaltStack |
|---|---|---|---|---|
| Année de sortie | 2012 | 2005 | 2009 | 2011 |
| Modèle | Push (sans agent) | Pull (avec agent) | Pull (avec agent) | Push et pull |
| Langage de description | YAML | DSL propriétaire | Ruby | YAML |
| Prérequis cible Linux | SSH + Python | Agent Puppet | Agent Chef | Agent Salt (optionnel en mode SSH) |
| Courbe d'apprentissage | Faible | Élevée | Très élevée | Moyenne |
| Support Windows | Bon (WinRM ou SSH) | Bon | Bon | Bon |
| Adoption entreprise | Très forte, en croissance | Historique, stable | En déclin depuis 2020 | Niche, forte communauté |
| Éditeur principal | Red Hat / IBM | Perforce (rachat 2022) | Progress Software | VMware / Broadcom |
| Cas d'usage idéal | Configuration polyvalente, déploiement | Grand parc à auto-correction continue | Environnements Ruby/dev-first | Automatisation événementielle rapide |
Verdict 2026 :
- Ansible est le choix par défaut pour la plupart des équipes qui démarrent.
- Puppet garde du sens dans les grandes entreprises historiques avec un parc massif.
- Chef est en déclin depuis 2020 — son rachat par Progress Software n'a pas relancé la dynamique.
- SaltStack est en position de niche — puissant mais avec une communauté plus réduite.
5. La réponse magique en entretien
Question du recruteur : « Pourquoi Ansible plutôt que Puppet ? »
Bonne réponse en 3 phrases :
Ansible est agentless, ce qui élimine la maintenance des agents Puppet, réduit la surface d'attaque et facilite l'adoption dans les équipes qui ont des contraintes de sécurité. Sa syntaxe YAML est très lisible, ce qui permet aux administrateurs système d'écrire de l'infrastructure as code sans compétences de développeur, contrairement au DSL Puppet ou au Ruby de Chef. Enfin, l'idempotence est native dans tous les modules Ansible, ce qui rend chaque exécution sûre et permet d'utiliser le même playbook comme documentation vivante et comme correcteur automatique de dérive.
Cette réponse démontre que vous comprenez les fondements, pas juste les mots-clés.
Retenir en 30 secondes
- Agentless : Ansible se connecte via SSH ou WinRM, aucun agent n'est installé sur les cibles.
- Idempotence : lancer le même playbook plusieurs fois donne le même résultat, sans casser quoi que ce soit.
- Push : la machine de contrôle initie tout — pas d'agent qui pull comme dans Puppet et Chef.
- Ansible domine face à Puppet, Chef et SaltStack en 2026 pour les projets modernes.
- Les deux principes (agentless + idempotence) expliquent 90 % du succès d'Ansible face à ses concurrents.
Suivant : L'écosystème Ansible : Galaxy, AWX, Ansible vs Terraform →