Open Badge v2 vs v3 expliqué : quelle spécification utiliser aujourd'hui ?

Si vous mettez en place un programme de certification en 2026, vous tomberez sur cette question dès la première heure de recherche : faut-il émettre de l’Open Badge v2.0 ou le tout nouveau v3.0 ? La réponse honnête est « cela dépend de qui doit lire vos certifications » — mais ce n’est pas très satisfaisant si c’est vous qui devez trancher d’ici vendredi. Voyons donc ce qui a réellement changé entre les deux spécifications, qui prend en charge quoi aujourd’hui, et laquelle la plupart des émetteurs devraient adopter dès maintenant.

Ce qu’est réellement Open Badge v2.0

Open Badge v2.0 est la spécification de 1EdTech (anciennement IMS Global) qui constitue l’ossature de la certification numérique depuis 2017. Elle repose sur JSON-LD et s’articule autour de trois objets liés entre eux :

• IssuerOrg — l’émetteur de la certification (nom, URL, e-mail, logo)
• BadgeClass — le type de certification en lui-même (nom, description, critères, image)
• Assertion — l’attribution spécifique à un destinataire donné (identité du destinataire, date issuedOn, preuves, méthode de vérification)

L’Assertion d’un destinataire pointe vers une BadgeClass, qui pointe elle-même vers une IssuerOrg. La vérification se fait de deux façons : hébergée (le vérificateur récupère le JSON de l’Assertion en direct depuis une URL stable et fait confiance au domaine) ou signée (l’Assertion porte une signature JWS que le vérificateur contrôle par rapport à la clé publique publiée par l’émetteur). La plupart des plateformes, dont badges.ninja, utilisent par défaut la vérification hébergée, avec la signature en option, car l’hébergée est plus simple à implémenter et plus facile à contrôler visuellement pour un humain.

Voici une Assertion v2.0 simplifiée, le genre de réponse que vous obtiendriez avec un appel GET /awards/{id} :

{
  "@context": "https://w3id.org/openbadges/v2",
  "type": "Assertion",
  "id": "https://badges.ninja/certify-badge/award/9f2a1c...",
  "recipient": {
    "type": "email",
    "hashed": true,
    "salt": "a1b2c3",
    "identity": "sha256$8f14e45..."
  },
  "badge": "https://badges.ninja/certify-badge/badge/7d3e...",
  "issuedOn": "2026-08-01T00:00:00Z",
  "verification": { "type": "hosted" }
}

C’est cette structure qui a fait de v2.0 le standard de facto : elle est assez simple pour être implémentée en une après-midi, et c’est ce que quasiment tous les consommateurs de données de badges s’attendent à voir.

Vérification hébergée vs signée en v2.0

Il vaut la peine de comprendre les deux modes de vérification au sein même de v2.0, car on confond souvent « v2.0 est moins sécurisé que v3.0 » avec « la vérification hébergée est moins sécurisée que la signée ». Ce ne sont pas les mêmes axes.

• Hébergée — le verification.type vaut "hosted", et l’id de l’Assertion est une URL en direct. Un vérificateur récupère cette URL et vérifie que la réponse correspond ; la confiance repose sur le contrôle du domaine (par exemple, seul badges.ninja peut publier sur badges.ninja/certify-badge/award/...). C’est ce qu’utilisent la plupart des pages de vérification grand public, car un humain n’a qu’à cliquer sur le lien.
• Signée — le verification.type vaut "signed", et l’Assertion porte (ou référence) une signature JWS sur le contenu. Un vérificateur résout la clé publique de l’émetteur et vérifie la signature indépendamment de l’accessibilité d’une quelconque URL. C’est plus proche, dans l’esprit, du modèle de v3.0, simplement sans la couche DID.

Voici à quoi ressemble une vérification de signature minimale en Node :

import { jwtVerify, importJWK } from 'jose';

const publicKey = await importJWK(issuerJwk, 'RS256');
const { payload } = await jwtVerify(assertionJws, publicKey);
// payload now contains the verified Assertion claims

Si votre programme tient à ce que les certifications restent vérifiables même après que votre API soit hors ligne pour maintenance, la v2.0 signée vous apporte l’essentiel du bénéfice de durabilité de v3.0, sans avoir à adopter les DID.

Ce que change Open Badge v3.0

Open Badge v3.0 est une réécriture bâtie sur le W3C Verifiable Credentials (VC) Data Model, et non une mise à jour incrémentale du format JSON-LD de v2.0. Voici les différences qui comptent en pratique :

