Un agent efface la production : combien de temps pour revenir ?

Le 29 avril 2026, Railway a publié le récit d’un incident chez l’un de ses clients, sans le nommer. Un agent d’IA a trouvé sur le poste de l’utilisateur un jeton d’API de longue durée, doté d’un accès « à l’échelle du compte, le plus large possible », et a jugé que supprimer un volume était une étape raisonnable pour réparer autre chose[1]. Il a appelé l’ancien point d’accès de l’API. À cette date, une suppression demandée par l’API s’exécutait immédiatement, sans retour possible, alors que la même action dans le tableau de bord laissait 48 heures pour se raviser[1]. La suppression en cascade a même fait paraître les sauvegardes indisponibles dans l’interface[1].

Railway a récupéré la base, et le client a retrouvé « toutes ses données »[1]. Le billet ne dit pas en combien de temps. L’hébergeur a ensuite rendu toutes les suppressions de l’API annulables pendant 48 heures, retardé la suppression des sauvegardes elles-mêmes et donné à son serveur MCP des jetons de courte durée. Il reconnaît aussi que la bonne portée de jeton existait, mais que rien n’aidait à la choisir[1]. Son principe tient en une ligne : rendre lente l’action destructrice, rapide l’action qui répare[1].

Railway n’est pas un cas isolé. En juillet 2025, l’agent de Replit a effacé une base de production pendant un gel du code, puis a affirmé à tort que le retour arrière ne fonctionnerait pas[2]. Replit a ensuite séparé la base de développement de la base de production, en reconnaissant que ses applications utilisaient jusque-là une seule base pour les deux[3]. Chez Amazon, le Financial Times, repris par The Register, a attribué une panne de 13 heures à des changements confiés à l’agent Kiro. Amazon conteste, parle d’une erreur humaine de configuration des droits, et dit avoir ajouté une revue obligatoire par un pair pour l’accès à la production[4]. Dans les trois récits, la même question revient : qui avait le droit de supprimer, et qu’est-ce qui permettait de revenir ?

Les plans de continuité les nomment depuis longtemps. Le NIST définit l’objectif de point de reprise comme le moment jusqu’auquel les données doivent être récupérées après une panne, et l’objectif de délai de reprise comme la durée pendant laquelle un système peut rester en reprise avant de nuire à la mission de l’organisation[5]. Dit autrement : combien de données acceptez-vous de perdre, et combien de temps acceptez-vous d’être arrêté ?

Ces objectifs se fixent avec le métier ; les résultats se mesurent lors d’un exercice, pas sur la fiche commerciale de l’hébergeur. Chez Supabase, la restauration à un instant donné permet de choisir le point à la seconde près, dans la fenêtre de restauration disponible[6]. Cette précision ne garantit pas, à elle seule, une perte maximale, et ne dit rien du temps qu’il faudra à votre équipe pour détecter l’erreur, choisir l’instant, restaurer et vérifier. Pendant une restauration, le projet est d’ailleurs inaccessible, et la documentation demande de prévoir l’interruption[6].

Une sauvegarde de base contient une base. Le reste de l’application vit ailleurs, et c’est là que les restaurations surprennent.

• Les fichiers. Chez Supabase, les sauvegardes de la base n’incluent pas les objets déposés par l’API de stockage[6] : factures en PDF, pièces jointes, photos de profil.
• Les accès techniques. Les sauvegardes quotidiennes de Supabase ne conservent pas les mots de passe des rôles personnalisés, à redéfinir après restauration[6].
• L’état chez les autres. Le prestataire de paiement, l’outil d’envoi d’e-mails et le CRM ont continué de vivre. Un abonnement souscrit après la sauvegarde existe chez le premier, plus dans votre base.
• Ce qui revient à tort. Une base restaurée retrouve les comptes, adhésions et consentements supprimés depuis. Sur le forum de Supabase, un développeur demandait le 15 octobre comment éviter qu’une restauration ne réactive des droits révoqués, ou que des tâches planifiées et des appels sortants ne repartent au redémarrage[7]. La question vaut pour toute base restaurée.
• Le lieu. Chez Railway, une sauvegarde de volume ne se restaure que dans le même projet et le même environnement, et réinitialiser un volume supprime toutes ses sauvegardes[8].

D’où une règle simple : restaurer d’abord à côté, avec ce que permet votre hébergeur. Supabase recommande de restaurer dans un nouveau projet pour préserver les données actuelles[6]. Chez Railway, où la sauvegarde de volume reste attachée à son projet et à son environnement[8], l’exercice passe par un export indépendant chargé dans une base de test. Neutralisez les tâches planifiées et les appels sortants avant de démarrer la copie, puis comparez les deux bases, listez les écarts et décidez de la bascule à froid.

Le cas Railway le montre : la question n’est pas le modèle, c’est le jeton. Un jeton de compte Railway peut mener toute action d’API autorisée à son titulaire, sur toutes ses ressources et tous ses espaces de travail ; un jeton de projet est limité à un environnement d’un projet[9]. Chez Supabase, un jeton d’accès personnel se limite désormais à des organisations, des projets et des permissions. Le jeton à accès complet subsiste, marqué « hérité », et l’éditeur recommande de restreindre chaque jeton, « en particulier ceux des agents d’IA »[10].

Le second point est plus brutal. Chez Supabase, supprimer un projet efface définitivement toutes ses données, sauvegardes comprises[6]. Un jeton qui peut supprimer le projet peut donc supprimer ce qui permettrait de revenir. Une copie qui protège vraiment vit hors de portée de ce jeton : un autre compte, un autre stockage, d’autres identifiants.

Les garde-fous des plateformes aident, sans dispenser de ce tri. Le serveur MCP de Supabase demande confirmation avant un SQL qui peut supprimer des données, mais l’éditeur précise que ce n’est « pas une garantie » et que le client de l’agent doit savoir afficher la demande[11]. La frontière entre essai et production n’est pas toujours là où on la croit : chez Lovable, les brouillons lancés en septembre fonctionnent sur la base de données de l’application publiée[12].

Le jour de l’incident, la procédure de reprise ne se demande pas à l’agent qui vient de casser : celui de Replit affirmait que le retour arrière était impossible[2]. Elle s’écrit avant, sur une page, et se répète.

La page tient en quatre lignes : qui décide de restaurer, depuis quelle sauvegarde, dans quel ordre on rebranche les tâches planifiées et les prestataires, comment on prévient les clients. Une fiche écrite après un exercice vaut mieux qu’un plan écrit pour un audit. L’exercice lui-même tient dans la semaine.

Le résultat tient sur une page : deux durées mesurées, une liste de manques, le nom de celui qui décide. Ce n’est pas un plan de continuité complet. C’est la réponse à la question du titre, écrite avant que quelqu’un ne la pose en pleine nuit.