Quand j’enseigne le SQL à mes étudiants en BTS SIO, la fonction ROUND revient systématiquement dès qu’on manipule des montants, des moyennes ou des pourcentages. Elle semble simple à utiliser, et c’est justement ce qui la rend dangereuse. J’ai vu des projets en entreprise accumuler des écarts de centimes pendant des mois parce qu’un développeur avait placé un ROUND au mauvais endroit dans sa requête. Dans ce guide, je vous explique comment utiliser round sql correctement, les pièges que je rencontre le plus souvent et les alternatives à connaître pour chaque situation.

Syntaxe de ROUND en SQL : les bases à maîtriser

La fonction ROUND() en SQL permet d’arrondir une valeur numérique à un nombre de décimales spécifié. Sa syntaxe de base est identique sur la plupart des SGBD :

ROUND(valeur_numerique, nombre_decimales)

Le premier paramètre est la valeur à arrondir : une colonne, un calcul ou une constante. Le second paramètre indique le nombre de chiffres après la virgule que vous souhaitez conserver. Si vous l’omettez, la plupart des SGBD arrondissent à l’entier le plus proche.

Voici quelques exemples concrets pour bien comprendre :

SELECT ROUND(15.7836, 2);   -- Résultat : 15.78
SELECT ROUND(15.7856, 2);   -- Résultat : 15.79
SELECT ROUND(15.7856, 0);   -- Résultat : 16
SELECT ROUND(15.7856);      -- Résultat : 16 (sans second paramètre)

Un point que mes étudiants oublient souvent : le second paramètre peut être négatif. Dans ce cas, l’arrondi s’applique à gauche de la virgule. C’est utile pour arrondir à la dizaine, à la centaine ou au millier le plus proche :

SELECT ROUND(1234.56, -1);  -- Résultat : 1230
SELECT ROUND(1234.56, -2);  -- Résultat : 1200
SELECT ROUND(1234.56, -3);  -- Résultat : 1000

Cette possibilité est particulièrement pratique pour générer des rapports statistiques où la précision au centime n’a pas de sens. Par exemple, quand je travaille sur des dashboards de chiffre d’affaires, j’arrondis souvent au millier pour améliorer la lisibilité.

Comment arrondir une colonne en SQL avec ROUND

Comment arrondir une colonne en SQL ? La question revient dans chaque promotion. La réponse est directe : il suffit de passer le nom de la colonne en premier paramètre de ROUND(). Voici un exemple sur une table produits contenant un prix unitaire :

SELECT 
    nom_produit,
    prix_unitaire,
    ROUND(prix_unitaire, 2) AS prix_arrondi
FROM produits;

Cette requête crée une colonne calculée prix_arrondi sans modifier les données en base. C’est un point essentiel : ROUND ne modifie pas la valeur stockée, elle transforme uniquement le résultat affiché. Si vous souhaitez modifier la donnée, il faut un UPDATE :

UPDATE produits
SET prix_unitaire = ROUND(prix_unitaire, 2)
WHERE prix_unitaire != ROUND(prix_unitaire, 2);

J’ajoute toujours la clause WHERE pour ne toucher que les lignes réellement concernées. Cela évite de déclencher des triggers inutilement et réduit le temps d’exécution sur les tables volumineuses.

ROUND s’utilise aussi dans des calculs combinés. Par exemple, pour calculer un prix TTC arrondi à partir d’un prix HT :

SELECT 
    nom_produit,
    prix_ht,
    ROUND(prix_ht * 1.20, 2) AS prix_ttc
FROM produits;

On peut combiner ROUND avec des fonctions d’agrégation comme AVG en SQL pour obtenir des moyennes lisibles. Quand je forme mes étudiants sur les jointures et les agrégations, c’est un réflexe que j’installe dès le départ :

SELECT 
    categorie,
    ROUND(AVG(prix_unitaire), 2) AS prix_moyen
FROM produits
GROUP BY categorie;

Sans le ROUND, AVG renvoie souvent des résultats avec 10 à 15 décimales selon le SGBD, ce qui est illisible dans un rapport. Pour mieux structurer vos requêtes complexes avec des jointures, je vous recommande de consulter mon guide sur SQL WHERE et LEFT JOIN qui détaille comment combiner ces clauses proprement.

