Le jour où j'ai effacé ma base de données (et comment Claude l'a sauvée)

Un vendredi après-midi. 17h30. Je suis fatigué mais je veux finir une petite tâche avant le week-end. Supprimer quelques utilisateurs de test de ma base de données (l'endroit où sont stockées toutes les données de mon application : utilisateurs, commandes, contenus...).

J'ouvre mon interface de base de données. Je tape ma requête SQL (le langage pour communiquer avec les bases de données). J'appuie sur Entrée.

En une seconde, 847 utilisateurs réels ont disparu.

Cette histoire a une fin heureuse. Mais elle aurait pu être catastrophique. Je te raconte ce qui s'est passé, pourquoi, et surtout comment t'assurer que ça ne t'arrivera jamais.

Ce Qui S'est Passé (La Boulette)

Je voulais supprimer les comptes de test. Ma requête aurait dû être :

DELETE FROM users WHERE email LIKE '%test%'

En français : "Supprime les utilisateurs dont l'email contient 'test'". Ce que j'ai tapé :

DELETE FROM users

En français : "Supprime TOUS les utilisateurs." J'ai oublié le WHERE. La clause WHERE, c'est le filtre qui dit "seulement ceux-là". Sans filtre... tout y passe. C'est une erreur classique. Tellement classique qu'il y a des mèmes sur internet. Mais quand ça t'arrive à toi, c'est pas drôle du tout.

Les 10 Premières Secondes (La Panique)

Au début, tu ne réalises pas. La requête s'exécute. Un message s'affiche : "847 rows affected" (847 lignes affectées). Pause. 847 ? J'ai pas 847 utilisateurs de test... Puis ton cerveau fait le calcul : - Pas de WHERE dans la requête - Table users - 847 = le nombre TOTAL de mes utilisateurs - Vendredi soir - Week-end qui commence Le sang se glace. Littéralement. J'ai senti mes mains devenir froides.

La Course Contre La Montre

Les 30 secondes suivantes ont été les plus longues de ma vie. Première pensée : "Ctrl+Z ? Non, ça marche pas comme ça avec les bases de données." Deuxième pensée : "Les backups ! Est-ce que j'ai des backups ?" J'utilise Supabase pour ma base de données. Supabase, c'est un service qui héberge ta base de données dans le cloud avec plein de fonctionnalités, dont des backups automatiques. Je me connecte au dashboard Supabase. Je cherche frénétiquement la section backups. Oui. J'avais activé les backups quotidiens quand j'ai créé le projet. À 3h du matin chaque jour. Soulagement partiel. J'ai perdu les données du jour (les inscriptions depuis 3h du matin), mais pas les 847 clients historiques.

La Restauration

La restauration a pris 30 minutes. Voici ce que j'ai fait : 1. Récupéré le backup du matin depuis le dashboard Supabase 2. Créé une nouvelle base de données temporaire avec ce backup 3. Exporté la table users du backup 4. Importé dans ma base de production (après avoir vérifié 3 fois) Si tu utilises Supabase, tu peux demander à Claude de t'aider :

Note : Les backups automatiques ne sont disponibles que sur les plans payants de Supabase (à partir du plan Pro). Sur le plan gratuit, tu dois faire tes propres backups manuels.

Le Bilan Des Dégâts

Ce que j'ai perdu :

• 15 inscriptions de la journée
• 3 heures de stress intense
• Ma confiance en moi (temporairement)
• Une nuit de sommeil (j'ai vérifié 10 fois que tout remarche)

Ce que j'ai évité grâce aux backups :

• La perte de 847 clients
• Des semaines à reconstruire les données
• Des emails d'excuse à envoyer
• Potentiellement la mort du projet

Les 15 utilisateurs perdus ? Je les ai contactés un par un pour m'excuser et leur demander de se réinscrire. Ils ont tous été compréhensifs. Les gens comprennent les erreurs humaines.

Les Règles Que Je M'impose Maintenant

Cette expérience m'a changé. Voici les règles que je suis religieusement depuis.

Règle 1 : Toujours avoir des backups

Pas "je vais configurer les backups un jour". Maintenant. Avant de continuer à lire cet article.

Si tu es sur le plan gratuit Supabase, fais des exports manuels réguliers :

Règle 2 : Tester le WHERE avant le DELETE

Avant de supprimer quoi que ce soit, fais d'abord un SELECT avec le même WHERE :

-- D'abord, je VÉRIFIE ce qui va être supprimé
SELECT * FROM users WHERE email LIKE '%test%'
-- Je regarde la liste, je vérifie que ce sont bien les bons
-- SEULEMENT ENSUITE je supprime
DELETE FROM users WHERE email LIKE '%test%'

Règle 3 : Ne jamais toucher à la prod le vendredi

Sérieusement. Cette règle existe pour une raison.

Le vendredi après-midi, tu es :

• Fatigué de la semaine
• Pressé de partir
• Moins concentré
• Plus susceptible de faire des erreurs

Et si quelque chose casse, ton week-end est foutu. Tu dois soit travailler le week-end, soit laisser le problème empirer jusqu'à lundi.

Ma règle maintenant : Vendredi après-midi = lecture de docs, planification, petites tâches sans risque. Les modifications de prod, c'est lundi à jeudi, le matin de préférence.

Règle 4 : Utiliser une base de test

Pour les manipulations risquées, utilise une copie de ta base. Jamais la prod directement.

Règle 5 : Transactions et ROLLBACK

Pour les opérations critiques, utilise des transactions. Une transaction, c'est comme un brouillon : tu peux annuler avant de valider.

BEGIN TRANSACTION;

DELETE FROM users WHERE email LIKE '%test%';

-- Tu regardes le résultat...
-- Si c'est bon :
COMMIT;
-- Si c'est pas bon :
ROLLBACK;

Le ROLLBACK annule tout ce que tu as fait depuis BEGIN TRANSACTION.

Comment Claude Peut T'aider

Claude ne peut pas restaurer une base de données effacée si tu n'as pas de backup. Personne ne peut. Mais il peut :

T'aider à configurer les backups AVANT la catastrophe

T'aider à écrire des requêtes sûres

T'aider à restaurer si tu as un backup

T'aider à créer des garde-fous

Les Signes Avant-Coureurs (Que J'aurais Dû Voir)

Avec le recul, tous les signaux étaient là :

• Fatigue : Vendredi soir après une semaine chargée
• Précipitation : "Je fais ça vite fait et je pars"
• Environnement de prod : Pas de filet de sécurité
• Pas de vérification : J'ai exécuté directement sans relire

Maintenant, avant toute opération sur la base de prod, je me pose 3 questions :

1. Suis-je fatigué ou pressé ? → Si oui, je remets à demain
2. Ai-je vérifié la requête avec un SELECT ? → Si non, je fais le SELECT d'abord
3. Ai-je un backup récent ? → Si non, je fais un backup d'abord

Ce Que J'aurais Perdu Sans Backups

Calculons le coût de cette erreur sans les backups :

• 847 clients : À 50 EUR de panier moyen = 42 350 EUR de revenus potentiels perdus
• Réputation : Combien de clients auraient publié leur mécontentement ?
• Temps de reconstruction : Combien d'heures pour retrouver les emails, recontacter tout le monde ?
• Moral : L'impact psychologique de tuer son projet par erreur

Les backups m'ont coûté... 25 EUR/mois (le coût du plan Pro Supabase).

ROI du backup : 42 350 EUR sauvés / 25 EUR de coût = 1 694x

C'est le meilleur investissement que j'ai jamais fait.

La Checklist Avant Toute Opération Dangereuse

Je me suis créé une checklist que je suis religieusement :

• [ ] Je ne suis pas fatigué/pressé/distrait
• [ ] J'ai un backup de moins de 24h
• [ ] J'ai testé sur une base de dev d'abord
• [ ] J'ai fait un SELECT pour voir ce qui sera affecté
• [ ] J'utilise une transaction (BEGIN/COMMIT/ROLLBACK)
• [ ] Quelqu'un d'autre a relu ma requête (si opération critique)
• [ ] Je sais comment restaurer si ça échoue

---

Pour Aller Plus Loin

Cette histoire a bien fini grâce aux backups. La tienne peut bien finir aussi. Mais seulement si tu configures les backups AVANT d'en avoir besoin.

Ce n'est pas une question de "si" tu feras une erreur, mais de "quand". Tout le monde finit par faire une boulette un jour. La différence entre une anecdote et une catastrophe, c'est d'avoir préparé le plan B.

Fais-le maintenant. Pas demain. Maintenant.

Pour ceux qui veulent aller plus loin : on a créé le Workshop "Bâtir avec l'IA".

Articles connexes pour sécuriser tes projets :

• Le fichier .claudeignore : ne donnez pas vos mots de passe : protège tes données sensibles
• Git pour les nuls : sauvegarder votre travail : le versionnement de code, ton autre filet de sécurité
• Oubliez Excel : créez une vraie base de données : bien démarrer avec les bases de données

— Charles