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. Périmètre du document

Ce document décrit les spécifications techniques détaillées du module bdes-evaluation, plateforme pour l’évaluation des enseignants du supérieur au Bénin.

Le contexte général, les parties prenantes et l’architecture transverse sont documentés dans le Document d’Architecture Technique (DAT) :

1.2. Périmètre fonctionnel bdes-evaluation

Le module bdes-evaluation couvre :

  • Campagnes d’évaluation : Création, activation, clôture des campagnes

  • Dossiers enseignants : Constitution, soumission, suivi des dossiers

  • Évaluations pédagogiques : Formulaires anonymes remplis par les étudiants

  • CTE : Commissions Techniques d’Évaluation (assignation, évaluation, signatures)

  • Validation DCE : Validation finale par le Délégué DCE

  • Rapports : Génération de rapports PDF et statistiques

1.3. Objectifs de qualité spécifiques

Priorité Objectif Cible module évaluation

1

Anonymat évaluations

Aucune donnée identifiante collectée lors des évaluations pédagogiques

2

Génération rapports

PDF généré en < 10 secondes pour 1000+ soumissions

3

Mode hors-ligne

Remplissage formulaires offline avec synchronisation différée

4

Codes d’accès

Génération sécurisée, usage unique, invalidation immédiate après soumission

1.4. Interfaces principales

Le module bdes-evaluation :

  • Consomme les données du module bdes-referentiel par appel de service à service (universités, UFR, enseignants)

  • S’authentifie via Keycloak (SSO gouvernemental)

  • Stocke les fichiers enseignants sur MinIO (S3-compatible)

  • Notifie via Kafka → notifications-api-ms → SMTP

2. Contraintes d’Architecture

Les contraintes techniques transverses (PostgreSQL, Spring Boot, Kubernetes, TLS, etc.) sont documentées dans le DAT - Contexte et Enjeux.

2.1. Contraintes métier spécifiques bdes-evaluation

Contrainte Description

Mode hors-ligne

Remplissage des formulaires d’évaluation en mode hors-ligne avec synchronisation ultérieure.

Anonymat des évaluations

Évaluations pédagogiques étudiants : aucune information identifiante collectée ou stockée.

Codes d’accès uniques

Chaque événement d’évaluation génère des codes d’accès uniques, sécurisés et à usage unique.

Versionnement formulaires

Un formulaire publié ne peut pas être modifié. Toute modification crée une nouvelle version.

Périodes d’activation

Évaluations actives uniquement pendant leur période définie. Aucune soumission hors période.

Notifications automatiques

Notifications obligatoires pour les événements critiques (campagne, rappels, résultats).

2.2. Contraintes techniques spécifiques

Contrainte Description

Génération PDF

Rapports PDF générés côté serveur. Bibliothèque : iText ou Apache PDFBox.

Stockage fichiers

Pièces jointes enseignants stockées sur MinIO (S3-compatible), bucket bdes-data. Le plafond par fichier est un paramètre applicatif (file.max-size-mb), réglable depuis l’écran Paramètres et appliqué à toutes les voies de dépôt.

Cache référentiels

Données bdes-referentiel mises en cache Redis (TTL 24h) pour réduire les appels X-ROAD.

3. Contexte et périmètre

3.1. Vue système bdes-evaluation

Diagramme de contexte système BDES Évaluation
Figure 1. Diagramme de contexte système

3.2. Acteurs

Acteur Interactions

Étudiant

Accède aux évaluations via lien + code, soumet formulaires anonymes

Enseignant

Constitue et soumet son dossier, consulte ses résultats

Évaluateur

Évalue les dossiers assignés au sein d’un CTE

Superviseur

Coordonne les CTE, assigne les dossiers aux évaluateurs

Responsable Académique

Consulte les résultats de son périmètre (UFR)

Délégué DCE

Crée les formulaires, valide les dossiers finaux

Administrateur

Administre les utilisateurs et la plateforme

3.3. Systèmes externes

Système Rôle

Keycloak

Authentification SSO, gestion des rôles

bdes-referentiel

Fournit les données référentielles par appel de service à service (universités, enseignants)

ANIP

Validation du NIP (optionnel)

MinIO

