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

Le couplage est possible, la forme n'est pas fixée par la loi

Oui, un passeport numérique de produit peut en pratique être couplé à un système ERP ou de gestion des stocks, mais l'ESPR ne prescrit pas la forme de ce couplage. Le règlement impose bien des exigences au passeport lui-même : il doit être construit techniquement de telle sorte que les données soient lisibles par machine et que les systèmes puissent les lire et les traiter automatiquement, en se basant sur des normes ouvertes plutôt que sur des formats fermés et propriétaires (article 11 de l'ESPR, Règlement (UE) 2024/1781). Cette exigence vise le passeport et le support de données, et non les systèmes internes d'un importateur de pneus, d'un grossiste ou d'un gestionnaire de parc automobile. Le fait qu'un couplage avec un progiciel ERP spécifique soit possible ou non, et comment il fonctionne, relève donc de la configuration technique du prestataire qui constitue et héberge le passeport — en l'occurrence une plateforme comme tyrepas.eu — et non d'une matière que la loi réglemente en détail.

Pour qui cette question est pertinente, et pour qui elle ne l'est pas

Cette question se pose surtout pour les acteurs qui traitent de grands volumes de pneus et pour lesquels les données de produit existent déjà quelque part dans un système : les importateurs qui gèrent les numéros d'articles, les données de lot et les spécifications techniques, les grossistes qui maintiennent les stocks par type de pneu, et les gestionnaires de parc automobile qui associent les pneus aux véhicules. Pour eux, un couplage est surtout pratique : les données n'ont pas besoin d'être entrées deux fois, et les informations du passeport peuvent revenir au système personnel.

Pour les utilisateurs finaux qui n'achètent qu'un pneu et scannent le code QR, le couplage avec un système ERP n'intervient pas — ils lisent le passeport, ils ne l'alimentent pas. Et pour les petites parties sans système propre, le couplage ne se pose pas non plus : le passeport peut tout aussi bien être fourni et consulté manuellement, sans que cela remette en cause sa validité. Les exigences techniques de l'article 11 portent en outre sur le passeport en lui-même, et non sur la question de savoir si un prestataire de services de passeport doit proposer un couplage spécifique avec une marque ERP particulière.

Pas encore de date fixe, mais une feuille de route claire

Le moment exact où l'obligation d'un passeport numérique de produit pour les pneus entrera en vigueur n'est pas encore fixé. Dans le plan de travail de l'ESPR pour la période 2025-2030, une acte délégué pour les pneus est attendu en 2027 ; ce n'est qu'avec la publication de celui-ci qu'une date d'entrée en vigueur concrète sera connue. Jusque-là, aucune exigence obligatoire ne s'applique aux pneus concernant le passeport lui-même, et donc pas non plus la manière dont les données sont fournies ou échangées.

Cela ne signifie pas qu'il n'y a rien à faire. Les exigences générales de l'article 10 et de l'article 11 de l'ESPR sont déjà fixées comme cadre dans lequel l'acte délégué relatif aux pneus sera précisé : la lisibilité par machine, les normes ouvertes et l'interopérabilité ne sont pas une nouvelle invention qui apparaît en 2027, mais le fondement sur lequel les règles spécifiques aux pneus seront construites. Celui qui réfléchit dès maintenant à un couplage ne construit donc pas sur du sable mouvant, même si la date définitive fait encore défaut.

Comment cela fonctionne en pratique

La première étape consiste à vérifier quelles données existent déjà dans le système ERP ou de gestion des stocks et qui devront figurer dans un passeport : numéro d'article, données de lot ou de lot, date de production, spécifications techniques par type de pneu. Bon nombre de ces données existent déjà, elles ne sont simplement pas encore structurées de manière à être prêtes pour un passeport.

La deuxième étape consiste à déterminer quel format le prestataire qui constitue et héberge le passeport accepte comme entrée. Puisque tyrepas.eu constitue le passeport à partir des données du fabricant ou de l'importateur, la question pratique n'est pas tant de savoir si le couplage est possible, mais sous quelle forme la fourniture des données est la plus pratique : une exportation périodique du système ERP, un fichier structuré, ou une autre voie de fourniture.

