Supprimer les commandes de test : nettoyer votre PrestaShop avant la mise en ligne

Dernière mise à jour : juin 2026 — l’absence d’action native de suppression des commandes et la réinitialisation du compteur de factures ont été vérifiées sur PrestaShop 1.7, 8 et 9.

La veille du lancement, votre base de données PrestaShop ressemble à une scène de crime que vous avez vous-même organisée. Vous avez passé des commandes pour tester les tarifs des transporteurs, fait passer deux fois une carte dans la passerelle de paiement pour être sûr, créé "asdf asdf" pour vérifier le formulaire d’adresse, et déclenché tous les statuts de commande pour voir partir les e-mails. Tout a fonctionné — et c’est précisément le problème. Chacune de ces commandes de test est désormais intégrée à vos statistiques, à votre séquence de facturation et à votre liste de clients ; le premier matin de vraies ventes, elle vous donnera discrètement une image fausse de l’activité de la boutique. Ce guide traite d’une tâche bien précise : supprimer proprement les commandes de test avant la mise en ligne, sur une boutique qui n’a encore jamais reçu de vraie commande — car dès que de véritables commandes et factures existent, PrestaShop rend volontairement leur suppression difficile, pour des raisons juridiques et comptables.

Le périmètre est volontairement limité. Nettoyer les paniers, les journaux et les tables de connexion pour maintenir les performances au fil du temps relève d’une autre routine — la différence entre "je lance la semaine prochaine" et "ma base de données grossit depuis deux ans" — et nous séparons les deux pour que vous ne supprimiez que ce qu’un lancement exige réellement.

Pourquoi une commande de test oubliée coûte plus cher qu’il n’y paraît

Supprimer une commande peut sembler purement cosmétique. Ce ne l’est pas. Dans PrestaShop, une commande n’est pas une seule ligne : c’est un petit graphe de lignes réparties dans une douzaine de tables, dont plusieurs alimentent les rapports et les compteurs sur lesquels vous vous appuierez dès le premier jour. Laissez-les en place, et voici ce qui casse concrètement :

• Votre premier chiffre d’affaires est faux, et vous ne pouvez pas le savoir. Le tableau de bord et les pages Statistiques additionnent ps_orders (et ps_order_detail) sans savoir quelles lignes correspondent à vos essais de tarifs transporteur. Le chiffre d’affaires du premier jour, le panier moyen et le taux de conversion sont tous gonflés par des commandes qui n’ont jamais existé, si bien que le moment où vous avez le plus besoin d’un signal propre — "la nouvelle boutique vend-elle vraiment ?" — est celui où vos données sont les plus sales.
• Votre première vraie facture porte le numéro #38. Dans PrestaShop, les numéros de facture proviennent d’un compteur continu, pas de la commande. Quarante commandes de test ayant généré des factures consomment quarante numéros ; la première vraie facture de votre comptable se retrouve donc avec un numéro non séquentiel au milieu de la trentaine, précédé de trente-sept factures invisibles. C’est exactement le type d’écart qui attire les questions lors d’un contrôle fiscal.
• Votre liste de clients est parsemée de fantômes. "Test User", "asdf asdf" et vos trois comptes jetables restent dans ps_customer à côté de vraies personnes. Chaque segment, export et statistique sur le "nombre de clients" les comptabilise. Exportez cette liste vers un outil d’e-mailing et les adresses de test — si vous en avez utilisé de réelles — recevront vos campagnes marketing.
• Le stock a bougé pour des ventes qui n’ont jamais eu lieu. Si vos commandes de test portaient sur de vrais produits avec la gestion des stocks activée, chacune a écrit une ligne dans ps_stock_mvt et décrémenté la quantité. Supprimez mal la commande, et le mouvement de stock reste en place : votre inventaire du jour de lancement est alors discrètement faux. (Le rapprochement de ces données est un chantier stock à part entière — voir la gestion des stocks quand les tableurs ne suffisent plus.)

Et alors ? Une commande de test que vous oubliez de supprimer n’encombre pas seulement un écran : elle corrompt les trois choses qu’un lancement doit vous fournir, à savoir un chiffre d’affaires honnête, une séquence de factures propre et une liste de clients fiable. Les retirer prend quinze minutes et vous offre une base de données que vous pouvez réellement lire.

