Le débat Hummingbird contre Classic se joue presque toujours sur le même argument : « Hummingbird supprime jQuery ». C’est l’argument le plus répété, y compris dans la version précédente de cet article, et il ne survit pas à l’ouverture d’un package.json.
Ce qui suit est la comparaison faite sur les dépôts officiels des deux thèmes, à leur version courante : Hummingbird v2.1.0, publiée le 14 juillet 2026, et Classic, dont la dernière version est la 3.1.2 du 11 mai 2026. Le vrai argument en faveur de la migration existe, il est même plus fort que celui qu’on cite, mais ce n’est pas celui-là.
Au programme :
- La version de Bootstrap que Classic embarque réellement, et pourquoi elle change la discussion
- Ce que « sans jQuery » veut dire exactement, et ce que ça ne vous fera pas gagner
- La différence de fond entre les deux thèmes, qui n’est ni le SEO ni la vitesse
- Ce que la migration ne vous apportera pas
Le chiffre qui décide, et ce n’est pas celui qu’on cite
Les comparatifs opposent en général « Bootstrap 4 » à « Bootstrap 5 ». La réalité est ailleurs. Voici les dépendances déclarées par le thème Classic :
// classic-theme, _dev/package.json (branche develop)
"devDependencies": {
"bootstrap": "4.0.0-alpha.5",
"bootstrap-touchspin": "^3.1.1",
"jquery": "^3.7.1",
"jquery-touchswipe": "^1.6",
"jquery.browser": "^0.1.0",
"sass": "^1.79.3"
}
Ce n’est pas Bootstrap 4. C’est Bootstrap 4.0.0-alpha.5, une préversion publiée en 2016, sur laquelle la version stable de Bootstrap 4 a introduit des changements de nommage et de grille. Le thème par défaut de PrestaShop 1.7 et 8 tourne donc sur une alpha vieille de dix ans, jamais montée jusqu’à la version stable du framework qu’elle utilise.
Face à ça, Hummingbird déclare "bootstrap": "5.3.3", en dépendance de production.
Cette seule ligne justifie mieux la migration que tous les arguments de conversion réunis. Elle explique pourquoi les correctifs CSS s’accumulent sur les boutiques Classic anciennes, pourquoi les classes utilitaires ne se comportent pas comme la documentation Bootstrap le décrit, et pourquoi les composants tiers récents s’y intègrent mal.
« Hummingbird supprime jQuery » : ce qui est vrai, et ce qui ne l’est pas
Regardons les dépendances de Hummingbird v2.1.0 :
// hummingbird, package.json (v2.1.0)
"dependencies": {
"@popperjs/core": "^2.11.8",
"bootstrap": "5.3.3",
"jquery": "^3.7.1",
"jquery-touchswipe": "^1.6",
"jquery.browser": "^0.1.0"
}
jQuery 3.7.1 est bien là, en dépendance de production, accompagné des deux mêmes greffons que Classic. Le thème l’embarque et le charge.
En revanche, le code du thème ne s’en sert pas. Vérification faite sur les six fichiers d’entrée de src/js/ :
theme.ts 108 lignes | imports jQuery : aucun | appels $( : 0
prestashop.ts 9 lignes | imports jQuery : aucun | appels $( : 0
product.ts 83 lignes | imports jQuery : aucun | appels $( : 0
quickview.ts 154 lignes | imports jQuery : aucun | appels $( : 0
form-validation.ts 27 lignes | imports jQuery : aucun | appels $( : 0
mobile-menu.ts 101 lignes | imports jQuery : aucun | appels $( : 0
La formulation exacte est donc : les composants de Hummingbird sont écrits sans jQuery, mais jQuery reste servi au navigateur. Il est là pour l’écosystème, parce que l’immense majorité des modules PrestaShop du marché suppose que $ est disponible globalement. Le retirer casserait le catalogue de modules du jour au lendemain.
La conséquence est importante pour qui décide d’un budget : le gain de poids que vous attendez de « la fin de jQuery » n’arrive pas le jour de la migration. Il arrivera le jour où vos propres modules n’en auront plus besoin, et ce jour-là ne dépend pas du thème. Promettre l’inverse, c’est promettre une amélioration que la mesure ne montrera pas.
La vraie différence est ailleurs
Ni le SEO ni la vitesse ne sont l’argument central, parce que les deux dépendent bien davantage de vos modules, de vos images et de votre hébergement que de votre thème. Ce qui sépare réellement les deux thèmes, c’est la nature du code que vous allez faire vivre pendant les cinq prochaines années.
Hummingbird v2.1.0, c’est 72 fichiers TypeScript compilés avec TypeScript 5.5.4, et des fichiers de test posés à côté des composants qu’ils couvrent :
src/js/components/useAlert.ts
src/js/components/useAlert.test.ts
src/js/components/useQuantityInput.ts
src/js/components/useQuantityInput.test.ts
src/js/components/useProgressRing.ts
src/js/components/useProgressRing.test.ts
src/js/accessibility/cart.ts
src/js/accessibility/product.ts
Trois choses s’y lisent directement. Le code est typé, donc une erreur d’intégration se voit à la compilation plutôt qu’en production. Il est testé. Et l’accessibilité a son propre dossier plutôt que d’être un correctif dispersé.
L’outillage de développement déclaré confirme le niveau d’exigence :
// hummingbird, package.json (v2.1.0), extrait des devDependencies
"typescript": "~5.5.4",
"webpack": "^5.95.0",
"@storybook/html-webpack5": "8.6.14",
"fork-ts-checker-webpack-plugin": "^9.0.2",
"@typescript-eslint/eslint-plugin": "^8.7.0",
"sass-embedded": "^1.79.3",
"css-minimizer-webpack-plugin": "^7.0.0"
Storybook, en particulier, veut dire que les composants du thème se visualisent et se testent isolément, ce qui est exactement ce dont on a besoin quand on adapte un thème sans vouloir casser les vingt autres pages.
Détail révélateur du niveau d’entretien du dépôt : Hummingbird embarque des consignes destinées aux assistants de code, avec un CLAUDE.md, un CONTEXT.md, un .cursorrules et quatre autres fichiers du même genre. Que l’on utilise ces outils ou non, c’est le signe d’un dépôt tenu en 2026, pas d’un socle laissé en l’état.
C’est ça, la bascule : on passe d’un thème qu’on modifie en espérant ne rien casser à un thème qui vous le dit. Pour une boutique dont le front sera repris par une autre équipe dans deux ans, l’écart est considérable, et il ne se mesure pas avec Lighthouse.
Sur l’évolution du thème lui-même et la manière dont l’équipe le documente, on avait détaillé la publication du fichier Figma officiel de la v2.
Accessibilité : ce qu’un thème peut garantir, et ce qu’il ne peut pas
La version précédente de cet article annonçait « plus de 95 % de conformité EAA dès l’installation ». Ce chiffre ne se vérifie nulle part, et surtout il ne peut pas être exact, parce qu’un thème ne peut pas être conforme tout seul.
Ce qu’un thème apporte : une hiérarchie de titres correcte, une navigation au clavier fonctionnelle, une gestion du focus, des contrastes par défaut acceptables. Hummingbird le fait, et son dossier src/js/accessibility/ montre que le sujet est traité comme du code et non comme une passe de correction.
Ce qu’un thème ne peut pas apporter : des textes alternatifs sur vos images produit, une hiérarchie de titres cohérente dans vos descriptions, des libellés compréhensibles dans les formulaires de vos modules, un tunnel de commande accessible si un module de paiement injecte son propre balisage. Or c’est là que se trouve l’essentiel des écarts constatés en audit.
Formulé honnêtement : Hummingbird vous met sur une bien meilleure ligne de départ que Classic, il ne vous met pas sur la ligne d’arrivée. Vendre un pourcentage de conformité livré avec un thème est trompeur, et c’est le genre d’affirmation qui se retourne le jour d’un contrôle.
Ce qui est officiellement acté
Sur les statuts, inutile d’interpréter, les dépôts le disent eux-mêmes. Celui de Hummingbird se décrit comme « Default theme for PrestaShop 9.1+ », celui de Classic comme « Default theme for PrestaShop 1.7 and 8+ ».
Hummingbird est donc bien le thème par défaut à partir de PrestaShop 9.1. En revanche, l’idée que Classic serait abandonné demande une nuance : sa dernière version, la 3.1.2, date du 11 mai 2026, précédée de la 3.1.1 en février et de la 3.1.0 en janvier. Ce n’est pas un dépôt à l’arrêt.
La lecture raisonnable est donc celle-ci. Classic continuera d’être corrigé, mais les nouveautés du front-end iront dans Hummingbird, et l’écart fonctionnel se creusera par le haut plutôt que par un abandon. Ce n’est pas une urgence, c’est une direction. Un marchand qui a refait son thème Classic il y a un an n’a aucune raison de tout reprendre dans les six mois.
Comment on mène la migration
Quatre étapes, dans cet ordre, et la deuxième est celle qui détermine le budget.
1. Cartographier l’existant. Quels gabarits sont surchargés, quels overrides sont en place, quels modules touchent à l’affichage. Sur une boutique de quelques années, cette liste est toujours plus longue que ce que le marchand imagine, parce qu’elle inclut des correctifs posés par des prestataires successifs.
Avant même de commencer, une commande vous dit sur quoi votre boutique tourne réellement, ce qui est souvent différent de ce qu’on vous a dit :
# Sur quelle base votre thème actuel est-il construit ?
cat themes/*/\_dev/package.json 2>/dev/null \
| grep -E '"(bootstrap|jquery|typescript)"'
# Combien de gabarits sont surchargés par des modules ?
find modules -path '*/views/templates/front/*' -name '*.tpl' | wc -l
# Combien de surcharges de gabarits du thème ?
find themes -path '*/modules/*' -name '*.tpl' | wc -l
Les deux derniers chiffres sont ceux qui déterminent le devis. Un thème avec trois surcharges se migre en quelques jours, un thème avec cent quarante est un tout autre projet.
2. Auditer les modules front, un par un. C’est l’étape décisive. Un module dont les gabarits reposent sur les classes de Bootstrap 4 alpha ne s’affichera pas correctement sur une grille Bootstrap 5, et il n’y aura aucune erreur : juste une mise en page cassée. Le coût réel de la migration se trouve ici, pas dans le thème.
3. Monter une préproduction et parcourir les tunnels à la main. Inscription, panier, paiement, compte client, et le tunnel de commande complet sur mobile. Ce sont les parcours où une régression coûte immédiatement du chiffre d’affaires.
4. Adapter, puis mesurer. Typographies, couleurs, hiérarchie visuelle. Et surtout, prendre les mesures de performance avant la migration pour pouvoir comparer après. Sans point de départ, personne ne pourra dire si l’opération a servi à quelque chose.
Si une montée vers PrestaShop 9 est prévue, il vaut mieux enchaîner les deux chantiers que les mener séparément, pour ne pas payer deux fois la recette complète. Le sujet est traité dans notre point sur PrestaShop 9.
Ce que la migration ne vous apportera pas
Autant le dire avant de signer un devis plutôt qu’après.
Elle n’allègera pas vos pages autant qu’annoncé. jQuery reste chargé, vos modules restent les mêmes, vos images restent les vôtres. Le passage de Bootstrap 4 alpha à Bootstrap 5 fait gagner du CSS, pas des secondes.
Elle ne réglera pas vos Core Web Vitals si le problème est ailleurs. Dans la plupart des audits que nous menons, le poste dominant est constitué des scripts tiers, des images non dimensionnées et du temps de réponse serveur. Un thème ne corrige aucun des trois. Si vos mesures pointent vers ces postes-là, traitez-les d’abord : ils vous coûteront moins cher et se verront davantage.
Elle ne vous rendra pas conforme à l’accessibilité. Voir plus haut, l’essentiel se joue dans vos contenus et vos modules.
Et elle vous coûtera du temps de recette. Le thème s’installe vite, ce sont les modules qui prennent le temps. Un marchand qui budgète la migration sans budgéter la reprise de ses modules front se trompe systématiquement de facteur.
Notre position
Hummingbird est le bon socle pour un projet qui démarre, sans discussion : partir aujourd’hui sur une alpha de Bootstrap 4 n’a aucun sens.
Pour une boutique existante, la question n’est pas « faut-il migrer » mais « quand ». Le bon moment est celui où vous touchez déjà au front : une montée de version, une refonte graphique, un chantier d’accessibilité. Migrer le thème à cette occasion coûte une fraction de ce que coûte un chantier isolé, parce que la recette est mutualisée.
Migrer uniquement pour migrer, en revanche, revient à payer intégralement une reprise de modules pour un gain que vos mesures ne montreront pas. C’est ce que nous déconseillons, et c’est exactement ce que la version précédente de cet article encourageait à faire.
Questions fréquentes
Hummingbird supprime-t-il vraiment jQuery ?
Le code du thème n’en utilise pas, c’est vérifiable dans ses sources TypeScript. Mais jQuery 3.7.1 figure dans ses dépendances de production et reste servi au navigateur, pour la compatibilité avec les modules du marché. Le gain de poids attendu n’arrive donc pas le jour de la migration.
Sur quelle version de Bootstrap tourne Classic ?
Sur 4.0.0-alpha.5, une préversion de 2016, et non sur Bootstrap 4 stable. C’est l’argument technique le plus solide en faveur de la migration, et curieusement le moins cité.
Classic est-il abandonné ?
Non. Sa version 3.1.2 date du 11 mai 2026. Il reste corrigé, mais les nouveautés du front-end vont dans Hummingbird, qui est le thème par défaut à partir de PrestaShop 9.1.
Puis-je rester sur Classic avec PrestaShop 9 ?
Oui. Ce n’est pas une impasse à court terme. La question devient sérieuse le jour où vous voulez une fonctionnalité front qui n’existe que dans Hummingbird, ou quand vos modules cessent d’être testés contre Bootstrap 4 alpha.
Combien coûte la migration ?
Elle se chiffre au nombre de modules front à reprendre et au nombre de gabarits surchargés, pas au thème lui-même. C’est pourquoi l’audit des modules est la première chose à faire, avant toute estimation.
Faut-il en profiter pour refaire le design ?
Souvent oui, parce que la recette complète sera de toute façon à refaire. Mais ce doit être une décision assumée, pas un ajout de dernière minute qui double le budget en cours de route.
Vous vous demandez si votre boutique a intérêt à basculer maintenant ou à attendre le prochain chantier front ? La réponse tient dans la liste de vos modules front et de vos surcharges de gabarits. Envoyez-la nous, on vous dira franchement si ça vaut le coup tout de suite.
