CSV, XML, API ou FTP : choisir le bon flux fournisseur

Choisissez le flux qui fournit les champs nécessaires avec une mise à jour traçable et une reprise sûre, pas celui dont le nom paraît le plus moderne. Un CSV complet déposé chaque jour peut être préférable à une API sans horodatage ni pagination fiable. Une API devient intéressante pour des variations fréquentes et des requêtes ciblées ; XML convient aux structures imbriquées et documentées ; FTP est un canal de transfert, souvent utilisé pour déposer des fichiers, pas un format de catalogue. Avant de décider, testez la documentation, le volume, les limites, les identifiants, le prix, le stock, la sécurité et le comportement en cas d'interruption.

Séparer le format, le transport et le contrat d'accès

CSV et XML décrivent principalement une représentation de données. HTTP et FTP décrivent des mécanismes d'échange. Une « API JSON » combine généralement un contrat applicatif, des documents JSON et un transport HTTP. Un « flux FTP » peut contenir un CSV, un XML, une archive ou plusieurs fichiers. Mélanger ces niveaux conduit à de fausses comparaisons.

La RFC 4180 documente un format CSV couramment utilisé et son type MIME. Elle décrit notamment les lignes, les séparateurs et l'échappement des champs entre guillemets, mais elle ne définit pas les colonnes price, stock ou ean. La recommandation XML du W3C définit la syntaxe et la bonne formation des documents XML ; elle ne donne pas davantage le schéma métier du fournisseur. Dans les deux cas, la documentation du producteur reste indispensable.

FTP, normalisé historiquement par la RFC 959 et complété par des mises à jour, sert au transfert de fichiers entre hôtes. Son existence ne signifie pas que la connexion est chiffrée ni que le contenu est récent. Il faut vérifier le protocole réellement proposé, la méthode d'authentification, les protections de transport et la politique de rotation des accès sans exposer de secret dans les journaux.

Une matrice de choix factuelle

Cette matrice ne classe pas une technologie dans l'absolu. Elle sert à faire émerger les questions que le fournisseur doit documenter. Un flux doit être jugé sur ses preuves réelles : exemple de réponse, dictionnaire de données, cadence annoncée, conditions d'utilisation, méthode de reprise et contact en cas d'incident.

Les critères qui décident vraiment

Complétude métier

Listez les champs non négociables avant de discuter technologie : identifiant de produit et de variante, SKU, marque, titre, prix, devise, nature HT/TTC, stock avec son niveau de précision, unité de vente, MOQ, pas de commande, image et horodatage. Utilisez la grille des colonnes d'un catalogue grossiste pour éviter qu'une démonstration technique masque l'absence d'une donnée essentielle.

Fraîcheur et preuve de changement

Demandez si le flux est complet ou incrémental. Pour un fichier complet, cherchez une date de génération et un mécanisme empêchant la lecture avant la fin du dépôt. Pour une API, documentez la pagination, le tri stable, les curseurs et la sémantique des suppressions. Les champs HTTP ETag et Last-Modified sont des validateurs définis par la RFC 9110, mais leur présence et leur sens dépendent du serveur. Ils ne remplacent pas un horodatage métier du prix ou du stock.

Le délai de confiance des prix et stocks doit être choisi selon le risque commercial. Un catalogue de caractéristiques peut évoluer lentement ; une disponibilité peut changer entre deux commandes. Le même cycle ne convient pas forcément aux deux familles de champs.

Reprise et idempotence

Simulez une interruption. Pouvez-vous reprendre à la page suivante sans manquer ni dupliquer de produits ? Un fichier possède-t-il un nom temporaire avant d'être déclaré complet ? Une API fournit-elle un identifiant et un ordre stables ? Les mises à jour doivent être idempotentes : rejouer le même document ne doit pas multiplier les offres.

Archivez l'empreinte du contenu accepté, la date de collecte, l'URL ou le nom de fichier et la version du parseur. Cette traçabilité permet de comprendre si une différence provient du fournisseur ou de votre transformation.

Sécurité et droits

Ne placez jamais une clé API dans le code, le CSV produit ou un message d'erreur. Limitez les accès au périmètre nécessaire et suivez la procédure de rotation du fournisseur. Vérifiez aussi la licence ou les conditions d'utilisation : une ressource techniquement accessible n'est pas automatiquement autorisée à la réutilisation commerciale. La RFC 9309 rappelle d'ailleurs que robots.txt n'est pas une forme d'autorisation d'accès.

Test de sélection en neuf étapes

1. Obtenir la documentation officielle et les conditions d'usage. 2. Lister les champs obligatoires et leur définition. 3. Vérifier un petit échantillon comprenant variantes, ruptures et valeurs vides. 4. Mesurer le volume et comprendre la pagination ou le découpage des fichiers. 5. Identifier fréquence, horodatages et signaux de changement. 6. Provoquer une erreur contrôlée et observer le code, le message et la reprise. 7. Rejouer le même extrait pour vérifier l'absence de doublons. 8. Comparer les données à des fiches officielles autorisées. 9. Lancer un lot canari fournisseur avant d'augmenter le volume.

À la fin, rédigez une fiche de décision avec trois colonnes : « prouvé », « non fourni » et « à confirmer ». Le terme « supporté » ne doit être utilisé que si un test ou une documentation officielle le démontre.

Checklist de raccordement

• ☐ Format et transport sont identifiés séparément.
• ☐ Le schéma métier et les unités sont documentés.
• ☐ Pagination, quotas et volume ont été testés.
• ☐ L'horodatage de génération est disponible ou marqué absent.
• ☐ Une reprise après interruption a été vérifiée.
• ☐ Les suppressions et ruptures ont une sémantique claire.
• ☐ Les secrets restent hors fichiers et journaux.
• ☐ Les conditions autorisent l'usage prévu.
• ☐ Les réponses brutes et leurs empreintes sont archivées.
• ☐ Le canari passe avant l'import complet.

Ce qu'ArbitragePro+ peut automatiser / ce que le vendeur doit vérifier

La spécification proposée diagnostic-flux pourrait contrôler structure, types, pagination, stabilité des identifiants, empreintes et erreurs d'un canari. Elle pourrait comparer les champs fournis aux exigences déclarées, sans prétendre définir le contrat du fournisseur.

Le vendeur doit choisir la source autorisée, obtenir les accès, confirmer la base fiscale et les unités, évaluer la sécurité du canal, puis valider que la fréquence convient à son modèle de commande.

Identifier le raccordement adapté

Consulter les sources suivies par ArbitragePro+ pour examiner les informations disponibles sur chaque connexion.

Sources officielles

• IETF, RFC 4180, « Common Format and MIME Type for CSV Files », https://www.rfc-editor.org/info/rfc4180/ — consulté le 2026-08-17.
• W3C, « Extensible Markup Language (XML) 1.0 », https://www.w3.org/TR/xml/ — consulté le 2026-08-17.
• IETF, RFC 9110, « HTTP Semantics », https://www.rfc-editor.org/rfc/rfc9110.html — consulté le 2026-08-17.
• IETF, RFC 959, « File Transfer Protocol », https://www.rfc-editor.org/info/rfc959/ — consulté le 2026-08-17.
• IETF, RFC 9309, « Robots Exclusion Protocol », https://www.rfc-editor.org/rfc/rfc9309.html — consulté le 2026-08-17.