Différences de comportement entre SGBD

C’est ici que les ennuis commencent. La fonction ROUND existe sur tous les SGBD relationnels, mais son comportement varie sur les cas limites, notamment quand le chiffre à arrondir est exactement 5. Je vais être précise, car c’est une source de bugs que j’ai rencontrée en production.

Le cas de Round sql server mérite une attention particulière. SQL Server propose un troisième paramètre optionnel. Quand il vaut 0 (ou est absent), la fonction arrondit normalement. Quand il vaut 1, elle tronque au lieu d’arrondir :

-- SQL Server uniquement
SELECT ROUND(15.789, 2, 0);  -- Résultat : 15.790 (arrondi)
SELECT ROUND(15.789, 2, 1);  -- Résultat : 15.780 (troncature)

PostgreSQL a un comportement subtil : pour les types numeric et decimal, il utilise l’arrondi bancaire (« half to even »), aussi appelé arrondi du banquier. Cela signifie que 2.5 s’arrondit à 2 (pair) et 3.5 à 4 (pair). Ce comportement réduit les biais statistiques sur de grands ensembles de données. En revanche, pour les types float et double precision, PostgreSQL utilise l’arrondi classique. Comme l’explique la documentation officielle de PostgreSQL sur les fonctions mathématiques, ce choix dépend directement du type de données utilisé.

Cette différence de comportement est critique si vous migrez une base de données d’un SGBD à un autre. J’ai accompagné une migration MySQL vers PostgreSQL où les totaux de facturation ne correspondaient plus : l’écart venait précisément de cette divergence sur les arrondis.

Les pièges classiques des arrondis en SQL

Après plusieurs années d’enseignement et de développement, j’ai identifié quatre pièges récurrents avec ROUND en SQL. Je les présente dans l’ordre de fréquence que j’observe chez mes étudiants et en entreprise.

Piège 1 : arrondir trop tôt dans la chaîne de calcul

C’est le piège numéro un. Quand vous appliquez ROUND à chaque étape intermédiaire d’un calcul, les erreurs d’arrondi se cumulent. Prenons un exemple concret :

-- MAUVAISE APPROCHE : arrondi à chaque étape
SELECT 
    ROUND(prix_ht * 1.20, 2) AS prix_ttc,
    ROUND(ROUND(prix_ht * 1.20, 2) * quantite, 2) AS total_ligne
FROM lignes_commande;

-- BONNE APPROCHE : arrondir une seule fois à la fin
SELECT 
    ROUND(prix_ht * 1.20 * quantite, 2) AS total_ligne
FROM lignes_commande;

Sur une commande de 500 lignes, la différence entre les deux approches peut atteindre plusieurs euros. En contexte comptable, cela rend vos états financiers incohérents.

Piège 2 : confondre arrondi et format d’affichage

ROUND modifie la valeur numérique. Si vous voulez simplement afficher deux décimales sans changer la valeur, utilisez FORMAT ou CAST. Par exemple, ROUND(10.0, 2) renvoie 10.0 sur certains SGBD, pas 10.00. Pour forcer l’affichage, préférez :

-- Forcer l'affichage à 2 décimales
SELECT CAST(prix AS DECIMAL(10,2)) FROM produits;
-- Ou en SQL Server
SELECT FORMAT(prix, 'N2') FROM produits;

Piège 3 : utiliser ROUND dans une clause WHERE

Comparer des valeurs arrondies dans un WHERE est risqué. L’arrondi empêche l’utilisation des index et peut donner des résultats inattendus :

-- ÉVITER : pas d'utilisation d'index, résultats imprécis
SELECT * FROM produits WHERE ROUND(prix, 2) = 19.99;

-- PRÉFÉRER : utiliser une plage
SELECT * FROM produits WHERE prix BETWEEN 19.985 AND 19.995;

Quand je documente ce type de subtilité dans mes projets, j’utilise systématiquement des commentaires SQL pour expliquer pourquoi une approche a été choisie plutôt qu’une autre.

Piège 4 : ignorer la représentation en virgule flottante

