BI self-service garde-fous simples

Rendre la BI en self-service ne veut pas dire laisser tout faire. L’objectif est de donner de l’autonomie aux équipes tout en protégeant la qualité et la cohérence des chiffres. Avec quelques garde-fous simples, on évite les silos, les doublons et les malentendus.

prérequis

catalogue de datasets validés et sandbox.
règles d’accès et d’usage écrites en une page.
un canal support pour questions et request.

aperçu rapide

séparer datasets validés et sandbox clairement.
documenter les définitions clés (KPIs, timeframes, périmètres).
mettre en place RLS/CLS et des vues prêtes à l’emploi.
limiter les ressources (quotas) et surveiller l’usage.
instaurer une revue légère avant publication large.
tenir un changelog visible des breaking changes.

carte mentale des principes

tutoriel pas-à-pas

étape 1 cadrer le périmètre self-service

Lister les domaines, définir les owners, préciser la distinction prod vs sandbox.

cat > self_service_scope.md <<'EOF'
domaines: sales, marketing, product
datasets validés: sales.orders_v, marketing.campaigns_v, product.events_v
datasets sandbox: *_sandbox (tables temporaires, retention 14 jours)
publication: review 10 min, owner + audience + doc courte
EOF

étape 2 exposer des vues prêtes et stables

Créer des vues suffixes _v avec colonnes propres, types castés, unités standardisées. La couche sémantique est critique.

-- vue validée: commandes des 12 derniers mois
CREATE OR REPLACE VIEW sales.orders_v AS
SELECT
  order_id,
  customer_id,
  order_date::date AS date,
  amount_eur::numeric(12,2) AS amount_eur,
  country
FROM sales.orders
WHERE order_date >= (CURRENT_DATE - INTERVAL '12 month');

étape 3 protéger par la ligne (RLS) et le catalogue

Appliquer Row-Level Security et afficher les règles dans le catalogue.

-- exemple RLS: accès par country
ALTER TABLE sales.orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY rls_orders_by_country ON sales.orders
USING (country = current_setting('app.country')::text);

# extrait de fiche catalogue
dataset: sales.orders_v
owner: sales
access: "RLS par country, voir policy rls_orders_by_country"
kpi_definition:
  - revenue_30d: "SUM(amount_eur) sur 30d rolling, country = context"
changelog:
  - "2020-10-20: ajout colonne country, recalcul revenue_30d"

étape 4 limiter les coûts et prévenir les abus

Mettre des quotas simples, des timeouts, et des alertes sur les queries lourdes.

# quotas (exemple)
echo "max_query_time_sec=120"   >> bi_policies.conf
echo "max_concurrency=3"        >> bi_policies.conf
echo "scan_soft_limit_gb=5"     >> bi_policies.conf

-- détecter les slow queries (30 derniers jours)
SELECT user_email, COUNT(*) AS queries_2min_plus
FROM query_logs
WHERE duration_ms >= 120000
  AND ts >= CURRENT_DATE - INTERVAL '30 day'
GROUP BY user_email
ORDER BY queries_2min_plus DESC;

étape 5 publier, signaler, itérer

Un clic ne suffit pas. Il faut une doc courte, des exemples, et un contact owner.

fiche minimale de publication
- quoi: orders_v, commandes clean 12 mois
- target: sales, finance, product
- exemples:
  1) Revenue 30d par country
  2) Top 50 customers 90d
- limites: lag data week-end, pas de multi-currency
- contact: owner: sales@example.com

exemples

cas marketing en autonomie sans casser la prod

-- KPI: CPA 30d par campaign (vues et montants standardisés)
SELECT
  DATE_TRUNC('day', date) AS d,
  campaign_id,
  ROUND(SUM(spend_eur)/NULLIF(SUM(conversions),0),2) AS cpa_30d
FROM marketing.campaigns_v
WHERE date >= CURRENT_DATE - INTERVAL '30 day'
GROUP BY d, campaign_id
ORDER BY d DESC, campaign_id;

note: la vue campaigns_v masque les colonnes techniques, impose l’unité EUR et filtre les status obsolètes.

erreurs courantes et solutions

tout exposer brut -> confusion -> vues validées + sandbox limité, fiches claires
définitions mouvantes -> débats -> glossaire KPI versionné
accès manuel -> data leaks -> RLS/CLS et rôles, jamais de copies locales
coûts qui explosent -> surprises -> quotas simples, alertes, review mensuelle usage
publications orphelines -> tech debt -> owner nommé, contact visible, deprecation plan
exemples absents -> low adoption -> 2 à 3 queries prêtes à copier par dataset

faq

faut-il un outil de plus pour réussir le self-service ? Non. Commencez avec la stack actuelle, mais imposez vues stables, RLS et doc courte.
comment éviter les sources de vérité multiples ? Metrics layer ou vues validées + glossaire; tout le reste pointe vers ces couches.
et si une team a besoin d’un champ custom ? Passage par sandbox, PR sur la vue, review rapide. Si utile, on merge.

Menu