Stateful vs stateless agents : que choisir ?

Introduction

Le choix stateful vs stateless agents devient utile dès qu’un agent sort du prototype et commence à vivre dans un vrai workflow métier. Ce comparatif est pertinent si vous hésitez entre simplicité d’exécution, mémoire utile, reprise après incident et coût d’exploitation. Vous allez voir quand un agent sans état suffit, quand un état de session devient rentable, et quand un état durable devient un prérequis. Si votre run reste court, déterministe et facile à relancer, ce n'est probablement pas le bon choix de persister partout : restez sur une approche plus simple.

Résumé rapide

Critère	Stateless	Session state	Durable state
Meilleur fit	tâche courte, une décision, rerun peu coûteux	conversation, formulaire, workflow borné	run long, reprise, audit, coordination
Force principale	simplicité, faible maintenance, latence plus basse	garde le fil sans alourdir toute l’architecture	fiabilité, reprise partielle, traçabilité métier
Limite principale	oublie tout entre deux runs	fragile si le worker redémarre ou si le flux se distribue	stockage, synchronisation, observabilité plus exigeants
Quand l’éviter	si le coût d’un rerun est élevé	si plusieurs services doivent relire le même état	si le besoin tient encore dans une seule étape
Verdict	meilleur point de départ par défaut	bon palier intermédiaire	à réserver aux cas où la reprise et l’audit créent une vraie valeur

En pratique, la vraie question n’est pas « avec mémoire ou sans mémoire ? ». La bonne question est : combien d’état faut-il conserver pour rendre le système utile, relançable et lisible, sans payer une dette d’exploitation inutile.

Stateful vs stateless : où vit réellement la complexité ?

La différence la plus utile entre un agent stateless et un agent stateful ne porte pas sur son “intelligence”, mais sur l’endroit où vous placez la continuité du travail. Un agent stateless reçoit une entrée, utilise son contexte immédiat, agit puis termine. À l’exécution suivante, il repart d’un état vierge. Cela reste très efficace pour un enrichissement ponctuel, une classification simple ou une génération courte où l’échec se corrige par un rerun bon marché.

Un agent stateful conserve au contraire une partie de la situation entre plusieurs étapes ou plusieurs runs : étape courante, sorties intermédiaires, statut de validation, références de documents, décision déjà prise, ou prochaine action autorisée. C’est précisément ce que formalise le guide sur le state management pour agents IA. L’état n’est donc pas un bonus abstrait. C’est un contrat de reprise et de coordination.

Le sujet devient concret quand on observe les incidents réels. Sans état, un timeout sur un appel outil oblige souvent à relancer toute la chaîne, même si 90 % du travail était déjà valide. Avec un état mal cadré, l’agent ne tombe plus forcément en panne, mais il devient plus difficile à relire : quelle version du contexte a été utilisée, quelle étape a déjà réussi, quel effet externe a déjà été déclenché ? L’état n’élimine pas la complexité ; il la déplace vers la modélisation, le stockage et l’observabilité.

Il faut aussi éviter un raccourci fréquent : “stateless” ne veut pas dire “sans aucun contexte”, et “stateful” ne veut pas dire “tout stocker”. Un agent peut rester stateless tout en recevant un contexte calculé à la volée. Inversement, un agent stateful peut rester simple si vous ne persistez que ce qui sert à reprendre ou à arbitrer proprement. Le vrai arbitrage est donc économique : combien de coordination, de maintenance et de lecture incident êtes-vous prêt à payer pour éviter des reruns ou des décisions aveugles ?

Quand choisir stateless, session state ou durable state

Le plus utile n’est pas d’opposer deux camps idéologiques, mais de distinguer trois niveaux : stateless, état de session, puis état durable. Ce découpage donne un repère plus opérationnel qu’un simple “avec mémoire / sans mémoire”.

1. Choisir stateless quand le rerun coûte peu

Un agent stateless suffit largement si votre tâche tient dans une seule intention claire, avec peu d’outils et une sortie facile à recalculer. C’est le cas d’un classifieur de tickets, d’un générateur de brouillon à partir d’un prompt borné, ou d’un enrichissement ponctuel déclenché par un événement applicatif. Dans ce cadre, le meilleur arbitrage est souvent le même que dans agent IA vs workflow : garder une exécution simple, lisible et peu coûteuse.

