Ansible 2026 : la stack pratique pour automatiser Linux et Windows

Pourquoi Ansible reste central en 2026

Ansible a beaucoup changé depuis sa première version. Le moteur historique livré avec la commande ansible a été éclaté en deux briques distinctes : ansible-core, le runtime minimaliste, et le Ansible Community Package, qui agrège ansible-core avec un large lot de collections (modules tiers maintenus par les communautés). En mai 2026, la version stable est ansible-core 2.20, sortie le 3 novembre 2025, dont la phase de correctifs critiques court jusqu’au 18 mai 2026 avant de basculer en phase « security only ». La 2.21 est en RC. Côté package communautaire, c’est la branche 13.x qui sert de référence pour qui veut un kit complet.

Cette séparation a une conséquence pratique : un parc moderne ne fige plus tout dans un binaire monolithique. On installe ansible-core, on déclare les collections nécessaires dans un fichier requirements.yml, et on les épingle. C’est ce qui rend la stack reproductible — un Ansible installé sur le poste d’un développeur exécute exactement les mêmes modules que la même version installée sur un runner GitHub Actions ou un nœud AWX.

Ansible n’a jamais cessé d’être pertinent parce qu’il occupe une niche que ses concurrents — Puppet, Chef, Salt, ou les outils plus récents comme Pyinfra — n’ont jamais entièrement comblée. Trois propriétés expliquent cette résilience : l’agentless (rien à installer sur les machines cibles, juste SSH ou WinRM), l’idempotence (le même playbook peut tourner cent fois sans casser ce qui marche), et la lisibilité du YAML (un sysadmin junior comprend un playbook bien écrit en quelques minutes).

Architecture et concepts clés à maîtriser

Avant d’écrire le moindre playbook, il faut tenir trois concepts dans la tête.

Le premier, c’est l’inventaire. Un inventaire Ansible décrit l’ensemble des machines à piloter et les groupes auxquels elles appartiennent. Il peut être statique (un fichier INI ou YAML) ou dynamique (un plugin qui interroge l’API d’un fournisseur cloud à chaque exécution). Les variables d’inventaire — group_vars/, host_vars/ — décrivent la configuration spécifique à chaque hôte ou groupe. Sans inventaire propre, un projet Ansible devient ingérable au-delà de cinq ou six machines.

Le deuxième, c’est le module. Un module est l’unité atomique d’action : ansible.builtin.copy dépose un fichier, ansible.builtin.user crée un compte, community.mysql.mysql_db crée une base. Ansible en livre des centaines, organisés en collections nommées en deux parties (namespace.collection). Un bon réflexe en 2026 : préférer le nom pleinement qualifié (fully qualified collection name, ou FQCN) plutôt que les alias courts. ansible.builtin.copy est explicite, copy tout court fonctionne mais devient ambigu dès qu’une collection tierce expose un module homonyme.

Le troisième, c’est l’idempotence. Un module Ansible bien écrit observe l’état actuel du système, le compare à l’état déclaré, et n’agit que si une divergence existe. Lancer le même playbook trois fois consécutives doit produire le même résultat — création la première fois, OK (changed=0) les fois suivantes. Les playbooks qui violent cette règle (par exemple en utilisant ansible.builtin.shell ou command sans garde-fou) sont les premiers à devenir hostiles à la maintenance.

La stack Ansible 2026 — ce qu’il faut installer

Une stack Ansible moderne tient en cinq briques, et il est utile de les distinguer d’emblée pour ne pas réinventer ce qui existe déjà.

