Guide de style SQL : comment écrire un code lisible

Style SQL : Comment écrire des requêtes plus claires et fiables

Dans la plupart des projets, je ne tombe pas sur du SQL faux. Je tombe sur du SQL laid. Des requêtes qui marchent, mais qu’on n’a pas envie de toucher tellement c’est laid. Des JOIN tassés, des alias flous, des WHERE ambigus, des noms de colonnes trop vagues pour être compris sans contexte. C’est exactement pour ça qu’un guide de style SQL a de la valeur. Il ne sert pas à normaliser pour le plaisir du beau . Il sert à réduire la friction, éviter les erreurs stupides et rendre le code plus simple à relire.

Dans ce guide SQL, je reprends les principes essentiels développés par Simon Holywell pour écrire des requêtes plus propres, plus lisibles et réellement exploitables.

Prenons une requête banale :

select c.id, c.firstname, c.lastname, sum(o.amount) total
from customers c join orders o on c.id=o.customer_id
where o.status='paid' and o.created_at>='2026-01-01'
group by c.id,c.firstname,c.lastname
order by total desc;

Oui, ça tourne. Non, ce n’est pas un SQL agréable à maintenir.

La même logique, écrite proprement :

SELECT c.customer_id,
       c.first_name,
       c.last_name,
       SUM(o.amount) AS amount_total
  FROM customer AS c
  JOIN orders AS o
    ON o.customer_id = c.customer_id
 WHERE o.order_status = 'paid'
   AND o.created_at >= '2026-01-01'
 GROUP BY c.customer_id,
          c.first_name,
          c.last_name
 ORDER BY amount_total DESC;

Découvrez égalementComment accélérer les backfills Data Transfer avec Cloud Shell ?

Même résultat. En revanche, la lecture n’a plus rien à voir.

Pourquoi le style SQL change-t-il réellement la qualité d’un projet ?

Le style SQL est souvent traité comme un sujet secondaire. C’est une erreur. Une requête mal écrite coûte du temps à tous les niveaux :

• elle se relit mal ;
• elle se corrige mal ;
• elle se transmet mal ;
• elle se compare mal dans Git ;
• elle se modifie avec plus de risque.

Je le vois régulièrement dans les projets data. Le problème ne vient pas toujours de la logique métier ou du modèle de données. Il vient souvent d’un SQL brouillon, tassé, incohérent, où chaque développeur ou analyste applique ses propres réflexes.

Le résultat est connu d’avance : personne n’aime relire le code, personne n’ose le toucher, et la moindre évolution devient inutilement coûteuse.

Découvrez égalementQuelles requêtes SQL maîtriser pour un data analyst efficace ?

Le style SQL ne règle pas tout. En revanche, il réduit énormément la friction.

Pourquoi rendre les mots-clés SQL plus lisibles ?

La première règle est simple : les mots-clés SQL doivent se distinguer immédiatement du reste.

J’écris systématiquement SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY, HAVING, CASE, AS en majuscules. Je ne le fais pas pour faire joli. Je le fais parce que l’œil repère plus vite la structure de la requête.

Regardons une version compacte :

select product_name, unit_price
from product
where unit_price > 100
order by unit_price desc;

Et la même version avec des mots-clés visuellement distincts :

SELECT product_name,
       unit_price
  FROM product
 WHERE unit_price > 100
 ORDER BY unit_price DESC;

Découvrez égalementComment analyser les paniers multi-produits pour booster le cross-selling ?

Sur trois lignes, la différence semble modeste. Sur une requête de 80 lignes avec plusieurs jointures, des agrégats, des sous-requêtes et des conditions complexes, c’est énorme.

Autre exemple, plus dense :

select order_id, customer_id, amount, created_at
from orders
where status = 'paid'
and amount > 500
and created_at >= '2026-01-01'
order by created_at desc;

Version propre :

SELECT order_id,
       customer_id,
       amount,
       created_at
  FROM orders
 WHERE order_status = 'paid'
   AND amount > 500
   AND created_at >= '2026-01-01'
 ORDER BY created_at DESC;

Dès qu’on veut relire rapidement la structure, la seconde version gagne immédiatement.

Comment choisir de bonnes conventions de nommage en SQL ?

Le SQL devient pénible très vite quand le nommage est mauvais. Colonnes floues, tables incohérentes, conventions mélangées, camelCase ici, snake_case là, préfixes hérités d’un vieux framework ou d’un ERP poussiéreux.