Le bon signal est le suivant : si le run échoue, pouvez-vous relancer sans doute sur les effets de bord, sans coût significatif et sans travail humain perdu ? Si oui, le stateless garde un avantage net. Vous avez moins de logique de persistance, moins de risque de divergence entre services, et un debugging plus local. Le piège classique est de confondre une tâche légèrement variable avec un besoin d’état durable. Dans beaucoup de cas, quelques paramètres explicites ou un workflow mieux cadré suffisent.

2. Introduire un état de session quand le fil d’exécution compte

L’état de session devient intéressant quand un agent doit conserver le fil sur plusieurs tours ou plusieurs étapes courtes, sans que cela justifie encore un stockage durable complet. Pensez à une conversation support avec collecte progressive d’informations, à un assistant interne qui remplit un formulaire complexe, ou à un run qui passe par qualification, recherche puis génération dans le même worker.

Ici, le vrai gain n’est pas la mémoire longue, mais la cohérence locale : éviter de redemander les mêmes éléments, garder la décision courante, et savoir où le flux en est. Ce palier intermédiaire est souvent sous-estimé. Il permet de lisser l’expérience sans basculer trop tôt dans une architecture de persistance lourde. En revanche, il reste fragile dès qu’un redémarrage, une distribution multi-workers ou une validation externe entrent dans le jeu.

3. Passer au durable state quand la reprise a une valeur métier

L’état durable devient rationnel lorsque le run doit survivre à un redémarrage, à un timeout, à une validation humaine, ou à une coordination entre composants. À ce stade, le vrai sujet n’est plus la commodité de l’agent, mais la continuité de service. Le guide sur le checkpointing pour agents IA couvre justement cette zone : on ne persiste pas pour faire “plus avancé”, mais pour reprendre proprement là où un run s’est arrêté.

Le bon signal est souvent visible dans les coûts cachés : documents déjà traités qu’il faut retraiter, appels modèles déjà payés, décisions humaines perdues, ou actions externes qu’il devient risqué de rejouer. Dès que ces pertes deviennent concrètes, l’état durable cesse d’être une sophistication et devient une protection opérationnelle.

4. Le tableau de décision qui évite la sur-architecture

Situation	Niveau d’état à privilégier	Pourquoi
Classification simple, réponse courte, aucun effet sensible	Stateless	un rerun coûte peu et l’état n’apporte presque rien
Conversation guidée, formulaire, workflow local en 2-3 étapes	Session state	l’agent garde le fil sans gérer toute la persistance métier
Run long, documents multiples, validation humaine, reprise nécessaire	Durable state	la perte de progression coûte plus cher que la persistance
Plusieurs rôles ou services doivent partager la même vérité	Durable state structuré	il faut un point de lecture unique, sinon la coordination dérive
Équipe sans discipline de logs, retries et versioning	Stateless ou session state	un état durable mal opéré crée plus de dette qu’il n’en retire

5. Le coût caché d’un agent stateful

Le mauvais calcul consiste à croire qu’un agent stateful “sait plus de choses”, donc qu’il est forcément meilleur. En réalité, il vous oblige surtout à gérer de nouveaux objets : schéma d’état, version de transitions, politique de rollback, stockage, synchronisation, nettoyage, sécurité et relecture incident. C’est là que des articles comme observabilité des agents IA en production deviennent nécessaires : sans traces, run_id, statut d’étape et lecture des retries, vous empilez de l’état sans gagner en fiabilité réelle.

6. Lien avec la coordination d’architecture

Le choix stateful vs stateless interagit aussi avec la structure globale de l’agent. Dès que plusieurs rôles interviennent, l’état devient un problème de coordination, pas seulement un détail d’implémentation. Le comparatif mono-agent vs multi-agent aide à clarifier ce point : plus vous distribuez les responsabilités, plus l’état partagé doit être lisible, borné et observable. Sinon, chaque composant reconstruit sa version locale de la vérité, et les bugs deviennent chers à diagnostiquer.

Le repère pratique est simple : partez stateless tant que la tâche reste courte et que la relance est tolérable. Ajoutez un état de session quand vous devez garder le fil localement. Passez au durable state seulement quand la reprise, l’audit ou la coordination créent un gain business visible et récurrent.

Exemple concret : support B2B avec reprise et audit

Prenons une équipe support B2B qui veut automatiser le tri et la préparation de réponse sur des tickets complexes. Le flux paraît simple au départ : lire le ticket, récupérer la documentation utile, proposer un brouillon, puis ouvrir une escalade si le cas touche la conformité ou la facturation. En version stateless, cela marche tant que chaque ticket se traite en un seul passage et que l’échec se corrige par un rerun immédiat.

