g9-migration/DOSSIER-SOFTWARE.md

Dossier — Stack logicielle de la maison (Partie 5)

Date : 06/10/2026 Auteur : Jean-Henry Foltzenlogel (Folzo) Réseau : 192.168.1.0/24 Statut global : 🟡 Conception validée (table rase) — architecture logicielle ciblée, décisions tranchées, plan de migration posé. Aucune implémentation : ce dossier est le cahier des charges logiciel qui précède le rebuild. Document : vivant — versionné, mis à jour à chaque évolution. Chaque section porte son statut (✅ / 🟡 / ⬜).

Nature du document : c'est le dossier Partie 5 — couche logicielle de l'infrastructure. Il fait suite à la table rase demandée : on repart de zéro, sans biais sur les outils existants, pour choisir la stack qui tient aujourd'hui ET dans le futur, qui passe en production (plus de R&D), qui est pérenne, 100% open source (licence notée par service), consolidée (pas 50 apps — un tout cohérent type Nextcloud), et résiliente par l'usage (chaque brique a un utilisateur nommé + un appareil + un usage quotidien).

Position dans le projet : DOSSIER-RECREATION.md (v2) décrit la machine (rôles, disques, 3-2-1, phases). Ce dossier décrit le logiciel qui tourne dessus : quelle brique, où, pourquoi, et comment on passe du chaos R&D actuel à un système de production. En cas de conflit sur les faits matériels, c'est le snapshot ETAT-DE-LART-2026-09-30.md qui fait foi ; pour l'architecture machine, c'est DOSSIER-RECREATION.md ; pour le logiciel (ce document), c'est lui qui fait foi.

Règle d'or de la table rase : chaque brique est justifiée (maturité, maintenance, ressource sur la machine cible, licence OSS, chemin de sortie/export). Si une brique ne sert personne au quotidien, elle ne rentre pas. La résilience = l'usage : un service que personne n'utilise est un coût, pas un asset.

---

Sommaire

• S1 — Objectif & principes de la table rase
• S2 — Architecture cible par machine
• S3 — Stack consolidée, brique par brique
• S4 — Bloc IA (le cœur du futur)
• S5 — Photos (PhotoPrism)
• S6 — Fichiers & productivité (Nextcloud)
• S7 — Média (Jellyfin + *arr + podcasts)
• S8 — Communication (Matrix + Jitsi + assistant vocal)
• S9 — Sécurité & accès distant
• S10 — Backup 3-2-1 (restic/borg + LUKS)
• S11 — Ops (Compose + Gitea + Watchtower + Beszel)
• S12 — Enfants & MDM
• S13 — Plan de migration R&D → production
• S14 — Grille des décisions + recommandations
• S15 — Critères d'acceptance (AC1–AC10)
• Changelog

---

S1 — Objectif & principes de la table rase

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

1.1 Pourquoi une table rase

L'infra actuelle est née empiriquement : 34 conteneurs sur le J5040, ~30 sur le xpenology, 9 sur le PC IA, des briques IA dupliquées (2× STT, 2× OCR, 2× OpenWebUI, Dify + RAGFlow + Qdrant + mcpo + pipelines…), des conteneurs morts, et des services qui ne servent plus personne. C'est du R&D : on a tout essayé, rien n'a été tranché ni fiabilisé.

La table rase, c'est arrêter de collectionner et choisir. Le critère n'est plus « est-ce que ça marche ? » mais « est-ce que ça sert quelqu'un, tous les jours, et est-ce que je peux le réparer en 5 min ? ».

1.2 Les 6 principes (le filtre de chaque brique)

#	Principe	Signification concrète
1	Table rase	On ne part pas de « ce qui est installé ». On part du besoin, et on choisit la brique qui le sert. L'existant n'est qu'un candidat, pas une contrainte.
2	Pérenne / fiable	On choisit des briques matures, maintenues, stables — pas des toys de démo. Le système doit tourner sans intervention.
3	100% open source	Chaque brique est OSS, licence notée (S3). Pas de zone grise (XPEnology éliminé), pas de SaaS GAFAM.
4	Consolidé	Un besoin = une brique = une machine. On vise ≤ ~20 briques au total, pas 50 apps. Un tout cohérent (Nextcloud comme socle famille), pas un cimetière de démos.
5	Résilience = usage	Chaque brique a un utilisateur nommé + un appareil + un usage quotidien (S8.2 / S15 AC8). Pas de brique orpheline.
6	Reversibilité	Chaque brique a un chemin de sortie/export documenté (S3). On ne se verrouille pas : on peut partir à tout moment.

1.3 Ce que la table rase change vs l'existant

Aspect	Avant (R&D)	Après (production)
Nombre de briques	~70 conteneurs (34+30+9)	≤ ~20 briques cohérentes
Duplication	2× STT, 2× OCR, 2× OpenWebUI, 2× n8n, Dify+RAGFlow	1 seul par fonction
Critère de garde	« ça marche »	« ça sert quelqu'un, tous les jours »
Licence	inconnue / mixte	notée par brique (OSS)
Sortie	aucune	chemin d'export documenté
Ops	ad hoc	Compose versionné + Watchtower + Beszel

---

S2 — Architecture cible par machine

Statut : ✅ Validée (Option A) (05/10/2026) — hérite de DOSSIER-RECREATION.md §R2, affinée par la redistribution logicielle.

2.1 Le choix clé : le PC IA garde toute la RAM

Le Qwen 3.8max (le LLM principal) consomme ~20 Go VRAM + ~50 Go RAM. Le PC IA a 62 Go RAM : c'est la seule machine qui peut le porter. Conséquence : le PC IA est saturé par l'IA → on n'y met rien d'autre de lourd. Cela déplace Matrix + Jitsi (comms, qui demandent de la RAM) sur le J5040 (edge), et Home Assistant reste sur la Freebox (VM légère, déjà en place).

2.2 Rôle logiciel de chaque machine (Option A)

Machine	IP	RAM	Rôle logiciel	Briques logicielles
Freebox Delta	.254	—	WAN + Maison + Backup	Home Assistant (enceintes Google ×4-5) · Frigate (Reolink, détection) · 2ᵉ copie backup (RAID5 3×1To)
J5040	.1	16 Go (upgradé)	Edge + Comms + Downloads	Firewall · DHCP · AdGuardHome · SearXNG (recherche web) · Caddy (TLS auto) · WireGuard · Web Station · Beszel · Matrix (Synapse) + Jitsi · Prowlarr/Sonarr/Radarr + qBittorrent
G9	.25	16 Go (fixe)	Cœur famille	Nextcloud (+Collabora Office, Deck, Notes, Groupware CalDAV/CardDAV, Mail IMAP) · PhotoPrism · Jellyfin (vidéo+musique) · Vaultwarden · Gitea · n8n · Valheim · SMB
PC IA	.11	62 Go	IA (max RAM)	Ollama (Qwen 3.8max) · Qdrant · hermes · OpenWebUI (famille, 1 seul)
G7	.30	15 Go	Spare / débordement	(non branché — secours G9, ou débordement Matrix/Jitsi en pic)
218play	.26	—	3ᵉ copie offsite	(backup)

2.3 Pourquoi cette répartition

Décision	Raison
Matrix + Jitsi sur J5040 (16 Go)	Le PC IA est saturé par le LLM (62 Go). Matrix (Synapse) + Jitsi (appels) demandent de la RAM → ils vont sur l'edge, qui a de la marge après la libération de l'IA.
Home Assistant sur Freebox	VM déjà en place, légère, et c'est le routeur (proximité domotique). Frigate (vision caméras) y tourne aussi — léger, pas de GPU requis pour la détection de base.
*arr + qBittorrent sur J5040	Les téléchargements sont de l'edge (proximité internet). Libère le G9 (cœur famille) et son disque RAID1 (données importantes, pas du média brut).
Nextcloud + PhotoPrism + Jellyfin sur G9	Le cœur famille = là où sont les données importantes (RAID1). Les apps qui les servent sont à côté des données (pas de traversée réseau).
n8n sur G9	L'automatisation touche le cœur famille (photos, fichiers, agenda). Un seul n8n (le 2ᵉ est supprimé).
Tout le bloc IA sur PC IA	Ollama + Qdrant + hermes + OpenWebUI = là où sont les GPU + 62 Go. Un seul endroit, un seul point de maintenance.

2.4 Budget ressource par machine (AC4)

