# Construire avec votre agent (MCP)

C'est le flux de travail central : **le tableau de bord est construit dans votre propre harness — Claude Code, Codex, Cursor, tout client MCP — et tout ce dont il dépend est maintenu dans Vibedasher.** Vous ne construisez pas dans notre application. Votre agent travaille en local, et le serveur **`vibedasher-mcp`** lui donne des outils vers la plateforme maintenue — jeux de données, moteur de requêtes, brouillons et builds de tableaux de bord, publication, partage, droits d'accès — de sorte que la moitié à état (connexions, jeux de données, pipelines, actualisations, gouvernance, hébergement) reste là où elle est maintenue et gouvernée, tandis que le code du tableau de bord reste entre les mains de votre agent.

À savoir avant d'en écrire une seule ligne

**Ce qui est hébergé est un bundle rendu côté client.** Votre tableau de bord est du React qui tourne dans le navigateur du visiteur sur des données servies par SQL. Aucune ligne de votre code serveur ne s'exécute ici — pas de routes d'API, pas de rendu côté serveur, pas de loaders, pas de workers d'arrière-plan — de sorte qu'un framework à rendu serveur ne peut pas être hébergé tel quel : Next.js sur l'un ou l'autre routeur, Remix, SvelteKit, Astro, Nuxt. Il n'y a pas non plus de `npm install` au moment du build ; les bibliothèques viennent d'une liste épinglée, et React est le seul framework qui y figure.

Cette pile n'est pas refusée, elle est **orientée**. Deux portes, toutes deux ouvertes : gardez votre propre serveur et tirez-y les données de ce compte avec le SDK que l'installation vous a déjà donné, ou construisez le tableau de bord ici et [éjectez-le](/fr/guides/eject-your-dashboard.md) pour l'héberger vous-même. Dans les deux cas, les connexions, les jeux de données, les actualisations, la gouvernance et le moteur de requêtes restent maintenus de notre côté.

Vous avez déjà un arbre ? `check_viz_tree(src_dir=<absolute path>)` y répond statiquement, contre vos vrais fichiers, avant de dépenser un build.

## Installer et se connecter[​](#installer-et-se-connecter "Lien direct vers Installer et se connecter")

```
pip install 'vibedasher-mcp>=0.6.0'

vibedasher login
```

`vibedasher login` ouvre votre navigateur, vous approuvez la session, et c'est terminé. Le refresh token est écrit dans le trousseau de votre système d'exploitation — ou, sur une machine sans trousseau, dans un fichier `0600` sous `~/.vibedasher/`. Aucune clé à générer, copier dans un fichier de configuration, ou faire tourner. La sous-commande `login` requiert la version **0.6.0 ou ultérieure** ; les versions antérieures ne l'ont pas.

Deux sous-commandes supplémentaires, et c'est tout :

```
vibedasher whoami    # le compte connecté, l'utilisateur et la région, et quand le re-consentement est dû

vibedasher logout    # révoque la session de cette machine et l'oublie
```

Par défaut, `login` vous connecte sur `eu-central-1` ; passez `--region` pour une autre région, et `--timeout` pour changer combien de temps il attend le callback (180 s).

Si votre terminal n'a pas de navigateur qu'il peut lancer — WSL, une session de bureau sans X, un terminal sans gestionnaire par défaut — utilisez `vibedasher login --no-browser`. Il affiche l'URL au lieu de l'ouvrir, et attend le même callback. Notez que l'écouteur de callback se lie sur `127.0.0.1` sur un port choisi par l'OS au moment de la connexion, donc le navigateur dans lequel vous collez l'URL doit être sur la **même machine**. Se connecter depuis un ordinateur portable pour une machine *distante* n'est pas une voie que `login` prend en charge — pour une machine à laquelle vous n'accédez que par SSH, utilisez une clé API (voir ci-dessous).

Puis enregistrez le serveur. Avec Claude Code :

```
claude mcp add vibedasher --env VIBEDASHER_REGION=eu-central-1 -- vibedasher-mcp
```

Ou dans n'importe quelle configuration de client MCP :

```
{

  "mcpServers": {

    "vibedasher": {

      "command": "vibedasher-mcp",

      "env": { "VIBEDASHER_REGION": "eu-central-1" }

    }

  }

}
```

Notez que `vibedasher-mcp` est le point d'entrée du **serveur** que votre client MCP lance ; `vibedasher` est la CLI que vous exécutez vous-même. Le serveur reprend la session que `vibedasher login` a stockée — il n'y a aucun identifiant dans le bloc de configuration.

Le serveur ne parle qu'à l'API publique et mesurée — la même surface que les [SDKs](/fr/api/sdks.md). Rien en marge, et aucun identifiant n'est jamais renvoyé dans les résultats d'outils.

### Headless et CI — utiliser une clé API[​](#headless-and-ci--use-an-api-key "Lien direct vers Headless et CI — utiliser une clé API")

