Le lien « recover_cart » renvoie vers l'accueil : pourquoi la récupération de panier ne fonctionne plus

Le symptôme

Un lien de récupération de panier généré depuis le back-office, du type /order?step=0&recover_cart=ID&token_cart=TOKEN, n'ouvre pas le checkout : il renvoie vers la page d'accueil, sans aucun message d'erreur visible. Ce n'est pas un problème du lien lui-même : le jeton est correct (il est calculé avec un hash qui combine la clé de cookie de la boutique et l'identifiant du panier), et il n'a pas expiré. Le clic ne mène simplement pas là où il devrait.

Ce que cela semblait être, et n'était pas

Le premier soupçon, raisonnable, était un problème de génération du lien : un jeton mal calculé, ou un format d'URL modifié par une mise à jour récente. Ce n'était pas ça : en comparant le lien généré par le back-office avec ce que PrestaShop s'attend à recevoir, les deux correspondaient exactement. Le deuxième soupçon était un cache ou une règle de redirection côté serveur qui intercepterait l'URL avant qu'elle n'atteigne PrestaShop. Écarté aussi : la requête arrivait à chaque fois au bon contrôleur.

À ce stade, il est devenu clair que le problème n'était pas dans le lien, mais dans quelque chose qui concernait le panier ou le client auquel il appartient, puisque certains liens fonctionnaient et d'autres non, avec exactement le même format.

La vraie cause

La récupération de panier dans PrestaShop passe par la méthode recoverCart(), appelée pendant FrontController::init(). En comparant les paniers qui échouaient avec ceux qui fonctionnaient, on découvre deux conditions distinctes qui mènent exactement au même symptôme (redirection vers l'accueil), et une seule des deux est à corriger.

• Le panier a déjà été commandé. Si une commande existe déjà pour ce panier, PrestaShop ne le rouvre pas : c'est un comportement correct, pas un bug, et il ne faut pas y toucher.
• Le client propriétaire du panier a été supprimé de façon « logique ». PrestaShop ne supprime jamais vraiment un client de la base de données : il positionne un indicateur (ps_customer.deleted = 1) et conserve l'historique des commandes. La méthode recoverCart(), en revanche, ne récupère pas un panier dont le propriétaire est marqué comme supprimé, même avec un jeton valide : elle ne le trouve tout simplement pas, comme si le panier n'existait pas, et la requête finit sur la page d'accueil.

Un client peut se retrouver marqué comme supprimé pour des raisons qui ne sont pas du tout une erreur technique : il a pu utiliser un module de conformité RGPD qui propose l'auto-suppression du compte, ou avoir été supprimé par un opérateur du back-office. Dans les deux cas, le comportement de PrestaShop est correct de son point de vue : un compte supprimé ne devrait pas pouvoir redevenir actif simplement en cliquant sur un lien. Le problème pratique, c'est que ce lien est souvent le seul moyen pour un vrai client de reprendre un achat qu'il avait commencé, et que la réponse qu'il obtient, une page d'accueil générique sans explication, ne lui dit pas pourquoi.

Le correctif

Le correctif porte sur recoverCart() : quand le jeton est valide mais que le client propriétaire est marqué comme supprimé, au lieu d'abandonner la récupération, le code vérifie s'il existe un autre compte, actif, avec la même adresse e-mail.

• S'il n'existe aucun compte actif jumeau, le client supprimé est réactivé (deleted = 0) et la récupération se poursuit normalement.
• S'il existe déjà un compte actif avec la même adresse e-mail (le cas typique est un client qui s'est réinscrit après avoir supprimé son ancien compte), le panier est transféré sur le compte actif, et ses adresses associées sont vidées pour être choisies à nouveau au checkout, au lieu d'être reprises d'un compte qui n'est plus utilisé activement. Cette distinction est la partie qui compte le plus : réactiver un compte alors qu'un autre compte actif partage déjà la même adresse e-mail créerait deux comptes parallèles avec le même identifiant de connexion, ce qui casse la connexion dans PrestaShop.

Les deux chemins sont inscrits dans un journal applicatif avant que la récupération normale du panier ne se poursuive : c'est le seul moyen de reconstituer plus tard pourquoi un compte supprimé est redevenu actif.

Il y a ici une question de politique, et pas seulement de technique, qu'il vaut la peine de dire explicitement : si un client avait demandé la suppression de son compte pour des raisons de protection des données, ce correctif l'annule au moment où il clique sur son propre lien de récupération. C'est défendable parce que c'est le client lui-même qui en est à l'origine, sur le lien qui lui a été envoyé, mais cela reste un choix de politique à peser au cas par cas, pas un simple détail d'implémentation.

Comment vérifier que le correctif tient

• Reproduisez les deux cas : un client supprimé sans compte jumeau (il doit être réactivé, et le checkout doit se charger), et un client supprimé avec un compte jumeau actif sur la même adresse e-mail (le panier doit passer sur le compte actif, adresses vidées, sans toucher à l'état de l'ancien compte).
• Vérifiez qu'un panier déjà lié à une commande reste bien non récupérable : ce correctif ne doit pas changer ce comportement, qui est correct tel quel.
• Consultez le journal applicatif après chaque récupération impliquant un client supprimé : il doit y avoir une ligne pour chaque réactivation ou transfert, indiquant lequel des deux cas s'est produit.
• Si la boutique utilise un module de conformité RGPD avec auto-suppression du compte, incluez ce scénario dans les tests après chaque mise à jour de ce module : c'est là que naissent le plus souvent les clients supprimés logiquement.

La boutique sur laquelle ce cas a été diagnostiqué reste volontairement anonyme. Si un lien de récupération de panier au jeton correct renvoie vers l'accueil au lieu d'ouvrir le checkout, et que le panier concerné n'a pas déjà été commandé, le bon endroit où chercher est l'état du client propriétaire, pas le lien lui-même. Pour la maintenance courante d'une boutique PrestaShop, un résumé des services se trouve sur cette page.