En bref
Le 21 octobre 2026, PHP a publié des correctifs pour des failles critiques, vite surnommées PHP2Shell, qui concernent quasiment tous les sites WordPress. PHP tourne sur le serveur : sa mise à jour revient donc à l’hébergeur, sauf si ton contrat de maintenance dit autre chose.
Ce qui a fait la différence entre les freelances et les agences cette semaine-là, ce n’est pas la technique, c’est ce qu’ils avaient écrit dans leur contrat et la façon dont ils ont parlé à leurs clients.
Et la prochaine échéance arrive vite : PHP 8.2 n’aura plus de correctifs de sécurité officiels après le 31 décembre 2026.
Si tu ne sais pas exactement ce que couvre ta maintenance, commence par mon guide 👉 le contrat de maintenance WordPress.
Que s’est-il passé avec la faille PHP d’octobre 2026 ?
PHP, c’est le langage qui fait tourner WordPress sur le serveur. Le 21 octobre 2026, le projet PHP a publié des versions corrigées pour plusieurs failles critiques, et le CERT-FR a émis une alerte dans la foulée. Particularité de ces failles : elles ont été trouvées avec l’aide de l’IA. Il y a de bonnes chances que ce genre d’alerte devienne plus fréquent.
Dans les jours qui ont suivi, j’ai entendu la même question chez les freelances et les agences que j’accompagne dans Unblur : est-ce que c’était à moi de m’en occuper ? Et si oui, gratuitement ? Certains ont passé leur semaine à relancer un hébergeur débordé. D’autres en sont sortis avec des rendez-vous dans l’agenda.
Qui doit s’occuper de la faille PHP : toi ou l’hébergeur ?
WordPress, le thème et les extensions, c’est ton terrain. PHP, c’est le serveur, et le serveur appartient à l’hébergeur ou à la personne qui l’administre. Ouvre ton contrat de maintenance (ou ton devis si tu n’as jamais fait de contrat) : tu vas tomber sur l’un de ces trois cas.
| Ton cas | Ce que tu fais | Qui paie |
|---|---|---|
| C’est écrit : tu gères l’hébergement, ou ton contrat mentionne la surveillance de PHP | Tu t’en occupes | Déjà compris dans le contrat |
| C’est flou : ton contrat dit « mises à jour » sans préciser | Le minimum qui protège le site (vérifier que l’hébergeur a appliqué le correctif, le relancer), puis tu clarifies le contrat avec ton client | À titre exceptionnel cette fois ; une montée de version se chiffre à part |
| C’est hors contrat : ancien client, site livré il y a des années | Tu le signales, parce que tu es la personne la mieux placée pour le faire | Une intervention ponctuelle, à prix fixe, avec son accord |
L’urgence peut justifier d’agir vite. Elle ne décide pas pour autant qui paie.
Comment vérifier tes sites avant d’écrire à tes clients ?
Avant d’envoyer le moindre message, sors la liste de tes sites et note pour chacun : l’hébergeur, le type d’hébergement (mutualisé ou serveur), la version de PHP, qui a la main dessus, et dans quel cas du tableau il tombe. Tu obtiens trois piles : les sites déjà à jour, ceux à faire corriger chez l’hébergeur, et ceux bloqués sur une vieille version.
La version de PHP se lit dans WordPress, dans Outils, puis Santé du site, onglet Infos, section Serveur. Attention, certains hébergeurs appliquent le correctif sans changer le numéro affiché : o2switch, par exemple, a corrigé ses versions dans la nuit alors que WordPress continuait d’afficher l’ancien numéro. Dans le doute, c’est le support de l’hébergeur qui te donne la vraie réponse.
Que dire à tes clients après une faille de sécurité ?
La règle de base : ton client n’apprend jamais après coup qu’on a touché à son site. Ton message d’avant répond en quelques lignes à cinq questions : ce qui se passe, sans jargon, ce que tu vas faire, quand, le risque, et ce que ça lui coûte.
- Segmente par situation. Site hébergé chez toi : il n’a rien à faire. Hébergé ailleurs : il vérifie avec son hébergeur, ou tu regardes pour lui.
- Parle de son site, pas de ton offre. Le prix n’arrive que quand tu proposes une intervention.
- Donne un seul point de contact : une adresse ou un lien de rendez-vous.
- Referme la boucle avec un second message court qui dit « c’est fait », même à ceux qui n’avaient rien à faire. Presque personne ne l’envoie, et c’est lui qui rassure le plus.
Un point de vigilance si tu écris au-delà de tes clients : en France, c’est de la prospection, avec des règles différentes selon que tu t’adresses à un professionnel ou à un particulier (voir la CNIL).
Pourquoi une alerte de sécurité est le meilleur moment pour parler de ta maintenance
Une intervention qui ne se voit pas n’existe pas pour ton client. Chez Whodunit, on envoyait des rapports de maintenance, et beaucoup de clients ne les lisaient jamais. La valeur venait du moment où on les parcourait ensemble, en rendez-vous. Quinze minutes de visio la semaine d’une alerte valent dix rapports.
Ce que ton client paie, ce n’est pas le temps passé sur la faille. C’est d’avoir quelqu’un qui le prévient, lui explique et le rassure. Vends la relation, pas les heures. Pour tes anciens clients, le compte rendu se termine d’ailleurs par la proposition d’un contrat, pour que la prochaine alerte soit gérée sans qu’ils aient à y penser.
Ce que tu en retiens
- Cherche « PHP », « serveur » ou « hébergement » dans ton contrat de maintenance. S’ils n’y sont pas, c’est le flou qui te fera encore travailler gratuitement à la prochaine alerte.
- Fais l’inventaire de ton parc : hébergeur, version de PHP, qui a la main.
- Repère tes sites en PHP 8.2 avant le 31 décembre 2026.
- Demande à ton hébergeur comment il te prévient en cas d’incident et qui applique les correctifs PHP sur ton offre.
Questions fréquentes
La mise à jour de PHP fait-elle partie de la maintenance WordPress ?
Pas automatiquement. Une maintenance WordPress couvre en général WordPress, le thème et les extensions. PHP relève du serveur, donc de l’hébergeur, sauf si le freelance ou l’agence gère l’hébergement ou si le contrat mentionne explicitement la surveillance de la version de PHP.
Comment connaître la version de PHP d’un site WordPress ?
Dans l’administration WordPress, menu Outils, puis Santé du site, onglet Infos, section Serveur. Après un correctif de sécurité, certains hébergeurs ne changent pas le numéro affiché : seul leur support peut confirmer que la correction est appliquée.
Quand PHP 8.2 arrive-t-il en fin de vie ?
Le 31 décembre 2026. Après cette date, les sites WordPress en PHP 8.2 ne reçoivent plus de correctifs de sécurité officiels : chaque version de PHP vit quatre ans, deux ans de corrections complètes puis deux ans de correctifs de sécurité seulement.
Faut-il facturer une intervention de sécurité hors contrat ?
Oui, avec l’accord du client et à prix fixe. Il vaut mieux distinguer trois prestations : la vérification du correctif (un forfait), la montée de version de PHP (un devis après test de compatibilité), et l’investigation si le site a été compromis (une prestation à part entière).
Le modèle de message à envoyer à tes anciens clients, et comment fixer le prix de l’intervention, sont dans l’édition du 28 octobre de L’associée business, ma newsletter du mercredi pour les freelances et les agences web.
Chaque semaine, un sujet concret et la méthode pour le transformer en chiffre. 👉 https://behindthewho.substack.com/
Sources : alerte CERT-FR CERTFR-2026-ALE-014 ; annonce PHP du 21/10/2026 ; PHP, versions supportées ; Yes We Blog (cas o2switch) ; The Next Web (découverte par l’IA).
Laisser un commentaire