Historique des versions

Version Date Rédacteur Description

1.0.0

18/06/2026

Équipe Technique

Version initiale

1.1.0

11/10/2026

Équipe Technique

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

Diffusion

Destinataires Pour validation Pour information

COPIL

X

Validation

Représentants Valideur Date

DCE

MND

ASIN

MESRS - DSI

UNIVERSITÉS - DSI

DSI Présidence

1. Introduction

1.1. Contexte et problématique métier

Le système d’évaluation des enseignants du supérieur au Bénin repose actuellement sur une plateforme basée sur Drupal (CMS) couplée à l’application Toolbox. Les formulaires d’évaluation sont extraits en PDF pour un remplissage hors ligne, puis téléversés dans le portail.

Limites du système actuel :

  • Processus hybride papier/numérique (formulaires PDF remplis hors ligne)

  • Workflow partiellement numérisé avec signature physique des documents finaux

  • Détection manuelle des conflits d’intérêt lors de l’affectation des évaluateurs

  • Difficultés à garantir l’anonymat des évaluations pédagogiques par les étudiants

  • Intégration limitée avec les systèmes référentiels

Problèmes identifiés :

  • Délais de traitement liés au processus hybride

  • Risques de versions multiples des documents PDF

  • Saisie manuelle des résultats d’évaluations étudiantes

  • Difficulté à produire des statistiques consolidées en temps réel

  • Manque de traçabilité complète du workflow

Solution proposée :

La plateforme bdes-evaluation digitalise l’ensemble du processus d’évaluation des enseignants, depuis la constitution des dossiers jusqu’à la validation finale par la DCE, en garantissant traçabilité, transparence et confidentialité.

1.2. Objectifs du projet

1.2.1. Objectif 1 : Digitaliser le processus d’évaluation

Remplacer le système d’évaluation manuel et fragmenté par une plateforme numérique permettant l’évaluation continue et systématique des enseignants du supérieur.

1.2.2. Objectif 2 : Garantir l’anonymat des évaluations pédagogiques

Permettre aux étudiants d’évaluer anonymement leurs enseignants tout en garantissant l’unicité des évaluations (un étudiant = une évaluation par enseignant).

1.2.3. Objectif 3 : Assurer l’interopérabilité avec le référentiel

Consommer automatiquement les données de référence (établissements, enseignants, programmes) depuis bdes-referentiel.

L’échange emprunte un appel de service à service, authentifié par un compte de service, X-ROAD étant la voie des consommateurs externes du référentiel. Il n’est pas en lecture seule : la plateforme alimente le référentiel en maquettes de formation et en planifications des enseignements, par ce même compte de service et par lui seul.

1.3. Périmètre

1.3.1. In-Scope (Inclus)

La plateforme bdes-evaluation couvre :

  • Gestion des campagnes : Création, planification et suivi des campagnes d’évaluation

  • Dossiers d’évaluation : Constitution, soumission et suivi des dossiers enseignants

  • Commissions d’évaluation (CTE) : Constitution et coordination des Commissions Techniques d’Évaluation

  • Évaluations pédagogiques : Collecte anonyme des évaluations par les étudiants

  • Formulaires d’évaluation : Création et gestion des grilles d’évaluation standardisées

  • Validation finale : Circuit de validation avec signature électronique DCE

  • Tableaux de bord : Synthèses et indicateurs pour le pilotage

  • Notifications : Alertes automatiques aux différents acteurs

  • Comptes et rôles : Reflet des comptes du fournisseur d’identité, demandes de rôles et attribution des habilitations

  • Planification des enseignements : Saisie et import des enseignements et du calendrier académique, dont le référentiel est alimenté

  • Visites de terrain : Planification et suivi des visites des évaluateurs auprès des enseignants évalués

  • Rapports d’experts : Modèles, rédaction, signature et validation des rapports individuels et conjoints

  • Paramétrage applicatif : Réglage des valeurs qui gouvernent les règles de gestion, sans livraison

1.3.2. Out-of-Scope (Exclus)

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

  • Gestion administrative des étudiants (géré par les établissements)

  • Gestion de la paie et des carrières des enseignants

  • Système de notation et bulletins des étudiants

  • Constitution des données de référence — structures, personnes, offres de formation — qui relève de bdes-referentiel et de ses sources

  • Authentification et politique de mot de passe, portées par le fournisseur d’identité

Deux exclusions ont été levées. La programmation des cours est désormais couverte : la plateforme porte la saisie et l’import des enseignements et du calendrier académique. Et l’exclusion des données de référence ne vaut plus pour les maquettes de formation ni pour les planifications, que la plateforme écrit dans le référentiel par le compte de service. Pour tout le reste, le référentiel demeure la source : aucun écran de la plateforme n’écrit ses données consolidées. La correction des lignes rejetées lors d’une alimentation fait exception et s’exerce depuis un écran, mais elle porte sur la zone de préparation, avant consolidation, et non sur la donnée de référence elle-même.

1.4. Glossaire et terminologie métier

Terme Définition

Campagne d’évaluation

Période définie pendant laquelle un groupe d’enseignants est évalué selon un processus structuré.

Code d’anonymat

Code unique généré par le système permettant à un étudiant d’évaluer un enseignant sans révéler son identité.

CTE

Commission Technique d’Évaluation. Groupe d’évaluateurs chargé d’évaluer un dossier d’enseignant ; son effectif actif est borné par deux paramètres applicatifs, aujourd’hui de trois à cinq.

DCE

Délégation au Contrôle et à l’Éthique. Commanditaire du projet et valideur final des évaluations.

Délégué DCE

Membre de la DCE responsable de la gestion des campagnes et de la validation finale.

Dossier d’évaluation

Ensemble des documents et informations soumis par un enseignant (CV, publications, contrats).

Enseignant

Membre du corps enseignant faisant l’objet d’une évaluation (titulaire, contractuel, vacataire).

Évaluateur

Enseignant-chercheur ou expert désigné pour évaluer les dossiers de pairs.

Évaluation pédagogique

Évaluation anonyme de la qualité de l’enseignement réalisée par les étudiants.

Expertise

Domaine de compétence d’un évaluateur, choisi dans la nomenclature du référentiel. La voie par laquelle il intervient — expert matière, expert pédagogue ou enquêteur — en est distincte.

Formulaire d’évaluation

Grille structurée en sections et critères permettant d’évaluer un enseignant de manière standardisée.

Rapporteur

Membre de la CTE, responsable de la synthèse et du rapport final.

Responsable Académique

Chef de département ou vice-doyen en charge du suivi des enseignants.

Statut de dossier

État d’un dossier dans le processus d’évaluation. Les états et les passages de l’un à l’autre sont décrits au chapitre des fonctionnalités, qui fait foi ; ils sont plus nombreux que les grandes étapes du processus, chaque acteur ayant son propre état d’attente.

Validation finale

Dernière étape où le délégué DCE rédige l’appréciation finale et signe électroniquement.

X-ROAD

Plateforme nationale d’interopérabilité pour l’échange sécurisé de données entre administrations.

2. Parties prenantes et Utilisateurs

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

2.1. Attentes clés par groupe

2.1.1. Commanditaire et Décideurs (DCE, MESRS)

  • Visibilité sur l’avancement des campagnes d’évaluation

  • Tableaux de bord de pilotage en temps réel

  • Traçabilité complète du processus d’évaluation

  • Conformité aux exigences réglementaires

2.1.2. Acteurs de l’évaluation (Délégués, Superviseurs, Évaluateurs)

  • Interface intuitive pour gérer les campagnes et dossiers

  • Outils de constitution et coordination des CTE

  • Grilles d’évaluation standardisées et configurables

  • Workflow de validation clair et efficace

2.1.3. Enseignants évalués

  • Processus de constitution de dossier simple et guidé

  • Visibilité sur l’état d’avancement de leur évaluation

  • Accès aux retours et recommandations

  • Confidentialité des informations personnelles

2.1.4. Étudiants

  • Processus d’évaluation simple et rapide

  • Garantie absolue de l’anonymat

  • Confiance dans l’utilisation constructive des retours

2.1.5. Opérationnels (Administrateurs, IT-NUM)

  • Interface d’administration ergonomique

  • Outils de supervision et monitoring

  • Documentation technique complète

3. Vue d’ensemble fonctionnelle

3.1. Diagramme de contexte

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

sfd eval context global
Figure 1. Diagramme de contexte

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

  • Entrées : Données référentielles (via bdes-referentiel), enseignants, établissements, cours, organisme, etc.

  • Sorties : Rapports d’évaluation validés, statistiques, notifications

  • Acteurs : Délégués DCE, Enseignants, Évaluateurs, Étudiants, Superviseurs, Administrateur

3.2. Cartographie des processus métier impactés

3.2.1. Processus AVANT (situation actuelle)

Le processus actuel s’appuie sur deux outils : Drupal (portail web) et Toolbox (application de gestion). Les formulaires sont extraits en PDF pour un remplissage hors ligne.

Processus Description actuelle Problèmes

Constitution dossier

Formulaires PDF extraits de Toolbox, remplis hors ligne puis téléversés dans Drupal

Processus hybride, risque de versions multiples, délais de traitement

Affectation évaluateurs

Gestion via Toolbox sans détection automatique des conflits d’intérêt

Risque de biais, vérification manuelle chronophage

Évaluations étudiantes

Formulaires PDF distribués aux étudiants

Anonymat difficile à garantir, saisie manuelle des résultats

Validation DCE

Workflow partiellement numérisé (Drupal), signature physique des documents finaux

Processus mixte papier/numérique, délais de circulation

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

Processus Description Bénéfices

Constitution dossier

Saisie en ligne avec pièces jointes numériques

Complétude garantie, traçabilité

Affectation évaluateurs

Affectation assistée ; un évaluateur ne peut jamais être affecté au dossier dont il est le propriétaire

Objectivité, traçabilité

Évaluation CTE

Grilles en ligne, rapports collaboratifs

Efficacité, standardisation

Évaluations étudiantes

Codes anonymes, formulaires en ligne

Anonymat garanti, participation accrue

Validation DCE

Signature électronique, workflow dématérialisé

Rapidité, traçabilité

3.3. Processus complet d’évaluation

Le processus d’évaluation bout-en-bout se décompose en 6 flux principaux, depuis la création de la campagne jusqu’à la consultation des résultats par l’enseignant.

sfd eval processus complet
Figure 2. Processus bout-en-bout

3.4. Flux de valeur principaux

3.4.1. Flux #1 : Création d’une campagne

Ce flux décrit la création et l’activation d’une campagne d’évaluation par le Délégué DCE.

Acteurs : Délégué DCE, Système

Transitions de statut :

  • Campagne : (création) → PLANIFIEE → ACTIVE

  • Dossier : (création automatique) → EN_COURS

Étapes :

  1. Le Délégué DCE crée la campagne (statut := PLANIFIEE)

  2. Le Délégué DCE publie la campagne (statut := ACTIVE)

  3. Le système crée automatiquement les dossiers pour chaque enseignant sélectionné (statut := EN_COURS)

  4. Le système notifie les enseignants concernés

3.4.2. Flux #2 : Constitution et soumission d’un dossier

Ce flux décrit la constitution du dossier par l’enseignant et sa soumission pour évaluation.

Acteurs : Enseignant, Système

Transitions de statut :

  • Dossier : EN_COURS → SOUMIS

Étapes :

  1. L’enseignant constitue son dossier (CV, publications, contrats, pièces justificatives)

  2. L’enseignant soumet son dossier (statut := SOUMIS)

  3. Le système notifie le Superviseur

3.4.3. Flux #3 : Assignation d’un dossier à un CTE

Ce flux décrit la création du Commission Technique d’Évaluation et l’assignation du dossier.

Acteurs : Superviseur, Système

Étapes :

  1. Le Superviseur crée La CTE

  2. Le Superviseur ajoute les membres, dans les bornes d’effectif fixées par paramètre

  3. Le Superviseur désigne le rapporteur principal

  4. Le Superviseur assigne le dossier à la CTE

  5. Le système vérifie les conflits d’intérêt

  6. Le système notifie les membres de la CTE

3.4.4. Flux #4 : Évaluation par La CTE

Ce flux décrit l’évaluation du dossier par les membres de la CTE.

Acteurs : CTE (Rapporteur et membres), Système

Transitions de statut :

  • Dossier : ASSIGNE_POUR_EVALUATION_CTE → EVALUATION_EN_COURS_CTE (ouverture de l’évaluation)

  • Dossier : EVALUATION_EN_COURS_CTE → EVALUATION_REMPLISSAGE_TERMINE (si le dossier est complet)

  • Dossier : EVALUATION_EN_COURS_CTE → EVALUATION_REVISION_ENSEIGNANT_REQUISE_CTE (si le dossier est incomplet)

Étapes :

  1. La commission ouvre l’évaluation du dossier qui lui a été affecté

  2. Si dossier complet :

    • La commission remplit la grille d’évaluation

    • La commission achève le remplissage (statut := EVALUATION_REMPLISSAGE_TERMINE)

    • Les membres signent, ce qui ouvre la phase de validation

    • Le système notifie le Délégué DCE

  3. Si dossier incomplet :

    • La commission demande une révision (statut := EVALUATION_REVISION_ENSEIGNANT_REQUISE_CTE)

    • Le système notifie l’enseignant

    • L’enseignant complète et re-soumet, et le dossier revient à EVALUATION_EN_COURS_CTE

3.4.5. Flux #5 : Validation par le Délégué DCE

Ce flux décrit la validation finale et la publication de la décision.

Acteurs : Délégué DCE, Système

Transitions de statut :

  • Dossier : EVALUATION_VALIDATION_CTE → EVALUATION_VALIDATION_DCE (validation)

  • Dossier : EVALUATION_VALIDATION_DCE → DISPONIBLE_POUR_ENSEIGNANT (publication)

  • Campagne : ACTIVE → TERMINEE → ARCHIVEE

Étapes :

  1. Le Délégué DCE consulte le dossier et le rapport de la commission

  2. Le Délégué DCE valide l’évaluation (statut := EVALUATION_VALIDATION_DCE)

  3. Le Délégué DCE publie la décision à l’enseignant (statut := DISPONIBLE_POUR_ENSEIGNANT)

  4. Le système notifie l’enseignant

  5. La campagne passe à TERMINEE à sa date de fin, ou par décision du Délégué DCE

  6. Le Délégué DCE peut archiver la campagne (statut := ARCHIVEE)

La validation par la DCE et la publication à l’enseignant sont deux gestes distincts : une évaluation validée n’est pas encore visible de l’enseignant. Le Délégué DCE peut aussi renvoyer le dossier à la commission plutôt que de le valider.

3.4.6. Flux #6 : Consultation et contestation

Ce flux décrit la consultation des résultats par l’enseignant et le processus de contestation éventuel.

