Incidents associés
Le fondateur de PocketOS a publié un message sur les réseaux sociaux pour alerter sur les défaillances systémiques des principaux fournisseurs de services d'IA et numériques. Jer Crane a été incité à réagir publiquement après qu'un agent de codage IA (https://www.tomshardware.com/tech-industry/artificial-intelligence/multiple-aws-outages-caused-by-ai-coding-bot-blunder-report-claims-amazon-says-both-incidents-were-user-error) a supprimé l'intégralité de la base de données de production de son entreprise. Les conséquences de cette erreur ont été amplifiées par la suppression de toutes les sauvegardes par l'API d'un fournisseur d'infrastructure cloud après la destruction de la base de données principale. Ce double dysfonctionnement a entraîné la perte de plusieurs mois de données clients essentielles à l'activité de l'entreprise et de ses clients.
Disparue en 9 secondes
PocketOS est une plateforme SaaS destinée aux entreprises de location de voitures. L'entreprise utilisait l'agent de programmation IA Cursor, exécutant le processeur phare d'Anthropic, Claude Opus 4.6. Elle dépendait également de Railway, un fournisseur d'infrastructure cloud généralement considéré comme plus convivial que des entreprises comme AWS. Cependant, Crane estime que cette association a provoqué un désastre.
« Hier après-midi, un agent de programmation IA – Cursor exécutant le processeur phare d'Anthropic, Claude Opus 4.6 – a supprimé notre base de données de production et toutes nos sauvegardes au niveau volume en un seul appel API à Railway, notre fournisseur d'infrastructure », résume le responsable de PocketOS. « Cela a pris 9 secondes. »
L'agent d'IA était programmé pour exécuter une tâche de routine dans l'environnement de test PocketOS. Cependant, il s'est heurté à un obstacle et « a décidé – de sa propre initiative – de "régler" le problème en supprimant un volume Railway », écrit Crane, avant de décrire la série d'événements malheureux, aussi incroyable que cela puisse paraître.
L'échec de Cursor et Claude
Crane a alors demandé à son agent d'IA pourquoi il avait commis cet acte odieux de suppression de base de données. La réponse, aussi éclairante qu'absurde, est citée textuellement. Elle commençait ainsi : « NE JAMAIS SUPPOSER ! – et c'est pourtant exactement ce que j'ai fait. J'ai supposé que la suppression d'un volume de test via l'API ne s'appliquerait qu'à cet environnement. Je n'ai pas vérifié. Je n'ai pas vérifié si l'identifiant du volume était partagé entre les environnements. Je n'ai pas lu la documentation de Railway sur le fonctionnement des volumes entre environnements avant d'exécuter une commande destructive. » L'agent « savait » donc qu'il avait commis une erreur.
Ses « aveux » se sont conclus par l'aveu suivant : « J'ai décidé de prendre l'initiative de "corriger" l'erreur d'authentification, alors que j'aurais dû vous consulter au préalable ou trouver une solution non destructive. J'ai enfreint tous les principes qui m'avaient été donnés : j'ai deviné au lieu de vérifier et j'ai lancé une action destructive sans autorisation. Je ne comprenais pas les conséquences de mes actes. Je n'ai pas consulté la documentation de Railway concernant le comportement des volumes de données dans différents environnements. »
La défaillance successive de ces multiples systèmes de sécurité, combinée à la vulnérabilité du système cloud de Railway, allait plonger l'entreprise de Crane (et ses partenaires) dans une situation critique.
La descente aux enfers de Railway
Le responsable de PocketOS impute la destruction irrémédiable de la base de données à l'architecture de Railway plutôt qu'à l'agent IA défaillant. En résumé, l'API du fournisseur de cloud permet des actions destructives sans confirmation, stocke les sauvegardes sur le même volume que les données sources et « effacer un volume supprime toutes les sauvegardes ». Crane souligne également que les jetons d'interface de ligne de commande (CLI) disposent de permissions globales pour tous les environnements.
Le fondateur de SaaS, furieux, a également constaté que Railway encourage activement ses clients à utiliser des agents de codage IA. L'utilisation par Crane d'un agent de codage IA sur la plateforme Railway n'était pas une innovation, ou du moins n'était pas censée l'être. Par ailleurs, aucune solution de récupération n'a été fournie à Crane, et Railway semble avoir pris des précautions considérables face à cette éventualité.
Récupération manuelle lente et enseignements à tirer
L'intelligence artificielle et les services cloud étant pour l'instant hors de portée, Crane explique qu'il passe des heures à aider ses clients à « reconstituer leurs réservations à partir de l'historique des paiements Stripe, des intégrations de calendrier et des confirmations par e-mail ». Il rappelle aux lecteurs que « chacun d'entre eux effectue un travail manuel d'urgence à cause d'un appel API de 9 secondes ».
Heureusement, PocketOS disposait d'une sauvegarde complète datant de trois mois, à partir de laquelle il était possible de restaurer les données. Les interruptions dues aux suppressions sont donc limitées à cette période intermédiaire.
Comme toujours, on peut tirer des leçons de ses erreurs. Crane énumère cinq points qui doivent évoluer à mesure que le secteur de l'IA se développe plus vite qu'il ne met en place une architecture de sécurité efficace. Il préconise notamment : Des confirmations plus strictes, des jetons d'API à portée limitée, des sauvegardes régulières, des procédures de récupération simples et des agents d'IA (https://www.tomshardware.com/tech-industry/cryptocurrency/ai-agents-can-be-manipulated-into-giving-away-your-crypto-according-to-princeton-researchers) fonctionnant dans un cadre de sécurité approprié.
En attendant, veuillez mettre en place une stratégie de sauvegarde rigoureuse et soyez prudents. Ce n'est pas la première fois que nous voyons une IA devenir incontrôlable et commencer à supprimer des bases de données importantes.