Tous les fournisseurs de DPP parlent d' « intégration ». Presque rien ne le pense.

La vraie question que se posent les décideurs

Lorsqu'un responsable de la conformité ou un directeur informatique évalue une plateforme DPP, la conversation commence généralement par les exigences ESPR et se termine par une discussion sur les protocoles d'API. Ce n'est pas le bon niveau d'abstraction.

La question qui compte réellement est plus simple : votre équipe doit-elle saisir deux fois les données des produits ? Une fois dans votre ERP et une fois dans la plateforme DPP ?

Si la réponse est oui, vous vous êtes acheté un flux de travail de conformité qui fonctionne parallèlement à vos opérations, et les systèmes parallèles divergent. Une composition matérielle qui est mise à jour dans SAP mais qui n'est pas reflétée dans le DPP n'est pas qu'un inconvénient. En vertu de l'ESPR (règlement UE 2024/1781), le DPP doit refléter l'état actuel du produit, et non son état au moment de la première publication. S'il n'est pas à jour, c'est que vous n'êtes pas en conformité.

C'est pourquoi l'architecture d'intégration d'une plateforme DPP est plus importante que son interface.

Ce que signifie réellement « intégration »

Le marché a l'habitude de tout appeler intégration. Un modèle CSV est appelé intégration. Un connecteur intergiciel tiers est appelé intégration. Un webhook qui se déclenche une fois par jour est appelé intégration.

Il y a une différence entre un plugin et une couche de plateforme.

Fluxy.One a conçu sa connexion SAP comme une couche native de la plateforme, et non comme un connecteur externe situé entre deux systèmes, ni comme une dépendance intergicielle avec ses propres modes de défaillance et conditions de licence. L'intégration de SAP Business One est opérationnelle aujourd'hui : synchronisation bidirectionnelle des données de base des produits et des enregistrements de lots, sans étapes d'exportation manuelles et sans développement ABAP personnalisé du côté SAP.

Pour les entreprises utilisant SAP ECC, l'ancienne version encore largement déployée, la même architecture arrivera au deuxième trimestre 2026, fonctionnant via SAP Service Layer. Encore une fois, aucun développement personnalisé n'est requis de part et d'autre. La plateforme absorbe la complexité ; votre environnement SAP reste inchangé.

Odoo est en ligne. L'importation au format CSV et SFTP couvre tous les ERP capables de produire une exportation standard, c'est-à-dire la plupart d'entre eux, et pour de nombreux fabricants de taille moyenne, ce sera la principale voie d'intégration pendant la première ou les deux premières années. Cela vaut la peine d'être pris au sérieux : une importation CSV bien structurée avec validation des champs et signalement des erreurs est plus fiable qu'une connexion API mal implémentée, et l'importation en masse de Fluxy.One gère jusqu'à 10 000 enregistrements par lot avec les deux.

L'intégration de Microsoft Dynamics est confirmée pour juillet 2026, conformément à la date limite de certification des fournisseurs de services DPP de l'UE.

Ce que signifie réellement le bidirectionnel dans la pratique

Prenons une situation concrète. Un fabricant met à jour la composition d'un matériau dans SAP : un fournisseur a modifié un composant, la nomenclature est révisée, l'enregistrement est enregistré. Dans le cadre d'une intégration à sens unique, rien ne se passe du côté du DPP. Quelqu'un doit remarquer le changement, se connecter à la plateforme DPP, trouver les SKU concernés et les mettre à jour manuellement. Dans un catalogue de 300 modèles, c'est une nuisance gérable. Sur un catalogue de 1 300, il s'agit d'un risque de conformité, car l'écart entre ce que SAP sait et ce que dit le DPP se creuse chaque fois qu'un enregistrement change sans que personne ne le remarque.

