CMS headless open source : lequel choisir

Trois CMS headless libres rangent le contenu de deux façons, et chacun impose son cadre au site. Strapi est un serveur Node.js à part : il garde les entrées dans une base SQL, les sert par API à n'importe quel front, et réserve la relecture, le SSO et les journaux d'audit à ses offres payantes. TinaCMS écrit le contenu en Markdown ou en JSON dans le dépôt Git, et chaque sauvegarde en production devient un commit, par son service TinaCloud, limité à GitHub, ou par un backend serverless à assembler soi-même. StudioCMS garde une base SQL mais vit dans le projet Astro : il exige Astro 7 et le rendu serveur, et en est à sa version 0.6.

Une base servie par API, ou des fichiers dans le dépôt Git

Strapi sépare le schéma du contenu. Les types se modélisent dans le panneau d'administration, qui écrit chacun dans un schema.json versionné avec le code, et les entrées vont dans la base. Chaque type reçoit une API REST avec filtres, tri, pagination et relations, et le plugin officiel @strapi/plugin-graphql y ajoute GraphQL. Le front ne connaît du CMS que cette API, quel que soit son framework. Le Content-Type Builder ne fonctionne qu'en développement : en production, un nouveau champ passe par le code et un redéploiement.

TinaCMS fait du dépôt la source de vérité. Les collections se déclarent dans tina/config.ts, d'où Tina tire une API GraphQL et des types TypeScript, et la base qui indexe les fichiers n'est, selon la documentation, qu'un « cache éphémère ». En développement, tinacms dev écrit directement dans les fichiers ; en production, un backend reçoit les modifications et les commite. L'historique, les diffs et les retours en arrière passent donc par Git. Avec l'Editorial Workflow de TinaCloud, une sauvegarde ne part plus sur la branche protégée : elle ouvre une branche et une pull request en brouillon.

StudioCMS range le contenu dans une base libSQL, MySQL ou PostgreSQL, comme Strapi, mais ne le sert pas d'abord par API. Les pages Astro le lisent par un module virtuel, studiocms:sdk, et la documentation présente son API REST comme « principalement utilisée en interne ». Aucun autre front qu'Astro n'est documenté, et le projet part de deux constats : aucun CMS ne tire parti de tout ce que permet Astro, et Astro seul demande d'être développeur. Les traductions du contenu n'y sont pas gérées, une demande ouverte depuis mai 2024, quand Strapi fournit l'internationalisation dans son cœur.

Ce que chaque outil impose : framework, base, hébergement

Relevé dans les dépôts et les documentations le 7 octobre 2026.

Strapi documente un minimum d'un cœur, 2 Go de RAM et 8 Go de disque, et en recommande deux, 4 Go et 32 Go. Il ne prend en charge ni MongoDB ni les bases « cloud native » comme Amazon Aurora, et ne publie aucune image Docker officielle : chacun construit la sienne, à la main ou avec l'outil communautaire @strapi-community/dockerize. Le serveur Strapi reste un service de plus à héberger à côté du front.

TinaCMS demande en production un backend qui reçoit les modifications et les commite. TinaCloud le fournit, avec l'index des fichiers et la gestion des comptes, et selon sa FAQ ne s'intègre qu'à GitHub. Le backend auto-hébergé est une fonction API Node.js, à déployer sur un environnement serverless comme Vercel ou Netlify. Il assemble un fournisseur d'authentification (Auth.js, Clerk ou le sien), un adaptateur de base, dont Vercel KV et MongoDB sont les deux officiels, et un fournisseur Git, livré pour GitHub seulement : une autre forge demande d'écrire le sien sur l'interface GitProvider. La FAQ nomme trois fonctions perdues hors de TinaCloud : les médias versionnés dans Git, le changement de branche à la volée et la recherche.

