Remplacer les Open Badges natifs de Moodle par Badges Ninja (meilleur créateur, même API)

Moodle délivre des Open Badges en natif depuis la version 2.5, et pour beaucoup d’administrateurs de cours, c’est une raison suffisante pour ne jamais regarder ailleurs. C’est intégré, c’est gratuit, et ça produit techniquement un identifiant conforme aux standards. Alors pourquoi tant d’administrateurs Moodle finissent-ils frustrés au moment d’émettre leur cinquantième badge ?

La réponse honnête : le système de badges de Moodle a été conçu pour cocher une case de conformité, pas pour être un produit de certification à part entière. Ça fonctionne, mais ça fonctionne comme une fonctionnalité greffée sur un LMS — fonctionnel, daté, et enfermé dans les contraintes de la plateforme qui l’héberge. Si vous avez déjà essayé de faire ressembler un badge Moodle à autre chose qu’une icône ronde en clip-art, ou entendu un diplômé demander « attends, où est-ce que je le vois déjà, ce truc ? », vous connaissez déjà cet écart.

Ce n’est pas un réquisitoire contre Moodle — c’est un excellent LMS, et son moteur de critères de badges (validation de cours, validation d’activité, attribution manuelle, appartenance à une cohorte) est vraiment bien pensé pour déclencher un identifiant. Le problème se situe en aval du déclenchement : les outils de conception, l’expérience du destinataire, et la visibilité du badge en dehors de votre instance Moodle. C’est exactement ce pour quoi badges.ninja a été conçu, et vous n’avez pas besoin d’abandonner la logique de validation de Moodle pour l’utiliser — il suffit de pointer le déclencheur vers un autre moteur d’émission.

Là où les badges natifs de Moodle montrent leurs limites

Le créateur est un compositeur d’images basé sur des coordonnées, pas un outil de design. L’éditeur de badges de Moodle vous permet de choisir une image de base, d’y déposer quelques icônes prédéfinies et d’ajuster leur position au pixel près. Il n’y a ni bibliothèque de formes, ni système de palettes, ni choix de polices au-delà de celles intégrées au jeu d’icônes. Si votre organisation a une identité de marque — un logo, une palette de couleurs, un langage visuel spécifique pour ses certifications —, l’éditeur de Moodle ne peut tout simplement pas l’exprimer. La plupart des établissements finissent par concevoir leurs badges dans Photoshop ou Canva et par téléverser un simple PNG plat, ce qui annule tout l’intérêt d’avoir un créateur intégré à l’application.

Les destinataires ont besoin d’une connexion Moodle pour voir leurs propres badges. Les badges attribués à un apprenant vivent dans sa page de profil Moodle. S’il a terminé le cours, oublié ses identifiants institutionnels, ou si l’établissement a depuis supprimé son compte, le badge a effectivement disparu de son côté — même si l’assertion sous-jacente peut encore se résoudre via le connecteur backpack de Moodle ou la page publique du badge. Il n’existe aucun espace dédié, à l’image de la marque, toujours accessible, où un destinataire peut se connecter avec simplement son e-mail et voir chaque identifiant qu’il a jamais gagné, tous cours confondus.

Le partage est une réflexion après coup. Moodle peut pousser les badges vers un service compatible Mozilla Backpack et expose une URL de vérification publique pour chaque badge, mais il n’y a pas de flux « Ajouter à LinkedIn » intégré, pas de bouton de partage en un clic, et aucune analyse d’engagement pour savoir si quelqu’un a effectivement regardé le badge après son émission. Pour les programmes qui veulent que le badge fonctionne comme un levier de bouche-à-oreille — bootcamps, organismes de formation continue, formation en entreprise — c’est un vrai coût d’opportunité.

Les opérations en masse sont poussives. Attribuer un badge à toute une cohorte fonctionne si tout le monde termine l’activité déclencheuse dans Moodle au même moment. Mais si vous devez rattraper des badges pour une cohorte passée, importer des validations historiques depuis un tableur, ou émettre un badge pour quelque chose qui s’est produit entièrement en dehors du LMS, vous vous retrouvez à écrire du SQL contre la base de données de Moodle ou à batailler avec des outils d’import CSV qui n’ont pas été conçus spécifiquement pour les badges.

Le schéma de remplacement : garder les déclencheurs de Moodle, changer l’émetteur

Vous n’avez pas besoin de migrer hors de Moodle pour corriger ça. Le schéma le plus propre consiste à laisser Moodle continuer à faire ce qu’il fait bien — suivre la validation de cours, la validation d’activité, l’appartenance à une cohorte — et à lui faire appeler l’API Badges Ninja au moment où une condition de validation se déclenche, au lieu d’attribuer (ou en plus d’attribuer) son badge natif.

Moodle prend en charge cela de plusieurs façons :

