Liste de contrôle HIPAA pour le développement logiciel — Privacy Rule, Security Rule, BAA

Sophie Laurent Responsable juridique & conformité, YuSMP Group · Praticienne RGPD, HIPAA et loi IA de l'UE

TL;DR — HIPAA pour le logiciel en un paragraphe

HIPAA s'applique-t-il à moi ? CE, BA et l'extension HITECH

HIPAA (Public Law 104-191, 1996) et ses réglementations aux 45 CFR Parts 160 et 164 s'appliquent directement aux Entités Couvertes (CE) : régimes d'assurance maladie, chambres de compensation de soins de santé et prestataires de soins transmettant des informations de santé sous forme électronique dans le cadre d'une transaction pour laquelle le HHS a adopté une norme (définition au 45 CFR 160.103). Pour les entreprises françaises opérant sur le marché américain ou traitant des données de patients américains, ces obligations s'ajoutent aux exigences du RGPD et de la certification HDS (Hébergeur de Données de Santé).

La loi HITECH de 2009 et la Règle Omnibus de 2013 ont étendu la majeure partie de la Privacy Rule et l'intégralité de la Security Rule aux Business Associates (BA) — toute personne ou entité qui crée, reçoit, conserve ou transmet des Informations de Santé Protégées (PHI) pour le compte d'une CE. Les BA comprennent les fournisseurs cloud, les éditeurs SaaS, les sociétés de facturation, les services de transcription, les entreprises d'analyse de données et, désormais — selon la guidance réglementaire HHS — les fournisseurs d'inférence IA lorsque des PHI transitent par leurs systèmes.

Si vous livrez un logiciel qui manipule des Informations de Santé Protégées, vous êtes presque certainement un Business Associate — c'est précisément là que débutent nos missions de développement logiciel conforme HIPAA, en cartographiant chaque flux de PHI avant d'écrire la moindre ligne de code de remédiation. Le test HHS est fonctionnel : avez-vous accès à des PHI dans le cadre de la prestation de services à une CE ? Si oui, le statut BA et l'obligation de BAA s'appliquent, quelle que soit la rédaction du contrat.

Notez l'exception dite du « conducteur » (HHS Guidance, 2013) : les services de pure transmission (FAI, services postaux) qui n'accèdent aux PHI que de manière transitoire ne sont pas des BA. Les fournisseurs cloud ne bénéficient explicitement pas de cette exception selon la même guidance, car ils stockent les PHI même momentanément.

Niveaux de pénalités 2026 et position de l'HHS en matière d'application

Les pénalités civiles en vertu du 45 CFR 160.404, telles qu'ajustées pour l'inflation dans la mise à jour du Federal Register de 2024, s'appliquent selon un barème par niveau de culpabilité. Les chiffres 2026, selon le dernier ajustement HHS :

Les pénalités pénales en vertu du 42 USC 1320d-6 ajoutent des peines d'emprisonnement de 1 à 10 ans pour les violations intentionnelles et les infractions commises dans l'intention de vendre des PHI à des fins personnelles. Les procureurs généraux des États disposent également d'un pouvoir d'application conféré par HITECH. En 2024–2025, les accords de résolution OCR se sont régulièrement établis entre 1 et 5 millions USD, les règlements Anthem et Premera continuant à ancrer la limite supérieure.

Le HHS a publié un Avis de Proposition de Réglementation (NPRM) en décembre 2024 pour renforcer la Security Rule, notamment en rendant obligatoires la plupart des spécifications « adressables », en imposant l'authentification multifacteur, le chiffrement des ePHI au repos et en transit par défaut, les inventaires d'actifs et les audits annuels de conformité. Pour toute entreprise française développant des logiciels pour le marché américain, nous traitons le NPRM comme le standard opérationnel pour tout projet HIPAA démarrant en 2026 — la finalisation est largement attendue en 2026–2027.

Principes essentiels de la Privacy Rule (45 CFR 164.500–534)

La Privacy Rule régit les utilisations et divulgations des PHI sous toute forme (papier, oral, électronique). Pour les développeurs de logiciels — y compris les prestataires informatiques européens servant des clients américains — les dispositions opératives essentielles sont :

