Avec les contraintes de Core Web Vital, les sites web ont de plus en plus d’impératifs à respecter pour espérer ne pas voir leur classement se dégrader dans l’algorithme de Google. La priorité, longtemps donnés à l’accumulation de fonctionnalités, a depuis quelques temps maintenant glissé sur les performances et l’optimisation, et même le vénérable thème Divi ou le respectable constructeur Elementor ont fait leur mue, où au moins l’ont commencé.
Les nouveaux outils de conceptions de site sous WordPress, d’Oxygen, jusqu’aux très récents et impressionnants Bricks ou Zion Builder, se veulent ultra-légers, flexibles et pouvant convenir aux développeurs pointus comme aux profanes. Petit mensonge en passant, les profanes s’y perdront allègrement et risquent une surconsommation d’aspirine.
Ajoutons à ça ceux qui étaient des thèmes à l’origine et qui s’acheminent plus ou moins rapidement vers des systèmes de gestion complets pour des sites de toutes tailles comme Kadence, Blocksy ou GeneratePress. Ces thèmes proposaient auparavant uniquement des configurations avancées des entêtes et pieds-de-page, ainsi que la gestion des typographies et des couleurs mais offrent maintenant la possibilité de configurer les affichages de chacune des parties de votre site, en partie pour Blocksy et Kadence (mais ça arrive), et presque de manière complète pour GeneratePress depuis sa dernière versions, les trois étant basés sur l’éditeur natif de WordPress, Gutenberg.
Plus récemment, un constructeur basé également sur Gutenberg, Cwickly, a pris le parti radical de s’appuyer uniquement sur la nouvelle option de WordPress 5.9, le FSE, Full Site Edition, autrement dit l’édition complète de tous les éléments du site, de l’entête au pied de page.
Choisir un environnement de design et d’intégration sous WordPress est devenu compliqué mais vraiment passionnant. Toutes ces solutions ont des avantages, parfois des inconvénients, mais surtout n’ont pas réellement la même capacité à répondre à certains impératifs de fonctionnalités, de design, ou de temps d’intégration. Ils dépendent tous d’un écosystème de développeurs, de son dynamisme, de sa pérennité et souvent de leur capacité à faire bon ménage avec les autres éléments et modules de WordPress.
J’ai envie de rester pragmatique et sans a priori, ou pas trop, et j’utilise la solution que j’estime la plus appropriée pour un projet précis, avec un objectif et un coût bien définis. Se limiter à une seule solution m’interdit des moyens permettant de travailler plus vite et mieux, et m’empêche de répondre le plus simplement et correctement à une demande. Un site sous Oxygen n’a pas la même structure pas plus que le même fonctionnement qu’un site Divi : il sera dépendant d’un développement plus long mais plus personnalisé, sera plus léger, mais avec peu d’interactions futures en dehors de la rédaction d’articles d’actualités, là ou le second pourra être modifié facilement et accueillir aisément des fonctionnalités standards (il existe des modules pour presque tout pour Divi), tout en restant accessible à la personne non spécialiste qui le gère. Cette distinction artificielle n’est pas à prendre comme une vérité mais plutôt que le résultat de nombreuses expériences sur des sites très différents, et je ne doute pas que de très nombreuses personnes ne seraient pas d’accord.
Lorsqu’on se préoccupe de design autant que de performances, de fonctionnalités autant que d’expérience utilisateur, le choix actuel au sein de la galaxie WordPress est d’une richesse inégalée parmi les gestionnaires de contenu web, et s’il est possible de s’y perdre très rapidement, il permet de proposer une palette infinie de sites, et ça, pour le designer et l’intégrateur, c’est une boîte de feutres et une trousse à outils tout en un !