ObsiGate/docs/ROADMAP.md

ObsiGate — Roadmap

Version : 2.0.0-dev | Dernière mise à jour : 2026-06-18 Voir aussi CHANGELOG.md, AUDIT_TECHNIQUE.md

---

Légende

Icône	Signification
✅	Terminé
🔵	En cours
⚪	Prévu / Backlog
🔴 Impact	Critique / Bloquant
🟡 Impact	Utile / Attendu
🟢 Impact	Nice-to-have / Confort

---

✅ Complété (v1.0.0 → v2.0.0-dev)

Fondations (v1.0.0 → v1.4.0)

#	Feature	Effort	Impact
1	FastAPI backend — CRUD fichiers, vaults, recherche full-text	5j	🔴
2	Moteur TF-IDF + stemming français (snowballstemmer)	2j	🔴
3	Watchdog — indexation temps réel avec debounce	1j	🟡
4	Interface SPA vanilla JS — sidebar, viewer, éditeur CodeMirror	8j	🔴
5	Sécurité : JWT + Argon2id, rate limiting, audit log, CSP headers	3j	🔴
6	Protection path traversal, utilisateur non-root Docker	0.5j	🔴
7	Compression GZip SSE-safe, Cache-Control immutable	0.5j	🟢
8	PWA : manifest, service worker, mode standalone	1j	🟡

UX & Productivité (v1.5.0 → v1.6.0)

#	Feature	Effort	Impact
9	Publication publique de documents (lien partageable, token)	1j	🟡
10	Webhooks HTTP avec signature HMAC-SHA256	1j	🟡
11	Dashboard statistiques (fichiers, tags, taille, vaults)	0.5j	🟡
12	Gestion des conflits Syncthing	0.5j	🟢
13	Index inversé incrémental (hook pattern)	1j	🟡
14	Backlinks panel dans le viewer	0.5j	🟡
15	Fichiers non-supportés → UI download	0.3j	🟢
16	Redaction de secrets (secret_redactor.py)	0.5j	🟡
17	Backup automatique avant écriture, restauration	1j	🟡
18	Vue graphe — Barnes-Hut, focus, plein écran, export PNG	3j	🟡
19	Header flat design, sticky panels, navigation historique ← → ↑	1j	🟢
20	Ctrl+survol → aperçu contenu formaté	0.5j	🟢

Architecture (v1.5.1)

#	Feature	Effort	Impact
21	Split app.js (8 875 lignes) → 16 modules ES	3j	🔴
22	Validateur imports/exports CI + tests unitaires frontend Node.js	0.5j	🟡

CI/CD & Qualité (v1.6.0)

#	Feature	Effort	Impact
23	Pipeline Gitea Actions : lint → test → security → build	1j	🔴
24	Ruff (0 erreur) + Mypy (0 erreur) + Bandit SAST + Pip-audit	0.5j	🟡
25	Pytest : 285 tests, 63% coverage	3j	🔴

AI Editor (v1.7.0)

#	Feature	Effort	Impact
26	Toolbar : Edit, Tone, Translate, Generate, Rewrite, Toolbox	2j	🟡
27	Multi-provider : DeepSeek, OpenRouter, Gemini	1j	🟡
28	16 endpoints REST /api/ai/{action} + backend ai.py / ai_routes.py	2j	🟡
29	Auto-save silencieux (2s debounce), loading toasts	0.5j	🟢

Fonctionnalités avancées (v1.8.0 → v1.9.0)

#	Feature	Effort	Impact
30	Export PDF via WeasyPrint (endpoint API + lien share public)	1j	🟡
31	Palette de commandes Ctrl+Alt+Space	1j	🟡
32	Barre d'outils mobile + palette fichiers/commandes 📱	1j	🟡
33	Drag & drop de fichiers	1j	🟡
34	Filtres recherche avancés : created:, modified:, size:	0.5j	🟡
35	Fichiers récents par vault	0.5j	🟡
36	Indicateur AI Actif (header + toast)	0.3j	🟢
37	Page d'accueil de vault (liste récursive par date, style recherche)	0.5j	🟡
38	Indexation non-bloquante (background thread)	0.5j	🟡
39	Git tags semver (v1.8.0, v1.9.0)	0.2j	🟢

Gestion des Backups (v1.9.0)

#	Feature	Effort	Impact
40	Diff viewer : unifié + côte à côte, restauration depuis backup	1j	🟡
41	Gestionnaire de backups : page complète, filtre, suppression, purge	1.5j	🟡
42	Purge par vault avec confirmation, preview contenu (100 Ko)	0.5j	🟡
43	Compression gzip des vieux backups (niveau 6)	0.5j	🟢
44	Backup automatique périodique (POST /api/backups/auto)	1j	🟡
45	Restauration depuis le gestionnaire (extraction timestamp, confirmation)	0.5j	🟡
46	Auto-nettoyage : max_backups_per_file (défaut 10)	0.5j	🟡

Mermaid.js (v2.0.0-dev)

#	Feature	Effort	Impact
47	CDN mermaid@11, securityLevel: strict, startOnLoad: false	0.5j	🟡
48	renderMermaidBlocks() — parse, rendu SVG, bloc d'erreur stylisé	1j	🟡
49	22 templates (flowchart → sankey-beta)	0.5j	🟡
50	Live preview dans l'éditeur (debounce 500ms, panneau #mermaid-live-preview)	1j	🟡
51	Thème dark/light synchronisé, export SVG + PNG	1j	🟡
52	Rendu inline dans le viewer Markdown	0.5j	🟡
53	Zoom molette + drag + boutons +/-	0.5j	🟢
54	Mode plein écran avec header bar (icônes zoom, copy, download, close)	0.5j	🟢
55	Focus mode — clic diagramme → panneau latéral 480px	0.3j	🟡
56	Pré-processeur Obsidian ([[liens]], ![[img]], ==highlight==)	0.3j	🟡
57	Header bar : type de diagramme + toggle Code/Preview + copy SVG + download PNG	1j	🟡

---

🔵 En cours (P1)

58. Tests E2E Playwright ✅ FAIT

