Everythink Studio
Architecture globale du système

Six sections, un seul système

De la vision produit à l'implémentation réelle : backend Rust, frontend Next.js, déploiement et feuille de route.

L'espace est le routeur

Chaque personne possède sa propre organisation personnelle et souscrit à n organisations. Chaque organisation — entreprise · gouvernement · syndicat · communauté — contient n réseaux ; chaque réseau contient n communautés ; chaque communauté contient n salles. Chaque nœud a son propre multipolygone : l'inclusion s'applique vers l'intérieur (communautés fragmentées à l'intérieur du polygone du réseau) ou vers l'extérieur (communautés en dehors du polygone). La topologie est fractale au sens mathématique : chaque niveau est une copie auto-similaire du précédent — S = ⋃ fᵢ(S), l'attracteur de l'opérateur de Hutchinson (théorème du point fixe de Banach). Les réseaux interopèrent entre eux (fédération) : un réseau se connecte à un autre en ne partageant que ce qui est public. Quand une personne rejoint une organisation, elle accède à ses n communautés et n salles. Le travail qu'elle y accomplit est suivi dans l'organisation et refléchi dans son organisation personnelle : il génère une réputation par personne, se distille en problèmes résolus, et ceux-ci sont copiés dans son réseau personnel, qui les suit. À partir des réponses accumulées, HAI construit une couche de contexte par utilisateur.

Les quatre couches de la plateforme

Chaque couche supérieure compose les garanties des couches inférieures sur des interfaces typées. Produits (modules v1) : HAI, Matchmaking, Chat, Calendar, Market, Social. Au-dessus des 4 couches, 10 instanciations sectorielles.

Trois principes qui gouvernent l'architecture

Chaque principe est une garantie vérifiable, pas une déclaration d'intention. Ensemble, ils établissent la règle de composition (de bout en bout), la règle de multiplication sectorielle (héritage sans modification) et la règle d'honnêteté (implémenté et mesuré = garantie).

Moteur HAI — 13 types de questions

En production depuis 2016. Une prémisse volontairement étroite et composable : une interaction est un workflow de questions typées, et la plateforme est une topologie géolocalisée pour que chaque réponse atterrisse dans un contexte bien défini. En v2, le moteur s'exécute sur deux couches d'inférence : le réseau appris (déterministe, sans LLM) et l'inférence A2A, qui complète les nœuds qui n'existent pas et effondre le réseau.

Calendar — vendre des services et gérer l'agenda

Un vendeur propose des services (type_event) avec prix, catégorie et disponibilité ; les clients réservent (event) avec participant, date et lieu. En mode white-label, tout vendeur du même réseau est visible et commandable — « d'autres vendent dans mon réseau ». Le paiement crée un marchand dans le réseau et retrouve les produits par product_key.

Market — vendre des produits et laisser les autres vendre dans mon réseau

Le vendeur liste des produits (market_product) avec marchand, fournisseur et prix, et leur attache des offres/coupons. Le client construit le panier (market_item) et paie (merchant_tx) avec la clé du réseau estampillée dans json_data. Litiges et évaluations des deux côtés. Les marchands sont liés au réseau par merchant.network — « d'autres vendent dans mon réseau ».

HAI + matchmaking + chat — le réseau personnel de chaque utilisateur

HAI remplit le réseau personnel de chaque utilisateur en comprenant ce qu'il cherche : les réseaux sont peuplés automatiquement depuis le site web ou la doc de l'entreprise/gouvernement/communauté/syndicat, les flux de questions sont générés, tout comme les liens croisés entre matchings de salles différentes (même communauté ou non). Le matchmaking automatise des processus : une intention utilisateur → un bon de commande dans le canal de dispatch de la communauté, géolocalisé dans la salle cible. Chat en temps réel sur socket + FCM. Les flux sont transverses (ils traversent les salles) et s'exécutent sur les deux couches d'inférence : le réseau appris + A2A, qui complète et effondre.

Social — promotions du réseau et interaction utilisateur

Le réseau lance des promotions dans son espace et les utilisateurs interagissent dans un module social : news/stories avec likes et commentaires, catégories définies par l'admin. Le feed social vit dans la topologie — le réseau publie, la communauté fragmente, la salle reçoit.

Deux couches d'inférence — le réseau neuronal qui s'effondre

