Intégration API Metabase
Nous développons votre connecteur Metabase
Nous embarquons Metabase dans votre produit : le client lit ses commandes dans le portail, l'analyste garde le même login, les chiffres restent filtrés par la session.
- Équipe produit senior
- embedding Metabase en production
- du cadrage au monitoring
À quoi sert l'API Metabase et pourquoi l'intégrer dans votre plateforme ?
Metabase est un outil de business intelligence qui laisse les équipes créer des dashboards sans SQL. Son embedding et son API permettent d'afficher ces rapports dans votre application, filtrés par client ou par périmètre. On l'intègre pour que tout cela vive dans votre produit : portail client avec « mes commandes » sans ouvrir Metabase, back-office interne en SSO sans second login, assistant question-réponse sur les ventes du compte, export mensuel déclenché depuis le produit. Les chiffres restent dans le même SI ; Metabase n'est plus un outil à part ni un CSV du lundi.
Ce que Metabase change dans votre plateforme
Dashboard client dans le portail
Mes commandes, mon encours : le client lit ses chiffres dans votre produit. Le filtre vient de sa session, pas d'un outil à part.
BI interne sans second login
L'analyste garde les mêmes groupes que votre annuaire, dans le back-office que vous contrôlez. Un seul login.
Assistant Q&R sur les ventes du compte
L'assistant répond avec les droits de l'utilisateur connecté. Pas de SQL libre, pas de clé admin dans le chatbot.
Export mensuel lancé depuis le produit
La card part en PDF via un compte de service. Le reporting reste dans le parcours métier, pas dans une boîte mail.
Ce que ça change dans votre produit
La technique au service d'un résultat mesurable : chiffres dans le portail, même SI, chaque compte voit ses lignes.
Le client ne bascule plus vers un outil BI
Le dashboard vit à côté du dossier. Plus de CSV du lundi ni de second login Metabase.
L'analyste reste dans votre back-office
Connexion unique, mêmes groupes. La BI s'ouvre dans le parcours que vous contrôlez.
Chaque compte ne voit que ses lignes
Le filtre client vient de la session, pas d'un paramètre manipulable dans l'URL. La confidentialité tient.
La BI peut rester chez vous
Hébergement maîtrisé, signatures côté serveur. Vous gardez la main sur les chiffres, sans exposer Metabase sur Internet.
Comment nous livrons votre connecteur Metabase
Cadrage
Où Metabase entre dans votre produit : portail client, back-office, assistant, export. Static ou modular/SSO, cloud ou self-host. Un mode par cas.
JWT
Contrat d'embed aligné sur vos sessions : locked params = IDs de session, secret côté serveur, mapping groupes SSO.
Développement
Connecteur branché sur le portail et le back-office. Signature serveur, refresh Agent API (iat < 180 s), jamais le secret en front.
Monitoring
Rotation du secret d'embedding jouée en staging. Self-host : réseau privé, SSO, sauvegardes. Metabase n'est pas nu sur Internet.
Ce que l'API apporte à votre plateforme
- Embarquer le dashboard dans le portail
- Static embedding JWT, locked params issus de la session. Le client voit ses lignes, pas Metabase.
- Ouvrir la BI dans le back-office
- Modular / SSO : vraies permissions, mêmes groupes que l'IdP. Pas de second login.
- Brancher l'assistant sur le compte
- Agent API avec les droits de l'utilisateur. JWT iat < 180 s, refresh, pas de clé admin.
- Automatiser l'export depuis le produit
- REST /api/* via compte de service : cards, dashboards, PDF. Le reporting part du parcours métier.
Le vocabulaire de l'API Metabase
- Locked parameters
- Valeurs figées dans le JWT static, typiquement un id_client. Issus de la session applicative, jamais d'un query string. Sans eux, le static n'isole pas les lignes.
- Secret d'embedding
- Un secret pour tous les embeds statiques. Le vol ouvre tous les dashboards. Rotation = tous les backends. Jamais en front.
- iat < 180 s
- Sur l'Agent API, le JWT doit avoir un iat de moins de 180 secondes. Un jeton de session d'une heure est rejeté. Endpoint de refresh obligatoire.
- Static vs SSO
- Static : locked params, pas de row-level security, pas de drill-through. SSO / modular : vraies permissions, groupes IdP. Deux produits, deux devis.
- X-Metabase-Session
- Cookie de session après POST /api/session. Compte de service, pas l'analyste. La clé d'API, elle, porte les permissions du groupe de la clé, partagées par tous les appelants.
- Self-host
- Versions, migrations, Postgres interne Metabase. Ce n'est pas une API cloud. Réseau privé, SSO, sauvegardes. Metabase n'est pas exposé nu sur Internet.
Les contraintes réelles de l'API Metabase
Static n'est pas du row-level security
Locked params vs permissions SSO. Promettre « chaque client ne voit que ses lignes » en static sans locked param est une faille. Le drill-through en static est impossible.
Un secret d'embedding pour tout
Le vol ouvre tous les dashboards embarqués. La rotation touche tous les backends qui signent du static. Nous la jouons en staging avant la prod, pas sur un portail live.
JWT Agent API : 180 secondes
Un JWT de session d'une heure est rejeté. Sans endpoint de refresh, l'assistant tombe en cours de conversation. Ce n'est pas optionnel.
apiKey en modular prod = non
La doc l'interdit. Une démo avec apiKey ne se shippe pas. Self-host : c'est de l'exploitation (versions, Postgres, réseau), pas seulement une API.
Embedding static ou SSO / modular ?
Deux façons d'embarquer Metabase dans votre plateforme. Le bon dépend de qui regarde et de ce qu'il a le droit de voir.
| Critère | StaticGuest JWT | SSO / modularVraies permissions |
|---|---|---|
| Isolation des lignes | Locked params seulement | Row-level, groupes IdP |
| Drill-through | Impossible | Selon l'embed full / SDK |
| Secret | Un secret pour tous les static | JWT SSO, pas ce secret |
| Clé d'API | Hors sujet | Interdite en modular prod |
| Session utilisateur | Non, guest | Oui |
| Mise en service | Plus courte | IdP, groupes, SDK |
| Le bon cas | KPI public filtrable | Portail authentifié |
Nous choisissons un mode par cas et le documentons. Mélanger static et SSO dans le même écran, c'est le plus sûr moyen d'une faille de filtre. Le secret ne quitte jamais le serveur.
Ce que nous mesurons sur une intégration Metabase
Les autres outils de productivité
Si Metabase n'est pas le reporting embarqué de votre produit, ces options se discutent au cadrage.
MetabaseNous développons votre connecteur MetabaseCette page
SlackL'alerte, quand le dashboard ne suffit pas à réveiller l'astreinte.
JiraLe ticket, quand un chiffre hors seuil doit devenir un dossier.
NotionLe commentaire et le wiki, autour du chiffre, pas à la place.
AirtableNous développons votre connecteur AirtableOn combine Metabase avec
La stack autour de Metabase quand on l'embarque dans un portail ou un back-office.
Metabase : vos questions
On la branche sur vos touchpoints produit : dashboard dans le portail client, BI dans le back-office, assistant sur le compte, export depuis le parcours. Techniquement : un mode d'embed par cas (static avec locked params, ou modular/SSO), JWT signés serveur depuis la session, Agent API avec iat < 180 s et refresh. Self-host : réseau privé, SSO, sauvegardes. La partie sensible n'est pas l'iframe, c'est le parcours produit, le secret d'embedding et les locked params.
Static : paramètres locked dans le JWT (id_client de la session), secret d'embedding uniquement serveur. Sans locked param, le static n'isole pas les lignes. SSO / modular : vraies permissions, groupes IdP, jamais d'apiKey en production. Ne pas promettre de drill-through en static (doc officielle). Un secret d'embedding volé ouvre tous les dashboards static : rotation jouée en staging. C'est le test d'un intégrateur BI, pas un réglage cosmétique.
La doc impose un iat de moins de 180 secondes. Un JWT « de session » d'une heure est rejeté. Sans endpoint de refresh, l'assistant tombe en cours de conversation. Ce n'est pas le même jeton que l'embedding static. Nous posons le refresh dès le prototype, et nous ne mettons jamais une clé d'API « admin » dans un chatbot utilisateur : les permissions sont celles du groupe de la clé, partagées par tous les appelants.
Oui, et c'est souvent l'argument. La BI reste dans le VPC, le logiciel métier signe des JWT. Ce n'est pas « une API cloud » : versions, migrations, Postgres interne, SSO, sauvegardes, Metabase non exposé nu sur Internet. Looker ou Power BI embarqué n'offrent pas le même rapport souveraineté / prix. Le devis d'intégration inclut l'exploitation si le self-host est dans le périmètre, sinon le cloud Metabase, sans inventer de quota horaire non publié.
Un premier flux utile, typiquement un dashboard static filtrable par client_id dans votre portail, se livre en deux à trois semaines. Une chaîne complète avec SSO / modular, Agent API et self-host demande plutôt six à huit semaines. La durée dépend surtout des touchpoints à brancher, du mode d'embed et de l'IdP. Nous cadrons le périmètre en amont et donnons une estimation ferme avant de commencer.
Un projet d'intégration Metabase ?
Parlons-en. 30 minutes pour cadrer où Metabase entre dans votre plateforme (portail, back-office, assistant) et ce que locked params tiennent.
Parler de mon projet Metabase