Skip to main content

​
Portail DSAR en libre-service de bout en bout

Devotel Orbit accepte les demandes des personnes concernées par deux canaux d’entrée : la saisie par vos opérateurs au nom de la personne et un portail public où la personne dépose elle-même. Une seule file alimente les deux. Ce guide parcourt le chemin du portail, de la publication du lien jusqu’à l’accomplissement, et montre comment il se combine avec la saisie par opérateur. La référence DSAR (EN) documente la surface des endpoints et la machine d’état publique e-mail/téléphone ; cette page est le runbook depuis lequel vous opérez.
Chaque contrôle ici appartient au tenant : vous publiez le lien, vous gérez la file, vous décidez et accomplissez. Orbit héberge le portail, prouve l’identité par un OTP à deux facteurs et suit les délais légaux — l’obligation légale de répondre reste chez vous, le responsable de traitement. Confirmez vos obligations avec votre conseil juridique.

​
1. Deux canaux d’entrée, une seule file

Saisie par opérateur. Votre équipe dépose une demande via POST /compliance/dsar ou la boîte de dialogue Create DSAR dans Settings → Compliance → DSAR. Une demande déposée ainsi démarre en verification_status: pending — aucun worker d’export ou de suppression n’y touche tant qu’un opérateur n’a pas approuvé ou rejeté la vérification d’identité. Ce canal convient actuellement aux personnes que vous connaissez déjà (un client connecté, un contact dans votre workspace), et aux droits que le formulaire public ne peut pas porter (correction, limit-sensitive-PI, non-discrimination). Portail public en libre-service. La personne concernée dépose sa propre demande via la page publique hébergée — sans compte, sans clé API, sans session. La page vérifie son identité par un OTP e-mail + SMS à deux facteurs avant que quoi que ce soit entre dans votre file, de sorte qu’un dépôt par portail arrive pré-vérifié et que le worker d’export ou de suppression démarre immédiatement. Opérez les deux. Le portail porte le volume grand public jusqu’à zéro intervention opérationnelle ; la saisie par opérateur couvre les cas limites que le portail ne peut pas traiter. Chaque demande, quel que soit le canal, atterrit dans la même liste Settings → Compliance → DSAR et la même réponse GET /compliance/dsar — une file, une bannière SLA, une chaîne d’audit.

​
2. Parcours du portail

​
Publier le lien

Hébergez le portail comme le lien « Déposer une demande de confidentialité » dans votre politique de confidentialité, le pied de page de votre site ou le centre de confidentialité de votre produit :
<locale> est le même préfixe de locale que chaque page web d’Orbit (en, fr, de, …). La page rend un formulaire d’identification en deux étapes derrière une vérification anti-bot Cloudflare Turnstile : la personne saisit son e-mail et son téléphone (E.164), choisit un type de demande, et la preuve d’identité commence.

​
Le prérequis expéditeur e-mail

Décidez de quelles adresses les codes de vérification du portail partent avant que le lien soit en ligne — un expéditeur non configuré laisse le portail échouer fermé en public. Deux expéditeurs niveau-plateforme se configurent une fois dans votre environnement API : Sans expéditeur SMS et sans repli plateforme, l’étape téléphone retourne 503 et le portail affiche un message « temporairement indisponible » ; sans clé de livraison e-mail, l’étape e-mail échoue de la même façon. En production, la première étape nécessite aussi un jeton Turnstile — configurez DEVOTEL_TURNSTILE_SECRET_KEY sur l’API et NEXT_PUBLIC_DEVOTEL_TURNSTILE_SITE_KEY sur le déploiement web, depuis le tableau de bord Cloudflare (Turnstile → Add site). Les codes de vérification SMS circulent sur le softswitch Devotel en tant qu’OTP plateforme — pas de trafic facturable au tenant.

​
Ce que la personne concernée voit

La personne complète une revendication en cinq étapes ; rien n’est mise en file tant que les deux preuves ne sont pas archivées :
  1. Begin — e-mail, téléphone (E.164), type de demande. Un OTP e-mail est envoyé immédiatement.
  2. Verify email — un code e-mail à 6 chiffres (TTL de 10 minutes, 3 tentatives, cooldown de renvoi de 60 secondes).
  3. Send phone code — un OTP SMS vers le même téléphone (cooldown de 60 secondes entre envois).
  4. Verify phone — un code SMS à 6 chiffres.
  5. Submit — la demande entre dans votre file uniquement avec les deux preuves. La revendication complète a un TTL total de 30 minutes.
Les types conviviaux que la personne choisit se mappent sur l’enum opérateur : Si les identifiants ne correspondent à aucun contact de votre workspace, l’étape submit répond toujours pareil — le portail ne révèle jamais si un contact existe — et la ligne d’audit est écrite au niveau plateforme pour que la trace forensique survive au cas sans correspondance.

​
La juridiction se mappe sur l’horloge SLA

