Tu gères une infrastructure Linux pour une PME ou un éditeur SaaS et tu passes encore trop de temps sur des tâches répétitives ? Déploiements manuels, configs qui divergent entre serveurs, mises à jour qui prennent des heures… J’ai exactement traversé cette situation. Quand j’ai commencé à industrialiser les infrastructures de mes clients avec Ansible, tout a changé : reproductibilité, traçabilité, gain de temps massif. Dans ce guide, je te montre comment passer d’une gestion manuelle à une approche Infrastructure as Code (IaC) avec Ansible, adaptée spécifiquement aux contraintes des PME et éditeurs SaaS. Pas de théorie abstraite : des commandes concrètes, une structure de repo éprouvée, et les pièges à éviter pour que ton industrialisation tienne la route.
Industrialiser une infrastructure Linux avec Ansible en PME/SaaS consiste à automatiser le provisioning, la configuration et le déploiement de serveurs via des playbooks déclaratifs, des rôles réutilisables et un inventaire structuré. Cela permet de passer d’une gestion manuelle et risquée à un processus reproductible, versionné et auditable.
Pourquoi Ansible (et pas autre chose)
Sur le papier, plusieurs outils peuvent automatiser une infrastructure : Terraform, Puppet, Chef, SaltStack… Mais pour une PME ou un éditeur SaaS qui démarre son industrialisation, Ansible a des atouts décisifs :
- Zéro agent — Ansible se connecte en SSH, pas besoin d’installer quoi que ce soit sur les serveurs cibles.
- YAML lisible — Pas besoin d’apprendre un langage DSL propriétaire. Un playbook Ansible se lit comme une recette.
- Courbe d’apprentissage faible — Un sysadmin Linux habitué au shell est opérationnel en quelques jours.
- Idempotence native — Tu relances un playbook 10 fois, le résultat est le même. Pas de effets de bord.
Pour une équipe de 1 à 5 personnes qui gère 5 à 50 serveurs, c’est le point d’entrée idéal. Et si tu as besoin d’être accompagné sur ce type de projet, notre offre DevOps est pensée pour les PME/SaaS.
Le contexte : l’infra manuelle en PME/SaaS
Dans la plupart des PME et éditeurs SaaS que j’accompagne, l’infrastructure commence de la même façon : un serveur provisionné à la main, des configs ajustées au fur et à mesure, des scripts bash qui traînent dans /root/. Ça fonctionne… jusqu’au jour où :
- Un nouveau serveur doit être cloné rapidement → on copie-colle des configs en espérant ne rien oublier.
- Une faille de sécurité est découverte → il faut patcher 15 serveurs un par un.
- Un dev quitte l’équipe → ses « connaissances tacites » partent avec lui.
- Une mise en production rate à cause d’une config différente entre staging et prod.
Ce mode opératoire coûte cher en temps, en stress et en risques. L’Infrastructure as Code (IaC) résout ces problèmes en déclarant l’état souhaité de tes serveurs dans des fichiers versionnés. Si tu veux aussi sécuriser tes déploiements et tes flux CI/CD, cet article sur la sécurisation de serveurs Linux complète parfaitement cette démarche.
Industrialiser ne veut pas dire tout automatiser du jour au lendemain. Commence par les tâches les plus répétitives et les plus risquées (hardening, monitoring, déploiement d’app). Le reste viendra naturellement.
Diagnostic : ton infra est-elle prête pour l’automatisation ?
Avant de te lancer, pose-toi ces questions :
- Tes serveurs sont-ils accessibles en SSH avec clé ? Si tu utilises encore des mots de passe, commence par là.
- Sais-tu exactement ce qui tourne sur chaque serveur ? Si la réponse est non, un inventaire est ta priorité.
- As-tu un processus de déploiement documenté (même minimal) ? L’automatisation d’un chaos organisé donne du chaos automatisé.
- Tes configs sont-elles versionnées quelque part ? Git est le prérequis absolu.
Si tu as répondu oui à au moins 3 questions, tu es prêt. Sinon, prends 1-2 semaines pour combler les manques.
Structurer un repo Ansible pour la production
La structure de ton repo Ansible est la décision la plus importante que tu prendras. Une bonne structure permet à n’importe qui dans l’équipe de comprendre, modifier et étendre l’infrastructure. Voici la structure que j’utilise en production, inspirée de mon repo ansible-production sur GitLab :
ansible-production/
├── inventory/
│ ├── production/
│ │ ├── hosts.yml
│ │ └── group_vars/
│ │ ├── all.yml
│ │ ├── webservers.yml
│ │ └── dbservers.yml
│ └── staging/
│ ├── hosts.yml
│ └── group_vars/
├── roles/
│ ├── common/ # Tâches communes à tous les serveurs
│ ├── nginx/ # Configuration du reverse proxy
│ ├── postgresql/ # Setup base de données
│ ├── docker/ # Installation et config Docker
│ └── monitoring/ # Prometheus, Grafana, Loki
├── playbooks/
│ ├── site.yml # Playbook principal
│ ├── deploy-app.yml # Déploiement applicatif
│ └── rollback.yml # Rollback en cas de problème
├── files/ # Fichiers statiques à copier
├── templates/ # Templates Jinja2
├── secrets/ # Ansible Vault (GITIGNORED)
└── ansible.cfg
Les principes clés :
- Un environnement par dossier d’inventaire — production, staging, etc.
- Un rôle par responsabilité — nginx, postgresql, docker… Pas de rôle fourre-tout.
- Les secrets ne committent jamais — Ansible Vault + .gitignore.
Premiers pas : inventaire et playbook de base
Commençons par l’inventaire. C’est le fichier qui dit à Ansible sur quels serveurs travailler :
# inventory/production/hosts.yml
all:
children:
webservers:
hosts:
web1.linux-man.fr:
ansible_host: 192.168.1.10
ansible_user: deploy
web2.linux-man.fr:
ansible_host: 192.168.1.11
ansible_user: deploy
dbservers:
hosts:
db1.linux-man.fr:
ansible_host: 192.168.1.20
ansible_user: deploy
Et un playbook de base pour le rôle common :
# playbooks/site.yml
---
- name: Configuration commune de tous les serveurs
hosts: all
become: true
roles:
- common
- name: Configuration des serveurs web
hosts: webservers
become: true
roles:
- nginx
- docker
- name: Configuration des serveurs de base de données
hosts: dbservers
become: true
roles:
- postgresql
- monitoring
Tu lances le tout avec :
ansible-playbook -i inventory/production playbooks/site.yml
Toujours tester avec --check (dry-run) avant d’appliquer : ansible-playbook -i inventory/production playbooks/site.yml --check. Ça simule les changements sans les appliquer.
Créer des rôles réutilisables
Un rôle Ansible est un dossier structuré qui regroupe tout ce dont un composant a besoin : tâches, variables, templates, handlers. Voici un exemple de rôle pour le hardening SSH :
roles/common/
├── tasks/
│ └── main.yml
├── handlers/
│ └── main.yml
├── templates/
│ └── sshd_config.j2
├── defaults/
│ └── main.yml
└── vars/
└── main.yml
# roles/common/tasks/main.yml
---
- name: Mettre à jour tous les paquets
apt:
update_cache: true
upgrade: dist
cache_valid_time: 3600
- name: Installer les paquets de base
apt:
name:
- curl
- vim
- htop
- tmux
- ufw
- fail2ban
- unattended-upgrades
state: present
- name: Configurer le firewall UFW
ufw:
rule: allow
port: "{{ item }}"
proto: tcp
loop:
- 22
- 80
- 443
- name: Activer UFW
ufw:
state: enabled
policy: deny
direction: incoming
- name: Déployer la config SSH
template:
src: sshd_config.j2
dest: /etc/ssh/sshd_config
owner: root
group: root
mode: "0600"
notify: Restart SSHD
L’idempotence est au cœur : si SSH est déjà configuré comme indiqué dans le template, Ansible ne fait rien. Tu peux relancer ce playbook autant de fois que tu veux, le résultat sera toujours le même.
Sécuriser les secrets avec Ansible Vault
La gestion des secrets est cruciale en production. Ansible Vault permet de chiffrer les fichiers sensibles (mots de passe, clés API, tokens) avant de les commiter dans Git.
Jamais de secrets en clair dans Git. Utilise Ansible Vault pour tout ce qui est sensible.
Créer un fichier chiffré :
ansible-vault create secrets/production.yml
Editer un fichier chiffré :
ansible-vault edit secrets/production.yml
Exemple de contenu :
# secrets/production.yml
db_password: "!vault |
$ANSIBLE_VAULT;1.1;AES256
66386439653066323439656334613534653361333135636465633966393862623433393562336362
36316434326632666265646638326365336462643765346637633631633964393832666536303266
64646266663431393766626262643261333531373433303664656662643235353332636637306432
62376532373730666434393865383064356434666338643833666332363762343035376537393833
39396637616262326563343833336433626436653333303963623932623936313939616231326264
66663434663762373633303264633637623233653662366362626438666634303464656336333163"
api_token: "!vault |
$ANSIBLE_VAULT;1.1;AES256
66386439653066323439656334613534653361333135636465633966393862623433393562336362
36316434326632666265646638326365336462643765346637633631633964393832666536303266
64646266663431393766626262643261333531373433303664656662643235353332636637306432
62376532373730666434393865383064356434666338643833666332363762343035376537393833
39396637616262326563343833336433626436653333303963623932623936313939616231326264
66663434663762373633303264633637623233653662366362626438666634303464656336333163"
Exécuter un playbook avec Vault :
ansible-playbook -i inventory/production playbooks/site.yml --ask-vault-pass
Les erreurs courantes (et comment les éviter)
🔧 « Mon playbook échoue parce que Ansible dit que le serveur est inaccessible »
Vérifie ta connexion SSH en dehors d’Ansible. Si ça ne marche pas en SSH, ça ne marchera pas avec Ansible. Vérifie aussi que ansible_host est correct dans l’inventaire.
🔧 « Ansible modifie des fichiers qu’il ne devrait pas »
Utilise --check systématiquement avant d’appliquer. C’est ton filet de sécurité. Si tu veux aller plus loin, configure host_key_checking = False avec prudence dans ansible.cfg après avoir compris les risques.
🔧 « Mes rôles deviennent ingérables »
La solution : un rôle par responsabilité, pas de rôle fourre-tout. Si un rôle dépasse 200 lignes de tâches, découpe-le en sous-rôles.
Checklist : industrialiser son infra avec Ansible
✅ Checklist pré-déploiement
--check + run réel)--diff pour vérifier les modificationsFAQ
▶ Ansible est-il adapté aux PME/SaaS ?
▶ Combien de temps pour industrialiser une infra avec Ansible ?
▶ Dois-je utiliser Ansible Vault ou un outil externe pour les secrets ?
▶ Comment tester un playbook sans toucher à la production ?
--check (dry-run) et --diff (voir ce qui change). Pour aller plus loin, Molecule permet de tester des rôles Ansible dans des conteneurs Docker isolés. C’est la méthode recommandée pour des playbooks critiques.▶ Quelle différence entre Terraform et Ansible ?
Conclusion
Industrialiser une infrastructure Linux avec Ansible n’est pas une question de technologie, mais d’approche. C’est passer d’une gestion manuelle et risquée à un processus reproductible, versionné et auditable. Pour une PME ou un éditeur SaaS, les gains sont immédiats : moins de stress, moins d’erreurs, plus de visibilité.
Si tu veux être accompagné pour industrialiser ton infrastructure avec Ansible, contacte-moi pour en discuter. J’ai accompagné plusieurs PME et éditeurs SaaS sur ce type de projet, et je peux t’aider à éviter les erreurs courantes et à mettre en place une base solide.
Tu veux industrialiser ton infrastructure Linux avec Ansible ?
J’ai accompagné plusieurs PME et éditeurs SaaS sur ce type de projet. Ensemble, nous mettrons en place une base solide qui s’adapte à ta croissance.