Auditer une data stack SaaS : un parcours de diagnostic

Un VPVPFormulation claire des bénéfices apportés par votre produit, des problèmes qu'il résout et des raisons pour lesquelles les clients doivent vous choisir plutôt qu'une alternative.Voir la définition complète → Analytics d'un éditeur SaaS mid-market ouvre deux dashboards avant un conseil d'administration. Le premier indique une croissance des utilisateurs actifs mensuels de 12 %. Le second, construit à partir du même flux d'événements, indique 4 %. Les deux sont « live » depuis des mois. Personne ne l'a vu parce que personne n'auditait le pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète → : on se contentait d'en consommer les résultats. Cela arrive en permanence, et c'est la raison pour laquelle les audits de données figurent désormais en point fixe des revues opérationnelles SaaS.

Cette leçon parcourt une data stack SaaS type, couche par couche, en montrant ce qui casse, comment le repérer et ce qu'il faut vérifier de façon récurrente.

L'anatomie d'une data stack SaaS

La plupart des sociétés SaaS font tourner une variante de ce pipeline :

1. Flux d'événements produit : l'instrumentation (via des outils comme Segment, Amplitude ou un SDK maison) qui capte les actions utilisateur (signup_completed, feature_used, subscription_upgraded).
2. Couche d'ingestion : achemine les événements vers le stockage, souvent via une CDPCDPLogiciel 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 → (customer data platform) ou un outil de streaming (Kafka, Fivetran).
3. 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 → : le magasin analytique (Snowflake, BigQuery, Databricks) où résident les données brutes et transformées.
4. Couche de transformation : les outils de modélisation 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 → (dbt domine) qui transforment les événements bruts en tables propres, exploitables par le business.
5. Couche BI : les dashboards (Looker, Tableau, Mode) que les utilisateurs métier voient réellement.

Chaque passage de relais entre ces couches est un endroit où la confiance s'érode. Auditer, c'est vérifier chaque jointure, pas seulement le dashboard final.

Couche 1 : le flux d'événements et le schemaschemaUn schema est le plan formel qui définit comment les données sont structurées, nommées, typées et reliées entre elles au sein d'une base de données, d'un fichier ou d'un message.Voir la définition complète → drift

Le schema drift, c'est quand la structure des données entrantes change sans prévenir : un champ est renommé, un type passe de string à integer, un nouvel événement en remplace un ancien, et rien n'est signalé en aval.

Exemple : l'engineering renomme plan_type en subscription_tier lors d'un refactor. Le dashboard qui suit la conversion vers l'upgrade, construit sur plan_type, cesse silencieusement de se mettre à jour. Il ne renvoie pas d'erreur : il se fige ou retourne des nulls, et souvent personne ne s'en aperçoit pendant des semaines.

Ce qu'il faut vérifier :

• Des tests de schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → tournent-ils à l'ingestion (vérification de la présence des champs attendus, correspondance des types) ?
• Existe-t-il un data contractdata contractAccord formel entre l'équipe qui produit les données et celles qui les consomment, fixant structure, sens, qualité et responsabilité en cas de rupture.Voir la définition complète → entre produit/engineering et analytics, c'est-à-dire un accord documenté sur les noms d'événements, les propriétés obligatoires et le processus de notification des changements ?
• À quand remonte la dernière réconciliation du tracking plan (la spécification maîtresse des événements censés se déclencher et de leur contenu) avec les événements réellement présents dans le warehouse ?

Une ressource gratuite et pratique sur la discipline du tracking plan : la documentation tracking plan de Segment, un modèle raisonnable même si vous n'utilisez pas Segment.

Couche 2 : ingestion et événements orphelins

Les événements orphelins sont des enregistrements qui arrivent dans le warehouse mais ne peuvent être rattachés à rien de significatif : un événement feature_used sans user_id correspondant, ou un identifiant utilisateur absent de la table users parce que le compte a été supprimé ou que le format d'ID a changé.

Les événements orphelins comptent parce qu'ils dégonflent ou gonflent discrètement les métriques. Si 8 % de vos événements feature_used ne peuvent pas être joints à un compte valide (fourchette plausible citée dans les audits de qualité de données, à considérer comme une estimation, les taux réels variant beaucoup d'une entreprise à l'autre), votre taux d'adoption de la fonctionnalité est faux d'environ cette marge, dans le sens où les données orphelines biaisent le calcul.

Vérification rapide, exemple chiffré :

Admettons que votre warehouse enregistre 500 000 événements feature_used sur un mois. Une jointure avec la table dim_users retourne 460 000 lignes appariées.

orphan_rate = (500,000 - 460,000) / 500,000 = 8.0%

Un taux d'orphelins de 8 % est un seuil courant à partir duquel les équipes commencent à investiguer (certaines fixent l'alerte à 2 ou 5 %, plus serré pour les événements critiques pour la facturation). En dessous de 1 à 2 % environ, il s'agit souvent de bruit de fond lié à des décalages temporels (un utilisateur agit juste avant que la suppression de son compte se propage). Au-delà, cela signale généralement une clé de jointure cassée ou un bug d'intégration.

Ce qu'il faut vérifier :

• Quel pourcentage des événements clés échoue à se joindre à une entité valide (user, account, subscription) ?
• Existe-t-il une dead-letter queue (zone de rétention des événements dont le traitement a échoué) que quelqu'un consulte réellement ?

Couche 3 : le warehouse, doublons et enregistrements manquants

