Mettre un agent IA en production : observabilité, mémoire et API

Votre Assistant Teranga marche sur votre machine. Mais le gérant veut le mettre en ligne pour ses clients — et là, trois questions surgissent qu’on n’avait pas en développement : « pourquoi a-t-il répondu ça ? », « combien ça coûte par jour ? » et « comment le faire tourner 24 h sur 24 sans que je relance le script ? ». Passer d’un prototype à un service fiable, c’est le sujet de ce dernier tutoriel.

On va rendre l’assistant observable (voir chaque décision avec LangSmith), lui donner une mémoire persistante qui survit aux redémarrages, l’exposer derrière une petite API web, et passer en revue la checklist de mise en production. À la fin, votre agent ne sera plus une démo, mais un service.

🎯 Ce que vous allez apprendre

• Tracer chaque exécution d’agent avec LangSmith, sans changer votre code.
• Rendre la mémoire de conversation persistante (au-delà de la RAM).
• Exposer l’agent derrière une API web avec FastAPI.
• Connaître la checklist coût, latence, sécurité avant la mise en ligne.

🛠️ Ce que vous allez construire

La version « production » de l’Assistant Teranga : une API POST /chat qui reçoit le message d’un client et renvoie la réponse de l’agent, avec chaque échange tracé dans LangSmith pour le déboguer, et une mémoire qui se souvient des conversations même après un redémarrage du serveur.

Prérequis

• Avoir un agent fonctionnel issu des tutoriels précédents (create_agent ou un graphe LangGraph).
• Python 3.10+. On ajoute : pip install -U langsmith fastapi uvicorn.
• Un compte LangSmith (offre gratuite suffisante pour démarrer) pour obtenir une clé d’API.
• ⏱️ Temps estimé : ~50 minutes.

Étape 1 — Voir ce que fait l’agent avec LangSmith

Le pire en production, c’est un agent qui répond mal sans qu’on sache pourquoi. LangSmith résout ça : il enregistre chaque appel de modèle, chaque outil, chaque étape, et les affiche dans une interface web où l’on rejoue le raisonnement. Le plus beau : pour une application LangChain ou LangGraph, on n’écrit aucun code de traçage — il suffit de poser quelques variables d’environnement.

import os

os.environ["LANGSMITH_TRACING"] = "true"
os.environ["LANGSMITH_API_KEY"] = "votre-cle-langsmith"
os.environ["LANGSMITH_PROJECT"] = "assistant-teranga"   # regroupe les traces

# ... puis votre code habituel, INCHANGÉ :
from langchain.agents import create_agent
from langchain.chat_models import init_chat_model
assistant = create_agent(init_chat_model("openai:gpt-4o-mini"), tools=[])
assistant.invoke({"messages": [{"role": "user", "content": "Bonjour !"}]})

Dès que ces variables sont en place, chaque invoke apparaît dans votre tableau de bord LangSmith : la question, les outils appelés, le temps de chaque étape, le nombre de jetons consommés. Rendez-vous sur l’interface : vous y voyez la trace complète, comme une boîte noire d’avion. C’est exactement ce qu’il faut pour comprendre une réponse étrange ou une facture qui grimpe.

✅ Point d’étape — après un invoke, une trace apparaît dans le projet « assistant-teranga » de LangSmith. Si rien n’apparaît, vérifiez LANGSMITH_TRACING="true" et la validité de la clé.

Étape 2 — Une mémoire qui survit au redémarrage

Dans le tutoriel LangGraph, InMemorySaver gardait la conversation en RAM — donc tout disparaissait à l’arrêt du serveur. En production, un client doit pouvoir reprendre sa conversation même après une coupure de courant ou un redéploiement. La solution : un checkpointer qui écrit dans une base, par exemple PostgreSQL, que beaucoup hébergent déjà.

# pip install -U langgraph-checkpoint-postgres
from langgraph.checkpoint.postgres import PostgresSaver

DB = "postgresql://user:motdepasse@localhost:5432/teranga"

with PostgresSaver.from_conn_string(DB) as memoire:
    memoire.setup()                     # crée les tables au premier lancement
    app = graphe.compile(checkpointer=memoire)
    config = {"configurable": {"thread_id": "client-77"}}
    app.invoke({"messages": [{"role": "user", "content": "Bonjour, ma commande ?"}]}, config)

