Mener un audit privacy et gouvernance avant une inspection réglementaire

Un inspecteur de la FDA arrive chez un fabricant de capteurs de glycémie en continu (CGM). En deux heures, il demande l'audit trail montrant qui a accédé aux relevés de glycémie des patients en mars dernier. L'entreprise sort le log. Il est vide. Personne n'avait activé la journalisation sur la base analytique. Cette seule lacune peut déclencher un Form 483 (la liste officielle des observations d'inspection de la FDA) et, si elle n'est pas résolue, une Warning Letter qui bloque les expéditions.

La solution ne consiste pas à compter sur la chance le jour de l'inspection. C'est un audit à blanc que vous menez vous-même, des mois plus tôt, face à une checklist concrète. Cette leçon vous donne cette checklist.

Pourquoi les pipelines de données des dispositifs sont un champ de mines en matière de gouvernance

Un pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète → medtech moderne fait passer les données entre de nombreuses mains : capteur sur le patient, application mobile, ingestion cloud, entrepôt analytique, et parfois un modèle de machine learning qui signale les anomalies. Chaque saut est un point où le consentement peut manquer, où les accès peuvent être trop largement accordés, ou où une violation peut passer sous silence.

Deux régulateurs très différents s'y intéressent, et ils posent des questions différentes.

• FDA (US Food and Drug Administration) : s'intéresse à l'intégrité des données et à la sécurité du dispositif. Son prisme, c'est le 21 CFR Part 11 (règles sur les enregistrements et signatures électroniques) et, pour la culture de préparation aux audits, le 21 CFR Part 820 (Quality System Regulation, qui converge désormais avec l'ISO 13485 dans le cadre de la transition vers la Quality Management System Regulation de 2026).
• Autorités de protection des données (DPA) : s'intéressent aux droits sur les données personnelles. Dans l'UE, cela veut dire le RGPD (Règlement général sur la protection des données) ; aux États-Unis, des règles sectorielles comme HIPAA (Health Insurance Portability and Accountability Act) plus des lois d'État comme le CCPA/CPRA californien.

Le piège : les équipes se préparent pour l'un et oublient l'autre. Des données de santé irréprochables aux yeux de la FDA sur le plan de l'intégrité peuvent rester un désastre de consentement au regard du RGPD.

Le concept central : intégrité des données plus droits sur les données

Pensez votre audit en deux colonnes.

Intégrité des données (prisme FDA). Le raccourci du secteur est ALCOA+ : les données doivent être Attribuables, Lisibles, Contemporaines, Originales, Exactes, et en plus Complètes, Cohérentes, Durables et Disponibles. Si vos relevés CGM ne peuvent pas être rattachés à un utilisateur précis et à un horodatage, ils échouent sur « Attribuables ».

Droits sur les données (prisme DPA). Le patient a-t-il consenti à cet usage précis ? Peut-il faire supprimer ses données ? La violation a-t-elle été notifiée dans les délais ?

Un bon audit à blanc parcourt le pipeline une fois et note chaque étape sur les deux colonnes.

La checklist de l'audit à blanc

