Requête SQL qui supprime des données : la repérer

Pour interroger une base, une requête SQL (langage de requête structuré) n'a besoin que de lire. Elle commence alors par SELECT (parfois par WITH, qui prépare un calcul avant un SELECT). Si vous voyez DELETE, UPDATE, INSERT, DROP, TRUNCATE ou ALTER, la requête ne lit pas : elle modifie ou supprime. Ne la lancez pas. Ce réflexe, plus un compte en lecture seule, suffit à écarter l'essentiel du risque.

Les mots qui modifient la base

Ces mots peuvent apparaître au milieu d'une longue requête. Cherchez-les partout, pas seulement au début.

Pourquoi le filtre absent est le pire scénario

La documentation de PostgreSQL est claire sur DELETE : si la clause WHERE est absente, toutes les lignes de la table sont supprimées. Il reste une table valide, mais vide. Elle donne même l'exemple DELETE FROM films; pour « vider la table films ». Elle ajoute que TRUNCATE est un moyen plus rapide de faire la même chose.

Pour UPDATE, PostgreSQL indique que la commande modifie les colonnes indiquées dans toutes les lignes qui satisfont la condition. Sans condition, aucune ligne n'est écartée : toute la table est concernée. Un exemple illustratif :

UPDATE clients SET remise = 0.10;

Cette ligne donne 10 % de remise à tous vos clients, alors que l'intention était peut-être d'en viser un seul.

Dans Access : les requêtes d'action

Access appelle « requêtes d'action » celles qui changent les données. L'aide Microsoft en décrit quatre : Création de table (et, si une table du même nom existe, Access la supprime), Ajout, Mise à jour et Suppression. Elle prévient dans un encadré : « Une requête d'action ne peut pas être annulée. » Elle conseille donc de sauvegarder les tables concernées avant une mise à jour. Avant d'exécuter une requête Mise à jour, l'aide indique qu'on peut prévisualiser les valeurs concernées en mode Feuille de données : faites-le.

Les détails pour Access sont dans créer une requête Access.

Avec un assistant IA

Un assistant qui interroge votre base agit avec les droits du compte qu'on lui a donné. Deux exemples tirés de la documentation des éditeurs :

• Airtable indique qu'Omni peut créer, modifier et supprimer des enregistrements, qu'il demande une confirmation avant toute suppression, et qu'il peut annuler ses propres modifications sur demande. Les propriétaires d'une base peuvent aussi interdire la création, la modification et la suppression de données aux personnes qui n'ont accès qu'aux interfaces. Voir notre fiche Airtable.
• Metabase indique que Metabot génère le SQL sans l'exécuter. Vous avez donc le temps de vérifier qu'il commence par SELECT.

Une confirmation demandée par l'outil ne remplace pas votre lecture : lisez ce qui va être supprimé avant de valider.

Les trois garde-fous

1. Un compte en lecture seule pour interroger. Un compte qui n'a que le droit de lire ne peut rien supprimer, même si la requête le demande : la base refuse. C'est la protection la plus efficace, et elle se demande à votre prestataire. Voir demander un accès en lecture seule.
2. Une sauvegarde récente et testée. La CNIL (Commission nationale de l'informatique et des libertés) recommande des sauvegardes fréquentes, au moins une copie hors ligne et sur un site distinct, et des tests réguliers de restauration. Une sauvegarde jamais restaurée est une promesse, pas une protection.
3. Une règle simple dans l'équipe : aucune requête qui ne commence pas par SELECT n'est lancée sans qu'une deuxième personne l'ait lue.

Si une requête de modification a été lancée par erreur

• Arrêtez toute nouvelle opération sur la base.
• Notez l'heure, la requête exacte et le compte utilisé.
• Prévenez la personne qui gère vos sauvegardes ou votre prestataire : c'est elle qui saura si une restauration est possible et à partir de quand.

Pour vérifier une requête de lecture, l'autre moitié du travail, voyez la liste de contrôle d'une requête générée par l'IA.