Historique des versions

Version Date Rédacteur Description

1.0.0

18/06/2026

Équipe Technique

Version initiale

1.1.0

11/10/2026

Équipe Technique

Mise à jour d’ensemble. Les cas d’utilisation, les règles de gestion et les scénarios de recette sont alignés sur le comportement attendu de la solution. Les schémas de données, les vues d’exécution et les diagrammes de séquence sont repris sur le modèle et les échanges livrés. Le dictionnaire des données est ramené aux tables structurantes, le modèle complet étant porté en annexe. Les documents sont mis en cohérence entre eux sur les statuts, les rôles, les interfaces et les nomenclatures.

Diffusion

Destinataires Pour validation Pour information

COPIL

X

Validation

Représentants Valideur Date

DCE

MND

ASIN

MESRS - DSI

UNIVERSITÉS - DSI

DSI Présidence

1. Introduction

1.1. Contexte et problématique métier

Les données de l’enseignement supérieur au Bénin sont dispersées dans plusieurs systèmes d’information indépendants :

  • MESRS : Établissements, programmes, accréditations (dispose de son propre SI)

  • UPB (Universités Publiques du Bénin) : Enseignants, étudiants, programmes (chaque université dispose de son propre SI)

  • EPES (Établissements Privés d’Enseignement Supérieur) : Données des établissements privés (chaque établissement dispose de son propre SI)

  • MTFP (Ministère du Travail et de la Fonction Publique) : Données RH des enseignants titulaires (dispose de son propre SI)

Problèmes identifiés :

  • Saisie multiple des mêmes données dans différents systèmes

  • Incohérences entre les sources (doublons, données obsolètes, formats différents)

  • Absence de source unique de vérité pour les données référentielles

  • Difficulté à produire des statistiques fiables sur l’enseignement supérieur

  • Impossibilité de partager les données de manière sécurisée entre administrations

Solution proposée :

La plateforme bdes-referentiel collecte, consolide et expose les données référentielles de l’enseignement supérieur via la plateforme nationale d’interopérabilité X-ROAD. Chaque source conserve son propre système d’information et transmet ses données au référentiel.

1.2. Objectifs du projet

1.2.1. Objectif 1 : Constituer un référentiel de données consolidé

Modéliser et réaliser la base de données relationnelles permettant le référentiel des données de l’enseignement supérieur au Bénin, en consolidant les données issues de sources multiples et disparates (MESRS, UPB, EPES, MTFP).

1.2.2. Objectif 2 : Assurer l’interopérabilité via X-ROAD

Mettre en place des mécanismes d’échanges d’information de type API avec d’autres systèmes (universitaires et gouvernementaux) via la plateforme nationale d’interopérabilité X-ROAD.

1.2.3. Objectif 3 : Permettre la migration des données existantes

Transférer les données des systèmes existants vers le nouveau référentiel, et réaliser l’import en masse des données de systèmes externes

1.3. Périmètre

1.3.1. In-Scope (Inclus)

Le référentiel bdes-referentiel consolide les données suivantes :

  • Établissements : Universités publiques (UPB), établissements privés (EPES)

  • UFR : Unités de Formation et de Recherche et leurs départements

  • Programmes académiques : Licences, Masters, Doctorats avec leurs UE et EC

  • Enseignants et chercheurs : Corps enseignant avec qualifications, spécialités, affectations

  • Acteurs de l’administration : Recteurs, vice-recteurs, doyens, vice-doyens, directeurs, secrétaires généraux, etc.

  • Grades et diplômes : Habilitations, titres universitaires

  • Programmation des cours : Planification des enseignements

Deux natures de données relèvent également du périmètre du référentiel :

Nature Contenu attendu

Étudiants

Inscriptions, parcours académiques, diplômes obtenus

Accréditations

Habilitations de programmes, certifications institutionnelles

1.3.2. Out-of-Scope (Exclus)

Les éléments suivants sont explicitement hors périmètre :

  • Gestion de la paie et des carrières (géré par MTFP/DRH/MEF)

  • Processus d’évaluation des enseignants (géré par bdes-evaluation)

  • Gestion financière et comptable détaillée (systèmes comptables)

  • Gestion des notes et bulletins étudiants (systèmes de scolarité)

  • Gestion des emplois du temps en temps réel (établissements)

  • Gestion de contenu pédagogique (LMS/plateformes e-learning)

  • Gestion bibliothécaire détaillée (SIG des bibliothèques)

1.4. Glossaire et terminologie métier

Terme Définition

Accréditation

Habilitation officielle délivrée à un établissement ou un programme académique pour délivrer des diplômes reconnus.

ANIP

Agence Nationale d’Identification des Personnes. Organisme béninois gérant le système national d’identification (NIP).

Déduplication

Processus de détection et résolution des doublons entre différentes sources de données.

Données consolidées

Données enrichies, dédupliquées et validées, constituant la source unique de vérité.

Données sources

Données brutes provenant des sources autoritaires avant consolidation.

EC (Élément Constitutif)

Composante d’une Unité d’Enseignement (UE). Plusieurs EC forment une UE complète.

EPES

Établissements Privés d’Enseignement Supérieur. Établissements agréés par le MESRS.

Grade académique

Titre universitaire officiel : Licence, Master, Doctorat, Agrégation, Professeur Titulaire, etc.

Historisation

Conservation de l’évolution temporelle complète des données avec versioning.

MESRS

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique. Source autoritaire pour les établissements et programmes.

MTFP

Ministère du Travail et de la Fonction Publique. Source autoritaire pour les données RH des enseignants titulaires.

NIP

Numéro d’Identification Personnel. Identifiant unique national délivré par l’ANIP.

Programme académique

Parcours de formation structuré menant à un diplôme : Licence, Master, Doctorat.

Source autoritaire

Système d’information officiel faisant autorité pour un domaine de données. Chaque source (universités, MESRS, MTFP) conserve son propre SI et transmet ses données au référentiel pour consolidation.

Suppression logique

Archivage sans suppression physique des données, permettant la traçabilité.

UE (Unité d’Enseignement)

Module d’enseignement dans un programme académique, composé de plusieurs EC.

UFR

Unité de Formation et de Recherche. Division académique d’une université.

UPB

Universités Publiques du Bénin (UAC, UP, UNA, UNSTIM, etc.).

X-ROAD

Plateforme nationale d’interopérabilité béninoise (XROADBJ) pour l’échange sécurisé de données entre administrations.

X-ROAD Consumer

Système qui consomme des services exposés via X-ROAD : administrations et systèmes gouvernementaux.

X-ROAD Provider

Système qui expose des services via X-ROAD. bdes-referentiel est provider.

2. Parties prenantes et Utilisateurs

Cette section présente les attentes spécifiques des parties prenantes vis-à-vis du module bdes-referentiel.

2.1. Attentes clés par groupe

2.1.1. Décideurs (MESRS, DCE, MND)

  • Visibilité sur les indicateurs de l’enseignement supérieur

  • Données fiables pour le pilotage des politiques publiques

  • Conformité aux standards nationaux d’interopérabilité

2.1.2. Sources autoritaires (UPB, EPES, MTFP)

  • Processus d’alimentation simple et documenté

  • Feedback sur la qualité des données fournies

  • Accès aux données consolidées pour vérification

2.1.3. Consommateurs (bdes-evaluation, autres SI)

  • API stables et documentées

  • Temps de réponse acceptables (< 3 secondes)

  • Haute disponibilité (>= 99.5%)

  • Authentification sécurisée