Acteurs : Enseignant

Étapes :

  1. L’enseignant consulte son dossier validé

  2. Si accord avec la décision : Fin du processus

  3. Si désaccord : L’enseignant initie un processus de contestation (processus externe, hors périmètre du système)

3.5. États des entités

3.5.1. États du dossier d’évaluation

Le dossier traverse cinq phases. Chacune compte plusieurs états, parce qu’un dossier attend toujours quelqu’un en particulier : l’enseignant, la DCE ou la commission. Les états et les passages de l’un à l’autre sont décrits en détail au chapitre des fonctionnalités, qui fait foi.

Phase Qui agit États

Constitution

L’enseignant

EN_COURS, SOUMIS, REVISION_ENSEIGNANT_REQUISE_DCE

Revue

La DCE

REVUE_EN_COURS_DCE

Évaluation

La commission

ASSIGNE_POUR_EVALUATION_CTE, EVALUATION_EN_COURS_CTE, EVALUATION_REVISION_ENSEIGNANT_REQUISE_CTE, EVALUATION_REMPLISSAGE_TERMINE

Validation

La commission, puis la DCE

EVALUATION_VALIDATION_EN_COURS, EVALUATION_VALIDATION_CTE, EVALUATION_VALIDATION_DCE, EVALUATION_REVISION_CTE_REQUISE_DCE

Publication

La DCE, puis l’enseignant

DISPONIBLE_POUR_ENSEIGNANT, REVISION_EXTERNE_REQUISE
Un dossier soumis n’est pas immédiatement évaluable : la DCE ouvre d’abord sa revue, puis l’affecte à une commission. Cette ouverture est une étape à part entière, qui marque la prise en charge du dossier.

3.5.2. États de la campagne

État Description

PLANIFIEE

La campagne est créée mais pas encore active

ACTIVE

La campagne est en cours, les enseignants peuvent constituer leurs dossiers

TERMINEE

Tous les dossiers ont été validés, la campagne est clôturée

ARCHIVEE

La campagne a été archivée par le Délégué DCE

3.6. Consommation des données de bdes-referentiel

Le système bdes-evaluation consomme les données de référence depuis bdes-referentiel par appel de service à service :

  • Établissements : Universités, écoles, instituts

  • UFR et départements : Structure organisationnelle

  • Enseignants : Identité, grade, affectation (lecture seule)

  • Programmes : Formations dispensées

Les données référentielles ne se saisissent pas dans bdes-evaluation : le référentiel en est la source. La plateforme y écrit en revanche les maquettes de formation et les planifications des enseignements, par le compte de service et par lui seul.

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

4.1. Traitement des cas d’utilisation

Cas Intitulé Traitement

UC-01

S’inscrire à la plateforme

INCHANGÉ

UC-02

Se connecter à la plateforme

INCHANGÉ

UC-03

Se déconnecter de la plateforme

INCHANGÉ

UC-04

Demander des privilèges ou rôles

INCHANGÉ

UC-04b

Gérer les demandes de privilèges ou rôles

INCHANGÉ

UC-05

Notifier les utilisateurs des évènements

REPRIS

UC-06

Gérer les formulaires d’évaluation

INCHANGÉ

UC-07

Créer une campagne d’évaluation

REPRIS

UC-08

Constituer un dossier d’évaluation

INCHANGÉ

UC-09

Assigner un dossier d’évaluation à un CTE

REPRIS

UC-10

Évaluer un dossier (CTE)

REPRIS

UC-11

Répondre anonymement à une évaluation

REPRIS

UC-12

Consulter et filtrer les enseignants

INCHANGÉ

UC-13

Visualiser une évaluation

REPRIS

UC-14

Exporter les données d’une évaluation

REPRIS

UC-15

Valider un dossier

REPRIS

UC-16

Consulter le tableau de bord

REPRIS

UC-17

Analyser la performance pédagogique

REPRIS

UC-18

Analyser la production scientifique

REPRIS

UC-19

Effectuer des analyses transversales

REPRIS

UC-20

Générer des rapports de synthèse

REPRIS

UC-21

Mettre à jour son profil

INCHANGÉ

UC-22

Gérer la planification des enseignements

REPRIS

UC-23

Planifier une visite de terrain

NOUVEAU

UC-24

Suivre une visite de terrain

NOUVEAU

UC-25

Gérer les modèles de rapport

NOUVEAU

UC-26

Produire un rapport conjoint

NOUVEAU

UC-26b

Produire un rapport individuel de campagne

NOUVEAU

UC-27

Associer un formulaire à un profil d’enseignant

NOUVEAU

UC-28

Corriger un score d’évaluation

NOUVEAU

UC-29

Gérer le calendrier académique

NOUVEAU

UC-30

Gérer la structure académique et les offres de formation

NOUVEAU

UC-31

Diffuser un message aux acteurs

NOUVEAU

UC-32

Régler les paramètres applicatifs

NOUVEAU

UC-33

Déclarer les spécialités d’un évaluateur

NOUVEAU

UC-34

Renvoyer une évaluation publiée en révision externe

NOUVEAU

UC-35

Synchroniser l’annuaire des comptes et des rôles

NOUVEAU

UC-36

Traiter les comptes divergents

NOUVEAU

UC-37

Attribuer ou retirer un rôle directement

NOUVEAU

UC-38

Réinitialiser un mot de passe

NOUVEAU

UC-39

Recevoir les évènements du fournisseur d’identité

ENTRE SERVICES

UC-40

Gérer ses préférences de notification

NOUVEAU

UC-41

Gérer les modèles de notification

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

4.1.1. Services porteurs

Tous les cas d’utilisation de ce chapitre ne sont pas portés par le service d’évaluation. Ceux qui relèvent de l’identité, des comptes et des notifications sont portés par des services distincts ; ils figurent ici parce que l’utilisateur les rencontre dans la même plateforme, et que la validation porte sur l’ensemble.

Cas Service porteur

UC-01, UC-02, UC-03

Fournisseur d’identité (Keycloak), dont la plateforme tient le reflet

UC-04, UC-04b, UC-35 à UC-39

Service des comptes et des rôles (bdes-users-api)

UC-05, UC-40, UC-41

Service des notifications (bdes-notifications-api)

UC-31

Porte d’entrée dans le service d’évaluation, remise par le service des notifications

UC-21

Référentiel (bdes-referentiel), dont la source est hors de la plateforme

UC-22, UC-30

Porte d’entrée dans le service d’évaluation, écriture dans le référentiel par le compte de service

Tous les autres

Service d’évaluation (bdes-evaluation-api)

4.2. Cas d’utilisation principaux

4.2.1. UC-01 : S’inscrire à la plateforme bdes-evaluation

Acteur principal : Utilisateur (Enseignant, Évaluateur, Représentant UFR)

Préconditions :

  • L’utilisateur dispose d’une adresse email institutionnelle valide

  • L’utilisateur n’a pas encore de compte sur la plateforme

Scénario nominal :

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

  2. L’utilisateur renseigne ses informations personnelles (nom, prénom, email, matricule, nip)

  3. Le système vérifie que l’email appartient à un domaine autorisé

  4. L’utilisateur choisit un mot de passe conforme aux règles de sécurité

  5. Le système envoie un email de confirmation

  6. L’utilisateur confirme son inscription via le lien reçu

  7. Le compte est créé avec un rôle de base

Les contraintes de validation sont portées par le fournisseur d’identité (Keycloak) et non par l’application.

Données recueillies à l’inscription :

Donnée Usage Obligatoire

Nom et prénoms

Identification de l’utilisateur dans l’application

Oui

Adresse électronique

Identifiant de connexion et destination des notifications

Oui

Mot de passe

Authentification

Oui

Matricule

Rattachement de l’utilisateur à sa fiche du référentiel

Non

NIP

Identifiant national, rapprochement d’identité

Non

Rôle du matricule. Renseigné, il sert à retrouver la fiche de l’enseignant dans bdes-referentiel et à amorcer le rattachement ; l’identifiant de cette fiche est ensuite conservé et devient la clé qui relie le compte à ses dossiers et à ses enseignements. Laissé vide, le compte existe mais reste détaché — l’utilisateur ne retrouve ni ses enseignements, ni ses dossiers, et les écrans qui en dépendent restent vides.

Naissance du compte. Le compte est créé chez le fournisseur d’identité, soit par l’utilisateur lui-même à l’inscription, soit par un administrateur. La plateforme n’en est pas l’auteur : elle en tient le reflet, alimenté par les évènements que le fournisseur d’identité lui transmet (UC-39) et, à défaut, par une synchronisation de l’annuaire (UC-35). Tant que ce reflet n’existe pas, l’utilisateur est connu du fournisseur d’identité et inconnu de la plateforme ; le dépôt de sa première demande de rôle le fait créer à la volée.

Vérification de l’adresse électronique. La politique de vérification — exigée ou non avant la première connexion — est un réglage du fournisseur d’identité, hors de la solution. La plateforme en reflète l’état et ne le présume pas : une adresse que le fournisseur d’identité donne pour vérifiée n’est pas enregistrée comme non vérifiée.

Contraintes de validation :

  • Domaines email autorisés : @gouv.bj, @mesrs.bj, @edu.bj

  • Politique de mot de passe :

    • Longueur minimale : 8 caractères

    • Au moins 1 chiffre

    • Au moins 1 lettre minuscule

    • Au moins 1 lettre majuscule

    • Au moins 1 caractère spécial

    • Ne doit pas contenir le nom d’utilisateur

Scénarios alternatifs :

  • 2a. Email déjà utilisé : Le système signale l’existence d’un compte

  • 3a. Domaine email non autorisé : Le système refuse l’inscription et liste les domaines acceptés

  • 4a. Mot de passe non conforme : Le système indique les critères non respectés

  • 6a. Lien expiré : Le système propose de renvoyer l’email de confirmation

4.2.2. UC-02 : Se connecter à la plateforme bdes-evaluation

Acteur principal : Utilisateur authentifié

Préconditions :

  • L’utilisateur possède un compte actif sur la plateforme

Scénario nominal :

  1. L’utilisateur accède à la page de connexion

  2. L’utilisateur saisit ses identifiants (email et mot de passe)

  3. Le système vérifie les identifiants

  4. Le système redirige l’utilisateur vers son tableau de bord

Scénarios alternatifs :

  • 3a. Identifiants incorrects : Le système affiche un message d’erreur

  • 3b. Compte désactivé : Le système refuse la connexion et informe l’utilisateur

  • 3c. Tentatives multiples échouées : Le système bloque temporairement le compte

4.2.3. UC-03 : Se déconnecter de la plateforme bdes-evaluation

Acteur principal : Utilisateur connecté

Préconditions :

  • L’utilisateur est actuellement connecté à la plateforme

Scénario nominal :

  1. L’utilisateur clique sur le bouton de déconnexion

  2. Le système invalide la session active

  3. Le système redirige l’utilisateur vers la page d’accueil

Scénarios alternatifs :

  • 1a. Session expirée : Le système a déjà invalidé la session automatiquement

4.2.4. UC-04 : Demander des privilèges ou rôles

Acteur principal : Utilisateur authentifié

Préconditions :

  • L’utilisateur possède un compte actif

Scénario nominal :

  1. L’utilisateur choisit le rôle qu’il souhaite obtenir

  2. L’utilisateur justifie sa demande

  3. Lorsque le rôle suppose une fiche au référentiel, l’utilisateur revendique la fiche qui le désigne ; si aucune fiche ne le désigne, il déclare son profil

  4. Le système enregistre la demande au statut PENDING et en avertit les gestionnaires

  5. L’utilisateur suit l’avancement de sa demande depuis son profil

Postconditions :

  • La demande est en attente de traitement et figure dans la liste du demandeur

Scénarios alternatifs :

  • 1a. Rôle d’administration : les rôles Administrateur et Délégué DCE ne peuvent pas être demandés ; ils sont attribués directement (UC-37). Le système refuse la demande

  • 1b. Demande déjà en cours : une seule demande en attente existe pour un même rôle ; le système refuse la seconde

  • 3a. Fiche déjà rattachée à un autre compte : le système refuse la revendication

  • 4a. Compte encore inconnu de la plateforme : le système en crée le reflet depuis l’annuaire avant d’enregistrer la demande

L’utilisateur ne demande un rôle que pour lui-même. Il n’existe pas de demande déposée pour le compte d’un tiers : un gestionnaire qui veut doter quelqu’un d’un rôle le lui attribue directement (UC-37).

4.2.5. UC-04b : Gérer les demandes de privilèges ou rôles

Acteur principal : Administrateur

Acteurs secondaires : Délégué DCE

Le Superviseur est averti du dépôt d’une demande, mais ne la traite pas : le droit de décision ne lui est pas accordé.

Préconditions :

  • Une demande est en attente de traitement

Scénario nominal :

  1. Le gestionnaire consulte les demandes en attente

  2. Le gestionnaire ouvre une demande et examine la justification et la fiche revendiquée

  3. Le gestionnaire approuve ou rejette la demande, en motivant sa décision

  4. À l’approbation, le système confirme le rattachement de la fiche, puis inscrit le rôle chez le fournisseur d’identité et en reporte l’effet dans la plateforme

  5. Le système pose le statut APPROVED ou REJECTED et en avertit le demandeur

Postconditions :

  • La demande est traitée, et le rôle est effectif chez le fournisseur d’identité comme dans la plateforme

Scénarios alternatifs :

  • 3a. Le gestionnaire est le demandeur, ou la cible de la demande : le système refuse l’approbation. Nul n’obtient un rôle par sa propre décision

  • 3b. Rôle d’administration : seul un administrateur approuve l’attribution ou le retrait des rôles Administrateur et Délégué DCE ; nul ne se retire à lui-même le rôle Administrateur

  • 3c. Demande déjà traitée : le système refuse un second traitement

  • 4a. Échec de l’inscription du rôle : le système rétablit l’état antérieur chez le fournisseur d’identité, afin que le rôle ne soit jamais effectif d’un seul côté

  • 5a. Le compte visé a disparu de l’annuaire : le système clôt la demande au statut CANCELLED

Retrait par l’auteur. L’auteur d’une demande en attente peut la retirer. Ce retrait la clôt au statut CANCELLED ; ce n’est pas une décision d’approbation, et il n’ouvre aucun droit.

4.2.6. UC-05 : Notifier les utilisateurs des évènements

Acteur principal : Système

Préconditions :

  • Un évènement déclencheur s’est produit (campagne créée, dossier soumis, demande de rôle déposée, échéance proche, etc.)

  • Les destinataires sont identifiés

