Quand j’utilise une ressource que je n’héberge pas, un stockage, un service de calcul, un jeu de données, je dois lui faire confiance sur des points que je ne peux pas voir : où elle tourne, sous quelle juridiction, avec quelles garanties, et qui en est responsable. En général, ces informations vivent sur une page commerciale ou dans une clause de contrat. Je les crois sur parole.

Les dataspaces, ces ensembles où plusieurs acteurs partagent des ressources, répondent autrement. Chaque ressource y est décrite dans un format que la machine sait lire, cette description est signée, et n’importe qui peut la vérifier sans rien demander à personne. Cet article explique comment cette description fonctionne, comment on la vérifie, et jusqu’où va la confiance qu’elle apporte.

Décrire la ressource dans un format que la machine lit

Le point de départ, c’est que la ressource se décrit elle-même. Elle le fait dans un document structuré que d’autres programmes peuvent lire et comparer, et non dans une fiche destinée à un lecteur humain. Dans le vocabulaire des dataspaces, ce document s’appelle une self-description.

Techniquement, c’est un Verifiable Credential du W3C, au format JSON-LD. Un Verifiable Credential est un ensemble d’affirmations (des claims) au sujet d’une entité, émis par quelqu’un et signé. Voici, simplifiée, la description d’un service de stockage.

{
  "@context": ["https://www.w3.org/ns/credentials/v2",
               "https://w3id.org/gaia-x/development#"],
  "type": ["VerifiableCredential"],
  "issuer": "did:web:stockage.example",
  "credentialSubject": {
    "id": "https://stockage.example/offres/objets-eu",
    "type": "gx:ServiceOffering",
    "gx:providedBy": "did:web:stockage.example",
    "gx:location": "FR",
    "gx:dataProtectionRegime": ["GDPR2016"],
    "gx:certification": "ISO/IEC 27001",
    "gx:endpoint": "https://stockage.example/connector"
  },
  "proof": {
    "type": "JsonWebSignature2020",
    "verificationMethod": "did:web:stockage.example#x509",
    "jws": "eyJhbGciOiJ..."
  }
}

Elle se lit sans difficulté. Le fournisseur (stockage.example) propose un service de stockage situé en France, soumis au RGPD, certifié ISO 27001, joignable à une adresse donnée. Le bloc proof, à la fin, contient la signature. La même structure sert pour un jeu de données ou pour le fournisseur lui-même : ressource comme participant, tout se décrit dans ce format unique.

Le bénéfice est concret. Là où chaque fournisseur présente d’habitude ses garanties à sa façon, tout le monde emploie ici le même vocabulaire structuré. Une juridiction se compare à une juridiction, une certification à une certification, par un programme, sans lecture humaine.

Une description signée et vérifiable

Une description, on peut l’écrire n’importe comment. Ce qui la rend fiable, c’est la signature.

Le format Verifiable Credential est devenu un standard du W3C en mai 2025. Sa propriété centrale est qu’un credential est inviolable, au sens où toute altération se voit, et que son auteur se vérifie cryptographiquement. Le modèle distingue trois rôles : l’émetteur (issuer) écrit et signe la description, le détenteur (holder) la présente, le vérificateur (verifier) la contrôle.

Les trois rôles : l'émetteur signe la description, le détenteur la présente, le vérificateur la contrôle hors ligne

Les trois rôles du modèle. L’émetteur signe la description, le détenteur la présente, le vérificateur la contrôle hors ligne avec la clé publique, sans recontacter l’émetteur.

Ce contrôle ne dépend de personne d’autre. Le vérificateur n’a pas besoin de rappeler l’émetteur, ni de se connecter à un serveur central, ni d’une autorisation. La signature se vérifie hors ligne, avec la clé publique. C’est le sens concret du mot « auditable » : une vérification que je peux faire moi-même, quand je veux, et non une promesse de transparence.

Remonter à une racine de confiance

Il reste un point faible. Une signature prouve que la description n’a pas été modifiée et qu’elle provient bien d’une certaine clé. Elle ne dit pas si je dois faire confiance au propriétaire de cette clé. N’importe qui peut signer une description affirmant « je suis situé en France et certifié ».

C’est le rôle de la racine de confiance. La clé qui signe doit se rattacher, par une chaîne de certificats, à une entité reconnue par le dataspace, ce qu’on appelle un trust anchor. Un service de conformité effectue cette vérification : il contrôle la forme de la description, vérifie chaque signature, et confirme que la clé remonte à une racine reconnue. Sans ce rattachement, la description est rejetée.

Le résultat d’une vérification ressemble à ceci.

{
  "signatureValid": true,
  "chainsToTrustAnchor": true,
  "trustAnchor": "did:web:registre.example",
  "issuerVerified": true
}

