Skip to main content

​
Assembler une posture GDPR de bout en bout

Le groupe Compliance documente chaque contrôle GDPR sur sa propre page : registres de consentement, désinscription et suppression, centre de préférences, réception des DSAR, registre Art. 30, DPA, classeur de preuves. Ce guide est la séquence à travers tous ces éléments — l’ordre dans lequel un tenant assemble réellement une posture GDPR, et ce que chaque étape laisse derrière elle comme preuve. Il prolonge la Posture B de la carte des postures en un parcours complet.
Cette page décrit les contrôles de la plateforme Orbit. Elle ne constitue pas un avis juridique. Les obligations qui s’appliquent à vous — responsable de traitement ou sous-traitant, base légale appropriée, nécessité ou non d’une DPIA — dépendent de vos traitements. Faites-les confirmer par un conseiller qualifié.

​
Le cadre tenant-owned

Lisez ceci d’abord, car cela façonne tout ce qui suit. La surface GDPR d’Orbit suit le même modèle que le reste de la carte de conformité (aperçu des postures) :
  • Chaque contrôle ici est ouvert ou vide par défaut. Un nouveau tenant n’a aucun registre de consentement, aucune limitation d’heures calmes, aucune activité dans le registre, aucune acceptation de DPA et aucune génération de classeur. Rien sur cette page n’est imposé, et rien ici ne bloque l’envoi par soi-même. Vous assemblez la posture ; la plateforme applique ce que vous avez configuré, pas une posture qu’elle aurait choisie pour vous.
  • Orbit est le conduit et le registre. Il transporte votre trafic, applique les limitations que vous configurez et tient le registre auditable. Il ne décide jamais de votre base légale, ne dépose jamais de dossier auprès d’une autorité de contrôle pour vous et ne signe jamais de DPA en votre nom.
  • Le classeur reflète ce que vous avez fait. Un registre vide s’exporte comme un registre vide. Assemblez la posture d’abord ; exportez ensuite.

​
Section 1 — La carte de la surface GDPR

Une ligne par obligation à laquelle un opérateur GDPR doit généralement répondre, associée au contrôle Orbit qui la couvre et à la page détaillée qui la documente. Deux contrôles adjacents complètent la carte :
  • Les heures calmes ne sont pas un article du GDPR, mais un destinataire européen soumis à un régime marketing local s’y attend — configurez-les avec le reste (Quiet hours configuration).
  • La résidence des données vocales décide où les enregistrements d’appels et les transcriptions résident physiquement (Voice data residency) — un choix de résidence que vous documentez dans le registre, pas une limitation.

​
Section 2 — Une séquence complète pour un destinataire européen

Un parcours concret pour un tenant envoyant des campagnes drip à des destinataires européens. Chaque étape nomme ce que vous faites et quelles preuves cela laisse derrière.

​
1. Capturez le consentement avec une base légale avant le premier envoi

Enregistrez le consentement par canal via POST /compliance/consent, avec lawful_basis renseigné. Pour le marketing vers de nouveaux destinataires européens, il s’agit généralement de consent ; pour des clients existants recevant des messages de service, il peut s’agir de legitimate_interests — ce choix vous appartient, et Orbit enregistre quelle que soit la base que vous déclarez.
Preuve laissée derrière : une ligne de consentement par canal avec base, source et horodatage — exportable comme fichier de preuve de registre dans Export Consent & Suppression Records.

​
2. Configurez la fenêtre d’heures calmes de repli de la campagne

Définissez la fenêtre de repli dont chaque drip ou journey hérite quand la ligne de campagne n’a pas sa propre fenêtre — par exemple 22:00 → 07:00 heure locale du destinataire, ce qui correspond à une période calme marketing européenne courante. Dans le tableau de bord : Paramètres → Limites de campagne → Heures calmes par défaut. Par l’API : PUT /api/v1/campaigns/quiet-hours/settings. C’est le contrôle d’envoi à la plus forte valeur pour une posture européenne : une seule écriture couvre chaque campagne qui ne définit jamais ses propres horaires. Détails dans Quiet hours configuration. Preuve laissée derrière : les envois suspendus apparaissent dans les rapports avec la fenêtre résolue, et GET /api/v1/compliance/quiet-hours/preview répond à la question « cet envoi serait-il suspendu, et jusqu’à quand » avant le déploiement.

​
3. Câblez les chemins de retrait

Le consentement que vous avez capturé doit être facile à retirer — Art. 7(3). Trois points d’entrée aboutissent à la même liste de suppression :
  • les mots-clés STOP sur SMS/WhatsApp,
  • POST /compliance/consent avec opt_in: false,
  • le centre de préférences — configurez-le via POST /compliance/preference-center, puis remettez à chaque contact un lien signé pour que le retrait arrive de manière structurée plutôt qu’en ticket de support.
Si vous migrez depuis une autre plateforme, importez en masse l’ancienne liste via POST /compliance/suppression-list/import avant le premier envoi. Voir Opt-Out & Suppression Lists. Preuve laissée derrière : des lignes de suppression fail-closed — une adresse supprimée est abandonnée avant expédition quel que soit le point d’entrée.

