Guide de décision
Changer de plateforme e-commerce sans perdre le trafic.
Une refonte de plateforme e-commerce se décide sur deux questions. Est-ce vraiment la plateforme qui plafonne le chiffre d'affaires, et comment déplacer une boutique qui vend pendant qu'on la reconstruit. La réponse à la seconde tient en grande partie dans un fichier que les plannings placent trop tard : le plan de redirection.
Le vrai problème est-il la plateforme.
Une bonne part des migrations que nous auditons ont été lancées pour un symptôme venu d'ailleurs. Le trafic baisse, la conversion stagne, et le projet qui arrive en comité s'appelle « changer de plateforme ». Le nouveau socle sort douze mois plus tard avec le même catalogue mal renseigné et le même transporteur en retard.
Séparez les couches avant d'écrire le cahier des charges. Un défaut de contenu se voit sur les pages catégorie et les fiches produit, et il se corrige en place. Un défaut de recherche interne se mesure sur le taux de requêtes sans résultat. Restent les blocages qui viennent bien du socle.
- Chaque évolution passe par un devis d'éditeur et un trimestre. Ajouter un mode de retrait devient un projet.
- La plateforme ralentit ou tombe pendant les pics, alors que les soldes et les fêtes sont exactement le moment où elle doit tenir.
- L'éditeur a annoncé une fin de support, et le calendrier vous est désormais imposé.
- Le modèle de données ne suit plus le commerce réel : plusieurs pays, plusieurs devises, du B2B à côté du B2C, des variantes irreprésentables.
- Le magasin et le site ne partagent ni le stock ni la commande, et la couture entre les deux est impossible à écrire sur ce socle.
Les signaux qui viennent d'ailleurs.
- Le trafic organique décroche. Regardez d'abord les pages catégorie, les facettes indexées et la qualité des fiches produit. Cette lecture est détaillée sur la page référencement IA.
- Le site est daté visuellement. Une refonte graphique se mène sur le socle existant, sans toucher aux URLs.
- Les acheteurs ne trouvent pas les produits. La recherche interne est un composant, et elle se remplace seule.
- La direction générale veut du headless. Une architecture produit un résultat seulement quand une équipe l'exploite.
Le risque numéro un, la visibilité de recherche.
Voici le mécanisme, dans l'ordre où il se produit. Un moteur associe un classement à une adresse précise. Le jour de la bascule, les URLs changent de forme, souvent parce que le nouveau socle impose sa structure de catégories. Les anciennes adresses répondent en erreur, les nouvelles repartent sans historique, et le temps que le moteur explore puis réévalue l'ensemble, les positions se perdent.
Le remède est documenté et gratuit. Google recommande les redirections permanentes côté serveur, 301 ou 308, et écrit noir sur blanc qu'elles n'entraînent pas de perte de PageRank. La même documentation demande une balise canonique autoréférente sur chaque nouvelle URL, la soumission du nouveau sitemap dans la Search Console, et réserve l'outil de changement d'adresse aux vrais changements de domaine (Google Search Central, « Site moves with URL changes », consulté le 28 août 2026).
Le même texte donne la mauvaise nouvelle. Pour un site de taille moyenne, quelques semaines ou plus peuvent s'écouler avant que les nouvelles adresses remplacent les anciennes dans les résultats. Une erreur de redirection se voit donc trois semaines après le lancement, quand la courbe descend et que l'équipe fête encore la mise en ligne. Deux pertes voisines passent inaperçues : les canoniques qui disparaissent avec les anciens gabarits, si bien qu'un site à facettes produit des milliers de variantes de la même page, et le temps de chargement qui se dégrade sous le poids du nouveau front.
Ce que nous faisons : l'export de douze mois d'URLs ayant reçu au moins une impression, une association une pour une, aucune chaîne de redirections, le schéma d'URL gelé avant le design, la carte testée sur la préproduction, puis une exploration complète le lendemain de la bascule. Notre étude publiée sur Lagrace montre ce que la visibilité de recherche vaut pour une PME.
Monolithe, headless, composable.
Le choix se juge sur l'équipe qui exploitera le système une fois la démonstration de l'éditeur oubliée. Un socle unifié réunit catalogue, vitrine et paiement dans un seul système, et une équipe compacte le fait vivre avec un intégrateur. Le headless sépare la vitrine du moteur de commerce, ce qui suppose une équipe front permanente, et une facture d'agence à chaque changement de gabarit quand cette équipe manque. Le composable assemble des briques spécialisées, et il demande quelqu'un qui possède les contrats et sait quelle brique a lâché à trois heures du matin.
Sur les chiffres de marché, prudence. La MACH Alliance, dans son rapport annuel du 14 janvier 2025, rapporte que neuf organisations sur dix ayant déployé une brique MACH estiment le retour sur investissement atteint ou dépassé. L'échantillon compte 561 décideurs informatiques de niveau directeur et au-dessus, dans des entreprises d'au moins 5 000 salariés, sur six pays dont la France. La réserve qui compte : l'alliance regroupe les éditeurs qui vendent cette architecture, et une PME de quarante personnes ressemble très peu à cet échantillon.
La séquence d'une refonte qui tient.
- Le gel du périmètre. Écrivez ce qui reste identique avec autant de soin que ce qui change. Un projet de refonte absorbe volontiers une refonte graphique et une réorganisation, et le jour où quelque chose casse plus personne ne sait laquelle des trois est en cause.
- La reprise de données. Le socle vide d'abord, puis le catalogue comparé page à page avec l'ancien site. Comptes clients, paniers, historiques et abonnements passent en dernier. Nettoyez les données avant, en place.
- Le plan de redirection. Un livrable, un responsable, une date, une recette. Il se prépare pendant la construction et se pose avant la mise en ligne.
- La bascule. Répétée jusqu'à devenir une formalité, avec un retour arrière prêt à chaque étape, et jamais dans les trois mois qui précèdent votre pic de vente.
- Les deux semaines qui suivent. On surveille la couverture d'indexation, les erreurs 404, le temps de réponse des pages catégorie et les paiements refusés. Beaucoup de propositions s'arrêtent à la mise en ligne. Nous restons sur cette fenêtre, parce que les erreurs de reprise y apparaissent.
Ce que nous avons déjà fait.
Nous avons mené la re-plateformisation de plus de 700 pages e-commerce pour une marque mondiale d'outdoor. Elle reste anonyme tant que l'accord de publication n'est pas signé, et nous préférons cette règle à une liste de logos. Ce qui se transmet, c'est la discipline : l'inventaire des URLs, la parité de structure, la bascule répétée, la surveillance des jours qui suivent.
La construction et la couture entre le magasin et le site se décrivent sur la page agence e-commerce. Pour un chantier plus large, la lecture d'ensemble est sur le conseil en transformation digitale.
Des questions, des réponses franches.
Combien de temps dure une refonte de plateforme e-commerce ?
Nous ne donnons pas de durée type. Elle se calcule sur deux compteurs que les plannings regardent trop tard : le nombre d'URLs qui reçoivent des impressions dans la Search Console, et le nombre d'intégrations qui touchent l'argent et le stock. Un catalogue avec un paiement et un transporteur, c'est un projet. Le même catalogue avec un ERP, un PIM et un programme de fidélité, c'en est un autre.
Comment ne pas perdre le référencement pendant une migration ?
Traitez le plan de redirection comme un livrable, avec un responsable nommé et une date, au même titre que la page panier. Exportez douze mois d'URLs ayant reçu au moins une impression, associez chacune à sa nouvelle adresse, posez les redirections avant la mise en ligne. Google recommande les redirections permanentes côté serveur, 301 ou 308, et indique qu'elles n'entraînent pas de perte de PageRank (Google Search Central, « Site moves with URL changes », consulté le 28 août 2026).
Faut-il tout migrer d'un coup ?
Rarement, quand le site vend déjà. Une bascule unique retire les deux choses qui sauvent une migration, l'état intermédiaire et le retour arrière, si bien que le premier incident sérieux se joue en direct sur des commandes réelles. Découpez : le socle vide, le catalogue, les redirections, les intégrations une par une, les comptes clients en dernier.
Le headless est-il fait pour nous ?
Posez la question à l'envers : qui écrira le front l'année prochaine, en interne, à temps plein. Le headless donne de la liberté à une équipe front permanente et ajoute une surface d'intégration à entretenir. Si la réponse est « une agence, au coup par coup », un socle unifié moderne coûtera moins cher à faire vivre. Nous construisons les deux et nous tranchons après le diagnostic.
Comment mesurer le succès d'une refonte ?
Écrivez les repères pendant que l'ancien site tourne encore, ils deviennent votre point de comparaison. Trois familles suffisent : la visibilité (impressions, clics, pages indexées), le commerce (ajout au panier, paiement abouti, panier moyen), l'exploitation (temps de réponse, erreurs de paiement). Si un seul chiffre doit trancher, prenez le chiffre d'affaires issu de la recherche organique sur quatre semaines glissantes.
Quand vaut-il mieux renoncer à changer de plateforme ?
Quand personne ne sait nommer le chiffre que la refonte débloque. Quand le blocage vient de la façon dont l'entreprise décide et livre, car un nouveau socle hérite de l'ancienne façon de travailler. Quand vous êtes à trois mois de votre pic de vente. Et quand aucune personne n'est désignée pour exploiter le système en ligne. Clarifiez ces quatre points, et le projet qui allait déraper devient un projet qui sort.
Passons votre plan de migration en revue.
Apportez le projet tel qu'il est, même à l'état de note. Trente minutes suffisent pour dire si le blocage vient bien de la plateforme, et pour repérer le poste que le planning sous-estime.