Zendesk et RGPD : tickets, IA et conservation

Un ticket Zendesk peut contenir une conversation, une pièce d’identité, une capture d’écran et des données reprises dans un CRM. La conformité exige de maîtriser cet ensemble, y compris les fonctions d’IA et les copies qui subsistent après la fermeture du ticket.

Définir ce qui doit entrer dans les tickets

Précisez les informations nécessaires au support et les pièces à éviter. Un numéro de carte bancaire ou une pièce d’identité appelle une protection adaptée, sans relever automatiquement des catégories sensibles de l’Art. 9(1). Des informations de santé peuvent, elles, relever de cet article et nécessiter une exception de l’Art. 9(2), en plus d’une base de l’Art. 6(1). Le contrat commercial ne constitue pas à lui seul cette exception. Voir le RGPD, chapitre II.

Demandez aux agents de conserver une référence de dossier lorsque le document complet n’est pas utile. Encadrez aussi les notes libres contenant des données sensibles. Les formulaires, réponses automatiques et consignes du support doivent expliquer quels documents transmettre et par quel canal.

Zendesk documente des fonctions de masquage définitif et de suppression. Vérifiez leur portée sur les commentaires, pièces jointes et autres services utilisés, puis les copies déjà transmises à des applications tierces.

Ne pas confondre fermeture, archivage et suppression

La documentation des calendriers de suppression distingue les tickets fermés, archivés et supprimés. Ces calendriers portent sur les tickets archivés ; l’archivage intervient généralement après 120 jours. Une règle fondée sur la dernière modification peut repartir après une nouvelle modification, y compris une opération de nettoyage.

Choisissez donc votre événement de départ avec soin. Pour chaque famille de tickets, indiquez : durée utile au support, justificatifs éventuellement nécessaires, périmètre d’archivage restreint et règle de suppression. L’Art. 5(1)(e) du RGPD impose une conservation limitée aux besoins de la finalité, sans fixer une durée universelle pour les tickets.

Utilisez la prévisualisation de la règle et faites contrôler un échantillon fictif ou dédié avant activation. La documentation signale que les tickets supprimés par ces calendriers ne sont pas restaurables. N’utilisez pas une règle globale tant que vous n’avez pas isolé les éléments soumis à une obligation de conservation ou nécessaires à un litige.

Examiner les fonctions d’IA une par une

L’affirmation « aucune donnée client n’entraîne jamais un modèle Zendesk » est trop large. La documentation sur l’usage des données distingue des modèles propriétaires, auxquels peuvent contribuer des données préparées, et les modèles génératifs tiers qui ne doivent pas employer les entrées pour leur propre entraînement.

La page AI Trust décrit des contrôles clients sur l’entraînement et l’activation des fonctions. Pour votre instance, relevez les options retenues, les catégories envoyées, les sous-traitants et les durées. La suppression d’identifiants ou la conversion du texte en nombres ne permet pas, à elle seule, de conclure à une anonymisation juridique.

Vérifiez aussi ce que produit l’outil : suggestion relue, réponse automatique, classement ou action sur un compte. Si l’usage est susceptible d’engendrer un risque élevé, l’AIPD devient obligatoire selon l’Art. 35(1) du RGPD.

Vérifier la portée réelle de l’hébergement régional

La politique d’hébergement Zendesk lie ses engagements à l’éligibilité et à l’activation d’une région. Elle distingue les services et prévoit des exceptions, notamment selon l’ancienneté de certains comptes Messaging ou QA.

Constituez un tableau par module : service, région confirmée, date de création pertinente, données exclues et flux d’assistance. Un ticket hébergé dans l’EEE ne prouve pas que tous les modules, historiques et connecteurs le sont. Pour les destinations extérieures, examinez les garanties de transfert.

Conservez le contrat et le DPA applicables à votre abonnement. Qualifiez séparément chaque application ajoutée : un outil choisi directement par votre entreprise n’est pas automatiquement un sous-traitant ultérieur de Zendesk.

Organiser une demande de droits complète

Recherchez les profils, tickets, conversations, pièces et exports concernés. Vérifiez l’identité de manière proportionnée, puis appliquez les conditions du droit demandé. Le droit à l’effacement n’impose pas de détruire une preuve encore légalement nécessaire, mais sa conservation doit rester limitée et justifiée.

Attribuez la coordination à une personne identifiée : le support traite la demande, l’administrateur intervient dans les modules et le responsable décide des exceptions avec le conseil du DPO. Une réponse au client doit décrire le résultat réel, pas seulement confirmer qu’un ticket est fermé.

Traduire la politique de conservation en règles vérifiables

La règle métier doit précéder le réglage. « Supprimer les tickets anciens » ne précise ni le besoin conservé ni le point de départ retenu. Pour chaque catégorie, faites répondre le métier à trois questions : à quoi l’historique sert-il encore, quelles données sont indispensables et quel événement termine ce besoin ? La réponse permet ensuite d’examiner la traduction technique.

Une matrice de travail peut distinguer ces situations :

Ce tableau ne fixe aucune durée légale. Une conservation pour défendre un droit en justice relève, sous ses conditions, de l’Art. 17(3)(e) ; elle ne permet pas de garder indéfiniment tous les tickets dans l’espace de travail des agents. Faites décider quelles pièces sont nécessaires, qui doit pouvoir les consulter et quand la justification sera réexaminée.

