WordPress 5.0 et Gutenberg : un changement de philosophie ?

WordPress 5.0 est sorti le 6 décembre dernier. Comme toute version majeure, elle apporte son lot de nouveautés. Et l'une d'elles est particulièrement visible : Gutenberg, un tout nouvel éditeur pour rédiger les contenus, éditeur qui vient remplacer automatiquement l'ancien TinyMCE.

Remarque préalable

Avant de lire cet article, il est important de lire ce passage.

Cet article n'a pas pour but de venir critiquer WordPress, ni Gutenberg, ni toutes les personnes qui ont participé à cette nouvelle version du CMS. Il ne s'agit ici que d'un point de vue personnel sur ce qui vient de se passer et sur le futur du CMS. L'objectif est de pouvoir dresser le bilan de la sortie de cette dernière version, de la façon dont elle a été décidée et déployée, et aussi de mieux comprendre comment fonctionne la communauté WordPress, avec ses atouts et ses défauts.

On parlera ainsi beaucoup de la forme plutôt que du fond. Il est donc possible que je me trompe ou que j'occulte involontairement certains aspects dans cet article. Si c'est le cas, ce sera un plaisir d'échanger avec vous en commentaire.

Qu'est-ce qui change avec WordPress 5.0 ?

Pas mal de choses en réalité. Un article sur Make WordPress détaille d'ailleurs tout ce qui change avec la 5.0 (par exemple, on peut enfin faire facilement de la traduction dans nos fichiers JavaScript, ce qui est génial). Mais ce que tout le monde va remarquer, c'est surtout le nouvel éditeur Gutenberg

Plus moderne, il permet de gérer et créer des contenus de façon très visuelle avec des blocs. On y retrouve des possibilités de mise en page traditionnelle (listes à puces, gras, alignement, etc.) mais de très nombreux éléments supplémentaires grâce à ce concept de Blocs :

Le principal intérêt est de rendre plus visuelle, interactive et complète la rédaction d'un contenu, et d'avoir au passage un rendu plus proche entre le contenu que l'on rédige et la façon dont ce dernier va s'afficher réellement sur notre site WordPress.

Pourquoi Gutenberg ?

Le point clé de cette mise à jour, c'est qu'elle ouvre de nouvelles perspectives pour l'avenir. Actuellement, l'utilisateur peut modifier son contenu, mais c'est le thème WordPress qui va gérer les autres éléments de chaque page (header, footer, sidebar, etc.). Pour de nouveaux utilisateurs WordPress, ces éléments de l'interface d'administration sont loin d'être facilement compréhensibles au premier abord, comme par exemple ces actions :

créer un menu ;
ajouter un widget ;
personnaliser un thème avec le Customizer ;
changer un contenu dans le header ou le footer ;
etc.

Le vrai objectif de Gutenberg est de rendre plus fluide et administrable l'intégralité de son site et de ses contenus. A terme, Gutenberg devrait ainsi unifier l'interface d'administration de WordPress avec le principe des blocs, et donc au passage de se débarrasser d'anciennes interfaces et API comme par exemple celles des Widgets et des Shortcodes.

Une des frustrations courantes des utilisateurs de WordPress est justement d'avoir une interface centrée sur la rédaction de contenus textes alors que le web est maintenant focalisé sur des contenus enrichis (vidéo, images, galeries, tableaux, boutons, contenu en pleine largeur, etc.). L'autre frustration courante était d'avoir un rendu visuel en backoffice A, et un rendu complètement différent en front-office B.

Gutenberg essaye ainsi de résoudre ces deux problématiques à la fois (vous pourrez d'ailleurs trouver ici un article anglais qui en parle très bien). La version 5.0 de ce nouvel éditeur n'est donc que la 1ère étape. La phase 2 est d'ailleurs déjà en route, et l'objectif est d'aller bien plus loin dans les mois et années à venir avec de nombreux projets visant à intégrer bien plus ce nouvel éditeur dans l'ensemble du backoffice de WordPress.

L'éditeur actuel est en effet incomplet, et il a le vilain défaut de mélanger une interface classique WYSIWYG (une interface comme n'importe quel logiciel de bureautique) avec des API supplémentaires :

