Une refonte de site web commence rarement par une question technique. Elle commence par une phrase du type : « notre site fait daté », « on veut quelque chose de plus moderne », « la concurrence a un site plus joli que le nôtre ». Le design est le déclencheur visible. Mais dans la grande majorité des projets WordPress et PrestaShop que l’on reprend, le vrai problème est ailleurs : le site n’est plus maintenable. Il ne peut plus être mis à jour, il tourne sur une version de PHP obsolète, et chaque tentative de correction casse quelque chose.

Cet article revient sur ce qui provoque réellement une refonte, sur le rôle du thème — la décision la plus sous-estimée du projet — et sur les montées de version PHP qui immobilisent tant de sites.

Le vrai déclencheur d’une refonte n’est presque jamais esthétique

Un site vieillit sur trois plans en même temps, mais à des vitesses différentes.

Le design vieillit lentement et de façon visible. Un site de 2019 paraît daté, mais il fonctionne encore.

La technique vieillit vite et de façon invisible. Les extensions ne sont plus maintenues, le thème n’a pas reçu de mise à jour depuis deux ans, l’hébergeur annonce la fin de support de PHP 7.4. Rien ne se voit à l’écran, jusqu’au jour où plus rien ne bouge.

La sécurité, elle, ne vieillit pas : elle se dégrade. Chaque extension non mise à jour est une porte laissée ouverte. WordPress et PrestaShop étant les deux CMS les plus déployés dans leurs catégories respectives, ils sont aussi les plus scannés automatiquement par les robots malveillants.

Le scénario typique : un client demande une refonte graphique, et l’audit d’un site existant révèle que le site tourne sur PHP 7.2, avec un thème premium acheté sur une marketplace, abandonné par son auteur, et quinze extensions dont six ne sont plus compatibles avec les versions actuelles du CMS. La refonte graphique devient alors le prétexte — parfaitement légitime — pour assainir la base.

Le choix du thème : la décision la plus structurante du projet

C’est le point sur lequel se joue la maintenabilité des cinq années à venir, et c’est paradoxalement celui qu’on traite le plus rapidement.

Le piège des thèmes « multi-usages »

Sur WordPress, les thèmes premium vendus sur les grandes marketplaces séduisent par leur promesse : des dizaines de démos préconfigurées, un constructeur de pages intégré, des centaines d’options. Le problème, c’est ce que cette polyvalence coûte.

Un thème multi-usages embarque du code pour tous les cas d’usage possibles, dont vous n’utiliserez que 5 %. Cela se traduit par des temps de chargement dégradés, un poids inutile sur chaque page, et surtout par une dépendance forte : le contenu est souvent stocké dans des formats propriétaires liés au constructeur de pages. Changer de thème revient alors à reconstruire l’intégralité du contenu.

Autre difficulté : ces thèmes intègrent fréquemment des versions d’extensions tierces sous licence groupée. Si l’auteur du thème cesse ses mises à jour, ces extensions restent figées à une version ancienne, y compris quand une faille de sécurité est publiée. Vous n’avez alors aucun moyen simple de les mettre à jour vous-même.

Deux familles de thèmes, et ce qu’elles engagent réellement sur la durée :

Critère	Thème premium multi-usages	Thème sur mesure ou minimaliste
Poids et chargement	Code pour des usages jamais utilisés	Seulement ce qui sert réellement
Stockage du contenu	Souvent un format propriétaire du constructeur de pages	Format natif du CMS, portable d’un thème à l’autre
Mises à jour des extensions groupées	Figées si l’auteur du thème arrête les siennes	Chaque extension se met à jour indépendamment
Coût de départ	Plus bas, quelques dizaines d’euros	Plus élevé, un développement dédié
Coût à cinq ans	Reconstruction complète si le thème est abandonné	Maintenance incrémentale, pas de reprise à zéro

Ce qu’il faut regarder avant de choisir

Quelques critères qui comptent davantage que le nombre de démos disponibles :

La fréquence des mises à jour sur les vingt-quatre derniers mois, pas seulement la date de la dernière.
L’éditeur : un studio structuré ou un développeur isolé ? Un thème abandonné est un thème à remplacer.
La compatibilité annoncée avec les versions PHP actuelles et les dernières versions du CMS.
Le mode de stockage du contenu : contenu natif ou format propriétaire ?
La possibilité de personnaliser proprement via un thème enfant, sans modifier les fichiers d’origine.

Sur les projets exigeants, un thème sur mesure — ou un thème minimaliste enrichi de blocs natifs — coûte souvent plus cher au départ et bien moins cher sur la durée.

Le cas particulier de PrestaShop

Sur PrestaShop, le sujet est encore plus sensible. Beaucoup de thèmes du marché s’appuient sur des overrides : des fichiers qui remplacent le comportement natif du logiciel. Un override est pratique à court terme et redoutable à long terme, car il fige le cœur du système. Dès que PrestaShop met à jour la classe concernée, l’override continue d’exécuter l’ancienne version du code, avec des effets de bord difficiles à diagnostiquer.

