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 et objectifs

1.1. Vue d’ensemble

bdes-referentiel est le système central de gestion des données de référence de l’enseignement supérieur au Bénin. Il agrège, normalise et expose via X-Road les données autoritaires provenant de multiples sources (systèmes de scolarité des universités, ministères, etc.).

Le système fonctionne comme un pipeline de données ELT (Extract, Load, Transform) qui :

  • Collecte les données de sources hétérogènes (API, fichiers Excel, bases de données)

  • Traite ces données (déduplication, normalisation, validation)

  • Expose un référentiel consolidé via X-Road pour les systèmes consommateurs (notamment bdes-evaluation)

1.2. Objectifs métier

Priorité Objectif

1

Centraliser les données de référence de l’enseignement supérieur du Bénin dans une source unique de vérité

2

Éliminer les doublons et incohérences entre les différentes sources de données universitaires

3

Fournir un référentiel fiable et à jour pour les systèmes métier (évaluation, statistiques, pilotage)

4

Assurer l’interopérabilité via X-Road avec les systèmes consommateurs

5

Automatiser la collecte et le traitement des données référentielles

1.3. Exigences de qualité spécifiques

Priorité Exigence Description

1

Fiabilité des données

Les données exposées doivent être exactes, complètes et cohérentes (taux d’erreur < 1%)

2

Disponibilité

Service disponible 99.5% du temps pendant les heures ouvrables

3

Performance

Réponse aux requêtes API < 2 secondes (95e percentile)

4

Sécurité

Authentification forte via X-Road, traçabilité complète des accès aux données

5

Maintenabilité

Architecture modulaire permettant l’ajout de nouvelles sources sans refonte majeure

1.4. Parties prenantes

Les parties prenantes de la plateforme BDES sont documentées de manière centralisée dans le Document d’Architecture Technique (DAT).

Voir : DAT - Contexte et Enjeux > Parties Prenantes

2. Contexte et périmètre

2.1. Contexte métier

context bdes referentiel
Figure 1. Diagramme de contexte métier

2.1.1. Partenaires de communication

Partenaire Description

SI Université

Systèmes d’information de gestion de la scolarité des Universités Publiques du Bénin : student.easylmd.net (UNA), academie.unstim.bj (UNSTIM), offres.uac.bj (UAC), Okapi (UPAR). Fournissent les données sur les enseignants, étudiants, programmes, UE/EC, soutenances.

Autres SI

Systèmes externes complémentaires. Fournissent les données RH statutaires des enseignants (corps, grade, affectations).

bdes-evaluation

Système consommateur principal. Utilise les référentiels (enseignants, universités, programmes) pour l’évaluation des enseignants.

X-Road

Infrastructure d’échange de données sécurisée. bdes-referentiel expose ses services via X-Road pour garantir traçabilité et sécurité.

Administrateurs DCE

Supervisent le fonctionnement du système, configurent les sources de données, pilotent la qualité des données.

2.1.2. Modèle de données référentielles

Le référentiel s’articule autour de six schémas logiques — REFERENCE, RAW, STAGING, MDM, GOLDEN et AUDIT — garantissant la séparation des préoccupations, la traçabilité et la qualité des données :

Le schéma GOLDEN contient les données maîtres consolidées et réconciliées du référentiel. Ces données constituent la source de vérité unique (Single Source of Truth) après nettoyage, déduplication et validation des données reçues dans la zone d’atterrissage. L’organisation en packages logiques (Personnes, Rôles_Fonctions, Structures, Formations) facilite la maintenance et l’évolution.

Le package GOLDEN.Personnes centralise toutes les informations relatives aux personnes physiques intervenant dans l’enseignement supérieur : étudiants, enseignants, chercheurs, personnel administratif. Une personne y a une fiche unique, identifiée par son matricule, qui porte son identité, son état civil et sa situation administrative. Le cumul de rôles — étudiant en doctorat et enseignant vacataire, par exemple — est porté par les affectations du package Rôles_Fonctions.

arc42 ref schema golden personne
Figure 2. Schéma GOLDEN.Personnes

Le package GOLDEN.Roles_Fonctions porte les affectations temporalisées : celles d’un rôle métier à une personne dans une structure, celles d’une fonction organisationnelle, et les habilitations. Les nomenclatures des rôles et des fonctions elles-mêmes appartiennent au schéma REFERENCE. Une même personne peut cumuler plusieurs rôles et fonctions, simultanément ou successivement, dans des structures différentes.

arc42 ref schema golden role fonction
Figure 3. Schéma GOLDEN.Role_Fonctions

Le package GOLDEN.Structures modélise l’organigramme complet de l’enseignement supérieur : universités, facultés (UFR), écoles, instituts, départements, laboratoires de recherche, chaires, écoles doctorales. Chaque structure se rattache à une structure parente unique ; le niveau hiérarchique est calculé à la lecture par la vue golden.v_structure_organisationnelle.

Caractéristiques communes au schéma GOLDEN : * Modèle normalisé évitant la redondance * Identité et état civil portés par la fiche de la personne ; contacts, adresses et pièces d’identité dans des tables dédiées * Temporalité par date_debut et date_fin pour les affectations, les liens et la validité des contacts et des adresses ; par dates d’ouverture et de fermeture pour les structures ; par plage de validité pour les offres de formation * Traçabilité des écritures par Hibernate Envers, dans le schéma AUDIT

arc42 ref schema golden structure
Figure 4. Schéma GOLDEN.Structures

Le package GOLDEN.Formation modélise l’offre de formation complète de l’enseignement supérieur : diplômes, formations, offres annuelles, parcours, unités d’enseignement (UE) et éléments constitutifs (EC), leurs rattachements à l’offre, et la planification des cours et de leurs créneaux. La hiérarchie permet de représenter la structure du système LMD (Licence-Master-Doctorat), avec ses semestres et ses crédits.

arc42 ref schema golden formation
Figure 5. Schéma GOLDEN.Formation

Le schéma REFERENCE contient l’ensemble des nomenclatures, listes de valeurs et référentiels statiques utilisés dans tout le système. Ces tables constituent le socle commun de données partagées entre toutes les entités métier. Elles garantissent l’homogénéité terminologique, facilitent l’interopérabilité avec les systèmes externes et permettent l’évolution des valeurs sans impact structurel sur la base.

Caractéristiques principales : * Données peu volatiles, modifiées par administration centralisée * Référencement depuis GOLDEN par le code de la nomenclature, et par l’identifiant pour quelques rattachements * Taxonomie des domaines, mentions et spécialités conforme à la nomenclature REESAO ; codes des pays conformes à la norme ISO 3166 * Historisation via colonnes d’audit (created_at, updated_at, version)

arc42 ref schema reference
Figure 6. Schéma REFERENCE

Les schémas RAW et STAGING forment la zone d’atterrissage des données provenant des sources externes (universités, MESRS, MTFP, etc.). Le lot arrive dans son format natif et y est conservé intégralement, pour préserver l’intégrité de la source ; il est ensuite éclaté en lignes typées, une table par entité, où se font le contrôle, la correction et le rapprochement avant consolidation dans GOLDEN.

Principes de fonctionnement : * Le payload reçu est conservé intégralement dans raw.bulk_import * Chaque ligne de staging porte son statut de traitement : PENDING, PROCESSING, PROCESSED, ERROR ou SKIPPED * Une ligne en défaut reste en staging, avec son motif, jusqu’à correction et relance * Les lignes traitées sont conservées, pour la traçabilité et la reprise des lots en erreur

arc42 ref schema ods
Figure 7. Zone d’atterrissage : schémas RAW et STAGING

Le schéma AUDIT assure la traçabilité des écritures sur les entités consolidées, par Hibernate Envers : chaque entité auditée porte sa table audit.<entité>_aud, et audit.revinfo horodate les révisions. Le schéma MDM porte les journaux du pipeline — mdm.reconciliation_log, mdm.ingest_error — et la provenance par champ, mdm.field_provenance. Conforme aux exigences ISO 27001 et RGPD pour l’auditabilité des données sensibles.

arc42 ref schema audit
Figure 8. Schémas AUDIT et MDM

2.2. Contexte technique

context technique referentiel
Figure 9. Diagramme de contexte technique

2.2.1. Canaux de communication

Canal Protocole/Format Données Fréquence

SI Université → bdes-migration

Excel

Enseignants, étudiants, programmes, UE/EC, soutenances

Trimestriel

Autres SI → bdes-migration

Excel via messagerie ou dépôt

Données RH enseignants (affectations, corps, grade)

À la demande

bdes-migration → referentiel-api-ms

