Clustraly
Intelligence des erreurs & RGPD

Gestion du cycle de vie : maîtrisez le statut de chaque erreur, de l'ouverture à la résolution

Gestion du cycle de vie (statut) une fonctionnalité du module Intelligence des erreurs & RGPD de Clustraly. La gestion du cycle de vie pilote le statut de chaque groupe d'erreurs ouvert, en cours, résolu, ignoré avec horodatage et détection des régressions.

Faites avancer chaque groupe d'erreurs entre ouvert, en cours, résolu et ignoré. La résolution s'horodate toute seule, et toute réapparition d'un bug déjà corrigé rebascule le groupe en régression. Vous gardez la décision, l'outil garde la trace.

Transitions d'état

Faites avancer chaque erreur d'un statut clair au suivant

Un groupe d'erreurs n'est jamais figé. Vous le déplacez à la main entre ouvert, en cours d'investigation, résolu ou ignoré, selon là où en est réellement votre équipe. Le statut reflète votre travail, pas une supposition.

L'IA vous propose des diagnostics ; vous décidez du statut. Chaque changement est immédiat et se retrouve dans les filtres et onglets de la console d'intelligence des erreurs.

  • Quatre états manuels : ouvert, en cours, résolu, ignoré
  • Statut modifiable à tout moment sur le groupe
  • Filtres et onglets par statut dans la console
Résolution tracée

Marquez « résolu » : la trace s'écrit toute seule

Dès que vous passez un groupe en résolu, l'outil horodate l'action : qui a résolu, à quel moment, et sur quelle version applicative. Vous n'avez plus à noter à côté qui a corrigé quoi, ni quand.

Cet historique reste attaché au groupe et alimente le rapport d'incident partageable, avec l'historique résolu, régressé et dernière alerte.

  • resolved_by, resolved_at et resolved_version enregistrés automatiquement
  • La version de résolution reste rattachée au groupe
  • Historique repris dans le rapport d'incident
Régression automatique

Une erreur résolue qui revient ? Vous le savez aussitôt

Si une empreinte déjà marquée résolue réapparaît, le groupe rebascule seul en « régression », avec la version et la date exactes où le problème est revenu. Aucune surveillance manuelle : le retour d'un bug ne passe plus inaperçu.

La régression étant un statut à part entière, elle se compte dans le tableau des tendances et se distingue nettement des nouvelles erreurs.

  • Bascule automatique en statut « regressed »
  • regressed_version et regressed_at horodatés
  • Nombre de régressions suivi dans les tendances
Nettoyage maîtrisé

Supprimez un groupe et tout son historique en une action

Quand un groupe n'a plus lieu d'exister, supprimez-le avec l'ensemble de ses évènements. L'action réclame une confirmation explicite, pour qu'aucun effacement n'arrive par accident.

Vous gardez une console propre, centrée sur les erreurs qui comptent vraiment, sans accumuler du bruit résolu depuis longtemps.

  • Suppression du groupe et de tous ses évènements
  • Confirmation obligatoire avant effacement
  • Réservée aux profils habilités errors.manage
Garde-fous

Chaque changement de statut reste sous contrôle

Changer un statut, résoudre ou supprimer un groupe exige la permission errors.manage et un jeton CSRF valide. Les actions sensibles sont protégées côté serveur, pas seulement masquées dans l'interface.

Le pilotage du cycle de vie reste ainsi réservé aux bonnes personnes, avec une traçabilité claire de qui fait quoi.

  • Permission errors.manage requise pour toute transition
  • Jeton CSRF vérifié à chaque action
  • Suppression protégée par une confirmation supplémentaire
Pourquoi ça compte

Vous pilotez, l'outil trace

Le statut, l'horodatage et la détection de régression avancent ensemble. Vous décidez de l'état de chaque erreur ; Clustraly enregistre qui, quand et sur quelle version et rebascule seul le groupe en régression si un problème résolu refait surface.

FAQ

Questions fréquentes

Quels statuts un groupe d'erreurs peut-il prendre ?
Quatre états se pilotent à la main : ouvert, en cours d'investigation, résolu et ignoré. Un cinquième état, « régression », s'applique automatiquement lorsqu'une erreur déjà résolue réapparaît.
Que se passe-t-il exactement quand je marque une erreur comme résolue ?
L'outil enregistre automatiquement l'auteur de la résolution (resolved_by), la date (resolved_at) et la version applicative concernée (resolved_version). Ces informations restent attachées au groupe et alimentent le rapport d'incident.
Comment une régression est-elle détectée ?
Si l'empreinte d'un groupe déjà résolu réapparaît dans un nouvel évènement, le groupe rebascule automatiquement en « régression », avec la version et la date de réapparition (regressed_version, regressed_at). Aucune action manuelle n'est nécessaire.
Qui peut changer un statut ou supprimer un groupe ?
Seuls les comptes disposant de la permission errors.manage. Chaque action requiert un jeton CSRF valide, et la suppression demande une confirmation explicite avant d'effacer le groupe et l'ensemble de ses évènements.
Prêt à commencer ?

Donnez à chaque erreur un statut qui dit la vérité

De l'ouverture à la résolution, en passant par la régression détectée toute seule, chaque groupe d'erreurs suit un cycle de vie clair et tracé. Vous gardez la décision ; Clustraly garde la mémoire qui a résolu, quand, et sur quelle version.