docs: remove #60 OAuth2, enrich 7 feature descriptions in ROADMAP

- Removed #60 OAuth2/OIDC from backlog
- Enriched with plain-language explanations + importance rationale:
  - #64 MFA (TOTP + WebAuthn + recovery codes)
  - #62 Collaboration temps réel (WebSocket + Yjs/CRDT + awareness)
  - #67 Notifications Push API (VAPID + service worker)
  - #68 Health check enrichi (memory, disk, backups, connections)
  - #70 Recherche sémantique (embeddings + FAISS + recherche hybride)
  - #71 Dashboard administrateur (widgets temps réel + users + audit)
  - #72 API publique OpenAPI 3.1 (Swagger UI + Redoc)
- Updated effort summary: 18 items restants, 52-68 jours

docs/ROADMAP.md

@@ -159,18 +159,6 @@
   - [x] UI indicateur : badge « Hors-ligne » + compteur de modifications en attente
   - [x] Gestion des conflits : détection et résolution manuelle (choix version locale vs serveur)
 
-### 60. OAuth2 / OIDC — Authentification SSO
-- **Effort :** 2-3 jours | **Impact :** 🟡
-- **Description :** Support de fournisseurs OAuth2/OIDC externes pour permettre l'authentification via Google, GitHub, ou tout provider compatible. Complément à l'auth JWT existante (pas de remplacement).
-- **Sous-tâches :**
-  - [ ] Configuration par provider : `OBSIGATE_OAUTH_GOOGLE_CLIENT_ID`, `OBSIGATE_OAUTH_GITHUB_CLIENT_ID`, etc.
-  - [ ] Endpoint `GET /api/auth/oauth/login?provider=google` → redirection
-  - [ ] Endpoint `GET /api/auth/oauth/callback` → échange code → token OIDC → création/liaison compte local
-  - [ ] Mapping roles : config `OBSIGATE_OAUTH_DEFAULT_ROLE` (défaut `user`)
-  - [ ] UI : boutons « Se connecter avec Google / GitHub » sur la page login
-  - [ ] Sécurité : state parameter anti-CSRF, PKCE, nonce validation
-  - [ ] Stockage : liaison `oauth_provider` + `oauth_sub` dans `users.json`
-
 ### 61. Plugins système — Extensions utilisateur
 - **Effort :** 4-5 jours | **Impact :** 🟢
 - **Description :** Système de plugins permettant aux utilisateurs d'étendre ObsiGate avec des renderers personnalisés, des opérateurs de recherche, et des hooks d'UI. Inspiré du modèle de plugins Obsidian.
@@ -185,7 +173,12 @@
 
 ### 62. Collaboration temps réel — Édition simultanée
 - **Effort :** 5-7 jours | **Impact :** 🟢
-- **Description :** Édition collaborative de fichiers markdown via WebSocket + CRDT (Yjs). Plusieurs utilisateurs peuvent éditer le même fichier simultanément avec résolution automatique des conflits.
+- **Description :** Permettre à plusieurs utilisateurs d'éditer le même document markdown en même temps, comme Google Docs. Chaque personne voit en temps réel ce que les autres tapent, avec leur curseur affiché en couleur.
+  - **WebSocket** : connexion persistante bidirectionnelle entre le navigateur et le serveur. Contrairement à HTTP où le client doit constamment demander « y a-t-il du nouveau ? » (polling), le WebSocket permet au serveur de pousser les changements instantanément. Une room WebSocket est créée par fichier ouvert — tous les utilisateurs qui éditent le même fichier rejoignent la même room.
+  - **Yjs + CRDT** : Yjs est une bibliothèque qui implémente un algorithme CRDT (Conflict-free Replicated Data Type). Imagine deux personnes qui tapent en même temps au même endroit — sans CRDT, on aurait un conflit et du texte perdu. Avec CRDT, les deux modifications sont fusionnées mathématiquement sans perte. Chaque caractère reçoit un identifiant unique, et l'ordre final est déterministe même si les opérations arrivent dans le désordre. Pas besoin de verrouiller le fichier ni de résoudre des conflits manuellement.
+  - **Awareness** : chaque utilisateur voit le curseur des autres (position, sélection) représenté par un nom et une couleur. Un indicateur dans la barre d'outils montre qui est connecté.
+  - **Persistance** : le serveur sauvegarde périodiquement le document (debounce 2s après la dernière modification) pour que les changements survivent à une déconnexion.
+- **Pourquoi c'est important :** Permet le travail d'équipe sur la documentation, les notes de réunion, les spécifications techniques, les brainstorms. C'est le passage d'ObsiGate de « outil personnel » à « outil d'équipe ».
 - **Sous-tâches :**
   - [ ] Serveur WebSocket : endpoint `/ws/collab/{vault}/{path}` avec gestion des rooms
   - [ ] Intégration Yjs : `Y.Doc` partagé, `Y.Text` pour le contenu markdown
