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

La plateforme BDES actuelle repose sur Drupal 9 et doit être migrée vers une nouvelle architecture moderne basée sur Spring Boot (backend) et Vue.js (frontend). Cette migration nécessite une stratégie claire pour assurer la continuité des données tout en améliorant leur qualité et leur cohérence.

1.2. Objectif du document

Ce document présente la stratégie de migration des données de l’ancienne plateforme Drupal vers la nouvelle plateforme BDES. Il détaille les choix techniques, les règles de transformation appliquées, et les recommandations pour garantir une migration réussie.

1.3. Périmètre de la migration

La migration concerne :

  • Les utilisateurs : Chargement dans Keycloak avec leurs rôles Drupal

  • Les enseignants : Chargement dans la table personne du référentiel

  • Les fichiers : Migration vers MinIO avec organisation par enseignant

  • Les données référentielles :

    • Extraction depuis les formulaires DCE (données Golden)

    • Intégration de données depuis API/services publics (pays, sexe, etc.)

Les évaluations existantes (formulaires KoboToolbox) ne seront pas migrées en raison de l’incompatibilité technique avec le nouveau système (SurveyJS). Ces données historiques resteront consultables dans l’ancien système.

2. État des Données Actuelles

2.1. Volume et complétude

La base de données actuelle contient :

  • 93 utilisateurs au total (uid 0 à 93)

  • Fichiers stockés dans le répertoire public://

  • Fichiers téléversés : Documents PDF, images, CV, publications

Complétude insuffisante : La base de données actuelle n’est pas représentative de l’ensemble des enseignants du Bénin. Elle nécessite d’être complétée avant ou après la migration pour assurer une couverture exhaustive.

2.2. Qualité des données

L’analyse des données existantes révèle plusieurs problèmes de qualité :

  • Noms non standardisés : Casse mixte, formats variés

  • Emails hétérogènes : Domaines variés détectés dans la base :

    • @gmail.com (68 occurrences)

    • @yahoo.fr (41 occurrences)

    • @hotmail.com (8 occurrences)

    • @uac.bj (4 occurrences - Université d’Abomey-Calavi)

    • @yahoo.com (4 occurrences)

    • @gouv.bj (2 occurrences)

    • @presidence.bj (2 occurrences)

    • @fa-up.bj (1 occurrence - Faculté d’Agronomie)

    • Domaines temporaires de test (gufum.com, vafyxh.com, bltiwd.com, exoular.com)

  • Utilisateurs sans email : Certains comptes n’ont pas d’adresse email (ex: user "DCE", "Delegues")

  • Données référentielles incomplètes : Nomenclatures non harmonisées

3. Stratégie de Migration des Utilisateurs

3.1. Règles de transformation des identifiants

3.1.1. Noms d’utilisateur

Règle appliquée : Extraction du radical de l’email

Email : armandbienvenugbangboche_ab@gmail.com
Username : armandbienvenugbangboche_ab

Justification : Standardisation des identifiants pour faciliter la gestion et éviter les doublons.

3.1.2. Cas des utilisateurs sans email

Les utilisateurs sans adresse email ne seront pas migrés automatiquement.

Actions à prévoir :

  1. Génération d’une liste des utilisateurs sans email

  2. Traitement manuel par l’administration :

    • Collecte des adresses email manquantes

    • Création manuelle des comptes après migration

  3. Communication auprès des enseignants concernés

3.1.3. Migration vers Keycloak

Tous les utilisateurs ayant un email seront chargés dans Keycloak :

  • Import des comptes : Création des utilisateurs avec leur email comme identifiant

  • Migration des rôles : Les rôles Drupal seront mappés vers les rôles Keycloak

  • Gestion de l’authentification : Keycloak devient le système d’authentification unique (SSO) pour la nouvelle plateforme

3.2. Normalisation des noms

3.2.1. Règle de casse

Pour garantir la cohérence et faciliter les recherches :

  • Nom de famille : MAJUSCULES

  • Prénom : Première lettre majuscule (Title Case)

Exemple :

Avant : Armand Bienvenu Gbangboche
Après : Armand Bienvenu GBANGBOCHE

