Fin de PHP 8.2 : sites de Monaco

Le 31 décembre 2026, PHP 8.2 arrive en fin de support de sécurité. À partir du 1er janvier 2027, le projet PHP ne publiera plus aucun correctif pour cette branche, quelle que soit la gravité de la faille. Il y a une semaine, les vulnérabilités PHP2Shell ont conduit le Gouvernement Princier, le Palais et la Mairie de Monaco à couper l'accès à leurs sites le temps d'une mise à jour préventive. La prochaine faille de ce type, si elle survient en 2027, n'aura tout simplement pas de correctif officiel pour ceux qui seront encore en 8.2.

Ce n'est pas une urgence. C'est une date, dans neuf semaines, dont la plupart des dirigeants monégasques n'ont jamais entendu parler et que leur hébergeur gérera, ou non, à leur place. Voici ce qui change, comment savoir si vous êtes concerné et comment migrer à temps sans casser votre site en pleine période des fêtes.

Ce qui s'arrête réellement le 31 décembre 2026

PHP, le langage derrière WordPress, WooCommerce, PrestaShop, Drupal, Laravel et une grande partie des développements sur mesure, est publié par branches annuelles. Chaque branche bénéficie de deux ans de support actif, puis d'une période de correctifs de sécurité uniquement. PHP 8.2 est sorti en décembre 2022, a quitté le support actif fin 2024 et perd son support de sécurité le 31 décembre 2026.

