Données, confidentialité et IA

En bref : toutes les données restent sur l’infrastructure Atlassian. L’éditeur ne les voit jamais.

Où vivent les données

Toutes les données de l’app sont conservées dans le stockage hébergé de Forge, sur l’infrastructure Atlassian, isolées par site. Il n’y a aucun service tiers, aucune analyse d’audience, aucun traçage et aucun flux de données externe, d’aucune sorte. Le stockage hébergé de Forge suit les réglages de résidence des données du produit hôte.

Ce que l’app enregistre

Par rappel : l’identifiant de compte de la personne propriétaire, la clé du ticket ou le texte JQL, la définition du déclencheur (y compris le texte de la condition IA le cas échéant), les canaux de notification, la langue de profil de la personne propriétaire, le statut et les horodatages. S’y ajoutent les notifications dans l’app, un journal d’audit par rappel et des compteurs d’usage des crédits IA. Le pool mensuel du site est compté de façon anonyme ; à côté, l’app tient un compteur par personne et par mois.

Une notification dans l’app contient l’objet, l’horodatage et le texte de la notification. Pour les déclencheurs de commentaire et d’IA, ce texte reprend un extrait du commentaire déclencheur, de 200 caractères au maximum. Cet extrait est exactement ce que la personne destinataire a de toute façon le droit de lire dans le ticket, et l’app revérifie cette autorisation à l’ouverture des notifications. En dehors de cet extrait, le contenu des tickets n’est pas copié dans le stockage de l’app.

Ce qui entre dans le périmètre de la résidence des données

Atlassian laisse la définition à l’éditeur de l’app et exige qu’il la publie. Pour HeadsUp, la réponse est courte.

Toutes les données de l’app entrent dans le périmètre. Tout ce que l’app enregistre, comme décrit plus haut, est conservé dans le stockage hébergé de Forge, sur l’infrastructure Atlassian, qui suit la région épinglée pour le produit hôte.

Rien n’est hors périmètre. L’app ne conserve rien en dehors du stockage hébergé de Forge et ne définit aucun flux de données propre vers l’extérieur.

Commentaires à visibilité restreinte

Les commentaires restreints à un rôle de projet ou à un groupe n’atteignent pas du tout HeadsUp. L’app fonctionne sous son propre utilisateur applicatif, et Jira ne distribue aucun événement pour un commentaire que cet utilisateur ne voit pas. Les notes internes dans Service Management arrivent en revanche, car l’app y dispose de la visibilité des agents. Pour tout ce qui arrive, HeadsUp n’enregistre, n’affiche et n’envoie jamais le texte : la notification, l’entrée de la boîte de réception et l’historique portent une phrase neutre à la place de l’extrait, et aucun commentaire automatique n’est écrit. Les rappels IA ignorent entièrement ces commentaires, leur texte n’atteint donc aucun modèle et aucun crédit n’est consommé. Une personne administratrice du projet peut délibérément ajouter l’utilisateur applicatif à un rôle restreint ; le commentaire déclenche alors un rappel, et la suppression de son contenu reste en place. Voir Installation et permissions.

Une limite mérite d’être connue. L’application réagit à l’événement de commentaire. Un commentaire écrit en clair puis restreint quelques secondes plus tard a déjà été distribué comme commentaire ouvert, et une restriction ultérieure ne rattrape pas un e-mail déjà parti.

Ce à quoi l’éditeur a accès

Rien de ce que l’app enregistre : le stockage hébergé de Forge est exploité par Atlassian et n’est pas lisible par l’éditeur. Les journaux d’exploitation de la plateforme sont délibérément tenus à l’écart des données personnelles et des contenus ; ils contiennent des identifiants techniques et des messages d’erreur, mais aucun texte de commentaire, aucune justification d’IA et aucun identifiant de compte complet.

Traitement par l’IA

