Formateur SQL en ligne gratuit

Qu’est-ce qu’un formateur SQL ?

Un formateur SQL réindente et remet en forme une requête déjà valide : il aligne les clauses, les jointures et les sous-requêtes, et harmonise la casse des mots-clés, sans changer ce que la requête interroge ni le résultat qu’elle renvoie. Formater SQL en ligne dans le navigateur veut dire coller le texte à gauche et récupérer, à droite, la même requête reposée sur la page.

Le format brut n’est presque jamais un choix : une requête copiée depuis un journal de requêtes lentes arrive sur une seule ligne de huit cents caractères, celle qu’un ORM a générée casse ses lignes n’importe où, et celle héritée dans un rapport que personne n’a touché depuis trois ans mélange trois conventions d’indentation différentes. Dans les trois cas, la requête fonctionne déjà ; seule sa lisibilité manque.

Ce formateur ne valide pas la syntaxe et ne corrige aucune erreur logique : il prend un SQL syntaxiquement correct et le met en page selon des règles fixes de casse et d’indentation, dialecte par dialecte.

Comment utiliser le formateur SQL

1. Collez votre SQL. Le volet de droite affiche la version formatée au fil de la frappe.
2. Choisissez le dialecte. Standard, MySQL, SQL Server ou PostgreSQL détermine les règles de citation des identifiants.
3. Réglez l’indentation et la casse. Deux espaces, quatre espaces ou une tabulation, mots-clés en majuscules, en minuscules ou inchangés, puis copiez le résultat.

Ce que « correct » veut dire ici, et ce qui est garanti

Il n’existe pas de spécification du formatage SQL. XML en a une, Markdown a CommonMark et ses six cent cinquante-deux exemples résolus, mais l’endroit où une clause se coupe, la profondeur d’indentation d’une sous-requête ou le fait de crier ou non les mots-clés relèvent d’une convention maison, pas d’une norme. « Correct » n’est donc pas défini pour ce travail, et un outil qui affiche un pourcentage d’exactitude a inventé la mesure qu’il affiche.

Ce qui peut être garanti, et l’est, c’est que le formatage ne change jamais ce que fait la requête. Deux promesses concrètes : chaque littéral de chaîne, chaque identifiant entre guillemets et chaque commentaire ressort octet pour octet tel qu’il est entré, et la suite des éléments ne change pas — rien n’est ajouté, supprimé ni réordonné. Seuls les espaces entre les éléments bougent, et seule la casse des mots-clés change.

Cette garantie est vérifiée par un test, pas seulement voulue. La suite des éléments est comparée avant et après formatage, sur un corpus écrit à la main et un balayage généré de mille cinq cents instructions couvrant les quatre dialectes, avec un cas de contrôle qui prouve que la comparaison est bien capable d’échouer. Mille huit cent deux vérifications au total.

Pourquoi cela compte concrètement : un formateur qui coupe la ligne à chaque virgule la coupera aussi à l’intérieur d’un littéral de chaîne, transformant une de vos données en deux lignes. Un formateur qui met en majuscules tous les mots-clés mettra en majuscules le mot select à l’intérieur d’une chaîne, ou dans une colonne justement nommée « select ». Ces deux cas changent le résultat de la requête, pas seulement son apparence.

Le dialecte, une question de correction, et une limite assumée

Le sélecteur de dialecte n’est pas une préférence de style : c’est une fonction de correction. Il choisit les règles de citation, seul endroit où se tromper corrompt une requête au lieu de simplement la restyliser. MySQL entoure les identifiants d’accents graves et traite le dièse comme un début de commentaire de ligne. SQL Server les entoure de crochets, si bien qu’un mot réservé entre crochets redevient un nom de colonne ordinaire. PostgreSQL et le SQL standard utilisent les guillemets doubles, et PostgreSQL ajoute des corps entre paires de signes dollar, dont le contenu peut comporter des points-virgules, des apostrophes et à peu près n’importe quoi.

Lire une requête MySQL à accents graves avec les règles standard fait passer ces accents pour de la ponctuation ordinaire. Lire un corps de fonction PostgreSQL sans gérer la citation par dollars massacre son contenu comme s’il s’agissait de SQL ordinaire. Ni l’un ni l’autre n’est affaire de goût, et il n’existe pas de valeur par défaut sûre — c’est exactement pour cela que l’outil pose la question au lieu d’en deviner une.

La mise en page, elle, obéit volontairement à peu de règles : les mots-clés de clause commencent une ligne, les jointures s’indentent d’un niveau en dessous, les parenthèses ouvrent un niveau, et les virgules coupent la ligne. Tout ce que le formateur ne reconnaît pas ressort tel quel plutôt que d’être deviné.

C’est un jeu de règles plus restreint que celui d’autres outils, et c’est volontaire : il obéit au même principe que la garantie de la section précédente — préserver ce qui n’est pas compris plutôt que de le transformer au hasard.

Pourquoi est-ce gratuit ?

Tout le travail se passe dans votre navigateur : coller, formater et copier n’envoient rien sur un serveur, ce qui rend l’outil gratuit à faire tourner quel que soit le nombre de requêtes traitées. Il n’y a ni compte à créer, ni filigrane sur le résultat, ni limite cachée qui apparaîtrait après quelques essais. Si votre SQL contient des données sensibles — noms de clients, jetons, adresses — rien ne quitte votre poste, puisqu’il n’y a rien à envoyer.

Cela vaut aussi pour la comparaison des éléments avant et après formatage qui garantit l’intégrité de la requête : elle tourne elle aussi dans la page, pas sur un serveur qui verrait passer votre SQL.