jQuery dans PrestaShop 8 et 9 : ce qui change vraiment pour votre boutique

Ouvrez l'inspecteur réseau de n'importe quelle boutique PrestaShop 8 ou 9, ancienne ou fraîchement installée : parmi les premières requêtes, il y a jQuery. En 2026, alors que le reste du web a tourné la page des frameworks DOM, la plateforme e-commerce open source la plus utilisée de France francophone embarque encore cette bibliothèque de 2006. Réaction fréquente des développeurs qui découvrent ça : crier à la dette. Réaction des gens qui maintiennent une boutique en production : vérifier ce qui casserait si on l'enlevait. Cet article prend le parti du second groupe. Nous allons voir pourquoi jQuery est encore là, comment PrestaShop le charge exactement, dans quels cas vous devez le garder, comment l'alléger sans rien casser, et ce que la voie headless change à l'équation.

Pourquoi jQuery est encore là dans PrestaShop 8 et 9

La réponse tient en un mot : l'écosystème. Des dizaines de milliers de modules existent sur le marché officiel et chez les éditeurs indépendants, et une part écrasante d'entre eux s'appuient sur jQuery pour leur interface — sélecteurs, événements, appels AJAX. Retirer la bibliothèque du socle, c'est déclarer obsolète du jour au lendemain une partie du catalogue d'extensions qui fait la valeur pratique de la plateforme. PrestaShop a fait ce calcul il y a des années et l'a refait à chaque version majeure : le coût de la compatibilité l'emporte sur le gain de la pureté technique.

Ce choix se traduit par un contrat implicite : toute page du front-office comme du back-office met à disposition jQuery et ses extensions historiques. Les thèmes du marché sont bâtis dessus, les modules s'appuient dessus, les tutoriels de la documentation officielle l'utilisent dans leurs exemples de code frontal. Quand vous installez PrestaShop 9, vous n'installez pas un front moderne débarrassé de ses anciens réflexes : vous installez une plateforme qui promet à son écosystème que $ existera.

Il faut le dire honnêtement : ce n'est pas de la paresse. La question « pourquoi ne pas passer à du JavaScript vanilla » a été posée cent fois dans les discussions du projet, et la réponse a toujours été la même — casser des milliers de modules pour économiser trente kilo-octets n'est pas un échange raisonnable pour des boutiques qui vivent de leurs extensions. Vous pouvez juger ce compromis discutable, il a au moins le mérite d'être explicite.

Comment PrestaShop charge jQuery, concrètement

Dans le thème classique comme dans la plupart des thèmes du marché, le chargement est orchestré par le gabarit scripts.tpl du thème, appelé depuis les layouts de pages. Vous y trouverez les appels qui insèrent la feuille de route des scripts : jQuery d'abord, puis les extensions (jQuery UI pour les widgets d'interface, jquery-migrate pour la rétrocompatibilité), puis le code du thème. L'ordre n'est pas décoratif : chaque brique suppose que la précédente est déjà interprétée.

Ce chargement est doublé d'une second mécanique moins visible : les modules qui déclarent leurs propres scripts via les hooks d'en-tête. Et c'est là que naît le vrai désordre des boutiques vieillissantes. Un module mal élevé ré-inclut sa propre copie de jQuery, parfois une version différente, parfois depuis un CDN tiers. Résultat mesuré sur des audits réels : deux, trois, parfois quatre copies de la même bibliothèque interprétées sur une même page, chacune écrasant les plugins enregistrés par la précédente. L'erreur $().datepicker is not a function qui apparaît « sans raison » après l'installation d'un module a presque toujours cette origine.

Pour localiser les coupables, la démarche est mécanique :

• ouvrez la page avec l'inspecteur réseau filtré sur « js » et comptez les requêtes dont le nom contient « jquery » — au-delà d'une, vous avez un doublon ;
• cherchez dans le code des modules installés (dossier modules/) les occurrences de « jquery » dans les gabarits et les contrôleurs qui injectent des scripts ;
• vérifiez le gabarit scripts.tpl de votre thème : il est éditable, et c'est le premier endroit où un précéd développeur a pu laisser une copie figée ;
• désactivez temporairement les modules un à un en environnement de test jusqu'à voir disparaître la requête en trop — méthode lourde mais infaillible.