Menez-la comme un exercice sur table avec vos équipes data, juridique et qualité dans la salle. Suivez un enregistrement réel de bout en bout (choisissez les données d'un seul patient et tracez-les).

1. Consentement et base légale

• Existe-t-il une base légale enregistrée pour chaque finalité de traitement ? Sous le RGPDRGPDRèglement de l'UE encadrant la collecte, le stockage et l'usage des données personnelles, avec des amendes indexées sur le chiffre d'affaires mondial.Voir la définition complète →, « nous collectons les données de glycémie pour faire fonctionner le dispositif » et « nous utilisons les données de glycémie pour entraîner un modèle d'IA » sont deux finalités distinctes qui exigent deux justifications distinctes.
• Pour les usages secondaires (recherche, entraînement de modèles), le consentement est-il spécifique et révocable ? Une simple case à cocher globale à l'inscription ne suffit généralement pas.
• Lacune concrète à chasser : des équipes analytics qui extraient des données identifiables pour un usage que le patient n'a jamais vu dans le formulaire de consentement.

2. Contrôles d'accès

• Sortez la liste d'accès réelle. Qui peut lire les enregistrements patients bruts ? Comparez avec qui *devrait* pouvoir. C'est le principe du moindre privilège.
• Cherchez les comptes de service partagés (un identifiant utilisé par cinq ingénieurs). Ils cassent l'« Attribuable » et constituent un finding classique au titre du Part 11.
• Vérifiez les comptes orphelins : anciens salariés ou prestataires sortis toujours actifs.

3. Audit trails et journalisation

• Chaque lecture, écriture et suppression de données personnelles est-elle journalisée, avec identifiant utilisateur et horodatage ?
• Les logs sont-ils infalsifiables (append-only, pour que personne ne puisse les modifier discrètement) ? Le Part 11 l'attend.
• La scène CGM ci-dessus, c'est exactement cette défaillance : une couche analytique sans journalisation.

4. Minimisation et conservation des données

• Stockez-vous plus que nécessaire ? Un modèle qui n'a besoin que de tendances anonymisées ne devrait pas reposer sur des noms en clair.
• Existe-t-il un calendrier de conservation avec suppression automatisée ? « On garde tout pour toujours » est une violation du RGPD et un problème de rayon d'explosion en cas de breach.

5. Préparation à la notification de violation

• Le RGPD impose de notifier la DPA dans les 72 heures suivant la prise de connaissance d'une violation qui menace les droits des personnes.
• HIPAAHIPAAHealth Insurance Portability and Accountability Act, loi américaine imposant la protection des données de santé (PHI). Violations : amendes jusqu'à 1,9M$ par catégorie de violation. impose de notifier les personnes concernées sans délai déraisonnable et au plus tard 60 jours après, et de déclarer les violations de grande ampleur (500 personnes et plus) au Department of Health and Human Services (HHS).
• Testez-le : simulez une violation. Lancez un chronomètre. Votre équipe peut-elle identifier les enregistrements concernés, évaluer le risque et rédiger la notification dans la fenêtre ?

6. Prestataires et transferts hors frontières

• Les fournisseurs cloud et sous-traitants ultérieurs ont besoin de Data Processing Agreements (DPA, version contrat) signés.
• Des données de patients européens qui atterrissent sur des serveurs américains exigent un mécanisme de transfert valide (par exemple, les clauses contractuelles types ou l'EU-US Data Privacy Framework). Vérifiez qu'il existe, ne le présumez pas.

Une bonne référence gratuite côté intégrité est le MHRA « GXP Data Integrity Guidance and Definitions », largement utilisé dans les sciences de la vie réglementées, même en dehors du Royaume-Uni.

Un exemple chiffré : noter le chrono de la notification de violation

Supposons que votre violation simulée concerne des patients européens. Chronologie d'un test réaliste :

• Heure 0 : l'outil de sécurité signale un export inhabituel depuis l'entrepôt.
• Heure 14 : l'équipe confirme qu'il s'agit d'une vraie violation (c'est la « prise de connaissance » au sens du RGPD, le chrono démarre ici, pas à l'heure 0).
• Fenêtre heure 14 à 72 : 58 heures pour notifier la DPA.

Si votre équipe a mis 40 heures uniquement pour identifier quels patients étaient concernés, faute d'inventaire de données propre, il vous reste 18 heures pour évaluer et déposer. C'est l'écart que l'audit à blanc met au jour. Le chiffre à suivre et à améliorer est le temps d'identification des enregistrements concernés. Faites-le baisser et le chrono des 72 heures cesse d'être terrifiant.

Une vérification technique rapide que vous pouvez réellement lancer

Les auditeurs adorent demander « prouvez le moindre privilège ». Une simple requête sur vos données de gestion des accès fait remonter les comptes sur-privilégiés avant eux :

-- Trouver les comptes ayant un accès en lecture aux données patients brutes
-- qui n'y ont PAS accédé depuis 90 jours ou plus (candidats à la révocation)
SELECT u.user_id, u.role, MAX(a.access_ts) AS last_access
FROM user_grants u
LEFT JOIN access_log a
  ON u.user_id = a.user_id
 AND a.resource = 'patient_raw'
WHERE u.resource = 'patient_raw'
GROUP BY u.user_id, u.role
HAVING MAX(a.access_ts) < NOW() - INTERVAL '90 days'
    OR MAX(a.access_ts) IS NULL;

Les lignes renvoyées constituent votre liste de nettoyage. Les lignes avec un dernier accès NULL sont particulièrement accablantes : accès accordé, jamais utilisé, du risque pur.

🎬 [VIDEO: "GDPR Explained in 5 Minutes" - youtube.com - un parcours concis et en langage clair des principes fondamentaux du RGPD pour les non-juristes]

TransformerTransformerUn Transformer est une architecture de réseau de neurones qui utilise le self-attention pour traiter des séquences en parallèle. Elle est au cœur de la plupart des modèles de langage et d'IA générative actuels.Voir la définition complète → les findings en plan de remédiation

Un audit à blanc qui produit une liste effrayante et aucun plan est du théâtre. Convertissez chaque finding en action suivie.

Pour chaque lacune, notez quatre choses :

1. Finding : « La base analytique n'a pas de journalisation des lectures. »
2. Notation du risque : élevé, moyen, faible (une lacune de journalisation sur des données de santé identifiables est élevée).
3. Responsable et échéance : une personne nommée, une date réelle.
4. Preuve de clôture : une capture d'écran de la configuration de log activée, un ticket de révocation d'accès, une nouvelle version du formulaire de consentement.

Cela reflète la manière dont la FDA attend que vous répondiez à un vrai Form 483 : pas seulement « nous l'avons corrigé », mais avec des preuves objectives et une analyse de cause racine pour que la lacune ne se reproduise pas. La même discipline satisfait une DPA qui examine vos obligations de responsabilité (accountability) au titre de l'article 5 du RGPD, qui exige que vous *démontriez* la conformité, pas simplement que vous la revendiquiez.

Schémas courants qui échouent devant les deux régulateurs à la fois

• Le compte « analytics » partagé casse l'attributionattributionUn framework qui attribue le crédit d'une conversion aux différents touchpoints y ayant contribué, afin de mesurer quels canaux et quelles interactions génèrent réellement des résultats.Voir la définition complète → FDA *et* le contrôle d'accès RGPD.
• « On l'a anonymisé » alors que les données ne sont en réalité que pseudonymisées (toujours réidentifiables) échoue au regard du RGPD *et* sape votre discours sur la minimisation.
• Pas de limites de conservation signifie une exposition plus large en cas de breach *et* une faiblesse de gestion des enregistrements au titre du Part 11.

Corriger cela une fois rapporte deux fois.

Points clés

• Auditez sur deux colonnes à la fois : intégrité des données (FDA, ALCOA+, Part 11) et droits sur les données (RGPD, HIPAA, CCPA). Se préparer pour l'un vous laisse exposé sur l'autre.
• Tracez un enregistrement réel de bout en bout dans le pipeline. Les revues de politiques abstraites passent à côté du log vide et du compte orphelin que le traçage concret attrape.
• Chronométrez votre réponse à incident en simulation. Le chrono de 72 heures du RGPD et la règle des 60 jours d'HIPAA ne sont tenables que si votre inventaire de données vous permet d'identifier rapidement les enregistrements concernés.
• Chaque finding a besoin d'un responsable, d'une échéance et d'une preuve de clôture. C'est exactement ce qui transforme un audit à blanc en véritable préparation à l'inspection.
• Corrigez d'abord les défaillances transversales (comptes partagés, absence de journalisation, absence de limites de conservation) : elles satisfont les deux régulateurs d'un seul geste.

Cette leçon a une visée pédagogique et ne constitue pas un conseil juridique ou réglementaire. Confirmez les exigences en vigueur avec un conseil qualifié et l'autorité compétente avant une inspection.