Politique de confidentialité de TuneCraft

En vigueur le [date de publication]

En bref

TuneCraft fonctionne sur Atlassian Forge et garde ses données dans le stockage Forge d’Atlassian pour votre site Jira, à l’emplacement de résidence des données de votre site. Elle ne déclare aucun accès réseau externe et n’envoie rien hors d’Atlassian.
Plugincraft ne reçoit aucune des données que l’application lit ou garde. Ce qu’elle peut lire de l’application est technique : les journaux de l’application et les statistiques d’utilisation qu’Atlassian montre à un éditeur pour chaque site. Comme pour toute application payante, le Marketplace d’Atlassian lui donne aussi votre licence et ses coordonnées. Un administrateur peut choisir de nous envoyer un paquet de soutien.
TuneCraft ne stocke aucune adresse courriel ni aucun texte des réglages de vos flux d’automatisation. Les textes écrits par des personnes qu’elle conserve sont les noms des flux, ce qu’un administrateur Jira saisit comme paramètre et, pendant 30 jours, l’ancien et le nouveau texte d’un changement d’étiquette.
Si un administrateur Jira active l’analyse automatique, un expéditeur que le client exécute envoie les flux caviardés au seul déclencheur Web de l’application, avec une clé. La section 6 dit ce qu’il envoie, ce que l’application garde et qui détient la clé.
Nous ne vendons pas de renseignements personnels, ne les utilisons pas pour de la publicité et ne les utilisons pas pour entraîner un modèle.
La sécurité, la journalisation, le traitement des données, l’IA et l’entente de traitement des données sont dans le centre de confiance.

Cette politique explique ce que TuneCraft : automatisation et nettoyage du site (« TuneCraft »), une application pour Jira Cloud conçue par Logiciels Plugincraft inc. (« Plugincraft », « nous »), fait des données. Elle couvre l’application seulement. La politique de confidentialité d’Atlassian couvre Jira lui-même, et la politique de confidentialité de ce site Web couvre plugincraft.ca et le soutien que nous offrons.

Logiciels Plugincraft inc. (en anglais, Plugincraft Software Inc.) est une société par actions constituée le 26 octobre 2026 en vertu de la Loi sur les sociétés par actions (RLRQ, chapitre S-31.1) du Québec. Son numéro d’entreprise du Québec (NEQ) est le 1182711235. Nous respectons la Loi sur la protection des renseignements personnels dans le secteur privé du Québec et, lorsqu’elle s’applique, la Loi sur la protection des renseignements personnels et les documents électroniques (LPRPDE) du Canada.

À qui s’adresser

Le président de Logiciels Plugincraft inc. est la personne responsable de la protection des renseignements personnels. Pour toute question, demande ou plainte concernant vos renseignements personnels, écrivez au président à info@plugincraft.ca. Indiquez « Protection des renseignements personnels » en objet.

Rôles

Votre organisation décide de la façon dont TuneCraft est utilisée et est la responsable du traitement des renseignements personnels qu’elle contient. Plugincraft fournit le logiciel qui traite ces données pour votre compte, à titre de sous-traitante. Notre entente de traitement des données en fixe les conditions. Atlassian héberge l’application sur sa plateforme et en est le seul sous-traitant (voir Sous-traitants).

1. Ce que TuneCraft lit

Sauf indication contraire, l’application lit Jira en tant que la personne qui l’utilise, avec les droits Jira propres à cette personne.