1. ansible-core — le binaire minimal, installé via pip install ansible-core ou via le paquet système (apt install ansible-core sur Debian/Ubuntu, dnf install ansible-core sur RHEL/Fedora). C’est l’unique vraie dépendance.
2. Collections — déclarées dans collections/requirements.yml à la racine du projet, installées avec ansible-galaxy collection install -r collections/requirements.yml. Pour un parc Hetzner par exemple, on prend hetzner.hcloud ; pour Windows, ansible.windows et microsoft.ad ; pour AWS, amazon.aws.
3. ansible-lint — le linter officiel qui attrape les erreurs de style et les anti-patterns avant qu’ils ne polluent la prod. Il s’intègre à pre-commit et aux pipelines CI.
4. Molecule — l’outil de tests pour les rôles. Il provisionne un conteneur Docker (ou Podman) éphémère, applique le rôle, vérifie l’idempotence et lance des assertions, puis détruit l’environnement. Indispensable dès qu’un rôle est partagé entre plusieurs projets.
5. ansible-vault — l’utilitaire de chiffrement intégré. Il chiffre des fichiers ou des variables individuelles avec AES-256 et gère plusieurs clés via le mécanisme vault-id. Aucun secret en clair dans Git.

Côté contrôleur, ansible-core 2.20 exige Python 3.12 à 3.14. Côté machines cibles, Python 3.9 minimum suffit pour les nœuds Linux ; pour Windows, c’est PowerShell 5.1 (présent par défaut sur Windows Server 2016 et plus récent) qui sert de runtime, sans Python.

Linux : du contrôle initial à la gestion à grande échelle

Sur Linux, Ansible parle SSH. Concrètement, le contrôleur ouvre une connexion SSH sur la cible, copie un module compilé en Python dans ~/.ansible/tmp/, l’exécute avec privilèges si nécessaire (via become: true, qui s’appuie sur sudo par défaut), récupère le résultat JSON, puis nettoie. Aucun agent, aucun port custom — c’est du SSH standard.

La trame de progression d’un parc Linux suit toujours la même courbe :

Étape 1 — l’inventaire statique de poche. Cinq à dix machines, un fichier inventory.ini, des groupes par rôle ([web], [db], [cache]). On exécute ansible all -i inventory.ini -m ping pour valider la connectivité, puis on enchaîne sur les premiers playbooks.

Étape 2 — la structuration en rôles. Dès que le projet dépasse trois playbooks, la duplication apparaît. On crée des rôles (roles/nginx/, roles/mariadb/) avec la commande ansible-galaxy init nom-du-role, qui génère le squelette canonique : tasks/, handlers/, defaults/, templates/, files/, meta/. Les playbooks deviennent alors de simples appels à des rôles paramétrés.

Étape 3 — la modularisation et le partage. Au-delà de cinq rôles, on les sort dans des dépôts séparés et on les importe via requirements.yml. C’est aussi à ce stade que Molecule devient indispensable : chaque rôle a sa suite de tests, déclenchée à chaque pull request.

Étape 4 — l’inventaire dynamique. Au-delà de quinze ou vingt machines, le fichier statique devient un goulot d’étranglement. On bascule sur un plugin d’inventaire qui interroge le provider à chaque run. Pour Hetzner Cloud, le plugin est hetzner.hcloud.hcloud et il accepte un api_token — qu’on stocke évidemment dans un vault et non en clair.

Étape 5 — l’orchestration multi-couches. Pour un nouveau projet en 2026, le pattern dominant est Terraform pour l’infrastructure, Ansible pour la configuration. Terraform crée les serveurs et les networks, exporte un inventaire dynamique, Ansible prend le relais pour configurer le système d’exploitation, déployer les services et appliquer les politiques de sécurité.

Windows : WinRM, Kerberos, PowerShell

Côté Windows, la mécanique est différente mais la promesse Ansible reste la même : aucun agent à installer. Le contrôleur communique avec la cible via WinRM (Windows Remote Management), un protocole HTTP/HTTPS encapsulant SOAP. Le contrôleur reste sur Linux ou macOS — Windows comme contrôleur n’est officiellement pas supporté pour ansible-core, même si la WSL2 reste un contournement viable pour le poste de développement.

Trois éléments à régler pour qu’un parc Windows réponde proprement :

L’authentification. En environnement Active Directory, on choisit Kerberos (ansible_winrm_transport: kerberos) — c’est le seul mode qui résiste aux attaques pass-the-hash et qui s’intègre avec les politiques de sécurité de l’AD. Hors AD, NTLM reste possible mais devient difficile à justifier en 2026.

