> ## Documentation Index
> Fetch the complete documentation index at: https://docs.logbrew.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Trier et résoudre les problèmes dans LogBrew

> Gérez les problèmes dans LogBrew. Lisez les preuves d’une occurrence, trouvez le propriétaire, puis résolvez, archivez, rouvrez, priorisez ou attribuez les problèmes à une personne ou à une équipe.

Un problème regroupe les occurrences d’erreur qui partagent une empreinte.
Lisez le résumé du groupe et une occurrence avant de changer le statut, la
priorité ou le responsable. Un changement de statut, de priorité ou de
responsable enregistre une décision de l’équipe. Il ne répare pas le logiciel
et ne réécrit pas les événements capturés.

Installez la [CLI LogBrew](/fr/guides/cli) et exécutez `logbrew login` avant de
commencer.

## Problèmes et occurrences

Une liste de problèmes renvoie un résumé du groupe, pas un événement complet.
Lisez ces champs avant d’ouvrir le détail :

| Champ | Signification |
| - | - |
| `title` | Titre capturé de l’échec. |
| `severity` | Gravité capturée. |
| `triage.effective_severity` | Gravité que LogBrew utilise après application des règles de problème. `severity` conserve la valeur capturée. `triage.rule_applied` vaut `true` quand une règle s’applique. |
| `occurrence_count` | Nombre d’occurrences conservées dans le groupe. |
| `first_seen_at` | Heure de la plus ancienne occurrence conservée. |
| `last_seen_at` | Heure de la plus récente occurrence conservée. |
| `project_id` | Projet qui contient le problème. |
| `service_name` | Service de la dernière occurrence. |
| `release` | Version de la dernière occurrence. |
| `environment` | Environnement de la dernière occurrence. |
| `status` | État du problème dans le workflow. Consultez [Valeurs de statut](#status-values). |
| `priority` | Ordre de triage du problème. Consultez [Priorité](#priority). |
| `priority_source` | `manual` quand une personne a défini la priorité. `derived` quand elle suit la gravité. |
| `assignee` | Compte ou équipe responsable de la prochaine étape, ou `null`. Consultez [Attribuer des problèmes](#assign-issues). |

Le nombre d’occurrences n’est pas un nombre d’utilisateurs touchés. Les
comptages et les heures s’appliquent au périmètre renvoyé, pas à tout
l’historique des erreurs. Un filtre `--since` ou `--until` limite les
occurrences que LogBrew compte. Quand vous communiquez un comptage, indiquez
aussi les filtres qui l’ont produit.

## <span id="status-values">Valeurs de statut</span>

| Statut | Signification |
| - | - |
| `unresolved` | Le problème attend une décision. |
| `resolved` | L’équipe a marqué le problème comme corrigé. Le statut ne prouve pas la correction. |
| `archived` | L’équipe a retiré le problème du triage actif. |

`archived` s’appelait auparavant `ignored`. Les 2 noms sélectionnent les mêmes
problèmes, et les 2 sont acceptés en entrée. `logbrew read`, `logbrew issues`
et les versions 2 et 3 de l’API affichent `archived`. La version 1 de l’API
(par défaut), le flux de suivi en direct et la réponse d’investigation de
problème affichent `ignored`. Le tableau de bord affiche les statuts
« Non résolu », « Résolu » et « Archivé ».

Le statut s’applique à tout le problème, pas à une seule occurrence. La gravité
indique l’urgence, et le statut enregistre la décision. Gardez les deux
séparés. Un problème `critical` peut passer à `resolved` après un correctif
vérifié. Un problème `archived` conserve sa gravité capturée.

LogBrew ne rouvre pas automatiquement un problème résolu. Quand une nouvelle
occurrence arrive après la résolution, l’investigation indique
`regressed` pour `lifecycle.effective_status`. Le `status` reste `resolved`
jusqu’à ce qu’une personne rouvre le problème.

## <span id="priority">Priorité</span>

La priorité fixe l’ordre dans lequel l’équipe trie les problèmes :

| Priorité | Signification |
| - | - |
| `high` | Examinez le problème en premier. |
| `medium` | Examinez le problème après les problèmes `high`. |
| `low` | Le problème peut attendre. |

Chaque problème a une priorité. Si personne ne la définit, elle suit la gravité
du problème : `error` et `critical` donnent `high`, `warning` donne `medium`,
et `info` donne `low`. Quand une règle de problème modifie la gravité, la
priorité suit `triage.effective_severity`. `priority_source` vaut alors
`derived`. Quand une personne définit la priorité, celle-ci reste fixe et
`priority_source` vaut `manual`.

Pour lister les problèmes à examiner en premier :

```bash theme={null}
logbrew read issues --project "<project_id>" --status unresolved \
  --priority high --since 24h --json
```

## <span id="assign-issues">Attribuer des problèmes</span>

Attribuez un problème pour indiquer qui est responsable de la prochaine étape.
Un problème a 0 ou 1 responsable : un compte ou une équipe.

<Steps>
  <Step title="Trouver les comptes attribuables">
    ```bash theme={null}
    logbrew issues assignees --project "<project_id>" --json
    ```

    `assignees` contient chaque compte qui peut lire le projet, avec
    `user_id`, `name` et `email`. `teams` contient chaque équipe de
    l’organisation du projet, avec `team_id`, `slug` et `name`. Vous ne pouvez
    pas attribuer un problème à un compte qui ne peut pas lire le projet, ni à
    une équipe d’une autre organisation.
  </Step>

  <Step title="Attribuer le problème">
    ```bash theme={null}
    logbrew issues assign "<user_id>" "<issue_id>" --json
    logbrew issues assign "team:<team_id>" "<issue_id>" --json
    ```

    Utilisez `me` à la place d’un ID d’utilisateur pour vous attribuer le
    problème. Utilisez `logbrew issues unassign "<issue_id>" --json` pour
    retirer l’attribution. Ajoutez `--project` pour modifier jusqu’à 100
    problèmes d’un même projet.
  </Step>

  <Step title="Lire vos problèmes">
    ```bash theme={null}
    logbrew read issues --project "<project_id>" --assignee me \
      --status unresolved --json
    ```

    Utilisez `--assignee my_teams` pour les problèmes de vos équipes,
    `--assignee "team:<team_id>"` pour une seule équipe, et `--assignee none`
    pour les problèmes qui n’ont pas de responsable.
  </Step>
</Steps>

Pour attribuer des problèmes, vous devez avoir l’autorisation de gérer les
problèmes du projet. La même autorisation permet de changer le statut, la
priorité, les règles de propriété, ainsi que les règles de problèmes et de
logs. Les propriétaires et les admins de l’organisation créent les équipes et
choisissent leurs membres. Une équipe ne donne à ses membres aucun accès aux
projets.

Quand un membre perd l’accès au projet, les problèmes qui lui sont attribués
n’affichent plus de responsable. Quand une équipe est supprimée, les problèmes
qui lui sont attribués n’affichent plus de responsable. Ces problèmes
apparaissent dans les lectures avec `--assignee none`. Si le membre retrouve
l’accès, les problèmes affichent de nouveau ce membre, sauf si quelqu’un a
changé ou retiré l’attribution entre-temps.

## <span id="find-who-owns-an-issue">Trouver le propriétaire d’un problème</span>

```bash theme={null}
logbrew issues owners "<issue_id>" --json
```

Le résultat liste les propriétaires suggérés, du plus pertinent au moins
pertinent, ainsi qu’un `suggested_assignee`. Chaque propriétaire a une
`source` :

| `source` | Signification |
| - | - |
| `ownership_rule` | Une règle du projet correspond au problème. `rule`, `line` et `matched` indiquent la règle et ce qu’elle a trouvé. |
| `codeowners` | Une ligne du fichier CODEOWNERS du projet correspond au chemin d’un frame de pile. |
| `recent_activity` | Le compte a modifié le problème ou en a été responsable. |

`inputs` compte les chemins de frames de pile, les modules, le modèle de route,
les tags et les règles que LogBrew a vérifiés. Si la liste est vide et que
`inputs` n’indique aucun chemin, le problème n’a pas de preuve à comparer. Cela
ne veut pas dire qu’il n’a pas de propriétaire.

Écrivez les règles de propriété dans un fichier texte, une règle par ligne :

```text theme={null}
# type:pattern owner...
path:src/payments/** ada@example.com #payments
url:/checkout/* #web
service:billing-api ada@example.com
tags.region:eu-* #europe
module:app.billing.* ada@example.com
```

Un motif `path` correspond à la fin du chemin d’un frame de pile : ainsi,
`src/payments/**` trouve les frames sous n’importe quel répertoire de
déploiement. `*` correspond à n’importe quel texte. Les propriétaires sont des
e-mails de comptes ou des `#team-slug`. La dernière règle qui correspond passe
en premier. Envoyez ensuite les règles, un fichier CODEOWNERS de GitHub, ou les
deux :

```bash theme={null}
logbrew issues ownership set --project "<project_id>" \
  --rules ownership.txt --codeowners .github/CODEOWNERS --json
logbrew issues ownership --project "<project_id>" --json
```

Dans CODEOWNERS, un e-mail désigne un compte, et `@org/team-slug` désigne
l’équipe qui a ce slug. Les règles qui désignent un compte sans accès au projet
ou une équipe inconnue échouent avec `422`. Les propriétaires CODEOWNERS qui ne
désignent personne apparaissent dans `unresolved_owners`. Un fichier vide
efface son texte.

## <span id="read-the-issue-history">Lire l’historique d’un problème</span>

```bash theme={null}
logbrew issues activity "<issue_id>" --json
```

L’historique liste chaque changement de statut, de priorité, de responsable et
de règle de gravité, du plus récent au plus ancien, avec le compte qui l’a
fait. Il se termine par `first_seen`. Un compte qui a perdu l’accès au projet
ne garde que son ID. Utilisez `--limit` et les valeurs de `next_cursor` pour
lire la suite.

## <span id="read-your-inbox">Lire votre boîte de réception</span>

```bash theme={null}
logbrew inbox --json
logbrew inbox read --json
```

La boîte de réception liste les problèmes que d’autres personnes vous ont
attribués, à vous ou à vos équipes, du plus récent au plus ancien. `unread`
compte les attributions arrivées après votre marque de lecture.
`logbrew inbox read` place la marque de lecture à maintenant. LogBrew n’envoie
pas d’e-mail pour ces attributions. La boîte de réception n’affiche que les
projets que vous pouvez lire actuellement.

## Workflow recommandé

<Steps>
  <Step title="Lister les problèmes non résolus d’un périmètre">
    ```bash theme={null}
    logbrew read issues --project "<project_id>" --environment production \
      --release api@1.2.3 --status unresolved --since 24h --json
    ```

    Gardez les mêmes filtres pour les lectures de liste suivantes. Un résultat
    vide signifie qu’aucun problème ne correspond à ce périmètre. Il ne prouve
    pas que le projet n’a pas d’erreurs. Copiez l’ID exact du problème, pas son
    titre.
  </Step>

  <Step title="Lire le détail du problème">
    ```bash theme={null}
    logbrew read issue "<issue_id>" --json
    ```

    Vérifiez que le projet renvoyé est le bon avant de continuer. Les lectures
    renvoient un instantané. Relisez le problème avant de changer son statut.
  </Step>

  <Step title="Investiguer une occurrence">
    ```bash theme={null}
    logbrew investigate issue "<issue_id>" --occurrence recommended --json
    ```

    Les lectures de détail et d’investigation n’utilisent pas les filtres de
    liste. Comparez `subject.project_id`, `event.occurred_at`, la version et
    l’environnement avec votre périmètre. L’occurrence recommandée peut être
    plus ancienne que la dernière. Suivez
    [Investiguer un problème](/fr/guides/investigate-an-issue) pour l’examen
    complet des preuves.
  </Step>

  <Step title="Suivre les preuves de trace seulement si elles sont disponibles">
    Lisez la trace uniquement quand `correlations.trace.status` vaut
    `available`. Utilisez l’ID de trace de la réponse. N’en inventez jamais
    un.

    ```bash theme={null}
    logbrew read trace "<trace_id>" --project "<project_id>" --json
    logbrew read logs --trace "<trace_id>" --project "<project_id>" \
      --since 24h --json
    ```

    La lecture de trace n’a pas de filtre de période. Si le statut vaut
    `not_linked`, continuez avec les preuves du problème.
  </Step>

  <Step title="Vérifier le déploiement candidat">
    Utilisez l’occurrence investiguée comme référence. Récupérez l’ID du
    déploiement dans les preuves de déploiement ou dans votre processus de
    livraison.

    ```bash theme={null}
    logbrew investigate issue "<issue_id>" verify \
      --baseline-occurrence "<occurrence_id>" \
      --candidate-deployment "<deployment_id>" \
      --json
    ```

    L’absence de récurrence pendant la période d’observation ne prouve pas
    une correction définitive. Si `status` vaut `insufficient_traffic` ou
    `unavailable`, laissez le problème à `unresolved`. Suivez la prochaine
    étape renvoyée.
  </Step>

  <Step title="Changer le statut, la priorité ou le responsable">
    Exécutez une seule commande. Ces commandes ne demandent pas de
    confirmation : vérifiez donc d’abord l’ID du problème.

    ```bash theme={null}
    logbrew issues resolve "<issue_id>" --json
    logbrew issues archive "<issue_id>" --json
    logbrew issues reopen "<issue_id>" --json
    logbrew issues priority low "<issue_id>" --json
    logbrew issues assign me "<issue_id>" --json
    ```

    Sans `--project`, chaque commande accepte 1 ID de problème. Vérifiez le
    code de sortie ainsi que les `status`, `priority` et `assignee` renvoyés.
    Si le résultat manque, relisez le problème avant la modification
    suivante.

    Les anciens scripts peuvent utiliser
    `logbrew set issue "<issue_id>" resolved` et les raccourcis `resolve`,
    `ignore` et `reopen`. `ignore` définit `archived`.
  </Step>
</Steps>

## Modifier plusieurs problèmes à la fois

Ajoutez `--project` pour modifier jusqu’à 100 problèmes d’un même projet en
une seule commande :

```bash theme={null}
logbrew issues archive "<issue_id_1>" "<issue_id_2>" "<issue_id_3>" \
  --project "<project_id>" --json
```

La commande applique la même modification à chaque problème. Chaque ID de
problème ne peut apparaître qu’une fois. La CLI rejette plus de 100 ID ou un ID
répété avant d’envoyer une requête. Le résultat contient 1 entrée par problème,
dans l’ordre de la commande :

| Résultat | Signification |
| - | - |
| `updated` | LogBrew a appliqué la modification. |
| `unchanged` | Le problème avait déjà la valeur demandée. |
| `not_found` | Le projet n’a aucun problème avec cet ID. LogBrew n’a rien modifié pour lui. |

Chaque entrée contient `issue_id`, `outcome` et `issue`. `issue` est le
problème dans son état actuel, ou `null` pour `not_found`. Vous pouvez relancer
la même commande après une panne réseau. Les problèmes déjà modifiés affichent
`unchanged`. Pour plus de 100 problèmes, exécutez plusieurs commandes. Pour un
résultat `not_found`, recopiez l’ID depuis une liste de problèmes de ce projet.
Consultez
[Mettre à jour des problèmes en masse](/fr/reference/telemetry-api#update-issues-in-bulk)
pour la requête d’API.

## Choisir le statut suivant

* **Gardez `unresolved`** quand l’échec est actif ou que le correctif n’est pas
  vérifié. Une trace manquante n’est pas une raison d’archiver un problème.
* **Passez à `resolved`** quand l’équipe a accepté les preuves du correctif. Un
  correctif proposé n’est pas une preuve.
* **Passez à `archived`** pour une condition acceptée ou un signal de test
  uniquement. La décision s’applique à toutes les occurrences du problème. La
  commande n’a pas de champ de motif : notez donc le motif dans le suivi de
  travail de votre équipe.
* **Rouvrez avec `unresolved`** quand une nouvelle occurrence arrive après la
  résolution. `lifecycle.regression.first_reappeared_occurrence` l’identifie.
  Comparez-la avec l’occurrence utilisée pour la résolution. Ne créez pas un
  autre problème.

## Transmettre l’investigation

Donnez à la personne suivante des références, pas une copie brute des
événements :

* L’ID, le statut, la priorité, le responsable et la gravité du problème.
* Le projet, le service, l’environnement et la version.
* L’heure de première occurrence, l’heure de dernière occurrence et le nombre
  d’occurrences.
* L’ID de l’occurrence sélectionnée et `occurrence_selection.reason`.
* `fix.status`, `cause.status` et leur `provenance`.
* Le statut et l’ID de la trace, s’ils sont disponibles.
* Le statut de reproduction et les preuves manquantes.
* Le résultat de la vérification du déploiement candidat.
* La prochaine étape renvoyée par la réponse.

Présentez les causes et les correctifs proposés comme des propositions.

## Corriger les erreurs de la CLI

Vérifiez le code de sortie du processus avant d’analyser la sortie. En cas de
succès, le JSON est écrit sur la sortie standard. Une erreur d’analyse de la
commande se termine avec le code `2`. Une erreur d’exécution se termine avec le
code `1`. Les erreurs JSON sont écrites sur la sortie d’erreur standard et
contiennent `ok: false`, `error`, `message` et `next`. Affichez `next` comme
une indication. Ne l’exécutez pas automatiquement.

Par exemple, `logbrew issues archive "<issue_id_1>" "<issue_id_2>" --json`
n’a pas de `--project`. La commande se termine avec le code `2` avant toute
requête, avec l’erreur `invalid_issue_command`.

Quand l’API rejette une requête, `error` vaut `api_error`. Lisez `status` pour
le statut HTTP et `api_code` pour le code d’erreur de l’API.

| Résultat | Correction |
| - | - |
| `not_logged_in` | Demandez à une personne d’exécuter `logbrew login`, puis relancez la lecture. |
| `invalid_issue_command` | Corrigez la commande. Utilisez `--project` pour plusieurs problèmes, au maximum 100 ID, et chaque ID une seule fois. |
| ID de problème non valide | Copiez l’ID exact depuis une liste de problèmes ou une réponse de détail. |
| Problème introuvable | Vérifiez le compte connecté et le projet. |
| Une modification échoue avec le `status` `403` | Le compte ne peut pas gérer les problèmes de ce projet. Demandez à une personne qui a cet accès. |
| `invalid_assignee` | Le filtre `--assignee` accepte `me`, `none`, `my_teams`, un ID d’utilisateur ou `team:<team_id>`. |
| Une attribution échoue avec le `status` `422` et l’`api_code` `validation_failed` | Le compte ne peut pas lire le projet, ou l’équipe n’appartient pas à l’organisation du projet. Choisissez-en un dans `logbrew issues assignees`. |
| `invalid_ownership_command`, `invalid_ownership_file` | Corrigez la commande. Un fichier de propriété doit être un texte UTF-8 de 128 Kio au plus. |
| `invalid_inbox_command` | Utilisez `logbrew inbox` ou `logbrew inbox read`. |
| `investigation_response_invalid` | La réponse n’a pas passé la validation de la CLI. Réessayez une fois. Si l’erreur se répète, mettez à jour la CLI ou signalez le dysfonctionnement. Ne contournez pas la validation. |
| Statut de trace `not_linked` | Continuez avec les preuves du problème. Ne lisez pas de trace. |
| Statut de trace `unavailable` | Relancez la lecture d’investigation plus tard. |
| Vérification `insufficient_traffic` | Laissez le problème à `unresolved`. Attendez du trafic sur la version candidate, puis vérifiez de nouveau. |

Une réponse en échec ne prouve pas qu’un changement de statut, de priorité ou
de responsable n’a eu aucun effet. Relisez le problème avant de réessayer.

## Ce qui rend un problème utile

* Un titre clair et un message lisible.
* Une empreinte stable.
* Des frames de pile, quand ils sont disponibles.
* Le contexte de version, d’environnement et de service.
* Le contexte de trace, quand il est capturé avec l’occurrence.
* Quelques attributs courts et pertinents, pas des payloads complets.

Consultez [API de télémétrie](/fr/reference/telemetry-api)
pour les filtres de liste et les contrats de réponse.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.