Tout le monde le sait, on l’entend chaque année, voire chaque mois, si ce n’est pas chaque semaine : WordPress est le CMS le plus exploité au monde. Malheureusement (ou pas), c’est une réalité et il est utilisé à ce jour, à la louche, par 35 % du premier million de sites webs au monde. Mais disons-le, de manière générale, quand vous naviguez sur internet, vous avez 1 chance sur 3 ou 4 de tomber sur un site qui utilise WordPress : c’est presque la vérité.
Pour ceux qui me connaissent, vous savez déjà que cet article ne va pas être un article à charge, bien au contraire. Je suis un utilisateur de WordPress mais je sais aussi faire la part des choses. Il est adapté pour beaucoup de sites (qu’ils soient vitrine, média, e-commerce, etc…) mais ce n’est pas toujours la meilleure solution. Tout comme la diversité des langages : on pourrait très facilement se dire qu’il suffit de prendre JavaScript ou PHP pour du web car il est adapté pour tous les sites, mais… ce n’est pas toujours le cas. Mais alors, pourquoi WordPress est-il détesté par les développeurs au même titre que les gens apprécient détester PHP ?
Le développement et la technique c’est comme la réalité, quand c’est vieux et qu’il y a de la dette ça coûte cher ; ce n’est pas le prix des établissements spécialisés pour nos amis les seniors qui diront le contraire. En ce qui concerne WordPress, clairement, c’est un dinosaure. La première version est arrivé en 2003 et… c’est du PHP. Vous combinez les deux et on tombe sur quelque chose d’imparfait, ou plutôt, une atrocité qui n’a pas le mérite de vivre aux yeux des puristes chevronnés qui préfèrent encore monter un serveur web en C (non sans déconner, ne faites pas ça juste pour un blog) que de penser à l’essentiel : de quoi avez-vous besoin ?
Suite à cela et au vu de son évolution sur plus de 16 ans, WordPress se heurte donc à une problématique réelle : c’est de la merde. C’est vieux, alors c’est forcément moisi et ce n’est pas à la mode. De ce point de vue là et sachant que nous aimons tellement critiquer et troller dans ce monde, WordPress n’a plus qu’a subir les foudres des développeurs vaillants et forts pour qui c’est une honte d’utiliser cette technologie. Alors, petite aparté… mettre plus de 10 minutes pour installer et mettre en place juste un blog ne vous fait-il pas honte en 2019 ? Personnellement, à part pour des raisons de R&D, de plaisir personnel ou de démonstration, l’écosystème de WordPress permet à n’importe qui (même non développeur) de mettre environ 10 minutes pour installer son blog ou son site vitrine, et être en ligne et ça, c’est stylé.
Malgré tout mon amour pour l’utilisation de ce CMS dont j’ai du mal a me séparer pour des utilisations diverses et variées, on a de quoi en dire long sur le code source de WordPress (en PHP, ne l’oublions pas, ce n’est pas un vrai langage), au point de le résumer en disant : c’est de la merde.
Il subit une dette technique longue comme le bras au niveau de sa conception sur beaucoup de choses. En même temps, rappelons-le, il a 16 ans. De fait, il est sujet à des discussions sans fin autour des concepts de la programmation en général et des façons de faire. Quand on voit la taille des fichiers ou même de certaines fonctions, il faut s’accrocher pour rester debout et ne pas perdre le fil. A ce sujet, je suis généralement du côté des puristes et si je tiens à mon coeur, j’évite d’ouvrir certains fichiers dans le core.
Mais, qu’on le veuille ou non, WordPress répond à un besoin : créer et faciliter la gestion d’un site ou plus généralement, d’une application web. C’est un outil qui, comme un framework, doit vous permettre d’accélérer votre développement et votre projet (parce que c’est notre… Ok ). Il est rangé dans ce que l’on appelle un système de gestion de contenu. Or, dans cette dernière phrase, a quel moment le mot contenu doit faire obligatoirement référence à blogging ? A moins d’en avoir oublié mon Larousse, tout type d’information est une forme de contenu. Une ligne de facturation est un contenu, un article est un contenu, un produit est un contenu. Et si WordPress en est là aujourd’hui, malgré ce code bouillonnant, c’est parce qu’au final…. il est simple !
Que vous le vouliez ou non, si PHP et WordPress sont 2 technologies très utilisées ce n’est pas par plaisir de vous faire chier, c’est parce que tous les 2 ont une chose en commun : la simplicité. Derrière ce mot, on retrouve quelque chose qu’on apprécie de voir aujourd’hui dans certaines de nos startups : la simplicité d’une fonctionnalité, d’un projet. On le retrouve également dans ce que l’on aime voir sur les sites web, une bonne expérience utilisateur : la simplicité. De ce fait, il est majoritairement accessible, utilisé, et surtout, ça marche, et ça marche bien.
Continuons dans les stéréotypes car je sens que notre ami Bob le puriste n’accepte pas encore que WordPress soit une solution viable.
L’ajout d’extensions WordPress impact, soit disant, la performance de votre site. En tant que bon développeur, je dirais bien que : oui et non, ça dépend.
Tout d’abord, il faut bien comprendre que la force de WordPress réside également dans son répertoire de plugins où l’on y trouve de tout, du bon et du moins bon (de la merde, encore et toujours). Si vous ajoutez tout et n’importe quoi, il va de soit que vous vous exposez à des problématiques de performances mais aussi de sécurité car c’est du code provenant de l’extérieur qui vient modifier et interagir avec votre installation. Mais dites moi… les modules PHP avec composer ou les bons vieux node_modules pour le JS… ce n’est pas pareil ? Et bien si. J’adore le JavaScript, sachez le, mais les node_modules… en comparaison, un trou noir dans la galaxie c’est une goutte d’eau. Tous modules externes à votre code est l’équivalent d’un plugin qui peut impacter la performance et la sécurité de votre application.
Maintenant, admettons que toutes les extensions WordPress soient potables et n’aient pas de problèmes et que vous en installiez… 200 ! Et bien encore une fois, sachez que si tout est en ordre, ça ne fera ni chaud ni froid à votre site. Prenez le plugin “Hello” et dupliquez le 200 fois, vous verrez, ça ne change rien. Le nombre de plugins n’a aucune corrélation avec la performance. En réalité, le seul dénominateur commun entre la performance et la sécurité c’est ce que j’appelle un code 18. 18 cm c’est la distance qui sépare le problème qui se situe entre la chaise et le clavier. Autrement dit : le développeur.
Relativement, plus vous récupérez et installez des choses de l’extérieur sans y faire attention, plus vous augmentez le risque d’impliquer la performance et la sécurité de votre site. C’est un peu comme si, pour construire quelque chose dans la réalité (votre maison par exemple ?), vous achetiez tout et n’importe quoi sans regarder, ni la provenance, ni l’utilité, ni la qualité et que vous vous faisiez livrer le tout sous la forme d’un tas de merde dans votre jardin. Quoi, vous ne faites pas ça ? Et bien alors ne le faites pas non plus pour votre site.
Il faut aussi imaginer qu’il existe de très bonnes agences WordPress et développeurs WordPress qui se servent des plugins pour développer et industrialiser leur développement. L’objectif étant de pouvoir réutiliser différentes fonctionnalités pour différents clients. Que ce soit fait dans le thème ou dans un plugin, au final, ça ne changera en rien la performance ou la sécurité. S’il y a un problème on revient au fondamental : l’erreur dans le code générée par un développeur.
Maintenant qu’on a bien dégrossi le sujet… Clairement on se demande au final si les gens ne détestent pas WordPress pour le simple plaisir de le détester (surtout quand on est Français, il faut trouver matière a râler ?). Je dirais que généralement, ces gens-là, sont fermés d’esprit et ignorent complètement le potentiel et ce que l’on peut faire avec cet outil. Ce qui est paradoxal c’est qu’ils en oublient le fondamental : un système de gestion de contenu.
Alors, bien évidemment vous avez le droit de ne pas aimer le CMS et de ne pas vouloir l’utiliser comme je ne souhaite pas utiliser SPIP ou Joomla (désolé, mais c’est de la daube #troll). En revanche il y a plusieurs points non négligeables qui font de WordPress un outil formidable.
Les évolutions du CMS ne cessent pas. La communauté est monstrueuse et l’activité autour de la contribution de cet outil est forte. Que ce soit par des évènements locaux, nationaux ou mondiaux, l’implication de différents acteurs a tous les niveaux : l’accessibilité, la traduction, le développement, le SEO etc… C’est un acteur majeur et ce n’est pas pour rien que la plupart des géants ont généralement un WordPress installé quelque part. Google, lui-même, privilégie certains supports quand ça ne fonctionne pas avec WordPress ! C’est dire l’importance du CMS. Quand on voit un blog comme TechCrunch qui utilise brillamment le CMS dans une logique (semi ?) headless, et bien d’autres grand sites, je trouve cela intéressant.
A titre personnel, j’utilise essentiellement WordPress comme un backend puissant, rapide et facile d’utilisation. Mon interface est généralement chargé en NextJS / ReactJS et je consomme les données du CMS à travers une API. Alors oui, l’API Rest native n’est pas forcément la meilleure (je suis le premier à ne pas l’aimer totalement) mais qu’est-ce qui vous empêche de créer des briques de votre côté pour pallier certains problèmes ?
Enfin, je terminerai par le sujet qui lui même fait débat au sein des utilisateurs WordPress : Gutenberg. Sache, Bob le puriste, que techniquement parlant, cet outil est génial et il est en ReactJS. Il est tellement génial que Drupal l’utilise… c’est fort ! Et personnellement, je suis totalement en adéquation avec ce que propose Gutenberg aujourd’hui et son évolution. C’est un outil puissant et je ne m’imagine pas revenir une seule seconde en arrière sur l’ancien éditeur. Que ce soit du côté utilisateur ou développeur. Pour ceux qui ne sont pas d’accord, c’est un tout autre sujet dont je ne parlerais pas dans cet article. Libre à chacun de penser ce qu’il veut, que ce soit de WordPress ou de Gutenberg. Pour ce qui est du CMS, oui, on peut faire des sites avec des millions de pages vues par jour, oui on peut avoir une base de données optimisée, oui on peut avoir des projets extrêmement bien développés dessus. Est-ce que c’est tout le temps cette solution qu’il faut prendre ? Pas forcément. Mais c’est un choix qui peut être fait pour 99 % des sites. Vous ne l’imaginez juste pas et c’est plus facile de le critiquer. A l’échelle du web et du développement, c’est le même genre de choix que l’on peut faire au niveau des langages en choisissant du python (Django ou autre), du ruby (Rails ou autre), du php (Symfony, Laravel ou autre), du .NET, du Java, du JavaScript, etc… et une réponse ne peut pas se résumer à : c’est de la merde. Surtout quand une technologie évolue en permanence (n’est-ce pas PHP ? le pauvre, on le déteste…).