Phase 4 : kit G9 (scripts + compose) + Gitea T4.4 backend Postgres
- compose/gitea : SQLite -> Postgres (source = paquet App Center DSM, gitea_db 13 repos/3 users), image épinglée 1.27.3, push-to-create - scripts/07a-migrate-gitea.sh : export pg_dump (MVCC, .25 lecture seule) + tar/ssh (sshd DSM refuse rsync/scp) + manifestes sha256 - scripts/03b-secrets.sh : secrets gitea ajoutés - journal.md : entrées Phase 4
This commit is contained in:
@@ -0,0 +1,799 @@
|
||||
# Guide — Culture de la donnée, de la dispersion à la souveraineté
|
||||
|
||||
**Date** : 30/09/2026
|
||||
**Auteur** : Jean-Henry Foltzenlogel (Folzo)
|
||||
**Réseau** : `192.168.1.0/24`
|
||||
**Statut global** : 🟡 **Guide de transformation** — à exécuter par phases (partie 10).
|
||||
**Document** : **vivant** — versionné, mis à jour à chaque évolution.
|
||||
|
||||
> **Nature du document** : ce n'est pas un rapport. C'est un **guide de transformation** — comment amener, transformer et adapter (mes habitudes, mon infra, ma famille) à une **culture de la donnée**, pour redevenir **maître de mes données** et faire de la donnée le **carburant du projet Effi** (mon Jarvis).
|
||||
>
|
||||
> **Position dans le projet** : c'est le **3ᵉ point** du renouvellement de l'infrastructure — le plus important, car **tout tourne autour**. Le dossier infra (`DOSSIER-RECREATION.md`, v2) décrit la **machine** ; ce guide décrit **l'esprit** qui fait tourner la machine.
|
||||
>
|
||||
> **Source de vérité** : les faits matériels proviennent du scan live du 30/09/2026 (`ETAT-DE-LART-2026-09-30.md`). L'inventaire des données (partie 2) est **préliminaire** — les lacunes sont marquées `🔎` à compléter au scan live.
|
||||
>
|
||||
> **Racine** : CAS IA & transformation digitale (thèse : **culture de la donnée + données non structurées**), défendu le 28/09/2026. Ce guide est l'application concrète de cette thèse à ma vie.
|
||||
|
||||
---
|
||||
|
||||
## Sommaire
|
||||
|
||||
- [0 — Manifeste](#0--manifeste)
|
||||
- [1 — Fondations](#1--fondations)
|
||||
- [2 — État des lieux des données](#2--état-des-lieux-des-données)
|
||||
- [3 — Architecture cible de la donnée](#3--architecture-cible-de-la-donnée)
|
||||
- [4 — Du non-structuré au structuré pour l'IA locale](#4--du-non-structuré-au-structuré-pour-lia-locale)
|
||||
- [5 — Adapter mes habitudes](#5--adapter-mes-habitudes)
|
||||
- [6 — Adapter la famille](#6--adapter-la-famille)
|
||||
- [7 — Adapter l'infrastructure](#7--adapter-linfrastructure)
|
||||
- [8 — Gouvernance, sécurité & continuité](#8--gouvernance-sécurité--continuité)
|
||||
- [9 — Mesure & amélioration continue](#9--mesure--amélioration-continue)
|
||||
- [10 — Roadmap « prendre le large »](#10--roadmap--prendre-le-large)
|
||||
- [Annexe A — Catalogue des actifs de données](#annexe-a--catalogue-des-actifs-de-données)
|
||||
- [Annexe B — Conventions de nommage & métadonnées](#annexe-b--conventions-de-nommage--métadonnées)
|
||||
- [Annexe C — Schéma de métadonnées (proposé)](#annexe-c--schéma-de-métadonnées-proposé)
|
||||
- [Annexe D — Glossaire](#annexe-d--glossaire)
|
||||
- [Changelog](#changelog)
|
||||
|
||||
---
|
||||
|
||||
## 0 — Manifeste
|
||||
|
||||
> **Statut** : ✅ Validé (intention)
|
||||
|
||||
### 0.1 Pourquoi la culture de la donnée est le point central
|
||||
|
||||
J'ai fait un **CAS IA & transformation digitale**. J'ai appris trois choses que je n'oublie plus :
|
||||
|
||||
1. **La donnée est la matière première de la valeur.** Sans donnée de qualité, pas d'IA utile.
|
||||
2. **La donnée non structurée est un gisement inexploré.** C'est là que se trouve le potentiel (et c'est le sujet de ma thèse).
|
||||
3. **La transformation digitale échoue sans culture de la donnée.** Les outils ne suffisent pas ; il faut changer **comment on pense, capture, organise et utilise** la donnée.
|
||||
|
||||
Aujourd'hui, mes données sont **éparpillées** : une partie cherchable sur le NAS, le reste dispersé entre Synology Photos, Joplin, Affine, Nextcloud, Obsidian, Gmail, Google Drive, des USB quasi pleins, et des machines qui n'ont rien en commun. J'ai passé beaucoup de temps sur les **photos** (seul actif réellement utilisable aujourd'hui, où je trouve de la plus-value). Le reste est en friche.
|
||||
|
||||
**Le problème n'est pas technique. C'est culturel.** Tant que je ne change pas **comment je traite mes données au quotidien**, chaque nouvel outil va juste créer un nouveau silo.
|
||||
|
||||
### 0.2 Le lien avec le projet Effi (mon Jarvis)
|
||||
|
||||
> **La culture de la donnée est l'activateur du projet Effi.**
|
||||
|
||||
Effi (mon Jarvis) ne sera pas un chatbot générique. Ce sera **un système qui connaît ma vie** — mes notes, mes photos, mes projets, mes décisions, mes habitudes. Et il ne pourra le que **si mes données sont** :
|
||||
|
||||
- **Maîtrisées** (je sais ce que j'ai, où c'est, qui y a accès),
|
||||
- **Trouvables** (je peux les retrouver en secondes, moi **et** l'IA),
|
||||
- **Utilisables** (structurées, indexées, exploitables),
|
||||
- **Améliorées** (la qualité augmente avec le temps),
|
||||
- **Pérennes** (elles survivent à un disque, à un OS, à un accident).
|
||||
|
||||
**Sans culture de la donnée, Effi est un Jarvis amnésique.** Avec, c'est un Jarvis qui **grandit avec moi**. C'est ça, le pari.
|
||||
|
||||
### 0.3 Les 5 engagements (mes 5 objectifs)
|
||||
|
||||
| # | Engagement | Question qu'il répond |
|
||||
|---|-----------|------------------------|
|
||||
| 1 | **Maîtrise / souveraineté** | *De qui sont mes données ? Qui y a accès ?* → redevenir **maître** de mes données. |
|
||||
| 2 | **Trouvabilité** | *Où est cette donnée ?* → la **trouver facilement**, moi et l'IA. |
|
||||
| 3 | **Utilité** | *À quoi ça me sert ?* → des données qui **m'aident**, pas qui m'enterrent. |
|
||||
| 4 | **Amélioration** | *Ça devient-il meilleur ?* → la qualité qui **s'améliore** avec le temps. |
|
||||
| 5 | **Pérennité** | *Ça survit-il ?* → **perpétuelle** s'il m'arrive quelque chose. |
|
||||
|
||||
> **Règle d'or** : toute décision (outil, flux, habitude) est évaluée contre ces 5 engagements. Si elle n'améliore aucun, on ne la fait pas.
|
||||
|
||||
---
|
||||
|
||||
## 1 — Fondations
|
||||
|
||||
> **Statut** : ✅ Validé (cadre conceptuel)
|
||||
|
||||
### 1.1 Qu'est-ce qu'une « culture de la donnée »
|
||||
|
||||
Une culture de la donnée, c'est un **système de croyances + pratiques** qui fait que la donnée est traitée comme un **actif** (comme de l'argent), pas comme un **déchet** (comme des fichiers qu'on jette dans un dossier).
|
||||
|
||||
Concrètement, ça se traduit en **reflexes** :
|
||||
|
||||
| Reflexe | Avant (silo) | Après (culture) |
|
||||
|---------|--------------|-----------------|
|
||||
| **Je reçois une info** | je la laisse dans la messagerie / le chat | je la **capture** au point d'entrée unique |
|
||||
| **Je crée un fichier** | je le nomme `screenshot 2026-09-30.png` | je le **nomme + je le classe** |
|
||||
| **J'ai une note** | elle dort dans une app | elle est **structurée + indexée** |
|
||||
| **Je cherche** | je fouille 6 apps | je **cherche une fois**, dans un moteur |
|
||||
| **Ça ne sert plus** | ça dort éternellement | je l'**archive ou je le supprime** |
|
||||
| **Un truc casse** | je perds des données | j'ai un **backup vérifié** |
|
||||
|
||||
### 1.2 Le cycle de vie de la donnée
|
||||
|
||||
Chaque donnée passe par **6 stades**. Une culture de la donnée, c'est **gérer chaque stade** :
|
||||
|
||||
```
|
||||
┌─────────┐ ┌───────────┐ ┌──────────┐ ┌─────────┐ ┌─────────┐ ┌──────────┐
|
||||
│ 1.CAPTURE│──►│2.ORGANISE │──►│3.STOCKAGE│──►│4.UTILISE│──►│5.ARCHIVE│──►│6.SUPPRIME│
|
||||
└─────────┘ └───────────┘ └──────────┘ └─────────┘ └─────────┘ └──────────┘
|
||||
point nommage + backup 3-2-1 recherche si inactif si obsolète
|
||||
d'entrée métadonnées + indexation + IA (froid) (inutile)
|
||||
```
|
||||
|
||||
| Stade | Question | Outil (direction) |
|
||||
|-------|----------|-------------------|
|
||||
| **1. Capture** | Où est le point d'entrée unique ? | Inbox unique (app + dossier) |
|
||||
| **2. Organisation** | Comment je nomme + je classe ? | Conventions (Annexe B) |
|
||||
| **3. Stockage** | Où c'est, est-ce sauvegardé ? | NAS G9 + 3-2-1 |
|
||||
| **4. Utilisation** | Comment je la retrouve + je m'en sers ? | Recherche + RAG (Effi) |
|
||||
| **5. Archivage** | Que faire de l'inactif ? | Zone froide (USB/offsite) |
|
||||
| **6. Suppression** | Que jeter, quand ? | Politique (partie 8) |
|
||||
|
||||
> **C'est le point que les gens oublient** (y compris moi) : on parle toujours de **stocker**, presque jamais de **supprimer**. Une culture de la donnée complète **gère la fin de vie** — sinon le disque se remplit et la donnée devient du bruit.
|
||||
|
||||
### 1.3 Les 5 propriétés, détaillées
|
||||
|
||||
| Propriété | Définition | Indicateur (mesurable) |
|
||||
|-----------|------------|------------------------|
|
||||
| **Maîtrise** | Je sais **ce que j'ai**, **où**, **qui y accède**. | Inventaire à jour (partie 2) + contrôle d'accès. |
|
||||
| **Trouvabilité** | Je retrouve une donnée en **< 30 s** (moi et l'IA). | Temps de recherche moyen ; taux de « trouvé du 1er coup ». |
|
||||
| **Utilité** | La donnée **sert** (décision, création, mémoire). | % de données réellement consultées (vs dormant). |
|
||||
| **Amélioration** | La **qualité** augmente avec le temps (métadonnées, dédup, structure). | % de données avec métadonnées complètes ; dédups faits. |
|
||||
| **Pérennité** | La donnée **survit** (disque, OS, accident, décès). | Backup 3-2-1 **vérifié** + continuité famille. |
|
||||
|
||||
### 1.4 Les 4 niveaux de structure (du gisement au carburant)
|
||||
|
||||
C'est le cœur de ma thèse — les **données non structurées** sont un gisement. Voici la hiérarchie :
|
||||
|
||||
| Niveau | Type | Exemple | Traitements pour « monter » |
|
||||
|--------|------|---------|------------------------------|
|
||||
| **L0 — Brut** | Non structuré, non exploitable | Photo, scan PDF, enregistrement audio, capture | OCR, STT, extraction |
|
||||
| **L1 — Textualisé** | Textes extraits, non organisés | Transcription, OCR brut | Nettoyage, segmentation |
|
||||
| **L2 — Structuré** | Champ, métadonnées, index | Notes taguées, photos géotaguées, fiches | Nommage, métadonnées, index |
|
||||
| **L3 — Sémantique** | Exploitable par l'IA | Embeddings, graph, RAG | Vectorisation (bge-m3 → Qdrant) |
|
||||
|
||||
> **L'objectif** : faire **monter** mes données de L0 → L3. C'est ce qui rendra Effi utile. Aujourd'hui, mes données sont majoritairement **L0** (photos, scans, audio) — d'où le potentiel inexploré.
|
||||
|
||||
---
|
||||
|
||||
## 2 — État des lieux des données
|
||||
|
||||
> **Statut** : 🟡 **Inventaire préliminaire** — basé sur l'état de l'art du 30/09/2026. Les valeurs marquées `🔎` sont à **compléter au scan live** (tâche d'exécution, partie 10 étape C1).
|
||||
|
||||
### 2.1 Règle de lecture
|
||||
|
||||
- Chaque actif de données est décrit : **localisation, volume, format, structure, qualité, sensibilité, valeur, priorité**.
|
||||
- **Sensibilité** : 🟢 publique / 🟡 privée / 🔴 critique (perte = désastre).
|
||||
- **Valeur** : 🔴 patrimoine (irremplaçable) / 🟠 haute / 🟡 moyenne / ⚪ faible.
|
||||
- **Priorité de structuration** (pour l'IA) : P0 (d'abord) → P3 (plus tard).
|
||||
|
||||
### 2.2 Cartographie par support (où sont mes données)
|
||||
|
||||
| Support | Machine / IP | Contenu | Volume | État |
|
||||
|---------|--------------|---------|--------|------|
|
||||
| **Synology Photos** | xpenology .25 | Photos famille ~10 ans | 🔎 à estimer | 🟡 fiable mais enchaîné XPEnology |
|
||||
| **Nextcloud** | xpenology .25 | Fichiers famille | 🔎 à estimer | 🟡 à migrer G9 |
|
||||
| **Joplin** | xpenology .25 | Notes | 🔎 à estimer | 🟡 dispersé |
|
||||
| **Affine** | xpenology .25 | Workspace | 🔎 à estimer | 🟡 à trancher (R6.2) |
|
||||
| **Obsidian** | effi-server .27 (CouchDB LiveSync) | Notes | 🔎 à estimer | 🟡 à trancher (R6.2) |
|
||||
| **Vaultwarden** | xpenology .25 | Mots de passe | — | 🔴 critique, à migrer G9 |
|
||||
| **Gitea** | xpenology .25 | Projets / docs / code | 🔎 à estimer | 🟠 à fiabiliser |
|
||||
| **Média USB** | xpenology USB1/USB2 | Films / séries | 15 To + 5.5 To | 🟡 à 92%, quasi pleins |
|
||||
| **Modèles LLM** | folzo-corp .11 | GGUF (28 modèles) | 98 Go | 🟡 dont ~18 legacy à trier |
|
||||
| **Gmail** | Google (cloud) | Mail famille | 🔎 à estimer | 🟠 à dégafamiser |
|
||||
| **Google Drive/Cal/Contacts** | Google (cloud) | Fichiers, agenda, contacts | 🔎 à estimer | 🟠 à dégafamiser |
|
||||
| **Enregistrements NVR** | Reolink .41/.123/.191 | Vidéos surveillance | 🔎 à estimer | 🟡 à trier (durée de rétention) |
|
||||
| **Laptop** | — | Workstation, clones locaux, docs | 2 To + 1 To | 🟡 à cartographier |
|
||||
| **218play** | .26 | Backup (2×2 To) | ~4 To | 🟡 offsite non exploité |
|
||||
| **Freebox RAID5** | .254 | Backup intermédiaire (3×1 To) | 2 To | 🟡 peu utilisé |
|
||||
| **WhatsApp / iMessage** | Cloud / téléphone | Messagerie | 🔎 à estimer | 🟡 à dégafamiser (Matrix) |
|
||||
|
||||
### 2.3 Inventaire détaillé des actifs
|
||||
|
||||
| # | Actif | Localisation | Volume | Format | Structure | Qualité | Sensibilité | Valeur | Prio IA |
|
||||
|---|-------|-------------|--------|--------|-----------|---------|-------------|--------|---------|
|
||||
| D1 | **Photos famille** | Synology Photos (.25) | 🔎 ~10 ans | JPG/HEIC | L1 (IA Syno) | 🟠 bonne | 🟡 privée | 🔴 patrimoine | **P0** |
|
||||
| D2 | **Mots de passe** | Vaultwarden (.25) | — | JSON (chiffré) | L2 | 🟠 | 🔴 critique | 🔴 critique | P2 |
|
||||
| D3 | **Notes** | Joplin/Affine/Obsidian (dispersé) | 🔎 | Markdown/DB | L1-L2 | 🟡 moyenne | 🟡 privée | 🟠 haute | **P0** |
|
||||
| D4 | **Fichiers famille** | Nextcloud (.25) | 🔎 | divers | L0-L2 | 🟡 | 🟡 privée | 🟠 haute | P1 |
|
||||
| D5 | **Projets / docs** | Gitea + clones | 🔎 | Markdown/code | L2 | 🟠 | 🟡 | 🟠 haute | **P0** |
|
||||
| D6 | **Média (films/séries)** | USB xpenology | 20.5 To | MKV/MP4 | L0 | 🟠 | 🟢 | 🟡 moyenne | P3 |
|
||||
| D7 | **Modèles LLM** | folzo-corp | 98 Go | GGUF | L3 (outils) | 🟠 | 🟢 | 🟡 moyenne | — (outils) |
|
||||
| D8 | **Mail** | Gmail | 🔎 | EML/HTML | L0-L1 | 🟡 | 🟡 | 🟠 haute | P1 |
|
||||
| D9 | **Agenda / contacts** | Google | 🔎 | ICS/VCF | L2 | 🟠 | 🟡 | 🟠 haute | P2 |
|
||||
| D10 | **Enregistrements NVR** | Reolink ×3 | 🔎 | MP4 | L0 | ⚪ | 🟡 | ⚪ faible | P3 |
|
||||
| D11 | **Musique** | (à localiser) | 🔎 | MP3/FLAC | L0-L2 | 🟠 | 🟢 | 🟡 moyenne | P3 |
|
||||
| D12 | **Messagerie** | WhatsApp/iMessage | 🔎 | binaire | L0 | ⚪ | 🟡 | ⚪ faible | P3 |
|
||||
|
||||
### 2.4 Diagnostic de l'état des lieux
|
||||
|
||||
**Constat** :
|
||||
|
||||
1. **Les photos (D1) sont le seul actif mature** — c'est là que je trouve de la plus-value aujourd'hui. C'est le modèle à **répliquer** sur les autres actifs.
|
||||
2. **Les notes (D3) sont le 2ᵉ gisement** — dispersées en 4 apps, c'est le plus gros frein à la culture de la donnée. C'est la décision R6.2.
|
||||
3. **Le non-structuré domine** — photos, scans, audio, vidéo = L0. C'est **exactement** le sujet de ma thèse : un gisement inexploré.
|
||||
4. **La dispersion est le problème n°1** — 6+ apps de notes, 3+ emplacements de fichiers, 2 clouds GAFAM. **Un actif, un endroit, une source de vérité.**
|
||||
5. **Le backup est inopérant** (USB HS) → la pérennité (engagement 5) est **au sol** aujourd'hui. C'est le risque #1 du dossier.
|
||||
|
||||
**Principe** : **un actif = un endroit = une source de vérité.** Pas de duplication, pas de « c'est peut-être ici, peut-être là ».
|
||||
|
||||
---
|
||||
|
||||
## 3 — Architecture cible de la donnée
|
||||
|
||||
> **Statut** : ✅ Cadré — à affiner au scan live (volumes, partitions).
|
||||
|
||||
### 3.1 Les 2 zones de données
|
||||
|
||||
| Zone | Contenu | Machine | Accès | Sensibilité max |
|
||||
|------|---------|---------|-------|-----------------|
|
||||
| **Famille** | Photos, fichiers, média, agenda, mots de passe, domotique | **NAS G9 (.25)** | Famille (postes enfants filtrés) | 🔴 (mots de passe) |
|
||||
| **Personnel / IA** | Notes, projets, RAG, Effi, modèles | **PC IA (.11)** | Moi | 🟡 |
|
||||
|
||||
> **Règle** : rien ne quitte la maison. Les données de la famille et les données personnelles restent **100% locales** — c'est le principe de souveraineté (partie 0).
|
||||
|
||||
### 3.2 Topologie de stockage (sur le G9, cœur famille)
|
||||
|
||||
```
|
||||
NAS G9 (.25)
|
||||
├── /data/famille/
|
||||
│ ├── photos/ ← D1 (patrimoine, IA)
|
||||
│ ├── fichiers/ ← D4 (Nextcloud)
|
||||
│ ├── media/ ← D6 (films/séries, Jellyfin)
|
||||
│ ├── musique/ ← D11
|
||||
│ └── partages/ ← partages famille
|
||||
├── /data/perso/
|
||||
│ ├── notes/ ← D3 (source de vérité unique)
|
||||
│ ├── projets/ ← D5 (Gitea)
|
||||
│ └── documents/ ← scans, PDF, admin
|
||||
├── /vault/
|
||||
│ └── motsdepasse/ ← D2 (Vaultwarden, chiffré)
|
||||
└── /backup/ ← point de départ du 3-2-1
|
||||
```
|
||||
|
||||
### 3.3 Le flux de la donnée (capture → pérennité)
|
||||
|
||||
```
|
||||
CAPTURE ORGANISER STOCKER UTILISER ARCHIVER
|
||||
│ │ │ │ │
|
||||
Inbox unique → Nommer + classer → NAS G9 → Recherche + → Zone froide
|
||||
(1 app, 1 (conventions (3-2-1) IA (Effi/RAG) (USB/offsite)
|
||||
dossier) Annexe B)
|
||||
│
|
||||
▼
|
||||
INDEXER (L0→L3)
|
||||
OCR / STT / embeddings
|
||||
(partie 4)
|
||||
```
|
||||
|
||||
### 3.4 Conventions (résumé — détail en Annexe B)
|
||||
|
||||
| Règle | Exemple |
|
||||
|-------|---------|
|
||||
| **Nommage** | `AAAAMMJJ-description.ext` (pas `screenshot 1.png`) |
|
||||
| **Un actif = un endroit** | Les notes → `/data/perso/notes/` uniquement |
|
||||
| **Métadonnées** | Chaque doc important a : auteur, date, tags, statut |
|
||||
| **Format ouvert** | Markdown, PDF, JPG — pas de format propriétaire verrouillé |
|
||||
| **Dédup** | Pas de 2 copies de la même donnée (sauf backup) |
|
||||
|
||||
---
|
||||
|
||||
## 4 — Du non-structuré au structuré pour l'IA locale
|
||||
|
||||
> **Statut** : ✅ Cadré — c'est le cœur de ma thèse. À exécuter par priorité (P0 d'abord).
|
||||
|
||||
### 4.1 Le principe
|
||||
|
||||
Mes données sont majoritairement **L0** (non structurées). Pour qu'Effi en profite, il faut les **monter** à **L3** (sémantique). Le pipeline :
|
||||
|
||||
```
|
||||
L0 (brut) L1 (textualisé) L2 (structuré) L3 (sémantique)
|
||||
───────── ────────────── ────────────── ───────────────
|
||||
Photo ──OCR──► texte ──tags/métadonnées──► embeddings
|
||||
Audio ──STT──► transcription ──diarisation──► ──bge-m3──► Qdrant
|
||||
PDF ──OCR──► texte ──segmentation──► (vector DB)
|
||||
Vidéo ──frames──► images ──scènes──►
|
||||
```
|
||||
|
||||
### 4.2 Les briques existantes (déjà dans mon infra)
|
||||
|
||||
| Étape | Outil | Machine | État |
|
||||
|-------|-------|---------|------|
|
||||
| **OCR** | `effi-ocr` / `kreuzberg` (PaddleOCR FR) | folzo-corp / effi-server | 🟡 unhealthy (à réparer) |
|
||||
| **STT** | `whisper` (faster-whisper) | effi-server | ✅ up |
|
||||
| **STT** | `effi-stt` | folzo-corp | 🟡 unhealthy (à réparer) |
|
||||
| **Embeddings** | `bge-m3` | effi-server | ✅ |
|
||||
| **Vector DB** | `Qdrant` | effi-server | ✅ |
|
||||
| **RAG** | `RAGFlow` | folzo-corp | ❌ crash loop (à réparer) |
|
||||
| **RAG** | `Dify` | effi-server | ✅ |
|
||||
| **LLM** | Swift-1.5 Qwen 27B (llama.cpp) | folzo-corp | ✅ stable |
|
||||
| **Interface** | `OpenWebUI` | effi-server | ✅ |
|
||||
| **Automatisation** | `n8n` | effi-server + xpenology | ✅ |
|
||||
|
||||
> **Bonne nouvelle** : j'ai **toute la chaîne** déjà en place. Le problème n'est pas de construire, c'est de **fiabiliser** (partie 10, étape C3) et de **l'alimenter** en données structurées.
|
||||
|
||||
### 4.3 Priorisation de ce à structurer en premier
|
||||
|
||||
| Prio | Actif | Pourquoi d'abord | Pipeline |
|
||||
|------|-------|------------------|----------|
|
||||
| **P0** | **Notes** (D3) | C'est mon 2ᵉ cerveau, déjà textuel (L1) → rapide à monter à L3 | Nettoyage → segmentation → bge-m3 → Qdrant |
|
||||
| **P0** | **Projets/docs** (D5) | Markdown, déjà structuré (L2) → le plus rentable | Indexation directe → Qdrant |
|
||||
| **P0** | **Photos** (D1) | Patrimoine, IA déjà en place (Syno) → à répliquer | OCR légendes + embeddings visuels |
|
||||
| **P1** | **Fichiers** (D4) | Hétérogène, valeur haute | OCR (PDF) → indexation |
|
||||
| **P1** | **Mail** (D8) | Volume élevé, valeur variable | Tri → extraction → indexation (sensible) |
|
||||
| **P2** | **Agenda/contacts** (D9) | Structuré (L2) → facile | Indexation |
|
||||
| **P3** | **Média/NVR/musique** | Volume énorme, valeur faible | À la demande seulement |
|
||||
|
||||
> **Règle** : on ne vectorise **pas** 20 To de films. On structure ce qui a de la **valeur cognitive** (notes, docs, photos de mémoire), on laisse le reste en **stockage passif**.
|
||||
|
||||
### 4.4 Le pipeline « capture → Effi » (boucle)
|
||||
|
||||
```
|
||||
Nouvelle donnée (note/photo/doc)
|
||||
│
|
||||
▼
|
||||
n8n détecte l'arrivée (watcher)
|
||||
│
|
||||
├──► si image/PDF → OCR (kreuzberg)
|
||||
├──► si audio → STT (whisper)
|
||||
│
|
||||
▼
|
||||
Nettoyage + segmentation
|
||||
│
|
||||
▼
|
||||
Embeddings (bge-m3)
|
||||
│
|
||||
▼
|
||||
Qdrant (vector DB)
|
||||
│
|
||||
▼
|
||||
Effi peut maintenant y répondre (RAG via Dify/OpenWebUI)
|
||||
```
|
||||
|
||||
> **C'est la boucle qui rend Effi « grandir avec moi »** : chaque nouvelle donnée structurée = Effi devient un peu plus utile. C'est la **culture de la donnée en action**.
|
||||
|
||||
---
|
||||
|
||||
## 5 — Adapter mes habitudes
|
||||
|
||||
> **Statut** : ✅ Cadré — c'est le plus important (la culture, pas la techno).
|
||||
|
||||
### 5.1 Les 6 réflexes à installer
|
||||
|
||||
| # | Réflexe | Action concrète | Fréquence |
|
||||
|---|---------|-----------------|-----------|
|
||||
| 1 | **1 point de capture** | Tout entre par **une** inbox (app + dossier `/inbox/`). Rien ne dort dans un chat/mail. | quotidien |
|
||||
| 2 | **Nommer au moment** | Je nomme le fichier **quand je le crée** (convention `AAAAMMJJ-description`). | à la création |
|
||||
| 3 | **Classeer en fin de journée** | Je vide l'inbox : je déplace chaque élément à sa place (ou je le supprime). | quotidien (10 min) |
|
||||
| 4 | **1 actif = 1 endroit** | Je ne duplique pas. Les notes → notes, les docs → docs. | permanent |
|
||||
| 5 | **Revue hebdo** | 30 min : je cherche ce qui dort, je dédups, j'archive, je structure. | hebdo |
|
||||
| 6 | **Documenter** | Chaque décision/évo majeure → mise à jour du dossier (source de vérité). | à chaque écho |
|
||||
|
||||
### 5.2 Le rituel quotidien (10 min)
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────┐
|
||||
│ FIN DE JOURNÉE — 10 MIN │
|
||||
├─────────────────────────────────────────────┤
|
||||
│ 1. Vide l'inbox (app + /inbox/) │
|
||||
│ 2. Nomme + classe chaque élément │
|
||||
│ 3. Supprime ce qui ne sert pas │
|
||||
│ 4. (optionnel) capture une note pour Effi │
|
||||
└─────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 5.3 La revue hebdo (30 min)
|
||||
|
||||
| Étape | Action | Durée |
|
||||
|-------|--------|-------|
|
||||
| 1 | **Trouver** : je cherche 3 choses aléatoires (test de trouvabilité) | 5 min |
|
||||
| 2 | **Dédup** : je repère les doublons | 5 min |
|
||||
| 3 | **Structurer** : je monte 1 actif de L0→L2 (tags, métadonnées) | 15 min |
|
||||
| 4 | **Archiver** : je déplace l'inactif en zone froide | 5 min |
|
||||
|
||||
### 5.4 L'automatisation (n8n) — ce qui ne doit pas être manuel
|
||||
|
||||
| Tâche | Automatisation | Gain |
|
||||
|-------|----------------|------|
|
||||
| **Indexation** | n8n watche `/inbox/` → OCR/STT → Qdrant | 0 min (auto) |
|
||||
| **Backup** | Snapshot quotidien NAS → Freebox, hebdo → 218play | 0 min (auto) |
|
||||
| **Alertes** | Beszel alerte si disque > 90%, service down | 0 min (auto) |
|
||||
| **Dédup photos** | Scan hebdo des doublons | quasi auto |
|
||||
| **Mise à jour docs** | Rappels (n8n) quand un dossier n'a pas été touché | 0 min (auto) |
|
||||
|
||||
> **Principe** : **automatiser ce qui est répétitif** (indexation, backup, alertes), **garder humain ce qui est judgment** (classer, archiver, supprimer). L'IA aide, elle ne décide pas à ma place.
|
||||
|
||||
---
|
||||
|
||||
## 6 — Adapter la famille
|
||||
|
||||
> **Statut** : ✅ Cadré — la culture de la donnée est une affaire **familiale**, pas solo.
|
||||
|
||||
### 6.1 Le principe
|
||||
|
||||
La famille ne va pas adopter un « système de données ». Elle va adopter **des réflexes simples** qui, agrégés, créent la culture. **Moins c'est plus** : 3 règles max, pas un manuel.
|
||||
|
||||
### 6.2 Les 3 règles famille (simples)
|
||||
|
||||
| # | Règle | Pourquoi |
|
||||
|---|-------|----------|
|
||||
| 1 | **Les photos vont sur le NAS** (pas dans le cloud) | Pérennité + souveraineté |
|
||||
| 2 | **Les documents vont dans le dossier famille** | Trouvabilité |
|
||||
| 3 | **On ne supprime pas, on demande** | Évite la perte d'un patrimoine |
|
||||
|
||||
### 6.3 L'onboarding (par personne)
|
||||
|
||||
| Personne | Ce qu'on lui montre | Effort |
|
||||
|----------|---------------------|--------|
|
||||
| **Moi** | Tout (admin) | — |
|
||||
| **Conjoint(e)** | App photos + dossier famille + partage | 30 min |
|
||||
| **Enfants** | App photos + règles simples (pas de cloud) | 15 min |
|
||||
|
||||
### 6.4 Ce qui est automatisé (la famille ne se soucie de rien)
|
||||
|
||||
| Tâche | Qui s'en occupe |
|
||||
|-------|-----------------|
|
||||
| **Backup** | n8n + 3-2-1 (invisible) |
|
||||
| **Indexation photos** | IA (reconnaissance, albums auto) |
|
||||
| **Sécurité** | DNS filtré (AdGuard) + profils enfants |
|
||||
| **Partage** | Liens (pas de transfert manuel) |
|
||||
|
||||
> **La famille vit la culture sans la subir** : elle pose les photos, elle retrouve ses docs, et le reste (backup, indexation, sécurité) est **transparent**.
|
||||
|
||||
---
|
||||
|
||||
## 7 — Adapter l'infrastructure
|
||||
|
||||
> **Statut** : ✅ Cadré — chaque service infra sert un engagement.
|
||||
|
||||
### 7.1 Mapping engagement → service
|
||||
|
||||
| Engagement | Service(s) | Machine |
|
||||
|------------|-----------|---------|
|
||||
| **Maîtrise** | Inventaire (ce dossier) + contrôle d'accès (VPN, profils) | toutes |
|
||||
| **Trouvabilité** | Recherche plein texte + RAG (Qdrant) + DNS (AdGuard) | PC IA + J5040 |
|
||||
| **Utilité** | RAG (Effi) + médiathèque (Jellyfin) + agenda (CalDAV) | PC IA + G9 |
|
||||
| **Amélioration** | OCR/STT + n8n (indexation auto) + dédup | PC IA |
|
||||
| **Pérennité** | Backup 3-2-1 + chiffrement + continuité | NAS + Freebox + 218play |
|
||||
|
||||
### 7.2 Le backup 3-2-1 (pérennité)
|
||||
|
||||
> **Schéma des 3 copies** (originale NAS G9 / intermédiaire Freebox / offsite 218play) : voir `DOSSIER-RECREATION.md` §R4 (source unique du plan).
|
||||
|
||||
> **Règle culture** : un backup **non testé** = pas de backup. **Test de restauration au moins 1×/trimestre** (critère de succès, partie 10).
|
||||
|
||||
### 7.3 La sécurité (souveraineté)
|
||||
|
||||
| Mesure | Détail |
|
||||
|--------|--------|
|
||||
| **Chiffrement** | Mots de passe (Vaultwarden) + disque (LUKS) + en transit (HTTPS) |
|
||||
| **Accès** | VPN pour l'extérieur, profils famille filtrés (AdGuard) |
|
||||
| **Isolation** | Réseau local, accès contrôlé (VPN, profils) |
|
||||
| **Mots de passe** | Vaultwarden (coffre unique), 2FA |
|
||||
| **MAJ** | Watchtower + suivi (mais testé, pas « on verra ») |
|
||||
|
||||
---
|
||||
|
||||
## 8 — Gouvernance, sécurité & continuité
|
||||
|
||||
> **Statut** : ✅ Cadré — c'est ce qui manquait (le « déployer la voile »).
|
||||
|
||||
### 8.1 La gouvernance (qui décide de quoi)
|
||||
|
||||
| Question | Règle |
|
||||
|----------|-------|
|
||||
| **De qui sont les données ?** | De la famille (photos, fichiers) / de moi (notes, projets). |
|
||||
| **Qui y a accès ?** | Famille → zone famille. Moi → perso. |
|
||||
| **Qui peut supprimer ?** | Moi (admin). La famille demande, je décide (règle 6.2). |
|
||||
| **Qui est responsable ?** | Moi (unique responsable de l'infra + des données). |
|
||||
|
||||
### 8.2 Les niveaux de sensibilité & règles associées
|
||||
|
||||
| Niveau | Exemple | Règle |
|
||||
|--------|---------|-------|
|
||||
| 🟢 Publique | Films, musique | Accès libre |
|
||||
| 🟡 Privée | Photos, notes, mail | Zone famille/perso, pas de cloud |
|
||||
| 🔴 Critique | Mots de passe | Chiffré, accès moi seul, backup dédié |
|
||||
|
||||
### 8.3 La politique de suppression & archivage
|
||||
|
||||
> **C'est le point que j'avais oublié** — et c'est essentiel pour la **qualité** (pas de bruit) et la **pérennité** (pas de saturation).
|
||||
|
||||
| Type | Règle |
|
||||
|------|-------|
|
||||
| **Photos** | Jamais supprimées (patrimoine). Dédup + archive des redondantes. |
|
||||
| **Notes** | Suppression si obsolète (je décide, en revue hebdo). |
|
||||
| **Mail** | Archivage après 2 ans, suppression si spam/doublon. |
|
||||
| **NVR** | Rétention limitée (ex. 30 jours) → suppression auto. |
|
||||
| **Média** | Suppression si inactif > 2 ans (je décide). |
|
||||
|
||||
> **Principe** : **tout a une fin de vie**, sauf le patrimoine. Une donnée sans fin de vie = du bruit qui noie la valeur.
|
||||
|
||||
### 8.4 La continuité (si « il m'arrive quelque chose »)
|
||||
|
||||
> **C'est l'engagement 5, sa partie la plus sérieuse.** Mes données doivent survivre à **moi**.
|
||||
|
||||
| Mesure | Détail |
|
||||
|--------|--------|
|
||||
| **Accès famille** | La famille sait **où** sont les données + **comment y accéder** (doc simple). |
|
||||
| **Mots de passe** | Vaultwarden : accès d'urgence famille (emergency access). |
|
||||
| **Documentation** | Ce dossier + les docs = source de vérité **lisible par un tiers**. |
|
||||
| **Backup offsite** | 218play = copie qui survit à un incendie du NAS. |
|
||||
| **Test** | La famille sait restaurer (testé 1×). |
|
||||
|
||||
> **Objectif** : si je disparais demain, ma famille a **accès** à ses photos, ses fichiers, ses mots de passe, et sait **réparer** le système de base. C'est la **pérennité** au sens fort.
|
||||
|
||||
---
|
||||
|
||||
## 9 — Mesure & amélioration continue
|
||||
|
||||
> **Statut** : ✅ Cadré — sans mesure, pas de culture (juste de l'intention).
|
||||
|
||||
### 9.1 Les KPI (à mesurer mensuellement)
|
||||
|
||||
| KPI | Définition | Cible (1 an) |
|
||||
|-----|------------|--------------|
|
||||
| **Trouvabilité** | % de recherches « trouvées du 1er coup » | > 90% |
|
||||
| **Structure** | % de données avec métadonnées complètes | > 70% (actifs P0) |
|
||||
| **Indexation** | % des actifs P0 montés à L3 (dans Qdrant) | > 80% |
|
||||
| **Pérennité** | Backup 3-2-1 vérifié (restauration testée) | 100% (trimestriel) |
|
||||
| **Dispersion** | Nombre de silos (apps de notes, emplacements) | 1 par actif |
|
||||
| **Sobriété** | Conso idle des 4 boîtiers 24/7 | stable (Freebox+J5040+G9 ~30 W + PC IA ~80-100 W) |
|
||||
| **Dégafamisation** | % de services GAFAM remplacés | > 80% |
|
||||
|
||||
### 9.2 Le cycle PDCA
|
||||
|
||||
```
|
||||
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
|
||||
│ PLAN │──►│ DO │──►│ CHECK │──►│ ACT │
|
||||
│ Définir │ │ Appliquer│ │ Mesurer │ │ Améliorer│
|
||||
│ la cible │ │ les │ │ les KPI │ │ (boucle) │
|
||||
│ du mois │ │ réflexes │ │ │ │ │
|
||||
└──────────┘ └──────────┘ └──────────┘ └──────────┘
|
||||
```
|
||||
|
||||
| Étape | Fréquence | Action |
|
||||
|-------|-----------|--------|
|
||||
| **Plan** | mensuel | Fixer 1-2 cibles (ex. « structurer les notes ») |
|
||||
| **Do** | quotidien | Appliquer les 6 réflexes (partie 5) |
|
||||
| **Check** | mensuel | Mesurer les KPI (9.1) |
|
||||
| **Act** | trimestriel | Ajuster les conventions, les automatisations |
|
||||
|
||||
### 9.3 Le « data health check » trimestriel
|
||||
|
||||
| Vérification | Outil |
|
||||
|--------------|-------|
|
||||
| Backup restaurable ? | Test restauration |
|
||||
| Disques < 80% ? | `df` / Beszel |
|
||||
| Services up ? | Beszel |
|
||||
| KPIs au vert ? | Tableau 9.1 |
|
||||
| Docs à jour ? | Ce dossier + état de l'art |
|
||||
|
||||
---
|
||||
|
||||
## 10 — Roadmap « prendre le large »
|
||||
|
||||
> **Statut** : 🟡 **Plan phasé** — calé sur les phases **R5** du dossier (plan canonique). Ce guide n'ajoute que les **actions spécifiques à la culture de la donnée** ; les actions « machine » sont dans R5 et **non dupliquées** ici.
|
||||
|
||||
### 10.0 Règle de lecture
|
||||
|
||||
- **R5 = plan canonique** (machine) : fondations (edge + cœur + IA + 3-2-1), cœur famille, finitions.
|
||||
- **Cette partie = couche culture** : elle référence R5 par ID et n'ajoute que ce qui est **spécifique à la donnée** (état des lieux, structuration, indexation, gouvernance).
|
||||
- **Fondations d'abord** : on ne structure pas des données sur un système sans backup (risque #1 R7).
|
||||
- **On ne passe à l'étape N+1 qu'après validation de l'étape N.**
|
||||
- **Statut** : ⬜ à faire → 🟡 en cours → ✅ validé.
|
||||
|
||||
### 10.1 Étape 1 — Fondations + état des lieux
|
||||
|
||||
**R5** : **Phase 0** (réparer backup USB, thermique Freebox, installer J5040 edge + G9, migrer l'IA, 3-2-1, G7 spare).
|
||||
|
||||
**Ajout culture** : l'état des lieux complet (la partie 2 du guide est préliminaire).
|
||||
|
||||
| # | Action | Dépendance | Critère de succès |
|
||||
|---|--------|------------|-------------------|
|
||||
| C1.1 | **Scanner tous les supports** (volumes, formats, counts) | R5 Ph0 | Partie 2 complétée (plus de `🔎`) |
|
||||
| C1.2 | **Cartographier les silos** (chaque actif → 1 endroit) | C1.1 | Matrice « 1 actif = 1 endroit » |
|
||||
| C1.3 | **Qualifier** (sensibilité, valeur, priorité) | C1.1 | Inventaire annoté (partie 2.3) |
|
||||
|
||||
**Statut** : ⬜
|
||||
> **Sans R5 Phase 0, la culture repose sur du sable** (pas de backup = pas de pérennité). **Sans C1, on structure à l'aveugle.**
|
||||
|
||||
### 10.2 Étape 2 — Cœur famille + structuration des actifs P0
|
||||
|
||||
**R5** : **Phase 1** (installer le G9, migrer photos/fichiers/mots de passe/média/notes).
|
||||
|
||||
**Ajout culture** : la structuration (L0→L3) des actifs P0, qui ne peut se faire **qu'après** la migration sur le G9.
|
||||
|
||||
| # | Action | Dépendance | Critère de succès |
|
||||
|---|--------|------------|-------------------|
|
||||
| C2.1 | **Notes** : 1 app de référence (trancher R6.2) | R5 Ph1 | Notes dans 1 seul endroit |
|
||||
| C2.2 | **Notes** : indexation (→ Qdrant) | C3.1, C2.1 | Effi répond sur mes notes |
|
||||
| C2.3 | **Projets/docs** : indexation (→ Qdrant) | C3.1 | Effi répond sur mes projets |
|
||||
| C2.4 | **Photos** : indexation (embeddings) | R5 Ph1 (1.1) | Recherche sémantique photos |
|
||||
|
||||
**Statut** : ⬜
|
||||
> **C'est là que la culture devient tangible** : Effi commence à « connaître » ma vie.
|
||||
|
||||
### 10.3 Étape 3 — Fiabiliser la chaîne IA
|
||||
|
||||
**R5** : **Phase 0** (0.5 — migrer l'IA sur le PC IA, power limit, mesurer conso) + **Phase 2** (finitions IA).
|
||||
|
||||
**Ajout culture** : valider que le pipeline L0→L3 (partie 4) est **opérationnel de bout en bout**.
|
||||
|
||||
| # | Action | Dépendance | Critère de succès |
|
||||
|---|--------|------------|-------------------|
|
||||
| C3.1 | **Pipeline testé** : 1 doc → OCR → Qdrant → Effi répond | R5 Ph0 (0.5) | Effi répond sur un doc nouveau |
|
||||
|
||||
**Statut** : ⬜
|
||||
|
||||
### 10.4 Étape 4 — Automatiser les réflexes
|
||||
|
||||
**Ajout culture** : les 6 réflexes (partie 5) portés par n8n.
|
||||
|
||||
| # | Action | Dépendance | Critère de succès |
|
||||
|---|--------|------------|-------------------|
|
||||
| C4.1 | **n8n** : watcher `/inbox/` → indexation | C2.2 | Nouvelle note indexée auto |
|
||||
| C4.2 | **n8n** : backup quotidien + hebdo | R5 Ph0 | 3-2-1 automatique |
|
||||
| C4.3 | **n8n** : alertes (disque, services) | — | Alertes fonctionnelles |
|
||||
| C4.4 | **Rituels** : inbox + revue hebdo en place | — | 2 semaines de pratique |
|
||||
|
||||
**Statut** : ⬜
|
||||
|
||||
### 10.5 Étape 5 — Gouvernance & continuité
|
||||
|
||||
**Ajout culture** : les règles (partie 8) en place et testées.
|
||||
|
||||
| # | Action | Dépendance | Critère de succès |
|
||||
|---|--------|------------|-------------------|
|
||||
| C5.1 | **Politique de suppression** écrite + appliquée | C1.2 | Règles de fin de vie actives |
|
||||
| C5.2 | **Sécurité** vérifiée (VPN, profils, 2FA) | R5 Ph1 | Accès contrôlés fonctionnels |
|
||||
| C5.3 | **Continuité** : doc famille + test restauration | R5 Ph0 | Famille sait restaurer |
|
||||
| C5.4 | **KPI** : tableau de mesure en place | C2.x | 1er mois de KPI mesurés |
|
||||
|
||||
**Statut** : ⬜
|
||||
|
||||
### 10.6 Vue d'ensemble
|
||||
|
||||
```
|
||||
R5 Ph0 ─► R5 Ph1 ─► R5 Ph2
|
||||
(fonda- (cœur (finitions)
|
||||
tions) famille)
|
||||
│ │ │
|
||||
▼ ▼ ▼
|
||||
C1 C2 C3 ← couche culture (ce guide)
|
||||
(état (structurer (pipeline
|
||||
des P0) testé)
|
||||
lieux)
|
||||
│
|
||||
▼
|
||||
C4 (automatiser) ─► C5 (gouvernance & continuité)
|
||||
```
|
||||
|
||||
> **Lien avec R5** : R5 est le **plan canonique** (machine). Les étapes C1-C5 sont la **couche culture** qui s'y greffe — C1 après Ph0, C2 après Ph1, C3 après Ph0 (0.5), C4/C5 transverses. **Un seul plan, deux couches** : plus de duplication, plus de divergence.
|
||||
|
||||
---
|
||||
|
||||
## Annexe A — Catalogue des actifs de données
|
||||
|
||||
> Version consolidée de la partie 2.3. À compléter au scan live (D1).
|
||||
|
||||
| ID | Actif | Zone | Machine | Volume | Format | Niveau | Sensibilité | Valeur | Prio IA | Statut |
|
||||
|----|-------|------|---------|--------|--------|--------|-------------|--------|---------|--------|
|
||||
| D1 | Photos famille | Famille | xpenology→G9 | 🔎 | JPG/HEIC | L1 | 🟡 | 🔴 | P0 | 🟡 |
|
||||
| D2 | Mots de passe | Famille | xpenology→G9 | — | JSON | L2 | 🔴 | 🔴 | P2 | 🟡 |
|
||||
| D3 | Notes | Perso | dispersé→G9 | 🔎 | MD/DB | L1-L2 | 🟡 | 🟠 | P0 | 🟡 |
|
||||
| D4 | Fichiers famille | Famille | xpenology→G9 | 🔎 | divers | L0-L2 | 🟡 | 🟠 | P1 | 🟡 |
|
||||
| D5 | Projets/docs | Perso | Gitea→G9 | 🔎 | MD/code | L2 | 🟡 | 🟠 | P0 | 🟡 |
|
||||
| D6 | Média | Famille | USB→G9 | 20.5 To | MKV | L0 | 🟢 | 🟡 | P3 | 🟡 |
|
||||
| D7 | Modèles LLM | Perso | folzo-corp | 98 Go | GGUF | L3 | 🟢 | 🟡 | — | 🟡 |
|
||||
| D8 | Mail | Famille | Gmail→local | 🔎 | EML | L0-L1 | 🟡 | 🟠 | P1 | 🟠 |
|
||||
| D9 | Agenda/contacts | Famille | Google→local | 🔎 | ICS/VCF | L2 | 🟡 | 🟠 | P2 | 🟠 |
|
||||
| D10 | Enregistrements NVR | Famille | Reolink | 🔎 | MP4 | L0 | 🟡 | ⚪ | P3 | 🟡 |
|
||||
| D11 | Musique | Famille | à localiser | 🔎 | MP3/FLAC | L0-L2 | 🟢 | 🟡 | P3 | 🟡 |
|
||||
| D12 | Messagerie | Famille | WhatsApp/iMsg | 🔎 | binaire | L0 | 🟡 | ⚪ | P3 | 🟡 |
|
||||
|
||||
---
|
||||
|
||||
## Annexe B — Conventions de nommage & métadonnées
|
||||
|
||||
### B.1 Nommage des fichiers
|
||||
|
||||
| Règle | Format | Exemple |
|
||||
|-------|--------|---------|
|
||||
| **Date** | `AAAAMMJJ` (ISO) | `20260930` |
|
||||
| **Description** | kebab-case, 3-6 mots | `recette-tarte-tatin` |
|
||||
| **Extension** | d'origine | `.pdf` |
|
||||
| **Complet** | `AAAAMMJJ-description.ext` | `20260930-recette-tarte-tatin.pdf` |
|
||||
|
||||
**Interdits** : `screenshot 1.png`, `nouveau dossier`, `copie de`, `final (2)`.
|
||||
|
||||
### B.2 Dossiers (structure)
|
||||
|
||||
```
|
||||
/data/
|
||||
├── famille/
|
||||
│ ├── photos/AAA/ ← par année
|
||||
│ ├── fichiers/
|
||||
│ │ ├── admin/ ← factures, contrats
|
||||
│ │ ├── sante/
|
||||
│ │ └── projets/
|
||||
│ ├── media/
|
||||
│ └── musique/
|
||||
├── perso/
|
||||
│ ├── notes/ ← 1 source de vérité
|
||||
│ ├── projets/
|
||||
│ └── documents/
|
||||
├── vault/
|
||||
└── backup/
|
||||
```
|
||||
|
||||
### B.3 Tags (pour la recherche + l'IA)
|
||||
|
||||
| Tag | Usage |
|
||||
|-----|-------|
|
||||
| `#personne/<nom>` | Personnes (photos, notes) |
|
||||
| `#lieu/<lieu>` | Lieux |
|
||||
| `#projet/<nom>` | Projets |
|
||||
| `#type/<type>` | admin, sante, recette, … |
|
||||
| `#statut/<statut>` | actif, archive, à-trier |
|
||||
| `#sensibilité/<niveau>` | publique, privee, critique |
|
||||
|
||||
---
|
||||
|
||||
## Annexe C — Schéma de métadonnées (proposé)
|
||||
|
||||
> Pour chaque actif important (doc, photo, note). Stocké en front-matter (Markdown) ou EXIF (photos).
|
||||
|
||||
```yaml
|
||||
---
|
||||
id: 20260930-recette-tarte-tatin
|
||||
titre: Recette tarte tatin
|
||||
auteur: Jean-Henry
|
||||
date_creation: 2026-09-30
|
||||
date_modification: 2026-09-30
|
||||
type: recette
|
||||
tags:
|
||||
- type/recette
|
||||
- statut/actif
|
||||
sensibilite: privee
|
||||
zone: famille
|
||||
source: capture-manuelle
|
||||
ia:
|
||||
indexe: true
|
||||
embedding: qdrant/notes
|
||||
date_indexation: 2026-09-30
|
||||
---
|
||||
```
|
||||
|
||||
| Champ | Obligatoire | Rôle |
|
||||
|-------|-------------|------|
|
||||
| `id` | ✅ | Identifiant unique (nommage) |
|
||||
| `titre` | ✅ | Recherche |
|
||||
| `date_creation` | ✅ | Pérennité / tri |
|
||||
| `type` | ✅ | Classement |
|
||||
| `tags` | ✅ | Recherche + IA |
|
||||
| `sensibilite` | ✅ | Gouvernance |
|
||||
| `zone` | ✅ | Isolation |
|
||||
| `ia.indexe` | ✅ | Suivi de l'indexation |
|
||||
|
||||
---
|
||||
|
||||
## Annexe D — Glossaire
|
||||
|
||||
| Terme | Définition |
|
||||
|-------|------------|
|
||||
| **Culture de la donnée** | Système de croyances + pratiques qui traite la donnée comme un actif. |
|
||||
| **Souveraineté** | Maîtrise totale de mes données (local, contrôle, export). |
|
||||
| **Dégafamisation** | Remplacer les services GAFAM par des équivalents locaux. |
|
||||
| **Donnée non structurée** | Donnée sans format imposé (photo, audio, texte libre) — le gisement. |
|
||||
| **L0→L3** | Hiérarchie de structure : brut → textualisé → structuré → sémantique. |
|
||||
| **RAG** | Retrieval-Augmented Generation (l'IA répond sur MES données). |
|
||||
| **Embedding** | Représentation vectorielle d'une donnée (bge-m3). |
|
||||
| **Qdrant** | Base de données vectorielle (stocke les embeddings). |
|
||||
| **3-2-1** | 3 copies, 2 supports, 1 offsite (backup). |
|
||||
| **PDCA** | Plan-Do-Check-Act (amélioration continue). |
|
||||
| **KPI** | Indicateur clé de performance. |
|
||||
| **G9** | HP Pro Mini 400 G9 (futur NAS, cœur famille). |
|
||||
| **Effi / Jarvis** | Mon assistant IA personnel, qui « connaît » ma vie grâce à mes données. |
|
||||
| **CAS** | Certificat d'Aptitude Spéciale (IA & transformation digitale). |
|
||||
|
||||
---
|
||||
|
||||
## Changelog
|
||||
|
||||
| Date | Version | Changement |
|
||||
|------|---------|------------|
|
||||
| 30/09/2026 | v1.0 | Création du guide — manifeste, fondations, état des lieux (préliminaire), architecture, pipeline IA, habitudes, famille, infra, gouvernance, mesure, roadmap, annexes. |
|
||||
| 30/09/2026 | v1.1 | Renommage sans date (doc vivant) ; suppression du périmètre pro CASU (2 zones, plus de zone isolée) ; roadmap réalignée sur R5 (plan canonique, couche culture C1-C5, plus de duplication) ; typo « s'il m'arrive ». |
|
||||
Reference in New Issue
Block a user