Pourquoi ce blog n'a pas de CMS : une table PostgreSQL et une commande

Ce blog que vous lisez n'a ni CMS, ni interface d'administration, ni éditeur en ligne. Publier un article, c'est écrire un fichier Markdown dans notre dépôt git et lancer une commande. Cet article documente ce choix — parce qu'il illustre bien une conviction qui traverse notre travail : la bonne quantité d'outil, c'est celle que l'usage justifie.

Le point de départ : un WordPress pour six articles

L'ancien blog de PYKEngine tournait sur WordPress. Bilan après quelques années : six articles publiés, des mises à jour de sécurité en continu, une base MySQL à sauvegarder, un thème à maintenir — et une interface d'administration utilisée quelques heures par an. WordPress est un excellent outil pour des équipes éditoriales qui publient quotidiennement sans développeur ; il était surdimensionné pour un studio d'ingénierie qui publie quelques articles par mois et vit dans git.

Lors de la refonte de notre site, la question s'est posée : quel CMS pour le remplacer ? La réponse honnête était : aucun.

L'architecture : trois pièces

Des fichiers Markdown versionnés. Chaque article est un fichier avec un en-tête de métadonnées (titre, slug, catégorie, tags), rangé par catégorie dans le dépôt. L'historique éditorial, c'est l'historique git — relecture par pull request comme pour du code.

Une base PostgreSQL dédiée. À la publication, l'article est rendu en HTML, nettoyé, et stocké en base avec ses images. Le site ne lit que la base : pas de rebuild ni de redéploiement pour publier — l'article est en ligne à la seconde. C'est la différence avec un site statique : le contenu vit à chaud, le code reste immuable.

Une CLI de publication. Le pont entre les deux :

# Publier (ou re-publier : la commande fait un upsert par slug)
pnpm article:publish articles/coulisses/mon-article.md

# Dépublier, lister
pnpm article:unpublish mon-article
pnpm article:list

Sous le capot, une centaine de lignes : lecture du frontmatter validé par un schéma strict (un article sans catégorie ou hors taxonomie est refusé à la publication — le garde-fou éditorial est dans le code), rendu Markdown → HTML avec nettoyage systématique, envoi des images en base avec des URLs immuables pour le cache :

const meta = frontmatterSchema.parse(frontmatter); // catégorie obligatoire, registre fermé
const html = renderArticleHtml(markdown); // rendu + sanitization au publish
await upsertArticle(db, meta, markdown, html); // en ligne immédiatement

Un détail d'architecture auquel nous tenons : le HTML est rendu et nettoyé au moment de la publication, pas à chaque visite. Le serveur ne fait que servir — moins de travail à chaque requête, et un invariant de sécurité simple : ce qui est en base est inerte.

Ce que ce choix nous coûte (soyons complets)

Ce système n'a pas d'interface : il faut être à l'aise avec un terminal et git pour publier — pour nous, c'est le quotidien ; pour une équipe marketing autonome, ce serait un blocage, et un CMS headless serait un choix plus honnête. Pas de prévisualisation WYSIWYG non plus (le Markdown et un serveur local en tiennent lieu), pas de planification de publication, pas de gestion de rôles éditoriaux. Chacune de ces limites est réelle ; aucune ne nous concerne à notre échelle. C'est toute la logique : les fonctionnalités qu'on n'a pas sont aussi des mises à jour, des surfaces d'attaque et des sauvegardes qu'on n'a pas.

Ce qu'on en retire pour vos projets

Ce n'est pas « n'utilisez pas de CMS » — plusieurs de nos clients en utilisent, à raison. C'est une méthode de décision : partir de l'usage réel (qui publie, à quelle fréquence, avec quelles compétences) et choisir l'outil le plus simple qui couvre cet usage, en comptant le coût total — maintenance, sécurité, sauvegardes — pas seulement le confort de l'interface. Six articles par an ne justifient pas la même machinerie qu'une rédaction de dix personnes. La bonne question n'est jamais « quel CMS ? » mais « qu'est-ce qui doit être facile, pour qui ? ».