Notre passage de 40 à 500 sites gérés : ce que l’outillage a dû changer

500 sites gérés aujourd’hui, contre 40 il y a un peu plus de six ans. Cette croissance ne s’est jamais accompagnée d’une refonte planifiée de l’outillage : à chaque palier, un point de friction précis a forcé la main, jamais une anticipation confortable. Ce texte retrace les trois paliers d’outillage traversés, ce qui a déclenché chacun d’eux, et ce que nous referions différemment avec le recul.

Il ne s’agit pas d’un guide prescriptif sur l’outillage idéal pour une agence WordPress : c’est un récit de décisions prises sous contrainte, certaines bonnes, d’autres qu’il a fallu corriger a posteriori.

Premier palier, jusqu’à 80 sites : les scripts bash maison

À 40 sites, un unique développeur gérait l’ensemble du parc à l’aide d’une poignée de scripts bash : un pour déployer via rsync, un pour synchroniser les bases entre environnements, un pour lancer les sauvegardes. Ce système, rudimentaire mais parfaitement compris par toute l’équipe restreinte de l’époque, a tenu sans changement majeur jusqu’à environ 80 sites, bien au-delà de ce que nous aurions estimé raisonnable au départ.

La limite est apparue non pas sur le volume de sites, mais sur le nombre de personnes intervenant sur ces scripts. Passé trois développeurs différents modifiant les mêmes fichiers bash sans convention stricte, les scripts ont commencé à diverger d’une machine à l’autre, chacun ayant sa propre version légèrement adaptée localement.

Deuxième palier, jusqu’à 300 sites : Ansible pour reprendre le contrôle

La bascule vers Ansible n’a pas été motivée par le volume de sites en lui-même, mais par le besoin de définir un état désiré de chaque serveur, décrit dans du code versionné plutôt que dans des habitudes individuelles. Les playbooks Ansible ont remplacé progressivement les scripts bash pour le provisionnement des serveurs et la configuration des environnements, tout en conservant WP-CLI pour les opérations propres à chaque site WordPress.

- hosts: serveurs_mutualises
  tasks:
    - name: Vérifier la version PHP installée
      command: php -v
      register: version_php
    - name: Déployer la configuration Nginx standard
      template:
        src: templates/nginx-wordpress.conf.j2
        dest: /etc/nginx/sites-available/{{ site_slug }}.conf

Cette étape a stabilisé l’infrastructure jusqu’à environ 300 sites, avec une équipe passée entre-temps à une dizaine de développeurs. Le principal bénéfice n’était pas la vitesse de déploiement, restée comparable, mais la reproductibilité : deux serveurs provisionnés à des mois d’intervalle finissaient dans un état strictement identique.

Troisième palier, au-delà de 300 sites : une plateforme interne

Passé 300 sites, la friction s’est déplacée de l’infrastructure vers la visibilité : personne dans l’équipe ne pouvait répondre en quelques secondes à des questions simples comme « combien de sites tournent encore en PHP 7.4 » ou « quel client a une sauvegarde de plus de sept jours ». Ansible décrit l’état désiré, mais ne donne pas de vue consolidée sur l’état réel du parc à un instant donné.

Nous avons développé une plateforme interne, construite autour d’un inventaire centralisé alimenté automatiquement par des remontées régulières depuis chaque site via WP-CLI, avec un tableau de bord consultable par toute l’équipe. Ce troisième palier reste, à ce jour, celui qui a demandé le plus d’investissement de développement pur, plusieurs mois cumulés sur plus d’un an.

Ce qui n’a jamais changé sur l’ensemble des trois paliers

• WP-CLI est resté l’outil d’exécution de référence côté WordPress à chaque palier
• Aucune bascule n’a été un big bang : chaque transition a coexisté plusieurs mois avec l’outillage précédent
• Chaque nouveau palier a été déclenché par une douleur déjà ressentie, jamais par anticipation pure

Changer d’outillage avant d’en ressentir la nécessité coûte souvent plus cher que de subir un peu de friction supplémentaire.

En résumé

Passer de 40 à 500 sites n’a jamais été une trajectoire planifiée à l’avance : chaque palier d’outillage a répondu à une contrainte concrète, au moment où elle devenait réellement handicapante. Les scripts bash, Ansible et la plateforme interne ne s’excluent pas entre eux, ils se sont simplement succédé à mesure que le volume et la taille de l’équipe rendaient l’étape précédente insuffisante.