Ce qu’il faut retenir
Le nombre de sites n’est pas le seul critère : l’isolation des données, des droits et des clés API est prioritaire.
Les éléments mutualisés doivent être choisis explicitement ; tout partager par défaut crée des erreurs de marque et de publication.
Le reporting doit permettre de voir à la fois la santé du portefeuille et l’historique précis d’un projet.
Commencer par cartographier le portefeuille
Listez les sites, leurs propriétaires, leurs domaines, leurs langues, leurs rythmes de publication et leurs dépendances. Deux blogs techniquement similaires peuvent nécessiter des règles différentes si l’un appartient à un client et l’autre à une marque interne.
Cette cartographie révèle ce qui doit être isolé et ce qui peut être partagé. Elle évite de sélectionner une plateforme sur un volume abstrait de projets alors que la difficulté réelle vient des validations, des identités ou des contraintes de diffusion.
Vérifier l’isolation et les permissions
Un utilisateur ne doit voir que les projets auxquels il est rattaché. Les auteurs, catégories, médias, jetons et journaux doivent suivre la même frontière. Testez la plateforme avec plusieurs rôles et tentez volontairement d’accéder à un identifiant appartenant à un autre projet.
Les droits utiles dépassent souvent le couple administrateur-rédacteur : création, édition, validation, publication, gestion des médias et consultation des statistiques peuvent exiger des autorisations distinctes. La simplicité de l’interface ne doit pas reposer sur des permissions trop larges.
Décider ce qui mérite d’être mutualisé
Une médiathèque globale peut réduire les doublons, mais elle exige des règles de licence et d’usage. Une taxonomie commune facilite le reporting, mais peut devenir artificielle pour certaines marques. Des modèles de contenus partagés accélèrent la production, à condition de permettre des variantes locales contrôlées.
Formalisez chaque mutualisation avec un propriétaire, une règle de modification et une stratégie de retrait. Le principe le plus sûr reste l’isolation par défaut, puis l’ouverture explicite des ressources réellement communes.
Recetter le CMS sur un scénario inter-projets
Créez deux projets, deux identités visuelles et trois niveaux de droits. Importez un média partagé, publiez un article sur un seul site, puis vérifiez API, sitemap, canonical et cache. Révoquez enfin un membre et une clé pour contrôler la propagation de la décision.
La recette doit produire des preuves : capture du périmètre visible, journal de publication, réponse d’API et temps de résolution d’une erreur. C’est ce dossier qui permet de comparer des solutions et de sécuriser la généralisation.
Aucune donnée d’un projet n’est accessible depuis un autre sans partage explicite.
Chaque publication reste attribuable à une personne et à un instant.
Les URLs, métadonnées et médias sont contrôlés sur le site réellement servi.
Sources et références
OpenAPI Initiative — OpenAPI Specification (consulté le 05/09/2026).
Google Search Central — Bonnes pratiques concernant les liens pour Google (consulté le 05/09/2026).
W3C — Web Content Accessibility Guidelines (WCAG) 2.2 (consulté le 05/09/2026).