StudioCMS n'a pas de serveur à lui : le tableau de bord, l'authentification et l'API sont servis par le site Astro. Ce site doit tourner en rendu serveur, avec un adaptateur Astro qui gère les routes SSR, l'option site, une base joignable et une clé CMS_ENCRYPTION_KEY, et un hébergement de fichiers statiques ne suffit donc pas. Depuis sa 0.5.0, StudioCMS exige Astro 7, qui demande lui-même Node.js 22.12 ou plus, et il ne tourne ni sous Bun ni sous Deno. Aucune version publiée n'a accepté Astro 6, et la page d'accueil du projet parle encore de « tout projet Astro v5 ».

Où en sont les projets

Strapi publie à peu près une version par semaine : la 5.57.0 du 7 octobre 2026 est la 44e de la branche 5 depuis janvier. Strapi 4 est en fin de vie depuis le 30 avril 2026, et sa dernière version, la 4.26.2 du 9 juin, corrigeait une faille d'exposition de données (CVE-2026-27886). Le passage à la v5 combine un outil de mise à jour, qui applique des codemods, et une reprise manuelle du code touché. Strapi est aussi le plus téléchargé des trois : 258 813 fois sur npm la semaine du 28 septembre 2026, contre 62 778 pour tinacms et 660 pour studiocms.

TinaCMS a publié 39 versions de son paquet principal en 2026, jusqu'à la 3.14.3 du 7 octobre, mais ses ruptures arrivent par les paquets voisins. @tinacms/cli est passé en 3.0.0 le 14 septembre, avec un nouveau type pour le texte riche qui casse le code TypeScript qui comptait sur any, puis en 4.0.0 le 1er octobre. Une v4 se prépare dans le même dépôt sous un nouveau nom npm, @tinacms/tinacms, absent du registre au 7 octobre 2026, et son README place la v3 en mode support, correctifs seulement. Un backend auto-hébergé qui appelle @tinacms/datalayer devra alors passer à un adaptateur Level (MongoDB, SQLite ou Upstash Redis).

StudioCMS est le plus jeune. Sa 0.1.0 est sortie le 15 janvier 2026, après des bêtas publiées depuis septembre 2024, et six mois séparent la 0.4.4 de la 0.5.0. Ses versions mineures cassent : la 0.5.0 abandonne Astro 5, la 0.6.0 retire un champ de l'API des plugins. Sur les 1 700 commits de la branche principale, un développeur en signe 905 et le robot Renovate 573 ; le deuxième contributeur humain en compte 18.

Ce que réservent les offres cloud et entreprise

Strapi est sous MIT à deux conditions, écrites dans son fichier de licence : n'utiliser aucun composant des dossiers ee/, livrés dans le même dépôt sous licence Strapi Enterprise, et n'avoir aucun compte sur Strapi Cloud. L'édition Community, gratuite, garde les API, les rôles et un usage illimité. L'offre Growth, à 45 dollars par mois pour trois sièges puis 15 dollars par siège, ajoute l'aperçu en direct, les Releases, 14 jours d'historique et Strapi AI ; le SSO de l'administration y est une option, à partir de 150 dollars par mois. Les workflows de relecture et les journaux d'audit n'existent que dans l'offre Enterprise, sur devis. Strapi Cloud démarre à 35 dollars par projet et par mois, pour une instance qui se met en veille sans trafic.

TinaCMS est sous Apache-2.0, et sa FAQ précise que tout le CMS, couche de données comprise, est open source. Les formules payantes portent sur TinaCloud, un service hébergé dont le dépôt, cité par le README, n'est pas accessible. La formule gratuite couvre deux utilisateurs ; au-delà, chaque projet se paie à l'année, 290 dollars pour trois utilisateurs, 490 dollars pour cinq, 2 990 dollars pour vingt. La relecture par pull request de l'Editorial Workflow commence à la formule à 490 dollars, et le SSO relève de l'offre Enterprise, sur devis.

StudioCMS est sous MIT, plugins officiels compris, et son site ne propose ni édition payante ni hébergement géré.