Le transport. En production, HTTPS avec un certificat valide (port 5986) — pas de HTTP nu (5985). Sur les machines cibles, on active WinRM via le script ConfigureRemotingForAnsible.ps1 fourni par la collection ansible.windows, qu’on adapte ensuite pour exiger TLS et un certificat émis par l’AD CS interne.

Les modules. Trois collections couvrent l’essentiel : ansible.windows (modules de base, équivalents Windows de copy, file, user), community.windows (modules avancés, par exemple win_iis_* pour IIS), et microsoft.ad (gestion fine d’Active Directory : utilisateurs, groupes, OU, GPO).

Le piège classique sur Windows : les modules s’exécutent en PowerShell sur la cible, mais les playbooks restent en YAML sur le contrôleur. La logique de quoting est différente, et un développeur Linux qui débute sur Windows passera quelques heures à comprendre pourquoi un chemin avec antislash échappe trois fois ses caractères. Les guides officiels Windows sont à lire avant le premier playbook.

Inventaire dynamique et secrets — les deux piliers de la production

Un projet Ansible qui n’a pas réglé ces deux questions n’est pas prêt pour la production. C’est aussi simple que ça.

L’inventaire dynamique élimine les écarts entre la réalité de l’infrastructure et le fichier d’inventaire. Quand un nouveau VPS est provisionné, il apparaît automatiquement dans l’inventaire au prochain run. Quand un VPS est détruit, il disparaît. Les playbooks ciblent des groupes définis par les tags ou les labels du provider — par exemple hcloud_label_role_web regroupe tous les serveurs taggés role=web sur Hetzner Cloud.

Le fichier d’inventaire dynamique est un YAML court qui déclare le plugin et ses paramètres. Le token API ne s’écrit jamais en dur dans ce fichier — il vient d’une variable d’environnement ou d’un fichier vault.

plugin: hetzner.hcloud.hcloud
keyed_groups:
  - key: labels.role
    prefix: role
hostvars:
  ansible_host: ipv4_address

Cette configuration crée automatiquement un groupe role_web pour chaque serveur taggé en conséquence, et utilise l’IPv4 du serveur comme adresse de connexion. Le résultat se vérifie avec ansible-inventory --graph.

Les secrets, eux, sont gérés par ansible-vault. Trois patterns coexistent en 2026 :

1. Fichiers chiffrés intégraux. ansible-vault encrypt secrets.yml chiffre tout le fichier. Pratique, mais le diff Git devient illisible — on voit juste un blob qui change.
2. Variables individuelles chiffrées. ansible-vault encrypt_string 'mon-secret' --name 'db_password' produit une chaîne YAML chiffrée à coller dans un fichier de variables clair. Les diffs restent lisibles, seules les valeurs sensibles sont chiffrées.
3. Vault-id multiples. Pour distinguer plusieurs niveaux de secrets — dev, prod, CI — on attribue un identifiant à chaque clé : --vault-id prod@~/.ansible/prod.key. Un même playbook peut alors être exécuté avec la clé qui correspond au contexte.

L’intégration CI repose sur le même mécanisme : la clé de vault est stockée dans un secret du runner (GitHub Actions, GitLab CI), exposée au moment du run, et passée à Ansible via --vault-password-file. Aucun secret n’est jamais écrit sur le disque persistant.

Tester ses rôles avec Molecule

Un rôle Ansible non testé est un rôle qui cassera la prochaine fois qu’on touche un default. Molecule corrige ce risque en provisionnant des conteneurs éphémères pour chaque exécution. Le cycle est défini dans molecule/default/molecule.yml et suit toujours la même séquence : create (lance le conteneur), converge (applique le rôle), idempotence (le relance et vérifie que rien ne change), verify (lance les assertions, généralement avec ansible.builtin.assert), destroy (nettoie).

En 2026, le driver dominant reste Docker, mais Podman gagne du terrain — il évite le démon root et s’intègre proprement aux runners CI sans privilèges spéciaux. Les images de référence (Debian, Ubuntu, Rocky Linux, AlmaLinux) sont publiées sous le namespace geerlingguy/docker-*-ansible, maintenu par Jeff Geerling, mainteneur historique de l’écosystème Ansible.

