WordPress : champion du web, souffre-douleur des devs

On va commencer cash : marre des développeurs qui crachent sur WordPress. Oui, toi là-bas, le petit génie full-stack qui ricane dès qu’on prononce “WP”. Parce que WordPress c’est pas assez hype, pas assez “framework moderne”, c’est bon pour les blogueuses cuisine et les sites web de tonton Roger ? Quelle condescendance… En attendant, ce “jouet” WordPress aligne aujourd’hui plus de 40% de l’ensemble du web. Oui monsieur le snob, pendant que tu méprises ce dinosaure du PHP, lui fait tourner 43,4% des sites web de la planète et 61,3% des sites avec un CMS . Le deuxième du classement (Shopify) plafonne à… 6,7% . Autant dire que WordPress écrase la concurrence. Mais bon, continue de faire la moue et de jurer que “WordPress c’est de la merde”, ça ne t’empêchera pas de tomber dessus à chaque coin d’Internet.

Un peu d’histoire : du blog open-source au mastodonte du web

WordPress n’a pas surgi par magie en dominant le web du jour au lendemain. Remontons en 2001 : un développeur français, Michel Valdrighi, crée un petit moteur de blog nommé b2/cafelog. Ce projet open-source pose les bases de WordPress. Fin 2002, Valdrighi doit abandonner b2 pour raisons personnelles, et deux gars vont reprendre le flambeau . En janvier 2003, l’américain Matt Mullenweg (futur co-fondateur d’Automattic) et l’anglais Mike Little décident de forker b2. Ils corrigent des bugs, ajoutent des fonctionnalités, et préparent une nouvelle version baptisée d’abord B2evolution, puis finalement WordPress (sur suggestion d’une amie de Mullenweg) . Le 27 mai 2003, WordPress 0.7 sort officiellement : le successeur de b2 est né, et même Valdrighi revient contribuer au projet . Cocorico, à l’origine de WordPress il y a un peu de 🇫🇷 !

Les premières versions de WordPress se concentrent sur le blogging. En 2004, la version 1.2 “Mingus” introduit le système d’extensions (plugins) – la toute première s’appelait Hello Dolly, inutile donc indispensable, toujours incluse par tradition. WordPress gagne en popularité grâce à sa simplicité d’installation et une communauté qui commence à créer thèmes et plugins en pagaille. En 2005, WordPress 2.0 “Duke” apporte une refonte de l’admin (et oui, déjà un panneau d’admin clean pendant que d’autres codent encore les leurs). 2008 voit l’arrivée d’une bibliothèque de thèmes officiels  et d’une refonte majeure de l’interface admin (version 2.7 “Coltrane”).

Le tournant arrive en 2010 avec WordPress 3.0 “Thelonious” : cette version fusionne WordPress MU (multi-sites) et, surtout, introduit les Custom Post Types et taxonomies personnalisées. En clair, on n’est plus limité aux articles et pages : on peut définir ses propres types de contenu et organiser tout ça comme on veut. WordPress cesse d’être juste une plateforme de blog pour devenir un CMS à part entière . À partir de là, on voit fleurir des sites vitrine, des portfolios, des magazines en ligne, des boutiques e-commerce (via WooCommerce) – tout ça propulsé par WordPress.

WordPress continue son ascension tout au long des années 2010. En parallèle, la société Automattic (fondée par Mullenweg) sponsorise le développement de l’écosystème, sans pour autant “posséder” WordPress (le projet reste open source, géré par la fondation WordPress). En 2018, la version 5.0 “Bebo” débarque avec un gros changement qui a fait hurler pas mal de puristes : le nouvel éditeur de contenu Gutenberg, basé sur un système de blocs. Fini l’éditeur texte à l’ancienne, place à une interface moderne (développée en React, oui React, le truc à la mode) intégrée directement dans le cœur de WordPress. Gutenberg a introduit une expérience de rédaction modulable : on insère des blocs de texte, d’images, de vidéo, qu’on déplace à la souris – un truc inimaginable dans WordPress quelques années plus tôt. Ça a râlé sec chez certains développeurs (“Quoi, du JavaScript dans mon bon vieux WP ?! Scandale !”), mais aujourd’hui l’éditeur de blocs est bien installé et rend WordPress plus accessible aux néophytes.

