Fonctionnalité : Créer un compte

Table of Contents

Résumé

Ce document présente la documentation complète de développement pour la fonctionnalité "Créer un compte" (UC-3) du système. Il couvre l’ensemble des aspects techniques, architecturaux et fonctionnels nécessaires à l’implémentation de cette fonctionnalité.

1. Informations générales

Identifiant

FR-3

Cas d’utilisation

UC-3

Alias

Inscription

Priorité

Moyenne

Version

1.1

Statut

Spécifié

2. Description fonctionnelle

2.1. Objectif contextuel

Permettre à un enseignant de créer un compte dans le système afin de pouvoir participer à une partie et utiliser les fonctionnalités du système.

2.2. Portée

Cette fonctionnalité s’inscrit dans le périmètre du Système de gestion des comptes utilisateurs.

2.3. Niveau

Utilisateur - Cette fonctionnalité est accessible directement par l’utilisateur final.

3. Acteurs

3.1. Acteur principal

  • L’enseignant : Utilisateur souhaitant créer un compte pour accéder au système

3.2. Acteur secondaire

  • Serveur d’identification : Système externe responsable de la validation et de l’activation des comptes

4. Conditions et événements

4.1. Événement déclencheur

L’enseignant souhaite participer à une partie et doit pour cela créer un compte dans le système.

4.2. Pré-conditions

  1. L’enseignant est connecté à Internet

  2. L’enseignant possède une adresse email valide

  3. L’enseignant a accès à sa boîte email

4.3. Post-conditions

  1. Le Système connaît l’enseignant à travers son identifiant unique

  2. Le compte de l’enseignant est activé et opérationnel

  3. L’enseignant peut se connecter au système

4.4. Conditions de succès

  • L’enseignant parvient à créer un compte avec succès

  • L’enseignant connaît son identifiant (adresse email)

  • L’enseignant connaît son mot de passe

  • Le compte est validé et activé

4.5. Conditions d’échec

  • L’enseignant n’arrive pas à créer un compte (données invalides, problème technique)

  • L’enseignant crée un compte mais ne connaît pas son identifiant ou son mot de passe

  • Le lien de validation expire avant d’être utilisé

  • L’email de validation n’est pas reçu ou est perdu

5. Scénario nominal

Le scénario nominal décrit le déroulement standard et attendu de la fonctionnalité.

# Description Responsable

1

L’enseignant demande la création d’un compte

Enseignant

2

L’enseignant saisit son adresse email, son nom, son prénom et son mot de passe

Enseignant

3

Le Système envoie une URL unique à l’adresse email de l’enseignant

Système

4

L’enseignant reçoit l’email et ouvre l’URL

Enseignant

5

Le serveur reçoit la requête correspondant à l’URL envoyée et valide l’inscription

Serveur d’identification

6. Conception UML

Cette section présente l’ensemble des diagrammes UML modélisant la fonctionnalité "Créer un compte" sous différents angles : fonctionnel, comportemental, structurel et technique.

6.1. Diagramme de cas d’utilisation

Le diagramme de cas d’utilisation présente une vue d’ensemble des interactions entre les acteurs (Enseignant, Serveur d’identification) et le système pour la création d’un compte.

cas-utilisation-creer-compte
Figure 1. Cas d’utilisation : Créer un compte

Points clés :

  • L’enseignant est l’acteur principal qui initie la création de compte

  • Le serveur d’identification intervient pour valider l’inscription

  • Les relations [include] montrent que l’envoi d’email et la validation sont des étapes obligatoires du processus

6.2. Diagramme de séquence

Le diagramme de séquence détaille chronologiquement les interactions entre tous les participants du système lors de la création d’un compte. Il est divisé en deux phases principales : la création du compte et sa validation.

sequence-creer-compte
Figure 2. Séquence détaillée : Processus de création et validation de compte

Analyse du flux :

6.2.1. Phase 1 : Création du compte

  1. L’enseignant demande l’accès au formulaire d’inscription

  2. Le système affiche le formulaire avec les champs requis

  3. L’enseignant saisit ses informations (email, nom, prénom, mot de passe)

  4. Le système valide les données côté serveur

  5. Le système crée le compte avec un statut "en attente"

  6. Le système génère une URL unique contenant un token de validation

  7. Le service email envoie l’URL à l’enseignant

