6 août 2026

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 bien plus cher à faire tourner.

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 : les CMS qui écrivent dans Git

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 à administrer, et l’historique Git est l’historique du contenu.

Contre : votre client hérite d’un compte GitHub et d’une façon de penser qui n’est pas la sienne. Le contenu et le code partagent le même historique, donc rétablir un texte oblige à toucher au dépôt. Et sur un parc, chaque site ajoute une configuration à tenir à la main.

Quand c’est le bon choix : vos éditeurs sont des développeurs, ou vous êtes le seul éditeur.

Un point sur l’écosystème, relevé le 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 : les headless en SaaS

Sanity, Storyblok, Prismic, DatoCMS, Strapi Cloud. Une API de contenu, un studio d’édition, et vous branchez ce que vous voulez dessus.

Pour : des produits mûrs, des interfaces d’édition riches, une vraie édition visuelle chez plusieurs d’entre eux, et des offres gratuites généreuses 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 ne dépend de rien une fois construit, l’éditeur n’a rien à savoir du dépôt, et le prix par site convient à 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, et l’envie que la maintenance reste légère.

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

La question sous les quatre familles

Avant le tableau, il y a une question qui décide plus que les familles elles-mêmes : le contenu de votre client, est-ce un ensemble de pages, ou un ensemble d’objets ?

Un site vitrine, ce sont des pages. Une accueil, une page prestations, une page contact, peut-être quelques réalisations. La structure est dessinée une fois et bouge rarement, et le client modifie du texte et des photos à l’intérieur.

Un catalogue, ce sont des objets. Des produits avec des variantes, des séances avec des dates, des membres avec des droits. La structure est relationnelle, le volume grandit, et les requêtes comptent.

Presque toutes les mauvaises décisions de CMS que j’ai vues venaient d’une mauvaise réponse à cette question. Un site vitrine forcé dans un back-end relationnel hérite d’une interface que personne ne sait utiliser. Un catalogue produits forcé dans des fichiers plats hérite d’une construction de six minutes et de filtres écrits à la main dont vous êtes désormais propriétaire.

Répondez-y d’abord, à voix haute, avant de comparer quoi que ce soit.

Ce que chaque famille fait à votre construction

Une dimension qui apparaît rarement dans les comparatifs et qui compte au quotidien.

Les CMS git ont un contenu local, donc la construction lit sur disque : rapide, déterministe, hors ligne. Le coût, c’est que les images vivent dans le dépôt et sont traitées pendant la construction, ce qui est ce qui ralentit réellement ces constructions à mesure que le site vieillit.

Les headless en SaaS font appeler une API par la construction. En général ça va, parfois c’est lent, et ça dépend d’un tiers en bonne santé au moment où vous déployez. Demandez ce qu’il advient de votre déploiement du vendredi si leur page d’état passe à l’orange.

Les CMS pensés pour le statique varient, et la distinction mérite d’être creusée : la construction appelle-t-elle l’API vivante du CMS, ou lit-elle un artefact figé sur un CDN ? Le second est strictement plus robuste, parce qu’une panne de l’éditeur cesse d’avoir de l’importance.

Pas de CMS, ce sont des fichiers, la réponse la plus rapide possible.

Le coût qui décide, et qui n’est sur aucun comparatif

Sur un parc, le coût qui finit par dominer n’est aucun des précédents. C’est le temps de support.

Chaque outil que vos clients touchent produit un flux de petites interruptions : un mot de passe oublié, une photo HEIC d’iPhone qui ne passe pas, une modification qui « ne s’est pas enregistrée », une page qui n’est pas en ligne parce qu’une construction a échoué sans rien dire.

Vingt sites avec deux éditeurs chacun, à une interruption par éditeur et par trimestre, font environ cent soixante interruptions par an, à dix minutes plus un changement de contexte chacune. Cela fait plusieurs semaines de travail, et ça n’apparaît sur aucun tableau.

Le levier qui réduit ce flux n’est pas les fonctionnalités, c’est l’inverse : moins d’écrans, moins de réglages, moins d’états qu’un éditeur peut atteindre. Chaque option exposée à un client non technique est une question qu’il pourra vous poser plus tard.

Ce qui recadre toute la comparaison : la famille qui gagne pour du travail client n’est en général pas la plus puissante, c’est celle qui produit le moins de questions.

Deux critères qu’on oublie systématiquement

La porte de sortie. Avant de choisir, demandez comment on récupère tout le contenu le jour où l’on part, et sous quel format. Un export en JSON maison n’est pas une porte de 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 conçu, la réponse doit être « rien, le site continue de tourner et un build aboutit encore ». Si la réponse est « le site tombe aussi », vous avez ajouté 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.

Les limites à peser avant de prendre le plan gratuit au sérieux : la publication passe par une construction, donc une à trois minutes entre le clic et la page en ligne. Il n’y a pas de constructeur de pages visuel, donc un client qui compose des mises en page sera plus heureux sur Storyblok. Il n’y a pas d’API de contenu à la requête. Et il n’existe pas de version auto-hébergée, donc un client qui exige le contenu sur sa propre infrastructure a besoin d’un CMS git ou de Strapi.

Le détail par éditeur, avec ce que chacun fait mieux que nous, est dans les comparatifs.