OneRoster (1.2 et groupes avancés)

OneRoster est un standard international d'échange d'annuaires scolaires (édité par 1EdTech) : il décrit, dans un format commun, les établissements, les années scolaires, les enseignements, les classes, les inscriptions et les utilisateurs d'une école. Il sert à raccorder un SIS, un ENT ou un LMS à un autre outil sans ressaisie ni format propriétaire.

Cette page s'adresse à la direction des systèmes d'information (la SI) de l'établissement. Elle décrit ce qu'Omniscol expose et consomme en OneRoster, l'authentification attendue, et le périmètre réel de chaque sens d'échange.

Versions prises en charge

Omniscol prend en charge OneRoster 1.2 Rostering — le socle (Org, AcademicSession, Course, Class, Enrollment, User, Demographics) — ainsi que la couche OR-Groups (Advanced Groups Service), le standard de groupes additif qui ajoute trois entités (Group, GroupMembership, GroupAssociation) au-dessus de la 1.2.

La couche OR-Groups est un standard en cours de publication. Elle est strictement additive sur la 1.2 : un Group ne fait que référencer les Class / User / Org / AcademicSession de la 1.2, en lecture seule. La version 1.3 de OneRoster est annoncée pour faire de Class une spécialisation de Group — orientation avec laquelle l'implémentation d'Omniscol converge déjà.

Omniscol producteur (Omniscol → ENT / LMS)

En producteur, Omniscol expose l'annuaire de l'établissement en lecture seule, via une API REST conforme OneRoster, pour qu'un ENT ou un LMS le lise.

• Le socle Rostering 1.2 est servi sous /ims/oneroster/rostering/v1p2/… (par exemple /orgs, /schools, /academicSessions, /courses, /classes, /enrollments, /users, /teachers, /students, /demographics, chacun avec ses variantes imbriquées).
• La couche groupes est servie sous /ims/oneroster/groups/v1p0/… (/groups, /groupMemberships, /groupAssociations et leurs variantes imbriquées).
• Le périmètre est l'année scolaire courante par défaut ; un paramètre permet de cibler une autre année ou de couvrir toutes les années.

Les données reflètent la planification consolidée d'Omniscol (emplois du temps actifs / publiés). Le producteur est en lecture seule par choix : aucune écriture (PUT / DELETE) n'est exposée — un système distant ne pilote pas la création ou la suppression d'entités dans Omniscol.

Authentification du producteur

Les points d'accès du producteur sont protégés par OAuth2 en flux client_credentials (jeton de machine à machine, sans utilisateur), émis par le serveur OAuth2 d'Omniscol. Ils ne sont pas réservés aux comptes Premium : l'accès est contrôlé par les scopes OAuth2, pas par l'offre. Chaque scope est spécifique à un service, et l'accès aux données démographiques est cloisonné à l'intérieur de la 1.2 :

Un jeton OR-Groups ne donne pas accès au socle Rostering, et réciproquement. Aucun scope d'écriture n'est annoncé. Les scopes privilégiés sont attribués par l'administration Omniscol au moment de l'enregistrement du client OAuth2 ; un client ne peut pas se les auto-attribuer. La gestion des clients OAuth2 et des jetons est décrite sur OAuth2 / OIDC (fournisseur) et API Omniscol.

Le périmètre des élèves est porté par la couche groupes

Choix structurant : la liste des élèves d'une classe ou d'un groupe est exposée via OR-Groups (GroupMembership), pas par le socle 1.2 seul. Un consommateur qui ne lit que la Rostering 1.2 obtient le catalogue (Courses, Classes), les inscriptions professeur → cours et l'annuaire des utilisateurs, mais pas l'appartenance des élèves. Pour savoir qui est dans quelle classe ou quel groupe, le consommateur doit implémenter la couche OR-Groups. Ce choix reflète le modèle français : un élève est inscrit dans une classe ou un groupe, pas matière par matière.

Le producteur s'expose en REST. Le format bundle CSV OneRoster (archive zip d'un fichier par collection), lui, est pris en charge côté import, pour les fournisseurs qui livrent leur annuaire par fichier plutôt que par API — voir la section consommateur ci-dessous.

Omniscol consommateur (SIS → Omniscol)

Profil français (enseignement scolaire)

Le profil français pour l'enseignement scolaire met en correspondance les notions françaises avec le modèle OneRoster : une division (la classe au sens effectif) devient un Group de type organisationnel principal ; un groupe devient un Group de diffusion pédagogique ; un groupe de groupes un Group transversal ; les partitions et alignements deviennent des associations de groupes ; une affectation d'un professeur à un cours devient une inscription professeur. Les identifiants comme l'INE ou l'identifiant agent sont portés dans les userIds de l'utilisateur.

Identifiants et confidentialité

Chaque entité exposée porte un identifiant stable, le sourcedId.

• Les identifiants structurels (établissement, année, enseignement, classe, groupe) sont stables et immuables d'un export à l'autre : un consommateur peut s'y fier pour corréler les données dans le temps.
• L'identifiant de l'utilisateur est anonymisé : Omniscol ne met jamais son propre identifiant nominatif sur le fil. Le jeton mis sur le fil est dérivé par une fonction à sens unique (HMAC) propre au compte ; les inscriptions et appartenances réutilisent ce jeton sans jamais exposer l'identifiant d'origine.

Statut

• Producteur — disponible et démontrable sans partenaire distant (l'export se suffit à lui-même). Rostering 1.2 et la couche OR-Groups sont servis en lecture seule, avec authentification OAuth2.
• Consommateur — la configuration d'import fait partie de la synchronisation Premium. La mise en service d'une synchronisation en direct avec un SIS dépend du fournisseur et, le cas échéant, des calendriers ministériels : elle se cadre sur demande, connecteur par connecteur. Il ne s'agit pas d'une synchronisation clés en main immédiate.