7 min de lecture
Ce qui casse vraiment quand on ne maintient pas son WordPress pendant un an
Quand on me confie un site WordPress qui n'a pas vu de mise à jour depuis un an ou deux, je sais à peu près ce que je vais trouver. Pas par paranoïa, juste par habitude. Voilà les pannes qui reviennent le plus souvent, et ce que ça coûte de remettre tout ça en route quand ça finit par lâcher pour de bon.
Petit repère avant d'attaquer : pour un site vitrine ou une petite boutique, un contrat de TMA correct tourne entre 30 et 150 € par mois, soit 400 à 1 800 € par an selon le périmètre. Gardez ce chiffre en tête, c'est l'unité de mesure qui sert dans les comparaisons ci-dessous.
Une version de PHP qui finit par bloquer le e-commerce
Celui-là, je l'ai vraiment vécu, et franchement c'est le plus douloureux côté client. Un site WooCommerce tournait depuis plusieurs années sur une version de PHP devenue ancienne. Tant que rien ne bouge, tant qu'on ne touche à rien, ça tient. Les commandes passent, l'admin répond, tout va bien.
Et puis un jour, l'hébergeur (OVH) décide que cette version pose un vrai problème de sécurité. D'abord des avertissements polis dans le panneau de gestion. Puis des restrictions. Une partie des requêtes commence à se faire bloquer, certaines pages renvoient des 500 erratiques. L'admin WordPress devient instable. L'update du cœur depuis l'interface ne passe plus. Et finalement, le module de paiement Stripe lâche, parce que la dernière version de la librairie réclame un PHP plus récent que celui qui tourne. Boutique HS, le temps qu'on diagnostique, qu'on monte un environnement de test, qu'on bascule la version PHP côté hébergeur en croisant les doigts pour que rien d'autre ne s'écroule, qu'on mette à jour ce qui doit l'être, qu'on revérifie les passerelles de paiement.
Une intervention d'urgence comme celle-là, en comptant tout, ça pèse facilement plusieurs mois de TMA d'un coup. Et encore, c'est sans le manque à gagner pendant que la boutique ne prend plus de commandes.
Une faille XSS sur un plugin laissé à l'abandon
Sur ce sujet, je n'ai pas vécu personnellement de gros incident, mais c'est tellement fréquent que je préfère en parler quand même. Les rapports Patchstack le rappellent chaque année : la quasi-totalité des vulnérabilités attribuées à WordPress concernent des plugins ou des thèmes tiers, pas le cœur logiciel. Et le Cross-Site Scripting (XSS) reste largement en tête des typologies les plus exploitées.
Le scénario type : un plugin est abandonné par son auteur (plus de mise à jour depuis 18 mois ou davantage), une faille publique est découverte, et dans les semaines qui suivent les bots scannent l'intégralité du web à la recherche des sites qui ont encore le plugin actif. Quand le vôtre fait partie du lot, vous le découvrez rarement par votre propre vigilance. Plutôt par un avertissement Google « ce site peut être dangereux », par des redirections bizarres vers des domaines russes ou par une homepage défoncée un matin.
Le nettoyage post-piratage est rarement rapide. Identifier la porte d'entrée, retirer les fichiers et les lignes injectées, vérifier qu'il ne reste rien dans la base, repartir si nécessaire d'une sauvegarde propre, demander la levée du flag Google, refaire toutes les clés de sécurité, changer les mots de passe admin. En coût, on est facilement sur un à deux ans de TMA. Toujours d'un coup.
Un compte admin nommé « admin » avec un mot de passe à six caractères
Le grand classique des sites repris. Un compte administrateur dont l'identifiant est admin (ou contact, ou le prénom du gérant), et un mot de passe choisi par quelqu'un qui devait juste « avoir un truc dont il se souviendrait ». Combinés, ces deux choix ouvrent une porte que les bots cherchent en permanence. Tester admin en login sur un WordPress, c'est leur premier réflexe, on parle d'un script qui tourne automatiquement sur des millions d'IP.
Pour donner une idée, si vous faites passer un mot de passe à l'estimateur de Bitwarden, voilà ce que ça donne. azerty123 tient zéro seconde face à une attaque automatisée. Muso2020!, qui semble pourtant « sécurisé » avec sa majuscule, son chiffre et son point d'exclamation, tombe en quelques minutes parce qu'il combine un mot probable et une année récente. Un mot de passe vraiment résistant ressemble plutôt à k7$Pm-9zL!qvW2 ou à une passphrase longue type cheval-orange-poele-kamoulox-42. Personne ne tape ça à la main, c'est précisément à ça que servent les gestionnaires de mots de passe.
Sur un site sans TMA, ces choses ne se voient pas tant qu'il ne se passe rien. Et puis un jour, quelqu'un finit par deviner le couple admin + mot de passe faible, et là c'est le pire scénario possible. Avec un accès administrateur, le pirate peut littéralement tout faire : modifier le code du thème ou des plugins, créer des nouveaux comptes invisibles, injecter du contenu caché, planter une ou plusieurs backdoors un peu partout. Le simple nettoyage post-piratage évoqué pour la faille XSS ne suffit plus, parce qu'on ne peut plus garantir qu'on a tout retiré. La seule réponse propre, c'est la restauration complète du site depuis une sauvegarde antérieure à l'intrusion (à condition d'en avoir une qu'on sait saine), suivie d'une remise à plat des accès, des clés et des identifiants. En coût, on est déjà sur l'équivalent d'années de TMA, sans parler du contenu publié entre la sauvegarde et l'incident, qu'il faut souvent ressaisir à la main.
Une bonne TMA évite tout ça à l'amont. Audit annuel des comptes utilisateurs, renommage des comptes admin évidents, mots de passe corrects, double authentification quand l'enjeu le justifie, et surtout sauvegardes versionnées qui permettent de revenir à un état propre si le pire arrive quand même.
Une base de données qui gonfle en silence
Moins spectaculaire que les deux premiers, mais beaucoup plus fréquent. La table wp_options accumule des transients jamais purgés, des réglages de plugins désinstallés depuis longtemps, des entrées laissées par d'anciens thèmes. Sur un site qui tourne depuis trois ou quatre ans sans nettoyage, j'ai déjà vu des wp_options à plusieurs dizaines de méga-octets. Or cette table est lue à chaque requête. Donc oui, ça ralentit chaque page.
Symptômes : l'admin devient lent, le frontend rame surtout sur ce qui n'est pas en cache, les sauvegardes prennent un temps fou. Le client soupçonne souvent l'hébergement, parfois change d'offre pour un truc plus cher, alors qu'il s'agit juste d'un nettoyage de base. C'est rapide à régler quand on sait où chercher, mais sans suivi régulier, ça finit par poser des questions techniques auxquelles personne en interne ne sait répondre.
Les petits oublis qui font de gros dégâts
La catégorie fourre-tout, et probablement celle qui fait le plus de victimes parce qu'elle ne ressemble pas à un risque. Le certificat SSL Let's Encrypt qui ne renouvelle plus parce qu'un cron a été désactivé pour une raison oubliée. Le nom de domaine qui expire parce que la carte bancaire associée a changé et que personne n'a mis à jour le compte registrar. La sauvegarde automatique configurée il y a deux ans qui ne tourne plus depuis six mois sans que personne ne s'en soit aperçu.
Pris séparément, aucun de ces incidents n'est dramatique. Mis bout à bout, ils expliquent pourquoi un site qui devait juste exister tranquillement se retrouve un matin inaccessible, sans certificat, et sans sauvegarde récente sur laquelle s'appuyer pour redresser la situation.
Les sauvegardes hors-site, vraie pierre angulaire
S'il faut retenir une seule chose de tout ce qui précède, c'est ça. Les sauvegardes hors-site sont la pierre angulaire d'une maintenance qui tient debout. Pas les mises à jour, pas l'audit, pas la sécurité : les sauvegardes. Tout simplement parce qu'elles sont le dernier filet quand tout le reste a échoué.
Hors-site, c'est le mot important. Une sauvegarde stockée sur le même serveur que le site (ou même chez le même hébergeur dans un dossier voisin) ne sert à rien le jour où l'hébergeur a un incident majeur, où le serveur est compromis et que le pirate efface ce qu'il trouve, ou tout simplement où le compte d'hébergement est suspendu pour une histoire de facturation impayée. La règle classique en sauvegarde, dite du « 3-2-1 », dit qu'on doit avoir trois copies des données, sur deux supports différents, dont au moins une copie hors-site. C'est de l'hygiène basique, et ça change radicalement le profil de risque d'un projet.
Concrètement, sur les sites que je maintiens, ça veut dire des sauvegardes quotidiennes incrémentales du fichier et de la base, conservées plusieurs semaines, déposées sur un stockage extérieur (typiquement S3 compatible chez un acteur européen, ou une solution dédiée de type WP Umbrella, BlogVault, UpdraftPlus avec destination distante). Et surtout, vérification régulière qu'on sait restaurer depuis ces sauvegardes, parce qu'une sauvegarde qu'on n'a jamais testée n'en est pas une. C'est exactement le genre de détail qu'une TMA prend en charge sans qu'on ait à y penser, et qui sauve la mise quand l'inattendu finit par arriver.
Le calcul est vite fait
Quand on additionne, ça devient assez évident. Une TMA basique sur un an coûte une fraction de ce qu'on paie en intervention d'urgence dès qu'un seul de ces incidents se produit. Et au-delà du prix, c'est surtout une question de temps. Une TMA prévient, une intervention d'urgence subit. Pendant qu'on diagnostique en panique, le site est immobilisé, les clients vont voir ailleurs, le référencement Google se dégrade.
Concrètement, mes contrats de TMA couvrent les fondamentaux. Mises à jour régulières du cœur, des plugins et du thème, avec test sur un environnement de pré-production avant publication. Surveillance de la version PHP, et anticipation des évolutions côté hébergeur. Sauvegardes vérifiées, pas juste configurées. Audit ponctuel des plugins et des failles connues. Rien d'extraordinaire, juste de l'hygiène, faite pour de vrai.
Si vous avez un site WordPress qui n'a pas vu d'intervention depuis quelques mois et que vous voulez savoir s'il est dans une situation saine, je propose un audit gratuit de prise de contact (versions, plugins, hébergement, sauvegardes) pour vous donner un avis honnête sans engagement. Écrivez-moi en quelques lignes, je vous reviens vite avec un premier diagnostic.