Je préfère une convention simple : snake_case partout, des noms explicites, et aucune fantaisie inutile.

Exemple bancal :

SELECT CustomerID, FirstName, LastName
FROM CustomerTable;

Version saine :

SELECT customer_id,
       first_name,
       last_name
  FROM customer;

Le second exemple évite plusieurs problèmes d’un coup :

• pas de guillemets obligatoires ;
• une lecture plus fluide ;
• une meilleure cohérence avec la plupart des environnements data ;
• un code plus simple à rechercher et à manipuler.

Même logique pour les noms de colonnes. Une colonne qui s’appelle id, name, status ou date sans contexte est une mauvaise idée.

Exemple flou :

SELECT id, name, status, date
  FROM orders;

Exemple propre :

SELECT order_id,
       order_status,
       created_date,
       customer_id
  FROM orders;

La différence paraît évidente une fois montrée. Pourtant, dans la vraie vie, on voit encore partout des tables remplies de colonnes nommées trop vaguement.

Quand je tombe sur ça dans un projet :

SELECT id, name
  FROM customers c
  JOIN orders o
    ON c.id = o.customer_id;

je sais qu’on va perdre du temps dès qu’on voudra enrichir la requête.

Version plus solide :

SELECT c.customer_id,
       c.customer_name
  FROM customer AS c
  JOIN orders AS o
    ON o.customer_id = c.customer_id;

Un nom correct évite des dizaines d’ambiguïtés.

Comment utiliser les alias sans dégrader la lisibilité ?

Les alias sont utiles. Les mauvais alias sont toxiques.

Je vois encore trop de SQL comme ça :

SELECT a.id, b.name, c.amount
  FROM table1 a
  JOIN table2 b
    ON a.id = b.id
  JOIN table3 c
    ON a.id = c.id;

Là, personne ne lit. Tout le monde décode.

Je préfère des alias courts mais logiques :

SELECT o.order_id,
       c.customer_name,
       p.payment_amount
  FROM orders AS o
  JOIN customer AS c
    ON c.customer_id = o.customer_id
  JOIN payment AS p
    ON p.order_id = o.order_id;

Le bon alias doit aider à comprendre la requête sans allonger inutilement chaque colonne.

Quelques exemples utiles :

SELECT o.order_id,
       ol.product_id,
       p.product_name
  FROM orders AS o
  JOIN order_line AS ol
    ON ol.order_id = o.order_id
  JOIN product AS p
    ON p.product_id = ol.product_id;

Ici, o, ol et p restent compacts tout en restant clairs.

Autre exemple avec plusieurs dimensions métier :

SELECT s.session_id,
       u.user_id,
       d.device_type,
       ch.channel_name
  FROM session AS s
  JOIN users AS u
    ON u.user_id = s.user_id
  JOIN device AS d
    ON d.device_id = s.device_id
  JOIN channel AS ch
    ON ch.channel_id = s.channel_id;

Même sur quatre tables, la lecture reste fluide.

En revanche, j’évite les alias trop longs quand ils n’apportent rien :

SELECT orders_table.order_id,
       customer_table.customer_name
  FROM orders AS orders_table
  JOIN customer AS customer_table
    ON customer_table.customer_id = orders_table.customer_id;

C’est propre techniquement, mais verbeux pour rien.

Comment organiser visuellement une requête SQL ?

Le SQL tassé est une mauvaise habitude. Une requête doit être lisible en balayage visuel.

Version compacte :

SELECT order_id, customer_id, amount FROM orders WHERE order_status = 'paid' AND amount > 1000 AND created_at >= '2026-01-01';

Version structurée :

SELECT order_id,
       customer_id,
       amount
  FROM orders
 WHERE order_status = 'paid'
   AND amount > 1000
   AND created_at >= '2026-01-01';

Avec cette mise en forme, je peux immédiatement repérer :

• ce qui est sélectionné ;
• d’où ça vient ;
• comment c’est filtré.

Même logique avec des fonctions :

SELECT customer_id,
       COUNT(order_id) AS order_count,
       SUM(amount) AS amount_total,
       AVG(amount) AS average_amount
  FROM orders
 GROUP BY customer_id;

Si je tasse ça sur une seule ligne, je perds en lisibilité sans rien gagner.

Autre exemple avec un CASE :

SELECT customer_id,
       total_amount,
       CASE
           WHEN total_amount >= 10000 THEN 'vip'
           WHEN total_amount >= 3000 THEN 'premium'
           ELSE 'standard'
       END AS customer_segment
  FROM customer_revenue;

