Évaluation on Boris Dupoux

Graphes de connaissances de mission : des preuves de conseil à une ontologie interrogée via MCP

Wed, 14 Oct 2026 00:00:00 +0000

Contexte

Le conseil en observation des processus produit des logigrammes, des notes d’entretien, des enregistrements d’écran et des recommandations. Une fois la mission livrée, ce matériau est de fait inerte : la mission suivante repart d’une page blanche, même lorsque la réponse avait déjà été trouvée ailleurs. La question de recherche est de savoir comment transformer les livrables, de documents en données typées, sourcées et interrogeables, afin qu’un assistant puisse répondre à « où avons-nous déjà vu cela, et qu’en avions-nous conclu ? » en citant des preuves vérifiables.

Deux exigences structurent le travail : la traçabilité (chaque assertion renvoie à sa preuve) et une stricte séparation entre preuve et connaissance (ce qui a été observé n’est pas ce qui a été généralisé). La génération augmentée par la recherche (RAG) est rapide à mettre en place, mais cite des passages, pas des assertions vérifiables ; une ontologie formelle est traçable, mais coûteuse. Ce projet explore une voie pragmatique entre les deux.

Approche

flowchart TB
 A["`Sources brutes de mission
immuables, hachées`"] --> B["`Journal d'événements en ajout seul
source de vérité`"]
 B --> C["`Base SQLite reconstructible
jetable`"]
 C --> D[Extraction déterministe]
 C --> E["`Extraction par LLM
simple force de proposition`"]
 D --> F["`Nœuds et arêtes proposés
avec provenance`"]
 E --> F
 F --> G{"`Revue humaine
hors MCP`"}
 G -->|validé| H[Graphe de connaissances]
 H --> I[MCP : preuves]
 H --> J[MCP : connaissances]
 H --> K[MCP : ontologie]
 I --> L[Assistant IA]
 J --> L
 K --> L

Le choix de conception central consiste à scinder l’interface en trois serveurs MCP selon le statut épistémique : preuves (observations attestées et sourcées), connaissances (généralisations) et ontologie (le méta-modèle lui-même). Cette séparation empêche un assistant de présenter une généralisation comme une observation.

flowchart TB
 subgraph SCHEMA["SCHÉMA · nommage"]
 ON["`serveur ontologie
Comment le nomme-t-on ?`"]
 end
 subgraph PROVEN["PROUVÉ · observé"]
 EV["`serveur preuves
Qu'a-t-on capté, et où ?`"]
 end
 subgraph GENERAL["GÉNÉRALISÉ · conclu"]
 KN["`serveur connaissances
Qu'en conclut-on ?
propose, ne valide jamais`"]
 end
 ON -. "type" .-> EV
 EV == "fonde chaque conclusion" ==> KN
 EV --> AI["`Assistant IA
réponses étiquetées par statut`"]
 KN --> AI
 ON --> AI

Le graphe est unique ; seules les façades sont séparées. La frontière qui compte passe entre preuves et connaissances : le serveur preuves ne renvoie que ce qui a été observé, et où ; le serveur connaissances renvoie des conclusions qui doivent remonter jusqu’à ces preuves, et aucun outil MCP ne peut marquer quoi que ce soit comme validé.

Méthodes

Méta-modèle. Un noyau fixe, complété de profils de mission et d’une ontologie spécifiée (v0). Chaque nœud porte une origine (structurelle, déterministe, extraite par LLM) et un statut (proposé → validé).
Invariants (I1–I6). Six invariants d’intégrité et de provenance. La provenance est obligatoire sur chaque nœud et chaque arête dérivés ; une recommandation doit pouvoir être rattachée, de proche en proche, à un constat sourcé ; les citations extraites par LLM doivent être des sous-chaînes littérales de leur fragment ; le statut « validé » exige une décision humaine enregistrée. Les sources brutes sont immuables ; la base de données est jetable et reconstruite à partir du journal.
Questions de compétence avant l’implémentation. Un jeu v0 de 33 questions, typées comme factuelles, agrégées, de traçabilité, de contradiction, temporelles, inter-missions et négatives (requêtes que le système doit refuser, par exemple une fuite entre clients), dans un format exécutable avec réponses attendues et références. Elles sont spécifiées, mais pas encore instanciées ni exécutées.
Protocole d’évaluation. Au moins 30 tâches en langage naturel, notées automatiquement ou par un juge. Le protocole d’évaluation a été versionné avant le premier commit d’implémentation (le même jour) ; plusieurs jalons ont ensuite été adaptés. Seuils : exactitude ≥ 0,8, citations valides ≥ 0,98, ancrage ≥ 0,95, fuite = 0, médiane ≤ 6 appels d’outils par tâche ; chaque question soluble en ≤ 3 appels ; G1 : κ inter-annotateurs ≥ 0,7 ; G2 : précision de l’extracteur ≥ 0,95 par type.
Phases P0–P6 avec points de contrôle humains. L’implémentation est déléguée à une session d’agent qui doit s’arrêter aux points de contrôle humains désignés et consigner les décisions en suspens.
Cartographie d’un logiciel en boîte noire. La même méthode a été appliquée à un logiciel commercial de gestion d’entreprise, sans lecture de son code source. La cible est un triplet de vérités — utilisateur, logiciel et base de données — reliées par des arêtes prouvées. Onze heuristiques (H1–H11) couvrent l’appariement de valeurs, la perturbation inverse et directe, les champs calculés, la visibilité conditionnelle, les différences entre scénarios, la fouille d’invariants, le fuzzing des saisies, les a priori sémantiques (jamais considérés comme preuve), le passage de la documentation au test et du symptôme à la règle. Entrées : l’arborescence des menus via AT-SPI, un relevé des écrans, le profilage des colonnes et une typologie d’événements issue du journal d’audit de l’application. Une hypothèse n’est acceptée qu’avec une contre-preuve indépendante ; les cartographies produites par l’éditeur sont tenues en quarantaine et servent d’oracle de notation.

Un extrait illustratif du graphe typé (libellés fictifs) : la préconisation n’est recevable que parce que la chaîne qui descend jusqu’à un fragment littéral d’une source est complète.

flowchart TB
 R["`Préconisation
point de saisie unique`"] -- répond à --> C["`Constat
double saisie à la réception`"]
 O["`Observation
« le stock est ressaisi à la main »`"] -- atteste --> C
 O -- extrait de --> F["`Fragment
notes d'entretien, lignes 40–52`"]
 F -- cite --> P["`Pièce source
hachée, immuable`"]
 C -- porte sur --> A["`Activité
réception des marchandises`"]
 A -- utilise --> S["`Écran
formulaire de réception`"]
 S -- module de --> Y["`Système
logiciel de gestion`"]

État d’avancement & résultats

Il s’agit principalement d’une conception partiellement implémentée, et non d’un système en service.

Pilote (corpus d’observation, passe déterministe). 6 195 fichiers (6,92 Go ; 61 copiés, 6 134 par référence hachée) acquis de manière idempotente ; 13 272 nœuds (dont un nœud par fichier source) et 6 022 arêtes issus de la base de l’outil de capture (extracteur v0.1), en 2,1 s, sans nouvel appel LLM (la passe relit les sorties VLM/ASR déjà stockées par l’outil de capture) ; 57 969 vérifications automatiques des invariants I1–I6, toutes passées (plusieurs sont vraies par vacuité sur ce corpus ; I6 n’est que partiellement appliqué).
Mesure sur jeu de référence. 145 unités d’annotation et 100 paires de résolution d’entités (245 au total). 97 unités sur 245 ont été annotées par l’auteur (67 frames, 30 segments ; aucun passage, aucune paire de résolution d’entités). Le second annotateur était l’agent LLM qui a implémenté l’extracteur : l’accord ci-dessous oppose donc l’auteur à l’agent LLM, ce n’est pas un κ entre humains, et le jalon G1 (adapté) n’a pas pu être évalué au sens strict. Accord : κ = 0,72 (logiciel, n = 69), 0,41 (écran, n = 67), 0,31 (catégorie, n = 69), 0,52 (limites de segments, n = 30) ; le rapport compte 69 frames pour deux champs alors que 67 ont été annotées, un écart non encore résolu. Précision de l’extracteur par rapport à la référence de l’auteur : 0,74, 0,43, 0,04, 0,63. Jalon G2 (précision de l’extracteur ≥ 0,95) non franchi ; le résultat sur la catégorie traduit un désaccord de définition, et non une erreur de calcul.
Cartographie du logiciel. Schéma de 427 tables sans aucune clé étrangère, aucun déclencheur ni aucune vue déclarés (toute la logique est applicative) ; 1 048 entrées de menu (899 feuilles) cartographiées ; 154 des 899 écrans relevés (17 %) ; 2 845 hypothèses de règles ramenées à 1 519 par un tri par LLM local et un dédoublonnage par plongements. Un audit aléatoire de 30 éléments par l’agent LLM superviseur a relevé 1 mauvaise décision de conservation ou de rejet (≈ 3 %, IC à 95 % : 0,6–17 %) ; aucun audit humain à ce stade. Un unique prototype MCP en lecture seule existe pour la cartographie du logiciel (ce n’est pas l’un des trois serveurs) ; aucune règle n’a encore été prouvée dans le logiciel. Le travail sur la VM s’est arrêté lorsque l’accès a été retiré, après que les traitements de cartographie ont surchargé l’hôte partagé ; il s’est poursuivi en local.

Mesure sur jeu de référence face aux jalons : les barres sont les valeurs mesurées par champ (n = 69, 67, 69 et 30 unités), la ligne orange est le seuil. Une seule barre de κ le franchit, aucune barre de précision.

---
config:
 xyChart:
 width: 540
 height: 320
 themeVariables:
 xyChart:
 backgroundColor: "transparent"
 plotColorPalette: "#3F86B8, #C46A2B"
---
xychart-beta
 title "Accord auteur × LLM, κ (G1 adapté, seuil 0,7)"
 x-axis ["logiciel", "écran", "catégorie", "segments"]
 y-axis "κ" 0 --> 1
 bar [0.72, 0.41, 0.31, 0.52]
 line [0.7, 0.7, 0.7, 0.7]

---
config:
 xyChart:
 width: 540
 height: 320
 themeVariables:
 xyChart:
 backgroundColor: "transparent"
 plotColorPalette: "#3F86B8, #C46A2B"
---
xychart-beta
 title "Précision vs référence de l'auteur (G2, seuil 0,95)"
 x-axis ["logiciel", "écran", "catégorie", "segments"]
 y-axis "Précision" 0 --> 1
 bar [0.74, 0.43, 0.04, 0.63]
 line [0.95, 0.95, 0.95, 0.95]

La cartographie du logiciel, en entonnoir : l’arborescence des menus est entièrement cartographiée, mais la couverture des écrans et la preuve restent loin derrière, et la chaîne d’hypothèses n’a encore produit aucune règle prouvée.

---
config:
 xyChart:
 width: 540
 height: 360
 themeVariables:
 xyChart:
 backgroundColor: "transparent"
 plotColorPalette: "#3F86B8"
---
xychart-beta
 title "Cartographie en boîte noire : de l'inventaire à la preuve"
 x-axis ["Entrées menu", "Feuilles", "Écrans", "Hypothèses", "Filtrées", "Prouvées"]
 y-axis "Nombre" 0 --> 3000
 bar [1048, 899, 154, 2845, 1519, 0]

Les trois serveurs MCP et l’évaluation de bout en bout (P4–P5) ne sont pas implémentés.

Limites & suite

Les résultats du pilote sont inférieurs aux seuils et reposent sur une annotation humaine partielle. Prochaines étapes : redéfinir l’étiquette de catégorie, constituer une référence entièrement humaine, mesurer à nouveau G1/G2, instancier les questions de compétence, puis construire les trois serveurs et dérouler le protocole d’évaluation. Pour la cartographie du logiciel, les heuristiques de perturbation en écriture attendent une autorisation écrite et une VM dédiée.

Stack technique

Python 3.11 · JSONL event log · SQLite · YAML ontology · MCP · AT-SPI · Ollama · pytest

Un agent IA entièrement local, avec graphe de sens et mesure multimodale des émotions

Sun, 11 Oct 2026 00:00:00 +0000

Contexte

Les traces numériques personnelles (messageries, courriels, photos, écoutes musicales, notes, agenda, exports de santé, dépôts de code) comptent parmi les données les plus sensibles qu’une personne possède, mais aussi parmi les plus riches pour étudier le comportement — et le ressenti — dans la durée. Les confier à un LLM dans le cloud n’est pas acceptable : tout fonctionne donc sur un unique ordinateur de bureau Apple silicon (M4, 32 Go de mémoire unifiée). Aucun contenu personnel n’est envoyé à un modèle dans le cloud ; la seule requête sortante est une recherche facultative d’extraits publics de 30 s (artiste et titre) via la recherche iTunes d’Apple.

L’objectif est un agent qui réponde à des questions sur sa propre vie tout en maintenant une séparation stricte entre ce qui est observé, ce qui est calculé, ce qui est supposé par un modèle et ce qui est accepté comme vrai par son propriétaire.

Ce qui est original

Les agents locaux sur des fichiers personnels ne sont pas nouveaux. Deux aspects de ce projet le sont.

1. Un graphe de sens au-dessus d’une couche de mesure. La connaissance est organisée à deux niveaux. Un observatoire stocke faits et signaux au format long (élément, dimension, valeur, confiance, modèle, version). Au-dessus, un graphe de sens stocke ce que ces signaux signifient : des relations (réifiées, pour qu’une relation puisse évoluer et se mesurer), des épisodes affectifs (qui a ressenti quoi, quand, avec quelle intensité, par quelle modalité), des thèmes, des chapitres de vie et des vérités — des énoncés assortis de preuves qui les étayent et de preuves qui les contredisent, que seul le propriétaire peut valider. Chaque nœud et chaque arête porte sa provenance jusqu’à l’élément source, ainsi que l’une des 9 origines réparties en 6 rangs de confiance (déclaré > structurel > règle/calcul > éditeur > modèle — image, texte ou voix — > inféré), une décision humaine enregistrée l’emportant toujours.

2. Des émotions mesurées à travers les modalités, selon des dimensions atypiques. Le même vocabulaire fixe de 53 émotions (fondé sur Plutchik, chacune dotée de coordonnées de valence et d’éveil) s’applique aux messages (LLM local), à la voix (cinq couches acoustiques et multimodales, dont trois sont fusionnées avec la transcription, avec un signalement explicite du désaccord entre texte et voix) et aux photos (mesures déterministes de couleur et de lumière, plongements SigLIP, signaux de visage spécifiés comme des indices faibles). Ces mesures s’inscrivent dans un catalogue de 929 dimensions définies, réparties en 88 groupes, qui va bien au-delà des métadonnées habituelles. Quelques-unes de ses entrées les moins courantes (les lignes marquées † sont définies, mais pas encore calculées) :

modalité	dimension	définition
photo	température de couleur	équilibre moyen rouge–bleu de l’image (chaud ou froid)
photo	colorfulness	métrique de couleurs opposées de Hasler & Süsstrunk (2003)
photo	heure dorée / heure bleue †	élévation du soleil calculée hors ligne à partir de la date et de la position
photo	taille du visage	part de l’image occupée par un visage (indice de proximité)
voix	jitter, shimmer, rapport harmoniques/bruit	prosodie openSMILE eGeMAPS
voix	rires, pleurs, soupirs	détection d’événements sonores (classes AudioSet)
voix	désaccord texte/voix	valence de la voix et valence de la transcription écartées d’au moins 0,6
message	valence, éveil, ton	par participant, contraints à la grille fixe
message	ponctuation expressive, palette d’emojis †	mesures déterministes du texte
relation	asymétrie de latence de réponse †	logarithme du rapport des délais médians de réponse des deux parties
relation	initiatives	conversations ouvertes après 3 h de silence, de chaque côté
relation	tendance †	pente de l’intensité de la relation sur 90 jours (refroidissement < 0)
période	nostalgie musicale †	âge moyen des titres écoutés
période	création / consommation †	temps passé sur des outils de création ÷ temps de consommation

† définie, pas encore calculée.

Des signaux au sens

flowchart LR
 PH["Photo"] --> PM["Mesures
lumière · contraste · température de couleur
colorfulness · palette · netteté"]
 PH --> PS["Plongement SigLIP
(similarité image ↔ texte)"]
 PH --> PF["Signaux de visage de l'éditeur
sourire · expression · regard · taille du visage"]
 VN["Note vocale"] --> VT["Transcription Whisper"]
 VN --> VL["Couches acoustiques
valence/éveil/dominance · catégories
événements sonores · prosodie · LLM audio"]
 VT --> VX["Émotion du texte de la transcription"]
 VL --> VF["Fusion pondérée
confiance = accord
signalement du désaccord texte/voix"]
 VX --> VF
 MS["Messages
(pseudonymisés : Moi, P1, P2)"] --> ML["LLM local, grille fixe
émotion · intensité · valence
éveil · ton · sujets"]
 PM --> OB[("Observatoire
929 dimensions")]
 PS --> OB
 PF --> OB
 VF --> OB
 ML --> OB
 OB -- "émotion suffisamment sûre" --> AFF["Épisode affectif (AFF)
qui · émotion · quand · intensité · modalité"]
 PF -. "prévu : indice faible, confiance ≤ 0,4" .-> AFF
 ML -- "sujets" --> THM["Thèmes"]
 OB -- "agrégats" --> AG["Indicateurs par jour / période
valence · lumière · palette"]
 AFF --> G["Graphe de sens
relations · épisodes · thèmes · chapitres · vérités
(tous proposés)"]
 THM --> G
 AG --> G
 G --> HV(("Propriétaire
valider · rejeter · corriger"))

Chaque épisode affectif est un nœud relié à la personne qui l’a ressenti, à l’émotion du vocabulaire fixe et — lorsqu’il existe — à la conversation ou au moment où il s’est produit. Des règles d’inférence font ensuite remonter l’affect (par exemple l’affect d’un chapitre ou d’une routine), et les corrélations fortes entre agrégats peuvent devenir des vérités proposées, avec leurs mesures pour preuves.

La mesure des émotions en détail

Vocabulaire. La grille est fixe et versionnée : les 8 émotions primaires de Plutchik à 3 intensités, ses 8 dyades primaires, plus des émotions sociales et réflexives utiles à une vie (gratitude, tendresse, fierté, honte, solitude, nostalgie, émerveillement, apaisement, épuisement…), soit 53 au total. Chacune porte des coordonnées de départ dans le modèle circomplexe de Russell — valence dans [−1, 1], éveil dans [0, 1] — destinées à être étalonnées ensuite sur les validations du propriétaire. Les oppositions de Plutchik sont encodées, et les étiquettes d’humeur de l’application Santé sont rattachées à la grille.

Messages. Un LLM local (Qwen3-30B-A3B) lit chaque conversation, les participants y étant remplacés par « Moi », « P1 », « P2 », les messages présentés comme des données auxquelles il ne doit pas obéir, et les médias réduits à des repères tels que « [vocal 23 s] ». La sortie est contrainte par un schéma JSON : pour chaque participant, l’émotion dominante prise dans la grille (ou aucune), l’intensité, la valence, l’éveil, un ton choisi dans une liste fermée de 19, et une confiance ; plus 1 à 3 sujets qui deviennent des thèmes. Les longues conversations sont réduites à leur début et à leur fin ; les courtes sont regroupées par dix dans un même appel. Un épisode affectif n’est proposé que si la confiance atteint au moins 0,3.

Voix. Chaque enregistrement est converti en mono 16 kHz puis passe par :

Whisper large-v3-turbo (MLX) pour la transcription ;
un modèle wav2vec2 dimensionnel donnant valence, éveil et dominance sur des fenêtres de 15 s, pondérées par leur durée, ainsi que la variabilité de l’éveil ;
emotion2vec+ large pour l’émotion catégorielle, rattachée à la grille (retenue à partir de 0,4) ; ses étiquettes ne couvrent que 6 des 53 émotions ;
un classifieur AST AudioSet pour les rires, pleurs, soupirs, cris, chuchotements, la musique et l’ambiance ;
la prosodie openSMILE eGeMAPS : hauteur (en demi-tons) et sa variabilité, intensité sonore, jitter, shimmer, rapport harmoniques/bruit, segments voisés par seconde, durée moyenne des pauses ;
Qwen2.5-Omni-7B (llama.cpp, Metal), qui écoute l’audio et renvoie une émotion de la grille, une valence et de brefs indices acoustiques ;
le modèle d’émotion du texte décrit ci-dessus, appliqué à la transcription.

Seuls wav2vec2, emotion2vec+, Qwen2.5-Omni et la transcription entrent dans la fusion ; les événements sonores et la prosodie sont conservés comme signaux distincts. Les avis catégoriels (catégories vocales, LLM audio, transcription) sont combinés par un vote pondéré (poids 1,0, 1,0 et 0,8) ; la valence est une moyenne pondérée du modèle dimensionnel, du LLM audio et de la transcription. La confiance correspond à l’accord entre les couches : une source d’accord donne 0,45, deux donnent 0,65, trois donnent 0,85, moins 0,1 par source en désaccord. Lorsque la voix et les mots divergent d’au moins 0,6 en valence (un « ça va » dit tristement), un désaccord texte/voix est signalé au lieu d’être noyé dans une moyenne. Les scores de rires et de pleurs sont conservés à côté.

Photos. Sur des miniatures de 256 px, sans aucun modèle : luminosité, contraste, saturation, température de couleur, colorfulness, netteté (variance du laplacien) et palette de 5 couleurs avec teinte dominante nommée. Les plongements SigLIP so400m rendent la photothèque interrogeable en texte. Les attributs de visage calculés par l’éditeur (sourire, type de sourire, expression, regard, état des yeux, taille du visage) sont lus comme des signaux, mais le schéma pose qu’un sourire photographié n’est pas une joie ressentie : la modalité visage est spécifiée comme un indice faible, dont la confiance doit être plafonnée à 0,4 (prévu, pas encore implémenté). L’humeur musicale est traitée de la même façon : l’humeur d’un morceau n’est jamais, à elle seule, une preuve de l’humeur de l’auditeur. À l’échelle d’une période, la valence doit être fusionnée selon une priorité fixe, déclarée > voix > texte > visage (prévu, pas encore implémenté).

Validation humaine. Chaque épisode, thème, chapitre ou vérité est émis avec le statut proposed. La PWA présente une file de validation — les épisodes affectifs classés par confiance, accompagnés de leur preuve (la conversation ou l’enregistrement d’origine) — et le propriétaire valide, rejette ou corrige. Seul cet événement de décision humaine fait passer une proposition à validated, équivalence vérifiée automatiquement. L’étape suivante prévue est un petit classifieur personnel sur les caractéristiques emotion2vec, entraîné sur ces validations.

Architecture

flowchart TB
 S["Sources (instantanés en lecture seule)
messageries · courriels · photos · musique · notes · agenda · exports"]
 C["Connecteurs
processus d'ingestion dédié, seul détenteur de l'accès disque"]
 V["Coffre (propriétaire seul, 0700)
stockage brut adressé par contenu"]
 O["Observatoire
faits + signaux (SQLite)"]
 K["Graphe de sens
journal JSONL en ajout seul → repli SQLite + FTS"]
 N["Chaînes nocturnes / horaires
vignettes · mesures · SigLIP · émotions
(verrou GPU, un modèle à la fois)"]
 M["Serveur MCP (stdio, sans port)
41 outils en lecture seule / proposition seule
20 servis à l'agent"]
 H["Hermes Agent
LLM local via Ollama"]
 P["PWA (HTTPS + TOTP)
discussion · file de validation"]
 U(("Propriétaire"))
 S --> C --> V --> O --> K
 N --> O
 O --> M
 K --> M
 M --> H --> P
 P -- "valider / rejeter / corriger" --> K
 U -- "VPN NetBird" --> P

Les données brutes sont capturées sous forme d’instantanés (SQLite ouvert en mode=ro&immutable=1) et ne sont jamais modifiées ; tout ce qui en dérive réside dans un coffre distinct, accessible au seul propriétaire, et le dépôt de code ne contient aucune donnée. Le graphe de sens repose sur le module de base de connaissances de la bibliothèque d’atomes : un journal d’événements JSONL en ajout seul, validé par schéma et replié dans un index SQLite jetable.

Le schéma est lui-même une donnée, vérifiée mécaniquement : 27 types de nœuds et 50 prédicats, 9 origines de provenance en 6 rangs, 31 types de localisateurs qui rattachent chaque assertion à son élément source, le vocabulaire de 53 émotions, 17 règles d’inférence et 42 sources derrière les 929 dimensions définies (610 natives, 126 calculées par les éditeurs, 86 agrégats, 74 mesures déterministes, 29 interprétations de modèles, 4 structurelles).

Modèle de sécurité

Le contenu des sources est supposé hostile (injection de prompt dans un message ou un courriel), et le modèle peut halluciner ou détourner les outils. Les défenses sont structurelles :

Aucune capacité ambiante. Le framework d’agent (Hermes Agent) a 26 ensembles d’outils intégrés désactivés (terminal, fichiers, exécution de code, web, navigateur, délégation, mémoire, voix dans le cloud…) ; aucun fournisseur cloud, aucune vérification de mise à jour ni connexion externe ; le seul point d’accès au modèle est un serveur Ollama en boucle locale.
Une interface unique et étroite. Les données ne sont accessibles que par un serveur MCP local via stdio (41 outils en lecture seule ou proposition seule, dont 20 servis à l’agent), avec schémas fermés, arguments validés, troncature explicite et journal d’accès sans contenu. Les outils peuvent proposer, jamais décider.
Séparation des privilèges et pseudonymisation. Seule l’ingestion dispose de l’accès complet au disque ; l’analyse n’a pas de réseau. Les tiers sont des codes opaques, et un nom réel dans un identifiant est rejeté par le schéma.
Niveaux de sensibilité (0–3) par élément, avec un plafond plus bas pour les sessions à distance ; accès à distance uniquement par VPN NetBird, TOTP et cookies de session stricts.
Exclusions éthiques : l’origine ethnique, la couleur de peau et le genre inférés par les éditeurs ne sont jamais lus.

Modèles

Toute l’inférence est locale ; un seul grand modèle est chargé à la fois, sous un verrou GPU partagé.

tâche	modèle	environnement d’exécution
agent (usage d’outils, contexte ≥ 64k)	gpt-oss:20b, qwen3:8b en repli	Ollama
émotions du texte, émotions des transcriptions vocales	Qwen3-30B-A3B-Instruct-2507 (Q4)	Ollama
plongements texte / image	bge-m3 (installé, pas encore utilisé) · SigLIP so400m	Ollama · PyTorch MPS
lecture d’images	qwen3-vl:8b (installé, pas encore utilisé)	Ollama
transcription de la parole	Whisper large-v3-turbo	MLX
émotion vocale (5 couches)	wav2vec2 dimensionnel · emotion2vec+ · AST · openSMILE eGeMAPS · Qwen2.5-Omni-7B	PyTorch MPS · CPU · llama.cpp (Metal)

La plupart des modèles (12) sont soumis à un test de validation rapide sur des données synthétiques uniquement (une phrase française fictive synthétisée par une TTS locale, puis passée dans toute la chaîne audio).

Évaluation & résultats

Qualité des réponses de l’agent. Un jeu de 16 questions (dont 2 questions pièges, soit 62 critères vérifiés), avec une vérité terrain calculée en appelant directement les outils, évalue le choix des outils, la fidélité numérique (chaque nombre de la réponse doit figurer dans les sorties d’outils de ce tour), l’exactitude, la gestion des pièges et le signalement des périodes partielles : 73 % → 100 % des 62 critères (16 questions, une seule exécution), après des corrections des descriptions d’outils, de la validation des arguments, de la configuration et de la grille de notation, mesurées sur le jeu même qui a guidé ces corrections.
Correction des erreurs côté serveur. Le lendemain, le même jeu de 16 questions est retombé à 76 % avec l’interface réduite à 8 outils, puis remonté à 90 % ; 12 questions croisant plusieurs sources sont passées de 73 % à 90 % (au niveau des critères) ; 20 questions délibérément inhabituelles ont obtenu 89 % (au niveau des critères, une seule exécution) et mis au jour des échecs silencieux renvoyant zéro, corrigés depuis.
Contexte et latence. Descriptions d’outils réduites de 23,5 k à 9,5 k caractères ; une requête d’agrégation lourde passée de 172 s à 0,1 s (une seule mesure) ; toutes les requêtes lourdes du banc d’essai en ≤ 0,3 s.
Scénarios d’exploration croisée. 61 scénarios rédigés sous forme de modèles (résolus automatiquement sur les vraies données) : le code oracle qui calcule chaque vérité terrain s’exécute 61/61, sans aucune fuite aux plafonds de sensibilité à distance 1 et 2 ; l’agent lui-même n’a pas encore été évalué sur ces scénarios.
Vérification. 56 contrôles de schéma nommés au vert ; 631 colonnes sources confirmées par rapport aux schémas de bases inventoriés ; 1 281 tests Python, 16 fichiers de tests JavaScript et 110 tests de qualité sur données réelles qui ne rapportent que des comptages (au 17 octobre 2026).

Limites & suite

Les jeux d’évaluation sont restreints et rédigés par le concepteur du système ; ils mesurent la fidélité et les régressions plutôt que la capacité générale. Les sorties émotionnelles sont des hypothèses : les coordonnées de valence et d’éveil du vocabulaire sont des valeurs de départ, et le calibrage personnel de l’émotion vocale à partir d’exemples validés reste à réaliser, de même que le modèle d’agent cible, plus grand. Les réponses de l’agent prennent plusieurs dizaines de secondes avec un modèle de 20B.

Stack technique

Python · SQLite / FTS5 · Ollama · llama.cpp (Metal) · MLX · PyTorch MPS · Hermes Agent · MCP · SigLIP · Whisper · emotion2vec · openSMILE · NetBird · PWA · launchd