Analyse d'impact relative à la protection des données (AIPD)
API QR Branding — fonctions IA
| Champ | Valeur |
|---|---|
| Date | 2026-03-08 |
| Responsable du traitement | QR Branding (Quartzon) |
| Version | 1.0 |
| État | Approuvée |
| Prochaine revue | 2026-09-08 |
1. Description du traitement
1.1 Nature du traitement
QR Branding propose la génération de QR codes assistée par IA selon deux modalités :
- Avec les propres comptes de QR Branding auprès des fournisseurs de LLM : le designer IA de qr-branding.com et l'endpoint géré de la marketplace (
POST /api/qr/ai/generate-managed). Une chaîne interne de fournisseurs de repli (Groq, Google Gemini, OpenAI) traite chaque requête. - Avec la propre clé du client (BYOK) : l'endpoint de la marketplace
POST /api/qr/ai/generate. Le client fournit sa propre clé API et choisit le fournisseur (OpenAI, Anthropic, Google, Mistral, Cohere, Groq, xAI, DeepSeek ou Qwen, ou son propre endpoint compatible OpenAI).
Dans les deux modalités, l'utilisateur envoie un prompt de design en langage naturel (par exemple « QR code bleu moderne pour une entreprise tech ») ainsi que le contenu du QR (URL, texte, vCard, etc.). Le système :
- Envoie uniquement le prompt de design et les paramètres de génération à un fournisseur de LLM externe : celui qui traite la requête dans la chaîne de repli de QR Branding, ou celui choisi par l'utilisateur (BYOK).
- Reçoit du LLM une configuration de design en JSON.
- Génère le QR code avec le contenu fourni et le design suggéré.
- Renvoie l'image du QR à l'utilisateur.
1.2 Périmètre
- Données traitées : prompts de design (texte libre), paramètres de génération (style prédéfini, créativité, lisibilité stricte), contenu des QR (URL, texte, coordonnées vCard, identifiants WiFi, géolocalisation), clé API du client (BYOK uniquement, transitoire).
- Volume estimé : jusqu'à 15 requêtes IA par minute et par IP, 100 générations par minute au total.
- Personnes concernées : utilisateurs du site qr-branding.com, utilisateurs de l'API (développeurs, entreprises) et, indirectement, les personnes dont les données figurent dans le contenu des QR (contacts vCard).
- Zone géographique : mondiale (API publique sur RapidAPI Marketplace).
1.3 Contexte
- Service sans état : aucune base de données, aucun contenu de QR n'est persisté.
- Comptes propres de QR Branding (site et endpoint géré) : QR Branding dispose de ses propres clés API auprès de Groq, Google (Gemini) et OpenAI, qui agissent comme ses sous-traitants et figurent sur la page des sous-traitants ultérieurs. Aucune adresse e-mail, donnée de facturation, adresse IP ni identifiant client ne leur est envoyé.
- Modèle BYOK (Bring Your Own Key) (
POST /api/qr/ai/generate) : le client fournit sa propre clé API à chaque requête ; QR Branding n'utilise pas ses comptes propres pour ces requêtes. - Le contenu des QR n'est jamais envoyé aux fournisseurs d'IA ; seul le prompt de design l'est.
- Les champs sensibles générés par le LLM (URL, base64) sont neutralisés avant le rendu.
- Le service tourne sur Azure Functions (Consumption Plan).
- Sur l'endpoint BYOK, la relation contractuelle avec le fournisseur de LLM est directe entre le client et le fournisseur.
1.4 Finalité
Permettre aux utilisateurs de générer des designs de QR personnalisés à partir de descriptions en langage naturel, sans avoir à configurer les paramètres à la main.
2. Nécessité et proportionnalité
2.1 Base juridique
Exécution d'un contrat (art. 6(1)(b) du RGPD) : le traitement est nécessaire pour fournir le service précis demandé par l'utilisateur.
2.2 Minimisation des données
| Principe | Mise en œuvre |
|---|---|
| Uniquement les données nécessaires | Seul le prompt est envoyé au LLM, pas le contenu du QR |
| Aucun stockage | Traitement en mémoire ; le texte du prompt et le contenu du QR sont supprimés après la réponse HTTP. Seule la configuration de design générée peut être mise en cache jusqu'à 30 jours, sous une clé dérivée d'un hachage SHA-256 du prompt et des paramètres |
| Aucun profilage | Aucun profil d'utilisateur ni historique des requêtes n'est créé |
| Anonymisation | Adresses IP anonymisées dans les journaux (dernier octet masqué) |
| Cloisonnement | Contenu du QR et prompt IA séparés dans le flux de données |
2.3 Proportionnalité
Le traitement est proportionné, car :
- L'utilisateur choisit activement d'utiliser la fonction IA (endpoint distinct).
- Sur l'endpoint BYOK, l'utilisateur sélectionne le fournisseur de LLM ; sur le site et l'endpoint géré, le fournisseur est l'un des sous-traitants listés sur la page des sous-traitants ultérieurs.
- Seul le prompt de design est transféré (pas les données personnelles du contenu du QR).
- Il n'existe pas d'alternative moins intrusive pour générer des designs à partir du langage naturel.
3. Identification et évaluation des risques
3.1 Risques identifiés
| # | Risque | Probabilité | Impact | Niveau | Atténuation |
|---|---|---|---|---|---|
| R1 | Injection de prompt : l'utilisateur injecte des instructions malveillantes dans le prompt | Moyenne | Moyen | Moyen | Délimiteurs <user_request>, instructions anti-fuite dans le prompt système, champs URL/base64 neutralisés après le LLM |
| R2 | Données personnelles dans les prompts : l'utilisateur inclut des données personnelles dans la description du design | Moyenne | Faible | Faible | Nous ne stockons pas le texte des prompts (le cache ne conserve que le design généré sous une clé dérivée d'un hachage) ; le prompt est envoyé sans aucun identifiant de l'utilisateur ; politique d'utilisation documentée |
| R3 | Exfiltration du prompt système : un attaquant extrait les instructions système | Faible | Faible | Faible | Pied de page anti-fuite dans le prompt système, sortie assainie (balises HTML supprimées) |
| R4 | Transfert international : prompts transmis à des fournisseurs situés hors de l'EEE | Moyenne | Faible | Faible | Comptes de QR Branding : Groq, Google et OpenAI (États-Unis) agissent comme sous-traitants conformément aux conditions de traitement des données de chaque fournisseur ; seuls le prompt de design et les paramètres sont envoyés. BYOK : le client a une relation directe avec le fournisseur et son propre DPA ; QR Branding n'agit que comme intermédiaire technique. Information dans la Politique de confidentialité et sur la page des sous-traitants ultérieurs |
| R5 | Conservation par le fournisseur de LLM : le fournisseur conserve des données selon ses propres politiques | Moyenne | Faible | Faible | Comptes de QR Branding : régie par les conditions de traitement des données de chaque fournisseur avec QR Branding. BYOK : responsabilité du client selon ses propres conditions avec le fournisseur |
| R6 | Réponse du LLM au contenu malveillant : XSS, URL malveillantes | Moyenne | Moyen | Moyen | Expression régulière d'assainissement HTML avec délai maximal, champs URL/base64 neutralisés, MaxDepth=32 à la désérialisation |
| R7 | Denial of wallet : abus de l'endpoint IA pour faire exploser les coûts | Moyenne | Élevé | Élevé | Limitation de débit (15 IA/min par IP, 100/min au total), RenderThrottle avec sémaphore, functionTimeout 1:30 |
| R8 | Fuite de clés API dans les journaux | Faible | Élevé | Moyen | SanitizeForLog() masque les motifs de clés API, messages d'erreur sans données personnelles |
3.2 Cartographie des flux de données
User → qr-branding.com or RapidAPI Proxy → Azure Functions
↓
[Design prompt + parameters only]
↓
LLM provider (QR Branding's fallback chain,
or the user's choice on BYOK)
↓
[Design JSON config]
↓
QR Rendering (SkiaSharp)
+ QR content (never leaves the server)
↓
QR image → User
4. Mesures d'atténuation
4.1 Mesures techniques en place
| Mesure | Risque atténué | État |
|---|---|---|
Délimiteurs de prompt (<user_request>) | R1 | ✅ Mise en œuvre |
| Pied de page anti-fuite dans le prompt système | R1, R3 | ✅ Mise en œuvre |
| Neutralisation des champs URL/base64 du LLM | R1, R6 | ✅ Mise en œuvre |
| Expression régulière d'assainissement HTML avec délai maximal (3s) | R6 | ✅ Mise en œuvre |
| MaxDepth=32 dans JsonSerializer | R6 | ✅ Mise en œuvre |
| Limitation de débit IA (15/min par IP, 100/min au total) | R7 | ✅ Mise en œuvre |
| RenderThrottle (sémaphore, 4 simultanés) | R7 | ✅ Mise en œuvre |
| functionTimeout 1:30 | R7 | ✅ Mise en œuvre |
| SanitizeForLog() : masquage des clés API | R8 | ✅ Mise en œuvre |
| Anonymisation des IP (dernier octet) | R2 | ✅ Mise en œuvre |
| Messages d'erreur sans données personnelles | R2 | ✅ Mise en œuvre |
| Plafond de tokens de sortie sur chaque appel au LLM | R7 | ✅ Mise en œuvre |
| Content-Length + contrôle de taille après lecture (1MB) | R7 | ✅ Mise en œuvre |
| Séparation de systemInstruction pour Google | R1 | ✅ Mise en œuvre |
4.2 Mesures organisationnelles
| Mesure | Risque atténué | État |
|---|---|---|
| Politique de confidentialité publiée | R4, R5 | ✅ Mise en œuvre |
| Mention des fournisseurs de LLM dans la documentation et sur la page des sous-traitants ultérieurs | R4 | ✅ Mise en œuvre |
| DPA avec les fournisseurs de LLM utilisés avec les comptes de QR Branding (Groq, Google, OpenAI) | R4, R5 | ⚠️ En attente de confirmation |
| DPA avec le fournisseur de LLM sur l'endpoint BYOK | R5 | Responsabilité du client |
| Procédure DSR documentée | Général | ✅ Documentée |
| Plan de réponse aux incidents | Général | ✅ Documenté |
5. Conclusion
5.1 Risque résiduel
Avec l'ensemble des mesures techniques et organisationnelles en place, le risque résiduel est évalué comme FAIBLE :
- Le traitement est sans état : ni le contenu des QR ni le texte du prompt ne sont persistés (le cache des prompts ne conserve que les designs générés sous une clé dérivée d'un hachage).
- Le contenu des QR (potentiellement sensible) ne quitte jamais l'infrastructure Azure.
- Seuls les prompts de design (qui contiennent rarement des données personnelles) sont transférés à des tiers.
- Toutes les mesures techniques d'atténuation issues du méga-audit sont mises en œuvre et vérifiées.
5.2 Décision
✅ Le traitement peut être mis en œuvre avec les mesures actuelles.
La consultation préalable de l'autorité de contrôle (art. 36 du RGPD) n'est pas requise, le risque résiduel étant faible.
5.3 Révision
Cette AIPD sera révisée :
- Au moins tous les 6 mois.
- Lorsque de nouveaux fournisseurs de LLM sont ajoutés.
- Lorsque le flux de données de l'endpoint IA change.
- Lorsque de nouveaux types de contenu de QR susceptibles de contenir des données sensibles sont introduits.
Document généré le 2026-03-08. Prochaine revue prévue : 2026-09-08.