📧 E-mailsDébutant PS 1.6 PS 1.7 PS 8.x

Désactiver l'email de confirmation de commande depuis le back-office PrestaShop

Comment empêcher l'envoi automatique d'emails de confirmation lors de la création ou modification de commandes dans le back-office PrestaShop 1.7 et 8.x.

En bref : Pour empêcher l'envoi d'emails de confirmation depuis le back-office PrestaShop, créez un statut de commande personnalisé avec l'option d'envoi d'email désactivée, ou utilisez le hook actionEmailSendBefore pour un contrôle conditionnel selon le contexte (BO vs front-office).

Publié le 21 mars 2026 5 min de lecture Alexandre Carette

Problématique : des emails envoyés sans contrôle depuis le back-office

Lorsqu'un marchand crée ou modifie une commande manuellement depuis le back-office PrestaShop, un email de confirmation est automatiquement envoyé au client. Dans certains contextes — commandes tests, commandes internes, ajustements manuels — cet envoi est indésirable et peut générer de la confusion côté client.

PrestaShop déclenche l'envoi d'emails à deux moments distincts lors de la gestion des commandes en back-office. Comprendre cette mécanique permet de désactiver précisément les notifications souhaitées.

Les deux sources d'emails lors de la création de commande en BO

1. L'email de récupération de panier (ajaxProcessSendMailValidateOrder)

Lorsqu'un administrateur crée une commande depuis le back-office, PrestaShop peut envoyer un email de type "backoffice_order" via la méthode ajaxProcessSendMailValidateOrder() du contrôleur AdminOrdersController.

Cet email contient un lien de récupération de panier et est déclenché avant même la validation du paiement. En PrestaShop 1.6 et 1.7, le code responsable se trouve dans :


// controllers/admin/AdminOrdersController.php
public function ajaxProcessSendMailValidateOrder()
{
    if ($this->tabAccess['edit'] === '1') {
        $cart = new Cart((int) Tools::getValue('id_cart'));
        if (Validate::isLoadedObject($cart)) {
            $customer = new Customer((int) $cart->id_customer);
            if (Validate::isLoadedObject($customer)) {
                $mailVars = array(
                    '{order_link}' => Context::getContext()->link->getPageLink(
                        'order', false, (int) $cart->id_lang,
                        'step=3&recover_cart=' . (int) $cart->id . '&token_cart=' . md5(_COOKIE_KEY_ . 'recover_cart_' . (int) $cart->id)
                    ),
                    '{firstname}' => $customer->firstname,
                    '{lastname}'  => $customer->lastname,
                );
                Mail::Send(
                    (int) $cart->id_lang,
                    'backoffice_order',
                    Mail::l('Process the payment of your order'),
                    $mailVars,
                    $customer->email,
                    $customer->firstname . ' ' . $customer->lastname
                );
            }
        }
    }
}

Pour désactiver cet envoi spécifique, vous pouvez créer un override de ce contrôleur :


// override/controllers/admin/AdminOrdersController.php
class AdminOrdersController extends AdminOrdersControllerCore
{
    public function ajaxProcessSendMailValidateOrder()
    {
        // Email de récupération de panier désactivé
        // pour les commandes créées depuis le back-office
        return;
    }
}

PrestaShop 8.x : Ce contrôleur a été migré vers Symfony. L'équivalent se gère désormais via les services du namespace PrestaShopBundle\Controller\Admin\Sell\Order. L'approche par override reste fonctionnelle sur les versions 1.6 et 1.7.

2. L'email de changement de statut (la solution recommandée)

Le second — et principal — déclencheur d'emails est le changement de statut de commande. C'est la source la plus fréquente d'emails indésirables et aussi la plus simple à maîtriser.

Chaque statut de commande dans PrestaShop dispose d'une option dédiée qui contrôle l'envoi d'email au client lors du passage à ce statut.

Solution recommandée : créer un statut silencieux

La méthode la plus propre et la plus maintenable consiste à créer un statut de commande personnalisé qui n'envoie aucun email.

