L'API convient aux données qui bougent souvent et dont le décalage se paie immédiatement : stocks, disponibilités, prix promotionnels. Le fichier convient aux données stables, aux imports fournisseurs et aux échanges avec des partenaires qui n'exposent pas d'interface. Le choix se fait flux par flux, selon la fréquence de mise à jour et le coût d'un écart, jamais globalement pour tout un projet.
API et fichiers : les cas passés en revue
Quand l'API s'impose, quand le fichier suffit
L'API quand le décalage coûte. Un stock affiché disponible alors qu'il ne l'est plus produit une commande annulée. Ce type d'écart justifie un échange continu.
Le fichier quand la donnée est stable. Une nomenclature, un référentiel de normes ou un catalogue fournisseur actualisé deux fois par an s'importe très bien en fichier, avec un contrôle avant chargement.
Le fichier aussi quand l'autre partie ne propose rien d'autre. Beaucoup de partenaires industriels échangent en fichier, et imposer une interface n'est pas toujours possible.
Ce que chaque mode fait bien
Quatre critères suffisent à situer les deux modes, et le dernier est celui qu'on oublie au moment du choix.
| Critère | API | Fichier |
|---|---|---|
| Fraîcheur | Continue ou quasi immédiate | Par cycle, selon la planification |
| Granularité | Objet par objet, champ par champ | Lot complet ou delta |
| Gestion des erreurs | Réponse immédiate, à traiter | Rapport après coup, à rejouer |
| Reprise après incident | Complexe, il faut rattraper | Simple, on relance le lot |
La dernière ligne est sous-estimée. Un échange par fichier se rejoue sans difficulté : le lot est là, on le relance. Un flux continu qui a décroché suppose de savoir ce qui est passé et ce qui ne l'est pas, ce qui demande un suivi plus fin.
C'est la raison pour laquelle nous démarrons rarement un projet avec tous les flux en temps réel, dans notre travail d'intégrateur PIM/DAM : la simplicité d'exploitation compte autant que la fraîcheur.
Le critère qui tranche : la fraîcheur attendue
Le réflexe consiste à choisir selon le volume. C'est le mauvais critère : un fichier de plusieurs centaines de milliers de lignes se traite très bien, alors qu'une poignée de valeurs très volatiles justifie une interface.
Le bon critère est le coût d'un écart. Posez la question flux par flux : si cette donnée est fausse pendant six heures, que se passe-t-il. Pour un stock sur un site marchand, la réponse est une commande impossible à honorer. Pour une nomenclature de classification, la réponse est qu'il ne se passe rien.
Un troisième cas mérite d'être nommé, parce qu'il couvre une bonne part des projets : le fichier planifié. Un export nocturne, déposé et chargé automatiquement, apporte une fraîcheur quotidienne avec la simplicité d'exploitation du fichier. C'est souvent le meilleur compromis pour les nouvelles références, les changements de statut et les tarifs.
Ce que coûte chaque mode à exploiter
Le coût de développement retient l'attention, celui d'exploitation est celui qui dure.
Il faut détecter les échecs, savoir ce qui n'est pas passé et rattraper. Sans alerte, le décalage s'installe sans que personne le voie.
Nommage, emplacement, encodage, séparateur. Un fichier déposé au mauvais format bloque le chargement, et la reprise est manuelle si rien n'est prévu.
Quels champs, dans quel ordre, avec quelles valeurs autorisées. Ce document évite la majorité des incidents, quel que soit le mode retenu.
Le troisième point est le plus important et le moins coûteux à produire. Un contrat d'échange écrit, même d'une page, économise plusieurs allers-retours en recette.
Les cas où le fichier reste le bon choix
Quatre situations justifient le fichier même quand une interface existe.
Les imports fournisseurs, livrés en tableur ou en CSV.
Les référentiels stables : normes, classifications, listes de valeurs.
Les partenaires qui n'exposent aucune interface.
Les chargements initiaux de reprise de données.
Le dernier cas est systématique. Une reprise se fait par lot, avec un rapport d'anomalies ligne par ligne et des rejeux successifs. Aucune interface ne remplace ce mode de travail sur la phase initiale d'un projet.
Un cinquième cas existe, moins avouable mais fréquent : quand l'accès à l'API d'un système tiers est facturé ou soumis à un délai de plusieurs mois, le fichier permet de démarrer sans attendre.
Ce qui fait échouer un échange, quel que soit le mode
Les incidents se ressemblent d'un projet à l'autre, et ils ne viennent presque jamais de la technologie choisie.
Trois causes dominent : un identifiant instable, qui fait recréer des doublons à chaque chargement ; un cas non prévu, comme une suppression côté source dont personne n'a défini le comportement attendu ; et un format qui change sans prévenir après une montée de version. Ces trois causes se traitent au cadrage, en écrivant le contrat d'échange, pas au moment de l'incident.
Deux dispositifs limitent les dégâts dans les deux modes. Le traitement ligne par ligne plutôt que par lot, pour qu'une anomalie isolée n'arrête pas tout. Et une alerte sur échec, faute de quoi le décalage entre systèmes s'installe silencieusement.
Le mode d'échange à privilégier selon vos flux
La composition de vos flux détermine le point de départ.
Fichier planifié pour l'essentiel, API pour les disponibilités si vous vendez en ligne. Les attributs techniques et les nomenclatures ne justifient pas le temps réel.
Fichier pour les échanges avec les négoces, qui attendent des formats normés livrés par cycle. L'API se justifie surtout côté site et portail.
API pour les stocks et les prix, indispensable dès qu'une marketplace est en jeu. Fichier pour les imports fournisseurs, qui restent majoritairement en tableur.
Dans les trois cas, écrivez le tableau des flux avant de choisir : champ, sens, fréquence, mode. C'est ce document qui rend la décision évidente.
Partenaire-intégrateur officiel Pimcore sur le marché français, nous construisons les échanges entre votre référentiel, votre ERP et vos canaux, en choisissant le mode flux par flux plutôt qu'en imposant une technologie. Pimcore étant intégralement piloté par API, les deux modes coexistent sans contournement.
Vous voulez savoir lesquels de vos flux justifient réellement du temps réel ?
Notre Blog
Nos derniers articles
Tendances, conseils, retours d’expérience : nos articles décryptent les sujets clés de votre transformation.
API ou fichier CSV : comment connecter son PIM ?
L’API convient aux données qui bougent souvent et dont le décalage se paie immédiatement : stocks, disponibilités, prix promotionnels. Le fichier convient aux données stables, aux imports fournisseurs et aux échanges avec des partenaires qui n’exposent pas d’interface. Le choix se fait flux par flux, selon la fréquence de mise à jour et le coût d’un écart, jamais globalement pour tout un projet.
Faut-il développer son propre PIM en interne ?
Développer son propre PIM revient à construire une base de données produit avec une interface de saisie, ce qui se fait vite. Le coût apparaît ensuite, sur les fonctions que personne n’avait chiffrées : règles de complétude par canal, statuts de traduction, gestion des médias et de leurs déclinaisons, droits par rôle, exports par plateforme, montées de version. Le projet se juge donc sur trois ans, pas sur la première livraison.
DAM ou GED : lequel pour vos fichiers produits ?
Une GED conserve les documents de l’entreprise et en assure la traçabilité : contrats, procédures, pièces réglementaires, avec versions, archivage et valeur probante. Un DAM organise les fichiers destinés à être diffusés : visuels, plans, notices, certificats, avec métadonnées, déclinaisons par canal et droits d’usage. Les deux se croisent sur un point, le document technique produit, et ce croisement explique la plupart des confusions.