• 164.502 — Utilisations et divulgations en général. Les PHI ne peuvent être utilisées ou divulguées que dans les conditions autorisées ou requises par la Privacy Rule, ou avec l'autorisation expresse de la personne concernée.
• 164.502(b) — Minimum nécessaire. Limiter les PHI au strict minimum nécessaire à la finalité prévue. En pratique logicielle : contrôle d'accès basé sur les rôles et visibilité au niveau des champs, et non « tout le monde voit tout ».
• 164.508 — Autorisations. Marketing, notes de psychothérapie, vente de PHI — nécessitent une autorisation écrite spécifique. Mise en œuvre : flux de consentement explicites avec options de révocation — une approche analogue à ce que le RGPD impose aux entreprises françaises.
• 164.514 — Anonymisation. Deux refuges légaux : Détermination par Expert (statistique) et Safe Harbor (suppression de 18 identifiants). Les données anonymisées sont hors du champ HIPAA. Traitez le pipeline d'anonymisation comme critique en matière de sécurité — la ré-identification constitue une violation.
• 164.520 — Avis de pratiques de confidentialité. Obligatoire pour les CE ; les contrats BA exigent souvent la conformité du BA à l'avis de confidentialité de la CE.
• 164.524 — Droit d'accès. Les personnes doivent pouvoir accéder à leurs PHI dans un délai de 30 jours (une prolongation de 30 jours autorisée). Le logiciel doit prendre en charge l'export des données patient dans des formats lisibles par machine — une exigence similaire au droit à la portabilité des données du RGPD.
• 164.526 — Droit de rectification. Les patients peuvent demander des rectifications ; le système doit accepter et acheminer ces demandes.
• 164.528 — Registre des divulgations. Historique sur 6 ans pour les divulgations hors traitement, paiement et opérations — le journal d'audit doit être conçu en ce sens dès le premier jour.

Mesures de protection techniques de la Security Rule (164.302–318)

La Security Rule régit exclusivement les ePHI (informations de santé protégées sous forme électronique) — c'est la règle que les équipes de développement manipulent au quotidien. Elle est organisée en trois groupes de mesures de protection, chacun avec des « Normes » (obligatoires) et des « Spécifications de mise en œuvre » (Requises ou Adressables). « Adressable » ne signifie pas optionnel — cela signifie que vous devez la mettre en œuvre ou documenter une alternative raisonnable et appropriée.

Mesures de protection administratives — 164.308

• 164.308(a)(1) Processus de gestion de la sécurité — analyse des risques, gestion des risques, politique de sanctions, revue des activités des systèmes d'information. L'analyse des risques est le fondement de tout le programme Security Rule ; les conclusions HHS citent systématiquement des analyses absentes ou obsolètes comme cause principale des règlements importants.
• 164.308(a)(3) Sécurité du personnel — procédures d'autorisation, de supervision, d'habilitation et de départ.
• 164.308(a)(4) Gestion des accès à l'information — autorisation d'accès, établissement et modification. Les revues trimestrielles des accès sont désormais considérées comme un prérequis fondamental.
• 164.308(a)(5) Sensibilisation et formation à la sécurité — formation périodique, rappels de sécurité, protection contre les logiciels malveillants, surveillance des connexions, gestion des mots de passe.
• 164.308(a)(6) Procédures d'incidents de sécurité — identifier, répondre, documenter, atténuer.
• 164.308(a)(7) Plan de continuité — sauvegarde des données, reprise après sinistre, fonctionnement en mode d'urgence, tests et révisions, criticité des applications et des données.
• 164.308(a)(8) Évaluation — évaluation technique et non technique périodique par rapport à la norme.
• 164.308(b) Contrats de Business Associate — assurances satisfaisantes écrites (BAA) avant tout accès du BA aux PHI.

Mesures de protection physiques — 164.310

Contrôles d'accès aux locaux (164.310(a)), utilisation et sécurité des postes de travail (164.310(b)/(c)), contrôles des appareils et supports incluant la mise au rebut, la réutilisation, la responsabilisation et la sauvegarde (164.310(d)). Pour les SaaS cloud natifs, les contrôles physiques sont largement hérités du BAA cloud, mais les politiques pour les postes de travail des développeurs manipulant des ePHI dans des environnements non-production restent de votre responsabilité.

