Chapitre 5.2 — Données de santé & handicap

⏱️ TL;DR — La donnée de santé est entendue très largement : ce n’est pas seulement un diagnostic, c’est toute information qui révèle l’état de santé physique ou mental, présent, passé ou futur — y compris par déduction. En EdTech, la donnée de santé la plus fréquente n’est pas un dossier médical : ce sont les aménagements pour élèves et stagiaires en situation de handicap (PAP, PPS, PAI, tiers-temps, matériel adapté, secrétaire à l’examen). Ces informations relèvent de l’article 9 : protection renforcée, accès très restreint, base légale spéciale, chiffrement — et surtout, jamais dans un champ notes en clair accessible à toute l’équipe. C’est le point où le RGPD croise le cours accessibilité : rendre une formation accessible oblige à traiter des données de santé, donc à le faire proprement.

🎯 Objectifs

• Comprendre l’étendue très large de la notion de donnée de santé.
• Identifier les aménagements (PAP, PPS, PAI, tiers-temps) comme données de santé.
• Concevoir un stockage cloisonné et un accès restreint pour ces données.
• Relier la conformité RGPD à l’obligation d’accessibilité des formations.

Ce qui compte comme donnée de santé : très large

La donnée de santé ne se limite pas à un diagnostic posé par un médecin. Le RGPD vise toute donnée relative à la santé physique ou mentale d’une personne, y compris la prestation de soins, qui révèle des informations sur son état de santé. Concrètement, sont des données de santé :

• un diagnostic, un traitement, une pathologie, un handicap, un trouble (dys, TDAH, autisme…) ;
• une allergie, une intolérance, un régime médical, un PAI (projet d’accueil individualisé) ;
• un aménagement d’examen ou de scolarité (tiers-temps, secrétaire, matériel adapté) ;
• une absence pour raison médicale, un certificat, un arrêt ;
• une information déduite : « transport adapté », « suivi par l’infirmerie », « dispensé d’EPS ».

Le mot clé est révéler. Une donnée n’a pas besoin d’être médicale dans sa forme pour être une donnée de santé : il suffit qu’elle permette de déduire un état de santé. « Bénéficie d’un tiers-temps » ne dit pas quelle pathologie, mais dit qu’il y en a une — c’est déjà une donnée de santé.

⚠️ Piège — « Ce n’est pas un dossier médical, juste un champ pratique pour l’organisation. » C’est l’erreur classique. Un champ amenagement = "tiers-temps + ordinateur" n’est pas une commodité administrative neutre : il révèle un handicap, donc c’est une donnée de l’article 9. Le traiter comme un champ ordinaire (visible par tout le back-office, exporté dans un CSV, copié dans un e-mail) est un manquement — et un risque concret de discrimination si l’information circule.

Le cas EdTech central : les aménagements

C’est le cas d’école. Une plateforme scolaire ou de formation doit organiser des aménagements pour les personnes en situation de handicap. Ces aménagements portent des noms qui reviennent sans cesse :

Toutes ces informations sont, sans exception, des données de santé au sens de l’article 9. Elles doivent donc suivre le régime renforcé : une exception de l’art. 9.2 (le plus souvent le consentement explicite de la personne ou de son représentant légal, parfois une obligation légale liée à l’accessibilité), une base légale de l’art. 6, et des garanties techniques et organisationnelles fortes.

Comment on les stocke : cloisonner, restreindre, chiffrer

Le bon réflexe n’est pas juridique, il est architectural. Une donnée de santé ne vit pas dans la table généraliste consultée par tout le monde.

// ❌ Anti-pattern : la donnée de santé noyée dans la fiche, visible par tout le back-office.
type Eleve = {
  id: string
  nom: string
  classe: string
  notes: string   // "PPS, tiers-temps, dyslexie sévère, suivi orthophoniste" ← FUITE de santé en clair
}
 
// ✅ Cloisonnement : la donnée sensible isolée, typée, chiffrée, à accès restreint.
type Eleve = {
  id: string
  nom: string
  classe: string
}
 
type AmenagementScolaire = {
  eleveId: string
  type: "tiers_temps" | "secretaire" | "materiel_adapte" | "salle_particuliere"
  // Pas de diagnostic en clair : on stocke le BESOIN, pas la pathologie détaillée.
  chiffre: true            // colonne chiffrée au repos
  accesRole: "referent_handicap" | "responsable_examen" // liste blanche de rôles
  base: "consentement_explicite"
  finalite: "organiser_les_amenagements_d_examen"
}