Votre export d’automatisation. Un administrateur Jira, ou un membre d’un groupe qu’un administrateur Jira a autorisé au niveau Gérer, choisit le fichier d’export dans son navigateur, qui le lit. Un administrateur de projet voit les flux de son propre projet, mais ne peut pas lancer d’analyse. Chaque valeur que des personnes ont écrite dans les réglages d’un flux (JQL, adresses et en-têtes de requêtes Web, adresses courriel, valeurs intelligentes, noms de champs personnalisés, valeurs comparées, commentaires et secrets) est remplacée dans le navigateur par un marqueur fabriqué avec une clé, et n’atteint jamais l’application. La seule exception est l’identifiant d’un compte Atlassian que les étapes d’un flux nomment (un responsable, un observateur, un destinataire, un client Jira Service Management) : pour une analyse lancée par un administrateur Jira, il est conservé à côté du flux, signalé à Atlassian et effacé à la fermeture du compte.
Ce qu’un expéditeur que vous exécutez envoie. Si un administrateur Jira active l’analyse automatique, le déclencheur Web de l’application reçoit ce que l’expéditeur lui envoie : pour chaque flux, son identifiant, son nom, les identifiants de compte de son propriétaire et de son acteur, les identifiants de ses projets, ses étapes dont chaque texte est remplacé par un marqueur, les identifiants de compte que ces étapes nomment, des identifiants Jira, des hachages à clé et des nombres. L’application ne lit rien dans Jira pour cela. Voir la section 6.
Le JQL de vos flux, et les tickets qu’ils traiteraient. Après une analyse, le navigateur de la personne qui l’a lancée envoie le JQL de chaque flux, et la recherche de chaque flux planifié, au Jira du site d’où vient le flux, en tant que cette personne. Jira dit s’il accepte le JQL et combien de tickets la recherche trouve maintenant. Un flux issu de l’export d’un autre site n’est pas envoyé. L’application ne garde que des nombres : le nombre trouvé, et combien de JQL d’un flux Jira a refusés ou n’a pas pu vérifier. Jamais le JQL ni les mots de Jira.
Qui vous êtes et ce que vous pouvez faire. Quand vous ouvrez TuneCraft, elle demande à Jira si vous êtes administrateur Jira ou administrateur de projet, et à quels groupes vous appartenez.
Les noms, tels que Jira vous les montre. Les pages demandent à Jira les noms des personnes, champs, statuts, espaces, versions, composants, types de tickets, groupes, rôles, schémas, filtres, tableaux de bord, tableaux et sprints qu’elles affichent, et cherchent dans Jira un nom que vous saisissez. Ils vous sont montrés et jamais stockés. Une adresse courriel que Jira renvoie avec une personne est écartée.
Ce que vos flux nomment, et si c’est encore là. Une fois par jour, lorsqu’un administrateur Jira a activé les vérifications en arrière-plan de l’outil Automatisation, l’application lit, en son propre nom, la configuration du site que vos flux nomment (champs et corbeille des champs, statuts, espaces, versions, composants, types de tickets, priorités, résolutions, types de liens et filtres) et si le propriétaire et l’acteur de chaque flux, ainsi que chaque compte que les étapes d’un flux conservé nomment, sont toujours actifs (les acteurs des flux activés sont redemandés chaque jour, les autres comptes chaque semaine). Elle ne lit aucun ticket. Elle garde ce qui est cassé, par identifiants Jira ou hachages à clé, et la dernière réponse pour chaque compte (actif ou non, et quand) à côté de son identifiant de compte.
La configuration et les nombres de votre site, pour les outils de nettoyage. Lorsqu’un administrateur Jira active les vérifications en arrière-plan d’un outil, l’application lit Jira en son propre nom, en arrière-plan, dans un budget de points Jira : de la configuration et des nombres seulement, jamais un ticket. Les outils sont Limites, Champs, Espaces, Filtres, Schémas et Workflows. L’outil 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 de votre configuration : ils lisent Jira, en tant qu’administrateur Jira, quand cet administrateur a leurs pages ouvertes. (Pièces jointes et Archivage lisent des tickets, en tant qu’administrateur Jira : voir plus bas.) Ils lisent, par exemple, les espaces avec leur dernière mise à jour, les champs personnalisés avec ce que Jira dit de leur utilisation, les filtres et tableaux de bord avec leur propriétaire, leur dernière utilisation et leur type de partage, les schémas de permissions et leurs octrois, les workflows, et les décomptes approximatifs de tickets de Jira. Les noms sont lus en mémoire. Ce qui est conservé, ce sont des identifiants, des nombres, des jours, le vocabulaire propre à Jira et des hachages à clé; le JQL d’un filtre n’est gardé que sous forme de hachage à clé. Les pages des outils dans le manuel énumèrent ce que chacun conserve. Là où l’application n’a pas le droit de lire quelque chose elle-même, la page ouverte d’un administrateur Jira le lit, en tant que cet administrateur.
La fusion de champs. Pour fusionner un champ personnalisé dans un autre, l’outil Champs lit les contextes, les options et les écrans des deux champs, ainsi que les tickets qui ont une valeur, en tant qu’administrateur Jira qui travaille dans la page. Pour copier, il lit les deux valeurs d’un ticket et écrit la seconde, un ticket à la fois, sans les courriels de notification de Jira; les valeurs restent dans la mémoire de l’application les secondes entre les deux et ne sont jamais stockées ni écrites dans un journal.
Les changements que vous faites avec TuneCraft. Lorsqu’un administrateur Jira confirme un changement dans un outil de nettoyage, l’application relit les objets dans Jira et fait le changement en tant que cet administrateur : le journal d’audit de Jira les montre donc. Une annulation se fait de la même façon. Les changements sont : le propriétaire, le nom, le JQL (la réparation de filtres, qui écrit l’identifiant d’un champ à la place d’un nom que Jira n’accepte plus, en tant que propriétaire du filtre, lorsque ce propriétaire est la personne qui confirme; prendre un filtre à son propriétaire pour le réparer n’est pas encore offert) ou le partage d’un filtre ou d’un tableau de bord (retrait du partage avec n’importe qui sur le Web, avec toute personne connectée ou avec un espace que Jira n’affiche plus); les valeurs d’un champ personnalisé copiées dans un autre (Fusionner des champs), après la préparation du champ à garder (options, espaces d’un contexte et écrans qui lui sont ajoutés); un champ personnalisé mis à la corbeille de Jira, restauré ou supprimé, et les options d’un champ à sélection désactivées ou activées; un espace, une version ou un composant; un schéma de permissions ou un rôle de projet; un statut, un workflow ou un schéma de workflow; un sprint (renommé, fermé avec ses tickets ouverts ajoutés au sprint suivant ou à un nouveau sprint, ou supprimé) ou un tableau; des espaces mis sur un autre schéma d’écrans par type de ticket; des tickets archivés, restaurés ou déplacés vers un autre statut; une étiquette renommée, fusionnée ou retirée; des pièces jointes supprimées; et des personnes retirées d’un groupe. Certains changements ne s’annulent pas (la suppression d’une pièce jointe, d’un filtre, d’un tableau de bord, d’un statut, d’un workflow, d’un schéma de workflow, d’un rôle de projet, d’une copie de schéma de permissions, d’une version, d’un composant, d’un tableau ou d’un sprint; la fermeture d’un sprint; la suppression définitive d’un champ; et le déplacement de tickets vers un autre statut) et la page le dit avant de demander. Avant de supprimer ou de renommer un objet (un filtre, un tableau de bord, un statut, un workflow, un schéma de workflow, un rôle de projet, une copie de schéma de permissions, une version, un composant, un tableau, un sprint, un champ à supprimer définitivement ou une pièce jointe), elle lit ce qu’un fichier d’enregistrement contient et le transmet au navigateur de l’administrateur, qui sauvegarde le fichier sur son ordinateur. L’application n’en garde rien.
Les étiquettes. Pour renommer, fusionner ou retirer une étiquette, l’application lit la liste des étiquettes du site et le décompte approximatif de Jira des tickets qui portent chacune de celles qui sont affichées, et cherche les tickets qui portent l’étiquette choisie. Pour la changer, elle modifie leurs étiquettes, en tant qu’administrateur Jira qui confirme et sans les courriels de notification de Jira. Elle garde l’ancienne et la nouvelle étiquette, ainsi que les identifiants des tickets modifiés, pendant 30 jours pour que le changement puisse être annulé ou poursuivi sans fichier. Elle garde aussi, pendant 400 jours, les étiquettes sous forme de hachages à clé et les nombres, et, tant que l’exécution est ouverte et 30 jours au plus, l’identifiant du dernier ticket traité.
Les pièces jointes. Pour totaliser l’espace que prennent les pièces jointes, l’outil Pièces jointes cherche les tickets qui ont des pièces jointes, en tant qu’administrateur Jira dont la page est ouverte : dans les espaces que cet administrateur choisit ou, une fois qu’un administrateur Jira a activé la lecture de tout le site, dans chaque espace qu’il peut parcourir, un espace à la fois, en reprenant à la visite suivante. Elle lit la taille, le type, le nom de fichier et la date de chaque pièce jointe. Elle compare les noms de fichiers en mémoire pour trouver les copies et n’en garde aucun. Elle garde des nombres et des tailles par espace, type de fichier et mois, les identifiants des 100 tickets dont les pièces jointes prennent le plus de place et, pour une lecture d’espaces choisis, l’identifiant de compte de l’administrateur Jira qui l’a lancée. Les noms des espaces et les clés des tickets sont lus dans Jira quand ils sont affichés. Pour supprimer des pièces jointes, voir « Les changements que vous faites avec TuneCraft ».
L’archivage. Pour archiver de vieux tickets ou fermer un arriéré périmé, l’outil Archivage cherche des tickets en tant qu’administrateur Jira qui l’utilise, par un filtre Jira que cet administrateur choisit ou par un JQL qu’il saisit, et montre un nombre, un échantillon et les espaces où ils se trouvent. L’échantillon est montré à cet administrateur et jamais stocké. L’administrateur sauvegarde un fichier d’enregistrement, avec les clés et les résumés, avant que quoi que ce soit change. Quand il confirme, l’application archive les tickets, les désarchive à l’annulation, ou les déplace vers un statut qu’il a choisi (un déplacement ne s’annule pas), par lots et en tant que cet administrateur. Pour un arriéré périmé, elle revérifie chaque lot dans Jira juste avant d’écrire. L’application garde les identifiants des tickets et leur état pendant 30 jours après la fin de l’exécution, et les nombres de l’exécution et l’identifiant de compte de l’administrateur pendant 400 jours. Jusqu’à la fin de l’exécution, elle garde aussi la façon dont elle a été lancée : son mode et, pour un arriéré périmé, les identifiants d’espaces, un jour et un identifiant de statut. Si personne ne termine ni n’arrête une exécution, la maintenance quotidienne la ferme 30 jours après son début, et les identifiants des tickets disparaissent 30 jours après avoir été enregistrés; la façon dont elle a été lancée reste jusqu’à 400 jours après sa dernière écriture. Elle ne garde jamais le JQL d’un filtre ni la clé, le résumé ou le texte d’un ticket.
Les membres de groupes, et les personnes désactivées. Dans la page Groupes, l’application demande à Jira les 50 premiers membres de chaque groupe à qui un schéma de permissions accorde quelque chose, et les membres d’un groupe (jusqu’à 500) quand vous cherchez ses personnes désactivées. Ils vous sont montrés et jamais stockés. Si vous retirez des personnes désactivées d’un groupe, l’application les retire en tant que vous et garde, pendant 30 jours, leurs identifiants de compte et l’identifiant Jira du groupe pour que vous puissiez les y remettre.
Les enregistrements d’audit de Jira. Lorsqu’un administrateur Jira appuie sur « Qui l’a fait » dans la page Historique des changements, l’application lit les enregistrements d’audit de Jira pour les jours qu’il a choisis, en tant que cet administrateur. Ils lui sont montrés et jamais stockés.
Ce qu’exige un type de ticket. Dans les formulaires qui créent des tickets, l’application demande à Jira quels champs un type de ticket exige dans l’espace que vous avez choisi. Elle vous les montre et les garde en mémoire jusqu’à une minute. Dans la page À faire, les valeurs qu’un administrateur Jira saisit ou choisit passent par l’application en route vers Jira, qui crée les tickets en tant que cet administrateur. Elles ne sont jamais stockées ni journalisées.
Les tickets près des plafonds de Jira. Lorsqu’un administrateur Jira ouvre la page de l’outil Limites sur les tickets près des plafonds, au plus une fois par jour pour le site, l’application lit les rapports de Jira sur les tickets qui dépassent les plafonds ou en sont proches, et cherche ces tickets par identifiant pour écarter ceux qui sont terminés. Ils sont montrés à cet administrateur seulement et jamais stockés. L’application garde combien il y en a pour chaque plafond, ainsi que l’identifiant de compte de cet administrateur avec le jour.
Un export d’utilisateurs, pour les sièges payants. Dans la page Sièges, un administrateur Jira choisit l’export d’utilisateurs d’Atlassian dans son navigateur, qui le lit. Seuls l’identifiant de compte de chaque siège payant, le dernier jour où la personne a utilisé le produit et l’indication d’administrateur du produit parviennent à l’application. Les noms et les adresses courriel restent dans le navigateur.
L’adresse de votre site. Avant de créer une alerte, l’application demande à Jira l’adresse de votre site, pour lier l’alerte à la page Utilisation de TuneCraft. Elle n’est jamais stockée.
Votre licence. L’application lit la licence de votre site pour TuneCraft dans le contexte qu’Atlassian transmet avec chaque requête.

