Refonte WordPress ou PrestaShop : les pièges techniques qu’on découvre trop tard

Une refonte commence souvent par une remarque sur le design : « Le site fait vieux. » « On voudrait quelque chose de plus moderne. »

Mais lorsqu’on ouvre réellement le site, le problème est parfois ailleurs.

Version de PHP ancienne, thème abandonné, extensions qui ne peuvent plus être mises à jour, dépendances devenues fragiles : le site fonctionne encore, mais chaque modification devient risquée.

La vraie question n’est donc pas seulement : « À quoi doit ressembler le nouveau site ? » C’est aussi : « Sur quelles bases voulons-nous pouvoir le faire évoluer dans cinq ans ? »

Un site peut vieillir sans que cela se voie

Le design est la partie la plus visible.

Un site créé il y a quelques années peut sembler daté tout en continuant parfaitement à remplir son rôle.

La technique, elle, vieillit plus discrètement.

Une extension n’est plus maintenue. Le thème ne suit plus les nouvelles versions du CMS. L’hébergeur annonce la fin d’une ancienne version de PHP.

Rien ne change forcément à l’écran.

Jusqu’au jour où une mise à jour devient impossible ou qu’une fonctionnalité cesse de fonctionner.

C’est souvent à ce moment-là qu’une simple refonte graphique devient un vrai chantier technique.

Avant de refaire le design, regarder ce qu’il y a dessous

Un audit de refonte devrait commencer par un inventaire.

Pour WordPress comme pour PrestaShop :

• version du CMS ;
• version de PHP ;
• thème utilisé ;
• extensions ou modules installés ;
• date de leur dernière mise à jour ;
• fonctionnalités réellement utilisées ;
• personnalisations ajoutées au fil du temps.

Cet inventaire permet de distinguer trois situations :

• Le site est sain. Une évolution graphique peut suffire.
• Le site est vieillissant mais récupérable. Certaines briques doivent être remplacées ou mises à jour.
• Le site est bloqué techniquement. La refonte devient l’occasion de repartir sur une base plus durable.

Le thème engage plusieurs années

Le choix d’un thème est souvent traité comme une question esthétique.

Il influence pourtant la performance, la maintenance et la facilité avec laquelle le site pourra évoluer.

Les thèmes très polyvalents

Les thèmes dits « multi-usages » peuvent être pratiques : ils proposent beaucoup de composants et permettent de produire rapidement des mises en page complexes.

Leur contrepartie est qu’ils peuvent embarquer de nombreuses fonctions dont le site n’a pas besoin.

Selon le thème et le constructeur de pages utilisé, cela peut aussi créer une dépendance : changer de thème plusieurs années plus tard devient plus compliqué si une partie du contenu repose sur des blocs ou formats spécifiques.

Ce n’est pas une raison pour bannir les thèmes premium.

C’est une raison pour regarder comment ils sont construits et maintenus, pas seulement leur démonstration commerciale.

Deux familles de thèmes, et ce qu’elles engagent le plus souvent sur la durée :

Critère	Thème premium multi-usages	Thème sur mesure ou minimaliste
Poids et chargement	Du code pour des usages que le site n’emploie pas	Ce qui sert réellement
Stockage du contenu	Parfois un format propre au constructeur de pages	Format natif du CMS, portable d’un thème à l’autre
Extensions fournies avec le thème	Figées si l’auteur du thème arrête ses mises à jour	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 sur plusieurs années	Une reprise lourde si le thème est abandonné	Une maintenance progressive

Ce que je regarde avant de choisir un thème

Quelques critères comptent davantage que le nombre de modèles disponibles :

• fréquence réelle des mises à jour ;
• historique de l’éditeur ;
• compatibilité avec les versions actuelles de PHP et du CMS ;
• façon dont le contenu est stocké ;
• dépendance à un constructeur de pages ;
• possibilité d’ajouter les personnalisations proprement ;
• documentation disponible.

Un thème simple, bien maintenu et suffisamment souple est souvent plus intéressant à long terme qu’un thème capable de tout faire.

Le cas particulier de PrestaShop

Sur PrestaShop, il faut aussi regarder la façon dont le thème et les modules personnalisent le fonctionnement du logiciel.

Les overrides permettent de remplacer certains comportements natifs.

Ils peuvent être utiles, mais ils compliquent parfois les mises à jour lorsque le cœur de PrestaShop évolue alors que le code personnalisé continue de reproduire un ancien fonctionnement.

Lors d’un audit, la question n’est donc pas seulement : « Quels modules sont installés ? » Mais : « Qu’est-ce qui a été modifié par rapport au fonctionnement standard ? »

