RGPD et objets connectés : checklist conformité pour développeurs

Sommaire

📌 En résumé

Priorisez la base légale et cartographiez chaque flux de données.
Recueillez et stockez le consentement via QR, pairing ou cloud-token.
Chiffrez en transit et au repos, OTA signées, rotation de clés.
Fournissez API pour droits (export/suppression) et réalisez une PIA si risque élevé.

Les objets sans écran compliquent le RGPD : qui consent, comment prouver, comment propager un retrait ? Si vous développez un device, ce guide court propose 7 priorités opérationnelles, patterns techniques et une checklist imprimable pour agir tout de suite.

Mis à jour le 8 septembre 2026 — ces recommandations suivent les lignes directrices CNIL et le règlement (UE) 2016/679.

Priorité 1 : identifier les traitements et choisir la base légale

Action à faire : cartographier les flux de données (mini‑schéma) pour chaque fonctionnalité.
Pattern : table « finalité → données → base légale → risque ».
Règles pratiques :
Pour chaque donnée, indiquer la finalité claire et la base légale (article 6 RGPD : exécution contrat, intérêt légitime, consentement).
Pour données sensibles (santé, géoloc. continue), privilégier consentement explicite ou base légale stricte.
Checklist rapide :
✅ Finalité documentée pour chaque donnée
✅ Base légale justifiée et tracée
✅ Marquage des traitements à risque (PIA requis)

Priorité 2 : information claire et accessible (où et comment)

Actions :
Fournir une information concise et un lien vers la politique de confidentialité.
Adapter le message au support (écran in‑device, packaging, app mobile).
Modèles de texte (à coller) :
Objet avec écran : « Nom de l’appareil collecte X pour Y. Responsable : Société Z. Pour exercer vos droits : lien/QR. »
Objet sans écran (QR sur packaging) : « Scannez ce QR pour gérer vos données et consentements. Responsable : Société Z. »
Pattern : QR code sur packaging → page mobile responsive → acceptation + token.
Checklist :
✅ Message de 1–2 phrases présent sur device/packaging/app
✅ Lien vers politique accessible et compréhensible
✅ Version courte + version détaillée pour développeurs/PIA

Priorité 3 : recueil et gestion du consentement (techniquement)

Patterns techniques (sans code long) :

Pairing BLE + échange d’un token de consentement stocké côté cloud. Le device reçoit un identifiant pseudonymisé lié au consentement.
QR code → page mobile → consentement signé → token renvoyé au device via gateway/cloud.
Consent sync : app mobile gère le consentement utilisateur et synchronise via MQTT/HTTPS sécurisé avec le device.

Exigences opérationnelles :
Horodater et stocker la preuve du consentement.
Permettre le retrait simple depuis l’app ou interface web.
Propager le retrait : cloud → device → purge locale si nécessaire.
Checklist :
✅ Consentement horodaté et stocké (logs d’audit)
✅ Mécanisme de retrait opérationnel et testé
✅ Token d’association device-user pseudo‑identifiant

⚠️ À noter

Pour les mineurs et les données de santé, exigez le consentement parental explicite ou évitez la collecte quand possible.

Priorité 4 : minimisation, pseudonymisation et conservation

Actions concrètes :
Collecter uniquement les champs nécessaires à la finalité.
Pseudonymiser à la périphérie (séparer ID device et données personnelles).
Implémenter TTL (time‑to‑live) et suppression automatique.
Checklist :
✅ Schéma de données minimise les champs
✅ Identifiants stockés séparément
✅ Suppression automatique paramétrée par finalité

Priorité 5 : sécurité technique (chiffrement, OTA, authentification)

Mesures essentielles :
Transfert : TLS 1.2/1.3 obligatoire.
Au repos : chiffrement des données sensibles.
Authentification : clé unique par device, rotation et gestion centralisée des secrets.
Mises à jour : OTA signées et vérifiées côté device.
Conformité : aligner sur ETSI EN 303 645.
Checklist :
✅ TLS activé pour toutes les communications
✅ OTA signée et testée
✅ Stockage chiffré pour données sensibles
✅ Processus de gestion des vulnérabilités documenté

