PrestaShop · refonte front-end
Rose Velours coud à la main des sapins, des cœurs et des étoiles lumineux, à Mazan, en Vaucluse. La marque avait une maquette Figma et une boutique PrestaShop en production — mais aucun environnement de test, et pas question de la fermer pour travailler. J’ai donc refondu le front-end en direct, par lots, avec la possibilité de revenir en arrière à chaque instant.
Ce qu’en dit la cliente
Merci une nouvelle fois à Aimé pour son travail. Tout a été parfaitement réalisé, et très rapidement en plus.
Avis vérifié sur Malt · septembre 2026
La boutique aujourd’hui
Une décoration artisanale se vend par l’image : du velours chiné, des guirlandes allumées, une maison provençale. La maquette Figma l’avait compris — grands visuels, typographie sobre, beaucoup d’air. Encore fallait-il la faire entrer dans un thème PrestaShop du commerce, sans le réécrire.
Toute l’intégration a été mesurée sur l’export de la maquette, pas estimée à l’œil : largeur de contenu, hauteur du bandeau, retraits de l’en-tête, échelle typographique, palette. Quand une valeur ne pouvait pas être respectée, l’écart a été écrit dans le journal du projet plutôt que passé sous silence.
En chiffres
L’audit d’abord
Avant de toucher au design, j’ai relevé l’état réel du front-office. Cinq défauts sortaient du cadre de la refonte, mais aucun ne pouvait rester.
Le thème déclarait Cabin, mais le champ « Google Fonts » du back-office contenait la balise HTML entière au lieu de la seule adresse. Résultat : une erreur 404, et tout le site affiché dans la police par défaut du navigateur.
Paiement sécurisé, fabrication artisanale, Made in France, service client : les quatre icônes renvoyaient une erreur 404, sur toutes les pages du site.
Le bandeau annonçait la livraison offerte, mais le seuil était réglé à zéro dans PrestaShop, c’est-à-dire désactivé. La boutique ne l’avait donc jamais accordée. Remis à la valeur de la maquette.
Le module de filtres était bien installé, mais sans aucun modèle configuré : il ne proposait donc rien, nulle part. Un modèle a été créé et appliqué aux 62 catégories.
Six images sur vingt-trois n’avaient ni largeur ni hauteur déclarées. Combiné au chargement différé, cela décalait le contenu sous les yeux du visiteur.
Un module publicitaire appelait une API avec un jeton expiré à chaque chargement : sans effet visible, mais une requête inutile et une erreur en console sur chaque page.
Deux pages refaites
La collection et la fiche produit portent l’essentiel de la vente. Elles ont été reprises écran par écran, valeur par valeur, puis contrôlées dans un vrai navigateur.
Matière, taille, prix, sous-catégorie : les filtres reprennent le vocabulaire de la marque — velours, fourrure, Small 1 m, Medium 1 m 45. La grille passe à trois colonnes quand la colonne de filtres apparaît, et à quatre sur les grands écrans. Un défaut du thème, qui posait les filtres au-dessus de la grille au lieu d’à côté, a été corrigé au passage.
Voir une collection
Grande galerie qui sert les photos d’origine plutôt qu’un carré rogné, matières en pastilles, tailles en boutons, guide des dimensions à portée, conseil de pose, et une vidéo par fiche quand la marque en fournit une. Sur mobile, le premier visuel occupe toute la hauteur de l’écran.
La méthode
Sans environnement de test, la prudence ne se décrète pas, elle s’outille. Le thème d’origine a d’abord été copié en entier et comparé fichier par fichier au serveur, puis figé dans un dépôt Git. Ensuite, chaque envoi a suivi la même règle : jamais un dossier entier, toujours des fichiers nommés un par un, et la version en ligne rapatriée juste avant d’être remplacée.
Un retour arrière ne consiste donc pas à espérer : il consiste à renvoyer le fichier d’avant. La procédure a été testée pour de vrai, pas supposée.
Elle a servi. Entre le lot 37 et le lot 41, j’ai construit un bandeau d’annonce à messages successifs, à partir de captures d’écran… qui venaient d’un autre projet, transmises par erreur. Tout a été défait le jour même : fichiers restaurés depuis le commit d’avant, module désinstallé, réglages remis à la valeur de la maquette, puis vérification que plus aucune trace ne subsistait dans les pages servies. C’est ce genre d’épisode qui décide si une méthode vaut quelque chose.
Ce que ce projet illustre
Le thème utilisé ici embarque huit variantes d’en-tête pour ordinateur, trois pour mobile et cinq pieds de page ; une seule de chaque est active, et le choix vit en base de données, pas dans les fichiers. Modifier le mauvais fichier ne produit aucun effet visible : le premier travail est donc de savoir ce qui sert réellement.
Deuxième enseignement, propre à PrestaShop : une partie de la boutique n’est pas dans le code. La composition de l’accueil, le méga-menu, les images de contenu, les réglages du thème et le vidage du cache vivent dans l’administration. Chaque lot précisait donc ce qui partait par FTP et ce qui restait à faire au back-office, pour qu’aucune modification ne soit perdue au premier enregistrement.
C’est la ligne que je tiens sur toutes mes missions PrestaShop : ne jamais toucher au cœur, garder le thème d’origine intact, et livrer un travail qu’un autre développeur pourra reprendre sans archéologie.
On peut travailler sur une boutique qui vend, à condition de pouvoir revenir en arrière à chaque étape. Parlons de la vôtre.
Six boutiques PrestaShop suivies depuis 2022 : maintenance, modules sur mesure, landing pages, intégrations fournisseurs et APIs transporteurs. Un parc géré comme un ensemble, pas boutique par boutique.
Lire l'étude de cas
Migration complète de Shopify vers WooCommerce : reconstruction avec Gutenberg et Kadence, correspondance des URLs, reprise des avis Judge.me, livraison Boxtal et paiement Sogecommerce, le tout prêt et validé en préproduction.
Lire l'étude de cas
Migration de Shopify vers WooCommerce menée à partir d’une analyse de l’existant : reconstruction, migration des données, préservation du SEO et des URLs, et adaptation des fonctionnalités à WooCommerce.
Lire l'étude de cas