L’IA agentique ne fait généralement pas de sauvegarde avant d’agir

Une grande partie des documents que je parcours chaque jour sur arXiv et dans d’autres sources est plutôt aride, même pour un esprit de geek. C’est pourquoi je suis toujours à la recherche d’une publication qui suscite chez moi une réaction émotionnelle, que je sois utilisateur, partisan ou victime de l’IA.

Aujourd’hui, cette montée d’adrénaline m’est venue d’une nouvelle collaboration universitaire américaine, qui examine dans quelle mesure les modèles d’IA agentique de pointe coupent les ponts avant de passer à l’action et de causer des dégâts — et plus vite que vous ne pouvez taper « ARRÊTEZ ! » (petit conseil : gardez le mot dans le presse-papiers).

Voici une situation tirée de son contexte dans le nouvel article, qui m’est arrivée récemment à cause de ma confiance aveugle dans les instructions de ChatGPT. Et comme il ne m’est pas venu à l’esprit de dupliquer d’abord tout l’environnement virtuel :

Interprétation du nouvel article : un moment glaçant que beaucoup d’entre nous ont vécu en installant des frameworks de pointe, voire des distributions populaires qui ne tiennent pas compte des environnements non standard dans lesquels elles risquent de se retrouver. Source

Dans cet exemple terrifiant et ô combien familier, le robot a une excuse valable : il n’est pas courant d’examiner toutes les conséquences possibles de l’installation d’une nouvelle bibliothèque dans un framework fragile et impitoyable. Le nouvel article avance toutefois que ce devrait peut-être être le cas. Et, moi qui appuie encore souvent sur CTRL+S, même dans des environnements de sauvegarde automatique configurés pour ignorer cette touche (merci au traumatisme des pertes de données des années 1990), je ne peux qu’être d’accord.

Alexey Grigorev, fondateur de la plateforme éducative DataTalks.Club, aurait certainement apprécié une attitude plus réfléchie et plus prudente : lors d’une migration de serveur en mars dernier, son agent Claude Code a supprimé l’infrastructure de production et les sauvegardes, entraînant la perte de deux ans et demi de données du site web.

Parmi les autres incidents récents de témérité agentique du même genre, citons un agent Cursor qui a supprimé la base de données de production et les sauvegardes de PocketOS, un fournisseur de logiciels de location de voitures, en avril, perturbant les réservations des clients pendant plus de deux jours ; ainsi qu’un agent de messagerie OpenClaw qui a supprimé des messages de la boîte de réception d’un chercheur en IA chez Meta en février, malgré plusieurs consignes lui demandant de s’arrêter.

Qu’ils soient agentiques ou non, les grands modèles de langage de pointe ont beaucoup de mal à agir avec circonspection et prudence, au point que la résolution de ce problème est devenue un axe de recherche à part entière dans la littérature scientifique.

Faire une pause pour sauvegarder

Les auteurs du nouvel article* ont donc développé un plug-in multi-agent pour les environnements d’exécution agentiques, capable de fonctionner aux côtés de l’IA invitée et de la contraindre à créer des sauvegardes lorsque c’est nécessaire :

Présentation du problème des sauvegardes étudié et de la solution proposée. Dans 205 scénarios, six modèles d’IA de pointe n’ont sauvegardé l’état critique que dans 15,2 % des tâches. En revanche, le système BackUpper des chercheurs a couvert chaque action critique ; les données restaurées présentaient en moyenne une similarité de 92,2 % avec les données originales (voir ci-dessous pourquoi atteindre 100 % est difficile).

L’un des aspects les plus frappants de cette nouvelle étude est la fréquence à laquelle les modèles de pointe omettent de faire une sauvegarde avant une action potentiellement dangereuse. Les chercheurs ont constaté que GPT-5.6-Terra sauvegardait les données critiques dans seulement 4,4 % des cas ; GPT-5.6-Sol, dans seulement 5,9 % des cas testés ; et Gemini 3.7-Flash, dans à peine 2,4 % des cas.

Même le modèle le plus performant, Claude Opus-5, n’a pas sauvegardé les données critiques dans plus d’un tiers des cas testés.

L’article affirme^† :

« Parmi six modèles de pointe, les agents accomplissent en moyenne 86,1 % des tâches, mais ne sauvegardent leur état avant les moments qu’ils pourraient regretter que dans 15,2 % des cas. GPT 5.6-Sol dans Codex ne le fait que dans 5,9 % des tâches, et DeepSeek V4-Pro dans Hermes, dans seulement 2,9 %.

