Aller au contenu
Langue: FR
Menu

Enregistrements d’apprentissage

RODMENA LRS

Disponible sur demande

Le référentiel de preuves pour la formation, enregistrant ce qui s'est produit une fois et le conservant à l'identique.

Contactez-nous

RODMENA LRS is a Learning Record Store. It receives records of learning activity in the xAPI format, stores them unchanged and returns them through the standard xAPI query interface. It passes all tests in the ADL LRS Conformance Test Suite for xAPI 1.0.3 and xAPI 2.0. The database itself keeps customers’ records apart from one another. Record contents are encrypted at rest. Learner identifiers are stored only in a keyed, pseudonymous form. Stored records cannot be altered, though a learner’s personal data can be erased on request and the erasures are written to a tamper-evident log.

À qui il est destiné. Les plateformes d’apprentissage et les organismes de formation qui ont besoin d’un magasin conforme pour les enregistrements d’activité des apprenants. Il s’agit d’un service back-end sur lequel des produits sont conçus et qu’ils appellent depuis leurs serveurs ; les apprenants et les navigateurs n’interagissent pas directement avec lui. REES en est le premier utilisateur.

Statut
Disponible sur demande
Partie de
Offres
Licence
Propriétaire. Copyright RODMENA LIMITED, tous droits réservés.
Conformité
1,365 Tests de conformité xAPI 1.0.3, tous réussis
1,435 Tests de conformité xAPI 2.0, tous réussis
Vérifié le 23 septembre 2026
Étiquettes
xAPIEnregistrements d’apprentissageConformitéMulti-locataireProtection des donnéesPiste d’audit

Spécification technique

Rédigé pour un évaluateur technique. Une ligne sans valeur mesurée est omise.

Normes

xAPI 1.0.3
Spécification ADL Experience API, version 1.0.3
xAPI 2.0
IEEE 9274.1.1-2023
Sélection de version
Par requête, via l'en-tête X-Experience-API-Version. Les versions 1.0.x et 2.0.x sont acceptées, et une version manquante ou inconnue est refusée avec une erreur 400.
Suite de conformité
Suite de tests de conformité ADL LRS, dernière exécution le 23 septembre 2026
Résultat de conformité
xAPI 1.0.3 : 1 365 sur 1 365. xAPI 2.0 : 1 435 sur 1 435.
Au-delà de la suite
Lorsque la suite indique qu'elle ne teste pas une exigence, une vérification dédiée la prend en charge. Nous avons également identifié six tests de la suite qui ne font aucune assertion et les avons couverts séparément.
Par conception
OAuth 1.0 est obsolète et n'est pas accepté. Les produits créés sur le service l'appellent de serveur à serveur. Il n'accepte pas les appels cross-origin provenant d'un navigateur.

Interface

Ressources
Statements, State, Activity Profile, Agent Profile, Activities, Agents et About. Toutes les routes GET répondent également à HEAD.
Authentification
HTTP Basic en utilisant des identifiants émis par le service. Les secrets font 256 bits et sont uniquement stockés sous forme de vérificateur à clé. Les identifiants inconnus, désactivés et expirés reçoivent des réponses 401 identiques au bit près.
Syntaxe de requête alternative
Pris en charge sous 1.0.3 et refusé sous 2.0, car cette spécification l’exige.
Déclarations signées
JWS avec RS256, RS384 et RS512, vérifié lorsqu’un certificat est inclus.
Pièces jointes
multipart/mixed, mis en correspondance par hachage SHA-2. 5 Mio par pièce jointe et 1 Mio par corps de déclaration, tous deux configurables.
Pagination
Des curseurs sans état signés qui restent valides après un redémarrage. Toutes les réponses statements comportent l'en-tête de cohérence xAPI.
Idempotence
Le renvoi d’un identifiant de déclaration (statement id) identique est accepté sans duplication. Un identifiant en conflit est refusé avec 409.
Limitation de débit
Par identifiant, plus un quota distinct par adresse client pour les échecs d'authentification.

Isolation et sécurité

