Un backend Postgres pour un agent LangGraph de réservation

Le moteur de réservation bâti sur LangGraph s'appuie désormais sur une base Postgres, tout en conservant un état de conversation géré par un checkpointer. Seules deux étapes du flux – génération des propositions et confirmation – touchent la base; le reste vit dans l'état de l'agent. Le démarrage choisit automatiquement entre mémoire et Postgres selon la configuration, rendant l'usage multi‑interfaces possible.

Deux nœuds accèdent aux données, l’état persiste entre les tours

Dans le flux de réservation, l'accès au stockage est limité à deux étapes. Le nœud chargé de générer des propositions lit les réservations et les techniciens, tandis que la confirmation écrit la réservation validée. Les autres étapes actualisent uniquement l'état interne sans interroger la table des réservations. La conversation se déroule dans AgentState, utilisé comme mémoire de travail. À chaque pas, les mises à jour partielles des nœuds sont intégrées, puis l'état est enregistré entre les tours grâce au checkpointer adossé à Postgres. Pour proposer des rendez‑vous, le nœud dédié appelle un moteur qui consulte les réservations existantes et la liste des techniciens via le dépôt, applique des règles déterministes sur les 7 prochains jours avec exclusion du dimanche, des heures de départ fixées, une durée et un score de trajet, puis renvoie les 3 meilleures options. Le message retourné expose ces créneaux numérotés. Une fois la confirmation acceptée, l'identifiant de réservation, le statut confirmé et le message récapitulatif sont intégrés à l'état, et un instantané est enregistré pour le thread de conversation.

Pourquoi l’en‑mémoire ne suffit pas en usage réel

La persistance en mémoire montre ses limites dès que l'on quitte un processus unique : au redémarrage, états de conversation et réservations disparaissent. Les sessions ne partagent pas la disponibilité, chaque processus disposant de son propre calendrier. Un même créneau peut être proposé puis confirmé sur la base d'une vue obsolète, alors qu'il a déjà été pris ailleurs. Si cette configuration minimaliste a permis de valider routage et logique lors de démonstrations et tests initiaux, elle ne répond pas aux exigences d'un produit. La nécessité d'un stockage partagé et durable s'impose pour éliminer ces incohérences et pérenniser l'expérience.

Postgres activé par configuration, avec deux tables dédiées

Le passage à Postgres introduit une base relationnelle minimale, composée de deux tables distinctes pour les techniciens et les réservations. La classe de dépôt côté Postgres implémente les opérations nécessaires, avec les fonctions de lecture et d'écriture définies dans cette implémentation. Le choix du backend s'effectue au démarrage. Une fonction d'initialisation opte pour la base Postgres dès qu'une URL de connexion est fournie, fléchant à la fois le dépôt de réservation et le checkpointer vers la base. À défaut, les deux restent en mémoire. Quelle que soit l'option, l'instance conforme à l'interface de dépôt est passée au constructeur du graphe. Dans cette architecture, AgentState demeure la mémoire de travail du graphe, et sa persistance est assurée en tandem par le checkpointer et le moteur de réservation. Le résultat est un backend Postgres opérationnel pour l'agent.

Une interface de persistance unique, branchée au graphe

Pour isoler le graphe et ses moteurs de la technologie de stockage, une interface BookingRepository définit trois capacités : exposer les techniciens par identifiant, lister les réservations confirmées et créer une réservation après contrôle de chevauchement, avec signalement d'erreur si le créneau est pris. Cette abstraction permet d'interchanger, au démarrage, l'implémentation en mémoire et celle pour Postgres. En mode mémoire, aucune table n'est créée ; les réservations vivent dans une liste du processus, les méthodes ne sollicitant jamais la base. Ce mode reste utile pour les tests unitaires et les démonstrations locales, au prix d'une volatilité totale au redémarrage. Côté graphe, la construction s'appuie sur cette interface et instancie un StateGraph ; à défaut d'instance fournie, le dépôt en mémoire est utilisé. Les nœuds consultent ou écrivent via l'interface : la confirmation utilise la création de réservation avec le prix converti en nombre flottant et lève une erreur si aucun créneau n'est sélectionné, puis retourne l'identifiant, le statut confirmé et un message formaté. La structure d'état recense les champs nécessaires, et le graphe peut être compilé avec un checkpointer explicite ou un mécanisme mémoire. Dans l'implémentation en mémoire, la liste des réservations est protégée et renvoyée par copie après verrouillage, et l'écriture vérifie les conflits avant insertion.

Un agent complet, multi‑interfaces, et un code public

L'agent de réservation s'appuie sur un graphe pilotant l'écoute des besoins, le calcul du prix, l'acceptation ou le refus, la proposition de créneaux optimisés, puis la confirmation et l'enregistrement du rendez‑vous. Il a été conçu pour un parcours de 15 minutes et propose déjà une interface Streamlit. Le remplacement des adaptateurs en mémoire par Postgres ouvre la voie à plusieurs interfaces, dont Streamlit et WhatsApp, partageant la même persistance côté serveur. Le projet vise la transformation en produit apte à servir une activité réelle, avec un backend Postgres déjà en place et un dépôt de code public. La suite annoncée porte sur l'exécution avec Docker et le raccordement à une instance Postgres hébergée.