Les branches encore supportées après cette date, selon php.net, sont la 8.3 (correctifs jusqu'à fin 2027), la 8.4 (jusqu'à fin 2028) et la 8.5 (jusqu'à fin 2029).

Fin de vie ne signifie pas que votre site s'arrête le 1er janvier. Cela signifie que toute vulnérabilité révélée après cette date reste ouverte en 8.2, sauf si quelqu'un d'autre que le projet PHP la corrige. Certains éditeurs de systèmes d'exploitation et certains hébergeurs rétroportent des correctifs sur d'anciennes branches pour leurs clients. Cela peut faire gagner du temps, mais c'est un engagement à obtenir par écrit de votre hébergeur, pas une hypothèse.

Pourquoi c'est plus important à Monaco qu'il n'y paraît

La majorité des sites d'entreprise monégasques tournent sous PHP. Hôtels, restaurants, agences, boutiques, cabinets d'avocats et family offices de la Principauté utilisent très largement WordPress ou une autre plateforme PHP. La coupure d'octobre des sites du Gouvernement a montré que le sujet concerne aussi bien les plus grands sites du pays que les plus petits.

La loi monégasque sur les données attend des logiciels maintenus. La loi n° 1.565 du 3 décembre 2024, contrôlée par l'APDP, impose aux responsables de traitement des mesures de sécurité adaptées au risque et la notification des violations. Faire tourner un serveur web sur un logiciel aux failles connues et non corrigées est difficile à justifier après un incident, et un formulaire de contact ou un espace client sur un tel site traite par définition des données personnelles. Nous ne sommes pas juristes, vérifiez donc vos obligations précises avec un conseil qualifié, mais la direction est claire.

Votre hébergeur peut vous migrer sans vous demander votre avis. Beaucoup d'hébergeurs mutualisés basculent automatiquement leurs clients hors des versions PHP en fin de vie. Si cela se produit en janvier pendant que personne ne surveille, un vieux thème ou une extension obsolète peut mettre tout le site hors ligne. Migrer selon votre propre calendrier est bien plus sûr que de se faire migrer.

Savoir où vous en êtes

Commencez par lister tous les sites que vous possédez, pas seulement le principal. Les mini-sites d'une ancienne campagne, un sous-domaine de réservation, la copie de préproduction que personne n'a supprimée : chacun tourne avec sa propre version de PHP et chacun est accessible depuis Internet.

Pour chaque site, identifiez la version de PHP. Sous WordPress, allez dans Outils, puis Santé du site, onglet Informations, section Serveur. Sur les autres plateformes, demandez à votre hébergeur ou à votre développeur et exigez une réponse écrite. Tout ce qui affiche 8.2 ou moins va sur la liste d'actions ; tout ce qui est en 8.1 ou moins est déjà sans support et doit migrer en premier.

Regardez ensuite de quoi le site est fait. Chaque thème et chaque extension WordPress indique une valeur « Nécessite PHP » et « Testé jusqu'à » sur sa fiche. Les extensions qui n'ont pas été mises à jour depuis plus d'un an, ou qui ont disparu du répertoire officiel, sont celles qui ont le plus de chances de casser sur une version plus récente.

Vers quelle version migrer

Pour la plupart des sites monégasques, PHP 8.4 est la cible raisonnable. Elle est supportée jusqu'à fin 2028, disponible chez les hébergeurs courants, et l'écosystème d'extensions a eu deux ans pour s'y adapter. PHP 8.3 est un repli acceptable si une extension critique ne supporte pas encore la 8.4, mais cela ne fait gagner qu'un an.

Quel que soit votre choix, testez d'abord sur une copie de préproduction. Les pannes typiques sont prévisibles : thèmes qui s'appuient sur des comportements obsolètes, extensions abandonnées, fonctions sur mesure écrites pour PHP 7, vieilles bibliothèques tierces embarquées dans une extension. Sur un site bien entretenu, la bascule prend une après-midi. Sur un site négligé, elle peut prendre plusieurs jours, surtout passés à remplacer des extensions que personne n'a touchées depuis le lancement. Notre équipe WordPress fait cela régulièrement, et cela coûte toujours moins cher qu'une panne en janvier.

Un plan en neuf semaines qui épargne les fêtes

• Jusqu'à la mi-novembre : inventaire. Listez chaque site, sa version de PHP, son hébergeur et les personnes qui y ont accès. Identifiez les extensions et thèmes qui bloquent la mise à niveau.
• Deuxième quinzaine de novembre : tests. Clonez chaque site en préproduction, changez la version de PHP et parcourez les pages qui vous font gagner de l'argent : formulaire de contact, parcours de réservation, tunnel de commande e-commerce, connexion client, sélecteur de langue.
• Avant le 10 décembre : bascule. Pour le commerce, l'hôtellerie-restauration et l'e-commerce, la fenêtre calme se referme début décembre. Basculez tôt, puis laissez le site tranquille pendant la haute saison.
• Janvier : revue. Vérifiez les journaux d'erreurs, confirmez que les sauvegardes fonctionnent avec la nouvelle version et documentez ce qui a été fait. Si un site est resté en 8.2, c'est le premier chantier de 2027.

Si vous ne pouvez pas tenir la date

Certains sites ne peuvent vraiment pas migrer à temps : une plateforme sur mesure dont le développeur a disparu, une extension indispensable mais abandonnée, un budget déjà consommé. Obtenez alors trois choses par écrit de votre hébergeur : s'il rétroportera des correctifs de sécurité en 8.2 et pendant combien de temps, quel pare-feu applicatif protège votre site, et quand il compte forcer la mise à niveau. Fixez une date de migration au premier trimestre 2027 et traitez l'intervalle comme un risque identifié.

Souvent, l'inventaire révèle autre chose : le site a six ou sept ans, repose sur un thème que plus personne ne maintient, et la réponse honnête est une refonte plutôt qu'un énième correctif. Dans ce cas, un projet de développement web mené posément à partir de janvier coûtera moins cher et apportera davantage qu'une série d'interventions d'urgence. Dans tous les cas, un vrai contrat de maintenance de site web est ce qui évite que ce genre d'échéance soit une surprise la prochaine fois.

Si vous souhaitez que nous vérifiions les versions PHP de vos sites et vous disions franchement ce qu'il faut faire avant le 31 décembre, contactez-nous. Le premier diagnostic nous prend moins d'une heure.