Modifier les données — Cours SQL

Le problème : une base n'est pas figée

Lire des données, c'est 80 % du travail. Mais il faut bien que ces données arrivent quelque part : un nouveau client s'inscrit, change d'email, supprime son compte. Trois actions, trois commandes : INSERT, UPDATE, DELETE.

Ce sont les commandes les plus dangereuses du SQL. Une erreur de lecture renvoie un mauvais résultat ; une erreur d'écriture détruit des données réelles. On reste sur la table clients.

INSERT INTO : ajouter une ligne

INSERT INTO crée une nouvelle ligne. On nomme les colonnes, puis on donne les valeurs dans le même ordre :

INSERT INTO clients (nom, email, ville)
VALUES ('Léa Martin', 'lea@exemple.fr', 'Lyon');

On ne fournit pas l'id : il est auto-incrémenté par la base. On peut insérer plusieurs lignes d'un coup :

INSERT INTO clients (nom, email, ville)
VALUES
    ('Karim Benali', 'karim@exemple.fr', 'Dijon'),
    ('Marie Dupont', 'marie@exemple.fr', 'Besançon');

Nommer explicitement les colonnes (INSERT INTO clients (nom, email, ville)) est plus sûr que de compter sur l'ordre des colonnes de la table : si la structure change un jour, votre requête continue de fonctionner.

UPDATE et DELETE : le WHERE est vital

UPDATE modifie des lignes existantes. DELETE en supprime. Les deux doivent être accompagnés d'un WHERE qui désigne précisément les lignes visées :

UPDATE clients
SET email = 'nouveau@exemple.fr'
WHERE id = 1;

DELETE FROM clients
WHERE id = 1;

Le WHERE id = 1 garantit qu'on ne touche qu'une seule ligne, celle de l'utilisateur concerné.

La catastrophe du WHERE oublié

Voici l'erreur qui a déjà coûté leur week-end à des milliers de développeurs :

-- CATASTROPHE : pas de WHERE
UPDATE clients SET email = 'test@test.fr';   -- réécrit l'email de TOUS les clients
DELETE FROM clients;                          -- vide la table ENTIÈRE

Un UPDATE ou un DELETE sans WHERE s'applique à TOUTE la table. Pas une ligne : toutes. Vos 50 000 clients voient leur email réécrit, ou disparaissent d'un coup. Réflexe de survie : écrivez toujours le WHERE AVANT le reste, et testez d'abord avec un SELECT portant le même WHERE pour voir quelles lignes seront touchées.

Filet de sécurité supplémentaire : la transaction. BEGIN ouvre une zone de travail, COMMIT valide les changements, ROLLBACK annule tout si quelque chose a mal tourné — comme un Ctrl+Z sur la base.

BEGIN;
DELETE FROM clients WHERE id = 1;
-- on vérifie le résultat... puis :
COMMIT;   -- ou ROLLBACK; pour tout annuler

The problem: a database is not frozen

Reading data is 80% of the job. But that data has to arrive somewhere: a new customer signs up, changes their email, deletes their account. Three actions, three commands: INSERT, UPDATE, DELETE.

These are the most dangerous SQL commands. A read error returns a wrong result; a write error destroys real data. We stay on the clients table.

INSERT INTO: add a row

INSERT INTO creates a new row. You name the columns, then give the values in the same order:

INSERT INTO clients (nom, email, ville)
VALUES ('Lea Martin', 'lea@exemple.fr', 'Lyon');

You do not provide the id: it is auto-incremented by the database. You can insert several rows at once:

INSERT INTO clients (nom, email, ville)
VALUES
    ('Karim Benali', 'karim@exemple.fr', 'Dijon'),
    ('Marie Dupont', 'marie@exemple.fr', 'Besancon');

Explicitly naming the columns (INSERT INTO clients (nom, email, ville)) is safer than relying on the table's column order: if the structure changes one day, your query keeps working.

UPDATE and DELETE: the WHERE is vital

UPDATE modifies existing rows. DELETE removes them. Both must come with a WHERE that precisely targets the rows:

UPDATE clients
SET email = 'nouveau@exemple.fr'
WHERE id = 1;

DELETE FROM clients
WHERE id = 1;

The WHERE id = 1 guarantees we touch a single row, the one of the relevant user.

The catastrophe of the forgotten WHERE

Here is the mistake that has already cost thousands of developers their weekend:

-- CATASTROPHE: no WHERE
UPDATE clients SET email = 'test@test.fr';   -- rewrites EVERY customer's email
DELETE FROM clients;                          -- wipes the WHOLE table