• Signature cryptographique par défaut. Chaque certification v3.0 est un VC signé — il n’existe pas de repli du type « hébergée, on fait confiance à l’URL ». La vérification est toujours mathématique, jamais fondée sur le domaine.
• Identité de l’émetteur fondée sur un DID. Au lieu d’un objet IssuerOrg avec une URL et un e-mail, l’émetteur est identifié par un identifiant décentralisé (DID), qui se résout en un document de clé publique.
• Alignement avec le Comprehensive Learner Record (CLR) 2.0. La v3.0 a été conçue pour interopérer avec le CLR, si bien qu’une seule certification peut porter à la fois les données de réussite et le niveau de détail structuré de relevé de notes attendu par les consommateurs de CLR (compétences, résultats d’évaluation, contexte de trimestre/cours).
• Compatibilité avec les portefeuilles numériques. Comme les certifications v3.0 sont des VC W3C standards, elles peuvent être conservées dans des portefeuilles d’identité, au même titre qu’un permis de conduire ou un certificat de vaccination — pas seulement affichées sur une page web.

En résumé : v2.0 répond à la question « un humain ou un script simple peut-il vérifier cette certification ? », et v3.0 répond à la question « cette certification peut-elle interopérer avec l’écosystème plus large des verifiable credentials — portefeuilles, DID, relevés d’apprentissage formels ? »

Comparaison côte à côte

Pourquoi la base installée tourne encore sur v2.0

C’est l’élément qui fait pencher la balance pour la plupart des programmes : les endroits où vos destinataires veulent réellement voir apparaître leurs certifications attendent toujours du v2.0. Le flux Add to Profile de LinkedIn, Credly, Badgr, et la grande majorité des intégrations ATS analysent le format Assertion/BadgeClass de v2.0. Si votre objectif est que « les destinataires puissent publier leur certification sur LinkedIn et que les recruteurs puissent cliquer pour la vérifier », v2.0 n’est pas un format hérité dont vous êtes prisonnier — c’est la langue que parle actuellement l’écosystème.

Nous avons traité cette même tension du point de vue du destinataire dans LinkedIn Skill Assessments vs Open Badges — la valeur d’un badge dépend en grande partie de la facilité avec laquelle il s’intègre aux endroits que recruteurs et pairs consultent déjà, et aujourd’hui, cette infrastructure est très majoritairement façonnée par v2.0.

Quand v3.0 fait réellement la différence

v3.0 n’est pas qu’un effet de mode — elle résout de vrais problèmes pour des programmes spécifiques :

• Universités et émetteurs soumis à des obligations CLR. Si vous émettez en parallèle d’un système de relevé de notes formel, ou qu’un organisme éducatif régional/étatique exige une sortie compatible CLR 2.0, l’alignement natif de v3.0 vous évite de devoir greffer des champs CLR sur une Assertion v2.0.
• Programmes visant le stockage en portefeuille numérique. Si vos destinataires doivent conserver la certification dans une application de portefeuille plutôt que simplement l’afficher sur une page web, seul un VC W3C (donc v3.0) fonctionnera nativement pour cela.
• Échange de certifications entre émetteurs avec confiance fondée sur les DID. Si vous construisez ou rejoignez un réseau où l’identité de l’émetteur doit être portable de façon cryptographique plutôt que reposer sur « faites confiance à cette URL », les DID sont la bonne brique de base.

Aucun de ces cas n’est fréquent pour un programme de formation, un bootcamp ou un émetteur de développement professionnel en 2026. Ils sont fréquents pour des institutions soumises à des exigences de conformité ou d’interopérabilité qui citent explicitement le CLR ou les VC W3C.

Une certification v3.0 simplifiée montre à quel point l’enveloppe diffère, même quand les données de réussite sous-jacentes représentent conceptuellement la même récompense :

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/ob/v3p0/context.json"
  ],
  "type": ["VerifiableCredential", "OpenBadgeCredential"],
  "issuer": { "id": "did:web:issuer.example.edu" },
  "credentialSubject": {
    "type": "AchievementSubject",
    "achievement": { "type": "Achievement", "name": "Developer Associate" }
  },
  "proof": { "type": "DataIntegrityProof", "cryptosuite": "eddsa-2022" }
}

Remarquez que le champ issuer est un DID, pas une URL, et que tout le document porte un bloc proof au lieu d’un pointeur verification. C’est l’outillage de résolution de DID et de signature de VC mentionné plus haut — un vrai travail d’ingénierie, et un travail perdu si rien en aval ne le consomme encore réellement.