Scénario nominal :

  1. Le service à l’origine de l’évènement émet la notification une fois son opération acquise, et jamais avant : aucune notification n’annonce un évènement qui n’a pas eu lieu

  2. Le système identifie les destinataires : des personnes nommées, les porteurs d’un rôle, ou l’ensemble des utilisateurs

  3. Le système compose le contenu à partir du modèle désigné, dans la langue du destinataire, en y substituant les éléments de l’évènement

  4. Le système retient les canaux que le destinataire accepte et dépose la notification sur chacun : le courriel et l’application

  5. Le destinataire connecté la reçoit sans rafraîchir sa page

  6. Le système conserve la notification et l’état de sa remise sur chaque canal

Postconditions :

  • La notification est consultable dans l’application et comptée parmi les non-lues

  • L’état de remise est conservé pour chaque canal : émise, remise, lue ou en échec

Scénarios alternatifs :

  • 1a. Évènement émis deux fois : le système ne notifie qu’une fois. Un évènement rejoué ne produit pas un second message

  • 3a. Modèle absent dans la langue du destinataire : le système retient la version française

  • 3b. Modèle introuvable : le système n’envoie rien et le consigne ; l’évènement métier n’en est pas affecté

  • 4a. Échec de remise : le système réessaie selon un délai croissant ; passé le nombre d’essais retenu, il consigne l’échec définitif et en avertit l’administrateur

  • 4b. Canal refusé par le destinataire : le système ne dépose rien sur ce canal

  • 4c. Service de notification indisponible : le service émetteur conserve la notification et la rejoue ; l’administrateur peut la rejouer ou purger la file d’attente

  • 5a. Destinataire hors ligne : la notification l’attend à sa prochaine connexion

4.2.7. UC-06 : Gérer les formulaires d’évaluation

Acteur principal : Délégué DCE

Préconditions :

  • L’acteur dispose du droit de gestion des formulaires

Scénario nominal :

  1. L’acteur accède à la gestion des formulaires

  2. L’acteur crée un formulaire ou en duplique un existant

  3. L’acteur définit les sections, les critères et leurs pondérations

  4. L’acteur enregistre le formulaire en brouillon

  5. L’acteur soumet le formulaire pour validation

  6. Le détenteur du droit de publication publie le formulaire

  7. Le formulaire publié devient utilisable dans les campagnes

Postconditions :

  • Un formulaire publié n’est plus modifiable ; une modification passe par une nouvelle version

Scénarios alternatifs :

  • 5a. Formulaire rejeté : Le validateur renvoie le formulaire en brouillon ; l’acteur effectue les corrections demandées

  • 2a. Duplication : L’acteur clone un formulaire archivé ; le clone repart en brouillon, indépendant de son modèle

  • 6a. Archivage : Le détenteur du droit de publication retire un formulaire de la circulation sans le supprimer

  • 7a. Formulaire déjà servi : Le schéma du formulaire est figé sur les dossiers qui l’ont reçu ; une nouvelle version ne modifie pas les dossiers en cours

4.2.8. UC-07 : Créer une campagne d’évaluation

Acteur principal : Délégué DCE

Préconditions :

  • L’acteur dispose du droit de gestion des campagnes

  • Les données référentielles sont disponibles (consommées depuis bdes-referentiel)

Scénario nominal :

  1. L’acteur renseigne les informations de la campagne : intitulé, année académique, dates de début et de fin, échéance de soumission des dossiers

  2. L’acteur sélectionne les enseignants concernés

  3. L’acteur associe les types d’évaluation, les formulaires et les modèles de rapport

  4. Le système crée la campagne au statut PLANIFIEE et les dossiers initiaux

  5. La campagne passe au statut ACTIVE, et les enseignants sont notifiés

Postconditions :

  • Les enseignants retenus disposent d’un dossier à constituer

Scénarios alternatifs :

  • 2a. Retrait d’un enseignant : L’acteur retire un enseignant de la campagne ; ses affectations en cours sont closes et ses visites à venir annulées

  • 2b. Retrait en masse : Possible tant que la campagne est encore planifiée, donc avant toute affectation

  • 2c. Enseignant retenu dans plusieurs campagnes : Autorisé. Un même enseignant peut faire l’objet de plusieurs campagnes simultanées

  • 4a. Dates invalides : Le système demande une correction

  • 5a. Publication par l’acteur : L’acteur active la campagne lui-même, sans attendre sa date de début

  • 5b. Réouverture : Une campagne active peut revenir au statut PLANIFIEE, et une campagne terminée être réactivée

Le passage d’un statut à l’autre emprunte deux voies. L’acteur l’exerce depuis l’écran des campagnes ; le système le fait aussi de lui-même, en repassant périodiquement sur les campagnes dont la date de début ou de fin est atteinte. Les deux voies posent les mêmes statuts. * 5c. Clôture : À la date de fin, le système fait passer la campagne au statut TERMINEE ; la clôture est réversible
Les transitions automatiques et les relances ne sont pas portées par le service d’évaluation mais par un service d’ordonnancement dédié, qui les déclenche à intervalle régulier. Un changement d’état peut donc survenir avec un décalage de quelques minutes après la date qui le commande. * 5d. Archivage : L’acteur archive une campagne terminée, ou une campagne encore planifiée (campagne := ARCHIVEE). L’archivage est irréversible et annule les visites de terrain à venir, ce que la clôture se garde de faire puisqu’elle est réversible * 5e. Relances : Avant l’échéance de soumission et avant la fin de campagne, le système relance les acteurs concernés

4.2.9. UC-08 : Constituer un dossier d’évaluation (Enseignant)

Acteur principal : Enseignant

Préconditions :

  • L’enseignant est retenu dans une campagne active

Scénario nominal :

  1. L’enseignant accède à son dossier en cours

  2. L’enseignant renseigne les formulaires attachés à son profil. Leurs sections couvrent les pièces du dossier : enseignements, publications, recherches, brevets, distinctions, subventions, partenariats, financements et activités de revue scientifique

  3. L’enseignant téléverse les pièces justificatives, rattachées aux sections qui les appellent

  4. L’enseignant soumet son dossier (dossier := SOUMIS)

Les pièces du dossier ne sont pas portées par des entités dédiées du modèle : chacune est une section de formulaire, et son contenu est enregistré avec les réponses du dossier. Les règles de saisie — champs obligatoires, bornes d’ancienneté des publications, formats attendus — sont portées par les formulaires eux-mêmes, définies à leur configuration, et non par l’application. Faire évoluer une règle revient donc à publier une nouvelle version du formulaire concerné (UC-06).

Postconditions :

  • Le dossier n’est plus modifiable tant qu’il n’est pas retourné

Scénarios alternatifs :

  • 2a. Travail en plusieurs fois : La saisie est conservée en brouillon ; l’enseignant la reprend ou l’abandonne à sa prochaine visite

  • 4a. Formulaires selon le profil : Les formulaires reçus dépendent du grade, du corps, du statut et de la spécialité de l’enseignant (UC-27)

  • 5a. Délai dépassé : Le système refuse la soumission

  • 5b. Retour pour correction : Un dossier retourné par le Délégué DCE redevient modifiable

4.2.10. UC-09 : Assigner un dossier d’évaluation à un CTE

Acteur principal : Délégué DCE

Acteurs secondaires : Superviseur

Préconditions :

  • Le dossier est au statut REVUE_EN_COURS_DCE : il a été soumis, puis sa revue a été ouverte par le Délégué DCE ou le superviseur

Un dossier simplement SOUMIS n’est pas affectable. L’ouverture de la revue est une étape à part entière, qui marque la prise en charge du dossier par la DCE.

Scénario nominal :

  1. L’acteur consulte les dossiers soumis

  2. L’acteur sélectionne un dossier à affecter

  3. L’acteur constitue la CTE et désigne le rapporteur

  4. Le système signale les conflits d’intérêt qu’il détecte parmi les évaluateurs retenus ; l’acteur arbitre

  5. L’acteur fixe l’échéance de l’évaluation et, s’il y a lieu, désigne le superviseur de l’affectation

  6. Le système enregistre l’affectation et notifie les évaluateurs

Postconditions :

  • L’évaluation est ouverte et visible des membres de la CTE

Scénarios alternatifs :

  • 3a. Affectation d’experts : Outre les membres de la CTE, l’acteur affecte des experts d’évaluation, porteurs de leur propre rôle sur le dossier

  • 3b. Affectation groupée : L’acteur affecte un même expert à plusieurs dossiers en une fois

  • 3c. Évaluateurs indisponibles : L’acteur recherche d’autres évaluateurs

  • 4a. Conflit d’intérêt détecté : Le système refuse qu’un évaluateur soit affecté au dossier dont il est l’auteur. Pour les autres situations, il signale le conflit et demande un autre évaluateur ; l’acteur peut passer outre en le motivant

  • 3d. Réaffectation : L’affectation en cours est close, ses visites à venir sont annulées, et la nouvelle affectation hérite du superviseur et de l’échéance de la précédente

  • 5a. Sans superviseur désigné : L’affectation reste valable. L’acteur qui affecte ne se désigne lui-même que s’il porte le rôle Superviseur ; toute désignation explicite vise un utilisateur portant ce rôle

  • 5b. Report d’échéance : L’acteur modifie l’échéance d’une affectation en cours

  • 6a. Relance : L’acteur relance les évaluateurs ; le système les relance aussi à l’approche de l’échéance

4.2.11. UC-10 : Évaluer un dossier (CTE)

Acteur principal : Membres de la CTE (Rapporteur et Évaluateurs)

Préconditions :

  • Les membres sont affectés à la CTE du dossier

  • Le dossier est au statut ASSIGNE_POUR_EVALUATION_CTE, qu’il porte depuis son affectation (UC-09)

Scénario nominal :

  1. Les membres de la CTE consultent le dossier complet

  2. Le rapporteur démarre l’évaluation (évaluation := DRAFT)

  3. Le rapporteur remplit la grille d’évaluation et enregistre son brouillon

  4. Le rapporteur marque le remplissage terminé (évaluation := COMPLETE, dossier := EVALUATION_REMPLISSAGE_TERMINE)

  5. Chaque membre de la CTE consulte le rapport et appose sa signature (évaluation := SIGN)

  6. Une fois toutes les signatures réunies, le système fait passer le dossier au statut EVALUATION_VALIDATION_CTE

  7. Le système notifie le Délégué DCE

Postconditions :

  • Toutes les signatures des membres de la CTE sont enregistrées

  • Le dossier est au statut EVALUATION_VALIDATION_CTE, seul état depuis lequel le Délégué DCE peut valider (UC-15)

Le statut de l'évaluation n’est pas indépendant : il est projeté depuis celui du dossier, qui porte seul la machine à états. Deux statuts de dossier se projettent sur la même valeur VALIDE — celui validé par la CTE et celui validé par le Délégué DCE. Toute condition doit donc être exprimée sur le statut du dossier, jamais sur celui de l’évaluation.
Le passage au statut EVALUATION_VALIDATION_CTE n’est le fait d’aucun acteur : le système le déclenche lorsque les signatures attendues sont réunies.

Scénarios alternatifs :

  • 1a. Dossier incomplet : La CTE demande une révision à l’enseignant (dossier := EVALUATION_REVISION_ENSEIGNANT_REQUISE_CTE)

  • 5a. Membre en désaccord : Le membre ajoute une observation divergente

  • 6a. Renvoi en révision : Le superviseur ou le Délégué DCE renvoie l’évaluation à la CTE avec un commentaire obligatoire. Toutes les signatures déjà apposées sont effacées et devront être reprises

  • 6b. Conflit d’intérêt détecté : Le membre se récuse et est retiré de la CTE

4.2.12. UC-11 : Répondre anonymement à une évaluation (Étudiant)

Acteur principal : Étudiant

L’anonymat est l’objectif de ce cas d’utilisation, et il repose sur deux appuis. Dans la solution : aucune identité d’étudiant n’est enregistrée — ni nom, ni adresse, ni identifiant. Hors de la solution : les jetons sont distribués de façon non nominative, les étudiants les prenant sans qu’il soit noté qui reçoit lequel. Le second appui est une hypothèse de fonctionnement : il conditionne l’anonymat autant que le premier.

Préconditions :

  • L’étudiant a reçu un jeton d’accès valide

  • La session d’évaluation est ouverte

Scénario nominal :

  1. L’étudiant accède au formulaire par son jeton ou par le code QR de la session, sans authentification

  2. Le système vérifie la validité du jeton

  3. L’étudiant remplit le formulaire d’évaluation

  4. L’étudiant soumet son évaluation

  5. Le système enregistre la réponse et marque le jeton comme utilisé

Postconditions :

  • Le jeton ne peut plus servir

  • La réponse est comptée dans les résultats de la session, sans rattachement à une personne

Scénarios alternatifs :

  • 2a. Jeton déjà utilisé : Le système refuse l’accès

  • 2b. Jeton invalide : Le système affiche une erreur

  • 2c. Session suspendue ou close : Le système refuse l’accès

  • 3a. Sollicitations répétées : Le système limite le nombre de tentatives par minute et par origine

4.2.13. UC-12 : Consulter et filtrer les enseignants

Acteur principal : Délégué DCE

Préconditions :

  • Le délégué est authentifié et autorisé

Scénario nominal :

  1. Le délégué accède au module de consultation

  2. Le délégué définit les critères de recherche (établissement, spécialité, grade, etc.)

  3. Le système affiche la liste filtrée des enseignants

  4. Le délégué consulte les détails d’un enseignant

  5. Le délégué exporte les données au format CSV/Excel

Scénarios alternatifs :

  • 3a. Aucun résultat : Le système propose d’élargir les critères

  • 5a. Export volumineux : Le système génère le fichier en arrière-plan

4.2.14. UC-13 : Visualiser une évaluation (DCE)

Acteur principal : Délégué DCE

Préconditions :

  • Le dossier est au statut EVALUATION_VALIDATION_DCE ou DISPONIBLE_POUR_ENSEIGNANT

La condition porte sur le dossier et non sur l’évaluation : le statut d’évaluation VALIDE recouvre aussi bien la validation par la CTE que celle par le Délégué DCE.

Scénario nominal :

  1. Le délégué accède au module de consultation des évaluations

  2. Le délégué sélectionne un dossier d’évaluation

  3. Le système affiche le rapport CTE complet

  4. Le délégué consulte les évaluations pédagogiques agrégées

  5. Le délégué peut naviguer entre les différentes sections du dossier

Scénarios alternatifs :

  • 2a. Dossier non accessible : Le système affiche un message d’erreur

  • 4a. Évaluations pédagogiques insuffisantes : Le système signale le nombre de réponses

4.2.15. UC-14 : Exporter les données d’une évaluation (DCE)

Acteur principal : Délégué DCE

Les exports portent sur les listes qu’offrent les écrans, et non sur une évaluation prise isolément. Chaque export a son format propre et se produit immédiatement.

Préconditions :

  • L’acteur dispose du droit de lecture sur les données exportées