Là encore, le format rend la logique explicite.

Comment rendre un WHERE plus clair et moins risqué ?

Le WHERE est souvent la zone qui se dégrade le plus vite. Quand tout est compacté, il devient difficile de comprendre la logique exacte.

Exemple moyen :

SELECT *
  FROM orders
 WHERE order_status = 'paid' AND amount > 1000 AND created_at >= '2026-01-01' AND source_system <> 'legacy';

Version lisible :

SELECT *
  FROM orders
 WHERE order_status = 'paid'
   AND amount > 1000
   AND created_at >= '2026-01-01'
   AND source_system <> 'legacy';

Chaque condition sur sa ligne. Toujours.

Quand la logique devient un peu plus riche, cette règle devient indispensable :

SELECT *
  FROM orders
 WHERE order_status IN ('paid', 'shipped')
   AND amount >= 100
   AND amount < 1000
   AND created_at >= '2026-01-01';

Autre cas fréquent : l’ambiguïté entre AND et OR.

Version dangereuse :

SELECT *
  FROM orders
 WHERE order_status = 'paid'
    OR order_status = 'shipped'
   AND amount > 500;

Beaucoup de gens lisent ça comme :

• statut paid ou shipped
• et montant > 500

Mais SQL ne l’interprète pas forcément comme ça. La priorité logique peut produire un résultat inattendu.

Version claire :

SELECT *
  FROM orders
 WHERE order_status IN ('paid', 'shipped')
   AND amount > 500;

Ou, si la logique métier est différente :

SELECT *
  FROM orders
 WHERE (
           order_status = 'paid'
        OR order_status = 'shipped'
       )
   AND amount > 500;

Dès qu’il y a le moindre doute, je parenthèse.

Quand faut-il utiliser IN, BETWEEN ou une borne explicite ?

Quand je vois une répétition inutile, je la simplifie.

Avant :

SELECT *
  FROM orders
 WHERE order_status = 'paid'
    OR order_status = 'shipped'
    OR order_status = 'delivered';

Après :

SELECT *
  FROM orders
 WHERE order_status IN ('paid', 'shipped', 'delivered');

Même logique pour des bornes :

SELECT *
  FROM orders
 WHERE amount BETWEEN 100 AND 500;

ou pour des dates :

SELECT *
  FROM orders
 WHERE created_at BETWEEN '2026-01-01' AND '2026-01-31';

Même si, en pratique, sur les timestamps, je fais souvent attention à la borne haute exclusive pour éviter les erreurs :

SELECT *
  FROM orders
 WHERE created_at >= '2026-01-01'
   AND created_at < '2026-02-01';

C’est un détail important. Beaucoup de bugs de période viennent d’un filtre temporel mal exprimé.

Comment présenter des jointures SQL de manière lisible ?

Dès qu’il y a plusieurs JOIN, le style devient décisif. Une jointure mal formatée fait perdre le fil de la logique relationnelle.

Version tassée :

SELECT o.order_id, c.customer_name, a.city
FROM orders AS o
JOIN customer AS c ON c.customer_id = o.customer_id
LEFT JOIN address AS a ON a.address_id = c.address_id AND a.is_primary = 1
WHERE o.order_status = 'paid';

Version lisible :

SELECT o.order_id,
       c.customer_name,
       a.city
  FROM orders AS o
  JOIN customer AS c
    ON c.customer_id = o.customer_id
  LEFT JOIN address AS a
    ON a.address_id = c.address_id
   AND a.is_primary = 1
 WHERE o.order_status = 'paid';

Je veux voir immédiatement :

• quelles tables participent à la requête ;
• de quel type de jointure il s’agit ;
• quelles conditions relèvent de la relation ;
• quelles conditions relèvent du filtre métier.

Autre exemple, un peu plus riche :

SELECT o.order_id,
       c.customer_name,
       ol.quantity,
       p.product_name,
       cat.category_name
  FROM orders AS o
  JOIN customer AS c
    ON c.customer_id = o.customer_id
  JOIN order_line AS ol
    ON ol.order_id = o.order_id
  JOIN product AS p
    ON p.product_id = ol.product_id
  LEFT JOIN category AS cat
    ON cat.category_id = p.category_id
 WHERE o.order_status = 'paid';

Là, la requête reste lisible malgré plusieurs jointures.

Comment rendre la logique métier explicite dans une requête SQL ?

Un SQL propre ne se contente pas de récupérer des colonnes. Il peut aussi expliciter une logique métier sans la rendre obscure.

