Single Source of Truth (SSoT)

Définition complète

La single source of truth — SSoT, traduite parfois par « source unique de vérité » — est un principe d'architecture de données et de gouvernance selon lequel chaque métrique critique de l'entreprise est définie et calculée à un seul endroit canonique que toutes les équipes consultent. Ce principe s'applique aux métriques composites — celles qui combinent plusieurs systèmes : ARR, NRR, CAC, marge de contribution, taux de conversion bout en bout — bien plus qu'aux données brutes elles-mêmes. La SSoT n'est pas un outil : c'est une discipline organisationnelle soutenue par un outil.

Une SSoT brisée se reconnaît à un symptôme universel : deux équipes rapportent des chiffres différents pour la même réalité économique. Le marketing annonce 4,2 M€ de pipeline ouvert ; les ventes annoncent 3,6 M€. La finance annonce 28 % de marge brute ; les opérations annoncent 33 %. Ces écarts ne viennent presque jamais d'une erreur de calcul. Ils viennent d'une divergence de définition : quels stages comptent dans le pipeline ? Quels coûts sont alloués à la marge brute ? Sans définition canonique, chaque équipe applique sa propre logique, et chaque logique a sa propre légitimité partielle.

Le concept trouve ses racines dans l'ingénierie logicielle des années 1990, où il désignait la pratique consistant à éviter la duplication d'information dans une base de données relationnelle. Il a été repris dans les années 2010 par les équipes data modernes pour décrire un objectif plus large : faire en sorte que la couche analytique de l'entreprise repose sur des définitions versionnées, auditables et partagées par toutes les équipes consommatrices. La popularisation des couches sémantiques (semantic layers) et des metric stores au début des années 2020 est la conséquence directe de ce besoin.

La SSoT n'exige pas un système monolithique : elle exige une définition unique par métrique. Le CRM reste la source du pipeline brut, l'ERP reste la source des transactions financières, l'outil produit reste la source de l'usage. La couche sémantique au-dessus de ces systèmes joue le rôle de SSoT pour les métriques composites — celles qui agrègent plusieurs sources. C'est cette couche qui doit être versionnée, auditée et reconnue par toutes les équipes comme la référence officielle.

Comment implémenter une SSoT

La mise en place d'une SSoT n'est pas un projet IT : c'est un projet de gouvernance, soutenu par une architecture technique. Les étapes ci-dessous sont celles observées chez les entreprises qui ont réussi à éliminer durablement les débats sur les chiffres en comité opérationnel.

1. 1

   Inventorier les métriques critiques. Lister les 10 à 15 métriques les plus discutées en comité opérationnel : revenu, ARR, NRR, CAC, marge de contribution, pipeline qualifié, taux de conversion par stage, churn. C'est l'inventaire minimal viable.

2. 2

   Cartographier les définitions existantes. Pour chaque métrique, identifier toutes les définitions actuellement utilisées dans l'entreprise — par équipe, par dashboard, par export Excel. L'écart est presque toujours plus grand que prévu : 4 à 5 définitions différentes de l'ARR ne sont pas rares.

3. 3

   Choisir la définition canonique. Pour chaque métrique, réunir les équipes concernées et trancher une définition unique. La discussion est souvent inconfortable car elle implique de renoncer à des conventions locales. La règle d'arbitrage : la définition canonique est celle qui sert le mieux la décision opérationnelle, pas celle qui flatte le plus les chiffres.

4. 4

   Implémenter dans une couche sémantique. Coder la définition canonique dans une couche sémantique (semantic layer) ou un metric store, alimenté automatiquement depuis les sources opérationnelles. Versionner le code de définition comme du code applicatif, avec revue par les pairs et historique des changements.

5. 5

   Faire converger toutes les équipes. Déprécier les dashboards et exports qui calculent leur propre version. Communiquer la SSoT comme la seule référence reconnue. La discipline est culturelle autant que technique : sans engagement explicite de la direction, les définitions locales reviennent en quelques mois.

Exemple concret

Prenons une scale-up française de logistique B2B, 60 salariés, qui réalise 12 M€ de chiffre d'affaires annuel. Lors d'un comité de pilotage mensuel, le directeur commercial annonce un pipeline ouvert de 8,4 M€ et un taux de conversion moyen de 26 %. Le directeur financier conteste : son tableau de bord, alimenté par un export du CRM le matin même, affiche 6,9 M€ de pipeline et un taux de conversion de 31 %. Le comité passe les 40 minutes suivantes à réconcilier les chiffres et reporte la décision d'investissement marketing à la réunion du mois suivant.

Après enquête, la cause est identifiée : le directeur commercial inclut dans son pipeline les opportunités au stade Discovery, alors que le directeur financier ne compte que les opportunités à partir du stade Proposal. Le taux de conversion suit la même logique : le directeur commercial calcule la conversion sur l'ensemble du pipeline, le directeur financier sur le pipeline qualifié. Aucun des deux n'a tort. Il n'y a simplement pas de définition canonique du « pipeline ouvert » dans l'entreprise.

