Versions de WordPress : décryptage des évolutions clés

Après plus de douze ans à construire des sites sous WordPress, j’ai traversé pratiquement toutes les mises à jour majeures du CMS. De la version 3.0 qui a introduit les custom post types jusqu’aux dernières releases orientées Full Site Editing, chaque version a redéfini ma façon de travailler. Dans cet article, je vous propose un décryptage complet des versions de WordPress, leur historique, leurs évolutions techniques et ce qui vous attend pour la suite.

Historique complet des versions de WordPress

WordPress a vu le jour en mai 2003, créé par Matt Mullenweg et Mike Little comme un fork du projet b2/cafelog. Depuis cette première release, le CMS a publié plus de 190 versions, chacune nommée d’après un musicien de jazz, une tradition qui perdure encore aujourd’hui.

Je me souviens de mes débuts en 2014 sur WordPress 3.9 « Smith ». À l’époque, l’éditeur visuel venait tout juste d’être amélioré avec TinyMCE 4.0 et on découvrait les prévisualisations de widgets en temps réel. Comparé à ce que propose le CMS aujourd’hui, c’était rudimentaire, mais déjà révolutionnaire pour la création de contenu accessible à tous.

Les premières versions (1.x à 2.x) ont posé les fondations : système de plugins, thèmes, pages statiques, gestion des rôles utilisateurs. C’est à partir de la branche 3.x que WordPress est véritablement devenu une plateforme de gestion de contenu complète, capable de rivaliser avec des CMS entreprise comme Drupal ou Joomla.

La philosophie de versioning de WordPress suit un schéma simple : les versions majeures (5.0, 6.0, 6.5) apportent de nouvelles fonctionnalités, tandis que les versions mineures (6.8.1, 6.8.2, 6.8.3) corrigent des bugs et des failles de sécurité. Vous pouvez consulter l’archive officielle des releases WordPress pour retrouver l’intégralité des versions publiées.

Les versions majeures qui ont tout changé

Parmi les dizaines de versions majeures, certaines ont littéralement redéfini l’écosystème. Voici celles que je considère comme les plus marquantes après des années de pratique quotidienne.

WordPress 3.0 « Thelonious » (2010) a été un tournant. L’introduction des custom post types, des menus personnalisés et la fusion de WordPress MU dans le core (multisite) ont transformé WordPress d’un simple outil de blog en un véritable CMS polyvalent. C’est à partir de cette version que j’ai commencé à construire des sites complexes : annuaires, portfolios, intranets d’entreprise.

WordPress 4.0 « Benny » (2014) a apporté une meilleure expérience d’écriture avec l’éditeur enrichi, l’embed automatique des médias et l’installation de plugins depuis le tableau de bord. Pour les développeurs comme moi, l’arrivée de la REST API dans les versions 4.x suivantes a ouvert la porte aux architectures headless et aux applications JavaScript connectées au back-end WordPress.

WordPress 5.0 « Bebo » (2018) reste la version la plus controversée de l’histoire du CMS. L’introduction de Gutenberg, le nouvel éditeur par blocs, a divisé la communauté. J’avoue avoir résisté au départ, habitué à l’efficacité de l’éditeur classique combiné à des page builders comme Divi. Avec le recul, cette décision stratégique s’est avérée pertinente pour l’avenir du CMS.

WordPress 6.0 à 6.5 ont progressivement enrichi l’éditeur de site complet (Full Site Editing), ajouté le fichier theme.json pour la configuration centralisée des thèmes, et amélioré significativement les performances du core. La version 6.3 a notamment introduit le Command Palette, un raccourci clavier inspiré de VS Code que j’utilise désormais au quotidien.

Gutenberg et le Full Site Editing : la grande transition

Le projet Gutenberg est sans doute la transformation la plus ambitieuse jamais entreprise par WordPress. Découpé en quatre phases, il vise à repenser entièrement la façon dont on crée et personnalise un site.

La phase 1 (WordPress 5.0+) a remplacé l’éditeur classique par l’éditeur de blocs pour le contenu. La phase 2 (WordPress 5.9 à 6.x) a étendu ce système aux templates, aux en-têtes, aux pieds de page et à l’ensemble du site via le Full Site Editing. La phase 3, en cours, se concentre sur la collaboration en temps réel et les workflows éditoriaux avancés. La phase 4 ciblera le multilingue natif.

En pratique, le Full Site Editing change radicalement mon approche du développement de thèmes. Là où je codais auparavant des templates PHP avec des fonctions comme get_header() et the_content(), je construis désormais des block themes déclaratifs via theme.json et des templates HTML composés de blocs. C’est un changement de paradigme que tout expert WordPress doit maîtriser.

