Renvoyer les confirmations de commande : une petite fonctionnalité que les clients apprécient vraiment

Voici une demande que tous les supports PrestaShop voient revenir sans cesse : « Je n'ai jamais reçu ma confirmation de commande — pouvez-vous me la renvoyer ? » Cela paraît anodin, et c'est précisément pour cette raison que beaucoup de boutiques le gèrent mal. Le client a passé commande, l'e-mail est parti, puis il a disparu dans un dossier spam, un onglet Promotions ou après une suppression accidentelle. Résultat : plus de référence de commande, plus de preuve de paiement, plus de lien de suivi — et un doute persistant sur le fait que la commande soit bien passée. La solution est simple, elle repose en grande partie sur ce que PrestaShop sait déjà faire, et elle supprime discrètement l'une des tâches les plus répétitives de votre équipe. Ce guide porte sur cette fonctionnalité précise : renvoyer l'e-mail de confirmation de commande — depuis votre back-office aujourd'hui, et en libre-service client demain.

Dernière mise à jour : juin 2026.

Ce n'est qu'une partie d'un processus de gestion des commandes plus large. Pour une vue d'ensemble sur la façon de traiter les commandes efficacement — statuts, actions groupées, routines quotidiennes — commencez par les workflows de gestion des commandes qui vous font gagner des heures. Ici, nous restons concentrés sur un point précis : remettre une confirmation de commande entre les mains du client.

Pourquoi les e-mails de confirmation se perdent au départ

Les propriétaires de boutique ont tendance à croire que « e-mail envoyé » signifie « e-mail lu ». Ce n'est pas le cas. Les e-mails transactionnels — confirmation de commande, avis d'expédition, facture — affrontent les mêmes filtres anti-spam et le même tri par onglets que tous les autres messages. Une part significative des e-mails transactionnels légitimes n'arrive jamais dans la boîte de réception ; le chiffre exact varie fortement selon la configuration d'envoi, donc ne vous accrochez pas à un pourcentage. Ce que vous pouvez maîtriser, c'est la question suivante : un e-mail perdu devient-il un ticket de support, ou un simple clic en libre-service ?

La cause profonde, dans beaucoup de boutiques PrestaShop, tient à l'infrastructure d'envoi. Si votre boutique envoie les e-mails via PHP mail() (Paramètres avancés → E-mail, le réglage par défaut sur de nombreuses installations) plutôt que via un SMTP authentifié, vos confirmations ont beaucoup plus de risques d'être signalées ou supprimées silencieusement — pas d'alignement SPF/DKIM, une adresse IP serveur sans réputation d'envoi, rien qui inspire confiance au serveur destinataire. Avant d'ajouter une fonctionnalité de renvoi, il vaut la peine de corriger la cause racine : passez au SMTP, envoyez l'e-mail de test depuis ce même écran, et vérifiez que SPF et DKIM sont bien publiés pour votre domaine. Un bouton de renvoi posé sur un expéditeur mal configuré ne fait que renvoyer des e-mails qui seront filtrés eux aussi.

Renvoyer une confirmation depuis le back-office — ce que PrestaShop offre déjà

La plupart des marchands passent à côté, donc autant être précis : PrestaShop peut renvoyer un e-mail de statut depuis la page de commande, sans module — mais avec une réserve importante. Ouvrez Commandes → Commandes, entrez dans la commande, puis regardez le bloc Statut près du haut de la page. La liste déroulante ne sert pas seulement à étiqueter la commande : réappliquer ou changer le statut vers un état auquel un modèle d'e-mail est associé déclenche à nouveau ce modèle. En revanche, cela ne permet pas de renvoyer proprement la confirmation de commande originale : cette confirmation est générée pendant la validation de la commande, et non par un e-mail classique lié à un état de commande. Il n'existe donc pas de bouton natif « renvoyer la confirmation » qui la reproduise sans modifier le statut de la commande (et sans ses effets de bord). Pour renvoyer proprement la confirmation originale, sans effet secondaire, il faut une logique personnalisée ou un module.

Le mécanisme se trouve dans la configuration des statuts de commande. Chaque statut (vous pouvez les consulter dans Paramètres de la boutique → Paramètres des commandes → États, stockés dans la table ps_order_state) possède une option « Envoyer un e-mail au client lorsque la commande est à cet état » et un modèle lié. Les statuts « En attente de paiement » / « Paiement accepté » / « Préparation en cours » pointent chacun vers un modèle comme payment ou preparation. La confirmation de commande originale (order_conf) est différente : elle est envoyée pendant le processus de validation de la commande ou du paiement, pas comme un e-mail ordinaire d'état de commande que l'on peut relancer depuis la liste déroulante. En pratique, pour un e-mail de statut, la méthode consiste donc à remettre la commande sur le statut que le client aurait dû recevoir, et PrestaShop renvoie cet e-mail de statut. Sous le capot, cela passe par OrderState et l'insertion dans l'historique de commande (OrderHistory::addWithemail()), c'est-à-dire le même chemin que l'e-mail automatique initial — le client reçoit donc un message identique et correctement formaté, pas une approximation tapée à la main.

