Module 0 · Section 0.2

Éthique et bonnes pratiques des données

50 min · niveau debutant · dernière révision : 2026-11-01

Objectifs d'apprentissage

Distinguer données personnelles, données de santé et données réellement anonymisées
Choisir entre anonymisation et pseudonymisation selon l'usage prévu et le risque de réidentification
Appliquer les principes de consentement, de minimisation et de durée de conservation à un projet
Lire une licence de données ou de code et vérifier si un usage est autorisé
Auditer un jeu de métadonnées synthétique et formuler des recommandations proportionnées

Prérequis : 0.1 Introduction et reproductibilité

Python 3.11+Supabase 2.x

Prérequis

Cette section suppose que vous savez installer un environnement Python et organiser un projet, comme dans le module 0. Les conventions du cours s'appliquent : identifiants et fonctions en anglais, texte en français. La section 1.1 a introduit les fichiers de séquences ; nous retrouverons ces formats sans les analyser. Aucune compétence juridique n'est requise : nous présentons des principes de conception, pas un avis juridique. Tous les exemples de données sont synthétiques.

Introduction

La bioinformatique manipule des données qui décrivent des personnes : génomes, exomes, matrices d'expression tumorale, fichiers VCF (Variant Call Format), tables de phénotypes. Un petit projet étudiant est concerné dès qu'il assemble quelques génomes ou compare des patients atteints d'une maladie rare. Ces données sont précieuses et sensibles parce qu'elles sont uniques, stables et partagées avec des apparentés.

Le risque computationnel est discret mais structurant. Les identifiants se cachent dans les en-têtes, les noms de colonnes, les commentaires, les noms de fichiers, les métadonnées d'images et les journaux. Une jointure peut reconstruire une identité que chaque table semblait protéger. Un modèle de langage (large language model, LLM) peut conserver un prompt et l'utiliser pour l'entraînement. Une licence mal lue peut interdire un partage que le code rend techniquement possible.

Cette section relie protection des personnes, conformité des usages et reproductibilité. Nous partons des données personnelles et du consentement, puis distinguons anonymisation et pseudonymisation. Nous examinons ensuite la minimisation, les licences, le stockage et les transferts vers l'intelligence artificielle (IA). L'étude de cas pseudonymise un jeu de métadonnées patients entièrement synthétique et montre pourquoi supprimer un nom ne suffit pas.

Théorie

Données personnelles, données de santé, données humaines

Une donnée personnelle se rapporte à une personne physique identifiée ou identifiable. L'identification peut être directe (nom, courriel, numéro de dossier) ou indirecte (combinaison d'attributs). Le Règlement général sur la protection des données (RGPD) tient compte de tous les moyens raisonnablement susceptibles d'être utilisés, y compris par recoupement. Une donnée pseudonymisée reste donc personnelle dès qu'une information supplémentaire permet de remonter à la personne. Seules les données véritablement anonymes, dont la réidentification n'est pas raisonnablement possible, sortent de son champ.

Les données de santé sont une catégorie particulière : état de santé, soins reçus, données génétiques. Un variant rare, une séquence tumorale ou une image médicale peuvent révéler une maladie, une prédisposition ou une parenté. Le caractère sensible ne dépend pas du nom de la colonne : une table features contenant un âge, un code postal et un diagnostic redevient identifiante par combinaison. À l'inverse, une séquence de référence publique, comme Escherichia coli K-12 MG1655, accession NC_000913.3, ne décrit aucune personne.

Trois plans se recoupent : juridique, éthique et technique. Un chiffrement parfait ne rend pas licite un usage non consenti, et un consentement signé ne protège pas contre une fuite.

Consentement, information et droit de retrait

Le consentement éclairé repose sur une information compréhensible : finalité, données collectées, durée, risques et bénéfices, partage, droits et contact. Il doit être libre, spécifique, informé et univoque. Un consentement large peut couvrir plusieurs études futures si les finalités, les catégories de données et les garanties sont encadrées. Un consentement obtenu pour une analyse ciblée ne couvre pas automatiquement un partenariat industriel ou un transfert vers un fournisseur d'IA.

Le droit de retrait s'applique aux traitements futurs. Les analyses déjà réalisées et les résultats agrégés publiés ne disparaissent pas rétroactivement, et le droit à l'effacement connaît des limites, notamment pour la recherche scientifique et les obligations légales. La conception doit donc prévoir un identifiant de consentement, une version, un canal de retrait et une procédure de suppression ou d'anonymisation. Un tableur sans traçabilité rend ces opérations coûteuses.

