Vous lancez un refactoring à 16 h et vous fermez votre ordinateur portable à 18 h. Le lendemain matin, l’exécution est terminée, toujours en cours, ou alors elle s’est arrêtée à 21 h 40 pour poser une question à laquelle personne n’était là pour répondre. Trois situations très différentes qui, vues de l’extérieur, sont restées identiques toute la nuit.
Anthropic affirme que Claude Opus 5.5 peut rester concentré sur sa tâche pendant 18 heures ou plus. Prenez cela au pied de la lettre. Une exécution lancée à la fin d’une journée de travail n’est pas terminée au début de la suivante. Le modèle a pris des décisions pendant onze heures sans vous, et le seul rempart contre une mauvaise décision réside dans les consignes que vous lui avez laissées avant de partir.
Une exécution qui s’inscrit dans votre journée de travail se supervise. Une exécution qui la dépasse impose d’y revenir plus tard. Il s’agit de deux logiques fondamentalement différentes, et la plupart des équipes fonctionnent encore selon la première.
En résumé
Une exécution d’agent de longue durée se poursuit au-delà de la présence d’un opérateur humain ; ainsi, chaque décision qu’il ne peut pas prendre seul doit être consignée sous forme d’état enregistré, plutôt que de rester bloquée sur une invite de commande dans un terminal que personne ne lit. Trois conditions doivent être impérativement réunies pour sécuriser ce fonctionnement : une condition d’arrêt que l’agent applique de manière autonome, un état « en attente d’une intervention humaine » clairement distinct des états d’exécution et d’échec, et une boîte de réception qu’une personne nommément désignée consulte chaque matin. Les agents recherchent, exécutent, testent et rendent compte. Les humains fixent le cap, accordent les autorisations et valident le résultat. Sharkly centralise ces trois rôles au niveau de la Tâche.
Ce qui a changé le 22/09/2026
Deux laboratoires d’IA ont publié des mises à jour majeures le même jour, bouleversant à la fois la durée et le coût d’une exécution.
| Claude Opus 5.5 | GPT-6 Sol | GPT-6 Luna | |
|---|---|---|---|
| API id | claude-opus-5-5 |
gpt-6-sol |
gpt-6-luna |
| Entrée / sortie par million de tokens | 4 $ / 20 $ | 2 $ / 10 $ | 0,10 $ / 0,50 $ |
| Entrée en cache | 0,20 $ en lecture, 5 $ en écriture | -90 % sur les lectures | -90 % sur les lectures |
| Contexte | 1M | 872k | 1M |
Selon Anthropic, Opus 5.5 coûte 40 % moins cher à l’usage qu’Opus 5, génère des réponses environ 30 % plus vite, offre une longueur maximale de sortie de 128k tokens et reste concentré sur sa tâche pendant 18 heures ou plus. De son côté, OpenAI affirme que Sol et Luna sont chacun 50 % moins chers que le tarif promotionnel de GPT-5.6 ; le terme « promotionnel » venant d’OpenAI elle-même, la comparaison s’établit donc par rapport à un tarif réduit, et non au prix catalogue. OpenAI annonce également une remise de 90 % sur la lecture des tokens d’entrée en cache pour GPT-6 et précise que la modification de l’effort de raisonnement ou de la disponibilité des outils n’invalide plus le cache — un point déterminant pour les exécutions qui durent toute la nuit.
Une exécution peut désormais être à la fois longue et peu coûteuse. En revanche, la journée de travail ne s’est pas allongée pour autant, pas plus que la capacité humaine à assimiler les résultats.
L’inversion de la revue
Lorsque vous suivez une exécution en direct, vous faites office de gestionnaire d’erreurs. Vous voyez l’agent ouvrir le mauvais fichier et vous l’interrompez aussitôt. Cette correction n’apparaît dans aucun journal d’événements, tout simplement parce que cela n’a jamais été nécessaire.
La nuit, cette surveillance disparaît. Chaque correction que vous auriez apportée doit être anticipée : soit sous la forme d’une règle déjà fournie à l’agent, soit par un point d’arrêt. Il n’y a pas de troisième voie. Un agent qui tourne sur de longues durées n’est pas simplement un agent autonome qui va jusqu’au bout de son travail. C’est un agent qui se heurtera, pendant votre sommeil, à une décision qui vous revient. Concevez votre système pour l’arrêt, pas uniquement pour la complétion.
Anthropic signale également une baisse de 85 % des tentatives réussies de contournement des consignes sur Opus 5.5. Une probabilité réduite ne constitue toutefois pas une condition d’arrêt. Même s’il est plus difficile de détourner un modèle de ses instructions, il a toujours besoin d’un mécanisme où consigner ses questions à 2 h du matin.
Trois conditions indispensables
1. Une condition d’arrêt que l’agent peut appliquer sans vous
Elle repose sur deux piliers : un plafond strict imposé par la plateforme et des règles écrites que l’agent applique de lui-même.
Le plafond relève de la configuration. Un Agent Sharkly dispose d’un nombre maximal de Tâches en cours d’exécution en parallèle et d’un délai d’expiration (timeout) par Tâche, configurés au niveau de l’Agent plutôt qu’à chaque exécution. Définissez ce délai au-dessus de la durée maximale souhaitée, mais en dessous de celle que vous êtes prêt à financer. Il s’agit d’un disjoncteur, pas d’un planning.
Les conditions écrites représentent la partie que les équipes ont tendance à négliger. Un agent qui ne s’arrête jamais n’est pas consciencieux : il est hors de contrôle.
Stop and wait for a human when:
- a change would touch a file outside the paths named in the Task;
- a check that passed at the start of the run still fails after two attempts;
- the Task description and the code disagree about intended behavior;
- you are about to run a command that writes outside the working directory.
When you stop, leave one comment: what you did, what you need, and the single
question that unblocks you. One question per stop.
Optez pour un délai d’expiration long lorsque la Tâche consiste en une modification bien délimitée, accompagnée de tests capables d’indiquer à l’agent s’il a terminé. Limitez-le à une heure ou deux si la Tâche est exploratoire, si les critères d’acceptation restent sujets à débat ou si l’exécution est susceptible de toucher à des éléments que vous refusez de voir modifiés sans relecture. Les portes d’approbation (approval gates) précisent les cas où un agent doit s’interrompre, même lorsqu’il est sûr de lui.
2. Un état d’attente distinct de l’état d’exécution
Dans Sharkly, le statut du cycle de vie de la Tâche et l’état de fonctionnement de l’Agent constituent deux enregistrements distincts. Une Tâche peut afficher le statut In Progress tandis que l’Agent est dans l’état Working, Waiting for human reply, Waiting for human review ou Error. L’exécution sous-jacente possède elle aussi ses propres états : Queued, Dispatched, Waiting for local directory, Running, Completed, Failed, Canceled.
Cela peut ressembler à des détails administratifs, jusqu’au jour où vous avez huit exécutions lancées pendant la nuit. Sans cette distinction, votre tableau de bord affichera à 9 h le statut In Progress aussi bien pour un agent en pleine modification de code que pour un agent bloqué depuis onze heures dans l’attente d’une réponse. Vous vous retrouvez alors obligé d’ouvrir les huit pour savoir où en est chacun.
| Ce que vous voyez | Ce que cela signifie | Ce que cela vous coûte d’ignorer |
|---|---|---|
| Working | Le Runtime travaille activement sur la Tâche | Rien pour le moment |
| Waiting for human reply | L’agent s’est arrêté et a posé une question | Chaque minute perdue est de la capacité inactive |
| Waiting for human review | Le travail est terminé et en attente de validation | La modification n’est pas déployée |
| Error / Failed | L’exécution s’est mal terminée | Une nouvelle tentative non lancée |
Le journal d’exécution rend l’interruption parfaitement compréhensible le lendemain matin : la raison de la mise en file d’attente, l’heure de début et de fin, les appels d’outils et les événements du Runtime, la source de déclenchement, ainsi que le détail des échecs ou des annulations. C’est ce que vous consultez à froid, sans avoir en tête tout le contexte de votre requête initiale. Consultez notre article sur le statut, les journaux et les signaux d’échec pour savoir quelles informations collecter si vous développez votre propre système.
3. Une boîte de réception consultée par une personne désignée
Un état d’attente sans responsable désigné attend indéfiniment. Les exécutions nocturnes échouent en silence, contrairement à celles de jour, car personne n’est là pour remarquer l’interruption.
La boîte de réception de Sharkly est une file d’attente personnelle de l’activité des tâches, et l’onglet Principal rassemble les alertes qui requièrent une intervention humaine : attente de votre réponse, attente de votre validation, tâches bloquées ou en échec, mentions directes et assignations. Les échecs d’exécution et les blocages sont directement transmis au responsable désigné plutôt qu’à tous les abonnés ; ainsi, une exécution qui échoue à 3 h du matin est prise en charge par quelqu’un, au lieu d’être envoyée à tout le monde — ce qui revient à ne l’envoyer à personne.
Deux Vues enregistrées structurent la matinée : les tâches en attente de revue et les tâches assignées à des Agents actuellement bloqués. Désignez explicitement la personne chargée de les ouvrir. « L’équipe » n’ouvre jamais une boîte de réception.
La revue matinale
L’ordre dans lequel vous traitez les éléments compte, et ce n’est pas celui proposé par le tableau de bord.
- D’abord, les demandes en attente d’une réponse humaine. Répondre relance un agent arrêté ; passer en revue ne déclenche rien. Si SH-312 attend depuis 21 h 40, l’action la plus rapide et efficace de toute votre journée consiste à lui répondre via un commentaire, ce qui replace immédiatement une exécution de suivi dans la file pour cette Tâche.
- Ensuite, les exécutions en échec et bloquées. Consultez l’intitulé du journal d’exécution et les détails techniques avant de relancer. Un simple code de statut HTTP est un indice, pas un diagnostic.
- Puis, les tâches en attente de revue. C’est la véritable file d’attente, et c’est celle qui s’allonge à mesure que les exécutions deviennent moins chères.
- Enfin, ce qui tourne encore. Laissez l’exécution se poursuivre ou annulez-la. Une exécution annulée ne reprend pas là où elle s’est arrêtée, mais la Tâche et son historique sont conservés ; n’hésitez donc pas à annuler sans hésiter si la direction prise est mauvaise. Pensez toutefois à lire le journal au préalable.
Ce que cela ne résout pas
Des exécutions plus longues ne réduisent pas la charge de revue : elles la concentrent. Une exécution de 18 heures produit un résultat unique issu de toute une nuit de décisions, qu’un humain doit malgré tout lire, évaluer et valider. Les chercheurs d’OpenAI montrent bien où cela mène : un chercheur médian consomme plus de 600 $ par jour d’inférence aux tarifs de l’API, et le 90e percentile dépasse les 7 000 $ par jour, alors que le nombre de personnes disponibles pour analyser ces résultats n’a pas bougé. Nous avons fait le calcul lors de la publication d’OpenAI, et rien dans ces récentes annonces ne vient modifier le dénominateur.
Des exécutions plus longues et plus économiques permettent de multiplier les tentatives en parallèle, mais ne réduisent pas le nombre de décisions à prendre. La revue humaine reste le goulot d’étranglement, et une baisse des prix aggrave la situation avant de l’améliorer. L’automatisation s’arrête là où le discernement de l’équipe devient indispensable ; lorsqu’elle s’interrompt, elle doit livrer un résultat assorti d’un contexte complet et d’éléments vérifiables.
FAQ
Quelle doit être la durée du délai d’expiration par Tâche pour un modèle fonctionnant sur 18 heures ? Plus long que l’exécution souhaitée, mais plus court que celle que vous regretteriez de payer. Commencez par quelques heures pour les travaux classiques et augmentez ce seuil par Agent pour les Tâches qui nécessitent réellement toute une nuit. Le délai d’expiration sert à interrompre une boucle infinie ; il ne détermine pas le temps nécessaire à un travail de qualité.
Que devient une question posée par l’agent à 2 h du matin ? Elle doit se transformer en un état « en attente de réponse humaine » et générer une notification dans la boîte de réception de la personne assignée, et non rester une simple ligne perdue dans l’historique du terminal. Si votre configuration actuelle risque de la laisser passer inaperçue, comblez cette faille avant d’augmenter le moindre délai d’expiration.
Le bilan
Aucun fournisseur ne propose la brique essentielle dans ce domaine, car ce qui compte réellement, c’est l’endroit où l’arrêt se produit et la personne qui prend le relais au matin. Le problème se pose de manière identique sur Claude Code, Codex et toutes les autres plateformes ; c’est pourquoi la responsabilité doit se situer au niveau de la tâche plutôt qu’au sein de la session d’un fournisseur particulier.
Si vous faites déjà tourner des agents la nuit, le test est simple : ouvrez votre tableau de bord à 9 h et vérifiez s’il fait la différence entre un agent en cours de traitement et un agent bloqué depuis la veille. Si ce n’est pas le cas, c’est la toute première chose à corriger, et c’est précisément à ce niveau que Sharkly intervient : la Tâche conserve l’objectif, l’état de l’exécution, le point de blocage, le résultat et la décision humaine, de la demande initiale jusqu’au déploiement.
