WebEngine

E-commerce

Migration de boutique

Changer de plateforme sans perdre ni commandes, ni clients, ni référencement.

MigrationSEO préservé

Une migration de boutique en ligne, ce n’est pas un export-import de fichier CSV un dimanche soir. C’est une opération où chaque erreur se paie cash : commandes perdues, comptes clients qui ne se connectent plus, positions Google qui s’effondrent en quelques jours. Je le vois régulièrement quand on me contacte après coup, pour réparer une migration faite trop vite.

Pourquoi une migration de boutique tourne mal

Le scénario est presque toujours le même. Une agence ou un prestataire installe la nouvelle plateforme, importe le catalogue tant bien que mal, bascule le DNS un vendredi soir — et le lundi, le client découvre que la moitié des fiches produits a perdu ses descriptions, que les avis clients ont disparu, que les URLs ont changé sans redirection et que le trafic Google chute de 40 % en une semaine. Les comptes clients ne retrouvent plus leur mot de passe parce que le hachage n’était pas compatible d’une plateforme à l’autre. L’historique des commandes n’est plus visible côté client, ce qui génère des dizaines de tickets support inutiles.

Rien de tout ça n’est une fatalité technique : ce sont des étapes qu’on a sautées parce qu’elles prennent du temps et ne se voient pas sur une maquette. Une migration réussie se juge à ce qui ne change pas pour le visiteur et le client existant : mêmes URLs ou redirections propres, mêmes comptes, même historique, mêmes positions dans les résultats de recherche. Le travail visible — le nouveau design, la nouvelle plateforme — n’est souvent que la partie la plus simple du projet.

Les raisons qui justifient de changer de plateforme

Je ne pousse jamais une migration par principe. Il y a des raisons concrètes qui la justifient, et d’autres qui ne suffisent pas. Changer de plateforme a du sens quand la boutique actuelle bloque la croissance : une installation WooCommerce qui s’effondre sous la charge dès qu’une campagne publicitaire fonctionne, un back-office PrestaShop devenu impossible à maintenir après des années de modules empilés par des prestataires différents, ou au contraire une boutique Shopify dont les frais et les limites de personnalisation freinent une marque qui veut reprendre la main sur son code.

Dans l’autre sens, je vois aussi des clients qui quittent Shopify pour PrestaShop ou une solution open source quand ils veulent arrêter de payer un abonnement mensuel proportionnel au chiffre d’affaires, ou intégrer des connecteurs métier trop spécifiques pour l’écosystème d’applications Shopify. D’autres migrent de PrestaShop vers WooCommerce parce que leur équipe interne connaît WordPress et veut pouvoir intervenir seule sur le contenu, sans dépendre d’un développeur pour chaque modification. Dans tous les cas, la question à se poser avant de me contacter n’est pas « quelle plateforme est la meilleure », mais « qu’est-ce que la plateforme actuelle m’empêche de faire aujourd’hui ». Si la réponse est claire et chiffrable, la migration a un vrai retour sur investissement.

Ma méthode pour migrer sans perdre de commandes

Une migration se prépare avant de toucher au code. Je commence toujours par un audit complet de la boutique existante : structure du catalogue, champs personnalisés, moyens de paiement actifs, connecteurs ERP ou comptables, volume de commandes et de comptes clients à reprendre. Cet audit donne le périmètre réel du projet, souvent plus large que ce que le client imaginait au départ.


Audit et cadrage

Je liste tout ce qui doit survivre à la migration : catalogue, clients, commandes, avis, redirections, tracking analytics et pixels publicitaires.


Mapping des données

Je fais correspondre les structures entre l’ancienne et la nouvelle plateforme avant tout import, pour éviter les pertes de champs ou de variantes produit.


SEO et redirections 301

Chaque URL indexée est redirigée vers son équivalent, pour ne pas repartir de zéro dans les résultats de recherche.


Recette avant bascule

Je teste la nouvelle boutique en environnement séparé — paiement, comptes, emails transactionnels — avant de couper le DNS.


La bascule elle-même se fait à un moment creux, avec une fenêtre de maintenance annoncée si le volume de commandes le justifie, pour éviter de perdre des commandes passées pendant le transfert des dernières données.

Ce qui se perd si la migration est bâclée

Certains éléments ne se recréent pas après coup. Les avis clients accumulés sur des années pèsent sur la conversion et sur le référencement local ; s’ils ne sont pas migrés, il faut recommencer une collecte à zéro. Les comptes clients avec mot de passe posent un problème technique réel : la plupart des plateformes ne stockent pas les mots de passe en clair, donc un import direct ne fonctionne pas — il faut soit forcer une réinitialisation à la première connexion, soit migrer le hachage si les deux systèmes sont compatibles. L’historique de commandes doit rester accessible au client, sans quoi le service après-vente devient impossible à assurer correctement.