Stockage des pièces jointes enseignants (S3-compatible)

SMTP

Envoi des notifications email

3.4. Spécification API

Propriété Valeur

URL de base

https://evaluation-api-ms.dev.api.testbdes.yes.bj

Authentification

Bearer JWT (OAuth2/OIDC via Keycloak)

Format

JSON

Documentation

https://evaluation-api-ms.dev.api.testbdes.yes.bj/scalar.html

Domaines fonctionnels :

  • Evaluations — Gestion des campagnes (CRUD, statuts, formulaires associés)

  • Forms — Gestion des formulaires (CRUD, versioning, publication)

  • Answers — Soumission et consultation des réponses anonymisées

  • Dossiers — Constitution et suivi des dossiers enseignants

  • CTE — Commissions techniques d’évaluation

3.5. Flux de données critiques

Flux Description

Soumission évaluation

Étudiant → code + formulaire → validation période → anonymisation → PostgreSQL

Constitution dossier

Enseignant → upload pièces → MinIO + métadonnées PostgreSQL → soumission

Évaluation CTE

Rapporteur → grille + rapport → signatures membres → notification Délégué

Validation DCE

Délégué → appréciation → signature → notification enseignant

Synchronisation référentiel

evaluation-api-ms → bdes-referentiel, par appel de service à service → cache Redis (TTL 24 h)

4. Stratégie de solution

L’architecture microservices, les patterns de communication et les stratégies de qualité transverses sont documentés dans le DAT - Architecture Applicative.

4.1. Stratégies spécifiques bdes-evaluation

4.1.1. Anonymisation des évaluations pédagogiques

  • Aucune information identifiante collectée lors de la soumission

  • Code d’accès unique par événement d’évaluation (non lié à l’étudiant)

  • Agrégation statistique : résultats présentés uniquement de manière agrégée

  • Stockage anonyme : aucune jointure possible vers l’identité du répondant

4.1.2. Mode hors-ligne

Le module supporte le remplissage offline pour les zones à faible connectivité :

  1. Chargement : Le formulaire est chargé dans le navigateur avec le code d’accès

  2. Remplissage offline : L’utilisateur complète le formulaire sans connexion

  3. Synchronisation : Dès retour de la connexion, les données sont envoyées au serveur

  4. Validation : Le serveur valide le code, la période et enregistre la soumission

4.1.3. Versionnement des formulaires

  • Un formulaire PUBLIÉ est immuable

  • Toute modification crée une nouvelle version

  • Les événements d’évaluation référencent une version spécifique

  • Historique complet conservé pour audit

4.1.4. Génération de rapports PDF

  • Génération côté serveur (Java)

  • Templates prédéfinis par type de rapport

  • Inclusion de graphiques (histogrammes, distributions)

  • Cible : < 10 secondes pour 1000+ soumissions

4.2. Architecture en couches

Chaque microservice du module respecte l’architecture en couches :

Couche Responsabilité

Controllers

Endpoints REST, validation entrées, mapping DTOs

Services

Logique métier, orchestration opérations

Repositories

Accès données via Spring Data JPA

Adapters

Intégration des services d’infrastructure (MinIO, Kafka) et du référentiel

5. Vue en Briques

5.1. Niveau 1 : Conteneurs

Décomposition du système bdes-evaluation en conteneurs déployables indépendamment.

Diagramme de conteneurs BDES Évaluation
Figure 2. Diagramme de conteneurs

5.1.1. Application Web

Interface utilisateur Nuxt.js/Vue.js responsive. Consomme l’API Gateway (HTTPS/JSON) et s’authentifie via Keycloak (OAuth2/OIDC).

5.1.2. API Gateway

Point d’entrée unique (KGateway). Routage vers les services du module, limitation de débit, coupe-circuit. La validation du jeton est faite par chaque service, sur les clés publiques du fournisseur d’identité.

5.1.3. evaluation-api-ms

Domaine évaluation : campagnes, formulaires, réponses, dossiers. Appelle bdes-referentiel de service à service, MinIO pour les fichiers, Kafka pour les évènements.

5.1.4. users-api-ms