L'intégration bidirectionnelle comble cet écart sur le plan structurel, et non par le biais d'un processus. Lorsqu'un enregistrement de produit change dans l'ERP, la plateforme DPP le voit. Lorsqu'un DPP est publié, validé, archivé ou signalé par un contrôle de conformité, l'ERP reflète ce statut. L'équipe des opérations arrête de gérer deux versions du même produit.

Comme Fluxy.One repose sur les normes GS1 de manière native, et non comme une couche superposée à un modèle de données propriétaire, les changements d'état sont enregistrés à l'aide d'EPCIS 2.0, la norme GS1 pour les données d'événements de la chaîne d'approvisionnement. EPCIS 2.0 (Electronic Product Code Information Services) capture ce qui est arrivé à un produit, où, quand et pourquoi, dans un format lisible directement par les autres systèmes conformes à la norme GS1, les autorités douanières et les organismes de surveillance du marché. Cela signifie que l'enregistrement des événements d'un DPP en cours de publication, de mise à jour ou d'archivage n'est pas un journal spécifique à la plateforme. Il s'agit d'un flux d'événements standardisé et interopérable. Pour les entreprises opérant sur plusieurs marchés ou partenaires commerciaux, cette distinction est importante.

Cela est particulièrement important dans le cadre de l'ESPR, car le règlement exige que le DPP reflète l'état actuel du produit, et non son état au moment de la première publication. Un DPP qui était exact en janvier et erroné en mars n'est pas un DPP conforme en mars. La synchronisation bidirectionnelle n'est pas une fonctionnalité pratique. C'est ainsi que vous tenez le registre à jour sans ajouter d'effectifs.

Une limite pratique mérite d'être mentionnée : les systèmes ERP conservent bien les données de base des produits. Ils contiennent la composition des matériaux, les identifiants des lots, les codes des installations de production et les structures des variantes. Ce qu'ils ne détiennent généralement pas, ce sont des données spécifiques au DPP : pourcentages de contenu recyclé au format requis par ESPR, GLN (Global Location Numbers) des fournisseurs tels que définis par GS1, ou enregistrements d'événements du cycle de vie tels que les réparations et le transfert de propriété. Ces données doivent être ajoutées séparément à la couche DPP, généralement lors de l'intégration et de la collecte des données sur les fournisseurs. L'intégration automatise ce que l'ERP sait déjà. Le reste est un enrichissement ponctuel, et non une saisie manuelle continue.

Les données DPP circulent vers l'extérieur, pas seulement vers l'intérieur

La plupart des fabricants qui envisagent le DPP se concentrent sur le problème de saisie, à savoir intégrer les données des produits dans le passeport sans avoir à reconstruire leurs opérations. C'est le bon point de départ. Mais il ne s'agit pas d'une vue d'ensemble.

L'ESPR nécessite la collecte de données structurées et validées sur chaque produit de votre catalogue : origine des matériaux par lot, identifiants des fournisseurs, contenu recyclé, enregistrements des installations de production, événements du cycle de vie. Ces données doivent être lisibles par machine, interrogeables et conservées pendant au moins dix ans. Il s'agit d'une obligation de conformité.

Il s'agit également d'un ensemble de données que la plupart des entreprises ne possèdent pas actuellement sous cette forme : il est stocké de manière centralisée, validé par rapport à un schéma réglementaire et lié à des SKU individuels et à des lots de production.

Un fabricant qui construit correctement cette infrastructure se retrouve avec quelque chose d'utile au-delà du code QR sur le produit. Composition des matériaux dans l'ensemble du catalogue, en un seul endroit. Origine du fournisseur par lot, non enfouie dans un système d'approvisionnement. Événements du cycle de vie (réparations, reventes, transferts de propriété) ajoutés par les acteurs autorisés au fil du temps et enregistrés en tant qu'événements EPCIS 2.0. Ce dernier point mérite une pause : chaque changement d'état dans la durée de vie du produit est enregistré dans un journal des événements immuable et standardisé qui accompagne l'identifiant du produit, et non la plateforme. Un réparateur en Pologne et un recycleur aux Pays-Bas peuvent tous deux participer à la même chaîne d'événements, dans un format lisible par n'importe quel système conforme à la norme GS1. C'est à cela que ressemble la traçabilité de la chaîne d'approvisionnement lorsqu'elle repose sur des normes ouvertes plutôt que sur le schéma propriétaire d'un fournisseur.