Pour les utilisateurs finaux, le bénéfice est concret : plus besoin d’un page builder tiers pour personnaliser l’en-tête ou le pied de page. L’éditeur natif offre désormais une expérience WYSIWYG complète directement depuis l’administration. Si vous travaillez sur l’optimisation de votre site, je vous recommande aussi de consulter mon guide sur le SEO WordPress pour tirer le meilleur parti de ces nouvelles fonctionnalités.

Version actuelle de WordPress : nouveautés et performances

À la date de rédaction de cet article, la version stable la plus récente est WordPress 6.8.x. Cette branche a apporté plusieurs améliorations notables qui méritent votre attention.

La version 6.8 a notamment introduit un système de style global amélioré, des performances de chargement optimisées grâce à une meilleure gestion du lazy loading et des scripts différés, ainsi que de nouvelles options de personnalisation dans l’éditeur de site. Le WordPress core a aussi bénéficié d’un travail important sur l’accessibilité, avec plus de 60 corrections dans cette seule release.

Les versions de maintenance comme 6.8.1, 6.8.2 et 6.8.3 ont corrigé des vulnérabilités de sécurité et des régressions. Je ne le répéterai jamais assez : appliquer ces mises à jour mineures est indispensable. En tant que développeur, j’utilise WP-CLI pour automatiser ces mises à jour sur les dizaines de sites que je maintiens.

Côté performances, WordPress 6.8 affiche des gains mesurables. Les temps de réponse du back-end ont diminué de 15 à 20 % sur les configurations standard grâce à l’optimisation des requêtes SQL et du système de cache objet. Pour un site e-commerce, cela se traduit directement par un meilleur taux de conversion, un point que j’aborde aussi dans mon article sur les fondamentaux du e-commerce.

Compatibilité PHP et exigences techniques par version

La relation entre les versions de WordPress et PHP est un sujet que je traite quotidiennement avec mes clients. Beaucoup de sites tournent encore sur des versions de PHP obsolètes, ce qui pose des problèmes de sécurité et de performances.

Mon conseil est clair : si votre hébergeur propose PHP 8.2 ou 8.3, activez-le. Les gains de performance sont significatifs (jusqu’à 30 % de temps d’exécution en moins comparé à PHP 7.4) et la sécurité est renforcée. Avant toute mise à jour PHP, testez vos plugins et votre thème sur un environnement de staging. J’utilise systématiquement le plugin PHP Compatibility Checker pour identifier les incompatibilités potentielles avant de basculer.

La documentation officielle de WordPress en français détaille les exigences techniques pour chaque version majeure. Je vous recommande de la consulter avant toute mise à jour importante.

WordPress 7 et la feuille de route à venir

La communauté WordPress attend avec impatience l’arrivée de WordPress 7, une version qui devrait marquer un nouveau cap dans l’évolution du CMS. Si les détails précis ne sont pas encore tous confirmés, la feuille de route laisse entrevoir plusieurs axes majeurs.

Le premier axe concerne la finalisation du Full Site Editing avec une expérience utilisateur véritablement unifiée. L’objectif est de proposer une interface d’édition fluide où la distinction entre contenu, templates et styles globaux s’efface complètement. En tant que développeur, j’attends particulièrement l’amélioration de l’API des blocs et une meilleure interopérabilité entre les blocs natifs et les blocs tiers.

Le deuxième axe est la collaboration en temps réel (phase 3 de Gutenberg). Imaginez plusieurs rédacteurs travaillant simultanément sur le même article, comme dans Google Docs. Cette fonctionnalité, très demandée par les équipes éditoriales, nécessite une refonte profonde de l’architecture de persistance du contenu.

Troisième axe : le multilingue natif (phase 4 de Gutenberg). Actuellement, la gestion multilingue repose sur des plugins comme WPML ou Polylang. L’intégration directe dans le core simplifierait considérablement le développement de sites internationaux, un besoin que je rencontre sur la majorité de mes projets clients.

Enfin, des discussions sont en cours autour d’une modernisation du core PHP, avec l’abandon progressif du support des versions PHP les plus anciennes et l’adoption de fonctionnalités modernes comme les attributs PHP 8, les types natifs et les fibres. Pour suivre l’avancement, je vous recommande de consulter régulièrement le blog Make WordPress Core.

Les différents types de WordPress et leurs usages

Quand on parle de « types de WordPress », il faut distinguer plusieurs réalités que mes clients confondent régulièrement.

WordPress.org est le logiciel open source que vous téléchargez et installez sur votre propre hébergement. C’est la version que j’utilise et recommande pour tous les projets professionnels. Elle offre un contrôle total sur le code, les données et la personnalisation. Si vous réalisez un audit SEO WordPress, c’est cette version qui vous donne accès à l’ensemble des leviers d’optimisation.