Le consentement n'est pas la seule base légale : mission d'intérêt public, obligation légale ou intérêt légitime peuvent fonder un traitement, sous conditions. La conformité se documente avec le délégué à la protection des données (data protection officer, DPO) et l'équipe juridique, pas dans une case cochée. Les modalités exactes dépendent de la base légale et du droit national. [À VÉRIFIER]

Anonymisation et pseudonymisation

La pseudonymisation remplace un identifiant direct par un pseudonyme tout en conservant séparément la possibilité de faire le lien. La table de correspondance ou la clé secrète constitue l'information supplémentaire qui rend la réidentification possible. Les données pseudonymisées restent personnelles et soumises aux mêmes principes : la pseudonymisation réduit l'exposition, pas les obligations.

L'anonymisation vise un état où la réidentification n'est pas raisonnablement possible. C'est un processus documenté, évalué selon le contexte et les auxiliaires disponibles, pas un label définitif. Supprimer le nom et le prénom ne suffit presque jamais : il reste des quasi-identifiants comme l'âge, le sexe, le code postal, la date d'hospitalisation, le diagnostic rare ou la profession. Leur combinaison peut isoler un individu. La k-anonymité exige que chaque combinaison de quasi-identifiants apparaisse au moins $k$ fois : pour chaque classe d'équivalence $G$ ,

|G| \geq k.

Plus $k$ est grand, plus l'incertitude augmente, mais plus l'information utile diminue. La k-anonymité ne protège ni contre l'homogénéité d'un groupe, ni contre des connaissances externes, ni contre les données longitudinales. C'est un indicateur, pas une garantie.

La pseudonymisation technique utilise souvent un HMAC (Hash-based Message Authentication Code), un hachage muni d'une clé secrète. Le même identifiant et la même clé donnent le même pseudonyme, ce qui permet de relier deux tables sans stocker l'identifiant d'origine. Un SHA-256 sans clé est insuffisant pour des identifiants structurés : un attaquant peut tester PAT-0001, PAT-0002 et retrouver la correspondance. Le « sel » de l'exercice est donc une clé secrète, conservée dans un gestionnaire de secrets et jamais publiée avec les données.

La troncature du pseudonyme crée un compromis. Avec $b$ bits de sortie et $N$ identifiants, la probabilité approximative de collision vaut

P(\text{collision}) \approx \frac{N(N-1)}{2 \cdot 2^b}.

Pour $N = 10^6$ et $b = 64$ , on obtient environ $1{,}4 \times 10^{-8}$ , une chance sur 70 millions. Seize caractères hexadécimaux, soit 64 bits, suffisent donc pour un million d'enregistrements dans cet usage. Huit caractères, soit 32 bits, rendent la collision probable dès quelques dizaines de milliers d'enregistrements. Une collision mélange deux dossiers.

Un HMAC n'est pas un chiffrement : il est à sens unique, alors qu'un chiffrement est réversible avec une clé. Si la réidentification est nécessaire, la table de correspondance est séparée, chiffrée et réservée à un rôle restreint ; sinon, elle est détruite et la décision est documentée. Pseudonymiser patient_id en laissant birth_date, postal_code et diagnosis change l'étiquette, pas le contenu.

Minimisation et cycle de vie

La minimisation consiste à collecter et conserver seulement ce qui est adéquat, pertinent et nécessaire. Elle porte sur les colonnes, les lignes, la granularité et la durée : une année de naissance au lieu d'une date, un département au lieu d'un code postal, une classe au lieu d'une valeur continue. Ces transformations réduisent l'utilité analytique, ce qu'il faut assumer explicitement.

Le cycle de vie comprend collecte, stockage, analyse, partage et suppression. Chaque étape a un responsable, une finalité et une trace. À la collecte, on vérifie la base légale et l'information. Au stockage, on sépare les identifiants des données de travail. À l'analyse, on applique le moindre privilège et on journalise les exports. Au partage, on vérifie licence, contrat et agrégation. À la suppression, on couvre aussi les sauvegardes. La durée de conservation se fixe avant le projet, avec une date et un responsable, plutôt qu'une phrase vague.

Licences des données et du code

