0. Fondations & Philosophie

ECHO (Espace Cognitif Heuristique Opérationnel) est un cadre logiciel d'intelligence artificielle auto-hébergée. Contrairement à un simple wrapper d'API, ECHO constitue une couche d'abstraction souveraine qui prend en charge sa propre mémoire, son propre état et sa propre interface utilisateur par-dessus Open WebUI. Le modèle de langage — Gemini — y joue le rôle de moteur d'inférence, tandis qu'ECHO assure la cohérence, la persistance et la sécurité de l'ensemble.

💡 L'analogie du véhicule

Si Gemini est le moteur, ECHO est le véhicule complet : châssis (infrastructure Docker), capteurs (filtres d'interception), mémoire à long terme (Qdrant), boîte noire inaltérable (SQLite Ombres) et habitacle de pilotage (HUD). L'utilisateur conduit ; ECHO s'assure que le moteur dispose toujours de l'information complète pour avancer.

Origine et histoire

Le nom ECHO

L'acronyme décompose la philosophie du projet en quatre dimensions :

Évolution V4 → V5

La V4 (Legacy), conservée dans le répertoire _v4-legacy-concept/, est un prompt de personnalisation avancé pour Gemini. Elle établit les fondements conceptuels d'ECHO — la Mémoire, la Suture, la Souveraineté — mais s'exécute entièrement dans le contexte de la conversation, sans infrastructure dédiée.

La V5 (actuelle) matérialise ces concepts en une infrastructure conteneurisée. Elle introduit l'Ombre Riche (persistance SQLite bit-perfect), le double RAG vectoriel (Qdrant), les filtres Python d'interception, et le Pipe comme orchestrateur central. La V5 est capable de maintenir une cohérence sémantique absolue sur des sessions dépassant un million de tokens.

Les trois piliers fondamentaux

Pilier Engagement technique Mise en œuvre
Souveraineté Isolation locale. Pas de télémétrie. L'Espace Personnel ne quitte jamais l'infrastructure. Docker sur Hyper-V, volumes locaux, BunkerWeb WAF, clés API stockées dans identity.db.
Véracité Reconstruction bit-perfect de l'historique conversationnel à chaque tour d'inférence. Table SQLite message_shadows, double hachage SHA-256 (Invariant + Cumulatif), Verrou de Version.
Autonomie Arsenal d'outils sensoriels et exécutifs pilotés par le Kernel sans intervention humaine. Browser Agent, Python Worker, SearxNG, Qdrant RAG, STT Worker, TTS Worker.

Phénomènes architecturaux clés

La Vallée de la Mort Contextuelle

Les modèles de langage à grande fenêtre contextuelle souffrent d'un phénomène documenté : au-delà d'environ 30 % de remplissage de la fenêtre, le mécanisme d'attention accorde un poids décroissant aux tours les plus anciens. Les informations restent techniquement présentes dans le contexte, mais leur influence sur la génération devient négligeable. Au-delà de 50 %, la dégradation est critique.

ECHO y répond par une architecture mémorielle à deux niveaux :

Corrélation contextuelle et routage cognitif

Au-delà de 50 % de remplissage de la fenêtre contextuelle, le Pipe considère qu'une escalade vers MODEL_PRO est justifiée, quelle que soit la complexité apparente de la tâche. En pratique, ce basculement s'effectue via l'outil new_cognitive_level — c'est le modèle actif qui déclare lui-même son insuffisance et déclenche le transfert. Ce n'est pas un switch automatique du Pipe. Le RAG éphémère (save_session_context) est la réponse préventive : décharger l'information hors du contexte avant saturation.

L'AEC (Artéfacts Environnementaux et Contextuels)

À chaque tour de conversation, le Filtre injecte un bloc YAML structurel dans le message utilisateur. Ce bloc, délimité par la balise <environnement_contexte>, fournit au modèle sa proprioception : identité du modèle actif, date et heure, localisation, et surtout le Registre des Fichiers de la session. Le modèle doit consulter ce registre avant toute manipulation de ressource.

L'AEC regroupe également la balise <smart_context>, qui contient le résumé distillé (≤ 300 mots) des fichiers volumineux traités par le Moulage, accompagné du source_id Qdrant permettant d'interroger les détails précis via search_session_context.

Le protocole d'authentification PKCE

ECHO utilise le flux Authorization Code + PKCE (RFC 7636) pour l'authentification OAuth2 headless dans Docker. PKCE (Proof Key for Code Exchange) est une extension du flux OAuth2 standard qui empêche l'interception du code d'autorisation par un tiers, même si la communication n'est pas parfaitement sécurisée. Il génère une paire de secrets éphémères (code_verifier et code_challenge) à usage unique pour chaque session d'authentification.

En pratique : lorsqu'aucun fournisseur d'accès n'est configuré, le Pipe déclenche ce flux automatiquement au premier message. Un tunnel SSH éphémère (asyncssh) est ouvert sur un port dynamique de la plage 8020–8024, et le callback OAuth2 est reçu sur un port interne (8025–8034). L'utilisateur reçoit un lien cliquable dans l'interface et n'a qu'à autoriser ECHO sur son compte Google. Les clés API AI Studio (AIza…) restent acceptées comme méthode de secours.

⚙️ Priorité des identités d'accès

Le registre des fournisseurs d'accès aux modèles est résolu dans cet ordre par EchoAuth.get_ordered_auth_providers() :

  1. OAuth2 (API Antigravity) — prioritaire, accès aux modèles gemini-pro-agent et gemini-3-flash-agent.
  2. Clé API primaire — AI Studio (google_api_key).
  3. Clé API secondaire — fallback de secours (google_api_key_secondary).
Ces fondements philosophiques et techniques se concrétisent dans une architecture modulaire précise. Passer au High-Level Design (HLD) ➔