2. Ce que TuneCraft stocke, et pourquoi

L’application stocke ce qui suit dans le stockage hébergé Forge d’Atlassian pour votre site. Les noms et les textes qu’une ligne n’énumère pas ne sont pas stockés.

Données	Pourquoi
Pour chaque flux analysé : son identifiant, son nom, son type de déclencheur, les identifiants de ses projets, son jour de création, le réglage de Jira pour ses courriels d’échec, pour un flux planifié ses exécutions par mois selon son calendrier (estimées), les identifiants de compte Atlassian de son propriétaire et de son acteur, une empreinte de sa structure, son score et ses nombres d’étapes estimés	Pour lister les constats par flux, aviser les propriétaires et reconnaître le flux dans les analyses suivantes
Pour chaque analyse : l’identifiant de compte de la personne qui l’a faite (ou l’application, pour une analyse automatique), quand, et ses totaux	Pour montrer l’historique des analyses
Pour une analyse lancée par un administrateur Jira : la structure de chaque flux (ses étapes, leur ordre et leurs réglages), chaque texte remplacé par un hachage à clé; en clair seulement des nombres, des vrai ou faux, les mots propres de l’export (le cron d’un calendrier avancé compris), les noms de champs propres à Jira, les identifiants de projets, ainsi que la fréquence, le début et la fin d’un calendrier de base. À côté, les identifiants de comptes que ses étapes nomment	Pour que les administrateurs Jira puissent optimiser un flux ou tous les flux à la fois, et suivre un flux d’une analyse à l’autre sans rechoisir l’export
Pour chaque flux de la dernière analyse terminée, et de celle en cours : ce qu’il utilise (les champs, options, statuts, projets, versions, composants, types de tickets, priorités, résolutions, types de liens, étiquettes, filtres et groupes qu’il nomme), chacun par identifiant Jira ou par hachage à clé de son nom, et comment il l’utilise; des nombres pour la gouvernance (requêtes Web, identifiants de connexion, adresses courriel fixes et celles hors des domaines de votre organisation, si un flux planifié fait une recherche et combien de tickets elle trouve, un propriétaire manquant, un acteur qui est une personne); ce qu’il nomme que Jira n’a plus; combien de ses JQL Jira a refusés. Jamais une adresse, un hôte, un en-tête, une valeur ni un texte de JQL. Un hachage à clé est un pseudonyme, et non un secret pour qui détient la base de données : la clé est conservée dans le même stockage, si bien qu’on peut retrouver un nom court en essayant des candidats. Une valeur qui ressemble à une personne n’est jamais hachée dans cet enregistrement	Pour que les administrateurs Jira voient quels flux utilisent quelque chose avant de le retirer ou de le changer, examinent les identifiants de connexion, les courriels et les propriétaires, et corrigent les flux qui échouent ou n’agissent jamais
Des journaux d’audit de l’automatisation choisis avec les exports : pour chaque flux, seulement des nombres et des jours civils (exécutions et leur issue, étapes facturées, durée, jour de la dernière exécution et de la dernière exécution échouée); les exécutions et étapes du site par jour, par produit; et, d’un journal qui liste toutes les exécutions, l’heure de sa dernière exécution : une seule heure pour tout le journal, sans flux, exécution, personne ni ticket à côté, gardée seulement quand le dernier jour de ce journal est le jour de l’analyse	Pour montrer quels flux échouent, sont arrêtés par les limites de Jira, s’exécutent sans rien faire ou ne s’exécutent plus, montrer l’utilisation au-delà des 90 jours que garde le journal de Jira, et prévoir le mois
Pour chaque siège payant d’un export d’utilisateurs qu’un administrateur Jira choisit : l’identifiant de compte, le dernier jour d’utilisation et l’indication d’administrateur du produit	Pour que les administrateurs Jira voient les sièges payants que personne n’utilise et les administrateurs du produit qui n’ont pas été actifs
Pour chaque action de la page À faire : son état, l’identifiant de compte de l’administrateur Jira qui l’a fixé et la clé du ticket qu’un administrateur Jira y a lié	Pour que les administrateurs Jira suivent le nettoyage qu’ils ont décidé
Pour chaque avis envoyé au propriétaire d’un flux : le flux (pour un filtre dont Jira refuse le JQL, l’identifiant Jira du filtre), quand, la clé du ticket Jira, les identifiants de compte de la personne avisée et de celle qui l’a envoyé, et l’objet. Pas son texte, qui est dans Jira, où toute personne qui peut parcourir le projet peut le lire	Pour lister les avis envoyés au sujet d’un flux
Pour chaque alerte envoyée : sa clé (le genre d’alerte, le produit et la période), quand, et la clé du ticket Jira. Aucun identifiant de compte. Pas son texte, qui est dans Jira, où toute personne qui peut parcourir le projet peut le lire	Pour lister les alertes envoyées, et pour qu’aucune alerte ne soit envoyée deux fois
Les paramètres qu’un administrateur Jira saisit : le forfait, le nombre d’utilisateurs, les groupes autorisés, les domaines de courriel de votre organisation, les réglages des alertes (projet, type de ticket, langue, noms ou identifiants de flux) et les identifiants de compte des personnes que les alertes mentionnent, les conventions de nommage des filtres, des tableaux de bord et des sprints, les deux nombres de jours après lesquels Laissés de côté compte un sprint comme laissé de côté, les cibles des vérifications (un nombre, avec l’identifiant de compte de l’administrateur Jira qui l’a fixée) et les consignes des vérifications (texte saisi par l’administrateur, 500 caractères au plus); les valeurs du modèle de coût, qu’une personne du niveau Gérer peut aussi enregistrer; et, à côté de chaque paramètre, l’identifiant de compte de la personne qui l’a enregistré en dernier	Pour calculer des estimations, décider de l’accès, distinguer les adresses de votre organisation de celles de l’extérieur, créer des alertes, et consigner qui a enregistré un paramètre en dernier
Pour les outils de nettoyage, tant qu’un administrateur Jira garde les vérifications d’un outil : de la configuration et des nombres par identifiant Jira (jamais un nom), avec la date de chaque lecture, une ligne pour chaque jour où un nombre a changé, et un code fait d’un nom avec la clé de votre site là où il faut trouver des copies (champs personnalisés, statuts, types de tickets, priorités, résolutions, types de liens, workflows), et, pour un champ personnalisé, les codes des noms qu’il a eus. Pour un filtre ou un tableau de bord, aussi l’identifiant de compte de son propriétaire et si ce propriétaire est actif. Pour le responsable d’un espace, l’identifiant de compte, seulement tant que Jira dit que ce responsable est inactif. Pour chaque personne à qui un schéma de permissions accorde une permission nommément, active ou non, l’identifiant de compte et la clé de la permission	Pour montrer ce qui est inutilisé, copié, cassé ou près d’une limite, et quand un nombre atteindrait le plafond de Jira
Le registre de chaque changement qu’un outil de nettoyage a fait dans Jira : l’outil, quand, le type, les identifiants de compte de l’administrateur Jira qui l’a fait et d’un nouveau propriétaire, combien d’objets, le résultat, et jusqu’à quand on peut l’annuler; pour chaque objet, l’identifiant Jira, son état et ce dont une annulation a besoin (des identifiants, jamais des noms; pour un renommage, des hachages à clé de l’ancien et du nouveau nom; pour un statut supprimé, un hachage à clé de son nom et de sa description, fait avec la clé de votre site, pour qu’un statut renommé depuis la confirmation soit laissé tel quel; pour un workflow ou un schéma de workflow supprimé, combien de workflows ou de statuts la suppression a laissés inutilisés, sous forme de nombres; pour un filtre réparé, des hachages à clé de son JQL avant et après, faits avec la clé de votre site, jamais le JQL)	Pour que les administrateurs Jira voient ce que TuneCraft a changé et l’annulent tant que Jira le permet
Pour chaque changement d’étiquette : l’ancienne et la nouvelle étiquette (le texte des étiquettes, 255 caractères au plus chacune) et les identifiants des tickets modifiés	Pour que le changement puisse être annulé ou poursuivi dans les 30 jours, sans fichier
Pour chaque fusion d’un champ dans un autre faite par un administrateur Jira (Champs > Fusionner des champs), 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. Les valeurs copiées passent par la mémoire de l’application et ne sont jamais stockées ni écrites dans un journal; aucun nom de champ, texte d’option ni clé ou résumé de ticket n’est gardé	Pour que le changement puisse être poursuivi, vérifié et annulé; gardé comme le dit la section 5
Pour chaque changement d’étiquette, où il en est : les hachages à clé de l’ancienne et de la nouvelle étiquette, son état et ses nombres, et, tant que l’exécution est ouverte, l’identifiant du dernier ticket traité	Pour qu’un changement d’étiquette puisse se dérouler par tranches, être arrêté, poursuivi ou annulé, et montrer ses nombres; gardé 400 jours, sauf l’identifiant du dernier ticket, qui disparaît à l’arrêt de l’exécution et dans tous les cas après 30 jours
Pour une lecture de Pièces jointes : des nombres de tickets, de fichiers et d’octets par espace, type de fichier et mois, les copies trouvées sur un ticket (des nombres), les identifiants des 100 tickets dont les pièces jointes prennent le plus de place et, pour une lecture d’espaces choisis, l’identifiant de compte de l’administrateur Jira qui l’a lancée. Jamais un nom de fichier, le texte d’un ticket ni le nom d’un espace	Pour montrer où les pièces jointes prennent de la place et quels tickets contiennent des copies
Pendant qu’une exécution d’archivage ou d’arriéré périmé est ouverte (si personne ne la termine ni ne l’arrête, jusqu’à 400 jours après sa dernière écriture) : la façon dont elle 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 identifiants et les états des tickets sont dans le registre des changements ci-dessus. Jamais une clé, un résumé, le nom d’un filtre ni un texte de JQL	Pour pouvoir arrêter l’exécution ou la poursuivre, et revérifier chaque lot d’un arriéré périmé avant de l’écrire
La liste d’exclusion : pour chaque proposition qu’un administrateur Jira a choisi de ne plus voir, l’outil, le type d’objet et l’identifiant Jira (pour un flux, son identifiant et le constat), l’identifiant de compte de l’administrateur Jira qui l’a exclue, le jour, un code de motif et le jour où l’exclusion prend fin, s’il y en a un; pour une personne exclue, l’identifiant de compte de cette personne. Jamais un nom	Pour qu’une proposition exclue ne soit plus faite
La liste de surveillance : pour chaque champ, espace ou filtre qu’un administrateur Jira a mis sous surveillance, son type et son identifiant Jira, l’identifiant de compte de l’administrateur Jira qui l’a ajouté, le jour, 30, 60 ou 90 jours, le dernier jour où il a été vu utilisé et le jour de la dernière vérification. Au plus 100 lignes. Jamais un nom	Pour qu’un administrateur Jira voie si quelque chose est encore utilisé avant de le retirer
L’historique des changements : pour chaque changement qu’une lecture en arrière-plan a vu dans la configuration de Jira, le type, l’identifiant Jira et le jour. Jamais un nom, une requête ni une valeur	Pour que les administrateurs Jira voient ce qui a changé sur leur site, et quand
Pour 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 (voir la section 6); 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 résultat du dernier envoi (des nombres) avec l’heure où il a été enregistré	Pour n’accepter un envoi que d’un expéditeur qui a la clé, enregistrer l’analyse, répondre à une partie envoyée de nouveau sans l’enregistrer deux fois, et montrer à un administrateur Jira ce qui s’est passé
Les identifiants de comptes que l’application stocke, avec la date de leur dernier stockage et de leur dernier signalement à Atlassian	Pour le signalement des données personnelles à Atlassian (section 5)
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	Pour utiliser de vrais nombres à la place d’estimations
Pour chaque correction qu’une analyse a confirmée : l’identifiant du flux, le constat, les étapes économisées, le jour, les identifiants de l’analyse qui l’a confirmée et, le cas échéant, de celle qui l’a trouvée défaite, et le nom du flux tant que l’analyse qui l’a confirmée est gardée	Pour montrer les étapes que les corrections ont économisées, et quelles corrections une analyse ultérieure a trouvées défaites
Pour chaque analyse : les liens entre ses flux (lequel peut démarrer lequel, copies, déclencheurs partagés, boucles), par identifiant de flux; et l’avancement de la comparaison de l’analyse avec la précédente (identifiants d’analyses, un identifiant de flux, des nombres)	Pour montrer comment les flux se relient, et pour savoir quels correctifs une analyse a confirmés ou annulés
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	Pour garder un essai dans ses limites
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). Des nombres et des jours seulement	Pour pouvoir comparer le score Tune avec celui de la veille
Pour chaque vérification en arrière-plan : 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	Pour poursuivre une vérification là où elle s’est arrêtée, respecter le budget de points, et montrer à un administrateur Jira ce que les vérifications ont fait
Des nombres sur les exécutions de maintenance de l’application, et ses propres points Jira par jour selon le type	Pour garder le stockage de l’application en ordre et montrer à un administrateur ce que l’application coûte