2.1.4. Opérationnels (Admin Référentiel, IT-NUM)

  • Interface d’administration ergonomique

  • Outils de détection et résolution des doublons

  • Tableaux de bord de qualité des données

  • Documentation technique complète

2.1.5. Bénéficiaires indirects (Enseignants, Étudiants)

  • Exactitude des données personnelles

  • Droit de consultation et de rectification

  • Confidentialité des informations sensibles

3. Vue d’ensemble fonctionnelle

3.1. Diagramme de contexte

Le système bdes-referentiel interagit avec son environnement externe comme illustré ci-dessous.

sfd ref context global
Figure 1. Diagramme de contexte

Le système vu comme une "boîte noire" :

  • Entrées : Données des sources autoritaires (MESRS, UPB, EPES, MTFP)

  • Sorties : Données consolidées exposées via X-ROAD

  • Acteurs : Administrateurs, consommateurs API, systèmes externes

3.2. Cartographie des processus métier impactés

3.2.1. Processus AVANT (situation actuelle)

Processus Description actuelle Problèmes

Collecte des données

Saisie manuelle depuis chaque système source (MESRS, UPB, EPES)

Doublons, incohérences, délais

Consolidation

Aucune - chaque système est isolé

Pas de vision unifiée

Partage inter-administrations

Échanges par email ou fichiers Excel

Non sécurisé, non traçable

Reporting statistique

Agrégation manuelle depuis plusieurs sources

Données non fiables, chronophage

3.2.2. Processus APRÈS (avec bdes-referentiel)

Processus Description Bénéfices

Collecte des données

Alimentation automatisée par API ; dépôt de fichier pour les maquettes et les planifications

Rapidité, traçabilité, validation

Consolidation

Déduplication automatique et consolidation des données

Source unique de vérité

Partage inter-administrations

Exposition sécurisée via X-ROAD

Sécurisé, auditable, temps réel

Reporting statistique

Tableaux de bord automatisés

Données fiables, temps réel

3.3. Flux de valeur principaux

3.3.1. Flux 1 : Alimentation du référentiel

Ce flux décrit le parcours d’une donnée depuis sa source jusqu’à sa consolidation.

Acteurs : Sources autoritaires (UPB, EPES, MESRS, MTFP), Système Référentiel

Étapes :

  1. La source transmet les données (par API, par dépôt de fichier pour les maquettes et les planifications, ou par synchronisation automatisée)

  2. Le système valide les données (format, cohérence, complétude)

  3. Le système détecte les doublons potentiels

  4. Les doublons simples sont résolus automatiquement

  5. Les doublons complexes sont marqués pour résolution manuelle

  6. La donnée consolidée est créée

  7. L’historique de la modification est enregistré

sfd ref p traitement commun

3.3.2. Flux 2 : Résolution des doublons

Ce flux décrit le processus de résolution manuelle des doublons complexes.

Acteurs : Système Référentiel, Administrateur Référentiel

Étapes :

  1. Le système détecte un doublon potentiel avec score de similarité

  2. Le doublon est ajouté à la file d’attente de résolution

  3. L’administrateur consulte la liste des doublons à traiter

  4. L’administrateur compare les enregistrements côte-à-côte

  5. L’administrateur décide : fusionner, marquer comme distinct, ou rejeter

  6. L’enregistrement consolidé est mis à jour en conséquence

  7. L’action est tracée dans l’historique

sfd ref sp resolution manuelle

3.3.3. Flux 3 : Consultation via X-ROAD

Ce flux décrit comment un système consommateur accède aux données consolidées.

Acteurs : Système consommateur (ex: bdes-evaluation), X-ROAD Security Server, Système Référentiel

Étapes :

  1. Le consommateur s’authentifie via X-ROAD

  2. Le consommateur envoie une requête de consultation

  3. X-ROAD Security Server vérifie les autorisations

  4. Le système référentiel traite la requête

  5. Les données consolidées sont retournées au consommateur

  6. L’appel est tracé dans les logs d’audit

sfd ref sequence consultation xroad

3.4. Options d’alimentation

Le système supporte trois modes d’alimentation, par ordre de priorité :

3.4.1. Option 1 : API exposées pour alimentation PUSH

  • Le système bdes-referentiel expose des API REST

  • Les sources (UPB, EPES, MESRS) appellent ces API pour alimenter

  • Validation immédiate et feedback en temps réel

  • Avantages : Temps réel, traçabilité complète, pas de fichiers intermédiaires

3.4.2. Option 2 : Dépôt de fichier pour les maquettes et les planifications

  • Le responsable académique dépose un fichier Excel au modèle fourni

  • Ce dépôt ne couvre que deux natures de données : les maquettes — unités d’enseignement et éléments constitutifs — et les planifications des enseignements. Les structures, les personnes, les formations et les nomenclatures s’alimentent par l’option 1

  • Import par lot avec validation automatique

  • Rapport d’import avec les succès et les lignes en erreur

  • Avantages : Simple, adapté à une saisie qui relève de l’établissement

3.4.3. Option 3 : Synchronisation PULL automatique

  • Le système se connecte aux API des sources

  • Synchronisation automatique programmée (cron)

  • Prérequis : Les sources doivent exposer des API REST. Les universités n’en exposent pas, ce qui situe cette option après les deux précédentes.

4. Description détaillée des fonctionnalités

4.1. Traitement des cas d’utilisation

Cas Intitulé Traitement

UC-01

Alimenter le référentiel par le service d’intégration

REPRIS

UC-02

Importer une maquette ou une planification par fichier

REPRIS

UC-03

Résoudre un doublon de fiche personne

REPRIS

UC-04

Consulter les données via X-ROAD

INCHANGÉ

UC-05

Corriger une donnée rejetée à l’intégration

NOUVEAU

UC-06

Revendiquer sa fiche personne

NOUVEAU

UC-07

Consulter les nomenclatures

NOUVEAU

UC-08

Consulter la hiérarchie des structures

NOUVEAU

UC-09

Consulter les formations et leurs maquettes

NOUVEAU

UC-10

Faire évoluer une maquette d’une année sur l’autre

NOUVEAU

UC-11

Déterminer le périmètre d’un responsable académique

NOUVEAU

UC-12

Tenir le calendrier académique

NOUVEAU
La colonne Traitement dit comment ce chapitre traite chaque cas d’utilisation. INCHANGÉ : repris sans modification. REPRIS : la description a été précisée. NOUVEAU : exigence spécifiée ici pour la première fois.

4.2. Cas d’utilisation principaux

4.2.1. UC-01 : Alimenter le référentiel par le service d’intégration

Acteur principal : Source autoritaire (UPB, EPES, MESRS, MTFP)

L’alimentation est séparée par nature de données — données de référence, structures académiques, personnes, planification des enseignements — chacune disposant de son point d’entrée et de son habilitation propre. Une source n’obtient que les habilitations des natures qu’elle alimente.

Préconditions :

  • La source est authentifiée et porte l’habilitation de la nature de données concernée

  • Les données respectent le format attendu

Scénario nominal :

  1. La source transmet un lot de données à l’un des points d’entrée d’alimentation

  2. Le système conserve le lot reçu dans son intégralité, à des fins de traçabilité

  3. Le système prépare les données : il contrôle leur forme et les rapproche des données déjà consolidées

  4. Le système consolide les données préparées : il crée, met à jour ou retire les enregistrements de référence

  5. Le système rend un compte rendu portant l’identifiant du lot, son statut, et le dénombrement des lignes traitées, insérées, mises à jour, ignorées et en erreur, détaillé par nature d’entité

