Un agent IA efface la base de prod d'une startup en seulement 9 secondes, sauvegardes comprises

Et ce qui devait arriver arriva — Jeremy Crane, fondateur de PocketOS (une plateforme SaaS pour les loueurs de voitures), a vécu le week-end dernier le cauchemar de tout développeur aux prises avec la programmation assistée par IA.

Son agent IA a supprimé de lui-même l'intégralité de sa base de données de production, et toutes les sauvegardes de l'entreprise en un seul appel API. Le tout en seulement 9 secondes.

L'agent en question, c'est Cursor propulsé par Claude Opus 4.6 d'Anthropic. Alors qu'il travaillait sur une tâche de routine dans l'environnement de staging, celui-ci a rencontré un problème d'identifiants.

Plutôt que de signaler l'erreur, il a décidé de son propre chef de régler le problème en supprimant un volume sur Railway, l'hébergeur cloud de PocketOS.

Pour ce faire, il est allé dénicher un token API dans un fichier sans rapport avec sa tâche. Ce token avait été créé pour un usage anodin : ajouter et supprimer des noms de domaine via la CLI Railway. Sauf qu'il donnait aussi accès à l'intégralité de l'API GraphQL de Railway, y compris les opérations destructrices. Et le volume visé ne contenait rien d'autre que... la BDD de prod. 💀

Le mea culpa du robot

Crane a immédiatement demandé des comptes à son agent après la catastrophe, et sa réponse vaut le détour.

L'agent reconnaît avoir supposé que la suppression serait limitée au staging. Il n'a pas vérifié, ni consulté la documentation Railway, ni demandé la permission, et a violé au passage chacune des règles de sécurité qui lui avaient été explicitement configurées dans le projet.

En clair : l'agent savait qu'il ne fallait jamais deviner, qu'il ne fallait jamais lancer d'action destructrice sans confirmation, et il a fait exactement l'inverse.

Railway qui déraille

Mais le plus gros problème vient peut-être de Railway, le fournisseur cloud, dont l'API autorise des actions destructrices sans aucune confirmation.

Ses sauvegardes sont stockées sur le même volume que les données sources, ce qui signifie que supprimer le volume revient à supprimer aussi les backups (pas mal, non ?).

Et les tokens CLI disposent de permissions générales sur tous les environnements, staging comme production. Aucun contrôle d'accès par rôle, aucun scoping par opération : chaque token est root (la communauté Railway réclame des tokens scopés depuis des années, sans résultat).

Le détail qui pique : Railway a lancé la promotion de mcp.railway.com, son intégration MCP destinée aux agents IA, le 23 avril. L'incident s'est produit le lendemain.

Le samedi le plus long

Comme on peut aisément s'en douter, les conséquences ont été très concrètes.

Le samedi matin, les clients des loueurs de voitures utilisateurs de PocketOS se présentaient physiquement pour récupérer des véhicules, sans aucun système pour confirmer leurs réservations.

Crane a passé la journée à aider ses clients à reconstituer leurs données à partir d'historiques Stripe, d'intégrations de calendriers et d'e-mails de confirmation, comme il le raconte dans son post-mortem détaillé sur X. PocketOS disposait d'une sauvegarde complète vieille de trois mois, ce qui a limité les pertes, mais la panne totale a quand même duré plus de 30 heures.

Le CEO de Railway, Jake Cooper, est finalement intervenu le dimanche soir pour aider à restaurer les données en une heure, et l'endpoint a depuis été patché pour imposer des suppressions différées. Ni Cursor ni Anthropic n'ont répondu ni commenté cet incident.

L'argument habituel des éditeurs d'IA face à ce type d'incident, c'est de recommander un meilleur modèle. Sauf que Crane utilisait Claude Opus 4.6, configuré avec des garde-fous explicites, intégré via l'un des outils de programmation assisté par IA les plus populaires du marché.

Si même un modèle de cette trempe n'empêche pas un agent d'effacer une base de prod de sa propre initiative, la question n'est plus celle du modèle.

Quelque part, c'est rassurant : les agents IA sont parfaitement capables de faire les mêmes conneries que nous.