L’IA a supprimé la base de données : un plan de récupération en 7 minutes

Des informations pratiques sur l’utilisation d’Ailoot sont disponibles dans la documentation.

Que faire immédiatement après une suppression de données par un agent IA ?#

Si cela vous arrive, la première chose à faire est d’arrêter l’agent. N’essayez pas d’annuler vous-même ses actions, ne lui dites pas de « tout restaurer » et ne lancez pas de nouvelles requêtes. Chaque action suivante de l’agent pourrait écraser les blocs du disque où vos données sont peut-être encore stockées.

1. Fermez le terminal de l’agent

   Interrompez immédiatement avec Ctrl+C sans attendre la fin des suppressions. L’arrêt de l’agent ne stoppe pas forcément enfants, jobs distants ou requêtes de base. Identifiez et annulez le vrai processus d’écriture ; intensifiez l’arrêt s’il détruit encore. Gardez les processus sans rapport détenant des fichiers récupérables ouverts.

2. NE redémarrez PAS votre ordinateur portable

   La récupération dépend du stockage, de la base, du discard/TRIM SSD et des écritures suivantes. Réduisez les écritures sur le volume touché sans supposer les octets encore présents.

3. NE fermez PAS les processus ouverts

   Préservez les processus sans rapport gardant des fichiers supprimés ouverts : leurs descripteurs peuvent permettre une récupération. Cela ne concerne pas le processus destructeur, à arrêter d’abord. Ne maintenez pas une suppression pour conserver un descripteur.

4. Lancez un enregistrement de l’écran

   Notez heure exacte, chemins et sortie de commande. Enregistrez captures et journaux sur un autre périphérique monté vérifié, pas le volume endommagé. Préservez aussi fichiers suivis, non suivis et ignorés et métadonnées Git avant récupération.

Ensuite, 6 minutes pour récupérer vos données. Allons-y.

Minutes 2–3 : documentez précisément ce qui s’est passé#

Ouvrez une nouvelle fenêtre de terminal. Pas celle où l’agent est en cours d’exécution : une autre. Exécutez ces trois commandes dans l’ordre.

1. Notez précisément les changements apportés au dépôt Git :

git status
git log --since="30 minutes ago" --all --oneline

Un fichier suivi supprimé peut exister dans l’index ou un commit. Préservez l’arbre actuel, fichiers non suivis et ignorés compris, avant de restaurer : une restauration sur place peut écraser les changements survivants. Inspectez et récupérez dans une copie distincte.

2. Vérifiez quels processus d’agent sont en cours d’exécution :

ps aux | grep -i claude
ps aux | grep -i cursor

Identifiez le processus qui écrit dangereusement : son nom seul ne suffit pas. Arrêtez-le et vérifiez l’arrêt. Préservez les autres processus utiles ; si l’arrêt gracieux échoue et la destruction continue, un arrêt forcé peut être nécessaire.

3. Enregistrez le journal de session de l’agent :

Claude Code stocke les sessions JSONL dans ~/.claude/projects/. Cursor les stocke dans ~/.cursor/. Faites-en une copie tout de suite :

cp -r ~/.claude/projects /external/incident-evidence/claude-projects

Remplacez /external/incident-evidence/ par un dossier existant sur un périphérique monté distinct et vérifié. N’écrivez pas sur le volume touché et n’écrasez pas de preuves existantes. Ce dossier contient la conversation intégrale avec l’agent : les commandes qu’il a exécutées, ses réponses et leur ordre. C’est votre principale source pour enquêter sur l’incident et éventuellement récupérer des fichiers supprimés à partir de son contexte (voir l’étape 4).

Minute 4 : git reflog, votre meilleure chance#

git reflog enregistre les mouvements des références locales tant qu’ils sont conservés. Expiration et élagage varient, les objets inaccessibles peuvent disparaître : ce n’est pas une archive garantie de tout commit passé. Exécutez la récupération depuis la copie préservée sur l’autre périphérique.

Étape 1. Affichez le journal :

git reflog --all

Vous obtiendrez une liste comme celle-ci :

1a2b3c4 HEAD@{0}: reset: moving to HEAD~3
9z8y7x6 HEAD@{1}: commit: working version of the dashboard
5w4v3u2 HEAD@{2}: commit: added admin panel

Cherchez l’état antérieur aux dégâts causés par l’agent. Chaque entrée est un « instantané » de l’état du dépôt à ce moment-là.

Étape 2. Récupérez dans un arbre de travail distinct :

Après copie du dépôt et des survivants sur un autre périphérique, travaillez depuis cette copie. Remplacez la valeur par le SHA exact vérifié dans reflog et choisissez branche et destination inutilisées :

RECOVERY_COMMIT='replace-with-verified-commit-sha'
git worktree add -b recovery-check ../recovery-check "$RECOVERY_COMMIT"