Un thème PrestaShop propre respecte l’architecture des modules et des hooks, et n’écrase pas le cœur. Cette seule différence sépare une boutique qui se met à jour en une heure d’une boutique bloquée pour trois ans.

PHP : la montée de version qui immobilise les sites

C’est le point de bascule le plus fréquent, et le plus mal anticipé.

Les hébergeurs cessent régulièrement de prendre en charge les anciennes versions de PHP, parce qu’elles ne reçoivent plus de correctifs de sécurité. Le passage de PHP 7.x aux versions 8.x introduit des changements de comportement qui rendent silencieusement inopérant du code écrit quelques années plus tôt. Fonctions supprimées, typage plus strict, erreurs autrefois tolérées devenues fatales.

Concrètement, cela produit trois situations :

Le site tombe. Page blanche, erreur 500, back-office inaccessible. C’est le cas le plus visible, donc le moins dangereux : on le corrige immédiatement.

Le site fonctionne, mais partiellement. Le formulaire de contact n’envoie plus rien. Le tunnel de commande échoue à la dernière étape. Un module de transporteur ne calcule plus les frais de port. Ces pannes passent parfois inaperçues pendant des semaines, avec un coût commercial direct.

Le site est gelé. C’est la situation la plus courante et la plus insidieuse. L’hébergeur impose PHP 8, mais un module critique ne le supporte pas. On reste donc sur l’ancienne version. Résultat : on ne peut plus mettre à jour le CMS, ni les extensions, ni le thème. Le site continue de tourner, en apparence normalement, sur une pile logicielle qui ne reçoit plus aucun correctif de sécurité — exactement le point aveugle que décrit notre article sur la surveillance d’un site après sa mise en ligne.

Ce gel est le vrai motif de refonte. C’est de la dette technique arrivée à échéance.

La dette technique se paie toujours, la question est quand

Le raisonnement est simple. Chaque mise à jour reportée augmente l’écart entre l’état du site et l’état du logiciel. Plus cet écart grandit, plus le rattrapage devient coûteux et risqué.

Un site tenu à jour en continu se maintient pour quelques centaines d’euros par an. Le même site laissé trois ans sans intervention nécessitera souvent une reprise complète, parce que les versions intermédiaires ne sont plus franchissables directement et que les modules obsolètes doivent être remplacés un par un.

Sur PrestaShop, ce phénomène est amplifié : le passage des anciennes branches vers les versions 8 et suivantes est une véritable migration, pas une mise à jour. Données, modules, thème et personnalisations doivent être traités séparément. Sur une boutique en production, avec un historique de commandes et de clients, l’opération demande une préparation sérieuse.

Conduire une refonte proprement

Quelques principes qui évitent de recréer le problème que l’on vient de résoudre :

Auditer avant de dessiner. Inventaire des extensions, de leur état de maintenance et de leur compatibilité PHP. Cet inventaire détermine souvent le périmètre réel du projet.

Décider ce qu’on garde et ce qu’on abandonne. Une refonte est le bon moment pour supprimer les fonctionnalités inutilisées. Chaque module conservé est un engagement de maintenance.

Travailler sur un environnement de préproduction. Aucune migration PHP ou CMS ne se teste directement en production, surtout sur une boutique.

Prévoir les redirections. C’est l’erreur la plus coûteuse en positions acquises sur les requêtes locales : changer les URL sans plan de redirection 301 détruit en une nuit un positionnement construit sur des années.

Contractualiser la maintenance. Une refonte sans plan de maintenance produit exactement le même site bloqué, trois ans plus tard.

En résumé

Une refonte réussie se juge trois ans après, pas le jour de la mise en ligne. Le site est-il toujours à jour ? Peut-on encore changer de version PHP sans crainte ? Le thème reçoit-il toujours des correctifs ?

Le design attire l’attention. Ce sont le thème et la capacité à se mettre à jour qui déterminent la durée de vie réelle du projet. Un thème maintenu, une architecture qui n’écrase pas le cœur du CMS, une compatibilité PHP traitée comme un critère de choix : à ce prix, une refonte règle le problème au lieu de le reporter de trois ans.

Bleupixel reprend et remet à niveau des sites WordPress depuis Buis-les-Baronnies, en Drôme provençale, aussi souvent qu’il en construit de nouveaux. Si le vôtre commence à se figer, dites en quelques lignes où il en est : l’inventaire des extensions suffit en général à savoir s’il faut une refonte ou une remise à niveau.

Sur des sujets voisins : partir de zéro plutôt que de refaire, quand on est artisan, remettre à plat sa fiche d’établissement Google — une refonte est le bon moment —, et les guides publiés par Bleupixel.

Refonte de site WordPress ou PrestaShop : les pièges techniques que personne ne voit venir