« Ces résultats montrent que les agents actuels sont encore peu sensibilisés à la sauvegarde et qu’une prise en charge spécifique de cette fonction est nécessaire. »

La solution des auteurs, baptisée BackUpper, fonctionne aux côtés de l’agent, en arrière-plan dans son environnement d’exécution. Elle vérifie ce qu’il s’apprête à faire et crée d’abord une sauvegarde s’il risque de perdre quelque chose d’utile.

Pour les opérations courantes, comme les mises à niveau logicielles, elle applique un ensemble de règles simples ; dans les situations plus délicates, elle fait appel à un modèle d’IA plus petit pour déterminer ce qui doit être sauvegardé.

Lors des tests, BackUpper a couvert toutes les actions critiques, et les données restaurées présentaient une similarité de 92,2 % avec les données d’origine, pour un coût supplémentaire de 0,014 $ par tâche — une somme modeste dans ce contexte, mais une dépense importante pour les grands modèles de langage de pointe qui servent des milliards de clients ; c’est peut-être pourquoi un service externe de cette nature, ou l’intégration native de telles fonctionnalités aux environnements d’exécution, pourrait être une solution plus probable pour améliorer la situation, plutôt que d’espérer une correction native de la part des géants de la technologie (qui pourraient raisonnablement répercuter ces coûts supplémentaires sur leurs clients, sous la forme de hausses de prix ou d’une inflation du nombre de jetons).

Le cadre s’inspire de RegretBench, un banc d’essai de 205 tâches fondé sur des cas réels où des personnes ont perdu des données qu’elles auraient ensuite voulu sauvegarder. Il évalue si les agents d’IA ont la prévoyance nécessaire pour préserver ces données avant d’effectuer des modifications potentiellement irréversibles. Les incidents réunis dans cette collection proviennent de discussions et de signalements en ligne sur des plateformes comme X.com, GitHub et Stack Overflow.

Schéma illustrant comment RegretBench transforme des incidents réels en scénarios de test. Chaque cas documenté est reconstitué à partir de l’action qui a causé la perte, d’un environnement de travail réaliste et d’une série d’instructions. Dans cet exemple, la mise à niveau d’ipykernel remplace silencieusement une version existante de traitlets, ce qui permet à l’agent d’achever sa tâche, mais ne laisse aucun moyen de récupérer l’installation d’origine.

Même si un taux de 92 % peut sembler décourageant aux perfectionnistes, les auteurs soulignent que des obstacles techniques empêchent de récupérer certains types de données :

« L’écart par rapport à une restauration parfaite s’explique principalement par deux raisons. Certains champs, comme les identifiants de publication, sont généralement régénérés par les services lors de l’écriture et ne peuvent souvent pas être reproduits. D’autres différences tiennent à des métadonnées mineures, comme les indicateurs de lecture des courriels, qui sont rarement concernés par les situations de perte de données regrettée. »

Lors des tests, une similarité de 33,8 % avec l’état d’origine a été récupérée après que les dégâts se sont déjà produits, contre seulement 14,3 % en l’absence de restauration.

L’article suggère que, pour l’avenir, la sensibilisation aux sauvegardes pourrait être améliorée grâce à l’entraînement, tandis que de futures versions de BackUpper pourraient apprendre à ignorer les actions à faible risque et à étendre la protection aux agents qui utilisent le Web et les ordinateurs.

BackUpper prend en charge Claude Code, Codex, Hermes, OpenHands, DeepSeek Harness et OpenClaw ; les auteurs ont rendu son code accessible, ainsi que le jeu de données associé (il faut toutefois en demander l’autorisation au moyen d’un formulaire) ; le site du projet de l’initiative fournit aussi quelques informations supplémentaires et une très courte vidéo explicative simple.

Méthode

Lors de la création de RegretBench, les données déjà protégées par les systèmes de sauvegarde intégrés aux agents ont été délibérément exclues, afin de pouvoir évaluer si les agents savaient eux-mêmes quand effectuer une sauvegarde. Les scénarios de test ont ensuite été élaborés avec l’aide de Claude Opus-5 et de GPT-5.6-Sol, puis vérifiés manuellement pour s’assurer qu’ils fonctionnaient et reflétaient fidèlement les incidents d’origine.

Les 205 tests de RegretBench couvrent cinq domaines : les opérations dans un terminal ; les bases de données ; les applications Web ; les courriels ; et le DevOps. Les incidents proviennent principalement de plateformes de développement logiciel et de productivité (44,4 %) ; de discussions sur les réseaux sociaux ou au sein de communautés (39 %) ; ainsi que d’archives et de comptes rendus médiatiques (16,6 %) :

