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

Le couplage est possible, dans les limites du format de données

Un couplage entre le passeport numérique de produit et un système ERP ou de gestion des stocks propre à l'entreprise est en principe possible, mais la manière dont il fonctionne dépend de la conception technique qui sera établie pour le passeport. Le ESPR (Règlement (UE) 2024/1781) prescrit à l'article 10 les exigences auxquelles doit satisfaire un passeport numérique de produit, et à l'article 11 comment il est construit et fonctionne sur le plan technique. Il en résulte qu'un passeport doit être lisible par machine et interopérable — non que chaque fabricant soit libre de construire un couplage propre à un système quelconque selon ses souhaits. Le couplage s'effectue en pratique via la plateforme qui assemble et héberge le passeport, et via le format de données qui est convenu à cet effet.

Pour qui c'est pertinent, et pour quoi cela ne l'est pas

Cette question concerne les fabricants et les importateurs de demi-produits en aluminium qui doivent fournir des données pour un passeport de produit — les fabricants de profilés, les fonderies, les producteurs d'aluminium d'emballage. Pour eux, il est pertinent de savoir si leurs données de production existantes (composition du matériau, numéros de lot, origine, spécifications techniques) peuvent circuler automatiquement vers le passeport, au lieu d'être retapées manuellement. Il ne s'agit pas de savoir si une entreprise est obligée de construire un couplage ERP — cette obligation n'existe pas. Le ESPR régit ce que le passeport doit pouvoir faire (interopérable, lisible par machine, accessible via un support de données tel qu'un code QR), non la manière dont une entreprise individuelle organise son propre logiciel interne. Une entreprise sans système ERP peut tout aussi bien fournir des données via un formulaire ou un fichier ; une entreprise disposant d'un système ERP complet peut éventuellement fournir ces données plus efficacement, mais n'y est pas obligée.

Quand cela s'applique : date non fixée

Il n'y a pas encore de date fixe à laquelle ces obligations s'appliqueront aux demi-produits en aluminium. L'acte délégué qui doit concrétiser ceci pour ce groupe de produits est attendu en 2027 selon le plan de travail de la Commission européenne pour 2025-2030. Ce n'est qu'avec cet acte qu'il sera clair quels champs de données sont obligatoires, dans quel format, et avec quelles spécifications techniques pour l'échange — donc ce n'est qu'à ce moment-là qu'il sera précisément clair comment un couplage avec un système ERP peut fonctionner techniquement. Jusque-là, il est établi que l'article 10 et l'article 11 du ESPR forment le cadre général : l'interopérabilité et la lisibilité par machine sont le point de départ, la mise en œuvre technique concrète suivra ultérieurement. Dès que l'acte délégué sera publié, la date d'application prévue sera complétée ici.

Ce que cela signifie pour l'approche

Pour ceux qui veulent déjà en tenir compte dès maintenant, l'ordre logique est le suivant : d'abord, identifier les données relatives à un produit en aluminium qui sont déjà enregistrées dans le système propre — composition, origine, données de lot, caractéristiques techniques. Ensuite, il est judicieux de vérifier si ces données sont disponibles de manière structurée et exportable (une exportation vers un fichier, un couplage via une interface) plutôt que seulement sur papier ou dispersées sur plusieurs départements. Après cela, il s'agit de se conformer au format que demande la plateforme qui assemble le passeport : alupas.eu assemble le passeport sur la base des données fournies par le fabricant ou l'importateur, et la manière dont cette fourniture fonctionne techniquement — saisie manuelle, téléchargement de fichier ou couplage automatisé — est une question qui sera coordonnée avec la plateforme dès que les spécifications techniques de l'acte délégué seront connues. Une entreprise qui tient déjà ses données de produits de manière claire et structurée aura moins de travail à faire ultérieurement pour fournir ces données, que ce soit via un couplage ERP ou autrement.

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

L'article 10 du ESPR décrit les exigences auxquelles un passeport numérique de produit doit satisfaire, notamment l'accessibilité des données et le lien avec un support de données. L'article 11 porte spécifiquement sur la conception technique et le fonctionnement du système de passeport : comment les données sont enregistrées, stockées et échangées, en vue de l'interopérabilité entre différents systèmes et acteurs de la chaîne. Les deux articles laissent les normes et formats techniques concrets à des règles d'exécution ultérieures ; ils fixent cependant le principe selon lequel le passeport doit être lisible par machine et fonctionner indépendamment du système, ce qui forme la base de tout futur lien avec un système externe tel qu'un progiciel ERP.

Si vous souhaitez dès maintenant vous préparer, le mieux est de mettre en ordre vos propres données de produits de manière structurée et numérique, afin que la fourniture — sous quelque forme que ce soit — soit par la suite une question de connexion plutôt que de réorganisation.

Sur quoi cela repose

Le règlement lui-même figure sur EUR-Lex. Nous faisons référence à chaque affirmation ; vous n'avez pas besoin de nous croire sur parole.

Ce que vous devez concrètement faire

Ce qu'on attend de vous

Le passeport doit être transférable en tant que dataset, non seulement en tant qu'écran

L'article 10 du ESPR (Règlement (UE) 2024/1781) décrit le passeport numérique de produit comme un ensemble de données lisibles et transférables par des moyens électroniques. Il s'agit d'une exigence différente d'« une belle page qui s'ouvre après le scan d'un code QR ». Pour une entreprise de 10 à 100 salariés, cela signifie que les données contenues dans le passeport doivent également être disponibles en tant que données structurées — non pas uniquement sous forme de texte sur une page web. Le fait que celles-ci soient ou non couplées à son propre système ERP ou de gestion des stocks est un choix que l'entreprise fait elle-même ; la réglementation n'oblige pas à un couplage, mais elle oblige à une dataset qui s'y prête.