Postconditions :

  • Le lot reçu est conservé et consultable

  • L’origine de chaque donnée consolidée est tracée

Scénarios alternatifs :

  • 3a. Données invalides : Le système retourne une erreur détaillant les champs fautifs, et le lot n’est pas consolidé

  • 4a. Ligne rejetée : La ligne porte son motif de rejet et reste disponible pour correction (UC-05) ; les autres lignes du lot sont consolidées. Un conflit avec une donnée existante produit un rejet de même nature, et non une mise à l’écart silencieuse

  • 4b. Ligne intégrée avec réserve : Une ligne peut être consolidée tout en portant un avertissement — par exemple lorsqu’une partie de ses créneaux a été ignorée pour chevauchement. Elle ne figure pas parmi les rejets

  • 4c. Donnée inexploitable : Une valeur que le système ne sait pas exploiter — libellé trop court, purement numérique, ou valant « néant » — fait l’objet d’un rejet portant son motif et son contenu d’origine, et reste corrigeable

4.2.2. UC-02 : Importer une maquette ou une planification par fichier

Acteur principal : Responsable académique

Acteurs secondaires : Administrateur

Deux natures de données seulement s’importent par fichier : la maquette des unités d’enseignement et des éléments constitutifs, et la planification des enseignements. Le fichier est converti puis emprunte le même chemin d’intégration que les autres alimentations (UC-01).

Préconditions :

  • L’acteur est habilité sur les structures concernées (UC-11)

  • Le fichier respecte le modèle téléchargeable

Scénario nominal :

  1. L’acteur télécharge le modèle, pré-rempli pour son périmètre

  2. L’acteur complète le modèle et le dépose

  3. Le système convertit le fichier et le soumet au chemin d’intégration

  4. Le système rend le même compte rendu que pour une alimentation directe (UC-01)

Postconditions :

  • Les lignes acceptées sont consolidées ; les lignes rejetées restent disponibles pour correction

Scénarios alternatifs :

  • 2a. Donnée hors périmètre : Le système refuse le dépôt dès la première ligne portant une structure hors du périmètre de l’acteur

  • 3a. Cellule illisible : Une cellule saisie hors du format attendu par le modèle n’est pas lue ; la ligne est rejetée avec son motif

4.2.3. UC-03 : Résoudre un doublon de fiche personne

La fusion n’est exerçable que depuis un écran présentant les deux fiches et le report projeté, et demandant une confirmation. Une résolution complémentaire passe par le traitement des rejets (UC-05), qui permet de trancher avant qu’un doublon ne se constitue.

Acteur principal : Administrateur

Le système cherche d’abord à éviter le doublon plutôt qu’à le résoudre. Pour une fiche à matricule provisoire, il rapproche par le nom normalisé ; si plusieurs fiches portent le même nom, il tente de les départager par l’établissement de rattachement. S’il n’y parvient pas, il refuse de trancher : la ligne est rejetée avec le motif « doublon potentiel » et attend une décision humaine (UC-05). Le présent cas d’utilisation traite les doublons déjà constitués.

Préconditions :

  • Deux fiches désignent la même personne

Scénario nominal :

  1. L’acteur identifie la fiche à conserver et celle à résorber

  2. L’acteur demande la fusion de la seconde vers la première

  3. Le système reporte sur la fiche conservée les spécialités, affectations, coordonnées, adresses et pièces d’identité de la fiche résorbée, sans créer de doublon

  4. Le système retire la fiche résorbée

Postconditions :

  • La fiche résorbée n’est plus visible ; la fiche conservée porte l’ensemble des rattachements

Scénarios alternatifs :

  • 1a. Doublon détecté à la revendication : Lorsqu’un matricule ou un identifiant national est déjà porté par une autre fiche, le système refuse le rattachement et désigne la fiche en conflit (UC-06)

  • 1b. Doublon signalé à l’intégration : La ligne rejetée pour « doublon potentiel » est traitée depuis l’écran des rejets, qui propose soit de créer une fiche distincte s’il s’agit d’une autre personne, soit d’écarter la ligne s’il s’agit d’un doublon (UC-05)

4.2.4. UC-04 : Consulter les données via X-ROAD

Acteur principal : Système consommateur (ex: bdes-evaluation)

Préconditions :

  • Le système consommateur dispose d’un certificat X-ROAD valide

  • Le système consommateur est autorisé à accéder aux données demandées

Scénario nominal :

  1. Le consommateur envoie une requête X-ROAD avec critères de recherche

  2. Le X-ROAD Security Server vérifie l’authentification et les autorisations

  3. Le système référentiel traite la requête

  4. Le système retourne les données consolidées correspondantes

  5. Le consommateur reçoit les données

Scénarios alternatifs :

  • 2a. Non autorisé : X-ROAD retourne une erreur d’accès refusé

  • 3a. Aucun résultat : Le système retourne une liste vide

4.2.5. UC-05 : Corriger une donnée rejetée à l’intégration

Acteur principal : Administrateur

Acteurs secondaires : Délégué DCE

Préconditions :

  • Une alimentation a produit des lignes rejetées

Scénario nominal :

  1. L’acteur consulte les lignes rejetées, filtrables par nature d’entité

  2. L’acteur ouvre une ligne et prend connaissance de son motif de rejet

  3. L’acteur corrige les données fautives ; la correction est datée, porte l’identité de son auteur et une note

  4. L’acteur relance l’intégration de la ligne

  5. Le système consolide la ligne corrigée

Postconditions :

  • La ligne disparaît de la liste des rejets

Scénarios alternatifs :

  • 3a. Champ non corrigeable : Seules les données réellement portées par la ligne préparée peuvent être modifiées

  • 4a. Relance groupée : L’acteur relance plusieurs lignes en une fois

  • 4b. Mise à l’écart : L’acteur écarte une ligne qui ne doit pas être intégrée ; elle cesse d’apparaître parmi les rejets sans être consolidée

  • 2a. Doublon potentiel : Lorsque le rejet signale des homonymes que le système n’a pas su départager, l’acteur tranche. S’il s’agit d’une autre personne, il demande la création forcée : le rapprochement automatique est alors écarté et une fiche distincte est créée. S’il s’agit d’un doublon, il écarte la ligne

  • 5a. Rejet persistant : La ligne corrigée est de nouveau rejetée et porte son nouveau motif

4.2.6. UC-06 : Revendiquer sa fiche personne

Acteur principal : Utilisateur nouvellement inscrit

Acteurs secondaires : Administrateur

Tant qu’une fiche n’est pas revendiquée, elle n’est rattachée à aucun compte. La revendication est ce qui relie un compte de la plateforme à l’identité qu’il désigne dans le référentiel.

Préconditions :

  • L’utilisateur dispose d’un compte

  • La fiche recherchée n’est rattachée à aucun autre compte

Scénario nominal :

  1. L’utilisateur recherche sa fiche par son nom ; le système n’expose que les fiches non rattachées et exige au moins trois caractères

  2. L’utilisateur désigne sa fiche et fournit les éléments qui l’identifient

  3. Le système vérifie la concordance de ces éléments avec la fiche

  4. Le système rattache la fiche au compte

Postconditions :

  • L’utilisateur accède aux données de sa fiche et à ce qui en dépend

  • La fiche n’est plus revendicable par un autre compte

