Choisir un CMS pour un site Astro : les quatre familles
Git-based, headless SaaS, CMS dédié au statique, ou rien du tout. Ce qui distingue vraiment ces options quand le site est en Astro, et comment trancher sans se tromper.
La question revient à chaque projet Astro dès qu’un client doit pouvoir modifier une page. Les comparatifs qu’on trouve alignent des tableaux de fonctionnalités qui se ressemblent tous. Le choix se joue en réalité sur trois questions, et le reste suit.
Les trois questions qui décident
1. Qui édite ? Un développeur, ou quelqu’un qui ne sait pas ce qu’est une branche. C’est de loin le critère le plus discriminant, et celui qu’on sous-estime le plus.
2. Le site doit-il rester statique ? Si oui, le CMS doit s’effacer au moment du build. Si non, tout devient possible et beaucoup plus cher à exploiter.
3. Combien de sites ? Un site, c’est un abonnement. Vingt sites, c’est un modèle économique, et le prix par projet devient le facteur dominant.
Famille 1 : git-based
Decap, Sveltia, Tina. L’éditeur écrit dans une interface, le CMS commite dans le dépôt.
Pour : gratuit ou presque, le contenu vit dans le dépôt, aucune base de données à exploiter, et l’historique Git est l’historique du contenu.
Contre : votre client hérite d’un compte GitHub et d’un modèle mental qui n’est pas le sien. Le contenu et le code partagent une histoire, donc restaurer un texte veut dire toucher au dépôt. Et sur un parc, chaque site est une configuration de plus à maintenir à la main.
Quand c’est le bon choix : vos éditeurs sont des développeurs, ou vous êtes le seul éditeur.
Note d’écosystème (relevé du 4 juillet 2026) : Sveltia a dépassé Decap en téléchargements npm et avance vite, mais reste sur un mainteneur unique, sans version 1.0 ni offre payante, avec une interface en anglais et japonais. Decap est entretenu a minima. Sur un parc client, la question de la pérennité mérite d’être posée avant celle des fonctionnalités.
Famille 2 : headless SaaS
Sanity, Storyblok, Prismic, DatoCMS, Strapi Cloud. Une API de contenu, un studio d’édition, et vous branchez ce que vous voulez dessus.
Pour : produits matures, éditeurs riches, édition visuelle sérieuse chez plusieurs d’entre eux, et des free tiers généreux qui suffisent largement à un site vitrine.
Contre : le prix. Au relevé du 4 juillet 2026, le plancher payant du marché se situait entre 10 et 18 $ par mois et par projet, avec un désert jusqu’au bloc 49-99 $. Les langues supplémentaires sont presque partout un palier de facturation. Sur vingt sites vitrine, l’addition dépasse souvent ce que vous facturez de maintenance.
Autre limite, moins visible : aucun ne s’occupe de remettre le site en ligne. Ils publient dans leur API ; déclencher le build, suivre le déploiement et dire à l’éditeur « c’est en ligne », c’est votre travail. La plupart des intégrations s’arrêtent à un webhook.
Quand c’est le bon choix : un projet unique, un budget qui l’absorbe, un besoin d’édition visuelle avancée.
Famille 3 : CMS pensés pour le statique
C’est la famille la plus récente, et celle où nous nous rangeons. Le principe commun : le contenu n’est requis qu’au build, et le CMS prend en charge la mise en ligne.
Pour : le site reste statique et sans dépendance runtime, l’éditeur n’a rien à comprendre du dépôt, et le prix par site est adapté à un parc.
Contre : la publication passe par un build, donc une à trois minutes entre le clic et la page en ligne. Ce n’est pas fait pour du contenu qui change toutes les minutes.
Quand c’est le bon choix : plusieurs sites vitrine, des clients non techniques, une exigence de simplicité d’exploitation.
Famille 4 : pas de CMS
À ne pas balayer. Si le contenu bouge trois fois par an et que c’est vous qui l’éditez, des fichiers markdown dans le dépôt sont la bonne réponse. Le meilleur CMS est celui qu’on n’installe pas.
Quand ça se retourne contre vous : le jour où le client attend deux semaines une modification de tarif, et que vous découvrez que ces demandes coûtent plus cher en interruptions qu’un abonnement.
Le tableau de décision
| Situation | Famille |
|---|---|
| Je suis le seul à éditer, contenu rare | Pas de CMS, ou git-based |
| Éditeurs développeurs, un projet | Git-based |
| Un projet, budget confortable, édition visuelle avancée | Headless SaaS |
| Clients non techniques, plusieurs sites | CMS pensé pour le statique |
| Contenu qui change à la minute | Rendu serveur, aucune de ces familles |
Deux critères qu’on oublie systématiquement
La sortie. Avant de choisir, demandez comment on récupère tout le contenu si vous partez, et sous quel format. Un export en JSON propriétaire n’est pas une sortie. Un export en markdown et JSON au format des content collections, si.
Ce qui se passe quand le CMS tombe. Sur un site statique bien architecturé, la réponse doit être « rien, le site continue de tourner et un build passe encore ». Si la réponse est « le site tombe aussi », vous avez introduit une dépendance dont vous n’aviez pas besoin.
Et Menestrel là-dedans
Nous sommes dans la troisième famille, dédiés à Astro et à rien d’autre. Le contenu part vers le site au build, jamais à la requête d’un visiteur, et la publication va jusqu’à la mise en ligne effective. Le plan gratuit couvre un site complet avec deux langues, sans carte bancaire.
Si votre site n’est pas sur Astro, nous ne sommes pas le bon outil, et il vaut mieux le dire tout de suite.