Deux modes de défaillance courants à cette couche :

• Duplication : la logique de retry d'une intégration API renvoie le même événement, ce qui gonfle les comptages. Un webhook Stripe rejoué trois fois peut tripler le comptage d'un événement subscription_created s'il n'y a pas de clé d'idempotence (un identifiant unique garantissant qu'un même événement n'est pas traité deux fois).
• Données arrivées en retard : des événements d'usage issus d'un SDK mobile qui les met en lot et ne les synchronise qu'à la réouverture de l'app, ce qui fait paraître le dashboard de la veille artificiellement bas avant une « révision à la hausse » quelques jours plus tard.

Ce qu'il faut vérifier :

• L'évolution du nombre de lignes des tables clés : les pics ou chutes soudains méritent une investigation.
• Existe-t-il des tests dbt d'unicité et de non-nullité sur les clés primaires ?

Un test dbt minimal, qui vérifie que subscription_id est unique et jamais null :

models:
  - name: fct_subscriptions
    columns:
      - name: subscription_id
        tests:
          - unique
          - not_null

C'est un correctif de cinq minutes qui empêche toute une catégorie de bugs de duplication silencieuse d'atteindre un dashboard.

Couche 4 : BI et dashboards obsolètes

Les dashboards obsolètes sont ceux qui tournent encore, ont encore bonne allure, mais reflètent un modèle de données cassé ou périmé. Causes possibles : une table amont a cessé de se rafraîchir, un filtre a été codé en dur sur une ancienne plage de dates, ou la définition de la métrique sous-jacente a changé sans que le dashboard soit reconstruit.

Une étude sectorielle de 2023 menée par Monte Carlo (éditeur de data observability) a montré que les équipes data des organisations types passent une part significative de leur temps à éteindre des incendies de qualité de données plutôt qu'à faire de l'analyse proactive ; les pourcentages exacts sont à traiter comme des estimations d'éditeur, mais la tendance est bien corroborée dans la communauté data engineering.

Ce qu'il faut vérifier :

• Propriétaire du dashboard et date de dernière vérification : si un dashboard n'a pas de propriétaire nommé, considérez qu'il n'est pas maintenu.
• Métadonnées de fraîcheur : l'outil BI indique-t-il la date du dernier rafraîchissement des données sous-jacentes ?
• Cohérence des définitions de métriques : « utilisateur actif » est-il défini une seule fois, de façon centralisée (idéalement dans une metrics layer comme la semantic layer de dbt ou un outil comme Cube), ou redéfini au cas par cas dans chaque dashboard ?

Construire la checklist d'audit récurrente

Un audit n'est pas un nettoyage ponctuel, c'est une cadence. Une checklist trimestrielle exploitable :

Flux d'événements

• Réconcilier le tracking plan avec les événements live du warehouse.
• Confirmer que les notifications de changement de schéma parviennent réellement à l'analytics, et pas seulement aux canaux Slack de l'engineering.

Ingestion

• Calculer le taux d'orphelins des 5 événements les plus critiques pour le business.
• Vérifier la tendance du volume de la dead-letter queue.

Warehouse

• Exécuter les tests d'unicité/non-nullité sur les clés primaires des tables de faits principales (subscriptions, invoices, usage).
• Contrôler par sondage les tendances de nombre de lignes pour repérer les pics inexpliqués.

Couche BI

• Auditer la propriété des dashboards : chaque dashboard doit avoir un propriétaire nommé, sinon il est archivé.
• Vérifier les 10 principaux dashboards destinés au comité de direction contre des requêtes SQL de référence.
• Confirmer que les définitions de métriques vivent en un seul endroit central, sans duplication d'un outil à l'autre.

Gouvernance

• Documenter qui peut modifier les schémas, qui approuve les nouveaux événements, qui est notifié des changements cassants.

Cela recoupe étroitement ce que le champ de la data observability appelle les « cinq piliers » (fraîcheur, distribution, volume, schéma, lineage), un framework popularisé par Monte Carlo et aujourd'hui largement repris dans le secteur ; voir cette présentation accessible de dbt Labs sur les tests de données.

🎬 [VIDEO: "Data Observability Explained" - youtube.com/@MonteCarloData - un parcours concis du framework fraîcheur, volume, schéma, distribution et lineage appliqué à des pipelines réels]

Points clés

• Le schema drift, les événements orphelins et les dashboards obsolètes sont les trois principaux destructeurs de confiance dans les data stacks SaaS ; chacun correspond à une couche différente (flux d'événements, ingestion, BI).
• Le taux d'orphelins est une métrique quantifiable et suivable : calculez-le comme (événements totaux − événements joignables) / événements totaux, et fixez un seuil d'alerte (souvent 2 à 5 %, plus élevé pour les événements exploratoires, plus bas pour ceux critiques pour la facturation).
• Chaque dashboard a besoin d'un propriétaire et d'une date de dernière vérification ; les dashboards sans propriétaire sont la source par défaut des métriques périmées et contradictoires.
• Les tests ont leur place en amont, pas seulement en BI : les tests d'unicité et de non-nullité dans la couche de transformation (via dbt ou équivalent) attrapent la duplication avant qu'elle n'atteigne un board deck.
• Les audits sont une cadence, pas un nettoyage : construisez une checklist trimestrielle couvrant flux d'événements, ingestion, warehouse, BI et gouvernance, et attribuez une responsabilité explicite pour chaque couche.