Bref, en près de 20 ans, WordPress est passé du statut de petit moteur de blog bricolé dans un coin du web à celui de colosse incontournable. Chaque version majeure porte le nom d’un jazzman (Mingus, Coltrane, Ella, etc.) – détail funky qui n’intéresse peut-être que moi, mais avouez que c’est plus stylé que “v3.6.1”. Et surtout, WordPress a su évoluer (peut-être pas au rythme effréné des frameworks JS, certes) pour rester dans la course : système de plugin robuste, API REST intégrée depuis 2016, éditeur React, support de PHP 8+, etc. Pas mal pour un “vieux” CMS, non ?

Le poids lourd des CMS : WordPress en quelques chiffres qui piquent

Que cela plaise ou non, WordPress domine outrageusement le marché des CMS. Selon W3Techs (le Vatican des stats web), au 16 avril 2025 WordPress alimente 61,3% des sites web qui utilisent un CMS, soit 43,4% de tous les sites web. En gros, presque la moitié d’Internet tourne sous WP. Derrière, c’est le désert : le second CMS le plus utilisé, Shopify, fait à peine 6,7% de parts de marché . Autrement dit, WordPress tout seul est plus utilisé que l’ensemble de ses dix concurrents suivants réunis. On est loin du simple effet de mode : c’est un raz-de-marée.

Quelques autres chiffres pour frimer en société : WordPress propulse plus de 810 millions de sites d’après les estimations. Il est traduit dans locale dizaines de langues, dispose de plus de 59 000 extensions gratuites sur le dépôt officiel (et des milliers d’autres premium ailleurs), et de 10 000+ thèmes prêts à l’emploi. Selon W3Techs toujours, environ 87% des sites WP tournent sur la branche 6.x (la plus récente), signe que malgré sa réputation de “vieux coucou”, le projet sait faire migrer son monde.

Et pour faire taire les mauvaises langues qui prétendent que “WordPress c’est pour les petits sites amateurs, de gros sites l’utilisent aussi. WhiteHouse.gov – oui, le site officiel de la Maison Blanche américaine – a utilisé WordPress sur plusieurs administrations (quand il s’agit de sécurité, ils ne prennent pas un truc bancal, je dis ça je dis rien). Le site Sony Music est sous WordPress, le PlayStation Blog également. TechCrunch (gros média tech international) carbure sous WordPress, tout comme le site Newsroom de Meta/Facebook. La liste est longue : si ces exemples ne suffisent pas à calmer les détracteurs, je ne peux plus rien pour vous. WordPress n’est pas qu’un joujou de débutant, c’est aussi un choix pragmatique fait par des acteurs majeurs du web.

Thèmes, plugins, hooks… un écosystème de développement à part

Comment WordPress permet-il de construire un site web dynamique ? Parlons un peu technique, pour voir ce qu’il a dans le ventre, et pourquoi ce n’est pas juste un “truc de blogueurs”. Les paradigmes de développement WordPress tournent autour de quelques concepts clés.

###Les Thèmes

C’est la couche présentation. Un thème WordPress est un ensemble de fichiers (PHP, CSS, JS…) qui définissent le design et la mise en page du site. En gros, c’est ton “template”. WordPress fournit une structure (the loop, hiérarchie de templates) qui permet au thème d’afficher le contenu. Un développeur peut créer un thème personnalisé pour adapter l’apparence du site aux besoins du client. Les thèmes peuvent être changés en un clic depuis l’admin, ce qui permet de refondre un site sans toucher à son contenu. Tout le HTML généré passe par là, donc un thème bien codé = un site performant et SEO-friendly. Un thème mal codé… eh bien c’est du HTML/PHP en vrac, et là c’est le drame, mais on y reviendra.

Les Extensions (plugins)

