Refonte et migration e-commerce à Paris

Catalogue, clients, commandes, contenus, URL, règles de prix, comptes, avis et paramétrages liés au paiement, à la livraison et à la fiscalité.

L’inventaire se fait avant toute chose et par entité, avec son volume : combien de références actives et inactives, combien de clients, combien de commandes et sur quelle profondeur d’historique. Ce dernier point se décide plutôt qu’il ne se subit — migrer dix ans de commandes alourdit la base sans servir personne ; trois ans couvrent la garantie et la comptabilité courante, et les archives restent consultables ailleurs.

Ce qu’on oublie régulièrement : les paramètres fiscaux par pays, les grilles de frais de port avec leurs seuils, les codes promotionnels encore valides, les avis clients quand ils sont hébergés dans la boutique, et les redirections déjà en place sur l’ancien site — qui doivent être enchaînées sans créer de boucle.

Ce qui ne se migre jamais : les mots de passe en clair s’ils existent, qui doivent être réinitialisés, et les modules qui n’ont pas d’équivalent sur le nouveau socle. La liste de ces derniers est établie avant la décision de migrer.

Oui avec un plan de redirections complet, la conservation des contenus utiles, la maîtrise des URL et la surveillance de l’indexation après la bascule.

La contrainte propre à une boutique est le volume : mille pages produit et deux cents pages de rayon font mille deux cents correspondances à établir. Elles ne s’écrivent pas à la main mais par correspondance de références — la règle transforme l’ancienne adresse en nouvelle à partir de l’identifiant produit, et seules les exceptions sont traitées une par une. L’export de l’ancien site et celui du nouveau sont comparés ligne à ligne, et le nombre d’adresses sans destination doit être zéro avant la bascule.

Les pages de rayon méritent une attention particulière parce qu’elles concentrent le trafic de recherche. Une refonte qui réorganise l’arborescence doit dire, pour chaque ancien rayon, quel nouveau rayon le remplace — et accepter parfois de conserver une catégorie qui n’avait plus de sens interne mais qui recevait des visites.

Après la bascule, la baisse est fréquente pendant deux à quatre semaines. Au-delà de six, il y a une cause à trouver.

Les commandes non terminées, les retours, les remboursements et les états intermédiaires sont analysés pour éviter les ruptures de traitement pendant la transition.

La règle la plus simple est aussi la plus sûre : on choisit une date de bascule, les commandes antérieures restent traitées sur l’ancien système jusqu’à leur terme, et les nouvelles partent sur le nouveau. Cela demande de garder l’ancien back-office accessible en lecture et en modification pendant quelques semaines, ce qui est presque toujours possible.

L’alternative — migrer les commandes en cours avec leur état — est nécessaire quand les délais de traitement sont longs. Elle demande une correspondance des statuts, et c’est là que les erreurs arrivent : un statut « en préparation » qui devient « en attente de paiement » déclenche un courriel de relance à un client qui a déjà payé. Nous désactivons donc les notifications automatiques pendant l’import.

Les retours et remboursements en cours sont listés nommément avant la bascule et suivis à la main. Ils sont peu nombreux et leur perte fait un litige.

Une courte fenêtre est parfois nécessaire. Elle est planifiée sur une période de faible activité, avec un gel des mises à jour de catalogue et un retour arrière possible.

Dans la plupart des cas, la coupure réelle se compte en dizaines de minutes : le temps du dernier import différentiel et de la bascule DNS, à condition d’avoir abaissé la durée de vie de l’enregistrement quelques jours avant. Sans cette précaution, la propagation étale la transition sur plusieurs heures pendant lesquelles vos clients voient l’une ou l’autre boutique — et peuvent commander sur celle qui va disparaître.

La fenêtre est choisie d’après vos propres données : le créneau de plus faible chiffre d’affaires de la semaine, généralement une nuit en milieu de semaine. Nous regardons la courbe plutôt que d’appliquer une règle générale.

Le gel du catalogue commence vingt-quatre à quarante-huit heures avant : toute modification de prix ou de stock faite sur l’ancien système après le dernier import serait perdue. Cette date est communiquée aux personnes concernées, pas seulement au chef de projet.

