L’architecture complète de mon assistant personnel auto-hébergé

20 diagrammes pour tout comprendre — du message utilisateur à la réponse, en passant par la mémoire, les outils, les crons, et la domotique.

Introduction

J’ai construit un assistant personnel auto-hébergé basé sur Hermes Agent (v3.11.1). Ce n’est pas un chatbot de plus — c’est un orchestrateur qui connecte messagerie, domotique, mémoire persistante, génération d’images, veille RSS, publication blog, et scripts système.

Cet article détaille l’architecture complète avec 20 diagrammes Mermaid. Chaque diagramme est un flux lisible, directement dans le navigateur ou dans Obsidian.

1. Le flux général d’une requête

flowchart TD
    U[👤 Jean-Paul] -->|Message| P[Plateformes
WebUI / Discord / Telegram
Email / WhatsApp / Webhook]
    P -->|Session + auth| C[Contexte
System Prompt
+ AGENTS.md
+ Mnemosyne
+ Autocontext]
    C -->|deepseek-v4-flash| M[Modèle Principal
Ollama Cloud
deepseek-v4-flash]
    M -.->|Timeout / erreur| F[Fallback Local
Ollama
qwen2.5:1.5b]
    M --> D{Action
nécessaire ?}
    F --> D
    D -->|Oui| T[Terminal
Commandes shell]
    D -->|Oui| FILES[Fichiers
Lecture / écriture]
    D -->|Oui| SEARCH[Recherche
SearX / session_search]
    D -->|Oui| MEM[Mnemosyne
Mémoire persistante]
    D -->|Oui| HA[Home Assistant
Domotique]
    D -->|Oui| IMG[Image Generation
FAL FLUX 2 Klein]
    D -->|Oui| WEB[Browser
Navigation web]
    D -->|Oui| MCP[Karakeep
Bookmarks]
    D -->|Oui| DELEG[delegate_task
Sous-agents]
    T --> R[Raisonnement
+ Compression RTK]
    FILES --> R
    SEARCH --> R
    MEM --> R
    HA --> R
    IMG --> R
    WEB --> R
    MCP --> R
    DELEG --> R
    R -->|Réponse| P
    P --> U

Ce qu’il faut retenir : le message arrive sur une plateforme, traverse le contexte (system prompt + mémoire), est traité par le modèle principal (deepseek-v4-flash sur Ollama Cloud), qui peut appeler des outils. Si le cloud est indisponible, fallback sur un modèle local (qwen2.5:1.5b). La réponse repart sur la même plateforme.

2. Le routage des modèles

flowchart TD
    Q[Tâche entrante] --> C{Complexité ?}
    C -->|Raisonnement, code,
fact-check, rédaction| D[deepseek-v4-flash
Ollama Cloud
💰 Forfait 20$/mois]
    C -->|Résumé, extraction,
triage, recherche fichiers| QW[qwen2.5:1.5b
Ollama Local
🆓 Gratuit]
    C -->|Sous-agents
delegate_task| QW2[qwen2.5:1.5b
Ollama Local]
    D -.->|Si indisponible| FALL[Fallback
qwen2.5:1.5b
Local]

Pourquoi deux modèles ? Le cloud (20 $/mois forfait) gère le raisonnement lourd. Le local (gratuit) gère le triage, les résumés, et les sous-agents. Le fallback garantit que le système ne s’arrête jamais.

3. L’architecture mémoire (Mnemosyne)

flowchart LR
    subgraph Entrées
        CONV[Conversations
sessions]
        TOOL[Résultats
outils]
        USER[Préférences
explicites]
        CORR[Corrections
utilisateur]
    end
    subgraph Mnemosyne
        WM[(Working Memory
220 faits)]
        EP[(Episodic Memory
résumés consolidés)]
        PERS[(Persona L3
règles durables)]
        CAN[(Canonical
slots stables)]
    end
    CONV -->|mnemosyne_remember| WM
    TOOL -->|Faits durables| WM
    USER -->|mnemosyne_remember_canonical| CAN
    CORR -->|mnemosyne_remember| WM
    WM -->|Consolidation
