Les 5 choses que je vérifie quand un site WordPress atterrit sur mon bureau

Le mois dernier, un site m’est arrivé avec 47 mises à jour de plugins en attente et plus aucune sauvegarde depuis 2024. Son propriétaire m’a appelé à 23 h : son formulaire de contact ne collectait plus rien, et il ignorait depuis quand. Ça, c’était le problème facile. Le plus difficile, c’était de lui expliquer que si quoi que ce soit avait mal tourné dans les dix minutes suivantes, restaurer son site, ça revenait à le reconstruire à partir de captures d’écran.

Cet appel n’a rien d’inhabituel : à peu près un site sur quatre m’arrive dans cet état. Le propriétaire est quelqu’un de sérieux, qui fait vivre une vraie boîte, et son site s’est dégradé sans bruit, au point qu’une mise à jour malheureuse, un plugin qui n’est plus maintenu ou un banal script de force brute suffirait à créer un problème qu’il ne saurait plus résoudre seul.

Voici donc la checklist d’audit WordPress que j’applique quand un site atterrit sur mon bureau. Cinq vérifications, dans l’ordre, avant tout le reste. Ni douze ni quinze : cinq. Si la liste est courte, c’est délibéré : ces cinq-là décident si le site est récupérable. Tout le reste peut attendre que les problèmes détectés soient réglés.

La seconde moitié de chaque section explique comment faire la vérification vous-même. Et si vous préférez confier ça à quelqu’un tous les mois pour ne plus y penser, c’est précisément ce que couvre notre offre de maintenance WordPress, bâtie autour de cette liste.

1. L’état des sauvegardes (celle qui passe avant toutes les autres)

Je commence toujours là, parce que rien d’autre ne peut être touché sans risque si la réponse est mauvaise.

Trois questions :

1. Y a-t-il des sauvegardes automatiques, quotidiennes et hebdomadaires ?
2. Où sont-elles stockées, sur le serveur du site ou ailleurs ?
3. Quand la dernière a-t-elle été vérifiée, autrement dit quand quelqu’un a-t-il vérifié qu’elle se restaure vraiment ?

Un site sans sauvegarde, sans copie externalisée, ou avec une sauvegarde jamais testée, je n’y touche pas tant que ce n’est pas réglé. La raison tient en une ligne : chacune des étapes suivantes (mises à jour, installation d’un plugin de sécurité, montée de version PHP) comporte un petit risque de casser quelque chose. Sans sauvegarde qui fonctionne, ce petit risque de casser quelque chose devient un petit risque de perdre le site.

Beaucoup de propriétaires se croient couverts parce que leur hébergeur promet, quelque part sur une page produit, une sauvegarde toutes les nuits. Ces sauvegardes existent bel et bien, mais elles peuvent lâcher précisément dans les cas où on en a le plus besoin : quand le compte d’hébergement lui-même est compromis, et quand il faut remonter plus loin que la rétention de l’hébergeur, souvent 7 à 14 jours, soit bien moins que ce que les gens imaginent.

Pour le corriger vous-même : installez un plugin de sauvegarde automatique, programmez une sauvegarde quotidienne de la base et une sauvegarde complète hebdomadaire, et envoyez les copies vers un stockage externe que vous contrôlez, jamais le serveur du site. Ne vous contentez pas des deux dernières : gardez un jeu tournant de copies quotidiennes, hebdomadaires et mensuelles, pour qu’un problème passé inaperçu pendant des semaines ait encore un point sain où revenir. Puis, une fois, restaurez-en une sur un site de test pour vérifier qu’elle fonctionne vraiment. C’est cet exercice de restauration que personne ne fait jamais.

Le raccourci : la vérification mensuelle des sauvegardes et les contrôles avant chaque mise à jour sont compris dans notre forfait de maintenance Essential, avec les sauvegardes quotidiennes et hebdomadaires qu’on surveille pour vous.

2. L’hygiène des mises à jour

Une fois la question des sauvegardes réglée, je passe à la liste des plugins. Pas encore pour mettre quoi que ce soit à jour : juste pour compter.