3.2.2. Suppression des espaces superflus

Tous les espaces en début et fin de chaîne sont supprimés, et les espaces multiples sont réduits à un seul espace.

3.3. Gestion des domaines email

3.3.1. Situation actuelle

Les emails des enseignants utilisent des domaines variés :

  • Fournisseurs grand public : @yahoo.fr, @gmail.com, @hotmail.com, @yahoo.com

  • Domaines institutionnels : @gouv.bj, @presidence.bj

  • Domaines universitaires : @uac.bj, @fa-up.bj (très minoritaires)

3.3.2. Stratégie retenue

Migration à l’identique : Les emails sont migrés tels quels, sans modification du domaine.

Recommandation future : Harmoniser progressivement vers des emails institutionnels (@uac.bj, @unstim.bj, etc.) pour :

  • Renforcer la crédibilité professionnelle

  • Faciliter la gestion administrative

  • Améliorer la traçabilité institutionnelle

Cette harmonisation devra être coordonnée avec les universités et le Ministère.

3.4. Migration des enseignants vers le référentiel

Les utilisateurs identifiés comme enseignants dans Drupal seront également chargés dans la table personne du module référentiel :

  • Rôle : ENSEIGNANT

  • Données : Nom, prénom, email, informations professionnelles

  • Lien avec Keycloak : Référence vers le compte Keycloak via l’email

Cette double saisie (Keycloak + Référentiel) permet :

  • Keycloak : Gestion de l’authentification et des autorisations

  • Référentiel : Gestion des données métier des enseignants (affectations, publications, dossiers)

4. Stratégie de Migration des Fichiers

4.1. Périmètre

Les fichiers à migrer sont stockés dans le répertoire public:// de Drupal et comprennent :

  • Documents PDF (décrets, politiques, rapports)

  • Images (slides, photos d’événements)

  • CV et dossiers des enseignants

  • Publications scientifiques

4.2. Règles de migration

4.2.1. Conservation des métadonnées

Chaque fichier migré conserve :

  • Propriétaire : Association avec le dossier enseignant

  • Date de téléversement : Date d’origine si disponible

  • Nom du fichier : Nom d’origine (avec nettoyage si nécessaire)

  • Type MIME : Pour validation du format

4.2.2. Organisation dans le nouveau système

Les fichiers seront migrés vers MinIO (stockage objet S3-compatible) avec l’organisation suivante :

  • Bucket : bdes-files

  • Organisation par enseignant : /{teacher_id}/

    • Chaque enseignant dispose d’un répertoire identifié par son teacher_id

    • Exemple : /42/cv.pdf, /42/publications/article-2023.pdf

  • Préservation de la structure : Les sous-répertoires sont conservés si nécessaire

4.3. Validation et contrôle qualité

Après migration, un contrôle sera effectué pour :

  • Vérifier l’intégrité des fichiers (taille, checksum)

  • Valider l’association correcte avec les propriétaires

  • Identifier les fichiers orphelins (sans propriétaire identifié)

5. Gestion des Données Non Migrées

5.1. Évaluations existantes (KoboToolbox)

5.1.1. Raison de la non-migration

Les formulaires d’évaluation actuels utilisent KoboToolbox, incompatible avec le nouveau système basé sur SurveyJS.

Différences techniques majeures :

  • Structure de données différente

  • Format JSON incompatible

  • Logique de questions/réponses distincte

5.1.2. Solution retenue

  • Conservation : Les données historiques restent dans l’ancien système Drupal

  • Consultation : Accès en lecture seule pour référence

  • Archivage : Export des données au format PDF/Excel pour archivage légal

Les nouvelles évaluations démarreront sur la nouvelle plateforme avec des formulaires SurveyJS. L’historique sera accessible via des rapports consolidés.

6. Migration des Données Référentielles

6.1. Source des données

6.1.1. Données Golden de la DCE

Les données des formulaires actuels de la DCE serviront de données Golden (référence) au démarrage :

  • Extraction des nomenclatures existantes (universités, UFR, domaines, spécialités)

  • Utilisation comme base initiale du référentiel

  • Nettoyage et harmonisation avant intégration

