corpusctl vs WordPress : ce que vous gagnez, et ce que vous abandonnez

Cet article traite des cas où cela cesse d'être vrai.

#WordPress headless est un aménagement a posteriori, et ça se voit

WordPress peut exposer le contenu via l'API REST ou WPGraphQL, et beaucoup d'équipes le mettent en œuvre avec succès. Mais il vaut la peine d'être précis sur ce que vous faites tourner.

Le rôle premier de WordPress est de rendre une page : interroger la base de données, exécuter le thème, déclencher les hooks, renvoyer du HTML. Passer au headless signifie conserver cette machinerie, la démarrer à chaque requête, puis jeter sa sortie au profit d'une réponse JSON que vous assemblez séparément.

Vous finissez par exploiter deux systèmes dans un seul processus. L'admin est un moteur de rendu de pages. L'API est une couche par-dessus un moteur de rendu de pages. Les extensions — qui sont la raison pour laquelle vous avez choisi WordPress — ont été écrites pour le moteur de rendu de pages, et une extension qui ajoute un champ à l'éditeur ne l'ajoute pas nécessairement à l'API.

corpusctl ne rend jamais de page. Il n'y a pas de couche de thème, pas de hiérarchie de gabarits, pas d'ordre de hooks à raisonner. Le client de lecture est l'interface principale, pas un ajout rapporté.

#Ce qui se passe réellement quand quelqu'un lit votre article

WordPress : la requête atteint PHP, PHP interroge MySQL, les extensions s'exécutent, le thème fait le rendu. Vous placez ensuite une extension de cache devant, puis peut-être un CDN devant celle-ci, et vous passez un temps réel sur l'invalidation du cache — parce que la page est calculée et que le cache est une copie d'un calcul qui pourrait changer à tout moment.

corpusctl : la publication déclenche le pipeline de compilation. Le contenu est validé, rendu, et écrit dans un fichier immuable, adressé par hachage dans le stockage objet ; le manifeste est rafraîchi. Le client d'un visiteur résout le slug vers un fragment de manifeste en local, puis récupère cette adresse depuis le cache de périphérie nginx.

Comme l'adresse est un hachage de contenu, la même adresse ne peut jamais renvoyer un contenu différent — elle est donc mise en cache pendant trente jours sans stratégie d'invalidation. Publier écrit une nouvelle adresse. Il n'y a rien à purger.

Deux requêtes HTTP, toutes deux depuis le cache. Aucune n'atteint l'API. Aucune n'atteint PostgreSQL.

Le chiffre qui en découle : le trafic des visiteurs ne charge pas du tout votre chemin d'écriture. Un éditeur qui enregistre un brouillon pendant un pic de trafic n'est pas en concurrence avec le pic.

#La surface d'extensions est aussi la surface d'attaque

L'écosystème d'extensions est la plus grande force de WordPress, et c'est la même phrase que son plus grand risque opérationnel. Chaque extension est du code tiers qui s'exécute dans votre processus avec un accès à la base de données. Un site avec trente extensions a trente flux de mises à jour et trente CVE potentielles, et l'extension qui casse est généralement celle que personne ne se souvient d'avoir installée.

corpusctl n'a pas de place de marché d'extensions — ce qui est une perte réelle, listée honnêtement ci-dessous. Ce qu'il a à la place, c'est un système de modules avec une règle imposée par la CI :

• Chaque fonctionnalité est un module : médias, recherche, webhooks, SEO, GraphQL, import, analytique.
• Les modules ne peuvent pas s'importer les uns les autres. Un registre de services et un bus d'événements sont les seuls canaux entre eux, et pnpm check:isolation fait échouer la compilation si cette règle est enfreinte.
• Retirer un module ne peut pas casser la compilation. C'est tout l'intérêt de la règle.

Et désactiver une fonctionnalité ne détruit rien : disabled conserve les données et reprend à la réactivation, uninstalled les efface avec une double confirmation, et une rétrogradation de forfait ne met jamais les modules qu'à l'état disabled.

#Plusieurs sites, un seul panneau

