Droit à l'effacement (RGPD art. 17)

Procédure technique pour supprimer les données d'un visiteur collectées par le snippet Korvus — à la demande du visiteur, via votre équipe DPO.

Contexte

Korvus agit comme sous-traitant au sens de l'article 28 du RGPD ; vous, éditeur du site, êtes le responsable de traitement. Lorsqu'un visiteur vous demande la suppression de ses données (art. 17 RGPD), vous devez pouvoir y répondre dans un délai d'un mois maximum (art. 12).

Cette page décrit le helper technique que Korvus vous fournit pour exécuter cette suppression sur les données collectées via notre snippet : raw_events, pageviews, sessions.

Ce qui est supprimé

• Sessions du visiteur pour le website concerné
• Pageviews associées à ces sessions
• Events bruts (raw_events) associés à ces sessions

Ce qui n'est pas supprimé

Les tables products et product_history contiennent uniquement des métadonnées produit agrégées (SKU, prix observé, disponibilité) — aucune donnée personnelle, aucun identifiant visiteur. Elles ne sont donc pas concernées par une demande d'effacement.

Les alertes (alert_events) et baselines (baselines) sont agrégées au niveau du site, jamais au niveau du visiteur. Seule exception : une preuve vidéo, lorsqu'elle existe, est rattachée à la session où l'incident s'est produit. Elle n'est accessible que depuis le dossier de cet incident, jamais par recherche sur un visiteur, et elle est purgée avec le reste des données.

Endpoint technique

POST https://app.korvus.fr/api/internal/data-subject-request

Authentification

Header Authorization: Bearer <INTERNAL_API_SECRET>. Le secret vous est communiqué hors bande par votre référent Korvus — jamais dans un navigateur, toujours depuis un backend ou un terminal sécurisé.

Corps de requête

Deux modes exclusifs (l'un des deux, pas les deux) :

{
  "website_id": "uuid-de-votre-site",
  "session_id": "uuid-de-la-session-du-visiteur"
}

ou :

{
  "website_id": "uuid-de-votre-site",
  "created_after": "2026-04-01T00:00:00Z"
}

Exactement un des deux champs session_id ou created_after doit être fourni.

Réponse

{
  "deleted": {
    "sessions": 1,
    "pageviews": 12,
    "events": 84,
    "dup_archive": 0,
    "proofs": 2
  },
  "clickhouse": { "status": "ok" }
}

dup_archive correspond aux doublons de session archivés lors du dédoublonnage, proofs aux preuves vidéo (objets de stockage et métadonnées).

Vérifiez clickhouse.status. Il vaut ok, skipped ou failed. Un failed est renvoyé avec un code HTTP 200 — la suppression a bien eu lieu dans la base principale, mais pas dans l'index analytique. Dans ce cas, relancez la même requête : elle est idempotente.

Codes d'erreur

Limite de 30 jours sur created_after

Un appel ne peut pas viser plus de 30 jours en arrière : cette borne protège les tables de collecte d'un verrouillage prolongé qui interromprait la mesure de tous nos clients.

Pour effacer un historique plus ancien, enchaînez plusieurs appels par fenêtres de 30 jours, du plus récent au plus ancien :

# Effacer 90 jours d'historique = 3 appels successifs
for OFFSET in 0 30 60; do
  SINCE=$(date -u -d "$((OFFSET + 30)) days ago" +%Y-%m-%dT%H:%M:%SZ)
  curl -X POST https://app.korvus.fr/api/internal/data-subject-request \
    -H "Authorization: Bearer $KORVUS_INTERNAL_SECRET" \
    -H "Content-Type: application/json" \
    -d "{\"website_id\": \"$WEBSITE_ID\", \"created_after\": \"$SINCE\"}"
done

Un seul appel sur une fenêtre trop large renvoie un 400 sans rien effacer : ne le confondez pas avec un succès partiel.

Exemple curl

curl -X POST https://app.korvus.fr/api/internal/data-subject-request \
  -H "Authorization: Bearer $INTERNAL_API_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "website_id": "00000000-0000-0000-0000-000000000000",
    "session_id": "11111111-1111-1111-1111-111111111111"
  }'

Garanties

• Transactionnel : la suppression raw_events + pageviews + sessions + archive de déduplication s'exécute dans une transaction SQL unique. Si une étape échoue, tout est annulé — aucun état partiel.
• Scopé au website : un DELETE ne peut jamais toucher les données d'un autre site, même par erreur de paramétrage. Le filtre website_id est présent sur chaque requête.
• Immédiat sur les systèmes actifs : les données disparaissent sans délai de nos bases de production (PostgreSQL et ClickHouse) ainsi que du stockage des preuves vidéo.

Sauvegardes

Les données restent présentes dans nos sauvegardes jusqu'à leur rotation. C'est une contrainte technique inhérente à toute sauvegarde, et voici précisément ce qu'elle recouvre :

Pendant cette période, ces sauvegardes ne sont utilisées à aucune autre fin que la restauration du service après incident. Elles ne sont ni consultées, ni analysées, ni exploitées.

Surtout, chaque effacement est journalisé de manière permanente. Si nous devions restaurer une sauvegarde antérieure à votre demande, notre procédure de restauration impose une étape de rejeu de tous les effacements enregistrés avant toute remise en service : une donnée effacée ne réapparaît pas par ce biais.

Passé le délai de rotation ci-dessus, plus aucune copie ne subsiste.

Délai de réponse légal

Le RGPD (art. 12) impose de répondre à une demande de droit d'effacement dans un délai d'un mois, prolongeable de deux mois pour les demandes complexes. L'endpoint ci-dessus vous permet de répondre en quelques secondes.