• Effort : 2-3 jours | Impact : 🔴
• Description : Tests navigateur automatisés pour les flows critiques : login, navigation vault, recherche full-text, ouverture/édition/sauvegarde de fichier, rendu Mermaid, export PDF.
• Implémentation : 44 tests Playwright (chromium-desktop) + 12 tests mobile dans tests/e2e/obsigate.spec.ts. Intégré au CI Gitea (job e2e après build).
• Sous-tâches :
  • Installation Playwright + config (playwright.config.ts)
  • Fixtures : vault de test (utilise les vaults Docker existants)
  • Test : dashboard → stats, tabs, Quick Help, sidebar
  • Test : recherche full-text → résultats, snippets, tri pertinence/date
  • Test : ouverture fichier → viewer Markdown, métadonnées
  • Test : éditeur → Forge, basic modal, Ctrl+S
  • Test : rendu Mermaid dans le viewer + preview Forge
  • Test : export PDF → bouton présent
  • Test : mode sombre → toggle, persistence localStorage
  • Test : responsive mobile → layout, recherche, barre flottante
  • Test : barre flottante résultats → compteur, nav, toggles Aa/wd
  • Test : sauvegardes → filtres Tous/Recherches/Répertoires
  • Test : raccourcis clavier → Ctrl+K, /, Escape
  • Test : menu contextuel répertoire
  • Intégration CI : job e2e dans .gitea/workflows/ci.yml

---

⚪ Backlog — Priorité 3 (P3)

59. Mode hors-ligne PWA complet ✅ FAIT

• Effort : 3-4 jours | Impact : 🟡
• Description : Service worker avancé avec IndexedDB pour permettre la navigation et la recherche en mode hors-ligne, avec file de synchronisation au retour réseau.
• Implémentation : offline-db.js (377 lignes) + offline.js (209 lignes). IndexedDB 3 stores (files, content, pending). Badge hors-ligne dans le header. Modale résolution de conflits.
• Sous-tâches :
  • IndexedDB : stockage local de l'index des fichiers (paths, titles, tags)
  • Moteur de recherche offline via IndexedDB (cursor + filtre)
  • Cache des fichiers markdown récemment ouverts (derniers 50, prune)
  • Stratégie de cache : Network First avec fallback IndexedDB
  • File de synchronisation : modifications offline → appliquées au retour réseau
  • UI indicateur : badge « Hors-ligne » + compteur de modifications en attente
  • 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.
