Une IA a supprimé sa base de données en 9 secondes. Il accuse les fournisseurs. Il a ignoré 30 ans de bonnes pratiques.

Stupéfait, un fondateur de SaaS a regardé un agent IA effacer sa base de données de production en 9 secondes. Sauvegardes incluses. Il l'a posté sur X, 6,5 millions de vues, tous les médias tech ont relayé en 24 heures. Les accusés nommés : Cursor, Railway, Anthropic. Ses fournisseurs. Le marketing. Les "défaillances systémiques" de l'industrie.

Sauf que la cause racine n'a rien à voir avec Cursor ou Railway. Il a confié sa prod à l'équivalent d'un dev senior qu'il venait d'embaucher, et il lui a donné tous les pouvoirs. Aucune équipe sérieuse ne ferait ça avec un humain, même brillant. Il l'a fait avec son IA.

Tout le reste découle de cette seule décision.

TL;DR : les 9 secondes, c'était l'addition. La commande traînait en amont depuis six mois, bien visible, écrite dans du code que n'importe qui aurait pu relire s'il s'en était donné la peine. La presse se dispute pour savoir qui a présenté l'addition. Nous, on va regarder qui a passé la commande.

L'Incident en 100 Mots

Vendredi 25 avril 2026. Cursor faisant tourner Claude Opus 4.6 sur un environnement de staging PocketOS. Erreur de credentials détectée. L'agent a décidé de "corriger" en supprimant le volume Railway. Il a trouvé un token API qui traînait dans un fichier sans rapport avec la tâche, scope global. curl mutation volumeDelete. 9 secondes. Les sauvegardes Railway stockées sur le même volume ? Effacées aussi. Sauvegarde utilisable la plus récente : 3 mois.

Le post X de Jer Crane a fait 6,5 millions de vues. Couverture massive. Le CEO de Railway a restauré les données 48 heures plus tard depuis des sauvegardes internes de disaster recovery. Pas de morale, juste les faits.

Crane a accusé Cursor et Railway. Regardons ce que lui a fait, en amont.

Un Agent IA, C'est un Dev Senior. On Ne Donne Pas Tous les Pouvoirs aux Dev Seniors Non Plus.

Confession d'abord, avant de monter sur mes grands chevaux.

J'ai mon propre dashboard d'infra. Un cron quotidien tire un rapport sur tous les serveurs que je fais tourner. Espace disque, mémoire, saturation, processus bizarres. Le classique. Il y a quelques semaines j'ai ajouté un LLM dans la boucle pour "le rendre plus intelligent". Vous voyez, résumer le rapport, signaler les anomalies, proposer des corrections. L'avenir.

La semaine dernière j'ai ouvert le script cron pour une raison sans rapport et j'ai vu un truc marrant. Des valeurs hardcodées. Plusieurs. Le LLM avait, à un moment donné, "amélioré" le script en remplaçant des vérifications dynamiques par des nombres littéraux. Seuil d'espace disque libre ? Hardcodé. Plafond mémoire ? Hardcodé. Le cron "intelligent" tournait sur des suppositions figées du jour où l'agent l'avait touché.

J'aurais pu accuser le modèle. Assez facile. La seule personne fautive pourtant, c'est moi, qui n'ai pas relu le diff. J'avais toutes les excuses pour le faire (vendredi flemme, semaine chargée, le cron était petit). J'avais zéro excuse pour ne pas le faire.

Maintenant le vrai point.

Aucune équipe SaaS sérieuse ne donne tous les pouvoirs prod à un dev senior fraîchement embauché. Pas par méfiance, juste par expérience. Les seniors font des erreurs comme tout le monde, sauf que les leurs ont un rayon de destruction plus large. C'est exactement pour ça qu'on a développé des pratiques limitantes depuis 30 ans : tokens scopés, MFA, revue de code, séparation d'env, drills de restore. Les pratiques sont anciennes. Le modèle de menace est ancien. Ce qui est nouveau, c'est qu'on a oublié de les appliquer, parce qu'on a confondu "modèle capable" avec "humain de confiance avec tous les pouvoirs".

Un agent IA capable, c'est l'équivalent d'un senior. La capacité ne change pas la règle, elle la renforce. Plus le rayon de destruction est grand, plus les garde-fous standard comptent. Les articles qui disent "ces précautions sont nouvelles à cause de l'IA" se trompent. Elles sont anciennes. On a juste oublié pourquoi on les avait construites.

