MTS : du RAG aux agents, analyse des tickets Jira via MCP et logs

Ilya Paramoshin, ingénieur principal chez MTS Web Services, a publié sur Habr le troisième article de sa série sur l'évolution d'un assistant RAG pour le support technique. Cette fois, il décrit le passage de la recherche dans la documentation à une plateforme dotée d'un accès MCP aux logs et aux bases de données, ainsi que d'une analyse automatique des tickets Jira.

Trois articles, une série

Ce texte prolonge deux publications antérieures du même auteur sur Habr. La première portait sur l'architecture d'un assistant RAG (Retrieval-Augmented Generation, génération de réponses s'appuyant sur des documents retrouvés) pour le support technique : indexation de Confluence et de Jira, recherche hybride, génération de réponses avec citations et évaluation de la qualité de la recherche. La seconde, plus récente, racontait comment MTS Web Services a construit un agent d'IA pour l'analyse automatique des tickets.

• Auteur : Ilya Paramoshin, ingénieur principal chez MTS Web Services
• Premier article : architecture de l'assistant RAG pour le support technique (indexation de Confluence et de Jira, recherche hybride, évaluation de la qualité de la recherche)
• Deuxième article : agent d'IA pour l'analyse automatique des tickets
• Troisième article (analysé ici) : MCP, logs et le parcours d'un ticket, de sa création au commentaire

Pourquoi le RAG a-t-il eu besoin de logs et de MCP ?

Après le déploiement de l'assistant RAG, les ingénieurs de l'entreprise ont trouvé plus vite les instructions et les procédures dont ils avaient besoin. Paramoshin y voit un effet direct de la première version du système. L'investigation des incidents exigeait toutefois aussi de travailler avec les logs, les bases de données et Jira lui-même, et pas seulement avec le texte de la documentation dans Confluence. C'est pourquoi l'équipe a décidé d'étendre le système au-delà de la recherche, plutôt que de se contenter de retoucher la base de connaissances.

Comment fonctionne la nouvelle plateforme

Les ingénieurs de MTS Web Services n'ont pas réécrit le système RAG de zéro. Ils l'ont développé comme une plateforme articulée autour de trois tâches.

«

Nous n'avons pas réécrit le RAG, nous avons commencé à le développer comme une plateforme autour de trois tâches : une interface unique, l'accès aux données d'exploitation et l'automatisation de l'analyse des tickets », — Ilya Paramoshin, ingénieur principal chez MTS Web Services, dans l'article sur Habr.

La recherche reste le cœur de la plateforme, mais des services distincts se sont greffés autour : les uns pour le travail interactif de l'ingénieur pendant une investigation, les autres pour l'analyse des tickets en arrière-plan, sans intervention humaine. Des trois tâches, la première est une interface unique par laquelle l'ingénieur accède à la fois à la recherche documentaire et aux autres services. La deuxième est l'accès aux données d'exploitation (logs, bases de données, Jira lui-même), mis en œuvre, à en juger par le titre de l'article, via le protocole MCP (Model Context Protocol), un standard ouvert qui offre aux agents d'IA un accès structuré à des sources de données externes au lieu d'une intégration dédiée à chaque service.

La troisième tâche est l'automatisation de l'analyse des tickets, c'est-à-dire le transfert d'une partie du travail routinier de l'ingénieur vers des services d'arrière-plan.

Selon l'auteur, l'article examine ensuite l'architecture de la solution, les raisons pour lesquelles certains composants ont été sortis du système RAG pour devenir des services autonomes, et le parcours d'un ticket, de sa création jusqu'à un commentaire généré automatiquement dans Jira. Le texte s'intitule « La vie après le RAG : MCP, logs et analyse automatique des tickets Jira », et ce titre signale à lui seul un changement de cap : de la recherche pure dans la base de connaissances au travail sur des données d'exploitation en temps réel.

Ce que cela signifie

Le cas de MTS Web Services illustre une trajectoire typique des systèmes RAG d'entreprise : d'un chatbot ponctuel sur la documentation à une infrastructure qui réunit recherche, données d'exploitation et automatisation des opérations routinières autour des tickets de support. Les trois articles de la série sur Habr, de l'architecture de recherche à l'agent d'IA puis à l'accès MCP et aux logs, montrent comment évoluent les exigences envers les assistants d'IA d'entreprise à mesure que les ingénieurs les utilisent non seulement pour lire la documentation, mais aussi pour investiguer des incidents.