Ce que je compte :

• Combien de plugins sont en retard d’une version ?
• Combien sont signalés pour une faille de sécurité connue ?
• À quand remonte le dernier créneau de mises à jour sur ce site ?

Le site aux 47 mises à jour dont je parlais en ouverture était un cas extrême, pas un cas rare. Le cas courant, c’est six à quinze mises à jour accumulées sur plusieurs mois, parce que le propriétaire n’ose plus cliquer sur le bouton. Et il a raison de ne plus oser : il s’est déjà fait avoir une fois. C’est exactement le sujet de l’article sur comment mettre à jour ses plugins sans tout casser.

Environ 60 % des sites WordPress compromis que j’ai audités l’ont été par un plugin en retard, sur une faille publiée. La faille est connue, le correctif est disponible, le site ne l’a jamais installé, et un script automatisé balaie internet à la recherche des versions restées vulnérables. Cet intervalle entre la sortie du correctif et son application, c’est le moment où le site est le plus exposé.

Pour le corriger vous-même : fixez un créneau mensuel. Avant ce créneau, faites une sauvegarde du jour et vérifiez-la. Pendant le créneau, mettez à jour par petits lots plutôt que tout d’un coup, et rechargez la page d’accueil, le formulaire de contact et vos pages critiques après chaque lot. Si quelque chose lâche, vous savez quel lot en est responsable. Le cœur de WordPress passe après les plugins, jamais avant. Et vous recommencez tous les mois, à la même date, sans exception.

3. Le socle de sécurité

Je regarde ensuite ce qui défend le site entre deux créneaux de maintenance.

Ce que je vérifie :

• Le plugin de sécurité est-il installé et réellement actif ? (Installé et actif, ce n’est pas la même chose. J’ai déjà vu des plugins désactivés pour régler un souci de performance, et jamais rallumés depuis.)
• À quand remonte le dernier scan anti-malware, et qu’a-t-il trouvé ?
• Les comptes administrateurs ont-ils des mots de passe solides et la double authentification ?
• Quelqu’un se connecte-t-il encore avec l’identifiant « admin » ?

À lui seul, l’identifiant « admin » vaut diagnostic : tous les scripts de force brute l’essaient en premier. Si votre page de connexion répond sur /wp-login.php, l’adresse par défaut, un compte « admin » avec un mot de passe faible se fait attaquer plusieurs fois par heure par des robots qui ne cherchent que ça.

Un plugin de sécurité ne sauvera pas un site dont le mot de passe administrateur est le prénom du propriétaire suivi de son année de naissance. En revanche, il absorbe le bruit de fond de la force brute, et le site cesse d’être une cible facile. La nuance compte, parce que la plupart des sites piratés n’étaient pas visés : c’était juste la seule porte restée ouverte dans la rue que remontait le cambrioleur.

Pour le corriger vous-même : installez un plugin de sécurité reconnu, activez son pare-feu et sa protection contre la force brute, et lancez un scan complet qui servira de point de repère. Renommez ou supprimez tout compte qui s’appelle « admin ». Imposez des mots de passe solides à chaque administrateur, et activez la double authentification, au moins sur ces comptes-là. L’essentiel de tout ça est gratuit ; ça coûte surtout un après-midi.

4. Le retard de versions (le cœur et PHP, pas seulement les plugins)

Les plugins captent presque toute l’attention, alors que deux briques tournent en arrière-plan et pèsent tout autant. Elles traînent souvent des années de retard.

Trois questions :

• Le cœur de WordPress est-il sur la version majeure en cours ?
• La version de PHP chez l’hébergeur reçoit-elle encore des correctifs de sécurité du projet PHP ?
• Combien de plugins ont été abandonnés par leur auteur depuis plus d’un an ?

