ServiceGouvernance du service : rétention, masquage, tickets sensibles, permissions par canal, politique de fichiers, historique de connexion et demandes des personnes concernées
La gouvernance du service se trouve dans Paramètres > Gouvernance du service. C'est la couche propre au support par-dessus la sécurité de la plateforme : l'isolement des données par organisation, les rôles et permissions, la piste d'audit, le journal des accès sensibles et les outils de confidentialité existent déjà. Cet écran gouverne ce qui arrive aux tickets, aux mess
La gouvernance du service se trouve dans Paramètres > Gouvernance du service. C'est la couche propre au support par-dessus la sécurité de la plateforme : l'isolement des données par organisation, les rôles et permissions, la piste d'audit, le journal des accès sensibles et les outils de confidentialité existent déjà. Cet écran gouverne ce qui arrive aux tickets, aux messages, aux pièces jointes et aux personnes qui les traitent. Tout part de zéro : sans aucune configuration, le support fonctionne exactement comme avant.
Permissions fines
Quatre permissions ont été ajoutées à la matrice des rôles (Paramètres > Rôles) : ticket_internal_note (voir et écrire des notes internes), ticket_message (supprimer un message pour tout le monde), ticket_sensitive (ouvrir un ticket marqué comme sensible, et le marquer ou le démarquer) et ticket_pii (voir les données personnelles dans les messages sans masquage). Chaque rôle qui pouvait lire les tickets a conservé le droit de voir les notes internes, personne ne perd donc rien le premier jour ; les administrateurs peuvent désormais le retirer des rôles partenaire externe ou API. Les organisations qui n'utilisent pas encore les rôles et permissions ne sont pas limitées par ces cases.
Rétention par classe de données
Une politique de rétention indique combien de temps un ticket résolu conserve ses données, par classe : le ticket lui-même, les messages du client, les notes internes, les pièces jointes et les réponses de satisfaction. Le compteur démarre à la résolution du ticket ; les tickets ouverts ne sont jamais touchés, quel que soit leur âge. Chaque politique choisit entre anonymiser (la ligne reste, les données personnelles telles que l'e-mail, le nom, le téléphone, les numéros de document et de carte en sont retirées, de sorte que le volume et les indicateurs de SLA survivent) et supprimer. Les pièces jointes ne peuvent être que supprimées. Le balayage nocturne applique les politiques par lots et consigne chaque passage dans un registre qui ne peut pas être modifié ; l'onglet Rétention affiche ce registre et permet à un administrateur de lancer le balayage maintenant pour cet espace de travail. Les classes sans politique s'affichent comme non déclarées, jamais présumées conservées pour toujours par choix.
Masquage dans la conversation
Les règles de masquage décident ce qui est caché dans les messages des tickets pour les personnes sans la permission ticket_pii. Il existe trois types : les données personnelles (e-mail, téléphone, identifiants fiscaux, numéros de carte, avec les mêmes détecteurs qui protègent les invites d'IA), les montants financiers ancrés à une devise, et les motifs personnalisés que vous écrivez (un format de numéro de compte, un code de commande). Chaque règle s'applique aux messages du client, aux notes internes ou aux deux, et remplace la correspondance par un marqueur de votre choix. L'onglet liste quels rôles voient tout avant que vous ne créiez la première règle, et prévisualise l'effet d'une règle sur un texte d'exemple. Les personnes disposant de la permission voient toujours le texte d'origine.
Tickets sensibles
Toute personne disposant de la permission ticket_sensitive peut marquer un ticket comme sensible depuis l'en-tête du ticket dans la console, avec un motif facultatif. À partir de là, seules les personnes disposant de cette permission peuvent l'ouvrir ; tout le monde reçoit un refus explicite. Chaque ouverture est consignée dans le journal des accès sensibles (qui, quand, quel ticket), dédupliquée par personne toutes les dix minutes pour que les rafraîchissements de page ne gonflent pas la piste. Marquer et démarquer sont enregistrés comme des événements de sécurité dans la piste d'audit, que les administrateurs ne peuvent pas désactiver.
Permissions par canal
Par défaut, toute personne pouvant répondre peut le faire sur tous les canaux. Dans l'onglet Canaux, un administrateur autorise des rôles précis sur un canal. La première ligne écrite pour un canal le ferme à tous les autres : à partir de là, seuls les rôles listés peuvent y répondre. Les canaux sans ligne restent ouverts. Le serveur applique cette règle à chaque réponse, quel que soit l'écran.
Historique de connexion
L'onglet Connexions affiche qui s'est connecté, quand, depuis quelle adresse et quel appareil, ainsi que les tentatives de mot de passe échouées pour les membres de cet espace de travail. L'authentification elle-même est gérée par le fournisseur d'identité ; ceci est un miroir de ce que le serveur voit, une ligne par session, conservée dans une table qui ne peut pas être modifiée.
Ouvrir cet article dans le système →