@@ -216,7 +209,11 @@
 
 ### 64. MFA — Authentification multi-facteurs
 - **Effort :** 2 jours | **Impact :** 🟡
-- **Description :** Ajout de TOTP (Time-based One-Time Password) et WebAuthn (clés de sécurité) comme second facteur d'authentification pour les comptes admin.
+- **Description :** Ajout d'un second facteur d'authentification obligatoire pour les comptes administrateur. Deux méthodes sont proposées :
+  - **TOTP** (Time-based One-Time Password) : l'utilisateur scanne un QR code avec son app d'authentification (Google Authenticator, Authy, Bitwarden) qui génère un code à 6 chiffres renouvelé toutes les 30 secondes. Au login, après avoir saisi son mot de passe, l'utilisateur doit entrer le code affiché sur son téléphone. Même si le mot de passe est volé, le compte reste protégé car l'attaquant n'a pas le téléphone.
+  - **WebAuthn** (clés de sécurité physiques) : l'utilisateur enregistre une clé USB (YubiKey, SoloKey) ou utilise la biométrie de son appareil (empreinte digitale, Face ID, Windows Hello). Au login, le navigateur demande de toucher la clé physique ou de scanner le doigt. C'est le niveau de sécurité le plus élevé — résistant au phishing car la clé vérifie le domaine du site avant de répondre.
+  - **Codes de secours** : 8 codes à usage unique imprimables, à conserver en lieu sûr, qui permettent de se connecter même si on perd son téléphone ou sa clé. Chaque code ne fonctionne qu'une seule fois.
+- **Pourquoi c'est important :** Le vol de mot de passe est la cause #1 de brèches de sécurité. Avec un vault Obsidian contenant des notes personnelles, projets sensibles, secrets et tokens API, l'authentification par simple mot de passe n'est plus suffisante. Le MFA empêche 99.9% des attaques de prise de compte automatisées (source : Microsoft Security).
 - **Sous-tâches :**
   - [ ] TOTP : génération de secret, QR code, vérification code 6 chiffres
   - [ ] WebAuthn : enregistrement de clé, assertion, attestation
@@ -559,7 +556,12 @@
 
 ### 67. Notifications web — Push API
 - **Effort :** 2 jours | **Impact :** 🟢