Il n’existe pas de bouton "supprimer la commande" propre — et ce n’est pas anodin

Première surprise : PrestaShop natif (1.7, 8, 9) ne propose pas d’action normale dans le back-office pour supprimer une commande. Les commandes sont traitées comme des documents financiers et doivent être conservées pour préserver l’intégrité juridique et comptable ; les actions groupées et les menus de ligne vers lesquels vous vous tournerez ne proposent donc tout simplement pas de "Supprimer" comme le font les listes de produits ou de clients. C’est intentionnel, pas un oubli.

C’est exactement pourquoi la seule manière sûre de supprimer des commandes de test consiste à le faire avant l’existence de toute vraie commande. Vos options réalistes sont les suivantes :

• Restaurer une sauvegarde propre d’avant lancement. La réinitialisation la plus simple et la plus sûre : reprenez l’instantané effectué avant vos tests et revenez à cet état. Tout ce qui suit suppose que vous préférez ne pas le faire, mais c’est l’option qui ne présente aucun risque de lignes orphelines.
• Travailler sur une base de préproduction. Testez sur une copie, puis déployez une base de production propre qui n’a jamais vu passer de commande de test.
• Utiliser un module ou un script dédié au nettoyage des commandes. Supprimer correctement une commande signifie parcourir tout le graphe des lignes liées ; c’est pourquoi cette opération doit être confiée à un outil testé par version, pas à une action admin cliquée à la main. Ne l’exécutez que sur une boutique sans aucune vraie commande.

Et même lorsqu’une commande est supprimée (par un module ou par la logique objet Order::delete() de PrestaShop), tout ce qui gravite autour d’elle à un niveau de distance n’est jamais nettoyé :

• Le client (ps_customer) et ses adresses (ps_address) — supprimer une commande ne supprime jamais la personne qui l’a passée. Vos faux clients survivent.
• Le panier d’origine (ps_cart, ps_cart_product) — le panier devenu commande reste derrière comme panier "abandonné".
• La ligne de facture (ps_order_invoice) et le compteur de numéros de facture — supprimer la commande ne remet pas en arrière le numéro qu’elle a consommé.
• Tout mouvement de stock (ps_stock_mvt) déjà écrit sur de vrais produits.

La suppression des commandes n’est donc que la première étape, pas tout le travail. Le schéma qui vous laisse réellement une base propre est le suivant : supprimer les commandes sur une boutique d’avant lancement, puis supprimer leurs clients et leurs paniers, puis définir explicitement le prochain numéro de facture. Voici comment procéder pour chaque partie de manière déterministe.

Le nettoyage avant lancement, étape par étape

