6 juin 2026

CMS flat-file en 2026 : quand des fichiers valent mieux qu'une base

Des fichiers markdown avec du frontmatter font encore tourner une bonne part des petits sites. Ce que le modèle réussit, les quatre endroits où il casse, et comment savoir de quel côté se trouve votre projet.

Un CMS flat-file range le contenu dans des fichiers, sur un disque. Pas de Postgres, pas de MySQL, pas d’API de contenu : un dossier de markdown, du frontmatter en YAML, parfois un index JSON. C’est la plus vieille idée de l’édition web et elle revient sans cesse, parce que pour toute une catégorie de sites elle est simplement juste.

Elle est aussi régulièrement conseillée pour des projets auxquels elle nuit. Voici comment faire la différence.

Ce que le modèle vous apporte réellement

Rien à administrer. Pas de processus de base de données à mettre à jour, pas de pool de connexions à dimensionner, pas de tâche de sauvegarde à surveiller, pas de restauration à tester à trois heures du matin. Votre contenu, ce sont des fichiers. cp -r est une stratégie de sauvegarde complète, et elle fonctionne.

Le versionnement est offert. Mettez le dossier dans Git et vous obtenez un historique par modification, des différences qu’un humain peut lire, des branches, et la possibilité de voir exactement ce qui a changé entre deux versions d’une page. Aucune liste de fonctionnalités ne rivalisera jamais avec git diff pour l’auditabilité.

Le contenu survit à l’outil. C’est l’avantage le plus sous-estimé. Un fichier markdown avec du frontmatter sera lisible dans cinquante ans, par n’importe quel éditeur, sans logiciel particulier. Tout CMS hébergé finit par augmenter ses prix, changer de cap ou fermer, et la question « comment on récupère notre contenu » arrive toujours. Avec des fichiers plats, il n’y a rien à récupérer : vous l’avez déjà.

Les constructions sont rapides et déterministes. Lire un dossier est la source de contenu la moins chère qui existe. Pas de réseau, pas de limitation de débit, pas d’API lente cet après-midi.

Ça se grep. Trouver toutes les pages qui mentionnent un nom de produit sur deux cents fichiers, en une commande. Essayez sur un CMS headless.

Les quatre endroits où ça casse

1. Celui qui édite, ce n’est pas vous

C’est le point principal, et ce n’est pas une objection technique.

Du contenu en fichiers plats s’édite soit dans un éditeur de code, ce qui suppose de connaître le markdown et d’avoir le dépôt cloné, soit par une interface web posée par-dessus, ce qui nous ramène directement à la question du CMS git et de son compte GitHub.

Un commerçant qui met à jour ses horaires depuis son téléphone un dimanche soir ne peut faire ni l’un ni l’autre. Ce n’est pas un défaut d’intelligence, c’est une inadéquation : le modèle suppose un éditeur à l’aise avec des fichiers, et la plupart des éditeurs ne le sont pas.

2. Les médias ne veulent pas être des fichiers

Du texte dans Git, c’est idéal. Des images dans Git, c’est un problème au ralenti.

Un client envoie une photo directement depuis son téléphone : quatre mégaoctets, quatre mille pixels de large, dans le mauvais sens. Elle part dans le dépôt. Le mois suivant il la remplace, et les deux versions restent dans l’historique pour toujours. Un site vitrine peut accumuler plusieurs centaines de mégaoctets d’images mortes en un an, et chaque développeur qui clone télécharge le tout.

Puis le vrai travail commence : cette photo doit être redimensionnée, convertie en AVIF et WebP, servie par un CDN, et accompagnée d’un texte alternatif que quelqu’un doit écrire. Une installation flat-file ne vous donne rien de tout ça. Vous branchez une chaîne de traitement d’images, et c’est désormais une chose que vous entretenez.

3. Les relations et les requêtes

Les fichiers plats n’ont pas de jointures. « Toutes les prestations proposées dans une ville donnée, triées par prix, qui ont une photo » est un filtre sur un tableau que vous assemblez en mémoire au moment de la construction. Ça marche très bien à deux cents entrées. À cinq mille, ça devient un coût de build et un bout de code dont vous êtes maintenant propriétaire.

Tout ce qui est réellement relationnel, un catalogue produits avec des variantes, un système de réservation, un annuaire de membres avec des droits, réclame une base. Le forcer dans des fichiers est une décision qu’on regrette au quatrième mois.

4. L’édition à plusieurs

Deux personnes qui modifient le même fichier, c’est un conflit de fusion. Et un conflit de fusion montré à un éditeur non technique, c’est la fin de sa volonté d’utiliser l’outil.

En pratique, ça compte moins qu’on ne le dit, parce que deux personnes éditent rarement la même page d’un petit site au même moment. Mais quand ça arrive, le modèle flat-file n’a aucune bonne réponse, et toutes celles qu’il a supposent d’expliquer Git.

Où passe la frontière

Le motif est clair : les fichiers plats sont excellents jusqu’à ce qu’une personne non technique doive écrire dedans, et jusqu’à ce que les images représentent un vrai volume. Ces deux choses arrivent ensemble, et elles arrivent dès que vous avez des clients.

La réponse « il suffit d’utiliser Git LFS »

Dès qu’on soulève le problème des images, quelqu’un propose Git LFS. Ça mérite une réponse, parce que ça résout moins qu’il n’y paraît.