Tous les modules vivent dans les salles d'un réseau et sont transverses : un dataflow (HAI) depuis une salle d'invités avec du pré-vente se connecte à celui d'un client avec du support technique. Contrairement à v1 (graphes statiques), ici il y a des réseaux de neurones : si le nœud suivant n'existe pas, A2A détermine les étapes suivantes, les enregistre, et le réseau s'effondre. Le périmètre est fini — ce qu'un utilisateur demande dans un réseau est enregistré pour tous — et la consommation LLM via A2A diminue avec le temps, elle n'augmente jamais.

Isolation multi-tenant vérifiable

Entreprises, gouvernements, ONG et communautés partagent un seul substrat IA depuis 2016, en gardant ce qui est privé provablement privé. Médiation complète par le Reference Monitor ; le seul canal autorisé = les périmètres publics.

Réseaux fédérés et matchmaking stable

Les réseaux se fédèrent via leurs projections publiques. Le matchmaking opère uniquement sur les périmètres publics dans un rayon de proximité ; acceptation différée → appariement stable.

Recueil typé — apprendre en quelques questions

Le système pose la question, l'utilisateur répond, et la réponse devient du contexte. Le recueil est typé (le moteur calcule sans surprises), fidèle et efficace. Il s'exécute sur la couche 1 (réseau appris, déterministe) ; quand un nœud n'existe pas, la couche 2 (A2A) détermine les étapes, les persiste, et le réseau s'effondre — apprentissage en quelques questions, et chaque nouvelle question est enregistrée pour tous.

Workflows agentiques — l'enveloppe

Certains nœuds exigent du travail ouvert : un agent LLM qui entrelace raisonnement et appels d'outils (style ReAct) jusqu'à obtenir une réponse du bon type. C'est la couche d'inférence 2 (A2A) : quand le nœud suivant n'existe pas dans le réseau appris, l'agent détermine les étapes suivantes, les persiste, et le réseau s'effondre — la consommation LLM diminue avec le temps, elle n'augmente jamais. L'enveloppe borne les trois modes de défaillance.

Assistance proactive — la valeur de l'information

L'inverse d'un chatbot réactif : il initie au lieu d'attendre. Le difficile est la retenue — ne parler que lorsque la valeur nette attendue du passage à l'action dépasse celle du silence.

Autorité bornée et provenance

Un agent capable d'agir — dépenser de l'argent, contacter des tiers, déplacer des données — doit être borné par ce à quoi l'utilisateur a consenti, n'utiliser l'information que pour la finalité donnée, et laisser une trace qui permette d'expliquer et d'annuler.

Réseaux autonomes au service des réseaux humains

Délégation bornée, allocation contract-net (annonce → enchère → attribution), et la limite honnête de la coordination : la vivacité uniquement sous synchronie partielle.

Sécurité et protocole de preuve

Dix instanciations sectorielles

Chaque déploiement sectoriel instancie les couches 1–4 sans les modifier et hérite de leurs garanties.

Production / conception / projeté

17 crates, hexagonal, un seul Postgres

Racine de composition (api) → cas d'usage ×10 → adaptateurs (ledger, a2a, courier) → domaine (core, ZERO I/O). Un seul Postgres (Timescale pg17 + pgvector) pour tout : ledger, événements, embeddings, geo-cache jobs/whisper. SQL vérifié à la compilation (cache offline .sqlx/, 107 requêtes).

Ports & adaptateurs — le domaine au centre

Le domaine (everythink-core) ne connaît aucun I/O. Les adaptateurs implémentent les ports pour la DB, l'email, A2A. Les cas d'usage orchestrent. La racine de composition (everythink-api) câble tout.

Pourquoi tant de crates — un rôle explicite par crate

Chaque crate a un rôle : racine de composition (api), client (sdk, cli), cas d'usage ×10, adaptateur d'infra (a2a, courier), ports + persistance (ledger), domaine (core).

17 crates convergent vers core

everythink-api est le hub ; tout dépend de core (ZERO I/O). Le SDK vit à l'intérieur du workspace (backend/crates/everythink-sdk) car il est couplé à core.

De l'authentification à la persistance — une requête complète

Client → api (auth + rate-limit + validation) → loom (exécution) → ledger (résout le profil via le trait de repo) → sisters (fan-out) → oracle (merge → Ensemble normalisé) → ledger (persistance) → 200 OK.

Six cas d'usage : orchestration, authentification et données

loom — orchestration : persiste via le port LoomStore / l'adaptateur LoomPersistence. ingest — pipeline de signaux : traite les signaux entrants. scry — sentiment : le port de référence SentimentReader / PgSentimentReader. eval — harnais de régression : évaluation continue. warden — auth : JWT access/refresh, Google OAuth, binding IP. whisper — webhooks signés HMAC avec livraison exactement une fois.

