Sovereign CMS : pourquoi j'ai construit mon propre CMS plutôt que prendre WordPress ou Payload

L'article que vous êtes en train de lire n'est pas dans une base de données. C'est un fichier JSON, dans un dossier content/, versionné avec le reste du code de ce site. Pas de MySQL, pas de service tiers, pas d'API externe à interroger pour afficher cette page. Ce choix a un nom : Sovereign CMS, le CMS que j'ai construit et que ce site fait tourner en production, tous les jours.

Pourquoi pas WordPress

WordPress fait le travail pour des millions de sites, mais il traîne avec lui une base de données à maintenir, une surface de sécurité qui grandit avec chaque plugin, et une architecture pensée pour des équipes éditoriales, pas pour un développeur seul qui veut du contrôle total sur son infrastructure. Pour un site personnel qui sert aussi de vitrine technique, c'est plus de complexité que ce dont j'ai besoin.

Pourquoi pas un CMS headless de plus

Les alternatives headless modernes — Payload, Keystatic, Decap — sont solides, et je ne prétends pas avoir réinventé quelque chose de meilleur sur tous les points. Mais la plupart d'entre elles gardent une dépendance : soit une base de données à héberger, soit un service SaaS externe à qui on confie son contenu. Ce que je voulais, c'était zéro dépendance externe. Le contenu du site doit pouvoir survivre à la disparition de n'importe quel service tiers, y compris les miens.

Les décisions de conception

• File-based, sans base de données — chaque page, chaque article de blog est un fichier JSON lisible et modifiable directement.
• Contenu versionné en Git — chaque modification de contenu est un commit. L'historique complet, les rollbacks, les diffs : je les ai gratuitement, avec les outils que j'utilise déjà pour le code.
• Admin protégé — une interface d'administration pour éditer sans toucher au JSON à la main, avec une authentification qui refuse l'accès par défaut si aucun mot de passe n'est configuré.
• Next.js 15 — le même framework, le même déploiement, la même stack que le reste du site. Pas de service séparé à faire tourner.

Ce que ça ne fait pas

Sovereign CMS n'est pas pensé pour une équipe éditoriale de dix personnes qui publie en simultané, ni pour un volume d'écriture massif. Le stockage fichier a ses limites de concurrence que je ne prétends pas avoir résolues comme le ferait une vraie base de données. C'est un CMS pour un builder qui gère son propre contenu, pas un produit pensé pour scaler à des centaines d'utilisateurs.

Pourquoi je ne le vends pas

C'est une question qu'on me pose régulièrement : pourquoi ne pas en faire un produit ? La réponse honnête est que le marché est déjà couvert par des solutions plus matures — Keystatic, Payload, Decap CMS — et que maintenir un produit CMS pour d'autres, seul, a un coût d'entretien que je ne suis pas prêt à porter. Sovereign CMS reste ce qu'il est : une pièce de portfolio intégrée à ce site, la preuve que je peux concevoir et maintenir une infrastructure de bout en bout — pas un produit à vendre de plus.

Le résultat le plus honnête que je puisse vous donner, c'est celui-ci : vous êtes en train de le lire.