Maintenance préventive d'un site web : anticiper les incidents au lieu de les subir

Le 5 avril 2026, l'activation d'un backdoor injecté huit mois plus tôt dans les 31 extensions du portefeuille Essential Plugin a compromis des dizaines de milliers de sites WordPress en moins de 48 heures. Deux jours après, l'infrastructure de mise à jour de Smart Slider 3 Pro, utilisée sur plus de 800 000 sites dans le monde, était à son tour piratée. Sur ce type d'attaque, les durées de récupération oscillent typiquement entre quelques heures et plusieurs semaines selon l'état de préparation du site touché, alors que la nature technique de la compromission est identique d'un site à l'autre. La différence ne se joue pas pendant l'incident, mais dans tout ce qui a été préparé ou négligé avant : les accès retrouvés ou pas dans la nuit, la sauvegarde déjà testée ou pas, l'hébergeur que nous savions joindre ou pas.

Cet écart de quelques heures contre plusieurs jours n'est pas anecdotique. Il décide d'une remédiation gérable ou d'une crise existentielle pour la PME qui en dépend. Il décide aussi de la conformité réglementaire, de la perte de chiffre d'affaires en ligne et de l'atteinte SEO qui suit un passage en « contenu piraté » dans les résultats Google. Cet article décrit ce que recouvre vraiment la maintenance préventive d'un site web, au-delà de la mise à jour mensuelle des extensions, et comment chacune de ses disciplines réduit concrètement le temps de récupération quand l'incident finit par arriver.

Ce que recouvre vraiment la maintenance préventive

La maintenance préventive d'un site web est très souvent réduite à un seul geste : cliquer sur « mettre à jour » une fois par mois dans le tableau de bord de WordPress, vérifier que le certificat SSL se renouvelle automatiquement, et considérer le travail terminé. Cette lecture courte est répandue, y compris dans certains contrats facturés comme tels, et elle laisse de côté tout ce qui fait la différence le jour où quelque chose lâche.

La vraie maintenance préventive est ce que nous entretenons pour que le site garde sa capacité à survivre à un incident. Elle suppose d'admettre, avant même d'écrire une ligne de code de défense, qu'un incident finira par arriver. Statistiquement, pour un site qui tourne plus de quelques années, ce n'est plus une question de probabilité. Une vulnérabilité critique sur une extension installée, une compromission d'éditeur via la chaîne d'approvisionnement, une panne datacenter, une erreur humaine de déploiement, un disque qui meurt sans préavis : la liste des événements qui mettent un site à genoux est longue, et aucune de ces catégories n'est rare.

Cet article s'appuie sur l'exemple WordPress parce que les attaques d'avril 2026 sont récentes, documentées et représentatives, et parce que WordPress fait tourner une part majoritaire des sites de PME. Les principes décrits sont valables pour n'importe quelle stack. Shopify, Drupal, Magento, les applications Laravel ou Symfony, les sites JavaScript construits sur Next.js ou Nuxt, les développements sur mesure : aucun de ces écosystèmes n'échappe aux vulnérabilités d'extensions ou de dépendances, aux compromissions de chaîne d'approvisionnement, aux pannes hébergeur ou aux erreurs humaines. Aucun CMS, aucun framework, aucune architecture n'élimine la question de la résilience opérationnelle. Le périmètre des mesures techniques s'adapte à la stack, leur nécessité demeure.

