MCP ne remplace pas une couche d’analytics

Connecter une intelligence artificielle à Jira ou Confluence donne rapidement une impression de puissance. L’agent retrouve un ticket, résume une page, rapproche quelques éléments et peut parfois agir dans l’outil. Cette capacité est utile. Elle ne transforme pourtant pas automatiquement les données de l’entreprise en un système d’analyse fiable.

Les cas d’usage que nous traitons chez Ovyka ne peuvent pas tous être documentés publiquement. Leur leçon d’architecture, elle, peut l’être : dès qu’une question porte sur des dizaines, des centaines ou des milliers d’éléments, un agent générique relié par MCP ne suffit généralement plus. Il faut organiser le travail entre recherche, préparation des données, calcul et interprétation.

Une connexion n’est pas un modèle de données

MCP standardise la manière dont une IA découvre et appelle des outils. La nuance est importante : le protocole ne crée pas lui-même les fonctions dont le système a besoin. Il rend disponibles celles que le serveur a réellement implémentées et que l’utilisateur est autorisé à appeler.

Le serveur Atlassian Rovo MCP (s’ouvre dans un nouvel onglet) (opens in a new tab) illustre bien cette distinction. Il propose notamment la lecture d’un ticket, des recherches JQL et CQL, une recherche en langage naturel ainsi que des outils de contexte fondés sur Teamwork Graph. Certains de ces outils peuvent rapprocher des objets liés entre plusieurs produits. Ce sont des capacités plus riches qu’un simple accès fiche par fiche, mais elles ne constituent pas pour autant une couche d’analytics métier prête à répondre à n’importe quelle question.

MCP est donc un excellent contrat d’accès. La qualité de la réponse dépend toujours des outils exposés derrière ce contrat, de leurs limites, des permissions et de la forme des données qu’ils renvoient.

Retrouver et agréger sont deux opérations différentes

Une recherche vise à retrouver les éléments les plus pertinents pour une demande. Elle convient très bien à des questions comme :

quel ticket décrit cet incident ?
quelle page explique cette décision ?
quels éléments récents parlent d’un même sujet ?
peux-tu résumer ce dossier et préparer une action ?

L’analytics répond à une autre famille de questions :

comment un indicateur évolue-t-il sur plusieurs périodes ?
quelle proportion d’éléments répond à plusieurs critères combinés ?
comment comparer des équipes dont les statuts et les pratiques diffèrent ?
quelles corrélations résistent à un contrôle sur l’ensemble du périmètre ?

Pour répondre sérieusement, il faut souvent lire un ensemble exhaustif, gérer la pagination, normaliser des champs, rapprocher des référentiels, traiter les valeurs absentes, appliquer des règles de calcul puis conserver la trace du résultat. Demander directement au modèle de lire une masse de tickets bruts et de « faire les comptes » mélange toutes ces responsabilités.

Le problème n’est pas que l’IA serait incapable de raisonner. Le problème est qu’un modèle de langage n’est ni une base analytique, ni un moteur de calcul déterministe. Son contexte est limité, la sélection des éléments peut introduire un biais et une même notion peut être codée différemment selon les projets. Sur un petit échantillon, la réponse peut sembler convaincante. À l’échelle d’un portefeuille, cette apparence ne suffit plus.

Un index améliore la recherche, pas la définition des indicateurs

La recherche Rovo (s’ouvre dans un nouvel onglet) (opens in a new tab) s’appuie sur les contenus accessibles à l’utilisateur pour faire remonter des résultats pertinents depuis Jira, Confluence et d’autres sources connectées. Un index de ce type est essentiel : sans lui, retrouver l’information utile dans un grand corpus devient lent et imprécis.

Mais un index de recherche répond d’abord à la question « quels contenus ressemblent le plus à cette demande ? ». Une couche analytique doit répondre à « quelles lignes entrent exactement dans ce calcul, selon quelle définition, à quelle date et avec quel résultat reproductible ? ».

Les deux approches peuvent se compléter. Elles ne sont pas interchangeables. Un bon index fournit à l’IA les documents ou objets pertinents. Une préparation analytique fournit des mesures, des dimensions et des agrégats explicites. Le modèle peut ensuite expliquer le résultat, relever une anomalie ou aider à décider, sans avoir à reconstruire lui-même toute la donnée source.

Préparer une donnée réellement exploitable par l’IA

Une architecture robuste sépare au minimum cinq responsabilités.

