À retenir
- Traitez le modèle comme sans état ; faites d'un magasin externe la source de vérité pour l'état du flux de travail.
- Séparez le contexte de travail, l'état à court terme et la mémoire à long terme — chacun avec ses propres règles de conservation.
- Les actions idempotentes rendent les nouvelles tentatives sûres et évitent les doubles facturations ou les envois en double.
- Mettez les agents en bac à sable avec des permissions en refus par défaut et journalisez chaque appel d'outil.
- Vous êtes juridiquement responsable des actions de vos agents ; construisez donc la piste d'audit pour prouver le contrôle.
Chaque semaine apporte une nouvelle vague d'agents IA : Meta lance une mascotte sympathique, OpenAI regroupe des fonctionnalités existantes dans un personnage avenant, HubSpot renomme sa pile technologique pour la quatrième fois. Les annonces se confondent. Mais sous le marketing, la véritable question d'ingénierie n'a guère changé : comment un agent se souvient-il de ce qu'il a fait, transporte-t-il l'état d'une étape à l'autre, et ce sans créer de risque opérationnel ou juridique ? C'est là que la plupart des projets en production réussissent ou échouent.
Pourquoi la mémoire est la partie difficile, pas le modèle
Les modèles de pointe sont déjà suffisamment bons. Comme le note Zapier, même le plus petit modèle Claude d'Anthropic surpasse désormais les meilleurs systèmes d'il y a deux ans. Le raisonnement brut est rarement le goulot d'étranglement. Ce qui casse en production, c'est la continuité : un agent qui oublie le message antérieur d'un client, réexécute une action facturée ou perd le fil de sa position dans un flux de travail en plusieurs étapes.
La « mémoire » d'un agent recouvre en réalité trois choses distinctes, et les confondre est l'erreur de conception la plus courante que nous observons :
- Le contexte de travail — la conversation et la tâche en cours, conservées dans la fenêtre de prompt. Rapide, mais éphémère et coûteux à faire grandir.
- L'état à court terme — où en est l'agent dans un flux de travail : quels outils il a appelés, ce qui a réussi, ce qui est en attente. Cela appartient à une base de données ou à une machine à états, jamais au seul prompt.
- La mémoire à long terme — les faits durables concernant un utilisateur ou un compte, généralement stockés dans un index vectoriel ou un magasin structuré, et récupérés à la demande.
Des outils comme les « dots » d'OpenAI ou Muse de Meta regroupent ces couches derrière un personnage, ce qui constitue une excellente conception de produit mais ne supprime pas la responsabilité sous-jacente. Si vous bâtissez sur leurs API, vous restez maître des décisions d'architecture concernant ce qui persiste, pendant combien de temps et à quel endroit.
L'état doit résider en dehors du modèle
Le modèle qui résiste au contact avec la production est simple : traiter le modèle comme sans état et faire d'un système externe la source de vérité. Chaque étape de l'agent lit l'état, agit, puis réécrit le nouvel état. Si une exécution plante, on reprend au dernier point de contrôle durable au lieu de tout rejouer depuis le début.
C'est ce qui distingue une véritable exécution de flux de travail — celle que l'AutomationBench de Zapier teste de bout en bout avec de vrais outils — d'un chatbot qui se trouve appeler des fonctions. L'idempotence compte ici aussi : un agent susceptible de réessayer une étape ne doit jamais facturer deux fois une carte ni envoyer une facture en double. Stockez une clé d'opération, vérifiez-la avant d'agir, et la nouvelle tentative devient sûre.
L'hygiène de la mémoire économise de l'argent et de la confiance
Une mémoire sans limite est un tueur silencieux. Entasser tout dans le contexte gonfle le coût en tokens et dégrade la qualité du raisonnement. L'approche disciplinée consiste à résumer et à élaguer : compresser les anciens échanges en un bref résumé d'état, ne promouvoir que les faits durables vers le stockage à long terme, et définir des politiques de conservation par type de données. Cela vous maintient aussi en conformité avec le RGPD — une mémoire qui se souvient indéfiniment d'un client est une responsabilité, pas une fonctionnalité.
Contenir ce que l'agent peut faire
La mémoire décide de ce qu'un agent sait ; le bac à sable décide de ce qu'il peut faire. La récente sortie d'OpenShell par NVIDIA adopte une posture de refus par défaut : tout ce qu'aucune règle n'autorise explicitement est bloqué. Cette philosophie devrait guider tout agent en production, quel que soit l'outillage. Donnez à l'agent l'ensemble d'actions autorisées le plus restreint, journalisez chaque appel d'outil, et gardez des humains dans la boucle pour les opérations à enjeux élevés.
Ce n'est pas de la paranoïa. OpenAI a notifié plus d'une centaine d'organisations au sujet d'activités d'agents pendant l'entraînement des modèles — un rappel que les agents agissent parfois de façons que leurs opérateurs n'anticipent pas toujours.
Vous êtes responsable de ce que font vos agents
Les conditions commerciales convergent entre OpenAI, Anthropic et Google Cloud, et elles pointent toutes dans la même direction : le client est responsable de son compte et des actions de ses agents. La responsabilité est généralement plafonnée à douze mois de frais, les services en bêta sont exclus et les garanties sont étroites. Pour une entreprise qui déploie des agents touchant à de vrais systèmes et à de l'argent réel, cela recadre tout le projet.
Cela signifie que votre piste d'audit, votre journal d'état et vos frontières de permissions ne sont pas de simples raffinements d'ingénierie — ce sont votre défense. Lorsqu'un agent fait quelque chose d'inattendu, vous devrez montrer exactement ce qu'il a vu, ce qu'il a décidé et ce qu'il était autorisé à faire.
Ce que nous recommandons
Pour les équipes qui font passer leurs agents du pilote à la production, les priorités sont constantes :
- Externaliser l'état ; garder le modèle sans état et reprenable.
- Séparer le contexte de travail, l'état du flux de travail et la mémoire à long terme — et appliquer des règles de conservation à chacun.
- Rendre chaque action idempotente afin que les nouvelles tentatives soient sûres.
- Mettre en bac à sable avec des permissions en refus par défaut et journaliser chaque appel d'outil.
- Partir du principe que vous êtes juridiquement responsable de l'agent, et construire la piste d'audit pour prouver le contrôle.
Le modèle que vous choisissez compte moins que l'échafaudage qui l'entoure. Réussissez la mémoire, l'état et le confinement, et un modèle modeste devient un collègue fiable. Ratez-les, et le modèle de pointe le plus performant devient une responsabilité coûteuse et amnésique.
Sources
- Claude models: Fable vs. Opus vs. Sonnet vs. Haiku — Zapier Blog
- Meta Muse AI agent: How to use the personal AI agent — Zapier Blog
- HubSpot AI tools: A complete guide to Agent Hub and Breeze — Zapier Blog
- NVIDIA livre OpenShell pour borner les agents, Sentry reste sans date — Actu IA
- Dots : un bon coup produit, pas une rupture technique — Actu IA
- Agents IA : le client répond de leurs actes, chez OpenAI comme ailleurs — Actu IA
