Bouton de retour en haut : un minuscule détail UX qui compte étonnamment

Dernière mise à jour : juin 2026, les notes d'implémentation s'appliquent à PrestaShop 1.7, 8 et 9. Le thème Classic par défaut n'intègre toujours pas de bouton de retour en haut ; le code ci-dessous est en JS natif, avec une zone tactile mobile de 44px.

Le bouton de retour en haut fait partie de ces détails que personne ne remarque tant qu'ils ne manquent pas, une petite flèche dans un coin qui ramène le client vers l'en-tête après qu'il a fait défiler une longue page jusqu'en bas. Il semble trop secondaire pour mériter qu'on s'y attarde. Mais dans une boutique PrestaShop, où les pages de catégories et de produits atteignent facilement plusieurs milliers de pixels de hauteur, la différence entre en avoir un ou non, c'est la différence entre un client à un appui de votre barre de recherche et un client qui fait défiler l'écran de son téléphone au pouce jusqu'à abandonner. Cet article explique comment ajouter ce bouton proprement dans PrestaShop : où il doit vivre dans le thème, comment l'ajouter sans modifier des fichiers que vous regretterez à la prochaine mise à jour, et les quelques erreurs qui transforment un bouton utile en élément qui recouvre votre bouton « Ajouter au panier ».

Si vous cherchez surtout à comprendre pourquoi ce bouton fait bouger les indicateurs, données d'engagement, angle abandon, nous avons développé cet argument dans bouton de retour en haut : petite amélioration UX, impact surprenant. Ici, nous restons du côté pratique : implémentation, mécanique PrestaShop et décisions qui font la différence.

Votre thème en a-t-il déjà un ? Vérifiez avant de construire

Premier point propre à PrestaShop : beaucoup de thèmes modernes incluent déjà un bouton de retour en haut, et vous êtes peut-être sur le point d'en ajouter un second. Le thème Classic par défaut de PrestaShop 1.7, 8 et 9 n'en inclut pas en standard. Une installation Classic de base doit donc l'ajouter. Mais la plupart des thèmes payants (et des thèmes dérivés de Warehouse) en proposent un, généralement activable depuis la page de configuration du thème sous Design → Thème & Logo ou dans le module de réglages du thème. Avant d'écrire une ligne de code, allez en bas d'une longue page de catégorie sur votre boutique en production et observez le coin de l'écran. Si un bouton apparaît déjà en fondu, votre travail relève de la configuration, pas du développement.

Pour confirmer d'où vient un bouton existant, affichez le code source et cherchez des marqueurs courants : un élément #back-to-top ou .scroll-to-top, ou un fragment de template dans votre thème sous themes/<yourtheme>/templates/ (souvent dans _partials/footer.tpl ou dans un fichier dédié scroll-top.tpl). S'il existe mais ne s'affiche pas, l'option du thème est simplement désactivée. C'est une case à cocher dans le back-office, pas un ticket développeur.

Les trois façons d'en ajouter un dans PrestaShop, et laquelle choisir

Si votre thème ne possède vraiment pas de bouton de retour en haut, vous avez trois voies réalistes. Elles diffèrent surtout sur un point qui compte davantage que la commodité dans PrestaShop : votre changement survit-il à une mise à jour du thème ou du cœur ?

La voie à éviter est celle qui paraît tentante : ouvrir footer.tpl dans votre thème actif et y coller le balisage. Cela fonctionne exactement jusqu'au moment où l'auteur du thème publie une mise à jour ; votre modification disparaît alors, et vous ne savez pas pourquoi. Si vous devez toucher aux templates, faites-le dans un thème enfant, nous expliquons pourquoi cette règle n'est pas négociable dans thèmes enfants : pourquoi vous ne devez jamais modifier le thème parent. Pour les approches plus propres sans modification de template, continuez.

La méthode propre : un bloc HTML personnalisé et quelques lignes de JS

