Réponse courte : une analyse d'impact relative à la protection des données (AIPD) est le document dans lequel vous décrivez une opération de traitement, démontrez qu'elle est nécessaire et proportionnée, évaluez les risques pour les personnes dont les données sont utilisées, et enregistrez les mesures qui réduisent ces risques. L'article 35 du RGPD la rend obligatoire lorsque le traitement est susceptible d'engendrer un risque élevé, et cite le traitement à grande échelle de catégories particulières de données, qui incluent les données de santé, comme un cas. En pratique, chaque application de santé comptant plus que quelques utilisateurs et chaque plateforme de données de santé en a besoin, avant que le traitement ne commence, et doit la réviser lorsque le traitement change. Le modèle ci-dessous suit l'article 35(7) et les directives européennes ; téléchargez-le à la fin.
Quand est-elle requise
Une analyse d'impact relative à la protection des données (AIPD) est requise en vertu de l'article 35 du RGPD chaque fois qu'un traitement est susceptible d'engendrer un risque élevé. Le traitement à grande échelle de catégories spéciales de données, telles que les données de santé, est une déclencheur automatique. Selon les critères du CEPD, une application de santé répond généralement à plusieurs critères (données sensibles, grande échelle, personnes vulnérables), donc presque toutes les applications de santé en nécessitent une avant le début du traitement.
L'article 35(3) liste trois déclencheurs automatiques : le profilage systématique et approfondi ayant des effets significatifs ; le traitement à grande échelle de catégories particulières de données (article 9) ou de données relatives aux condamnations pénales ; la surveillance systématique à grande échelle de zones accessibles au public. Les critères du Comité européen de la protection des données (issus de l'ancien Groupe de travail de l'article 29) en ajoutent six autres ; si deux critères ou plus s'appliquent, effectuez une AIPD : évaluation ou notation ; décisions automatisées ayant des effets juridiques ou similaires ; surveillance systématique ; données sensibles ; grande échelle ; recoupement ou combinaison de jeux de données ; données concernant des personnes vulnérables (les patients comptent) ; utilisation innovante de la technologie ; empêchement pour les personnes d'exercer un droit ou d'utiliser un service. Une application de santé touche généralement aux données sensibles, à la grande échelle, aux personnes vulnérables et souvent à la technologie innovante. Les autorités nationales publient également des listes de traitements qui nécessitent toujours une AIPD (article 35(4)) ; la plupart incluent les applications de santé et les appareils connectés.
La liste de contrôle
Une liste de contrôle d'AIPD pour une application de santé suit les quatre éléments de l'article 35(7) du RGPD : une description du traitement (finalités, données, acteurs, technologie), une évaluation de la nécessité et de la proportionnalité (base juridique, minimisation, droits, sous-traitants, conservation), une évaluation des risques pour les personnes dont les données sont utilisées, et les mesures qui traitent ces risques, suivies d'une consultation, d'une approbation et d'une révision périodique.
1. Décrire le traitement (Art. 35(7)(a))
- Finalités, une par une : stockage des dossiers de la personne ; partage avec une clinique ; rappels ; statistiques anonymisées ; fonctionnalités d'IA.
- Catégories de données par finalité, avec les données de santé marquées ; sources (la personne, cliniques, appareils portables, documents) ; destinataires ; conservation par catégorie ; transferts hors de l'UE et leur mécanisme.
- Acteurs : responsable(s) de traitement, sous-traitants (hébergement, analyse, outils de support, fournisseurs d'IA) avec leurs contrats ; le délégué à la protection des données (DPD).
- Technologie : architecture, emplacement des données, chiffrement, identité, journalisation. Un diagramme de flux de données est le moyen le plus rapide de trouver ce que vous avez oublié.
2. Nécessité et proportionnalité (Art. 35(7)(b))
- Base juridique en vertu de l'article 6 et de l'exception de l'article 9(2), par finalité (Article 9 du RGPD expliqué).
- Minimisation des données : pour chaque élément de donnée, pourquoi il est nécessaire ; ce que vous avez décidé de ne pas collecter.
- Information des personnes (articles 13-14) et comment les droits (accès, rectification, effacement, portabilité, opposition, retrait du consentement) sont exercés dans le produit, et non par e-mail au support.
- Sous-traitants : contrats de l'article 28 en place ; sous-traitants listés ; droits d'audit.
- Conservation et suppression : périodes concrètes et le mécanisme qui les applique.
3. Risques pour les personnes (Art. 35(7)(c)) Évaluez la probabilité et la gravité pour chacun des trois événements classiques, pour chaque finalité :
- Accès illégitime (violation, initiated interne, partage trop large, une clinique voyant plus que ce qui est approuvé) ;
- Modification non désirée (données erronées dans un dossier sur lequel un clinicien se fie, erreurs de synchronisation, une fonctionnalité d'IA écrivant dans le dossier) ;
- Disparition (perte d'un dossier dont la personne dépend ; prise de contrôle de compte ; un fournisseur qui ferme). Puis les risques spécifiques à la santé : ré-identification de statistiques "anonymes" ; inférence de conditions à partir du comportement ; discrimination si les données parviennent aux assureurs ou aux employeurs ; préjudice causé par les données d'enfants ; données de localisation autour des cliniques ; SDK tiers dans l'application envoyant des données à des réseaux publicitaires (la constatation la plus fréquente dans les audits réglementaires d'applications de santé).
4. Mesures (Art. 35(7)(d)) Pour chaque risque, le contrôle et le risque résiduel : chiffrement au repos et en transit ; authentification forte ; accès limité par consentement et par temps, avec des journaux que la personne peut lire ; pseudonymisation dans l'analyse et dans les journaux ; pas de SDK publicitaires ou de suivi tiers ; environnements séparés et données synthétiques pour le développement ; sauvegardes avec restauration testée ; revue des fournisseurs ; réponse aux incidents avec l'horloge des 72 heures ; pratiques de développement sécurisé ; formation du personnel et confidentialité ; exportation et suppression des données dans le produit ; un "kill switch" pour les intégrations.
5. Consultation
- L'avis du DPD est enregistré (Art. 35(2)) ; les points de vue des personnes ou de leurs représentants sont sollicités lorsque cela est approprié (Art. 35(9)), par exemple par le biais d'un panel d'utilisateurs ou d'une association de patients.
- Si un risque résiduel élevé subsiste, consultez l'autorité de contrôle avant le traitement (Art. 36). La plupart des applications de santé bien contrôlées n'atteignent pas ce stade ; les plateformes traitant pour de nombreuses cliniques y parviennent parfois.
6. Approbation et révision
- Approuvé par la direction du responsable de traitement ; daté ; versionné.
- Révisé lorsque les finalités, les données, la technologie ou les destinataires changent, et au moins tous les un ou deux ans (Art. 35(11)).
Constatations typiques dans les AIPD d'applications de santé
Les constatations les plus courantes dans les AIPD d'applications de santé concernent les SDK d'analyse et de rapport de plantage qui reçoivent des identifiants avec le contexte de santé, les notifications push qui révèlent des conditions sur l'écran de verrouillage, le personnel de support ayant un accès illimité à la base de données, les sauvegardes en dehors de l'UE, les données conservées après la fermeture d'un compte, les écrans de consentement qui regroupent les finalités, et les ensembles de données "anonymisés" qui identifient toujours les personnes.
Chacun de ces points a une solution concrète, et l'AIPD est l'endroit où la solution est engagée.
Le modèle
Le modèle d'AIPD sur cette page est un document Markdown remplissable pour une application de santé, structuré en six sections (description du traitement, nécessité et proportionnalité, risques pour les personnes, mesures, consultation, approbation et révision) avec un tableau des risques et un tableau des mesures. Il suit l'article 35(7) du RGPD et les critères du CEPD, et constitue une structure de départ, pas un avis juridique.
Télécharger le modèle d'AIPD. Il peut être importé dans n'importe quel outil de document ; votre DPO l'adapte.
Chez Anpheros
Anpheros maintient une AIPD pour Anpheros Daily et une pour Anpheros Platform en tant que sous-traitant, avec la structure ci-dessus, et les choix qui en ont découlé sont visibles dans le produit : consentement par finalité, accès limité et journalisé, pas de SDK publicitaires, hébergement dans l'UE, exportation et suppression dans l'application. Voir Transparence de la santé.
Cette page explique la réglementation pour les équipes produit et ingénierie. Ce n'est pas un conseil juridique ; les textes liés sous Sources font autorité, et votre délégué à la protection des données, organisme notifié ou conseiller décide pour votre cas. Dernière révision : octobre 2026.
Pages connexes
- Article 9 du RGPD pour les données de santé
- Dé-identification des données de santé
- Qui a consulté mon dossier médical ?
- Une application de santé est-elle un dispositif médical ?
- ISO 27001 vs ISO 27799
- Carte de la réglementation des données de santé
Sources
- Articles 35 et 36 du RGPD, EUR-Lex
- Groupe de travail de l'article 29 / CEPD : Lignes directrices sur l'AIPD (WP248 rev.01)
- CNIL : Méthodologie et logiciel d'analyse d'impact relative à la protection des données (PIA)
- ICO : Data protection impact assessments
- CEPD : lignes directrices, recommandations et bonnes pratiques
Questions fréquentes
Ai-je besoin d'une AIPD pour une petite application avec peu d'utilisateurs ?
Si elle traite des données de santé, presque toujours oui : les données sensibles plus les personnes vulnérables satisfont déjà au critère des deux conditions, et plusieurs listes nationales citent explicitement les applications de santé. L'AIPD d'une petite application est simplement plus courte.
Qui rédige l'AIPD ?
Le responsable de traitement est responsable ; en pratique, le propriétaire du produit et le responsable de l'ingénierie la rédigent avec l'avis du DPD, car ils connaissent les flux de données. L'externalisation complète produit un document que personne ne peut maintenir à jour.
L'AIPD doit-elle être publiée ?
Non. C'est un document de responsabilité interne présenté à l'autorité de contrôle sur demande. De nombreuses organisations publient un résumé ; l'EHDS et certaines réglementations nationales exigent la transparence sur certains traitements.
En quoi une AIPD diffère-t-elle d'une évaluation des risques selon l'ISO 27001 ?
L'évaluation ISO examine les risques pour l'organisation ; l'AIPD examine les risques pour les personnes dont les données sont traitées. Elles partagent des contrôles et des preuves, et un bon programme de sécurité alimente la section des mesures de l'AIPD.
Essayez gratuitement dans le sandbox
Votre premier appel FHIR en 5 minutes. Une API HL7 FHIR R4 avec le consentement du patient intégré : essayez-la dans le bac à sable, puis connectez votre propre application ou système de clinique.
Gratuit · 30 patients synthétiques · sans carte
Anpheros développe un dossier médical que le patient contrôle et peut partager avec n'importe quelle clinique, sur une plateforme HL7 FHIR R4, basée en UE. Ces guides vous aident à comprendre et organiser votre santé ; ils ne remplacent pas votre médecin.
À propos d'Anpheros →