C’est la couche fonctionnalités. WordPress propose de base un noyau relativement léger (publication d’articles, gestion des utilisateurs, commentaires…). Les plugins servent à étendre ces fonctionnalités : e-commerce, SEO, formulaires de contact, forums, que sais-je. Il existe des plugins pour tout. Un plugin est un paquet de code PHP qu’on peut activer ou désactiver à la volée. Ils fonctionnent en se “greffant” sur WordPress via les hooks (voir point suivant). La beauté du système, c’est que tu peux ajouter une fonctionnalité complexe sans coder 1000 lignes : il y a probablement déjà un plugin pour ça. L’inverse, c’est aussi un piège : certains sites WordPress finissent avec 50 plugins activés et là bonjour les problèmes (conflits, lenteurs…). D’où l’importance de bien choisir et de ne pas installer n’importe quoi. Mais utilisé intelligemment, le système d’extensions fait gagner un temps fou par rapport à tout recoder from scratch.

Modèle de données

Sous le capot, WordPress, c’est une base de données MySQL avec une douzaine de tables par défaut. La structure est relativement simple (certains diront simpliste) : la table principale wp_posts contient à peu près tout (articles de blog, pages, pièces jointes, et tout type de contenu personnalisé). Une colonne post_type permet de distinguer la nature de chaque contenu. Les métadonnées (custom fields) sont stockées dans wp_postmeta sous forme de paires clé/valeur – pratique pour ajouter des infos (ex: un champ “prix” sur un post de type “Produit”), mais moins performant si on en abuse. On a aussi des tables pour les utilisateurs (wp_users), les commentaires (wp_comments), les termes (wp_terms pour catégories/étiquettes et taxonomies). En gros, pas de schéma relationnel hyper sophistiqué : WordPress privilégie une approche flexible où presque tout peut être un “post” avec des métadonnées. Ça fait hurler les puristes de la BDD, mais force est de constater que ça marche et que ça couvre 90% des besoins sans changer une ligne de schéma. Et si vraiment tu veux créer tes propres tables, tu peux, WordPress n’interdit pas de faire du SQL custom dans un plugin (c’est juste rarement nécessaire). Notons qu’avec l’extension WooCommerce par exemple, on retrouve ce modèle : les produits de la boutique sont gérés comme des custom post types, leurs attributs comme des meta, etc. Ça permet à WooCommerce de s’intégrer complètement dans WordPress sans réinventer la roue.

Les Hooks (actions & filtres)

Voici l’épine dorsale du développement WordPress. Les hooks sont des points d’ancrage dans le code WordPress où les développeurs peuvent “accrocher” leurs propres fonctions. Il y a deux types : les actions et les filtres. Une action permet d’exécuter du code à un moment précis du déroulement (par exemple “après la publication d’un article” ou “à l’affichage du footer”). Un filtre permet de modifier une donnée avant qu’elle soit utilisée ou affichée (par exemple “filtrer le contenu de l’article avant de l’afficher à l’écran”). Concrètement, WordPress appelle do_action('nom_de_action') à divers endroits stratégiques; n’importe quel plugin ou thème peut y attacher une fonction via add_action('nom_de_action', 'ma_fonction'). Pareil pour les filtres avec apply_filters('nom_du_filtre', $maVariable) et add_filter(...). C’est grâce à ce système de hooks que les plugins et thèmes peuvent étendre ou modifier le comportement de WordPress sans toucher au code cœur. Tu veux ajouter un champ personnalisé dans la page de profil utilisateur ? Hop, un hook d’action bien placé. Tu veux filtrer les titres d’articles pour censurer les gros mots ? Hop, un hook de filtre sur the_title. WordPress en comporte des centaines prêts à l’emploi. C’est à la fois puissant et… déroutant quand on débute. Oui, ça peut donner un code éparpillé façon puzzle, où faut suivre à la trace quel hook fait quoi. Mais au moins, ça évite de modifier le core (péché capital qui rendrait impossible les mises à jour). Les hooks sont la base de tout dev WordPress qui se respecte, et maîtriser actions/filtres, c’est obtenir les clés du royaume pour plier WP à sa volonté.

Autres éléments notables

Pour être complet, citons aussi les shortcodes (petits codes style [gallery] qu’un éditeur peut insérer dans le contenu et que WP remplacera dynamiquement par un rendu, pratique avant Gutenberg), l’API REST (depuis WP 4.7, permettant d’interagir avec WordPress en JSON via HTTP, très utile pour faire du headless ou des frontends JS modernes), et le WP-Admin – le fameux back-office WordPress, cette interface d’administration qui, sans développement supplémentaire, permet de gérer utilisateurs, contenus, médias, réglages… C’est quand même un des gros atouts de WP : file-lui une base de données, et pouf, tu as un back-office complet pour gérer ton site. Essaie d’en dire autant de Laravel ou Django sans coder… On y reviendra en comparant avec les stacks full custom, tiens.