Le code de votre graphe ne change pas : seul le checkpointer passe de la RAM à PostgreSQL. Désormais, l’état de chaque thread_id est sauvegardé sur disque. Redémarrez le serveur, relancez avec le même thread_id : la conversation reprend là où elle s’était arrêtée. C’est la différence entre une démo et un service sur lequel un client peut compter.

✅ Point d’étape — après un redémarrage, une conversation reprend son contexte. Si la mémoire est vide, vérifiez que setup() a bien créé les tables et que la chaîne de connexion est correcte.

Étape 3 — Exposer l’agent derrière une API web

Un agent dans un script n’est utile à personne. Pour qu’un site, une application mobile ou un bot puisse l’interroger, on l’enveloppe dans une petite API. FastAPI est parfait : léger, rapide, et il génère même une documentation interactive. On crée un seul point d’entrée, POST /chat.

from fastapi import FastAPI
from pydantic import BaseModel

api = FastAPI()

class Message(BaseModel):
    client_id: str
    texte: str

@api.post("/chat")
def chat(m: Message):
    config = {"configurable": {"thread_id": m.client_id}}
    sortie = app.invoke({"messages": [{"role": "user", "content": m.texte}]}, config)
    return {"reponse": sortie["messages"][-1].content}

On lance le serveur avec uvicorn fichier:api --reload. Le client_id sert de thread_id : chaque client garde son fil de conversation, et la mémoire persistante de l’étape 2 fait le reste. Testez avec un simple curl ou rendez-vous sur /docs pour l’interface générée automatiquement. Votre agent est maintenant joignable par n’importe quelle application.

✅ Point d’étape — un appel POST /chat avec un client_id et un texte renvoie une réponse JSON. Si vous obtenez une erreur 500, regardez la trace LangSmith : elle vous dira précisément où ça casse.

L’option LangGraph Platform

Écrire son API à la main est instructif et reste parfait pour un petit service. Sachez toutefois que l’écosystème propose des raccourcis : la commande langgraph dev (du paquet langgraph-cli) lance un serveur de développement à partir d’un fichier langgraph.json, avec API, persistance et même une interface de test intégrée. Pour un déploiement plus ambitieux, LangGraph Platform gère le passage à l’échelle. Le choix dépend de vos moyens : pour la coopérative Teranga, un FastAPI sur un VPS modeste suffit amplement ; gardez les plateformes managées pour le jour où le trafic l’exige.

Mesurer la qualité, pas seulement le bon fonctionnement

« Ça marche » ne veut pas dire « ça répond bien ». Un agent peut tourner sans erreur tout en donnant des réponses médiocres. Pour savoir si une modification améliore vraiment l’assistant, il faut une mesure — et c’est là que LangSmith dépasse le simple traçage. On y constitue un jeu d’exemples : une liste de questions clients réelles avec la réponse attendue. On rejoue ensuite l’agent sur ce jeu après chaque changement et on compare.

Concrètement, vous rassemblez vingt vraies questions (« livrez-vous à Kaolack ? », « comment retourner un panier ? »…) et la bonne réponse pour chacune. Avant de changer un prompt ou de modèle, vous lancez l’agent sur ces vingt cas et notez le score ; après le changement, vous recommencez. Si le score baisse, vous l’avez vu avant vos clients. Cette discipline — figer des cas de référence et ne jamais déployer une régression — est ce qui distingue un bricolage d’un service maintenu sérieusement. Commencez petit : même dix exemples valent infiniment mieux que de juger à l’instinct.

Le streaming côté API

En développement, on attend la réponse complète sans gêne. Mais un client face à dix secondes de silence croit que l’assistant est en panne. La parade vue avec LangGraph — le streaming — se prolonge jusqu’à l’API : au lieu de renvoyer toute la réponse d’un bloc, on la diffuse au fil de l’eau, et l’interface affiche le texte mot à mot. FastAPI sait renvoyer un flux (une StreamingResponse) alimenté par le stream de votre agent. Le gain est surtout perçu : la réponse n’arrive pas plus vite, mais le client la voit commencer tout de suite, ce qui change tout sur une connexion lente. C’est un détail d’ingénierie à fort impact sur la satisfaction.

La checklist de mise en production

Avant d’ouvrir l’assistant au public, quelques garde-fous évitent les mauvaises surprises. Ce ne sont pas des détails : ce sont eux qui séparent un projet qui tient de celui qui explose au premier afflux.

