« Trellis provides the foundation for maintaining flawless server configuration across development, staging, and production environments », annonce toujours la documentation du projet Roots. La promesse tient depuis 2015 : environnements identiques du poste de développement à la production, décrits en Ansible plutôt que configurés à la main. Mais en 2024, choisir Trellis pour une nouvelle agence qui démarre pose une question que les premières années ne posaient pas aussi frontalement : le temps investi dans le maintien de playbooks Ansible reste-t-il justifié face à des hébergeurs managés qui font l’essentiel du travail en quelques clics ?
Le constat vient d’un choix de stack de départ pour une agence qui lance son activité et cherche la fondation la plus pérenne, sans équipe dédiée à l’infrastructure. Trellis a été testé pendant deux mois sur un projet réel avant d’être écarté, non pour des raisons de qualité technique, mais pour un rapport effort-bénéfice qui ne collait plus avec la taille de l’équipe.
Ce que Trellis fait toujours très bien
Le provisionnement d’un nouveau serveur avec ansible-playbook server.yml -e env=production reste impressionnant : en une quarantaine de minutes, un VPS nu se retrouve avec Nginx, PHP-FPM, MariaDB, un pare-feu configuré et une structure de dossiers cohérente avec Bedrock, sans intervention manuelle. La reproductibilité entre développement, recette et production est réelle, et les rôles Ansible du projet sont maintenus avec sérieux par la communauté Roots.
Sur un parc de plusieurs serveurs identiques, cette reproductibilité justifie largement l’investissement initial. C’est précisément la situation qui a changé pour l’agence concernée : un seul serveur de production à faire vivre, pas un parc à industrialiser.
La friction qui a fini par peser
Chaque montée de version PHP demandait de vérifier la compatibilité des rôles Ansible du projet avec la nouvelle version, parfois d’attendre une mise à jour communautaire, parfois de patcher soi-même un rôle pour débloquer une migration urgente. Sur un projet où personne dans l’équipe n’avait une expertise Ansible poussée, chaque intervention sur les playbooks prenait un temps disproportionné par rapport au gain attendu.
Ce que proposent les hébergeurs managés en 2024
Les hébergeurs spécialisés WordPress (au sens large, hébergement managé avec interface web) couvrent aujourd’hui l’essentiel de ce que Trellis automatisait manuellement : certificats TLS renouvelés automatiquement, mise à jour de la version PHP en quelques clics dans un tableau de bord, sauvegardes programmées sans configuration Ansible à écrire. La contrepartie est une perte de contrôle fin sur la configuration serveur, un compromis qui s’est révélé acceptable pour une agence qui débute et n’a pas de besoin d’infrastructure spécifique.
Ce qui a fait pencher la balance
- Temps de mise en route d’un nouveau projet : quelques minutes chez l’hébergeur managé, contre une demi-journée pour adapter les playbooks Trellis à un nouveau projet
- Compétence Ansible nécessaire en interne pour déboguer un provisionnement qui échoue
- Coût du VPS nu à héberger soi-même, à comparer à l’offre managée équivalente
Ce que ce retour d’expérience ne remet pas en cause
Bedrock, la structure de projet WordPress sur laquelle s’appuie Trellis, reste utilisé sans changement : la séparation des variables d’environnement, la structure web/app plutôt que wp-content, et l’installation des extensions par Composer continuent d’apporter une vraie rigueur au projet, indépendamment du choix d’hébergement. Ce n’est donc pas Bedrock qui a été remis en question, seulement la couche de provisionnement serveur.
Le bon outil d’infrastructure n’est pas le plus puissant dans l’absolu, c’est celui que l’équipe en face peut maintenir sans y consacrer plus de temps que le projet n’en vaut la peine.
Pour quel profil Trellis reste pertinent
Une équipe qui gère un parc de plusieurs serveurs avec des besoins de configuration spécifiques (règles de pare-feu particulières, services additionnels, environnements multiples strictement identiques) continue de trouver dans Trellis un vrai bénéfice de reproductibilité. C’est la taille du parc et la compétence Ansible disponible en interne qui déterminent si l’investissement reste rentable, pas la qualité de l’outil lui-même.
En résumé
Trellis n’a rien perdu de sa robustesse en 2024, mais son rapport effort-bénéfice s’est déplacé face à des hébergeurs managés devenus très compétents sur les tâches qu’il automatisait. Pour une petite agence qui démarre, la simplicité opérationnelle d’un hébergeur managé l’a emporté sur le contrôle fin qu’offre un provisionnement Ansible complet.
