Sortie de PrestaShop 9.1 : Hummingbird 2.0, livraison multi-transporteurs et guide de migration

PrestaShop 9.1.0 est passée en version stable le 23 mars 2026, deux semaines et demie après la RC1. Nous la faisons tourner sur notre propre infrastructure de développement depuis les versions bêta, et nous avons déjà migré une bonne partie de nos 159 modules dessus. Voici la version des notes de version que nous aurions aimé lire : ce qui a réellement changé, ce qui relève surtout de l’annonce, et ce que nous avons rencontré en pratique.

Si vous êtes resté sur 1.7 ou 8.x en attendant le bon moment pour franchir le pas, 9.1 est une cible défendable. Ce n’est pas magique pour autant. Voici ce que le changelog ne dit pas.

Hummingbird 2.0, le thème par défaut des nouvelles installations, avec quelques réserves

Le changement le plus visible : Hummingbird est le thème par défaut sur les nouvelles installations PS 9.1. Le Hummingbird d’origine était arrivé avec 9.0 comme thème moderne optionnel ; la version 2.0 est une vraie refonte, pas un simple coup de peinture.

• Bootstrap 5.3.3 au lieu de la version alpha utilisée dans Hummingbird 1.x. Vous récupérez ainsi une API d’utilitaires stable, des hooks de mode sombre fonctionnels et des propriétés CSS personnalisées sur lesquelles on peut vraiment s’appuyer dans un thème enfant.
• Travail d’accessibilité EAA, l’équipe annonce une conformité de « plus de 95 % » avec l’European Accessibility Act (en vigueur depuis juin 2025). Meilleure ARIA, meilleurs contrastes, navigation clavier qui fonctionne réellement. Autant le dire clairement : 95 %, ce n’est pas 100 %, et nous avons déjà dû corriger quelques bugs d’état de focus dans nos propres surcouches de commande. Testez avant de livrer à un acheteur soumis à des exigences réglementaires.
• jQuery est déprécié, pas supprimé. Il est encore dans le bundle, mais son retrait est prévu pour PrestaShop 10. Si vous écrivez du nouveau JavaScript de module, écrivez-le en vanilla JS. Nous avons fait cette conversion sur nos modules front-office l’an dernier et cela ne nous a pas manqué une seule fois.
• Nouveaux attributs de hook JS, data-ps-ref, data-ps-action, data-ps-target remplacent les sélecteurs CSS improvisés comme surface recommandée de liaison JS. L’idée est que les designers puissent renommer des classes sans casser les scripts des modules. Nous aimons ce changement.
• Écart de hooks : displayOrderDetail et displayModalContent sont nouveaux. displaySearch disparaît, si votre module s’y enregistrait, il vous faut un remplacement.

Pour le travail sur les thèmes enfants lui-même, nous l’avons détaillé séparément : guide des thèmes enfants. Version courte : partez du starter Hummingbird 2.0, ne forkez pas le parent.

Hummingbird 1.x → 2.0 : ce qui coince

Si vous avez déjà livré un thème enfant basé sur Hummingbird 1.x, c’est ici que passera votre journée de migration :