-- **Description :** Notifications push navigateur pour les changements de vault (fichier modifié, ajouté, supprimé). Utilise la Push API et le service worker existant.
+- **Description :** Recevoir des notifications sur le bureau ou le téléphone quand un fichier est modifié, ajouté ou supprimé dans un de vos vaults, même si ObsiGate n'est pas ouvert dans le navigateur.
+  - **Fonctionnement** : Le navigateur s'abonne auprès du serveur via la Push API (standard W3C). Le serveur stocke l'abonnement (endpoint + clés de chiffrement). Quand un fichier change (détecté par le watcher existant), le serveur envoie une notification chiffrée au push service du navigateur (Firebase pour Chrome, APNs pour Safari, etc.), qui la relaye au navigateur même s'il est fermé. Le service worker ObsiGate affiche alors la notification système.
+  - **Contenu** : titre du fichier modifié, nom du vault, type d'action (créé/modifié/supprimé). Un clic sur la notification ouvre directement le fichier dans ObsiGate.
+  - **Configuration** : activation/désactivation par vault. L'utilisateur choisit pour quels vaults il reçoit des notifications.
+  - **VAPID** : protocole d'authentification volontaire qui permet au serveur de s'identifier auprès du push service sans avoir à s'enregistrer comme application. Une paire de clés publique/privée est générée — la clé publique est partagée avec le navigateur, la clé privée reste sur le serveur.
+- **Pourquoi c'est important :** Collaborer sans avoir à constamment rafraîchir l'interface pour voir si quelqu'un a modifié quelque chose. Particulièrement utile en équipe ou pour les vaults partagés via Syncthing — on sait immédiatement quand une note est mise à jour.
 - **Sous-tâches :**
   - [ ] Souscription Push : endpoint `POST /api/push/subscribe` (stockage `subscription` + `vault`)
   - [ ] Envoi : webhook interne `on_file_change` → dispatch notification via Web Push
@@ -570,7 +572,17 @@
 
 ### 68. Health check enrichi
 - **Effort :** 1 jour | **Impact :** 🟢
-- **Description :** Endpoint `/api/health` étendu avec métriques détaillées : état de l'index, consommation mémoire, uptime, connexions SSE actives, nombre de backups, dernière indexation.
+- **Description :** Un endpoint `/api/health` qui ne se contente pas de dire « je suis vivant », mais donne un diagnostic complet de l'état du serveur. Essentiel pour le monitoring et le debugging.
+  - **Métriques exposées :**
+    - **Index** : nombre de fichiers indexés, nombre de tokens, date de la dernière indexation complète. Permet de détecter si l'indexeur est bloqué ou ne tourne plus.
+    - **Mémoire** : consommation RAM du processus (RSS), heap Python utilisé. Permet de détecter les fuites mémoire avant qu'elles ne crashent le serveur.
+    - **Uptime** : depuis quand le serveur tourne. Simple, mais indispensable pour corréler un problème avec un redémarrage.
+    - **Connexions** : nombre de connexions SSE actives (recherche en cours, streaming AI, etc.). Permet de savoir combien d'utilisateurs sont connectés.
+    - **Backups** : nombre total, âge du backup le plus ancien, espace disque consommé. Permet de détecter si les backups s'accumulent anormalement.
+    - **Disque** : espace libre sur la partition `/data`. Évite le crash silencieux quand le disque est plein.
+  - **Format** : JSON structuré, facile à intégrer dans des outils de monitoring (Prometheus, Grafana, Uptime Kuma, Healthchecks.io).
+  - **Sécurité** : l'endpoint public `/api/health` retourne `ok` ou `degraded`, l'endpoint détaillé est protégé par authentification admin.
+- **Pourquoi c'est important :** Actuellement, la seule façon de savoir si ObsiGate a un problème est de constater que ça ne marche plus. Avec un health check enrichi, on peut configurer des alertes automatiques (via Uptime Kuma ou un cron) qui préviennent AVANT que l'utilisateur ne remarque le problème.
 - **Sous-tâches :**
   - [ ] Métriques index : nombre de fichiers, nombre de tokens, génération courante
   - [ ] Métriques mémoire : RSS, heap used (via `psutil` ou `/proc/self/status`)
@@ -591,7 +603,16 @@
 
 ### 70. Recherche sémantique — Embeddings vectoriels
 - **Effort :** 4-5 jours | **Impact :** 🟢