WordPress.com est une plateforme hébergée par Automattic (la société de Matt Mullenweg) qui propose WordPress en mode SaaS. Elle existe en plusieurs plans : gratuit (très limité), Personal, Premium, Business et eCommerce. Seuls les plans Business et supérieurs permettent d’installer des plugins et thèmes personnalisés. Pour un site vitrine simple sans ambition technique, c’est une option viable. Pour tout le reste, WordPress.org reste le choix évident.

WordPress Multisite est une fonctionnalité intégrée au core qui permet de gérer un réseau de sites depuis une seule installation. Je l’utilise pour des clients qui gèrent plusieurs marques ou sites régionaux. L’administration centralisée des mises à jour et des plugins fait gagner un temps considérable.

WordPress headless désigne une architecture où WordPress sert uniquement de back-end (API REST ou WPGraphQL) tandis que le front-end est développé avec un framework JavaScript comme React, Vue.js ou Next.js. C’est une approche que j’adopte de plus en plus pour les projets nécessitant des performances front-end exceptionnelles ou une expérience utilisateur type application web.

WordPress est-il obsolète en 2026 ?

C’est une question que l’on me pose de plus en plus, et ma réponse est nuancée mais claire : non, WordPress n’est pas obsolète en 2026. Cependant, il fait face à des défis réels qui méritent d’être examinés.

Avec 43 % de parts de marché sur l’ensemble des sites web et plus de 60 % parmi les sites utilisant un CMS identifiable, WordPress reste le leader incontesté. Son écosystème de plus de 59 000 plugins et 12 000 thèmes est sans équivalent. La communauté de contributeurs compte des milliers de développeurs actifs à travers le monde.

Cela dit, la concurrence s’est renforcée. Des plateformes comme Webflow, Framer ou des CMS headless comme Strapi et Contentful attirent les développeurs qui cherchent des architectures modernes. Certains reprochent à WordPress une dette technique liée à sa rétrocompatibilité avec PHP 7.x, un éditeur de blocs qui reste perfectible et des performances natives en retrait face aux sites statiques générés avec des frameworks comme Astro ou Hugo.

Pourquoi certains s’éloignent-ils de WordPress ? Les raisons les plus fréquentes que je constate sont : la complexité de maintenance (mises à jour du core, des plugins, du thème, de PHP), les problèmes de sécurité liés aux plugins mal maintenus, et la courbe d’apprentissage de Gutenberg qui a déstabilisé des utilisateurs habitués à l’éditeur classique. Pour un développeur freelance, ces contraintes se transforment en opportunités de service.

Mon avis de praticien : WordPress reste le meilleur choix pour la majorité des projets web en 2026. Sa flexibilité, son écosystème et sa communauté sont des atouts irremplaçables. Les alternatives brillent sur des niches spécifiques, mais aucune n’offre la polyvalence de WordPress. Pour maximiser le potentiel de votre site, je recommande de travailler avec un consultant SEO WordPress et de faire appel aux bonnes extensions SEO.

Gérer les mises à jour WordPress en pratique

La gestion des mises à jour est le nerf de la guerre pour tout site WordPress en production. Voici la méthodologie que j’applique systématiquement sur les projets que je maintiens.

Étape 1 : sauvegarde complète. Avant toute mise à jour, je réalise un backup intégral (fichiers + base de données). J’utilise WP-CLI avec la commande wp db export combinée à un rsync des fichiers. Pour les clients qui préfèrent une solution graphique, UpdraftPlus fait très bien le travail.

Étape 2 : test en staging. Je ne mets jamais à jour un site en production sans avoir d’abord testé sur un environnement de staging. La plupart des hébergeurs WordPress proposent aujourd’hui un système de staging en un clic. C’est indispensable pour détecter les incompatibilités entre plugins, thèmes et la nouvelle version du core.

Étape 3 : mise à jour séquentielle. Je mets d’abord à jour les plugins un par un, puis le thème, et enfin le core WordPress. Cette approche séquentielle permet d’isoler rapidement la source d’un éventuel problème. Avec WP-CLI, la commande wp plugin update --all est tentante, mais je la déconseille en production.

Étape 4 : vérification post-mise à jour. Je contrôle le site front-end (pages clés, formulaires, checkout si e-commerce), les logs d’erreur PHP et les performances via des outils comme Query Monitor. Si tout fonctionne, je déploie en production.

Pour les mises à jour de sécurité mineures, WordPress propose des mises à jour automatiques activées par défaut depuis la version 3.7. Je recommande de les laisser activées : le risque d’une faille non corrigée est bien supérieur au risque d’une régression sur un patch de sécurité.