Vous ouvrez le panneau d’administration de WooCommerce et vous voyez trois mille produits, dont la moitié sont des doublons issus d’un import raté, avec des attributs comme «Color 1», «Color 2», «Size_copy_2023». L’interface «Produits → tout sélectionner → Supprimer» expire après les deux premières centaines. Cela vous rappelle quelque chose? Le nettoyage massif du catalogue est une tâche à laquelle tout le monde est confronté lors de la migration d’une boutique, de la fusion d’une base de staging avec la production ou de la remise en ligne d’une vitrine après un rebranding.

Le problème tient à la structure même de WooCommerce: les produits sont répartis sur quatre tables (wp_posts, wp_postmeta, wp_term_relationships et wp_term_taxonomy), et les attributs sont stockés dans trois autres. Vous ne pouvez pas simplement cliquer sur «Tout supprimer»; le moteur plantera avant d’atteindre la fin de la liste. Vous avez besoin d’un outil qui contourne l’interface et attaque directement la base de données, ou qui passe par la ligne de commande.

Voici trois méthodes qui fonctionnent, du SQL radical aux extensions sécurisées. Avec une sauvegarde, une vérification du préfixe et une bonne compréhension de ce qui se passe exactement dans chaque table.

💡 Aperçu rapide:

• Faites un dump complet de la base de données; DELETE est irréversible, il n’y a pas de corbeille
• Vérifiez le préfixe des tables dans wp-config.php et remplacez wp_ par celui-ci
• Exécutez les commandes SQL en cascade: attributs → produits → postmeta orphelines
• Si vous avez un accès SSH, WP-CLI règle tout en une seule commande et déclenche les hooks nécessaires
• Pour une boutique en production sans expérience SQL, les extensions avec un bouton «Supprimer» sont plus sûres

Précautions: sauvegarde et préfixe

Toute commande SQL qui modifie le contenu des tables de WordPress est irréversible. DELETE ne demande pas de confirmation, n’envoie pas l’enregistrement dans la corbeille; la ligne disparaît instantanément et définitivement. Règle numéro un: faites une sauvegarde complète de la base de données avant d’exécuter l’une des requêtes ci-dessous.

L’approche la plus fiable consiste à exporter un dump via phpMyAdmin: onglet «Exporter» → format SQL → compresser avec gzip. Ou via votre panneau d’hébergement (cPanel → Sauvegarde → Base de données). Pour ceux qui travaillent en ligne de commande:

1
mysqldump -u username -p database_name > backup_$(date +%Y%m%d).sql

Deuxième point: toutes les requêtes ci-dessous utilisent le préfixe standard wp_. Si vous avez changé le préfixe lors de l’installation de WordPress pour wpx_, store_ ou autre chose, remplacez wp_ dans chaque commande par le vôtre. Le préfixe réel se trouve dans wp-config.php, à la ligne $table_prefix. Vous avez vérifié? Passons à la suite.

Méthode 1: commandes SQL dans phpMyAdmin, contrôle total

La méthode la plus rapide et la plus radicale. Idéale lorsque vous devez effacer des centaines ou des milliers d’enregistrements en une seule passe et que l’interface standard de WooCommerce expire. Toutes les requêtes s’exécutent dans phpMyAdmin, dans l’onglet «SQL», une par une, dans un ordre strict.

Supprimer les attributs WooCommerce

Les attributs vivent dans trois tables à la fois: wp_terms, wp_term_taxonomy et wp_term_relationships. Ils se distinguent des catégories et étiquettes classiques par le préfixe pa_ dans le champ taxonomy, abréviation de «product attribute». Vous devez les supprimer en cascade, en commençant par les termes et en terminant par les relations:

1
DELETE FROM wp_terms WHERE term_id IN
2
(SELECT term_id FROM wp_term_taxonomy WHERE taxonomy LIKE 'pa_%');
3
 
4
DELETE FROM wp_term_taxonomy WHERE taxonomy LIKE 'pa_%';
5
 
6
DELETE FROM wp_term_relationships WHERE term_taxonomy_id NOT IN
7
(SELECT term_taxonomy_id FROM wp_term_taxonomy);

La première requête supprime les noms d’attributs de wp_terms. La deuxième retire leurs enregistrements de taxonomie de wp_term_taxonomy. La troisième nettoie les relations «terme-objet» orphelines dans wp_term_relationships qui se retrouvent sans taxonomie parente. L’ordre est important: si vous supprimez la taxonomie avant les termes, la troisième requête en attrapera trop.

Supprimer les produits WooCommerce

Les produits et leurs variations sont des enregistrements de type product et product_variation dans la table wp_posts. Mais effacer simplement les lignes de wp_posts ne suffit pas: les métadonnées resteront dans wp_postmeta (prix, SKU, paramètres de livraison) et les relations de termes resteront dans wp_term_relationships (catégories, étiquettes). Trois requêtes, en cascade:

1
DELETE FROM wp_term_relationships WHERE object_id IN
2
(SELECT ID FROM wp_posts WHERE post_type IN ('product','product_variation'));
3
 
4
DELETE FROM wp_postmeta WHERE post_id IN
5
(SELECT ID FROM wp_posts WHERE post_type IN ('product','product_variation'));
6
 
7
DELETE FROM wp_posts WHERE post_type IN ('product','product_variation');

D’abord, nous cassons les relations du produit avec les taxonomies, puis nous supprimons les métadonnées, et seulement ensuite l’enregistrement du produit lui-même. Si vous inversez l’ordre et supprimez wp_posts en premier, les sous-requêtes SELECT ID FROM wp_posts des deuxième et troisième étapes renverront un ensemble vide, et les métadonnées et relations resteront comme poids mort dans la base de données.

Nettoyer les postmeta orphelines

Après toute opération de suppression via SQL, il est utile de vérifier si wp_postmeta contient des lignes qui référencent des articles inexistants. Cela arrive avec des transactions interrompues, des imports cassés, ou lorsque des articles ont été supprimés sans cascade:

1
DELETE pm
2
FROM wp_postmeta pm
3
LEFT JOIN wp_posts wp ON wp.ID = pm.post_id
4
WHERE wp.ID IS NULL;

La requête trouve toutes les lignes de wp_postmeta qui n’ont pas d’enregistrement parent dans wp_posts et les supprime. Elle est sans danger: elle ne touche pas aux données vivantes, seulement aux déchets.

Méthode 2: WP-CLI, rapide et sans phpMyAdmin

Si vous avez un accès SSH au serveur, WP-CLI gère la suppression massive de manière plus élégante que n’importe quelle requête SQL. Une seule commande, et WooCommerce parcourt lui-même les tables liées, sans laisser de données orphelines:

1
wp wc product delete $(wp wc product list --field=ID --per_page=-1) --force

Le flag --per_page=-1 exporte les identifiants de tous les produits sans pagination. --force ignore la corbeille et supprime définitivement. Si vous avez plus de 10 000 produits, il est préférable de fractionner en lots de 500 pour éviter de heurter les limites de mémoire:

1
wp wc product list --field=ID --per_page=500 --page=1 | xargs wp wc product delete --force

Pour supprimer des attributs via WP-CLI, utilisez:

1
wp wc product_attribute list --field=id --per_page=-1 | xargs -I{} wp wc product_attribute delete {} --force

L’avantage principal de WP-CLI par rapport au SQL brut est qu’il déclenche les hooks internes de WooCommerce, before_delete_post et after_delete_post. Cela donne aux plugins de cache et de recherche (Elasticsearch, Redis, Relevanssi) l’occasion de nettoyer leurs index. Les requêtes SQL ne le font pas; après leur exécution, la recherche peut continuer à renvoyer des produits déjà supprimés pendant un certain temps.

Méthode 3: les plugins, quand vous ne voulez pas toucher à la base de données

Pour ceux qui trouvent la ligne de commande et phpMyAdmin trop risqués, le marché propose des plugins spécialisés. Ils fonctionnent sur la base des mêmes requêtes SQL, mais les cachent derrière un bouton.

Delete All Products for WooCommerce est un plugin gratuit disponible sur le dépôt officiel WordPress.org. Il ajoute un simple bouton dans le panneau d’administration. Cliquez → choisissez «mettre à la corbeille» ou «définitivement» → confirmez. Un minimum d’étapes, zéro risque de faute de frappe SQL. L’inconvénient: il ne fonctionne qu’avec les produits, il ne touche pas aux attributs.

WooCommerce Store Toolkit (également connu sous le nom de Store Toolkit for WooCommerce) est une option plus sérieuse. Il nettoie non seulement les produits et les attributs, mais aussi les commandes, les coupons, les sessions et les transients, avec des filtres par date et par statut. Adapté à un grand nettoyage complet de la boutique avant une relance.

Quel que soit le plugin que vous choisissez, la règle de la sauvegarde reste valable. Un plugin exécute les mêmes requêtes DELETE; simplement, vous ne les voyez pas.

Comparaison des méthodes: que choisir et quand

Si vous avez un produit ou une douzaine, l’interface WooCommerce «Produits → sélectionner → Supprimer» fera l’affaire. Des centaines ou des milliers nécessitent SQL ou WP-CLI. Une boutique en production où il n’y a pas droit à l’erreur nécessite un plugin ou WP-CLI.

Limites importantes: ce qui n’est pas supprimé