Event-Driven Ansible — l’automatisation réactive

Event-Driven Ansible (EDA) est l’extension officielle qui transforme Ansible d’un outil poussé (on lance un playbook quand on en a besoin) en un outil réactif (un playbook se déclenche automatiquement quand une condition est remplie). C’est le projet stratégique de Red Hat depuis l’acquisition de la startup à l’origine du concept.

Le vocabulaire change un peu. Au lieu de playbook, on parle de rulebook. Un rulebook se compose de trois éléments : une source (d’où viennent les événements : webhook, Kafka, Prometheus Alertmanager, journaux Loki, fichier surveillé), des conditions (quels événements déclenchent quoi), et des actions (en général run_playbook ou run_module).

Un cas d’usage classique : Prometheus envoie une alerte « disque saturé » via Alertmanager → un rulebook EDA reçoit le webhook → si l’alerte concerne un serveur du groupe role_web, le rulebook lance un playbook qui purge les vieux logs et redémarre le service. Tout cela sans intervention humaine, en quelques secondes.

Les tutoriels pour mettre cela en pratique

Pour chaque brique évoquée, un tutoriel pas-à-pas creuse le détail :

• Installer Ansible et exécuter son premier playbook — l’inventaire, les modules de base, l’idempotence vérifiée à la main.
• Structurer un projet Ansible en rôles — ansible-galaxy init, le rôle defaults vs vars, les handlers et la notification.
• Gérer les secrets avec Ansible Vault — chiffrement de fichiers, encrypt_string, vault-id multiples, intégration GitHub Actions.
• Inventaire dynamique pour Hetzner Cloud — installation du plugin, keyed_groups par labels, group_vars qui suivent.
• Provisionner un serveur web LEMP avec Ansible — Nginx, PHP-FPM 8.x, MariaDB, certificats Let’s Encrypt automatiques.
• Durcir un serveur Linux avec Ansible — alignement CIS Benchmark, fail2ban, sshd hardening, ufw, sysctl.
• Déployer une application Node.js avec Ansible et systemd — pull Git, build, unité systemd, reverse proxy, rolling deploys.
• Orchestrer Terraform et Ansible — le pattern provision-puis-configure, en détail.
• Tester ses rôles avec Molecule et Docker — la matrice de scénarios, l’idempotence, les assertions, l’intégration CI.
• Event-Driven Ansible — le rulebook minimal, la source webhook, l’action run_playbook, le déploiement avec ansible-rulebook.

Performance — pousser Ansible au-delà de cent machines

Le reproche le plus fréquent fait à Ansible concerne sa lenteur quand le parc grandit. Le problème est réel mais se règle avec trois leviers que les équipes négligent souvent.

Le nombre de forks. Par défaut, ansible-core exécute les tâches sur cinq hôtes en parallèle. Cette valeur date d’une époque où les contrôleurs avaient peu de RAM. Sur un poste moderne ou un runner CI, on monte facilement à cinquante ou cent forks via ansible.cfg : forks = 50. La latence d’un play sur cent serveurs passe alors d’une vingtaine de minutes à deux ou trois minutes.

Le pipelining SSH. Avec pipelining = True dans ansible.cfg, ansible-core fusionne le transfert et l’exécution du module en un seul aller-retour SSH au lieu de deux. Le gain typique est de 30 à 50 % sur les playbooks dominés par les petits modules. Il exige requiretty désactivé dans /etc/sudoers sur les cibles, ce qui est le cas par défaut sur Debian/Ubuntu modernes.

Les handlers et la stratégie d’exécution. La stratégie par défaut linear attend que tous les hôtes aient terminé une tâche avant de passer à la suivante. La stratégie free laisse chaque hôte avancer à son rythme — utile sur un parc hétérogène où certaines machines sont plus lentes. Pour les déploiements rolling, on combine cela avec serial: 5 au niveau du play pour ne traiter que cinq hôtes à la fois.

Au-delà de quelques centaines de machines, on bascule en architecture pull avec ansible-pull ou en mode événementiel avec EDA — chaque cible s’auto-configure depuis Git, ce qui scale linéairement avec le nombre de machines au lieu de saturer le contrôleur.

