Un site web est un logiciel. La moitié du web PHP ne reçoit plus de correctifs de sécurité.

---

RÉPONSE RAPIDE

Environ la moitié des sites web construits sur PHP tournent sous une version que ses développeurs ne corrigent plus, et cette part passe à environ deux sur trois le 31 décembre 2026. La plupart des failles se trouvent dans les extensions, pas dans le cœur. Vérifiez votre version de PHP et votre liste d'extensions cette semaine. Si personne n'est chargé de le faire chaque mois, votre site n'a pas de mainteneur.

---

Le site web d'un bureau d'ingénierie de quarante personnes a été mis en ligne en 2019. Un freelance l'a construit sur WordPress, avec un thème acheté sur une place de marché et vingt-sept extensions, avant d'accepter un poste à temps plein ailleurs. Le site s'affiche toujours. Le formulaire de contact envoie toujours ses messages. La directrice ou le directeur financier, qui en a hérité, ne s'est pas connecté au panneau d'hébergement depuis deux ans, car rien ne semblait anormal.

Que rien ne semble anormal, c'est justement le problème. Un site web n'est pas une brochure imprimée une fois pour toutes. C'est un logiciel, assemblé à partir de composants dont les auteurs continuent à publier des correctifs, ou cessent de le faire. Quand les correctifs s'arrêtent, le site continue de fonctionner. Il cesse simplement d'être défendu.

La moitié du web PHP tourne sous une version qui ne reçoit plus de correctifs de sécurité

PHP fait fonctionner WordPress et la plupart des sites de petites entreprises. W3Techs le trouve sur 69,9 % des sites dont il parvient à identifier le langage serveur.

Le projet PHP publie précisément la date à laquelle chaque version cesse de recevoir des correctifs de sécurité. Selon php.net, la version 7.4 a atteint sa fin de vie le 28 novembre 2022, la 8.0 le 26 novembre 2023 et la 8.1 le 31 décembre 2025. Passées ces dates, une faille nouvellement découverte dans cette version n'est jamais corrigée.

Personne ne publie le nombre de sites qui utilisent encore ces versions ; Elevates l'a donc calculé. Prenons les parts de versions de W3Techs au 19 septembre 2026 : 28,0 % des sites PHP sont en version 7, 7,8 % en version 5, 0,1 % en version 4. Sur les 64,1 % en version 8, la ventilation de W3Techs en place 16,1 % en 8.1 et 6,2 % en 8.0. Additionnez : environ 50,2 % des sites web PHP tournent sous une version qui ne reçoit plus de correctifs de sécurité.

Ce n'est pas une frange de sites de loisir oubliés. C'est la moitié de la façon la plus courante de mettre une petite entreprise en ligne.

Le 31 décembre 2026, la moitié devient deux sur trois

Le calendrier de support ne fait pas de pause. php.net indique que le support de sécurité de PHP 8.2 prend fin le 31 décembre 2026. W3Techs place aujourd'hui 28,9 % des sites PHP 8 sur la 8.2.

Si personne ne change de version, la part des sites PHP sous une version non prise en charge passe d'environ 50 % à environ 68,7 % au 1er janvier. Là encore, il s'agit du calcul d'Elevates, à partir des mêmes sources et de la même date.

Chacune de ces dates a été publiée des années à l'avance. Aucune n'a été une surprise pour qui regardait. Les sites qui les ont franchies n'avaient simplement personne pour regarder.

Le point faible n'est pas WordPress, mais ce qu'on lui greffe

WordPress fait fonctionner 40,2 % de tous les sites web, et on lui reproche beaucoup de choses. Le reproche tombe au mauvais endroit.

Patchstack, une entreprise qui vend de la sécurité pour WordPress, publie chaque année un décompte des nouvelles vulnérabilités de l'écosystème. Son rapport 2026 a recensé 11 334 nouvelles vulnérabilités en 2025, soit une hausse de 42 % par rapport à 2024. Parmi elles, 91 % concernaient des extensions et 9 % des thèmes. Le cœur de WordPress en comptait six, toutes de faible priorité.

Le cœur est donc la partie la mieux défendue du site. Le risque se trouve dans les extensions, et chaque extension est un fournisseur distinct. Un formulaire de contact d'un développeur, un diaporama d'un autre, un bandeau de cookies d'un troisième, un outil de sauvegarde d'un quatrième. Chacun a son propre calendrier de publication, ses propres priorités, et sa propre probabilité d'être abandonné par son auteur.

Vingt-sept extensions, c'est vingt-sept fournisseurs. La plupart des entreprises ne pourraient en citer aucun.

Près de la moitié des failles sont publiques avant même qu'un correctif existe

On suppose volontiers que mettre à jour suffit : activez les mises à jour automatiques et le problème se règle tout seul. Les données disent le contraire.