• Renommages de classes Bootstrap 5.3. ml-*/mr-* → ms-*/me-*. data-toggle → data-bs-toggle. .custom-control → .form-check. Passez votre thème enfant et vos templates de module au grep. Nous en avons trouvé dans des modules que nous n’avions pas touchés depuis deux ans.
• Sélecteurs JS. Les sélecteurs basés sur les classes, comme .product-add-to-cart, fonctionnent encore, mais la convention se déplace vers data-ps-ref. Migrez progressivement. Il n’y a pas encore de date couperet.
• Surcharges de couleurs. Bootstrap 5.3 compile les valeurs de couleur dans des propriétés CSS personnalisées locales aux composants. Surcharger le jeton global :root ne suffit pas pour des éléments comme .btn-primary. Il faut .btn-primary { --bs-btn-bg: #yourcolor; }. C’est la première chose à vérifier dans chaque ticket de support « la couleur de la marque ne s’applique pas ».

Livraison multi-transporteurs, la fonctionnalité que les marchands demandent depuis la 1.5

C’est le gros morceau. Une même commande peut désormais être expédiée par plusieurs transporteurs, avec suivi et statuts indépendants par expédition.

Jusqu’à la 9.0 incluse, une commande signifiait un transporteur. Vendez un receveur de douche de 200 kg plus un tube de silicone, et le marchand devait soit diviser la commande à la main, soit développer un module sur mesure, soit absorber la différence. Tous nos clients du secteur salle de bains attendaient cela depuis des années.

La 9.1 introduit l’affectation des transporteurs au niveau de l’expédition :

• Diviser une commande en plusieurs expéditions, chacune avec son propre transporteur et son propre suivi
• Fusionner de nouveau les expéditions si l’entrepôt change de plan
• Suivre chaque expédition indépendamment dans le flux de traitement de la commande
• Dates de livraison et statuts par expédition

Deux réserves importantes. D’abord, cette fonctionnalité est livrée derrière un feature flag ; il faut l’activer volontairement, ne la considérez pas acquise. Ensuite, l’API est explicitement indiquée comme « susceptible d’évoluer » par l’équipe cœur, donc si vous écrivez aujourd’hui du code d’intégration dessus, attendez-vous à devoir y revenir avant la 10.0. Nous ne l’intégrons pas encore à nos modules de livraison en production, car nous attendons au moins une version mineure pour que l’API se stabilise.

Si vous vendez un catalogue mixte (meubles plus accessoires, équipements plus consommables, tout ce où DHL gère les petits colis et un transporteur palette le reste), c’est le prétexte de mise à niveau.

Le nouveau système de remises

L’ancien moteur de règles panier a un successeur. Lui aussi se trouve derrière un feature flag et reste désactivé par défaut. Le nouveau modèle sépare les remises en quatre types explicites :

• Remises catalogue, appliquées aux produits avant le panier
• Remises panier, appliquées au moment de la commande selon des conditions
• Livraison gratuite, un type de remise à part entière, pas une case à cocher sur une règle panier
• Cadeau offert, produits ajoutés automatiquement

Les anciennes règles panier continuent de fonctionner, rien ne casse lors de la mise à niveau. Le nouveau système est plus rapide (nous avons vu une boutique avec 600 règles panier dont la page d’administration était inutilisable ; le nouveau modèle les gère sans broncher) et plus facile à comprendre. Le reporting devient aussi plus clair : vous pouvez enfin séparer « chiffre d’affaires perdu à cause de la livraison gratuite » de « chiffre d’affaires perdu à cause des remises en pourcentage » sans analyser une table monolithique.

Nous n’avons pas encore migré de client hors des règles panier historiques en conditions réelles. Derrière un feature flag signifie : « testez sur préproduction, ne basculez pas en production sans plan de retour arrière ».

Changements côté développeur à connaître

Les points ci-dessous sont ceux qui nous importent réellement en tant qu’auteurs de modules, pas le changelog complet :

• Nouveaux hooks : actionModuleEnable, actionModuleDisable, actionModuleUpgradeAfter, actionConfigurationUpdateValueBefore. actionModuleUpgradeAfter est celui que nous attendions. Il nous permet d’exécuter fiablement des migrations post-mise à niveau sans devoir nous accrocher à l’ordre de nos propres fichiers upgrade-*.php.
• Nouvelles commandes CLI : prestashop:thumbnails:regenerate, prestashop:search:index, prestashop:translation:export-module. À elle seule, la commande de miniatures nous fait gagner une heure à chaque déploiement de rafraîchissement de catalogue.
• Améliorations de l’auto-mapping Doctrine pour les entités de modules, moins de boilerplate services.yml.
• PHP 8.1–8.5 officiellement pris en charge. Nous faisons tourner notre conteneur de développement en 8.4 et n’avons rien rencontré.
• Taux de TVA mis à jour pour l’Estonie et la Roumanie.
• D3 et NVD3 mis à jour, si vous avez des widgets de tableau de bord personnalisés, testez-les en régression.
• Le thème Classic passe en 3.1.1 pour les boutiques qui n’ont pas encore migré.

Pourquoi 9.1 est une cible de migration raisonnable

La question que les clients nous posent à chaque appel : « Je suis en 1.6 / 1.7 / 8.x, je mets à niveau maintenant, ou j’attends ? » Depuis un an, notre réponse était « attendez la 9.1 ». Cette réponse est désormais : « allez-y ».

Depuis PrestaShop 1.6

La 1.6 est en fin de vie depuis octobre 2023. Plus de correctifs de sécurité, plus de travail de compatibilité, et PHP 7.x est mort chez la plupart des hébergeurs. Chaque mois ajoute du risque et du coût de migration.

Retour au réel sur l’effort : une migration 1.6 → 9.1 est une reconstruction, pas une mise à niveau. Les données (produits, clients, commandes) migrent. Le thème, non, prévoyez un thème enfant Hummingbird 2.0 depuis zéro. La plupart des modules doivent être remplacés. Deux à six semaines de travail pour une boutique non triviale, principalement en tests, pas dans la mise à niveau elle-même.

La forme du chantier :

1. Monter une installation 9.1 propre en préproduction
2. Exporter le catalogue, les clients et les commandes depuis la source 1.6
3. Importer via les outils officiels ou un script de migration DB direct, nous le scriptions généralement
4. Installer et tester chaque module individuellement, pas en lot
5. Construire le thème enfant sur Hummingbird 2.0
6. Planifier des 301 pour chaque URL dont la forme change
7. Tester chaque parcours de commande, passerelle de paiement, livraison, e-mail transactionnel
8. Basculer le DNS sur une plage de faible trafic

Depuis PrestaShop 1.7

La 1.7 était la version de transition, moitié legacy, moitié Symfony. La 9.1 fait avancer la migration, mais ne la termine pas : les contrôleurs d’administration legacy/Smarty passent encore par le wrapper LegacyController. La surface d’API se modernise, et les nouvelles installations PS 9.1 obtiennent enfin un vrai thème responsive moderne par défaut.

La compatibilité des modules est raisonnable. Les modules bien maintenus fonctionnent déjà sur le chemin 1.7 → 9.x. Utilisez l’Update Assistant (l’ancien autoupgrade), mais uniquement sur une copie de préproduction. Nous avons vu l’Update Assistant échouer en cours de route sur de vraies boutiques à cause de lignes de base de données orphelines ou d’un override personnalisé ; si cela arrive en production, vous avez une indisponibilité au lieu d’une session de debug.

Ce qui frappe pendant une migration 1.7 → 9.1 :

• Les fichiers d’override dans override/classes/ sont la plus grande source de douleur lors des mises à niveau. Beaucoup entreront en conflit avec la nouvelle architecture. Passez-les tous en revue et remplacez-les par un hook quand c’est possible.
• API supprimées. Tools::displayPrice() a disparu. AdminController::ajaxDie() a disparu. Si vos modules personnalisés les appellent directement, ils provoqueront une erreur fatale. Nous encapsulons les API dépréciées dans notre package prestashop-compat, si vous maintenez vos propres modules, ce modèle mérite d’être copié.
• Les thèmes basés sur Classic depuis 1.7 fonctionnent pour la plupart sur 9.x, avec quelques bizarreries visuelles. Les thèmes enfants Hummingbird 1.x nécessitent la passe de renommage Bootstrap 5.3.
• PHP. 9.1 exige 8.1 au minimum. Si votre hébergeur est encore en 7.4 ou 8.0, c’est la première migration, avant de toucher à PrestaShop.

Depuis PrestaShop 8.x

C’est le cas simple. Le grand saut était 8 → 9.0 (Symfony 4.4 → 6.4, nouvelle API d’administration). 9.0 → 9.1 est incrémental. Si vos modules tournent déjà sur 9.0, ils devraient tourner sur 9.1 avec des tests de régression légers.

Les raisons de le faire : Hummingbird 2.0 surpasse Classic pour les nouvelles constructions, le multi-transporteurs corrige un vrai problème opérationnel, et vous restez sur la branche maintenue.

Où regarder après la mise à niveau : toute personnalisation d’administration (l’API d’administration a bougé en 9.0), les modules dans le pipeline de commande (le multi-transporteurs touche le modèle objet de commande), et les widgets de tableau de bord (mise à jour D3/NVD3).

La vision à long terme

PrestaShop 10 est la prochaine destination. jQuery disparaîtra complètement. L’administration continue de se moderniser. Le tunnel de commande natif en une page (la fonctionnalité que les marchands réclament depuis dix ans) a son premier code fusionné et vise une future version mineure. Le travail B2B avance dans le cœur.

9.1 sur Symfony 6.4 LTS est aujourd’hui la version qui offre la plus longue piste de support disponible. Rester sur 1.6 ou 1.7, c’est rester sur quelque chose qui n’est déjà plus pris en charge.

Liste de contrôle de migration

Quel que soit votre point de départ, l’ordre des opérations est à peu près le même :

1. Audit. Listez chaque module, chaque personnalisation de thème, chaque override, chaque intégration externe (paiement, ERP, API de livraison).
2. Passe de compatibilité modules. Pour chaque module, confirmez la prise en charge 9.x avec le développeur ou dans le changelog. Remplacez ceux qui ne sont pas pris en charge avant la mise à niveau, pas après.
3. Environnement de préproduction. Clonez la base de données et les fichiers de production vers un serveur séparé. La production n’est pas un environnement de test.
4. PHP d’abord. 9.1 exige 8.1+. Nous utilisons par défaut 8.2 ou 8.3 sur les piles de production client. 8.4 sur nos propres environnements de développement.
5. Update Assistant pour les boutiques 1.7+. Installation propre plus migration des données pour la 1.6.
6. Testez chaque parcours de commande. Chaque moyen de paiement, chaque option de livraison, chaque e-mail transactionnel. Passez de vraies commandes de test.
7. Préservez les URL. Mettez une 301 sur chaque URL dont la forme a changé. Surveillez Search Console le premier mois.
8. Réinitialisez OPcache correctement. Via une requête web, pas en CLI. Les pools sont différents. C’est la cause de la moitié des tickets « écran blanc après déploiement » que nous voyons.
9. Surveillez les 48 premières heures. Journaux d’erreurs, taux de conversion, temps de chargement des pages. Ayez un plan de retour arrière documenté.

Ce qui piège les équipes

Les échecs de mise à niveau récurrents que nous voyons dans les migrations client, par ordre de fréquence :

• Échecs silencieux d’override. Un override dans override/classes/Foo.php se charge encore à la place du fichier cœur même lorsque la signature est mauvaise. PrestaShop ne le journalise pas toujours. Passez en revue et supprimez les overrides inutilisés avant la mise à niveau, pas après.
• OPcache sert un bytecode obsolète. Vous avez téléversé le nouveau code, lancé vos tests via CLI, tout semblait bon, et le pool web sert encore l’ancien build. Réinitialisez via un endpoint PHP accessible par le web. Nous gardons un opcache-reset.php à nom fixe dans chaque projet exactement pour cela.
• Colonnes personnalisées sur les tables cœur. Si vous avez ajouté des colonnes à ps_order, ps_product, etc., comparez-les à upgrade/sql/9.1.0.sql. Les collisions de schéma font tomber une boutique.
• Webhooks de paiement pointant vers l’ancienne URL. Changement de domaine pendant la migration ? Mettez à jour l’URL de webhook dans Stripe, PayPal, Adyen, ou celui que vous utilisez. Des webhooks manqués signifient des confirmations de commande manquées et des clients mécontents.
• Chemins cron. 9.x a déplacé certains points d’entrée. Revérifiez chaque tâche planifiée après la mise à niveau.
• Templates d’e-mails. Le moteur de templates a évolué en 9.x. Les templates d’e-mails personnalisés venus de 1.7 ne se rendent pas toujours correctement. Testez chaque type d’e-mail transactionnel, pas seulement la confirmation de commande.

Échecs de mise à niveau de modules nommés (et correctifs)

Une poignée de modules cœur précis causent la plupart des rapports « la mise à niveau s’est terminée mais le back-office est mort ». Ils méritent d’être vérifiés avant de lancer la mise à niveau, avec les vrais correctifs :

• ps_mbo (Marketplace in your Back Office) peut faire tomber le back-office. Mettez à niveau vers 9.0 avec ps_mbo installé, et le back-office peut devenir inaccessible au chargement, le réinstaller sur 9.0 reproduit l’erreur. Correctif : désinstallez ps_mbo avant de lancer la mise à niveau 9.0. (Issue PrestaShop #38983.)
• ps_edition_basic est réservé à PrestaShop 8 et n’est pas supprimé automatiquement. S’il reste installé, il peut provoquer une erreur sur la page d’accueil après la mise à niveau. Correctif : changez la page par défaut de votre back-office pour ne plus utiliser le tableau de bord Edition Basic et désinstallez ps_edition_basic avant la mise à niveau, ou laissez l’étape des modules incompatibles de l’Update Assistant le supprimer (elle lit maintenant la compatibilité de version déclarée par chaque module).
• ps_distributionapiclient (DistributionApi) peut provoquer une erreur 500 dans le back-office. La mise à niveau se termine, mais la mise à jour de ce module échoue ensuite avec "Too few arguments to function DistributionApi::__construct(), 6 passed and exactly 7 expected", puis vider le cache met le back-office en 500 (la boutique front-office continue de fonctionner). Au moment de la rédaction, c’est toujours ouvert sans correctif officiel (issue #39032), donc ne videz pas le cache après l’échec d’une mise à jour DistributionApi, et vérifiez l’issue avant de migrer une boutique qui en dépend fortement.
• Le back-office continue d’indiquer « mise à jour disponible » après que vous avez déjà mis à jour un module. Sur les premières 9.0, la colonne version de ps_module n’était pas écrite après une mise à jour de module, donc l’invite ne disparaissait jamais. Correctif : mettez à niveau vers 9.0.1 ou une version ultérieure. Le problème a été résolu par un nouveau parseur de versions de modules (PR #39358). Si vous êtes bloqué sur un build plus ancien, le contournement communautaire consiste à définir la ligne à la main : UPDATE ps_module SET version='<installed>' WHERE name='<module>' (cela efface l’invite, mais ce n’est pas un correctif officiel). (Issue #39151.)
• L’Update Assistant s’arrête sur un lien symbolique. Sur les hébergeurs qui interdisent les symlinks, le passage 8.2.1 → 9.0.0 peut s’arrêter avec "Could not extract link admin/bundles/apiplatform … Failed to create 'symbolic' link". Correctif : mettez à jour le module Update Assistant (autoupgrade) vers une version actuelle et assurez-vous que votre hébergeur autorise les symlinks. (Issue #38892.)

Aucun de ces points n’est une raison de ne pas mettre à niveau. Ce sont des raisons de faire d’abord la passe de compatibilité modules en préproduction, qui est l’étape 2 de la liste de contrôle ci-dessus.

Performance, honnêtement

9.1 sur Symfony 6.4 est plus rapide que les anciennes versions, mais les raisons n’ont rien de magique :

• La compilation du conteneur coûte moins cher dans Symfony 6.4 que dans 4.4. Le temps de bootstrap baisse.
• Hummingbird 2.0 embarque moins de CSS et de JS que Classic. Avec jQuery déprécié, les nouvelles installations transportent une charge JS plus légère que 1.7 n’en a jamais eu.
• PHP 8 JIT. Le passage de 7.x à 8.x explique la plupart des grands chiffres « PrestaShop est devenu plus rapide ». 10–30 % est typique pour des charges catalogue.
• Le cache HTTP / Doctrine dans Symfony 6.4 a une génération de maturité de plus que dans 4.4.

Sur notre propre conteneur de développement, une boutique de 5 000 produits en 9.1 avec Hummingbird 2.0 sert les pages catégorie à environ 120 ms de TTFB. Le même matériel sous 1.7 avec Classic était autour de 250 ms. Ce chiffre vient d’un environnement de développement, pas d’une promesse de production, votre résultat dépendra de l’hébergement, des modules et de la configuration. Mais la direction est réelle.

À propos de nos modules

Les 159 modules mypresta.rocks ont tous été passés sur 9.1, et mypresta.rocks lui-même tourne en production sur 9.1.3. Nous livrons une seule base de code par module ; chaque module du catalogue déclare une prise en charge de PrestaShop 1.6 jusqu’à la version actuelle, sans plafond de version dur ni forks séparés ou ZIP spécifiques par version.

Les éléments qui comptent pour la compatibilité entre versions :

• Couche d’administration. Nous utilisons un framework d’administration partagé (notre package prestashop-admin) qui encapsule la coque Symfony afin que les modules individuels n’aient pas à le faire. Onglets parents, fil d’Ariane, barre latérale, tout fonctionne dans l’administration 9.1 sans changement par module.
• Traduction. Nous utilisons $this->module->l() partout parce que cela survit aux versions. La suppression de $this->l() dans les contrôleurs d’administration ne nous affecte pas.
• Formatage des prix. Tools::displayPrice() est supprimé en 9.0. Nous l’encapsulons dans MyPrestaRocks\Compat\PriceFormatter, appelle le formateur moderne basé sur la locale en 8.x/9.x, retombe sur 1.7. Un helper, toutes les versions PS, aucun if (version_compare(...)) dispersé dans les templates.

Si vous planifiez une migration et voulez tester notre pile sur vos données, prenez une démo gratuite de 30 jours en préproduction lorsqu’elle est disponible. Si vous préférez être accompagné, nous proposons aussi du conseil en migration.

FAQ

Puis-je sauter la 8 et passer directement de 1.7 à 9.1 ?

Oui. L’Update Assistant prend en charge le passage direct 1.7.x → 9.x. Aucune étape intermédiaire en 8.x n’est nécessaire. Réserve : confirmez d’abord que chaque module est compatible 9.x.

Mon thème Classic fonctionnera-t-il encore sur 9.1 ?

Oui. Classic est mis à jour en 3.1.1 dans 9.1 et reste entièrement pris en charge, il n’est simplement plus le thème par défaut des nouvelles installations. Un thème enfant Classic devrait continuer à fonctionner avec de petits ajustements.

Le multi-transporteurs est-il prêt pour la production ?

Il est livré derrière un feature flag. PrestaShop le considère assez stable pour être utilisé mais se réserve le droit de modifier l’API. Si c’est critique pour votre activité, activez-le en préproduction, écrivez des tests d’intégration et préparez-vous à revoir votre code en 9.2.

Quelle version de PHP ?

8.2 ou 8.3 pour les piles de production conservatrices. 8.1 est le minimum. 8.4 et 8.5 sont pris en charge et nous faisons tourner 8.4 en développement, mais vérifiez toute votre pile de modules avant de la pousser en production.

Combien de temps prend une migration typique ?

8.x → 9.1 sans modules exotiques : un après-midi. 1.7 → 9.1 avec une boutique chargée en modules : une à deux semaines de tests. 1.6 → 9.1 avec reconstruction de thème : deux à six semaines. La mise à niveau elle-même est rapide. C’est la vérification de chaque flux qui prend du temps.

Attendre ou commencer à préparer maintenant ?

Commencez maintenant. 9.1.0 est stable. L’étape suivante est une mise à niveau en préproduction, auditer les modules, tester le tunnel de commande, vérifier le thème, planifier la bascule en production.

PrestaShop 9 est-il prêt pour la production ?

Oui. 9.1.0 est stable depuis mars 2026 et repose sur la branche Symfony 6.4 LTS, la plus longue piste de support disponible aujourd’hui. Nous faisons tourner mypresta.rocks lui-même sur 9.1.3. La réserve honnête est celle habituelle pour une version majeure : les nouveaux moteurs multi-transporteurs et de remises sont livrés derrière des feature flags, donc testez-les en préproduction avant de les activer en production.

Mes modules existants fonctionneront-ils sur PrestaShop 9.1 ?

Les modules bien maintenus le font généralement. Le chemin 1.7 → 9.x est pris en charge. Les vrais risques sont quelques modules cœur précis pendant la mise à niveau elle-même (voir les correctifs par module nommés ci-dessus) et tout module qui appelle des API supprimées en 9.0, comme Tools::displayPrice(). Confirmez la prise en charge 9.x module par module en préproduction avant le passage en production, et remplacez d’abord ceux qui ne sont pas pris en charge.

Conclusion

9.0 était la révolution : Symfony 6.4, nouvelle API d’administration, architecture moderne. 9.1 est la version qui rend 9.0 pratique, un thème moderne prêt pour la production, le modèle de livraison que les marchands demandent depuis l’époque des 1.x, et un moteur de remises qui ne s’effondre pas sous 600 règles panier.

Quelle que soit votre version de départ, c’est celle vers laquelle il vaut la peine de migrer. Plus vous attendez, plus l’écart se creuse. Si vous attendiez « la bonne version », c’est la 9.1.

À lire aussi

• Comment migrer vers PrestaShop 9 : guide complet de mise à niveau
• Thèmes enfants PrestaShop : guide de personnalisation Classic & Hummingbird
• Dépannage PrestaShop : corriger les écrans blancs & erreurs 500
• Optimisation des performances des requêtes de base de données PrestaShop et du cache pleine page