~/progetti/formicaio/README.md
←~/progetti/formicaio/README.md

Formicaio

{ “date”: “2026-10-24”, “statut”: “live”, “modules_stack”: 14 }

Une équipe d'agents spécialisés pour vos objectifs du quotidien — ils retiennent le contexte, citent leurs sources et mesurent les progrès

Formicaio est né d'une question que je me posais chaque matin : « qu'est-ce que je peux manger ce matin ? ». Pour y répondre correctement, il faut le plan d'entraînement, le jour de la semaine, ce qu'il y a dans le placard et l'objectif — et avec un chat d'IA générique, il fallait tout réexpliquer depuis le début, à chaque fois : un quart d'heure pour décider d'un repas, pour finalement recevoir un conseil qui ne savait rien de moi. Formicaio part de l'hypothèse inverse : le contexte est une donnée structurée, pas un texte à réécrire. C'est un assistant personnel fait d'agents spécialisés, regroupés en équipes — athlétisme, études, n'importe quel autre domaine — qui répondent en quelques secondes avec votre contexte, indiquent de quelle source vient chaque conseil et tiennent le compte de ce que vous faites vraiment.

## Équipes, agents et sources

Une équipe est un domaine avec son état partagé : objectifs, métriques, engagements récurrents, types d'observation. À l'intérieur, un ou plusieurs agents, chacun avec ses instructions, ses principes et ses documents. Avant chaque réponse, une lecture structurée de la question choisit l'agent qui doit répondre et reconnaît ce qu'il faut enregistrer ; puis l'agent répond en citant les passages d'où vient son conseil.

·Des documents par agent, découpés en passages et retrouvés avec la recherche plein texte de PostgreSQL : chaque citation renvoie au passage exact
·Des observations lues dans le chat : un entraînement sauté, une pesée ou un repas deviennent des données, validées par le noyau, sans formulaire à remplir
·Des engagements récurrents, comme les entraînements de la semaine, avec les exceptions dites dans le chat
·Chaque réponse est une recommandation pour un jour précis : un tap sous la réponse dit comment ça s'est passé, et c'est de là que se mesure l'adhérence

## Un noyau qui ne sait rien de l'athlétisme

L'exigence la plus stricte était l'agnosticité : un nouveau domaine doit s'ajouter par la seule configuration, sans toucher au code. Le noyau ne connaît ni la piste ni les examens, et un contrôle en CI échoue si un terme du pilote apparaît dans ses modules. La configuration d'une équipe est décrite par un JSON Schema versionné et validée avec Ajv ; chaque enregistrement publie une nouvelle version immuable, et chaque tour enregistre celle qu'il a utilisée. La deuxième équipe, études, est née ainsi : un fichier de configuration, zéro ligne de code. Aujourd'hui, équipes, agents, métriques et types d'observation se créent et se modifient directement depuis l'app, à partir de modèles.

## Le tour, de la question à la réponse

Chaque question est un tour avec une trace complète : la version de la configuration, le contexte envoyé au modèle, les tentatives, les contrôles des règles, les tokens et le coût. Le contexte s'assemble en lisant le noyau dans le même processus, car au sein d'un tour le système doit lire ses propres écritures : c'est la raison principale pour laquelle l'architecture est un monolithe modulaire et non un ensemble de services.

·Monolithe modulaire aux frontières strictes : une interface publique par module, un schéma PostgreSQL et un rôle de base de données par module, dépendances vérifiées en CI avec dependency-cruiser
·Des événements mis en file dans la même transaction que le tour et livrés une seule fois par graphile-worker, en dead-letter après trois tentatives
·Un plafond de dépense quotidien par utilisateur, réservé sous un advisory lock avant d'appeler le modèle
·Le texte des questions et des réponses est effacé après 90 jours : restent les dates, les durées, les coûts et une empreinte

## Votre clé, votre modèle

Formicaio n'a pas de clé à lui. Chaque utilisateur choisit le fournisseur dans les réglages — Anthropic, OpenAI ou DeepSeek — et colle sa propre clé, scellée avec AES-256-GCM dans un schéma à part. Il y a un modèle par fournisseur, derrière un adaptateur commun avec sa propre boucle de nouvelles tentatives dans le budget de latence du tour. Chaque réponse est payée par qui la demande, et avant le choix, l'app dit clairement comment chaque fournisseur traite les données.

## Mesurer, pas deviner

Le projet a un gate hebdomadaire avec deux chiffres : l'adhérence, c'est-à-dire la part des jours d'engagement où le conseil est vraiment suivi (l'objectif est d'au moins 80 %), et le temps entre la question et la réponse affichée (p95 sous les deux minutes, contre le quart d'heure de départ). La qualité des réponses est évaluée sur un jeu de questions figé, sur une copie jetable de la base de données, jamais en production.

## Design et identité visuelle

L'app est une PWA installable, pensée pour le téléphone mais confortable aussi sur ordinateur, avec une esthétique douce et un seul bleu comme couleur principale. La marque est une fourmilière en coupe : le dôme en haut, les chambres à l'intérieur, les galeries découpées jusqu'à l'entrée, de sorte que le fond transparaît sur n'importe quelle surface. Dans le nom, le « AI » de FORMICAIO est dans la couleur d'accent.

·HeroUI v3 avec les tokens de Formicaio, thème clair et sombre
·Plus Jakarta Sans servie par l'app elle-même : aucune requête vers des services de polices externes
·Connexion sans mot de passe, avec l'e-mail et un code à six chiffres, construite sur les API de Clerk avec le markup de l'app
·Réponses en Markdown rendues de façon sûre, avec des citations numérotées ; chaque page publique est vérifiée avec axe-core dans les tests

## Stack technologique

Un monorepo TypeScript géré avec pnpm : le backend, la PWA et un client API généré à partir du contrat OpenAPI du backend, pour que front-end et back-end ne puissent pas diverger en silence.

·Backend : NestJS sur Fastify, Kysely pour l'accès aux données, PostgreSQL 18
·Files et échéances : graphile-worker sur le même PostgreSQL
·Configuration des équipes : JSON Schema validé avec Ajv
·Web : React, Vite, React Router, TanStack Query, HeroUI v3, Tailwind CSS v4, i18next
·Modèles : les SDK d'Anthropic et d'OpenAI, ce dernier servant aussi DeepSeek via son API compatible
·Tests par niveaux avec Vitest, des frontières entre modules jusqu'aux vrais processus avec un fournisseur de modèle simulé

## En production

Il tourne dans des conteneurs Docker sur un serveur dans l'Union européenne. Les images sont construites par la CI, taguées avec le SHA du commit, et chaque commit sur main part en production tout seul : de la CI, le serveur n'accepte qu'une seule chose, le déploiement d'un commit de main, toujours avec une sauvegarde de la base de données avant les migrations. La base de données est sur un volume chiffré avec LUKS2, et les sauvegardes nocturnes quittent le serveur déjà chiffrées avec age, vers Cloudflare R2.

Formicaio est un projet personnel, imaginé, conçu et développé seul, et son premier utilisateur, c'est moi. Les documents du projet — discovery, estimation, modèle de domaine, architecture, plan d'implémentation et plan de test — ont été écrits par donumAI et approuvés par moi étape par étape. Le critère avec lequel je le juge est écrit dans le gate : quatre semaines d'usage quotidien, avec une adhérence d'au moins 80 %. Le reste, ce sont des intentions.

// stack
[“nestjs”, “postgres”, “react”, “llm”, “fastify”, “kysely”, “graphile-worker”, “vite”, “heroui”, “tailwind”, “typescript”, “pwa”, “json-schema”, “docker”, ]