Trois façons d’amener l’IA dans Jira

Trois voies, un seul backlog

En 2026, l’IA ne manque pas. Ce qui manque, c’est de savoir où l’utiliser avec pertinence.

Si votre équipe travaille dans Jira, vous l’avez déjà senti. Atlassian a intégré Rovo directement dans sa plateforme. OpenAI et Anthropic ont ouvert des connecteurs qui permettent à ChatGPT et à Claude de lire votre backlog. Et une nouvelle génération d’applications natives Forge, dont Just, installe l’IA directement dans le panneau du ticket, en faisant de l’issue à la fois le point d’entrée et le point d’arrivée.

Trois voies. Un seul backlog. Des expériences radicalement différentes.

Le réflexe, c’est de demander laquelle est la meilleure. En réalité, ce n’est pas la bonne question. La plus honnête est souvent : laquelle correspond réellement à notre façon de travailler ?

Pour certaines équipes, tout se joue sur la portée et la gouvernance. Pour d’autres, sur la liberté de choisir les meilleurs modèles. Et pour d’autres encore, sur un flux structuré dans Jira capable d’exploiter plusieurs fournisseurs sans quitter l’issue.

Première voie : Rovo

Rovo est la couche d’IA d’Atlassian, tissée dans Jira Cloud, Confluence et Jira Service Management. Elle s’appuie sur un Teamwork Graph qui relie les personnes, les projets et les contenus de l’écosystème Atlassian, et elle s’est structurée autour de trois piliers : Search, Chat et Agents.

Point fort : la portée. Rovo Search parcourt Jira, Confluence et de nombreuses applications tierces en respectant les droits déjà en place, ce qui le rend utile pour les équipes noyées sous des informations dispersées.
Point fort : le chemin d’approbation le plus simple. Pas de clés de fournisseur à gérer, pas de modèle à choisir, pas de budget de tokens à surveiller. La gouvernance reste dans le cadre habituel des permissions et de l’audit Atlassian. La tarification est aussi plus lisible : en 2026, Rovo est positionné comme une composante des offres Atlassian Cloud, avec un accès lié au plan choisi et à ses quotas.
Limite : moins de maîtrise et moins de profondeur au niveau du ticket. Le choix du modèle est verrouillé, et l’IA reste à côté du travail plutôt qu’au cœur d’un flux structuré dans le panneau de l’issue.

Rovo est la bonne voie lorsque le vrai problème consiste à retrouver de l’information à travers plusieurs produits et que la priorité est un accès encadré, sans mise en place.

Rovo est le plus pertinent quand le besoin principal est un accès large à toute la plateforme Atlassian.

Deuxième voie : les connecteurs

Les connecteurs suivent la logique inverse. Au lieu d’enfermer l’IA dans Atlassian, ils amènent les données Jira là où l’IA vit déjà : ChatGPT, Claude Desktop, Cursor ou tout autre client compatible avec le Model Context Protocol (MCP).

Point fort : la liberté de modèle. Ils donnent accès à ce que propose le client externe. Aujourd’hui, cela veut dire Claude Opus 4.6, GPT-5.4, Gemini 3.0 Pro et les prochains modèles qui arriveront.
Point fort : une expérience déjà familière. C’est ce qui les rend séduisants pour les utilisateurs avancés qui passent déjà leurs journées dans Claude, ChatGPT ou Cursor et veulent profiter des meilleurs modèles sans apprendre une nouvelle interface. La version moderne de ce pont passe de plus en plus par MCP : le client se connecte à un serveur MCP d’Atlassian ou d’un tiers, découvre les outils Jira, puis les utilise directement dans la conversation.
Limite : l’utilisateur devient la couche d’intégration. Le contexte reste souvent superficiel si personne ne continue à le recopier à la main, l’écriture en retour vers Jira existe parfois mais reste rarement structurée, et chaque échange demeure en général privé dans un seul client. L’authentification peut aussi être laborieuse : le serveur MCP officiel d’Atlassian repose sur OAuth, et beaucoup d’équipes ajoutent un connecteur managé tiers pour rendre l’expérience plus fluide.

Les connecteurs sont la bonne voie lorsque le besoin principal est d’amener le contexte Jira dans une IA externe puissante et que l’utilisateur valorise davantage la souplesse des modèles que le flux partagé de l’équipe.

Les connecteurs sont les plus naturels quand le client IA est déjà l’outil dans lequel on aime travailler.

Troisième voie : Just

Just emprunte une troisième voie. C’est une application Jira native Forge qui installe l’expérience d’IA directement dans le panneau de l’issue, non pas comme une barre de discussion latérale, mais comme un cycle structuré : génération d’insights, clarification, planification, exécution et réécriture dans les champs Jira.