PHP est celui que personne ne regarde jamais, faute d’un endroit sur le tableau de bord qui le signale. Or les versions de PHP arrivent en fin de vie selon un calendrier public, et à partir de là elles ne reçoivent plus de correctifs de sécurité. Un site resté sur une version obsolète tiendra jusqu’à la prochaine migration de son hébergeur, et il y en aura une : ce jour-là, les plugins qui fonctionnaient la veille cesseront de fonctionner. Le premier signe n’est d’ailleurs presque jamais un message d’avertissement, mais un écran blanc, une erreur 500 à la place de la page d’accueil.

Les plugins abandonnés sont la version silencieuse du même problème. Quand une extension n’a plus rien reçu depuis 18 mois, prenez-le comme une question, pas comme un verdict : regardez son forum de support, si elle se déclare encore compatible avec la version actuelle de WordPress, et si une faille a été signalée. Parfois c’est un petit outil fini qui n’a vraiment besoin de rien. Souvent son auteur est passé à autre chose, et toute faille découverte ensuite ne sera jamais corrigée. L’extension tourne encore, le site tourne encore, et la porte reste ouverte.

Pour le corriger vous-même : la version de WordPress se lit sur le tableau de bord, celle de PHP dans le panneau de votre hébergeur : il l’affiche forcément quelque part, et sinon son support vous la donnera. Pour chaque plugin, regardez la date de dernière mise à jour sur sa fiche WordPress.org : au-delà de 12 mois, c’est un candidat au remplacement. Quant à la montée de version PHP, préparez-la sérieusement, parce que certains plugins ou thèmes peuvent devenir incompatibles, mais préparez-la : mieux vaut la choisir que se la faire imposer par l’hébergeur.

5. La préparation à la reprise (le test de la panique)

C’est l’étape que presque personne ne fait, et celle qui décide de ce que vous coûtera le jour où tout lâchera.

Imaginez le site en panne, là, maintenant. Pas lent : en panne. Piratage, incident chez l’hébergeur ou mise à jour ratée, peu importe. Répondez à ceci :

• Avez-vous accès au panneau d’hébergement ? Identifiant, mot de passe, adresse qui répond.
• Avez-vous accès au panneau DNS ? Parfois c’est le même compte que l’hébergement, souvent non.
• Avez-vous accès à l’administration WordPress ? Même quand le site est à terre, cette adresse-là répond parfois encore.
• Avez-vous un fichier de sauvegarde récent que vous pouvez transmettre à quelqu’un, ou envoyer vous-même, dans les cinq minutes qui viennent ?
• S’il fallait qu’un développeur restaure le site, combien de temps vous faudrait-il pour lui fournir tout ce dont il a besoin ?

La plupart des propriétaires découvrent leurs réponses en pleine panique, c’est-à-dire au pire moment possible. Le mot de passe d’hébergement dort dans un mail vieux de quatre ans, le compte DNS est au nom d’un ancien freelance, la sauvegarde est sur un disque dur resté au bureau, et le développeur patiente pendant que vous cherchez, site toujours à terre.

La parade n’a rien de spectaculaire : un document qui liste chaque accès et chaque lien dont un développeur aurait besoin ce jour-là, rangé dans un gestionnaire de mots de passe dont vous vous servez vraiment. Faites l’exercice de restauration une fois pendant que tout va bien, pour avoir le réflexe le jour où plus rien ne va.

Pour le corriger vous-même : ouvrez un gestionnaire de mots de passe aujourd’hui, et créez les entrées pour l’hébergement, le DNS, l’administration WordPress, le FTP ou SSH, la messagerie du domaine et le CDN si vous en avez un. Testez chaque accès en vous connectant pour de bon. Une fois par an, simulez une reprise complète : prenez la dernière sauvegarde et restaurez-la sur un environnement de test neuf. Si vous y arrivez en moins d’une heure, vous êtes prêt.

Le raccourci : notre forfait Pro comprend une restauration d’urgence prioritaire sous 4 heures. Les accès, eux, restent chez vous : sans eux, on ne sait même pas vers quoi restaurer. Mais une restauration, ça ne s’improvise pas un vendredi à 21 h.

Ce que je fais après les cinq vérifications