Documentez les exceptions avant d’activer une suppression. Une liste d’exclusions non maintenue peut finir par devenir une conservation permanente. Pour chaque exception, inscrivez un responsable, une raison intelligible et un événement de réexamen. La mention « demandé par le juridique » ne suffit pas si personne ne peut retrouver le dossier correspondant.

Éviter que le nettoyage repousse sans fin la suppression

La règle fondée sur la dernière modification mérite une attention particulière. Dans la documentation Zendesk, certaines actions de nettoyage peuvent modifier cette date. Une intervention destinée à réduire les données peut donc changer l’échéance d’une règle automatique. Il faut comparer le comportement configuré à la durée décidée pour la finalité, et pas seulement vérifier que la règle existe.

Préparez un petit tableau de cas à soumettre à l’administrateur : ticket récent, ticket ancien inchangé, ticket ancien récemment nettoyé et ticket sous conservation justifiée. Pour chacun, indiquez le sort attendu et sa raison. Ce tableau constitue un scénario de vérification proposé ; il ne décrit aucun essai effectué dans un compte Zendesk.

L’administrateur doit expliquer quelles conditions sélectionnent réellement chaque cas. Si une règle ne traduit pas correctement la politique, adaptez l’organisation ou cherchez un autre moyen avant sa mise en service. Un seuil technique de l’outil ne devient pas la durée autorisée par le RGPD. Inversement, une durée écrite dans une politique ne prouve pas son exécution.

Après activation, contrôlez périodiquement les écarts : éléments qui restent au-delà de l’échéance, suppressions attendues non réalisées et exclusions sans responsable. Conservez le résultat des vérifications effectivement menées. La surveillance de la règle doit aussi couvrir ses modifications ultérieures et les effets d’un changement d’offre ou de module.

Répondre à un droit sans perdre les éléments de recherche

Le guide Zendesk attire l’attention sur l’ordre des opérations : les informations du profil peuvent être utiles pour retrouver des données dans les conversations avant de supprimer l’utilisateur. Préparez donc la recherche et les rapprochements avant l’action finale. Une suppression précipitée peut compliquer la vérification du reste du périmètre.

Pour une demande d’accès, l’objectif juridique est celui de l’Art. 15 : permettre l’accès aux données concernées et fournir les informations exigées. Un export standard ne doit pas être envoyé sans examen de son contenu, de son exhaustivité et des données d’autres personnes. Pour un effacement, appliquez les conditions de l’Art. 17 et expliquez les éventuelles conservations justifiées. Les deux démarches ne se remplacent pas.

La réponse doit porter sur ce qui a été réellement traité. Faites distinguer le profil, les tickets, les pièces et les copies extérieures. L’Art. 19 encadre l’information des destinataires en cas de rectification, d’effacement ou de limitation concernés par ce texte, avec ses exceptions. Affectez cette coordination à une personne capable de suivre les réponses des applications connectées.

Faire évoluer l’IA et les habilitations ensemble

Avant d’ajouter une fonction d’IA, décrivez son intervention dans le travail du support. Qui relit une suggestion ? Qui peut corriger une classification ? Quelles actions sont possibles sur un compte et quelles situations imposent une intervention humaine ? La disponibilité commerciale d’une fonction ne répond pas à ces questions d’organisation.

Rapprochez les données accessibles du besoin annoncé. Une équipe chargée de traiter des questions générales n’a pas nécessairement besoin des pièces utilisées par un autre service pour examiner un dossier particulier. Limitez également les autorisations d’export, les comptes d’administration et l’installation de connecteurs. Ces mesures participent à la protection par défaut de l’Art. 25(2) et à la sécurité adaptée au risque de l’Art. 32(1).

Enfin, conservez un historique compréhensible des décisions : fonction activée, sources autorisées, choix relatifs à l’amélioration, contrôle humain et responsable de la revue. Lorsqu’une nouvelle utilisation change le risque, réexaminez l’analyse existante selon l’Art. 35(11), si une AIPD a été réalisée. Une capture des réglages à l’achat ne documente pas les usages plusieurs mois plus tard.

Ce qu’il faut retenir

• Réduisez les données et documents introduits dans les tickets.
• Paramétrez une suppression effective avec un point de départ maîtrisé.
• Distinguez modèles propriétaires et modèles génératifs tiers.
• Vérifiez l’hébergement et les droits pour chaque module et copie.

FAQ

Les tickets archivés sont-ils effacés ?

Non. L’archivage et la suppression sont des opérations distinctes. Les règles de conservation doivent prévoir le sort final des données.

L’hébergement européen couvre-t-il toute la suite ?

Il faut vérifier les engagements et exceptions service par service. L’éligibilité commerciale et la région effectivement activée comptent toutes deux.

Peut-on garder les tickets sans limite pour améliorer l’IA ?

Une fonction d’amélioration ne dispense pas de justifier les finalités, la base légale, l’information et la durée. Une conservation indéfinie ne devient pas licite parce qu’un outil peut exploiter l’historique.

Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.

Thiébaut Devergranne est docteur en droit et fondateur de donneespersonnelles.fr. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données personnelles.