Migration e-commerce : la checklist des données à réunir

Migration e-commerce: la checklist des données à réunir

Le scénario classique est moins élégant: des variantes disparaissent, des prix se décalent, les comptes clients ne se reconnectent plus, les anciennes fiches produits renvoient vers des erreurs 404 et les passerelles de paiement demandent soudain des identifiants que personne n’a pensé à récupérer.

Le problème n’est généralement pas la nouvelle plateforme. Shopify, WooCommerce ou une solution plus spécialisée savent vendre en ligne. Le problème vient de ce que nous avons laissé derrière nous: données mal classées, URL oubliées, historiques incomplets, règles métier enfouies dans un plugin abandonné. Une migration révèle la dette accumulée. Elle ne la crée pas.

Cette checklist de migration e-commerce sert donc à préparer un inventaire exploitable, pas à remplir un tableur décoratif. L’objectif est simple: savoir ce qui doit être transféré, ce qui doit être nettoyé, ce qui doit être recréé manuellement et ce qui peut disparaître sans provoquer de catastrophe commerciale ou SEO.

1. Audit et nettoyage: l’art de ne pas transférer n’importe quoi

La première erreur consiste à considérer l’ancienne boutique comme une source de vérité. Elle ne l’est presque jamais. Au fil des années, elle a accumulé des produits retirés, des catégories sans contenu, des doublons, des comptes clients inactifs, des règles promotionnelles obsolètes et des extensions dont plus personne ne connaît le fonctionnement exact.

Copier tout l’existant vers la nouvelle plateforme ne constitue pas une stratégie de sauvegarde. C’est une manière très efficace de transporter les problèmes dans un environnement plus coûteux.

Avant de préparer une migration Shopify, WooCommerce ou toute autre solution, il faut établir un inventaire complet des objets présents dans l’ancien système:

• produits actifs, archivés, supprimés ou masqués;
• variantes et références SKU;
• catégories, collections, familles et attributs;
• images, documents techniques et contenus éditoriaux;
• comptes clients et historique de commandes;
• coupons, règles de prix et promotions récurrentes;
• modes de livraison et zones géographiques;
• taxes, devises et règles de facturation;
• commandes, remboursements, avoirs et statuts associés;
• comptes administrateurs, rôles et permissions;
• extensions, applications et connexions avec des outils tiers;
• URL indexables, fichiers sitemap et règles de traitement des robots.

Cette liste n’a rien de spectaculaire. C’est précisément pour cela qu’elle est souvent négligée. Les projets de transformation numérique aiment parler d’architecture cible, d’omnicanal et de personnalisation prédictive; ils oublient parfois de vérifier si la fiche produit principale contient encore la bonne image.

Le catalogue doit être trié avant l’export

Un audit catalogue permet de distinguer les éléments qui méritent une migration de ceux qui ne doivent pas encombrer la nouvelle base. Pour chaque produit, il faut au minimum examiner:

• son statut commercial réel;
• son niveau de stock ou sa disponibilité;
• ses ventes récentes;
• son trafic organique;
• ses backlinks éventuels;
• ses variantes encore vendues;
• sa présence dans des campagnes ou des flux produits;
• la qualité de ses descriptions et de ses attributs;
• les éventuels doublons avec un autre produit.

Une fiche produit obsolète peut pourtant conserver une valeur SEO. À l’inverse, un produit toujours présent dans le back-office peut n’avoir ni trafic, ni vente, ni intérêt pour le catalogue futur. Le statut administratif ne suffit donc pas à décider. Ce serait pratique. Ce serait surtout faux.

Il faut également repérer les contenus dupliqués: descriptions identiques pour plusieurs variantes, textes copiés entre catégories, titres générés automatiquement ou méta-descriptions héritées d’une ancienne structure. Une migration est un mauvais moment pour reproduire mécaniquement une incohérence, mais un excellent moment pour la supprimer.

Une migration réussie ne transfère pas tout. Elle transfère ce qui reste utile, traçable et exploitable.

La sauvegarde vient avant le nettoyage

Nettoyer ne signifie pas supprimer sans retour. La sauvegarde des données avant migration du site doit couvrir l’ensemble des informations nécessaires à une restauration ou à une vérification ultérieure. Elle doit être réalisée avant toute modification importante du catalogue, de la base clients ou des réglages techniques.