Un runner de build, une machine cron, un conteneur : aucun endroit où un navigateur peut s'ouvrir, et personne pour cliquer sur approuver. Là, authentifiez-vous avec une **clé API** à la place. Générez-en une depuis l'application sur [cloud.vibedasher.com](https://cloud.vibedasher.com) (Paramètres → Clés API) — la création de clé se fait uniquement en session, c'est donc une action de navigateur, pas un appel d'API ; voir [Authentification](/fr/api/authentication.md) — et placez-la dans le bloc `env` du serveur :

```
{

  "mcpServers": {

    "vibedasher": {

      "command": "vibedasher-mcp",

      "env": {

        "VIBEDASHER_API_KEY": "<your-api-key>",

        "VIBEDASHER_REGION": "eu-central-1"

      }

    }

  }

}
```

`VIBEDASHER_API_KEY` prend le pas quand elle est définie : le serveur utilise la clé et ignore toute session de connexion stockée. Traitez la clé comme un mot de passe — une variable d'environnement ou un coffre-fort de secrets, jamais le contrôle de version. Sur votre propre machine, préférez `vibedasher login` ; il n'y a alors aucun secret durable sur disque susceptible de fuiter ou de nécessiter une rotation.

## La boucle que votre agent exécute[​](#la-boucle-que-votre-agent-exécute "Lien direct vers La boucle que votre agent exécute")

Tout ce qui suit est votre agent construisant le *tableau de bord* — l'état de la plateforme contre lequel il construit (connexions, jeux de données, actualisations, gouvernance) est configuré une fois et maintenu dans Vibedasher, si bien que chaque itération de la boucle le trouve déjà en place.

1. **Faire entrer des données** — `upload_dataset_from_file(name, csv_path)` pour un fichier sur disque (`upload_dataset` prend le CSV en ligne à la place, ce qui coûte des tokens pour chaque ligne), ou `create_dataset_from_connection` contre une [source de données connectée](/fr/guides/connect-a-data-source.md). Chaque jeu de données obtient un alias `cleanSQLName` — cet alias est le nom de table en SQL, jamais un nom de table physique.
2. **Explorer** — `run_query(sql, dataset_ids)` : un SELECT en lecture seule à travers les jeux de données, avec des colonnes typées et des lignes en retour.
3. **Créer et construire** — `create_viz(name, dataset_ids)`, puis `push_viz_files(viz_id, files)` avec un `App.tsx` à la racine, puis `build_viz` → `get_build_status(build_id)` jusqu'à ce que le bundle compile. Vous avez déjà un arbre React ? `check_viz_tree(src_dir=...)` nomme d'abord chaque modification nécessaire, de façon statique, sans dépenser un build.
4. **Publier** — `publish_viz(viz_id)` promeut le brouillon vers la version que voient les visionneurs, et `share_viz(viz_id)` renvoie le lien à diffuser. `build_viz` à lui seul ne publie **pas**.
5. **Vérifier** — `render_probe(viz_id)` ouvre le tableau de bord publié dans un vrai navigateur et rapporte ce qui s'est réellement peint : combien de tuiles ont été rendues, les chiffres clés relus mot pour mot, et toute erreur de console. Un build vert signifie que le code a compilé — pas que le graphique montre ce que son titre prétend, et un graphique qui n'a jamais reçu de données laisse un canevas d'une seule couleur en pleine taille que toute vérification fondée sur des comptages accepte.
6. **Itérer** — `eject_viz` pour récupérer la source React complète, l'éditer en local, `push_viz_files` pour valider les changements sur la branche de brouillon, reconstruire, republier.

Votre agent dispose aussi d'outils pour les dossiers, groupes, utilisateurs et droits d'accès (`grant_access` / `revoke_access`), la gouvernance est donc elle aussi scriptable — voir [Publier et partager](/fr/guides/publish-and-share.md).

## Éjecter — le code reste le vôtre[​](#eject--the-code-stays-yours "Lien direct vers Éjecter — le code reste le vôtre")

Publier sur Vibedasher est la fin normale de la boucle — c'est ce qui garde le tableau de bord hébergé, gouverné et relié à des données maintenues. Mais le code lui-même est du React et du SQL ordinaires et il reste le vôtre : `eject_viz` remet à votre agent l'arbre source exécutable complet (composants, `package.json`, configuration Tailwind) plus un manifeste de câblage, et `eject_instructions` explique comment le reconstruire nativement dans votre propre application — les requêtes passant par le SDK contre vos jeux de données Vibedasher, l'hébergement se faisant entièrement de votre côté. Les arbres volumineux sont livrés sur disque (`out_dir=...`) ou paginés ; suivez `delivery.pendingPaths` jusqu'à ce qu'il soit vide avant de considérer l'arbre comme complet.

Un choix à l'intérieur de tout cela mérite d'être fait délibérément, car c'est la moitié que vous ne pourrez plus changer ensuite. Un tableau de bord éjecté depuis une visualisation **publique et publiée** embarque une voie sans identifiants : il télécharge un extrait Parquet et exécute chaque requête dans le navigateur du visiteur, sans clé, sans jeton et sans backend de votre côté. Cela signifie aussi que chaque visiteur obtient toutes les lignes du jeu de données, et qu'aucun visionneur ne peut se voir montrer moins de lignes qu'un autre — voir [Qui peut voir quoi](/fr/guides/who-can-see-what.md#row-level-filtering-the-embed-lane-and-only-the-embed-lane) pour les deux montages qui *peuvent* restreindre un visionneur, et tranchez entre eux avant de construire.

L'histoire complète — les trois appels d'éjection, le contrat de pagination, et les deux générations de props encore vivantes — se trouve dans **[Éjecter votre tableau de bord](/fr/guides/eject-your-dashboard.md)**.

## Ensuite[​](#ensuite "Lien direct vers Ensuite")

* **[La voie de requête wasm](/fr/guides/the-wasm-query-lane.md)** — la voie de données sans identifiants en détail, et ce qu'elle sacrifie.
* **[Éjecter votre tableau de bord](/fr/guides/eject-your-dashboard.md)** — sortir le code, et rebrancher les données.

L'application sur [cloud.vibedasher.com](https://cloud.vibedasher.com) travaille sur les mêmes tableaux de bord et brouillons que votre agent, si bien qu'une personne peut relire dans l'interface et publier depuis là — mais la boucle du harness ci-dessus est le chemin pour lequel nous construisons et que nous documentons.