Construire un operating model de data governance en pharma

L'accroche : deux jeux de données, deux propriétaires très différents

Imaginez une réunion du comité de data governancedata governanceLa data governance est l'ensemble des politiques, rôles et processus qui garantissent que les données sont exactes, sécurisées, bien définies et utilisées de façon responsable dans toute l'organisation.Voir la définition complète → d'un laboratoire pharmaceutique de taille intermédiaire en 2026. Point un : à qui appartiennent les données d'engagement HCP (Health Care Professional) générées quand un commercial enregistre une conversation avec un cardiologue dans le CRMCRMCustomer Relationship Management : logiciel et stratégie pour gérer et analyser les interactions clients tout au long de leur cycle de vie.Voir la définition complète → (Customer Relationship Management system) ? Point deux : à qui appartiennent les données de biomarqueurs issues des prélèvements sanguins d'un essai de phase II, aujourd'hui stockées dans un système d'information de laboratoire ?

Ces deux questions de « propriété des données » semblent similaires. Elles ne le sont pas. Les données d'engagement HCP sont revendiquées conjointement par le Commercial (qui en a besoin pour son ciblage) et par le Medical Affairs (qui en a besoin pour la revue de conformité des interactions promotionnelles). Les données de biomarqueurs sont revendiquées par la R&D (qui en a besoin pour l'analyse du critère principal) et de plus en plus par le Commercial (qui veut des signaux précoces de biomarqueurs pour préparer le lancement).