6.2.2. Phase 2 : Validation du compte

  1. L’enseignant consulte son email et clique sur l’URL

  2. La requête est envoyée au serveur d’identification

  3. Le serveur transmet le token au système

  4. Le système vérifie la validité du token

  5. Le système active le compte

  6. Le serveur d’identification confirme le succès à l’enseignant

Messages clés :

  • Validation des données : Garantit l’intégrité des informations avant création

  • Token unique : Sécurise le processus de validation

  • Confirmation asynchrone : Permet une validation différée via email

6.3. Diagramme d’activité

Le diagramme d’activité illustre le flux de travail détaillé de la création de compte, incluant les points de décision, les chemins alternatifs et la répartition des responsabilités entre acteurs.

activite-creer-compte
Figure 3. Flux d’activité : Création et validation de compte

Points de décision :

6.3.1. Décision 1 : Validation des données

  • Condition : Les données saisies sont-elles valides ?

  • Si oui : Poursuite du processus de création

  • Si non : Affichage des erreurs de validation et arrêt du flux

Critères de validation :

  • Format d’email valide (RFC 5322)

  • Nom et prénom non vides

  • Mot de passe respectant la politique de sécurité (longueur minimale, complexité)

6.3.2. Décision 2 : Validation du token

  • Condition : Le token reçu est-il valide et non expiré ?

  • Si oui : Activation du compte

  • Si non : Affichage d’une erreur "Lien invalide ou expiré"

Responsabilités par couloir :

  • Enseignant : Saisie des données, consultation email, clic sur le lien

  • Système : Validation, création, génération du token, activation

  • Serveur d’identification : Réception des requêtes, affichage des résultats

6.4. Diagramme d’états

Le diagramme d’états représente le cycle de vie complet d’un compte enseignant, de sa création à son activation, en passant par les états transitoires.

etats-compte
Figure 4. États du compte enseignant

États définis :

État Description Actions possibles

Non Existant

État initial avant toute création

Créer un compte

En Attente

Compte créé mais non validé. Email de validation envoyé.

Valider via URL, Expiration automatique

Actif

Compte validé et opérationnel

Utilisation normale du système

Expiré

Token de validation périmé (optionnel)

Suppression automatique, Nouvelle demande

Transitions :

  • NonExistant → EnAttente : Soumission du formulaire d’inscription

  • EnAttente → Actif : Validation réussie via URL unique (token valide)

  • EnAttente → Expiré : Délai de validation dépassé (ex: 24h)

  • Expiré → NonExistant : Suppression automatique des comptes expirés

L’état "Expiré" est optionnel et dépend de la politique de sécurité mise en place. Il permet d’éviter l’accumulation de comptes non validés.

6.5. Diagramme de classes

Le diagramme de classes présente le modèle objet complet pour la gestion de la création de compte, incluant les entités métier, les services et les repositories.

classes-creer-compte
Figure 5. Modèle de classes : Gestion des inscriptions

Classes principales :

6.5.1. Entités du domaine

Enseignant

Représente un utilisateur enseignant du système.

  • Attributs :

    • id : Identifiant unique (UUID)

    • email : Adresse email (identifiant de connexion)

    • nom, prenom : Informations personnelles

    • motDePasse : Mot de passe hashé (bcrypt/argon2)

    • statut : État actuel du compte (enum)

    • tokenValidation : Token unique pour validation email

    • dateExpirationToken : Date limite de validité du token

    • dateCreation : Horodatage de création

  • Méthodes :

    • creerCompte() : Initialise un nouveau compte

    • validerEmail() : Active le compte après validation

    • estActif() : Vérifie si le compte est utilisable

StatutCompte (Enumération)

Définit les états possibles d’un compte :

  • EN_ATTENTE : En attente de validation email

  • ACTIF : Compte validé et opérationnel

  • EXPIRE : Token de validation périmé

  • SUSPENDU : Compte désactivé (usage futur)

6.5.2. Couche Service

ServiceInscription