Étape 1 : Accéder à la gestion des statuts

Rendez-vous dans Commandes > Statuts depuis le menu du back-office.

Étape 2 : Créer un nouveau statut

Cliquez sur Ajouter un statut de commande et configurez-le ainsi :

  • **Nom du statut** : « En attente de traitement interne » (ou tout libellé adapté à votre workflow)
  • **Couleur** : choisissez une couleur distincte pour le repérer facilement
  • **Envoyer un email au client** : **Décoché** — c'est le réglage clé
  • **Template d'email** : laissez vide
  • **Marquer la commande comme validée** : selon votre besoin
  • **Marquer la commande comme payée** : selon votre besoin

Étape 3 : Utiliser ce statut lors de la création manuelle

Lorsque vous créez une commande depuis le back-office, sélectionnez ce nouveau statut dans le champ « Statut de la commande » au lieu de « Paiement accepté » ou tout autre statut standard.

Le client ne recevra aucune notification. Vous pourrez basculer vers un statut avec notification ultérieurement, quand la commande sera prête à être communiquée.

Étape 4 : Modifier un statut existant (alternative)

Si vous souhaitez désactiver l'email sur un statut déjà existant plutôt que d'en créer un nouveau :

  1. Allez dans **Commandes > Statuts**
  2. Cliquez sur **Modifier** à côté du statut concerné
  3. Décochez **« Envoyer un email au client lorsque le statut de sa commande change »**
  4. Sauvegardez
  5. Attention : modifier un statut standard comme « Paiement accepté » affectera toutes les commandes, y compris celles passées par les clients en front-office. Privilégiez la création d'un statut dédié.

    Approche avancée : désactiver les emails par module

    Pour un contrôle encore plus fin, vous pouvez développer un module qui intercepte l'envoi d'emails via le hook actionEmailSendBefore (disponible depuis PrestaShop 1.7.6) :

    
    public function hookActionEmailSendBefore($params)
    {
        // Bloquer les emails de type 'order_conf' si la commande
        // provient du back-office
        if ($params['template'] === 'order_conf') {
            if ($this->isBackOfficeContext()) {
                return false; // Bloque l'envoi
            }
        }
        return true;
    }
    
    private function isBackOfficeContext()
    {
        return defined('_PS_ADMIN_DIR_')
            || (isset($_SERVER['SCRIPT_NAME'])
                && strpos($_SERVER['SCRIPT_NAME'], 'admin') !== false);
    }
    

    Cette approche est idéale si vous souhaitez bloquer l'email uniquement pour les commandes créées en back-office tout en conservant l'envoi pour les commandes front-office.

    Récapitulatif des templates d'emails concernés

    TemplateDéclencheurFichier `order_conf`Validation de commande`mails/{lang}/order_conf.html` `backoffice_order`Création BO (récupération panier)`mails/{lang}/backoffice_order.html` `order_changed`Changement de statut`mails/{lang}/order_changed.html`

    Bonnes pratiques

    • **Ne supprimez jamais les templates d'emails** : désactivez l'envoi via les statuts ou les hooks
    • **Documentez vos statuts personnalisés** : votre équipe doit savoir quel statut envoie quoi
    • **Testez en preprod** : vérifiez toujours le comportement des emails sur un environnement de test avant d'appliquer en production
    • **Pensez au multilingue** : si vous avez plusieurs langues, vérifiez que la désactivation fonctionne pour toutes les langues configurées
#email #commandes #back-office #statuts #configuration

Questions fréquentes

Tout ce que vous devez savoir sur ce sujet.

Un projet PrestaShop ?

Discutons-en directement.

★★★★★

193 projets livrés

Gratuit & sans engagement — réponse sous 24h

Alexandre Carette

Alexandre Carette

Expert PrestaShop & Architecture E-commerce

Développeur PrestaShop depuis 2014, 193 projets livrés. Je conçois des architectures headless Nuxt + PrestaShop et des outils d'automatisation IA pour les e-commerçants.