Linux & VPS

Ansible en 2026 : Automatiser son Infrastructure Linux de Zéro — Guide Complet

Guide complet Ansible pour débutants : installation, playbooks, variables, vault et exemples réels sur Rocky Linux et Ubuntu.

Rh1nux

19 mars 2026 — 9 min read

L'automatisation est devenue un pilier incontournable de l'administration système moderne. Que vous gériez 2 serveurs ou 200, répéter les mêmes tâches à la main est une source d'erreurs, de perte de temps et de frustration. C'est là qu'Ansible entre en scène.

Dans ce guide complet, vous allez découvrir Ansible de zéro : ce que c'est, pourquoi l'utiliser, comment l'installer et comment l'utiliser pour automatiser vos tâches quotidiennes. Pas besoin d'être expert — si vous savez utiliser SSH et taper des commandes Linux, vous êtes prêt.

Qu'est-ce qu'Ansible et pourquoi l'utiliser ?

Ansible est un outil d'automatisation open source développé par Red Hat. Il permet de gérer des serveurs distants, de déployer des applications, de configurer des systèmes et d'orchestrer des tâches complexes — le tout depuis une seule machine.

Ce qui rend Ansible unique par rapport à ses concurrents (Chef, Puppet, SaltStack), c'est sa philosophie sans agent (agentless). Ansible se connecte à vos serveurs via SSH et exécute des tâches directement. Pas de daemon à installer, pas de certificat à gérer, pas de port supplémentaire à ouvrir.

Voici pourquoi Ansible s'est imposé comme le standard de l'industrie :

Simple à apprendre : les playbooks sont écrits en YAML, un format lisible même par un non-développeur
Agentless : pas d'agent à installer sur les machines cibles, juste SSH
Idempotent : vous pouvez relancer un playbook plusieurs fois sans risque — il n'appliquera que ce qui est nécessaire
Extensible : des milliers de modules disponibles pour tout gérer (packages, fichiers, services, cloud, réseau...)
Open source et gratuit : communauté massive, documentation excellente, Ansible Galaxy pour partager des rôles

En 2026, Ansible reste l'outil de référence pour les équipes DevOps, SRE et sysadmin. Maîtriser Ansible, c'est s'offrir un avantage concret sur le marché.

Prérequis avant de commencer

Avant d'installer Ansible, voici ce dont vous avez besoin :