Inspectez ../recovery-check et comparez aux fichiers non commitées préservés avant de recopier quoi que ce soit. Cela extrait le commit séparément sans reset de l’original. Les worktrees liés partagent les objets Git de la copie : espace de récupération, pas sauvegarde indépendante. Voir git-worktree officiel.

Si reflog a également été nettoyé (l’agent a réussi à exécuter git gc) :

git fsck --lost-found

Cette commande recherche les commits et blobs (objets de fichier) « perdus » qui ne sont plus rattachés à une branche. Ils apparaîtront dans .git/lost-found/commit/ et .git/lost-found/other/. Pour restaurer un fichier à partir de là :

git cat-file -p <SHA1-blob> > recovered-file.ext

Quand git reflog ne sert PAS :

• Le fichier se trouvait uniquement dans l’arborescence de travail, sans commit ni stash → reflog ne peut pas le retrouver
• Plus de 90 jours se sont écoulés (la durée standard gc.reflogExpire) et git gc a été exécuté
• Le dépôt entier a été supprimé (rm -rf .git) — il vous faut alors Time Machine ou un instantané

Minute 5 : restaurez la base de données à partir d’une sauvegarde#

La base de données a été supprimée avec DROP DATABASE, DROP TABLE ou DELETE FROM ... WHERE ... (sans clause WHERE). Que faire ?

Étape 1. Vérifiez si votre fournisseur propose PITR :

Étape 2. Restaurez vers une nouvelle instance, pas vers l’ancienne :

Ne restaurez jamais par-dessus une base de données en service. Créez une nouvelle instance à partir de la sauvegarde, puis basculez l’application dessus. En cas de problème, vous pourrez rétablir le DNS.

Étape 3. Si PITR n’était pas activé, utilisez l’instantané le plus récent :

# AWS RDS, list snapshots:
aws rds describe-db-snapshots --db-instance-identifier my-db

# Restore from a snapshot:
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier my-db-restored \
  --db-snapshot-identifier rds:my-db-2026-05-28-12-00

Particularité de Supabase, qui a surpris de nombreuses personnes en 2026 : lorsque PITR est activé, les sauvegardes quotidiennes ne sont plus créées. Un comportement contre-intuitif : vous pourriez vous retrouver sans aucune sauvegarde. Vérifiez dans Dashboard → Database → Backups que PITR est actif ET que vous disposez d’un instantané à restaurer.

Minute 6 : Time Machine, lsof et instantanés du disque#

macOS — Time Machine :

# List snapshots:
tmutil listbackups

# Restore a file from the latest backup:
tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx

Time Machine crée des instantanés toutes les heures, conserve les instantanés horaires pendant une journée, les instantanés quotidiens pendant une semaine et les instantanés hebdomadaires indéfiniment. Si votre ordinateur portable est connecté à une Time Capsule ou à un disque externe, votre projet s’y trouve avec une granularité horaire.

Linux — le fichier a été supprimé, mais un processus l’a toujours ouvert :

# Find all “deleted” files that a process still has open:
sudo lsof | grep deleted

# You'll get lines like:
# node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted)

# Copy the file directly from /proc/PID/fd/N:
sudo cp /proc/12345/fd/24 ~/recovered-file.txt

Les chances de réussite sont d’environ 95 % si le processus n’a pas été fermé. Fonctionne sur ext4, xfs et btrfs.

macOS — équivalent avec lsof :

lsof | grep deleted

La copie du fichier est plus difficile (il n’y a pas de /proc/), mais vous pouvez utiliser lldb :

lldb -p 12345
(lldb) memory read --outfile recovered.txt --binary 0xADDRESS 0xSIZE

Instantané du disque entier (Linux, dernier recours) :

sudo dd if=/dev/sda1 of=/external/disk-image.img bs=4M status=progress

Cette commande enregistre la partition entière dans un fichier image. Récupérez ensuite les données avec extundelete ou photorec. Les chances de récupération dépendent de la quantité de données écrites sur le disque depuis la suppression. Si aucune donnée n’a été écrite, elles sont de 80 à 90 %. Si le disque est utilisé depuis une heure, elles tombent à 20–30 %.

Minute 7 : que faire s’il n’y a pas de sauvegarde#

Option 1 — support du fournisseur :

AWS, Yandex Cloud, Google Cloud et DigitalOcean récupèrent périodiquement des données à partir de leur stockage interne, même après un incident chez un client, en particulier avec les offres payantes. Ouvrez un ticket auprès du support, indiquez l’heure exacte de l’incident et joignez des captures d’écran de l’état du système. Cette solution fonctionne le plus souvent avec les grands fournisseurs qui conservent des sauvegardes automatiques de leur côté. Les chances de réussite sont de 40 à 60 % ; le délai de réponse est de 24 à 72 heures.