Service orchestrant le processus complet d’inscription.

  • Responsabilités :

    • Coordonner les différentes étapes de création

    • Valider les données saisies

    • Générer les tokens de validation

    • Orchestrer l’envoi d’emails

    • Gérer la validation finale

  • Dépendances :

    • EnseignantRepository : Persistance des données

    • ServiceEmail : Envoi d’emails

    • ServeurIdentification : Validation externe

ServiceEmail

Service technique d’envoi d’emails.

  • envoyerEmailValidation() : Envoie l’email contenant l’URL unique

ServeurIdentification

Interface avec le serveur externe d’identification.

  • validerToken() : Vérifie la validité d’un token

  • activerCompte() : Active définitivement un compte

6.5.3. Couche Données

EnseignantRepository

Repository gérant la persistance des enseignants.

  • sauvegarder() : Crée un nouvel enseignant en base

  • rechercherParEmail() : Recherche par adresse email

  • rechercherParToken() : Recherche par token de validation

  • mettreAJour() : Met à jour les informations

ResultatInscription

Objet de transfert (DTO) retournant le résultat d’une inscription.

  • succes : Booléen indiquant le succès

  • message : Message descriptif

  • erreurs : Liste des erreurs de validation

Relations clés :

  • ServiceInscription utilise les repositories et services

  • Enseignant possède un StatutCompte

  • ServiceInscription crée des ResultatInscription

6.6. Diagramme de composants

Le diagramme de composants illustre l’architecture logicielle en couches du système, montrant comment les différents composants interagissent pour réaliser la fonctionnalité de création de compte.

composants-creer-compte
Figure 6. Architecture en composants : Système d’inscription

Architecture en 3 couches :

6.6.1. Couche Présentation

Responsable de l’interface utilisateur et de la gestion des requêtes HTTP.

  • Interface Web Inscription :

    • Pages HTML/JavaScript pour le formulaire d’inscription

    • Validation côté client

    • Gestion de l’affichage des erreurs

  • Contrôleur Inscription :

    • Endpoint REST pour l’inscription (POST /api/inscription)

    • Endpoint pour la validation (GET /api/validation/example-token)

    • Transformation des requêtes HTTP en appels métier

6.6.2. Couche Métier (Business)

Contient la logique métier et les règles de gestion.

  • Service Inscription :

    • Orchestrateur principal du processus

    • Implémente le scénario nominal UC-3

    • Coordonne les services techniques

  • Service Validation :

    • Validation des règles métier

    • Vérification des contraintes (email unique, format, etc.)

    • Validation de la politique de mot de passe

  • Gestionnaire Token :

    • Génération de tokens uniques sécurisés (UUID v4)

    • Vérification de la validité des tokens

    • Gestion des expirations

6.6.3. Couche Infrastructure

Gère la persistance et les services externes.

  • Repository Enseignant :

    • Accès aux données (CRUD)

    • Requêtes SQL via ORM

  • Service Email :

    • Envoi d’emails transactionnels

    • Templates d’emails

    • Gestion de la file d’attente d’envoi

  • Serveur Identification :

    • Interface avec le système d’authentification

    • Validation externe des inscriptions

Composants externes :

  • Base de données : Stockage persistant (PostgreSQL, MySQL, etc.)

  • SMTP Server : Serveur d’envoi d’emails (SendGrid, Amazon SES, etc.)

Flux de données :

HTTP Request → Contrôleur → Service Inscription → Validation/Token → Repository → BD
                                    ↓
                              Service Email → SMTP

6.7. Diagramme de déploiement

Le diagramme de déploiement présente l’infrastructure technique et la distribution physique des composants du système sur les différents nœuds d’exécution.

deploiement-creer-compte
Figure 7. Infrastructure de déploiement

Nœuds d’exécution :

6.7.1. Client Web

  • Navigateur : Chrome, Firefox, Safari, Edge

  • Application Web : Single Page Application (SPA)

    • Frameworks : React, Vue.js ou Angular

    • Communication via HTTPS

    • Validation côté client

6.7.2. Serveur Web

  • Technologie : Apache HTTP Server ou Nginx

  • Rôle :

    • Reverse proxy vers le serveur d’application

    • Servir les fichiers statiques (HTML, CSS, JS, images)

    • Terminaison SSL/TLS

    • Load balancing (optionnel)

  • Configuration :

    • Port 443 (HTTPS)

    • Certificat SSL/TLS