La disponibilité en ligne n'implique pas la liberté d'usage. Un jeu peut être consultable gratuitement mais soumis à une licence restrictive, à un contrat d'accès ou à des droits de tiers. Une licence de code, comme MIT, régit le logiciel et non les données qu'il produit. Il faut lire la licence du jeu, celle du logiciel et les conditions du dépôt.

Licence	Usage commercial	Redistribution	Obligations principales
CC0	Oui	Oui	Aucune condition, renonciation autant que possible
CC BY	Oui	Oui	Attribution de l'auteur
CC BY-SA	Oui	Oui	Attribution et partage des adaptations sous la même licence
CC BY-NC	Non	Oui	Attribution et usage non commercial
MIT	Oui	Oui	Conserver la notice de licence et l'attribution
Accès restreint	Non	Non	Autorisation écrite, contrat d'accès, pas de réidentification

Les bases publiques diffèrent. NCBI ne pose pas lui-même de restrictions sur ses bases moléculaires, mais des déposants ou des pays peuvent revendiquer des droits et certaines données humaines sont à accès contrôlé. UniProt diffuse ses parties protégeables sous CC BY 4.0. Les fichiers de données de la Protein Data Bank (PDB) sont sous CC0 1.0 selon le wwPDB, les publications et ressources externes ayant leurs propres conditions. Vérifier la licence au niveau du fichier.

Les données humaines à accès contrôlé, comme celles de dbGaP (Database of Genotypes and Phenotypes) ou de l'EGA (European Genome-phenome Archive), ne sont pas librement rediffusables : comité d'accès, contrat d'utilisation et non-réidentification. Une licence CC BY ne s'applique pas par-dessus ce contrat.

Stockage, accès et durée de conservation

Le chiffrement au repos protège les disques et les sauvegardes ; le chiffrement en transit protège le réseau. Les clés sont séparées des données, stockées dans un gestionnaire de secrets et renouvelées selon une procédure documentée. Le contrôle d'accès applique le moindre privilège, avec authentification multifacteur, journaux d'accès et revue régulière des permissions.

Avec PostgreSQL, et notamment Supabase 2.x, une clé publique limitée par les politiques de sécurité au niveau des lignes (row level security, RLS) coexiste avec une clé de service qui contourne ces politiques. La clé de service reste côté serveur, jamais dans une application mobile ni un notebook partagé. Les buckets sont privés, les URL publiques désactivées et les exports journalisés. Les politiques RLS se testent avec un compte non privilégié : une politique écrite mais non appliquée donne une fausse impression de sécurité.

Une donnée supprimée ne peut pas fuir. La durée de conservation se définit par catégorie, avec rappels automatiques, sauvegardes couvertes et procédure testée. Les identifiants n'apparaissent ni dans les noms de fichiers, ni dans les commits, tickets, journaux ou captures d'écran. On versionne le script, le schéma et une empreinte, pas les données individuelles.

Intelligence artificielle et confidentialité

Un LLM transforme un fichier en texte envoyé à un tiers. Selon le contrat, le fournisseur peut conserver le prompt, l'utiliser pour améliorer le service, le transférer à un sous-traitant ou l'héberger dans un autre pays. Même un pseudonyme peut être réidentifié par recoupement, surtout dans une petite cohorte ou avec un âge, une maladie rare et une date. Un agrégat de taille 1 ou 2 peut désigner une personne.

La règle pratique est de ne pas envoyer de données identifiantes à un LLM. Si l'analyse est nécessaire, on retire les identifiants, on généralise les quasi-identifiants, on vérifie que le contrat interdit l'entraînement, on limite la conservation et on utilise un environnement approuvé. Pour les données sensibles, un modèle local ou un jeu synthétique est préférable.

RGPD et autres cadres

Le RGPD repose sur la licéité, la loyauté, la transparence, la limitation des finalités, la minimisation, l'exactitude, la limitation de conservation, l'intégrité et la responsabilité. Les données de santé et génétiques sont des catégories particulières, soumises à des conditions supplémentaires. Les personnes disposent de droits d'accès, de rectification, d'effacement, de limitation et d'opposition.

D'autres cadres coexistent : le HIPAA (Health Insurance Portability and Accountability Act) aux États-Unis pour certaines données de santé, la Common Rule pour la recherche fédérale, la LGPD au Brésil, la PIPL en Chine. Les définitions, bases légales, règles de transfert et obligations de notification diffèrent. Un projet international cartographie donc les juridictions, les hébergements et les destinataires, puis consulte le DPO, le comité d'éthique et l'équipe juridique. Cette section ne donne pas de conseil juridique. [À VÉRIFIER]

