Analyse des bases juridiques du traitement des données
API QR Branding — art. 6 du RGPD
| Champ | Valeur |
|---|---|
| Responsable du traitement | QR Branding (Quartzon) |
| Date | 2026-03-08 |
| Version | 1.0 |
1. Principe de licéité (art. 6)
Tout traitement de données personnelles doit reposer sur au moins l'une des bases juridiques de l'art. 6(1) du RGPD. Chaque activité de traitement de QR Branding et sa base juridique correspondante sont analysées ci-dessous.
2. Analyse par activité de traitement
2.1 Génération de QR codes contenant des données personnelles
| Aspect | Analyse |
|---|---|
| Activité | L'utilisateur envoie un contenu de QR qui peut inclure des données personnelles (une vCard avec nom, e-mail, téléphone et adresse ; une géolocalisation ; des adresses e-mail) |
| Base juridique | Art. 6(1)(b) — Exécution d'un contrat |
| Justification | Le traitement est nécessaire à l'exécution du service que l'utilisateur a souscrit via RapidAPI. Sans traitement du contenu, le QR code demandé ne peut pas être généré |
| Proportionnalité | Minimale : seul le contenu strictement nécessaire est traité, en mémoire, sans stockage |
| Alternative moins intrusive | Aucune : le contenu du QR EST la donnée à encoder |
2.2 QR codes générés par IA
La génération par IA fonctionne selon deux modalités :
- Comptes propres de QR Branding (le designer IA de qr-branding.com et l'endpoint géré
POST /api/qr/ai/generate-managed) : QR Branding envoie le prompt de design, avec ses propres clés API, à un fournisseur de LLM de sa chaîne interne de repli (Groq, Google Gemini, OpenAI). Ces fournisseurs agissent comme sous-traitants de QR Branding et figurent sur la page des sous-traitants ultérieurs. - BYOK (Bring Your Own Key) (l'endpoint
POST /api/qr/ai/generate) : le client fournit sa propre clé API et choisit le fournisseur ; QR Branding n'utilise pas ses comptes propres pour ces requêtes.
| Aspect | Analyse |
|---|---|
| Activité | L'utilisateur envoie un prompt de design. QR Branding transmet le prompt à un fournisseur de LLM : avec ses propres clés (site et endpoint géré) ou avec la clé du client (llmApiKey, endpoint BYOK) |
| Modèle | Comptes propres de QR Branding auprès de Groq, Google (Gemini) et OpenAI, ou BYOK (Bring Your Own Key) avec le fournisseur choisi par le client |
| Base juridique | Art. 6(1)(b) — Exécution d'un contrat |
| Justification | L'utilisateur demande explicitement un design généré par IA : sur le site et l'endpoint géré, en lançant une génération par IA ; sur l'endpoint BYOK, également en choisissant le fournisseur et en fournissant sa propre clé API. Le traitement est nécessaire pour exécuter cette demande précise |
| Proportionnalité | Seuls le prompt de design et les paramètres de génération sont envoyés au LLM. Le contenu du QR, les adresses IP et les données d'identification ne sont JAMAIS transmis. Sur l'endpoint BYOK, la clé API du client n'est ni stockée ni journalisée |
| Remarque | L'utilisateur choisit activement d'utiliser la génération par IA et le prompt qu'il envoie. Sur l'endpoint BYOK, il choisit également le fournisseur de LLM et fournit sa propre clé API, et la relation avec le fournisseur de LLM est directe entre le client et le fournisseur |
2.3 Limitation de débit
| Aspect | Analyse |
|---|---|
| Activité | Comptage des requêtes par identifiant (utilisateur RapidAPI, identifiant d'abonnement, IP anonymisée) pour limiter le rythme d'utilisation |
| Base juridique | Art. 6(1)(f) — Intérêt légitime |
| Intérêt légitime | Protéger la disponibilité du service pour tous les utilisateurs et prévenir les abus et les coûts excessifs |
| Test de mise en balance | |
| — Intérêt du responsable du traitement | Élevé : sans limitation de débit, un seul utilisateur pourrait épuiser les ressources ou générer des coûts prohibitifs |
| — Impact sur la personne concernée | Minimal : seul un identifiant pseudonyme sert à compter les requêtes, les données sont conservées en mémoire volatile (2 min) et les adresses IP sont anonymisées |
| — Attente raisonnable | Oui : les utilisateurs d'API s'attendent à une limitation de débit, pratique courante du secteur |
| — Garanties | Données éphémères (2 min), anonymisation des IP, plafond de suivi (50K IP), aucune journalisation des identifiants |
| Conclusion | L'intérêt légitime prévaut nettement, compte tenu de l'impact minimal sur la personne concernée |
2.4 Télémétrie et diagnostic (Application Insights)
| Aspect | Analyse |
|---|---|
| Activité | Collecte de métriques de performance, d'erreurs et de métadonnées de requêtes (sans données personnelles) |
| Base juridique | Art. 6(1)(f) — Intérêt légitime |
| Intérêt légitime | Assurer la fiabilité et la disponibilité du service, et diagnostiquer rapidement les problèmes |
| Test de mise en balance | |
| — Intérêt du responsable du traitement | Élevé : sans télémétrie, les incidents ne peuvent être ni détectés ni résolus |
| — Impact sur la personne concernée | Minimal : données personnelles retirées des messages d'erreur, clés API masquées, adresses IP anonymisées |
| — Attente raisonnable | Oui : la supervision est une pratique courante des services cloud |
| — Garanties | Conservation de 90 jours, journalisation sans données personnelles, anonymisation des IP, masquage des clés API |
| Conclusion | L'intérêt légitime prévaut nettement |
2.5 Authentification RapidAPI
| Aspect | Analyse |
|---|---|
| Activité | Vérification de l'en-tête X-RapidAPI-Proxy-Secret à chaque requête |
| Base juridique | Art. 6(1)(f) — Intérêt légitime |
| Justification | Protéger le service contre les accès non autorisés |
| Remarque | Le secret est une donnée du serveur, pas une donnée de l'utilisateur. Aucune donnée personnelle n'est traitée à cette étape |
3. Bases juridiques NON retenues
| Base juridique | Art. | Pourquoi n'est-elle pas utilisée ? |
|---|---|---|
| Consentement | Art. 6(1)(a) | Aucun consentement explicite n'est recueilli. Il n'est pas nécessaire : le traitement repose sur le contrat et l'intérêt légitime. S'appuyer sur le consentement créerait des obligations supplémentaires (possibilité de retrait) sans aucun bénéfice |
| Obligation légale | Art. 6(1)(c) | Aucune obligation légale n'impose le traitement de ces données |
| Intérêts vitaux | Art. 6(1)(d) | Sans objet : le service ne traite pas de données pour protéger des intérêts vitaux |
| Intérêt public | Art. 6(1)(e) | Sans objet : il s'agit d'un service commercial privé |
4. Catégories particulières de données (art. 9)
QR Branding ne demande ni n'exige de catégories particulières de données personnelles (origine ethnique, santé, orientation sexuelle, etc.).
L'utilisateur pourrait toutefois inclure de telles données dans le contenu d'un QR (par exemple un QR code contenant des données médicales). Dans ce cas :
- QR Branding agit comme un sous-traitant technique qui encode les données sans les interpréter.
- La responsabilité du traitement des catégories particulières incombe à l'utilisateur qui décide de les inclure.
- La base juridique dans ce scénario serait le consentement explicite de la personne concernée, que l'utilisateur doit obtenir avant d'encoder les données.
- QR Branding ne stocke pas ces données et les supprime immédiatement après la génération.
5. Données relatives aux enfants (art. 8)
- QR Branding est un service d'API B2B/B2C destiné aux développeurs et aux entreprises.
- Il ne s'adresse pas aux enfants de moins de 16 ans.
- Aucune donnée relative à l'âge n'est collectée et aucune vérification de l'âge n'est effectuée.
- Si un utilisateur inclut des données relatives à des enfants dans le contenu d'un QR, il lui incombe d'obtenir le consentement parental.
6. Transferts internationaux (art. 44-49)
| Destination | Base juridique du transfert | Fournisseur |
|---|---|---|
| UE/États-Unis (Azure) | Online Services Terms + CCT | Microsoft Azure |
| États-Unis | Conditions de la plateforme | RapidAPI |
| États-Unis | Conditions de traitement des données de chaque fournisseur (voir la page des sous-traitants ultérieurs) | Groq, Google (Gemini), OpenAI : génération par IA avec les comptes de QR Branding |
Remarque sur les fournisseurs de LLM : avec les comptes propres de QR Branding (le site et l'endpoint géré), les prompts de design sont transférés à Groq, Google (Gemini) ou OpenAI, qui agissent comme sous-traitants de QR Branding. Sur l'endpoint BYOK, les prompts sont transférés au fournisseur choisi par le client (OpenAI, Anthropic, Google, Mistral, Cohere, Groq, xAI, DeepSeek ou Qwen, ou son propre endpoint compatible OpenAI) à l'aide de la propre clé API du client. La responsabilité de ce transfert incombe au client, qui entretient une relation contractuelle directe avec le fournisseur ; QR Branding agit comme intermédiaire technique.
L'utilisation de l'endpoint standard de génération de QR n'implique aucun transfert vers des fournisseurs de LLM (le traitement a lieu exclusivement sur Azure).
7. Révision
Cette analyse des bases juridiques doit être révisée :
- Lorsque de nouvelles activités de traitement sont ajoutées
- Lorsque les données traitées par les activités existantes changent
- Lorsque les politiques des fournisseurs de LLM changent
- Au moins une fois par an
Document généré le 2026-03-08.