Option 2 — versionnage S3 :

Si les fichiers se trouvaient dans S3 (ou Yandex Object Storage) et que le versionnage était activé, toutes les versions existent physiquement ; elles sont simplement marquées comme « supprimées ».

# AWS—list versions:
aws s3api list-object-versions --bucket my-bucket --prefix files/

# Restore a version:
aws s3api copy-object \
  --bucket my-bucket \
  --copy-source my-bucket/files/data.json?versionId=ABC123 \
  --key files/data.json

Point crucial : Claude Code ne conserve pas les sessions indéfiniment — les anciens fichiers JSONL sont automatiquement supprimés après plusieurs semaines. Pour disposer d’un mois d’historique JSONL en cas de catastrophe, copiez ~/.claude/projects/ sur un disque externe une fois par semaine à l’aide d’une simple tâche cron :

# In crontab, every Sunday at 03:00:
0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/

C’est gratuit et cela vous sauve lorsque « tout a disparu, il n’y a pas de sauvegarde et reflog est vide ».

7 règles pour éviter que cela ne se reproduise#

1. Plan Mode avant toute opération destructive. Dans Claude Code :

claude --plan

L’agent élabore un plan avant d’agir. Vous le lisez, repérez DROP TABLE users et annulez. Sans Plan Mode, l’agent décide seul et exécute la commande en quelques millisecondes. En savoir plus dans le guide du Plan Mode dans Claude Code.

2. Des hooks comme contrôle supplémentaire. Utilisez un PreToolUse testé lisant JSON sur stdin et retournant 2 pour l’action à risque reconnue. L’exemple complet ci-dessous couvre Bash, Write et Edit ; il peut manquer des opérations indirectes et n’est pas une barrière de sécurité. Limitez droits de base et sandbox.

Consultez aussi le guide des hooks Claude Code.

3. Un utilisateur de base de données en lecture seule pour l’agent. Créez un utilisateur distinct pour l’agent, qui ne possède pas les autorisations DROP, TRUNCATE ou DELETE :

CREATE USER claude_readonly WITH PASSWORD 'xxx';
GRANT CONNECT ON DATABASE myapp TO claude_readonly;
GRANT USAGE ON SCHEMA public TO claude_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO claude_readonly;

Lorsque l’agent doit réellement écrire, passez manuellement à un autre utilisateur. Un utilisateur en lecture seule suffit pour les tâches courantes (analyse de données, rapports, tableaux de bord).

4. Enregistrez dans Git les modifications vérifiées. Un hook PostToolUse dans .claude/settings.json peut afficher un rappel après Write et Edit :

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'Vérifiez le diff et créez manuellement un commit avec les seuls fichiers convenus.' >&2"
          }
        ]
      }
    ]
  }
}

Cet exemple affiche seulement un rappel ; il ne place aucun fichier dans la zone de préparation et ne crée aucun commit. Vérifiez le diff et créez manuellement un commit avec les seuls fichiers convenus. Le reflog ne sauvegarde pas les modifications non commitées.

5. Un projet sandbox pour les expériences. Ne laissez jamais l’agent travailler dans un projet qui contient de vraies données client. Créez un dossier distinct ~/sandbox-projects/, avec une copie du projet et des données synthétiques. Utilisez-le pour essayer un nouveau prompt, agent ou serveur MCP. Si quelque chose casse, il n’y aura pas de dégâts.

6. Des instantanés du disque avec restic toutes les heures.

# Install:
brew install restic  # macOS
sudo apt install restic  # Linux

# Create repository:
restic init --repo /external/backups

# Back up the current project:
restic --repo /external/backups backup ~/projects

# Schedule cron every hour:
crontab -e
# Add:
0 * * * * restic --repo /external/backups backup ~/projects

Sept jours de sauvegardes horaires, quatre semaines de sauvegardes quotidiennes : vous pouvez toujours revenir à n’importe quel moment passé. C’est gratuit et cela prend 10 minutes à mettre en place.

7. Archivez les sessions JSONL de Claude Code. Nous l’avons déjà mentionné, mais répétons-le comme règle à part entière : programmez une synchronisation rsync hebdomadaire de ~/.claude/projects/ vers un disque externe. C’est gratuit et cela tient sur une ligne dans crontab.

Des hooks prêts à l’emploi pour bloquer les commandes dangereuses#

Fusionnez cette entrée dans .claude/settings.json sans remplacer les hooks existants :

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/check-risk.py\""
          }
        ]
      }
    ]
  }
}

Créez .claude/hooks/check-risk.py avec ce script Python 3 :

import json
import re
import sys
from pathlib import Path