Service des comptes et des rôles. Keycloak est la source unique de l’identité ; ce service en tient le reflet local et le maintient à jour :

  • Évènements Keycloak : un Event Listener SPI transmet les créations, modifications et suppressions de comptes, les changements de groupe et les inscriptions. La réception est authentifiée par signature.

  • Synchronisation de rattrapage : un parcours de l’annuaire réaligne le reflet lorsque des évènements ont été perdus, et recense les comptes connus localement mais disparus de l’annuaire.

  • Demandes de rôles : dépôt, approbation ou rejet, puis inscription du rôle dans le groupe Keycloak correspondant et projection vers evaluation-api.

  • Rattachement au Référentiel : lors d’une demande de rôle, l’utilisateur revendique la fiche du Référentiel qui le désigne ; la confirmation propage son matricule et son identifiant national.

La synchronisation va de Keycloak vers ce service, et jamais l’inverse. Le Référentiel n’est pas une source de comptes : c’est une fiche qu’un compte revendique.

5.1.5. notifications-api-ms

Remise des notifications sur deux canaux : le courriel, et le dépôt dans l’application avec poussée en temps réel par WebSocket/STOMP. Consomme les évènements Kafka, répartis sur trois files selon leur priorité, et les déduplique par clé d’idempotence. Le contenu est composé depuis un modèle traduit, avec repli sur le français. Les canaux servis dépendent des préférences du destinataire. L’état de remise est conservé par canal.

L’abonnement en temps réel exige un jeton valide et n’est accordé qu’à la file personnelle du destinataire, à la diffusion générale, ou au canal d’un rôle qu’il porte.

5.1.6. Bases de données

Chaque microservice dispose de sa propre base de données (pattern Database per Service), garantissant l’isolation et l’autonomie des équipes.

evaluation data model core
Figure 3. Modèle de données - Flux d’évaluation
evaluation data model dossier
Figure 4. Modèle de données - Dossier enseignant
users data model
Figure 5. Modèle de données - users-api-ms
notification data model
Figure 6. Modèle de données - notifications-api-ms

5.2. Niveau 2 : Composants

Décomposition interne des microservices. Chaque diagramme présente les contrôleurs REST exposés et leurs dépendances.

5.2.1. evaluation-api-ms

Composants evaluation-api-ms
Figure 7. Composants evaluation-api-ms

5.2.2. users-api-ms

Composants users-api-ms
Figure 8. Composants users-api-ms

5.2.3. notifications-api-ms

Composants notifications-api-ms
Figure 9. Composants notifications-api-ms

5.2.4. Stack technique transverse

  • Security : OAuth2/OIDC (Keycloak)

  • Persistance : Spring Data JPA

  • Messaging : Kafka

  • Discovery : Kubernetes native

6. Vue Exécution

Scénarios d’exécution critiques illustrant les interactions entre composants.

6.1. Scénario 1 : Inscription Utilisateur

register sequence
Figure 10. Flux d’inscription avec validation référentiel

Étapes principales :

  1. L’utilisateur accède à la page d’inscription via Keycloak

  2. Saisie des informations personnelles (nom, email institutionnel, NIP, matricule)

  3. Keycloak valide le domaine email (@gouv.bj, @mesrs.bj, @edu.bj)

  4. Création du compte et envoi de l’email de confirmation

  5. Activation du compte après confirmation

  6. Event Listener SPI Keycloak transmet l’évènement d’inscription à users-api-ms

  7. Création du reflet local : users-api-ms crée l’enregistrement du compte à partir des données portées par l’évènement, sans interroger l’annuaire ni le référentiel. Le matricule et l’identifiant national, s’ils ont été saisis, sont conservés comme attributs du compte

  8. Rattachement au référentiel : il n’intervient pas à l’inscription. Il se produit lors de la première demande de rôle, lorsque l’utilisateur revendique la fiche du référentiel qui le désigne ; la confirmation de cette revendication lie le compte à la fiche

  9. Projection vers Évaluation : elle suit le rôle, non le compte. Un utilisateur sans rôle n’est pas projeté dans evaluation-api-ms, ce qui est un cas normal et non une erreur

