g9-migration/PROJET-SECOND-CERVEAU.md

# Projet — Second Cerveau & Inventaire des Données Numériques

**Date** : 05/10/2026
**Auteur** : Jean-Henry Foltzenlogel (Folzo)
**Réseau** : `192.168.1.0/24`
**Statut global** : 🟡 **Cahier des charges rédigé** — réflexion terminée, architecture cible posée. **Aucune implémentation** : l'infra est en pleine (re)création (`DOSSIER-RECREATION.md` v2) et ce projet démarre **après** les fondations.
**Document** : **vivant** — versionné, mis à jour à chaque étape. Chaque section porte son statut (✅ / 🟡 / ⬜).

> **Nature du document** : c'est le **cahier des charges + plan** du projet « Second Cerveau & Inventaire ». Il succède à la réflexion de l'échange du 05/10/2026. Il **ne duplique pas** les specs hardware (→ snapshot `ETAT-DE-LART-2026-09-30.md`) ni l'architecture d'infra (→ `DOSSIER-RECREATION.md` v2). En cas de conflit sur un fait matériel, c'est le **snapshot** qui fait foi ; pour l'architecture d'infra, c'est **`DOSSIER-RECREATION.md`** ; pour **ce projet** (second cerveau, inventaire, analyse de valeur), c'est **ce document** qui fait foi.

---

## Sommaire

