Import et export de produits dans PrestaShop : méthodes CSV, XML et API

Faire entrer des produits dans PrestaShop, puis les en faire sortir, c'est la plomberie peu glamour dont tout catalogue finit par dépendre : une migration depuis une autre plateforme, un flux fournisseur nocturne qui modifie 4 000 prix en une nuit, un ERP qui détient le stock et doit le répercuter dans PrestaShop. PrestaShop met à votre disposition trois outils réellement différents pour cela — l'importateur CSV intégré, l'API Webservice et le Gestionnaire SQL pour l'export — et l'erreur la plus coûteuse que commettent les marchands consiste à choisir le mauvais outil. Lancer une boutique avec 200 produits et synchroniser chaque nuit 40 000 références ne relèvent pas du même travail, et l'outil parfait pour l'un s'effondrera discrètement sur l'autre. Ce guide porte spécifiquement sur les données produit : catalogue, déclinaisons, images, stock et prix, à l'import comme à l'export. (Si ce dont vous avez réellement besoin, c'est d'extraire de PrestaShop des données de commandes et de factures — pour la comptabilité ou le rapprochement — il s'agit d'un autre chemin d'export, traité dans les exports CSV des commandes et factures.)

Dernière mise à jour : juin 2026.

L'importateur CSV intégré : le point de départ de presque tout le monde

PrestaShop intègre un importateur natif dans Paramètres avancés → Import (le AdminImportController). Il accepte le CSV pour les produits, déclinaisons, catégories, clients, adresses, marques (fabricants), fournisseurs, alias et — lorsque votre version les expose — magasins ; vous choisissez d'abord le type d'entité, puis vous téléversez le fichier. Pour un catalogue de quelques milliers de produits, sans besoin de synchronisation récurrente, c'est la bonne solution et vous pouvez ignorer la section sur l'API. L'avantage est bien réel : vous chargez toute votre boutique depuis une feuille de calcul, depuis le back-office, sans développeur ni ligne de code.

Les règles de format CSV qui provoquent la plupart des échecs

L'importateur ne pardonne pas les erreurs de format, et un fichier mal formé est la première raison pour laquelle un import « ne fonctionne pas ». Vérifiez ces points avant de téléverser quoi que ce soit :