Le CASE est très utile pour ça.

Exemple de segmentation :

SELECT customer_id,
       total_amount,
       CASE
           WHEN total_amount >= 10000 THEN 'vip'
           WHEN total_amount >= 3000 THEN 'premium'
           ELSE 'standard'
       END AS customer_segment
  FROM customer_revenue;

Exemple de catégorisation de statut :

SELECT order_id,
       shipped_at,
       delivered_at,
       CASE
           WHEN delivered_at IS NOT NULL THEN 'delivered'
           WHEN shipped_at IS NOT NULL THEN 'shipped'
           ELSE 'pending'
       END AS fulfillment_status
  FROM orders;

Exemple d’analyse de performance logistique :

SELECT order_id,
       created_at,
       shipped_at,
       CASE
           WHEN shipped_at IS NULL THEN 'not_shipped'
           WHEN shipped_at <= created_at + INTERVAL '1 day' THEN 'shipped_in_24h'
           WHEN shipped_at <= created_at + INTERVAL '2 day' THEN 'shipped_in_48h'
           ELSE 'shipped_after_48h'
       END AS shipping_delay_bucket
  FROM orders;

J’aime ce type de SQL parce qu’il raconte quelque chose. Il ne se contente pas d’extraire de la donnée brute. Il met déjà en forme une partie de l’intelligence métier.

Comment écrire proprement une sous-requête ou une CTE ?

Une sous-requête doit être lisible comme une requête normale. Pas comme un appendice honteux coincé entre parenthèses.

Version sale :

SELECT customer_id,
(SELECT MAX(created_at) FROM orders WHERE orders.customer_id = customer.customer_id) AS last_order_at
FROM customer;

Version lisible :

SELECT c.customer_id,
       (
           SELECT MAX(o.created_at)
             FROM orders AS o
            WHERE o.customer_id = c.customer_id
       ) AS last_order_at
  FROM customer AS c;

Encore mieux, souvent, avec une CTE :

WITH last_order AS (
    SELECT customer_id,
           MAX(created_at) AS last_order_at
      FROM orders
     GROUP BY customer_id
)
SELECT c.customer_id,
       lo.last_order_at
  FROM customer AS c
  LEFT JOIN last_order AS lo
    ON lo.customer_id = c.customer_id;

Les CTE sont très utiles pour découper une logique complexe en étapes lisibles.

Exemple plus riche :

WITH paid_orders AS (
    SELECT order_id,
           customer_id,
           amount,
           created_at
      FROM orders
     WHERE order_status = 'paid'
),
customer_totals AS (
    SELECT customer_id,
           COUNT(order_id) AS order_count,
           SUM(amount) AS amount_total
      FROM paid_orders
     GROUP BY customer_id
)
SELECT c.customer_id,
       c.first_name,
       c.last_name,
       ct.order_count,
       ct.amount_total
  FROM customer AS c
  JOIN customer_totals AS ct
    ON ct.customer_id = c.customer_id;

Cette approche coûte parfois une ou deux lignes de plus. En échange, elle améliore énormément la compréhension.

À quoi servent réellement les commentaires dans du SQL ?

Je commente peu. Mais quand je commente, je le fais pour une vraie raison.

Ça, c’est inutile :

-- sélectionne les commandes payées
SELECT *
  FROM orders
 WHERE order_status = 'paid';

Le commentaire ne sert à rien. La requête dit déjà exactement ça.

En revanche, ça devient utile :

/* Exclut les commandes migrées depuis l'ancien ERP car
   leur historique de statut n'est pas fiable avant le 2024-11-01 */
SELECT order_id,
       order_status,
       created_at
  FROM orders
 WHERE created_at >= '2024-11-01'
   AND source_system <> 'legacy_erp';

Autre exemple :

/* Le revenu net retire ici les remboursements partiels et complets,
   mais ne déduit pas encore les avoirs comptables traités hors plateforme */
SELECT order_id,
       gross_amount - refunded_amount AS net_amount
  FROM finance_order_metrics;

Un bon commentaire explique le pourquoi, la limite, l’exception ou l’arbitrage métier. Il ne paraphrase pas le SQL.

Comment écrire correctement les dates et les filtres temporels en SQL ?

Les dates mal écrites sont une source de confusion permanente. J’évite absolument les formats ambigus.

Ça :

WHERE created_at = '01/02/2026'

est une mauvaise idée.

Je préfère toujours :

WHERE created_at >= '2026-02-01'

et pour une date-heure :