An UPDATE or DELETE without WHERE applies to the WHOLE table. Not one row: all of them. Your 50,000 customers get their email rewritten, or vanish at once. Survival reflex: always write the WHERE BEFORE the rest, and test first with a SELECT using the same WHERE to see which rows will be affected.

An extra safety net: the transaction. BEGIN opens a workspace, COMMIT validates the changes, ROLLBACK cancels everything if something went wrong — like a Ctrl+Z on the database.

BEGIN;
DELETE FROM clients WHERE id = 1;
-- check the result... then:
COMMIT;   -- or ROLLBACK; to cancel everything

À vous d'essayer — la base est déjà remplie, le SELECT final montre le résultat :

CREATE TABLE clients (id INTEGER, nom TEXT, ville TEXT);
INSERT INTO clients VALUES (1, 'Alice Durand', 'Dijon');
INSERT INTO clients VALUES (2, 'Marc Petit', 'Lyon');

INSERT INTO clients VALUES (3, 'Léa Martin', 'Dijon');
UPDATE clients SET ville = 'Besançon' WHERE id = 2;
DELETE FROM clients WHERE id = 1;

SELECT * FROM clients ORDER BY id;

Avec l'IA

Faites générer une requête de modification par l'IA et exigez un WHERE explicite + un SELECT de vérification avant exécution :

Table clients (id, nom, email, ville). Écris la requête UPDATE pour changer l'email du client dont l'id vaut 42 en 'nouveau@exemple.fr'. Règle obligatoire : la requête DOIT contenir un WHERE ciblant l'id, jamais un UPDATE global. Donne d'abord un SELECT de vérification montrant la ligne concernée, puis l'UPDATE. Explique le risque d'un UPDATE sans WHERE.

Ré-explique sans regarder

Sans relire la réponse de l'IA : avec tes mots, pourquoi a-t-on exigé un WHERE ciblant l'id ET un SELECT de vérification avant l'UPDATE ?

Une bonne explication dit : sans WHERE, l'UPDATE réécrit l'email de TOUTES les lignes, c'est irréversible une fois validé. Le WHERE id = 42 limite l'action à la seule ligne voulue. Le SELECT portant le même WHERE sert de répétition : il montre EXACTEMENT les lignes qui seront touchées avant qu'on écrive quoi que ce soit. Bonus : enrober le tout dans BEGIN / COMMIT permet un ROLLBACK si le résultat surprend.

Exercice : Modifiez en sécurité

Écrivez un UPDATE qui change la ville du client d'id 3 en 'Paris'. La requête DOIT contenir SET et un WHERE ciblant id = 3 (sinon elle modifierait toute la table).

UPDATE clients
SET ...
WHERE ...;

Accepter ou rejeter le code de l'IA

Tu as demandé à l'IA de mettre la ville de Marc Petit (id 2) à jour en 'Lille'. Elle te répond ceci. Ton rôle de relecteur : l'accepter tel quel ou le rejeter, et dire pourquoi.

UPDATE clients
SET ville = 'Lille';

Rejeter sans hésiter. Le WHERE manque : cet UPDATE met TOUS les clients à Lille, pas seulement Marc Petit. C'est exactement la catastrophe du WHERE oublié, et une fois le COMMIT passé c'est irréversible. La requête correcte est UPDATE clients SET ville = 'Lille' WHERE id = 2;. Réflexe : avant de valider, lance SELECT * FROM clients WHERE id = 2; pour confirmer la cible.

Rappel libre

Sans remonter dans la leçon : quelle commande ajoute une ligne, et que se passe-t-il si tu lances un UPDATE ou un DELETE sans WHERE ?

INSERT INTO ajoute une ligne (on nomme les colonnes, on donne les valeurs, sans fournir l'id auto-incrémenté). Un UPDATE ou un DELETE sans WHERE s'applique à TOUTE la table : il réécrit ou supprime chaque ligne, pas une seule. Réflexe : écrire le WHERE d'abord, le tester avec un SELECT, et travailler dans une transaction (BEGIN … COMMIT/ROLLBACK) pour pouvoir annuler.

Que fait DELETE FROM clients; (sans WHERE) ?

Rien, la requête est invalide Supprime la première ligne Supprime TOUTES les lignes de la table

Pourquoi ne pas fournir l'id dans un INSERT ?

Il est auto-incrémenté par la base L'id est interdit dans INSERT Pour économiser de la place

À quoi sert ROLLBACK dans une transaction ?

Valider définitivement les changements Annuler les changements non validés Sauvegarder la base sur disque

Prochaine étape

Vous remplissez et videz des tables qui existent déjà. La dernière leçon remonte d'un cran : créer vos propres tables avec CREATE TABLE, types, clés et index, puis bloquer les injections SQL avec les requêtes préparées.

Leçon 7 : Concevoir et sécuriser →