Le rôle du comité n'est pas de désigner un « propriétaire » unique au sens IT. Il s'agit d'attribuer la data stewardshipdata stewardshipUn responsable côté métier, garant de la qualité, de la cohérence et du bon usage des données de son domaine.Voir la définition complète → (la responsabilité opérationnelle de la qualité des données, des règles d'accès et du cycle de vie), distincte de la data ownership (la redevabilité sur l'usage qui est fait des données), et de documenter les deux dans une politique auditable par toute l'entreprise.

Pourquoi la pharma a besoin d'un operating model formel, pas d'un simple PDF de politique

La pharma se situe au croisement des régimes de confidentialité les plus stricts et des réglementations produit les plus strictes. Un operating model de data governance, c'est la structure concrète (rôles, comités, outils, cadences de revue) qui rend la politique applicable au quotidien.

Trois forces réglementaires rendent la chose incontournable :

• 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 → (General Data Protection Regulation, UE, en vigueur depuis 2018) encadre toute donnée personnelle rattachée à des patients ou des HCP européens, y compris, selon de nombreuses interprétations, les données d'essai pseudonymisées.
• 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. (Health Insurance Portability and Accountability Act, États-Unis, 1996) encadre les protected health information (PHI) détenues par les covered entities et leurs business associates, ce qui compte lorsque les laboratoires reçoivent de la real-world datareal-world dataRWD, données collectées en dehors des essais cliniques contrôlés : dossiers médicaux, claims d'assurance, données de dispositifs connectés, base des Real-World Evidence (RWE). de systèmes de santé.
• Le 21 CFR Part 11 (réglementation FDA sur les enregistrements et signatures électroniques) encadre l'intégrité des données soutenant les dossiers réglementaires : une défaillance de gouvernance sur des données d'essai peut compromettre une approbation, pas seulement déclencher une amende sur la vie privée.

Ajoutez à cela le Clinical Trials Regulation (536/2014) européen et les guidances FDA sur l'intégrité des données, et vous comprenez pourquoi « qui peut toucher ce dataset, et comment le prouver » est une question de conseil d'administration, pas un simple ticket IT.

Les rôles clés : qui fait quoi concrètement

Un operating model qui fonctionne a besoin de rôles nommés, pas seulement d'une déclaration de politique. La structure pharma standard ressemble à ceci :

Data Owner : un dirigeant métier senior (par exemple VPVPFormulation claire des bénéfices apportés par votre produit, des problèmes qu'il résout et des raisons pour lesquelles les clients doivent vous choisir plutôt qu'une alternative.Voir la définition complète → Clinical Operations, VP Commercial Analytics) redevable des données d'un domaine. Les owners approuvent les politiques d'accès et valident les nouveaux usages.

Data Steward : un rôle opérationnel (souvent intégré dans la fonction métier, pas dans l'IT) qui gère au quotidien la qualité des données, les métadonnées et les demandes d'accès. Un data steward clinique s'assure que les datasets d'essai sont propres avant le database lock ; un data steward commercial s'assure que les enregistrements HCP sont dédoublonnés et que les flags de consentement sont à jour.

Data Governance Council : une instance transverse, réunissant typiquement R&D, Medical, Commercial, Legal, Privacy/Compliance et IT, qui se réunit tous les mois ou tous les trimestres pour arbitrer les litiges (comme l'exemple HCP vs biomarqueurs ci-dessus) et approuver les nouveaux accords de partage de données.

Data Protection Officer (DPO) : un rôle légalement obligatoire au titre du RGPD pour beaucoup de laboratoires, indépendant des data owners opérationnels, responsable de la supervision de la conformité en matière de vie privée.

Qualified Person / Data Integrity Lead : dans les contextes GxP (Good Practice, par exemple Good Clinical Practice, Good Manufacturing Practice), un rôle redevable de la conformité des données soutenant les dépôts réglementaires aux principes ALCOA+ (Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring, Available).

Niveaux d'accès : tout le monde n'a pas la même vue

Un modèle de gouvernance opérationnel définit des niveaux d'accès liés au rôle et à la finalité, pas seulement à la séniorité. Une structure courante :

Ce découpage en tiers est ce qui rend un data-sharing agreement (DSA) applicable. Un DSA est un contrat qui précise quelles données circulent entre deux parties (disons un laboratoire et un hôpital universitaire menant une étude de real-world evidence), sous quel tier, dans quel but et pour combien de temps. Chaque DSA devrait renvoyer explicitement à l'un de ces tiers plutôt que d'employer un langage vague comme « données dé-identifiées » sans définir le standard utilisé (le HIPAA Safe Harbor et la guidance d'anonymisation de l'EMA diffèrent dans le détail).

Un exemple concret : le routage d'une demande de données

Supposons qu'une équipe market access demande des données de prescription HCP reliées à des données d'outcomes en vie réelle pour construire un value dossier destiné aux payeurs. Le workflow de gouvernance :

1. Demande soumise au Data Steward concerné (Commercial Analytics).
2. Le steward vérifie : cela nécessite-t-il le Tier 2 (pseudonymisé, validation DPO requise) ou le Tier 3 (agrégé) suffit-il au besoin métier ?
3. Si le Tier 2 est réellement nécessaire, la demande remonte au Data Governance Council avec une limitation de finalité documentée (principe de l'article 5 du RGPD : des données collectées pour une finalité ne peuvent être librement réutilisées pour une autre).
4. Le juridique vérifie la cohérence avec les DSA existants avec la source de données (par exemple un fournisseur de données de remboursement comme IQVIA ou un système de santé).
5. Accès accordé avec une date d'expiration et consigné dans un registre d'accès, auditable ultérieurement.

Un extrait simple de contrôle d'accès illustrant la logique qu'une équipe de gouvernance pourrait coder dans un système de demande d'accès :

def evaluate_request(purpose, data_tier_requested, requester_role):
    if data_tier_requested == "Tier1_Identified" and requester_role not in ["trial_site_staff", "treating_physician"]:
        return "DENY: identified data restricted to clinical care roles"
    if purpose not in APPROVED_PURPOSES[data_tier_requested]:
        return "ESCALATE: purpose not pre-approved, route to Governance Council"
    return "APPROVE: log access, set 12-month expiry"

C'est une logique illustrative, pas un moteur de conformité réel, mais elle montre comment les décisions de gouvernance s'opérationnalisent en règles système plutôt que de rester dans un document de politique.

Audits et contrôles : prouver que le modèle fonctionne

Un modèle de gouvernance ne vaut que par sa piste d'audit. Les contrôles pratiques que mènent les équipes pharma :

• Audits de consentement : échantillonner trimestriellement les enregistrements HCP et patients pour confirmer que les flags de consentement correspondent à l'usage réel des données (critique au titre du principe d'accountability du RGPD).
• Revues des logs d'accès : qui a accédé aux données Tier 1/2 au dernier trimestre, et chaque accès correspondait-il à une finalité approuvée ?
• Contrôles de data lineage : pour tout chiffre figurant dans un dossier réglementaire, pouvez-vous remonter jusqu'à l'enregistrement source brut (exigence centrale du Part 11 / ALCOA+) ?
• Balayages d'expiration des DSA : y a-t-il des accords de partage de données qui fonctionnent au-delà de leur date de fin contractuelle ?

La guidance de l'ICO britannique sur la protection des données dès la conception est une bonne référence gratuite pour structurer ces audits, même hors du Royaume-Uni, puisque beaucoup de laboratoires appliquent un standard global unique.

Où ça coince en pratique

Le mode de défaillance le plus courant n'est pas la malveillance, c'est l'ambiguïté. Les équipes commerciales réutilisent des signaux de biomarqueurs issus d'essais pour du ciblage de lancement sans revérifier si le consentement patient initial couvrait un usage commercial secondaire. Les équipes R&D gardent des données de vie réelle dont le Medical Affairs a besoin pour une revue de signal de sécurité, parce que personne n'a formellement attribué la stewardship au moment de l'onboarding de la source.

Les bons comités de gouvernance corrigent cela en exigeant un registre des cas d'usage de données dès l'entrée : chaque nouvelle source obtient un owner, un steward, des finalités autorisées et un tier documentés, avant que le premier analyste n'y touche, et non après qu'un problème est apparu.

Points clés à retenir

• Séparez la data ownership (redevabilité sur l'usage) de la data stewardship (qualité opérationnelle et gestion des accès) ; en pharma, les litiges naissent généralement de la confusion entre les deux.
• Construisez les accès autour de tiers définis (identifié, pseudonymisé, agrégé, synthétique) et exigez que chaque data-sharing agreement référence explicitement un tier, plutôt que des termes vagues comme « dé-identifié ».
• Ancrez l'operating model dans des réglementations nommées : RGPD et HIPAA pour la vie privée, 21 CFR Part 11 et ALCOA+ pour l'intégrité des données soutenant les dossiers réglementaires.
• Menez des audits récurrents (contrôles de consentement, revues de logs d'accès, traçages de data lineagedata lineageLe data lineage cartographie les déplacements et transformations de la donnée à travers les systèmes, de l'origine à la consommation : d'où elle vient, ce qui l'a modifiée, et où elle va.Voir la définition complète →, balayages d'expiration des DSA) plutôt que de traiter la gouvernance comme une validation de politique ponctuelle.
• Utilisez un Data Governance Council transverse pour arbitrer les conflits de propriété (R&D vs Commercial vs Medical) avant qu'ils ne deviennent des incidents de conformité.