[LOCKLITE-135] Create bugs plan

README.md

@@ -18,9 +18,10 @@ businesses [![Build Status](https://github.com/vbetsch/lockLite/actions/workflow
 ![ESLint](https://img.shields.io/badge/ESLint-4B3263?style=for-the-badge&logo=eslint&logoColor=white)
 ![Prettier](https://img.shields.io/badge/prettier-%23F7B93E.svg?style=for-the-badge&logo=prettier&logoColor=black)
 
-[//]: # (## Asserts)
+### Documentation
 
-[//]: # (- [ASSERT_NAME](ASSERT_PATH))
+- [Test Plan (C2.3.1)](docs/RECETTES.md)
+- [Defect Correction Plan (C2.3.2)](docs/BOGUES.md)
 
 ### Dependencies
 
@@ -44,7 +45,8 @@ We recommend using a WSL for this project. If so, please follow the [Linux](#lin
 
 ### Installation
 
-1. Create a `.env` file by copying the example file `.env.example` file. These values are only for the local environment, you can modify it if you want.
+1. Create a `.env` file by copying the example file `.env.example` file. These values are only for the local
+   environment, you can modify it if you want.
 
 2. Start docker services with the following command
 

docs/BOGUES.md

@@ -0,0 +1,138 @@
+# Plan de correction des bogues
+
+> Compétence RNCP : C2.3.2
+
+[//]: # (TODO: Modify when we will have accessibility reference -> ACCESSIBILITY)
+
+[//]: # (TODO: Modify when we will have changelogs -> CHANGELOGS)
+
+### Références
+
+- Cahier de recettes : [RECETTES.md](RECETTES.md)
+- Configuration Jest : [jest.config.ts](../jest.config.ts)
+
+## 1. Objectif
+
+Ce document décrit le processus mis en place pour détecter, qualifier, corriger et valider les anomalies et régressions
+identifiées lors de la phase de recette, afin de garantir le fonctionnement du logiciel conformément à l’attendu.
+
+## 2. Méthodologie de détection et consignation
+
+### 2.1 Outils utilisés
+
+- **Tests automatisés** : Jest pour les tests unitaires
+- **Surveillance en développement** : logs applicatifs (loggers), console et monitoring.
+- **Intégration continue** : GitHub Actions pour exécuter automatiquement les suites de tests.
+- **Traçabilité** : Outil de suivi Notion qui référence les bogues découverts
+
+### 2.2 Sources de détection
+
+- Échecs des scénarios du cahier de recettes.
+- Alertes CI/CD lors des push ou pull requests.
+
+### 2.3 Fiche d’anomalie
+
+Chaque anomalie est consignée dans l’outil de suivi interne sous le format :
+
+- **ID unique**
+- **Date**
+- **Environnement**
+- **Description**
+- **Étapes de reproduction**
+- **Résultat attendu**
+- **Résultat obtenu**
+- **Pièces jointes** (logs, captures d’écran)
+
+## 3. Qualification des anomalies
+
+### 3.1 Priorisation
+
+- **Bloquant** : empêche l’utilisation de la fonctionnalité principale.
+- **Majeur** : impact significatif mais contournement possible.
+- **Mineur** : gêne légère ou esthétique.
+
+### 3.2 Catégorisation
+
+- **Fonctionnelle** : non-respect d’une spécification.
+- **Technique** : problème de performance, compatibilité ou sécurité.
+- **Régression** : fonctionnalité précédemment validée qui échoue.
+
+[//]: # (TODO: ACCESSIBILITY)
+
+[//]: # (- **Accessibilité** : non-conformité avec le référentiel retenu ...)
+
+## 4. Analyse des points d’amélioration
+
+Pour chaque test en échec :
+
+1. **Identifier la cause racine** via l’analyse des logs, reproduction contrôlée et revue de code.
+2. **Évaluer l’impact** sur les autres modules et fonctionnalités.
+3. **Proposer la solution technique** la plus adaptée.
+
+## 5. Processus de traitement et validation
+
+### 5.1 Workflow
+
+1. Création d’une branche Git dédiée au correctif.
+2. Implémentation du correctif en respectant les bonnes pratiques et normes de sécurité.
+3. Ajout ou mise à jour des tests unitaires.
+4. Exécution des tests en local.
+5. Création d’une Pull Request avec revue par IA.
+6. Validation automatique par la CI (GitHub Actions).
+7. Fusion et déploiement.
+8. Reproduction du scénario en production.
+
+### 5.2 Critères de validation
+
+- Tous les tests du cahier de recettes sont passés.
+- Aucune régression détectée.
+- Code conforme aux règles ESLint et Prettier.
+
+## 6. Suivi et traçabilité
+
+- Les bogues sont référencés dès leur détection dans l'outil de suivi interne.
+- Ils sont étiquettés par les identifiants des
+  scénarios de recettes concernés.
+- **Indicateurs de suivi** :
+  - % d’anomalies corrigées dans les délais.
+  - Nombre de régressions post-correction.
+  - Évolution des anomalies critiques.
+
+[//]: # (TODO: CHANGELOGS)
+
+[//]: # (- **Journal de versions** mis à jour pour chaque correctif.)
+
+## 7. Exemples représentatifs
+
+> Les anomalies ci-dessous illustrent l’application de ce plan. Les autres sont consignées dans l’outil de suivi interne.
+
+### Bug #001 – Zone cliquable du bouton Logout trop restreinte
+- Priorité : Mineur  
+- Catégorie : UX/Accessibilité  
+- Description : Le `onClick` était attaché au label au lieu de l’élément de liste, cliquer à côté du texte ne déclenchait pas la déconnexion.  
+- Cause racine : Gestionnaire d’événement positionné sur le mauvais composant MUI.  
+- Correction : Déplacer `onClick` sur `ListItem`/`ListItemButton`
+- Validation : vérification manuelle du déclenchement sur toute la zone.
+
+---
+
+### Bug #002 – Incohérences de nommage dans la documentation API
+- Priorité : Majeur  
+- Catégorie : Technique/Documentation  
+- Description : Les noms exposés dans la documentation (OpenAPI/Swagger) ne correspondaient pas toujours aux objets réellement retournés.  
+- Cause racine : Divergence entre DTO/schema et la génération de doc.  
+- Correction : Aligner les schémas OpenAPI avec les DTO réels, régénérer la doc  
+- Validation : Documentation régénérée et relue
+
+---
+
+### Bug #003 – Visibilité des coffres-forts entre utilisateurs
+- Priorité : Bloquant (Sécurité)  
+- Catégorie : Sécurité/Fonctionnelle  
+- Description : Les utilisateurs voyaient les coffres-forts de tout le monde, de plus un coffre-fort créé n’était pas relié à l’utilisateur courant.  
+- Cause racine : Les requêtes ne sont pas filtrées par `userId` et absence de liaison propriétaire à la création.  
+- Correction :  
+  - Lecture : filtrer systématiquement par `userId` côté serveur et non côté client.  
+  - Création : relier le coffre-fort au propriétaire au moment de l’insert.  
+  - Ajouter des tests unitaires : un utilisateur A ne doit jamais voir/éditer les coffres-forts de B, création doit lier le `ownerId`.  
+- Validation : Tests unitaires OK (list/read/update/delete), vérification manuelle en recette avec deux comptes distincts.

docs/RECETTES.md

@@ -1,34 +1,27 @@
 # Cahier de recettes
 
-> Version : [`1.1.2`](https://github.com/vbetsch/locklite/releases/tag/v1.1.2)
->
-> Projet : LockLite — Gestionnaire de mots de passe
->
 > Compétence RNCP : C2.3.1
+>
+> Version : [`1.1.2`](https://github.com/vbetsch/locklite/releases/tag/v1.1.2)
 
-[//]: # (TODO: Modify when we will link with tests -> TESTS)
+### Références
 
-[//]: # (TODO: Modify when we will have bugs plan -> BUGS)
+- Schéma Prisma : [schema.prisma](../prisma/schema.prisma)
+- Configuration Jest : [jest.config.ts](../jest.config.ts)
+- Documentation API Swagger : http://localhost:3000/api/docs
+- Plan de correction des bogues : [BOGUES.md](BOGUES.md)
+
+[//]: # (TODO: Modify when we will have accessibility reference -> ACCESSIBILITY)
 
 [//]: # (TODO: Modify when we will have production environment -> PROD)
 
 ## 1. Objet et périmètre
 
 Ce document décrit les scénarios de tests et résultats attendus pour valider les fonctionnalités de LockLite, détecter
 les anomalies et prévenir les régressions.  
-Périmètre couvert : fonctionnalités MVP prévues pour le rendu du Bloc 2.
-
-## 2. Références
-
-- Schéma Prisma : [schema.prisma](../prisma/schema.prisma)
-- Configuration Jest : [jest.config.ts](../jest.config.ts)
-- Documentation API Swagger : http://localhost:3000/api/docs
+Périmètre couvert : toutes les fonctionnalités du MVP.
 
-[//]: # (TODO: BUGS)
-
-- Plan de correction des bogues (C2.3.2) : [lien]
-
-## 3. Environnements et données de test
+## 2. Environnements et données de test
 
 [//]: # (TODO: PROD)
 
@@ -44,22 +37,26 @@ Périmètre couvert : fonctionnalités MVP prévues pour le rendu du Bloc 2.
 
 - **Jeux de données** : coffres-forts et utilisateurs générés via seed Prisma avec la commande `npm run prisma:seed`
 
-## 4. Stratégie de test
+## 3. Stratégie de test
 
 - **Fonctionnels** : validation des parcours utilisateur
 - **Structurels** : conformité schémas API et contraintes DB
 - **Sécurité** : authentification, autorisations, stockage sécurisé
 - **Outils** : Jest, ESLint, GitHub Actions
 
-## 5. Matrice de couverture
+## 4. Matrice de couverture
+
+[//]: # (TODO: ACCESSIBILITY)
+
+[//]: # (Ajouter des tests d'accessibilité)
 
 | ID | Fonctionnalité            | Tests fonctionnels                                        | Tests structurels    | Tests sécurité        |
 |----|---------------------------|-----------------------------------------------------------|----------------------|-----------------------|
 | F0 | Documentation API         | `TC-F0`                                                   | `TS-F0.1`, `TS-F0.2` | —                     |
 | F1 | Gestion des coffres-forts | `TC-F1.1`, `TC-F1.2`, `TC-F1.3.A`, `TC-F1.3.B`, `TC-F1.4` | `TS-F1.3`            | `SE-VAULTS`           |
 | F2 | Authentification          | `TC-F2.1.A`, `TC-F2.1.B`, `TC-F2.2`                       | —                    | `SE-HASH`, `SE-GUARD` |
 
-## 6. Tests fonctionnels
+## 5. Tests fonctionnels
 
 ### TC-F0 — Affichage de la documentation API
 
@@ -215,7 +212,7 @@ identifiants valides
 
 - [ ] test manuel
 
-## 7. Tests structurels
+## 6. Tests structurels
 
 ### TS-F0.1 — Format des erreurs
 
@@ -253,7 +250,7 @@ coffre-fort ne s'ajoute pas dans la liste, une erreur apparaît m'indiquant que
 - [ ] test manuel
 - [ ] tests unitaires
 
-## 8. Tests de sécurité
+## 7. Tests de sécurité
 
 ### SE-VAULTS - Confidentialité des coffres-forts
 
@@ -287,7 +284,7 @@ coffre-fort ne s'ajoute pas dans la liste, une erreur apparaît m'indiquant que
 - [ ] test manuel
 - [ ] tests unitaires
 
-## 9. Procédure d’exécution
+## 8. Procédure d’exécution
 
 - **CI** : pipeline GitHub Actions → lint, tests avec rapport de couverture, build
 
@@ -297,7 +294,7 @@ coffre-fort ne s'ajoute pas dans la liste, une erreur apparaît m'indiquant que
   1. `npm install`
   2. `npm test`
 
-## 10. Critères de réussite
+## 9. Critères de réussite
 
 - 100 % des scénarios critiques passent
 - 0 anomalie bloquante ouverte
@@ -307,20 +304,14 @@ coffre-fort ne s'ajoute pas dans la liste, une erreur apparaît m'indiquant que
   - 80% de lignes
   - 80% de statements
 
-## 11. Traçabilité
+## 10. Traçabilité
 
 Chaque scénario est lié à :
 
 - Un ID unique (ex. `TC-F3.1`)
+- Des tests Jest reprenant cet ID
 
-[//]: # (TODO : TESTS)
-
-- Un test Jest (`describe/it`) reprenant cet ID
-
-## 12. Gestion des anomalies
-
-- Création d'un ticket "bug" contenant l'ID du scénario dans l'outil de gestion de projet.
-
-[//]: # (TODO : BUGS)
+## 11. Gestion des anomalies
 
-Ajout dans le Plan de correction des bogues (C2.3.2).
+- Création d'un ticket "bug" contenant l'ID du scénario dans l'outil de suivi.
+- Respect du [Plan de correction des bogues](BOGUES.md).