Add roadmap items for PDF support and split view editor

ROADMAP.md

@@ -233,6 +233,229 @@
   - [ ] 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` :
+    ```json
+    {
+      "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.
+
 ---
 
 ## ⚪ Backlog — Priorité 4 (P4)
@@ -322,9 +545,9 @@
 |---|---|---|
 | ✅ Complété | #1 → #57 | ~65 jours |
 | 🔵 P1 | #58 (Playwright) | 2-3 jours |
-| ⚪ P3 | #59 → #66 (8 items) | 20-27 jours |
+| ⚪ P3 | #59 → #66, #74, #75 (10 items) | 29-39 jours |
 | ⚪ P4 | #67 → #73 (7 items) | 18-23 jours |
-| **Total restant** | **16 items** | **40-53 jours** |
+| **Total restant** | **18 items** | **49-65 jours** |
 
 ---