Chaîne de middleware — trace → timeout → CORS → routage

Requête entrante → Trace + request_id → Timeout 60s → 408 → CORS + compression → sous-arbre de routes à 5 branches.

Trois régimes d'authentification coexistent sur un seul routeur

Public (probes/register/login/refresh) · Eye-Key (HMAC, rate limit glissant de 60s) · user-JWT (warden, Console) · Atlas WS (auto-authentifié, plafonds par utilisateur).

RBAC sans héritage — une seule fonction, une matrice explicite

can(role, action) en const fn : Owner → true ; Profile Read/Write Self → true ; match explicite sur (role, action) ; le reste → Owner uniquement. AUTHORIZE dans le handler → 403 en cas de refus.

Un seul datastore pour tout

timescale/timescaledb-ha:pg17 + pgvector (vector(1024) + HNSW). Un seul pool. Six domaines de données : Ledger, Simulations, Users, Embeddings, geo_signals, Jobs. Health check : pg_isready dans docker-compose (service_healthy).

Persistance via un port, jamais via un concret

TRAIT de repository · Pg*Repository (tout le SQL vit ici) · MockRepository (tests sans DB) · AppState : Arc<dyn Repository> · les cas d'usage appellent le TRAIT.

SQL vérifié à la compilation, migrations réversibles

