Vous pilotez plusieurs marques, pays ou filiales sur des sites qui ont divergé au fil du temps. Nous concevons la plateforme multi-sites adaptée, puis nous l'opérons site par site, depuis 2010.
Quatre signaux font basculer un groupe ou une ETI vers une plateforme multi-sites coordonnée.
Vous maintenez plus de trois à cinq sites de façon indépendante, avec des montées de version désynchronisées.
Vous gérez plusieurs marques ou plusieurs pays, chacun avec ses contenus et ses contraintes locales.
Plusieurs équipes éditoriales coexistent et réclament des droits différenciés par site et par rôle.
Vos sites publics, votre intranet et votre extranet doivent partager des composants et une charte commune.
Vos coûts de maintenance dérivent à mesure que les prestataires et les stacks se multiplient.
Une base, plusieurs sites virtuels.
Un seul WordPress administre des dizaines de sites qui partagent thème, extensions et gouvernance. Adapté à des sites homogènes par pays ou par marque, avec une équipe centrale qui garde la main.
Des sites autonomes, un pilotage commun.
Chaque site reste indépendant, avec sa stack et son cycle de vie. Le partage se limite aux standards de sécurité, de déploiement et de supervision. Adapté aux marques fortement différenciées.
Un backend de contenu, plusieurs fronts.
Un référentiel de contenu unique (Strapi ou WordPress headless) alimente des fronts dédiés en Next.js. Pour des plateformes aux expériences très différentes qui partagent une même source de vérité.
Une plateforme multi-sites, aussi appelée écosystème multi-sites, consiste à coordonner plusieurs sites (marques, pays, filiales, intranets) sous une gouvernance unique, plutôt que de les laisser vivre chacun dans leur coin. Une plateforme multi-sites moderne fédère en général 5 à 30 sites qui partagent une charte, des composants et un socle de sécurité commun, tout en laissant chaque équipe autonome sur son périmètre.
Le sujet revient avec force en 2026. Les groupes consolident leurs marques sur des socles communs. Chaque site doit répondre à des exigences de sécurité et de conformité (RGPD, accessibilité) par pays. Les équipes digitales se centralisent et cherchent à réduire le nombre de prestataires et de stacks à maintenir. La fatigue de l’outillage hétérogène devient un vrai sujet de direction.
Sooyoos conçoit et opère ce type d’architecture depuis 2010. Une vingtaine d’experts internalisés, plus de 300 projets livrés, partenaire SensioLabs (Symfony) et partenaire AWS depuis 2022. Nous intervenons sur les trois patterns du marché et nous restons pour les exploiter dans la durée.
Trois malentendus reviennent souvent. Une plateforme multi-sites n’est ni un site vitrine dupliqué à la chaîne, ni un assemblage de sites reliés par des exports manuels, ni une promesse de centralisation qui retire toute autonomie aux équipes locales. C’est un équilibre : une base commune qui industrialise, et des marges de manœuvre locales qui respectent les métiers.
Quatre signaux annoncent le moment de basculer. Le premier : vous maintenez plus de trois à cinq sites de façon indépendante, et les montées de version se désynchronisent. Le deuxième : vous gérez plusieurs marques ou plusieurs pays, chacun avec ses contenus et ses contraintes locales. Le troisième : plusieurs équipes éditoriales coexistent et réclament des droits différenciés. Le quatrième : vos sites publics, votre intranet et votre extranet doivent partager des composants et une charte commune.
Un cinquième signal est financier. Quand les prestataires et les stacks se multiplient, les coûts de maintenance dérivent et la visibilité se perd. Une plateforme multi-sites bien pensée inverse cette courbe : elle mutualise ce qui peut l’être et isole ce qui doit rester autonome.
Le choix d’architecture conditionne tout le reste : la gouvernance, le coût d’exploitation et la capacité à grandir. Trois patterns dominent.
Le WordPress multisite repose sur un seul WordPress qui administre des dizaines de sites virtuels. Ils partagent thème, extensions et gouvernance. C’est l’usine à sites la plus légère à exploiter, idéale pour 10 à 50 sites homogènes par pays ou par marque. Freyssinet, filiale de Vinci Construction présente dans plus de 100 pays, en est l’illustration : un sous-site par pays, jusqu’à deux langues par site, une base commune. Nous en assurons l’hébergement, les évolutions et la maintenance depuis septembre 2022.
Le pattern plusieurs WordPress orchestrés garde chaque site autonome, avec sa stack et son cycle de vie. Le partage se limite aux standards de sécurité, de déploiement et de supervision. Il convient aux marques fortement différenciées qui veulent une liberté totale d’expérience. Pierre Frey relève en partie de cette logique : un site international servi par une API Gateway sous Symfony, avec un temps d’accès divisé par huit pour un visiteur aux États-Unis.
Le headless centralisé sépare un backend de contenu unique (Strapi ou WordPress headless) de fronts dédiés en Next.js. Il vise les plateformes aux expériences très différentes qui partagent une même source de vérité. Notre article sur le WordPress headless et celui sur Strapi détaillent cette approche.
Le tableau comparatif de cette page met ces trois patterns face à face. La règle reste simple : choisir le pattern qui supporte la croissance prévue à trois ans, au-delà du seul besoin du jour.
La gouvernance multi-sites décide du succès d’une plateforme multi-sites bien plus que la technique. Un parc de sites sans cadre éditorial diverge en dix-huit mois. Les chartes se contredisent, les contenus se dupliquent, les contributeurs se perdent.
Cinq leviers structurent cette gouvernance multi-sites. Les droits granulaires par site et par rôle donnent à chaque contributeur exactement le périmètre dont il a besoin. Les templates communs garantissent la cohérence, avec des règles de surcharge locale claires pour respecter les spécificités pays. Les workflows de validation organisent la relecture entre équipes marque et équipes pays. Le calendrier éditorial partagé évite les collisions de publication. Enfin, des métriques par site dans un dashboard unifié donnent à la direction digitale une vue d’ensemble, sans avoir à compiler dix sources.
Berger-Levrault illustre cet équilibre. Nous avons développé une plateforme multisite et multilingue dont chaque site est dédié à un pays, modifiable indépendamment par les collaborateurs, avec un moteur de recherche à autocomplétion. La plateforme a soutenu une nette croissance de la création de leads.
L’équipe Sooyoos a accompagné Berger-Levrault dans le développement du site institutionnel. La conception est centrée utilisateur. Suite à des tests utilisateurs menés avec nos clients, l’expérience utilisateur est positive !
Nathalie Assoulant, Cheffe de Projet Marketing, Berger-Levrault
Une plateforme multi-sites vit après sa mise en production. Le run est donc une part centrale de l’offre, au même titre que le build. Nous l’opérons avec la même équipe que celle qui a construit, ce qui évite la perte de contexte entre build et run.
Notre run multi-sites combine plusieurs engagements. Un hypercare de 3 mois par site suit chaque mise en production, avec une disponibilité accrue de l’équipe. Une TMA centralisée prend ensuite le relais, avec des délais d’intervention engagés par criticité (P1, P2, P3). La réversibilité reste totale et s’applique site par site : code source, données, documentation et accès vous appartiennent. Des réunions de suivi trimestrielles pilotent les évolutions. Le monitoring Sentry et le ticketing Jira assurent la traçabilité des incidents.
Cette logique de run s’inscrit dans le cycle Run de Sooyoos. La continuité d’équipe est ce qui permet de tenir un parc de dix ou vingt sites sans que personne ne découvre le code la veille d’une opération sensible.
Développement de site, évolutions et maintenance. Sooyoos est un partenaire de confiance, qui a une très bonne expertise et livre des solutions de qualité. Les échanges sont fluides, les engagements tenus. Après plusieurs années de collaboration, c’est toujours un plaisir de travailler avec eux.
Alexia Lacapère, Cheffe de projet digital, Berger-Levrault
Trois erreurs reviennent dans les projets multi-sites mal cadrés.
La première : sous-investir la gouvernance éditoriale. Sans droits, templates et workflows posés dès le départ, les sites divergent et la cohérence de marque s’érode. La remise en ordre coûte ensuite bien plus cher que le cadrage initial.
La deuxième : choisir un pattern technique qui ne supporte pas la croissance prévue. Une architecture taillée pour dix sites peut casser à cinquante. Le pattern se choisit sur la trajectoire à trois ans, en anticipant le périmètre futur.
La troisième : reporter l’observabilité. Sans dashboard unifié et sans supervision centralisée, le diagnostic d’un incident traîne, et un problème sur un site reste invisible jusqu’à ce qu’un utilisateur le signale. L’observabilité se conçoit avec l’architecture.
Une plateforme multi-sites bien conçue produit trois effets mesurables.
D’abord, un time-to-market réduit pour chaque nouveau site. Une base commune permet d’ouvrir un nouveau site pays en réutilisant thème, composants et pipeline de déploiement, au lieu de repartir de zéro. C’est ce qui permet à un groupe comme Freyssinet de couvrir plus de 100 pays sur une même fondation.
Ensuite, une économie de TMA. Mutualiser la maintenance et la supervision coûte moins qu’un parc de prestataires éclatés, chacun avec son contrat et sa stack. La consolidation se lit directement sur le budget.
Enfin, une continuité de service. Notre partenariat AWS depuis 2022 soutient un uptime de 99,99%, avec une infrastructure à l’échelle pour absorber les pics. La disponibilité d’un site critique ne dépend plus d’une intervention manuelle de dernière minute.
Une plateforme multi-sites se décide sur une architecture, une gouvernance et un run pensés ensemble. C’est l’objet du Diagnostic : en deux semaines, nous fixons le pattern adapté, le plan de gouvernance et l’estimation budgétaire. Cette page s’inscrit dans le cycle Build de Sooyoos, en amont du Run qui prend ensuite le relais. Pour intégrer un intranet à votre plateforme, notre article dédié à l’intranet WordPress complète cette lecture. Décrivez votre contexte : nous revenons vers vous sous 48h.
| WordPress multisite | Plusieurs WordPress | Headless centralisé | |
|---|---|---|---|
| Cas d'usage | 10 à 50 sites homogènes (pays, marques proches) | Marques très différenciées, cycles indépendants | Expériences hétérogènes, même source de contenu |
| Gouvernance | Forte, centralisée par nature | À outiller site par site | Centralisée sur le contenu, libre sur les fronts |
| Partage de composants | Thème et extensions mutualisés | Standards communs, code souvent dupliqué | Composants front réutilisés, API commune |
| Montée en charge | Bonne, jusqu'à plusieurs dizaines de sites | Linéaire, chaque site se gère seul | Élevée, fronts mis à l'échelle séparément |
| Coût d'exploitation | Mutualisé, faible par site | Croît avec le nombre de sites | Maîtrisé, mais stack plus exigeante |
| Techno typique | WordPress multisite (Bedrock, Timber) | WordPress autonomes, standards partagés | Strapi ou WordPress headless, Next.js |
Nous cadrons le pattern d'architecture, la gouvernance cible et le budget avant tout développement.
Nous posons l'arborescence multi-sites, les droits par rôle, les templates communs et les règles de surcharge locale.
Nous livrons site par site, en réutilisant la base commune, avec un design-to-cost actif à chaque étape.
Nous ouvrons chaque site en production sans attendre que la plateforme entière soit terminée.
Les mêmes développeurs assurent l'hypercare 3 mois par site, puis la TMA centralisée et la supervision.
Vous basculez dès que vous maintenez plus de trois à cinq sites en parallèle, ou dès qu'apparaissent plusieurs marques, plusieurs pays ou plusieurs équipes éditoriales. Le seuil n'est pas qu'un nombre de sites : c'est le moment où la coordination devient plus coûteuse que la production. Quand chaque montée de version se fait site par site, quand les chartes divergent et quand personne ne voit l'ensemble dans un tableau de bord unique, la plateforme multi-sites devient pertinente. Freyssinet, présent dans plus de 100 pays, illustre le cas extrême : un sous-site par pays, une base commune, un pilotage unique.
WordPress multisite convient à des sites homogènes qui partagent thème, extensions et gouvernance ; plusieurs WordPress autonomes conviennent à des marques fortement différenciées. Le multisite mutualise la maintenance et impose une cohérence forte : un seul cœur applicatif sert dix à cinquante sites. C'est l'approche retenue pour Freyssinet, avec un sous-site par pays et jusqu'à deux langues par site. Les WordPress séparés offrent une liberté totale par marque, au prix d'une duplication de code et d'une gouvernance à outiller site par site. Le bon arbitrage dépend de l'homogénéité de vos sites et de l'autonomie attendue par chaque équipe.
Le choix dépend de l'homogénéité de vos sites et de la liberté attendue côté affichage. Une plateforme multi-sites WordPress (multisite) reste la plus simple à exploiter quand les sites se ressemblent et qu'une équipe centrale pilote l'ensemble. Le headless s'impose quand vos fronts doivent offrir des expériences très différentes tout en partageant une même source de contenu : un backend unique (Strapi ou WordPress headless) alimente des fronts dédiés en Next.js. Une solution dédiée se justifie pour des contraintes métier spécifiques que ni l'un ni l'autre ne couvre. Pour Pierre Frey, nous avons servi un site international par une API Gateway sous Symfony, avec un temps d'accès divisé par huit pour un visiteur aux États-Unis.
La gouvernance multi-sites repose sur quatre piliers : des droits granulaires par site et par rôle, des templates communs surchargeables localement, des workflows de validation par équipe, et un dashboard de métriques unifié. Sans ce cadre, dix sites divergent en dix-huit mois : chartes incohérentes, doublons de contenu, contributeurs perdus. Nous posons cette gouvernance multi-sites dès la phase d'architecture. La rattraper après coup coûte bien plus cher. Chaque équipe pays ou marque garde sa main sur ses contenus, dans des limites définies par la base commune. Le résultat : une cohérence de marque préservée et des contributeurs autonomes sur leur périmètre.
Le coût du run dépend du nombre de sites, du pattern d'architecture retenu et du niveau de service attendu. Trois facteurs pèsent : le volume de sites à superviser, le périmètre de maintenance corrective et évolutive, et les engagements de délai par criticité (P1, P2, P3). Une usine à sites mutualisée coûte moins par site qu'un parc de prestataires éclatés, car la base commune et la supervision sont partagées. Nous chiffrons précisément ce run au Diagnostic, avant tout engagement, plutôt que d'afficher un forfait déconnecté de votre réalité. Le montant du Diagnostic est déduit si vous lancez la suite avec nous.
Oui : la migration se fait par lots, site par site, sans interruption de service sur les sites non encore traités. Nous démarrons par un Diagnostic qui cartographie l'existant, les contenus et les intégrations. Puis nous bâtissons la base commune et migrons un premier site pilote en production. Les suivants reprennent cette base, ce qui accélère chaque vague. Chaque mise en production est suivie d'un hypercare de 3 mois par les mêmes développeurs, pour stabiliser avant d'enchaîner. Cette progression incrémentale évite l'effet tunnel et le big bang qui mettent un parc entier en risque.
Nous accompagnons un projet multi-sites en trois temps : Diagnostic de deux semaines, build incrémental site par site, puis run avec la même équipe. Sooyoos conçoit et opère des écosystèmes digitaux depuis 2010, avec une vingtaine d'experts internalisés et plus de 300 projets livrés. Nous sommes partenaire SensioLabs (Symfony) et partenaire AWS depuis 2022, avec un uptime de 99,99%. La même équipe vous suit du cadrage à la production continue, ce qui évite la perte de contexte entre build et run. Vous gardez la propriété du code et une réversibilité totale, site par site.
Décrivez votre contexte en deux lignes. Nous revenons vers vous sous 48h pour un premier échange de cadrage.