Aspects notables :

  • Synchronisation asynchrone via Event Listener SPI, avec signature de l’évènement

  • Le reflet local est alimenté par l’évènement, sans appel sortant

  • Liaison à la fiche du référentiel par revendication, lors de la demande de rôle

  • Le format de l’identifiant national est contrôlé — dix chiffres — sans vérification externe

6.2. Scénario 2 : Authentification Utilisateur

auth sequence
Figure 11. Flux d’authentification via Keycloak

Étapes principales :

  1. L’utilisateur accède à l’application web

  2. L’application web constate l’absence de session et redirige vers Keycloak

  3. L’utilisateur saisit ses credentials (ou utilise SSO si déjà authentifié)

  4. Keycloak valide les credentials et retourne un code d’autorisation

  5. L’application web échange le code contre des tokens JWT (access + refresh)

  6. Toutes les requêtes suivantes incluent l’access token dans l’en-tête Authorization

  7. La passerelle route la requête vers le service visé ; le service valide lui-même le jeton sur les clés publiques du fournisseur d’identité

Aspects notables :

  • Support SSO entre services gouvernementaux

  • Jetons JWT : durée de vie du jeton d’accès de 30 minutes, session SSO expirant après 30 minutes d’inactivité et 10 heures au maximum

  • Refresh automatique transparent

6.3. Scénario 3 : Création d’une Campagne d’Évaluation

campaign create sequence
Figure 12. Flux de création de campagne avec récupération des enseignants

Étapes principales :

  1. Le Délégué DCE accède à l’interface de création de campagne

  2. Saisie des informations de la campagne (intitulé, année académique, période, type d’évaluation)

  3. Sélection des critères de ciblage des enseignants (université, grade, ancienneté, etc.)

  4. Récupération des enseignants depuis BDES Référentiel, par appel de service à service :

    1. Requête avec les critères de filtrage

    2. Retour de la liste des enseignants éligibles avec leurs informations

  5. Pour chaque enseignant retourné :

    1. Vérification si l’enseignant existe dans evaluation-api-ms

    2. Si absent : création automatique avec liaison vers l’identifiant du référentiel (referentiel_user_id)

    3. Si présent : mise à jour des informations si nécessaire

  6. Création de la campagne avec association des enseignants ciblés

  7. Création automatique des dossiers vides pour chaque enseignant

  8. Publication d’un événement Kafka pour notifications

Aspects notables :

  • Récupération en temps réel des enseignants depuis le référentiel

  • Synchronisation automatique enseignants référentiel → évaluation

  • Liaison vers la fiche du référentiel par referentiel_user_id

  • Création automatique des dossiers enseignants

  • Traçabilité complète (audit trail)

6.4. Scénario 4 : Constitution d’un Dossier Enseignant

dossier sequence
Figure 13. Flux de constitution et soumission de dossier

Étapes principales :

  1. L’enseignant accède à son dossier en cours (créé automatiquement lors de la campagne)

  2. Complétion du CV numérique et ajout des publications (3 dernières années)

  3. Dépôt des pièces justificatives dans MinIO, depuis les rubriques du dossier ou depuis une question de type fichier d’un formulaire ; le plafond par fichier est le paramètre applicatif file.max-size-mb

  4. Renseignement des contrats d’enseignement

  5. Validation de la complétude du dossier par le système

  6. Soumission du dossier (statut passe à SOUMIS)

  7. Publication d’un événement Kafka pour notifier le Superviseur

Aspects notables :

  • Stockage sécurisé des fichiers sur MinIO (S3-compatible)

  • Validation de complétude côté serveur (CV, publications, contrats requis)

  • Soumission irréversible (sauf demande de révision par le CTE)

  • Notification asynchrone du Superviseur

6.5. Scénario 5 : Assignation d’un Dossier à un CTE

cte assign sequence
Figure 14. Flux d’assignation avec détection de conflits d’intérêt

Étapes principales :

  1. Le Superviseur consulte les dossiers soumis en attente d’assignation

  2. Sélection d’un dossier et création du CTE (1 à 5 évaluateurs)

  3. Désignation du rapporteur principal parmi les évaluateurs

  4. Le système vérifie les conflits d’intérêt pour chaque évaluateur proposé

  5. Si conflits détectés, le système retourne les raisons et demande d’autres évaluateurs

  6. Si aucun conflit, le CTE est créé et les évaluateurs sont notifiés