L'approche qui évite de toucher aux fichiers du thème consiste à injecter le balisage du bouton via un bloc de contenu HTML et à charger son comportement via le custom.js du thème. Le thème Classic inclut themes/<yourtheme>/assets/js/custom.js (avec custom.css à côté) pour le JavaScript appliqué à tout le site. Attention toutefois : l'existence de ces fichiers et leur comportement lors des mises à jour dépendent du thème. Les modifier dans le thème parent actif reste une modification de fichiers du thème, et une mise à jour peut les écraser si le thème ou l'éditeur ne les préserve pas. Pour une vraie sécurité face aux mises à jour, préférez un thème enfant ou des ressources enregistrées via un module. Toute la discipline autour de leur usage sûr, et la raison pour laquelle ils valent mieux que la modification des fichiers groupés compilés du thème. Est détaillée dans CSS et JavaScript personnalisés dans PrestaShop sans casser les mises à jour.

Pour le balisage lui-même, vous ne voulez pas coder un <div> en dur dans un template. Un bloc HTML/module dédié placé dans la zone du pied de page fait l'affaire. Utilisez-en un qui prend en charge le point d'accroche cible (pour un bouton ancré au pied de page, un module accroché à displayFooter ou displayBeforeBodyClosingTag), ou créez votre propre petit module. Gardez en tête que le balisage ne peut être injecté que dans les points d'accroche pris en charge par un module et réellement rendus par le thème, pas littéralement n'importe où dans la boutique. La mécanique de placement des blocs personnalisés est expliquée dans blocs HTML : ajouter du contenu personnalisé partout dans votre boutique PrestaShop. Le bouton n'est qu'un lien ou un bouton accessible ; le JavaScript gère son apparition et le défilement fluide.

Une implémentation minimale et accessible tient réellement en une quinzaine de lignes, ce n'est pas un sujet de performance, et elle doit être en JS natif (le thème Classic embarque encore jQuery, mais s'y appuyer est fragile, beaucoup de thèmes tiers plus légers le retirent ou le chargent en différé, donc ne supposez pas que $() est disponible) :

• Balisage : un vrai <button type="button" id="back-to-top" aria-label="Back to top"> avec un glyphe flèche ou un SVG à l'intérieur, jamais un simple <div>, car une div n'est ni focalisable ni annoncée aux lecteurs d'écran.
• Affichage après défilement : un écouteur de défilement qui ajoute une classe visible dès que window.scrollY dépasse environ 300–500px (à peu près une hauteur d'écran). Limitez la fréquence de l'écouteur pour qu'il ne s'exécute pas à chaque pixel.
• Retour fluide : window.scrollTo({ top: 0, behavior: 'smooth' }) au clic, une seule ligne, native, sans bibliothèque d'animation.

Voici l'ensemble, balisage, affichage/masquage avec limitation de fréquence et défilement fluide natif. C'est du code natif, sans dépendance, qui respecte la préférence de mouvement du visiteur :

<!-- markup: a real button, focusable and announced -->
<button type="button" id="back-to-top" aria-label="Back to top">↑</button>

#back-to-top {
  position: fixed;
  right: 1rem;
  bottom: 1rem;           /* raise this if a cookie bar / chat sits here */
  width: 48px;
  height: 48px;          /* 44px+ tap target on mobile */
  opacity: 0;
  visibility: hidden;
  transition: opacity .2s ease;
  z-index: 1030;       /* deliberate, below banner/chat – test it */
}
#back-to-top.is-visible { opacity: 1; visibility: visible; }

const btn = document.getElementById('back-to-top');
let ticking = false;

window.addEventListener('scroll', () => {
  if (ticking) return;            // throttle to one check per frame
  ticking = true;
  window.requestAnimationFrame(() => {
    btn.classList.toggle('is-visible', window.scrollY > 400);
    ticking = false;
  });
}, { passive: true });

btn.addEventListener('click', () => {
  const reduce = window.matchMedia('(prefers-reduced-motion: reduce)').matches;
  window.scrollTo({ top: 0, behavior: reduce ? 'auto' : 'smooth' });
});

