# Un agent IA relié à Sentry propose un correctif à chaque erreur

> 34 propositions de correctif en un mois, une seule fusionnée sans modification. Retour sur un agent qui suggère du code à partir d'une trace Sentry, avec une revue humaine qui reste incontournable.

- Auteur : Clément Hadrot
- Publié le : 2025-10-28
- Mis à jour le : 2025-10-28
- Catégorie : IA & MCP
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/agent-ia-sentry-propose-correctif/

## L’essentiel

- L'agent propose une branche et une pull request, jamais une fusion directe
- Le taux de correctifs valides du premier coup reste minoritaire
- La revue humaine détecte des effets de bord que l'agent ignore systématiquement

Trente-quatre propositions de correctif générées en un mois par l'agent mis en place au studio Rivelo, à partir des erreurs remontées par Sentry sur son application principale. Une seule d'entre elles a été fusionnée telle quelle, sans qu'un développeur n'y touche une seule ligne. Ce chiffre, volontairement mis en avant dans cet article plutôt que dissimulé, dit l'essentiel du fonctionnement réel de ce dispositif : un assistant à la proposition, pas un système de correction autonome.

L'agent surveille en continu les nouvelles erreurs remontées par Sentry, en filtre un sous-ensemble jugé traitable automatiquement (erreurs récurrentes avec une stack trace claire, excluant les erreurs liées à une infrastructure externe), et propose pour chacune une branche Git contenant un correctif potentiel, accompagné d'une pull request explicative.

## Le fonctionnement du pipeline

Dès qu'une erreur Sentry dépasse un seuil de dix occurrences en une heure, un déclencheur transmet son identifiant à l'agent, qui récupère la stack trace complète ainsi que le fichier source concerné via l'API du dépôt Git. Le modèle analyse ensuite le contexte du code autour de la ligne fautive, propose une modification, et ouvre une pull request avec un message décrivant son raisonnement et un lien vers l'événement Sentry d'origine.

```
if (event.count > 10 && event.duration_minutes <= 60) {
  const trace = await sentry.getStackTrace(event.id);
  const source = await git.getFileAtLine(trace.file, trace.line);
  const suggestion = await agent.proposeFix({ trace, source });
  await git.openPullRequest(suggestion);
}
```

## La revue humaine, jamais contournée

> L'essentiel à retenir : L'agent propose une branche et une pull request, jamais une fusion directe ; Le taux de correctifs valides du premier coup reste minoritaire ; La revue humaine détecte des effets de bord que l'agent ignore systématiquement

Aucune pull request générée par l'agent n'est fusionnée automatiquement, quel que soit le niveau de confiance affiché dans son propre résumé : la configuration du dépôt impose une revue humaine obligatoire sur cette branche particulière, sans exception possible même pour un correctif jugé trivial par le modèle lui-même. Cette contrainte technique, pas seulement une consigne d'équipe, garantit qu'aucune fusion accidentelle ne puisse se produire par simple oubli d'un développeur pressé.

Sur les trente-quatre propositions du mois observé, vingt-deux ont été jugées globalement pertinentes mais nécessitant un ajustement avant fusion, neuf ont été rejetées faute de comprendre correctement le contexte métier de l'erreur, et une seule a été fusionnée sans aucune modification, un cas simple de vérification d'index de tableau manquante.

### Ce que la revue humaine a détecté que l'agent ignorait

- Un correctif qui aurait supprimé une vérification de sécurité en même temps que le bug ciblé, sans que l'agent ne perçoive ce lien.
- Une régression potentielle sur un cas d'usage rare, non couvert par les tests existants et donc invisible pour l'agent qui ne s'appuyait que sur la stack trace.
- Un correctif techniquement correct mais qui ne respectait pas une convention de nommage propre à ce module, ajoutée après le dernier entraînement pertinent du modèle.

> Un agent qui propose un correctif n'élimine pas le besoin de relecture, il en change la nature : on ne relit plus une ligne écrite à la hâte par un collègue fatigué, on relit une hypothèse formulée par un système qui n'a jamais vu tourner l'application en production.

## Pourquoi ce taux de 3 % n'est pas un échec

Considérer que 97 % de propositions non fusionnées telles quelles représente un échec du dispositif reviendrait à mal mesurer sa valeur réelle : même les propositions rejetées ou modifiées ont, dans la grande majorité des cas, permis au développeur d'identifier plus vite la ligne fautive et le contexte de l'erreur, un gain de temps qui ne se lit pas dans le seul taux de fusion directe.

## Ce que ce dispositif ne fait pas

La configuration initiale de Sentry, ses règles de regroupement et ses seuils d'alerte restent en dehors du périmètre de ce projet, qui se contente d'exploiter les événements déjà qualifiés par l'outil de suivi d'erreurs en amont.

## En résumé

Un agent relié à Sentry capable de proposer un correctif de code accélère la première étape du traitement d'une erreur, sans jamais dispenser d'une revue humaine attentive avant toute fusion. Le studio Rivelo considère ce dispositif comme un gain net, à condition de ne jamais perdre de vue que la responsabilité finale du code fusionné reste entièrement humaine.