Celle des shortcodes comme " [je_suis_un_shortocde] ";
L'API View des shortcodes (dont quasiment personne ne parle et/ou ne connaît l'existence) ;
Les autres menus de WordPress pour gérer tout le reste (notamment le Customizer, les widgets ou encore les menus dont on a déjà parlé).

Smashing Magazine en parle très bien dans son article sur les blocs. WordPress souhaite à terme passer de ce fonctionnement :

à celui-ci :

Malheureusement, l'arrivée de Gutenberg a fait grincer les dents de beaucoup de personnes. Voyons pourquoi ?

Un changement de philosophie ?

A titre personnel, je pense que Gutenberg est une bonne chose, et va permettre de créer plus facilement des sites enrichis et variés. Cela va permettre enfin de s'écarter du sacro-saint carcan des catégories/articles d'une part et des pages d'autre par t. Mais la façon dont il a été déployé a provoqué une levée de boucliers d'une partie de la communauté.

Il y a en effet un vrai changement dans ce qui faisait la force de WordPress : la rétrocompatibilité (pour la première fois je dois dire à nos clients de ne pas mettre à jour WordPress tout de suite) et la manière de communiquer sur cette version majeure.

Forcer un changement majeur

Les équipes de WordPress ont forcé un changement majeur conséquent, et qui a malheureusement eu un impact non négligeable sur la rétrocompatibilité de certains thèmes et extensions. Beaucoup d'entre eux se greffent en effet sur l'éditeur classique TinyMCE. Il a donc fallu pour une partie d'entre eux s'adapter au nouvel éditeur.

Le créateur de WordPress le dit lui-même, c'est la version majeure la plus controversée de l'histoire du CMS WordPress :

" It was definitely the most controversial release in a while "

Le problème n'est pas tant l'éditeur en lui-même, mais la façon dont il a été mis en place, dont la communication a été faite et dont la communauté a été impliquée. Pour certains, cela a donné (à tort ou à raison) la sensation qu'il fallait sortir coûte que coûte Gutenberg, que l'éditeur soit prêt ou non.

Communication chaotique

L'une des plus grosses frustrations liées à cette nouvelle version est son aspect désordonné, chaotique et imprévisible. Prenons un exemple simple, la date de mise en ligne. Initialement prévue pour Novembre, celle-ci avait été déplacée à Janvier. Puis Matt Mullenweg a décidé d'accélérer la date à début Décembre sans prendre en compte les remarques de chacun, comme ici avec Yoast.

En d'autres termes, il était difficile de s'adapter pour l'écosystème, ce qui a provoqué de la frustration et de l'incompréhension pour une partie de la communauté. Étant donné le rythme rapide de développement (rapide au vu de la taille du projet et des implications) et le flou sur la date de sortie réelle, cela a amené différentes complications supplémentaires :

Les problématiques de Gutenberg

Accessibilité

La première d'entre-elles a été l'accessibilité. Un éditeur se doit d'être utilisable par tous. Cela implique une accessibilité classique pour tous les navigateurs :

dans toutes les résolutions ;
sur tous les périphériques, que ce soit sur ordinateur fixe, portable, téléphone ou tablette.

Cela sous-entend également que les personnes souffrant d'un handicap (quel qu'il soit) soient toujours capables d'utiliser l'éditeur de WordPress.

C'est d'ailleurs là où le bât blesse. Deux mois avant la sortie définitive, Rian Rietveld, la personne leader de l'équipe Accessibilité de WordPress, a " démissionné " de son poste. Et les termes utilisés sont assez durs envers le nouvel éditeur :

" The codebase of Gutenberg is difficult for all of us "
" There was no React developer with accessibility experience in the community "
" Functionality that was tested, improved and then approved by Andrea, changed in a later stage, breaking the a11y improvements again "
" New functionality was not keyboard tested before implementation "

En d'autres termes, le code de Gutenberg est trop complexe, changeait trop souvent, sans avoir les personnes compétentes sur le langage utilisé (React) et sans mettre en place les processus logiques pour tester l'accessibilité pour ce genre de projet. C'est d'ailleurs l'un des reproches qui revient le plus souvent quand on parle du nouvel éditeur. Dans l'article, l'auteur explique clairement que Gutenberg est une régression par rapport à l'ancien éditeur TinyMCE.