En résumé, WordPress offre un squelette clé en main : une base de données, une interface admin, un moteur d’extensions, et un système de templates. Avec ça, on peut déjà faire énormément de choses sans réinventer la roue à chaque projet. Le revers de la médaille, c’est que mal utilisé, ça peut devenir un joyeux bordel (ex: tout coller dans un fichier functions.php du thème sans ordre, multiplier les plugins redondants, etc.). D’où l’intérêt des bonnes pratiques et des outils modernes pour garder un WordPress propre…

WordPress moderne : outils et frameworks pour un dev propre et scalable

Maintenant qu’on a admis que WP est partout et qu’il a de sérieux atouts, attaquons un autre préjugé : “OK WordPress c’est répandu, mais pour un vrai dev c’est insupportable, c’est le bazar, c’est pas maintenable”. Il est vrai qu’historiquement, coder sur WordPress pouvait vite ressembler à un plat de spaghettis : du PHP procédural mélangé à de l’HTML dans les thèmes, pas de gestionnaire de dépendances, des fonctions globales partout… Bonne nouvelle : la communauté a développé tout un écosystème d’outils et de frameworks pour civiliser ce Far West. Voici de quoi faire du développement WordPress professionnel, propre, moderne – si, si, c’est possible :

Themosis : WordPress à la sauce MVC (inspiration Laravel)

Vous rêvez d’un WordPress orienté objet, structuré en MVC avec routes, contrôleurs, vues et tout le toutim ? Themosis est fait pour vous. Il s’agit d’un framework PHP surcouche de WordPress, très inspiré par Laravel. Themosis permet de construire des applications sur WordPress en bénéficiant de standards modernes : système de routing, templates Blade (le moteur de Laravel) ou Twig, utilisation de Composer, organisation du code en modules… Le tout sans sacrifier l’API WordPress. En gros, on garde le meilleur de WP (son cœur, sa flexibilité, son admin) mais on code dans un cadre structuré. Fini le functions.php de 1000 lignes où on colle pêle-mêle nos fonctions custom; fini le HTML mélangé à du PHP cracra dans les templates. Themosis impose une séparation claire des préoccupations et une architecture MVC classique (routes -> contrôleurs -> vues), ce que beaucoup de développeurs pro attendaient pour enfin respirer sous WP . Selon un retour d’expérience chez Fabernovel, “Fini le traditionnel plat de spaghetti mêlant HTML et PHP dans le thème ! Finie la tentation de bourrer le functions.php. Et tout ça en restant fidèle à l’API WordPress… Ça reste moins ambitieux que les frameworks stars, mais très adapté à de nombreux projets qui veulent se lancer rapidement. Et le client bénéficie du fameux back-office WP sans effort de développement.”. Tout est dit. Themosis, en quelque sorte, modernise l’approche du dev WordPress en y ajoutant les standards des frameworks MVC (routing, templating, ORM…). C’est un projet open-source (made in Switzerland 🇨🇭 par Julien Lambé), toujours maintenu à ce jour, et une vraie bouffée d’air frais pour ceux qui aiment WordPress mais veulent coder “propre”. Alors oui, ça demande d’apprendre un cadre spécifique en plus de WordPress lui-même, et ce n’est pas aussi répandu qu’un Laravel pur. Mais pour des projets sur mesure un peu costauds, c’est un excellent compromis.

Bedrock : structurez vos projets WordPress comme des applis modernes

Bedrock n’est pas à proprement parler un framework, c’est un boilerplate (un squelette de projet) proposé par l’équipe Roots. Le pitch : “WordPress devrait être structuré comme une vraie appli PHP moderne”. En pratique, Bedrock fournit une arborescence repensée du projet, avec un répertoire app/ pour le code du site (plugins, thèmes, mu-plugins) séparé du core WP, la gestion des dépendances via Composer, et la prise en charge des variables d’environnement à la Laravel (fichier .env pour configurer la base de données, les clés secrètes, etc.). Au lieu du vrac traditionnel où tout est mélangé, on se retrouve avec par exemple :