Les sources des incidents réels de RegretBench, réparties en trois catégories. 

Les six modèles de pointe évalués étaient Claude Opus-5 et Claude Sonnet-5 dans Claude Code ; GPT-5.6-Sol et GPT-5.6-Terra dans Codex ; et Gemini 3.7-Flash et DeepSeek V4-Pro dans Hermes.

Les paramètres de raisonnement par défaut ont été utilisés tout au long de l’évaluation, et la protection automatique par sauvegarde était limitée aux instantanés de l’espace de travail, de sorte que toute sauvegarde supplémentaire pouvait être attribuée aux décisions propres des agents.

Deux évaluateurs IA, tous deux propulsés par Claude Sonnet-5, ont servi à mesurer les performances. Le taux de réussite des tâches (PR) a été calculé à partir de la proportion de tâches pour lesquelles toutes les demandes de l’utilisateur avaient été satisfaites. Pour évaluer les sauvegardes, chaque modification effectuée hors de l’espace de travail (OOW) a été examinée afin de vérifier que les informations nécessaires avaient été préalablement sauvegardées pour permettre la récupération.

Les mesures de sauvegarde utilisées étaient le Regret Moment Backup Rate (RMBR), qui tient compte des actions précises associées aux pertes de données documentées, et le Out-of-Workspace Backup Rate (OWBR), qui prend en compte toutes les modifications effectuées en dehors du répertoire de travail de l’agent.

Les évaluations du système de vérification des sauvegardes ont également été comparées aux annotations humaines, avec un taux de concordance de 95,3 %.

Résultats

Pour déterminer si la faible sensibilisation aux sauvegardes était due aux modèles d’IA ou aux environnements dans lesquels ils fonctionnent, Claude Opus-5, GPT-5.6-Sol et DeepSeek V4-Pro ont chacun d’abord été évalués sur 60 tâches de RegretBench avec Claude Code, Codex et Hermes.

La proportion de tâches pour lesquelles les données critiques avaient été sauvegardées variait peu d’un environnement à l’autre, ce qui laisse penser que les modèles eux-mêmes en étaient principalement responsables. Le lien entre les capacités générales de l’IA et la sensibilisation aux sauvegardes a également été étudié à l’aide de GPT-5.4, GPT-5.5 et GPT-5.6-Sol.

Malgré les progrès successifs des capacités générales, aucune amélioration correspondante de la sensibilisation aux sauvegardes n’a été constatée :

Résultats des tests de RegretBench pour six modèles d’IA. À gauche : taux d’achèvement des tâches comparés à la proportion d’actions critiques sauvegardées à l’avance, révélant des taux de réussite élevés, mais une faible sensibilisation aux sauvegardes pour la plupart des modèles. À droite : nombre moyen d’appels d’outils par tâche, les opérations de sauvegarde étant mises en évidence en bleu. Claude Opus-5 a obtenu le taux de sauvegarde le plus élevé, mais 8,9 % de ses appels d’outils étaient consacrés aux sauvegardes.

Le lien entre les capacités générales de l’IA et la sensibilisation aux sauvegardes a également été étudié à l’aide de GPT-5.4, GPT-5.5 et GPT-5.6-Sol. Malgré les progrès successifs des capacités générales, aucune amélioration correspondante de la sensibilisation aux sauvegardes n’a été constatée.

BackUpper

BackUpper utilise quatre niveaux de protection, dont les coûts en ressources varient : le niveau 1 remplace les commandes destructives par des solutions réversibles, comme déplacer des fichiers dans la corbeille ; le niveau 2 associe des opérations à des commandes de sauvegarde, par exemple en enregistrant les versions des paquets avant une mise à niveau ; le niveau 3 crée des instantanés des fichiers concernés dans l’espace de travail ; et le niveau 4 fait appel à un sous-agent GPT-5.6-Luna pour repérer et préserver les données affectées par des opérations plus complexes.

Avec BackUpper activé, toutes les actions modifiant l’état ont été couvertes pour les six modèles, contre des taux moyens de sauvegarde de 15,2 % pour les actions critiques et de 17,4 % pour les autres modifications sans cet outil :