Le problème apparaît quand le ticket déclenche plusieurs sous-étapes : recherche documentaire, enrichissement CRM, validation d’un niveau de priorité, puis génération de réponse. Si le worker tombe après la recherche mais avant la validation, relancer tout le run coûte du temps, des appels modèles et parfois une nouvelle lecture humaine. C’est là qu’un durable state bien borné devient utile : run_id, étape courante, sources retenues, statut de validation, nombre de retries et prochaine action autorisée.

Le bon compromis n’est pourtant pas de tout rendre stateful. Dans ce cas, la lecture du ticket et la première classification peuvent rester stateless. En revanche, dès qu’un agent doit conserver des sources sélectionnées, suspendre un run pour validation et reprendre sans refaire les appels coûteux, l’état persistant devient un vrai levier d’exploitation. Le verdict est donc tranché : si votre valeur vient d’une simple décision ponctuelle, gardez le stateless ; si votre valeur dépend d’une reprise fiable et d’un audit clair, le stateful n’est plus un luxe mais une exigence.

Bonnes pratiques

Commencez toujours par modéliser la perte acceptable. Si un rerun complet ne coûte presque rien, persister de l’état est souvent du sur-design. En revanche, si vous perdez des appels outils, une validation humaine ou des sorties intermédiaires coûteuses, l’état devient un sujet produit, pas seulement un sujet technique.

Ensuite, persistez le minimum utile. Un bon état contient ce qui pilote la reprise : étape, identifiants, sorties validées, erreurs exploitables, prochaine transition. Il ne doit pas devenir un dépôt de prompts, de logs bruts ou de documents entiers. Cette discipline réduit la dette de maintenance et facilite le rollback.

Mini-checklist avant de passer en stateful :

• le coût d’un rerun complet est mesurable et non trivial ;
• les effets externes sont idempotents ou compensables ;
• l’équipe sait lire run_id, statut d’étape, retries et version de workflow ;
• un scénario plus simple reste possible si l’état durable n’apporte pas de gain net.

Enfin, gardez une logique par paliers. Stateless d’abord, session state ensuite, durable state seulement quand la reprise, l’audit ou la coordination le justifient. En production, cette progressivité protège mieux qu’une architecture “complète” montée trop tôt.

Questions fréquentes

Quelle différence entre stateful et stateless agents ?

Un agent stateless traite une entrée puis oublie l’exécution une fois la réponse produite. Un agent stateful conserve une partie de la situation entre plusieurs étapes ou plusieurs runs : statut, sorties intermédiaires, validations ou prochaine action. La différence utile n’est donc pas théorique ; elle concerne surtout reprise, audit et coût d’exploitation.

Quand un agent stateless suffit-il largement ?

Un agent stateless suffit quand la tâche reste courte, avec peu d’outils, peu d’effets de bord et un rerun peu coûteux. C’est souvent le bon point de départ pour un classifieur, un brouillon ponctuel ou un enrichissement simple. Dès que la perte de progression devient chère, cette approche montre ses limites.

Faut-il stocker tout l’historique pour rendre un agent stateful ?

Non. Un bon agent stateful ne stocke pas tout ; il persiste seulement ce qui permet de reprendre, d’arbitrer et d’auditer correctement. Trop stocker complique synchronisation, sécurité et maintenance. Le bon réflexe est de conserver un état exécutable, pas une archive brute du système.

Comment choisir entre session state et durable state ?

Choisissez un état de session si vous devez garder le fil localement dans un worker ou une conversation courte. Choisissez un durable state si le run doit survivre à un redémarrage, à une validation humaine ou à une orchestration distribuée. La vraie ligne de partage est la valeur métier de la reprise, pas la mode des architectures stateful.

Articles liés

Retenez l’arbitrage central : le stateless reste le meilleur point de départ tant qu’un rerun complet reste acceptable, et le stateful devient rentable quand la reprise, l’audit ou la coordination évitent une perte réelle de temps, de qualité ou d’argent. La prochaine étape logique consiste à définir précisément ce que votre run doit conserver, puis à choisir le niveau de persistance minimal qui protège cette valeur. Si vous devez persister des runs sans sur-architecturer, lisez ensuite Gérer l’état d’un agent IA.

• Gérer l’état d’un agent IA
• Reprendre un agent sans tout relancer
• Observabilité agents IA en production
• Agent IA vs workflow : lequel choisir ?
• Mono-agent vs multi-agent : quel choix ?