Imports fournisseurs FTP/EDI PRICAT : guide automatisation 2026 (PIM)

Un import fournisseur échoue rarement sur le contenu des données. Il échoue sur le tuyau : un fichier lu pendant qu'il était encore en cours d'écriture, un mot de passe expiré un dimanche soir, un différentiel pris pour un catalogue complet. Cet article traite cette couche-là — FTP, SFTP, EDI PRICAT, planification, accusés de réception, reprise après échec. Le mapping des attributs et la normalisation des valeurs sont un sujet distinct, qui mérite son propre article.

Le transport est une couche à part entière

Deux questions sont souvent traitées ensemble alors qu'elles n'ont ni les mêmes causes de panne ni les mêmes responsables. La première est sémantique : que veut dire la colonne « PDS_NET » du fournisseur, en quelle unité, dans quel attribut doit-elle atterrir ? La seconde est logistique : comment le fichier arrive-t-il, comment savez-vous qu'il est complet, et que se passe-t-il quand il n'arrive pas ? Une règle de conversion parfaite ne dira rien d'un fichier tronqué parce que la connexion s'est coupée. Le transport a ses propres modes de défaillance : c'est lui qui décide si vos imports tiennent à cinquante fournisseurs ou s'ils réclament une surveillance humaine chaque matin.

FTP, FTPS, SFTP : trois sigles, deux protocoles

Les trois circulent comme des synonymes dans les échanges avec les fournisseurs. Ils ne le sont pas, et la confusion se paie en journées de configuration perdues.

FTP et FTPS

Le FTP historique ouvre deux connexions distinctes : un canal de commande sur le port 21 et un canal de données négocié à part, en mode actif ou passif. Cette séparation est la source de la moitié des incidents de pare-feu, et le FTP transporte identifiants et contenus en clair. Le FTPS ajoute une couche TLS au même protocole, en mode explicite ou implicite : cela règle la confidentialité, pas la gymnastique des deux canaux.

SFTP

Le SFTP n'a aucune parenté avec le FTP malgré son nom : c'est un sous-système de SSH, sur une connexion unique, port 22 par défaut. Une seule session chiffrée porte commandes et données, ce qui simplifie les règles de pare-feu, et il accepte l'authentification par clé publique — décisif en production, où un mot de passe partagé entre trois personnes finit toujours par expirer au pire moment. Si le fournisseur vous laisse le choix, c'est celui-ci ; un FTP en clair hérité est une dette qui ne survivra pas à votre prochain audit de sécurité.

Récupérer un fichier sans le couper en deux

Le piège le plus fréquent des dépôts de fichiers ne dépend pas du protocole : c'est la course entre celui qui écrit et celui qui lit. Le fournisseur pousse un catalogue de 180 Mo, la collecte se déclenche pendant le transfert, et vous lisez un fichier syntaxiquement valide mais amputé de sa moitié : aucune erreur n'est levée et six mille références disparaissent du catalogue. Trois conventions l'évitent.

• L'écriture atomique — le fournisseur dépose sous un nom temporaire (catalogue.csv.part) puis renomme en catalogue.csv une fois le transfert terminé. Le renommage est instantané : le fichier au nom attendu est, par construction, toujours complet.
• Le fichier témoin — à défaut, le fournisseur dépose un second fichier vide (catalogue.ok) après le premier. La collecte ne se déclenche qu'à la vue du témoin, jamais du catalogue seul.
• La stabilité de taille — sans coopération du fournisseur, le collecteur observe la taille sur deux relevés espacés et ne prend le fichier que si elle n'a pas bougé. C'est un filet de sécurité, pas une garantie.

Dernier réflexe : ne supprimez pas un fichier après lecture, déplacez-le dans une archive datée. Rejouer six semaines d'historique depuis l'archive prend une heure ; redemander ces fichiers à quinze fournisseurs prend un mois, et la moitié ne les a plus.

EDI : un format de message autant qu'un tuyau

L'EDI est souvent présenté comme « du FTP en plus compliqué ». C'est une mauvaise lecture : le FTP transporte des fichiers dont le contenu ne l'intéresse pas, l'EDI définit la grammaire des messages, leur séquence et leurs réponses. Il répond à une question que le FTP ignore : que doit répondre le destinataire, et sous quelle forme ?

