Le nouvel obstacle pratique : qui peut enregistrer un passeport ?
Le registre DPP de l’UE est opérationnel depuis le 20 juillet 2026. Pour de nombreuses équipes, la question technique était d’abord prioritaire : est-il possible d’enregistrer un identifiant de produit, et le support redirige-t-il correctement ? C’est nécessaire, mais incomplet. Avec le règlement d’exécution (UE) 2026/1778 du 16 juillet 2026, l’identité en amont acquiert une importance réglementaire propre : l’enregistrement doit être effectué par des opérateurs économiques vérifiés, et l’accès aux fonctions du registre n’est pas la même chose que l’accès public aux informations sur les produits.
Il ne s’agit pas de rendre les codes QR plus complexes. Il s’agit de modéliser correctement les responsabilités, les justificatifs et les autorisations avant le premier processus d’enregistrement en production. Le guide suivant distingue ces niveaux et montre ce que les fabricants peuvent préparer concrètement dès maintenant.
Trois identités à ne pas confondre
Dans un projet DPP, au moins trois identités différentes interviennent.
Premièrement, il y a l’opérateur économique : l’entreprise ou l’entrepreneur individuel qui met un produit sur le marché ou agit dans le registre. L’article 4 du règlement 2026/1778 lie la qualification d’« opérateur économique vérifié » à une preuve d’identité. Pour les entrepreneurs individuels établis dans l’UE, l’acte juridique cite notamment une signature électronique qualifiée ou un moyen d’identification électronique conforme à eIDAS, avec un niveau de garantie élevé. Les personnes morales doivent elles aussi être vérifiées au moyen de justificatifs définis.
Deuxièmement, il y a l’utilisateur humain. Les achats, la gestion des données de référence, la conformité, les prestataires externes et un fournisseur de services DPP n’agissent pas automatiquement avec les mêmes pouvoirs. Un compte utilisateur ne remplace donc pas le contexte vérifié de l’entreprise. Une attribution traçable est nécessaire : qui agit pour quel opérateur économique, avec quel rôle et jusqu’à quelle date ?
Troisièmement, il y a l’identité du produit. Un GTIN, un numéro de série ou un autre identifiant décrit le produit ou le niveau de granularité requis ; il ne prouve pas que la personne devant l’écran est autorisée à effectuer l’enregistrement. Le ESPR sépare expressément ces sphères : le support relie le produit au passeport, tandis que le registre conserve les identifiants uniques et les données d’enregistrement. La présentation de la Commission sur le DPP décrit le processus en conséquence : les informations sur le produit sont créées et enregistrées, puis le registre génère un identifiant d’enregistrement unique.
Quiconque regroupe ces trois identités dans un tableau, un jeton d’API ou une boîte de courrier électronique commune crée par la suite un risque d’audit et d’exploitation. La bonne question n’est pas « Qui connaît le lien ? », mais « Qui est autorisé à déclencher une opération dans le registre au nom de cet opérateur économique ? ».
L’accès public par QR n’est pas une autorisation d’accès au registre
Un code QR apposé sur le produit reste un accès au passeport. Ce n’est pas un mécanisme de connexion au registre et il ne devrait pas le devenir. Les consommateurs, les ateliers de réparation, les recycleurs et les autorités ont besoin d’informations différentes. Le guide actuel de la Commission sur le DPP précise que les informations sont accessibles selon les rôles des utilisateurs.
En pratique, une séparation claire des couches est donc recommandée :
- Le scan public fournit une vue stable du passeport, accessible gratuitement, avec les informations prescrites pour le groupe de produits concerné.
- Une interface à accès limité selon les rôles gère les justificatifs, les données des fournisseurs, l’historique des modifications et les validations internes.
- Le connecteur du registre ne doit transmettre que les données d’enregistrement nécessaires et associer une réponse du registre à une fiche produit précise.
Cela évite deux idées reçues répandues. Premièrement, un lien QR « secret » ne remplace pas un contrôle d’accès : il peut être transmis et ne constitue pas une preuve fiable d’autorisation. Deuxièmement, le registre n’est pas le lieu de stockage de tous les documents relatifs au produit. La Commission explique que les informations complètes sur le produit peuvent être conservées par l’opérateur économique ou un fournisseur de services DPP ; les métadonnées et identifiants nécessaires sont enregistrés.
Ce que le règlement suggère sur le plan technique
Le règlement 2026/1778 ne décrit pas le registre comme une simple base de données de consultation. Il mentionne notamment une API pour l’enregistrement et la réception des données, une plateforme permettant de confirmer l’existence et l’exhaustivité, un schéma pour les identifiants d’enregistrement uniques, un répertoire des fournisseurs de services DPP vérifiés, un système de journalisation ainsi que des schémas d’identification et d’autorisation. Les modèles de données doivent en outre être versionnés.
Ces exigences ne définissent pas une architecture produit complète. Elles fournissent toutefois des garde-fous solides :
Profil de l’entreprise avant l’importation des produits
Avant un import massif, créez une fiche d’entreprise contrôlée. Elle doit comprendre l’entité juridique, son statut d’opérateur économique, le justificatif d’identité choisi, la date de la vérification et le service responsable. Un système DPP ne devrait conserver le justificatif lui-même que dans la mesure nécessaire et autorisée ; souvent, un statut de vérification accompagné d’une référence et d’une logique d’expiration ou de réévaluation suffit.
La délégation est un enregistrement à part entière
Lorsqu’un fournisseur de services ou une agence intervient, la délégation doit en définir la portée. Il est recommandé d’indiquer au minimum l’opérateur économique, les actions autorisées, les groupes de produits ou les marques, la date de début, la date de fin et la révocation. Une clé d’API générale sans limite de mandat est trop imprécise pour une opération ayant une portée réglementaire.
Un enregistrement traçable
Pour chaque enregistrement, les équipes devraient au minimum conserver la version locale du produit, l’identifiant transmis, la réponse avec l’identifiant d’enregistrement, l’horodatage, le rôle ayant agi et la catégorie d’erreur. Il sera ainsi possible de distinguer ultérieurement un passeport incomplet sur le fond, un conflit d’identifiants ou une autorisation manquante. La journalisation ne doit pas devenir une collecte de données personnelles superflues ; elle doit établir une chaîne d’actions responsable et vérifiable.
Tester les autorisations comme des règles métier
Les cas de test ne devraient pas s’arrêter à « l’API répond 200 ». Vérifiez au minimum les points suivants : un utilisateur non autorisé ne peut déclencher aucun enregistrement ; un fournisseur mandaté ne peut traiter que le mandat convenu ; une délégation arrivée à expiration est rejetée ; la vue publique du passeport ne divulgue aucune donnée interne du registre ou relative aux justificatifs ; et une opération soumise à nouveau est traitée de manière traçable comme une répétition.
Un plan de démarrage simple pour les prochaines semaines
Ne commencez pas par une migration complète. Choisissez un petit ensemble représentatif de produits et une chaîne réelle de responsabilités.
- Pour chaque produit pilote, attribuez le fabricant, le metteur sur le marché, les responsables des données et, le cas échéant, le fournisseur de services.
- Documentez la procédure de vérification de l’opérateur économique et la personne qui approuve cette vérification.
- Définissez les rôles pour la préparation, la validation métier, l’enregistrement et les seuls droits de lecture.
- Enregistrez une fiche de test avec des données produit versionnées et consignez l’enregistrement, la réponse et le processus de correction.
- Testez séparément l’accès public par QR, les rôles internes et le connecteur du registre.
- Exercez la révocation et le remplacement : que se passe-t-il lors d’un changement de prestataire, d’une modification de la dénomination de l’entreprise ou d’un identifiant erroné ?
Cette démarche est également conforme à la recommandation déjà publiée de tester séparément le registre, le résolveur et la source de données. La nouveauté réside dans l’accent mis sur le point suivant : avant une intégration robuste de l’API, il faut savoir quelle organisation vérifiée et quel rôle assument la responsabilité de l’opération.
Ce qu’il ne faut pas encore affirmer
Le règlement sur le registre crée le cadre technique et organisationnel. Il ne rend pas immédiatement chaque groupe de produits soumis à DPP et ne remplace pas les actes délégués spécifiques à chaque secteur. La Commission continue de présenter la mise en œuvre groupe de produits par groupe de produits ; en vertu des actes délégués ESPR déjà adoptés, une période transitoire d’au moins 18 mois est en principe prévue. De même, le statut vérifié d’une entreprise n’autorise pas à fournir des données produit incomplètes ou incorrectes.
La conséquence est néanmoins concrète pour les équipes : l’identité, le mandat, les rôles et la journalisation doivent figurer dans le backlog DPP avant le passage à l’échelle des enregistrements. Le code QR reste ainsi le point d’entrée public simple, tandis que l’opération dans le registre devient ce qu’elle est sur le plan réglementaire : une action responsable et traçable d’un opérateur économique vérifié.