Les rappels dotés d’une condition IA évaluent les nouveaux commentaires via l’API Forge LLMs : des modèles hébergés et exploités par Atlassian sur l’infrastructure Atlassian. Les textes des commentaires ne quittent pas la plateforme Atlassian. La politique d’utilisation acceptable d’Atlassian et sa modération IA s’appliquent. Il n’y a aucun coût d’IA pour l’organisation cliente ; l’usage des modèles est facturé à l’éditeur de l’app.

Chaque décision de l’IA est inscrite dans le journal d’audit du rappel, dans le stockage d’app propre au site, où chacun peut la consulter.

Les crédits IA en détail

• Pool mensuel par site : utilisateurs Jira sous licence × 20 (Standard) ou × 200 (Advanced) crédits IA, avec un pool minimum garanti pour les petits sites (100 et 500) et un plafond à 1 000 utilisateurs. Si un site dispose de plusieurs produits Jira, c’est le plus grand nombre d’utilisateurs qui compte, personne n’est donc compté deux fois.
• Tous les utilisateurs se partagent librement le pool, sur le même modèle qu’Atlassian Automation. La consommation est visible par tous dans l’app.
• Quand le pool est épuisé, les rappels IA sont en pause jusqu’au 1er du mois suivant. Toute personne dont un rappel IA cherche ensuite à se déclencher est prévenue une fois par mois, dans la boîte de réception et par e-mail ; celle qui n’en a aucun n’est pas prévenue. Toutes les autres fonctions continuent normalement.
• Maîtrise des coûts intégrée : les commentaires sont préfiltrés par la JQL avant tout appel à l’IA, les commentaires de moins de 15 caractères ne sont jamais évalués, et les commentaires écrits par des apps et des automatisations n’atteignent eux non plus aucun modèle.

Entretien automatique

Deux traitements planifiés évitent que les crédits IA partagés soient gaspillés. Aucun des deux ne supprime quoi que ce soit.

Quand un compte Jira est désactivé, un traitement quotidien met les rappels de cette personne en pause. Les surveillances de comptes partis continueraient sinon de tourner et de puiser dans les crédits IA partagés du site, et pour un déclencheur IA le crédit est consommé avant même l’appel au modèle. L’app ne met en pause que sur un compte explicitement désactivé ; si l’état ne peut pas être déterminé, le rappel est laissé tel quel. Réactiver le compte ne réactive volontairement pas les rappels : après une longue absence, les anciennes surveillances ne sont souvent plus souhaitées et se remettraient aussitôt à consommer des crédits IA. Chaque entrée concernée porte un bouton Réactiver, la personne décide donc de ce dont elle a encore besoin.

Les dates d’expiration sont vérifiées toutes les heures. Chacun peut donner une date d’expiration à ses rappels répétés et à ses alertes de filtre, et l’absence d’expiration est présélectionnée. Les règles expirées sont mises en pause et se prolongent d’un clic.

Conservation

Les notifications dans l’app et le journal d’audit n’ont pas de date d’expiration. Rien dans l’app ne les supprime de façon planifiée ; les deux traitements planifiés ci-dessus ne font que changer le statut des rappels. Ils restent dans le stockage d’app propre au site jusqu’à leur suppression par la fonction de suppression dans l’app, et au plus tard lorsque Atlassian supprime le stockage de l’app après la désinstallation.

Suppression et désinstallation

Chacun peut supprimer ses rappels un par un. Leur journal d’audit et les notifications personnelles qui s’y rapportent partent avec ; sur un rappel partagé, la boîte de réception de la personne propriétaire reste intacte. Une seule action dans l’app efface tout le reste : tous les rappels, la boîte de réception complète, le journal d’audit, les compteurs d’usage personnels et le marqueur de la fenêtre de bienvenue. Celle-ci réapparaît ensuite, c’est voulu. Après la désinstallation, Atlassian supprime le stockage de l’app selon la durée de rétention de la plateforme Forge (actuellement 28 jours). L’éditeur n’en conserve aucune copie.