Une machine de contrôle (votre poste ou un serveur) sous Linux ou macOS. Ansible ne fonctionne pas nativement sous Windows comme machine de contrôle (WSL2 est nécessaire dans ce cas).
Python 3.8 ou supérieur installé sur la machine de contrôle
SSH configuré vers vos machines cibles. L'authentification par clé SSH est fortement recommandée.
Les machines cibles doivent avoir Python 3 installé (la plupart des distributions modernes l'ont par défaut)

Pour vérifier votre version de Python :

python3 --version

Si vous n'avez pas encore de clé SSH, générez-en une :

ssh-keygen -t ed25519 -C "ansible-key"
ssh-copy-id admin@192.168.1.10

Installation d'Ansible

Ansible s'installe facilement via le gestionnaire de paquets de votre distribution ou via pip.

Sur Ubuntu / Debian

sudo apt update && sudo apt install -y ansible
ansible --version

Sur Rocky Linux / RHEL / AlmaLinux

Il faut d'abord activer le dépôt EPEL (Extra Packages for Enterprise Linux) :

sudo dnf install -y epel-release
sudo dnf install -y ansible
ansible --version

Via pip (méthode universelle)

Si vous voulez toujours avoir la dernière version, pip est la méthode la plus fiable :

pip3 install ansible
ansible --version

La commande ansible --version doit vous afficher quelque chose comme :

ansible [core 2.16.x]
  config file = /etc/ansible/ansible.cfg
  configured module search path = [...]
  python version = 3.11.x
  jinja version = 3.x.x

Si vous voyez cette sortie, Ansible est correctement installé. Passons à la configuration.

Concepts clés à comprendre

Avant de lancer votre première commande, familiarisez-vous avec le vocabulaire Ansible. C'est la base de tout.

Le nœud de contrôle (Control Node)

C'est votre machine — celle où Ansible est installé. C'est d'ici que toutes les commandes partent. Ansible se connecte en SSH vers les machines cibles depuis ce nœud.

Les nœuds gérés (Managed Nodes)

Ce sont vos serveurs cibles. Ansible s'y connecte via SSH pour exécuter des tâches. Aucun logiciel Ansible n'est installé dessus — juste Python et un serveur SSH.

L'inventaire (Inventory)

L'inventaire est un fichier qui liste tous vos serveurs et les organise en groupes. C'est le fichier que vous passerez à presque toutes vos commandes Ansible.

Les modules

Les modules sont les "briques" d'Ansible. Chaque module effectue une action spécifique : installer un paquet, copier un fichier, créer un utilisateur, gérer un service... Il en existe des milliers dans la bibliothèque standard et sur Ansible Galaxy.

Les tâches (Tasks)

Une tâche est l'appel d'un module avec des paramètres. Par exemple : "installe le paquet nginx" ou "crée l'utilisateur deployer".

Les playbooks

Un playbook est un fichier YAML qui contient une liste de tâches à exécuter sur un groupe de machines. C'est le cœur d'Ansible — votre recette d'automatisation.

Les rôles (Roles)

Un rôle est une façon structurée d'organiser un playbook complexe en plusieurs fichiers réutilisables. On en parle plus loin dans ce guide.

Premiers pas : créer votre inventaire

L'inventaire est votre première étape concrète. Créez un fichier inventory.ini dans votre répertoire de travail :

[webservers]
192.168.1.10
192.168.1.11

[dbservers]
192.168.1.20

[all:vars]
ansible_user=admin
ansible_ssh_private_key_file=~/.ssh/id_rsa

Quelques explications :

[webservers] et [dbservers] sont des groupes. Vous pouvez les nommer comme vous voulez.
[all:vars] définit des variables qui s'appliquent à toutes les machines.
ansible_user est l'utilisateur SSH à utiliser pour se connecter.
ansible_ssh_private_key_file pointe vers votre clé SSH privée.

Vous pouvez aussi utiliser des noms DNS au lieu d'adresses IP, et ajouter des variables par hôte :

[webservers]
web01.mondomaine.com ansible_port=2222
web02.mondomaine.com

Tester la connectivité avec le module ping

Le module ping d'Ansible n'est pas un ping ICMP — il vérifie qu'Ansible peut se connecter à l'hôte et que Python est disponible.

ansible all -i inventory.ini -m ping
ansible webservers -i inventory.ini -m ping

Si tout est bien configuré, vous devez voir pour chaque machine :

192.168.1.10 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Un résultat SUCCESS avec "ping": "pong" confirme qu'Ansible peut communiquer avec vos serveurs. Vous êtes prêt pour la suite.

Les commandes ad-hoc

Avant de passer aux playbooks, Ansible permet d'exécuter des tâches ponctuelles directement en ligne de commande. Ces commandes sont appelées commandes ad-hoc. Elles sont parfaites pour les opérations rapides.

# Vérifier l'espace disque sur tous les hosts
ansible all -i inventory.ini -m shell -a "df -h /"

# Copier un fichier
ansible webservers -i inventory.ini -m copy -a "src=/local/file dest=/remote/path"

# Redémarrer un service
ansible webservers -i inventory.ini -m service -a "name=nginx state=restarted" --become

# Installer un paquet
ansible all -i inventory.ini -m package -a "name=htop state=present" --become

L'option --become équivaut à un sudo — Ansible prendra les droits root sur la machine cible. L'option -a passe des arguments au module.

Écrire votre premier Playbook

Un playbook est un fichier YAML qui décrit ce qu'Ansible doit faire. Créez un fichier deploy-nginx.yml :

---
- name: Installer et démarrer Nginx
  hosts: webservers
  become: yes
  tasks:
    - name: Installer Nginx
      ansible.builtin.package:
        name: nginx
        state: present

    - name: Démarrer et activer Nginx
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: yes

Décortiquons ce fichier :

--- : indique le début d'un document YAML
name : description du play (lisible par les humains)
hosts: webservers : ce play s'applique au groupe webservers de l'inventaire
become: yes : utiliser sudo pour toutes les tâches
tasks : liste des tâches à exécuter dans l'ordre
ansible.builtin.package : module générique pour installer des paquets (fonctionne sur Ubuntu, Rocky Linux, etc.)
state: present : le paquet doit être installé
state: started : le service doit être démarré
enabled: yes : le service doit démarrer automatiquement au boot

Lancer un playbook

ansible-playbook -i inventory.ini deploy-nginx.yml
ansible-playbook -i inventory.ini deploy-nginx.yml --check  # dry-run
ansible-playbook -i inventory.ini deploy-nginx.yml -v       # verbose

L'option --check (dry-run) simule l'exécution sans appliquer de changements — indispensable avant de lancer sur de la production. L'option -v (verbose) affiche plus de détails sur chaque tâche.

Après l'exécution, Ansible affiche un résumé :

PLAY RECAP *****************************************************
192.168.1.10 : ok=2  changed=2  unreachable=0  failed=0
192.168.1.11 : ok=2  changed=2  unreachable=0  failed=0

ok : tâches exécutées avec succès
changed : modifications effectuées sur la machine
unreachable : machine inaccessible
failed : tâches en échec

Les Variables dans Ansible

Les variables permettent de rendre vos playbooks flexibles et réutilisables. Plutôt qu'un playbook codé en dur pour un cas précis, vous créez un playbook générique paramétrable.

Variables dans le playbook

---
- name: Créer un utilisateur système
  hosts: all
  become: yes
  vars:
    username: deployer
    shell: /bin/bash
  tasks:
    - name: Créer l'utilisateur {{ username }}
      ansible.builtin.user:
        name: "{{ username }}"
        shell: "{{ shell }}"
        create_home: yes
        state: present

Les variables s'utilisent avec la syntaxe {{ variable }} (syntaxe Jinja2). Ici, username et shell sont définies dans la section vars du playbook.

Passer des variables en ligne de commande

ansible-playbook -i inventory.ini playbook.yml -e "username=newuser shell=/bin/zsh"

Fichiers de variables (group_vars et host_vars)

Pour des configurations plus complexes, organisez vos variables dans des fichiers dédiés :

group_vars/
├── all.yml          # Variables pour tous les hôtes
├── webservers.yml   # Variables pour le groupe webservers
└── dbservers.yml    # Variables pour le groupe dbservers

Ces fichiers sont automatiquement chargés par Ansible si vous les placez dans le répertoire group_vars/ à côté de votre inventaire.

Ansible Vault : protéger vos secrets

Ne stockez jamais vos mots de passe, clés API ou tokens en clair dans vos fichiers Ansible. Ansible Vault chiffre ces informations sensibles.

Créer un fichier chiffré

ansible-vault create secrets.yml

Ansible vous demandera un mot de passe, puis ouvrira un éditeur pour que vous saisissiez vos secrets en YAML :

db_password: MonMotDePasseSuperSecret
api_key: abc123xyz789
smtp_password: P@ssw0rd!

Modifier un fichier chiffré

ansible-vault edit secrets.yml

Utiliser un fichier chiffré dans un playbook

ansible-playbook -i inventory.ini playbook.yml --ask-vault-pass

Ansible déchiffre automatiquement secrets.yml et rend les variables disponibles dans votre playbook. Vous pouvez aussi utiliser un fichier contenant le mot de passe (utile pour l'automatisation CI/CD) avec l'option --vault-password-file.

Exemples réels : cas d'usage courants

Maintenant que vous maîtrisez les bases, voici des exemples concrets que vous pouvez utiliser directement dans votre infrastructure.

Déployer et configurer un pare-feu

---
- name: Configurer le pare-feu UFW
  hosts: webservers
  become: yes
  tasks:
    - name: Installer UFW
      ansible.builtin.package:
        name: ufw
        state: present

    - name: Autoriser SSH
      community.general.ufw:
        rule: allow
        port: "22"

    - name: Autoriser HTTP et HTTPS
      community.general.ufw:
        rule: allow
        port: "{{ item }}"
      loop:
        - "80"
        - "443"

    - name: Activer UFW
      community.general.ufw:
        state: enabled

Mettre à jour tous les serveurs

---
- name: Mise à jour complète des serveurs
  hosts: all
  become: yes
  tasks:
    - name: Mettre à jour les paquets (Debian/Ubuntu)
      ansible.builtin.apt:
        upgrade: dist
        update_cache: yes
      when: ansible_os_family == "Debian"

    - name: Mettre à jour les paquets (RHEL/Rocky)
      ansible.builtin.dnf:
        name: "*"
        state: latest
      when: ansible_os_family == "RedHat"

La variable ansible_os_family est automatiquement collectée par Ansible (c'est un fact). Ce playbook est donc compatible avec vos environnements mixtes Ubuntu/Rocky Linux.

Les Rôles Ansible : structurer vos projets

Quand vos playbooks grandissent, les rôles permettent de les organiser de façon propre et réutilisable. Un rôle est une structure de répertoires standardisée :

roles/
└── nginx/
    ├── tasks/
    │   └── main.yml
    ├── handlers/
    │   └── main.yml
    ├── templates/
    │   └── nginx.conf.j2
    ├── files/
    ├── vars/
    │   └── main.yml
    └── defaults/
        └── main.yml

Voici le rôle de chaque répertoire :

tasks/ : les tâches principales du rôle (obligatoire)
handlers/ : actions déclenchées par notify (ex: redémarrer nginx après modification de config)
templates/ : fichiers de configuration Jinja2 (variables remplacées dynamiquement)
files/ : fichiers statiques à copier sur les hôtes
vars/ : variables du rôle (haute priorité)
defaults/ : variables par défaut (basse priorité, facilement surchargées)

Pour créer la structure d'un rôle automatiquement :

ansible-galaxy role init roles/nginx

Les rôles se partagent sur Ansible Galaxy (galaxy.ansible.com), le hub communautaire d'Ansible. Des milliers de rôles prêts à l'emploi y sont disponibles.

Bonnes pratiques Ansible

Quelques règles d'or pour garder vos projets Ansible maintenables et sécurisés :

1. Toujours utiliser des modules natifs plutôt que shell/command

Préférez ansible.builtin.package à ansible.builtin.shell: apt install nginx. Les modules natifs sont idempotents, gèrent les erreurs proprement, et fonctionnent sur plusieurs distributions.

2. Versionnez vos playbooks avec Git

Vos playbooks sont de l'infrastructure as code. Traitez-les comme du code : commits réguliers, branches pour les changements majeurs, tags pour les déploiements en production.

3. Toujours tester avec --check avant de déployer

ansible-playbook -i inventory.ini playbook.yml --check --diff

L'option --diff affiche les différences dans les fichiers modifiés, comme un git diff.

4. Organisez vos variables par environnement

inventories/
├── production/
│   ├── hosts.ini
│   └── group_vars/
└── staging/
    ├── hosts.ini
    └── group_vars/

5. Documentez vos playbooks

Le champ name de chaque tâche est votre documentation. Soyez descriptif : préférez "Installer Nginx et ses dépendances" à "Install".

6. Utilisez ansible-lint

pip3 install ansible-lint
ansible-lint playbook.yml

ansible-lint analyse vos playbooks et signale les erreurs de style, les modules dépréciés et les mauvaises pratiques.

7. Ne mettez jamais de secrets en clair

Utilisez systématiquement Ansible Vault pour tout ce qui est sensible : mots de passe, clés, tokens. Configurez votre .gitignore pour ne jamais committer de fichiers de secrets non chiffrés.

Conclusion : Ansible, votre nouveau super-pouvoir de sysadmin

Vous avez maintenant les bases solides pour commencer à automatiser votre infrastructure avec Ansible. Récapitulons ce que vous avez appris :

Ansible est agentless : il fonctionne via SSH, sans rien installer sur vos serveurs
L'inventaire organise vos machines en groupes logiques
Les playbooks en YAML décrivent vos automatisations de façon lisible
Les modules fournissent des actions idempotentes et portables
Les variables rendent vos playbooks flexibles et réutilisables
Ansible Vault protège vos secrets
Les rôles structurent vos projets complexes

La prochaine étape ? Commencez petit : automatisez une tâche répétitive que vous faites manuellement chaque semaine. Mise à jour de vos serveurs, déploiement d'une application, création d'utilisateurs... Chaque tâche automatisée est du temps gagné et une erreur humaine évitée.

Ansible Galaxy regorge de rôles prêts à l'emploi. La documentation officielle d'Ansible est l'une des meilleures du monde open source. Et la communauté est immense et bienveillante.

En 2026, l'automatisation n'est plus un luxe réservé aux grandes entreprises — c'est une compétence de base pour tout sysadmin qui se respecte. Vous avez maintenant les clés pour démarrer. À vous de jouer.