my-project/
├── .env (config locale/dev/prod)
├── composer.json (liste des dépendances)
├── web/
│   ├── wp/ (le core WP ici, versionné via Composer)
│   ├── app/
│   │   ├── plugins/
│   │   ├── mu-plugins/
│   │   ├── themes/
│   │   └── uploads/
│   └── wp-config.php (appelant les configs .env selon env)
└── vendor/ (libs PHP installées par Composer)

Avec Bedrock, on gère WordPress lui-même comme une dépendance (oui, on peut installer WordPress via Composer !), ainsi que les plugins et thèmes. Plus besoin de les installer à la main via l’admin ou de les commiter directement : tout est listé dans composer.json, et n’importe quel membre de l’équipe peut recréer l’environnement en un composer install. Ça change la vie en termes de déploiements et de maintenance du projet. Fini les “il manque le plugin X en production” ou “Oups, j’ai modifié un fichier core par erreur” – Composer verrouille les versions, facilite le travail d’équipe et un dépôt Git clean. Bedrock apporte aussi des petits plus de sécurité (en plaçant le core WP hors du répertoire public, on évite l’accès direct à certains fichiers sensibles, et il intègre par exemple wp-password-bcrypt pour un hashing de mdp plus costaud). En somme, Bedrock transforme WordPress en application PHP dignement structurée : config par environnement, dossier de contenu propre, versionnement serein. Pour beaucoup de développeurs, c’est “la façon dont WordPress aurait dû être conçu” dès le départ, dixit certains fans. C’est un projet open-source largement utilisé, sponsorisé même par des boîtes comme WordPress.com et WP Engine. Si vous faites du WordPress sur Git en équipe, honnêtement, jetez un œil à Bedrock, vous ne reviendrez plus au wp-config.php plein de constantes en dur.

Sage : starter theme moderne (Tailwind, Blade et bonnes pratiques)

Toujours par l’équipe Roots, voici Sage : un starter theme ultra-moderne pour WordPress. L’idée est de fournir une base saine pour développer un thème custom de A à Z, en intégrant les outils front-end actuels. Sage** embarque notamment Tailwind CSS (framework CSS utilitaire) et le moteur de templates Blade (hérité de Laravel) par défaut. Le tout est bien sûr configurable si vous préférez Bootstrap ou autre chose, mais ça donne le ton : adieu le vieux PHP spaghetti, Sage propose un thème structuré façon Laravel. On y code les templates en Blade (donc on peut faire de l’héritage de layouts, des composants réutilisables, etc.), tout en ayant accès aux fonctions WordPress à l’intérieur. Sage est également compatible avec l’éditeur de blocs (Gutenberg), et génère même automatiquement un fichier theme.json à partir de la config Tailwind pour aligner les styles de l’éditeur . En clair, c’est un thème hybride qui marrie le meilleur de WP et du moderne : on bénéficie du système de bloc Gutenberg et on peut utiliser un workflow front-end avec Webpack/Vite, NPM, etc. Ah oui, Sage intègre un outil nommé Acorn qui apporte des fonctionnalités Laravel dans WP (par ex, la syntaxe Blade ou la gestion de dépendances), c’est malin. Pour un développeur qui vient d’un univers Symfony/Laravel, utiliser Sage va rendre la création de thèmes WP beaucoup plus agréable, avec un workflow moderne (live reload, compilation SCSS/JS, etc.). Et pour un dev WordPress classique qui n’avait pas encore mis le nez dans ces outils, Sage offre une belle porte d’entrée pour upgrader ses pratiques. Maintenu depuis plus de 14 ans, Sage en est à sa version 10+ et continue d’évoluer. C’est gratuit, open-source, et très documenté. En bref : si vous devez faire un thème WordPress from scratch, n’allez pas réinventer la roue, partez sur Sage et construisez à partir de cette base solide. Vous gagnerez du temps et vous éviterez bien des erreurs de structure.

WP-CLI : administrez WordPress du bout des doigts (et du terminal)