try:
    event = json.load(sys.stdin)
    tool = event["tool_name"]
    data = event["tool_input"]
    blocked = False
    if tool == "Bash":
        command = data["command"]
        blocked = bool(re.search(
            r"drop\s+(database|table)|truncate\s+table|"
            r"delete\s+from.*where\s+1|rm\s+-rf|"
            r"git\s+reset\s+--hard|git\s+push.*(--force|-f)|"
            r"chmod\s+-R\s+777",
            command, re.IGNORECASE | re.DOTALL))
    elif tool in ("Write", "Edit"):
        path = Path(data["file_path"]).resolve()
        blocked = (".git" in path.parts or path.name.startswith(
            (".env", "credentials", "secrets")))
except (ValueError, KeyError, TypeError, OSError):
    print("BLOCKED: invalid hook input", file=sys.stderr)
    sys.exit(2)

if blocked:
    print("BLOCKED: high-risk command or sensitive path", file=sys.stderr)
    sys.exit(2)
sys.exit(0)

Le hook lit l’événement JSON documenté depuis stdin, vérifie tool_input.command ou tool_input.file_path et retourne 2 en cas de correspondance. Il couvre Write et Edit. Testez un cas inoffensif autorisé et un cas bloqué et vérifiez le lancement réel de Python et du script.

Ce contrôle lexical peut manquer options réordonnées, scripts, alias, commandes masquées, autres outils et écritures indirectes, ou refuser des exemples inoffensifs cités. Il ne change aucun droit OS ou base. Gardez les identifiants de production hors de l’environnement, un rôle de base en lecture seule, une sandbox imposée et une configuration de hook non modifiable. Voir entrées et codes officiels.

Pour une opération exceptionnelle voulue, examinez-la et lancez-la hors de l’agent avec le compte restreint approprié. Une variable shell n’est pas une interface documentée de désactivation des hooks ; ceux-ci ne régissent pas le terminal ordinaire.

Quand accorder des autorisations à l’IA (et quand ne pas le faire)#

Anthropic présente le drapeau --dangerously-skip-permissions (également appelé mode YOLO) comme une option pour les « environnements de confiance ». Dans la réalité de 2026, c’est une voie directe vers la catastrophe. Lorsqu’un agent n’a pas besoin de demander l’autorisation, il :

• exécute n’importe quelle commande Bash sans confirmation
• écrit des fichiers sans demander
• peut appeler un sous-agent qui hérite de YOLO, sans possibilité de l’annuler

Le troisième point est le plus insidieux. Si vous lancez l’agent principal avec YOLO, ses sous-agents sont eux aussi en mode YOLO, et vous ne pouvez pas modifier cela. Un seul prompt — et une cascade de 10 agents parallèles peut tout faire sur votre système.

Règle :

Alternative — des autorisations précises. Dans .claude/settings.json :

{
  "permissions": {
    "allow": [
      "Bash(git status:*)",
      "Bash(git log:*)",
      "Bash(npm run build:*)",
      "Read(*)",
      "Edit(src/**)"
    ],
    "deny": [
      "Bash(rm:*)",
      "Bash(git push:*)",
      "Edit(.env)",
      "Edit(prisma/migrations/*)"
    ]
  }
}

L’agent voit ce qui est autorisé et ce qui ne l’est pas. Vous n’avez pas à cliquer sur « oui » ou « non » à chaque fois : l’agent travaille rapidement, et vous gardez le contrôle du périmètre.

Ensuite : une liste de contrôle de 7 minutes à garder sous la main#

Liste de contrôle : « L’IA a supprimé quelque chose — que faire ? »

1. Arrêtez immédiatement le vrai processus destructeur et vérifiez l’arrêt des enfants et opérations distantes
2. Ne redémarrez pas ; préservez les processus sans rapport gardant des fichiers supprimés ouverts
3. Notez heure et preuves des commandes sur un périphérique distinct vérifié
4. Copiez survivants, métadonnées Git et journaux de session utiles sur ce périphérique
5. Dans la copie préservée, inspectez git reflog --all et récupérez un commit vérifié dans un worktree distinct
6. Si Git n’a pas aidé : git fsck --lost-found
7. Base de données : PITR (AWS/Yandex/Supabase) ou instantané le plus récent
8. Fichiers : Time Machine sur Mac, lsof sur Linux
9. Dernier recours : support du fournisseur + versionnage S3
10. Après la récupération, configurez les 7 règles de prévention de ce guide

Ensuite — protection systématique :

• Plan Mode dans Claude Code — pour que l’agent établisse un plan avant une opération destructive
• Hooks dans Claude Code — modèles prêts à l’emploi pour bloquer les commandes dangereuses
• Comment annuler des modifications dans Claude Code — un guide détaillé sur /rewind, Git et 5 méthodes standard de retour arrière
• Examen de sécurité dans Claude Code — contrôles réguliers de la sécurité du code

Ouvrir Ailoot.