Finuslugi lance des agents IA nocturnes : ils ont repéré des pertes sur 1600 inscriptions sans la moindre alerte

Les problèmes les plus pénibles en production ne ressemblent pas à des pannes. Les principaux graphiques sont au vert, les alertes restent muettes, le service est disponible, mais sur une étape du parcours utilisateur, la part d'opérations en échec ou le temps de réponse augmente. Pour le système dans son ensemble, tout va bien ; pour la personne concernée, le produit est cassé.

Chaque semaine, l'équipe inscription de Finuslugi refaisait à la main le même parcours : Grafana, puis les logs dans OpenSearch, puis la recherche de l'opération métier problématique et du code associé. Cela représentait de quatre à huit heures par semaine, et ce avant même que l'ingénieur ne commence à réfléchir à ce qu'il fallait corriger. C'est précisément cette partie que l'équipe a décidé d'automatiser : non pas la prise de décision, mais la collecte des faits et la préparation d'une hypothèse.

Comment fonctionne le circuit nocturne

À heure fixe (dans Multica, c'est Autopilot), une tâche est créée et reprise par OpenCode. Un lead-agent prend ensuite le relais : via MCP, il lit dans Confluence le catalogue des opérations métier et les règles de contrôle de chacune. Dans le scénario de base pour Prometheus, il y a 21 opérations. Le lead-agent les distribue à sept agents enfants, à raison de trois chacun, et ceux-ci vérifient leur périmètre en parallèle.

Le diagnostic est volontairement scindé en deux étapes. Dans la première, un agent collecteur travaille au sein d'un seul circuit d'observabilité et répond à une question étroite : y a-t-il un écart, et quelle est sa gravité ? Il compare les faits au SLA et à la baseline, puis attribue un statut : OK, WARNING ou BREACH. Il produit une fiche courte : opération, valeur constatée, SLA, baseline et données probantes. Seuls les statuts WARNING et BREACH parviennent à l'analyst-agent. Celui-ci ouvre le dépôt associé et formule une hypothèse sur la cause.

Si l'écart est confirmé, Multica assemble un brouillon de ticket Jira. Il contient l'opération métier, les valeurs des métriques, la violation du SLA, le contexte technique, la cause et une proposition de correctif. Le mot clé est ici « brouillon » : c'est l'ingénieur qui fait passer la tâche dans le backlog, après avoir vérifié les conclusions.

Pourquoi on ne peut pas simplement donner tous les logs au modèle

La tentation se comprend : « regarde tous les services, les métriques, les logs et le code, et trouve quelque chose de suspect ». En pratique, une telle requête se heurte au temps d'exécution, à la taille du contexte et à la qualité de la réponse. Plus les données sont hétérogènes, plus il est difficile de comprendre sur quoi repose l'hypothèse.

C'est pourquoi les SLA et l'observabilité commencent par restreindre la recherche, et la sous-tâche devient à la fois l'unité de parallélisme et la frontière du contexte. Cela offre plusieurs avantages concrets : les calculs déterministes ne se mélangent pas au raisonnement du LLM, la partie qui a échoué peut être relancée séparément, et la qualité se vérifie au niveau d'un rôle et d'un artefact précis.

Trois sources, trois couches de problèmes

Le système a été étoffé par étapes, et chaque source répondait à sa propre question.

• Prometheus montre où quelque chose a changé : failrate, latence et respect des SLA par opération. La première version, fondée sur les métriques et le code, a trouvé des problèmes touchant environ 1000 inscriptions.
• OpenSearch explique ce qui s'est exactement passé : codes HTTP, messages d'erreur, stack traces. Cela a ajouté environ 600 inscriptions. Si la cause se trouve dans le service d'une autre équipe, l'agent peut consulter le dépôt de l'équipe voisine s'il y a accès ; le lien est déterminé par les appels Feign.
• Sentry a apporté une nouvelle classe de signaux : erreurs front-end et vitesse de chargement des pages. Une page sans erreur mais qui met une minute à charger ne fonctionne pas pour l'utilisateur, et le failrate du backend ne le montrera pas.

Après chaque série de corrections, le résultat plafonnait jusqu'au branchement de la source suivante. Les auteurs en tirent honnêtement la conclusion : le gain ne venait pas de l'« intelligence » du modèle, mais de l'élargissement du champ de vision.

Limites et marche à suivre en pratique

On ne peut pas réduire le failrate à une seule formule. Les erreurs 500 et les 401/403/422 n'ont pas la même sémantique, les erreurs attendues, comme une session expirée, ont leur propre niveau acceptable, et certaines opérations ont leurs propres exceptions. L'agent n'est utile que dans la mesure où l'équipe a décrit avec précision les opérations, les SLA, les baselines et le sens des signaux. L'IA ne remplace pas le modèle d'observabilité, elle s'appuie sur lui.

Le circuit de diagnostic devient lui-même un système de production, et il faut donc aussi le superviser : stabilité des exécutions, taux de faux positifs, utilité des rapports. Il faut aussi examiner le cheminement par lequel l'agent est arrivé à sa conclusion. Un faux positif signifie qu'il faut préciser le SLA ou la formule. Données insuffisantes : améliorez l'observabilité ou le skill de collecte du contexte. Mauvais dépôt choisi : améliorez le skill d'analyse des dépendances. Rapport bruyant : durcissez le contrat.

Pour reproduire l'approche, ne commencez pas par l'agent. Formalisez d'abord ce qui compte comme un problème et à quoi comparer les signaux, sinon le LLM ne fera que reproduire votre incertitude. Fixez le rapport final comme un contrat : opération, severity, faits, impact, code, hypothèse, niveau de confiance, prochaine action.

L'équipe prévoit de raccourcir le chemin entre l'hypothèse et le correctif : correctifs types et MR à la place du brouillon Jira. Mais plus l'agent s'approche de la modification de la production, plus la vérification humaine, le contrôle d'accès et la reproductibilité deviennent importants. Pour l'instant, ce n'est pas un « ingénieur IA » autonome qui l'emporte, mais des rôles étroits, des frontières claires et un humain au point de décision.