C’est souvent là que se cachent les difficultés de migration.

PHP : le moment où la dette technique devient visible

WordPress, PrestaShop, leurs thèmes et leurs extensions dépendent de PHP.

Les anciennes versions finissent par ne plus recevoir de correctifs de sécurité, puis les hébergeurs cessent progressivement de les proposer.

C’est normal.

Le problème apparaît lorsqu’un site dépend encore d’un composant qui ne fonctionne pas correctement avec la version suivante.

Trois situations sont fréquentes.

Le site ne fonctionne plus. Erreur 500, page blanche, administration inaccessible. C’est spectaculaire, mais au moins le problème est immédiatement visible.

Une fonctionnalité casse discrètement. Le site continue de s’afficher, mais le formulaire n’envoie plus, un paiement échoue, un module de livraison répond mal ou une tâche programmée ne s’exécute plus. C’est souvent plus dangereux parce que le problème peut rester invisible plusieurs jours ou plusieurs semaines. WooCommerce exigera PHP 8.1 à partir de sa version 11.6, en février 2027 : les mises à jour d’une boutique WooCommerce se préparent donc dès maintenant.

Le site devient impossible à mettre à jour. C’est le cas le plus gênant. Un composant important bloque le passage vers une nouvelle version de PHP. On conserve donc l’ancienne version. Puis le CMS ne peut plus évoluer. Puis certaines extensions non plus. Le site continue de fonctionner, mais le retard technique s’accumule.

La dette technique ne disparaît pas

Reporter une mise à jour n’est pas toujours une erreur.

Il est parfois raisonnable d’attendre quelques semaines ou quelques mois.

Mais lorsqu’une pile logicielle reste figée pendant plusieurs années, chaque étape de rattrapage devient plus délicate.

Le problème n’est pas seulement le temps écoulé.

C’est le nombre de dépendances qui ont évolué entre-temps :

• PHP ;
• CMS ;
• thème ;
• modules ;
• API externes ;
• moyens de paiement ;
• services de livraison.

Plus l’écart est important, plus une simple mise à jour ressemble à une migration.

Refonte ou remise à niveau ?

Tout site ancien n’a pas besoin d’être reconstruit.

Avant de parler de refonte, je distingue deux possibilités.

La remise à niveau. On conserve la structure actuelle et on corrige les versions, le thème, les extensions, les performances, la sécurité et quelques éléments graphiques. C’est pertinent lorsque la base est encore saine.

La refonte. On revoit l’architecture, le design et parfois les outils techniques. Elle devient pertinente lorsque l’existant bloque réellement l’évolution du site ou que les besoins de l’entreprise ont profondément changé.

L’audit sert justement à éviter de vendre une reconstruction complète lorsqu’une remise à niveau suffit.

Parfois, c’est l’entreprise qui change

Un site peut être techniquement sain et devoir quand même être refait.

Parce que l’entreprise a changé.

Bleupixel a par exemple accompagné une entreprise artisanale de la Drôme dont l’activité a été séparée en deux sociétés.

Le site unique ne correspondait plus à la nouvelle organisation.

Une partie du travail a donc consisté à conserver le domaine historique pour une activité et à créer un nouveau domaine pour l’autre.

Dans ce type de projet, le principal risque n’est pas PHP.

C’est le référencement.

Le résultat mérite d’être donné sans le lisser : il y a eu un creux. Les deux sites ont retrouvé leur niveau de trafic en moins de quatre mois. Une séparation de domaine se paie, et quatre mois est une durée qu’il vaut mieux annoncer au départ que découvrir en route.

Une refonte peut casser ce qui fonctionnait déjà sur Google

Lorsqu’une page change d’adresse, Google doit comprendre où son contenu a été déplacé.

Si l’ancienne URL disparaît sans redirection, elle devient une erreur 404.

Les liens reçus vers cette adresse et l’historique associé ne sont alors plus transmis proprement vers la nouvelle page.

C’est pourquoi le plan de redirection fait partie de la refonte, pas du ménage effectué après la mise en ligne.

Avant la migration : conserver la carte de l’ancien site

Avant de toucher au site, je garde une liste aussi complète que possible des anciennes URL.

Plusieurs sources peuvent être utiles :

• sitemap ;
• Search Console ;
• outils d’analyse ;
• ancienne configuration de redirections ;
• crawl du site ;
• URL recevant encore des liens.

Le sitemap seul n’est pas toujours suffisant.

Bleupixel en a fait l’expérience lors de sa propre refonte : Search Console a fait réapparaître une ancienne URL qui ne figurait plus dans le sitemap utilisé pour préparer la migration.

