Headless CMS : Payload, Sanity, Strapi, comment choisir

Payload, Sanity et Strapi résolvent le même problème avec trois modèles différents. Payload et Strapi s'installent chez vous, avec vos données dans votre base ; Sanity est un service hébergé où vos contenus vivent chez l'éditeur. Payload est écrit en TypeScript et peut s'exécuter dans la même application Next.js ; Strapi est un service séparé en Node ; Sanity fournit un éditeur en React et une API. Le critère qui décide est la propriété des données et la réversibilité, pas la liste des fonctions.

Les trois modèles, en une phrase chacun

Payload. Auto-hébergé, TypeScript de bout en bout, avec MongoDB ou PostgreSQL. Sa particularité : il s'installe dans une application Next.js et non à côté, ce qui permet au site de lire la base directement, sans passer par HTTP.

Sanity. Service hébergé. Les contenus vivent dans l'infrastructure de l'éditeur, l'interface d'édition est une application React que vous personnalisez et déployez. Facturation à l'usage, avec des paliers.

Strapi. Auto-hébergé, Node et JavaScript, avec plusieurs bases relationnelles. Le plus ancien des trois dans cette catégorie, avec une communauté large. Une offre hébergée existe en parallèle de l'auto-hébergement.

Le critère qui décide : où vivent vos contenus

C'est la première question, et elle passe avant les fonctionnalités.

Chez vous. Payload et Strapi écrivent dans une base que vous hébergez. Vous sauvegardez, vous exportez, vous migrez quand vous voulez. Vous assumez aussi l'hébergement, les sauvegardes et les mises à jour.

Chez l'éditeur. Sanity héberge vos données. Vous gagnez l'absence d'infrastructure et une disponibilité que vous n'auriez pas seul. Vous acceptez une dépendance : les données s'exportent, mais elles vivent ailleurs, et le modèle de facturation peut évoluer.

Aucun des deux modèles n'est meilleur en soi. Ce qui est nécessaire, c'est de choisir en connaissance de cause plutôt que sur une comparaison de fonctionnalités.

Le coût réel

Payload et Strapi. Le logiciel est ouvert. Vous payez l'hébergement de l'application et de la base, plus le temps de maintenance. Sur un site d'entreprise, cela reste modeste et surtout prévisible : le coût ne varie pas avec le trafic ni avec le nombre d'éditeurs.

Sanity. Un niveau gratuit généreux, puis une facturation liée à l'usage : nombre d'utilisateurs, volume de documents, requêtes API, bande passante. Sur un site à trafic modéré, cela reste faible. Sur un site à fort trafic ou avec beaucoup d'éditeurs, la facture devient une ligne budgétaire à surveiller.

Le point à vérifier avant de s'engager : ce qui déclenche le passage au palier supérieur, et de combien.

L'expérience d'édition

C'est ce que votre équipe utilisera tous les jours, et c'est le critère qu'on oublie de tester.

Sanity a l'éditeur le plus abouti et le plus personnalisable, avec une édition collaborative en temps réel. C'est aussi celui qui demande le plus de travail de mise en place, parce que l'interface est une application à construire.

Payload produit une administration complète à partir de la définition des collections, en TypeScript. L'interface est sobre et cohérente, les champs sont typés, et l'administration se traduit, y compris en français seul si on le souhaite. Les brouillons, les versions et l'enregistrement automatique sont natifs.

Strapi a une interface de construction de modèles accessible sans écrire de code, ce qui est un avantage réel pour une équipe qui veut ajouter un champ sans développeur. En contrepartie, le modèle vit dans l'interface autant que dans le code, ce qui complique le passage d'un environnement à l'autre.

Ce qui fait pencher en pratique

Prenez Payload si votre site est en Next.js et que vous voulez une seule application à déployer, un typage strict de bout en bout, et vos données chez vous. C'est notre choix par défaut, et nous devons dire pourquoi : ce site tourne dessus. Le CMS s'exécute dans la même application que le site, qui lit la base directement, sans requête HTTP ni jeton d'API. Sur un site où chaque page est prérendue, cela supprime une couche entière.

Prenez Sanity si vous avez plusieurs sites ou applications à alimenter depuis une même source, une équipe éditoriale qui travaille à plusieurs sur les mêmes documents, et pas d'envie d'héberger quoi que ce soit.

Prenez Strapi si votre équipe est en JavaScript plutôt qu'en TypeScript, si vous voulez pouvoir modifier le modèle de données depuis une interface, et si vous alimentez plusieurs applications qui ne sont pas toutes en React.

Ce qu'aucun des trois ne fait bien

Il faut le dire, parce que c'est la source de déception la plus fréquente.

La composition libre de pages. Un client habitué à Elementor s'attend à déplacer des blocs et à voir le résultat. Un CMS découplé propose des champs et des blocs définis à l'avance, et la mise en page appartient au site. C'est un choix de conception, et il faut l'annoncer au cadrage.

La prévisualisation exacte. Elle existe sur les trois, elle demande une mise en place et elle n'est jamais aussi immédiate qu'un éditeur intégré au site.

Le remplacement d'un développeur. Ajouter un champ, un type de contenu ou une règle demande d'intervenir dans le code sur Payload, moins sur Strapi. Ce n'est pas un outil qu'une équipe marketing fait évoluer seule.

Questions fréquentes

Un CMS découplé est-il plus compliqué que WordPress ?

Pour publier un article, non : l'expérience est comparable, parfois meilleure parce que les champs sont conçus pour votre site. Pour modifier la structure du site, oui : cela demande un développeur là où WordPress permettait d'installer une extension. C'est un déplacement de la complexité, pas une augmentation.

Peut-on migrer d'un headless CMS à un autre ?

Oui, et c'est plus simple qu'une migration depuis WordPress, parce que les contenus sont structurés et exportables en JSON. Ce qui ne se transporte pas, c'est le code du site, qui interroge une API spécifique. Comptez la réécriture de la couche de lecture, pas celle des contenus.

Faut-il un CMS pour un site de vingt pages ?

Pas nécessairement. Si les contenus changent quelques fois par an et que la personne qui les modifie sait éditer un fichier, les garder dans le dépôt est plus simple et plus robuste. Le CMS devient utile dès qu'une personne non technique doit publier régulièrement.

Ces outils gèrent-ils les médias et les images ?

Les trois gèrent le téléversement et les déclinaisons. Sanity inclut un service de transformation d'images performant. Payload et Strapi produisent les déclinaisons à l'enregistrement et demandent un stockage persistant, ce qui est un point d'attention en hébergement conteneurisé : sans volume persistant, chaque déploiement efface les fichiers importés.

Pour choisir

Posez trois questions dans cet ordre : qui publie et à quelle fréquence, où doivent vivre les données, et qui interviendra sur le modèle dans deux ans. Les fonctionnalités se ressemblent, les réponses à ces trois questions non. Le contexte plus large du choix technique est traité dans notre article sur Next.js pour un site vitrine, et la migration depuis WordPress dans celui sur la migration vers Next.js.