Le passive: true sur l'écouteur de défilement et la limitation via requestAnimationFrame sont les deux détails qui évitent de peser sur le thread principal de votre boutique ; la vérification de réduction des animations au clic est la petite attention d'accessibilité qui coûte une ligne. Enregistrez ce JS comme fichier externe via un point d'accroche de module plutôt que de le coller en ligne.

Envelopper cela dans un petit module conçu pour cet usage, plutôt que dans des fichiers épars, a un avantage qui mérite d'être nommé : il vous suit d'une boutique à l'autre et n'est pas lié au cycle de vie d'un seul thème. C'est le même raisonnement que pour gérer les animations au défilement comme une couche maîtrisée plutôt que comme des scripts intégrés directement et dispersés, le bouton et les mouvements de défilement subtils appartiennent à la même famille : des finitions front-end qui ne devraient pas vous obliger à dériver votre thème.

Les pièges propres à PrestaShop qui mordent vraiment

Un bouton circulaire de retour en haut se trouve dans le coin inférieur droit d’une page produit de la boutique.

Le bouton lui-même est trivial. Ce qui casse sur de vraies boutiques PrestaShop, c'est tout ce qui partage le coin inférieur droit avec lui. Les installations PrestaShop accumulent des widgets flottants, et ils veulent tous le même emplacement.

