Sanity vs Payload, le match des CMS headless
Sanity vs Payload, ce n'est pas un match de fonctionnalités : ce sont deux modèles opposés. Sanity est un CMS hébergé, facturé au siège ; Payload est un logiciel self-hosted, payé en DevOps, c'est-à-dire en temps d'administration. Deux façons de payer, deux rapports à l'infrastructure. Ce comparatif laisse volontairement de côté les pages marketing de sanity.io et de payloadcms.com : il s'appuie sur les grilles tarifaires publiques des deux éditeurs et, pour Payload, sur des retours d'agence publiés. Objectif : montrer ce que chaque modèle change pour une équipe, un budget et un serveur.
En bref
La réponse courte : Sanity si votre contrainte est le temps des équipes. Payload si votre contrainte est la maîtrise de l'infrastructure. Si vous n'avez ni l'une ni l'autre de ces deux douleurs, ne migrez pas cette année.
Sanity et Payload, c'est quoi la différence en une phrase ?
Sanity est un service hébergé : vos contenus vivent dans son infrastructure, vous vous connectez à un studio déjà en ligne, et l'abonnement se paie par utilisateur.
Payload est un logiciel que vous installez : l'application tourne sur votre serveur, avec votre base de données, et aucun éditeur ne vous est facturé.
Dit autrement : Sanity vous loue une cuisine équipée, Payload vous vend les plans, les matériaux et la plomberie. Dans les deux cas, vous décidez de ce qui sort de la cuisine - c'est-à-dire du front-end qui affiche les pages.
Concrètement, les deux sont des cms headless : le contenu est stocké, structuré et servi par API, et c'est votre site (Next.js, Astro, Nuxt) qui vient le chercher pour construire le HTML. Ni l'un ni l'autre ne « fabrique » une page tout seul.
Deux nuances qui comptent au moment de choisir :
- Payload CMS est un cms headless open source sous licence MIT, écrit en Node et TypeScript. Depuis la version 3, il s'installe directement dans une application Next.js : même dépôt, même déploiement, même langage que le site. C'est ce qui explique sa popularité chez les développeurs, et aussi pourquoi la stack Node doit être maîtrisée côté prestataire.
- Sanity CMS ouvre son studio (React), son éditeur de contenu et son langage de requête GROQ, mais garde son backend propriétaire. Le stockage, l'API et le CDN sont un service, pas un logiciel que l'on peut emporter.
C'est la vraie ligne de partage. Avec Payload, un client Postgres suffit pour lire la table des articles. Avec Sanity, tout passe par l'API et par GROQ. Ce n'est pas un défaut - c'est le prix de ne rien administrer. Une fiche dédiée à Sanity CMS comme outil no-code détaille ce que cela change au quotidien pour une équipe non technique.
Combien ça coûte vraiment sur 3 ans ?
Hypothèses de calcul : site vitrine + blog, environ 400 pages, 6 éditeurs, 3 ans, taux de conversion 1 $ ≈ 0,92 €. Les fourchettes Sanity proviennent des grilles publiques de l'éditeur ; celles de Payload, des grilles publiques combinées aux retours d'agence publiés.
Le plan Growth de Sanity coûte 15 $ par siège et par mois, avec un plafond de 50 sièges au-delà duquel l'éditeur bascule en contrat Enterprise sur devis. Bonne nouvelle : les sièges « lecteur » sont gratuits, donc vos commerciaux qui consultent une fiche produit ne coûtent rien. Mauvaise nouvelle : dès que la rédaction s'ouvre à des partenaires ou à des traducteurs, chaque compte pèse.
Côté Payload, la licence est à zéro et l'infrastructure reste modeste : 27 à 95 € par mois selon la charge et le niveau de service du Postgres. Sur trois ans, le total reste sous les 3 500 € dans le scénario le plus large.
Sauf que le coût ne disparaît pas, il change de ligne comptable. Sur Payload, il faut quelqu'un pour appliquer les correctifs, lire les avis de sécurité, tester après une montée de version majeure et restaurer une sauvegarde le jour où ça tourne mal. Les retours d'agence publiés chiffrent cette charge à un à trois jours de développeur par an sur un site tranquille. À 500 € la journée, le calcul donne 80 à 125 € par mois d'équivalent budget.
Le point de bascule se situe autour d'une dizaine d'éditeurs. En dessous, Sanity et Payload coûtent à peu près la même chose : la licence compense l'infrastructure. Au-delà de dix à douze sièges, Sanity grimpe de façon linéaire là où Payload reste plat. À 25 éditeurs, la comparaison donne ≈ 345 €/mois chez Sanity contre ≈ 135 €/mois tout compris chez Payload, maintenance intégrée. C'est le seul argument tarifaire vraiment solide de Payload, et il n'existe qu'à partir d'une certaine taille d'équipe.
Quel CMS choisit-on selon votre situation ?
Équipe éditoriale nombreuse (8 personnes et plus). Sanity convient ici. Le studio est pensé pour plusieurs mains simultanées, la collaboration en temps réel évite les écrasements de brouillon, et personne n'a besoin d'être recruté pour tenir l'infrastructure.
Contenus sensibles ou hébergement encadré. Le modèle de Payload s'impose quand les données doivent rester sur un serveur que vous contrôlez : hébergeur, région, durée de rétention, accès. Pour un industriel, un cabinet médical ou une structure avec des exigences RGPD écrites, ce critère est souvent non négociable. Nuance : Sanity propose des régions de stockage et affiche des engagements de conformité, donc ce critère n'élimine pas Sanity partout - seulement quand les juristes veulent la main sur la base.
Besoin de sortir un site en six semaines. Sanity si personne n'est technique dans l'équipe : le studio est opérationnel le premier jour. Payload si un développeur Next.js est déjà dans la boucle : d'après la documentation de l'éditeur, ajouter un back-office à une application existante se compte en jours, pas en semaines.
Multilingue. Les deux savent le faire, pas de la même manière. Payload gère la localisation dans le schéma : chaque champ déclare ses langues, avec des règles de repli explicites. Sanity s'appuie plutôt sur un plugin de traduction documentaire. Sur un FR/EN simple, la différence ne se voit pas. Sur quatre langues et quarante types de contenus, le modèle de Payload est plus lisible sur un projet multilingue complexe : le schéma rend la liste des langues visible dans le code.
Logique métier et données internes. Le choix se porte sur Payload : accès direct à Postgres, hooks serveur, tâches planifiées, droits d'accès champ par champ. Un annuaire, un portail client ou un catalogue avec règles de prix se construisent plus naturellement sur ce modèle.
Aucune ligne ne colle et le site actuel fonctionne. Alors la bonne décision est souvent de ne rien changer, ou de traiter le vrai problème (contenu, performance, parcours de conversion). Pour un projet qui part de zéro sur le choix de plateforme, le comparatif WordPress vs Webflow répond à cette question-là, pas à celle du CMS headless.
Deux critères suffisent à trancher. Quand la personne qui gère le site aujourd'hui n'est pas développeuse, Sanity convient mieux. Quand elle est développeuse, Payload devient le choix naturel.
Faut-il migrer pour autant ?
Choisir entre Sanity et Payload, c'est 20 % du sujet. Les retours d'agence publiés situent une migration CMS→CMS menée proprement entre 40 et 120 heures de développement. Ce chiffre n'apparaît sur aucune page éditeur, pour une raison évidente : il n'est pas à leur avantage.
Un principe revient dans ces mêmes retours : ne pas cumuler une refonte graphique, un changement d'URL et une migration de CMS le même jour. Trois chantiers simultanés, et l'origine d'une baisse de trafic devient impossible à identifier. Un guide dédié à la migration de Webflow vers Sanity avec Claude Code détaille l'ordre des opérations.
Les pièges à connaître
La latence du Studio Sanity sur les gros documents. Les retours d'utilisateurs publiés signalent qu'au-delà d'environ 900 références dans un même document, la frappe accuse 300 à 500 ms de retard. Sur un article riche en blocs liés, le ressenti devient pénible pour l'éditeur. Contournement : découper les documents, limiter les tableaux de références, passer par des vues filtrées plutôt que par un document fourre-tout.
La faille SQL injection de Payload. La fiche CVE-2026-25544 indique une injection SQL non authentifiée notée CVSS 9,8, touchant les versions antérieures à la 3.73.0 via les champs JSON et richText. Le correctif est simple - monter de version - mais l'épisode rappelle la règle : sur un SaaS hébergé, ce patch est appliqué par l'éditeur ; en self-hosted, il revient aux équipes, comme les retours d'agence publiés le rappellent.
Payload Cloud n'accepte plus de nouveaux projets. D'après la documentation de l'éditeur, les nouvelles inscriptions sont suspendues ; les projets en cours continuent de fonctionner, sans date de réouverture annoncée. La conséquence est mécanique : pour un projet lancé aujourd'hui, le dimensionnement part directement sur un VPS ou un Postgres managé, et l'offre cloud ne peut plus figurer au devis.
La dépendance à GROQ. Il ne s'agit pas d'une critique mais d'un constat technique : écrire une requête de transformation en GROQ fait gagner deux à trois semaines de travail par rapport à un assemblage manuel côté front. Ces requêtes ne se transposent nulle part ailleurs. Le jour où le projet quitte Sanity, ce travail reste derrière. C'est le lock-in de Sanity, et il est réel.
La gouvernance compte autant que les benchmarks. Un CMS open source qui change d'actionnaire, de modèle économique ou de roadmap peut laisser un projet en plan. Ça n'arrive pas qu'aux autres. La question se pose avant de signer, pas après la mise en production.
Le devis de migration sous-évalué. Selon les retours d'agence publiés, c'est le grand classique du métier : une agence annonce 30 heures, il en faut 90. Le périmètre mérite donc d'être vérifié avant signature - import des médias, redirections, formation, garantie post-bascule - et le chiffre de 40 à 120 heures gagne à être détaillé poste par poste.
Sanity ou Payload pour le SEO ?
Ni l'un ni l'autre ne référence votre site. Un CMS stocke et sert du contenu ; le référencement se joue dans le HTML rendu, la structure de liens et la qualité éditoriale. C'est le point que les pages comparatives de Sanity et de Payload passent sous silence, justement parce qu'il ne les avantage pas.
Dans les deux cas, les mêmes champs doivent être modélisés : title, meta description, URL canonique, noindex, image Open Graph, et un mot-clé principal pour que l'équipe sache sur quoi la page travaille. Aucun des deux ne le fait à votre place, aucune extension ne le fera correctement à votre place.
Sur les redirections, Sanity s'appuie en général sur un type de document « redirect » que le front lit à la volée ; Payload sur une collection dédiée que l'on interroge dans le middleware. Comptez une journée de développement dans un cas comme dans l'autre. La différence se joue ailleurs.
Elle se joue sur deux choses :
- Le confort de relecture. Le Presentation tool de Sanity affiche la page dans son contexte pendant la rédaction. Effet constaté : moins de publications hasardeuses, moins de corrections après coup, des pages plus complètes.
- La maîtrise de la performance. Un Payload auto-hébergé sur un VPS parisien avec un vrai cache peut, en théorie, battre un CDN lointain pour une audience française. Cela suppose une configuration que personne ne réalisera à votre place.
Un dernier point reste souvent absent des comparatifs cms headless : le SEO dépend de la personne qui publie. Un CMS qui décourage l'équipe, c'est moins de contenu, moins de maillage, moins de trafic. L'ergonomie du back-office est un sujet SEO.
Verdict
Un comparatif n'a d'intérêt que s'il assume une position sur le fond. Voici la sienne.
- PME française, 3 à 15 éditeurs, pas de développeur Node en interne, contenu qui bouge souvent : Sanity. Le surcoût par siège est un prix juste pour ne gérer aucun serveur et former une équipe en une journée.
- Entreprise avec un développeur ou une agence Next.js, données à garder chez soi, logique métier côté back - annuaire, portail, catalogue : Payload. Le self-hosted devient un avantage et non une corvée.
- Blog et site vitrine qui tournent sur Webflow, équipe satisfaite : ne pas migrer. Moderniser le CMS n'est pas un projet, c'est un coût. Mieux vaut attendre une douleur réelle.
- Site dont dépend le chiffre d'affaires, sans personne capable de patcher un serveur : éviter Payload en solo. Un CMS auto-hébergé sans mainteneur, c'est une dette qui arrive toujours au mauvais moment.
La position par défaut, sans connaître un contexte particulier : Sanity, pour la majorité des PME françaises. Payload prend l'avantage dès qu'un développeur fait partie de l'équipe et que les données doivent rester en interne. Cette conclusion repose sur des grilles tarifaires publiques et des retours d'agence publiés, pas sur un argument commercial.
