Persistance des conversations : SQLite et SQLAlchemy dans the_orchestrator
Avant, l’API fonctionnait en mode stateless : chaque appel à /chat repartait de zéro. L’historique disparaissait dès qu’on rechargeait la page ou qu’on redémarrait le serveur.
Il était donc impossible de reprendre une conversation ou de retracer les actions d’un agent.
Le commit ajoute trois tables (conversations, messages et agent_logs) ainsi qu’un CRUD /conversations. Mais le problème n’est pas entièrement résolu : /chat ne stocke toujours rien en base, il reste à brancher les éléments.
L’architecture retenue
Trois tables SQLite ont été créées : conversations, messages et agent_logs. Le schéma est initialisé au démarrage via SQLAlchemy 2.0 avec un create_all().
Un service conversation_service.py expose les opérations CRUD sur ces tables. Les endpoints dédiés sont regroupés sous /api/v1/conversations : liste, création, lecture avec messages, suppression en cascade, ajout de message et enregistrement de logs d’agent.
Voici l’extrait de code du routeur FastAPI pour les conversations :
Ce que ça change en pratique
Les endpoints /conversations permettent désormais de créer, lister, lire et supprimer des conversations, ainsi que d’ajouter des messages et des logs d’agent.
Vingt-cinq tests d’intégration passent, couvrant les endpoints via le TestClient de FastAPI : chat, agents, conversations, messages, logs, ainsi que les cas d’erreur 404 et 422.
Les tradeoffs, assumés
Alembic a été installé pour gérer les migrations puis écarté. Le projet utilise un create_all() au démarrage, plus simple pour un schéma qui bouge encore.
Le compromis est assumé : il faudra reprendre les migrations plus tard si le schéma se stabilise.
Quand ça vaut le coup, et quand non
SQLite est parfait pour un projet local mono-utilisateur qui veut relire son historique.
Il ne vaut plus le coup dès qu’il y a plusieurs workers, un conteneur éphémère ou si le vrai besoin est de chercher dans l’historique plutôt que de le relire.
Ce que je changerais si je recommençais
Je referais une tranche verticale d’abord : brancher /chat sur la base avant de construire six endpoints que personne n’appelle.
Le CRUD complet a masqué deux vrais bugs (updated_at jamais mis à jour, cascades SQLite inactives) que 27 tests verts n’ont pas attrapés.
La stack
Python 3.13+ avec FastAPI pour l’API. SQLAlchemy 2.0 pour l’ORM et SQLite comme base de données.
React 18 pour l’interface.
Docker Compose pour l’orchestration des services (backend, frontend, Ollama, Qdrant).