Ce qu'un CMS multi-sites doit vraiment savoir faire
Gérer vingt sites clients, ce n'est pas gérer un site vingt fois. Les sept choses qui cassent à l'échelle, et les questions à poser à un éditeur avant d'y engager un parc.
La communication des CMS s’adresse à une entreprise qui possède un site web. Les fonctionnalités, les tarifs, l’accueil : tout suppose un produit unique avec une équipe éditoriale derrière.
Une agence a une forme complètement différente. Vingt sites, quarante clients qui ne touchent chacun qu’au leur, aucune équipe éditoriale partagée, et un forfait de maintenance par site qui décide si l’ensemble est rentable. Presque rien de ce qui est pensé pour la première forme ne survit au contact de la seconde.
Voici ce qui casse, dans l’ordre où ça casse.
1. Un prix qui se multiplie
Le premier mur, et le plus brutal.
Presque tous les CMS hébergés facturent par projet, par espace ou par siège. Sur un site, c’est une ligne dans un budget. Sur vingt, c’est le budget.
Concrètement, au relevé du 8 août 2026 : Contentful passe d’une offre gratuite à 300 € par mois sans rien entre les deux. Strapi Cloud démarre à 35 $ par mois et par projet, donc vingt sites font vingt abonnements. Sanity facture 15 $ par siège, et le nombre de sièges d’une agence grandit avec chaque client. L’offre gratuite de Storyblok autorise un siège, puis Growth est à 99 $ par mois avec 20 $ par langue supplémentaire.
Aucune de ces sociétés n’est déraisonnable. Elles sont tarifées pour leur vrai client, qui est une entreprise avec un site et un budget. Vous n’êtes pas ce client.
La question à poser : combien ça coûte à vingt sites, avec deux éditeurs et deux langues chacun ? Faites le calcul avant la démonstration, pas après.
2. Un cloisonnement qui cloisonne réellement
Votre client doit voir son site et rien d’autre. Pas « voir une liste où le sien est surligné » : rien d’autre. Ni l’existence de vos autres clients, ni leurs noms dans une liste déroulante, ni un 403 qui confirme qu’un autre projet existe.
Ça paraît évident et c’est régulièrement mal fait. Le signe qui ne trompe pas est le code d’erreur : si demander une ressource qui ne vous appartient pas renvoie 403 Interdit, le système vient de vous confirmer que cette ressource existe. Sur un parc de clients, c’est une fuite d’information avec des conséquences commerciales : votre client apprend avec qui d’autre vous travaillez.
La question à poser : que se passe-t-il si je demande la ressource d’un autre client par son identifiant ? La bonne réponse est 404, partout, sans exception.
3. Un modèle de contenu qu’on répète sans le recopier
Vingt sites vitrine partagent peut-être quatre-vingts pour cent de leur structure : une page d’accueil, des prestations, un bloc de contact, des horaires, quelques champs de référencement. Les vingt pour cent restants font la particularité de chaque client.
Les systèmes qui obligent à reconstruire le modèle à la main à chaque fois vous punissent deux fois : à la mise en place, puis chaque fois que vous améliorez le motif commun et devez l’appliquer sur vingt sites manuellement.
Le fait que le modèle vive dans du code plutôt que dans une interface compte ici plus qu’ailleurs. Un fichier TypeScript se copie, se compare, se relit, s’extrait dans un paquet partagé et s’importe. Un modèle cliqué dans une interface d’administration ne se recrée qu’en cliquant à nouveau.
La question à poser : puis-je mettre mon modèle de contenu sous gestion de version, et en partager des morceaux entre projets ?
4. Des sièges qui ne sont pas un poste de coût
Le nombre d’éditeurs d’une agence croît d’une façon que celui d’un éditeur de logiciel ne connaît pas. Chaque client représente une ou deux personnes. La personne qui met à jour la carte l’été en fait une de plus. L’associé du client qui se connecte deux fois par an, encore une.
La facturation au siège transforme chacune de ces personnes en ligne de facture, ce qui vous pousse vers la chose à ne jamais faire : partager un identifiant entre plusieurs humains. Votre journal d’activité ne vaut alors plus rien, et le jour où un client demande qui a supprimé sa page de tarifs, vous ne pouvez pas répondre.
La question à poser : combien coûte un éditeur de plus ? Si la réponse n’est pas zéro, faites le calcul à quarante éditeurs.
5. Un déploiement qui survit à l’hétérogénéité
Les sites clients ne sont pas uniformes. L’un est sur Vercel parce que l’agence précédente l’y a mis. Un autre est sur Netlify. Un troisième est sur un hébergement mutualisé avec du FTP parce que c’est ce que le beau-frère du client lui a vendu. Un quatrième est sur votre propre serveur.
Un CMS qui suppose une seule histoire de déploiement vous oblige à uniformiser votre parc, et ce chantier-là, personne ne le paie.
Ce que vous voulez, c’est une cible de déploiement par site : un hook, un déclencheur d’intégration continue, un agent sur un serveur, ce dont ce site-là a besoin, configuré une fois puis invisible.
Et surtout, un état réel. Un outil qui affiche « publié » alors qu’il veut dire « ligne écrite et webhook envoyé » est pire que celui qui ne dit rien, parce que votre client le croit. Une construction qui échoue en silence, c’est ainsi qu’un client découvre trois semaines plus tard que ses nouveaux tarifs n’ont jamais été en ligne.
La question à poser : après que mon éditeur a cliqué sur Publier, qu’est-ce qui lui dit que la page est réellement servie ?
6. Une facturation qu’on peut refacturer ou absorber
Deux modèles coexistent dans les agences et les deux méritent d’être pris en charge.
Soit le client paie directement, et il lui faut alors sa propre facture avec ses propres mentions de TVA. Soit vous absorbez le coût dans un forfait de maintenance, et vous voulez une facture unique pour tout le parc plutôt que vingt prélèvements à rapprocher.
La question à poser : puis-je être facturé une seule fois pour tout le parc, et puis-je mettre ma propre marque devant le client ?
7. Une sortie qui vaut pour vingt sites d’un coup
La question que toute agence devrait poser et que presque aucune ne pose : qu’arrive-t-il au parc si cet éditeur double ses prix, change de cap ou ferme ?
Pour un site, une migration est un week-end désagréable. Pour vingt, c’est un chantier que vous ne pouvez pas financer, ce qui veut dire que vous paierez le nouveau prix. Cette asymétrie est précisément pourquoi les tarifs par projet ont tendance à monter une fois qu’un éditeur sait ses clients captifs.
La protection, c’est un vrai export, et « vrai » a un sens précis : du contenu dans un format que votre outil suivant sait lire, pas un export JSON maison qui contient techniquement vos données. Pour un parc Astro, ça veut dire du markdown et du JSON à la forme des content collections, produit par une commande que vous pouvez lancer aujourd’hui sans demander à personne.
La question à poser : montrez-moi l’export, maintenant, sur l’offre gratuite, et regardons ce qui en sort.
Le coût qui n’est sur aucune liste de fonctionnalités
Sur un parc, le coût qui finit par dominer n’est aucun des précédents. C’est le temps de support.
Chaque outil que vos clients touchent produit un flux de petites interruptions : un mot de passe oublié, une photo qui ne passe pas parce que c’est un HEIC d’iPhone, une page qui « ne s’est pas enregistrée » parce qu’ils ont fermé l’onglet trop vite, une modification invisible parce que la construction a échoué en silence.
Chacune coûte dix minutes et un changement de contexte. Vingt sites avec deux éditeurs chacun, à une interruption par éditeur et par trimestre, font environ cent soixante interruptions par an. Cela représente plusieurs semaines de votre attention, et n’apparaît sur aucun tableau comparatif.
Le levier qui réduit ce flux n’est pas les fonctionnalités, c’est l’inverse : moins d’écrans, moins de réglages, moins d’états dans lesquels un éditeur peut se mettre. Chaque option que vous exposez à un client non technique est une question qu’il pourra vous poser plus tard. C’est pour ça que notre éditeur n’a aucun écran de réglages, et que la seule fenêtre qu’il rencontre est la confirmation avant une suppression.
Ce que nous avons construit, et ce que nous avons laissé de côté
Menestrel est façonné par ces contraintes, parce qu’il a commencé comme outil interne pour exactement ce problème.
La facturation est par site, avec sièges et langues illimités dès le premier plan payant : 3 € HT par mois et par site, ou un plan Studio à 15 € HT couvrant dix sites. Ajouter un éditeur ne coûte rien, volontairement.
Le cloisonnement répond 404 partout, vérifié par une suite de tests dédiée qui parcourt chaque point d’entrée avec la session d’un autre client et exige un 404.
Le modèle de contenu est du TypeScript dans votre dépôt, donc il se compare, se relit et se copie comme n’importe quel code.
Les cibles de déploiement sont par site : Vercel, Netlify, Cloudflare Pages, GitHub Actions ou un agent sur votre serveur. L’éditeur voit l’état réel du déploiement, jusqu’à « en ligne ».
Et le plan Studio porte la marque blanche : votre domaine, votre logo, et des emails partant de votre propre domaine d’envoi.
Ce que nous ne faisons pas, et qu’il faut peser : pas de constructeur de pages visuel, pas d’API de contenu à la requête, pas d’auto-hébergement, et Astro uniquement. La publication passe par un build, donc une à trois minutes entre le clic et la page en ligne. Si l’une de ces contraintes est rédhibitoire, nous sommes le mauvais outil et les comparatifs disent lequel ne l’est pas.
Le résumé honnête
Le problème du multi-sites est surtout un problème d’économie déguisé en problème technique. Les fonctionnalités nécessaires n’ont rien d’exotique ; ce qui casse, c’est que tout est tarifé et pensé pour quelqu’un qui a un seul site.
Avant d’engager un parc, faites le calcul à vingt sites, demandez ce que renvoie une requête vers un autre client, et demandez ce que voit l’éditeur après avoir publié. Ces trois réponses vous apprendront plus que n’importe quel tableau de fonctionnalités.