LangGraph utilise Postgres pour conserver l’historique client

Un agent de service client construit avec LangGraph gagne en robustesse grâce à une persistance Postgres. L’application Streamlit peut fonctionner avec un conteneur PostgreSQL 16 local via Docker ou une instance distante, sans modification de comportement, et les données sont conservées après redémarrage.

La persistance reste active quand l’app redémarre

Avec une base Postgres, Streamlit et la base fonctionnent dans des processus distincts : relancer l’application ne redémarre pas le conteneur de base de données. Les réservations sont stockées sur un volume Docker persistant, ce qui permet à l’application de retrouver l’historique lors de nouveaux rendez-vous. La base de données n’est supprimée que si le conteneur est arrêté ou supprimé et que le volume est effacé. Ce principe s’applique aussi avec une instance distante : seul l’emplacement de Postgres change, le comportement de l’application reste identique.

Un environnement local reproductible en quelques minutes

Les tests avec Docker offrent un serveur PostgreSQL réel local, équivalent à la production, sans nécessiter d’installation de Postgres sur la machine. Les URL et identifiants sont centralisés dans les fichiers de configuration, ce qui garantit la reproductibilité. La base, isolée dans un conteneur, peut être arrêtée ou supprimée sans affecter le reste du système, facilitant des cycles de tests propres et rapides.

Configuration Docker : image, ports, volume et santé

Le projet fournit un docker-compose qui démarre PostgreSQL 16 via l’image postgres:16-alpine, avec POSTGRES_USER=booking, POSTGRES_PASSWORD=booking et POSTGRES_DB=booking_agent. Le port 5432 du conteneur est exposé sur 5432 en local et un volume booking_pgdata stocke les données. Un healthcheck pg_isready s’exécute toutes les 5 secondes avec un délai de 5 secondes et 10 tentatives. Après avoir vérifié que Docker Desktop fonctionne, le conteneur se lance avec « docker compose up -d ». La chaîne DATABASE_URL à utiliser est « postgresql://booking:booking@localhost:5432/booking_agent ». L’application se lance via la commande Streamlit fournie et une réservation de test a pu être réalisée ; l’interface n’a pas proposé le créneau déjà réservé, et l’activité est visible dans Docker Desktop.

Base hébergée : même appli, Postgres distant

Une instance Postgres dans le cloud peut remplacer le conteneur local. Il suffit de créer la base via le fournisseur, de récupérer une chaîne de connexion de type « postgresql://USER:PASSWORD@HOST:PORT/DATABASE », de la placer dans le fichier .env comme DATABASE_URL, puis de démarrer l’application comme précédemment. Le fonctionnement de l’application reste identique, seule l’infrastructure d’hébergement de Postgres change.

LangGraph stocke les échanges et consulte les réservations

La progression de la conversation est gérée dans LangGraph AgentState et enregistrée sous forme de points de contrôle. Avant de proposer des créneaux, l’agent interroge les réservations existantes pour éviter d’offrir un horaire déjà pris ; lors d’une confirmation, il consigne technicien, plage horaire, adresse et prix. Deux modes de persistance existent : en mémoire, destiné à la démonstration et aux tests rapides, et Postgres pour la durabilité. Sans DATABASE_URL, l’application utilise InMemoryBookingRepository et MemorySaver sans créer de tables, et l’état est perdu au redémarrage. Pour un essai local, les dépendances s’installent avec Poetry, un fichier .env est créé, OPENAI_API_KEY défini, puis l’interface est lancée à localhost:8501. L’agent peut produire un devis si toutes les informations nécessaires ont déjà été fournies, ou demander taille et adresse sinon.

Capacités de l’agent et feuille de route du projet

Construit avec LangGraph et doté d’un état, l’agent gère un parcours de réservation de 15 minutes, intégré à une interface Streamlit et soutenu par Postgres. Né d’un échange avec un service de nettoyage, il couvre questions clients, compréhension des besoins, calcul et présentation du prix, acceptation ou refus, proposition d’horaires optimisés, puis confirmation et enregistrement du rendez-vous. Le code est disponible sur GitHub sous customer-service-agent. Le projet évolue vers un produit à valeur d’usage, avec en perspective l’ajout de canaux comme WhatsApp, une couche de sécurité pour limiter l’injection de requêtes, et des améliorations du flux de réservation et de l’expérience de chat, qui feront l’objet de développements à venir.