Règles de conflit d’intérêt :

  • Même UFR/département que l’enseignant évalué

  • Co-auteur de publications récentes

  • Lien hiérarchique direct

Aspects notables :

  • Détection automatique des conflits d’intérêt

  • Consultation des données Référentiel par appel de service à service

  • Notification asynchrone des évaluateurs via Kafka

6.6. Scénario 6 : Création d’un Événement d’Évaluation Pédagogique

create eval sequence
Figure 15. Flux de création d’événement d’évaluation

Étapes principales :

  1. Le Délégué DCE renseigne la session d’évaluation : formulaire, enseignement visé, période

  2. La passerelle route la requête vers le Service Évaluations, qui valide le jeton et les habilitations qu’il porte

  3. Le Service Évaluations vérifie l’existence et la validité du formulaire sélectionné

  4. Le Service Évaluations vérifie l’existence de la ressource à évaluer (enseignant, cours, etc.)

  5. Génération d’un code d’accès unique, tiré aléatoirement sur un alphabet sans caractères ambigus, de longueur paramétrable ; son unicité est garantie par une contrainte en base

  6. Enregistrement de l’événement en base de données

  7. Publication d’un événement Kafka pour notifications asynchrones

  8. Le système de notifications envoie automatiquement les notifications aux parties prenantes, par courriel et par dépôt dans l’application

Aspects notables :

  • Validation en cascade (formulaire, ressource, période)

  • Code d’accès sécurisé à usage unique

  • Notifications asynchrones via Kafka

  • Transaction atomique avec rollback

  • Audit trail complet

6.7. Scénario 7 : Évaluation par le CTE

cte evaluate sequence
Figure 16. Flux d’évaluation avec signatures multiples

Étapes principales :

  1. Les membres du CTE consultent le dossier complet de l’enseignant

  2. Le CTE vérifie la complétude du dossier

    1. Si incomplet : demande de révision (statut → EVALUATION_REVISION_ENSEIGNANT_REQUISE_CTE), notification enseignant

    2. Si complet : poursuite de l’évaluation

  3. Le rapporteur remplit la grille d’évaluation et rédige le rapport de synthèse

  4. Le rapporteur signe électroniquement son évaluation

  5. Chaque membre du CTE consulte le rapport et signe (accord ou réserve avec observation)

  6. Une fois toutes les signatures collectées, le dossier passe au statut EVALUATION_VALIDATION_CTE

  7. Le Délégué DCE est notifié pour validation finale

Aspects notables :

  • Workflow de signatures multiples (rapporteur + membres)

  • Possibilité d’observations divergentes

  • Traçabilité complète des signatures et horodatage

  • Notification automatique à chaque étape

6.8. Scénario 8 : Soumission d’Évaluation Pédagogique par un Étudiant

submit eval sequence
Figure 17. Flux de soumission d’évaluation

Étapes principales :

  1. L’étudiant accède au lien d’évaluation et saisit le code d’accès fourni

  2. Le système valide le code et vérifie que l’évaluation est dans sa période d’activation

  3. Si valide, le formulaire d’évaluation est affiché

  4. L’étudiant remplit toutes les questions obligatoires

  5. À la soumission, les données sont anonymisées (suppression de toute information identifiante)

  6. La soumission est enregistrée en base de données de manière anonyme

  7. Le code d’accès est immédiatement invalidé (usage unique)

  8. L’écran confirme la prise en compte de la réponse, sans rien enregistrer qui identifie l’étudiant

Aspects notables :

  • Anonymat garanti (aucune donnée identifiante stockée)

  • Validation stricte de la période d’activation

  • Code d’accès à usage unique

  • Validation réponses obligatoires (client et serveur)

  • Reçu anonyme horodaté

6.9. Scénario 9 : Validation Finale par le Délégué DCE

dce validate sequence
Figure 18. Flux de validation DCE avec signature électronique