Les vrais devs adorent la ligne de commande, non ? Ça tombe bien, WP-CLI est l’interface en ligne de commande officielle de WordPress. Plutôt que de vous casser les pieds à naviguer dans l’admin web pour faire des tâches répétitives, WP-CLI vous permet de tout faire en quelques commandes shell. Installer WordPress en 1 ligne, mettre à jour le core, ajouter un plugin, créer un utilisateur, exporter la base, chercher/remplacer du texte dans la base, vider le cache… tout ça sans ouvrir un navigateur. Un petit wp plugin install classic-editor --activate et hop, plugin installé et activé en 2 secondes dans votre terminal. Besoin de passer en multisite ? wp core multisite-convert. Besoin de générer 100 faux articles pour vos tests ? wp post generate --count=100. Bref, WP-CLI c’est le couteau suisse du développeur WordPress, indispensable pour automatiser les déploiements, gérer plusieurs sites rapidement, ou simplement gagner du temps au quotidien. Et cerise sur le gâteau, on peut l’étendre avec ses propres commandes (on peut créer un package WP-CLI custom pour ses projets). Donc plus d’excuse “WordPress c’est fait pour cliquer, pas pour scripter” – WP-CLI apporte une vraie philosophie DevOps à l’écosystème WP. À tel point que des outils comme Trellis (encore un projet Roots) l’intègrent pour automatiser l’install serveur, etc. Si vous ne le connaissiez pas et faites du WP, filez sur wp-cli.org, ça va vous changer la vie.

Timber : Twig + WordPress = thèmes propres et développeurs heureux

On termine cette liste d’outils avec Timber. Timber** est un plugin qui vise à améliorer l’expérience de développement de thèmes WordPress en introduisant le moteur de templates Twig. Si vous avez déjà bossé avec Symfony, Laravel ou Django, vous connaissez Twig (ou ses équivalents) : c’est un langage de template qui permet de séparer le HTML de la logique PHP, avec une syntaxe claire pour les boucles, les conditions, etc. Timber s’appuie sur ce concept : “WordPress c’est génial, mais The Loop ne l’est pas” dit leur introduction, alors ils ont intégré Twig dans WordPress pour rendre la vie plus belle . Concrètement, avec Timber, on va pouvoir écrire des fichiers de template .twig pour le thème, et dans le PHP on se contentera de préparer les données puis de les passer au template. Le PHP gère la logique et les données, le Twig gère le HTML – magnifique séparation des responsabilités . Fini le spaghetti de <?php if ( have_posts() ) : while( have_posts() ): the_post(); ?> et autre <?php echo $variable; ?> en plein milieu du HTML. À la place, on aura par exemple un fichier single.twig avec du code du genre :

<h1>{{ post.title }}</h1>
<div class="content">
  {{ post.content }}
</div>
{% if post.custom_field %}
  <p>Champ perso: {{ post.custom_field }}</p>
{% endif %}

Et dans notre single.php (le contrôleur en somme) :

$data = Timber::get_context();
$post = new Timber\Post();
$data['post'] = $post;
Timber::render('single.twig', $data);

Timber aide à créer des thèmes WordPress sur mesure plus rapidement et avec un code plus durable. Le tout en restant compatible avec tout le reste (on peut utiliser les fonctions WP dans Twig via Timber, gérer les menus, les sidebars, etc.). On note que Timber est passé en version 2.x et désormais distribué via Composer (ils ont même dû arrêter de le proposer sur le dépôt officiel WP à cause de ça). Mais ça s’intègre très bien avec Bedrock/Sage ou même sans, du moment qu’on utilise Composer dans son projet. Timber, c’est un peu le pont entre les bonnes pratiques de templating des frameworks modernes et l’écosystème WordPress. Beaucoup de développeurs témoignent que “Timber + Twig ont ravivé leur amour pour WordPress”  – rien que ça. Si vous voulez un thème custom hyper propre, ou migrer un thème existant vers une structure plus claire, essayez Timber. Vos futurs collègues (ou vous-même dans 6 mois) vous remercieront quand ils n’auront pas à déchiffrer du PHP spaghetti.

(Et avant que les esprits chagrins disent “oui mais maintenant avec Gutenberg on peut quasiment se passer de coder des templates…”, je répondrai que Timber reste pertinent pour des sites complexes où Gutenberg ne couvre pas 100% des besoins de présentation, ou pour ceux qui préfèrent maîtriser totalement leur front-end.)