Conservez au minimum:

1. un export complet de la base de données;

2. un export des produits avec leurs variantes, références, prix et stocks;

3. les médias associés, notamment les images haute définition;

4. le fichier clients et les métadonnées disponibles;

5. l’historique des commandes et des transactions;

6. les règles de livraison, de taxe et de promotion;

7. la liste des URL actuelles;

8. les réglages SEO, les balises canoniques et les fichiers sitemap;

9. la configuration des applications et services connectés;

10. les journaux ou rapports utiles pour identifier les anomalies après la bascule.

Une sauvegarde dont personne ne connaît le format, l’emplacement ou la méthode de restauration n’est pas une sauvegarde opérationnelle. C’est un acte de foi avec un nom de fichier rassurant.

2. Cartographier les données produits et clients

L’export brut n’est pas encore un plan de migration. Il faut ensuite cartographier les données: identifier leur origine, leur destination, leur format et leur niveau de transformation nécessaire.

Cette cartographie constitue une partie essentielle du cahier des charges e-commerce. Elle permet de repérer les champs qui portent le même nom mais pas le même sens, les champs obligatoires dans la nouvelle solution et les données qui n’ont aucun équivalent direct.

Un champ appelé description peut contenir un texte commercial, du HTML, des informations techniques, des consignes de montage ou plusieurs de ces éléments mélangés. Un champ appelé prix peut désigner un tarif public, un tarif professionnel, un prix promotionnel ou un montant hors taxes. Le nom de la colonne ne garantit absolument rien. Le contexte métier, lui, compte beaucoup.

Le produit n’est pas une ligne de CSV

La structure produit mérite une attention particulière, surtout lorsque l’ancienne et la nouvelle plateforme ne modélisent pas les variantes de la même façon. Il faut distinguer clairement:

• le produit parent;
• les variantes;
• les attributs comme la taille, la couleur ou la capacité;
• les références SKU;
• les codes-barres ou identifiants externes;
• les prix par variante;
• les niveaux de stock;
• les poids et dimensions;
• les images principales et secondaires;
• les règles de disponibilité;
• les catégories et collections;
• les relations entre produits associés;
• les produits complémentaires ou de remplacement.

Une variante mal importée peut sembler anodine dans le back-office et produire une expérience désastreuse côté client: mauvaise image affichée, stock partagé alors qu’il devrait être séparé, référence absente dans le système logistique ou prix correspondant à une autre option. Le tunnel d’achat ne pardonne pas ce genre de détail. Il laisse simplement le client partir ailleurs.

Il faut aussi décider comment seront gérées les données éditoriales. Les descriptions longues, les caractéristiques techniques, les notices PDF et les arguments commerciaux ne doivent pas être rangés dans un même champ sous prétexte que l’ancien outil le permettait. La nouvelle plateforme devra pouvoir les afficher, les filtrer et les maintenir sans demander une opération de chirurgie à chaque mise à jour.

Le fichier client exige une définition précise

Le fichier clients ne se limite pas à une liste d’adresses e-mail. Il peut contenir plusieurs niveaux d’information:

• identité et coordonnées;
• adresses de facturation et de livraison;
• historique de commandes;
• dates de création et de dernière activité;
• groupes ou segments commerciaux;
• consentements marketing;
• préférences de communication;
• notes internes;
• métadonnées issues d’un programme de fidélité;
• identifiants utilisés par un outil de marketing automation.

Il faut séparer les données nécessaires au fonctionnement du compte de celles destinées à la segmentation commerciale. Les consentements ne sont pas de simples étiquettes marketing à recopier dans une colonne. Ils doivent conserver leur signification, leur statut et leur contexte d’utilisation.

L’historique de commandes doit également être considéré comme une donnée métier, pas seulement comme une archive. Les commandes peuvent être nécessaires au service client, à la comptabilité, à la gestion des retours ou au calcul de la valeur client. Si la nouvelle plateforme ne peut pas importer toute l’historique, il faut prévoir une solution d’accès séparée plutôt que de faire disparaître cette information dans un ancien export que personne ne consultera.

Tableau de cartographie à intégrer au projet