Étapes principales :

  1. Le Délégué DCE consulte les dossiers au statut EVALUATION_VALIDATION_CTE

  2. Consultation du dossier complet : rapport CTE, évaluations pédagogiques agrégées, signatures

  3. Rédaction de l’appréciation finale

  4. Sélection de la décision : FAVORABLE, DEFAVORABLE ou RESERVES

  5. Signature électronique du Délégué DCE

  6. Le dossier passe au statut EVALUATION_VALIDATION_DCE

  7. La publication à l’enseignant est un geste distinct : le dossier passe alors au statut DISPONIBLE_POUR_ENSEIGNANT et l’enseignant est notifié

Aspects notables :

  • Vue consolidée (dossier + rapport CTE + évaluations pédagogiques)

  • Évaluations pédagogiques présentées de manière agrégée et anonyme

  • Signature électronique obligatoire

  • Décision et commentaire enregistrés dans l’audit trail

  • Notification automatique de l’enseignant

6.10. Scénario 10 : Consultation de ses résultats par l’enseignant

report sequence
Figure 19. Flux de génération de rapport

Étapes principales :

  1. L’enseignant choisit la campagne dont il veut consulter le résultat

  2. Le service ne lui rend que les évaluations de son propre dossier, et seulement celles qui ont été publiées

  3. Il consulte l’évaluation, les signatures de la commission et les rapports qui l’accompagnent

  4. Les pièces jointes sont servies depuis le stockage objet

  5. L’impression du formulaire renseigné se fait depuis le navigateur

Aspects notables :

  • Autorisation par la requête elle-même : propriétaire du dossier, et évaluation publiée

  • Agrégation de données anonymisées pour les évaluations pédagogiques

  • Les analyses chiffrées — moyennes, distributions, comparaisons — et leurs exports relèvent des tableaux de bord décisionnels, alimentés par l’entrepôt de données

7. Vue Déploiement

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

7.1. Vue déploiement bdes-evaluation

Déploiement BDES Évaluation
Figure 20. Diagramme de déploiement - Flux applicatifs

Le dimensionnement des pods, la configuration Kubernetes et les points d’accès sont documentés dans le DAT - Architecture Physique.

7.2. Composants déployés (namespace bdes-evaluation)

Composant Rôle

evaluation-api-ms

API REST principale du module évaluation

users-api-ms

Gestion des utilisateurs, synchronisation Keycloak

notifications-api-ms

Envoi des notifications par courriel et par dépôt dans l’application

Frontend Vue.js

Interface utilisateur SPA

7.3. Dépendances externes

  • PostgreSQL : Base de données bdes_evaluation

  • Kafka : trois files par priorité, <env>.notifications-high, -medium et -low

  • MinIO : bucket bdes-data (pièces des dossiers enseignants)

  • Redis : Cache sessions et données référentielles

  • Keycloak : Authentification OIDC

  • bdes-referentiel : appel de service à service, avec un compte de service

8. Concepts transversaux

Cette section présente les concepts transversaux et les solutions techniques applicables au module bdes-evaluation. Les aspects transversaux à la plateforme BDES sont documentés dans le DAT.

Pour les concepts transversaux à toute la plateforme BDES, consulter le Document d’Architecture Technique (DAT) :

8.1. Sécurité (Spécificités Module Évaluation)

8.1.1. Rôles Applicatifs bdes-evaluation

Le système BDES utilise une gestion centralisée des rôles via Keycloak (voir DAT Sécurité). Les rôles spécifiques au module évaluation sont :

Rôle Permissions module évaluation

ROLE_ETUDIANT

Réponse aux évaluations pédagogiques, de façon anonyme

ROLE_ENSEIGNANT

Consultation/constitution dossier d’évaluation personnel

ROLE_EVALUATEUR

Évaluation des dossiers assignés au sein d’un CTE

ROLE_SUPERVISEUR

Coordination CTE, validation collégiale des rapports

ROLE_DELEGUE

Création formulaires, validation finale DCE

8.1.2. Anonymisation des Évaluations Étudiants

Le module évaluation implémente une anonymisation stricte pour les évaluations pédagogiques :

  • Aucune information identifiante n’est collectée lors de la soumission

  • Code d’accès unique généré par événement d’évaluation (non lié à l’étudiant)

  • Agrégation statistique : résultats présentés uniquement sous forme agrégée

8.2. Gestion des erreurs

