Intégration fournisseur e-commerce : flux produits XML, CSV ou API

Une intégration fournisseur e-commerce consiste, en pratique, à synchroniser avec votre grossiste deux types de données qui n'évoluent pas du tout au même rythme. Le catalogue — noms, descriptions, photos, catégories — change rarement, parfois une fois par semaine ou moins. Le stock et les prix changent souvent : toutes les heures chez certains fournisseurs, en temps réel chez d'autres. Le choix entre un fichier CSV, un flux produits XML ou une API n'est pas une question de mode technologique — il découle directement de la fréquence réelle de changement des données et de la rapidité avec laquelle vous devez y réagir.

Ce que vous synchronisez réellement avec un fournisseur

Séparer le catalogue du couple stock-et-prix a une conséquence concrète sur le format à choisir : un fichier mis à jour une fois par semaine peut rester un CSV importé manuellement, sans aucune automatisation. Les données qui doivent être à jour en quelques minutes — le stock d'un produit proche de la rupture, un prix chez un fournisseur qui révise ses tarifs plusieurs fois par jour — ont besoin d'un mécanisme récurrent ou d'une API, car importer un fichier à la main une fois par jour garantit qu'une partie de la journée, vous vendez un produit que le fournisseur n'a plus, ou à un prix qui n'est plus valable.

En pratique, le « catalogue » regroupe le nom du produit, la description, les photos, la catégorie et les attributs (couleur, taille, matériau) — des champs qui ne changent que lorsque le fournisseur lance un nouveau produit ou corrige une erreur de description. Le « stock et prix » regroupe la quantité disponible et le prix d'achat (ou le prix conseillé, si le fournisseur en recommande un) — des champs qui peuvent changer plusieurs fois dans la même journée, indépendamment du fait que le produit lui-même ait changé ou non.

La conséquence pratique de cette distinction : vous n'avez pas besoin — et vous ne devriez généralement pas — construire une intégration unique et uniforme pour les deux types de données. Vous pouvez importer le catalogue par un mécanisme (un CSV hebdomadaire, par exemple) et synchroniser le stock et le prix par un mécanisme complètement différent et plus fréquent (un flux XML rafraîchi toutes les heures, ou une API en temps réel). Mélanger les deux dans un seul processus d'import, rarement exécuté, est l'une des raisons les plus fréquentes pour lesquelles le stock d'une boutique « dérive » par rapport à la réalité chez le fournisseur — non pas parce que le mécanisme est défaillant, mais parce que des données qui changent à deux vitesses différentes se retrouvent sur le même calendrier unique.

CSV — le format le plus simple, avec un mythe à démonter

Le CSV est le format le moins exigeant techniquement — chaque plateforme e-commerce le prend en charge, et un fournisseur peut l'exporter depuis son propre système sans intégration dédiée.