À partir de ce postulat, le travail change de nature. Il ne s'agit plus seulement d'empêcher (c'est le rôle de la sécurité préventive, traitée dans notre article sur le durcissement WordPress) ni de nettoyer (c'est le rôle du diagnostic et de la désinfection, traités dans notre article sur les attaques Essential Plugin et Smart Slider 3 Pro d'avril 2026). Il s'agit de tenir vivants, à tout moment, tous les éléments dont l'équipe aura besoin pour réagir vite : les accès, les sauvegardes, la connaissance de l'hébergeur, les logs, le plan d'action. Ces éléments ne servent à rien pendant 99 % du temps, ce qui explique pourquoi ils sont presque toujours négligés. Et ils font la totalité de la différence pendant le 1 % où tout dépend d'eux.

Quand la même attaque produit des écarts de récupération de plusieurs jours

Les deux attaques d'avril 2026 contre Essential Plugin et Smart Slider 3 Pro ont rendu particulièrement visible une asymétrie connue depuis longtemps dans la sécurité informatique. Face à un incident donné, la sévérité finale dépend très peu de la complexité technique de l'attaque, et très fortement de l'état de préparation du site touché. Deux profils de sites se dégagent typiquement face à ce genre de compromission.

Le premier profil est celui d'un site maintenu avec une discipline complète. Accès SFTP et SSH à jour dans un coffre-fort partagé, sauvegarde de la veille restaurable en quelques minutes, connaissance directe de l'hébergeur avec un canal de contact identifié, logs Apache et PHP consultables et conservés plus de 30 jours, procédure de nettoyage déjà écrite et déjà rodée sur des incidents antérieurs. Pour ce profil, la séquence de remédiation tient en quelques heures : isolation, restauration, vérification d'intégrité, rotation des secrets, remise en ligne. La perte de chiffre d'affaires est marginale, la perte de données nulle, la notification réglementaire faite dans les délais prévus par le RGPD ou la Loi 25.

Le second profil est celui d'un site où plusieurs maillons manquent. Le développeur qui a fait le site trois ans plus tôt n'est plus joignable, personne ne sait où sont les accès SFTP, le support hébergeur répond par ticket avec un délai de 48 à 72 heures, la dernière sauvegarde dort sur un disque dur dont personne ne se souvient plus du chiffrement, et le fichier wp-config.php infecté ne livre rien d'exploitable sans accès à des logs qui ont déjà été tournés. Pour ce profil, la remédiation se compte en semaines. Le coût se mesure en perte de chiffre d'affaires, en réinstallation complète depuis zéro avec recréation de contenu, parfois en notification réglementaire hors délai avec les sanctions associées, et presque toujours en travail de reconstruction d'autorité SEO après le marquage du site en « contenu piraté » par Google.

Cette polarité est un constat sectoriel récurrent. Les acteurs de la sécurité WordPress (Wordfence, Patchstack, Sucuri) en font régulièrement état dans leurs bilans annuels et leurs analyses post-incident. La résilience opérationnelle, qui est précisément la discipline qui consiste à se préparer pour réduire la sévérité d'un incident, est documentée depuis plus de vingt ans dans la sécurité informatique d'entreprise. Elle reste largement absente du périmètre habituel de la maintenance facturée aux PME propriétaires d'un site web, qui découvrent au moment du premier incident sérieux que la maintenance qu'elles pensaient avoir n'incluait pas les éléments qui auraient changé l'issue.

Connaître son hébergeur avant d'en avoir besoin

L'hébergeur d'un site web est l'interlocuteur de première ligne quand quelque chose lâche. C'est lui qui a accès à l'infrastructure physique, qui voit les pics de trafic suspects, qui peut isoler un site compromis du reste de son parc, et qui dispose souvent de sauvegardes ou d'outils de récupération que le propriétaire n'a pas. Le problème, pour la majorité des PME, c'est que l'hébergeur reste un fournisseur abstrait dont elles n'ont jamais eu besoin avant l'incident, et qu'elles découvrent dans les pires conditions possibles.

Qui appeler, comment, à quel délai réel

La première information à connaître est concrètement, à 23 heures un dimanche, qui contacter chez son hébergeur en cas d'incident, et quel est le délai de réponse réel. Ce délai est rarement celui qui figure sur la page commerciale. Les offres mutualisées entrée de gamme indiquent souvent un support « 24/7 » qui se traduit à l'épreuve par un ticket lu dans les 24 à 48 heures et une réponse rapide uniquement pendant les horaires de bureau. Les offres WordPress infogérées (O2Switch ou WPServeur côté France, WPCloud.ca ou LIKUID côté Québec, Kinsta ou WP Engine côté nord-américain) proposent des temps de réponse réels mesurés en minutes pour les incidents qualifiés comme prioritaires, mais l'accès à ce niveau de service suppose souvent une offre dédiée et un canal de signalement spécifique.

La bonne pratique consiste à tester son support hébergeur avant d'en avoir besoin. Une question technique non urgente envoyée par les canaux normaux (ticket, chat, téléphone selon ce qui existe), avec mesure du temps de première réponse et de résolution, donne en quelques jours une lecture honnête de ce que nous pouvons attendre le jour J. Cette mesure prend 30 minutes à organiser et elle évite de découvrir au pire moment que le support imaginé n'existe pas dans la fenêtre temporelle nécessaire. Pour un site critique, il vaut la peine de programmer ce test deux fois par an, parce que les niveaux de service évoluent et qu'un support qui était excellent il y a 18 mois peut s'être dégradé silencieusement.

Le périmètre du support, où il s'arrête vraiment

La deuxième information à connaître est le périmètre du support. Un hébergeur intervient sur l'infrastructure : disponibilité du serveur, connectivité réseau, performance globale, sauvegardes côté hébergement. Il n'intervient quasiment jamais sur le contenu applicatif. Un site WordPress compromis par un plugin malveillant n'est pas, au sens strict, un problème d'hébergement. Le support pourra fournir des accès, des logs, parfois isoler le site pour limiter la propagation, mais le nettoyage, le diagnostic et la remise en service restent à la charge du propriétaire ou de son agence.

Les offres infogérées brouillent cette frontière en incluant des prestations applicatives (mises à jour de WordPress et des extensions, scans de sécurité, sauvegardes WordPress dédiées), ce qui élargit le périmètre couvert. Les contrats détaillent toujours ce qui est inclus et ce qui ne l'est pas, et le moment de les lire est avant l'incident, pas pendant. Pour un site qui compte, il vaut la peine de demander explicitement à l'hébergeur quels scénarios il prend en charge dans le cadre du contrat, quels scénarios bascullent sur facturation à l'intervention, et quels scénarios sont simplement hors périmètre. La réponse écrite à ces trois questions, archivée avec le contrat, vaut mieux que la promesse commerciale orale qui ne pèsera pas lourd le jour d'une dispute.

Mutualisé, infogéré, VPS : trois conversations distinctes en cas d'incident

Selon le type d'hébergement, la conversation en cas d'incident n'est pas la même. Sur un mutualisé classique (offres économiques chez OVH, Hostinger ou Hostpapa côté France, offres entrée de gamme chez WHC ou Astral Internet côté Québec), l'hébergeur dispose d'un accès limité au site lui-même et le propriétaire reste responsable de presque tout ce qui ne touche pas à l'infrastructure partagée. Sur une offre WordPress infogérée, l'hébergeur intervient activement sur le site, dispose d'outils internes de diagnostic et de remédiation, et propose souvent un canal de support technique de haut niveau pour les incidents WordPress qui le distingue nettement du mutualisé classique. Sur un VPS ou un serveur dédié, l'hébergeur n'intervient pas sur l'OS ni sur les applications, et la totalité de la maintenance applicative repose sur le propriétaire ou son équipe technique.

Savoir lequel de ces trois mondes nous habitons, et avoir conscience de ce que cela implique en cas d'incident, est une condition de base pour une maintenance préventive sérieuse. Le malentendu fréquent consiste à confondre une configuration ponctuelle réalisée par une agence et un contrat d'infogérance applicative. Sans précision explicite, un contrat d'hébergement reste un mutualisé standard, et le périmètre de support qu'il couvre ne s'étend pas au nettoyage d'un site compromis ni à la résolution d'un bug applicatif. Cette distinction se vérifie en lisant le contrat avant l'incident, pas en interpellant le support pendant.

Garder les accès vivants

Un site WordPress en production s'appuie sur une série d'accès techniques qui doivent rester opérationnels en permanence, et dont l'absence de l'un suffit à transformer une intervention rapide en chantier pénible. La maintenance préventive consiste à tenir ces accès à jour, à les documenter, et à les rendre disponibles pour les personnes qui en auront besoin sans dépendance à un individu unique.

L'inventaire des accès qui doivent rester opérationnels

Cinq familles d'accès méritent une vigilance permanente. Le premier est l'accès SFTP ou SSH au serveur d'hébergement, qui permet de lire et modifier les fichiers en dehors de l'interface WordPress, indispensable quand l'administration WordPress elle-même est compromise ou inaccessible. Le deuxième est l'accès à la base de données via phpMyAdmin ou en ligne de commande, qui permet d'inspecter ou de réparer des données quand l'interface WordPress refuse de fonctionner. Le troisième est l'accès au panneau d'administration de l'hébergeur (cPanel, Plesk, ou panneaux propriétaires comme celui d'O2Switch ou de Kinsta), qui donne accès aux logs, aux sauvegardes hébergeur, à la gestion DNS et aux outils de monitoring. Le quatrième est l'accès en ligne de commande via WP-CLI, qui permet d'exécuter des opérations WordPress sans passer par l'interface graphique, particulièrement utile sur les sites lourds ou compromis. Le cinquième est l'accès à la zone DNS du domaine, qui peut être hébergée chez le bureau d'enregistrement ou chez l'hébergeur, et qui est critique pour basculer le site sur une infrastructure de secours en cas de panne grave ou pour modifier rapidement les enregistrements MX en cas de compromission du serveur de courriel associé.

