🎯 Situation

Lors d'un comité de direction, le CFO d'un client a présenté un chiffre d'affaires de 1,1 M$ pour le trimestre. Le directeur commercial avait un chiffre différent — 1,2 M$ — dans sa présentation. Le CEO a demandé à l'IT de sortir le "vrai" chiffre. L'IT est revenu avec 1,15 M$.

Trois chiffres différents. Une seule entreprise. Un seul trimestre. Les trois équipes étaient convaincues d'avoir raison.

👉 Elles avaient toutes raison — et c'était exactement le problème. Chaque équipe mesurait le chiffre d'affaires différemment, depuis des systèmes différents, avec des filtres différents. Personne n'avait tort. Mais personne n'était d'accord. Et les décisions étaient prises dans l'écart entre ces chiffres.

C'est l'un des problèmes data les plus fréquents et les plus coûteux dans les entreprises en croissance. Et SQL est l'une des façons les plus propres de le résoudre.

⚠️ Challenge

Quand différentes équipes calculent le même KPI de façon indépendante, on n'obtient pas une mauvaise réponse — on obtient plusieurs réponses défendables. Chacune a sa logique. Aucune ne correspond.

📈 Chiffre d'affaires commercial (1,2 M$)

  • Extrait du CRM : toutes les opportunités marquées "Gagnées"
  • Inclut les deals facturés en T1 mais payés en T2
  • Utilise la valeur contractuelle, pas le paiement reçu
  • Exclut les remboursements traités après la clôture mensuelle

📊 Chiffre d'affaires finance (1,1 M$)

  • Extrait de l'ERP : factures avec paiement confirmé
  • Trésorerie reçue pendant le trimestre uniquement
  • Inclut les remboursements et avoirs
  • Exclut les revenus des contrats différés

Aucune définition n'est fausse. Mais elles répondent à des questions différentes. Le problème n'est pas la donnée — c'est l'absence d'une définition commune stockée en un seul endroit depuis lequel chaque rapport s'alimenterait.

🔍 Comment SQL résout ça

Les vues SQL sont la solution standard à ce problème. Une vue est une requête sauvegardée — un calcul nommé qui vit dans la base de données et peut être référencé par tout outil qui s'y connecte.

Au lieu que chaque équipe écrive sa propre version du "chiffre d'affaires" dans son propre tableur ou outil BI, on l'écrit une seule fois en SQL, on la stocke comme vue, et chaque dashboard, chaque rapport et chaque analyste utilise cette définition unique :

CREATE VIEW vw_ca_trimestriel AS
SELECT
    DATE_TRUNC('quarter', date_facture)   AS trimestre,
    SUM(montant_facture)                  AS ca_brut,
    SUM(montant_remboursement)            AS remboursements,
    SUM(montant_facture - montant_remboursement) AS ca_net
FROM factures
WHERE statut_paiement = 'confirme'
  AND date_facture >= '2026-01-01'
GROUP BY DATE_TRUNC('quarter', date_facture);

La définition est maintenant documentée, versionnée et partagée. Les ventes, la finance et l'IT interrogent tous vw_ca_trimestriel. Si la définition doit changer — par exemple, l'entreprise décide de passer de la comptabilité de caisse à la comptabilité d'engagement — on met à jour la vue en un seul endroit. Tous les rapports se mettent à jour automatiquement.

La vue ne fait pas que corriger le chiffre — elle force la conversation métier qui aurait dû avoir lieu en premier : que signifie "chiffre d'affaires" pour nous exactement ? Une fois cette conversation tenue et la réponse écrite en SQL, le débat s'arrête.

✓️ Bonne pratique : une couche KPIs en SQL

L'approche la plus robuste consiste à construire une couche KPIs dédiée dans ta base centrale — un ensemble de vues qui définissent chaque métier métier en un seul endroit :

  • Une vue par KPI — vw_ca, vw_taux_churn, vw_panier_moyen, vw_marge_par_produit
  • Nommage cohérent — préfixer toutes les vues KPIs avec vw_kpi_ pour que les analystes sachent exactement où chercher
  • Commentaires dans le SQL — documenter la définition métier directement dans la requête avec des -- commentaires : ce qui est inclus, exclu, et pourquoi
  • Power BI se connecte aux vues — pas aux tables brutes. La couche BI reste propre ; la logique vit dans SQL

Quand un nouvel analyste rejoint l'équipe, il n'a pas besoin de demander "comment calcule-t-on le churn ?" — il lit vw_kpi_taux_churn et la réponse est là, avec la logique métier documentée en ligne.

💡 Synthèse

Des KPIs différents selon les équipes, ce n'est pas un problème de qualité des données — c'est un problème de définition. Les données sont généralement correctes. Les définitions ne sont juste pas alignées.

SQL règle ça en faisant de la définition une partie de l'infrastructure :

  • Écrire la définition du KPI une seule fois — sous forme de vue SQL dans la base centrale
  • Avoir la conversation métier en premier — que signifie exactement "chiffre d'affaires" pour nous ? Faire se mettre d'accord tout le monde avant d'écrire une seule ligne de code
  • Connecter tous les rapports à la vue — Power BI, Excel, tout outil qui interroge la base utilise la même source
  • La versionner et la documenter — si la définition change, mettre à jour la vue et documenter pourquoi

Le débat en comité de direction sur le chiffre d'affaires n'est pas un problème technologique. C'est un problème de gouvernance que la technologie peut faire respecter une fois que l'entreprise a décidé quelle devait être la réponse.

👉 Quand deux personnes regardent les mêmes données et voient des chiffres différents, le problème n'est pas la donnée.

C'est l'absence d'une définition partagée. SQL, c'est là où tu l'écris.