Expérience post-achat : ce qui se passe après la commande compte

La plupart des boutiques PrestaShop concentrent toute leur attention sur la partie du parcours qui s’achève lorsque le client clique sur "Passer commande". Tout ce qui vient ensuite — l’e-mail de confirmation, l’attente, le colis sur le pas de la porte, puis le silence — fonctionne avec ce que la plateforme envoie par défaut. C’est une occasion manquée, car la période après la commande est celle où un acheteur décide si vous n’étiez qu’une transaction ponctuelle ou une boutique vers laquelle il reviendra. Ce guide porte sur cette fenêtre précise : l’expérience post-achat dans PrestaShop, l’endroit où elle se configure dans le back-office, et les réglages concrets qui la transforment d’un détail oublié en raison de recommander.

Pour bien cadrer le sujet : il ne s’agit pas ici d’un article sur la stratégie de fidélisation (la vision plus large qui consiste à transformer les acheteurs en clients réguliers est traitée dans le premier achat n’est qu’un début), ni d’un article sur les raisons économiques qui rendent les acheteurs récurrents si importants — c’est le sujet de la valeur vie client. Ici, nous parlons de la couche opérationnelle qui soutient les deux : ce que votre boutique fait réellement, automatiquement, dans les jours qui suivent le paiement.

Où se situe l’expérience post-achat dans PrestaShop

Presque tout ce qui est décrit dans cet article repose sur un mécanisme que la plupart des marchands ne configurent jamais de façon délibérée : les états de commande. Dans PrestaShop, chaque commande passe par des états définis dans Paramètres de la boutique → Commandes → États (le contrôleur AdminStatuses, appuyé par la classe OrderState et les tables ps_order_state / ps_order_state_lang). Chaque état comporte un ensemble d’options — surtout la case "Envoyer un e-mail au client.", liée à un modèle d’e-mail précis, ainsi que "Définir la commande associée comme expédiée.", "Définir la commande associée comme payée." et "Définir la commande associée comme livrée."

Qu’est-ce que cela change pour vous ? La plupart des mises à jour après le paiement sont pilotées par les états de commande, même si la création de commande et les modules de paiement peuvent aussi envoyer leurs propres e-mails. "Paiement accepté", "Préparation en cours", "Expédiée", "Livrée" : chacun correspond à une ligne OrderState qui peut, ou non, déclencher un e-mail. Si votre communication post-achat semble pauvre, la cause est presque toujours là : des états dont la case d’envoi d’e-mail n’est pas cochée, ou des modèles standards que personne n’a réécrits. Pour améliorer l’expérience, il faut modifier les états, pas greffer un outil séparé.

La chronologie post-achat, appliquée à PrestaShop

Il est utile de voir toute la séquence et l’endroit où chaque étape se pilote, car les points de contact sont répartis dans différentes zones du back-office :

Les quatre premières lignes sont natives dans PrestaShop et peuvent être correctement configurées dès aujourd’hui, gratuitement. Les trois dernières nécessitent un déclencheur externe, car le cœur de PrestaShop ne sait pas "envoyer quelque chose X jours après la livraison" — nous y revenons à la fin.

Confirmation de commande : l’e-mail le plus ouvert que vous enverrez

La confirmation de commande est le message qui reçoit le plus d’attention dans toute la relation — les confirmations transactionnelles affichent régulièrement des taux d’ouverture très supérieurs aux e-mails marketing, parce que le client les attend activement. PrestaShop envoie order_conf lorsque la commande est validée et créée par le module de paiement ; un changement d’état vers paiement accepté peut envoyer un e-mail d’état distinct. La version par défaut est fonctionnelle, mais vite oubliée. La modifier dans International → Traductions → Traductions des e-mails (ou dans les modèles bruts de mails/<lang>/, avec Apparence → Thème d’e-mail le cas échéant) fait partie des changements les moins coûteux et les plus rentables. Ce qu’elle doit contenir :

