Sur mon mandat, SQL Server est partout. Pis j’ai remarqué une affaire: le même produit vit une double vie. Pour le dev, c’est un jouet pratique — on crée une base en deux clics, on bricole, on teste. Pour la production, c’est un vrai moteur qui demande de la discipline. Le piège, c’est de traiter le deuxième comme le premier.

Quand je développe, je m’en fous un peu des index, des transactions, des plans d’exécution. Ça marche sur ma base de test avec mes 100 lignes. Mais le jour où la même requête roule sur 2 millions de lignes en production, le jouet montre les dents.

La requête qui réveille

-- Sur ma base de test: instantané
-- En production sur 2M de lignes: 40 secondes
SELECT c.nom, SUM(f.montant) AS total
FROM clients c
JOIN factures f ON f.client_id = c.id
WHERE f.date_facture >= '2005-01-01'
GROUP BY c.nom
ORDER BY total DESC;

La même requête, deux mondes. En dev, elle répond avant que je lève le doigt de la touche. En prod, sans le bon index sur f.client_id pis f.date_facture, elle scanne toute la table pis fige l’application. Le moteur fait exactement ce que je lui demande — c’est moi qui pensais encore en mode jouet.

Le déclic de discipline

Depuis, je regarde le plan d’exécution avant de livrer. Est-ce qu’y’a un index? Est-ce que je ramène juste les colonnes dont j’ai besoin? Est-ce que ma transaction garde un verrou trop longtemps? Ces questions-là, le jouet me les pose jamais. Le vrai moteur, lui, me les pose à la dure quand c’est trop tard.

Ce que j’en retiens

SQL Server entre jouet de dev pis vrai moteur, c’est la même boîte avec deux niveaux d’exigence. Mon erreur de jeunesse, c’était de croire que « ça marche sur ma machine » voulait dire « ça va marcher en production ». La maturité, comme dev, c’est de traiter la base de données avec le respect d’un moteur — index, plans, volumétrie — même quand mon petit test de 100 lignes me dit que tout est beau.