Enseigner le SQL : faire écrire de vraies requêtes dès la première heure

Le vrai obstacle n'est pas le langage, c'est la base

Le SQL est l'un des langages les plus accessibles qu'on puisse enseigner : sa syntaxe se lit presque comme une phrase, et un débutant produit une requête utile en quelques minutes. L'obstacle est ailleurs.

Avant d'écrire un seul SELECT, il faut une base de données à disposition. Et c'est là que les formations SQL perdent leur première demi-journée :

• Installer un serveur sur chaque poste demande des droits d'administration que les apprenants n'ont presque jamais.
• Partager une base commune pose l'autre problème : le premier DELETE maladroit casse le jeu de données de tout le groupe.
• Donner un accès distant suppose un serveur à administrer, des comptes à créer, et un pare-feu à convaincre.

La solution la plus simple consiste à donner à chacun sa propre base, dans son navigateur, déjà remplie. Personne n'installe rien, personne ne casse le travail des autres, et un DROP TABLE malheureux ne coûte qu'un rechargement de page.

Un jeu de données qu'on comprend sans explication

Le choix du jeu de données pèse plus lourd qu'on ne l'imagine sur la réussite d'une formation. Une base trop riche oblige à expliquer le métier avant d'expliquer le langage ; une base trop pauvre ne permet aucune jointure intéressante.

Le modèle qui fonctionne partout tient en quatre tables : des clients, des produits, des commandes, et les lignes de ces commandes. Tout le monde en comprend le sens sans préambule, et cette structure suffit à couvrir l'essentiel du programme :

• Le filtrage et le tri sur la table des clients.
• Les agrégats — compter, additionner, faire une moyenne — sur les produits.
• La jointure simple entre commandes et clients.
• La jointure multiple et le regroupement pour calculer un chiffre d'affaires par client.

Gardez le volume modeste : une dizaine de lignes par table. Un résultat qu'on peut lire en entier à l'écran permet de vérifier par soi-même que la requête a fait ce qu'on croyait.

L'ordre qui évite les blocages

La progression classique des manuels suit l'ordre de la syntaxe. L'ordre qui fonctionne en salle suit plutôt la difficulté réelle, et elle ne se situe pas là où on l'attend.

Commencez par lire, pas par écrire. Une requête déjà rédigée, qu'on exécute et dont on observe le résultat, installe l'essentiel : une requête rend un tableau. Faites-la ensuite modifier — changer une ville, ajouter un tri — avant d'en faire écrire une de zéro.

Introduisez la jointure tôt. C'est contre-intuitif, mais la jointure est le cœur du SQL et la source de la plupart des blocages. La repousser en fin de programme laisse croire que le reste est acquis, alors que la moitié du groupe cale dès la première.

Gardez GROUP BY pour la fin. Le regroupement demande de penser en ensembles plutôt qu'en lignes : c'est un vrai saut conceptuel, qui mérite du temps et des exemples visuels.

Les trois erreurs qui reviennent toujours

Trois malentendus reviennent dans chaque groupe, quel que soit le niveau. Les anticiper fait gagner une heure.

• La jointure oubliée. Deux tables dans le FROM, aucune condition de liaison, et la requête rend le produit de toutes les lignes. Le résultat est énorme et personne ne comprend pourquoi. Montrez-le volontairement une fois : c'est la démonstration la plus efficace.
• Le filtre au mauvais endroit. Filtrer avant ou après un regroupement ne donne pas le même résultat. Faites écrire les deux versions côte à côte plutôt que d'expliquer la règle.
• La comparaison avec une valeur absente. Un champ vide ne se compare pas comme les autres : la requête ne renvoie rien, sans erreur, et l'apprenant cherche sa faute ailleurs pendant dix minutes.

Ces trois cas ont un point commun : la requête ne plante pas. Elle rend un résultat faux, silencieusement. D'où l'importance de travailler sur un jeu de données assez petit pour qu'on puisse vérifier le résultat à l'œil.

Corriger en direct, sans donner la réponse trop tôt

Le SQL se prête particulièrement bien à la correction collective : une requête tient en quelques lignes, et le résultat est immédiatement visible par tous.

Le dispositif le plus efficace consiste à projeter votre propre écran pendant que chacun travaille dans le sien. Vous écrivez une requête, elle apparaît chez eux ; ils l'adaptent sans avoir à la recopier de mémoire. Au moment de corriger, montrez d'abord le résultat attendu — le tableau, pas la requête. Le groupe cherche alors le chemin, ce qui est exactement l'exercice.

Gardez le corrigé écrit à l'avance mais masqué, et ne le révélez qu'après. Un corrigé visible trop tôt transforme un exercice de raisonnement en exercice de recopie.

Ce qu'il reste à voir sur un vrai serveur

Une base dans le navigateur couvre tout ce qu'on interroge. Elle ne couvre pas ce qu'on administre, et c'est une distinction qu'il vaut mieux poser clairement devant le groupe.

Restent à traiter dans un environnement réel : les droits et les utilisateurs, les sauvegardes, l'optimisation et les index sur des volumes conséquents, les transactions concurrentes, et les différences de dialecte entre moteurs. Ces sujets relèvent du métier d'administrateur plus que de l'écriture de requêtes.

Pour une initiation, une remise à niveau ou un module SQL dans une formation plus large, le navigateur suffit largement — et il libère la demi-journée qu'on passait à installer.