Concevoir un produit healthtech en 2026 : HIPAA, FHIR et le calcul des rançongiciels qu'on ne peut pas esquiver

Un chiffre fixe l'enjeu avant même que vous n'écriviez une ligne de code : la violation de données de santé moyenne coûte désormais environ 10,22 millions de dollars, et la santé détient le titre des violations les plus coûteuses, tous secteurs confondus, depuis quatorze années consécutives. Ce n'est pas un risque marginal que l'on corrige après le lancement. Pour quiconque construit un logiciel qui touche aux données patients, c'est la chose autour de laquelle tout le produit finit par être bâti.

Un outil d'agenda et un outil de prise de rendez-vous patients semblent presque identiques dans une démo. Même calendrier, même flux de réservation, même e-mail de confirmation. Toute la différence se joue en dessous : qui peut consulter un dossier, où il est stocké, à qui vous vous êtes légalement engagé à le protéger, et ce qui se passe le jour où quelqu'un tente de le voler. Rien de tout cela n'apparaît sur une capture d'écran, et tout cela décide si le produit est livrable ou non.

Trois éléments déterminent ce que « bon » veut dire en healthtech aujourd'hui. La Security Rule de HIPAA est réécrite pour la première fois en plus de vingt ans. Les échéances fédérales d'interopérabilité forcent les données de santé vers une norme d'API commune. Et les rançongiciels sont devenus assez graves pour que les régulateurs cessent de voir une violation comme une malchance et commencent à la voir comme une preuve. Si vous cadrez un projet, traitez ces trois éléments comme des contraintes de conception, pas comme des notes de bas de page juridiques à gérer plus tard. La version anticipée coûte bien moins cher que le rattrapage.

Le rançongiciel a cessé d'être le problème des autres

L'ampleur est difficile à balayer d'un revers de main. Depuis 2009, les États-Unis ont recensé plus de 7 400 violations de données de santé, touchant au-delà de 935 millions de dossiers — soit plusieurs fois la population du pays. Le rançongiciel en représente une part croissante : il est à l'origine d'environ 28 pour cent des grandes violations de santé, et cette part ne cesse de grandir. Pour une petite entreprise qui détient des données patients, une attaque réussie n'est pas un incident informatique. C'est potentiellement la fin de l'entreprise.

Les fondateurs ont tendance à sous-estimer ce qui suit. Quand l'Office for Civil Rights (le bureau des droits civiques de l'OCR) ouvre une enquête après une violation, la première chose qu'il demande n'est généralement pas une chronologie forensique de l'attaque. C'est votre analyse de risques — le document qui montre que vous aviez identifié où vivaient les données patients et ce qui pouvait mal tourner avec elles. Une analyse absente ou périmée est la violation sur laquelle reposent réellement la plupart des règlements. L'OCR en résout entre quinze et une vingtaine par an, fréquemment liées à un incident de rançongiciel, à une analyse de risques manquante, ou à une demande de dossiers qu'on a laissée traîner. Le règlement moyen en 2025 s'élevait à environ 1,2 million de dollars.

Une violation vous facture donc par couches : la récupération elle-même, le règlement réglementaire par-dessus, et la confiance des clients qui ne revient à aucun prix. Et « on n'a pas eu de chance, on s'est fait pirater » n'est plus vraiment une défense. Ce qu'un enquêteur veut savoir, c'est si vous aviez fait le travail de base pour la voir venir.

HIPAA est en cours de réécriture, et « optionnel » est en voie de disparition

Pendant la plus grande partie de son existence, la HIPAA Security Rule a réparti ses garde-fous en deux catégories : « requis » et « adressables ». En pratique, beaucoup d'équipes ont lu « adressable » comme « optionnel » et ont écarté des éléments comme le chiffrement avec une justification d'une ligne. La réécriture qui chemine au sein du HHS — la première refonte majeure de la règle en plus de deux décennies — ferme cette brèche. La proposition pousse vers le caractère franchement obligatoire des garde-fous autrefois négociables, dont le chiffrement des données au repos et en transit, l'authentification multifacteur, et un véritable inventaire des systèmes qui détiennent des données patients.

Si vous construisez maintenant, le mouvement est évident : construisez comme si ces éléments étaient déjà requis, car les règles ne vont que dans une seule direction. Aucun d'eux n'est exotique. Ils sont faciles à intégrer dans la conception tant que le système est jeune, et pénibles à injecter dans un système en production où les données patients circulent déjà.

