Garde-fous et sécurité des agents IA dans Jira

Les garde-fous vous permettent d'adopter l'IA à grande échelle en instaurant la confiance grâce à des workflows agentiques. Ceux qui fonctionnent sont intégrés à vos workflows, de sorte que le système les applique au lieu de s'en remettre à l'agent.
Dans Jira, ce système est celui que votre équipe utilise déjà pour travailler. Jira accorde à chaque agent les droits d'accès qui lui reviennent grâce à un système d'autorisations, à des points de contrôle où des humains interviennent pour valider les transitions de workflow, ainsi qu'à un historique de toutes les actions effectuées par l'agent sur le ticket. Le Teamwork Graph fournit à l'agent le contexte nécessaire pour agir.
Ce guide présente les risques auxquels s'attaquent les garde-fous destinés aux agents, ainsi que la manière de les mettre en œuvre dans Jira. Il vous permettra ainsi de déployer l'IA de manière sûre et responsable, en accordant aux agents plus d'autonomie sur les tickets de votre équipe, qu'il s'agisse de tâches courantes de maintenance ou de projets à forte valeur ajoutée, sans pour autant perdre le contrôle. À cette échelle, l'autonomie repose sur quatre garde-fous que vous définissez dans Jira, à l'aide des workflows, des autorisations et des règles déjà mises en place par votre équipe :
Détermination du périmètre d'accès. Définissez les données auxquelles un agent a accès, les outils qu'il peut utiliser et les domaines dans lesquels il peut intervenir, via vos autorisations Jira existantes.
Contrôle des décisions à risque. Servez-vous des transitions de workflow pour exiger une approbation humaine avant qu'un ticket à fort impact n'aboutisse.
Vérification de la sortie. Vérifiez ce que l'agent a produit dans le cadre de votre revue habituelle de pull request avant la mise en production de la sortie.
Conservation de l'enregistrement. Chaque action effectuée par un agent est consignée dans l'historique du ticket, avec mention de la personne qui l'a approuvée.
Que sont les garde-fous en ingénierie agentique ?
Les garde-fous des agents sont les mécanismes de contrôle qui garantissent que le travail d'un agent IA est sûr, conforme aux attentes et consigné : ce à quoi il a accès, les points de contrôle où une personne intervient, et l'historique de ses actions. Un garde-fou est appliqué par le système dans lequel l'agent évolue. Il n'est pas laissé à la discrétion de l'agent de le respecter de lui-même.
On ne peut pas garantir la sécurité d'un agent en lui donnant simplement des instructions de comportement, car celles-ci peuvent être oubliées, mal interprétées ou contournées. Un véritable garde-fou se situe au-dessus de l'agent, dans son environnement, où la limite s'applique quoi qu'on lui dise. C'est le même principe qui régit déjà le fonctionnement de votre équipe : c'est le système qui décide de ce qui est possible, et non la personne à qui l'on demande de respecter les règles.
Dans la pratique, les garde-fous relatifs aux agents couvrent plusieurs domaines connexes :
Accès et périmètre : les données auxquelles un agent peut accéder, les outils qu'il peut utiliser et les domaines dans lesquels il peut intervenir.
Tâches délimitées : les tâches dont un agent peut se charger entièrement, et celles qui restent du ressort d'une personne.
Approbation humaine : les points de contrôle où une personne passe en revue ou approuve avant que le travail ne se poursuive.
Vérification des sorties : la validation de ce que l'agent a produit avant sa livraison.
Responsabilité et audit : un historique de ce que l'agent a fait, pourquoi, et qui a donné son accord.
Gouvernance : les contrôles permanents qui garantissent la cohérence de l'ensemble à mesure que l'utilisation des agents se développe.
Ensemble, ces éléments renforcent la confiance dans les workflows agentiques. Ils permettent à une équipe de confier davantage de responsabilités aux agents sans perdre le contrôle, car un humain reste responsable du résultat.
Pourquoi les agents d'IA ont-ils besoin de garde-fous ?
Les agents agissent. Contrairement à un chatbot qui se contente de faire des suggestions, un agent peut modifier du code, déplacer des tâches et déclencher des actions concrètes dans l'ensemble de vos outils. C'est cette autonomie qui les rend utiles, mais c'est aussi la raison pour laquelle ils ont besoin de garde-fous : plus un agent est capable d'agir de manière autonome, plus il est important que son travail reste aligné, contrôlé et justifiable.
Les principaux risques traités par les garde-fous, et les domaines où le jugement humain reste essentiel :
Manque d'alignement : l'agent optimise un objectif erroné ou s'écarte de la tâche.
Sorties de mauvaise qualité ou erronés : un travail qui semble terminé, mais qui passe à côté de l'objectif, notamment du code ou des faits hallucinés.
Accès trop étendu : l'agent accède à des données ou à des systèmes auxquels il ne devrait pas.
Actions non vérifiées et irréversibles : des changements à fort impact qu'il est impossible d'annuler proprement, comme la mise en production ou la suppression de données, et qui nécessitent un contrôle humain avant leur mise en œuvre.
Absence de responsabilité ou de visibilité : sans trace écrite, personne ne peut voir ce que l'agent a fait ni qui a donné son accord.
Coûts incontrôlables : les agents peuvent consommer des jetons et des ressources informatiques de manière imprévisible ; leurs dépenses doivent donc être plafonnées, comme pour toute autre ressource.
Un garde-fou ne fonctionne que si c'est le système qui l'applique, et non l'agent. Indiquer à un agent ce qu'il ne doit pas faire ne constitue pas un garde-fou, car il peut recevoir cette consigne tout en agissant à votre insu. Les véritables garde-fous se situent au-dessus de l'agent, dans l'environnement où il évolue, de sorte que l'action indésirable soit rendue impossible, et pas seulement déconseillée.
C'est pourquoi les garde-fous constituent une condition préalable à l'autonomie, et non un frein à celle-ci. Les équipes qui font confiance à ces limites peuvent confier davantage de responsabilités aux agents tout en réduisant la supervision directe. Celles qui n'y parviennent pas perdront la rapidité pour laquelle elles ont adopté les agents.
Comment gouverner les agents d'IA en toute sécurité dans Jira ?
Si un garde-fou doit être mis en place au-dessus de l'agent dans le système où il opère, alors c'est ce système qui importe, et pour les tâches d'ingénierie, il s'agit de Jira. Lorsque les agents opèrent au sein du System of Work d'Atlassian, ils accèdent à vos données et à vos tickets via les mêmes autorisations Jira que votre équipe utilise déjà, ainsi qu'à vos workflows et à votre piste d'audit existants. Ce qu'un agent peut faire au sein de son propre environnement reste sous son contrôle ; ainsi, Jira gère l'accès au travail, tandis que les autorisations au niveau de l'agent gouvernent les outils qu'il exécute.
À lui seul, un agent de codage ne gouverne que ses propres actions. Jira gouverne le travail, de sorte que les garde-fous s'appliquent en un seul endroit pour tous les agents, et vous pouvez voir quel risque chacun d'entre eux traite.
C'est au niveau des workflows que s'effectue l'essentiel de cette mise en œuvre. Les états, les transitions et les règles qui acheminent le travail entre les collaborateurs l'acheminent également vers les agents, déterminent les transitions qu'un agent est autorisé à effectuer et soumettent les changements importants à une validation.
Accès : ce que vous pouvez contrôler dans Jira
Le premier paramètre de contrôle est le périmètre : les données, les outils et les projets avec lesquels un agent peut travailler. Il s'agit d'un garde-fou contre les accès trop larges. Dans Jira, vous le configurez de la même manière que pour n'importe quel coéquipier, ce qui rend le processus familier et vous permet de l'ajuster à votre guise.
Fonctionnement dans Jira : vous choisissez l'identité sous laquelle un agent agit. Par défaut, il agit au nom de la personne qui s'en sert, n'ayant accès qu'aux données, projets et tickets auxquels cette personne a accès. Vous pouvez également attribuer à un agent son propre compte et ses propres autorisations, afin que son accès ne dépende d'aucune personne en particulier. Les administrateurs contrôlent quels agents sont actifs et où. Ce qu'un agent peut faire avec ses propres outils est défini par l'agent lui-même, et non par Jira. Vous pouvez maintenir un accès large ou définir un périmètre strict, puis l'élargir à mesure que la confiance grandit.
Les contrôles que vous ajustez :il s'agit des mêmes leviers d'autorisation que ceux que vous utilisez déjà pour les utilisateurs : les systèmes d'autorisation et les rôles de projet définissent ce qu'un agent peut faire dans un projet, tandis que les restrictions de sécurité des tickets déterminent ceux qu'il peut consulter. Les restreindre, même partiellement, limite la portée de l'agent, sans qu'aucun système spécifique aux agents ne soit nécessaire.
Accordez l'accès à ce qui est nécessaire à la tâche : la plupart des agents travaillent mieux lorsqu'ils disposent d'une certaine marge de manœuvre ; limitez donc le périmètre d'accès au strict nécessaire pour la tâche. Pour les systèmes véritablement sensibles, restreignez spécifiquement l'accès à ceux-ci.
Comment contrôler les actions des agents dans votre workflow ?
Le deuxième garde-fou est le workflow : les règles qui déterminent quand un agent s'exécute, ce qu'il peut faire de manière autonome et quels messages doivent être traités par un humain. C'est votre protection contre les décalages et les actions irréversibles. Vous définissez ces règles sur les transitions que votre équipe utilise déjà, de sorte que la supervision ne se résume pas à un simple contrôle final.
Une condition de transition limite les étapes sur lesquelles un agent peut intervenir, un validateur bloque le travail qui n'est pas prêt, et une étape d'approbation réserve les changements importants à une intervention humaine. L'approbation humaine n'est qu'une règle parmi d'autres, et le défi consiste à adapter chaque règle au risque encouru.
Comment le configurer dans Jira : ouvrez le workflow correspondant au type de ticket et ajoutez un agent à une transition, par exemple lors du passage à l'étape « En revue », afin que l'agent s'exécute lorsqu'un ticket atteint ce stade. L'ajout d'un agent définit le moment où il s'exécute, et non si une personne doit donner son accord. L'approbation humaine est un contrôle distinct : une étape d'approbation du workflow bloque la transition, et vous pouvez l'associer aux instructions propres à l'agent concernant le moment où il doit marquer une pause et demander confirmation, ou à une règle d'automatisation. Une transition est l'un des nombreux points d'entrée possibles. Un agent peut également se déclencher lorsque :
une tâche est créée, ce qui permet de la trier dès ses débuts
une étiquette ou un champ est modifié, ou selon un calendrier défini par une règle d'automatisation
il s'exécute en arrière-plan pour des opérations de routine, telles que la rédaction de notes de version
Adaptez le contrôle au niveau de risque : laissez les tâches à faible risque s'exécuter automatiquement (une mise à jour de dépendance), avertissez un collaborateur des tâches à risque moyen (un changement de configuration partagée) et exigez une approbation pour les actions à haut risque ou irréversibles (intervenant sur l'environnement de production ou supprimant des données).
Déterminez quelles tâches relèvent de la propriété de l'agent : la décision concernant ce dont un agent est propriétaire précède la définition du point de contrôle. Confiez sans réserve les tâches à faible risque à un agent, préparez les tâches à fort impact pour qu'une personne les finalise, et réservez les décisions les plus cruciales à un humain. Définir le périmètre de la tâche est la première décision ; le point de contrôle sert à la faire respecter.
Donnez à vos agents leurs propres instructions : vous définissez comment un agent doit se comporter et faire avancer le travail, y compris quelles décisions il doit prendre et quand il doit s'arrêter et demander confirmation, afin qu'il suive les conventions de votre équipe plutôt que des paramètres par défaut génériques.
Passer en revue la sortie : comment valider ce que l'agent a produit ?
Le troisième garde-fou consiste à passer en revue le produit du travail lui-même, ce qui permet à une personne de repérer les sorties de mauvaise qualité et les hallucinations avant qu'elles ne soient déployées. Pour un agent de codage, il s'agit de la pull request qu'il ouvre.
Dans Jira : considérez la sortie produite par l'agent comme non fiable jusqu'à ce qu'une personne ou vos contrôles existants l'aient vérifiée, selon les mêmes critères que ceux que vous appliqueriez au code d'un nouveau contributeur. Le travail de l'agent est lié au ticket, et les changements de code arrivent sous forme de pull request qui suit votre processus habituel de revue et de merge. Rien de ce qu'un agent produit ne contourne la revue déjà effectuée par votre équipe.
Consultez le travail derrière la sortie : vous ne voyez pas uniquement le résultat final. Les sessions d'agent dans Jira vous offrent un emplacement unique pour voir ce qu'un agent a fait et pourquoi, afin qu'un réviseur dispose du contexte nécessaire pour comprendre la sortie au lieu de devoir la reconstituer.
Légende : Exemple : définissez des normes de revue de code par l'IA dans Bitbucket Cloud et appliquez-les automatiquement à chaque pull request.
Garder un historique permettant de rendre des comptes : qui a fait quoi, et quand ?
Le quatrième garde-fou est l'historique, la clé de la responsabilité. Il relie le travail de l'agent à son intention : ce que l'agent a fait, pourquoi, à quel ticket cela a servi, et qui l'a approuvé. C'est ce lien qui permet de retracer et de comprendre facilement les tickets lorsque quelque chose tourne mal.
Dans Jira : chaque agent opère sous une identité connue. Il peut s'agir soit de la personne qui a assigné ou configuré la tâche, agissant avec les autorisations de cette dernière, soit de son propre compte d'agent doté des autorisations que vous lui avez assignées. Dans les deux cas, l'historique relie chaque action à une identité responsable. L'historique consigne ce que l'agent a fait et qui en est responsable. Ces informations figurent dans l'historique du ticket, aux côtés des interventions humaines, les approbations étant associées au réviseur qui les a validées. Les administrateurs peuvent également surveiller les journaux d'audit afin de détecter toute activité inhabituelle.
Intégrez le travail de l'agent local au dossier. Le suivi des sessions d'agent permet de regrouper les activités des agents de codage IA locaux dans les IDE ou terminaux locaux, en les associant au ticket. Ainsi, le travail effectué en dehors de Jira est tout de même consigné dans un seul et même dossier traçable. Vous pouvez vous inscrire sur la liste d'attente ici.
Quelles sont les bonnes pratiques relatives aux garde-fous des agents ?
Adaptez l'accès d'un agent à sa tâche et étendez-le à mesure que la confiance s'installe (les agents utilisent vos autorisations Jira existantes).
Donnez aux agents des instructions claires sur la façon d'agir et sur le moment où faire une pause pour poser des questions.
Confiez d'abord aux agents des tâches à faible risque et réversibles avant de leur confier des tâches à fort impact.
Faites intervenir un humain dans les décisions importantes, avec des points de contrôle à plusieurs étapes, et pas seulement pour l'approbation finale.
Vérifiez la sortie générée par l'agent en suivant le même processus que pour les résultats générés par des humains (revue et merge des pull requests).
Consignez chaque action effectuée par un agent, en la reliant au ticket correspondant (historique et journal d'audit).
Assurez-vous que les agents agissent en tenant compte du contexte afin de maîtriser les coûts, car les dépassements de budget sont dus au fait que les agents avancent à l'aveuglette et refont le travail.

Atlassian a constaté qu'en s'appuyant sur Teamwork Graph, l'IA améliorait de 44 % la qualité des réponses, tout en réduisant de 48 % la consommation de jetons.
Quels sont les garde-fous pris en charge par Jira, et lesquels relèvent d'autres outils ?
Les garde-fous sont présents à plusieurs niveaux de votre stack d'agents. Jira gère la partie travail et accès ; les autres parties relèvent de votre fournisseur de modèle, de votre framework d'agents et de votre infrastructure d'intégration continue (CI).
Garde-fous appliqués par Jira | Garde-fous gérés ailleurs dans votre stack |
Délimiter l'accès des agents via les autorisations Jira et la configuration du projet | Filtrer ou modérer la sortie du modèle (c'est le fournisseur du modèle qui s'en charge) |
Conditionner le ticket à une approbation humaine lors d'une transition de workflow | Exécuter le modèle ou l'environnement d'exécution de l'agent (l'agent de codage Jira s'exécute dans une sandbox fournie par Atlassian ; les agents tiers s'exécutent dans leur propre framework) |
Enregistrer les actions des agents dans l'historique des tickets et dans les journaux d'audit administrateur | Bloquer toutes les injections de prompt (le filtrage est utile, mais rien ne permet de tout détecter ; Jira limite les dégâts si l'une d'elles parvient à passer) |
Définir l'exécution autonome ou soumise à approbation par tâche | Imposer des vérifications au niveau du code telles que des tests et des analyses de sécurité (ce que fait votre pipeline CI) |
Jira régit ce que les agents peuvent faire et enregistre ce qu'ils ont fait ; il vient compléter la sécurité au niveau du modèle et de l'environnement d'exécution, sans pour autant la remplacer.
Comment ajouter votre premier garde-fou d'agent dans Jira
Vous n'avez pas besoin d'un programme de gouvernance complet pour commencer. Un garde-fou vous permet de confier à un agent des tâches concrètes en toute responsabilité, en veillant à ce qu'une personne soit impliquée dans les décisions importantes, et d'élargir le champ d'action à mesure que la confiance s'installe.
Choisissez une tâche courante et réversible, comme un test instable ou une mise à jour de dépendance (cela limite le coût d'une erreur).
Exécutez l'agent avec les accès que vous accorderiez à un nouveau coéquipier, sans aller au-delà de ce qui est nécessaire à la réalisation de la tâche.
Ajoutez-le à une transition de workflow afin qu'une personne l'approuve au préalable (permet de détecter les actions inadaptées ou risquées).
Passez en revue la pull request selon votre processus habituel (cela permet de détecter les sorties de faible qualité ou les hallucinations).
Vérifiez que tout est enregistré sur le ticket (traçabilité si vous devez revenir en arrière).
Voici comment mettre en place un workflow permettant de déployer l'IA à grande échelle de manière responsable : de meilleures sorties pour les agents, un temps de vérification réduit et davantage d'autonomie. Vous pouvez ensuite étendre ce processus en toute sécurité.

Consultez notre Guide fiable sur la gouvernance responsable de l'IA, dans le cadre des Principes de la technologie éthique d'Atlassian.
Questions fréquentes sur les garde-fous des agents IA
Comment assurez-vous la sécurité des agents IA ?
Pour garantir la sécurité des agents IA, il faut contrôler leurs droits d'accès, exiger une approbation humaine pour les actions à fort impact et enregistrer toutes leurs activités, en adaptant la surveillance au niveau de risque de chaque tâche.
Comment Jira gère-t-il les agents IA ?
Jira gère les agents IA via les contrôles que votre équipe utilise déjà : les agents fonctionnent dans le cadre des autorisations et des workflows de Jira ; vous pouvez subordonner leur intervention à une approbation humaine lors d'une transition de workflow ; et leurs actions sont consignées dans l'historique des tickets et le journal d'audit.
Les agents IA dans Jira peuvent-ils exiger une approbation humaine ?
Oui. Vous pouvez ajouter un agent à une transition de workflow afin qu'un utilisateur humain examine et approuve la sortie avant que le ticket ne passe à l'étape suivante, et réserver l'autonomie aux tâches réversibles et à faible risque.
Qu'en est-il de l'injection de prompts avec des agents IA ?
Une injection de prompt est une entrée non fiable qui tente d'inciter un agent à effectuer des actions non souhaitées. Atlassian filtre les données transmises aux agents alimentés par Rovo afin de détecter les tentatives d'injection ; et comme aucun filtre n'est infaillible, des garde-fous à plusieurs niveaux prennent le relais : accès restreint, approbation humaine et piste d'audit complète.