Données sensibles RGPD : liste et conditions

Une information peut être confidentielle sans relever de l’article 9 du RGPD. À l’inverse, un champ apparemment ordinaire peut révéler une donnée sensible par son contexte ou son rapprochement avec d’autres informations. La qualification doit précéder le choix de la règle qui permet le traitement.

Les catégories particulières de l’article 9

L’Art. 9(1) interdit en principe le traitement des données révélant l’origine raciale ou ethnique, les opinions politiques, les convictions religieuses ou philosophiques et l’appartenance syndicale. Il vise aussi les données génétiques, les données biométriques traitées aux fins d’identifier une personne de manière unique, la santé, la vie sexuelle et l’orientation sexuelle. Source : RGPD, Art. 9(1).

Cette liste ne recouvre pas toutes les informations présentant un risque. Un numéro bancaire, un mot de passe ou une localisation peuvent nécessiter une protection importante sans relever, par leur seule nature, de l’article 9. Les données pénales suivent le régime distinct de l’article 10 ; le numéro national d’identification relève également de règles spécifiques.

Les définitions de données génétiques, biométriques et de santé figurent aux Art. 4(13), (14) et (15). Source : RGPD, Art. 4.

Les données de santé peuvent être déduites

La CNIL distingue notamment les informations de santé par nature, celles révélées par croisement et celles qualifiées en raison de leur usage médical. Une mesure issue d’un outil de bien-être n’est donc ni toujours exclue ni toujours incluse : examinez ce qu’elle permet de conclure sur la santé. Source : CNIL, définition d’une donnée de santé.

Exemple hypothétique : un service conserve seulement une préférence de rendez-vous en matinée. Cette donnée ne révèle pas nécessairement un état de santé. S’il ajoute que ce choix correspond à un traitement médical déterminé, le fichier contient une information de santé.

Ce que la CJUE retient pour qualifier une donnée sensible

La Cour de justice interprète largement la notion, parce que l’Art. 9 protège contre des risques élevés pour les droits fondamentaux. Quatre arrêts sont utiles en pratique. Les liens ci-dessous renvoient à la recherche de la Cour par numéro d’affaire ; je n’ai pas rouvert chaque arrêt pour cette mise à jour, et il convient de vérifier le point cité dans le texte intégral avant de s’en prévaloir.

Deux conséquences pratiques en découlent. D’abord, l’intention du responsable de traitement n’est pas le critère : ce qui compte est ce que la donnée permet de révéler. Ensuite, il est risqué de séparer artificiellement un fichier « neutre » d’un fichier « sensible » si les rapprochements restent possibles. Pour les données biométriques, voir aussi le guide sur les données biométriques.

Vérifier une base de l’article 6 et une exception de l’article 9

L’exception à l’interdiction ne dispense pas du fondement exigé par l’Art. 6(1). Identifiez donc les deux niveaux, ainsi que les conditions nationales pertinentes. Le commentaire de l’article 9 approfondit leur articulation.

Cette synthèse ne remplace pas les conditions complètes du texte de l’Art. 9(2) à (4). Une donnée trouvée en ligne n’est pas, de ce seul fait, manifestement rendue publique par son titulaire. Le consentement explicite ne permet pas non plus de contourner une règle qui interdit le traitement malgré ce consentement.

Pour les associations visées par le point (d), le texte couvre les membres, anciens membres et personnes ayant des contacts réguliers avec l’organisme en lien avec ses finalités, sous les autres conditions prévues. Il ne crée pas une exception pour toute association. Le guide RGPD associatif permet d’appliquer cette distinction.

Exemple résolu : une application de rendez-vous pour une pharmacie

Cas hypothétique. Une pharmacie lance un site de commande avec retrait en officine. Le formulaire demande nom, e-mail, produits commandés, ainsi qu’un champ libre « informations utiles ». Le prestataire de statistiques reçoit l’historique de commandes.

1. Qualification. Les produits commandés peuvent permettre de déduire un état de santé (voir C-21/23) : le traitement est à examiner sous l’angle de l’Art. 9(1), y compris pour les clients qui commandent sans ordonnance.
2. Base de l’Art. 6. L’exécution de la commande relève du contrat, Art. 6(1)(b), pour la commande elle-même ; chaque finalité supplémentaire (statistiques, relance) nécessite sa propre base.
3. Exception de l’Art. 9(2). Le consentement explicite, Art. 9(2)(a), est souvent la voie pour les finalités commerciales ; le cadre sanitaire de l’Art. 9(2)(h) et 9(3) ne se transpose pas automatiquement à une fonction de vente en ligne. Cette appréciation dépend des textes applicables aux pharmaciens, à vérifier avec le conseil de l’officine.
4. Décisions de conception. Retirer le champ libre ou le borner ; ne pas transmettre l’historique au prestataire de statistiques, ou le transmettre sans lien avec une personne identifiable ; vérifier les outils tiers chargés sur le site.
5. Obligations associées. AIPD si le traitement est à grande échelle (Art. 35(3)(b)) ou si la liste CNIL le prévoit ; contrat de sous-traitance, Art. 28 ; sécurité, Art. 32.

