Demandes des personnes concernées

En tant qu’admin ou propriétaire, utilise Paramètres > Gouvernance > Personnes concernées pour traiter une demande d’effacement. Tale suit la demande, son approbation, son délai d’attente et le résultat de la suppression. Vérifie d’abord l’identité de la personne et le bon périmètre selon la procédure de ton organisation.

Déposer une demande

1. Choisis Déposer une demande et recherche la Personne concernée par nom ou e-mail. Vérifie que tu as sélectionné le bon compte.
2. Choisis le Fondement légal et explique la demande dans Motif détaillé, avec une référence à ton dossier interne.
3. Saisis exactement ERASE, puis choisis Déposer la demande.
4. Ouvre le reçu et vérifie le statut, l’échéance et la prochaine action requise.

L’effacement supprime définitivement les données couvertes ; il ne les déplace pas vers la corbeille. Le reçu indique les catégories et les nombres concernés : chats, documents et imports, préférences, retours, notifications, usage et nettoyage des identifiants personnels dans l’audit. Il supprime aussi les transcriptions des exécutions de l’agent standard que la personne a démarrées et les fichiers que seules ces transcriptions contenaient ; les fichiers produits qu’une tâche conserve restent. L’effacement supprime aussi les espaces de travail de sandbox propres aux exécutions d’agent que la personne a démarrées, même si du travail s’y exécute encore ; le reçu les compte sous Espaces de travail de sandbox. Un espace de travail n’est compté qu’une fois ses fichiers supprimés par le service de sandbox, ce qui peut prendre un moment pour un grand espace. D’ici là, ou tant que leur suppression échoue, le reçu indique Partiel et cite sandboxWorkspaces parmi les passes échouées ; choisis plus tard Réessayer, et l’effacement se termine dès que les fichiers ont disparu. Sous Kubernetes, un espace est compté une fois son volume remis au provisionneur de stockage du cluster ; avec une StorageClass dont la reclaimPolicy est Retain, les fichiers du volume restent jusqu’à ce qu’un opérateur supprime le volume, même si le reçu compte l’espace. Un service de sandbox ou un appareil qui n’est pas encore passé à cette version ne peut pas confirmer la suppression ; le reçu reste alors Partiel jusqu’à sa mise à jour.

La catégorie Requêtes aux modèles couvre les requêtes à l’API des modèles et les appels directs aux modèles dans les automatisations. Les requêtes déjà comptabilisées sont supprimées. Une requête encore en cours conserve les données nécessaires à sa comptabilisation, avec un pseudonyme à la place de l’identité de la personne. L’usage reçu plus tard est enregistré sous ce pseudonyme. Si la suppression de l’exécution d’automatisation ou de l’identité échoue, le reçu reste Partiel et le nettoyage des données d’usage qui en dépend attend une nouvelle tentative.

Les tâches qui désignent la personne comme Relecteur perdent cette désignation. Une demande de revue qui l’attend encore passe à la première personne autorisée parmi celle qui a créé la tâche, puis celle qui a créé le projet. Cette personne reçoit une notification. Pour une tâche archivée, la demande passe sans notification. Les décisions de revue que la personne a déjà prises restent enregistrées sans son nom.

Le contenu des versions enregistrées d’automatisation et leurs rapports de tests restent inchangés lors de l’effacement. L’effacement remplace l’identité de la personne par un pseudonyme lorsqu’elle a enregistré une version ou exécuté ses tests, l’a déployée, a configuré son déclencheur, l’a installée dans un projet ou l’a supprimée.

L’effacement des exécutions concernées d’une personne ne réécrit pas les valeurs copiées dans les tests des versions d’automatisation conservées. Examine séparément ces contenus rédigés selon la procédure de ton organisation. Utilise des exemples synthétiques lorsque tu enregistres une exécution comme test.

Vérifier la règle avant le dépôt

Seul le propriétaire peut modifier cette règle. Les protections renforcées s’appliquent immédiatement ; les assouplissements attendent 24 heures pour permettre à tout admin de les annuler. Vérifie les réglages effectifs et les éventuels changements en attente avant de compter sur une nouvelle valeur.

Suivre le reçu

Un reçu ouvert peut empêcher un second dépôt pour la même personne. Reprends ce reçu au lieu de multiplier les demandes. Une demande bloquée dès le dépôt doit à nouveau respecter la règle actuelle d’approbation et d’attente lors d’un nouvel essai. Un reçu en attente d’approbation conserve l’exigence d’approbation fixée à son dépôt : désactiver la double approbation ensuite ne le libère pas.

Les exécutions d’automatisation suspendues lors d’une mise à niveau sont conservées tant que leurs actions externes antérieures restent non vérifiées. L’effacement supprime les autres exécutions admissibles de la personne et compte séparément celles qui ont été effacées et celles qui ont été conservées. Le reçu reste partiel. Ces blocages d’exécution sont distincts des conservations légales et aucune action ne permet actuellement de les lever. Une demande d’arrêt ou une nouvelle tentative d’effacement ne les lève pas. Une organisation contenant ces blocages ne peut pas non plus être supprimée.

Gérer l’échéance

La liste montre le délai suivi et les éventuels retards. Utilise Prolonger le délai pour une prolongation justifiée tant que l’action est disponible. L’application autorise une prolongation avant l’expiration du délai initial et enregistre le motif ainsi que l’admin.

Cette échéance facilite le suivi. Ton organisation reste responsable de l’examen et des échanges avec la personne. Terminer un reçu Tale ne confirme pas, à lui seul, une suppression dans des systèmes externes indépendants ou des sauvegardes.

Vérifier le résultat

Ouvre les compteurs par catégorie, les erreurs et la chronologie d’audit du reçu. Une action terminée, une catégorie sous conservation légale et une étape échouée n’ont pas le même résultat. Note ces distinctions dans ton dossier. Consulte les journaux d’audit pour les événements administratifs associés.