• Un récapitulatif de commande clair que le client peut vérifier d’un coup d’œil — produits, quantités, total et adresse de livraison. Le modèle par défaut l’inclut déjà ; ne le retirez pas.
• Une date de livraison prévue précise, pas une fourchette vague. "Arrive jeudi 19 juin" rassure ; "3–5 jours ouvrés" oblige le client à faire le calcul. PrestaShop ne fournit pas nativement d’estimation de livraison par commande dans la confirmation, et c’est exactement ce manque que comble notre module Estimated Delivery Date : il calcule et affiche une date concrète sur la fiche produit, puis la transmet jusqu’après l’achat, afin que la date vue par le client avant de commander soit celle qu’il voit ensuite. Le bénéfice : moins de tickets "où est ma commande ?", parce que vous avez répondu à la question avant qu’elle ne soit posée.
• Ce qui se passe ensuite. Une phrase — "Vous recevrez un lien de suivi dès l’expédition de votre commande" — transforme un silence anxiogène en attente maîtrisée.
• Un moyen évident de vous contacter. Une confirmation sans contact support donne l’impression qu’une machine se parle à elle-même. Les raisons pour lesquelles nous considérons les réponses rapides comme non négociables méritent leur propre sujet : le support compte.

Une réalité pratique de PrestaShop : les commandes qui restent bloquées sur "En attente de paiement" (virement bancaire, certaines passerelles avec redirection) peuvent ne pas recevoir le même message de paiement accepté. Si un client dit n’avoir reçu aucune confirmation, vérifiez d’abord l’historique des états de la commande ainsi que le comportement du journal d’e-mails et des modèles pour ce module de paiement — et si vous devez en renvoyer une après avoir corrigé un état, notre module Resend Order Confirmation ajoute un bouton en un clic sur la page de commande, au lieu de vous obliger à simuler un changement d’état. Et alors ? Le support résout "je n’ai jamais reçu mon reçu" en quelques secondes, directement depuis la commande qu’il consulte déjà.

Expédition et suivi : le moment où l’attente devient nerveuse

Entre "Paiement accepté" et l’arrivée du colis, le client a payé mais n’a encore rien en main. C’est la partie la plus fragile. PrestaShop la gère via l’état "Expédiée" : lorsque vous passez une commande en Expédiée et saisissez un numéro de suivi (le modèle d’URL du transporteur se trouve dans Livraison → Transporteurs, ce qui transforme le numéro en lien cliquable), le client reçoit automatiquement l’e-mail de transit.

• Envoyez la notification d’expédition au moment même où vous expédiez — avec le numéro de suivi et un lien direct vers la page du transporteur. C’est natif ; il faut simplement penser à définir l’état et à remplir le champ de suivi, au lieu de laisser les commandes bloquées sur "Préparation".
• Soyez proactif en cas de retard. Si un transporteur prend du retard, un court message du type "nous avons un jour de retard, nouvelle estimation vendredi" envoyé avant que le client ne s’en aperçoive inspire plus confiance qu’une livraison parfaite. PrestaShop ne le générera pas pour vous — c’est une note manuelle ou un état à ajouter — mais c’est l’habitude la plus rentable de tout le flux post-achat.
• Faites travailler l’état natif "Livrée". PrestaShop fournit par défaut un état "Livrée" (avec l’option correspondante "Définir la commande associée comme livrée."), mais il n’envoie généralement aucun e-mail et beaucoup d’équipes n’y passent jamais leurs commandes. Ouvrez-le dans États, cochez "Envoyer un e-mail au client." et associez-lui un message de confirmation serein : vous obtenez ainsi un déclencheur propre pour tout ce qui suit — les automatisations de suivi et de demande d’avis en aval peuvent s’appuyer sur cet état précis.

Si votre flux de travail est plus complexe que ce que permettent les états par défaut — par exemple limiter les personnes autorisées à passer une commande de Préparation à Expédiée, ou diriger les états vers le bon service — c’est le sujet de notre guide sur la montée en charge, et le module Order Workflow existe précisément pour imposer des transitions d’état personnalisées et des autorisations par service, afin qu’une équipe occupée ne puisse pas envoyer un e-mail "Expédiée" pour une commande qui n’a pas encore été préparée.

Le moment du déballage

Cette partie ne relève pas du logiciel, et prétendre qu’un module peut la résoudre serait malhonnête — mais elle fait partie de l’expérience post-achat, donc elle mérite un paragraphe. Le bon de livraison généré par PrestaShop (depuis la commande, ou en lot depuis Commandes) est l’équivalent imprimé de la confirmation numérique ; un colis physique sans aucun document à l’intérieur paraît incomplet. Un autocollant sur une boîte simple, un remerciement manuscrit d’une ligne ou un petit code de réduction pour la prochaine commande coûtent presque rien et créent une dose de sympathie disproportionnée. Une précaution propre à PrestaShop : lorsqu’une commande est expédiée à une adresse différente — probablement un cadeau — utilisez un bon de livraison plutôt qu’une facture, afin de ne pas afficher les prix au destinataire.

