PrestaShop 9.1, Hummingbird et maintenance securite : faut-il changer de theme maintenant ?

Changer le theme d'une boutique PrestaShop ressemble souvent a une decision graphique. On voit une page d'accueil plus moderne, des fiches produits plus nettes, un menu plus propre sur mobile, et l'envie de remplacer l'ancien habillage arrive vite.

Pour une boutique qui vend deja, ce n'est pourtant pas un simple changement de vitrine. Le theme touche au catalogue, aux filtres, aux variantes, au tunnel de commande, aux modules de paiement, aux balises SEO, aux donnees structurees, au suivi analytics, aux performances mobiles et parfois a des personnalisations faites il y a plusieurs annees.

PrestaShop 9.1 et le travail autour de Hummingbird rendent la question plus actuelle. Le projet avance vers un front office plus moderne, plus structure et plus facile a maintenir. Mais le bon choix pour une PME francaise n'est pas automatiquement "changer de theme tout de suite". La vraie question est plus utile :

faut-il seulement appliquer les correctifs, preparer un rafraichissement de theme, ou cadrer une refonte plus profonde de la boutique ?

Ce que PrestaShop 9.1 et Hummingbird changent vraiment dans la decision

PrestaShop a indique que Hummingbird v2 est le theme par defaut depuis PrestaShop 9.1. En juin 2026, le projet a aussi publie un fichier Figma public officiel pour Hummingbird v2, presente comme une reference pour les composants, les tokens de design, les espacements et les mises en page. C'est important pour les agences, integrateurs et marchands qui ne veulent plus construire leur boutique uniquement a partir d'un theme ancien, modifie par couches successives.

Ce signal ne veut pas dire qu'une boutique existante doit migrer brutalement vers un nouveau theme. Il veut dire que l'ecosysteme se structure. Les themes, les composants, le balisage, l'accessibilite et la maintenabilite front office deviennent des sujets plus concrets.

Dans le meme temps, les publications officielles recentes rappellent que la maintenance PrestaShop reste un sujet de production. Les versions 9.1.4 et 8.2.7 ont notamment integre le module ps_facetedsearch corrige en 4.0.4 apres une alerte de securite importante. Ce point est deja traite dans notre article sur les verifications PrestaShop 9 avant mise a jour et dans l'analyse de la decision PrestaShop 9.1.4 / 8.2.7.

Ici, le sujet est different. Une boutique peut etre a jour cote correctifs et rester fragile cote theme. A l'inverse, une boutique peut avoir besoin d'un patch de securite urgent sans que le changement de theme soit prioritaire cette semaine.

Le mauvais reflexe : copier un theme de demo sur une boutique vivante

Une boutique de demo ne porte pas les memes contraintes qu'une boutique reelle.

Sur une vraie boutique, les categories ont parfois des profondeurs differentes. Les produits ont des declinaisons, des tailles, des couleurs, des stocks variables, des champs personnalises, des regles de livraison, des promos et des contraintes de TVA. Le checkout depend de modules de paiement, de transporteurs, de relance panier, d'email transactionnel, de consentement cookies et parfois d'ERP ou de CRM.

C'est pour cela qu'un theme qui parait propre en capture peut creer des problemes tres concrets une fois applique :

• les filtres catalogue n'affichent plus les bonnes facettes ;
• les variations produit deviennent moins lisibles sur mobile ;
• le bouton d'ajout au panier descend trop bas ;
• les avis, garanties ou delais de livraison disparaissent de la zone utile ;
• les emails ou traductions heritent d'anciennes personnalisations ;
• les evenements analytics ne remontent plus correctement ;
• des URLs, donnees structurees ou canoniques changent sans plan de redirection.

La bonne methode ne consiste donc pas a demander "quel theme est le plus joli ?". Elle consiste a demander : "quel theme peut supporter notre catalogue, notre checkout, notre SEO et notre exploitation quotidienne ?"

Trois chemins possibles : patch, theme ou refonte

Avant de choisir un chantier, il faut separer trois niveaux de decision. Ils ne demandent pas le meme budget, le meme calendrier ni le meme niveau de risque.

1. Patch only : securiser et stabiliser sans changer l'experience

C'est le bon chemin quand le site vend encore correctement, que le theme n'est pas le principal frein commercial, mais que la boutique doit etre remise dans un etat plus sain.

