Kirby CMS : un site vitrine sans base de données

Un site vitrine de vingt pages n’a pas besoin d’une base de données. Il n’a pas besoin non plus d’un CMS capable de gérer un forum, une boutique et un intranet. Pourtant c’est souvent ce qu’on lui installe, avec les conséquences qui vont avec : des mises à jour à surveiller, une surface d’attaque à défendre, et un back-office dont le client utilisera trois boutons sur quarante.

Kirby part d’une autre idée : le contenu est fait de fichiers.

Ce que « sans base de données » change concrètement

Chaque page est un dossier sur le disque, chaque contenu un fichier texte. Cette décision, en apparence anodine, a des conséquences en chaîne.

La sauvegarde redevient triviale. Sauvegarder le site, c’est copier un dossier. Pas de dump à synchroniser avec les fichiers, pas de risque d’avoir une base d’hier avec des images d’aujourd’hui. Une seule chose à restaurer, donc une restauration qu’on teste vraiment.

Le versionnement devient possible. Le contenu peut vivre dans Git. On voit qui a changé quoi, on revient en arrière sur une phrase, on compare deux états. Essayez d’obtenir ça d’une base de données sans outillage dédié.

La surface d’attaque diminue. Pas de base, pas d’injection SQL. Ce n’est pas une garantie de sécurité absolue — rien ne l’est — mais c’est une catégorie entière de vulnérabilités qui n’existe pas.

Le déploiement se simplifie. Copier des fichiers, c’est tout. Pas de migration de schéma, pas d’ordre à respecter entre code et données.

Le back-office est construit, pas subi

C’est le point que les clients remarquent, et de loin le plus décisif à l’usage. Dans Kirby, l’interface d’administration se décrit : on déclare les champs d’un type de page, et le panneau se construit à partir de cette déclaration.

Un site de menuiserie n’a pas de « type d’article » ni de « catégorie » : il a des réalisations, avec une galerie, un lieu et un type d’ouvrage. On décrit exactement ça, et le client obtient un formulaire qui parle son métier.

La différence est double. Le client n’a pas à traduire son métier dans le vocabulaire d’un CMS généraliste — et il ne peut pas casser la mise en page, parce que les champs qui casseraient la mise en page n’existent pas. Un back-office restreint est un service rendu, pas une limitation.

La performance vient d’ailleurs

On lit souvent que l’absence de base rend le site plus rapide. C’est vrai à la marge, et ce n’est pas le vrai sujet : la lenteur d’un site vitrine vient presque toujours des images et des scripts tiers, pas des requêtes.

Le gain réel est ailleurs : moins de pièces mobiles. Un serveur web, du PHP, des fichiers. Il y a moins de choses à régler, donc moins de choses qui se dérèglent, et le diagnostic prend dix minutes au lieu d’une demi-journée.

Quand je ne le choisis pas

Le choix serait malhonnête si je ne disais pas où il s’arrête.

• Le e-commerce. Un catalogue, des stocks, des commandes, des clients : c’est exactement ce à quoi une base de données sert. Là, j’utilise Prestashop.
• Les très gros volumes de contenu. Des milliers de pages avec du filtrage croisé : le fichier plat n’est plus le bon outil.
• Les contributeurs nombreux et simultanés. Une rédaction entière qui écrit en même temps demande autre chose.
• Une équipe qui connaît déjà autre chose. Si le client a une équipe formée sur un autre CMS, mon confort ne vaut pas leur autonomie.

En résumé

Kirby est un choix de sobriété. Pour un site vitrine d’entreprise — présenter un métier, des réalisations, amener au contact — il donne un back-office sur mesure, une maintenance légère et une sauvegarde qui tient dans une commande. C’est très exactement ce qu’on demande à ce type de site, et rien de plus.

Le luxe, sur ces projets, n’est pas d’avoir plus de fonctionnalités. C’est de ne pas en avoir trop.