T
sql format beautify database developer-tools

Formateur SQL : Embellissez et formatez vos requêtes SQL instantanément

Améliorez la lisibilité de vos requêtes SQL avec notre formateur SQL en ligne. Formatez, embellissez et nettoyez facilement les scripts de base de données complexes.

2026-04-09 Utiliser cet outil

Introduction

Tout développeur qui travaille avec des bases de données a déjà rencontré un mur de SQL non formaté : des mots-clés en minuscules, aucun saut de ligne, des noms de tables collés aux conditions JOIN, le tout sur une seule ligne qui défile indéfiniment vers la droite. C'est presque impossible à déboguer, à revoir dans une pull request ou à transmettre à un collègue. Le formatage SQL n'est pas seulement cosmétique — c'est une discipline professionnelle qui améliore la lisibilité, réduit les bugs, impose les normes d'équipe et rend la maintenance beaucoup plus facile.

Que vous écriviez un SELECT de cinq lignes ou un pipeline analytique de cent lignes avec des CTEs et des fonctions de fenêtrage, un formatage cohérent est la différence entre du code qui communique l'intention et du code qui l'obscurcit.

Une Brève Histoire de SQL

SQL est né au début des années 1970 au laboratoire de recherche IBM de San José, où le modèle relationnel d'Edgar F. Codd a inspiré Donald D. Chamberlin et Raymond F. Boyce à développer un langage appelé SEQUEL (Structured English Query Language). Il a été renommé SQL par la suite. IBM l'a intégré dans System R, et Oracle est devenue en 1979 la première entreprise à vendre une base de données SQL commerciale.

L'American National Standards Institute (ANSI) a publié le premier standard SQL en 1986, suivi de la ratification ISO. Les révisions ultérieures — SQL-89, SQL-92, SQL:1999, SQL:2003, SQL:2008, SQL:2011, SQL:2016 — ont progressivement ajouté des fonctionnalités comme les déclencheurs, les procédures stockées, les requêtes récursives (CTEs), les fonctions de fenêtrage et la prise en charge JSON.

Malgré le standard, chaque grand fournisseur de bases de données a introduit des extensions propriétaires, donnant naissance à des dialectes : MySQL, PostgreSQL, Microsoft SQL Server (T-SQL), SQLite, Oracle PL/SQL et d'autres. Ces dialectes partagent un noyau commun mais diffèrent dans la syntaxe pour les opérations sur les chaînes, les fonctions de date, les colonnes d'identité et plus encore.

Bases de la Syntaxe SQL

Avant de formater, il est utile de comprendre les blocs de construction. Une instruction SELECT standard suit cet ordre logique :

SELECT   -- colonnes à retourner
FROM     -- tables sources
JOIN     -- tables associées
WHERE    -- filtres au niveau des lignes
GROUP BY -- regroupement pour l'agrégation
HAVING   -- filtres au niveau de l'agrégat
ORDER BY -- ordre de tri
LIMIT    -- restriction du nombre de lignes

Chaque clause a un objectif distinct. WHERE filtre avant l'agrégation ; HAVING filtre après. GROUP BY réduit plusieurs lignes à une seule par groupe. ORDER BY s'applique en dernier (avant LIMIT). Comprendre cet ordre vous aide à formater les requêtes de sorte que chaque clause commence sur sa propre ligne, rendant le flux logique immédiatement visible.

Conventions de Formatage

Il n'existe pas de standard universel unique, mais les conventions suivantes sont largement adoptées :

Capitalisation des Mots-Clés La plupart des guides de style recommandent d'écrire les mots-clés SQL (SELECT, FROM, WHERE, JOIN, GROUP BY, HAVING, ORDER BY, LIMIT) en MAJUSCULES. Cela fournit un contraste visuel entre les mots-clés structuraux et les identifiants définis par l'utilisateur. Certaines équipes modernes préfèrent les minuscules pour des raisons esthétiques, et des outils comme dbt ont popularisé ce style. La règle clé : être cohérent.