Au Bénin, la protection des données personnelles relève du cadre national, notamment du Code du numérique et de l'autorité de protection des données personnelles. Les modalités précises applicables à un projet de recherche (base légale, formalités, transferts, conservation) doivent être confirmées avec le responsable juridique et l'autorité compétente avant toute collecte. [À VÉRIFIER]

Exemple travaillé à la main

Six patients synthétiques partagent âge, sexe, code postal et diagnostic. Si trois d'entre eux ont la même combinaison, leur classe a une taille de 3, donc $k = 3$ pour ce groupe. Si un quatrième est seul, la plus petite classe vaut 1 et le jeu n'est pas 3-anonyme, même si les autres groupes sont grands : on rapporte le minimum, pas la moyenne.

Pour 16 caractères hexadécimaux, $b = 64$ bits. Avec un million d'enregistrements, la borne de collision vaut environ $1{,}4 \times 10^{-8}$ . Le calcul est en $O(N)$ en temps et en mémoire, et la classification des colonnes en $O(c)$ pour $c$ colonnes. Ces coûts pèsent peu devant le risque de réidentification.

Implémentation

Le code ci-dessous rassemble les trois briques : pseudonymisation par HMAC tronqué, classification de colonnes et lecture d'une licence. Il n'utilise que la bibliothèque standard de Python 3.11 et ne fait aucun accès réseau. La sortie a été vérifiée le 2026-11-01.

Pseudonymiser, classer, vérifier une licence

from hashlib import sha256
from hmac import new as hmac_new
from re import sub

DIRECT = {"patient_id", "name", "email", "birth_date", "date_of_birth", "mrn", "phone", "address"}
QUASI = {"age", "sex", "postal_code", "city", "diagnosis", "visit_date", "birth_year"}
NON_ID = {"sequence", "gc_content", "gene_id", "expression", "chrom", "pos", "ref", "alt"}

def normalize(name):
  return sub(r"[^a-z0-9]+", "_", name.strip().lower()).strip("_")

def pseudonymize_ids(records, salt, key="patient_id", digest_chars=16):
  if not salt:
      raise ValueError("salt must be non-empty")
  key_bytes = salt.encode("utf-8")
  output = []
  for record in records:
      digest = hmac_new(key_bytes, str(record[key]).encode("utf-8"), sha256).hexdigest()
      new_record = dict(record)
      new_record[key] = "psn_" + digest[:digest_chars]
      output.append(new_record)
  return output

def detect_direct_identifiers(columns):
  classes = {}
  for column in columns:
      normalized = normalize(column)
      if normalized in DIRECT:
          classes[column] = "direct"
      elif normalized in QUASI:
          classes[column] = "quasi"
      elif normalized in NON_ID:
          classes[column] = "non_identifying"
      else:
          classes[column] = "unknown"
  return classes

def license_allows(license_name, use):
  rules = {
      "CC0": {"commercial": True, "redistribute": True, "research": True},
      "CC BY": {"commercial": True, "redistribute": True, "research": True},
      "CC BY-NC": {"commercial": False, "redistribute": True, "research": True},
      "MIT": {"commercial": True, "redistribute": True, "research": True},
  }
  key = sub(r"[^a-z0-9]+", " ", license_name.strip().lower()).strip()
  aliases = {"cc0": "CC0", "cc by": "CC BY", "cc by nc": "CC BY-NC", "mit": "MIT"}
  if key not in aliases or use not in rules[aliases[key]]:
      raise ValueError("unknown license or use")
  return rules[aliases[key]][use]

records = [
  {"patient_id": "PAT-001", "age": 34, "postal_code": "75011"},
  {"patient_id": "PAT-002", "age": 51, "postal_code": "13005"},
]
for row in pseudonymize_ids(records, "demo-2026"):
  print(row)
print(detect_direct_identifiers(["patient_id", "age", "postal_code", "gc_content"]))
print(license_allows("CC BY-NC", "commercial"), license_allows("CC BY-NC", "research"))

SortieCtrl+Entrée pour exécuter · 10 s max

Aucune sortie. Exécutez le code pour voir le résultat.