Trois règles se lisent dans ce code. Un : on isole la donnée sensible dans sa propre table, pas dans un champ notes fourre-tout. Deux : on stocke le besoin (tiers-temps, matériel) plutôt que le diagnostic détaillé quand ce dernier n’est pas nécessaire à la finalité — c’est de la minimisation appliquée au sensible. Trois : l’accès est réservé, par rôle, aux seules personnes qui organisent l’aménagement (référent handicap, responsable d’examen), pas à toute l’équipe pédagogique ni au support technique.

💡 Réflexe — Pose-toi la question du cercle d’accès avant celle du stockage : « Qui, très précisément, a besoin de voir cette information pour faire son travail ? » Pour un tiers-temps, c’est celui qui édite les convocations d’examen — pas le prof de sport, pas le community manager, pas le stagiaire admin. Tu conçois alors un contrôle d’accès par rôle restrictif par défaut, et tu journalises les consultations. Le chiffrement au repos et la pseudonymisation viennent en complément (Partie 9), mais le premier rempart, c’est qui peut regarder.

🧭 Sur FormaCampus — Côté LMS scolaire, un enseignant a besoin de savoir qu’un élève dispose d’un tiers-temps pour organiser un contrôle, mais pas de connaître le détail médical qui le justifie. Côté organisme de formation, un stagiaire en situation de handicap peut demander une adaptation des supports : c’est une donnée de santé, traitée sur la base de son consentement explicite et conservée le temps de la formation. FormaCampus stocke donc ces aménagements dans un module dédié, chiffré, avec un accès limité au référent handicap et au responsable de session, une trace des consultations, et une purge automatique après la fin du parcours. Rien de tout cela n’apparaît dans les exports statistiques ni dans les tableaux de bord des formateurs.

🔒 Côté personne concernée — Un parent qui déclare le handicap de son enfant, ou un stagiaire adulte qui demande un aménagement, fait un acte de confiance difficile. Il redoute deux choses : que l’information circule au-delà des personnes qui en ont besoin (et le stigmatise), et qu’on la lui redemande sans cesse. Il attend qu’elle serve uniquement à obtenir l’adaptation, qu’elle reste confidentielle, et qu’elle disparaisse quand elle n’est plus utile. Un aménagement bien géré est invisible pour les autres et libérateur pour la personne.

📚 Le texte — La donnée de santé fait partie des catégories particulières de l’article 9.1 ; elle bénéficie d’exceptions à l’article 9.2 (dont le consentement explicite et, dans le domaine médical, le traitement par un professionnel soumis au secret). Le traitement de données sensibles à grande échelle est aussi l’un des critères qui rendent obligatoires un DPO (art. 37) et souvent une AIPD (art. 35).

Le pont avec l’accessibilité

Rendre une formation accessible — objectif légitime, souvent une obligation — suppose presque toujours de traiter des données de santé : pour adapter un support, accorder un temps majoré ou fournir un outil, il faut savoir qu’un besoin existe. Les deux exigences ne s’opposent pas, elles se complètent : l’accessibilité impose l’aménagement, le RGPD impose de le traiter proprement (minimisation, accès restreint, sécurité). Le mauvais réflexe serait de renoncer à l’accessibilité « à cause du RGPD » ; le bon réflexe est de faire les deux, en concevant dès le départ un traitement des aménagements qui soit à la fois efficace et protecteur. Le cours Accessibilité détaille le versant technique et normatif de ces adaptations ; ce chapitre en couvre le versant données.

✏️ Exercices

Exercice 1 — Qualifie la donnée. Pour chaque élément, indique si c’est une donnée de santé (art. 9) : (a) « allergie à l’arachide, PAI en place », (b) « absent le 3 mars », (c) « dispensé d’EPS sur l’année », (d) « aime le foot ».

Exercice 2 — Répare l’architecture. Une plateforme stocke, dans la table eleves, un champ texte remarques que les 40 utilisateurs du back-office peuvent lire, et où figurent des mentions comme « TDAH, sous traitement, tiers-temps ». Qu’est-ce qui ne va pas, et comment corriger ?

Exercice 3 — Minimiser. Le service examens a besoin d’organiser les salles. Un dev propose d’afficher, en face de chaque candidat, le diagnostic complet justifiant l’aménagement. Est-ce nécessaire ?

🧠 Quiz de révision

Chapitre suivant : Biométrie & génétique — pourquoi identifier une personne par son visage ou son empreinte est un traitement à très haut risque, la distinction authentification / identification, et le cas de la reconnaissance faciale à l’entrée des lycées.