État Redis, conteneurs personnalisés et MCP : la couche manquante dans le déploiement d'agents en production

Le piège du prototype

Si vous avez suivi nos guides précédents — démarrer avec LangChain, Ollama et Mistral, et la comparaison des frameworks LangGraph vs. LangChain — vous savez déjà comment faire tourner un agent en local. Vous avez vu comment orchestrer des agents MCP avec CrewAI. Vous avez peut-être même conçu une architecture RAG pour l'IA + Web3.

Ce qu'aucun de ces modèles ne résout, c'est le moment où votre agent doit quitter votre ordinateur portable.

À ce stade, trois problèmes surgissent simultanément :

1. L'état disparaît lorsque le processus redémarre
2. La mise à l'échelle casse parce que chaque réplica conserve sa propre conversation
3. L'intégration des outils se fragmente à mesure que vous câblez manuellement chaque service externe

MCP, Docker et Redis résolvent chacun l'un de ces problèmes. Ensemble, ils forment le modèle de déploiement qui transforme un prototype en infrastructure.

---

Problème 1 — L'état n'a nulle part où vivre

LangGraph est explicite à ce sujet : les agents sont des graphes à état. Chaque transition de nœud, chaque appel d'outil, chaque étape de raisonnement intermédiaire est un état qui doit survivre à l'invocation suivante.

En mode prototype, cet état vit en mémoire. En production, un état en mémoire signifie :

• Un redémarrage de conteneur efface la conversation
• Deux réplicas derrière un load balancer produisent deux conversations divergentes
• Les workflows longs ne peuvent ni se mettre en pause ni reprendre

La réponse de LangGraph est un checkpointer — une couche de persistance externe qui sérialise l'état à des points définis. Postgres est la référence par défaut. Redis est l'option vers laquelle la plupart des équipes arrivent lorsque le débit devient un enjeu.

Pourquoi Redis spécifiquement :

• Lectures et écritures en sub-milliseconde pour les opérations de checkpoint
• Sémantique TTL pour que l'état éphémère des conversations se nettoie automatiquement
• Notifications Pub/Sub permettant aux workers distribués de réagir aux changements de checkpoint en temps réel
• Streams pour le handoff entre agents et l'event sourcing
• Clustering qui correspond aux modèles de déploiement conteneurisés

Si vous avez lu notre article sur l'architecture IA + Web3 + RAG, vous savez déjà comment le contexte de récupération est intégré au prompt. Redis est l'endroit où ce contexte, l'état de la conversation et la mémoire de travail de l'agent vivent tous — récupérables dans le même cycle de requête.

---

Problème 2 — Les conteneurs vous donnent l'isolation, pas l'état

Docker résout le problème du packaging. Il ne résout pas le problème de l'état.

Un conteneur personnalisé vous donne :

• Un runtime reproductible
• Des limites de ressources par service
• L'isolation réseau
• Un déploiement standardisé OCI

Ce qu'il ne vous donne pas, c'est la persistance de l'état. Tuez le conteneur, l'état disparaît. Passez à trois réplicas, trois états indépendants.

La correction est architecturale : l'état vit à l'extérieur du conteneur, indexé par thread ID, dans Redis. N'importe quel réplica peut reprendre n'importe quelle conversation. Redémarrez le conteneur au milieu d'un workflow et l'agent reprend depuis le dernier checkpoint.

C'est le même modèle que nous avons décrit dans le guide chatbot CrewAI MCP lorsque plusieurs agents doivent se coordonner — la couche d'état partagée est ce qui permet aux handoffs de fonctionner de manière fiable.

---

Problème 3 — L'intégration des outils ne se standardise pas toute seule

C'est ici que MCP entre dans la conversation.

Le Model Context Protocol est un standard ouvert pour exposer des outils, des sources de données et des prompts aux applications LLM via une interface JSON-RPC cohérente. Son architecture sépare :

