« Le logo ne s’affiche plus après la mise à jour du plugin. » Ce message, reçu un lundi matin de la part d’un hôtelier propriétaire d’un établissement de douze chambres, résume assez bien ce que signifie tester des fonctionnalités expérimentales sur un vrai projet : accepter que le sol puisse bouger d’une semaine sur l’autre.
La page d’accueil de cet hôtel indépendant a servi de bac à sable à trois blocs alors tout juste apparus dans l’extension Gutenberg : Site Title, Site Tagline et une première mouture du bloc de requête destiné à afficher automatiquement les avis clients les plus récents. Rien de tout cela n’existait dans WordPress en version stable ; tout provenait de la branche de développement du plugin, installée volontairement sur un environnement de préproduction isolé.
Pourquoi un hôtel plutôt qu’un site plus complexe
Le choix de ce projet n’était pas anodin. La page d’accueil de l’hôtel ne comportait que quelques éléments : un nom d’établissement, une accroche courte, une galerie de chambres et un flux de trois derniers avis. Ce périmètre restreint permettait de mesurer précisément le comportement de chaque bloc de site sans le bruit d’une page riche en widgets et en mises en forme personnalisées.
- Le bloc Site Title affiche dynamiquement le nom du site défini dans les réglages généraux, sans dépendre du thème.
- Le bloc Site Tagline reprend le slogan configuré au même endroit.
- Le bloc de requête, encore appelé simplement « Query » à ce stade, remplace la boucle PHP manuelle habituellement écrite dans le thème.
Le comportement observé, section par section
Sur cette page d’accueil, le bloc Site Title s’est révélé fiable dès l’installation : il reprend fidèlement la valeur du champ « Titre du site » sans configuration supplémentaire. Le bloc Site Tagline a montré le même comportement, avec une seule surprise : toute modification du slogan dans les réglages se répercute immédiatement sur la façade, sans besoin de vider le moindre cache, ce qui tranche avec les thèmes classiques où ce texte est souvent codé en dur.
Le bloc de requête chargé d’afficher les avis récents a demandé davantage d’ajustements. À ce stade de développement, ses réglages de tri et de nombre d’éléments changeaient d’un jour à l’autre selon les mises à jour du plugin, obligeant à revérifier la configuration après chaque montée de version.
Les limites rencontrées sur ce terrain d’essai
Instabilité de l’interface de réglages
Les panneaux latéraux de configuration de ces blocs changeaient de position et parfois de libellé d’une version à l’autre du plugin, rendant la formation de l’équipe éditoriale de l’hôtel plus complexe que prévu.
Absence de garde-fous visuels
Rien n’empêchait, à ce stade, de supprimer accidentellement le bloc Site Title depuis l’éditeur, avec pour conséquence la disparition pure et simple du nom de l’établissement en façade, sans message d’avertissement.
Documentation quasi inexistante
Faute de documentation stabilisée, la seule source fiable restait le suivi des tickets et des changelogs publiés sur le dépôt du projet.
Ce que ce test a permis d’anticiper
Au-delà des anecdotes techniques, ce projet a surtout permis de comprendre la logique de fond de ces blocs : contrairement aux blocs de contenu habituels, les blocs de site ne stockent aucune donnée dans le contenu de la page. Ils lisent une source unique, centralisée, ce qui change fondamentalement la façon de penser une page d’accueil.
Tester une fonctionnalité instable sur un vrai projet, à condition d’en prévenir le client et de limiter le périmètre, reste la meilleure façon de comprendre une direction avant qu’elle ne s’impose partout.
Notre verdict à ce stade
Livrer une page d’accueil entièrement construite avec ces blocs de site n’aurait pas été raisonnable pour ce client en production. La solution retenue a consisté à garder un thème classique stable pour l’ensemble du site, tout en isolant cette page d’accueil expérimentale sur un sous-domaine de test, invisible du grand public, pour continuer à observer l’évolution de ces blocs avant toute généralisation.