-- **Description :** Moteur de recherche sémantique utilisant des embeddings (sentence-transformers) pour trouver des notes par similarité de sens, au-delà des mots-clés exacts.
+- **Description :** La recherche actuelle (TF-IDF) ne trouve que les documents contenant EXACTEMENT les mots tapés. La recherche sémantique comprend le SENS de la requête et trouve des documents pertinents même s'ils utilisent des mots différents.
+  - **Exemple concret :** Vous cherchez « comment sauvegarder mes données ». La recherche TF-IDF ne trouvera que les documents contenant « sauvegarder » ET « données ». La recherche sémantique trouvera aussi un document titré « Stratégie de backup automatique » ou « Protection contre la perte de fichiers » parce qu'elle comprend que ces phrases parlent de la même chose.
+  - **Fonctionnement technique :**
+    - Chaque document (ou chunk de ~512 tokens) est converti en un **vecteur** (une liste de 384 nombres) par un modèle de langage léger comme `all-MiniLM-L6-v2` (80 Mo, s'exécute en ~2ms par document sur CPU). Ce vecteur capture le sens — deux phrases qui veulent dire la même chose auront des vecteurs très proches.
+    - Au moment de la recherche, la requête utilisateur est elle aussi convertie en vecteur.
+    - On calcule la **similarité cosinus** entre le vecteur de la requête et les vecteurs de tous les documents. Les documents avec la similarité la plus élevée sont retournés.
+    - **Recherche hybride** : on combine le score TF-IDF (pertinence par mots-clés exacts) et le score sémantique (pertinence par sens) via RRF (Reciprocal Rank Fusion) — les documents bien classés par les deux méthodes remontent en premier.
+  - **Stockage** : les vecteurs sont stockés avec FAISS (Facebook AI Similarity Search), une bibliothèque optimisée qui permet de chercher parmi des millions de vecteurs en quelques millisecondes.
+  - **Indexation** : les embeddings sont générés une fois à l'indexation du fichier (pas à chaque recherche). Un fichier modifié voit son embedding regénéré automatiquement par le watcher.
+- **Pourquoi c'est important :** La recherche par mots-clés échoue dans ~30% des cas où l'utilisateur ne se souvient pas des mots exacts utilisés dans ses notes. La recherche sémantique résout ce problème. C'est particulièrement utile pour les gros vaults (500+ notes) où on ne peut pas tout parcourir manuellement.
 - **Sous-tâches :**
   - [ ] Génération d'embeddings : modèle `all-MiniLM-L6-v2` via `sentence-transformers` (Python) ou appel API externe
   - [ ] Stockage : index vectoriel avec `numpy` + `faiss` (ou `usearch` pour performance)
@@ -602,7 +623,21 @@
 
 ### 71. Tableau de bord administrateur
 - **Effort :** 2 jours | **Impact :** 🟢
-- **Description :** Page d'administration dédiée avec monitoring en temps réel, gestion des utilisateurs avancée, et logs d'audit visualisables.
+- **Description :** Une page web dédiée accessible uniquement aux administrateurs qui centralise tout le monitoring et la gestion du serveur ObsiGate en un seul endroit. Un cockpit de pilotage pour le sysadmin.
+  - **Widgets temps réel** (rafraîchis via SSE) :
+    - **CPU / RAM / Disque** : jauges visuelles avec seuils d'alerte (vert < 70%, orange < 90%, rouge > 90%). Permet de voir en un coup d'œil si le serveur est en surcharge.
+    - **Requêtes par minute** : graphique sparkline des dernières 24h. Permet de détecter les pics d'activité anormaux (attaques, bots, bug qui spam l'API).
+    - **Utilisateurs actifs** : nombre de sessions connectées en ce moment, compteur de recherches en cours.
+  - **Gestion des utilisateurs** :
+    - Tableau triable/filtrable de tous les comptes (nom, rôle, date de création, dernière connexion, nombre de vaults).
+    - Création, édition, suppression d'utilisateurs. Attribution de rôles (admin/user/readonly).
+    - Réinitialisation de mot de passe administrateur.
+  - **Logs d'audit visuels** :
+    - Tableau chronologique des 500 dernières actions : qui a fait quoi, quand, depuis quelle IP.
+    - Filtres par utilisateur, type d'action (login, création fichier, suppression, modification settings), plage de dates.
+    - Export CSV pour analyse externe.
+  - **Statistiques backups** : graphique d'évolution du nombre et de la taille des backups par vault. Détection automatique des vaults sans backup récent.
+- **Pourquoi c'est important :** Actuellement, administrer ObsiGate nécessite de se connecter en SSH au serveur et de lire des fichiers JSON. Le dashboard rend toutes ces opérations accessibles depuis l'interface web, avec des visuels qui permettent de diagnostiquer un problème en 10 secondes au lieu de 10 minutes de CLI.
 - **Sous-tâches :**
   - [ ] Widgets temps réel : CPU, mémoire, espace disque, requêtes/min (rafraîchissement SSE)
   - [ ] Gestion utilisateurs : tableau triable, création/édition/suppression, filtre par rôle
