Galaris : faire durer une mission au-delà de la conversation

Blog · Laurent Lécluse · 9 octobre 2026

Confier une mission à un agent pose rapidement des questions de logiciel classique : que se passe-t-il si la connexion coupe ? Si le serveur redémarre ? Si un outil a effectué une action, mais que sa réponse n’est jamais arrivée ?

Dans Galaris, je sépare l’échange conversationnel du travail durable. La conversation permet de formuler une demande et de suivre ce qui se passe. Une tâche porte la mission, son état et ses tentatives d’exécution. Voici les mécanismes derrière cette séparation.

Une tâche a une existence en base

Prenons un exemple pédagogique : un agent doit comparer trois propositions et rédiger une note de synthèse. L’utilisateur ferme son navigateur pendant l’analyse. À son retour, il veut retrouver la mission et comprendre son avancement.

Pour soutenir ce type d’usage, PostgreSQL conserve les tâches et leurs journaux. Un ordonnanceur sélectionne le travail éligible ; la façade agentique organise son exécution. Dans le code, app.task porte la persistance et l’ordonnancement, tandis que app.agent porte l’orchestration. Ces responsabilités sont explicites dans les invariants.

L’interface peut ainsi reconstruire son affichage à partir d’un état conservé côté serveur. Le suivi d’activité se recharge à l’ouverture et à la reconnexion, puis reçoit les événements des runs actifs. Le flux d’exécution décrit ce contrat.

Distinguer la mission de ses tentatives

Une mission peut rencontrer une erreur de transport, être interrompue ou nécessiter une reprise. Son identité reste utile pendant ces changements ; chaque tentative doit aussi conserver sa propre trace.

Galaris distingue donc Task, la tâche, de TaskAttempt, une tentative de prise en charge. L’ordonnanceur réclame une tâche avec un bail, ou lease : une autorisation temporaire d’exécution. Une tentative remplacée ou dont le bail a expiré perd le droit d’écrire les checkpoints de cette exécution. Le mécanisme est décrit dans la séquence nominale et les règles de reprise.

Cette frontière répond à un problème concret de concurrence. Un ancien worker peut revenir tardivement après une coupure, alors qu’une nouvelle tentative a pris le relais. Il faut empêcher son résultat de réécrire l’état courant.

Rendre les transitions compréhensibles

Le code définit les transitions entre création, routage, exécution, planification, succès et erreur. La suspension conserve la phase à reprendre. Les indications visibles comme « en attente » ou « en pause » sont des projections de cet état, plutôt que des phases supplémentaires à synchroniser partout.

La machine d’état des tâches donne les événements admis et leurs effets. Elle précise notamment ce qu’un retry peut reprendre.

Décrire ces transitions aide à examiner un comportement : une tâche en erreur doit-elle relancer le routage, l’exécution ou la livraison du résultat ? Ces opérations touchent des parties différentes du travail et n’ont pas les mêmes conséquences.

Le cas difficile : l’action a-t-elle déjà eu lieu ?

Reprenons un cas pédagogique, cette fois avec un outil qui crée un dossier dans une application externe. L’outil reçoit la demande, crée le dossier, puis la connexion coupe avant l’accusé de réception. Répéter la demande peut créer un doublon.

Dans le harnais interne de Galaris, un journal marque l’appel d’outil avant son exécution, puis enregistre son résultat. Un résultat déjà journalisé peut être restitué lors de la reprise. Un appel interrompu dont l’effet est inconnu demande un traitement particulier : sans preuve permettant de le réconcilier ni contrat autorisant son rejeu, le système conserve un diagnostic d’incertitude.

Deux propriétés aident à décider :

• une lecture peut être réessayée lorsque son contrat l’autorise ;
• une opération idempotente peut être répétée en conservant le même effet métier, par exemple avec un identifiant de demande stable pris en charge par le service cible.

Les outils inconnus sont traités de manière conservatrice. La politique repose sur leurs contrats explicites. Le journal des effets et des checkpoints détaille ces règles et leurs limites selon le driver.

Planifier quand les unités de travail peuvent être reprises séparément

Une mission peut s’exécuter directement ou devenir un plan. Dans Galaris, le dispatcher distingue la difficulté d’une demande de sa possibilité de décomposition : un livrable complexe peut rester une exécution directe ; un plan se justifie lorsque plusieurs unités de travail gagnent à être terminées, vérifiées et reprises séparément.

La décision de routage et les choix disponibles sont conservés. Cette politique est décrite dans la séquence d’exécution.

Pour l’exemple des trois propositions, la question devient concrète : les analyses sont-elles indépendantes ? Quels résultats faut-il conserver ? Quelle étape produit la synthèse ? Définir ces frontières prépare aussi les contrôles et la reprise.

Ce que cette conception apporte à un projet métier

Ces mécanismes servent également aux imports, aux traitements documentaires et aux synchronisations entre logiciels. Dans chaque cas, il faut conserver la demande, suivre les tentatives, délimiter les actions rejouables et rendre les échecs explicables.

Mon travail sur Galaris associe l’intégration de l’IA à cette conception de l’exécution : préciser l’état durable, les frontières de responsabilité et les preuves nécessaires avant de déclarer un travail terminé.

Lire la suite : outils et autorisations · Revenir à la stack · Parlons de vos traitements

Repère technique : architecture publique au commit 7e7bdea8, consultée le 9 octobre 2026. Les exemples sont pédagogiques ; les possibilités de reprise dépendent du harnais et des outils utilisés.