Traitement des données : conservation et suppression
En vigueur le [date de publication]
| Application | TuneCraft : automatisation et nettoyage du site, une application Jira Cloud conçue sur Atlassian Forge |
|---|---|
| Fiche Marketplace | Pas encore inscrite. TuneCraft n’est pas encore sur le Marketplace d’Atlassian, et sa clé d’application sera ajoutée ici lorsqu’elle le sera. |
| Identifiant de l’application Forge | ari:cloud:ecosystem::app/facece90-dfd5-4792-9bff-6a5bd061a341 |
| Éditeur | Logiciels Plugincraft inc., société constituée en vertu des lois du Québec, Canada |
En bref
- Toutes les données que l’application stocke sont conservées dans Forge SQL, la base de données hébergée d’Atlassian pour les applications Forge, à l’emplacement de résidence des données de votre site Jira, et elles suivent le site.
- L’application n’envoie aucune donnée à Plugincraft ni à aucun autre service hors d’Atlassian : aucune donnée n’est donc détenue par un tiers à supprimer.
- Les analyses, les lectures et les registres sont conservés pour les durées du tableau ci-dessous. Une maintenance quotidienne retire ce qui a expiré.
- Lorsque l’application est désinstallée, Atlassian garde les données stockées pendant 30 jours, puis les supprime définitivement.
Où les données sont conservées
L’application stocke ses données dans Forge SQL, la base de données hébergée d’Atlassian pour les applications Forge. La base appartient à votre installation. Le stockage hébergé Forge prend en charge la résidence des données : il reste au même emplacement que le site Jira, et Forge le déplace lorsqu’un administrateur déplace le site. L’application n’a besoin d’aucun réglage propre pour cela, et ne garde aucune copie ailleurs. Elle n’utilise ni stockage clé-valeur ni stockage d’objets.
Ce que l’application crée dans Jira même, comme les tickets d’alerte et d’avis, est conservé dans Jira selon les règles de votre propre site. Leur texte est dans Jira, et non dans la base de l’application.
L’application ne déclare aucune sortie de données : il n’y a donc aucune donnée envoyée hors d’Atlassian dont on pourrait décrire la conservation ici. L’analyse automatique envoie des données vers l’application, depuis un expéditeur que le client exécute, et non l’inverse. L’expéditeur lit d’abord le texte réel des règles par l’API d’Atlassian, là où le client l’exécute : sur ses propres systèmes ou comme tâche planifiée dans ScriptRunner Cloud, une application de scripts d’un autre éditeur que le client a installée (voir la politique de confidentialité).
Chiffrement. Atlassian indique que la plateforme Forge utilise AES-256 pour chiffrer au repos les données stockées dans le stockage des applications Forge, et TLS 1.2 ou plus en transit. Voir Chiffrement au repos et en transit dans l’Aperçu de la sécurité, qui renvoie à la documentation d’Atlassian.
Ce qui est stocké et combien de temps
La liste est par type de données. La politique de confidentialité dit ce que chacun contient et pourquoi. Tout est dans Forge SQL.
| Données | Durée de conservation |
|---|---|
| Les analyses : pour chaque flux, son identifiant, son nom, son type de déclencheur, les identifiants de ses projets, son jour de création, les identifiants de compte de son propriétaire et de son acteur, une empreinte de sa structure, son score et ses constats; et, pour une analyse lancée par un administrateur Jira, la structure du flux dont chaque texte est remplacé par un marqueur, ainsi que les identifiants de comptes que ses étapes nomment | Les 24 dernières analyses et, tant qu’aucune d’elles n’a gardé ce que ses flux nomment, la dernière analyse qui l’a gardé. La maintenance quotidienne retire les plus anciennes, et une personne du niveau Gérer peut supprimer une analyse plus tôt dans la page Historique. Un flux conservé reste tant qu’une analyse conservée le nomme. |
| Ce que chaque flux utilise (des identifiants et des hachages à clé) | La dernière analyse qui a gardé ce que ses flux nomment, et celle en cours. La maintenance quotidienne les retire des analyses plus anciennes, et ceux d’une analyse supprimée partent avec elle. |
| Ce que chaque flux nomme que Jira n’a plus, d’après la lecture des flux cassés de l’outil Automatisation (des identifiants et des hachages à clé) | La lecture publiée en dernier, pour l’analyse qu’elle couvre. Une lecture plus récente la remplace, et ceux d’une analyse supprimée partent avec elle. La désactivation des vérifications en arrière-plan de l’outil Automatisation ne les retire pas. |
| Les nombres de gouvernance de chaque flux, et combien de ses textes JQL Jira a refusés (des nombres seulement) | La dernière analyse qui a gardé ce que ses flux nomment et celle en cours, comme ce que chaque flux utilise. Les nombres d’une analyse qui n’a gardé aucune référence restent aussi longtemps que l’analyse : les 24 dernières analyses, ou plus longtemps pour l’analyse gardée comme ci-dessus. |
| Les correctifs confirmés par des analyses : l’identifiant du flux, le constat et les étapes économisées | Conservés comme registre de ce qui a été économisé. Le nom du flux est retiré dès que l’analyse qui a confirmé le correctif n’est plus conservée. |
| Des nombres et des jours tirés des journaux d’audit de l’automatisation : exécutions, étapes, durée et issue des exécutions de chaque flux; exécutions et étapes du site par jour et par produit; et, d’un journal qui liste toutes les exécutions, l’heure de sa dernière exécution (une seule heure, sans flux, exécution ni personne à côté) | 400 jours, sauf cette heure, gardée seulement quand le journal atteint le jour de l’analyse et qui reste jusqu’à ce que l’analyse suivante d’un journal qui liste toutes les exécutions et finit le même jour ou plus tard la remplace. |
| La santé des exécutions : pour chaque flux, les exécutions de son journal d’audit le plus récent selon leur issue, et les jours de ses dernières exécutions (des nombres et des jours seulement) | Une ligne par flux, remplacée par chaque journal plus récent et retirée quand le flux n’est plus dans la dernière analyse et que sa ligne n’a pas été remplacée depuis 90 jours. Les jours que couvraient les journaux : 400 jours. |
| Les paramètres : accès à l’application, forfait et allocation, réglages des alertes, domaines de courriel de l’organisation, conventions de nommage, les deux nombres de jours après lesquels Laissés de côté compte un sprint comme laissé de côté, cibles (avec l’identifiant de compte de l’administrateur Jira qui a fixé chacune), consignes pour une vérification et valeurs du modèle de coût, chaque paramètre étant accompagné de l’identifiant de compte de la personne qui l’a enregistré en dernier (un administrateur Jira ou, pour le modèle de coût, une personne du niveau Gérer) | Jusqu’à ce qu’un administrateur Jira (ou, pour le modèle de coût, une personne du niveau Gérer) les change, ou que l’application soit désinstallée. Une cible : jusqu’à ce qu’un administrateur Jira la retire, et 400 jours après qu’elle a été atteinte. |
| Les alertes envoyées (leur objet, quand, et la clé du ticket) et les identifiants de compte des personnes que les alertes mentionnent | Alertes : 400 jours. Les personnes mentionnées : tant qu’elles sont choisies. |
| Les avis aux propriétaires envoyés : le flux, quand, la clé du ticket, ainsi que les identifiants de compte de la personne avisée et de l’expéditeur | Un an. |
| La liste À faire : l’état de chaque action, l’identifiant de compte de la personne qui l’a fixé et la clé du ticket qui y est lié | 400 jours après qu’une lecture a confirmé une action terminée, ou dès qu’aucune lecture n’a vu son problème depuis 400 jours. Une action ignorée, ou marquée terminée sans confirmation d’une lecture, reste tant qu’une lecture montre encore le problème. |
| La liste d’exclusion et la liste de surveillance : des identifiants Jira, le jour, le code de raison et l’identifiant de compte de la personne qui l’a fait | Jusqu’à l’arrêt ou à la fin des jours, ou jusqu’à ce que Jira n’ait plus l’objet; une exclusion pour un flux disparaît aussi dès que la dernière analyse n’a plus le flux et que l’exclusion a plus de 30 jours. Une surveillance disparaît aussi dans la journée lorsque les vérifications de son outil (Champs, Espaces ou Filtres) sont désactivées. Au plus 500 lignes par outil pour la liste d’exclusion et 100 pour la liste de surveillance. |
| Les sièges d’un export d’utilisateurs téléversé : identifiant de compte, dernier jour d’utilisation et indication d’administrateur du produit (les noms et les adresses courriel restent dans le navigateur) | Jusqu’à ce qu’un administrateur Jira téléverse un nouveau fichier ou le retire, et au plus 90 jours après le téléversement. |
| Les lectures de la configuration de Jira pour les outils de nettoyage qui ont des vérifications en arrière-plan (Limites, Champs, Espaces, Filtres, Schémas, Workflows) : identifiants, nombres, jours, vocabulaire propre à Jira et hachages à clé. Personnes n’a pas de vérifications à lui : il se sert de ce que gardent Filtres, Schémas et Espaces. Étiquettes et Tableaux ne gardent aucune lecture | Tant qu’un administrateur Jira garde les vérifications en arrière-plan de l’outil. Retirées lorsque Jira n’a plus l’objet, et dans la journée qui suit la désactivation des vérifications. Limites fait exception : ses derniers nombres, par identifiant Jira et sans aucun nom, restent tant que Jira a l’espace ou le schéma, même après la désactivation des vérifications. Une autre exception : l’historique des noms d’un champ personnalisé (des hachages à clé, servant à réparer un champ renommé dans un filtre) est gardé 400 jours après la dernière fois que le nom a été vu, même pour un champ que Jira a supprimé, et retiré dans la journée qui suit la désactivation des vérifications de Champs. |
| Les historiques de ces lectures : chaque nombre aux jours où il a changé, l’historique des changements (type, identifiant Jira et jour) et les points Jira par jour | 400 jours. |
| Le registre des changements qu’un outil de nettoyage a faits dans Jira : qui, quand, de quel type, combien d’objets, le résultat et jusqu’à quand on peut l’annuler; pour un statut supprimé, un hachage à clé de son nom et de sa description; pour un workflow ou un schéma de workflow supprimé, combien de workflows ou de statuts la suppression a laissés inutilisés (des nombres); pour un filtre réparé, des hachages à clé de son JQL avant et après | Le changement : 400 jours. Chacun de ses objets, avec ce dont une annulation a besoin : 30 jours. Un changement resté ouvert, que personne n’a terminé ni arrêté, est fermé par la maintenance quotidienne 30 jours après son début (une semaine pour une fusion de schémas ou pour un changement que la page Modifications de son outil ferme, une heure pour la suppression d’une copie de schéma de permissions ou le retrait d’un octroi ouvert), et ses objets disparaissent comme ci-dessus. |
| L’ancienne et la nouvelle étiquette d’un changement d’étiquette (le texte des étiquettes, 255 caractères au plus chacune) et les identifiants des tickets qu’il a modifiés | 30 jours, pour qu’Annuler et Poursuivre n’exigent aucun fichier. Ensuite supprimées par la maintenance (les identifiants de tickets d’un changement resté ouvert disparaissent 30 jours après avoir été enregistrés, une fois que la maintenance a fermé le changement). Jamais écrites dans un journal. |
| La fusion d’un champ dans un autre, et chaque préparation du champ à garder (options, espaces d’un contexte, écrans ajoutés) : les identifiants des deux champs personnalisés, des nombres, et les identifiants des tickets, options, espaces ou écrans touchés, chacun avec un code pour la réponse de Jira. Jamais une valeur, un nom de champ, le texte d’une option ni la clé ou le résumé d’un ticket | L’exécution et ses nombres : 400 jours, avec le registre du changement. Les identifiants des tickets, options, espaces et écrans : 30 jours. Jamais écrits dans un journal. |
| Où en est un changement d’étiquette : les hachages à clé de l’ancienne et de la nouvelle étiquette, son état et ses nombres, et l’identifiant du dernier ticket traité | 400 jours, avec le registre du changement. L’identifiant du dernier ticket traité : effacé à l’arrêt de l’exécution et dans tous les cas après 30 jours. |
| Les lectures des pièces jointes : nombres par espace, type de fichier et mois, et les 100 tickets ayant le plus d’octets de pièces jointes, par identifiant | Une lecture d’espaces choisis : 90 jours. Une lecture de tout le site : la dernière terminée. |
| La façon dont une exécution d’archivage ou d’arriéré périmé a été lancée : son mode et, pour un arriéré périmé, les identifiants d’espaces, un jour et un identifiant de statut (les tickets de l’exécution sont dans le registre des changements ci-dessus) | Jusqu’à la fin de l’exécution. Pour une exécution que personne ne termine ni n’arrête : jusqu’à 400 jours après sa dernière écriture. Les identifiants de ses tickets disparaissent comme dans le registre des changements ci-dessus. |
| L’analyse automatique : une empreinte à sens unique du secret de la clé; les parties d’un envoi en cours, qui contiennent les flux tels que l’expéditeur les a envoyés (noms, identifiants de compte des propriétaires, des acteurs et des personnes que les étapes nomment, étapes caviardées); un registre de chaque envoi en cours ou tout juste terminé (son identifiant, son heure de début, son état et des nombres); et le dernier résultat (des nombres) | L’empreinte de la clé, jusqu’à ce qu’un administrateur Jira remplace la clé ou la désactive. Les parties d’un envoi sont supprimées à sa fin; la maintenance quotidienne retire celles d’un envoi qui ne se termine jamais dès qu’il a une heure (trois heures si l’application avait commencé à l’enregistrer, 26 heures si l’expéditeur a demandé à le garder ouvert). Le registre part avec elles. Le dernier résultat reste jusqu’à l’envoi suivant. |
| Les nombres d’exécutions et d’étapes par mois mesurés pour certains flux (saisis par une personne du niveau Gérer, ou comptés à partir d’un journal d’audit) : l’identifiant du flux, les nombres, leur provenance et le jour de la mesure | Jusqu’à ce qu’une personne du niveau Gérer les retire. La maintenance quotidienne retire un nombre 90 jours après le jour de la mesure lorsque la dernière analyse n’a plus le flux. |
| Les liens entre les flux d’une analyse (lequel peut démarrer lequel, copies, déclencheurs partagés, boucles), par identifiant de flux, et l’avancement de la comparaison d’une analyse avec la précédente (identifiants d’analyses, un identifiant de flux, des nombres) | Retirés avec leur analyse. |
| Pour un essai : l’identifiant du seul flux pour lequel Optimiser peut préparer un correctif, une empreinte de sa structure et l’analyse dont il a été choisi; et combien d’objets chaque outil de nettoyage a modifiés | Tant que l’application est installée : rien ne les retire plus tôt. |
| La santé du site : pour chaque jour où l’accueil des outils a été ouvert, les nombres entiers des cartes des outils (objets et constats comptés par outil et par gravité, et part de la limite la plus proche) | 400 jours. |
| La comptabilité des vérifications en arrière-plan : pour chaque vérification, son état, où elle en est (identifiants Jira et positions), des nombres, des points Jira et des heures, et le code court de son dernier échec; et, pour chaque jour, ce qu’elle a fait (passages terminés, essais échoués, points dépensés). Aucun nom ni identifiant de compte | La ligne d’une vérification reste tant que la vérification existe. Les lignes de chaque jour : 14 jours. |
| Les identifiants de comptes Atlassian que l’application stocke, avec la date de leur dernier stockage et de leur dernier signalement à Atlassian | Tant qu’un enregistrement détient l’identifiant. Un identifiant qu’Atlassian signale comme fermé est effacé de tous les enregistrements, et l’identifiant seul est gardé environ un cycle de signalement de plus (7 jours, sauf si Atlassian en fixe un autre). |
| Les journaux de l’application | Voir Journalisation des données. |
L’application stocke des identifiants de comptes Atlassian pour consigner qui a lancé une analyse, qui a enregistré un paramètre, à qui appartient ou qui exécute un flux, qui a été avisé et qui a fait un changement. Elle ne stocke ni noms ni adresses courriel; elle les demande à Jira lorsqu’elle doit les afficher. Les textes écrits par des personnes qu’elle conserve sont les noms des flux et les textes du tableau : l’ancienne et la nouvelle étiquette d’un changement d’étiquette (30 jours), ainsi que les paramètres, les conventions de nommage et les consignes saisis par un administrateur Jira.
Comment les données sont supprimées
- Supprimer une analyse. Une personne du niveau Gérer (un administrateur Jira, ou un membre d’un groupe qu’un administrateur Jira a autorisé à ce niveau) peut supprimer n’importe quelle analyse dans la page Historique, ce qui retire ses flux, ses lectures et ses structures conservées. Une analyse que repousse une plus récente hors des 24 dernières est retirée par la maintenance quotidienne.
- Maintenance quotidienne. Une tâche quotidienne retire ce qui a expiré ou que plus personne ne peut atteindre, par lots, en reprenant là où elle s’était arrêtée la veille. Les administrateurs Jira peuvent voir la dernière exécution dans la page Maintenance et la lancer à la demande.
- Désactiver les vérifications d’un outil. Lorsqu’un administrateur Jira désactive les vérifications en arrière-plan d’un outil, ses lectures sont retirées dans la journée, de même que les lignes de la liste de surveillance de ses champs, espaces ou filtres. Les exceptions sont dans le tableau ci-dessus.
- Comptes fermés. L’application garde des identifiants de comptes Atlassian, ni noms ni adresses courriel. Elle signale à Atlassian les identifiants qu’elle stocke une fois par cycle de signalement, comme Atlassian l’exige des applications. Lorsqu’Atlassian indique qu’un compte a été fermé, une exécution quotidienne efface cet identifiant de tous les enregistrements qui le contiennent, généralement le jour même. Dans un flux conservé, l’identifiant et son marqueur sont retirés. Les comptes désactivés sont laissés tels quels.
- Changements dans Jira. Ce qu’un administrateur Jira supprime dans Jira par l’application (un champ, un filtre, un statut, etc.) est supprimé par Jira, selon ses propres règles. Là où Jira a une corbeille ou des archives, l’application les utilise. Là où il n’en a pas, l’application remet d’abord à l’administrateur un fichier d’enregistrement à sauvegarder.
- Désinstallation. L’application n’a aucun code qui s’exécute à la désinstallation et ne garde aucune copie hors de l’installation. Lorsqu’un administrateur désinstalle l’application, Atlassian supprime d’abord de façon logicielle les données qu’elle a stockées pour le site, les garde 30 jours, puis les supprime définitivement. Une réinstallation est une nouvelle installation, mais une demande faite à Atlassian dans les 21 jours suivant la désinstallation peut la relier aux anciennes données. Un administrateur peut aussi garder l’application jusqu’à la fin de la période de facturation ou d’essai, plus 60 jours, avant son retrait, ou la retirer tout de suite. Ces délais sont ceux d’Atlassian : voir la page d’Atlassian pour les administrateurs de site et sa page sur le cycle de vie des données du stockage hébergé Forge (en anglais), qui prévalent si elles changent.
- Copies qu’Atlassian garde. Lorsque l’application supprime des données pendant qu’elle est installée, Atlassian les retire du stockage principal et garde une copie supprimée de façon logicielle pour qu’une suppression accidentelle puisse être annulée. Atlassian détruit cette copie, et les sauvegardes faites avant la suppression, à la fin de sa période de conservation.
- Suppression du site. Lorsqu’un site Jira est supprimé, le site et les données de l’application restent récupérables pendant la période de suppression logicielle d’Atlassian. Une fois le site retiré définitivement par Atlassian, les données de l’application sont supprimées aussitôt.
- Fichiers d’enregistrement et exportations. Un fichier d’enregistrement, un téléchargement de constats ou un fichier de correctif est enregistré à l’endroit choisi par la personne, et Plugincraft ne le reçoit jamais. Un fichier d’enregistrement contient les noms de ce qu’il consigne : il faut donc le garder en lieu sûr. Supprimer des données dans l’application ne supprime pas les fichiers déjà enregistrés.
- Votre export d’automatisation et l’export d’utilisateurs. Les fichiers sont lus dans le navigateur de l’administrateur. L’application ne garde que ce que le tableau ci-dessus énumère.
Demandes concernant les renseignements personnels
Les données que vous avez créées dans l’application sont dans votre site Jira : vos administrateurs Jira peuvent donc les consulter et les supprimer directement. Pour des questions ou des demandes concernant les renseignements personnels que Plugincraft détient elle-même, consultez la politique de confidentialité de ce site Web ou écrivez au président de Logiciels Plugincraft inc., qui est la personne responsable de la protection des renseignements personnels, à info@plugincraft.ca. Pour la politique propre à l’application, voir la politique de confidentialité de TuneCraft.