Scénario nominal :

  1. L’acteur affiche la liste qu’il veut exporter et y applique ses filtres

  2. L’acteur demande l’export

  3. Le système produit le fichier dans le format propre à cette liste et le remet immédiatement

Postconditions :

  • Le fichier reflète les filtres appliqués à l’écran au moment de la demande

Scénarios alternatifs :

  • 3a. Liste des affectations : fichier tableur

  • 3b. Liste des visites de terrain : fichier CSV

  • 3c. Jetons d’une session d’évaluation étudiante : fichier PDF ou CSV

  • 3d. Formulaire renseigné : impression en PDF depuis le navigateur

  • 3e. Volume trop important : Le système refuse l’export au-delà du plafond configuré et invite à restreindre la sélection

4.2.16. UC-15 : Valider un dossier (DCE)

Acteur principal : Délégué DCE

Acteurs secondaires : Superviseur, sur les affectations dont il est désigné superviseur

Préconditions :

  • Le dossier est au statut EVALUATION_VALIDATION_CTE : la CTE a terminé son remplissage, puis le superviseur a validé pour son compte

  • Les signatures de la CTE — ou de tous les experts lorsqu’il n’y a pas de CTE — sont complètes

  • Le Délégué DCE n’est pas le propriétaire du dossier évalué

Le remplissage terminé par la CTE (dossier au statut EVALUATION_REMPLISSAGE_TERMINE) ne suffit pas : deux transitions le séparent de la validation DCE — le démarrage puis l’achèvement de la validation par la CTE.

Scénario nominal :

  1. Le délégué consulte le dossier et le rapport de la CTE

  2. Le délégué consulte les évaluations pédagogiques agrégées

  3. Le délégué rédige son appréciation finale

  4. Le délégué sélectionne sa décision (favorable, défavorable ou avec réserves)

  5. Le délégué signe électroniquement

  6. Le système fait passer le dossier au statut EVALUATION_VALIDATION_DCE

  7. Le délégué publie le résultat ; le dossier passe au statut DISPONIBLE_POUR_ENSEIGNANT et l’enseignant est notifié

Scénarios alternatifs :

  • 1a. Dossier du délégué lui-même : Le système refuse la validation, sans exception de rôle

  • 1b. Validation par le superviseur de l’affectation : Le superviseur désigné sur une affectation y exerce les mêmes gestes que le délégué — appréciation, décision, signature, validation puis publication — sur cette seule affectation. Hors de son périmètre, le système refuse

  • 4a. Renvoi en révision : Le délégué renvoie l’évaluation à la CTE avec un commentaire obligatoire ; toutes les signatures de la CTE sont effacées

4.2.17. UC-16 : Consulter le tableau de bord (KPIs)

Les cas UC-16 à UC-19 sont servis par deux voies. Des écrans applicatifs rendent les indicateurs de suivi — taux de complétion, campagnes actives, dossiers soumis, évaluations publiées, calendrier des campagnes — calculés par la solution elle-même. Des tableaux de bord décisionnels embarqués, alimentés par l’entrepôt de données, servent les analyses ; leurs capacités d’exploration et d’export sont celles de l’outil décisionnel.

Acteur principal : Délégué DCE

Préconditions :

  • Des données d’évaluation existent dans le système

Scénario nominal :

  1. L’acteur accède au tableau de bord principal

  2. Le système affiche les indicateurs clés : campagnes actives, dossiers soumis, taux de complétion, évaluations publiées

  3. L’acteur consulte le calendrier des campagnes et le suivi rapide

  4. L’acteur filtre par période, établissement ou type de campagne

Scénarios alternatifs :

  • 2a. Données insuffisantes : Le système signale le manque de données

4.2.18. UC-17 : Analyser la performance pédagogique

Voir la note portée par UC-16 : les analyses sont servies par les tableaux de bord décisionnels embarqués.

Acteur principal : Délégué DCE, Responsable Académique

Préconditions :

  • L’utilisateur est authentifié et autorisé

  • Des évaluations pédagogiques existent dans le système

Scénario nominal :

  1. L’utilisateur accède au module d’analyse pédagogique

  2. Le système affiche les tendances des évaluations pédagogiques

  3. L’utilisateur consulte les comparaisons inter-établissements

  4. L’utilisateur analyse les évolutions temporelles des scores

  5. L’utilisateur exporte les graphiques et données

Scénarios alternatifs :

  • 3a. Établissement sans données : Le système affiche un message approprié

  • 5a. Export non disponible : Le système génère le rapport en arrière-plan

4.2.19. UC-18 : Analyser la production scientifique

Acteur principal : Délégué DCE, Responsable Académique

Préconditions :

  • L’utilisateur est authentifié et autorisé

  • Des dossiers soumis portent des sections de production scientifique renseignées

Scénario nominal :

  1. L’utilisateur accède au module d’analyse scientifique

  2. Le système agrège les réponses des sections de production scientifique des dossiers et restitue les statistiques par enseignant

  3. L’utilisateur consulte les tendances de production par domaine

  4. L’utilisateur analyse les indicateurs de recherche disponibles

  5. L’utilisateur compare la production entre établissements ou départements

Scénarios alternatifs :

  • 2a. Sections non renseignées : Le système signale les dossiers dont les sections de production scientifique sont vides

  • 4a. Indicateurs non disponibles : Le système utilise les données disponibles

L’analyse porte sur les réponses des formulaires du dossier, et non sur des enregistrements de publications tenus à part : la production scientifique est déclarée dans les sections prévues à cet effet, dont le contenu suit la version du formulaire en vigueur.

4.2.20. UC-19 : Effectuer des analyses transversales

Acteur principal : Délégué DCE

Préconditions :

  • L’utilisateur est authentifié et autorisé

  • Des données multi-dimensions existent dans le système

Scénario nominal :

  1. L’utilisateur accède au module d’analyses transversales

  2. L’utilisateur sélectionne les dimensions d’analyse (établissement, grade, discipline)

  3. Le système génère les visualisations croisées

  4. L’utilisateur explore les corrélations entre indicateurs

  5. L’utilisateur sauvegarde ou exporte ses analyses personnalisées

Scénarios alternatifs :

  • 3a. Combinaison de filtres sans résultats : Le système propose des alternatives

  • 5a. Analyse complexe : Le système propose de programmer l’exécution

4.2.21. UC-20 : Générer des rapports de synthèse

Les rapports de la plateforme sont produits à partir de modèles (UC-25) et se déclinent en trois formes : le rapport individuel attaché à une évaluation, le rapport conjoint des évaluateurs d’une même évaluation (UC-26), et le rapport individuel de campagne, qui porte sur l’ensemble de la campagne et non sur un dossier (UC-26b). Seules les synthèses par établissement ou par année relèvent des tableaux de bord décisionnels (UC-16).

Acteur principal : Évaluateur

Acteurs secondaires : Délégué DCE (validation)

Préconditions :

  • L’acteur est affecté à l’évaluation

  • Un modèle de rapport est disponible pour la campagne

Scénario nominal :

  1. L’acteur choisit un modèle parmi ceux rattachés à la campagne

  2. L’acteur renseigne le rapport

  3. L’acteur soumet le rapport (statut := SUBMITTED)

  4. Le Délégué DCE valide le rapport (statut := VALIDATED)

  5. Le rapport validé est consultable et imprimable

Scénarios alternatifs :

  • 4a. Retour pour correction : Le Délégué DCE retourne le rapport avec un commentaire

  • 2a. Rapport conjoint : Plusieurs évaluateurs renseignent et signent le même rapport (UC-26)

4.2.22. UC-21 : Mettre à jour son profil (Enseignant)

Ce cas d’utilisation est adressé dans bdes-referentiel et consommé par bdes-evaluation. Les données de profil dont il est question ici sont relative à l’identité de l’individu, son adresse, son rattachement, etc.

Acteur principal : Enseignant

Préconditions :

  • L’acteur demande la mise à jour des informations dans la source autoritaire.

  • La source autoritaire communique les nouvelles données à bdes-referentiel selon le canal admis.

4.2.23. UC-22 : Gérer la planification des enseignements (Responsable académique)

Ce cas d’utilisation était auparavant traité hors plateforme. La planification est désormais saisie dans bdes-evaluation et écrite dans bdes-referentiel par le compte de service. Quatre surfaces d’écran écrivent ainsi dans le référentiel : la planification des cours, la maquette des unités d’enseignement et des éléments constitutifs (UC-30), le calendrier académique (UC-29) et les créneaux-types. Toutes passent par le compte de service ; aucune n’écrit directement.

Acteur principal : Responsable académique

Acteurs secondaires : Administrateur ; Délégué DCE (consultation)

Préconditions :

  • L’acteur est rattaché à une UFR par une fonction ouvrant droit à la planification

  • La maquette de la formation comporte des UE et des EC pour l’année choisie

Scénario nominal :

  1. L’acteur choisit une année académique et une offre de formation de son périmètre

  2. L’acteur choisit un élément constitutif et l’enseignant qui l’assure

  3. L’acteur saisit les créneaux : date, heure de début, heure de fin, type de séance, salle

  4. Le système enregistre et rend un rapport : créées, déjà existantes, rejetées

Postconditions :

  • Les créneaux sont visibles dans l’emploi du temps de l’enseignant

Scénarios alternatifs :

  • 3a. Import en masse : L’acteur dépose un fichier Excel conforme au modèle téléchargeable

  • 3b. Séances récurrentes : L’acteur déclare un créneau-type et demande la génération sur la période, hors jours fériés et périodes non enseignées

  • 3c. Reconduction : L’acteur reprend les lignes d’une année précédente — formation, élément constitutif, enseignant — qui sont reportées sur l’année cible. Les créneaux ne sont pas repris : les dates appartiennent à l’année source et doivent être ressaisies

  • 4a. Chevauchement : Le système refuse un créneau recouvrant une autre séance du même enseignant

4.2.24. UC-23 : Planifier une visite de terrain

Acteur principal : Délégué DCE

Acteurs secondaires : Superviseur affecté au dossier

Préconditions :

  • L’évaluateur est affecté au dossier de l’enseignant

  • L’enseignant dispose d’un matricule et d’un créneau planifié dans la période de la campagne

Scénario nominal :

  1. L’acteur choisit une campagne puis un évaluateur

  2. Le système affiche les dossiers de cet évaluateur et leurs créneaux disponibles

  3. L’acteur choisit un dossier ; le système ouvre l’emploi du temps sur le premier créneau à venir

  4. L’acteur choisit un créneau et désigne les évaluateurs participants

  5. Le système enregistre la visite (visite := PLANIFIEE)

Postconditions :

  • La visite apparaît dans l’emploi du temps et dans la liste des visites

Scénarios alternatifs :

  • 2a. Aucun créneau disponible : Le système affiche le motif (sans matricule, ou aucun cours planifié) ; la visite hors cours reste possible

  • 4a. Visite hors cours : L’acteur saisit librement date, heures et lieu, sans dépasser la fin de la campagne

  • 5a. Évaluateur déjà pris : Le système refuse et nomme la visite en conflit

  • 5b. Dossier déjà couvert : Le système refuse et propose d’ouvrir la visite existante

4.2.25. UC-24 : Suivre une visite de terrain

Acteur principal : Délégué DCE

Préconditions :

  • Une visite est planifiée

Scénario nominal :

  1. L’acteur consulte la liste des visites, filtrable par statut, type et UFR

  2. L’acteur modifie la visite : plage, évaluateurs, lieu, commentaire

  3. Après le début de la visite, l’acteur la marque réalisée (visite := REALISEE)

  4. Le système trace l’auteur et la date de la déclaration

Postconditions :

  • L’historique de la visite conserve chaque changement et son auteur

Scénarios alternatifs :

  • 2a. Modification concurrente : Le système refuse, nomme l’auteur de la dernière modification et repart de la version à jour

  • 3a. Retour arrière : L’acteur annule la déclaration (visite := PLANIFIEE)

  • 3b. Annulation : L’acteur annule la visite en saisissant un motif obligatoire (visite := ANNULEE)

  • 3c. Annulation automatique : Au retrait du dernier évaluateur, le système annule la visite et porte son nom dans l’historique

  • 4a. Visite passée non confirmée : Une visite dont la fin est dépassée sans déclaration est signalée dans la liste

4.2.26. UC-25 : Gérer les modèles de rapport

Acteur principal : Délégué DCE

Acteurs secondaires : Superviseur, Administrateur

Préconditions :

  • L’acteur dispose du droit de gestion des modèles de rapport

Scénario nominal :

  1. L’acteur crée un modèle et en définit la portée : individuelle, CTE, groupe d’experts externes, ou globale

  2. L’acteur compose le contenu du modèle et lui affecte une ou plusieurs catégories

  3. L’acteur fixe la période de validité du modèle

  4. L’acteur publie le modèle (statut := PUBLISHED)

  5. Le modèle devient utilisable dans les campagnes auxquelles il est rattaché

Postconditions :

  • Un modèle publié n’est plus modifiable

  • Les rapports correspondants sont créés automatiquement sur les évaluations de la campagne (UC-26)

La portée détermine qui remplit le rapport et combien d’exemplaires existent. INDIVIDUAL : un rapport par évaluateur. CTE : un rapport conjoint aux membres du CTE. EXPERT_GROUP : un rapport conjoint aux experts externes au CTE. GLOBAL : un rapport conjoint à tous, membres du CTE et experts externes réunis.

Scénarios alternatifs :

  • 4a. Duplication : L’acteur clone un modèle ; le clone repart en brouillon, sans période de validité, indépendant de son modèle

  • 4b. Modèle en brouillon : Tant qu’il n’est pas publié, le modèle reste modifiable et invisible des évaluateurs

  • 5a. Suppression : L’acteur supprime un modèle ; le système refuse si au moins un rapport s’y rattache

4.2.27. UC-26 : Produire un rapport conjoint

Acteur principal : Évaluateur

Acteurs secondaires : Délégué DCE (validation)

Les rapports conjoints ne sont pas créés par un acteur. Le système les crée à l’ouverture de l’évaluation, un par modèle de portée conjointe rattaché à la campagne, et complète les signatures attendues à chaque ajout d’un expert ou d’un membre de CTE. L’évaluateur trouve donc le rapport déjà présent : il le renseigne et le signe.

Préconditions :

  • L’évaluation est ouverte et la campagne porte au moins un modèle de portée conjointe

  • L’acteur est habilité à remplir ce rapport au titre de sa portée : membre du CTE pour un rapport de portée CTE, expert externe pour un rapport de groupe d’experts, l’un ou l’autre pour un rapport global

Scénario nominal :

  1. L’acteur ouvre le rapport conjoint attaché à l’évaluation

  2. Les évaluateurs habilités le renseignent tour à tour

  3. Chaque évaluateur appose sa signature ; la première fait passer le rapport à PENDING_VALIDATION

  4. Lorsque tous les signataires attendus ont signé, le rapporteur ou le superviseur soumet le rapport (statut := SUBMITTED)

  5. Le Délégué DCE valide le rapport (statut := VALIDATED)