Scénarios alternatifs :

  • 3a. Identifiant national mal formé : Le système refuse ; l’identifiant comporte dix chiffres

  • 3b. Matricule discordant : Lorsque la fiche porte un matricule définitif, celui fourni doit correspondre

  • 3c. Fiche déjà rattachée au même compte : Le système confirme sans rien modifier

  • 3d. Fiche déjà rattachée à un autre compte : Le système refuse

  • 3e. Matricule ou identifiant national déjà porté ailleurs : Le système refuse et désigne la fiche en conflit (UC-03)

  • 1a. Aucune fiche trouvée : L’utilisateur déclare son profil ; le système crée une fiche par le chemin d’intégration et la rattache

  • 4a. Rattachement erroné : Un administrateur délie la fiche, qui redevient revendicable ; l’opération est exercée depuis un écran désignant la fiche et le compte à délier

4.2.7. UC-07 : Consulter les nomenclatures

Acteur principal : Système consommateur

Les nomenclatures — grades, corps, statuts, mentions, types de diplôme, natures de structure, modalités d’évaluation, semestres, années académiques et autres listes de référence — sont servies en lecture seule et s’alimentent par le chemin d’intégration (UC-01). Elles alimentent les listes de choix des écrans, et quatre d’entre elles sont consultables depuis l’écran de rattachement des formulaires à un profil d’enseignant.

Préconditions :

  • L’appelant porte l’habilitation de lecture du référentiel

Scénario nominal :

  1. L’appelant demande une nomenclature, en totalité ou par identifiant

  2. Le système rend les valeurs en vigueur

Scénarios alternatifs :

  • 2a. Valeur retirée : Une valeur retirée ne figure plus dans la nomenclature, mais reste rendue sur les données qui la portaient, signalée comme retirée

4.2.8. UC-08 : Consulter la hiérarchie des structures

Acteur principal : Système consommateur ou utilisateur habilité

Préconditions :

  • L’appelant porte l’habilitation de lecture du référentiel

Scénario nominal :

  1. L’appelant demande les structures, éventuellement filtrées par leur nature

  2. Le système rend les structures et leur rattachement à leur structure parente

  3. L’appelant demande les structures filles d’une structure, ou remonte la chaîne de ses structures parentes

Postconditions :

  • Chaque structure est désignée par son code, stable dans le temps

Scénarios alternatifs :

  • 2a. Période de validité : Une structure porte ses dates d’ouverture et de fermeture ainsi que, le cas échéant, son motif de fermeture ; ces informations figurent sur l’écran de la structure

4.2.9. UC-09 : Consulter les formations et leurs maquettes

Acteur principal : Système consommateur ou utilisateur habilité

Préconditions :

  • L’appelant porte l’habilitation de lecture du référentiel

Scénario nominal :

  1. L’appelant recherche une formation par son intitulé ou son code

  2. Le système rend la formation, son diplôme et la structure qui l’habilite à le délivrer

  3. L’appelant demande la maquette de la formation pour une année académique

  4. Le système rend les unités d’enseignement et leurs éléments constitutifs

Postconditions :

  • La maquette rendue est celle dont la période de validité couvre l’année demandée

4.2.10. UC-10 : Faire évoluer une maquette d’une année sur l’autre

Acteur principal : Source autoritaire ou responsable académique, par le chemin d’intégration

La maquette d’une formation évolue par une opération de versionnement portée par le chemin d’intégration, et non par écriture directe : la période en vigueur est close et une nouvelle période s’ouvre, les rattachements étant repris.

Préconditions :

  • Une maquette est en vigueur pour la formation

Scénario nominal :

  1. L’alimentation porte l’indication de versionnement sur la formation concernée

  2. Le système clôt la période de validité en vigueur

  3. Le système ouvre une nouvelle période et y reprend les rattachements de la précédente

  4. Les évolutions portées par l’alimentation s’appliquent à la nouvelle période

Postconditions :

  • Les périodes de validité d’une même formation ne se recouvrent jamais

  • La maquette de l’année précédente reste consultable

Scénarios alternatifs :

  • 1a. Maquette d’une année antérieure : Le système refuse de modifier une maquette dont la période a commencé avant l’année en cours

4.2.11. UC-11 : Déterminer le périmètre d’un responsable académique

Acteur principal : Système

Le périmètre ne découle pas d’un rôle applicatif mais d’une affectation de fonction active sur une structure. Lire l’ensemble des données et pouvoir y écrire sont deux portées distinctes : la première n’emporte jamais la seconde.
Le référentiel n’authentifie pas l’utilisateur final : il reçoit son identité et ses ouvertures de portée du service d’évaluation, qui les a résolues depuis le jeton. Le contexte ainsi transmis doit être vérifiable par le référentiel et non simplement déclaré, et la qualité d’administrateur ne peut être portée par un paramètre d’appel. Tout point d’entrée consommant ce contexte est réservé au compte de service ; en ouvrir un sous une autre habilitation serait une régression de sécurité.

Préconditions :

  • L’appelant est identifié par son matricule ou son identifiant national

Scénario nominal :

  1. Le système résout l’identité de l’appelant

  2. Le système recherche ses affectations de fonction actives ouvrant droit à la planification

  3. Le système en déduit les structures sur lesquelles il peut écrire

  4. Toute écriture portant sur une structure hors de ce périmètre est refusée

Postconditions :

  • Le périmètre est recalculé à chaque demande, jamais conservé

Scénarios alternatifs :

  • 2a. Aucune affectation ouvrant droit : L’acteur ne peut écrire sur aucune structure

  • 3a. Lecture globale : Certains acteurs consultent l’ensemble des données sans pour autant pouvoir y écrire

  • 3b. Administration : L’administrateur n’est borné par aucun périmètre

4.2.12. UC-12 : Tenir le calendrier académique

Acteur principal : Délégué DCE ou Administrateur

Préconditions :

  • L’année académique est connue du référentiel

Scénario nominal :

  1. L’acteur déclare les jours fériés de l’année

  2. L’acteur déclare les périodes non enseignées

  3. L’acteur fixe les dates de début et de fin de chaque semestre

Postconditions :

  • Le calendrier est consultable par les acteurs qui en dépendent pour planifier

Le responsable académique consulte le calendrier, dont il a besoin pour planifier les enseignements, sans pouvoir le modifier.

4.3. Règles de gestion

4.3.1. RG0 - Règles Transversales

ID Règle de Gestion

RG0.1

Toute création, mise à jour ou suppression est historisée avec sa date, sa version et son auteur. L’auteur d’une correction, d’une mise à l’écart ou d’une création forcée est l’identité portée par le jeton de l’appel ; aucun champ de la requête ne peut la désigner ni la remplacer

RG0.2

Les données de référence se suppriment par désactivation et restent consultables ; les tables de rattachement entre deux données sont, elles, réécrites à chaque consolidation

RG0.3

Une donnée consolidée provient de sa source. Une donnée que la source ne fournit pas reste vide : la consolidation n’y substitue aucune valeur par défaut

RG0.4

Une alimentation portant une donnée déjà consolidée met cette donnée à jour. Le compte rendu ne porte en « mises à jour » que les lignes ayant effectivement modifié une donnée consolidée

RG0.5

L’autorité sur une donnée appartient à sa source : le référentiel ne soumet aucune mise à jour à une validation par un tiers

RG0.6

La continuité d’une année sur l’autre est assurée par les périodes de validité, qui conservent l’état antérieur sans l’archiver ni le déplacer

RG0.7

Les informations sensibles (revenus, financement, évaluations) sont accessibles uniquement selon les rôles définis

4.3.2. RG1 - Référentiel des Établissements

ID Règle de Gestion

RG1.1

Chaque établissement doit être identifié par un code unique (code MESRS)

RG1.2

Les établissements sont catégorisés par type (université, école, institut, centre)

RG1.3