• Coût : fixez un plafond mensuel chez votre fournisseur et surveillez les jetons via LangSmith. Un agent qui boucle peut coûter cher en une nuit.
• Latence : mesurez le temps de réponse réel ; activez le streaming pour que le client voie la réponse arriver plutôt qu’un long silence.
• Secrets : jamais de clé d’API dans le code ni dans Git. Utilisez des variables d’environnement et un fichier ignoré par Git.
• Garde-fous : limitez le nombre de messages par client et par minute, et validez les entrées pour vous prémunir des messages piégés qui tenteraient de détourner l’agent.
• Repli : prévoyez une réponse de secours (« un conseiller vous répondra ») si le modèle est injoignable, plutôt qu’une page d’erreur.

🐞 Pièges fréquents

🌍 Adaptation au contexte ouest-africain

La bonne nouvelle : héberger un agent coûte peu. Un VPS à 5 000–7 000 FCFA par mois fait tourner FastAPI et PostgreSQL pour un assistant de PME ou de coopérative. Le vrai poste de coût reste les appels au modèle hébergé : surveillez-les de près avec LangSmith et plafonnez-les. Pour un trafic modéré, un petit modèle « mini » tient parfaitement la charge des questions courantes. Pensez aussi à la résilience face aux coupures : un checkpointer persistant et une réponse de repli garantissent qu’une panne de courant ou une coupure réseau n’efface pas les conversations en cours et ne laisse pas le client devant une erreur. Enfin, l’offre gratuite de LangSmith suffit largement pour démarrer et déboguer sans dépenser un franc.

✅ Récapitulatif

Votre agent est passé du prototype au service : il est observable grâce à LangSmith, il se souvient des conversations même après un redémarrage grâce à un checkpointer persistant, il est joignable par n’importe quelle application via une API FastAPI, et vous connaissez la checklist coût-latence-sécurité avant l’ouverture au public. C’est la dernière brique : l’Assistant Teranga est prêt à servir de vrais clients. Et avec lui, vous tenez désormais toute la chaîne, du premier appel de modèle jusqu’à la mise en ligne.

C’est aussi la fin de la série. En six étapes, vous êtes passé d’un simple appel de modèle à un agent outillé, documenté par un RAG, capable d’enchaîner des actions, d’orchestrer un parcours avec LangGraph, de déléguer à une équipe CrewAI, et enfin de tourner en production sous surveillance. Aucun de ces blocs n’est réservé aux grandes entreprises : chacun tient sur un petit serveur et répond à un besoin concret de PME ou de coopérative. Le reste, c’est de la pratique — reprenez le projet fil rouge, branchez-le sur vos vraies données, et faites-le vivre.

🧾 Aide-mémoire

💪 À vous de jouer

Ajoutez à l’API un point d’entrée GET /sante qui renvoie {"statut": "ok"} — indispensable pour qu’un service de surveillance vérifie que votre agent est en vie. Puis configurez une alerte si l’agent ne répond plus.

@api.get("/sante")
def sante():
    return {"statut": "ok"}

Tutoriels frères

• LangGraph : agents à états et cycles — la mémoire et les parcours sur mesure.
• CrewAI : une équipe d’agents collaboratifs — répartir le travail entre agents.

Pour aller plus loin

• 🔝 Retour au guide principal : le guide des frameworks d’agents IA
• Documentation officielle : démarrage rapide LangSmith
• Sur le déploiement : voir aussi notre tutoriel sécuriser un agent IA en production.

FAQ

Q : LangSmith est-il obligatoire ?
R : Non, mais fortement conseillé. Sans observabilité, déboguer un agent en production relève de la devinette. L’offre gratuite couvre largement les besoins d’un petit projet ; on peut aussi se contenter de journaux applicatifs au début.

Q : Puis-je utiliser une autre base que PostgreSQL pour la mémoire ?
R : Oui, LangGraph propose plusieurs checkpointers (dont SQLite, plus simple pour un mono-serveur). PostgreSQL s’impose dès qu’on veut partager la mémoire entre plusieurs instances ou un trafic conséquent.

Q : Faut-il LangGraph Platform pour déployer ?
R : Non. Une API FastAPI sur un VPS classique suffit pour la plupart des projets. Les plateformes managées apportent du confort et du passage à l’échelle, mais ce n’est pas un prérequis pour démarrer.

Q : Comment éviter qu’un utilisateur fasse exploser ma facture ?
R : Combinez un plafond de dépense chez le fournisseur, une limite de messages par client et par minute dans l’API, et une alerte sur la consommation de jetons via LangSmith. Ces trois garde-fous suffisent à dormir tranquille.