Il y a toutefois un piège, et c'est précisément la raison d'être d'un outil dédié. Modifier le statut de commande pour redéclencher un e-mail écrit aussi une nouvelle ligne dans l'historique de la commande et peut faire avancer l'état du workflow. Selon le statut, cela peut également déclencher des comportements liés aux factures ou aux bons de livraison, exécuter des hooks et lancer des automatisations de modules rattachées à cet état (les mouvements de stock, eux, n'interviennent qu'avec des statuts de type annulation, remboursement ou remise en stock). Si votre seul objectif était de renvoyer l'e-mail, vous avez maintenant brouillé la chronologie de la commande, potentiellement déclenché des effets secondaires liés à ce statut, et rendu l'historique moins clair pour la personne qui le relira plus tard. Pour un cas isolé, cela peut passer. Comme habitude quotidienne sur des dizaines de commandes, c'est vite brouillon.

La voie propre côté back-office : un vrai « renvoi » qui ne touche pas au statut

Ce que les équipes support veulent réellement, c'est un bouton qui renvoie la confirmation sans modifier quoi que ce soit dans la commande — même modèle, mêmes données, aucune nouvelle ligne de statut, aucun effet secondaire. C'est exactement le manque que comble notre module Resend Order Confirmation : il ajoute un contrôle de renvoi en un clic sur la page de détail de commande dans le back-office. Concrètement, qu'est-ce que cela change ? Quand un client écrit, votre agent ouvre la commande, clique une fois, et la confirmation originale repart — pas besoin de retrouver le bon modèle, pas de rédaction manuelle, pas de changement de statut qui pollue l'historique de commande. L'agent y passe quinze secondes au lieu de cinq minutes, et le dossier de commande reste propre.

C'est une petite fonctionnalité, mais le calcul du temps gagné est bien réel. Traiter un renvoi manuellement — retrouver la commande, vérifier l'identité, trouver le modèle, renvoyer ou rechanger le statut — prend facilement cinq à dix minutes de temps support qualifié par demande, entre les changements de contexte et les vérifications. Une boutique qui reçoit même quelques demandes de ce type par semaine perd des heures chaque mois sur une tâche qui ne demande aucun jugement particulier. Ce temps est bien mieux utilisé sur les demandes qui nécessitent vraiment une intervention humaine : livraison endommagée, litige de remboursement, changement d'adresse après expédition.

Renvoi par statut ou renvoi dédié — que choisir

Mieux que renvoyer : faire en sorte que le client n'ait jamais besoin de demander

Le ticket de support le plus rapide est celui qui n'est jamais ouvert. PrestaShop expose déjà beaucoup de données de commande dans le compte client : lorsqu'un client connecté va dans Historique des commandes (le contrôleur history) puis clique sur Détails (le contrôleur order-detail, servi par order-detail.tpl), il peut voir la commande complète, les lignes de produits, la chronologie des statuts et toute facture disponible. Pour la plupart des demandes du type « où est ma confirmation ? », la réponse se trouve déjà sur cette page — le client ne savait simplement pas où regarder.

Deux actions bouclent la boucle :

• Rendre la page de détail de commande autonome. Si le contenu complet de la confirmation — référence de commande, articles, totaux, adresse de livraison, moyen de paiement — est visible dans le compte, l'e-mail devient une commodité plutôt que l'unique trace. Un client qui peut consulter sa commande en ligne a rarement besoin qu'on la lui renvoie par e-mail.
• Ajouter un lien « renvoyer la confirmation » dans le compte. Un simple lien sur la page de détail de commande, qui renvoie la confirmation à l'adresse e-mail du compte, transforme un ticket de support en clic en libre-service. La demande n'atteint jamais votre boîte de réception. C'est le même mécanisme de renvoi que le bouton du back-office, simplement exposé au client connecté pour ses propres commandes.

Une limite mérite d'être formulée clairement : le libre-service n'aide que les clients qui ont utilisé un compte. Un invité qui a commandé sans s'inscrire — et qui s'est trompé dans son adresse e-mail — ne peut pas se connecter pour retrouver quoi que ce soit. C'est précisément le cas où votre configuration SMTP et un renvoi propre depuis le back-office comptent le plus. Il vous faut donc les deux : le libre-service pour les titulaires de compte, et un renvoi back-office propre pour tous les autres.

La même logique vaut pour tous les e-mails transactionnels

Dès que vous traitez « le client a perdu l'e-mail » comme un problème récurrent que l'on peut résoudre, plutôt que comme une corvée au cas par cas, le même modèle s'étend à toute votre communication autour des commandes :