WordPress Multisite existe et fonctionne, avec les réserves que les opérateurs connaissent : des extensions qui se comportent mal à travers le réseau, une base de données partagée, une mise à niveau qui tombe sur chaque site en même temps, et un modèle de permissions qui n'a pas été conçu pour « cet éditeur travaille sur les marques une et trois mais ne doit pas voir la marque deux ».

corpusctl est multilocataire dans le cœur, à côté de l'authentification et du registre de modules :

• Un seul panneau, un nombre illimité d'espaces.
• Un utilisateur porte un rôle distinct par espace.
• Isolation assurée par la sécurité au niveau des lignes de PostgreSQL — dans la base de données, sous la couche applicative où vit un filtre oublié.

L'argument en faveur de la RLS est étroit : l'isolation au niveau applicatif tient jusqu'à la seule requête qui a sauté le filtre, et cette requête finit toujours par être écrite, par quelqu'un de pressé, dans un module que personne ne relit attentivement. La RLS rend la fuite impossible en dessous de l'erreur.

#Contenu structuré, et à qui appartient le design

Le contenu WordPress est un article ou une page, étendu avec des champs personnalisés et une extension pour les gérer. Ça marche, et le modèle trahit ses origines.

Dans corpusctl, il n'y a pas de types de contenu intégrés. Vous les définissez depuis le panneau ou l'API, et les champs portent des rôles — title, slug, body — de sorte que le système sait quel champ est le titre sans dépendre du nom que vous lui avez donné. La localisation est par champ. Chaque enregistrement est versionné, les anciennes versions sont restaurables, et la publication peut être programmée.

Côté interface, les moteurs de rendu de blocs sont livrés avec zéro style par défaut. Pas une seule ligne de CSS. Chaque type de bloc est surchargeable, et un type de bloc inconnu est ignoré proprement plutôt que de lever une erreur. L'arbre de rendu du cœur est indépendant du framework ; les adaptateurs React, Vue et Next.js s'y posent par-dessus en couches minces.

Comparez cela à un thème WordPress, qui est une décision de design dont vous héritez puis que vous surchargez.

#Trois bonnes raisons de rester sur WordPress

Le recrutement. Vous pouvez trouver quelqu'un qui connaît WordPress dans n'importe quelle ville, à n'importe quel budget, la semaine prochaine. Vous ne pouvez pas faire cela pour corpusctl et prétendre le contraire serait ridicule.

L'écosystème. Formulaires, réservations, adhésions, e-commerce, outillage SEO, utilitaires de migration — une extension existe, elle est éprouvée au combat, et elle coûte 59 $. Construire l'équivalent face à une API est un projet.

C'est gratuit. Le cœur de WordPress ne coûte rien et n'a jamais rien coûté. Si le budget est la contrainte déterminante, cela clôt la discussion.

Ajoutez-en une quatrième, moins confortable : corpusctl est jeune. Le SSO et un SLA contractuel figurent sur la feuille de route, ce qui est la façon polie de dire qu'ils n'existent pas encore. Il n'y a pas de place de marché ni de CDN mondial — le cache de périphérie est mono-région. Si votre liste de contrôle d'achat comporte l'un de ces éléments, cette comparaison s'arrête ici.

#Le résumé honnête

Restez sur WordPress si une seule équipe édite un seul site, si l'écosystème travaille réellement pour vous, ou si le budget en décide.

Passez à corpusctl si vous gérez plusieurs projets, plusieurs interfaces, ou une surface d'extensions que vous ne pouvez plus auditer — et que vous voulez que le chemin de lecture cesse d'être un problème de cache.

Vous migrez ? Le module d'import lit un export WXR de WordPress : articles, pages, étiquettes et médias. Les rôles de champ sont mis en correspondance, et le corps est converti vers le modèle de blocs. Prévoyez un temps réel pour tout ce qu'une extension faisait — cette logique ne s'exporte pas.

Voir l'architecture → · Lire la documentation →

corpusctl vs Directus : une plateforme de contenu face à une surcouche de base de données