1. Sauvegardez d’abord la base de données — ce n’est pas négociable. Faites un vrai dump de base de données : l’outil de sauvegarde de votre hébergeur, phpMyAdmin ou Adminer, ou un mysqldump si vous disposez d’un accès shell. (Remarque : SQL Manager, dans Paramètres avancés, sert à exécuter des requêtes enregistrées sur vos données, pas à réaliser une sauvegarde complète — ne comptez pas dessus pour cela.) La suppression de commandes est destructive et il n’existe pas d’annulation. Si quoi que ce soit ci-dessous vous surprend, vous restaurez et vous recommencez.
2. Établissez une liste définitive des ID de commandes de test. Dans Commandes → Commandes, triez par date et identifiez chaque commande passée avant le lancement. Notez la plage d’ID : il s’agit presque toujours d’un bloc continu au début (de 1 à une valeur donnée). Le piège ici est le lancement progressif : si vous avez reçu de vraies premières commandes, leurs ID sont mélangés aux tests. Listez explicitement les vraies commandes afin de ne jamais supprimer un client payant.
3. Supprimez les commandes. Comme PrestaShop natif ne propose pas d’action de suppression de commande dans le back-office, cette étape nécessite un module de nettoyage dédié ou un petit script appelant Order::delete() sur chaque ID de test — ou, plus simplement encore, la restauration de votre sauvegarde propre d’avant lancement. Ne le faites que sur une boutique sans aucune vraie commande.
4. Supprimez les clients de test. Allez dans Clients → Clients, trouvez les comptes manifestement fictifs et supprimez-les — cela supprime aussi leurs adresses. Là encore, surveillez les acheteurs d’un lancement progressif que vous souhaitez conserver.
5. Définissez explicitement le prochain numéro de facture à 1. Allez dans Commandes → Factures, puis dans Options des factures, définissez Prochain numéro de facture disponible sur 1 — uniquement sur une boutique où aucune facture réelle n’a jamais été émise, et après avoir vérifié qu’aucune séquence légale de facturation n’a déjà commencé. (Cela définit directement le numéro de départ ; ne vous attendez pas à ce qu’une valeur 0 "démarre automatiquement à 1".) Faites de même pour la numérotation des bons de livraison si vous avez testé les livraisons (Commandes → Bons de livraison). C’est l’étape que presque tout le monde oublie, et c’est celle que votre comptable remarque — mais si de vraies factures existent déjà, laissez la séquence intacte et consultez plutôt vos obligations comptables.
6. Videz le cache. Paramètres avancés → Performances → Vider le cache. Les compteurs et les vues de liste sont mis en cache ; sans cela, l’administration peut encore afficher d’anciens totaux.
7. Vérifiez les chiffres, pas votre mémoire. Ouvrez Commandes → Commandes (la liste doit être vide ou ne contenir que les vraies commandes d’un lancement progressif), Clients et le tableau de bord. Si le chiffre d’affaires n’est pas à zéro (ou ne correspond pas à votre véritable montant de lancement progressif), quelque chose n’a pas été supprimé — revenez à votre sauvegarde et à votre liste avant de lancer avec des données sales.

Quand vous avez des dizaines de commandes de test : la piste SQL

Cliquer dans cinquante commandes une par une est fastidieux et source d’erreurs. Si vous êtes à l’aise dans Paramètres avancés → Base de données → SQL Manager (ce qui convient pour des requêtes d’analyse en lecture seule), vous pouvez au moins délimiter précisément les données de test — mais, comme l’explique la section suivante, la suppression elle-même doit passer par du code testé, pas par un DELETE écrit à la main. La raison tient au schéma de PrestaShop : beaucoup de tables n’ont pas de clés étrangères en cascade ; supprimer d’abord le parent rend donc les enfants orphelins au lieu de les supprimer, et il est facile de sous-estimer l’ensemble complet des tables liées.

Commencez par trouver les commandes de test afin de travailler à partir de vrais ID, pas d’hypothèses. Par exemple, tout ce qui a été passé avant votre date de lancement :

SELECT id_order, reference, total_paid, date_add FROM ps_orders WHERE date_add < '2026-06-13 00:00:00' ORDER BY id_order;

Privilégiez fortement la logique Order::delete() propre à PrestaShop pour gérer les lignes enfants (exécutez-la depuis un petit script sur vos ID de test), plutôt qu’une suppression écrite à la main. Une vraie commande PrestaShop touche bien plus que la demi-douzaine de tables évidentes : détails et historique de commande, mais aussi transporteurs de commande, messages, retours et avoirs, personnalisations, factures, taxes, ainsi que les lignes ps_order_payment associées par référence de commande plutôt que par un lien enfant propre sur id_order — sans compter les tables propres aux modules ajoutées par votre installation. C’est précisément ce qui rend dangereuse une liste de DELETE écrite à la main : toute table oubliée devient un orphelin invisible.

Ce guide ne vous donne donc volontairement pas une recette SQL partielle du type "supprimez ces N tables dans cet ordre" — cette recette serait incomplète pour presque n’importe quelle vraie boutique. Utilisez la logique objet (Order::delete()) ou un script de nettoyage testé par version qui énumère chaque table liée, y compris les lignes de paiement qu’il doit retrouver par référence. Ensuite seulement, nettoyez séparément les satellites : clients, paniers, compteur de factures.

Et alors ? Oublier une table liée n’est pas un détail de puriste : si vous vous trompez, vous laissez des lignes orphelines invisibles qui continuent à polluer les rapports tout en donnant l’impression que la suppression a bien eu lieu dans l’administration. C’est précisément le mode d’échec que toute cette opération cherche à éviter, et c’est pourquoi nous nous appuyons sur du code testé plutôt que sur un bloc SQL à copier-coller.