Mesures de protection techniques — 164.312

C'est la section que votre équipe d'ingénierie doit implémenter directement. Cinq normes :

• 164.312(a) Contrôle d'accès. Identification unique de l'utilisateur (Requise), procédure d'accès d'urgence (Requise), déconnexion automatique (Adressable — en pratique requise), chiffrement et déchiffrement (Adressable — en pratique requis).
• 164.312(b) Contrôles d'audit. Mécanismes matériels, logiciels et procéduraux qui enregistrent et examinent les activités dans les systèmes d'information contenant des ePHI. Aucune durée de conservation spécifiée, mais 164.316(b)(2) fixe 6 ans pour la documentation associée.
• 164.312(c) Intégrité. Mécanisme pour authentifier les ePHI — protection contre les altérations ou destructions non autorisées. Hachages cryptographiques, signatures numériques, stockage en écriture unique pour les journaux d'audit.
• 164.312(d) Authentification des personnes ou entités. Vérification de l'identité avant d'accorder l'accès. L'authentification multifacteur (MFA) est désormais considérée comme le niveau minimal.
• 164.312(e) Sécurité des transmissions. Contrôles d'intégrité et chiffrement des ePHI en transit. TLS 1.2+ partout, sans exception.

Notification de violation : le compteur de 60 jours (164.400–414)

La notification de violation a été ajoutée par HITECH et codifiée au 45 CFR Sous-partie D. Une « violation » est l'acquisition, l'accès, l'utilisation ou la divulgation de PHI non sécurisées d'une manière non autorisée par la Privacy Rule et qui compromet la sécurité ou la confidentialité (164.402). Une évaluation des risques à quatre facteurs détermine si la notification est requise ; la présomption est qu'une utilisation ou divulgation non autorisée est une violation, sauf si l'analyse démontre une faible probabilité de compromission.

Le port de sécurité : si les PHI ont été chiffrées selon le standard HHS/HITECH (NIST SP 800-111 au repos, TLS validé FIPS 140-2 / NIST SP 800-52 en transit), l'événement de perte n'est pas une violation déclarable. Le chiffrement est le contrôle à effet de levier le plus élevé de tout le dispositif technique HIPAA — un principe que partagent également les directives HDS pour les entreprises françaises hébergeant des données de santé.

BAA et la chaîne de sous-traitance

L'exigence de BAA au 45 CFR 164.504(e) est non négociable. Les éléments obligatoires sont :

• Les utilisations et divulgations de PHI autorisées et requises par le BA.
• Le BA ne doit pas utiliser ou divulguer les PHI autrement que ce qui est autorisé ou requis.
• Le BA doit mettre en œuvre des mesures de protection appropriées (Security Rule pour les ePHI).
• Le BA doit signaler les violations et incidents de sécurité.
• Le BA doit s'assurer que les sous-traitants acceptent les mêmes restrictions (164.308(b)(2), 164.502(e)(1)(ii)).
• Le BA doit rendre les PHI disponibles pour l'accès individuel, la rectification et la comptabilisation.
• Le BA doit restituer ou détruire les PHI à la résiliation du contrat (si faisable).
• Le BA doit mettre ses pratiques de conformité à la disposition du HHS.
• Résiliation en cas de violation matérielle.

Constituez un inventaire BAA dès maintenant si vous n'en avez pas. Nous observons des programmes où Postgres sur une instance RDS éligible HIPAA est correctement couvert par BAA, mais où les journaux transitent vers un outil d'observabilité non-HIPAA — une violation immédiate. Chaque service en aval qui accède même transitoirement à des ePHI nécessite un BAA.

Cloud, LLM, mobile et IoT — les ePHI dans les architectures modernes

Les réalités HIPAA modernes vont bien au-delà de ce qu'imaginait la loi de 1996. Implications pratiques pour les équipes de développement logiciel en France et en Europe :

