La stack de Galaris : du navigateur aux agents IA

Blog · Laurent Lécluse · 9 octobre 2026

Dans Galaris, on peut discuter avec un agent, lui confier une mission, suivre son activité et retrouver les documents produits. Derrière ces usages, plusieurs systèmes doivent coopérer : une interface web, une API, une base de données, des moteurs d’exécution et des outils connectés.

Je conçois et développe cette plateforme de bout en bout. Pour expliquer sa stack, le plus utile est de suivre les responsabilités de chaque brique : où vit l’état d’une mission ? Qui contrôle les accès ? Comment un changement de modèle se répercute-t-il dans l’application ?

Les principales briques

Ces briques sont décrites dans le guide développeur. Les dépendances frontend et backend permettent d’en examiner le détail.

Vue et Quasar : donner une forme au travail

L’interface doit rendre compréhensible une activité qui se déroule parfois pendant plusieurs minutes. Une conversation, la fiche d’un agent et le suivi d’une mission présentent des informations liées, avec des interactions différentes.

Vue porte les composants de l’interface. Quasar fournit les éléments visuels et interactifs ; Pinia organise les états partagés ; TypeScript permet de vérifier les contrats utilisés dans le code frontend. Vite assure le développement et la construction de l’application. Cette répartition est visible dans le manifeste frontend.

Le travail de conception consiste ensuite à choisir les informations utiles à chaque écran. Une mission en attente d’une réponse humaine doit pouvoir se distinguer d’une mission en cours d’exécution. L’utilisateur a besoin de comprendre ce qu’il peut faire à ce moment-là : apporter une précision, examiner un résultat ou demander un arrêt.

FastAPI et PostgreSQL : garder un état durable

Le backend utilise FastAPI pour l’API et Pydantic pour la validation des données. SQLAlchemy et asyncpg relient les services Python à PostgreSQL. La base est la source durable des tâches, des objectifs, des processus et des journaux métier : ce contrat figure dans les invariants d’architecture.

Cette responsabilité est essentielle pour une application qui exécute du travail en arrière-plan. Fermer un onglet ne doit pas faire disparaître une mission. À la reconnexion, l’interface retrouve son activité depuis le serveur, puis suit les événements des exécutions actives. Ce mécanisme de réhydratation est documenté dans le flux d’exécution.

La mémoire ajoute une autre dimension. Une recherche par mots aide à retrouver un terme exact ; une recherche vectorielle rapproche des formulations de sens voisin. Galaris combine ces approches, avec des contrôles d’accès sur les informations rappelées. Le flux mémoire décrit cette articulation.

Organiser le code autour de responsabilités explicites

Une stack devient difficile à faire évoluer lorsque chaque fonctionnalité dépend des détails de toutes les autres. Dans Galaris, j’organise le code en trois ensembles :

• core porte l’infrastructure commune : API, base, utilisateurs, autorisations et paramètres ;
• app porte les domaines de Galaris : agents, tâches, mémoire, outils et conversations ;
• bridge adapte des systèmes externes aux contrats de la plateforme.

Le socle core ne dépend pas des fonctionnalités de app. Les domaines communiquent par des interfaces publiques. Des contrôles d’architecture refusent de nouvelles dépendances non déclarées ou de nouveaux cycles ; la dette existante est suivie dans une référence explicite. Ces règles sont détaillées dans le guide des couches et modules.

Cela donne un critère concret à la revue de code : une intégration doit rejoindre le bon contrat, et une fonctionnalité doit rester sous la responsabilité de son domaine.

Séparer la plateforme du moteur IA

Un modèle produit des réponses ; un harnais organise son exécution avec des outils et un historique. Galaris dispose d’un harnais interne fondé sur Pydantic AI et de contrats pour d’autres moteurs compatibles.

La façade app.agent porte l’orchestration commune. app.task conserve et ordonnance les tâches. Le driver reçoit une demande d’exécution structurée, sans avoir à manipuler les modèles SQLAlchemy de la tâche. Ces frontières sont documentées dans l’architecture agentique.

Cette séparation permet de garder l’identité, les droits et le suivi du travail dans la plateforme lorsque le moteur compatible change. Elle demande aussi de vérifier ce que chaque driver sait réellement faire : annuler une exécution ou reprendre un checkpoint dépend de ses capacités déclarées.

Ce que ce projet montre de ma pratique

Galaris réunit le développement d’une interface, la conception d’une API, la modélisation des données et l’intégration de moteurs IA. Mon travail consiste à relier ces éléments avec des responsabilités que l’on peut examiner et des comportements que l’on peut vérifier.

Ces questions se retrouvent dans une application métier : conserver un dossier, suivre un traitement long, relier un service externe ou faire évoluer un module sans propager ses détails partout.

Lire la suite : exécuter une mission durable · Voir mon travail sur Galaris · Échanger sur votre application

Repère technique : sources publiques consultées le 9 octobre 2026, au commit 7e7bdea8. Galaris reste en version alpha ; cet article décrit cette révision de son architecture.