Postconditions :

  • Le rapport validé est consultable et imprimable, et n’est plus modifiable

Scénarios alternatifs :

  • 4a. Signatures incomplètes : La soumission est refusée tant qu’un signataire attendu n’a pas signé

  • 5a. Retour pour correction : Le Délégué DCE retourne le rapport (statut := RETURNED) ; il redevient modifiable et toutes les signatures déjà apposées sont effacées

4.2.28. UC-26b : Produire un rapport individuel de campagne

Acteur principal : Évaluateur

Acteurs secondaires : Délégué DCE (validation)

Ce rapport ne porte pas sur un dossier mais sur toute la campagne. Il se distingue du rapport individuel d’évaluation, qui est attaché à un dossier précis et à l’affectation de son auteur.

Préconditions :

  • La campagne porte au moins un modèle de portée individuelle

Scénario nominal :

  1. L’acteur ouvre ses rapports de campagne ; le système crée en brouillon ceux qui manquent, un par modèle de portée individuelle

  2. L’acteur renseigne le rapport

  3. L’acteur le soumet (statut := SUBMITTED)

  4. Le Délégué DCE le valide (statut := VALIDATED)

Postconditions :

  • Il existe au plus un rapport par campagne, évaluateur et modèle

Scénarios alternatifs :

  • 1a. Rapports déjà amorcés : Le système rend les rapports existants sans en créer de nouveaux

  • 1b. Création par la DCE : Le Délégué DCE peut créer manuellement le rapport d’un évaluateur donné

  • 4a. Retour pour correction : Le rapport revient à l’auteur (statut := RETURNED) et redevient modifiable

4.2.29. UC-27 : Associer un formulaire à un profil d’enseignant

Acteur principal : Délégué DCE

Préconditions :

  • Les formulaires concernés sont publiés

Scénario nominal :

  1. L’acteur choisit un critère de profil : grade, corps, statut ou spécialité

  2. L’acteur associe un ou plusieurs formulaires à ce critère

  3. Le système enregistre l’association

  4. À l’ouverture d’une campagne, chaque enseignant reçoit les formulaires correspondant à son profil

Postconditions :

  • Les dossiers créés portent les formulaires issus de l’association

Scénarios alternatifs :

  • 2a. Affectation en masse : L’acteur applique une association à l’ensemble des dossiers déjà ouverts

  • 3a. Retrait : L’acteur supprime une association ; les dossiers déjà servis ne sont pas modifiés

4.2.30. UC-28 : Corriger un score d’évaluation

Acteur principal : Délégué DCE

Préconditions :

  • Une évaluation porte un score calculé

Scénario nominal :

  1. L’acteur constate un score à corriger

  2. L’acteur saisit la valeur retenue et la motive

  3. Le système conserve le score calculé et lui superpose la valeur saisie

  4. Le système trace l’auteur et la date de la correction

Postconditions :

  • Le score affiché est la valeur corrigée ; le score calculé reste consultable

Scénarios alternatifs :

  • 3a. Retrait de la correction : L’acteur supprime la surcharge ; le score calculé redevient le score affiché

4.2.31. UC-29 : Gérer le calendrier académique

Acteur principal : Délégué DCE ou Administrateur, sans distinction de prérogative

Le responsable académique lit le calendrier — il en a besoin pour la génération des emplois du temps — mais ne l’écrit pas, alors qu’il est l’acteur principal de UC-22 et UC-30.

Préconditions :

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

Scénario nominal :

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

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

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

  4. Le système applique ces bornes à la génération des emplois du temps

Postconditions :

  • Aucun créneau n’est généré sur un jour férié ni sur une période non enseignée

Cette garantie porte sur tous les chemins de création de créneaux, import en masse compris (RG8.4).

Scénarios alternatifs :

  • 4a. Modification en cours d’année : Les créneaux déjà générés ne sont pas repris ; seules les générations suivantes tiennent compte du changement

4.2.32. UC-30 : Gérer la structure académique et les offres de formation

Acteur principal : Responsable académique

Acteurs secondaires : Délégué DCE (consultation)

Préconditions :

  • L’acteur est rattaché à une UFR par une fonction ouvrant droit à la planification

Scénario nominal :

  1. L’acteur consulte les offres de formation de son périmètre

  2. L’acteur complète la maquette d’une formation : unités d’enseignement et éléments constitutifs

  3. L’acteur enregistre la maquette

  4. Le système écrit la maquette dans le référentiel par l’intermédiaire du compte de service

Postconditions :

  • Les éléments constitutifs deviennent planifiables (UC-22)

Scénarios alternatifs :

  • 2a. Import en masse : L’acteur dépose un fichier Excel conforme au modèle téléchargeable

  • 3a. Versionnement : L’acteur déclenche le versionnement d’une maquette pour une nouvelle année académique

4.2.33. UC-31 : Diffuser un message aux acteurs

Acteur principal : Délégué DCE

Acteurs secondaires : Administrateur

Le superviseur ne diffuse pas : le droit requis ne lui est pas accordé.

Préconditions :

  • L’acteur dispose du droit de diffusion

Scénario nominal :

  1. L’acteur rédige un message

  2. L’acteur choisit les destinataires : un ou plusieurs rôles, ou des personnes nommées

  3. L’acteur envoie le message

  4. Le système notifie les destinataires et conserve le message dans les envois

Postconditions :

  • Le message figure dans l’historique des envois de l’acteur

4.2.34. UC-32 : Régler les paramètres applicatifs

Acteur principal : Administrateur

Préconditions :

  • L’acteur dispose du droit de réglage

Scénario nominal :

  1. L’acteur consulte les paramètres, groupés par service et par catégorie

  2. L’acteur modifie la valeur d’un paramètre

  3. Le système enregistre la valeur et l’applique

Postconditions :

  • La nouvelle valeur s’applique sans redémarrage du service

Scénarios alternatifs :

  • 2a. Valeur non conforme au type attendu : Le système refuse et rappelle le type du paramètre

4.2.35. UC-33 : Déclarer les spécialités d’un évaluateur

Acteur principal : Évaluateur

Acteurs secondaires : Délégué DCE, Superviseur

Préconditions :

  • L’acteur dispose d’un compte sur la plateforme

Scénario nominal :

  1. L’évaluateur déclare sa spécialité en demandant le rôle d’évaluateur (UC-04)

  2. À l’approbation de la demande, la spécialité déclarée est portée sur le profil créé

  3. L’évaluateur peut ensuite compléter ou reprendre ses spécialités depuis son profil

  4. Les spécialités choisies le sont dans la nomenclature du référentiel ; le libellé enregistré est celui de la nomenclature

Postconditions :

  • Les spécialités sont visibles sur le profil de l’évaluateur et servent à le retrouver lors de la constitution d’une commission

Scénarios alternatifs :

  • 4a. Libellé hors nomenclature : aucune proposition ne correspond et la saisie n’est pas enregistrable

  • 3a. Reprise par un gestionnaire : le Délégué DCE ou le Superviseur peut reprendre les spécialités d’un évaluateur depuis sa fiche

Les spécialités sont portées par bdes-evaluation et non par le référentiel : elles qualifient l’évaluateur dans le cadre de l’évaluation, et non la personne dans le référentiel.

4.2.36. UC-34 : Renvoyer une évaluation publiée en révision externe

Acteur principal : Délégué DCE

Un dossier publié à l’enseignant n’est pas un état terminal. Cette phase permet de rouvrir une évaluation déjà rendue, par exemple après une contestation ou un contrôle postérieur.

Préconditions :

  • Le dossier est au statut DISPONIBLE_POUR_ENSEIGNANT

Scénario nominal :

  1. L’acteur demande la révision externe du dossier (dossier := REVISION_EXTERNE_REQUISE)

  2. Le système notifie les acteurs concernés

  3. Un évaluateur rouvre l’évaluation (dossier := EVALUATION_EN_COURS_CTE)

  4. Le circuit d’évaluation reprend à partir de cet état

Postconditions :

  • L’évaluation redevient modifiable et devra de nouveau être signée, validée puis publiée

4.2.37. UC-35 : Synchroniser l’annuaire des comptes et des rôles

Acteur principal : Administrateur

Préconditions :

  • L’acteur dispose du droit de synchronisation

Scénario nominal :

  1. L’acteur demande la synchronisation

  2. Le système parcourt l’annuaire du fournisseur d’identité et met à jour le reflet des comptes, des groupes et des appartenances

  3. Le système réaligne les rôles connus du service d’évaluation sur les appartenances relevées

  4. Le système recense les comptes divergents (UC-36)

  5. Le système rend le compte rendu de l’opération

Postconditions :

  • Le reflet local correspond à l’annuaire, et les rôles exploités par les écrans correspondent aux appartenances relevées

Scénarios alternatifs :

  • 2a. Un groupe a disparu de l’annuaire : le système retire le groupe du reflet local

  • 3a. Échec du réalignement des rôles : le système n’interrompt pas la synchronisation, qui a produit son effet, et signale l’échec partiel

  • 4a. Compte local absent de l’annuaire : le système le signale sans y toucher (UC-36)

La synchronisation va de l’annuaire vers la plateforme, et jamais l’inverse. Elle répare un reflet désaligné ; elle ne crée ni ne modifie aucun compte chez le fournisseur d’identité.

4.2.38. UC-36 : Traiter les comptes divergents

Acteur principal : Administrateur

Préconditions :

  • Un recensement a relevé au moins un compte connu de la plateforme et absent de l’annuaire

Scénario nominal :

  1. L’acteur consulte la liste des comptes divergents

  2. L’acteur examine un compte et constate sa disparition de l’annuaire

  3. L’acteur décide de le mettre à l’écart

  4. Le système confirme l’absence du compte dans l’annuaire, puis le met à l’écart et clôt les demandes de rôle qui le visaient

Postconditions :

  • Le compte n’est plus actif dans la plateforme et ses demandes ouvertes sont closes ; son historique reste consultable

Scénarios alternatifs :

  • 4a. Le compte est en réalité présent dans l’annuaire : le système refuse la mise à l’écart. Le recensement avait relevé une absence qui n’en était pas une

Le système observe sans corriger de lui-même. Un rattachement automatique exposerait à ce qu’une adresse réattribuée hérite des dossiers de son précédent titulaire : la mise à l’écart reste donc une décision humaine, prise au vu du compte.

4.2.39. UC-37 : Attribuer ou retirer un rôle directement

Acteur principal : Administrateur

Acteurs secondaires : Délégué DCE

Préconditions :

  • L’acteur dispose du droit d’attribution

  • Le compte visé est connu de la plateforme

Scénario nominal :

  1. L’acteur ouvre la fiche du compte et consulte ses rôles

  2. L’acteur attribue ou retire un rôle, en motivant sa décision

  3. Le système inscrit le changement chez le fournisseur d’identité et en reporte l’effet dans la plateforme

  4. Le système conserve la décision, son auteur et son motif, au même titre qu’une demande approuvée

Postconditions :

  • Le rôle est effectif, et la décision est tracée

Scénarios alternatifs :

  • 2a. Rôle d’administration : seul un administrateur attribue ou retire les rôles Administrateur et Délégué DCE, et nul ne se retire à lui-même le rôle Administrateur

  • 2b. Retrait incohérent : le rôle Enseignant ne se retire pas tant que l’utilisateur est Responsable académique ; le système refuse

  • 3a. Échec du report dans la plateforme : le système rétablit l’état antérieur chez le fournisseur d’identité

Une attribution directe laisse la même trace qu’une demande approuvée. Elle n’est pas un raccourci qui échapperait à l’historique : c’est le même geste, sans l’étape de la demande.

4.2.40. UC-38 : Réinitialiser un mot de passe

Acteur principal : Utilisateur authentifié

Acteurs secondaires : Administrateur

Préconditions :

  • Le compte visé est actif

Scénario nominal :

  1. L’utilisateur demande la réinitialisation de son mot de passe

  2. Le système demande au fournisseur d’identité d’engager la réinitialisation

  3. Le fournisseur d’identité adresse au titulaire du compte le message qui lui permet de choisir un nouveau mot de passe

Postconditions :

  • La réinitialisation est engagée ; elle s’achève hors de la plateforme

Scénarios alternatifs :

  • 1a. Réinitialisation demandée pour un tiers : un administrateur peut l’engager pour le compte d’un autre utilisateur ; le message part vers l’adresse de ce compte, et non vers celle du demandeur

Le mot de passe n’est à aucun moment manipulé par la plateforme, qui ne le voit ni ne le transporte. Elle ne fait que demander au fournisseur d’identité d’engager la démarche.

4.2.41. UC-39 : Recevoir les évènements du fournisseur d’identité

Acteur principal : Système

Préconditions :

  • Le fournisseur d’identité est configuré pour transmettre ses évènements à la plateforme

Scénario nominal :

  1. Le fournisseur d’identité transmet un évènement : inscription, création, modification ou suppression d’un compte, création, modification ou suppression d’un groupe, adhésion ou retrait d’un groupe, connexion

  2. Le système vérifie l’authenticité de l’évènement et son horodatage

  3. Le système consigne l’évènement

  4. Le système met à jour le reflet concerné : le compte, le groupe, ou l’appartenance

  5. Lorsque l’évènement porte sur une appartenance, le système en reporte l’effet sur les rôles exploités par le service d’évaluation

Postconditions :

  • Le reflet local est à jour sans qu’aucune synchronisation n’ait été demandée, et l’évènement est consigné

Scénarios alternatifs :

  • 2a. Évènement non authentifié, ou horodaté hors de la tolérance admise : le système le refuse

  • 4a. Suppression d’un compte : le système met le compte à l’écart et clôt les demandes de rôle qui le visaient

  • 4b. Compte encore inconnu de la plateforme : le système en crée le reflet à partir des données portées par l’évènement, sans interroger l’annuaire

La trace d’un évènement d’identité consigne le type d’évènement, le compte concerné et la liste des attributs modifiés, sans leur valeur. Les évènements transmis peuvent porter l’identifiant national, le matricule et la date de naissance ; la trace dit que l’identité a été modifiée, sans en recopier le contenu.

4.2.42. UC-40 : Gérer ses préférences de notification

Acteur principal : Utilisateur authentifié

Préconditions :

  • L’utilisateur possède un compte actif

Scénario nominal :

  1. L’utilisateur consulte ses préférences de notification

  2. L’utilisateur accepte ou refuse chaque canal : le courriel, le dépôt dans l’application

  3. Le système enregistre les préférences et s’y conforme pour les notifications suivantes

Postconditions :

  • Les notifications ne sont plus déposées sur les canaux refusés

Scénarios alternatifs :

  • 2a. Tous les canaux refusés : les notifications restent consignées et consultables, mais ne sont plus poussées vers l’utilisateur