Ces accès doivent être documentés, attribués nommément à des personnes (pas à un compte générique partagé), et révisés chaque fois qu'une personne change de rôle ou quitte l'organisation. Un accès SSH avec une clé privée laissée chez un ancien prestataire est une porte d'entrée silencieuse qui survivra à la fin de la collaboration aussi longtemps qu'elle n'est pas explicitement révoquée. La revue des accès au moins une fois par an, et systématiquement à chaque changement structurant, est l'une des disciplines les plus rentables de la maintenance préventive.

Le coffre-fort partagé, règle de fonctionnement non négociable

Le moyen pratique de tenir cette discipline est un gestionnaire de mots de passe partagé entre les personnes qui ont besoin des accès. 1Password, Bitwarden, Dashlane Business ou des solutions équivalentes : les outils existent, ils sont peu coûteux (de l'ordre de quelques euros ou dollars par utilisateur et par mois), et ils résolvent simultanément le problème de la sécurité des mots de passe individuels, celui de la transmission entre membres d'une équipe ou entre le client et son agence, et celui de la révocation rapide quand un accès doit être retiré.

La règle de fonctionnement à poser dès le démarrage du site est simple : tout accès technique entre dans le coffre-fort à l'instant où il est créé, dans un dossier dédié au site. Le coffre est partagé avec les personnes qui ont besoin des accès, avec une gestion granulaire des droits qui permet de retirer un accès en quelques clics quand quelqu'un quitte le projet. Cette discipline évite la situation très classique où un site est tenu par un seul développeur qui détient seul les accès, et où son départ ou son indisponibilité bloque toute intervention pendant des jours. Pour un site qui appartient à une organisation, c'est aussi une question de souveraineté élémentaire : les accès d'un site appartiennent à l'organisation, pas à l'individu qui les a créés.

Gestion des sauvegardes : périmètre, rotation, tests, hors ligne

Les principes des sauvegardes (règle 3-2-1, profondeur de rétention contre les attaques dormantes, importance d'une copie immutable hors ligne) ont été posés dans notre article sur les attaques Essential Plugin et Smart Slider 3 Pro. Ce que nous traitons ici est différent : ce que nous entretenons dans le temps pour que ces sauvegardes soient effectivement utilisables le jour où nous en avons besoin. La majorité des sauvegardes qui existent sur le papier ne sont jamais testées, ne couvrent pas tout ce qu'elles devraient couvrir, ou échouent silencieusement sans que personne ne s'en aperçoive avant l'incident.

Le périmètre exact d'une sauvegarde

Une sauvegarde « complète » est souvent moins complète qu'elle ne paraît. Une sauvegarde WordPress standard archive le contenu du répertoire d'installation (cœur, extensions, thèmes, médias dans /wp-content/uploads) et l'export de la base de données. Ce qui manque presque toujours : la configuration serveur (fichiers vhosts Apache ou nginx, règles .htaccess spécifiques, configuration PHP-FPM), les tâches cron système configurées hors WordPress, les certificats SSL personnalisés non gérés par Let's Encrypt, les fichiers placés en dehors de l'arborescence WordPress (scripts maison, dossiers d'imports, exports comptables), et les configurations d'extensions stockées en dehors de la base WordPress (rares mais présentes pour certains plugins de cache, de CDN ou d'optimisation d'images).

Pour un site standard, le manque le plus dommageable est celui de la configuration serveur. Une restauration de site qui ne réinstalle pas le .htaccess ou la configuration nginx peut redémarrer le site avec un comportement subtilement différent (URL réécrites cassées, certificat manquant, cache désactivé, redirections perdues), ce qui complique le diagnostic et peut générer une période d'instabilité après restauration. La règle pratique est de faire l'inventaire écrit, une fois pour toutes, de tout ce qui est nécessaire à reconstruire un site identique, et de vérifier que chaque élément de cet inventaire est couvert par au moins une sauvegarde régulière. Cet inventaire prend une à deux heures à établir et se révise lors des évolutions structurelles.

Rotation et profondeur de rétention

Une politique de rétention raisonnable pour un site WordPress qui compte combine plusieurs cadences imbriquées. Les sauvegardes quotidiennes couvrent les incidents récents (erreur humaine sur le jour, compromission détectée rapidement, perte de données mineure) et se conservent typiquement une à deux semaines. Les sauvegardes hebdomadaires couvrent les incidents qui se révèlent plus tardivement et se conservent un à trois mois. Les sauvegardes mensuelles couvrent les attaques dormantes longues, comme celle d'Essential Plugin où le backdoor avait été introduit huit mois avant son activation, et se conservent au moins douze mois.

Cette stratification a un coût de stockage très limité. Les sauvegardes mensuelles ne représentent que douze copies par an, soit quelques dizaines de gigaoctets pour la majorité des sites, ce qui tient largement dans les offres de stockage objet à quelques euros ou dollars par mois (Backblaze B2, Wasabi, Amazon S3 Glacier pour les profondeurs longues). La rétention par défaut de la plupart des hébergeurs est très courte (souvent 7 à 30 jours), ce qui justifie systématiquement l'ajout d'une sauvegarde indépendante avec une politique de rétention propre.

Vérifier que la sauvegarde a bien tourné

Le scénario le plus pénible n'est pas l'absence de sauvegarde, c'est la sauvegarde que nous croyons avoir et qui n'existe pas. Les échecs silencieux sont fréquents : espace disque saturé sur la destination, identifiants S3 expirés sans renouvellement, mise à jour d'extension qui casse le déclencheur, panne réseau qui interrompt le transfert, modification de mot de passe FTP qui passe inaperçue. La sauvegarde paraît programmée, le tableau de bord WordPress est vert, et personne ne consulte le fichier de log qui aurait alerté sur l'échec.

La parade est l'alerting automatique sur échec de sauvegarde. La plupart des extensions de sauvegarde sérieuses (UpdraftPlus, BlogVault, WP Vivid Backup, Jetpack Backup) proposent un envoi de notification par courriel ou webhook en cas d'échec. Encore faut-il que cette notification soit configurée, qu'elle pointe vers une adresse réellement surveillée par une personne, et qu'elle ne soit pas filtrée comme spam. Une vérification mensuelle manuelle sur l'existence et la taille de la dernière sauvegarde complète cette alerte, en captant les cas où l'alerte elle-même ne s'est pas déclenchée. Cette vérification prend trois minutes par site et par mois, ce qui en fait l'une des disciplines les moins coûteuses du dispositif.

Tester la restauration pour de vrai

Une sauvegarde non testée n'est pas une sauvegarde, c'est un pari. Le test consiste à restaurer la dernière sauvegarde sur un environnement de préproduction, vérifier que le site répond, que la base est cohérente, que les fonctionnalités critiques marchent (paiement, formulaire de contact, connexion administrateur, processus métier spécifique), et que la procédure de restauration tient dans le temps estimé. C'est typiquement à cette occasion que se révèlent les écarts entre ce qui est censé fonctionner et ce qui fonctionne vraiment : restauration trop lente face au RTO posé, étape intermédiaire manquante dans la procédure, élément critique absent du périmètre de la sauvegarde.

La cadence raisonnable est trimestrielle pour les sites en maintenance contractuelle, semestrielle au minimum pour les autres. Le test prend une à deux heures sur un site de taille moyenne, et il fait passer la sauvegarde du statut « supposée fonctionner » à « déjà fonctionné une fois ». Cette différence est exactement celle qui décide entre une remédiation en quelques heures et une remédiation en plusieurs jours. C'est aussi à cette occasion que la procédure de restauration se documente proprement, parce que ce qui paraît évident pendant le test devient impossible à reconstituer six mois plus tard sous pression.

La copie hors ligne, vraiment hors ligne

Les sauvegardes en ligne (côté hébergeur, sur un stockage objet type S3 ou B2, sur un Dropbox ou un Google Drive) restent vulnérables aux scénarios où l'environnement de production est compromis dans son ensemble. Un ransomware qui se propage sur le réseau de stockage et chiffre les sauvegardes en même temps que la production. Une suppression du compte hébergeur en cascade après compromission de l'accès. Une mise à jour d'extension de sauvegarde qui supprime accidentellement l'historique. Ces scénarios figurent régulièrement dans les analyses post-incident des acteurs de la sécurité informatique et ne relèvent pas de la théorie.

La sauvegarde hors ligne, déconnectée du réseau et stockée sur un support physique distinct (disque dur externe au bureau, support optique, NAS personnel hors site, dépôt chez un tiers de confiance), est la dernière ligne de défense quand toutes les copies en ligne sont compromises ou inaccessibles. Cette pratique paraît old-school. Elle reste pertinente pour les sites qui portent des données dont la perte serait critique : catalogue produit complet d'un e-commerce, base clients d'un service récurrent, archives juridiques ou comptables. La cadence peut être plus espacée (mensuelle ou trimestrielle), elle compense en immutabilité ce qu'elle perd en fraîcheur. Pour une PME, deux disques durs externes en rotation gardés en lieu sûr, avec une copie alternée chaque mois, constituent un dispositif simple et robuste.

Restauration partielle quand un fragment suffit

Un incident n'oblige pas toujours à restaurer l'ensemble du site. Une commande WooCommerce supprimée par erreur, un article éditorial écrasé par une mauvaise manipulation, une option WordPress corrompue par une extension défaillante : ces cas se résolvent par restauration ciblée d'une partie de la base ou d'un fichier, sans toucher au reste. Cette capacité demande de pouvoir extraire une portion d'une sauvegarde au lieu de devoir la restaurer entièrement, ce que la plupart des solutions de sauvegarde permettent à condition de savoir manipuler les outils.

Pour une PME, le plus simple est souvent de restaurer la sauvegarde complète sur un environnement de préproduction, d'y extraire la donnée recherchée, et de la réimporter en production. La manipulation prend plus de temps qu'une vraie restauration partielle, mais elle évite la complexité technique d'une extraction directe. Avoir un environnement de préproduction utilisable rapidement, chez le même hébergeur ou en local sur un Local de Flywheel ou un DevKinsta, est un investissement préventif qui se rentabilise dès le premier incident.

Chiffrer ce qui doit l'être

Les sauvegardes contiennent par construction tout ce que le site contient, y compris les données personnelles des clients, les commandes, les coordonnées de paiement (jamais en clair pour qui respecte PCI-DSS, mais des tokens et adresses associées), les historiques de connexion, les contenus sous embargo. Une sauvegarde non chiffrée stockée sur un support qui peut être perdu, volé ou compromis constitue une violation de données potentielle au sens du RGPD et de la Loi 25. Le chiffrement au repos des sauvegardes, typiquement avec AES-256 supporté nativement par les principales solutions de sauvegarde et de stockage, ramène ce risque à un niveau acceptable, à condition que la clé de chiffrement soit conservée séparément et de manière sécurisée.

Pour les sites assujettis au RGPD ou à la Loi 25 québécoise, ce chiffrement n'est pas optionnel dès lors que les sauvegardes contiennent des données personnelles. La gestion de la clé est un sujet en soi, qui s'intègre au coffre-fort partagé évoqué plus haut et qui doit faire l'objet d'une procédure de récupération en cas de perte de l'accès principal, faute de quoi la sauvegarde chiffrée devient inutilisable au pire moment.

Les logs, accessibles et lisibles

Les logs sont la trace d'audit qui permet, en cas d'incident, de reconstituer ce qui s'est passé, par où l'attaquant est entré, ce qu'il a fait, et quels fichiers ont été ajoutés ou modifiés. Sans logs, le diagnostic se fait à l'aveugle, le nettoyage est approximatif, et la prévention de récidive devient illusoire. La maintenance préventive consiste à s'assurer que ces logs existent, qu'ils sont accessibles, et qu'ils couvrent une fenêtre temporelle suffisante.

Où sont les logs, combien de temps ils restent

Trois familles de logs concernent un site WordPress. Les logs HTTP du serveur web (Apache ou nginx) enregistrent toutes les requêtes entrantes : URL, méthode HTTP, code de réponse, adresse IP source, agent utilisateur, taille de la réponse, parfois le temps de traitement. Les logs PHP enregistrent les erreurs d'exécution, les avertissements et les notices, qui révèlent souvent l'activation d'un backdoor, l'exécution de code suspect ou des tentatives d'inclusion de fichiers distants. Les logs WordPress eux-mêmes, qui n'existent pas nativement et doivent être ajoutés par une extension dédiée comme WP Activity Log ou Activity Log de WP White Security, enregistrent les actions des utilisateurs dans l'administration : connexions et tentatives de connexion, modifications de contenu, changements d'extensions, créations de comptes, modifications de rôles.

La rétention par défaut varie considérablement selon l'hébergeur. Les offres mutualisées entrée de gamme conservent typiquement les logs Apache et PHP entre 7 et 30 jours, parfois moins, avec une rotation automatique sans archivage de long terme. Les offres infogérées et VPS conservent plus longtemps, mais la configuration reste à la charge du propriétaire pour les VPS. Pour un site critique, vérifier (et ajuster si nécessaire) la durée de rétention est une opération qui prend quelques minutes auprès du support hébergeur ou dans le fichier de configuration nginx ou Apache, et qui change tout le jour où nous cherchons à comprendre un incident survenu trois mois plus tôt. La rétention cible raisonnable est de 90 à 180 jours pour la majorité des sites.

Identifier la source d'un fichier ajouté ou modifié

Dans la plupart des compromissions, l'attaquant ajoute ou modifie des fichiers PHP dans l'arborescence du site : backdoor caché dans un dossier de plugin, ajout au wp-config.php, dépôt d'un shell web dans le dossier des médias. La capacité à identifier ces fichiers et à reconstituer leur origine est ce qui transforme un nettoyage approximatif en désinfection complète.

La méthode pratique repose sur trois croisements. D'abord, lister les fichiers PHP de l'arborescence et trier par date de dernière modification :

# Lister les fichiers PHP modifiés dans les 7 derniers jours
find /var/www/html -type f -name "*.php" -mtime -7

# Lister les fichiers ajoutés depuis une date de référence
find /var/www/html -type f -newer /var/log/reference.txt

Tout fichier modifié récemment hors d'une mise à jour légitime est suspect et mérite un examen. Ensuite, vérifier le propriétaire et les permissions de chaque fichier suspect : un fichier appartenant à www-data au lieu de l'utilisateur SSH habituel signale souvent une création par un processus PHP plutôt que par une manipulation administrateur normale. Enfin, croiser l'horodatage du fichier avec les logs HTTP du serveur pour identifier la requête qui a déclenché la création : l'URL appelée, l'adresse IP source, l'agent utilisateur livrent ensemble une piste exploitable, qui peut aussi permettre de remonter à d'autres requêtes du même attaquant et donc à d'autres fichiers ajoutés ailleurs.

Ce travail demande une compétence technique réelle et il prend du temps. C'est précisément pour cette raison qu'il vaut mieux le préparer à froid : connaître les commandes utiles, savoir où sont les logs sur l'hébergement utilisé, avoir un script d'inventaire prêt à exécuter. Découvrir ces outils en pleine crise allonge la durée d'incident et augmente le risque de manquer un élément de compromission qui se réveillera plus tard.

RTO et RPO : poser les objectifs avant de subir l'incident

RTO et RPO sont deux acronymes empruntés à la résilience IT d'entreprise. Ils méritent d'être adoptés par les PME parce qu'ils transforment des discussions floues sur la maintenance en objectifs mesurables, et qu'ils rendent défendables des arbitrages techniques qui sans eux paraissent toujours surdimensionnés ou sous-dimensionnés.

Définitions accessibles

Le RTO (Recovery Time Objective) est le temps maximum que nous acceptons de rester en panne entre le moment de l'incident et la remise en service. Pour un site vitrine corporate avec peu de trafic critique, un RTO de 24 heures peut être acceptable : le site est de retour le lendemain, l'impact est limité à une journée de visibilité perdue. Pour un site e-commerce qui fait son chiffre d'affaires en ligne, un RTO de quelques heures devient nécessaire : au-delà, la perte de commandes manquées et l'effet sur le référencement commencent à coûter cher. Pour un service en ligne dont l'indisponibilité bloque l'activité de clients en aval, nous parlons plutôt de minutes.

Le RPO (Recovery Point Objective) est la quantité maximale de données que nous acceptons de perdre entre la dernière sauvegarde utilisable et le moment de l'incident. Si la dernière sauvegarde date de 24 heures et que l'incident survient maintenant, le RPO réel est de 24 heures, et toutes les données entrées depuis sont perdues. Pour un blog éditorial, un RPO de 24 heures est généralement acceptable. Pour un e-commerce, perdre 24 heures de commandes serait inacceptable, ce qui impose un RPO de quelques minutes à quelques heures maximum.

Valeurs typiques pour une PME selon la criticité du site

Pour un site vitrine standard d'une PME ou TPE, sans transactionnel direct, des objectifs RTO de 4 à 12 heures et RPO de 24 heures couvrent la majorité des besoins réels. Cela se traduit techniquement par une sauvegarde quotidienne, une procédure de restauration documentée et déjà testée, et un accès rapide à l'hébergeur en cas de problème. Le coût de ce dispositif est modeste et accessible à toute organisation.

Pour un site e-commerce de taille moyenne, les objectifs se resserrent. Un RTO de 1 à 4 heures et un RPO de 1 à 4 heures impliquent une sauvegarde plusieurs fois par jour (toutes les 4 heures par exemple), un environnement de préproduction prêt à recevoir une restauration immédiate, et idéalement un système de réplication continue de la base de données pour limiter la perte de commandes en cours. Le coût est plus élevé mais reste proportionné à l'enjeu : pour un e-commerce qui fait quelques milliers d'euros de chiffre d'affaires par jour, une heure d'indisponibilité représente déjà plusieurs centaines d'euros perdus, sans compter l'effet sur la confiance des clients.

Pour un site critique d'une PME qui dépend totalement de sa présence en ligne, les objectifs s'approchent du temps réel. RTO de quelques minutes, RPO de quelques minutes : cela suppose une infrastructure de secours (hot standby), des sauvegardes continues, et un mécanisme de bascule automatique entre serveurs. Le coût d'une telle architecture devient significatif et doit être mis en balance avec le coût d'une heure d'indisponibilité. Pour la majorité des PME, cette configuration est surdimensionnée. Pour les exceptions, elle est indispensable.

Comment ces objectifs déterminent vraiment les choix techniques

L'intérêt de poser RTO et RPO en chiffres concrets, et pas en intentions vagues, est de rendre les arbitrages techniques évidents. Un RTO de 1 heure interdit de facto un hébergement mutualisé entrée de gamme avec support uniquement sur ticket : aucune chance de recevoir une réponse dans la fenêtre. Un RPO de 15 minutes interdit une sauvegarde quotidienne : il faut une réplication continue. Un RTO de 12 heures n'impose pas grand-chose d'autre qu'une discipline de sauvegarde et un accès à jour, donc une stack technique modeste.

Cette explicitation transforme la discussion entre l'agence et son client. Plutôt que de demander « voulez-vous une maintenance ? », nous demandons « combien de temps acceptez-vous d'être en panne, et combien de données acceptez-vous de perdre ? ». Les réponses chiffrées rendent les choix budgétaires défendables des deux côtés, parce qu'ils répondent directement à un objectif que le client a lui-même posé et qui correspond à sa réalité d'activité.

Classer ses données pour savoir ce que nous protégeons vraiment

Toutes les données d'un site web ne sont pas exposées au même risque ni soumises au même cadre réglementaire. Une politique de maintenance préventive sérieuse commence par classer ces données en quelques catégories, ce qui rend ensuite tous les arbitrages plus simples : périmètre de chiffrement, durée de rétention des sauvegardes, niveau de contrôle d'accès, périmètre des notifications en cas de violation, priorité de récupération en cas d'incident partiel.

Les données publiques correspondent au contenu éditorial du site, accessible à n'importe quel visiteur : articles de blog, pages services, fiches produits, médias publics, mentions légales. Une compromission de ces données ne génère pas en soi de risque pour des tiers, au-delà de l'atteinte à la réputation du site. Le chiffrement au repos n'est pas une nécessité absolue, la protection passe surtout par l'intégrité, c'est-à-dire empêcher la modification non autorisée.

Les données personnelles sont celles qui permettent d'identifier directement ou indirectement une personne physique : comptes utilisateurs, adresses courriel collectées sur formulaires, adresses postales, numéros de téléphone, journaux de connexion, identifiants de session, données comportementales détaillées. Ces données sont assujetties au RGPD en Europe et à la Loi 25 au Québec. Une compromission entraîne des obligations de notification dans des délais courts (72 heures pour le RGPD à compter de la découverte) et expose à des sanctions significatives. Le chiffrement au repos est fortement recommandé, et obligatoire pour certaines sous-catégories de données sensibles (santé, identifiants nationaux, données biométriques).

Les données métier sensibles correspondent aux informations dont la perte ou la divulgation impacte directement l'activité : commandes WooCommerce, devis, factures, données comptables, contenu sous embargo, informations contractuelles, base prospects qualifiés. Ces données peuvent recouper les deux catégories précédentes mais ajoutent un enjeu de continuité d'activité. Leur protection combine sauvegardes fréquentes, chiffrement au repos, contrôle d'accès strict, et journalisation des consultations.

Cette classification se documente une fois, dans un tableau de quelques lignes par catégorie, et sert ensuite de référence pour toutes les décisions de maintenance. Elle évite à la fois de surinvestir sur des données publiques peu sensibles et de sous-investir sur des données personnelles dont la perte coûterait cher en notification réglementaire et en réputation.

Le runbook d'incident, écrit à froid

Le runbook est le document opérationnel qui transforme un dispositif de maintenance préventive éclaté en plan d'action mobilisable en quelques minutes. C'est probablement la pièce la plus sous-investie de tout le dispositif, parce qu'elle paraît rébarbative à écrire et qu'elle ne sert pas en temps normal. Et c'est probablement la pièce qui fait le plus la différence le jour où elle sert.

Ce que c'est, ce que ce n'est pas

Un runbook d'incident est un document court (typiquement deux à cinq pages, pas un manuel de procédures de cinquante), partagé entre les personnes susceptibles d'intervenir, qui décrit étape par étape ce qu'il faut faire face aux scénarios d'incident probables. Il ne remplace pas la compétence technique, il libère le temps de cerveau que nous consacrerions en pleine crise à se demander « par quoi je commence ? » et à chercher les informations dont nous avons besoin.

Le runbook n'est pas un document légal ni une politique de sécurité des systèmes d'information au sens des grandes organisations. C'est un outil opérationnel, pragmatique, écrit dans un langage simple, qui doit pouvoir être suivi en pleine nuit par quelqu'un qui n'est pas en pleine forme. Il n'est pas non plus une assurance contre l'imprévu : il couvre les scénarios anticipés et donne une trame, il ne couvre pas les scénarios que personne n'a vus venir. Sa valeur n'est pas dans son exhaustivité, elle est dans son existence et dans sa mise à jour régulière.

Les sections obligatoires

Un runbook utile contient quelques blocs structurants. Le premier est la liste des contacts clés avec leurs coordonnées et leurs disponibilités réelles : hébergeur (numéro et identifiant client), agence de maintenance, développeur d'astreinte si applicable, DPO interne ou externe, autorités de notification (CNIL en France, Commission d'accès à l'information au Québec). Ces contacts doivent être à jour, ce qui suppose une revue régulière. Le deuxième est l'inventaire des accès avec les renvois vers le coffre-fort partagé. Pas les mots de passe en clair dans le runbook, mais les indications claires : « Accès SFTP : voir entrée 'Site X - SFTP' dans le coffre 1Password partagé ». Cette indirection évite à la fois la diffusion non maîtrisée des secrets et la perte de temps à chercher les bons identifiants en pleine intervention.

Le troisième bloc est la procédure de premier diagnostic : par où commencer pour qualifier l'incident, comment décider si le site doit être isolé, qui prend la décision de couper le service, quels logs consulter en priorité. Ces gestes initiaux doivent être documentés assez précisément pour que la personne d'astreinte ne perde pas de temps à improviser sous pression. Le quatrième est la procédure de restauration depuis sauvegarde : où trouver la dernière sauvegarde fiable, comment la restaurer pas à pas, sur quel environnement, avec quelle validation post-restauration. Cette procédure doit avoir été testée au moins une fois, idéalement plusieurs fois. Le cinquième est la procédure de notification réglementaire : modèle de courrier ou de formulaire prêt à signer pour la CNIL et la Commission d'accès à l'information, avec les champs à remplir au moment de l'incident (nature des données concernées, nombre de personnes affectées, mesures prises). Le délai légal est court (72 heures pour le RGPD), et avoir un modèle préparé à froid évite la rédaction sous pression dans un cadre juridique exigeant.

Exemple de runbook condensé

Pour un site WordPress PME standard, un runbook tient sur deux ou trois pages structurées sur ce modèle :

# Runbook incident : Site [nom]

## Contacts
- Hébergeur : [nom], support au [numéro], identifiant client [X]
- Agence maintenance : [nom], [téléphone direct]
- DPO : [nom], [email]
- CNIL : cnil.fr/notification | CAI Québec : cai.gouv.qc.ca

## Accès
Tous les accès dans le coffre-fort [nom], dossier "[nom site]" :
- SFTP, SSH, BDD, panneau hébergeur, WP admin
- Codes 2FA dans entrée dédiée

## Si le site est en panne (page blanche, erreur 500)
1. Vérifier statut hébergeur sur [URL page statut]
2. Si panne hébergeur : informer le client, surveiller à intervalles
3. Si panne site : consulter logs PHP via panneau hébergeur
4. Si erreur claire : corriger en SFTP
5. Sinon : restaurer dernière sauvegarde

## Si suspicion de compromission
1. Mettre le site en mode maintenance
2. Télécharger wp-config.php, vérifier injections
3. Lister fichiers PHP récents : find . -name "*.php" -mtime -7
4. Vérifier comptes administrateurs dans BDD (table wp_users)
5. Si compromission confirmée : suivre procédure nettoyage
6. Si données personnelles exfiltrées : déclencher notification

## Restauration depuis sauvegarde
1. Identifier dernière sauvegarde antérieure à l'incident
2. Restaurer sur préproduction d'abord
3. Valider : accueil, page produit, commande, formulaire contact
4. Si OK : basculer vers production
5. Régénérer secrets WordPress (salt keys, mots de passe admin et BDD)
6. Surveiller les heures suivantes

## Post-incident
1. Rédiger compte-rendu sous 48h (timeline, cause racine, actions)
2. Mettre à jour ce runbook si lacune identifiée
3. Traiter la cause racine, pas seulement le symptôme

Ce niveau de détail tient sur deux à trois pages bien formatées. La valeur n'est pas dans l'exhaustivité mais dans le fait que le document existe, qu'il est à jour, et qu'il est consulté en pleine crise plutôt que reconstruit à la volée. Pour les sites avec des scénarios spécifiques (e-commerce avec passerelle de paiement, intégrations tierces critiques, applications métier), des sections additionnelles couvrent ces cas particuliers sans alourdir le runbook général.

Revue annuelle, sinon il pourrit

Un runbook qui n'est pas tenu à jour devient toxique : il oriente vers des contacts qui ont changé, suggère des outils qui n'existent plus, propose des procédures obsolètes. La règle pratique est une revue annuelle minimum, avec mise à jour systématique à chaque changement structurant (changement d'hébergeur, refonte technique majeure, changement de prestataire ou de personne en astreinte, évolution réglementaire). Cette revue prend une heure, elle se programme comme une tâche récurrente dans l'outil de gestion de l'équipe, et elle garde le runbook utile dans la durée. Un runbook non maintenu finit par être pire que pas de runbook du tout, parce qu'il donne une fausse impression de préparation à l'équipe qui s'appuie dessus.

La boucle d'amélioration post-incident

Chaque incident est une opportunité de réduire la probabilité ou l'impact du suivant. Cette opportunité se perd presque toujours, parce qu'une fois la crise passée, l'attention bascule sur autre chose et le post-mortem n'est jamais écrit. La discipline qui transforme un incident en apprentissage tient en trois étapes simples mais rigoureuses.

La première est le compte-rendu écrit, idéalement dans les 48 heures qui suivent le retour à la normale. Il documente la timeline de l'incident (quand l'avons-nous découvert, qu'avons-nous fait, dans quel ordre), la cause racine (pas le symptôme, la cause qui a permis au symptôme d'arriver), les conséquences (durée d'indisponibilité, perte de données, notification réglementaire effectuée ou non), et les actions correctives décidées avec leur calendrier. Ce document n'a pas vocation à dépasser deux pages. Il est partagé avec les personnes qui ont participé à la résolution et avec celles qui auront à intervenir sur des incidents similaires à l'avenir.

La deuxième étape est la mise à jour du runbook et des procédures à partir des leçons tirées. Si l'incident a révélé qu'un accès était périmé, qu'une sauvegarde n'avait pas tourné, qu'un contact hébergeur avait changé, le runbook est mis à jour immédiatement, pas plus tard. Si une étape de diagnostic a manqué pour traiter ce type d'incident, elle est ajoutée. Cette mise à jour systématique transforme un incident isolé en amélioration permanente du dispositif, et c'est elle qui justifie tout l'effort de tenue du runbook entre les incidents.

La troisième étape est l'action sur la cause racine, qui ne se confond pas avec la remise en service. Si l'incident vient d'une extension compromise, le post-mortem doit interroger pourquoi cette extension était installée, pourquoi son éditeur n'avait pas été vérifié au moment du choix initial, pourquoi le mécanisme de veille n'avait pas alerté à temps quand la vulnérabilité a été divulguée. Traiter le symptôme sans traiter la cause garantit la récurrence. Cette discipline est ce qui sépare une équipe qui subit les incidents successifs d'une équipe dont le dispositif s'améliore après chaque crise et qui finit par voir la fréquence et la gravité des incidents diminuer dans la durée.

Maintenance interne ou déléguée : deux trajectoires viables, une à éviter

Tenir l'ensemble des disciplines décrites dans cet article suppose un investissement réel en temps et en compétence. Pour une PME propriétaire d'un site WordPress, deux trajectoires sont défendables, et une troisième est l'option qui coûte le plus cher à long terme.

La première trajectoire est la maintenance interne. Elle suppose qu'au moins une personne dans l'organisation a la compétence technique et le temps dédié pour tenir le rituel : audit trimestriel des extensions, revue mensuelle des sauvegardes, mise à jour annuelle du runbook, veille hebdomadaire sur les vulnérabilités. Cette personne doit avoir les accès, connaître l'hébergeur, savoir restaurer une sauvegarde, et pouvoir basculer en mode urgence sans préavis. Pour une organisation qui a déjà un profil technique en interne (responsable IT, développeur en poste, prestataire technique récurrent dédié), cette option est viable et donne un contrôle total sur la maintenance et sur les arbitrages techniques.

La seconde trajectoire est la délégation à une agence ou à un prestataire spécialisé, dans le cadre d'un contrat de maintenance qui couvre explicitement les disciplines décrites ici. Le contrat doit préciser ce qui est inclus (mises à jour, sauvegardes indépendantes, surveillance, intervention sur incident, audits réguliers, mise à jour du runbook) et à quels niveaux de service (délai de réponse, délai d'intervention, périmètre de la garantie). Cette option transfère la charge opérationnelle à un acteur compétent, à condition que le contrat couvre vraiment la maintenance préventive et pas seulement la maintenance corrective (intervention quand quelque chose casse, sans préparation amont). Beaucoup de contrats facturés comme « maintenance » se réduisent en pratique à la maintenance corrective, ce qui revient à payer une assurance pompiers sans payer l'extincteur.

La troisième voie, qui mérite d'être nommée pour que nous l'évitions consciemment, est l'option « on s'en occupe quand on y pense ». Pas de rituel régulier, pas de runbook, pas de test de restauration, pas de veille active. Les mises à jour se font quand quelqu'un y pense (souvent trop tard), les sauvegardes existent peut-être mais n'ont jamais été testées, l'hébergeur est un fournisseur abstrait dont nous n'avons jamais utilisé le support. Cette option paraît la moins coûteuse au quotidien, parce qu'elle ne facture rien. Elle se révèle systématiquement la plus coûteuse au premier incident sérieux, où la durée de remédiation se compte en jours ou en semaines, avec pertes de chiffre d'affaires, retard de notification réglementaire, et reconstruction d'autorité SEO à la clé.

Chez MtoM Création, nous proposons des contrats de maintenance qui couvrent l'ensemble des disciplines décrites dans cet article, pour les sites WordPress que nous mettons en production comme pour ceux que nous reprenons. Cette posture s'inscrit dans la continuité de nos articles précédents sur la sécurité préventive et sur la gestion des attaques d'avril 2026 : la maintenance ne se découpe pas en moments isolés, elle se tient dans la durée et c'est cette durée qui en fait le rapport coût-risque.

Préparer ce que la crise révèlera

L'image qui ressort des incidents successifs qu'a connus l'écosystème WordPress ces dernières années, et particulièrement de la double attaque d'avril 2026 contre Essential Plugin et Smart Slider 3 Pro, est celle d'une asymétrie qui se joue très en amont. Deux sites face à la même menace ne réagissent pas pareil. L'un redémarre propre en quelques heures, l'autre passe plusieurs jours à plusieurs semaines en chantier. La différence ne se mesure pas pendant l'attaque, elle se joue dans tout ce qui a été préparé ou négligé pendant les mois et les années qui ont précédé.

La maintenance préventive est ce qui détermine de quel côté nous tombons. Elle ne se résume pas aux mises à jour mensuelles d'extensions, et elle ne se découpe pas en gestes ponctuels que nous enchaînons quand nous y pensons. Elle suppose une discipline tenue dans la durée, avec un coût récurrent modeste comparé à celui d'un incident mal géré. Pour une PME propriétaire d'un site qui compte pour son activité, cette discipline n'est pas un luxe d'organisation mature : c'est l'investissement minimal qui rend l'incident gérable plutôt que catastrophique. Cette logique vaut quel que soit le CMS ou la stack technique sur laquelle le site repose : WordPress concentre les exemples récents les mieux documentés, mais Shopify, Drupal, Magento, les applications Laravel ou Symfony, les sites JavaScript et les développements sur mesure relèvent tous de la même discipline. Les outils, les pratiques et les méthodes existent, ils sont documentés, ils sont éprouvés. Il reste à les adopter, à les tenir, et à les améliorer après chaque épreuve.