6.7.3. Serveur Application

  • Technologie :

    • Java : Tomcat, Spring Boot, WildFly

    • Node.js : Express, NestJS

    • Python : Django, Flask

    • .NET : ASP.NET Core

  • Composants déployés :

    • API REST (endpoints d’inscription et validation)

    • Services métier (ServiceInscription, etc.)

    • Services techniques (ServiceEmail, etc.)

  • Configuration :

    • Port 8080 (HTTP interne) ou 8443 (HTTPS)

    • Pool de connexions à la base de données

    • Configuration SMTP

6.7.4. Serveur Base de Données

  • Technologie : PostgreSQL 12+, MySQL 8+, ou autre SGBDR

  • Configuration :

    • Port 5432 (PostgreSQL) ou 3306 (MySQL)

    • Authentification sécurisée

    • Encryption des connexions (SSL)

  • Haute disponibilité :

    • Réplication master-slave

    • Sauvegardes automatiques quotidiennes

    • Point-in-time recovery (PITR)

6.7.5. Serveur Email

  • Technologie :

    • Serveur SMTP dédié (Postfix, Sendmail)

    • Service cloud (SendGrid, Amazon SES, Mailgun)

  • Configuration :

    • Port 587 (SMTP avec STARTTLS)

    • Authentification SMTP

    • File d’attente asynchrone pour performances

  • Fonctionnalités :

    • Retry automatique en cas d’échec

    • Logs d’envoi

    • Templates d’emails

6.7.6. Serveur Identification

  • Technologie :

    • OAuth 2.0 / OpenID Connect

    • LDAP / Active Directory

    • Service d’identité dédié (Keycloak, Auth0)

  • Rôle :

    • Validation des tokens

    • Activation des comptes

    • Gestion centralisée de l’authentification

Protocoles et ports :

Source Destination Port Protocole

Navigateur

Serveur Web

443

HTTPS

Serveur Web

Serveur Application

8080

HTTP(S)

Serveur Application

Base de données

5432

PostgreSQL (TCP)

Serveur Application

Serveur Email

587

SMTP (STARTTLS)

Serveur Application

Serveur Identification

443

HTTPS (REST API)

Considérations de sécurité :

  • Toutes les communications externes en HTTPS

  • Chiffrement des mots de passe (bcrypt, argon2)

  • Tokens de validation sécurisés et à usage unique

  • Expiration des tokens (24h recommandées)

  • Firewall entre les différentes couches

  • Isolation réseau (VLANs)

Scalabilité :

  • Horizontale : Ajout de serveurs d’application derrière un load balancer

  • Verticale : Augmentation des ressources (CPU, RAM) des serveurs

  • Cache : Redis/Memcached pour les sessions et données fréquentes

  • CDN : Pour les assets statiques

7. Spécifications techniques

7.1. Données requises

Le formulaire d’inscription doit collecter les informations suivantes :

Champ Type Obligatoire Contraintes

Email

String

Oui

Format RFC 5322, unique dans le système

Nom

String

Oui

2-50 caractères, lettres et espaces autorisés

Prénom

String

Oui

2-50 caractères, lettres et espaces autorisés

Mot de passe

String

Oui

Minimum 8 caractères, au moins 1 majuscule, 1 minuscule, 1 chiffre, 1 caractère spécial

7.2. Règles de validation

7.2.1. Email

  • Format valide selon RFC 5322

  • Unicité dans la base de données

  • Domaine email résolvable (vérification DNS MX optionnelle)

  • Longueur maximale : 255 caractères

7.2.2. Nom et Prénom

  • Caractères autorisés : lettres (UTF-8), espaces, traits d’union, apostrophes

  • Pas de chiffres ni caractères spéciaux

  • Trim des espaces en début et fin

  • Longueur : 2 à 50 caractères

