Mardi soir, tu lances un agent de six heures. Il est censé scraper la page tarifaire d'un concurrent, trier quarante tickets Linear oubliés, et faire un dry-run d'une migration Postgres pendant que tu dors. Le dashboard dit « autonomous ». Le marketing dit « long-horizon ». Ta carte bancaire dit « ouais, vas-y ». Tu fermes le laptop.

Tu te réveilles avec une tâche à moitié finie, trois tickets Linear en doublon enregistrés sous ton nom, et un canal Slack rempli de questions d'un collègue qui pensait que toi, tu étais réveillé à 3h du matin. L'agent a planté à la quatrième heure. Personne — ni toi, ni le vendeur — ne peut te dire si cliquer sur « resume » va doubler les dégâts ou les réparer.

Bienvenue en avril 2026, le mois où les agents multi-heures sont devenus une métrique de pricing avant de devenir une garantie de fiabilité 😹.

Huit jours, trois modèles de persistance, zéro standard

Entre le 8 et le 15 avril, les deux plus gros vendeurs d'agents ont expédié trois manières différentes de garder un agent IA en vie au-delà d'une heure — et aucune ne s'accorde sur ce que « en vie » signifie.

Le 14 avril, Anthropic a lancé Claude Code Routines — des runs d'agents planifiés ou déclenchés par webhook, en research preview, plafonnés par jour (5/jour sur Pro, 15/jour sur Max, 25/jour sur Team et Enterprise). Intervalle minimum : une heure. The Register a poliment qualifié ça de « cron jobs vaguement astucieux » 😼.

Le 15 avril, OpenAI a sorti Agents SDK v0.14.0 avec une nouvelle surface SandboxAgent, un backend de sandbox pluggable (Docker, E2B, Modal, Vercel, Cloudflare — choisis ton camp), et un truc appelé MEMORY.md — un fichier markdown littéral que l'agent s'écrit à lui-même entre deux runs.

Et le 8 avril, Anthropic avait déjà lancé Managed Agents, qui facture l'usage en session-hours — une unité de facturation qui suppose explicitement que ton agent va tourner pendant des heures.

Trois modèles de persistance. Zéro interop. Bienvenue dans l'autonomie long-horizon.

Ce que chaque vendeur sauvegarde réellement

Petit détour — parce que « l'agent se souvient » a l'air simple, et ça ne l'est pas.

Un agent, c'est une boucle : le LLM (large language model — le cerveau derrière ChatGPT ou Claude) lit une tâche, appelle un outil (recherche web, commande shell, appel API), lit le résultat, décide quoi faire ensuite. Un agent long-horizon, c'est cette boucle qui tourne pendant des heures. Un checkpoint, c'est un instantané sauvegardé de l'état de la boucle, pour que si le process plante, tu puisses reprendre depuis l'instantané au lieu de tout recommencer à zéro.

Voici ce que chaque vendeur sauvegarde réellement :

  • Anthropic Routines — sauvegarde la conversation et le plan dans une session. D'après la doc, « chaque event GitHub correspondant démarre une nouvelle session » — les sessions ne partagent même pas leur état entre triggers. Et : « les events au-delà de la limite sont droppés jusqu'à ce que la fenêtre se réinitialise » — autrement dit, un pic de webhooks perd silencieusement du travail, pas de queue, pas de retry 🙀.
  • OpenAI Sandbox Agents — sauvegarde un fichier MEMORY.md dans le filesystem du sandbox. La propre doc d'OpenAI dit qu'il « distille les leçons en fichiers lisibles plutôt que de préserver l'état complet du workspace ». En clair : il se souvient de ce qu'il a appris, pas de ce qu'il a fait. Tué en plein git push ? Le plan survit. Le commit à moitié pushé, non.
  • Anthropic Managed Agents — facture à la session-hour. Ce qu'une session-hour checkpoint, c'est non documenté.

Aucun d'eux — aucun — ne documente ce qui arrive aux side-effects quand un run plante. Un side-effect, c'est tout ce que l'agent a touché en dehors de sa propre mémoire : un appel API parti, un ticket Linear créé, une ligne insérée dans ta base, un message Slack envoyé, un commit git pushé. Ça, ça ne se rembobine pas.