Indentation Utilisez 4 espaces (ou 2 espaces dans les styles compacts) pour indenter les listes de colonnes, les clauses ON et les prédicats WHERE. Les tabulations doivent être évitées dans les bases de code partagées en raison d'un rendu incohérent selon les éditeurs.

Sauts de Ligne Chaque clause principale (SELECT, FROM, WHERE, GROUP BY, etc.) doit commencer sur sa propre ligne. Les listes de colonnes dans SELECT doivent être placées une par ligne, en retrait sous le mot-clé. Cela facilite l'ajout, la suppression ou le commentaire de colonnes individuelles.

Position de la Virgule Il y a deux camps : les virgules en fin de ligne et les virgules en début de ligne suivante. Les virgules en fin de ligne sont plus naturelles pour la plupart des programmeurs ; les virgules en début de ligne permettent de repérer d'un coup d'œil une virgule manquante. Choisissez-en une et tenez-vous-y.

Alias Utilisez toujours le mot-clé AS lors de l'attribution d'alias (u AS utilisateur, pas u utilisateur). Cela rend l'intention explicite et évite l'ambiguïté dans les requêtes complexes.

Exemple de Formatage Avant et Après

-- AVANT (non formaté)
select u.id,u.name,o.total from users u inner join orders o on u.id=o.user_id where o.total>100 and u.active=1 order by o.total desc limit 10

-- APRÈS (formaté)
SELECT
    u.id,
    u.name,
    o.total
FROM
    users u
    INNER JOIN orders o ON u.id = o.user_id
WHERE
    o.total > 100
    AND u.active = 1
ORDER BY
    o.total DESC
LIMIT 10

La version formatée rend la relation entre les tables, les conditions de filtre et l'ordre de tri immédiatement lisibles.

Comparaison des Dialectes SQL

Bien que SQL soit standardisé, les dialectes diffèrent sur des points importants :

Fonctionnalité MySQL PostgreSQL SQL Server SQLite
Concaténation de chaînes CONCAT() || ou CONCAT() + ou CONCAT() ||
Auto-incrémentation AUTO_INCREMENT SERIAL / IDENTITY IDENTITY AUTOINCREMENT
Limiter les lignes LIMIT n LIMIT n TOP n LIMIT n
Fonctions de date DATE(), NOW() CURRENT_DATE, NOW() GETDATE() DATE()
Sensibilité à la casse Par défaut : insensible Par défaut : sensible Par défaut : insensible Configurable

Comprendre ces différences est crucial lors du portage de requêtes entre bases de données. Un formateur qui connaît le dialecte cible peut produire des sorties syntaxiquement valides même pour des constructions spécifiques au dialecte.

Guides de Style SQL

Deux guides de style largement référencés aident les équipes à établir un consensus :

Guide de Style SQL de Simon Holywell (sqlstyle.guide) Ce guide met l'accent sur l'alignement des mots racines, l'utilisation de « rivières » d'espace blanc pour séparer visuellement les clauses, les virgules en début de ligne et le snake_case pour les identifiants. Il est opiniâtre mais exhaustif, et largement utilisé dans les équipes d'ingénierie des données.

Guide de Style SQL de Google Le guide de style interne de Google (partiellement public via la documentation BigQuery) favorise les virgules en fin de ligne, l'indentation de 4 espaces, les mots-clés en MAJUSCULES et le retour à la ligne pour les longues listes IN. Il s'aligne bien avec les normes de codage Java familières à de nombreux ingénieurs Google.

La plupart des équipes créent un guide de style interne léger dérivé de l'un de ces guides et l'appliquent via un formatage automatisé dans les pipelines CI.

Comment Fonctionnent les Formateurs SQL

Un formateur SQL est, à la base, un front-end de compilateur spécialisé. Le processus implique typiquement trois étapes :

