---
title: Mon run a échoué
question: Que faire quand un run se termine en échec ?
description: Lire la catégorie d'erreur, comprendre ce qu'elle veut dire, et savoir s'il faut relancer.
section: solve
order: 2
---
Ouvrez le run dans **Runs** : la catégorie d'erreur est affichée en haut, et c'est elle qui dit quoi faire. Un échec n'est pas forcément une panne — le plus souvent, le pipeline a refusé de livrer un travail qu'il jugeait insuffisant.

## Que veulent dire les catégories d'erreur ?

**Vérification insuffisante** — le code produit n'a pas atteint le score minimal, même après les tentatives de correction. La merge request existe, en brouillon, avec les reproches en commentaire. Lisez-les : souvent l'issue était ambiguë, parfois une convention interne manque à vos contextes.

**Question sans réponse** — l'agent lecteur avait besoin d'une précision et personne n'a répondu. Voir [Diavi me pose une question](/help/fr/clarification-demandee/).

**Intervention humaine nécessaire** — le pipeline a rencontré quelque chose qu'il ne sait pas trancher seul. La merge request contient ce qui a pu être fait, et le commentaire dit où ça bloque.

**Réponse trop longue** — le modèle a atteint son plafond de sortie en plein travail. Cela arrive sur les issues qui touchent beaucoup de fichiers d'un coup. Découpez l'issue en deux et relancez.

**Infrastructure** — un incident de notre côté. Ce run **n'est pas décompté** de votre quota. Relancez ; si ça se reproduit, écrivez-nous.

## Faut-il relancer ?

Relancer à l'identique ne sert que si l'échec était une erreur d'infrastructure. Dans tous les autres cas, changez quelque chose d'abord : préciser l'issue, la découper, ou ajouter la convention manquante à vos contextes. Sans changement, le second run rencontrera le même mur que le premier — et comptera dans votre quota.

## Où voir le détail ?

L'onglet **Logs** montre le déroulé complet, étape par étape. Un glossaire y explique les termes qui reviennent.