À ce stade, je ne fais plus confiance sur parole. La description est intègre, elle provient d’un acteur dont l’identité a été établie, et ses affirmations engagent quelqu’un d’identifiable. Si le service prétend être en France sans l’être, ce n’est plus une ligne commerciale sans conséquence : c’est une affirmation signée, fausse, et traçable.

La donnée reste à la source

Un point important : décrire une ressource ne revient pas à la déplacer. Ce qui circule dans le dataspace, c’est la description, pas la donnée. La donnée reste chez son détenteur et ne se déplace, de pair à pair, que lorsqu’un accord a été négocié. Le dataspace n’est pas un entrepôt central où tout serait copié, mais une couche de descriptions vérifiables au-dessus de ressources qui restent à leur place.

La donnée reste chez le fournisseur ; seule la description signée est publiée au catalogue ; la donnée circule en pair à pair après un accord

La donnée reste chez le fournisseur. Seule la description signée est publiée au catalogue ; la donnée elle-même ne circule qu’en pair à pair, après un accord.

Sans acheter le discours qui va avec

Une objection légitime : tout ça vient de projets très marqués, avec un fort discours sur la souveraineté. On peut ne pas vouloir s’y abonner.

Bonne nouvelle, les briques sont des standards, pas le projet politique. Le Verifiable Credential est une recommandation du W3C. Les identifiants décentralisés (DID) aussi. Les vocabulaires de description, les langages de politique, les catalogues, sont des spécifications ouvertes. Plusieurs implémentations existent, dont des composants Eclipse réutilisables hors de tout label. On peut prendre la mécanique, décrire et vérifier des ressources, sans rien adopter du reste. La partie qui m’intéresse n’est pas une idéologie, c’est un format et une signature.

Quand la description ne suffit pas : l’attestation

Tout ce qui précède apporte une chose : la certitude vérifiable de ce qu’une ressource déclare être. C’est déjà beaucoup, mais cela reste déclaratif. Le service déclare être en France et certifié, et je peux le vérifier ; rien ne garantit encore que ma donnée, une fois envoyée chez lui, sera traitée comme prévu.

Pour combler cet écart, certains dataspaces vont plus loin et demandent à l’infrastructure de prouver son intégrité avant de recevoir quoi que ce soit. C’est le principe de l’attestation distante. Avant de libérer une donnée, le connecteur d’en face prouve, matériellement, qu’il exécute une pile logicielle approuvée et non modifiée. La preuve s’appuie sur du matériel dédié, une puce TPM et un démarrage mesuré, qui enregistrent l’état du système et le présentent de façon non falsifiable. Tant que cette preuve n’est pas fournie et validée, la donnée ne part pas.

La preuve d’intégrité ressemble à ceci.

{
  "attestation": {
    "platform": "did:web:client.example",
    "measuredBoot": "sha256:7f3a...e21",
    "stack": "trusted-connector 1.4 (approuvée)",
    "tpm": "TPM 2.0",
    "verdict": "intègre"
  },
  "transferAllowed": true
}

Le Trusted Connector des Industrial Data Spaces procède ainsi : mesure d’intégrité, attestation distante, et négociation du niveau de confiance et de la politique d’usage avant le transfert. Une variante plus stricte, le confidential computing, protège la donnée pendant son traitement, de sorte que même l’opérateur de la machine ne puisse pas la lire.

La différence est nette. Avec la seule description signée, l’infrastructure est un participant responsable : ce qu’elle déclare est vérifiable, et elle est imputable si elle ment. Avec l’attestation, elle devient un participant qui applique : elle ne reçoit la donnée qu’après avoir prouvé qu’elle la traitera comme convenu.

Deux niveaux de confiance : au niveau déclaratif on vérifie la signature et le rattachement à une racine de confiance ; au niveau attesté l'infrastructure prouve son intégrité avant de recevoir la donnée

Deux niveaux de confiance. Au niveau déclaratif, on vérifie ce que la ressource déclare. Avec l’attestation, l’infrastructure prouve son intégrité avant de recevoir la donnée.

Limites

Le niveau fort a un coût. Le matériel d’attestation, les connecteurs certifiés et le confidential computing ne sont pas le réglage par défaut, mais l’exception réservée aux cas sensibles. La plupart des échanges s’arrêtent au niveau déclaratif et s’appuient, pour le reste, sur le contrat et la traçabilité. La description vérifiable apporte l’imputabilité, pas l’impossibilité technique de mal faire.

Conclusion

Même au seul niveau déclaratif, quelque chose change. Je choisis une ressource sur des faits que je peux contrôler moi-même, et non sur sa fiche commerciale : sa juridiction, ses certifications et son responsable sont écrits dans un format unique, signés, et rattachés à une identité établie.

C’est une brique que je regarde de près pour mon coach sportif. Il manipule des données de santé et choisit déjà entre un traitement local et le cloud. Le jour où il devra dialoguer avec des ressources extérieures, pouvoir les vérifier plutôt que les croire ne sera pas un luxe. Ce sera le sujet d’un autre article.