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

Le couplage est le point de départ, la forme technique n'est pas encore définie

Un couplage entre le passeport produit numérique et un système ERP ou de gestion des stocks propre à l'entreprise correspond à la manière dont l'ESPR a conçu le passeport : les données doivent être lisibles par machine et interopérables, précisément pour éviter qu'elles ne doivent être réintroduites manuellement à chaque fois. L'article 10 de l'ESPR (Règlement (UE) 2024/1781) impose des exigences au passeport produit qui visent l'interopérabilité, et l'article 11 porte sur la conception technique et le fonctionnement de celui-ci, y compris la manière dont les données sont échangées. Cela signifie qu'un couplage est fondamentalement possible. Ce qui manque encore, c'est la mise en œuvre technique concrète pour le textile : quel format de fichier, quels champs sont obligatoires et si une API standard sera établie, cela n'est pas encore déterminé. Ces détails découleront de la réglementation supplémentaire qui sera spécifiquement établie pour les vêtements et les textiles.

Pour qui cela s'applique et pour quoi non

L'exigence d'interopérabilité de l'article 10 et les dispositions techniques de l'article 11 s'appliquent au passeport produit numérique en tant que tel, que la marque, l'importateur ou la marque de distributeur rassemble le passeport lui-même ou le fasse assembler. Il s'agit donc d'une exigence générique au sein de l'ESPR, et non quelque chose qui est inventé séparément par catégorie de produit. Ce qui ne découle pas de cela, c'est une obligation de construire dès maintenant un couplage technique, ou une garantie qu'un format de fichier ou un protocole particulier s'avérerait utilisable par la suite. Le passeport n'est en outre pas une copie d'un système ERP : il contient les données pertinentes pour le passeport (composition, origine, informations d'entretien, etc.), non la totalité de la gestion des stocks ou des commandes. Un couplage signifie en pratique qu'une partie des données produit déjà existantes est transférée au passeport, et non que les deux systèmes fusionnent complètement.

Quand cela devient concret et ce qui s'applique jusqu'à alors

Il n'y a pas encore de date fixe pour cette obligation. Le plan de travail ESPR 2025-2030 indique qu'une mesure d'exécution pour le textile est attendue en 2027, et que les vêtements contenant quatre-vingts pour cent ou plus de fibres textiles seront les premiers traités. Dès que cette mesure sera publiée, il sera également clair quelles exigences techniques sont imposées à l'échange de données, et donc si et comment un couplage avec un système ERP ou de gestion des stocks pourrait fonctionner. Jusque-là, seules les dispositions générales des articles 10 et 11 s'appliquent : le cadre est établi, mais la mise en œuvre technique pour le textile ne l'est pas encore. Quiconque souhaiterait dès maintenant développer un couplage construirait donc sur un cadre dont les détails pourraient encore changer.

Ce que cela signifie en pratique, étape par étape

D'abord, il est judicieux de regarder quelles données existent déjà dans le propre système et lesquelles devraient probablement se retrouver dans un passeport : composition des fibres, pays de production, origine des matériaux, instructions d'entretien. Ensuite, il est pratique de consigner ces données aussi structurées que possible, dans des champs fixes avec des valeurs univoques plutôt que du texte libre, pour qu'elles puissent être facilement transférées ultérieurement vers n'importe quel format. Après cela, il est judicieux d'attendre avant de construire réellement un couplage technique ou une API, car les exigences pour le textile ne sont pas encore établies ; l'énergie consacrée maintenant à un couplage spécifique pourrait nécessiter une adaptation après la publication de la mesure d'exécution. Ce qui fonctionne déjà, c'est la fourniture de données de la manière actuellement disponible : manuellement, via un fichier, ou via une simple export du système existant. Texpas constitue le passeport à partir des données fournies par le fabricant ou l'importateur, et traite déjà cette fourniture maintenant sans qu'un couplage en direct soit nécessaire. Dès que le cadre technique pour le textile sera connu, il sera possible de déterminer si un couplage plus direct à partir du système ERP ou de gestion des stocks présente une valeur ajoutée.

Sur quoi cela est basé : articles 10 et 11 de l'ESPR

L'exigence d'interopérabilité et l'exigence de lisibilité automatisée pour le passeport numérique des produits découlent de l'article 10 du ESPR (Règlement (UE) 2024/1781), qui fixe les exigences générales pour le passeport. L'article 11 du même règlement décrit la conception technique et le fonctionnement du passeport, notamment la manière dont les données sont enregistrées et échangées numériquement. Ces deux articles constituent le cadre dans lequel la législation ultérieure spécifique aux produits pour le textile doit remplir les détails techniques; ce complément n'existe pas encore pour les vêtements et textiles.

Quiconque enregistre dès maintenant les données sur la composition, l'origine et l'entretien de manière structurée dans son propre système n'aura pas besoin de recommencer ultérieurement, quelle que soit la forme technique que prendra le couplage. Pour l'état actuel de l'acte délégué et le calendrier exact, la source officielle de la Commission européenne est le point à surveiller.

Ce sur quoi cela est basé

Le règlement lui-même se trouve sur EUR-Lex. Nous renvoyons par affirmation; vous n'avez pas besoin de nous croire.

Ce que vous devez faire concrètement

Ce qu'on attend de vous

Le passeport doit pouvoir recevoir des données des systèmes sources

L'article 10 du ESPR (Règlement (UE) 2024/1781) établit les exigences relatives aux données qui doivent figurer dans un passeport produit numérique et à la manière dont ces données sont accessibles. Ces données ne viennent pas de nulle part : elles se trouvent déjà dans des systèmes existants tels qu'un progiciel ERP, un système PLM ou un progiciel de gestion des stocks — composition matérielle, données de fournisseurs, numéros de lot, instructions d'entretien. Pour une entreprise de 10 à 100 salariés, cela signifie concrètement qu'il doit y avoir une connexion entre le système où ces données se trouvent déjà et le système qui compile et publie le passeport. Il peut s'agir d'un couplage automatisé, mais aussi d'une exportation périodique qui est téléchargée manuellement. Les deux sont fondamentalement possibles ; la forme pratique dépend du nombre de produits et de variantes et de la fréquence à laquelle les données changent.

Le fonctionnement technique doit s'aligner sur les normes établies

L'article 11 du ESPR (Règlement (UE) 2024/1781) décrit la conception technique et le fonctionnement du passeport, y compris la manière dont l'échange de données s'effectue. Cela touche directement à la question de savoir comment un couplage est mis en place techniquement : tous les formats d'export d'un système ERP quelconque ne s'alignent pas sans modification sur ce qu'un système de passeport attend. Pour une entreprise de taille moyenne, cela signifie qu'une traduction est nécessaire entre la propre structure de données et le format utilisé pour le passeport. C'est une question technique, non juridique — mais cela touche également à la question ce qu'est GS1 Digital Link et si c'est nécessaire pour le passeport du produitcar une partie de la normalisation attendue passe par ce type de systèmes.

Chaque produit doit être traçable jusqu'aux bonnes données de passeport

Un couplage avec un système ERP ou de gestion des stocks ne fonctionne que s'il existe un moyen cohérent d'assortir un produit physique au bon passeport. Cela nécessite une clé cohérente entre les systèmes : le même numéro d'article, le même code de lot ou la même identification de variante dans le système ERP que dans le passeport. Sans cet alignement, il existe un risque qu'un système couplé transmette bien des données, mais vers le mauvais passeport, ou qu'une modification dans un système ne se répercute pas dans l'autre. Cela est étroitement lié à la manière dont chaque produit reçoit un code d'identification unique; sans une logique d'identification claire, un couplage entre systèmes a peu de valeur.

Où cela pose problème en pratique

Une première situation qui revient souvent : une entreprise dispose d'un système ERP dans lequel les articles sont enregistrés par style, mais pas par couleur ou taille. Le passeport doit cependant être exact au niveau des variantes, et il s'avère que le couplage transmet des données qui sont correctes pour une taille mais non pour une autre.

Une deuxième situation : les données sont transférées une seule fois lors du lancement d'une collection, mais une modification ultérieure du système ERP — par exemple un fournisseur différent pour une partie du lot — n'est pas automatiquement transférée au passeport publié. Le passeport perd ainsi sa correspondance avec la réalité sans que personne ne le remarque, jusqu'à ce que quelqu'un découvre une erreur et se demande si un passeport produit publié peut encore être modifié.

Une troisième situation : un couplage est mis en place techniquement par un tiers informatique externe, mais personne au sein de l'entreprise ne vérifie ensuite si les données qui se retrouvent dans le passeport correspondent effectivement à ce qui figure sur l'étiquette ou l'emballage. Un couplage technique qui fonctionne n'est pas automatiquement un couplage qui est correct.

Une quatrième situation : le système de gestion des stocks est utilisé pour faire expirer automatiquement les passeports dès qu'un produit est épuisé, sans tenir compte de la question de savoir combien de temps un passeport doit rester disponible. Cela peut créer un décalage entre ce qui est opérationnellement pratique pour l'administration des stocks et ce qui est attendu en ce qui concerne la durée pendant laquelle un passeport de produit doit rester disponible.

Une cinquième situation : lors d'une fusion, d'une acquisition ou de l'arrêt d'une division, le lien est déconnecté sans qu'on ait réfléchi à qui gère les données par la suite, ce qui rejoint la question mentionnée ce qui advient du passeport produit si une entreprise cesse son activité.

Ce que vous pouvez documenter

Un aperçu des systèmes qui fournissent quelles données de passeport : ERP pour le matériau et l'origine, système d'inventaire pour la disponibilité, PLM pour les données de conception et de composition.
Un accord établi sur la fréquence de synchronisation : liaison en temps réel, export quotidien, ou mise à jour manuelle par collection.
Un document décrivant la clé d'identification utilisée pour faire correspondre un produit dans le système ERP avec le bon passeport — y compris le fonctionnement en cas de variantes de taille ou de couleur.
Une fonction ou une personne responsable qui vérifie si les données entrantes via le lien sont effectivement exactes avant la publication ou la mise à jour d'un passeport.
Une procédure pour ce qui se passe en cas de modification dans le système source : qui la signale, et comment la modification est-elle intégrée dans le passeport publié.
Des accords avec un fournisseur informatique ou un service informatique interne sur le format technique du lien, y compris ce qui se passe en cas de changement de système ou de migration.
Un aperçu des données qui sont effectivement fournies automatiquement via un lien et lesquelles doivent encore être complétées manuellement, pour qu'il n'y ait pas de vide entre ce que le système pense envoyer et ce qui se trouve réellement dans le passeport.

Ceci n'est pas un avis juridique. Cette page fournit des informations générales sur la réglementation dont parle cette plateforme. Nous ne connaissons pas votre situation. En cas de doute sur votre cas personnel, consultez un juriste ou l'autorité de surveillance 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.