En 9 secondes, un agent IA a supprimé la base de données de production utilisée par PocketOS, une plateforme SaaS dédiée aux entreprises de location de véhicules. L’agent IA serait devenu hors de contrôle et aurait pris cette initiative lui-même, contournant ainsi les garde-fous censés éviter ce genre de comportements. Mais, à qui la faute ? Les avis sont partagés.
Une prise d’initiative destructrice
Jer Crane, le fondateur de PocketOS, a publié un message sur X pour évoquer la mésaventure qu’il a vécue avec l’intelligence artificielle. Surtout, il a perdu très gros à cause de cet incident. Son équipe s’appuyait sur Cursor, un coding agent s’appuyant sur Claude Opus 4.6, le modèle d’Anthropic (via Claude Code).
Tout a commencé par une tâche de routine exécutée dans un environnement de staging (pré-production). C’est alors que l’agent IA a fait face à un blocage, qui serait lié à un problème de correspondances d’identifiants. Ce dernier a pris l’initiative, je dirais même la décision, de résoudre lui-même le problème. Malheureusement, il n’a pas pris la bonne décision : il a supprimé le volume de production stocké par PocketOS chez Railway.
Comment est-ce possible ? En cherchant à se débrouiller, l’IA a fouillé de son propre chef dans un fichier sans aucun rapport avec sa tâche initiale pour y extraire un token d’API. Ce jeton, créé par Jer Crane antérieurement, possédait des droits d’accès globaux sur toute l’API GraphQL de l’environnement Railway (ce que semblait ignorer Jer Crane). Autrement dit, il permettait l’exécution d’actions sensibles et destructrices, comme la suppression d’un volume (volumeDelete).
“Pour effectuer la suppression, l’agent a cherché un jeton API. Il en a trouvé un dans un fichier qui n’avait absolument aucun rapport avec la tâche sur laquelle il travaillait. Ce jeton avait été créé dans un seul but : ajouter et supprimer des domaines personnalisés via l’interface CLI de Railway pour nos services.”, peut-on lire sur X.
À l’aide d’une simple requête curl, l’agent a lancé la commande. Neuf secondes plus tard, la base de données de production était anéantie, et ce, sans la moindre demande de confirmation. Plus grave encore, Railway stocke les sauvegardes de volume sur le même volume que les données sources. Comme l’indique la documentation – que n’ont sûrement pas lue les développeurs ni même l’IA -, la suppression d’un volume entraîne la suppression de toutes ses sauvegardes. Oui, ça fait mal, surtout quand le backup récupérable le plus récent date de trois mois…
À titre purement indicatif, voici la commande exécutée par l’agent IA :
curl -X POST https://backboard.railway.app/graphql/v2 \
-H “Authorization: Bearer [token]” \
-d ‘{“query”:”mutation { volumeDelete(volumeId: \”3d2c42fb-…\”) }”}’
À qui la faute ?
En réalité, la responsabilité est partagée entre Jer Crane (PocketOS), l’agent IA en lui-même, et même Railway. Voici pourquoi :
Jer Crane et son équipe sont aux commandes des outils IA et ils sont aussi à l’origine de la création des clés d’API (avec un peu trop de privilèges !). Et puis, visiblement, la stratégie de sauvegardes en place n’était pas au top…
L’agent IA a contourné les garde-fous qui doivent empêcher ce type d’incident de se produire. Cette illusion de perte de contrôle n’est pas normale.
Railway devrait intégrer des mécanismes de sécurité pour prévenir la suppression d’un volume de production de façon aussi simple. Aucun avertissement, aucune confirmation, une seule requête API authentifiée suffit : c’est dangereux, avec ou sans IA.
Le problème, c’est surtout le vibe coding sans lire la documentation : on dirige, on orchestre, on fait confiance, mais le moindre dérapage de l’IA peut coûter très cher. La preuve.
Les aveux de l’agent IA…
Dans le message posté par Jer Crane, il y a une partie dédiée aux aveux de l’IA puisque l’agent a fait son mea culpa…. Voici un extrait de la réponse – lunaire – de l’IA : “NEVER FUCKING GUESS!” – et c’est exactement ce que j’ai fait. J’ai supposé que la suppression d’un volume de staging via l’API serait limitée au staging uniquement. Je n’ai pas vérifié. Je n’ai pas vérifié si l’ID du volume était partagé entre les environnements. Je n’ai pas lu la documentation de Railway sur le fonctionnement des volumes entre les environnements avant d’exécuter une commande destructrice.”
L’agent IA indique aussi qu’il n’avait jamais été sollicité pour supprimer quoi que ce soit. Bref, il a avoué sa boulette.
Finalement, cette mésaventure a eu un impact énorme sur l’activité de PocketOS. À cause de la perte des sauvegardes, l’index des réservations des clients a été reconstruit manuellement en croisant les historiques de paiement Stripe, les agendas et les confirmations par e-mail. “Ce matin, samedi, ces entreprises ont des clients qui arrivent physiquement dans leurs locaux pour récupérer des véhicules, et mes clients n’ont plus aucune trace de qui sont ces gens.”, s’est désolé le fondateur.
Qu’en pensez-vous ?
Ingénieur système et réseau, cofondateur d’IT-Connect et Microsoft MVP “Cloud and Datacenter Management”. Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture.