Tableaux de bord Tableau
La mise en page, les repères, les couleurs, le tri et les formats de nombre deviennent une app Streamlit in Snowflake, avec ses filtres comme sélecteurs en direct.
Tableau vers Snowflake
Migrez Tableau vers Snowflake en une conversation.
Le Boreon MCP Layer lit chaque classeur de votre site Tableau Server ou Tableau Cloud, transforme le flux Prep qui l’alimente en table dynamique Snowflake, reconstruit le tableau de bord en app Streamlit in Snowflake et vérifie chaque chiffre face à Tableau avant de publier. Pas de scripts ni de SQL écrit à la main.
En production en un mois
- Semaines 1 à 2MVPLe Boreon MCP Layer derrière votre pare-feu, vos tableaux de bord prioritaires migrés et chaque chiffre prouvé.
- Semaines 3 à 4Déploiement finalLe reste de vos classeurs prioritaires, le durcissement, la validation et la formation.
- Jour 30Mise en productionVotre équipe l’utilise dans le chat, et chaque migration à venir vous appartient.
Toute la chaîne
Le flux devient une table, puis l’app suit
Un classeur alimenté par un flux Prep part de Tableau Server ou Tableau Cloud en une seule tâche, dans l’ordre de construction.
Chaque étape du flux devient une CTE dans une seule instruction SQL, créée comme table dynamique Snowflake, ou comme vue matérialisée là où Snowflake le permet. La table est d’abord créée et vérifiée, et seulement ensuite l’app Streamlit in Snowflake est construite dessus. L’app lit une table déjà contrôlée.
CREATE DYNAMIC TABLE sales.pipeline_dt
TARGET_LAG = '1 hour'
WAREHOUSE = compute_wh
AS
WITH clean AS ( … ),
joined AS ( … )
SELECT … FROM joined;Ce qui migre
Les tableaux de bord deviennent des apps Streamlit
Quatre types de travail depuis Tableau Server ou Tableau Cloud, tous lancés depuis le même chat.
Flux Tableau Prep
Chaque étape du flux devient une CTE dans une seule instruction SQL, créée comme table dynamique Snowflake, ou comme vue matérialisée là où Snowflake le permet.
Toute la chaîne
Un classeur alimenté par un flux Prep migre en une seule tâche : la table est d’abord créée et vérifiée, puis l’app est construite dessus.
Les réponses se publient aussi dans Tableau
Depuis le même chat, Render & Publish envoie n’importe quelle réponse à votre site Tableau sous forme de classeur, sans ajouter de seconde source de données.
Le Boreon MCP Layer parle Tableau et Snowflake
Il lit les deux côtés par leurs propres API, tient un modèle sémantique de leur correspondance et n’écrit que lorsque vous le demandez.
| Ce qu’il lit | Comment il se connecte | |
|---|---|---|
| Tableau | Classeurs et tableaux de bord, sources de données publiées, flux Prep, le VizQL Data Service et la Metadata API, sur votre site Tableau Server ou Tableau Cloud. | Un jeton d’accès personnel, un JWT de Connected App ou un compte de service central. |
| Snowflake | Votre compte, vos bases de données, schémas et entrepôts virtuels, chaque requête passant par la SQL API. | Une paire de clés ou OAuth, ou au nom de chaque personne via Snowflake OAuth, avec ses propres rôles appliqués. |
| Boreon MCP Layer | Les champs Tableau associés aux colonnes Snowflake, par licence, avec le lignage du flux à la source de données puis au classeur. | Votre propre SSO, chaque écriture auditée. |
Preuve sur Snowflake
Prouvé sur Snowflake avant publication
Chaque migration vous remet sa preuve, mesurée sur vos propres classeurs.
- Ses propres tables. Un tableau de bord n’est reconstruit que sur les tables Snowflake où ses données se trouvent déjà.
- Tout ou rien. Si une feuille n’a pas de correspondance fidèle, rien n’est publié et l’agent explique pourquoi.
- Les chiffres d’abord. Moyennes, décomptes distincts et médianes restent exacts sous les filtres du tableau de bord, vérifiés face à la réponse de Tableau lui-même.
- Requêtes prouvées d’abord. La requête de chaque feuille s’exécute sur Snowflake avant la publication, et l’app s’ouvre sans erreur SQL.
- Écritures auditées. Les seules écritures sont celles que vous demandez : une app publiée ou une table créée, chacune auditée.
Après la migration
Le portail reste, pour Snowflake et Databricks aussi
Quand la fenêtre de migration se referme, le Boreon MCP Layer reste sur site comme portail de chat pour vos entrepôts de données : Snowflake, et Databricks aussi, où chaque tableau de bord affiché par le portail intègre Genie. Voir le portail LLM
Un MVP en deux semaines. En production en un mois.
Dites-nous quels tableaux de bord de votre site Tableau Server ou Tableau Cloud vous migreriez en premier. Nous les cadrons, installons le Boreon MCP Layer derrière votre pare-feu et mettons un MVP fonctionnel entre les mains de votre équipe en deux semaines, avec le déploiement final et la mise en production dans le mois.