Si les cinq points passent, le site est en bon état et le travail qui suit relève de la performance, du SEO, de l’accessibilité, tout ce qui améliore un site déjà sécurisé. Si un seul échoue, c’est là que le travail commence, et rien d’autre n’avance tant qu’il n’est pas réglé. Dans cet ordre, jamais l’inverse.

Parfois les cinq échouent parce que personne n’en a jamais eu la charge : c’est un problème de maintenance, et les plans mensuels existent pour ça. Parfois ils échouent parce que celui qui a construit le site a bâclé le travail. La réponse est alors tout autre : le guide pour choisir un sous-traitant web reprend les questions à poser avant de confier le site au suivant. Et si vous lisez ceci pour le compte d’un client plutôt que pour votre propre activité, c’est exactement la logique de notre sous-traitance en marque blanche pour agences : les vérifications ont lieu, que le client final en entende parler ou non. Vous pouvez juger le résultat dans nos réalisations.

Dans tous les cas, l’essentiel est que l’audit ait lieu. Le site qui atterrit sur mon bureau à 23 h, c’est toujours celui dont l’audit a été repoussé.

FAQ

À quelle fréquence faut-il auditer son site WordPress ?

Une fois par mois pour les cinq vérifications de cet article, et une fois par trimestre pour le travail de fond : performance, SEO, accessibilité. Les plantages que je constate touchent presque toujours des sites qui n’ont rien vu passer depuis six à douze mois.

Peut-on faire soi-même un audit WordPress ?

Oui. L’ensemble des cinq vérifications peut être réalisé en un après-midi, par quelqu’un qui n’est pas technicien, avec les bons plugins et un gestionnaire de mots de passe. Le difficile, c’est de recommencer tous les mois pendant des années. Cette régularité-là, c’est ce que la plupart des propriétaires finissent par externaliser.

Combien de temps prend un audit WordPress ?

Comptez deux heures la première fois, surtout parce que vous chercherez des choses que vous n’avez jamais regardées. Ensuite, ça devient une habitude mensuelle de 20 à 30 minutes.

Quelle est l’erreur d’audit la plus fréquente ?

L’absence de sauvegarde vérifiée, très loin devant. Les gens se croient couverts parce que l’hébergeur l’a dit, jusqu’au jour où il faut vraiment restaurer. Vient ensuite le retard de plusieurs années sur les mises à jour de plugins, qui reste la porte d’entrée de la plupart des piratages.

Un plugin de sécurité est-il utile si on a déjà un mot de passe solide ?

Oui, mais aucun des deux ne remplace la mise à jour. Un mot de passe solide protège votre page de connexion contre la force brute. Un plugin de sécurité, avec un pare-feu bien réglé, peut aussi limiter certaines attaques qui contournent cette page, comme les tentatives contre une extension non corrigée, sans pour autant refermer la faille de façon fiable : seule la mise à jour de l’extension le fait. Les deux vous font gagner du temps et couvrent des angles différents, mais le correctif reste la vraie parade.

Un audit peut-il empêcher un piratage ?

Aucun audit ne garantit qu’un site ne sera jamais piraté. En revanche, celui-ci ferme les quatre portes d’entrée que je retrouve le plus souvent sur les sites compromis : plugins en retard, plugins abandonnés, identifiants administrateur faibles, et une page de connexion exposée sans pare-feu devant. Fermer ces quatre-là, c’est fermer celles qu’empruntent la plupart des attaquants.

Que faire si mon site est déjà cassé ?

Arrêtez d’y toucher. Le premier réflexe est de sauvegarder l’état actuel, même cassé, parce que cette version-là contient les traces de ce qui s’est passé. Restaurez ensuite la dernière sauvegarde saine sur un environnement de test, surtout pas sur le site en ligne. Et si ce site cassé, c’est votre activité, le moment est venu de passer la main à quelqu’un dont c’est le métier, pas d’apprendre le sien dans l’urgence.

Une question sur cet article ? Réponse par e-mail, en privé. Rien n'est publié sur le site. +