docs: update API integration and data model details

Updated documentation to reflect changes in the API GitHub integration, revised data model for tags, and introduced GDPR timestamp field. Enhanced diagrams and data schema descriptions for clarity.

cdc.md

@@ -130,22 +130,27 @@ flowchart TB
 
     subgraph Storage["Stockage"]
         DB[(PostgreSQL)]
-        S3[("Stockage S3\n(Fichiers)")]
+    end
+
+    subgraph External["Services Externes"]
+        GH["API GitHub"]
     end
 
     FE <-->|"1. Requêtes HTTP/API REST"| BE
     FE <-->|"2. Communication temps réel"| WS
     BE <-->|"3. Requêtes SQL via DrizzleORM"| DB
-    BE <-->|"4. Stockage/Récupération de fichiers"| S3
+    BE <-->|"4. Récupération des avatars"| GH
     BE <-->|"5. Événements temps réel"| WS
 
     classDef client fill:#d8a0d8,stroke:#333,stroke-width:2px
     classDef server fill:#a0a0d8,stroke:#333,stroke-width:2px
     classDef storage fill:#a0d8a0,stroke:#333,stroke-width:2px
+    classDef external fill:#d8d8a0,stroke:#333,stroke-width:2px
 
     class Client client
     class Server server
     class Storage storage
+    class External external
 ```
 
 Ce diagramme montre les principaux flux d'interactions:
@@ -165,10 +170,10 @@ Ce diagramme montre les principaux flux d'interactions:
    - Transactions pour garantir l'intégrité des données
    - Utilisation d'index pour des performances optimales
 
-4. **Backend ↔ Stockage S3**: Gestion des fichiers
+4. **Backend ↔ API GitHub**: Récupération des données utilisateur
-   - Stockage des avatars utilisateurs
+   - Récupération des avatars utilisateurs
-   - Sauvegarde des exports de données
+   - Authentification des utilisateurs
-   - Gestion des pièces jointes
+   - Récupération des informations de profil
 
 5. **Backend ↔ WebSocket**: Gestion des événements
    - Diffusion des mises à jour aux clients connectés
@@ -187,10 +192,10 @@ Cette architecture permet une séparation claire des responsabilités tout en of
 #### 2.3.1 Entités Principales
 1. **User**
    - id: UUIDv7 (clé primaire, type `uuid` optimisé pour l'indexation)
-   - email: String (unique, type `varchar(255)` avec index)
    - name: String (type `varchar(100)`)
-   - avatar: String (URL, type `text`)
+   - avatar: String (URL depuis l'API Github, type `text`)
    - githubId: String (pour l'authentification OAuth, type `varchar(50)` avec index)
+   - gdprTimestamp: DateTime (timestamp d'acceptation RGPD, type `timestamptz`)
    - createdAt: DateTime (type `timestamptz` avec index)
    - updatedAt: DateTime (type `timestamptz`)
    - metadata: JSON (données flexibles, type `jsonb`)
@@ -229,12 +234,13 @@ Cette architecture permet une séparation claire des responsabilités tout en of
    - createdAt: DateTime (type `timestamptz`)
    - updatedAt: DateTime (type `timestamptz`)
 
-5. **PersonTag**
+5. **Tag**
    - id: UUIDv7 (clé primaire, type `uuid` optimisé pour l'indexation)
    - name: String (type `varchar(50)` avec index)
    - color: String (code couleur, type `varchar(7)`)
-   - projectId: UUID (clé étrangère vers Project, type `uuid` avec index)
+   - type: Enum (PROJECT, PERSON, type `enum` natif PostgreSQL)
    - persons: Relation vers Person (table de jointure avec index)
+   - projects: Relation vers Project (table de jointure avec index)
    - createdAt: DateTime (type `timestamptz`)
    - updatedAt: DateTime (type `timestamptz`)
 
@@ -243,11 +249,13 @@ Cette architecture permet une séparation claire des responsabilités tout en of
 - Un **Project** appartient à un seul **User**
 - Un **Project** contient plusieurs **Persons**
 - Un **Project** peut avoir plusieurs **Groups**
+- Un **Project** peut être associé à plusieurs **Tags** de type PROJECT
 - Une **Person** appartient à un seul **Project**
-- Une **Person** peut être associée à plusieurs **PersonTags**
+- Une **Person** peut être associée à plusieurs **Tags** de type PERSON
 - Une **Person** peut être membre d'un seul **Group** à la fois
 - Un **Group** appartient à un seul **Project**
 - Un **Group** peut contenir plusieurs **Persons**
+- Les **Tags** sont globaux et gérés par les administrateurs
 
 #### 2.3.3 Schéma de Base de Données
 Le schéma sera implémenté via DrizzleORM, permettant une définition type-safe des tables et relations avec une approche code-first. Les migrations SQL seront générées automatiquement à partir des changements de schéma, offrant un contrôle précis sur l'évolution de la base de données.
@@ -259,10 +267,10 @@ Le diagramme ci-dessous représente le modèle conceptuel de données de l'appli
 erDiagram
     USER {
         uuid id PK
-        string email
         string name
         string avatar
         string githubId
+        datetime gdprTimestamp
         datetime createdAt
         datetime updatedAt
         json metadata
@@ -303,11 +311,11 @@ erDiagram
         datetime updatedAt
     }
 
-    PERSON_TAG {
+    TAG {
         uuid id PK
         string name
         string color
-        uuid projectId FK
+        enum type
         datetime createdAt
         datetime updatedAt
     }
@@ -315,8 +323,8 @@ erDiagram
     USER ||--o{ PROJECT : "possède"
     PROJECT ||--o{ PERSON : "contient"
     PROJECT ||--o{ GROUP : "contient"
-    PROJECT ||--o{ PERSON_TAG : "contient"
+    PROJECT }o--o{ TAG : "est associé à"
-    PERSON }o--o{ PERSON_TAG : "est associée à"
+    PERSON }o--o{ TAG : "est associée à"
     PERSON }o--|| GROUP : "est membre de"
 ```
 
