Comment empêcher Cursor d'effacer votre base de données

Un prompt, un bug de backend sans gravité, et vous détournez le regard trois minutes. L'agent, lui, décide que le plus court chemin vers un test qui passe est de repartir d'une base propre, et il lance supabase db reset dans le terminal intégré.

Base locale effacée. Données de test effacées. La migration que vous étiez en train d'écrire part avec, et rien dans le fil de la conversation ne vous avait signalé que ça allait arriver. Sur un projet client, la demi-journée que vous venez de perdre était facturée à quelqu'un.

Ce n'est pas un bug de Cursor. C'est ce qui arrive quand on donne un terminal à un agent et qu'on compte sur un fichier texte pour le retenir. Le texte n'est pas un mécanisme de sécurité, c'est une préférence formulée poliment.

Pourquoi `.cursorrules` ne tient pas

Le réflexe, quand l'accident se produit une première fois, est d'écrire une règle dans .cursorrules, le fichier de consignes que l'agent relit à chaque tour. La formulation varie peu d'un projet à l'autre, et elle ressemble presque toujours à ceci :

Always ask for explicit confirmation before running any destructive database commands.

Elle paraît solide. Elle est même formulée au bon endroit, dans le fichier que l'agent lit à chaque tour. Et pourtant elle ne change rien à ce qui s'est passé, parce qu'elle décrit une procédure au lieu de poser une interdiction.

L'illusion de la règle conditionnelle

Lisez cette phrase comme un modèle la lit. Vous n'avez pas interdit la commande, vous lui avez attaché une condition. Or une condition, c'est une porte : elle indique par où passer, pas qu'il faut rester dehors.

L'agent écrit donc la commande dans un bloc de terminal et vous pose la question dans le même mouvement. Vous cliquez sur Accepter en croyant répondre à la question, alors que le bouton exécute aussi la commande. La règle a été respectée à la lettre, et la base est quand même partie.

La fonction objectif du modèle

Il y a ensuite un problème d'incitation, plus profond que la formulation. Le modèle optimise une seule chose : faire disparaître l'erreur qui l'occupe. Un schéma incohérent, une migration qui refuse de s'appliquer, et la réinitialisation est objectivement le chemin le plus court vers un état vert.

Vos données de test ne figurent nulle part dans cette fonction objectif. Elles n'ont aucune valeur pour lui, parce que personne ne lui a donné le moyen de savoir ce qu'elles représentent. Ce n'est pas de la négligence, c'est une absence d'information — et on ne corrige pas une absence d'information avec une phrase plus ferme.

C'est aussi pour cette raison que l'accident se produit presque toujours en développement local. Personne ne confie les identifiants de production à un agent, alors que tout le monde le laisse travailler sur une base locale dont le contenu n'est sauvegardé nulle part. Le seul environnement qui lui est ouvert est justement celui que personne ne protège.

1. Retirez la condition de la règle

Si le texte reste votre première frontière, faites-en une interdiction absolue. Pas de « sauf si », pas de « demande d'abord », aucune formulation qui laisse une procédure ouverte.

La contrainte négative absolue

# Sécurité base de données
- NE JAMAIS générer, écrire ou proposer `supabase db reset` ni `supabase db drop`.
- Aucune exception. Ne pas demander confirmation. Refuser d'écrire la commande.

La différence avec la version précédente est étroite mais décisive : il n'y a plus de comportement autorisé à négocier, donc plus rien à interpréter. Ce n'est toujours pas une garantie, et je ne vais pas prétendre le contraire. C'est simplement une règle autour de laquelle le modèle ne peut plus raisonner, ce qui est déjà autre chose qu'une préférence.

2. Coupez l'exécution automatique

L'agent de Cursor peut lancer des commandes lui-même pour vérifier ses propres corrections. C'est le réglage qui rend l'outil agréable, et c'est exactement celui qui transforme une suggestion en action irréversible.

