Philosophie de MonCMS
Publié le 2026-04-08
MonCMS ne cherche pas à être un CMS spectaculaire. Il cherche à rester compréhensible, portable et durable dans le temps.
La philosophie du projet repose sur quelques choix explicites : contenu éditorial en Markdown, frontend statique et applicatif en Astro, backend en FastAPI, reverse-proxy Traefik déjà présent, SQLite réservée aux données applicatives, et déploiement via Docker Compose. Aucun de ces choix n’est là par effet de mode. Chacun répond à une contrainte précise.
1) Le contenu éditorial reste un fichier, pas un enregistrement opaque
Le point central est simple : un article est un fichier .md dans site/src/content/posts/.
Cela implique plusieurs conséquences concrètes :
- le contenu reste lisible sans application particulière
- la sauvegarde du contenu éditorial est triviale
- l’export n’est pas une fonctionnalité annexe : il est implicite, parce que le contenu est déjà dans un format ouvert
- aucun schéma de base de données ne devient la source de vérité du texte
Ce choix est important politiquement autant que techniquement. Il empêche qu’un futur changement d’outil, d’hébergement ou d’équipe rende les articles difficiles à récupérer.
2) La stack est volontairement découplée
La stack retenue est minimale mais précise :
- Astro pour le site principal et le RSS
- FastAPI pour l’API applicative
- Traefik pour le routage HTTP/HTTPS par domaine
- Docker Compose pour l’exécution et le déploiement
- SQLite pour les données applicatives locales
Le domaine DOMAIN_SITE sert le frontend, les pages et le flux RSS. Le domaine DOMAIN_API sert exclusivement FastAPI. Cette séparation n’est pas décorative.
Elle permet :
- d’éviter d’exposer accidentellement des endpoints applicatifs sur le domaine du site
- de clarifier les responsabilités réseau
- de rendre la topologie plus lisible pour l’exploitation et le débogage
- de garder Traefik dans son rôle strict de proxy HTTP/HTTPS
Traefik ne gère ni SMTP, ni logique métier, ni édition. Il route. C’est justement ce qu’on attend de lui.
3) Astro est choisi pour servir du durable, pas seulement du moderne
Le frontend n’est pas conçu comme une application complexe dépendante d’un runtime serveur permanent. Il est construit en statique, puis servi simplement.
Ce choix justifie plusieurs propriétés utiles :
- les pages éditoriales sont servies comme des fichiers statiques simples
- le RSS est généré sans service supplémentaire dédié
- les applications front JavaScript restent possibles, mais dans un cadre maîtrisé
- la surface d’attaque et la complexité opérationnelle sont réduites
Autrement dit : Astro est ici un outil de publication fiable, pas un prétexte à ajouter de l’infrastructure.
4) FastAPI est réservée à l’applicatif et aux canaux d’entrée
FastAPI a deux roles dans MonCMS.
Le premier est applicatif : exposer des endpoints utiles aux applications front et aux usages métier.
Le second est éditorial, mais uniquement comme canal d’entrée supplémentaire : l’endpoint /publish accepte un body Markdown brut, l’écrit en fichier .md, puis déclenche un rebuild explicite du site.
Le point important est ici le suivant : l’API ne devient pas un CMS opaque. Elle ne remplace pas le fichier. Elle écrit le fichier.
Cette nuance justifie aussi le choix actuel de ne pas imposer un payload JSON structuré pour la publication. Le Markdown brut reste l’entrée la plus simple et la plus cohérente avec le modèle éditorial.
5) SQLite est volontairement limitée aux données applicatives
SQLite est utile, mais elle n’a pas vocation à absorber tout le système.
Elle sert à stocker ce qui relève de l’état applicatif : notes, formulaires, outils, petites fonctions métier. En revanche, elle ne doit pas devenir le dépôt central du contenu éditorial.
Le projet assume aussi un choix de persistance concret : la base est stockée dans api/data/app.db, via un bind mount hôte, pas via un volume Docker nommé.
Pourquoi ce choix ?
- le fichier reste visible directement sur l’hôte
- la sauvegarde et la restauration sont simples
- l’inspection manuelle reste possible sans couche d’abstraction Docker supplémentaire
- cela reste cohérent avec l’idée générale du projet : garder les artefacts essentiels récupérables et lisibles
Le résultat est plus rustique qu’une abstraction complète, mais plus robuste sur le temps long.
6) Le rebuild explicite est un choix de gouvernance
Il n’y a pas de watcher permanent. Il n’y a pas de rebuild automatique en continu. Ce n’est pas un manque, c’est une décision.
Le rebuild peut être déclenché :
- manuellement
- par le script de publication par e-mail
- par l’endpoint
/publish
Ce mode de fonctionnement force à assumer le moment de publication. Il évite les effets de bord silencieux et garde l’opération lisible.
Quand un article entre dans le système, on sait comment il est arrivé et quel mécanisme a été activé ensuite.
Conclusion
MonCMS n’essaie pas de masquer la technique derrière une interface omnipotente. Il essaie au contraire de réduire le nombre de zones opaques.
Markdown pour la vérité éditoriale. Astro pour la publication statique. FastAPI pour l’applicatif et les canaux d’entrée. Traefik pour le routage. SQLite pour les données locales utiles, pas pour tout centraliser.
La justification générale tient en une phrase : chaque composant de la stack doit avoir une responsabilité claire, et aucun composant ne doit capturer inutilement le contenu ou la capacité de le récupérer.
Le résultat attendu est un CMS qui reste exploitable et compréhensible dans plusieurs années, même si l’infrastructure évolue, si les outils changent, ou si l’on doit déplacer l’ensemble vers une autre machine.