« L’intégration transparente à un ERP » est une promesse standard qui, dans la pratique, s’accompagne d’un projet de trois mois. Nous publions notre guide des API afin que votre service informatique puisse vérifier, avant la signature du contrat, quelles données seront réellement interrogées. Voici ce que vous devez savoir avant de vous lancer dans un projet d’intégration.
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
- des 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 la due diligence)
En théorie, toutes ces données sont disponibles dans votre ERP. Dans la pratique, elles sont réparties entre 4 et 7 modules : gestion des articles (MM), production (PP), qualité (QM), fournisseurs (LFA1), parfois un module EHS distinct pour les données environnementales, parfois un système PLM pour les formulations.
La question d’intégration n’est pas : « Votre ERP fournit-il des données à un DPP ? » Elle est : « Comment rassemblez-vous les données issues de 5 sous-systèmes pour former un ensemble de données cohérent ? »
Trois modèles d’intégration éprouvés
Modèle 1 : OData / REST-Pull
Fonctionne bien avec les ERP modernes (SAP S/4HANA Cloud, Dynamics 365, Odoo). Le fournisseur de DPP extrait les données via OData ou REST. De manière incrémentielle, planifiée ou déclenchée par des événements.
Avantages : peu de développement de votre part, vous fournissez les identifiants de lecture, le fournisseur se charge de la transformation.
Inconvénients : ne fonctionne pas avec les anciennes installations SAP ECC sans couche API supplémentaire. Vous devez mettre en place une gouvernance des demandes d’accès aux données.
Modèle 2 : intégration basée sur les événements
SAP Event Mesh, Apache Kafka, RabbitMQ. Votre ERP publie des événements de modification, le fournisseur DPP les consomme.
Avantages : quasi en temps réel, évolutif de manière élégante, découplé.
Inconvénients : la mise en place est complexe et nécessite une infrastructure dont ne disposent pas tous les services informatiques. Généralement surdimensionné pour les petites entreprises.
Modèle 3 : middleware / ETL
Vous disposez d’une couche d’intégration (Mulesoft, Boomi, Informatica, Azure Data Factory) entre l’ERP et les systèmes externes. Le middleware fait office d’interface : le fournisseur DPP communique avec le middleware, jamais directement avec l’ERP.
Avantages : les investissements existants sont valorisés, la gouvernance est stable, aucun accès direct à l’ERP pour des tiers.
Inconvénients : vos coûts liés au middleware évoluent en conséquence.
Ce que nous faisons différemment dans nos projets concrets
De nombreux prestataires souhaitent se connecter directement à votre ERP. Nous intégrons systématiquement une étape intermédiaire: notre API accepte un schéma JSON neutre que vous pouvez alimenter à l’aide de l’outil de votre choix. Cela signifie que :
- Vous pouvez effectuer vous-même le traitement des données, avec les outils que votre équipe maîtrise
- Vous pouvez changer de fournisseur : 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 schéma complet et tous les points de terminaison sont documentés publiquement sous forme de spécification OpenAPI à l’adresse /apidocs. 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 pratique pour 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 en ligne.
Deux semaines, pas trois mois. Le point crucial, c’est 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 réparties dans plusieurs systèmes: SAP contient 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 est la « source de vérité » pour chaque champ.
Certificats au format PDF: les fournisseurs transmettent les certificats GOTS, OEKO-TEX ou REACH sous forme de scans PDF. Ce n’est pas une source de données structurée. Solution : les organismes de certification proposent de plus en plus souvent des requêtes via API (OEKO-TEX est en tête, GOTS est à la traîne). Ou bien : saisir manuellement les données, 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 formulation complète. Cela ne constitue presque jamais un obstacle, mais doit être clarifié dès le début.
Données CO₂ fournies par les fournisseurs: votre fournisseur indique une valeur moyenne pour l’ensemble de son portefeuille, et non par lot. Solution : accepter cette situation temporairement, 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 en avez besoin de plus. Solution : traduction automatique avec base de données terminologique ; nous avons consacré un article distinct à ce sujet.
Les questions à 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’un investissement dans un middleware qui devrait être exploité ?
- Existe-t-il déjà une couche API opérationnelle au-dessus de votre ERP ?
Les réponses détermineront lequel des trois modèles vous convient le mieux. Elles détermineront également si un projet durera deux semaines ou six mois.