Le « aha » que personne n'a mis sur la landing page

La partie qu'on dit tout bas, à voix haute : quand un agent multi-heures plante et reprend, le checkpoint restaure l'intention de l'agent, pas l'état du monde sur lequel l'agent agissait.

Ton agent a créé un ticket Linear à la troisième heure. Il a planté à la quatrième. Le checkpoint à 3h30 ne sait pas que le ticket existe. Reprise : il recrée le ticket. Félicitations, tu as des doublons — et d'après la doc d'Anthropic, « les tickets Linear… utilisent tes comptes liés », donc les doublons sont sous ton nom. Tes collègues pensent que toi, tu les spammes 😾.

Ce n'est pas un bug. C'est l'architecture. L'analyse de The New Stack sur les release notes d'OpenAI souligne que le harness « peut garder l'auth, le billing, les audit logs, la revue humaine et l'état de récupération en dehors d'un seul container » — ce qui est vrai, et c'est aussi une manière polie de dire que le SDK a des opinions sur son propre état et aucune sur le tien.

Vertex Agent Engine de Google, pour mémoire, a vu Sessions et Memory Bank passer en GA dès décembre 2025 ; avril 2026 n'a ajouté qu'une preview d'Agent Designer. Donc personne — ni Anthropic, ni OpenAI, ni Google — ne résout l'idempotence des side-effects à ta place.

Le prix que personne n'a mis sur la page de tarifs

L'idempotence — la propriété qu'une opération faite deux fois a le même effet qu'une seule fois — est désormais entièrement ton problème. Chaque appel d'outil que ton agent fait vers l'extérieur a besoin d'une clé d'idempotence (un ID unique par opération, pour que le service receveur déduplique les retries). Chaque action externe a besoin d'un outbox journalisé (un log que tu écris avant l'action, pour savoir ce que tu as tenté même si tu plantes avant de confirmer le succès).

Les re-runs coûtent le double : double tokens (les morceaux de mots que le LLM traite, facturés au million), double session-hours, double temps réel d'attente. Et comme aucun vendeur ne propose un format de checkpoint portable, tu ne peux pas basculer d'Anthropic vers OpenAI au milieu d'une tâche. Tu es lock-in par la forme de tes bug reports.

Le thread Hacker News sur Routines l'a dit clairement : « Je ne vais pas bâtir mon business sur des trucs que je ne peux pas répliquer moi-même. » Un autre commentateur a noté que debugger une routine multi-heures serait « insupportable ». Correct sur les deux points 🐈‍⬛.

Si tu mets ça en prod

Si tu fais tourner des agents au-delà d'une heure en avril 2026, le checkpoint de la plateforme n'est pas ta stratégie de récupération. C'est un reçu. Tu as besoin de trois choses que les vendeurs n'ont pas construites pour toi :

  1. Un outbox journalisé — chaque side-effect externe écrit dans un log avant exécution, pour que le replay sache ce que l'agent a tenté.
  2. Des clés d'idempotence sur chaque appel d'outil — GitHub, Linear, Slack, tes propres APIs. Aucune exception.
  3. Une UI de reprise manuelle — pour qu'un humain décide de retry, skip ou abort après un crash. Pas l'agent. Pas le vendeur.

Ce qui a vraiment changé ce mois-ci

« Les agents tournent pendant des heures » est devenu une unité de pricing en avril 2026. La plomberie en dessous est encore à l'échelle du quart d'heure. Quelque part dans le prochain trimestre, une entreprise écrira le premier post-mortem public sur un managed agent que personne n'a pu rembobiner — et la question intéressante ne sera pas quel vendeur a échoué, mais pourquoi quelqu'un a cru que le checkpoint était la garantie 😸.

Le conseil du chat : fais tourner ton propre outbox. Ne fais confiance au bouton « resume » d'aucun vendeur. Et si un sales deck dit « autonomous », demande-leur de définir le mot par écrit.