Agents IA d’astreinte : diagnostiquer les incidents
Découvrez comment des agents IA et une base graphe relient alertes, dépendances et changements pour accélérer le diagnostic. Examinez le projet et ses limites.
Huit alertes, une seule panne : comment des agents IA remontent à la cause
À deux heures du matin, le paiement ne passe plus. Le site ralentit, le service de paiement échoue, le proxy remonte des erreurs, et plusieurs applications jusque-là muettes se mettent à alerter. Huit notifications - mais peut-être une seule panne à résoudre. Le plus dur n'est pas de manquer d'informations. C'est de relier les bonnes données assez vite pour démêler les symptômes de la cause.
Un projet expérimental, Blast Radius, propose une approche assez pragmatique : confier à plusieurs agents IA un contexte structuré dans une base de données en graphe. Les alertes, les dépendances techniques, les changements récents, les équipes responsables et les incidents passés deviennent des éléments reliés. L'agent peut ensuite enquêter à partir de questions opérationnelles, pendant que le graphe vérifie une partie de ses réponses.
Présenté pour Graph Hacks 2026, ce cas d'usage sert surtout à tester une idée : qu'est-ce que l'IA peut vraiment apporter aux opérations informatiques - et où il faut rester vigilant. Ci-dessous : l'architecture, les résultats, les compromis et les précautions avant d'envisager un déploiement en production.
Pourquoi huit alertes ne signifient pas huit pannes
Dans un système distribué, une panne n'arrive presque jamais « toute seule ». Elle se propage : si une base de données devient indisponible, les applications qui l'appellent peuvent échouer à leur tour. La supervision remonte alors plusieurs alertes, mais toutes ne pointent pas vers une cause indépendante. Certaines ne font que refléter les effets d'un même incident.
L'astreinte doit généralement répondre à trois questions, souvent avec des informations éparpillées dans différents outils :
- Quel composant est probablement à l'origine de l'incident, et lesquels sont touchés ?
- Quels changements récents peuvent expliquer la dégradation ?
- Qui contacter (équipe, propriétaire, personne) ?
Une alerte décrit un état anormal. Elle ne donne pas le chemin causal qui l'explique. Pour le reconstituer, il faut recouper la topologie des services, les dépôts de code, les demandes de fusion, les équipes propriétaires, les rotations d'astreinte et l'historique des incidents. Dit autrement : l'enquête consiste à relier des morceaux qui sont dispersés.
Le problème n'est pas seulement le volume d'alertes
Empiler des tableaux de bord ou multiplier les notifications n'aide pas si l'équipe ne sait pas distinguer le signal du bruit. L'objectif, c'est de réduire le temps entre la détection et une hypothèse vérifiable sur la cause.
L'IA peut aider, mais pas comme une boule de cristal. Un grand modèle de langage peut structurer une enquête, choisir quels outils consulter, et résumer des résultats. En revanche, sans contexte « réel » et contrôlé, il ne sait pas naturellement quelles dépendances existent dans votre organisation, ni qui est propriétaire de quoi. Il peut donc produire une réponse cohérente sur le papier... mais fausse par rapport à l'infrastructure.
Blast Radius traite le diagnostic comme un problème de relations entre objets. Par exemple : si le service de paiement dépend d'un sujet Kafka, et que plusieurs consommateurs de ce sujet tombent en panne en même temps, ce sujet devient une piste à regarder même s'il ne déclenche aucune alerte directement.
Pourquoi représenter l'incident sous forme de graphe
Une base graphe représente des entités sous forme de nœuds et les relations sous forme d'arêtes. Ici, un nœud peut être un service, une base de données, une personne, une équipe, une demande de fusion ou un incident. Les relations décrivent, par exemple, qu'un service appelle un autre, que telle équipe en est responsable, ou qu'une modification de code a eu un impact.
Ce format colle bien aux questions d'astreinte, parce qu'elles reviennent souvent à chercher des chemins : « quels composants dépendent de ce service ? », « qui possède ce composant ? », « quels changements récents sont liés ? ». Dans un modèle relationnel classique, ce genre de parcours peut vite demander des requêtes récursives et des itérations. Ici, en Cypher (avec FalkorDB), ces parcours s'expriment comme des chemins dans le graphe.
Les relations encodent le contexte opérationnel
Blast Radius rassemble plusieurs familles de données :
- La topologie : services, bases de données et sujets Kafka, reliés via des dépendances (
CALLS,READS_WRITES,PUBLISHES,CONSUMES). - Les usages : composants liés à des parcours utilisateurs qu'ils alimentent (paiement, panier, etc.).
- Les responsabilités : personnes dans les équipes, équipes propriétaires des composants, rotations d'astreinte.
- Les changements et la documentation : demandes de fusion, décisions d'architecture, procédures et documents associés.
- La mémoire des incidents : alertes, causes racines, composants touchés, actions de résolution et enseignements.
- Le fonctionnement des agents : exécutions, étapes, tâches et éléments de preuve associés aux conclusions.
Chaque organisation a son propre graphe, identifié par un identifiant de tenant. L'idée est d'éviter de mélanger les contextes entre entreprises. Mais ça ne remplace pas une analyse de sécurité complète : droits d'accès, conservation des données et règles de cloisonnement doivent aussi être évalués dans l'environnement de déploiement.
La requête cherche un point commun, pas une explication « magique »
Pour remonter à une cause candidate, l'investigateur part des composants en alerte et parcourt leurs dépendances. Il cherche les composants qui se retrouvent dans plusieurs chemins, puis ajoute des indices : le candidat est-il aussi en alerte ? Ses dépendances alertent-elles elles-mêmes ? A-t-il été modifié récemment ?
La logique se déroule ainsi :
- Parcourir jusqu'à six relations depuis chaque composant en alerte.
- Compter combien de composants en alerte dépendent de chaque candidat.
- Retenir les candidats dont les dépendances sont elles-mêmes en alerte.
- Chercher les demandes de fusion récentes qui touchent ces composants.
- Classer les pistes selon leur capacité à expliquer l'ensemble des symptômes.
La profondeur maximale est volontairement limitée : moins de recherche, moins de bruit. Le parcours commence à zéro saut, ce qui permet aussi de proposer un composant en alerte comme cause possible de sa propre défaillance.
Le classement aide à prioriser, mais il ne constitue pas une preuve causale. Une dépendance commune peut être un indice fort sans être la cause réelle. Dans tous les cas, le résultat doit rester une hypothèse, assortie d'éléments vérifiables.
Comment les agents enquêtent et se coordonnent
Le système évite de confier toute la chaîne à un seul agent. C'est important : classer des alertes, enquêter sur des dépendances, rédiger un incident, répondre à une question d'architecture... ce sont des tâches différentes.
Quatre rôles complémentaires
- Triage : regroupe les alertes en incidents et estime la gravité. Ici, cette étape s'appuie sur la logique du graphe, pas sur un modèle de langage. Résultat : c'est plus rapide et ça consomme moins (pas d'appel à un fournisseur d'IA).
- Investigation : examine dépendances, changements et incidents similaires, puis propose une cause et des éléments pour justifier.
- Documentation : rédige le compte rendu et enregistre les enseignements après validation humaine.
- Connaissance de l'entreprise : répond aux questions sur dépendances, décisions de conception et responsabilités.
Les agents ne s'appellent pas « directement » entre eux. Ils se passent du travail par des nœuds Task dans le graphe. Le triage crée une tâche d'investigation ; un agent disponible la prend en charge et l'enregistre comme prise. Ensuite, une autre tâche peut être transmise à l'agent chargé de la documentation.
Ce découpage rend le travail visible et repris en cas de coupure. Si un processus s'arrête, la tâche reste enregistrée et un autre agent peut reprendre. Selon le projet, une écriture dans FalkorDB est appliquée de façon à réclamer une tâche via une opération unique, plutôt que de laisser deux agents la prendre en même temps.
Des preuves reliées aux conclusions
En exploitation, une décision utile doit pouvoir être relue. Dans Blast Radius, une conclusion peut être reliée par une arête SUPPORTED_BY aux éléments qui la justifient. Ce n'est donc pas seulement « la demande de fusion semble suspecte » : la conclusion pointe vers la demande de fusion correspondante dans le graphe.
Les étapes d'un agent enregistrent aussi les nœuds consultés. On peut ensuite retrouver des incidents où l'agent a inspecté tel composant ou telle modification. Les états des agents, les transferts de tâches et les preuves font partie de la même structure que les données d'exploitation.
C'est un choix d'architecture pragmatique : un journal séparé pourrait suffire, mais il faudrait alors maintenir la correspondance entre le journal, les données et les décisions. En centralisant dans le graphe, certaines requêtes deviennent plus simples et la traçabilité s'améliore. En contrepartie, on concentre davantage d'informations sensibles au même endroit : la gouvernance et les contrôles d'accès deviennent incontournables.
Autre détail : les dates sont stockées en format numérique, puis présentées au modèle comme « il y a deux heures ». Les petits modèles testés dans le projet géraient mal certains calculs sur les horodatages bruts. Le format du contexte transmis au modèle fait donc partie de la fiabilité, au même titre que le modèle lui-même.
Fiabilité, résultats et limites de l'expérience
Même avec les bons outils, un agent peut se tromper. Lors des premiers essais, l'investigateur de Blast Radius trouvait parfois une piste pertinente... puis basculait vers une autre conclusion - souvent celle qui produisait le plus d'alertes.
Le projet ajoute donc une vérification déterministe : quand l'agent propose une cause racine, le graphe recalcule la couverture des alertes. Si un autre composant explique mieux les symptômes, l'agent reçoit ces chiffres et doit reconsidérer sa réponse. Après un rejet, sa deuxième proposition devient la réponse retenue. Le graphe joue ainsi le rôle de contre-avis, sans « droit de veto » absolu : il peut manquer des informations qu'un modèle ou un opérateur possède.
Mémoire des incidents passés
Après résolution, un agent rédige un compte rendu et enregistre une leçon, reliée à la cause et à la correction. Lors d'un incident ultérieur, l'investigateur cherche des cas similaires en combinant deux signaux : similarité textuelle des incidents et structure dans le graphe.
La recherche vectorielle retrouve des descriptions proches, mais formulations similaires ne garantissent pas des causes similaires. « Erreurs de paiement » et « latence du paiement » partagent peut-être le vocabulaire, sans désigner le même problème. Le classement ajoute donc des critères plus concrets : cause racine commune et recouvrement des services touchés.
Les vecteurs sont calculés localement avec bge-small-en-v1.5 via FastEmbed, d'après la description du projet. L'objectif est d'éviter de solliciter un service externe pour cette étape et de réduire la dépendance aux quotas d'un fournisseur. Attention toutefois : les modèles de langage peuvent toujours être appelés via des services tiers.
Les quotas sont un scénario normal, pas une exception
Pour fonctionner avec des offres gratuites, le système prévoit une chaîne de repli : Groq en premier, puis d'autres fournisseurs configurés, et enfin un modèle local avec Ollama. Les erreurs sont catégorisées (quota atteint, clé invalide, modèle indisponible, fournisseur en panne), et chaque modèle passe en « refroidissement » avant un nouvel appel.
Les réponses du modèle et les résultats des outils sont sauvegardés sous forme d'étapes reliées. Si tous les fournisseurs deviennent indisponibles, l'exécution est mise en pause ; elle reprend ensuite à partir de l'état enregistré, sans tout rejouer depuis le début.
Les essais ont aussi mis en évidence un défaut assez concret : après une longue pause, un agent pouvait continuer à appeler des outils jusqu'à épuiser son budget, sans produire de réponse finale. Le correctif limite alors les options proposées au modèle une fois le budget atteint : il ne peut plus lancer une nouvelle enquête et doit résumer ce qu'il a déjà trouvé.
Des résultats intéressants, mais sur un périmètre limité
L'évaluation utilise les huit scénarios de panne du jeu de démonstration OpenTelemetry. Chaque scénario est injecté dans un graphe neuf, puis l'agent d'investigation est comparé à une cause connue. Le test est ensuite répété après résolution pour vérifier l'usage de la mémoire.
| Mesure | Première occurrence | Même panne rejouée |
|---|---|---|
| Cause racine correcte | 8 sur 8 | 8 sur 8 |
| Incident appris cité | - | 7 sur 8 |
| Appels au modèle en moyenne | 5,6 | 5,0 |
| Requêtes au graphe en moyenne | 4,5 | 4,8 |
Pendant l'évaluation, les quotas ont provoqué 24 bascules vers un autre modèle et 34 mises en pause complètes. Les exécutions mises en pause ont repris depuis leur dernier point de sauvegarde et sont allées jusqu'au bout.
Ces chiffres indiquent un test utile, pas une garantie pour la production. Huit pannes simulées sur une topologie maîtrisée ne couvrent pas toutes les situations réelles : défaillances partielles, causes multiples, données de dépendance incomplètes, changements simultanés, erreurs de configuration. La prochaine étape raisonnable n'est pas d'affirmer que l'IA « résout les incidents », mais de mesurer son comportement sur des données plus représentatives, avec une validation humaine.
Ce que ce cas d'usage change pour les équipes
La leçon principale n'est pas « remplacer l'observabilité » ni « automatiser tout de suite ». Elle est plus précise : un agent devient utile quand il a un contexte opérationnel structuré, des outils limités et testables, et un mécanisme qui confronte ses conclusions à des données.
Blast Radius donne au modèle des requêtes de graphe nommées et pré-écrites, plutôt que de le laisser générer librement du Cypher. Cette contrainte réduit la surface d'action : vous pouvez tester les requêtes, comprendre leur coût et contrôler ce que l'agent a le droit de consulter. L'interface peut aussi afficher ce qui a été utilisé à chaque étape.
Brancher des données réelles sans deviner
Pour alimenter un graphe à partir d'un dépôt GitHub public, le projet analyse les fichiers de composition pour trouver des services et des dépendances, y compris des noms d'hôtes présents dans des variables d'environnement. Les fichiers CODEOWNERS servent à identifier les responsables ; les demandes de fusion relient les changements aux composants selon les chemins des fichiers.
Sur le dépôt de démonstration OpenTelemetry, l'import a trouvé 26 composants et 43 dépendances (selon l'auteur). Les identifiants GitHub sont conservés sous forme de pseudonymes stables par défaut. La pseudonymisation réduit l'exposition directe des noms, mais elle ne rend pas les données anonymes « par magie » : d'autres informations peuvent toujours permettre de retrouver des personnes.
Les alertes peuvent arriver via un webhook compatible avec Alertmanager (utilisé notamment par Grafana). Les libellés comme service, app ou le nom d'un pod sont rapprochés des composants connus. Si aucun rapprochement fiable n'est possible, le système le signale au lieu d'inventer une correspondance. En pratique, cette règle compte : « composant non identifié » est moins spectaculaire, mais c'est souvent plus sûr qu'un diagnostic basé sur une association hasardeuse.
Encadrer les actions et les données
Le système peut créer un ticket GitHub contenant la cause présumée, les preuves et une correction recommandée. Le projet prévoit un jeton limité à un dépôt et à une permission spécifique (créer des tickets). Il peut aussi envoyer des messages dans Slack ou Discord quand une cause est identifiée ou qu'un incident est résolu. Des identifiants d'action fixes par incident évitent de créer plusieurs tickets ou d'envoyer plusieurs fois la même notification lors d'une reprise.
Pour une organisation en France ou en Europe, il faut aussi couvrir les obligations liées à la protection des données. Les historiques d'incidents peuvent contenir des noms, des identifiants, des extraits de journaux ou des informations sur les utilisateurs. Avant de brancher ces données à un modèle hébergé, il faut préciser ce qui est transmis, à quel fournisseur, pour quelle durée et avec quelles garanties contractuelles. Le RGPD ne se résume pas à choisir une option de pseudonymisation : il faut documenter les traitements, limiter les données, et vérifier les accès.
Enfin, il faut distinguer clairement recommandation et action. Ouvrir un ticket ou notifier une équipe ne comporte pas le même risque que modifier un paramètre de production. Le projet envisage des corrections approuvées par un humain à terme (par exemple retour arrière d'une version ou modification d'un indicateur de fonctionnalité). C'est une progression logique : d'abord observation et assistance, puis mesure de la qualité, puis uniquement des actions réversibles et contrôlées.
Conclusion
Les agents d'astreinte deviennent intéressants non pas parce qu'ils « comprennent » les incidents, mais parce qu'ils peuvent parcourir un contexte exploitable, conserver les preuves et reprendre un travail interrompu. Ici, le graphe aide à structurer les dépendances, les responsabilités, les changements et la mémoire. Les contrôles déterministes, les tâches récupérables et les limites d'accès réduisent certains risques - sans supprimer la nécessité de vérifier les résultats.
Pour une équipe, le meilleur point de départ est un test circonscrit : quelques services, des dépendances connues, des alertes historiques, et un mode sans action automatique en production. Mesurez les causes correctement identifiées, les fausses pistes, le temps gagné et le coût opérationnel. Ensuite seulement, décidez quelles actions méritent d'être automatisées.
Le code, les requêtes et les détails de l'évaluation sont disponibles dans le dépôt Blast Radius sur GitHub. Pour comprendre le contexte de conception, lisez aussi l'article source.