Dans le même rapport, Patchstack a constaté que 46 % des vulnérabilités n'avaient pas reçu de correctif de la part du développeur à temps pour leur divulgation publique, contre 33 % l'année précédente. Sa propre conclusion : les propriétaires de sites web « ne peuvent pas compter sur les mises à jour des extensions comme mesure de sécurité ».

Une mise à jour comble les failles pour lesquelles un correctif existe. Elle ne fait rien pour une extension dont l'auteur ne donne plus signe de vie, ni pour les jours qui séparent la divulgation d'une faille de la livraison du correctif. Dans ces cas, quelqu'un doit trancher : désactiver l'extension, la remplacer, ou accepter le risque en connaissance de cause. Une mise à jour automatique ne peut pas prendre cette décision. Il faut une personne.

Les attaquants agissent en heures. La plupart des propriétaires, en trimestres

Le délai entre la divulgation et l'attaque est court. Patchstack a constaté qu'environ la moitié des vulnérabilités à fort impact avaient été exploitées dans les 24 heures. Pondérée par l'intensité de l'exploitation, la durée médiane avant la première exploitation était de cinq heures.

Comparez maintenant avec la façon dont la plupart des entreprises traitent leur site web. On le révise quand quelqu'un se plaint, ou à l'occasion d'une refonte, à intervalles de plusieurs années. Une fenêtre de cinq heures et un cycle de révision de trois ans ne se rencontrent pas.

L'hébergeur n'est pas non plus un filet de sécurité. Patchstack a testé des défenses courantes, dont des pare-feu applicatifs web et Cloudflare, face à de véritables exploits de vulnérabilités WordPress, et indique qu'elles ont bloqué 12 % des attaques propres à WordPress. Il faut y voir le test d'un éditeur, puisque Patchstack vend l'alternative. Même fortement relativisé, ce chiffre dit la même chose : le pare-feu de l'hébergeur n'est pas de la maintenance.

« Ça fonctionne encore » ne veut pas dire « c'est encore maintenu »

C'est la phrase qui maintient en ligne des sites obsolètes. La page d'accueil s'affiche, donc le site doit aller bien.

Un site non corrigé ressemble en tout point à un site à jour, jusqu'au jour où ce n'est plus le cas. Ce qui change en premier est invisible : une page de spam injectée dans un dossier que personne ne consulte, une redirection qui ne se déclenche que pour les visiteurs venant de Google, un script ajouté à la page de paiement. Les moteurs de recherche et les navigateurs peuvent s'en apercevoir avant le propriétaire, et ils réagissent en détournant les visiteurs par un avertissement.

Une compromission entraîne trois coûts, et la réparation est le plus faible. Le premier est le temps pendant lequel le site a servi les desseins de quelqu'un d'autre avant que quiconque ne s'en aperçoive. Le deuxième est la confiance : un client qui voit un avertissement du navigateur sur votre domaine ne lit pas l'explication. Le troisième est juridique. Si le site détient des données personnelles, une violation peut déclencher des obligations de notification au titre de l'article 33 du RGPD, dont le délai de 72 heures court à partir du moment où le responsable du traitement en a connaissance.

Aucun de ces coûts ne figure sur la facture du site web. Tous sont payés par l'entreprise qui le possède.

Ce que vous pouvez vérifier cet après-midi sans payer personne

L'essentiel de la première passe est gratuit, et vous pouvez la faire vous-même.

• Trouvez votre version de PHP. Le panneau de contrôle de votre hébergeur l'affiche, généralement sous une rubrique du type paramètres PHP ou logiciels. Si elle commence par 7, ou s'il s'agit de la 8.0 ou de la 8.1, elle ne reçoit plus de correctifs de sécurité. S'il s'agit de la 8.2, elle s'arrête le 31 décembre 2026.
• Comptez vos extensions. Dans l'administration de WordPress, ouvrez la page des extensions. Notez combien sont installées, et combien sont activées.
• Supprimez ce qui est inactif. Une extension inactive reste sur le serveur, et son code peut toujours être atteint. Si personne ne sait dire pourquoi elle est là, supprimez-la.
• Vérifiez la dernière mise à jour de chaque extension active. Le répertoire des extensions indique la date de dernière mise à jour de chacune. Une extension qui n'a pas bougé depuis un an ou plus est une extension à remplacer.
• Activez les mises à jour automatiques pour les versions mineures, et vérifiez que les sauvegardes s'exécutent réellement et qu'elles peuvent être restaurées. Une sauvegarde que personne n'a jamais restaurée est un espoir, pas une sauvegarde.
• Notez qui dispose d'un accès administrateur. Supprimez les comptes des personnes parties.

Pour beaucoup de petits sites, cela représente un après-midi, et cela élimine une grande part des risques faciles. Faites-le même si vous ne parlez jamais à une agence.

Là où l'après-midi s'arrête

La passe gratuite a un plafond, et on l'atteint vite.