Un WordPress bien structuré vs une stack full-stack : qui fait quoi, et pourquoi pas les deux ?

Récapitulons un peu : on a un WordPress omniprésent, qui a évolué, et tout un tas d’outils pour le rendre plus propre et modulable. Est-ce que ça en fait le saint Graal universel du développement web ? Pas forcément, chaque stack a ses avantages. Mais il est temps de tordre le cou à l’idée que “WordPress = archaïque, nul pour les vrais devs” et “Full-stack sur framework maison = seul choix valable pour du sérieux”.

Les possibilités d’un écosystème WordPress bien structuré

Un WordPress bien configuré, c’est un peu le couteau suisse du web. Tu peux faire un blog basique en 30 minutes, ou un site institutionnel complexe en exploitant à fond les custom post types, ACF, etc. Avec les bons plugins et un peu de code custom, tu couvres énormément de cas d’usage sans partir de zéro. Besoin d’une boutique en ligne ? Un coup de WooCommerce et tu as une base e-commerce robuste (paiements, gestion de stock, etc.) intégrée directement. Besoin d’un SEO correct ? Yoast SEO ou RankMath et t’as déjà tout un panel d’optimisations dispo. Un site multi-langue ? Polylang ou WPML et roule (bon courage pour coder ça from scratch). WordPress te file gratuitement tout un tas de fonctionnalités qu’en full-stack custom tu devrais développer ou assembler toi-même : système de gestion d’utilisateurs avec rôles et permissions, médiathèque, éditeur WYSIWYG, révisions de contenu, programmation de publications, commentaires, recherche interne, etc. Franchement, réinventer la roue sur tous ces sujets c’est fun 5 minutes, mais en prod tu es bien content que WordPress l’ait déjà fait pour toi de manière globale et testée par des millions d’utilisateurs.

Avec les frameworks et bonnes pratiques qu’on a vus (Themosis, Bedrock, etc.), on peut obtenir un WordPress modulaire, versionné, industrialisé. Un projet WordPress bien mené peut avoir sa CI/CD, ses tests (oui on peut tester du code WP, il y a même une librairie WP_Mock ou simplement PHPUnit + un bootstrap WP), son déploiement automatisé via Composer/WP-CLI. En termes de scalabilité, un WordPress peut encaisser de très grosses charges pour peu qu’on mette en place du cache (ex: plugin WP Super Cache ou directement Varnish), et qu’on scale horizontalement la partie web (puisque la partie état est dans la base de données). La base MySQL peut devenir un goulot d’étranglement, certes, mais il existe des solutions (replication master/slave, cache d’objets persistant type Redis). D’ailleurs, de très gros sites médias (cités plus haut) tournent sur WordPress, preuve qu’on peut le faire monter en charge. Donc l’argument “WordPress ça tient pas la charge” est un peu daté – mal configuré, il peut avoir des soucis (comme n’importe quelle appli mal faite en fait). Bien optimisé, ça peut servir des millions de pages vues sans broncher.

Comparaison avec une approche full-stack moderne

Opposons-le au “full-stack moderne” dont raffolent nos détracteurs. Par là, on entend typiquement un framework backend (Laravel, Symfony, Express, Django, whatever) + un frontend JS (React, Vue, Svelte…) + éventuellement une API GraphQL, etc. C’est super puissant, modulable, tout ce qu’on veut. Mais soyons honnêtes : est-ce toujours pertinent pour le type de projet qu’on réalise ? Si tu dois sortir un site web de contenu classique (quelques pages statiques, un blog actu, un formulaire de contact), tu vas t’amuser à coder un backend Node + un frontend React SSR pour ça ? Tu vas y passer 3 mois là où WordPress t’aurait filé 90% du truc en standard. Tout ça pour quoi, avoir le plaisir intellectuel d’éviter WordPress ? C’est un luxe que peu de clients sont prêts à payer. La stack full custom se justifie pour des applications web avec une logique métier très spécifique, ou des besoins de performance très pointus sur certaines fonctionnalités, etc. Mais pour un site de contenu, WordPress reste souvent le choix le plus rationnel. D’ailleurs, c’est rigolo de voir nombre de startups hyper techno avoir leur site marketing ou blog corporate sous WordPress, pendant que leur produit principal tourne sur du Node/Go/etc. On utilise l’outil adapté à la tâche : WP pour le site web info, et le stack custom pour le cœur applicatif. Eh oui : WordPress et le “full-stack moderne” peuvent tout à fait cohabiter.

