Au premier rendez-vous, on parle volontiers « du site ». Quelques semaines plus tard, on découvre un site B2B, une boutique grand public, un site d’abonnements, un catalogue à synchroniser et des commerciaux qui ont besoin d’un PDF à envoyer. Le singulier n’a pas résisté longtemps.
Dans un écosystème réel, le client est une entité et plusieurs sites remplissent des rôles distincts. Certains s’adressent au grand public, d’autres aux professionnels ou à des parcours spécialisés. Les ranger dans la même case simplifierait peut-être un tableau, mais compliquerait les parcours, les contenus et la maintenance.
01
Le client n’est pas le site
Cette distinction paraît évidente jusqu’au jour où un même nom se retrouve utilisé pour désigner une entreprise, une marque, un domaine, un catalogue et un outil interne. On finit alors par discuter d’une modification sans savoir quelle plateforme, quel public ou quel parcours elle concerne.
Un modèle simple évite cette confusion : le client porte la relation et les objectifs généraux ; chaque plateforme possède son public, son rôle, ses contenus, ses contraintes et ses responsables. Le lien entre les projets reste visible, mais leur identité ne disparaît pas.
- Client : la relation, les décisions et les priorités globales
- Marque ou service : la promesse faite à un public précis
- Plateforme : le site, la boutique ou l’outil qui remplit un rôle
- Données partagées : produits, commandes, comptes ou contenus
- Interventions : les évolutions documentées dans le temps
02
Commencer par les rôles, pas par la technologie
Deux plateformes peuvent utiliser WordPress et WooCommerce sans devoir offrir la même navigation. À l’inverse, un site, un fichier d’import et un one-pager commercial peuvent participer au même parcours alors qu’ils ne partagent aucune technologie.
La première cartographie doit donc décrire ce que chaque élément permet de faire : commander cent références, acheter un magazine à l’unité, souscrire un abonnement, préparer une expédition ou comprendre l’offre commerciale. La pile technique vient ensuite, au service de ces rôles.
03
Partager les données sans imposer le même parcours
La cohérence ne signifie pas que tout doit devenir identique. Un acheteur professionnel connaît souvent ses références et veut ajouter des quantités rapidement. Un particulier a besoin de couvertures, de catégories, de conseils et d’un panier plus classique. Leur montrer la même interface au nom de la mutualisation crée surtout une frustration commune.
Ce qui mérite d’être partagé se trouve souvent derrière l’écran : identifiants stables, règles communes, sources de catalogue ou conventions de données. Le front-end, lui, peut rester adapté à chaque usage.
- Une source claire pour chaque donnée importante
- Des identifiants stables entre les plateformes
- Des règles métier documentées avant l’automatisation
- Des parcours différents lorsque les intentions diffèrent
- Des tests sur les échanges, pas seulement sur chaque site isolé
04
Travailler avec l’équipe interne, pas à sa place
Un écosystème de cette taille ne se pilote pas correctement depuis l’extérieur, avec trois captures d’écran et une réunion mensuelle. L’équipe interne porte la connaissance quotidienne du métier et de l’infrastructure ; le partenaire externe apporte son regard et ses compétences ciblées.
Les responsabilités doivent rester explicites. Selon le sujet, la solution vient de l’équipe, du prestataire ou de leur discussion. Une vraie collaboration ressemble rarement au portfolio d’un héros solitaire. Elle fonctionne généralement mieux.
05
Le print fait aussi partie de l’écosystème
Un commercial ne va pas toujours ouvrir quatre sites pendant un rendez-vous. Il lui faut parfois une page qui explique les canaux physiques, les plateformes numériques, les chiffres clés et le prochain point de contact. Ce document n’est pas un supplément décoratif : c’est une interface, simplement imprimable et jointe à un e-mail.
Un bon document commercial se conçoit avec la même question qu’un site : que doit comprendre cette personne maintenant, et quelle action doit devenir évidente ensuite ? Faire tenir davantage de blocs ne rend pas l’offre plus complète. Seulement plus petite.
06
Organiser aussi la gouvernance
Une architecture multi-sites échoue rarement parce qu’il manque une flèche dans le schéma. Elle échoue quand personne ne sait qui valide une catégorie, qui surveille un import, qui peut modifier une règle de commande ou dans quel ordre déployer une évolution partagée.
Le document utile associe chaque plateforme à un propriétaire métier, un responsable technique, des dépendances et une fréquence de contrôle. Il devient alors possible de faire évoluer une pièce sans jouer à « voyons ce que cela casse ailleurs ».
Sources et outils utiles
Questions fréquentes
Pour aller au bout du sujet.
Faut-il réunir tous les sites d’un client dans un multisite WordPress ?+
Non. Le multisite peut être pertinent lorsque les sites partagent réellement leur gouvernance, leurs extensions et leur cycle de maintenance. Des publics, équipes ou risques différents peuvent justifier des installations séparées mais bien documentées.
Comment éviter de dupliquer les contenus entre plusieurs plateformes ?+
Il faut d’abord identifier la source de vérité de chaque information. Certaines données gagnent à être synchronisées ; d’autres contenus doivent rester spécifiques parce qu’ils répondent à une intention différente.
Par où commencer l’audit d’un écosystème existant ?+
Par les plateformes, leurs publics, leurs fonctions, leurs responsables et les données qu’elles échangent. Les solutions techniques deviennent beaucoup plus faciles à évaluer une fois cette carte établie.