Une requête qui arrive en une seule ligne de 400 caractères est illisible, et les requêtes illisibles cachent des bugs. Cet outil analyse votre SQL et le dispose avec chaque clause sur sa propre ligne. Il analyse au lieu de simplement indenter, ce qui lui permet de vous dire quand quelque chose cloche — et explique pourquoi choisir le bon dialecte compte.
Le sélecteur de dialecte n'est pas décoratif
SQL est une norme que personne n'implémente exactement, et les écarts commencent à quelque chose d'aussi élémentaire que citer un nom. MySQL et MariaDB entourent les identifiants d'accents graves. PostgreSQL utilise les guillemets doubles et rejette net les accents graves. SQL Server prend les crochets. Une requête écrite pour l'un et analysée comme un autre ne se formate pas seulement bizarrement — elle échoue.
Vous pouvez le constater ici. Collez une requête MySQL avec des noms de colonnes entre accents graves, choisissez PostgreSQL, et la sortie se vide : l'analyseur a correctement refusé de lire des accents graves comme du PostgreSQL, car ils n'en sont pas. C'est l'outil qui vous dit quelque chose de vrai sur votre requête, pas une panne.
Les écarts vont plus loin que la citation. La limite de lignes s'écrit LIMIT en MySQL, PostgreSQL et SQLite, TOP en SQL Server, et FETCH FIRST dans la vraie norme. La concaténation de chaînes est || presque partout et CONCAT() en MySQL, où || signifie OU logique sauf si un mode particulier est activé. Si vous déplacez une requête d'un moteur à l'autre, ce sont les jointures où elle se fissure.
Le formatage vérifie la syntaxe, pas la vérité
Donnez à cet outil une requête pleine d'absurdités et il affichera une erreur, car il analyse réellement le texte. C'est utile, et c'est aussi la limite de ce qu'il peut vous dire. Une requête peut être parfaitement bien formée et pourtant catastrophiquement fausse.
Il ne peut pas savoir si vos tables existent, si la colonne sur laquelle vous avez joint est indexée, si ce JOIN renverra les lignes attendues ou cinquante millions. Un formatage propre n'est pas une revue de code. Ce que le formatage vous achète, c'est la possibilité de voir la forme de la requête — et une fois déployée, une condition de jointure manquante ou un WHERE ayant perdu ses parenthèses tend à devenir visible comme elle ne l'est jamais sur une longue ligne.
Un formateur n'est pas un outil de sécurité
Cela mérite d'être dit franchement car la confusion est réelle. Formater votre SQL ne fait strictement rien contre l'injection SQL. Il n'échappe rien, ne valide rien, et une requête construite en collant des saisies utilisateur dans une chaîne est exactement aussi dangereuse formatée que non formatée — elle est juste plus lisible pendant qu'elle supprime votre table.
La seule vraie défense, ce sont les requêtes paramétrées : le texte SQL et les valeurs voyagent séparément, une valeur ne peut donc jamais être réinterprétée comme de la syntaxe. Tous les pilotes courants le prennent en charge. Si vous vous surprenez à chercher une fonction d'échappement, c'est généralement le signe que la requête est construite à l'envers.
Les mots-clés ignorent la casse ; les identifiants sont le piège
SELECT, select et SeLeCt sont le même mot-clé pour tous les moteurs : l'option majuscules ici est donc du pur style — une convention répandue qui rend la structure balayable du regard, rien de plus. Personne ne vous remerciera pour des mots-clés en minuscules, et rien ne cassera non plus.
C'est la casse des identifiants qui abrite les vrais bugs. PostgreSQL rabat les identifiants non cités en minuscules : SELECT MyColumn demande donc en réalité mycolumn — et si vous avez créé la colonne en tant que "MyColumn" avec des guillemets, elle ne sera pas trouvée. La norme dit que les identifiants se rabattent en majuscules ; PostgreSQL est donc techniquement non conforme ici, et tout le monde a discrètement accepté de vivre avec.
MySQL est plus étrange encore : la sensibilité à la casse des noms de tables dépend du système de fichiers sous le serveur. Les tables sont des fichiers : sous Linux elles sont sensibles à la casse, sous Windows et macOS non. C'est le mécanisme derrière une classe de bugs précise et misérable — une requête qui marche sur le Mac d'un développeur et échoue en production sous Linux, sans rien dans le code pour l'expliquer.
Questions fréquentes
Ma requête est-elle envoyée à un serveur ?
Non. Cet outil porte la mention « client » : l'analyseur s'exécute dans votre onglet et le SQL ne quitte jamais votre machine. Cela compte davantage ici que pour la plupart des outils, car les vraies requêtes transportent des noms de tables, de colonnes et souvent des valeurs littérales issues de la production — la forme de votre schéma est une information que vous ne souhaitez probablement pas confier à un inconnu.
Le formatage change-t-il ce que fait ma requête ?
Non. Les espaces entre les jetons SQL ne sont pas significatifs : la requête reformatée est la même requête. La seule chose à surveiller, ce sont les littéraux de chaînes : le texte entre guillemets est une donnée, et un formateur doit le laisser intact. Celui-ci le fait. Si vous croisez un jour un formateur qui réindente à l'intérieur d'une chaîne, cessez immédiatement de l'utiliser.
Pourquoi ma requête affiche-t-elle une erreur ici mais tourne dans ma base ?
Très probablement le dialecte. Choisissez le moteur que vous utilisez réellement plutôt que Standard SQL — les moteurs acceptent quantité de choses que la norme ignore. Ce peut aussi être une extension véritablement propre au moteur que l'analyseur ne modélise pas ; dans ce cas la requête va bien et l'outil n'est simplement pas l'autorité en la matière. Votre base l'est.
Dois-je écrire les mots-clés en majuscules ?
Cela ne change rien pour le moteur. La convention existe parce qu'elle sépare le langage de vos données d'un coup d'œil : dans SELECT name FROM users, les mots en majuscules sont du SQL et ceux en minuscules sont les vôtres. La plupart des équipes la suivent, et la règle utile est de s'aligner sur ce qui existe déjà dans votre code plutôt que d'avoir un avis.
Peut-il formater une procédure stockée ou un gros script de migration ?
Il gère plusieurs instructions et vous les sépare. Les extensions procédurales — PL/pgSQL, les routines MySQL, le contrôle de flux T-SQL — sont un langage distinct posé sur SQL, et la prise en charge varie selon le dialecte. Si le corps d'une procédure revient abîmé, c'est la limite que vous avez atteinte, et la réponse est de formater les requêtes qu'elle contient plutôt que la routine entière.