Cartographier le paysage data en SaaS : sources, systèmes et propriétaires

Dans une entreprise SaaS de taille moyenne, une seule inscription à un free trial peut déclencher des écritures dans six systèmes différents en moins de dix secondes : un événement de product analytics, un lead dans le CRMCRMCustomer Relationship Management : logiciel et stratégie pour gérer et analyser les interactions clients tout au long de leur cycle de vie.Voir la définition complète →, une coquille de compte de facturation, un touchpoint d'attribution marketingattribution marketingUn framework qui attribue le crédit d'une conversion aux différents touchpoints y ayant contribué, afin de mesurer quels canaux et quelles interactions génèrent réellement des résultats.Voir la définition complète →, un flag d'éligibilité au support et un job de synchronisation vers le data warehousedata warehouseUn référentiel central qui consolide les données de nombreux systèmes sources dans un stockage structuré et optimisé pour les requêtes, conçu pour l'analytique, le reporting et la business intelligence.Voir la définition complète →. Aucun de ces systèmes ne s'accorde sur la façon de nommer le client. Voilà le paysage data en SaaS, et le cartographier est le premier travail de quiconque fait de l'analytics, de la finance ou des ops dans le secteur.

Pourquoi cartographier les sources avant de toucher à un dashboard

La plupart des « problèmes de data » en SaaS ne sont pas des problèmes d'analytics. Ce sont des problèmes de propriété. Un chiffre de churn semble faux non pas parce que le SQLSQLSales Qualified Lead : un prospect que l'équipe commerciale a validé comme prêt pour une prise de contact directe et une proposition, après avoir passé des critères de qualification explicites.Voir la définition complète → est mauvais, mais parce que la facturation définit le « client » comme un abonnement actif alors que le produit le définit comme un workspace connecté.

Une source map est un artefact simple : pour chaque jeu de données, qui le possède, où il réside, à quoi il sert et ce qui le casse. Avant de construire des métriques, construisez cette carte. Elle évite le mode de défaillance le plus courant de l'analytics SaaS : deux équipes présentant des chiffres différents pour « la même » métrique au même comité.

Les cinq sources de données centrales en SaaS

