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
• S1 — Besoin & périmètre
• S2 — Les 9 exigences du second cerveau
• S3 — Sources réelles
• S4 — Architecture
• S5 — MVP (Second Cerveau Tier A de bout en bout)
• S6 — Roadmap & phases
• S7 — Décisions ouvertes
• S8 — Risques
• S9 — Lien avec l'infrastructure
• S10 — Montée en compétence
• Annexe A — Critères d'acceptance
• Annexe B — Glossaire
• 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).