> ## Documentation Index > Fetch the complete documentation index at: https://docs.atconseil.info/llms.txt > Use this file to discover all available pages before exploring further. # Hub des sessions > Retrouvez toutes les sessions exploratoires d'un projet au même endroit : filtrez par périmètre, lisez l'issue de chaque session, exportez une session ou tout le périmètre en PDF. Une session archivée sur une user story se retrouve facilement — à condition de se souvenir de quelle story. L'onglet **Explore** du hub TestPulse répond à l'autre question : *qu'a-t-on réellement exploré sur ce projet ?* ## Toutes les sessions du projet, groupées par work item L'onglet liste **toutes les sessions exploratoires du projet**, groupées par le work item sur lequel elles ont été menées, activité la plus récente en tête. Chaque groupe affiche son work item, son **type**, le nombre de sessions qu'il porte et la date de sa dernière activité — puis se déplie en **une ligne par session**. C'est cette ligne qui compte : **statut**, charte, testeur, durée, nombre de notes, de captures, de fichiers et de bugs, et un lien — vers la Task archivée une fois la session close, ou vers la fiche elle-même tant qu'elle est en cours, où l'onglet Explore la reprend. Pour une session active, ce lien vous dit si elle est **la vôtre** : la vôtre affiche votre nom et propose de la reprendre, celle d'un collègue ouvre seulement la fiche. Azure DevOps ne restaure une session qu'au compte qui l'a démarrée : promettre davantage serait promettre ce qui ne peut pas arriver. Une story explorée trois fois affiche trois lignes distinctes, et non un empilement de pastilles fusionnées. ## Le verdict, quand il y en a un Depuis la v2.60.0, une session close peut porter un **verdict** — Réussi, Échoué ou Bloqué — choisi par le testeur à la clôture. Il s'affiche comme son propre badge **à côté** du badge de statut, jamais à sa place : le statut dit où en est la session dans sa vie, le verdict dit comment elle s'est passée. Le filtre **Verdict** restreint la liste à une valeur, ou aux sessions qui n'en portent **aucun** — une réponse distincte de « tous », le verdict étant facultatif et le passer parfaitement légitime. Un verdict n'est **compté nulle part**. Une session marquée Échoué n'incrémente aucun indicateur d'échec, dans aucun rapport et dans aucun quality gate — c'est le jugement d'un testeur sur une session, pas un résultat de test. La même valeur est écrite en tag sur la tâche de suivi pour être requêtable depuis Azure DevOps ; si quelqu'un modifie ce tag à la main, c'est le document de session que TestPulse lit. ## Lire le statut d'un coup d'œil Chaque session porte un **statut avec sa couleur et sa propre icône** — complète, active, interrompue, abandonnée ou incomplète. La couleur n'est jamais le seul signal : la liste reste lisible en thème sombre et pour les lecteurs daltoniens. **Incomplète** mérite une précision : ce statut marque une session dont la clôture n'est pas allée à son terme. Rien n'est perdu — la Task archivée porte la vérité — et la ligne renvoie directement vers elle. ## Restreindre le périmètre Les filtres couvrent **area path, iteration path, tag de campagne, testeur, période et verdict**, plus un interrupteur pour inclure les sessions archivées. Les filtres d'area et d'iteration **retiennent les sous-chemins** : choisir une racine ramène tout ce qui se trouve dessous, comme Azure DevOps traite lui-même ces chemins. Chaque option de filtre porte **son propre compteur de résultats**, ce qui permet de juger sa sélectivité avant de la choisir. Le filtre **Testeur** se positionne sur vous à l'ouverture du hub, avec une puce visible **« Filtré sur mes sessions »** retirable en un clic. **Les sessions actives y échappent** : une session ne reçoit sa tâche de suivi — et donc un nom de testeur résolvable — qu'à la clôture, si bien qu'un filtre par testeur masquerait sinon toutes les sessions en cours, y compris les vôtres. Tous les autres filtres continuent de s'y appliquer. Ce filtre réduit le bruit ; il n'apporte aucune confidentialité. Les sessions sont stockées au **scope projet** et lisibles par toute personne ayant accès au projet, indépendamment des équipes Azure DevOps. ## Archivées, jamais supprimées Au-delà d'un seuil, les sessions anciennes quittent la vue par défaut — elles sont **archivées à l'affichage uniquement**. TestPulse **ne supprime jamais une session** : l'interrupteur les fait revenir, et le total réel reste affiché. ## Exporter une session, ou tout le périmètre Toute session portant au moins une entrée propose **Exporter la session** — le même PDF signé que depuis la fiche work item. Une session sans rien de consigné n'affiche aucun bouton, puisqu'il n'y aurait rien à rapporter. **Exporter le rapport** produit le **rapport agrégé de périmètre** : page de garde, synthèse, sessions par area et par iteration, une section par work item, et une annexe. Les deux exports ouvrent une boîte de dialogue avec un **titre pré-rempli** que vous acceptez tel quel ou réécrivez, et tous deux suivent la **charte configurée dans les Réglages** — libellé, couleur de thème et logo de page de garde. ## Ce que les indicateurs disent — et ne disent pas L'onglet affiche les **work items couverts**, un **compteur de sessions** et les **sessions interrompues**. Ce compteur correspond aux lignes réellement listées — sessions incomplètes comprises — donc vérifiable en les comptant. Un indicateur **« Découvertes »** figurait ici, additionnant les work items créés depuis une session. Il a été retiré en v2.57.2 : un testeur qui saisissait les mêmes constats directement dans Azure DevOps comptait zéro, si bien que le nombre n'a jamais mesuré ce que son nom promettait. Il n'y a délibérément **pas d'effort total** : une session laissée ouverte une nuit produit une durée arithmétiquement exacte et pratiquement dénuée de sens, et la sommer aurait rendu le chiffre indigne de confiance. La durée par session, elle, reste affichée à côté de sa charte, là où un humain peut en juger. Les work items créés par TestPulse pour archiver une session sont **signalés comme tels** et exclus de la couverture : ce sont des enregistrements, pas des sujets d'exploration. Des indicateurs à examiner, jamais un verdict : c'est vous qui décidez. ## Strictement en lecture seule L'onglet **lit et exporte**. Il n'écrit jamais dans Azure DevOps — attacher un rapport à un work item reste sur la fiche, là où vit la session. ## Voir aussi Démarrer une session depuis une user story. Ce que contient le PDF exporté. Annoter des captures et créer des work items. Ce qui reste dans votre tenant.