​
4. Décidez de votre chemin de réception DSAR

Deux chemins, et la plupart des postures européennes utilisent les deux :
  • Déposée par l’opérateur — votre équipe dépose pour le compte d’un client avec POST /compliance/dsar (applicable_jurisdiction: "gdpr" démarre l’horloge SLA de 30 jours).
  • Portail public en libre-service — publiez le lien du portail sous votre politique de confidentialité pour que les personnes concernées déposent directement ; le flux vérifie l’identité avec une OTP deux facteurs e-mail + SMS avant toute mise en file.
Décidez depuis quels e-mails le portail envoie avant de le lier publiquement — un expéditeur non défini laisse le portail indisponible. Détail complet de réception et de vérification dans DSAR. Preuve laissée derrière : chaque demande porte son statut, son horloge SLA et son historique de traitement — les lignes que le classeur GDPR lit.

​
5. Déposez vos activités de traitement dans le registre

Avant l’arrivée du premier DSAR, documentez ce que vous faites. Enregistrez chaque activité dans le registre de confidentialité : finalité, catégories de données, destinataires, transferts transfrontaliers, période de rétention et mesures de sécurité. Orbit filtre chaque activité par rapport aux déclencheurs de l’Art. 35(3) et signale une DPIA requise — une activité signalée ne peut pas passer à l’état actif tant que la DPIA n’est pas enregistrée. Preuve laissée derrière : une référence humaine par activité (par exemple ROPA-2026-0004) et un inventaire exportable que vous pouvez remettre à une autorité de contrôle en vertu de l’Art. 30(4).

​
6. Exécutez le DPA

Prévisualisez le modèle, acceptez-le avec l’e-signature saisie et archivez la copie exécutée — le tout via GET/POST /api/v1/compliance/dpa ou le tableau de bord. L’acceptation est une formalité contractuelle au titre de l’Art. 28 : cela ne change rien à ce qu’Orbit traite et ne bloque rien. Tant que vous n’acceptez pas, votre dpa_status reste not_accepted — un élément ouvert que toute revue d’achat trouvera. Voir Data Processing Agreement. Preuve laissée derrière : le registre d’acceptation — version du modèle, signataire, horodatage — et la copie exécutée rendue.

​
7. Exportez le classeur GDPR pour un achat ou une autorité

Lorsqu’une revue de sécurité d’acheteur ou une autorité demande la posture complète, générez le classeur du cadre GDPR depuis Paramètres → Conformité → Classeur (ou POST /api/v1/compliance/binder/generate). Il assemble l’historique des demandes de personnes concernées, les compteurs de violations, et la posture de consentement et de rétention dans un pack avec un lien de téléchargement signé de 24 heures — PDF pour un lecteur humain, ZIP pour un import GRC. Voir Evidence Binder. Exécutez le classeur en dernier. Il lit les surfaces que les étapes 1 à 6 ont remplies, donc générer avant ces étapes remet au lecteur un pack vide.

​
Section 3 — Bundles d’activation pertinents pour le GDPR

Le plugin marketplace groupe deux points de départ pertinents pour le GDPR, tous deux activés via GET /api/v1/compliance/vertical-bundles : Chaque activation est en brouillon uniquement et s’accompagne d’une checklist de mise en production — aucun bundle n’active une posture GDPR par soi-même, et en activer un n’enregistre jamais de consentement, ne dépose jamais d’activité de registre et n’accepte jamais de DPA pour vous. Les bundles raccourcissent la mise en place ; la séquence ci-dessus reste la vôtre. Voir Plugin Marketplace.

​
Section 4 — Ce qu’Orbit NE fait PAS

Conditions limites, énoncées une seule fois et clairement :
  • Orbit ne dépose jamais de dossier auprès d’une autorité de contrôle pour vous. La notification de violation à une autorité (Art. 33) et aux personnes concernées (Art. 34) sont vos actes. Le classeur présente votre posture de comptage de violations comme preuve ; le dépôt vous appartient.
  • Orbit ne signe ni n’accepte jamais automatiquement le DPA. La e-signature saisie est un acte délibéré du propriétaire ou de l’administrateur de votre workspace.
  • Orbit ne décide jamais de votre base légale, période de rétention, ni si une DPIA est adéquate. Le registre filtre et signale ; les jugements qu’il enregistre sont les vôtres.
  • Rien sur cette page ne bloque l’envoi. Les registres de consentement, le registre, le DPA et le classeur sont le grand-livre. Les limitations d’envoi qui existent — heures calmes que vous avez activées, entrées de suppression que vous avez enregistrées — sont celles que vous avez activées, et chacune est ouverte par défaut.
  • Ceci n’est pas un avis juridique. La séquence assemble les contrôles d’Orbit ; le fait que la posture assemblée satisfasse au GDPR pour vos traitements relève de votre conseiller.

​
Références associées