L'interopérabilité entre les systèmes est un principe fondateur, non un choix technique du fournisseur

L'article 11 du ESPR porte sur la conception technique et le fonctionnement du passeport numérique de produit et mentionne l'interopérabilité comme l'un des principes auquel le système de passeport doit se conformer. Cela touche directement la question de savoir si le couplage avec son propre système est possible : un passeport qui a été conçu selon cet article est en principe destiné à permettre l'échange de données entre systèmes, non pas à être un environnement fermé. En pratique, une entreprise le remarque principalement dans la question des formats de données et des codes d'identification que la plateforme utilise, et du fait que ceux-ci s'alignent sur ce que son propre système ERP utilise déjà.

Le code d'identification unique est le lien entre le passeport et l'administration interne

Un couplage entre un passeport de produit et un système interne tient ou tombe sur la base d'un code d'identification cohérent par produit ou par lot. Sans une clé de couplage univoque, un couplage ERP reste en pratique difficile à automatiser, même si cela ne figure nulle part littéralement dans le texte de l'article 10 ou 11. La manière dont ce code d'identification est construit et attribué est décrite sur la page concernant comment vous attribuez à chaque produit un code d'identification unique. Pour une entreprise qui vend de l'aluminium par lot, cela est également lié à la question de savoir si l'enregistrement se fait par lot ou à l'unité, ce qui est développé plus en détail sur la page concernant l'enregistrement par lot ou à l'unité.

Le passeport persiste, même si le système interne change

Un système ERP est à un moment donné remplacé, migré ou mis à jour. Le passeport de produit lui-même n'en suit pas automatiquement les modifications — il est hébergé pendant dix ans, indépendamment de ce qui se passe en interne avec la gestion des stocks. Cette distinction est pertinente lors de la mise en place d'un couplage : le couplage est une commodité pour la propre gestion de l'entreprise, non un remplacement de l'obligation que le passeport reste accessible. Plus d'informations sur cette période de conservation se trouvent sur la page concernant combien de temps un passeport doit rester disponible.

Où cela s'avère problématique en pratique

Quelques situations reviennent régulièrement chez les entreprises qui envisagent un couplage entre passeport et système interne :

Le système ERP est considéré comme la source, alors que le passeport doit rester la source. Une fois que les données sont publiées, le passeport est la vérité consultable pour l'extérieur. Les modifications du système interne ne s'y répercutent pas automatiquement, et celui qui confond cela court le risque que le passeport et l'administration interne divergent.
Les mutations de stock sont confondues avec les modifications du passeport. Un système interne de gestion des stocks change quotidiennement : quantités, localisations, statuts des lots. Le passeport de produit enregistre les caractéristiques du produit, non la position de stock actuelle. Celui qui mélange ces deux types de données dans un seul couplage crée une complexité inutile — et parfois des ajustements injustifiés à un passeport déjà publié. La manière précise dont cette modification après publication fonctionne est décrite sur la page concernant modification des données après publication.
Un couplage est construit sans tenir compte du code d'identification de la plateforme. Si le numéro d'article interne ne correspond pas au code utilisé dans le passeport, cela entraîne une étape manuelle de réconciliation qui annule largement l'appairage dans la pratique.
On suppose qu'un couplage ERP assure également la création du code QR physique sur le produit. Ce sont deux composants distincts : le couplage de données gère l'échange d'informations, l'apposition du support sur l'aluminium lui-même est un processus séparé. À ce sujet, voir comment le code QR arrive sur le produit.
On suppose que le système propre va bientôt « générer » lui-même un passeport. Tant que l'acte délégué concernant l'aluminium n'a pas été publié, le format de données exact qui sera obligatoire n'est pas encore déterminé. Un couplage peut être préparé, mais l'hypothèse que le système ERP propre satisfera bientôt de manière autonome à toutes les exigences est prématurée.

Ce que vous pouvez documenter

Pour les entreprises qui envisagent un couplage entre le passeport produit et un système propre, il est utile de documenter en interne les points suivants — même si le couplage n'est pas encore construit :

Quels champs du système ERP ou de gestion des stocks correspondent à quels champs du passeport produit, y compris le code d'identification utilisé par produit ou par lot.
Qui au sein de l'entreprise est responsable de la mise à jour des données qui sont utilisées à la fois en interne et dans le passeport.
Un accord sur le moment où les données du système interne sont reprises dans le passeport, et le moment où cela n'arrive explicitement pas automatiquement.
Une documentation sur le système qui fait autorité pour quelle donnée — de manière à ce qu'en cas de contrôle ou de question d'un client, il soit clair d'où provient un chiffre ou une caractéristique.
Un aperçu de la question de savoir si le passeport est établi par pièce ou par lot, étant donné que cela détermine comment un couplage avec les lignes de stock peut être mieux configuré.

Ces points ne fixent aucun résultat et ne garantissent pas qu'un couplage satisfera à ce que l'acte délégué exigera par la suite — ce texte n'existe pas encore. Ils font en sorte qu'une entreprise, dès que les exigences techniques deviennent concrètes, ne part pas de zéro pour déterminer quelles données appartiennent où.

Ceci n'est pas un avis juridique. Cette page fournit des informations générales sur la réglementation qui régit cette plateforme. Nous ne connaissons pas votre situation. En cas de doute concernant votre propre cas, consultez un juriste ou l'autorité de contrôle compétente.

Rédigé avec l'IA sur la base des sources ci-dessus, vérifié par un humain le 2026-08-22. Quelque chose ne va pas ? Faites-le nous savoir — les corrections sont prioritaires.