WHERE created_at >= '2026-02-01T09:00:00'

Autre bon exemple avec des périodes mensuelles :

SELECT COUNT(*) AS order_count
  FROM orders
 WHERE created_at >= '2026-02-01'
   AND created_at < '2026-03-01';

Ce format évite une quantité ridicule d’erreurs.

Sur les projets analytics, c’est encore plus critique, parce qu’un mauvais filtre temporel peut fausser un KPI entier sans que personne ne s’en rende compte immédiatement.

Pourquoi le style SQL ne concerne-t-il pas seulement les SELECT ?

Le style SQL ne concerne pas seulement les SELECT. Les scripts de création de tables doivent eux aussi être propres.

Version moyenne :

CREATE TABLE orders(
id INTEGER PRIMARY KEY,
customer_id INTEGER NOT NULL,
amount FLOAT NOT NULL DEFAULT 0,
status VARCHAR(20),
created_at TIMESTAMP
);

Version plus saine :

CREATE TABLE orders (
    order_id         INTEGER       PRIMARY KEY,
    customer_id      INTEGER       NOT NULL,
    amount           DECIMAL(12,2) NOT NULL DEFAULT 0.00,
    order_status     VARCHAR(20)   NOT NULL,
    created_at       TIMESTAMP     NOT NULL
);

Ici, plusieurs choses changent :

• le nom des colonnes devient explicite ;
• les types sont plus cohérents ;
• les contraintes se lisent mieux ;
• le montant n’utilise plus un type flottant mal adapté à de la finance.

Autre exemple avec des contraintes :

CREATE TABLE order_line (
    order_line_id    INTEGER       PRIMARY KEY,
    order_id         INTEGER       NOT NULL,
    product_id       INTEGER       NOT NULL,
    quantity         INTEGER       NOT NULL,
    unit_price       DECIMAL(12,2) NOT NULL,
    created_at       TIMESTAMP     NOT NULL
);

Et si je veux aller plus loin :

CREATE TABLE customer (
    customer_id      INTEGER       PRIMARY KEY,
    email            VARCHAR(255)  NOT NULL,
    first_name       VARCHAR(100)  NOT NULL,
    last_name        VARCHAR(100)  NOT NULL,
    created_at       TIMESTAMP     NOT NULL,
    customer_status  VARCHAR(20)   NOT NULL
);

Même sur du DDL, un bon style réduit la charge mentale.

À quoi ressemble une requête SQL avant et après un vrai nettoyage ?

Le plus parlant reste souvent le avant/après.

Premier exemple.

Version sale :

select u.id, u.firstname, u.lastname, count(o.id) nb, sum(o.amount) total
from users u left join orders o on u.id=o.user_id
where o.status='paid' or o.status='shipped' and o.created_at>='2026-01-01'
group by u.id, u.firstname, u.lastname
having sum(o.amount)>500
order by total desc;

Version propre :

SELECT u.user_id,
       u.first_name,
       u.last_name,
       COUNT(o.order_id) AS order_count,
       SUM(o.amount) AS amount_total
  FROM users AS u
  LEFT JOIN orders AS o
    ON o.user_id = u.user_id
 WHERE o.order_status IN ('paid', 'shipped')
   AND o.created_at >= '2026-01-01'
 GROUP BY u.user_id,
          u.first_name,
          u.last_name
HAVING SUM(o.amount) > 500
 ORDER BY amount_total DESC;

Deuxième exemple.

Version sale :

select date(created_at) d, count(*) c from orders group by date(created_at) order by d;

Version propre :

SELECT DATE(created_at) AS created_date,
       COUNT(*) AS order_count
  FROM orders
 GROUP BY DATE(created_at)
 ORDER BY created_date;

Troisième exemple.

Version sale :

select p.name, sum(ol.qty*ol.price) ca from order_line ol join product p on p.id=ol.product_id group by p.name order by ca desc;

Version propre :

SELECT p.product_name,
       SUM(ol.quantity * ol.unit_price) AS revenue_total
  FROM order_line AS ol
  JOIN product AS p
    ON p.product_id = ol.product_id
 GROUP BY p.product_name
 ORDER BY revenue_total DESC;

Quatrième exemple.

Version sale :

select * from customers where city='Paris' or city='Lyon' or city='Marseille';

Version propre :

SELECT *
  FROM customer
 WHERE city IN ('Paris', 'Lyon', 'Marseille');

Cinquième exemple.

Version sale :

select id,case when score>80 then 'ok' else 'ko' end s from tests;