1. Webhook de validation de cours / interrogation des Moodle Web Services (REST). L’API core_completion de Moodle expose l’état de validation par utilisateur et par cours. Une tâche planifiée légère (une tâche cron planifiée de Moodle, ou une tâche cron externe qui interroge l’API REST de Moodle) peut vérifier les inscriptions nouvellement validées et, pour chacune, appeler le point de terminaison awards de Badges Ninja.

2. Un hook de plugin local. Si vous avez un développeur dans votre équipe, le système d’événements de Moodle (\core\event\course_completed) peut être observé par un petit plugin local qui envoie une requête HTTP à l’instant même où la validation se produit — sans délai d’interrogation.

3. Zapier/Make/n8n comme colle, si vous préférez éviter de toucher au code de Moodle — Moodle peut pousser les événements de validation vers un récepteur de webhook qu’un outil d’automatisation sans code transforme en appel d’attribution.

Voici l’appel d’attribution proprement dit, une fois que vous avez le nom et l’e-mail d’un utilisateur ayant validé son cours :

curl -X POST https://api.badges.ninja/awards \
  -H "X-Api-Key: bws_3f9a1c2d4e5b6a7c8d9e0f1a2b3c4d5e" \
  -H "Content-Type: application/json" \
  -d '{
    "badgeId": "badge_moodle_course_completion",
    "recipient": { "name": "Jordan Alvarez", "email": "learner@example.edu" },
    "issuedOn": "2026-08-31"
  }'

Ou en Node, à l’intérieur de la tâche planifiée ou du récepteur de webhook que vous utilisez :

const response = await fetch("https://api.badges.ninja/awards", {
  method: "POST",
  headers: {
    "X-Api-Key": process.env.BADGES_NINJA_API_KEY,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    badgeId: "badge_moodle_course_completion",
    recipient: { name: completedUser.fullname, email: completedUser.email },
    issuedOn: Date.now(),
  }),
});
const award = await response.json();

L’e-mail du destinataire est haché en SHA-256 au repos, l’attribution reçoit automatiquement une URL de vérification unique, un QR code et un certificat PDF au format A4 — et, point crucial, le destinataire peut le réclamer via une connexion par lien magique sur badges.ninja/me, sans avoir besoin d’un compte Moodle séparé. Consultez la structure complète des requêtes/réponses dans la référence de l’API awards et le guide d’authentification pour comprendre le fonctionnement des clés API de bout en bout.

Si vous préférez procéder par lots — par exemple pour rattraper tout un semestre de validations en une seule passe plutôt que de câbler des événements en temps réel —, exportez les validations depuis Moodle sous forme de CSV et utilisez directement le flux d’attribution en masse, qui prend en charge la pause/reprise pour les gros fichiers. Le sujet est détaillé dans comment émettre des Open Badges depuis un CSV.

Concevoir le badge lui-même

Une fois la plomberie en place, la conception du badge lui-même prend quelques minutes, pas un ticket à votre équipe web. Le créateur visuel vous donne plus de 80 modèles de formes, un véritable système de palette de couleurs, des bibliothèques d’icônes et le téléversement de polices personnalisées — pour qu’un badge « Statistiques avancées — Validé » puisse vraiment ressembler à quelque chose qui appartient à la marque de votre établissement plutôt qu’à une icône de réussite Moodle générique.

Chaque clé API dispose d’une portée définie et peut être révoquée depuis le même tableau de bord où vous gérez vos badges et vos émetteurs, donc confier l’identifiant d’intégration à un développeur (ou à un outil d’automatisation comme Zapier) ne signifie pas partager les identifiants de connexion de votre compte principal.

Comparatif côte à côte : expérience du destinataire

Moodle garde tout de même l’avantage sur un point : si votre seule exigence est « le badge existe, il est techniquement conforme à l’Open Badge v2.0, et il vit dans le LMS que l’apprenant utilise déjà », les badges natifs ne coûtent rien de plus et ne demandent aucun travail d’intégration. Le compromis apparaît dès que vous vous souciez de la qualité du design, de la portabilité après la fin du cours, ou de la transformation de l’émission en signal de recrutement/marketing — ce qui finit par concerner la plupart des établissements.

Pour un panorama plus large de la façon dont les autres plateformes d’Open Badges se comparent en prix et en fonctionnalités, consultez le comparatif des plateformes Open Badges les moins chères. Et si votre établissement hésite entre l’Open Badge v2.0 et la spécification plus récente des identifiants vérifiables, Open Badge v2 vs v3 expliqué détaille lequel adopter concrètement aujourd’hui.

Prêt à émettre votre premier identifiant vérifiable ? Commencez gratuitement sur badges.ninja — créateur visuel, page de vérification publique, certificat PDF, sortie Open Badge v2.0. Aucune carte bancaire requise.