Échanges de données PLM : alimenter l’ERP et les distributeurs

Une recette validée ne s’arrête pas à la fiche produit. La même donnée doit repartir vers l’ERP, vers les plateformes de vos distributeurs, vers le réseau GDSN, vers votre site web. Dans beaucoup d’entreprises, ce trajet est encore assuré à la main : un export par destination, un fichier retouché à chaque envoi. C’est là que la donnée se perd, et que les fiches se font rejeter.

Le coût caché n’est pas l’export, c’est sa maintenance

Chaque destination a ses exigences propres : un format de fichier, un jeu d’unités, une liste de champs obligatoires, une façon bien à elle de nommer un allergène. Rien de tout cela n’est difficile en soi. Ce qui coûte, c’est de faire vivre l’ensemble dans la durée.

• Un distributeur ajoute un champ : il faut retoucher l’export qui le concerne.
• Une réglementation change une mention obligatoire : il faut la répercuter partout.
• La personne qui avait écrit la macro change de poste, et plus personne n’ose y toucher.

Le vrai signal d’alerte est ailleurs. Posez la question suivante à votre équipe : « la fiche de la référence 10428 est-elle partie chez ce distributeur, et à quelle date ? ». Si la réponse demande d’ouvrir une boîte mail et de retrouver un fichier, le problème n’est pas l’export. C’est qu’aucun système ne garde la trace de ce qui a été envoyé.

Un connecteur standard plutôt qu’un développement spécifique

C’est le principe retenu dans beCPG : le PLM détient la donnée produit, et des connecteurs standards l’emmènent là où elle doit aller. Ils existent déjà pour les destinations les plus courantes du secteur.

• GS1 / GDSN — génération de la fiche produit au format Catalogue Item Notification, et dépôt sur Atrify ou Synkka.
• Equadis et Salsify (SupplierXM) — publication vers les plateformes utilisées par les enseignes et le e-commerce.
• SAP — articles, nomenclatures et gammes de fabrication, au format OData pour S/4HANA ou en IDoc pour les intégrations plus anciennes.
• CSV — le passe-partout : autres ERP, MES, portail web, applications maison, tout ce qui sait lire un fichier structuré.

Les flux entrants passent par d’autres chemins, comme le portail fournisseurs ou les imports Excel et CSV, et les cubes d’analyse de beCPG lisent directement le référentiel : ce ne sont pas des connecteurs.

Le point important tient en une phrase : ces connecteurs sont des applications autonomes. Elles ne s’installent pas dans le PLM, elles l’interrogent par son API REST avec un compte dédié. Dans la première version de cet article, en 2013, nous décrivions ces échanges comme un bus de données à mettre en place. Le besoin n’a pas changé ; ce qui a changé, c’est qu’il n’y a plus de bus à développer pour publier vos fiches. Et si votre système d’information dispose déjà d’un bus ou d’une plateforme d’intégration, les connecteurs s’y insèrent : ils déposent des fichiers ou se lancent depuis l’ordonnanceur existant.

Ce qui se paramètre, et ce qui ne se code pas

Mettre un connecteur en service, c’est répondre à quatre questions : quels produits, lus comment, transformés en quoi, déposés où.

Le mappage se déclare dans un fichier de paramètres ou un classeur Excel : chaque champ attendu par la destination y est relié à un champ beCPG, langue par langue. La livraison se choisit : dépôt de fichier en local, en FTP, en FTPS ou en SFTP, ou, pour Salsify et Synkka, appel direct de l’API de la plateforme. La fréquence se planifie, et un échec déclenche un e-mail. Pour l’essentiel, ce ne sont pas des lignes de code : ce sont des paramètres, et ils se relisent.

Savoir ce qui est parti, quand, et pourquoi ça a échoué

Reste la question du départ : qui a reçu quoi. beCPG y répond avec les canaux de publication. Un canal, c’est une destination : le GDSN, un ERP, une plateforme distributeur. On y rattache les produits concernés, et à chaque envoi le connecteur réécrit le résultat directement sur la fiche produit. Il peut aussi mettre à jour la fiche après l’envoi, par exemple en changeant l’état du produit. Pour les catalogues, l’identifiant attribué par la plateforme revient dans beCPG.

La lecture est directe. Deux canaux sont au vert, un troisième est en échec, et le motif est écrit en clair : le code pays d’origine manque pour le marché visé. Ce n’est plus un rejet anonyme reçu trois jours plus tard par courriel : c’est une information posée sur la fiche, visible par la personne qui peut la corriger. Une fois le champ complété, trois actions suffisent — Réessayer les produits en échec, Réinitialiser le canal pour tout renvoyer, ou Arrêter les envois sur une référence retirée du catalogue.

C’est aussi ce mécanisme qui porte la diffusion de la fiche produit GS1 : mêmes canaux, même suivi, une destination de plus.

Trois façons d’échanger, et qui fait quoi

Les connecteurs couvrent la publication. Pour le reste, beCPG s’appuie sur deux autres mécanismes du produit standard : l’API REST, pour synchroniser l’ERP en temps réel dans les deux sens (une fiche validée part, les coûts reviennent), et l’import de masse Excel ou CSV, pour les reprises et les mises à jour, avec un import à blanc qui remonte les erreurs avant chargement. Tous ces échanges passent en HTTPS et appliquent les droits de l’utilisateur appelant.

Pour une synchronisation avec l’ERP, beCPG réalise sa moitié de l’interface : ateliers, présentation des points d’entrée, paramétrage côté beCPG et tests. Votre équipe ou votre intégrateur porte l’orchestration, le transcodage et la supervision, à moins de confier l’ensemble à beCPG. Les règles de transformation restent côté interface, ce qui préserve les montées de version, et la correspondance entre code beCPG et code ERP garantit l’unicité des articles.

Par où commencer

Inutile de tout brancher d’un coup. Prenez la destination qui vous coûte le plus de reprises manuelles aujourd’hui — souvent la première plateforme distributeur ou le GDSN — et traitez-la seule. Le reste suit le même chemin, canal par canal.

Un PLM qui ne parle pas au reste du système d’information finit par devenir un fichier de plus. La liste complète des connecteurs et leur paramétrage sont décrits dans la documentation beCPG. Pour étudier votre cas, écrivez-nous.