HolmesGPT : l'agent SRE qui interroge vos données d'observabilité, et ce qu'il coûte vraiment
SRE Agent - CNCF Sandbox Project
En bref
- De quoi s’agit-il ?
- HolmesGPT est un agent Python sous licence Apache-2.0, projet sandbox de la CNCF, qui mène une boucle agentique sur Prometheus, Kubernetes, Datadog ou Jira pour proposer une cause racine. Le mécanisme est documenté, l'exploitation l'est moins.
- À qui s’adresse-t-il ?
- HolmesGPT convient aux équipes SRE qui possèdent déjà un socle d'observabilité interrogeable par API et qui acceptent que chaque investigation consomme des jetons sur des données de production. Il ne convient pas à celles qui cherchent une détection déterministe à seuils fixes, ni à celles dont les données ne sortent pas du réseau.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : personne ne déclenche l'investigation
La plupart des incidents ne sont pas difficiles à diagnostiquer une fois qu'un humain a ouvert le bon tableau de bord. Le coût réel se situe en amont : il faut remarquer l'anomalie, décider qu'elle mérite une investigation, puis rassembler manuellement des données dispersées entre Prometheus, les logs Kubernetes et un ticket Jira. HolmesGPT vise cette étape. Le README le formule sans détour : la plupart des agents savent dépanner, mais attendent qu'un humain remarque le problème. Le projet s'adresse donc aux équipes SRE et plateforme qui ont déjà des sources d'observabilité interrogeables par API, et qui veulent automatiser la collecte et la synthèse. Il n'est pas réservé à Kubernetes : le README indique explicitement qu'il fonctionne avec des VM, du bare metal, des services cloud ou des conteneurs.
La boucle agentique et le problème des fenêtres de contexte
Le mécanisme central est une boucle agentique : le modèle interroge successivement des sources de données live via des outils, puis formule une cause racine. La difficulté n'est pas le raisonnement, c'est le volume. Une requête PromQL mal cadrée peut renvoyer des centaines de milliers de séries. Le README annonce trois réponses à ce problème : un filtrage côté serveur, une traversée d'arborescence JSON, et des transformateurs de sortie d'outil qui gardent les charges volumineuses hors de la fenêtre de contexte. Il mentionne aussi des limites de mémoire par outil, la diffusion en flux des gros résultats vers le disque et un budget de sortie automatique pour éviter les OOM. Ce sont des choix d'ingénierie précis, et ils indiquent où se situe la fragilité : si un transformateur ne réduit pas assez une charge, l'agent perd du contexte ou échoue. C'est aussi la partie la moins documentée publiquement. Le README énumère les propriétés, pas les seuils, ni la taille maximale d'un résultat avant mise sur disque.
Toolsets : un catalogue large, une surface de confiance large
HolmesGPT connecte ses sources via des toolsets. Le tableau du README en liste une longue série : AKS, Atlassian Rovo, ArgoCD, AWS via MCP, Azure via MCP, Confluence, Coralogix, Crossplane, Datadog, Docker, Elasticsearch et OpenSearch, GCP, GitHub, GitLab, et la liste continue. Plusieurs passent par MCP, le protocole de contexte de modèle. L'intérêt est évident : une équipe qui utilise déjà Datadog n'a pas à écrire de code d'intégration. Le revers l'est tout autant. Chaque toolset est un chemin par lequel l'agent lit des données de production, et l'agent décide lui-même quels outils appeler. Accorder à un agent LLM un accès en lecture à Jira, Confluence et GitHub élargit la surface au-delà du seul diagnostic. Le README mentionne également des intégrations d'alerte bidirectionnelles : récupérer des alertes depuis AlertManager, PagerDuty, OpsGenie ou Jira, et réécrire les conclusions. Cette écriture mérite une revue séparée de la lecture.
Installation et mode opérateur
Le README renvoie à une section Installation et à la documentation sur holmesgpt.dev, sans fournir dans le texte fourni la commande exacte d'installation ni les clés de configuration. Je ne peux donc pas les citer sans les inventer. Ce qui est documenté, en revanche, c'est le mode opérateur. HolmesGPT tourne en arrière-plan en continu, détecte des problèmes et envoie un message Slack avec le correctif. L'opérateur s'exécute dans Kubernetes, mais les contrôles de santé peuvent interroger n'importe quelle source connectée, y compris des VM, des services cloud ou des bases de données. Deux usages sont décrits : la vérification de déploiement, où un contrôle de santé accompagne la nouvelle version applicative, et les contrôles planifiés, qui surveillent un service et détectent les régressions. Le point à retenir est que le mode opérateur transforme un outil d'investigation à la demande en processus permanent. La consommation de jetons devient alors continue, pas ponctuelle.
Ce que le projet ne dit pas
Trois zones restent floues dans le matériel fourni. D'abord le coût : aucun ordre de grandeur du nombre de jetons par investigation n'apparaît, alors que la boucle agentique peut enchaîner plusieurs appels d'outils. Ensuite la sécurité : envoyer des logs de production, des événements RDS ou des pages Confluence privées à un fournisseur LLM externe est une décision d'architecture, et le README ne propose pas de garde-fou visible sur ce point. Enfin la qualité du diagnostic : aucune mesure de précision n'est publiée dans le matériel disponible. Un agent qui produit une cause racine plausible mais fausse coûte plus cher qu'une absence de réponse, parce qu'il oriente l'incident dans la mauvaise direction. Ces trois points ne disqualifient pas le projet, mais ils déterminent s'il est déployable chez vous.
Face à un runbook automatisé
L'alternative la plus courante n'est pas un autre agent LLM, c'est un runbook automatisé : une suite de requêtes fixes déclenchées par une alerte, avec des seuils écrits à l'avance. La différence d'approche est nette. Un runbook est déterministe, son coût est prévisible et son périmètre est connu à l'avance. Il ne s'adapte pas à un incident inédit, et c'est précisément là que HolmesGPT intervient : quand la cause n'est pas dans la liste des causes anticipées. Le choix se fait donc sur la nature de vos incidents. Si 90 pour cent de vos alertes correspondent à des scénarios déjà écrits, un runbook coûtera moins cher et sera plus fiable. Si vous passez du temps à explorer des pistes nouvelles à chaque incident, la boucle agentique a un intérêt réel.
Licence, maintenance et coût de mise à jour
Le projet est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et de l'avis de licence. Je ne donne pas de conseil juridique : faites relire l'usage prévu si vous redistribuez le logiciel. Sur le rythme de publication, les versions indiquées dans le matériel montrent une cadence soutenue, avec des versions alpha intermédiaires entre les versions stables. Une cadence élevée signifie que les interfaces des toolsets et les clés de configuration peuvent bouger entre deux versions mineures. Pour une équipe qui épingle une version, cela implique de tester la montée de version avant de la déployer, en particulier si vous avez écrit un toolset personnalisé. Le README documente la création de toolsets personnalisés et de toolsets API REST, ce qui est le principal point d'extension, et donc le principal point de rupture lors des mises à jour.
Conclusion éditoriale
HolmesGPT convient aux équipes SRE qui possèdent déjà un socle d'observabilité interrogeable par API et qui acceptent que chaque investigation consomme des jetons sur des données de production. Il ne convient pas à celles qui cherchent une détection déterministe à seuils fixes, ni à celles dont les données ne sortent pas du réseau. Avant tout déploiement, vérifiez deux choses concrètement : la façon dont votre fournisseur LLM traite les charges envoyées, et le comportement du budget de sortie par outil sur vos requêtes les plus larges.
Notes de la communauté