Comment vérifier la version de PHP et sur quoi tourne votre site

Vérifier les versions de PHP, Node.js, du CMS et des extensions sans développeur : hébergeur, tableau de bord WordPress, en-têtes et versions prises en charge.

Illustration : un serveur avec des étiquettes de version, une loupe au-dessus d’une fenêtre de navigateur et un porte-bloc avec une liste de contrôle
Illustration générée par IA

Quand tombe une nouvelle sur une faille dans PHP, Node.js ou une extension populaire, la première question est : cela concerne-t-il mon site ? La réponse dépend de quelques numéros de version, rarement notés quelque part. Sans eux, vous ne pouvez pas évaluer le risque, et la discussion avec l’hébergeur ou le prestataire commence par un échange d’e-mails pleins de questions.

Dans ce guide, je montre comment vérifier la version de PHP, de Node.js, du CMS et des extensions, la plupart du temps sans développeur, et tout noter dans une courte fiche d’identité du site. État des connaissances : 6 novembre 2026. Les dates de support et les versions corrigées peuvent changer : avant de décider, vérifiez-les donc sur le site de l’éditeur.

Quatre choses à savoir sur votre site

Tout site se compose de plusieurs couches de logiciels. Chacune a son propre numéro de version et ses propres correctifs de sécurité, et une faille ne concerne généralement qu’une seule d’entre elles.

  1. Le serveur web, c’est-à-dire le programme qui envoie le site au navigateur : le plus souvent nginx, Apache ou LiteSpeed.
  2. Le langage dans lequel tourne le site : PHP (WordPress, WooCommerce, PrestaShop, Joomla) ou Node.js (Next.js, Nuxt, Express).
  3. Le CMS ou le framework : WordPress, PrestaShop, Next.js et similaires.
  4. Les compléments : extensions, thème, modules de boutique et bibliothèques.

Sur un hébergement mutualisé, le serveur web est généralement géré par l’hébergeur, vous choisissez souvent vous-même la version de PHP dans le panneau, et le CMS et les extensions sont l’affaire du propriétaire du site ou du prestataire. Je décris le partage des tâches dans le guide consacré à la question de savoir qui est responsable de la mise à jour du site.

Méthode 1 : le panneau de l’hébergeur et l’administration du site

C’est la méthode la plus sûre, car vous voyez les données de l’intérieur, et non des suppositions.

Le panneau de l’hébergeur

Connectez-vous au panneau de l’hébergeur et cherchez une entrée du genre « Version de PHP », « Configuration PHP » ou « PHP et Node.js ». Dans les panneaux cPanel, c’est l’outil MultiPHP Manager qui s’en charge : il affiche la version de PHP à côté de chaque domaine. J’ai décrit les chemins exacts pour OVHcloud, home.pl et nazwa.pl dans le guide sur la fin du support de PHP 8.2.

Le panneau n’affiche souvent que la branche, par exemple 8.3. Pour les failles, c’est le numéro complet de la version qui compte, par exemple 8.3.x, car le correctif arrive dans une version précise. Vous verrez le numéro complet dans l’administration du CMS, ou l’hébergeur vous le donnera.

Un site sous Node.js tourne généralement sur un serveur VPS ou sur une plateforme comme Vercel ou Netlify. La version de Node.js est alors visible dans les paramètres du projet ou dans ses fichiers : le plus simple est donc de demander au prestataire (un message tout prêt se trouve plus bas).

WordPress et WooCommerce

  • Tableau de bord → Mises à jour affiche la version de WordPress ainsi que les extensions et les thèmes qui attendent une mise à jour.
  • Outils → Santé du site → Infos est l’endroit le plus pratique. La section « WordPress » contient la version du système, la section « Serveur » la version complète de PHP et le logiciel du serveur, et les sections « Extensions activées » et « Extensions désactivées » chaque extension avec son numéro de version.
  • Extensions → Extensions installées affiche les versions et indique si les mises à jour automatiques fonctionnent.

Le bouton « Copier les infos du site dans le presse-papiers », sur la même page, fournit l’ensemble des données à coller dans un e-mail. Ne l’envoyez qu’à une personne de confiance, car il contient des détails techniques sur le serveur.

Si vous voyez dans le tableau de bord un encadré « Mise à jour de PHP recommandée », WordPress vous signale lui-même que la version de PHP du serveur est trop ancienne. Selon wordpress.org, la version recommandée aujourd’hui est PHP 8.3 ou plus récente.

PrestaShop

Dans l’administration de PrestaShop, allez dans Paramètres avancés → Informations (dans le menu, groupe « Configurer »). Vous y verrez la version de PrestaShop, les données du serveur, la version de PHP et celle de la base de données. Vous vérifierez les versions des modules dans Modules → Gestionnaire de modules.

Méthode 2 : ce que le site révèle de l’extérieur

Cette méthode fonctionne sans connexion, mais vous ne voyez que ce que le site montre lui-même. S’il masque bien les versions, vous n’apprendrez pas grand-chose, et c’est justement une bonne nouvelle.

Les en-têtes du serveur