Les noms de flux sont du texte écrit par votre équipe. Ils sont conservés pour que les rapports puissent nommer les flux. Les flux conservés ne servent qu’aux administrateurs Jira. TuneCraft n’utilise pas vos données à d’autres fins, ne les vend pas, ne les utilise pas pour de la publicité et ne les utilise pas pour entraîner un modèle.

3. Où elles sont conservées

Toutes les données que l’application stocke sont dans Forge SQL, la base de données hébergée d’Atlassian pour les applications Forge, qui appartient à votre installation. Elles restent à l’emplacement de résidence des données de votre site Jira et le suivent si un administrateur change cet emplacement. L’application ne déclare aucun accès réseau externe, aucune ressource distante ni aucun appel externe, et n’a aucun outil MCP ni aucune API REST autre que le déclencheur Web de l’analyse automatique. Son seul point d’entrée à distance est le déclencheur Web de l’analyse automatique (section 6). Plugincraft n’a aucun serveur à elle. Voir Traitement des données : conservation et suppression.

4. Qui peut les voir

Dans l’application. Les personnes que vos administrateurs autorisent : les administrateurs Jira, les membres des groupes qu’ils autorisent, et les administrateurs d’un projet pour les flux de ce projet seulement. Les outils de nettoyage sont réservés aux administrateurs Jira. Les permissions de Jira s’appliquent à tout ce que l’application lit ou modifie dans Jira en tant qu’une personne.