Ce diagnostic est le seul geste technique rentable avant toute décision : on n'allège bien que ce qu'on a mesuré.

Les cas où vous devez garder jQuery — et l'assumer

Si votre boutique utilise des modules du marché pour des fonctions visibles — carrousel de page d'accueil, sélecteur de déclinaisons avancé, zoom sur fiches produit, wishlist, chat — jQuery reste. Ces modules injectent des comportements qui s'accrochent au DOM via la bibliothèque, et leur code n'existe pas en version alternative. Vous pouvez le déplorer, vous ne pouvez pas le réécrire : le code source des modules commerciaux n'est pas à vous.

Garder jQuery impose alors une contrepartie que peu de maintenance prévoient : suivre ses correctifs. La bibliothèque a connu ses propres vulnérabilités — falsification de propriété Object.prototype sur les anciennes versions, ReDoS dans l'analyseur d'expressions — et une copie figée dans un thème depuis trois ans ne reçoit rien de ces correctifs. La référence officielle de l'API jQuery documente les comportements attendus version par version : c'est la boussole quand un module exige « jQuery 1.x » et que vous ne savez plus ce que vous avez le droit de monter.

La dette frontale ne se rembourse pas en la niant : elle se rembourse en l'inventoriant, en la figeant volontairement là où elle est raisonnable, et en traçant une frontière nette au-delà de laquelle le nouveau code n'y touche plus.

La position pragmatique, celle que nous recommandons aux gérants qui nous consultent : jQuery est un composant comme les autres. Il a une version, des correctifs, un périmètre — et une règle : le nouveau code que vous écrivez n'en dépend plus. La dette cesse de croître, c'est déjà la moitié du travail.

Alléger jQuery sans le retirer : les gains réalistes

Entre « tout garder tel quel » et « tout réécrire », il existe une palier intermédiaire : réduire l'empreinte et le périmètre de la bibliothèque sans rompre le contrat des modules. Les leviers sont connus, il faut surtout les appliquer dans l'ordre et mesurer à chaque étape.

Le premier est la suppression de jquery-migrate. Cette extension ne sert qu'à faire tourner du code écrit pour jQuery antérieur à la version 1.9 — elle restaure les API retirées et journalise leurs usages dans la console. Si aucun de vos modules n'est antique, elle ne fait qu'ajouter du poids et masquer les avertissements qui vous préviendraient qu'un module est plus vieux que prévu. La méthode : la désactiver en environnement de test, surveiller la console sur les pages clés pendant une semaine de navigation réelle, et ne rétablir que si un module proteste.

Le deuxième levier est le chargement conditionnel : toutes les pages n'ont pas besoin de la machinerie. La page de contenu institutionnel d'une vitrine n'a rien à faire avec jQuery UI et ses widgets ; le tunnel de commande, lui, en vit probablement. Conditionner l'inclusion au contrôleur concerné, dans le gabarit du thème, retire des dizaines de kilo-octets aux pages qui n'en ont aucun usage — et ce sont souvent les pages à fort trafic SEO.

Le tableau suivant résume les quatre stratégies possibles et leur échange réel :

Une précision d'honnêteté technique : jQuery minifié et compressé représente environ trente kilo-octets, cache chaude. Ce n'est pas le gouffre que certains articles de blog vendent. Le coût réel est ailleurs — dans les copies multiples, les extensions UI chargées pour rien, et le code applicatif qui s'accumule par-dessus. C'est pourquoi l'allègement passe d'abord par l'inventaire, jamais par la suppression aveugle.

La sortie par le haut : thème maison, puis front headless

Le jour où la question n'est plus « comment alléger » mais « comment ne plus en dépendre », deux chemins s'ouvrent. Le premier est le thème maison en JavaScript standard : tout est possible, le navigateur moderne couvre nativement ce pour quoi jQuery a été inventé — querySelector pour les sélecteurs, fetch pour AJAX, addEventListener pour les événements. Le thème classique de PrestaShop est un point de départ documenté, et nous détaillons cette mécanique dans notre retour d'expérience sur la construction d'un hub Pro avec PrestaShop headless et Nuxt. Mais soyez lucide : si votre boutique dépend de modules frontaux du marché, le thème sans jQuery ne les rend pas compatibles — il les casse. Cette voie n'est saine que pour des boutiques à périmètre de modules maîtrisé.

