21, 22 et 23 octobre 2026. Trois journées un peu particulières dans mon quotidien de développeur web freelance à Chartres. Deux importantes failles de sécurité découvertes dans PHP, le langage de programmation que j'utilise depuis près de 20 ans, viennent semer une certaine inquiétude dans le monde du web.
Pour les propriétaires de sites internet, cette actualité peut sembler assez lointaine ou incompréhensible. Pour un développeur qui accompagne des entreprises, des professionnels et des associations depuis des années, elle soulève immédiatement de nombreuses questions.
Quels sites sont concernés ? Quels sont les risques ? Comment protéger les clients ? Et que faire des sites anciens qui ne peuvent pas facilement fonctionner avec les dernières versions de PHP ?
Voici comment j'ai vécu ces trois journées, entre inventaire des sites, échanges avec les clients, recherche de solutions et quelques bonnes surprises.
Mercredi 21 octobre : une alerte qui concerne potentiellement des millions de sites
Tout commence véritablement pour moi le mercredi 21 octobre, lorsque l'alerte prend de l'ampleur.
La veille, les responsables de PHP ont annoncé l'existence de deux failles de sécurité critiques. Des informations ont commencé à circuler avant leur divulgation complète, accélérant la publication des correctifs.
Ces vulnérabilités, référencées CVE-2026-109618 et CVE-2026-109619, sont particulièrement préoccupantes : dans certaines conditions, elles peuvent permettre à un attaquant d'exécuter du code à distance sur un serveur, sans même avoir besoin de s'identifier.
Autrement dit, une personne malveillante pourrait potentiellement prendre le contrôle d'un site, modifier son contenu, accéder à des informations confidentielles ou interrompre son fonctionnement.
Et le problème ne vient pas d'une erreur commise lors du développement d'un site. Il se situe directement dans PHP. Même un site parfaitement développé peut donc être concerné.
L'ampleur du problème devient rapidement évidente. Plusieurs sites institutionnels français, notamment ceux des impôts et de certaines préfectures, sont temporairement rendus indisponibles par précaution, comme le rapporte La Dépêche dans son article du 21 octobre.
De mon côté, je commence à réfléchir à la stratégie à adopter.
Je sais déjà que plusieurs générations de sites vont être concernées, avec des situations techniques et financières très différentes. Certains sites sont récents, d'autres ont été développés il y a plus de dix ans. Certains sont très utilisés, d'autres beaucoup moins.
Les correctifs officiels sont publiés dans la journée pour les versions récentes de PHP. Mais une difficulté se dessine immédiatement : que faire des sites fonctionnant encore avec d'anciennes versions qui ne bénéficient plus du support officiel ?
Jeudi 22 octobre : faire l'inventaire et contacter les clients
Le jeudi, je passe à l'action.
Première étape : reprendre la liste de tous les sites internet encore en activité que j'ai développés ou sur lesquels j'interviens.
Cela concerne mes clients directs, bien sûr, mais également les sites que je réalise ou maintiens en sous-traitance pour d'autres entreprises.
C'est dans ce genre de situation que je mesure l'intérêt d'avoir un fichier de suivi régulièrement actualisé : les noms de domaine, les hébergements, les versions de PHP utilisées, les coordonnées des interlocuteurs et l'historique des interventions.
Un site créé il y a douze ans peut toujours être en activité. Et même si je n'interviens plus dessus au quotidien, il faut pouvoir retrouver les informations nécessaires.
Je distingue rapidement plusieurs catégories de sites.
Les premiers utilisent des versions relativement récentes de PHP. Pour ceux-là, les opérations devraient être assez simples : vérifier les correctifs disponibles, les appliquer et contrôler le bon fonctionnement du site.
Viennent ensuite les sites utilisant PHP 8.1 ou des versions antérieures. Ces versions ne sont plus maintenues officiellement. À ce stade, les possibilités de correction dépendent donc des hébergeurs ou d'une migration vers une version plus récente.
Enfin, il reste quelques sites beaucoup plus anciens, notamment sous PHP 5.6, pour lesquels la situation est nettement plus délicate.
Expliquer les risques sans inquiéter inutilement
Une fois ce premier inventaire réalisé, je prends mon téléphone et commence à contacter les clients concernés, ainsi que les entreprises pour lesquelles je travaille en sous-traitance.
L'exercice n'est pas aussi simple qu'il paraît.
Comment expliquer à quelqu'un qui n'a aucune connaissance technique que son site fonctionne avec une version de PHP devenue vulnérable ? Comment lui faire comprendre que le risque est sérieux, tout en évitant de l'alarmer inutilement ?
Je prends le temps d'expliquer ce qu'est PHP, pourquoi ces failles concernent potentiellement autant de sites internet et quelles peuvent être les conséquences concrètes d'une attaque.
J'insiste aussi sur un point important : ce problème n'est pas lié à une mauvaise conception de leur site internet. Il touche directement un composant technique utilisé par une grande partie du web.
L'objectif n'est pas de créer de l'inquiétude, mais de permettre à chacun de comprendre la situation et de prendre les bonnes décisions.
Les mises à jour réalisées ces dernières années prennent tout leur sens
Au fil de mes vérifications, je réalise également quelque chose d'assez satisfaisant.
Depuis deux ans, j'ai régulièrement proposé à mes clients de faire évoluer leurs sites pour les rendre compatibles avec PHP 8.
Ces opérations ne sont pas toujours très visibles pour eux. Contrairement à une refonte graphique, elles ne changent pas nécessairement l'apparence du site. Pourtant, elles peuvent représenter un vrai travail de développement : certaines fonctions ont disparu, d'autres ont changé de comportement et il faut parfois reprendre plusieurs parties du code.
Ce sont aussi des interventions qui ont un coût, pas toujours facile à justifier lorsque le site fonctionne encore parfaitement.
Mais aujourd'hui, les clients qui avaient accepté ces mises à jour se retrouvent dans une situation bien plus confortable.
Leurs sites sont déjà compatibles avec des versions récentes de PHP. Ils peuvent donc bénéficier des correctifs de sécurité sans nécessiter une remise à niveau complète du code.
Je me félicite d'avoir insisté sur ces évolutions au fil des années. C'est précisément le rôle que j'estime devoir jouer auprès de mes clients : ne pas simplement intervenir lorsqu'un problème apparaît, mais proposer des améliorations pour éviter qu'il ne devienne trop important.
Les sites plus anciens : des situations à traiter au cas par cas
Pour les sites encore sous PHP 7, une migration vers PHP 8.2 ou une version supérieure semble envisageable avec un travail d'adaptation raisonnable dans plusieurs cas. Il faut naturellement vérifier les fonctionnalités, corriger les incompatibilités et réaliser des tests avant toute mise en production.
En revanche, les quelques sites qui fonctionnent encore sous PHP 5.6 posent des questions plus compliquées.
Certains ont été développés il y a dix ou quinze ans. Les technologies ont beaucoup évolué depuis et une migration ne se résume pas forcément à changer un paramètre sur l'hébergement.
Il faut alors examiner chaque situation.
Pour les sites commerciaux, la discussion est finalement assez naturelle. Les clients comprennent généralement qu'un site internet vieux de dix ans ou davantage ne peut pas fonctionner éternellement sans évolution majeure.
Dans certains cas, une refonte complète devient plus pertinente qu'une succession de corrections sur un code très ancien. C'est l'occasion de repartir sur des bases techniques actuelles, mais aussi de moderniser l'interface et les fonctionnalités.
D'autres situations sont moins évidentes.
Je pense notamment à certaines associations disposant de budgets très limités, avec des sites qui ne sont presque plus utilisés mais qui restent accessibles sur Internet.
Faut-il investir dans une mise à jour parfois coûteuse ? Envisager un nouveau site plus simple ? Suspendre temporairement un service vulnérable ?
Il n'existe pas de réponse universelle. Le niveau de risque doit être évalué et les mesures de protection ne peuvent pas être repoussées indéfiniment. Mais les contraintes financières et l'utilité réelle du site doivent aussi entrer dans la réflexion.
Pour quelques-uns de ces dossiers, la question reste encore ouverte.
Reprendre contact avec d'anciens clients
Au cours de cette journée, je décide également de contacter d'anciens clients avec lesquels je n'ai parfois plus échangé depuis plusieurs années.
Certains gèrent désormais eux-mêmes leur hébergement ou ont confié la maintenance de leur site à un autre prestataire.
Je n'ai donc plus nécessairement la main sur leurs installations, mais je connais les technologies utilisées à l'époque et je sais qu'ils pourraient être concernés.
Je prends simplement l'initiative de les prévenir et de leur conseiller de vérifier leur situation.
Cette démarche est particulièrement bien accueillie.
Elle me rappelle qu'une relation professionnelle ne se limite pas à la livraison d'un site ou à une prestation facturée. Même après plusieurs années, prendre quelques minutes pour informer un ancien client d'un risque potentiel est une attention qui compte.
Vendredi 23 octobre : une bonne nouvelle pour les anciennes versions de PHP
Et puis, le vendredi, une information vient modifier une partie de mon analyse.
Des correctifs de sécurité ont finalement été mis à disposition pour certaines anciennes versions de PHP, y compris PHP 5.6 !
Il faut préciser un point important : ces correctifs ne correspondent pas à une reprise du support officiel de ces versions par le projet PHP.
Ce sont notamment des correctifs dits rétroportés, proposés par certains fournisseurs spécialisés. Le principe consiste à corriger une vulnérabilité dans une ancienne version sans imposer immédiatement une migration vers une nouvelle génération de PHP.
Par exemple, CloudLinux confirme la disponibilité de correctifs pour des versions allant jusqu'à PHP 5.2 sur certains de ses environnements.
C'est une très bonne nouvelle pour les propriétaires de sites anciens.
Cela peut permettre de sécuriser rapidement certains sites tout en conservant leur version actuelle de PHP, et donc sans devoir engager immédiatement de lourds travaux de compatibilité.
Mais attention : la disponibilité d'un correctif ne signifie pas automatiquement qu'il est installé sur tous les hébergements.
Il faut vérifier la solution utilisée par l'hébergeur, la disponibilité des mises à jour et leur déploiement effectif.
Autre subtilité : avec ces correctifs rétroportés, le numéro de version de PHP ne change pas nécessairement. Un serveur peut continuer à afficher PHP 7.4.33 tout en ayant reçu une correction de sécurité spécifique. À l'inverse, ce seul numéro ne suffit pas à prouver que la correction a été appliquée.
Et surtout, cette bonne nouvelle ne règle pas le problème de fond : les anciennes versions de PHP restent obsolètes. Un correctif ponctuel ne remplace pas une véritable politique de mise à jour sur le long terme.
Cette évolution donne néanmoins un peu de temps pour envisager des migrations plus sereinement, sans devoir prendre toutes les décisions dans l'urgence.
Ce que je retiens de ces trois journées
Ces trois jours auront été particulièrement riches en échanges, en vérifications techniques et en réflexions sur la maintenance des sites internet.
Ils viennent surtout confirmer plusieurs convictions que j'ai acquises au fil de mon activité de développeur web freelance.
La première, c'est qu'un site internet ne doit jamais être considéré comme un produit terminé une fois mis en ligne. Même s'il fonctionne parfaitement et que son apparence reste actuelle, les technologies sur lesquelles il repose continuent d'évoluer.
La deuxième, c'est que les opérations de maintenance préventive ont une vraie valeur. Les mises à jour de compatibilité PHP que j'ai proposées ces deux dernières années ont parfois demandé un investissement à mes clients, mais elles leur évitent aujourd'hui des interventions bien plus importantes.
La troisième, c'est l'importance du suivi. Disposer d'informations à jour sur les sites développés, leurs hébergements et leurs interlocuteurs fait gagner un temps considérable dans une situation d'urgence.
Enfin, ces journées m'ont rappelé que mon métier ne consiste pas seulement à développer des sites internet.
Il consiste aussi à conseiller, anticiper, expliquer et accompagner des personnes qui n'ont pas forcément les connaissances techniques pour mesurer les enjeux de sécurité.
Depuis 2008, j'ai vu PHP évoluer, des technologies apparaître et d'autres disparaître. Les sites que je développe aujourd'hui n'ont techniquement plus grand-chose à voir avec ceux que je réalisais à mes débuts.
Mais une chose ne change pas : la qualité d'un site internet ne se mesure pas uniquement au jour de sa mise en ligne. Elle se mesure aussi à sa capacité à évoluer et à rester fiable dans le temps.
Et cette semaine d'octobre 2026 en aura été une bonne illustration.
Pour approfondir le sujet : consultez également l'alerte officielle du CERT-FR ainsi que les recommandations de sécurité publiées par PHP.