Isolation des locataires
Sécurité au niveau des lignes (row-level security) de PostgreSQL, activée et forcée sur chaque table contenant des données de locataires. Le rôle de base de données de l’application ne possède rien et ne peut pas la contourner. Chaque transaction tire son locataire du seul identifiant authentifié.
Isolation, appliquée
Un test du catalogue fait échouer la compilation si une table de locataire, ou une partition créée au moment de l’exécution, est dépourvue de la politique RLS.
Chiffrement au repos
AES-256-GCM sur les corps de déclaration, les documents, les pièces jointes, les définitions d’activité et les identités d’authentification, sous une clé par enregistrement dérivée avec HKDF-SHA256.
Liaison de texte chiffré
Un texte chiffré est lié à l'identité de sa ligne et ne se déchiffrera pas s'il est déplacé vers une autre ligne.
Garde des clés
Trois clés conservées en dehors de la base de données, dans des fichiers de clés en 0600 ou dans l’environnement. Il n’existe aucune clé par défaut, et le service refuse de démarrer sans elles.
Rotation des clés
La clé d'index fait l'objet d'une rotation par un renouvellement de clé hors ligne et interruptible, et la rotation de la clé d'identifiants réémet les identifiants. Dans la mesure où les enregistrements stockent l'identifiant de la clé qui les a écrits, une rotation ne requiert aucune migration de données.
Identifiants des apprenants
Conservé uniquement sous forme de jetons HMAC-SHA256 sous une clé par locataire, et un même apprenant dans deux locataires génère deux jetons sans lien. Aucune colonne ne conserve d'identité d'apprenant en clair.
Portées des identifiants
L'ensemble de périmètres xAPI comprenant statements/write, statements/read, statements/read/mine, state, profile, all/read et all. Le plus restreint lit uniquement les déclarations que ces identifiants ont eux-mêmes écrites.
Immutabilité
Des déclencheurs de base de données maintiennent les déclarations et les pièces jointes en ajout seul en refusant UPDATE, DELETE et TRUNCATE. Les seules modifications autorisées sont le drapeau d'invalidation et un effacement.
Transport de base de données
Le protocole TLS avec vérification intégrale du certificat et du nom d'hôte est obligatoire, et le service refuse de démarrer sans lui.
Événements d’audit des requêtes
Un événement structuré par requête, comportant l’identifiant de requête, l’identifiant de clé d’authentification, le locataire, la méthode, la ressource, le statut, le nombre d’enregistrements, la durée et les noms de filtres. Les valeurs des apprenants dans les filtres sont tokenisées avant d’être journalisées.
Détection des altérations
Le journal d'effacement est chaîné par hachage, et une seule commande vérifie l'ensemble de la chaîne, du premier au dernier maillon.

Protection des données

Effacement
Un caviardage de pseudonymisation. L'apprenant est remplacé par un pseudonyme aléatoire à chaque endroit où une déclaration peut le nommer, les réponses en texte libre ainsi que les pièces jointes sont supprimées, et ses documents State et Agent Profile sont effacés. La suppression physique n'est pas utilisée.
Effacement, enregistré
Les effacements sont inscrits dans le journal chaîné par hachage. Dans la mesure où la commande refuse un effacement qui ne correspond à rien, une faute de frappe sur l'apprenant ne peut pas passer pour un effacement mené à bien.
Sauvegardes
Un effacement est complet une fois que les sauvegardes prises avant celui-ci ont expiré. Après une restauration, le journal d’effacement est rejoué.
Conservation
Par mois calendaire, par instance. Le mois est détaché, exporté dans un fichier par locataire, puis supprimé. La suppression est refusée si le nombre de lignes exportées ne correspond pas.
Conservation, par client
Un client ayant besoin de sa propre période de conservation a besoin de sa propre instance.
Export en cas de sortie
Via l'interface standard xAPI, un client peut parcourir l'ensemble de ses enregistrements et de leurs pièces jointes au format JSON xAPI et tout récupérer.
Localisation des données
Une instance s’exécute dans la région exigée par un contrat. Le service n’a besoin que d’une base de données PostgreSQL.

Opérations et vérification

Modèle de déploiement
Une instance mutualisée multi-locataires, ou une instance dédiée par client.
Les sondes prouvent qu’elles peuvent échouer
Le banc de test ne validera la réussite d'aucune des 47 sondes comportementales tant qu'il n'aura pas été démontré que cette sonde ÉCHOUE (FAIL) face à un build délibérément corrompu. Nous exécutons également la suite de conformité sur des builds corrompus.

Ce que cela fait

  • Conformité testée

    Réussit les 1 365 tests de l’ADL LRS Conformance Test Suite pour xAPI 1.0.3, ainsi que les 1 435 tests pour xAPI 2.0.

  • Les enregistrements ne changent jamais

    Une fois stockée, une déclaration ne peut être ni modifiée ni écrasée, seulement annulée, comme le spécifie la norme.

  • Isolé par conception

    Les enregistrements des clients sont maintenus séparés par des règles appliquées par la base de données, en plus du code applicatif.

  • Chiffré et pseudonymisé

    Le contenu des enregistrements est chiffré au repos, et les identifiants des apprenants ne sont indexés que sous forme de jetons à clé.

  • Effacement avec une piste d’audit

    On request, a learner’s personal data is removed from their records, and the erasure is recorded in a tamper-evident, hash-chained log.

  • Identifiants à portée limitée

    Un identifiant d’authentification est limité aux opérations dont il a besoin, pouvant aller jusqu’à ne lire que les enregistrements qu’il a lui-même écrits.

Pour la documentation, un pilote ou une intégration, contactez-nous.