Dans Jira. L’application crée des tickets Jira pour les alertes, les avis aux propriétaires et la page À faire. Les alertes sont créées en tant qu’application (Jira montre l’application comme rapporteuse), dans le projet et le type de ticket qu’un administrateur Jira a choisis et dans lesquels il peut créer. Toute personne qui peut parcourir ce projet peut les lire. Elles mentionnent les personnes choisies par l’administrateur, si bien que Jira les avise, et seulement celles qui peuvent parcourir le projet. Par défaut, elles nomment les flux par leurs identifiants seulement; un administrateur Jira peut activer les noms. Les avis aux propriétaires sont créés en tant que la personne qui les envoie, qui doit avoir le niveau Gérer, et les tickets de la page À faire en tant qu’administrateur Jira qui les confirme.

Plugincraft. Plugincraft ne reçoit aucune des données que l’application lit ou garde. Ce qu’elle peut lire de l’application est technique, et c’est plus que les journaux :

les journaux de l’application, qu’Atlassian conserve et que Plugincraft peut lire pour corriger des problèmes (section 7);
les statistiques d’utilisation qu’Atlassian montre à un éditeur pour chaque site où l’application a fonctionné : appels, erreurs, temps de réponse, temps des requêtes et taille de la base de données, avec l’adresse du site;
votre licence et ses coordonnées, que le Marketplace d’Atlassian donne à un éditeur pour toute application payante;
un paquet de soutien, seulement si un administrateur Jira choisit de nous en envoyer un. Il contient des versions, l’état de la licence, la taille des tables, des nombres et les dernières exécutions de maintenance, jamais de flux ni de personnes.

