Sanity vs Payload : quel CMS headless pour votre PME ?
Sanity vs Payload : quel CMS headless pour votre PME ?
Vous voulez modifier une offre en français, faire relire sa version anglaise et publier les deux sans mobiliser un développeur à chaque correction. Votre équipe technique, elle, veut réutiliser ces contenus dans le site et un espace client. C’est à cette rencontre entre travail éditorial et application que le choix entre Sanity et Payload devient intéressant.
Sanity et Payload sont deux solutions de gestion de contenus structurés. Sanity sépare son service de données, Content Lake, d’un Studio configurable. Payload fonctionne dans une application Next.js dont il faut organiser le déploiement et les dépendances. Le bon choix dépend du parcours de publication et des responsabilités que votre équipe peut réellement prendre en charge.
Un CMS headless sépare le contenu de son affichage
Dans une architecture headless, le CMS conserve les contenus et les rend accessibles à d’autres applications. Le site qui les présente au visiteur constitue une autre couche. Cette séparation permet de réutiliser une fiche de service dans plusieurs interfaces ; elle oblige aussi à concevoir comment une modification devient une page visible.
Si votre besoin est surtout de composer un site vitrine et de transmettre ses demandes commerciales, commencez par le choix entre WordPress et Webflow pour un site connecté. Passer à un CMS headless ajoute des décisions d’intégration : cela doit répondre à un besoin précis, pas à une préférence de développeur.
Sanity et Payload ne déplacent pas les mêmes responsabilités
La documentation de Sanity distingue Content Lake, qui conserve les documents et fournit les moyens de les interroger, du Studio où l’équipe travaille. Le Studio se configure en JavaScript ou TypeScript et peut être hébergé chez Sanity ou ailleurs. Les aperçus et l’édition visuelle font partie des possibilités documentées, mais doivent correspondre à votre site et à son modèle de contenu.
Le service de contenu géré par Sanity ne supprime donc pas le travail d’intégration. Quelqu’un doit définir les fiches, leurs relations, les champs autorisés et le rendu du site. Un responsable marketing ne devrait pas découvrir après signature qu’une nouvelle famille de pages exige une évolution du schéma.
Payload s’intègre à Next.js. Sa documentation de mise en production demande de prévoir, selon le projet, la base de données, le stockage permanent des médias, l’envoi d’emails et la diffusion des contenus. L’auto-hébergement est possible ; il faut alors attribuer l’exploitation à une équipe ou à un prestataire. Avoir accès au code ne garantit ni une sauvegarde restaurable ni une intervention disponible.
La comparaison utile porte sur une configuration et un engagement de service précis. « Sanity sans technique » et « Payload gratuit » masquent tous deux une partie du travail à financer.
Faites publier la même offre dans les deux solutions
Prenons un scénario de décision, pas un résultat client : une PME publie une fiche de prestation avec un prix indicatif, une image, une version anglaise et un lien vers une demande de devis. Le responsable marketing modifie le texte ; une autre personne valide le prix. La page ne doit pas afficher une nouvelle promesse avant cette validation.
Demandez une démonstration sur cette fiche, avec vos contributeurs. Ils doivent pouvoir préparer la modification, comprendre ce qui est encore en brouillon et vérifier le rendu avant publication. Faites ensuite modifier le modèle : ajouter une condition commerciale doit-il passer par un développeur ? Cette évolution ne constitue pas un défaut en soi, mais son délai et son coût doivent être connus.
- Contribution : qui peut modifier le texte, les médias et les éléments commerciaux ?
- Validation : qui autorise la mise en ligne, et comment le contributeur distingue-t-il un contenu enregistré d’un contenu publié ?
- Aperçu : la version présentée correspond-elle réellement à ce que le visiteur verra ?
- Reprise : qui intervient si le contenu est publié dans le CMS mais absent du site ?
Si la responsable marketing voit sa modification dans le Studio mais pas sur le site, elle doit savoir qui appeler et quel état vérifier. C’est ce passage entre contenu enregistré et page réellement publiée que la démonstration doit rendre visible.
En multilingue, décidez ce qui se passe quand une traduction manque
Sanity documente deux approches : traduire certains champs dans un document commun ou utiliser des documents distincts reliés entre eux. La seconde permet de publier les langues indépendamment. Le choix dépend de ce qui doit rester commun et de ce que chaque marché doit pouvoir faire évoluer.
Payload propose une localisation au niveau des champs et des mécanismes de repli vers une autre langue. Un champ anglais manquant peut donc recevoir une valeur de repli selon la configuration. Pour une description commerciale, ce comportement mérite une décision explicite : afficher le français, masquer la page ou attendre la traduction n’a pas la même conséquence pour le visiteur.
Testez une traduction incomplète, pas seulement deux pages terminées. Vérifiez les liens, les médias et les informations commerciales de chaque version. Les règles de publication par langue doivent être confirmées dans la version et la configuration retenues ; elles ne se déduisent pas de la présence d’un sélecteur de langue.
Comparez le coût du parcours complet, pas seulement la licence
Un devis comparable doit séparer la mise en place initiale, les abonnements et usages facturés, l’hébergement des différentes couches, puis la maintenance. Ajoutez les évolutions du modèle éditorial, les tests des mises à jour et l’assistance aux contributeurs. Les tarifs et limites des offres évoluent : faites chiffrer votre nombre d’éditeurs, vos contenus, vos médias et vos usages réels au moment du choix.
Dans Sanity, demandez ce que couvre le service de contenu et ce qui reste à votre intégrateur pour le Studio et le site. Dans Payload, demandez qui assume les dépendances et la remise en service, y compris lorsque l’hébergement est confié à un tiers. Ne comparez pas un abonnement accompagné avec une simple machine à administrer vous-même.
Le référencement ne départage pas automatiquement les deux solutions. Le rendu public doit permettre de retrouver le contenu utile, les liens, les bonnes URL et les indications de langue. Google précise que ses fonctionnalités de recherche avec IA ne demandent ni fichier spécial ni balisage particulier. Un changement de CMS ne prouve donc pas un gain de visibilité.
Choisissez après un pilote éditorial, pas avant
Sanity mérite l’examen lorsque votre équipe souhaite s’appuyer sur un service de contenu géré, avec un Studio adapté à sa façon de travailler. Payload mérite l’examen lorsque l’intégration à une application Next.js et la maîtrise de son déploiement répondent à une contrainte réelle, avec une exploitation financée. Les deux nécessitent une mise en œuvre cohérente ; aucun ne remplace le cadrage.
Avant une migration, exigez une preuve sur une fiche représentative : publication française et anglaise, aperçu, comportement en traduction manquante, retour à une version précédente et restauration testée. Si le site actuel répond déjà au besoin, corrigez d’abord le problème identifié plutôt que de financer un remplacement complet.
Chez Say Digital, ce pilote peut s’inscrire dans le cadrage du projet : observer le travail, concevoir le modèle, tester avec les contributeurs, puis définir les conditions de déploiement et de suivi. Le périmètre et les critères de réception se fixent avant la réalisation. Parlons de votre parcours de publication : qui publie, où le contenu est réutilisé, et ce qui bloque aujourd’hui.