Les informations minimales incluent : nom, sigle, adresse, statut juridique (public/privé)

RG1.4

Un établissement ne peut être supprimé s’il est lié à des enseignants, étudiants ou programmes actifs

4.3.3. RG2 - Référentiel des Programmes Académiques

ID Règle de Gestion

RG2.1

Chaque programme académique est rattaché à un établissement

RG2.2

Les informations minimales incluent : intitulé, diplôme délivré, durée, modalités

RG2.3

Un programme peut avoir plusieurs parcours ou spécialités

RG2.4

L’archivage est obligatoire pour les programmes fermés (pas de suppression)

4.3.4. RG3 - Référentiel des Unités d’Enseignement (UE)

ID Règle de Gestion

RG3.1

Chaque UE appartient à un programme académique

RG3.2

Les informations minimales incluent : code UE, intitulé, crédits ECTS

RG3.3

Une UE peut être mutualisée entre plusieurs programmes

RG3.4

Les UE archivées doivent rester accessibles pour la traçabilité académique

4.3.5. RG4 - Référentiel des Enseignants

ID Règle de Gestion

RG4.1

Chaque enseignant doit être identifié par un matricule unique

RG4.2

Les informations minimales incluent : nom, prénom, grade, spécialité

RG4.3

L’affectation d’un enseignant est liée à un établissement principal

RG4.4

Un enseignant ne peut être supprimé s’il est lié à des enseignements planifiés, à une fonction administrative, à un rôle ou à un autre enseignant

4.3.6. RG5 - Référentiel des Étudiants

ID Règle de Gestion

RG5.1

Chaque étudiant est identifié par un matricule unique

RG5.2

Les informations minimales incluent : nom, prénom, date de naissance, nationalité

RG5.3

L’inscription de l’étudiant doit être liée à un programme et une année académique

RG5.4

Un étudiant ne peut être supprimé s’il a des inscriptions, notes ou diplômes validés

4.3.7. RG14 - Règles de Qualité des Données

ID Règle de Gestion

RG14.1

Un enregistrement ne peut être marqué comme VALIDE que si tous les champs obligatoires sont renseignés

RG14.2

La qualité d’une donnée consolidée tient à celle de sa source

RG14.3

La dernière valeur non vide reçue fait foi

4.3.8. RG16 - Règles de Déduplication

ID Règle de Gestion

RG16.1

Le rapprochement des personnes s’appuie sur le matricule, puis sur l’identifiant national. Au-delà de ces deux clés, aucun rapprochement n’est acquis sans décision humaine : la ligne est rejetée pour arbitrage

RG16.2

Les doublons détectés doivent être présentés pour résolution avec suggestion automatique

RG16.3

Après déduplication, un et un seul enregistrement consolidé doit être créé avec traçabilité vers tous les enregistrements sources fusionnés
Règle d’arbitrage entre sources. La consolidation retient la dernière valeur non vide reçue. Les règles ci-dessous précisent ce que cela implique pour la qualité, la fiabilité et le niveau de confiance des sources.

4.3.9. RG6 - Alimentation et intégration des données

ID Règle de Gestion

RG6.1

L’alimentation est séparée par nature de données — référence, structures académiques, personnes, planification — chacune disposant de son habilitation propre

RG6.2

Le lot reçu est conservé dans son intégralité, indépendamment du sort de chacune de ses lignes

RG6.3

L’intégration se fait en deux temps : préparation des données reçues, puis consolidation vers les données de référence

RG6.4

Une ligne de préparation porte l’un des états suivants : en attente, en cours, intégrée, en erreur, écartée. L’état « écartée » n’est jamais produit par l’intégration : il résulte d’une décision humaine prise lors du traitement des rejets (UC-05)

RG6.5

Une ligne intégrée peut porter un message d’avertissement : la présence d’un message ne signifie pas que la ligne a été rejetée, et une ligne intégrée ne l’a pas nécessairement été dans son intégralité

RG6.6

Le rejet d’une ligne ne fait pas échouer le lot : les autres lignes sont consolidées et la ligne rejetée conserve son motif. Toute ligne ou valeur non consolidée est portée dans les rejets avec son motif et son contenu d’origine ; aucun écart n’est rendu par un seul compteur

RG6.7

Le compte rendu rendu à la source dénombre les lignes traitées, insérées, mises à jour, écartées et en erreur, détaillées par nature d’entité

RG6.8

L’issue d’un lot est conservée avec le lot — abouti, partiel ou en erreur — avec le dénombrement des lignes par état. Le compte rendu rendu à la source et la trace durable portent la même issue

RG6.9

L’origine de chaque donnée consolidée est tracée : pour chaque champ, la source dont la valeur a été retenue et la date de sa prise en compte

RG6.10

Chaque source porte un niveau de confiance, enregistré avec la configuration de la source ; la dernière alimentation reçue fait foi

RG6.11

L’état d’une année académique ne se change pas par alimentation : sa clôture est une décision, non la conséquence d’un fichier

RG6.12

La donnée consolidée ne se corrige pas directement : elle se corrige en rejouant son alimentation ou depuis l’écran des rejets. Toute donnée consolidée doit rester corrigeable par au moins un chemin exerçable

4.3.10. RG7 - Identité des personnes et revendication

ID Règle de Gestion

RG7.1

Une fiche personne est identifiée par son matricule ; l’identifiant national et le compte rattaché sont également uniques

RG7.2

Une fiche n’est rattachée qu’à un seul compte, et un compte ne revendique qu’une fiche non encore rattachée

RG7.3

La revendication exige la concordance des éléments d’identité fournis avec ceux de la fiche ; l’identifiant national comporte dix chiffres

RG7.4

Une revendication déjà acquise est confirmée sans effet, de sorte qu’elle peut être rejouée sans risque

RG7.5

Le rattachement erroné d’une fiche peut être défait ; la fiche redevient alors revendicable

RG7.6

Une personne sans matricule définitif reçoit un matricule provisoire. Le passage au matricule définitif ne se fait pas de lui-même : il suppose une fusion de fiches (UC-03)

RG7.7

Le rapprochement automatique d’une fiche à matricule provisoire se fait par le nom normalisé, puis, en cas d’homonymie, par l’établissement de rattachement

RG7.8

Lorsque le système ne parvient pas à départager des homonymes, il ne crée pas de fiche et ne rapproche pas : il rejette la ligne pour décision humaine. Aucun doublon n’est créé par défaut

RG7.9

Seule une décision humaine explicite — la création forcée — conduit à créer une fiche malgré un homonyme détecté ; cette décision est tracée

RG7.10

La fusion de deux fiches reporte sur la fiche conservée les rattachements de la fiche résorbée, sans jamais créer de doublon

4.3.11. RG8 - Validité dans le temps

ID Règle de Gestion

RG8.1

Une structure porte une période de validité et, lorsqu’elle est fermée, le motif de sa fermeture

RG8.2

La maquette d’une formation porte une période de validité exprimée en années académiques, dont la fin reste ouverte tant que la maquette est en vigueur

RG8.3

Deux périodes de validité d’une même formation ne se recouvrent jamais

RG8.4

Faire évoluer une maquette clôt la période en vigueur et en ouvre une nouvelle, en y reprenant les rattachements de la précédente

RG8.5

Une maquette dont la période a commencé avant l’année en cours n’est plus modifiable

RG8.6

La maquette d’une formation ne se modifie que par le chemin d’intégration ; aucun point d’entrée d’écriture directe ne l’expose

4.3.12. RG9 - Périmètres et habilitations

ID Règle de Gestion

RG9.1

