Le poids d’un produit figure dans la gestion des stocks. La part de matériaux recyclés est indiquée dans le système de formulation. Le certificat du fournisseur est disponible au format PDF sur un lecteur réseau. La fiche produit a besoin de ces trois informations dans un seul enregistrement, et c’est précisément là que réside le projet d’intégration, et non dans la connexion entre deux systèmes.
L’« intégration ERP transparente » est une promesse standard qui, dans la pratique, se traduit par un projet de trois mois. Nous publions notre guide afin que votre service informatique puisse vérifier, avant la signature du contrat, quelles données sont réellement requises. Cet article présente les données dont le passeport a besoin issues de vos systèmes, les trois voies par lesquelles elles nous parviennent et explique pourquoi cela peut être réalisé en deux semaines.
Ce que votre ERP doit réellement fournir
Pour créer un DPP, nous avons besoin, pour chaque produit :
- des données de base: référence, désignation, variantes, poids, dimensions, images
- Données de nomenclature: composants avec quantités et taux de matériaux recyclés
- Données d’origine: lieu de production, numéro de lot, date de production
- Données environnementales: CO₂eq par unité, consommation d’eau, consommation d’énergie
- Données fournisseurs: qui fournit quel composant (pour les obligations de diligence)
En théorie, toutes ces données sont disponibles dans votre ERP. En pratique, elles sont réparties entre 4 et 7 modules : gestion des stocks, production, qualité, base de données fournisseurs, parfois un module distinct pour les données environnementales, parfois un système dédié aux formulations et aux nomenclatures.
La question de l’intégration n’est pas : « Votre ERP fournit-il des données à un DPP ? » Elle est plutôt : « Comment rassemblez-vous ### les données issues de 5 sous-systèmes pour former un ensemble cohérent ? »
Trois méthodes éprouvées
### Méthode n° 1 : extraire les données de l’ERP
Cela fonctionne bien avec les ERP modernes (SAP S/4HANA Cloud, Dynamics 365, Odoo). Le fournisseur du DPP récupère les données via l’interface de l’ERP (techniquement OData ou REST). Seules les modifications sont transférées, selon un calendrier défini ou déclenchées par un événement.
Avantages : peu de développement de votre part ; vous fournissez un accès en lecture, le prestataire se charge de la conversion.
Inconvénients : ne fonctionne pas avec les anciennes installations SAP ECC sans couche d’interface supplémentaire. Vous devez définir des règles claires pour déterminer qui est autorisé à consulter quelles données.
Méthode 2 : transmission des modifications
Votre ERP signale chaque modification sous forme d’événement (via SAP Event Mesh, Apache Kafka ou RabbitMQ), que le fournisseur de DPP réceptionne.
Avantages : quasi en temps réel, évolutif, les systèmes ne dépendent pas les uns des autres.
Inconvénients : la mise en place est complexe et nécessite une infrastructure dont ne disposent pas tous les services informatiques. Généralement excessif pour les petites entreprises.
Méthode n° 3 : utiliser la couche d’intégration existante
Vous disposez déjà d’une ### couche d’intégration(Mulesoft, Boomi, Informatica, Azure Data Factory) entre l’ERP et les systèmes externes. Cette couche fait office d’interface : le fournisseur de DPP communique avec elle, jamais directement avec l’ERP.
Avantages : les investissements existants sont valorisés, les règles restent stables, aucun accès direct à l’ERP pour des tiers.
Inconvénients : vos coûts liés à la couche d’intégration augmentent en conséquence.
Ce que nous faisons différemment dans des projets concrets
De nombreux prestataires souhaitent se connecter directement à votre ERP. Nous intégrons systématiquement une étape intermédiaire: notre interface accepte un format de données neutre (un schéma JSON) que vous alimentez à l’aide de l’outil de votre choix. Cela signifie :
- Vous pouvez effectuer vous-même le traitement des données, avec les outils que votre équipe maîtrise
- Vous pouvez changer de prestataire : le format neutre est portable
- Vous pouvez récupérer l’intégralité de votre base de données à tout moment, au format CSV, XLSX, JSON-LD et SQL, ainsi que via l’API REST
- Nous fournissons un validateur d’importation qui vérifie vos données avant leur téléchargement
Le format complet et toutes les requêtes sont décrits publiquement dans le document « Documentation de l’API », sous la forme d’une spécification d’interface conforme à OpenAPI. Votre service informatique peut tester l’interface avant la signature d’un contrat - y compris les exemples de requêtes, les réponses d’erreur et les détails d’authentification.
Calendrier de mise en œuvre de cette approche :
- Jours 1 à 2: atelier de mappage. Quel champ ERP correspond à quel champ DPP ?
- Jours 3 à 5: premières exportations JSON depuis l’ERP, via notre validateur.
- Jours 6 à 8: correction des erreurs (champs manquants, codages incohérents).
- Jours 9 à 10: les premiers DPP sont mis en production.
Deux semaines, et non trois mois. Le point crucial réside dans l’atelier de mappage : c’est là que se joue la qualité des données.
Ce qui peut mal tourner : les pièges les plus courants
Données de base produit dans plusieurs systèmes: SAP détient la référence article, le PIM les images et les textes marketing, le PLM la nomenclature. Personne n’a une vue d’ensemble cohérente. Solution : définissez avant le projet quel système fait autorité pour chaque champ.
Certificats au format PDF: les fournisseurs transmettent les certificats GOTS, OEKO-TEX ou REACH sous forme de scans PDF. Il ne s’agit pas d’une source de données structurée. Solution : les organismes de certification proposent de plus en plus souvent une consultation via une interface (OEKO-TEX est en tête, GOTS est à la traîne). Ou bien : saisissez les informations manuellement, mais en indiquant la date de validité, afin qu’aucun certificat périmé n’apparaisse dans le DPP.
Confidentialité de la formulation: notamment dans les secteurs des cosmétiques, de l’alimentation et des produits pharmaceutiques, la formulation complète relève du secret d’entreprise. Le DPP doit-il la rendre publique ? Solution : le modèle à trois niveaux de l’ESPR. La catégorie de produit est publique, les autorités ont accès à la composition complète. Cela ne constitue presque jamais un obstacle, mais doit être clarifié dès le début.
Données relatives au CO₂ fournies par les fournisseurs: votre fournisseur communique une valeur moyenne pour l’ensemble de son portefeuille, et non par lot. Solution : accepter cette situation à titre provisoire, puis adapter les contrats fournisseurs à long terme. L’ESPR exige des valeurs spécifiques par produit à compter d’une date de référence, mais la pratique actuelle constitue un compromis.
Versions linguistiques locales: votre ERP ne contient que la désignation du produit en allemand et en anglais. Pour les 27 pays de l’UE, vous avez besoin de plus. Solution : traduction automatique avec une base de données terminologique ; nous avons consacré un article distinct à ce sujet.
Les questions que vous devriez vous poser avant le projet
Avant d’envoyer un appel d’offres à trois prestataires, répondez en interne aux questions suivantes :
- Combien de produits/références doivent disposer de DPP ? (10, 10 000, 1 million ?)
- Quels systèmes contiennent aujourd’hui des données pertinentes pour les DPP ?
- Quel service gère chacun de ces systèmes ?
- Disposez-vous d’une couche d’intégration qui devrait être utilisée ?
- Existe-t-il déjà une interface opérationnelle via votre ERP ?
Les réponses détermineront laquelle des trois approches vous convient le mieux.
Les réponses détermineront si un projet durera deux semaines ou six mois.
Questions concernant cet article
L'interface REST est-elle suffisante, ou avons-nous besoin d'un middleware ?
L’interface suffit. Les trois modèles se distinguent par l’endroit où la transformation a lieu, et non par ce que nous recevons : notre interface accepte un schéma JSON neutre, quel que soit l’outil utilisé pour le générer. Une extraction depuis un ERP moderne, un flux d’événements et une couche d’intégration existante aboutissent tous au même point de terminaison. Un middleware est utile si vous en exploitez déjà un et si celui-ci doit rester le contrat vis-à-vis des tiers. S’il n’en existe pas aujourd’hui, n’en achetez pas pour le passeport produit.
Quelles décisions seront prises lors de l'atelier de cartographie ?
Quel champ ERP correspond à quel champ de passeport - et quel système fait office de source de référence lorsque plusieurs systèmes contiennent la même valeur. L’atelier se déroule les jours 1 et 2 et constitue le point crucial de l’ensemble du projet, car c’est là que les décisions relatives à la qualité des données sont prises, et non plus tard dans le code. Veillez à faire participer les personnes chargées de la maintenance des systèmes, et pas seulement les responsables du projet : les services chargés des données de base, de la production, de la qualité et des achats font rarement partie d’un même service. Tout ce qui suit, à savoir les exportations, la validation et la correction des erreurs, relève du savoir-faire technique.
Nos certificats ne sont disponibles que sous forme de fichiers PDF numérisés. Que devons-nous en faire ?
Un scan ne constitue pas une source de données structurée et n’est donc pas utilisable pour le passeport. Deux solutions sont possibles : d’une part, les opérateurs de certification proposent de plus en plus souvent des requêtes via API ; d’autre part, lorsqu’il n’y en a pas, vous saisissez les valeurs manuellement, mais toujours en indiquant la date de validité, afin qu’aucun certificat périmé ne figure dans un passeport publié. Prévoyez cette procédure manuelle comme une tâche récurrente, et non comme une tâche ponctuelle.
Notre service informatique pourrait-il vérifier l'interface avant que nous ne signions quoi que ce soit ?
Oui. Le schéma complet et tous les points de terminaison sont disponibles sous forme de spécification OpenAPI à l’adresse Documentation de l’API, avec des exemples de requêtes, de réponses d’erreur et de détails d’authentification. Aucune de ces informations n’est soumise à une discussion commerciale ; votre équipe d’intégration peut donc évaluer l’effort nécessaire avant même la signature d’un contrat. Si un fournisseur ne divulgue pas son interface à ce stade, cela constitue également une réponse en soi.
Que deviennent nos données lorsque nous changeons de fournisseur ?
Ils sont compatibles. L’interface accepte un schéma JSON neutre au lieu d’un format propriétaire, et l’ensemble de votre base de données est restitué au format CSV, XLSX, JSON-LD et SQL, ou via l’API REST. C’est voulu : le format que vous alimentez est portable ; un changement ne nécessite donc qu’une exportation, et non la création d’un nouveau modèle. Posez la même question à chaque prestataire avant l’atelier de mappage, car vos noms de champs figureront ensuite dans son modèle.
Combien de temps dure réellement une connexion ?
Dans les projets que nous accompagnons, deux semaines : deux jours de cartographie, trois jours jusqu’aux premières exportations via notre validateur, trois jours de correction des erreurs, deux jours jusqu’à la publication des premiers passeports. Le plus long n’est jamais le code, mais ce que le validateur détecte : des champs manquants, des codages incohérents, des valeurs dont personne ne se sent responsable. Prévoyez ces jours-là, au lieu de les raccourcir. Un projet qui les ignore publie également ces lacunes.
Devons-nous intégrer tous les produits en même temps ?
Non. Commencez par les produits qui nécessitent un passeport en premier lieu, ainsi que par un système source : le schéma neutre prend en charge aussi bien un catalogue partiel qu’un catalogue complet, et les importations sont reproductibles ; les exécutions ultérieures mettent donc à jour le stock. Cela permet également de limiter la portée de l’atelier de mappage à un volume suffisamment restreint pour pouvoir le mener à bien en deux jours. L’extension ultérieure relève d’une tâche de mappage, et non d’un nouveau projet.