Anatomie d'un PRICAT EDIFACT

Le PRICAT (Price/Sales Catalogue) est le message de catalogue tarifaire d'UN/EDIFACT, celui qu'un distributeur reçoit de ses fournisseurs. Un échange est une suite de segments de trois lettres encadrés par deux enveloppes : UNB … UNZ pour l'échange, dont l'en-tête porte les identifiants des parties et une référence de contrôle unique qui permet de détecter un envoi en double ; UNH … UNT pour le message, qui déclare son type, la version du répertoire utilisé (D.96A, D.01B…) et l'agence de normalisation. Entre les deux viennent l'identification du document et les parties (BGM, DTM, NAD, ces dernières identifiées par leur GLN), puis le corps : ligne article et GTIN (LIN), identifiants complémentaires (PIA), descriptions (IMD), mesures (MEA), prix et devise (PRI, CUX).

La version du répertoire n'est pas un détail cosmétique : deux fournisseurs peuvent envoyer un PRICAT parfaitement conforme et attendre des lectures différentes parce qu'ils ne se réfèrent pas au même. S'y ajoutent les guides sectoriels — EANCOM, le sous-ensemble EDIFACT maintenu par GS1, précise l'usage des segments pour le commerce de détail, et chaque enseigne publie le sien par-dessus.

Les autres messages du cycle

Le PRICAT ne vit jamais seul : le cycle commercial s'écrit aussi avec ORDERS (commande), ORDRSP (réponse à commande), DESADV (avis d'expédition) et INVOIC (facture), sur le même canal et avec le même partenaire. Côté nord-américain, la norme ANSI X12 couvre les mêmes besoins avec une autre numérotation : 832 pour le catalogue, 850 pour la commande.

CONTRL et APERAK : les deux accusés de réception

C'est le point le plus mal compris de l'EDI, et celui qui fait la différence en exploitation. CONTRL est l'accusé technique : il dit « j'ai reçu l'échange, sa syntaxe est correcte », ou signale le segment fautif — il ne dit rien du sens du message. APERAK est l'accusé applicatif : « j'ai reçu, j'ai compris, et voici ce que mon application en a fait », accepté, accepté avec réserves, ou rejeté avec un code d'erreur métier.

Un CONTRL positif ne dit donc rien d'utile sur le fond. Et un flux qui n'émet aucun accusé laisse le fournisseur dans le noir : il continue à publier sans savoir que ses trois cents dernières lignes partent en rejet chaque semaine. Émettre un retour exploitable, même hors EDI strict, est ce qui transforme un import en échange.

Planifier : fréquence, fenêtre et fuseau

La fréquence se cale sur le rythme réel de publication, pas sur une ambition. Interroger toutes les heures un serveur alimenté une fois par semaine noie le journal sous des relevés vides ; à l'inverse, une collecte quotidienne sur un flux de prix publié trois fois par jour vous fait vendre à un tarif périmé.

La fenêtre est l'intervalle pendant lequel le fichier est censé être disponible. Elle sert autant à déclencher qu'à alerter : si rien n'est arrivé à la fin de la fenêtre, quelqu'un doit le savoir. Un import qui ne trouve rien est un import raté, pas un import réussi sans données.

Le fuseau se venge deux fois par an : un fournisseur qui publie « à 22 h » publie à 22 h chez lui, et au changement d'heure la fenêtre se décale. Écrivez les planifications dans un fuseau explicite, et décalez de quelques minutes les collectes entre fournisseurs — une coupure réseau à minuit pile ne fera pas échouer cinquante flux d'un coup.

Reprendre après un échec

Un flux automatisé se juge sur ce qu'il fait quand ça se passe mal.