• Sous-tâches :
  • Spécification du format de plugin : plugin.json (name, version, hooks, permissions)
  • API de hooks : onFileRender, onSearchFilter, onEditorAction, onSidebarItem
  • Sandbox d'exécution : Web Worker isolé pour le code plugin
  • UI : page « Plugins » dans les paramètres (installer, activer/désactiver, désinstaller)
  • Distribution : dépôt de plugins communautaire (fichier JSON index)
  • Hot-reload : activation/désactivation sans rechargement de page
  • Sécurité : manifest de permissions, validation de signature, CSP restrictif

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.
• 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
  • Awareness : curseurs colorés par utilisateur, sélections visibles
  • Synchro backend : persistance périodique du document (debounce 2s)
  • Gestion des droits : vérification check_vault_access par connexion WS
  • UI : indicateur de présence (avatars dans la barre d'outils éditeur)
  • UI : curseurs distants dans CodeMirror (extension collaborative)
  • Gestion des déconnexions : reconnexion automatique, merge state au retour
  • Tests de charge : 5+ utilisateurs simultanés sur le même fichier

63. Internationalisation (i18n) — Multilingue

• Effort : 2-3 jours | Impact : 🟡 | Statut : 🟢 90% complété
• Description : Support de l'anglais et du français via un système de clés de traduction. L'interface est actuellement en français uniquement. L'anglais est nécessaire pour une adoption plus large.
• Sous-tâches :
  • Extraction des chaînes : inventaire de toutes les chaînes UI (~300) → 1171 clés extraites
  • Format : JSON fr.json + en.json dans frontend/locales/ → 1171 clés parfaitement synchronisées
  • Fonction t(key) → frontend/js/i18n.js avec _applyDOM(), data-i18n, data-i18n-attr, data-i18n-placeholder, data-i18n-html
  • Sélecteur de langue dans les paramètres (persisté localStorage) → localStorage.setItem('obsigate-lang')
  • Traduction des messages backend (erreurs API, toasts) — partiel : ~30 fichiers Python avec chaînes FR en dur
  • Documentation multilingue (README.fr.md, README.md)
  • Nettoyage : ~563 clés inutilisées dans les locales (auto-générées, sans référence HTML)
  • Tests : 17 fichiers JS sans import { t } — certains avec texte FR résiduel (ai.js, autocomplete.js, graph.js, etc.)
  • Interface principale : dashboard, sidebar, editor, search, settings → EN/FR complet
  • Guide d'utilisation : toutes les sections (Intro → Astuces) → 94 paragraphes traduits
  • Thèmes, palette de commandes, raccourcis → EN/FR complet
  • Messages toast backend : showToast() reçoit parfois du texte FR en dur depuis Python

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.
• Sous-tâches :
  • TOTP : génération de secret, QR code, vérification code 6 chiffres
  • WebAuthn : enregistrement de clé, assertion, attestation
  • UI : page « Sécurité du compte » avec activation/désactivation MFA
  • Flow login : mot de passe → challenge TOTP si activé
  • Recovery codes : 8 codes de backup à usage unique
  • Stockage : totp_secret + webauthn_credential_id dans users.json

65. Thèmes personnalisés — CSS variables

• Effort : 1-2 jours | Impact : 🟢
• Description : Exposition de variables CSS pour permettre aux utilisateurs de créer des thèmes personnalisés. Presets inclus : light, dark, high-contrast, sepia.
• Sous-tâches :
  • Audit des variables CSS existantes → liste des 30+ variables
  • Fichier themes.json avec presets (light, dark, high-contrast, sepia)
  • UI : sélecteur de thème dans les paramètres (aperçu live)
  • Import/export de thème personnalisé (JSON)
  • Application dynamique sans rechargement (document.documentElement.style.setProperty)

66. Export multi-formats

• Effort : 1-2 jours | Impact : 🟢
• Description : Export de notes individuelles ou de vaults entiers en HTML standalone, bundle Markdown (.zip), et ePub pour liseuses.
• Sous-tâches :
  • Export HTML standalone : CSS inliné, images en base64, navigation inter-fichiers
  • Export MD bundle : ZIP du vault avec structure préservée
  • Export ePub : conversion markdown → ePub via markdown + ebooklib
  • UI : bouton « Exporter » dans le viewer (fichier unique) + dans le menu vault (export complet)
  • Endpoints : GET /api/export/html, GET /api/export/md-bundle, GET /api/export/epub

74. Support complet des documents PDF

• Effort : 4-5 jours | Impact : 🟡
• Description : Prise en charge native des fichiers PDF dans ObsiGate avec parité fonctionnelle complète avec les documents Markdown : apparition dans l'arborescence, indexation full-text, visualisation inline dans le navigateur, recherche TF-IDF, et téléchargement. Actuellement, les PDF sont traités comme des fichiers binaires non supportés (message « Ce fichier est binaire et ne peut pas être affiché » + bouton download).
• Architecture actuelle :
  • SUPPORTED_EXTENSIONS (backend/indexer.py:56) : ne contient pas .pdf → les PDF sont ignorés par l'indexeur, le file watcher, et l'arborescence
  • api_file_view() (backend/main.py:2303) : UnicodeDecodeError sur lecture → retourne unsupported: true
  • frontend/js/viewer.js:377 : si data.unsupported → affiche le message binaire + bouton download
  • pdf_export.py : exporte du MD → PDF (WeasyPrint) — aucun rapport avec la lecture de PDF existants
  • Icone PDF déjà présente dans EXT_ICONS frontend (.pdf → file-text) — inutilisée
• Sous-tâches :

A. Backend — Extraction de texte PDF (1-1.5 jour)

• A1. Dépendance : Ajouter pymupdf (PyMuPDF/fitz) à requirements.txt — bibliothèque C performante avec extraction texte + métadonnées, déjà compatible avec l'image Docker (libs système GTK/Pango déjà présentes pour WeasyPrint). Alternative légère : pypdf (pure Python, pas de deps système) si pymupdf pose problème.
• A2. Module backend/pdf_reader.py : Créer un module dédié avec les fonctions :
  • extract_pdf_text(file_path: Path) -> str : extrait tout le texte du PDF, page par page, avec séparateur \f entre pages. Gère les PDF encodés, protégés par mot de passe (retourne erreur explicite), et corrompus.
  • extract_pdf_metadata(file_path: Path) -> dict : extrait titre, auteur, sujet, nombre de pages, taille.
  • extract_pdf_preview(file_path: Path, max_chars: int = 100000) -> str : extrait les N premiers caractères pour l'indexation (limité par SEARCH_CONTENT_LIMIT).
• A3. Fallback pypdf : Si pymupdf non disponible (exception d'import), fallback automatique sur pypdf avec un log warning. Code structuré avec une interface abstraite (PdfReader protocol) pour swap transparent.

B. Backend — Indexation des PDF (1 jour)

• B1. Ajout à SUPPORTED_EXTENSIONS : Ajouter .pdf au set dans backend/indexer.py:56. Déclencher un rebuild complet de l'index (incrémental via le file watcher pour les nouveaux PDFs).
• B2. Modification de index_document() (backend/indexer.py:524) : Dans la fonction d'indexation, détecter l'extension .pdf et appeler extract_pdf_text() au lieu de read_text(). Le texte extrait alimente le pipeline TF-IDF existant — aucun changement nécessaire dans search.py.
• B3. Métadonnées PDF dans le document info : Enrichir la structure de retour de index_document() avec les champs spécifiques PDF : page_count, pdf_title (titre extrait des métadonnées, prioritaire sur le nom de fichier), pdf_author.
• B4. Gestion d'erreur robuste : PDF corrompu → log warning + skip (ne pas bloquer l'indexation). PDF volumineux (>50 Mo) → log info + extraction tronquée à SEARCH_CONTENT_LIMIT. Timeout d'extraction configurable (30s par défaut).

C. Backend — API endpoints PDF (0.5 jour)

• C1. Modification de api_file_view() (backend/main.py:2270) : Avant la tentative de read_text(), détecter .pdf par extension. Pour les PDF :
  • Extraire le texte avec extract_pdf_text()
  • Extraire les métadonnées (pages, auteur)
  • Retourner une réponse structurée : is_pdf: true, page_count, pdf_metadata, html (aperçu texte formaté), raw_length
  • Le champ html contient un rendu texte simple (pas de markdown) : texte paginé ou première page formatée
• C2. Nouvel endpoint GET /api/file/{vault}/pdf/stream : Sert le fichier PDF brut avec Content-Type: application/pdf et Content-Disposition: inline pour visualisation dans le navigateur. Supporte le Range header (HTTP 206 Partial Content) pour le streaming progressif des gros PDFs — essentiel pour la performance sur des documents volumineux.
• C3. Nouvel endpoint GET /api/file/{vault}/pdf/info : Retourne les métadonnées seules (pages, titre, auteur) sans le contenu — permet à l'UI d'afficher les infos avant de charger le PDF lourd.
• C4. Endpoint download : Déjà fonctionnel (/api/file/{vault}/download) — aucun changement nécessaire.

D. Frontend — Arborescence de fichiers (0.5 jour)

• D1. Icône et filtre : L'icône PDF (file-text de Lucide) est déjà mappée dans EXT_ICONS (frontend/js/utils.js:129). Une fois .pdf dans SUPPORTED_EXTENSIONS, les PDFs apparaissent automatiquement dans l'arborescence via l'API list_directory. Aucun changement UI nécessaire.
• D2. Distinction visuelle (optionnel) : Sous-titre léger sous le nom du fichier dans l'arborescence indiquant le nombre de pages (ex: « 12 pages ») pour différencier rapidement les PDF des MD. Donnée disponible via l'API pdf/info.
• D3. Drag & drop et upload : Le mécanisme d'upload existant (POST /api/file/{vault}/upload) fonctionne déjà pour tout type de fichier. Vérifier que le MIME type application/pdf est correctement détecté et que le watcher réindexe automatiquement.

E. Frontend — Viewer PDF (1 jour)

• E1. Rendu inline natif : Utiliser le visualiseur PDF intégré du navigateur via <iframe> pointant sur /api/file/{vault}/pdf/stream?path=.... Approche optimale :
  • Zéro dépendance JS supplémentaire
  • Rendu identique à Chrome/Firefox/Safari natif
  • Support natif du zoom, recherche dans le document, navigation par pages, rotation
  • L'iframe s'adapte en hauteur (height: 100% du content-area)
• E2. Détection dans le viewer : Dans frontend/js/viewer.js, fonction renderFileContent() — ajouter une branche après la détection data.unsupported :
  • Si data.is_pdf === true → render l'iframe PDF au lieu du viewer markdown
  • Si le navigateur ne supporte pas le rendu PDF inline → fallback sur l'UI « binaire » avec bouton download + bouton « Ouvrir dans un nouvel onglet »
• E3. Barre d'outils PDF : Dans la barre d'outils du viewer (celle qui a déjà les boutons Copier, Source, .md, PDF, Éditer, pop-out), pour les fichiers PDF :
  • Remplacer « Copier » / « Source » / « Éditer » par des actions spécifiques PDF
  • Bouton « Télécharger » (.pdf) — déjà existant, fonctionne
  • Bouton « Plein écran » — ouvre le PDF dans un nouvel onglet en plein écran
  • Badge « N pages » indiquant le nombre de pages
  • Bouton « pop-out » — gardé, ouvre le viewer PDF dans une popup séparée
• E4. Thème : L'iframe PDF est en dehors du DOM applicatif donc pas affecté par le thème dark/light. Ajouter un message discret « Le PDF s'affiche avec le thème de votre navigateur » si _currentTheme === 'dark' (les PDFs en fond blanc dans un thème sombre peuvent surprendre).
• E5. Responsive : L'iframe s'adapte à la largeur du content-area. En mode mobile, hauteur ajustée à la viewport. La toolbar mobile existante fonctionne avec les actions PDF.

F. Frontend — Recherche (0.5 jour)

• F1. Résultats de recherche : Les PDFs apparaissent dans les résultats via le TF-IDF existant (le texte extrait est indexé). Ajouter un badge visuel « PDF » à côté du titre dans les résultats de recherche pour distinguer les PDFs des MD — utiliser l'icône file-text.
• F2. Snippets de recherche : Les extraits de contexte montrent le texte extrait du PDF avec surlignage des termes recherchés — fonctionnement identique aux MD via le mécanisme de snippet existant dans search.py.
• F3. Filtres de recherche avancés : Ajouter ext:pdf comme filtre pour limiter la recherche aux PDFs uniquement (complément aux filtres created:, modified:, size: déjà prévus #34).

G. Docker & Dépendances (0.5 jour)

• G1. requirements.txt : Ajouter pymupdf>=1.24.0 (sinon pypdf>=4.0 en fallback).
• G2. Dockerfile : Vérifier que l'image python:3.11-slim dispose des libs système nécessaires pour pymupdf. Si besoin, ajouter libmupdf-dev ou utiliser pypdf (pure Python) pour éviter la complexité. Recommandation : pypdf pour la simplicité Docker, pymupdf en option pour la performance.
• G3. Configuration : Ajouter OBSIGATE_PDF_MAX_SIZE_MB (défaut 50) pour limiter la taille des PDFs indexés et OBSIGATE_PDF_EXTRACT_TIMEOUT (défaut 30s).

H. Tests (1 jour)

• H1. Tests unitaires backend :
  • test_pdf_reader.py : extraction texte PDF simple, PDF vide, PDF avec uniquement des images (OCR non requis — retourne chaîne vide), PDF protégé par mot de passe, PDF corrompu, extraction métadonnées
  • Fixtures : créer un PDF de test minimal (2 pages, texte simple) via reportlab dans les fixtures de test
  • test_pdf_indexing.py : vérifier qu'un PDF dans un vault est correctement indexé, que le texte est recherchable, que index_document() gère l'extension .pdf
  • test_pdf_api.py : endpoint view retourne is_pdf: true, endpoint pdf/stream retourne application/pdf, endpoint pdf/info retourne les métadonnées
• H2. Tests frontend :
  • Test d'intégration : naviguer vers un fichier PDF → l'iframe est rendue
  • Test : fichier PDF dans les résultats de recherche
  • Test : téléchargement de PDF fonctionnel
• H3. CI : Ajouter la fixture PDF de test dans les artefacts de CI. Les tests PDF sont sautés si pymupdf/pypdf n'est pas disponible.

I. Documentation utilisateur (inclus dans l'effort)

• I1. Mettre à jour README.md : mentionner le support PDF dans les formats supportés
• I2. Ajouter une note dans la FAQ : « Comment visualiser un PDF dans ObsiGate ? »
• I3. Documenter les limitations : pas d'OCR (PDFs scannés non recherchables), pas d'annotation PDF, pas d'édition de PDF

J. Points d'attention / Risques

• Performance : Un PDF de 500 pages peut générer beaucoup de texte → SEARCH_CONTENT_LIMIT (100 Ko) limite l'indexation au début du document. Pour les PDFs volumineux, envisager une extraction paginée avec SEARCH_CONTENT_LIMIT réparti sur les N premières pages.
• Sécurité : Les PDFs malveillants (injections JS, liens externes) ne sont pas exécutés dans l'iframe par défaut (sandbox du navigateur). Ajouter sandbox="allow-same-origin" sur l'iframe pour renforcer.
• Mémoire : pymupdf charge le PDF entier en mémoire. Pour les très gros PDFs (>200 Mo), utiliser le streaming ou pypdf qui supporte la lecture paresseuse.
• Compatibilité navigateurs : Le rendu PDF natif fonctionne sur Chrome, Firefox, Edge, Safari. Safari iOS a des limitations sur les iframes PDF. Prévoir le fallback « ouvrir dans un nouvel onglet » pour ces cas.
• PDFs dans les vaults Obsidian : Obsidian Desktop ne gère pas nativement les PDFs (affichage via iframe système). ObsiGate apporte une valeur ajoutée en offrant la visualisation + recherche.

---

75. Éditeur multi-panneaux (Split View)

• Effort : 5-7 jours | Impact : 🟡
• Description : Système de panneaux divisés permettant d'afficher plusieurs documents côte à côte ou superposés, à la manière d'un éditeur de code (VS Code, Sublime Text). Drag & drop des onglets entre les panneaux, actions depuis le menu contextuel, et raccourcis clavier pour diviser/naviguer entre les panneaux. Le système remplace le content-area unique par un gestionnaire de panneaux (PaneManager) qui orchestre 1 à 4 zones d'affichage indépendantes, chacune avec sa propre barre d'onglets.
• Architecture actuelle :
  • DOM (frontend/index.html:885-896) : Un seul bloc .content-wrapper contenant .tab-bar + main.content-area#content-area. Le content-area est un conteneur monolithique dont le contenu est remplacé par renderFile() à chaque changement d'onglet.
  • TabManager (frontend/app.js:7988) : Gère déjà les onglets (ouvrir, fermer, preview, drag-reorder, menu contextuel). État stocké dans _tabs[], _tabCache{}, _activeTabId. Mais il est couplé au content-area unique — il remplace area.innerHTML à chaque activation.
  • Renderer : renderFile() (frontend/js/viewer.js:377) et renderFileContent() (frontend/app.js:3182) écrivent directement dans content-area via document.getElementById("content-area").
  • Déjà présent : Les onglets sont draggables dans la barre (réorganisation interne). Le drag & drop de fichiers depuis l'arborescence n'existe pas encore (#33).
• Sous-tâches :

A. PaneManager — Gestionnaire de panneaux (2-3 jours)

• A1. Classe PaneManager (frontend/js/pane-manager.js) : Nouveau module responsable de la grille de panneaux.
  • État : _panes: [] — tableau ordonné de {id, element, tabBar, tabList, contentArea, tabs: [], activeTabId, tabCache: {}, dirtyTabs: Set}
  • Pane actif : _activePaneId — le dernier panneau ayant reçu le focus
  • Disposition : _layout: 'horizontal' | 'vertical' | 'grid' — déterminé automatiquement selon le nombre et l'ordre de création
  • Maximum : 4 panneaux (grille 2×2) pour éviter la surcharge cognitive et les problèmes de performance
• A2. Création dynamique du DOM : Quand un 2e panneau est créé, le .content-wrapper est transformé :
  • Le .tab-bar et #content-area d'origine deviennent le pane #1
  • Un conteneur .pane-grid (flex/grid) englobe tous les panneaux
  • Chaque panneau a sa propre .pane-container > .tab-bar.pane-tab-bar + .content-area.pane-content
  • Une poignée de redimensionnement (.pane-resize-handle) est insérée entre chaque paire de panneaux
• A3. Redimensionnement (resize) : Implémentation native sans bibliothèque.
  • Mouse down sur .pane-resize-handle → capture du pointeur → calcul des ratios en pixels → mise à jour flex-basis en %
  • Double-clic sur la poignée → réinitialise à 50/50
  • Persistance des ratios dans localStorage par clé pane-layout-{N}panes
  • Contrainte : largeur/hauteur minimum de 200px par panneau
• A4. Indépendance des panneaux : Chaque panneau a son propre :
  • Jeu d'onglets (un fichier peut être ouvert dans plusieurs panneaux simultanément)
  • État de scroll, toggle source view, position du curseur
  • Cache de données (tabCache) — les données fetchées sont partagées via un cache global pour éviter les requêtes dupliquées
  • Barre d'outils viewer (copier, source, éditer, pop-out) rattachée au panneau actif

B. Refactoring du TabManager (1 jour)

• B1. Découplage du DOM global : Actuellement TabManager référence document.getElementById("content-area") et document.getElementById("tab-bar") en dur. Refactorer pour que chaque instance de Pane TabManager reçoive ses propres éléments DOM en paramètre.
• B2. Extraction de l'état : Le TabManager actuel est un objet singleton avec état mutable partagé. Le scoper dans une factory createTabManager(tabBar, tabList, contentArea) qui retourne une instance indépendante.
• B3. Compatibilité ascendante : Le pane #1 (unique par défaut) réutilise les IDs DOM existants (#tab-bar, #tab-list, #content-area) pour ne rien casser. Les panneaux additionnels créent des IDs suffixés (#tab-bar-2, #content-area-2, etc.).
• B4. Synchronisation avec le state global : currentVault, currentPath, syncActiveFileTreeItem() sont mis à jour depuis le panneau actif. Quand on switch de panneau (clic dans un panneau), le state global reflète le document affiché dans ce panneau.

C. Actions de division (1 jour)

• C1. Menu contextuel des onglets : Ajouter 3 actions au menu existant (_showTabContextMenu) :
  • « Diviser à droite » (splitRight) — crée un nouveau panneau à droite avec cet onglet, le ferme dans le panneau source
  • « Diviser en bas » (splitDown) — crée un nouveau panneau en dessous
  • « Déplacer vers... » (sous-menu) — liste les autres panneaux existants pour y déplacer l'onglet
• C2. Raccourcis clavier (non conflictuels avec le navigateur) :
  • Ctrl+Alt+\ → diviser le panneau actif à droite
  • Ctrl+Alt+Shift+\ → diviser le panneau actif en bas
  • Ctrl+Alt+←/→/↑/↓ → naviguer entre les panneaux (focus)
  • Ctrl+Alt+W → fermer le panneau actif (tous ses onglets sont fermés)
  • Ctrl+Shift+Alt+W → fermer tous les autres panneaux
• C3. Boutons dans la barre d'onglets : À droite de chaque .tab-bar, ajouter deux mini-boutons (visibles au survol) : « Split Right » (⊞→) et « Split Down » (⊞↓).
• C4. Fermeture d'un panneau : Si un panneau est fermé, ses onglets sont perdus (pas déplacés). Si c'est le dernier panneau → retour au mode panneau unique (le DOM redevient comme avant). Si le panneau actif est fermé → le focus passe au voisin le plus proche.

D. Drag & Drop (1 jour)

• D1. Drag d'onglet entre panneaux : Étendre le drag & drop existant des onglets.
  • dragstart : mémoriser le paneId source + tabId
  • dragover sur une .tab-bar d'un autre panneau : accepter le drop, afficher un indicateur
  • drop : retirer l'onglet du panneau source, l'ajouter au panneau destination, l'activer. Si c'était le dernier onglet du panneau source et que le panneau a été créé par split → fermer le panneau source (sinon le laisser vide)
  • dragend : nettoyer les indicateurs
• D2. Drag de fichier depuis l'arborescence (complément à #33) : Quand un fichier est dragué depuis le tree, au lieu de simplement l'ouvrir dans le panneau actif, permettre de le dropper :
  • Sur une .tab-bar d'un panneau spécifique → ouvre dans ce panneau
  • Sur une zone vide entre .pane-resize-handle → zone de drop fantôme qui crée un nouveau panneau
  • Sur l'espace après le dernier onglet → ouvre dans ce panneau (comportement par défaut)
• D3. Drag pour créer un panneau : Si l'onglet est dragué vers le bord droit ou inférieur du content-area actif, une zone de drop « glow » apparaît (comme VS Code). Dropper l'onglet sur cette zone crée un nouveau panneau avec cet onglet.

E. Rendu et performance (0.5 jour)

• E1. Indépendance du rendu : Chaque panneau appelle renderFile() dans son propre content-area. renderFile() est déjà conçu pour écrire dans le content-area global → nécessite un paramètre targetElement optionnel (défaut #content-area).
• E2. Cache de données partagé : Les données fetchées (/api/file/{vault}/view) sont mises en cache au niveau du PaneManager pour éviter de refetch le même fichier s'il est ouvert dans 2 panneaux différents. Invalidation du cache quand le fichier est sauvegardé.
• E3. Rendu paresseux : Seul le panneau actif fait le rendu complet. Les panneaux inactifs conservent leur DOM intact mais ne sont pas ré-actualisés tant qu'ils ne reçoivent pas le focus (sauf si le fichier a changé sur disque via watcher).
• E4. Gestion des éditeurs : Quand un fichier est en cours d'édition dans le panneau A, il est verrouillé en lecture dans le panneau B (badge « En édition ailleurs »). Pas d'édition simultanée du même fichier dans 2 panneaux (géré par le backend qui verrouille via ETag/If-Match — à implémenter dans #78).

F. CSS & Design (0.5 jour)

• F1. Grille de panneaux : CSS Grid pour la disposition.
  • 1 panneau : pas de grille (layout actuel)
  • 2 panneaux : grid-template-columns: 1fr 4px 1fr (horizontal) ou grid-template-rows: 1fr 4px 1fr (vertical)
  • 3 panneaux : disposition automatique (2 en haut, 1 en bas, ou l'inverse selon l'ordre de création)
  • 4 panneaux : grille 2×2
• F2. Poignées de redimensionnement : Style cohérent avec .sidebar-resize-handle existante.
  • 4px de large, fond var(--border), hover var(--accent) avec transition 150ms
  • Curseur col-resize ou row-resize selon l'orientation
  • Barre fine centrale de 2px en var(--accent) au survol
• F3. Barre d'onglets par panneau : Style identique à la barre d'onglets actuelle.
  • Onglet actif avec accent-color de fond + border-bottom
  • Badge « panneau actif » discret : bordure gauche de 2px en var(--accent) sur tout le panneau
• F4. Thème sombre/clair : Toutes les nouvelles classes CSS utilisent les variables CSS existantes → compatibilité automatique avec le toggle de thème.
• F5. Responsive / Mobile : Le split view est désactivé en dessous de 768px. Sur mobile, comportement actuel inchangé (panneau unique, toolbar bottom). Un message dans les paramètres : « Le mode multi-panneaux est disponible sur les écrans larges (≥ 768px) ».

G. Persistance et restauration (0.5 jour)

• G1. Sauvegarde de la disposition : Dans localStorage sous la clé obsigate-panes :

  {
    "layout": "horizontal",
    "panes": [
      {"id": "pane-1", "tabs": ["vaultA::doc1.md", "vaultA::doc2.md"], "activeTab": "vaultA::doc1.md", "width": "50%"},
      {"id": "pane-2", "tabs": ["vaultB::readme.md"], "activeTab": "vaultB::readme.md", "width": "50%"}
    ]
  }
  

• G2. Restauration au chargement : Au démarrage, si obsigate-panes existe → restaurer la disposition. Les onglets sont rouverts (fetchés). Si un fichier n'existe plus → l'onglet est ignoré avec un log warning.
• G3. Reset : Option dans les paramètres : « Réinitialiser la disposition des panneaux » → supprime obsigate-panes du localStorage, retour au mode panneau unique.

H. Compatibilité avec les fonctionnalités existantes (0.5 jour)

• H1. Palette de commandes (#31) : Ajouter les commandes « Split Right », « Split Down », « Focus Next Pane », « Focus Previous Pane », « Close Pane », « Close Other Panes ».
• H2. Pop-out (#??) : Le bouton pop-out ouvre le document dans une popup séparée (comportement existant). Pas de split view dans la popup (fenêtre indépendante).
• H3. Mermaid Live Preview (#50) : La preview Mermaid est locale au panneau actif. Chaque panneau a sa propre preview (gérée par mermaid-viewer.js déjà scoped au content-area).
• H4. AI Editor (#26-29) : L'éditeur AI s'ouvre dans une modale plein écran (inchangé). Pas d'édition multi-panneau dans l'éditeur.
• H5. Backup & sauvegarde : Ctrl+S sauvegarde le document du panneau actif uniquement (pas de sauvegarde globale). Chaque panneau gère son propre dirty state.

I. Tests (1 jour)

• I1. Tests unitaires PaneManager : Création de panneaux, split right/down, fermeture, redimensionnement, navigation entre panneaux, drag & drop d'onglets entre panneaux.
• I2. Tests d'intégration frontend :
  • Ouvrir 2 fichiers → split right → vérifier que chaque panneau a le bon contenu
  • Drag d'un onglet du pane 1 vers le pane 2 → vérifier le transfert
  • Split down → vérifier la disposition verticale
  • Fermer un panneau → vérifier que l'autre panneau reprend tout l'espace
  • Redimensionner → vérifier la persistance du ratio
• I3. Tests E2E (Playwright, #58) :
  • Test : split right → 2 panneaux visibles
  • Test : drag tab entre panneaux
  • Test : raccourci clavier Ctrl+Alt+\
  • Test : restauration de la disposition au rechargement
• I4. Tests de régression : Vérifier que le comportement en mode panneau unique (par défaut) est strictement identique au comportement actuel — même DOM, mêmes IDs, mêmes événements.

J. Points d'attention / Risques

• Complexité du DOM : Passer d'un content-area unique à un système multi-panneau est le changement architectural le plus profond depuis le refactoring en modules ES — toucher à renderFile(), TabManager, et tous les appels à document.getElementById("content-area") disséminés dans le code.
• Performance mémoire : 4 panneaux × 10 onglets × contenu HTML = potentiellement lourd. Implémenter le lazy rendering (seul le panneau actif a son DOM dans le document, les autres sont masqués via display: none ou content-visibility: auto).
• Mobile : Le split view n'a pas de sens sur mobile → désactivé. Mais le code doit gérer la transition si l'utilisateur bascule en mode desktop (ex: tablette en paysage).
• État global vs local : currentVault et currentPath sont utilisés par de nombreuses fonctions (recherche, sidebar, breadcrumb). Le passage au panneau actif doit mettre à jour ces variables de manière fiable — un bug ici casserait la navigation.
• Backup avant split : Avant la première activation du mode multi-panneau, sauvegarder la disposition actuelle pour pouvoir revenir en arrière en cas de bug.

---

76. BooksLM — Console AI contextuelle par répertoire (style NotebookLM)

• Effort : 5-6 jours | Impact : 🟡
• Description : Console de chat AI contextuelle accessible via le menu contextuel des répertoires dans l'arborescence. Au clic sur « BooksLM », un panneau de chat s'ouvre à droite du viewer et indexe automatiquement toutes les ressources markdown (et PDF via #74) du répertoire courant et de ses sous-répertoires récursivement comme contexte pour un assistant AI. L'assistant peut répondre à des questions, résumer, synthétiser, et croiser l'information à travers tous les documents du scope — exactement comme NotebookLM de Google, mais pour n'importe quel répertoire de votre vault Obsidian.
• Fonctionnement général :
  • L'utilisateur fait un clic-droit sur un répertoire dans l'arborescence → option « BooksLM »
  • Un panneau latéral (450-500px) s'ouvre à droite, poussant le viewer existant
  • Le backend collecte tous les fichiers .md (et .pdf si #74 est complété) récursivement
  • Le contenu est assemblé en un contexte système pour le LLM (fenêtre de contexte optimisée)
  • L'utilisateur peut chatter avec l'AI qui a une connaissance complète du répertoire
  • L'historique de chat est optionnellement sauvegardé (localStorage ou fichier .books-lm.json dans le répertoire)
• Sous-tâches :

A. Backend — Collecte et préparation du contexte (1.5-2 jours)

• A1. Nouvel endpoint POST /api/ai/bookslm/context : Reçoit {vault, directory} → parcourt récursivement le répertoire → lit tous les fichiers supportés → retourne un objet {files: [{path, title, content, type: "md"|"pdf"}], total_chars, file_count, directory_tree}
• A2. Limites configurables : BOOKSLM_MAX_FILES (défaut 200), BOOKSLM_MAX_TOTAL_CHARS (défaut 200 000), BOOKSLM_MAX_FILE_CHARS (défaut 30 000 par fichier). Les fichiers au-delà sont tronqués avec un message [... continue dans le fichier].
• A3. Filtrage intelligent : Ignorer les fichiers cachés (. préfixe), les dossiers _attachments/, les fichiers binaires non-supportés. Respecter .gitignore ou .obsigate-ignore si présent.
• A4. Streaming du contexte : Pour les très gros répertoires, l'endpoint supporte le streaming SSE pour informer l'UI de la progression (« Indexation de 45/127 fichiers... »).

B. Backend — Endpoint chat BooksLM (1 jour)

• B1. Endpoint POST /api/ai/bookslm/chat : Reçoit {vault, directory, message, conversation_history: [{role, content}]} → construit le contexte système à partir des fichiers du répertoire → appelle le provider AI configuré → stream la réponse via SSE.
• B2. Prompt système : Template par défaut optimisé : « Tu es un assistant de recherche qui aide à comprendre et analyser les documents d'un répertoire. Voici le contenu de tous les documents disponibles. Réponds en te basant UNIQUEMENT sur ces documents. Cite tes sources avec le nom du fichier. Si l'information n'est pas dans les documents, dis-le clairement. »
• B3. Mode « Sources » : Chaque réponse inclut les fichiers référencés (détectés via mention de titre ou contenu). L'UI affiche des badges de source cliquables.
• B4. Mise en cache du contexte : Le contexte du répertoire est caché en mémoire (hash du contenu) pour éviter de re-parser tous les fichiers à chaque message. Invalidé si un fichier est modifié (watcher).
• B5. Provider : Utilise la même abstraction provider que l'AI Editor (#27) — DeepSeek, OpenRouter, Gemini. Ajouter BOOKSLM_DEFAULT_MODEL dans .env (défaut : DEEPSEEK_MODEL).

C. Frontend — Panneau de chat BooksLM (2 jours)

• C1. Module frontend/js/bookslm.js : Nouveau module ES avec la classe BooksLM :
  • Gère l'état : _isOpen, _currentDirectory, _messages[], _contextFiles[], _isLoading
  • Crée le DOM du panneau : conteneur latéral .bookslm-panel (450px, redimensionnable via poignée)
  • Header : titre « BooksLM », nom du répertoire courant, bouton fermer, bouton « Nouvelle conversation »
  • Zone de messages : scrollable, bulles utilisateur (droite) et assistant (gauche) avec Markdown rendu
  • Zone d'entrée : textarea avec Ctrl+Enter pour envoyer, bouton envoyer
  • Barre d'état : nombre de fichiers indexés, nombre total de caractères
• C2. Intégration au menu contextuel : Dans frontend/js/context-menu.js, ajouter l'option « 🧠 BooksLM » pour les nœuds de type directory dans l'arborescence. Visible seulement si le vault est accessible.
• C3. Rendu Markdown dans le chat : Utiliser le renderer Markdown existant (ou un sous-ensemble simplifié) pour afficher les réponses de l'AI avec support du gras, italique, code, listes, et tableaux.
• C4. Streaming des réponses : Connexion SSE pour afficher la réponse de l'AI token par token (effet « typing » naturel).
• C5. Badges de sources : Après chaque réponse, afficher les fichiers sources mentionnés sous forme de badges cliquables qui ouvrent le fichier dans le viewer principal.
• C6. Mode plein écran : Bouton pour basculer en mode plein écran (cache la sidebar, le panneau prend tout l'espace). Utile pour les sessions de recherche intense.

D. Frontend — Actions et UX (0.5-1 jour)

• D1. Copier la réponse : Bouton copie sur chaque message assistant.
• D2. Régénérer : Bouton pour régénérer la dernière réponse (utile si la réponse est hors-sujet).
• D3. Exporter la conversation : Bouton pour exporter l'historique en Markdown → sauvegarder comme note dans le répertoire courant.
• D4. Historique des conversations : Stockage dans localStorage par clé bookslm-history-{vault}-{directory}. Liste déroulante dans le header pour charger une conversation précédente.
• D5. Indicateur de contexte : Barre de progression montrant l'utilisation du contexte (% de la limite BOOKSLM_MAX_TOTAL_CHARS). Si le répertoire est trop gros, suggérer de réduire le scope.
• D6. Suggestions de questions : Après l'indexation, afficher 3 questions suggérées basées sur les titres et métadonnées des fichiers (« Résume ce répertoire », « Quels sont les thèmes principaux ? », « Y a-t-il des contradictions entre ces documents ? »).

E. CSS & Design (0.5 jour)

• E1. Panneau latéral : Animation slide-in depuis la droite (300ms ease-out). Ombre portée pour séparation visuelle.
• E2. Poignée de redimensionnement : Similaire à .sidebar-resize-handle, curseur col-resize, largeur min 350px, max 800px. Persistance dans localStorage.
• E3. Bulles de chat : Style cohérent avec le thème actuel. Messages utilisateur avec accent-color, messages assistant avec fond var(--surface2).
• E4. Responsive : Sur mobile (<768px), le panneau passe en plein écran (pas de split view). Navigation par swipe pour revenir au viewer.
• E5. Thème sombre/clair : Toutes les variables CSS utilisent les customs properties existantes → compatibilité automatique.

F. Intégration et compatibilité (0.5 jour)

• F1. Compatibilité Split View (#75) : Si le split view est actif, BooksLM s'ouvre en remplacement du panneau le plus à droite (ou en 3e colonne). Le panneau BooksLM est traité comme un type spécial de pane dans le PaneManager.
• F2. Compatibilité AI Editor (#26-29) : BooksLM utilise le même système de provider AI. Les clés API configurées pour l'AI Editor fonctionnent pour BooksLM.
• F3. Compatibilité PDF (#74) : Si le support PDF est implémenté, les PDFs dans le répertoire sont inclus dans le contexte (texte extrait).
• F4. Palette de commandes (#31) : Ajouter les commandes « BooksLM: Ouvrir pour le répertoire courant » et « BooksLM: Nouvelle conversation ».

G. Tests (1 jour)

• G1. Tests unitaires backend :
  • test_bookslm_context.py : collecte récursive, respect des limites, filtrage fichiers cachés, streaming SSE
  • test_bookslm_chat.py : construction du prompt, caching du contexte, invalidation après modification
• G2. Tests d'intégration frontend :
  • Ouverture du panneau BooksLM depuis le menu contextuel
  • Envoi d'un message et affichage de la réponse
  • Badges de sources cliquables
  • Export de conversation
  • Redimensionnement du panneau
• G3. Tests E2E (Playwright, #58) :
  • Test : clic-droit sur répertoire → BooksLM → panneau visible
  • Test : chat fonctionnel → message envoyé → réponse reçue
  • Test : fermeture et réouverture → historique restauré

H. Points d'attention / Risques

• Taille du contexte : Un répertoire avec 500 fichiers markdown peut facilement dépasser 1M de caractères → essentiel de tronquer intelligemment (préférer les fichiers modifiés récemment, ou prioriser selon la structure : README.md, index.md en premier).
• Coût API : Chaque message envoie le contexte complet au LLM → potentiellement coûteux en tokens. Ajouter un avertissement si le contexte dépasse 100K tokens estimés.
• Performance : La collecte récursive de 200+ fichiers peut prendre plusieurs secondes → l'UI doit montrer la progression (streaming SSE) et le backend doit être non-bloquant (background task).
• Sécurité : Ne pas envoyer les fichiers ignorés (.env, .git/, .hermes/, tokens, secrets) dans le contexte. Le secret_redactor.py existant (#16) doit être appliqué au contenu avant envoi au LLM.
• Privacy : Si le provider AI est externe (OpenRouter, DeepSeek, Gemini), le contenu des fichiers est envoyé à un tiers → warning dans l'UI avec option d'activer/désactiver par vault.
• Scope répertoire : Ne PAS inclure les fichiers hors du répertoire (pas de remontée au parent ou de traversée de vault). Le scope est strictement le répertoire + sous-répertoires.

---

⚪ Backlog — Priorité 4 (P4)

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.
• Sous-tâches :
  • Souscription Push : endpoint POST /api/push/subscribe (stockage subscription + vault)
  • Envoi : webhook interne on_file_change → dispatch notification via Web Push
  • Configuration VAPID : clés publique/privée dans config.json
  • UI : permission navigateur + toggle activer/désactiver par vault
  • Payload : titre du fichier, vault, action (created/modified/deleted)
  • Clic sur notification → ouvre le fichier dans ObsiGate

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.
• 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)
  • Métriques uptime : time.time() - server_start_time
  • Métriques backups : nombre total, âge du plus vieux, espace disque
  • Format réponse JSON structuré : { status, uptime, index, memory, backups, connections }
  • Endpoint séparé GET /api/health/detailed (protégé admin)

69. Éditeur mobile natif — Interface tactile optimisée

• Effort : 2-3 jours | Impact : 🟢
• Description : Refonte de l'expérience mobile pour l'édition : barre d'outils contextuelle, presse-papiers optimisé, gestes tactiles (swipe pour actions rapides), mode lecture plein écran.
• Sous-tâches :
  • Barre d'outils mobile flottante : bold, italic, code, liste, lien (inspirée de l'éditeur Obsidian mobile)
  • Raccourcis swipe : gauche → backlinks, droite → table des matières
  • Mode lecture : cache sidebar + header, plein écran, swipe horizontal pour page suivante
  • Presse-papiers : bouton « Coller » persistant (iOS contourne restriction clipboard)
  • Adaptation CodeMirror : hauteur ajustable, police agrandissable (pinch zoom)

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.
• 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)
  • Indexation : embedding par chunk de 512 tokens avec recouvrement
  • Recherche hybride : combinaison TF-IDF + similarité cosinus (RRF — Reciprocal Rank Fusion)
  • UI : toggle « Recherche sémantique » dans la barre de recherche
  • UI : score de similarité dans les résultats

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.
• 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
  • Logs d'audit : visualisation des 500 dernières entrées, filtre par utilisateur/action/date
  • Backup stats : graphique d'évolution (taille totale, nombre par vault, âge moyen)
  • Protection : accès restreint au rôle admin uniquement

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.
• 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)
  • Exemples dans les schémas : examples=[...] pour les endpoints clés
  • Tagging des endpoints par catégorie (Files, Vaults, Search, Auth, AI, Backups)
  • Serveur mock : prism ou openapi-generator pour tests sans backend
  • Page de documentation intégrée : lien dans le menu header (« API »)

73. Synchronisation multi-appareils — Obsidian Sync compatible

• Effort : 6-8 jours | Impact : 🟢
• Description : Synchronisation des vaults entre plusieurs instances d'ObsiGate via un protocole de synchronisation décentralisé ou compatible Obsidian Sync. Alternative self-hosted à Obsidian Sync.
• Sous-tâches :
  • Protocole : évaluation CRDT vs OT vs diff/patch pour fichiers markdown
  • Transport : WebSocket ou polling HTTPS avec compression
  • Merge strategy : LWW (Last Writer Wins) avec historique des deux versions
  • Détection de changements : hash SHA-256 par fichier, journal des modifications
  • UI : page « Synchronisation » avec statut par appareil, historique des syncs
  • Conflits : UI de résolution manuelle (diff côte à côte entre version locale et distante)
  • Chiffrement : optionnel, chiffrement AES-256-GCM avant transmission
  • Pairing : échange de clé publique + code QR pour appairage des appareils

---

📊 Résumé des efforts

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
⚪ P4	#67 → #73 (7 items)	18-23 jours
Total restant	19 items	54-71 jours

---

Notes

• Les items P3/P4 ne sont pas ordonnés par priorité interne — à raffiner selon les retours utilisateurs.
• L'effort inclut le développement + tests unitaires + intégration CI, mais pas la documentation utilisateur.
• Les items marqués 🟢 (nice-to-have) sont de bons candidats pour des contributions externes.
• Le mode hors-ligne (#59) et l'i18n (#63) sont les P3 ayant le meilleur rapport effort/valeur.