Concrètement, cela se présente aujourd'hui : Fluxy.One permet d'accéder à la couche de données DPP via les API Google standard. Les entreprises qui utilisent déjà Looker Studio ou d'autres outils de l'écosystème Google peuvent se connecter sans développement personnalisé et créer leurs propres rapports en s'appuyant sur les données DPP en direct. Il ne s'agit pas d'un produit d'analyse packagé, mais d'un accès par API à un ensemble de données structuré et validé, et ce que vous créez avec ce produit dépend des questions que vous posez.

Avant la fin de 2026, la plateforme ajoutera une API d'analyse dédiée et un bac à sable pour les développeurs pour une intégration et des tests personnalisés. C'est à ce moment-là que la couche de données devient correctement programmable pour les équipes extérieures à l'écosystème Google.

Les entreprises qui considèrent le DPP comme une infrastructure de données plutôt que comme une case à cocher de conformité sont celles qui retirent quelque chose du processus. La réglementation vous oblige à collecter les données. Ce que vous en ferez ensuite est facultatif, mais l'option est là.

Cinq questions à poser à tout fournisseur de DPP à propos de l'intégration

1 - La connexion ERP est-elle intégrée à la plateforme ou dépend-elle d'un connecteur ou d'un intergiciel tiers ? Les connecteurs tiers présentent leurs propres considérations en matière de fiabilité, de maintenance et de licence.

2 - La synchronisation est-elle bidirectionnelle ou les données ne circulent-elles que dans un sens ? L'importation unidirectionnelle signifie que votre ERP ne sait jamais ce qui se passe du côté du DPP.

3 - Que se passe-t-il lorsqu'une fiche produit change dans votre ERP après la publication du DPP ? Existe-t-il un chemin de mise à jour automatique ou quelqu'un doit-il le déclencher manuellement ?

4 - L'intégration est-elle incluse dans l'abonnement ou s'agit-il de frais de mise en œuvre distincts ? Les périmètres d'intégration personnalisés ont l'habitude de s'étendre.

5 - Pouvez-vous accéder à la couche de données DPP pour vos propres analyses, ou celle-ci est-elle verrouillée dans l'interface de reporting de la plateforme ?

Les réponses réduiront considérablement le champ.

Découvrez comment Fluxy.One se connecte à votre infrastructure ERP existante et ce que vous pouvez faire avec les données une fois qu'elles sont disponibles. Bénéficiez d'une consultation gratuite.

Fluxy.One est une plateforme de passeport numérique ESPR pour les produits de l'UE destinée aux fabricants, aux importateurs et aux distributeurs qui se préparent à se conformer à la réglementation de l'UE sur les produits. La plateforme couvre l'intégralité du cycle de vie du DPP, des données de base des produits et des codes QR GS1 Digital Link à la validation de la conformité réglementaire et à la traçabilité de la chaîne d'approvisionnement, avec des intégrations natives pour SAP Business One, SAP ECC, Odoo et Microsoft Dynamics, et une couche d'événements EPCIS 2.0 native à GS1 pour un enregistrement standardisé des événements de la chaîne d'approvisionnement. Les entreprises clientes peuvent connecter les outils de BI existants via les API Google standard dès aujourd'hui ; une API d'analyse dédiée et un sandbox pour les développeurs sont prévus pour le quatrième trimestre 2026. Cet article reflète la position de la réglementation et de la plateforme en mai 2026. Les lois de mise en œuvre de l'ESPR continuent de se développer ; cet article est destiné à une orientation et non à des conseils juridiques.