Passer au FSE, c’est un grand pas. Mine de rien, ça demande à revoir pas mal de choses dans vos processus de création de sites. Vous vous demandez alors si ce n’est pas encore trop tôt, si la technologie est assez mature, et c’est totalement légitime. Dans ce cours, je vais tenter d’aborder objectivement les facteurs qui vont vous permettre de décider.
Sommaire du cours
- Le choix d’une technologie dans un monde en mouvement
- Argument 1 • Créer des sites plus rapidement avec moins d’effort
- Argument 2 • Des process en phase avec l’industrie
- Argument 3 • Du natif qui s’affranchit des dépendances
- Argument 4 • Composer, réutiliser et ne pas réinventer la roue
- Argument 5 • Une meilleure ergonomie pour le client
Le choix d’une technologie dans un monde en mouvement
Le web est comme un TGV qui file à toute allure. Alors pour rester dans le train du progrès, il faut périodiquement remettre en question les outils, technologies et techniques que l’on utilise au jour le jour, afin d’estimer si un changement est nécessaire.
Lorsqu’on vient à prendre de telles décisions, on veut être sûr que nos choix seront pérennes, et qu’on n’aura de ce fait pas besoin de changer toutes les ans. En effet, la moindre erreur de jugement pourrait coûter très cher à une entreprise.
Mais à l’inverse, se complaire dans des technologies trop anciennes n’est pas bon non plus : on accumule une dette technique, et rattraper son retard demandera beaucoup d’énergie. Plus on attend et pire ce sera.
Il faut donc trouver le juste milieu : ne pas être dans le wagon des premiers adopteurs pour ne pas payer les pots cassés, mais ne pas être trop à la traine non plus pour garder sa compétitivité, au risque de voir s’éloigner le train depuis le quai de la gare.
5 arguments pour sauter dans le wagon du FSE
Et la problématique prend tout son sens avec le Full Site Editing. À l’heure où j’écris ces lignes, à l’été 2024, la question est au cœur des esprits : le FSE semble mature, tout le monde en parle, et beaucoup de conférences dans les WordCamps abordent ce sujet.
Alors la question est simple : doit-on passer au Full Site Editing dès maintenant ? Et la réponse est oui ! Et ce sera encore plus vrai si vous lisez cet article dans le futur.
Mais je ne demande pas de me croire sur parole, je vais tenter de vous apporter des arguments les plus objectifs possibles (dixit le gars qui essaie de vous vendre une formation !).
J’ai 5 principaux arguments en faveur du FSE. Les voici :
- Tout d’abord, on crée des sites plus rapidement. On est donc plus rentable ;
- Ensuite, on va professionnaliser nos procédés et s’aligner avec les standards de l’industrie, je pense notamment au design system, Figma… ;
- Tout cela grâce à une technologie native qui nous affranchit des outils tiers et qui ouvre le champ des possibles sans aucune limite ;
- De plus, on va pouvoir réutiliser nos créations et s’enlever des tâches répétitives grâce aux compositions : notre travail n’en sera que plus passionnant ;
- Enfin, on propose une meilleure ergonomie à nos client, plus visuelle et instantanée.
Je vais détailler chacun de ces points afin que vous preniez bien la mesure des forces de l’éditeur de site.
Argument 1 • Créer des sites plus rapidement avec moins d’effort
Vous avez peut-être un doute sur ce point mais je vous garantis qu’une fois à l’aise avec l’outil, vous allez créer des sites bien plus rapidement qu’auparavant.
On est plus rapide car on écrit moins de code
Tout d’abord, la plupart des modèles de page seront réalisés via l’éditeur et exportés en HTML.
Exit donc les longues journées d’intégration HTML et CSS. Avant, on passait nos journées dans notre IDE :
Désormais, on va plutôt passer du temps dans l’éditeur, et on exportera en HTML le résultat de nos compositions de blocs.
Vous l’avez compris : on n’a plus besoin d’écrire autant de HTML et de CSS qu’auparavant ! Ça va bien sûr mettre un coup de pied dans l’organisation des métiers de votre agence, mais on en reparlera.
Peut-on faire confiance à WordPress sur le HTML et CSS généré ?
Bien entendu, à ce niveau vous devez sûrement vous dire qu’en laissant WordPress gérer le HTML et le CSS de base des blocs, vous perdez en contrôle et en autonomie.
C’est totalement légitime. J’ai eu exactement les mêmes craintes. Je tiens à vous rassurer toutefois, on garde le contrôle et en cas de besoin, on a toujours une solution :
- On peut surcharger ou remplacer les CSS qui ne nous conviendraient pas ;
- On peut toujours créer nos propres blocs si les natifs ne nous suffisent pas ;
- Cela dit, le HTML et le CSS générés par WordPress est vraiment très propre.
Voici un exemple de HTML généré par WordPress côté front :
On peut observer plusieurs choses :
- Le nom des classes est clair et consistant. WordPress utilise la notation BEM que j’aime beaucoup et qui a fait ses preuves.
- Il n’y a pas plus de
<div>
que nécessaire, contrairement à Elementor. - Certains blocs ont beaucoup de classes mais c’est une bonne chose : c’est ce que l’on appelle de la composition, chaque classe ayant un rôle bien précis (alignement, couleur, espacement…).
Dans cet exemple, la classe has-tertiary-background-color
permet d’appliquer la troisième couleur de la palette de notre charte graphique via une variable CSS. Mais on en reparlera en détail par la suite.
On se retrouve également à taper moins de PHP au final. La plupart des configurations vont se faire sur le fichier theme.json
. Beaucoup des anciens hooks que l’on utilisait auparavant n’ont plus vraiment d’utilité dans ce nouveau monde. Et tant mieux.
Et du coup dans tout ça, on passe peut-être 30% de temps en moins pour réaliser un site. On peut donc proposer des prix moins chers, ou alors augmenter sa marge !
Vous pourriez vous dire qu’on en est arrivés à réinventer Elementor ! Il y a des similitudes bien sûr, mais là où Elementor est adapté au grand public, le FSE, dans sa version complète, est bien plus adapté aux agences. Notamment avec le design system intégré. On en reparle juste après.
Argument 2 • Des process en phase avec l’industrie
L’argument le plus fort en faveur du FSE, c’est pour moi celui-di : créer un site web fait appel à de nombreux métiers, mais le chaînon le plus important, c’est celui situé entre designers et développeurs.
Figma et les Design System
Aujourd’hui, le designer moderne utilise en général un outil comme Figma pour créer ses designs. C’est l’outil de web design parfait car il permet de créer des composants réutilisables, contraindre les mises en forme, et collaborer en direct avec ses collègues, tout ça dans votre navigateur et en toute fluidité.
Figma a coiffé au poteau les autres logiciels comme Sketch, et même Adobe n’a pas réussi à dominer ce marché avec XD.
En ce qui concerne les composants, on peut par exemple créer des boutons qui s’adaptent automatiquement à la taille du texte à l’intérieur, et il existe même un mode développeur (payant) pour faciliter l’intégration des éléments en HTML et CSS.
L’outil de rêve que l’on a attendu pendant des années, en somme.
Dans cet exemple, j’ai créé des composants boutons avec des variations de styles (primary, secondary, disabled) et ces boutons utilisent le composant icône. Chaque composant est entouré d’une bordure violette.
Le design system : le pont entre le design et l’intégration
Du coup aujourd’hui les designers, avant de penser « pages », vont réfléchir au design system. Le but, en plus de définir les éléments classiques de la charte graphique, va être de modéliser les différents composants du site : boutons, menus, cartes, styles globaux… Ainsi que leurs différents états et intéractions.
Voici par exemple le design system de BackWPUp, un plugin WordPress dédié à la sauvegarde de vos sites.
Non seulement cette approche est géniale, mais en plus WordPress a la même approche. Et là, bingo ! Designers et développeurs parlent enfin le même langage.
Argument 3 • Du natif qui s’affranchit des dépendances
Il aura fallu être patient pour avoir un éditeur digne de ce nom. Les solutions tierces comme Elementor, Beaver, Oxygen… n’ont pas attendu que WordPress se modernise pour sortir leurs propres solutions.
Avant même l’arrivée providentielle d’Elementor qui a secoué l’écosystème WordPress comme un raz-de-marée dès 2016, certains thèmes de Theme Forest (Envato) commençaient à proposer des thèmes à tout faire comme Avada.
De son côté, Elegant Theme proposait son thème unique : Divi.
Lorsque WordPress a sorti Gutenberg en 2018, ce n’était pas encore un page builder, juste un éditeur de contenu.
Les utilisateurs sont d’abord restés méfiants : pourquoi changer alors que nos outils tiers sont meilleurs ?
Et c’est pour cela qu’encore aujourd’hui, on a une communauté très éparpillée. Pour ne citer que quelques exemples, il y a :
- Ceux qui veulent faire des sites à la main (en HTML, CSS et PHP) ;
- Ceux qui préfèrent Elementor en version gratuite, avec un thème comme Astra ;
- Ceux qui préfèrent payer une licence pro et tout faire avec leur builder ;
- Ceux qui veulent une approche hybride : un builder et du développement spécifique…
Il y a donc plein d’approches différentes avec WordPress, c’est pour cela que c’est parfois compliqué pour une personne qui débute avec le CMS.
Si ça vous intéresse, j’ai écris un article concernant les différentes façons de faire un site avec WordPress sur le blog :
C’est également très compliqué lorsqu’on récupère des sites faits par d’autres agences en maintenance (on parle de TMA). Dans ce cas, il faut maitriser un minimum les technologies utilisées et ce sont rarement les mêmes.
Pourquoi revenir au natif ?
À l’heure où j’écris ces lignes, des années se sont écoulées et des milliers de contributeurs ont travaillé d’arrache-pied pour proposer un outil visuel abouti, et qui est autant adapté aux no-coders qu’aux développeurs.
Personne n’y croyait vraiment à l’origine. Mais le fait de créer un outil basé autour des standards de l’industrie, comme on en a parlé avant, avec un certain minimalisme plutôt qu’une profusion de réglages, l’a propulsé au top des éditeurs.
Mais quels sont les avantages d’un outil natif ?
Tout le monde utilise la même technologie
Le premier avantage c’est qu’on évite d’éparpiller la communauté. Tout le monde se rejoint autour d’une vision commune. Cela permet d’avancer plus vite et plus loin ensemble.
Cela dit, c’est quand même bien d’avoir le choix. Nul ne sera obligé de passer au FSE s’il veut continuer d’utiliser un autre outil, et c’est tout à fait OK !
Pas besoin d’alourdir le site et l’interface avec un outil tiers
Le second argument c’est la légèreté. En restant sur une solution native, on n’a plus besoin d’installer des outils tiers qui peuvent alourdir le site.
De plus, l’installation d’un page builder va ajouter de nombreuses pages d’options et des interfaces supplémentaires qui n’aident pas forcément à garder une UX claire.
Le problème de trop dépendre de solutions tierces, c’est le risque d’incompatibilité avec les autres plugins. Même si aujourd’hui la plupart fonctionnent très bien avec Elementor et les autres builders, ça reste quand même un risque.
WordPress retrouve sa souveraineté, et c’est plus simple pour les débutants
Comme je le disais précédemment, c’est compliqué pour un débutant de savoir par où apprendre WordPress. Avec une solution native, officielle et bien documentée, c’est beaucoup plus simple de savoir par où commencer.
Après tout, l’éditeur de contenu est le cœur d’un CMS. Ça aurait été un comble que WordPress ne propose pas quelque chose de solide nativement.
Argument 4 • Composer, réutiliser et ne pas réinventer la roue
Est-ce que vous avez parfois l’impression, pour chaque projet, de refaire la même chose sans fin ?
On essaie de capitaliser sur l’existant bien entendu, mais ce n’est pas toujours évident. Et on le sait très bien aujourd’hui la plupart des sites se ressemblent en terme de mise en page :
- On a des sections pleines largeur avec une couleur ou image de fond ;
- On dispose les informations dans des colonnes : 2/3, 1/3, 1/4 ;
- On essaie de ne pas mettre trop de textes ;
- Et on varie les éléments : titres, images, boutons…
Après tout, les règles de web design sont les mêmes pour tout le monde.
C’est là où le FSE apporte un gros argument sur la table : les compositions que l’on peut réutiliser au sein du site d’abord, mais également d’un site à un autre.
Imaginons une composition toute simple :
Voici à quoi elle va ressembler sur mon premier site, une fois le design system configuré au travers du theme.json
:
Si je l’importe sur mon prochain site, et que je prends bien soin de conserver les mêmes noms de couleurs de ma charte, la composition va hériter des réglages du nouveau site : espacements, couleurs, typographie… Voici le résultat :
Du coup, le but va être de créer des compositions et de les garder bien au chaud. Au fur et à mesure des projets, vous aurez accumulé une belle librairie de compositions. Vous gagnerez alors encore plus en productivité.
Argument 5 • Une meilleure ergonomie pour le client
En passant au FSE, vous n’aurez pas que des avantages pour votre agence. Vous allez également offrir une meilleure expérience à vos clients.
En leur donnant accès au Full Site Editing, vous allez leur donner accès à un outil visuel « pixel perfect ». Pour la première fois, ils auront un véritable éditeur WYSIWYG (What You See Is What You Get).
De mon expérience, la plupart des agences (et moi-même) utilisions auparavant des formulaires à base de groupes de champs ACF pour rendre administrables les différentes pages du site.
J’ai toujours adoré cette approche mais elle présente des limites. On peut vite se retrouver avec beaucoup de champs et une interface lourde et peu visuelle : on est obligés d’imaginer à quoi va ressembler la page.
Avec le Full Site Editing, on voit en direct ce que l’on va avoir en front :
Il n’y a pas photo !
Votre client aux commandes du FSE
Mais je vous vois venir ! Un grand pouvoir implique de grandes responsabilités : si on donne les pleins pouvoir au client, il va tout casser !
C’est un peu ce qu’il se passe avec Elementor d’ailleurs. Si bien que ceux qui créent des sites pour leurs clients en gardent la gestion.
Mais c’est différent avec le FSE ! Il y a plusieurs concepts intéressants qui vont permettre de limiter la casse :
Verrouiller les blocs et les compositions
La première chose, c’est que vous pouvez verrouiller vos blocs, compositions et modèles. Votre utilisateur n’aura alors plus le droit de modifier ou supprimer ces blocs. Il pourra uniquement modifier leur contenu.
Ici, on peut voir que j’ai verrouillé :
- Le déplacement : l’utilisateur ne peut plus déplacer le bloc (ou le groupe de blocs) ;
- La suppression : l’utilisateur ne peut plus non plus supprimer le groupe de blocs ;
- Mais l’édition de contenus reste tout à fait possible !
Et ce réglage peut-être appliqué à tous les blocs enfants. Ici j’ai appliqué ça au bloc « groupe » qui fait office de section.
Une interface utilisateur épurée et simple à comprendre
Mais le plus important, c’est que comme la grosse partie de la configuration des réglages visuels va se faire via le fichier theme.json
, les options proposées dans l’éditeur sont volontairement limitées :
Et voici pour comparaison Elementor :
Grâce au design system du FSE, qui sera défini par le designer en amont, on va contraindre les possibilités et les limites de l’éditeur pour offrir l’interface la plus simple possible. Mais on en reparle juste après !
Bien sûr, si vous activez toutes les options disponibles, alors l’interface de Gutenberg pourra se retrouver plutôt chargée.
D’ailleurs, vous allez pouvoir choisir les réglages à afficher ou cacher de l’éditeur, selon le projet et le client. Le FSE propose une belle granularité dans ses réglages.
Dans cet exemple j’ai fait plusieurs choses intéressantes :
- J’ai désactivé le choix d’une couleur personnalisée. L’utilisateur est alors limité à celles que j’ai définies dans la palette ;
- J’ai supprimé les dégradés et duotones car je n’en ai pas besoin sur le site ;
- J’ai désactivé l’option qui permet de changer la couleur d’un lien ;
Voici à quoi ressemble le sélecteur de couleurs lorsque toutes les options sont à true
:
Et voici à quoi il ressemble une fois que j’ai appliqué mes restrictions :
Et on pourra faire la même chose pour les espacements :
Ici j’ai été moins restrictif que précédemment :
- J’ai autorisé l’utilisateur à modifier l’espacement entre les blocs, et les marges internes et externes ;
- Par contre, l’utilisateur ne pourra pas définir un espacement personnalisé
- Au niveau des unités, j’ai limité aux pixels, rem et pourcentages.
Voici du coup à quoi ressemblent les options d’un bloc avec ces réglages :
Comme vous pouvez le remarquer, l’utilisateur a le choix entre 6 tailles d’espacements et pas une de plus. Vous gardez le contrôle car votre utilisateur est contraint à respecter le design system.
Le choix vous appartient, mais n’oubliez pas les sages conseils d’oncle Ben !
Aujourd’hui, Gutenberg est le seul éditeur qui permet autant de granularité et de personnalisation dans les choix proposés à l’utilisateur final, là où les autres éditeurs ont plutôt opté pour la course à la fonctionnalité : plus il y en a, mieux c’est !
Bien entendu, dans la suite de la formation, on va passer en revue tous les réglages du theme.json
et je vais vous apprendre à interpréter votre design system à la perfection.
Et voilà, j’espère vous avoir éclairé un peu plus sur les bénéfices du FSE.
Si vous y passez prochainement, vous aurez un avantage sur vos concurrents en terme de productivité, de rentabilité, de modernité et d’ergonomie. Ce sont souvent des arguments qui peuvent faire la différence dans vos propositions clients.
Et le plus beau dans tout ça, c’est que vous diminuez largement les dépendances à des extensions ou outils externes, ce qui en facilite la maintenance et les futures évolutions.
Dans le prochain cours, on va comparer le FSE aux autres constructeurs comme Elementor. Après tout, ils sont là depuis plus longtemps et ont peut-être de l’avance sur certains aspects.
0
Questions, réponses et commentaires