Les types FLOAT et DOUBLE ne stockent pas les décimales de manière exacte. Un nombre qui semble valoir 2.5 peut en réalité valoir 2.4999999999 en mémoire. ROUND appliqué sur cette valeur donne 2 au lieu de 3. La solution : toujours utiliser les types DECIMAL ou NUMERIC pour les montants financiers. La documentation MySQL sur les types DECIMAL détaille les garanties de précision offertes par ce type.

Alternatives à ROUND : FLOOR, CEIL et TRUNCATE

Comment arrondir un nombre en SQL quand ROUND ne correspond pas au besoin ? Trois fonctions alternatives couvrent la majorité des cas. Je les présente avec leur comportement sur des valeurs positives et négatives, car c’est souvent source de confusion.

FLOOR SQL : arrondi à l’entier inférieur

Floor sql renvoie le plus grand entier inférieur ou égal à la valeur. Attention, « inférieur » signifie vers moins l’infini, pas vers zéro :

SELECT FLOOR(3.7);    -- Résultat : 3
SELECT FLOOR(-3.7);   -- Résultat : -4 (pas -3 !)
SELECT FLOOR(3.0);    -- Résultat : 3

FLOOR est utile pour calculer des tranches (âge, prix, catégories) ou pour un sql arrondi supérieur quand on le combine avec une logique conditionnelle.

CEIL (ou CEILING) : arrondi à l’entier supérieur

CEIL renvoie le plus petit entier supérieur ou égal à la valeur. C’est la fonction que je recommande quand vous cherchez un sql server arrondi supérieur systématique :

SELECT CEIL(3.2);     -- Résultat : 4
SELECT CEIL(-3.2);    -- Résultat : -3
SELECT CEIL(3.0);     -- Résultat : 3

Un cas d’usage classique : calculer le nombre de pages nécessaires pour afficher des résultats paginés.

-- Nombre de pages pour afficher tous les produits (10 par page)
SELECT CEIL(COUNT(*) / 10.0) AS nombre_pages
FROM produits;

TRUNCATE (ou TRUNC) : couper sans arrondir

TRUNCATE supprime les décimales excédentaires sans arrondir. C’est l’équivalent d’un ciseau : on coupe, on ne négocie pas.

SELECT TRUNCATE(3.789, 2);   -- Résultat : 3.78 (MySQL)
SELECT TRUNC(3.789, 2);      -- Résultat : 3.78 (PostgreSQL, Oracle)

En SQL Server, TRUNCATE n’existe pas en tant que fonction mathématique. On utilise à la place ROUND avec le troisième paramètre à 1, comme je l’ai montré plus haut.

Bonnes pratiques pour arrondir en SQL sans erreur

Après avoir identifié les pièges, voici les règles que j’applique systématiquement dans mes projets et que je transmets à mes étudiants. Ces pratiques s’appuient sur des retours d’expérience concrets en production.

1. Utiliser le type DECIMAL pour les montants financiers. Je déclare toujours mes colonnes de prix en DECIMAL(10,2) ou DECIMAL(10,4) selon la précision requise. Cela garantit que la base stocke la valeur exacte, sans les approximations des types flottants. Un DECIMAL(10,2) peut stocker des valeurs allant de -99 999 999.99 à 99 999 999.99, ce qui couvre la majorité des cas métier.

2. Arrondir le plus tard possible. Effectuez tous vos calculs intermédiaires avec la précision maximale. N’appliquez ROUND qu’au dernier SELECT, celui qui produit le résultat final affiché à l’utilisateur ou envoyé au rapport.

3. Documenter vos choix d’arrondi. Quand je choisis ROUND plutôt que TRUNCATE pour un calcul de TVA, j’ajoute un commentaire SQL qui explique pourquoi. Six mois plus tard, quand un autre développeur reprend le code, il comprend immédiatement la logique. L’utilisation de commentaires bien structurés évite des heures de débogage.

4. Tester les cas limites. Avant de déployer une requête avec ROUND, je vérifie toujours le comportement sur les valeurs 0.5, -0.5, NULL et 0. C’est un réflexe qui m’a évité plusieurs bugs en production :

-- Script de test des cas limites
SELECT 
    ROUND(0.5, 0)   AS demi,
    ROUND(-0.5, 0)   AS demi_negatif,
    ROUND(NULL, 2)   AS valeur_null,
    ROUND(0, 2)      AS zero;

