Suite de tests du résolveur GS1 : vérifier la robustesse des DPP-Links avant la mise en production

Un code QR qui ouvre une page dans le navigateur ne prouve pas encore la robustesse d’un résolveur. Pour un résolveur GS1, c’est l’ensemble du comportement HTTP qui compte : quels identifiants sont acceptés ? Quelle est la cible par défaut ? Le service fournit-il un jeu de liens lisible par machine ? Les accès depuis un navigateur fonctionnent-ils entre domaines différents ? Et les requêtes invalides ou indisponibles signalent-elles la bonne erreur ?

Depuis le 16 janvier 2026, le GS1-Conformant Resolver Standard 1.2.0 est disponible. La suite de tests GS1 publique correspondante est désormais considérée comme stable ; son code a été mis à jour pour la dernière fois le 29 juin 2026. Il est ainsi possible de transformer une norme abstraite en test d’acceptation concret. Cet article présente les vérifications à effectuer avant la mise en production, les limites de la suite de tests et les éléments justificatifs à intégrer à une validation technique.

Un scan réussi n’est que le début

Un GS1 Digital Link contient un identifiant GS1 dans un URI HTTPS. Le résolveur associe cet identifiant à une ou plusieurs ressources, par exemple une page produit, un mode d’emploi, une fiche technique ou une interface de programmation. Notre article d’introduction explique le résolveur GS1 avec un exemple en direct. Pour valider une mise en production, une simple redirection standard réussie ne suffit toutefois pas.

Le standard du résolveur 1.2.0 impose notamment HTTPS, la prise en charge de GET, HEAD et OPTIONS, le partage de ressources entre origines (CORS), un lien par défaut identifiable ainsi qu’une sortie sous forme de jeu de liens. Avec linkType=linkset ou l’en-tête Accept application/linkset+json, le résolveur ne doit pas rediriger. Il doit au contraire renvoyer les liens typés disponibles sous forme de représentation autonome.

Cette distinction est importante : le parcours humain dans le navigateur peut fonctionner alors que l’accès machine, la langue, les types de liens ou les cas d’erreur sont défaillants. Ce sont précisément les écarts qu’un simple test de scan ne permet pas de détecter.

Le plan d’acceptation en sept étapes

1. Définir des URI de test représentatifs

Ne commencez pas par un seul produit type. Constituez une petite collection de tests versionnée :

au moins un identifiant valide pour chaque clé primaire GS1 prise en charge ;
un cas GTIN sans qualificatif ;
des cas avec lot ou numéro de série, si cette granularité est prise en charge ;
un identifiant syntaxiquement invalide ;
un identifiant valide, mais inconnu ;
un identifiant connu sans le type de lien demandé.

Le standard autorise un résolveur à ne prendre en charge qu’un sous-ensemble des clés primaires GS1. Pour chaque clé primaire prise en charge, ses qualificatifs et attributs de données doivent toutefois être traités intégralement. L’ensemble de tests doit donc correspondre aux capacités effectivement déclarées, et non à une affirmation marketing générale.

2. Vérifier la redirection standard et les méthodes

Testez d’abord l’appel normal sans en-têtes particuliers. Un lien standard déterministe est attendu. Poursuivez avec HEAD et OPTIONS : HEAD ne doit pas utiliser une logique de routage différente de GET, et OPTIONS doit rendre les méthodes proposées compréhensibles.

Un test manuel minimal se présente ainsi :

curl -sS -D - -o /dev/null \
  "https://id.gs1.org/01/09506000134352"

curl -sS -I \
  "https://id.gs1.org/01/09506000134352"

Documentez le code d’état, Location, les en-têtes de cache et le nombre de redirections. Une boucle de redirection, une cible aléatoire ou un chemin différent selon la méthode constitue un échec de validation, même si un smartphone finit par afficher une page.

3. Demander un jeu de liens plutôt qu’une page web

Le contrôle machine le plus important porte sur le jeu de liens :

curl -sS \
  -H "Accept: application/linkset+json" \
  "https://id.gs1.org/01/09506000134352"

Le RFC 9264 définit application/linkset+json comme une représentation JSON autonome d’un ensemble de liens web typés. GS1 renforce le contrat : la sortie doit être valide par rapport au schéma normatif du jeu de liens pour la version 1.2.0. Ne vérifiez donc pas seulement qu’un JSON est renvoyé, mais aussi le type MIME, le schéma, les URI cibles absolus, l’ancre et les relations de liens.

