Une refonte PrestaShop ne consiste pas à installer un nouveau thème sur une base ancienne. Elle touche un système qui encaisse des commandes, conserve des comptes clients, applique des règles commerciales et échange parfois avec plusieurs outils. La bonne méthode protège d’abord les ventes et les données, puis améliore l’expérience et la technique.
Commencer par la boutique réellement exploitée
Deux installations de même version peuvent avoir des risques très différents. L’une utilise quelques fonctions natives et un paiement standard. L’autre dépend d’un thème surchargé, de modules modifiés, d’un transporteur spécifique, d’un ERP et de tâches planifiées qui ne sont documentées nulle part.
Avant de choisir une cible, observez le fonctionnement actuel sur une période représentative. Une commande simple ne révèle pas les remises par groupe, les retours partiels, les ruptures, les avoirs, les ventes internationales ou les interventions manuelles réalisées chaque semaine.
| Périmètre | Éléments à recenser | Risque si oublié |
|---|---|---|
| Catalogue | Produits, déclinaisons, caractéristiques, marques, catégories, médias et règles de prix | Fiches incomplètes, variantes dupliquées ou prix incohérents |
| Commandes | États, factures, avoirs, retours, paiements, transporteurs et e-mails | Historique inutilisable ou parcours de traitement interrompu |
| Personnalisation | Thème, modules, overrides, hooks, scripts et tâches planifiées | Fonction métier disparue après mise à jour |
| Connexions | ERP, PIM, comptabilité, stock, marketplaces, CRM et outils marketing | Données contradictoires ou échanges silencieusement bloqués |
| SEO | URL, canonicals, catégories, contenus, filtres, backlinks et trafic | Perte de visibilité après changement de structure |
| Infrastructure | PHP, base, cache, stockage, sauvegardes, DNS, certificats et e-mails | Nouvelle boutique correcte mais environnement incapable de la servir |
Décider ce qui doit être conservé, corrigé ou remplacé
Tout migrer à l’identique reproduit la dette existante. Tout reconstruire sans inventaire supprime des fonctions discrètes mais essentielles. Chaque composant doit donc recevoir une décision explicite : conserver, mettre à jour, reconfigurer, remplacer, redévelopper ou retirer.
Pour un module, relevez son éditeur, sa version, sa licence, ses données, ses dépendances et les éventuelles modifications locales. Un module inutilisé mais encore actif peut ralentir l’administration ou agrandir la surface d’attaque. À l’inverse, un module peu visible peut produire les exports attendus chaque matin par la logistique.
Cartographier les données et leur source de vérité
Une migration fiable ne se résume pas à copier des tables. Il faut savoir quelles données doivent vivre dans la nouvelle boutique et lesquelles appartiennent à un autre système. Si le stock vient d’un ERP, une modification manuelle dans PrestaShop sera peut-être écrasée au prochain échange. Si les prix sont calculés dans la boutique, l’ERP ne doit pas les renvoyer sans règle claire.
Pour chaque flux, documentez
- le système qui déclenche l’échange et celui qui fait foi ;
- les objets et champs réellement transmis ;
- la fréquence, le volume et le délai acceptable ;
- la méthode d’authentification et les droits accordés ;
- la détection des doublons et des données invalides ;
- les journaux disponibles, les alertes et la méthode de reprise.
La documentation développeur PrestaShop sur les services externes présente plusieurs mécanismes d’échange. Le webservice natif expose des ressources, tandis qu’un contrôleur de module peut porter une action plus spécifique. Le mécanisme doit suivre le cas d’usage au lieu d’être choisi uniquement parce qu’il existe déjà.
Construire une matrice de migration
Une matrice transforme une intention vague en contrôle vérifiable. Pour chaque famille de données, indiquez la source, la cible, la méthode, les transformations, le volume attendu et la preuve de réussite.
| Donnée | Décision | Contrôle après import |
|---|---|---|
| Produits actifs | Importer avec références, déclinaisons, prix et catégories | Comparer les volumes et un échantillon de chaque type |
| Anciens produits visibles dans Google | Conserver, remplacer ou rediriger individuellement | Tester statut HTTP, destination et contenu équivalent |
| Comptes clients | Conserver les données nécessaires et la méthode de connexion compatible | Tester connexion, réinitialisation et consentements |
| Commandes | Importer l’historique utile au support et à la comptabilité | Comparer totaux, taxes, états, factures et avoirs |
| Modules abandonnés | Ne pas migrer, mais identifier leurs données résiduelles | Vérifier qu’aucun traitement ou écran n’en dépend |
Préserver les URL qui ont acquis de la valeur
Exportez les URL depuis le sitemap, un crawl, Search Console, les outils analytics et les backlinks connus. Ajoutez les catégories et produits absents de ces sources mais encore utiles aux clients. Pour chaque ancienne URL, définissez une destination précise.
Une page supprimée n’a pas toujours besoin d’une redirection. Si aucun équivalent n’existe et que le contenu n’a plus d’utilité, un statut de suppression peut être plus honnête. En revanche, une catégorie renommée ou un produit remplacé doit conduire vers la ressource la plus proche, pas vers l’accueil.
Contrôlez également les canonicals, les variantes de langue, les paramètres, les filtres et la pagination. Le but n’est pas d’indexer chaque combinaison possible, mais de rendre accessibles les pages qui répondent à une intention distincte.
Recetter avec des scénarios de vente complets
Une recette limitée à « la page s’affiche » ne protège pas une boutique. Préparez des scénarios qui traversent plusieurs systèmes et incluent les erreurs.
- Créer un compte. Tester validation, consentement, e-mail, connexion et réinitialisation du mot de passe.
- Composer un panier. Mélanger déclinaisons, remises, seuils, stock faible et produits soumis à des règles différentes.
- Choisir la livraison. Vérifier zones, poids, montants, points relais, délais et indisponibilités.
- Payer. Tester réussite, refus, abandon, double clic, retour tardif du prestataire et confirmation de commande.
- Traiter la commande. Vérifier stock, facture, préparation, e-mails, expédition et mise à jour des outils connectés.
- Gérer l’après-vente. Tester annulation, retour partiel, remboursement, avoir et historique client.
La documentation utilisateur PrestaShop consacrée aux commandes rappelle l’étendue du cycle : commandes, factures, avoirs, retours, paniers et opérations du back-office. Chaque fonction utilisée par l’entreprise doit apparaître dans la recette.
Préparer une bascule réversible
Fixez une heure de gel des modifications, puis déterminez les données à resynchroniser juste avant l’ouverture : nouvelles commandes, clients, stocks, contenus ou prix. Réduisez le TTL DNS si un changement d’infrastructure est prévu et conservez l’ancien environnement tant que les contrôles ne sont pas terminés.
Le plan de bascule doit nommer
- la dernière sauvegarde et sa procédure de restauration ;
- la personne responsable de chaque action ;
- l’ordre des imports et changements techniques ;
- les tests bloquants avant ouverture ;
- les critères qui déclenchent un retour arrière ;
- la surveillance des paiements, commandes, e-mails, erreurs et redirections.
Une refonte réussie améliore aussi l’exploitation
Le nouveau front-office peut être plus clair et plus rapide, mais la réussite se mesure également dans le back-office : temps nécessaire pour créer un produit, comprendre une erreur, préparer une commande ou modifier une règle commerciale. Documentez les changements et formez les personnes qui utiliseront réellement la boutique.
Pour étudier une création ou une reprise, découvrez le service Alliance Web de création et refonte PrestaShop à Angers. Le guide sur la refonte d’un site internet complète les contrôles de contenu, de mesure et de mise en ligne.
Besoin d’un regard extérieur ?
Passons de la méthode à votre projet.
Alliance Web peut vous aider à prioriser les décisions et à construire un périmètre adapté.
Découvrir le service associé