• Encodage : UTF-8 sans BOM. Si vous avez construit le fichier dans Excel, utilisez Enregistrer sous → CSV UTF-8 — le simple format "CSV" enregistre en Windows-1252 et transforme chaque caractère accentué en mojibake (é devient é). Si votre fichier contient déjà un BOM, supprimez-le : sed -i '1s/^\xEF\xBB\xBF//' file.csv.
• Séparateur : point-virgule (;) par défaut. Modifiable dans l'écran d'import, mais ne passez jamais à la virgule si vos descriptions contiennent des virgules — ce qui est toujours le cas.
• Qualificateur de texte : guillemets doubles ("). Entourez tout champ qui contient le séparateur ou un saut de ligne.
• Fins de ligne : Unix LF est le choix le plus sûr ; CRLF est accepté, mais injecte parfois des lignes vides fantômes importées comme des produits vierges.
• Ligne d'en-tête : les noms de colonnes correspondent soit aux noms de champs de PrestaShop, soit vous les associez manuellement sur l'écran suivant. L'importateur mémorise un mappage nommé, donc un fichier fournisseur récurrent ne doit être mappé qu'une seule fois.

Un fichier produit minimal :

ID;Active;Name;Categories;Price (tax excl.);Tax rules ID;Reference;Quantity;Description

Le réglage qui décide entre mise à jour et doublon

C'est celui qui piège les gens au deuxième import. L'importateur a deux modes qui se ressemblent presque parfaitement, mais qui se comportent à l'opposé. Par défaut, il crée des lignes. Pour lui faire mettre à jour les produits existants au lieu de les cloner, vous devez cocher « Utiliser la référence du produit comme clé » (ou fournir la vraie colonne ID et cocher l'équivalent utilisant l'ID comme clé). Oubliez ce réglage lors d'une mise à jour de prix et vous ne mettez pas à jour 4 000 produits — vous créez 4 000 doublons et doublez votre catalogue. Qu'est-ce que cela signifie concrètement ? Un flux fournisseur récurrent doit contenir une Reference stable (ou un ID) sur chaque ligne, et cette case doit être cochée, absolument à chaque fois.

Déclinaisons : importées séparément, et l'ordre compte

Les déclinaisons (variantes) constituent leur propre entité — vous importez d'abord les produits parents, puis vous lancez un second import avec l'entité Déclinaisons sélectionnée. Chaque ligne référence le parent par ID ou référence et contient le groupe d'attributs, la valeur, l'impact sur le prix, la quantité, l'EAN13 et la référence de la déclinaison :

Product ID;Attribute (Name:Type:Position);Value (Value:Position);Reference;Supplier reference;EAN13;Impact on price;Quantity

Le piège classique : PrestaShop crée automatiquement les groupes d'attributs et les valeurs qu'il ne connaît pas encore, et il fait la correspondance sur la chaîne exacte. "Size", "size" et "SIZE" deviennent trois groupes d'attributs distincts, et votre liste déroulante de tailles finit en désordre. Normalisez la casse et l'orthographe dans le fichier avant l'import, pas après.

Images par URL — et pourquoi c'est ici que votre serveur lâche

Vous pouvez renseigner les images en plaçant dans la colonne image une liste d'URL séparées par des virgules ; la première devient la couverture. Ce sont les mécanismes internes qui piègent les utilisateurs, car chaque URL déclenche un téléchargement synchrone pendant la requête d'import :

• Tempête de téléchargements : 5 000 produits × 3 images = 15 000 récupérations HTTP dans une seule tâche d'import. Un import déclenché depuis le web expirera bien avant la fin. Le schéma fiable se fait en deux passes : importer d'abord les produits sans images, puis effectuer une seconde passe, en lots plus petits, uniquement pour les images.
• Multiplication des miniatures : chaque image importée est régénérée dans tous les formats définis dans Apparence → Paramètres des images. Huit formats signifient huit opérations de redimensionnement par image. Avant un gros import d'images, supprimez temporairement les formats inutilisés, puis régénérez une seule fois à la fin.
• « Supprimer toutes les images avant l'import » : cette option supprime toutes les images existantes des produits correspondants — y compris celles que vous avez ajoutées à la main — avant de charger le nouveau jeu. C'est le bon outil pour une resynchronisation propre, et une catastrophe si ce n'était pas votre intention.

Faire survivre les gros imports : délais d'expiration, mémoire et CLI

L'importateur web reste à l'aise jusqu'à environ 5 000 produits. Au-delà, vous cessez de lutter contre le format CSV et commencez à lutter contre PHP et le serveur web :

• Temps d'exécution : le max_execution_time standard de 30 secondes est inutilisable pour un gros fichier. Passez-le à 600+ dans php.ini (ou par import via le worker), sinon vous ne terminerez jamais un seul lot.
• Mémoire : un CSV de 50 MB contenant environ 20 000 produits demande 256 MB+ de mémoire PHP ; réglez memory_limit sur 512M pour garder de la marge.
• Travaillez en lots : découpez en fichiers de 1 000 à 2 000 lignes. Si la ligne 7 400 échoue, vous relancez un lot, pas les 40 000 lignes.
• Désactivez l'indexation pendant l'exécution : dans Paramètres de la boutique → Rechercher, désactivez « Indexer les produits à l'enregistrement », et ne régénérez pas les images au milieu de l'import. Réindexez une seule fois à la fin. Sur les grands catalogues, c'est le gain de temps le plus important — réindexer chaque ligne représente l'essentiel du temps écoulé.
• Sortez les gros traitements de la requête web : le cœur de PrestaShop ne fournit pas de commande console prestashop:import intégrée, donc pour une migration ponctuelle de 10 000+ produits, les réponses pratiques consistent à découper fortement les fichiers (1 000 à 2 000 lignes), à relever les limites serveur ci-dessous, ou à piloter le chargement depuis un module d'import dédié ou un script API exécuté en ligne de commande — bref, tout ce qui tourne hors du serveur web pour éviter les délais d'expiration de requête.

Extraire les données produit : les options d'export de PrestaShop

L'export est le point faible de la plateforme, et il vaut mieux le dire clairement. La page Import native sert aux imports et aux fichiers d'exemple — ce n'est pas un véritable outil d'export produit. Ce qui s'en rapproche le plus dans le back-office est le bouton Exporter de la liste des produits elle-même, mais il ne sort que les champs de base affichés dans la liste — pas les déclinaisons, pas les prix spécifiques, pas le stock par entrepôt. Pour un besoin sérieux, deux voies sont meilleures.

Gestionnaire SQL : le cheval de trait de l'export

Paramètres avancés → Base de données → Gestionnaire SQL vous permet d'écrire une requête de lecture et de télécharger le résultat en CSV. C'est le moyen le plus rapide d'obtenir exactement les colonnes voulues. Pour exporter tous les produits avec leur stock actuel :

SELECT p.id_product, pl.name, p.reference, p.price, sa.quantity FROM ps_product p JOIN ps_product_lang pl ON p.id_product = pl.id_product AND pl.id_lang = 1 JOIN ps_stock_available sa ON p.id_product = sa.id_product AND sa.id_product_attribute = 0;

(Remplacez ps_ par le vrai préfixe de vos tables.) Cela fonctionne parfaitement avec l'importateur pour les modifications en masse : exporter en CSV, modifier les prix ou le stock dans une feuille de calcul, réimporter avec la référence comme clé. La limite, c'est que le Gestionnaire SQL est manuel et en lecture seule — excellent outil ponctuel, mais mauvaise automatisation, car quelqu'un doit cliquer.

Quand l'export doit devenir un flux récurrent

Flux de prix quotidiens, flux marketplace et Google Shopping, transmission nocturne à un système externe — tout cela exige un fichier généré selon un calendrier, pas une personne dans le Gestionnaire SQL. C'est le territoire des modules : un générateur qui construit un flux produit multilingue (et, pour la découvrabilité, garde votre sitemap synchronisé avec le catalogue actif) via cron, afin que le fichier reste à jour sans que personne ne touche au back-office. Si la génération de flux est le vrai besoin, parcourez les modules d'export et de flux sur mypresta.rocks — l'intérêt étant d'avoir un flux toujours actuel et un administrateur qui n'a jamais à se rappeler de le lancer.

XML et API Webservice : pour les intégrations, pas les migrations

XML est la lingua franca des flux B2B, des ERP et des marketplaces, et voici le point clé : l'importateur CSV de PrestaShop ne lit pas du tout le XML. Vous avez deux options honnêtes, adaptées à des objectifs différents.

Option 1 — convertir le XML en CSV

Si un fournisseur vous remet un flux XML et que vous voulez simplement l'intégrer une fois au catalogue, transformez-le au format CSV attendu par PrestaShop avec une feuille de style XSLT, un court script Python (xml.etree.ElementTree traite la plupart des flux fournisseurs plats en nettement moins de 50 lignes), ou un outil de données comme Talend ou Akeneo. Puis donnez-le à l'importateur natif. Simple, sans API à activer, idéal pour un chargement ponctuel.

Option 2 — parler directement à l'API Webservice

Pour une synchronisation bidirectionnelle continue, l'API Webservice est la bonne couche. C'est une interface de style REST avec un CRUD complet sur les produits, déclinaisons, catégories, stocks, clients et commandes. Le Webservice classique (legacy) privilégie XML — c'est le format sur lequel s'appuyer dans les versions prises en charge ; JSON n'est généralement pas disponible sur le webservice legacy, donc si vous avez spécifiquement besoin de JSON, vérifiez plutôt si votre version de PrestaShop fournit la nouvelle API d'administration basée sur Symfony. Activez-la dans Paramètres avancés → Webservice, puis créez une clé et ne lui accordez que les ressources et verbes nécessaires — ne donnez jamais à une clé un accès global à toutes les ressources. Créez un produit avec un POST vers https://yourstore.com/api/products contenant un corps XML ; mettez à jour avec PUT et l'ID du produit dans l'URL ; la réponse renvoie l'entité avec son nouvel ID.

Trois réalités à prévoir avant de construire dessus :

• Une entité par requête. Il n'y a pas de point d'entrée en masse — 10 000 produits, ce sont 10 000 appels. Le webservice legacy du cœur n'intègre pas de limitation de débit API, mais votre hébergement, une couche de sécurité/WAF, ou votre propre Apache (mod_evasive) ou Nginx (limit_req) peut brider une rafale ; espacez donc les appels d'environ 100 à 200 ms, et un import de 10k devient une fenêtre planifiée d'environ 30 minutes, pas une surprise.
• Les images se téléversent, elles ne se téléchargent pas. Envoyez le fichier en POST vers /api/images/products/{id} et PrestaShop le stocke directement — bien plus fiable que l'approche CSV par téléchargement d'URL, car rien ne dépend de la capacité de votre serveur à récupérer une URL distante au milieu de l'import.
• Prévoyez une logique de reprise. L'API répond avec des codes HTTP (201 créé, 200 mis à jour, 404 introuvable, 500 erreur serveur). Journalisez chaque réponse et réessayez les 500 — sur des milliers d'appels, quelques-uns échoueront de façon transitoire, et une synchronisation qui ne peut pas reprendre n'est pas fiable.

Les erreurs que vous verrez vraiment — et leur correction

• « La propriété X est vide » : un champ obligatoire (nom, prix, catégorie) est vide. Vérifiez que chaque colonne obligatoire contient une valeur sur chaque ligne.
• « La catégorie n'existe pas » : vous avez référencé un ID de catégorie qui n'existe pas. Importez d'abord les catégories, ou utilisez les noms de catégories — l'importateur accepte les deux et crée celles qui manquent.
• Prix incorrects après import : l'importateur lit les prix hors taxes. Si votre fichier contient des prix TTC, divisez d'abord par (1 + taux) ou mappez la bonne règle de taxe.
• Accents transformés en caractères illisibles : le fichier n'est pas en UTF-8. Convertissez-le : iconv -f Windows-1252 -t UTF-8 input.csv > output.csv.
• L'import a « fonctionné », mais les produits sont invisibles : vérifiez Active=1, une vraie catégorie assignée, la bonne association de boutique en multiboutique, et que l'index produit a été reconstruit.
• Doublons après un réimport : vous avez oublié « Utiliser la référence du produit comme clé » (ou l'ID comme clé). Cela met à jour au lieu de cloner — voir l'avertissement ci-dessus.

Choisir la bonne méthode

Faites correspondre l'outil au travail, pas à l'habitude :

Questions fréquentes

Mon deuxième import a créé des doublons au lieu de mettre à jour. Qu'ai-je oublié ?

La case « Utiliser la référence du produit comme clé » (ou l'équivalent avec l'ID comme clé). Par défaut, l'importateur crée des lignes ; une mise à jour de prix sans cette case cochée clone donc chaque produit au lieu de le mettre à jour. Assurez-vous que chaque ligne contient une Reference ou un ID stable, et cochez l'option de clé à chaque exécution récurrente.

Pourquoi tous les caractères accentués sont-ils devenus illisibles après l'import ?

Le fichier n'est pas en UTF-8. Le simple enregistrement "CSV" d'Excel utilise Windows-1252, ce qui dégrade les accents — utilisez plutôt Enregistrer sous → CSV UTF-8, et supprimez un éventuel BOM en début de fichier. La section du billet consacrée à l'encodage montre exactement à quoi ressemblent les caractères cassés et la commande iconv en une ligne qui reconvertit un fichier Windows-1252 en UTF-8 propre.

L'importateur intégré peut-il lire un flux XML ?

Non — l'importateur CSV ne lit pas du tout le XML. Pour un chargement ponctuel, transformez d'abord le XML au format CSV attendu par PrestaShop (une feuille de style XSLT ou un court script xml.etree.ElementTree traite la plupart des flux fournisseurs plats). Pour une synchronisation bidirectionnelle continue, utilisez directement l'API Webservice au lieu de convertir des fichiers à chaque fois.

Mon import expire sans cesse sur un gros catalogue. Comment le faire passer ?

L'importateur web reste à l'aise jusqu'à environ 5 000 produits. Au-delà, découpez en lots de 1 000 à 2 000 lignes, augmentez max_execution_time (à 600+) et memory_limit (à 512M), et désactivez « Indexer les produits à l'enregistrement » pendant l'exécution — réindexer chaque ligne représente l'essentiel du temps écoulé. Le cœur de PrestaShop ne fournit pas de commande console prestashop:import, donc pour une migration de 10 000+ produits, pilotez le chargement depuis un module d'import ou un script API exécuté hors de la requête web.

Comment modifier en masse les prix ou le stock sans réimporter tout le catalogue ?

Faites un aller-retour par le Gestionnaire SQL : exportez en CSV les colonnes dont vous avez besoin, modifiez-les dans une feuille de calcul, puis réimportez avec la référence comme clé pour mettre à jour au lieu de cloner. Pour les changements de prix fréquents, nos modules de mise à jour massive des prix et de flux produit le font depuis le back-office selon un calendrier, afin que vous n'ayez pas à lancer le Gestionnaire SQL à la main ni à vous rappeler la case de clé à chaque fois.

Là où l'import/export rejoint le reste de vos opérations

L'import et l'export vivent rarement seuls — ils sont généralement une étape dans un flux de travail de catalogue ou de stock plus large. Quelques sujets voisins utiles à connaître :

• Stock via CSV. Une mise à jour de quantités en masse n'est qu'un import de deux colonnes avec une clé de référence. Mais la question plus profonde — quel niveau ces nombres doivent avoir, et quand réapprovisionner — est une discipline à part entière : voir quand réapprovisionner le stock.
• Dépasser la feuille de calcul. Si vous faites constamment des allers-retours avec des CSV rien que pour garder le stock juste, c'est généralement le signal qu'il est temps de passer à de vrais outils de gestion des stocks — quand les feuilles de calcul ne suffisent plus couvre cette transition.
• Export des commandes et factures. Entité différente, chemin différent — l'extraction des données de commande pour la comptabilité est traitée dans les exports CSV des commandes et factures.

Les données produit font partie de ces travaux que personne ne célèbre, mais dont tout le monde dépend : des imports propres signifient des fiches exactes, des prix corrects et un stock qui reflète la réalité. Le principe sous-jacent aux trois méthodes est le même — garder une clé stable sur chaque produit, choisir l'outil adapté à l'échelle du travail, et ne jamais laisser un import s'exécuter deux fois sans savoir s'il crée ou s'il met à jour. Si ce que vous cherchez vraiment est la génération récurrente de flux ou la transmission planifiée de données produit, les modules d'export et de sitemap sur mypresta.rocks sont conçus exactement pour cela — un flux qui reste à jour sans que personne n'ait à penser à appuyer sur un bouton.