Le périmètre d’écriture d’un responsable académique découle de ses affectations de fonction actives, et non d’un rôle applicatif

RG9.2

Seules certaines fonctions de direction d’unité de formation ouvrent droit à la planification

RG9.3

Une affectation échue n’ouvre plus aucun droit

RG9.4

Consulter l’ensemble des données et pouvoir y écrire sont deux portées distinctes : la première n’emporte jamais la seconde

RG9.5

Le périmètre est recalculé à chaque demande, à partir de l’identité que le service appelant transmet. Le référentiel ne vérifie pas cette identité : il fait confiance au service d’évaluation, qui l’a résolue depuis le jeton de l’utilisateur. Cette confiance est la frontière de sécurité du dispositif

RG9.6

Un dépôt est refusé dès la première donnée portant une structure hors du périmètre de son auteur

RG9.7

Les échanges entre services passent par un compte de service, porteur d’habilitations qui ne sont jamais accordées à un utilisateur

4.3.13. RG10 - Suppression et conservation

ID Règle de Gestion

RG10.1

Les données de référence sont supprimées par marquage et restent consultables. Les tables de rattachement — spécialités d’une personne, supports et modalités d’un élément constitutif — font exception : leur contenu est effacé puis réécrit à chaque consolidation

RG10.2

Le retrait d’une valeur n’altère pas la lecture des données qui la portaient : la valeur retirée reste rendue sur ces données, signalée comme retirée. Aucune lecture n’échoue du fait d’un retrait

RG10.3

Une donnée ne peut être supprimée tant qu’elle porte des données filles encore actives

RG10.4

Le retrait d’une donnée ne peut être demandé par l’alimentation que pour les unités d’enseignement et les éléments constitutifs. Il emprunte un chemin propre, distinct de celui d’une création, et n’en subit pas les contrôles

4.4. Critères d’acceptation

Une fonctionnalité est considérée terminée lorsque :

  • Code développé et revu

  • Tests unitaires passent avec couverture >= 80%

  • Tests fonctionnels passent

  • Documentation mise à jour (si applicable)

  • Validation COPIL obtenue

  • Déployé en environnement de recette et testé

5. Modèle de données métier

5.1. Principe de consolidation des données

Le référentiel distingue deux niveaux de données :

  • Données sources : Données brutes telles que fournies par les sources autoritaires (MESRS, UPB, EPES, MTFP)

  • Données consolidées : Données enrichies, dédupliquées et validées, constituant la source unique de vérité

5.1.1. Entités gérées par le référentiel

Entité Description

Accréditation

Habilitation officielle d’un établissement ou programme

Diplôme

Titre académique délivré à un étudiant

Élément Constitutif (EC)

Composante d’une UE

Enseignant

Personnel enseignant ou chercheur avec ses qualifications et affectations

Établissement

Université publique ou établissement privé d’enseignement supérieur

Étudiant

Étudiant inscrit avec son parcours académique

Fonction administrative

Rôle administratif exercé par un enseignant (Doyen, Recteur, etc.)

Grade académique

Titre universitaire (Professeur Titulaire, Maître de Conférences, etc.)

Programme académique

Parcours de formation menant à un diplôme (Licence, Master, Doctorat)

UFR

Unité de Formation et de Recherche, division académique d’un établissement

Unité d’Enseignement (UE)

Module d’enseignement composé d’éléments constitutifs

5.2. Dictionnaire de données

5.2.1. Établissement

Attribut Description Obligatoire

Code MESRS

Code officiel attribué par le MESRS

Oui

Nom

Nom complet de l’établissement

Oui

Sigle

Sigle ou acronyme (ex: UAC, UP)

Non

Type

Type d’établissement (université, école, institut, centre)

Oui

Statut juridique

Public ou Privé

Oui

Adresse

Adresse postale complète

Non

Ville

Ville de localisation

Oui

Téléphone

Numéro de contact

Non

Email

Adresse email de contact

Non

Site web

URL du site officiel

Non

Date de création

Date de création de l’établissement

Non

Actif

Indique si l’établissement est en activité

Oui

5.2.2. Enseignant

Attribut Description Obligatoire

Matricule

Matricule unique de l’enseignant

Oui

NIP

Numéro d’Identification Personnel (ANIP)

Non

Nom

Nom de famille

Oui

Prénom(s)

Prénom(s)

Oui

Date de naissance

Date de naissance

Non

Sexe

Genre (Masculin/Féminin)

Oui

Nationalité

Nationalité

Non

Email

Email professionnel

Non

Téléphone

Numéro de téléphone

Non

Grade

Grade académique (Professeur Titulaire, Maître de Conférences, etc.)

Oui

Spécialité

Domaine de spécialité

Non

Établissement principal

Établissement d’affectation principal

Oui

Statut

Statut professionnel (Titulaire, Contractuel, Vacataire)

Oui

Date de recrutement

Date de premier recrutement

Non

Actif

Indique si l’enseignant est en activité

Oui

5.2.3. Étudiant

Entité du périmètre du référentiel ; le dictionnaire ci-dessous en décrit l’attendu.
Attribut Description Obligatoire

Matricule

Matricule étudiant unique

Oui

NIP

Numéro d’Identification Personnel (ANIP)

Non

Nom

Nom de famille

Oui

Prénom(s)

Prénom(s)

Oui

Date de naissance

Date de naissance

Oui

Lieu de naissance

Lieu de naissance

Non

Sexe

Genre (Masculin/Féminin)

Oui

Nationalité

Nationalité

Oui

Email

Adresse email

Non

Téléphone

Numéro de téléphone

Non

Adresse

Adresse de résidence

Non

Actif

Indique si l’étudiant est inscrit

Oui

5.2.4. Programme académique

Attribut Description Obligatoire

Code

Code du programme

Oui

Intitulé

Intitulé complet du programme

Oui

Niveau

Niveau du diplôme (Licence, Master, Doctorat, Autres)

Oui

Durée

Durée en semestres

Oui

Crédits totaux

Nombre total de crédits

Non

Modalité

Modalité d’enseignement (Présentiel, Distanciel, Hybride)

Oui

Établissement

Établissement de rattachement

Oui

UFR

UFR de rattachement

Non

Date de création

Date de création du programme

Non

Date d’accréditation

Date de la dernière accréditation

Non

Actif

Indique si le programme est ouvert aux inscriptions

Oui

5.2.5. UFR (Unité de Formation et de Recherche)

Attribut Description Obligatoire

Code

Code unique de l’UFR

Oui

Libellé

Nom complet de l’UFR

Oui

Sigle

Sigle ou acronyme

Non

Établissement

Établissement de rattachement

Oui

Adresse

Adresse postale

Non

Email

Adresse email de contact

Non

Téléphone

Numéro de contact

Non

Date de création

Date de création de l’UFR

Non

Actif

Indique si l’UFR est en activité

Oui

5.2.6. Unité d’Enseignement (UE)

Attribut Description Obligatoire

Code

Code unique de l’UE

Oui

Intitulé

Intitulé complet de l’UE

Oui

Programme

Programme de rattachement

Oui

Semestre

Semestre d’enseignement (S1 à S6 pour Licence, etc.)

Oui

Crédits

Nombre de crédits ECTS

Oui

Coefficient

Coefficient de pondération

Oui

Type

Type d’UE (Fondamentale, Transversale, Optionnelle)

Oui

Obligatoire

Indique si l’UE est obligatoire

Oui

5.2.7. Élément Constitutif (EC)

Attribut Description Obligatoire

Code

Code unique de l’EC

Oui