Accéder aux sources. Jira, Confluence et les autres outils restent les systèmes de référence. Les permissions doivent être conservées et les appels limités au périmètre nécessaire.
Extraire les bons objets. MCP, JQL, CQL ou des API spécialisées servent à rechercher, lire et déclencher les opérations disponibles.
Préparer la donnée. Les statuts, dates, identifiants et relations sont normalisés. Les règles métier sont appliquées avant l’appel au modèle.
Calculer de manière déterministe. Les volumes, ratios, tendances et contrôles sont produits par du code ou un moteur analytique qui peut rejouer exactement le même calcul.
Interpréter et agir. L’IA reçoit les résultats utiles, leurs définitions et les éléments de preuve nécessaires. Elle peut alors synthétiser, expliquer, comparer ou proposer une action.

Cette séparation ne rend pas le système plus lourd par principe. Elle évite surtout d’envoyer au modèle des milliers d’objets alors qu’un tableau agrégé, quelques exceptions et les bonnes sources suffisent. Elle améliore également l’auditabilité : on peut distinguer ce qui vient des données, ce qui vient d’une règle et ce qui relève de l’interprétation.

Les agents avancés sont des systèmes, pas de longs prompts

Chez Ovyka, nous travaillons sur des automates et des architectures d’agents capables d’aller au-delà d’un agent générique relié à quelques outils. L’enjeu n’est pas de multiplier les agents pour rendre le dispositif spectaculaire. Il est de donner à chaque composant une responsabilité claire.

Un orchestrateur peut qualifier la demande et choisir le bon parcours. Un outil de recherche retrouve les sources. Un traitement déterministe prépare un agrégat. Un agent spécialisé analyse les exceptions. Un autre contrôle la cohérence ou prépare une restitution adaptée au destinataire. Les actions sensibles restent soumises aux permissions et, lorsque le contexte l’exige, à une validation humaine.

Cette approche permet aussi de reconnaître qu’une question n’est pas encore traitable. Si les équipes n’emploient pas les mêmes définitions, si une donnée décisive n’est pas historisée ou si l’accès n’est pas suffisamment complet, l’agent doit le signaler. Inventer une précision à partir d’un corpus incomplet serait plus rapide, mais inutile.

Pour approfondir la conception de ces systèmes, Ovyka présente ses approches autour des architectures IA, automatisations et agents autonomes (s’ouvre dans un nouvel onglet) (opens in a new tab) ainsi que des cas d’usage Atlassian AI et Rovo (s’ouvre dans un nouvel onglet) (opens in a new tab).

Choisir l’architecture à partir de la question

Toutes les demandes ne nécessitent pas une plateforme de données dédiée. Trois niveaux couvrent déjà beaucoup de situations.

Recherche directe. Pour retrouver une information, résumer quelques objets identifiés ou créer une action, les outils MCP natifs peuvent suffire. C’est le chemin le plus court et souvent le meilleur.

Recherche suivie d’un calcul. Si la question porte sur un périmètre défini et un calcul simple, l’agent peut construire une requête, laisser un traitement déterministe parcourir tous les résultats, puis commenter l’agrégat produit.

Donnée préparée et agents spécialisés. Pour des analyses récurrentes, multi-sources ou à fort enjeu, il devient pertinent de normaliser et d’indexer la donnée, de pré-calculer certains indicateurs et d’orchestrer plusieurs composants spécialisés.

Avant de choisir, je pose cinq questions :

Cherche-t-on un contenu pertinent ou un résultat exhaustif ?
Le résultat doit-il être reproductible et contrôlable ?
Les champs ont-ils la même signification dans tout le périmètre ?
Quelle fraîcheur et quel historique sont réellement nécessaires ?
Quelles preuves faut-il présenter avec la réponse ?

Ces questions ressemblent à celles que l’on devrait poser avant une migration. Dans mes projets, le travail sur les plateformes montre régulièrement que déplacer ou connecter les données ne suffit pas. Comme je l’expliquais dans Une migration d’outil vaut par la visibilité qu’elle rend possible, la valeur apparaît lorsque les relations et les usages redeviennent lisibles.

Le bon partage des responsabilités

MCP ouvre une voie propre et standardisée entre l’IA et les outils de travail. Les moteurs de recherche et les graphes de connaissance améliorent fortement l’accès au contexte. Une couche de données préparée rend les analyses massives fiables. Les agents spécialisés transforment enfin ces résultats en explications et en actions utiles.

Il ne faut pas demander à un seul composant de jouer tous ces rôles. Une IA d’entreprise devient réellement intéressante lorsque l’architecture sait où chercher, quoi calculer, ce qu’elle peut affirmer et quand elle doit demander une validation.