Refondre un site WooCommerce sans perdre l’historique des commandes

Le vrai enjeu n’est pas le design, c’est la donnée

Une boutique WooCommerce n’est pas un site, c’est une base de données vivante habillée d’un site. Derrière les pages, il y a l’historique des commandes, les comptes clients et leurs adresses, les moyens de paiement enregistrés, les stocks, les coupons, parfois des abonnements en cours, et tout un réseau de flux : e-mails transactionnels, connexions comptables, exports logistiques.

Refondre, c’est changer l’habillage et la mécanique de présentation sans perturber cette donnée. La confondre avec une simple refonte graphique est la première erreur, et la plus coûteuse.

Pourquoi un thème comme Elementor finit par peser

Elementor, comme les autres constructeurs visuels, permet de composer des pages sans coder. C’est son intérêt, et c’est aussi son coût. Pour offrir cette souplesse, il génère un volume important de code : un arbre HTML profond, des feuilles de style et des scripts chargés sur chaque page, des réglages empilés au fil des années.

Sur un site vitrine, cette surcharge se remarque à peine. Sur une boutique, elle se paie en Core Web Vitals dégradés, donc en positions perdues et en conversions manquées : chaque dixième de seconde de chargement compte au moment d’acheter. Le problème n’est pas de vouloir un beau site, c’est le poids accumulé et la dépendance à un outil dont on ne sort plus facilement.

Sortir d’Elementor : remplacer, pas nettoyer

On ne « nettoie » pas un site Elementor pour le rendre léger : le poids est structurel. On le remplace par un thème léger, construit avec les blocs natifs de WordPress ou développé sur mesure, dont chaque ligne de code a une raison d’être.

Le piège, c’est que le contenu est souvent enfermé dans les widgets Elementor. Supprimer l’extension sans préparation laisse des pages remplies de codes techniques inertes. La bonne démarche consiste à extraire le contenu réel, puis à reconstruire proprement les gabarits qui comptent : la fiche produit, la page catégorie, le panier, le tunnel de commande et l’espace compte. Ce sont eux qui font vendre, et eux qui doivent être irréprochables.

Cartographier avant de toucher

Aucune boutique ne se refond à l’aveugle. Avant la première ligne, on dresse l’inventaire de l’existant :

• Les gabarits : accueil, catégorie, fiche produit, panier, commande, compte client, pages légales.
• Les extensions : paiement, livraison, calcul de TVA, marketing, e-mails, avis, fidélité.
• Les intégrations : logiciel de comptabilité, ERP, CRM, outil d’e-mailing, pixels publicitaires, marketplaces.
• Les flux : e-mails transactionnels, webhooks de paiement, exports de commandes, synchronisation des stocks.
• Les parcours et tunnels : relance de panier abandonné, ventes additionnelles, codes promo, programmes de fidélité.

Cette cartographie est la colonne vertébrale du projet. Ce qui n’y figure pas est ce qui casse le jour de la bascule.

Les données WooCommerce : où elles vivent vraiment

Comprendre où sont stockées les données change tout. Les produits, les clients et les coupons vivent dans les tables de WordPress. Les commandes, elles, ont depuis peu leur propre logement : le stockage haute performance des commandes, le HPOS, range désormais les commandes dans des tables dédiées plutôt que parmi les articles du site. C’est plus rapide, mais cela veut dire que l’historique des ventes est une donnée structurée à part entière, qu’il faut préserver telle quelle.

Le principe directeur en découle : ces données ne se recréent pas, elles se préservent. On ne « refait » pas un historique de commandes, un compte client ou un paiement enregistré. On les garde intacts, et on change ce qu’il y a autour.

La bonne méthode : refondre sur une copie de la base réelle

Deux approches existent, et une seule protège vraiment la donnée.

La mauvaise consiste à bâtir un site neuf puis à y importer les données. C’est là que se perdent les identifiants de commande, que se cassent les liens de paiement, que l’historique se retrouve tronqué ou dédoublé. Sur une boutique à lourd historique, cette voie est un champ de mines.

La bonne consiste à refondre en place, sur une copie complète de la base réelle. On duplique le site en environnement de test, on y remplace la couche de présentation (thème, gabarits, extensions superflues), et on ne touche pas aux tables WooCommerce. La donnée ne bouge pas : elle est simplement rhabillée. Quand la copie est parfaite, c’est elle qui devient le site, pas un site neuf qu’on aurait rempli à la main.

Préserver les flux, les tunnels et les fonctionnalités

Une boutique n’est pas qu’un catalogue : c’est un ensemble de mécanismes qui doivent survivre à la refonte, un par un.

• Les paiements : passerelles reconnectées, jetons de carte préservés, webhooks re-testés, pour que les abonnements et les remboursements continuent de fonctionner.
• Les e-mails transactionnels : confirmation, expédition, facture. Ils doivent partir dès la première commande post-bascule, sans exception.
• La TVA et la livraison : règles, zones et transporteurs vérifiés, car une erreur ici fausse chaque commande.
• Les comptes clients : conservés avec leurs mots de passe chiffrés, pour que personne n’ait à se réinscrire.
• Les tunnels et relances : panier abandonné, ventes additionnelles, codes promo, reconstruits à l’identique ou améliorés, jamais oubliés.
• Le référencement : les adresses des produits et des catégories sont préservées. Quand une URL doit changer, une redirection 301 la relie à l’ancienne, pour ne pas perdre le trafic ni le jus des liens.

La bascule : la nuit du go-live

La mise en ligne se prépare comme une opération, pas comme un clic. Le déroulé type :

• Fenêtre courte de gel des commandes, choisie sur un creux d’activité.
• Synchronisation finale des commandes reçues entre le clone et le site en production, pour ne rien perdre du dernier moment.
• Bascule vers la version refondue.
• Tests immédiats : une commande de test réelle jusqu’au paiement, l’e-mail de confirmation reçu, un compte client vérifié, une facture générée.
• Plan de retour arrière prêt : si un test échoue, on revient à l’état précédent en quelques minutes.

Tant que la commande de test n’a pas abouti de bout en bout, la bascule n’est pas validée.

Après la bascule : surveiller, comparer

Une refonte ne se juge pas le soir du go-live, mais dans les jours qui suivent. On surveille le volume de commandes, le taux de conversion, les erreurs éventuelles et les Core Web Vitals, et on compare avec l’avant. C’est la preuve, chiffrée, que le site refondu vend mieux et plus vite, sans avoir rien perdu en route.

C’est exactement le type de projet que mène Limbus Studio : une refonte WooCommerce qui allège le site, modernise l’interface et préserve l’intégralité de l’historique, des flux et des fonctionnalités.