Intitulé

Intitulé de l’élément constitutif

Oui

UE

Unité d’enseignement de rattachement

Oui

Crédits

Nombre de crédits

Oui

Volume horaire CM

Volume horaire cours magistraux

Oui

Volume horaire TD

Volume horaire travaux dirigés

Oui

Volume horaire TP

Volume horaire travaux pratiques

Oui

5.2.8. Diplôme

Attribut Description Obligatoire

Intitulé

Intitulé complet du diplôme

Oui

Type

Type de diplôme (Licence, Master, Doctorat, etc.)

Oui

Niveau

Niveau LMD (Bac+3, Bac+5, Bac+8)

Oui

Domaine

Domaine de spécialité (Sciences, Lettres, Droit, etc.)

Oui

Grade

Grade académique associé

Oui

5.2.9. Grade académique

Attribut Description Obligatoire

Code

Code unique du grade

Oui

Libellé

Intitulé du grade (Professeur Titulaire, Maître de Conférences, etc.)

Oui

Niveau hiérarchique

Ordre dans la hiérarchie académique

Oui

Corps fonction publique

Corps de la fonction publique associé

Non

Grade supérieur

Grade hiérarchiquement supérieur

Non

Actif

Indique si le grade est actif

Oui

5.2.10. Fonction administrative

Attribut Description Obligatoire

Code

Code unique de la fonction

Oui

Libellé

Intitulé de la fonction (Recteur, Doyen, Vice-Recteur, etc.)

Oui

Description

Description détaillée des responsabilités

Non

Niveau hiérarchique

Ordre dans la hiérarchie administrative

Oui

Actif

Indique si la fonction est active

Oui

5.2.11. Accréditation

Entité du périmètre du référentiel ; le dictionnaire ci-dessous en décrit l’attendu.
Attribut Description Obligatoire

Code

Code unique de l’accréditation

Oui

Établissement

Établissement accrédité

Oui (si accréditation établissement)

Programme

Programme accrédité

Oui (si accréditation programme)

Date d’obtention

Date d’obtention de l’accréditation

Oui

Date d’expiration

Date d’expiration de l’accréditation

Non

Organisme

Organisme ayant délivré l’accréditation

Oui

Référence

Référence officielle de l’accréditation

Non

Actif

Indique si l’accréditation est valide

Oui

5.3. Relations principales entre entités

Entité source Relation Entité cible

Établissement

1:N

UFR

Établissement

1:N

Programme

Établissement

1:N

Enseignant (affectation principale)

Programme

1:N

UE

Enseignant

1:N

Fonction administrative

Étudiant

N:M

Programme (via Inscription)

Étudiant

1:N

Diplôme

Établissement

1:N

Accréditation

Programme

1:N

Accréditation

6. Exigences non-fonctionnelles

6.1. Performance

Exigence Description Cible

Temps de réponse API

Temps de traitement des requêtes API X-ROAD

< 3 secondes (95% des requêtes)

Temps de réponse interface

Temps de chargement des pages de l’interface d’administration

< 2 secondes (95% des requêtes)

Temps de traitement d’un dépôt

Temps de traitement d’un fichier de maquette ou de planification déposé

< 5 secondes par 1000 lignes

Temps de déduplication

Temps de calcul de similarité pour détection de doublon

< 1 seconde par enregistrement

Temps de consolidation

Temps de mise à jour d’un enregistrement consolidé

< 2 secondes

6.2. Disponibilité

Exigence Description Cible

Disponibilité globale

Taux de disponibilité du service

>= 99.5%

Plages d’utilisation

Heures de disponibilité garantie

24h/24, 7j/7

Maintenance planifiée

Préavis pour maintenance

7 jours minimum

Fenêtre de maintenance

Créneau de maintenance préféré

Dimanche 2h-6h

Durée maximale maintenance

Durée maximale d’une maintenance planifiée

4 heures

6.3. Volumétrie

Donnée Estimation

Nombre d’établissements

~12 (publics et privés)

Nombre d’enseignants

~10 000

Nombre d’étudiants

~200 000

Nombre de programmes

~XXXX

Nombre d’UE

~XXXX

Croissance annuelle estimée

+5% à +10%

Taille totale base de données

~50 Go (incluant historique)

Nombre de requêtes API/jour

~50 (estimation initiale)

Utilisateurs simultanés (interface admin)

~5

6.4. Sécurité et Confidentialité

6.4.1. Authentification et Autorisation

Exigence Description

Authentification sources

Certificats X-ROAD pour les sources autoritaires

Authentification consommateurs

Certificats X-ROAD pour les systèmes consommateurs

Authentification interface admin

Authentification centralisée (OAuth2/OIDC)

Gestion des rôles

RBAC (Role-Based Access Control) avec rôles : Administrateur, Superviseur, Consultation

Expiration de session

Session inactive expirée après 30 minutes

6.4.2. Protection des données

Exigence Description

Chiffrement en transit

TLS 1.2 minimum pour toutes les communications

Chiffrement au repos

Données sensibles chiffrées en base

Journalisation

Tous les accès aux données sensibles sont tracés

Anonymisation

Exports statistiques anonymisés (sans NIP, nom, contact)

6.4.3. Matrice de droits/habilitations

La consultation des données consolidées et la recherche de personnes sont ouvertes à tout utilisateur authentifié : elles sont portées par le rôle socle, dont tous les autres héritent. Les rôles se composent par ailleurs entre eux : le Délégué DCE hérite du Superviseur et de l’Évaluateur, et l’Administrateur porte toutes les autorisations.

Fonctionnalité Administrateur Délégué DCE Superviseur Responsable académique

Consultation des données consolidées

Oui

Oui

Oui

Oui

Dépôt d’une maquette ou d’une planification

Oui

Non

Non

Oui

Traitement des lignes rejetées à l’intégration

Oui

Oui

Non

Non

Correction d’une fiche personne

Oui

Oui

Non

Non

Modification directe d’une donnée consolidée

Non

Non

Non

Non

Gestion des comptes et des rôles

Oui

Oui

Non

Non

Configuration du système

Oui

Non

Non

Non
L’alimentation en masse du référentiel n’est accordée à aucun rôle d’utilisateur. Elle s’exerce par des comptes de service : celui de chaque source autoritaire, qui porte le droit de déposer un lot de données de référence, académiques ou de personnes ; et celui de la plateforme, qui dépose les maquettes et les planifications. La modification directe d’une donnée consolidée n’est accordée à personne : une donnée se corrige en rejouant son alimentation ou depuis l’écran des rejets (RG6.12).

6.5. Accessibilité et Internationalisation

Exigence Description

Langue principale

Français

Langues

Français et anglais ; les libellés du référentiel sont servis dans la langue demandée, avec repli sur le français

Accessibilité

Interface conforme WCAG 2.1 niveau AA (cible)

Navigation clavier

Toutes les fonctionnalités accessibles au clavier

Formats de date

Format français (JJ/MM/AAAA)

Encodage

UTF-8 pour tous les échanges

7. Contraintes et Interfaces

7.1. Contraintes légales et réglementaires

Contrainte Description

Protection des données personnelles

Conformité aux réglementations nationales sur la protection des données à caractère personnel (NIP, informations d’identité)

Archivage légal

Conservation obligatoire des données académiques (diplômes, notes, inscriptions) selon les durées légales en vigueur

Interopérabilité nationale

Utilisation obligatoire de X-ROAD Bénin (XROADBJ) pour tout échange de données inter-administrations

Validation identité

Recours à l’ANIP pour la validation des Numéros d’Identification Personnel (NIP)

