Les normes européennes que nous parlons

Nous publions des model cards lisibles par machine pour les modèles de matching et de prédiction, nous conservons une explication facteur par facteur des premiers résultats d’une recherche talent-match et nous la montrons à l’étudiant sur /matches/[id]/why. Les opérations sensibles sont écrites dans un journal d’audit.

Le registre des algorithmes et les explications par match sont actifs sur la recherche talent-match. Les tests de biais, la couverture des autres systèmes de scoring et la documentation technique de l’annexe IV n’existent pas.

Exposition en libre-service des droits art. 15/16/17/20. Consentement aux cookies par catégorie. Base de données principale dans l’Union européenne ; la page vie privée indique quels sous-traitants sont hors EEE et sur quelle base de transfert.

L’accès, la rectification, l’effacement et la portabilité sont en libre-service. L’examen humain au titre de l’art. 22 se demande dans le produit depuis l’explication du match : la demande est enregistrée avec une référence et une échéance à 30 jours et, à la clôture, la décision du relecteur est réinscrite sur l’explication. Les visiteurs non connectés et la page du registre des algorithmes renvoient encore à l’e-mail.

Aujourd’hui : un journal d’audit sur les opérations sensibles, un registre public de model cards et une décision humaine obligatoire dans le tri de la Talent Suite. Les tests de biais et la documentation de gouvernance des données n’existent pas.

Nous ne sommes pas certifiés ISO/IEC 42001 et nous n’avons pas de système de management de l’IA documenté.

Les termes de compétences sont résolus en URI ESCO d'abord via notre table SkillMapping, puis via un petit référentiel curé, puis via l'API ESCO en direct, les résultats étant mis en cache dans SkillMapping. Le matching unifie les termes de compétences à travers cet index mappé sur ESCO. Le score de matching lui-même ne porte pas d'URI ESCO.

Les étudiants exportent leur profil fondé sur des preuves au format Europass v3 JSON-LD en un seul clic.

Chaque Verifiable Credential que nous émettons est exportable au format EDCI JSON-LD avec la preuve Ed25519 préservée. L'export d'un credential isolé porte aussi le niveau CEC (EQF) figurant au dossier de l'étudiant, lorsqu'il y en a un.

Les attestations sont émises dans la forme documentaire des W3C Verifiable Credentials et signées en Ed25519 sur une sérialisation JSON canonique qui nous est propre — pas la suite W3C Ed25519Signature2020, qui exige la canonicalisation RDF URDNA2015 et un proofValue multibase. La clé publique est publiée pour la vérification hors ligne.

Les étudiants exportent leurs compétences de niveau Avancé/Expert sous forme de credentials Open Badges 3.0.

Les compétences numériques de notre catalogue reprennent les noms et domaines de DigComp. Les identifiants que nous attribuons ne sont pas des URI publiés par le JRC.

Les compétences entrepreneuriales reprennent les noms et domaines d'EntreComp, avec les mêmes limites sur les identifiants.

Les compétences en durabilité reprennent les noms et domaines de GreenComp, avec les mêmes limites sur les identifiants.

Les niveaux EQF sont attribués par l'autorité qui délivre le titre, et non déduits par nous. L'export EDCI d'une attestation individuelle ne reprend qu'un niveau déjà inscrit au dossier de l'étudiant, et omet le champ lorsqu'il n'y en a aucun.

Un endpoint de métadonnées SAML de substitution existe et renvoie un descripteur vide. Le flux d’authentification n’est pas construit.

Scaffold SPID/CIE : liste typée d’IdP et modèle d’attributs. Aucun flux de connexion câblé ; l’enregistrement auprès de l’AgID est en attente.

Les credentials EDCI et W3C VC que nous émettons sont dans les formats que les wallets EUDIW devraient lire ; aucune intégration wallet n'a encore été construite ni testée.

Les credentials sont déjà compatibles EDCI. L'intégration wallet arrivera quand les implémentations de référence atteindront la bêta publique.

Le modèle de données des équivalences ECTS existe, mais aucun écran ne l'utilise aujourd'hui.

L'export des inscriptions en échange au format OLA JSON-LD existe comme endpoint d'API ; aucun écran ne l'appelle aujourd'hui. L'intégration au réseau EWP nécessite un onboarding SAML par établissement.

Le modèle de données des accords bilatéraux existe ; aucun écran ne l'utilise aujourd'hui.

Non connecté au réseau EWP : aucun endpoint enregistré.

Il n'existe pas d'intégration avec le réseau ENIC-NARIC.

Prévu, sans date.