Exemples :

• module de recherche a facettes a mettre a jour ;
• version PrestaShop ou modules natifs en retard ;
• bugs connus sur commandes, traductions, emails ou back office ;
• besoin de verifier les sauvegardes, le staging et le plan de retour arriere ;
• quelques corrections SEO ou performance sans chantier visuel.

Dans ce cas, changer de theme peut etre une distraction. Il vaut mieux corriger ce qui expose la boutique, tester le catalogue et le checkout, puis garder une trace claire de l'etat technique. C'est souvent le premier travail d'une maintenance PrestaShop serieuse.

2. Theme refresh : moderniser le front sans reconstruire toute la boutique

C'est pertinent quand le socle reste sain, mais que l'interface front office nuit clairement a la confiance ou a la conversion.

Signaux typiques :

• mobile difficile a parcourir ;
• fiches produits encombrees ou peu rassurantes ;
• categories et filtres mal hierarchises ;
• pages lentes a cause d'un theme ancien surcharge ;
• incoherence visuelle entre la marque actuelle et la boutique ;
• tunnel de commande present mais peu lisible.

Un theme refresh n'est pas "leger" pour autant. Il doit etre traite comme un chantier e-commerce : inventaire des templates, reprise des zones critiques, tests panier/commande, controle SEO et validation module par module.

Pour une boutique lyonnaise ou une PME qui veut vendre davantage sans tout reconstruire, ce chemin peut etre plus rentable qu'une refonte complete. Il faut simplement accepter qu'un theme touche aux operations, pas seulement au design.

3. Refonte ou migration : repartir propre quand les couches anciennes coutent trop cher

La refonte devient logique quand le theme actuel n'est qu'un symptome.

Par exemple :

• le catalogue est mal structure ;
• les modules critiques ne sont plus maintenus ;
• le checkout a ete modifie plusieurs fois sans documentation ;
• l'hebergement ou la version PHP bloque les evolutions ;
• les URLs et contenus SEO sont incoherents ;
• les donnees produits, images ou attributs doivent etre nettoyes ;
• l'equipe ne sait plus ce qui est natif, module ou developpement specifique.

Dans ce cas, parler uniquement de theme risque de sous-dimensionner le chantier. Il faut plutot regarder la migration de site web, la preservation SEO, la reprise catalogue, l'architecture des pages et le deploiement controle. Notre article sur les signes a corriger avant une refonte PrestaShop va dans ce sens : si la boutique est confuse, changer l'habillage ne suffit pas.

La grille d'audit avant de toucher au theme

Avant de modifier le front office, un audit court mais precis peut eviter beaucoup de casse. Voici les zones que 1Design regarderait avant de recommander patch, theme refresh ou refonte.

1. Overrides, child theme et personnalisations invisibles

Beaucoup de boutiques PrestaShop ont ete adaptees au fil du temps. Un bloc de rassurance ajoute par un prestataire, un template produit modifie pour afficher une information metier, un hook de module deplace, une traduction corrigee a la main, une regle CSS ajoutee en urgence.

Ces changements ne sont pas toujours documentes. Avant de changer de theme, il faut identifier :

• les overrides de classes ou controllers ;
• les templates modifies dans le theme ;
• les modules relies a des hooks front office ;
• les fichiers de traduction ou emails personnalises ;
• les scripts ajoutes dans le theme ou via un module ;
• les zones ou un developpement specifique remplace le comportement natif.

Le risque n'est pas seulement technique. Une personnalisation peut porter une information qui aide a vendre : delai de livraison, garantie, condition de retour, message B2B, preuve locale. Si elle disparait, la page devient plus propre mais moins efficace.

2. Catalogue, filtres et recherche

Les filtres sont un point sensible dans PrestaShop, surtout pour les boutiques avec beaucoup de categories, tailles, couleurs, marques ou caracteristiques. Le recent sujet autour de ps_facetedsearch rappelle que le filtrage catalogue n'est pas un simple widget visuel.

Avant un changement de theme, testez les pages qui comptent vraiment :

• categories principales ;
• categories profondes ;
• recherche interne ;
• filtres par prix, marque, taille, couleur, disponibilite ;
• tri et pagination ;
• produits avec nombreuses declinaisons ;
• produits en rupture ou commande speciale.

