J’allais connecter ChatGPT à Jira. Puis j’ai vu ce message
Quand j’ai commencé ce POC, mon premier réflexe a été assez simple : regarder si une solution existait déjà.
Et c’est bien le cas.
ChatGPT propose un plugin d'Atlassian nommé Rovo, qui n'est autre que l'agent officiel de la firme.
Sur le papier, c’était exactement ce que je cherchais.
Quelques clics, une autorisation et je pouvais commencer mes premiers tests.
Sauf qu’au moment de lancer la connexion, ChatGPT m’a affiché ce message.
Donc, si j'ai bien compris :
- Le message parle d’acteurs malveillants qui pourraient tenter d’accéder à mes données de l'une des deux applications.
- Il précise aussi que certaines informations peuvent être partagées avec l’application, comme mon adresse IP, ma localisation approximative et un résumé du contexte récent de mes échanges avec ChatGPT.
Honnêtement, cela m’a fait réfléchir.
Cela ne veut pas dire que le plugin Atlassian Rovo est dangereux.
Ce n’est pas non plus la preuve que la connexion proposée est mal sécurisée.
Mais dès que je commence à relier deux outils qui contiennent potentiellement des données sensibles, on est en droit de se poser quelques questions.
- Quelles données vont réellement circuler ?
- Quelles actions ChatGPT pourra-t-il réaliser réellement dans Jira ?
- Comment suivre les échanges entre les deux outils ?
- Que se passe-t-il si l’un des deux environnements est compromis ?
- Et surtout, comment couper rapidement la connexion si quelque chose ne se passe pas comme prévu ?
Je pouvais cliquer sur « Continuer vers Atlassian Rovo » et faire confiance au fonctionnement proposé mais pour ce POC, j'ai préféré prendre un autre chemin.
Celui d'y rajouter mon propre proxy.
Dans l'idée, ChatGPT ne communiquerait donc pas directement avec Rovo et toutes les requêtes passeront d’abord par cette une application d'ont j'ai le contrôle.
Ainsi, je pourrai décider précisément quelles actions seront autorisées, quelles données peuvent circuler et quelles demandes doivent être refusées.
Je pourrai également conserver une trace des échanges et couper la connexion depuis un point unique en cas de problème.
Soyons clairs, ajouter un proxy ne rend pas automatiquement la connexion sécurisée.
C’est même un composant supplémentaire qu’il faudra protéger.
Mais dans le cadre de ce POC, il me donne quelque chose d’essentiel : de la visibilité ce qui se trame derrière.
Avant de chercher à créer des ponts direct entre ChatGPT et Jira, je veux d’abord comprendre ce que je connecte, ce qui circule et jusqu’où je suis prêt à ouvrir la porte.
Un mini-proxy, pas une usine à gaz
À ce stade, je sais pourquoi je veux ajouter un proxy.
Il me reste maintenant à le construire.
Je ne voulais pas passer plusieurs semaines à développer une plateforme complète.
Avec quelques bons prompts dans Cursor, plusieurs ajustements et un peu de tests, j’ai obtenu un petit serveur Node.js fonctionnel (pile-poil ce qu'il faut).
Rien de spectaculaire. Et c’est très bien comme ça.
Pour commencer, ce proxy doit seulement remplir deux fonctions.
Fonction 1 : une porte d’entrée pour ChatGPT
La première fonction est d’exposer une URL MCP.
Cette URL est la porte d’entrée que je vais donner à ChatGPT.
Je ne vais pas donner celle de Rovo, mais celle de mon app proxy. L'URL qui va capter le signal d'entrée émanant de ChatGPT pour le redigirer ensuite vers l'URL du MCP de Rovo.
De son côté, le proxy recevra la demande, vérifiera qu’elle est autorisée, puis décidera s’il peut la transmettre en l'état.
Fonction 2 : voir tout ce qui passe dans le proxy
La seconde fonction est une petite interface UI de suivi des logs.
Je veux pouvoir voir tous les appels envoyés par ChatGPT, le nombre de requêtes, les fonctions demandées, les informations reçues et les réponses renvoyées par Rovo.
Dans une architecture plus ambitieuse, ces traces pourraient être envoyées dans des systèmes plus robustes et faits pour ça (ex: Kibana, Datadog ou autre). Mais ce n’est pas mon objectif pour le moment.
Pour ce POC, une petite page web (géré par la même app Node) qui se rafraichit en temps réel me suffit amplement.
Elle me permet de commencer à observer les flux sans ajouter une nouvelle couche de complexité.
Cette interface ne sera pas exposée sur Internet. Elle restera accessible uniquement en local, depuis mon ordinateur.
Il restait tout de même un problème.
Mon proxy fonctionne sur ma machine.
ChatGPT, lui, ne peut pas appeler directement une adresse locale.
Pour connecter un serveur MCP distant, il lui faut obligatoirement une adresse publique en HTTPS.
Je suis donc passé par Cloudflare Tunnel.
Le principe est assez simple.
Via simple ligne de commande, Cloudflare génère une adresse HTTPS temporaire et fait transiter tout le signal vers ma machine (un peu comme le fais Ngrok).
Je n’ai donc pas besoin de déployer immédiatement mon proxy sur un VPS.
Après avoir installé cloudflared, je tape simplement ceci pour rediriger les requêtes vers mon proxy : cloudflared tunnel --url http://127.0.0.1:8787
Et j'obtiens une jolie URL prête à l'emploi !
Cette adresse étant publique, je ne veux pas la laisser ouverte sans protection. Sans quoi, n'importe qui pourrait l'exploiter.
C'est pourquoi, j'ai ajouté une barrière à l'entrée de mon proxy, un Bearer token.
À chaque appel, mon proxy vérifie alors que le bon token est présent.
Si le token est absent ou incorrect, la requête est simplement refusée et renvoie vers une erreur 401.
Cela ne constitue pas une protection absolue en soi. En revanche, une personne qui découvrirait l’URL ne pourrait pas utiliser mon proxy sans connaître également ce token.
Le premier test est volontairement très simple
Dans un premier temps, testons la connexion.
Mon proxy dispose déjà d'une redirection vers le MCP de Rovo, mais sans configuration particulière (ça va donc planter en bout de chaîne).
Mais nous ce qu'on veut, c'est déjà voir si le signal émanant de ChatGPT est bien capté.
Je configure donc ChatGPT avec l'url Cloudflare et le Bearer Token.
Suite à quoi, je démarre une nouvelle conversation en demandant explicitement à ChatGPT d'utiliser cet MCP (pour éviter qu'il s'égare, mais à terme, je pense qu'il n'y aura plus besoin de le préciser).
Si une requête apparaît dans les logs de mon proxy, cela viendra valider la connexion.
Allez, je lance ma première demande.
Bingo !
Mon endpoint MCP fonctionne et mon proxy détecte bien toutes requêtes (qu'on pourra analyser un peu plus tard) 🙂
A ce stade, le signal est bien capté et redirigé vers le MCP de Rovo (accessible à cette adresse).
Mais comme prévu, celui-ci retourne une erreur.
Il ne me reste plus qu'à enrichir mes requêtes redirigées avec 3 données obligatoires :
- L'adresse e-mail du compte Atlassian à utiliser
- Créer un "Jeton d'API" depuis Atlassian
- Définir l'url du "site Atlassian" (le workspace en somme) sur lequel on souhaite opérer
Pour permettre à mon proxy de communiquer avec Jira, j’ai donc besoin d’un jeton API.
Mais il y a un problème.
Ce jeton est lié à un compte utilisateur Atlassian et non à un environnement.
Cela veut dire que, techniquement parlant, ce jeton donnerait des droits à tous les environnements dont on aurait personnellement accès.
Donc, si vous utilisez le même compte Atlassian chez plusieurs clients, une requête faite par ChatGPT pourrait accidentellement opérer au sein d'une mauvaise instance JIRA.
Pour moi, ce n’est pas suffisamment cloisonné.
J’ai donc créé un nouvel utilisateur Atlassian uniquement pour ce POC.
Cet utilisateur a accès à une seule instance Jira Cloud (celle que j'ai créé pour ce test) et aucun environnement client n’est accessible depuis ce compte.
C’est seulement à partir de cet utilisateur isolé que je vais créer mon jeton API.
Go !
Je me rend sur cette page cette page (accessible via Mon compte > Sécurité > Jetons API > Créer un jeton d’API avec périmètre), je démarre le process et au moment de sélectionner l'app, je choisis "Rovo MCP V2".
Il faut définir ensuite des droits (reads, write... etc.).
Dans le cadre ce POC, mon instance JIRA étant utilisée comme sandbox, j'ai donné tous les droits.
C'est ce token qui sera ajouté au proxy pour enrichir mes requêtes sortantes vers Rovo (en plus de l'url du site et de l'adresse mail de mon compte Atlassian).
Et c'est tout.
Lançons à présent le test final
Je dois vous dire que je suis content 🙂
On obtient un résultat positif.
Voyez donc.
Non seulement on obtient un résultat, mais aussi, il ne s'agit pas d'une simple restitution.
L'IA prend les devants et donne directement des pistes d'améliorations.
Conclusion : un POC validé !
Ce POC vient confirmer que l'on peut aisément installer un proxy entre les assistants grands public du marché et des services MCP proposées par de plus en plus de services SaaS.
Mais surtout, ce test permet de :
- Se positionner comme un véritable observateur entre 2 systèmes externes
- Faire du reverse ingeneering sur la mécanique des assistants IA et agents IA
- Détecter d'éventuelles anomalies/bizarreries dans les requêtes
- Confirmer que l'on peut couper tout un service à distance en cas d'attaque sans avoir à bidouiller dans ChatGPT, ni dans JIRA
- Démontrer au marché IT une nouvelle voie pour sécuriser et cloisonner d'éventuelles tentatives d'intrusions ou de détournement venant d'un des deux outils
En somme, c'est bien le genre de sujet que toute équipe informatique pourrait se poser légitimement aujourd'hui, dans un monde où les interconnexions inter-systèmes se multiplient tout en diminuant drastiquement les frictions techniques, sans que l'on puisse nécessairement rationaliser tout ça, ni mesurer l'impact en cas de problème.
Des sujets qui s'inscrivent tout à fait dans le thème de la gouvernance de l'IA. Sujet passionnant adressé par de plus en plus de DSI en France et dans le monde.
Et après ?
Ce premier POC technique étant terminé, j'irai bien faire un tour sur le terrain du pilotage.
Notamment, le pilotage par la voix qui change radicalement notre rapport aux outils et qui fera repenser totalement à nos journées "type" de chef.fe de projet.
Tout cela me paraît très excitant !
La suite, au prochain épisode 🙂