La troisième étape consiste à réfléchir à la direction opposée : le renvoi des données du passeport vers son propre système, par exemple pour qu'un gestionnaire de parc automobile puisse lier les informations du passeport à un enregistrement de véhicule sans avoir à rechercher lui-même le passeport via le code QR. Ceci aussi est une question de coordination technique entre le système ERP et la plateforme, et non d'une obligation légale.

Enfin, il est important de tenir compte de la durée : un passeport est hébergé pour une période de dix ans. Celui qui met en place un lien ferait bien de réfléchir également aux mises à jour au cours de cette période — par exemple lorsque les données de produit changent — afin que le lien ne fonctionne pas seulement lors de la première livraison, mais aussi lors des ajustements ultérieurs.

La base légale : articles 10 et 11 du ESPR

Les exigences relatives au passeport numérique du produit lui-même sont énoncées à l'article 10 du ESPR (Règlement (UE) 2024/1781), qui établit les exigences générales du passeport. L'article 11 du même règlement porte spécifiquement sur la conception technique et le fonctionnement du passeport, en mettant l'accent sur l'interopérabilité et les normes ouvertes afin que les données soient lisibles par machine et échangeables. Les deux articles portent sur le passeport en tant que produit, non sur les systèmes d'information interne des importateurs, des grossistes ou des gestionnaires de parcs automobiles — le lien avec ceux-ci est une mise en œuvre technique qui s'ajoute à cela.

Pour ceux qui souhaitent déjà se préparer, le mieux est de commencer par cartographier ses propres données de produit et de prendre contact avec la partie qui va assembler et héberger le passeport pour les pneus, afin de discuter de l'itinéraire de livraison qui convient le mieux au système ERP ou de gestion des stocks existant.

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 concrètement faire

Ce que l'on attend de vous

Le passeport doit pouvoir recevoir des données d'un système source

Un passeport produit n'est pas saisi manuellement dans un formulaire isolé — les données proviennent de quelque part : d'un système ERP, d'un logiciel de gestion des stocks, d'une export Excel du fabricant, ou d'une combinaison de ceux-ci. L'article 10 du ESPR (Règlement (UE) 2024/1781) fixe des exigences quant aux données qui doivent figurer dans le passeport et à la manière dont elles sont accessibles, mais ne prescrit pas le système via lequel une entreprise fournit ces données. Pour un importateur de pneus ou un grossiste employant entre 10 et 100 personnes, cela signifie en pratique qu'il doit exister un moyen fixe et reproductible de transférer les données de produits du propre système de l'entreprise vers le passeport — et non une saisie manuelle unique qui doit être réinventée à chaque nouveau lot de pneus.

Le lien doit correspondre à un code d'identification unique par produit

L'article 11 du ESPR décrit le fonctionnement technique du passeport produit numérique, notamment le lien entre un produit et son passeport via un code d'identification. Un système ERP ou de gestion des stocks fonctionne généralement avec ses propres numéros d'articles, SKU ou codes internes. Pour le lien avec le passeport, ce code interne doit correspondre ou être traduit en code d'identification utilisé par le passeport. Les entreprises qui disposent déjà d'un code clair et unique pour chaque dimension de pneu ou pour chaque lot dans leur système de gestion des stocks ont un avantage ; les entreprises qui travaillent avec des lots groupés ou des noms de modèles génériques découvrent souvent lors du lien que leur administration interne n'est pas suffisamment détaillée. Vous trouverez plus de détails sur cette étape de base dans comment attribuer à chaque produit un code d'identification unique ?

Les modifications du système source doivent être répercutées dans le passeport

Un système de gestion des stocks n'est jamais statique : les prix changent, les spécifications sont mises à jour, un fournisseur modifie une composition. L'article 10 part du principe que le passeport reflète l'état actuel des données, dans la mesure où la catégorie de données l'exige. Pour une entreprise, cela signifie qu'un lien avec son propre système ne doit pas seulement fonctionner lors de la première saisie, mais aussi lors de modifications ultérieures — faute de quoi, le passeport devient un document qui était exact au moment de sa publication, mais qui ne l'est plus maintenant.