@@ -327,10 +335,10 @@ Le diagramme ci-dessous représente le modèle logique de données, montrant les
 erDiagram
     users {
         uuid id PK
-        varchar(255) email
         varchar(100) name
         text avatar
         varchar(50) githubId
+        timestamptz gdprTimestamp
         timestamptz createdAt
         timestamptz updatedAt
         jsonb metadata
@@ -371,11 +379,11 @@ erDiagram
         timestamptz updatedAt
     }
 
-    person_tags {
+    tags {
         uuid id PK
         varchar(50) name
         varchar(7) color
-        uuid projectId FK
+        enum type
         timestamptz createdAt
         timestamptz updatedAt
     }
@@ -394,14 +402,22 @@ erDiagram
         timestamptz createdAt
     }
 
+    project_to_tag {
+        uuid id PK
+        uuid projectId FK
+        uuid tagId FK
+        timestamptz createdAt
+    }
+
     users ||--o{ projects : "ownerId"
     projects ||--o{ persons : "projectId"
     projects ||--o{ groups : "projectId"
-    projects ||--o{ person_tags : "projectId"
+    projects ||--o{ project_to_tag : "projectId"
     persons ||--o{ person_to_group : "personId"
     groups ||--o{ person_to_group : "groupId"
     persons ||--o{ person_to_tag : "personId"
-    person_tags ||--o{ person_to_tag : "tagId"
+    tags ||--o{ person_to_tag : "tagId"
+    tags ||--o{ project_to_tag : "tagId"
 ```
 
 ##### 2.3.3.3 Stratégie d'Indexation
@@ -415,15 +431,16 @@ Pour optimiser les performances des requêtes, les stratégies d'indexation suiv
 DrizzleORM facilite la définition de ces index directement dans le schéma avec une syntaxe déclarative:
 ```typescript
 // Exemple de définition d'index avec DrizzleORM
-import { pgTable, uuid, varchar, index } from 'drizzle-orm/pg-core';
+import { pgTable, uuid, varchar, timestamp, index } from 'drizzle-orm/pg-core';
 
 export const users = pgTable('users', {
   id: uuid('id').primaryKey().defaultRandom(),
-  email: varchar('email', { length: 255 }).notNull().unique(),
   name: varchar('name', { length: 255 }),
+  githubId: varchar('githubId', { length: 50 }),
+  gdprTimestamp: timestamp('gdprTimestamp', { withTimezone: true }),
 }, (table) => {
   return {
-    emailIdx: index('email_idx').on(table.email),
+    githubIdIdx: index('githubId_idx').on(table.githubId),
     nameIdx: index('name_idx').on(table.name),
   };
 });
@@ -448,28 +465,33 @@ flowchart TD
     User[Utilisateur] -->|Crée et gère| Project[Projet]
     Project -->|Contient| Person[Personnes]
     Project -->|Organise en| Group[Groupes]
+    Project -->|Associé à| Tag[Tags/Étiquettes]
     Person -->|Appartient à| Group
-    Person -->|Possède| Tag[Tags/Étiquettes]
+    Person -->|Associée à| Tag
+    Admin[Administrateur] -->|Gère| Tag
 
     classDef user fill:#d8a0d8,stroke:#333,stroke-width:2px
     classDef project fill:#a0a0d8,stroke:#333,stroke-width:2px
     classDef person fill:#a0d8a0,stroke:#333,stroke-width:2px
     classDef group fill:#d8a0a0,stroke:#333,stroke-width:2px
     classDef tag fill:#d8d8a0,stroke:#333,stroke-width:2px
+    classDef admin fill:#a0d8d8,stroke:#333,stroke-width:2px
 
     class User user
     class Project project
     class Person person
     class Group group
     class Tag tag
+    class Admin admin
 ```
 
 Ce diagramme illustre les concepts clés de l'application:
 - Un **Utilisateur** crée et gère des projets
-- Chaque **Projet** contient des personnes et des groupes
+- Chaque **Projet** contient des personnes et des groupes et peut être associé à des tags
-- Les **Personnes** sont organisées en groupes et peuvent avoir des tags
+- Les **Personnes** sont organisées en groupes et peuvent être associées à des tags
 - Les **Groupes** sont composés de personnes
-- Les **Tags** permettent de catégoriser les personnes selon différents critères
+- Les **Tags** permettent de catégoriser les personnes et les projets selon différents critères
+- L'**Administrateur** gère les tags globaux utilisés dans toute l'application
 
 Cette représentation simplifiée permet aux parties prenantes non-techniques de comprendre facilement la structure générale de l'application sans avoir à se plonger dans les détails techniques du modèle de données.
 
@@ -522,22 +544,27 @@ Cette représentation simplifiée permet aux parties prenantes non-techniques de
 - Création de compte utilisateur obligatoire pour utiliser pleinement les fonctionnalités
 - Authentification via OAuth2.0 avec GitHub:
   - Flux d'authentification sécurisé avec redirection vers GitHub
-  - Récupération des informations de base du profil (nom, email, avatar)
+  - Récupération des informations de base du profil (nom, avatar) depuis l'API GitHub
   - Possibilité d'étendre à d'autres fournisseurs d'identité dans le futur
 - Gestion des sessions utilisateur avec JWT (JSON Web Tokens):
   - Token d'accès avec durée de validité limitée (15 minutes)
   - Token de rafraîchissement pour prolonger la session (validité de 7 jours)
   - Révocation des tokens en cas de déconnexion ou de suspicion de compromission
 - Gestion des autorisations basée sur les rôles (RBAC):
-  - Rôle administrateur pour la gestion globale
+  - Rôle administrateur pour la gestion globale:
+    - Gestion des tags globaux (création, modification, suppression)
+    - Attribution des types de tags (PROJECT, PERSON)
+    - Surveillance de l'utilisation des tags
+    - Gestion des utilisateurs et de leurs droits
   - Rôle utilisateur standard pour la création et gestion de projets personnels
   - Rôle invité pour l'accès en lecture seule à des projets partagés
 
 #### 3.2.2 Profil Utilisateur
 - Gestion des informations personnelles:
   - Modification du nom d'affichage
-  - Mise à jour de l'avatar
+  - Affichage de l'avatar récupéré depuis l'API GitHub
   - Gestion des préférences (notifications, thème, langue)
+  - Gestion du consentement RGPD (timestamp)
 - Tableau de bord personnel:
   - Vue d'ensemble des projets créés
   - Statistiques d'utilisation
@@ -553,14 +580,43 @@ Cette représentation simplifiée permet aux parties prenantes non-techniques de
 - Suppression de compte avec option de conservation ou suppression des projets
 - Conformité RGPD avec droit à l'oubli et portabilité des données
 
-### 3.3 Création et Gestion de Groupes
+### 3.3 Système d'Administration
-#### 3.3.1 Création de Projet de Groupe
+
+#### 3.3.1 Interface d'Administration
+- Tableau de bord administrateur dédié:
+  - Vue d'ensemble de l'utilisation de l'application
+  - Statistiques sur les utilisateurs, projets, et tags
+  - Alertes et notifications système
+- Accès sécurisé réservé aux utilisateurs avec le rôle administrateur
+- Interface distincte de l'application principale
+
+#### 3.3.2 Gestion des Tags Globaux
+- Interface de création et gestion des tags:
+  - Création de nouveaux tags avec nom et couleur
+  - Définition du type de tag (PROJECT ou PERSON)
+  - Modification des tags existants
+  - Suppression des tags non utilisés
+- Visualisation de l'utilisation des tags:
+  - Nombre de projets et personnes associés à chaque tag
+  - Statistiques d'utilisation par utilisateur
+- Possibilité de fusionner des tags similaires
+- Exportation de la liste des tags au format CSV
+
+#### 3.3.3 Gestion des Utilisateurs
+- Liste complète des utilisateurs avec filtres et recherche
+- Modification des rôles utilisateur (administrateur, utilisateur standard, invité)
+- Surveillance de l'activité des utilisateurs
+- Possibilité de désactiver temporairement un compte utilisateur
+- Vérification du statut RGPD des utilisateurs
+
+### 3.4 Création et Gestion de Groupes
+#### 3.4.1 Création de Projet de Groupe
 - Possibilité de créer une liste de personnes qui seront placées dans les groupes
 - Attribution de "tags" aux personnes
 - Définition d'échelles de niveau personnalisées
 - Nom de projet unique à l'échelle de l'utilisateur
 
-#### 3.3.2 Attributs des Personnes
+#### 3.4.2 Attributs des Personnes
 Chaque personne dans le système sera caractérisée par les attributs suivants :
 - Prénom
 - Nom
@@ -571,12 +627,12 @@ Chaque personne dans le système sera caractérisée par les attributs suivants
 - Niveau d'aisance à l'oral (timide, réservé, à l'aise)
 - Âge
 
-#### 3.3.3 Interface de Création Manuelle
+#### 3.4.3 Interface de Création Manuelle
 - Affichage de la liste des personnes sur le côté (format desktop minimum)
 - Possibilité de réaliser manuellement les groupes
 - Option de renommer chaque groupe manuellement
 
-#### 3.3.4 Assistant à la Création de Groupe
+#### 3.4.4 Assistant à la Création de Groupe
 - Fonctionnalité de création aléatoire de groupes
 - L'utilisateur définit le nombre de groupes souhaités
 - Attribution obligatoire d'un nom à chaque groupe
@@ -584,7 +640,7 @@ Chaque personne dans le système sera caractérisée par les attributs suivants
   - Groupes équilibrés pour la progression du niveau
   - Groupes équilibrés par niveau de compétence
 
-### 3.4 Communication en Temps Réel
+### 3.5 Communication en Temps Réel
 - Utilisation de SocketIO pour les mises à jour en temps réel
 - Notification des modifications de groupes aux utilisateurs concernés
 - Collaboration possible entre utilisateurs sur un même projet de groupe