Jira a longtemps été perçu comme l’outil que les développeurs ouvrent parce qu’ils y sont obligés, pas parce qu’ils en ont envie. Atlassian tente désormais de changer cette relation avec une série de nouveautés centrées sur l’intelligence artificielle, pensées pour rapprocher Jira du quotidien réel des équipes de développement.
L’objectif est clair : faire de Jira autre chose qu’un espace de suivi de tickets pour chefs de projet. Atlassian veut en faire un point d’entrée opérationnel du cycle de développement logiciel, capable de générer des spécifications, d’assigner du travail à des agents de codage, de produire des pull requests et d’automatiser une partie des tâches répétitives.
Selon les informations rapportées par The New Stack, les équipes peuvent désormais assigner des éléments de travail Jira directement à Claude Code, Cursor ou GitHub Copilot. Le support d’OpenAI Codex est annoncé pour plus tard. Atlassian intègre aussi son propre Jira Coding Agent, inclus dans les offres payantes, pour transformer des tickets en pull requests sans nécessiter de configuration locale.
Jira veut devenir un environnement de travail pour développeurs, pas seulement un outil de suivi
La promesse d’Atlassian repose sur une idée simple : si les développeurs doivent déjà passer par Jira pour comprendre les priorités, pourquoi ne pas leur permettre d’y lancer directement une partie du travail technique ?
Ming Wu, responsable de l’ingénierie DevAI chez Atlassian, résume sans détour le problème : les développeurs n’aiment généralement pas interagir avec Jira. L’entreprise veut donc rendre cette interaction plus utile, plus rapide et moins éloignée de leur environnement habituel.
Le nouveau Jira Coding Agent, précédemment connu sous le nom de Rovo Dev, fonctionne dans le cloud. Il ne s’exécute pas sur l’ordinateur du développeur. Chaque ticket peut être assigné soit à une personne, soit à un agent, selon la nature de la tâche. Lorsqu’une session est ouverte, l’utilisateur accède à une interface proche de VS Code, avec un diff de code et un terminal intégrés.
Dans la pratique, Atlassian cherche à réduire les allers-retours entre les tickets, l’IDE, la documentation, les discussions Slack et les dépôts de code. C’est précisément ce changement de contexte qui pèse sur la productivité des équipes.
Ce que les nouvelles fonctions IA changent concrètement
Les annonces d’Atlassian ne se limitent pas à un agent de code. Elles couvrent plusieurs étapes du cycle de vie logiciel, de la planification à la revue.
Des tickets assignables à des agents IA
Les équipes peuvent confier certains éléments Jira à des agents comme Claude Code, Cursor ou GitHub Copilot. L’idée n’est pas de remplacer systématiquement le développeur, mais de choisir l’exécutant le plus adapté : humain pour les décisions complexes, agent pour les tâches cadrées et répétitives.
Exemples de tâches susceptibles d’être confiées à un agent :
- corriger un bug simple à partir d’un ticket bien documenté ;
- générer des tests unitaires manquants ;
- préparer une pull request sur une modification de faible portée ;
- remédier à certaines vulnérabilités connues ;
- mettre à jour une documentation technique liée au code.
Jira Planner génère des spécifications dans Confluence
Atlassian introduit aussi Jira Planner, un outil capable de s’appuyer sur l’historique Jira, Confluence et le contexte de l’équipe pour produire une spécification technique dans Confluence. Cette spécification peut ensuite être découpée en éléments de travail Jira.
Ce point est important, car la planification reste souvent l’un des endroits où les informations se perdent. Les décisions sont prises dans une réunion, détaillées dans un document, discutées dans Slack, puis traduites en tickets parfois incomplets. Atlassian veut rapprocher ces étapes dans un flux plus continu.
Jira s’invite davantage dans Slack
Avec Jira for Slack, les utilisateurs peuvent créer des éléments de travail en interpellant @Jira depuis un fil de discussion. L’intérêt est de capturer une demande ou un bug au moment où il apparaît, sans obliger l’utilisateur à quitter la conversation pour remplir manuellement un ticket.
Pour les équipes produit et support, ce type d’intégration peut limiter les pertes d’information. Pour les développeurs, il peut aussi éviter les tickets trop vagues générés plusieurs heures après une discussion.
Le nouveau goulot d’étranglement : la revue humaine
L’un des grands sujets soulevés par les agents de codage est moins la génération de code que sa validation. Si l’IA produit plus vite, le risque est de déplacer le problème vers la revue de code.
Ming Wu reconnaît ce point : le goulot d’étranglement reste humain. Plus le volume de code généré augmente, plus il devient difficile de tout relire correctement. La longueur des changements reste un facteur critique, même avec des outils d’assistance.
Atlassian mise donc aussi sur des fonctions de revue augmentée : parcours guidés pour attirer l’attention du reviewer sur les zones importantes, auto-review par IA pour filtrer les problèmes mineurs, priorisation des changements réellement sensibles.
Le scénario le plus réaliste à court terme n’est pas une automatisation totale de la revue, mais une redistribution de l’effort : l’IA traite les vérifications mécaniques, tandis que les développeurs se concentrent sur l’architecture, les effets de bord, la sécurité et la cohérence produit.
Le contexte devient l’arme stratégique d’Atlassian
Sur le marché des assistants IA pour développeurs, Atlassian ne se positionne pas exactement comme GitHub, les éditeurs d’IDE ou les fournisseurs de modèles. Son avantage revendiqué est le contexte d’équipe.
Ce contexte passe par le Teamwork Graph, la couche de données d’Atlassian qui relie Jira, Confluence, Slack, GitHub et Jira Product Discovery. L’objectif est de fournir aux agents suffisamment d’informations pour comprendre non seulement le code, mais aussi les décisions produit, l’historique des tickets, les dépendances et les habitudes de l’équipe.
Cette approche répond à une limite fréquente des assistants IA : ils peuvent écrire du code, mais ils manquent souvent du contexte métier ou organisationnel qui rend ce code pertinent. Un agent capable de lire un ticket, de consulter une spécification, d’identifier les discussions liées et de comprendre la structure de l’équipe peut produire un résultat plus exploitable.
Atlassian indique également que le contexte de base de code doit fonctionner avec différents fournisseurs de gestion de sources, notamment GitHub et Bitbucket. C’est un point clé pour les entreprises qui utilisent plusieurs systèmes en parallèle.
Des gains de productivité mesurés, mais loin du mythe du “10x”
Atlassian avance plusieurs chiffres pour défendre son approche. Une étude longitudinale menée avec DX, plateforme de productivité développeur rachetée par Atlassian pour 1 milliard de dollars, indique que les gains de productivité liés à l’IA plafonnent autour de 15 %, avec de nombreuses organisations sous les 10 %.
Ce constat tranche avec certains discours marketing promettant des gains spectaculaires. DX a d’ailleurs résumé ces données de manière directe : les gains de productivité de l’IA seraient plutôt de l’ordre de 10 %, pas de 10 fois.
Atlassian met toutefois en avant ses propres résultats internes, observés auprès de ses 6 000 ingénieurs utilisant les nouvelles capacités :
- 44 % d’amélioration de l’efficacité de complétion des tâches par agent ;
- 48 % de baisse de la consommation de tokens ;
- 36 % de réduction du cycle de vie des pull requests ;
- 51 % des vulnérabilités de code routinières résolues de façon autonome puis placées en file de revue développeur.
Ces chiffres doivent être lus avec prudence. Les performances d’un agent dépendent du modèle utilisé, de la qualité des tickets, du niveau de contexte disponible, des règles internes et du type de tâche. Ming Wu souligne d’ailleurs que les démonstrations isolées publiées en ligne masquent souvent les cas limites, les biais d’échantillon ou l’absence de benchmark représentatif.
Pourquoi cette stratégie pourrait changer le rôle des développeurs
Si les agents écrivent davantage de code, le rôle du développeur évolue. Il devient moins centré sur la saisie manuelle de chaque ligne et davantage sur la définition du problème, la validation, l’architecture, l’intégration et la qualité.
Ming Wu anticipe une évolution progressive des interfaces : certaines expériences n’ont déjà plus d’éditeur classique et passent principalement par le chat. Elle reconnaît que cette approche n’est pas toujours confortable, mais estime que la direction générale du marché va vers une diminution du temps passé à écrire directement du code.
Cette transition peut être déroutante. Les développeurs devront apprendre à formuler des tâches précises, à encadrer les agents, à vérifier leurs sorties et à maintenir une vision globale du système. Les product managers, de leur côté, pourront prototyper plus vite et manipuler davantage de contexte technique.
En clair, l’IA ne supprime pas les frontières entre métiers, mais elle les rend plus poreuses. Les développeurs devront comprendre davantage le produit, tandis que les équipes produit pourront aller plus loin dans l’exploration technique.
Les agents Jira ne se limitent pas au code
Atlassian observe déjà des usages d’agents pour des tâches non techniques. Les utilisateurs peuvent assigner des travaux à des agents dans Jira depuis quelque temps, et les agents de codage représentent seulement une extension plus récente de cette logique.
La documentation, la planification budgétaire, la synthèse d’informations ou la préparation de tickets sont des cas d’usage plus simples que la génération de code. C’est d’ailleurs pourquoi Atlassian ne présente pas Jira Planner comme un outil exclusivement destiné aux développeurs, même si le lancement met fortement l’accent sur le cycle logiciel.
Pour les organisations, cela ouvre une question intéressante : faut-il penser les agents IA comme des assistants spécialisés par métier, ou comme une couche transversale intégrée aux workflows existants ? Atlassian parie clairement sur la deuxième option.
Ce que les équipes doivent surveiller avant d’adopter ces agents
Les nouvelles fonctions d’Atlassian peuvent être utiles, mais elles exigent une gouvernance claire. Confier des tickets à des agents IA sans cadre peut créer plus de bruit que de valeur.
Avant de généraliser ce type d’usage, une équipe devrait définir :
- les catégories de tâches autorisées pour les agents ;
- les règles de revue obligatoire avant fusion ;
- les exigences de tests automatisés ;
- les zones du code interdites à l’automatisation sans validation senior ;
- les critères de qualité d’un ticket exploitable par IA ;
- les métriques à suivre : temps de cycle, taux de rejet, bugs introduits, charge de revue.
Le point le plus important reste la qualité de l’entrée. Un ticket flou produira rarement une pull request fiable, même avec un très bon modèle. À l’inverse, un ticket précis, relié à une spécification claire et accompagné de critères d’acceptation mesurables, augmente fortement les chances d’obtenir un résultat utile.
Une feuille de route volontairement courte
Atlassian reconnaît que l’évolution du développement logiciel est trop rapide pour planifier loin. Ming Wu indique que l’entreprise travaille essentiellement par trimestre, avec un horizon d’environ six mois au maximum. Au-delà, les prévisions deviennent incertaines.
Cette prudence est révélatrice. Le marché des agents IA évolue vite, les interfaces changent, les modèles progressent et les usages réels restent en construction. Atlassian ne vend donc pas seulement une nouvelle fonction Jira : l’entreprise essaie de repositionner sa plateforme au cœur d’un cycle logiciel qui pourrait être très différent dans un an.
Jira peut-il vraiment séduire les développeurs ?
La réponse dépendra moins de l’IA elle-même que de l’expérience quotidienne. Les développeurs n’adopteront pas Jira plus volontiers parce qu’un agent y est ajouté. Ils le feront si Jira leur évite réellement des tâches pénibles, réduit les changements de contexte et améliore la qualité des informations disponibles.
Atlassian dispose d’un atout majeur : ses outils sont déjà profondément installés dans de nombreuses organisations. Si le Teamwork Graph parvient à fournir aux agents un contexte fiable, Jira pourrait devenir un lieu d’orchestration pertinent entre produit, code, documentation et communication.
Mais le défi reste culturel autant que technique. Pour réconcilier les développeurs avec Jira, Atlassian devra prouver que ses agents ne créent pas simplement plus de tickets, plus de pull requests et plus de revues à gérer, mais qu’ils permettent réellement de livrer mieux, avec moins de friction.
La bataille ne se jouera donc pas sur la promesse d’une productivité multipliée par dix. Elle se jouera sur quelque chose de plus concret : quelques heures gagnées, moins d’interruptions, des tickets mieux structurés et des revues plus ciblées. C’est probablement là que l’IA peut rendre Jira enfin plus acceptable pour les développeurs.