Document d’accompagnement au contrat d’interface AAF

1. Alimentation depuis le SI du MEN pour le premier et le second degré

Le ministère en charge de l’Éducation nationale (MEN) souhaite généraliser, en lien avec les collectivités locales et en interministériel, les espaces numériques de travail (ENT) dans le premier degré et le second degré.

Ce chapitre a pour objet de formaliser les modalités d’alimentation de l’annuaire ENT du premier degré et du second degré depuis le système d’information du ministère de l’Education nationale (SI du MEN) et d’autres systèmes d’information externes.

Dans le cadre d’une étude « Intégration des spécificités du premier degré de l’enseignement scolaire dans le cadre de référence des ENT » et du chantier de « Définition et conception de l’annuaire ENT », en liaison avec un groupe de travail chargé de recueillir les besoins des futurs utilisateurs de l’ENT et des porteurs de projet, le modèle d’information de l’annuaire ENT a été défini. Une partie importante des informations nécessaires au fonctionnement concerne les populations de la communauté éducative gérées par le MEN.

Ce document aborde les sujets suivants pour le premier et le second degré :

• Description des principes généraux de l’alimentation depuis le SI du MEN ;
• Description des principes généraux de l’alimentation depuis le SI EA (système d’information de l’enseignement agricole du ministère en charge de l’Agriculture) ;
• Description des modalités de mise à disposition des données ;
• Description du format du fichier d’alimentation ;
• Description des données échangées et des règles de gestion ;
• Exemples de fichier d’alimentation.

1.1. Principes généraux de l’alimentation depuis le SI du MEN

1.1.1. L’alimentation pour le premier degré

Figure 1 : Mise en œuvre de l’alimentation par le SI du MEN de l’annuaire ENT premier degré dans une académie

Comme représenté par la Figure 1, chaque académie met à disposition des ENT des données sur des personnes et des structures liées à l’enseignement primaire dans l’académie :

1. Les maires et les directeurs d’école renseignent la base ONDE¹;
2. L’instance académique de « l’annuaire » fédérateur² consolide les informations ;
3. « L’annuaire » académique fédérateur génère des fichiers qui alimentent l’annuaire ENT ;
4. Des données utilisateurs sont consultées à partir des ENT.

Chaque projet ENT ne dispose que des informations liées à son périmètre. Celui-ci se définit par une liste d’écoles de l’académie, qui doit être préalablement transmise à l’académie.

Les données mises à disposition pour le périmètre d’un projet ENT concernent :

