ARCHITECTURE & CULTURE

Chargeback et Showback

Sans visibilité sur qui consomme quoi, il n'y a pas de responsabilisation. Le showback et le chargeback sont les mécanismes qui rendent les coûts visibles et actionnables.

C'est souvent le point de bascule entre une organisation qui subit ses coûts data et une organisation qui les pilote.

Showback vs Chargeback

Note

Showback : montrer les coûts

Rendre visible la consommation de chaque équipe, projet ou pipeline. Pas de facturation interne, mais de la transparence. C'est la première étape, et souvent suffisante pour déclencher des comportements vertueux.

Succes

Chargeback : imputer les coûts

Facturer les coûts au budget de chaque équipe. Plus contraignant à mettre en place mais beaucoup plus incitatif. L'équipe qui consomme est celle qui paie.

Attention

Recommandation : commencez toujours par le showback. C'est plus simple à mettre en place, moins politique, et dans 70% des cas, la simple visibilité suffit à réduire les coûts de 20-30%. Le chargeback viendra naturellement quand l'organisation sera prête.

Pourquoi c'est essentiel

Sans allocation des coûts, la facture data cloud est un bloc opaque imputé à « l'IT » ou « la data team » dans sa globalité. Personne ne se sent responsable, personne n'optimise.

Le showback crée un effet miroir : quand une équipe voit qu'elle représente 40% de la facture BigQuery, elle commence naturellement à se poser des questions. J'ai vu des équipes réduire leur consommation de 30% en un mois, simplement parce qu'elles ont découvert que leurs pipelines full-refresh tournaient toutes les heures au lieu d'une fois par jour.

À retenir

Le showback fonctionne par la transparence, pas par la culpabilisation. Présentez les coûts comme une information factuelle, pas comme un reproche. L'objectif est que chaque équipe comprenne sa contribution et identifie ses leviers d'optimisation.

Situation	Sans showback	Avec showback
Pipeline coûteux	Personne ne le sait	L'équipe voit le coût et réagit
Requête ad-hoc massive	Noyée dans le total	Identifiée et attribuée
Nouveau projet data	Pas de budget prévu	Estimation basée sur l'historique
Objectif de réduction	Impossible à découper	Objectif par équipe

Modèles d'allocation des coûts

Allocation directe

Chaque ressource est attribuée à une équipe. Sur Snowflake, c'est naturel avec les warehouses dédiés : le warehouse de l'équipe Analytics coûte X, celui de l'équipe Data Engineering coûte Y. Sur BigQuery, c'est plus complexe car le compute est partagé.

Allocation proportionnelle

Les coûts des ressources partagées sont répartis au prorata de l'utilisation. Par exemple, si l'équipe A représente 60% des bytes scannés sur BigQuery, elle se voit imputer 60% du coût compute.

Allocation hybride (recommandé)

Les coûts directement attribuables (warehouses dédiés, storage par dataset) sont imputés directement. Les coûts partagés sont répartis proportionnellement. C'est le modèle le plus juste et le plus actionnable.

Décision concrète

Pour démarrer, choisissez un critère d'allocation simple : par dataset pour le storage, par utilisateur ou service account pour le compute. La perfection viendra plus tard. Un modèle simple appliqué vaut mieux qu'un modèle parfait jamais déployé.

Implémentation sur BigQuery

Sur BigQuery, l'allocation repose sur INFORMATION_SCHEMA.JOBS qui contient l'historique de toutes les requêtes avec leur coût.

-- Coût par équipe (basé sur le user_email, 30 derniers jours)
-- Prérequis : convention de nommage email → équipe
SELECT
  CASE
    WHEN user_email LIKE '%@analytics.%' THEN 'Analytics'
    WHEN user_email LIKE '%@data-eng.%'  THEN 'Data Engineering'
    WHEN user_email LIKE 'svc-dbt%'      THEN 'Pipelines dbt'
    WHEN user_email LIKE 'svc-airflow%'  THEN 'Orchestration'
    ELSE 'Autres'
  END AS team,
  COUNT(*) AS query_count,
  ROUND(SUM(total_bytes_billed) / POW(1024, 4), 2) AS total_tb,
  ROUND(SUM(total_bytes_billed) / POW(1024, 4) * 6.25, 2) AS cost_eur
FROM `region-eu`.INFORMATION_SCHEMA.JOBS
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
  AND state = 'DONE'