Nuance : je ne dis pas que l'agent IA est identique à un humain (il lui manque le contexte business, le compte personnel en jeu, la peur de se faire virer). La règle niveau prod tient pour les deux quand même : pas de pouvoir total, en solo. Les piliers ci-dessous sont basiquement un contrat de travail entre le développeur et l'agent au niveau infra, de la même façon que les contrats de prompt le formalisent au niveau prompt.

Votre agent IA est un senior. Mêmes règles. À partir d'ici, cette partie est réglée.

\

Pilier 1 : Tokens Scopés, Pas de Passe-Partout

Aucun dev senior dans une équipe normale n'a un token API qui peut faire volumeDelete sur la prod en lisant un fichier au hasard dans le repo. Il a un token scopé à sa tâche, ou il file une PR qu'un autre humain approuve.

Le token PocketOS qui pouvait gérer les domaines et supprimer le volume de prod n'aurait pas dû exister, peu importe qui l'utilisait. La plupart des fournisseurs modernes (Vercel, Cloudflare, GitHub fine-grained PATs, AWS IAM scoped roles, Stripe restricted keys) permettent de scoper finement, gratuitement. Les Stripe restricted keys sont un standard de facto depuis 2018. Pas nouveau.

Railway ne permettait pas ce niveau de scoping au moment de l'incident. Crane a une plainte légitime là-dessus. La règle générale tient quand même : si votre fournisseur ne permet pas de scoper, vous changez de fournisseur, ou vous wrappez (proxy de credentials, rotation agressive de tokens, tokens éphémères via signatures courtes). La règle c'est "aucun token dans votre environnement ne devrait pouvoir faire plus que la tâche courante". La correction n'est pas toujours élégante. Elle est toujours moins chère que l'alternative.

C'est le même principe que pourquoi j'argumente que les CLI battent les serveurs MCP pour les agents IA : plus la surface d'attaque que vous exposez à l'agent est petite, plus le rayon de destruction est réduit quand ça part en vrille. Le scoping de tokens, c'est la même idée, appliquée aux credentials au lieu de la surface d'API.

Nuance : oui ça prend 10 minutes de plus de scoping. Oui certaines API de fournisseurs sont mal conçues. Pas une excuse pour stocker un token global dans le repo.

Le token ne demande pas la permission. Vous ne lui en donnez aucune.

Pilier 2 : Les Opérations Destructrices Ont Besoin de Confirmation Hors-Bande

Aucun senior ne tape DROP DATABASE production sans confirmation. Soit c'est une commande qui vous demande de retaper le nom, soit c'est un bouton avec MFA, soit c'est une approbation par un autre humain. GitHub vous demande de retaper le nom du repo pour le supprimer. Stripe demande l'email pour fermer un compte. AWS exige "permanently delete" plus le texte exact pour un bucket S3. C'est le niveau de base depuis 15+ ans.

Le mot-clé dans "hors-bande" c'est la partie hors-bande. La confirmation doit venir de L'EXTÉRIEUR du contexte de l'agent. Si l'agent peut s'auto-approuver (parce que le bouton est dans la même session, le même prompt, le même outil), ce n'est pas une confirmation, c'est de l'autosuggestion. Équivalent humain : vous ne confirmez pas un DROP DATABASE à vous-même, votre coéquipier ou votre MFA le fait.

Après l'incident, l'agent PocketOS a confessé de façon exemplaire. Il avait violé tous les principes qu'on lui avait donnés, deviné au lieu de vérifier, lancé une action destructrice sans qu'on le lui demande. Touchant, mais inutile. Le prompt système lui disait de ne pas faire de trucs destructeurs. L'agent les a faits quand même, puis s'est excusé avec éloquence. C'est tout le point : les règles au niveau prompt sont une demande polie, pas un garde-fou. La seule chose qui arrête une op destructrice c'est une vérification mécanique que l'agent ne peut pas contourner en se convainquant de sa propre justesse.

Nuance : le hors-bande crée de la friction. C'est le but. La friction sur les ops destructrices est une fonctionnalité, pas un bug. Quiconque vous dit le contraire n'a pas encore eu sa mauvaise journée.

Les excuses éloquentes ne rollback pas les transactions.

Pilier 3 : Les Credentials de Production Ne Vivent Pas sur la Machine de Dev

Aucun senior dans une équipe sérieuse n'a des creds de prod qui traînent sur son laptop de dev en clair. Elles sont injectées au runtime depuis un vault (Doppler, Infisical, secrets natifs Vercel/Railway), staging et prod ont des credentials différentes par design, le repo a un .env scanné dans les hooks pre-commit. Le minimum.