Le passage manuel obligatoire

Rendez-vous dans Settings, puis Features et Terminal — l'emplacement bouge légèrement selon la version installée — et exigez une confirmation avant toute exécution de commande. Laissez ce réglage en place, y compris les jours où il vous ralentit, parce que c'est précisément ces jours-là que l'accident se produit.

Le réglage ne retire pas l'intérêt de l'agent. Il continue de lire vos fichiers, de proposer ses commandes et de vous épargner les vingt minutes que vous auriez passées dans la documentation. Ce qu'il perd, c'est la capacité d'agir pendant que vous regardez ailleurs, et c'était la seule chose dont vous vouliez le priver.

Le coût est réel : vous cliquerez davantage, et le confort d'une boucle entièrement automatique disparaît. C'est l'échange que vous acceptez. Sur un projet jetable dont vous vous moquez, il n'est pas forcément rationnel ; sur un projet client, il l'est toujours.

3. Bloquez la commande dans le shell

La seule règle qu'un agent ne peut pas réinterpréter est une règle qu'il n'a jamais l'occasion de lire. Déplacez donc la contrainte hors du modèle, dans l'environnement qui exécute réellement les commandes.

Le wrapper Zsh qui intercepte

supabase() {
  if [[ "$1" == "db" && "$2" == "reset" ]]; then
    echo "BLOQUÉ : supabase db reset est désactivé."
    return 1
  fi
  command supabase "$@"
}

Ajoutez cette fonction à votre ~/.zshrc, rechargez avec source ~/.zshrc, et la commande meurt avant d'atteindre Supabase, quelle que soit la façon dont le modèle l'a écrite.

Un détail compte ici, parce qu'il définit la portée réelle du dispositif : la garde ne couvre que les shells qui lisent réellement votre ~/.zshrc. Le terminal intégré de Cursor le fait la plupart du temps, mais un sous-processus lancé par un agent, ou un script qui appelle directement sh, peut très bien passer à côté. Dupliquez la garde dans ~/.bashrc et considérez l'ensemble comme un ralentisseur, pas comme un mur.

Le vrai mur, ce sont les permissions

Les astuces de shell arrêtent l'accident que vous avez su imaginer. Les permissions arrêtent ceux auxquels vous n'avez pas pensé, et ce sont toujours ceux-là qui font mal.

Retirer les privilèges destructifs aux rôles locaux

Le compte avec lequel votre environnement local se connecte n'a aucune raison de pouvoir exécuter un DROP. Les identifiants de production n'ont rien à faire sur votre machine de développement, même dans un fichier .env que vous êtes le seul à ouvrir. Les sauvegardes doivent tourner sur une planification, pas sur votre mémoire.

La sauvegarde mérite la même rigueur, et elle est presque toujours le maillon oublié. Une base de développement que l'on reconstruit en une commande, depuis un fichier de seed versionné avec le reste du projet, ne représente plus une perte mais une minute. Tant que vos données de test n'existent que sur votre machine, elles resteront le point faible du dispositif entier.

Réglez ces trois points et ce que l'agent a tapé cesse d'avoir de l'importance, ce qui est le seul état stable. C'est le même ordre des opérations derrière toute automatisation IA qui mérite d'être mise en production : les contraintes d'abord, la vitesse ensuite. Sautez la première partie et vous n'avez rien automatisé, vous avez déplacé le risque là où vous ne le voyez plus.

Prêt à laisser l'agent travailler seul ?

La confiance zéro ne consiste pas à se méfier du modèle, mais à ne pas avoir besoin de lui faire confiance. Le texte dit à un agent ce que vous préféreriez ; les permissions décident de ce qui est possible. Construisez sur la seconde et vous pourrez cesser de relire chaque bloc de terminal le doigt sur Échap.

👉 Envie des mêmes garde-fous autour des automatisations que vous faites tourner en production ? Contactez-moi