• Cloud. AWS, GCP et Azure publient des listes de services éligibles HIPAA. Signez le BAA avant d'envoyer des ePHI. Limitez les charges de travail ePHI aux services éligibles uniquement. Méfiez-vous des services « fantômes » créés par les analystes. Pour les entreprises françaises, notez que l'hébergement de données de santé sur des serveurs situés en France peut également nécessiter la certification HDS.
• LLMs. AWS Bedrock, Azure OpenAI Service et Vertex AI offrent une utilisation couverte par BAA. ChatGPT grand public et Claude.ai ne sont pas couverts par BAA — même coller des PHI dans une console développeur constitue une violation. Pour le RAG sur des PHI, le magasin d'embeddings, la base de données vectorielle et les journaux de récupération contiennent tous des ePHI et nécessitent une couverture BAA complète. Notre pratique de développement logiciel conforme HIPAA traite la pile LLM comme une surface ePHI de premier ordre.
• Mobile. Les applications de santé iOS et Android manipulant des PHI doivent utiliser Keychain / Keystore pour les identifiants, imposer une authentification biométrique ou par PIN, désactiver la sauvegarde des ePHI vers iCloud / Google Drive (aucun des deux n'est couvert par BAA), et épingler les certificats.
• IoT et télésurveillance. Chiffrement du transport appareil-cloud, rotation de l'identité des appareils, démarrage sécurisé et journalisation inviolable. Couche FDA 510(k) pour les dispositifs de classe II/III.

Un SDLC conforme HIPAA en 8 piliers

1. Analyse des risques conformément au 164.308(a)(1)(ii)(A), actualisée annuellement et après tout changement significatif. Utilisez la méthodologie NIST 800-30 ; les auditeurs la reconnaissent.
2. Formation du personnel conformément au 164.530(b) pour toute personne manipulant des PHI ; documentée dans un LMS avec attestations de complétion.
3. Accès au moindre privilège avec revues trimestrielles des accès conformément au 164.308(a)(4) ; provisionnement SCIM, accès JIT pour la production, définitions de rôles versionnées.
4. Journalisation d'audit dans un entrepôt inviolable (object lock, append-only) avec rétention de 6 ans minimum pour satisfaire 164.316(b)(2) ; journaliser chaque lecture, écriture, suppression et export de PHI, avec utilisateur, horodatage, IP source et identifiant d'enregistrement.
5. Chiffrement au repos (AES-256, clés gérées par KMS) et en transit (TLS 1.2+, modules cryptographiques validés FIPS 140-2 si possible) ; BYOK pour les locataires entreprise.
6. Sauvegarde, reprise après sinistre et plan de continuité testé conformément au 164.308(a)(7) ; RTO/RPO documentés par système, restauration testée au moins annuellement.
7. Chaîne BAA cartographiée, actualisée annuellement, contrôlée par les achats.
8. Runbook de réponse aux incidents avec le compteur de 60 jours intégré, testé deux fois par an via exercice de simulation, intégré à la gestion des astreintes.

La liste de contrôle technique que les auditeurs utilisent vraiment

• Identifiants utilisateur uniques — aucun compte partagé, jamais.
• MFA imposée pour tout compte ayant accès aux PHI, sans exception pour la « commodité administrative ».
• Délais d'expiration de session ≤ 15 minutes pour les interfaces cliniques, ≤ 30 minutes pour le back-office.
• Déconnexion automatique implémentée et testée.
• Chiffrement au repos avec clés gérées par KMS ; politique de rotation des clés documentée et exécutée.
• TLS 1.2+ partout ; chiffrements faibles désactivés ; HSTS preload.
• Journaux d'audit en append-only, immuables, avec vérification d'intégrité (HMAC ou signé) ; rétention 6 ans.
• Piste d'audit pour l'export des PHI avec résolution au niveau des champs.
• Pipeline d'anonymisation validé selon Safe Harbor ou Détermination par Expert, avec risque de ré-identification retesté annuellement.
• Accès à la base de données de production via JIT uniquement, chaque session enregistrée.
• Sauvegardes chiffrées, géographiquement diversifiées, testées en restauration.
• Inventaire BAA fournisseurs à jour ; chaque service manipulant des PHI inclus.
• Analyse des risques à jour, signée, datée dans les 12 derniers mois.
• Runbook de réponse aux incidents à jour, dernier exercice de simulation il y a moins de 6 mois.
• Dossiers de formation du personnel à jour, dernier cycle il y a moins de 12 mois.

Les 10 violations les plus courantes que nous observons lors des audits préventifs

1. Analyse des risques absente ou obsolète depuis 3 ans ou plus.
2. Journaux transitant vers un outil d'observabilité non couvert par BAA (Datadog par défaut, Sentry par défaut, etc.).
3. Accès développeur « fantôme » à la production sans JIT, sans enregistrement.
4. Comptes de service partagés, souvent des héritages de la période de développement.
5. Anonymisation implémentée via du SQL ad hoc, sans pipeline validé.
6. L'application mobile met en cache des PHI dans le stockage local sans chiffrement.
7. ChatGPT ou Claude.ai utilisés par le personnel de support avec de vraies PHI — violation immédiate.
8. Sauvegardes chiffrées en transit mais stockées en clair sur un cache CDN.
9. Pas de BAA avec le fournisseur de messagerie malgré des PHI dans les corps des tickets de support.
10. Le runbook de réponse aux incidents mentionne le compteur de 60 jours mais personne ne l'a déclenché depuis 18 mois.

Si vous planifiez un projet HealthTech ou remettez à niveau un programme HIPAA, nous réalisons des évaluations des lacunes à prix fixe dans le cadre de notre service de développement logiciel conforme HIPAA ; nous les avons livrées en parallèle avec des programmes de développement SaaS et de logiciel sur mesure, et un CTO fractionné avec expérience HIPAA se rentabilise généralement dans les deux premiers mois grâce à la seule réduction des risques.

FAQ

Dois-je être conforme HIPAA si je suis uniquement un éditeur logiciel ?

Si vous créez, recevez, conservez ou transmettez des PHI pour le compte d'une Entité Couverte, oui — vous êtes un Business Associate au sens du 45 CFR 160.103, la Security Rule étendue par HITECH et la majeure partie de la Privacy Rule s'appliquent directement, et vous devez un BAA. Cela s'applique aux prestataires informatiques européens et aux entreprises françaises servant des clients américains dans le secteur de la santé.

Que requiert techniquement la Security Rule ?

164.312 Mesures de protection techniques : contrôle d'accès avec identifiants uniques et accès d'urgence (164.312(a)), contrôles d'audit (164.312(b)), intégrité (164.312(c)), authentification (164.312(d)) — avec MFA comme niveau minimal 2026 — et sécurité des transmissions avec TLS 1.2+ (164.312(e)).

De combien de temps est-ce que je dispose pour signaler une violation ?

CE : notifier les individus dans les 60 jours suivant la découverte (164.404) ; le HHS simultanément si 500+ ; journal annuel si <500. BA : notifier la CE dans les 60 jours (164.410), généralement réduit contractuellement à 5–30 jours.

Le chiffrement offre-t-il un port de sécurité pour la notification de violation ?

Oui, si le chiffrement respecte le standard HHS/HITECH — NIST 800-111 au repos, NIST 800-52 / FIPS 140-2 en transit. Les clés doivent être séparées du texte chiffré.

Puis-je utiliser AWS, GCP, Azure pour les ePHI ?

Oui — signez d'abord le BAA, limitez aux services éligibles HIPAA, implémentez le chiffrement KMS, le moindre privilège IAM, la journalisation d'audit complète, l'isolation VPC. Vérifiez la liste d'éligibilité trimestriellement.

À quoi ressemble un SDLC conforme HIPAA ?

Huit piliers : analyse des risques, formation du personnel, accès au moindre privilège, journalisation d'audit avec rétention 6 ans, chiffrement, plan de continuité, chaîne BAA, réponse aux incidents avec le compteur de 60 jours intégré.

HIPAA n'est pas une liste de contrôle. C'est une posture opérationnelle.

Les équipes qui livrent des projets HIPAA proprement traitent la conformité comme un artefact de build : achats conditionnés au BAA, services chiffrés par défaut, journaux d'audit générés par le framework et non manuellement, MFA imposée dès le premier jour, analyse des risques sur calendrier. Les équipes qui traitent HIPAA comme un audit en fin de projet manquent toujours quelque chose de substantiel et le paient lors d'une enquête OCR.

Dernière mise à jour le 26 mai 2026. Les references aux sections renvoient aux 45 CFR Parties 160 et 164. Rien dans cet article ne constitue un conseil juridique pour une situation specifique.