Publier et partager

Publier, c'est la passation de votre harness vers la plateforme maintenue : le tableau de bord cesse d'être la sortie d'un agent et devient quelque chose sur lequel votre équipe peut compter — une URL stable, gouvernée par vos droits d'accès, qui continue de répondre une fois la session terminée.

Draft et main sont de vraies branches git

Ce n'est pas une métaphore. Chaque tableau de bord est un dépôt git, conservé comme un dépôt nu dans un stockage objet. Vos modifications — depuis votre agent, depuis l'assistant intégré à l'application, depuis l'éditeur de code — sont des commits sur une branche draft. Publier fusionne ce brouillon dans main.

Trois conséquences à prévoir :

• Vous ne pouvez pas écrire directement sur main. Les écritures y sont refusées ; la seule façon pour du contenu d'atteindre la version en direct est une publication.
• Chaque publication crée une étiquette de version. L'étiquette enregistre l'état de main avant la fusion — donc v1 est ce que votre première publication a remplacé, v2 est ce que votre deuxième publication a remplacé, et la version actuellement en direct est main, non étiquetée jusqu'à la prochaine publication.
• Les publications concurrentes fusionnent plutôt que d'écraser. Si main a bougé pendant que votre brouillon était ouvert et que les deux ont touché des fichiers différents, les deux ensembles de modifications aboutissent. S'ils ont touché le même fichier de façon incompatible, la publication échoue avec 409 PUBLISH_MERGE_CONFLICT et nomme les chemins en conflit. Elle ne choisit pas un gagnant silencieusement.

Vous pouvez lire cet historique :

print(client.viz.list_tags(viz_id))
print(client.viz.get_commit_log(viz_id, "main", max_count=20))
print(client.viz.preview_publish(viz_id))   # diff between draft and main

console.log(await client.viz.listTags(vizId));
console.log(await client.viz.getCommitLog(vizId, 'main', { maxCount: 20 }));
console.log(await client.viz.previewPublish(vizId));

Publier un tableau de bord

Votre agent peut le faire directement via MCP ; dans l'application c'est le bouton Publier ; depuis le code c'est un seul appel :

client.viz.publish(viz_id)

await client.viz.publish(vizId);

Publier lance d'abord un contrôle de santé sur le dernier build du tableau de bord. Si le bundle est FAILED ou périmé, la publication est refusée avec un 409 plutôt que de promouvoir quelque chose qui ne s'affiche pas — passez force=true pour outrepasser cela délibérément.

La publication fusionne ensuite, étiquette, et démarre un build. Le statut ne devient PUBLISHED que lorsque ce build réussit ; s'il échoue, le tableau de bord atterrit en ERROR et main est réinitialisé. Donc le retour de publish() n'est pas le même fait que « le tableau de bord est en direct » — relisez publishStatus avant de dire à quelqu'un que le lien fonctionne. (Même règle que l'actualisation renvoyant 202 : l'appel qui se termine et le travail qui se termine sont deux faits différents.)

Qui peut l'ouvrir — trois modes, pas deux

Publier décide que le tableau de bord est en direct. Un champ séparé, viewMode, décide qui peut l'ouvrir. Confondre les deux est l'erreur la plus courante ici.

viewMode	Qui peut l'ouvrir
public	N'importe qui avec le lien. Aucun compte requis.
protected	Seulement un visionneur pour lequel votre backend a généré un jeton d'intégration — avec des filtres par ligne et par visionneur. Voir Intégration.
private	Personne en dehors de votre compte. Publié, mais inaccessible depuis la surface publique.

Le lien d'un tableau de bord publié ressemble à :

https://cloud.vibedasher.com/v/<slug>

Cette URL ne sert du contenu que quand le tableau de bord est à la fois publié et public. Un tableau de bord protected sur la même URL a besoin d'un jeton ajouté.

La mise en public est contrôlée séparément, et un agent ne peut pas le faire seul

Rendre les données de l'entreprise lisibles par le monde entier est la seule chose irréversible dans tout ce flux, elle a donc son propre verrou plutôt que de suivre publish. Deux interrupteurs, tous deux sur le compte, tous deux vérifiés côté serveur sur chaque route pouvant écrire viewMode :

• allowForPublicViz — un interrupteur d'arrêt d'urgence à l'échelle du compte. Désactivez-le et rien dans le compte ne peut être rendu public, par personne, par aucune route.
• apiKeysMayPublish — vaut false par défaut. Même quand le partage public est autorisé, un appelant s'authentifiant avec une clé API ne peut pas être celui qui bascule un tableau de bord en public. Un admin doit activer ceci, et ne peut le faire que depuis une session de navigateur — PUT /v1/account refuse de le définir depuis une clé API, si bien que l'interrupteur ne peut pas s'activer lui-même.

Ce second point est l'essentiel. Ailleurs sur cette plateforme, une clé API agit comme son utilisateur créateur avec le rôle complet de cet utilisateur (voir Qui peut voir quoi). Publier sur l'internet ouvert est l'exception délibérée : votre agent peut construire le tableau de bord, le publier, et le partager à l'intérieur de votre compte, mais par défaut il ne peut pas être ce qui le rend public. Un humain dans un navigateur doit avoir dit oui une fois, au niveau du compte.

Le code est figé ; les données ne le sont pas

C'est la propriété qui fait qu'un tableau de bord publié vaut la peine d'être hébergé plutôt qu'exporté.

Le code du tableau de bord est capturé au moment de la publication. Le bundle est construit une fois et servi depuis le stockage. Votre brouillon continue d'évoluer indépendamment et ne se répercute pas sur la version en direct tant que vous ne publiez pas à nouveau.

Les données sont lues en direct au moment de la consultation. Chaque graphique d'un tableau de bord publié interroge le contenu actuel de ses jeux de données quand quelqu'un l'ouvre. Une actualisation qui atterrit à 3h du matin apparaît sur le tableau de bord publié à 9h sans rien reconstruire et sans personne dans la boucle. C'est toute la raison pour laquelle la moitié « données » vit dans la plateforme — voir Garder vos données fraîches.

Dépublier et republier

DELETE /v1/viz/{id}/publish retire le tableau de bord : le statut revient à NOT_PUBLISHED et le bundle en direct est supprimé. Votre brouillon reste intact.

• Le slug est conservé et reste réservé, donc republier réutilise la même URL.
• Les anciens liens échouent de façon incohérente. La page de visionnage répond 404, l'API publique répond 403, et les endpoints de données en cache répondent 404. Si vous gérez cela de façon programmatique, ne vous basez pas uniquement sur le code de statut.
• Renommer le slug casse définitivement chaque lien existant. Il n'y a pas de redirection d'un ancien slug vers un nouveau. Choisissez le slug avant de diffuser l'URL.

L'intégrer

Les tableaux de bord publiés s'affichent via une iframe intégrable que vous pouvez déposer dans n'importe quelle application, page de documentation ou site — public, ou verrouillé par visionneur avec des filtres au niveau des lignes. Voir Intégrer un tableau de bord.