Un administrateur du site peut désactiver l’accès de l’éditeur aux journaux de l’application dans l’administration d’Atlassian.

Demandes des autorités. Plugincraft ne garde aucune copie des données que vous stockez dans TuneCraft : elles restent dans le stockage d’Atlassian pour votre site Jira. Si un tribunal, la police ou une autre autorité nous demande ces données, nous adressons la demande à vous ou à Atlassian. Si une demande vous concerne, nous vous en informons avant d’y répondre, sauf si la loi l’interdit, et nous ne communiquons que ce que la loi exige.

5. Combien de temps

Les analyses. Les 24 dernières analyses sont conservées et, tant qu’aucune d’elles n’a gardé ce que ses flux nomment (un expéditeur qui n’envoie que des résumés, ou une base presque pleine), la dernière analyse qui l’a gardé l’est aussi. 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. Ce que les flux utilisent, ainsi que les nombres de gouvernance, sont gardés pour la dernière analyse qui les a gardés et pour l’analyse en cours; la maintenance quotidienne les retire des analyses plus anciennes. Les nombres d’une analyse qui n’a gardé aucune référence restent aussi longtemps que cette analyse, parmi les 24 dernières. Un flux conservé reste tant qu’une analyse conservée le nomme.
Les correctifs. Un correctif que des analyses ont confirmé reste comme registre de ce qui a été économisé (l’identifiant du flux, le constat et les étapes). Le nom du flux est retiré dès que l’analyse qui l’a confirmé n’est plus conservée.
Les nombres et les historiques. L’utilisation de l’automatisation, les alertes envoyées, l’historique des constats, l’historique de Limites, l’historique des changements et les points Jira par jour sont gardés 400 jours. La santé des exécutions est une ligne par flux, remplacée par chaque nouveau journal d’audit 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 sont gardés 400 jours. Les lectures de Jira d’un outil sont gardées tant qu’un administrateur Jira garde ses vérifications, retirées quand Jira n’a plus l’objet, et retirées 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. Deux autres lectures suivent leurs propres règles. Les codes des noms qu’un champ personnalisé a eus (ils permettent à la réparation de filtres de pointer un filtre vers un champ renommé) sont gardés jusqu’à 400 jours après la dernière fois que le nom a été vu, même pour un champ que Jira a supprimé, et sont retirés dans la journée qui suit la désactivation des vérifications de Champs. Ce que la lecture des flux cassés de l’outil Automatisation a trouvé (ce qu’un flux nomme que Jira n’a plus) est gardé avec son analyse et n’est pas retiré à la désactivation des vérifications.
Les registres de changements. Le registre d’un changement est gardé 400 jours, chacun de ses objets 30 jours, et l’ancienne et la nouvelle étiquette d’un changement d’étiquette 30 jours. Un changement commencé et jamais terminé ni arrêté (un onglet fermé en plein retrait de personnes d’un groupe, ou en plein changement d’étiquette) 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, avec les identifiants de tickets et les identifiants de compte qu’ils contiennent, disparaissent 30 jours après avoir été enregistrés. Une exécution d’archivage laissée ouverte garde aussi la façon dont elle a été lancée jusqu’à 400 jours après sa dernière écriture. L’exécution d’un changement d’étiquette (les hachages à clé de ses étiquettes et ses nombres) est gardée 400 jours, avec le registre du changement; l’identifiant du dernier ticket traité disparaît à l’arrêt de l’exécution et dans tous les cas 30 jours après. La fusion d’un champ dans un autre garde son exécution (les identifiants des deux champs et ses nombres) 400 jours, et l’identifiant du dernier ticket traité 30 jours après l’exécution.
Les personnes. Les avis aux propriétaires sont gardés un an. Les personnes que les alertes mentionnent sont gardées tant qu’elles sont choisies. Les sièges d’un export d’utilisateurs sont gardés jusqu’à ce qu’un administrateur Jira téléverse un nouveau fichier ou les retire, et au plus 90 jours après le téléversement. L’état d’une action À faire et l’identifiant de compte de la personne qui l’a fixé sont retirés 400 jours après qu’une lecture l’a confirmée 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.
Les listes d’exclusion et de surveillance. Gardées jusqu’à ce qu’un administrateur Jira les arrête, jusqu’à la fin des jours pour lesquels une exclusion a été posée, 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. Les identifiants de compte qu’elles contiennent sont effacés à la fermeture du compte.
Les cibles. Une cible qu’un administrateur Jira fixe pour une vérification est gardée jusqu’à ce qu’il la retire, et 400 jours après qu’elle a été atteinte. L’identifiant de compte de l’administrateur qui l’a fixée est effacé à la fermeture du compte.
Les autres enregistrements. Les nombres d’exécutions mesurés sont gardés jusqu’à ce qu’une personne du niveau Gérer les retire, et sont retirés 90 jours après le jour de la mesure lorsque la dernière analyse n’a plus le flux. Les liens d’une analyse et l’avancement de sa comparaison partent avec l’analyse. Les nombres de la santé du site sont gardés 400 jours, et les chiffres quotidiens des vérifications en arrière-plan 14 jours. Le seul flux qu’un essai peut optimiser, et le décompte des modifications de l’essai, restent tant que l’application est installée.
Les lectures de pièces jointes. Une lecture d’espaces choisis est gardée 90 jours. Une lecture de tout le site est gardée jusqu’à ce qu’une plus récente se termine.
Les envois de l’analyse automatique. Les parties d’un envoi sont supprimées quand l’envoi se termine. Un envoi qui ne se termine jamais est retiré par la maintenance quotidienne dès qu’il a une heure, trois heures si l’application avait commencé à l’enregistrer, ou 26 heures si l’expéditeur a demandé à l’application de le garder ouvert pour plusieurs exécutions (voir la section 6).
Les comptes fermés. L’application signale à Atlassian les identifiants de comptes Atlassian qu’elle stocke une fois par cycle de signalement (7 jours, sauf si Atlassian en fixe un autre), comme Atlassian l’exige des applications. Lorsqu’Atlassian indique qu’un compte a été fermé, une exécution quotidienne retire cet identifiant de toutes les données de l’application, généralement le jour même, et ne garde que l’identifiant seul pendant environ un cycle de plus pour qu’il ne soit pas signalé de nouveau.
La désinstallation. Lorsque vous désinstallez TuneCraft, Atlassian supprime les données stockées de l’application selon ses règles de conservation des données. Elle les garde 30 jours, puis les supprime définitivement, et peut rattacher une réinstallation aux anciennes données sur demande dans les 21 jours. Nous n’en gardons aucune copie. Voir Traitement des données.