6.1.2. Services publics et API externes

Certaines données référentielles seront récupérées depuis des API ou services publics :

Donnée référentielle Source Type d’intégration

Pays

API publique (REST Countries, ISO 3166)

Intégration automatique

Sexe / Genre

Liste standardisée (ISO 5218)

Données statiques

Types de pièces d’identité

Nomenclature nationale

Données statiques

Types de contacts

Liste standardisée (email, téléphone, adresse)

Données statiques

6.2. Gestion du référentiel

6.2.1. Principe de gouvernance

Pas d’interface de gestion dans la plateforme BDES pour les données référentielles.

Justification :

  • Éviter les modifications anarchiques

  • Garantir la cohérence avec les sources officielles

  • Responsabiliser les sources autoritaires

6.2.2. Sources autoritaires

Les données référentielles ne peuvent être modifiées que par leurs sources officielles :

Donnée référentielle Source autoritaire Modalité de mise à jour

Universités

Ministère de l’Enseignement Supérieur

Import fichier ou API SI Ministère

UFR / Facultés

Universités

Import fichier ou API SI Universitaires

Enseignants

Universités

Import fichier ou API SI Universitaires

Domaines de recherche

Conseil National de la Recherche

Import manuel contrôlé

Si les SI sources (Ministère, Universités) exposent leurs données sur X-ROAD, la plateforme BDES consommera ces services. Sinon, l’intégration se fera par import de fichiers (CSV, Excel) ou via des API REST dédiées.

6.2.3. Processus de mise à jour

  1. Détection : Une modification est nécessaire (nouvelle université, nouveau domaine)

  2. Demande : La DCE émet une demande auprès de la source autoritaire

  3. Validation : La source autoritaire valide et transmet les données

  4. Intégration : Les données sont intégrées via API, import fichier, ou X-ROAD (si disponible)

  5. Notification : Les utilisateurs concernés sont notifiés de la mise à jour

7. Recommandations pour une Migration Réussie

7.1. Avant la migration

Actions préparatoires :

  1. Compléter la base de données : Ajouter les enseignants manquants avant migration

  2. Nettoyer les données : Supprimer les comptes de test, les doublons

  3. Collecter les emails manquants : Contacter les enseignants sans email

  4. Extraire les données Golden : Analyser et nettoyer les données des formulaires DCE

  5. Préparer Keycloak : Configurer le realm, les rôles, les clients OAuth2

  6. Intégrer les référentiels publics : Charger les données depuis les API (pays, sexe, etc.)

  7. Sauvegarder : Effectuer une sauvegarde complète de la base Drupal

7.2. Pendant la migration

  • Migration en plusieurs phases :

    1. Données référentielles (Golden + API publiques)

    2. Utilisateurs vers Keycloak (avec rôles Drupal)

    3. Enseignants vers table personne du référentiel

    4. Fichiers vers MinIO

  • Tests de validation : Vérifier l’intégrité des données à chaque phase

  • Traçabilité : Enregistrer tous les logs de migration pour audit

7.3. Après la migration

  • Contrôle qualité : Vérifier un échantillon représentatif de comptes et fichiers

  • Communication : Informer les enseignants de la nouvelle plateforme et des changements d’identifiants

  • Support : Mettre en place un support pour accompagner les utilisateurs

  • Harmonisation progressive : Planifier l’harmonisation des emails vers des domaines institutionnels

8. Conclusion

Ce document définit la stratégie de migration des données de l’ancienne plateforme Drupal vers la nouvelle architecture BDES. Les points clés sont :

  • Migration sélective : Seuls les utilisateurs avec email, les enseignants et leurs fichiers seront migrés

  • Keycloak comme référentiel d’identités : Centralisation de l’authentification SSO

  • MinIO pour le stockage : Organisation des fichiers par enseignant

  • Données Golden DCE : Base initiale du référentiel à compléter par les sources autoritaires

  • Évaluations non migrées : Conservation en lecture seule dans l’ancien système

La réussite de cette migration dépend de la préparation des données (nettoyage, collecte des emails manquants) et de la coordination avec les parties prenantes (DCE, universités, Ministère).