nocturne| EP
    WM -->|Promotion
manuelle| PERS
    WM -->|Injection
contexte| SYS[System Prompt
chaque tour]
    EP -->|Injection
contexte| SYS
    PERS -->|Auto-injection| SYS
    CAN -->|Injection
contexte| SYS

Le secret : une mémoire à 4 niveaux. Les faits bruts (Working) sont consolidés en résumés (Episodic) la nuit. Les règles durables sont promues en Persona (toujours injectées). Les slots stables (nom, préférences) sont en Canonical. Tout est injecté dans le contexte à chaque tour.

4. Le cycle de vie des cron jobs

flowchart LR
    S[Scheduler
Chronos] -->|Tick programmé| J{Type de job ?}
    J -->|no_agent=true| SH[Script shell/Python
→ stdout]
    J -->|no_agent=false| AG[Agent Hermes
→ raisonnement + outils]
    SH -->|stdout| DEL{Delivery}
    AG --> DEL
    DEL -->|origin| WEBUI[WebUI / Chat actuel]
    DEL -->|local| LOG[Fichier log
~/.hermes/cron/output/]
    DEL -->|all| FANOUT[Discord + Telegram
+ Email + WhatsApp]
    DEL -->|platform:id| SPEC[Cible spécifique
ex: Telegram:-100...]
    subgraph Scripts actifs
        UPD[update-hermes.sh
Mer/Dim 5h]
        CERT[renew-certs.sh
1er du mois 5h]
        LINUX[update-linux.sh
Lun 4h]
        SOC[soc-status.sh
Toutes les 30min]
        VEILLE[Veille éco
Lun 8h]
        DIV[Divergences Sara/Jenkins
Lun 10h]
    end
    SH --> UPD
    SH --> CERT
    SH --> LINUX
    SH --> SOC
    SH --> VEILLE
    SH --> DIV

6 scripts actifs : mises à jour (Hermes, Linux, certificats), surveillance sécurité (fail2ban toutes les 30 min), veille économique, et comparaison d’agents.

5. Le flux Kanban

flowchart TD
    OBJ[Objectif utilisateur] -->|décompose| ORC[Orchestrator
Agent Hermes]
    ORC -->|kanban_create| BOARD[(Board SQLite
cartes + dépendances)]
    BOARD -->|Carte prête
dépendances satisfaites| DISP[Dispatcher
surveille le board]
    DISP -->|spawn worker| WK[Worker Hermes
session isolée]
    WK -->|kanban_show| BOARD
    WK -->|Travail| TOOLS[Outils
Terminal / Fichiers / Web]
    WK -->|kanban_heartbeat| BOARD
    WK -->|kanban_block
décision humaine| BOARD
    WK -->|kanban_complete| BOARD
    BOARD -->|Notification| U[👤 Jean-Paul]
    subgraph Exemple pipeline article
        A[Recherche] --> B[Rédaction]
        B --> C[Fact-check]
        C --> D[Finalisation + pub]
    end

Kanban = traçabilité : chaque tâche est une carte avec dépendances. Le dispatcher ne lance pas B avant que A soit finie. Les workers sont isolés, sans mémoire persistante — tout passe par le board.

6. Le pipeline de publication blog

flowchart LR
    subgraph Idéation
        GERM[🌱 Germe
22_Germes/]
        NOTE[📝 Note
dossier thématique]
        LU[📖 Fiche livre
50_Lectures/]
    end
    subgraph Rédaction
        BRO[Ébauche
51_Blog/]
        FC[Fact-check
skill fact-checking]
        REL[Relecture
corrections]
    end
    subgraph Publication
        IMG[Image à la une
400×220px
FAL FLUX 2 Klein]
        WP[Publication
WordPress]
        CAT[Catégorie
selon dossier]
    end
    GERM -->|Développement| BRO
    NOTE --> BRO
    LU --> BRO
    BRO --> FC
    FC --> REL
    REL --> IMG
    IMG --> WP
    WP -->|origin:ai| CAT