Idées reçues à corriger

• « v3.0 est plus sécurisé ». Pas forcément — la v2.0 signée et la v3.0 reposent toutes les deux sur une vérification cryptographique. L’avantage de v3.0 réside dans la standardisation de l’identité (DID) et l’interopérabilité avec les portefeuilles, pas dans une amélioration de sécurité par rapport à la v2.0 signée.
• « v2.0 est obsolète ». Ce n’est pas le cas. 1EdTech maintient les deux spécifications, et v2.0 reste la version référencée par les plateformes et intégrations que les émetteurs utilisent réellement au quotidien.
• « Il faut choisir une seule version pour tout le programme ». Faux. Rien n’empêche un émetteur de publier en v2.0 pour un usage général et d’ajouter une sortie v3.0 pour une intégration partenaire spécifique qui l’exige — les données de récompense sous-jacentes ne changent pas, seule la représentation change.

Le chemin de migration (et pourquoi vous n’avez pas à choisir pour toujours)

La démarche pragmatique pour presque tous les émetteurs : livrez v2.0 maintenant, et traitez v3.0 comme un ajout, pas un remplacement, quand un consommateur en aval spécifique l’exige. Voici pourquoi cette approche fonctionne proprement :

1. Vos identifiants de BadgeClass et d’Assertion n’ont pas besoin de changer quand vous ajoutez le support v3.0 plus tard — vous ajoutez une seconde représentation, de forme différente, de la même récompense sous-jacente, sans migrer les certifications des destinataires existants.
2. Les vérificateurs qui ne comprennent que v2.0 continuent de fonctionner exactement comme avant.
3. Vous évitez de construire une infrastructure DID et des pipelines de signature de VC avant d’avoir une exigence concrète qui les nécessite.

C’est exactement la logique que nous appliquons en interne chez badges.ninja : chaque récompense sort sous forme d’Open Badge v2.0 — JSON-LD, vérification hébergée sur une URL stable /certify-badge/award/{guid}, prêt pour LinkedIn Add to Profile dès le départ — parce que c’est ce qui couvre l’écrasante majorité de ce qu’on demande réellement aux émetteurs de produire. Si votre programme a besoin plus tard d’une sortie v3.0/CLR pour un partenaire institutionnel spécifique, c’est un ajout ciblé au-dessus d’un pipeline v2.0 qui fonctionne déjà, pas une réécriture.

Cette manière de séquencer les choses vous protège aussi d’un risque plus subtil : vous engager dans une infrastructure DID avant de savoir quelle méthode de DID vos partenaires attendent réellement. L’écosystème des VC ne s’est pas encore accordé sur une méthode de DID unique — did:web, did:key, et des méthodes ancrées sur des registres distribués coexistent tous dans la nature, et se tromper de méthode pour un partenaire pilote signifie refaire plus tard le travail d’identité de l’émetteur. Attendre une exigence nommée, c’est s’assurer de savoir de quelle méthode vous avez réellement besoin avant de construire quoi que ce soit.

Un test rapide pour votre propre programme

Posez-vous ces trois questions avant de consacrer du temps d’ingénierie à v3.0 :

• Un consommateur de mes certifications — un ATS employeur, un organisme de licence, une institution partenaire — exige-t-il explicitement une sortie CLR 2.0 ou VC W3C ? Si non, v2.0 vous suffit.
• Mes destinataires doivent-ils conserver cette certification dans une application de portefeuille numérique, et pas seulement sur un profil web ou LinkedIn ? Si non, v2.0 vous suffit.
• Suis-je en train de construire une infrastructure de confiance inter-émetteurs où la vérification hébergée fondée sur une URL n’est réellement pas suffisante ? Si non, v2.0 vous suffit.

Si vous avez répondu « non » trois fois, vous n’êtes pas en retard en livrant du v2.0 en 2026 — vous faites correspondre la spécification à l’écosystème qui la consomme réellement. Reposez-vous la question quand un partenaire spécifique ou une exigence de conformité nommera explicitement v3.0 — pas parce que vous avez le sentiment général que « v3 est plus récent ».

Pour en savoir plus sur la manière dont les données de vérification de badges se comportent face aux formats de certification plus anciens et non standardisés, consultez Blockchain Certificates vs Open Badges, qui explore les compromis de vérification et de portabilité sous un angle différent.

---

Prêt à émettre votre première certification vérifiable ? Commencez gratuitement sur badges.ninja — concepteur visuel, page de vérification publique, certificat PDF, sortie Open Badge v2.0. Aucune carte bancaire requise.