La suppression en masse de produits et d’attributs via SQL ne touche pas aux fichiers médias. Les images de produits téléchargées dans la médiathèque WordPress (enregistrements avec post_type = 'attachment') restent en place, à la fois dans le système de fichiers et dans la base de données. Si vous reconstruisez le catalogue à partir de zéro et souhaitez libérer de l’espace sur votre hébergement, les fichiers médias doivent être nettoyés séparément: via «Médias → sélectionner → Supprimer définitivement» ou WP-CLI:

1
wp post delete $(wp post list --post_type=attachment --field=ID --per_page=-1) --force

Les commandes SQL ne mettent pas non plus à jour les compteurs WooCommerce (nombre de produits par catégorie) qui sont mis en cache dans wp_termmeta et wp_options sous forme de transients avec le préfixe _wc_term_counts_. Après une suppression en masse, le panneau d’administration peut temporairement afficher des nombres de produits par catégorie incorrects. Cela se corrige en relançant le comptage:

1
wp wc tool run recount_terms

Ou via l’extension Recount Terms du dépôt officiel.

La vidéo propose une démonstration pas à pas des commandes SQL pour supprimer les attributs WooCommerce dans phpMyAdmin: navigation dans les tables et vérification des résultats après chaque requête.

⁉️🤔 Foire aux questions

Est-il sûr de supprimer des produits via SQL sur une boutique en production?

Sur une boutique en production, utiliser du SQL brut pour une suppression en masse est une pratique risquée. Une simple faute de frappe dans un nom de table ou une clause WHERE peut affecter les commandes, les utilisateurs ou les réglages. Si la boutique est en ligne et génère du chiffre d’affaires, utilisez WP-CLI ou des extensions qui vous empêcheront de vous tirer une balle dans le pied. Réservez le SQL aux environnements de développement, à la préproduction et aux situations où l’interface d’administration ne parvient déjà plus à se charger.

Pourquoi les produits restent-ils visibles dans la recherche du site après une suppression SQL?

Les extensions de recherche (Relevanssi, Elasticsearch, SearchWP) maintiennent leur propre index, qui n’est pas mis à jour lorsque wp_posts est manipulé directement, en contournant l’API WordPress. Après un nettoyage via SQL, vous devez reconstruire l’index de recherche dans les paramètres de l’extension ou via WP-CLI: par exemple, wp relevanssi index --reindex.

Comment supprimer uniquement les produits d’une catégorie spécifique, et non la totalité?

Ajoutez un filtre par le term_taxonomy_id de la catégorie souhaitée. La démarche: récupérez le term_id de la catégorie → trouvez le term_taxonomy_id dans wp_term_taxonomy → filtrez object_id dans wp_term_relationships avant de supprimer dans wp_posts. En pratique, il est plus simple d’utiliser WP-CLI: wp wc product list --category=slug-kategorii --field=ID | xargs wp wc product delete --force.

Les produits peuvent-ils être restaurés après une suppression SQL?

Uniquement à partir d’une sauvegarde. Contrairement à la suppression via la corbeille WordPress (Mettre à la corbeille), la commande SQL DELETE efface les lignes physiquement et de manière irréversible. C’est précisément la raison pour laquelle la règle «sauvegarder d’abord» est répétée dans chaque section de cet article. Deux minutes consacrées à un dump vous feront gagner des heures de restauration.

Quelle est la différence entre supprimer des attributs et supprimer des variations?

Les variations sont un sous-type de produits (product_variation). Elles se suppriment avec les mêmes commandes SQL que les produits simples: la condition post_type IN ('product','product_variation') dans le deuxième bloc de la «Méthode 1» inclut déjà les variations. Les attributs (pa_color, pa_size) sont des taxonomies; ils se suppriment séparément, par le premier bloc de commandes SQL. L’ordre correct est le suivant: d’abord les produits (y compris les variations), puis les attributs. Si vous procédez dans l’ordre inverse, les variations perdront leurs liaisons d’attributs, mais les enregistrements de variation eux-mêmes resteront dans la base de données.

Quoi utiliser en 2026: l’essentiel

Les commandes SQL, WP-CLI et les extensions sont trois outils aux niveaux de risque variables pour une même tâche. Le choix se résume à une matrice simple:

• Vous avez un accès SSH et de l’expérience en ligne de commande → WP-CLI (wp wc product delete). Sûr, rapide, avec des hooks.
• Pas d’accès SSH mais vous disposez de phpMyAdmin et comprenez le schéma des tables → SQL. Contrôle total, résultats instantanés. Mais sauvegardez d’abord.
• Vous ne voulez aucun risque → Delete All Products ou Store Toolkit. Plus lent, mais un bouton à la place d’une requête SQL.

Dans tous les cas, une sauvegarde de la base de données est l’action numéro un. Ne commencez pas sans elle.

🔗 Delete All Products for WooCommerce, gratuit sur WordPress.org🔗 WooCommerce Store Toolkit, nettoyage avancé de boutique