6. L’analyse automatique

Un administrateur Jira peut activer l’analyse automatique. Un expéditeur, un script que le client exécute, lit alors le vrai texte de chaque règle avec le jeton d’API Atlassian du client, le caviarde du côté du client selon des règles au moins aussi strictes que celles du navigateur, et envoie le résultat au déclencheur Web de l’application, en parties d’au plus 58 000 octets. Une règle que l’expéditeur ne peut pas caviarder n’est pas envoyée et est comptée. L’application enregistre une telle analyse comme faite par l’application, et non par une personne, et garde ce qu’elle reçoit comme pour une analyse lancée par un administrateur Jira.

Le client choisit où l’expéditeur s’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 sur son site Jira. Dans ce cas, ScriptRunner lit le vrai texte des règles et détient le jeton d’API du client, selon l’entente du client avec cet éditeur, avant que quoi que ce soit parvienne à TuneCraft. Le jeton n’atteint jamais TuneCraft ni Plugincraft.

Ce que l’application reçoit. Pour chaque flux : son identifiant, son nom, s’il est activé, les identifiants de compte de son propriétaire et de son acteur, les identifiants de ses projets, ses étapes dont chaque texte des réglages est remplacé par un marqueur, les identifiants de compte que ces étapes nomment, des identifiants Jira, des hachages à clé et des nombres. Les noms de flux sont du texte écrit par votre équipe : ils sont gardés et montrés tels quels. L’application ne reçoit jamais un texte des réglages d’une règle : elle vérifie chaque flux à son arrivée et de nouveau avant d’enregistrer l’analyse, et un seul flux non caviardé fait refuser tout l’envoi, sans que rien n’en soit gardé.

Le déclencheur Web. C’est le seul point d’entrée à distance de l’application. Il n’accepte que POST, avec une clé dans l’en-tête Authorization, et répond par l’une de dix réponses fixes (acceptée, non autorisée, sans licence, trop grande, requête invalide, hors ordre, déjà reçue, limite, réessayer plus tard, erreur), jamais par des données. Il refuse un envoi sans licence de l’application (un essai compte), plus de 6 envois par jour pour le site, plus de deux envois ouverts à la fois, une requête de plus de 150 Ko et un envoi de plus de 800 parties ou de 20 000 flux.

