Panier qui se vide sur PrestaShop - Causes & solutions

Symptômes : comment confirmer le diagnostic

Avant de toucher à quoi que ce soit, identifie précisément QUAND le panier se vide. C'est l'information qui détermine la cause. Le message affiché côté client est presque toujours le même ("Votre panier est vide"), mais le déclencheur, lui, change tout.

Reproduis le bug toi-même en navigation privée, DevTools ouvert sur l'onglet Application > Cookies. Note si le cookie de session PrestaShop (préfixe du type PrestaShop-xxxxxxxx, ou ps_cart selon ta config) est présent, son domaine exact (.tondomaine.fr vs tondomaine.fr), son attribut SameSite et son expiration. Un cookie absent, ou présent sur le mauvais domaine, est déjà la moitié du diagnostic.

• Se vide au refresh ou au changement de page → cause cookie/domaine ou mini-panier Ajax (branche A).
• Se vide au retour de la passerelle de paiement → SameSite + mode POST/GET (branche B). C'est la cause n°1 depuis 1.7.
• Se vide à la connexion/identification du client → panier invité non rattaché au compte (branche C).
• Se vide pour TOUS les clients en même temps, souvent après une mise à jour, une migration serveur ou un déploiement → cache/proxy ou _COOKIE_KEY_ (branche D).
• Panier différent entre deux onglets, deux appareils, ou panier d'un autre client → reverse proxy qui sert une page privée mise en cache (branche D).
• À distinguer : des paniers fantômes qui se REMPLISSENT seuls (lignes cart créées en masse) ne sont pas ce bug — ce sont des bots/scrapers qui frappent l'ajout au panier. Voir la note de désambiguïsation plus bas.

Impact business immédiat

Ce bug frappe à l'endroit le plus cher du tunnel. Chaque session qui perd son panier est un coût d'acquisition déjà payé (SEA, SEO, emailing) qui ne se convertit pas. Et quand le panier se vide AU RETOUR DU PAIEMENT, c'est le pire scénario : le client était prêt à payer, il a vu sa carte débitée ou la 3DS validée, et la commande n'existe pas côté boutique. Tu génères du SAV, des litiges et des remboursements en plus de la vente perdue.

• Hausse brutale et visible du taux d'abandon panier dans les stats (souvent le premier signal détecté).
• Baisse immédiate du CA journalier, proportionnelle au trafic — sur une grosse boutique ça se chiffre à l'heure.
• Paiements encaissés sans commande créée (cas retour paiement) : risque de chargeback et de perte de confiance.
• Budget publicitaire dépensé pour amener un trafic qui ne peut pas convertir.
• Érosion de la confiance : un client qui voit son panier disparaître ne revient pas, même bug corrigé.

Causes classées par probabilité

Sur PrestaShop 1.7 et plus, l'ordre réel de fréquence a changé par rapport aux vieux tutos. Voici le classement à jour, du plus fréquent au plus rare.