La direction décide d'établir une SSoT. Après deux ateliers réunissant ventes, marketing et finance, la définition canonique retenue est : pipeline qualifié = somme des opportunités aux stades Proposal, Negotiation et Verbal Commit, avec un montant supérieur à 5 000 €, créées dans les 12 derniers mois. Cette définition est implémentée dans la couche sémantique de la plateforme d'operating intelligence. Trois mois plus tard, le débat sur les chiffres a disparu des comités. Le temps gagné est réinvesti dans des décisions opérationnelles concrètes : allocation budgétaire par canal, priorisation des segments, ajustement du quota commercial.

Analyse approfondie

La SSoT est l'un des principes les plus simples à énoncer et l'un des plus difficiles à mettre en œuvre durablement. Sa difficulté ne tient pas à la technique — les couches sémantiques modernes (dbt Semantic Layer, Cube, LookML, AtScale, Fairview) sont matures depuis 2022 — mais à la gouvernance. Choisir une définition canonique signifie souvent renoncer à des conventions locales que des équipes ont construites pendant des années. Cette renonciation est politique avant d'être technique. Sans engagement explicite et répété de la direction, les définitions locales réapparaissent en quelques mois.

Le coût d'une SSoT brisée se mesure sur trois dimensions économiques. Premièrement, le temps de réconciliation : dans les entreprises observées sans SSoT, les comités opérationnels passent en moyenne 40 à 60 % de leur durée à débattre des chiffres au lieu de décider. Sur un comité hebdomadaire de 90 minutes, c'est 45 minutes perdues chaque semaine, soit environ 39 heures de cadres dirigeants par an, par comité. Multiplié par trois ou quatre comités, le coût devient significatif. Deuxièmement, les décisions reportées : quand un chiffre est contesté, la décision est reportée à la réunion suivante. Sur un cycle bi-mensuel, c'est deux semaines perdues à chaque cycle. Troisièmement, l'érosion de la confiance : à force de chiffres contradictoires, les équipes finissent par construire leur propre version locale, ce qui aggrave structurellement le problème.

Une SSoT correctement implémentée ne remplace pas les sources de données opérationnelles — CRM, ERP, produit, marketing automation. Elle s'installe au-dessus de ces sources comme une couche d'agrégation et de définition. La distinction est importante : la SSoT n'est pas un système monolithique qui remplace tout, mais une couche fine qui réconcilie. Les sources opérationnelles restent les SSoT de leurs données brutes respectives. La couche sémantique est la SSoT des métriques composites qui combinent plusieurs sources.

Le versioning des définitions est un aspect souvent négligé. Une définition canonique évolue : le périmètre du « pipeline qualifié » peut changer quand l'entreprise lance un nouveau segment, le calcul du CAC peut s'affiner quand on isole le coût d'acquisition par canal. Chaque évolution doit être documentée, versionnée et historisée — exactement comme du code applicatif. Sans ce versioning, les comparaisons historiques deviennent impossibles : la croissance apparente d'un trimestre peut être un simple effet de définition. Les outils modernes de couche sémantique gèrent ce versioning nativement.

Les plateformes d'operating intelligence existent en grande partie pour être la SSoT des métriques opérationnelles. Elles agrègent les données CRM, ERP, produit, marketing et finance dans une couche sémantique unifiée, exposent les métriques composites aux équipes opérationnelles via des dashboards et des alertes, et versionnent les définitions pour garantir la traçabilité historique. Sans cette couche, la SSoT reste un objectif théorique. Avec elle, elle devient une réalité opérationnelle vérifiable chaque semaine en comité.

Erreurs fréquentes

• ✗

  Confondre SSoT et système unique : la SSoT n'exige pas que toute l'entreprise utilise le même outil. Elle exige que chaque métrique critique ait une définition canonique unique. Le CRM reste la source du pipeline brut, l'ERP reste la source des transactions, le produit reste la source de l'usage. La couche sémantique au-dessus est la SSoT des métriques composites — pas un remplaçant des sources opérationnelles.

• ✗

  Implémenter la SSoT dans un tableur : un tableur partagé n'est pas une SSoT. Sa logique de calcul est implicite, il se duplique à chaque téléchargement, et son alimentation manuelle introduit délai et erreur. Une SSoT exige une logique versionnée, une alimentation automatique et un point d'accès unique. La couche sémantique moderne est l'outil natif de la SSoT.

• ✗

  Lancer la SSoT sans engagement de la direction : la mise en place d'une SSoT exige de renoncer à des conventions locales que des équipes ont construites pendant des années. Sans engagement explicite et répété de la direction — y compris la sanction des dashboards parallèles qui réapparaissent — les définitions locales reviennent en quelques mois. La technique ne suffit pas : la gouvernance est le facteur déterminant.

Comment Fairview établit la SSoT

Fairview est conçu pour être la SSoT des métriques opérationnelles. La plateforme se connecte à votre CRM (Salesforce, HubSpot, Pipedrive), à votre ERP, à votre outil de facturation (Stripe, Chargebee) et à votre data warehouse. Vous définissez chaque métrique critique — pipeline qualifié, ARR récurrent qualifié, marge de contribution, CAC par canal — une seule fois, dans une couche sémantique versionnée. Toutes les équipes consultent la même définition, alimentée automatiquement à chaque mise à jour des sources. L'historique des définitions est conservé : si la formule du CAC évolue, les comparaisons historiques restent traçables. Les comités opérationnels cessent de débattre des chiffres et se concentrent sur les décisions.

Questions fréquentes