---
title: "Remarques"
weight: 60
description: "Signaler un bug ou une idée hors-liste pendant la recette."
---

# Remarques

Pendant la recette, un testeur remarque souvent un comportement qui ne figure pas
dans la liste des points : un bug imprévu, ou une idée d'amélioration. La remarque
permet de le consigner sans alourdir la todolist.

## Signaler une remarque

Depuis le tableau de bord ou la todolist d'un projet, cliquez sur **Remarques**.
En haut de la page, le formulaire **Nouvelle remarque** comporte :

- **Type** : Bug ou Idée.
- **Titre** : un intitulé court et explicite (obligatoire).
- **Version (optionnel)** : la version concernée, si la remarque se rapporte à une
  version précise.
- **Détail** : une description libre, au format Markdown.

![Formulaire de remarque avec le type, le titre, la version et le détail](screenshots/remarque-formulaire.webp)

Cliquez sur **Enregistrer la remarque**. Elle apparaît aussitôt dans la liste.

## Consulter les remarques

Sous le formulaire, la liste présente toutes les remarques du projet, de la plus
récente à la plus ancienne. Chaque ligne indique le type, le titre (avec un extrait
du détail), la version concernée, l'auteur, le statut et la date.

Une remarque passe par les statuts suivants au fil de son traitement :

| Statut | Signification                                                  |
|--------|----------------------------------------------------------------|
| Ouvert | Remarque enregistrée, en attente de tri.                       |
| Trié   | Remarque examinée par un responsable.                          |
| Promu  | Remarque transformée en point de test.                         |
| Fermé  | Remarque close (traitée, refusée ou en doublon).               |

## Changer le statut d'une remarque

Un développeur ou un administrateur du projet peut faire évoluer le statut
directement dans la liste : le sélecteur de la colonne **Statut** permet de passer
une remarque de Ouvert à Trié, ou de la marquer Fermé une fois le bug corrigé. Le
rapporteur voit ce statut changer, ce qui lui indique que son bug est traité. Les
autres membres voient le statut en lecture seule.

## Escalader vers un autre projet

Il arrive qu'un bug remonté dans un projet relève en réalité d'un autre (par
exemple un utilisateur de SmartIntervention signale un bug qui vient de SmartAuth).
Vous pouvez alors **escalader** la remarque vers le projet responsable, sans la
faire disparaitre de son projet d'origine.

Sur une remarque du projet courant, choisissez le projet responsable et cliquez sur
**Escalader** (action réservée aux développeurs/administrateurs du projet
d'origine). La remarque :

- **reste visible** dans son projet d'origine, avec la mention "Vers <projet>" ;
- **apparait aussi** dans la liste des remarques du projet responsable, avec la
  mention "Depuis <projet d'origine>" ;
- garde **un seul statut partagé** : quand l'équipe du projet responsable la marque
  Fermé (corrigé), le rapporteur du projet d'origine le voit immédiatement et peut
  vérifier la correction.

![Liste des remarques avec une remarque escaladée vers un autre projet](screenshots/remarque-escalade.webp)

Le bouton **retirer l'escalade** annule le rattachement si besoin. Un
développeur/administrateur de l'un ou l'autre des deux projets peut faire évoluer le
statut de la remarque escaladée.

## De la remarque au point de test

Une remarque pertinente peut être **promue** en point de test : elle devient alors
un cas à part entière, avec sa propre référence, et entre dans le cycle de recette.
La promotion est une action réservée aux développeurs, réalisée via l'agent IA ou
l'API (voir [Automatisation](/captests/automatisation)) ; elle ne se fait pas
depuis la console web.

> **Note :** les remarques restent volontairement légères. capTests n'est pas un
> suiveur de bugs complet : pour un suivi détaillé, rattachez la remarque ou le
> point promu à un ticket externe via les liens typés.