• Bannières de consentement cookies et RGPD. Les modules de consentement et de conformité cookies courants sur les boutiques PrestaShop, qu'il s'agisse d'un module de conformité légale ou d'une CMP tierce, se fixent généralement en bas de la fenêtre. Un bouton de retour en haut qui les ignore finit soit caché derrière la bannière, soit posé sur le bouton « Accepter ». Placez le bouton en bas à droite et laissez à la bannière toute la bande inférieure, ou remontez le bouton au-dessus de la hauteur de la bannière pendant qu'elle est affichée.
• Widgets de chat en direct (Crisp, Messenger, tawk.to). Ils se fixent presque tous en bas à droite, exactement là où la convention place le bouton de retour en haut. Ne luttez pas contre eux : empilez le bouton au-dessus de la bulle de chat avec un décalage bottom supplémentaire, afin qu'un client n'ait jamais à choisir entre « nous parler » et « remonter en haut ».
• La guerre d'empilement du z-index. C'est le défaut le plus courant. Les widgets de chat et modules de consentement définissent souvent des valeurs z-index très élevées, et votre bouton peut se retrouver rendu sous eux. Visible mais impossible à cliquer, ce qui est pire que son absence. Définissez un z-index intentionnel et testez en cliquant réellement sur le bouton sur mobile avec la bannière cookies et le chat actifs, pas sur une page de préproduction propre où aucun des deux n'existe.
• Les en-têtes fixes changent le calcul. Beaucoup de thèmes PrestaShop (et les options d'en-tête fixe dans les thèmes payants) gardent la navigation, la recherche et le panier épinglés en haut pendant le défilement. Si c'est votre cas, le bouton est moins indispensable, la recherche et le panier restent déjà accessibles, mais il mérite toujours sa place pour revenir à la bannière principale, aux filtres en haut d'une catégorie ou au début d'un long article de blog. Sur un thème avec en-tête fixe, rendez le bouton un peu plus petit et discret ; c'est une commodité, pas une bouée de sauvetage.

Là où il gagne sa place dans une boutique PrestaShop

Toutes les pages n'en ont pas le même besoin. Le bouton est le plus rentable précisément là où les pages PrestaShop deviennent les plus longues, et cela vaut la peine de savoir lesquelles pour le contrôler là où cela compte :

• Le mobile, avant tout. La fenêtre plus petite impose davantage de défilement pour le même contenu ; un utilisateur sur téléphone parcourt donc beaucoup plus de hauteurs d'écran qu'un utilisateur sur ordinateur sur la même page de catégorie. Si vous ne devez réussir le bouton que sur un seul type d'appareil, réussissez-le sur mobile, et respectez-y la cible tactile minimale de 44–48px.
• Les longues pages de catégorie avec plus de 30 produits, filtres de recherche à facettes, défilement infini ou pagination profonde. Quand un client atteint le produit n° 35, l'en-tête est réellement à des milliers de pixels.
• Les pages produit riches en contenu avec longues descriptions, tableaux de caractéristiques, avis et carrousels de ventes croisées, elles dépassent régulièrement 5 000px.
• Les pages blog et CMS. Vos contenus statiques et éditoriaux comptent souvent parmi les défilements les plus profonds de tout le site. Pendant que vous améliorez ces pages, la navigation CMS elle-même mérite aussi d'être clarifiée, des libellés de menu plus explicites pour les pages statiques aident les clients qui remontent en haut à trouver réellement où aller ensuite, comme nous l'expliquons dans noms d'affichage des pages CMS : une meilleure navigation pour vos pages statiques.

Bien régler le comportement

Quelle que soit la méthode choisie, les mêmes petits détails séparent un bouton qui paraît natif d'un bouton qui semble ajouté après coup :

• Apparaître seulement après défilement. L'afficher tout en haut de la page n'est qu'un bruit visuel inutile. Faites-le apparaître une fois que le client a dépassé environ une hauteur d'écran.
• Défilement fluide, pas téléportation. Un saut instantané vers le haut désoriente. Le client ne sait plus s'il a défilé ou s'il a atterri sur une nouvelle page. Un défilement fluide de 300–500ms préserve son repère spatial.
• Fondu, pas rebond. Un fondu subtil d'environ 200ms en entrée et en sortie donne une impression soignée. Les animations qui rebondissent, glissent ou pulsent attirent une attention que le bouton ne mérite pas ; il doit être repérable, pas distrayant.
• Accessible dès la conception. Un vrai <button> ou <a> (focalisable et annoncé), un aria-label, un anneau de focus clavier visible et un contraste suffisant avec le fond de page sur lequel il flotte. Ces points ne coûtent rien à intégrer dès la construction et sont pénibles à ajouter après coup.

Faut-il le mesurer ?

Vous pouvez, et sur une boutique fréquentée cela vaut quelques minutes : déclenchez un événement d'analyse à chaque clic sur le bouton. Vous saurez ainsi quelle part des sessions sur les longues pages l'utilise réellement, et quelles pages génèrent le plus de clics, souvent un signal utile pour repérer vos pages les plus profondes et les plus engageantes. Traitez tout pourcentage lu ailleurs comme une indication, pas comme un objectif ; le chiffre honnête dépend entièrement de la longueur de vos pages et du comportement de vos clients, donc lisez-le dans votre propre boutique plutôt que de faire confiance à un chiffre de blog.

Le bouton de retour en haut est une chose rare en UX e-commerce : une amélioration presque sans contrepartie. Il coûte quelques lignes, consomme des ressources négligeables, aide les clients qui en ont besoin et reste invisible pour les autres. La seule façon de se tromper dans PrestaShop est de l'ajouter négligemment, en modifiant le thème parent, ce qui le fera disparaître à la prochaine mise à jour, ou en le déposant dans un coin déjà revendiqué par votre bannière cookies et votre widget de chat. Ajoutez-le proprement, à un endroit qui survit aux mises à jour, et testez-le là où les widgets flottants vivent réellement. Puis oubliez-le, ce qui est précisément ce qu'un bon détail UX doit vous permettre de faire.

Questions fréquentes

Le thème par défaut de PrestaShop inclut-il un bouton de retour en haut ?

Non. Le thème Classic de PrestaShop 1.7, 8 et 9 est livré sans ce bouton, donc une installation Classic standard doit l'ajouter. Beaucoup de thèmes payants et dérivés de Warehouse en incluent un, généralement activable dans les réglages propres au thème. Avant de construire quoi que ce soit, descendez en bas d'une longue page de catégorie sur votre boutique en production, si un bouton apparaît déjà en fondu, votre travail consiste à activer une case dans le back-office, pas à écrire du code.

Quelle est la méthode la plus propre pour l'ajouter sans casser les mises à jour ?

Placez le balisage dans un bloc HTML du back-office sur un point d'accroche de pied de page comme displayFooter ou displayBeforeBodyClosingTag, et enregistrez le JavaScript comme fichier externe via un petit module, rien n'est modifié dans l'arborescence du thème, donc une mise à jour du thème ne peut pas l'effacer. Modifier footer.tpl dans le thème parent actif est la voie à éviter ; si vous devez toucher aux templates, faites-le dans un thème enfant.

Dois-je utiliser jQuery pour la logique de défilement ?

Non, écrivez-la en JavaScript natif. Le thème Classic embarque encore jQuery, mais beaucoup de thèmes tiers plus légers le retirent ou le chargent en différé, donc vous ne pouvez pas supposer que $() est disponible. Tout le bouton tient en une quinzaine de lignes de JS simple : un écouteur de défilement limité en fréquence qui active une classe de visibilité après environ 400px, puis window.scrollTo({ top: 0, behavior: 'smooth' }) au clic. Aucune bibliothèque nécessaire.

Mon bouton est visible, mais je ne peux pas cliquer dessus. Pourquoi ?

C'est le défaut le plus fréquent, un conflit d'empilement de z-index. Les widgets de chat et bannières de consentement définissent souvent des valeurs z-index très élevées, si bien que votre bouton est rendu sous eux : visible mais non cliquable, ce qui est pire que son absence. Définissez un z-index intentionnel et testez en cliquant réellement sur mobile avec la bannière cookies et le chat actifs, pas sur une page de préproduction propre où aucun des deux n'existe.

Comment éviter qu'il recouvre ma bannière cookies ou ma bulle de chat ?

Les trois veulent le coin inférieur droit. Donnez à la bannière de consentement toute la bande inférieure et gardez le bouton dans le coin, ou augmentez le décalage bottom du bouton pendant que la bannière est affichée. Pour une bulle de chat, empilez le bouton au-dessus avec un décalage supplémentaire afin qu'un client n'ait jamais à choisir entre « nous parler » et « remonter en haut ». Vérifiez toujours avec les deux widgets actifs.

À quelle distance de défilement le bouton doit-il apparaître ?

Environ une hauteur d'écran, autour de 300–500px vers le bas. L'afficher tout en haut de la page n'est qu'un bruit visuel inutile ; le révéler seulement après que le client a défilé lui donne une présence intentionnelle. Limitez la fréquence de l'écouteur de défilement (une garde requestAnimationFrame plus un écouteur passif) afin que la vérification s'exécute au maximum une fois par frame et reste hors du thread principal.

Doit-il être accessible, et comment ?

Oui, et c'est peu coûteux à bien faire dès la construction. Utilisez un vrai <button> ou <a> plutôt qu'un <div> stylisé afin qu'il soit focalisable et annoncé, ajoutez un aria-label="Back to top", conservez un anneau de focus clavier visible, assurez un contraste suffisant avec le fond de page et respectez prefers-reduced-motion en revenant à un saut instantané. Les ajouter après coup est bien plus pénible que de les inclure dès le départ.

Le bouton vaut-il encore le coup si mon thème a un en-tête fixe ?

Il est moins indispensable, mais reste utile. Un en-tête fixe garde la recherche et le panier accessibles, donc le bouton n'est pas une bouée de sauvetage, mais il aide encore un client à revenir à la bannière principale, aux filtres en haut d'une catégorie ou au début d'un long article de blog. Sur un thème avec en-tête fixe, rendez le bouton un peu plus petit et discret afin qu'il soit perçu comme une commodité plutôt que comme un élément fixe concurrent.

Guides associés

• Bouton de retour en haut : petite amélioration UX, impact surprenant
• CSS et JavaScript personnalisés dans PrestaShop sans casser les mises à jour
• Animations au défilement : ajouter un mouvement subtil aux pages de votre boutique