Saviez-vous qu'une IA générative pouvais utiliser de manière sécurisée et contrôlée vos applications grâce à un serveur MCP ? on vous explique comment on a utilisé le serveur MCP Atlassian pour utiliser Claude Desktop à interagir avec notre outil de gestion de projet préféré : JIRA
La Model Context Protocol (MCP) est une norme ouverte conçue pour faciliter l’intégration des modèles d’IA avec diverses sources de données et outils. En proposant une interface standardisée, MCP permet des connexions fluides et sécurisées, donnant aux systèmes d’IA un accès efficace aux informations contextuelles. Elle simplifie le processus de développement et facilite la création d’applications d’IA robustes et interconnectées.
Le serveur MCP agit comme un traducteur entre l’IA et vos outils : il fournit une liste claire des actions possibles (les tools) et les informations nécessaires pour chaque action, afin que l’IA sache exactement comment dialoguer avec vos APIs métiers.
Exemple
Tool: jira_add_comment
Description : Add a comment to a Jira issue.
Pour ceux qui veulent en savoir plus, je vous invite à lire la note wikipédia qui explique plus en détail le sujet.
Pour notre prototype nous avons utilisé le serveur MCP official d'Atlassian et suivi le guide afin de connecter notre tenant Jira Cloud avec notre serveur MCP monté sur Docker. Pour les techos, voici le lien Github de mcp-atlassian.
Pour les plus pressés, il existe même un connecteur intégré dans Docker Desktop sur le MCP Toolkit ;)
Mais comme on est des puristes, voici la commande à lancer :
1docker run --rm -i \
2-e JIRA_URL="https://votre-instance.atlassian.net" \
3-e JIRA_USERNAME="vous@votre-entreprise.com" \
4-e JIRA_API_TOKEN="token_API_Jira" \
5ghcr.io/sooperset/mcp-atlassian:latestRésultat de la création du container :
On voulait initialement faire la démonstration avec Mistral et un script Python, mais pour pouvoir tester facilement notre agent conversationnel, on s'est orienté sur une solution technique permettant d'interagir dans une interface graphique.
Alors autant utiliser la solution Claude Desktop qui permet d'interagir avec un client intégré et un service MCP local. L'éditeur Anthropic étant un des premiers à introduire ce protocole, on peut s'attendre à de meilleurs résultats.
Présupposition vérifiée, pour cela, rien de plus simple :
Si MCP_DOCKER n'est pas visible, assurez-vous que votre client est bien connecté depuis Docker Desktop
Pour utiliser votre service MCP, il faut s'assurer que votre prompt utilise bien le connecteur.
Et c'est là qu'on commence à s'amuser :)
Pour ces expérimentations, j'utilise Claude Sonnet 4, mon serveur MCP local via Docker et j'ai désactivé la recherche web.
Sur ce premier test, on interroge l'IA sur le fonctionnement d'une fonctionnalité qui est normalement spécifiée dans un ticket JIRA.
Dans mon cas d'exemple, je spécifie dans mon prompt : le projet jira et la fonctionnalité souhaitée. On voit les étapes de réflexions de l'IA pour répondre à notre requête :
🎯 Contexte et objectif
Public cible : Utilisateurs PRO uniquement
Utilisation : Faciliter les grosses commandes et permettre l'ajout rapide de produits commandés régulièrement
Plateforme : PC uniquement (pas disponible sur mobile)
📊 Structure du fichier requis
Colonnes obligatoires :
Code VM : Référence produit VM Matériaux
Quantité : Nombre d'unités à commander
Colonnes optionnelles :
Référence fournisseur
Code EAN
Mesures de conversion (m², ml, m³, etc.) pour calculer automatiquement les quantités
🔧 Fonctionnement technique
1. Interface dans le panier
Un nouvel encart apparaît dans le panier sur PC
Deux fonctionnalités principales :
Téléchargement d'un fichier modèle
Import d'un fichier personnalisé
2. Processus de validation
Le système vérifie :
La conformité du format (XLS/CSV)
La présence des colonnes obligatoires
La validité des codes VM
La disponibilité des produits dans le point de vente
Le statut d'activation des produits
3. Gestion des quantités
Support des unités de mesure (m², ml, m³)
Calcul automatique des quantités selon les conversions
⚡ Messages de retour utilisateur
✅ Succès
"Votre fichier a bien été pris en compte, les produits ont été ajoutés à votre panier."
❌ Erreurs possibles
Fichier non conforme :"Votre fichier contient des erreurs."
Produits indisponibles :"Certains articles ne sont plus disponibles. Seuls les produits disponibles ont été ajoutés à votre panier."
🎨 Interface utilisateur
Desktop : Encart intégré dans la page panier avec zones de téléchargement et d'import
Mobile : Fonctionnalité non disponible
Messages d'erreur : Affichage contextuel avec maquettes spécifiques
📈 Suivi analytique
Événement GA4 configuré pour tracker l'utilisation de cette fonctionnalité
🚧 Statut actuel
Statut : En Backlog (pas encore développé)
Version prévue : Release 1.2.9
Priorité : Urgente
Estimation : 2 jours de développement
Cette fonctionnalité s'inspire du modèle Oro Commerce et vise à améliorer l'expérience des clients professionnels pour leurs commandes en volume.
Clairement, on ne s'attendait pas à ce niveau de détail, il a réussi à convenir les notions de "règles de gestion" et "tests d'acceptance" pour formuler les choses de manière synthétique et par thématique.
Au-delà du mode de recherche intuitif qu'offre l'approche conversationnel, il est intéressant de constater une complémentarité dans la restitution de l'information entre le ticket original et le rendu généré par l'IA.
Dans ce cas d'exemple, je souhaite connaître les tickets urgents ou importants à traiter. La liste des tickets assignés étant visibles sur l'accueil Jira, j'attends de lui qu'il me communique une information complémentaire.
Dans les projets Jira dans lequel j’interviens en tant que personne assignée, peux-tu me dire quels sont les 3 tickets les plus urgents et importants à traiter ?
La recherche est assez rapide et demande que 2 requêtes vers JIRA / serveur MCP.
Dans sa restitution, je retrouve en effet mes tickets urgents, avec notamment ceux qui ont une interaction avec le client en premier, ce qui est pertinent et correspond à l'interface JIRA.
Ce qui est pertinent, c'est qu'il a rajouté un 4ème ticket à surveiller qu'il estime intéressant. Il s'avère que sa synthèse et le ticket remonté apporte une information que je n'avais pas vu sur mon Dashboard Jira. Ce ticket avait été traité mais le statut n'avait pas été mis à jour.
On peut décliner cette recherche en ciblant, par exemple, les tickets comportant un commentaire mentionnant un besoin d'analyse, de livrable ou d'avis d'expert.
Pour des raisons de confidentialité, je ne communiquerai pas de screenshot ou résultat de cette expérimentation.
J'ai testé l'évaluation d'une équipe technique quant à sa capacité de répondre aux tickets : vitesse, qualité, pertinence des échanges, historique d'affectation, etc.
Points positifs
Au-delà des statistiques remontés, il a pu m'indiquer qui fait preuve de plus de polyvalence, quel développeur est plus à même de résoudre un sujet complexe, qui est le plus véloce pour une typologie de tâche, etc. Ce qui m'apporte une vision enrichissante sur le comportement de mon équipe et me permet d'organiser différemment l'affectation des tâches par exemple.
J'ai même pu lui demander ce qu'il pensait de moi dans mon rôle de "Product owner sur un projet spécifique et de me donner des axes d'amélioration continue.
Points négatifs
Sans travailler finement le prompt, il n'hésitera pas à ranger les personnes dans un classement du plus rapide, plus productif, etc... ce qui ne correspond pas à notre philosophie d'évaluation du management de la performance que l'on applique dans notre agence.
Pour cette expérimentation j'ai désactivé le mode EDIT_ONLY afin de laisser l'IA créer un ticket sur notre Jira. J'ai formulé une demande assez simple, très orienté métier/technique, sans rentrer dans les détails.
Déclare un ticket Hosting pour demander la mise en place d'un service elasticsearch 8.x sous docker sur une VM de service. attribue ce ticket à Mahtieu W avec moi comme observateur. Dans le sprint Actuel sur un epic TMA
On remarque qu'il a du faire plusieurs interactions pour trouver le code projet exact ainsi que le collaborateur ciblé (9 requêtes vers JIRA) et seulement 3 requêtes pour créer le ticket, ajouter un commentaire et me rajouter en observateur. Il faut dire que j'avais mal écrit le nom du collaborateur pour voir comment il allait s'en sortir.
Dans sa restitution, il donne une URL API du ticket et non une URL vers l'interface graphique pour lire le ticket.
On remarque aucune erreur technique, le ticket correspond au besoin, il est bien affecté au sprint et au ticket parent TMA, la personne assignée est juste et je suis bien en observateur.
Toutefois il a pris de grandes libertés sur la description et les commentaires sur le sujet, cela n'est pas pertinent, verbeux et donnes des consignes au collaborateurs que je ne souhaite pas. La mise en forme laisse elle aussi à désirer.
Il facilement identifiable dans ce test qu'une meilleure qualification du contexte, via un prompt/agent demandant des questions préalables, optimisera grandement l'expérience et la qualité du ticket créé.
Cette fois-ci j'ai voulu améliorer mon prompt pour avoir un traitement plus efficace et qui correspond mieux à mon besoin sur la création d'un ticket.
Je souhaite créer un nouveau ticket dans mon projet jira HOSTING. Ce ticket demande la mise en place d'un service elasticsearch 8.x sous docker. Ce service doit être installé sur une VM de service que le responsable devra choisir selon les critères habituels (il doit comparer l'espace et ressource nécessaire en se basant sur l'ancien service en place pour point de comparaison). Ce ticket doit être attribué à Mathieu Wambre. Je souhaite être en responsable et Florent Jousseaume en observateur. Le ticket doit être traité d'ans l'épic TMA courant et intégré au sprint en cours. Je souhaite que le devops qui traite ce ticket me communique les informations de connexion, il test de connexion pour vérifier la mise en place et s'assure d'avoir bien géré la sécurité autour de l'accès au service (authentification + filtre IP dans la configuration du WAF sur les ports techniques).
Et bien malgré toutes ces précisions, Claude a du faire appel 12 fois au serveur MCP pour requêter JIRA. Il a noté qu'il existait un ticket relatant du même sujet.
Le rendu du ticket n'est guère mieux que la première fois, il a encore rajouté des informations non pertinentes et en double des éléments de qualification présent dans un système de ticket JIRA (les affectations par exemple).
J'ai fait un troisième essai en demandant dans le prompt de me poser des questions si besoin et de ne pas improviser. Hélas, le résultat et temps de réalisation de la tâche ne sont pas significativement améliorés, je reste persuadé qu'il est préférable de réaliser mon ticket directement sur l'interface Jira.
Pour être totalement transparent, ce qui devait être un test rapide de POC pour démontrer une certaine efficacité des serveurs MCP a montré que la technologie était encore jeune, et au-delà des billets d'actualités sur les failles de sécurités présentes sur ces services MCP, il n'est pas toujours aisé de faire fonctionner efficacement ce type de service comme on l'imagine.
Quelques petits écueils rencontrés :
Finalement, Claude Desktop dans sa version Pro est très efficace pour tester vos serveurs MCP et réaliser des POC d'usage avec vos équipes. On remarque toutefois une certaine lenteur d'exécution, pas très gênante lorsqu'on recherche une information sur un projet, contexte ou statistique. Cela reste plus rapide et profond qu'une recherche manuelle.
En revanche, pour la création d'un ticket, utiliser l'interface graphique avec la gestion des écrans reste plus rapide, fiable et permet de s'assurer d'enrichir les bonnes informations du premier coup.
Afin d'affiner le résultat et l'efficience de vos actions, il sera intéressant de préparer vos prompts lorsque vous faites vos demandes. Cela permet par exemple de mieux formater votre description de ticket pour de la remonté d'anomalie ou demande d'une nouvelle tâche ou bien mieux formater le retour d'une analyse d'activité.
En résumé, l’utilisation d’une IA générative couplée à un service MCP pour réaliser des tâches simples peut s’avérer décevante : la valeur ajoutée reste limitée comparée à l’ergonomie et à l’efficacité des interfaces graphiques traditionnelles. Pour séduire les utilisateurs finaux, il faudra proposer des fonctionnalités réellement différenciantes – des services que ni un assistant vocal ni un simple crawler web ne peuvent offrir aujourd’hui.
En revanche, notre retour d’expérience montre que les serveurs MCP présentent un fort potentiel dès lors qu’il s’agit de chaîner plusieurs actions complexes, notamment dans le cadre d’agents spécialisés ou de cas d’usage métier avancés. L’émergence de serveurs MCP distants devrait accélérer la standardisation de ce protocole, ouvrant la voie à une intégration plus naturelle des applications et services métiers dans les outils d’IA générative.
Au-delà de l'expérience Jira, là où ça devient encore plus intéressant, c'est de mettre à disposition plusieurs connecteurs pour réaliser des commandes parallèles selon une demande.
Dans un cas de projet R&D, nous avons pu raccorder un second serveur MCP Elasticsearch (qui possède nos logs) afin de pouvoir combiner une analyse des indicateurs applicatifs et serveur pour enrichir l'analyse de détection de bug et identifier si celui-ci a déjà été rapporté sur le projet par exemple.
Rajoutez à cela un troisième connecteur MCP vers notre GIT, en capacité de lire le code source du projet, et vous aurez peut-être un premier prototype de détection d'anomalie applicative ;)
Si vous souhaitez mettre en place votre propre serveur MCP pour vos applications métier, ou sécuriser un serveur MCP pour un usage en production, n'hésitez pas à nous contacter ;)