Pire encore, un site dédié au projet explique clairement que ces compromis ont été faits sciemment. Pour résumer, on sacrifie une partie de l'accessibilité alors que WordPress représente 32% du web mondial.

Compatibilité et développement sur-mesure

Cette problématique est inhérente à tout projet de grande envergure. Le nouvel éditeur étant un changement d'envergure, il faut s'assurer qu'il ne vienne pas casser les sites WordPress. Le problème, c'est que la combinaison d'extensions et de thèmes est gigantesque, et cela sans compter les combinaisons de versions différentes de ces mêmes extensions et thèmes, du cœur de WordPress, des configurations serveur et des configurations du CMS. Il est impossible humainement de tester toutes les configurations qui pourraient exister, et c'est donc aux utilisateurs finaux de tester et de faire remonter un maximum de problématiques.

C'est là que la notion de délai prend toute son importance : si on réduit le temps de développement d'une version majeure, il est difficile pour tout le monde de prendre le temps de tester, de trouver des solutions et de les incorporer dans le cœur.

Et si vous ajoutez à cela tous les développements sur-mesure, cela complexifie l'ensemble. Je connais par exemple certains projets qui utilisent WordPress pour diffuser du contenu ailleurs, par exemple sur des applications Android et iOS. Le souci, c'est que le nouvel éditeur ajoute du marquage en base de données. Il faut donc que ces développeurs rajoutent des fonctions de nettoyage avant d'envoyer le contenu à leurs applications tierces :

Parfois bien entendu, ne pas être rétro compatible est nécessaire et inévitable. Par exemple, la version 5.0.1 est une version corrective qui a aussi été appliquée aux versions majeures précédentes (si vous n'êtes pas en version 5.0 mais en 4.9 ou inférieur, vous êtes aussi concernés), et qui n'est pas 100% rétro compatible ! Cela a été fait ici en toute connaissance de cause pour corriger des failles de sécurité. Il n'y avait donc pas le choix, mais cela impacte certaines extensions, comme ici avec WP Rocket :

Réapprendre

C'est valable pour n'importe quelle mise à jour d'un outil, mais la taille du projet Gutenberg accentue le phénomène. Pour les utilisateurs, il faut apprendre à écrire avec le nouvel éditeur, et les développeurs doivent apprendre à coder. Un nouvel Handbook est d'ailleurs là pour vous y aider.

Pour ces derniers, il faut se mettre à React, la librairie JavaScript phare de Facebook. Pourquoi React ? Pour plusieurs raisons : la taille de la communauté, les performances de celle-ci et surtout, savoir que derrière il y a un réseau social d'envergure qui " pousse " ce projet. Les développeurs WordPress doivent donc apprendre à utiliser cette librairie (si vous n'aimez pas le JavaScript, il va falloir faire avec). Et même avec des développeurs aguerris, c'est loin d'être simple au premier abord comme en témoigne cet article de Julien Maury dont vous allez vite sentir la frustration ^^.

Côté utilisateur, il faut aussi apprendre une nouvelle interface. Je ne dis pas ici qu'elle est meilleure ou moins bonne que l'ancienne : elle nécessite un apprentissage supplémentaire. En fonction de l'utilisateur, cette phase peut être rapide, et pour d'autre plus longue.

