Connecter l'analyse à votre stack : 5 modèles d'intégration API

L'analyse devient exponentiellement plus utile dès qu'elle quitte le tableau de bord et commence à alimenter le reste de votre stack. Voici cinq modèles d'intégration concrets — du simple digest quotidien à l'entrepôt BI complet — avec la structure de code pour chacun.

Le tableau de bord est un point de départ, pas une destination

Chaque outil d'analyse est livré avec un tableau de bord, et pour la plupart des équipes, c'est là que l'utilisation s'arrête. Vous vous connectez, regardez les chiffres, vous déconnectez. Les données sont prisonnières de l'interface.

C'est une occasion manquée. L'analyse devient bien plus précieuse lorsqu'elle cesse d'être un endroit séparé que vous visitez et commence à être un signal qui circule dans les systèmes que vous utilisez déjà : le Slack de votre équipe, vos rapports de business intelligence, votre CRM, vos alertes opérationnelles. Le tableau de bord devient la vue par défaut — mais il n'est plus le seul.

La clé est une API publique avec une authentification simple par clé. Une fois que vous l'avez, chaque modèle ci-dessous n'est qu'à un petit script de distance.

Modèle 1 : le digest Slack du lundi matin

L'intégration la plus simple et la plus rentable. Chaque lundi à 9h, un script récupère les statistiques de la semaine écoulée, les formate en un court message et le publie dans un canal Slack.

#!/bin/bash
# weekly-digest.sh — run via cron Mondays 09:00

LOGLY_KEY=$LOGLY_KEY
SITE=my-blog
WEBHOOK=$SLACK_WEBHOOK

stats=$(curl -sH "Authorization: Bearer $LOGLY_KEY" \
  "https://app.logly.uk/api/sites/$SITE/stats?days=7")

pv=$(echo "$stats" | jq -r '.totals.pageviews')
prev=$(echo "$stats" | jq -r '.prev_totals.pageviews')
delta=$(awk "BEGIN { print (($pv - $prev) / $prev) * 100 }")

curl -X POST -H 'Content-Type: application/json' \
  -d "{\"text\":\"📊 Last 7 days: *$pv pageviews* (${delta}% vs prev week)\"}" \
  "$WEBHOOK"

Vingt lignes de bash, zéro maintenance continue, les données arrivent là où votre équipe vit déjà. C'est le type d'intégration qui se construit en 30 minutes et fonctionne de manière fiable pendant des années.

Pourquoi c'est plus important qu'il n'y paraît

La plupart des équipes souffrent du problème « on devrait regarder l'analyse plus souvent ». La solution n'est pas plus de discipline — c'est de mettre les chiffres pertinents devant les gens automatiquement, dans le canal qu'ils consultent déjà. Un digest du lundi dans #marketing ou #product transforme la conversation de « je devrais me connecter au tableau de bord » à « intéressant que le trafic était en hausse — quelqu'un sait pourquoi ? ». C'est le petit changement comportemental qui transforme l'analyse d'une chose que vous avez en une chose que vous utilisez.

Modèle 2 : joindre le trafic et les revenus dans une feuille de calcul

Vous gérez un produit SaaS et vous voulez savoir quels canaux d'acquisition génèrent réellement des clients payants — pas seulement des inscriptions, pas seulement des essais, mais des clients payants. Aucun tableau de bord unique ne peut répondre à cette question car les données se trouvent à trois endroits : le trafic dans votre analyse, les inscriptions dans votre base de données produit, les abonnements dans Stripe.

Un pull planifié vers Google Sheets fait le lien :

// Google Apps Script — runs daily, appends to a tab
function updateAnalyticsRow() {
  const url = "https://app.logly.uk/api/sites/my-saas/stats?days=1";
  const r = UrlFetchApp.fetch(url, {
    headers: { Authorization: "Bearer " + PropertiesService.getScriptProperties().getProperty('LOGLY_KEY') }
  });
  const data = JSON.parse(r.getContentText());
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('Daily traffic');
  const today = Utilities.formatDate(new Date(), 'UTC', 'yyyy-MM-dd');
  sheet.appendRow([today, data.totals.pageviews, data.totals.sessions, data.totals.visitors]);
}