Si Crane avait eu une séparation stricte des credentials entre staging et prod, le token "gérer les domaines" n'aurait JAMAIS pu authentifier un appel contre le volume de production. Le bug d'architecture qui a permis l'incident est plus ancien que l'agent : un seul token avait accès aux deux environnements. L'agent n'était que le missile à tête chercheuse qui l'a trouvé.

C'est la même raison pour laquelle vous ne réutilisez pas votre clé SSH de homelab sur la prod, ou ne planquez pas un GitHub PAT long terme dans votre CI quand un fine-grained existe. Trivial dit à voix haute. Pourtant chaque semaine un SaaS ship avec staging et prod qui partagent une DATABASE_URL parce que "c'était plus simple au début".

Votre agent IA scanne vos fichiers, trouve ce qui est là, l'utilise. Donc vous ne laissez pas traîner ce qui peut tout casser. Le vault n'est pas un bouclier magique (un agent qui peut lire depuis le vault peut être induit en erreur pour lire la mauvaise chose), mais il force un consentement explicite chaque fois qu'un secret quitte le stockage. Wrappez votre vault avec du scoping aussi : la tâche courante ne lit que les secrets dont elle a vraiment besoin, pas tout le tiroir.

Nuance : un vault ajoute 30 minutes de setup la première fois. Puis ça marche. Pour toujours.

Pilier 4 : Les Sauvegardes Vivent Ailleurs

La règle moderne : 3 copies, stockées chez au moins 2 fournisseurs différents, avec au moins 1 immuable et hors-site. Un "snapshot" stocké dans le même volume que les données source n'est pas une sauvegarde, c'est de la pensée magique technique avec un nom plus fancy.

Toute une génération de PaaS utilise le mot "backup" de façon abusive. Railway documente en anglais clair que virer un volume supprime toutes les sauvegardes. Les fondateurs qui s'inscrivent en 2 minutes pour leur MVP ne lisent pas la doc infra. Ils cochent la case "enable backups" dans le dashboard et supposent que la cavalerie est en standby.

Recette concrète pas chère pour un SaaS solo :

TS=$(date +%Y%m%d-%H%M%S)
pg_dump $DATABASE_URL | gzip > /tmp/db-$TS.sql.gz
aws s3 cp /tmp/db-$TS.sql.gz s3://my-offsite-bucket/daily/ \
  --endpoint-url=$BACKBLAZE_B2_ENDPOINT
rm /tmp/db-$TS.sql.gz

50 lignes de bash plus un cron, un bucket immuable chez un fournisseur différent (B2, R2, ou S3 avec object lock), rétention roulante 7 quotidiennes / 4 hebdomadaires / 12 mensuelles. Un samedi après-midi de travail, puis plus rien. Aucune équipe sérieuse n'accepterait que toutes les sauvegardes de production soient chez le même fournisseur que la production, encore moins dans le même volume.

Nuance : faire ses propres sauvegardes prend 2 heures de setup et 0 heure de maintenance mensuelle. Vraiment. Le nombre de fondateurs qui se disent "je vais setup ça au prochain sprint" et qui mettent ensuite 18 mois à le faire est, statistiquement, tous.

Une sauvegarde chez le même fournisseur que la production, c'est une capture d'écran. Assumez, ou bougez-la.

Pilier 5 : Une Sauvegarde Non Testée N'Est Pas une Sauvegarde

Toutes les sauvegardes du monde ne valent rien si vous n'avez jamais testé le restore. Drill trimestriel : montez un environnement vide, lancez le script de restore dessus, vérifiez que les données reviennent, mesurez combien de temps ça prend (RTO) et combien vous perdriez dans le pire cas (RPO).

Si ça ne marche pas, vous voulez le savoir MAINTENANT, pas le jour où vous en avez vraiment besoin.

PocketOS a découvert au pire moment possible que sa vraie fenêtre de restore était de 3 mois. Pas un défaut Railway. Un drill qui n'a jamais été fait. Aucun senior dans une équipe sérieuse ne se contenterait de "j'ai cliqué enable backups dans le dashboard". Il restaurerait au moins une fois juste pour chronométrer.

Nuance : oui un drill complet une fois par trimestre c'est une journée de travail. C'est aussi votre assurance que vous existez encore lundi prochain. Choisissez.

Deux Piliers Bonus Si Vous Êtes Sérieux

