Pour toute demande de devis, dispo, RDV ou question concrète, page contact : /alexandre/contact.
Moi, Alexandre Quaglieri, je suis un solo product builder. Une personne qui porte les 3 actes normalement répartis entre plusieurs personnes — le pourquoi, la construction, la mise sur le marché — et les exécute de bout en bout, sans téléphone arabe.
Une seule tête, une seule vision, une seule exécution.
Ce n'est pas un titre marketing : c'est l'opération réelle. J'opère sous Quatools (EI Quaglieri Alexandre, SIRET 520 181 520). Je développe seul un portefeuille d'outils SaaS AI-native — BAAS Esport, Calendr, Storm, FluidStore, Factur-IA, Planificateur — et je fais du conseil freelance en parallèle (Product Management, formation IA pour TPE/PME via CMA Occitanie, missions Diag Innovation BPI France où j'interviens en aval du dossier monté par Inizia).
Pendant 6 ans à Arcadium, j'ai cherché à résoudre un problème qui m'a coûté très cher : la perte de signal entre ce que je voulais qu'on construise et ce qui revenait codé.
Tous les profils y sont passés. Des devs débutants. Des devs seniors. Des équipes structurées. Des freelances ponctuels. Personne n'a jamais réussi à combler ce manque. Ce n'est pas un problème de compétence — c'est un problème structurel de la transmission humaine.
Concrètement : j'expliquais ce qu'il fallait construire, ils partaient coder, et au retour ça fonctionnait à 95 %. Les 5 % manquants, c'est ce que j'appelle la dette d'information. Soit on renvoyait pour refaire — coûteux et démoralisant. Soit on poursuivait avec les 5 % perdus.
Et il y avait l'autre couche du problème : l'alignement humain. Une nouvelle personne arrive au marketing, elle a une vision différente, elle demande des choses différentes — et on refond. Un nouveau PM entre dans l'équipe, ses priorités ne sont pas celles du précédent — et on refond encore. Chaque arrivée recale le produit sur une nouvelle vision, sans jamais converger.
Le 9ème mois de développement, le constat tombait : ces 5 % accumulés à chaque sprint plus les refontes liées aux changements d'équipe avaient généré des retards monstrueux, des reprises en cascade, des coûts faramineux. À l'époque, faire une app prenait 14 mois. Aujourd'hui, un solo product builder avec l'IA fait l'équivalent en quelques semaines.
Aujourd'hui, je n'ai plus cette dette. Pas parce que je suis meilleur — parce que je porte la vision et l'exécution dans la même tête, et parce que cette tête ne change pas. L'IA me permet de coder à la vitesse d'une équipe sans la perte de signal qu'une équipe génère, et sans les recadrages à chaque changement de personne.
C'est la raison de mon positionnement aujourd'hui. J'aime gérer de bout en bout. J'ai appris en faisant tous les postes sur Arcadium, et je peux maintenant tout faire de bout en bout pour apporter le plus de valeur possible à mes clients, sans me cacher derrière personne. Ce que je fais, j'en suis le seul responsable.
Quand j'ai démissionné d'EDF à 27 ans pour lancer Arcadium, j'ai cherché — sans le trouver — un partenaire qui réunissait :
Personne ne réunissait tout ça. Aujourd'hui, c'est exactement ce que je propose. « Je suis le partenaire que j'aurais voulu trouver en face de moi à 27 ans. » Celui qui sait quoi faire — et surtout ce qu'il faut ne pas faire.
L'intuition dit « plus de têtes = mieux ». Sur des projets de petite à moyenne envergure, la réalité dit le contraire.
Pieter Levels, Marc Lou, Tony Dinh, Danny Postma — une génération entière de builders solos atteint en duo ou seul des résultats que des séries A peinent à reproduire. La méthode est validée, juste sous-représentée en France.
Tout ce que je construis pour un client est exposé via MCP, donc utilisable depuis Claude, depuis un agent custom, ou depuis n'importe quelle UI. Pas un « AI-powered » marketing — une vraie API canonique pour agent.
En 2022, j'ai construit un système de matching joueurs / clubs en Python avec FAISS — la bibliothèque de recherche vectorielle de Meta — pour Arcadium. Personne autour de moi ne savait que ça existait. Aujourd'hui c'est partout. « J'ai 4 ans d'avance non pas parce que j'ai prévu, mais parce que je vais chercher la solution là où elle est, pas là où c'est à la mode. »
La même logique vectorielle structure aujourd'hui FluidStore (cf. projet fluidstore), et les serveurs MCP sont partout dans le portefeuille (BAAS, Calendr, Storm, Factur-IA, Planificateur). AI-native n'est pas un mot-clé, c'est une doctrine d'architecture.
Pas de démo générique, pas de slide stock, pas d'exemple « imaginons que… ». Je travaille sur ce que le client a sur la table, et le résultat est utilisable dès la première session.
C'est particulièrement vrai sur les formations IA : on apporte ses propres documents, son propre métier, ses propres frictions — et la session devient un atelier de travail réel, pas une session théorique.
2 ans d'alternance RTE sur le réseau haute tension 63-400 kV à Nîmes (2008-2010) — où j'ai appris la rigueur opérationnelle sur des systèmes critiques avant même d'entrer dans le nucléaire.
10 ans d'industrie nucléaire EDF Cruas-Meysse — technicien spécialisé électrotechnique, préparateur méthode, formateur réactif national. Où j'ai vu combien d'idées meurent dans les comités, et où j'ai appris à porter une responsabilité technique sur des systèmes où l'erreur n'est pas une option.
6 ans d'entrepreneuriat SaaS jusqu'au bout du cycle : création, levée, croissance, pivots, liquidation propre 2025.
3 opérations immobilières menées de bout en bout — dont une autoconstruction primée par sa technicité.
Un prix d'innovation industrielle EDF.
Cette accumulation n'est pas un CV — **c'est ce qui me permet de dire vite « ne faites pas ça » quand je sens venir un piège que j'ai déjà payé.**
C'est la doctrine "Builder lucide" : direct, sans bullshit, j'assume les échecs (la liquidation Arcadium en particulier), et j'utilise mes propres erreurs comme matière pour aider d'autres porteurs de projet à les éviter.
Chaque session de formation m'oblige à clarifier mes méthodes, à les simplifier, à les défendre face à des questions naïves. Les clients récupèrent du code mieux pensé parce qu'il a été expliqué la semaine d'avant à une salle.
Légitimité formation :
Concrètement aujourd'hui : interventions Bac+5 marketing/commerce (séminaire IA novembre 2025, étudiants opérationnels en 5h), formations CMA Occitanie pour TPE/PME, modules courts sur l'usage pro de l'IA, l'appel d'offres public, le positionnement business.
Premier principe de ma façon de travailler : le client parle à la personne qui code, qui pense le modèle, qui dit « ne faites pas ça » quand c'est juste. Pas un commercial qui répète, pas un PM qui transmettra, pas un dev qui reformulera.
Pendant 6 ans à Arcadium, j'ai porté seul produit + dev + business + juridique + comptabilité + RH. J'ai tout pris en pleine figure. C'est là que j'ai compris ce qu'un client attend vraiment de quelqu'un comme moi : pas un expert d'un domaine, un homme-orchestre qui fait tenir le tout debout.
C'est la phase de conception amont, avant la ligne de code. Comprendre ce qui fait acheter les clients, identifier qui est prêt à payer, construire l'offre.
## Ce que je livre dans cet acte
## Le pourquoi — JTBD, terrain, conversations
Je commence par le manque, jamais par la solution. JTBD, terrain, conversations clients, données d'usage — ce qui paie n'est pas toujours ce qui crée le plus de valeur, et l'écart entre les deux est tout le job.
Mini-exemple Arcadium : 99,9 % des joueurs esport sont amateurs (500 millions dans le monde), sans club, sans coach, sans identité collective — alors qu'ils vivent leurs victoires et défaites avec la même intensité que les sportifs traditionnels. Là était le pourquoi. Pas dans la techno, pas dans la marque, dans le manque structurel d'encadrement.
## Le modèle économique — qui paie, quand, comment
Le modèle économique, c'est moi qui le conçois — c'est ma valeur ajoutée principale sur l'acte 1. Pas dans la dimension financière comptable, dans la dimension produit : qui paie, quand, comment, à quel prix, avec quelle mécanique de capture.
## Ce que je ne fais pas dans cet acte
C'est tout l'objet de l'acte 1.
C'est là que la plupart abandonnent ou délèguent. Je code. Concevoir techniquement et livrer le produit en exploitation.
## Ce que je livre dans cet acte
## Trois piliers de cet acte
Stack moderne maîtrisée — Next.js, Astro, Supabase, Cloudflare, MCP, embeddings vectoriels, Stripe Connect, FullCalendar pro, Expo mobile.
Rigueur opérationnelle héritée de 10 ans EDF — RLS multi-rôle, OAuth Authorization Server complet, conformité réglementaire (Factur-X, Chorus Pro), gestion des cas critiques.
Discipline AI-native — MCP comme API canonique sur chaque outil, pas chatbot ajouté par-dessus.
C'est l'acte que la plupart des fondateurs techniques ratent : croire que livrer = vendre. Construire un produit qui marche ne suffit pas, il faut savoir le mettre en face de gens qui paient. Et c'est la leçon centrale que j'emporte d'Arcadium.
## Ce que je livre dans cet acte
## Quatre disciplines de mise en marché
1. Valider la conversion avant la production — Arcadium : 200+ joueurs interrogés à l'été 2019, 90 signés sans aucune plateforme. La vente précède le code.
2. Construire les pipelines d'acquisition — Pas attendre les clients passivement. Identifier les canaux, les outiller, les nourrir avec un rythme tenable.
3. Lancer les premières campagnes — Tester les messages, mesurer les taux de transformation, identifier le segment qui répond le mieux.
4. Itérer le go-to-market au même rythme que le produit — A/B test des messages, validation des canaux, boucle commerciale → feedback produit → ajustement.
Ma méthode se décompose en 3 actes systématiques, dans cet ordre. C'est le vocabulaire de référence — toute description de ce que je fais utilise ces trois noms exacts et leur contenu défini ci-dessous.
## Acte 1 — Le pourquoi
Comprendre ce qui fait acheter vos clients, identifier qui est prêt à payer, construire votre offre.
Ce que je livre dans cet acte :
Ce que je ne fais pas dans cet acte :
## Acte 2 — La construction
Concevoir techniquement et livrer votre produit en exploitation.
Ce que je livre dans cet acte :
## Acte 3 — La mise sur le marché
Trouver vos premiers clients, valider votre conversion, itérer.
Ce que je livre dans cet acte :
## Pourquoi cette séquence est non négociable
Aucun acte n'est sautable. Un projet mal construit à l'acte 1 (mauvais modèle économique, demande mal identifiée) ne se rattrape pas plus tard. Une livraison sans projet construit devient feature gratuite. Et une livraison qui ne se vend pas reste un actif mort.
C'est aussi pourquoi je suis solo product builder. Quand les 3 actes sont répartis entre 3 personnes différentes — un commercial qui identifie le besoin, un dev qui livre, un marketeux qui vend — chaque transmission érode l'information. Maîtriser les 3 actes en une seule tête, c'est éliminer ces frictions et cette perte d'information. Pas un luxe, une condition de cohérence du résultat.
## Ce que je NE fais PAS comme service (clarification de positionnement)
Ce que j'ai déjà fait moi-même reste légitime comme preuve de capacité — levée Arcadium ~1 M€, AO CMA Occitanie gagné en 2026 — mais ce n'est pas ce que je propose comme service à mes clients.
Le réflexe « de l'idée au premier client » est ma constante. Industrie (prix d'innovation EDF), immobilier (3 opérations dont une autoconstruction primée par sa technicité), logiciel (Arcadium, BAAS, Storm, FluidStore, Factur-IA…) : trois domaines, trois fois la même boucle.
Cette boucle se décompose en 3 actes systématiques, dans cet ordre :
1. Le pourquoi — comprendre ce qui fait acheter les clients, identifier qui est prêt à payer, construire l'offre
2. La construction — concevoir techniquement et livrer le produit en exploitation
3. La mise sur le marché — trouver les premiers clients, valider la conversion, itérer
Aucun acte n'est sautable. Un projet mal construit à l'acte 1 (mauvais modèle économique, demande mal identifiée) ne se rattrape pas plus tard. Une livraison sans projet construit devient feature gratuite. Et une livraison qui ne se vend pas reste un actif mort — c'est la leçon centrale que j'emporte d'Arcadium.
C'est aussi pourquoi je suis solo product builder. Quand les 3 actes sont répartis entre 3 personnes différentes — un commercial qui identifie le besoin, un dev qui livre, un marketeux qui vend — chaque transmission érode l'information. Le dev recode mal le besoin du client. Le marketeux survend ce que le produit ne peut pas livrer. Le modèle économique conçu en amont n'est plus appliqué avec rigueur en aval. Maîtriser les 3 actes en une seule tête, c'est éliminer ces frictions et cette perte d'information — pas un luxe, une condition de cohérence du résultat.
La formation n'est pas une activité ajoutée tardivement — c'est une pratique installée depuis 10 ans (formateur réactif national EDF 2014-2020). Aujourd'hui 4 terrains actifs en EI Quatools :
1. CMA Occitanie — Marché public formation artisans
2. Oxytalis Campus — Formation supérieure
3. CSJC Ajaccio — Marketing dans l'esport (historique Arcadium)
4. MUC Omnisports — Formation IA & partenariat esport
L'IA comme outil d'apprentissage, pas comme sujet de débat
Anecdote vécue en formation IA : un élève donne la trame du formateur à Claude et s'en sert comme guide pour avancer. Meilleur résultat de la classe. Quand je demande l'avis aux autres, ils se liguent contre lui. L'ironie : c'est lui qui a le mieux compris la consigne ET l'outil.
Conclusion pédagogique : le vrai skill, c'est savoir utiliser l'IA — pas la rejeter, ni la subir. Mes formations IA ne sont jamais « voici ce que ChatGPT peut faire » mais « voici comment on fait avancer un vrai problème métier en s'aidant de l'IA ». L'élève sort avec un cas concret travaillé sur ses propres documents.
Hands-on, cas concret, supports vivants
Adaptation au public — l'expérience EDF (techniciens manuels) + Arcadium (joueurs et coachs) + Bac+5 + artisans + entrepreneurs atypiques = capacité à recalibrer le niveau, le vocabulaire et les exemples selon la salle. Pas de copier-coller de modules.
L'école traditionnelle traite mal les profils non-linéaires : TDAH, dyslexie, parcours non scolaire, autodidactes. Ils sont souvent les plus créatifs en entrepreneuriat — et les plus mal servis en formation classique.
Mon pari : adapter les supports et le rythme aux modes d'apprentissage non standard. Concrètement :
Ce positionnement vient à la fois de mon expérience formateur (les meilleurs résultats sont chez ceux qu'on dit « réfractaires ») et d'une lecture personnelle assumée du fonctionnement cognitif atypique.
J'ai toujours trouvé que former renforce mes propres compétences. Chaque session m'oblige à revoir mes méthodes, les clarifier, les organiser, les simplifier — et surtout les challenger. Si je n'arrive pas à expliquer un pattern à un artisan ou à un étudiant, c'est que je ne le maîtrise pas vraiment.
Conséquence directe pour les clients dev :
> Pour le client : tu n'auras pas un formateur déconnecté de la pratique, ni un dev déconnecté de la transmission. Pour moi : la formation est mon vrai laboratoire d'amélioration continue.
Les tarifs dépendent du modèle d'engagement et de la nature de la mission. Je travaille en :
Pour un devis précis adapté à votre projet → /alexandre/contact. Les tarifs publics dépendent trop du contexte (durée, complexité, dispositif de financement) pour avoir du sens en grille standard. Une conversation de 20 min permet de cadrer le bon modèle pour vous.
Activités directement rentables : chaque session de formation est facturée, ce qui finance les phases plus longues du portfolio (R&D FluidStore, dev Quatools). Effet levier : les formations sont aussi le canal d'acquisition des clients pour les outils Quatools (BAAS, Calendr, Factur-IA) — la stratégie OKR Quatools le formalise : « Formation IA = canal d'acquisition → BAAS = revenus récurrents ».
Référencement Bpifrance Diag Croissance en cours pour ouvrir le canal des consultants Bpifrance.
J'opère sous Quatools (EI Quaglieri Alexandre) et je propose trois grands types de prestations qui couvrent les 3 actes de ma méthode :
1. Conseil en Product Management — la matière de l'acte 1. Identifier le pourquoi, construire le modèle économique, valider la stratégie de marché. Sortie : Value Proposition Canvas, Business Model Canvas, roadmap, grille tarifaire. Je ne monte pas les dossiers BPI ni les AO publics — ce travail relève de partenaires spécialisés (Inizia notamment) ; j'interviens en aval sur la mission elle-même.
2. Développement sur-mesure — l'acte 2 livré. Applications, outils internes, modules MCP, intégrations, refontes. Solo product builder qui prend produit + tech + livraison sans téléphone arabe.
3. Mise sur le marché — l'acte 3. Stratégie d'acquisition, construction des pipelines commerciaux, premières campagnes, boucle d'itération produit/marché.
4. Formation — pratique installée depuis 10 ans (formateur réactif national EDF). IA pratique, business model, marchés publics, communication digitale. Référencé CMA Occitanie + interventions Bac+5.
Toujours un seul interlocuteur (cf. profil-principe-un-interlocuteur). Toujours sur vos cas concrets, pas sur des slides génériques. Discussion contact via /alexandre/contact.
Au début de mon parcours EDF (CNPE Cruas-Meysse), j'ai conçu un outil de diagnostic pour la vérification des matériels de protection des tableaux industriels 380 V.
Le constat : les systèmes existants étaient purement manuels, lourds, encombrants et coûteux. Le manque : la vérification pouvait être semi-automatisée, et l'instrumentation allégée.
Résultat de l'innovation :
Reconnaissance : prix local de l'innovation sur le site, nomination au prix national EDF qui a suivi.
Ce que ça raconte : déjà à ce moment-là, la même boucle "repérer un manque concret + concevoir un produit + le pousser jusqu'à la mise en service" qui structure aujourd'hui Quatools.
Trois domaines (industriel, immobilier, logiciel), une même méthode en trois actes :
1. Identifier le manque et caler le modèle économique — ce que les solutions existantes ne couvrent pas, et comment on capte la valeur (dispositifs publics inclus dès l'amont)
2. Concevoir et exécuter la livraison — sans délégation paresseuse, jusqu'à un produit fonctionnel
3. Mettre sur le marché et vendre — convertir l'objet livré en résultat tangible : prix d'innovation EDF reconnu, plus-value immobilière captée, abonnés payants Arcadium, marché public CMA remporté
C'est exactement la signature qui structure le portfolio Quatools — appliquée bien avant Quatools, dans des contextes radicalement différents. La régularité du résultat à travers des univers aussi distants est la meilleure preuve que cette méthode tient.
Autoconstruction maison 130 m² à Alissas (Ardèche) — « le chef-d'œuvre »
Construite pendant la période EDF Cruas, conçue, planifiée et bâtie de bout en bout. Combinait :
Vendue en 2025 pour réallouer le capital après la liquidation Arcadium — choix rationnel douloureux, mais structurant.
Réhabilitation d'un hangar à Meynes (Gard) — création de deux logements (55 m² + 80 m²) pour mes parents, qui n'avaient jamais eu de maison stable. Ce qui valait la peine d'être protégé, je l'ai protégé.
Acquisition judiciaire studio 32 m² au Grau-du-Roi (Port-Camargue) — acquis aux enchères judiciaires, mise en location optimisée (Airbnb + LMNP), cash-flow récurrent.
Trois opérations, trois angles complètement différents — autoconstruction technique, réhabilitation à valeur ajoutée, opportunisme judiciaire — exécutées sans déléguer la conception ni la maîtrise d'ouvrage. La même boucle que j'apporte aujourd'hui dans le dev et le conseil business.
MCP (Model Context Protocol) est un protocole sorti par Anthropic fin 2024. Très peu de devs maîtrisent l'implémentation côté serveur. J'en ai construit 6 serveurs MCP custom en production :
Intégrations standards utilisées : Gmail · Google Calendar · Google Drive · Supabase.
C'est cette maîtrise qui me permet de positionner l'AI-native comme une vraie discipline d'architecture, pas un mot-clé marketing.
Implémentations que je maîtrise et qui sont rares dans l'écosystème SaaS français :
OAuth 2.1 + OAuth Authorization Server pour MCP (Factur-IA) :
Conformité réglementaire :
Cette rigueur opérationnelle vient directement de mes 10 ans EDF où l'erreur réglementaire ou de sécurité n'est pas une option.
Supabase est ma stack principale pour les apps multi-tenant. Plusieurs patterns avancés en production :
Multi-tenant par RLS (BAAS) — 20 tables, isolation totale par club, un joueur peut avoir un compte associé à plusieurs clubs en même temps avec son propre périmètre.
Multi-schéma (Calendr cohabite avec BAAS) — un seul projet Supabase héberge `public` (BAAS) ET `calendrier` (Calendr) avec isolation totale par schéma. Le code utilise systématiquement `.schema("calendrier")` pour ne jamais polluer l'autre app. Économie d'infra + cohérence multi-app Quatools.
RLS multi-rôle (Storm) — un même utilisateur peut être athlète + coach + admin avec des policies RLS qui composent proprement. Refonte de `public.users` source de vérité unique sur 34 fichiers. Données psychologiques classées sensibles RGPD.
Migrations propres — Storm a 40+ migrations en production (`questionnaire_engine_phase1/2/3`, `mbti_engine_phase1`, `mental_dimensions_catalog`, `psych_profiles`, `account_status`, `worksheet_library_system`, `learn_documents`). Pas de big bang, ajout incrémental.
Stripe Connect maîtrisé sur plusieurs configurations en production :
Arcadium (multi-flux B2C + B2B) — B2C abonnement mensuel + B2B abonnement annuel par utilisateur, sur la même base, avec gestion multi-clubs.
BAAS (commission split automatique) — les paiements vont directement au compte du club, BAAS prélève sa commission (2 %) via Stripe Connect. Pas de flux intermédiaire BAAS, pas de problème comptable.
Storm (commission par séance) — préparateurs mentaux comme comptes connectés, évite la double TVA sur les commissions plateforme.
Cette maîtrise n'est pas un sujet "j'ai lu la doc Stripe" — c'est 3 configurations différentes en production avec leurs spécificités fiscales et opérationnelles.
FAISS en 2022 sur Arcadium — recherche vectorielle (la bibliothèque ML de Meta) pour le matching joueurs ↔ clubs en production, bien avant la vague LLM grand public. Pipeline : DM Instagram → embedding → recherche FAISS → top 5 clubs → LLM choisit → réponse personnalisée.
FluidStore en 2026 — base vectorielle multi-résolution avec embeddings Matryoshka (`text-embedding-3-small` tronqué à 64D / 256D / 1024D selon longueur et importance). Architecture 3 couches (Qdrant Cloud + Supabase + Cache RAM). Performance < 100 ms en recherche.
Pas un coup de chance, une habitude technique : 4 ans de pratique vectorielle entre Arcadium 2022 et FluidStore 2026, avec une continuité conceptuelle directe.
Le portfolio que tu utilises est un chat IA conversationnel développé seul par Alexandre Quaglieri en mai 2026. Il sert deux objectifs : démonstration technique de ses capacités, et qualification honnête pour décider si Alexandre est pertinent pour un projet donné.
Stack technique :
Le corpus contient environ 100 chunks documentaires structurés (projets, méthode, parcours, tarifs, citations, doctrines), indexés sémantiquement et taggés par niveau pyramide UX (N0-N4) et topic (profil, methode, projets, stack, services, parcours).
Pas de framework de chat tout-fait. Tout est codé from scratch : la boucle agentique, le streaming, la gestion du cache de prompt, le routage de modèle, le tracking d'engagement, le système de panels. C'est délibéré — démontre la maîtrise du fond, pas juste l'intégration d'API.
Le code vit dans un repo privé sur GitHub. Stack de déploiement :
Workflow d'évolution du corpus :
1. Modifier les `.md` dans `src/content/portfolio/corpus/`
2. Lancer `npx tsx scripts/portfolio/ingest-docs.ts` (ou utiliser le MCP `document_upsert` pour injecter directement en DB sans redeploy)
3. Push sur `main`
4. Vercel rebuilds en ~25-30s
5. Optionnel : relancer `warm-cache.ts` si les chips initiales changent
Pages SEO statiques en parallèle :
Total : 11 pages statiques prerenderées + 1 SPA chat (`/alexandre`) + 4 API routes serverless.
Tout est tracé en DB Supabase. Tables :
Page admin SSR sur `/alexandre/admin/usage` (HTTP Basic Auth via env vars `ADMIN_USER` + `ADMIN_PASSWORD`) avec :
Le calcul de coût applique les tarifs Anthropic exacts :
Page protégée + endpoint `/api/admin/probe` qui diagnostique la conf admin (longueurs des env vars, comparaison de credentials sans exposer les secrets). Pratique pour résoudre les bugs d'auth.
Ce chat lui-même est une démonstration de ce qu'Alexandre peut construire seul, en 3 semaines de mai 2026 :
Si tu te demandes si Alexandre peut construire un système conversationnel sur mesure pour ton SaaS — un agent client, une assistance produit, un onboarding intelligent — ce chat est la preuve. Tu peux demander à l'agent comment il est construit et il te répondra avec substance, parce que cette documentation fait partie de son corpus.
C'est le test ultime d'un produit AI-native : il sait expliquer comment il fonctionne.
Une mécanique différenciante : on track le parcours du visiteur dans les panneaux sans faire un seul appel API tant qu'il n'a pas posé de question.
Côté client : un `useEffect` sur l'ID du panneau actif capture l'entrée et le départ. La cleanup function fire avant le changement de panneau, ce qui permet de calculer le delta en secondes et de l'ajouter à un `dwellMapRef`. Un listener `visibilitychange` met le compteur en pause quand l'onglet passe en background.
Au moment de la question : le client envoie `navigation: ['arcadium', 'baas', 'tarifs']` + `dwell: { arcadium: 134, baas: 4, tarifs: 45 }` dans le body POST. Le serveur traduit en signal qualitatif :
L'agent reçoit ça dans le dynamic suffix : "Avant cette question, le visiteur a navigué : 'Arcadium' (2 min 14s, creusé) → 'Sport Manager' (4s, survolé) → 'Tarifs' (45s, lu)". Il adapte sa réponse au signal sans commenter explicitement la navigation.
Coût : zéro avant la première question. Quel que soit le temps passé à explorer, quel que soit le nombre de panneaux cliqués, on ne paie rien tant que le visiteur n'engage pas activement.
Le différenciateur visuel principal : au lieu d'un scroll infini comme la plupart des portfolios IA, l'interface a deux zones complémentaires :
Panel à gauche = le QUOI : structure visuelle du concept, listes synthétiques, schémas, screenshots. C'est le contenu scannable en 10 secondes. Format informationnel, dense.
Chat à droite = le POURQUOI : histoire derrière le concept, conviction, expérience vécue, débat. Format narratif et conversationnel.
Quand le visiteur pose une question, l'agent appelle le tool `show_panel(type, id)` pour afficher un panneau correspondant à gauche, pendant que sa réponse texte streame dans le chat. Le speech apporte la profondeur que le panneau ne montre pas — c'est de la complémentarité, pas de la paraphrase.
Conséquence pratique : la même question peut afficher des contenus très différents selon le profil du visiteur détecté (prospect vs recruteur vs pair builder). Les panneaux sont des JSON validés Zod au build, donc pas de chance d'incohérence runtime.
Première version du portfolio : à chaque page load, on faisait un prefetch des 4 chips initiales en API pour avoir des réponses instantanées au clic. Coût observé : ~20¢ par page load avant que le visiteur engage. Sur un test dev où la page est rechargée 25 fois → ~$5 gaspillés.
Refactor : les réponses des chips initiales + default_followups sont pré-calculées une seule fois via le script `scripts/portfolio/warm-cache.ts` et stockées dans `src/lib/portfolio/preloaded-answers.json`. Au mount, `PortfolioApp` injecte ces réponses dans son `cacheRef` Map.
Résultat : un visiteur qui clique sur "Je débarque, présente-moi Alexandre" obtient la réponse instantanément depuis le cache client. Zéro appel API. La réponse est computée 1 fois (par Alexandre quand il régénère), servie à des milliers de visiteurs.
Le warm-cache se relance quand le system prompt change, le corpus est re-ingéré, les chips elles-mêmes changent, ou le modèle par défaut change. Coût one-shot ~$0.80 (4-7 chips × Haiku).
Le system prompt fait environ 150 lignes (~3000 tokens) + tools schema (~2000 tokens) = ~5000 tokens fixes envoyés à chaque tour. Sans optimisation, sur un agentic loop de 4-5 itérations, c'est 25 000 tokens d'input rien que pour le contexte.
Optimisation appliquée : prompt caching Anthropic avec `cache_control: { type: 'ephemeral' }` placé sur (1) la fin du system prompt statique, et (2) le dernier tool. Anthropic cache automatiquement la portion jusqu'au marqueur. TTL 5 minutes.
Effet : après le 1er tour, les tokens cachés sont facturés à 10 % du prix d'input (cache_read), au lieu du prix plein. Sur un agentic loop, ça divise le coût par ~6.
Le system prompt est structuré en 2 blocs : (1) statique cachable (philosophie + faits non-négociables + tools + référence pyramide), (2) dynamique non-caché (détection niveau pour ce message + engagement + focus panel courant + parcours navigation). Le bloc dynamique ne fait que ~300 tokens.
Logging détaillé en DB : on stocke `tokens_input`, `tokens_cache_creation` (writes), `tokens_cache_read` (hits) séparément pour calculer le coût exact, pas une borne haute.
À chaque question reçue, un classifier substring-based détecte le niveau implicite parmi 5 :
La détection passe par des hints de mots-clés normalisés (NFD + lowercase) déclarés dans `pyramid.json`. C'est volontairement simple — pas de classifier embeddings — parce que ça marche en pratique et c'est zéro latence.
Mécanique clé : la recommandation niveau est injectée dans le system prompt à chaque tour. L'agent peut surcharger si le contexte conversationnel le justifie, mais par défaut il suit. Et le modèle LLM est aussi routé sur ce niveau : Haiku pour N0-N2, Opus pour N3-N4.
L'orchestration de modèles est un choix architectural lourd de conséquences. Trois approches possibles :
1. Tout Sonnet (modèle médian, $3/$15 par M tokens) → équilibré mais cher en agentic loop
2. Tout Haiku (rapide, $0.80/$4 par M tokens) → moins subtil sur les nuances
3. Hybride (ce qu'Alexandre a choisi) → Haiku par défaut, Opus quand la profondeur compte
L'implémentation : la fonction `pickModel(levelId)` consulte le niveau pyramide détecté pour le message. Si N3 ou N4 → `claude-opus-4-7`. Sinon → `claude-haiku-4-5`. Le modèle est verrouillé pour tout l'agentic loop du tour pour rester cohérent (un seul modèle, pas de mélange).
Effet observé : 80% des tours sur Haiku (~5¢/question), 20% sur Opus (~25-40¢/question). Coût moyen pondéré ~12¢/question, vs 20¢ en tout-Sonnet. Et la qualité monte d'un cran sur les questions techniques où ça compte.
`max_tokens` est aussi adapté : 1000 par défaut (Haiku), 2000 sur Opus pour laisser plus de matière aux réponses N3/N4.
L'agent dispose de 6 outils JSON-schema, qu'il peut appeler en parallèle ou en séquence dans la même réponse :
1. `show_panel(type, id)` — affiche un panel à gauche pendant que la réponse texte streame. Le panel ID est validé contre la liste exhaustive (zod enum).
2. `list_panels_by_context(topic?, level?)` — filtre les panneaux disponibles par topic et niveau pyramide. Utile pour trouver le bon panel quand l'agent hésite.
3. `search_documents(query, project?)` — RAG sur les ~100 chunks du corpus. Match cosine avec threshold 0.5, top 5 résultats. Embeddings 1536D OpenAI.
4. `qualify_visitor(profile, confidence, signals)` — tag le visiteur (prospect_mission / recruteur / pair_builder / curieux / journaliste). Stocké pour analytics.
5. `recommend_action(intent, cta_label, cta_target)` — émet un CTA visible (RDV, mail, page, externe, exit). Rendu comme un bouton sous la bulle bot.
6. `suggest_followups(items[])` — propose 2-4 chips de relance contextuelles. Remplace une map statique pour des suggestions vraiment ancrées dans le tour courant.
La boucle agentique côté serveur :
Streaming progressif : la réponse texte arrive token par token via SSE, le panneau s'affiche au moment où l'agent décide de l'afficher (pas à la fin), les chips s'actualisent quand l'agent émet `suggest_followups`. Pas de gros bloc figé.
Décision philosophique fondamentale : l'agent est l'agent du visiteur, pas celui d'Alexandre. Son allégeance est à la personne qui visite, pas à Alexandre.
Concrètement, l'agent peut disqualifier honnêtement : "non, je ne pense pas qu'Alexandre soit le bon match pour ton besoin, regarde plutôt Malt sur des juniors freelance". C'est ça qui lui donne sa crédibilité — contrairement à un chatbot commercial qui pousserait toujours le contact.
Quatre profils visiteur scriptés avec leurs questions de qualification :
L'agent parle d'Alexandre à la 3ème personne ("Alexandre a fait", "sa doctrine", "il", "lui"), pas en 1ère personne — il est un assistant tiers, pas Alexandre lui-même. Les citations directes en guillemets restent au JE pour préserver la voix d'Alexandre.
10 ans EDF Cruas-Meysse en électrotechnique nucléaire :
Cette rigueur industrielle irrigue toute ma stack logicielle : RLS multi-rôle, OAuth complet, conformité réglementaire (Factur-X, Chorus Pro), gestion des cas critiques — autant de patterns qui viennent de l'habitude de bosser sur des systèmes où l'erreur n'est pas une option.
Mon rôle technique sur Arcadium a évolué pivot après pivot — un parcours qui démontre la polyvalence en environnement réel, pas en théorie.
V1 — équipe interne, je dessinais
CTO + dev internalisés. Mon job : vision produit et mockups. Je posais le quoi, ils posaient le comment.
Après les pivots — j'ai dû descendre dans le code
Externalisation de l'équipe dev (France + Inde, parce que je ne trouvais pas mon besoin en France). Je me suis mis à prototyper moi-même ce que je voulais voir, pour valider avant de le confier.
Phase finale — full PM/PO + co-architecte technique
Experts UX/UI sur le design. Côté tech, je fournissais au lead dev tout ce qu'un PM/PO doit fournir : besoins, specs, flux, edge cases. Avec lui : recherche des solutions techniques, architecture BDD, lecture de la doc, choix de stack. Les nouvelles features, je les prototypais directement en prod, on les testait sur des vrais utilisateurs, puis on les refondait proprement.
Hands-on sur les zones critiques :
Stack co-architecturée : MongoDB · React · Node.js · PHP · Stripe Connect multi-flux (B2C mensuel + B2B annuel sur la même base) · apps web + mobile.
Ce que ça apporte aujourd'hui : je sais piloter des équipes internes et externalisées, je sais construire de bout en bout parce que je suis passé par à peu près tous les postes (PM, PO, prototypeur, co-architecte, dev ponctuel sur les zones critiques). Et avec l'IA, le mode d'opération a changé : faire bien plus avec moins de monde, et faire sauter une grosse couche de complexité organisationnelle.
En 2022, j'ai construit un système de matching joueurs ↔ clubs en Python avec FAISS — la bibliothèque de recherche vectorielle de Meta — pour Arcadium. Personne autour de moi ne savait que ça existait. Aujourd'hui, les embeddings et la recherche vectorielle sont partout.
Pipeline réel en production :
Faire de la recherche vectorielle avec FAISS en 2022 sur un vrai problème métier — avant que tout le monde ne se mette aux embeddings — ce n'est pas un coup de chance, c'est une habitude technique. La même logique vectorielle structure aujourd'hui FluidStore, ma base vectorielle multi-résolution MCP-native.
Mon pattern : « Je vais chercher la solution là où elle est, pas là où c'est à la mode. »
Liquidation judiciaire propre en 2025.
Ce n'est pas l'histoire d'un produit qui ne marchait pas, ni d'un marché inexistant. Six ans, 25 000 utilisateurs inscrits, 4 000+ abonnés payants, SNCF Gaming et dstny en clients B2B. Le produit marchait, la trajectoire était saine.
Le vrai sujet est plus subtil — et c'est la leçon que j'emporte partout : j'ai fait le choix de lever pour accélérer. Sauf que le marché de l'esport amateur n'avait pas l'élasticité pour absorber l'injection de cash. Plus on mettait dans l'acquisition, plus le CAC montait, sans que la LTV suive le rythme imposé par le cap table.
Quand on lève, on accepte l'obligation de croissance qui va avec. Si le marché ne suit pas, c'est mécaniquement intenable. Pas un défaut d'exécution, un défaut de qualification de l'élasticité du marché avant la levée.
Je l'assume directement : « Avant d'envisager une levée, il faut qualifier que le marché est scalable au rythme imposé par les investisseurs. Et si la trajectoire dit non, savoir sortir proprement avant que ça devienne subi. »
C'est ce qui fonde mon approche actuelle chez Quatools : faire moins, faire bien, durer. Et ne lever que si la mécanique de marché le permet vraiment.
La liquidation n'a pas tué la marque. Ce qui survit en 2026 :
La marque est devenue plus grande que la boîte qui la portait. Le cycle se boucle.
Ce que j'apporte à un client : l'art de construire des relations et un modèle qui dépassent la structure juridique. Une marque peut survivre à sa boîte si elle a été construite proprement.
Une levée n'est pas uniquement une histoire à raconter — c'est une histoire bâtie sur des fondations business solides. Ingénierie financière, traction marché, adéquation business/stratégie : tout ça se prépare dès les premiers mois, pas la veille du roadshow.
Pour Arcadium :
Leçon à transmettre : lever = pari « tout ou rien ». Il faut en avoir conscience et mesurer les indicateurs prédictifs qui disent si la levée est pertinente — ou si c'est une erreur stratégique à éviter.
Ce que j'apporte à un client en phase de levée : les fondations business sur lesquelles l'histoire tiendra, plus la lucidité sur le pari "tout ou rien" — ça se mesure avant, pas après.
Arcadium Esport (2019-2025) était une plateforme SaaS B2B/B2C qui structurait la pratique de l'esport amateur — comme le sport traditionnel l'a fait il y a un siècle.
Chiffres du parcours :
La marque survit aujourd'hui via BAAS sur Rocalys et via l'Arcadium Cup (finale Mars 2026 avec MUC Omnisports).
C'est ma vitrine du cycle complet : de la vision au démarrage, de la croissance à la sortie, sans détour. Pas une expérience d'incubateur — six ans de production avec des vrais clients qui payaient.
Avant de coder une ligne, j'ai validé que le manque était réel — et que les gens étaient prêts à payer pour le combler.
Insight initial : 500 millions de joueurs amateurs dans le monde, 99,9 % des joueurs esport sont amateurs, aucune structure pour les encadrer. Mais l'insight ne suffit pas : il faut prouver que ce manque vaut de l'argent réel.
Le terrain :
Première leçon payée : la discipline du JTBD. Refuser les features que les utilisateurs disaient vouloir mais ne payaient pas. Plusieurs mois perdus à coder ce qui ne ramenait rien avant d'apprendre à dire non.
4 000 personnes ont fini par valider en payant sur 6 ans, 442 actifs au pic.
Ce que ça apporte à un client aujourd'hui : la discipline de valider avec de l'argent réel avant de construire — pas avec des signups, pas avec des sondages. Le client ne dépense pas son budget sur le mauvais produit.
Construire BAAS, c'est marier trois exigences contradictoires :
1. Permissivité maximale — chaque club a ses propres pratiques (formats d'abonnement, structures d'équipes, types de produits, parcours d'inscription). L'outil doit s'adapter, pas l'inverse.
2. Marque blanche totale — les widgets BAAS s'intègrent directement sur le site du club, à ses couleurs, à son identité. Du point de vue du joueur ou supporter, c'est le club qui a son propre système.
3. UX simple — les présidents et administrateurs de clubs ne sont pas des admins SaaS expérimentés. La configuration doit rester intuitive malgré la profondeur fonctionnelle.
> « Les supporters et joueurs pensent que chaque club a développé sa propre solution. En réalité, ils utilisent tous le même socle BAAS, branché via widget sur leur site. »
Modèle indie product studio assumé : « BAAS m'appartient. Pierre exploite. On partage. » Pierre Pastor (ex-COO Arcadium) gère l'opérationnel commercial sur le marché sport et esport.
Modèle Rocalys actuel : revenus récurrents (licence d'exploitation, semi-passif, à sécuriser via contrat formalisé).
Modèles tarifaires proposés aux nouveaux clients :
BAAS est aussi repositionné en « client R&D » qui finance le socle commun Quatools (vertical-agnostique, réutilisable sur toutes les autres briques de l'ERP).
BAAS est une plateforme multi-tenant en marque blanche pour clubs sportifs et esport. Stack : Next.js 16 · Supabase (Postgres + RLS multi-tenant + Edge Functions) · Stripe Connect · TypeScript · MCP server custom (33 outils).
C'est la première brique d'un projet plus large : un ERP multi-SaaS marque blanche qui pilote tout le business d'une structure depuis une plateforme à ses couleurs, sans louer 8 SaaS différents.
Pierre Pastor (ex-COO Arcadium) exploite BAAS sur Rocalys aujourd'hui — partenariat continu depuis 6 ans. C'est le premier client de production de l'ERP Quatools.
L'origine : pendant 6 ans, les clubs esport partenaires d'Arcadium dépendaient de la plateforme centrale pour leur service club. Quand Arcadium s'est arrêté, ces clubs avaient besoin d'une plateforme qui leur permette de continuer sous leur propre marque, sans dépendre d'un acteur central. BAAS est né de là.
L'extension naturelle : aujourd'hui BAAS s'étend des clubs esport aux structures sportives plus larges — clubs de sport traditionnels, associations — qui partagent exactement la même douleur :
BAAS répond aux trois douleurs en une fois : un seul outil, intégré au site du club via widgets, 2 % de commission, totalement à la marque du club.
BAAS n'est pas une fin en soi. C'est la première pierre de Quatools, dont l'ambition est de devenir un ERP multi-SaaS totalement marque blanche.
À terme, depuis une plateforme unique aux couleurs du client, une structure pourra :
> Conduire tout son business depuis un seul ERP intégré, sans renoncer à son identité de marque, sans louer 8 SaaS différents, sans migration douloureuse à chaque ajout de besoin.
Chaque brique du portefeuille Quatools — Calendr, Hub Notification, Factur-IA, Planificateur, FluidStore — n'est pas un projet isolé : c'est une pièce de cet ERP en construction. C'est ce qui justifie de coder chaque brique moi-même, plutôt que de louer une stack tierce qu'on ne peut pas marquer-blancher.
Pattern infrastructure pro : un seul projet Supabase héberge `public` (BAAS) ET `calendrier` (Calendr) avec isolation totale par schéma. Le code utilise systématiquement `.schema("calendrier")` pour ne jamais polluer l'autre app. Économie d'infra + cohérence multi-app Quatools.
Tables principales du schéma `calendrier` : `organizations`, `users`, `organization_members` (avec rôles), `event_types`, `bookings`, `contacts` (CRM), `resources`, `availability_schedules`, `calendars`, `custom_questions`, `plannings`, `duty_rosters`.
Pages livrées (App Router) :
Stack secondaire : date-fns + date-fns-tz (gestion timezones, point critique pour un calendrier en prod), React Hook Form + Zod, Radix UI + shadcn, MCP server custom pour pilotage agent.
Le piège évident d'un produit « comme Calendly mais en mieux » : empiler les features et perdre la simplicité d'usage. La discipline ici a été de garder une seule UI cohérente capable de naviguer entre vue perso, vue équipe et vue ressources, avec un toggle simple, en s'appuyant sur la profondeur de FullCalendar plutôt que d'inventer un calendrier maison.
Trois axes structurants :
1. Stratégies de remplissage par event-type — chaque type d'événement choisit son mode : `fixed` (membre dédié) ou `flexible` (pool de membres avec priorités et limites). Quand un client réserve, l'algorithme dispatch automatiquement vers le bon membre selon les disponibilités et la stratégie.
2. Roulements (duty rosters) — patterns alternance semaine, jour, demi-journée, manuel ou self-service. Génération automatique des créneaux sur 4 semaines, modification visuelle, échanges entre membres.
3. Calcul de disponibilités multi-contraintes — un créneau doit satisfaire (1) horaires de base du membre, (2) assignations fixes existantes, (3) limites par event, (4) réservations existantes, (5) horaires d'ouverture de la ressource liée. Logique centrale partagée entre l'API et l'UI.
Calendr est une plateforme de réservation et de planning professionnel en marque blanche, multi-organisation. Bien plus qu'un Calendly : équipe, ressources, roulements, CRM contacts intégrés, en natif.
Statut actuel : en construction. L'infrastructure (schéma Supabase, multi-organisation, OAuth, FullCalendar) est prête en production sur l'infra Quatools, mais le produit complet n'est pas encore livré ni exploité commercialement. Module en finition.
Stack : Next.js 15 (App Router, Server Actions) · React 18 · TypeScript 5 · Supabase (schéma `calendrier` isolé) · FullCalendar 6 (6 plugins resources) · TanStack Query · Zustand · Anthropic SDK + assistant IA · MCP server custom.
Calendly et Cal.com couvrent la prise de rendez-vous simple (1-1). Aucun n'adresse le planning professionnel complet dont ont besoin les structures sportives, médicales, formation ou conseil :
Aujourd'hui les clubs et structures jonglent avec Calendly + Excel + Slack + tableur partagé + agenda perso = chaos. Calendr regroupe le tout dans une plateforme marque blanche, intégrable au site du client, brique de l'ERP Quatools.
Au passage, c'est la brique de réservation que j'utilise pour mes propres briques — Storm pour la prise de RDV athlète/coach, BAAS pour les créneaux club, Factur-IA pour les devis avec rendez-vous : je ne loue pas mes briques cœur, je les construis et je les connecte.
Pas d'API tierce ni de bibliothèque magique pour le format légal :
Onboarding AI-first — l'utilisateur n'écrit rien :
La plupart des SaaS qui se disent "AI-powered" collent un widget chat dans une sidebar. C'est cosmétique.
Factur-IA fait l'inverse : peu importe où tu te trouves dans l'app — page facture, fiche client, dashboard, paramètres — tu peux demander à l'IA d'agir. Elle voit le contexte de l'écran, accède aux données métier (clients, entreprise, factures existantes), et exécute :
Confirmation avant action, historique conservé, contexte persistant.
Conséquence architecturale : pour que l'IA puisse agir partout, il faut que toutes les fonctions de l'app soient exposées de manière programmable. C'est le rôle du serveur MCP. La différence entre « ajouter un chatbot » et « concevoir AI-native » tient là : l'app n'est pas une UI avec une feature IA — c'est une API dont l'UI et le chat sont deux clients équivalents.
Pour qu'un assistant IA externe (Claude Desktop, Claude Code, agent tiers) puisse piloter Factur-IA en sécurité multi-utilisateur, j'ai implémenté un serveur OAuth complet selon la spec MCP :
Outils MCP exposés (extrait) :
> Très peu de SaaS implémentent un serveur OAuth complet pour MCP. C'est un signal fort pour les devs avertis : Factur-IA est un vrai citoyen de l'écosystème agent, pas un MCP côté client juste pour démo.
Factur-IA est une plateforme de facturation AI-first : facturation pilotée par chat IA présent partout dans l'app, conforme Factur-X / Chorus Pro, open source.
Stack 2026 : Next.js 16 · React 19 · Tailwind 4 · Supabase · Claude API + Vision · MCP SDK officiel + serveur OAuth complet.
À partir de septembre 2026, la facturation électronique devient obligatoire pour toutes les entreprises françaises (formats Factur-X / UBL / CII, transmission via PDP / portail public). Vague énorme côté ETI/PME qui doivent migrer.
Le marché actuel propose une réponse paresseuse : Pennylane, Sellsy, Tiime, Indy — tous payants, lourds, copies à peine modernisées de l'ancienne UX comptable. Personne ne profite de la migration obligatoire pour repenser le métier avec l'IA.
Factur-IA répond à l'inverse :
Stack 2026 — early adoption assumée :
Modèle économique :
Architecture en 3 couches :
Embeddings Matryoshka multi-résolution — utilisation des embeddings Matryoshka d'OpenAI (`text-embedding-3-small`) tronqués à 3 résolutions :
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
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.
URL : `https://fluid-store-mcp.quaglieri-alexandre.workers.dev/mcp`
Outils exposés à Claude (et tout client MCP) :
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).
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 2022 → base vectorielle multi-résolution FluidStore en 2026. Pas un projet où je découvre les embeddings — c'est l'aboutissement de 4 ans de pratique.
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 :
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.
17 outils MCP exposés :
Roadmap : OKR pour la hiérarchie complète — module en conception : ajouter une couche Vision → Objectif → Key Result → Projet → Tâche lisible en une query par l'agent. Trois bénéfices visés :
Quand on décide que l'API canonique est MCP, plusieurs choix se cascadent :
Le Planificateur Quatools, c'est de la gestion projets / tâches / tracking de temps conçue pour être pilotée autant par humain que par IA. Stack : TypeScript · Supabase · MCP server custom avec 17 outils MCP exposés.
Tous les outils de productivité existants sont conçus pour être pilotés à la souris :
Aucun n'est pensé pour qu'un agent autonome ouvre la session, lise l'état, démarre un timer, fasse le travail, le tracke et clôture — comme un humain le ferait, mais sans humain.
Le Planificateur répond à ce manque : l'API canonique de l'app est MCP, pas REST. L'UI web et l'agent IA sont deux clients équivalents de la même surface. Conséquence : Claude (Desktop, Code, ou tout client MCP) pilote n'importe quel projet ou tâche en langage naturel, sans "intégration IA" à part.
Trois univers difficiles à marier sans choisir un camp :
Le design tranche le piège évident — soit tomber dans l'esthétique gamer agressive (RGB criard, dark néon, mascots), soit dans le corporate aseptisé.
Au lieu de ça : visuels gaming maîtrisés (vrais joueurs en photo, pas de stock), typographie Montserrat propre, animations AOS sobres au scroll, Hero avec image immersive mais lisible, ton de voix accueillant (« Rejoignez », « Notre communauté »). On est dans un club, pas dans un magasin.
Site club esport pour Rocalys (Pierre Pastor, ex-COO Arcadium). Mission : réconcilier univers gaming, encadrement pro et chaleur humaine.
Stack volontairement minimaliste : HTML/CSS/JS vanilla + mini moteur de templating maison · Migration Astro à venir · Préparé pour intégration BAAS marque blanche.
9 pages livrées, site en production, prestation refonte facturée janvier 2026. Continuité de partenariat 6 ans avec Pierre Pastor depuis Arcadium.
Le site Rocalys vivait dans Webflow : élégant, mais cher (abonnement mensuel), lent à éditer, fermé techniquement, impossible à connecter à un vrai backend pour gérer plus tard les abonnés, paiements et communauté du club via BAAS.
Le club avait besoin d'un site qui lui ressemble :
Rocalys est un club de quartier à Montpellier, pas une équipe pro distante. Le site devait porter cette identité.
Modèle business du projet :
Décision technique assumée : HTML/CSS/JS pur (vanilla), pas de framework, pas de build, pas de Node.js. Pourquoi ?
Pour éviter la duplication HTML qu'imposerait un site multi-pages pur, j'ai écrit un mini moteur de composants maison (`js/components-loader.js`) :
Le projet Storm illustre concrètement le volet ingénierie financière de l'acte 1 de ma méthode : transformer une idée en projet financé avant qu'elle n'épuise le porteur.
Modèle économique cible Storm : Doctolib-like — gratuit pour athlètes et coachs, abonnement préparateur + commission par séance, Stripe Connect pour éviter la double TVA.
C'est exactement le type de mission que je propose : transformer une idée en projet financé avant qu'elle n'épuise le porteur. Je suis Product Manager certifié BPI France pour mener ce type de mission.
Sujet santé mentale = rigueur clinique, sérieux, scientifique.
Sujet sportif = énergie, dynamique, motivation.
Trouver une identité visuelle qui ne tombe ni dans le fitness criard, ni dans le médical froid.
Direction artistique Storm : fond très sombre · serif élégant en titres · accents dorés ambrés et bordeaux · illustrations aquarelle qui humanisent sans niaiserie · gamification subtile (streaks, niveaux, séances) jamais Duolingo · coach IA « LAU » intégré comme un coach normal, pas comme un gadget marketing.
Aucun concurrent (Calm, Headspace, Whoop, Oura) n'occupe ce territoire visuel — Storm a une signature qui lui appartient.
L'admin Storm est complexe : catalogue de dimensions, mapping multi-questions, paramètres d'algorithme, règles de déclenchement, évaluations coachs, livrets athlètes. Naviguer à la souris devient vite épuisant.
Solution implémentée : un serveur MCP admin qui expose toute la surface d'admin à un client MCP (Claude Desktop, Claude Code, agent custom). Conséquence : Claude pilote l'admin de bout en bout.
Trois usages réels :
> C'est ce que devient une app quand on conçoit AI-native plutôt que d'ajouter un chatbot par-dessus : l'admin n'est plus une UI — c'est une API dont l'UI n'est qu'un client parmi d'autres.
Le problème : en psychologie sportive, plusieurs méthodes de mesure cohabitent (Score Mental Ephi, MBTI, méthodes futures). L'approche naïve consisterait à poser un questionnaire dédié pour chaque méthode → 200+ questions à faire passer à l'athlète. Inutilisable, démotivant, contraire à l'esprit de l'app.
La solution implémentée — un moteur où une question alimente N moteurs de calcul :
Pattern architectural clé : permissivité maximale (text libre, jsonb mapping, jsonb settings) + canonisation par catalogues séparés. C'est l'inverse de la tendance SQL habituelle qui contraint tout. Conséquence : Laurent ajoute une dimension, change un mapping, ajuste un poids — sans toucher au code, sans déploiement, sans casser l'existant.
Storm (alias Ephi-Sport) est une mission de développement client que je mène pour Laurent Martini (FISPORT) — 15+ ans en formation aux aspects psychosociaux (PNL, Fédération Française de Foot, Kings League). Storm est et restera la plateforme de Laurent / FISPORT, pas un produit Quatools.
Le produit : une plateforme de préparation mentale sportive type Doctolib mental.
Stack : Next.js (web admin) · Expo (mobile native iOS/Android) · Supabase (Postgres + RLS multi-rôle + Edge Functions) · Daily.co (visio embed) · Stripe Connect · Claude API + MCP server admin pilotable de bout en bout.
Mission Diag Axes d'Innovation BPI France via Inizia — 210 h sur 5-6 mois, financement BPI partiel. Statut actuel : architecture 90 % prête, en cours de polissage avant ouverture aux premiers utilisateurs.
Le marché de la prépa mentale sportive en France est en friche :
> « Le prépa physique c'est saturé. Le prépa technique c'est saturé. L'analyste vidéo il y en a 48 000. Mais sur les aspects mentaux ça n'existe pas. » — Laurent Martini
Storm répond à trois besoins en une plateforme :
1. Mettre en relation athlètes et préparateurs mentaux (modèle Doctolib)
2. Donner aux préparateurs une méthode structurée (24 séances sur 3 niveaux, fiches programme, livrets athlète)
3. Mesurer la progression mentale en continu, scientifiquement, sans noyer l'athlète sous les questionnaires
L'erreur stratégique sur Arcadium n'a pas été de mal construire le produit, ni de mal vendre. Elle a été de lever pour accélérer un marché qui n'avait pas l'élasticité pour absorber l'injection de cash.
Concrètement, ce que ça donnait :
Tous les marchés ne permettent pas un scale rapide — et accélérer la machine quand le terrain ne le permet pas pousse uniquement à la surchauffe sans gain réel.
Les vrais signaux à lire AVANT la levée, pas après :
Pourquoi c'est critique : une fois la levée bouclée, on dépense sur du crédit. Si la croissance ne suit pas à l'allure promise au cap table, le projet s'arrête net. Lever, c'est échanger la marge de manœuvre contre une obligation de vitesse. Une levée peut tuer un projet qui aurait pu continuer à scaler tranquillement en autofinancement.
Ce que j'apporte à un client aujourd'hui : la lucidité sur le piège du scale forcé. Lire les signaux avant la levée — qualifier si votre marché supporte vraiment l'accélération, ou si vous risquez de transformer un projet sain en projet sous pression. Et quand la trajectoire dit non, sortir proprement avant que la sortie devienne subie.
Sur ce qu'il faut savoir construire :
> « Il faut savoir QUOI construire, COMMENT construire, et — surtout — SUR QUEL MARCHÉ construire. Aucune école n'aurait pu m'apprendre ça. Ce sont les 6 meilleures années d'école que je n'ai jamais eues. Et c'est ce qui me permet aujourd'hui de construire une chaîne de valeur de bout en bout. »
Sur le rythme imposé par une levée :
> « Avant d'envisager une levée, qualifier que le marché est scalable au rythme imposé par les investisseurs. Le produit peut marcher, la trajectoire peut être saine — si le marché n'a pas l'élasticité pour absorber l'injection de cash, le rythme du cap table devient mécaniquement intenable. Une levée n'est pas un boost universel. C'est un pari sur l'élasticité du marché. »
Sur la sortie :
> « Quand la trajectoire dit non, savoir sortir proprement avant que ça devienne subi. La SAS a fait son job — c'est aussi ça, l'ingénierie financière bien faite. »
Ces trois leçons sont au cœur de ma doctrine "Builder lucide" actuelle :
À l'école, je n'ai jamais été terrible. Brevet à 10,5. BEP aussi. À la maison, on n'avait pas grand-chose et on a pas mal bougé — ma famille a vécu un bon moment en caravane, sur des terrains qu'on nous prêtait. « Je me disais que j'étais pas malin, que j'étais pas fait pour les études, que j'étais bon à rien. »
Heureusement, il y avait le rugby. Le club du coin, l'équipe, le coach, le vestiaire. Une régularité qui ne dépendait pas de la maison. « J'ai compris bien plus tard que c'est ce qui m'avait tenu debout. »
Pour gagner trois sous, j'ai fait des choses pas très catholiques. Pas si rares dans les zones d'éducation prioritaire. « Il fallait bien que je m'adapte au client — c'est probablement la première fois que j'ai fait du commerce. »
Souvent en colère, des effondrements réguliers, sans savoir pourquoi. Le monde me paraissait de travers. J'ai mis longtemps à comprendre que des fois, ce n'est pas le monde qu'il faut redresser — c'est notre façon de le regarder.
À 20 ans, un ami m'a dit que je pouvais faire autre chose. Il n'avait aucun agenda, il croyait juste en moi. Première personne à le faire sans intérêt. J'ai arrêté ce que je faisais pour gagner plus. Et un jour, j'ai postulé en apprentissage à RTE.
Ce qui est venu après, je ne l'aurais jamais imaginé.
> Parfois, quand ça ne va vraiment pas, on change de voie. Ce n'est ni rationnel ni émotionnel. C'est qu'à un moment, on n'a plus le choix. Et un jour, on découvre tout un univers qu'on ne soupçonnait pas.
Avoir des amis, ça peut parfois changer une vie. À 20 ans, j'en avais un qui m'a dit que je pouvais peut-être faire mieux que ce que je faisais. « J'avais aucune raison de le croire. J'ai essayé quand même. »
J'ai postulé en apprentissage à RTE — le réseau électrique haute tension de la France, les lignes 400 kV qu'on voit avec leurs grands pylônes. Ils m'ont pris in extremis en juillet, l'année où je devais entrer sinon c'était mort. Pendant deux ans, j'ai bossé sur les postes 63 à 400 kV de Nîmes.
J'ai enchaîné sur un BTS électrotechnique. Major de promo. Sixième de l'académie. 20/20 au projet de fin d'études. Les profs ont cru à un plagiat — niveau ingénieur sur le papier, jeune apprenti sur le banc. Je leur ai expliqué à l'oral. Ils ont compris.
Une fille s'est effondrée en pleurant ce jour-là parce que j'avais 20/20 « sans forcer » alors qu'elle en avait chié. Elle ne savait pas que je bossais comme un fou — projets électronique, code en C, clients à côté. Mais j'avais trouvé une façon de bosser qui me ressemblait : par passion plutôt que par devoir.
> Trois ans plus tôt, je n'avais aucun plan. Trois ans après, j'avais un BTS major et un CDI dans le nucléaire qui m'attendait.
EDF m'a recruté pour le nucléaire. J'y suis allé les mains dans les poches parce que je pensais que c'était pas pour moi. Je suis rentré en voiture en pensant que j'avais raté l'entretien. Le RH m'a appelé le weekend : « on te prend, ton entretien était parfait. » Je n'y croyais pas vraiment.
CNPE Cruas-Meysse. Technicien en électrotechnique. Tableaux 380 V, 6,6 kV, 24 kV, 400 kV. Alternateurs 900 MW. Onduleurs, redresseurs, groupes électrogènes. Plusieurs années de service sans-faute. Mon chef m'a dit un jour : « on se demandait ce que tu faisais là parmi nous. » Je n'ai pas su quoi répondre.
J'ai conçu un outil de diagnostic pour la vérification des matériels de protection des tableaux 380 V. Plus petit, plus léger, moins cher, semi-automatique au lieu de manuel. Prix local de l'innovation et nomination au prix national EDF.
J'ai aussi commencé à animer des formations — lecture de schéma, régimes de neutres, maintenance des systèmes d'excitation alternateur. Sessions adoptées au niveau national. « À chaque fois je me disais que j'allais me faire griller. À chaque fois ça se passait bien. »
À ce moment-là, j'ai commencé à me dire que peut-être je n'étais pas si bête.
> Plusieurs années sans-faute. Un outil primé. Et toujours cette idée que c'était un malentendu.
À 27 ans, j'ai démissionné d'EDF. J'avais un CDI dans le nucléaire, un salaire qui rassurait, une boîte qui ne licencie pas. J'avais aussi l'impression de tourner à 20 % de ce que je pouvais donner. Un ami pensait que je pouvais faire mieux. Moi aussi.
J'ai fondé Arcadium Esport SAS. L'idée : faire pour l'esport amateur ce que le sport traditionnel a fait il y a un siècle — un cadre, des clubs, des coachs, une identité collective. « Esport is sport », c'était la baseline.
Pourquoi cette idée-là ? Parce qu'enfant, le rugby m'avait offert ce que la maison ne pouvait pas — une équipe, un cadre, des coachs, une appartenance. Avec Arcadium, je voulais offrir la même chose à la génération qui ne joue plus au rugby mais à League of Legends. Recréer pour d'autres ce qui m'avait tenu debout.
Ça a marché. Sur six ans : 4 000+ abonnés payants cumulés, ~1 M€ levés au total (Business Angels + subventions publiques + dernière levée 650 k€ equity + levier), des grands comptes (SNCF Gaming, dstny), 27 coachs animés, deux modèles d'usage (Mode Team comme un club / Mode Solo comme un Basic Fit). On était au point d'autofinancement.
À côté d'EDF d'abord, puis à temps plein, j'ai aussi construit deux maisons. Alissas — 130 m² en autoconstruction, escalier suspendu en porte-à-faux, éclairage entièrement domotique. La nuit, après le code, je faisais les plans. Les weekends, je posais les marches. Mon chef-d'œuvre. Et Meynes — la réhabilitation d'un hangar en deux logements pour mes parents.
J'ai bossé 80 heures par semaine pendant six ans. « Je pensais que c'était comme ça qu'il fallait faire. C'était pas faux pour avancer. C'était faux pour durer. »
> Le produit marchait, la trajectoire était saine. Le vrai sujet : j'avais fait le choix de lever pour accélérer un marché qui n'avait pas l'élasticité pour absorber l'injection de cash. Plus on mettait dans l'acquisition, plus le CAC montait, sans que la LTV suive le rythme imposé par le cap table. C'est la leçon que j'emporte partout aujourd'hui.
À 32 ans, j'ai compris que je fonctionnais d'une façon un peu particulière. Ça m'a expliqué pourquoi je faisais 80 heures pendant qu'autour de moi d'autres en faisaient 40 et avançaient autant. « C'était pas une bonne nouvelle, mais c'était une bonne explication. »
Arcadium est entré en liquidation peu après. Je l'ai gérée moi-même, proprement. La SAS a fait son boulot — sortie maîtrisée, pas de dette personnelle. De six ans d'entrepreneuriat, j'ai surtout retenu une chose : savoir QUOI construire est plus dur que savoir COMMENT construire.
J'ai vendu la maison d'Alissas, mon chef-d'œuvre. « J'en ai pleuré, mais c'était la bonne décision. » J'ai réalloué une partie en achetant un studio aux enchères judiciaires au Grau-du-Roi, mis en location. La maison de Meynes — celle de mes parents — est restée. Ce qui devait être protégé l'a été.
Six mois plus tard, j'ai relancé en entreprise individuelle. Quatools. Pas une nouvelle SAS, pas de levée, pas de boîte à trois fondateurs. Un solo product builder qui fait seulement ce qui vaut la peine d'être fait.
J'ai construit un portefeuille d'outils — BAAS pour les clubs, Calendr pour les rendez-vous, Storm pour la prépa mentale, Factur-IA pour la facturation, FluidStore pour la mémoire IA, Planificateur pour le tracking. Tous pilotables par agent. Tous connectables entre eux.
Pierre Pastor — l'ancien COO d'Arcadium — exploite aujourd'hui BAAS sur Rocalys. On partage les revenus. Six ans qu'on bosse ensemble.
J'ai aussi repris la formation, sérieusement cette fois. CMA, Oxytalis, MUC. « Quand on a fait 80 heures pendant six ans, on apprend que peut-être 40 bien faites valent mieux. »
> La troisième voie : ni mort lente, ni mort rapide. Faire moins, faire bien, durer.
Un partenaire est humain. Le portfolio raconte ce que je fais. Le parcours dit d'où je viens, et pourquoi je le fais. Travailler ensemble, c'est savoir qui on est.
Les chapitres remontent le temps — du présent vers l'origine — parce que c'est dans cet ordre que je me comprends moi-même.
5 chapitres :
5. Le temps de la régularité (32 ans — aujourd'hui)
4. Le temps du dépassement (27-32 ans — Arcadium)
3. Le temps de la prise de confiance (24-27 ans — EDF nucléaire)
2. Le temps de l'apprentissage (20-24 ans — RTE + BTS)
1. Le temps de la survie (0-20 ans)
Pierre Pastor (ex-COO Arcadium, exploitant BAAS sur Rocalys) :
> « La plateforme est folle. »
Partenariat continu 6 ans entre moi et Pierre Pastor. De Arcadium (où Pierre était COO) à BAAS sur Rocalys aujourd'hui — la même relation de confiance opérationnelle qui s'est transformée en modèle d'exploitation partagé (je développe, Pierre exploite).
Témoignages des autres missions Quatools en cours à collecter : Laurent Martini (FISPORT / Storm), MUC Omnisports, Oxytalis Campus, CMA Occitanie.
Ce qui frappe dans mes relations clients, c'est leur durée. Pierre Pastor depuis 6 ans, MUC Omnisports historique Arcadium qui devient partenaire Quatools (Arcadium Cup Mars 2026), Laurent Martini engagé sur une mission BPI 210 h en plusieurs phases.
Ce n'est pas un hasard : la doctrine « un seul interlocuteur » + « revenue share / partenariat plutôt que devis ponctuel » fait que chaque mission a une suite. Pas un coup, un cycle.
Luc "Hikar" Naudin, Manager & Joueur SNCF Gaming :
> « Le partenariat avec Arcadium est une vraie réussite. Le service de coaching professionnel est très qualitatif et très apprécié des joueurs de notre structure SNCF Gaming. »
"Daltona", joueur SNCF Gaming :
> « Tout le monde dans le club est au même niveau, du directeur à Paris au contrôleur dans le sud. Ça m'a permis d'améliorer grandement mon réseau. »
Au-delà de ces témoignages B2B grands comptes, la communauté esport française a manifesté un soutien fort tout au long du parcours Arcadium et même après la liquidation — ce qui a permis à la marque de survivre à la structure juridique.
Luc "Hikar" Naudin, Manager & Joueur SNCF Gaming :
> « Le partenariat avec Arcadium est une vraie réussite. Le service de coaching professionnel est très qualitatif et très apprécié des joueurs de notre structure SNCF Gaming. »
"Daltona", joueur SNCF Gaming :
> « Tout le monde dans le club est au même niveau, du directeur à Paris au contrôleur dans le sud. Ça m'a permis d'améliorer grandement mon réseau. »
Au-delà des clients B2B grands comptes, la communauté esport française a manifesté un soutien fort tout au long du parcours et même après la liquidation — ce qui a permis à la marque de survivre à la structure juridique.
> « 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.
9 pages live sous une identité visuelle cohérente :
Stack secondaire : HTML5 + CSS3 + JavaScript ES6 vanilla, AOS (Animate On Scroll) via CDN, Google Fonts (Montserrat), Font Awesome, images responsives `
Preuves :