1. Télémétrie produit (données d'usage)

Il s'agit de données au niveau événement : connexions, clics, adoption de fonctionnalités, appels APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète →, durée de session. Capturées via des outils d'instrumentation comme Amplitude, Mixpanel ou Segment (une customer data platformcustomer data platformLogiciel qui unifie les données client de toutes les sources en un profil unique et durable, exploitable par le marketing, les ventes et le service.Voir la définition complète →, CDP, qui route les événements vers plusieurs destinations).

• Propriétaire : en général Product ou Data Engineering.
• Casse typique : dérive d'instrumentation. Un développeur renomme un événement (« signup_complete » devient « user_created ») et trois mois de courbes de tendance se cassent silencieusement. Aucune erreur n'est levée, la donnée signifie simplement autre chose sans bruit.
• Grain : généralement au niveau événement, horodaté, rattaché à un user ID ou un account ID.

2. Données de facturation et d'abonnement

Elles vivent dans des systèmes comme Stripe, Chargebee ou Zuora. C'est le système de référence pour le MRRMRRMonthly Recurring Revenue : le revenu mensuel récurrent, prévisible et normalisé, issu des abonnements actifs. La métrique de référence des activités SaaS et par abonnement.Voir la définition complète → (monthly recurring revenue), le palier de plan, le nombre de sièges, les remises et le statut de paiement.

• Propriétaire : Finance, parfois RevOps.
• Casse typique : identités clients désalignées entre facturation et CRM (une entreprise renommée dans Salesforce mais pas dans Stripe), et remises manuelles qui ne remontent pas dans les systèmes de reporting.
• Grain : niveau compte/abonnement, généralement mensuel ou déclenché par événement (upgrade, downgrade, résiliation).

3. Données CRM (customer relationship management)

Enregistrements Salesforce ou HubSpot : leads, opportunités, étapes de deal, termes contractuels, dates de renouvellement. C'est le récit du client côté vente.

• Propriétaire : Sales Ops / RevOps.
• Casse typique : champs obsolètes ou saisis manuellement. Un commercial oublie de mettre à jour l'étape du deal ; les prévisions construites sur les données CRM deviennent peu fiables. Également des doublons de comptes quand plusieurs commerciaux crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éent des fiches distinctes pour la même entreprise.

4. Données support et customer success

Tickets Zendesk, Intercom ou Gainsight, enquêtes NPS (Net Promoter Score), health scores. Cela capte le sentiment client et les frictions.

• Propriétaire : Customer Success / Support.
• Casse typique : health scores construits sur des snapshots d'usage périmés, ou volume de tickets confondu avec insatisfaction (un power user ouvre beaucoup de tickets parce qu'il utilise intensivement le produit, pas parce qu'il est mécontent).

5. Données marketing et acquisition

Plateformes publicitaires (Google Ads, LinkedIn), web analytics (GA4) et outils d'attribution. Elles capturent les intrants du CAC (customer acquisition cost) : dépense, canal, campagne, conversion.

• Propriétaire : Marketing / Growth.
• Casse typique : désaccords sur les modèles d'attribution (last-touch vs multi-touch), et restrictions cookies/consentement liées au RGPD (Règlement général sur la protection des données, la loi européenne sur la vie privée) ou au CCPA (California Consumer Privacy Act) qui réduisent le trafic traçable, en particulier en Europe après 2018 et de plus en plus aux États-Unis depuis 2020.

Construire la source map : un modèle pratique

Une source map exploitable comporte cinq colonnes. Voici un exemple condensé :

La colonne critique que la plupart des équipes sautent est « défaillance courante ». Nommer le mode de défaillance à l'avance, c'est ce qui permet de construire un monitoring dessus, plutôt que de le découvrir pendant une revue en comité.

Le problème de l'identity resolution

La raison pour laquelle ces cinq systèmes ne s'accordent pas naturellement : chacun utilise une clé différente.

• La télémétrie produit s'appuie sur un device ID ou un user ID.
• La facturation s'appuie sur un ID de compte/abonnement.
• Le CRM s'appuie sur une fiche entreprise/contact.

Réconcilier tout cela s'appelle l'identity resolution, et cela passe généralement par une table de mapping des customer ID maintenue dans le data warehouse (Snowflake, BigQuery, Databricks sont les plateformes courantes en 2026).

Une requête de mapping simplifiée ressemble à ceci :

-- Identity resolution simplifiée : jointure de l'usage produit avec le compte de facturation
SELECT
    p.user_id,
    p.account_id AS product_account_id,
    b.subscription_id,
    b.crm_account_id,
    c.salesforce_account_name
FROM product_events p
LEFT JOIN billing_accounts b
    ON p.account_id = b.external_account_id
LEFT JOIN crm_accounts c
    ON b.crm_account_id = c.account_id
WHERE p.event_date >= CURRENT_DATE - INTERVAL '30 days';

Si product_account_id et crm_account_id ne se mappent pas de façon fiable en 1:1, toute métrique de churn ou d'expansion basée sur l'usage en aval est suspecte. Cette jointure qui échoue silencieusement est l'une des causes racines les plus fréquentes des incidents du type « les chiffres du dashboard ne correspondent pas » dans les entreprises SaaS.

Pour une référence technique plus poussée sur ce type de discipline de pipeline, le glossaire de dbt Labs est une introduction solide et gratuite aux concepts d'analytics engineering évoqués tout au long de ce module.

Qui possède quoi : un point de réalité sur la gouvernance

Les litiges de propriété sont la norme, pas l'exception, dans la data SaaS. Quelques schémas à connaître :

• Les entreprises product-led growth (PLG) (motion type Notion, Figma) tendent à confier au Product la définition client faisant autorité, puisque l'usage porte le business. La facturation est souvent en aval et plus légère.
• Le SaaS enterprise sales-led (motion traditionnelle type Salesforce) tend à faire du CRM la « source of truth » pour l'identité des comptes, la télémétrie produit étant traitée comme complémentaire.
• Les conseils de data governance, courants à l'échelle (Série C+ ou entreprises cotées), formalisent cela en assignant un data steward par domaine : une personne nommée, responsable des définitions, pas seulement de l'outillage de qualité de données.

Frameworks de gouvernance à connaître par leur nom : le DAMA-DMBOK (Data Management Body of Knowledge) est le framework de référence standard pour les rôles et responsabilités en data governance, utile si vous voulez un vocabulaire formel pour ces conversations sur la propriété.

🎬 [VIDEO : « Data Governance Explained » - youtube.com - cherchez des interventions récentes DAMA ou Data Council expliquant les modèles de stewardship et de propriété dans les stacks data SaaS modernes]

Où cela casse en pratique : trois cas réels

1. L'événement renommé. L'engineering livre un refactor, renomme trial_started en trial_activated. Le dashboard d'activation du Growth s'écrase à plat. Personne ne le remarque pendant deux semaines parce qu'aucune alerte n'était rattachée au volume de cet événement.

1. La dérive d'identité facturation/CRM. Un client est racheté par une autre entreprise, renommé dans Salesforce, mais le compte Stripe affiche toujours l'ancienne raison sociale. Le reporting de revenus par « client » sous-compte le nombre réel de logos.

1. La guerre de l'attribution. Le marketing reporte le CAC en attribution last-touch ; la finance reporte le CAC en divisant la dépense fully-loaded par les nouveaux logos. Les deux sont « corrects » selon leur propre définition. Sans source map documentée, cela devient une dispute récurrente et improductive plutôt qu'une réconciliation de cinq minutes.

Points clés à retenir

• La data SaaS provient de cinq systèmes centraux : télémétrie produit, facturation, CRM, support/success et marketing. Chacun a son propriétaire, son grain et son mode de défaillance typique.
• Construisez une source map (jeu de données, système, propriétaire, grain, défaillance courante) avant de construire des métriques. C'est le moyen le plus rapide d'éviter des chiffres contradictoires en comité de direction.
• L'identity resolution, la réconciliation des différents schémas d'ID entre systèmes, est la cause racine la plus fréquente des incidents « les chiffres ne correspondent pas ».
• La propriété suit le business model : les entreprises PLG s'ancrent sur la donnée produit, les entreprises sales-led sur la donnée CRM. Sachez dans quel modèle vous êtes avant de décider quel chiffre fait autorité.
• Les frameworks de gouvernance comme DAMA-DMBOK vous donnent un vocabulaire formel (data steward, système de référence) pour trancher les litiges de propriété plutôt que de les rejouer chaque trimestre.