Vous avez une échéance réglementaire — les batteries en 2027, les textiles peu après — et une décision à prendre : développer un système de Passeport Numérique de Produit en interne, ou en acheter un. La plupart des articles « développer ou acheter » sont des argumentaires de vente à peine déguisés. Celui-ci essaie d'être honnête, y compris sur les cas où développer est réellement le bon choix.
Ce que « développer le sien » implique vraiment
Un DPP n'est pas une ligne de base de données plus une page web. Pour être conforme et utile, un système doit faire tout ceci :
- un résolveur GS1 Digital Link avec négociation de contenu (HTML pour les humains, JSON-LD pour les machines, un linkset pour les autorités) ;
- une gestion des GTIN/numéros de série avec des identifiants immuables afin que les étiquettes imprimées ne soient jamais invalidées ;
- un hébergement immuable et pérenne des données du passeport (le passeport doit survivre à votre prochaine migration de CMS) ;
- une génération de QR codes prêts à imprimer dans des formats vectoriels (SVG/EPS) pour les imprimantes d'étiquettes ;
- une validation UE spécifique à la catégorie — les règles relatives aux batteries (Règl. 2023/1542) et celles relatives aux textiles/ESPR diffèrent champ par champ ;
- des pages consommateurs localisées dans les langues de l'UE ;
- la soumission au registre de l'UE, l'analyse des scans et une piste d'audit.
Une estimation réaliste pour développer et exploiter tout cela en interne se situe entre 100 k€ et 500 k€+ et 9 à 18 mois — et, point crucial, rien de tout cela n'est votre véritable produit.
Ce que l'achat vous apporte
| Développer en interne | Acheter (p. ex. qr3.app) | |
|---|---|---|
| Délai jusqu'au premier DPP conforme | 9 à 18 mois | quelques minutes |
| Coût initial | 100 k€–500 k€+ | 0 € (offre gratuite) |
| Coût récurrent | votre équipe d'ingénierie | à partir de 29 €/mois |
| Mises à jour de conformité (actes délégués ESPR) | vous suivez + implémentez | inclus |
| Résolveur GS1 + négociation de contenu | développer + exploiter | inclus |
| Pages consommateurs localisées | développer | inclus |
| Là où va la concentration de votre équipe | l'infrastructure | votre produit |
La troisième option que la plupart des articles oublient : achetez l'infrastructure, développez votre UX
Ce n'est pas tout ou rien. Les parties coûteuses et indifférenciées — le résolveur, l'hébergement immuable, la génération de QR codes, la validation UE — sont exactement ce que vous ne devriez pas développer. La partie qui vaut la peine d'être possédée, c'est votre expérience de marque et vos intégrations. Donc : achetez l'infrastructure via l'API, développez votre UX par-dessus.
import { QR3 } from "@qr3/sdk";
const client = new QR3({ apiKey: process.env.QR3_API_KEY! });
// The hard, compliance-heavy part — one call, straight from your ERP/PIM:
const passport = await client.dpp.create({
gtin: product.gtin,
serial: product.serial,
product_name: product.name,
manufacturer: "ExampleTech GmbH",
origin_country: "DE",
category: "battery",
battery_data: product.batteryData,
});
// Build YOUR experience on top: your dashboard, your branding, your
// integrations. React to scans in your own systems via webhooks:
// qr.scanned -> update analytics, trigger re-orders, flag a recall.
C'est le recadrage honnête de l'argument classique « le développer coûte une fortune » : achetez la partie qui est difficile et identique pour tout le monde ; développez la partie qui vous est propre.
Quand développer en interne a réellement du sens
Pour être juste — parfois, c'est le cas :
- le DPP est votre produit principal (vous vendez vous-même une plateforme de conformité) ;
- vous avez des exigences qu'aucun fournisseur ne satisfait (résidence des données exotique, pile sur site sur mesure) ;
- une échelle extrême où l'économie par unité l'emporte sur n'importe quel SaaS.
En dehors de ces cas, développer le travail lourd et indifférencié est généralement une distraction qui vous éloigne de la livraison de votre véritable produit avant l'échéance.
FAQ
Une API n'est-elle pas juste une autre forme de dépendance (lock-in) ? Moins que développer le vôtre et vous retrouver dépendant de votre propre code non maintenu. Les GTIN/numéros de série sont des standards GS1 ; les données du passeport sont exportables en JSON-LD. Les standards sont portables par conception.
Pouvons-nous commencer par acheter et développer plus tard si nous dépassons cette solution ? Oui — c'est tout l'intérêt de la voie hybride. Commencez sur l'API dès aujourd'hui (respectez l'échéance), internalisez de manière sélective plus tard si l'économie l'exige.
Et plus précisément, concernant la pression de l'échéance ? Développer prend 9 à 18 mois ; les DPP pour batteries sont attendus en 2027. Si vous n'avez pas commencé à développer, acheter est la seule voie qui respecte l'échéance.
Sources
Commencez gratuitement et livrez un DPP conforme dès aujourd'hui : app.qr3.app/sign-up