Ce qui est " marrant " avec ce point précis, c'est que justement aucun éditeur ne sera jamais idéal. Certains vont préférer l'ancien, d'autres le nouveau. Une partie des utilisateurs apprendra bien plus facilement Gutenberg que TinyMCE, et une autre partie fera exactement l'inverse. Et vous aurez aussi une partie qui aura du mal à rédiger quelle que soit l'interface que l'on va leur proposer (l'informatique est loin d'être aussi " innée " qu'on peut le penser).

Open Source ne veut pas dire démocratie

WordPress n'est pas une démocratie

Un grand nombre de personnes a critiqué le projet. Il suffit par exemple de regarder les notes attribuées à l'extension sur le dépôt officiel de WordPress :

Les avis sont tellement critiques que certains ont lancés des projets à côté, comme ClassicPress. Et bon nombre d'entre eux ont la sensation de ne pas être entendus.

Si le projet est Open Source, " pourquoi ne suis-je pas écouté ?" . C'est pour une raison simple, Open Source ne veut pas dire démocratie. Certains décident, et non pas toute la communauté.

C'est quoi l'Open Source ?

Sous ce terme barbare se cache un concept simple. Un projet Open Source est un projet dont le code est ouvert à tous. Cela implique 4 libertés fondamentales :

exécuter le code ;
l'étudier ;
le rediffuser ;
l'améliorer.

En aucun cas cela ne veut dire que tout le monde peut décider de l'avenir d'un projet Open Source (et si c'était le cas, nous serions dans un bordel monstre). Je vous invite à lire d'ailleurs cet excellent article anglais : " Open Source is not about you "

As a user of something open source you are not thereby entitled to anything at all. You are not entitled to contribute. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints.

Traduction : En tant qu'utilisateur d'un projet Open Source, vous n'avez donc droit à rien du tout (par rapport à ce dernier). Vous n'êtes pas autorisé à contribuer [de façon automatique]. Vous n'avez pas droit d'obtenir l'attention des autres. Vous n'avez pas le droit à ce que vos réclamations aient une valeur.

La phrase est dure, mais elle est vraie : quand l'auteur parle d'avoir le droit, c'est dans le sens " systématique " du terme. Dans un projet Open Source, vous pouvez donc donner votre avis, cela ne voudra pas dire qu'il sera forcément pris en compte.

Qui décide chez WordPress ?

Prenons maintenant un peu de temps pour comprendre comment cela se traduit pour notre CMS. Qui décide de l'évolution du projet WordPress ?

Les " Lead Developers " : 6 personnes (dont Matt Mullenweg, le créateur de WordPress) qui assurent la cohérence et la stratégie à long terme ;
Les " Core Comitters " : ceux qui ont le droit d'intégrer du code directement dans WordPress (environ 30 personnes) ;
Le " Mission Control et Security Team " : ceux qui déclenchent les mises à jour au niveau mondial, qui sont en charge de la sécurité et de s'assurer que tout se passe pour le mieux ;
Les " Components maintainers " : ceux en charge d'une partie bien précise de WordPress et qui doivent s'assurer de sa maintenabilité/évolution (tests, mises à jour, sécurité, cohérence, etc.). Et des composants, il y en a beaucoup ;
Les " Core contributors " : tous ceux et celles qui participent au cœur (n'importe qui peut devenir Core contributor, vous y compris).

Mais en résumé, les vraies décisions importantes sur WordPress sont décidées par une unique personne : le Project Leader, Matt Mullenweg, en concertation avec les 5 autres Lead Developers et la communauté. Attention à ce que je dis par contre, il ne faut pas caricaturer : il ne décide pas tout seul au doigt mouillé. Il le fait en écoutant la communauté, mais c'est lui à la fin qui va départager les avis et choisir une solution et stratégie.

Le difficile monde des projets informatiques

Au-delà des erreurs de gestion du projet Gutenberg (forcer la mise à jour, date imprécise, un projet pas prêt à 100%), la version 5.0 s'est heurtée en plus aux problématiques courantes des projets informatiques et/ou Open Source (et auxquelles se heurtent toutes les versions majeures dans des proportions plus ou moins grandes). Cela a accentué la frustration d'une partie de la communauté.

Le frein au changement

Cette problématique, vous l'aurez partout. La résistance au changement est un concept psychologique inhérent à l'être humain, et qui est particulièrement développé dans le monde de l'informatique au sens large.

Tout changement d'interface, de logiciel, de design ou de procédures provoque souvent ce type de résistance. Et Gutenberg entre parfaitement dans ce cas de figure.

Tout le monde n'était pas au courant

Autre problématique courante : croire que tout le monde a pris connaissance de la prochaine évolution.

Lorsque l'on parle de résistance au changement, un des moyens de s'en prémunir est de communiquer en amont. Mais c'est un raisonnement erroné car cela part du principe que tout le monde sera au courant. Et Gutenberg n'échappe pas à la règle : malgré la communication importante, certains utilisateurs, développeurs et même des agences n'étaient pas au courant.

C'est d'ailleurs un problème courant : ce n'est pas parce que l'on communique que les gens sont au courant.

Prenons par exemple le message que WordPress affichait dans l'interface d'administration pour prévenir de l'arrivée de Gutenberg : il n'a pas suffi car :

il n'a pas été forcément lu ;
il a été lu par les mauvaises personnes
ceux qui ont lu n'ont pas forcément pris conscience de l'impact réel du nouvel éditeur

C'est d'ailleurs frustrant pour tout le monde : pour ceux qui n'étaient pas au courant car ils ne comprennent pas, et ceux qui portent le projet car ils doivent faire face aux critiques. Cela arrive aussi fréquemment dans tous les autres aspects, comme par exemple pour les traductions : les bénévoles proposent et soumettent une traduction, puis des utilisateurs se plaignent après sa mise en place (on peut citer par exemple les débats sur les termes " étiquettes " ou " téléverser ").

Ceux qui se plaignent mettent toujours en avant la même chose : " nous n'étions pas mis au courant " et " on ne nous demande pas notre avis" . Dans le même temps, ceux qui participent au projet ont souvent le même argument : vous n'aviez qu'à participer ou vous informer. Il y a là un énorme biais de jugement : cela part du principe que ceux qui critiquent ont le temps, les compétences et les connaissances pour participer. Et j'insiste beaucoup sur la notion de temps libre. Pour certains, ils ne peuvent pas participer à ce type de projet (problèmes de santé, famille, autres passions, travail important, etc.). A titre personnel, je participe à la communauté et j'aimerais faire plus. Mais j'ai tout simplement une femme et deux enfants que j'aime.

Sur ce point précis, il n'existera malheureusement jamais de solution efficace. Cela dit, cela n'empêche pas le fait suivant : si l'on ne participe pas, on peut donner son avis (poliment) mais on doit respecter le travail de ceux qui font avancer le projet (WordPress n'en serait pas là sans le travail colossal de nombreux contributeurs dans le monde, merci encore à eux).

Un faible nombre d'individus qui décident réellement

Autre point bloquant des projets informatiques : les grandes décisions sont prises par un nombre restreint de personnes. Ces dernières peuvent se tromper (l'erreur est humaine) ou encore avoir un point de vu erroné ou biaisé. Attention, je ne dis pas que c'est le cas, mais le risque existe.

D'un autre côté, un projet a besoin d'un leadership et d'un cap. Si tout le monde pouvait et devait donner son avis avant un changement, le projet WordPress n'avancerait jamais. Un bon projet Open Source a besoin d'un cap et d'une stratégie, et notre CMS n'échappe pas à la règle. En d'autres termes, c'est à la fois une force et un problème.

Conflits d'intérêts ?

Un autre point soulevé par certains membres de la communauté (moi le premier), c'est les conflits d'intérêts potentiels que cela implique. Avec peu de personnes décisionnaires, celles-ci peuvent influer sur les décisions afin de favoriser celles dont ils pourraient bénéficier. On peut donc se poser la question si les décisions principales sont faites en faveur ou non des autres activités des leaders de WordPress. On peut aussi se poser la question inverse : peuvent-ils bloquer des décisions qui iraient à l'encontre de leurs activités, même si celles-ci seraient bénéfiques pour le projet ?

Attention cependant avec ce que je viens de dire : je ne dis pas qu'il y a conflit d'intérêt, mais juste que le risque existe.

On peut citer ici très facilement l'exemple de WordPress.org et Matt Mullenweg avec sa société d' Automattic ( WooCommerce, JetPack, Gravatar, etc.). C'est aussi le cas de n'importe quel contributeur à WordPress : on peut l'être avec ou sans idée derrière la tête. Prenez Google récemment : s'ils s'investissent dans la communauté, croyez-moi qu'il y a toujours une arrière-pensée derrière. On peut d'ailleurs transposer ce problème dans la vie réelle avec par exemple les députés qui peuvent avoir des sociétés et qui peuvent vouloir modifier la loi pour en profiter (ou en tout cas anticiper des changements à venir).

Maintenant, soyons parfaitement honnêtes : il n'y a aucune solution qui permettrait de supprimer ces conflits d'intérêt potentiels, à moins de travailler dans un autre secteur d'activité quand on contribue soi-même à WordPress (autant dire que c'est loin d'être le cas, et c'est aussi très loin d'être faisable). Matt Mullenweg répond d'ailleurs à cette critique dans son dernier article sur WordPress 5.0. Dans le cadre de la version 5.0, je pense sincèrement que ce n'est pas le cas. Mais quand on voit qu'il doit répondre publiquement à cette critique, c'est qu'on a dû la lui faire régulièrement.

L'inertie du développement

Vouloir participer à un projet Open Source est une excellente chose. J'invite d'ailleurs tout le monde à contribuer, que vous soyez développeur, utilisateur, traducteur ou encore référenceur. Le problème, c'est de savoir comment participer, où commencer, ou même se dire " est-ce que l'on est légitime " pour contribuer au cœur de WordPress. Sur ce point-là, je le répète : vous pouvez TOUS participer.

Le souci, c'est qu'avec de tels projets, les outils mis en place ne sont pas forcément intuitifs. Rappelez-vous toujours que l'on n'a pas tous les mêmes compétences et expériences, et que nous n'avons pas forcément le temps de pouvoir regarder cela en détail. Sur ce point, la communauté WordPress fait des efforts, mais je pense sincèrement que l'on pourrait aller bien plus loin. Regardez par exemple l'interface austère de la gestion des tickets en cours de traitement :

En simplifiant et en expliquant mieux comment participer, il y aurait peut-être eu moins de retour sur la version 5.0 qui vient de sortir (ce qui est marrant dans ma phrase, c'est que je rentre dans le cadre du point précédent : ceux qui critiquent mais qui ne participent pas).

Par contre, un point bloquant qu'il faut noter mais qui ne pourra jamais être résolu, c'est l'inertie d'un tel projet. Pour le faire évoluer sans casser la rétrocompatibilité, il faut faire des choix et traiter les priorités. On peut ainsi soumettre des bugs ou des idées d'améliorations, et cela peut prendre des années avant que ces soumissions ne soient prises en compte. En voici un exemple avec une amélioration que l'on avait demandé à l'agence pour la gestion des flux RSS de WordPress, et qui aura mis près de 3 ans à être incorporé dans le cœur de WordPress..

Une décision n'est pas toujours idéale pour tout le monde

Autre point clé non spécifique à Gutenberg, c'est qu'une décision est censée convenir et profiter au plus grand nombre, mais pas à tous. Dans certains cas, on peut ainsi avoir une évolution qui va à l'encontre de nos intérêts personnels.

C'est notamment le cas des entreprises qui travaillent avec WordPress, et dont le rythme des mises à jour n'est pas forcément adapté. Prenez par exemple les gros sites utilisant ce CMS : une " simple " mise à jour nécessite des jours de travail : serveurs de développement, tests, recettage, déploiement. Gutenberg n'échappe pas à la règle, d'autant plus que cette mise à jour n'est absolument pas 100% rétro compatible avec les versions majeures précédentes de WordPress et le reste de l'écosystème.

D'ailleurs, le nouveau rythme souhaité pour les versions mineures est d'une mise à jour à minima tous les 15 jours, rythme insoutenable pour certaines structures.

Ceux qui décident peuvent perdre leur motivation

Un projet ne va de l'avant qu'à une condition simple : il faut des personnes motivées pour le faire avancer. WordPress a une taille qui lui permet d'avoir constamment des contributeurs partout dans le monde pour le faire évoluer.

Mais cette motivation peut se perdre. Par exemple, la frustration engendrée par la version 5.0 a pu démotiver certains développeurs actifs (comme le leader de l'équipe accessibilité qui a démissionné). Mais cela peut arriver à n'importe qui, comme très récemment Matt Mullenweg qui a exprimé clairement sa perte de motivation concernant les aspects liés à l'accessibilité (je ne peux le blâmer, tout le monde peut se démotiver, surtout si l'on fait face à de nombreuses critiques) :

Traduction : WordPress est attaqué bien plus souvent que les autres logiciels et services qui sont bien pires [en termes d'accessibilité]. Ces dernières semaines, j'ai perdu la majeure partie de ma motivation concernant ces problématiques, après avoir passé ma vie à les défendre.

Gutenberg est-il un bon choix ?

C'est la question : est-ce que la mise en place de Gutenberg est LA bonne stratégie pour l'avenir de WordPress ?

Je n'aurais pas la réponse à cette question, et personne ne l'aura jamais d'ailleurs. Quand on fait un choix stratégique en marketing, seul le temps nous dira si c'était une bonne solution. Et nous ne saurons jamais si c'était LA meilleure d'entre elles (une autre stratégie pourrait être meilleure).

Si vous écoutez tous ceux qui s'expriment sur le sujet, vous aurez des avis très divergents, basés sur leur propre expérience de Gutenberg, sur leur maîtrise de l'informatique et de WordPress et sur leur rapport avec le CMS ( " je l'utilise ponctuellement, j'ai un blog, je travaille avec, etc. ").

Dois-je mettre à jour vers WordPress 5.0 ?

Non.

En tout cas, pas immédiatement. Il s'agit bien entendu d'un avis personnel qui est donné ici, mais il faut savoir que de très nombreux développeurs et utilisateurs ont le même, y compris parmi les plus connus d'entre eux :

J'aime particulièrement la vision de WPML :

Unless you're missing an adrenaline shot, there's no point in doing a major update right now

Traduction : à moins d'avoir envie d'un shoot d'adrénaline, il n'est pas utile de mettre à jour WordPress maintenant.

Cependant, cette assertion ne sera vraie que pendant quelques temps. D'ici quelques semaines, la plupart des extensions et thèmes se seront théoriquement adaptés, et les utilisateurs et développeurs auront appris à utiliser ce nouvel éditeur.

Notre avis sur Gutenberg

A titre personnel, nous estimons que le nouvel éditeur est une bonne chose pour l'avenir du CMS. Le fait d'uniformiser certains pans entiers de l'interface d'administration de WordPress ne pourra qu'être bénéfique pour l'utilisateur.

Comme indiqué, le vrai problème avec la version 5.0 de WordPress, ce n'est pas ce qu'elle apporte, mais bel et bien la manière dont elle a été mise en place.

D'un point de vue purement référencement naturel, Gutenberg devrait à terme nous permettre de créer bien plus facilement des contenus enrichis et optimisés pour une meilleure visibilité dans les moteurs de recherche. C'est donc une excellente nouvelle. Nous ne sommes d'ailleurs pas les seul à le penser, Yoast est aussi excité que nous sur ce sujet.

Et vous, que faites-vous pour WordPress ?

La critique est toujours constructive. Elle ne fait pas toujours plaisir à entendre mais elle permet de faire avancer et de faire évoluer un projet pour le plus grand nombre. Et j'espère que cet article sera bien perçu en ce sens.

Mais critiquer n'est qu'une étape, il faut ensuite participer (dans la limite de son temps, de sa motivation et de ses domaines d'expertises). Ce que je vous incite tous à faire ici, c'est justement de mettre le pied à l'étrier. Nous pouvons tous contribuer au projet WordPress et à son écosystème, et ceci de plein de façons différentes :

soumettre des bugs ou idées d'amélioration ;
proposer des patchs ;
créer des extensions ou des thèmes ;
devenir conférencier ;
proposer et/ou améliorer des traductions ;
créer un évènement (Meetup, WordCamp, etc.) ;
Écrire des articles ;
Participer aux échanges, sur Twitter, sur Slack, sur le forum de WPFR ou ailleurs ;
Etc.

Regardez notamment cette excellente conférence de JB Audras qui en parle : " Comment contribuer au cœur de WordPress " !

Autres sources non citées dans l'article :

PS : cet article a été rédigé sans Gutenberg ^^

PS2 : et vive WordPress !