Le thème Classic a longtemps été la base de travail par défaut pour tout projet PrestaShop. Fonctionnel, bien documenté, compatible avec des centaines de modules — il a rendu de bons services. Mais son socle technique, construit sur Bootstrap 4 et une dépendance forte à jQuery, accuse aujourd'hui son âge face aux exigences des Core Web Vitals et des audits de performance modernes.
Hummingbird est la réponse officielle de l'équipe PrestaShop à ce vieillissement. Je l'utilise désormais sur plusieurs boutiques en production, notamment une boutique de pièces détachées pour quads et une boutique de pièces de motoculture sur PrestaShop 9 avec un catalogue de l'ordre de cent mille références et des maquettes Figma desktop et mobile réalisées par un designer. Cette dernière a été développée en environ cinq jours grâce à l'apport de l'IA dans la production du code.
Voici ce que j'en retiens — sans langue de bois. Les avantages, mais aussi les pièges que j'ai rencontrés et qu'on ne trouve pas dans la documentation officielle. Si vous envisagez de créer une boutique PrestaShop ou une refonte, cet article vous aidera à vous décider.
Hummingbird en deux mots
Hummingbird est le thème officiel moderne de PrestaShop, développé directement par l'équipe core. Il a été conçu pour succéder à Classic en prenant acte des évolutions du web : Bootstrap 5, abandon de jQuery comme dépendance principale, architecture de composants plus propre et focus sur les performances mesurables.
Concrètement, ce changement de base technique a des effets visibles : le JavaScript chargé en page est plus léger, le rendu initial est plus rapide, et les métriques de Core Web Vitals (LCP, CLS, FID) sont plus faciles à optimiser. Google intègre ces signaux dans son algorithme de classement — un site performant ne convertit pas seulement mieux, il se positionne mieux.
Côté architecture, Hummingbird reprend les mêmes conventions PrestaShop (templates Smarty, overrides, thème enfant) mais les applique avec une rigueur accrue. Le thème est distribué en version compilée, ce qui impose un workflow de développement spécifique — j'y reviendrai dans la section pièges.
Il est gratuit, open source, et téléchargeable directement depuis le gestionnaire de thèmes PrestaShop. Pour les nouveaux projets, c'est le point de départ que je recommande sans hésitation. Pour les boutiques existantes qui envisagent une refonte, la question mérite une analyse — voir la section comparatif ci-dessous.
Hummingbird ou Classic ? Le comparatif honnête
La question revient dans chaque projet de refonte ou de nouvelle boutique. Voici ma grille de lecture après deux projets en production avec Hummingbird.
La lecture est claire : pour une nouvelle boutique ou une refonte, Hummingbird est le bon choix. Sa base technique plus récente vous évite d'accumuler de la dette dès le départ. En revanche, si votre boutique repose sur une vingtaine de modules anciens achetés sur le marketplace et que vous n'avez pas prévu de budget pour les adapter, la migration est à étudier avec soin.
Classic n'est pas mort — il est maintenu par l'équipe PrestaShop et reste parfaitement fonctionnel. Mais il ne recevra pas les améliorations de performance que l'équipe core concentre sur Hummingbird. Si vous démarrez un projet aujourd'hui sur Classic, vous partez avec un écart technique d'emblée.
Pour choisir la plateforme elle-même avant même de parler de thème, consultez mon comparatif PrestaShop vs Shopify vs WooCommerce.
Les pièges que j'ai rencontrés
C'est la section la plus utile de cet article. Ce que la documentation officielle explique, et ce que l'expérience terrain complète.
La version compilée : on ne touche pas au parent
Hummingbird est distribué en version compilée. Les fichiers CSS et JavaScript du thème parent sont minifiés et concaténés — les sources Sass ne sont pas fournies dans la release officielle. Conséquence directe : vous ne modifiez jamais un fichier du dossier du thème parent. Toute modification directe sera écrasée à la prochaine mise à jour. C'est la règle n°1, et la plus souvent violée par les développeurs qui débarquent depuis Classic.
Le thème enfant est obligatoire, pas optionnel
Avec Classic, on pouvait parfois modifier le thème directement « pour aller vite ». Avec Hummingbird, c'est un mur : sans thème enfant, vos modifications disparaissent à chaque mise à jour. La bonne pratique est de créer un thème enfant dès le début du projet, avec son propre dossier de styles compilés. Ce thème hérite de tout le parent et ne contient que vos surcharges. Le pipeline de compilation (généralement Webpack ou Vite) fait partie du projet de développement.
Surcharger les templates, jamais les modifier
Pour personnaliser un template (une fiche produit, une page catégorie, un bloc), la règle est simple : copiez le fichier .tpl du thème parent dans la même arborescence de votre thème enfant, puis modifiez la copie. PrestaShop utilise en priorité le template du thème enfant s'il existe. Cette approche garantit que votre personnalisation ne disparaît pas avec les mises à jour du parent. Organisez vos overrides en miroir exact du thème parent pour vous y retrouver facilement.
Les modules tiers stylés pour Classic
C'est le piège le plus fréquent en production. Beaucoup de modules PrestaShop du marketplace ont leurs propres feuilles de style pensées pour Classic. Sur Hummingbird, ils peuvent s'afficher correctement, de manière acceptable, ou complètement décalés — selon la qualité du code du module. Sur les boutiques que j'ai livrées, j'ai dû adapter l'affichage de plusieurs modules : ajout de styles de surcharge dans le thème enfant, parfois contacts avec l'éditeur pour une version compatible. Prévoyez du temps pour ce travail lors de la recette.
Les gros catalogues et les boucles de listing
Sur un catalogue de cent mille références, les pages de listing sont sous pression. Hummingbird n'est pas responsable des requêtes SQL lentes, mais certains traitements applicatifs appelés dans les boucles de produits peuvent créer des bottlenecks visibles. Sur la boutique à gros catalogue que j'ai livrée, j'ai combiné la mise en cache agressive, la pagination optimisée et la limitation des données chargées dans les vignettes. La règle : profiles d'abord, optimise ensuite. Ne présupposez pas d'où vient le problème de performance.
Règle d'or avec Hummingbird : traitez-le comme une dépendance externe, pas comme votre code. Vos fichiers vivent dans le thème enfant, point. Cette discipline demande un léger effort d'adaptation au démarrage, mais elle vous protège de toute mauvaise surprise lors des mises à jour de PrestaShop ou du thème parent.
De la maquette Figma au thème en production
Sur la boutique de motoculture, le designer a livré des maquettes desktop et mobile complètes avant que je ne commence le développement. Cette organisation a été déterminante dans la rapidité d'exécution.
La méthode que j'applique :
Extraction de la charte
Avant d'écrire une ligne de code, j'extrais la charte graphique des maquettes : couleurs (primaires, secondaires, neutres), typographies (famille, tailles, graisses), espacements récurrents. Ces valeurs deviennent des variables CSS dans le thème enfant.
Construction des composants de base
Boutons, badges, alertes, formulaires, cartes produit — les briques réutilisables d'abord. Elles servent de fondation pour toutes les pages suivantes. Tout changement de couleur ou de typographie n'a ensuite lieu qu'à un seul endroit.
Pages dans l'ordre : structure → accueil → catalogue → fiche produit → tunnel → compte
Je commence par la structure globale (header, footer, navigation), puis les pages dans l'ordre décroissant du trafic attendu. Le tunnel de commande en dernier, car il dépend de tout le reste et mérite une recette spécifique.
Mobile en priorité, desktop en adaptation
Je développe d'abord pour mobile, puis j'adapte pour les écrans larges. C'est l'inverse du réflexe classique, mais c'est ce que PrestaShop attend et ce que Google mesure en priorité.
Recette avant mise en production
Tests sur les navigateurs cibles, vérification des modules, parcours complet de commande, vérification des emails transactionnels. La mise en production se fait sur un créneau planifié, jamais en urgence.
Sur la boutique de motoculture, l'IA (Claude) a participé directement à la production du code : génération des composants de base à partir de la charte, adaptation des overrides de templates, rédaction des styles de surcharge. Ce n'est pas une exagération de dire que cet apport a divisé le temps de développement — avec la réserve que la qualité du résultat dépend entièrement de la qualité des maquettes fournies et de la maîtrise du développeur qui supervise.
Pour les projets à gros catalogues, la gestion des performances serveur est un sujet à part entière. J'ai détaillé la configuration que j'utilise dans l'article Serveur Debian pour PrestaShop avec un gros catalogue.
Ce qui fait gagner en performance avec Hummingbird
Je ne publierai pas de scores Lighthouse ici sans avoir les mesures under les yeux — les chiffres inventés ou extrapolés ne rendent pas service. En revanche, je peux vous expliquer pourquoi Hummingbird part d'une meilleure base que Classic sur les métriques qui comptent.
Moins de JavaScript bloquant
La suppression de jQuery comme dépendance principale réduit significativement le JavaScript à parser et exécuter en page. Le navigateur peut afficher le contenu plus tôt.
CSS plus ciblé
Bootstrap 5 génère des classes plus granulaires. Avec du tree-shaking adapté dans le thème enfant, le CSS livré en production est plus léger que le fichier monolithique de Classic.
Conçu pour les Core Web Vitals
Le chargement des ressources, l'ordre d'affichage et les animations ont été pensés pour minimiser le CLS (décalage de mise en page) et maximiser le LCP (affichage du contenu principal).
Plus facile à optimiser
Sur une base propre, les optimisations (lazy loading, préchargement des polices, compression d'images) ont un impact plus mesurable. Sur Classic, certaines optimisations se heurtaient à des dépendances difficiles à isoler.
La performance d'un site e-commerce ne dépend jamais du seul thème : la configuration serveur, la gestion du cache, les images, les requêtes SQL — tout joue. Mais partir d'un thème dont la base technique est alignée avec les standards actuels vous évite de lutter contre votre propre outillage.
Faut-il passer à Hummingbird ?
Pour une création ou une refonte : oui, sans hésiter. Hummingbird est le thème stratégique de PrestaShop pour les années à venir. Démarrer un projet dessus, c'est investir dans une base maintenue, documentée et orientée performance.
Pour une boutique en production sur Classic : à étudier au cas par cas. Si votre boutique dépend de nombreux modules anciens et fonctionne bien, la migration n'est pas une urgence. En revanche, si vous prévoyez une refonte graphique ou une montée de version de PrestaShop, c'est le bon moment pour passer à Hummingbird — le coût marginal est faible par rapport à une refonte qui ne changerait pas le thème.
La question de la migration PrestaShop est souvent liée : si vous êtes encore sur une version 1.7 ou 8.x ancienne, la montée de version et le changement de thème se font souvent ensemble. J'ai détaillé ce process dans l'article Migration PrestaShop 1.7 vers 8 et 9.
Passez à Hummingbird si…
- → Vous créez une nouvelle boutique
- → Vous planifiez une refonte graphique
- → Vous voulez améliorer vos scores de performance
- → Vous montez de version PrestaShop
- → Vos modules principaux sont récents
Étudiez d'abord si…
- → Vous avez de nombreux modules anciens sur Classic
- → Votre boutique fonctionne bien et la refonte n'est pas planifiée
- → Votre budget ne couvre pas l'adaptation des modules
Je réalise des intégrations Hummingbird aussi bien pour des créations de boutiques PrestaShop que pour des agences qui sous-traitent le développement thème — voir la note à ce sujet plus bas. Mes services PrestaShop couvrent l'ensemble du cycle, du choix du thème jusqu'à la mise en production.
Questions fréquentes
Hummingbird est-il gratuit ?↓
Oui, c'est le thème officiel de PrestaShop, gratuit et open source. Il est distribué par l'équipe PrestaShop et disponible directement dans le gestionnaire de thèmes de votre back-office.
Hummingbird est-il compatible avec tous les modules ?↓
Les modules récents et bien codés fonctionnent très bien. Certains modules anciens conçus pour Classic peuvent nécessiter une adaptation de leur affichage côté thème enfant. C'est un travail que je réalise systématiquement lors de la phase de recette.
Peut-on modifier Hummingbird directement ?↓
Non. Hummingbird est distribué en version compilée — ses sources ne sont pas modifiables. Toute personnalisation passe par un thème enfant : vous n'éditez que votre propre code, jamais les fichiers du parent. C'est ce qui garantit la compatibilité avec les futures mises à jour de PrestaShop.
Combien de temps pour intégrer une maquette sur Hummingbird ?↓
De quelques jours à quelques semaines selon le nombre de pages, la complexité du design mobile et les fonctionnalités spécifiques. Une boutique standard (accueil, catalogue, fiche produit, tunnel, compte client) avec maquettes Figma fournies peut être intégrée en une semaine de développement si les maquettes sont complètes.
Hummingbird améliore-t-il le référencement ?↓
Indirectement, oui. Un site plus rapide et mieux noté sur les Core Web Vitals est favorisé par Google et convertit mieux. Hummingbird, par sa conception Bootstrap 5 et son JavaScript allégé, part d'une meilleure base technique que Classic pour atteindre de bons scores Lighthouse.
Pour les agences web
Je réalise des intégrations Hummingbird en marque blanche pour les agences qui n'ont pas de développeur PrestaShop en interne. Livraison propre et documentée, délai tenu, disponibilité pour les questions techniques. Vous gardez la relation client, je fournis le développement. Voir ma page développeur PrestaShop pour agences.
Note de l'auteur — Frédéric R.
Développeur PrestaShop freelance dans les Vosges (Grand Est) depuis 15 ans, j'interviens sur des projets e-commerce dans toute la France. Les boutiques mentionnées dans cet article sont en production. Les clients ont souhaité rester anonymes.