Comment vérifier la version de WordPress - Guide complet

Pour faire un check wordpress version rapide, je commence presque toujours par l’interface d’administration, puis je confirme l’information côté serveur si j’ai le moindre doute. La bonne méthode dépend surtout de l’accès dont tu disposes : tableau de bord, SSH, fichiers du site ou simple navigateur. Dans cet article, je passe en revue les contrôles les plus fiables, ceux qu’il faut éviter de surinterpréter, et la façon de choisir la méthode la plus sûre selon le contexte.

Le moyen le plus rapide dans l’administration WordPress

Si j’ai accès au tableau de bord, je ne cherche pas compliqué. Dans WordPress, l’écran Santé du site affiche une section dédiée au cœur du site avec la version actuellement installée. C’est plus net que de se fier à un détail visuel du tableau de bord, parce que l’information est présentée dans un emplacement explicite.

1. Ouvre Tableau de bord > Mises à jour pour voir si WordPress signale une version plus récente.
2. Va dans Outils > Santé du site > Infos.
3. Déplie la section WordPress.
4. Lis la ligne Version : elle correspond à l’installation active.

Vérifier la version depuis le serveur

Quand j’ai un accès SSH, je passe en mode direct. La commande la plus pratique est wp core version : elle renvoie la version du cœur WordPress installée sur l’hébergement, sans ouvrir le navigateur. Si je veux un peu plus de contexte, j’ajoute --extra, qui affiche des informations utiles au diagnostic.

Le second point que je vérifie, c’est le fichier wp-includes/version.php. C’est là que WordPress stocke la variable $wp_version. En pratique, ce fichier me sert de source locale de référence : si je dois confirmer exactement ce qui est déployé sur le disque, c’est la piste la plus propre.

• WP-CLI : idéal pour une maintenance, un déploiement ou un audit rapide.
• version.php : utile si tu veux contrôler le code réellement présent sur le serveur.
• Limite : si l’hébergement bloque SSH ou si WP-CLI n’est pas installé, cette méthode disparaît tout simplement.

Dans un projet géré proprement, ces deux vérifications se recoupent. Si elles ne donnent pas la même réponse, je considère qu’il y a un décalage entre environnement, déploiement ou cache. C’est précisément là que les indices visibles dans le navigateur deviennent intéressants, mais il faut les lire avec prudence.

Lire les indices visibles dans le navigateur

Le navigateur peut donner de bons indices, mais je les traite comme des indices, pas comme une preuve définitive. Le code source d’une page peut encore contenir une balise générateur WordPress, et certains fichiers publics peuvent laisser apparaître une version dans les chemins ou les paramètres d’assets. Le piège, c’est de croire qu’un indice côté front-end suffit à confirmer l’installation réelle.

• Balise générateur : elle peut révéler WordPress, mais elle est parfois supprimée par des plugins de sécurité ou par un thème.
• Paramètre ?ver= : il est fréquent sur les CSS et les scripts, mais il concerne souvent le fichier chargé, pas forcément la version du cœur.
• Fichiers publics : selon la configuration, ils peuvent montrer une version, mais ils peuvent aussi être masqués, déplacés ou mis en cache.

Mon approche est simple : si l’interface, WP-CLI et les fichiers se contredisent, je ne tranche jamais à partir du code source seul. Je pars du principe qu’un site durci pour la sécurité ou servi derrière un cache agressif peut brouiller les indices visibles. La suite logique consiste donc à choisir la bonne méthode selon le niveau d’accès dont tu disposes.

Choisir la bonne méthode selon ton accès au site

Je recommande rarement de partir du navigateur quand un accès plus propre existe. C’est tentant, parce que c’est immédiat, mais la fiabilité baisse dès qu’un plugin, un cache ou un proxy intermédiaire entre en jeu. Si tu veux éviter les erreurs d’interprétation, traite toujours la hiérarchie de confiance dans cet ordre : admin, serveur, fichiers, puis seulement indices publics.

Ce qu’il faut vérifier juste après

Identifier la version ne suffit pas si ton objectif est de sécuriser une mise à jour. Une version WordPress ancienne n’est pas seulement une question de numéro : elle te dit aussi qu’il faut vérifier la compatibilité du thème, des extensions et de l’environnement serveur. Dans mes audits, c’est souvent là que se cachent les vrais risques.

• PHP : regarde la version utilisée par l’hébergement, parce qu’un WordPress à jour ne compense pas un serveur trop ancien.
• Extensions : une extension critique peut bloquer une mise à jour bien avant le cœur de WordPress.
• Thème : les thèmes surchargés ou abandonnés sont souvent la source des régressions.
• Sauvegarde : fais une sauvegarde complète avant toute mise à niveau, même si tout semble simple.
• Site de préproduction : si le site génère du trafic ou du chiffre d’affaires, teste la version cible ailleurs avant de la déployer.

Je privilégie cette lecture parce qu’une version de WordPress ne vit jamais seule : elle dépend du reste de la pile technique. Une fois ce contrôle fait, il devient beaucoup plus facile de décider si tu peux mettre à jour immédiatement ou si tu dois d’abord corriger l’environnement. C’est aussi la meilleure manière d’éviter les fausses conclusions sur l’état réel du site.

Le petit audit qui évite les mauvaises surprises

Autrement dit, vérifier la version WordPress n’est pas un geste purement administratif. C’est souvent le point de départ d’un audit plus intelligent, plus rapide et, surtout, plus fiable.