Atlassian veut faire évoluer Jira d’un outil de suivi vers un système capable d’identifier en continu les tâches de backlog suffisamment préparées, de les confier à un agent de développement, de lancer l’exécution et les tests puis de présenter une demande de fusion à un humain. La nouvelle fonction Agent loops s’inscrit dans un ensemble plus large : contexte multi-dépôts, contrôle d’accès des agents, règles de développement communes, revue automatisée et suivi de l’usage.
La nouveauté ne tient donc pas au simple déclenchement d’un agent depuis Jira. En juillet, Atlassian présentait déjà Jira Automation comme une couche d’orchestration pour GitHub Copilot, Cursor et Claude. L’annonce de septembre ajoute une logique persistante : Jira peut parcourir régulièrement le travail disponible au lieu d’attendre un nouveau déclenchement humain. La question d’architecture devient alors moins « l’agent sait-il coder ? » que « quelles tâches peuvent entrer seules dans ce circuit, à quelles informations l’agent a-t-il accès et quelles décisions restent soumises à une personne ? »
Le premier garde-fou se trouve dans le backlog
Dans son annonce du 10 septembre, Atlassian explique qu’Agent loops recherche en continu les tâches non attribuées et suffisamment définies, les délègue à Jira Coding Agent, lance l’exécution et les tests, puis ouvre une demande de fusion prête à être examinée. Le choix de fusionner reste humain.
Cette condition de tâche « suffisamment définie » est centrale. Le contrôle commence avant la génération de code. Une organisation doit décider quels états, critères ou types de tâches autorisent l’entrée dans la boucle. Si le backlog n’est qu’un outil administratif, une étiquette imprécise peut devenir par inadvertance une autorisation d’exécution.
La version précédente de l’orchestration Jira permettait déjà de déléguer des actions à plusieurs agents à partir d’événements. La boucle ajoute un répartiteur permanent qui peut retrouver du travail sans nouveau prompt. La qualité du backlog, les critères d’éligibilité et le traitement des exceptions deviennent donc des éléments du modèle de sécurité.
Donner du contexte ne doit pas élargir automatiquement les droits
Atlassian sépare aussi deux sujets souvent confondus : les informations utiles à l’agent et celles qu’il est autorisé à consulter. Code Context, fondé sur Teamwork Graph, apporte à Rovo et aux agents de développement une vue couvrant plusieurs dépôts. Agent Context Controls doit permettre aux équipes de plateforme de choisir quels agents peuvent agir dans un espace et ce qu’ils peuvent y voir.
La séparation est saine. Un contexte plus riche peut réduire les recherches inutiles et améliorer la préparation d’un changement, mais il expose également davantage de code, de documentation et de connaissances internes. Une architecture gouvernée doit donc répondre indépendamment à deux questions : quelles informations sont pertinentes pour la tâche, et lesquelles sont autorisées pour cet agent précis ?
Atlassian cite une analyse interne de DX selon laquelle les équipes utilisant le plus de contexte Teamwork Graph auraient livré environ 64 % de plus par développeur. Il s’agit d’une corrélation rapportée par le fournisseur, pas d’une démonstration causale de l’effet du contexte sur la productivité.
Plusieurs contrôles avant la décision de fusion
Standards permet aux équipes de plateforme d’associer des règles de développement aux dépôts. AI Review examine ensuite les demandes de fusion au regard de ces règles avant leur arrivée chez un réviseur humain. Un tableau de bord doit suivre l’usage des agents, tandis que DX for Agentic Development agrège des indicateurs d’adoption, de coût, de débit et de qualité.
L’intérêt vient de l’enchaînement. Jira choisit le travail admissible ; les contrôles de contexte limitent ce que l’agent peut consulter ; les règles de dépôt définissent les attentes ; une revue automatisée vérifie la proposition ; l’humain conserve enfin l’autorité de fusion.
Cette succession de contrôles ne garantit pas la sûreté. Si une mauvaise règle est commune à la sélection, aux standards et à la revue, plusieurs mécanismes automatiques peuvent confirmer la même erreur. Il faut donc, en plus des étapes de contrôle, une responsabilité claire sur les politiques, des traces d’audit et une procédure d’escalade lorsque les mécanismes ne sont pas d’accord.
Une architecture encore inégalement disponible
Le niveau de maturité limite la portée de l’annonce. Atlassian indique que Code Context arrive progressivement en bêta ouverte chez les clients payants. Agent loops, Standards et AI Review restent en accès anticipé privé. Agent Context Controls et le tableau de bord d’usage doivent être généralisés dans les prochains mois, tandis que DX for Agentic Development est annoncé en disponibilité générale ce trimestre.
Le compte rendu indépendant d’IT Pro confirme ce déploiement par étapes. Il serait donc prématuré de lire l’annonce comme une preuve de fonctionnement à grande échelle en production. Elle décrit surtout la couche de contrôle qu’Atlassian est en train d’assembler autour des agents.
Pour une équipe qui évalue cette approche, la question utile n’est pas de savoir si Jira peut ouvrir automatiquement une demande de fusion. Il faut vérifier si trois frontières sont réellement explicites : les tâches admissibles, les ressources auxquelles l’agent peut accéder et les effets qui nécessitent encore une autorisation humaine.
Lorsque ces frontières sont observables et auditées, une boucle persistante peut réduire la coordination répétitive sans transformer discrètement le backlog en file d’exécution. Dans le cas contraire, l’automatisation ne corrige pas un modèle de contrôle faible ; elle le fait simplement fonctionner plus souvent.