Une cartographie utile décrit la donnée et la décision associée. Un tableau peut prendre cette forme:

Ce tableau n’a pas vocation à impressionner la direction avec des colonnes colorées. Il sert à répondre à la question qui fâche: que devient exactement chaque donnée une fois la migration terminée?

3. Sécurité et passerelles de paiement: ce qui ne se transfère pas comme un catalogue

Les équipes préparent souvent minutieusement les produits et traitent la partie paiement à la fin, comme un réglage secondaire. C’est une très mauvaise idée. Un catalogue incomplet se corrige; une passerelle de paiement mal configurée bloque directement les ventes.

Les identifiants, clés secrètes et jetons liés aux prestataires de paiement ne sont pas nécessairement transférables automatiquement. Pour des raisons de sécurité, certaines informations confidentielles devront être reconfigurées manuellement sur la nouvelle plateforme. Il ne faut donc pas promettre une migration intégrale à partir d’un simple fichier CSV, surtout lorsqu’il est question de données d’authentification ou de tokens de paiement.

L’inventaire doit préciser, pour chaque moyen de paiement:

• le prestataire utilisé;
• l’environnement de production et celui de test;
• les identifiants de compte marchand;
• les clés publiques et privées;
• les URL de notification ou webhooks;
• les règles de capture et d’autorisation;
• la gestion des remboursements;
• les moyens de paiement proposés selon le pays;
• les paramètres antifraude;
• les règles de paiement différé ou fractionné;
• les procédures de rapprochement comptable.

Les numéros complets de carte bancaire ne sont évidemment pas une donnée à extraire pour la déplacer d’une plateforme à une autre. La logique correcte consiste à comprendre ce que le prestataire de paiement peut conserver, ce que la nouvelle intégration peut réutiliser et ce qui devra être recréé, avec éventuellement une nouvelle authentification côté client.

Tester le paiement avec des cas réels

Un test de paiement ne se limite pas à vérifier qu’un bouton affiche le mot « payer ». Il faut couvrir plusieurs scénarios:

1. paiement accepté avec une carte ou un moyen local;

2. paiement refusé;

3. authentification forte demandée;

4. commande interrompue puis reprise;

5. remboursement total;

6. remboursement partiel;

7. paiement différé ou en plusieurs fois;

8. commande avec coupon;

9. commande comprenant plusieurs taux de taxe;

10. notification reçue par l’outil de gestion ou le système logistique.

Il faut ensuite vérifier la cohérence entre la boutique, la passerelle, le système de gestion des commandes et les outils comptables. Une commande marquée comme payée sur le site mais absente du système de préparation n’est pas un petit défaut d’intégration. C’est une promesse faite au client sans mécanisme pour la tenir.

Les mêmes précautions concernent les solutions de livraison, les connecteurs ERP, les outils de marketing automation, les flux vers les places de marché et les applications de personnalisation. Chaque connexion doit être recensée, testée et attribuée à un responsable. Une intégration sans propriétaire devient rapidement une légende interne: tout le monde sait qu’elle existe, personne ne sait pourquoi.

4. Redirections 301: la partie invisible qui protège le trafic

Changer de plateforme e-commerce implique souvent de modifier la structure des URL. Les chemins produits peuvent évoluer, les catégories être renommées, les identifiants changer ou les paramètres être générés autrement. Pour les moteurs de recherche, une nouvelle adresse n’est pas la continuation naturelle de l’ancienne. Sans signal explicite, elle ressemble à une page différente, voire à une page disparue.

La redirection 301 permanente sert à transmettre les anciennes URL vers leurs nouvelles destinations et à limiter la perte d’autorité SEO. Elle permet également d’éviter que les utilisateurs arrivent sur des erreurs 404 depuis les résultats de recherche, les favoris ou les liens externes.

La règle la plus simple est aussi la plus souvent mal appliquée: chaque ancienne URL utile doit être associée à une nouvelle URL pertinente. Pas à la page d’accueil par défaut. Pas à une catégorie vaguement proche. Pas à une page fourre-tout destinée à faire disparaître l’erreur dans un rapport.

Construire la matrice des URL

La matrice de redirection doit être préparée avant la mise en production. Elle rassemble notamment:

• l’ancienne URL;
• le type de page;
• son statut actuel;
• la nouvelle URL cible;
• la raison du changement;
• la priorité SEO ou commerciale;
• le responsable de validation;
• le statut du test.

Il faut croiser plusieurs sources pour constituer cette liste: crawl du site, données de recherche organique, journaux serveur si disponibles, liens internes, campagnes publicitaires, flux produits et anciennes communications commerciales. Se limiter aux URL encore présentes dans le menu du site revient à ignorer une grande partie de la surface réelle d’un commerce en ligne.

Les fiches produits supprimées posent un cas particulier. Si un produit possède un remplaçant clairement identifié, la redirection peut pointer vers celui-ci. Si aucune alternative n’existe, une catégorie pertinente peut être préférable. Dans certains cas, conserver une page informative avec un statut clair est plus honnête qu’une redirection artificielle. Le choix dépend du contenu, de l’intention de recherche et de la valeur de l’ancienne page.

Éviter les chaînes et les redirections absurdes

Une ancienne URL ne doit pas être redirigée vers une URL intermédiaire qui redirige elle-même vers une troisième adresse. Ces chaînes compliquent le parcours, ralentissent les robots et rendent le diagnostic plus pénible. La cible doit être l’URL finale.

Il faut aussi surveiller:

• les boucles de redirection;
• les redirections vers des pages non pertinentes;
• les anciennes versions HTTP et HTTPS;
• les variantes avec ou sans slash final;
• les paramètres de suivi;
• les URL avec majuscules ou caractères encodés;
• les pages de pagination;
• les anciennes URL de catégories;
• les fichiers et médias qui continuent d’attirer du trafic.

Une migration sans plan de redirections 301 ne change pas seulement les URL. Elle change les conditions dans lesquelles les clients et les moteurs peuvent retrouver l’entreprise.

Après la bascule, le sitemap doit être soumis à nouveau avec les nouvelles adresses. Le suivi du trafic SEO et des erreurs doit être maintenu pendant deux à quatre semaines au minimum, car certaines anomalies n’apparaissent qu’après le passage des robots ou la reprise des campagnes.

5. Environnement de recette et protocole de bascule

La migration ne doit jamais être testée directement sur le site en production. Un environnement de recette, ou staging, permet de vérifier le fonctionnement de la nouvelle boutique avant qu’elle ne reçoive de vrais clients, de vraies commandes et les conséquences très réelles d’une configuration incomplète.

L’environnement de recette doit reproduire autant que possible:

• la structure du catalogue;
• les règles de prix;
• les taxes;
• les modes de livraison;
• les comptes et rôles internes;
• les principales intégrations;
• les modèles d’e-mails;
• le tunnel d’achat;
• les règles de stock;
• les redirections;
• les paramètres SEO;
• les dispositifs de suivi analytique.

Il ne s’agit pas de chercher une perfection théorique. Il s’agit d’exposer les erreurs avant qu’elles ne deviennent publiques. Le staging n’a pas besoin d’être joli dans une présentation commerciale; il doit être suffisamment proche de la production pour rendre les tests crédibles.

Organiser les tests par parcours, pas par écran

Tester page par page donne souvent une illusion de contrôle. Une fiche produit peut fonctionner seule et échouer dès qu’elle est combinée à une promotion, une variante, un mode de livraison ou un paiement spécifique. Il faut donc tester des parcours complets.

Un protocole cohérent couvre par exemple:

1. recherche d’un produit;

2. filtrage par attribut;

3. consultation d’une fiche avec variantes;

4. ajout au panier;

5. modification d’une quantité;

6. application d’un coupon;

7. création ou reconnexion d’un compte;

8. saisie d’une adresse différente de l’adresse de facturation;

9. sélection du transport;

10. paiement;

11. confirmation de commande;

12. transmission au système logistique;

13. envoi des e-mails;

14. modification du statut;

15. remboursement ou annulation.

Les tests doivent être réalisés sur ordinateur et mobile, avec plusieurs navigateurs et plusieurs configurations de compte. Le m-commerce ne mérite pas un traitement de seconde zone: un champ mal dimensionné, une erreur de validation invisible ou un clavier qui recouvre le bouton de paiement suffit à augmenter la friction au pire endroit du parcours.