Une réserve honnête : tronquer les tables de commandes (TRUNCATE ps_orders et les tables associées) est l’option brutale que vous verrez conseillée en ligne. C’est rapide et cela réinitialise les ID auto-incrémentés à 1 — séduisant pour un lancement — mais cela contourne toutes les protections, ne touche pas aux tables satellites et détruira sans hésiter une commande de lancement progressif. Ne l’envisagez que sur une boutique sans aucune donnée réelle, et uniquement avec une sauvegarde dont vous avez confirmé la restauration.

Nettoyer aussi les données de démonstration pendant que vous y êtes

Les commandes de test bloquent le lancement, mais si vous avez installé PrestaShop avec les données de démonstration, le catalogue d’exemple est lui aussi un problème d’avant lancement — et mérite d’être traité dans la même session. Lorsqu’il est installé avec les données de démonstration, PrestaShop peut inclure des produits, catégories, fournisseurs, marques et pages CMS d’exemple (les pages de remplacement "Livraison", "Mentions légales", "À propos de nous") — les éléments exacts varient selon la version, la distribution et la langue. Les laisser en place expose à deux risques : qu’un vrai produit se retrouve accidentellement dans une catégorie de démonstration, et que Google indexe une page "Conditions générales" encore remplie de Lorem ipsum.

Supprimez ou réécrivez, dans Catalogue et Apparence → Pages : les produits et catégories de démonstration, ainsi que les pages CMS de remplacement (remplacez-les par vos vrais textes légaux, ne vous contentez pas de les masquer). Faites-le via le back-office ou un processus d’import contrôlé — ne supprimez pas des fichiers à la main dans /img, qui contient les images de vos produits, catégories, marques, fournisseurs, thèmes et du système en production, pas seulement celles de démonstration. Supprimer les produits de démonstration via le BO efface leurs enregistrements d’images de manière sûre ; si vous souhaitez ensuite récupérer de l’espace disque, régénérez ou purgez les images inutilisées uniquement avec une sauvegarde sous la main. Si vous partez d’un gros catalogue de démonstration et importez votre vrai catalogue, le faire proprement via CSV est une tâche à part entière — voir l’import et l’export de produits dans PrestaShop.

Prévention : éviter de recréer le problème la prochaine fois

Vous testerez à nouveau — à chaque changement de thème, mise à jour de module de paiement et montée de version PrestaShop. L’objectif est que les futurs tests ne laissent aucun résidu dans vos données réelles :

• Testez sur une copie de préproduction, pas sur la boutique en ligne. Une installation dupliquée où chaque commande de test, remboursement et changement de statut se produit à l’écart. C’est le gain le plus important : votre ps_orders de production ne contient jamais que de vraies ventes, il n’y a donc rien à nettoyer.
• Utilisez le mode sandbox pour les paiements. Stripe, PayPal et la plupart des passerelles proposent une clé de test/sandbox qui traite de fausses transactions sans aucun débit réel. Testez le tunnel de commande sans jamais toucher à une vraie carte — et pensez à repasser chaque passerelle en mode réel avant le lancement (une clé sandbox oubliée est le bug de lancement inverse).
• Balisez le test en production inévitable. Si vous devez tester en production, utilisez un marqueur reconnaissable — un client nommé ZZ-TEST, un motif d’e-mail dédié, une note dans la commande — afin qu’un seul filtre triable fasse ressortir toutes les lignes de test à supprimer. L’intérêt de commandes de test clairement marquées rejoint la façon dont vous gérez les statuts de commande en général ; si vous testez souvent les e-mails de statut, l’automatisation de ces transitions est traitée dans la personnalisation et l’automatisation des workflows de statut de commande.

Questions fréquentes

Comment supprimer une commande de test dans PrestaShop ?