De l’idée à la publication : une germe (note brève) ou une fiche de lecture devient une ébauche, passe par le fact-check, reçoit une image générée par FAL FLUX 2 Klein (400×220 px), et est publiée sur WordPress avec catégorie et tag origin:ai.

7. Le pipeline de veille RSS

flowchart LR
    subgraph Collecte
        RSS[Flux RSS/Atom
multi-sources]
        WEB[Pages web
surveillées]
        API[APIs JSON
GitHub, etc.]
    end
    subgraph Traitement
        WAT[Watchers Hermes
poll périodique]
        CLAS[Classification
par thème]
        DEDUP[Déduplication
watermark]
    end
    subgraph Stockage
        INBOX[📥 10_Boite_Reception/]
        QUERY[71_Queries/
YYYY-MM-DD-sujet.md]
        CONCEPT[20_Concepts/
dossier thématique]
    end
    RSS --> WAT
    WEB --> WAT
    API --> WAT
    WAT --> CLAS
    CLAS --> DEDUP
    DEDUP --> INBOX
    DEDUP --> QUERY
    DEDUP --> CONCEPT

Veille automatisée : les watchers Hermes pollent les flux RSS, les pages web et les APIs. Le contenu est classé par thème, dédupliqué (watermark), et stocké dans la boîte de réception ou les dossiers thématiques du vault Obsidian.

8. Le pipeline de capture web

flowchart LR
    URL[URL entrante] -->|web_extract| EXT[Extraction
contenu texte]
    EXT --> SUM[Résumé
points clés]
    SUM --> SAVE[Dépôt
10_Boite_Reception/
YYYY-MM-DD-titre.md]
    SAVE --> INBOX[📥 _inbox.md
index mis à jour]
    INBOX -->|Tri manuel| CLASS[Classement
dossier définitif]

Capture rapide : une URL → extraction du contenu → résumé → dépôt dans la boîte de réception avec index. Le tri final est manuel (l’utilisateur décide du classement).

9. Le pipeline email

flowchart TD
    EXT[Email externe
SMTP/IMAP] -->|himalaya| IN[📥 Boîte réception
hermes@rouze.eu]
    IN --> FILTER{Type ?}
    FILTER -->|Notification cron| ARCH[Archive
+ log]
    FILTER -->|Demande utilisateur| RESP[Réponse
via smtp-send]
    FILTER -->|Rapport périodique| FWD[Transférer
jean-paul@rouze.eu]
    FILTER -->|Alerte système| NTFY[ntfy notification
+ Discord]
    RESP -->|smtplib| SENT[📤 Envoyé]
    FWD --> SENT

3 comptes email (hermes, jeanpaul, rouzejp) gérés via Himalaya CLI. Les notifications cron sont archivées, les demandes utilisateur reçoivent une réponse automatique, les alertes système partent vers ntfy + Discord.

10. Le flux multi-plateforme