Suivi, avis et réactivation : la partie que le cœur ne peut pas faire seul

Tout ce qui précède est natif dans PrestaShop. Les trois points de contact suivants ne le sont pas, et il vaut la peine d’expliquer pourquoi : le cœur ne dispose pas d’un planificateur capable de dire "envoyer cet e-mail au client sept jours après que sa commande a atteint l’état Livrée". Cette logique de temporisation doit venir de l’extérieur, et c’est là que le flux post-achat se transforme en fidélisation durable… ou s’arrête simplement.

• Contrôle de satisfaction (3–7 jours après la livraison). Un vrai "tout se passe bien ?" — pas un argumentaire commercial — permet de repérer les problèmes tant qu’ils peuvent encore être corrigés et montre que vous avez continué à vous soucier de la commande après l’encaissement.
• Demande d’avis (7–14 jours après la livraison). Assez tard pour que le produit ait été utilisé, assez tôt pour que l’expérience soit encore fraîche. La mécanique de collecte des avis, leur affichage et leur capacité à générer des extraits enrichis sont un sujet à part entière — nous le traitons dans la mise en avant client plutôt que de le répéter ici.
• Réactivation (30–60 jours). Produits complémentaires, rappel de réassort au moment où un consommable approche de la fin, ou nouveautés d’une catégorie. Qui reçoit quel message relève de la segmentation — la segmentation client et l’approche RFM expliquent comment découper votre liste sans diplôme en analyse de données.

Pour relier ces messages à de vrais événements de commande, vous connectez PrestaShop à une plateforme e-mail compatible avec les automatisations déclenchées par état de commande. Nos intégrations Brevo et ActiveCampaign synchronisent vos clients et vos commandes, afin qu’un état "Livrée" dans PrestaShop puisse lancer une séquence programmée de l’autre côté. Le bénéfice, formulé honnêtement : l’intégration déplace les données et déclenche le scénario — mais la séquence doit toujours être rédigée par vous, et elle sera envoyée que le texte soit bon ou non. Configurez-la une fois, puis le suivi, la demande d’avis et la réactivation fonctionneront automatiquement pour chaque commande à partir de ce moment-là.

Quand l’expérience post-achat tourne mal

Les livraisons en retard, les produits endommagés et les mauvais articles sont inévitables à volume élevé. La façon dont vous les traitez définit davantage votre marque qu’une centaine de commandes sans accroc. Le schéma qui fonctionne : répondre en quelques heures plutôt qu’en quelques jours, présenter des excuses sans rejeter la faute sur le transporteur, commencer par la solution plutôt que par l’explication logistique, et corriger un peu plus que nécessaire — un remboursement accompagné d’un petit code coûte peu et sauve souvent la relation. Le paradoxe de la récupération est réel : un client dont le problème a été bien résolu finit souvent plus fidèle qu’un client qui n’a jamais rencontré de problème. Le fil de messages par commande et les notes de commande de PrestaShop gardent tout cet échange attaché à la commande, afin que n’importe quelle personne de votre équipe puisse le reprendre avec tout le contexte.

Un point de départ en 30 minutes

Vous n’avez pas besoin de lancer un projet pour améliorer cela — il s’agit surtout de modifier ce qui existe déjà :

• Ouvrez Paramètres de la boutique → Commandes → États et vérifiez quels états envoient réellement un e-mail au client. Cochez la case pour ceux qui devraient le faire.
• Réécrivez le modèle order_conf dans International → Traductions → Traductions des e-mails (ou dans les fichiers bruts mails/<lang>/) pour y inclure une ligne claire sur la prochaine étape et un contact support évident.
• Activez un e-mail sur l’état natif "Livrée" avec un message de clôture chaleureux — il devient le déclencheur de tout ce qui suit.
• Assurez-vous que les numéros de suivi et les URL des transporteurs sont bien renseignés, afin que l’e-mail d’expédition pointe directement vers le transporteur.
• Choisissez un point de contact externe à ajouter — généralement la demande d’avis — et branchez-le via votre plateforme e-mail.

Le paiement reçoit toute l’attention, mais les jours qui suivent la commande sont ceux où les clients décident discrètement si vous comptez encore pour eux. Sur PrestaShop en particulier, presque tout est déjà disponible — états de commande, modèles d’e-mail, champs de suivi — en attente d’être configuré intentionnellement au lieu de laisser les réglages par défaut parler au nom de la marque. Faites-les correctement, ajoutez un seul suivi programmé, et un acheteur ponctuel aura une raison de revenir.