• Host — votre application
• Clients — connecteurs à l'intérieur du host
• Servers — services exposant des outils et des ressources

Le détail opérationnel important que la plupart des explications MCP omettent : les serveurs MCP sont généralement déployés en tant que conteneurs Docker.

Ce n'est pas anodin. Conteneuriser les serveurs MCP est ce qui rend le modèle viable dans les environnements d'entreprise :

Le MCP Gateway de Docker va plus loin en centralisant les secrets, l'authentification et les politiques à travers chaque connexion MCP.

Si vous avez suivi le guide CrewAI + MCP, c'est la moitié déploiement de ce que vous avez construit.

---

L'architecture de référence

┌─────────────────────────────────────────────────────────────┐
│                    MCP Host (Your Application)              │
│                    MCP Clients (Connectors)                 │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│              Docker Container Runtime                       │
│  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────┐ │
│  │  MCP Server A   │  │  MCP Server B   │  │  LangGraph  │ │
│  │  (Tool Provider)│  │  (Data Source)  │  │   Agent     │ │
│  └────────┬────────┘  └────────┬────────┘  └──────┬──────┘ │
└───────────┼────────────────────┼───────────────────┼────────┘
            │                    │                   │
            ▼                    ▼                   ▼
┌─────────────────────────────────────────────────────────────┐
│                    Redis State Layer                        │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────┐  │
│  │  Checkpoints │  │  Agent Memory│  │  Pub/Sub Events  │  │
│  │  (TTL)       │  │  (Semantic)  │  │  (Coordination)  │  │
│  └──────────────┘  └──────────────┘  └──────────────────┘  │
└─────────────────────────────────────────────────────────────┘

Chaque composant résout un problème distinct. Aucun ne résout les trois.

---

Ce que cela signifie pour votre pipeline de déploiement

Trois questions d'approvisionnement auxquelles cette architecture répond clairement :

« Où vivent nos données ? » Instance Redis que vous contrôlez, avec politiques TTL, chiffrement au repos et pistes d'audit.

« Comment cela se met-il à l'échelle ? » Mise à l'échelle horizontale des conteneurs avec un état Redis partagé. Aucune affinité de session requise. N'importe quel réplica peut servir n'importe quelle conversation.

« Que se passe-t-il en cas de panne ? » L'état persiste à travers les redémarrages de conteneurs. Pub/Sub expose les changements de checkpoint pour une surveillance en temps réel. Les workflows échoués reprennent depuis le dernier checkpoint plutôt que de repartir de zéro.

---

Quand ce modèle est approprié — et quand il ne l'est pas

Utilisez des agents conteneurisés avec Redis quand :

• Les conversations s'étendent sur plusieurs tours ou sessions
• Vous avez besoin d'une mise à l'échelle horizontale derrière un load balancer
• Les handoffs multi-agents nécessitent un état partagé
• L'intégration des outils est exposée via MCP

Envisagez un état adossé à Postgres quand :

• Vous avez besoin d'auditabilité à long terme de chaque décision d'agent
• Les requêtes relationnelles sur l'historique des agents importent plus que la latence

Approche hybride : Redis pour l'état chaud, Postgres pour l'archivage. La plupart des systèmes en production convergent ici.

---

Où Quopa intervient

Les quatre articles liés ci-dessus couvrent les briques de base. Le vide, c'est le déploiement.

Nous aidons les équipes à passer du prototype à la production avec :

• Conception de couche d'état adossée à Redis pour les agents LangGraph, LangChain et CrewAI
• Packaging de conteneurs personnalisés incluant le déploiement de serveurs MCP
• Architecture d'intégration connectant RAG, contexte Web3 et outils d'entreprise à travers une seule fabrique d'état

Si vous avez dépassé le stade du prototype et que le problème d'état est apparu, c'est la conversation à avoir maintenant — pas après le premier incident de production.

Parlez-nous du déploiement d'agents de niveau production →

---