Agents IA durables : une checklist de sélection du runtime pour les workflows de production en 2026

Pourquoi les agents IA durables sont une décision de runtime, pas seulement une décision de modèle

Les agents IA durables ne sont pas des prompts plus solides avec quelques outils attachés. Ce sont des workflows de production capables de survivre aux délais, aux échecs partiels, aux événements dupliqués, aux revues humaines, aux changements de fournisseur et aux redémarrages de workers. Cette distinction compte, car la plupart des démonstrations d'agents masquent la partie la plus difficile. Le modèle répond, un outil s'exécute, et la page paraît convaincante. La production pose une question moins flatteuse : que se passe-t-il quand l'approbation revient demain, quand le worker meurt à mi-parcours, ou quand le même webhook arrive deux fois ?

Mon avis : beaucoup d'équipes choisissent l'infrastructure d'agents trop tard. Elles choisissent un modèle, construisent une boucle de chat, branchent quelques outils internes, puis découvrent que le vrai produit est un moteur de workflow portant une interface IA. À ce stade, l'état est déjà dispersé entre prompts, journaux, mémoire temporaire et effets de bord. Le runtime a déjà été choisi par accident.

Pour la planification 2026, la question la plus sûre n'est pas quel modèle doit exécuter l'agent. C'est quel runtime doit posséder l'état, les nouvelles tentatives, les permissions, les approbations et la reprise. La documentation Durable AI de Temporal part des concepts d'orchestration de workflows. Cloudflare Agents et Durable Objects sont pertinents pour les agents avec état et la coordination dans les applications hébergées sur Cloudflare. Les agents Convex conviennent aux équipes qui construisent déjà des backends d'applications réactifs. Val Town convient à l'automatisation programmable légère. Une pile personnalisée peut fonctionner lorsque le contrôle compte plus que la vitesse, mais cela signifie aussi que l'équipe assume les parties gênantes.

La matrice d'adéquation des agents durables

Un processus de sélection pratique a besoin de moins d'adjectifs de fournisseurs et de plus de tests d'échec. La matrice d'adéquation des agents durables compare les runtimes selon cinq axes.

Temporal est un bon candidat lorsque le workflow est long, avec état, et plein de cas limites de processus métier. Sa documentation IA mérite d'être lue si l'équipe pense déjà en termes de workflows, activités, signaux et nouvelles tentatives : https://docs.temporal.io/ai. Le compromis est que les équipes doivent apprendre le modèle de workflow et traiter le comportement de l'agent comme une partie d'un système distribué plus large.

Cloudflare Agents, associé à Durable Objects, convient aux équipes qui veulent des agents avec état dans des applications web hébergées sur Cloudflare. Les docs pertinentes sont https://developers.cloudflare.com/agents/ et https://developers.cloudflare.com/durable-objects/. Cette voie peut être attractive pour les sessions d'agents orientées utilisateur, la coordination et l'état à faible latence dans la plateforme Cloudflare. La réserve concerne l'adéquation à la plateforme. Si le reste du système vit loin de Cloudflare, les choix d'intégration comptent.

Les agents Convex conviennent aux équipes produit qui utilisent déjà Convex ou veulent garder l'état de l'agent proche des données applicatives réactives : https://docs.convex.dev/agents/overview. L'avantage est de réduire la colle entre l'état applicatif et l'état de l'agent. Le risque est le même qu'avec tout runtime natif à l'application : il peut être parfait pour les workflows produit et moins naturel pour l'orchestration entre systèmes.

Val Town doit être traité comme une couche d'automatisation rapide, pas comme une plateforme d'agents universelle : https://docs.val.town/. Il est utile pour de petits outils internes, des scripts, des tâches planifiées, des prototypes et du code de liaison. Il est moins approprié lorsque le workflow nécessite une auditabilité stricte, des approbations en plusieurs étapes, des permissions complexes ou une réponse aux incidents approfondie.

Un runtime personnalisé, construit à partir de files, bases de données, workers, planificateurs et passerelles de modèles, peut être la bonne réponse pour des environnements réglementés ou des contraintes d'architecture inhabituelles. Il donne le contrôle sur le stockage, le réseau, le routage des modèles et les politiques. Il signifie aussi que l'équipe doit concevoir directement l'idempotence, les nouvelles tentatives, l'observabilité, le rejeu, les évaluations, les flux d'approbation et les contrôles de coûts. Ce n'est pas un projet de week-end.

Un playbook d'évaluation pratique

N'évaluez pas les runtimes d'agents durables avec une démonstration du chemin heureux. Choisissez un workflow réel et faites-le mal se comporter volontairement. Par exemple, utilisez un workflow de triage support qui lit un ticket, vérifie le contexte du compte, rédige une réponse, attend une approbation, met à jour un CRM et envoie un message. Testez ensuite les parties qui cassent habituellement.

Tuez le worker après l'appel au modèle mais avant l'action d'écriture. Livrez deux fois le même webhook. Changez le schéma de réponse d'un outil. Retardez l'approbation humaine de 24 heures. Retournez un timeout partiel depuis le CRM. Faites tourner une clé de fournisseur de modèle. Demandez à l'agent de reprendre depuis le milieu. Si le runtime ne peut pas rendre ces cas routiniers, il n'est pas prêt pour ce workflow.

Une petite preuve de durabilité doit répondre à ces questions :

1. Où l'état du workflow est-il stocké, et qui le possède ?
2. Le workflow peut-il reprendre après un redémarrage de processus sans refaire des actions dangereuses ?
3. Les appels d'outils sont-ils idempotents, ou protégés par des clés d'idempotence ?
4. Un humain peut-il approuver, rejeter ou modifier une action proposée sans casser l'exécution ?
5. Un opérateur peut-il inspecter l'historique et expliquer pourquoi l'agent a agi ?
6. Les prompts, schémas d'outils, versions de modèles et sorties sont-ils assez bien enregistrés pour l'évaluation ?
7. Que se passe-t-il quand le modèle donne une mauvaise réponse mais que le runtime se comporte correctement ?

