Puis-je lier le passeport numérique à mon système ERP ou de gestion des stocks ?

Le couplage est possible, à condition que les données soient fournies de manière structurée

Coupler un passeport numérique de produit à un système ERP ou de gestion des stocks est en principe possible, car le ESPR prescrit que le passeport numérique de produit soit construit techniquement de manière à ce que l'échange de données s'effectue de manière interopérable et lisible par machine (article 11 du ESPR, Règlement (UE) 2024/1781). Cela signifie que les données qui se trouvent déjà dans un système ERP ou de gestion des stocks — composition des matériaux, origine, pièces, numéros de lot ou de série — peuvent en principe être la source à partir de laquelle le passeport est construit. Le couplage ne réside pas alors dans une connexion directe et en direct entre deux systèmes, mais dans le fait que les mêmes données qui sont déjà tenues à jour en interne sont fournies dans un format approprié pour le passeport.

Pour quelles données cela fonctionne et pour lesquelles cela ne fonctionne pas

Il s'agit de données qui sont déjà enregistrées quelque part et qui sont pertinentes pour le passeport d'un produit spécifique : spécifications techniques, informations sur les matériaux, données de réparation et d'entretien, ou informations sur l'origine. Pour ce type de données, une fourniture structurée à partir d'un système existant est logique. Il ne s'agit pas d'un couplage systémique général et permanent prescrit par l'ESPR — le règlement n'oblige aucun fabricant ni importateur à une technologie, une API ou un logiciel spécifique. L'article 11 porte sur la configuration technique du passeport lui-même : comment le support de données, le registre et l'accès aux données sont organisés. Il ne prescrit pas comment une entreprise organise ou exporte son propre système ERP. Il est également important de noter que les données exactes qui doivent figurer dans le passeport varient selon le groupe de produits et sont élaborées par groupe de produits dans un acte délégué. Ce qui constitue un champ ERP pertinent pour un produit (par exemple un pourcentage de matériau) ne s'applique pas nécessairement à un autre groupe de produits.

Les exigences techniques s'appliquent déjà, la spécification par groupe de produits ne s'applique pas encore partout

L'ESPR lui-même, avec les exigences générales concernant le passeport numérique de produit (article 10) et sa configuration technique (article 11), est établi et constitue le cadre dans lequel chaque passeport de produit devra fonctionner à l'avenir. Le moment où un produit concret a besoin d'un passeport et les données exactes qui doivent y figurer sont réglés séparément par groupe de produits. Pour de nombreux groupes de produits, cette spécification n'a pas encore été publiée ou n'est pas encore en vigueur. Jusqu'au moment où il est établi pour un groupe de produits quelles données sont obligatoires, il n'y a donc pas encore d'obligation concrète de mettre en place un couplage ou un flux de données à partir d'un système ERP — il est néanmoins judicieux de savoir d'avance où se trouveraient les données pertinentes en interne, afin qu'au moment du démarrage d'une obligation, il ne soit pas nécessaire de recommencer à zéro.

Comment cela est mis en pratique

La première étape consiste à vérifier quelles données sont déjà présentes dans votre système ERP ou d'inventaire et qui concernent ce qu'un passeport contient généralement : identification du produit, composition matérielle, origine, composants, informations de garantie ou de réparation. Ensuite, il est utile d'examiner comment exporter ces données du système — sous forme de fichier, de rapport ou via une liaison structurée — dans un format lisible et transférable, conformément à la configuration ouverte et interopérable que l'article 11 prescrit pour le passeport. Par la suite, il est important de relier les données à l'identification unique du produit que le passeport exige selon l'article 10, de sorte que chaque passeport soit démontrablement associé au bon produit. Comme un passeport doit rester à jour tout au long de la durée de vie d'un produit, il est pratique de réfléchir également à un processus récurrent : comment une modification dans le système ERP (par exemple un composant adapté ou un nouveau fournisseur) est-elle intégrée dans le passeport à un moment donné. Cela n'a pas besoin d'être en temps réel — une fourniture périodique, par exemple lors de modifications ou de nouvelles productions, est suffisante dans la plupart des cas. Une plateforme qui compile les passeports à partir de données fournies, comme prodpas.eu, reçoit généralement ces données précisément de cette manière : sous forme de fourniture structurée provenant de l'administration existante d'un fabricant ou d'un importateur, et non comme une liaison en direct permanent entre deux systèmes.

D'où cela découle : articles 10 et 11 du ESPR

L'obligation d'interopérabilité et de lisibilité par machine du passeport produit numérique figure à l'article 11 du ESPR (Règlement (UE) 2024/1781), qui régit la configuration technique et le fonctionnement du passeport. L'article 10 du même règlement décrit les exigences générales auxquelles un passeport doit satisfaire, y compris le lien à une identification unique du produit. Ensemble, ces articles forment la base pour laquelle les données sources provenant d'un système existant, à condition d'être fournies de manière structurée, peuvent constituer une entrée appropriée pour un passeport — sans que le règlement ne prescrive quelle technique ou quel système une entreprise utilise en interne pour cela.

Pour ceux qui veulent se préparer dès maintenant, le mieux est de commencer par un aperçu des données produit qui se trouvent dans votre propre système ERP ou d'inventaire et du format dans lequel elles peuvent être exportées. Une fois qu'il est clair pour votre propre groupe de produits quelles données un passeport doit contenir, cette fourniture à partir de l'administration existante est généralement le point de départ pratique.