Skip to main content

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.
Cette page décrit les contrôles de plateforme d’Orbit. Ce n’est pas un avis juridique. Vos obligations — quelles lois s’appliquent, ce que vous devez divulguer, et dans quel délai — dépendent du lieu de résidence de vos personnes concernées et des données que vous traitez. Confirmez auprès d’un conseil juridique qualifié.
Tous les endpoints ci-dessous sont racinés à https://api.orbit.devotel.io/api/v1/compliance.

Juridictions prises en charge et délais

Le applicable_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.
Retourne 202 Accepted :
Noteapplicable_jurisdiction ne prend gdpr par défaut que pour les droits qui existent sous le RGPD. Les types de demande opt_out_sale et limit_sensitive_pi sont propres à CCPA/CPRA et n’ont pas d’équivalent RGPD ; vous devez donc définir explicitement applicable_jurisdiction à ccpa ou cpra pour eux. L’omettre (ou laisser le défaut gdpr) est rejeté avec 422 VALIDATION_ERROR.

Cycle de vie des statuts

Une demande progresse ainsi : receivedprocessingcompleted avec des branches terminales failed, expired et cancelled. Le sous-état de vérification est suivi indépendamment : pendingverified (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 filtre status optionnel.
  • GET /compliance/dsar/{id} — récupère une demande. La réponse inclut l’export_url signée (et son export_expires_at) une fois qu’un export d’accès/portabilité a été produit, plus tables_exported dé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) et limit (≤ 500).
  • POST /compliance/dsar/erasure-requests/{id}/cancel — annule un effacement pending avant son exécution. reason optionnel (≤ 500 caractères). Retourne 409 s’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 :
Les niveaux de sévérité progressent proportionnellement à la fenêtre de SLA de chaque juridiction — les seuils en jours sont ancrés au cas RGPD de 30 jours et multipliés par le ratio 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.
La porte est fail-open quand DEVOTEL_TURNSTILE_SECRET_KEY n’est pas défini : begin accepte les requêtes sans token et consigne un seul avertissement. Définissez le secret en production, sinon le portail est sans protection Turnstile, même si toutes les autres défenses anti-abus ci-dessus s’appliquent toujours. Générez les deux clés dans le tableau de bord Cloudflare (Turnstile → Ajouter un site) et définissez-les respectivement sur les déploiements API et web.

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 dans GET /compliance/dsar aux côtés des demandes déposées par un opérateur.

Références associées