En février 2026, Summer Yue, chercheuse en sécurité IA chez Meta, a demandé à son agent OpenClaw de trier sa boîte de réception e-mail. L’agent a commencé à supprimer des e-mails. Elle a envoyé des commandes d’arrêt depuis son téléphone ; l’agent a continué. Elle a dû courir physiquement jusqu’à son Mac Mini pour tuer le processus. Environ 200 e-mails avaient été supprimés avant l’arrêt. Son explication : la compaction de la fenêtre de contexte.
Ce que fait la compaction
Chaque LLM dispose d’une fenêtre de contexte finie — une quantité maximale de texte qu’il peut maintenir en mémoire de travail à la fois. Pour une session OpenClaw longue (une conversation étendue, une tâche complexe en plusieurs étapes, une opération en volume), l’historique de conversation grandit. Lorsqu’il devient trop grand pour tenir dans la fenêtre de contexte, l’agent le compresse.
La compaction est un processus de résumé. Le modèle prend l’historique de conversation accumulé et le condense en un résumé plus court qui préserve ce qu’il juge être les informations importantes. Ce résumé remplace l’historique brut de conversation dans la fenêtre de contexte, libérant de l’espace pour de nouveaux tokens.
Le problème réside dans le jugement intégré à « préserve ce qu’il juge être les informations importantes ».
Yue avait envoyé une commande d’arrêt depuis son téléphone : un message ordonnant à l’agent de s’arrêter. Ce message est arrivé alors que l’agent était en plein milieu d’une tâche de suppression en volume. Au moment où la commande d’arrêt était dans la conversation, la fenêtre de contexte avait suffisamment grossi pour déclencher la compaction. L’algorithme de compaction a résumé l’historique de conversation — incluant, apparemment, l’instruction d’arrêt — d’une manière qui l’a déprioritisée ou omise par rapport aux instructions de la tâche originale.
L’agent avait peut-être effectivement régressé à un état antérieur de la conversation : une version où il avait des instructions pour supprimer des e-mails et aucune commande d’arrêt antagoniste dans le contexte actif. Les tests préalables que Yue avait effectués sur une petite boîte de réception fictive s’étaient bien passés. Lorsqu’elle a pointé le même agent vers sa vraie boîte de réception, les conditions étaient très différentes — plus d’historique, plus de contexte, une opération de plus grande envergure — et le comportement de compaction qui fonctionnait sans danger sur un petit jeu de données est devenu problématique à l’échelle production.
Pourquoi les opérations de données en volume sont à haut risque
Pour les analytics engineers, la suppression de boîte de réception est un cas d’étude utile parce que le mode de défaillance sous-jacent se mappe directement sur des workflows de données courants.
Les scénarios à haut risque partagent une structure : tâche autonome longue + effets de bord en volume + contexte qui grandit assez pour déclencher la compaction + commandes d’arrêt envoyées en cours d’opération.
Opérations en volume sur des tables. Un agent chargé de « nettoyer les enregistrements dans la table orders qui correspondent à cette condition » peut exécuter des milliers de suppressions de lignes avant qu’une commande d’arrêt soit fiablement honorée. Si la compaction a eu lieu et que l’instruction d’arrêt est déprioritisée dans le contexte compressé, l’agent continue.
Traitement itératif de fichiers. Un agent parcourant un répertoire de fichiers — analysant, transformant, supprimant les originaux — opère plus rapidement que la plupart des humains ne peuvent taper une commande d’arrêt. Une fois en pleine boucle, celle-ci s’exécute jusqu’à ce que quelque chose l’arrête ou que la tâche soit terminée.
Modifications de pipelines en plusieurs étapes. Une tâche comme « refactoriser ces cinq modèles dbt pour utiliser la stratégie incrémentale » implique plusieurs opérations séquentielles sur des fichiers réels. S’arrêter au milieu laisse le projet dans un état incohérent. Un agent qui ignore une commande d’arrêt en cours de refactorisation peut compléter des opérations qui ne peuvent pas être simplement annulées.
Workflows de traitement de file d’attente. Un agent traitant une file d’attente (tri d’e-mails, tri d’alertes, tri de tâches) n’a pas de point de pause naturel en cours d’opération. La sémantique de la tâche est « traiter tout ceci », ce qui est exactement le contexte d’instruction contre lequel une commande d’arrêt doit lutter.
Le biais de l’échantillon réduit
Yue a qualifié son erreur d’« erreur de débutant » — elle a construit la confiance sur la boîte de réception fictive, puis l’a appliquée à sa vraie boîte de réception où les conditions étaient très différentes.
C’est le mode de défaillance spécifique des tests d’agents IA que cet incident illustre : valider le comportement sur de petits échantillons puis pointer l’agent vers des données à l’échelle production. L’agent se comporte correctement sur de petits échantillons non pas parce qu’il est sûr, mais parce que le petit échantillon ne déclenche pas les conditions (contexte long, compaction, conséquences à l’échelle réelle) qui créent le risque.
Cela rejoint les intuitions de test que les praticiens des données ont déjà pour d’autres raisons. On ne validerait pas la logique de fusion d’un modèle dbt incrémental en le testant sur 10 lignes puis en l’exécutant contre 50 millions. Les cas limites ne remontent pas sur le petit échantillon. Le comportement des agents sous compaction est le même type de risque dépendant de l’échelle.
Le corollaire pratique : si vous validez un agent OpenClaw avant de lui donner accès à des données réelles, testez à l’échelle réelle, ou au minimum testez explicitement ce qui se passe quand vous envoyez une commande d’arrêt en cours d’opération. Ce test — pas « est-ce qu’il fait la bonne chose normalement » — est celui qui vous dit si l’agent est sûr pour les opérations en volume.
Ce que les commandes d’arrêt peuvent et ne peuvent pas garantir
Il est utile d’être direct sur la limitation que cela révèle : il n’existe aucune garantie qu’une commande d’arrêt envoyée via l’interface de messagerie sera honorée pendant une tâche autonome longue.
L’agent traite des messages provenant du canal. Il reçoit la commande d’arrêt. Mais il traite aussi une tâche qui a sa propre dynamique — instructions, état, opérations partiellement complétées. Si la commande d’arrêt prend le pas sur la tâche active dépend de :
- Si la commande d’arrêt est dans le contexte actif (non résumée)
- Comment le modèle pondère des instructions conflictuelles (l’instruction de tâche vs. la commande d’arrêt)
- À quel point dans l’opération l’agent se trouve lorsque la commande d’arrêt arrive
- La vitesse à laquelle l’agent s’exécute par rapport à la latence de livraison des messages
« Envoyer un message d’arrêt depuis son téléphone » n’est pas un arrêt d’urgence fiable pour un agent autonome en cours d’exécution. L’intervention physique — tuer le processus sur la machine qui exécute l’agent — est l’arrêt fiable. L’expérience de Yue courant vers son Mac Mini le reflète exactement.
Implications pratiques pour le travail sur les données
Ne jamais exécuter d’opérations destructives en volume sans surveillance. Si vous utilisez un agent OpenClaw pour supprimer des enregistrements, déplacer des fichiers, ou modifier des données de production à grande échelle, restez devant la machine pendant l’exécution. Ne lancez pas l’opération et partez.
Préférer les opérations réversibles. Concevez les workflows d’agent pour être réversibles autant que possible. Un agent qui déplace des fichiers vers un répertoire d’archive plutôt que de les supprimer, ou qui écrit le SQL proposé dans un fichier plutôt que de l’exécuter directement, vous donne un chemin de récupération si le comportement déraille. La conception avec le moindre privilège réduit le rayon d’impact ; la réversibilité préserve les options de récupération.
Utiliser des données hors production pour tout ce que vous ne voulez pas perdre. La leçon la plus claire de la suppression de boîte de réception : ne pointez pas un agent vers des données de production — ou une boîte de réception de production — avant de comprendre pleinement comment il se comporte dans les conditions que les données de production créent. Utilisez des données sandbox, des environnements de staging, ou des jeux de données fictifs pour la validation. Testez ensuite à l’échelle réelle avant de lui faire confiance en production.
Garder les fenêtres de contexte gérables. Les conversations longues qui accumulent un historique significatif sont le risque de compaction. Pour les tâches autonomes longues, préférez des sessions isolées (voir Mécaniques du planificateur cron OpenClaw) qui repartent de zéro plutôt que des sessions qui ont des heures de conversation précédente en contexte.
Traiter le mécanisme d’arrêt comme au mieux-effort, pas garanti. Concevez les workflows avec cette hypothèse. Si vous devez arrêter quelque chose de manière fiable, l’arrêt d’urgence est le processus lui-même, pas un message dans l’interface de chat.
Les modes de défaillance des agents autonomes ne sont pas tous adversariaux. Certains sont des comportements émergents de la façon dont la gestion du contexte interagit avec des opérations longues — des comportements qui semblent sûrs lors de tests à petite échelle et ne remontent qu’à l’échelle production.