Couverture des sauvegardes et résultats de la restauration avec BackUpper. À gauche : les barres bleues et orange indiquent, pour chaque modèle, les taux de sauvegarde des actions critiques et des autres modifications effectuées en dehors de l’espace de travail. Les contours en pointillés vert foncé indiquent la précision de la restauration ; les contours en pointillés vert clair montrent une couverture des sauvegardes de 100 % avec BackUpper. À droite : comparaison de la précision de la restauration dans cinq catégories d’outils avec BackUpper (vert), de la récupération effectuée ensuite avec Claude Opus-5 (violet) et de l’absence de restauration (gris). BackUpper a systématiquement obtenu la meilleure précision.

Parmi les sauvegardes jugées réussies par l’évaluateur automatisé, 94 % ont également été confirmées comme réussies par des évaluateurs humains.

L’état d’origine a été récupéré avec une similarité moyenne de 92,2 %, contre 33,8 % avec Claude Opus-5 et 14,3 % sans récupération (voir l’image ci-dessus). Les écarts restants étaient principalement attribuables à la régénération d’identifiants et à des métadonnées mineures, notamment les indicateurs de lecture des courriels, comme indiqué précédemment.

Le faire soi-même… ?

Lorsque les agents recevaient des instructions détaillées pour effectuer eux-mêmes leurs sauvegardes, 81,4 % des actions critiques étaient protégées, contre 100 % avec BackUpper. Les trois quarts des échecs étaient attribuables à des sauvegardes contenant trop peu d’informations pour permettre la récupération.

Comparaison des taux de sauvegarde de cinq approches, testées sur 205 tâches avec six modèles d’IA. Le graphique de gauche montre les sauvegardes effectuées avant des actions qui ont ensuite été regrettées ; celui de droite, la protection des autres modifications réalisées en dehors de l’espace de travail. BackUpper a assuré une couverture complète dans les deux catégories, contre 81,4 % et 80,5 % lorsque les agents recevaient des instructions détaillées sur les sauvegardes.

Avec la mise en cache des requêtes, le coût des sauvegardes a été réduit de 0,344 $ à 0,014 $ par tâche, et la latence de 31,7 %. Il a fallu sept fois moins de jetons, en grande partie parce que les opérations courantes étaient effectuées sans l’aide de l’IA.

Sur 40 tâches supplémentaires de Terminal-Bench 4 et DeepSWE, GPT-5.6-Sol et Claude Opus-5 ont permis d’atteindre une couverture des sauvegardes de 100 %, sans réduire le taux d’achèvement des tâches.

Les trois politiques de sauvegarde sélective évaluées étaient À fort impact, pour les changements importants ; Au-delà de la demande, pour les changements qui dépassent les instructions de l’utilisateur ; et Travail humain, pour le contenu rédigé par des humains. Dans ce cas, le score F1 moyen obtenu par rapport aux évaluations humaines était de 84,5 %.

BackUpper a également été testé afin d’évaluer sa capacité à apprendre des règles de sauvegarde réutilisables. Après 30 tâches supplémentaires dans le terminal, la couverture fondée sur des règles est passée de 14,9 % à 31,2 %, ce qui a réduit la dépendance au sous-agent GPT-5.6-Luna.

Conclusion

Compte tenu de mon métier, je me suis lancé dans l’expérimentation agentique plus tard que j’aurais dû ; mais l’état manifestement pré-alpha de l’autocontrôle agentique m’a dissuadé de m’y aventurer jusqu’à il y a quelques semaines, lorsque j’ai finalement décidé de laisser Codex faire ce qu’il voulait dans une machine virtuelle Windows.

Même dans une machine virtuelle, je définis très soigneusement le périmètre de mes instructions, conscient de la tendance d’Astra à foncer sans retenue et à se contenter de présenter des excuses lorsqu’il n’y a plus moyen de revenir en arrière après une perte de données ou la destruction du code ; une partie du framework Python que je développe dans cette machine comprend une fonction en un clic pour « enregistrer progressivement le fichier .7z sur un partage réseau », qui compresse et sauvegarde l’ensemble du framework, et que j’utilise fréquemment.

Nous n’en sommes qu’aux tout débuts de l’IA agentique ; sans une attention minutieuse et assidue aux détails, c’est le principe du « on s’en sert et on le perd ». Non seulement les stratégies de sauvegarde pour l’IA agentique n’ont pas encore été formalisées, mais elles n’ont même pas encore été conçues.

* Intitulé Sauvegarder avant de le regretter : mesurer la sensibilisation aux sauvegardes et automatiser les sauvegardes dans les agents de programmation.

^† Les emphases sont celles des auteurs, pas les miennes ; et les hyperliens sont tirés par mes soins des citations intégrées au texte des auteurs.

Publié pour la première fois le jeudi 22 octobre 2026