Modèle de workflow RGPD pour exportation, rectification et suppression : rôles, approbations, délais et enregistrements de preuve d'exécution que vous pouvez garder dans votre app.
Un workflow de demandes RGPD fait la différence entre gérer les demandes de confidentialité sereinement et paniquer à chaque nouvel email. Les personnes peuvent vous demander d'exporter leurs données personnelles (accès), de les corriger (rectification) ou de les supprimer (effacement). Ces demandes sont normales pour toute application qui stocke des profils, messages, commandes, tickets de support ou identifiants analytiques.
Une gestion ad hoc se casse rapidement. Une demande arrive dans la boîte mail de quelqu'un, est transférée, et se transforme en vérifications manuelles de base de données et captures d'écran. Les délais sont dépassés, les données de la mauvaise personne peuvent être exportées par erreur, et les équipes oublient les données qui vivent en dehors de la base principale (outils email, prestataires de paiement, ou journaux). Le plus grand manque est généralement le même : aucune piste d'audit claire qui prouve ce que vous avez fait et quand.
Un workflow bien conçu rend les demandes prévisibles et reproductibles. Il doit produire trois résultats : rapidité (la demande va aux bons responsables avec dates d'échéance et rappels), exactitude (l'export, la correction ou la suppression est complète dans les bons systèmes), et preuve (vous pouvez montrer des enregistrements de preuve d'exécution avec approbations, horodatages et les données concernées).
La portée compte. Le workflow doit couvrir les données dans votre application (base de données, fichiers et outils d'administration internes) et les systèmes connectés que votre app utilise (paiements, messagerie, CRM, analytics, sauvegardes et stockage cloud). Un exemple simple : un utilisateur demande la suppression, mais son email existe toujours dans votre outil de support et son identifiant client reste dans Stripe. Sans portée définie, vous « terminez » la demande tout en conservant des données personnelles.
Si vous construisez cela sur une plateforme comme AppMaster, l'objectif est d'associer chaque type de demande à un ensemble cohérent d'étapes, de rôles et de résultats enregistrés, pour que la conformité ne dépende pas de la personne de garde.
Une demande RGPD, c'est quand une personne vous demande de faire quelque chose avec ses données personnelles. Les données personnelles sont toute information pouvant identifier directement ou indirectement quelqu'un, comme un nom, un email, un identifiant d'appareil ou l'historique d'un ticket de support.
En termes simples, vous pouvez être responsable du traitement (controller) — vous décidez pourquoi et comment les données sont utilisées — ou sous-traitant (processor) — vous traitez les données pour quelqu'un d'autre. Beaucoup d'apps jouent les deux rôles selon la fonctionnalité, donc votre workflow doit consigner quel rôle s'applique à chaque demande.
Les types les plus courants sont : accès (export), rectification (correction) et effacement (suppression). Traitez-les comme des parcours différents, car chacun présente des risques différents et nécessite des preuves différentes.
La plupart des demandes ont un délai de réponse, et le chronomètre commence généralement quand vous recevez la demande, pas quand c'est pratique. Votre workflow doit afficher les dates : reçu, vérifié, cadré et complété. Cela vous aide à éviter les délais manqués et fournit une piste d'audit propre si quelqu'un demande plus tard ce qui s'est passé.
Il faut assez d'information pour trouver les bons enregistrements, mais pas trop pour créer un risque de confidentialité. En général, vous devez savoir qui fait la demande (et comment vous allez la vérifier), quelle action est demandée (export, correction, suppression), quel compte ou identifiant rechercher, et où livrer la réponse (canal sécurisé).
Si la demande est vague, posez des questions de clarification au lieu de deviner.
Parfois vous pouvez limiter ou refuser une demande, par exemple si vous ne pouvez pas vérifier l'identité, si la demande est répétitive, ou si la loi vous oblige à conserver certains enregistrements (factures, par ex.). Même dans ce cas, enregistrez ce que vous avez décidé, pourquoi, et ce que vous avez fait à la place, comme une suppression partielle ou un export limité.
Un workflow RGPD fonctionne plus vite et plus sûr quand chaque étape a un responsable nommé. L'objectif est simple : une personne approuve, une autre exécute, et vous pouvez prouver ce qui s'est passé ensuite.
Commencez par un petit ensemble de rôles qui correspondent à l'organisation existante. Dans les petites équipes, la même personne peut couvrir plusieurs rôles, mais les permissions doivent rester séparées.
Une répartition pratique de type RACI ressemble à ceci :
La sécurité est généralement consultée plutôt que d'exécuter chaque étape. Elle aide à définir les contrôles d'identité, à revoir les schémas inhabituels (comme des demandes répétées) et à confirmer que les exports sont livrés en sécurité.
La séparation des tâches est cruciale pour la suppression. La personne qui peut appuyer sur le bouton de suppression ne doit pas être la seule à décider que la suppression est permise. Cela réduit les erreurs et le risque d'abus.
Pour éviter des dossiers bloqués, prévoyez la couverture et les transferts à l'avance : définissez un titulaire principal et un remplaçant pour chaque rôle (les vacances arrivent), un point d'escalade quand les délais sont en danger, exigez des notes d'état à chaque transfert, et conservez un seul dossier de cas avec horodatages et approbations.
Si vous créez cela comme outil interne (par exemple dans AppMaster), modélisez les rôles comme actions permissionnées : qui peut approuver, qui peut exécuter, et qui peut seulement voir. Cette structure rend le workflow auditable par défaut.
L'intake est là où le travail RGPD réussit ou échoue. Si les demandes arrivent à différents endroits et sont traitées au coup par coup, vous perdez du temps et une trace propre de ce qui a été fait. L'objectif est un cas suivi par demande, avec un propriétaire clair, des horodatages et une voie répétable.
Acceptez les demandes via un petit nombre de canaux, mais redirigez-les vers la même file. Beaucoup d'équipes utilisent un formulaire intégré à l'app (rapide et structuré), une boîte email pour la confidentialité, un portail de tickets support, et le suivi téléphonique ou chat qu'un agent enregistre (ne traitez jamais une demande uniquement à l'oral).
Qu'elle vienne de l'app ou par email, capturez les mêmes champs de base. Gardez le formulaire court, mais suffisamment précis pour retrouver le bon compte et comprendre la demande. Champs utiles : type de demande (export/accès, rectification, suppression), identifiants de compte (ID utilisateur, email, téléphone, numéro client), destination de livraison (téléchargement in-app, réponse par email vérifié, adresse postale si vraiment nécessaire), signaux d'identité déjà en votre possession (dernière connexion, ID de commande récent, 4 derniers chiffres d'un token de paiement sauvegardé, etc.), et un champ libre.
Créez un cas dès la réception. Utilisez une règle « une demande = un cas » pour pouvoir l'auditer plus tard. Donnez-lui un identifiant unique (par exemple RGPD-2026-00128) et enregistrez le canal, l'heure d'intake, les détails du demandeur et qui possède l'étape suivante.
Envoyez rapidement un accusé de réception, même si vous ne pouvez pas agir tout de suite. Restez factuel : confirmez l'ID du cas, dites que vous allez vérifier l'identité et donnez un délai réaliste. Évitez les promesses comme « nous supprimerons tout immédiatement ». Expliquez la suite, ce dont vous avez besoin (le cas échéant) et comment vous confirmerez la clôture du dossier.
Les contrôles d'identité doivent être proportionnés. Si quelqu'un demande simplement une copie de son profil depuis un compte connecté, vous n'avez généralement pas besoin du même niveau de vérification que pour une suppression qui peut affecter commandes, factures ou espaces d'équipe.
Une bonne règle : vérifiez avec des signaux dont vous disposez déjà, pas en collectant de nouveaux documents sensibles.
Commencez par l'option la plus sûre : confirmez que le demandeur contrôle le compte que vous connaissez déjà.
Cela évite de créer une nouvelle pile de documents d'identité sensibles qui nécessitent protection, règles de conservation et réponse en cas de violation.
Parfois une demande vient d'un avocat, d'un parent ou d'un mandataire. Demandez deux choses : la preuve de l'identité de la personne concernée (en utilisant l'approche minimale ci-dessus) et la preuve d'autorité.
En pratique, cela signifie souvent une autorisation signée par la personne concernée plus un moyen de la confirmer (par exemple une réponse depuis l'email du compte enregistré). Si le mandataire fait partie de la même organisation (comme un admin agissant pour un employé), documentez la politique interne et limitez ce que l'admin peut demander.
Si vous ne pouvez pas vérifier l'identité, ne traitez pas la demande. Demandez le minimum d'informations supplémentaires nécessaires, mettez le workflow en pause et consignez chaque étape (ce que vous avez demandé, quand et ce que vous avez reçu). Supprimez tout artefact de vérification une fois la vérification terminée.
Avant d'exporter, modifier ou supprimer des données, vous avez besoin d'une étape de tri. C'est là que la plupart des problèmes sont évités : systèmes manqués, mauvais type de demande, ou travail commencé avant de savoir ce qui est réellement demandé.
Écrivez la portée en langage clair. Répondez à trois questions : quelles données, où elles sont stockées et quelle période est concernée. Vérifiez aussi si quelque chose nécessite de suspendre ou limiter l'action, comme un litige en cours, une enquête pour fraude, ou une conservation légale.
Une checklist de tri simple couvre : ce que la personne demande (accès/export, correction, suppression ou mixte), quels systèmes peuvent contenir ses données (base de l'app, boîte support, facturation, analytics), quels identifiants utiliser pour retrouver les enregistrements (email, ID utilisateur, téléphone, numéro de commande), quelle période s'applique (tous les temps vs période spécifique), et les contraintes éventuelles (conservation légale, compte partagé, ou données affectant une autre personne).
Classifiez tôt les demandes mixtes. « Envoyez-moi mes données puis supprimez mon compte » doit devenir deux sorties suivies : un paquet de données et une action de suppression, chacune avec sa propre approbation et preuve.
Décidez si une revue manuelle est requise. Déclencheurs : données sensibles, comptes partagés, enregistrements qui mentionnent d'autres personnes, ou tout élément exposant des notes internes. Dans ces cas, ajoutez une étape de relecteur avant l'envoi ou la suppression.
Fixez des délais internes et des points d'escalade. Les délais RGPD sont stricts, visez donc une cible interne courte (par ex. tri sous 2 jours ouvrés) et définissez qui est notifié si le dossier stagne.
Exemple : un utilisateur demande la suppression, mais le tri révèle des factures impayées et des tickets support mentionnant d'autres clients. Vous pouvez toujours poursuivre, mais probablement avec une suppression partielle, conservation des enregistrements financiers et une signature d'un réviseur documentée. Dans des outils comme AppMaster, c'est plus simple à gérer quand les changements de statut, approbateurs et notes de clôture sont capturés au même endroit.
Un bon flux d'accès n'est pas « vider toutes les données ». C'est pouvoir expliquer, plus tard, exactement ce que vous avez recherché, ce que vous avez livré et pourquoi.
Commencez par tenir à jour une carte simple des données utilisateur. Pour un utilisateur, listez où ses données peuvent résider : tables de profil, commandes et factures, tickets support, messages de chat, fichiers uploadés, événements d'audit et journaux que vous avez inclus dans la portée. Incluez les systèmes tiers aussi (par ex. enregistrements du prestataire de paiement) pour ne pas les oublier dans l'urgence.
Ensuite, exécutez l'export selon une séquence prévisible :
Exemple : un client demande son export, mais vos notes support mentionnent un autre client par nom. Incluez la note en ayant retiré les identifiants de l'autre personne et consignez la redaction effectuée et la raison.
Si vous construisez cela dans un outil comme AppMaster, traitez la génération d'export et l'approbation d'envoi comme des étapes séparées. Cela facilite l'ajout d'une seconde vérification et crée des enregistrements plus propres si vous devez montrer ce qui a été livré et quand.
Une demande de rectification signifie qu'une personne dit qu'une donnée la concernant est incorrecte et souhaite qu'elle soit corrigée. L'objectif est de corriger ce qui doit l'être, sans réécrire silencieusement des enregistrements qui doivent rester comme preuves historiques.
Décidez ce que couvre la « correction » dans votre app. Exemples fréquents : champs de profil (nom, email, adresse), paramètres de compte et préférences. Cela peut aussi concerner du contenu généré par l'utilisateur (nom d'affichage sur un commentaire) et certaines métadonnées transactionnelles (numéro de téléphone de livraison incorrect). Traitez les enregistrements financiers et d'audit avec une attention particulière.
Les règles d'approbation gardent le support rapide mais sûr. Répartition pratique : le support peut corriger les champs de profil à faible risque (typos, formatage) après vérification basique ; un propriétaire de données (ou le responsable confidentialité) approuve les changements des champs d'identité ou liés à la facturation et l'accès ; l'ingénierie revoit les corrections qui affectent des tables transactionnelles ou des intégrations.
Votre piste d'audit doit capturer l'ancienne valeur, la nouvelle valeur, la raison, qui a modifié, quand et à quelle demande cela appartenait. Si vous utilisez AppMaster, vous pouvez modéliser cela comme une table dédiée « Rectification Log » dans le Data Designer et faire respecter les approbations dans le Business Process Editor.
En cas de désaccord sur l'exactitude, enregistrez les deux positions et mettez la modification en pause pendant l'enquête. Évitez aussi de réécrire des historiques qui doivent rester intacts (factures, journaux de sécurité). Ajoutez plutôt une entrée corrective ou une annotation afin que l'historique reste fidèle tandis que les données courantes deviennent exactes.
Une demande de suppression RGPD paraît simple jusqu'à ce que vous rencontriez des dépendances : factures que vous devez garder, signaux de fraude à ne pas effacer, ou tickets support qui font référence à d'autres personnes. Traitez la suppression comme un travail contrôlé avec points de décision clairs et une traçabilité.
Commencez par choisir l'une des trois issues selon ce que vous stockez et ce que vous devez conserver :
Écrivez la raison dans le dossier, surtout si vous ne pouvez pas supprimer entièrement pour des obligations légales.
Mappez les données de l'utilisateur vers les systèmes qui pourraient bloquer ou modifier l'approche : paiements et factures, indicateurs antifraude, historique support, analytics produit, logs email/SMS et fichiers uploadés.
Si un enregistrement de paiement doit être conservé, vous pouvez souvent supprimer ou anonymiser le profil utilisateur tout en gardant une facture avec des champs minimaux. Pour l'historique support, pensez à rédiger les noms et emails tout en conservant la conversation pour la qualité.
Conservez des étapes cohérentes pour pouvoir prouver l'achèvement ensuite.
Si vous construisez cela dans AppMaster, traitez la suppression comme un Business Process avec états explicites, approbations et tâches réessayables.
Envoyez des instructions de suppression aux tiers (paiements, messagerie, analytics) et consignez leurs confirmations. Conservez la preuve d'exécution : logs d'exécution du job, horodatages, l'ID de l'opérateur ou de l'automatisation, et une note de clôture listant ce qui a été supprimé, anonymisé ou conservé et pourquoi.
La plupart des manquements à la conformité ne viennent pas d'une mauvaise intention. Ils arrivent parce que le travail est dispersé entre threads d'email, messages de chat et corrections rapides.
Le premier piège est l'absence d'un identifiant de dossier unique. Sans un cas centralisé, vous ne pouvez pas prouver qui a demandé quoi, quand vous avez vérifié l'identité, ce que vous avez fait et quand vous avez fini.
Un autre piège est l'absence d'approbations. Si la même personne peut approuver et exécuter, une erreur peut passer inaperçue. Même une vérification à deux personnes légère aide, surtout pour la suppression et les exports.
La suppression échoue dans les deux sens. La sur-suppression enlève des données nécessaires pour la sécurité, la prévention de la fraude ou les obligations légales et comptables, sans revue. La sous-suppression est plus fréquente : suppression de la ligne principale de la base sans toucher les pièces jointes, journaux, événements analytics, index de recherche, caches et jobs en arrière-plan qui peuvent recréer les données plus tard.
Les exports présentent aussi des risques. Récupérer des données depuis plusieurs sources peut provoquer des erreurs de jointure incluant les données d'un autre utilisateur. Les notes internes sont un autre problème fréquent : des commentaires comme « suspicion de fraude » ou « remise VIP » peuvent se retrouver dans l'export alors qu'ils étaient destinés au personnel.
Exemple : un agent support exporte « tous les tickets » pour un client, mais la requête inclut aussi des messages d'une boîte partagée ou d'un contact fusionné. C'est un incident de confidentialité créé par un raccourci « utile ».
Des garde-fous simples préviennent la plupart de ces problèmes : créez un identifiant de dossier unique et enregistrez chaque action sous ce cas ; séparez les rôles intake, approbation et exécution ; maintenez une carte des données (tables, fichiers, journaux, recherche, caches, jobs asynchrones) ; utilisez des modèles d'export ciblés et testez avec des comptes factices ; et enregistrez des preuves d'achèvement (ce qui a été changé ou supprimé, par qui et quand).
Si vous construisez cela dans AppMaster, traitez le cas comme un objet de première classe et faites en sorte que chaque étape du workflow écrive automatiquement une entrée d'audit.
Un bon workflow de demandes RGPD est facile à exécuter un jour chargé et facile à prouver ensuite. Si vous pouvez répondre rapidement à deux questions — qu'avons-nous fait et quand l'avons-nous fait — vous êtes en bonne posture.
Utilisez une checklist cohérente pour chaque cas (accès, correction ou suppression) : enregistrez l'intake et attribuez un ID de cas, un propriétaire et une date d'échéance ; vérifiez l'identité avec une méthode sûre et consignez comment elle a été vérifiée (sans stocker les documents bruts) ; cadrer la demande (produits, comptes, plage temporelle, sources de données) ; obtenez les approbations nécessaires (responsable confidentialité, juridique, propriétaire système) ; exécutez, confirmez auprès du demandeur et sauvegardez les preuves d'exécution.
Pour la preuve, vous n'avez pas besoin de stocker plus de données personnelles. Vous avez besoin de métadonnées fiables. Au minimum, conservez l'ID de cas, le type de demande, la méthode de vérification d'identité (pas les documents bruts), les horodatages de chaque étape, les noms ou rôles des approbateurs, les actions effectuées, et une référence au livrable (par ex. ID du fichier exporté, numéro de ticket ou ID du job de suppression).
Pour réduire les erreurs et accélérer les réponses, standardisez les messages clés afin que chaque demandeur reçoive des mises à jour claires et cohérentes. Gardez trois messages prêts : accusé de réception (ce que vous avez reçu, délai estimé et comment vous vérifierez l'identité), demande d'information (ce qui manque et comment le fournir), et clôture (ce que vous avez livré ou modifié, ce que vous n'avez pas pu faire et pourquoi, et comment faire appel).
Prochaines étapes : implémentez le workflow dans votre app pour qu'il ne vive plus dans des emails éparpillés. Modélisez le cas comme un enregistrement avec étapes de statut, attachez des références de preuves, et ajoutez des approbations basées sur les rôles ainsi que des journaux d'audit.
Les équipes construisent souvent cet outil interne RGPD dans AppMaster (appmaster.io) car vous pouvez définir la table de cas dans le Data Designer, configurer les approbations et les étapes d'exécution dans le Business Process Editor, et lier la piste d'audit à chaque changement d'état. Bien fait, le workflow devient reproductible, mesurable et défendable.
Quelle est la première chose à faire quand une demande RGPD arrive ?Créez immédiatement un dossier unique dès la réception de la demande, puis vérifiez l'identité, déterminez la portée des sources de données et lancez uniquement ensuite l'export/la rectification/la suppression. Traitez « accès », « rectification » et « suppression » comme des parcours distincts afin de conserver les bonnes approbations et preuves pour chacun.
Comment vérifier l'identité sans demander une copie de pièce d'identité ?Utilisez des signaux que vous possédez déjà plutôt que de collecter de nouveaux documents sensibles. Par défaut, vérifiez via le compte connecté ou en répondant uniquement à l'adresse email déjà enregistrée, et ajoutez une confirmation supplémentaire pour les actions à risque (par exemple la suppression).
Pourquoi avons-nous besoin d'un identifiant de dossier et d'une piste d'audit pour chaque demande ?Parce que c'est la seule façon de prouver ce qui a été fait ensuite. Un dossier avec un identifiant, des horodatages, des responsables, des approbations et des notes de clôture vous aide à éviter des délais manqués, les confusions du type « quelqu'un l'a déjà traité » et fournit des preuves si la personne concernée ou un régulateur demande des détails.
Quelles informations devons-nous collecter à l'intake (et quoi éviter) ?Recueillez juste ce qu'il faut pour retrouver les bons enregistrements et livrer la réponse en sécurité : type de demande, identifiants de compte, canal de livraison préféré et méthode de vérification d'identité. Évitez de collecter des données personnelles supplémentaires « au cas où », car cela crée de nouveaux risques et du travail de conservation.
Que signifie vraiment « définir la portée » d'une demande ?Définir la portée, c'est écrire ce que vous allez chercher, où cela peut se trouver et quelle période est pertinente. Par défaut pratique, incluez votre base de données d'application ainsi que les outils connectés comme paiements, support, messagerie, analytics, stockage de fichiers et sauvegardes sur lesquels vous pouvez raisonnablement agir.
Quelle est la façon la plus sûre de traiter une demande d'accès (export de données) ?Générez un paquet structuré (souvent JSON ou CSV) et ajoutez un court résumé en langage courant pour que la personne comprenne. Relisez pour détecter les données d'autres personnes et les notes internes avant la livraison, et enregistrez précisément quels systèmes ont été consultés et quels fichiers ont été produits.
Comment traiter une demande de rectification sans casser l'historique ?Corrigez par défaut les données de profil courantes, mais n'écrasez pas les enregistrements qui doivent rester historiquement exacts (factures, journaux de sécurité). Quand on ne peut pas réécrire, ajoutez une note corrective ou une entrée complémentaire, et consignez l'ancienne valeur, la nouvelle, qui a changé quoi et quand.
Faut-il tout supprimer lorsqu'une personne demande l'effacement ?Pas toujours. Décidez cela dès le dossier. La bonne issue est souvent une suppression partielle ou une anonymisation tout en conservant les enregistrements légalement requis (par exemple les documents financiers). Documentez ce qui a été conservé et la raison dans la note de clôture.
Quelles sont les erreurs les plus courantes des équipes face aux demandes RGPD ?Sur-supprimer (enlever des données que vous devez garder) et sous-supprimer (oublier fichiers, journaux, caches, index de recherche ou services tiers) sont les deux erreurs majeures. Autre problème fréquent : exporter des données qui incluent par erreur les informations d'une autre personne à cause de jointures, contacts fusionnés ou boîtes partagées.
Comment implémenter ce workflow comme outil interne dans AppMaster ?Modélisez la requête comme une table “case” avec états, responsables, dates d'échéance et références de preuves, puis faites respecter les approbations et l'exécution comme actions permissionnées. Dans AppMaster, on utilise généralement le Data Designer pour la table de cas et les journaux d'audit, et le Business Process Editor pour implémenter les flux récurrents et les écritures d'audit automatiques.
21 janv. 2026
8 min
20 janv. 20268 min
20 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