La clé. Un administrateur Jira fabrique la clé sur la carte Analyse automatique de la page Analyse et ne la voit qu’une fois. Elle a deux parties. L’une est un secret que l’expéditeur envoie avec chaque envoi pour montrer qu’il y est autorisé; l’application n’en garde qu’une empreinte à sens unique, faite avec l’identifiant du site et un secret propre à l’application, conservé dans une variable Forge chiffrée. L’autre est la clé d’analyse du site, la clé derrière chaque hachage à clé de cette politique, dont l’expéditeur a besoin pour faire les mêmes hachages à clé que le navigateur; l’application la garde aussi dans son stockage, et le navigateur de toute personne qui lance une analyse la reçoit. Quiconque détient la clé entière peut envoyer des analyses à l’application et peut tester des hypothèses contre un hachage à clé (un pseudonyme); gardez-la donc comme vous gardez le jeton d’API, dans le coffre à secrets de l’expéditeur. Remplacer la clé ou désactiver l’analyse automatique arrête aussitôt le secret précédent. Cela ne change pas la clé d’analyse.

Pendant qu’un envoi est en cours. Les parties d’un envoi attendent dans le stockage de l’application jusqu’à l’arrivée de la dernière et jusqu’à ce que l’application ait enregistré l’analyse; elles sont alors supprimées. Un envoi qui ne se termine jamais (un expéditeur qui s’est arrêté) est retiré par la maintenance quotidienne dès qu’il a une heure, trois heures si l’application avait commencé à l’enregistrer, ou 26 heures si l’expéditeur a demandé à l’application de le garder ouvert pour plusieurs exécutions. Les parties qui attendent contiennent les mêmes données que l’analyse enregistrée, y compris les identifiants de compte des propriétaires, des acteurs et des personnes que les étapes nomment. Ces identifiants sont ajoutés à la liste que l’application signale à Atlassian quand l’analyse est enregistrée : pendant les heures où un envoi attend, ils n’y sont pas, et un envoi qui ne se termine jamais est supprimé sans avoir été signalé.

7. Journaux et soutien

Atlassian conserve les journaux techniques de l’application, que Plugincraft peut lire pour corriger des problèmes. Ils ne contiennent que des identifiants des enregistrements propres à l’application, des nombres, des états et des codes d’erreur, jamais le contenu de vos flux, des noms ou des adresses courriel. Atlassian conserve les journaux des applications selon ses propres règles (sa documentation dit que les journaux sont disponibles pour les 30 derniers jours). Voir Journalisation des données.

Lorsque vous nous écrivez, nous conservons votre message, votre adresse courriel et tout ce que vous choisissez d’y joindre, comme le décrit la politique de confidentialité de ce site Web. Chaque administrateur décide d’envoyer ou non un paquet de soutien.

8. Fonctions d’IA

Sur un site qui a Rovo, TuneCraft a un assistant d’IA, l’assistant TuneCraft, qu’une personne ouvre depuis un bouton Demander à Rovo. C’est Rovo d’Atlassian : le modèle est celui qu’Atlassian fournit sur sa plateforme, et TuneCraft n’envoie rien hors d’Atlassian. La demande du bouton désigne ce que la personne regarde par son identifiant (un numéro de flux, de champ, de filtre ou d’espace, jamais un JQL, le texte d’une étiquette ni un secret). Pour répondre, l’assistant demande à TuneCraft ce que la personne peut voir : des nombres, des identifiants, les constats et les économies de la dernière analyse, et les noms que les pages de la personne montrent déjà. Ces réponses vont à Rovo et ne sont montrées qu’à cette personne. L’assistant ne modifie jamais Jira. Sur un site sans Rovo, l’application n’a aucune fonction d’IA. Voir la Politique d’utilisation de l’IA.

9. Comment nous les protégeons

L’accès à nos comptes et à nos dossiers est limité aux personnes qui en ont besoin et protégé par des mots de passe robustes et l’authentification à deux facteurs. L’application s’appuie sur la sécurité d’Atlassian pour tout ce qu’elle stocke. Pour signaler une vulnérabilité, voir l’Aperçu de la sécurité. La façon dont nous traitons les incidents est dans Réponse aux incidents.

Si un incident de confidentialité touchant vos renseignements personnels présente un risque de préjudice sérieux, nous vous en aviserons, ainsi que la Commission d’accès à l’information du Québec, avec diligence, comme la loi l’exige. Nous tenons un registre de tous les incidents.

10. Vos droits

Les demandes concernant des données personnelles dans TuneCraft (accès, correction, suppression) s’adressent aux administrateurs Jira de votre organisation, qui contrôlent les données. Ils peuvent les consulter dans l’application, et une personne du niveau Gérer peut supprimer des analyses dans la page Historique. Nous les aidons à titre de sous-traitante.

Pour les renseignements personnels que Plugincraft détient elle-même, vous pouvez nous demander de vous dire ce que nous détenons à votre sujet et de vous en remettre une copie, de corriger ce qui est inexact, de détruire ce dont nous n’avons plus besoin, et de cesser de les utiliser à une fin que vous aviez acceptée. Écrivez à info@plugincraft.ca. Nous pouvons vous demander de confirmer votre identité. Nous répondons dans les 30 jours, et c’est gratuit. Si notre réponse ne vous satisfait pas, vous pouvez porter plainte auprès de la Commission d’accès à l’information du Québec ou du Commissariat à la protection de la vie privée du Canada.

11. Enfants

L’application est destinée aux entreprises et ne vise pas les enfants de moins de 14 ans. Nous ne recueillons pas sciemment leurs renseignements.

12. Modifications de cette politique

Si nous modifions cette politique, nous mettrons à jour la date en haut de cette page. Si un changement est important, nous l’annoncerons aussi sur cette page avant son entrée en vigueur, et dans les « Nouveautés » de l’application.

13. Langue

Cette politique est disponible en français et en anglais. Les deux versions ont la même valeur.