• L'idempotence — le collecteur enregistre une empreinte de chaque fichier traité (nom, taille, somme de contrôle) et, côté EDI, la référence de contrôle de l'échange. Un fichier republié à l'identique est reconnu et ignoré.
• La reprise à l'étape — collecte, analyse et écriture sont tracées séparément. Quand l'écriture échoue, on rejoue l'écriture ; on ne repart pas d'une connexion au serveur, qui n'a peut-être plus le fichier.
• La quarantaine — un fichier illisible part dans un répertoire dédié avec le motif du refus, plutôt que d'être retenté indéfiniment.
• Le seuil d'alerte — quelques lignes en rejet se traitent au fil de l'eau ; un tiers du fichier en rejet est un changement de format côté fournisseur, et doit réveiller quelqu'un le jour même.

Les pièges de la couche transport

• Le différentiel pris pour un complet — certains fournisseurs envoient tout le catalogue, d'autres seulement les créations et modifications, et certains alternent sans prévenir. Le comportement se choisit par flux, jamais en le déduisant du fichier. Corollaire : une référence qui sort du fichier est-elle arrêtée, en rupture, ou oubliée ? Sans règle explicite, le catalogue se vide tout seul ; la réponse par défaut raisonnable est de marquer inactif et d'alerter.
• Les noms de fichiers qui bougent — passer de catalogue.csv à catalogue_2026.csv suffit à ce que le collecteur ne trouve plus rien. Un motif de nom tolérant, assorti d'une alerte sur les fichiers non reconnus, règle le cas.

Ce que Pixee PIM prend en charge côté transport

Le module d'import de Pixee PIM collecte les catalogues depuis FTP, SFTP, URL directe (HTTP) ou pièce jointe e-mail (IMAP), en plus du dépôt manuel — aux formats CSV, Excel, XML et JSON. Les messages EDI (PRICAT) ne sont pas lus nativement : ils passent par une conversion en amont vers l'un de ces formats. Pour chaque flux, vous décrivez le transport et la planification — accès, motif de nom de fichier, format source, fréquence quotidienne, hebdomadaire ou personnalisée. Le système détecte les nouveaux fichiers, tient un rapport par import et conserve l'historique complet : de quoi rejouer un flux ou répondre à un fournisseur qui conteste une livraison. La validation des identifiants produits à l'entrée relève du module EAN Manager, et les flux normalisés de la grande distribution suivent une logique voisine, décrite dans notre article sur la synchronisation GDSN / GS1.

Un échange EDI historique n'a pas à être démonté pour ouvrir un canal supplémentaire : c'est le principe de l'intégration Sage X3, où le PIM se place à côté du flux existant. Les volumes dépendent du plan — 2 fournisseurs et un import automatisé pendant l'essai gratuit de 30 jours, 5 fournisseurs et 150 imports par mois sur Starter, 25 fournisseurs en imports illimités sur Growth ; le détail est sur la page tarifs.

Questions fréquentes

Faut-il exiger de l'EDI d'un fournisseur qui livre déjà un CSV correct ?

Non, tant que le CSV arrive de façon fiable et que le fournisseur reste réactif en cas d'anomalie. L'EDI apporte une grammaire normalisée et un cycle d'accusés, ce qui n'a de valeur que si le volume ou le nombre de partenaires rend le suivi manuel impossible. Imposer de l'EDIFACT à un fournisseur qui n'en fait pas revient à lui faire financer un prestataire pour un problème que vous n'avez pas.

Quelle fréquence de collecte choisir pour un flux de prix ?

Celle à laquelle le fournisseur publie réellement, pas celle que vous souhaiteriez. La date de dernière modification des fichiers déposés sur deux ou trois semaines donne le rythme effectif. Une collecte plus fréquente que la publication remplit le journal et masque les vraies absences de fichier.

Que faire quand un import n'a rien trouvé à l'heure prévue ?

Le traiter comme une anomalie, pas comme un succès. Une fenêtre de disponibilité assortie d'une alerte distingue les deux cas : le fichier est en retard, ou il ne viendra pas. Sans cette distinction, une chaîne d'import peut rester muette des semaines pendant que le catalogue vieillit.

Peut-on rejouer un import déjà passé sans dupliquer les données ?

Oui, à deux conditions : conserver les fichiers sources dans une archive datée plutôt que de les supprimer après lecture, et écrire de façon idempotente — les enregistrements sont rapprochés sur un identifiant stable puis mis à jour, jamais ajoutés aveuglément. Le rejeu devient alors une opération sans risque.