À défaut de réglage, les valeurs par défaut s’appliquent : tous canaux acceptés. Les préférences ne sont consultées que pour les envois adressés à des personnes nommées ; un envoi à un rôle ou en diffusion générale ne les lit pas.

4.2.43. UC-41 : Gérer les modèles de notification

Acteur principal : Administrateur

Préconditions :

  • L’acteur dispose du droit de gestion des modèles

Scénario nominal :

  1. L’acteur consulte les modèles de notification

  2. L’acteur crée ou modifie un modèle : son objet, son contenu, les éléments qu’il attend de l’évènement

  3. L’acteur renseigne le modèle dans chaque langue retenue

  4. L’acteur active le modèle

  5. Le système emploie le modèle pour les notifications suivantes

Postconditions :

  • Le modèle est disponible et les notifications qui s’y réfèrent en reprennent le contenu

Scénarios alternatifs :

  • 3a. Langue non renseignée : le système retient la version française

  • 4a. Modèle désactivé : les notifications qui s’y réfèrent ne sont plus composées

4.3. Règles de gestion

4.3.1. RG1 - Règles transversales

ID Règle de Gestion

RG1.1

Toute modification doit être historisée avec l’auteur, la date et le motif

RG1.2

Les suppressions se font par désactivation (pas de suppression physique)

RG1.3

Les actions sensibles nécessitent une authentification préalable

RG1.4

Une saisie en cours survit à une interruption de la connexion : elle est conservée sur le poste et rendue à son auteur au retour de la connexion

RG1.5

Une soumission faite hors connexion est mise en attente sur le poste, son auteur en est informé, et elle part dès que la connexion revient. Cela vaut pour le dépôt d’un dossier par l’enseignant et pour la réponse d’un étudiant à une évaluation

4.3.2. RG2 - Gestion des dossiers enseignants

ID Règle de Gestion

RG2.1

Le contenu minimal d’un dossier est défini par les formulaires attachés au profil de l’enseignant ; les champs obligatoires et les bornes d’ancienneté sont fixés à la configuration de ces formulaires

RG2.2

Les données de base de l’enseignant proviennent de bdes-referentiel (lecture seule)

RG2.3

Un enseignant n’a qu’un seul dossier actif par campagne ; cette unicité est garantie par une contrainte de la base, qui exclut les dossiers retirés

RG2.4

La soumission d’un dossier est irréversible, sauf demande de révision : par la DCE avant affectation, ou par la CTE pendant l’évaluation

4.3.3. RG3 - Gestion des campagnes

ID Règle de Gestion

RG3.1

Une campagne porte un nom, une date de début, une date de fin et une date limite de soumission ; elle ne vise pas un établissement en particulier

RG3.2

La sélection d’un enseignant déclenche la création automatique de son dossier

RG3.3

Les enseignants sélectionnés sont notifiés automatiquement

RG3.4

Tout acte du circuit d’évaluation — revue, affectation, remplissage, signature, validation, publication — exige une campagne au statut ACTIVE. Une campagne clôturée, archivée ou encore planifiée bloque l’ensemble du circuit, et pas seulement la modification des dossiers

RG3.5

L’historique complet des campagnes passées doit être conservé

RG3.6

La clôture automatique à la date de fin rend inachevable toute évaluation encore en cours ; la reprise suppose de rouvrir la campagne, ce que sa réversibilité permet

4.3.4. RG4 - Gestion des CTE

ID Règle de Gestion

RG4.1

Un CTE comprend de 3 à 5 évaluateurs actifs — bornes paramétrables (cte.min-members, cte.max-members) — dont un rapporteur unique ; un second rapporteur ou un second superviseur est refusé

RG4.2

Un évaluateur ne peut pas être affecté au dossier dont il est l’auteur. Le système signale par ailleurs trois situations de conflit d’intérêt : l’évaluateur relève de la même UFR ou du même département que l’enseignant évalué, il a avec lui un lien hiérarchique direct, ou une co-signature apparaît entre eux dans les travaux déclarés au dossier

RG4.3

Chaque évaluateur n’a qu’un seul type d’expertise par évaluation

RG4.4

Lorsque toutes les signatures attendues sont réunies, le système fait avancer l’évaluation de lui-même ; aucun acteur ne valide pour le compte de la CTE

RG4.5

Le passage du dossier au statut EVALUATION_REMPLISSAGE_TERMINE clôt le remplissage par la CTE. La validation de la commission s’achève ensuite d’elle-même, une fois réunies toutes les signatures de la CTE, ou celles de tous les experts lorsqu’il n’y a pas de CTE

RG4.6

Seul un utilisateur portant le rôle Évaluateur peut être membre d’un CTE ; le superviseur d’une affectation n’est pas obligatoire, et nul ne peut s’affecter comme expert sur son propre dossier

4.3.5. RG5 - Évaluations pédagogiques

ID Règle de Gestion

RG5.1

Chaque session d’évaluation porte sur un cours et un enseignant ; les jetons sont générés par session, par lots de 500 au plus

RG5.2

L’unicité d’une réponse repose sur le jeton : consommé, il ne peut plus servir. Aucune identité d’étudiant n’étant enregistrée, la solution ne peut pas constater qu’une même personne répond deux fois avec deux jetons

RG5.3

L’accès au formulaire se fait sans authentification (via code uniquement)

RG5.4

Aucun lien traçable ne doit exister entre un étudiant et ses réponses

RG5.5

Les résultats sont présentés de manière agrégée ; la restitution ne comporte ni valeur de jeton, ni horodatage de soumission, qui permettraient de reconstituer un ordre de passage

4.3.6. RG6 - Formulaires d’évaluation

ID Règle de Gestion

RG6.1

Un formulaire est structuré en sections, critères et pondérations

RG6.2

Un formulaire en brouillon ou en attente de validation se modifie sur place ; reprendre un formulaire publié crée une nouvelle version, et le schéma reste figé sur les dossiers déjà servis

RG6.3

Un formulaire doit être approuvé avant utilisation en campagne

RG6.4

Les formulaires obsolètes sont archivés mais non supprimés

RG6.5

Les critères peuvent être obligatoires ou optionnels

4.3.7. RG7 - Validation finale

ID Règle de Gestion

RG7.1

Seuls les dossiers au statut EVALUATION_VALIDATION_CTE — remplissage terminé puis validé par le superviseur — sont accessibles à la validation du Délégué DCE

RG7.2

L’appréciation finale comprend : décision + commentaire obligatoire

RG7.3

La signature électronique du délégué est obligatoire pour valider

RG7.4

L’enseignant est notifié et peut consulter son dossier validé

RG7.5

Nul ne valide l’évaluation de son propre dossier ; ce refus ne souffre aucune exception de rôle

4.3.8. RG8 - Planification des enseignements et calendrier académique

ID Règle de Gestion

RG8.1

Seul un utilisateur rattaché à une UFR par une fonction ouvrant droit à la planification peut y planifier

RG8.2

La planification porte sur un élément constitutif, un enseignant et une année académique

RG8.3

Deux séances du même enseignant sur une même année académique ne peuvent se chevaucher. Toute séance non créée figure au rapport avec son motif : aucune ligne déposée ne disparaît sans être décomptée

RG8.4

Les bornes du calendrier académique — jours fériés, périodes non enseignées — s’appliquent à tous les chemins de création de créneaux, import en masse compris

RG8.5

La modification du calendrier académique ne reprend pas les créneaux déjà générés ; elle ne vaut que pour les générations suivantes

RG8.6

L’écriture dans le référentiel passe exclusivement par le compte de service ; aucun écran n’y écrit directement

RG8.7

Les imports en masse rendent un rapport dénombrant les lignes traitées, insérées, mises à jour, ignorées et en erreur. La création d’un jour férié, d’une période non enseignée ou d’un créneau-type ne rend pas de rapport

4.3.9. RG9 - Visites de terrain

ID Règle de Gestion

RG9.1

Une visite ne peut porter que sur un dossier auquel l’évaluateur est déjà affecté

RG9.2

Une visite se pose sur un créneau de cours de l’enseignant, ou hors cours ; hors cours, le lieu est obligatoire

RG9.3

Une visite ne peut commencer dans le passé ni dépasser la date de fin de la campagne

RG9.4

Une visite ne peut être posée que si la campagne est ACTIVE, que l’affectation n’est pas close, et que l’évaluation n’est pas déjà finalisée (remplissage terminé, signée, validée ou publiée). Un créneau postérieur à l’échéance d’évaluation ou tombant un jour férié est signalé mais accepté : ce sont des indications, non des interdits

RG9.5

Un même évaluateur ne peut avoir deux visites qui se chevauchent, tous dossiers confondus

RG9.6

Deux visites non annulées du même dossier ne peuvent se chevaucher

RG9.7

L’annulation d’une visite exige un motif

RG9.8

Une visite ne peut être déclarée réalisée qu’après son début, et jamais à une date future ; la déclaration est réversible

RG9.9

Au retrait d’un évaluateur, sa ligne est d’abord rattachée à son autre voie si elle est encore active ; sinon elle est retirée. La visite n’est annulée que s’il ne reste plus aucun évaluateur actif, et seulement pour les visites à venir. L’historique conserve le nom de l’évaluateur retiré et le motif

RG9.10

Les créneaux proposés couvrent au plus 90 jours à venir, et l’amplitude lue ne peut excéder 120 jours (valeurs figées)

RG9.11

Une modification concurrente est refusée : l’auteur et l’heure de la dernière modification sont restitués

RG9.12

La fonctionnalité est gouvernée par un interrupteur applicatif (visites.terrain.enabled) ; désactivée, seule la lecture de son état reste accessible

RG9.13

Une visite sur un cours exige que l’enseignant ait un matricule et que le créneau existe au référentiel, à l’identique

RG9.14

Un évaluateur de voie ENQUÊTEUR seule ne peut pas être porté sur une visite de type COURS

RG9.15

Une visite n’est modifiable qu’au statut PLANIFIEE ; une visite réalisée doit d’abord revenir à ce statut pour être annulée

RG9.16

La date de réalisation ne peut être ni postérieure à l’instant présent, ni antérieure au début de la visite

4.3.10. RG10 - Rapports d’experts et modèles de rapport

ID Règle de Gestion

RG10.1

Un rapport est produit à partir d’un modèle rattaché à la campagne

RG10.2

Un modèle porte une période de validité et l’une des quatre portées : INDIVIDUAL (un rapport par évaluateur), CTE (conjoint aux membres du CTE), EXPERT_GROUP (conjoint aux experts externes au CTE), GLOBAL (conjoint à tous)

RG10.3

Les rapports conjoints ne sont pas créés par un acteur : le système les crée à l’ouverture de l’évaluation, un par modèle de portée conjointe de la campagne, et complète les signatures attendues à chaque ajout d’un expert ou d’un membre de CTE

RG10.4

La portée d’un rapport détermine qui peut le remplir : un rapport de portée CTE n’est remplissable que par un membre du CTE

RG10.5

Un rapport individuel de campagne est unique pour un triplet campagne, évaluateur et modèle ; son amorçage est sans effet s’il existe déjà

RG10.6

Un modèle publié n’est plus modifiable ; il peut être cloné pour repartir d’un brouillon indépendant

RG10.7

Un rapport conjoint est renseigné et signé par les évaluateurs d’une même évaluation ; un rapport individuel n’engage que son auteur

RG10.8

Un rapport suit les statuts DRAFT, PENDING_VALIDATION, SUBMITTED, VALIDATED et RETURNED

RG10.9

Un rapport conjoint passe à PENDING_VALIDATION dès la première signature ; il ne peut être soumis que lorsque tous les signataires attendus ont signé

RG10.10

Le retour pour correction d’un rapport conjoint réinitialise toutes les signatures déjà apposées

RG10.11

Un rapport validé n’est plus modifiable ; il reste consultable et imprimable

RG10.12

Une modification du contenu d’un rapport conjoint invalide les signatures déjà apposées, qui doivent être reprises. Nul ne peut se trouver signataire d’un texte qu’il n’a pas vu

RG10.13

Nul ne valide ni ne retourne un rapport qu’il a renseigné ou signé, individuel comme conjoint

RG10.13bis

Le retour en correction d’un rapport conjoint est réservé au Délégué DCE

RG10.14

Un modèle de rapport référencé par au moins un rapport ne peut pas être supprimé

4.3.11. RG11 - Évaluation étudiante et accès anonyme

ID Règle de Gestion

RG11.1

Aucune identité d’étudiant n’est enregistrée : ni nom, ni adresse, ni identifiant

RG11.2

Les jetons sont distribués de façon non nominative, hors de la solution : nul ne consigne qui reçoit quel jeton. Cette hypothèse de fonctionnement conditionne l’anonymat au même titre que l’absence d’identité enregistrée

RG11.3

La restitution des résultats ne comporte aucun élément permettant de reconstituer un ordre de passage ou une identité

RG11.4

L’accès au formulaire se fait par un jeton à usage unique, sans authentification

RG11.5

Un jeton consommé ne peut plus servir

RG11.6

La longueur du jeton est un paramètre applicatif (student_eval_token_length) ; les tentatives sont limitées par minute et par origine

RG11.7

Une session suspendue ou close n’accepte plus de réponse

RG11.8

Une session d’évaluation étudiante ne peut être ouverte, ni recevoir de réponse, que pendant la période d’activité de la campagne dont elle relève ; les résultats agrégés ne changent plus après la clôture

RG11.9

Une session ne peut être supprimée que si elle ne porte aucune réponse

RG11.10

Le nombre de jetons ouverts est plafonné pour l’ensemble du geste, et non par session ; au-delà, la demande est refusée avec son motif

4.3.12. RG12 - Habilitations, périmètres et rôles

ID Règle de Gestion

RG12.1

Tout accès à une ressource est soumis à une permission ; aucun point d’entrée n’est ouvert sans règle explicite

RG12.2

Les accès sans authentification sont déclarés explicitement et limités en débit : trois pour le parcours étudiant, et la consommation d’un code d’invitation externe — ce dernier relevant d’une voie abandonnée, dont le retrait est prévu

RG12.3

Le périmètre des données rendues dépend du rôle : le Délégué DCE voit l’ensemble, le Superviseur ses affectations, l’évaluateur ses dossiers, l’enseignant les siens

RG12.4

Nul ne valide l’évaluation de son propre dossier ; ce refus ne souffre aucune exception de rôle

RG12.5

Le matricule rattache un compte à sa fiche du référentiel ; sans lui, le compte reste détaché de ses dossiers et de ses enseignements

RG12.6

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

4.3.13. RG13 - Comptes, identité et rôles

ID Règle de Gestion

RG13.1

Le fournisseur d’identité fait foi pour l’identité et l’authentification. La plateforme en tient le reflet et n’écrit jamais l’identité à sa place

