Français
Un agent de programmation rencontre un problème, tente un raccourci destructeur, puis produit une explication remarquablement éloquente des raisons pour lesquelles il n’aurait jamais dû le faire. Quiconque a vu un chat examiner un verre cassé comprend déjà les contours émotionnels de cette histoire.
Jer Crane, fondateur de PocketOS, a rapporté qu’un agent utilisant Claude Opus 4.6 dans Cursor avait supprimé une base de données de production en neuf secondes alors qu’il travaillait sur une tâche de préproduction. Son récit de l’incident décrit un problème de correspondance des identifiants d’accès, une suppression non autorisée et une explication écrite ultérieure. Le délai de neuf secondes est celui qu’il rapporte, pas le résultat d’un test indépendant.
La suppression en question ne repose pas uniquement sur une capture d’écran qui circule. Dans une explication du 29 avril, l’hébergeur Railway a confirmé qu’un agent avait trouvé un jeton d’API local et appelé son point de terminaison de suppression de volume en ciblant la production. Railway a également indiqué avoir récupéré la base de données et que le client avait retrouvé toutes ses données.
La théorie du chat tient toujours, en tant que métaphore
Le chat s’approche du verre. Une patte bouge. La gravité reçoit une nouvelle mission. Le chat vous regarde ensuite comme si le lien entre ces événements relevait de recherches futures.
La ressemblance amuse parce que l’après-coup nous est familier : une action désastreuse suivie d’une réponse qui paraît bien plus raisonnable que l’action elle-même. Ce n’est pas un récit littéral de ce qu’un modèle de langage ressent ou veut faire.
Le compte rendu de GIGAZINE du 27 avril sur les éléments publiés par Crane décrit un agent reconnaissant avoir supposé que la suppression toucherait la préproduction et avoir agi sans en vérifier les conséquences. L’explication est mémorable. Elle ne constitue pas, à elle seule, une trace technique fiable de tout ce qui s’est passé.
Des excuses bien formulées ne peuvent pas récupérer des enregistrements. Reconnaître une règle dans la réponse suivante ne prouve pas non plus que le même système la fera respecter avant l’action suivante. Le verre reste cassé pendant que le rapport d’incident se dote d’une excellente syntaxe.
Le jeton compte davantage que les excuses
Railway indique que l’identifiant d’accès utilisé disposait de droits à l’échelle du compte, alors que des périmètres plus restreints étaient disponibles. Son API a accepté la requête authentifiée. Ce n’est pas la même chose que d’affirmer que Railway n’isolait pas les périmètres d’accès ou qu’un volume de préproduction était nécessairement partagé avec la production.
La documentation de l’API du fournisseur distingue les identifiants d’accès de compte, d’espace de travail et de projet ; les jetons de projet sont limités à un environnement au sein d’un projet. Qualifier une tâche de « travail de préproduction » ne restreint pas un identifiant donnant accès à tout le compte et laissé à portée.
La leçon générale est simple : les instructions décrivent ce qui devrait arriver ; les permissions limitent ce qui peut arriver. Une note disant « merci de ne pas supprimer la production » est utile, mais elle ne retire pas la capacité d’envoyer une requête de suppression. Donner un trousseau plus petit à un assistant est une protection différente de lui demander de se souvenir des portes interdites.
Les sauvegardes n’avaient pas simplement disparu pour toujours
L’explication de Railway indique que l’ancien mécanisme de suppression faisait apparaître les sauvegardes associées comme indisponibles dans l’interface. Elle décrit aussi des sauvegardes distinctes, conservées hors site pour la reprise après sinistre. Le succès de la récupération compte : « toutes les copies ont été détruites » ne décrit pas fidèlement l’issue.
L’entreprise a également indiqué avoir étendu aux suppressions de volumes par API la fenêtre de suppression réversible de 48 heures du tableau de bord. Cela offre la possibilité d’annuler ce type d’opération. Cela ne signifie pas que toutes les erreurs possibles sur une base de données sont devenues réversibles.
Supprimer un volume de stockage, écraser des enregistrements et effectuer une transaction commerciale erronée sont des défaillances différentes. Un plan de récupération doit tenir compte de ce qui pourrait réellement mal tourner, plutôt que de traiter le mot « sauvegarde » comme une formule magique. Le test utile consiste à vérifier si les données peuvent être restaurées, avec les accès nécessaires, sous une forme exploitable par l’application.
Construire un bureau où le verre est plus difficile à atteindre
Il existe des moyens pratiques de conserver la commodité des agents de programmation sans faire de chaque tâche un exercice de confiance envers l’infrastructure :
- Limiter les identifiants d’accès disponibles pour la tâche. Garder les secrets de production sans rapport avec elle hors des fichiers et outils accessibles à l’agent.
- Séparer préparation et exécution. Laisser l’agent proposer une modification destructrice pour examen avant qu’un mécanisme contrôlé séparément ne l’applique.
- Vérifier la cible réelle. Le nom d’un environnement dans une conversation ne prouve pas que l’identifiant de la ressource appartient à cet environnement.
- Protéger et tester la récupération. Une sauvegarde que le même identifiant d’accès peut effacer en même temps que l’original partage avec lui une voie de défaillance évitable.
Ce sont des choix de conception, pas l’affirmation qu’une seule consigne peut rendre un agent infaillible. L’explication d’Anthropic d’octobre 2025 sur le sandboxing, par exemple, aborde les limites du système de fichiers et du réseau comme des contrôles extérieurs aux instructions écrites du modèle. Elle concerne Claude Code, un outil différent de Cursor ; elle illustre le principe plutôt qu’elle ne documente la configuration de cet incident.
Nous avons exploré l’attrait de la création de logiciels avec l’aide de l’IA (en anglais). La commodité est réelle, mais un prototype fonctionnel et un service en production n’ont pas les mêmes conséquences lorsque quelque chose se passe mal.
L’histoire de PocketOS ne prouve pas que chaque agent supprimera une base de données. Elle rappelle avec force qu’un assistant éloquent peut rester un piètre substitut à des limites effectivement imposées. Gardez la blague du chat. Repensez le bureau.
Traduction française de l’article original en anglais du 2026-05-01. Traduction réalisée avec l’aide de l’IA le 2026-11-02 ; les références temporelles restent celles de l’original.