Il faut regarder le rendu desktop et mobile. Un filtre tres visible sur ordinateur peut devenir cache, trop long ou difficile a refermer sur mobile. Pour un marchand, ce detail peut faire perdre des ventes sans generer d'erreur technique evidente.

3. Fiches produits : la confiance avant l'esthetique

Un nouveau theme peut rendre les fiches produits plus elegantes, mais l'objectif commercial reste le meme : aider le client a comprendre, comparer et acheter.

Sur les fiches importantes, verifiez au minimum :

• titre, prix, promotion et disponibilite ;
• declinaisons et options ;
• photos et zoom ;
• delais de livraison ;
• frais ou conditions de retour ;
• reassurance, garantie, paiement securise ;
• avis ou preuves quand elles existent ;
• produits associes sans surcharge ;
• donnees structurees produit ;
• balises title/meta et H1 ;
• bouton panier visible sur mobile.

Un theme moderne qui masque les informations de livraison ou qui rend les variantes confuses peut faire moins bien qu'un vieux theme clair.

4. Checkout, paiement, livraison et emails

Le checkout doit etre teste comme un parcours complet, pas comme une page isolee. PrestaShop continue d'avancer sur les sujets de commande et de checkout, et les modules de paiement/livraison evoluent souvent en parallele.

Avant de valider un theme ou une refonte, faites au moins un jeu de tests :

• creation de compte et commande invite ;
• adresse francaise simple ;
• adresse avec accents, apostrophe ou entreprise ;
• plusieurs modes de livraison ;
• paiement CB, PayPal ou autre moyen actif ;
• code promo si la boutique l'utilise ;
• email de confirmation client ;
• email administrateur ;
• facture ou bon de livraison si necessaire ;
• annulation ou remboursement test selon le contexte.

Un probleme de checkout n'est pas une imperfection graphique. C'est une perte directe de chiffre d'affaires. C'est aussi pour cela qu'une creation de site e-commerce doit toujours inclure des tests de parcours, pas seulement une validation visuelle.

5. Consentement, analytics et evenements de conversion

Un theme peut modifier la maniere dont les scripts sont charges, dont les boutons sont classes, dont les etapes du tunnel sont marquees, ou dont les composants apparaissent apres consentement.

Il faut verifier :

• banniere cookies et choix utilisateur ;
• Google Analytics / Matomo / autre outil ;
• evenements panier, checkout, achat ;
• pixels publicitaires si presents ;
• suivi formulaire ou demande de devis ;
• erreurs JavaScript ;
• scripts inseres deux fois ;
• performance mobile apres chargement des tags.

Sans cette verification, une boutique peut continuer a vendre mais perdre la lecture de ses performances. Le dirigeant croit alors que le changement de theme n'a rien modifie, alors que le reporting est simplement casse.

6. SEO : URLs, canoniques, donnees structurees et sitemap

Le SEO est souvent le grand oublie des changements de theme. Pourtant, un theme peut toucher aux titres visibles, aux breadcrumbs, aux donnees structurees, aux blocs de contenu, aux liens internes et parfois aux templates de categories.

Avant mise en production, controlez :

• URLs conservees ou redirigees ;
• canoniques ;
• balises title/meta sur produits et categories ;
• H1/H2 ;
• fil d'Ariane ;
• donnees structurees produit ;
• images et attributs alt utiles ;
• pagination et filtres indexables ou non ;
• sitemap ;
• pages principales deja positionnees.

Le bon objectif n'est pas de "faire du SEO en plus" pendant le changement de theme. Le premier objectif est de ne pas casser ce qui fonctionne deja. Ensuite seulement, on peut ameliorer la structure, les contenus et le maillage interne.

7. Mobile, accessibilite et performance percue

Hummingbird avance sur des sujets de structure, de composants et d'accessibilite. C'est une bonne direction, mais une boutique reelle doit etre testee avec son contenu, ses images, ses modules et ses regles metier.

Sur mobile, regardez :

• menu et recherche ;
• filtres categories ;
• fiche produit ;
• choix de declinaisons ;
• panier ;
• checkout ;
• messages d'erreur ;
• boutons et zones tactiles ;
• lisibilite des textes ;
• poids des images ;
• comportement apres consentement cookies.

