Quand un site se fait pirater, le réflexe est d'accuser le CMS. « WordPress n'est pas sûr. » « PrestaShop est une passoire. » C'est presque toujours faux, et surtout, ça désigne la mauvaise cible.
Le cœur de ces deux logiciels est maintenu par des équipes qui publient des correctifs de sécurité rapidement et publiquement. Ce n'est pas là que ça cède. Ça cède dans les modules — les extensions, les thèmes, les greffons que l'on ajoute autour pour obtenir les fonctions dont on a besoin.
Un site n'est pas un logiciel, c'est quarante
Une boutique PrestaShop en production tourne rarement avec les modules d'origine. Elle en a un pour le transporteur, un pour la relance de panier, un pour les avis clients, un pour l'export comptable, un pour le flux Google Shopping, un pour la bannière de cookies. Un site WordPress d'entreprise n'est pas différent : formulaires, cache, SEO, galerie, réservation.
Chacun de ces modules est un logiciel à part entière, écrit par quelqu'un d'autre, avec son propre rythme de publication, sa propre qualité de code et sa propre espérance de vie. Un site qui en compte quarante ne dépend pas d'un éditeur, mais de quarante et un.
C'est cette arithmétique que l'on oublie au moment de cliquer sur « installer ». Chaque fonction ajoutée en trois minutes crée une dépendance à suivre pendant des années.
Le module abandonné est une porte qui ne se referme jamais
Le vrai danger n'est pas le module vulnérable : c'est le module abandonné.
Un module maintenu qui présente une faille reçoit un correctif. Vous mettez à jour, l'affaire est close. Un module dont l'auteur a cessé de publier — parce qu'il a changé de métier, revendu son activité ou simplement arrêté — conserve sa faille indéfiniment. Il continue de fonctionner parfaitement, ce qui est précisément le problème : rien, dans l'usage quotidien, ne signale qu'il n'est plus suivi.
Les signaux existent, mais ils sont passifs. Une mention « non testé avec les dernières versions » dans un annuaire d'extensions, une page d'éditeur qui ne répond plus. Personne ne reçoit d'alerte. Il faut aller regarder.
Cas particulier, fréquent sur PrestaShop : les modules payants installés hors circuit officiel. Outre le fait qu'ils ne recevront jamais de mise à jour, ils arrivent régulièrement avec du code ajouté par celui qui les a redistribués. On installe alors la porte d'entrée soi-même, en même temps que la fonction.
Vous n'êtes pas visé, vous êtes énuméré
L'autre malentendu tenace : « mon site est trop petit pour intéresser quelqu'un ».
Une faille de module n'est pas exploitée par quelqu'un qui vous en veut. Dès qu'elle est publiée — et elle est publiée, c'est le principe d'une divulgation responsable — des robots balaient le web à la recherche de toutes les installations qui la présentent. Ils ne choisissent pas leurs cibles, ils les énumèrent. Le délai entre la publication d'une faille et le début du balayage automatisé se compte en jours, parfois en heures.
Votre taille n'entre pas dans l'équation. Votre version de module, si.
Ce que ça donne quand ça arrive
Une compromission par module se voit rarement. Le site reste debout, les commandes passent, rien ne clignote. C'est ce qui la rend coûteuse : elle travaille pendant des mois avant qu'on la remarque.
Les manifestations les plus courantes sont indirectes. Des milliers d'URL parasites apparaissent dans l'index de Google, souvent sur des thématiques sans aucun rapport avec l'activité. Des redirections se déclenchent uniquement pour les visiteurs venant d'un moteur de recherche, ou uniquement sur mobile — jamais quand le propriétaire teste son propre site. Des tâches planifiées apparaissent. Des fichiers se déposent dans les répertoires d'envoi.
Et le dégât le plus durable est un dégât de référencement. Le temps que Google consacre à explorer un site n'est pas extensible : s'il le dépense sur des pages parasites, il ne le dépense pas sur les fiches produit. Sur la boutique dont j'ai raconté le sauvetage cet été, un module d'import défaillant fabriquait à lui seul plusieurs milliers d'adresses invalides — 4 533 erreurs, sur un site dont les vraies pages attendaient d'être vues.
La remise en état, elle, est bien plus lourde que la mise à jour qui l'aurait évitée. Il faut identifier le point d'entrée, nettoyer sans casser, vérifier qu'aucun accès résiduel ne subsiste, puis demander à Google de réexaminer un site qu'il a parfois déjà déclassé. C'est ce qui est arrivé à l'association 4 Pattes Sans Toit, dont le site a dû être entièrement reconstruit.
Le piège de la mise à jour impossible
Reste la difficulté que rencontrent tous les commerçants, et qui explique beaucoup d'installations figées.
Sur PrestaShop, passer d'une 1.7 à une version majeure récente suppose que tous les modules suivent. Il suffit qu'un seul module payant, essentiel au métier, n'ait jamais été porté pour que la migration se bloque. La boutique reste alors sur une version dont le support s'éteint, non par négligence, mais parce qu'un maillon manque.
Sur WordPress, le cœur applique seul ses correctifs de sécurité depuis des années. Les extensions, non : leur mise à jour automatique existe mais se règle extension par extension, et reste désactivée par défaut. Le noyau se protège tout seul, ce qui est rassurant — et trompeur, puisque ce n'est pas lui qui est visé.
Dans les deux cas, le blocage est réel. Il ne se résout pas en ignorant le problème, mais en le traitant comme une décision : remplacer le module, le faire porter, ou assumer un risque qu'on a au moins nommé.
La maintenance n'est pas « tout mettre à jour »
Cliquer sur « mettre à jour » sans filet est une façon rapide de casser une boutique en production. La maintenance sérieuse est plus ennuyeuse, et tient en quelques habitudes.
Savoir ce qui est installé. Un inventaire des modules, avec leur version, leur éditeur et la date de leur dernière publication. La plupart des sites que je reprends n'en ont aucun.
Supprimer ce qui ne sert pas. Un module désactivé reste du code présent sur le serveur, et souvent atteignable. Le meilleur module est celui qu'on a désinstallé.
Tester avant de publier. Une copie du site où l'on applique les mises à jour avant de les passer en production. C'est ce qui transforme une mise à jour risquée en opération routinière.
Avoir des sauvegardes qu'on a déjà restaurées. Une sauvegarde jamais testée n'est pas une sauvegarde, c'est une intention.
Lire les journaux de temps en temps. Les erreurs 404 en masse, les requêtes qui n'ont rien à faire là, la charge qui ne retombe pas la nuit : les signaux sont dans les journaux d'accès bien avant d'être visibles à l'écran.
Un site qui n'a pas été touché depuis deux ans
Ce n'est pas un site stable, c'est un site dont la dette s'accumule en silence. Si vous ne savez pas quand vos modules ont été mis à jour pour la dernière fois, ni combien vous en avez, c'est déjà une réponse.
Un état des lieux se fait par l'inventaire et par les journaux, pas par supposition — et il vaut toujours mieux le faire avant l'incident qu'après.