Formateur SQL

Comment utiliser le formateur SQL

1. Collez une ou plusieurs instructions SQL dans la zone de saisie.
2. Sélectionnez le dialecte correspondant à votre base de données : SQL standard, MySQL, PostgreSQL, SQL Server (T-SQL), SQLite, MariaDB, BigQuery, Snowflake ou Oracle PL/SQL.
3. Choisissez la casse des mots-clés : MAJUSCULES, minuscules, ou conserver la casse d’origine.
4. Définissez la taille de l’indentation.
5. Cliquez sur Formater le SQL et copiez le résultat.

Vos requêtes sont formatées dans le navigateur et ne sont jamais envoyées ni stockées, vous pouvez donc coller sans risque des requêtes de production qui révèlent des noms de tables ou une logique métier.

Pourquoi formater du SQL ?

Le SQL ne tient pas compte des espaces : la base de données exécute une requête d’une seule ligne exactement comme une requête joliment indentée. Les humains, eux, les lisent très différemment. Les requêtes copiées depuis des journaux d’ORM, des outils de supervision ou des rapports de requêtes lentes arrivent généralement sur une seule longue ligne, ce qui rend difficile de voir quelles conditions appartiennent à quelle jointure ou sous-requête.

Un formateur place chaque clause principale (SELECT, FROM, JOIN, WHERE, GROUP BY, ORDER BY) sur sa propre ligne et indente les parties imbriquées de façon cohérente. Comparez :

select u.id,u.email,count(o.id) as orders from users u left join orders o on o.user_id=u.id where u.created_at>='2026-01-01' group by u.id,u.email having count(o.id)>5 order by orders desc;

SELECT
  u.id,
  u.email,
  COUNT(o.id) AS orders
FROM
  users u
  LEFT JOIN orders o ON o.user_id = u.id
WHERE
  u.created_at >= '2026-01-01'
GROUP BY
  u.id,
  u.email
HAVING
  COUNT(o.id) > 5
ORDER BY
  orders DESC;

La version formatée est plus facile à relire dans une pull request, plus facile à déboguer, et produit des diffs plus propres quand quelqu’un ajoute ensuite une colonne ou une condition.

Pourquoi le dialecte compte

Chaque base de données étend le SQL standard avec sa propre syntaxe. Choisir le bon dialecte aide le formateur à reconnaître correctement les mots-clés, les opérateurs et les guillemets d’identifiants :

Si une requête est formatée de façon étrange, par exemple si un opérateur est coupé ou si un mot-clé est traité comme un nom de colonne, passer au bon dialecte règle généralement le problème.

Erreurs SQL courantes que le formatage aide à repérer

Un formateur n’exécute pas votre requête et ne la valide pas entièrement, mais une mise en page claire rend évidents de nombreux bugs :

• Une virgule manquante dans la liste des colonnes du SELECT. SELECT id name FROM users est du SQL valide, mais il renvoie id sous l’alias name. Avec une colonne par ligne, la virgule manquante saute aux yeux.
• Un filtre sur une table jointe en jointure externe dans le WHERE. LEFT JOIN orders o … WHERE o.status = 'paid' transforme silencieusement la jointure externe en jointure interne. Déplacez la condition dans la clause ON si vous voulez conserver les lignes sans correspondance.
• Des AND et des OR mélangés sans parenthèses. AND est prioritaire sur OR, donc a OR b AND c signifie a OR (b AND c). Ajoutez des parenthèses pour rendre l’intention explicite.
• Des parenthèses ou des guillemets non équilibrés. Quand l’indentation de la sortie dérive soudain, cherchez une parenthèse non fermée ou une chaîne littérale ouverte juste avant ce point.

Conseils et bonnes pratiques

• Les mots-clés en majuscules sont une convention répandue, car ils distinguent la syntaxe SQL des noms de vos tables et colonnes ; les minuscules sont tout aussi valables. Choisissez l’une des deux par projet.
• Donnez toujours un alias aux tables dans les requêtes multi-tables et qualifiez les noms de colonnes (u.id plutôt que id).
• Ne construisez jamais du SQL en concaténant des saisies d’utilisateur. Utilisez des requêtes paramétrées ou des requêtes préparées pour prévenir l’injection SQL.
• Vous stockez des horodatages sous forme d’entiers ? Utilisez le convertisseur de timestamp Unix pour vérifier ce que signifie une valeur, et le générateur d’UUID pour des clés primaires de test.

Questions fréquentes

Le formatage change-t-il ce que fait ma requête ?

Non. Le formateur ne modifie que les espaces, les sauts de ligne et, si vous le choisissez, la casse des mots-clés. Les identifiants, les chaînes littérales et la logique de la requête restent inchangés.

Le formateur SQL vérifie-t-il que ma requête est valide ?

Pas complètement. Il découpe la requête en jetons pour la mettre en page, une saisie gravement erronée peut donc produire un résultat étrange, mais il ne vérifie pas que les tables ou les colonnes existent ni que l’instruction s’exécuterait. Utilisez pour cela votre base de données ou un EXPLAIN.

Puis-je formater plusieurs instructions à la fois ?

Oui. Séparez les instructions par des points-virgules et chacune est formatée à son tour.

Les mots-clés SQL doivent-ils être en majuscules ?

Dans toutes les grandes bases de données, les mots-clés SQL sont insensibles à la casse, c’est donc purement une question de style. Les majuscules sont traditionnelles et courantes dans la documentation ; beaucoup d’équipes modernes préfèrent les minuscules. Ce qui compte, c’est la cohérence.

Mis à jour 2026-10-17