Par des comparaisons de volumes, des contrôles d’échantillons, des tests de commandes réelles et une vérification des règles de prix et de fiscalité.

Les contrôles se font à trois niveaux. Les volumes d’abord : nombre de références par rayon, nombre de clients, nombre de commandes par année, comparés à l’export d’origine. Un écart supérieur à un pour cent doit être expliqué avant de continuer.

Les échantillons ensuite : une trentaine de références choisies pour couvrir les cas difficiles — produit à déclinaisons multiples, produit en promotion, produit à prix négocié, produit hors taxe, produit volumineux avec frais de port spécifiques. Chacune est comparée fiche à fiche.

Et les commandes réelles enfin : au moins une commande complète payée, expédiée et remboursée sur le nouveau système, avec vérification du montant, de la TVA, des frais de port et de l’écriture comptable. C’est le seul test qui valide la chaîne entière.

Les données d’origine sont conservées intactes pendant plusieurs mois. Une migration dont on ne peut pas repartir n’est pas une migration.

Selon la méthode de chiffrement utilisée, une réinitialisation peut être nécessaire. La procédure est alors préparée et communiquée aux clients.

Le cas favorable : l’ancien système utilise un algorithme reconnu et le nouveau sait le lire. Les empreintes sont transférées telles quelles, les clients se connectent comme avant, et leur mot de passe est réécrit au format courant à la première connexion. Aucune communication n’est nécessaire.

Le cas défavorable : l’algorithme est obsolète ou propriétaire. Il faut alors une réinitialisation, et c’est un moment sensible — un courriel de masse demandant de changer son mot de passe ressemble exactement à une tentative d’hameçonnage. Nous préparons donc le message avec vous, nous l’envoyons depuis votre domaine authentifié, nous l’annonçons aussi sur la boutique, et nous conservons la possibilité de se connecter par un lien à usage unique pour ceux qui ne l’ont pas lu.

Dans tous les cas, des mots de passe trouvés en clair dans une base ancienne ne sont jamais réimportés : ils sont réinitialisés, et l’incident est documenté.

Avant la bascule, à partir de l’inventaire des URL et des correspondances décidées, avec des tests sur un environnement de préparation.

Le calendrier qui fonctionne : l’inventaire des adresses existantes dès le début du projet, à partir de l’export du site et des données de recherche des douze derniers mois ; la table de correspondance construite pendant l’intégration ; les tests une semaine avant la bascule sur l’environnement de préparation, en appelant chaque ancienne adresse et en vérifiant le code de réponse et la destination.

Ce test est automatisable et il doit l’être : mille deux cents vérifications manuelles ne se font pas. Le rapport liste les adresses sans destination, celles qui aboutissent à une erreur, et les chaînes de plus d’un saut — une redirection qui pointe vers une autre redirection perd du signal et ralentit l’exploration.

Après la bascule, la surveillance des pages introuvables pendant quarante-huit heures attrape ce que l’inventaire avait manqué, notamment les adresses jamais visitées par un moteur mais présentes dans des liens externes.

Quatre à huit semaines permettent de suivre l’indexation, les erreurs, les parcours d’achat et les performances avant de conclure sur les résultats.

Le suivi se lit à des rythmes différents selon l’indicateur. Les erreurs techniques et les paniers abandonnés au paiement se regardent quotidiennement pendant la première semaine : une anomalie de transaction coûte immédiatement. L’exploration et l’indexation se suivent hebdomadairement dans les outils pour webmasters. Le chiffre d’affaires comparé à l’année précédente ne devient interprétable qu’à partir de la quatrième semaine, et il faut le corriger de la saisonnalité.

Deux pièges symétriques. Conclure trop tôt à l’échec parce que le trafic baisse pendant la réexploration, et annuler des choix corrects. Ou conclure trop tôt au succès parce que les premiers jours profitent d’un effet de nouveauté et d’une communication.

Nous remettons un point à quatre semaines et un à huit, avec les chiffres et ce qu’ils permettent de dire. Au-delà de huit semaines, une baisse persistante n’est plus une transition.