JSON-LD expliqué
JSON-LD, c'est du JSON ordinaire avec une ligne supplémentaire qui dit ce que signifient les champs. Cette ligne transforme un nom de champ local en nom défini mondialement, de sorte qu'un système qui n'a jamais vu vos données peut tout de même comprendre de quoi vous parlez. C'est une norme du W3C depuis 2014, c'est ainsi que les moteurs de recherche lisent cette page même, et c'est sur cette base qu'est construit le modèle de données du W3C pour les attestations vérifiables.
Le problème du JSON ordinaire
JSON dit comment les données sont écrites. Il ne dit rien de ce qu'elles signifient. Un champ nommé name peut être une personne, une entreprise ou un produit. Un champ nommé id peut être un numéro client, un numéro de passeport ou une ligne dans la base de données de quelqu'un. Deux systèmes peuvent tous deux produire du JSON parfaitement valide et pourtant être en désaccord sur chacun de ses champs.
En pratique, cet écart se comble par un accord. Les deux parties consignent ce que signifient les champs et construisent leur logiciel en conséquence. Cela fonctionne pour une intégration, devient coûteux à dix, et cesse complètement de fonctionner lorsqu'une attestation délivrée dans un pays doit être comprise par un vérificateur d'un autre pays à qui personne n'a parlé au préalable.
Ce que fait le @context
JSON-LD comble cet écart à l'intérieur même du document. Un @context associe chaque nom de champ abrégé à un identifiant unique au niveau mondial, en général une URL contrôlée par celui qui a défini le vocabulaire. Le champ reste court et lisible pour un humain et devient sans ambiguïté pour une machine.
JSON ordinaire
{
"name": "Alex Jansen",
"birthDate": "1994-03-21",
"jobTitle": "Compliance Officer"
}Valide, lisible et dépourvu de sens pour quiconque n'a pas été informé à l'avance de ce que les champs sont censés contenir.
Les mêmes données en JSON-LD
{
"@context": "https://schema.org",
"@type": "Person",
"name": "Alex Jansen",
"birthDate": "1994-03-21",
"jobTitle": "Compliance Officer"
}Chaque champ pointe désormais vers une définition publiée, de sorte qu'un système qui n'a jamais vu ce document peut quand même le lire correctement.
- @context nomme le vocabulaire dans lequel chaque champ du document est défini.
- @type indique quel genre de chose le document décrit, afin que les bonnes définitions soient choisies dans ce vocabulaire.
Rien ne change dans les données elles-mêmes. Les mêmes valeurs, dans la même forme, portent désormais un renvoi vers la définition de chaque champ. Un système récepteur qui reconnaît le vocabulaire sait exactement ce qu'il a reçu, et un système qui ne le reconnaît pas peut toujours lire le document comme du JSON ordinaire et ignorer le reste.
C'est toute l'idée. Le sens voyage avec le document au lieu de résider dans une spécification sur laquelle les deux parties devaient s'entendre à l'avance.
Où il apparaît dans les attestations vérifiables
Le W3C Verifiable Credentials Data Model 2.0, W3C Recommendation depuis le 15 mai 2025, est construit sur JSON-LD. Chaque attestation s'ouvre sur un @context dont la première valeur est le vocabulaire partagé des attestations, de sorte que les termes communs à toutes les attestations, l'émetteur, le sujet, les dates de validité et les informations de statut, signifient partout la même chose.
Tout le reste provient d'un second vocabulaire. Une université en publie un pour les champs de diplôme, une chambre de commerce un autre pour les champs d'immatriculation d'entreprise. Un vérificateur qui s'intéresse aux diplômes charge le premier, un vérificateur qui s'intéresse aux données d'entreprise charge le second, et ni l'un ni l'autre n'a besoin d'être modifié quand l'autre ajoute un champ.
C'est ce qui permet à un même format d'attestation de porter des données que personne n'avait prévues lorsque le format a été écrit, et c'est la propriété dont un écosystème ouvert a besoin et dont un profil fermé se passe.
Signer des données liées
Une attestation doit aussi être signée, et le modèle de données laisse délibérément un choix à cet endroit. Une preuve enveloppante emballe toute l'attestation dans un conteneur de signature tel qu'un JWT. Les octets sont signés exactement tels qu'ils sont, de sorte que tout ce qui les réordonne ou les reformate en chemin casse la signature.
Une preuve Data Integrity intégrée fonctionne dans l'autre sens. Le document est d'abord mis sous une forme canonique, définie par RDF Dataset Canonicalization et W3C Recommendation depuis le 21 mai 2024, et la signature couvre cette forme plutôt que les octets. Comme la forme canonique ne dépend ni de l'ordre des clés, ni des espaces, ni des noms abrégés que le @context emploie, la signature survit à une réécriture ailleurs.
Sa place dans l'EUDI Wallet
Pas là où la plupart des gens le supposent. L'Architecture and Reference Framework désigne deux formats d'attestation pour le portefeuille européen, SD-JWT VC et mdoc, et aucun des deux n'est JSON-LD. Une organisation qui émet aujourd'hui vers l'EUDI Wallet ne rencontrera aucun @context en chemin.
Le raisonnement tient à la facilité de mise en œuvre. Les deux formats ont une structure figée, un seul mécanisme de signature et aucun document qu'un vérificateur doive aller chercher avant de pouvoir contrôler quoi que ce soit. Pour un portefeuille qui tourne sur un téléphone et un vérificateur qui doit répondre en quelques millisecondes, cela vaut plus qu'un vocabulaire ouvert.
JSON-LD gagne sa place là où les données doivent voyager au-delà de l'écosystème qui les a définies : passeports produits et données de chaîne d'approvisionnement, pilotes intersectoriels, et types d'attestation qu'aucun profil central ne recensera jamais. Les deux mondes se recoupent plus souvent qu'ils ne s'opposent, et les organisations qui travaillent dans les deux finissent généralement par prendre en charge les deux.
L'autre JSON-LD, celui que vous utilisez déjà
Bien avant les attestations, JSON-LD est devenu la manière dont un site web indique à un moteur de recherche de quoi parle une page. Un bloc de JSON-LD dans le code source de la page, avec le vocabulaire de schema.org, est ce qui transforme une page en article, produit, événement ou organisation reconnus. Cette page en porte un.
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "JSON-LD expliqué",
"description": "Ce que JSON-LD ajoute au JSON ordinaire, comment un @context donne un sens unique à chaque champ et où les attestations vérifiables l'utilisent.",
"image": "https://www.credenco.com/images/og-default.jpg",
"datePublished": "2026-10-15",
"dateModified": "2026-10-15",
"inLanguage": "fr",
"mainEntityOfPage": "https://www.credenco.com/fr/explained/json-ld",
"author": {
"@type": "Organization",
"name": "Credenco",
"url": "https://www.credenco.com/"
},
"publisher": {
"@type": "Organization",
"name": "Credenco",
"logo": {
"@type": "ImageObject",
"url": "https://www.credenco.com/logo.svg"
}
}
}C'est le même format avec un vocabulaire différent, et c'est la façon la plus claire de saisir l'idée. Personne ici n'a conclu d'accord avec un quelconque moteur de recherche. Le @context pointe vers schema.org, le moteur de recherche connaît déjà ce vocabulaire, et la page est comprise par une partie à qui elle n'a jamais parlé. Une attestation qui franchit une frontière fait exactement la même chose.
Ce que cela coûte
Le contexte doit être disponible. Un vérificateur qui le récupère au moment de la vérification a ajouté une dépendance réseau à une décision de sécurité, et celui qui sert ce document peut changer ce que l'attestation semble dire. Les déploiements réels figent les contextes qu'ils acceptent et les livrent avec le logiciel au lieu de les résoudre en direct.
La canonisation représente aussi un vrai travail. Transformer un document en jeu de données canonique avant de le signer demande nettement plus de code que de signer des octets, et les modes de défaillance sont subtils. Les documents sont également plus volumineux, ce qui commence à compter sur un code QR ou lors d'un échange NFC.
Rien de tout cela ne fait de JSON-LD un mauvais choix. Cela en fait un choix : payez pour des vocabulaires ouverts là où les données doivent survivre à l'accord qui les a créées, et passez-vous-en là où un profil figé dit déjà tout ce dont les deux parties ont besoin.
Ce que cela signifie pour vous
Émetteur
Émettre vers l'EUDI Wallet signifie SD-JWT VC ou mdoc, et JSON-LD n'entre jamais en jeu. Émettre vers un écosystème W3C fait de votre @context un engagement de long terme : c'est la définition publique de vos champs, et la modifier casse tout vérificateur qui a mis l'ancienne en cache.
Vérificateur
Décidez quels contextes vous acceptez et livrez-les avec votre logiciel. En récupérer un pendant la vérification fait d'un serveur distant une partie de votre décision de sécurité et place un appel réseau au milieu de votre temps de réponse.
Développeur
Lisez un document JSON-LD comme du JSON ordinaire quand vous n'avez besoin que d'un champ, et ne sortez un processeur complet que là où vous développez ou canonisez réellement. L'essentiel de la complexité que l'on attribue à JSON-LD se trouve dans le chemin de signature, pas dans celui de la lecture.
Termes associés
Questions fréquentes
JSON-LD reste-t-il du simple JSON ?
Oui. Tout document JSON-LD est du JSON valide, et un logiciel qui n'a besoin que de lire un champ peut le traiter comme tel. La mécanique supplémentaire n'intervient que lorsque vous développez un document dans sa forme complète ou que vous le canonisez pour le signer, ce que la plupart du code qui lit une attestation ne fait jamais.
L'EUDI Wallet utilise-t-il JSON-LD ?
Non. L'Architecture and Reference Framework désigne SD-JWT VC et mdoc comme formats d'attestation, et aucun des deux n'utilise JSON-LD. Il compte pour les écosystèmes W3C d'attestations vérifiables, les passeports produits et les données de chaîne d'approvisionnement, pas pour le portefeuille européen lui-même.
Un vérificateur télécharge-t-il le @context à chaque fois ?
Il ne devrait pas. Récupérer un contexte pendant la vérification place un appel réseau au cœur d'une décision de sécurité et donne à un serveur distant la possibilité de changer ce que le document semble dire. Les implémentations figent les contextes qu'elles acceptent et les livrent avec le logiciel, ce qui supprime aussi la latence.
Est-ce le même JSON-LD que lisent les moteurs de recherche ?
Le même format avec un vocabulaire différent. Les données structurées d'une page web pointent leur @context vers schema.org, tandis qu'une attestation le pointe vers le vocabulaire des attestations et vers ce dont elle a besoin en plus. Les règles de traitement sont identiques dans les deux cas.
Sources
Cette page est informative et ne constitue pas un conseil juridique. Pour des orientations faisant autorité, consultez directement les spécifications du W3C.