La décision finale dépend des faits : ce cas illustre la méthode, non une qualification définitive.

Erreurs fréquentes

• Se limiter à la liste de l’Art. 9(1). Une donnée déduite ou révélée par recoupement peut en relever ; à l’inverse, toute donnée « intime » n’en relève pas.
• Confondre exception et base légale. Le consentement explicite de l’Art. 9(2)(a) ne remplace pas l’identification d’une base de l’Art. 6(1), et inversement.
• Considérer une donnée publique comme librement réutilisable. L’Art. 9(2)(e) exige que la personne l’ait manifestement rendue publique elle-même (voir C-252/21 et C-446/21).
• Collecter « au cas où ». Un champ sensible sans finalité précise heurte la minimisation ; voir le principe de minimisation.
• Oublier les sous-traitants et outils tiers. Un traceur ou un SDK peut transmettre des données révélatrices sans que l’équipe produit le sache.
• Traiter l’AIPD comme automatique ou comme inutile. Elle dépend de l’échelle et des critères de l’Art. 35 ; voir quand faire une AIPD.

Déterminer les obligations concrètes

L’Art. 35(3)(b) impose une AIPD pour le traitement à grande échelle des catégories visées. L’Art. 35(1) et les listes applicables peuvent conduire à une AIPD dans d’autres situations. L’Art. 37(1)(c) impose un DPO lorsque les activités de base consistent en ce traitement à grande échelle. Ces conditions ne se confondent pas avec la simple présence d’une donnée sensible. Source : RGPD, Art. 35 et 37.

Les garanties de recherche de l’article 89 doivent être examinées pour les projets concernés. En France, les formalités de recherche et de santé dépendent du traitement et du régime applicable ; il n’existe pas une autorisation CNIL générale obligatoire pour toute recherche contenant une donnée sensible. Source : loi Informatique et Libertés, notamment Art. 44 et 64 à 79.

L’Art. 32(1) demande une sécurité adaptée au risque. Il ne prescrit pas, par sa seule rédaction, le même chiffrement dans toutes les situations. Analysez accès, échanges, copies, sauvegardes et possibilités de rapprochement. Les exigences sectorielles éventuellement applicables doivent être ajoutées à cette analyse.

En cas de violation, la notification à l’autorité dépend du risque selon l’Art. 33(1) ; l’information des personnes dépend du risque élevé et des exceptions de l’Art. 34. La sensibilité pèse fortement dans l’analyse, sans remplacer cette décision.

Fiche pratique de justification

Consignez la finalité, les champs sensibles, leur nécessité, la base de l’Art. 6, l’exception de l’Art. 9, les textes ou faits qui en établissent les conditions, les accès et la durée. Ajoutez les décisions relatives à l’AIPD, au DPO et aux formalités particulières.

Cette fiche peut être liée au registre. L’Art. 30 ne liste pas expressément « exception de l’article 9 » parmi ses rubriques obligatoires ; documenter cette justification demeure utile à la démonstration de la licéité. Vérifiez aussi la minimisation des informations collectées : la meilleure exception ne justifie pas un champ inutile.

Ce qu’il faut retenir

• Qualifiez les données selon ce qu’elles révèlent et l’usage qui en est fait.
• Cumulez un fondement de l’article 6 et une exception pertinente de l’article 9.
• AIPD, DPO, formalités et notification ont chacun leurs conditions.
• Conservez les justifications et vérifiez les protections dans les outils réels.
• La CJUE retient une lecture large : une donnée déduite ou révélée par recoupement peut relever de l’Art. 9.

FAQ

Toute photographie est-elle une donnée biométrique ?

Non. La qualification dépend notamment d’un traitement technique spécifique permettant ou confirmant l’identification unique. Une photographie peut cependant révéler d’autres informations sensibles selon son contenu et son contexte.

Le consentement explicite suffit-il toujours ?

Non. Il faut qu’il soit valable, qu’il vise les finalités concernées et qu’aucune règle applicable n’interdise de lever l’interdiction par consentement. Les autres principes du RGPD restent exigibles.

Une donnée confidentielle relève-t-elle forcément de l’article 9 ?

Non. Les informations bancaires ou mots de passe peuvent être très risqués sans appartenir à la liste de l’article 9. Leur sécurité doit néanmoins être adaptée.

Les données pénales sont-elles des données sensibles au sens de l’article 9 ?

Non, elles ont leur régime propre à l’Art. 10, qui limite le traitement aux situations encadrées par le droit. Elles appellent néanmoins une vigilance comparable. Voir l’article 10 du RGPD.

Peut-on réutiliser une donnée sensible publiée sur un réseau social ?

Pas automatiquement. L’Art. 9(2)(e) vise une donnée manifestement rendue publique par la personne concernée elle-même, et uniquement pour ce qu’elle a rendu public (C-446/21). Il faut en outre une base de l’Art. 6 et le respect des autres principes.

Recevez nos analyses pratiques sur la conformité RGPD dans la newsletter.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.