Publié le · par Patrick Faramaz
Imaginez la situation : vous recevez une alerte sur une faille importante dans PHP, un logiciel utilisé par de nombreux sites. Votre site fonctionne toujours, mais les questions arrivent aussitôt : « Sommes-nous concernés ? Faut-il le mettre hors ligne ? Qui peut vérifier ? »
Ce scénario illustre une difficulté bien concrète : sans interlocuteur identifié, il faut chercher de l’aide tout en essayant de comprendre l’urgence. Un contrat de maintenance bien défini prépare cette organisation avant l’incident. Sa valeur ne se résume pas à effectuer des mises à jour.
Avoir quelqu’un à appeler, qui ne découvre pas votre site
Un prestataire sollicité pour la première fois doit commencer par comprendre l’existant. Où le site est-il hébergé ? Qui possède les accès ? Quels développements ont été ajoutés ? Les sauvegardes sont-elles exploitables ? Cette prise de connaissance est nécessaire, même pour une personne expérimentée.
Une relation de maintenance suivie permet de préparer ces réponses. L’interlocuteur connaît l’environnement, l’historique des interventions et les fonctions importantes pour l’entreprise. Il dispose des accès autorisés nécessaires, gérés de manière sécurisée, et sait comment joindre l’hébergeur si son intervention est requise.
Cela ne supprime pas le diagnostic. Cela évite de reconstruire tout le contexte au moment où il faudrait déjà pouvoir agir. Le contrat doit précisément prévoir cette connaissance du site, pas seulement afficher une adresse de contact.
L’alerte PHP d’octobre 2026 : un exemple concret
Le 21 octobre 2026, le projet PHP a annoncé des correctifs pour deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619, connues sous le nom de « PHP2Shell ». Elles pouvaient permettre l’exécution de code à distance sans authentification sur des installations PHP traitant des requêtes web. L’avis signalait un risque particulièrement élevé avec Apache et son module PHP.
Les versions correctives annoncées étaient PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12 ; les paquets corrigés proposés par les distributions ou fournisseurs devaient également être vérifiés. Le 26 octobre, la CISA, agence américaine de cybersécurité, a ajouté les deux vulnérabilités à son catalogue des failles exploitées. Il ne s’agissait donc plus seulement d’un risque théorique (PHP, CISA).
Cet exemple concerne le moteur PHP, pas une extension WordPress particulière. Il montre pourquoi une alerte générale doit être rapprochée de la situation réelle du site : logiciel utilisé, version effectivement exécutée, correctifs du fournisseur et exposition du service.
« Faut-il tout mettre hors ligne ? » : une décision à qualifier
Face à une faille critique, couper le site peut sembler être le seul moyen de se rassurer. Mais une mise hors ligne est une mesure de confinement, pas une réparation ni une preuve d’absence de compromission.
Dans son alerte PHP, la CISA recommandait notamment de mettre hors ligne les systèmes qui ne pouvaient pas être corrigés immédiatement. Cette recommandation répondait à une menace précise. Elle ne signifie pas que toute alerte, sur n’importe quel composant, impose automatiquement de fermer tous les sites.
Le rôle de l’interlocuteur technique est d’examiner rapidement les faits : le site est-il concerné par cette vulnérabilité ? Un correctif existe-t-il et peut-il être appliqué ? Quelles mesures temporaires sont pertinentes, avec quelles limites ? Faut-il restreindre un service ou suspendre son accès pendant l’intervention ?
La décision doit être expliquée, avec ses conséquences pour l’activité et les conditions de remise en service. Elle ne doit reposer ni sur la panique, ni sur un « tout va bien » sans vérification.
Agir, puis rendre compte de ce qui a été vérifié
Un bug de formulaire et une suspicion d’intrusion ne demandent pas la même réponse. Dans les deux cas, il faut qualifier le problème, identifier son périmètre et décider des actions adaptées.
Pour une alerte de sécurité, appliquer le correctif ne suffit pas toujours à clore le sujet. Il peut aussi être nécessaire de rechercher des traces de compromission, de conserver les éléments utiles à l’analyse et de poursuivre les investigations. Une mise à jour ne retire pas, à elle seule, les conséquences d’une intrusion déjà survenue.
L’intervention doit s’appuyer sur des sauvegardes dont la restauration a été testée, prévoir les tests nécessaires et contrôler les fonctions essentielles après changement. La documentation de WordPress sur la sécurité rappelle justement l’importance des sauvegardes, des journaux et de la surveillance, au-delà des mises à jour.
La réponse utile pour le dirigeant est factuelle : quel composant était concerné, ce qui a été corrigé, les contrôles réalisés, les incertitudes restantes et la suite prévue. Dire « ce site n’est pas concerné par cette faille dans le périmètre vérifié » est plus précis que promettre un site « hors de danger ».
Ce que le contrat doit rendre concret
Le mot « maintenance » peut recouvrir des engagements très différents. Avant de signer, vérifiez quelques points :
- Le périmètre : site, développements spécifiques, extensions, environnement serveur ; ce qui est inclus et ce qui ne l’est pas.
- Les modalités d’urgence : qui contacter, par quel canal, sur quels horaires et selon quels niveaux de priorité.
- Les délais définis : la prise en charge d’une demande n’est pas sa résolution. Un diagnostic peut révéler un problème dépendant d’un éditeur ou de l’hébergeur.
- Les responsabilités : qui surveille les alertes, applique les correctifs, gère les sauvegardes et décide d’une interruption du service.
- La continuité du suivi : documentation, accès, compte rendu et transmission des informations si le prestataire change.
Un contrat engage sur ce qu’il définit. Il ne promet pas automatiquement une disponibilité instantanée, une couverture permanente ou la résolution de tous les incidents. Ces points doivent être écrits, compris et adaptés à l’importance du site pour votre entreprise.
Ne pas attendre l’urgence pour organiser la réponse
Quand votre site participe à votre activité, savoir qui peut intervenir compte autant que savoir qu’il faut l’entretenir. Un contrat de maintenance sert à établir cette relation, ses moyens et ses limites avant qu’un problème survienne.
Vous ne savez pas qui appeler si votre site rencontre un incident ? Faites le point avec Goodmotion sur votre organisation actuelle et le cadre de maintenance adapté à votre site.
*Sources officielles consultées le 6 novembre 2026 : annonces du projet PHP, alerte CISA mise à jour le 26 octobre et documentation de sécurité WordPress, accessibles dans les liens de l’article.*