Faut-il vraiment choisir un seul outil d’infrastructure as code pour gérer un parc WordPress d’agence, ou combiner plusieurs approches selon la couche concernée ? Pour trancher, nous avons reproduit le même scénario de provisionnement — dix serveurs, chacun hébergeant plusieurs sites WordPress mutualisés — avec trois outils différents : Ansible, déjà en place depuis plusieurs années, Terraform, et Pulumi, plus récent dans notre pratique.
Ce comparatif ne prétend pas trancher définitivement en faveur d’un seul outil : il documente ce que chacun fait bien, ce qu’il fait moins bien, et pourquoi la réponse la plus honnête, en 2026, reste probablement « les trois, mais pas pour la même chose ».
Ansible : la configuration applicative reste son terrain naturel
Ansible, sans agent à installer et reposant sur SSH, reste l’outil le plus direct pour tout ce qui touche à la configuration applicative d’un serveur déjà provisionné : installation de PHP-FPM, configuration de Nginx, déploiement de la structure de dossiers WordPress standard. Sa syntaxe déclarative en YAML reste accessible à une équipe qui n’a pas de culture de développement logiciel poussée, ce qui compte pour une agence où les profils sont mixtes entre administration système et développement.
Terraform : plus pertinent pour les ressources cloud elles-mêmes
Terraform s’est montré plus adapté dès qu’il s’agissait de provisionner les ressources elles-mêmes plutôt que de configurer un serveur existant : création des instances chez le fournisseur cloud, configuration réseau, attribution des adresses IP et des groupes de sécurité. Son modèle d’état, qui suit précisément ce qui a été créé et compare systématiquement à l’état désiré avant chaque application, a évité plusieurs dérives de configuration que l’équipe n’aurait pas détectées manuellement sur dix serveurs.
resource "server" "wordpress_mutu_01" {
plan = "medium"
region = "fr-par"
tags = ["wordpress", "mutualise", "agence"]
}Pulumi : un vrai langage de programmation, pour les équipes qui le préfèrent
Pulumi reprend une logique proche de Terraform côté gestion d’état, mais permet d’écrire l’infrastructure dans un langage de programmation généraliste plutôt que dans un langage déclaratif dédié. Pour une équipe habituée à écrire du JavaScript ou du TypeScript au quotidien pour le développement de thèmes et d’extensions, cette proximité de syntaxe a réduit la courbe d’apprentissage initiale, au prix d’un écosystème de modules encore moins fourni que celui de Terraform sur certains fournisseurs cloud spécifiques.
Tableau comparatif sur le scénario testé
| Critère | Ansible | Terraform | Pulumi |
|---|---|---|---|
| Provisionnement de ressources cloud | Limité | Excellent | Excellent |
| Configuration applicative serveur | Excellent | Limité | Limité |
| Courbe d’apprentissage pour développeurs JS | Modérée | Modérée | Faible |
| Maturité de l’écosystème | Très bonne | Très bonne | Bonne |
Ce que le scénario complet a fini par ressembler
Sur les dix serveurs testés, l’architecture retenue combine finalement Terraform pour le provisionnement initial des ressources cloud, puis Ansible pour la configuration applicative une fois les serveurs disponibles. Pulumi, testé en parallèle sur trois serveurs, n’a pas démontré d’avantage suffisant pour justifier une troisième technologie dans la chaîne, sur ce scénario précis et avec cette équipe précise.
- Terraform décrit ce qui doit exister au niveau infrastructure
- Ansible configure ce qui doit tourner sur cette infrastructure une fois créée
- Aucun script bash maison n’intervient plus dans cette chaîne, contrairement à il y a encore deux ans
Le meilleur outil d’infrastructure as code n’est pas celui qui fait tout, c’est celui dont l’équipe comprend réellement chaque ligne qu’elle écrit.
Notre verdict
Aucun des trois outils testés n’a été écarté définitivement à l’issue de ce comparatif, mais leur périmètre d’usage s’est clarifié : Terraform pour les ressources, Ansible pour la configuration, et Pulumi réservé aux cas où une équipe préfère explicitement retrouver un langage de programmation classique. Ce découpage, propre à notre contexte d’agence, ne se transpose pas nécessairement ailleurs sans adaptation.
