### **6. Dashboard**

#### **6.1. Périmètre V1**

Le dashboard est la tour de contrôle, pas l'atelier. L'édition des parcours a lieu dans l'extension, sur le site réel, là où les éléments à cibler existent.

**Écrans livrés :**

| Écran | Contenu |
| --- | --- |
| Connexion | Authentification par fournisseur d'identité (section 8.3) |
| Projets | Liste, clé publique, gestion des origines autorisées, extrait d'intégration à copier |
| Parcours d'un projet | Nom, statut, version publiée, date de dernière publication, alerte de sélecteur rompu |
| Détail d'un parcours | Étapes en lecture seule, historique des versions, activation, suspension, archivage |
| Analytics d'un parcours | Tunnel de complétion, répartition des choix, étapes en échec de ciblage |

**Volontairement absents, et pourquoi :**

- **Un éditeur de parcours.** Ce serait un second éditeur à écrire, à tester et à maintenir en cohérence avec celui de l'extension, alors qu'il serait structurellement inférieur : hors du site du client, il ne peut ni pointer un élément ni vérifier qu'un sélecteur résout. Deux éditeurs, c'est deux fois le travail pour une expérience dégradée.
- **La gestion fine des droits.** En V1, tout membre d'une organisation dispose des mêmes droits sur ses projets. Les organisations visées comptent quelques administrateurs qui se connaissent ; une matrice de rôles serait une machinerie sans utilisateur.
- **La facturation et les quotas.** Aucun modèle tarifaire n'est arrêté à ce stade.
- **Le statut de relecture** issu du cahier fonctionnel : il n'existe que pour les parcours engendrés par le module IA, hors périmètre V1 (section 0.1). Les statuts se limitent donc à brouillon, publié, suspendu et archivé.

#### **6.2. Architecture front**

Application monopage en Vite, React et Tailwind, compilée en fichiers statiques servis par le backend Hono (ADR-07). Il n'y a donc qu'un seul processus applicatif à déployer et à superviser.

L'accès à l'API passe par le client RPC typé du monorepo : le dashboard ne redéclare aucun type de requête ni de réponse, et une rupture de contrat côté serveur devient une erreur de compilation côté client plutôt qu'une anomalie découverte en production.

La session est portée par un cookie propre au domaine, avec les attributs `HttpOnly`, `Secure` et `SameSite=Lax` (section 8.3). Aucun jeton n'est stocké dans le stockage local du navigateur.

#### **6.3. Restitution des analytics**

**Tunnel de complétion.** Pour une version donnée, le nombre de sessions ayant atteint chaque étape, dans l'ordre du parcours. La lecture recherchée est immédiate : l'endroit où la courbe s'effondre est l'étape à retravailler.

Les indicateurs sont toujours présentés **par version**, jamais agrégés entre versions. Comparer le taux de complétion d'un parcours avant et après sa refonte n'a de sens que si les deux mesures restent distinguables ; c'est la raison d'être de l'identité stable des étapes de la section 2.3.

**Répartition des choix.** Pour chaque étape de type question, la distribution des réponses. C'est accessoirement un outil de connaissance des utilisateurs du client, souvent la donnée la plus appréciée de ce type de produit.

**Sélecteurs rompus.** Le décompte des événements `target_lost` par étape, mis en avant sur la liste des parcours. C'est la fonction qui referme la boucle du différenciateur produit : le SDK détecte qu'un repère a cédé, le dashboard le signale, l'administrateur rouvre l'extension et recapture l'élément. Sans cette remontée, la résilience du ciblage ne serait qu'une promesse invérifiable.

**Export.** Les données affichées sont exportables en CSV. Format unique, sans mise en forme ni tableur : les clients qui veulent croiser ces chiffres avec les leurs disposent déjà d'outils pour le faire.

#### **6.4. Modération et journal**

Les transitions de statut sont explicites et journalisées : qui a publié quoi, quand, et vers quelle version. Ce journal sert autant au diagnostic (« depuis quand ce parcours ne convertit-il plus ? ») qu'à la responsabilité au sein de l'organisation cliente.

**Le délai de propagation est affiché à la publication.** La confirmation indique explicitement que le changement atteindra les visiteurs sous une minute, et jusqu'à dix minutes pour un visiteur isolé dont le cache est périmé (section 7.2). Cette mention n'est pas une précaution juridique : sans elle, un administrateur qui recharge son site trois secondes après avoir publié conclut que le produit ne fonctionne pas, et ouvre un ticket. Annoncer le délai coûte une phrase et supprime cette classe entière de faux incidents.

Un parcours suspendu disparaît immédiatement du manifeste des prochaines lectures, mais ses versions restent lisibles à leurs URL, puisqu'elles sont immuables et mises en cache pour longtemps (ADR-03). Une session déjà en cours chez un utilisateur se termine donc normalement, ce qui est le comportement souhaitable : interrompre un guidage en cours de route serait plus déroutant que de le laisser s'achever.