docs: add system architecture interaction flow diagram

cdc.md

@@ -114,7 +114,70 @@ L'application suivra une architecture monorepo avec séparation claire entre le
 - WebSockets via SocketIO pour les communications en temps réel
 - Authentification via JWT pour sécuriser les échanges
 
-#### 2.2.3 Déploiement
+#### 2.2.3 Architecture et Flux d'Interactions
+Le diagramme ci-dessous illustre les interactions entre les différents composants du système:
+
+```mermaid
+flowchart TB
+    subgraph Client["Client (Navigateur)"]
+        FE["Frontend (NextJS)"]
+    end
+
+    subgraph Server["Serveur"]
+        BE["Backend (NestJS)"]
+        WS["WebSocket (SocketIO)"]
+    end
+
+    subgraph Storage["Stockage"]
+        DB[(PostgreSQL)]
+        S3[("Stockage S3\n(Fichiers)")]
+    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 <-->|"5. Événements temps réel"| WS
+
+    classDef client fill:#f9f,stroke:#333,stroke-width:2px
+    classDef server fill:#bbf,stroke:#333,stroke-width:2px
+    classDef storage fill:#bfb,stroke:#333,stroke-width:2px
+
+    class Client client
+    class Server server
+    class Storage storage
+```
+
+Ce diagramme montre les principaux flux d'interactions:
+
+1. **Frontend ↔ Backend**: Communication via API REST pour les opérations CRUD standard
+   - Requêtes HTTP pour la création, lecture, mise à jour et suppression de données
+   - Authentification via JWT pour sécuriser les échanges
+   - Validation des données côté client et serveur
+
+2. **Frontend ↔ WebSocket**: Communication en temps réel
+   - Notifications instantanées
+   - Mises à jour en direct des groupes
+   - Collaboration entre utilisateurs
+
+3. **Backend ↔ Base de données**: Persistance des données
+   - Requêtes SQL optimisées via DrizzleORM
+   - Transactions pour garantir l'intégrité des données
+   - Utilisation d'index pour des performances optimales
+
+4. **Backend ↔ Stockage S3**: Gestion des fichiers
+   - Stockage des avatars utilisateurs
+   - Sauvegarde des exports de données
+   - Gestion des pièces jointes
+
+5. **Backend ↔ WebSocket**: Gestion des événements
+   - Diffusion des mises à jour aux clients connectés
+   - Gestion des salles pour les projets collaboratifs
+   - Notification des changements en temps réel
+
+Cette architecture permet une séparation claire des responsabilités tout en offrant une expérience utilisateur fluide et réactive.
+
+#### 2.2.4 Déploiement
 - Conteneurisation avec Docker pour assurer la cohérence entre les environnements
 - CI/CD via GitHub Actions pour l'intégration et le déploiement continus
 - Infrastructure scalable pour gérer les pics de charge
@@ -377,6 +440,39 @@ Les types de données PostgreSQL seront optimisés pour chaque cas d'usage:
 
 Ces optimisations permettront d'améliorer les performances des requêtes, de réduire l'empreinte mémoire et d'assurer l'intégrité des données.
 
+##### 2.3.3.5 Modèle Simplifié pour Utilisateurs Non-Techniques
+Le diagramme ci-dessous présente une version simplifiée du modèle de données, conçue pour être facilement compréhensible par des personnes non-techniques:
+
+```mermaid
+flowchart TD
+    User[Utilisateur] -->|Crée et gère| Project[Projet]
+    Project -->|Contient| Person[Personnes]
+    Project -->|Organise en| Group[Groupes]
+    Person -->|Appartient à| Group
+    Person -->|Possède| Tag[Tags/Étiquettes]
+
+    classDef user fill:#f9f,stroke:#333,stroke-width:2px
+    classDef project fill:#bbf,stroke:#333,stroke-width:2px
+    classDef person fill:#bfb,stroke:#333,stroke-width:2px
+    classDef group fill:#fbb,stroke:#333,stroke-width:2px
+    classDef tag fill:#ffb,stroke:#333,stroke-width:2px
+
+    class User user
+    class Project project
+    class Person person
+    class Group group
+    class Tag tag
+```
+
+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
+- Les **Personnes** sont organisées en groupes et peuvent avoir des tags
+- Les **Groupes** sont composés de personnes
+- Les **Tags** permettent de catégoriser les personnes selon différents critères
+
+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.
+
 ## 3. Spécifications Fonctionnelles
 
 ### 3.1 Interface Utilisateur