Une refonte PrestaShop se décide sur des faits techniques, pas sur une lassitude esthétique
Le dirigeant qui nous appelle au sujet de sa boutique PrestaShop commence rarement par la vraie raison. Il parle d'un site qui « fait daté », d'un concurrent dont les fiches produit sont plus jolies, d'une envie de renouveau avant la saison haute. Puis, au fil de la conversation, les faits arrivent : le prestataire d'origine ne répond plus depuis deux ans, l'hébergeur a annoncé la fin du support d'une version de PHP, le module de transporteur refuse de générer les étiquettes depuis la dernière mise à jour, et la personne qui saisit les produits perd une heure par jour dans un back-office qui met huit secondes à afficher une liste. Ces éléments-là ne se voient pas depuis la page d'accueil, et ce sont pourtant eux qui commandent la décision. Une refonte de boutique en ligne est d'abord une opération d'ingénierie sur un actif qui produit du chiffre d'affaires tous les jours, y compris pendant les travaux ; le graphisme n'en est qu'une couche, et souvent pas la plus coûteuse.
Cette page s'adresse à un décideur qui n'écrit pas de code et qui doit pourtant arbitrer. Vous n'avez pas besoin de savoir ce qu'est un service container ou une surcharge de template pour trancher correctement : vous avez besoin de comprendre quelles sont les deux ou trois questions structurantes, ce que chaque réponse engage en argent, en délai et en risque, et à quels signaux reconnaître qu'un projet part de travers. Le reste relève de notre métier. Nous écrivons donc ici les mécanismes plutôt que les recettes, avec les ordres de grandeur que nous constatons sur les dossiers que nous ouvrons, et sans dissimuler les endroits où une migration se paye cher lorsqu'elle est mal préparée.
Il faut poser d'emblée le principe qui gouverne tout le reste. Une boutique existante possède deux patrimoines distincts, et ils ne se traitent pas de la même manière. Le premier est le patrimoine de données : le catalogue, les déclinaisons, les clients, les commandes, les avoirs, les factures. Il se transporte, il se contrôle, il se réconcilie ligne à ligne. Le second est le patrimoine de visibilité : les adresses connues de Google, les pages qui reçoivent des impressions, les liens que d'autres sites vous ont accordés au fil des années, la confiance accumulée par un domaine. Celui-là ne se transporte pas dans un fichier, il se préserve par des décisions prises avant la bascule, principalement par un plan de redirections rigoureux. La très grande majorité des refontes ratées que nous reprenons ont soigné le premier patrimoine et négligé le second, avec une conséquence identique : un catalogue impeccable sur un site que plus personne ne trouve.
Nous travaillons ces projets depuis Arras et Lille, pour des e-commerçants des Hauts-de-France comme pour des marchands installés à Paris, à Lyon ou à Marseille, avec un interlocuteur unique du cadrage à la mise en ligne. La distance n'a plus d'incidence pratique sur ce type d'opération ; la qualité de la préparation, elle, en a une considérable. Si votre projet touche plus largement à la création et à la refonte de boutiques en ligne, la page dédiée expose notre approche générale du commerce électronique ; celle-ci se concentre sur le cas particulier, et particulièrement technique, d'une boutique PrestaShop déjà en production.
Reconnaître qu'une boutique PrestaShop est arrivée en fin de vie
Une boutique ne s'effondre pas du jour au lendemain. Elle se dégrade par accumulation, et le propriétaire s'habitue à chaque dégradation à mesure qu'elle apparaît, si bien qu'il ne mesure plus l'écart total. Le premier symptôme, le plus objectif, est la version installée. PrestaShop a connu plusieurs ruptures majeures, et une boutique restée en 1.6 fonctionne peut-être encore, mais elle ne reçoit plus aucun correctif de sécurité et elle est arrimée à des versions de PHP que les hébergeurs sérieux ne proposent plus. Le jour où votre hébergeur impose une montée de version du serveur, la boutique tombe, et elle tombe un mardi matin de novembre, pas un dimanche d'août. Nous avons vu des marchands découvrir la situation par une page blanche à l'ouverture, avec une remise en service qui a demandé plusieurs jours parce que rien n'avait été anticipé.
Le deuxième symptôme est l'état du parc de modules. Un PrestaShop en production accumule couramment quarante à soixante-dix modules actifs, dont une partie a été installée pour un besoin ponctuel oublié depuis. Le problème n'est pas leur nombre en soi, c'est leur cycle de vie : un module acheté sur une place de marché il y a six ans dont l'auteur a cessé toute activité ne recevra jamais de version compatible avec la branche suivante. Or il suffit d'un seul module non porté et réellement critique, un connecteur d'ERP ou une passerelle de transporteur par exemple, pour bloquer une montée de version entière. Le recensement de ces dépendances est la première chose que nous produisons, parce qu'elle décide souvent du scénario retenu avant même toute considération esthétique.
Le thème, la lenteur du back-office et les surcharges invisibles
Le troisième symptôme concerne le thème. Les thèmes commerciaux vendus pour PrestaShop embarquent fréquemment leur propre moteur d'options, des dizaines de fichiers de surcharge et parfois des modules maison qui dupliquent des fonctions natives. Après trois ans d'interventions successives, on trouve des modifications directes dans des fichiers du cœur, des feuilles de style qui se contredisent, des scripts chargés deux fois. Le site s'affiche, mais chaque intervention devient plus longue et plus risquée que la précédente, et le devis de la moindre évolution grimpe sans que le dirigeant comprenne pourquoi. C'est ce que nous appelons une dette technique arrivée à maturité : elle ne se voit pas, elle se paye à chaque demande.
Le quatrième symptôme est la lenteur du back-office, et il mérite d'être pris au sérieux parce qu'il coûte du temps salarié tous les jours. Une base de commandes ancienne, des tables de statistiques jamais purgées, un moteur de recherche interne qui réindexe à chaque enregistrement, un serveur mutualisé saturé : les causes sont identifiables et souvent corrigeables sans refonte. Le cinquième, enfin, est le plus insidieux : les incompatibilités silencieuses. Un courriel de confirmation qui n'arrive plus, un flux d'export vers une place de marché qui envoie des prix erronés, une taxe mal appliquée sur une zone d'expédition. Personne ne remonte l'information parce que chaque cas semble isolé, jusqu'au moment où l'on additionne les commandes perdues sur un trimestre.
Aucun de ces signaux ne se voit depuis la page d'accueil. Tous se constatent en une heure d'examen, et ce sont eux qui commandent le scénario de refonte.
Un point de prudence pour finir : ces signaux justifient un examen, pas nécessairement une reconstruction. Nous avons remis à des marchands d'Amiens et de Valenciennes des recommandations qui tenaient en une montée de version encadrée, un nettoyage de modules et un changement d'hébergement, pour une fraction du prix d'une refonte complète, parce que la structure sous-jacente était saine. Conclure trop vite à la refonte totale arrange le prestataire et rarement le client ; c'est précisément ce que l'audit préalable sert à éviter.
L'audit préalable : ce qu'on mesure avant d'engager la moindre décision
Aucune décision sérieuse ne se prend sur une boutique existante sans un état des lieux documenté, et cet état des lieux n'est pas un exercice de forme. Il conditionne le scénario, le budget et le calendrier, et il coûte infiniment moins cher que les corrections qu'il permet d'éviter. Nous le menons en quatre volets qui s'éclairent mutuellement. Le volet plateforme d'abord : version exacte de PrestaShop, version de PHP et de la base de données, mode d'hébergement, présence ou non d'une sauvegarde restaurable et testée, existence d'un environnement de préproduction, mode de déploiement des modifications. Il n'est pas rare que nous découvrions à ce stade qu'aucune sauvegarde n'a jamais été restaurée pour vérification, ce qui revient à ne pas en avoir.
Le volet code ensuite. Nous listons les modules installés, leur origine, leur éditeur, leur date de dernière mise à jour et leur compatibilité annoncée avec les branches supérieures. Nous relevons les surcharges de contrôleurs et de templates, les éventuelles modifications directes dans le cœur, les développements spécifiques et leur documentation. Cette cartographie a une vertu simple : elle transforme une inquiétude diffuse en une liste finie d'éléments, dont chacun reçoit une décision explicite. Un dirigeant ne peut pas arbitrer sur « le site est vieux » ; il peut parfaitement arbitrer sur un tableau de soixante lignes où figurent le rôle de chaque module, son coût de remplacement et la conséquence de sa disparition.
Le volet données et le volet visibilité
Le volet données recense les volumes et les particularités : nombre de produits, de déclinaisons, de caractéristiques, de catégories, profondeur de l'arborescence, existence de groupes de clients avec des tarifs distincts, règles de prix catalogue et panier, bons de réduction en cours de validité, avoirs, historique de commandes sur plusieurs exercices. Ce sont ces particularités qui font la difficulté réelle d'une reprise, bien davantage que le nombre brut de références. Un catalogue de quinze mille produits sans déclinaison se transporte plus facilement qu'un catalogue de huit cents produits configurables avec des tarifs dégressifs par groupe et des quantités minimales par revendeur, situation courante chez les grossistes et les industriels de la région lensoise ou dunkerquoise.
Le volet visibilité, enfin, est celui que l'on oublie et qui décide de l'après. Il consiste à extraire l'inventaire complet des adresses connues du moteur, à mesurer lesquelles reçoivent réellement des impressions et des clics, à repérer les pages de catégorie et les fiches qui portent le chiffre d'affaires organique, à relever la structure des adresses en vigueur et les liens externes acquis au fil des ans. Ce travail rejoint celui que nous décrivons dans notre audit technique et sémantique, appliqué ici au cas particulier d'une boutique appelée à changer de socle. Sans cet inventaire, le plan de redirections ne peut pas être écrit, et sans plan de redirections, la refonte est une perte de visibilité programmée. Nous refusons d'ailleurs d'ouvrir un chantier de migration sans ce volet, non par principe commercial, mais parce que nous savons ce qu'il en coûte de le reconstituer après coup, quand les anciennes adresses ne répondent plus et que l'on ne dispose plus d'aucune source pour les retrouver.
Monter de version majeure ou repartir d'une installation propre
Une fois l'audit posé, la première grande bifurcation apparaît : fait-on évoluer la boutique existante, ou construit-on une installation neuve dans laquelle on réinjecte les données ? Les deux voies mènent à une boutique à jour, elles n'ont ni le même coût, ni le même profil de risque, ni le même résultat à trois ans. La montée de version en place consiste à faire progresser l'installation actuelle vers une branche supérieure, avec ses modules et son thème, en corrigeant au fur et à mesure ce qui casse. Sur une boutique restée proche du standard, peu modifiée, avec des modules majoritairement officiels ou maintenus, c'est la voie raisonnable : elle préserve la structure des adresses, elle conserve les identifiants internes des produits et des commandes, et elle évite l'essentiel du travail de reprise de données. Le calendrier est plus court, la facture aussi.
Le problème est que cette voie transporte tout ce qui existe, y compris ce que l'on préférerait laisser derrière. Les surcharges obsolètes, les tables de données mortes, les configurations contradictoires accumulées par des prestataires successifs, les modules désactivés qui laissent leurs traces en base : tout arrive de l'autre côté. Sur une boutique de dix ans passablement chargée, l'expérience montre que la montée de version consomme un budget considérable pour aboutir à un site à jour mais toujours difficile à faire évoluer. Le dirigeant a alors le sentiment désagréable d'avoir payé beaucoup pour un résultat qu'il ne voit pas, et il a raison de le ressentir ainsi : la valeur produite est réelle mais purement défensive.
L'installation propre avec reprise de données
L'autre voie consiste à installer une version récente et vierge, à choisir un thème et des modules maintenus, à reconstruire les développements spécifiques réellement utiles, puis à importer le catalogue, les clients et l'historique par des scripts écrits pour l'occasion. C'est plus long, c'est plus cher à l'instant du projet, et cela produit une boutique dont on connaît chaque ligne. Les gains apparaissent ensuite : un back-office qui répond, des mises à jour qui s'appliquent sans drame, des évolutions dont le devis reste proportionné à la demande. Cette voie impose en revanche une discipline absolue sur deux points, la fidélité de la reprise des données et le plan de redirections, car les adresses et les identifiants internes changent presque toujours.
Le choix entre les deux ne se fait pas au goût du prestataire. Il se déduit de trois éléments mesurés pendant l'audit : la proportion de code spécifique et non standard, la disponibilité de versions maintenues pour les modules critiques, et l'écart entre la boutique actuelle et ce que le marchand veut vendre dans deux ans. Quand ces trois éléments pointent dans la même direction, la décision est évidente et se prend en une réunion. Quand ils divergent, nous chiffrons les deux scénarios et nous présentons le comparatif, y compris lorsque le scénario le moins cher est celui qui nous rapporte le moins. Un dirigeant qui comprend ce qu'il achète devient un client durable ; un dirigeant à qui l'on vend une reconstruction inutile s'en aperçoit tôt ou tard.
Le choix se déduit de trois mesures faites pendant l'audit : la part de code non standard, la disponibilité de versions maintenues pour les modules critiques, et l'écart avec ce que vous voudrez vendre dans deux ans.
Une nuance mérite d'être ajoutée pour les boutiques très anciennes. Entre certaines branches de PrestaShop, la montée directe n'existe pas et impose des paliers successifs, chaque palier apportant son lot de correctifs à appliquer. Le cumul de ces étapes atteint parfois le coût d'une reconstruction, sans en offrir les bénéfices. C'est un calcul que nous posons noir sur blanc avant de nous engager, parce qu'il est le seul argument honnête à opposer à un marchand qui voudrait, très légitimement, dépenser le moins possible.
Rester sur PrestaShop, basculer vers WooCommerce ou aller au sur-mesure
La question du changement de plateforme se pose presque toujours au moment d'une refonte, et elle mérite une réponse argumentée plutôt qu'un réflexe. Nous mettons en œuvre PrestaShop comme WooCommerce, et nous développons également des applications marchandes sur mesure lorsque le besoin l'exige, ce qui nous met dans la position confortable de pouvoir répondre sans défendre une chapelle. La règle que nous appliquons est simple : on ne change pas de plateforme parce que l'actuelle est vieille, on en change parce qu'elle est structurellement inadaptée à ce que l'on vend. Une boutique PrestaShop en 1.6 mal entretenue n'est pas un argument contre PrestaShop, c'est un argument contre l'absence de maintenance, et le même marchand reproduira exactement la même situation sur une autre technologie s'il ne change rien à sa manière de gérer son outil.
PrestaShop conserve des atouts réels sur des configurations précises. La gestion native des déclinaisons, des caractéristiques, des groupes de clients avec des tarifs distincts, de la TVA par zone géographique et des règles de prix combinées reste solide et pensée pour le commerce. Un grossiste qui vend à la fois aux particuliers et aux professionnels avec des grilles tarifaires différentes, un industriel dont les produits se déclinent en dimensions et en finitions, un distributeur qui gère plusieurs entrepôts et des délais d'expédition variables trouvent dans PrestaShop des mécanismes que d'autres solutions n'offrent qu'au prix d'extensions payantes empilées. La contrepartie est connue : un écosystème de modules majoritairement commerciaux dont la licence se renouvelle souvent à chaque version majeure, et un besoin de compétences plus spécialisées, donc moins abondantes et plus chères.
Ce qui plaide honnêtement pour WooCommerce
WooCommerce devient le meilleur choix lorsque le contenu éditorial pèse autant que le catalogue. Une marque qui vend deux cents références mais dont l'acquisition repose sur des guides d'achat, des comparatifs, un blog nourri et une stratégie de référencement offensive travaille plus confortablement dans l'écosystème WordPress, où la maîtrise des adresses, des balises et de la structure de contenu est totale et où les compétences disponibles sont bien plus répandues. C'est également le choix pertinent quand l'équipe interne doit gérer le site au quotidien sans crainte, ou quand le budget de maintenance doit rester contenu. Nous détaillons cette approche du côté du référencement d'un site WordPress, qui s'applique directement à une boutique WooCommerce. En revanche, un catalogue de plusieurs dizaines de milliers de références avec de nombreuses déclinaisons demande un travail d'optimisation sérieux pour rester rapide, et il faut le budgéter plutôt que le découvrir.
Le sur-mesure, enfin, ne se justifie que lorsque le modèle de vente ne rentre dans aucun moule : configurateur produit complexe, tarification calculée en temps réel selon des paramètres métier, intégration profonde avec un système de production, plateforme de mise en relation. Il coûte cher à construire et engage une maintenance permanente, mais il supprime la contrainte d'une solution que l'on plie sans cesse. Notre manière de trancher consiste à écrire noir sur blanc les cinq ou six règles commerciales qui font la spécificité de l'activité, puis à vérifier laquelle des trois voies les absorbe sans acrobatie. Cette liste-là, le dirigeant est le seul à pouvoir la fournir, et c'est pourquoi le cadrage commence toujours par une conversation sur le commerce avant de porter sur la technique.
On ne change pas de solution parce que l'actuelle est vieille, mais parce qu'elle est inadaptée à ce que l'on vend. Ces couches se tranchent dans cet ordre.
Un dernier critère est trop rarement examiné : la réversibilité. Quelle que soit la voie choisie, assurez-vous que le nom de domaine, l'hébergement, les comptes de mesure, les contrats de paiement et le code spécifique développé pour vous sont bien à votre nom et exportables. Cette vérification se fait quand la relation est excellente, jamais au moment d'un désaccord. Un marchand qui possède ses accès peut changer de prestataire en quinze jours ; un marchand qui ne les possède pas est captif, et le prix de sa liberté sera un jour très supérieur à ce qu'il a cru économiser.
La reprise du catalogue : produits, déclinaisons et règles de prix
La reprise du catalogue est la partie du projet que tout le monde croit simple et qui consomme le plus d'heures. L'illusion vient des exports : PrestaShop sait produire un fichier de produits, la nouvelle installation sait en importer un, donc l'affaire semble réglée en une journée. Ce raisonnement fonctionne pour une boutique de trois cents références sans complexité. Il s'effondre dès que l'on touche aux déclinaisons, qui constituent le véritable point dur. Une déclinaison n'est pas une ligne de tableau : c'est une combinaison d'attributs, avec son propre identifiant, son propre stock, son propre code-barres, son propre prix d'impact, parfois sa propre image et son propre poids pour le calcul des frais de port. Sur un catalogue de textile ou de pièces techniques, un millier de produits engendre couramment plusieurs dizaines de milliers de combinaisons, et chacune doit se retrouver de l'autre côté avec la même référence, sous peine de désynchroniser les stocks et de vendre ce que l'on n'a plus.
Le deuxième point dur concerne les règles de prix. Une boutique en activité depuis plusieurs années accumule des tarifs spécifiques par groupe de clients, des remises par quantité, des promotions programmées avec des dates de début et de fin, des prix par pays ou par devise, des bons de réduction en circulation et des règles de panier conditionnelles. Ces objets sont modélisés différemment d'une version à l'autre, et plus encore d'une plateforme à l'autre. Nous les reprenons rarement par import automatique : nous les reconstruisons à partir d'un inventaire validé par le marchand, parce qu'une refonte est aussi l'occasion de supprimer les vingt règles obsolètes qui traînent et que personne n'ose désactiver de peur de casser quelque chose.
Les images, les contenus et les données de référencement
Les images demandent une attention particulière parce qu'elles pèsent lourd et qu'elles portent des informations utiles. Il faut les récupérer en résolution d'origine, préserver l'ordre d'affichage, conserver l'association aux déclinaisons quand elle existe, et régénérer les formats d'affichage de la nouvelle installation. Le texte alternatif, lorsqu'il a été renseigné, doit suivre : c'est un travail éditorial qui a été payé une fois et qu'il serait absurde de perdre. Nous voyons régulièrement des reprises où toutes les images arrivent bien mais désordonnées, et où la première photo de chaque fiche devient une vue de détail incompréhensible en page de catégorie.
Il faut enfin reprendre les données de référencement attachées au catalogue : les titres et méta-descriptions personnalisés, les fragments d'adresse réécrits, les descriptions courtes et longues, les balises canoniques particulières. Ces champs représentent souvent des centaines d'heures de rédaction cumulées, et ils disparaissent silencieusement dans une reprise mal cadrée parce qu'ils ne sont pas visibles à l'écran. Notre méthode consiste à établir avant tout transfert un fichier de correspondance qui associe chaque produit et chaque déclinaison de l'ancien système à son équivalent dans le nouveau, avec les identifiants des deux côtés. Ce fichier n'est pas un livrable annexe : il sert ensuite à contrôler la reprise, à générer le plan de redirections, à réconcilier les stocks et à rattraper les erreurs si un problème apparaît après la mise en ligne. Un projet qui ne produit pas ce fichier de correspondance n'a aucun moyen sérieux de prouver que la reprise est complète.
Les clients, les commandes et l'historique : ce qui se reprend et ce qui ne se reprend pas
Le fichier client est l'actif le plus précieux d'une boutique et le plus délicat à déplacer. Les comptes, les adresses de facturation et de livraison, les groupes tarifaires, les consentements marketing et les paniers en cours se reprennent techniquement sans difficulté majeure au sein de PrestaShop. La question sensible est celle des mots de passe. Ils ne sont pas stockés en clair, ce qui est heureux, mais sous forme d'empreintes calculées avec un algorithme et une clé propres à l'installation d'origine. Lorsque cette clé est conservée et que l'algorithme reste compatible, les clients ne s'aperçoivent de rien. Lorsque la boutique change de plateforme ou que la méthode de hachage évolue, les empreintes deviennent inutilisables et il faut prévoir un mécanisme de réinitialisation, accompagné d'un message clair envoyé avant la bascule. Ce détail apparemment mineur provoque, quand il est découvert le jour J, une vague d'appels au service client et une chute immédiate des commandes des acheteurs réguliers.
Les commandes posent une question de nature différente, moins technique que juridique et comptable. Une commande passée est un document qui engage : elle est liée à une facture numérotée en séquence continue, à un taux de TVA en vigueur à sa date, à des conditions générales de vente d'une version donnée, et elle doit rester consultable pendant la durée légale de conservation. On ne réécrit pas des factures antérieures, on ne renumérote pas une séquence, et on ne recalcule pas des montants avec les taux d'aujourd'hui. La reprise doit donc préserver l'intégrité de l'existant, ce qui interdit certaines simplifications tentantes.
Trois stratégies possibles pour l'historique
La première stratégie consiste à tout migrer : commandes, lignes de commande, statuts, messages, avoirs, factures au format d'origine. C'est la plus confortable pour le marchand, et la plus coûteuse, car chaque commande référence des produits, des transporteurs, des moyens de paiement et des états qui doivent exister dans le nouveau système avec les bons identifiants. La deuxième consiste à ne migrer que les commandes récentes, généralement celles encore susceptibles de donner lieu à un retour, un échange ou une réclamation, et à conserver le reste dans un export archivé et dans les documents comptables. La troisième, utile lors d'un changement de plateforme, consiste à basculer l'historique dans un espace de consultation en lecture seule, indépendant de la boutique, auquel le service client accède quand il en a besoin.
Le choix dépend de votre métier et de vos obligations. Un vendeur de matériel technique dont les clients réclament des garanties trois ans après l'achat n'a pas les mêmes besoins qu'un marchand de produits de consommation courante. Nous posons systématiquement la question au dirigeant plutôt que de décider à sa place, parce que l'écart de coût entre la première et la troisième stratégie est significatif et qu'il n'a de sens que rapporté à un usage réel. Un point de vigilance pour terminer : le règlement européen sur les données personnelles s'applique intégralement à cette opération. Les consentements doivent suivre les personnes, les comptes inactifs depuis longtemps méritent d'être purgés plutôt que transportés, et l'environnement de test dans lequel vous travaillerez pendant plusieurs semaines contient une copie de votre base clients, ce qui impose de le protéger par une authentification et de le détruire proprement à la fin du chantier.
Le plan de redirections, point le plus critique de toute la refonte
S'il ne fallait retenir qu'un seul chapitre de cette page, ce serait celui-ci. Une boutique en activité depuis plusieurs années possède un capital d'adresses connues : Google les a indexées, des sites externes pointent vers elles, des clients les ont mises en favori, des campagnes publicitaires les utilisent, des places de marché et des comparateurs les référencent. Lorsque la structure des adresses change — et elle change presque toujours, que ce soit à cause d'une nouvelle arborescence, d'un changement de format de réécriture ou d'un renumérotage des identifiants produits —, chacune de ces anciennes adresses doit indiquer où trouver son remplaçant. C'est le rôle de la redirection permanente, un signal envoyé par le serveur qui dit au navigateur et au moteur que la page a déménagé définitivement et transmet l'essentiel de la valeur accumulée vers la nouvelle adresse.
Ce qui arrive quand ce travail est bâclé est parfaitement documenté par les dossiers de rattrapage que l'on nous confie. Les anciennes adresses renvoient une erreur, le moteur les retire progressivement de son index, les pages nouvelles doivent repartir de zéro sans bénéficier de l'ancienneté du domaine, et le trafic organique chute de moitié ou davantage en trois à six semaines. Le marchand voit son chiffre d'affaires baisser au moment précis où il vient d'investir dans un site plus beau, et le prestataire lui explique que « c'est normal après une refonte, cela va remonter ». Ce n'est pas normal. Une refonte correctement redirigée provoque au pire un flottement de quelques semaines, le temps que le moteur réexplore l'ensemble ; elle ne provoque pas d'effondrement durable.
La méthode, adresse par adresse
Le plan se construit à partir de sources multiples que l'on croise, car aucune ne suffit seule. L'exploration complète de l'ancien site donne les adresses atteignables par navigation. L'export du rapport d'indexation du moteur donne celles qu'il connaît, y compris celles que plus aucun lien ne pointe. Les journaux du serveur sur plusieurs mois révèlent les adresses réellement demandées, y compris par des sources externes. Les fichiers de plan de site, les exports d'anciennes campagnes et les flux envoyés aux comparateurs complètent la liste. On obtient ainsi un inventaire nettement plus large que celui du crawl seul, et c'est cet inventaire complet qui doit être traité.
Chaque adresse reçoit ensuite une destination individuelle. La tentation, quand la liste compte plusieurs dizaines de milliers de lignes, est de tout renvoyer vers la page d'accueil ou vers la catégorie parente. C'est une erreur : une redirection massive vers une page sans rapport est traitée comme une page d'erreur déguisée et ne transmet rien. Une fiche produit disparue doit pointer vers son remplaçant, ou à défaut vers la catégorie la plus proche qui répond à la même intention d'achat. Un produit définitivement arrêté et sans équivalent peut légitimement renvoyer une erreur assumée, à condition que la page correspondante propose des alternatives. Nous produisons ce plan sous forme de fichier de correspondance validé, nous le testons intégralement sur l'environnement de préproduction avant la bascule, et nous le contrôlons de nouveau dans l'heure qui suit la mise en ligne. Sur les gros catalogues, l'exécution passe par des règles génériques pour les motifs réguliers et par une table de correspondance pour les cas particuliers, avec une vigilance sur les chaînes de redirection : une adresse doit atteindre sa destination en un seul saut, jamais en trois.
- Étape 1 Inventorier toutes les sources Exploration de l'ancien site, rapport d'indexation du moteur, journaux serveur sur plusieurs mois, plans de site, flux comparateurs et anciennes campagnes.
- Étape 2 Établir la correspondance Associer chaque produit, déclinaison et catégorie de l'ancien système à son équivalent dans le nouveau, avec les identifiants des deux côtés.
- Étape 3 Attribuer une destination individuelle Chaque adresse vers son remplaçant ou la catégorie répondant à la même intention. Jamais un renvoi massif vers la page d'accueil.
- Étape 4 Écrire les règles Motifs génériques pour les cas réguliers, table de correspondance pour les exceptions. Une adresse doit atteindre sa cible en un seul saut.
- Étape 5 Tester en préproduction Contrôle intégral sur l'environnement de test, avec un échantillon couvrant chaque gabarit et chaque type d'adresse.
- Étape 6 Vérifier dans l'heure suivant la bascule Nouveau contrôle en production, puis relecture des journaux à vingt-quatre et soixante-douze heures pour repérer les oublis.
- Étape 7 Conserver au moins un an Des liens externes anciens continuent d'amener du trafic longtemps après, et le moteur revient vérifier des adresses qu'il n'a plus explorées depuis des mois.
C'est le seul chantier dont l'oubli fait chuter durablement le chiffre d'affaires organique. Il s'écrit avant la bascule, jamais après.
Un plan de redirections ne se supprime pas au bout d'un mois. Nous conservons les règles au moins un an, souvent davantage, parce que des liens externes anciens continuent d'amener du trafic longtemps après et que le moteur revient périodiquement vérifier des adresses qu'il n'a plus explorées depuis des mois. Le coût de conservation est nul, le coût de suppression prématurée est une perte sèche. Ce travail s'inscrit naturellement dans une prestation de référencement continue, où la refonte devient un jalon parmi d'autres plutôt qu'un événement isolé dont personne ne surveille les suites.
Filtres, recherche à facettes et gaspillage d'exploration
La navigation à facettes est la fonction la plus utile d'une boutique pour l'acheteur et la plus dangereuse pour le référencement. Son principe consiste à laisser le visiteur restreindre une catégorie par marque, taille, couleur, matière, fourchette de prix, disponibilité, et à combiner ces critères librement. Du point de vue commercial, c'est excellent. Du point de vue des adresses, chaque combinaison produit une adresse distincte, et le nombre de combinaisons croît de manière multiplicative. Une catégorie avec six familles de filtres comportant chacune une poignée de valeurs engendre sans effort plusieurs milliers d'adresses pour un seul rayon, et une boutique de taille moyenne dépasse rapidement le million d'adresses théoriques alors qu'elle ne compte que quelques milliers de produits réels.
Le moteur de recherche dispose d'un budget d'exploration limité pour votre domaine. S'il le dépense à parcourir des combinaisons de filtres qui n'apportent aucune valeur propre, il ne le dépense pas à découvrir vos nouveaux produits, vos pages de catégorie retravaillées et vos guides d'achat. C'est un mal silencieux : rien ne se voit à l'écran, aucun visiteur ne se plaint, et pourtant les fiches nouvellement publiées mettent des semaines à apparaître. Sur les boutiques que nous reprenons, l'analyse des journaux montre régulièrement que la majorité du temps de robot part dans des pages de filtres, de tri et de pagination profonde, au détriment complet du catalogue utile.
Ce qu'une refonte doit trancher
Une refonte est le moment idéal pour régler la question, parce qu'on la traite à la conception plutôt qu'en rattrapage. La règle de fond consiste à décider, filtre par filtre, s'il produit une page qui mérite d'exister dans les résultats de recherche. Certaines combinaisons correspondent à une demande réelle et formulée : une famille de produits associée à une marque, ou associée à une caractéristique technique que les gens tapent effectivement. Celles-là gagnent à devenir de véritables pages, avec une adresse propre, un titre spécifique, un contenu éditorial et un maillage interne. Toutes les autres — les combinaisons multiples, les tris, les fourchettes de prix, les pages de résultats de recherche interne — doivent rester accessibles au visiteur et invisibles pour le moteur.
Les moyens techniques existent et se complètent : blocage d'exploration des motifs de paramètres, indication de non-indexation sur les pages générées, adresse canonique renvoyant vers la catégorie de référence, absence de liens suivis vers les combinaisons secondaires, et exclusion de ces adresses du plan de site. Aucun de ces moyens n'est suffisant seul, et leur combinaison demande d'être posée correctement, faute de quoi on obtient l'inverse du résultat souhaité, par exemple des pages bloquées à l'exploration mais indexées sans contenu. Cette architecture se décide avant le développement du thème, parce qu'elle influence la manière dont les liens de filtres sont générés dans les templates. Nous ajoutons systématiquement à la recette une vérification portant sur l'échantillonnage d'adresses de filtres, et une mesure du volume total d'adresses accessibles, qui doit rester dans un ordre de grandeur cohérent avec la taille réelle du catalogue. Un marchand qui découvre après coup que sa nouvelle boutique expose quatre cent mille adresses pour deux mille produits vient d'hériter d'un problème dont le traitement demandera plusieurs semaines.
Les modules : lesquels garder, lesquels remplacer, lesquels supprimer
Le parc de modules est le lieu où se cristallise l'essentiel de la dette d'une boutique PrestaShop, et son traitement demande une méthode plutôt qu'un tri à l'intuition. Nous commençons par établir, pour chaque module actif, quatre informations : à quoi il sert concrètement dans l'exploitation quotidienne, qui l'a écrit et si cet éditeur publie encore, quel est son coût de licence et de renouvellement, et ce qui se passerait s'il disparaissait demain. Cette dernière question est la plus éclairante. Elle révèle presque toujours que le tiers du parc ne sert plus à personne : un module d'avis remplacé par une solution externe et jamais désinstallé, un affichage de bandeau saisonnier laissé en place, une extension de statistiques doublonnant l'outil de mesure, un connecteur vers une place de marché abandonnée deux ans plus tôt.
Le deuxième groupe rassemble les modules dont la fonction est native dans les versions récentes. PrestaShop a progressivement intégré ce qui n'existait qu'en extension : gestion avancée des images, réécriture d'adresses, certains aspects du multiboutique, plusieurs mécanismes de cache. Reprendre un module payant pour une fonction désormais standard revient à payer deux fois et à ajouter un risque d'incompatibilité pour rien. Le troisième groupe est celui des modules réellement critiques et sans équivalent : connecteur d'ERP ou de logiciel de gestion, passerelle de transporteur avec impression d'étiquettes, module de facturation conforme, gestion de programmes de fidélité complexes. Ceux-là décident du calendrier, parce qu'il faut soit obtenir une version compatible, soit financer un développement de remplacement, soit renoncer à une fonction, et aucune de ces trois options ne s'improvise la veille de la bascule.
Chaque module ajoute du code exécuté à chaque page, des requêtes en base, un point de rupture lors des mises à jour et une licence à renouveler.
Le quatrième groupe est celui des modules à remplacer par un équivalent maintenu. C'est là que le dirigeant doit accepter un compromis fonctionnel, car le remplaçant ne fera jamais exactement la même chose que l'ancien. Nous préparons ces arbitrages en amont, avec une démonstration sur l'environnement de préproduction, plutôt que de les découvrir en production sous la pression. Notre position générale, formée par les reprises de dossiers, est qu'un parc réduit et à jour vaut mieux qu'un parc riche et fragile : chaque module ajoute du code exécuté à chaque page, des requêtes à la base, des points de rupture lors des mises à jour et une ligne de licence à renouveler. Diviser par deux un parc de soixante modules produit habituellement un gain de vitesse perceptible et une baisse durable du coût de maintenance.
Une remarque financière qui surprend souvent les marchands : les licences de modules PrestaShop ne sont pas systématiquement transférables d'une version majeure à l'autre, ni parfois d'un nom de domaine à l'autre. Un projet de refonte doit donc intégrer un poste budgétaire de renouvellement de licences, que nous chiffrons pendant l'audit à partir du parc réel. Sur une boutique chargée, ce poste atteint parfois plusieurs milliers d'euros à lui seul, et il vaut mieux l'apprendre au moment du devis qu'au moment de l'installation. C'est aussi ce qui rend le tri rentable : chaque module supprimé est une licence que vous ne renouvelez pas, un risque en moins et quelques dizaines de millisecondes gagnées sur chaque affichage.
Le thème et la performance : où se joue vraiment la vitesse d'une boutique
La vitesse d'une boutique n'est pas un sujet de confort, c'est un sujet de chiffre d'affaires et de référencement. Un visiteur qui attend perd patience, particulièrement sur mobile et particulièrement dans le tunnel de commande, et le moteur mesure explicitement plusieurs indicateurs d'expérience de chargement. La difficulté, pour un dirigeant, est que le discours commercial autour des thèmes entretient une confusion : on lui vend un thème « optimisé », il constate que son site reste lent, et personne ne lui explique pourquoi. La raison est simple. La performance d'un PrestaShop se joue à quatre endroits distincts, et le thème n'en est qu'un.
Le premier endroit est le serveur. Une boutique n'est pas un site vitrine : elle exécute du code à chaque affichage, interroge la base pour les stocks, les prix et les règles applicables, et supporte mal la mutualisation bon marché. Le passage d'un hébergement mutualisé à une infrastructure dimensionnée, avec une version récente de PHP, un cache d'opcode correctement configuré et une base de données sur un disque rapide, produit souvent le gain le plus spectaculaire de tout le chantier, pour un coût mensuel modeste. Le deuxième endroit est la base de données elle-même : index manquants sur des tables devenues volumineuses, tables de connexions et de statistiques jamais purgées, recherches internes non optimisées. Ce travail est invisible et décisif, notamment pour la fluidité du back-office dont se plaignent les équipes de saisie.
Le thème, les images et ce que le visiteur ressent
Le troisième endroit est le thème proprement dit, et le critère de choix n'est pas son apparence sur la démonstration de l'éditeur. Un thème sain se reconnaît à un nombre restreint de fichiers de style et de scripts, à l'absence de bibliothèques dupliquées, à un balisage propre et à une compatibilité annoncée avec la version cible. Les thèmes multifonctions qui proposent quarante variantes d'accueil et un constructeur visuel embarquent nécessairement le code de toutes les variantes, y compris celles que vous n'utiliserez jamais. Nous préférons partir d'un thème sobre et le travailler, plutôt que de désactiver interminablement des fonctions dans un thème surchargé.
Le quatrième endroit est le contenu servi, principalement les images. Un catalogue photographique représente la majeure partie du poids d'une page de boutique : formats modernes, dimensions adaptées à l'affichage réel, chargement différé pour ce qui se trouve hors écran, dimensions déclarées pour éviter que la mise en page ne saute pendant le chargement. À cela s'ajoutent les scripts tiers, qui sont le point aveugle de la plupart des boutiques : outil de mesure, bandeau de consentement, module de discussion en direct, pixel publicitaire, widget d'avis, chacun ajoutant des requêtes vers des serveurs sur lesquels vous n'avez aucune maîtrise. Il n'est pas rare qu'une boutique techniquement rapide soit rendue lente par six scripts marketing dont deux ne sont plus utilisés. Nous mesurons systématiquement l'affichage sur un téléphone d'entrée de gamme en connexion mobile réelle plutôt que sur un poste de bureau en fibre, parce que c'est cette expérience-là que vit une bonne partie de vos acheteurs, à Douai comme à Paris.
Tunnel de commande, transporteurs, paiements et conformité
Le tunnel de commande est la partie de la boutique où chaque défaut se paye immédiatement en commandes perdues, et c'est aussi celle que l'on teste le moins parce qu'elle est fastidieuse à parcourir. Une refonte doit reprendre chaque étape avec méthode : ajout au panier depuis une fiche et depuis une page de catégorie, modification des quantités, application d'un code de réduction, création de compte et commande sans compte, saisie d'une adresse de livraison différente de la facturation, choix du transporteur avec recalcul correct des frais, acceptation des conditions générales, paiement, page de confirmation, courriel de confirmation, et affichage de la commande dans l'espace client comme dans le back-office. Chacune de ces étapes doit être vérifiée sur ordinateur, sur téléphone et dans plusieurs navigateurs, et chacune doit fonctionner pour un client français comme pour un client d'un autre pays de l'Union si vous y expédiez.
Les transporteurs concentrent une bonne part des surprises. Les frais de port dépendent de grilles combinant poids, zone géographique, montant du panier et parfois volume, et ces grilles se reconstruisent presque toujours à la main lors d'une migration, car leur modélisation varie d'une version à l'autre. La règle que nous appliquons est de vérifier les extrémités et les seuils : un panier très léger, un panier très lourd, un panier juste en dessous du seuil de gratuité et un panier juste au-dessus, une livraison en France métropolitaine, une en Corse, une en Belgique, une hors zone couverte. Les modules de points relais ajoutent une couche de dépendance à une cartographie externe qu'il faut tester en conditions réelles. Une erreur de grille non détectée ne provoque pas d'alerte : elle facture simplement les frais de port au mauvais montant sur chaque commande, et vous perdez de l'argent ou des ventes sans le savoir.
Paiements, obligations légales et documents contractuels
Les moyens de paiement demandent une coordination avec des tiers, et cette coordination prend du temps qu'il faut anticiper. Le contrat de vente à distance est lié à un identifiant de boutique, les identifiants techniques doivent être régénérés pour la nouvelle installation, l'authentification forte du porteur doit fonctionner intégralement, et les paiements en plusieurs fois ou par solutions de financement imposent chacun leur propre recette. Nous testons systématiquement les parcours d'échec autant que les parcours de succès : carte refusée, abandon en cours d'authentification, retour au site après paiement interrompu. Un tunnel qui gère mal un paiement refusé crée des commandes fantômes en attente, des stocks bloqués et des clients persuadés d'avoir payé.
La conformité, enfin, n'est pas un supplément juridique optionnel. Les mentions légales, les conditions générales, les informations sur le droit de rétractation et le formulaire type, la politique de confidentialité, l'affichage des prix toutes taxes comprises pour les particuliers, les informations sur la garantie légale de conformité, les éventuelles obligations sectorielles et les nouvelles règles d'accessibilité applicables au commerce en ligne doivent être en place à la mise en ligne, pas trois mois après. Le bandeau de consentement doit réellement bloquer les traceurs avant acceptation, ce qui est loin d'être le cas partout, et les données personnelles reprises pendant la migration relèvent du même régime que sur l'ancienne boutique. Ces sujets sont ingrats et ils ne font vendre aucun produit, mais un contrôle ou une réclamation client arrive toujours au pire moment, et leur traitement en amont coûte quelques heures là où leur traitement en urgence coûte beaucoup plus.
Multiboutique et multilingue : les configurations qui doublent la difficulté
PrestaShop propose nativement un mode multiboutique qui permet de gérer plusieurs vitrines sur une même installation, avec un catalogue partagé ou séparé, des clients communs ou distincts, des transporteurs et des règles de prix propres à chaque boutique. C'est une fonction puissante et c'est aussi celle qui complique le plus une migration, parce qu'elle multiplie les dimensions de chaque objet. Un produit n'a plus un prix, il a un prix par boutique ; une catégorie n'a plus une position, elle en a une par contexte ; un module peut être actif ici et inactif là. Une reprise de données qui ignore cette dimension produit des résultats apparemment corrects sur la boutique principale et complètement faux sur les autres, avec des découvertes qui s'échelonnent sur des semaines.
La première question à trancher est d'ailleurs celle du maintien de cette architecture. Le multiboutique se justifie quand les vitrines partagent réellement un catalogue et une logistique, par exemple une marque qui vend sous plusieurs enseignes ou qui sépare son offre professionnelle de son offre grand public. Il se justifie beaucoup moins quand il a été mis en place pour gérer deux langues ou deux pays, usage pour lequel les fonctions natives de langues et de zones conviennent mieux. Nous rencontrons régulièrement des installations où le multiboutique a servi de solution de contournement à un problème qui aurait dû être traité autrement, et la refonte est l'occasion de simplifier, à condition de mesurer honnêtement ce que la simplification impose de reconstruire.
Les langues, les pays et les balises de correspondance
Le multilingue soulève des questions parallèles. Chaque langue possède ses traductions de contenus, ses fragments d'adresse réécrits, ses traductions de thème et de modules, et ses paramètres régionaux. Une reprise doit vérifier que chaque champ traduit existe bien dans chaque langue et qu'aucune langue ne récupère silencieusement le texte de la langue par défaut, ce qui se produit fréquemment et passe inaperçu jusqu'à ce qu'un client belge néerlandophone signale une fiche entièrement en français. Il faut aussi vérifier les formats de date, les séparateurs décimaux, les devises et les règles de taxation, qui diffèrent selon les pays de destination.
Du point de vue du référencement, la question centrale est celle des correspondances entre versions linguistiques. Les balises qui déclarent à un moteur qu'une page existe en plusieurs langues ou pour plusieurs pays doivent être complètes et réciproques : chaque version doit citer toutes les autres, y compris elle-même, et les déclarations doivent pointer vers des adresses qui répondent correctement. Une migration casse très facilement ce dispositif, parce que les adresses changent et que les balises sont souvent générées par un module qui n'a pas été reconfiguré. Le symptôme est caractéristique : le moteur se met à afficher la mauvaise version linguistique dans les résultats d'un pays, ou considère les versions comme des doublons et n'en retient qu'une. Nous vérifions systématiquement ce point avant bascule, sur un échantillon couvrant chaque langue et chaque type de page, puis de nouveau après la mise en ligne, car c'est un des rares réglages dont l'erreur se répercute directement sur des marchés entiers.
La recette avant bascule : ce qu'il faut avoir vérifié pour dormir tranquille
La recette est l'étape que les calendriers serrés sacrifient en premier et celle dont l'absence coûte le plus cher. Elle consiste à vérifier méthodiquement, sur un environnement identique à la production, que tout ce qui fonctionnait fonctionne encore et que tout ce qui a été ajouté fonctionne comme prévu. Elle ne se mène pas en naviguant au hasard : elle suit une liste écrite, dont chaque ligne reçoit un verdict et un responsable. Cette liste comporte au minimum les parcours de commande complets, les grilles de transport aux valeurs extrêmes, chaque moyen de paiement en succès et en échec, les courriels transactionnels reçus dans une vraie boîte et lus sur un téléphone, la cohérence des stocks, les exports comptables, les flux vers les places de marché et les comparateurs, les connecteurs de gestion, et le bon fonctionnement du back-office pour chaque profil d'utilisateur.
S'y ajoute une recette spécifiquement dédiée au référencement, distincte de la recette fonctionnelle et souvent oubliée. Elle vérifie que l'environnement de test est bien fermé aux moteurs et que la production, elle, sera bien ouverte — l'inverse de ces deux réglages est l'accident classique, et laisser une interdiction d'indexation en place le jour de la mise en ligne fait disparaître une boutique en quelques jours. Elle contrôle un échantillon représentatif de redirections, l'exactitude des titres et méta-descriptions sur chaque gabarit, la présence des données structurées de produit avec le prix et la disponibilité, la génération du plan de site, la cohérence des balises canoniques, le traitement des pages de filtres, et l'absence de contenus dupliqués entre versions avec et sans paramètres.
- Étape 1 Contrôler la reprise des données Comptages produits, déclinaisons, images, règles de prix et clients confrontés au fichier de correspondance établi avant transfert.
- Étape 2 Parcourir le tunnel de bout en bout Panier, code de réduction, compte et commande invité, adresses distinctes, sur ordinateur, sur téléphone et sur plusieurs navigateurs.
- Étape 3 Éprouver transporteurs et paiements Grilles testées aux extrémités et aux seuils, chaque moyen de paiement en succès comme en échec, courriels lus dans une vraie boîte.
- Étape 4 Mener la recette de référencement Redirections échantillonnées, titres et descriptions par gabarit, données structurées, plan de site, canoniques, traitement des filtres.
- Étape 5 Vérifier l'exploitation quotidienne Saisie catalogue, préparation de commandes, exports comptables, flux vers les places de marché, droits par profil d'utilisateur.
- Étape 6 Écrire la procédure de retour arrière Quelle sauvegarde, où, en combien de temps, par qui, et jusqu'à quel moment le retour reste possible sans perdre de commandes.
Une liste écrite, un verdict et un responsable par ligne. Faites-y participer ceux qui utilisent la boutique tous les jours, pas seulement les décideurs.
Nous recommandons de faire participer à cette recette les personnes qui utilisent la boutique tous les jours plutôt que les seuls décideurs. La responsable de la saisie catalogue repérera en dix minutes que l'ajout d'une déclinaison demande désormais trois clics de plus ; le préparateur de commandes verra immédiatement que le bon de préparation n'affiche plus l'emplacement en stock ; le comptable notera que l'export ne comporte plus le code analytique. Ces détails n'apparaissent dans aucune spécification et ils déterminent l'adhésion des équipes au nouvel outil. Prévoyez donc une session encadrée, avec un tableau où chacun consigne ce qu'il constate, et acceptez qu'une partie des retours donne lieu à des ajustements après la mise en ligne plutôt que de repousser indéfiniment la date.
Un dernier élément de la recette porte sur la procédure de retour arrière. Avant de basculer, il faut savoir exactement comment revenir à la situation antérieure si un problème majeur survient : quelle sauvegarde restaurer, où elle se trouve, combien de temps prend la restauration, qui possède les accès, et jusqu'à quel moment ce retour reste possible sans perdre les commandes passées entre-temps. Cette procédure doit être écrite et, idéalement, testée. Elle ne servira probablement pas, et c'est justement parce qu'elle existe que la bascule se déroule dans le calme plutôt que dans l'improvisation.
La bascule, les soixante-douze heures qui suivent et les semaines d'après
Le moment de la mise en ligne se choisit et ne se subit pas. Nous privilégions un créneau de faible activité commerciale, avec une équipe complète disponible dans les heures qui suivent, et nous évitons systématiquement les veilles de week-end, les veilles de jours fériés et les périodes de forte saisonnalité. Basculer une boutique le vendredi à dix-sept heures revient à parier que rien ne se produira pendant soixante heures sans surveillance ; ce pari se perd régulièrement. Nous évitons également de faire coïncider la refonte avec un changement de nom de domaine ou un changement d'hébergeur lorsque cela peut être évité, car en cas d'anomalie il devient impossible de savoir laquelle des trois opérations est en cause. Quand ces changements sont inévitables, on les échelonne.
Dans l'heure qui suit la mise en ligne, une série de vérifications s'enchaîne dans un ordre précis : le site répond, le certificat de sécurité est valide sur toutes les versions du domaine, l'accès aux moteurs est bien autorisé, un échantillon d'anciennes adresses redirige correctement, une commande de test complète passe avec un vrai paiement, le courriel de confirmation arrive, la commande apparaît en back-office et le flux vers le système de gestion fonctionne. Dans les vingt-quatre heures, on soumet les nouveaux plans de site, on surveille les erreurs serveur dans les journaux, on contrôle le taux de pages en erreur, et on vérifie que l'outil de mesure enregistre bien les transactions avec leurs montants. Dans les soixante-douze heures, on relit les journaux à la recherche des adresses demandées qui renvoient une erreur, car ce sont elles qui révèlent les oublis du plan de redirections, et on corrige au fil de l'eau.
Les semaines suivantes et les signes d'une migration qui se passe mal
La surveillance ne s'arrête pas là. Pendant six à huit semaines, nous suivons quatre indicateurs : le nombre de pages indexées, la courbe d'impressions et de clics par type de page, le nombre de commandes rapporté à la même période de l'année précédente, et le taux d'erreurs serveur. Une refonte réussie présente un profil caractéristique : un léger tassement des impressions pendant deux à trois semaines, le temps que le moteur réexplore et réévalue l'ensemble, puis un retour au niveau antérieur et, généralement, un dépassement lié aux améliorations apportées. Les commandes suivent avec un décalage, parce qu'un tunnel plus fluide produit ses effets immédiatement alors que la visibilité met plus longtemps.
Les signes d'une migration qui se passe mal sont tout aussi lisibles, à condition de regarder. Une chute brutale et continue des pages indexées trahit presque toujours une interdiction d'indexation restée active, une erreur de balise canonique généralisée ou des redirections défaillantes. Une explosion du nombre d'adresses connues sans progression du trafic signale un problème de filtres non maîtrisés. Une hausse des erreurs serveur pointe des adresses oubliées ou un hébergement sous-dimensionné. Une chute du taux de conversion à isopérimètre de trafic désigne le tunnel, souvent une étape cassée sur un navigateur particulier ou un moyen de paiement défaillant. Dans tous les cas, la règle est la même : plus le diagnostic est précoce, plus le rattrapage est simple. Nous reprenons régulièrement des migrations conduites par d'autres, et l'écart de difficulté entre une intervention à quinze jours et une intervention à six mois est considérable, parce que dans le second cas le moteur a eu le temps d'oublier des milliers d'adresses qu'il faudra lui réapprendre une par une.
Questions fréquentes
Vais-je perdre mon référencement en refondant ma boutique PrestaShop ?
Pas si le plan de redirections est construit avant la bascule et testé. Le risque ne vient pas de la refonte elle-même mais du changement d'adresses non traité : les anciennes pages renvoient une erreur, le moteur les retire de son index, et les nouvelles repartent sans bénéficier de l'ancienneté du domaine. Une migration correctement préparée provoque au pire un tassement des impressions pendant deux à trois semaines, le temps que l'ensemble soit réexploré, puis un retour au niveau antérieur. Exigez de votre prestataire l'inventaire complet des adresses actuelles, construit à partir de l'exploration du site, du rapport d'indexation et des journaux serveur, et la table de correspondance qui en découle. Sans ces deux documents, le plan n'existe pas.
Faut-il monter de version ou repartir d'une installation neuve ?
La réponse se déduit de trois mesures faites pendant l'audit. Si la boutique est restée proche du standard, avec peu de surcharges et des modules majoritairement maintenus, la montée de version en place est la voie raisonnable : elle préserve les adresses et les identifiants internes, elle coûte moins cher et elle va plus vite. Si l'installation traîne des années de modifications directes, des modules abandonnés et une base surchargée, la montée transporte tous ces défauts de l'autre côté et vous payez cher un résultat que vous ne voyez pas. L'installation propre avec reprise de données coûte davantage sur l'instant et produit une boutique dont chaque ligne est connue, donc évolutive. Nous chiffrons les deux scénarios quand ils sont défendables.
Dois-je quitter PrestaShop pour WooCommerce ?
Pas parce que votre version est ancienne : une boutique mal entretenue n'est pas un argument contre PrestaShop, et le même marchand reproduira la situation ailleurs s'il ne change rien à sa gestion. PrestaShop reste solide sur les catalogues à nombreuses déclinaisons, les groupes de clients à tarifs distincts et les activités mixtes particuliers-professionnels. WooCommerce devient préférable quand le contenu éditorial pèse autant que le catalogue, quand l'équipe interne doit gérer le site sans crainte, ou quand le budget de maintenance doit rester contenu. Nous mettons en œuvre les deux, ce qui nous permet de répondre sans défendre une chapelle : écrivez les cinq règles commerciales qui font votre spécificité, et la solution qui les absorbe sans acrobatie apparaît d'elle-même.
Est-ce que je conserve mes clients, leurs mots de passe et l'historique des commandes ?
Les comptes, adresses, groupes tarifaires et consentements se reprennent sans difficulté majeure. Les mots de passe sont un cas particulier : ils sont stockés sous forme d'empreintes calculées avec une clé propre à l'installation d'origine. Quand cette clé et l'algorithme sont conservés, vos clients ne s'aperçoivent de rien ; quand vous changez de plateforme, il faut prévoir une réinitialisation et prévenir avant la bascule, sous peine d'une vague d'appels le jour J. Pour les commandes, trois stratégies existent : tout migrer, ne reprendre que les commandes récentes, ou basculer l'historique dans un espace de consultation en lecture seule. Le choix dépend de vos obligations de conservation et de la fréquence réelle des réclamations tardives dans votre métier.
Combien coûte une refonte de boutique PrestaShop ?
Aucun prix sérieux ne se donne avant d'avoir vu l'installation, et un forfait annoncé à l'aveugle se paye ensuite en avenants. Cinq facteurs font varier le budget : le scénario retenu, entre remise en état ciblée et reconstruction complète ; la complexité du catalogue, où les déclinaisons et les règles tarifaires pèsent bien plus que le nombre de références ; le parc de modules, avec les licences à renouveler et les développements spécifiques à reconstruire ; le nombre d'intégrations avec des systèmes tiers, chacune ajoutant sa propre recette ; et le périmètre éditorial, reprendre des textes existants n'ayant rien à voir avec la réécriture de centaines de fiches. L'audit préalable chiffre ces postes un par un avant tout engagement.
Combien de temps ma boutique sera-t-elle indisponible pendant la bascule ?
Une bascule bien préparée n'impose qu'une interruption courte, généralement le temps de figer les commandes, de synchroniser une dernière fois les données et de faire pointer le site vers la nouvelle installation. Ce n'est pas la durée d'indisponibilité qui compte, c'est le créneau. Nous choisissons une période de faible activité, avec une équipe complète disponible dans les heures qui suivent, et nous évitons les veilles de week-end, de jours fériés et les pics saisonniers. Nous évitons aussi de cumuler la refonte avec un changement de domaine ou d'hébergeur, car en cas d'anomalie il devient impossible de savoir laquelle des opérations est en cause. Une procédure de retour arrière écrite et testée accompagne systématiquement la mise en ligne.
Ma refonte est en ligne depuis deux mois et mon trafic a chuté : que faire ?
Il faut d'abord identifier la nature de la chute, car chaque symptôme a une cause distincte. Un effondrement du nombre de pages indexées trahit presque toujours une interdiction d'indexation restée active, des balises canoniques généralisées à tort ou des redirections défaillantes. Une explosion des adresses connues sans progression du trafic signale des pages de filtres non maîtrisées. Une hausse des erreurs serveur pointe des adresses oubliées dans le plan de redirections. Une baisse du taux de conversion à trafic constant désigne le tunnel de commande, souvent une étape cassée sur un navigateur ou un moyen de paiement. Le rattrapage est d'autant plus simple qu'il est précoce : à six mois, le moteur a oublié des milliers d'adresses qu'il faudra lui réapprendre.
Que deviennent mes modules payants et mes développements sur mesure ?
Il faut les traiter un par un, avec quatre informations pour chacun : son rôle réel dans l'exploitation, la vitalité de son éditeur, son coût de renouvellement et la conséquence de sa disparition. Cette dernière question révèle en général qu'un tiers du parc ne sert plus à personne. Certaines fonctions autrefois payantes sont devenues natives et n'ont plus à être achetées. Les modules réellement critiques et sans équivalent, connecteur de gestion ou passerelle de transporteur par exemple, décident du calendrier du projet, car il faut soit obtenir une version compatible, soit financer un remplacement. Attention enfin aux licences : elles ne sont pas toujours transférables d'une version majeure ou d'un domaine à l'autre, et ce poste doit figurer au devis.
Budget, délais réels et maintenance après la refonte
Il n'existe pas de prix standard pour une refonte de boutique PrestaShop, et toute agence qui annonce un tarif avant d'avoir vu l'installation vend un forfait qui se paiera en avenants. Ce qui fait varier le budget se compte pourtant sur les doigts d'une main. Le premier facteur est le scénario retenu : une montée de version encadrée sur une boutique proche du standard n'a aucun rapport avec une reconstruction propre assortie d'une reprise complète de l'historique. Le deuxième est le volume et la complexité du catalogue, où les déclinaisons et les règles tarifaires pèsent bien plus lourd que le nombre de références. Le troisième est le parc de modules, avec la part de développements spécifiques à reconstruire et les licences à renouveler. Le quatrième est le nombre d'intégrations avec des systèmes tiers, chaque connecteur d'ERP, de logistique ou de place de marché ajoutant sa propre recette. Le cinquième est le périmètre éditorial : reprendre tel quel des textes existants ne coûte presque rien, réécrire des centaines de fiches et de pages de catégorie représente un chantier à part entière.
Les délais obéissent aux mêmes déterminants. Sur les dossiers que nous menons, une montée de version bien préparée s'étale généralement sur quelques semaines entre le lancement et la bascule, une refonte complète avec reprise de données sur plusieurs mois, et un changement de plateforme sur une durée comparable ou supérieure selon la complexité des développements de remplacement. Ces fourchettes supposent une chose que nous rappelons toujours : la disponibilité du client. Les projets qui dérapent ne dérapent presque jamais sur le code, ils dérapent sur les validations en attente, les contenus promis qui n'arrivent pas, les accès à des prestataires tiers qu'on met trois semaines à obtenir, et les décisions reportées de réunion en réunion. Un dirigeant qui bloque deux heures par semaine dans son agenda pour son projet gagne davantage de temps que n'importe quelle optimisation de méthode.
Ce qui vient après, et qui décide de la valeur réelle du projet
Une refonte sans maintenance produit exactement la situation qui vous a conduit à refondre, avec un décalage de quelques années. C'est le point sur lequel nous insistons le plus auprès des marchands, parce qu'il détermine si l'investissement se rentabilise sur cinq ans ou s'il se déprécie dès la deuxième année. La maintenance d'une boutique recouvre des choses concrètes : appliquer les correctifs de sécurité de PrestaShop et des modules dans un délai raisonnable, tester ces mises à jour sur un environnement de préproduction avant de les passer en production, vérifier que les sauvegardes existent et se restaurent réellement, surveiller les temps de réponse et les erreurs, purger les données inutiles qui font grossir la base, contrôler périodiquement le tunnel de commande et les paiements, et suivre les indicateurs de visibilité pour réagir avant que le chiffre d'affaires ne bouge.
Ce suivi se combine naturellement avec le travail de référencement, car une boutique vivante publie de nouveaux produits, retire des références et fait évoluer son arborescence, et chacune de ces opérations a des conséquences sur les adresses et sur l'indexation. Un produit supprimé sans redirection, une catégorie renommée sans traitement de l'ancienne adresse, une page saisonnière dépubliée chaque année : ces gestes quotidiens reproduisent à petite échelle le problème de la refonte. Les traiter au fil de l'eau coûte quelques minutes ; les découvrir deux ans plus tard coûte un audit et une campagne de rattrapage. C'est la raison pour laquelle nous préférons accompagner une boutique dans la durée plutôt que de livrer un projet et de refermer le dossier.
Nous intervenons sur ces migrations depuis Arras et Lille, pour des e-commerçants de Douai, Lens, Béthune, Valenciennes, Amiens et Dunkerque comme pour des marchands parisiens et des entreprises réparties partout en France, avec les compétences réunies chez le même interlocuteur : développement, reprise de données, référencement, rédaction et exploitation. La façon la plus efficace d'avancer consiste à nous donner accès à votre boutique actuelle et à nous exposer ce que vous vendez, à qui, avec quelles contraintes de gestion et quelles échéances. Nous vous dirons quel scénario correspond à votre situation, ce qu'il représente en budget et en calendrier, ce qui est incompressible et ce qui peut attendre une seconde étape. Et s'il apparaît qu'une remise en état ciblée suffit à régler votre problème, nous vous le dirons aussi, même si cela nous conduit à vous vendre nettement moins que ce que vous étiez venu chercher. Vous pouvez aussi parcourir notre blog pour vous faire une idée de notre manière de traiter ces sujets, ou solliciter directement un consultant en référencement si votre question porte d'abord sur la visibilité.