Point fort : la profondeur du flux. L’IA vit dans le ticket lui-même, pas dans un client séparé, et l’issue devient à la fois l’entrée et la destination.
Point fort : un système natif Jira capable de combiner plusieurs fournisseurs. Au lieu d’un simple aller-retour question-réponse, Just suit une séquence structurée : analyse, clarification, planification, recherche web, travail sur l’image, exécution et restitution dans Jira. Chaque étape peut être activée, sautée ou relue avant de modifier l’issue. Comme l’outil a été pensé pour plusieurs fournisseurs, l’équipe peut affecter chaque étape au modèle le plus adapté et réunir dans un seul système le contexte projet réutilisable, l’exécution visible, la consommation de tokens, le coût et les boucles de retour.
Limite : plus de mise en place et des contraintes de plateforme. Just inclut bien des clés d’essai pour démarrer, mais son fonctionnement durable repose sur un paiement à l’usage avec vos propres clés fournisseur. Cela demande une configuration un peu plus avancée : quelqu’un dans l’équipe doit connecter, créer et gérer les clés API de l’organisation. C’est aussi une option plus pertinente quand l’usage de l’IA varie fortement d’une personne à l’autre, car on n’impose pas le même coût fixe par siège à tout le monde. Je détaille ce compromis budgétaire dans Le budget IA dont personne ne parle. En tant qu’application Forge, Just reste également soumis aux contraintes d’exécution d’Atlassian.

Just est la bonne voie si vous voulez réunir, dans Jira, les forces de plusieurs fournisseurs d’IA au sein d’un flux révisable et si vous acceptez un peu plus de configuration pour obtenir ce niveau de maîtrise.

Just considère l’issue Jira à la fois comme point de départ et comme point d’arrivée.

La vraie différence : l’endroit où l’IA vit

Si l’on retire les listes de fonctionnalités et qu’on ramène chaque voie à son essence, la différence est d’ordre architectural.

Rovo, c’est le métro. Il dessert toute la ville. Vous passez de Jira à Confluence puis à Google Drive dans le même réseau. Les lignes sont fixées, l’horaire est géré pour vous, et vous faites confiance à l’exploitant.

Les connecteurs, ce sont des voitures avec chauffeur. Vous choisissez le véhicule, vous choisissez le conducteur, et vous allez exactement où vous voulez. En revanche, c’est vous qui donnez les indications, le trajet reste privé, et le reste de l’équipe n’en voit pas vraiment le déroulé complet.

Just, c’est une navette dédiée. Elle ne couvre qu’un seul corridor, l’issue Jira, mais elle l’assure avec des étapes, des points de revue et de la transparence. Elle peut aussi changer de fournisseur au fil du trajet sans faire sortir l’équipe de Jira. Tout le monde voit où en est la navette, ce qu’elle transporte et à quel moment elle arrive.

Résumé de la carte

Si l’on réduit toute la comparaison à l’essentiel, le contraste devient très simple à lire.

Dimension	Rovo	Connecteurs	Just
Où l’IA vit	Plateforme Atlassian	Client IA externe	Flux de travail de l’issue Jira
Point fort principal	Connaissance transversale entre produits	Liberté d’utiliser les meilleurs modèles	Exécution multi-fournisseur dans Jira
Forme	Recherche, chat, agents	Conversation ouverte	Cycle guidé et révisable
Visibilité partagée	Élevée	Faible	Élevée
Maîtrise du modèle	Gérée par Atlassian	Liberté individuelle maximale	Pilotage par étape au niveau de l’équipe
Principale contrepartie	Choix de modèle verrouillé	Contexte et réécriture fragmentés	Plus de mise en place et gestion des clés

La décision, dans sa forme la plus simple, tient donc à cela : portée gouvernée, liberté individuelle de modèle, ou flux structuré dans Jira capable de réunir le meilleur de plusieurs fournisseurs.

Un hub Jira qui alimente trois routes d’IA différentes rend visible la différence d’architecture : portée de plateforme, souplesse des connecteurs et exécution native du flux partent du même point, mais font circuler le travail différemment.

Choisir sa voie

Aucune voie n’est universellement juste. Une équipe qui doit chercher de l’information dans six produits SaaS et ne veut aucune charge d’infrastructure devrait commencer par Rovo.

Un ingénieur qui veut faire raisonner Claude Opus 4.6, GPT-5.4 ou Gemini 3.0 Pro sur son backlog depuis son propre client aura plutôt intérêt à utiliser un connecteur.

Une équipe produit ou delivery qui veut un flux Jira révisable, où différentes étapes peuvent mobiliser différents fournisseurs, et où le coût, la qualité et les résultats restent visibles pour toute l’équipe, devrait regarder Just sur l’Atlassian Marketplace.

Beaucoup d’équipes utiliseront plus d’une voie. Ces options ne s’excluent pas. L’important est de choisir consciemment, en fonction de la manière réelle dont l’équipe travaille et de l’endroit où se situe le vrai frottement, pas en fonction de la démo d’IA la plus impressionnante de la semaine dernière.