Aller au contenu
Langue: FR
Menu

Dossiers d'apprentissage

RODMENA LRS

Bientôt disponible

Le magasin de preuves pour l'apprentissage : ce qui s'est passé, enregistré une fois, conservé à l'identique.

Contactez-nous

RODMENA LRS est un Learning Record Store : il reçoit les enregistrements d'activité d'apprentissage au format xAPI, les stocke sans modification et les restitue via l'interface de requête xAPI standard. Il réussit tous les tests de l'ADL LRS Conformance Test Suite pour xAPI 1.0.3 et xAPI 2.0. Les enregistrements de chaque client sont isolés de ceux de tous les autres clients au sein même de la base de données. Le contenu des enregistrements est chiffré au repos, et les identifiants des apprenants ne sont stockés que sous une forme pseudonyme et à clé. Les enregistrements stockés ne peuvent pas être modifiés ; les données personnelles d'un apprenant peuvent être effacées sur demande, et chaque effacement est consigné dans un journal inviolable.

À qui il est destiné. Les plateformes d'apprentissage et les organismes de formation qui ont besoin d'un espace conforme pour conserver les enregistrements d'activité des apprenants. Il s'agit d'un service back-end : des produits sont construits sur celui-ci et l'appellent depuis leurs serveurs. Les apprenants et les navigateurs ne communiquent pas directement avec lui. REES en est le premier consommateur.

Statut
Bientôt disponible
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
Verified 23 septembre 2026
Étiquettes
xAPIDossiers d'apprentissageConformitéMulti-locataireProtection des donnéesPiste d'audit

Spécification technique

Indiqué 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
Sur demande, via l'en-tête X-Experience-API-Version. Les versions 1.0.x et 2.0.x sont acceptées ; une version absente ou inconnue est refusée avec un code 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
Les exigences que la suite déclare ne pas tester sont chacune couvertes par un contrôle dédié. Six tests de la suite qui n'affirment rien ont été identifiés et couverts séparément.
Par conception
OAuth 1.0 n'est pas accepté, car il est obsolète. Le service est appelé de serveur à serveur par les produits construits sur celui-ci, et n'accepte pas les appels cross-origin depuis un navigateur.

Interface

Ressources
Statements, State, Activity Profile, Agent Profile, Activities, Agents et About, avec HEAD sur chaque route GET.
Authentification
HTTP Basic avec les identifiants émis par le service. Secrets de 256 bits, stockés uniquement sous forme de vérificateur à clé. Les identifiants inconnus, désactivés et expirés reçoivent des réponses 401 identiques octet pour octet.
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 MiB par pièce jointe et 1 MiB par corps de déclaration, tous deux configurables.
Pagination
Des curseurs signés et sans état qui restent valides après un redémarrage, avec l'en-tête de cohérence xAPI sur chaque réponse statements.
Idempotence
Renvoyer un statement id identique est accepté sans duplication. Un statement id en conflit est refusé avec 409.
Limitation de débit
Par identifiant, avec un budget distinct pour les échecs d'authentification par adresse client.

Isolation et sécurité

Isolation des locataires
PostgreSQL sécurité au niveau des lignes, 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 build si une table de locataire, ou une partition créée au moment de l'exécution, est dépourvue de la policy.
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é
Chaque texte chiffré est lié à l'identité de sa ligne ; il ne peut donc pas être déplacé vers une autre ligne et continuer à être déchiffré.
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 tourne au moyen d'une réaffectation de clés hors ligne et reprenable, et la rotation de la clé d'identification réémet les identifiants. Chaque enregistrement stocke l'id de la clé qui l'a écrit, de sorte qu'une rotation ne nécessite aucune migration de données.
Identifiants des apprenants
Conservés uniquement sous forme de jetons HMAC-SHA256 sous une clé propre à chaque tenant, de sorte qu'un même apprenant dans deux tenants produit des jetons sans lien. Aucune colonne ne contient l'identité d'un apprenant en clair.
Portées des identifiants
L'ensemble des portées xAPI : statements/write, statements/read, statements/read/mine, state, profile, all/read et all. La portée de lecture la plus restrictive ne lit que les statements que ce credential a lui-même écrits.
Immutabilité
Les déclarations et les pièces jointes sont en ajout seul, ce que garantissent des déclencheurs de base de données qui refusent UPDATE, DELETE et TRUNCATE. Les seules modifications autorisées sont l'indicateur d'annulation et un effacement.
Transport de base de données
TLS avec vérification complète du certificat et du nom d'hôte est obligatoire ; le service refuse de démarrer dans le cas contraire.
Demander les événements d'audit
Un événement structuré par requête, comportant l'identifiant de requête, l'identifiant de clé d'authentification, le tenant, 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.
Preuve de falsification
Le journal d'effacement est chaîné par hachage, et une seule commande vérifie toute la chaîne de bout en bout.

Protection des données

Effacement
Une rédaction pseudonymisante. L'apprenant est remplacé par un pseudonyme aléatoire à chaque endroit où un énoncé peut le nommer, les réponses en texte libre et 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é
Chaque effacement est écrit dans le journal à chaîne de hachage. La commande refuse un effacement qui ne correspond à rien, de sorte qu'un apprenant mal saisi ne puisse ressembler à un effacement terminé.
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
L'interface xAPI standard. Un client peut parcourir chaque enregistrement au format xAPI JSON, avec ses pièces jointes, et tout récupérer.
Résidence
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
Chacune des 47 sondes comportementales doit être démontrée en ÉCHEC face à une build délibérément cassée avant que sa réussite ne soit comptabilisée, et le harnais l'impose. La suite de conformité est exécutée contre des builds cassées pour la même raison.

Ce que cela fait

  • Testé de conformité

    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é, un statement ne peut être ni modifié ni écrasé, seulement annulé, comme le spécifie la norme.

  • Isolé par conception

    Les enregistrements de chaque client sont séparés par des règles appliquées dans la base de données, et non uniquement par le 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

    Les données personnelles d’un apprenant sont supprimées de ses dossiers sur demande, et chaque effacement est consigné dans un journal infalsifiable, chaîné par hachage.

  • Informations d'identification à portée limitée

    Chaque identifiant est limité aux opérations dont il a besoin, jusqu'à ne lire que les enregistrements qu'il a lui-même écrits.

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