Les jeux de liens formellement valides mais incorrects sur le plan métier sont particulièrement trompeurs : par exemple, un manuel associé au type de lien d’une page d’informations produit ou une cible liée à un numéro de série au niveau GTIN. La validation du schéma et les jeux de données métier doivent donc être utilisés conjointement.

4. Contrôler la description du résolveur

Un résolveur conforme fournit sous /.well-known/gs1resolver une description lisible par machine. Celle-ci indique notamment la racine du résolveur et les clés primaires prises en charge. Le fichier doit être valide par rapport au schéma GS1 pour les fichiers de description de résolveur.

Ce test permet d’éviter une incohérence fréquente : le service peut prendre en charge davantage ou moins d’éléments que ne l’affirme sa propre description. Intégrez donc à l’acceptation à la fois la validation du schéma et une comparaison avec des cas de test réels.

5. Tester CORS et la négociation de contenu

CORS n’est pas une fonctionnalité de confort. Le standard l’impose afin que les applications basées sur navigateur puissent interroger le résolveur entre domaines. Testez au minimum une origine de navigateur autorisée ainsi que le parcours de prévalidation. Vérifiez également si Accept: application/linkset+json et linkType=linkset fournissent des résultats cohérents.

Ajoutez un test négatif pour un type MIME non pris en charge. Un service qui renvoie toujours du HTML, quel que soit l’en-tête Accept, reste accessible aux utilisateurs, mais n’est pas lisible de manière fiable par les machines.

6. Couvrir la langue, le contexte et la granularité

Le standard prévoit Accept-Language ainsi que le paramètre de requête context pour distinguer plusieurs liens correspondants. Tous les résolveurs ne sont pas obligés de proposer chaque variante. En revanche, lorsque la langue ou le contexte sont pris en charge, les règles de sélection doivent être reproductibles.

Testez donc une langue disponible, une langue indisponible et un ordre de repli défini. Le même principe s’applique à GTIN, au lot et au numéro de série : un identifiant plus précis peut prendre en compte des liens pertinents de niveaux supérieurs, sans brouiller l’affectation métier. Consignez le nombre de liens attendu comme jeu de données de test ; les tests instantanés reposant uniquement sur l’ordre sont trop fragiles.

7. Distinguer les erreurs sémantiquement

Les codes d’erreur font partie du contrat. Le standard du résolveur prévoit, pour les identifiants GS1 syntaxiquement invalides, un message avec HTTP 400. Lorsqu’un type de lien concret mais indisponible est demandé, une redirection vers la cible par défaut n’est précisément pas la bonne réponse. Ces cas doivent être distingués de celui d’un identifiant inconnu mais syntaxiquement valide.

Vérifiez également que les réponses d’erreur ne divulguent aucun détail interne, jeton ou trace d’exécution, et que GET, HEAD et les requêtes depuis un navigateur conservent la même sémantique. Un joli document d’erreur HTML ne peut pas compenser un code d’état incorrect.

Bien utiliser la suite de tests GS1

La suite de tests publique reçoit un URI et vérifie son comportement par rapport au résolveur 1.2.0. Elle convient bien comme contrôle indépendant de bon fonctionnement et de conformité. Pour la validation, enregistrez la date du test, l’URI testé, la version du standard, le résultat et, le cas échéant, les cas d’erreur reproductibles.

La suite ne remplace toutefois pas votre propre régression. GS1 précise explicitement qu’elle ne vérifie pas encore la compression. Si votre résolveur traite des chaînes binaires EPC ou d’autres formes compressées, vous aurez besoin de vecteurs de test distincts. De même, la suite publique ne connaît ni vos types de liens métier ni vos exigences en matière d’autorisation, de gestion multi-tenant ou de disponibilité.

Un processus robuste combine donc trois niveaux :

la suite GS1 publique comme contrôle de conformité externe ;
des tests de schéma pour le jeu de liens et la description du résolveur dans la CI ;
vos propres tests de bout en bout pour les identifiants réels, les rôles, les langues et les pannes.

Ce que doit contenir le dossier de validation

Une validation n’est reproductible que si le résultat n’est pas seulement visible dans le navigateur, mais aussi documenté. Le dossier de validation doit au minimum contenir la version du standard et de la suite, l’instant du test, l’environnement cible, les URI de test, les types de liens attendus, les résultats HTTP, la validation du schéma, le contrôle CORS et les exceptions connues.

Automatisez les éléments stables dans la CI, mais maintenez un passage externe ciblé contre la suite publique avant toute modification importante du résolveur. Ainsi, « le code QR s’ouvre » devient une affirmation vérifiable sur l’identité, le routage et les informations produit lisibles par machine.