GROUP BY team
ORDER BY cost_eur DESC;

-- Coût par projet/dataset (pour allocation storage)
SELECT
  table_schema AS dataset,
  ROUND(SUM(total_logical_bytes) / POW(1024, 3), 2) AS size_gb,
  ROUND(SUM(total_logical_bytes) / POW(1024, 3) * 0.02, 2) AS storage_cost_eur_month
FROM `project`.region-eu.INFORMATION_SCHEMA.TABLE_STORAGE
GROUP BY dataset
ORDER BY storage_cost_eur_month DESC;

À retenir

Utilisez des labels BigQuery sur les jobs pour tagger automatiquement les requêtes par équipe, projet ou pipeline. C'est plus fiable que le mapping par email. Imposez les labels via des policies Terraform ou des wrappers dans vos outils d'orchestration.

Erreur fréquente

Mapper les coûts par email sans convention de nommage. Quand quelqu'un quitte l'entreprise ou change d'équipe, l'historique devient illisible. Préférez les service accounts avec des noms explicites pour les pipelines.

Implémentation sur Snowflake

Sur Snowflake, l'allocation est plus naturelle grâce aux warehouses dédiés. Chaque warehouse a un coût directement mesurable en credits.

-- Coût par warehouse (30 derniers jours)
SELECT
  warehouse_name,
  ROUND(SUM(credits_used), 2) AS total_credits,
  ROUND(SUM(credits_used) * 3.00, 2) AS cost_eur  -- $3/credit Enterprise
FROM snowflake.account_usage.warehouse_metering_history
WHERE start_time > DATEADD('day', -30, CURRENT_TIMESTAMP())
GROUP BY warehouse_name
ORDER BY total_credits DESC;

-- Coût par utilisateur (pour les warehouses partagés)
SELECT
  user_name,
  warehouse_name,
  COUNT(*) AS query_count,
  ROUND(SUM(execution_time) / 1000 / 3600, 2) AS compute_hours,
  ROUND(SUM(bytes_scanned) / POW(1024, 4), 2) AS tb_scanned
FROM snowflake.account_usage.query_history
WHERE start_time > DATEADD('day', -30, CURRENT_TIMESTAMP())
GROUP BY user_name, warehouse_name
ORDER BY compute_hours DESC
LIMIT 20;

Le rapport mensuel de showback

Un bon rapport de showback doit être simple, visuel et actionnable. Voici la structure que je recommande :

RAPPORT SHOWBACK MENSUEL
│
├── 1. Résumé exécutif
│   ├── Coût total du mois : XX XXX €
│   ├── Evolution MoM : +/-X%
│   └── Top 3 équipes par coût
│
├── 2. Répartition par équipe
│   ├── [Graphique] Camembert des coûts par équipe
│   ├── [Tableau] Détail par équipe : compute, storage, total
│   └── [Tendance] Evolution sur 3 mois glissants
│
├── 3. Top 10 postes de coût
│   ├── Les 10 pipelines/requêtes les plus coûteux
│   └── Potentiel d'optimisation estimé
│
├── 4. Anomalies du mois
│   ├── Pics de consommation identifiés
│   └── Causes et actions prises
│
└── 5. Recommandations
    ├── Top 3 actions à fort ROI
    └── Objectif pour le mois suivant

Succes

Conseil : envoyez ce rapport automatiquement par email/Slack le 3ème jour ouvrable du mois. L'automatisation garantit la régularité. Un rapport manuel finit toujours par être oublié.

Pièges à éviter

Attention

Précision excessive

Ne cherchez pas l'allocation au centime près. Une répartition à 90% correcte est suffisante et bien plus facile à maintenir. L'objectif est la responsabilisation, pas la comptabilité analytique.

Attention

Chargeback sans showback préalable

Imputer des coûts à des équipes qui n'ont jamais eu de visibilité crée de la résistance et de la méfiance. Toujours commencer par au moins 2-3 mois de showback.

Attention

Ignorer les coûts partagés

Les coûts « communs » (infrastructure de base, monitoring, etc.) doivent être identifiés séparément. Les imputer arbitrairement à une équipe fausse l'analyse.

Jonathan Kini

J'aide les équipes data à réduire et maîtriser leurs coûts BigQuery et Snowflake, sans sacrifier la performance. 8 ans de terrain, de la startup aux environnements data à grande échelle.

LinkedIn À propos