7.2. Contraintes organisationnelles

Contrainte Description

Validation COPIL

Toute décision concernant le référentiel provient du COPIL (IT-NUM, DCE, ASIN, MND, DSI Présidence) et est collégiale

Sources Autoritaires

Les sources de données officielles sont : MESRS, UPB (Universités), MTFP, EPES

Hébergement

Datacenter de la Présidence (infrastructure mutualisée)

Interopérabilité

X-ROAD Bénin (XROADBJ) est la plateforme d’interopérabilité nationale obligatoire

Validation NIP

ANIP (Agence Nationale d’Identification des Personnes) via X-ROAD

Confidentialité

Données sensibles : accès restreint par rôle

7.3. Interfaces avec les systèmes tiers

Code Direction Système Description

IF-01

SORTIE

X-ROAD (Provider)

Exposition sécurisée des données référentielles consolidées aux systèmes gouvernementaux consommateurs. bdes-referentiel est un provider X-ROAD.

IF-02

ENTRÉE

Sources MESRS

Import périodique des données établissements, programmes, accréditations depuis le MESRS.

IF-03

ENTRÉE

Sources UPB

Import périodique des données enseignants, étudiants, programmes depuis les systèmes universitaires.

IF-04

ENTRÉE

Sources MTFP

Import périodique des données RH des enseignants titulaires du secteur public.

IF-05

ENTRÉE

Sources EPES

Import périodique des données établissements privés, programmes, enseignants, étudiants.

IF-06

CONSULTATION

ANIP

Validation du Numéro d’Identification Personnel (NIP) des enseignants et étudiants.

IF-07

SORTIE

Service Notifications

Envoi des alertes sur anomalies, alertes de qualité, rapports de synchronisation.

IF-08

BIDIRECTIONNEL

Interface Web Admin

Application d’administration pour la gestion manuelle des référentiels, résolution des doublons et monitoring.

7.3.1. Formats d’échange

Interface Format entrant Format sortant

IF-01 (X-ROAD)

-

JSON, XML (selon requête consommateur)

IF-02 à IF-05 (Sources)

JSON via API ; Excel pour les maquettes et les planifications

-

IF-06 (ANIP)

-

JSON (réponse validation NIP)

IF-07 (Notifications)

-

Email (HTML/texte)

IF-08 (Interface Admin)

Formulaires web

JSON (API REST)

8. Hypothèses et Risques

8.1. Hypothèses

ID Hypothèse Impact si invalide

H-01

Les sources autoritaires (MESRS, UPB, EPES, MTFP) disposent de données exploitables dans un format structuré, tableur ou export de base de données

Développement de connecteurs spécifiques, saisie manuelle accrue

H-02

Les sources autoritaires ont la capacité technique d’alimenter le référentiel via API ou dépôt de fichiers

Mise en place de processus d’import manuels

H-03

L’infrastructure X-ROAD Bénin est opérationnelle et accessible pour l’exposition des services

Exposition des données via API REST directe (moins sécurisée)

H-04

L’ANIP dispose d’un service de validation NIP accessible via X-ROAD

Validation manuelle des identités, risque de doublons

H-05

Le datacenter de la Présidence peut héberger la solution avec les ressources nécessaires

Recherche d’un hébergement alternatif

H-06

Les établissements acceptent de partager leurs données selon les formats définis

Négociations supplémentaires, adaptation des formats

H-07

Les utilisateurs finaux (administrateurs) ont les compétences pour utiliser l’interface de gestion

Formation complémentaire nécessaire

H-08

Le COPIL peut se réunir régulièrement pour les validations et arbitrages

Retards dans les prises de décision

8.2. Risques fonctionnels

ID Risque Probabilité Impact Mitigation

R-01

Qualité insuffisante des données sources (incomplètes, incohérentes)

Élevée

Élevé

Mise en place de contrôles de qualité à l’import, scores de qualité, alertes automatiques

R-02

Résistance des établissements à partager leurs données

Moyenne

Élevé

Implication du MESRS, communication sur les bénéfices, garanties de confidentialité

R-03

Doublons non détectés malgré les algorithmes

Moyenne

Moyen

Revue manuelle périodique, amélioration continue des algorithmes de similarité

R-04

Indisponibilité des sources autoritaires

Moyenne

Moyen

Mode dégradé avec données en cache, notifications aux administrateurs

R-05

Changement des formats de données des sources

Moyenne

Moyen

Documentation des formats, versionnement des connecteurs, tests de non-régression

R-06

Surcharge du système lors d’imports massifs

Faible

Moyen

Traitement par lots, file d’attente, dimensionnement adapté

R-07

Perte de données lors de la consolidation

Faible

Élevé

Historisation complète, traçabilité des sources, sauvegardes régulières

R-08

Difficultés d’adoption par les utilisateurs

Moyenne

Moyen

Interface ergonomique, documentation utilisateur, support et formation

R-09

Évolution réglementaire impactant les données à collecter

Faible

Moyen

Architecture flexible, veille réglementaire, capacité d’évolution rapide

8.3. Dépendances critiques

Dépendance Description Criticité

X-ROAD Bénin

Infrastructure d’interopérabilité pour l’exposition des données

Critique

Authentification centralisée

Gestion des identités pour l’interface d’administration

Critique

Sources autoritaires

Disponibilité et qualité des données MESRS, UPB, EPES, MTFP

Critique

ANIP

Service de validation des NIP

Haute

Datacenter Présidence

Hébergement de l’infrastructure

Critique

bdes-evaluation

Principal consommateur des données référentielles

Haute

9. Annexes

9.1. Interfaces

Le module bdes-referentiel est un service sans interface propre : aucun écran n’y manipule directement les données consolidées. Les fonctions que décrivent ses cas d’utilisation — la correction d’une donnée rejetée à l’intégration, la revendication d’une fiche, le dépôt d’une maquette ou d’une planification, la consultation des nomenclatures, des structures et des offres — sont exercées depuis les écrans du module bdes-evaluation, qui appelle le référentiel par son compte de service.

9.2. Exemples de rapports

9.2.1. Rapport de qualité des données

Entité Total Score >= 80 Score 50-79 Score < 50

Établissements

80

72 (90%)

6 (8%)

2 (2%)

Enseignants

10 000

8 500 (85%)

1 200 (12%)

300 (3%)

Étudiants

200 000

170 000 (85%)

25 000 (12.5%)

5 000 (2.5%)

Programmes

2 000

1 800 (90%)

180 (9%)

20 (1%)

9.2.2. Rapport d’import

Information Valeur

Date d’import

2024-12-15 14:30:00

Source

UPB - Université d’Abomey-Calavi

Type de données

Enseignants

Fichier

enseignants_uac_2024.xlsx

Lignes traitées

1 250

Succès

1 180 (94.4%)

Erreurs

70 (5.6%)

Doublons détectés

35

Durée traitement

4.2 secondes

9.2.3. Rapport des doublons en attente

ID Enregistrement 1 Enregistrement 2 Score Date détection

DUP-001

KOKOU Jean (UAC)

KOKOU Jean-Pierre (UP)

92%

2024-12-10

DUP-002

MENSAH Afi (EPES-001)

MENSAH Affi (EPES-002)

88%

2024-12-11

DUP-003

AGBOSSOU Marc (MTFP)

AGBOSSOU Marc (UPB)

95%

2024-12-12

9.3. Références documentaires

Réf Document Source

REF-01

BDES_REF_REGLES_GESTION.pdf

DCE / MESRS

REF-02

Spécifications X-ROAD Bénin

ASIN