Une page peut obtenir un score technique correct et rester difficile a utiliser. A l'inverse, une petite correction d'interface peut avoir plus d'impact qu'un changement de theme complet.

Le scenario que beaucoup de boutiques sous-estiment : tout marche, sauf une chose critique

Le piege d'un changement de theme, c'est qu'il peut sembler reussi pendant les premiers controles. La page d'accueil charge. Les categories s'affichent. Le panier s'ouvre. Le design est plus moderne.

Puis un cas reel arrive :

• une cliente utilise un code promo avec livraison gratuite ;
• un produit a trois declinaisons et une rupture partielle ;
• une commande vient d'un mobile avec consentement refuse ;
• une adresse contient un caractere particulier ;
• un transporteur n'apparait que pour certains poids ;
• un module de paiement affiche un message d'erreur discret ;
• une categorie historique perd son balisage SEO.

Ce sont ces cas qui justifient un staging propre. Pas pour faire du theatre technique, mais pour tester les parcours qui rapportent de l'argent.

Comment 1Design cadrerait la decision

Pour une boutique PrestaShop, 1Design ne commencerait pas par choisir un theme. Le travail utile commence plus tot.

1. Inventaire de l'existant : version PrestaShop, theme, modules, overrides, hebergement, PHP, sauvegardes, pages SEO fortes, parcours de vente.
2. Priorisation commerciale : quelles pages vendent, quelles categories comptent, quels freins reviennent dans les demandes clients ou le support.
3. Diagnostic theme/front office : ce qui releve d'un patch, d'un ajustement UX, d'un theme refresh ou d'une refonte.
4. Staging et sauvegarde : environnement testable, plan de retour arriere, donnees suffisamment proches du reel.
5. Tests catalogue et checkout : produits types, filtres, panier, paiement, livraison, emails, erreurs.
6. Preservation SEO : URLs, redirections, canoniques, donnees structurees, liens internes, sitemap.
7. Deploiement controle : fenetre de mise en ligne, verification post-deploiement, suivi des commandes et logs.

Cette approche peut mener a trois conclusions differentes. Parfois, la meilleure reponse est de patcher maintenant et de reporter la refonte. Parfois, le theme refresh est le bon levier. Parfois, la boutique est assez empilee pour qu'une migration ou refonte controlee soit plus saine que des corrections ponctuelles.

Ce qu'il faut decider avant de demander un devis

Avant de solliciter un devis, une PME peut deja preparer quelques reponses. Elles rendent la discussion plus concrete et evitent les propositions trop vagues.

Demandez-vous :

• quelles pages ou categories generent le plus de chiffre d'affaires ;
• quels modules sont indispensables au fonctionnement ;
• ce qui a ete personnalise dans le theme actuel ;
• quelles URLs ne doivent pas bouger ;
• quels moyens de paiement et livraison doivent etre testes ;
• quels problemes clients reviennent souvent ;
• quelles donnees analytics servent aux decisions ;
• quel niveau d'interruption est acceptable ;
• qui valide la boutique avant mise en production.

Si ces reponses sont floues, ce n'est pas un probleme. C'est justement le role de l'audit. Une revue de devis ou de cadrage e-commerce peut aider a distinguer le vrai besoin d'un simple changement visuel.

Conclusion : ne changez pas de theme pour suivre une version, changez-le quand le parcours le justifie

PrestaShop 9.1, Hummingbird et les recentes publications du projet donnent de bons signaux : le front office avance, la maintenance continue, les themes deviennent plus structures, et les marchands ont interet a surveiller leur socle.

Mais une boutique n'a pas besoin d'une reaction automatique. Elle a besoin d'une decision propre.

Si le probleme est un correctif ou un module sensible, commencez par securiser. Si le theme freine la lecture, le mobile ou la conversion, preparez un theme refresh teste. Si le catalogue, le checkout, les modules et le SEO sont devenus trop difficiles a maintenir, cadrez une refonte ou une migration.

Votre boutique PrestaShop doit evoluer, mais vous ne savez pas si le bon choix est un patch, un nouveau theme ou une refonte plus profonde ? 1Design peut relire le catalogue, le checkout, les modules, les URLs SEO et le parcours mobile avant de toucher a la production. Le point de depart peut etre simple : nous contacter pour cadrer les risques, les priorites et le bon niveau d'intervention.