Demandes d’accès des personnes concernées (DSAR)
Une demande d’accès des personnes concernées (aussi appelée demande de vie privée ou demande de droits des consommateurs) est le mécanisme formel par lequel une personne exerce ses droits sur les données personnelles que vous détenez à son sujet — le droit à l’accès, à la suppression, à la rectification, à la portabilité, ou à l’opposition à la vente de ces données. La plupart des lois sur la vie privée vous imposent un délai strict de réponse (30 jours sous le RGPD, 45 sous CCPA/CPRA). Orbit vous offre deux chemins de réception et un pipeline de traitement :- DSAR déposée par un opérateur — votre équipe support ou conformité dépose une demande pour le compte d’un client via l’API authentifiée ou le tableau de bord.
- Portail public en libre-service — la personne concernée dépose sa propre demande via un flux public non authentifié qui prouve son identité par un OTP à deux facteurs e-mail + SMS avant que quoi que ce soit soit mis en file.
https://api.orbit.devotel.io/api/v1/compliance.
Juridictions prises en charge et délais
Leapplicable_jurisdiction d’une demande détermine quelle horloge légale
le suivi des SLA d’Orbit applique. Les opérateurs peuvent reclasser une
demande après sa réception.
Types de demandes
request_type décrit ce que la personne demande. L’ensemble complet des
verbes CCPA/CPRA est disponible pour les opérateurs ; le portail public
expose un sous-ensemble plus convivial qui s’y rattache.
Pour les demandes d’accès CCPA, vous pouvez aussi joindre
consumer_categories — les catégories CCPA §1798.100(b) que la personne
demande : identifiers, customer_records,
protected_classifications, commercial, biometric,
internet_activity, geolocation, sensory, professional,
education, inferences, sensitive_pi.
Demandes déposées par un opérateur
Créer une demande
POST /compliance/dsar — nécessite une clé API admin ou propriétaire.
Fournissez au moins un identifiant de personne (contact_id,
subject_email ou subject_phone) plus l’requester_email qui doit
recevoir la correspondance.
202 Accepted :
Note —applicable_jurisdictionne prendgdprpar défaut que pour les droits qui existent sous le RGPD. Les types de demandeopt_out_saleetlimit_sensitive_pisont propres à CCPA/CPRA et n’ont pas d’équivalent RGPD ; vous devez donc définir explicitementapplicable_jurisdictionàccpaoucprapour eux. L’omettre (ou laisser le défautgdpr) est rejeté avec422 VALIDATION_ERROR.
Cycle de vie des statuts
Une demande progresse ainsi :received → processing → completed
avec des branches terminales failed, expired et cancelled. Le
sous-état de vérification est suivi indépendamment :
pending → verified (le worker continue) ou rejected (le worker
s’arrête). Les lignes RGPD/déposées par un admin prennent par défaut
not_required.
Vérifier ou rejeter l’identité
Les demandes à plus haute assurance (delete, opt-out, limit-sensitive) exigent une décision d’opérateur avant que le traitement ne poursuive :decision vaut verified ou rejected ; notes est optionnel
(≤ 2048 caractères). Retourne le nouveau verification_status et
verified_at.
Annuler une demande
POST /compliance/dsar/{id}/cancel retire une demande en cours
(RGPD Art 7(3)). Fonctionne seulement tant que la demande est received
ou processing ; une demande terminale retourne 409 Conflict.
Lister et lire les demandes
GET /compliance/dsar— liste paginée. Requête :page(≥ 1),page_size(≤ 100, défaut 25), et un filtrestatusoptionnel.GET /compliance/dsar/{id}— récupère une demande. La réponse inclut l’export_urlsignée (et sonexport_expires_at) une fois qu’un export d’accès/portabilité a été produit, plustables_exporteddécrivant les nombres de lignes par table.
Demandes d’effacement
Les effacements RGPD Art 17 sont suivis comme une ressource à part, pour que vous puissiez auditer et intervenir avant que les données soient détruites :GET /compliance/dsar/erasure-requests— liste. Requête :status(pending,cancelled,executing,executed,failed) etlimit(≤ 500).POST /compliance/dsar/erasure-requests/{id}/cancel— annule un effacement pending avant son exécution.reasonoptionnel (≤ 500 caractères). Retourne409s’il est déjà en exécution ou terminé.
Tableau de bord des SLA
GET /compliance/dsar/sla retourne un instantané combiné des SLA export +
effacement, pour ne jamais manquer un délai légal :
slaDays / 30, de sorte qu’une
demande passe toujours en amber puis en red à la même fraction de son
propre délai. escalation_due bascule 5 jours avant le délai légal
(slaDays − 5).
Pour le RGPD (sla_days: 30) : vert (< 20 jours écoulés),
ambre (20–25), rouge (26–30), rouge + breach (> 30) ;
escalation_due au jour 25.
Pour CCPA/CPRA (sla_days: 45), les mêmes ratios donnent vert
(< 30), ambre (30–38), rouge (39–45), rouge + breach (> 45) ;
escalation_due au jour 40. Lisez toujours les bornes des niveaux par
rapport au sla_days retourné pour cette demande, pas aux chiffres fixes
20/25/30.
Portail public en libre-service
Le flux public permet à une personne concernée de déposer une demande sans compte. L’identité est prouvée par un OTP à deux facteurs — un code e-mail et un code SMS — avant que toute demande soit mise en file. Les endpoints vivent sous/compliance/public/dsar et ne sont pas
authentifiés, mais sont défendus par Cloudflare Turnstile, des limites de
débit par IP et par identifiant, et une forme de réponse préservant la vie
privée qui ne révèle jamais si une paire e-mail/téléphone correspond à un
contact réel.
Les codes de vérification SMS sont livrés via le softswitch de Devotel
(le seul chemin SMS sortant de la plateforme). Ce sont des OTP de
plateforme, pas du trafic facturable au tenant, et ils ne portent aucune
persistance de reçus de livraison.
Aperçu du flux
1
Démarrer
POST /compliance/public/dsar/begin avec email, phone (E.164),
request_type (access | delete | portability | opt_out), et un
turnstile_token Cloudflare (requis en production). Retourne un
claim_id opaque, email_sent: true, et expires_in: 600. Un OTP
e-mail est envoyé immédiatement.2
Vérifier l'e-mail
POST /compliance/public/dsar/verify-email avec claim_id et le
code à 6 chiffres. Retourne l’état email_verified et l’étape
suivante phone_send. Les codes expirent après 10 minutes ; 3
tentatives max. POST …/resend-email (avec claim_id + email) émet
un nouveau code, sous réserve d’un cooldown de 60 secondes.3
Envoyer le code SMS
POST /compliance/public/dsar/send-phone avec claim_id et le phone
qui correspond à celui donné au démarrage. Envoie un OTP SMS
(expires_in: 600). Un cooldown de 60 secondes s’applique entre les
envois ; une nouvelle tentative trop tôt retourne 429 avec
Retry-After.4
Vérifier le téléphone
POST /compliance/public/dsar/verify-phone avec claim_id et le
code à 6 chiffres. Retourne l’état phone_verified et l’étape
suivante submit.5
Soumettre
POST /compliance/public/dsar/submit avec claim_id. Persiste une
ligne d’audit et — seulement si l’e-mail + téléphone vérifiés
correspondent à un contact de votre tenant — met en file une vraie DSAR
(pré-marquée verification_status: verified, puisque l’OTP a déjà
prouvé l’identité). Retourne un reference_id (par ex. dsar_pub_…)
et un booléen queued.Configurer les expéditeurs de la preuve d’identité
Les deux OTP sont envoyés depuis des expéditeurs de niveau plateforme que vous configurez une fois dans votre environnement API. Définissez-les avant de publier le portail — un expéditeur SMS non défini sans repli fait échouer l’étape téléphone en mode fermé.
Si
DEVOTEL_DSAR_PROOF_SMS_FROM et DEVOTEL_PLATFORM_DEFAULT_FROM
sont tous deux non définis, l’étape send-phone échoue fermée avec un
503 — le portail retourne un message « temporairement indisponible » et
l’échec est émis sous la métrique dsar.proof.sms_send_failed afin qu’il
apparaisse dans vos tableaux de bord plutôt que de sauter silencieusement
le second facteur. De même, l’étape e-mail retourne 503 quand
DEVOTEL_RESEND_API_KEY n’est pas défini. Configurez les deux expéditeurs
avant de lier publiquement le portail.
Défenses contre les abus
La forme de réponse est identique, que les identifiants correspondent ou
non à un contact réel — le portail ne confirme ni n’infirme jamais que
quelqu’un se trouve dans votre base. Quand Redis est indisponible, les
portes de limitation échouent ouvertes (fail-open) pour préserver la
disponibilité.
Activer la protection Turnstile
La porte Turnstile se configure avec deux variables d’environnement.Héberger le lien du portail
Publiez le portail public dans votre politique de confidentialité comme lien « Soumettre une demande de vie privée ». Comme le flux s’auto-vérifie par OTP, les demandes qui arrivent par là sont déjà prouvées en identité — elles atterrissent dans votre file d’opérateur prêtes à être traitées, et apparaissent dansGET /compliance/dsar aux côtés des demandes déposées
par un opérateur.
Références associées
- Construire une posture RGPD de bout en bout — où s’inscrit la réception des DSAR dans la séquence complète.
- Gestion du consentement — enregistrer et consulter l’état de consentement qu’une DSAR peut vous demander d’honorer.
- Listes de désinscription et suppression —
comment les résultats
delete/opt_outalimentent la suppression. - Consentement à l’enregistrement des appels — traiter les enregistrements référencés par une demande d’accès.
- Référence API → Compliance — schémas requête/réponse complets (régénérés depuis l’API en direct).