Le format de réponse standardisé et les codes d’erreur transverses (ERR-AUTH-, ERR-AUTHZ-) sont documentés dans le DAT - Architecture Applicative.

8.2.1. Codes d’erreur spécifiques bdes-evaluation

Code Description

ERR-EVAL-001

Code d’accès invalide

ERR-EVAL-002

Période d’évaluation expirée

ERR-EVAL-003

Évaluation déjà soumise (code usage unique)

ERR-FORM-001

Formulaire introuvable

ERR-FORM-002

Formulaire inactif ou archivé

ERR-DOSSIER-001

Dossier non trouvé

ERR-DOSSIER-002

Dossier déjà soumis (modification impossible)

ERR-CTE-001

Conflit d’intérêt détecté

ERR-USER-001

NIP invalide

8.3. Logging et Monitoring

La stack de monitoring (Prometheus, Grafana, Loki) est documentée dans le DAT - Exploitation.

8.3.1. Métriques Métier bdes-evaluation

Le module expose des métriques spécifiques via Prometheus :

  • Compteurs métier : bdes_evaluations_created_total, bdes_submissions_total, bdes_reports_generated_total

  • Jauges : bdes_active_campaigns, bdes_pending_evaluations

  • Histogrammes : bdes_pdf_generation_duration_seconds, bdes_campaign_activation_duration_seconds

8.4. Communication inter-services

La matrice des flux détaillée avec les ports et protocoles est documentée dans le DAT - Architecture Fonctionnelle.

8.4.1. Synchrone (REST)

  • APIs REST : JSON over HTTP pour communication request/response

  • Spring RestTemplate / WebClient : clients HTTP avec retry et timeout

8.4.2. Asynchrone (Kafka)

  • Topics Kafka :

    • <env>.notifications-high : évènements à remettre sans délai

    • <env>.notifications-medium : évènements courants

    • <env>.notifications-low : évènements différables

    • audit-logs : événements d’audit pour traçabilité

8.5. Internationalisation (i18n)

  • Support multilingue : Français (FR), Anglais (EN)

  • Messages d’erreur traduits selon locale utilisateur

  • Formats localisés : dates, nombres, devises

  • Gestion via fichiers properties : messages_fr.properties, messages_en.properties

8.6. Validation des données

8.6.1. Validation côté client (Vue.js)

  • Validation temps réel avec feedback immédiat

  • Veevalidate ou Vuelidate pour règles de validation

  • Désactivation bouton soumission si formulaire invalide

8.6.2. Validation côté serveur (Spring Boot)

  • Bean Validation (JSR-380) : annotations @NotNull, @Size, @Email, @Pattern

  • Validations personnalisées : @ValidNIP, @ValidCodeAcces, @ValidPeriode

  • Validation automatique dans controllers via @Valid / @Validated

8.7. Gestion de la configuration

La stratégie de gestion de configuration (Kubernetes Secrets, ConfigMaps, Sealed Secrets) est documentée dans le DAT - Exploitation.

8.7.1. Configuration spécifique bdes-evaluation

  • Profils Spring : dev, staging, prod pour environnements multiples

  • Variables d’environnement : KAFKA_BOOTSTRAP_SERVERS, MINIO_ENDPOINT, KEYCLOAK_ISSUER_URI

  • Paramètres métier : durée validité codes d’accès, seuils anonymisation, délais notifications

8.7.2. Paramètres d’exploitation

Ces réglages sont portés par la table des paramètres applicatifs du service, au même titre que les paramètres métier décrits au SFD, mais ils ne gouvernent aucune règle de gestion : ils conditionnent le comportement du service en exploitation.

Les quatre clés cb.* sont modifiables en base mais exigent un redémarrage du service pour être prises en compte, là où les autres paramètres sont appliqués à chaud.
Clé Ce qu’elle gouverne Valeur

outbox.max.attempts

Nombre d’essais avant qu’une notification parte en file de rattrapage

5

outbox.base.delay.seconds

Délai de base entre deux essais

60 s

outbox.batch.size

Taille d’un lot de reprise

50

outbox.retention.days

Durée de conservation de la file

7 jours

cb.referentiel.wait-duration

Temps d’isolement du référentiel après incident