Passer de PHP 7.4 à 8.3 n'est pas un simple interrupteur dans le panneau d'hébergement. Le code écrit pour l'ancienne version peut ne plus fonctionner avec la nouvelle : un thème qui utilise des fonctions supprimées par la nouvelle version, une extension qui n'a jamais été mise à jour pour elle. Sur un vieux site, actionner l'interrupteur produit souvent une page blanche. La mise à niveau est donc repoussée, et le site reste sur la version qui ne reçoit plus de correctifs. C'est ainsi que la moitié du web PHP en est arrivée là.

Il en va de même pour une extension abandonnée qui assure une fonction dont l'entreprise dépend, comme le formulaire de réservation ou l'espace membres. La remplacer suppose de reconstruire cette fonctionnalité, de la tester et d'en migrer les données. C'est du travail d'ingénierie, qu'aucune liste de contrôle ne couvre.

Et la liste de contrôle doit être refaite le mois prochain, puis le mois suivant. L'après-midi corrige aujourd'hui. Il ne rend personne responsable de demain.

À quoi ressemble un site maintenu, mois par mois

La maintenance paraît floue, et c'est pourquoi on la saute. Elle ne l'est pas. C'est une routine courte, avec un calendrier, qui tient sur une page.

Chaque mois : appliquer les mises à jour du cœur, du thème et de chaque extension, d'abord sur une copie du site lorsqu'il s'agit d'une mise à jour majeure. Lire les avis de sécurité des extensions réellement installées, pas de tout l'écosystème. Vérifier que la sauvegarde de la nuit dernière existe et qu'elle est complète.

Chaque trimestre : restaurer une sauvegarde sur une copie de test et vérifier que le site fonctionne à partir d'elle. Passer en revue les personnes qui ont un accès administrateur. Réexaminer chaque extension qui n'a pas été mise à jour depuis six mois, et décider si elle reste.

Chaque année : consulter le calendrier de support de PHP et planifier le prochain changement de version avant l'échéance, pas après. Renouveler le nom de domaine et les certificats sous la surveillance d'une personne désignée, et non d'une carte bancaire peut-être expirée. Se demander si chaque extension mérite encore sa place, car l'extension la plus facile à sécuriser est celle qui n'est pas installée.

Pour tout avis de sécurité sans correctif : décider dans la journée de désactiver, de remplacer ou d'accepter. Consigner la décision par écrit, avec une date.

Tout cela n'a rien d'exotique. C'est la même discipline que toute entreprise applique déjà à ses comptes ou à ses véhicules : un calendrier, une personne désignée et une trace écrite. Ce qui manque sur la plupart des sites, ce n'est pas le savoir. C'est le nom en face de la tâche.

Un logiciel a besoin d'un responsable, pas d'une date de lancement

Le vrai manque n'est pas technique. C'est que personne n'est propriétaire du fonctionnement du site.

Un site web se vend généralement comme un projet : une conception, une réalisation, un lancement, une facture. L'exploitation est traitée comme une réflexion après coup, ou comme des frais d'hébergement. Mais le lancement est le jour où le logiciel commence à vieillir. Chaque mois qui suit, quelque part, un fournisseur publie un correctif ou cesse d'en publier, et quelqu'un doit s'en apercevoir.

C'est ainsi qu'Elevates tarife un site : la réalisation une fois, l'exploitation chaque mois, avec une personne désignée responsable des mises à jour, des sauvegardes et des accès. La réalisation n'est jamais rouverte pour financer la maintenance, et la maintenance n'est jamais dissimulée dans la réalisation. Son propre site, elevates.it, est construit sans aucune couche d'extensions : les pages sont compilées à partir d'un code qu'Elevates maîtrise, ce qui réduit d'emblée le nombre de fournisseurs à surveiller.

Pour un site comme celui du bureau d'ingénierie, le bilan honnête aboutit généralement à l'un de deux endroits. Parfois, c'est un après-midi de nettoyage, une mise à niveau de PHP qui passe, et une routine mensuelle que l'entreprise peut assurer elle-même ou confier à quelqu'un. Cela ne coûte que de l'attention, et c'est l'issue à espérer. Parfois, le thème et la moitié des extensions ne survivent pas à la mise à niveau, et le choix se situe entre reconstruire avec moins de pièces mobiles ou payer chaque mois pour maintenir une vieille pile en sursis. Dans les deux cas, ce doit être une décision prise délibérément, avec les dates sous les yeux.

La question à poser cette semaine

Posez une question à la personne qui s'occupe de votre site web : quelle version de PHP le site utilise-t-il, et quand cesse-t-elle de recevoir des correctifs de sécurité ?

Si la réponse arrive vite, avec une date et un plan, votre site a un mainteneur. Si la question circule de main en main, ou si la réponse est « ça va, ça marche », alors il a une date de lancement et rien depuis. Elevates peut faire cette vérification avec vous et vous dire dans lequel des deux cas vous vous trouvez.