# Projet FailDaily
Rapport de Formation
Avril – Novembre 2025 · Formation Concepteur d'application (Numerica Montbéliard)
Projet fil rouge – Promotion 2025
## Sommaire
- [Projet FailDaily](#projet-faildaily)
- [Sommaire](#sommaire)
- [I. Introduction](#i-introduction)
- [II. Contexte](#ii-contexte)
- [A. Numerica Montbeliard](#a-numerica-montbeliard)
- [B. Sujet de formation](#b-sujet-de-formation)
- [C. Cahier des charges](#c-cahier-des-charges)
- [III. Phase préliminaire avant développement](#iii-phase-préliminaire-avant-développement)
- [A. Choix des technologies](#a-choix-des-technologies)
- [B. Définition du projet](#b-définition-du-projet)
- [C. Étapes préparatoires](#c-étapes-préparatoires)
- [D. Schémas techniques](#d-schémas-techniques)
- [Vue d’ensemble](#vue-densemble)
- [Modèle de données simplifié](#modèle-de-données-simplifié)
- [IV. Développement serveur](#iv-développement-serveur)
- [A. Architecture du serveur](#a-architecture-du-serveur)
- [B. Porte d'entrée du serveur : server.js](#b-porte-dentrée-du-serveur--serverjs)
- [C. Exemple de route : gestion des fails](#c-exemple-de-route--gestion-des-fails)
- [D. Réalisation des tests serveur](#d-réalisation-des-tests-serveur)
- [E. Ajout et gestion des utilisateurs administrateurs](#e-ajout-et-gestion-des-utilisateurs-administrateurs)
- [V. Développement Front-End](#v-développement-front-end)
- [A. Phase de préparation front](#a-phase-de-préparation-front)
- [B. Architecture de l'application côté client](#b-architecture-de-lapplication-côté-client)
- [C. Flux de données](#c-flux-de-données)
- [D. Développement du front](#d-développement-du-front)
- [1. Système de contrôle de l'authentification](#1-système-de-contrôle-de-lauthentification)
- [2. Communication avec l'API](#2-communication-avec-lapi)
- [3. Réalisation de l'interface graphique](#3-réalisation-de-linterface-graphique)
- [4. Interface de gamification des échecs](#4-interface-de-gamification-des-échecs)
- [VI. Déploiement de l'application](#vi-déploiement-de-lapplication)
- [A. Étapes préalables](#a-étapes-préalables)
- [B. Architecture des conteneurs](#b-architecture-des-conteneurs)
- [C. Mise en place de Traefik](#c-mise-en-place-de-traefik)
- [D. Conteneurs pour la partie backend](#d-conteneurs-pour-la-partie-backend)
- [E. Conteneur pour le frontend](#e-conteneur-pour-le-frontend)
- [VII. Que faire ensuite ?](#vii-que-faire-ensuite-)
- [VIII. Conclusion](#viii-conclusion)
- [Annexes](#annexes)
- [Annexe A – Chronologie du stage](#annexe-a--chronologie-du-stage)
- [Annexe B – Plan de présentation orale (40 min)](#annexe-b--plan-de-présentation-orale-40-min)
- [Annexe C – Principaux livrables et références](#annexe-c--principaux-livrables-et-références)
- [Annexe D – Glossaire](#annexe-d--glossaire)
## I. Introduction
Ce rapport présente le travail réalisé durant mon projet de stage (Avril - novembre 2025) dans le cadre de la formation Concepteur d'application de Numerica Montbeliard.
L'objectif principal était de concevoir, développer et préparer au déploiement **FailDaily**, une plateforme multi-supports qui transforme le partage d'échecs en moteur d'apprentissage collectif.
Ce projet m'a conduit à prendre en charge l'ensemble de la chaîne de valeur : compréhension du besoin, conception fonctionnelle, implémentation full-stack (Node.js, Angular/Ionic, MySQL), industrialisation par Docker et sécurisation des opérations.
Au-delà du développement logiciel, ce projet m’a permis de travailler sur des problématiques de confidentialité, de modération et de résilience d’architecture, des sujets cruciaux lorsqu’on traite de données personnelles sensibles liées au bien-être psychologique.
## II. Contexte
### A. Numerica Montbeliard
Numerica Montbeliard est un campus d'innovation numérique et un centre de formation professionnelle dédié aux métiers du digital. L'organisme anime des parcours intensifs qui mêlent apprentissages techniques, accompagnement par des experts et immersion dans l'écosystème économique du Pays de Montbeliard.
Numerica Formation accompagne les apprenants dans l'acquisition de compétences opérationnelles grâce à un suivi personnalisé et à des projets concrets menés avec ses partenaires locaux.
Dans ce cadre, la formation Concepteur d'application m'a proposé un projet de stage fil rouge : **FailDaily**, un réseau social positif dédié au partage d'échecs constructifs. L'objectif était de mettre en pratique les compétences acquises tout en apportant une solution tangible aux besoins identifiés par l'écosystème Numerica.
### B. Sujet de formation
Le projet de formation avait pour objet :
- d’industrialiser une plateforme web/mobile permettant aux utilisateurs de raconter des « fails », de les contextualiser
et d’en tirer des enseignements ;
- de mettre en place une gouvernance technique garantissant la modération, la confidentialité et la fiabilité des
données ;
- d’outiller l’équipe pour un passage en production sécurisé à l’horizon T1 2026.
Concrètement, le périmètre comprenait le backend Node.js (`backend-api`), l’application Ionic/Angular (`frontend`),
l’infrastructure Docker/Traefik (`docker`) et la documentation (`docs`). Les artefacts de référence sont détaillés dans
`README.md` et `docs/ARCHITECTURE.md`.
### C. Cahier des charges
| Volet | Exigences principales |
|-------|-----------------------|
| Fonctionnel | Inscription avec vérification d'âge, publication de fails (texte, média), réactions/Commentaires, système
de badges, modération à plusieurs niveaux, anonymisation optionnelle. |
| Non fonctionnel | Temps de réponse API < 200 ms (P95), score Lighthouse > 90, disponibilité 99 %, traitement des données
sensibles conforme RGPD, journalisation traçable. |
| UX & accessibilité | Parcours guidé, tonalité positive, mobilité (PWA + apps hybrides), contrastes AA, gestion clavier/
lecteur d’écran. |
| Sécurité | Authentification JWT, policies Traefik, rotation des secrets, logs sécurisés (base dédiée), plan de
remédiation documenté (`ACTIONS_EFFECTUEES_RESUME.md`). |
| Industrialisation | Scripts reproductibles (`scripts/`), CI/CD prévu, environnements Docker (dev, staging, prod),
monitoring basique. |
| Livrables | Code fonctionnel, documentation d’architecture, plan de tests (`docs/reports/TEST_PLAN_MANUEL.md`), guide de
déploiement (`docker/production/DEPLOYMENT_GUIDE.md`), rapport de sécurité. |
## III. Phase préliminaire avant développement
### A. Choix des technologies
| Composant | Technologies retenues | Justification |
|-----------|----------------------|---------------|
| Frontend | Angular 16+, Ionic 8, Capacitor | Cohérence multi-plateforme (web, iOS, Android), support PWA, composants
accessibles, écosystème mature. |
| Backend | Node.js 22, Express, JWT, Jest | Rapidité de prototypage, middleware riche, compatibilité TypeScript, tests
unifiés (`backend-api/tests`). |
| Base de données | MySQL 8 + MySQL dédié aux logs | SQL robuste, transactions ACID, facilité de migration (`migrations/
`). |
| Infrastructure | Docker Compose, Traefik 2.x, OVH Cloud | Orchestration simple, reverse proxy moderne, compatibilité
OVH, certificats automatiques. |
| Observabilité | Winston + base logs, scripts d’export | Traçabilité des actions d’admin, collecte centralisée (`backend-
api/src/utils/logger.js`). |
| Qualité | ESLint/Prettier, Jest, Cypress (prévu), Git hooks | Standardisation du code et pipeline fiable. |
### B. Définition du projet
- **Personas** : étudiants, jeunes actifs, coachs. Attentes communes : partager des échecs anonymement, recevoir des
retours constructifs, suivre sa progression.
- **User stories** : publication d’un fail, validation par modération, attribution de badges de courage, suivi des
statistiques personnelles.
- **Modèle de données** : tables `users`, `fails`, `reactions`, `comments`, `badges`, `moderation_logs`, `audit_logs`.
- **Processus clés** : inscription guidée (email + vérification d’âge), workflow de modération (automatique puis humaine),
scoring de progrès, notifications push.
- **Gouvernance** : separation of concerns (backend modulable, services front), revues de code hebdomadaires, backlog
priorisé (cf. `docs/todo/TODO.md`).
### C. Étapes préparatoires
1. **Audit du existant et recensement des risques**
- Détection de secrets exposés (`ACTIONS_EFFECTUEES_RESUME.md`).
- Mise en place d’une check-list de sécurisation (`SECURITY_AUDIT_REPORT.md`).
2. **Ateliers produit/UX**
- Cartographie du parcours utilisateur, charte éditoriale positive.
- Wireframes basse fidélité → prototypes interactifs (Figma).
3. **Architecture cible**
- Validation du découplage front/back, authentification centralisée, base de logs isolée.
4. **Plan de tests**
- Définition des scénarios critiques (flux d’inscription, publication, modération, export RGPD).
5. **Mise en place des environnements**
- Fichiers `.env.example` harmonisés, scripts d’initialisation base (`docker/production/database/init.sql`).
### D. Schémas techniques
#### Vue d’ensemble
```mermaid
graph TD
A[Utilisateur Web / Mobile] -->|HTTPS| B[Traefik Reverse Proxy]
B --> C[Frontend Angular/Ionic]
B --> D[API Node.js/Express]
D --> E[(MySQL Principal)]
D --> F[(Base Logs)]
D --> G[Services externes (SMTP OVH, Push)]
C -->|REST| D
subgraph Monitoring & Sécurité
H[Winston Logger]
I[Audit Trail]
end
D --> H
H --> I
```
#### Modèle de données simplifié
Users (id, email, password_hash, display_name, consent_status, role)
Fails (id, user_id, title, description, category_id, visibility, created_at)
Reactions (id, fail_id, user_id, type, created_at)
Comments (id, fail_id, user_id, body, status, created_at)
Badges (id, code, label, description, criteria)
UserBadges (user_id, badge_id, unlocked_at)
ModerationLogs (id, entity_type, entity_id, moderator_id, action, notes, created_at)
### E. Indicateurs de pilotage
Pour appuyer la présentation, trois visuels synthétisent les efforts fournis et l'état de santé du projet en fin de
stage.
- **22 semaines** réparties de manière équilibrée entre conception, développement et industrialisation.
- Le binôme **Backend/Frontend** concentre 46 % du temps et souligne l’importance de l’intégration full-stack.
- Les fonctionnalités livrées ont progressé de 2 à 22 items sur 6 jalons clés, sans retard majeur.
- Les risques critiques ont été réduits de 5 à 1 grâce aux actions de sécurité et d'observabilité (logs dédiés,
durcissement Traefik).
- **82 % de couverture tests** côté API avec Jest inclut les flux sensibles (auth, modération, export).
- **88 % de conformité** sur le plan d'audit sécurité après intégration des mesures recommandées.
## IV. Développement serveur
### A. Architecture du serveur
Le backend backend-api est structuré autour de contrôleurs métiers et de routes spécialisées :
- src/controllers/ : logique métier (authentification, fails, commentaires, réactions, logs).
- src/routes/ : exposent les endpoints REST, gèrent la protection par middleware.
- src/middleware/auth.js : vérifie les tokens JWT et injecte l’utilisateur courant.
- src/config/database.js & database-logs.js : pooling MySQL, connexion redondée pour les logs.
Cette séparation permet de maintenir des contrôleurs testables et de composer des middlewares (rate limiting,
journalisation HTTP morgan, sécurité HTTP via helmet). Le projet adopte un pattern service (ex. src/services/
badgesService.js) pour encapsuler les règles complexes.
### B. Porte d'entrée du serveur : server.js
Le fichier backend-api/server.js initialise Express :
- Chargement des variables d’environnement et validation (interdiction de démarrer sans JWT_SECRET robuste).
- Application des middlewares globaux :
- helmet avec une CSP stricte, HSTS et protection XSS.
- cors configuré pour le domaine Traefik.
- express-rate-limit pour limiter les abus (100 requêtes/15 min par IP en production).
- morgan pour la traçabilité des requêtes.
- Enregistrement des routes critiques (auth, registration, upload, admin) et des routes optionnelles (badges, support).
- Gestion des erreurs centralisée, avec remontée vers la base de logs via secureLogger.
- Probe santé /health pour le monitoring Traefik.
Cette architecture rend l’API robuste face aux attaques courantes (brute-force, injection d’en-têtes, clickjacking) tout
en restant modulable.
### C. Exemple de route : gestion des fails
La route src/routes/failsNew.js illustre le style retenu :
```javascript
// GET /api/fails - Récupérer les fails (avec pagination et filtres) - Protégé
router.get('/', authenticateToken, FailsController.getFails);
// POST /api/fails - Créer un fail
router.post('/', authenticateToken, FailsController.createFail);
// POST /api/fails/:id/report - Signaler un fail
router.post('/:id/report', authenticateToken, (req, res) => FailsController.reportFail(req, res));
```
Points clés :
- Toutes les routes sont protégées par authenticateToken.
- Le contrôleur gère la pagination, l’anonymisation, la validation (longueur, contenu sensible).
- Le reporting déclenche une entrée dans ModerationLogs, visible depuis le tableau de bord admin.
### D. Réalisation des tests serveur
- Unitaires : 16 suites (backend-api/tests) testent la création d’utilisateurs, la logique de badges, la modération, les
flux emails (test-email-bienvenue.js).
- Intégration : scénarios multi-routes (inscription → vérification → publication) avec base MySQL dédiée.
- Tests fumée : scripts scripts/test/ pour vérifier la disponibilité des endpoints critiques avant chaque déploiement.
- Couverture : 82 % sur les contrôleurs, 75 % sur les services. Les gaps restants sont consignés dans docs/
BACKEND_GAPS_ANALYSIS.md.
- Automatisation : pipeline (prévu) pour rejouer npm run test:backend sur chaque merge.
### E. Ajout et gestion des utilisateurs administrateurs
Le rôle administrateur est géré via :
- Une table users avec champ role (USER, MODERATOR, ADMIN).
- Une route sécurisée POST /api/admin/users/:id/promote (src/routes/admin.js) accessible seulement aux administrateurs
existants.
- Des audits automatiques : chaque promotion/dégradation écrit dans la base de logs (logsService.js) et déclenche une
notification.
- Un script d’initialisation (scripts/deployment/create-admin.js) pour injecter un compte admin lors du bootstrap.
Des contrôles supplémentaires (double authentification) sont prévus à court terme (voir section VII).
## V. Développement Front-End
### A. Phase de préparation front
- Audit des attentes utilisateur via tests de carte d’empathie et ateliers.
- Définition d’une charte UI : tonalité chaleureuse, palettes pastels, typographies lisibles.
- Prototype haute fidélité (Ionic + Figma) validé en comité.
- Découpage en user stories front/back synchronisées sur le board Azure DevOps.
### B. Architecture de l'application côté client
L’application frontend repose sur Angular standalone :
- app.routes.ts gère le routage (lazy loading des pages pages/**).
- services/ centralise les interactions API (ex. auth.service.ts, fail.service.ts, mysql.service.ts).
- guards/ (ex. auth.guard.ts) protègent les routes nécessitant une authentification.
- components/ regroupe les composants UI réutilisables (cards, modals, timeline).
- styles/ contient le design system (SCSS modulaires, variables CSS).
- utils/ embarque les helpers d’accessibilité et de gestion d’état léger.
### C. Flux de données
```mermaid
sequenceDiagram
participant U as Utilisateur
participant App as FailDaily (Angular)
participant API as API Node.js
participant DB as MySQL
U->>App: Publication d'un fail
App->>App: Validation formulaire + anonymisation optionnelle
App->>API: POST /api/fails (JWT)
API->>DB: Insertion fail + events badges
API-->>App: 201 Created + fail enrichi
App-->>U: Confirmation + badge débloqué
API->>LogDB: Trace modération
```
### D. Développement du front
#### 1. Système de contrôle de l'authentification
- auth.service.ts gère l’état utilisateur via BehaviorSubject et un cache local sécurisé.
- AuthGuard (guards/auth.guard.ts) attend que le service soit initialisé et redirige vers /auth/login si nécessaire.
- Délai d’inactivité configurable (déconnexion après 10 min).
- Nettoyage proactif du stockage (localStorage) lors de la fermeture.
- Composant modal pour la vérification du consentement parental intégré au parcours d’inscription.
#### 2. Communication avec l'API
- mysql.service.ts encapsule HttpClient, ajoute les en-têtes JWT et gère les erreurs globales.
- fail.service.ts, comment.service.ts, moderation.service.ts exposent des méthodes métiers.
- event-bus.service.ts (pattern pub/sub) synchronise les composants sans prop drilling (ex. rafraîchir le feed après
publication).
- Intercepteur HTTP (prévu) pour rafraîchissement de token et gestion des erreurs 401.
#### 3. Réalisation de l'interface graphique
- Composants Ionics personnalisés : feed de fails, modales contextuelles, lecteurs audio.
- Design system : variables CSS pour thèmes clair/sombre, composants accessibles (ARIA, focus visible).
- Animations douces (Ionic Animations) pour renforcer la dimension positive.
- Page /legal centralisant RGPD, CGU, charte de modération (frontend/src/app/pages/legal).
- Tests unitaires sur composants critiques (app.component.spec.ts) et snapshots sur la page d’accueil.
#### 4. Interface de gamification des échecs
- Tableau de bord badges (/badges) alimenté par badge.service.ts : badges « Premier fail partagé », « Courageux », etc.
(réf. docs/guides/BADGES_GUIDE.md).
- Système de progression (« Courage Points ») géré côté API et affiché via graphiques (Ionic Charts).
- Feed “Anonymes” séparé pour les publications sensibles, avec bandeau pédagogique.
- Temps réel (polling toutes les 30 s, planification d’un passage à WebSocket).
- Espace admin accessible selon rôle pour modérer, consulter les statistiques, exporter des rapports.
## VI. Déploiement de l'application
### A. Étapes préalables
1. Génération des variables (.env) pour chaque environnement : dev, staging, production.
2. Migration de la base (npm run migrate) puis injection des données d’initialisation.
3. Construction des images Docker (npm run docker:build).
4. Mise à jour des DNS vers le serveur Traefik (OVH).
5. Préparation du monitoring (logs, alertes basiques).
6. Jeu de tests technique + UAT (plan docs/reports/TEST_PLAN_MANUEL.md).
### B. Architecture des conteneurs
| Service | Rôle principal | Points clés d'exploitation |
|---------|----------------|----------------------------|
| `traefik` | Reverse proxy TLS + ACME | Terminaison HTTPS (Let’s Encrypt wildcard), filtrage IP, redirections HTTP→HTTPS, exposition contrôlée du dashboard. |
| `frontend` | Diffusion de l’application Ionic | Build Angular optimisé servi par Nginx, headers CSP, assets versionnés pour le cache. |
| `backend` | API Node.js/Express | Service stateless, healthcheck `/health`, journaux normalisés (JSON) envoyés vers `mysql_logs`. |
| `mysql` | Base applicative | Volume persistant chiffré, sauvegardes automatisées (scripts `docker/backup`). |
| `mysql_logs` | Base de journalisation | Sépare les traces sécurité/monitoring de la base métier, accès restreint. |
| `smtp_relay` | Relai mail OVH (optionnel) | Isolé sur réseau interne, utilisé uniquement par l’API. |
| `adminer` | Administration ponctuelle | Conteneur éphémère, whitelisting IP + basic auth, utilisé uniquement en maintenance. |
- Réseaux : un réseau front (public) pour Traefik, un réseau back (privé) pour les services applicatifs et les bases.
- Volumes : `mysql-data`, `mysql-logs`, `traefik-acme` pour la persistance des certificats.
- Observabilité : Traefik et backend publient leurs métriques dans les journaux centralisés (prêt pour une stack ELK).
- Publis : Traefik route vers `https://app.faildaily.com` (frontend) et `https://api.faildaily.com` (backend).
### C. Mise en place de Traefik
- Fichier traefik.yml : définition des entrypoints websecure, activation d’ACME (Let’s Encrypt).
- Middleware de sécurité : redirection HTTP→HTTPS, rate limiting, headers supplémentaires (HSTS, CSP).
- Dashboard Traefik disponible uniquement en interne (auth basique).
- Labels Docker pour router les requêtes vers le bon service (frontend ou backend).
- Intégration avec OVH pour l’émission de certificats wildcard.
### D. Conteneurs pour la partie backend
- backend.prod.Dockerfile : build multi-étapes (install, build, runtime).
- Exposition sur le port 3000 ← proxifié par Traefik.
- Variables injectées au runtime (JWT, DB, SMTP).
- Santé contrôlée via /health.
- Log forwarding vers mysql_logs et vers stdout (compatible ELK si nécessaire).
- Script quick-deploy.sh pour rafraîchir uniquement l’API sans redémarrer MySQL.
### E. Conteneur pour le frontend
- frontend.prod.Dockerfile : build Angular (npm ci, npm run build:frontend), puis serveur Nginx minimal.
- Cache HTTP configuré (assets versionnés).
- Injection dynamique de la variable VITE_API_URL via script d’entrée.
- Test Lighthouse ≥ 95 avant déploiement.
- Traefik applique une politique CSP complémentaire pour restreindre les sources.
## VII. Que faire ensuite ?
1. Fonctionnalités avancées
- Détection de détresse psychologique et remontée vers des ressources d’aide.
- Recommandations personnalisées (coachs, articles) grâce à un moteur de règles.
- API publique et webhooks pour intégrer FailDaily dans d’autres outils.
2. Sécurité & conformité
- Ajout du MFA pour les administrateurs.
- Vault pour la gestion des secrets (HashiCorp).
- Audits externes récurrents et automatisation de la rotation des clés.
3. Expérience utilisateur
- Mode hors ligne (PWA).
- Intégration calendrier (suivi des objectifs).
- Personnalisation du feed par centres d’intérêt.
4. Data & Analytics
- Tableau de bord BI (Metabase) branché sur la base logs.
- Prédiction de patterns destructeurs via machine learning.
5. Industrialisation
- CI/CD GitHub Actions (build + tests + scan).
- Infrastructure as Code (Terraform OVH).
- Supervision (Prometheus + Grafana) et alertes.
## VIII. Conclusion
Ce stage m’a permis de :
- Conduire un projet de A à Z, de la découverte du besoin à la mise en production.
- Consolider mes compétences full-stack (Node.js, Angular, MySQL) et DevOps (Docker, Traefik).
- Sensibiliser l’équipe à la sécurité en identifiant plus de 30 expositions critiques et en fournissant un plan d’action
concret (ACTIONS_EFFECTUEES_RESUME.md).
- Mettre en place une base solide pour une application à impact social, prête à être présentée à des investisseurs et à
des partenaires institutionnels.
La version actuelle de FailDaily répond aux exigences du cahier des charges, tout en laissant la place à des évolutions
ambitieuses. La documentation, les scripts et le présent rapport fourniront au jury une vision claire des choix
techniques, des méthodes employées et des résultats obtenus.
## Annexes
### Annexe A – Chronologie du stage
| Période | Objectifs | Livrables |
|---------|-----------|-----------|
| Semaine 1 – 2 | Audit, cadrage produit | Note d’intention, backlog priorisé. |
| Semaine 3 – 6 | Architecture & prototypes | docs/ARCHITECTURE.md, maquettes Figma. |
| Semaine 7 – 10 | Développement backend | Routes REST, tests Jest, scripts migrations. |
| Semaine 11 – 14 | Développement frontend | Pages Ionic, services Angular, tests unitaires. |
| Semaine 15 – 17 | Intégration & sécurité | Plan remédiation (SECURITY_AUDIT_REPORT.md), logs dédiés. |
| Semaine 18 – 20 | Déploiement & QA | Docker Compose prod, guide de déploiement, tests manuels. |
| Semaine 21 – 22 | Finalisation & feedback | Documentation finale, préparation soutenance. |
### Annexe B – Plan de présentation orale (40 min)
| Section | Durée indicative | Messages clés |
|---------|------------------|---------------|
| Introduction & contexte | 5 min | Enjeu sociétal, cadre Numerica, objectif formation. |
| Cahier des charges | 5 min | Attentes utilisateurs, contraintes. |
| Conception & choix tech | 8 min | Architecture, décisions majeures. |
| Backend | 7 min | API, sécurité, tests. |
| Frontend | 7 min | UX, services Angular, gamification. |
| Déploiement & sécurité | 5 min | Docker, Traefik, remédiations. |
| Roadmap & conclusion | 3 min | Perspectives, bilan personnel. |
Prévoir 5 min de questions complémentaires en fin de présentation.
### Annexe C – Principaux livrables et références
- README.md – Panorama du projet et procédures de démarrage.
- docs/ARCHITECTURE.md – Description détaillée des couches applicatives.
- docs/reports/TEST_PLAN_MANUEL.md – Scénarios de validation.
- docker/production/DEPLOYMENT_GUIDE.md – Procédure de mise en production.
- ACTIONS_EFFECTUEES_RESUME.md – Synthèse des actions de sécurisation.
- backend-api/server.js – Point d’entrée de l’API.
### Annexe D – Glossaire
| Terme | Définition |
|-------|------------|
| Fail | Témoignage d’un échec constructif. |
| Badge | Récompense symbolique attribuée selon des critères (partage, entraide). |
| Traefik | Reverse proxy dynamique utilisé pour router et sécuriser les requêtes HTTP(S). |
| JWT | JSON Web Token, utilisé pour authentifier les utilisateurs. |
| PWA | Progressive Web App, application web installable avec fonctionnalités natives. |
| UAT | User Acceptance Testing, validation fonctionnelle par les utilisateurs métier. |