Éditer .up.sql + .down.sql (appariés) → just sqlx-prepare → committer .sqlx/*.json (107 requêtes) → build/CI avec SQLX_OFFLINE=true et sans DB vivante.

Health checks + SQLX offline — déploiements précis

docker-compose : postgres (pg_isready, 10s/5s/10) → dragonfly (redis-cli ping, 10s/3s/10) → api (service_healthy). app/admin : health check désactivé (distroless/static). CI : SQLX_OFFLINE=true avec le cache .sqlx/ committé.

SSE (Tide) + WebSocket (GeoHub) — fan-out par tuile

TideBroker : SSE avec sujets composites, broadcast 256, keep-alive 15s, reconnexion Last-Event-ID. GeoHub : WS avec DashMap[Tile → broadcast 64], pilotage du viewport, gzip opt-in.

Six cas d'usage d'orchestration et de données

everythink-warden — authentification utilisateur

everythink-whisper — webhooks signés et livraison durable

A2A (protocole) et Courier (email)

everythink-cli et everythink-sdk

Six invariants jamais violés

4 apps, 13 packages, une seule identité

web (:3000) · app (:3001) · admin (:3002) · mobile (Expo). Packages : types, sdk-core + façades, domain, ui, auth, api-client, telemetry, config.

Quatre surfaces, un backend, trois acteurs

Acteurs : utilisateur final (invité → authentifié) · développeur (Eye-Key) · admin/opérateur (staff). Surfaces : web/app/admin/mobile. API backend (REST + SSE sous /api/v1).

Conteneurs — le monorepo complet

4 apps + couche SDK (6 façades) + services (4) + design system + tooling + types (feuille). Utilisez le zoom pour explorer.

web, app, admin, mobile — une par audience

Six façades, un cœur, zéro endpoint dans le cœur

sdk-core (HttpClient, consumeSSE, TokenProvider) · sdk-guest · sdk-auth · sdk-atlas · sdk-eye · sdk-admin.

Services applicatifs, UI et build

domain (mappers) · telemetry (outbox) · api-client (legacy) · auth (NextAuth v5 + RBAC) · ui (kit + tokens) · config (presets eslint) · types (Zod, feuille).

sdk-core sait le COMMENT, jamais le QUOI

Les endpoints vivent UNIQUEMENT dans les façades ; sdk-core valide chaque réponse avec Zod contre @everythink/types ; un arbre SdkError avec ContractViolation en cas de dérive.

Feature-Sliced Design + MVVM — les imports descendent

Screen (View) → hook view-model → feature.repository.ts (LA seule porte vers le SDK). Frontière ESLint no-restricted-imports (INV-1). Couches FSD : shared → entities → features → widgets → app.

Une connexion, une origine, quatre surfaces

apps/web /auth (une seule origine) → cookie httpOnly 'everythink_at' → token en mémoire + seed localStorage → EverythinkAuthGuard + resolveMe (GET /api/v1/auth/me) → gate basée sur le rôle.

can(role, action) — matrice explicite, sans héritage

3 couches : (1) auth.ts allowedRoles par app → (2) middleware → (3) can() dans l'UI + les server actions. Reflète everythink_core::rbac du backend.

Une seule stylesheet, tokens sémantiques, Tailwind v4

Une source unique de vérité pour le design : tokens CSS dans :root, mapping sémantique via @theme (Tailwind v4), et NativeWind pour le mobile avec des tokens miroirs. Les apps consomment des composants sémantiques (bg-accent, text-foreground, font-display/mono), jamais de hex bruts. Palette cosmic-purple : --gold: #d9ab5c, --violet: #9d7df5, --emerald: #10B981.

Zod à la frontière réseau — un contrat unique

Les types wire sont définis une seule fois dans @everythink/types avec Zod. Le SDK valide chaque réponse du backend (z.parse(response)) ; un payload invalide lève ApiError, jamais un crash. Les composants ne voient jamais le JSON brut : *.repository.ts parse, @everythink/domain mappe DTO → modèle, et le view-model expose un état typé à la View.

apps/mobile — Expo, expo-router, NativeWind

React Native avec expo-router (routage par fichiers) et NativeWind (Tailwind pour RN). Le système de thème reflète les tokens du design system web (tailwind.config.js + src/theme/index.ts). Il consomme sdk-guest, sdk-auth, sdk-atlas, domain et telemetry. Exclu de la CI web : --filter=!@everythink/mobile.

Quatre règles appliquées mécaniquement

Des règles vérifiables par ESLint + TypeScript, pas des conventions : (1) INV-1 : seul *.repository.ts importe un SDK (no-restricted-imports) ; (2) couches FSD : les imports descendent (shared → entities → features → widgets → app), le cross-feature passe uniquement par le barrel public ; (3) connexion partagée : web + app partagent localStorage('everythink:auth') + resolveMe() ; (4) RBAC 3 couches : auth.ts allowedRoles → middleware → can(role, action) dans l'UI + les server actions.

docker-compose.prod.yml — la stack complète

ALB (TLS) → nginx :80 → api (:18081, migrations au démarrage) · web (Next standalone) · app/admin (static distroless) · postgres (timescale/timescaledb-ha:pg17 + pgvector) · dragonfly (compatible Redis). 7 services : postgres · dragonfly · api · web · app · admin · nginx.

nginx comme point d'entrée unique

nginx :80 est le seul point d'entrée interne. Il route /api/v1/* → api:18081, / → web:3000, /app/* → static, /admin/* → static. web parle à api via EVERYTHINK_API_INTERNAL_URL (http://api:18081). api dépend de postgres et dragonfly avec condition : service_healthy.

backend/.env — le seul endroit pour les secrets

docker-compose.prod.yml monte backend/.env via env_file sur les services api et web. api détient tous les secrets (JWT_SECRET, EYE_KEY_HMAC_SECRET, GOOGLE_CLIENT_ID, BREVO_API_KEY). web ne reçoit que les variables NEXT_PUBLIC_* — il ne détient jamais BREVO_API_KEY. app/admin sont static distroless sans secrets dans le build.

Préprod directe vs la gate CI/CD

Deux chemins de déploiement : la préprod se déploie directement depuis l'arbre de travail (sans passer par main) ; la prod exige un merge vers main et la gate d'intégrité. La règle est critique : n'utilisez PAS le workflow deploy pour la préprod, car il tire le :latest de main et écrase le déploiement direct.

affected sur les PR, intégrité sur main

Un pipeline à 2 niveaux : le niveau PR n'exécute que ce qui est affecté (backend : ci-affected-crates.sh ; frontend : turbo --affected), le niveau main exécute l'intégrité complète (backend + frontend/mobile complets + E2E + sécurité). main reste vert et déployable.

Nœuds self-hosted fédérés · BYOK · DAO par réseau

Direction de la feuille de route pour v2. Rien de ce qui suit n'est une capacité existante. Flux : l'opérateur génère une paire Ed25519 locale → seul le fingerprint va au contrôleur (BYOK) → nœud self-hosted → ancrage du ledger → fédération sur les projections publiques uniquement → DAO du réseau.

Cinq phases vers v2

Architecture de référence de la chaîne candidate

Architecture de référence pour la notarisation des engagements de hash du ledger Postgres : Solana v0.8.13 (Yakovenko) — PoH comme horloge cryptographique, consensus PoS avec bonds/slashing, PoRep pour le stockage. Le choix de la chaîne est une décision explicite de l'opérateur ; ceci est une référence, pas une implémentation.