Cette dernière question est facile à oublier. C'est aussi là que beaucoup de programmes d'agents deviennent coûteux. Un runtime durable peut rendre l'échec récupérable, mais il ne peut pas rendre bonne une conception de tâche faible. Les équipes ont encore besoin de jeux d'évaluation, de contrôles de politiques et de chemins d'escalade clairs.

La sécurité et la gouvernance changent la décision de runtime

La sécurité des agents n'est pas seulement une question de prompt. C'est une question d'architecture de runtime. Le cadrage de la triade létale de Simon Willison est une grille utile, car il relie trois conditions : l'accès à des données privées, l'exposition à du contenu non fiable, et un moyen d'exfiltrer des informations : https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/. Quand les trois apparaissent dans le même flux d'agent, le risque d'injection de prompt devient plus concret.

La sélection du runtime doit donc séparer les chemins de lecture, les chemins d'écriture et les chemins de communication sortante. Un agent de recherche qui lit des documents internes ne doit pas automatiquement avoir la permission d'envoyer des e-mails à des destinataires arbitraires. Un agent d'achats capable de rédiger un bon de commande ne doit pas pouvoir l'approuver sans contrôles de politique. Un agent développeur qui lit du code source doit avoir des règles étroites pour publier des données hors de l'espace de travail.

L'approbation humaine reste utile, mais seulement si elle est spécifique. Approuver cette exécution est vague. Approuver l'envoi de cet e-mail exact à ces destinataires avec ces pièces jointes est préférable. Le runtime doit préserver l'action proposée, le réviseur, la décision et l'appel d'outil final. Sinon, l'approbation n'est qu'une gouvernance faible avec un horodatage.

Ce que les équipes comprennent mal

La première erreur consiste à traiter les nouvelles tentatives comme de l'intelligence. Réessayer un mauvais appel d'outil peut corriger un échec transitoire. Réessayer un mauvais plan peut faire répéter les dégâts plus vite. Les runtimes durables ont besoin de politiques de nouvelle tentative, mais aussi de conditions d'arrêt, d'escalade humaine et d'enregistrements qui montrent ce qui a été réessayé et pourquoi.

La deuxième erreur consiste à confondre mémoire et source de vérité. La mémoire conversationnelle est un contexte utile. Elle ne doit pas être le seul endroit où vivent les approbations, l'état client, les actions financières ou les décisions de conformité. Les workflows durables ont besoin d'une vraie source de vérité, et le runtime doit rendre cette frontière claire.

La troisième erreur consiste à ignorer la protection contre les doublons. Les webhooks se répètent. Les utilisateurs double-cliquent. Les planificateurs se chevauchent. Les fournisseurs expirent après avoir terminé une requête. Tout workflow qui écrit dans des systèmes externes a besoin de clés d'idempotence, d'identifiants externes ou d'un autre modèle de contrôle des doublons.

La quatrième erreur consiste à construire une plateforme avant de prouver un workflow. Le travail de plateforme paraît productif parce qu'il crée des abstractions. Le meilleur premier geste est un workflow étroit avec des bords douloureux. Si le runtime le gère bien, les abstractions seront fondées sur des preuves plutôt que sur le goût.

La cinquième erreur consiste à ignorer les coûts et la latence jusqu'au lancement. Les agents durables peuvent appeler plusieurs modèles, outils, bases de données et contrôles de politiques. Certains workflows en ont besoin. D'autres ont besoin d'un chemin plus simple, comme de la recherche plus une recommandation rédigée. Mesurez l'exécution complète, pas seulement la latence du modèle.

Chemins recommandés

Pour les équipes produit qui ajoutent des agents à une application existante, commencez par le runtime le plus proche de l'état applicatif. Convex peut convenir si le produit utilise déjà Convex. Cloudflare peut convenir aux sessions avec état orientées utilisateur dans des applications hébergées sur Cloudflare. Le facteur décisif est généralement la propriété opérationnelle : les personnes qui livrent la fonctionnalité doivent aussi pouvoir inspecter et déboguer l'agent.

Pour les équipes plateforme qui orchestrent de longs processus métier, Temporal mérite une évaluation sérieuse. Il fait de la durée, des nouvelles tentatives, des signaux et de l'historique de workflow des préoccupations de premier ordre. C'est utile quand les agents deviennent partie prenante de processus d'onboarding, de finance, d'opérations, d'achats ou de support.

Pour les équipes développeur qui construisent des automatisations internes, Val Town peut être un bon point de départ lorsque la tâche est petite et réversible. Gardez le périmètre honnête. Si l'automatisation commence à toucher des données sensibles, des approbations ou des écritures irréversibles, déplacez le workflow dans un runtime avec des contrôles plus solides.

Pour les équipes avec une conformité stricte, un réseau inhabituel ou des besoins de routage de modèles personnalisés, une pile personnalisée peut être justifiée. L'équipe doit budgéter plus que des workers et des files. Elle aura besoin d'application des politiques, de pistes d'audit, de stockage d'évaluations, d'outillage de rejeu, de procédures d'incident et de maintenance continue.

La checklist de planification

Avant le début du travail de production, écrivez les réponses en langage simple :

Le meilleur runtime n'est pas celui qui porte le plus de branding agent. C'est celui qui rend l'échec compréhensible, limite les actions dangereuses et donne aux opérateurs un chemin propre vers un état connu. Choisissez-le avec un workflow réel, pas avec une présentation.