HTTP/REST (JSON), api/v1/bulk/*

Lots d’import, payload conservé intégralement

À la demande

referentiel-api-ms → pipeline MDM

Appel de fonction dans la transaction de l’import

Ingestion vers staging, rapprochement vers golden

Synchrone à l’import

X-Road Security Server → referentiel-api-ms

HTTP/REST (JSON)

Requêtes des consommateurs externes

À la demande

bdes-evaluation → referentiel-api-ms

HTTP/REST, compte de service

Consultation des référentiels ; dépôt des maquettes et des planifications

Temps réel

ANIP/Autres consommateurs → X-Road

X-Road Protocol (REST)

Consultation données statistiques, indicateurs

À la demande

Formats de données

  • Entrée : Excel, JSON (API REST)

  • Stockage : PostgreSQL (schéma normalisé)

  • Exposition : JSON via X-Road (REST) ou selon configuration

3. Stratégie de solution

3.1. Approche générale

bdes-referentiel adopte une architecture ELT (Extract-Load-Transform) dont les trois étapes s’exécutent dans PostgreSQL :

  • Extraction & Chargement : réception des données par l’API d’import en masse (/api/v1/bulk/*), conservation du payload complet dans le schéma raw, puis éclatement en lignes typées dans le schéma staging

  • Transformation en base : rapprochement et consolidation vers le schéma golden par des fonctions PL/pgSQL du schéma mdm, livrées et versionnées avec le schéma par les migrations Flyway

  • Exposition via API Spring Boot : services REST sécurisés par X-Road pour les consommateurs

3.2. Décisions technologiques

Technologie Décision Justification

PL/pgSQL (fonctions mdm.*)

Moteur de transformation

Transformation au plus près des données, dans la transaction de l’import ; aucun composant d’exécution supplémentaire ; code versionné avec le schéma

Flyway (bdes-db-migration)

Livraison du schéma et du pipeline

Les fonctions du pipeline sont des objets de la base ; chaque évolution est une migration (CREATE OR REPLACE) rejouable

PostgreSQL 16

Base de données référentielle

ACID, JSONB pour les payloads bruts, extensions pg_trgm (similarité) et unaccent (normalisation des noms), vues

Spring Boot 3

Framework API REST

Stack Java standard, Spring Data JPA, intégration X-Road, cache Redis

X-Road

Bus d’interopérabilité

Exigence gouvernementale, authentification mutuelle, traçabilité complète

3.3. Composants

referentiel-api-ms (Spring Boot)

Reçoit les imports en masse, déclenche le pipeline de consolidation (mdm.process_import) dans la transaction de la requête, expose les données golden via API REST avec cache, et porte le workflow de correction des lignes en erreur.

Pipeline MDM (fonctions PL/pgSQL)

Ingestion raw vers staging (mdm.ingest_*), rapprochement staging vers golden (mdm.reconcile_*), déclencheurs d’auto-rapprochement sur les tables staging. Fonctionnement à la demande, synchrone à l’appel d’import.

bdes-db-migration (Flyway)

Porte les migrations du schéma referentiel, dont la définition des tables staging, des fonctions du pipeline et de ses déclencheurs. Exécuté en Job Kubernetes à chaque livraison.

3.4. Stratégie qualité des données

quality strategy

Niveaux de validation :

  1. Chargement staging (mdm.ingest_*) : champs obligatoires (matricule, nom, code), normalisation des libellés, résolution des codes de référence par libellé (similarité pg_trgm), écart des éléments déjà connus. Un élément en défaut est journalisé dans mdm.ingest_error ; le lot continue.

  2. Rapprochement (mdm.reconcile_*) : existence des références, résolution de la clé naturelle, règles d’unicité et de suppression. Une ligne en défaut passe en statut ERROR avec un message, et reste disponible pour correction.

  3. Consolidation golden : création ou mise à jour. En mise à jour, chaque champ prend la dernière valeur non vide reçue ; une valeur absente ou vide ne remplace pas la valeur en place.

  4. Traçabilité : mdm.field_provenance (source du dernier apport par champ, pour les personnes), mdm.reconciliation_log (journal des lots), raw.bulk_import (payload conservé), tables audit.*_aud (Hibernate Envers).

3.5. Architecture des données

Schéma à 6 couches :

  • REFERENCE : Nomenclatures (grades, corps, statuts, types, années académiques, géographie)

  • RAW : Payloads d’import reçus par l’API, conservés intégralement (raw.bulk_import)

  • STAGING : Une table par entité importée, lignes typées avec statut de traitement (PENDING, PROCESSING, PROCESSED, ERROR, SKIPPED)

  • MDM : Configuration des sources et des déclencheurs, fonctions du pipeline, journal, provenance

  • GOLDEN : Données consolidées (source de vérité)

  • AUDIT : Historique des entités JPA (Hibernate Envers)

Les schémas raw et staging forment la zone d’atterrissage. Les lignes de raw et de staging sont conservées après traitement, pour la traçabilité et la reprise des lots en erreur.

La stratégie de déploiement est documentée dans le DAT - Exploitation.

4. Vue en Briques

4.1. Niveau 1 : Vue d’ensemble

building blocks level1
Figure 10. Diagramme des briques constituantes

4.1.1. Composants principaux

Composant Responsabilité

referentiel-api-ms

Expose les référentiels via API REST. Reçoit les imports en masse (/api/v1/bulk/*), déclenche le pipeline de consolidation en base, porte le workflow de correction des lignes en erreur (/api/v1/staging/errors). Gère authentification X-Road, requêtes, cache, logs.

Pipeline MDM (PostgreSQL)

Fonctions PL/pgSQL et déclencheurs du schéma mdm et du schéma staging : ingestion du payload brut en lignes typées, rapprochement et consolidation vers golden, journalisation.

bdes-db-migration

Migrations Flyway du schéma referentiel. Livre et fait évoluer les tables, les fonctions du pipeline et leurs déclencheurs.

Base de données

Stocke référentiels consolidés (PostgreSQL). Schémas REFERENCE, RAW, STAGING, MDM, GOLDEN, AUDIT.

bdes-migration

Outil d’alimentation en ligne de commande (Python). Transforme les fichiers sources et les soumet à l’API d’import (POST /api/v1/bulk/personnes). Déployé en CronJob (voir DAT).

X-Road Security Server

Infrastructure externe. Sécurité, traçabilité, routage des requêtes.

4.2. Niveau 2 : Pipeline MDM

building blocks pipeline mdm
Figure 11. Composantes du pipeline de consolidation

Composants du pipeline

Composant Description

Service d’import

BulkController et BulkImportService. Enregistre le payload JSON dans raw.bulk_import (statut RECEIVED, batch_id), puis appelle mdm.process_import(id) dans la même transaction. Construit le rapport d’import (compteurs par phase et par entité, statut PROCESSED ou PARTIAL). Les dépôts Excel (planification, UE/EC) sont convertis en payload JSON et suivent le même chemin.

raw.bulk_import

Table de réception. Conserve le payload complet, le type (REFERENTIEL, ACADEMIQUE, PERSONNES), la source (source_code) et le statut de traitement (RECEIVED, PARSING, PARSED, RECONCILING, PROCESSED, ERROR).

Fonctions d’ingestion

mdm.ingest_import (dispatcher par type) vers mdm.ingest_referentiel, mdm.ingest_personnes, mdm.ingest_academique, mdm.ingest_planifications. Lisent le JSONB, normalisent les libellés (mdm.normalize_libelle), résolvent certains codes par libellé (mdm.fuzzy_match_*, pg_trgm), écartent les éléments déjà connus, insèrent une ligne par élément dans la table staging correspondante.

Tables staging

Une table par entité importée (personne physique, adresse postale, coordonnées de contact, affectations rôle et fonction, structure organisationnelle, type de structure, formation, programme de formation, unité d’enseignement, élément constitutif, planification de cours, année académique, grade, statut, corps, mention, spécialité, domaine, nature de support, type de diplôme). Colonnes communes : source_code, batch_id, status, error_message, raw_data, colonnes de correction (corrected_by, corrected_at, correction_note).

Fonctions de rapprochement

mdm.reconcile_<entité>(staging_id) : traitement unitaire d’une ligne PENDING (résolution des références, recherche de l’enregistrement golden existant, INSERT ou UPDATE, statut final). mdm.reconcile_all_<entité>(batch_id) : parcours des lignes PENDING d’un lot, garde d’exception par ligne, journal dans mdm.reconciliation_log.

Déclencheurs d’auto-rapprochement

staging.trg_reconcile_<entité>, AFTER INSERT sur la table staging. Appellent la fonction unitaire si mdm.trigger_config.auto_reconcile est vrai pour l’entité. Fonctions mdm.enable_auto_reconcile, mdm.disable_auto_reconcile, mdm.enable_all_auto_reconcile, mdm.disable_all_auto_reconcile pour modifier cette configuration.

Configuration des sources

mdm.source_config : codes de source autorisés (ANIP, MESRS, UAC, UNA, DCE_FORMS, DCE_DATA, IMPORTATION, EVALUATION_API, REFERENTIEL_API, SELF_DECLARED) avec libellé et niveau de confiance. Le source_code des tables staging référence cette table.

Journal et provenance

mdm.reconciliation_log (exécutions des lots : compteurs, durée, statut), mdm.v_reconciliation_stats (agrégation par jour et entité), mdm.field_provenance (source du dernier apport par champ, alimentée pour les personnes physiques), mdm.ingest_error (éléments non ingérés avec leur contenu brut).

Workflow de correction

StagingErrorController et StagingErrorService. Vue staging.v_all_errors (lignes ERROR de toutes les tables staging), correction colonne par colonne, remise en PENDING par staging.reset_for_retry suivie de l’appel de la fonction unitaire, ou passage en SKIPPED.

4.3. Niveau 2 : bdes-referentiel-api

building blocks api
Figure 12. Composantes du service API
Composant Description

Contrôleurs REST

Endpoints API répartis en six familles : les nomenclatures de référence (pays, genres, corps, grades, catégories, classes, mentions, spécialités, statuts, fonctions, rôles métiers, domaines REESAO, types et natures, diplômes et leurs niveaux, finalités et voies, modalités d’évaluation, années académiques, semestres, libellés) ; les personnes (api/v1/personnes, adresses postales, coordonnées de contact, liens de personne, affectations de fonction et de rôle) ; les structures (api/v1/structures et leurs périodes de validité) ; l'offre de formation (api/v1/formations, programme-formations, prerequis-formations, ue, ec, types-ue, habilitations, diplomes) ; le calendrier académique et la planification (calendrier-academique, creneau-types, planifications-cours) ; et les paramètres applicatifs (/api/v1/app-params). Validation des entrées, sérialisation JSON.

Contrôleurs d’import et de correction

/api/v1/bulk/{referentiel,academique,personnes,planification} et dépôts Excel associés ; /api/v1/staging/errors (liste, détail, correction, relance, ignorer). Habilitations dédiées (bulk-*:create, staging-errors:read, staging-errors:write, planification:orchestrate).

Services Métier

Logique applicative : requêtes complexes, agrégations, filtres. BulkImportService : contrôle de périmètre des dépôts de planification, appel du pipeline, rapport d’import.

Repositories

Spring Data JPA. Accès base de données, requêtes JPQL optimisées.

Cache

Redis. Cache données référentielles peu volatiles (TTL configurable). Éviction des caches de formations à chaque import académique.

Sécurité

Intégration X-Road pour authentification. Vérification certificats, traçabilité requêtes.

5. Vue Exécution

5.1. Pipeline de consolidation des données

Le processus de consolidation transforme les données brutes multi-sources (schémas raw et staging) en référentiel unique (schéma golden, et schéma reference pour les nomenclatures). Cette transformation s’opère par des fonctions PL/pgSQL du schéma mdm, exécutées dans la transaction de l’appel d’import.

Principes de fonctionnement :

  • Les données sources arrivent par l’API d’import en masse (POST /api/v1/bulk/{referentiel,academique,personnes,planification}) sous forme d’un payload JSON ; les dépôts Excel (planification, UE/EC) sont convertis en payload JSON par le service et suivent le même chemin

  • Le payload est conservé intégralement dans raw.bulk_import, puis éclaté en lignes typées dans les tables staging (phase INGEST)

  • Chaque ligne staging est rapprochée d’un enregistrement golden existant, créé ou mis à jour (phase RECONCILE), soit par le déclencheur AFTER INSERT de sa table, soit par le lot mdm.reconcile_all_<entité> appelé à la fin de l’import

  • Une ligne qui ne peut pas être rapprochée reste en staging avec le statut ERROR et un message ; elle est corrigeable et rejouable depuis l’API /api/v1/staging/errors

  • mdm.reconciliation_log journalise chaque lot ; mdm.field_provenance conserve la source du dernier apport par champ pour les personnes physiques ; mdm.ingest_error conserve les éléments non ingérés

Les sections suivantes détaillent le déroulement commun d’un import, puis les flux par domaine métier.

5.2. Déroulement d’un import en masse

runtime import sequence

Étapes :

  1. Réception : BulkImportService enregistre le payload dans raw.bulk_import avec le type (REFERENTIEL, ACADEMIQUE, PERSONNES), le code de source et un batch_id. Pour une planification déposée par un responsable d’UFR, le service vérifie au préalable que toutes les formations citées appartiennent à son périmètre.

  2. Déclenchement : dans la même transaction, le service appelle mdm.process_import(id). La fonction refuse un import qui n’est pas en statut RECEIVED.

  3. Phase INGEST : mdm.ingest_import route vers mdm.ingest_referentiel, mdm.ingest_personnes ou mdm.ingest_academique selon le type ; mdm.ingest_planifications traite la section planifications d’un import académique. Chaque élément du payload est normalisé et inséré dans la table staging de son entité, avec le batch_id de l’import. Un élément dont le champ obligatoire manque est compté skipped ; un élément déjà connu (clé exacte ou similarité d’intitulé) est compté matched et n’est pas inséré ; un élément dont l’insertion échoue est journalisé dans mdm.ingest_error et compté errors. Le lot continue dans tous les cas.

  4. Rapprochement par déclencheur : pour les entités dont mdm.trigger_config.auto_reconcile est vrai, le déclencheur AFTER INSERT appelle la fonction unitaire immédiatement, pendant la phase INGEST. Une exception dans la fonction est rattrapée par le déclencheur, qui marque la ligne ERROR sans interrompre l’insertion.

  5. Phase RECONCILE : mdm.process_import appelle les lots mdm.reconcile_all_<entité>(batch_id) dans un ordre fixe par type d’import (voir Orchestration globale). Chaque lot ne traite que les lignes encore PENDING : pour une entité à déclencheur actif, le lot ne trouve rien et renvoie des compteurs à zéro ; pour une entité sans déclencheur (corps, mention, affectations, programme de formation, année académique), c’est le lot qui effectue le rapprochement.

  6. Rapport : la fonction renvoie une ligne par phase et par entité (total_items, inserted, matched, skipped, errors). Le service en déduit le statut PROCESSED (aucune erreur) ou PARTIAL. Pour les dépôts UE/EC et planification, le service recompte directement sur les lignes staging du lot (reconcile_action, status, error_message) et sur mdm.ingest_error, afin de restituer les écritures effectuées par les déclencheurs.

  7. Échec global : si mdm.process_import lève une exception non rattrapée (type inconnu, statut inattendu), le service journalise l’erreur, la transaction est annulée et l’appel répond en erreur.

Statuts successifs de raw.bulk_import : RECEIVED → PARSING → PARSED → RECONCILING → PROCESSED (ou ERROR).

5.3. Flux 1 : Consolidation des structures organisationnelles

La consolidation des structures (universités, UFR, départements, écoles) résout la hiérarchie par le code ou le sigle du parent.

runtime structures

Étapes du flux :

  1. Import : section structures d’un payload academique. Chaque élément porte un code, un libellé, un sigle, un type de structure et le code ou le sigle de la structure parente.

  2. Chargement staging (mdm.ingest_academique) : libellé normalisé ; un élément sans libellé valide est écarté ; un élément dont le code existe déjà en staging pour la même source, ou dont le libellé est similaire (pg_trgm, seuil 0,85) à une structure déjà en staging pour la même source ou présente en golden, est compté matched et n’est pas inséré. Insertion dans staging.structure_organisationnelle.

  3. Rapprochement (mdm.reconcile_structure_organisationnelle, par déclencheur) : résolution du type de structure par code ou libellé dans reference.type_structure ; résolution du parent par code ou sigle dans golden.structure_organisationnelle ; recherche de la structure existante par code, sigle ou libellé (insensible à la casse).

  4. Chargement : si absente, insertion dans golden.structure_organisationnelle (statut ACTIF) ; si présente, seule la structure parente est renseignée lorsqu’elle manquait. Les autres attributs d’une structure existante ne sont pas modifiés par l’import.

5.4. Flux 2 : Consolidation des enseignants

La déduplication des enseignants est critique : un même enseignant peut apparaître dans plusieurs sources avec des variations orthographiques du nom, et certaines sources ne fournissent pas de matricule définitif.

runtime enseignants

Étapes du flux :

  1. Extraction : section enseignants d’un payload personnes. Chaque élément porte identité, naissance, nationalité, contacts, adresses, grade, statut, corps, et les sections affectations (rôles) et fonctions.

  2. Chargement staging (mdm.ingest_personnes) : matricule et nom obligatoires ; noms et libellés normalisés ; grade et corps résolus par code, sinon par similarité de libellé (mdm.fuzzy_match_grade, mdm.fuzzy_match_corps) ; statut résolu par code ou libellé exact. Un élément dont le matricule ou le NPI existe déjà (en staging pour la même source, ou en golden), ou dont le nom complet est similaire à 0,90 ou plus à une personne connue, est compté matched et n’est pas inséré. Insertion dans staging.personne_physique (avec le JSON brut dans raw_data), puis dans staging.adresse_postale, staging.coordonnees_contact, staging.affectation_role_personne et staging.affectation_fonction_personne pour les sections correspondantes.

  3. Rapprochement (mdm.reconcile_personne, par déclencheur) :

    • si un corps_code est fourni, il doit exister dans reference.corps (code ou libellé), sinon la ligne est rejetée avec la liste des corps disponibles ;

    • recherche par matricule exact dans golden.personne_physique ;

    • pour un matricule provisoire (PROV-*), recherche par clé de nom normalisée (mdm.person_name_key : minuscules, sans accents, lettres seules, mots triés) ; un seul homonyme vivant est rapproché ; plusieurs homonymes sont départagés par l’établissement des affectations (libellés des structures et de leurs ancêtres) ; sans départage, la ligne est rejetée avec un message de doublon potentiel ; la colonne force_create permet au correcteur d’imposer la création.

  4. Chargement : si absente, insertion dans golden.personne_physique (statut ACTIF, valeurs par défaut pour sexe, nationalité, échelon et catégorie non fournis) ; si présente, mise à jour champ par champ : chaque champ prend la valeur reçue si elle est non vide, et conserve sinon la valeur en place. Les spécialités listées dans raw_data sont liées à la personne. Le matricule effectif est celui de la fiche rapprochée.

  5. Provenance : pour chaque champ non vide reçu, mdm.field_provenance enregistre la source et la date du dernier apport (score constant par champ).

  6. Entités liées (phase RECONCILE) : mdm.reconcile_all_adresses_postales et mdm.reconcile_all_coordonnees_contacts traitent les lignes restantes ; les affectations relèvent du Flux 5.

5.5. Flux 3 : Consolidation des étudiants

Similaire aux enseignants, avec la gestion des doubles cursus et des réorientations (même étudiant inscrit dans plusieurs formations ou universités successivement). Les étudiants sont rattachés au modèle golden par le rôle ETUDIANT de AFFECTATION_ROLE_PERSONNE.

runtime etudiants

Particularités :

  • Déduplication inter-universités : détection d’un étudiant ayant changé d’établissement (réorientation)

  • Déduplication intra-université : détection d’un double cursus (même étudiant dans deux formations simultanément)

  • Fusion dans la même PERSONNE_PHYSIQUE, distinction par AFFECTATION_ROLE_PERSONNE (rôle ETUDIANT)

5.6. Flux 4 : Consolidation des programmes de formation

Les maquettes pédagogiques arrivent dans un payload academique dont les sections formations, programmes, unitesEnseignement et elementsConstitutifs sont traitées dans cet ordre ; chaque UE référence sa formation et chaque EC référence sa formation et son UE.

runtime programmes

Étapes du flux :

  1. Extraction : payload academique (API, ou dépôt Excel UE/EC converti par le service). Le service normalise les codes d’UE (lettres et chiffres, majuscules) sauf pour les lignes action=DELETE.

  2. Chargement staging (mdm.ingest_academique) :

    • Formations : intitulé obligatoire ; un intitulé identique en staging pour la même source, ou similaire (0,85) à une formation déjà en staging pour la même source ou présente en golden, est compté matched ; sinon insertion dans staging.formation.

    • Programmes (offre de formation) : formation et année académique obligatoires ; insertion dans staging.programme_formation sans déduplication.

    • UE : avec un code, insertion directe dans staging.unite_enseignement ; sans code, déduplication par intitulé similaire (0,85) bornée à la formation. L’année académique de l’offre visée est conservée si fournie.

    • EC : même règle que les UE (déduplication par intitulé uniquement en l’absence de code), insertion dans staging.element_constitutif.

  3. Rapprochement des formations (mdm.reconcile_formation, par déclencheur) : type de diplôme résolu par libellé ; formation existante recherchée par code ou intitulé ; insertion si absente ; si présente, aucun attribut de la fiche existante n’est modifié par l’import.

  4. Rapprochement de l’offre (mdm.reconcile_programme_formation, phase RECONCILE) : formation et année académique résolues par code ou libellé, sinon rejet ; clé d’unicité (formation, année) sur les offres vivantes ; l’action VERSIONNER ouvre une nouvelle période de validité de la maquette à partir de l’année cible (mdm.reconduire_offre), avec refus explicite si l’année précédente n’est pas couverte ou si la maquette commence déjà à l’année demandée.

  5. Rapprochement des UE (mdm.reconcile_unite_enseignement, par déclencheur) : formation résolue par code ou intitulé, sinon rejet ; semestre résolu par libellé sur le modèle en vigueur, avec décomposition des libellés hérités (« S5 Licence ») en numéro et niveau ; clé (formation, code) sur les lignes vivantes ; action=DELETE effectue une suppression logique, refusée si l’UE possède encore des EC actifs ; l’action effectivement appliquée est mémorisée dans reconcile_action. Après écriture, l’UE est rattachée à l’offre de l’année indiquée, ou de l’année en cours à défaut (mdm.rattacher_ue_a_l_offre) ; un rattachement impossible n’empêche pas l’écriture de l’UE.

  6. Rapprochement des EC (mdm.reconcile_element_constitutif, par déclencheur) : UE résolue par code puis par libellé, dans la formation, sur les lignes vivantes, sinon rejet ; clé (UE, code) ; action=DELETE refusée si des planifications actives référencent l’EC ; natures de support et modalités d’évaluation remplacées intégralement ; rattachement à l’offre comme pour l’UE. Le total des crédits de la formation est recalculé par déclencheur sur golden.unite_enseignement.

5.7. Flux 5 : Consolidation des affectations

Les affectations lient une personne, un rôle métier ou une fonction, et une structure, avec temporalité. Elles arrivent dans les sections affectations et fonctions de chaque enseignant du payload personnes et sont traitées en phase RECONCILE, après les personnes.

runtime affectations

Étapes du flux :

  1. Extraction : pour chaque enseignant, rôles (affectations : métier, structure, dates) et fonctions (fonctions : fonction, structure, dates, acte de nomination).

  2. Chargement staging (mdm.ingest_personnes) : insertion dans staging.affectation_role_personne et staging.affectation_fonction_personne avec le matricule, le nom et les prénoms de la personne, et le code ou le libellé de la structure, du métier ou de la fonction.

  3. Résolution des références (mdm.reconcile_affectation_role, mdm.reconcile_affectation_fonction, lots sans déclencheur) :

    • personne par matricule dans golden.personne_physique ; pour les fonctions, à défaut, par similarité du nom complet (0,90) ;

    • structure par code, par libellé exact ou par sigle, sur les structures vivantes ; plusieurs structures homonymes (même sigle dans des universités différentes) entraînent le rejet de la ligne avec la liste des candidats ;

    • métier par code ou libellé dans reference.role_metier ; fonction par code, libellé ou similarité (0,8) dans reference.fonction.

  4. Chargement : affectation existante recherchée par (personne, structure, métier ou fonction) sur les lignes vivantes ; mise à jour des dates et du statut si présente, insertion sinon.

  5. Erreurs : une référence non résolue laisse la ligne en ERROR avec le motif (« Structure "X" non trouvée », « Métier/rôle "X" non trouvé », candidats homonymes). Ces lignes restent en staging jusqu’à correction et relance.

5.8. Flux 6 : Consolidation des inscriptions étudiants

Les inscriptions sont modélisées comme des affectations du rôle ETUDIANT, avec un périmètre formation et année académique.

runtime inscriptions

Particularités :

  • Une inscription est une affectation temporaire du rôle ETUDIANT

  • structure_id porte la structure responsable de la formation (UFR, École)

  • date_debut et date_fin bornent la période de l’année académique

  • Deux affectations ETUDIANT simultanées sur des formations différentes permettent le double cursus

  • La succession des affectations ETUDIANT donne la traçabilité du parcours

5.9. Flux 7 : Planification des cours

La planification affecte un enseignant à un élément constitutif pour une année académique, avec des créneaux.

Étapes du flux :

  1. Extraction : section planifications d’un payload academique, déposée par POST /api/v1/bulk/planification ou par le dépôt Excel correspondant, après contrôle du périmètre du déposant (formations de son UFR).

  2. Chargement staging (mdm.ingest_planifications) : insertion dans staging.planification_cours avec formation, EC, enseignant (NPI, matricule, nom), année académique et créneaux.

  3. Rapprochement (mdm.reconcile_planification_cours, par déclencheur) : formation par code ou intitulé ; EC par code puis par libellé dans la formation, sur les EC vivants ; enseignant par NPI, par matricule, puis par nom complet exact lorsqu’il désigne une seule personne ; année académique par code ou libellé. Toute référence non résolue ou ambiguë rejette la ligne avec le motif.

  4. Chargement : planification existante recherchée par (EC, année) ; insertion ou mise à jour dans golden.planification_cours, rattachée à l’offre de l’année lorsqu’elle existe ; les créneaux saisis manuellement sont remplacés intégralement, les créneaux générés sont conservés. Un créneau en chevauchement est ignoré et signalé dans error_message sans rejeter la ligne.

5.10. Orchestration globale

Ordre d’exécution : l’ordre est fixé par mdm.process_import selon le type d’import. Les entités à déclencheur actif sont rapprochées dès leur insertion en staging, dans l’ordre des sections du payload ; les autres le sont en phase RECONCILE.

runtime ordre

Entités et mode de rapprochement :

Entité staging Déclencheur AFTER INSERT Lot en phase RECONCILE

personne_physique, adresse_postale, coordonnees_contact

Oui (auto_reconcile vrai par défaut)

Oui, lignes restantes

structure_organisationnelle, type_structure, formation, unite_enseignement, element_constitutif

Oui

Oui, lignes restantes

grade_enseignant, statut_enseignant, domaine_reesao, specialite, nature_support_cours, type_diplome

Oui

Oui, lignes restantes (type_diplome : déclencheur seul)

corps, mention

Non

Oui

affectation_role_personne, affectation_fonction_personne

Non

Oui

programme_formation, annee_academique

Non (auto_reconcile faux)

Oui

planification_cours

Oui

Non

Les nomenclatures importées (corps, grades, statuts, domaines, mentions, spécialités, natures de support, types de structure, types de diplôme, années académiques) sont consolidées dans le schéma reference ; les autres entités le sont dans le schéma golden.

Fréquence d’exécution :

  • Imports : à la demande, par appel de l’API ; l’outil bdes-migration (CronJob, voir DAT) soumet les personnes par POST /api/v1/bulk/personnes

  • Consolidation : synchrone à l’appel d’import, dans sa transaction

Gestion des erreurs :

Niveau Traitement Trace

Élément du payload

L’élément n’est pas inséré en staging ; le lot continue

mdm.ingest_error (batch_id, référence de l’élément, message, contenu brut)

Ligne staging

Rejet métier (REJECTED) ou exception : statut ERROR avec message ; les autres lignes du lot sont traitées

error_message de la ligne ; vue staging.v_all_errors

Lot d’une entité

Compteurs processed, inserted, updated, skipped, errors

mdm.reconciliation_log

Import

Exception non rattrapée : transaction annulée, appel en erreur

Journal applicatif du service

Rapport

PROCESSED sans erreur, PARTIAL sinon ; message agrégeant les motifs de rejet pour les dépôts UE/EC et planification

Réponse HTTP ; raw.bulk_import.status

Workflow de correction (/api/v1/staging/errors) :

  1. Consultation : liste paginée des lignes ERROR (filtres par entité, lot, source) et détail d’une ligne avec toutes ses colonnes.

  2. Correction : modification des colonnes de la ligne staging (colonnes réelles de la table uniquement), avec auteur et note de correction.

  3. Relance : staging.reset_for_retry remet la ligne en PENDING, puis la fonction unitaire mdm.reconcile_<entité> est appelée pour cette ligne.

  4. Abandon : passage en SKIPPED ; la ligne n’est plus traitée.

6. Vue Déploiement

L’infrastructure Kubernetes et les composants transverses sont documentés dans le DAT - Architecture Physique.

6.1. Vue déploiement bdes-referentiel

deployment referentiel

Le dimensionnement des pods et la configuration Kubernetes sont documentés dans le DAT - Architecture Physique.

6.2. Composants déployés

Composant Rôle

referentiel-api-ms

API REST d’exposition des données référentielles via X-Road ; réception des imports en masse et appel du pipeline de consolidation dans PostgreSQL

bdes-db-migration

Job Kubernetes exécutant les migrations Flyway du schéma referentiel (tables, fonctions PL/pgSQL mdm.*, déclencheurs staging.*). Lancé par le pipeline CI du dépôt bdes-db-migration, indépendamment du déploiement du service

bdes-migration

CronJob d’alimentation (outil Python) qui soumet les données transformées à l’API d’import ; voir DAT

Aucun composant d’exécution n’est dédié au pipeline de consolidation : les transformations sont des fonctions de la base de données, exécutées par PostgreSQL lors de l’appel de l’API d’import.

6.3. Volumes persistants spécifiques

Volume Taille Usage

postgresql-data

100 Gi

Schémas REFERENCE, RAW, STAGING, MDM, GOLDEN, AUDIT

6.4. Exposition

L’API referentiel-api-ms est exposée aux consommateurs externes — administrations et systèmes gouvernementaux — par X-Road Security Server. Les services de la plateforme l’appellent de service à service, avec un compte de service.

6.5. Stratégie de mise à jour

  • referentiel-api : Rolling update (maxUnavailable: 1)

  • Pipeline de consolidation : livraison par migration Flyway (CREATE OR REPLACE des fonctions, CREATE TABLE IF NOT EXISTS), appliquée par le Job bdes-db-migration avant la version du service qui en dépend ; scripts de retour arrière fournis au cas par cas (dossier rollback/ du dépôt)

  • PostgreSQL : Switchover primary/replica (downtime < 30s)

7. Décisions d’architecture

7.1. ADR-001 : Architecture ELT avec transformation PL/pgSQL en base

Contexte : Choix entre ETL externe (Spring Batch, Pentaho), ELT avec un outil de transformation dédié et ELT par fonctions de la base de données.

Décision : Adopter l’ELT avec transformation in-database par des fonctions PL/pgSQL (schéma mdm), livrées par les migrations Flyway et déclenchées par l’API d’import. Les deux autres options, ETL externe et outil de transformation dédié, sont écartées.

Justification :

  • PostgreSQL dispose de capacités de calcul suffisantes pour transformations in-database

  • La consolidation s’exécute dans la transaction de l’import : le client reçoit un rapport complet en réponse à son appel

  • Aucun composant d’exécution ni orchestrateur supplémentaire à exploiter

  • Versionning Git natif des transformations, dans le même dépôt que le schéma (bdes-db-migration)

  • Compétences SQL de l’équipe

Conséquences :

  • Pour : Import et consolidation atomiques (une transaction)

  • Pour : Transformations lisibles en SQL, livrées avec le schéma

  • Pour : Aucun composant à déployer en plus de PostgreSQL et du service

  • Contre : Compétences PL/pgSQL avancées requises

  • Contre : Chaque évolution redéfinit la fonction entière (CREATE OR REPLACE)

  • Contre : Durée de l’appel d’import proportionnelle au volume du lot

Statut : Accepté

7.2. ADR-002 : Architecture multi-schémas (REFERENCE, RAW, STAGING, MDM, GOLDEN, AUDIT)

Contexte : Organisation logique de la base de données référentielle.

Décision : Adopter une architecture à 6 schémas séparés.

Justification :

  • REFERENCE : Nomenclatures (seed et imports referentiel)

  • RAW : Payloads d’import conservés intégralement (raw.bulk_import)

  • STAGING : Une table par entité importée, avec statut de traitement et colonnes de correction

  • MDM : Configuration des sources et des déclencheurs, fonctions du pipeline, journal, provenance

  • GOLDEN : Single Source of Truth, données consolidées

  • AUDIT : Historique des entités JPA (Hibernate Envers)

Conséquences :

  • Pour : Séparation préoccupations claire

  • Pour : Traçabilité (payload conservé, lignes staging conservées avec leur statut, mdm.reconciliation_log, mdm.field_provenance)

  • Pour : Performance (GOLDEN optimisé lectures)

  • Contre : Complexité accrue (6 schémas vs 1)

  • Contre : Croissance continue de raw et staging

Statut : Accepté

7.3. ADR-003 : PostgreSQL

Contexte : Choix SGBD pour référentiel consolidé.

Décision : PostgreSQL 16.

Justification :

  • Données hautement structurées = modèle relationnel optimal

  • ACID requis pour intégrité référentielle

  • Support JSONB pour données semi-structurées (payloads raw, raw_data des tables staging)

  • Open-source sans licensing

  • Écosystème mature (pg_trgm pour la similarité, unaccent pour la normalisation des noms, PL/pgSQL pour le pipeline)

Conséquences :

  • Pour : ACID garanti

  • Pour : Requêtes SQL complexes performantes

  • Pour : Compétences équipe existantes

Statut : Accepté

7.4. ADR-004 : Cache Redis

Contexte : Stratégie cache pour bdes-referentiel-api.

Décision : Utiliser Redis externe.

Justification :

  • Cache distribué partagé entre replicas API = cohérence cache

  • Données référentielles TTL long (24h) = hit rate élevé

  • Observabilité native (redis-exporter Prometheus)

Conséquences :

  • Pour : Cohérence cache multi-pods

  • Contre : Latence réseau Redis (+1-2ms)

  • Contre : Éviction explicite des caches de formations à chaque import académique (écritures hors Hibernate par le pipeline)

Statut : Accepté

7.5. Synthèse décisions

ADR Décision Statut

ADR-001

Architecture ELT, transformation PL/pgSQL en base

Pour : Accepté

ADR-002

6 schémas (REFERENCE, RAW, STAGING, MDM, GOLDEN, AUDIT)

Pour : Accepté

ADR-003

PostgreSQL 16

Pour : Accepté

ADR-004

Cache Redis externe

Pour : Accepté

8. Risques et Dettes techniques

8.1. Risques technologiques

ID Risque Probabilité Impact Mitigation

RISK-001

Déduplication fuzzy matching : Faux positifs
Le rapprochement par similarité de nom peut fusionner des personnes distinctes aux noms proches (homonymes).

Moyenne

Moyen

Clé de nom normalisée (mdm.person_name_key) et départage par l’établissement des affectations ; journal de rapprochement (mdm.reconciliation_log) ; une ligne non départagée est rejetée avec un message de doublon potentiel et reste en staging pour arbitrage, la colonne force_create permettant au correcteur d’imposer la création.

RISK-002

Qualité données sources SI Université
Données extraites peuvent être incomplètes ou incohérentes selon maturité SI source.

Élevée

Moyen

Contrôles bloquants à l’ingestion (champs obligatoires, résolution des références), journal des éléments en défaut (mdm.ingest_error), provenance par champ (mdm.field_provenance), tableau de bord qualité, réunions trimestrielles DCE + universités.

RISK-003

Volumétrie croissante PostgreSQL
Croissance données peut dégrader performances si non anticipée.

Moyenne

Moyen

Alertes Prometheus sur la taille de la base, métriques des requêtes lentes, partitionnement des tables historiques, politique de conservation des zones raw et staging.

RISK-004

Indisponibilité sources SI Université
APIs ou fichiers sources peuvent être temporairement indisponibles.

Moyenne

Faible

Données GOLDEN restent accessibles (obsolètes mais disponibles), TTL cache API 24h.

RISK-005

Dépendance X-Road
X-Road Security Server est le point de passage des consommateurs externes. Une panne les prive d’accès au référentiel.

Faible

Élevé

X-Road déployé en haute disponibilité (2 Security Servers). Les services de la plateforme ne sont pas affectés : ils appellent le référentiel de service à service.

RISK-006

Compétences SQL avancées requises
Les transformations du pipeline sont des fonctions PL/pgSQL et demandent un SQL avancé. Risque si turnover équipe.

Moyenne

Moyen

Formation de l’équipe, transformations versionnées avec le schéma dans bdes-db-migration et revues comme toute migration, fonctions documentées dans le présent STD, aux chapitres « Stratégie de solution » et « Vue d’exécution ».

9. Dictionnaire des données

Ce dictionnaire décrit les tables structurantes du référentiel : le registre des personnes, les affectations qui leur donnent un rôle ou une fonction, l’organigramme des structures, l’offre de formation et ses maquettes, et les nomenclatures dont elles dépendent. Les nomenclatures de typage et les tables de liaison n’y figurent pas.

L’inventaire complet du modèle — cent tables, schéma par schéma, et les cinq fichiers DBML qui en portent le détail colonne par colonne — figure à l’annexe Inventaire du modèle de données. Le schéma lui-même est livré par les migrations Flyway du dépôt bdes-db-migration, qui en est l’autorité. La zone d’atterrissage — schémas RAW et STAGING — est décrite au chapitre « Contexte et périmètre ». L’historique des écritures est porté par Hibernate Envers, dans le schéma AUDIT, et non par des tables d’historique dédiées. Toutes les tables ci-dessous portent en outre le même socle de colonnes de gestion, qui n’est pas répété dans les tableaux : created_at, updated_at, modified_at, modified_by, deleted_at (suppression logique), version (verrou optimiste, bigint non nul, défaut 0), locked, ainsi que created_by (jsonb non nul), last_updated_by et deleted_by (jsonb).

PAYS : Référentiel exhaustif des pays du monde selon la norme ISO 3166. Utilisé pour les nationalités, lieux de naissance, adresses et pièces d’identité, qui le référencent par le code ISO alpha-2.

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

code_iso2

varchar(2)

UNIQUE, NOT NULL

Code ISO 3166-1 alpha-2 (ex: BJ, FR) ; cible des clés étrangères

code_iso3

varchar(3)

UNIQUE, NOT NULL

Code ISO 3166-1 alpha-3 (ex: BEN, FRA)

libelle

varchar(255)

NOT NULL

Nom officiel du pays (ex: Bénin, France)

nationalite

varchar(255)

NOT NULL

Gentilé (ex: Béninois, Français)

actif

boolean

NOT NULL

Indicateur d’activation

DOMAINE_REESAO : Tête de la nomenclature REESAO des domaines d’études (ex: Sciences et Technologies, Sciences Juridiques, Politiques et Administratives). Elle se décline en mentions, puis en spécialités.

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

code

varchar(255)

UNIQUE, NOT NULL

Code du domaine (ex: ST, SJPA, SEG) ; cible des clés étrangères

libelle

varchar(255)

NOT NULL

Intitulé du grand domaine

niveau

integer

NOT NULL

Niveau dans la nomenclature (1 pour le domaine)

actif

boolean

NOT NULL

Indicateur d’activation

SPECIALITE : Niveau le plus fin de la nomenclature REESAO : chaque spécialité se rattache à une mention, elle-même rattachée à un domaine. Permet d’affiner la classification des formations selon le contexte béninois.

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

code

varchar(255)

UNIQUE, NOT NULL

Code spécialité (ex: LLA_SPE_001) ; cible des clés étrangères

libelle

varchar(255)

NOT NULL

Intitulé de la spécialité

mention_code

varchar(255)

FK vers reference.mention (code)

Mention de rattachement

actif

boolean

NOT NULL

Indicateur d’activation

TYPE_DIPLOME : Référentiel des types de diplômes délivrés (Licence, Master, Doctorat, CAPES, etc.).

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

code

varchar(255)

UNIQUE, NOT NULL

Code type (ex: LICENCE, MASTER, DOCTORAT) ; cible des clés étrangères

libelle

varchar(255)

NOT NULL

Intitulé complet (ex: Licence, Master)

sigle

varchar(255)

NOT NULL

Abréviation (ex: LIC, MAS)

actif

boolean

Indicateur d’activation

NIVEAU_DIPLOME : Référentiel des niveaux de qualification, rattachés à un type de diplôme et positionnés dans les grilles LMD et RNCP.

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

code

varchar(255)

UNIQUE, NOT NULL

Code niveau (ex: L1, L3, M2) ; cible des clés étrangères

libelle

varchar(255)

NOT NULL

Intitulé (ex: Licence 3)

niveau_lmd

integer

NOT NULL

Niveau dans le système LMD

niveau_rncp

integer

NOT NULL

Équivalence RNCP

ordre

integer

Rang d’affichage dans la grille

type_diplome_code

varchar(255)

FK vers reference.type_diplome (code)

Type de diplôme auquel le niveau appartient

actif

boolean

NOT NULL

Indicateur d’activation

TYPE_STRUCTURE : Typologie des structures organisationnelles (Université, Faculté, École, Laboratoire, Chaire, etc.).

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

code

varchar(255)

UNIQUE, NOT NULL

Code type (ex: UNIV, CHAI) ; cible des clés étrangères

libelle

varchar(255)

NOT NULL

Intitulé complet

niveau_hierarchique

integer

NOT NULL

Niveau indicatif attaché au type ; le niveau effectif d’une structure est calculé depuis parent_id par la vue golden.v_structure_organisationnelle

actif

boolean

NOT NULL

Indicateur d’activation

STATUT_MATRIMONIAL : Liste des statuts matrimoniaux (Célibataire, Marié(e), Divorcé(e), Veuf/Veuve, etc.).

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

code

varchar(255)

UNIQUE, NOT NULL

Code statut (ex: CELIBATAIRE, MARIE) ; cible des clés étrangères

libelle

varchar(255)

NOT NULL

Intitulé complet

actif

boolean

NOT NULL

Indicateur d’activation

ANNEE_ACADEMIQUE : Référentiel des années académiques, période de référence des offres de formation et des planifications. Un index unique partiel garantit qu’au plus une année porte le statut EN_COURS.

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

code

varchar(255)

UNIQUE, NOT NULL

Code année (ex: 2026-2027) ; cible des clés étrangères

libelle

varchar(255)

NOT NULL

Libellé complet

date_debut

timestamp(6) with time zone

NOT NULL

Début de l’année académique

date_fin

timestamp(6) with time zone

NOT NULL

Fin de l’année académique

statut

varchar(255)

CHECK (EN_COURS, TERMINE, NON_DEMMARRE)

Statut de l’année

PERSONNE_PHYSIQUE : Table centrale du registre des personnes. Elle porte l’identité (nom de famille, prénoms, sexe, date et lieu de naissance), les identifiants pérennes (matricule, npi) et la situation administrative de l’agent (corps, grade, catégorie, classe, échelle, échelon). Le matricule est la clé de rattachement de toutes les tables satellites, qui le suivent par ON UPDATE CASCADE.

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

matricule

varchar(255)

UNIQUE, NOT NULL

Matricule fonctionnel permanent ; cible des clés étrangères des tables satellites

npi

varchar(255)

UNIQUE

Numéro Personnel d’Identification national

nom_famille

varchar(255)

NOT NULL

Nom de famille

nom_usage

varchar(255)

Nom d’usage (nom d’épouse notamment)

prenoms

varchar(255)

NOT NULL

Prénoms

sexe

varchar(255)

NOT NULL

Sexe

civilite

varchar(255)

Civilité

genre_code

varchar(255)

FK vers reference.genre (code), NOT NULL

Genre

date_naissance

timestamp(6) with time zone

Date de naissance

ville_naissance

varchar(255)

Ville de naissance

pays_naissance_code

varchar(2)

FK vers reference.pays (code_iso2)

Pays de naissance

nationalite_code

varchar(2)

FK vers reference.pays (code_iso2), NOT NULL

Nationalité

statut_matrimonial_code

varchar(255)

FK vers reference.statut_matrimonial (code)

Situation matrimoniale

adresse

varchar(255)

Adresse libre saisie sur la fiche

statut

varchar(255)

CHECK (ACTIF, INACTIF), NOT NULL

Validité de la fiche personne

statut_code

varchar(255)

FK vers reference.statut_enseignant (code)

Statut d’enseignant

corps_code

varchar(20)

FK vers reference.corps (code)

Corps d’appartenance

grade_code

varchar(255)

FK vers reference.grade_enseignant (code)

Grade

categorie_code

varchar(10)

FK vers reference.categorie (code)

Catégorie

classe_code

varchar(20)

FK vers reference.classe (code)

Classe

echelle_code

varchar(255)

FK vers reference.echelle (code)

Échelle

echelon_code

varchar(255)

FK vers reference.echelon (code)

Échelon

date_recrutement

timestamp

Date de recrutement

photo_profil

text

Photo de profil

kc_user_id

varchar(255)

UNIQUE si renseigné

Identifiant du compte Keycloak lié à la fiche

PIECE_IDENTITE : Pièces d’identité détenues par une personne. Une personne peut en détenir plusieurs (CNI, passeport, permis), chacune avec ses dates d’émission et d’expiration et son autorité émettrice.

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

personne_matricule

varchar(255)

FK vers golden.personne_physique (matricule) ON UPDATE CASCADE, NOT NULL

Personne titulaire

type_piece_code

bigint

FK vers reference.type_piece_identite, NOT NULL

Type de pièce

numero

varchar(255)

UNIQUE, NOT NULL

Numéro de la pièce

date_emission

timestamp(6) with time zone

NOT NULL

Date d’émission

date_expiration

timestamp(6) with time zone

NOT NULL

Date d’expiration

autorite_emission

varchar(255)

NOT NULL

Autorité émettrice

pays_emission_code

varchar(2)

FK vers reference.pays (code_iso2), NOT NULL

Pays d’émission

COORDONNEES_CONTACT : Moyens de contact d’une personne (emails, téléphones). Gestion multi-contact avec indication du contact principal et bornes de validité.

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

personne_matricule

varchar(255)

FK vers golden.personne_physique (matricule) ON UPDATE CASCADE, NOT NULL

Personne concernée

type_contact_code

varchar(255)

FK vers reference.type_contact (code), NOT NULL

Type de contact

valeur

varchar(255)

NOT NULL

Email, numéro de téléphone, etc.

principal

boolean

NOT NULL

Contact principal pour ce type

date_debut_validite

timestamp(6) with time zone

Début de validité

date_fin_validite

timestamp(6) with time zone

Fin de validité (NULL si actuel)

ADRESSE_POSTALE : Adresses postales d’une personne avec bornes de validité. Support multi-adresses (domicile, administrative, professionnelle) et désignation de l’adresse principale.

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

personne_matricule

varchar(255)

FK vers golden.personne_physique (matricule) ON UPDATE CASCADE, NOT NULL

Personne concernée

type_adresse_code

varchar(255)

FK vers reference.type_adresse (code), NOT NULL

Type d’adresse

numero_voie

varchar(255)

NOT NULL

Numéro de voie

nom_voie

varchar(255)

NOT NULL

Nom de la rue ou de l’avenue

complement

varchar(255)

Complément d’adresse

code_postal

varchar(255)

NOT NULL

Code postal

ville

varchar(255)

NOT NULL

Ville

quartier

varchar(255)

NOT NULL

Quartier ou arrondissement

pays_code

varchar(2)

FK vers reference.pays (code_iso2), NOT NULL

Pays

principale

boolean

NOT NULL

Adresse principale

date_debut_validite

timestamp(6) with time zone

Début de validité

date_fin_validite

timestamp(6) with time zone

Fin de validité

LIEN_PERSONNE : Relations entre personnes (tuteur légal, contact d’urgence, conjoint, parent). Permet de modéliser le réseau relationnel avec sa temporalité. Les deux extrémités référencent le matricule.

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

personne_source_matricule

varchar(255)

FK vers golden.personne_physique (matricule) ON UPDATE CASCADE, NOT NULL

Personne source de la relation

personne_cible_matricule

varchar(255)

FK vers golden.personne_physique (matricule) ON UPDATE CASCADE, NOT NULL

Personne cible de la relation

type_lien_code

varchar(255)

FK vers reference.type_lien_personne (code), NOT NULL

Type de lien

date_debut

timestamp(6) with time zone

NOT NULL

Début de la relation

date_fin

timestamp(6) with time zone

NOT NULL

Fin de la relation

ROLE_METIER : Référentiel des rôles métier dans l’enseignement supérieur. Un rôle représente une casquette fonctionnelle qu’une personne peut endosser (exemple : Enseignant, Étudiant, Chercheur, Personnel administratif, Recteur).

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

code

varchar(255)

UNIQUE, NOT NULL

Code rôle (ex: ENSEIGNANT, ETUDIANT) ; cible des clés étrangères

libelle

varchar(255)

NOT NULL

Intitulé du rôle

description

text

Description détaillée

actif

boolean

NOT NULL

Indicateur d’activation

FONCTION : Référentiel des fonctions organisationnelles (postes de responsabilité). Une fonction représente un poste occupé dans l’organigramme (exemple : Recteur, Vice-Recteur, Directeur UFR, Chef de département).

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

code

varchar(255)

UNIQUE, NOT NULL

Code fonction (ex: RECT, VR_AA) ; cible des clés étrangères

libelle

varchar(255)

NOT NULL

Intitulé de la fonction

description

text

Description détaillée

niveau_hierarchique

integer

NOT NULL

Rang de la fonction dans l’organigramme

actif

boolean

NOT NULL

Indicateur d’activation

AFFECTATION_ROLE_PERSONNE : Affectations des rôles aux personnes avec temporalité et périmètre structurel. Permet de tracer qui a quel rôle, où et quand. Exemple : Jean est Enseignant à la Faculté de Droit de 2020 à 2025, puis Recteur de l’UAC de 2025 à 2030.

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

personne_matricule

varchar(255)

FK vers golden.personne_physique (matricule) ON UPDATE CASCADE, NOT NULL

Personne affectée

metier_code

varchar(255)

FK vers reference.role_metier (code), NOT NULL

Rôle métier affecté

structure_code

varchar(255)

FK vers golden.structure_organisationnelle (code), NOT NULL

Structure de rattachement

date_debut

timestamp(6) with time zone

Date de début d’affectation

date_fin

timestamp(6) with time zone

Date de fin (NULL si en cours)

statut

varchar(255)

CHECK (ACTIF, INACTIF), NOT NULL

Statut de l’affectation

date_affectation

timestamp(6) with time zone

Date administrative de l’affectation

utilisateur_affectation

varchar(255)

Utilisateur ayant créé l’affectation

AFFECTATION_FONCTION_PERSONNE : Affectations des fonctions organisationnelles aux personnes. Similaire aux affectations de rôle, mais avec traçabilité de l’acte de nomination officiel.

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

personne_matricule

varchar(255)

FK vers golden.personne_physique (matricule) ON UPDATE CASCADE, NOT NULL

Personne nommée

fonction_code

varchar(255)

FK vers reference.fonction (code), NOT NULL

Fonction exercée

structure_code

varchar(255)

FK vers golden.structure_organisationnelle (code), NOT NULL

Structure d’exercice

date_debut

timestamp(6) with time zone

Date de prise de fonction

date_fin

timestamp(6) with time zone

Date de fin de fonction

statut

varchar(255)

CHECK (ACTIF, INACTIF), NOT NULL

Statut de la nomination

date_nomination

timestamp(6) with time zone

Date officielle de nomination

acte_nomination

varchar(255)

Référence de l’acte administratif

STRUCTURE_ORGANISATIONNELLE : Table centrale de l’organigramme. Contient toutes les structures quel que soit leur niveau hiérarchique (Université, UFR, Département, Laboratoire, Chaire, etc.). La hiérarchie est matérialisée par l’auto-référence parent_id ; le niveau hiérarchique est calculé à la lecture par la vue golden.v_structure_organisationnelle.

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

code

varchar(255)

UNIQUE, NOT NULL

Code unique structure (ex: UAC, UAC-FDSP) ; cible des clés étrangères

libelle

varchar(255)

NOT NULL

Nom complet de la structure

sigle

varchar(255)

NOT NULL

Sigle ou acronyme (ex: UAC, FDSP)

parent_id

bigint

FK vers golden.structure_organisationnelle (id)

Structure parente directe (NULL pour un établissement autonome)

type_structure_code

varchar(255)

FK vers reference.type_structure (code)

Type de structure

nature_structure_code

varchar(10)

FK vers reference.nature_structure (code)

Nature de la structure (public, privé, etc.)

date_creation

timestamp(6) with time zone

Date de création administrative

date_fermeture

timestamp(6) with time zone

Date de fermeture (si applicable)

statut

varchar(255)

CHECK (ACTIF, INACTIF), NOT NULL

Statut de la structure

adresse

varchar(255)

NOT NULL

Adresse de la structure

telephone

varchar(255)

NOT NULL

Numéro de téléphone

email

varchar(255)

NOT NULL

Email institutionnel

PERIODE_VALIDITE_STRUCTURE : Suivi des périodes d’activité des structures (ouverture, fermeture, réouverture). Permet de tracer l’évolution du paysage institutionnel.

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

structure_code

varchar(255)

FK vers golden.structure_organisationnelle (code), NOT NULL

Structure concernée

date_ouverture

timestamp(6) with time zone

NOT NULL

Date d’ouverture

date_fermeture

timestamp(6) with time zone

NOT NULL

Date de fermeture

motif_fermeture

varchar(255)

Raison de la fermeture

statut

varchar(255)

CHECK (ACTIF, INACTIF), NOT NULL

Statut de la période

DIPLOME : Référentiel des diplômes officiels délivrés par l’enseignement supérieur. Représente le titre obtenu à l’issue d’un cursus (Licence ès Lettres, Master en Droit, Doctorat en Sciences, etc.).

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

type_diplome_code

varchar(255)

FK vers reference.type_diplome (code), NOT NULL

Type (Licence, Master, etc.)

niveau_diplome_code

varchar(255)

FK vers reference.niveau_diplome (code), NOT NULL

Niveau de qualification

intitule

varchar(255)

NOT NULL

Intitulé complet du diplôme

domaine_code

varchar(255)

FK vers reference.domaine_reesao (code), NOT NULL

Domaine REESAO

grade

varchar(255)

NOT NULL

Grade universitaire

statut

varchar(255)

CHECK (ACTIF, INACTIF), NOT NULL

Statut du diplôme

FORMATION : Cursus de formation complet menant à un diplôme. Une formation est un objet permanent (ex : Licence en Droit) dont les déclinaisons datées sont portées par les PROGRAMME_FORMATION.

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

code

varchar(255)

UNIQUE, NOT NULL

Code formation ; cible des clés étrangères

intitule

varchar(255)

NOT NULL

Intitulé complet

type_diplome_code

varchar(255)

FK vers reference.type_diplome (code), NOT NULL

Type de diplôme visé

niveau_diplome_code

varchar(255)

FK vers reference.niveau_diplome (code), NOT NULL

Niveau de qualification

finalite_code

varchar(3)

FK vers reference.finalite_diplome (code)

Finalité du diplôme

voie_code

varchar(1)

FK vers reference.voie_diplome (code)

Voie de formation

habilitation_id

bigint

FK vers golden.habilitation (id)

Habilitation dont relève la formation

duree_annees

integer

NOT NULL

Durée nominale en années

credits_totaux

integer

NOT NULL

Total de crédits requis

date_creation

timestamp(6) with time zone

NOT NULL

Date de création de la formation

statut

varchar(255)

CHECK (ACTIF, INACTIF), NOT NULL

Statut de la formation

decoupage

varchar(30)

Découpage de l’année (SEMESTRIEL, ANNUEL, etc.)

PROGRAMME_FORMATION : Offre de formation : déclinaison d’une formation sur une plage d’années académiques, sous la responsabilité d’une structure. Une contrainte d’exclusion interdit à deux offres non supprimées de la même formation de se chevaucher dans le temps.

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

formation_code

varchar(255)

FK vers golden.formation (code), NOT NULL

Formation déclinée

annee_academique_code

varchar(255)

FK vers reference.annee_academique (code), NOT NULL

Année académique de l’offre

annee_debut_code

varchar(255)

FK vers reference.annee_academique (code), NOT NULL

Première année de validité

annee_fin_code

varchar(255)

FK vers reference.annee_academique (code)

Dernière année de validité (NULL si ouverte)

periode_validite

tstzrange

EXCLUDE (formation_code, periode_validite) si non supprimée

Intervalle de validité calculé depuis les années de début et de fin

date_approbation

timestamp(6) with time zone

NOT NULL

Date d’approbation officielle

structure_responsable_code

varchar(255)

FK vers golden.structure_organisationnelle (code), NOT NULL

Structure responsable

statut

varchar(255)

CHECK (ACTIF, INACTIF), NOT NULL

Statut de l’offre

PARCOURS : Spécialisations au sein d’une formation. Permet de modéliser les parcours différenciés (ex : dans Master Informatique, parcours Big Data ou parcours Cybersécurité).

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

formation_code

varchar(255)

FK vers golden.formation (code), NOT NULL

Formation d’appartenance

code

varchar(255)

UNIQUE, NOT NULL

Code parcours ; cible des clés étrangères

intitule

varchar(255)

NOT NULL

Intitulé du parcours

description

text

Description détaillée

credits_requis

integer

NOT NULL

Crédits spécifiques au parcours

UNITE_ENSEIGNEMENT : Unité d’Enseignement (UE) = regroupement cohérent de cours. Chaque UE est rattachée à une formation, éventuellement à un parcours, et positionnée dans la maquette par la période désignée par semestre_id. Le couple (formation, code) est unique parmi les UE non supprimées.

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

code

varchar(255)

NOT NULL, unique avec formation_code si non supprimée

Code UE ; cible des clés étrangères

intitule

varchar(255)

NOT NULL

Intitulé de l’UE

description

text

Description de l’UE

formation_code

varchar(255)

FK vers golden.formation (code), NOT NULL

Formation d’appartenance

parcours_code

varchar(255)

FK vers golden.parcours (code)

Parcours d’appartenance (optionnel)

semestre_id

bigint

FK vers reference.semestre (id), NOT NULL

Période de positionnement dans la maquette

niveau_id

bigint

FK vers reference.niveau_diplome (id)

Niveau de positionnement

credits

integer

NOT NULL

Crédits de l’UE

coefficient

float4

NOT NULL

Coefficient pour le calcul des moyennes

type_ue

varchar(255)

NOT NULL

Code de la taxonomie pédagogique (fondamentale, méthodologie, etc.)

obligatoire

boolean

NOT NULL

UE obligatoire ou optionnelle

ELEMENT_CONSTITUTIF : Élément Constitutif (EC) = cours individuel au sein d’une UE. C’est le niveau atomique de la maquette pédagogique. Chaque EC définit ses volumes horaires (CM = Cours Magistral, TD = Travaux Dirigés, TP = Travaux Pratiques, TPE = Travail Personnel de l’Étudiant). Le couple (UE, code) est unique parmi les EC non supprimés.

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

code

varchar(255)

NOT NULL, unique avec ue_id si non supprimé

Code EC ; cible des clés étrangères

intitule

varchar(255)

NOT NULL

Intitulé du cours

ue_id

bigint

FK vers golden.unite_enseignement (id), NOT NULL

UE parente

ue_code

varchar(255)

NOT NULL

Code de l’UE parente, conservé dénormalisé

credits

integer

NOT NULL

Crédits de l’EC

volume_horaire_cm

integer

NOT NULL

Volume CM en heures

volume_horaire_td

integer

NOT NULL

Volume TD en heures

volume_horaire_tp

integer

NOT NULL

Volume TP en heures

volume_horaire_tpe

integer

NOT NULL

Volume TPE en heures

PREREQUIS_FORMATION : Conditions d’accès attachées à une formation. Chaque ligne porte un type de prérequis et son caractère strict ou souple pour la formation désignée.

Colonne Type Contraintes Description

id

bigint

PK, généré

Clé primaire technique

unique_id

uuid

UNIQUE, NOT NULL

Identifiant externe stable

formation_code

varchar(255)

FK vers golden.formation (code), NOT NULL

Formation dont l’accès est conditionné

type_prerequis

varchar(255)

NOT NULL

Type de prérequis

obligatoire

boolean

NOT NULL

Prérequis strict ou souple

10. Annexe : inventaire du modèle de données

Le dictionnaire des données décrit les tables structurantes du référentiel. La présente annexe en donne l’inventaire complet, schéma par schéma : cent tables pour les données et leur consolidation, auxquelles s’ajoute l’historique des écritures.

Chaque schéma a son objet. REFERENCE porte les nomenclatures, RAW et STAGING la zone d’atterrissage des données reçues, MDM la configuration du pipeline et ses journaux, GOLDEN les données consolidées, et AUDIT l’historique de leurs écritures. Les schémas de structure figurent au chapitre « Contexte et périmètre », et le fonctionnement du pipeline au chapitre « Vue d’exécution ».

10.1. Schéma GOLDEN : les données consolidées

Vingt-sept tables, groupées par domaine.

10.1.1. Personnes

Table Objet

personne_physique

Fiche d’une personne : identité, état civil, situation administrative. Clé de rattachement : le matricule

personne_physique_specialites

Spécialités d’une personne, vers la nomenclature des spécialités

piece_identite

Pièces d’identité détenues, avec leurs dates de validité

adresse_postale

Adresses d’une personne, dont une principale

coordonnees_contact

Courriels et numéros de téléphone, dont un principal

lien_personne

Relations entre personnes : tuteur, contact d’urgence, conjoint

10.1.2. Structures et affectations

Table Objet

structure_organisationnelle

Organigramme complet. Le rattachement est un parent unique ; le niveau hiérarchique est calculé par la vue v_structure_organisationnelle

periode_validite_structure

Périodes d’ouverture et de fermeture d’une structure

affectation_role_personne

Affectation d’un rôle métier à une personne, dans une structure, sur une période

affectation_fonction_personne

Affectation d’une fonction organisationnelle, avec son acte de nomination

habilitation

Habilitation d’une structure à délivrer une spécialité : numéro, organisme, échéance

10.1.3. Formations, maquettes et planification

Table Objet

diplome

Diplôme délivré, rattaché à un type, un niveau et un domaine

formation

Formation, objet permanent : code, intitulé, niveau, durée, crédits

prerequis_formation

Conditions d’accès attachées à une formation

parcours

Parcours au sein d’une formation

type_parcours

Typologie des parcours

specialites_diplome

Spécialités rattachées à un diplôme

programme_formation

Offre de formation : la formation déclinée sur une plage d’années, sans chevauchement

programme_ue

Rattachement d’une unité d’enseignement à une offre

programme_ec

Rattachement d’un élément constitutif à une unité de l’offre

unite_enseignement

Unité d’enseignement : semestre, crédits, coefficient, type

element_constitutif

Élément constitutif d’une unité : crédits et volumes horaires CM, TD, TP, TPE

element_constitutif_modalite_evaluation

Modalités d’évaluation d’un élément constitutif

element_constitutif_nature_support

Natures de support de cours d’un élément constitutif

planification_cours

Enseignement planifié : un élément constitutif, un enseignant, une année

planification_creneau_type

Créneau récurrent servant de modèle à la génération

planification_creneau

Créneau d’enseignement, généré depuis un modèle ou saisi

10.2. Schéma REFERENCE : les nomenclatures

Trente-neuf tables. Les données consolidées s’y réfèrent par le code de la nomenclature, et par code_iso2 pour les pays.

Famille Tables

Géographie

pays, departement, ville, arrondissement, quartier

Identité des personnes

genre, statut_matrimonial, type_piece_identite, type_lien_personne, type_adresse, type_contact

Carrière

corps, categorie, classe, echelle, echelon, grade_enseignant, statut_enseignant

Rôles et fonctions

fonction, role_metier

Structures

type_structure, nature_structure

Diplômes

type_diplome, niveau_diplome, finalite_diplome, voie_diplome, type_diplome_finalite, type_diplome_voie

Taxonomie REESAO

domaine_reesao, mention, specialite

Pédagogie

type_ue, modalite_evaluation, nature_support_cours

Calendrier

semestre, annee_academique, calendrier_semestre, periode_non_enseignee, jour_ferie

10.3. Schémas RAW et STAGING : la zone d’atterrissage

Le schéma RAW porte deux tables : bulk_import, où le payload reçu est conservé intégralement avec le statut du lot, et bulk_data.

Le schéma STAGING porte vingt-six tables, une par entité importée. Chaque ligne y reçoit son statut de traitement — PENDING, PROCESSING, PROCESSED, ERROR ou SKIPPED — son motif de rejet le cas échéant, et le bloc de correction humaine qui permet de la reprendre.

personne_physique adresse_postale coordonnees_contact structure_organisationnelle

affectation_role_personne

affectation_fonction_personne

annee_academique

corps

categorie

classe

echelle

echelon

statut_matrimonial

grade_enseignant

statut_enseignant

type_structure

type_diplome

domaine_reesao

mention

specialite

nature_support_cours

formation

programme_formation

unite_enseignement

element_constitutif

planification_cours

10.4. Schéma MDM : la configuration du pipeline et ses journaux

Table Objet

source_config

Sources autoritaires déclarées, avec leur niveau de confiance

trigger_config

Entités dont le rapprochement se déclenche à l’insertion

reconciliation_log

Journal des lots traités, par phase et par entité

ingest_error

Éléments en défaut à l’ingestion, avec leur motif et leur contenu reçu

field_provenance

Source et date du dernier apport, champ par champ, pour les personnes

field_history

Historique des valeurs d’un champ

10.5. Schéma AUDIT : l’historique des écritures

L’historique est tenu par Hibernate Envers. Chaque entité auditée porte sa table audit.<entité>_aud, qui reçoit une ligne par révision, et audit.revinfo horodate les révisions. Soixante-six tables d’audit couvrent ainsi les schémas golden et reference.

10.6. Source du modèle

Le modèle est décrit, table par table et colonne par colonne, par cinq fichiers au format DBML, versionnés avec la documentation dans src/docs/dbml/ :

Fichier Tables Contenu

referentiel-personnes.dbml

6

Le registre des personnes et leurs rattachements

referentiel-structures.dbml

5

L’organigramme et les affectations

referentiel-formations.dbml

16

L’offre de formation, les maquettes et la planification

referentiel-nomenclatures.dbml

39

Les nomenclatures du schéma REFERENCE

referentiel-zone-atterrissage.dbml

34

Les schémas RAW, STAGING et MDM

Ces fichiers portent les types, les contraintes et les clés étrangères. Ils se lisent tels quels et se rendent en diagramme par un outil acceptant le format DBML. Les colonnes de gestion communes à presque toutes les tables — identifiant externe, verrou optimiste, dates et auteurs de création, de modification et de suppression — y sont dites une fois, en tête de chaque fichier, plutôt que répétées sur chaque table.

Le schéma lui-même est livré par les migrations Flyway du dépôt bdes-db-migration, qui en est l’autorité : toute évolution y est tracée et rejouable.

11. Glossaire

Le glossaire commun de la plateforme BDES est documenté dans le DAT - Glossaire.