RG13.2

Un compte est identifié par l’identifiant que lui donne le fournisseur d’identité. C’est cette clé, et non l’adresse électronique ni le matricule, qui relie le compte à ses rôles et à ses demandes

RG13.3

Un rôle est porté par l’appartenance à un groupe chez le fournisseur d’identité. La plateforme n’en conserve qu’un reflet, et le jeton de l’utilisateur en est la seule preuve à l’exécution

RG13.4

Un rôle n’est jamais effectif d’un seul côté : si son inscription chez le fournisseur d’identité aboutit et que son report échoue, l’état antérieur est rétabli

RG13.5

Nul ne s’attribue un rôle : ni par une demande qu’il approuve lui-même, ni au titre d’une demande dont il est la cible

RG13.6

Les rôles d’administration — Administrateur, Délégué DCE — ne se demandent pas : ils s’attribuent directement, et seul un administrateur les accorde ou les retire. Nul ne se retire à lui-même le rôle Administrateur

RG13.7

Une attribution directe laisse la même trace qu’une demande approuvée, avec son auteur, sa cible et son motif

RG13.8

Un retrait qui laisserait l’utilisateur dans un état incohérent est refusé : le rôle Enseignant ne se retire pas tant que l’utilisateur est Responsable académique

RG13.9

Une demande traitée ne se retraite pas. Un statut ne se pose qu’une fois, et ne contredit jamais l’état effectif du rôle chez le fournisseur d’identité

RG13.10

Le mot de passe n’est ni vu ni transporté par la plateforme : elle demande au fournisseur d’identité d’engager la réinitialisation, qui s’achève hors d’elle

RG13.11

Un compte connu de la plateforme et absent de l’annuaire est signalé, non corrigé d’office. Sa mise à l’écart est une décision humaine, prise au vu du compte

RG13.12

La disparition d’un compte clôt les demandes de rôle qui le visaient

RG13.13

Les évènements transmis par le fournisseur d’identité sont authentifiés et horodatés ; un évènement non authentifié, ou horodaté hors de la tolérance admise, est refusé

RG13.14

La synchronisation de l’annuaire va vers la plateforme, et jamais l’inverse

RG13.15

Le rattachement d’un compte à sa fiche du référentiel est unique de part et d’autre : une fiche pour un compte, un compte pour une fiche

4.3.14. RG14 - Notifications

ID Règle de Gestion

RG14.1

Une notification n’est émise qu’une fois acquise l’opération qui la motive : aucune notification n’annonce un évènement qui n’a pas eu lieu

RG14.2

Un même évènement ne notifie qu’une fois, même rejoué

RG14.3

Le contenu d’une notification vient d’un modèle, dans la langue du destinataire, avec repli sur le français

RG14.4

Les canaux de remise sont le courriel et le dépôt dans l’application. Le destinataire choisit ceux qu’il accepte, et son choix n’admet pas d’exception — y compris lorsque l’envoi le désigne par son rôle et non par son nom

RG14.5

L’état de remise est conservé par canal — émise, remise, lue, en échec. L’état d’ensemble s’en déduit et ne se saisit pas

RG14.6

Une remise en échec est réessayée selon un délai croissant. L’échec définitif est consigné et porté à la connaissance d’un administrateur

RG14.7

L’indisponibilité du service de notification ne fait pas échouer l’opération métier : la notification est conservée par le service émetteur, puis rejouée

RG14.8

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

RG14.9

Un client ne publie pas sur les canaux de diffusion : il n’émet que vers les points d’entrée prévus à cet effet

RG14.10

L’échec d’une notification n’affecte jamais l’évènement métier qui l’a motivée

RG14.11

La manière de désigner les destinataires — par leur nom, par leur rôle, ou par une diffusion générale — ne change pas la remise : la notification est conservée, comptée parmi les non-lues et servie sur les canaux acceptés dans les trois cas

4.4. Paramètres applicatifs

Une partie des valeurs citées dans les règles de gestion n’est pas figée dans la solution : elle est portée par des paramètres applicatifs, modifiables par un administrateur depuis l’écran de configuration (UC-32), sans livraison ni redémarrage.

La distinction importe pour la validation : une valeur paramétrable est un réglage, qui peut être ajusté à l’usage ; une valeur figée est une règle, dont la modification suppose une évolution de la solution.

4.4.1. Paramètres gouvernant une règle de gestion

Clé Ce qu’elle gouverne Valeur Règle concernée

cte.min-members

Nombre minimal d’évaluateurs actifs d’un CTE

3

RG4.1

cte.max-members

Nombre maximal d’évaluateurs actifs d’un CTE

5

RG4.1

campaign.submission-end-min-gap-days

Délai minimal entre la date limite de soumission et la fin de campagne, en jours

7

RG3.1

visites.terrain.enabled

Interrupteur de la fonctionnalité « visites de terrain »

activée

RG9.12

score.override.comment.min.length

Longueur minimale de la justification d’une correction de score

10 caractères

UC-28

comment.max.depth

Profondeur maximale d’un fil de commentaires

1

—

comment.edit.window.minutes

Délai pendant lequel un commentaire reste modifiable par son auteur

15 minutes

—

assignment.export.max-rows

Nombre maximal de lignes d’un export d’affectations

20 000

UC-14 alt 3e

4.4.2. Paramètres de dépôt de fichiers

Clé Ce qu’elle gouverne Valeur

file.max-size-mb

Taille maximale d’un fichier déposé

1 000 Mo

file.allowed-types

Types de fichiers acceptés

PDF, images, documents bureautiques, texte, CSV, JSON, XML, HTML

file.tmp-cleanup-pass2-delay-minutes

Délai avant la seconde passe de nettoyage des fichiers temporaires

15 minutes

4.5. Critères d’acceptation

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

  • Code développé et revu

  • Tests unitaires passent avec couverture >= 80%

  • Tests fonctionnels passent

  • Documentation mise à jour, si applicable

  • Validation COPIL obtenue

  • Déployé en environnement de recette et vérifié à l’écran

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

5.1. Principe de gestion des données

Le module évaluation gère deux catégories de données :

  • Données référentielles : Proviennent de bdes-referentiel (établissements, enseignants, programmes) ; le référentiel en est la source

  • Données d’évaluation : Créées et gérées par bdes-evaluation (campagnes, dossiers, évaluations)

5.1.1. Entités gérées par le module

Entité Description

Utilisateur

Personne inscrite sur la plateforme avec un ou plusieurs rôles (Enseignant, Évaluateur, Superviseur, Délégué, Admin)

Demande de rôle

Requête d’un utilisateur pour obtenir des privilèges supplémentaires (statut : PENDING, APPROVED, REJECTED, CANCELLED)

Campagne

Période d’évaluation avec dates, établissement cible et enseignants sélectionnés

Type d’évaluation

Catégorie de campagne (initiale, périodique, exceptionnelle)

Dossier

Ensemble des éléments soumis par un enseignant pour évaluation

Assignation

Affectation d’un dossier à un CTE pour évaluation

CTE

Commission Technique d’Évaluation composée d’évaluateurs

Membre CTE

Évaluateur affecté à un CTE avec son rôle (Rapporteur, Évaluateur, Superviseur) et son expertise

Évaluation CTE

Grille remplie par le rapporteur et signée par tous les membres de la CTE

Formulaire

Grille structurée de critères d’évaluation versionnée

Réponse formulaire

Réponses saisies pour un formulaire d’évaluation

Évaluation pédagogique

Réponse anonyme d’un étudiant sur un enseignant

Validation DCE

Décision finale avec appréciation et signature

5.1.2. Composantes du dossier enseignant

Le dossier d’évaluation contient les éléments ci-dessous. Ils ne sont pas portés par des entités dédiées du modèle : ce sont des sections des formulaires, et leur contenu est enregistré avec les réponses du dossier.

Composante Description

Articles

Publications dans des revues indexées

Travaux de recherche

Projets de recherche en cours ou terminés

Revues scientifiques

Participation à des comités de revues

Activités de revue

Participation aux activités de revues scientifiques

Brevets

Propriété intellectuelle déposée

Distinctions

Prix, adhésions à des académies ou sociétés savantes

Partenariats

Collaborations avec d’autres institutions

Financements

Fonds de recherche obtenus

Subventions

Aides financières reçues

Cours

Enseignements dispensés

Fichiers

Pièces justificatives téléversées

5.2. Dictionnaire de données

5.2.1. Utilisateur

Attribut Description Obligatoire

Email

Adresse électronique, identifiant de connexion et destination des notifications. La restriction à des domaines institutionnels est un réglage du fournisseur d’identité, activable par environnement

Oui

Nom

Nom de famille

Oui

Prénom

Prénom

Oui

Matricule

Matricule professionnel

Non

NIP

Numéro d’Identification Personnel

Non

Téléphone

Numéro de téléphone

Non

Rôles

Liste des rôles attribués (ENSEIGNANT, EVALUATEUR, SUPERVISEUR, DELEGUE, ADMIN)

Oui

Expertise

Domaine d’expertise (pour les évaluateurs)

Non

Spécialité

Spécialité disciplinaire

Non

Grade

Grade académique

Non

5.2.2. Demande de rôle

Attribut Description Obligatoire

Utilisateur

Utilisateur demandeur

Oui

Rôle demandé

Rôle souhaité (ENSEIGNANT, EVALUATEUR, SUPERVISEUR)

Oui

Justification

Motif de la demande

Oui

Statut

État de la demande : PENDING, APPROVED, REJECTED, CANCELLED

Oui

Traité par

Administrateur ayant traité la demande

Non

Commentaire admin

Commentaire de l’administrateur

Non

Date de décision

Date de traitement de la demande

Non

5.2.3. Campagne

Attribut Description Obligatoire

Intitulé

Nom de la campagne

Oui

Description

Description complémentaire

Non

Année académique

Année sur laquelle porte la campagne

Oui

Date de début

Date à partir de laquelle la campagne est active

Oui

Date de fin

Date à laquelle la campagne se termine

Oui

Date limite de soumission

Échéance de dépôt des dossiers par les enseignants, antérieure à la fin de campagne

Oui

Enseignants visés

Les enseignants évalués, désignés par leur matricule

Oui

Types d’évaluation

Natures d’évaluation retenues pour la campagne

Oui

Formulaires

Formulaires rattachés à la campagne

Oui

Modèles de rapport

Modèles rattachés, qui déterminent les rapports à produire

Non

Statut

État de la campagne : PLANIFIEE, ACTIVE, TERMINEE, ARCHIVEE

Oui

5.2.4. Dossier

Attribut Description Obligatoire

Numéro

Identifiant unique du dossier

Oui

Campagne

Campagne de rattachement

Oui

Enseignant

Enseignant concerné (référence bdes-referentiel)

Oui

Statut

État du dossier. Les valeurs et leurs passages sont décrits au chapitre des fonctionnalités

Oui

Date de création

Date de création du dossier

Oui

Date de soumission

Date de soumission par l’enseignant

Non

Date de validation

Date de validation finale DCE

Non

5.2.5. CTE (Commission Technique d’Évaluation)

Attribut Description Obligatoire

Code

Identifiant unique de la CTE

Oui

Dossier

Dossier évalué

Oui

Superviseur

Superviseur coordonnant La CTE

Oui

Rapporteur

Évaluateur désigné comme rapporteur

Oui

Date de constitution

Date de création de la CTE

Oui

Statut

Type de commission, qui distingue la commission d’évaluation des autres formations retenues

Oui

5.2.6. Évaluateur (membre de la CTE)

Attribut Description Obligatoire

CTE

CTE de rattachement

Oui

Enseignant

Enseignant évaluateur (référence bdes-referentiel)

Oui

Expertise

Type d’expertise (Pédagogique, Scientifique, Administrative)

Oui

Est rapporteur

Indique si c’est le rapporteur

Oui

Date d’affectation

Date d’affectation à la CTE

Oui

5.2.7. Formulaire

Attribut Description Obligatoire

Code

Identifiant unique du formulaire

Oui

Intitulé

Nom du formulaire

Oui

Version

Numéro de version

Oui

Statut

État du formulaire : DRAFT, WAITING_APPROVAL, PUBLISHED, ARCHIVED

Oui

Date de création

Date de création

Oui

Date d’approbation

Date d’approbation DCE

Non

5.2.8. Section

Attribut Description Obligatoire

Formulaire

Formulaire de rattachement

Oui

Intitulé

Nom de la section

Oui

Ordre

Position dans le formulaire

Oui

Pondération

Poids de la section dans l’évaluation globale

Oui

5.2.9. Critère

Attribut Description Obligatoire

Section

Section de rattachement

Oui

Intitulé

Libellé du critère

Oui

Type

Type de réponse (Note, Texte, Oui/Non)

Oui

Pondération

Poids du critère dans la section

Oui

Obligatoire

Indique si le critère est obligatoire

Oui

Ordre

Position dans la section

Oui

5.2.10. Évaluation pédagogique

Attribut Description Obligatoire

Code anonyme

Hash du code d’accès (pour unicité)

Oui

Enseignant

Enseignant évalué

Oui

Campagne

Campagne de rattachement

Oui

Date de soumission

Date de l’évaluation

Oui

Réponses

Réponses aux critères du formulaire

Oui
Aucune information permettant d’identifier l’étudiant n’est stockée.

5.2.11. Validation DCE

Attribut Description Obligatoire

Dossier

Dossier validé

Oui

Délégué

Délégué DCE ayant validé

Oui

Décision

Décision finale (FAVORABLE, DEFAVORABLE, AVEC_RESERVES)

Oui

Appréciation

Commentaire du délégué

Oui

Date de validation

Date de la validation

Oui

Signature

Signature électronique du délégué

Oui

5.3. Relations principales entre entités

Entité source Relation Entité cible

Campagne

1:N

Dossier

Dossier

1:1

CTE

CTE

1:N

Évaluateur (membre)

Dossier

1:1

Validation DCE

Formulaire

1:N

Section

Section

1:N

Critère

Campagne

N:M

Formulaire

Enseignant (ref)

1:N

Évaluation pédagogique

6. Exigences non-fonctionnelles

6.1. Performance

Exigence Description Cible

Temps de réponse interface

Temps de chargement des pages de l’application

< 2 secondes (95% des requêtes)

Temps de réponse formulaires

Temps de soumission d’un formulaire d’évaluation

< 3 secondes

Capacité utilisateurs

Nombre d’utilisateurs actifs simultanés supportés

100 utilisateurs

Temps de génération rapport

Temps de génération d’un rapport PDF

< 10 secondes

6.2. Disponibilité

Exigence Description Cible

Disponibilité globale

Taux de disponibilité du service

>= 99.5%

Plages d’utilisation

Heures de disponibilité garantie

24h/24, 7j/7

Maintenance planifiée

Préavis pour maintenance

