Je n’ai pas commencé par une stratégie d’IA pour la santé.
J’ai commencé par un malaise.
Les gens vont coller des notes cliniques, des résultats de laboratoire, des comptes rendus de médecin, des récits de patients, des exports de formulaires, des courriers d’assurance et des captures d’écran dans des outils, parce que ces outils sont utiles.
Certains de ces outils utilisent l’IA.
D’autres sont du SaaS ordinaire.
D’autres encore sont des tableaux de bord, des systèmes de tickets, des produits d’analyse, des applications de transcription, des applications de notes, des CRM, des formulaires d’admission ou des convertisseurs de fichiers.
Cette partie est déjà tranchée.
La question est ce qui se passe avant l’envoi.
Qu’est-ce qui est retiré ?
Qu’est-ce qui reste en local ?
Qu’est-ce qui arrive au service ?
Qui le stocke ?
Qui peut le revendre ?
Qui peut le croiser plus tard avec autre chose ?
Qui peut prouver ce qui s’est passé ?
La première version était modeste
Le dépôt public était petit.
Un outil local. Une note clinique. Une question de base : puis-je retirer les informations de santé sensibles avant que le texte ne quitte la machine ?
Ce n’était pas une entreprise.
Ce n’était pas un produit médical.
Ce n’était pas une garantie de conformité.
C’était le refus d’accepter le comportement par défaut : copier le texte brut, le coller dans un système cloud et espérer que la politique de confidentialité suffise.
Je n’aime pas le réduire à une coque technique autour d’un autre outil.
Techniquement, il utilisait NLM Scrubber.
Mais l’enjeu n’était pas la plomberie logicielle.
L’enjeu, c’était la question derrière.
Une personne ordinaire pourrait-elle nettoyer une note de santé en local avant d’en envoyer la partie utile ailleurs ?
Le système pourrait-il partir de moins de données, et non de plus ?
L’idée plus large derrière le dépôt
Le dépôt était le premier artefact public d’une idée plus large.
Les données de santé ne se présentent pas partout de la même façon.
Les formulaires diffèrent.
Les identifiants diffèrent.
Les dates diffèrent.
Les langues diffèrent.
Le contexte juridique diffère.
Je suis né en Belgique. J’ai des racines marocaines. Je vis en Espagne depuis des années. Je communique beaucoup avec des personnes et des projets liés aux États-Unis.
La question ne me semblait donc pas abstraite.
La Belgique, le Maroc, l’Espagne, l’Union européenne, les États-Unis.
Des formulaires différents.
Des hypothèses différentes.
Un langage différent sur la vie privée.
Une pression juridique différente.
La version impossible serait un anonymiseur mondial pour 200 pays.
Ce n’est pas ce que j’ai construit.
La version utile était plus modeste : commencer par les contextes les plus pertinents, apprendre des outils existants, adapter la réflexion à de vrais identifiants et à de vrais flux de travail, et garder le traitement en local quand c’est possible.
Voilà l’histoire derrière le prototype.
Pas un moteur de conformité mondial abouti.
Un premier artefact pour une question plus difficile.
Pourquoi ce n’est pas de la paranoïa
Le problème n’est pas que chaque entreprise vende en secret votre note d’hôpital.
C’est trop facile à dire et trop faible pour être défendu.
Le problème, c’est que les données circulent.
Elles sont journalisées.
Elles sont conservées.
Elles sont copiées dans des sauvegardes.
Elles servent à améliorer le produit.
Elles sont partagées avec des sous-traitants.
Elles sont combinées avec des données de navigation, de localisation, d’achat, d’appareil et de compte.
Elles sont parfois vendues.
Elles font parfois l’objet d’une fuite.
Elles sont parfois déduites de données qui ne semblaient pas médicales au départ.
La FTC a averti que les informations de santé ne se limitent pas aux traitements et aux diagnostics : les données de localisation, de navigation et d’achat peuvent aussi révéler des informations de santé.
C’est important, car une personne n’est pas exposée seulement par ce qu’elle a saisi dans un formulaire médical.
Une personne est exposée par les recoupements.
Un achat en pharmacie.
Une visite en clinique.
Une recherche liée à une grossesse.
Une allergie.
Un médicament.
Une absence au travail.
Un ticket de support.
Une photo.
Une vidéo.
Un événement d’agenda.
Une donnée isolée peut sembler anodine.
L’ensemble, lui, ne l’est pas.
Ce qui peut être retourné contre vous
Les données de santé peuvent devenir un moyen de pression.
Pas toujours.
Pas automatiquement.
Mais assez souvent pour que la réserve soit le comportement par défaut.
Une allergie n’est pas seulement un fait médical.
Entre de mauvaises mains, c’est une vulnérabilité.
Un médicament peut révéler une pathologie.
Une pathologie peut influencer la façon dont quelqu’un juge votre fiabilité, votre niveau de risque, votre capacité de travail, votre profil d’assuré ou votre crédibilité.
Une trace de localisation peut révéler quelle clinique quelqu’un a visitée.
Un achat lié à une grossesse peut révéler quelque chose avant que la personne n’en ait parlé à quiconque.
Une note de santé mentale peut devenir un point de stigmatisation.
Une pathologie génétique ou chronique peut devenir un signal de profilage.
Un jeu de données qui arrive sur un marché criminel peut servir à l’usurpation d’identité, à l’hameçonnage, à la fraude au crédit, à la prise de contrôle de comptes ou à l’ingénierie sociale.
Ce n’est pas un scénario de film.
C’est la conséquence pratique d’avoir donné trop de contexte parce qu’un service était pratique.
Le service peut être utile.
La commodité peut être réelle.
Le rapport peut être bon.
Le flux de travail peut faire gagner du temps.
Cela ne veut toujours pas dire que les données brutes devaient partir.
Les angles assurance, travail et secteur public
Le risque à venir n’est pas seulement la publicité.
C’est le scoring.
Le scoring d’assurance.
Le filtrage à l’embauche.
L’éligibilité aux prestations du secteur public.
Les contrôles antifraude.
Les vérifications d’antécédents.
Les décisions de crédit et de prêt.
Les questions de frontière et d’immigration.
Les preuves en cas de litige.
La crédibilité juridique.
Quand assez de données sont disponibles, des systèmes peuvent confronter l’histoire que vous racontez à celle que racontent vos données.
Cela peut être utile quand cela détecte une fraude.
Cela peut aussi être injuste quand les données sont incomplètes, anciennes, déduites, biaisées, achetées à un courtier ou sorties de leur contexte.
La personne jugée ne verra peut-être jamais le profil complet.
Elle ne saura peut-être jamais quelle donnée a compté.
Elle ne saura peut-être jamais quelle entreprise la détenait.
C’est pourquoi la minimisation des données de santé n’est pas une simple préférence technique.
C’est une question de pouvoir.
Ce que le prototype a révélé
L’anonymisation ne consiste pas seulement à retirer un nom.
Une note clinique peut identifier une personne par des dates, des événements rares, des lieux, des chronologies, des détails familiaux, des numéros de téléphone, des identifiants ou des combinaisons de détails qui semblent anodins pris isolément.
Retirez le nom en laissant la date d’admission, la date de sortie, l’hôpital et le numéro de téléphone, et la note peut encore renvoyer à une personne.
Retirez trop, et la note peut cesser d’être utile.
Modifiez mal une date, et la chronologie clinique peut devenir trompeuse.
C’est là que le travail devient sérieux.
Pas dramatique.
Sérieux.
Les cas limites ennuyeux sont le système de confidentialité.
Pourquoi les dates comptent
Les dates paraissent petites jusqu’à ce qu’on les traite comme des preuves.
Une date de naissance peut identifier quelqu’un.
Une date d’opération peut identifier quelqu’un.
Un intervalle entre l’admission et la sortie peut compter sur le plan clinique.
Si un système décale les dates de 0 jour, la confidentialité n’a pas progressé.
S’il transforme `03/15/22` en un autre format sans prévenir, la forme du texte a changé.
S’il conserve l’année à un endroit et décale le mois à un autre, un intervalle peut devenir absurde au passage d’une année à l’autre.
Ce ne sont pas des problèmes glamour.
Ce sont précisément les problèmes qui décident si l’on peut faire confiance à une couche de confidentialité.
La découverte d’OpenMed
Après avoir construit le prototype, j’ai découvert OpenMed.
OpenMed est un projet open source de santé plus vaste, qui travaille sur le traitement des textes cliniques local first, la détection des données personnelles identifiantes (PII), la désidentification et l’extraction d’entités médicales.
Il travaillait sur le même problème de confidentialité, à une échelle plus profonde.
Le geste immature aurait été de prétendre que mon petit prototype était la réponse complète.
Le geste mûr a été de contribuer au projet qui allait déjà plus loin.
C’est ce que j’ai fait.
Je n’ai pas construit OpenMed.
Je ne suis pas propriétaire d’OpenMed.
J’ai apporté une petite contribution à la confidentialité et à la fiabilité autour de la désidentification.
D’autres contributeurs ont fait davantage.
C’est important.
Ce n’est pas une histoire pour me vanter.
C’est une histoire de collaboration.
J’ai d’abord construit un petit prototype autonome. Puis j’ai trouvé un projet open source plus vaste qui travaillait sur le même problème et j’ai commencé à contribuer là où le travail pouvait compter davantage.
Pourquoi je ne liste pas ici chaque contribution
La trace publique existe.
GitHub peut la montrer.
Mais la leçon n’est pas « regardez mes pull requests ».
La leçon, c’est que le travail sur la confidentialité en santé devient réel dans des détails ennuyeux : les dates, les formats, la reproductibilité, les tests, les valeurs par défaut et la relecture.
C’est cette partie qui m’importe.
Pas posséder le plus gros projet.
Pas prétendre que le premier prototype a tout résolu.
Rejoindre l’écosystème plus solide quand je l’ai trouvé.
La réglementation va vers la même question
L’orientation juridique n’est pas identique d’une région à l’autre, mais la pression est facile à voir.
En Europe, l’article 9 du RGPD traite les données concernant la santé comme des catégories particulières de données.
Le règlement européen sur l’IA (AI Act) repose sur un cadre fondé sur les risques, avec des catégories à haut risque où les systèmes peuvent affecter la santé, la sécurité ou les droits fondamentaux.
Les États-Unis n’ont pas d’équivalent fédéral unique du RGPD pour toutes les données proches de la santé.
Cela fait partie du problème.
Certaines protections existent dans des contextes précis.
Une partie de la pression vient des lois des États, de l’application des règles et des règles sectorielles.
Colorado SB26-189 encadre les technologies de prise de décision automatisée autour des décisions à conséquences importantes, y compris les services de santé, avec des obligations pour les développeurs et les déployeurs à partir du 1er janvier 2027.
Le système DROP de Californie montre la direction prise pour les courtiers en données : les résidents peuvent soumettre des demandes de suppression et les courtiers en données doivent commencer à les traiter à partir du 1er août 2026.
L’outil de la FTC sur les applications mobiles de santé et les recommandations de la FTC sur les informations de santé renvoient tous deux à la même question pratique : quelles informations de santé sont collectées, comment elles sont utilisées, qui les reçoit, combien de temps elles sont conservées et si le consentement était réellement éclairé.
Rien de tout cela ne signifie qu’une démo est conforme parce qu’elle retire quelques identifiants.
C’est exactement le piège.
La conformité n’est pas un autocollant que l’on colle sur un prototype.
La couche utile se situe avant le théâtre de la conformité : collecter moins, retirer plus, garder le traitement en local quand c’est possible, relire les résultats à la main et conserver la preuve de ce qui s’est passé.
La couche manquante
Il manque une couche dans la plupart des partages de données.
La traçabilité.
Pas seulement une politique de confidentialité.
Pas seulement une case à cocher.
Un moyen de savoir où les données sensibles ont circulé, qui y a touché, ce qui a été retiré, ce qui a été conservé et quels usages en aval étaient autorisés.
Appelez cela un registre, un reçu, une piste d’audit, un contrat ou quelque chose de plus malin.
Le nom compte moins que la fonction.
Aujourd’hui, la plupart des gens n’ont pas cela.
Ils envoient.
Ils font confiance.
Ils oublient.
Les données, elles, n’oublient pas.
C’est un article à part.
Mais c’est la raison pour laquelle ce petit prototype comptait pour moi.
Ce que les équipes devraient faire ensuite
Les prochaines étapes pratiques ne sont pas dramatiques.
Elles sont ennuyeuses.
C’est pourquoi elles comptent.
Ne collez pas de texte clinique brut dans des outils par défaut.
Ne téléversez pas de formulaires de santé, de résultats de laboratoire ou de captures d’écran dans des outils SaaS tant que le flux des données n’est pas compris.
Retirez d’abord les identifiants.
Traitez les dates comme sensibles.
Traitez les allergies, les médicaments, l’état de grossesse, les notes de santé mentale, les données génétiques et les maladies rares comme un contexte à haut risque.
Gardez le traitement en local quand c’est possible.
Utilisez des exemples synthétiques pour les tests.
Relisez les résultats à la main.
Conservez des journaux de ce qui a été retiré et de ce qui a été envoyé.
Demandez où les données sont stockées.
Demandez qui sont les sous-traitants.
Demandez si les données peuvent être supprimées.
Demandez si elles sont utilisées pour l’entraînement, l’analyse, le profilage ou l’amélioration du produit.
Ne prétendez pas être conforme sans examen juridique et vie privée.
Si le système ne sait pas répondre à ces questions, le problème n’est pas le prompt.
Le problème, c’est le flux de travail.
Ce que j’ai appris
Ce que j’ai appris est simple : la confidentialité en santé n’est pas un bouton sur lequel on appuie à la fin. C’est une frontière que l’on conçoit avant que des données sensibles n’atteignent un système qui n’en a pas besoin.
Les prochaines étapes pratiques sont ennuyeuses, et c’est pourquoi elles comptent.
Ne collez pas de texte clinique brut par défaut.
Retirez d’abord les identifiants.
Traitez les dates comme sensibles.
Utilisez des exemples synthétiques pour les tests.
Gardez le traitement en local quand c’est possible.
Relisez les résultats à la main.
Journalisez ce qui a été retiré et ce qui a été envoyé.
Ne prétendez pas être conforme parce qu’une démo a fonctionné une fois.
Une meilleure technologie de santé ne commence pas par un meilleur prompt.
Elle commence par moins de données inutiles qui franchissent la frontière.