Exemple concret d’approche hybride : tu veux un frontend ultra-smooth en React/Vue parce que c’est tendance ou parce que ton projet le nécessite (application web riche). Pas de souci : WordPress peut servir de headless CMS. Tu le laisses gérer toute la partie admin et contenu (tes rédacteurs l’adoreront comparé à un back-office maison minimaliste), et tu consommes ses données via l’API REST (ou GraphQL avec un plugin comme WPGraphQL). Ton front se connecte à WP comme il le ferait à n’importe quelle API. Tu as même des frameworks dédiés comme Next.js qui ont des exemples pour consommer du WordPress headless, ou des starters genre Frontity (React) – bien que Frontity ait été racheté et repositionné, signe que WP headless intéresse du monde. Au final, tu as le beurre et l’argent du beurre : une UX front sur-mesure ET la facilité de gestion de contenu de WordPress.

Alors, on fait la paix ?

Le but ici n’est pas de dire que WordPress est meilleur que les autres solutions en toutes circonstances. C’est de montrer qu’il n’est pas le jouet archaïque que certains aiment dépeindre. Oui, WordPress c’est du PHP, oui il traîne des bouts de code pas très jolis pour assurer la rétrocompatibilité, oui son écosystème peut produire du code immonde si on fait n’importe quoi. Mais avec méthode et outillage, WordPress peut tout à fait s’inscrire dans un workflow de développement moderne, propre, collaboratif. Et en retour, il apporte quelque chose de précieux : la productivité sur tout ce qui est générique (gestion de contenu, auth, etc.) et la richesse fonctionnelle d’un écosystème mature (plugins à gogo, communauté gigantesque, documentation à foison).

Plutôt que de mépriser, le bon développeur est celui qui sait choisir le bon outil pour le bon projet. Parfois ce sera un framework maison hyper optimisé, parfois ce sera un WordPress bien fichu, parfois un mix des deux. Il n’y a pas de honte à utiliser WordPress pour ce qu’il fait de mieux. Ce n’est pas être un “mauvais dev” que de préférer éviter de recoder pour la énième fois un système de login ou un back-office de gestion d’articles. C’est peut-être même l’inverse : c’est avoir la sagesse de réutiliser une solution éprouvée et de se concentrer sur la vraie valeur ajoutée.

Alors oui, on peut continuer la petite guerre de chapelles (les “vrais devs” vs les “intégrateurs WordPress”). Mais à la fin de la journée, ce qui compte, c’est le résultat. Et WordPress, aussi agaçant soit-il pour ton ego de technicien, livre des résultats. Il fait tourner un site de façon stable en un temps record. Il permet à des non-développeurs de gérer leur contenu en autonomie. Il a ses défauts (sécurité : si on ne met pas à jour, on ouvre des portes, mais ça c’est la responsabilité de tout logiciel ; performance : ça dépend plus de comment on l’héberge et l’optimise que de WordPress lui-même). Mais il a prouvé qu’il pouvait évoluer et rester pertinent.

Le mot de la fin

En gros, arrête un peu de faire ta diva du code. La prochaine fois que tu craches sur WordPress en soirée, rappelle-toi qu’il y a 1 chance sur 3 pour que le site sur lequel tu as lu tes tutos préférés tourne… sur WordPress. Le karma bitch, tu connais ? WordPress est peut-être loin d’être parfait, mais il a une qualité incontestable : il existe, il marche, et il rend service à la moitié du web. Alors on dit merci qui ? Merci Michel, Matt et Mike. Et on range son mépris gratuit au placard. Parce qu’au final, le meilleur outil, c’est celui qui te permet de livrer un projet qui roule, qui plaît à ton client, et qui ne te réveille pas chaque nuit en sueur. Et si pour toi cet outil c’est WordPress, tu n’as pas à en rougir – tu devrais même en être fier !