Version propre :

SELECT test_id,
       CASE
           WHEN score > 80 THEN 'passed'
           ELSE 'failed'
       END AS test_result
  FROM tests;

Sixième exemple.

Version sale :

select c.id,c.name,(select count(*) from orders o where o.customer_id=c.id) nb_orders from customers c;

Version propre :

SELECT c.customer_id,
       c.customer_name,
       (
           SELECT COUNT(*)
             FROM orders AS o
            WHERE o.customer_id = c.customer_id
       ) AS order_count
  FROM customer AS c;

Septième exemple avec CTE.

WITH monthly_orders AS (
    SELECT DATE_TRUNC('month', created_at) AS order_month,
           COUNT(order_id) AS order_count,
           SUM(amount) AS amount_total
      FROM orders
     WHERE order_status = 'paid'
     GROUP BY DATE_TRUNC('month', created_at)
)
SELECT order_month,
       order_count,
       amount_total
  FROM monthly_orders
 ORDER BY order_month;

Huitième exemple sur des événements analytics :

SELECT session_id,
       user_id,
       event_name,
       event_timestamp
  FROM analytics_events
 WHERE event_name IN ('page_view', 'purchase', 'generate_lead')
   AND event_timestamp >= '2026-01-01T00:00:00';

Neuvième exemple avec enrichissement métier :

SELECT session_source,
       session_medium,
       COUNT(DISTINCT session_id) AS session_count,
       COUNT(DISTINCT user_id) AS user_count,
       CASE
           WHEN session_medium = 'cpc' THEN 'paid'
           WHEN session_medium = 'organic' THEN 'organic'
           WHEN session_medium = 'email' THEN 'owned'
           ELSE 'other'
       END AS channel_grouping
  FROM analytics_sessions
 GROUP BY session_source,
          session_medium;

Dixième exemple avec gestion propre des NULL :

SELECT order_id,
       delivered_at,
       CASE
           WHEN delivered_at IS NULL THEN 'not_delivered'
           ELSE 'delivered'
       END AS delivery_status
  FROM orders;

Comment relire une requête SQL avant de la valider ?

Avant de considérer qu’une requête est propre, je passe mentalement sur une série de points très simples :

• les mots-clés SQL sont-ils bien visibles ?
• les colonnes ont-elles des noms explicites ?
• les alias aident-ils à comprendre ?
• les JOIN sont-ils lisibles ?
• les conditions du WHERE sont-elles structurées ?
• les agrégats ont-ils des alias compréhensibles ?
• la logique métier est-elle explicite quand elle le mérite ?
• les dates sont-elles non ambiguës ?
• les commentaires servent-ils vraiment à quelque chose ?
• la requête peut-elle être relue vite sans effort inutile ?

Si la réponse est non sur plusieurs de ces points, je réécris. Je ne négocie pas longtemps avec un SQL sale. Ça ne vaut jamais le coup.

Qu’apporte concrètement un bon style SQL au quotidien ?

Un bon style SQL n’est pas là pour flatter l’ego du développeur ou donner l’illusion d’une sophistication technique. Il apporte des bénéfices très concrets.

Je relis plus vite. Les autres relisent plus vite. Les erreurs logiques sautent davantage aux yeux. Les revues de code deviennent moins pénibles. Les différences Git sont plus propres. Les refactors sont moins risqués. L’onboarding d’une nouvelle personne est plus simple.

Et dans les environnements data, analytics engineering ou BI, c’est encore plus important. Une requête SQL n’est pas juste un bout de code isolé. Elle nourrit souvent un rapport, un dashboard, une alerte, un export, un modèle dbt, une table de travail ou un pipeline métier. Quand le SQL est sale, toute la chaîne devient plus fragile.

Pourquoi adopter un guide de style SQL dans une équipe ?

Le style SQL n’est pas un détail. C’est une méthode de travail.

Le guide de Holywell donne une excellente base : nommage cohérent, structure visuelle nette, alias utiles, usage raisonné des formes les plus lisibles, et attention constante à la maintenabilité.

Ensuite, le plus important reste la cohérence. Une équipe n’a pas besoin de débattre pendant des heures sur chaque virgule. Elle a besoin d’un cadre simple et appliqué partout.

Mon objectif n’est jamais d’écrire du SQL “joli”. Mon objectif est d’écrire du SQL que je peux relire rapidement, comprendre sans friction, corriger sans stress et transmettre sans honte.

Et dans un vrai projet, c’est déjà une énorme victoire.