Il est utile d'être concret sur ce à quoi « conforme HIPAA » renvoie réellement, car l'expression est brandie comme un badge qui s'achète. Il n'existe aucun certificat. Ce qui existe : un ensemble de garde-fous administratifs, physiques et techniques que vous pouvez prouver avoir mis en place, une analyse de risques que vous maintenez à jour, et un business associate agreement signé avec chaque service externe qui manipule les données à votre place. Ce dernier point fait trébucher plus d'équipes débutantes que tout autre — l'outil d'analytics, le fournisseur de messagerie, le suivi d'erreurs, chacun est un prestataire qui touche aux données patients, et chacun a besoin d'un BAA, sans quoi il ne devrait pas figurer dans la stack.

Vos données doivent parler FHIR

La deuxième force qui remodèle la healthtech est l'interopérabilité, et elle avance selon un calendrier. La règle Interoperability and Prior Authorization de CMS impose aux payeurs concernés — Medicare Advantage, Medicaid, CHIP, et les plans qui s'y connectent — de mettre en place des API basées sur FHIR, les premières dispositions arrivant en janvier 2026 et les exigences d'API de base étant dues avant janvier 2027. En avril 2026, CMS a proposé d'étendre la même approche à l'autorisation préalable des médicaments. Les échéances continuent d'arriver, et la norme qui les sous-tend toutes, c'est FHIR.

Vous n'êtes peut-être pas un payeur, donc la lettre de la règle ne vous lie peut-être pas. Sa gravité, elle, vous lie quand même. Une fois que les grands systèmes auxquels votre produit doit se connecter exposent et consomment tous du FHIR, un modèle de données propriétaire devient un problème de traduction que vous vous êtes engagé à résoudre indéfiniment. Les équipes qui ont conçu leur schéma autour des ressources FHIR dès le départ s'intègrent en quelques jours. Celles qui ne l'ont pas fait le découvrent généralement la semaine où un partenaire hospitalier leur demande comment elles échangent des données.

C'est l'endroit le moins cher pour être discipliné tôt. Modéliser un patient, un rendez-vous ou une observation de la façon dont FHIR le définit déjà ne vous coûte presque rien au départ et vous épargne une migration plus tard. Inventer votre propre version paraît plus rapide le premier jour et vous le facture le cinq-centième.

Ce que cela implique pour votre façon de construire

Le fil qui relie tout cela : en healthtech, la conformité vit dans l'architecture, et l'ordre dans lequel vous prenez ces décisions détermine si elles sont bon marché ou ruineuses. Quelques points méritent d'être bien faits avant que le premier vrai dossier patient n'existe :

• Ne bricolez pas votre propre infrastructure conforme. Les grands clouds proposent des services éligibles HIPAA et signeront un BAA. Construire une infrastructure sécurisée à partir de zéro, c'est une façon de passer un an à réinventer ce que vous pouvez louer.
• Concevez l'accès et la journalisation d'audit dès le départ. Qui peut lire quel dossier, et une trace de qui l'a réellement fait, c'est trivial à ajouter tôt et une réécriture à ajouter tard.
• Vérifiez le BAA de chaque prestataire avant de l'intégrer. Si un service refuse d'en signer un, il n'a pas le droit de toucher aux données patients, aussi pratique soit-il.
• Traitez l'analyse de risques comme un document vivant. C'est la première chose qu'un régulateur réclame, elle ne devrait donc pas être quelque chose que vous rédigez la semaine avant qu'une violation ne force la question.

Les appareils connectés ajoutent leur propre exposition. Le marché du matériel médical connecté à Internet valait déjà environ 47 milliards de dollars en 2023, et chaque capteur, objet porté ou moniteur qui diffuse des données dans votre produit élargit la surface qu'on peut attaquer. Si le matériel fait partie du plan, le modèle de sécurité doit s'étendre jusqu'à la périphérie, et non s'arrêter au serveur.

Je ne prétendrai pas que tout cela soit gratuit. Le faire correctement ajoute du temps et du coût à un projet, et un fondateur qui court pour valider une idée ressent chacune de ces semaines. Mais le coût est en grande partie connaissable, et un coût connaissable est un coût autour duquel on peut planifier. Vous pouvez budgéter une infrastructure éligible HIPAA, un modèle de données façonné par FHIR, une revue de sécurité. Ce que vous ne pouvez pas budgéter, c'est l'autre voie : une violation dont la moyenne dépasse largement les sept chiffres, un dossier OCR qui atterrit par-dessus, et les clients qui partent en silence parce qu'un produit de santé qui a laissé fuir leurs dossiers est une chose difficile à pardonner. Entre un coût connu et un coût inconnaissable, le coût connu est l'affaire à saisir.