Le second chemin est le headless : PrestaShop devient la couche de données — catalogue, commandes, clients, stocks — exposée par son API, et le frontal que vous bâtissez décide de ses propres dépendances. jQuery cesse d'être votre problème parce que le front n'est plus PrestaShop. C'est une refonte, pas un correctif : nous en avons décrit le coût et les arbitrages dans notre comparatif entre PrestaShop headless et Shopify, et l'architecture d'exécution — conteneurs, isolation, supervision — dans notre guide sur l'architecture multi-conteneurs PrestaShop headless en production.

Ce chemin a un coût d'entrée réel, mais il a ceci de définitif : la question « que fait-on de jQuery » ne se reposera plus jamais, parce qu'elle est devenue une décision qui vous appartient au lieu d'un héritage que vous subissez. Les équipes qui industrialisent cette frontière — déploiement continu, tests automatisés du front — en profitent d'ailleurs au-delà du poids des scripts, comme nous le racontons dans notre retour sur la CI/CD d'un PrestaShop headless déployé par GitHub Actions.

Migrer de PrestaShop 8 vers 9 : ce que jQuery change dans votre plan

La version 9 de PrestaShop ne bouleverse pas la donne : jQuery demeure au front-office, le thème classique demeure compatible, et l'essentiel des ruptures de la migration se joue ailleurs — PHP, schéma, back-office. Mais la migration est précisément le moment où le désordre frontal accumulé pendant des années se paie : scripts dupliqués, versions figées, dépendances non déclarées. Autant nettoyer avant de déplacer.

La séquence qui a fait ses preuves sur nos migrations :

• inventorier les modules qui chargent ou dépendent de jQuery, et vérifier leur compatibilité déclarée avec la version 9 avant tout le reste ;
• reproduire la boutique cible dans un environnement d'exécution isolé — notre configuration Docker Compose de PrestaShop en production sert aussi de base d'environnement de test ;
• supprimer les doublons de chargement détectés, en commençant par les copies de modules, avant de toucher au gabarit du thème ;
• tester la migration sans jquery-migrate pour révéler les modules réellement anciens — leurs plaintes en console valent inventaire ;
• valider les parcours critiques (fiche produit, panier, tunnel, compte client) sur mobile et desktop avant de basculer.

Après la bascule, tenez une règle simple : chaque nouveau développement frontal s'écrit en JavaScript standard, jQuery ne servant qu'aux modules qui l'exigent. La dette gèle au lieu de croître, et la prochaine migration en sera d'autant plus simple.

Le référencement ne paie pas votre jQuery — mais il compte les millisecondes

Restons mesurés : aucun classement ne s'est effondré pour trente kilo-octets de bibliothèque locale et cachée. Les signaux de performance de Google — les Core Web Vitals, dont l'Interaction to Next Pin — regardent la réactivité mesurée chez vos visiteurs, pas votre stack en particulier. Mais une page qui interprète trois copies de jQuery avant de pouvoir répondre au premier clic, elle, dégrade réellement ce signal, surtout sur mobile d'entrée de gamme en réseau médiocre.

La hiérarchie des priorités SEO est donc simple à énoncer : corrigez d'abord les contenus et la structure — c'est là que se gagne la visibilité —, puis traitez la performance quand elle est mesurée comme traînante, en commençant par les doublons de scripts qui coûtent le plus pour le moindre risque. Notre retour d'expérience sur un pipeline SEO automatisé sur PrestaShop montre cet ordre de grandeur à l'œuvre : les gains de contenu dominent toujours, la performance vient consolider.

En résumé : jQuery dans PrestaShop 8 et 9 n'est ni un scandale ni un détail. C'est une dépendance d'écosystème, gérable par l'inventaire, l'allègement mesuré et une frontière nette pour le nouveau code — et définitivement soluble le jour où le front vous appartient.