Ajoutez des pulls similaires pour les inscriptions (depuis votre export de base de données) et les abonnements (depuis l'API de Stripe). Trois onglets dans une feuille, deux jours d'effort. Désormais, votre rapport aux investisseurs dispose d'un graphique intitulé « Revenus par canal d'acquisition » qu'aucun tableau de bord individuel n'aurait pu produire.

Modèle 3 : entrepôt BI avec Metabase, Looker Studio ou Superset

Quand l'approche par feuille de calcul commence à craquer sous son propre poids, l'étape suivante est un véritable entrepôt. Postgres, BigQuery, DuckDB, ou ce que votre équipe préfère. Le modèle est identique quelle que soit la base de données : planifiez un pull quotidien, ajoutez à une table, pointez un outil BI dessus.

# Python — runs daily, appends to Postgres
import os, requests, psycopg2, csv, io

LOGLY_KEY = os.environ['LOGLY_KEY']
DB = psycopg2.connect(os.environ['DATABASE_URL'])

r = requests.get(
    'https://app.logly.uk/api/sites/my-site/export',
    params={'type': 'daily', 'days': 2},
    headers={'Authorization': f'Bearer {LOGLY_KEY}'},
)
reader = csv.DictReader(io.StringIO(r.text))

with DB.cursor() as cur:
    for row in reader:
        cur.execute("""
          INSERT INTO analytics_daily (date, pageviews, sessions, visitors, avg_duration_s, bounce_rate)
          VALUES (%(date)s, %(pageviews)s, %(sessions)s, %(visitors)s, %(avg_duration_s)s, %(bounce_rate)s)
          ON CONFLICT (date) DO UPDATE SET
            pageviews = EXCLUDED.pageviews,
            sessions  = EXCLUDED.sessions
        """, row)
DB.commit()

L'endpoint d'export CSV fait le gros du travail — une requête HTTP, tous les agrégats quotidiens, parsés par la bibliothèque standard de Python. Une fois les données dans Postgres, chaque outil BI qui existe peut les interroger. Vous n'êtes plus dépendant de ce que le tableau de bord d'analyse choisit de visualiser.

Modèle 4 : définition programmatique d'entonnoirs pour les variantes de tests A/B

Vous menez des expériences. Chaque variante peut nécessiter son propre entonnoir — « les utilisateurs sur hero_v2 ont-ils progressé de /pricing vers /signup à un taux plus élevé que hero_v1 ? ». Créer manuellement ces entonnoirs dans le tableau de bord avant chaque test est une source de friction. L'API vous permet de scripter cela.

// Node.js — creates one funnel per variant when a test starts
const variants = ['control', 'urgency', 'social_proof'];

for (const v of variants) {
  await fetch('https://app.logly.uk/api/sites/my-site/funnels', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.LOGLY_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      name: `Hero test — ${v}`,
      steps: [`/?variant=${v}`, '/pricing', '/signup', '/dashboard'],
    }),
  });
}

Combiné avec le marquage de la variante dans l'URL ou en tant qu'événement personnalisé, vous obtenez des données d'entonnoir par variante sans configuration manuelle. Lorsque le test se termine, un second script peut récupérer les résultats des trois entonnoirs, publier un gagnant sur Slack et nettoyer les définitions d'entonnoirs.

Modèle 5 : alertes opérationnelles sur les anomalies de trafic

Vous voulez savoir si le trafic chute de 50 % du jour au lendemain — car cela signifie probablement que votre site est en panne, que votre DNS est cassé, ou que votre tracker a cessé de fonctionner. Un simple script de sondage qui vérifie l'activité récente permet de détecter cela automatiquement.

# Python — runs every 15 min via cron
import requests, os, sys

key = os.environ['LOGLY_KEY']
r = requests.get(
    'https://app.logly.uk/api/sites/my-site/active',
    headers={'Authorization': f'Bearer {key}'},
)
active = r.json()['active']

if active == 0:
    requests.post(os.environ['PAGERDUTY_WEBHOOK'], json={
        'incident_key': 'logly-zero-traffic',
        'description': 'Logly reports zero active visitors — possible site outage',
    })
    sys.exit(1)

Associez-le à un seuil de référence (visiteurs actifs médians pour cette heure de la semaine) et vous disposez d'une détection d'anomalies de base sans mettre en place une vraie infrastructure de monitoring. Pour la plupart des petites équipes, c'est le bon niveau de visibilité opérationnelle — pas sur-conçu, mais qui attrape les pires modes de défaillance.

Ce qui fait une bonne API d'analyse

Les affirmations « nous avons une API » ne se valent pas toutes. À vérifier avant de vous engager dans une stack :

1. Un mécanisme d'authentification unique et canonique. Une clé bearer de longue durée est préférable à OAuth ou aux tokens rotatifs pour les échanges serveur à serveur. Vous devez pouvoir écrire un appel curl en une minute.
2. Les mêmes endpoints que le tableau de bord. Si l'API publique est un sous-ensemble distinct des données que voit le tableau de bord, vous avez deux produits à synchroniser. Un seul backend partagé signifie que tout ce que vous voyez dans l'UI peut être extrait via l'API.
3. Des formats standards en sortie. JSON pour les requêtes, CSV pour les données en masse, horodatages ISO, codes pays standard. Pas de sérialisation propriétaire, pas de XML, pas de SDK obligatoire.
4. Des clés révocables avec un signal d'utilisation. Vous devez pouvoir révoquer une clé compromise instantanément, et idéalement voir quand une clé a été utilisée pour la dernière fois afin de nettoyer les intégrations oubliées.

Commencez petit

Le piège avec les intégrations est d'imaginer l'architecture complète avant de livrer la première. Ne le faites pas. Le chemin qui fonctionne pour presque toutes les équipes :

1. Semaine 1 : livrez le Modèle 1 — un digest Slack du lundi. Vingt lignes de bash.
2. Mois 2 : ajoutez le Modèle 2 si vous avez besoin de jointures entre systèmes. Une Google Sheet avec trois pulls planifiés.
3. Trimestre 2 : migrez vers le Modèle 3 si la feuille commence à craquer. Entrepôt + outil BI.
4. Selon les besoins : ajoutez les Modèles 4 et 5 quand des cas d'usage spécifiques le justifient.

Chaque étape s'appuie sur le modèle de la précédente. Le script bash devient un script Python devient une tâche planifiée dans votre plateforme de données. Même endpoint, même authentification, sophistication croissante.