Aller au contenu

Procédure d'exercice des droits des personnes concernées (DSR)

API QR Branding — art. 15-22 du RGPD

ChampValeur
Responsable du traitementQR Branding (Quartzon)
Date2026-03-08
Version1.0
Canal des demandessupport@qr-branding.com

1. Droits reconnus

DroitArticle du RGPDApplication chez QR Branding
AccèsArt. 15✅ Applicable : aux données d'Application Insights
RectificationArt. 16⚠️ Limité : service sans état, aucune donnée stockée à rectifier
Effacement (« droit à l'oubli »)Art. 17⚠️ Limité : les données en mémoire ont déjà été supprimées ; applicable à Application Insights
Limitation du traitementArt. 18✅ Applicable : nous pouvons restreindre l'accès à la télémétrie
PortabilitéArt. 20⚠️ Limité : aucune donnée structurée d'utilisateur n'est stockée
OppositionArt. 21✅ Applicable : aux traitements fondés sur l'intérêt légitime
Ne pas faire l'objet d'une décision automatiséeArt. 22⚠️ La génération par IA ne prend aucune décision produisant des effets juridiques pour l'utilisateur

2. Contexte particulier : un service sans état

QR Branding fonctionne comme un service sans état, sans base de données. Cela a des conséquences importantes pour les demandes DSR :

Données qui N'existent PAS et ne peuvent donc être ni récupérées ni supprimées :

  • Contenu des QR (URL, texte, vCard, WiFi) → traité en mémoire, supprimé après la réponse
  • Prompts IA → traités en mémoire, supprimés après la réponse (le cache des prompts ne conserve que le design généré, jusqu'à 30 jours, sous une clé dérivée d'un hachage SHA-256 du prompt)
  • Images de QR générées → renvoyées à l'utilisateur, non stockées
  • Logos et images envoyés → traités en mémoire, supprimés

Données qui PEUVENT exister :

  • Application Insights (90 jours) : chemins des requêtes, durées, erreurs, métriques de performance
  • Compteurs de limitation de débit (2 minutes) : identifiants RapidAPI anonymisés, adresses IP anonymisées
  • Données détenues par les fournisseurs de LLM : prompts de design, selon la politique de conservation de chaque fournisseur

3. Procédure de traitement

3.1 Réception de la demande

ÉtapeActionDélai
1Recevoir la demande par e-mail (support@qr-branding.com)—
2Accuser réception auprès du demandeur48h
3Vérifier l'identité du demandeur5 jours
4Évaluer la recevabilité de la demande5 jours
5Exécuter l'action demandée—
6Répondre au demandeur avec le résultat30 jours maximum à compter de la réception

3.2 Vérification de l'identité

Pour empêcher des tiers d'accéder aux données d'autrui :

  1. Demander à la personne concernée d'indiquer son utilisateur RapidAPI ou son identifiant d'abonnement.
  2. Le cas échéant, demander un appel d'API de vérification depuis son compte RapidAPI pour confirmer qu'elle en est titulaire.
  3. Ne pas exiger de documents excessifs : la vérification doit être proportionnée.

3.3 Réponses par type de droit

Droit d'accès (art. 15)

Réponse type :

Madame, Monsieur [nom],

En réponse à votre demande d'accès au titre de l'art. 15 du RGPD, nous vous informons de ce qui suit :

QR Branding est un service sans état qui ne stocke pas de données personnelles au-delà du traitement immédiat de chaque requête d'API. Nous ne conservons ni base d'utilisateurs, ni historique des requêtes, ni contenu de QR généré.

Les seules données susceptibles d'exister temporairement sont :

  1. La télémétrie dans Application Insights (90 jours) : des métadonnées sur vos requêtes d'API (chemins, temps de réponse, codes de statut HTTP). Ces données ne contiennent ni contenu de QR ni donnée personnelle identifiable, les adresses IP étant anonymisées avant journalisation.

  2. Les données détenues par les fournisseurs de LLM (si vous avez utilisé la fonction IA) : si vous avez utilisé la génération par IA sur qr-branding.com ou l'endpoint géré, vos prompts de design ont été traités par nos fournisseurs de LLM (Groq, Google ou OpenAI) agissant en tant que nos sous-traitants, sans aucun identifiant vous concernant. Si vous avez utilisé l'endpoint BYOK avec votre propre clé, les prompts de design que vous avez envoyés peuvent être conservés selon la politique du fournisseur que vous avez choisi ; nous vous recommandons de contacter directement ce fournisseur pour exercer vos droits.

Si vous souhaitez que nous extrayions les données de télémétrie associées à votre identifiant RapidAPI, nous le ferons volontiers.

Droit à l'effacement (art. 17)

Réponse type :

En réponse à votre demande d'effacement :

  • Le contenu des QR et les images générées ne sont jamais stockés et sont supprimés immédiatement après chaque réponse de l'API.
  • Les compteurs de limitation de débit associés à votre identifiant expirent automatiquement au bout de 2 minutes.
  • Si vous souhaitez que nous supprimions les données de télémétrie d'Application Insights associées à votre identifiant, nous le ferons et vous le confirmerons une fois l'opération effectuée.
  • Pour les données conservées par le fournisseur de LLM que vous avez utilisé avec votre propre clé (endpoint BYOK), nous vous communiquons les contacts confidentialité de chaque fournisseur afin que vous puissiez exercer vos droits directement.

Droit d'opposition (art. 21)

Pour les traitements fondés sur l'intérêt légitime (limitation de débit, télémétrie) :

  1. Évaluer s'il existe des motifs légitimes impérieux qui prévalent sur les intérêts du demandeur.
  2. Limitation de débit : l'intérêt légitime (disponibilité du service) prévaut généralement, mais l'évaluation doit être documentée.
  3. Télémétrie : évaluer au cas par cas. Le cas échéant, configurer une exclusion dans Application Insights.

Droit à la portabilité des données (art. 20)

Réponse type :

QR Branding ne stocke pas de données personnelles structurées. Il n'existe aucune donnée que nous puissions exporter dans un format portable. Toutes les informations traitées sont supprimées immédiatement après chaque requête d'API.


4. Délais

PhaseDélai maximal
Accusé de réception48 heures
Réponse complète30 jours à compter de la réception (art. 12(3))
Prolongation (demandes complexes)+60 jours supplémentaires (en informant le demandeur dans les 30 premiers jours)
Exécution d'un effacement72 heures après approbation

5. Exceptions et refus

Une demande peut être refusée si :

MotifBase juridique
Demandes manifestement infondées ou excessivesArt. 12(5)
Identité impossible à vérifierArt. 12(6)
Atteinte aux droits de tiersArt. 15(4)
Obligation légale de conservationArt. 17(3)

En cas de refus :

  1. Informer le demandeur des motifs.
  2. L'informer de son droit d'introduire une réclamation auprès de l'autorité de contrôle.
  3. Documenter le refus et ses motifs.

6. Registre des demandes

Toute demande DSR doit être consignée :

ChampDescription
IDDSR-YYYY-NNN
Date de réception—
CanalE-mail / RapidAPI / Autre
Type de droitAccès / Effacement / Opposition / etc.
Identifiant du demandeurUtilisateur RapidAPI (aucune donnée personnelle supplémentaire)
Date de réponse—
RésultatExécutée / Refusée (avec motif)
Actions menéesDescription de ce qui a été fait

7. Données détenues par les fournisseurs de LLM

7.1 Comptes propres de QR Branding (site et endpoint géré)

Pour la génération par IA sur qr-branding.com et sur l'endpoint géré (POST /api/qr/ai/generate-managed), Groq, Google (Gemini) et OpenAI agissent comme sous-traitants de QR Branding (voir la page des sous-traitants ultérieurs). Les demandes portant sur ces données sont traitées par QR Branding en tant que responsable du traitement, selon la procédure décrite dans ce document. Seuls le prompt de design et les paramètres de génération sont envoyés au fournisseur, sans l'adresse e-mail, l'adresse IP ni aucun autre identifiant de l'utilisateur.

7.2 Endpoint BYOK

Sur l'endpoint POST /api/qr/ai/generate, le client fournit sa propre clé API de fournisseur de LLM (BYOK, Bring Your Own Key). Par conséquent :

  • Pour ces requêtes, QR Branding n'a aucune relation contractuelle avec le fournisseur de LLM.
  • Si un utilisateur demande l'accès à des données traitées par un fournisseur de LLM, ou leur effacement, il doit contacter directement le fournisseur, auprès duquel il détient son propre compte.
  • QR Branding peut communiquer à l'utilisateur les contacts confidentialité de chaque fournisseur :
FournisseurContact confidentialité
OpenAIprivacy@openai.com
Anthropicprivacy@anthropic.com
GoogleFormulaire de confidentialité de Google Cloud
Mistral AIprivacy@mistral.ai
Cohereprivacy@cohere.com
Groqprivacy@groq.com

Pour xAI, DeepSeek et Qwen, également pris en charge sur l'endpoint BYOK, l'utilisateur doit utiliser le contact confidentialité publié par le fournisseur.


Document généré le 2026-03-08.