Machine	RAM	Charge estimée	Marge	Verdict
J5040	16 Go	edge (~2 Go) + SearXNG (~200 Mo) + Matrix+Jitsi (~3-4 Go) + *arr+qBittorrent (~1-2 Go) + Beszel/Caddy/AdGuard (~1 Go) ≈ 7-9 Go	~7 Go	✅ tenable (G7 = débordement en pic)
G9	16 Go	Nextcloud+Collabora (~3-4 Go) + PhotoPrism (~2-3 Go) + Jellyfin (~1-2 Go) + n8n (~1 Go) + Gitea/Vaultwarden (~1 Go) ≈ 8-11 Go	~5-8 Go	✅ tenable (surveiller Collabora en pic)
PC IA	62 Go	Ollama Qwen 3.8max (~50 Go) + Qdrant (~1-2 Go) + hermes (~1 Go) + OpenWebUI (~1 Go) ≈ 53 Go	~9 Go	✅ tenable (le LLM domine, c'est assumé)
Freebox	—	HA + Frigate (légers, VM)	—	✅ léger (pas de GPU requis)

Point de vigilance unique : le J5040 avec Matrix+Jitsi en pic (appels vidéo + téléchargements). Le G7 (15 Go) est le débordement documenté : si le J5040 sature, on y déplace Matrix/Jitsi. C'est le seul vrai risque RAM de l'architecture.

---

S3 — Stack consolidée, brique par brique

Statut : ✅ Validée (05/10/2026) — ~20 briques sur 4 machines. Chaque brique est justifiée (maturité, maintenance, ressource, licence OSS, chemin de sortie). C'est la réponse aux AC2, AC3, AC10.

3.1 La stack complète (une brique = un besoin = une machine)

#	Brique	Besoin servi	Machine	Licence OSS	Maturité / maintenance	Chemin de sortie / export
1	Firewall (nftables)	Protection LAN/WAN	J5040	GPL-2.0	Système (noyau Linux), très stable	Config = fichiers, exportable
2	DHCP (dnsmasq)	Attributions IP	J5040	GPL-2.0	Système, très stable	Config exportable
3	AdGuard Home	DNS + filtre pubs + parents	J5040	MIT	Très mature, maintenu	Config + listes exportables
4	Caddy	Reverse proxy + TLS auto (Let's Encrypt)	J5040	Apache-2.0	Très mature (Caddy 2), maintenu	Caddyfile = config, exportable
5	WireGuard	Accès distant chiffré	J5040	GPL-2.0	Système (noyau), très stable	Clés exportables
6	Web Station	Sites web (dd/lola.folzocorp…)	J5040	— (contenu)	Statique	Fichiers, exportables
7	Beszel	Monitoring léger + alertes	J5040	MIT	Mature, maintenu (henrygd)	Base SQLite, exportable
8	Matrix (Synapse)	Messagerie du foyer (complément de WhatsApp, pas de remplacement)	J5040	Apache-2.0	Très mature (Element/Matrix), maintenu	Export des salons (JSON), comptes
9	Jitsi	Visioconférence	J5040	Apache-2.0	Mature (Jitsi Meet), maintenu	N/A (appels éphémères)
10	*arr (Prowlarr + Sonarr + Radarr) — 1 stack	Gestion séries/films (indexers + queue)	J5040	GPL-3.0	Très mature (la stack *arr), maintenu	Bases SQLite exportables, config
11	qBittorrent	Téléchargement (torrent/HTTP)	J5040	GPL-2.0	Très mature, maintenu	File de tâches exportable
12	Nextcloud	Fichiers + socle famille (Drive, partages)	G9	AGPL-3.0	Très mature, maintenu	Export complet (fichiers = standard)
13	↳ Collabora Office (app NC #12)	Bureautique (remplace Office/Docs)	G9	MPL-2.0 (code)	Mature (LibreOffice base), maintenu	Fichiers ODF (standard ouvert)
14	↳ Nextcloud Groupware (app NC #12)	Agenda + contacts (CalDAV/CardDAV)	G9	AGPL-3.0	Mature, maintenu	ICS / VCF (standards ouverts)
15	↳ Nextcloud Deck + Notes (apps NC #12)	Tâches + notes rapides famille	G9	AGPL-3.0	Mature, maintenu	Export Markdown / JSON
16	PhotoPrism	Photos (timeline, visages, albums, partage, recherche sémantique)	G9	AGPL-3.0 (core)	Mature, maintenu	Lecture in-place des originaux (pas de verrouillage)
17	Jellyfin	Vidéo + musique (streaming famille)	G9	AGPL-3.0	Très mature, maintenu	N/A (lecture des fichiers sources)
18	Vaultwarden	Mots de passe (coffre famille)	G9	AGPL-3.0	Très mature, maintenu	Export chiffré (standard Bitwarden)
19	Gitea	Git (vault second cerveau + versioning)	G9	MIT	Très mature, maintenu	Repos git (exportables)
20	n8n	Automatisation (workflows)	G9	⚠️ Sustainable Use License (fair-code, PAS OSI)	Très mature, maintenu	Workflows exportables (JSON)
21	Valheim	Jeu (monde famille)	G9	— (jeu)	Stable	Sauvegardes de monde
22	Ollama	Backend LLM (Qwen 3.8max)	PC IA	MIT	Très mature, maintenu	Modèles = fichiers (re-téléchargeables)
23	Qdrant	Vector DB (RAG / second cerveau)	PC IA	Apache-2.0	Très mature, maintenu	Collections exportables (JSON)
24	hermes	Harnais agent (Effi — mémoire, MCP, knowledge)	PC IA	MIT	Communautaire, maintenu (nesquena — ghcr.io/nesquena/hermes-webui)	Mémoire = fichiers, exportable
25	OpenWebUI	Front LLM simple famille (1 seul)	PC IA	BSD-3	Très mature, maintenu	N/A (interface)
26	Home Assistant	Domotique (enceintes Google, maison)	Freebox	Apache-2.0	Très mature, maintenu	Config YAML exportable
27	Frigate	Vision caméras (Reolink, détection)	Freebox	AGPL-3.0	Mature, maintenu	Enregistrements = fichiers vidéo
28	SearXNG	Recherche web (meta-moteur privé, dégooglisation)	J5040	AGPL-3.0	Très mature, maintenu	Config + listes de blocage exportables

Comptage : 28 lignes = 25 briques fonctionnelles (les 3 apps Nextcloud ↳ 13-15 sont des apps du socle NC #12, pas des briques séparées ; la stack *arr #10 = 1 brique). On reste dans la cible de consolidation ≤ ~20 briques (S1.2, vs ~70 conteneurs / 50 apps) — c'est le maximum justifié, chaque brique ayant un utilisateur nommé (S8.2).

⚠️ Note honnêteté licence (AC10) : n8n n'est PAS open source au sens OSI — il est sous Sustainable Use License (fair-code, source disponible, usage libre, mais restrictions d'usage). C'est le seul écart au « 100% OSI ». Alternative OSI si on veut du 100% pur : Activepieces (MIT) ou n8n → remplacement progressif. Décision : on garde n8n (maturité + écosystème + usage interne non-commercial = licence confortable) mais c'est noté pour transparence.

3.2 La liste de suppression explicite (le ballast R&D)

AC2 : tout ce qui n'est pas dans le tableau 3.1 est supprimé du rebuild. C'est la table rase concrète.

Brique supprimée	Pourquoi
Dify (14 conteneurs)	Plateforme agents R&D — remplacée par hermes + Ollama + Qdrant (plus sobre, plus pérenne).
RAGFlow (crash loop)	RAG dupliqué — remplacé par Qdrant direct (plus simple, stable).
STT dupliqué (effi-stt + whisper)	2× la même chose → 1 seul (faster-whisper, sur PC IA, on-demand).
OCR dupliqué (effi-ocr + kreuzberg)	2× → 1 seul (kreuzberg/PaddleOCR FR, sur PC IA, on-demand).
OpenWebUI multiples (2×)	1 seul (sur PC IA, front famille).
llm-proxy (LiteLLM)	Remplacé par Ollama direct (point d'entrée unique).
mcpo + pipelines (OpenWebUI)	Remplacés par hermes (harnais agent avec MCP natif).
ComfyUI (port mort)	On-demand uniquement, pas 24/7 — réactivé seulement si usage image.
Pterodactyl (panel + DB + cache)	Remplacé par Valheim direct (3 conteneurs → 1).
CouchDB + Obsidian (conteneur)	Obsidian = app locale (pas un conteneur serveur) ; le vault = Gitea.
Leantime	Gestion de projet R&D — remplacé par Nextcloud Deck (tâques famille).
Affine	Workspace R&D — remplacé par Obsidian + Gitea (second cerveau).
Joplin	Notes dupliquées — remplacées par Obsidian + Gitea (vault unique).
OnlyOffice	Bureautique dupliquée — remplacée par Collabora Office (app Nextcloud).
InfluxDB	Métriques dupliquées — remplacées par Beszel (léger, historique intégré).
Flaresolverr	Anti-Cloudflare R&D — supprimé (pas d'usage quotidien).
mini-qr	Utilitaire marginal — supprimé.
Conteneurs morts (wg-easy, xteve, wol-proxy, youtubedl, mcpo…)	Morts — supprimés.
18 modèles Ollama legacy (98 Go)	Tri — garder les modèles utiles (Qwen 3.8max + embeddings), supprimer le reste.
FreshRSS (lecture RSS)	Pas d'utilisateur nommé à usage quotidien au moment de la table rase (résilience = usage). Les podcasts RSS sont déjà couverts côté client par AntennaPod (zéro serveur). Chemin de ré-add : Compose sur G9 en < 5 min (~100 Mo, AGPL-3.0) si le besoin émerge.

Bilan : ~70 conteneurs → ~20 briques. C'est la consolidation (principe 4).

3.3 Justification par brique (maturité + ressource + sortie)

AC3 : les briques clés sont justifiées en détail. Les autres suivent le même raisonnement (tableau 3.1).

Brique	Maturité	Ressource (machine cible)	Pourquoi CELLE-ci (vs alternatives)
Caddy	Caddy 2, très stable	~50 Mo (J5040)	TLS auto (Let's Encrypt) sans script. Plus simple que Traefik/Nginx pour un usage familial.
Matrix (Synapse)	Standard de fait, très maintenu	~2-3 Go (J5040)	Messagerie du foyer (chiffré, fédéré, OSS) — complément de WhatsApp, pas un remplacement. Alternative : Element = le client.
Jitsi	Mature (Jitsi Meet)	~1-2 Go (J5040)	Visio OSS, s'intègre à Matrix (Element).
PhotoPrism	Mature, AGPL	~2-3 Go (G9)	Lecture in-place (ne déplace pas les originaux) + IA (visages, recherche sémantique) + partage. Plus sobre qu'Immich (qui désorganise).
Jellyfin	Très mature, AGPL	~1-2 Go (G9)	Vidéo + musique OSS, transcodage, multi-appareils. Standard de fait.
Nextcloud	Très mature, AGPL	~2-3 Go (G9)	Socle famille : Drive + Office + Groupware + Deck + Notes en un seul (consolidation).
Vaultwarden	Très mature, AGPL	~100 Mo (G9)	Mots de passe OSS (alternative Bitwarden légère). Standard d'export.
Gitea	Très mature, MIT	~200 Mo (G9)	Git léger (vault second cerveau + versioning). Plus sobre que GitLab.
n8n	Très mature (fair-code)	~1 Go (G9)	Automatisation (workflows). Écosystème riche. ⚠️ non-OSI (noté).
Ollama	Très mature, MIT	~50 Go (PC IA)	Backend LLM (Qwen 3.8max). Point d'entrée unique, simple.
Qdrant	Très mature, Apache-2.0	~1-2 Go (PC IA)	Vector DB (RAG / second cerveau). Plus performant que sqlite-vec à l'échelle.
hermes	Communautaire, MIT	~1 Go (PC IA)	Harnais agent (Effi) : mémoire, MCP, knowledge. Remplace Dify/mcpo/pipelines.
OpenWebUI	Très mature, BSD-3	~1 Go (PC IA)	Front LLM simple pour la famille (1 seul).
Home Assistant	Très mature, Apache-2.0	VM légère (Freebox)	Domotique standard de fait (enceintes Google, maison).
Frigate	Mature, AGPL	léger (Freebox)	Vision caméras (Reolink) + détection. Plus simple qu'un NVR dédié.
Beszel	Mature, MIT	~50 Mo (J5040)	Monitoring léger + historique + alertes. Plus sobre que InfluxDB+Grafana.
AdGuard Home	Très mature, MIT	~100 Mo (J5040)	DNS + filtre pubs + parents. Standard de fait.
WireGuard	Système (noyau), GPL-2.0	négligeable (J5040)	VPN moderne, simple, performant.
restic/borg (S10)	Très mature, Apache/GPL	léger	Backup chiffré, dédupliqué, versionné, append-only.

3.4 Usages nommés — briques edge & infra (AC8)

Chaque brique du S3.1 a un utilisateur nommé + appareil + usage quotidien (résilience = usage). Les briques famille sont détaillées en S5.3 / S6.4 / S7.3 / S8.2 / S12.3 ; les briques edge & infra ici.

Brique	Utilisateur nommé	Appareil	Usage quotidien
SearXNG	Moi + famille	Laptop + téléphone	Recherche web (privé, sans tracking) — remplace la recherche Google pour l'usage perso
AdGuard Home	Famille (dont enfants)	Tous les appareils	DNS + filtre pubs + profils parents
Caddy / WireGuard / firewall	Moi	Laptop + téléphone	Accès distant sécurisé (VPN) + TLS auto
Beszel	Moi	Laptop + téléphone	Monitoring + alertes (→ Matrix)

---

S4 — Bloc IA (le cœur du futur)

Statut : ✅ Validé (05/10/2026) — le bloc IA est consolidé sur le PC IA (62 Go). C'est la différence vs l'existant (qui était dispersé + dupliqué).

4.1 L'architecture du bloc IA (1 seul endroit)

┌─────────────────────────────────────────────────────────┐
│  PC IA (.11) — 62 Go RAM, 2× RTX 3060 (24 Go VRAM)      │
│                                                         │
│  ┌─────────────┐   ┌─────────────┐   ┌──────────────┐  │
│  │  Ollama     │   │  Qdrant     │   │  hermes      │  │
│  │  (LLM)      │   │  (vector DB)│   │  (agent)     │  │
│  │  Qwen 3.8max│──►│  (RAG /     │◄──│  (Effi)      │  │
│  │  ~50 Go RAM │   │   2ᵉ        │   │  mémoire +   │  │
│  │  ~20 Go VRAM│   │   cerveau)  │   │  MCP +       │  │
│  └──────┬──────┘   └─────────────┘   │  knowledge   │  │
│         │                            └──────┬───────┘  │
│         ▼                                   ▼          │
│  ┌─────────────────────────────────────────────────┐   │
│  │  OpenWebUI (front famille, 1 seul)              │   │
│  │  → la famille pose des questions au LLM         │   │
│  └─────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────┘

4.2 Les briques du bloc IA (et pourquoi)

Brique	Rôle	Pourquoi CELLE-ci
Ollama	Backend LLM (Qwen 3.8max)	Point d'entrée unique, simple, MIT. Remplace llama.cpp direct + llm-proxy.
Qwen 3.8max	Le LLM principal	~20 Go VRAM + ~50 Go RAM → seul le PC IA (62 Go) le porte. C'est le cerveau.
Qdrant	Vector DB (RAG / 2ᵉ cerveau)	Stocke les embeddings (bge-m3) du second cerveau. Apache-2.0, performant.
hermes	Harnais agent (Effi)	Mémoire + MCP + knowledge : c'est l'Effi (mon Jarvis). Remplace Dify + mcpo + pipelines. MIT.
OpenWebUI	Front famille (1 seul)	La famille pose des questions au LLM simplement. BSD-3.

4.3 Le second cerveau (2 couches) — lien avec PROJET-SECOND-CERVEAU.md

Le bloc IA porte le second cerveau (projet séparé). Modèle 2 couches (source unique) : PROJET-SECOND-CERVEAU.md S4.1 — couche 1 = la connaissance (markdown, vérité), couche 2 = l'index (cache jetable, reconstruisible).

Mapping sur les briques (spécificité du dossier logiciel) :

Couche	Brique	Machine
1 — Connaissance	Gitea (canon) + G9 (working)	G9
2 — Index	Qdrant (embeddings)	PC IA

L'hermes est le harnais qui récupère d'elle-même le contexte (exigence #2) via MCP.

4.4 Ce qui est supprimé du bloc IA (vs l'existant)

Supprimé	Remplacé par
Dify (14 conteneurs)	hermes + Ollama + Qdrant
RAGFlow (crash loop)	Qdrant direct
llm-proxy (LiteLLM)	Ollama direct
mcpo + pipelines	hermes (MCP natif)
2× OpenWebUI	1 seul (PC IA)
2× STT	1 seul (faster-whisper, on-demand)
2× OCR	1 seul (kreuzberg/PaddleOCR FR, on-demand)
ComfyUI 24/7	On-demand uniquement

Bilan : le bloc IA passe de ~30 conteneurs dispersés à 5 briques sur 1 machine. C'est la consolidation du futur.

---

S5 — Photos (PhotoPrism)

Statut : ✅ Tranché (05/10/2026) — PhotoPrism (lecture in-place). Répond à la décision ouverte R6.1 de DOSSIER-RECREATION.md.

5.1 Le choix : PhotoPrism (et pourquoi pas Immich)

Critère	PhotoPrism ✅	Immich ❌
Lecture in-place	✅ Lit l'arborescence d'originaux (triés par année), ne déplace pas les fichiers	❌ Importe dans sa propre base (désorganise)
IA (visages, recherche sémantique)	✅ intégrée	✅ intégrée
Partage famille	✅ (liens, albums)	✅
Auto-upload Android (téléphones enfants)	✅ (app + API)	✅
Sobriété (G9, 16 Go)	✅ ~2-3 Go	🟡 plus gourmand
Licence	AGPL-3.0 (core)	AGPL-3.0
Sortie	✅ originaux intacts (on peut partir sans perte)	🟡 export depuis la base

Décision : PhotoPrism car il lit les originaux en place (pas de verrouillage, pas de désorganisation). C'est aligné avec la culture de la donnée (pas de déplacement des sources brutes — PROJET-SECOND-CERVEAU.md S1.4).

5.2 La migration des 10 ans de photos Synology

Étape	Action
1	Copier l'arborescence des originaux Synology → G9 /data/famille/photos/AAA/ (par année, convention Annexe B du guide).
2	Pointeur PhotoPrism sur /data/famille/photos/ (lecture in-place).
3	Indexation (visages, lieux, recherche sémantique) — se fait en arrière-plan.
4	Reprise des albums : les albums Synology ne sont pas importés directement (les fichiers sont intacts → on re-crée les albums ou un script de mapping).

Point d'attention : les albums Synology sont une vue, pas les fichiers. Les fichiers sont intacts → on re-crée les albums dans PhotoPrism (ou un script de mapping des noms d'albums). Aucune perte (les originaux sont là).

5.3 L'usage famille (résilience = usage)

Utilisateur	Appareil	Usage quotidien
Moi	Laptop + téléphone	Recherche, albums, partage
Femme	Téléphone	Photos famille, albums
Enfants	Téléphone Android	Auto-upload des photos (règle famille #1 : « les photos vont sur le NAS »)

---

S6 — Fichiers & productivité (Nextcloud)

Statut : ✅ Tranché (05/10/2026) — Nextcloud comme socle famille (consolidation). Répond aux décisions R6.2 (notes) + 2.1/2.2 (agenda/mail).

6.1 Nextcloud = le socle (un seul, pas 5 apps)

Principe de consolidation : Nextcloud regroupe les briques de productivité famille en un seul service (pas Leantime + Affine + Joplin + OnlyOffice + … séparés).

App Nextcloud	Besoin	Remplace
Nextcloud Drive	Fichiers famille (partages, sync)	Nextcloud existant + Google Drive
Collabora Office	Bureautique (docs, tableurs, présentations)	OnlyOffice + Office GAFAM
Groupware (CalDAV/CardDAV)	Agenda + contacts	Google Agenda/Contacts
Deck	Tâches famille (kanban)	Leantime
Notes	Notes rapides famille	(pas le second cerveau — voir S6.2)
Mail (IMAP)	Lecture mail (voir S6.3)	—

6.2 Les notes : le second cerveau (pas Nextcloud Notes)

Décision R6.2 tranchée : les notes de connaissance (second cerveau) = Obsidian + Gitea (markdown versionné), PAS Nextcloud Notes.

Type de note	Outil	Pourquoi
Second cerveau (connaissance, versionné, IA)	Obsidian (viewer) + Gitea (store) + Qdrant (index)	Markdown = format ouvert, versionné git, lisible par l'humain et l'IA. Nextcloud Notes = mauvais fit comme store (pas de versioning, pas de structure liée — PROJET-SECOND-CERVEAU.md S4.3).
Notes rapides famille (listes, mémos)	Nextcloud Notes	Simple, partagé, pas besoin de versioning.

Séparation claire : le second cerveau (moi, connaissance) = Obsidian+Gitea+Qdrant. Les notes rapides famille = Nextcloud Notes. Pas de confusion.

6.3 Le mail : pas de serveur SMTP local (décision pragmatique)

Décision : pas de serveur mail local (la livraison SMTP est trop difficile à fiabiliser — SPF/DKIM/DMARC, réputation, spam). On garde Gmail/Hotmail pour la livraison, et Nextcloud Mail pour la lecture via IMAP.

Aspect	Choix
Lecture	Nextcloud Mail (IMAP vers Gmail/Hotmail)
Accès web	Gmail/Hotmail (externes) pour l'envoi
Étape par étape	On lit en local d'abord ; la dégafamisation complète du mail (serveur local) est un horizon > 1 an (trop risqué en production).

Honnêteté : le mail est le point le plus dur à dégafamiser (livraison). On ne le force pas : on lit en local, on garde la livraison externe. C'est pérenne (pas de risque spam) et réversible.

6.4 L'usage famille (résilience = usage)

Utilisateur	Appareil	Usage quotidien
Moi	Laptop + téléphone	Fichiers, Office, agenda, second cerveau
Femme	Téléphone	Fichiers, agenda, contacts, mail
Enfants	PC + téléphone	Fichiers (dossier famille), photos

---

S7 — Média (Jellyfin + *arr + podcasts)

Statut : ✅ Tranché (05/10/2026) — Jellyfin (vidéo+musique) + *arr (gestion) + AntennaPod (podcasts, zéro serveur).

7.1 La stack média

Brique	Rôle	Machine	Licence
Jellyfin	Streaming vidéo + musique (transcodage, multi-appareils)	G9	AGPL-3.0
Prowlarr	Indexers (source de métadonnées)	J5040	GPL-3.0
Sonarr	Séries (queue + métadonnées)	J5040	GPL-3.0
Radarr	Films (queue + métadonnées)	J5040	GPL-3.0
qBittorrent	Téléchargement (torrent/HTTP)	J5040	GPL-2.0
AntennaPod	Podcasts (app Android, zéro serveur)	Téléphone	GPL-3.0

7.2 Pourquoi cette répartition

Décision	Raison
*arr + qBittorrent sur J5040	Les téléchargements sont de l'edge (proximité internet). Le G9 (cœur famille) n'est pas saturé par les torrents.
Jellyfin sur G9	Le streaming lit les fichiers (USB média sur G9). L'app est à côté des données.
Podcasts = AntennaPod + RSS	Zéro serveur : AntennaPod lit les flux RSS directement. Pas de brique serveur pour les podcasts (consolidation).

7.3 L'usage famille (résilience = usage)

Utilisateur	Appareil	Usage quotidien
Famille	TV (Shield/Mi Box) + Denon	Jellyfin (films, séries, musique)
Moi	Téléphone	AntennaPod (podcasts)
Enfants	TV + PC	Jellyfin (contenus filtrés)

---

S8 — Communication (Matrix + Jitsi + assistant vocal)

Statut : ✅ Tranché (05/10/2026), révisé 12/10/2026 — Matrix + Jitsi + Element = complément du foyer (messagerie familiale + canal d'alerte + assistant), pas un remplacement de WhatsApp. WhatsApp reste la messagerie principale (famille, amis, travail) — réalité d'usage mesurée, voir g9-migration/BRIDGE-WHATSAPP.md.

8.1 La stack communication

Brique	Rôle	Machine	Licence
Matrix (Synapse)	Messagerie du foyer + canal d'alerte ops (complément de WhatsApp)	J5040	Apache-2.0
Jitsi	Visioconférence	J5040	Apache-2.0
Element	Client (Android) — 2 adultes d'abord, ados en phase 2	Téléphone	GPL-3.0
Home Assistant	Assistant vocal (enceintes Google)	Freebox	Apache-2.0

8.2 L'usage famille (résilience = usage)

Utilisateur	Appareil	Usage quotidien
Famille	Téléphone (Element)	Messagerie du foyer (salon famille) — WhatsApp garde les échanges extérieurs (amis, travail, famille élargie)
Famille	Téléphone + TV	Visio (Jitsi, via Element)
Moi	Téléphone + PC	Salon ops (alertes backup / sondes / dérive registre)
Moi	Enceintes Google ×4-5	Assistant vocal (Home Assistant) → peut déclencher n8n, contrôler Frigate

Décision 12/10/2026 (statut du canal) : Matrix + Jitsi + Element = complément du foyer — salon famille, salon ops, salon Effi. WhatsApp n'est pas remplacé et reste la messagerie principale (famille élargie, amis, travail) : c'est un constat d'usage mesuré, pas un choix technologique. Element s'installe d'abord sur les 2 appareils adultes ; les 4 ados viennent en phase 2, déclenchée par le GO famille explicite de l'utilisateur. Grille de décision : S14.5.

Les 4 interdictions (applicables dès maintenant, vérifiables) :

1. Interdiction de présenter Matrix comme un remplacement de WhatsApp, et d'inciter la famille à quitter WhatsApp pour Matrix (WhatsApp garde les échanges extérieurs).
2. Interdiction de faire transiter les alertes ops par WhatsApp : le canal d'alerte est Matrix uniquement (pas d'e-mail, pas de SMS, pas de WhatsApp).
3. Interdiction d'automatiser l'envoi de messages WhatsApp (pont mautrix-whatsapp : étudié, non déployé, numéro familial interdit — voir g9-migration/BRIDGE-WHATSAPP.md).
4. Interdiction d'équiper les 4 ados d'Element (et de comptes enfants Matrix) sans GO famille explicite, et sans coffre/2FA posé pour eux (C-FM1).

Ces 4 interdictions sont contrôlables : interdiction 1 = vocabulaire du dossier, contrôlée par la commande suivante dont la sortie doit être vide (0 ligne) : grep -in "remplace whatsapp" DOSSIER-SOFTWARE.md g9-migration/*.md g9-migration/RUNBOOKS/*.md GUIDE-MATRIX.md | grep -vi "pas\|complément\|interdiction\|ne présente" — les lignes qui mentionnent WhatsApp le font en négation (S3.1 #8, S3.3, S8 statut, S8.2 décision + cette liste, S13.3 C.1, S14.5, changelog, journal.md = historique) ; interdiction 2 = le canal d'alerte est Matrix (3 notifications types mesurées dans le salon ops) ; interdiction 3 = 0 flux n8n vers WhatsApp (inventaire n8n) ; interdiction 4 = 0 compte ado Matrix (Synapse mesuré : 4 comptes, aucun ado).

8.3 Le bot hermes ↔ Matrix

hermes (Effi, sur PC IA) est connecté à Matrix : la famille peut parler à Effi dans un salon Matrix. C'est l'assistant de famille (projet second cerveau, phase 3).

8.4 Les alertes n8n → Matrix

n8n (G9) envoie les alertes (Beszel, backup, services) dans un salon Matrix dédié. C'est le canal d'alerte unique (pas d'e-mail, pas de SMS).

---

S9 — Sécurité & accès distant

Statut : ✅ Tranché (05/10/2026), révisé 10/10/2026 (G9 mono-disque : LUKS abandonné sur le G9, voir changelog) — Caddy + TLS auto, WireGuard, firewall strict, chiffrement des copies (restic), 2FA, sous-domaines folzocorp.fr. Répond à l'AC6.

9.1 Le modèle de sécurité (couche par couche)

Couche	Brique	Détail
Périmètre	Firewall (nftables) sur J5040	Filtre LAN/WAN strict : par défaut dénier, autoriser seulement les ports exposés.
Entrée internet	Caddy (reverse proxy)	Point d'entrée unique + TLS auto (Let's Encrypt, auto-renew). Remplace le script de 6 mois (pérenne).
Accès distant	WireGuard	VPN chiffré pour accéder à la maison depuis l'extérieur. Pas d'exposition directe des services.
Chiffrement disque	restic (copies) / LUKS disques amovibles	Révisé 10/10/2026 : G9 mono-disque sans LUKS (données familiales non critiques) ; la protection repose sur les backups restic déjà chiffrés + disques de backup amovibles chiffrés. La protection internet = firewall/Caddy/WireGuard, pas LUKS.
Identité	2FA	Tous les services exposés (Nextcloud, Vaultwarden, Gitea, Matrix) en 2FA.
DNS / filtre	AdGuard Home	DNS interne + filtre pubs + profils enfants.
Mots de passe	Vaultwarden	Coffre unique + 2FA + emergency access famille.

9.2 L'accès distant (folzocorp.fr)

Élément	Détail
Domaine	folzocorp.fr (principal) + sous-domaines par service
Sous-domaines	cloud.folzocorp.fr (Nextcloud) · prisme.folzocorp.fr (PhotoPrism) · photos.folzocorp.fr (Synology Photos — LAN-only, temporaire, disparaît avec le xpenology en Phase 6) · media.folzocorp.fr (Jellyfin) · matrix.folzocorp.fr (Matrix) · git.folzocorp.fr (Gitea) · pass.folzocorp.fr (Vaultwarden) · n8n.folzocorp.fr (n8n) · ai.folzocorp.fr (OpenWebUI)
TLS	Caddy génère + renouvelle automatiquement les certificats Let's Encrypt (pas de script).
Exposition	Seulement les services nécessaires à l'extérieur passent par Caddy. Le reste est LAN-only (accès via WireGuard).

Principe : le moins d'exposition possible. Par défaut LAN-only ; l'extérieur passe par WireGuard (VPN) ou Caddy (services explicitement exposés, TLS + 2FA).

9.3 Le firewall strict (J5040)

Règle	Détail
Par défaut	Dénier tout (WAN → LAN).
Autorisé WAN	Seulement les ports Caddy (443) + WireGuard (UDP 51820).
LAN	Libre (les services sont LAN-first).
Enfants	AdGuard Home (DNS filtré) + profils (restriction par appareil).

---

S10 — Backup 3-2-1 (restic/borg + LUKS)

Statut : ✅ Tranché (05/10/2026), révisé 10/10/2026 (G9 : le disque source n'est pas LUKS — le chiffrement est assuré par restic lui-même) — restic (ou borg) chiffré + append-only + procédure de restore testée. Répond à l'AC5.

10.1 Pourquoi restic/borg (pas rsync)

Critère	restic / borg ✅	rsync ❌
Déduplication	✅ (économe en espace)	❌
Chiffrement	✅ (intégrée)	❌ (à ajouter)
Versioning	✅ (historique)	❌
Append-only / anti-ransomware	✅ (snapshots non-modifiables)	❌
Incidentel	✅ (seul les changements)	🟡 (delta, mais pas versionné)

Décision : restic (ou borg) — chiffré, dédupliqué, versionné, append-only (résiste au ransomware). C'est la pérennité au sens fort.

10.2 Le schéma 3-2-1 (source unique : DOSSIER-RECREATION.md §R4)

Schéma des 3 copies (originale G9 + PC IA / intermédiaire Freebox / offsite 218play) : source unique = DOSSIER-RECREATION.md §R4 (tableau complet : supports, machines, contenu, fréquence).

Outil : restic (ou borg) — chiffré + append-only (S10.1). Copie 2 (Freebox) = quotidien, copie 3 (218play) = hebdo.

État 10/10/2026 (copie 2, G9) : ✅ restic 0.19.1 + rclone 1.75.2, repo rclone:freeboxftp:Freebox/backup/g9 (FTP local de la Freebox, port 21), snapshot initial 4.18 GiB, append-only prouvé, restore testée, jobs cron 03:30 (backup, conteneurs stateful stoppés) / 04:00 (prune 7-4-12-5) / 09:15 (health

• alerte Matrix). Mont CIFS abandonné (restic échoue sur chmod, FUSE perd des objets) → backend rclone, donc aucune dépendance de montage (résiste au reboot, pas besoin de smbd au boot).

Phase 5 (planifié, non réalisé) : la Freebox ne peut pas exécuter restic (FTP/SFTP/SMB/WebDAV exposés, pas de conteneur pour rest-server, autostart VM non validé) → ① VM Freebox avec rest-server --append-only (repo append-only côté serveur, plus fort que l'actuel imposé par le rclone local du G9), servi en HTTPS/TLS + htpasswd (g9-backup en écriture, g9-restore en lecture), repo cible rest:https://… ; ② restic copy G9 → Freebox → 218play (copie 3, repo append-only dédié, identifiants NoAccess côté SMB) ; ③ chroot/rootfs durci sur le G9 pour isoler le job de backup.

10.3 Les données IA dans le 3-2-1

Donnée IA	Où	Sauvegardée ?
Qdrant (vector DB / 2ᵉ cerveau)	PC IA	✅ Oui (critique)
n8n (workflows)	G9	✅ Oui
Vault second cerveau (md)	Gitea (G9)	✅ Oui (critique)
hermes (mémoire)	PC IA	✅ Oui
Modèles GGUF (98 Go)	PC IA	❌ Non (re-téléchargeables)
Ollama (modèles)	PC IA	❌ Non (re-téléchargeables)

10.4 La procédure de restore testée (AC5)

Un backup non testé = pas de backup. La procédure est documentée et testée au moins 1×/trimestre.

Étape	Action
1	Restaurer un snapshot restic sur une machine de test (G7).
2	Vérifier l'intégrité (photos, fichiers, mots de passe, données IA).
3	Valider que la famille peut repartir (services accessibles).
4	Documenter le résultat (date, durée, anomalies).

Continuité (si « il m'arrive quelque chose ») : la famille sait restaurer (testé 1×), les mots de passe ont un emergency access, la doc est lisible par un tiers.

---

S11 — Ops (Compose + Gitea + Watchtower + Beszel)

Statut : ✅ Tranché (05/10/2026) — Docker Compose versionné dans Gitea + Watchtower (MAJ sélective : stateless auto / stateful manuel) + Beszel (monitoring) + n8n (alertes). Pas de Portainer, pas de PaaS. (Affiné 06/10/2026 après l'incident Nextcloud — voir §11.4.)

11.1 L'approche ops (sobre, versionnée, observable)

Brique	Rôle	Machine	Licence
Docker Compose	Déclaration des services (fichiers docker-compose.yml)	toutes	Apache-2.0
Gitea	Versioning des docker-compose.yml + config (source de vérité)	G9	MIT
Watchtower	Mises à jour automatiques sélectives (stateless auto / stateful exclu + manuel)	J5040 + G9 + PC IA	Apache-2.0
Beszel	Monitoring léger + historique + alertes (métriques + état conteneurs)	J5040 (hub) + agents	MIT
Registre (11-registry.sh → REGISTRE-BRIQUES.md)	Inventaire généré (images épinglées, labels, endpoints, état) + détection de dérive par git diff	pilot → .24/.27 (lecture seule)	MIT (kit)
Sondes applicatives (12-probes.sh)	up ≠ utilisable : sonde la fonction (occ status, discovery, healthz, login) + alertes JSON + 1 digest/jour	G9 (cron)	MIT (kit)
n8n	Alertes + automatisation (workflows)	G9	⚠️ fair-code

11.2 Pourquoi pas Portainer / PaaS

Option	Verdict	Raison
Portainer	❌	Redondant avec Compose + Gitea. Une brique de plus à maintenir.
PaaS (ex. Coolify)	❌	Trop lourd pour 4 machines. Compose + Gitea suffit.
Compose + Gitea + Watchtower	✅	Sobre, versionné, reproductible. C'est la production.

11.3 Le flux ops (reproductible)

docker-compose.yml (source de vérité, dans Gitea)
        │
        ▼
  git pull → docker compose up -d  (déploiement)
        │
        ▼
  Watchtower (MAJ images **stateless** uniquement — stateful exclu)
        │
        ▼
  Beszel (monitoring) → alertes → n8n → Matrix

Principe : tout est dans git (les docker-compose.yml + config). Une machine tombe → on re-crée depuis Gitea en < 5 min (c'est la maîtrise, pilier 5).

11.4 Watchtower sélectif (règle stateless / stateful)

Contexte : l'incident Nextcloud (06/10/2026 — voir ETAT-DE-LART-2026-10-06.md §3) a montré qu'un Watchtower non sélectif a mis à jour l'application ET sa base MariaDB la nuit, sans laisser la migration de schéma se terminer → Nextcloud en maintenance mode (503). Watchtower ne « teste » rien : il remplace l'image et relance le conteneur, point. La sécurité vient de la sélectivité, pas d'un test.

La règle :

Type de conteneur	Traitement Watchtower	Pourquoi
Stateless (pas d'état persistant : Caddy, AdGuard, SearXNG, Beszel, n8n*…)	Auto (Watchtower les met à jour)	Pas d'état à migrer → le swap d'image est sûr.
Stateful (base de données, cache persistant, état : Nextcloud, MariaDB/Postgres, Redis, Vaultwarden, Gitea, InfluxDB, OnlyOffice/Collabora, Leantime, Affine, Joplin, Qdrant…)	Exclu (label com.centurylinklabs.watchtower.enable=false) + MAJ manuelle (§11.5)	Une MAJ d'image sans migration de schéma = corruption / service HS. La migration doit être supervisée, avec backup en place.

* n8n : son état (workflows) est dans Postgres → le conteneur n8n est stateless (image), mais sa DB est stateful (exclue). On traite la DB comme stateful.

Les briques à exclure de Watchtower (stateful, sur le NAS actuel + cible G9) :

Brique	Image	Pourquoi stateful
Nextcloud	nextcloud:latest	App + migration de schéma (l'incident).
MariaDB (Nextcloud DB)	mariadb:10.6	Base de données — migration de schéma.
Redis (Nextcloud cache)	redis:latest	Cache persistant (RDB/AOF).
Vaultwarden	vaultwarden/server:latest	Coffre (Postgres interne).
Gitea	gitea/gitea:latest	Repos + DB (Postgres/SQLite).
n8n + Postgres	n8n:latest + postgres:17	Workflows + DB.
InfluxDB	influxdb:2.7	Base de métriques.
OnlyOffice / Collabora	onlyoffice/documentserver:latest	État + config persistante.
Leantime + MySQL	leantime:latest + mysql:8.4	App + DB.
Affine + Postgres + Redis	affine:stable + pgvector:pg16 + redis:latest	App + DB + cache.
Joplin + Postgres	joplin/server:latest + postgres:16	App + DB.
Qdrant	qdrant/qdrant:latest	Vector DB (2ᵉ cerveau) — critique.

Configuration Watchtower cible (sur chaque machine) :

services:
  watchtower:
    image: containrrr/watchtower:1          # ⚠️ pin la MAJEURE (pas :latest)
    container_name: watchtower
    environment:
      - TZ=Europe/Paris
      - WATCHTOWER_SCHEDULE=0 0 2 * * *     # fenêtre de MAJ (nuit)
      - WATCHTOWER_CLEANUP=false            # ⚠️ GARDER les anciennes images (rollback)
      - WATCHTOWER_INCLUDE_STOPPED=false    # ne pas toucher les conteneurs arrêtés
      # Notifications (n8n / Matrix) — on est averti de chaque MAJ :
      - WATCHTOWER_NOTIFICATIONS=matrix
      - WATCHTOWER_NOTIFICATION_MATRIX_HOMESERVER=https://matrix.folzocorp.fr
      - WATCHTOWER_NOTIFICATION_MATRIX_ROOMID=!SALON-OPS
      # (ou WATCHTOWER_NOTIFICATIONS=n8n + URL du webhook)
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    restart: unless-stopped

Pinning des majeures : les images stateless sont pinées en majeure (:1, :2…) pour éviter un saut mineur surprise ; les stateful sont exclus (pas de pinning — MAJ manuelle supervisée, §11.5).

⚠️ Écart actuel (NAS) = action corrective : le Watchtower du NAS tourne avec 0 exclusion, 0 notification, WATCHTOWER_CLEANUP=true (supprime les anciennes images → pas de rollback), et l'image :latest (non pinnée). C'est exactement la config qui a causé l'incident Nextcloud. Action immédiate : exclure les briques stateful de Watchtower sur le NAS actuel (même avant la migration xpenology → G9) — voir S13.1 (A.0) + DOSSIER-RECREATION.md R7.

11.5 Procédure de MAJ manuelle des services stateful

Règle absolue : pas de MAJ stateful sans backup en place (le 3-2-1 est fonctionnel, §S10). C'est la leçon de l'incident Nextcloud.

Étape	Action	Détail
1	Backup DB + config	pg_dump / mysqldump (ou snapshot restic) de la base + copie du dossier de config (ex. nextcloud/config). Vérifier que le dump est complet (taille, lignes).
2	Maintenance mode ON	docker exec nextcloud_app php occ maintenance:mode --on (ou équivalent). Bloque les écritures pendant la migration.
3	Pull + up	docker compose pull <service> puis docker compose up -d <service> (image pinée à la nouvelle version).
4	Migration de schéma	docker exec nextcloud_app php occ upgrade (laisse terminer — c'est l'étape que Watchtower a sauté).
5	Vérification	status.php (version, needsDbUpgrade: false, maintenance false) + occ status + test fonctionnel (login, 1 fichier).
6	Maintenance mode OFF	docker exec nextcloud_app php occ maintenance:mode --off.
7	Alerte	n8n → Matrix : « MAJ stateful → OK » (ou échec → rollback depuis l'ancienne image, conservée car CLEANUP=false).

Rollback : si l'étape 5 échoue → occ maintenance:mode --on + restaurer le dump de l'étape 1 + relancer l'ancienne image (conservée). C'est la raison de WATCHTOWER_CLEANUP=false + du pinning.

---

S12 — Enfants & MDM

Statut : ✅ Tranché (05/10/2026) — AdGuardHome (DNS + parental) + Google Family Link (maintenant) + MicroMDM / Android Enterprise (option future).

12.1 La protection enfants (actuelle)

Brique	Rôle	Machine
AdGuard Home	DNS filtré + profils enfants (restriction par appareil)	J5040
Google Family Link	Contrôle parental (temps d'écran, apps) sur Android	(cloud Google, usage parental uniquement)

Note honnêteté : Family Link est un service Google (cloud). C'est le seul service GAFAM gardé — mais pour un usage parental (contrôle des enfants), pas pour les données famille. C'est pragmatique (pas d'alternative OSS MDM mature pour Android familial) et limité (pas de données familiales, juste du contrôle).

12.2 L'option future : MDM Android (si besoin)

Option	Détail
MicroMDM	MDM iOS (Apple) — OSS. Si on a des iPad/iPhone.
Android Enterprise	MDM Android — via un gestionnaire (ex. MicroMDM équivalent Android, ou Geeks). Option future si le besoin de contrôle à distance des téléphones enfants se précise.

Décision : Family Link pour l'instant (simple, gratuit, parental). MDM OSS en option future si le besoin de contrôle à distance (rester, verrouiller, effacer) se précise. Pas de sur-ingénierie maintenant.

12.3 L'usage enfants (résilience = usage)

Utilisateur	Appareil	Usage quotidien
Enfants	Téléphone Android + PC	AdGuard (DNS filtré) + Family Link (contrôle) + Jellyfin (contenus) + PhotoPrism (auto-upload)

---

S13 — Plan de migration R&D → production

Statut : ✅ Posé (05/10/2026) — phased, avec critères de succès par phase. Répond à l'AC7. S'appuie sur les phases R5 de DOSSIER-RECREATION.md (plan machine) ; cette section ajoute la couche logicielle.

13.0 Règle de lecture

• R5 = plan machine (fondations, cœur famille, finitions). Cette section = couche logicielle (quelle brique, dans quel ordre).
• Fondations d'abord : on ne déploie pas de brique sur un système sans backup (risque #1).
• On ne passe à la phase N+1 qu'après validation de la phase N.
• Statut : ⬜ à faire → 🟡 en cours → ✅ validé.

🔴 Prérequis absolu de TOUTE migration : un backup 3-2-1 fonctionnel (restic/borg chiffré, restauration testée, données IA incluses — S10) AVANT toute migration (xpenology → G9, ou MAJ d'une brique stateful). Aucune migration sans backup = aucun risque pris. L'incident Nextcloud (06/10/2026) est la preuve que le risque « MAJ stateful non supervisée » est réel : Watchtower a mis à jour l'app + la DB sans laisser la migration de schéma se terminer → service HS. La sélectivité (S11.4) + la procédure manuelle (S11.5) + le backup en place sont la réponse.

🔴 Action corrective immédiate (sur le NAS actuel, AVANT la migration) : exclure les briques stateful de Watchtower sur le xpenology (label com.centurylinklabs.watchtower.enable=false — liste S11.4) + passer WATCHTOWER_CLEANUP=false + notifier via n8n/Matrix. C'est urgent (le NAS actuel est toujours en production, sans exclusion) et indépendant de la migration xpenology → G9. → Phase A.0 ci-dessous.

13.1 Phase A — Fondations logicielles (avec R5 Phase 0)

Objectif : l'edge + le cœur + le bloc IA en place, backup 3-2-1 fonctionnel.

#	Action logicielle	Dépendance	Critère de succès (vérifiable)
A.0	Sécuriser le NAS actuel : exclure les briques stateful de Watchtower (S11.4) + WATCHTOWER_CLEANUP=false + notifications n8n/Matrix + backup 3-2-1 fonctionnel (prérequis)	—	0 stateful sous Watchtower sur le NAS ; backup 3-2-1 opérationnel (restauration testée) ; aucune MAJ stateful non supervisée possible
A.1	J5040 edge : firewall + DHCP + AdGuard + SearXNG + Caddy (TLS auto) + WireGuard	R5 0.3	Edge fonctionnel ; certificats auto-renew ; sites accessibles ; firewall strict ; recherche locale fonctionnelle
A.2	G9 cœur : OS + RAID1 + USB + SMB	R5 0.4	G9 monté ; IP .25 ; partages SMB accessibles
A.3	PC IA : Ollama (Qwen 3.8max) + Qdrant + hermes + OpenWebUI (1 seul)	R5 0.5	LLM fonctionnel ; conso idle mesurée < 80 W ; J5040 < 30%
A.4	Backup 3-2-1 : restic (G9+PC IA → Freebox quotidien → 218play hebdo) + LUKS	R5 0.6	3 copies en place + restauration testée (données IA incluses)
A.5	Ops : Compose dans Gitea + Watchtower + Beszel	A.1–A.4	Tous les services déclarés en Compose ; MAJ auto ; monitoring + alertes

Statut : ⬜ Dépendances : R5 Phase 0

13.2 Phase B — Cœur famille (dégafamisation, avec R5 Phase 1)

Objectif : le G9 devient le cœur famille (les briques famille en place).

#	Action logicielle	Dépendance	Critère de succès
B.1	PhotoPrism (photos, in-place) + migration 10 ans	Phase A + R5 1.1	Photos accessibles, IA OK, auto-upload Android
B.2	Nextcloud (Drive + Collabora + Groupware + Deck + Notes)	Phase A	Fichiers + Office + agenda + contacts + tâches accessibles
B.3	Vaultwarden (mots de passe) + 2FA + emergency access	Phase A	Coffre accessible famille, 2FA actif
B.4	Jellyfin (vidéo+musique) + *arr + qBittorrent	Phase A	Films/séries/musique accessibles
B.5	Gitea (vault second cerveau) + Obsidian	Phase A	Vault versionné, accessible
B.6	n8n (automatisation + alertes → Matrix)	Phase A	Workflows fonctionnels, alertes en Matrix
B.7	DNS (AdGuard) + sous-domaines folzocorp.fr	Phase A	Sous-domaines résolus, TLS auto

Statut : ⬜ Dépendances : Phase A + R5 Phase 1

13.3 Phase C — Finitions (dégafamisation complète, avec R5 Phase 2)

Objectif : la famille n'utilise plus de GAFAM (sauf Family Link parental).

#	Action logicielle	Dépendance	Critère de succès
C.1	Matrix + Jitsi + Element (complément du foyer, pas un remplacement de WhatsApp)	Phase B	Famille messagerie + visio en local
C.2	Home Assistant (enceintes Google) + Frigate (caméras)	Phase B	Assistant vocal + vision caméras
C.3	Bot hermes ↔ Matrix (Effi famille)	Phase B + 2ᵉ cerveau	Effi répond dans Matrix
C.4	Enfants : AdGuard profils + Family Link	Phase B	Enfants protégés (DNS + parental)
C.5	Décommissionner le ballast R&D (Dify, RAGFlow, conteneurs morts…)	Phase B	~70 conteneurs → ~20 briques ; plus de dupliqué
C.6	Valheim (jeu famille)	Phase B	Monde accessible

Statut : ⬜ Dépendances : Phase B + R5 Phase 2

13.4 Vue d'ensemble

Phase A (Fondations logicielles) ──► Phase B (Cœur famille) ──► Phase C (Finitions)
  edge + cœur + IA + 3-2-1 + ops      PhotoPrism + NC + Jellyfin    Matrix + HA +
  (avec R5 Ph0)                        + Vaultwarden + Gitea + n8n   enfants + décommission
                                      (avec R5 Ph1)                  (avec R5 Ph2)

Lien avec R5 : R5 = machine (fondations, cœur, finitions). Cette section = logiciel (les briques, dans l'ordre). Un seul plan, deux couches (comme le guide culture, C1-C5).

---

S14 — Grille des décisions + recommandations

Statut : ✅ Tranchées (05/10/2026) — chaque décision a une grille d'évaluation remplie + une recommandation. Répond à l'AC9.

14.1 Photos (R6.1)

Critère	PhotoPrism ✅	Immich	Nextcloud Photos
Lecture in-place	✅	❌ (importe)	🟡
IA (visages, sémantique)	✅	✅	❌
Partage famille	✅	✅	✅
Auto-upload Android	✅	✅	🟡
Sobriété (G9 16 Go)	✅	🟡	✅
Licence	AGPL-3.0	AGPL-3.0	AGPL-3.0
Sortie	✅ (originaux intacts)	🟡	✅
Verdict	✅ Recommandé	❌ (désorganise)	❌ (pas d'IA)

Recommandation : PhotoPrism (lecture in-place + IA + sobre).

14.2 Notes / second cerveau (R6.2)

Critère	Obsidian+Gitea+Qdrant ✅	Nextcloud Notes	Joplin	Affine
Versioning	✅ (git)	❌	🟡	🟡
Structure liée (wikilinks)	✅	❌	🟡	✅
Lisible par l'IA (RAG)	✅ (md + Qdrant)	🟡	🟡	❌
Format ouvert	✅ (md)	🟡	✅	🟡
Échelle (une vie)	✅	❌	🟡	🟡
Verdict	✅ Recommandé	❌ (mauvais fit store)	❌ (silo)	❌ (R&D)

Recommandation : Obsidian (viewer) + Gitea (store) + Qdrant (index) pour le second cerveau ; Nextcloud Notes pour les notes rapides famille.

14.3 Mail

Critère	Nextcloud Mail (IMAP) ✅	Serveur SMTP local
Fiabilité livraison	✅ (Gmail/Hotmail)	❌ (SPF/DKIM/DMARC, spam)
Complexité	✅ (faible)	❌ (élevée)
Pérennité	✅	🟡 (risque spam)
Verdict	✅ Recommandé	❌ (trop risqué en prod)

Recommandation : Nextcloud Mail (lecture IMAP) + livraison externe (Gmail/Hotmail). Dégafamisation complète du mail = horizon > 1 an.

14.4 Frontend IA

Critère	OpenWebUI (1 seul) ✅	Dify	mcpo+pipelines
Sobriété	✅	❌ (14 conteneurs)	🟡
Simplicité famille	✅	🟡	❌
Pérennité	✅	🟡 (R&D)	🟡
Verdict	✅ Recommandé	❌	❌

Recommandation : 1 seul OpenWebUI (front famille) + hermes (harnais agent).

14.5 Communication (Matrix)

Critère	Matrix+Jitsi+Element ✅	WhatsApp	Signal
OSS / souverain	✅	❌	✅
Visio intégrée	✅ (Jitsi)	✅	🟡
Fédéré / auto-hébergé	✅	❌	🟡
Verdict	✅ Recommandé	❌ (GAFAM)	🟡 (pas d'auto-hébergement facile)

Recommandation : Matrix (Synapse) + Jitsi + Element en complément du foyer (messagerie familiale + alertes + assistant). Révisé 12/10/2026 : WhatsApp n'est pas remplaçable dans notre usage (famille, amis, travail) → il reste la messagerie principale ; Element couvre le foyer et le canal d'alerte. Le pont mautrix-whatsapp est étudié, non déployé : numéro familial interdit, risque de bannissement, coût de session (QR / 12 jours). Détail : g9-migration/BRIDGE-WHATSAPP.md.

14.6 MDM enfants

Critère	Family Link ✅ (maintenant)	MicroMDM / Android Enterprise (future)
Simplicité	✅	🟡
OSS	❌ (Google)	✅
Contrôle parental	✅	✅
Verdict	✅ Recommandé (maintenant)	🟡 (option future)

Recommandation : Google Family Link (maintenant, usage parental) + MDM OSS (MicroMDM/Android Enterprise) en option future.

14.7 Coffre famille (décision 12/10/2026)

Critère	Vaultwarden unique (6 personnes) ✅	Nextcloud Passwords
Dépendance	✅ indépendant des autres briques	❌ le coffre vit dans la brique qu'il protège (Nextcloud HS = plus les accès pour réparer Nextcloud)
Reset admin d'un compte enfant	✅ sans effet sur le coffre	❌ clés dérivées du mot de passe → coffre potentiellement illisible
Modèle familial (organisations, emergency access)	✅	❌
Coût pour 6 (import, backup, reset, formation)	✅ 1 chemin	❌ 2 chemins (registre doublé)
Verdict	✅ Retenu	❌ Non retenu (pilote adulte possible, non déclenché)

14.8 Identité (décision 12/10/2026, ordre validé)

Étape	Décision	Statut
1	Registre d'identités (moitié générée + moitié humaine) — répond à « quel compte a servi ? »	✅ posé (g9-migration/REGISTRE-IDENTITES.md)
2	Étude exposition internet avant tout IdP	✅ étude écrite, 5 décisions à rendre
3	Authelia en cible, pilote 3 briques (Synapse, Gitea, Jellyfin), opt-in + break-glass	🟡 après étude + Phase 5
—	Authentik / Keycloak / Samba AD / FreeIPA / Nextcloud-IdP	❌ écartés (poids, sur-ingénierie, SPOF sur la brique la plus stateful)

14.9 Suivi applicatif (décision 12/10/2026)

Critère	Sondes + registre + Diun ✅	Grafana/Prometheus (+cAdvisor)	Netdata	Uptime Kuma
Couvre up ≠ utilisable	✅ (occ, discovery, healthz, login)	❌ (métriques)	🟡	✅
Briques ajoutées	0 (scripts du kit)	4	1 (lourd)	1 (stateful)
Chevauchement avec Beszel	complémentaire	redondant (InfluxDB déjà écarté)	redondant	partiel
Charge de maintenance	faible (cron + 1 digest/jour)	élevée	moyenne	moyenne + fatigue d'alertes
Verdict	✅ Retenu	❌	❌	🟡 reporté (déclencheur écrit, Phase 6 + 2 semaines d'usage)

14.10 Autonomie de l'assistante IA (décision 12/10/2026)

Paliers G11 : L0 lecture seule → L1 propose → L2 exécute le stateless documenté → L3 stateful sur GO explicite. Portes chiffrées (≥ 90 % de propositions pertinentes sur 30 jours ; sinistre simulé sans perte). Interdits permanents : destructif, suppression de données, réseau (G6), wipe, création de privilège, lecture de secrets hors coffre. Détail : g9-migration/README.md (charte G11).

---

S15 — Critères d'acceptance (AC1–AC10)

Statut : ✅ Tous remplis par ce dossier. C'est la preuve que la table rase est complète.

AC	Critère	Où c'est rempli
AC1	Chaque besoin famille/perso mappé sur UNE brique + UNE machine (pas d'orphelin, pas de doublon)	S3.1 (tableau 28 briques, 1 besoin = 1 brique = 1 machine — F9 recherche web = SearXNG (S3.1 #28) ; F15 RSS = suppression explicite (S3.2, chemin de ré-add documenté)) + S2.2 (rôle par machine)
AC2	Stack consolidée ≤ ~20 briques + liste de suppression explicite	S3.1 (~20 briques) + S3.2 (liste de suppression : Dify, RAGFlow, STT/OCR dupliqués, conteneurs morts, OpenWebUI multiples → 1 seul)
AC3	Chaque outil justifié (maturité, maintenance, ressource, licence OSS, chemin de sortie)	S3.1 (colonnes licence + sortie) + S3.3 (justification détaillée par brique)
AC4	Budget ressource par machine tenable (J5040 ~7-9/16, G9 ~8-11/16, PC IA ~53/62, Freebox léger)	S2.4 (tableau budget ressource par machine)
AC5	3-2-1 avec restic/borg (chiffré, append-only) + procédure de restore testée (LUKS source abandonné 10/10/2026 — chiffrement porté par restic)	S10 (restic/borg + procédure de restore testée §10.4)
AC6	Modèle sécurité (Caddy+TLS auto, WireGuard, firewall strict, copies chiffrées, 2FA, sous-domaines folzocorp.fr)	S9 (modèle de sécurité couche par couche + sous-domaines §9.2)
AC7	Plan de migration R&D→production, phased, avec critères de succès par phase	S13 (Phase A/B/C, critères de succès par action)
AC8	Résilience/adoption — chaque service a un utilisateur nommé + appareil + usage quotidien	S3.4 (briques edge & infra) + S5.3, S6.4, S7.3, S8.2, S12.3 (tableaux d'usage par utilisateur/appareil/usage)
AC9	Décisions (photos, sync notes, mail, frontend IA, Matrix, MDM) = grille d'évaluation remplie + recommandation	S14 (6 grilles d'évaluation + recommandations)
AC10	100% open source, licence notée par service	S3.1 (colonne licence par brique) + S3.1 note (honnêteté : n8n = fair-code, non-OSI, noté)

Bilan : les 10 critères sont tous remplis par ce dossier. La table rase est complète : architecture ciblée, décisions tranchées, plan de migration posé, licences notées, budget ressource validé, sécurité + backup + ops + enfants couverts.

---

Changelog

Date	Version	Changement
12/10/2026	v1.8	Identités mesurées + trou Synapse réparé + exposition durcie : balayage lecture seule (15-/16-identity-sweep) → Gitea 2FA = 0/4 et le bot g9ops est admin, Synapse admin = 0, Nextcloud 8 comptes + providers 2FA installés, n8n 1 owner, PhotoPrism 3 comptes, CouchDB = 401 (faux positif « sans auth » corrigé) ; 1ᵉʳ admin Synapse créé et vérifié (26-synapse-admin-repair.sh : register → mxid aléatoire password_hash NULL, HMAC incorrect sur la voie signée, puis bcrypt en base + docker restart + PUT /_synapse/admin/v2/users → login OK + API admin OK ; snapshot sqlite avant, compte temporaire désactivé, 0 purge ; 27-synapse-family-users.sh outille les 6 comptes famille admin:false) ; pare-feu durci sur GO : SSH LAN-only sur .24 et .27, 443 LAN-only sur .24, plus aucune règle Anywhere sur le G9, Tailscale coupé sur le pilot ; dumps logiques des 3 bases dans le périmètre restic + rejouabilité Gitea prouvée (116 tables) ; hub Beszel hors-G9 sur J5040 (digest, ufw LAN-only, 200) ; 31 critères clôturés côté IA avec distinction explicite « prouvé par mesure » / « geste humain » (RESTE-HUMAIN.md). Artéfacts : scripts/{25,26,27}-*.sh, §7 et §7.1 de REGISTRE-IDENTITES.md, RUNBOOKS/matrix.md réécrit.
12/10/2026	v1.7	Mesures Phase 4.5 (l'existant est maintenant prouvé, pas seulement décidé) : registre 22 conteneurs / 7 constats et définitions compose entrées dans le dépôt (matrix/, g9-queue/, valheim/, diun/ vivaient hors git) ; dérive prouvée de bout en bout (--check --alert → payload JSON reçu → revert → « aucune dérive ») ; chaîne d'alerte vérifiée : 5 payloads JSON conformes dans le salon ops + 3 notifications types avec event_ids (backup OK, backup KO provoqué, sonde KO) ; Diun déployé (digest crazymax/diun@sha256:e324b793…, notifie sans appliquer, docker inspect avant/après identique) ; prisme.folzocorp.fr = 200 (route posée sur le J5040, Let's Encrypt DNS-01) — photos. sert encore PhotoPrism, web DSM .25 = 000 ; backup : 5 snapshots Freebox, coffres + gitea/db + nextcloud/db + 505 836 entrées photos dans le snapshot, restauration sha256 identique à .25, médias 15 To/5,5 To exclus par construction ; photos : 433 941 fichiers == 433 941, indexation 9,1 %, RAM 1,1 GiB. Artéfacts : PHOTOS-DOUBLE-RUN.md, scripts/13-diun-notify.sh, scripts/g9-verify-alert.py --list.
12/10/2026	v1.6	Identité + suivi applicatif + communication (décisions 12/10) : S8 révisé — Matrix/Jitsi/Element = complément du foyer, pas remplacement de WhatsApp (Element : 2 adultes d'abord, ados phase 2) ; S9.2 sous-domaines alignés sur le réel (pass.folzocorp.fr = Vaultwarden, prisme.folzocorp.fr = PhotoPrism, photos.folzocorp.fr = Synology Photos temporaire, meurt Phase 6) ; S11 enrichi de deux briques d'ops sans conteneur de plus : registre généré (11-registry.sh → REGISTRE-BRIQUES.md, dérive par git diff) et sondes applicatives (12-probes.sh, up ≠ utilisable, alertes JSON + 1 digest/jour) ; S14.7→S14.10 : coffre unique Vaultwarden pour 6 (Nextcloud Passwords écarté : boucle de verrouillage + reset admin + pas d'emergency access), identité = registre → étude exposition → Authelia (Authentik/Keycloak/Samba AD/FreeIPA écartés), suivi = sondes + registre + Diun (Grafana/Prometheus/Netdata écartés, Uptime Kuma reporté avec déclencheur écrit), G11 paliers d'autonomie IA. Artéfacts : g9-migration/{REGISTRE-IDENTITES,REGISTRE-BRIQUES,PARTAGE-SECRET-MAITRE,RESTORE-NAS-USB,EXPOSITION-INTERNET,BRIDGE-WHATSAPP}.md, RUNBOOKS/ ×7, charte G11.
10/10/2026	v1.5	S10.2 — copie 2 (Freebox) EN PLACE sur le G9 : restic 0.19.1 + rclone 1.75.2, repo rclone:freeboxftp:Freebox/backup/g9 (FTP local 21), snapshot 4.18 GiB, append-only prouvé, restore testée (sha256), cron 03:30/04:00/09:15 + alerte Matrix ; mont CIFS abandonné (restic/chmod, FUSE) → backend rclone, persistance post-reboot sans montage. Phase 5 planifiée (non réalisée) : VM Freebox + rest-server --append-only (autostart à valider), restic copy → 218play, identifiants NoAccess, chroot durci.
06/10/2026	v1.4	Cohérence inter-dossiers (source unique) : (1) S10.2 — le schéma 3-2-1 ne re-déclare plus le tableau → pointeur vers DOSSIER-RECREATION.md §R4 (source unique) + note outil (restic, quotidien/hebdo) ; (2) S4.3 — le modèle 2 couches ne re-déclare plus le principe → pointeur vers PROJET-SECOND-CERVEAU.md S4.1 (source unique) + tableau mapping briques/machines (spécificité du dossier logiciel) ; (3) S3.1 — le tableau est cadré autour des briques fonctionnelles : la stack *arr #10 = 1 brique, les apps Nextcloud 13-15 marquées ↳ apps du socle NC #12 ; note de comptage précisée (28 lignes = 25 briques fonctionnelles, dans la cible ≤ ~20 briques de consolidation).
06/10/2026	v1.3	Correction mainteneur hermes : S3.1 #24 — « maintenu (Nous Research) » → « maintenu (nesquena — ghcr.io/nesquena/hermes-webui) », aligné sur l'image réellement en production (snapshot ETAT-DE-LART-2026-09-30.md §2.1).
06/10/2026	v1.2	S11 Ops — Watchtower sélectif (après l'incident Nextcloud du 06/10, documenté dans ETAT-DE-LART-2026-10-06.md §3) : correction de la règle stateless = auto / stateful = exclu + MAJ manuelle (S11.4) — suppression de l'adjectif « testées » (Watchtower ne teste rien) ; liste des briques stateful à exclure (Nextcloud, MariaDB, Redis, Vaultwarden, Gitea, n8n+Postgres, InfluxDB, OnlyOffice/Collabora, Leantime+MySQL, Affine+Postgres+Redis, Joplin+Postgres, Qdrant) ; config Watchtower cible (pinning des majeures, CLEANUP=false, notifications n8n/Matrix) ; écart actuel NAS (0 exclusion, 0 notification, CLEANUP=true, :latest) = action corrective. Nouvelle procédure de MAJ manuelle stateful (S11.5, 7 étapes + rollback, règle « pas de MAJ stateful sans backup »). S13 : prérequis absolu « backup 3-2-1 fonctionnel AVANT toute migration » + action corrective immédiate (exclure les stateful de Watchtower sur le NAS actuel) + Phase A.0 (sécuriser le NAS + backup). S11 statut + cohérence interne vérifiés.
06/10/2026	v1.1	Correction AC1 (besoins orphelins) : SearXNG mappé dans la stack consolidée (S3.1 #28, edge J5040 — S2.2, S2.4, S3.4, S13 A.1) ; FreshRSS ajouté à la liste de suppression explicite (S3.2 — pas d'usage quotidien nommé, podcasts RSS couverts côté client par AntennaPod, chemin de ré-add documenté). S15 (AC1/AC8) mis à jour.
05/10/2026	v1.0	Création du dossier Partie 5 (couche logicielle) — table rase : 6 principes (S1), architecture cible Option A (S2, PC IA garde la RAM, Matrix+Jitsi sur J5040, HA sur Freebox), stack consolidée ~20 briques (S3) + liste de suppression (Dify, RAGFlow, dupliqués, morts), bloc IA (S4, Ollama+Qwen 3.8max+Qdrant+hermes+OpenWebUI), PhotoPrism (S5), Nextcloud socle (S6), Jellyfin+*arr+AntennaPod (S7), Matrix+Jitsi+Element (S8), sécurité (S9, Caddy+WireGuard+LUKS+2FA+sous-domaines), backup 3-2-1 restic/borg (S10), ops (S11, Compose+Gitea+Watchtower+Beszel), enfants/MDM (S12), plan de migration A/B/C (S13), grille des décisions (S14), AC1–AC10 (S15). Licences notées par brique (honnêteté : n8n = fair-code).