30 s

cb.referentiel.failure-rate

Taux d’échec déclenchant cet isolement

50 %

cb.notification.wait-duration

Temps d’isolement du service de notification

30 s

cb.notification.failure-rate

Taux d’échec déclenchant cet isolement

50 %

cors.allowed-origins

Origines autorisées à appeler l’API depuis un navigateur

liste des domaines de la plateforme

student_eval_trusted_proxies

Relais de confiance autorisés à déclarer l’adresse d’origine d’un étudiant

aucun
student_eval_trusted_proxies est vide par défaut, ce qui protège d’un en-tête d’origine forgé. La contrepartie est à connaître à l’exploitation : derrière un relais, l’adresse vue par le service est celle du relais, de sorte que le plafond de tentatives par origine est partagé par l’ensemble des étudiants qui passent par ce relais. Les seuils de la limitation de débit sont figés dans le service.

8.8. Résilience et Haute Disponibilité

Les patterns de résilience (Circuit Breaker, Retry, Bulkhead) et la stratégie de haute disponibilité sont documentés dans le DAT - Haute Disponibilité.

8.8.1. Timeouts Spécifiques bdes-evaluation

Opération Timeout

Génération rapport PDF

120 secondes

Calcul agrégation statistiques

60 secondes

Export données campagne

90 secondes

8.9. Gestion des transactions

  • Transactions locales : @Transactional Spring pour opérations single-DB

  • Isolation : READ_COMMITTED par défaut

  • Propagation : REQUIRED (défaut), REQUIRES_NEW pour isolation

  • Rollback : automatique sur RuntimeException, manuel via setRollbackOnly()

8.10. Performance et Optimisation

Aspect Technique Objectif

Caching distribué

Redis pour données référentiels et sessions

Réduire latence et charge DB

Caching local

Caffeine (in-memory)

Accès ultra-rapide données volatiles

Pagination

20 items/page (max 100), curseur ou offset

Limiter charge réseau et mémoire

Lazy loading JPA

@OneToMany(fetch = LAZY) + fetch joins

Éviter requêtes N+1

Indexation DB

Index colonnes WHERE/JOIN, composites multi-critères

Optimiser temps réponse requêtes

8.11. Mode hors-ligne (Offline)

Le système supporte un mode de fonctionnement hors-ligne pour les zones à faible connectivité :

Cette approche garantit :

  • Couverture zones non connectées

  • Intégrité des données (validation multi-niveaux)

  • Audit trail complet (horodatage scan, opérateur, validation)

9. Décisions d’architecture

Les décisions d’architecture transverses (microservices, PostgreSQL, Keycloak, Kafka, etc.) sont documentées dans le DAT.

9.1. Décisions spécifiques bdes-evaluation

ADR Décision Justification et conséquences

ADR-EVAL-001

Anonymisation irréversible

Les évaluations pédagogiques étudiants sont stockées sans aucune information identifiante.
+ Anonymat garanti, conformité RGPD
- Impossible de détecter les soumissions multiples

ADR-EVAL-002

Versionnement formulaires

Un formulaire publié est immuable. Toute modification crée une nouvelle version.
+ Cohérence des évaluations en cours, historique complet
- Prolifération des versions

ADR-EVAL-003

Codes d’accès à usage unique

Chaque code d’accès est invalidé après soumission.
+ Sécurité renforcée, empêche réutilisation
- Nécessite génération de nouveaux codes si problème

ADR-EVAL-004

Stockage fichiers sur MinIO

Les pièces jointes enseignants sont stockées sur MinIO (S3-compatible) plutôt qu’en base.
+ Scalabilité, performance, versioning natif
- Dépendance supplémentaire

ADR-EVAL-005

Cache référentiel Redis

Les données bdes-referentiel sont mises en cache Redis avec TTL 24h.
+ Réduction de la latence et de la charge sur le référentiel
- Données potentiellement obsolètes (acceptable pour référentiels)

ADR-EVAL-006

Génération PDF côté serveur

Les rapports PDF sont générés côté serveur (Java) et non côté client.
+ Contrôle qualité, templates uniformes, sécurité
- Charge serveur, timeout pour gros rapports

10. Glossaire

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