flowchart TD
    subgraph Entrées
        WUI[WebUI
Browser]
        TG[Telegram
@hermeswsljpr_bot]
        DC[Discord
#jenkins]
        ML[Email
hermes@rouze.eu]
        WA[WhatsApp]
        WH[Webhook]
    end
    subgraph Hermes Core
        GATE[Gateway
connexions persistantes]
        SESS[Session Manager
contexte par chat]
        PROF[Profil default
unique]
    end
    subgraph Sorties
        WUI2[WebUI]
        TG2[Telegram
Cat 5782530975]
        DC2[Discord
#jenkins / #reports]
        ML2[Email
jean-paul@rouze.eu]
    end
    WUI --> GATE
    TG --> GATE
    DC --> GATE
    ML --> GATE
    WA --> GATE
    WH --> GATE
    GATE --> SESS
    SESS --> PROF
    PROF -->|Réponse| GATE
    GATE --> WUI2
    GATE --> TG2
    GATE --> DC2
    GATE --> ML2

6 plateformes connectées : WebUI, Telegram, Discord, Email, WhatsApp, Webhook. Un profil unique (default) gère tout. Le Session Manager maintient le contexte par chat.

11. Le cycle de mise à jour système

flowchart TD
    subgraph Scripts cron
        UPD[update-hermes.sh
Mer/Dim 5h]
        LINUX[update-linux.sh
Lun 4h]
        CERT[renew-certs.sh
1er mois 5h]
    end
    subgraph Actions
        UPD -->|git pull + npm install| HW[Hermes WebUI]
        UPD -->|pip install -e .| HA[Hermes Agent]
        LINUX -->|apt upgrade| APT[Paquets système]
        LINUX -->|curl install.sh| OLL[Ollama]
        CERT -->|acme.sh --issue --force| SSL[Certificats SSL
Traefik]
    end
    subgraph Vérification
        HW -->|timeout 600| OK1[✅ WebUI OK]
        HA -->|hermes --version| OK2[✅ Agent OK]
        APT -->|silencieux si rien| OK3[✅ Paquets OK]
        OLL -->|ollama --version| OK4[✅ Ollama OK]
        SSL -->|acme.sh --list| OK5[✅ Certs OK]
    end
    subgraph Échec
        OK1 -.->|timeout| NTFY[🔴 ntfy notification
à Jean-Paul]
        OK2 -.->|erreur| NTFY
        OK3 -.->|timeout| NTFY
        OK4 -.->|erreur| NTFY
        OK5 -.->|erreur| NTFY
    end

3 scripts cron mettent à jour Hermes Agent, Hermes WebUI, les paquets Linux, Ollama, et les certificats SSL. Chaque étape est vérifiée. En cas d’échec, une notification ntfy est envoyée.

12. Le flux Home Assistant (domotique)

flowchart LR
    subgraph Sorède
        HA_S[Home Assistant
192.168.1.144]
        ENP[Enphase Envoy
PV solaire]
        CUM[Cumulus Zigbee
eau chaude]
        AWT[AWTRIX
192.168.1.253]
    end
    subgraph GTV
        HA_G[Home Assistant
GTV]
    end
    subgraph Hermes
        CMD[Commande
ha_call_service]
        QRY[Requête
ha_get_state]
        LST[Liste
ha_list_entities]
    end
    CMD -->|turn_on/off| HA_S
    CMD -->|turn_on/off| HA_G
    QRY -->|sensor.*| HA_S
    QRY -->|sensor.*| HA_G
    LST -->|domain filter| HA_S
    LST -->|domain filter| HA_G
    HA_S -->|Production| ENP
    HA_S -->|Température| CUM
    HA_S -->|Affichage| AWT

Deux maisons : Sorède (résidence principale, Enphase solaire, cumulus Zigbee, AWTRIX) et GTV (garage). Hermes contrôle tout via l’API REST Home Assistant.

13. Le flux de délégation (delegate_task)

flowchart TD
    P[Agent Parent
conversation principale] -->|delegate_task| C1[Sous-agent 1
recherche]
    P -->|delegate_task| C2[Sous-agent 2
analyse]
    P -->|delegate_task| C3[Sous-agent 3
synthèse]
    C1 -->|Résumé| P
    C2 -->|Résumé| P
    C3 -->|Résumé| P
    P -->|Vérifie résultats| V{Valide ?}
    V -->|Oui| R[Réponse finale]
    V -->|Non| RE[Relance ou corrige]
    subgraph Contraintes
        MAX[Max 3 sous-agents
simultanés]
        NEST[Pas de sous-sous-agents
max_spawn_depth=1]
        NOQ[Pas de clarify
dans les sous-agents]
    end

Parallélisme maîtrisé : jusqu’à 3 sous-agents simultanés, chacun dans une session isolée. Pas de sous-sous-agents (profondeur 1). Les sous-agents ne peuvent pas poser de questions — tout doit être dans le contexte de départ.

14. Le cycle de notification et alertes

flowchart TD
    subgraph Sources d'alerte
        CRON[Échec cron job]
        SOC[Fail2ban
soc-status.sh]
        HA[Home Assistant
seuils dépassés]
        SYS[Disque plein
load élevé]
    end
    subgraph Routage
        NTFY_SRV[ntfy server
notification push]
        DISCORD[Discord
#jenkins]
        TG[Telegram
Cat / Jean-Paul]
        EMAIL[Email
jean-paul@rouze.eu]
    end
    subgraph Destinataires
        JP[👤 Jean-Paul
actions]
        CAT[👩 Catherine
récap coûts 1er du mois]
    end
    CRON -->|ntfy-notify.sh| NTFY_SRV
    SOC -->|ntfy-notify.sh| NTFY_SRV
    HA -->|webhook| NTFY_SRV
    SYS -->|bypass déterministe| NTFY_SRV
    NTFY_SRV --> DISCORD
    NTFY_SRV --> TG
    NTFY_SRV --> EMAIL
    DISCORD --> JP
    TG --> JP
    TG --> CAT
    EMAIL --> JP

4 sources d’alerte : échecs cron, fail2ban, seuils Home Assistant, santé système. Tout converge vers ntfy, qui distribue vers Discord, Telegram et email. Catherine reçoit un récap coûts le 1er du mois.

15. Le pipeline de traitement de la boîte de réception

flowchart TD
    INBOX[📥 10_Boite_Reception/] -->|Lire _inbox.md| ANALYSE[Analyser contenu
identifier thème]
    ANALYSE --> DECIDE{Thème ?}
    DECIDE -->|Histoire| HIST[20_Concepts/Histoire/]
    DECIDE -->|Immobilier| IMMO[20_Concepts/Immobilier/]
    DECIDE -->|Sciences/IA| IA[20_Concepts/Sciences/ia/]
    DECIDE -->|Société| SOC[20_Concepts/Societe/]
    DECIDE -->|OSINT| OSINT[20_Concepts/OSINT/]
    DECIDE -->|Personne| ENT[61_Entites/]
    DECIDE -->|Autre| AUTRE[dossier approprié]
    HIST -->|Créer wikilinks| LINK[🔗 Lier aux notes
existantes]
    IMMO --> LINK
    IA --> LINK
    SOC --> LINK
    OSINT --> LINK
    ENT --> LINK
    AUTRE --> LINK
    LINK --> UPDATE[📝 Mettre à jour
_inbox.md]

Tri automatique : le contenu de la boîte de réception est analysé, routé vers le dossier thématique approprié (Histoire, Immobilier, Sciences, Société, OSINT, Entités…), et des wikilinks sont créés vers les notes existantes.

16. Le cycle de veille divergences Sara/Jenkins

flowchart LR
    subgraph Agents
        SARA[Sara
Windows / féminine]
        JENK[Jenkins
Linux / masculin]
    end
    subgraph Tâche commune
        Q[Même question
posée aux deux]
        R1[Réponse Sara]
        R2[Réponse Jenkins]
    end
    subgraph Analyse
        COMP[Comparer
approches]
        DIV[Identifier
divergences]
        REP[Rapport
lundi 10h]
    end
    Q --> SARA
    Q --> JENK
    SARA --> R1
    JENK --> R2
    R1 --> COMP
    R2 --> COMP
    COMP --> DIV
    DIV --> REP

Expérience agentique : deux agents (Sara sur Windows, Jenkins sur Linux) reçoivent la même question. Leurs réponses sont comparées pour identifier les divergences d’approche. Rapport hebdomadaire le lundi.

17. Le cycle de consolidation mémoire (Mnemosyne)

flowchart TD
    subgraph Quotidien
        W[Working Memory
faits bruts]
        W -->|mnemosyne_sleep| C{Consolidation
nocturne}
    end
    C -->|Âge > seuil| EP[Episodic Memory
résumé compressé]
    C -->|Récent| W2[Retour Working
rafraîchi]
    EP -->|Promotion manuelle| P3[Persona L3
règles durables]
    P3 -->|Déclin si non utilisé| W3[Retour
Memoria]
    subgraph Niveaux
        L1[L1: Working
transitoire]
        L2[L2: Episodic
compressé]
        L3[L3: Persona
toujours injecté]
    end
    W --> L1
    EP --> L2
    P3 --> L3

3 niveaux de mémoire : Working (transitoire, 220 faits), Episodic (compressé, consolidé la nuit), Persona (toujours injecté, décline si non utilisé). Les faits trop vieux sont archivés.

18. Le flux de fact-checking

flowchart LR
    Q[Demande fact:] -->|Charger skill| SK[skill fact-checking]
    SK -->|Recherche| SRC[Sources citées
vérification]
    SRC -->|Affirmation 1| V1{Vraie ?}
    SRC -->|Affirmation 2| V2{Vraie ?}
    SRC -->|Affirmation 3| V3{Vraie ?}
    V1 -->|Oui| OK1[✅ Confirmé]
    V1 -->|Non| KO1[❌ Réfuté]
    V2 -->|Oui| OK2[✅ Confirmé]
    V2 -->|Non| KO2[❌ Réfuté]
    V3 -->|Oui| OK3[✅ Confirmé]
    V3 -->|Non| KO3[❌ Réfuté]
    OK1 --> RAPPORT[Rapport structuré
source + vérification + conclusion]
    OK2 --> RAPPORT
    OK3 --> RAPPORT
    KO1 --> RAPPORT
    KO2 --> RAPPORT
    KO3 --> RAPPORT

Vérification par affirmation : chaque affirmation est vérifiée individuellement avec sa source. Le résultat est un rapport structuré (source → vérification → conclusion).

19. Le flux de génération d’images

flowchart LR
    Q[Demande image] -->|prompt| FAL[FAL.ai
FLUX 2 Klein 9B]
    FAL --> MODE{Mode ?}
    MODE -->|Texte → Image| T2I[Generation
from scratch]
    MODE -->|Image → Image| I2I[Édition
+ reference images]
    T2I -->|aspect_ratio| RATIO[landscape / square / portrait]
    I2I -->|image_url| EDIT[Transforme
source]
    RATIO --> RES[🖼️ Image
URL ou fichier local]
    EDIT --> RES
    RES -->|MEDIA:path| DELIV[Affichage
dans la conversation]

FLUX 2 Klein 9B via FAL.ai. Deux modes : texte → image (from scratch) ou image → image (édition). Trois ratios : landscape, square, portrait. L’image est affichée directement dans la conversation.

20. Le cycle de backup et synchronisation

flowchart LR
    subgraph NAS
        GTV[NAS GTV
DS414]
        SOR[NAS Sorède
DS416play]
    end
    subgraph Vault
        OBS[Obsidian Jenkins
/root/obsidian-jenkins/]
    end
    subgraph Sync
        ST[Syncthing
P2P file sync]
    end
    OBS -->|Syncthing| ST
    ST -->|Backup prioritaire| GTV
    ST -->|Backup secondaire| SOR
    GTV -->|Backup Catherine| SOR

Syncthing synchronise le vault Obsidian entre le VPS et les NAS. Backup prioritaire sur le NAS GTV (DS414), secondaire sur le NAS Sorède (DS416play). Catherine a son propre backup GTV → Sorède.

Légende des diagrammes

Symbole	Signification
`[Carré]`	Étape de traitement
`{Losange}`	Décision / branchement
`((Cercle))`	Point d’entrée / sortie
`[(Base)]`	Stockage persistant
`-.->`	Chemin de fallback / secondaire
`-->`	Chemin principal
`subgraph`	Groupe logique de composants

Chiffres clés

Métrique	Valeur
Modèle principal	deepseek-v4-flash (Ollama Cloud)
Modèle local	qwen2.5:1.5b (Ollama)
Mémoire	220 faits Working, 4 niveaux
Scripts cron actifs	6
Plateformes connectées	6 (WebUI, Telegram, Discord, Email, WhatsApp, Webhook)
Outils disponibles	10+ (Terminal, Fichiers, SearX, Mnemosyne, HA, FAL, Browser, MCP, delegate_task…)
Sous-agents max	3 simultanés
Coût cloud	20 $/mois forfait
NAS	2 (DS414 + DS416play)
Maisons domotiques	2 (Sorède + GTV)

Pour aller plus loin

Article généré le 2026-07-03 — 20 diagrammes Mermaid, statut : brouillon.

† 4 revisions

L’architecture complète de mon assistant personnel auto-hébergé — 20 diagrammes pour tout comprendre