Chaque réponse du serveur comporte des en-têtes, c’est-à-dire une courte fiche invisible sur la page. Deux d’entre eux renseignent sur le logiciel :

  • Server : nginx et Apache, dans leur configuration par défaut, y indiquent leur nom et leur numéro de version, par exemple nginx/1.24.0.
  • X-Powered-By : PHP, dans sa configuration par défaut, y inscrit sa version, par exemple PHP/8.3.x. Express y inscrit Express, et Next.js Next.js, dans les deux cas sans numéro.

Comment les consulter dans Chrome : appuyez sur F12, ouvrez l’onglet Network (« Réseau » dans la version française), actualisez la page, cliquez sur la première ligne de la liste et repérez les en-têtes de la réponse. Certains hébergeurs masquent les numéros de version : un résultat vide ne prouve donc rien.

Le code source de la page

Appuyez sur Ctrl+U, puis sur Ctrl+F, et saisissez generator. Par défaut, WordPress insère dans le code une balise avec le numéro de version, par exemple :

<meta name="generator" content="WordPress 7.1.4">

Les adresses des fichiers révèlent le reste : /wp-content/plugins/nom-de-l-extension/ montre les noms des extensions, /_next/static/ signifie Next.js, et /_nuxt/ Nuxt. Les extensions de sécurité suppriment souvent la balise generator : son absence ne prouve donc rien.

Une extension de navigateur

Le moyen le plus rapide d’identifier les technologies est une extension de navigateur comme Wappalyzer ou BuiltWith (toutes deux disponibles pour Chrome et Firefox). En cliquant sur l’icône, vous voyez le CMS, le framework, le serveur et les bibliothèques. C’est une identification d’après des indices : elles n’affichent la version que si le site la révèle, et il leur arrive de se tromper.

Les robots qui cherchent sur le web des sites aux versions obsolètes voient la même chose : il vaut donc mieux que le serveur n’affiche pas les numéros. Ce n’est pas une protection complète (la documentation d’Express écrit en toutes lettres qu’un attaquant expérimenté reconnaîtra de toute façon le logiciel), mais cela complique les scans simples.

Analyser votre site

Mon outil gratuit Analyser votre site fait une partie de ce travail à votre place. Il avertit lorsque l’en-tête Server ou X-Powered-By contient un numéro de version et suggère de le masquer. Il reconnaît aussi la plateforme d’après la balise generator et les adresses des fichiers (notamment WordPress, WooCommerce, PrestaShop, Shopify, Shoper et Next.js) et l’affiche à côté du résultat. Il ne lit toutefois ni la version du CMS ni la liste des extensions et ne se connecte pas à l’administration : il ne remplace donc pas une vérification de l’intérieur.

Où trouver les versions : tableau pour les sites courants

Type de site Version de la plateforme Version de PHP ou de Node.js Compléments
WordPress, WooCommerce Tableau de bord → Mises à jour Outils → Santé du site → Infos → Serveur Extensions → Extensions installées
PrestaShop Paramètres avancés → Informations même endroit Modules → Gestionnaire de modules
Next.js, Nuxt et autres sous Node.js fichier package.json ou commande npx next -v (prestataire) paramètres du projet chez le fournisseur ou node -v sur le serveur package.json et fichier de verrouillage des versions, par ex. package-lock.json
Site statique (HTML) pas de CMS généralement aucun ; PHP seulement pour des scripts, par ex. un formulaire bibliothèques JavaScript, s’il y en a
Boutique par abonnement (Shopify, Shoper, Wix) mise à jour par le fournisseur de la plateforme sans objet applications et intégrations installées

Votre version de PHP ou de Node.js est-elle encore prise en charge ?

Le numéro seul ne dit pas grand-chose. Ce qui compte, c’est de savoir si l’éditeur publie encore des correctifs de sécurité pour cette version. Situation au 6 novembre 2026 selon le tableau des versions prises en charge sur php.net et le calendrier des versions de Node.js :

Logiciel Correctifs de sécurité jusqu’au Que faire
PHP 8.1 et plus anciens il n’y en a plus (8.1 jusqu’au 31 décembre 2025) changer de version au plus vite
PHP 8.2 31 décembre 2026 planifier le changement dès novembre
PHP 8.3 31 décembre 2027 veiller à avoir la dernière version 8.3.x
PHP 8.4 31 décembre 2028 veiller à avoir la dernière version 8.4.x
PHP 8.5 31 décembre 2029 la choisir si le CMS et les extensions la prennent en charge
Node.js 20 et plus anciens, ainsi que 21, 23, 25 il n’y en a plus (20 jusqu’au 30 avril 2026) passer à 24 ou 26 au plus vite
Node.js 22 30 avril 2027 planifier la migration avant avril 2027
Node.js 24 30 avril 2028 veiller à avoir la dernière version
Node.js 26 30 avril 2029 veiller à avoir la dernière version

Node.js 27 n’en est encore qu’à la phase de test (alpha). Selon nodejs.org, sur les serveurs de production, on ne devrait utiliser que des versions à support long (LTS).