• Les établissements d’enseignement primaire du périmètre du projet ENT ;
• Le rectorat, le vice-rectorat, les directions des services départementaux de l'éducation nationale (DSDEN) et les services départementaux de l’académie concernée, les circonscriptions ;
• Les élèves du primaire scolarisés dans une des écoles du périmètre du projet ENT ;
• Les personnes en relation avec ces élèves (personnes ou organismes exerçant l'autorité parentale) ;
• Les personnels enseignants et non enseignants rattachés administrativement à ou exerçant dans un des établissements du périmètre du projet ENT.

Dès lors qu’une personne exerce une fonction dans un établissement du périmètre du projet ENT, l’entrée correspondant à la personne est transmise dans les fichiers d’alimentation de l’annuaire ENT.

1.1.2. L’alimentation pour le second degré

Figure 2 : Mise en œuvre de l’alimentation par le SI du MEN de l’annuaire ENT second degré dans une académie

Chaque académie met à disposition des ENT des données sur des personnes et des structures liées à l’enseignement secondaire dans l’académie :

Le chef d’établissement renseigne la base SIECLE ;

L’instance académique de « l’annuaire » fédérateur³ consolide les informations ;

« L’annuaire » académique fédérateur génère des fichiers qui alimentent l’annuaire ENT ;

Des données utilisateurs sont consultées à partir des ENT.

Chaque projet ENT ne dispose que des informations liées à son périmètre. Celui-ci se définit par une liste d’établissements d’enseignement secondaire de l’académie, qui doit être préalablement transmise à l’académie.

Les données mises à disposition pour le périmètre d’un projet ENT concernent :

Les établissements d’enseignement secondaire du périmètre de l’ENT ;

Le rectorat ou vice-rectorat, les directions des services départementaux de l’Éducation nationale (DSDEN) et les services départementaux de l’académie concernée ;

Les élèves du secondaire scolarisés dans un des établissements du périmètre du projet ENT ;

Les personnes en relation avec ces élèves (représentants légaux, personnes en charge de l’élève, personnes à contacter…) ;

Les personnels enseignants et non enseignants rattachés administrativement à ou exerçant dans un des établissements du périmètre du projet ENT (enseignants, chefs d'établissement, personnels administratifs, gestionnaires, TOS gérés dans les bases du MEN, vacataires, infirmiers…).

Notons qu’une personne peut être rattachée administrativement à un établissement et exercer en plus dans d’autres établissements. Par exemple, un enseignant peut être rattaché administrativement à un établissement, y enseigner une discipline et enseigner cette discipline ou d’autres dans d’autres établissements. Dès lors qu’une personne exerce une fonction dans un établissement du périmètre du projet ENT, l’entrée correspondant à la personne est transmise dans les fichiers d’alimentation de l’annuaire ENT.

1.1.3. L’alimentation depuis le SI Enseignement agricole (SI EA)

Le Centre national d’études et de ressources en technologies avancées (CNERTA), maîtrise d’œuvre du SI EA, met à disposition des ENT des données sur des personnes et des structures liées à l’enseignement secondaire agricole dans l’académie à partir du dispositif SAPIA (système d’authentification et propagation d’identités pour l’enseignement agricole).

Figure 3 : Mise en œuvre de l’alimentation par le SI du MASA

1. L’établissement renseigne la base de gestion des élèves FREGATA et la base de gestion des dotations et/ou des personnels puis procède aux ajustements nécessaires sur la base de consolidation COLENTAGRI
2. Le CNERTA consolide les informations et actualise le contenu de l’annuaire fédérateur SAPIA
3. À partir de données métier consolidées et de l’annuaire SAPIA, la génération de fichiers à destination des ENT régionaux
4. Des données utilisateur sont consultées à partir de l’ENT

Chaque projet ENT ne dispose que des informations liées à son périmètre. Celui-ci se définit par une liste d’établissements d’enseignement secondaire agricole de la région, qui doit être préalablement transmise au CNERTA via le délégué régional TIC de la DRAAF (autorité académique de l’enseignement agricole).

• Les données mises à disposition pour le périmètre d’un ENT concernent :
• Les établissements d’enseignement secondaire agricole du périmètre du projet ENT ;
• Les élèves du secondaire, les apprentis et les stagiaires de la formation continue scolarisés dans un des établissements du périmètre du projet ENT ;
• Les personnes en relation avec ces élèves (personnes exerçant l'autorité parentale, personnes hébergeant un élève, responsables financiers, correspondants en cas d'urgence…) ;
• Les personnels enseignants et non enseignants rattachés administrativement à ou exerçant dans un des établissements du périmètre du projet ENT (enseignants, chefs d'établissement, personnels administratifs, gestionnaires, TOS gérés dans les bases du SIEA, vacataires, infirmiers…).

Notons qu’une personne peut être rattachée administrativement à un établissement et exercer en plus dans d’autres établissements. Par exemple, un enseignant peut être rattaché administrativement à un établissement, y enseigner une discipline et enseigner cette discipline ou d’autres dans d’autres établissements. Dès lors qu’une personne exerce une fonction dans un établissement du périmètre du projet ENT, l’entrée correspondant à la personne est transmise dans les fichiers d’alimentation de l’annuaire ENT.

1.2. Modalités de mise à disposition des données

1.2.1. Accès aux fichiers d’alimentation

Les modalités de mise à disposition des fichiers d’alimentation⁴ doivent être étudiées et définies au cas par cas entre le projet ENT et le rectorat concerné notamment :

• Serveur de retrait ou de dépôt des fichiers ;
• Protocole d’échange ;
• Moyen d’authentification et autres dispositions de sécurité ;
• Fréquence, horaire et durée de mise à disposition.

Afin de garantir une fraicheur suffisante des informations présentes dans l’annuaire ENT, il est recommandé au rectorat de mettre à disposition les fichiers et au projet ENT d’intégrer les fichiers de manière à ce que ces données soient mises à jour dans l’ENT à J+1⁵.

Spécificités pour l’enseignement agricole C'est au titulaire du marché de récupérer les fichiers XML de manière sécurisée auprès du SI EA.

1.2.2. Types de fichiers d’alimentation

Le rectorat peut fournir deux types de fichiers d’alimentation :

• un fichier complet, mis à disposition toutes les semaines ou à la demande ; il est généralement utilisé lors de l’initialisation de l’annuaire ENT ou lors de sa réinitialisation au moment de la rentrée scolaire et a pour avantage d’assurer une intégrité des données dans l’annuaire ENT ; cependant son temps de chargement peut s’avérer très long (jusqu’à plusieurs heures) ;
• un fichier delta, mis à disposition quotidiennement ou à la demande ; il est plutôt utilisé lors des mises à jour régulières et fréquentes de l’annuaire ENT et a pour avantage d’assurer une mise à jour rapide de l’annuaire ENT ; il peut cependant être source d’incohérences fonctionnelles (par exemple l’omission de certaines demandes de suppression de comptes au moment de la rentrée scolaire).

Chaque porteur de projet pourra choisir :

• Sur quel type de fichiers reposent les mécanismes d’alimentation de l’annuaire ENT ;
• La fréquence d’intégration de ces fichiers dans l’annuaire ENT.

Spécificités pour l’enseignement agricole
Le CNERTA met à disposition quotidiennement les deux types de fichiers : complet et delta pour chaque région utilisatrice du dispositif SAPIA. Les fichiers d’alimentation proposés sont obligatoirement de type XML.

1.2.2.1. Mise à disposition de fichiers complets

Le rectorat met à disposition des fichiers complets représentant l’intégralité du contenu du SI du MEN pour les personnes et les structures appartenant au périmètre du projet ENT concerné. Ces fichiers complets sont générés :

• À une fréquence déterminée par le porteur de projet et le rectorat ;
• Sur demande, en complément.

Spécificités pour l’enseignement agricole
Le CNERTA met quotidiennement à disposition des fichiers complets représentant l’intégralité du contenu du SI EA pour les personnes et les structures appartenant au périmètre du projet ENT concerné.
Les fichiers sont disponibles sur un espace ftp spécifique. Une procédure de récupération est à mettre en œuvre par les opérateurs ENT.

1.2.2.2. Mise à disposition de fichiers delta

Principe

Au jour J, le rectorat met à disposition un fichier delta contenant tous les objets créés, modifiés ou supprimés depuis les n derniers jours. Tous les attributs de ces objets sont renseignés dans le fichier avec leur valeur au jour J.

Le service d’alimentation de la solution ENT peut ainsi comparer l’ensemble des objets présents dans le fichier delta avec le contenu de l’annuaire ENT afin de déterminer les changements apportés depuis la dernière intégration.

Remarques :

• Les objets créés, modifiés ou supprimés sont répétés pendant n jours. Pour ne pas perdre d’information, il faut que le délai entre l'intégration de deux fichiers delta soit inférieur ou égal à n ; l'import des deltas n'est donc pas obligatoirement quotidien. Cependant un import journalier est préconisé afin de bénéficier de données à jour dans la solution.
• Sur demande, un fichier delta, par rapport à une date donnée, pourra être mis à disposition du porteur de projet.

1.2.2.3. Valeur de n

n détermine le nombre de jours pendant lesquels un objet créé, modifié ou supprimé doit être répété dans les fichiers delta des jours suivants (n ³ 1). Autrement dit, chaque fichier delta contient tous les objets qui ont été modifiés durant les n jours précédents.

n est une valeur paramétrable pour chaque projet ENT et peut être modifiée sur demande auprès du rectorat.

Une valeur faible de n permet de limiter la taille des fichiers delta (notamment pendant les périodes de changements nombreux), mais impose de prendre en compte les fichiers plus régulièrement.

Quelle que soit la valeur de n, ce mode de fonctionnement permet de prendre en compte les modifications quotidiennes du SI du MEN puisque le fichier delta est généré tous les jours.

Spécificités pour l’enseignement agricole
Le CNERTA met quotidiennement à disposition des fichiers delta contenant tous les objets créés, modifiés ou supprimés depuis les n derniers jours. Tous les attributs de ces objets sont renseignés dans le fichier avec leur valeur au jour J.
La valeur n est la même pour toutes les régions : 7 jours

1.2.2.4. Fichier sans modification

Dans le cas où aucune modification n’aurait été effectuée depuis les n derniers jours, un fichier d’alimentation est tout de même généré. Celui-ci contient uniquement les lignes d’en-tête et le bloc racine vide.

1.2.3. Processus de chargement

Chaque type d’import (complet / delta) révèle ses avantages et ses inconvénients. Il convient donc de définir un modèle susceptible de combiner ces deux solutions et de profiter des avantages de chacune d’entre elles, tout en minimisant les inconvénients.

En particulier, le modèle le plus adapté d’import des fichiers doit tenir compte des contraintes suivantes :

• Un usage quotidien de l’ENT aux heures pleines par les différents acteurs ; l’import des fichiers doit donc se réaliser pendant des périodes de faible activité de l’ENT ; par conséquent, la nuit pendant la semaine pour les fichiers delta et éventuellement le week-end pour les fichiers complets correspondent aux périodes les plus adaptées pour effectuer ces imports ;
• Une mise à jour quotidienne des données de l’annuaire ; comme des mises à jour ont lieu régulièrement au niveau des bases académiques, il convient de répercuter rapidement ces mises à jour au niveau de l’annuaire ; l’import de fichiers delta demeure la solution la plus adaptée pour répondre à cette contrainte ;
• Un besoin d’intégrité des données importées ; chaque acteur de l’ENT doit avoir un compte d’accès et retrouver tous les rattachements auxquels il a droit ; l’import des fichiers complets se révèle utile pour assurer une resynchronisation complète des données et garantir cette intégrité.

Le modèle le plus adapté pour répondre aux contraintes citées précédemment se rapproche de celui‑ci :

• Une initialisation des données à partir d’un fichier complet ;
• Un import très fréquent de fichiers delta ;
• Un import occasionnel d’un fichier complet.

L’initialisation des données à partir d’un fichier complet demeure une étape nécessaire pour débuter l’intégration des données dans l’annuaire ENT. De même, lors de la période de rentrée scolaire, une réinitialisation des données à partir d’un fichier complet s’avère judicieux pour supprimer les données obsolètes et ajouter les nouveaux comptes.

Un import très fréquent de fichiers delta permet la mise à jour régulière et rapide (même en semaine) de l’annuaire ENT sans impacter l’usage de l’ENT par les différents acteurs. En période de rentrée scolaire, la fréquence de chargement doit être très proche. À partir du mois de janvier, cette fréquence peut s’espacer.

Un import occasionnel d’un fichier complet assure la remise en conformité régulière des données de l’annuaire ENT. Elle s’effectue périodiquement ou à la demande (plus fréquente pendant la période de rentrée scolaire, plus rare en dehors de cette période) et il convient de déterminer le jour d’import du fichier complet en collaboration avec les différents acteurs pour les prévenir de cette opération et du risque de dégradation voire d’indisponibilité de l’ENT pendant la période de l’import. Un jour du week‑end est conseillé pour effectuer cette opération, jour où l’ENT est moins utilisé, afin d’effectuer des traitements plus longs au niveau de l’annuaire ENT. Il faut au passage prendre en compte le temps nécessaire pour générer un fichier complet et adapter la période de génération du fichier delta suivant, en fonction du temps complet de traitement du fichier complet (entre la génération et le chargement).

Figure 4: Séquence de chargement des fichiers complets ou delta

Ce processus de chargement se révèle critique pour le bon fonctionnement de l’ENT. Il convient donc de mettre en œuvre des mécanismes de contrôle et de notifications d’alerte sur ce processus.

Par ailleurs, lorsque l’annuaire ENT est alimenté par différentes sources (SI du MEN, SI du ministère en charge de l’Agriculture), le porteur devra s’assurer de l’isolation des données dans l’annuaire de telle manière que l’import d’un fichier venant d’un SI n’influe pas sur les données venant d’un autre SI.

Ce processus de chargement doit également s’accompagner d’un processus régulier de désactivation et de suppression de comptes. Cependant, pendant la période d’initialisation de l’annuaire, afin d’éviter de supprimer des comptes identifiés comme inactifs avant la distribution de ces comptes aux usagers, il convient d’adapter le paramètre par défaut d’expiration d’un compte inactif (3 mois) en fonction de la période de mise à disposition des comptes (rentrée scolaire ou pas).

1.2.4. Caractéristiques des fichiers d’alimentation

Les caractéristiques des fichiers d’alimentation sont présentées dans le tableau ci-dessous :

Tableau 1 : Caractéristiques du fichier d’alimentation

1.3. Format du fichier d’alimentation pour le premier et le second degré

1.3.1. Présentation du format

Le format proposé pour le fichier d’alimentation reprend, en limitant les actions possibles, les principes de SPML (Service Provisioning Markup Language) version 1.0. Ce standard, basé sur XML, a été conçu afin d’automatiser les tâches de gestion des comptes des utilisateurs et des structures dans les référentiels d’entreprise.

L’utilisation qui en est faite ici se limite à un transfert d’information unidirectionnel, bien que le standard prévoit un fonctionnement « requête – réponse ».

Le fichier d’alimentation étant au format XML, certains caractères contenus dans les données doivent être transformés avant de les inscrire dans le fichier. Les transformations nécessaires sont les suivantes :

Tableau 2 : Caractères à remplacer dans les données

Par ailleurs, il est important de noter que les noms des balises XML utilisées dans la syntaxe du fichier d’alimentation sont sensibles à la casse.

1.3.2. Syntaxe du fichier d’alimentation

Le fichier d’alimentation doit commencer par les lignes d’en-tête suivantes :

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE ficAlimMENESR SYSTEM "ficAlimMENESR.dtd">

Le corps du fichier d’alimentation est inséré à la suite des lignes d’en-tête au sein d’un bloc racine <ficAlimMENESR> :

Exemple de fichier d’alimentation premier degré :

<ficAlimMENESR>

<!-- versionAF="AAF-VE[Année].[N° de version]" -->

<!-- versionSDET="2025" -->

<!-- codeAcademieExport="13" -->

<!-- degre="1D" -->

<!-- dateGenerationExport="05/09/2025" -->

*(corps du fichier d’alimentation)*

</ficAlimMENESR>

Exemple de fichier d’alimentation second degré :

<ficAlimMENESR>

*(corps du fichier d’alimentation)*

</ficAlimMENESR>

Le bloc racine contient différents blocs décrits ci-après et dont l’enchaînement et les imbrications sont présentés sur la figure 5.

Figure 5 : Structure du fichier d’alimentation

1.3.2.1. Bloc « requête »

Les seules requêtes SPML⁶ prises en compte pour le fichier d’alimentation sont :

1. <addRequest>

   • signification :
     • création (ou présence) d’une personne ou d’une structure dans le SI du MEN,
     • entrée d’une personne ou d’une structure dans le périmètre d’extraction,
   • utilisation : fichier complet ou fichier delta,
   • syntaxe : ce bloc se compose d’un unique bloc <operationalAttributes>, d’un unique bloc <identifier> et d’un unique bloc <attributes> ;

2. <modifyRequest>

   • signification : modification d’une personne ou d’une structure existante dans le SI du MEN,
   • utilisation : fichier delta,
   • syntaxe : ce bloc se compose d’un unique bloc <operationalAttributes>, d’un unique bloc <identifier> et d’un unique bloc <modifications> ;

3. <deleteRequest>

   • signification :
     • suppression d’une personne ou d’une structure dans le SI du MEN,
     • sortie d’une personne ou d’une structure du périmètre d’extraction,
   • utilisation : fichier delta,
   • syntaxe : ce bloc se compose d’un unique bloc <operationalAttributes> et d’un unique bloc <identifier>.

1.3.2.2. Bloc <operationalAttributes>

Un bloc <operationalAttributes> est obligatoire pour toute requête. Il permet de préciser la catégorie correspondant à la personne ou la structure concernée par chaque requête.

Dans le premier degré :

Un bloc <operationalAttributes> contient un seul bloc <attr>, qui peut être de deux types :

• <attr name="categoriePersonne"> : définit la catégorie d’une personne ;
• <attr name="categorieStructure"> : définit la catégorie d’une structure.

Dans le second degré :

Un bloc <operationalAttributes> contient un seul bloc <attr>, qui peut être de deux types :

• <attr name="categoriePersonne"> : définit la catégorie d’une personne ;
• <attr name="categorieStructure"> : définit la catégorie d’une structure ;
•  : définit la catégorie d’une matière ;
•  : définit la catégorie d’une Mef.

Au sein d’un bloc <attr>, la catégorie à laquelle appartient une structure ou une personne est placée dans un bloc <value>.

La syntaxe est la suivante :

<operationalAttributes>

<attr name="categoriePersonne">

<value>Eleve</value>

</attr>

</operationalAttributes>

1.3.2.3. Bloc <identifier>

Un bloc <identifier> est obligatoire pour toute requête. Il permet de préciser la clé de jointure correspondant à la personne ou la structure concernée par chaque requête.

La clé est indiquée par une balise <id>.

La syntaxe est la suivante :

<identifier>

<id>123456789</id>

</identifier>

1.3.2.4. Bloc <attributes>

Un bloc <attributes> est obligatoire pour toute requête <addRequest>. Il ne peut être inséré qu’au sein d’une requête <addRequest>.

Un bloc <attributes> regroupe l’ensemble des attributs de la fiche identifiée par le bloc <identifier> qui le précède. Il se compose donc de plusieurs blocs <attr>.

Au sein d’un bloc <attr>, le(s) valeur(s) d’un attribut sont placées dans des blocs <value>.

La syntaxe est la suivante :

<attributes>

<attr name="nomAttribut1">

<value>valeur de l’attribut n°1</value>

</attr>

<attr name="nomAttribut2">

<value>valeur de l’attribut n°2</value>

<value>2e valeur de l’attribut n°2</value>

</attr>

</attributes>

Remarque sur les attributs multi-valués : comme dans l’exemple ci-dessus, il est possible de faire apparaître plusieurs fois la balise <value> afin de donner plusieurs valeurs à un attribut.

1.3.2.5. Bloc <modifications>

Un bloc <modifications> est obligatoire pour toute requête <modifyRequest>. Il ne peut être inséré qu’au sein d’une requête <modifyRequest>.

Un bloc <modifications> regroupe l’ensemble des attributs de la fiche identifiée par le bloc <identifier> qui le précède. Il se compose donc de plusieurs blocs <modification>.

Un bloc <modification> contient les attributs suivants :

• name : nom de l’attribut à modifier ;
• operation : type de modification à effectuer
  • operation="replace" : remplacement de la (les) valeur(s) existante(s) par la (les) valeur(s) indiquée(s) ( « replace » et le seul type d’operation utilisé).

Au sein d’un bloc <modification>, les valeurs sont placées dans des blocs <value>.
Exemple :

<modifications>

<modification name="nomAttribut1" operation="replace">

<value>valeur de l’attribut n°1</value>

</modification>

<modification name="nomAttribut2" operation="replace">

<value>nouvelle valeur de l’attribut n°2</value>

</modification>

</modifications>

1.3.3. Exemple de fichier d’alimentation complet (pour le second degré)

Le fichier d’alimentation complet fournit une vision à l’instant t de toutes les personnes et les structures présentes dans le SI du MEN et appartenant au périmètre de l’ENT concerné.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE ficAlimMENESR SYSTEM "ficAlimMENESR.dtd">

<ficAlimMENESR>

<!-- versionAF="AAF-VE[Année].[N° de version]" -->

<!-- versionSDET="2025" -->

<!-- codeAcademieExport="13" -->

<!-- degre="2D" -->

<!-- dateGenerationExport="05/09/2025" -->

<addRequest>

<operationalAttributes>

<attr name="categoriePersonne">

<value>Eleve</value>

</attr>

</operationalAttributes>

<identifier>

<id>1812064</id>

</identifier>

<attributes>

<attr name="ENTPersonJointure"><value>1812064</value></attr>

<attr name="ENTEleveINE"><value>[numéro INE]</value></attr>

<attrname="ENTEleveStructRattachId"><value>117567</value></attr>

<attrname="ENTPersonDateNaissance"><value>29/08/2005</value></attr>

<attr name="ENTPersonNomPatro"><value>CABLEAU</value></attr>

<attr name="sn"><value>CABLEAU</value></attr>

<attr name="givenName">Kevin</attr>

<attr name="ENTPersonAutresPrenoms">

<value>Kevin</value><value>Michel</value>

</attr>

<attr name="personalTitle"><value>M.</value></attr>

<attr name="ENTElevePersRelEleve">

<value>2119550$20$1$1$0$1</value>

<value>2119551$39$0$3$0$0</value>

</attr>

<attr name="ENTEleveBoursier"><value>O</value></attr>

<attr name="ENTEleveRegime"><value>DEMI-PENSIONNAIRE DANS L&apos;ETABLISSEMENT</value></attr>

<attr name="ENTEleveTransport"><value>O</value></attr>

<attr name="ENTPersonAdresse"><value>7 avenue de Montpellier</value></attr>

<attr name="ENTPersonCodePostal"><value>12000</value></attr>

<attr name="ENTPersonVille"><value>RODEZ</value></attr>

<attr name="ENTPersonPays"><value>FRANCE</value></attr>

<attr name="ENTEleveAdresseRel"><value>2119551</value></attr>

<attr name="ENTEleveStatutEleve"><value>SCOLAIRE</value></attr>

<attr name="ENTEleveMEF"><value>21225503110</value></attr>

<attr name="ENTEleveLibelleMEF"><value>T_STI GENIE ELECTROTECHNIQUE</value></attr>

<attr name="ENTEleveNivFormation"><value>TERMINALE GENERALE &amp; TECHNO YC BT</value></attr>

<attr name="ENTEleveFiliere"><value>TERMINALE TECHNOLOGIQUE</value></attr>

<attr name="ENTEleveCodeEnseignements">

<value>240900</value>

<value>100100</value>

<value>230700</value>

<value>191300</value>

<value>061300</value>

<value>064700</value>

<value>030201</value>

<value>010300</value>

</attr>

<attrname="ENTEleveEnseignementsEtablissementsAccueil"><value/></attr>

<attr name="ENTPersonStructRattach"><value>50245</value></attr>

<attr name="ENTEleveDateEntreeStructRattach">

<value>50245$02/09/2020</value>

</attr>

<attr name="ENTEleveDateSortieStructRattach">

<value/>

</attr>

<attr name="ENTEleveDateEntreeClasses">

<value>50245$31/08/2025$TTIE2</value>

</attr>

<attr name="ENTEleveDateSortieClasses">

<value/>

</attr>

<attr name="ENTEleveClasses"><value>50245$TTIE2</value></attr>

<attrname="ENTEleveGroupes"><value>50245$TTIE2_A</value></attr>

</attributes>

</addRequest>

<addRequest>

…

</addRequest>

</ficAlimMENESR>

Spécificités pour l’enseignement agricole :

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE ficAlimAGRI SYSTEM "ficAlimAGRI.dtd">

<ficAlimAGRI>

<!-- versionAF="SAPIA 2018" -->

<!-- versionSDET="Annexe 4bis version 6.6" -->

<ficAlimAGRI>

<addRequest>

<operationalAttributes>

<attr name="categoriePersonne">

<value>Eleve</value>

</attr>

</operationalAttributes>

<identifier>

<id>9801317302081</id>

</identifier>

<attributes><attrname="ENTPersonJointure"><value>9801317302081</value></attr>

<attrname="ENTPersonDateNaissance"><value>28/05/2001</value></attr>

<attr name="ENTEleveINE"><value></value></attr>

<attr name="ENTPersonNomPatro"><value>CHEVALIER</value></attr>

<attr name="sn"><value>CHEVALIER</value></attr>

<attr name="givenName"><value>Lucie</value></attr>

<attr name="ENTPersonAutresPrenoms"><value>Lucie Marie</value></attr>

<attr name="personalTitle"><value>Mme</value></attr>

<attr name="ENTEleveEnseignements">

<value>PHYSIQUE-CHIMIE</value>

<value>INFORMATIQUE</value>

<value>MATHEMATIQUES</value>

<value>E.P.S.</value>

<value>BIOLOGIE-ECOLOGIE</value>

<value>ECONOMIE D&#39;ENTREPRISE</value>

<value>HISTOIRE-GEOGRAPHIE</value>

<value>EDUCATION SOCIOCULTURELLE</value>

<value>FRAN&#199;AIS</value>

<value>ANIMALERIE</value>

<value>PRATIQUES PROF.</value>

<value>TECHNIQUES COMMERCIALES</value>

<value>ANGLAIS</value>

</attr>

<attr name="ENTEleveCodeEnseignements">

<value>695301</value>

<value>693600</value>

<value>693000</value>

<value>692800</value>

<value>692600</value>

<value>692000</value>

<value>691900</value>

<value>691600</value>

<value>691400</value>

<value>691000</value>

<value>653000</value>

<value>620200</value>

<value>610100</value>

</attr>

<attr name="ENTEleveEnseignementsEtablissementsAccueil"><value>240900$50245</value></attr>

<attr name="ENTEleveStatutEleve"><value>SCOLAIRE</value></attr>

<attr name="ENTEleveMEF"><value>27622103310</value></attr>

<attr name="ENTEleveLibelleMEF"><value>2DPROA CONSEIL VENTE</value></attr>

<attr name="ENTEleveNivFormation"><value>BAC PRO 3 ANS : 2NDE PRO (OU 1ERE ANNEE)</value></attr>

<attr name="ENTEleveFiliere"><value>BAC PRO AGRICOLE EN 3 ANS : 2NDE PRO</value></attr>

<attrname="ENTPersonStructRattach"><value>9800949000000</value></attr>

<attr name="ENTEleveDateEntreeClasses"><value></value></attr>

<attr name="ENTEleveDateSortieClasses"><value></value></attr>

<attr name="ENTEleveClasses"><value>9800949000000$2e TCVA</value></attr>

<attr name="ENTEleveBoursier"><value>N</value></attr>

<attr name="ENTEleveGroupes"><value/></attr>

<attr name="ENTEleveRegime"><value>DEMI-PENSIONNAIRE DANS L&#39;ETABLISSEMENT</value></attr>

<attr name="ENTEleveTransport"><value>N</value></attr>

<attr name="ENTPersonAdresse"><value></value></attr>

<attr name="ENTPersonCodePostal"><value></value></attr>

<attr name="ENTPersonVille"><value></value></attr>

<attr name="ENTPersonPays"><value></value></attr>

<attr name="ENTEleveAdresseRel"><value></value>

<value>9801317502770</value>

<value>9801317502771</value>

</attr>

<attrname="ENTEleveStructRattachId"><value>302081</value></attr>

<attrname="ENTEleveStructRattachIdMEN"><value>790242</value></attr>

<attr name="ENTElevePersRelEleve">

<value>9801317502770$20$0$1$0$0</value>

<value>9801317502771$10$0$1$0$0</value>

</attr>

</attributes>

</addRequest>

</ficAlimAGRI>

1.3.4. Exemples de fichier d’alimentation delta (pour le second degré)

Le fichier d’alimentation complet fournit une vision à l’instant t de toutes les personnes et les structures créées, modifiées ou supprimées lors des n derniers jours au sein du SI du MEN et appartenant au périmètre de l’ENT concerné.

L’exemple des fichiers d’alimentation ci-dessous correspond aux opérations suivantes effectuées au sein du SI du MEN :

• un ou plusieurs attributs d’une personne de l’Éducation nationale dont la clé de jointure est 440 ont été modifiés il y a moins de n jours ;
• un élève dont la clé de jointure est 21481 a été retiré du SI du MEN.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE ficAlimMENESR SYSTEM "ficAlimMENESR.dtd">

<ficAlimMENESR>

<!-- versionAF="AAF-VE[Année].[N° de version]" -->

<!-- versionSDET="2025" -->

<!-- codeAcademieExport="13" -->

<!-- degre="2D" -->

<!-- dateGenerationExport="05/09/2025" -->

<modifyRequest>

<operationalAttributes>

<attr name="categoriePersonne">

<value>PersEducNat</value>

</attr>

</operationalAttributes>

<identifier>

<id>440</id>

</identifier>

<modifications>

<modification name="ENTPersonJointure"operation="replace"><value>440</value></modification>

<modification name="ENTPersonSTSId"operation="replace"><value>8283$E 14578</value></modification>

<modification name="ENTPersonDateNaissance"operation="replace"><value>29/04/1968</value></modification>

<modification name="ENTPersonNomPatro"operation="replace"><value>AIRE</value></modification>

<modification name="sn"operation="replace"><value>AIRE</value></modification>

<modification name="givenName"operation="replace"><value>Bobby</value></modification>

<modification name="personalTitle"operation="replace"><value>M.</value></modification>

<modification name="mail"operation="replace"><value>bmurier@ac-academie.fr</value></modification>

<modification name="ENTPersonStructRattach"operation="replace"><value>8283</value></modification>

<modification name="ENTPersonStructRattachDate"operation="replace"><value>8283$02/09/2024$31/12/9999</value></modification>

<modification name="ENTAuxEnsCategoDiscipline"operation="replace"><value>19$EDUCATION PHYSIQUE ET SPORTIVE</value></modification>

<modification name="ENTAuxEnsCategoDisciplineDate"operation="replace"><value>19$EDUCATION PHYSIQUE ET SPORTIVE$01/09/1991$31/12/9999</value></modification>

<modification name="ENTAuxEnsDisciplinesPoste"operation="replace"><value>EDUCATION PHYSIQUE ET SPORTIVE$19</value></modification>

<modification name="ENTAuxEnsMEF" operation="replace">

<value>8283$21125105110$1_STI GENIE MECANIQ:PRODUCTIQ.MECANIQ.</value>

<value>8283$21120101110$1_STL PHYSIQ.LAB.PROC.IND:CONTRL.REGUL.</value>

<value>8283$21122004110$1_STL
PHYSIQ.LAB.PROC.IND:OPTQ.PHY.CHIM</value>

<value>8283$21125105112$1EURO GENIE MECANIQ:
PRODUCTIQ.MECANIQ.</value>

<value>8283$20111011112$1S SI SCIENTIFIQUE EUROPEENNE</value>

<value>8283$20010014110$2DE DETERMINATION</value>

<value>8283$30111020210$CPGE1 PTSI (PHYS.TECHN.SCI.INGEN.)</value>

<value>8283$20111011110$PREMIERE SCIENTIFIQUE SI</value>

<value>8283$21225105110$T_STI GENIE MECANIQ
PRODUCTIQ.MECANIQ.</value>

<value>8283$21222206110$T_STL CHIMIE DE LABO.ET PROCEDES
INDUST.</value>

</modification>

<modification name="ENTAuxEnsMEFDate" operation="replace">

<value>8283$21125105110$1_STI GENIE MECANIQ:
PRODUCTIQ.MECANIQ.$01/09/2025$31/08/2026</value>

<value>8283$21120101110$1_STL PHYSIQ.LAB.PROC.IND:CONTRL.REGUL.
.$01/09/2025$31/08/2026</value>

<value>8283$21122004110$1_STL
PHYSIQ.LAB.PROC.IND:OPTQ.PHY.CHIM.$01/09/2025$31/08/2026</value>

<value>8283$21125105112$1EURO GENIE MECANIQ: PRODUCTIQ.MECANIQ.
.$01/09/2025$31/08/2026</value>

<value>8283$20111011112$1S SI SCIENTIFIQUE
EUROPEENNE.$01/09/2025$31/08/2026</value>

<value>8283$20010014110$2DE
DETERMINATION.$01/09/2025$31/08/2026</value>

<value>8283$30111020210$CPGE1 PTSI (PHYS.TECHN.SCI.INGEN.)
.$01/09/2025$31/08/2026</value>

<value>8283$20111011110$PREMIERE SCIENTIFIQUE
SI.$01/09/2025$31/08/2026</value>

<value>8283$21225105110$T_STI GENIE MECANIQ PRODUCTIQ.MECANIQ.
.$01/09/2025$31/08/2026</value>

<value>8283$21222206110$T_STL CHIMIE DE LABO.ET PROCEDES INDUST.
.$01/09/2025$31/08/2026</value>

</modification>

<modification name="ENTAuxEnsMatiereEnseignEtab"operation="replace"><value>8283$EDUCATION PHYSIQUE ET SPORTIVE</value></modification>

<modification name="ENTAuxEnsClassesMatieres" operation="replace">

<value>8283$671$100100</value>

<value>8283$801$100100</value>

<value>8283$602$100100</value>

<value>8283$503$100100</value>

<value>8283$510$100100</value>

<value>8283$712$100100</value>

<value>8283$705$100100</value>

</modification>

<modification name="ENTAuxEnsClassesMatieresDate" operation="replace">

<value>8283$671$100100$01/09/2025$31/08/2026</value>

<value>8283$801$100100$01/09/2025$31/08/2026</value>

<value>8283$602$100100$01/09/2025$31/08/2026</value>

<value>8283$503$100100$01/09/2025$31/08/2026</value>

<value>8283$510$100100$01/09/2025$31/08/2026</value>

<value>8283$712$100100$01/09/2025$31/08/2026</value>

<value>8283$705$100100$01/09/2025$31/08/2026</value>

</modification>

<modification name="ENTAuxEnsGroupesMatieres"operation="replace"><value/></modification>

<modification name="ENTAuxEnsGroupesMatieresDate"operation="replace"><value/></modification>

<modification name="ENTAuxEnsClassesPrincipal"operation="replace"><value/></modification>

<modification name="ENTAuxEnsClassesPrincipalDate"operation="replace"><value/></modification>

<modification name="ENTPersonFonctions"operation="replace"><value>8283$ENS$ENSEIGNEMENT$L1900$EDUCATION
PHYSIQUE ET SPORTIVE</value></modification>

<modification name="ENTPersonFonctionsDate"operation="replace"><value>8283$ENS$ENSEIGNEMENT$L1900$EDUCATION
PHYSIQUE ET SPORTIVE$01/09/2025$31/08/2026</value></modification>

<modification name="ENTPersonCategorieEnseignant"operation="replace"><value>O</value></modification>

<modification name="ENTPersonCategorieEnseignantDate"operation="replace"><value>01/09/2025$31/08/2026</value></modification>

</modifications>

</modifyRequest>

<deleteRequest>

<operationalAttributes>

<attr name="categoriePersonne">

<value>Eleve</value>

</attr>

</operationalAttributes>

<identifier>

<id>21481</id>

</identifier>

</deleteRequest>

</ficAlimMENESR>

Spécificités pour l’enseignement agricole :

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE ficAlimAGRI SYSTEM "ficAlimAGRI.dtd">

<!-- versionAF="SAPIA 2018" -->

<!-- versionSDET=" Annexe4_AlimentationMEN-SIexternes_2024" -->

<ficAlimAGRI>

<modifyRequest>

<operationalAttributes>

<attr name="categoriePersonne">

<value>Eleve</value>

</attr>

</operationalAttributes>

<identifier>

<id>9801307302108</id>

</identifier>

<modifications>

<modification name="ENTPersonJointure"operation="replace"><value>9801307302108</value></modification>

<modification name="ENTPersonDateNaissance"operation="replace"><value>30/03/2000</value></modification>

<modification name="ENTPersonNomPatro"operation="replace"><value>BICHET</value></modification>

<modification name="sn"operation="replace"><value>BICHET-CHEVALIER</value></modification>

<modification name="givenName"operation="replace"><value>Marianne</value></modification>

<modification name="ENTPersonAutresPrenoms"operation="replace"><value>Marianne Bozena</value></modification>

<modification name="personalTitle"operation="replace"><value>Mme</value></modification>

<modification name="ENTEleveCodeEnseignements" operation="replace">

<value>695301</value>

<value>693600</value>

<value>693000</value>

<value>692800</value>

<value>692600</value>

<value>692000</value>

<value>691900</value>

<value>691600</value>

<value>691400</value>

<value>691300</value>

<value>691000</value>

<value>660900</value>

<value>653000</value>

<value>640300</value>

<value>600500</value>

<value>600100</value>

</modification>

<modification name="ENTEleveEnseignements" operation="replace">

<value>ANGLAIS</value>

<value>PHYSIQUE-CHIMIE</value

value>BIOLOGIE-ECOLOGIE</value>

<value>INFORMATIQUE</value>

<value>MATHEMATIQUES</value>

<value>E.P.S.</value>

<value>DOCUMENTATION</value>

<value>HISTOIRE-GEOGRAPHIE</value>

<value>EDUCATION SOCIOCULTURELLE</value>

<value>FRAN&#199;AIS</value>

<value>AGRO-EQUIPEMENTS</value>

<value>HIPPOLOGIE</value>

<value>EQUITATION</value>

<value>PRODUCTIONS VEGETALES</value>

<value>ECONOMIE D&#39;ENTREPRISE</value>

<value>PRATIQUES PROF.</value>

</modification><modification name="ENTEleveStatutEleve"operation="replace"><value>SCOLAIRE</value></modification>

<modification name="ENTEleveMEF"operation="replace"><value>27621211330</value></modification>

<modification name="ENTEleveLibelleMEF"operation="replace"><value>TLPROA COND GEST ENTR
HIPPIQUE</value></modification>

<modification name="ENTEleveNivFormation"operation="replace"><value>BAC PRO 3 ANS : TERM PRO (OU 3EME
ANNEE)</value></modification>

<modification name="ENTEleveFiliere" operation="replace"><value>BAC
PRO AGRICOLE EN 3 ANS : TERM PRO</value></modification>

<modification name="ENTPersonStructRattach"operation="replace"><value>9800928000000</value></modification>

<modification name="ENTEleveDateEntreeClasses"
operation="replace><value></value></modification>

< modification name="ENTEleveDateSortieClasses"
operation="replace><value></value></modification>

<modification name="ENTEleveClasses"operation="replace"><value>9800928000000$TaleCGEH</value></modification>

<modification name="ENTEleveBoursier"operation="replace"><value>O</value></modification>

<modification name="ENTEleveGroupes"operation="replace"><value/></modification>

<modification name="ENTEleveRegime"operation="replace"><value>DEMI-PENSIONNAIRE DANS
L&#39;ETABLISSEMENT</value></modification>

<modification name="ENTEleveTransport"operation="replace"><value>N</value></modification>

<modification name="ENTEleveStructRattachId"operation="replace"><value>302108</value></modification>

<modification name="ENTEleveStructRattachIdMEN"operation="replace"><value>792107</value></modification>

<modification name="ENTElevePersRelEleve" operation="replace">

<value>9801307502854$10$0$1$0$0</value>

<value>9801307502853$20$0$1$0$0</value>

</modifications>

</modifyRequest>

<deleteRequest>

<operationalAttributes>

<attr name="categoriePersonne">

<value>Eleve</value>

</attr>

</operationalAttributes>

<identifier>

<id>9801312304063</id>

</identifier>

</deleteRequest>

</ficAlimAGRI>

1.3.5. Exemple de fichier d’informations

Les fichiers d’alimentation sont accompagnés par un fichier d'informations (InfosEducNat).

Pour le premier degré :

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE ficInformMENESR SYSTEM "ficInformMENESR.dtd">

<ficInformMENESR>

<parametres>

<param name="ENTAnneeScolaire"><value>2025</value></param>

<param
name="ENTDateImportSco1D"><value>03/09/2025</value></param>

<param name="ENTDateImportSco1DHorodatage"><value>03/09/2025
10:41:25</value></param>

<param name="ENTDateExport"><value>05/09/2025</value></param>

<param name="ENTHorodatage"><value>05/09/2025
14:54:14</value></param>

<param name="ENTgeneration"><value>

listeAcademie=[]

listeDept=[]

listeFonction=[]

listeGrade=[]

listeMinistere=[]

listeNiveau=[]

listeNumen=[]

listeRne=[UAI1,UAI2,UAI3,…]

listeRneAAjouter=[]

listeRneASupprimer=[]

listeSecteur=[]

listeSi=[]

listeTransformation=[ENT1DVA_eleve, ENT1DVA_etab, ENT1DVA_parent,
ENT1DVA_pen]

listeType=[]

</value></param>

</parametres>

</ficInformMENESR>

Pour le second degré :

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE ficInformMENESR SYSTEM "ficInformMENESR.dtd">

<ficInformMENESR>

<parametres>

<param name="ENTAnneeScolaire"><value>2025</value></param>

<param
name="ENTDateImportSco2D"><value>03/09/2025</value></param>

<param name="ENTDateImportSco2DHorodatage"><value>03/09/2025
10:41:25</value></param>

<param name="ENTDateExport"><value>05/09/2025</value></param>

<param name="ENTHorodatage"><value>05/09/2025
14:54:14</value></param>

<param name="ENTgeneration"><value>

listeAcademie=[]

listeDept=[]

listeFonction=[]

listeGrade=[]

listeMinistere=[]

listeNiveau=[]

listeNumen=[]

listeRne=[ UAI1,UAI2,UAI3,…]

listeRneAAjouter=[]

listeRneASupprimer=[]

listeSecteur=[]

listeSi=[]

listeTransformation=[ENT2DVA_etab, ENT2DVA_mef, ENT2DVA_matiere,
ENT2DVA_parent, ENT2DVA_pen, ENT2DVA_eleve]

listeType=[]

</value></param>

</parametres>

</ficInformMENESR>

1.3.6. DTD

La DTD (Document Type Definition) des fichiers d’alimentation est donnée ci-dessous :

<!ELEMENT ficAlimMENESR (addRequest|modifyRequest|deleteRequest)>

<!ELEMENT addRequest (operationalAttributes, identifier, attributes)>

<!ELEMENT modifyRequest (operationalAttributes, identifier,

l'attribut "name" de l'element "attr" doit etre egal a

<!ELEMENT id (#PCDATA)>

<!ATTLIST attr name CDATA #REQUIRED>

<!ATTLIST modification

name CDATA #REQUIRED

Remarque : il est également possible de formaliser la structure du fichier XML au travers d’un « schema » (.xsd) au lieu d’une DTD (.dtd). Celui-ci pourra être généré à partir de la DTD fournie.

1.3.7. Spécificité enseignement agricole

1.3.7.1. Présentation du format

L’ensemble des éléments décrivant le format du fichier d’alimentation s’applique aux fichiers générés pour l’enseignement agricole.

1.3.7.2. Syntaxe du fichier d’alimentation

Le fichier d’alimentation doit commencer par les lignes d’en-tête suivantes :

Le corps du fichier d’alimentation est inséré à la suite des lignes

(corps du fichier d’alimentation)

La description du bloc racine et des différents blocs qui le constituent est identique à celle des fichiers du MEN.

1.3.7.3. DTD

La DTD (Document Type Definition) des fichiers d’alimentation est donnée ci-dessous :

<!ELEMENT modifyRequest (operationalAttributes, identifier,

l'attribut "name" de l'element "attr" doit etre egal a

<!ELEMENT id (#PCDATA)>

<!ATTLIST attr name CDATA #REQUIRED>

<!ATTLIST modification

name CDATA #REQUIRED

du fichier XML au travers d’un « schéma » (.xsd) au lieu d’une DTD (.dtd). Celui-ci pourra être généré à partir de la DTD fournie.

1.4. Données échangées et règles de gestion

1.4.1. Catégories de personnes et de structures

1.4.1.1. Correspondance entre les catégories de l’annuaire ENT et les catégories du fichier d’alimentation

Les tableaux ci-après présentent les catégories de structures et de personnes de l’annuaire ENT en correspondance avec les catégories présentes dans le fichier d’alimentation.

L’information « Code » indique la dénomination qui est utilisée dans le fichier d’alimentation.

Tableau 3 : Catégories de structures

Tableau 4 : Catégories de personnes

1.4.2. Répartition entre les catégories de personnes et de structures

Comme indiqué dans les tableaux du chapitre précédent, les catégories de structures et de personnes présentes dans le fichier d’alimentation regroupent certaines catégories de l’annuaire ENT.

Le service d’alimentation de la solution ENT doit donc répartir les objets entre les catégories de l’annuaire ENT en se basant sur les caractéristiques de ces objets.

1.4.2.1. Répartition des structures

La catégorie « EtabEducNat » dispose d’un attribut ENTStructureTypeStruct qui indique le type de structure.

La règle de répartition suivie par le service d’alimentation de la solution ENT est la suivante :

Si ENTStructureTypeStruct vaut « RECTORAT » ou « VICE-RECTORAT TOM » ou « DIRECTION SERVICES DEPARTEMENTAUX EN » ou « SERVICE DE LA DSDEN » ou « CIRCONSCRIPTIONS INSPECTION EDUC NAT » ou « DRAAF – DAAF »,
, la structure est affectée à la catégorie « ENTServAc », sinon elle est affectée à la catégorie « ENTEcole » pour le premier degré ou à la catégorie « ENTEtablissement » pour le second degré.

1.4.2.2. Répartition des personnes

Le modèle de l’annuaire ENT prévoit plusieurs catégories pour les personnes : les élèves, les responsables d’élèves, les enseignants, les personnels non enseignants rattachés à une école ou à un établissement, les personnels non enseignants rattachés à un service académique, les personnels non enseignants rattachés à une collectivité locale, les personnes extérieures, etc.

Pour les personnels de l’éducation nationale dans le premier degré, la règle se définit donc sur la fonction (enseignant ou non) ou sur l’attribut ENTPersonCategorieEnseignant lorsqu’il sera disponible puis sur la structure de rattachement pour les personnels non enseignants.

Pour les personnels de l’Éducation nationale et de l’enseignement agricole dans le second degré, la règle d’appartenance doit dorénavant être basée sur l’attribut ENTPersonCategorieEnseignant de la catégorie « PersEducNat ».

L’attribut ENTPersonCategorieEnseignant sera valorisé avec la valeur « O » si l’agent exerce au moins une fonction d’affectation enseignant (si l'une des fonctions à l'une de ces valeurs : ENS, DOC, DCT, ALB, PRO, APP, REM, FIJ, FCA, APP, STG, ACP – cf. table BCN N_FONCTION_FILIERE) dans les bases RH, et pour au moins une structure de l’académie (établissement, zone de remplacement, etc.), même si la structure est en dehors du périmètre de l’ENT. Il sera valorisé à « N » dans le cas contraire.

Le service d’alimentation de la solution ENT doit suivre la règle de répartition suivante :

SI ENTPersonCategorieEnseignant = « O » ALORS
la personne est affectée à la classe « ENTAuxEns »
SINON
la personne est affectée à la classe « ENTAuxNonEnsEtab »

Spécificités pour l’enseignement agricole
L’attribut ENTPersonCategorieEnseignant est alimenté avec la valeur « O » si l’agent est défini comme « Enseignant » ou si une fiche de service le met en face d’un ensemble d’élèves.

L'agent avec l’attribut ENTPersonFonctions « ENS » avec une spécialité de poste qui prend la valeur « FD0016 », doit être affecté aux deux classes : Enseignant et Documentaliste.

1.4.3. Description des données échangées

Les données échangées depuis le SI du MEN (pour le premier et le second degré) et du ministère en charge de l’Agriculture (pour le second degré) sont définies dans le contrat d’interface AAF. Ce document décrit notamment les attributs attendus par l’annuaire ENT pour chaque catégorie de personnes et de structures.

Les informations suivantes sont précisées :

• attribut obligatoire ou facultatif ;
• attribut mono-valué ou multi-valué ;
• attribut actuellement livré (ou non) ;
• règle utilisée par le MEN et le MASA pour extraire l’attribut depuis les bases de son SI ;
• nomenclature (référence à Base Centrale des Nomenclatures du MEN ;
• format.

Son contenu est bien spécifique au fichier d’alimentation. Les différences concernent notamment les points suivants :

• Seuls les attributs alimentés depuis le SI MEN sont mentionnés ;
• Certains attributs mentionnés ne sont pas stockés dans l’annuaire ENT (tel que l’attribut ENTPersonCategorieEnseignant) ;
• Certaines catégories de personnes et de structures sont regroupées ;
• Le caractère obligatoire ou facultatif peut être différent en raison du regroupement de catégories.

Les libellés, les nomenclatures et les formats sont toutefois identiques, permettant au service d’alimentation de la solution ENT d’assurer la correspondance entre les données alimentées et le contenu de l’annuaire ENT.

Les nomenclatures relatives aux MEF et aux matières enseignées sont transmises depuis le SI du MEN sans forcément être stockées dans l’annuaire ENT.

1.4.4. Contraintes d’intégrité

Des contraintes d’intégrité sur les données de l’annuaire ENT sont données au chapitre 3.3 du document « Spécifications de l’annuaire ENT ».

1.4.5. Clés de jointure avec l’annuaire ENT

1.4.5.1. Généralités

Afin d’assurer la correspondance entre les entrées (personnes et structures) du SI du MEN et celles stockées dans l’annuaire ENT, il est nécessaire de disposer d’un identifiant commun jouant le rôle de clé de jointure.

Une clé de jointure identifie de manière unique une personne ou une structure, et doit être mentionnée pour chaque opération réalisée sur la personne ou la structure concernée.

Ainsi, le MEN fournit une clé de jointure persistante (pérenne d’une année scolaire sur l’autre), permettant d’identifier de manière unique, sur le périmètre de l’académie, chaque personne et chaque structure au fil des alimentations successives. Cette clé de jointure n’a pas, a priori, de signification particulière et ne présuppose pas de l’identifiant qui sera utilisé au sein de la solution ENT.

Les règles de construction des clés de jointure stockées dans l’annuaire ENT sont définies dans le document « Spécifications de l’annuaire ENT ».

1.4.5.2. Références entre objets

Lorsqu’un attribut nécessite de faire référence à une personne ou à une structure (exemple : l’attribut ENTEleveAutoriteParentale de la fiche d’un élève), la valeur de l’attribut correspond à la clé de jointure de la personne ou de la structure pointée. Les attributs pour lesquels une clé de jointure est requise sont précisés dans le chapitre 4.3 « Attributs particuliers » du document « Spécifications de l’annuaire ENT ».

Pour le premier degré, le service d’alimentation de la solution ENT remplacera la clé de jointure par l’identifiant de la personne ou de la structure au sein de l’annuaire ENT et correspondant à la clé de jointure en question.

Pour le second degré, le service d’alimentation de la solution ENT remplacera la clé de jointure par le dn de la personne ou de la structure au sein de l’annuaire ENT et correspondant à la clé de jointure en question.

Notons qu’il est possible qu’une référence désigne une personne ou une structure qui n’appartient pas au périmètre du projet ENT et qui n’est donc pas présente dans l’annuaire ENT. Ce cas devra être géré par le service d’alimentation de la solution ENT (référence ignorée, remontée d’alerte…).

1.4.5.3. Personnes appartenant à plusieurs catégories de personnes

Une personne peut appartenir à plusieurs catégories de personnes. Par exemple, un enseignant qui est également parent d’un élève appartiendra aux catégories PersEducNat et PersRelEleve.

Dans ce cas, la personne disposera d’une clé de jointure différente pour chacune des catégories auxquelles elle appartient et sera considérée comme deux personnes distinctes. Aucun rapprochement ne sera effectué par le MEN.

Comme indiqué dans le document « Spécifications de l’annuaire ENT », la solution ENT pourra offrir aux utilisateurs un service permettant de réconcilier les identités distinctes qu’ils possèdent dans chacune des catégories.

1.4.5.4. Identifiant unique de l’élève dans la structure de rattachement dans les bases de scolarité du MEN

Pour l'interfaçage avec certaines applications nationales sous responsabilité du MEN comme par exemple le livret scolaire au collège (livret scolaire du CP à la 3e) ou le livret scolaire du lycée (LSL), l’identifiant de l’élève dans les bases de scolarité SCONET (SIECLE) est nécessaire. Cet identifiant est unique sur un périmètre académique et est modifié quand l’élève change d’établissement.

Cet identifiant est fourni par le MEN par les annuaires fédérateurs dans l’attribut ENTEleveStructureRattach.

Spécificités pour l’enseignement agricole

Afin de permettre l’interfaçage entre les ENT et le livret scolaire au collège (LSU 2D) ou le livret scolaire du lycée ou autre service mis à disposition de l’enseignement agricole pour les élèves du second degré, l’identifiant de l’élève dans les bases de scolarité SIECLE (ex-SCONET) est également nécessaire.

Cette information est fournie par le dispositif SAPIA dans l’attribut ENTEleveStructureRattachIdMEN (identifiant élève de SIECLE – SCONET - récupéré lors de l’échange avec le SI du MEN pour les élèves concernés)

Les ENT devront alors appliquer la règle d’alimentation suivante lors de l’envoi vers le LSU 2D ou LSL des données des élèves : si un élève est rattaché à un établissement agricole et ENTEleveStructureRattachIdMEN a une valeur non vide, envoi au LSU 2D ou LSL de la valeur du champ ENTEleveStructureRattachIdMEN.

Le code FREGATA reste toujours disponible dans l’ENT pour les élèves de l’enseignement agricole dans l'attribut ENTEleveStructRattachId.

1.4.6. Règles de gestion complémentaires

1.4.6.1. Casse des valeurs des attributs

Le traitement des chaînes de caractères (minuscules, majuscules, accentuées ou non…) n’est pas identique dans toutes les bases d’informations du SI du MEN.

Les fichiers d’alimentation contiendront les données issues du SI du MEN « en l’état ». Chaque solution ENT effectuera ensuite les transformations qu’elle jugera nécessaires.

1.4.6.2. Gestion des attributs vides

Les fichiers d’alimentation contiennent toutes les balises XML des attributs des personnes et des structures, que ceux-ci soient obligatoires ou facultatifs.

Si les bases du SI du MEN ne permettent pas de valoriser un attribut (obligatoire ou facultatif), la balise XML sera transmise à vide.

Exemple :

<attr name="*nomAttribut1*">

<value></value>

</attr>

ou

<attr name="*nomAttribut1*">

<value/>

</attr>

Le service d’alimentation de la solution ENT devra donc s’assurer de la présence de tous les attributs obligatoires, et remonter éventuellement des alertes.

1.4.6.3. Qualité des données

Les informations mises à disposition des ENT sont directement issues des bases du MEN. Aucun contrôle ou traitement correctif n’est appliqué par le dispositif.

Les porteurs de projet ENT veillent à ce que les écoles et établissements bénéficiaires de l’ENT s’assurent de la qualité des informations saisies dans les bases du MEN et qui seront transmises en l’état aux ENT. En particulier :

• les données sur l’école ou l’établissement dans RENOIRH ;
• les données sur son personnel enseignant et non enseignant dans les bases RH ;
• les données sur les élèves et les personnes en relation avec eux, dans ONDE ou dans SIECLE.

Spécificités pour l’enseignement agricole :

les données sur l’établissement se trouvent dans les référentiels GENOME et refEA;

les données sur le personnel enseignant et non enseignant titulaire dans les logiciels GUEPARD, PHOENIX et ceux d’éditeurs privés ;

les données manquantes sur le personnel sont actualisées dans COLENTAGRI ;

les données sur les élèves et les personnes en relation avec eux dans FREGATA.

Il appartient au soumissionnaire de prendre les mesures nécessaires pour rejeter et identifier les anomalies, puis pour demander une correction à la source. Cela s’avère particulièrement important pour les attributs faisant l’objet de traitements automatisés (génération d’un identifiant de connexion par exemple).

Par ailleurs, afin de suivre plus aisément le résultat de cette intégration dans l’annuaire ENT, il est préconisé de générer des rapports indiquant les statistiques des différentes opérations effectuées (nombre de création, de modification, de suppression de comptes avec la possibilité d’accéder au détail) et des erreurs rencontrées.

1.4.6.4. Traitements particuliers des requêtes de modification et suppression

modifyRequest

Le service d’alimentation de la solution ENT devra traiter une telle requête en création si l’objet concerné n’est pas présent dans l’annuaire ENT. Exemple : un enseignant remplaçant est affecté dans une autre école appartenant, elle, au périmètre du projet ENT.

Remarque : Dès lors qu’un attribut d’un objet des bases du MEN est modifié, une requête de modification est générée (sous réserve que l’objet appartienne au périmètre du projet ENT). Cela signifie que des requêtes de modification peuvent être émises pour des attributs qui ne concernent pas le projet ENT. Ce cas s’avère toutefois rare, en particulier pour les élèves et les personnes en relation avec les élèves.

deleteRequest

Chaque projet ENT détermine les règles de gestion associées à la réception d’une telle requête :

• délai avant désactivation du compte : immédiat, au bout de 6 mois, en fin d’année scolaire... ;
• délai avant archivage et suppression du compte.

Remarque : Le compte doit être supprimé lorsque la personne n’a plus vocation à en disposer. Pour plus de détails, se reporter au paragraphe « Droits d’accès » du document principal.

Le service d’alimentation de la solution ENT devra ignorer une requête de suppression si l’objet concerné n’est pas présent dans l’annuaire ENT.

2. Nomenclatures ENT

L’interopérabilité est un enjeu fort pour les ENT et se joue sur plusieurs plans :

• niveau politique : partenaires de coopération présentant des projets compatibles, des priorités harmonisées et des objectifs ciblés ;
• niveau juridique : harmonisation de la législation pour que les données échangées se voient reconnaître une valeur juridique adéquate ;
• niveau organisationnel : processus coordonnés au sein desquels différentes organisations parviennent à un objectif préalablement fixé et offrant un avantage mutuel ;
• niveau sémantique : signification précise des informations échangées préservée et comprise de tous ;
• niveau technique : planification des questions techniques relatives à la mise en relation des systèmes et services informatiques.

Le présent document présente les nomenclatures spécifiques aux usages des services numériques pour l’éducation en lien avec les espaces numériques de travail. Il s’appuie sur le référentiel d’interopérabilité de la doctrine technique du numérique pour l’éducation. D’autres spécificités peuvent être à prendre en compte pour d’autres systèmes d’information (par exemple, SI du ministère en charge de l’enseignement agricole, ou le SI d’une collectivité territoriale)

L’interopérabilité sémantique entre composantes ou systèmes d’information hétérogènes et dans les systèmes d’échange nécessite de poser un contenu informationnel compréhensible par les différents partenaires.

Les spécifications d’interopérabilité sémantique imposent de définir un langage commun permettant aux applications des systèmes d’information participants d’interpréter de façon homogène la nature et les valeurs des données transmises et de les réutiliser sans erreur ou perte d’information.

Différentes nomenclatures sont ainsi définies pour y répondre.

Les nomenclatures de la BCN (Base centrale des nomenclatures) constituent un langage commun entre le système d'information de l'Éducation nationale et celui de l'Enseignement supérieur et de la Recherche : nomenclatures et règles de gestion et de contrôle propres, ainsi que certaines nomenclatures interministérielles et internationales.

Elles sont mises à jour régulièrement et historisées au moyen de dates d'ouverture et de fermeture.

Elles sont en consultation sur le site de la BCN

Les nomenclatures sont précisées pour :

• Les codes des projets ENT ;
• Les modules élémentaires de formation ;
• Les enseignements ;
• Les nomenclatures académiques transmises par le SI du MEN ;
• Les profils de l’accédant ;
• Les personnes en relation avec les élèves.

2.1. Codes des projets ENT

2.1.1. Définition du code projet

Ce chapitre présente la liste des codes identifiant les projets ENT. Chaque projet ENT est identifié par un code unique sur le périmètre national. En effet, la combinaison du code projet ENT avec l’identifiant des utilisateurs permet de garantir au niveau national l’unicité de l’identifiant utilisateur transmis au GAR.

Ce code est donné pour le premier et second degré dans les tableaux ci-après. Il se compose de la manière suivante :

• Les deux premiers caractères définissent le porteur de projet géographiquement selon le périmètre du projet ENT.
• Le troisième caractère précise le ou les degrés d’enseignement concernés
  • 0 pour 1D/2D
  • 1 pour 1D
  • 2 pour 2D
• Le dernier caractère alphabétique permet de prendre en compte la multiplicité des projets sur un même territoire et un même public.

2.2. Codes des porteurs de projets

2.2.0.1. Projets régionaux ou académiques

Les régions et les académies porteurs de projet ENT sont identifiés par les deux caractères suivants dont les valeurs figurent dans les tableaux ci-après.

2.2.0.2. Projets départementaux

Les départements porteurs de projet ENT sont identifiés par les deux caractères suivants dont les valeurs figurent dans les tableaux ci-après.

2.3. Regroupement d’écoles ou d’établissements : RPI, cités scolaires

2.3.1. RPI (regroupements pédagogiques intercommunaux)

Les regroupements pédagogiques intercommunaux (RPI) permettent à plusieurs communes, notamment en milieu rural, de se réunir pour l'établissement et l'entretien d'une école :

Dans les RPI dits « dispersés », chaque école rassemble les élèves de plusieurs communes par niveau pédagogique et garde son statut juridique et sa direction d’école ;

Dans le cas de RPI dits « concentrés », l’ensemble des élèves des communes concernées est scolarisé dans l’école de l’une des communes.

Les configurations de RPI peuvent se retrouver dans la base RAMSESE⁷ au travers de la table qui liste les zones et de la table qui fait le lien entre les zones et les établissements. Dans les exports ENT, les écoles appartenant à un RPI peuvent être identifiées par l’intermédiaire du champ « ENTEcoleRPI » qui indique le code du RPI, son nom et le code département associé.

Les solutions ENT peuvent donc se baser sur cette information pour reconstituer les RPI du projet ENT.

2.3.2. Cités scolaires

Une cité scolaire publique est un ensemble immobilier constitué d'au moins 2 établissements scolaires publics qui utilisent en commun des locaux, et dont au moins un est un établissement du second degré. On entend ici par établissement les EPLE (établissements publics locaux d’enseignement), soit collège, lycée, lycée professionnel, et les écoles communales du premier degré.

Une cité scolaire privée est un ensemble immobilier constitué d'au moins 2 structures ayant un type d'UAI différent parmi les types d'UAI suivants : lycée, lycée professionnel, collège ou école ordinaire du premier degré. Dans la base RAMSESE, la cité scolaire est traitée comme une zone à laquelle on peut rattacher la liste des UAI faisant partie d'une même cité scolaire, sachant que seuls doivent être rattachés à la cité scolaire les établissements juridiquement autonomes.

Dans les exports ENT, les établissements au sein d’une cité scolaire sont identifiés par le champ « ENTEtablissementStructRattachFctl » qui contient l’identifiant de l’établissement responsable de gestion de la cité scolaire à laquelle appartient éventuellement l'établissement si celui-ci fait partie du périmètre du projet ENT.

Les solutions ENT peuvent donc se baser sur cette information pour reconstituer la notion de cité scolaire.

2.4. Nomenclature des MEF

2.4.1. Généralités

La formation que suit un élève pendant une année scolaire est qualifiée par différentes nomenclatures qui s’articulent autour des MEF (Modules élémentaires de formation). Chaque nomenclature apporte un niveau plus ou moins fin d’information. Ces nomenclatures sont organisées selon deux axes hiérarchisés (détaillés dans les chapitres suivants) :

• La thématique de la formation ;
• La position de la formation par rapport à un cursus.

La thématique de la formation, dont les nomenclatures associées sont les suivantes :

Tableau 1 : Nomenclatures associées à la thématique de la formation

La spécialité de formation du diplôme est construite comme illustré Figure 1 à partir des nomenclatures suivantes :

• catégorie (N_CATEGORIE_SPECIALITE) ;
• domaine (N_DOMAINE_SPECIALITE) ;
• groupe (N_GROUPE_SPECIALITE) ;
• numéro d’ordre.

Figure 1 : Nomenclature de la spécialité de formation du diplôme

La nomenclature N_GROUPE_SPECIALITE est définie par le Conseil national de l’information statistique (CNIS).

Nota : le niveau de formation du diplôme (N_NIVEAU_FORMATION_DIPLOME) peut être déterminé à partir du dispositif de formation (N_DISPOSITIF_FORMATION). La spécialité du diplôme (N_FORMATION_DIPLOME) et le niveau de formation du diplôme sont liés.

La position de la formation par rapport à un cursus, dont les nomenclatures associées sont les suivantes :

Tableau 2 : Nomenclatures associées à la position de la formation dans le cursus

2.4.2. Thématique de la formation

2.4.2.1. MEF nationaux et MEF académiques

Il existe deux catégories de MEF codifiant la thématique de formation : les MEF nationaux et les MEF académiques. Ces deux types de MEF sont codifiés sur 11 caractères.

Les MEF nationaux ont une portée nationale. Le 11^e et dernier caractère d’un MEF national vaut toujours « 0 » (zéro). Les MEF nationaux sont codés sur 10 caractères dans la BCN et sur 11 caractères lors de transmission dans le SI du MEN.

Les MEF académiques sont des MEF créés localement, en respectant certaines règles de gestion, pour répondre aux besoins suivants :

• La mise en place de formations nationales à gestion académique, telles que les sections linguistiques, sportives, les formations qualifiantes de SEGPA, certaines actions de la MGI (Mission générale d'insertion) ;
• Les besoins propres de l'académie : mise en place pour des publics ciblés de formations ayant une durée ou une spécialité particulière (par exemple, préparation d'un bac technologique en 3 ans au lieu de 2).

Le 11^e et dernier caractère d’un MEF académique est un chiffre différent de « 0 » (zéro) ou bien une lettre (cf. nomenclature N_TYPE_MEF).

Les académies peuvent adapter la durée du dispositif de formation ou la spécialité. Dans le 2^e cas, le 8^e caractère du MEF devient une lettre.

Lorsqu’un MEF académique est créé, il est associé à un MEF de rattachement. Il s’agit du MEF national à partir duquel le MEF académique a été « profilé ».

Les MEF des formations de l'enseignement agricole, proposées en voie initiale (scolaire), sont également disponibles dans la BCN et intégrés dans les fichiers d'alimentation des ENT.

2.4.2.2. Enseignements

Une thématique de formation définie par un MEF correspond à un ensemble d’enseignements ou matières enseignées. Les correspondances sont définies dans la table N_MEF_MATIERE de la BCN.

Nota : Certains MEF nationaux n’ont pas de définition de programme dans N_MEF_MATIERE.

2.4.2.3. Codification

La codification de la thématique de formation d’un MEF est illustrée. Deux exemples de MEF sont également présentés : « 1CAP2 CHOCOLATIER CONFISEUR » et « PREMIERE SCIENTIFIQUE SVT ».

Cette codification n’est valable que pour les MEF nationaux.

Figure 2 : Nomenclature des MEF nationaux pour le MEF « 1CAP2 CHOCOLATIER CONFISEUR »

Figure 3 : Nomenclature des MEF nationaux pour le MEF « PREMIERE SCIENTIFIQUE SVT »

2.4.3. Classification de la formation par rapport à un cursus

À chaque MEF national est associé un unique MEFSTAT11.

Le MEFSTAT11 est un code hiérarchisé : plus on lit de caractères, plus la formation est décrite finement et plus on précise la classification de la formation par rapport au cursus.

9 nomenclatures, MEF_STAT_1 à MEF_STAT_9, permettent de lire chacun des niveaux de rupture.

Tableau 3 : Niveaux de rupture du MEFSTAT11

La classification d’une formation par rapport à un cursus est illustrée Figure 4 et Figure 5 avec deux exemples de MEF / MEFSTAT11 présentés : « 1CAP2 CHOCOLATIER CONFISEUR » et « PREMIERE SCIENTIFIQUE SVT ».

Figure 4 : Nomenclature des MEFSTAT nationaux pour le MEF « 1CAP2 CHOCOLATIER CONFISEUR »

Figure 5 : Nomenclature des MEFSTAT nationaux pour le MEF « PREMIERE SCIENTIFIQUE SVT »

2.4.4. Synthèse des informations disponibles à partir d’un MEF national

Tableau 4 : Exemples d’informations disponibles à partir d'un MEF national

2.5. Enseignements

2.5.1. Nomenclatures « de gestion » utilisées par le MEN

Les nomenclatures utilisées par le ministère sont décrites dans la BCN.

Enseignements

Une formation comprend des enseignements (ou matières enseignées), qui sont codés sur 6 caractères :

• Les 2 premiers caractères codent les familles de matières (Langues vivantes, Sciences…) ;
• Les 4 premiers caractères codent les matières (Allemand, Mathématiques…) ;
• Le 5^e caractère code les modalités d’éloignement (enseignement dans l’établissement, par correspondance…) ;
• Le 6^e caractère code les modalités d’enseignement (une option prise en premier ou second choix…).
• La codification des enseignements est illustrée Figure 6 avec un exemple d’enseignement : « ALLEMAND LV1 ».

Figure 6 : Nomenclature des matières enseignées pour l’enseignement « ALLEMAND LV1 »

2.5.1.1. Disciplines

Pour un enseignant, il convient de distinguer sa discipline de recrutement de sa discipline de poste :

• discipline de recrutement : discipline correspondant au concours que le candidat a passé pour être recruté ;
• discipline de poste : il s’agit de la discipline effectivement enseignée. Cette information est renseignée par le service chargé de la gestion des personnels enseignants de l'enseignement scolaire du MEN en fonction des matières enseignées. Elle peut correspondre à plusieurs disciplines de recrutement (et donc plusieurs concours).

Tableau 5 : Exemples de disciplines de recrutement et de disciplines de postes associées

La codification des disciplines de poste est illustrée. Un exemple de discipline de poste est également présenté : « ALLEMAND LETTRES ».

Figure 7 : Nomenclature des disciplines pour la discipline de poste « ALLEMAND LETTRES »

2.5.2. Correspondances BCN / ScoLOMFR

Les solutions ENT reposent sur des annuaires alimentés par les données du SI du ministère en charge de l’Éducation nationale :

• les attributs de l’annuaire ENT sont définies dans le contrat d’interface AAF ;
• les attributs alimentés par le SI du MEN sont repris dans contrat d’interface AAF ;
• la référence des nomenclatures est la Base centrale des nomenclatures (BCN).

Parmi les données qui peuvent être transmises par la solution ENT aux services Tiers, des informations sur l’accédant, non associées à une identité, permettent d’assurer l’authentification, le contrôle d’accès au service et la fourniture du service.

Certains attributs, décrits selon la nomenclature BCN, ne peuvent être facilement exploités par les services Tiers fournisseurs de contenus pédagogiques, organisés selon une approche plus pédagogique qu’administrative.

Afin d’articuler les deux approches, un travail de mise en correspondance est réalisé, sur la base du profil ScoLOMFR, permettant l’alignement des vocabulaires « Niveaux » (voc-22) et « Domaines d’enseignement » (voc-15) sur les nomenclatures BCN MEFSTAT et N_MATIERE_ENSEIGNEE.

ScoLOMFR fournit un vocabulaire spécifique d’alignement ScoLOMFR-BCN, qui définit les équivalences. Il est fourni au format SKOS⁸.

Les équivalences sont décomposées en alignement exact, alignement proche, alignement générique et alignement spécifique.

Le profil ScoLOMFR est évolutif (avec un comité de pilotage annuel prenant en compte les demandes d’évolution et une mise à jour annuelle publiée en septembre). La date de publication de la version 4.0.0 dans son intégralité est prévue le 14 mai 2018.

Les vocabulaires et un manuel technique sont disponibles sur ScoLOMFR.

2.5.2.1. Niveaux

Les niveaux détaillés ScoLOMFR Voc-022 sont mis en correspondance avec le code MEFSTAT fourni aux ENT par le SI MEN.

Dans le premier degré, l’attribut ENTEleveNiveau (classe ENTEleve) est renseigné à partir de la nomenclature BCN N_MEFSTAT_4.

Dans le second degré, l’attribut ENTMEFSTAT11 est alimenté par le SI du MEN avec la nomenclature BCN V_MEFSTAT_11 (c’est-à-dire encodée sur 11 caractères). Le niveau détaillé de la liste ScoLOMFR Voc-022 correspond à un nombre variable de caractères du MEFSTAT11 : généralement les 6 premiers caractères de cet attribut correspondant à la nomenclature BCN N_MEFSTAT_6 sont utilisés dans la liste ScolomFR Voc-022.

2.5.2.2. Domaines d’enseignement

Les domaines d’enseignement ScoLOMFR Voc-015 sont mis en correspondance avec la nomenclature BCN N_MATIERE_ENSEIGNEE.

Dans le second degré, les attributs ENTAuxEnsMatiereEnseignEtab, ENTAuxEnsClassesMatieres, ENTAuxEnsGroupesMatieres, (classe auxiliaire ENTAuxEnseignant) sont renseignés à partir de la nomenclature BCN N_MATIERE_ENSEIGNEE.

2.5.3. Correspondances BCN / nomenclatures de l’enseignement agricole

Le système d’information de l’enseignement agricole s’appuie sur des nomenclatures propres. Pour faciliter les échanges de données, entre le ministère en charge de l’enseignement agricole et le ministère en charge de l’Éducation nationale ou services Tiers, une correspondance a été établie entre les nomenclatures de référence de l’enseignement agricole et celles contenues dans la BCN, sauf pour celles utilisées dans la gestion des ressources humaines et celle décrivant les matières enseignées.

Les nomenclatures spécifiques aux besoins de gestion des ressources humaines à l’Éducation nationale ne peuvent correspondre avec les nomenclatures de l’enseignement agricole. Il est alors nécessaire d’utiliser une table de référence spécifique aux besoins de l’enseignement agricole.

Ainsi, l’attribut ENTPersonFonctions (classe auxiliaire ENTAuxEnseignant) est renseigné pour l’enseignement agricole à partir des nomenclatures N_FONCTION_FILIERE et N_FAMILLE_POSTE_EA (table contenant les familles de postes de l’enseignement agricole) Cette table est disponible dans la BCN.

Exemples de valeurs du champ ENTPersonFonctions pour les enseignants, fourni par le SI de l’enseignement agricole :

9801030000000$ENS$ENSEIGNEMENT DEVANT ELEVES$FD0032$Aménagem/Aménag Paysagers

9801034000000$ENS$ENSEIGNEMENT DEVANT ELEVES$FD0001$MATHÉMATIQUES

9801022000000$ENS$ENSEIGNEMENT DEVANT ELEVES$FD0046$ZOOTECHNIE/HIPPOLOGIE

9801034000000$ENS$ENSEIGNEMENT DEVANT ELEVES$LV01$Anglais

Exemples de valeurs du champ ENTPersonFonctions pour d’autres fonctions :

9801012000000$ADM$FONCTION ADMINISTRATIVE$FS0019$Administratif cat. B

9801014000000$EDU$EDUCATION$FS0011$CPE

9801014000000$LAB$PERSONNELS DE LABORATOIRE$FS0015$Laboratoire cat. B

9801014000000$MDS$PERSONNELS MEDICO-SOCIAUX$FS0017$Santé

9801014000000$TEC$PERSONNELS TECHNIQUES$FS0022$Surveillance cat. B

9801019000000$DIR$DIRECTION$FS0008$Directeur CFPPA

2.6. Informations de scolarité transmises par le SI du MEN

Les tableaux ci-dessous reprennent les informations liées aux MEF et aux enseignements qui sont transmises par le SI du MEN au travers des fichiers d’alimentation des annuaires ENT.

2.6.1. Nomenclatures académiques transmises dans le second degré par le biais de l’annuaire académique fédérateur (AAF)

Dans le second degré, deux fichiers contenant des nomenclatures sont transmis par l’AAF aux solutions ENT.

Un premier fichier contient pour chaque Mef :

• Le libellé du Mef ;
• Le Mef national de rattachement ;
• Le code Mef_stat_11.

Un deuxième fichier contient pour chaque code matière le libellé associé.

2.6.2. Informations transmises pour les élèves du second degré

Tableau 6 : Nomenclatures transmises pour les élèves dans le second degré

2.6.3. Informations transmises pour les enseignants de l’Éducation nationale du second degré

Tableau 7 : Nomenclatures transmises pour les enseignants de l’Éducation nationale dans le second degré

2.7. Profils de l’accédant

Le profil de l’accédant non associé à une identité constitue une des données qui peut être transmise par la solution ENT aux services Tiers afin d’assurer l’authentification et le contrôle d’accès.

Il permet à un administrateur de donner des droits d’accès à une application en se basant sur ce profil et ainsi autoriser les accès (par exemple, autoriser les utilisateurs ayant le profil « Élève » à consulter une encyclopédie). Les informations de profils sont présentées par l’accédant dans le jeton de sécurité, ce qui permet de l’autoriser.

Chaque catégorie de profil de l’accédant est identifiée par un code unique sur le périmètre national.

Les profils de l’accédant sont par défaut peuplés automatiquement en fonction de la valeur d’un ou plusieurs attributs caractérisant les personnes. Ils peuvent être complétés de manière discrétionnaire.

Tableau 8 : Identifiants des profils de l'accédant

La valeur de l’identifiant du profil à fournir se détermine à partir de la classe d’objet puis de la fonction de la personne, comme le décrit le tableau ci-après :

Tableau 9 : Détermination du profil de l'accédant à partir de la classe d’objet et de la fonction

Cette liste des fonctions associées à un profil de l’accédant demeure non exhaustive. Elle est liée aux fonctions transmises par le SI du ministère en charge de l’Éducation nationale.

Les porteurs de projet pourront ajouter d’autres fonctions, depuis la liste des fonctions fournie par la BCN, à certains profils recensés afin notamment de permettre l’interopérabilité avec les informations transmises par d’autres SI (par exemple SI du ministère en charge de l’enseignement agricole, SI de la collectivité territoriale).

Spécificités pour le profil National_col
Les données des personnels non enseignants rattachés à une collectivité locale ne proviennent pas de la catégorie « PersEducNat ». Elles sont issues du référentiel de la collectivité et devront avoir comme profil accédant National_col.

Il peut arriver d’avoir des contractuels de la collectivité territoriale rattachés à un établissement et qui y jouent un rôle équivalent à celui du MEN. Dans ce cas, il est recommandé d’attribuer à ces personnes le profil accédant équivalent. Par exemple un contractuel engagé par la collectivité et qui enseigne dans un établissement devrait avoir le profil accédant National_ens.

2.8. Personnes en relation avec les élèves

2.8.1. Premier degré

Dans le premier degré, les personnes en relation avec l’élève sont décrites dans le champ ENTEleveAutoriteParentale qui contient les informations suivantes :
cle_jointure_person$type_relation

Les différents éléments composant ce champ sont détaillés ci-après :

cle_jointure_person : identifiant du responsable dans l’AAF pour l’Éducation nationale ;

type_relation : les différentes valeurs possibles sont indiquées dans la nomenclature commune aux premier et second degrés N_LIEN_ELEVE_RESPONSABLE⁹ (qui remplace l’ancienne nomenclature N_LIEN_PARENTE_1D). 

2.8.2. Second degré

Dans le second degré et dans le but d’aligner les informations transmises aux solutions ENT avec celles saisies dans SIECLE (ex-SCONET), le champ ENTElevePersRelEleve contient les informations suivantes :
cle_jointure_person$type_relation$resp_financier$resp$contact$beneficiaire

Les différents éléments composant ce champ sont détaillés ci-après :

• cle_jointure_person : identifiant du responsable dans l’AAF pour l’Éducation nationale ;
• type_relation : les différentes valeurs possibles sont indiquées dans la nomenclature commune aux premier et second degrés N_LIEN_ELEVE_RESPONSABLE (qui remplace l’ancienne nomenclature N_LIEN_PARENTE) ;
• resp_financier : s’appuie sur l’information « Paie les frais scolaires » dans SIECLE (responsable financier) ; 1 si la personne est responsable financier, 0 si la personne n’est pas responsable financier ;
• resp : les différentes valeurs possibles sont celles indiquées dans la nomenclature BCN commune aux premier et second degrés N_NIVEAU_RESPONSABILITE : 1 si la personne est « représentant légal », 2 si la personne est « personne en charge de l’élève », 3 si la personne est « personne à contacter » ;
• contact : s’appuie sur l’information de SIECLE concernant les représentants légaux et les personnes en charge de l’élève qui permet aux établissements d'indiquer si le responsable est à joindre en priorité ou non : 1 si la personne est à contacter en priorité, 0 sinon ;
• beneficiaire : s’appuie sur la nouvelle information « Perçoit les aides » dans SIECLE (les différentes valeurs possibles sont : 1 pour oui, 0 pour non).

Les combinaisons possibles pour les éléments resp et contact sont les suivantes :

Tableau 10 : Combinaisons possibles des éléments resp et contact dans le champ ENTElevePersRelEleve

Pour le niveau de responsabilité « personne à contacter » (niveau 3), les informations de la personne sont limitées à sa civilité, son lien avec l’élève, son nom de famille, son nom d’usage, son prénom et ses coordonnées téléphoniques.

2.9. Recommandations pour les porteurs de projets

• Chaque projet est identifié par un code unique sur le périmètre national respectant la nomenclature définie.
• Chaque catégorie de profil de l’accédant est identifiée par un code unique sur le périmètre national respectant la nomenclature définie.

3. Spécifications de l’annuaire ENT

3.1. Contenu de l’annuaire ENT

Le périmètre couvert par l’annuaire ENT regroupe l’ensemble des personnes et des structures liées à l’enseignement primaire et/ou à l’enseignement secondaire pour le périmètre définit par le porteur de projet ENT :

• Services académiques (rectorats / DSDEN / circonscriptions) et écoles ou groupement d’écoles, établissements du second degré
• Région / département / communes / intercommunalités

3.1.1. Périmètre des données

3.1.1.1. Catégories de personnes

Rapportés au périmètre du projet ENT, les catégories de personnes concernées par l’annuaire ENT sont les suivantes (liste non exhaustive) :

• Les élèves scolarisés dans une école primaire ou un établissement du second degré ;
• Les personnes en relation avec les élèves scolarisés (couvre les personnes responsables de l’élève, les correspondants en cas d'urgence) ;
• Les enseignants exerçant une activité au sein du projet (couvre les professeurs des écoles, les professeurs rattachés à un établissement du second degré ou à des services académiques, les conseillers pédagogiques de circonscription, les conseillers numériques et les conseillers pédagogiques départementaux) ;
• Les non enseignants rattachés administrativement à une école primaire (couvre les ATSEM¹⁰, les EVS¹¹, les AVS¹², les AESH¹³, le personnel des écoles privées) ou à un établissement du second degré (couvre les chefs d'établissement, les responsables d’enseignement spécialisé, les EVS, les AVS, les AESH, certains personnels administratifs ainsi que les personnels des établissements privés) 
• Les non enseignants rattachés administrativement à des services académiques et exerçant une activité au sein du projet (couvre les corps d'inspection et les personnels détachés du rectorat ainsi que les directions académiques – IA-DASEN, IA-DAASEN, IEN) ;
• Les non enseignants rattachés administrativement à une collectivité territoriale et pouvant exercer une activité au sein du projet (couvre les personnels des collectivités territoriales et des intercommunalités, les techniciens et ouvriers de service) ;
• Les personnes extérieures intervenant pour une école ou un établissement (couvre les personnels sociaux et de santé, le personnel d’orientation, les contractuels Éducation nationale, les syndicats et associations de parents d’élèves siégeant en conseil d’école ou au conseil d’administration, les prestataires, les invités).
• Les tuteurs de stage et maîtres d’apprentissage des élèves du second degré ;
• Les responsables des entreprises, associations ou entités partenaires des écoles primaires, des établissements d’enseignement secondaire et des services académiques.

3.1.1.2. Catégories de structures

Les structures concernées par l’annuaire ENT pour le premier degré sont les suivantes :

• Les écoles primaires appartenant au périmètre de l’ENT. Il peut s’agir de tout ou partie des structures d'enseignement référencées par le MEN et disposant à ce titre d'un numéro UAI (ex RNE)
  (couvre a minima les écoles maternelles et élémentaires, qu’elles soient publiques, privées ou privées sous contrat) ;
• Les services académiques appartenant au périmètre de l’ENT.
  (couvre a minima les rectorats, les services académiques départementaux et les circonscriptions).
• Les collectivités territoriales appartenant au périmètre de l’ENT
  (couvre a minima les conseils régionaux, les conseils départementaux, les mairies et les intercommunalités).

Les structures concernées par l’annuaire ENT pour le second degré sont les suivantes :

• Les établissements d’enseignement secondaire appartenant au périmètre du projet. Il peut s’agir de tout ou partie des structures d'enseignement référencées par le MEN ou le ministère en charge de l’enseignement agricole et disposant à ce titre d'un numéro UAI (ex-RNE)
  (couvre a minima les collèges et les lycées, qu’ils soient publics ou privés, les établissements d’enseignement agricole) ;
• Les autorités et services académiques appartenant au périmètre du projet.
  (couvre a minima le rectorat ou vice-rectorat, les directions académiques des services départementaux de l’Éducation nationale (DSDEN) les services des DSDEN et pour l’enseignement agricole la direction régionale de l’Alimentation, de l’enseignement agricole et de la Forêt (DRAAF-DAF) et les services régionaux de la Formation et du Développement (SFRD)) ;
• Les collectivités territoriales appartenant au périmètre du projet
  (couvre a minima les conseils régionaux et les conseils départementaux) ;
• Les entreprises partenaires des établissements d’enseignement secondaire et des services académiques appartenant au périmètre du projet
  (couvre a minima les entreprises accueillant des élèves de l’académie en stage ou en apprentissage, les entreprises formant des apprentis, les Chambres de Commerce et d’Industrie et les partenaires socio-culturels).

3.1.2. Modèle de sécurité

Le modèle de sécurité de l’annuaire ENT décrit les associations entre les personnes, les profils applicatifs, les rôles applicatifs et les applications afin de définir les niveaux d’habilitations des acteurs de l’ENT aux différentes applications qui leur sont proposées.

Le soumissionnaire pourra cependant proposer et justifier une solution technique alternative pour gérer les habilitations au sein de sa solution et non au sein de l’annuaire ENT. Il devra alors décrire l’ensemble des modifications à apporter, notamment au modèle et à l’architecture technique.

Ce modèle de sécurité de l’annuaire ENT est représenté en figure 1.

Chaque élément est décrit dans la suite du chapitre.

3.1.2.1. « Personne »

Une Personne est un membre d’une des catégories de personnes définies sur le périmètre adressé par l’annuaire ENT.

Une Personne peut être associée à plusieurs Profils applicatifs.

Une Personne peut être directement associée (si nécessaire) à plusieurs Rôles applicatifs.

3.1.2.2. « Profil applicatif »

Un Profil applicatif est un objet de sécurité permettant le regroupement de Personnes selon des caractéristiques particulières propres à la Personne afin de faciliter les actes d’administration.

Le Profil applicatif peut être défini par rapport à différents niveaux :

• « niveau projet » : identique pour tous les établissements du projet, il permet à un individu d’avoir un profil applicatif permettant des accès aux mêmes services quel que soit l’établissement interne au projet ;
• « niveau établissement » : il permet de personnaliser un profil applicatif particulier à l’établissement.

Un Profil applicatif peut être peuplé selon trois modes :

• « mode Automatique »¹⁴ : une règle de peuplement détermine dynamiquement les Personnes qui appartiennent à un Profil applicatif. Exemple de règle de peuplement d’un profil correspondant aux élèves de Première et de Terminale technologiques : (classe d’objet = « Élève ») ET (filière = « Technologique ») ET ( (niveau = « Première ») OU (niveau = « Terminale ») )
• « mode Discrétionnaire » : les gestionnaires affectent manuellement des Personnes à un Profil applicatif.
• « mode Mixte »: les deux modes précédents sont utilisés pour peupler le Profil applicatif.

La maîtrise d’ouvrage en charge du projet ENT pourra, si elle le souhaite, baser les règles de peuplement sur des attributs supplémentaires.
La réplication filtrée devra être adaptée en conséquence.

Les Profils applicatifs peuvent également être imbriqués (un Profil applicatif peut regrouper d’autres Profils applicatifs) ou exclusifs.

La liste des Profils applicatifs d’une Personne peut également être utilisée dans la règle de peuplement.

Exemple de règle de peuplement d’un profil applicatif regroupant l’ensemble du personnel administratif : (profil = « Secrétariat ») ET (profil = « Personnel de direction »)

3.1.2.3. « Application »

Une Application désigne tout service applicatif proposé aux Personnes et utilisant les services du socle ENT.

Les Applications utilisent tout d’abord le service mutualisé « Gestion d’identités et d’accès » pour contrôler l’authentification d’une Personne en vérifiant la validité des identifiants et des moyens d’authentification présentés.

Les Applications utilisent également le service mutualisé « Gestion d’identités et d’accès » pour contrôler l’accès de la Personne à l’Application, en réalisant les vérifications suivantes :

• la valeur de certains attributs de la Personne (les applications peuvent baser leurs autorisations sur certains attributs du modèle.)
• et/ou l’appartenance de la Personne à au moins un des Profils applicatifs liés à l’Application.

L’Application utilise les Profils applicatifs pour définir des droits d’accès macroscopiques.

3.1.2.4. « Rôle applicatif »

Une Application peut également définir des Rôles applicatifs dans l’annuaire ENT. Un Rôle applicatif donne accès à un ensemble de fonctionnalités au sein de l’application pour laquelle a été défini le Rôle applicatif.

Un Rôle applicatif est défini pour une ou plusieurs Applications. Un Rôle applicatif peut être associé à plusieurs Profils applicatifs et plusieurs Personnes directement.

La gestion de droits plus fins reste du ressort des Applications.

3.1.2.5. Exemple

Une application de gestion du budget de l’établissement déclare dans l’annuaire ENT des rôles applicatifs, qui pour l’application ont la signification suivante :

• « Responsable » : a accès à toutes les fonctions de l’application ;
• « Gestionnaire » : a accès aux fonctions de visualisation et de modification ;
• « Utilisateur » : a accès à la fonction de visualisation.

Les profils applicatifs « Personnels de direction » et « Personnels d’intendance » sont associés au rôle « Responsable », le profil applicatif « Personnels administratifs » est associé au rôle « Gestionnaire » et le profil applicatif « Conseillers d’éducation » est associé au rôle « Utilisateur ». Le rôle applicatif « Responsable » est directement attribué à une des personnes.

3.1.2.6. Remarques

Le présent document ne tient pas compte, à ce stade, de fonctionnalités spécifiques proposés par le soumissionnaire.

Le soumissionnaire précisera les impacts de ces fonctions sur le modèle de données de l’annuaire.

Le modèle présenté peut éventuellement être adapté ou limité en fonction des implémentations proposées par le soumissionnaire :

• Exemples de limitations : pas d’utilisation des groupes dynamiques, limitation de la taille des groupes statiques…
• Exemples d’adaptations : utilisation de la classe d’objet ou d’une combinaison d’attributs existants pour déterminer l’appartenance à un profil applicatif partagé… Des solutions différentes pourront notamment être proposées en fonction des catégories de personnes, du fait des différences de volumétrie et de la possibilité ou non d’utiliser la classe d’objet pour déterminer l’appartenance à un profil.

Le soumissionnaire précisera donc, en fonction des capacités des services AAS qu’il propose et de l’impact de la volumétrie sur les performances, les limitations et les adaptations proposées sur le modèle de sécurité.

Le soumissionnaire pourra également adapter le modèle afin de définir des habilitations à partir des groupes de personnes. Il devra alors décrire l’ensemble des modifications à apporter à ce modèle de sécurité.

3.1.3. Caractérisation des personnes et des structures

3.1.3.1. Dans le premier degré

Les paragraphes exposés ensuite expliquent les relations entre les différents éléments du modèle.

3.1.3.1.1. Description des personnes

# 3.1.3.1.1.1. Élève

Un Élève appartient à une et une seule École.

Un Élève est en relation avec une, ou plusieurs Personnes en relation avec l’élève.

Un Élève appartient à zéro, un, ou plusieurs Groupes spécifiques. Ces Groupes peuvent regrouper des personnes d’Ecoles différentes.

Un Élève appartient à une ou plusieurs Classes, sauf dans le cas particulier des écoles virtuelles qui ne comportent aucune classe : les élèves concernés n’appartiennent donc à aucune classe.

# 3.1.3.1.1.2. Personne en relation avec l’élève

Une Personne en relation avec l’élève est en relation avec un ou plusieurs Élèves.

Une Personne en relation avec l’élève appartient à zéro, un, ou plusieurs Groupes spécifiques.

# 3.1.3.1.1.3. Enseignant

Un Enseignant exerce dans zéro, une ou plusieurs Écoles.

Un Enseignant enseigne dans zéro, une, ou plusieurs Classes. Il peut être responsable d’une ou plusieurs des Classes dans lesquelles il enseigne.

Un Enseignant appartient à zéro, un, ou plusieurs Groupes spécifiques.

# 3.1.3.1.1.4. Non enseignant

Un Non enseignant exerce dans zéro, une ou plusieurs Écoles.

Un Non enseignant est rattaché administrativement soit à une et une seule Collectivité territoriale, soit à un et un seul Service académique.

Un Non Enseignant appartient à zéro, un, ou plusieurs Groupes spécifiques.

# 3.1.3.1.1.5. Personne extérieure

Une Personne extérieure intervient dans une ou plusieurs Écoles.

Une Personne extérieure appartient à zéro, un, ou plusieurs Groupes spécifiques.

3.1.3.1.2. Description des structures liées aux personnes

# 3.1.3.1.2.1. École

À une École sont rattachés zéro, un ou plusieurs Élèves.

À une École sont rattachés zéro, un ou plusieurs Enseignants.

Une École est liée à une et une seule Collectivité territoriale.

Une École est liée à un et un seul Service académique.

Dans une École exercent zéro, un, ou plusieurs Non enseignants.

Dans une École interviennent zéro, une ou plusieurs Personnes extérieures.

Une École possède une ou plusieurs Classes.

Une École possède zéro, un, ou plusieurs Groupes spécifiques.

Une École fait partie de zéro, un ou plusieurs groupements d’écoles. Ces groupements d’écoles peuvent être un Regroupement Pédagogique Intercommunal (RPI).

# 3.1.3.1.2.2. Collectivité territoriale

Une Collectivité territoriale est liée à une ou plusieurs Écoles.

À une Collectivité territoriale sont rattachés administrativement zéro, un ou plusieurs Non enseignants.

# 3.1.3.1.2.3. Services académiques

Un Service académique est lié à zéro, une ou plusieurs Écoles.

À un Service académique sont rattachés administrativement zéro, un ou plusieurs Non enseignants.

3.1.3.1.3. Description regroupements de personnes ou de structures

# 3.1.3.1.3.1. Classe

Une Classe appartient à une et une seule École.

Une Classe regroupe zéro, un ou plusieurs Élèves.

Une Classe reçoit l’Enseignement d’un ou plusieurs Enseignants. Parmi ces Enseignants, un seul en a la responsabilité.

# 3.1.3.1.3.2. Groupe spécifique

Un Groupe spécifique appartient à zéro, une ou plusieurs Écoles.

Un Groupe spécifique regroupe une ou plusieurs Personnes qui peuvent être rattachées à des Écoles différentes.

Un Groupe spécifique contenant au moins un Élève doit contenir au moins un adulte de l’Éducation Nationale.

# 3.1.3.1.3.3. Groupement d’écoles

Un Groupement d’écoles regroupe au minimum deux Écoles.

Un Groupement d’écoles appartient à zéro, un ou plusieurs Groupement d’écoles.

Un Groupement d’écoles regroupe zéro, un ou plusieurs Groupement d’écoles.

3.1.3.2. Dans le second degré

Le modèle ci-après prend en compte le fait qu’une personne puisse appartenir à plusieurs catégories. Il peut s’agir par exemple d’un enseignant qui est également responsable d’un élève ou encore d’un enseignant qui assure des fonctions administratives dans un établissement (chef d’établissement notamment).

La figure suivante est une illustration de la caractérisation des personnes de l’annuaire ENT.

Les paragraphes ci-après expliquent les relations entre les différents éléments du modèle.

3.1.3.2.1. Description des personnes

# 3.1.3.2.1.1. Élève

Un Élève est rattaché administrativement à un et un seul Établissement.

Un Élève est en relation avec zéro (élève majeur), une, ou plusieurs Personnes en relation avec l’élève.

Un Élève suit un ou plusieurs Enseignements.

Un Élève effectue zéro ou un stage/apprentissage simultanément. Pour ce stage/apprentissage, il est suivi par un ou plusieurs Enseignants, et un ou plusieurs Tuteurs de stage ou maîtres d’apprentissage. Parmi les Enseignants qui suivent l’Élève durant son stage/apprentissage, un seul est responsable de l’Élève.

Un Élève appartient à zéro, un, ou plusieurs Groupes. Ces Groupes peuvent se trouver dans des Établissements différents.

Un Élève appartient au moins à une Classe. Un Élève peut appartenir à plusieurs Classes, mais à une seule Classe par Établissement.

Remarque : Dans certains cas, un élève peut être amené à utiliser plusieurs ENT. En effet, si un élève suit des enseignements dans un établissement autre que son établissement de rattachement administratif et que les deux établissements ne sont pas « couverts » par le même ENT, cet élève est géré dans les deux ENT. Ce besoin d’accès à de multiples ENT peut également concerner des enseignants, des personnes en relation avec l’élève ou des non enseignants.

# 3.1.3.2.1.2. Personne en relation avec l’élève

Une Personne en relation avec l’élève est en relation avec un ou plusieurs Élèves.

# 3.1.3.2.1.3. Enseignant

Un Enseignant est rattaché administrativement à un et un seul Établissement.

Un Enseignant exerce une ou plusieurs Disciplines dans un ou plusieurs Établissements.

Un Enseignant enseigne dans zéro, une, ou plusieurs Classes.

Un Enseignant enseigne dans zéro, un, ou plusieurs Groupes.

Un Enseignant suit zéro, un, ou plusieurs Élèves durant leur stage/apprentissage. Parmi les Enseignants qui suivent un Élève durant son stage/apprentissage, un seul est responsable de l’Élève.

# 3.1.3.2.1.4. Non enseignant

Un Non enseignant peut exercer une activité dans un ou plusieurs Domaines, dans un ou plusieurs Établissements.

Un Non enseignant est lié soit à une et une seule Collectivité locale, soit à un et un seul ensemble de Services académiques, soit à un et un seul Établissement.

# 3.1.3.2.1.5. Personnel extérieur

Un Personnel extérieur exerce une activité dans un ou plusieurs Établissements.

# 3.1.3.2.1.6. Tuteur de stage ou maître d’apprentissage

Un Tuteur de stage ou maître d’apprentissage suit un ou plusieurs Élèves durant leur stage/apprentissage.

Un Tuteur de stage ou maître d’apprentissage travaille dans une Entreprise partenaire.

# 3.1.3.2.1.7. Responsable d’entreprise

Un Responsable d’entreprise est responsable d’une ou plusieurs Entreprises partenaires.

3.1.3.2.2. Description des structures liées aux personnes

# 3.1.3.2.2.1. Établissement

À un Établissement sont rattachés administrativement un ou plusieurs Élèves.

Un Établissement est lié à une et une seule Collectivité locale.

Un Établissement est lié à un et un seul ensemble de Services académiques.

À un Établissement sont rattachés administrativement zéro, un, ou plusieurs Non enseignants.

Dans un Établissement, zéro, un, ou plusieurs Non enseignants (rattachés administrativement ou non) peuvent exercer une activité dans un ou plusieurs Domaines.

Dans un Établissement, zéro, un, ou plusieurs Personnels extérieurs peuvent exercer une activité.

Dans un Établissement sont exercées une ou plusieurs Disciplines par un ou plusieurs Enseignants.

Un Établissement possède une ou plusieurs Classes.

Un Établissement possède zéro, un, ou plusieurs Groupes.

Un Établissement fait partie de zéro, un, ou plusieurs Groupements d’établissements.

Un Établissement est partenaire d’une ou plusieurs Entreprises partenaires.

# 3.1.3.2.2.2. Collectivité locale

Une Collectivité locale est liée à un ou plusieurs Établissements.

À une Collectivité locale sont rattachés administrativement zéro, un ou plusieurs Non enseignants.

# 3.1.3.2.2.3. Services académiques

Un ensemble de Services académiques est liée à un ou plusieurs Établissements.

À un ensemble de Services académiques sont rattachés administrativement zéro, un ou plusieurs Non enseignants.

# 3.1.3.2.2.4. Entreprise partenaire

Une Entreprise partenaire est dirigée par un et un seul Responsable d’entreprise.

Une Entreprise partenaire est partenaire d’un ou plusieurs Établissements.

Dans une Entreprise partenaire travaillent zéro, un ou plusieurs Tuteurs de stage ou maîtres d’apprentissage.

3.1.3.2.3. Description des autres types de données liés aux personnes

# 3.1.3.2.3.1. Domaine

Un Domaine peut correspondre à l’activité d’un ou plusieurs Non enseignants dans un ou plusieurs Établissements.

# 3.1.3.2.3.2. Discipline

Une Discipline peut être exercée par un ou plusieurs Enseignants dans un ou plusieurs Établissements.

# 3.1.3.2.3.3. Classe

Une Classe appartient à un et un seul Établissement.

Une Classe regroupe un ou plusieurs Élèves qui peuvent être rattachés administrativement à des Établissements différents.

Une Classe reçoit l’Enseignement d’un ou plusieurs Enseignants.

# 3.1.3.2.3.4. Groupe

Un Groupe appartient à un et un seul Établissement.

Un Groupe regroupe zéro, un, ou plusieurs Élèves qui peuvent être rattachés administrativement à des Établissements différents.

Un Groupe reçoit l’Enseignement d’un ou plusieurs Enseignants.

# 3.1.3.2.3.5. Groupe libre (créé dans un établissement) ou groupe Adhoc

Un Groupe Adhoc appartient à un et un seul établissement

Un groupe Adhoc peut contenir des personnes de plusieurs établissements

Un Groupe Adhoc regroupe zéro, une, ou plusieurs personnes

Un Groupe Adhoc n’a plus lieu d’être s’il est vide

# 3.1.3.2.3.6. Enseignement

Un Enseignement est suivi par zéro, un, ou plusieurs Élèves.

# 3.1.3.2.3.7. Groupement d’établissements

Un Groupement d’établissements regroupe deux ou plus Établissements. Le terme Groupement d’établissements inclut les bassins de formation, les cités scolaires et les GRETA.

3.2. Description de l’annuaire ENT

3.2.1. Description des classes d’objet de l’annuaire ENT

Remarques : sauf mention contraire, les « classes » dont il est question dans ce chapitre sont des classes au sens LDAP.

3.2.1.1. Gestion des objets de l’annuaire ENT

3.2.1.1.1. Personnes appartenant à plusieurs catégories de personnes

# 3.2.1.1.1.1. Dans le premier degré

Une personne peut appartenir à plusieurs catégories de personnes. Il peut s’agir par exemple d’un enseignant qui est également responsable d’un élève.

Dans le cadre de l’ENT, une telle personne possèdera deux comptes distincts. En particulier, aucun rapprochement ne sera effectué par le dispositif d’alimentation MEN.

Aucune contrainte n’interdit la gestion du « multiprofil » dans la solution ENT. Les projets ENT qui le souhaitent pourront donc compléter les services offerts en permettant d’appartenir à plusieurs catégories de personnes et en mettant en œuvre des mécanismes de sélection de profil au moment de l’accès à l’ENT, voire de « réconciliation » de plusieurs identités.

# 3.2.1.1.1.2. Dans le second degré

Une personne peut appartenir à plusieurs catégories de personnes. Il peut s’agir par exemple d’un enseignant qui est également parent d’un élève.

L’entrée de l’annuaire ENT représentant une telle personne doit disposer de l’ensemble des caractéristiques propres à chacune des catégories de la personne.

C’est pourquoi le schéma de l’annuaire ENT est basé sur l’utilisation de classes LDAP auxiliaires, qui permettent de compléter une entrée de l’annuaire ENT avec des attributs spécifiques. En cumulant plusieurs classes auxiliaires sur l’entrée d’une même personne, celle-ci disposera de tous les attributs nécessaires en fonction des catégories de personnes auxquelles elle appartient.

Exemple de création d’un enseignant qui est également parent d’un élève :

• Un objet est créé à partir de la classe ENTPerson. L’objet dispose ainsi des attributs communs à tous les utilisateurs de l’ENT.
• La personne étant enseignante, il faut ajouter la classe auxiliaire ENTAuxEnseignant à l’objet. Celui-ci dispose alors d’attributs tels que les disciplines enseignées, les classes dont la personne est professeur principal…
• Étant également responsable d’élève, il faut ajouter la classe auxiliaire ENTAuxPersRelEleve à l’objet. Celui-ci dispose alors d’attributs tels que les élèves en responsabilité…

Il n’est pas possible de restreindre les classes LDAP structurelles que peut venir compléter une classe auxiliaire. Un contrôle d’intégrité devra donc être assuré au niveau des services de gestion de contenu afin de ne permettre l’ajout de classes auxiliaires qu’à la classe structurelle ENTPerson. Les élèves (classe ENTEleve) ne peuvent en effet pas appartenir à plusieurs catégories.

Par ailleurs, l’ENT pourra offrir aux utilisateurs un service permettant de réconcilier les identités distinctes qu’ils possèdent dans chacune des catégories.

3.2.1.1.2. Personnes exerçant dans plusieurs écoles ou établissements

Certaines personnes exercent leur activité dans plusieurs écoles ou établissements :

• des élèves suivent des cours dans plusieurs établissements ;
• des enseignants interviennent dans plusieurs écoles ou établissements ;
• des personnels non enseignants ou administratifs dépendant d’une collectivité territoriale exercent des fonctions dans plusieurs écoles ou établissements.

En conséquence, ces personnes accèdent à plusieurs ENT d’établissement. Selon les cas, ces ENT relèvent du même projet ENT ou de projets différents (les possibilités de rapprochement des comptes sont donc différentes).

Il est donc nécessaire de distinguer la structure de rattachement administratif et la ou les structures d’exercice. C’est pourquoi tout utilisateur de l’ENT possède l’attribut « ENTPersonStructRattach » pour désigner la ou les structures de rattachement administratif. Ce rattachement est de nature administrative pour les structures de type collectivité et service académique.

Les structures d’exercice peuvent être déduites d’autres attributs :

• de l’attribut « ENTPersonFonctions » pour les personnels du second degré
• des classes et des groupes dans les différentes écoles pour les élèves et les enseignants ;
• des fonctions pour les enseignants et les non enseignants ;
• des élèves pour les personnes en relation avec l’élève

3.2.1.1.3. Qualification des relations multiples entre objets de l’annuaire ENT

Une certaine complexité peut apparaître dans le schéma LDAP lorsqu’il est nécessaire de qualifier des relations « n – n » entre objets.
Exemple : « Comment qualifier la relation entre un élève et une personne, sachant qu’un élève peut être en relation avec plusieurs personnes dont le rôle est différent, et qu’une personne peut être en relation avec plusieurs élèves et jouer un rôle différent vis-à-vis de chaque élève ? ».

Afin de qualifier d’éventuelles relations supplémentaires concernant un Élève, il est possible d’utiliser la classe ENTRelEleve. Une instance de ce groupe doit être créée pour chaque relation entre chaque couple « Élève – Personne en relation avec l’élève ». Un attribut du groupe permet de qualifier cette relation. Il conviendra toutefois d’être attentif au volume d’entrées supplémentaires générées dans l’annuaire ENT par cette solution.

Afin de transmettre les informations issues de SIECLE, l’attribut ENTElevePersRelEleve contient le dn de la personne en relation suivi des « codes » type de relation, responsable financier, responsable légal, contact, bénéficiaire.
Remarque : Ces informations sont cependant amenées à évoluer du fait de l’évolution de la gestion des responsables dans SIECLE.

3.2.1.2. Schéma LDAP

Les classes LDAP standard sont utilisées autant que possible afin de faciliter la mise en place d’applications génériques. Les attributs non disponibles dans le schéma standard sont ajoutés dans des classes dédiées à l’ENT par extension du schéma.

Le schéma LDAP de l’annuaire ENT est représenté sur la Figure 12. Les différentes classes sont décrites dans la suite du chapitre.

Le récapitulatif des attributs par catégorie de personnes ou de structures est donné dans le contrat d’interface AAF. Notons que le caractère facultatif ou obligatoire d’un attribut hérité peut varier en fonction de la catégorie de personnes ou de structures.

Remarque : Des attributs à caractère technique pourront être ajoutés au schéma LDAP afin de couvrir les besoins du service mutualisé « Gestion d’identités et d’accès » (utilisateur suspendu, date de validité, « challenges »…).

Figure 12 : Schéma LDAP de l’annuaire ENT

3.2.1.3. Classes d’objets relatives aux personnes

Figure 13 : Diagramme d'héritage pour les classes d’objets relatives aux personnes

3.2.1.3.1. Classes person, organizationalPerson et inetOrgPerson

Les classes person, organizationalPerson et inetOrgPerson sont des classes LDAP standard qui servent de base pour décrire des personnes. Les attributs correspondants sont donnés dans le tableau ci-dessous.

Les attributs grisés ne sont pas utilisés par le modèle d’information de l’annuaire ENT.

Une ligne barrée dans les tableaux ci-dessous indique un attribut présent pour des raisons de rétrocompatibilité. Cet attribut ne devrait pas faire partie de la structure de l'annuaire ENT. Notons qu'il pourra être supprimé dans une future mise à jour majeure du cahier des charges.

Les cellules en italique correspondent à des contraintes spécifiques à l’annuaire ENT sur les propriétés des attributs. Ces contraintes d’intégrité devront être contrôlées par les services de gestion de contenu en plus de celles mentionnées au chapitre 3.3.
Exemple : le standard LDAP autorise l’attribut « telephoneNumber » à être multi-valué alors que dans le modèle de l’annuaire ENT cet attribut doit être mono-valué.

Les classes person, organizationalPerson et inetOrgPerson ne doivent pas être instanciées dans l’annuaire ENT.

3.2.1.3.2. Objet personne Classe ENTPerson

La classe ENTPerson hérite de la classe inetOrgPerson et ajoute les attributs communs à toutes les personnes de l’ENT. Ces attributs sont donnés dans le tableau ci-dessous.

Tableau 2 : description des attributs LDAP pour l’objet personne

L’attribut « ENTPersonProfils » doit être mis à jour lors de l’attribution ou du retrait d’un profil applicatif à une personne.

L’attribut « ENTPersonFonctions » doit être utilisé pour déterminer l’ensemble des établissements d’exercices d’un enseignant, l’attribut « ENTPersonStructRattach » fournissant uniquement l’établissement de rattachement administratif de l’enseignant.

Dans le cas où l’attribut « ENTPersonFonctions » est alimenté par le SI du ministère en charge de l’enseignement agricole, une attention particulière doit être portée à la nomenclature spécifique utilisée : N_FAMILLE_POSTE_EA.

Les attributs « ENTPersonAutresMails » et « ENTPersonAutresMobiles » doivent être utilisés pour laisser la possibilité aux utilisateurs de l’ENT de renseigner directement leurs coordonnées personnelles (adresse e-mail, numéro de téléphone mobile) dans l’ENT. Le stockage de ces informations dans ces champs a pour but de ne pas écraser les données de même type (attributs « mail » et « mobile ») qui doivent être uniquement alimentées par des flux automatisés.

La classe ENTPerson peut être complétée par une ou plusieurs des classes auxiliaires définies dans le modèle. Ces classes auxiliaires sont détaillées dans la suite du chapitre.

3.2.1.3.3. Objet élève (Classe ENTEleve)

La classe ENTEleve hérite de la classe ENTPerson et ajoute les attributs relatifs à la catégorie de personnes « Élèves ». Ces attributs sont donnés dans le tableau ci-dessous.

L’attribut « ENTEleveClasses » doit être utilisé pour déterminer l’ensemble des établissements d’un élève, l’attribut « ENTPersonStructRattach » fournissant uniquement l’établissement de rattachement administratif de l’élève.

3.2.1.3.4. Objet personne en relation avec l’élève (classes ENTPersRelEleve et ENTAuxPersRelEleve)

La classe ENTPersRelEleve hérite de la classe ENTPerson et ajoute les attributs relatifs à la catégorie de personnes Personne en relation avec l’élève de l’enseignement primaire.

La classe ENTAuxPersRelEleve est une classe auxiliaire permettant de compléter la classe ENTPerson avec les attributs relatifs à la catégorie de personnes « Personnes en relation avec les élèves » des enseignements secondaire et agricole. Ces attributs sont donnés dans le tableau ci-dessous.

Tableau 4 : description des attributs LDAP pour l’objet personne en relation avec l’élève

La classe auxiliaire ENTAuxPersRelEleve ne doit compléter que des objets appartenant à la classe ENTPerson.

3.2.1.3.5. Objet personnel enseignant (classes ENTEnseignant et ENTAuxEnseignant)

La classe ENTEnseignant hérite de la classe ENTPerson et ajoute les attributs relatifs à la catégorie de personnes Personnel enseignant de l’enseignement primaire.

La classe ENTAuxEnseignant est une classe auxiliaire permettant de compléter la classe ENTPerson avec les attributs relatifs à la catégorie de personnes Enseignants des enseignements secondaire et agricole. Ces attributs sont donnés dans le tableau ci-dessous.

Tableau 5 : description des attributs LDAP pour l’objet personnel enseignant

La classe auxiliaire ENTAuxEnseignant ne doit compléter que des objets appartenant à la classe ENTPerson.

L’attribut ENTAuxEnsCategoDiscipline fournit des codes pivots pour les disciplines d’enseignements uniquement. Il n’existe pas de pivots pour les autres fonctions.

3.2.1.3.6. Objet personnel non enseignant (classes ENTNonEnsEcole et ENTAuxNonEnsEtab)

La classe ENTNonEnsEcole hérite de la classe ENTPerson et ajoute les attributs relatifs à la catégorie de personnes Personnel non enseignant (non enseignants intervenant dans une ou plusieurs écoles).

La classe ENTAuxNonEnsEtab est une classe auxiliaire permettant, pour les personnels du secondaire et agricole, de compléter la classe ENTPerson avec les attributs relatifs à la catégorie de personnes Non enseignants rattachés administrativement à un établissement d’enseignement. Ces attributs sont donnés dans le tableau ci-dessous.

Tableau 6 : description des attributs LDAP pour l’objet personnel non enseignant

La classe auxiliaire ENTAuxNonEnsEtab ne doit compléter que des objets appartenant à la classe ENTPerson.

3.2.1.3.7. Objet personnel académique (classes ENTNonEnsServAc et ENTAuxNonEnsServAc)

La classe ENTNonEnsServAc hérite de la classe ENTNonEnsEcole et ajoute les attributs relatifs à la catégorie de personnes Personnel académique (non enseignants rattachés administrativement aux services académiques intervenant dans une ou plusieurs écoles).

La classe ENTAuxNonEnsServAc est une classe auxiliaire permettant, pour les personnels du secondaire et agricole, de compléter la classe ENTPerson avec les attributs relatifs à la catégorie de personnes Non enseignants rattachés administrativement aux services académiques. Ces attributs sont donnés dans le tableau ci-dessous.

Tableau 7 : description des attributs LDAP pour l’objet personnel académique

La classe auxiliaire ENTAuxNonEnsServAc ne doit compléter que des objets appartenant à la classe ENTPerson.

3.2.1.3.8. Objet personnel collectivité (classes ENTNonEnsCollLoc et ENTAuxNonEnsCollLoc)

La classe ENTNonEnsCollLoc hérite de la classe ENTNonEnsEcole et ajoute les attributs relatifs à la catégorie de personnes Personnel collectivité (non enseignants rattachés administrativement à une collectivité territoriale intervenant dans une ou plusieurs écoles).

La classe ENTAuxNonEnsCollLoc est une classe auxiliaire permettant, pour les personnels du secondaire et agricole, de compléter la classe ENTPerson avec les attributs relatifs à la catégorie de personnes Non enseignants rattachés administrativement à une collectivité locale. Ces attributs sont donnés dans le tableau ci-dessous.

Tableau 8 : description des attributs LDAP pour l’objet personnel collectivité

La classe auxiliaire ENTAuxNonEnsCollLoc ne doit compléter que des objets appartenant à la classe ENTPerson.

3.2.1.3.9. Objet personne extérieure (classes ENTPersExt et ENTAuxPersExt)

La classe ENTPersExt hérite de la classe ENTPerson et ajoute les attributs relatifs à la catégorie de personnes Personnes extérieures (personne intervenant en tant qu’enseignant dans une classe mais n’appartenant pas à l’Education Nationale).

La classe ENTAuxPersExt est une classe auxiliaire permettant de compléter, pour les personnels du secondaire et agricole, la classe ENTPerson avec les attributs relatifs à la catégorie de personnes Personnels extérieurs. Ces attributs sont donnés dans le tableau ci-dessous.

Tableau 9 : description des attributs LDAP pour l’objet personne extérieure

La classe auxiliaire ENTAuxPersExt ne doit compléter que des objets appartenant à la classe ENTPerson.

3.2.1.3.10. Classe ENTAuxTuteurStage

La classe ENTAuxTuteurStage est une classe auxiliaire permettant de compléter, pour les personnels du secondaire et agricole, la classe ENTPerson avec les attributs relatifs à la catégorie de personnes Tuteurs de stage et maîtres d’apprentissage. Ces attributs sont donnés dans le tableau ci-dessous.

Tableau 10 : description des attributs LDAP pour la classe tuteur de stage

La classe auxiliaire ENTAuxTuteurStage ne doit compléter que des objets appartenant à la classe ENTPerson.

3.2.1.3.11. Classe ENTAuxRespEntrp

La classe ENTAuxRespEntrp est une classe auxiliaire permettant de compléter, pour les personnels du secondaire et agricole, la classe ENTPerson avec les attributs relatifs à la catégorie de personnes Responsables des entreprises partenaires. Ces attributs sont donnés dans le tableau ci-dessous.

Tableau 11 : description des attributs LDAP pour la classe responsables des entreprises partenaires

La classe auxiliaire ENTAuxRespEntrp ne doit compléter que des objets appartenant à la classe ENTPerson.

3.2.1.3.12. Classe ENTPersonRelation

La classe ENTPersonRelation est une classe auxiliaire permettant de compléter la classe ENTPerson avec les attributs relatifs à la définition des opérations de réconciliation entre comptes utilisateurs. Ces attributs sont donnés dans le tableau ci-dessous.

Tableau 12 : description des attributs LDAP pour la classe PersonRelation

Les attributs « ENTPersRelFusionPrincipal » et « ENTPersRelFusionSecondaire » sont essentiellement utilisés pour permettre un retour arrière et annuler une opération de fusion effectuée par erreur.

La classe auxiliaire ENTPersonRelation ne doit compléter que des objets appartenant à la classe ENTPerson.

3.2.1.4. Classes d’objets relatives aux structures

3.2.1.4.1. Classe organizationalUnit

La classe organizationalUnit est une classe LDAP standard qui sert de base pour décrire des structures. Les attributs sont donnés dans le tableau ci-dessous.

Les attributs grisés ne sont pas utilisés par le modèle d’information de l’annuaire ENT.

Les cellules en italique correspondent à des restrictions spécifiques à l’annuaire ENT sur les propriétés d’attributs. Ces contraintes d’intégrité devront être contrôlées par les services de gestion de contenu en plus de celles mentionnées au chapitre 3.3.

Tableau 13 : description des attributs LDAP pour la classe organizationalUnit

3.2.1.4.2. Objet structure (classe ENTStructure)

La classe ENTStructure est une classe abstraite qui hérite de la classe organizationalUnit et la complète avec les attributs communs à toutes les structures de l’ENT. Ces attributs sont donnés dans le tableau ci-dessous.

Tableau 14 : description des attributs LDAP pour l’objet structure

La classe abstraite ENTStructure ne peut pas être instanciée.

3.2.1.4.3. Objet école et établissement (classes ENTEcole et ENTEtablissement)

La classe ENTEcole hérite de la classe ENTStructure et ajoute les attributs relatifs à la catégorie de structures Ecoles.

La classe ENTEtablissement complète la classe ENTStructure avec les attributs relatifs à la catégorie de structures Établissements d’enseignement. Ces attributs sont donnés dans le tableau ci-dessous.

Tableau 15 : description des attributs LDAP pour l’objet école ou établissement

3.2.1.4.4. Objet Service académique (classe ENTServAc)

La classe ENTServAc hérite de la classe ENTStructure et ajoute les attributs relatifs à la catégorie de structures Services académiques. Ces attributs sont donnés dans le tableau ci-dessous.

Tableau 16 : description des attributs LDAP pour l’objet service académique

3.2.1.4.5. Objet Collectivité locale (classe ENTCollLoc)

La classe ENTCollLoc hérite de la classe ENTStructure et ajoute les attributs relatifs à la catégorie de structures Collectivité territoriale. Ces attributs sont donnés dans le tableau ci-dessous.

Tableau 17 : description des attributs LDAP pour l’objet collectivité locale

3.2.1.4.6. Objet Entreprise Classe ENTEntreprise

La classe ENTEntreprise complète la classe ENTStructure avec les attributs relatifs à la catégorie de structures Entreprises partenaires. Ces attributs sont donnés dans le tableau ci-dessous.

Tableau 18 : description des attributs LDAP pour l’objet entreprise

3.2.1.5. Classes relatives aux groupes d’entrées de l’annuaire ENT

3.2.1.5.1. Dans le premier degré

# 3.2.1.5.1.1. Objet groupe (classe ENTGroupe)

La classe ENTGroupe est une classe abstraite qui regroupe les attributs communs à tous les groupes de l’ENT (regroupements de personnes ou de structures).

La classe abstraite ENTGroupe ne peut pas être instanciée.

# 3.2.1.5.1.2. Objet classe (classe ENTClasse)

La classe ENTClasse hérite de la classe ENTGroupe et ajoute les attributs relatifs aux classes d’élèves.

Les classes sont définies par école. L’attribut « ENTGroupeEcoleProprietaire correspond à l’identifiant de l’école pour laquelle est définie la classe.

# 3.2.1.5.1.3. Objet groupe spécifique (classe ENTGroupeSpecifique)

La classe ENTGroupeSpecifique hérite de la classe ENTGroupe et ajoute les attributs relatifs aux groupes spécifiques (tout groupe de personnes autre que les classes : groupe d’enseignement, association de parents, …).

Les groupes spécifiques sont définis par école. L’attribut « ENTGroupeEcoleProprietaire » correspond à l’identifiant de l’école pour laquelle est défini le groupe spécifique.

# 3.2.1.5.1.4. Objet regroupement d’écoles (classe ENTGroupementEcoles)

La classe ENTGroupementEcoles hérite de la classe ENTGroupe et ajoute les attributs relatifs aux regroupements d’écoles. Un regroupement d’école peut être institutionnel (cas des écoles regroupées dans une circonscription, un secteur de collège ou un RPI par exemple) ou ad hoc (regroupement d’écoles créés spécifiquement pour les besoins d’un projet ENT). Un regroupement d’écoles peut regrouper des structures de type « école » aussi bien que d’autres regroupements d’écoles.

3.2.1.5.2. Dans le second degré

# 3.2.1.5.2.1. Classe groupOfNames

La classe groupOfNames est une classe LDAP standard qui sert de base pour décrire des groupes d’entrées de l’annuaire ENT (groupes de personnes, de structures, de groupes…). Les attributs correspondants sont donnés dans le tableau ci-dessous.

Les attributs grisés ne sont pas utilisés par le modèle d’information de l’annuaire ENT.

Les cellules en italique correspondent à des restrictions spécifiques à l’annuaire ENT sur les propriétés d’attributs. Ces contraintes d’intégrité devront être contrôlées par les services de gestion de contenu en plus de celles mentionnées au chapitre 3.3.

Tableau 19 : description des attributs LDAP pour la classe GroupOfNames

# 3.2.1.5.2.2. Classe ENTClasse

Remarque : il est ici question de la « classe LDAP » représentant une « classe d’élèves ».

La classe ENTClasse hérite de la classe groupOfNames et ajoute les attributs relatifs aux classes des élèves. Ces attributs sont donnés dans le tableau ci-dessous.

Les classes sont définies par établissement d’enseignement. L’attribut « owner », hérité de groupOfNames, correspond au « dn » de l’établissement d’enseignement pour lequel est définie la classe.

L’attribut « member », hérité de groupOfNames, correspond aux « dn » des élèves de la classe.

L’attribut « cn » doit désigner de façon unique une classe sur le périmètre de l’ENT. La règle de construction proposée est la suivante : le nom d’une classe doit être préfixé du numéro SIREN de l’établissement d’enseignement pour lequel elle est définie, suivi d’un « _ ».
Exemple : 123456789_3eme2

La maîtrise d’ouvrage en charge du projet ENT pourra éventuellement définir sa propre règle de construction.

# 3.2.1.5.2.3. Classe ENTGroupe

La classe ENTGroupe hérite de la classe groupOfNames et ajoute les attributs relatifs aux groupes d’élèves. Ces attributs sont donnés dans le tableau ci-dessous.

Les groupes d’élèves sont définis par établissement d’enseignement. L’attribut « owner », hérité de groupOfNames, correspond au « dn » de l’établissement d’enseignement pour lequel est défini le groupe.

L’attribut « member », hérité de groupOfNames, correspond aux « dn » des élèves du groupe.

L’attribut « cn » doit désigner de façon unique un groupe d’élèves sur le périmètre de l’ENT. La règle de construction proposée est la suivante : le nom du groupe d’élèves peut être préfixé du numéro SIREN pour lequel il est défini, suivi d’un « _ ».
Exemple : 123456789_latin2

# 3.2.1.5.2.4. Classe ENTGroupementEtabs

La classe ENTGroupementEtabs hérite de la classe groupOfNames et ajoute les attributs relatifs aux groupements d’établissements (bassins de formation, cités scolaires, GRETA). Ces attributs sont donnés dans le tableau ci-dessous.

L’attribut « owner », hérité de groupOfNames, n’est pas renseigné.

L’attribut « member », hérité de groupOfNames, correspond aux « dn » des établissements qui constituent le regroupement.

L’attribut « cn » doit désigner de façon unique un groupement d’établissements sur le périmètre de l’ENT.

# 3.2.1.5.2.5. Classe ENTProfil

La classe ENTProfil hérite de la classe groupOfNames et ajoute les attributs relatifs aux profils applicatifs décrits dans le modèle de sécurité de l’annuaire ENT. Ces attributs sont donnés dans le tableau ci-dessous.

Tableau 23 : description des attributs LDAP pour la classe ENTProfil

Il existe deux types de profils applicatifs :

• les profils applicatifs partagés au niveau du projet et qui sont donc transverses aux établissements d’un ENT ; dans ce cas, l’attribut « owner », hérité de groupOfNames, n’est pas renseigné) ;
• les profils applicatifs locaux définis sur le périmètre d’une structure (établissement notamment) ; dans ce cas, l’attribut « owner », hérité de groupOfNames, correspond au « dn » de l’établissement d’enseignement qui a défini le profil applicatif.

L’attribut « member », hérité de groupOfNames, correspond aux « dn » des personnes associées à ce profil applicatif.

L’attribut « cn » doit désigner de façon unique un groupement d’établissements sur le périmètre de l’ENT. La règle de construction est la suivante :

• les profils applicatifs partagés au niveau projet sont préfixés par le code projet ENT : « LxxCiiii »
• les profils applicatifs définis par des structures sont préfixés par le numéro UAI de la structure suivi de « _ ».

Des informations complémentaires sur les règles de peuplement des profils applicatifs sont données au chapitre 3.2.

# 3.2.1.5.2.6. Classe ENTRoleAppli

La classe ENTRoleAppli hérite de la classe groupOfNames et ajoute les attributs relatifs aux rôles applicatifs décrits dans le modèle de sécurité de l’annuaire ENT. Ces attributs sont donnés dans le tableau ci-dessous.

Tableau 24 : description des attributs LDAP pour la classe ENTRoleAppli

Un rôle applicatif est défini par rapport à une ou plusieurs applications données. L’attribut « owner », hérité de groupOfNames, correspond au « dn » de ou des applications qui ont défini le rôle applicatif. Cet attribut doit nécessairement être renseigné.

L’attribut « member », hérité de groupOfNames, correspond aux « dn » des personnes associées à ce rôle applicatif.

# 3.2.1.5.2.7. Classe ENTRelEleve

La classe ENTRelEleve hérite de la classe groupOfNames et ajoute les attributs relatifs à une relation entre un Élève et une Personne en relation avec l’élève. Ces attributs sont donnés dans le tableau ci-dessous.

L’attribut « member », hérité de groupOfNames, correspond aux « dn » d’un seul Eleve et d’une seule Personne en relation avec l’élève.

L’attribut « description », hérité de groupOfNames, qualifie la relation entre l’Eleve et la Personne en relation avec l’élève.

Remarque : Il est nécessaire de créer un groupe par relation que l’on veut représenter.

3.2.1.6. Classe relative aux applications

3.2.1.6.1. Classe ENTApplication

La classe ENTApplication hérite directement de la classe top et décrit les applications qui utilisent l’annuaire ENT. Ces applications peuvent reposer ou non sur le socle ENT. Les attributs sont donnés dans le tableau ci-dessous.

Les cellules en italique correspondent à des restrictions spécifiques à l’annuaire ENT sur les propriétés d’attributs. Ces contraintes d’intégrité devront être contrôlées par les services de gestion de contenu en plus de celles mentionnées au chapitre 3.3.

Tableau 26 : description des attributs LDAP pour la classe ENTApplication

La classe ENTApplication possède un identifiant et un mot de passe qui permettent à l’annuaire ENT d’authentifier l’application sur l’ENT.

3.2.2. DIT de l’annuaire ENT

3.2.2.1. Racine

La maîtrise d’ouvrage en charge du projet ENT indiquera la racine qu’il souhaite mettre en place pour l’annuaire ENT. La seule contrainte est de faire référence au nom du projet ENT dans la racine.

Exemple de racine possible pour le projet PRISME : « dc=prisme-lorraine, dc=net »

3.2.2.2. Arborescence

L’organisation retenue pour le DIT est une organisation à plat. Dans cette organisation, tous les objets de l’annuaire ENT sont classés dans des catégories directement rattachées à la racine.

Les catégories sont :

• personnes : liste des personnes, contient des objets des classes ENTPerson et ENTEleve ;
• structures : liste des structures, contient des objets des classes ENTEtablissement, ENTServAc, ENTCollLoc et ENTEntreprise ;
• groupes : liste des groupes, contient les objets des classes ENTClasse, ENTGroupe, ENTGroupementEtabs, ENTProfil, ENTRoleAppli et ENTRelEleve ;
• applications : liste des applications utilisant l’annuaire ENT, contient les objets de la classe ENTApplication.

Des contraintes applicatives, notamment par rapport aux services AAS, pourraient imposer d’utiliser des termes anglais pour les branches personnes (people) et groupes (groups). La maîtrise d’ouvrage en charge du projet ENT modifiera en conséquence le DIT de l’annuaire ENT ou laissera éventuellement cette liberté au soumissionnaire.

Figure 16 : DIT de l’annuaire ENT

Compte tenu du nombre de personnes au sein de l’ENT, les risques d’homonymie sont très présents. C’est pourquoi l’attribut « cn », tel qu’il est construit, ne pourra pas être utilisé comme RDN (Relative Distinguished Name) des personnes. Des précisions sont données au chapitre 4.3.4.2.1 « cn » des personnesErreur ! Source du renvoi introuvable..

Le soumissionnaire pourra proposer et justifier une organisation plus hiérarchique en précisant les impacts éventuels sur le schéma et notamment comment les personnes exerçant dans plusieurs établissements sont alors gérées). Il précisera également si des ACL sont positionnées sur certaines branches.

3.2.3. Attributs particuliers

3.2.3.1. Identifiant unique des personnes sur l’annuaire ENT

3.2.3.1.1. Dans le premier degré

Toute entrée appartenant une classe héritant de la classe ENTPerson possède un attribut « ENTPersonIdentifiant » qui représente l’identifiant interne à l’ENT de la personne et doit être unique sur le périmètre national.

3.2.3.1.2. Dans le second degré

Toute entrée appartenant à la classe inetOrgPerson ou à une classe qui en hérite possède un attribut « uid ». Cet attribut représente l’identifiant interne à l’ENT et doit être unique sur le périmètre national.

3.2.3.1.3. Format de l’identifiant unique

Un format d’identifiant unique qui ne permette pas d’être associé à l’identité de l’accédant doit être proposée. À défaut, la méthode suivante peut être utilisée :

Cet identifiant est de la forme « C₁xxC₂jjMMaahhmmsszzz » avec :

• C₁ et C₂ : lettre et chiffre associés au territoire du projet ENT ;
• xx : 2 lettres à générer pour chaque entrée ;
• jjMMaahhmmsszzz : 15 chiffres à générer pour chaque entrée à partir de la date de création du compte utilisateur à la milliseconde avec :

• jj : jour de création sur deux caractères,
• MM : mois de création sur deux caractères,
• aa : année de création sur deux caractères,
• hh : heure de création sur deux caractères (entre 00 et 23),
• mm : minute de création sur deux caractères,
• ss : seconde de création sur deux caractères,
• zzz : milliseconde de création sur trois caractères.

3.2.3.1.4. Service de génération de l’identifiant

Dans les cas où la méthode proposée ci-dessus serait retenue pour la génération de l’identifiant, un service de génération de l’identifiant serait à implémenter suivant les principes de fonctionnement suivants :

• respect du format présenté ;
• utilisation du code projet ENT pour les caractères C₁ et C₂ ;
• génération des caractères xx sur la base des attributs discriminants suivants :

• le nom d’usage,
• le prénom usuel (les attributs complémentaires suivants peuvent être utilisés pour résoudre les cas d’homonymie (deux personnes possédant les mêmes valeurs pour tous les attributs discriminants),
• les autres prénoms,
• le nom de famille (patronymique) ;

• utilisation de la date de création du compte à la milliseconde pour les caractères jjMMaahhmmsszzz (le projet ENT veillera au respect de ce principe également dans le cas d’une création des comptes par lots) ;
• renvoi de l’identifiant déjà généré si les mêmes attributs discriminants sont présentés.

Le projet ENT déterminera si l’identifiant d’un utilisateur supprimé peut être réutilisé, et si oui, au bout de combien de temps. Notons que la réutilisation d’un identifiant peut présenter un risque de confusion d’identité vis-à-vis d’un tiers).

3.2.3.1.5. Exemple de construction de l’identifiant unique

Dans les cas où la méthode proposée ci-dessus serait retenue pour la génération de l’identifiant, voici comment pourrait être construit l’identifiant unique pour la création d’un compte pour Paul MARTIN dans le département de l’Aisne le 01/09/2024 à 01:23:45.678 :

• C₁ et C₂ : la nomenclature nous indique que le département de l’Aisne est associé aux codes L = O et C = 3.
• xx : si la solution s’appuie sur la première lettre du prénom et la première lettre du nom, xx = pm.
• jjMMaahhmmsszzz : le compte est créé le 01/09/2024 à 01:23:45.678, jjMMaahhmmsszzz = 20240901012345678.

L’identifiant unique associé au compte est donc Opm320240901012345678.

3.2.3.2. Login

Toute entrée appartenant à une classe qui hérite de la classe ENTPerson possède un attribut « ENTPersonLogin » qui correspond à l’identifiant de connexion à l’ENT.

Cet identifiant de connexion doit être unique sur le périmètre de l’ENT. Cette unicité doit également prendre en compte les valeurs d’alias existants (cf. chapitre suivant).

3.2.3.2.1. Format du login

Le projet ENT pourra choisir parmi les propositions suivantes la règle de construction du login qu’il souhaite adopter :

• prenom.nomXX, où XX est un incrément garantissant l’unicité ;
• pnomXX, où XX est un incrément garantissant l’unicité ;
• autre proposition.

Remarque : dans le cas où le login se repose en partie sur le nom, il est conseillé de ne pas positionner le champ « ENTPersonLogin » comme attribut utilisé pour définir l’identifiant unique de l’utilisateur (son « dn » dans l’annuaire LDAP), afin de gérer plus facilement les changements de nom.

3.2.3.2.2. Service de génération du login

Selon le format de login choisi par le projet ENT, un service de génération du login peut être nécessaire (notamment en cas d’incrément garantissant l’unicité). Le projet ENT indiquera ici les principes de fonctionnement attendus pour ce service.

3.2.3.3. Alias

Le schéma LDAP proposé permet de créer un seul alias pour chaque utilisateur. Il devra être adapté si le projet ENT ne souhaite pas offrir cette fonctionnalité, ou souhaite que les utilisateurs disposent de plusieurs alias.

Toute entrée appartenant à la classe ENTPerson ou à une classe qui en hérite possède un attribut « ENTPersonAlias » qui correspond à un identifiant alternatif de connexion à l’ENT. Celui-ci peut donc être utilisé à la place de « ENTPersonLogin ».

L’alias offre aux utilisateurs la possibilité de choisir un identifiant de connexion plus facile à retenir que celui qui est fourni automatiquement. Pour les solutions ENT proposant une fonctionnalité de gestion des alias, les règles de création sont les suivantes :

• un alias donné est attribué à la première personne qui en fait la demande ;
• cet alias doit être unique sur le périmètre de l’ENT ;
• cette unicité doit également prendre en compte les valeurs des identifiants de connexion existants (cf. chapitre précédent).

Le dictionnaire de données proposé ne prend pas en compte cette fonctionnalité optionnelle.

3.2.3.4. Nom d’affichage des personnes

3.2.3.4.1. Dans le premier degré

Le nom d’affichage, correspondant à l’attribut « ENTPersonNomAffichage » de la classe ENTPerson, est construit comme suit :

• nom d’usage (en majuscules sans caractères diacritiques) ;
• suivi d’un espace ;
• suivi du prénom usuel (en minuscule, sauf la première lettre, et avec caractères diacritiques).

Les lettres entrelacées sont séparées et les traits d’union et les apostrophes sont remplacés par des espaces.

Exemple : DE LA FONTAINE Jean Pierre

Le projet ENT pourra éventuellement proposer une autre règle de construction du nom d’affichage.

3.2.3.4.2. Dans le second degré

# 3.2.3.4.2.1. « cn » des personnes

Le Common Name, ou « cn », des utilisateurs est construit comme suit :

• nom d’usage (en majuscules sans caractères diacritiques) ;
• suivi d’un espace ;
• suivi du prénom usuel (en minuscule, sauf la première lettre, et avec caractères diacritiques).

Les lettres entrelacées sont séparées et les traits d’union et les apostrophes sont remplacés par des espaces.

Exemple : DE LA FONTAINE Jean Pierre

Remarque : L’unicité d’un « cn » dans la branche people n’est pas garantie. Il ne sera donc pas utilisé dans la construction du « dn ».

# 3.2.3.4.2.2. Photographie

Toute entrée appartenant à la classe inetOrgPerson ou à une classe qui en hérite possède un attribut « jpegPhoto ». Cet attribut permet de stocker une photographie au format JPEG ; il n’est utilisé que pour certaines catégories de personnes.

Le stockage de ces photographies au sein de l’ENT représente un volume de données conséquent qui peut impacter fortement les performances de l’annuaire ENT.

Des indications volumétriques sont données au chapitre Erreur ! Source du renvoi introuvable.. À partir de ces informations, le soumissionnaire indiquera s’il est préférable de stocker les photographies dans l’annuaire ENT ou au sein d’un support de stockage externe.

Dans le deuxième cas, l’annuaire ENT ne conservera que le chemin permettant d’accéder au fichier.

Dans tous les cas, un contrôle sur la taille maximum des photographies sera nécessaire.

# 3.2.3.4.2.3. Construction du « dn »

Chaque entrée de l’annuaire est référencée de manière unique dans le DIT par son « dn » (Distinguished Name). Il s’agit du chemin d'accès à l’entrée depuis le sommet de l'arbre.

La construction du « dn » est la suivante :

• le « dn » des entrées représentant des personnes sera basé sur l’attribut « uid » ;
• le « dn » des entrées représentant des structures d’établissement sera basé sur l’attribut « ENTStructureUAI » ;
• le « dn » des entrées représentant les autres structures sera basé sur l’attribut « ENTStructureSIREN » ;
• le « dn » des entrées représentant des groupes sera basé sur l’attribut « cn » ;
• le « dn » des entrées représentant des applications sera basé sur l’attribut « ENTApplicationId ».

3.2.3.5. ENTPersonJointure et ENTStructureJointure (clés de jointure avec les sources autoritaires)

Afin d’assurer la correspondance entre les objets personnes et structures des sources autoritaires et ceux stockés dans l’annuaire ENT, il est nécessaire de disposer d’un identifiant commun jouant le rôle de clé de jointure.

Chaque source autoritaire fournit donc une clé de jointure persistante, qui permet d’identifier de manière unique chaque personne et chaque structure au fil des alimentations successives, et donc de suivre le cycle de vie des objets (modification des attributs et suppression). Cette clé de jointure doit notamment être pérenne d’une année scolaire sur l’autre.

Une même entrée personne ou structure dans l’annuaire ENT doit cependant disposer d’une clé de jointure pour chacune des sources autoritaires qui permettent d’alimenter un ou plusieurs de ses attributs.

Les clés de jointure sont stockées dans l’annuaire ENT grâce aux attributs multi-valués « ENTPersonJointure » (pour les personnes) et « ENTStructureJointure » (pour les structures). Ils sont construits comme suit :

• identifiant de la source autoritaire ;les identifiants sont les suivants :

• alimentation manuelle depuis l’ENT : identifiant = « ENT »,
• alimentation depuis le SI du MEN  :
  • Pour le premier degré : identifiant = « AC1D- » + nom de l’académie,
  • Pour le second degré : identifiant = « AC- » + nom de l’académie,
• autres sources d’alimentation :
  • identifiant librement défini par chaque projet ENT ;
  • identifiant librement défini par chaque projet ENT (par exemple, pour l’enseignement agricole, « EA- » + code académie ou code région) ;

• suivi du caractère « $ » ;
• suivi de la clé de jointure fournie par la source autoritaire pour désigner l’objet.

NB : Ce champ est distinct de l’identifiant unique des personnes sur l’annuaire ENT, défini au chapitre 4.3.1.

3.2.3.6. Identifiant unique de l’élève dans la structure de rattachement dans les bases de scolarité du MEN

Pour l'interfaçage avec certaines applications nationales sous responsabilité du MEN comme par exemple le livret scolaire au collège (livret scolaire du CP à la 3e) ou le livret scolaire du lycée (LSL), l’identifiant de l’élève dans les bases de scolarité SCONET (SIECLE) est nécessaire. Cet identifiant est unique sur un périmètre académique et est modifié quand l’élève change d’établissement.

Cet identifiant est fourni par le SI du MEN dans l’attribut ENTEleveStructureRattach et par le SI de l’enseignement agricole dans l’attribut ENTEleveStructureRattachIdMEN.

3.2.3.7. INE (Identifiant national élève)

L’INE de l’annuaire ENT est alimenté par le SI du MEN pour le premier degré et le second degré. L’INE de l’annuaire ENT est alimenté par le SI du MASA pour les élèves de l’enseignement agricole.

Cet INE est destiné exclusivement à une utilisation interne au périmètre de l'ENT par exemple :

• pour conserver les données lors du passage du premier degré au second degré ;
• lors d’un changement d’académie à l’intérieur d’un projet ENT ;

• pour l’interfaçage avec les services numériques pour l’éducation habilités qui nécessitent l’INE (afin de gérer l’unicité) ;

L’INE ne doit pas être utilisé en dehors de ces finalités.

3.2.3.8. GARPersonIdentifiant (identifiant GAR pour les personnes)

Afin de disposer d’une clé de jointure unique et pérenne entre les utilisateurs de l’ENT et le GAR, le projet ENT doit fournir un identifiant unique dédié au GAR, appelé GARPersonIdentifiant :

• pour les élèves, les enseignants, les enseignants documentalistes et autres personnels des écoles et établissements qui accèdent aux ressources depuis leur ENT (profils National_elv, National_ens, National_doc, National_evs, National_aca, …) ;
• pour les « responsables d’affectation » (utilisateurs chargés d’affecter les ressources aux élèves et enseignants).

Le GARPersonIdentifiant est transmis au GAR par le projet ENT lors du provisionnement des données du GAR conformément au Référentiel technique, fonctionnel et de sécurité du GAR (RTFS) à destination des éditeurs/intégrateurs ENT.

En cas de changement de solution ENT (par exemple en cas de renouvellement ou de changement de marché ENT), dans le cadre de la reprise de données liée à la réversibilité, cet identifiant doit faire partie de données à reprendre dans la nouvelle solution. La même contrainte s’applique en cas de changement de prestataire ENT ou de modification du périmètre du projet ENT, qu’il y ait un changement de solution ENT ou pas.

Divers aspects techniques sont à prendre en compte :

• Format de transmission :  l’UUID se présente et se transmet habituellement sous la forme de chaîne de 36 caractères (32 caractères hexadécimaux en 5 groupes séparés par des tirets), tel que c’est utilisé dans la RFC 4122, que ce soit en JSON ou en XML. S’il s’agit de transmettre ce type d’identifiant dans des services de type SOAP, le format de transmission devrait être aussi cette chaîne de caractères car le format UUID n’existe pas en tant que tel dans la spécification du protocole. Voici à titre d’exemple, à quoi pourrait ressembler la définition de l’UUID à transmettre dans JSON et XML :

• En JSON schema :

"uuid": {  
            "type": "string",  
            "pattern":
"^[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}$"  
        }

• En XML :

<s:simpleType name="guid">

<s:restriction base="s:string">

<s:pattern value="[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}"/>

</s:restriction>

</s:simpleType>

• Format de manipulation (dans le GAR, l’ENT ou autre système connexe) : compte tenu du fait que les principaux langages de programmation représentent souvent les UUID dans le format de chaîne de 36 caractères mentionné, il est conseillé d’utiliser ce format en interne dans les différents systèmes et dans la communication avec le GAR ;

• en Java, le résultat de l’appel à toString sur un objet de type UUID utilise le format mentionné ;
• en C#, il est possible d’obtenir un objet UUID directement à partir d’un String qui se trouve dans ce format de 36 caractères évoqué. En ce qui concerne l’affichage, la fonction ToString¹⁵ permet de produire un UUID au format mentionné à l’aide du spécificateur « D ».

• Format d’affichage (pour debug par exemple) : le format de 36 caractères est souvent jugé le plus adapté car plus facilement lisible pour les humains ;
• Format de stockage en base : au moment de stocker des UUID dans les bases de données, mis à part le stockage sous forme de variable de caractères (VARCHAR), des formats plus adaptés/optimisés peuvent être envisagés pour faciliter l’indexation, comme par exemple le type BINARY(16) dans MySQL ou un format équivalent. Pour information, sur MySQL 8, il y a les fonctions UUID_TO_BIN et BIN_TO_UUID pour transformer des UUID en chaîne de caractères et vice-versa.

3.2.3.9. Dates de scolarité

La date de scolarité demandée pour les interfaçages avec le livret scolaire du CP à la troisièm correspond à une date de la période pédagogique et une date où l'élève était scolarisé dans la classe. Cette précision est nécessaire lorsqu'un élève est arrivé dans la classe, ou a quitté la classe, en cours de période.

Cette information obligatoire (date-scolarite) permet de vérifier la cohérence avec les informations présentes dans les bases de scolarité (SIECLE et ONDE). En cas d’erreur sur cette date, l’import dans le LSU est rejeté.

Afin de de renseigner la date de scolarité des élèves, les attributs ENTEleveDateEntreeClasses et ENTEleveDateSortieClasses peuvent être utilisés par les éditeurs/intégrateurs ENT.

L’attribut ENTEleveDateEntreeClasses indique la (les) date(s) d’entrée dans la (les) division(s) de l'établissement de rattachement administratif de l’élève.

L’attribut ENTEleveDateSortieClasses indique la (les) date(s) de sortie de la (les) division(s) de l'établissement de rattachement administratif de l’élève.

3.3. Architecture technique de l’annuaire ENT

Plusieurs exigences et éléments de contexte ont servi à bâtir l’architecture technique de l’annuaire ENT :

• les besoins en termes d’usage de l’annuaire : mise à jour, gestion, authentification / autorisation, consultation ;
• la répartition géographique des sources d’alimentation, notamment celles du MEN ;
• le périmètre minimum couvert par un ENT (à savoir un département) ;
• la volumétrie attendue.

Sur la base de ces éléments, une solution d’architecture a été définie.

Cette solution peut être déclinée en trois options afin de garantir des niveaux de disponibilité et de partage de charge en adéquation avec les exigences de qualité de service.

Le soumissionnaire préconisera l’option la plus pertinente au regard de son offre technique et des éléments de volumétrie. Par défaut, l’option à retenir sera la première.

La maîtrise d’ouvrage en charge du projet ENT peut cependant choisir d’imposer une des options aux soumissionnaires.

3.3.1. Principes d’architecture

La solution d’architecture (Figure 17) repose sur la séparation de l’annuaire ENT en deux référentiels typés par usage :

• un référentiel pour les mises à jour, la gestion et la consultation d’informations ;
• un référentiel pour l’authentification et l’autorisation des utilisateurs.

Quelques éléments de justification :

• les performances du référentiel d’authentification et d’autorisation ne sont pas impactées par les requêtes de consultation et les accès en écriture lors des mises à jour ;
• cette séparation permet d’appliquer des procédures d’exploitation adaptées aux exigences de qualité de service de chacun des référentiels (plus fortes pour un référentiel d’authentification / autorisation que pour un référentiel de consultation).

La brique d’alimentation correspond au composant technique du service d’alimentation chargé de la mise à jour automatique de l’annuaire ENT. Les mises à jour depuis cette brique, ainsi que les mises à jour manuelles depuis l’IHM de gestion de contenu, sont réalisées sur le référentiel (1). Celui-ci traite également les requêtes de consultation, en provenance des applications.

Le référentiel (2) est dédié aux requêtes d’authentification et d’autorisation. Il est alimenté par réplication filtrée depuis le référentiel (1). Seuls les attributs utiles à la gestion des autorisations sont répliqués dans le référentiel (2).

3.3.1.1. Indexation de l’annuaire ENT

Afin d’améliorer le temps de réponse aux requêtes effectuées sur l’annuaire ENT, des index doivent être créés sur certains attributs.

Le référentiel de « mise à jour, gestion et consultation » et le référentiel « d’authentification / autorisation » pourront disposer d’index différents.

Il est notamment recommandé de créer des index sur les attributs suivants : « uid », « login », « alias », « ENTPersonStructRattach ».

3.3.2. Architecture – option 1

disponibilité sur la solution d’architecture présentée précédemment.

La haute-disponibilité repose sur la mise en place d’un référentiel (1’) de secours. Il s’agit d’une réplication totale du référentiel (1) de mise à jour et de consultation.

Les applications ne s’adressent qu’à un proxy LDAP (ou un commutateur de niveau 7/Applicatif) dont le rôle est de répartir les requêtes en fonction de leur type :

• les requêtes de consultation sont dirigées vers le référentiel (1) ;
• les requêtes d’authentification / autorisation sont dirigées vers le référentiel (2).

Remarque : Un proxy LDAP offre cependant des fonctions plus avancées permettant d’optimiser les performances (ex. : gestion de cache).

Si un des référentiels (1) ou (2) ne répond pas, le proxy LDAP (ou le commutateur de niveau 7) redirige les requêtes vers le référentiel (1’) de secours.

Remarques :

• si le référentiel (1) de mise à jour et de consultation est indisponible, il ne sera plus possible de mettre à jour l’annuaire ENT, que ce soit automatiquement ou via l’IHM de gestion de contenu ;
• si les référentiels (1) et (2) sont indisponibles en même temps, toutes les requêtes seront redirigées sur le même référentiel (1’) de secours, avec un risque de dégradation des performances.

3.3.3. Architecture – option 2

L’option 2 (Figure 19) complète l’option 1. La redirection des requêtes par un proxy LDAP (ou un commutateur niveau 7) est reprise. Cependant, cette option permet en plus d’assurer la haute-disponibilité pour les actes de mises à jour et de gestion via l’IHM de gestion de contenu.

L’IHM de gestion de contenu est redondée et les requêtes correspondantes passent désormais par le proxy LDAP (ou commutateur niveau 7). En fonctionnement nominal, ces requêtes sont dirigées vers le référentiel (1) de mise à jour et de consultation. Si celui-ci n’est pas disponible, elles sont alors redirigées vers le référentiel (1’) de secours.

Afin que les modifications apportées au référentiel (1’) de secours lors d’un dysfonctionnement soient prises en compte dans le référentiel (1), une réplication totale multi-maîtres est mise en place entre les référentiels (1) et (1’).

Remarques :

Si le référentiel (1) de mise à jour et de consultation est indisponible, il ne sera plus possible de mettre à jour l’annuaire ENT via la brique d’alimentation.

Les modifications apportées au référentiel (1’) lors d’un fonctionnement en mode secouru ne seront répercutées sur le référentiel (2) d’authentification / autorisation que lorsque le référentiel (1) sera de nouveau opérationnel.

3.3.4. Architecture – option 3

L’option 3 (Figure 20) généralise la haute-disponibilité à tous les composants de l’architecture et ajoute la répartition de charge. Elle est constituée des éléments suivants :

• deux référentiels de mise à jour, consultation et gestion : (1) et (1’), une réplication totale multi-maîtres étant mise en place entre ces deux référentiels ;
• deux référentiels d’authentification / autorisation : (2) et (2’), une réplication totale multi-maîtres étant mise en place entre ces deux référentiels ; ils sont alimentés par réplication filtrée, respectivement depuis les référentiels (1) et (1’) ;
• un commutateur niveau 7, secouru en Heartbeat, répartissant les requêtes de mise à jour / gestion, d’authentification / autorisation et de consultation sur deux proxy LDAP en fonction de leur charge ;
• chaque proxy LDAP n’est relié qu’à un seul référentiel de mise à jour, consultation et gestion ( (1) ou (1’) ) et un seul référentiel d’authentification / autorisation ( (2) ou (2’) ) ; le proxy redirige alors les requêtes vers le référentiel adéquat.

Les applications et l’IHM de gestion de contenu ne s’adressent qu’au commutateur.

Figure 20 : Architecture – Option 3

Remarque : Cette architecture pourrait permettre de localiser sur deux sites différents les référentiels (1)–(2) et (1’)–(2’).

3.4. Services de l’annuaire ENT

Cette partie décrit l’ensemble des services attendus pour l’annuaire ENT.

Le soumissionnaire détaillera, pour chaque fonctionnalité, le mode de fonctionnement de sa solution et les principes de mise en œuvre (prérequis, développements et paramétrages nécessaires…). Une distinction claire devra être effectuée entre les fonctionnalités natives (ne nécessitant qu’un paramétrage), les fonctionnalités à développer, et les fonctionnalités non prises en charge.

La maîtrise d’ouvrage en charge du projet ENT pourra, en fonction de ses besoins, ne pas faire figurer dans son cahier des charges certaines fonctionnalités présentées ci-après, ou a contrario ajouter certaines fonctionnalités manquantes.

Par ailleurs, elle précisera les éléments suivants : charte graphique et gabarit des IHM, cinématique et dynamique des pages.

3.4.1. Services de gestion

3.4.1.1. Services d’alimentation

[SRV-1] Alimentation depuis un fichier

Deux types d’alimentation par fichiers sont envisageables :

• alimentation depuis un fichier XML fourni par le MEN ou le ministère en charge de l’enseignement agricole ; le fichier XML fourni par le MEN ou le ministère en charge de l’enseignement agricole comporte les objets personnes et structures gérés respectivement par le MEN ou le ministère en charge de l’enseignement agricole ainsi que leurs caractéristiques ;
• alimentation depuis un fichier fourni par une autre source externe ; le soumissionnaire proposera a minima un connecteur permettant l’alimentation de l’annuaire ENT à partir de fichiers plats.

La maîtrise d’ouvrage en charge du projet ENT pourra éventuellement compléter ce chapitre avec les informations concernant les autres sources d’alimentation (par exemple SI de la collectivité locale ou SI du ministère en charge de l’enseignement agricole). Les fichiers en question pourront être de type XML, DSML, CSV, LDIF, etc.

Les services d’alimentation doivent :

• permettre de créer, modifier, et supprimer des personnes et des structures, et leurs attributs dans l’annuaire ENT, à partir des données fournies dans le fichier plat, en définissant des règles de synchronisation et de jointure ;
• permettre de définir les fréquences d’alimentation ;
• permettre de suspendre une alimentation à tout moment ;
• implémenter des mécanismes de contrôle du format des fichiers en entrée, de gestion des erreurs (reprises), de gestion des doublons, de vérification des règles de synchronisation, de vérification des contraintes d’intégrité définies au chapitre 3.3 ; les contraintes d’intégrité liées à une limite quantitative (exemple : nombre maximum d’élèves délégués par classe) devront être paramétrables ;
• implémenter des notifications d’alertes en cas d’erreur ou de non-respect de règles ou de contraintes ; ces alertes pourront être classées en différents niveaux. Selon le niveau d’alerte, le mécanisme d’alimentation pourra ou non être stoppé.

La maîtrise d’ouvrage en charge du projet ENT pourra préciser les niveaux d’alertes et les processus associés qu’elle souhaite mettre en œuvre, ou laisser à la discrétion du soumissionnaire le fait d’effectuer des propositions en ce sens.

Remarque : L’alimentation des mots de passe ne fait pas partie des fonctions attendues pour les services d’alimentation.

[SRV-2] Règles de gestion de l’alimentation

Les services d’alimentation doivent prendre en compte des règles de gestion de l’alimentation, et nomment :

• des règles de transformation de la casse des attributs alimentés ;
• des règles de construction des clés de jointure (cf. chapitre 4.3.5) ;
• des règles de répartition des objets alimentés entre les différentes catégories de personnes et de structures gérées au sein de l’annuaire ENT ;
• des règles de transformation des références (entre objets alimentés) en dn pointant vers des objets de l’annuaire ENT.

Les règles de gestion pourront être spécifiques à chaque source autoritaire. Les règles concernant l’alimentation depuis le SI du MEN ou du ministère en charge de l’enseignement agricole sont décrites dans le contrat d’interface AAF.

La maîtrise d’ouvrage en charge du projet ENT pourra compléter ce chapitre avec des règles de gestion complémentaires, notamment par rapport à d’autres sources d’alimentation que le SI du MEN ou le SI du ministère en charge de l’enseignement agricole.

[SRV-3] Réconciliation de

comptes utilisateurs

Les informations concernant une même personne physique peuvent provenir de différentes sources autoritaires, notamment lorsqu’une personne appartient à plusieurs catégories de personnes. Ainsi, les informations d’un parent d’élève travaillant pour une collectivité locale proviendront à la fois du SI du MEN et du SI de la collectivité.

Par ailleurs, pour une même source autoritaire, une même personne physique peut être vue comme deux objets différents, et donc être alimentée sous deux clés de jointure différentes, notamment lorsqu’un parent d’élève reçoit un compte associé à chacun de ses enfants identifiés dans l’ENT. Une réconciliation sera donc nécessaire également dans ce cas.

Deux types de réconciliation sont identifiés :

• le rapprochement de comptes : cette opération réconcilie deux comptes institutionnels de sources autoritaires différentes ou de deux comptes séparés d’une même source autoritaire. Les deux comptes restent actifs mais un seul, le compte principal, est utilisé pour accéder à l’ENT. L’autre compte, le compte principal, reste présent pour intégrer les mises à jour qui le concernent (au niveau de son entrée LDAP et de ses appartenances dans les groupes), venant des différentes sources autoritaires ;
• la fusion de comptes : cette opération intègre les informations venant d’un compte manuel temporaire dans un compte institutionnel. Une fois la fusion effectuée, le compte manuel est archivé.

Le service de réconciliation doit notamment contrôler l’exclusivité de la relation d’un compte identifié comme secondaire avec un compte principal. Autrement dit, un compte secondaire déjà réconcilié ne peut plus être rapproché avec un autre compte, tant que la relation de réconciliation existante est active, et tant que le compte principal est référencé au niveau de l’annuaire de l’ENT.

Afin que chaque personne physique puisse disposer d’un seul compte sur l’annuaire ENT (et donc d’un seul identifiant de connexion), les services d’alimentation doivent permettre de réconcilier les informations issues des différentes sources autoritaires. Cette réconciliation ne pourra se faire qu’à l’initiative de la personne concernée ou de l’administrateur de l’ENT.

Pour tout objet « Personne », le principe de réconciliation est le suivant :

• la personne se connecte à l’ENT à l’aide d’un de ses comptes, <compte1>, puis accède au service de réconciliation ;
• l’ENT demande à la personne :

• de saisir à nouveau le mot de passe de <compte1>,
• de saisir l’identifiant de connexion (login) et le mot de passe du ou des comptes qui doivent être réconciliés avec <compte1>,
• de choisir le compte de référence parmi <compte1> et les autres comptes. Ce compte de référence détermine :

• l’identifiant de connexion et le mot de passe qui seront utilisés pour les prochains accès à l’ENT,
• les informations qui seront conservées en cas de divergence entre les différentes sources (nom de famille orthographié différemment par exemple) ;

• après vérification des identifiants de connexion et des mots de passe, l’ENT :

• ajoute les informations provenant des différents comptes au compte de référence,
• conserve l’ensemble des clés de jointure,
• rappelle à la personne l’unique identifiant de connexion qui doit désormais être utilisé.

Au niveau de l’annuaire de l’ENT, le principe de réconciliation est le suivant :

• l’administrateur se connecte à l’ENT, puis accède au service de réconciliation ;
• l’ENT demande à l’administrateur :

• de saisir l’identifiant de connexion (login) du ,
• de saisir l’identifiant de connexion (login) du ou des comptes qui doivent être réconciliés avec ,
• de choisir le compte de référence parmi et les autres comptes. Ce compte de référence détermine :

• l’identifiant de connexion et le mot de passe qui seront utilisés pour les prochains accès à l’ENT,
• les informations qui seront conservées en cas de divergence entre les différentes sources (nom de famille orthographié différemment par exemple) ;

• après vérification des identifiants de connexion, l’ENT :

• ajoute les informations provenant des différents comptes au compte de référence,
• conserve l’ensemble des clés de jointure,
• notifie à la personne concernée l’unique identifiant de connexion qui doit désormais être utilisé.

Remarque : dans le cadre d’une fédération d’identités, même si l’opération de réconciliation est effectuée au niveau de l’outil de gestion des identités, cette réconciliation doit être répercutée vers l’annuaire ENT afin de mutualiser les informations des deux comptes au sein de l’ENT.

La maîtrise d’ouvrage en charge du projet ENT pourra préciser et détailler le modèle retenu pour la prise en compte des demandes de réconciliation (modèle synchrone ou modèle asynchrone), ainsi que les services mis en œuvre pour mutualiser les données venant des deux comptes rapprochés ou pour migrer les données du compte source vers le compte cible lors d’une fusion.

3.4.1.2. Services de gestion de contenu

[SRV-4] Environnement de gestion central et unique

Le service de gestion de contenu doit proposer un environnement de gestion central et unique donnant accès aux fonctions de gestion des entrées de l’annuaire ENT.

L’accès à l’environnement de gestion des entrées est réservé aux administrateurs centraux et locaux, et aux utilisateurs. Ils doivent se signer par la fourniture d’un couple « identifiant / mot de passe ».

[SRV-5] Gestion des personnes

et des structures

Le service de gestion de contenu doit permettre d’appliquer des opérations (création, modification, suppression) sur les personnes et les structures de l’annuaire ENT :

• gestion des d’entrées correspondant à des personnes :

• Création / suppression d’entrées,
• Modification des attributs d’une entrée,
• Ajout / suppression d’une catégorie à une personne ;

• gestion des d’entrées correspondant à des structures :

• Création / suppression d’entrées,
• Modification des attributs d’une entrée.

Le service de gestion de contenu doit notamment contrôler les contraintes d’intégrité mentionnées au chapitre 3.3 et permettre de gérer les multiples relations d’un élève avec des personnes en relation avec les élèves.

Ces différentes opérations seront par ailleurs implémentées en conformité avec les contraintes d’intégrité présentées aux chapitres 3.3.

Remarques :

• ces fonctions seront notamment utilisées pour compléter le peuplement de l’annuaire ENT avec les catégories de personnes et de structures qui ne sont pas alimentées automatiquement ;
• toute donnée issue de l’alimentation du MEN ou du ministère en charge de l’enseignement agricole n'est pas modifiable dans l'interface de gestion de contenu, à l’exception de certains attributs décrits dans le contrat d’interface AAF. Ces attributs sont en effet initialisés par l’alimentation MEN ou ministère en charge de l’enseignement agricole puis proposés en self-service (civilité pour les élèves par exemple).

[SRV-6] Gestion des nomenclatures

Le service de gestion de contenu doit offrir une fonction de gestion des nomenclatures. Ce service consiste en l’implémentation et en la gestion d’une table de nomenclature locale permettant d’associer chaque attribut ne disposant pas d’une nomenclature nationale à une nomenclature définie localement.

[SRV-7] Gestion des listes rouges

L’outil de gestion de contenu doit permettre de gérer des listes rouges d’utilisateurs.

Ces utilisateurs n’apparaîtront pas dans les pages blanches. Les informations sur ces utilisateurs serviront uniquement à déterminer leurs habilitations.

Remarque : Cette fonctionnalité sera notamment utilisée dans le cas d’élèves placés sous protection juridique.

[SRV-8] Gestion des groupes de personnes / groupes de structures

Cette fonction offre la possibilité de gérer des groupes de personnes (classes, groupes de langue…) et des groupes de structures (regroupement d’établissements…).

• création / suppression d’entrées ;
• modification de la liste des membres (ajout / suppression de membres).

Ces groupes peuvent être peuplés de trois manières :

• « Discrétionnaire » : le groupe est peuplé / dépeuplé manuellement par l’administrateur ;
• « Automatique » : le groupe est peuplé / dépeuplé automatiquement en fonction de règles de peuplement basées sur des combinaisons de valeurs des attributs des personnes ou structures ;
• « Mixte » : à la fois discrétionnaire et automatique.

Il est également possible de créer des groupes de groupes. Les objets peuplés peuvent être des groupes ou des personnes (ou structures). Le nombre de récursivité n’est pas limité.

[SRV-9] Gestion des profils applicatifs

Cette fonction offre la possibilité de gérer des profils applicatifs.

• création / suppression ;
• modification de la liste des membres (ajout / suppression de membres).

Ces profils peuvent être peuplés de trois manières :

• « Discrétionnaire » : le profil applicatif est peuplé / dépeuplé manuellement par l’administrateur ;
• « Automatique » : le profil applicatif est peuplé / dépeuplé automatiquement en fonction de règles de peuplement basées sur des combinaisons de valeurs des attributs des personnes ;
• « Mixte » : à la fois discrétionnaire et automatique.

Il est également possible de créer des profils applicatifs de profils applicatifs. Les objets peuplés peuvent être des groupes ou des personnes. Le nombre de récursivité n’est pas limité.

Un profil applicatif peut être exclusif. Une personne associée à un profil applicatif exclusif ne peut être associée à tout autre profil applicatif ou à certains profils applicatifs.

Un profil peut hériter d’un profil applicatif existant. L’ensemble des attributs du profil applicatif hérité est alors associé automatiquement au profil applicatif héritant, dont notamment la liste des personnes membres du profil applicatif et les rôles applicatifs associés.

[SRV-10] Gestion des rôles applicatifs

Cette fonction offre la possibilité de gérer des rôles applicatifs.

• création / suppression ;
• association à une ou plusieurs applications ;
• gestion de l’association à un ou plusieurs profils applicatifs.

Remarque : Une personne peut directement être associée à un rôle applicatif, soit de manière discrétionnaire, soit de manière automatique, sans l’intermédiaire d’un profil applicatif associé à ce rôle.

[SRV-11] Gestion des applications

Sur son périmètre d’administration, un administrateur peut créer, modifier, supprimer une application.

Une application peut être associée à zéro, un, ou plusieurs rôles applicatifs.

Remarque : Certains éléments caractérisant les applications sont liés aux services AAS implémentés, et ne sont pas intégrés à ce document (exemples : période d’accès, typologie d’accès, modes d’authentification...).

[SRV-12] Délégation des droits d’accès aux données de l’annuaire ENT

Des droits d’accès en lecture / écriture sont positionnés sur les objets et attributs de l’annuaire ENT.

Des périmètres distincts d’administration sont définis pour chaque administrateur (délégation ou répartition de l’administration des utilisateurs).

Les périmètres suivants peuvent être définis :

• des portées d’administration : objets et attributs de ces objets ;
• des actions d’administration sur ces portées :

• droits : lecture, création, modification, suppression de données,
• capacité à déléguer ces droits :

• à une ou plusieurs personnes (de manière discrétionnaire, par appartenance à un groupe…),
• sur une période donnée (date d’effet / date de fin),
• attribution de tout ou partie des droits dont on dispose,
• attribution de la capacité de déléguer tout ou partie de ces droits à d’autres personnes.

Des recouvrements de périmètres entre administrateurs sont possibles.

Un niveau hiérarchique est associé à chaque administrateur. Un administrateur de niveau n peut annuler toutes les actions réalisées par les administrateurs de niveau inférieur ou modifier toutes les données accessibles par les administrateurs de niveau inférieur.

Un administrateur peut ainsi définir les droits d’un utilisateur sur les attributs le caractérisant (lecture / écriture / capacité de délégation d’administration sur ses attributs).

Exemple d’implémentation : définitions

Ces différents services permettent par exemple de décliner l’organisation suivante, selon quatre niveaux : administrateur central, propriétaire, gestionnaire, utilisateur.

l’administrateur central a en charge la création et la gestion des objets transverses à l’ENT tels que les profils applicatifs partagés, et les rôles applicatifs et les applications transverses ;

les propriétaires possèdent les droits en écriture sur les objets de leur périmètre, et définissent pour chacun des attributs d’un type d’objet :

• les gestionnaires et leurs droits (lecture / écriture),
• la capacité à déléguer ces droits ;

les gestionnaires sont responsables de la gestion / mise à jour des objets / attributs ;

un utilisateur est un gestionnaire particulier, n’ayant des droits d’écriture et de capacité à déléguer un droit en lecture ou en écriture uniquement sur ses attributs.

[SRV-13] Délégation des droits d’accès sur les applications

Une personne, sous réserve qu’elle soit autorisée à le faire, doit pouvoir déléguer tout ou partie de ses droits d’accès à une ou plusieurs applications, et ce de manière temporaire.

Une délégation temporaire de droits se caractérise par :

• une liste de personnes à qui les droits (tout ou partie des droits possédés) sont délégués (liste discrétionnaire, liste basée sur un groupe de personnes ou sur un profil applicatif). ;
• une période donnée : une date d’effet et une date de fin de cette délégation pour chaque personne déléguée ;
• la capacité pour chaque personne déléguée de déléguer elle-même à d’autres personnes tout ou partie de ces droits.

[SRV-14] Gestion des suspensions

Le service de gestion offre la capacité de suspendre les personnes.

Lorsqu’une personne est suspendue, toutes ses caractéristiques sont conservées (attributs, liens…) mais la personne ne peut pas accéder aux applications de l’ENT.

Il est également possible de positionner pour toute personne une date d’activation et une date de fin de validité. En fonction de ces dates, des traitements de suspension ou de notification de suspension peuvent être lancés.

Il est possible de réactiver une personne suspendue.

[SRV-15] Import / export de fichiers

Le service de gestion de contenu doit permettre :

• d’importer un fichier afin de peupler l’annuaire ENT ;
• d’exporter dans un fichier des entrées sélectionnées.

Les formats de fichier devant être pris en charge sont les suivants : CSV, LDIF, XML.

[SRV-16] Outil de workflow

Les processus définis au chapitre 7 doivent être informatisés. Pour ce faire, les fonctions de workflow suivantes sont attendues :

• une interface graphique et simple d’utilisation permettant de créer et de gérer les workflows relatifs aux processus de l’ENT ;
• la capacité à gérer les fonctionnalités classiques de workflow : validation en série, en parallèle, escalade en cas de non traitement dans les délais impartis, champs à renseigner de façon obligatoire ou facultative pour valider une étape du workflow, envoi de notification par mail, envoi de mail prédéfini selon la ressource traitée, édition d’état papier…

[SRV-17] Changement de mot de passe

Le service de gestion de contenu doit permettre aux utilisateurs de modifier leur mot de passe. Cette action nécessite :

• de saisir l’ancien mot de passe ;
• de saisir et confirmer le nouveau mot de passe.

Les mots de passe ne doivent pas être stockés en clair. Ils devraient être stockés de manière chiffrée et irréversible, éventuellement sous forme d’empreintes numériques (cf. document [2]).

[SRV-18] Création / modification / suppression de l’alias

Un utilisateur peut se créer, s’il le souhaite, un alias de connexion l’ENT. Il ne peut disposer que d’un seul alias. La règle retenue pour la création des alias sur le périmètre de l’ENT est la suivante : « premier arrivé, premier servi ».

[SRV-19] Demande de modification de ses propres informations

Le service de gestion de contenu doit permettre à une personne de demander des modifications sur certains de ses attributs non accessibles en écriture : changement de coordonnées, erreur de saisie… via l’utilisation d’un workflow.

La fiche de l’utilisateur passe alors en mode « édition ». Les modifications ne sont pas inscrites dans l’annuaire ENT mais transmises à la personne définie dans le workflow.

3.4.2. Services d’accès

3.4.3. Services techniques

3.4.3.1. Services de sécurité

Ce chapitre présente les services de sécurité utilisés par les services AAS.

En fonction des services AAS retenus, la maîtrise d’ouvrage en charge du projet ENT pourra étendre la couverture fonctionnelle de ces services. En effet, seuls les services fondamentaux d’authentification et d’autorisation sont demandés par la suite.

Au regard des services demandés, le soumissionnaire indiquera les extensions de schéma LDAP nécessaires et les éventuels impacts sur l’architecture technique.

[SRV-20] Gestion de l’authentification

Lors de l’accès d’une personne à une application de l’ENT, les services AAS vérifient au travers d’une requête d’authentification la validité du couple « identifiant de connexion / mot de passe » dans l’annuaire ENT.

• paramètres d’entrée : identifiant de connexion / mot de passe ;
• paramètres de sortie : OK / NOK.

Remarque : L’utilisation d’un alias de connexion est possible.

[SRV-21] Gestion du multi-rôles

Une personne, lorsqu’elle souhaite accéder à une application pour laquelle elle possède plusieurs « rôles », peut choisir, lors de la phase d’authentification, avec quel rôle elle se connecte. Elle retrouve alors uniquement l’environnement applicatif et les droits associés au rôle choisi.

Remarque : Cette fonction peut nécessiter l’utilisation du service de réconciliation de comptes.

[SRV-22] Gestion de l’autorisation

Lors de l’accès d’une personne à une application de l’ENT, les services AAS vérifie au travers d’une requête d’autorisation si la personne est autorisée à accéder à l’application demandée.

Le contrôle d’autorisation sur une application peut être réalisé sur la valeur d’un attribut de la personne, sur l’appartenance de la personne à un profil applicatif, sur l’appartenance de la personne à un rôle applicatif. Il ne peut se baser que sur un sous-ensemble défini des objets et attributs de l’annuaire ENT.

Aussi, plusieurs types de requête sont envisageables :

• Requête autorisation de type 1 :
  • paramètres d’entrée : identifiant de connexion de la personne / identifiant d’attribut / valeur d’attribut ;
  • paramètres de sortie : OK / NOK.

• Requête autorisation de type 2 :
  • paramètres d’entrée : identifiant de connexion de la personne / identifiant de profil applicatif ;
  • paramètres de sortie : OK / NOK.

• Requête autorisation de type 3 :
  • paramètres d’entrée : identifiant de connexion de la personne / identifiant de rôle applicatif ;
  • paramètres de sortie : OK / NOK.

• Requête autorisation de type 4 :
  • paramètres d’entrée : identifiant de connexion de la personne ;
  • paramètres de sortie : liste des profils applicatifs associés à la personne.

• Requête autorisation de type 5 :
  • paramètres d’entrée : identifiant de connexion de la personne ;
  • paramètres de sortie : liste des rôles applicatifs associés à la personne.

3.4.3.2. Services de publication

[SRV-23] Publication pour les applications

Les applications de l’ENT, en cohérence avec leurs droits d’accès aux données de l’annuaire ENT, peuvent interroger l’annuaire ENT pour récupérer tout ou partie des caractéristiques d’une personne, d’une structure, la liste des membres d’un profil applicatif…

[SRV-24] Pages Blanches

Une personne peut consulter les fiches des autres personnes de l’ENT. Ces fiches pourraient comporter les zones suivantes afin d’organiser les informations :

• informations civiles ;
• coordonnées personnelles ;
• coordonnées professionnelles ;
• informations administratives ;
• scolarité ;
• divers.

En fonction de ses droits, une personne ne pourra consulter que certaines informations sur les fiches des autres personnes.

Lorsque les attributs des fiches font référence à des entrées de l’annuaire ENT (des personnes, des structures, des classes, des groupes…), des liens hypertextes doivent permettent d’accéder aux fiches correspondant à ces entrées.

[SRV-25] Pages Jaunes

Une personne peut consulter les fiches des structures gérées par l’ENT. Ces fiches pourraient comporter les zones suivantes afin d’organiser les informations :

• informations légales ;
• coordonnées géographiques ;
• coordonnées du standard ;
• divers.

Remarque : Toutes les informations des fiches des structures sont consultables librement par toutes les personnes de l’ENT.

Le service de consultation doit également permettre d’accéder aux fiches correspondant aux différents groupes de l’annuaire ENT (classes, groupes, regroupements d’établissements…) afin d’obtenir la liste des membres de ces groupes.

[SRV-26] Navigation

Les Pages Blanches doivent proposer une navigation arborescente avec affichage sur la zone principale de l’IHM de la fiche sélectionnée. Les arborescences suivantes doivent être proposées a minima :

• par établissement, puis par catégorie de personnes, puis par ordre alphabétique ;
• pour un établissement, par catégorie de personnes, puis par ordre alphabétique ;
• par structure (établissement, services académiques, collectivité locale), puis par catégorie de personnes (consolidation).

[SRV-27] Recherche

La recherche constitue une fonctionnalité particulièrement importante du service de gestion de contenu. Ce dernier doit en effet permettre à la fois une recherche très ciblée et une recherche beaucoup plus générale.

Les recherches peuvent porter sur les différents attributs des catégories de personnes et notamment le nom, le prénom, la structure de rattachement, le niveau scolaire…

Pour les attributs dont la nomenclature définit une liste fermée, l’interface doit proposer des listes de choix en plus d’un champ libre.

L’outil doit permettre l’utilisation d’expressions logiques pour constituer des requêtes de recherche.

Des requêtes « standard » doivent également être proposées aux utilisateurs. La liste ci-dessous donne quelques exemples de requêtes qui pourraient être proposées :

• rechercher toutes les personnes de la catégorie <liste de catégories> dans l’établissement <liste d’établissements> ;
• rechercher toutes les personnes de la catégorie <liste de catégories> liées à la classe/groupe <liste des classes/groupes> ;
• rechercher tous les <catégorie de personnes> dans l’établissement <liste d’établissements> ;
• rechercher tous les enseignants [respectivement les élèves] qui enseignent [respectivement qui suivent] l’enseignement <liste d’enseignements> ;
• rechercher toutes les personnes qui exercent la fonction ou le domaine <liste de fonctions/domaines>.

Le résultat de la recherche doit être présenté sous forme de tableau ou de liste. Un lien doit permettre de consulter la fiche correspondant à chacune des entrées retournées en résultat de la recherche.

La notion de « panier » doit être implémentée par l’outil de gestion de

contenu. Ce terme désigne la capacité à conserver des entrées du

résultat d’une requête pour effectuer des actions postérieures (exemples

envoi d’e-mail ou impression de chacune des fiches correspondantes…).

[SRV-28] Édition

Il est possible d’exporter une fiche, le résultat d’une recherche ou toutes les fiches issues d’une recherche dans un fichier, en précisant notamment :

• les fiches à exporter par rapport au résultat d’une recherche (quelles personnes, quelles structures) ;
• les attributs à exporter pour chaque fiche.

Les formats de fichier devant être pris en charge sont les suivants : PDF, CSV.

[SRV-29] Impression

Une fiche « Personne », une fiche « Structure », le résultat d’une recherche ou toutes les fiches issues d’une recherche peuvent être imprimées.

3.4.4. API de service

[SRV-1] API de service

L’ensemble des services présentés précédemment doivent être accessibles via des API développées en C ou JAVA.

[SRV-2] Couche de services

En option, le soumissionnaire pourra proposer la réalisation d’une couche de services permettant de rendre les applications indépendantes du modèle de données de l’annuaire ENT, limitant ainsi les impacts en cas d’évolution de celui-ci.

Il devra choisir une méthode d’implémentation de la couche de services (de préférence basée sur une architecture « Web Services » à l’aide des techniques SOAP / WSDL / UDDI) et fournir un schéma d’architecture technique expliquant la mise en place de cette couche de services.

3.5. Organisation et processus types de gestion de l’annuaire ENT

L’objectif de cette partie est de donner aux soumissionnaires une vision détaillée des processus pressentis pour l’annuaire ENT. La solution proposée devra être capable de gérer ces processus et d’intégrer de manière simple (paramétrage et interface graphique) de nouveaux processus du même type et leur déclinaison en workflow.

3.5.1. Organisation type de la gestion des droits d’accès

3.5.1.1. 4 .5.1.1. Acteurs

L’organisation de la gestion des droits d’accès aux données de l’annuaire ENT peut reposer sur les acteurs présentés ci-dessous.

3.5.1.1.1. Administrateur central

L’administrateur central de l’annuaire ENT a accès en écriture sur les objets de type « profil applicatif partagé », « rôle applicatif » et « application » transverses à l’ENT.

Il est ainsi en charge de la création de ces objets et de leur mise à jour.

3.5.1.1.2. Propriétaires et gestionnaires locaux

Le chef d’établissement est le propriétaire de l’ensemble des données sur son périmètre de responsabilité. Les populations concernées correspondent à l’ensemble des personnes rattachées administrativement à l’établissement ou exerçant une fonction dans l’établissement.

Ainsi, le chef d’établissement possède un accès en écriture sur les objets de type « personne », « structure », « profil applicatif local à l’établissement », « rôle applicatif local à l’établissement », « application locale à l’établissement », et peut notamment inscrire une personne dans un profil applicatif.

Il peut déléguer tout ou partie de ses droits sur ces données à des gestionnaires locaux (par exemple, les personnels administratifs).

3.5.1.1.3. Définition des droits d’accès

Les principes de gestion des droits d’accès aux données de l’annuaire ENT respectivement pour le MEN et pour le ministère en charge de l’enseignement agricole doivent être définis en tenant compte des principes du RGPD et de loi relative à l’Informatique, aux fichiers et aux libertés modifiée. Pour plus de détails, se reporter au service mutualisé « Gestion d’identités et d’accès » du document principal.

3.5.2. Processus type de gestion

3.5.2.1. Gestion des personnes

3.5.2.1.1. Inscription d’une personne

Plusieurs modes d’inscription d’une personne dans l’annuaire ENT peuvent être envisagés.

Inscription automatique

La création d’une personne dans l’annuaire ENT est réalisée automatiquement depuis les sources d’alimentation. Si une entrée est identifiée comme nouvelle dans la source alors qu’elle est déjà présente dans l’annuaire ENT, une anomalie est déclenchée.

Inscription manuelle par la structure de rattachement

Pour les catégories de personnes qui ne sont pas alimentées automatiquement, la création est réalisée manuellement dans l’annuaire ENT via l’interface de gestion de contenu prévue à cet effet. Cette alimentation manuelle est réalisée par le propriétaire ou par un gestionnaire délégué, en charge de l’établissement de rattachement administratif de la personne à créer.

Inscription individuelle

L’inscription individuelle consiste en une demande engagée par la personne auprès d’un gestionnaire de l’établissement ou du propriétaire, au travers d’un workflow où la personne renseigne les informations nécessaires à sa création dans l’annuaire ENT. Une fois ces informations validées par le gestionnaire, la personne est créée dans l’annuaire.

Quel que soit le mode d’inscription, l’activation du compte est réalisée à la première connexion de la personne, sous réserve de son acceptation explicite.

3.5.2.1.2. Suppression d’une personne

La maîtrise d’ouvrage en charge du projet ENT doit préciser les actions à effectuer lorsqu’une personne est supprimée du référentiel source. Ces actions peuvent dépendre des catégories de personnes concernées.

Exemples : suppression directe de l’entrée, suspension de l’entrée et suppression automatique au bout d’une durée déterminée, conservation de l’entrée pendant quelques mois puis suppression (permet aux utilisateurs de disposer des ressources pendant quelques mois supplémentaires, notamment afin de récupérer leurs données).

3.5.2.1.3. Modification d’une personne

Les modifications des attributs d’une personne suivent les modes d’inscription envisageables pour la personne, à savoir une modification automatique via l’alimentation depuis des référentiels externes, une modification manuelle sur demande de l’utilisateur et réalisée soit directement par lui-même, soit par le gestionnaire, ou une modification manuelle réalisée directement par le gestionnaire.

3.5.2.2. Gestion des structures

3.5.2.2.1. Ajout d’une structure

La création d’une structure est réalisée automatiquement pour toutes les nouvelles entrées des sources d’alimentation autoritaires.

Pour les catégories de structures qui ne sont pas alimentées automatiquement, la création est réalisée manuellement dans l’annuaire ENT via l’interface prévue à cet effet. Cette alimentation manuelle pourra être réalisée par le propriétaire ou un gestionnaire délégué.

3.5.2.2.2. Suppression d’une structure

Le projet ENT doit préciser ici les actions à effectuer lorsqu’une structure est supprimée d’un référentiel source. Ces actions peuvent dépendre des catégories de structures concernées.

Exemples : suppression directe de l’entrée, suspension de l’entrée et suppression automatique au bout d’une durée déterminée, conservation de l’entrée pendant quelques mois puis suppression (permet aux utilisateurs de cette structure de disposer des ressources pendant quelques mois supplémentaires, notamment afin de récupérer leurs données).

3.5.2.3. Gestion des profils applicatifs

3.5.2.3.1. Ajout d’un profil

La création des profils applicatifs est réalisée manuellement dans l’annuaire ENT via l’interface prévue à cet effet.

Un propriétaire ou un gestionnaire délégué peut uniquement créer des profils applicatifs locaux sur son périmètre de responsabilité.

L’administrateur central de l’annuaire ENT peut créer des profils applicatifs partagés, dont la portée sera transverse à tout l’ENT.

Remarque : L’ajout d’un profil applicatif partagé n’a de sens que s’il est réellement partagé pour tous les établissements d’un projet ENT.

3.5.2.3.2. Suppression d’un profil applicatif

La suppression des profils applicatifs est réalisée manuellement dans l’annuaire ENT via l’interface prévue à cet effet.

Un propriétaire ou un gestionnaire délégué peut uniquement supprimer des profils applicatifs locaux à son périmètre de responsabilité.

L’administrateur central de l’annuaire ENT peut supprimer des profils applicatifs partagés, dont la portée est transverse à tout l’ENT.

3.5.2.3.3. Peuplement / dépeuplement manuel d’un profil

Le peuplement des profils applicatifs est réalisé manuellement dans l’annuaire ENT via l’interface prévue à cet effet.

Un propriétaire ou un gestionnaire délégué peut uniquement peupler un profil applicatif avec des personnes appartenant à son périmètre de responsabilité. Il pourra peupler tout profil applicatif partagé et tout profil applicatif local à son périmètre de responsabilité.

Le dépeuplement d’un profil applicatif suit les mêmes règles que le peuplement.

3.5.2.4. Gestion des applications et des rôles applicatifs

3.5.2.4.1. Ajout d’une application ou d’un rôle applicatif

La création d’une application ou d’un rôle applicatif est réalisée manuellement dans l’annuaire ENT via l’interface prévue à cet effet.

Un propriétaire ou un gestionnaire délégué peut uniquement créer des applications et des rôles applicatifs locaux sur son périmètre de responsabilité.

L’administrateur central de l’annuaire ENT peut créer des applications et des rôles applicatifs transverses à tout l’ENT.

3.5.2.4.2. Suppression d’une application ou d’un rôle applicatif

La suppression d’une application ou d’un rôle applicatif est réalisée manuellement dans l’annuaire ENT via l’interface prévue à cet effet

Un propriétaire ou un gestionnaire délégué peut uniquement supprimer des applications et des rôles applicatifs locaux à son périmètre de responsabilité.

L’administrateur central de l’annuaire ENT peut supprimer des applications ou des rôles applicatifs transverses à tout l’ENT.

Remarque : La suppression d’une application entraîne la suppression de tous les rôles applicatifs associés à cette application, si le rôle applicatif est uniquement associé à cette application. Dans le cas contraire, seule la référence de cette application est supprimée au niveau du rôle applicatif (attribut « owner »).

3.5.2.4.3. Peuplement / dépeuplement manuel d’un rôle applicatif

Le peuplement d’un rôle applicatif est réalisé manuellement dans l’annuaire ENT via l’interface prévue à cet effet.

Un propriétaire ou un gestionnaire délégué peut uniquement peupler un rôle applicatif avec des personnes ou des profils applicatifs appartenant à son périmètre de responsabilité. Il pourra peupler tout rôle applicatif associé à une application transverse ou locale à son périmètre de responsabilité.

Le dépeuplement d’un rôle applicatif suit les mêmes règles que le peuplement.

4. Gestion des droits sur les données

Un certain nombre d’attributs ne sont pas gérés dans le contrat d’interface AAF. Ces attributs sont décrits dans le fichier « Caractérisation des personnes et des structures », disponible ci-après :[lien de téléchargement du fichier "personnesStructures_2D à insérer]

Les attributs concernés sont ceux pour lesquels la source d’alimentation indiquée est « self-service » ou « vide ». Ils concernent les catégories suivantes :

• ENTEleve – Attributs : Elève de l'enseignement secondaire
• ENTAuxPersRelEleve – attributs : Personne exerçant l'autorité parentale, hébergeur, responsable financier, correspondant en cas d'urgence, etc.
• ENTAuxEnseignant – attributs : Personnel de l'éducation nationale ou de l'enseignement agricole exerçant une activité pédagogique devant des élèves
• ENTAuxNonEnsEtabAttributs : Personnel de l'éducation nationale ou de l'enseignement agricole exerçant une activité pédagogique devant des élèves

Les autres attributs sont décrits dans le contrat d’interface AAF.