1. Analyse Lexicale (Tokenisation) La chaîne SQL brute est décomposée en un flux plat de tokens : mots-clés (SELECT, FROM), identifiants (users, u), opérateurs (=, >), littéraux ('completed', 100), ponctuation (,, ;) et espaces blancs/commentaires. L'analyseur lexical ne comprend pas la structure — il ne fait que classer les caractères.

2. Analyse Syntaxique (Parsing) Le flux de tokens est transmis à un parseur qui construit un Arbre Syntaxique Abstrait (AST). Chaque nœud dans l'AST représente une construction logique : un nœud SelectStatement contient un nœud ColumnList, un nœud FromClause, un nœud WhereClause, etc. Le parseur applique les règles grammaticales et détecte les erreurs de syntaxe.

3. Ré-émission (Pretty Printing) Le formateur parcourt l'AST et émet du texte SQL selon les règles de formatage : sauts de ligne après les mots-clés de clause, indentation pour les nœuds enfants, espaces autour des opérateurs, transformations de casse des mots-clés. Puisque la sortie est dérivée de l'AST plutôt que d'une manipulation de chaînes, la signification sémantique de la requête est parfaitement préservée.

Certains formateurs plus simples sautent la construction complète de l'AST et appliquent des transformations basées sur des règles directement sur le flux de tokens. C'est plus rapide mais moins précis pour les structures imbriquées complexes.

Modèles SQL Courants avec Exemples

JOIN Multi-Tables

SELECT
    c.name AS customer_name,
    p.name AS product_name,
    oi.quantity,
    oi.unit_price
FROM
    customers c
    INNER JOIN orders o ON c.id = o.customer_id
    INNER JOIN order_items oi ON o.id = oi.order_id
    INNER JOIN products p ON oi.product_id = p.id
WHERE
    o.status = 'shipped'
    AND o.created_at >= '2024-01-01'
ORDER BY
    c.name,
    o.created_at DESC;

Sous-requête

SELECT
    department,
    AVG(salary) AS avg_salary
FROM employees
WHERE salary > (
    SELECT AVG(salary)
    FROM employees
)
GROUP BY department
ORDER BY avg_salary DESC;

CTE (Expression de Table Commune)

WITH monthly_revenue AS (
    SELECT
        DATE_TRUNC('month', created_at) AS month,
        SUM(amount) AS revenue
    FROM orders
    WHERE status = 'completed'
    GROUP BY 1
),
ranked_months AS (
    SELECT
        month,
        revenue,
        RANK() OVER (ORDER BY revenue DESC) AS rank
    FROM monthly_revenue
)
SELECT *
FROM ranked_months
WHERE rank <= 3;

Les CTEs améliorent la lisibilité en décomposant les requêtes complexes en blocs de construction nommés et réutilisables. Ils sont particulièrement précieux dans le SQL analytique où les agrégations intermédiaires alimentent des calculs supplémentaires.

Fonctions de Fenêtrage

SELECT
    employee_id,
    department,
    salary,
    AVG(salary) OVER (PARTITION BY department) AS dept_avg,
    RANK() OVER (PARTITION BY department ORDER BY salary DESC) AS dept_rank
FROM employees;

Les fonctions de fenêtrage (ROW_NUMBER, RANK, LAG, LEAD, SUM, AVG avec OVER) comptent parmi les plus puissantes de SQL. Un formatage approprié — chaque clause OVER sur la même ligne que sa fonction — est essentiel pour la lisibilité.

Agrégation avec HAVING

SELECT
    category,
    COUNT(*) AS total_products,
    AVG(price) AS avg_price,
    MAX(price) AS max_price
FROM products
WHERE active = 1
GROUP BY category
HAVING COUNT(*) > 10
ORDER BY avg_price DESC;

Intégration avec les IDEs et les Outils

VS Code Le package npm sql-formatter alimente plusieurs extensions VS Code. Configurez le formatage à la sauvegarde dans settings.json :

