Ce que Kirby CMS permet que WordPress ne permettra jamais

WordPress est le CMS le plus utilisé au monde. Il fait tourner plus d'un tiers du web. Sa communauté est immense, son écosystème de plugins couvre pratiquement tous les besoins. Pour un client qui veut gérer un blog ou un site vitrine standard, c'est souvent une réponse raisonnable.

Mais pour un développeur front-end qui conçoit des sites sur-mesure, WordPress est une contrainte permanente. Kirby est une liberté permanente. Ce n'est pas une question de goût. C'est structurel.

Avec WordPress, le HTML est produit en partie par le theme, en partie par les plugins, en partie par Gutenberg. On ne sait jamais exactement ce qui sera rendu. Des classes inutiles, des attributs superflus, des styles inline injectés par des extensions tierces : le markup final est rarement celui qu'on aurait écrit.

Avec Kirby, il n'y a que les templates PHP qu'on a écrits. Le HTML généré est exactement celui prévu. Pas une balise de plus. C'est la condition pour faire de l'intégration pixel-perfect sérieuse.

Dans WordPress, le back-office est standard. On peut le personnaliser avec des plugins (ACF, Carbon Fields...), mais c'est une couche au-dessus d'une structure qui n'a pas été conçue pour ça.

Dans Kirby, les blueprints YAML définissent exactement les champs dont chaque type de page a besoin. Une page de réalisation n'a pas les mêmes champs qu'un article ou une page contact. Le back-office reflète la structure réelle du contenu. Les clients ne voient que ce qui les concerne, dans l'ordre qu'on a décidé, avec les libellés qu'on a choisis.

C'est une ergonomie d'administration que WordPress ne peut pas reproduire sans une complexité considérable.

Kirby stocke tout en fichiers texte. Pas de MySQL, pas de requêtes, pas de migrations à gérer lors d'un déploiement. Le contenu vit dans des dossiers, lisibles par n'importe quel éditeur, versionnable avec Git.

Déployer un site Kirby, c'est copier des fichiers. Sauvegarder un site Kirby, c'est sauvegarder un dossier. Déboguer un problème de contenu, c'est ouvrir un fichier texte. Cette simplicité a une valeur concrète, surtout sur des projets où le client gère lui-même ses mises à jour.

WordPress est la cible numéro un des attaques automatisées sur le web. Pas parce qu'il est mal conçu, mais parce que sa prévalence en fait une cible évidente, et que son écosystème de plugins introduit régulièrement des failles.

Kirby n'a pas de base de données à attaquer, pas de plugin tiers installé par défaut, pas d'interface d'administration accessible sur une URL prévisible. La surface d'attaque est structurellement plus petite. Pour des clients qui hébergent des données sensibles ou qui veulent éviter les mises à jour d'urgence à 3h du matin, c'est un argument réel.

Le meilleur outil est celui qu'on n'entend pas. Kirby ne s'impose pas. Il ne dicte pas une structure de URL, un format de contenu, une façon d'organiser les pages. Il s'adapte au projet.

Après des années à travailler avec les deux, je reviens toujours à la même conclusion : WordPress est une plateforme qu'on configure. Kirby est un outil qu'on programme. Pour un développeur qui veut du sur-mesure vrai, la différence est fondamentale.