Shopify. La documentation de Shopify décrit les exigences formelles du fichier sans indiquer de limite de taille : « save your CSV file in UTF-8 format using LF-style linefeeds », et chaque colonne doit être séparée par une virgule, avec la première ligne comme en-têtes de colonnes (help.shopify.com/en/manual/products/import-export/using-csv, consulté le 2026-10-01 ; documentation en anglais, citations dans la langue d'origine). Les images ne font pas partie du fichier lui-même : « A CSV file can only contain text » et, plus loin sur la même page, « You can use only image URLs in CSV files ». Les URL d'images hébergées ailleurs doivent être accessibles publiquement, en https:// et sans protection par mot de passe. Aucune des trois pages de documentation Shopify vérifiées — import CSV, aperçu import/export, résolution de problèmes — n'indique de taille maximale en mégaoctets. Si vous avez entendu parler d'une limite de 15 Mo, ce chiffre n'est confirmé par aucune documentation Shopify actuelle ; la seule limite confirmée et précise ne concerne que les boutiques ayant au moins 500 000 variantes (hors boutiques Shopify Plus), qui peuvent créer au maximum 10 000 nouvelles variantes par 24 heures par import CSV ou via l'API.

WooCommerce. L'importateur CSV de produits intégré à WooCommerce n'a pas de limite de taille propre — « The Maximum size value shown on the upload screen is set at the server level. To increase it, contact your hosting company » (woocommerce.com/document/product-csv-importer-exporter, consulté le 2026-10-05). Seul votre hébergeur peut la relever. Avant un import volumineux, la documentation conseille de faire une sauvegarde, de tester un petit import sur une copie de la boutique (site de staging) et de diviser le CSV en lots plus petits, où les erreurs sont plus faciles à trouver et à corriger. Les seules colonnes obligatoires sont SKU (WooCommerce en génère un si elle est omise) et Name — le reste des champs est facultatif. Un produit à variantes s'importe via une ligne parent plus des lignes de variantes liées par Parent, le SKU et les attributs. Pour transformer un produit simple existant en produit à variantes, la documentation précise que depuis WooCommerce 11.1, un seul import suffit si la ligne parent précède ses variantes dans le fichier ; sur une version plus ancienne, ou si l'ordre des lignes n'est pas garanti, il faut deux passages — d'abord le produit avec ses attributs, puis les variantes seules.

PrestaShop. L'outil d'import de PrestaShop attend un fichier CSV avec un séparateur point-virgule recommandé — « We recommend using a semicolon ';' as a field separator » — en encodage UTF-8 (avec ISO-8859-1 comme alternative) et des dates au format ISO 8601 (docs.prestashop-project.org, consulté le 2026-10-01). La documentation donne un exemple de ligne d'en-tête et de données pour les produits : "Enabled";"Name";"Categories";"Price";"Tax rule ID";"Buying price";"On sale";"Reference";"Weight";"Quantity";"Short desc.";"Long desc";"Images URL" — la colonne Reference correspond au SKU, et Images URL n'accepte que des adresses, pas de fichiers binaires, comme chez Shopify et WooCommerce. Contrainte importante : les données s'importent pour une seule langue à la fois — un catalogue multilingue demande autant de passages d'import qu'il y a de langues. Si vous cherchez spécifiquement à intégrer PrestaShop avec des fournisseurs, c'est ce même mécanisme CSV qui constitue le point de départ — la documentation d'import ne décrit pas d'autre chemin intégré dédié aux fournisseurs, et les différences entre fournisseurs portent sur le format du fichier d'entrée (séparateur, encodage, noms de colonnes). Si le stock et les prix doivent se mettre à jour plus souvent que vous ne pouvez importer un fichier à la main, il faut passer à la couche décrite plus bas — une API ou un outil d'intégration.

Flux produits XML — quand le CSV ne suffit plus

Le XML entre en jeu lorsque l'échange de données a besoin d'une structure que le CSV ne gère pas bien — catégories imbriquées, variantes liées à un produit parent, plusieurs photos par produit dans un seul fichier. Contrairement au CSV, que chaque plateforme e-commerce accepte comme un tableau plat, un flux produits XML de fournisseur est généralement construit selon le schéma propre à ce fournisseur. Il n'existe pas de norme XML unique à l'échelle du secteur pour les flux grossistes B2B, contrairement aux flux produits pour marketplaces (voir Google Merchant Center plus bas) — chaque fournisseur, ou la plateforme logicielle derrière lui, a tendance à définir sa propre structure, ses propres noms de champs et son propre système de versions.

Avant de construire un mapping sur le flux XML d'un fournisseur donné, vérifiez le schéma exact et la version qu'il exporte. Les noms de champs, l'imbrication et même la structure racine du fichier peuvent différer non seulement entre fournisseurs, mais aussi entre versions de l'outil d'export d'un même fournisseur au fil du temps. Un mapping qui fonctionnait pour le flux d'un fournisseur peut échouer silencieusement sur celui d'un autre — l'importateur ne renvoie généralement pas d'erreur, il récupère simplement moins de champs que prévu, ce qui explique pourquoi le conseil sur le journal de synchronisation donné plus bas dans cet article compte autant pour le XML que pour le CSV.

Si la documentation d'un fournisseur donné recommande une structure XML particulière, considérez-la comme source de vérité plutôt que les instructions génériques « import XML » de la documentation de votre propre plateforme — les outils d'import de plateforme sont généralement conçus pour une structure générique, et c'est le flux spécifique au fournisseur qui s'y adapte, pas l'inverse.

API et intégrateurs — quand il faut une synchronisation en temps réel

Si un changement de stock chez le fournisseur doit atteindre votre boutique en quelques minutes plutôt qu'en quelques heures, un fichier (CSV ou XML) importé selon un calendrier récurrent ne suffit plus — c'est là qu'intervient une API, ou une couche d'intégration qui fait la synchronisation à votre place.

En pratique, la synchronisation fournisseur en temps réel se construit de trois façons : via le connecteur ou l'application native de votre plateforme pour ce fournisseur précis, lorsqu'il en existe un ; via une intégration API directe avec le système du fournisseur ; ou via un outil d'automatisation généraliste comme Zapier, Make ou n8n, qui vérifie les changements de stock à intervalles réguliers (ou les reçoit au moment où ils se produisent) et les transmet à la boutique. Ces trois options diffèrent surtout par leur modèle tarifaire et leur fréquence de synchronisation. Zapier vend un forfait assorti d'un quota mensuel de tâches, Make facture en crédits (« most actions consume 1 credit »), et n8n tarife ses offres cloud au nombre d'exécutions de workflows par mois, avec une Community Edition auto-hébergée disponible sur GitHub (n8n.io/pricing, consulté le 2026-10-01). Avec un connecteur natif, la fréquence de synchronisation est celle que son éditeur a prévue — vérifiez-la avant de compter dessus.

Quelle que soit la voie choisie, la leçon des imports de fichiers reste valable : la fréquence à laquelle l'intégration vérifie les changements dépend généralement du forfait. La page tarifaire de Zapier indique un délai de mise à jour de 15 minutes sur l'offre Free et de 2 minutes sur Professional ; Make fixe un intervalle minimal de 15 minutes entre deux scénarios planifiés sur son offre Free, et de 1 minute à partir de Core (zapier.com/pricing, make.com/en/pricing, consulté le 2026-10-01). Une synchronisation réellement en temps réel — où le système du fournisseur transmet un changement dès qu'il se produit, au lieu que votre intégration le vérifie à intervalles fixes — doit aussi être prise en charge du côté du fournisseur : demandez-la-lui avant de bâtir votre organisation dessus. Nous traitons le même compromis du côté marketplace — synchroniser avec une marketplace plutôt qu'avec un fournisseur — dans notre article sur l'intégration marketplace ; la leçon reste la même dans les deux cas : choisir une couche d'intégration revient surtout à choisir une fréquence de synchronisation, pas seulement une liste de connexions prises en charge.

Dropshipping — le même mécanisme, des exigences de fraîcheur plus élevées

Le dropshipping change qui expédie physiquement la marchandise, mais ne change pas la logique d'intégration — il ne fait que relever le niveau d'exigence sur la fraîcheur des données. Une commande passée dans votre boutique part automatiquement vers le fournisseur (via une API ou un fichier d'échange de commandes), le fournisseur emballe et expédie directement au client, et vous ne détenez jamais de stock physique. Conséquence : si le stock du fournisseur ne se synchronise qu'une fois par jour au lieu d'être en temps réel, le risque de vendre un produit que le fournisseur n'a plus est plus élevé que dans un modèle où vous détenez votre propre entrepôt — parce que vous n'avez pas de seconde couche de contrôle (votre propre stock physique) entre la commande du client et son exécution.

Le dropshipping a aussi une conséquence côté documents, pas seulement côté stock. C'est généralement vous, en tant que vendeur visible par le client, qui émettez la facture ou le reçu, même si la marchandise n'est jamais passée par votre entrepôt — le fournisseur vous adresse sa propre facture, à vous, client professionnel. Ces deux documents (votre facture au client, celle que le fournisseur vous adresse) vivent dans deux systèmes différents et n'ont pas besoin de correspondre par numéro ou par date — si leur circulation n'est pas définie à l'avance, un décalage comptable apparaît facilement. La question de savoir qui doit détenir quel document lors d'une intégration avec un ERP est traitée plus en détail dans notre article sur l'intégration ERP, WMS et CRM.

Flux produits vers Google — une chose distincte de l'import fournisseur

L'import depuis un fournisseur alimente votre catalogue produits ; un flux vers Google Merchant Center est un fichier distinct, construit à partir de votre catalogue déjà importé, pas à partir du fichier brut du fournisseur. Google accepte trois formats — « Delimited text files: .txt (tab-delimited text) or .tsv... XML files: .xml » — avec une limite de taille par fichier de 4 Go (support.google.com/merchants/answer/12631822, consulté le 2026-10-01) ; aucune des deux pages vérifiées n'indique de limite sur le nombre de produits dans un fichier. Vous pouvez charger le fichier à la main (il faut alors le recharger après chaque changement), mais Merchant Center dispose aussi d'un mécanisme documenté pour récupérer le fichier depuis une URL fixe selon un calendrier — toutes les 24 heures par défaut, avec un calendrier configurable (support.google.com/merchants/answer/12158380, consulté le 2026-10-01). C'est le même mécanisme qu'un flux par URL pour un flux produits XML : vous indiquez l'adresse une seule fois, et le système l'interroge lui-même, sans rechargement manuel à chaque changement. Les exigences complètes sur le contenu du flux lui-même — limites de titre et de description, GTIN, exigences sur les images — sont un sujet à part ; cet article ne traite que de l'origine des données de ce flux.

Erreurs fréquentes d'intégration fournisseur e-commerce

• SKU dupliqués — le fournisseur utilise le même identifiant pour un produit de base et sa variante, et le mapping des champs dans la boutique ne les distingue pas, si bien que les variantes s'écrasent mutuellement à chaque synchronisation.
• Incompatibilité d'encodage — un fichier en ISO-8859-1 importé comme UTF-8 (ou l'inverse) transforme les caractères accentués des noms et descriptions en chaînes illisibles.
• Prix TTC et prix HT inversés lors du mapping — le fournisseur envoie un prix HT, la boutique l'interprète comme un prix TTC (ou l'inverse), ce qui détériore silencieusement la marge sur tout le catalogue sans aucune erreur d'import visible.
• Décalage entre la synchronisation du stock et la commande du client — si le stock ne se met à jour que toutes les heures au lieu d'être en temps réel, un produit que le fournisseur n'a plus peut être vendu pendant cette heure-là — risque plus élevé en cas de forte rotation et en dropshipping.
• Photos hébergées sur une URL non publique ou temporaire — un import CSV avec des adresses d'images sur le serveur du fournisseur, qui expire ou bloque l'accès externe par la suite, produit des fiches produits sans photo dans la boutique, même si l'import a « réussi ».
• Une seule version de fichier pour plusieurs langues — dans un catalogue multilingue, si l'importateur (comme celui de PrestaShop) ne gère qu'une langue par passage, essayer d'importer un seul fichier avec des colonnes pour plusieurs langues à la fois échoue totalement ou n'importe qu'une seule langue, selon l'outil.
• Aucune séparation entre le calendrier d'import du catalogue et celui de la synchronisation du stock — le mécanisme décrit plus haut : si les deux processus tournent sur le même cycle peu fréquent, le stock et le prix ne sont à jour qu'au rythme, rare, du catalogue lui-même, alors qu'ils pourraient techniquement être rafraîchis bien plus souvent.

La plupart de ces erreurs ne produisent jamais de message « import échoué » — le fichier se charge sans problème, et l'erreur n'apparaît que dans son effet : un prix faux, une photo manquante, ou un produit vendu qui n'existe plus. C'est pourquoi il vaut la peine de conserver un journal simple pour chaque synchronisation (nombre d'articles mis à jour, nombre d'erreurs, durée) et de le comparer au passage précédent — une baisse soudaine du nombre d'articles mis à jour, même sans aucun message d'erreur, signifie généralement que quelque chose a changé chez le fournisseur (format de fichier, URL, structure des colonnes) avant que vous ne le remarquiez dans la boutique elle-même.

Si vous ne savez pas si construire une intégration complète et automatisée avec un fournisseur (API, synchronisation en temps réel) a du sens à l'échelle de votre catalogue, ou si un import CSV récurrent suffit, consultez notre calculateur de coût d'une boutique en ligne — il prend en compte la taille du catalogue (nombre de SKU) et les intégrations, y compris avec un système ERP, pour voir comment ces deux variables font bouger le budget.

Pour une vue d'ensemble de la place de l'intégration fournisseur dans le reste des opérations d'une boutique — avec l'ERP, le WMS et l'automatisation — voir notre page sur les opérations e-commerce.