Le backend qui porte toute la plateforme¶

Yisin API doit accueillir un assistant citoyen, un espace professionnel, l'administration, la facturation et l'IA sans devenir un amas de services indissociables.

La décision structurante¶

Le backend reste un monolithe modulaire FastAPI. Un seul service simplifie les transactions, le déploiement et le diagnostic ; des domaines internes nets préparent l'évolution sans imposer maintenant le coût des microservices.

yisin-web ─────┐
yisin-admin ───┼──► yisin-api ──► PostgreSQL
clients futurs ┘         │       ├── Redis
                        │       ├── Qdrant
yisin-ia ── manifeste ──┤       ├── stockage objet
                        │       └── fournisseur LLM
                        └── événements et audit

Le backend est la seule autorité applicative. Les interfaces n'accèdent jamais directement aux stockages, à Qdrant ou au modèle.

Les frontières métier¶

La plateforme est divisée en familles cohérentes :

Famille	Modules principaux
Accès	identité OIDC, comptes, workspaces, rôles et permissions
Produit YISIN	conversations, runs, historique et feedback
Intelligence juridique	corpus, retrieval, preuves, génération et vérification
Commerce	offres, droits, quotas, ledger, abonnements et paiements
WEDOTO	professionnels, dossiers, pièces, productions et exports
Gouvernance	qualité, administration, audit et notifications

Chaque module possède ses règles et ses données. Il communique avec un autre module par un cas d'usage public ou un événement durable, jamais en modifiant directement ses tables.

Ne plus confondre les statuts¶

L'ancien backend stockait dans un seul rôle des notions différentes comme utilisateur gratuit, abonné, avocat et administrateur. La refonte sépare :

l'identité OIDC ;
l'appartenance à un espace personnel ou cabinet ;
les permissions métier ;
le statut de vérification professionnelle ;
les droits issus d'une offre commerciale.

Un paiement peut ainsi accorder un droit sans transformer le rôle de sécurité du compte. Une validation d'avocat n'accorde pas automatiquement un privilège d'administration.

Une réponse est une exécution¶

Le cœur du backend n'est pas un simple endpoint qui attend le texte du LLM. Une question crée un run : droits et quota sont contrôlés, les sources sont retrouvées, un dossier de preuves est construit, un brouillon est généré, puis les affirmations et citations sont vérifiées avant publication.

question → autorisation → recherche → preuves → brouillon
         → vérification → réponse citée / clarification / abstention

Le client reçoit des événements SSE de progression. Le texte final n'est diffusé qu'après la gate juridique. Une coupure peut être reprise avec Last-Event-ID, et une annulation devient une vraie transition persistée.

Quatre mémoires différentes¶

Système	Fonction
PostgreSQL	autorité sur les comptes, conversations, runs, dossiers et paiements
Qdrant	index de recherche reconstructible depuis le corpus
Redis	cache borné, limites, verrous courts et transport des jobs
S3/MinIO	pièces et exports privés avec accès signé et rétention

Une pièce WEDOTO n'est jamais mélangée au corpus. Son texte est traité comme une donnée potentiellement hostile, pas comme une instruction adressée au modèle.

Les choix qui corrigent l'héritage¶

Ancien fonctionnement	Nouvelle règle
ChromaDB et copie manuelle du corpus	Qdrant alimenté par un manifeste vérifié
réponse de mémoire si le RAG échoue	abstention ou indisponibilité explicite
service WEDOTO géant	professionnels, dossiers, documents et productions séparés
fichiers sur le disque du backend	stockage objet privé
mots de passe et JWT gérés dans l'application	OIDC, MFA pour l'administration
réglages critiques modifiables sans version	profils publiés, snapshots et audit
texte et citations acceptés du LLM	citations reconstruites depuis les preuves

Ordre de construction¶

fondation PostgreSQL, Redis, migrations et observabilité ;
identité, workspace et permissions ;
conversations, runs, SSE, idempotence et ledger d'usage ;
retrieval mesurable et dossier de preuves ;
génération contrôlée et première réponse YISIN complète ;
administration et qualité ;
offres, quotas et paiements ;
WEDOTO par tranches ;
migration et retrait de l'ancien backend.

Les cinq premières étapes forment le premier objectif : prouver de bout en bout qu'une réponse peut être sûre, sourcée, persistée et reconstructible. Les fonctions commerciales ou professionnelles ne doivent pas retarder cette preuve.

Architecture cible et état réel

La validation du corpus, l'indexeur Qdrant et les fondations B1/B2/B3 existent : PostgreSQL async, Alembic, outbox, Redis, erreurs stables, corrélation, validation JWT/JWKS, compte local, workspace personnel et permissions par portée, runs persistants, SSE reprenable, idempotence, outbox et ledger. Le fournisseur OIDC réel reste à choisir et raccorder aux interfaces. Le retrieval runtime, le fournisseur LLM, la gate juridique et les modules WEDOTO sont encore à construire.