Le code s'exécute dans votre navigateur (Web Worker isolé). Il n'a pas accès au serveur ; l'accès réseau est désactivé pendant l'exécution. Le premier clic sur « Exécuter » télécharge Pyodide depuis jsDelivr (plusieurs mégaoctets, version 0.26.4 épinglée) ; rien n'est chargé avant ce clic.

La sortie attendue est :

{'patient_id': 'psn_134b451a8fd45491', 'age': 34, 'postal_code': '75011'}
{'patient_id': 'psn_bcf4345019b4a76c', 'age': 51, 'postal_code': '13005'}
{'patient_id': 'direct', 'age': 'quasi', 'postal_code': 'quasi', 'gc_content': 'non_identifying'}
False True

Trois points sont critiques. La clé HMAC doit être secrète et stable : si elle change, les jointures entre exports échouent ; si elle fuit, un attaquant teste des identifiants courants. La troncature se choisit selon le nombre d'enregistrements. Une colonne inconnue reste unknown et déclenche une revue humaine : une liste blanche qui classe tout le reste comme « non identifiant » est un piège. En production, la clé vit dans un gestionnaire de secrets, la table de correspondance est séparée et les notebooks sont nettoyés avant partage.

Étude de cas

Jeu entièrement synthétique de six patients : noms, courriels, dates et diagnostics inventés, courriels en .invalid. Le fichier brut contient patient_id, name, email, birth_date, postal_code, sex, diagnosis, visit_date et consent. La question : que reste-t-il après pseudonymisation, et est-ce anonyme ? Extrait du fichier brut :

Identifiant	Nom fictif	Courriel fictif	Naissance	Code postal	Sexe	Diagnostic	Visite
PAT-001	Patient Alpha	alpha@example.invalid	1980-03-14	75011	F	thyroid	2025-01-12
PAT-002	Patient Beta	beta@example.invalid	1981-07-02	75012	F	thyroid	2025-01-19
PAT-003	Patient Gamma	gamma@example.invalid	1975-11-23	13005	M	diabetes	2025-02-03

La transformation remplace patient_id par un HMAC tronqué (clé demo-2026), supprime name et email, et résume la naissance en année, le code postal en deux chiffres, la visite en mois et le diagnostic en catégorie. Voici les six enregistrements.

Pseudonyme	Année	Préfixe	Sexe	Groupe	Mois
psn_134b451a8fd45491	1980	75	F	endocrine	2025-01
psn_bcf4345019b4a76c	1981	75	F	endocrine	2025-01
psn_c81889b44faabed2	1975	13	M	metabolic	2025-02
psn_6653cc6fcee128a8	1975	13	M	metabolic	2025-03
psn_47a4ce692e85e403	1990	69	F	respiratory	2025-02
psn_b3c05942016bac69	1992	69	M	respiratory	2025-02

L'audit classe le brut en high : quatre identifiants directs, quatre quasi-identifiants, un transfert LLM et une licence CC BY. Après transformation : moderate, quasi-identifiants seulement. CC BY autorise le partage avec attribution, mais ne rend pas le jeu anonyme.

Le calcul de k-anonymité est moins rassurant. Les deux premiers forment un groupe de taille 2 ; les quatre autres sont seuls (mois, année, sexe). La plus petite classe vaut 1. Il faut supprimer ou regrouper les lignes uniques, ou documenter le risque résiduel.

La pseudonymisation a retiré les identifiants directs, pas le pouvoir identifiant des combinaisons. Limites : texte libre, métadonnées d'images, dates, diagnostics rares, génomes uniques et proches des apparentés. La clé de démonstration est publique ; en production, elle serait secrète.

On supprime les colonnes inutiles, généralise, vérifie k, limite l'accès, interdit le LLM non approuvé et documente le risque. Le partage passe par l'agrégation ou l'accès contrôlé ; la reproductibilité par le code, le schéma et les paramètres.

Erreurs fréquentes

Quiz

Exercices

Exercice guidé0.2-e1

Énoncé

Écrire pseudonymize_ids(records, salt, key="patient_id", digest_chars=16) qui remplace chaque identifiant par psn_ suivi des digest_chars premiers caractères hexadécimaux de HMAC-SHA256(salt, identifiant), sans modifier les enregistrements d'origine. Écrire aussi detect_direct_identifiers(columns) qui classe chaque nom de colonne en direct, quasi, non_identifying ou unknown, en normalisant la casse et les séparateurs. Un sel vide, un identifiant vide ou une clé absente lèvent une exception. Tous les exemples sont synthétiques.

