# Runtime dev, viewer et publication

## Runtime dev vs runtime viewer

### Fonctionnel
Le produit doit séparer développement et consultation publiée. Un dashboard publié s’ouvre normalement dans le viewer. Pour modifier, action explicite : “Entrer en édition”.

### Technique
Même application, mais deux runtimes séparés :

```txt
/workspace/*   # développement
/viewer/*      # consultation publiée
```

Le viewer ne doit pas charger : moteur workspace complet, outils dev, gestion multi-fenêtres, panneaux d’édition, layout editor.

## Séparation des ressources dev / consommation

### Fonctionnel
Une requête qui plante en développement ne doit jamais impacter les dashboards publiés.

### Technique
Prévoir séparation : workers dev/viewer, queues dev/viewer, caches dev/viewer, quotas dev/viewer, pools de connexions séparés et monitoring séparé.

## Publication des dashboards

### Fonctionnel
Un dashboard peut passer en mode publié via une action “Publier”. Le publié est destiné à la consultation par utilisateurs finaux.

### Technique

```txt
status: draft | published
draftVersionId
publishedVersionId
```

Publication :
- fige une version publiée ;
- bascule vers ressources viewer ;
- conserve draft modifiable séparément.

## Draft preview

### Fonctionnel
Possibilité d’exceptions pour des consommateurs testeurs.

### Technique

```txt
DraftPreviewAccess
  objectId
  objectType
  userId | groupId
  permission: view_draft
  expiresAt
```