Une boutique en ligne qui tourne depuis des années finit par se heurter à un mur. Le catalogue s’est étoffé, le thème s’est alourdi de modules, les pages mettent trois secondes à s’afficher sur mobile, et chaque nouvelle idée d’interface se négocie contre les contraintes du template. Le commerçant, lui, ne veut pas tout jeter : son back-office fonctionne, ses habitudes de gestion sont rodées, et son référencement représente des années de travail qu’il n’a aucune envie de sacrifier.
C’est exactement le point de départ d’un projet que nous avons mené récemment pour un disquaire spécialisé, dont le catalogue dépasse les quinze mille références. La boutique tournait sous PrestaShop, avec un lecteur audio pour écouter les extraits, une tarification différenciée entre particuliers et professionnels, et un référencement solide sur des milliers de fiches produits. L’objectif : une vitrine moderne et rapide, sans perdre une miette de l’existant. Voici comment nous nous y sommes pris, et pourquoi nous avons fait ces choix plutôt que d’autres.
Le problème du thème PrestaShop classique
Dans une installation PrestaShop standard, le même logiciel fait tout : il gère le catalogue, les commandes et les clients, et il génère aussi les pages HTML que voient les visiteurs. Cette approche est parfaitement viable pour beaucoup de boutiques. Elle montre ses limites quand on cherche une interface très rapide, très personnalisée, ou riche en interactions.
Le thème rend les pages côté serveur à partir de gabarits, avec une couche de modules qui s’empilent au fil du temps. Chaque module ajoute son JavaScript, ses feuilles de style, ses requêtes. On gagne en fonctionnalités, on perd en légèreté. Et quand on veut sortir des sentiers battus, par exemple un lecteur audio qui continue de jouer pendant qu’on navigue de fiche en fiche, on se bat contre l’architecture au lieu de s’appuyer dessus.
Ce qu’est une architecture headless, sans jargon
L’idée du « headless » (littéralement « sans tête ») est de séparer deux choses que PrestaShop réunit d’habitude : le moteur de commerce d’un côté, la vitrine de l’autre.
Le moteur, c’est PrestaShop, qui continue de gérer tout ce qu’il gère déjà : produits, stocks, prix, commandes, clients, paiement. Rien ne change de ce côté, et c’est un point que nous tenions à préserver. Le commerçant garde son back-office, ses modules, ses habitudes.
La vitrine, elle, devient une application distincte, construite avec Next.js, un framework web moderne fondé sur React. Cette application interroge PrestaShop en coulisses pour récupérer les données (le catalogue, les prix, le panier d’un client) et les affiche dans une interface entièrement sur mesure, rapide et fluide.
Les deux communiquent par une API. Le visiteur, lui, ne voit qu’une chose : un site qui répond vite et bien. Il ignore totalement qu’il y a deux briques derrière.
Pourquoi Next.js
Le choix du framework n’est pas anodin, et il a des conséquences directes sur le référencement. Une application web moderne peut afficher ses pages de deux façons. Soit le navigateur reçoit une page presque vide qu’il remplit ensuite avec du JavaScript, ce qui va vite pour l’utilisateur mais laisse une page blanche à Google au premier passage. Soit le serveur construit la page complète avant de l’envoyer, et le visiteur comme le moteur de recherche reçoivent directement du contenu prêt à lire.
Next.js sait faire le rendu côté serveur (SSR). Concrètement, quand une fiche produit est demandée, notre application appelle PrestaShop, récupère le prix et le stock à jour, insère ces données dans la page, puis envoie le tout au navigateur. Le client voit immédiatement le bon prix, sans flash ni délai, et Googlebot reçoit une page pleine, parfaitement indexable. C’est la condition non négociable pour ne pas saborder son référencement en passant au headless, et c’est précisément là que beaucoup de projets échouent.
Rendu serveur SSR contre rendu client pour l'indexation GoogleNext.js apporte aussi l’optimisation automatique des images, un atout considérable pour un catalogue de plusieurs milliers de visuels : conversion au format moderne, redimensionnement selon l’écran, compression sans perte visible. Sur des pages riches en pochettes de disques, le gain de poids est immédiat.
Le vrai risque d’une migration : le référencement
C’est le sujet qui fait perdre le sommeil à tout commerçant sérieux, et à juste titre. Changer de plateforme ne fait pas perdre de référencement en soi. Ce qui en fait perdre, c’est le changement d’adresses : quand une fiche produit qui vivait à une certaine URL depuis des années se retrouve à une adresse différente, Google doit tout réapprendre, les liens externes accumulés pointent dans le vide, et le trafic chute.
La parade habituelle consiste à mettre en place un plan de redirections, page par page, pour envoyer chaque ancienne adresse vers la nouvelle. C’est efficace mais laborieux, et la moindre oubli se paie en pages perdues. On a vu des migrations propres sur le papier perdre un tiers de leur trafic organique à cause d’un dossier renommé sans redirection.
Nous avons fait un choix plus radical et plus sûr : conserver des adresses strictement identiques. Notre front Next.js utilise exactement les mêmes URLs que le PrestaShop d’origine, pour les catégories, les fiches produits, les pages de contenu. Aucune redirection à maintenir, aucun risque d’en oublier une. Pour Google, l’adresse d’une fiche est la même qu’avant ; seul le contenu servi à cette adresse est devenu plus rapide et mieux structuré. Le patrimoine de référencement est préservé par construction, pas rattrapé après coup.
La bascule progressive, pilotée par le commerçant
Mettre un nouveau front en production, c’est un moment délicat. La méthode « big bang », où l’on bascule tout le monde d’un coup, expose l’intégralité des visiteurs au premier bug qui aurait échappé aux tests. Les équipes techniques aguerries lui préfèrent des approches progressives, où l’on n’expose la nouvelle version qu’à une fraction du trafic avant de généraliser.
Nous avons repris ce principe et l’avons rendu accessible directement au commerçant, depuis son back-office PrestaShop. Un réglage à trois positions y pilote toute la bascule :
En mode désactivé, tous les visiteurs voient l’ancien site. En mode par adresse, seules les personnes autorisées (le commerçant sur son propre ordinateur, par exemple) voient le nouveau front, pendant que tout le reste du public continue sur l’ancien. En mode complet, tout le monde passe sur la nouvelle vitrine.
L’intérêt est double. Le commerçant peut tester son nouveau site en conditions réelles, avec ses vrais produits et ses vraies commandes, sans qu’aucun de ses clients ne s’en aperçoive. Et le jour de la bascule complète, si quoi que ce soit clochait, le retour en arrière se fait en un clic, sans intervention technique, sans downtime. Ce filet de sécurité, souvent réservé aux grandes plateformes disposant d’équipes d’ingénierie dédiées, se retrouve ici entre les mains d’un commerçant indépendant.
Ce que le commerçant conserve, ce qu’il gagne
À l’arrivée, l’équilibre est celui que nous recherchions dès le départ.
Il conserve son back-office PrestaShop et toute sa logique de gestion. Il conserve ses URLs et son référencement. Il conserve ses fonctionnalités métier, y compris les plus spécifiques : le lecteur audio persistant qui accompagne la navigation, la tarification hors taxes réservée aux comptes professionnels, la restauration du panier d’un client d’une visite à l’autre, le tunnel de commande complet jusqu’au paiement.
Il gagne une vitrine nettement plus rapide, une interface libérée des contraintes du thème, et une base technique qui pourra évoluer sans qu’on ait à toucher au moteur de commerce. Le jour où il voudra ajouter une fonctionnalité au front, ou même changer une brique en arrière-plan, les deux parties évoluent indépendamment.
Ce que nous en retenons
Une architecture headless n’est pas une fin en soi, et ce n’est pas la bonne réponse pour toutes les boutiques. Elle prend tout son sens quand la performance et la liberté d’interface deviennent des enjeux réels, et quand le commerçant tient à préserver un existant qui fonctionne.
Le vrai travail n’est pas dans le branchement de l’API, qui est la partie la plus documentée. Il est dans les détails qui font qu’une migration réussit ou échoue : servir chaque donnée critique côté serveur pour l’indexation, préserver les adresses au caractère près, reconstruire à l’identique les fonctionnalités métier une par une, et sécuriser la mise en production pour qu’elle ne soit jamais un saut dans le vide. C’est là que se joue la différence entre une belle démonstration technique et une boutique qui continue de vendre le lendemain de la bascule.
Vous exploitez une boutique PrestaShop qui mérite une vitrine plus moderne, sans remettre en jeu votre référencement ? C’est le type de projet sur lequel nous intervenons. Parlons-en.
Commentaires