Un CMS git, c'est quoi exactement, et quand faut-il en prendre un
Decap, Sveltia, Keystatic et Tina écrivent tous dans votre dépôt. Comment ça marche vraiment, ce que ça coûte à votre client, et le moment où le modèle cesse d'être rentable.
Demandez un conseil de CMS sur n’importe quel forum de sites statiques, et quelqu’un répondra « prends un CMS git ». C’est un bon conseil à peu près une fois sur deux. L’autre fois, ça refile discrètement à votre client un problème qu’il ne sait pas résoudre. Autant comprendre le modèle avant d’y engager un projet.
L’idée en un paragraphe
Un CMS git n’a pas de base de données. L’éditeur ouvre une interface web, remplit un formulaire, enregistre, et le CMS écrit un fichier dans votre dépôt Git en passant par l’API de la forge. Votre contenu est un fichier markdown avec du frontmatter, posé à côté de vos composants. Votre intégration continue voit arriver un commit et reconstruit le site.
C’est toute l’architecture. Pas d’API de contenu, pas de serveur à faire tourner, pas de données à sauvegarder séparément, rien à payer. Pour toute une catégorie de projets, c’est quasiment parfait.
Ce qui se passe vraiment quand quelqu’un enregistre
Les détails comptent, parce que c’est là que se logent les frottements.
L’authentification. Le CMS a besoin du droit d’écrire dans votre dépôt. Ce droit vient forcément de quelque part, et ce quelque part est le compte de votre éditeur, ou un service intermédiaire qui agit en son nom. Decap s’est longtemps appuyé sur Netlify Identity, puis sur une application OAuth que vous hébergez. Sveltia authentifie directement l’éditeur auprès de GitHub ou GitLab. Keystatic sait tourner en local sans authentification, ou contre GitHub pour le mode hébergé.
Quel que soit le chemin, la conséquence est la même : votre éditeur se retrouve avec un compte sur une plateforme de développeurs, et un écran lui demandant d’autoriser une application à écrire dans un dépôt de code. Pour un développeur, c’est une formalité de deux secondes. Pour une fleuriste, c’est un moment de vraie perplexité, et souvent un coup de téléphone.
L’écriture. L’enregistrement devient un ou plusieurs commits sur une branche. Certaines configurations committent directement sur la branche principale, d’autres ouvrent une demande de fusion pour qu’un humain relise avant publication. Excellente idée sur un site de documentation, absurde quand un client change ses horaires.
Les médias. Les images partent dans le dépôt aussi, sauf configuration d’un stockage externe. C’est la partie qu’on sous-estime le plus. Un client qui envoie des photos depuis son téléphone pousse des JPEG de douze mégapixels, et ils restent dans l’historique Git pour toujours. Le dépôt d’un site vitrine peut atteindre plusieurs centaines de mégaoctets en un an d’usage ordinaire, et Git n’oublie rien : chaque clone télécharge chaque version de chaque photo jamais envoyée.
La publication. Un commit déclenche votre intégration continue. Ce qui se passe ensuite se joue entre vous et vos journaux de build. Rien dans le CMS ne sait si la construction a réussi, si le déploiement est parti, ni si la page que l’éditeur vient de modifier est réellement servie. L’éditeur enregistre puis, de son point de vue, attend quelque chose d’indéterminé.
Là où le modèle gagne vraiment
Soyons justes, ces outils sont bons et gratuits.
C’est vous qui éditez. Si vous rédigez vous-même, committer par un formulaire vaut mieux que n’importe quel service hébergé : pas de compte, pas d’abonnement, pas de tiers, et votre contenu est versionné avec votre code. Pour un blog personnel ou une documentation, c’est la bonne réponse et tout le reste est du superflu.
Le contenu doit rester dans le dépôt. Certains clients l’exigent, certains audits aussi. Si « le contenu est dans Git, sous notre contrôle, et repart avec nous » est une exigence contractuelle ferme, la discussion s’arrête là.
Vos éditeurs sont techniques. Une équipe de développeurs qui entretient une documentation ne butera jamais sur le compte GitHub, comprendra le circuit de relecture, et appréciera même que la relecture de contenu ressemble à celle du code.
Le budget est nul et doit le rester. Rien ne bat le gratuit.
Là où ça cesse d’être rentable
Le problème du compte GitHub se multiplie. Un client, une fois, c’est un appel au support. Vingt clients, c’est une catégorie récurrente d’appels, et elle arrive au pire moment : le client essaie de corriger une faute sur sa page d’accueil, il est déjà agacé, et la réponse contient les mots « double authentification ».
Le contenu et le code partagent un historique. Ça paraît élégant jusqu’au jour où il faut retrouver la grille tarifaire du mois dernier, et où vous faites de l’archéologie dans un dépôt qui contient aussi quinze jours de vos propres remaniements. Pire : l’erreur d’un client et une fusion ratée de développeur cohabitent au même endroit et peuvent entrer en conflit. Nous gardons le contenu hors du dépôt exprès : le schéma est du code et mérite une relecture, le texte du client n’en est pas et n’en demande pas.
Chaque site est une configuration tenue à la main. Un fichier par dépôt, décrivant chaque champ de chaque collection, en YAML ou en JavaScript. Changez la forme d’une collection et vous l’éditez à la main. Multipliez par vingt sites, ajoutez les ruptures de compatibilité de chaque version majeure. C’est la part qui grignote la marge d’une agence sans qu’on la voie : pas un gros coût visible, juste une taxe permanente sur chaque projet.
Personne ne boucle la boucle. L’éditeur enregistre, le commit arrive, la construction tourne, et si elle échoue, le site du client continue de servir l’ancienne page pendant qu’il croit avoir publié. Il l’apprend par un client à lui. Vous l’apprenez par un appel.
Un mot sur l’état des outils
Chiffres relevés le 4 juillet 2026, à revérifier avant d’y engager un client.
Decap (ex-Netlify CMS) est le vétéran, entretenu a minima : les versions sont rares, la liste de tickets est longue, et la communauté est largement passée à autre chose.
Sveltia est le successeur énergique. Il a dépassé Decap en téléchargements npm et avance vite. Il repose aussi sur un mainteneur unique, sans version 1.0, sans offre payante, avec une interface disponible seulement en anglais et en japonais. Ce dernier point l’élimine pour un client francophone, indépendamment de tout le reste.
Keystatic est le plus récent, porté par l’équipe de Thinkmill, et techniquement le plus proche de ce que nous faisons : schéma en TypeScript, contenu typé, vraie intégration Astro.
Tina est à part : git en dessous, mais avec une offre hébergée payante et une édition visuelle réellement réussie.
Rien de tout cela n’est un reproche. C’est le cycle de vie normal et sain d’outils open source. C’est simplement une question à poser franchement avant que vingt sites clients ne dépendent des soirées libres d’un seul mainteneur.
La décision, dite simplement
Une seule question : qui édite, et combien de sites ?
| Qui édite | Combien de sites | Réponse |
|---|---|---|
| Vous | Peu importe | Un CMS git, ou pas de CMS du tout |
| Des développeurs | Un ou deux | Un CMS git |
| Des clients | Un | Un CMS git marche, avec des appels au support |
| Des clients | Plus d’une poignée | Le modèle vous facture en support et en maintenance |
La dernière ligne est tout le propos. L’outil est gratuit, mais un outil gratuit se paie en autre chose. Avec des CMS git sur un parc, vous payez en frictions d’accueil, en fichiers de configuration tenus à la main, et en appels reçus quand une construction échoue en silence.
Ce que nous faisons autrement, et ce que nous abandonnons
Menestrel garde le contenu hors de votre dépôt, dans une base, et c’est la plus grande différence de philosophie. Le schéma, lui, reste dans votre dépôt en TypeScript, donc dans la revue de code et l’historique Git comme le reste du projet. Le contenu, non, parce que le texte d’un client n’a rien à faire dans une base de code.
Votre client se connecte avec une adresse email. Pas de plateforme de développeurs, pas d’écran d’autorisation, pas de double authentification à installer sur un compte qu’il utilisera quatre fois par an.
Et la publication va jusqu’au bout : le clic fige un instantané immuable, déclenche la reconstruction chez votre hébergeur, et suit le déploiement jusqu’à ce que la page soit réellement servie. L’éditeur voit « en ligne », pas « enregistré ».
Ce que nous abandonnons en échange est réel et mérite d’être dit. Nous ne sommes pas gratuits : trois euros par mois et par site. Votre contenu n’est pas dans votre dépôt, même s’il s’exporte en une commande en markdown et JSON au format des content collections, sur tous les plans y compris le gratuit. Et nous ne prenons en charge qu’Astro.
Si vous êtes déjà sur Decap ou Sveltia avec un site Astro, c’est la migration la plus simple que nous sachions faire : votre contenu est déjà du markdown dans des content collections. menestrel import les lit directement, images comprises, et construit le schéma à partir de ce qu’il trouve.
La version longue de cette comparaison, avec ce que chaque outil fait mieux, est sur la page comparative des CMS git.