PROJET

FluidStore — backend universel à structure émergente

Base vectorielle multi-résolution MCP-native · Python + Qdrant + Supabase + Cloudflare Workers · embeddings Matryoshka 64/256/1024D

FluidStore — backend universel à structure émergente

FluidStore est un nouveau paradigme architectural : on ne définit plus la structure des données, elle émerge. Comme passer de l'Assembly au C, du C au Python — sauf qu'on abstrait la structure même des données.

Stack : Python · Qdrant Cloud · Supabase · Cloudflare Workers · OpenAI embeddings Matryoshka (64/256/1024D) · TypeScript MCP server.

Continuité avec Arcadium : recherche vectorielle FAISS sur Arcadium en 2023 → base vectorielle multi-résolution FluidStore en 2026. Pas un projet où je découvre les embeddings — c'est l'aboutissement de 3 ans de pratique.

Pourquoi FluidStore — l'angle architectural inversé

80 % du temps de dev est passé à architecturer les données : design du schéma SQL, migrations, débats normalisation/dénormalisation, refactoring quand le modèle se révèle insuffisant. Plus de temps à structurer qu'à créer.

Toutes les solutions actuelles demandent de définir quelque chose à l'avance :

  • Supabase / PostgreSQL : tu définis le schéma
  • Firebase : tu définis la structure
  • Notion / Airtable : tu définis les colonnes

FluidStore : tu ne définis rien. Tu balances tes données, le système comprend sémantiquement les relations. Le schéma émerge des vues que tu crées.

FluidStore n'est pas un concurrent à Notion, pas un outil de notes, pas une BDD vectorielle de plus. C'est un building block — une infrastructure pour construire des apps sans architecture mentale préalable.

Architecture FluidStore — 3 couches + embeddings Matryoshka

Architecture en 3 couches :

  • Qdrant Cloud — moteur de recherche vectorielle
  • Supabase (Postgres) — métadonnées, liens, hiérarchie
  • Cache RAM — chemins chauds

Embeddings Matryoshka multi-résolution — utilisation des embeddings Matryoshka d'OpenAI (text-embedding-3-small) tronqués à 3 résolutions :

  • 64D (courts fragments, < 100 caractères) — index ultra rapide, coût stockage minimal
  • 256D (résolution standard) — équilibre coût/précision
  • 1024D (documents importants) — précision maximale pour les recherches profondes

La résolution est choisie automatiquement à l'insertion selon la longueur et l'importance. Performance mesurée : recherche < 100 ms, stockage < 500 ms.

3 types de liens entre documents :

  1. Auto — similarité vectorielle > 0,3, calculée à l'insertion
  2. Forcés — link(from_id, to_id, weight) manuel pour exprimer une relation métier
  3. Inférés (Phase 2 — IA jardinier) — un agent qui propose des liens manqués en analysant le graphe

Architecture hybride Fluid + SQL

FluidStore ne remplace pas PostgreSQL — il le complète.

FluidStore PostgreSQL
Force Sémantique, découverte, liens auto, flexibilité Intégrité, permissions, ACID, prévisibilité
Usage Mémoire / découverte / contexte IA Source de vérité métier

Nouveau pattern architectural proposé :

Fluid Layer (sémantique)
    ↓
DB Layer (intégrité)
    ↓
Sync Layer
    ↓
Controller → View

Innovation conceptuelle : un schéma n'est plus une contrainte sur les données, c'est une vue projetée à la demande. Chaque vue créée par l'utilisateur définit un schéma implicite. Les données entrantes (webhooks, API, drop fichier) s'adaptent automatiquement aux vues actives. Une même donnée peut se conformer à plusieurs schémas simultanément.

Conséquence : plus besoin de migration. Une nouvelle vue = un nouveau schéma. Les données existantes se réadaptent.

Le serveur MCP FluidStore (déployé Cloudflare Workers)

URL : https://fluid-store-mcp.quaglieri-alexandre.workers.dev/mcp

Outils exposés à Claude (et tout client MCP) :

  • store — stocker un document avec embedding + métadonnées
  • query — recherche sémantique multi-résolution
  • get_context — document + tous ses voisins liés
  • deepen — passer un document à une résolution supérieure quand il devient central
  • link — lien manuel entre 2 documents
  • discover — lister les schémas (vues) disponibles
  • schema — créer/modifier une vue dynamiquement

FluidStore est utilisé pour ma mémoire IA — y compris pour générer ce portfolio (interrogation en langage naturel sur 6 ans de projets, pitchs, leçons).

Modèle économique et acquéreurs potentiels FluidStore

  • R&D Quatools — pièce stratégique du portfolio, finance long terme
  • Exploitation interne immédiate — utilisé sur les missions EPHI-SPORTS, Beelib, le Planificateur — gain de productivité direct sur chaque prestation
  • Acquéreurs potentiels identifiés : Supabase, Cloudflare, Vercel, Anthropic, OpenAI — toute boîte qui veut compléter sa stack data avec une couche sémantique
  • Modèle SaaS direct envisageable à terme : SDK + CLI + templates d'apps (CRM, wiki, project manager) — chaque app devient juste UI + FluidStore

Preuves et état FluidStore

  • Phase 1 livrée : API MCP fonctionnelle, dogfood en production sur tous mes projets
  • Performance mesurée : recherche < 100 ms, stockage < 500 ms
  • Cas d'usage validés :
    • Mon portfolio est rempli en interrogeant FluidStore (la mémoire de 6 ans de projets, pitchs, leçons est sémantiquement adressable en langage naturel)
    • Mémoire conversationnelle Claude : chaque conversation s'enrichit du contexte de tous les projets passés
    • Schémas dynamiques actifs : Planificateur (projects, tasks, timesheets), Lifememory (notes personnelles), EPHI-SPORTS (mission BPI)
  • Roadmap publiée : Phase 2A insertion (PDF/DOCX/audio/webhook), Phase 2B visualisation (graphe D3.js, clusters auto), Phase 2C View Generator (Claude génère le composant React de l'interface à la volée à partir d'une description en langage naturel)

« Tu ne choisis plus un outil (CRM, Notion, Excel), tu décris ce que tu veux voir » — la promesse finale de FluidStore : l'app devient juste l'interface, le moteur fait tout le reste.