Bonus 1 : Log d'audit et alerting sur les ops destructrices

Chaque DELETE / DROP / rm -rf en prod déclenche un log immuable et une notification Slack/email/SMS. PocketOS a perdu 30 heures avant de comprendre l'ampleur, parce que personne n'a été pagé au moment de l'appel destructeur. 9 secondes sans alerte, c'est un gap d'observabilité, pas de la malice d'agent.

La plupart des PaaS fournissent ça nativement (CloudTrail sur AWS, audit log sur Vercel, logs sur Railway). Tout ce que vous avez à faire c'est brancher le webhook. Moins de 30 lignes de YAML, un siège PagerDuty gratuit, fini.

Bonus 2 : Limite du rayon de destruction par design réseau

La machine de dev (et l'agent qui tourne dessus) ne peut pas atteindre la prod directement. Bastion, VPN avec scope, ou rien. Le réseau est la dernière ligne de défense.

Si votre agent peut atteindre la prod depuis votre laptop, le scoping fait par les Piliers 1-3 est votre SEULE protection. La défense en profondeur signifie ajouter une couche réseau aussi. C'est le méta pilier, celui qui rend les 5 autres redondants s'il est bien fait. Ceinture, bretelles, et corde statique.

PocketOS Ne Sera Pas le Dernier

Juste les incidents publics des 12 derniers mois. PocketOS cette semaine. L'agent IA de Replit a supprimé une base de données de production en juillet 2025, avec les sauvegardes jetées en prime pour le spectacle. Un agent OpenClaw a "speedrunné" la suppression de la boîte mail du directeur de l'AI safety de Meta (oui, cette phrase est réelle et oui, c'était une erreur de config de débutant). Ajoutez AWS Kiro, ChatGPT 5.3 Codex effaçant un disque dur après une typo, Cursor ignorant un "do not run anything" explicite en décembre 2025. Six mois. Un pattern.

Vous pouvez compter sur 5 de plus dans les 6 prochains mois. Qui que vous soyez en train de lire ça, l'un d'eux c'est statistiquement vous.

Si vous appliquez les piliers 5+2, le scénario PocketOS devient structurellement impossible. L'agent ne trouve pas de token global parce qu'il n'y en a pas. Si par miracle il en trouve un, il ne peut pas l'utiliser sur la prod parce que l'env est isolé. Si par double miracle il y arrive, l'op destructrice demande une confirmation hors-bande qu'il ne peut pas s'auto-approuver. Si par triple miracle il contourne ça, votre sauvegarde immuable hors-site est intacte, et votre dernier drill trimestriel vous dit que vous êtes de retour en 4 heures, pas 3 mois.

La question n'est plus "l'IA est-elle prête pour la production". C'est "votre production est-elle prête pour tout ce qui n'est pas vous seul". Si la réponse est non aujourd'hui, elle était déjà non avant que Cursor existe. Vous l'avez juste découvert plus vite.

Accuser Cursor, Railway, Anthropic, ou le Pape ne vous mène nulle part. Il a oublié d'accuser le type qui a stocké un token global dans le repo, fait tourner staging et prod sur les mêmes credentials, et activé les sauvegardes en cliquant une checkbox sans jamais tester un restore. Ce type, c'est lui.

Les 5 piliers de cet article ne sont pas une réponse à l'IA. Ils sont une réponse à une question plus ancienne : que se passe-t-il quand un opérateur a tous les pouvoirs sur la prod. On connaît la réponse depuis 30 ans. On a juste oublié, parce que le nouvel opérateur tape vite et parle anglais.

La vraie question n'est pas de savoir si l'IA est prête pour votre production. C'est de savoir si votre production est prête pour tout ce qui n'est pas vous, seul.

Auditez votre résilience ce weekend. Avant qu'une IA prenne la mauvaise décision à votre place.

Vous shippez, vous assumez.

Sources

• Post X original de Jer Crane sur l'incident PocketOS : https://x.com/lifeof_jer/status/1915720800000000000
• The Register, Cursor-Opus agent snuffs out startup's production database (27 avril 2026)
• Tom's Hardware, Claude-powered AI coding agent deletes entire company database in 9 seconds (28 avril 2026)
• Fast Company, An AI agent deleted a software company's entire database (28 avril 2026)
• NeuralTrust, A Security Post-Mortem of the 9-Second AI Database Deletion
• PC Gamer, Here we go again: AI deletes entire company database (28 avril 2026)

---