Toutes les anciennes pages ne doivent pas être redirigées vers l’accueil

Une redirection doit avoir du sens.

Si une ancienne page possède un équivalent clair, elle redirige vers celui-ci.

Si elle n’a aucun équivalent et aucune valeur particulière, une 404 peut être parfaitement normale.

Envoyer toutes les anciennes URL vers la page d’accueil donne l’impression de « sauver » les adresses, mais cela ne fournit pas nécessairement une destination pertinente au visiteur ou au moteur.

Le plan doit donc être décidé URL par URL.

Toujours travailler sur une préproduction

Une montée de version importante ne se teste pas directement sur le site public.

Encore moins sur une boutique PrestaShop.

Une préproduction permet de vérifier :

• PHP ;
• thème ;
• modules ;
• formulaires ;
• commandes ;
• paiements ;
• transporteurs ;
• emails ;
• tâches programmées ;
• performances.

L’objectif est simple : découvrir les problèmes avant les clients.

Profiter de la refonte pour supprimer

Une refonte est aussi une occasion de faire du tri.

Une extension installée il y a cinq ans pour une fonctionnalité qui n’existe plus n’a aucune raison de rester.

Chaque module conservé représente :

• une mise à jour future ;
• un risque de compatibilité ;
• une dépendance supplémentaire ;
• parfois un coût de licence.

Ce qu’on supprime proprement ne tombera plus jamais en panne.

Et après la mise en ligne ?

La refonte n’est pas la fin de la maintenance.

Sans mises à jour régulières, on reconstruit simplement un site qui rencontrera les mêmes problèmes quelques années plus tard.

Après livraison, il faut au minimum prévoir :

• mises à jour ;
• sauvegardes ;
• contrôle des erreurs ;
• vérification des formulaires ou commandes ;
• suivi de l’hébergement ;
• surveillance des composants abandonnés.

La maintenance n’a pas besoin d’être lourde.

Elle doit surtout être régulière.

Comment savoir s’il faut refaire le site ?

Quelques signaux doivent inciter à regarder de plus près :

• PHP très ancien ;
• CMS impossible à mettre à jour ;
• thème abandonné ;
• extensions critiques non maintenues ;
• erreurs après chaque mise à jour ;
• back-office devenu difficile à utiliser ;
• fonctionnalités devenues inutiles mais impossibles à retirer ;
• architecture qui ne correspond plus à l’entreprise.

Un seul de ces signes n’impose pas forcément une refonte.

Plusieurs réunis justifient au minimum un audit.

Questions fréquentes

Un vieux site doit-il forcément être refait ?

Non.

L’âge n’est pas le bon critère.

Un site ancien mais bien entretenu peut rester parfaitement exploitable. Un site beaucoup plus récent peut être techniquement bloqué s’il dépend d’un thème ou d’extensions abandonnées.

Un thème premium est-il une mauvaise idée ?

Pas nécessairement.

Le sujet est surtout sa maintenance, son architecture et le niveau de dépendance qu’il crée.

Peut-on simplement changer de version PHP ?

Parfois.

Mais il faut d’abord tester la compatibilité du CMS, du thème et des modules.

Sur une boutique ou un site important, cette vérification doit se faire sur une copie du site.

Faut-il absolument conserver toutes les anciennes URL ?

Non.

Il faut surtout conserver ou rediriger celles qui ont un équivalent utile, du trafic, des liens ou une valeur éditoriale.

Certaines anciennes URL peuvent légitimement disparaître.

Une refonte fait-elle forcément perdre du référencement ?

Non.

Mais elle peut provoquer une période de transition, surtout si les URL, les contenus ou les domaines changent.

Le risque se réduit fortement en préparant l’indexation et les redirections avant la mise en ligne.

Une refonte réussie doit surtout rester maintenable

Le design compte.

Mais la réussite d’une refonte se voit aussi plus tard :

• les mises à jour passent toujours ;
• PHP peut évoluer ;
• le thème est encore maintenu ;
• les extensions sont sous contrôle ;
• le contenu reste facile à modifier.

Autrement dit, le nouveau site ne doit pas seulement être plus joli.

Il doit être plus facile à faire vivre.

Bleupixel reprend, maintient et refond des sites WordPress et sites web depuis Buis-les-Baronnies, en Drôme et dans le Vaucluse.

Si votre site commence à devenir difficile à mettre à jour, un simple inventaire du CMS, de PHP, du thème et des extensions suffit souvent à savoir s’il faut réellement le refaire ou simplement le remettre à niveau.