Deuxième point : le numéro complet. Les correctifs pour PHP 8.3 arrivent dans les versions successives 8.3.x, et quand l’éditeur annonce une faille, il indique les versions corrigées. La vôtre doit être identique ou plus récente. Sur un hébergement mutualisé, les nouvelles versions au sein d’une branche sont généralement installées par l’hébergeur, mais il vaut la peine de le faire confirmer par e-mail.

Pour les extensions WordPress, vous pouvez saisir le nom et la version dans la base de vulnérabilités de Patchstack ou dans celle de Wordfence. Vous verrez les failles connues et la version dans laquelle elles ont été corrigées.

Que faire aujourd’hui : la fiche d’identité du site en 15 minutes

Notez les résultats en un seul endroit. À la prochaine nouvelle sur une faille, vous vérifierez en une minute si elle vous concerne. Modèle à copier :

Site : votreentreprise.pl Hébergeur et offre : … Qui met à jour : CMS et extensions …, serveur et PHP … Serveur web : … (version, si elle est connue) PHP ou Node.js : … (numéro complet) CMS ou framework : … (version) Extensions, thème, modules : nom et version de chacun Date de vérification : …

Ensuite, parcourez cette liste :

  1. Comparez les versions de PHP et de Node.js avec le tableau ci-dessus. Une version sans correctifs est la première tâche à confier.
  2. Mettez à jour le CMS et les extensions, en commençant par une sauvegarde. J’ai décrit l’ordre des étapes dans le guide pour mettre à jour WordPress en toute sécurité.
  3. Supprimez les extensions que vous n’utilisez pas. WordPress avertit lui-même, dans la Santé du site, que les extensions désactivées sont des cibles faciles.
  4. Vérifiez les extensions dans une base de vulnérabilités, surtout celles qui n’ont pas été mises à jour depuis longtemps.
  5. Passez le site dans Analyser votre site et vérifiez que le serveur ne révèle pas de versions.
  6. Inscrivez dans votre agenda une revue de la fiche une fois par mois.

Ce qu’il faut confier à l’hébergeur ou au prestataire

Si vous ne trouvez pas quelque chose ou si le site tourne sous Node.js, envoyez un court message :

Bonjour, pourriez-vous m’indiquer sur quels logiciels tourne le site votreentreprise.pl : version complète de PHP ou de Node.js, version du CMS ou du framework, liste des extensions ou des dépendances avec leurs versions et version du serveur web ? Merci de préciser également qui installe les correctifs de sécurité et en combien de temps, et si le serveur masque les numéros de version dans les en-têtes. Merci d’avance.

Un prestataire qui a accès au serveur le vérifiera en quelques commandes :

curl -sI https://twojafirma.pl | grep -iE "^(server|x-powered-by):"
node -v
npx next -v
php -v

Attention : php -v affiche la version de PHP utilisée en ligne de commande. Sur un hébergement proposant plusieurs versions, elle diffère parfois de celle du site : la Santé du site ou le panneau de l’hébergeur sont donc plus fiables.

On masque généralement les numéros de version dans la configuration : expose_php = Off dans PHP, server_tokens off; dans nginx, ServerTokens Prod dans Apache, poweredByHeader: false dans Next.js et app.disable('x-powered-by') dans Express. Sur un hébergement mutualisé, certains de ces réglages ne peuvent être modifiés que par l’hébergeur.

S’il s’avère que le site présente une faille, vous trouverez le plan d’action dans le guide suivant de cette série : « Faille sur un site d’entreprise : que faire dans les 24 premières heures ».

Quand une faille grave apparaît dans PHP, la version compte immédiatement. J’en décris un exemple et un plan d’action dans le guide Faille dans PHP (PHP2Shell) : que vérifier et que demander à l’hébergeur.

En résumé

Vous répondrez en une minute à la question « cette faille me concerne-t-elle ? » si vous avez noté quatre choses : le serveur, la version de PHP ou de Node.js, la version du CMS et la liste des compléments. Vous trouverez l’essentiel dans le panneau de l’hébergeur et dans le tableau de bord de WordPress ; pour le reste, Analyser votre site ou un e-mail au prestataire vous renseigneront.

Si vous préférez que quelqu’un surveille cela à votre place, choisissez la maintenance technique. Dans le forfait Veille (à partir de 149 PLN HT par mois), je surveille le site, je fais les sauvegardes et les mises à jour de sécurité, et j’envoie un rapport chaque mois. Les forfaits Standard (à partir de 349 PLN HT par mois) et Pro (à partir de 749 PLN HT par mois) ajoutent des sauvegardes et des mises à jour plus fréquentes, des heures de travail chaque mois et une réaction plus rapide. Si vous voulez vérifier la résistance du site aux attaques courantes, commandez un audit de sécurité (à partir de 990 PLN HT) ou écrivez-moi. Je réponds sous 24 heures.

Questions fréquentes

Services liés au sujet

Vous avez un projet similaire ?

Décrivez votre besoin et je vous envoie un devis sous 24 heures. Les nouveaux clients bénéficient de 20 % de réduction sur la première commande.

Demander un devisRéserver un appel (20 min)

À lire aussi