Créer un CMS moderne sans réinventer le Web
Les nouvelles technologies Web sont passionnantes. De nouveaux frameworks, modèles de rendu, systèmes de construction et couches d'abstraction résolvent régulièrement de vrais problèmes.
Mais toutes les nouvelles applications n'ont pas besoin d'une nouvelle architecture d'application.
WebBlocks CMS est parti d'une question assez simple :
Jusqu'où un CMS moderne peut-il aller si nous continuons à utiliser des technologies Web familières où elles fonctionnent déjà bien ?
Cela signifie PHP et Laravel pour l'application. Une base de données relationnelle pour le contenu structuré. HTML pour le balisage. CSS pour la présentation. JavaScript où le comportement du navigateur nécessite réellement JavaScript.
Aucune de ces idées n’est nouvelle.
C'est intentionnel.
WebBlocks CMS n'est pas une tentative de réinventer MVC, d'inventer des blocs, de remplacer Laravel ou d'introduire une autre architecture frontale. Il s'agit d'une tentative de créer un CMS moderne et performant tout en gardant l'application sous-jacente compréhensible et sous le contrôle du développeur.
Et de plus en plus, cela signifie également rendre le même CMS structuré accessible en toute sécurité aux outils d'IA et d'automatisation.
Un CMS qui rejoint votre application Laravel
Une hypothèse courante concernant les CMS est que le CMS est l’application.
Vous l'installez, construisez tout dans son monde, suivez ses conventions de routage, utilisez son modèle d'extension et adaptez le reste de votre projet autour de lui.
WebBlocks adopte une approche différente.
Il est distribué sous forme de package Composer et peut être installé dans une application Laravel que vous possédez déjà.
L'application Laravel reste l'application.
Il continue de posséder des éléments tels que :
- authentification
- configuration de la base de données
- files d’attente
- courrier électronique
- déploiement
- routes de l’application
- infrastructure
- logique métier propre au domaine
WebBlocks ajoute la couche de gestion de contenu : pages, mises en page, blocs, médias, navigation, localisation, révisions, flux de publication et l'espace de travail /webadmin.
L'installation reste volontairement familière :
composer require fklavyenet/webblocks-cms
suivi de php artisan webblocks:install.
Il n'est pas nécessaire de créer une deuxième application frontale simplement parce que le projet a désormais besoin d'un contenu modifiable.
Votre produit Laravel et votre site Web peuvent vivre ensemble
Cela devient particulièrement utile lorsque le site Web n'est qu'une partie d'une application plus vaste.
Imaginez que vous disposez déjà de :
- un produit SaaS
- un portail client
- une demande de réservation
- un système d'entreprise interne
- une plateforme d'adhésion
- une application Laravel liée au commerce électronique
- ou simplement un projet Laravel avec une logique métier personnalisée substantielle
Le produit lui-même fonctionne peut-être déjà parfaitement bien.
Ce dont vous avez besoin, c'est d'un moyen pour les éditeurs de gérer la partie publique : la page d'accueil, les pages de produits, la documentation, les pages de destination, le contenu d'aide, les pages juridiques, les pages de campagne ou tout autre contenu éditorial.
Une solution consiste à ajouter une autre application.
Un CMS distinct. Une interface distincte. Peut-être un autre cadre, un autre processus de déploiement et une autre frontière d'intégration entre le produit et le site Web.
WebBlocks peut à la place devenir le site Web facultatif et la couche de contenu de l'application Laravel existante.
La logique du produit reste à sa place.
Dans Laravel.
Le CMS gère les parties orientées contenu.
C'est à cela que sert le modèle de coexistence .
WebBlocks peut également fonctionner comme CMS principal pour un site Web conventionnel. Le point important est que cela n’oblige pas tous les projets Laravel à adopter la même architecture.
Il peut également restituer le site Web public
WebBlocks ne se limite pas à agir comme une base de données de contenu headless.
Il peut gérer et afficher lui-même le site Web public.
Les pages ont de véritables chemins publics tels que :
/features/contact/docs/internal-content-api
Le moteur de rendu public fonctionne à partir du même modèle structuré Page → Mise en page → Emplacement → Modèle de bloc que les éditeurs gèrent dans le CMS.
Cela signifie qu'une application Laravel peut contenir à la fois des routes d'application et des pages publiques gérées par le CMS sans introduire un autre environnement d'exécution frontal uniquement pour la diffusion de contenu.
Le package CMS lui-même ne nécessite pas Node, npm, Vite ou un framework frontend distinct.
Cela ne signifie pas que JavaScript est interdit.
Cela signifie que JavaScript est utilisé lorsque quelque chose nécessite réellement JavaScript plutôt que de devenir une condition préalable au rendu du site Web.
Le même principe s'applique tout au long du projet :
Utilisez chaque technologie là où elle apporte quelque chose d'utile.
Page → Mise en page → Slot → Bloc n’est pas une nouvelle invention
Les systèmes de contenu basés sur des blocs existent depuis de nombreuses années.
Drupal possède des régions et des blocs. D'autres produits CMS ont leurs propres versions de sections, composants, modules, widgets et contenus réutilisables.
WebBlocks ne prétend pas avoir inventé ce concept.
Son modèle de contenu est volontairement compréhensible :
Page → Mise en page → Emplacement → Block
Une page sélectionne une mise en page.
La présentation définit des zones nommées.
Ces emplacements contiennent des blocs.
Les blocs contiennent du contenu structuré et peuvent eux-mêmes prendre en charge des structures imbriquées, le cas échéant.
La valeur n'est pas que les mots soient nouveaux.
La valeur est qu'un éditeur, un développeur Laravel et un outil d'automatisation peuvent tous raisonner sur la même structure explicite.
Il n'est pas nécessaire qu'il y ait un modèle d'application frontale masquée entre le CMS et la page rendue.
Le contenu réutilisable devrait être normal
Les en-têtes, pieds de page, barres latérales, appels à l'action et autres structures répétées ne doivent pas avoir à être reconstruits sur chaque page.
WebBlocks utilise Shared Slots pour cela.
Encore une fois, le contenu réutilisable n'est pas présenté comme une invention révolutionnaire du CMS. C’est quelque chose qu’un CMS pratique devrait offrir.
Mais le contenu réutilisable introduit également un problème éditorial important : la modification du contenu partagé peut affecter plusieurs pages simultanément.
C'est pourquoi les Shared Slots participent à leurs propres workflows de contenu et de révision contrôlés au lieu d'être traités comme des fragments globaux invisibles.
La réutilisation est utile.
La réutilisation réglementée est plus sûre.
La publication n'est pas qu'un simple interrupteur marche/arrêt
Un CMS devient plus intéressant lorsque plusieurs personnes — ou plusieurs types d'acteurs — peuvent modifier le contenu.
WebBlocks sépare l'état de la page de la publication de blocs plutôt que de supposer silencieusement que la publication d'une page doit rendre public chaque bloc non publié.
Les pages peuvent passer d'un état éditorial à l'autre.
Revisions fournit des instantanés de sécurité au niveau de la page.
Le contenu partagé possède son propre historique de révision.
La publication peut indiquer explicitement si les blocs appartenant à une page doivent également devenir publics.
Ceci est important pour les équipes éditoriales humaines.
Cela devient encore plus important une fois que l'automatisation et l'IA entrent dans le flux de travail.
Le multisite et la localisation font partie du modèle de contenu
Une installation WebBlocks peut gérer des sites, domaines et langues distincts tout en gardant la propriété du site explicite.
La localisation ne consiste pas simplement à « dupliquer la page et à la traduire ».
Le contenu, les chemins et les données SEO peuvent être localisés tandis que la structure de la page révisée reste compréhensible.
Cela devient utile pour les organisations qui gèrent plusieurs sites de produits, sites régionaux ou propriétés multilingues mais ne souhaitent pas une installation CMS distincte pour chacun.
Encore une fois, cela ne veut pas dire que le multisite ou la localisation sont de nouveaux concepts.
Il s'agit de responsabilités CMS établies.
Le but est de les fournir sans obliger l'application Laravel à abandonner le contrôle de son architecture.
Le média appartient également au CMS
Le contenu éditorial est bien plus que du texte.
WebBlocks inclut la gestion des médias et des variantes d'images afin que les médias puissent participer au même environnement de publication structuré que les pages et les blocs.
Combiné avec la navigation, la recherche, les révisions, les sauvegardes, le transfert de site et la publication contrôlée, l'intention est de couvrir les responsabilités opérationnelles normales attendues d'un CMS plutôt que de démontrer un petit prototype d'éditeur de blocs.
Cette distinction est importante.
Un éditeur de blocs est une fonctionnalité.
Un CMS doit également gérer le cycle de vie du contenu.
Ensuite, l'IA change le problème
C'est là que l'architecture conventionnelle devient particulièrement intéressante.
De nombreux produits ajoutent actuellement l'IA en plaçant une zone de texte quelque part dans l'interface d'administration et en la connectant à un modèle.
Cela peut être utile, mais ce n'est pas la direction explorée par WebBlocks.
La question la plus intéressante est :
Que se passe-t-il si un outil d'IA peut comprendre et faire fonctionner le CMS actuel en toute sécurité ?
WebBlocks expose les capacités structurées du CMS via son Internal Content API.
Une IA ou un outil opérateur fiable peut inspecter l'installation réelle plutôt que de deviner comment fonctionne le CMS.
Il peut découvrir les sites, paramètres régionaux, mises en page, types de blocs et contrats de contenu disponibles.
Il peut inspecter le contenu structuré existant.
Il peut préparer un plan de page entier.
Il peut valider ce plan avant de modifier le contenu.
Il peut créer ou modifier un brouillon de contenu.
Et la publication reste une fonctionnalité distincte nécessitant une autorisation explicite.
Cette distinction est importante.
L'IA n'a pas besoin de supprimer l'interface d'administration.
Il n'est pas nécessaire de simuler les clics de souris.
Il n'est pas nécessaire d'inventer le HTML et d'espérer que le CMS l'accepte.
Il peut fonctionner avec le même modèle de contenu structuré que celui compris par le CMS lui-même.
L'accès à l'IA ne signifie pas nécessairement un accès illimité
Donner à un outil d'IA l'accès à un CMS soulève une question évidente :
Qu'est-il permis de faire ?
Le Internal Content API est délibérément limité aux autorisations.
La validation du contenu et l'application du contenu sont des opérations distinctes.
L'application du contenu est d'abord une ébauche.
La publication nécessite une fonctionnalité content.publish distincte.
L'API rejette les opérations en dehors de ses contrats définis plutôt que de traiter l'automatisation comme un administrateur jouissant d'une liberté illimitée.
L'intention n'est pas :
« Laissez l'IA contrôler le site Web. »
Il est plus proche de :
« Laissez les outils fiables effectuer des opérations CMS bien définies dans le même type de limites que celles que nous attendons des autres acteurs applicatifs. »
Cela crée des possibilités intéressantes.
Un outil d'IA pourrait préparer une nouvelle page de destination tout en laissant la décision finale de publication à un éditeur.
Il peut mettre à jour les brouillons de sections sélectionnés sans remplacer la page entière.
Il pourrait comprendre quelles structures de blocs sont prises en charge par l'installation réelle avant de proposer du contenu.
Il pourrait fonctionner sur un site multilingue tout en respectant les limites du site et des paramètres régionaux.
Et comme il s'agit de fonctionnalités CMS plutôt que d'une intégration d'IA spécifique au fournisseur, le cœur du CMS ne doit pas nécessairement dépendre d'un seul fournisseur de modèles.
Conventionnel ne signifie pas statique
Utiliser des technologies établies ne signifie pas rejeter de nouvelles fonctionnalités.
Cela peut impliquer de placer ces fonctionnalités sur une couche différente.
HTML ne devient pas obsolète car une IA a aidé à créer le contenu.
Laravel n'a pas besoin de devenir une application JavaScript car un éditeur souhaite des blocs interactifs.
Une base de données relationnelle ne devient pas inadaptée car un outil d'automatisation écrit du contenu structuré via une API.
Le rendu côté serveur n'empêche pas les flux de travail éditoriaux modernes.
Et une application Laravel conventionnelle peut toujours exposer des contrats lisibles par machine suffisamment sophistiqués pour que les outils d'IA puissent fonctionner en toute sécurité.
Cette combinaison est l'expérience derrière WebBlocks CMS.
Ce que WebBlocks n'essaie pas de prouver
WebBlocks n'essaie pas de prouver que :
- MVC est nouveau
- les applications monolithiques sont nouvelles
- les blocs sont nouveaux
- les régions réutilisables sont nouvelles
- le rendu côté serveur est nouveau
- les workflows CMS sont nouveaux
Ce n’est clairement pas le cas.
Le projet ne prétend pas non plus que les frameworks frontaux, les architectures sans tête ou les applications lourdes en JavaScript sont intrinsèquement erronés.
Ils résolvent des problèmes réels et constituent le bon choix pour de nombreuses applications.
La question plus précise est de savoir si cela devrait constituer une exigence automatique pour chaque projet Laravel soutenu par un CMS.
La réponse de WebBlocks est de les rendre facultatifs plutôt que fondamentaux.
Une fondation volontairement ennuyeuse
Il existe une tendance dans les logiciels à décrire une « technologie ennuyeuse » comme s'il s'agissait d'excuses.
Cela peut également être un avantage.
Un développeur Laravel ouvrant un projet WebBlocks devrait toujours reconnaître une application Laravel.
Un développeur frontend doit toujours voir HTML, CSS et JavaScript.
Un éditeur doit voir les pages et le contenu plutôt que l'architecture de déploiement.
Et un outil d'IA devrait voir les schémas, les autorisations et les opérations structurées explicites plutôt que d'avoir à procéder à la rétro-ingénierie d'une interface d'administration.
Il y a beaucoup de place pour l'innovation au-delà de cette base.
La fondation elle-même ne doit pas nécessairement être inconnue.
Essayez l'approche plutôt que la terminologie
Les concepts individuels dans WebBlocks CMS sont intentionnellement reconnaissables.
La partie intéressante est la manière dont ils fonctionnent ensemble :
- un CMS Laravel installable avec Composer,
- une couche de contenu facultative pour un produit existant,
- le rendu du site web public,
- des pages structurées et du contenu réutilisable,
- le multisite et la localisation,
- les médias et la navigation,
- les révisions et la publication contrôlée,
- des API aux autorisations délimitées qui permettent aux outils d’IA modernes de participer à de véritables workflows CMS.
La question de savoir si cette combinaison est utile est une question bien plus intéressante que de savoir si MVC, des blocs ou des applications monolithiques existaient avant elle.
Ils l’ont fait.
Le projet est open source, la documentation est publique et il y a une démonstration en direct.
La meilleure façon d’évaluer l’idée n’est donc pas de se demander si les ingrédients sont nouveaux.
Essayez le CMS et voyez ce qui peut être construit avec eux.