Pourquoi WordPress DX a pris du retard – le point de vue honnête d'un développeur

DEV - 01/06
WordPress gère toujours 43 % du Web, mais ouvrir une base de code WordPress 2026 ressemble à un voyage dans le temps. Voici pourquoi l'expérience des développeurs a pris du retard sur les piles modernes : avec du vrai code, pas des prises de vue rapides.

Une version de ceci se trouve également sur mon propre site. (Je travaille sur UnfoldCMS – mais cet article concerne WordPress DX, pas un argumentaire.)

Un développeur rejoint un projet WordPress en 2026. Il ouvrefonctions.php, faites défiler les 800 lignes deajouter_actionetajouter_filter, et ouvrez tranquillement LinkedIn dans un autre onglet.

J'ai vu cela se produire. J'ai été ce développeur. Et je veux être juste : WordPress DX n'est pas mauvais parce que les personnes qui le maintiennent sont mauvaises. C'est dommage car la plateforme a été conçue en 2003, autour de PHP 4, et a depuis lors bénéficié de droits acquis pour chaque décision concernant l'API. L'écart avec les piles modernes ne se réduit pas, il se creuse.

Ce n’est pas une diatribe « WordPress mauvais ». Il s'agit d'un aperçu des raisons pour lesquelles l'expérience du développeur a pris du retard, avec la même tâche écrite dans les deux sens afin que vous puissiez juger par vous-même.

TL;DR : Les problèmes DX de WordPress sont structurels : fonctions globales, hooks et filtres comme modèle d'extension principal, données non typées danswp_postmeta, pas de tests de première classe, la saisie semi-automatique de l'IDE qui meurt à la limite du hook et un modèle de déploiement toujours façonné autour de FTP. Les piles modernes corrigent tout cela par défaut. L'écart décide de votre bassin de recrutement, de la ma...
[Courte citation de 8% de l'article original]