Atlassian a étendu Jira pour que les équipes d’ingénierie planifient, assignent des tâches à des agents de programmation, suivent leur exécution et mesurent leur coût depuis un seul environnement. La plateforme prend en charge Claude Code, Cursor et GitHub Copilot, intègre un agent propriétaire capable de générer des demandes d’intégration de changements, et prépare une intégration directe avec OpenAI Codex.
L’essentiel en 20 secondes : Jira pourra assigner du travail à différents agents et signaler quelles tâches sont bloquées ou en attente de révision. Teamwork Graph apportera du contexte issu de Jira, Confluence, Slack et des dépôts de code. L’agent propriétaire travaillera dans un environnement isolé et générera des pull requests. Atlassian mesurera aussi l’usage de tokens, la dépense et le coût estimé par changement de code.
L’entreprise s’attaque à une contradiction qui émerge dans les départements de développement. Les programmeurs utilisent de plus en plus d’assistants et d’agents d’intelligence artificielle, sans que cette hausse se traduise par une amélioration équivalente de la capacité à livrer du logiciel. Une étude longitudinale menée par Atlassian et DX montre que l’usage de l’IA par les ingénieurs a grimpé de 65 %, quand la vitesse moyenne de développement ne progressait que d’environ 10 %, jusqu’à 15 % dans les organisations les plus avancées. Ces chiffres viennent d’une recherche sponsorisée par Atlassian, pas d’une mesure universelle du secteur, mais ils expliquent l’approche du nouveau Jira.
Le problème ne se limite plus à écrire du code. Avant même de commencer, il faut comprendre ce qui doit être construit, revoir les décisions antérieures, localiser les dépendances et transformer une demande métier en exigences techniques. Viennent ensuite les tests, la revue de sécurité, la documentation, l’approbation et le déploiement. Les agents génèrent du code rapidement, mais interprètent parfois une demande trop littéralement, ignorent une contrainte architecturale ou produisent une solution en apparence valide qui exige ensuite plusieurs heures de révision. Atlassian veut faire de Jira la couche de coordination entre les personnes et ces agents.
Jira ne se contente plus d’enregistrer qui fait quoi
Depuis plus de deux décennies, Jira sert de registre de bugs, d’histoires, de projets et de flux de travail. La nouvelle version étend cette fonction : un agent devient un participant à qui l’on assigne du travail, comme à un membre de l’équipe, tout en restant lié au ticket qui a déclenché l’action. Les utilisateurs pourront confier des tâches directement à Claude Code, Cursor ou GitHub Copilot. L’intégration pour attribuer du travail à Codex arrivera plus tard, mais Jira permet déjà d’ouvrir certains tickets dans l’application locale de Codex en chargeant au préalable les informations principales.
| Capacité | Ce que l’équipe pourra faire |
|---|---|
| Assignation à des agents | Envoyer un ticket à Claude Code, Cursor ou GitHub Copilot |
| Jira Coding Agent | Générer du code dans Jira et préparer un pull request |
| Séances centralisées | Voir quels agents travaillent, sont bloqués ou en attente de révision |
| Automatisations | Envoyer erreurs, tests ou documentation aux agents en arrière-plan |
| Modèle agentique | Créer des projets avec états et flux prédéfinis |
| Rapport de coûts | Relier consommation de tokens et dépenses aux projets et modifications |
Jira Coding Agent est l’outil propriétaire d’Atlassian pour exécuter ce travail. Il lit le ticket, consulte les informations autorisées dans Jira et Confluence, accède au dépôt choisi et travaille dans une session cloud isolée. Il peut exécuter des commandes Bash ou PowerShell, modifier du code et envoyer ces changements vers une branche, puis créer une ébauche de pull request, mais ne peut pas la fusionner lui-même : la revue et l’approbation finales restent entre les mains de l’équipe. Ses permissions héritent de celles de l’utilisateur qui démarre la session, sans accès aux informations Jira, Confluence ou dépôts que cet utilisateur ne possède pas déjà, et chaque session ne clone que le dépôt sélectionné dans l’environnement isolé.
| Actions possibles avec Jira Coding Agent | Portée annoncée |
|---|---|
| Consulter Jira et Confluence | Selon les permissions de l’utilisateur |
| Accéder au code | Uniquement au dépôt sélectionné |
| Exécuter des commandes | Dans l’environnement cloud isolé |
| Créer une branche | Autorisé si l’utilisateur le valide |
| Ouvrir un pull request | Peut créer une ébauche |
| Fusionner des changements | Interdit |
| Accéder à l’environnement local | Non |
| Supprimer des informations de Jira ou Confluence | Non |
Ce dispositif réduit certains risques, sans supprimer la nécessité de revoir le code : un agent peut introduire des vulnérabilités, toucher plus de fichiers que nécessaire ou produire des tests qui valident sa propre solution sans couvrir les cas critiques. La visibilité des sessions vise aussi à éviter que le travail se disperse entre terminaux, conversations privées et outils déconnectés. Jira montrera quel agent a reçu une tâche, quelles actions il a menées et où une intervention humaine s’impose.
Teamwork Graph s’attaque au problème du contexte d’entreprise
La pièce centrale de la proposition s’appelle Teamwork Graph, la couche par laquelle Atlassian relie tâches, documents, personnes, objectifs, code et décisions antérieures. Un agent peut recevoir un ticket du type « corrige le processus de paiement », mais cette phrase ne dit rien des services concernés, d’une décision prise six mois plus tôt, des exigences réglementaires applicables ou du composant à ne surtout pas toucher. Cette connaissance reste souvent éparpillée entre Jira, Confluence, Slack, GitHub et des conversations internes.
Teamwork Graph cherche à fournir ce contexte enrichi avant que l’agent ne génère du code. Selon des tests internes d’Atlassian, les agents dotés de ces informations ont produit des résultats 44 % plus précis et consommé 48 % de tokens en moins par rapport à des agents sans cette couche — des chiffres issus d’évaluations internes, sans détail complet sur les modèles, dépôts et critères employés.
| Sources d’information | Contributions possibles |
|---|---|
| Jira | Exigences, responsables, statuts, priorités |
| Confluence | Spécifications, décisions, documentation |
| Slack | Conversations ayant évoqué la demande |
| GitHub | Code, branches, changements, dépendances |
| Loom | Vidéos, audio, clics et explication visuelle d’une tâche |
| Jira Product Discovery | Besoins clients et décisions produit |
Jira Planner exploitera ces informations pour transformer des projets complexes en spécifications techniques structurées, en consultant la base de code, l’historique de Jira et Confluence, ainsi que le contexte de l’équipe, avant de créer un document dans Confluence qu’une personne ou un agent pourra examiner. Cette fonctionnalité n’est pas encore généralisée : Atlassian a lancé une liste d’attente pour son programme d’accès anticipé, et les résultats devront être évalués dans des organisations à la documentation incomplète, aux projets anciens et aux dépôts volumineux.
Jira pour Slack permettra de créer des tickets et d’assigner des tâches en mentionnant @Jira dans une conversation, en transférant le contenu pertinent vers l’élément de travail et en synchronisant les nouveaux messages comme commentaires, pour éviter que l’agent ne travaille sur un résumé déconnecté de la discussion d’origine. Loom, de son côté, transformera un enregistrement d’écran et une explication orale en instructions structurées : un responsable pourra montrer une erreur, indiquer où elle se produit et décrire le comportement attendu, pendant que la plateforme extrait images, clics, liens et voix pour construire un plan qui deviendra des tâches Jira. L’objectif n’est pas d’ajouter plus de données, mais de sélectionner celles qui comptent : envoyer des documents complets à un modèle augmente le coût, encombre la fenêtre de contexte et brouille les décisions importantes. La réduction de tokens annoncée dépendra de la capacité de Teamwork Graph à filtrer et relier correctement l’information.
Automatiser la détection d’erreurs et de vulnérabilités sans perdre le contrôle
Jira intégrera des agents dans son constructeur de règles d’automatisation. Une équipe pourra définir que certaines erreurs simples, tests manquants ou tâches de documentation soient envoyés automatiquement à un agent, qui opèrera en arrière-plan et notifiera lorsqu’un pull request sera prêt à être révisé. Atlassian envisage aussi ce modèle pour supprimer des indicateurs de fonctionnalités obsolètes, corriger des vulnérabilités connues ou mettre à jour la documentation après un changement. L’entreprise affirme avoir réduit jusqu’à 80 % le temps consacré à certaines tâches répétitives dans certaines équipes Jira, un résultat interne lié à des flux précis, pas nécessairement transposable à l’ensemble du cycle de développement.
| Travail pouvant être délégué | Contrôle à maintenir |
|---|---|
| Corrections mineures | Revue du changement et tests |
| Génération de tests | Vérification de la couverture et de la qualité |
| Vulnérabilités connues | Validation de la sécurité |
| Mise à jour de la documentation | Vérification de la précision |
| Suppression de code obsolète | Confirmation des dépendances |
| Changements répétitifs | Limites concernant dépôts et fichiers |
L’automatisation peut augmenter le volume de modifications préparées, mais risque aussi de créer un goulet d’étranglement à la revue : si plusieurs agents proposent des changements plus vite que l’équipe ne peut les examiner, le travail en attente s’accumule et certaines modifications finissent approuvées sans analyse suffisante — un risque proche de celui que Linus Torvalds évoque pour la revue du noyau Linux. Atlassian cherche à rendre ce problème visible via une vue unifiée des sessions, où les responsables suivent ce qui est en cours, ce qu’un agent a arrêté, quelles modifications attendent une révision et depuis combien de temps.
L’entreprise propose aussi un rapport dans Atlassian DX pour relier les dépenses en Claude, Cursor, GitHub Copilot et autres outils aux projets et résultats d’ingénierie. Le système estimera le coût IA par pull request et rassemblera la consommation de tokens, souvent répartie entre plusieurs fournisseurs — une préoccupation similaire à celle qui pousse Moonshot à comparer le coût par token de Kimi K3 face à ses concurrents. Mesurer le coût par changement peut aider, mais ne suffit pas à garantir la qualité : un pull request bon marché qui introduit de la dette technique ou exige une révision approfondie peut coûter plus cher, au final, qu’un autre plus onéreux mais robuste. Les entreprises devront combiner cette mesure avec les temps de cycle, les incidents, les retours en arrière et les résultats en production.
Ce qui est disponible et ce qui va arriver
Atlassian indique que les agents Claude Code, Cursor et GitHub Copilot, Jira pour Slack, Jira Coding Agent, les automatisations, les modèles et la vue de sessions sont déjà accessibles aux clients payants de Jira Cloud sans coût supplémentaire spécifique. Les détails de support précisent toutefois que Jira Coding Agent exige que les fonctionnalités IA soient activées, que des crédits Rovo soient disponibles, que GitHub Cloud ou Bitbucket Cloud soient connectés, et que l’édition soit compatible. « Sans coût supplémentaire » ne veut pas dire usage illimité ni disponibilité automatique dans toutes les configurations.
| Fonction | Situation |
|---|---|
| Claude Code, Cursor et GitHub Copilot dans Jira | Disponible |
| Jira Coding Agent | Disponible dans les plans compatibles |
| Jira pour Slack | Disponible |
| Automatisations avec agents | Disponibles |
| Vue des sessions | Disponible |
| Jira Planner | Liste d’attente pour accès anticipé |
| Rovo pour Microsoft Teams | Accès anticipé |
| Assignation directe à Codex | Prochainement |
| DX AI Cost Management | Disponible pour les clients d’Atlassian DX |
Il faut distinguer la simple création d’un ticket dans l’outil de son attribution à un agent. Jira peut déjà lancer Codex, Claude Code, Cursor ou GitHub Copilot en local en chargeant le contexte du ticket, mais l’intégration annoncée pour assigner Codex directement depuis Jira reste en développement.
Atlassian veut faire évoluer le rôle historique de Jira, simple registre du travail d’ingénierie, vers un atout pour la gestion des agents. L’objectif n’est pas seulement d’avoir le meilleur modèle de programmation, mais de maîtriser le contexte, l’attribution, la supervision et la mesure de tous ces éléments. Le succès dépendra de la capacité de Teamwork Graph à représenter fidèlement la réalité de chaque entreprise : quand les tickets sont incomplets, la documentation obsolète ou les décisions clés cachées dans des conversations privées, l’agent hérite de ces problèmes. Jira peut offrir un point de convergence entre humains et systèmes automatisés, mais ne remplace pas la nécessité de définir clairement les exigences, maintenir une connaissance fiable et réviser ce qui part en production.
Questions fréquentes
Quels agents de programmation Jira peut-il utiliser ?
Atlassian prend en charge Claude Code, Cursor et GitHub Copilot. Codex peut déjà s’ouvrir depuis un ticket avec contexte chargé, mais son attribution directe comme agent dans Jira arrivera à une étape ultérieure.
Qu’est-ce que Jira Coding Agent ?
L’agent propriétaire d’Atlassian pour générer du code à partir d’un ticket. Il fonctionne dans un environnement cloud isolé, peut créer une branche et ouvrir un brouillon de pull request, mais ne peut pas fusionner lui-même.
Que rajoute Teamwork Graph aux agents ?
Il relie tâches, documents, conversations, code, personnes et décisions pour fournir un contexte d’entreprise. Atlassian indique que ses tests internes ont amélioré la précision et réduit la consommation de tokens.
Les nouvelles fonctionnalités ont-elles un coût supplémentaire ?
Atlassian les inclut dans ses plans payants compatibles, mais certaines nécessitent des crédits Rovo, l’activation de l’IA et une connexion à un dépôt. DX AI Cost Management est proposé aux clients d’Atlassian DX.