Le tracking analytics et les pixels publicitaires (Google Ads, Meta) sont souvent oubliés lors d’une migration : sans configuration identique dès le premier jour, vous perdez plusieurs semaines de données de conversion et l’optimisation de vos campagnes en cours repart à zéro.

Le référencement mérite une vigilance particulière : au-delà des redirections, il faut surveiller le positionnement pendant les semaines qui suivent la bascule, corriger rapidement les erreurs d’exploration remontées par la Search Console, et vérifier que le nouveau site ne génère pas de contenu dupliqué avec l’ancien s’il reste temporairement accessible.

Les cas où je vous déconseille la migration

Une migration coûte du temps et de l’argent, et elle n’est pas toujours la bonne réponse. Si votre plateforme actuelle fonctionne mais que le vrai problème est la vitesse de chargement ou le référencement, une optimisation ciblée coûte moins cher et règle souvent le problème sans risque de casse. Je le dis clairement plutôt que de vendre une refonte inutile.

Je déconseille aussi la migration quand le catalogue est petit (moins d’une cinquantaine de produits) et que la plateforme actuelle n’est pas réellement en cause dans les difficultés rencontrées : le retour sur investissement d’un chantier de migration ne se justifie pas face à quelques ajustements de configuration. De même, si l’équipe interne n’est pas prête à apprendre un nouveau back-office ou si le budget disponible impose de sauter les étapes de recette et de tests, mieux vaut reporter le projet plutôt que le mener dans des conditions qui reproduiront exactement les problèmes décrits plus haut. Une migration bâclée coûte toujours plus cher à corriger ensuite qu’à bien faire dès le départ.

Vous envisagez de changer de plateforme e-commerce ?

Décrivez-moi votre boutique actuelle et ce qui vous pousse à en changer : je vous dis si une migration est justifiée avant de chiffrer quoi que ce soit.

Demander un devis

Combien coûte une migration de boutique

Le prix dépend directement du volume à reprendre et du nombre de connecteurs à reconfigurer : catalogue de quelques dizaines ou de plusieurs milliers de références, historique de commandes à importer ou non, intégrations avec un ERP, un logiciel de comptabilité, un outil de gestion des stocks ou une solution de paiement spécifique. Un catalogue simple avec peu de personnalisations se migre plus vite qu’une boutique avec des variantes produit complexes, des tarifs par groupe de clients ou des modules métier développés sur mesure.

Migration type : ≈ 3 000 € HTselon catalogue et historique · petite boutique : souvent bien moins, décrivez-la au devis. À reprendre et les connecteurs à reconfigurertous les tarifs →

Ce montant correspond à une migration avec audit, mapping des données, redirections SEO et recette avant bascule — pas à un simple export-import sans vérification. Si le projet inclut aussi une refonte visuelle complète plutôt qu’un simple changement de plateforme, le budget se rapproche de celui d’une boutique e-commerce construite de zéro. Je fournis un chiffrage précis après avoir vu le back-office actuel, pas avant.

Questions fréquentes sur la migration de boutique

Questions fréquentes


Combien de temps dure une migration de boutique ?

Pour un catalogue de taille moyenne avec quelques connecteurs, comptez entre trois et six semaines : audit, mapping des données, développement, recette, puis bascule. Un catalogue volumineux ou des intégrations complexes rallongent ce délai.


Est-ce que je perds mon référencement en migrant de plateforme ?

Pas si les redirections 301 sont posées correctement pour chaque URL indexée et que la structure du site reste cohérente. Une baisse temporaire de quelques jours est normale pendant que Google réindexe, mais elle ne doit pas durer si le travail est fait proprement.


Peut-on migrer sans interrompre les ventes ?

Oui dans la majorité des cas, en préparant la nouvelle boutique en environnement séparé et en ne coupant l’ancienne qu’au moment de la bascule finale. Une courte fenêtre de maintenance reste parfois nécessaire pour synchroniser les toutes dernières commandes.


Que devient l'historique des commandes de mes clients ?

Il peut être importé dans la nouvelle plateforme si elle le permet, ou conservé en lecture seule sur l’ancien système pour le service après-vente. Je définis cette stratégie avec vous dès l’audit, en fonction de vos obligations de conservation des données.


Faut-il migrer aussi mes avis clients ?

C’est recommandé si vous en avez accumulé un volume significatif : ils pèsent sur la conversion et sur le référencement. La faisabilité dépend de la plateforme d’avis utilisée et de sa compatibilité avec la nouvelle boutique.


Quelle plateforme choisir pour ma nouvelle boutique ?

Cela dépend de votre volume de commandes, de votre besoin d’autonomie sur le contenu et de votre budget de fonctionnement. Je peux comparer avec vous les options concrètes, notamment WooCommerce, PrestaShop et Shopify, avant de démarrer le chiffrage.