Le lien doit être traçable jusqu'à la source

Un passeport qui affiche des données sans qu'il soit possible de déterminer le système, l'export ou la version dont elles proviennent est difficile à justifier lors d'un contrôle. Cela ne découle pas d'un article spécifique, mais de l'application pratique des articles 10 et 11 ensemble : les données doivent être exactes ET vérifiables. Pour les entreprises disposant d'un lien vers leur ERP, cela signifie qu'une forme de journalisation ou de gestion des versions est souhaitable — quand et quel ensemble de données a été transféré, et par qui.

Où cela s'est mal passé dans la pratique

Un grossiste couple le module de gestion des stocks du système ERP une seule fois au passeport lors du lancement, mais oublie que les nouvelles dimensions de pneus ajoutées ultérieurement ne sont pas automatiquement reprises — le passeport reste bloqué sur l'assortiment de la date de démarrage.

Un importateur utilise dans le système ERP un code de regroupement pour toute une ligne de produits (« 175/65R14 pneu été, diverses marques »), tandis que le passeport doit fonctionner selon le code d'identification unique. Le lien produit alors un seul passeport pour des produits qui nécessitent en réalité chacun leur propre passeport — voir aussi comment la taille du pneu se rapporte-t-elle au code d'identification unique ?

Un responsable de parc automobile reçoit une export du fabricant dans un format qui ne correspond pas à son propre système de gestion des stocks, et les données sont saisies manuellement dans un fichier intermédiaire. Lors de la prochaine livraison, ce fichier intermédiaire n'est pas mis à jour, ce qui fait que le passeport affiche une version plus ancienne des spécifications que celle qui se trouve réellement dans l'entrepôt.

Une entreprise couple le système ERP directement au passeport sans étape intermédiaire, et une erreur dans un champ d'export (par exemple une colonne confondue contenant les dimensions de pneus) se retrouve inaperçue dans plusieurs passeports, car personne ne vérifie les données couplées après le transfert.

Un importateur pense qu'un seul appairage suffit pour toutes les futures variantes d'un modèle, alors qu'en réalité des données distinctes sont nécessaires pour chaque dimension ou version — la question de savoir si les données peuvent être réutilisées pour différentes dimensions de pneus du même modèle se pose alors trop tard, voir puis-je utiliser les mêmes données pour plusieurs dimensions de pneus du même modèle ?

Ce que vous pouvez documenter

Un aperçu du système (ERP, gestion des stocks, portail fournisseur) qui est la source de chaque champ de données du passeport, afin qu'en cas de question ou de contrôle, il soit immédiatement clair d'où provient un chiffre ou une spécification.
Une procédure établie pour le transfert de données pour les nouveaux produits, incluant le moment où le code d'identification unique est attribué et appairé.
Un accord sur la personne responsable de la mise à jour du passeport lorsque les données du système source changent — et selon quelle procédure cela se fait.
Une étape de contrôle après chaque appairage ou export, au cours de laquelle on vérifie par sondage si les données du passeport correspondent au système source.
Un journal ou un historique des versions de ce qui a été transféré et quand, afin qu'une modification ultérieure soit traçable.
Documentation de l'appairage technique lui-même (quels formats d'export, quels champs sont mappés, quel logiciel ou couche intermédiaire est utilisé), utilisable comme annexe aux audits internes.

Pour les entreprises qui doivent encore déterminer si leurs pneus relèvent de cette obligation, il s'agit d'une étape préalable logique — voir le passeport numérique de produit s'applique-t-il à mes pneumatiques ? Quiconque souhaite en savoir plus sur le rôle du passeport dans la chaîne globale et sur la façon dont l'appairage avec son propre système s'insère, trouvera une explication générale dans qu'est-ce qu'un passeport numérique de produit pour pneus ?

Ceci n'est pas un avis juridique. Cette page fournit des informations générales sur la réglementation sur laquelle porte cette plateforme. Nous ne connaissons pas votre situation. En cas de doute concernant votre 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. Y a-t-il quelque chose d'incorrect ? Nous le faire savoir — les corrections sont prioritaires.