- [Résumé exécutif](#résumé-exécutif)
- [S1 — Besoin & périmètre](#s1--besoin--périmètre)
- [S2 — Les 9 exigences du second cerveau](#s2--les-9-exigences-du-second-cerveau)
- [S3 — Sources réelles](#s3--sources-réelles)
- [S4 — Architecture](#s4--architecture)
- [S5 — MVP (Second Cerveau Tier A de bout en bout)](#s5--mvp-second-cerveau-tier-a-de-bout-en-bout)
- [S6 — Roadmap & phases](#s6--roadmap--phases)
- [S7 — Décisions ouvertes](#s7--décisions-ouvertes)
- [S8 — Risques](#s8--risques)
- [S9 — Lien avec l'infrastructure](#s9--lien-avec-linfrastructure)
- [S10 — Montée en compétence](#s10--montée-en-compétence)
- [Annexe A — Critères d'acceptance](#annexe-a--critères-dacceptance)
- [Annexe B — Glossaire](#annexe-b--glossaire)
- [Changelog](#changelog)

---

## Résumé exécutif

**Le problème** : ma donnée numérique est **dispersée** (plusieurs machines, protocoles, 50 To+), et surtout ma **connaissance** (notes, écrits IA, mails, fichiers précieux) est **éparpillée et oubliable** — chaque IA (OpenFox, OpenCode, Hermes) a sa propre mémoire, oublie ce qu'on lui a dit, et on se répète.

**La vision** : un **second cerveau de famille** — une mémoire **partagée, versionnée, lisible par l'humain et puisée d'elle-même par l'IA** — plus un **inventaire** du reste (où est quoi, doublons, corruption) pour prendre conscience de l'ensemble de la donnée.

**La décision clé** : le second cerveau n'est **ni** un outil de notes, **ni** un RAG opaque. C'est un **modèle à deux couches** :

| Couche | Nature | Consommateur |
|--------|--------|--------------|
| **1 — La connaissance** | Fichiers **Markdown**, versionnés git | **Toi** (Obsidian) + source de vérité |
| **2 — L'index** | Embeddings + index vectoriel (**cache jetable**) | **L'IA** (recherche rapide via MCP) |

> **Principe fondateur** : **la couche 1 est la vérité, la couche 2 est jetable** (reconstruisible à tout moment depuis la couche 1). Un seul artefact de connaissance (le vault md), deux consommateurs (toi + l'IA). C'est ce qui découple le **besoin** de l'**outil** et garantit de ne pas changer dans 5 mois.

**Le périmètre se scinde en deux tiers** :

| | **Tier A — le cœur** (analyse IA profonde) | **Tier B — le bulk** (analyse cheap, sans IA) |
|---|---|---|
| **Contenu** | ~10 Go fichiers précieux + **mails** + **notes** + **écrits IA** | Photos, films, archives, le reste |
| **Traitement** | LLM profond → fiches md structurées + index vectoriel | Pass 1 seul : métadonnées, doublons, corruption |
| **Volume** | Petit, borné | Tens de To |
| **Valeur** | **C'est ici que réside l'intérêt** | Juste savoir où est quoi / doublons / corrompu |

**Le succès** (mesurable) : poser une question naturelle à l'IA sur mes données et obtenir une réponse précise avec références (machine + chemin) ; l'IA **récupère d'elle-même** le contexte quand un sujet revient ; la famille (femme, enfants) bénéficie de la même aide, **automatisée et non intrusive**, en alternative souveraine aux GAFAM et aux IA cloud.

---

## S1 — Besoin & périmètre

> **Statut** : ✅ Validé (05/10/2026)

### 1.1 Le besoin

**Objectif principal** : prendre conscience de l'ensemble de ma donnée numérique dispersée, identifier la **valeur** de chaque donnée (et du corpus global), et faire de ma **connaissance** un actif **navigable** — par moi et par l'IA.

**Ce que l'utilisateur veut en fin de compte** :
- **Une vue d'ensemble** : où est quoi, combien, en double, en déshérence, corrompu.
- **Une évaluation de valeur** : ce qui est précieux, sensible, obsolète, dupliqué.
- **Un second cerveau** : un index consultable par un LLM local, pour qu'une IA puisse **se repérer d'elle-même** dans l'ensemble de mes données (recherche sémantique, notes, références précises) **sans que je réexplique**.
- **Une assistante quotidienne** : « ma petite assistante Effi » qui m'aide au quotidien sur n'importe quel sujet, en puisant dans le cerveau + l'inventaire.
- **Un outil de famille** : utilisable par ma femme (surtout mails / organisation) et mes enfants, **automatisé et non intrusif**, en **alternative souveraine** aux GAFAM et aux IA cloud (ChatGPT, Claude) qui ciblent la jeune génération.

### 1.2 Périmètre & contraintes

- **Périmètre** : plusieurs machines/serveurs (PC, NAS, serveurs) sur le réseau local ; protocoles multiples (SMB, SSH/SFTP, local, WebDAV) ; tous types de fichiers.
- **Volume réel inconnu** (c'est le but de l'inventaire) — estimé ~50 To+ (voir S3).
- **100% local / auto-hébergé** : aucune donnée ne quitte la maison (données personnelles, sensibles).
- **IA locale** (Ollama / llama.cpp sur PC IA) — pas d'API cloud.
- **Économique en temps** : approche par **passes / entonnoir** (le moins cher d'abord).
- **Incrémental** : l'inventaire se maintient dans le temps (re-scan des seuls nouveaux/modifiés).

### 1.3 Le reframe Tier A / Tier B (décision clé de périmètre)

> Le périmètre n'est **pas** « analyser 50 To ». C'est **deux choses distinctes** :

| | **Tier A — le cœur** | **Tier B — le bulk** |
|---|---|---|
| **Contenu** | ~10 Go fichiers précieux (Google Drive + Synology) + **mails** + **notes** + **écrits IA** (OpenFox, OpenCode, Hermes) | Photos, films, archives, le reste |
| **Traitement** | **LLM profond** → fiche structurée (résumé, valeur, sensibilité, tags) + index vectoriel | **Pass 1 seul** : métadonnées, doublons, corruption. **Zéro IA.** |
| **Volume** | Petit, borné | Tens de To |
| **Valeur** | **C'est ici que réside l'intérêt principal** | Juste savoir où est quoi / doublons / corrompu |

**Conséquence majeure** : le coût IA devient **trivial**. L'analyse profonde ne touche que ~10 Go + mails + notes + écrits — très tractable sur 2× RTX 3060. Les 50 To ne touchent **que** le Pass 1 (mécanique, pas cher). L'entonnoir fonctionne : son extrémité étroite (IA profonde) est **petite et curée**, pas « 5% de 10M fichiers ».

> **Le vrai nom de la valeur** : ce n'est pas juste un « inventaire ». C'est un **index de connaissance personnelle** — rendre ma pensée, mes projets, mes écrits (surtout l'historique IA, trace de tout ce que j'ai fait) **navigables et interrogeables** par un LLM. C'est un **second cerveau**, pas un catalogue de disques.

### 1.4 Ce que l'utilisateur ne veut PAS

- **Pas** d'Immich (désorganise les fichiers) → penche pour **Moments + Nextcloud** (→ S6 Phase 4, Outillage).
- **Pas** de déplacement des données brutes : le projet **produit** des notes/fiches, il ne déplace pas les sources.
- **Pas** de suppression / dédoublonnage d'actions au MVP : **lecture seule**, identification uniquement.
- **Pas** de nouveau stack RAG : s'appuyer sur les briques existantes (voir S9).

---

## S2 — Les 9 exigences du second cerveau

> **Statut** : ✅ Validé (05/10/2026) — **cœur du document**. Ce tableau est le **cahier des charges** du second cerveau. La **Phase 4 (Outillage, S6)** n'aura qu'à le cocher outil par outil.

> **Principe** : les **besoins** (ce qu'il doit faire) sont découplés des **outils** (avec quoi). Le modèle 2 couches (S4) est **outil-agnostique** : il ne dit ni Gitea ni Nextcloud ni Obsidian. On pourra changer de host, d'éditeur, de vector DB **sans toucher au contenu** (markdown universel + index reconstruisible).

| # | Exigence | Ce que ça veut dire concrètement |
|---|----------|-----------------------------------|
| 1 | **Persistance cross-harnais** | Ce qui est dit avec OpenFox doit être lisible par OpenCode et Hermes. Une mémoire **partagée**, pas 3 silos. |
| 2 | **Récupération autonome** | L'IA sait *qu'elle doit* chercher et le fait *d'elle-même* quand le sujet revient. Pas « l'utilisateur colle le contexte ». |
| 3 | **Lisible + éditable par l'humain** | Tu peux ouvrir, lire, éditer, lier. Pas une boîte noire. |
| 4 | **Versionné / non destructif** | Historique, pas de perte, on revient en arrière. |
| 5 | **Structuré et navigable** | Organisé (liens, tags, arborescence), pas un tas. |
| 6 | **Scalable à une vie + la famille** | De quelques Mo aujourd'hui à des dizaines de Go, et **partitionnable par personne** plus tard (moi, femme, enfants). |
| 7 | **100% local / souverain** | Rien ne quitte la maison. |
| 8 | **Rapide pour l'IA** | Recherche sémantique instantanée, pas un grep sur 10 Go. |
| 9 | **Ingestion ouverte** | N'importe quelle source (fichiers, mails, notes, sessions IA, futurs) peut **alimenter** le cerveau. Système ouvert. |

**Ces 9 lignes sont le cahier des charges du second cerveau.** C'est ce qui rend le choix des outils (S6 Phase 4) définitif et évite de « changer dans 5 mois ».

---

## S3 — Sources réelles

> **Statut** : 🟡 **Partiellement vérifié** — les sources Tier A du PC IA sont localisées (05/10/2026, via SSH `jeuxpc`). Les écrits IA sur `effi-server` sont **à localiser** (pas de clé SSH depuis l'environnement de rédaction).

### 3.1 Sources Tier A (analyse IA profonde)

| Source | Emplacement | Nature / taille | Statut |
|--------|-------------|-----------------|--------|
| **Fichiers précieux** | Google Drive → copie chaude sur NAS (Cloud Sync Synology) → **SMB** | ~10 Go | ✅ localisé (SMB) |
| **Fichiers précieux** | Synology (xpenology / G9) | ~10 Go | ✅ localisé (SMB) |
| **Mails** | **Gmail** + **Hotmail** (20-30 ans) via **Thunderbird** sur PC | 2 boîtes, volumineux | ✅ localisé (Thunderbird) — **point difficile** (dégafamisation vs attachement) |
| **Notes** | `~/Documents/Notes/CAS IA` (PC IA) + Joplin (`~/Documents/Joplin/`) | md | ✅ localisé (PC IA) |
| **Écrits IA — OpenCode sessions** | `~/.local/share/opencode/opencode.db` (PC IA) | **SQLite, 218 Mo** | ✅ localisé — **extracteur dédié requis** |
| **Écrits IA — OpenCode projets** | `~/Documents/OpenCode/Projets` (PC IA) | git repo | ✅ localisé |
| **Écrits IA — OpenFox** | `effi-server` (J5040, .1) | à localiser | ⚠️ **à vérifier** |
| **Écrits IA — Hermes** | `effi-server` (J5040, .1) | à localiser | ⚠️ **à vérifier** |

> **Note OpenCode** : les sessions sont dans un **SQLite** (`opencode.db`, 218 Mo), pas des fichiers texte. Un **extracteur dédié** (ou l'API OpenCode) est requis pour les rendre indexables. C'est une brique du MVP (C1.1).

### 3.2 Sources Tier B (analyse cheap, sans IA)

| Source | Emplacement | Contenu |
|--------|-------------|---------|
| **Photos** | xpenology (USB1 15 To, USB2 5,5 To), 218play, Laptop | Photos famille (dont 2008 sur disque USB HS) |
| **Films / séries** | xpenology, 218play, Laptop | Médias |
| **Archives** | divers | Dumps, ISO, backups |
| **Le reste** | G9 (RAID1 2 To + USB 20 To), Laptop (2 To + 1 To), Freebox (2 To RAID5) | Divers |

> **Volume estimé total** : ~50 To+ (USB1 15 To + USB2 5,5 To + USB3 3,6 To + 218play 4 To + Freebox 2 To + Laptop 3 To + G9 20 To). **À re-dimensionner précisément en Phase 0** (C0.1).

### 3.3 Sources exclues / hors périmètre

- **Disque USB 3,6 To HS** (xpenology, secteurs défectueux) : hors périmètre — l'utilisateur a **218play** + un **disque 4 To 3,5" retrouvé** (à brancher sur le PC IA) comme copies. Voir snapshot `ETAT-DE-LART-2026-10-06.md` §2.
- **NVR Reolink** (surveillance) : hors périmètre (enregistreurs autonomes).

---

## S4 — Architecture

> **Statut** : ✅ Validé (05/10/2026) — modèle 2 couches + découpage des rôles + mécanisme MCP.

### 4.1 Le modèle 2 couches (colonne vertébrale)

```
┌─────────────────────────────────────────────────────────┐
│  COUCHE 1 — LA CONNAISSANCE (source de vérité)            │
│  Fichiers Markdown, lisibles, versionnés git              │
│  = le vault                                               │
│  → TOI tu lis/édites ici (Obsidian)                       │
├─────────────────────────────────────────────────────────┤
│  COUCHE 2 — L'INDEX (dérivé, JETABLE)                     │
│  Embeddings + index vectoriel (sqlite-vec / Qdrant)       │
│  → L'IA recherche ici (rapidité, via MCP)                 │
│  → se RECONSTRUIT à tout moment depuis la couche 1        │
└─────────────────────────────────────────────────────────┘
```

**Le principe qui débloque tout** : **la couche 1 est la vérité, la couche 2 est jetable.**
- La connaissance = des **fichiers Markdown dans un repo git** : à la fois le vault (tu lis, édites, liens `[[wikilinks]]`) **et** la source que l'IA indexe. **Un seul artefact, deux consommateurs.**
- L'index vectoriel n'est qu'un **cache**. S'il est corrompu/obsolète → on le **reconstruit** depuis les md. Il n'est **jamais** la source de vérité.
- Ça élimine le dilemme « rapide pour l'IA **ou** consultable par moi » : c'est rapide **et** consultable, parce que la vitesse vient de l'index et la vérité vient des md.

### 4.2 Pourquoi pas « juste RAG » ni « juste Obsidian »

- **Pas un RAG pur** (chunking + embeddings seul) : tu ne peux **pas le lire**. Tes données précieuses sont de la **connaissance que tu veux aussi relire et faire vivre**, pas juste « interroger ». Un RAG opaque, tu ne peux pas l'éditer, le lier, le versionner. Les md, si.
- **Pas « juste Obsidian, sans index »** : sur un corpus qui grandit, la recherche sémantique (« où est-ce que j'ai parlé de X ? ») devient lente/floue en plein texte. L'index vectoriel rend la consultation LLM **rapide et fiable** (exigence #8).

### 4.3 Le découpage des rôles (outil-agnostique)

> Le second cerveau n'est **ni** Gitea, **ni** Obsidian, **ni** Nextcloud Notes. C'est **les fichiers markdown + l'index**. Les outils sont juste des **rôles** autour :

| Rôle | Exigences servies | Candidate(s) | Note |
|------|-------------------|--------------|------|
| **Store** (la vérité) | 1,3,4,5,6,7 | **Repo git de markdown** | Gitea = *host canonique* du repo. Le store = les fichiers, **pas** Gitea. |
| **Viewer / éditeur** | 3 | **Obsidian** (pointe sur le dossier md) | C'est un *front-end*, **pas** le store. |
| **Index + retrieval** | 2,8 | embeddings + sqlite-vec / Qdrant + **MCP** | Le cache jetable. |
| **Ingestion** | 9 | extracteurs (OpenCode.db, mails, notes, fichiers) | Les portes d'entrée. |

**Réponses aux doutes** :
- **Gitea** : bon choix pour le **versioning** (host du repo) ; apprendre git rentre dans le pilier « monter en compétence ». Mais ne pas le sur-vendre : Gitea est juste *où le repo vit*. Le cerveau, c'est les md. Si on change de host, les md ne bougent pas.
- **Nextcloud Notes** : c'est une **app de notes simple**, pas un store de connaissance. Il ne fait **pas** le versioning (#4), la structure liée (#5), ni l'échelle d'une vie (#6). Comme *store* du second cerveau, **mauvais fit**. Comme *viewer* d'un sous-ensemble, OK. → **constat à noter pour la Phase 4 (Outillage, S6)**, pas une décision maintenant.

### 4.4 Le mécanisme de récupération autonome (exigence #2)

> C'est le mécanisme qui transforme « l'IA oublie et on répète » en « l'IA se souvient parce qu'elle va chercher ».

1. L'index (vector + SQL) est exposé via **MCP** (un outil « second cerveau »).
2. Chaque harnais (OpenFox, OpenCode, Hermes) est configuré avec cet outil + une instruction : *« tu as accès au second cerveau de l'utilisateur ; quand un sujet revient, cherche-le avant de répondre. »*
3. En cours de conversation, l'IA détecte « on parle du projet X » → appelle l'outil → récupère les fiches → intègre le contexte **sans que tu réexpliques**.

> ⚠️ **Dépendance** : ça exige que chaque harnais **supporte MCP** et soit **prompté** pour l'utiliser. OpenFox : oui. OpenCode : oui. Hermes : **à vérifier**.

### 4.5 Le flux global (sources → cerveau)

```
Sources brutes (immuables, in situ)
   ├── Fichiers précieux (Google Drive/SMB + Synology) ─┐
   ├── Mails (Thunderbird)                             ├─→ [INGESTION] ─→ [ANALYSE LLM]
   ├── Notes / écrits IA (OpenCode.db, notes, md)      ─┘                    │
   └── (fichiers précieux : fiches, PAS de déplacement) ────────────────────  ▼
                                                                        Vault md
                                                                        (Gitea canon + G9 working)
                                                                              │
                                                                    ┌─────────┴─────────┐
                                                                    ▼                   ▼
                                                              Index vectoriel      Toi (Obsidian)
                                                              (cache, jetable)
                                                                    │
                                                                    ▼
                                                              Consultation LLM (MCP)
                                                              → réponse + références
```

Le vault contient **la connaissance distillée** (fiches, résumés, tags, index des mails) — **pas** les 10 Go bruts. Les bruts sont **référencés par chemin** (machine + path) dans les fiches.

### 4.6 Synthèse des briques

| Brique | Rôle | Où |
|--------|------|-----|
| **Scanner** (Tier B) | métadonnées + doublons + corruption, pas d'IA | sur **G9** (là où seront les données) |
| **Extracteurs** | sessions OpenCode (SQLite→texte), mails, notes, écrits | **PC IA** |
| **Analyse** (Tier A) | LLM profond → fiches md structurées | **PC IA** (2×3060) |
| **Vault** | md versionné git = source de vérité, lisible + éditable | **Gitea** (canon) + **G9** (working) |
| **Index** | embeddings + sqlite-vec/Qdrant, jetable, reconstruisible | **G9** (ou PC IA) |
| **Consultation** | requête NLP → réponse + références, exposé en **MCP** | **PC IA** |

---

## S5 — MVP (Second Cerveau Tier A de bout en bout)

> **Statut** : 🟡 **Cahier des charges posé** — à implémenter **après** les fondations infra (`DOSSIER-RECREATION.md` Phase 0).

**Définition** : le MVP = la plus petite version qui livre la **valeur centrale** : *poser une question naturelle à un LLM sur mes données précieuses et obtenir une réponse précise avec références (machine + chemin), avec récupération autonome.*

**Le MVP = le Tier A de bout en bout** (le scanner Tier B est une **piste séparée**, pas dans le MVP) :

1. **Ingestion** des sources Tier A (fichiers précieux, mails, notes, écrits IA) → store local.
2. **Analyse profonde** : chaque doc → fiche structurée LLM (résumé, valeur, sensibilité, tags).
3. **Vault** : md versionné git (Gitea canon + G9 working).
4. **Index** : embeddings + index vectoriel (sqlite-vec ou Qdrant), reconstruisible.
5. **Consultation** : requête NLP → réponse + références, exposée en **MCP** avec récupération autonome.

### 5.1 Critères d'acceptance du MVP

Voir **Annexe A** (C1.1 → C1.13 + transverses CT.1 → CT.4).

---

## S6 — Roadmap & phases

> **Statut** : 🟡 **Cadrée** — l'ordre est posé ; le démarrage est **conditionné aux fondations infra**.

| Phase | Contenu | IA ? | Dépendance |
|-------|---------|------|------------|
| **0 — Dimensionnement** | Estimer le volume réel par source (rclone size / échantillonnage), identifier les sources prioritaires. **Dérisk tout le reste.** | non | infra (re)créée |
| **1 — MVP (Second Cerveau Tier A)** | Ingestion → analyse → vault → index → consultation MCP (de bout en bout) | oui (2×3060) | Phase 0 |
| **2 — Scanner (Tier B)** | Pass 1 métadonnées + dédoublonnage par taille + corruption + stats + dashboard + incrémental | **non** | Phase 0 |
| **3 — Famille & assistante** | Partitionnement par personne ; 2ᵉ cerveau de la femme (automatisé, non intrusif) ; protection enfants ; assistante Effi | oui | Phases 1+2 |
| **4 — Outillage** | Choix des outils (notes, viewer, vector DB, host) en cochant les 9 exigences (S2) | — | Phase 1 (pour valider le besoin) |

> **Ordre de valeur** : le **MVP (Phase 1)** est la priorité car il livre la valeur centrale (second cerveau). Le **Scanner (Phase 2)** est utile mais secondaire. La **Famille (Phase 3)** est long terme. L'**outillage (Phase 4)** se décide **après** avoir validé le besoin sur soi.

> ⚠️ **Timing** : ce projet démarre **après** que l'infra est en place (migration xpenology→G9, backup 3-2-1 fonctionnel, disque J5040 allégé). Les données sont **en flux** pendant la (re)création ; un inventaire fait trop tôt serait obsolète. Le re-scan post-migration est systématique (d'où l'incrémental).

---

## S7 — Décisions ouvertes

> **Statut** : 🟡 **À trancher** — chacune a sa liste de critères (S2). On ne tranche jamais à l'arrache.

| # | Décision | Statut | Critères / note |
|---|----------|--------|-----------------|
| D1 | **Notes** : quel outil ? (Nextcloud Notes vs Obsidian vs autre) | → **DOSSIER-SOFTWARE.md** (Partie 5) | Les 9 exigences (S2) guident le choix. Nextcloud Notes = mauvais fit comme *store* (S4.3). |
| D2 | **Mails** : Thunderbird+MCP (validé en test) vs n8n vs autre | À évaluer | Thunderbird+MCP a marché en test (« du bricolage mais ça a marché »). n8n = alternative à étudier. |
| D3 | **Écrits IA** : localiser OpenFox/Hermes sur `effi-server` | ⚠️ **À vérifier** | Pas de clé SSH depuis l'environnement de rédaction. À faire manuellement. |
| D4 | **Store** : Gitea (host canon) confirmé ? | À valider | Bon pour le versioning ; à apprendre git (pilier 4). Le store = les md, pas Gitea. |
| D5 | **Vector DB** : sqlite-vec (simple) vs Qdrant (déjà installé) | ✅ **Tranché : Qdrant** | Qdrant (bge-m3) tourne déjà. Décision actée dans `DOSSIER-SOFTWARE.md` S4.2. |
| D6 | **Famille** : partitionnement dès le design ou post-MVP ? | Long terme | Hors MVP. Exigence #6 (S2). Déploiement progressif : moi → femme → enfants. |
| D7 | **Photos Tier B** : Moments + Nextcloud vs autre | → **DOSSIER-SOFTWARE.md** (Partie 5) | Pas d'Immich (désorganise). Le scanner (Tier B) ne dépend pas de ce choix. |

---

## S8 — Risques

> **Statut** : 🟡 **Identifiés** — matrice à évaluer en Phase 0.

| # | Risque | Prob. | Impact | Mitigation |
|---|--------|-------|--------|------------|
| 1 | **Faux négatifs au triage** (fichier précieux au nom générique) | 3 | 3 | Triage sur **contenu** (extrait/EXIF), seuils réglables, re-passe possible |
| 2 | **Volume Tier B inconnu** → passes longues | 3 | 3 | **Phase 0 dimensionnement d'abord** (C0.1) ; entonnoir (IA seulement sur Tier A) |
| 3 | **Sessions OpenCode en SQLite** (pas texte) | 2 | 2 | **Extracteur dédié** (C1.1) |
| 4 | **Harnais sans support MCP** (Hermes ?) | 3 | 3 | À vérifier ; **fallback** = lecture directe du vault md |
| 5 | **Maintenance du vault** (git) | 3 | 2 | Montée en compétence (S10) + conventions simples |
| 6 | **Non-intrusivité pour la famille** | 3 | 3 | Ingestion **automatisée**, pas de saisie manuelle |
| 7 | **Échelle** (une vie + famille) | 2 | 3 | Markdown = format universel, index **reconstruisible** |
| 8 | **Mails volumineux** (20-30 ans) | 3 | 2 | Index + triage (pas ingestion brute) ; sous-projet à part |
| 9 | **Dépendance aux fondations infra** | 4 | 4 | Démarrage **conditionné** à la (re)création (S6) ; backup 3-2-1 d'abord |

---

## S9 — Lien avec l'infrastructure

> **Statut** : ✅ **Aligné** avec `DOSSIER-RECREATION.md` v2 (architecture cible).

### 9.1 Rôle de chaque machine pour ce projet

| Machine | Rôle (infra) | Rôle (ce projet) |
|---------|--------------|------------------|
| **G9** (.25) | Cœur famille | **Truth** : vault working copy + scanner (les données) + index (option) |
| **PC IA** (.11) | IA 24/7 (2×3060) | **Calcul** : extracteurs + analyse LLM + consultation MCP ; **4 To backup** local des données précieuses |
| **Gitea** (sur G9) | Versioning | **Host canonique** du vault |
| **effi-server / J5040** (.1) | Edge / IA | Source des écrits IA (OpenFox, Hermes) — **à localiser** |
| **218play** (.26) | Offsite (3ᵉ copie) | Backup du vault + données précieuses |

### 9.2 Règle de placement des données

- **G9 = vérité canonique** (cœur famille).
- **PC IA = calcul** (2×3060, Ollama) + **4 To 3,5" retrouvé = copie de backup locale** des données précieuses.
- **Stage** les ~10 Go du Tier A sur le NVMe du PC IA pour l'analyse (10 Go = négligeable) ou lecture réseau.
- **Gitea = host canon** du vault ; **G9 = working copy**.

### 9.3 S'appuyer sur les briques existantes (pas de nouveau stack)

> L'infra a **déjà** : Qdrant (bge-m3), Ollama (28 modèles, embeddings), mcpo (orchestrateur MCP), Dify, n8n. Ce projet **expose** le second cerveau via **MCP** vers ces briques existantes. **Pas de nouveau stack RAG.**

> ⚠️ **Note** : Qdrant a été mis en place pour le projet Effi ; OpenWebUI ne marche plus très bien ; RAGFlow et Dify servent de **maquette** pour la présentation. L'infra a grandi de manière empirique — **l'ensemble des applications à garder/rejeter sera revu dans la Phase 4 (Outillage, S6)**, une fois les données traitées. Ce projet **ne préjuge pas** de ce choix.

---

## S10 — Montée en compétence

> **Statut** : ✅ **Cadré** — l'infra + ce projet comme terrain d'apprentissage (pilier 4).

| Compétence | Service / action dans ce projet | Phase |
|------------|---------------------------------|-------|
| **Git** | Vault versionné (Gitea), conventions de commit, branches | 1 |
| **MCP** | Exposition du second cerveau en outil MCP, configuration des harnais | 1 |
| **RAG** | Index vectoriel, embeddings, recherche sémantique, chunking | 1 |
| **SQLite / SQL** | Base de l'inventaire, requêtes, sqlite-vec | 1, 2 |
| **OCR** | Tesseract / kreuzberg (PDF scannés) | 1 |
| **Dédoublonnage** | Hash exact, pHash, pré-filtre par taille | 2 |
| **Ingestion** | Extracteurs (SQLite→texte, mails, notes) | 1 |
| **Orchestration** | Passes, files de priorité, quotas | 1 |

> **Lien CAS** : ce projet est un **portfolio réel** du CAS (IA & transformation digitale) — la culture de la donnée appliquée (second cerveau, source de vérité, 3-2-1) + la méthode (état de l'art → besoins → architecture → plan).

---

## Annexe A — Critères d'acceptance

> **Statut** : ✅ **Posés** (05/10/2026) — 31 critères, par phase.

### Phase 0 — Dimensionnement

| ID | Critère |
|----|---------|
| C0.1 | Volume réel par source (nb fichiers + Go), table des volumes |
| C0.2 | Sources **Tier A** identifiées et localisées (fichiers précieux, mails, notes, écrits IA) |
| C0.3 | Sources **Tier B** identifiées (photos, films, archives) |

### Phase 1 — MVP (Second Cerveau Tier A de bout en bout)

**Ingestion**

| ID | Critère |
|----|---------|
| C1.1 | Extracteur sessions OpenCode (`opencode.db` SQLite → texte) |
| C1.2 | Ingestion des notes (md) |
| C1.3 | Ingestion des écrits IA (OpenFox, Hermes) — à localiser sur effi-server |
| C1.4 | Ingestion fichiers précieux (Google Drive/SMB + Synology) → fiches |
| C1.5 | Ingestion mails (Thunderbird) → index + triage |

**Analyse**

| ID | Critère |
|----|---------|
| C1.6 | Analyse LLM → fiches md structurées (résumé, valeur, sensibilité, tags) |

**Vault (couche 1 — vérité)**

| ID | Critère |
|----|---------|
| C1.7 | Vault markdown versionné git (Gitea canon + G9 working copy) |
| C1.8 | Fiches liées (wikilinks, tags, arborescence) |

**Index (couche 2 — jetable)**

| ID | Critère |
|----|---------|
| C1.9 | Embeddings + index vectoriel (sqlite-vec **ou** Qdrant) |
| C1.10 | Index **reconstruisible** à tout moment depuis le vault |

**Consultation**

| ID | Critère |
|----|---------|
| C1.11 | Requête NLP → réponse + références précises (machine + chemin) |
| C1.12 | Exposition **MCP** (outil « second cerveau ») |
| C1.13 | **Récupération autonome** : le harnais appelle l'outil seul quand le sujet revient |

### Phase 2 — Scanner (Tier B, sans IA)

| ID | Critère |
|----|---------|
| C2.1 | Config N sources (SMB, SFTP, local), identifiants chiffrés |
| C2.2 | Pass 1 métadonnées (chemin, taille, mtime, type) |
| C2.3 | Dédoublonnage (pré-filtre taille, hash exact **uniquement** sur doublons) |
| C2.4 | Détection corruption (photos : EXIF/validité ; films : intégrité) |
| C2.5 | Stats volumétriques (par source / type / doublons) |
| C2.6 | Dashboard minimal (volumes, doublons, top dossiers) |
| C2.7 | Re-scan incrémental (mtime + size) |

### Phase 3 — Famille & assistante (long terme)

| ID | Critère |
|----|---------|
| C3.1 | **Partitionnement par personne** (moi → femme → enfants) |
| C3.2 | Second cerveau de la **femme** : ingestion **automatisée, non intrusive** (mails, organisation) |
| C3.3 | **Protection enfants** : alternative souveraine aux GAFAM / IA cloud (anti-dépendance) |
| C3.4 | **Assistante Effi** quotidienne : répond à tout sujet en puisant dans le cerveau + l'inventaire |

### Transverses (toutes phases)

| ID | Critère |
|----|---------|
| CT.1 | **100% local** — aucune donnée ne quitte la maison |
| CT.2 | **Non destructif / versionné** — historique, pas de perte |
| CT.3 | **Lisible + éditable par l'humain** — pas de boîte noire |
| CT.4 | **Index = cache** — jamais la source de vérité |

---

## Annexe B — Glossaire

| Terme | Définition |
|-------|------------|
| **Second cerveau** | Mémoire partagée, versionnée, lisible par l'humain et puisée d'elle-même par l'IA |
| **Vault** | La couche 1 : fichiers markdown versionnés git (source de vérité) |
| **Index** | La couche 2 : embeddings + index vectoriel (cache jetable, reconstruisible) |
| **Tier A** | Le cœur : ~10 Go précieux + mails + notes + écrits IA (analyse IA profonde) |
| **Tier B** | Le bulk : photos, films, archives (analyse cheap, sans IA) |
| **MCP** | Model Context Protocol — expose le second cerveau comme outil pour les harnais IA |
| **Harnais** | L'outil IA (OpenFox, OpenCode, Hermes) qui consomme le second cerveau |
| **RAG** | Retrieval-Augmented Generation |
| **pHash** | Hash perceptuel (images) pour détection de doublons approximatifs |
| **Gitea** | Host git canonique du vault (versioning) |
| **Dégafamisation** | Remplacer les services GAFAM par des équivalents locaux |
| **CAS** | Certificat d'Aptitude Spéciale (IA & transformation digitale) |

---

## Changelog

| Date | Version | Changement |
|------|---------|------------|
| 06/10/2026 | **v1.1** | **Correction IP** : `effi-server` / J5040 standardisé sur l'IP **cible .1** (post-rebuild) au lieu de l'ancienne .27 — S3.1 (écrits IA OpenFox/Hermes) + S9.1 (rôle machine). Le projet démarre **après** la (re)création où J5040 = .1. |
| 05/10/2026 | **v1.0** | **Création du dossier** — synthèse de la réflexion du 05/10/2026. Périmètre Tier A/B, **9 exigences du second cerveau** (S2), sources réelles vérifiées (S3), **architecture 2 couches** (S4), MVP Tier A (S5), roadmap (S6), décisions ouvertes (S7), risques (S8), lien infra (S9), montée en compétence (S10), **31 critères d'acceptance** (Annexe A). |