Priorité 6 : exercices des droits et API produit

Solutions pratiques :
Fournir endpoints REST sécurisés pour export, rectification, suppression.
Lier ID utilisateur ↔ données device via un mapping pseudonymisé.
Workflow de vérification d’identité avant action (email, app).
Checklist :
✅ Endpoints droits implémentés et documentés
✅ Procédures de vérification d’identité en place
✅ Logs prouvant les actions d’effacement/export

Priorité 7 : PIA / DPIA et gouvernance produit

Quand réaliser une PIA :
Si traitement à risque élevé : profilage, localization continue, données santé.
Livrables attendus :
Synthèse PIA, registre des traitements, plan d’action avec preuves d’implémentation.
Checklist :
✅ PIA lancée si indicateur de risque élevé
✅ Plan d’action suivi et preuves archivées

Checklist finale imprimable (10 points oui/non)

J’ai cartographié les flux et justifié la base légale ✅/❌
J’ai fourni une information courte accessible sur device/packaging/app ✅/❌
Le consentement est horodaté et stocké (avec retrait possible) ✅/❌
Les données collectées sont minimisées ✅/❌
Les identifiants device sont pseudonymisés ✅/❌
Les communications utilisent TLS 1.2/1.3 ✅/❌
Les OTA sont signées et vérifiées ✅/❌
API pour droits (export/suppression) disponibles ✅/❌
PIA réalisée si traitement à risque élevé ✅/❌
Journal d’audit des accès et actions conservé ✅/❌

Cas pratiques & patterns rapides

Objet sans écran (capteur domestique)

Étapes : QR sur packaging → app onboarding → token cloud → device associé.
Checklist : info QR, token horodaté, suppression remote testée.

Bracelet santé (données sensibles)

Étapes : pairing sécurisé BLE → consentement explicite via app → chiffrement local + cloud.
Checklist : consentement parental si mineur, chiffrement fort, PIA.

Tracker de flotte

Étapes : device envoie télémétrie via gateway → mapping pseudonymisé → dashboards avec accès restreint.
Checklist : pseudonymisation, durée de conservation courte, endpoint suppression client.

« La conformité pour l’IoT s’obtient par des patterns simples : minimisation, preuve du consentement et sécurité dès la conception. »
Alice Martin, lead engineer produit

FAQ

Quand le consentement est‑il nécessaire pour un objet connecté ?

Le consentement est requis quand la finalité n’est couverte par aucune autre base légale et que l’action repose sur une manifestation libre, spécifique, éclairée et univoque. Pour données sensibles, le consentement explicite est préférable.

Que faire si l’objet n’a pas d’écran ?

Offrez un point d’entrée : QR code sur packaging, onboarding via app mobile ou portail web. Stockez la preuve horodatée et associez un token au device.

Faut‑il chiffrer les données sur l’objet ?

Oui pour les données personnelles sensibles. Chiffrez en transit (TLS 1.2/1.3) et au repos ; utilisez clés uniques par device et rotation régulière.

Quand réaliser une PIA/DPIA ?

Lorsque le traitement présente un risque élevé pour les droits et libertés (ex : surveillance, santé, profilage). Utilisez la PIA comme document de gouvernance et preuve de conformité.

Comment prouver le retrait du consentement ?

Conservez un enregistrement horodaté du consentement et des retraits, et assurez la propagation technique du retrait (cloud → device) avec purge des données concernées.

Meta : checklist téléchargeable et mini‑schéma d’architecture (QR → app → token → cloud → device) disponible à l’impression. Les recommandations évoluent avec les lignes directrices CNIL/UE ; vérifiez les mises à jour réglementaires régulièrement.