Développement WordPress multisite
Quand une organisation exploite plusieurs sites apparentés, la partie coûteuse est rarement de les construire. C’est de maintenir cinq bases de code, cinq piles d’extensions, cinq calendriers de mise à jour et cinq versions légèrement divergentes du même design. Un réseau multisite ramène cela à un de chaque, tout en gardant contenus, rédacteurs et permissions séparés.
- Un seul code, un seul système de design, un seul processus de mise en production
- Contenus, utilisateurs et permissions distincts par site
- Des réseaux bilingues où le français et l’anglais sont gérés comme une paire de sites
- Une décision d’architecture prise délibérément, y compris quand la réponse est non
Quand un réseau est la bonne structure
Le multisite est un vrai choix d’architecture avec de vrais coûts, et il est survendu. Le test n’est pas le nombre de sites, c’est ce qu’ils devraient avoir en commun.
Cela convient
Des sites qui devraient partager un code, un système de design et une cadence de mise en production : divisions ou services, sites régionaux ou municipaux, une famille de marques, des microsites de campagne, ou une présence française et anglaise maintenue comme une paire. Les rédacteurs restent séparés ; la plateforme non.
Cela ne convient pas
Des sites aux architectures réellement différentes, aux calendriers de mise en production indépendants, à l’hébergement distinct ou aux exigences de résidence des données propres, ou dont les propriétaires n’ont aucune autorité commune. Les forcer dans un réseau fait de chaque déploiement une négociation.
Exploiter un réseau correctement
Architecture du réseau
Structure en sous-domaines ou en sous-répertoires, mappage de domaines, quelles extensions sont activées pour le réseau et lesquelles par site, et où se situe la frontière entre le partagé et le local. Décidé avant la construction, parce que c’est coûteux à déplacer ensuite.
Des rôles à l'échelle du réseau
Super administrateurs, rédacteurs par site, et les permissions intermédiaires calquées sur la gouvernance réelle de l’organisation : qui peut publier où, et qui peut changer ce qui touche tout le monde.
Paires bilingues
Le français et l’anglais exploités comme des sites d’un même réseau, avec la relation entre pages appariées modélisée explicitement, pour que le changement de langue, les balises hreflang et l’état de traduction soient structurels plutôt que manuels.
Du contenu partagé là où cela aide
Actifs communs, avis, répertoires ou taxonomies diffusés entre les sites là où la duplication dériverait autrement, sans fusionner les sites qui doivent rester séparés.
Un seul processus de mise en production
Gestion de versions, pipeline de construction et environnements échelonnés pour le réseau dans son ensemble, avec un déploiement qui met à jour tous les sites d’un coup et un repli défini.
Un réseau bilingue que nous exploitons nous-mêmes
wplook.ca est un multisite WordPress : un site anglais et un site français dans un même réseau, partageant un seul thème, une seule bibliothèque de blocs sur mesure et un seul pipeline de déploiement, avec la relation entre pages appariées stockée comme métadonnée de contenu et utilisée pour générer le sélecteur de langue et les balises hreflang. C’est un petit réseau, et c’est le schéma que les plus grands utilisent.
La livraison bilingue est aussi une constante dans notre travail client. Les plateformes hypothécaires et de courtage sont construites et maintenues en français et en anglais, y compris une plateforme entièrement francophone. Savoir si une organisation donnée est mieux servie par un réseau multisite ou par une couche de traduction dans un site unique est une décision que nous prenons projet par projet plutôt que par défaut, et nous expliquons l’arbitrage avant qu’il soit fait.
Vous exploitez plus de sites que vous ne pouvez maintenir?
Dites-nous combien de sites il y a, qui possède chacun, et ce qu’ils devraient avoir en commun. C’est cette dernière réponse qui décide si un réseau est la bonne forme.
Ce que coûte un réseau
Des limites honnêtes, parce qu’elles décident si c’est la bonne structure : un réseau partage une base de données, donc un site mal élevé peut affecter les autres ; les extensions ne sont pas toutes compatibles multisite et celles qui ne le sont pas doivent être repérées avant qu’on s’y fie ; les exigences d’hébergement ou de résidence des données propres à un site ne peuvent pas être satisfaites dans un seul réseau ; et une cadence de mise en production unique signifie qu’un site ne peut pas livrer selon son propre calendrier.
Aucune de ces limites n’est une raison d’éviter le multisite. Ce sont les raisons de décider délibérément, et de garder ouverte la possibilité d’en séparer un site plus tard en ne laissant pas les parties partagées du réseau grossir au-delà de ce qui devrait vraiment être partagé.
Questions fréquentes
-
Multisite, ou des installations WordPress séparées?
Le test est ce que les sites devraient avoir en commun, pas leur nombre. S’ils devraient partager un système de design, une bibliothèque de composants et une cadence de mise en production, des installations séparées signifient maintenir cette similitude à la main et la regarder dériver. S’ils ont des architectures, des propriétaires ou des calendriers réellement différents, un réseau fait de chaque déploiement une négociation. Trois sites qui vont ensemble sont un meilleur argument pour le multisite que dix qui ne vont pas ensemble.
-
Pour le français et l'anglais, faut-il un multisite ou une extension de traduction?
Les deux fonctionnent, et ils échouent différemment. Une couche de traduction dans un seul site garde le contenu apparié proche et est plus simple à exploiter, ce qui convient aux sites dont la majeure partie du contenu existe dans les deux langues. Des sites appariés dans un réseau donnent à chaque langue ses propres rédacteurs, permissions, menus et structure, ce qui convient aux organisations où les deux versions ne sont pas des traductions l’une de l’autre mais des contenus différents pour des publics différents. Nous tranchons projet par projet. Ce site est du second type.
-
Un site peut-il quitter le réseau plus tard?
Oui, et cela vaut la peine d’être prévu même quand personne ne le projette. Séparer un site signifie exporter son contenu et ses utilisateurs et monter sa propre installation, ce qui est un travail de migration ordinaire. Ce qui rend l’opération coûteuse, c’est un réseau dont les parties partagées ont grossi au-delà de ce qui devait vraiment l’être, alors nous gardons cette frontière délibérée dès le départ.
-
Le multisite rend-il les sites plus lents?
Pas en soi. Un réseau partage une base de données, donc la cause habituelle d’un site lent dans un réseau est une requête ou une extension qui se comporte mal sur un site et affecte les voisins, ce qui est une raison de gouverner ce qui est activé pour le réseau plutôt qu’une raison d’éviter le multisite. Mise en cache, requêtes et Core Web Vitals restent le même problème d’ingénierie que sur un site unique.
-
Chaque site peut-il avoir son propre domaine?
Oui, par mappage de domaines, et un réseau peut mélanger des sites en sous-répertoire, en sous-domaine et à domaine mappé. Ce qu’un réseau ne peut pas faire, c’est placer des sites sur des hébergements distincts ou satisfaire des exigences de résidence des données propres à un site, parce qu’il y a une seule base de données et un seul système de fichiers. Si cette contrainte s’applique à un site du groupe, elle décide de l’architecture.
-
Qui peut faire quoi dans un réseau?
C’est une question de gouvernance avant d’être une question technique, et c’est la partie le plus souvent remise à après le lancement. Les super administrateurs peuvent changer des choses qui touchent chaque site, y compris les extensions et les thèmes, alors ce rôle est délibérément restreint. Les rédacteurs et administrateurs par site sont calqués sur la gouvernance réelle de l’organisation : qui publie où, et qui a le droit de changer quelque chose que tout le monde voit.