Une panne en production revient à l’équipe sous forme de correctif, pas de ticket

Le client et ses difficultés

Il s’agit de notre propre produit, créé pour nos besoins et utilisé tous les jours. Le constat de départ était simple : une grande partie des incidents qui surviennent en production ne sont pas des problèmes complexes. Ce sont de petits détails : un service externe modifie le format de sa réponse, une page dont nous récupérons les données change de structure ou une condition limite n’est plus respectée. La correction ne prend que quelques minutes, mais avant de s’y mettre, il faut lire le ticket, reproduire le problème, trouver le code concerné et se remettre dans le contexte. Ces minutes deviennent une heure, et plusieurs heures de ce type s’accumulent chaque semaine.

L’idée naturelle — laisser un modèle écrire le correctif — présente un défaut majeur. Le modèle peut produire un correctif accompagné d’un test adapté qui réussit, alors que le problème initial n’a pas du tout été résolu. Il s’auto-évalue. Il nous fallait une preuve indépendante de l’auteur du code.

Deuxième enjeu : la sécurité. Tout changement ne peut pas être appliqué sans intervention humaine. Un correctif touchant aux paiements ou aux autorisations relève d’une autre catégorie qu’une adaptation à un format de données modifié. Enfin, toutes les pannes ne se corrigent pas par du code. Certaines sont dues à des restrictions imposées par des services externes ou à des accès expirés. L’agent devait les reconnaître et ne rien faire, plutôt que de créer des tickets que personne ne pourrait résoudre.

Ce que nous avons mis en place

Nous avons créé une boucle où deux agents indépendants se partagent la correction et sa vérification. Une règle, et non un modèle, décide si le changement peut être appliqué.

Tout commence par un événement. L’application touchée envoie un signal contenant le diagnostic et l’empreinte de l’erreur, afin qu’un même incident ne lance pas le processus dix fois. La boucle est un composant réutilisable dans GitHub Actions : quelques lignes de configuration suffisent pour l’ajouter à un autre projet, sans déploiement distinct.

Le premier agent, basé sur Claude Code, commence par écrire un test qui reproduit l’erreur, puis propose le correctif le plus limité possible. L’ordre compte : il faut d’abord prouver le problème, puis le résoudre. Le résultat est soumis sous forme de proposition de changement standard, comme celle qu’ouvrirait un membre de l’équipe.

Le second agent est lancé séparément et ne connaît pas le raisonnement du premier. Il vérifie un point précis : le test échoue-t-il bien sur l’ancien code et réussit-il sur le nouveau ? C’est la preuve objective qui manque lorsque l’auteur du correctif est aussi chargé de l’évaluer.

Enfin, un garde-fou non agentique applique une règle simple : si le changement présente un faible risque, que tous les tests passent et que la vérification indépendante est concluante, le correctif est appliqué automatiquement. Dans tous les autres cas, il attend une personne. Supabase héberge le tableau des cas en attente et l’historique complet de la boucle.

Fonctionnement actuel

La boucle fait partie de notre travail quotidien. Lorsqu’un incident survient, l’équipe ne reçoit pas un ticket à décortiquer, mais une proposition de changement prête à examiner, accompagnée d’un test qui prouve que le problème existait et qu’il a été résolu.

Les petites pannes récurrentes disparaissent sans intervention : le matin, on voit simplement qu’un incident de la veille a été corrigé. Les correctifs considérés comme sensibles attendent une décision humaine dans le tableau ; c’est la seule étape manuelle. Les incidents impossibles à corriger dans le code sont reconnus et mis de côté, au lieu d’encombrer la file d’attente.

Résultats

Deux agents indépendants se chargent de la correction et de sa vérification. Les correctifs à faible risque sont appliqués automatiquement ; les changements risqués attendent une décision humaine. Chaque changement est étayé par une preuve claire : le test échouait avant la correction et réussit après.

Ce que nous ferions autrement

La première version n’utilisait qu’un seul agent pour écrire le correctif et l’évaluer lui-même. Tout semblait fonctionner jusqu’à ce que nous examinions précisément ce qui avait été corrigé. Séparer le travail en deux processus indépendants a été la seule véritable réponse aux réussites inventées ; cette séparation aurait dû être prévue dès le premier jour.

Nous avons aussi sous-estimé la part des tickets impossibles à résoudre par le code : accès expirés, restrictions imposées par des services externes ou pannes de systèmes tiers. Avant d’ajouter leur détection, la boucle produisait du bruit et l’équipe cessait de prêter attention aux résultats. La cause de l’incident devrait être classée avant l’intervention de l’agent correcteur, et non après.