• 1. Cookie SameSite (1.7.8+). En Lax ou Strict, le cookie de session n'est pas renvoyé sur la requête POST cross-site de retour de paiement. La session est perdue, le panier semble vide. Cause n°1 moderne, quasi jamais traitée dans un guide panier dédié.
• 2. Incohérence domaine www / non-www (ou HTTP/HTTPS). Boutique configurée sur www.domaine.fr mais accédée via domaine.fr (ou inverse) : le cookie est posé sur un domaine, lu sur l'autre, donc invisible. Classique et très fréquent après un passage SSL.
• 3. Reverse proxy / CDN qui met en cache des pages privées. Varnish, Cloudflare APO ou un cache full-page qui sert panier/checkout/compte client depuis le cache : panier vide ou croisé entre clients.
• 4. Mini-panier en mode Ajax. Le produit est bien ajouté en base mais le bloc panier ne se rafraîchit pas, ou paraît vide au changement de page.
• 5. Panier invité non rattaché au compte à la connexion (réglage Clients).
• 6. Cache Smarty / compilation corrompue après mise à jour de thème ou de module.
• 7. _COOKIE_KEY_ modifié (migration, changement de serveur, réinstallation) : tous les cookies existants deviennent illisibles → tous les paniers invités vidés. Comportement attendu, pas un bug.
• 8. Module ou thème tiers en conflit (override de Cart, hook panier, module de connexion sociale qui régénère l'id_guest).
• 9. Durée de vie du cookie front-office trop courte.
• 10. .htaccess corrompu (URL rewriting cassé, boucle de redirection ERR_TOO_MANY_REDIRECTS).
• 11. Tables cart / cart_product incohérentes en base.

Diagnostic : les commandes à lancer

Ne devine pas. Active d'abord le mode debug pour voir l'erreur réelle, puis trace la session côté serveur. L'objectif est d'observer ce qui arrive à l'id_cart et au cookie pour une session que tu contrôles.

Active le mode développement en éditant le fichier de config, puis surveille les logs PHP et serveur pendant que tu reproduis le bug.

// config/defines.inc.php
define('_PS_MODE_DEV_', true);
// Recharge la page qui plante : l'erreur réelle s'affiche au lieu de la page blanche/panier vide.
// Remets false une fois le diagnostic terminé.

# Erreurs PHP applicatives
tail -f var/logs/*.log

# Erreurs serveur web (adapte le chemin selon Apache/Nginx)
tail -f /var/log/apache2/error.log
tail -f /var/log/nginx/error.log

# Repère les redirections en boucle ou les sessions perdues
grep -iE 'cart|cookie|session|redirect' var/logs/*.log | tail -n 50

DevTools > Application > Storage > Cookies > https://tondomaine.fr
Contrôle pour le cookie de session PrestaShop :
- Domain : doit matcher le domaine configuré (.tondomaine.fr OU tondomaine.fr, pas les deux versions concurrentes)
- SameSite : si "Lax" ou "Strict" et que le bug est au retour paiement -> coupable probable
- Secure : doit être coché si tout le site est en HTTPS
- Expires : ne doit pas être "Session" si tu attends une persistance

-- Le panier existe-t-il vraiment en base alors que le front affiche vide ?
SELECT id_cart, id_customer, id_guest, id_shop, date_upd
FROM ps_cart
ORDER BY date_upd DESC
LIMIT 20;

-- Les produits sont-ils bien rattachés à ce panier ?
SELECT * FROM ps_cart_product WHERE id_cart = <ID_DU_CART>;

-- Détecter un id_guest qui change (module connexion sociale qui écrase le panier invité)
SELECT id_guest, COUNT(*) FROM ps_cart GROUP BY id_guest ORDER BY 2 DESC LIMIT 10;
-- Remplace ps_ par ton vrai préfixe de tables.

# Le panier/checkout ne doit JAMAIS revenir depuis le cache.
# Cherche un header de cache HIT sur une page privée = bug confirmé.
curl -sI https://tondomaine.fr/panier | grep -iE 'cache|cf-cache-status|x-varnish|age'
# cf-cache-status: HIT ou Age > 0 sur /panier ou /commande = page privée cachée -> branche D

Solutions pas-à-pas

Applique la branche qui correspond à ton symptôme. Sauvegarde avant toute modification de fichier ou de base, et travaille sur staging quand c'est possible.

1. BRANCHE B — Se vide au retour de paiement (SameSite, cause n°1). Va dans Paramètres de la boutique > Général. Passe l'attribut Cookie SameSite sur "Aucun (None)". En None, l'attribut Secure devient obligatoire : ton site doit donc être 100% HTTPS. Si ton PSP propose le retour en mode GET plutôt que POST (Systempay/PayZen, Monetico, Lyra le documentent), bascule-le aussi : un retour GET conserve le cookie même en SameSite=Lax.
2. BRANCHE A/D — Incohérence de domaine. Va dans Paramètres de la boutique > Trafic & SEO > URL de la boutique. Renseigne le MÊME nom dans "Domaine" ET "Domaine SSL" (par ex. www.tondomaine.fr partout, sans le https://). Choisis une seule version (avec OU sans www) et impose-la par une redirection 301 dans le .htaccess.
3. Forcer le www (ou non-www) et le HTTPS dans .htaccess, à placer dans le bloc de réécriture PrestaShop, avant les règles existantes : voir le bloc de code ci-dessous.
4. BRANCHE A — Mini-panier Ajax. Dans Modules, configure ton bloc panier (ps_shoppingcart sur 1.7+) et désactive le mode Ajax si le panier paraît vide au changement de page. Vide ensuite le cache.
5. BRANCHE C — Panier perdu à la connexion. Va dans Paramètres de la boutique > Clients et active "Réafficher le panier après connexion" (Oui). Le panier invité sera rattaché au compte au login au lieu d'être abandonné.
6. BRANCHE D — Cache Smarty corrompu. Paramètres avancés > Performances : passe "Cache" sur Non, "Forcer la compilation" sur Oui, sauvegarde, puis clique "Vider le cache". Recharge, teste, puis remets une config cache propre (Cache Oui, compilation Non) une fois le bug confirmé résolu.
7. BRANCHE D — Proxy/CDN. Exclus explicitement du cache les routes privées : panier, commande/checkout, connexion et espace client. Sur Cloudflare APO, ajoute une Cache Rule "Bypass cache" sur ces URL ; sur Varnish, ajoute-les au vcl_recv en return(pass). Purge ensuite le cache CDN EN PLUS du cache PrestaShop.
8. BRANCHE D — Cache serveur via .htaccess/headers : vide le cache complet après chaque changement de domaine ou de config cookie, sinon tu testes une page périmée.
9. Conflit module/thème. Désactive les modules récents un par un (mini-panier custom, connexion sociale, livraison, promo) et reteste à chaque fois. Un module qui régénère l'id_guest ou override la classe Cart est le suspect type.
10. Durée de vie du cookie. Paramètres de la boutique > Général : augmente la "Durée de vie du cookie front office" si les paniers expirent trop vite (équivalent de l'ancienne constante PS_COOKIE_LIFETIME_FO).
11. En dernier recours, .htaccess corrompu : régénère-le via Paramètres de la boutique > Trafic & SEO > bouton "Générer le fichier .htaccess", ou restaure une version saine à la racine. Vérifie qu'il n'y a pas de boucle ERR_TOO_MANY_REDIRECTS.

# À placer après "RewriteEngine on" dans le bloc PrestaShop
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.tondomaine.fr/$1 [R=301,L]

# Forcer le www (évite que le cookie soit posé sur deux domaines distincts)
RewriteCond %{HTTP_HOST} ^tondomaine\.fr [NC]
RewriteRule ^(.*)$ https://www.tondomaine.fr/$1 [R=301,L]

Spécificités par version

Les chemins back-office ont changé entre 1.6 et 1.7, et la cause dominante aussi. Voici le mapping pour ne pas chercher au mauvais endroit.

La table ci-dessous traduit l'ancienne nomenclature 1.6 (encore présente dans la plupart des tutos qui rankent) vers 1.7 / 8.x / 9.x.

• 1.6.x (héritage) : la cause classique était l'incohérence de domaine et le cache Smarty. Sur de très vieilles 1.5.x, un bug de regex sur le domaine dans classes/Cookie.php et un bloc d'optimisation dans classes/shop/Shop.php pouvaient vider le panier — ce code n'existe plus en 1.7+, ne le cherche pas.
• 1.7.0 à 1.7.7 : chemins back-office déjà modernisés. SameSite pas encore exposé : la cause reste surtout domaine + cache + proxy.
• 1.7.8+ : introduction de l'attribut Cookie SameSite (Lax par défaut). C'est le tournant : à partir de là, le retour de paiement POST cross-site casse les paniers. C'est devenu la cause n°1.
• 8.x : comportement SameSite identique à 1.7.8+. Réglage dans Paramètres de la boutique > Général. PHP 8.1+ recommandé.
• 9.x : même logique de session et de cookie. Vérifie en priorité SameSite=None + Secure (tout HTTPS) et l'exclusion CDN, qui restent les deux pièges modernes.
• Mapping des chemins : Préférences > Performances (1.6) = Paramètres avancés > Performances (1.7+). Préférences > SEO & URL (1.6) = Paramètres de la boutique > Trafic & SEO > URL de la boutique (1.7+). Préférences > Général et Préférences > Clients (1.6) = Paramètres de la boutique > Général et > Clients (1.7+).

Note de désambiguïsation : panier qui se vide vs paniers qui se remplissent seuls

Deux problèmes opposés se confondent dans les recherches. Si tu vois apparaître des dizaines ou centaines de lignes ps_cart créées sans commande, paniers "fantômes" qui se REMPLISSENT seuls, ce n'est pas ce bug de session : ce sont des bots/scrapers qui frappent l'URL d'ajout au panier. La réponse est différente — rate limiting, protection bot (Cloudflare), CAPTCHA sur l'ajout, et purge périodique des vieux paniers abandonnés. Ne va pas régler SameSite ou les domaines pour ça.

• Panier qui se VIDE pour un vrai client → session/cookie/cache (ce guide).
• Paniers qui se REMPLISSENT seuls en masse → bots, à traiter par protection anti-bot et nettoyage des tables cart.
• Doute ? Regarde id_customer dans ps_cart : des milliers de paniers à id_customer=0 créés en rafale = bots.

Quand appeler un expert

Si tu as suivi les branches A à D, vérifié les cookies dans DevTools, confirmé que le panier existe bien en base, et que le bug persiste — tu es probablement sur un conflit de module profond, un override de la classe Cart, une couche de cache serveur que tu ne maîtrises pas, ou un comportement aléatoire impossible à reproduire sans capturer les headers complets en production.

C'est exactement le terrain de BugRescue. On trace la session côté serveur sur un client réel, on capture les headers du tunnel de paiement et on isole la cause racine sans casser ta performance ni ta prod. Si tu perds des ventes chaque heure, ne laisse pas le bug tourner : un diagnostic ciblé coûte moins cher qu'une journée de CA perdu.

• Bug intermittent impossible à reproduire de façon fiable.
• Paiements encaissés sans commande créée (retour PSP) qui continuent malgré le réglage SameSite.
• Architecture multi-store, multi-domaine ou reverse proxy custom.
• Override de Cart/Cookie ou module sur-mesure suspecté.
• Migration ou changement de serveur récent avec _COOKIE_KEY_ modifié et effets de bord persistants.

FAQ