7 jours minimum

Fenêtre de maintenance

Créneau de maintenance préféré

Dimanche 2h-6h

Temps de reprise

Délai de reprise après incident

< 30 secondes

6.3. Volumétrie

Donnée Estimation

Nombre de campagnes par an

~xxxx

Nombre d’enseignants évalués par an

~xxxx

Nombre d’étudiants évaluateurs

~xxxx

Nombre de dossiers par campagne

~xxxx

Nombre d’évaluations pédagogiques par campagne

~xxxx

Taille moyenne d’un dossier (pièces jointes)

~xxxx Mo

Croissance annuelle estimée

+10%

Utilisateurs simultanés (pic)

~xxxx

6.4. Sécurité et Confidentialité

6.4.1. Authentification et Autorisation

Exigence Description

Authentification centralisée

Authentification unique pour tous les utilisateurs du système

Gestion des rôles

Contrôle d’accès basé sur les rôles (Délégué, Superviseur, Évaluateur, Enseignant)

Expiration de session

Session inactive expirée après 30 minutes

Accès anonyme

Évaluations pédagogiques accessibles uniquement via code d’anonymat

6.4.2. Protection des données

Exigence Description

Chiffrement en transit

Communications chiffrées pour toutes les échanges

Chiffrement au repos

Données sensibles chiffrées en base

Anonymat étudiants

Aucun lien traçable entre un étudiant et ses évaluations

Journalisation

Toutes les actions sensibles sont tracées

Confidentialité dossiers

Accès aux dossiers limité aux acteurs autorisés

6.4.3. Matrice de droits/habilitations

Fonctionnalité Admin Délégué DCE Superviseur Évaluateur Enseignant Étudiant

Gérer les comptes et les rôles

Oui

Oui

Oui

Non

Non

Non

Créer une campagne

Oui

Oui

Non

Non

Non

Non

Affecter un dossier à un CTE

Oui

Oui

Oui

Non

Non

Non

Constituer son dossier

Non

Non

Non

Non

Oui

Non

Répondre à une évaluation pédagogique

Non

Non

Non

Non

Non

Oui

Évaluer un dossier

Oui

Oui

Non

Oui

Non

Non

Valider le rapport d’un CTE

Oui

Oui

Sur son périmètre

Non

Non

Non

Valider une évaluation pour la DCE

Oui

Oui

Sur son périmètre

Non

Non

Non

Publier une évaluation à l’enseignant

Oui

Oui

Sur son périmètre

Non

Non

Non

Ouvrir une session d’évaluation étudiante

Oui

Oui

Oui

Non

Non

Non

Consulter le journal d’audit

Oui

Oui

Non

Non

Non

Non

Gérer les formulaires

Oui

Oui

Oui

Non

Non

Non
Les rôles se composent. Le Délégué DCE hérite du Superviseur et de l’Évaluateur, le Superviseur et l’Évaluateur héritent du rôle socle, et l’Administrateur porte toutes les autorisations : un « Non » signale donc l’absence d’autorisation propre, non une interdiction.
Deux acteurs distincts portent le nom de superviseur, et il faut les tenir séparés.

  1. Le Superviseur, colonne de ce tableau : il coordonne les commissions, affecte les dossiers, gère les formulaires, les comptes et les sessions d’évaluation étudiante. Désigné superviseur d’une affectation, il la pilote et ne voit que son périmètre.

  2. Le président d’un CTE, membre de la commission évaluatrice : il évalue et signe, au même titre que le rapporteur. Les écrans l’affichent « Président ».

Les trois lignes marquées « Sur son périmètre » — valider le rapport d’un CTE, valider pour la DCE, publier à l’enseignant — sont exercées par le Superviseur sur les seules affectations dont il est désigné superviseur, et par le Délégué DCE sans restriction de périmètre. Le président du CTE ne les exerce pas : son rôle dans la commission est d’évaluer et de signer.

6.5. Traçabilité et Audit

Exigence Description

Historique complet

Conservation de l’historique de toutes les modifications

Immuabilité

Les logs d’audit ne peuvent pas être modifiés ou supprimés

Horodatage

Chaque action est horodatée avec précision

Identification

Chaque action est associée à l’utilisateur responsable

Conservation

Durée de conservation des audits : 10 ans minimum

6.6. Accessibilité et Internationalisation

Exigence Description

Langue principale

Français

Langues

Français et anglais, au choix de l’utilisateur, son choix étant conservé d’une session à l’autre

Accessibilité

Interface conforme WCAG 2.1 niveau AA (cible)

Navigation clavier

Toutes les fonctionnalités accessibles au clavier

Responsive

Interface adaptée desktop, tablette et mobile

Formats de date

Format français (JJ/MM/AAAA)

Encodage

UTF-8 pour tous les échanges

6.7. Notifications

Exigence Description

Délai d’envoi

Notifications critiques envoyées en moins de 2 minutes

Canaux

Email (obligatoire), notifications in-app (optionnel)

Gestion des échecs

Réessai automatique en cas d’échec d’envoi

Événements notifiés

Sélection campagne, soumission dossier, demande révision, validation CTE, validation DCE

7. Contraintes et Interfaces

7.1. Contraintes métier

ID Contrainte Impact

CM-01

Le système doit respecter le calendrier académique béninois

Planification des campagnes alignée sur l’année universitaire

CM-02

L’anonymat des évaluations étudiantes est une obligation légale

Architecture garantissant l’impossibilité de traçage

CM-03

Les formulaires d’évaluation doivent être validés par la DCE avant usage

Workflow d’approbation obligatoire

CM-04

La signature électronique a valeur légale

Intégration d’un système de signature conforme

CM-05

Conservation des dossiers pendant 10 ans minimum

Archivage long terme avec intégrité garantie

7.2. Contraintes organisationnelles

ID Contrainte Impact

CO-01

La validation finale relève de la DCE : elle est exercée par le Délégué DCE sur toute affectation, et par un Superviseur sur les seules affectations dont il est désigné superviseur. Par nul autre

Workflow centralisé vers la DCE

CO-02

Les établissements conservent leur autonomie organisationnelle

Flexibilité dans la configuration des campagnes

CO-03

Le COPIL valide les évolutions fonctionnelles majeures

Gouvernance des changements

CO-04

IT-NUM assure le support pendant la première année

Transfert de compétences planifié

7.3. Interfaces avec systèmes externes

7.3.1. IF-01 : bdes-referentiel (appel de service à service)

Caractéristique Description

Type

Consommation de données référentielles

Direction

bdes-evaluation → bdes-referentiel

Données échangées

Établissements, UFR, Enseignants, Programmes

Fréquence

À la consommation

Mode

Consultation des données de référence ; écriture des maquettes et des planifications par le compte de service

7.3.2. IF-02 : Service d’authentification centralisée

Caractéristique Description

Type

Authentification et gestion des identités

Direction

Bidirectionnelle

Fonctions

Authentification unique, gestion des rôles, permissions

Utilisateurs

Tous les utilisateurs authentifiés du système

7.3.3. IF-03 : Service de messagerie

Caractéristique Description

Type

Envoi de notifications par email

Direction

bdes-evaluation → Service email

Fonctions

Notifications automatiques aux acteurs de la plateforme et rappels d’échéance

Volume estimé

~1000 emails/jour en période de campagne

7.3.4. IF-04 : Stockage de fichiers

Caractéristique Description

Type

Stockage sécurisé de documents

Direction

Bidirectionnelle

Données

CV, publications, diplômes, contrats, rapports

Exigences

Versionnement, intégrité, confidentialité

7.4. Dépendances fonctionnelles

Dépendance Description Criticité

bdes-referentiel

Source des données référentielles (établissements, enseignants)

Critique

Service d’authentification

Gestion des identités et accès

Critique

Service de messagerie

Envoi des notifications et codes anonymes

Haute

Stockage fichiers

Persistance des documents joints

Critique

7.5. Contraintes d’intégration

ID Contrainte

CI-01

Les données référentielles ne se saisissent pas dans bdes-evaluation ; les maquettes et les planifications sont écrites dans le référentiel par le compte de service

CI-02

La consommation des données de bdes-referentiel doit gérer les indisponibilités temporaires

CI-03

Les codes d’anonymat doivent être générés de manière non prédictible

CI-04

La signature électronique doit être conforme aux standards en vigueur

8. Hypothèses et Risques

8.1. Hypothèses de travail

Les hypothèses suivantes constituent le socle sur lequel repose la conception fonctionnelle du module d’évaluation.

8.1.1. Hypothèses relatives aux données

ID Hypothèse

H-01

Les données référentielles (enseignants, établissements, programmes) sont disponibles et fiables dans le système source bdes-referentiel.

H-02

Les volumes de données estimés sont corrects : environ xxxx enseignants évalués par an, xxxx étudiants participants, et xxxx documents traités.

H-03

Les enseignants disposeront d’un accès internet permettant le téléchargement de leurs documents (CV, publications).

H-04

Les jetons d’évaluation sont remis aux étudiants hors de la plateforme, de façon non nominative. L’établissement dispose d’un moyen de les distribuer sans consigner qui reçoit quel jeton.

H-05

Aucune migration de données historiques n’est requise ; le système démarre avec les nouvelles campagnes.

8.1.2. Hypothèses relatives aux utilisateurs

ID Hypothèse

H-06

Les délégués DCE, enseignants et évaluateurs pilotes seront disponibles pour participer aux phases de recette.

H-07

Les utilisateurs finaux disposent de navigateurs modernes (versions récentes de Chrome, Firefox, Safari ou Edge).

H-08

Les formulaires d’évaluation actuels seront fournis par la DCE pour intégration.

H-09

La connexion internet des établissements d’enseignement supérieur est suffisamment stable pour l’utilisation du système.

8.1.3. Hypothèses relatives à l’organisation

ID Hypothèse

H-10

La DCE dispose de l’autorité nécessaire pour valider les formulaires d’évaluation et les décisions finales.

H-11

Le budget alloué est suffisant pour couvrir le développement, les tests, les formations et le support initial.

H-12

L’équipe BDES sera formée et opérationnelle pour assurer le support après la période de transition.

H-13

Les lois béninoises sur la protection des données personnelles permettent le traitement des données d’évaluation.

8.2. Risques identifiés

Les risques suivants ont été identifiés et doivent être surveillés tout au long du projet.

8.2.1. Risques liés aux données et systèmes

ID Description Probabilité Impact Mesures d’atténuation

R-01

Indisponibilité temporaire des données référentielles du système source

Moyenne

Élevé

Mécanisme de cache local, mode dégradé avec données en lecture seule

R-02

Volumes de données supérieurs aux estimations initiales

Faible

Moyen

Conception évolutive dès le départ, surveillance des métriques de croissance

R-03

Service de messagerie indisponible ou saturé en période de campagne

Moyenne

Moyen

Files d’attente avec reprise automatique, notifications alternatives dans l’interface

8.2.2. Risques liés aux utilisateurs

ID Description Probabilité Impact Mesures d’atténuation

R-04

Résistance au changement par les utilisateurs finaux

Moyenne

Élevé

Implication des utilisateurs dès la conception, formations adaptées, support réactif, communication sur les bénéfices

R-05

Disponibilité insuffisante des utilisateurs pilotes pour la recette

Élevée

Moyen

Identification et engagement précoce des pilotes, planification communiquée à l’avance

R-06

Difficultés d’accès au système pour les utilisateurs en zones à faible connectivité

Moyenne

Moyen

Interface optimisée, sauvegarde automatique en cours de saisie, mode offline partiel

8.2.3. Risques liés au processus métier

ID Description Probabilité Impact Mesures d’atténuation

R-07

Changement de scope en cours de projet (nouveaux besoins métier)

Moyenne

Moyen

Gouvernance stricte via le comité de pilotage, priorisation des demandes

R-08

Complexité sous-estimée du processus d’anonymisation des évaluations étudiantes

Moyenne

Élevé

Revue approfondie du mécanisme d’anonymat, validation par des experts

R-09

Non-conformité aux exigences réglementaires

Faible

Critique

Veille réglementaire continue, validation juridique des processus

R-10

Délais de validation DCE allongeant les campagnes

Moyenne

Moyen

Tableaux de bord de suivi, alertes automatiques, rappels aux validateurs

8.2.4. Risques liés à l’adoption

ID Description Probabilité Impact Mesures d’atténuation

R-11

Formation insuffisante des utilisateurs

Faible

Élevé

Sessions de formation dédiées par profil, documentation accessible, aide en ligne contextuelle

R-12

Faible taux de participation des étudiants aux évaluations pédagogiques

Moyenne

Moyen

Sensibilisation via les établissements, interface simple et rapide, rappels automatiques

9. Annexes

9.1. Annexe A : Acronymes

Acronyme Signification

BDES

Base de Données de l’Enseignement Supérieur

COPIL

Comité de Pilotage

CTE

Commission Technique d’Évaluation

CV

Curriculum Vitae

DCE

Délégation au Contrôle et à l’Éthique

MESRS

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

SFD

Spécifications Fonctionnelles Détaillées

UAC

Université d’Abomey-Calavi

UFR

Unité de Formation et de Recherche

UNA

Université Nationale d’Agriculture

UNSTIM

Université Nationale des Sciences, Technologies, Ingénierie et Mathématiques

UP

Université de Parakou

9.2. Annexe B : Matrice des rôles et permissions

La matrice des droits figure au chapitre Exigences de qualité, section « Matrice de droits/habilitations ». Elle porte les six rôles — Administrateur, Délégué DCE, Superviseur, Évaluateur, Enseignant et Étudiant —, la composition qui les relie, et la distinction entre le rôle Superviseur et le superviseur d’une affectation.

9.3. Annexe C : États du dossier d’évaluation

9.3.1. Diagramme des états

sfd eval workflow
Figure 3. Diagramme d’état

9.3.2. Description des états

Les états du dossier et leurs transitions sont décrits au chapitre Vue d’ensemble, qui les regroupe par phase : constitution, revue, évaluation, validation et publication. Les règles qui gouvernent chaque transition, et les acteurs qui en disposent, figurent au chapitre des fonctionnalités.

9.4. Annexe D : Types de formulaires

Type Description Utilisateurs

Formulaire CTE

Grille d’évaluation utilisée par les membres de la CTE pour évaluer les dossiers enseignants

Évaluateurs

Formulaire pédagogique

Questionnaire anonyme pour les étudiants évaluant la qualité de l’enseignement

Étudiants

Auto-évaluation

Formulaire permettant à l’enseignant de présenter ses réalisations et objectifs

Enseignants

9.5. Annexe E : Documents de référence

Document Description

TDRs du projet

Document initial définissant les objectifs et le périmètre du projet

Séances de travail avec la DCE

Plusieurs réunions de travail pour clarifier les besoins

Système d’évaluation existante (Drupal)

Accès pour comprendre l’existant