"[sql]": { "editor.defaultFormatter": "mtxr.sqltools" }

JetBrains DataGrip DataGrip dispose d'un formatage SQL intégré sous Code → Reformater le code (Ctrl+Alt+L). Les options de style sont configurables par dialecte de source de données sous Paramètres → Éditeur → Style de code → SQL.

DBeaver DBeaver prend en charge le formatage SQL via Éditeur SQL → Formater SQL et permet une configuration personnalisée du formateur dans Préférences → Éditeurs → Éditeur SQL → Formatage.

Ligne de Commande Le package npm sql-formatter peut être utilisé comme outil CLI :

npx sql-formatter --language postgresql --indent 4 query.sql

Meilleures Pratiques

  1. Formatez tôt, formatez souvent. Exécutez le formateur avant chaque commit, pas seulement avant la revue de code.
  2. Convenez d'abord d'un guide de style. Aucun formateur ne peut remplacer le consensus de l'équipe sur les conventions.
  3. Utilisez les alias de manière cohérente. Les alias courts (1-2 lettres) conviennent aux requêtes simples ; les alias descriptifs améliorent la lisibilité dans les requêtes complexes.
  4. Nommez les CTEs de manière descriptive. monthly_revenue est mieux que cte1 ou tmp.
  5. Commentez la logique complexe. Une requête bien formatée avec des commentaires inline expliquant des règles métier non évidentes est beaucoup plus maintenable que du SQL intelligent mais silencieux.
  6. Lintez le SQL dans la CI. Des outils comme sqlfluff peuvent appliquer des règles de formatage automatiquement dans les pipelines de pull requests.
  7. Gardez CASE WHEN lisible. Divisez les longues chaînes CASE WHEN sur plusieurs lignes, une branche par ligne.
  8. Qualifiez toutes les références de colonnes. Dans les requêtes multi-tables, préfixez toujours les noms de colonnes avec l'alias de table (u.id et non seulement id).

Foire Aux Questions

Le formatage change-t-il le comportement de ma requête ? Non. Un formateur ne change que les espaces blancs, les sauts de ligne et la casse des mots-clés. La structure logique et le plan d'exécution restent identiques.

Un formateur peut-il corriger les erreurs de syntaxe ? Non. Les formateurs nécessitent du SQL syntaxiquement valide (ou presque valide) pour analyser correctement. Utilisez un linter comme sqlfluff pour détecter et expliquer les erreurs.

Quel style de casse pour les mots-clés devrais-je utiliser ? Les MAJUSCULES pour les mots-clés sont la convention la plus traditionnelle et la plus largement recommandée dans les communautés SQL et les guides de style. Cependant, les minuscules sont de plus en plus populaires dans dbt et les outils de données modernes. Choisissez-en un pour votre équipe et appliquez-le automatiquement.

Prend-il en charge les procédures stockées et les blocs PL/SQL ? La prise en charge varie. La plupart des formateurs gèrent bien les DML (SELECT, INSERT, UPDATE, DELETE). Les extensions procédurales (PL/SQL, lots T-SQL, blocs BEGIN...END) nécessitent des parseurs conscients du dialecte et varient en qualité de support.

Mes données SQL sont-elles en sécurité lors de l'utilisation de formateurs en ligne ? Un bon formateur en ligne traite tout côté client dans le navigateur en utilisant JavaScript. Votre requête ne quitte jamais votre machine. Vérifiez toujours cela dans la politique de confidentialité de l'outil avant de coller des informations de schéma sensibles.

Quelle est la différence entre un formateur et un linter ? Un formateur transforme la présentation du SQL sans en changer la signification. Un linter (sqlfluff, SQLCheck) analyse le SQL pour les violations de style, les anti-modèles et les bugs potentiels, signalant les problèmes plutôt que de les corriger automatiquement.

Retour au blog Formateur SQL →