Douze communes, chacune avec son propre annuaire d’équipements publics, ses associations locales et ses actualités municipales, fusionnées en un seul portail intercommunal : l’opération produit un site de plus de cent mille pages, un volume qui dépasse largement ce qu’une architecture WordPress mono-site standard peut absorber sans dégradation progressive des temps de réponse.
Arborescence retenue
La structuration éditoriale du contenu (organisation des rubriques, taxonomies communales) reste hors du périmètre technique traité ici. Côté architecture serveur, le choix s’est porté sur un multisite WordPress avec un réseau par commune, plutôt qu’un site unique avec cent mille articles dans une seule table wp_posts :
portail-intercommunal/
├── commune-a.portail.fr (sous-site, ~8 000 pages)
├── commune-b.portail.fr (sous-site, ~9 500 pages)
├── ...
└── wp-content/
└── uploads/sites/{id}/ (médias isolés par sous-site)
Cette isolation par sous-site répartit la charge de requêtes sur des tables préfixées distinctes (wp_2_posts, wp_3_posts, etc.), ce qu’un moteur MySQL/MariaDB gère nettement mieux qu’une table unique de cent mille lignes soumise à des milliers de requêtes de recherche simultanées.
Base de données : partitionnement logique
Le multisite WordPress partitionne déjà logiquement les données par sous-site au niveau des tables, ce qui limite la profondeur des index nécessaires par requête. Un index composé sur les colonnes les plus sollicitées en recherche (statut de publication, type de contenu, date) reste néanmoins indispensable pour éviter les balayages complets de table lors des recherches transversales à l’ensemble du réseau.
ALTER TABLE wp_2_posts
ADD INDEX idx_recherche (post_status, post_type, post_date);
Cache par sous-arborescence
Un cache de page global, invalidé dans son ensemble à chaque publication sur n’importe quelle commune, provoquerait une régénération massive et coûteuse. Le cache est segmenté par sous-domaine, chaque commune disposant de son propre espace de cache invalidé indépendamment des onze autres.
- Un sous-site publié n’invalide jamais le cache des onze autres sous-sites
- La recherche transversale (annuaire intercommunal complet) passe par un index dédié, distinct du cache de page
- Les médias restent physiquement isolés par sous-site, ce qui simplifie la migration future d’une commune vers un hébergement séparé si nécessaire
L’index de recherche transversal
Pour l’annuaire global qui traverse les douze communes, une recherche native WordPress, même optimisée par des index MySQL, montre ses limites au-delà de quelques dizaines de milliers d’entrées consultées simultanément. Un moteur de recherche dédié type OpenSearch, alimenté par une synchronisation périodique plutôt qu’en temps réel, absorbe cette charge sans solliciter la base de données transactionnelle du site.
Sur un volume de cent mille pages, la question n’est jamais « WordPress peut-il tenir » mais « quelle architecture autour de WordPress évite de tout reconstruire dans deux ans ».
La question de la sauvegarde à ce volume
Sauvegarder l’intégralité de ce réseau multisite en une seule opération devient rapidement impraticable au-delà d’un certain volume : un export complet via wp db export sur l’ensemble des tables préfixées peut dépasser plusieurs dizaines de gigaoctets et immobiliser le serveur pendant l’opération. Une sauvegarde par sous-site, planifiée en rotation plutôt que simultanément sur les douze communes, répartit la charge d’export dans le temps.
wp db export --tables=$(wp db tables 'wp_3_*' --format=csv) sauvegarde-commune-b.sql
En résumé
Un site intercommunal de cette ampleur tient sur WordPress à condition de partitionner logiquement les données par multisite, de segmenter le cache par sous-arborescence et de sortir la recherche transversale de la base transactionnelle principale. Cette architecture, pensée dès la fusion des annuaires, évite qu’une refonte complète ne devienne nécessaire au premier doublement de volume, à condition de traiter également la sauvegarde comme un sujet d’architecture à part entière plutôt qu’un script générique appliqué tel quel.