PrestaShop natif (1.7, 8, 9) ne propose aucune action "Supprimer la commande" dans le back-office : les commandes sont traitées comme des documents financiers et conservées par conception. La seule façon sûre de supprimer des commandes de test consiste à le faire avant l’existence de toute vraie commande : restaurer une sauvegarde propre d’avant lancement, déployer une base de préproduction qui n’a jamais reçu de commande de test, ou exécuter un module/script de nettoyage testé par version qui appelle Order::delete() sur vos ID de test. Sauvegardez d’abord la base de données ; la suppression de commandes est destructive et il n’y a pas d’annulation.

Pourquoi ma première vraie facture commence-t-elle au numéro 38 au lieu de 1 ?

Les numéros de facture proviennent d’un compteur continu, pas de la commande ; chaque commande de test ayant généré une facture a donc consommé un numéro. Après avoir supprimé les tests, allez dans Commandes → Factures → Options des factures et définissez Prochain numéro de facture disponible sur 1 — mais uniquement sur une boutique où aucune facture réelle n’a jamais été émise. Le définir sur 0 ne "démarre pas automatiquement à 1" ; indiquez directement le numéro de départ. Si de vraies factures existent déjà, laissez la séquence intacte.

Supprimer une commande supprime-t-il aussi le client et le panier ?

Non. Supprimer une commande ne supprime jamais la personne qui l’a passée (ps_customer) ni ses adresses (ps_address), et le panier devenu commande reste derrière comme panier "abandonné" (ps_cart). Cela ne remet pas non plus en arrière le compteur de numéros de facture ni les mouvements de stock déjà écrits. La suppression de la commande est donc la première étape, pas tout le travail : vous devez ensuite supprimer séparément les clients et paniers de test, puis réinitialiser le compteur.

Puis-je simplement lancer une requête DELETE ou TRUNCATE sur les tables de commandes ?

Évitez. Une vraie commande touche bien plus que la demi-douzaine de tables évidentes : détails et historique de commande, transporteurs, messages, retours, avoirs, personnalisations, factures, taxes, ainsi que les lignes ps_order_payment liées par référence de commande plutôt que par id_order — sans compter les tables propres aux modules. Un DELETE écrit à la main qui en oublie une laisse des lignes orphelines invisibles qui continuent à polluer les rapports tout en semblant supprimées. TRUNCATE est plus rapide et réinitialise les ID à 1, mais contourne toutes les protections et détruira une commande de lancement progressif. Utilisez plutôt Order::delete() ou un script de nettoyage testé. Un SELECT en lecture seule pour trouver d’abord les ID de test ne pose pas de problème.

Comment éviter de recréer ce désordre la prochaine fois ?

Testez sur une copie de préproduction, pas sur la boutique en ligne : ainsi, votre ps_orders de production ne contient jamais que de vraies ventes. Utilisez le mode sandbox/test de chaque passerelle pour tester les paiements (et pensez à repasser chaque passerelle en mode réel avant le lancement). Si vous devez tester en production, balisez les commandes avec un marqueur reconnaissable (un nom de client ZZ-TEST ou un motif d’e-mail dédié) afin qu’un seul filtre triable fasse ressortir toutes les lignes de test à supprimer.

Où cela s’inscrit dans l’ensemble

Supprimer les commandes de test est une étape unique de lancement. Les habitudes qui gardent une base de commandes propre et fiable après le lancement relèvent d’une discipline distincte et continue : corriger la commande réelle occasionnelle partie avec une erreur grâce à l’édition de commandes, renvoyer une confirmation à un client qui a perdu la sienne avec le renvoi des confirmations de commande, extraire des chiffres propres pour votre comptable avec les exports CSV de commandes et de factures, et assurer le quotidien qui fait tourner tout cela avec les workflows de gestion des commandes qui vous font gagner des heures.

Le principe du jour de lancement est simple : les seules commandes dans votre base de données doivent être celles qu’un client a réellement passées. Sortez les commandes de test — dans le bon ordre, avec le compteur de factures réinitialisé et la sauvegarde mise de côté en sécurité — et le premier chiffre d’affaires de votre boutique dira la vérité. Ensuite, chaque rapport propre que vous lirez sera une petite récompense pour les quinze minutes passées maintenant. Si une base de données bien tenue et des statistiques exactes comptent dans votre façon de gérer la boutique, c’est précisément le type de fiabilité en arrière-plan que nos modules PrestaShop sont conçus pour protéger.