La personne choisit la juridiction sous laquelle sa demande relève, et ce choix décide à la fois de l’horloge légale que la ligne porte et des valeurs de request_type que la file peut contenir : L’exactitude du pairing compte : opt_out_sale et limit_sensitive_pi n’ont pas d’équivalent GDPR, et la juridiction défaut des opérateurs est gdpr — réglez-la expressément pour les consommateurs californiques. Un dépôt portail de opt_out régle par défaut la juridiction sur CCPA/CPRA, précisément parce que le défaut GDPR serait sinon invalide. Une erreur de choix de la personne est corrigible : reclassifiez la juridiction depuis la file, et le badge SLA se ré-ancre.

​
3. Ce que les opérateurs voient après un dépôt

Un dépôt portail qui correspond à un contact atterrit dans Settings → Compliance → DSAR aux côtés des demandes opérateurs. Parce que l’OTP a déjà prouvé l’identité, il arrive comme verification_status: verified — aucun portail d’approbation/rejet ne le bloque.
  • Statut et échéance. La ligne porte le statut de cycle normal et un badge SLA Day X of N ancré sur la fenêtre de la juridiction ; tout dépassement déclenche la bannière SLA niveau workspace. GET /compliance/dsar/sla donne la même image par API.
  • Demandes de suppression. La personne qui a choisi « delete » apparaît dans la section portail de l’onglet Erasure requests (Art. 17), avec son badge SLA, avant la fenêtre de refroidissement de 7 jours par défaut.
  • Accomplissement. Une demande d’accès ou de portabilité passe à Completed avec une export_url signée ; l’action Download decrypted construit l’export en clair pour un opérateur. Une suppression exécutée offre le certificat Proof of deletion et Propagate vers vos destinations connectées.
  • Chaîne d’audit. Begin, les deux vérifications et submit écrivent des lignes avec des identifiants hachés (jamais en clair), l’IP source et le user agent — l’enregistrement dont votre dossier de preuves (EN) se remplit quand un régulateur demande comment l’identité a été établie.

​
4. Ce qu’Orbit ne fait pas

Le portail est la machinerie de l’entrée et de la preuve d’identité ; les décisions juridiques restent chez vous :
  • Orbit ne décide jamais de la validité. Il n’accepte ou ne rejette une demande sur aucune base légale. Les lignes en verification pending attendent votre décision d’approbation/rejet ; les lignes verified s’accomplissent parce que vous le permettez, pas parce que la plateforme a jugé la revendication.
  • Orbit ne s’auto-accomplit jamais sur une décision opérateur. Pour une demande opérateur, aucun export n’est produit et rien n’est supprimé tant que verification_status: pending. Un dépôt portail contourne le portail seulement parce que son OTP a déjà prouvé l’identité.
  • La suppression respecte votre posture de refroidissement. Le défaut de 7 jours (surrécrivable par tenant) vous donne la fenêtre pour rejeter, retenir ou exonérer avant la destruction.
  • L’identification de la loi applicable reste le travail de votre conseil. Orbit ancre l’horloge SLA sur la juridiction que la personne a choisie et que vous avez confirmée.
  • Le portail expose le sous-ensemble de droits conviviaux — une personne ayant besoin d’un droit opérateur-only (correction, limit-sensitive-PI, non-discrimination) dépose par votre équipe.

​
5. Exemple de bout en bout — une demande GDPR d’accès

Une cliente à Berlin ouvre votre politique de confidentialité, touche le lien du portail et demande tout ce que vous détenez. Séquence :
  1. Begin. Elle saisit son e-mail, son téléphone en E.164 (+4915…), choisit access et passe la vérification Turnstile. Le portail retourne une id de revendication ; l’OTP e-mail est déjà en route.
  2. Verify email. Elle lit le code à 6 chiffres (TTL de 10 minutes, jusqu’à 3 tentatives) et passe le premier facteur.
  3. Send phone code, Verify phone. Le second facteur se répète par SMS — avec un cooldown de 60 secondes entre envois — et les deux preuves sont désormais archivées.
  4. Submit. Le portail dépose la demande. Parce que son e-mail et son téléphone correspondent à un contact dans votre workspace, la ligne se met en file comme know sous gdpr et retourne une référence dsar_pub_….
  5. Dans votre file. La ligne affiche Day 1 of 30 — verification_status: verified — et le worker d’export l’a déjà. Personne dans votre équipe ne touche la triage.
  6. Accomplir. Le worker compile le export et marque la ligne Completed avec export_url et tables_exported. Un opérateur livre le lien de téléchargement (une copie en clair réservée aux opérateurs est à un clic de Download decrypted).
  7. Au-delà de la ligne SLA. Si la ligne est encore ouverte quand la fenêtre GDPR de 30 jours s’épuise, la bannière SLA du workspace la signale — et si elle avait mal choisi une juridiction à l’entrée, la reclassification depuis la file corrige l’horloge rétroactivement.
Temps entre la première soumission du formulaire de la personne et la demande mise en file : les deux allers-retours OTP. Interventions opérateur : zéro.

​
Références connexes