Refonte WordPress : ce que vous ne savez pas sur votre site va piloter vos décisions à votre place. Prévoyez un audit.
Publié le
par
Vous préparez une refonte. Le périmètre est cadré, les équipes alignées, le prestataire identifié. Vous avez une direction.
Ce que vous voyez du site, vous le maîtrisez. Mais ce qui opère en dessous, c’est une autre histoire – les dépendances implicites, les logiques métier non documentées, les décisions techniques dont plus personne ne se souvient…
Ces zones d’ombre ne restent pas abstraites longtemps. Elles se manifestent en cours de projet, quand les arbitrages sont contraints et que chaque correction coûte deux fois plus cher. Ce n’est pas un risque théorique : c’est le scénario le plus fréquent que nous observons sur les refontes que nous reprenons.
Un audit en amont ne ralentit pas le projet. Il vous remet aux commandes avant que quelqu’un – ou quelque chose – ne prenne les décisions à votre place.
Dans cet article, on explique pourquoi l’existant est systématiquement sous-estimé, et ce que ça coûte concrètement.
On vous partage aussi un guide diagnostic complet : +50 points de vigilance pour cartographier votre site avant de le transformer.
Un site WordPress n’est pas un site. C’est un système.
Il articule une logique métier (formulaires, automatisations, interactions avec d’autres outils), une couche technique (plugins, développements spécifiques, scripts), une infrastructure (hébergement, cache, configuration serveur), un modèle éditorial (outils de contribution, structuration des contenus), et un mode d’exploitation (déploiement, maintenance, supervision).
Dans la plupart des cas que nous voyons lorsque nous reprenons des projets en maintenance, ces couches ne sont pas parfaitement alignées. Des décisions techniques qui contraignent le contenu. Des habitudes de contribution qui contournent les règles prévues. Des fonctionnalités héritées de l’hébergeur qui jouent un vrai rôle dans l’équilibre – sans que personne ne le sache vraiment.
Un site vivant accumule. Chaque intervention a ajouté une couche, une fonctionnalité, une correction, une intégration. Progressivement, une partie de la logique s’est déplacée hors du champ visible.
Tant que le site tient, ce n’est pas un problème. C’est au moment où vous cherchez à le transformer que ça le devient.
La refonte n’assainit pas l’existant. Elle le révèle.
C’est le point que la plupart des directions sous-estiment au moment de lancer le projet. Et ce n’est pas une question de négligence – c’est un mécanisme bien documenté.
Un site qui fonctionne donne une illusion de maîtrise. On en voit le résultat, pas le fonctionnement. Et la refonte est mentalement vécue comme une page blanche – ce qui rend psychologiquement difficile d’investir du temps à documenter ce qu’on est censé quitter. Pourquoi creuser ce qu’on va remplacer ?
C’est précisément ce raisonnement qui expose le projet.
La refonte est perçue comme une opportunité de repartir sur des bases saines. En réalité, elle agit d’abord comme un révélateur.
Parce qu’on ne repart pas de zéro. On modifie plusieurs couches en même temps – structure, contenu, technique, parfois infrastructure. Et à ce moment-là, tout ce qui était implicite devient visible. Une fonctionnalité mal comprise est mal reproduite. Une dépendance non identifiée casse ailleurs. Une anomalie tolérée depuis des mois devient bloquante du jour au lendemain.
Ce que vous ne savez pas va décider à votre place.
Lorsqu’on analyse un site existant en amont d’une refonte, ce ne sont pas tant les problèmes visibles qui ressortent. C’est l’étendue de ce que personne ne maîtrise vraiment : des fonctionnalités dont personne ne connaît le périmètre exact, des automatisations actives mais non documentées, des choix techniques dont la logique s’est perdue.
Et surtout : une tolérance aux anomalies. Des erreurs peuvent exister en continu sans bloquer le site – et donc sans être traitées. Tant que « ça fonctionne », elles restent invisibles. Jusqu’au jour où elles ne le sont plus, souvent en production, souvent au mauvais moment.
Le problème n’est pas que ces zones existent. Tous les sites en ont. Le problème, c’est qu’elles continuent d’exister pendant la refonte, et qu’elles orientent vos décisions sans que vous le sachiez.
Vous pensez arbitrer sur la base d’une lecture claire, mais en réalité, vous arbitrez sur des hypothèses.
Et dans la pratique, ça se traduit par consacrer les premières semaines du projet à comprendre ce qu’on a – pas à construire ce qu’on veut. C’est le coût de l’absence d’audit, qui se paie au mauvais moment.
L’audit n’est pas un état des lieux. C’est ce qui vous remet aux commandes.
Une refonte engage bien plus qu’un nouveau site. Elle engage :
📍 Votre acquisition – SEO, tracking, parcours
📍 Votre performance réelle
📍 Vos fonctionnalités métier
📍 Votre capacité à maintenir et faire évoluer le site
Elle engage aussi un budget, un planning et des équipes. Sans lecture claire de l’existant, vous ne sécurisez pas ces sujets : vous pariez.
Ce qu’un audit produit concrètement, c’est une cartographie des décisions à prendre. Ce que vous conservez, ce que vous corrigez, ce que vous reconstruisez. Avec une visibilité sur les risques réels.
Sans audit, ces décisions existent quand même ! Mais elles sont prises plus tard, sous contrainte, avec moins de visibilité. Ce n’est pas seulement plus risqué : c’est structurellement plus cher.
Précision utile : ce qu’un audit pré-refonte est, et ce qu’il n’est pas.
C’est un point qui revient souvent et qui mérite d’être posé clairement.
Un audit pré-refonte n’est pas un audit de sécurité. Ce n’est pas un audit SEO. Ce n’est pas un audit UX. Ce sont des sujets connexes, légitimes, qui ont leur propre périmètre et leurs propres livrables.
Un audit pré-refonte, c’est une lecture systémique de l’existant au service des décisions à venir. Il répond à une question précise : qu’est-ce que je dois savoir sur ce site avant de le transformer – et pourquoi.
Cette clarté de périmètre n’est pas anodine. C’est souvent la confusion entre ces différents types d’audit qui retarde la décision de lancer la démarche.
Qui le porte en interne ?
Dans les organisations que nous accompagnons, la question du commanditaire revient presque toujours. L’audit, qui le commande ? Qui le lit ? Qui en est responsable ?
En clair, c’est celui qui va porter la refonte qui doit porter l’audit. Pas pour des raisons de gouvernance abstraite, mais parce que l’audit lui donne quelque chose de concret : les arguments pour aligner toutes les autres parties prenantes.
Une refonte ne se pilote pas seul. Elle implique des équipes techniques qui n’ont parfois pas choisi l’outil, des directions métier qui ont leurs propres priorités, des validations qui prennent du temps. L’audit donne une base commune. Une lecture partagée de l’existant, sur laquelle les arbitrages peuvent s’appuyer.
Avant de lancer votre refonte
Il faut sortir de l’idée reçue tenace qu’une refonte permet de repartir de zéro. Nouveau site, nouvelle base, nouvelle page blanche.
En réalité, on ne repart jamais de zéro. On transforme un système existant, avec tout ce qu’il contient. Les contraintes ne disparaissent pas, elles changent de forme, et les dépendances ne s’effacent pas, elles se déplacent.
Ce qui change, c’est votre niveau de lecture au moment de prendre les décisions. Et c’est précisément ça qui fait la différence entre un projet qu’on pilote et un projet qu’on subit.
Récupérez votre guide diagnostic
+50 points de vigilance répertoriés, pour voir si votre projet repose sur une base maîtrisée ou sur des angles morts.
« * » indique les champs nécessaires
Si la checklist révèle de nombreuses zones d’ombre, c’est généralement le signe qu’un audit structuré s’impose avant de lancer la production. C’est précisément ce type de situation qu’on accompagne.