Il faut également vérifier la charge cognitive du tunnel. Les messages d’erreur doivent expliquer le problème et indiquer comment le résoudre. Les étapes inutiles doivent disparaître. Les options de livraison ne doivent pas être présentées comme une énigme administrative. Nous avons collectivement réussi à transformer un achat en ligne en parcours d’obstacles, puis à appeler cela de la personnalisation. Il est temps de relire les écrans avec un peu de lucidité.

Préparer la bascule comme une opération contrôlée

Le jour du changement, les responsabilités doivent être explicites. Qui bloque les modifications sur l’ancien site? Qui réalise l’export final? Qui importe les dernières commandes? Qui active les redirections? Qui valide les paiements? Qui surveille les erreurs? Une migration sans responsable identifié repose sur une mécanique familière: chacun pense que quelqu’un d’autre vérifiera.

Le protocole de bascule doit prévoir:

• une fenêtre d’intervention clairement définie;
• une sauvegarde finale;
• un gel temporaire des modifications de catalogue et de configuration;
• l’export des dernières commandes et des nouveaux clients;
• la vérification des stocks;
• l’activation des DNS ou du nouveau routage;
• la publication des redirections 301;
• la vérification du certificat et du protocole HTTPS;
• les tests de commande en production;
• la surveillance des erreurs applicatives;
• la vérification du sitemap et des fichiers robots;
• un plan de retour à l’ancienne version si une anomalie critique apparaît.

Il n’est pas nécessaire de dramatiser chaque migration. En revanche, il faut accepter qu’une bascule comporte des risques et qu’un plan de retour soit plus utile qu’un discours optimiste. Promettre une migration instantanée sans période de recette revient à confondre vitesse et absence de préparation.

La checklist finale, celle qui évite les mauvaises surprises

Avant de considérer la migration comme terminée, nous devons pouvoir répondre clairement aux points suivants:

• La base complète a-t-elle été sauvegardée avant le nettoyage?
• Les produits actifs, les variantes, les SKU, les prix et les stocks ont-ils été cartographiés?
• Les images sont-elles associées aux bons produits et aux bonnes variantes?
• Les catégories et collections ont-elles une structure cohérente dans la nouvelle plateforme?
• Les fiches obsolètes, doublons et contenus inutiles ont-ils été identifiés?
• Les clients, commandes et consentements sont-ils traités selon des règles distinctes?
• Les mots de passe et les données sensibles ont-ils fait l’objet d’un traitement spécifique?
• Les identifiants des passerelles de paiement ont-ils été reconfigurés manuellement lorsque nécessaire?
• Les remboursements et notifications ont-ils été testés?
• Les applications tierces et flux logistiques ont-ils un responsable identifié?
• Les anciennes URL importantes figurent-elles dans une matrice de redirections 301?
• Les chaînes, boucles et destinations incohérentes ont-elles été contrôlées?
• Le nouveau sitemap a-t-il été généré et soumis après la bascule?
• Le tunnel d’achat a-t-il été testé sur mobile et sur ordinateur?
• La surveillance du trafic, des commandes et des erreurs est-elle prévue pendant deux à quatre semaines?
• Le plan de retour est-il documenté, compréhensible et techniquement applicable?

Cette liste ne remplace pas un audit technique. Elle donne au projet une ossature concrète et permet de distinguer une migration préparée d’un simple changement de thème accompagné d’un import massif.

Une migration e-commerce est d’abord un travail de clarification

Le choix de la plateforme attire toute l’attention: fonctionnalités Shopify, flexibilité de WooCommerce, connecteurs, applications, moyens de paiement, coûts d’exploitation. Ces sujets comptent, mais ils ne corrigent pas un catalogue incohérent ni une architecture d’URL abandonnée.

Les étapes pour changer de plateforme e-commerce commencent bien avant l’installation de la nouvelle solution. Elles commencent par la définition de ce que l’entreprise sait réellement de ses données, de ses clients et de ses flux de vente. Une sauvegarde complète, une cartographie champ par champ, un nettoyage raisonné, une stratégie de redirections 301 et une recette sérieuse forment la base du projet.

Le reste relève de l’outillage. Et l’outillage, contrairement aux tendances du moment, ne pense pas à notre place.