La conformité, en clair.

Oui. Chaque champ de chaque schéma sectoriel porte un niveau d'accès par audience. La vue consommateur n'affiche que les champs marqués « public » ; une habilitation auditeur, recycleur, réparateur ou organisme notifié déverrouille les champs marqués pour cette audience (la séparation §§ 1/2/3/4 de l'annexe XIII du règlement Batteries sert de modèle). Les deux vues se résolvent depuis la même URL /p/{code} via négociation Accept-header.

Oui. Même URL, contenu négocié via l'en-tête Accept (HTML pour les humains, JSON-LD pour les machines) et filtré par l'habilitation présentée par le visiteur. Nous ne forkons jamais l'URL par audience — l'article 10 ESPR impose une URL permanente.

Par une habilitation signée à courte durée de vie, délivrée via un parcours de candidature contrôlé. Cinq rôles sont reconnus : fabricant, auditeur, recycleur, réparateur, organisme notifié. Les habilitations sont révocables depuis une seule console admin ; une révocation s'applique dès la requête suivante. Tant qu'aucune spécification eIDAS-DPP nationale n'est publiée, la vérification est manuelle — quelques émissions par mois à l'échelle pilote.

Aujourd'hui, le passeport porte un seul bloc fin-de-vie. Des blocs par juridiction (résolus via paramètre de requête, cookie de langue ou géo-IP, avec fallback sur le bloc par défaut du fabricant) sont prévus pour la prochaine livraison ; la forme de données et le résolveur sont conçus, et les paquets de contenu par marché sont cadrés. En attendant, les fabricants exportant vers plusieurs pays publient un bloc par défaut écrit pour être acceptable à l'échelle de l'UE.

Déjà livré. EN, DE, DA, FR, IT, ES et PL sont rendus nativement sur chaque page, y compris le viewer /p/{code} destiné au consommateur ; des balises hreflang réciproques sont émises sur chaque variante ; Accept-Language est auto-détecté pour les visiteurs arrivant directement sur /p/{code}.

Oui. Chaque enregistrement écrit une ligne passport_revisions avec hash_before, hash_after et un diff structuré. La chaîne est servie sur /p/{code}/audit en JSON, avec les chemins de diff à accès restreint masqués pour les appelants anonymes et déverrouillés pour les auditeurs habilités. La validité de la chaîne se vérifie côté client, sans avoir à faire confiance à notre infrastructure.

Chaque passeport possède un passport_hash (SHA-256 sur le JSON-LD canonique). Le hash apparaît dans la vue HTML, dans la réponse JSON-LD et dans le PDF hors-ligne — trois surfaces indépendantes qu'un régulateur peut recouper sans avoir à faire confiance à l'une isolément.

Non. L'article 10(4) ESPR impose une persistance à vie ; un DELETE sur un passeport renvoie 403. Les passeports batterie passent à is_active=False (article 77(8)) lorsque l'unité atteint le flux des déchets — le viewer renvoie 410 Gone pour les lecteurs humains, la ligne reste en base pour audit.

Construits sur l'architecture ESPR. Plusieurs actes délégués (textile, électronique) ne sont pas finalisés, aucune plateforme au monde ne peut donc revendiquer une conformité sectorielle complète aujourd'hui. Nos schémas suivent les projets de travail ; à la publication de chaque acte délégué, nous re-tagguons les champs du schéma — nous ne reconstruisons pas.

L'article 13 ESPR rend le registre obligatoire à compter du 19 juillet 2026. Notre intégration est abstraite derrière un module unique, en mode stub aujourd'hui ; quand la Commission publiera l'API LinkSet et délivrera les credentials provider, nous basculons trois variables d'environnement — pas d'autre changement de code. Contenza K/S est membre du consortium CIRPASS-2, donc nous suivons les mêmes documents de travail que ceux contre lesquels la Commission rédige.

Batterie (2023/1542), textile (acte délégué ESPR + 2024/3015), construction (CPR 305/2011), électronique (ESPR + Right-to-Repair 2024/1799 + DEEE), pneus (2020/740) et un fallback général pour les produits sans acte sectoriel. Machines (2023/1230) est volontairement hors-périmètre — la réglementation impose une documentation technique CE, pas un DPP.

Dans l'UE. PostgreSQL + MinIO sur du matériel européen, au Danemark. Le champ « prestataire de copie de sauvegarde » de l'annexe III(l) est rempli sur chaque passeport, pour qu'un régulateur puisse identifier le dépositaire des données sans nous interroger.

Oui. L'endpoint machine JSON-LD est l'export — même forme canonique sur laquelle le hash d'intégrité est calculé. CORS activé (Access-Control-Allow-Origin: *) pour qu'un outil tiers puisse récupérer en cross-origin. Un bundle ZIP de compte complet et un modèle de résolveur portable sont prévus pour la prochaine livraison ; le JSON-LD par passeport est déjà aujourd'hui un export complet et vérifiable par machine.

Oui. Caddy en TLS à la demande émet un certificat par domaine vérifié à la première requête. La propriété du domaine est vérifiée par un enregistrement TXT avant émission ; un détournement de domaine n'est pas possible.

Oui — c'est une partie du design. L'import CSV en masse (Professional+) met les SKU existants en conformité ; le QR peut être imprimé sur des étiquettes, des hangtags ou la prochaine campagne d'emballage. Le passeporting rétroactif est précisément le cas que la réglementation prévoit pour la période de transition.