@@ -612,7 +647,17 @@
 
 ### 72. API publique documentée — OpenAPI 3.1
 - **Effort :** 1-2 jours | **Impact :** 🟢
-- **Description :** Documentation OpenAPI complète et interactive (Swagger UI + Redoc) pour l'API REST, avec exemples de requêtes, descriptions en anglais, et schémas Pydantic exposés.
+- **Description :** Une page de documentation interactive et auto-générée de toutes les API REST d'ObsiGate, accessible via un bouton dans l'interface. L'équivalent d'un manuel technique mais qui se teste en direct.
+  - **OpenAPI 3.1** : c'est le format standard mondial pour décrire une API REST. Un seul fichier JSON/YAML contient la description de tous les endpoints, leurs paramètres, les formats de réponse, les codes d'erreur, et les modèles de données. Ce standard est supporté par des centaines d'outils.
+  - **Swagger UI** : une interface web qui lit le fichier OpenAPI et génère automatiquement une documentation interactive. L'utilisateur voit chaque endpoint, peut remplir les paramètres dans un formulaire, cliquer « Execute » et voir la réponse réelle de l'API en direct. Parfait pour les développeurs qui veulent intégrer ObsiGate à leurs scripts ou comprendre comment fonctionne l'API.
+  - **Redoc** : une alternative à Swagger UI, plus propre et orientée lecture, idéale pour la documentation publique.
+  - **Contenu documenté :**
+    - Les 40+ endpoints existants, regroupés par catégorie (Fichiers, Vaults, Recherche, Auth, AI, Backups).
+    - Chaque endpoint avec description, paramètres obligatoires/optionnels, exemples de requête et réponse.
+    - Les modèles de données Pydantic exposés comme schémas JSON (ex: structure d'un `FileInfo`, d'un `SearchResult`).
+    - Les codes d'erreur possibles avec leur signification.
+  - **Auto-génération** : FastAPI génère déjà partiellement le schéma OpenAPI. Le travail consiste à compléter les docstrings manquantes, ajouter `response_model` sur les endpoints qui n'en ont pas, et enrichir avec des exemples.
+- **Pourquoi c'est important :** Une API sans documentation est comme un logiciel sans interface — techniquement fonctionnel mais inutilisable. Avec une doc OpenAPI, ObsiGate devient intégrable dans n'importe quel écosystème. Un développeur peut en 5 minutes comprendre comment uploader un fichier, chercher dans un vault, ou récupérer le contenu d'une note — et écrire un script qui automatise ses workflows.
 - **Sous-tâches :**
   - [ ] Audit des endpoints existants → compléter les docstrings manquants
   - [ ] Ajout de `response_model` sur tous les endpoints (40+ actuellement, ~15 sans modèle)
@@ -641,10 +686,10 @@
 | Priorité | Items | Effort total estimé |
 |---|---|---|
 | ✅ Complété | #1 → #57 | ~65 jours |
-| 🔵 P1 | #58 (Playwright) | 2-3 jours |
-| ⚪ P3 | #59 → #66, #74, #75, #76 (11 items) | 34-45 jours |
+|| 🔵 P1 | ✅ #58 (Playwright E2E) | Terminé |
+|| P3 | #59, #61-66, #74, #75, #76 (10 items) | 32-42 jours |
 | ⚪ P4 | #67 → #73 (7 items) | 18-23 jours |
-| **Total restant** | **19 items** | **54-71 jours** |
+|| **Total restant** | **18 items** | **52-68 jours** |
 
 ---