LFS remplace les fichiers binaires de votre historique par des pointeurs, et stocke les octets réels sur un serveur à part. Votre dépôt reste léger, ce qui était l’objectif. En échange, vous héritez d’un quota de stockage à surveiller chez votre hébergeur, d’un quota de bande passante que les clones de CI consomment vite, d’une dépendance que chaque intervenant doit installer avant de pouvoir cloner, et d’un mode de panne où le clone réussit mais les images manquent.

Surtout, ça ne touche pas au vrai problème. La photo de quatre mégapixels fait toujours quatre mégapixels. Elle doit toujours être redimensionnée, convertie, et servie par un CDN. LFS déplace l’endroit où vivent les octets, il ne les transforme pas en bons octets.

Si les images comptent dans votre contenu, et sur un site vitrine c’est toujours le cas, elles réclament une chaîne de traitement plutôt qu’une astuce de stockage.

Ce que le flat-file coûte la deuxième année

Les trois premiers mois d’un projet flat-file sont très agréables. Les coûts arrivent plus tard, et autant les nommer pour pouvoir les chiffrer.

La configuration dérive du contenu. Votre collection a un champ prix. Un client demande un prix « à partir de » et un prix « jusqu’à ». Vous modifiez le schéma à la main, migrez les fichiers existants à la main, et espérez ne pas en avoir oublié. Il n’y a pas d’histoire de migration, parce qu’il n’y a pas de système qui sache quelle était la forme précédente.

La construction ralentit sans que vous le voyiez. Lire des fichiers est rapide. Lire des fichiers, puis redimensionner chaque image, puis générer les déclinaisons, ne l’est pas. Sur un site à deux cents photos, ça transforme une construction de quatre secondes en une de quatre-vingt-dix, et personne ne remarque le jour où c’est arrivé.

Faire monter un collègue prend un après-midi. La connaissance du fonctionnement du contenu de ce site-là vit dans un fichier de configuration et dans votre tête. Avec vingt sites configurés légèrement différemment sur trois ans, ça fait vingt petits savoirs oraux.

Aucun de ces points n’est fatal. Tous sont réels, et aucun n’apparaît dans le tableau comparatif au moment de choisir.

L’hybride qui marche vraiment

Il existe une troisième voie, dont on parle moins qu’elle ne le mérite, et c’est celle sur laquelle nous avons construit.

Gardez le schéma dans des fichiers. Votre modèle de contenu, déclaré en TypeScript dans votre dépôt, versionné, relu en demande de fusion, comparable.

Sortez le contenu des fichiers. Mettez-le derrière une interface qu’une personne non technique peut utiliser, avec une vraie gestion des médias, et rendez-le sous forme de fichiers dès qu’on le demande.

Puis réconciliez les deux au moment de la construction : le CMS fige l’état publié dans un instantané immuable, et votre build lit cet instantané exactement comme il lirait un dossier de markdown. Du point de vue d’Astro, rien n’a changé. getCollection() fonctionne, le typage fonctionne, et la construction reste statique, sans dépendance à l’exécution.

Concrètement, avec Menestrel, le modèle vit dans cms.config.ts :

import { collection, defineConfig, fields } from '@menestrel/fields';

export default defineConfig({
  project: 'atelier-morel',
  locales: { default: 'fr', others: ['en'] },
  collections: {
    services: collection({
      label: { fr: 'Prestations', en: 'Services' },
      slugFrom: 'title',
      fields: {
        title: fields.text({ required: true, localized: true }),
        summary: fields.textarea({ localized: true }),
        price: fields.number({ unit: '€' }),
        photo: fields.image(),
      },
    }),
  },
});

Ce fichier passe en revue comme du code. Le client ne le voit jamais. Ce qu’il voit, lui, c’est un formulaire de quatre champs et un bouton Publier.

Ce qu’on perd en quittant le flat-file pur

Autant être franc, l’échange est réel.

Vous ajoutez une dépendance que vous n’aviez pas. Un service hébergé, c’est une société qui peut augmenter ses prix ou disparaître. Notre réponse tient dans l’export : une commande, sur tous les plans y compris le gratuit, qui produit du markdown et du JSON au format des content collections, exactement la forme que vous auriez eue en flat-file. C’est la seule réponse qui vaille quelque chose, et vous devriez l’exiger de tout CMS hébergé que vous envisagez.

Vous payez. Trois euros par mois et par site. Les fichiers plats sont gratuits.

La publication passe par un build. Lire des fichiers locaux est instantané, un instantané plus une reconstruction prend une à trois minutes. Si votre contenu change à la minute, ce modèle est mauvais pour vous et le rendu serveur est le bon.

Comment trancher

Écrivez qui édite, à quelle fréquence, et combien de photos cette personne enverra dans l’année.

Si la réponse est « moi, de temps en temps, aucune », prenez des fichiers plats et arrêtez de lire des articles sur les CMS. Si la réponse est « mon client, tous les mois, des dizaines », le modèle flat-file tiendra environ six mois puis commencera à vous coûter en temps de support et en poids de dépôt.

Si vous êtes entre les deux, le comparatif des CMS git détaille ce terrain intermédiaire, y compris les cas où les outils gratuits restent le meilleur choix.