• Factures. La facture est l'e-mail que les clients demandent le plus souvent à recevoir à nouveau — pour leur comptabilité, leurs notes de frais ou une demande de remboursement. PrestaShop joint la facture PDF à la commande dès qu'elle dispose d'un numéro de facture valide ; assurez-vous que les clients peuvent la télécharger depuis leur compte, et si vous exportez régulièrement des factures pour votre comptabilité, consultez les exports CSV pour les commandes et les factures.
• Notifications d'expédition. « Où est mon lien de suivi ? » est le même problème sous une autre forme : c'est un e-mail de statut (le modèle shipped) que le client a perdu. La logique de renvoi est identique.
• Confirmations après modification d'une commande. Si vous avez modifié les lignes, le prix ou l'adresse après la commande du client, la confirmation originale est désormais incorrecte — renvoyer l'ancienne est pire qu'inutile. Émettez à nouveau la confirmation corrigée uniquement une fois la modification finalisée ; les mécanismes de modification d'une commande existante sont expliqués dans la modification de commande : corriger les erreurs après validation par le client.

Ne gonflez pas vos chiffres — nettoyez d'abord les commandes de test

Une remarque opérationnelle qui rattrape souvent les boutiques lorsqu'elles créent ou testent des fonctionnalités d'e-mail : il est facile de se spammer soi-même avec des renvois pendant que l'on ajuste les modèles, et tout aussi facile de laisser derrière soi une pile de fausses commandes. Si vous avez fait vos tests sur une boutique en production ou presque en production, supprimez les données factices avant qu'elles ne faussent vos compteurs de commandes et ne déclenchent des e-mails indésirables — consultez la suppression des commandes de test avant la mise en ligne.

Questions fréquentes

Pourquoi ne puis-je pas simplement renvoyer la confirmation de commande originale depuis la page de commande dans PrestaShop standard ? Parce que la confirmation (le modèle order_conf) est générée une seule fois pendant la validation de la commande, et non comme un e-mail ordinaire lié à un état de commande. La liste déroulante Statut ne redéclenche que les e-mails associés à un état de commande — le seul moyen natif de « renvoyer » consiste donc à changer le statut, ce qui écrit une nouvelle ligne d'historique et peut déclencher des effets secondaires. Un renvoi propre de la confirmation originale, sans effet secondaire, nécessite une logique personnalisée ou un module.

Renvoyer un e-mail va-t-il facturer le client une nouvelle fois ou modifier la commande ? Non. L'envoi d'un e-mail ne touche jamais au paiement, au stock ni aux totaux — il ne fait que renvoyer un message. Le risque qui inquiète les gens vient du contournement consistant à changer le statut pour déclencher l'e-mail, pas de l'e-mail lui-même. Un renvoi dédié qui ne change pas le statut laisse la commande totalement intacte.

Mes confirmations continuent d'arriver en spam même après renvoi. Que faire ? Un renvoi ne corrige pas un problème d'expéditeur — le second exemplaire est filtré de la même manière que le premier. Vérifiez Paramètres avancés → E-mail : si vous utilisez PHP mail(), passez à un SMTP authentifié, envoyez l'e-mail de test depuis cet écran, puis confirmez que SPF et DKIM sont publiés pour votre domaine. Corrigez d'abord l'expéditeur, puis renvoyez.

Un invité a commandé avec une adresse e-mail mal saisie — peut-il recevoir la confirmation ? Pas en libre-service, puisqu'il n'a pas de compte auquel se connecter. C'est exactement le cas où un renvoi depuis le back-office est utile : corrigez l'e-mail sur la commande si votre version le permet, puis renvoyez la confirmation à l'adresse corrigée.

Le module fonctionne-t-il avec ma version de PrestaShop ? Le contrôle de renvoi se greffe sur la page de détail de commande et sur le même chemin d'e-mail que PrestaShop utilise déjà. Il fonctionne donc sur les branches 1.6, 1.7, 8 et 9 que nous prenons en charge — le mécanisme sous-jacent OrderHistory/mail est resté compatible.

À retenir

« Renvoyez-moi ma confirmation » est une toute petite demande qui révèle la façon dont une boutique traite ses clients. Mal gérée, elle devient une corvée manuelle de cinq minutes et donne au client l'impression que vous n'étiez pas prêt pour un problème pourtant évident. Bien gérée, elle devient invisible : l'expéditeur est configuré pour que moins d'e-mails se perdent, le renvoi depuis le back-office se fait en un clic propre qui ne désorganise pas l'historique de commande, et le client peut généralement retrouver sa commande lui-même puis se renvoyer la confirmation sans jamais écrire au support. Rien de tout cela n'est une prouesse technique révolutionnaire — c'est simplement ce type de détail discret et abouti qui rend une boutique fiable, et dont les clients se souviennent la prochaine fois qu'ils choisissent où acheter.