AWX et Ansible Automation Platform — quand passer au stade industriel

Tant qu’on reste sur un seul opérateur ou une petite équipe alignée, la ligne de commande suffit. Dès qu’il faut donner des droits d’exécution à des non-experts (équipes métier, NOC, support niveau 2), le terminal devient un goulot. C’est là qu’AWX entre en scène.

AWX est l’interface web open source qui empile, sur ansible-core, une couche de RBAC fine (qui peut lancer quel job, contre quel inventaire, avec quelles credentials), un planificateur de jobs, un système de notifications, des templates de playbook paramétrables, et une API REST complète. On installe AWX en quelques minutes via le AWX Operator sur un cluster Kubernetes — ou sur un mini-K3s mono-nœud pour les petites équipes.

Ansible Automation Platform (AAP) est la version commerciale Red Hat qui ajoute le support, l’Automation Hub privé pour les collections certifiées, l’intégration avancée avec Insights et OpenShift, et un SLA. Le rapport coût/bénéfice ne devient évident qu’à partir d’un certain volume — disons une équipe ops de cinq personnes pilotant plusieurs centaines de machines réparties sur plusieurs environnements.

Erreurs fréquentes et comment les éviter

FAQ

ansible-core ou Ansible Community Package : que choisir ?
Pour un nouveau projet en 2026, ansible-core seul plus un requirements.yml explicite est le choix le plus propre. Le package communautaire reste pratique pour un poste de découverte ou un script ponctuel, mais il rend les dépendances opaques.

Faut-il encore apprendre Ansible si Terraform existe ?
Oui. Terraform et Ansible répondent à des problèmes différents. Terraform décrit l’infrastructure (serveurs, réseaux, DNS) ; Ansible configure ce qui tourne dessus (paquets, services, fichiers). Les deux outils se complètent, ils ne se remplacent pas.

Quelle distribution Linux choisir pour un parc Ansible ?
Toutes celles qui livrent un Python ≥ 3.9 sur les cibles. En pratique, Debian 12, Ubuntu 22.04 LTS et 24.04 LTS, Rocky Linux 9, AlmaLinux 9 sont les choix les plus simples car les modules apt et dnf les gèrent sans surprise.

Comment gérer un parc mixte Linux et Windows depuis un même contrôleur ?
Un contrôleur Linux unique pilote les deux. Les hôtes Windows déclarent ansible_connection: winrm et leurs spécificités d’authentification dans group_vars/windows.yml. Les hôtes Linux gardent les valeurs par défaut (SSH). Un même playbook peut alors orchestrer les deux mondes en utilisant des modules distincts par groupe.

Combien de temps pour devenir productif sur Ansible ?
Une dizaine d’heures pour les bases (premier playbook, rôle simple, inventaire). Trente à cinquante heures pour la maîtrise réelle (vault, inventaire dynamique, Molecule, CI/CD). Au-delà, on entre dans la spécialisation : EDA, AWX/AAP, intégration multi-cloud.

Quelle est la différence entre AWX et Ansible Automation Platform ?
AWX est le projet upstream open source. Ansible Automation Platform (AAP) est l’offre commerciale Red Hat construite à partir d’AWX, avec support, RBAC durci, hub de collections certifiées et services managés. Pour une PME qui débute, AWX suffit largement.

Ansible peut-il remplacer un script bash ?
Pour une opération unique sur une seule machine, un script bash reste plus rapide à écrire. Dès qu’on cible plusieurs machines ou qu’on a besoin d’idempotence, Ansible devient supérieur — même pour des tâches qu’on aurait écrites en bash dix ans plus tôt.

Pour approfondir

• Documentation officielle ansible-core — la référence absolue, à garder ouverte en permanence.
• Calendrier des versions et maintenance — pour épingler la bonne version selon la fenêtre de support.
• Ansible Galaxy — l’index public des collections et rôles communautaires.
• Documentation Molecule — pour structurer une suite de tests sérieuse.
• ansible-lint — la liste des règles et leur justification.
• Event-Driven Ansible — la documentation officielle EDA et ses sources d’événements.