Comment vérifier votre travail

Les tests se trouvent dans exercises/module-0/0.2-ethique-donnees/test_0_2.py. Depuis la racine du dépôt :

python -m pytest exercises/module-0/0.2-ethique-donnees -q

Corrigé verrouillé

Le corrigé est chargé uniquement après confirmation. Il n'est pas présent dans la page avant cette action.

Exercice approfondi0.2-e2

Énoncé

Implémenter license_allows(license_name, use) et license_obligations(license_name) avec une table couvrant CC0, CC BY, CC BY-SA, CC BY-NC, MIT, restricted et controlled. Les usages reconnus sont commercial, redistribute, modify et research. Normaliser la casse et les séparateurs, accepter quelques synonymes, et lever ValueError pour une licence ou un usage inconnu. La fonction échoue fermée : mieux vaut refuser et demander une vérification que d'autoriser par défaut. Expliquer en une phrase pourquoi controlled renvoie False même pour la recherche.

Comment vérifier votre travail

Les tests se trouvent dans exercises/module-0/0.2-ethique-donnees/test_0_2.py. Depuis la racine du dépôt :

python -m pytest exercises/module-0/0.2-ethique-donnees -q

Corrigé verrouillé

Le corrigé est chargé uniquement après confirmation. Il n'est pas présent dans la page avant cette action.

Mini-projet0.2-projet

Énoncé

Mini-projet : audit d'un jeu de métadonnées. Implémenter audit_dataset(metadata, license_name) qui reçoit un dictionnaire décrivant un jeu synthétique (human_data, records, columns, consent, retention_days, storage, transfers) et une licence. Le rapport contient risk_level (low, moderate, high), une liste triée de findings avec code, severity et message, des recommendations sans doublon et le classement des colonnes. Une seule alerte high classe le jeu en high. Une licence inconnue produit LICENSE_UNKNOWN et un risque high. Le code ne lit aucune valeur individuelle.

Comment vérifier votre travail

Les tests se trouvent dans exercises/module-0/0.2-ethique-donnees/projet/test_projet_0_2.py. Depuis la racine du dépôt :

python -m pytest exercises/module-0/0.2-ethique-donnees/projet -q

Corrigé verrouillé

Le corrigé est chargé uniquement après confirmation. Il n'est pas présent dans la page avant cette action.

Résumé

Une donnée pseudonymisée reste personnelle : la clé ou la table de correspondance permet la réidentification.
Supprimer un nom ne suffit pas ; les quasi-identifiants se combinent et la k-anonymité mesure une partie du risque.
Un HMAC avec une clé secrète produit un pseudonyme stable ; un hachage nu résiste mal aux identifiants structurés.
Le consentement doit être informé, spécifique et révocable ; le retrait s'applique aux traitements futurs.
La minimisation porte sur les colonnes, les lignes, la granularité et la durée de conservation.
Une licence publique n'est pas une absence de droits ; CC BY, CC BY-NC, MIT et accès contrôlé imposent des obligations différentes.
Ne pas envoyer de données identifiantes à un LLM ; documenter tout transfert et vérifier le contrat.
La conformité se démontre par des décisions traçables, pas par une case cochée.

Références

Règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril 2016 relatif à la protection des personnes physiques à l'égard du traitement des données à caractère personnel (RGPD). Journal officiel de l'Union européenne, L 119, 4 mai 2016. https://eur-lex.europa.eu/eli/reg/2016/679/oj
CNIL. Le règlement général sur la protection des données (RGPD). https://www.cnil.fr/fr/reglement-europeen-protection-donnees
Berman, H. M., Westbrook, J., Feng, Z., Gilliland, G., Bhat, T. N., Weissig, H., Shindyalov, I. N., & Bourne, P. E. (2000). The Protein Data Bank. Nucleic Acids Research, 28(1), 235–242.
NCBI. Website and Data Usage Policies and Disclaimers. https://www.ncbi.nlm.nih.gov/home/about/policies/
UniProt. License & disclaimer. https://www.uniprot.org/help/license
RCSB PDB. Policies: Usage Policies. https://www.rcsb.org/pages/policies
Creative Commons. About CC Licenses. https://creativecommons.org/share-your-work/cclicenses/
EGA. European Genome-phenome Archive. https://ega-archive.org/