7.2.3. Mot de passe

  • Longueur minimale : 8 caractères (recommandé : 12+)

  • Au moins une lettre majuscule

  • Au moins une lettre minuscule

  • Au moins un chiffre

  • Au moins un caractère spécial (@, #, $, %, etc.)

  • Pas d’utilisation de mots de passe communs (dictionnaire)

  • Hashage avec bcrypt ou argon2 (cost factor 10+)

7.3. Token de validation

7.3.1. Génération

  • Format : UUID v4 ou chaîne aléatoire cryptographiquement sûre

  • Longueur : 32-64 caractères

  • Caractères : alphanumériques (a-zA-Z0-9)

  • Stockage en base de données associé au compte

7.3.2. Validité

  • Durée de vie : 24 heures (configurable)

  • Usage unique : invalidé après utilisation

  • Vérifié lors de la validation du compte

7.3.3. URL de validation

Format : https://domaine.com/validation?token=unique-token-123

Exemple : https://app.example.com/validation?token=a3f5d9c2b7e4f1a8d6c9b2e5f8a1d4c7

7.4. Email de validation

7.4.1. Template

Sujet : Confirmez votre inscription

Bonjour {PRENOM} {NOM},

Merci de vous être inscrit(e) sur notre plateforme.

Pour activer votre compte, veuillez cliquer sur le lien ci-dessous :

{URL_VALIDATION}

Ce lien est valable pendant 24 heures.

Si vous n'êtes pas à l'origine de cette inscription, vous pouvez ignorer cet email.

Cordialement,
L'équipe {NOM_APPLICATION}

7.4.2. Contenu

  • Personnalisation avec nom et prénom

  • Lien cliquable de validation

  • Mention de la durée de validité

  • Instructions claires

  • Informations de contact/support

7.5. Sécurité

7.5.1. Protection contre les attaques

  • Rate limiting : Maximum 5 tentatives d’inscription par IP/heure

  • CAPTCHA : Après 2 échecs de validation

  • Protection CSRF : Token CSRF dans les formulaires

  • Validation stricte : Côté client ET serveur

  • Sanitization : Nettoyage des entrées utilisateur (XSS)

7.5.2. Confidentialité (RGPD)

  • Consentement explicite pour le traitement des données

  • Information sur l’utilisation des données personnelles

  • Droit à l’oubli : possibilité de supprimer le compte

  • Chiffrement des données sensibles

  • Logs anonymisés

8. Scénarios alternatifs et gestion d’erreurs

8.1. Cas d’erreur 1 : Email invalide ou déjà utilisé

Déclencheur : L’enseignant saisit un email au format invalide ou déjà enregistré.

Comportement du système :

  1. Le système détecte l’erreur lors de la validation

  2. Affichage d’un message d’erreur explicite :

    • "L’adresse email n’est pas valide"

    • "Cette adresse email est déjà utilisée"

  3. Le formulaire reste pré-rempli avec les autres champs

  4. Focus automatique sur le champ en erreur

Reprise : L’enseignant corrige l’email et soumet à nouveau.

8.2. Cas d’erreur 2 : Mot de passe non conforme

Déclencheur : Le mot de passe ne respecte pas la politique de sécurité.

Comportement du système :

  1. Validation en temps réel pendant la saisie

  2. Affichage des critères non satisfaits :

    • Au moins 8 caractères

    • Une lettre majuscule

    • Un chiffre

  3. Message d’erreur détaillé lors de la soumission

  4. Indicateur de force du mot de passe

Reprise : L’enseignant saisit un mot de passe conforme.

8.3. Cas d’erreur 3 : Email de validation non reçu

Déclencheur : L’enseignant ne reçoit pas l’email dans sa boîte de réception.

Causes possibles :

  • Email dans les spams/indésirables

  • Adresse email incorrecte

  • Problème technique serveur SMTP

  • Boîte de réception pleine

Comportement du système :

  1. Page de confirmation affichée après inscription

  2. Message : "Un email de validation a été envoyé à user@example.com"

  3. Bouton "Renvoyer l’email" disponible après 2 minutes

  4. Lien vers FAQ "Email non reçu ?"

Reprise :

  1. L’enseignant vérifie ses spams

  2. Utilise le bouton "Renvoyer l’email" si nécessaire

  3. Contacte le support si le problème persiste

8.4. Cas d’erreur 4 : Token expiré

Déclencheur : L’enseignant clique sur le lien après expiration (> 24h).

Comportement du système :

  1. Détection du token expiré

  2. Affichage d’une page d’erreur explicite :

    • "Ce lien de validation a expiré"

    • Explication de la durée de validité

  3. Bouton "Demander un nouveau lien"

Reprise :

  1. L’enseignant clique sur "Demander un nouveau lien"

  2. Saisit son adresse email

  3. Un nouveau token est généré et envoyé

8.5. Cas d’erreur 5 : Token invalide ou déjà utilisé

Déclencheur : Le token dans l’URL est incorrect ou a déjà servi.

Comportement du système :

  1. Vérification de l’existence et du statut du token

  2. Page d’erreur avec message approprié :

    • "Ce lien de validation n’est pas valide"

    • "Ce compte a déjà été validé"

  3. Lien vers la page de connexion si compte déjà actif

Reprise :

  • Si compte déjà validé : connexion directe

  • Si token invalide : nouvelle demande d’inscription ou contact support

8.6. Cas alternatif 1 : Problème technique lors de l’envoi d’email

Déclencheur : Le serveur SMTP est indisponible ou retourne une erreur.

Comportement du système :

  1. Le compte est créé avec statut "En attente"

  2. L’envoi d’email échoue et est mis en file d’attente

  3. Message affiché à l’enseignant :

    • "Votre compte a été créé"

    • "L’email de validation sera envoyé dans quelques instants"

  4. Retry automatique toutes les 5 minutes (max 3 tentatives)

  5. Notification aux administrateurs si échec persistant

Reprise :

  1. L’email est envoyé lors du prochain retry réussi

  2. L’enseignant peut utiliser "Renvoyer l’email" si nécessaire

9. Objectifs de performance

Métrique Valeur cible Mesure

Temps de réponse création

< 500ms

Du clic sur "S’inscrire" à l’affichage de la confirmation

Temps d’envoi email

< 30 secondes

De la création du compte à la réception de l’email

Temps de validation

< 200ms

Du clic sur le lien à l’affichage de la confirmation

Disponibilité

99.9%

Uptime mensuel du service

Taux de succès

> 95%

Pourcentage d’inscriptions complétées avec succès

9.1. Charge attendue

  • Utilisateurs simultanés : 100 inscriptions/heure en période de pointe

  • Stockage : ~1 Ko par compte enseignant

  • Emails : 1 email par inscription + 0.2 renvoi moyen

10. Tests et validation

10.1. Tests unitaires

Composant testé Couverture cible

ServiceInscription

> 90%

Service Validation

> 95%

Gestionnaire Token

100%

EnseignantRepository

> 85%

Entité Enseignant

> 80%

Scénarios de test unitaire :

  1. Validation d’un email valide

  2. Rejet d’un email invalide

  3. Rejet d’un email en doublon

  4. Génération de token unique

  5. Validation de mot de passe conforme

  6. Rejet de mot de passe trop faible

  7. Vérification d’expiration de token

10.2. Tests d’intégration

Scénarios prioritaires :

  1. Inscription complète : Création → Envoi email → Validation → Activation

  2. Workflow avec base de données : Persistance et récupération des données

  3. Intégration SMTP : Envoi effectif d’emails

  4. Intégration serveur d’identification : Communication avec le serveur externe

  5. Gestion des erreurs : Comportement en cas d’indisponibilité des services

10.3. Tests fonctionnels

Cas de test principaux :

ID Scénario Résultat attendu

TF-01

Inscription avec données valides

Compte créé, email reçu, validation réussie

TF-02

Inscription avec email existant

Message d’erreur "Email déjà utilisé"

TF-03

Inscription avec mot de passe faible

Message d’erreur listant les critères non respectés

TF-04

Validation avec token expiré

Message d’erreur avec possibilité de renvoyer

TF-05

Validation avec token invalide

Page d’erreur appropriée

TF-06

Renvoyer email de validation

Nouvel email reçu avec nouveau token

10.4. Tests de sécurité

Points de vérification :

  1. Injection SQL : Tentatives d’injection dans les champs

  2. XSS : Saisie de scripts dans nom/prénom

  3. CSRF : Soumission de formulaire sans token CSRF

  4. Brute force : Tentatives répétées d’inscription

  5. Énumération d’emails : Différence de réponse selon existence du compte

  6. Token prediction : Vérification du caractère aléatoire des tokens

10.5. Tests de performance

Scénarios de charge :

  1. Charge normale : 50 inscriptions/heure

  2. Charge élevée : 200 inscriptions/heure

  3. Pic de charge : 500 inscriptions/heure (rentrée scolaire)

  4. Test de stress : Augmentation progressive jusqu’à dégradation

Métriques surveillées :

  • Temps de réponse des endpoints

  • Utilisation CPU/RAM

  • Nombre de connexions base de données

  • File d’attente emails

  • Taux d’erreur

11. Contraintes techniques

11.1. Contraintes technologiques

  • Format de documentation : AsciiDoc (NF-Req-3)

  • Compatibilité navigateurs : Chrome 90+, Firefox 88+, Safari 14+, Edge 90+

  • Responsive design : Support mobile/tablette

  • Accessibilité : WCAG 2.1 niveau AA minimum

11.2. Contraintes réglementaires

  • RGPD : Conformité complète avec le règlement européen

  • Consentement : Opt-in explicite pour le traitement des données

  • Données personnelles : Minimisation et finalité claire

  • Conservation : Durée limitée, suppression à la demande

11.3. Contraintes opérationnelles

  • Logs : Conservation des logs d’inscription pendant 90 jours

  • Monitoring : Alertes en cas d’échec d’envoi d’email

  • Backup : Sauvegarde quotidienne de la base de données

  • Maintenance : Fenêtre de maintenance hebdomadaire (dimanche 2h-4h)

12. Dépendances

12.1. Dépendances fonctionnelles

Fonctionnalité dépendante Description

Se connecter (UC-4)

Nécessite un compte créé et validé

Participer à une partie (UC-X)

L’enseignant doit être inscrit et connecté

Réinitialiser mot de passe

Utilise le même mécanisme d’envoi d’email

12.2. Dépendances techniques

  • Base de données : PostgreSQL 12+ ou MySQL 8+

  • Serveur SMTP : Configuration d’un serveur d’envoi d’emails

  • Serveur d’identification : Service d’authentification externe

  • Bibliothèques :

    • Hashing : bcrypt ou argon2

    • Validation : validator.js ou équivalent

    • ORM : Hibernate, Sequelize, TypeORM selon technologie

    • Email : Nodemailer, JavaMail, etc.

13. Annexes

13.1. Glossaire

Terme Définition

Token

Chaîne de caractères unique et aléatoire utilisée pour valider une action

UUID

Universally Unique Identifier - Identifiant unique généré aléatoirement

SMTP

Simple Mail Transfer Protocol - Protocole d’envoi d’emails

Hashing

Transformation irréversible d’un mot de passe en empreinte

Salt

Donnée aléatoire ajoutée au mot de passe avant hashing

RGPD

Règlement Général sur la Protection des Données

REST API

Interface de programmation utilisant le protocole HTTP

ORM

Object-Relational Mapping - Mappage objet-relationnel

13.2. Références

  • RFC 5322 - Internet Message Format

  • OWASP Top 10 - Bonnes pratiques de sécurité web

  • WCAG 2.1 - Web Content Accessibility Guidelines

  • RGPD - Règlement (UE) 2016/679

13.3. Historique des versions

Version Date Auteur Modifications

1.0

2024-01-15

Équipe dev

Version initiale

1.1

2024-02-10

Équipe dev

Ajout diagramme de déploiement, précisions sécurité

13.4. Fichiers sources des diagrammes

Tous les diagrammes PlantUML sont disponibles dans le répertoire :

/docs/diagrams/creer-compte/
├── diagram_cas_utilisation_creer_compte.puml
├── diagram_sequence_creer_compte.puml
├── diagram_activite_creer_compte.puml
├── diagram_etat_compte.puml
├── diagram_classe_creer_compte.puml
├── diagram_composants_creer_compte.puml
└── diagram_deploiement_creer_compte.puml

Pour générer les images SVG :

plantuml -tsvg diagram_*.puml

14. Contact et Support

Pour toute question concernant cette fonctionnalité :

Auteur : Cheikh Tidiane DIOP
Institution : Université de Nantes - Master Informatique
Date : Janvier 2026

Document construit conformément à la norme NF-Req-3 : Documentation en format AsciiDoc