La réponse courte. La plupart des petits sites fonctionnent avec un logiciel appelé PHP. Voyez-le comme le moteur sous le capot. Le 21 octobre 2026, deux failles graves ont été découvertes dans ce moteur. Elles permettent à un inconnu de tromper un site pour lui faire exécuter son code, sans jamais avoir à se connecter. Les correctifs sont sortis le jour même, mais uniquement pour les versions encore maintenues. Si votre site utilise PHP 8.1 ou plus ancien, les fabricants ont cessé de le corriger : il n’existe donc aucun correctif pour votre version. Beaucoup de sites de chambres d’hôtes et de gîtes sont exactement dans ce cas : construits il y a des années, en parfait état de marche, et jamais revus depuis. Tapez l’adresse de votre site dans la vérification gratuite juste ci-dessous : vous saurez en quelques secondes de quel côté de la ligne vous êtes.
Pour celle-ci, vous n’avez besoin d’aucun numéro de version. Tapez l’adresse de votre site, appuyez sur le bouton, et en quelques secondes vous aurez une réponse franche : si les failles d’octobre 2026 concernent votre site, et quoi faire. La vérification regarde uniquement les informations que votre site montre déjà à n’importe quel visiteur. Rien n’est installé sur votre site, et nous ne conservons pas votre adresse.
Votre résultat apparaîtra ici.
Certains sites gardent leur numéro de version caché. Si c’est le cas du vôtre, l’outil vous le dira, et la vérification en deux minutes ci-dessus sert de solution de repli.
Si vous avez déjà trouvé votre numéro de version, choisissez-le ici. Vous verrez tout de suite si elle est encore maintenue, si le correctif d’octobre 2026 vous couvre, et quoi faire ensuite.
Choisissez votre version ci-dessus et votre résultat apparaîtra ici.
PHP est le moteur qui fait tourner WordPress et la plupart des sites de petites entreprises. Le 21 octobre 2026, l’équipe qui s’occupe de PHP a annoncé deux failles graves. Elles sont enregistrées sous les numéros de référence CVE-2026-109618 et CVE-2026-109619, et on les a surnommées ensemble « php2shell ». Chacune est notée 9,2 sur 10 en gravité, presque le maximum de l’échelle. En langage simple, chacune de ces failles peut permettre à un inconnu d’envoyer un message soigneusement rédigé à votre site et d’amener l’ordinateur derrière à exécuter son code. Il n’a pas besoin de mot de passe. Dans le pire des cas décrit par l’équipe PHP, cela peut se produire avant même que le code de votre propre site ne se réveille.
Les correctifs ont été publiés le jour même, dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. L’avis de l’équipe PHP est sans détour : il n’existe aucune solution de contournement qui vous protège complètement, et la mise à jour est le seul choix sûr. En France, le CERT-FR a émis l’alerte CERTFR-2026-ALE-014 sur ces mêmes vulnérabilités et recommande, pour les versions qui ne sont plus maintenues, de migrer vers une version maintenue.
Deux choses comptent si votre site n’est pas récent. D’abord, un correctif n’existe que pour les versions encore maintenues. L’annonce le dit clairement : PHP 8.1 et les versions plus anciennes ne reçoivent plus de mises à jour de l’équipe PHP. Ensuite, l’équipe a fait quelque chose d’inhabituel : pour les personnes qui fabriquent PHP elles-mêmes à partir de son code brut, elle a aussi publié de petits correctifs pour PHP 7.4, 8.0 et 8.1. C’est dire la gravité du problème. Un compte d’hébergement classique ne recevra pas ces correctifs tout seul, et c’est pourquoi vérifier votre version compte.
Chaque version de PHP reçoit deux ans d’attention complète. Puis elle reçoit deux années de plus où seuls les trous de sécurité sont corrigés. Après cela, elle arrive à ce que les ingénieurs appellent la fin de vie. En langage simple, les fabricants ont cessé de la corriger, un peu comme un téléphone qui ne reçoit plus de mises à jour. La version ne cesse pas de fonctionner. Votre site a exactement la même apparence le lendemain. Il cesse simplement de devenir plus sûr.
| Version de PHP | Où elle en est en octobre 2026 | Fin des correctifs de sécurité |
|---|---|---|
| 8.5 | Entièrement prise en charge | 31 décembre 2029 |
| 8.4 | Entièrement prise en charge | 31 décembre 2028 |
| 8.3 | Correctifs de sécurité uniquement | 31 décembre 2027 |
| 8.2 | Correctifs de sécurité uniquement, et presque à court de temps | 31 décembre 2026 |
| 8.1 et plus anciennes, y compris tout PHP 7 | Fin de vie : plus personne ne la corrige | Déjà arrêtés |
Beaucoup de petits sites d’hébergement touristique restent sur PHP 7.4, 8.0 ou 8.1. Personne n’a rien fait de mal. Le site a été construit, il fonctionnait, les réservations arrivaient, et il n’y a jamais eu de raison de rouvrir le panneau de contrôle de l’hébergement. Les hébergeurs ne vous font pas toujours passer à une version plus récente d’eux-mêmes. Un saut de version peut casser un site ancien, et ils préfèrent laisser un site qui fonctionne tranquille plutôt que de le casser en silence. Résultat : un site qui a l’air en forme et qui a discrètement dépassé de plusieurs années son dernier correctif de sécurité.
Si votre site tourne sous WordPress (c’est le cas de la plupart des sites de chambres d’hôtes), voici où se cache le numéro de version :
Si votre site n’est pas sous WordPress, ou si vous ne pouvez pas vous connecter :
Comparez maintenant votre numéro au tableau ci-dessus. En 8.2, vous avez le correctif pour l’instant, mais le compte à rebours tourne : les correctifs pour 8.2 s’arrêtent le 31 décembre 2026. En 8.1 ou en dessous, votre version est au-delà de la fin, et le reste de cette page parle de vos options.
D’abord, gardons le sens des proportions. Une version ancienne ne veut pas dire que votre site a été piraté, et personne ne s’en prend à votre maison d’hôtes nommément. Le risque fonctionne ainsi. Quand une faille est annoncée, ses détails sont publiés pour que tout le monde les lise. Ensuite, des ordinateurs partent à la recherche des sites qui ont encore la faille, automatiquement, jour et nuit. Une version ancienne signifie que chaque faille découverte à partir de maintenant reste ouverte sur votre site pour de bon, y compris la paire de ce mois-ci, où l’attaquant n’a même pas besoin de mot de passe.
Si quelqu’un entre malgré tout, les résultats sont en général ennuyeux plutôt que dramatiques : vos pages modifiées ou redirigées vers des sites de spam, des pages indésirables cachées sous votre adresse, ou votre compte d’hébergement utilisé pour envoyer des courriers indésirables. Ce dernier point peut faire inscrire votre adresse sur des listes noires, et vos demandes de réservation commencent alors à atterrir dans les dossiers indésirables de vos clients. Et le site d’une chambre d’hôtes n’est pas qu’une brochure. Vos formulaires de demande contiennent les noms, les dates et les coordonnées de vos clients. Si votre système de réservation fonctionne comme une extension, un petit module ajouté à l’intérieur de votre site, le parcours de réservation lui-même se trouve derrière le même moteur. C’est cette partie de votre activité que le numéro de version monte la garde en silence.
1. Passer à une version de PHP plus récente, là où votre site se trouve. C’est la bonne réponse pour la plupart des sites, et elle est souvent gratuite : votre hébergeur actionne un interrupteur et votre site continue sa vie. Elle vous convient si les éléments de construction de votre site, son thème et ses modules complémentaires (extensions), sont encore entretenus par les personnes qui les ont fabriqués. Le seul vrai risque, c’est qu’un module écrit pour PHP 7 s’écroule sous PHP 8. Faites-le donc dans l’ordre sûr : sauvegarde complète d’abord, puis le changement, puis la visite de vos pages et de votre parcours de réservation une par une. Demandez à votre hébergeur de le faire, ou de l’essayer d’abord sur une copie d’entraînement, et convenez à l’avance qu’il reviendra en arrière si quelque chose casse. Une mise à jour prudente qui tourne mal vous coûte un après-midi. Rester sur une version sans correctifs ne coûte rien aujourd’hui et porte le risque chaque jour à partir de maintenant.
2. Garder le site, et mettre les correctifs au calendrier de quelqu’un d’autre. Si le site fait bien travailler votre établissement et que vous ne voulez tout simplement jamais ouvrir l’espace d’administration, payer quelqu’un pour s’en occuper est une réponse honnête : cette personne garde WordPress, le thème, les modules complémentaires et la version de PHP à jour pour vous, et vérifie le site ensuite. Elle convient aux propriétaires dont le site est sain mais dont l’attention est ailleurs. Le problème de version est rarement une question de connaissances. C’est une question de travail qui n’appartient à personne. Cette voie lui donne un responsable.
3. Recommencer avec un site construit à la main. Si le diagnostic est mauvais à tous les niveaux, un moteur que plus personne ne corrige, des modules que leurs fabricants ont abandonnés, un design qui date d’avant l’époque où la plupart des clients réservaient sur téléphone, alors réparer morceau par morceau peut coûter plus cher que recommencer. C’est la voie dans laquelle nous travaillons. Nous construisons à la main votre site de réservation directe pour £1,999 en paiement unique, avec votre moteur de réservation existant intégré dedans. Comme nous le disons sur notre page sur les channel managers : sous WordPress, des outils comme un moteur de réservation arrivent en général sous forme d’extension, et une extension est une chose de plus à mettre à jour et à garder sûre. Un site construit à la main n’a ni modèles tout faits ni constructeurs de pages, et toute la chaîne d’entretien, WordPress, thème, extensions et version de PHP, n’est tout simplement plus la vôtre à courir après. Voyez notre guide du coût d’un site de chambre d’hôtes pour comparer la construction en paiement unique avec les coûts permanents des plateformes et de la maintenance.
Dans WordPress, connectez-vous à votre espace d’administration, puis allez dans Outils, Santé du site, et ouvrez l’onglet Informations. Dépliez la section Serveur : la version de PHP y est indiquée. Si votre site n’est pas sous WordPress, connectez-vous au panneau de contrôle de votre hébergeur et cherchez « Select PHP Version » ou « MultiPHP Manager », qui affiche la version définie pour votre site. Si aucune de ces deux voies ne fonctionne, posez une seule question à votre hébergeur : quelle version de PHP mon site utilise-t-il, et est-elle encore maintenue ? Ou utilisez l’outil de vérification gratuit de cette page : tapez l’adresse de votre site, et il vous dira si votre version se voit de l’extérieur.
En octobre 2026, PHP 8.2, 8.3, 8.4 et 8.5 sont encore maintenus. PHP 8.2 est dans sa dernière ligne droite, avec des correctifs de sécurité uniquement, et arrive à la fin le 31 décembre 2026. PHP 8.1 et tout ce qui est plus ancien, y compris tout PHP 7, ont dépassé la fin : l’équipe PHP ne publie plus de correctifs de sécurité pour eux.
Non. Une version ancienne ne veut pas dire que quelqu’un est entré dans votre site. Cela veut dire que, lorsqu’une nouvelle faille est annoncée, aucun correctif n’est publié pour votre version par la voie habituelle. Les failles corrigées le 21 octobre 2026 en sont un exemple concret : des correctifs sont sortis pour PHP 8.2 à 8.5, tandis que PHP 8.1 et les versions plus anciennes n’ont reçu aucune version régulière. Voyez-le comme un travail à réserver, pas comme un incendie à éteindre dans la panique, et réservez-le vite.
C’est possible, si votre thème ou vos modules complémentaires sont anciens. Un module écrit pour PHP 7 peut s’écrouler sous PHP 8. C’est pourquoi les mises à jour doivent se faire avec une sauvegarde complète d’abord et, si vous le pouvez, un essai sur une copie d’entraînement. En pratique, la plupart des hébergeurs actionneront l’interrupteur pour vous et le remettront en arrière si quelque chose casse. Le risque d’une mise à jour prudente est faible et de courte durée. Le risque de rester sur une version sans correctifs, lui, ne disparaît pas.
Non. Ces entreprises fonctionnent sur leurs propres systèmes, et les réservations qui y sont faites continuent normalement. Ce qui fonctionne avec votre PHP, c’est votre propre site : vos pages, vos formulaires de demande et, si votre système de réservation est une extension à l’intérieur de votre site, votre parcours de réservation directe. C’est cette partie qu’il vaut la peine de protéger, car c’est le canal par lequel les coordonnées de vos clients arrivent directement chez vous.
En général, non. Si votre site WordPress fait par ailleurs son travail, mettre PHP à jour et garder WordPress, le thème et les modules complémentaires entretenus règle le problème. Une reconstruction mérite réflexion quand le site est ancien à tous les niveaux : une version de PHP que plus personne ne corrige, des modules que leurs fabricants ne maintiennent plus, et un design qui date d’avant les réservations sur téléphone portable pour la plupart des clients. Dans ce cas, la reconstruction enlève toute la chaîne d’entretien au lieu de la réparer maillon par maillon.
Si votre vérification aboutit à une version encore maintenue, parfait : notez la date à laquelle ses correctifs s’arrêtent, mettez un rappel, et retournez vous occuper de votre établissement. Si elle aboutit à une version ancienne, vous connaissez maintenant les trois voies et, en gros, ce que chacune coûte en argent ou en attention. Et si le site est de toute façon bon pour une reconstruction, un site construit à la main enlève pour de bon toute la routine des correctifs de votre liste.
Site web construit à la main, £1,999 en paiement unique, 0 % de commission. Découvrez d’abord votre propre chambre d’hôtes avec une démo à £9.90.
Essayer une démo à £9.90Des questions ? Appelez le +44 7727 811227 (IA 24 h/24 et 7 j/7) · WhatsApp (un humain) · hello@directbook.uk
Dernière vérification : 21 octobre 2026. Informations générales uniquement, ne constituent ni un conseil en sécurité ni un conseil juridique. Sources : avis de sécurité PHP, « Critical remote code execution vulnerabilities, update now » (php.net, 21 octobre 2026) ; alerte CERT-FR CERTFR-2026-ALE-014, « Multiples vulnérabilités dans PHP » (cert.ssi.gouv.fr, mise à jour du 21 octobre 2026) ; PHP Supported Versions (php.net, consulté le 21 octobre 2026) ; annonces de publication PHP pour 8.2.35, 8.3.36, 8.4.27 et 8.5.12 (php.net, 21 octobre 2026) ; avis préalable de publication de sécurité PHP (php.net, 20 octobre 2026).