# Dupliquer un produit variable par copier-coller en base plutôt que par l’API casse le stock

> Dupliquer un produit variable directement en SQL semble plus rapide qu'un appel à l'API WooCommerce. C'est aussi le meilleur moyen de casser les variations et le stock. Voici pourquoi, et la bonne méthode.

- Auteur : WordPress Développement
- Publié le : 2021-10-28
- Mis à jour le : 2021-10-28
- Catégorie : E-commerce
- URL : https://www.wpmoderne.fr/ecommerce/dupliquer-produit-variable-copier-coller-base-plutot-que-api/

## L’essentiel

- Un produit variable relie plusieurs tables liées par des identifiants qu'une copie SQL ne réindexe pas
- wc_get_product suivi d'une duplication native préserve ces relations
- Le stock par variation doit être régénéré, jamais copié tel quel

« On duplique juste la ligne dans `wp_posts` et ses métadonnées dans `wp_postmeta`, ça ira plus vite que de repasser par l'interface. » Cette phrase, entendue sur plus d'un projet de reprise, précède presque toujours un ticket de support signalant que la fiche produit dupliquée affiche un stock erroné, ou pire, que les variations de couleur ne correspondent plus aux bonnes images une fois la copie publiée.

Ce billet explique pourquoi dupliquer un produit variable directement en base de données casse les variations et le stock, et quelle méthode utiliser à la place, en s'appuyant sur `wc_get_product()` plutôt que sur des requêtes SQL manuelles.

## Ce qu'on voit sur le terrain

Le scénario typique : un développeur pressé exécute une requête `INSERT INTO wp_posts SELECT ... FROM wp_posts WHERE ID = X` pour copier un produit variable, puis fait de même pour `wp_postmeta` en changeant l'identifiant de post parent. Le nouveau produit apparaît bien dans le catalogue, avec son prix et sa description, mais les variations restent liées à l'ancien identifiant de produit parent, ou pire, plusieurs variations pointent encore vers le même identifiant de stock que l'original.

## Pourquoi c'est un problème

> L'essentiel à retenir : Un produit variable relie plusieurs tables liées par des identifiants qu'une copie SQL ne réindexe pas ; wc_get_product suivi d'une duplication native préserve ces relations ; Le stock par variation doit être régénéré, jamais copié tel quel

Un produit variable WooCommerce n'est jamais un post isolé. Le produit parent, chaque variation (elle-même un post de type `product_variation`), les entrées de la table des termes pour les attributs, et les métadonnées de stock par variation forment un ensemble de relations croisées par identifiants. Une copie SQL brute reproduit le contenu des colonnes, mais ne réindexe aucune de ces relations : les nouvelles variations continuent de désigner l'ancien produit comme parent tant qu'aucun script de correction n'a réécrit chaque référence.

- La table des posts pour le produit parent et chacune de ses variations
- La table des métadonnées de posts pour le prix, le stock et les attributs de chaque variation
- La table de taxonomie pour les attributs utilisés en tant que termes

## La bonne méthode : passer par l'API produit

WooCommerce expose une méthode de duplication native, accessible depuis l'administration via le lien « Dupliquer », qui s'appuie en interne sur des classes dédiées pour recréer proprement chaque variation avec de nouveaux identifiants cohérents. Pour une duplication programmatique, la voie correcte consiste à charger le produit avec `wc_get_product()`, puis à utiliser la classe interne de duplication plutôt que de reconstruire les relations à la main :

```
$produit_original = wc_get_product( $id_produit_source );

if ( $produit_original && $produit_original->is_type( 'variable' ) ) {
    $duplicateur = new WC_Admin_Duplicate_Product();
    $nouveau_produit = $duplicateur->product_duplicate( $produit_original );
}
```

Cette approche recrée chaque variation comme une entité à part entière, avec un nouvel identifiant, tout en réattribuant correctement le lien vers le nouveau produit parent et en régénérant les entrées de stock associées.

## Le stock ne se copie jamais tel quel

Même en passant par l'API, le stock d'un produit dupliqué ne doit presque jamais être copié à l'identique : le nouveau produit démarre en général à zéro, ou avec une quantité définie manuellement, plutôt que d'hériter du stock physique réel de l'original, qui reste rattaché à un seul emplacement d'inventaire.

> Sur nos migrations, la règle est simple : toute duplication de produit variable repasse par la classe de duplication native, jamais par une requête SQL directe, même pour un lot de plusieurs centaines de références.

## Et pour un import en masse ?

Ce billet ne couvre volontairement pas le cas de l'import d'un catalogue entier depuis un fichier fournisseur, qui suit une logique différente d'appariement par référence plutôt que de duplication d'un produit existant.

## En résumé

Une copie SQL directe donne l'illusion d'un gain de temps, mais déplace le vrai travail vers un débogage a posteriori souvent plus long que l'appel à l'API dès le départ. Passer par `wc_get_product()` et la classe de duplication native de WooCommerce reste la seule méthode qui garantit des variations et un stock cohérents pour le produit dupliqué.