Sur la plupart des SGBD, ROUND(NULL, 2) renvoie NULL. Si votre colonne peut contenir des valeurs nulles, pensez à encadrer ROUND avec COALESCE :

SELECT ROUND(COALESCE(prix, 0), 2) AS prix_arrondi
FROM produits;

5. Vérifier la cohérence des totaux. Quand vous arrondissez des lignes individuellement, la somme des arrondis peut différer de l’arrondi de la somme. C’est un problème mathématique connu que je montre à chaque promotion :

-- Démonstration de l'écart
SELECT 
    SUM(ROUND(montant, 2)) AS somme_des_arrondis,
    ROUND(SUM(montant), 2) AS arrondi_de_la_somme
FROM lignes_facture;

La différence est généralement de quelques centimes, mais en comptabilité, chaque centime compte. La pratique standard est de calculer le total exact puis d’arrondir une seule fois.

Cas pratiques : ROUND dans des requêtes réelles

Pour conclure la partie technique, voici trois scénarios que je rencontre régulièrement en cours et en entreprise. Ils montrent comment utiliser la fonction ROUND() en SQL de manière pertinente.

Cas 1 : calcul de remise avec arrondi

Un site e-commerce applique une remise de 15 % sur certains produits. Le prix final doit être arrondi à 2 décimales :

SELECT 
    p.nom_produit,
    p.prix_ht,
    r.pourcentage_remise,
    ROUND(p.prix_ht * (1 - r.pourcentage_remise / 100.0) * 1.20, 2) AS prix_ttc_remise
FROM produits p
INNER JOIN remises r ON p.id_categorie = r.id_categorie
WHERE r.date_fin >= CURRENT_DATE;

Remarquez que je multiplie par 100.0 (avec un point décimal) et non par 100. Cela force une division en virgule flottante plutôt qu’une division entière, ce qui évite une perte de précision silencieuse.

Cas 2 : rapport de performance avec moyennes arrondies

Pour générer un rapport mensuel avec des indicateurs lisibles, je combine ROUND avec plusieurs fonctions d’agrégation. Quand ces rapports nécessitent l’union de plusieurs sources de données, la maîtrise de SQL UNION devient indispensable :

SELECT 
    departement,
    COUNT(*) AS nb_employes,
    ROUND(AVG(salaire), 0) AS salaire_moyen,
    ROUND(MIN(salaire), 0) AS salaire_min,
    ROUND(MAX(salaire), 0) AS salaire_max,
    ROUND(AVG(salaire) / MAX(salaire) * 100, 1) AS ratio_moyen_max
FROM employes
GROUP BY departement
ORDER BY salaire_moyen DESC;

Ici, j’arrondis à 0 décimale pour les salaires (personne ne regarde les centimes dans un rapport RH) et à 1 décimale pour le ratio qui est un pourcentage.

Cas 3 : correction de données existantes

Lors d’une migration de base de données, il arrive que des colonnes contiennent des valeurs avec trop de décimales suite à des conversions de types. Voici comment nettoyer :

-- Vérifier les lignes concernées
SELECT COUNT(*) 
FROM transactions 
WHERE montant != ROUND(montant, 2);

-- Corriger en une seule passe
UPDATE transactions
SET montant = ROUND(montant, 2)
WHERE montant != ROUND(montant, 2);

Je précède toujours un UPDATE massif d’un SELECT COUNT pour évaluer l’impact. Sur une table de plusieurs millions de lignes, c’est un réflexe de prudence essentiel. Pour les projets qui combinent SQL et PHP, le typage strict avec les enums PHP permet de s’assurer que les valeurs arrondies restent cohérentes côté applicatif.

Comment utiliser la fonction round de manière optimale ? La réponse tient en une phrase : appliquez-la uniquement quand vous savez pourquoi vous arrondissez, à quel moment du calcul, et avec quel type de données. Tout le reste est de la technique que vous maîtrisez maintenant.

Lucie Moreau

Formatrice IT indépendante depuis 2016, ancienne étudiante BTS SIO SLAM. 6 ans d'expérience en entreprise.