Guides›Sécurité & conformité

Droit de la sécurité et de la vie privée · États-Unis, Union européenne, Royaume-Uni

La loi d'abord, puis le logiciel qui l'applique.

Un dossier de santé mentale est l'une des données les mieux protégées qui soient. Un seul regard de trop sur un seul fichier peut devenir une atteinte à déclarer. Cette page commence par les trois lois qui décident de ce que vous devez faire — HIPAA aux États-Unis, le RGPD dans l'Union européenne et le RGPD britannique au Royaume-Uni. Elle montre ensuite exactement quelle partie de la plateforme exécute chaque obligation. Elle couvre après cela la façon dont le logiciel lui-même est bâti, la façon dont Odoo Community contrôle qui voit quoi, la façon dont le serveur est durci, et, à la fin, les parts qui restent à votre organisation.

C'est écrit en langage simple à dessein. Vous devriez pouvoir la remettre à un délégué à la protection des données, à un auditeur en sécurité de l'information ou à un gestionnaire qui n'a jamais lu un règlement, et que les trois la suivent.

Délégués à la protection des données Auditeurs en sécurité de l'information Directeurs cliniques Acheteurs en vérification diligente

3régimes juridiques couverts 5propriétés de chaque dossier 0façons de passer outre l'accès AES-256-GCMde chiffrement sur chaque fichier 20 ansla plus longue conservation modélisée

Choisissez votre pays Ce que la loi demande États-Unis · UE · RU côte à côte Ce qui est protégé Les cinq propriétés Qui peut ouvrir un dossier Odoo : accès, connexion, rôles Durcissement du serveur Défense en profondeur Pratique du secteur de la santé Si quelque chose tourne mal Contrôles de la plateforme Ce que vous pouvez prouver Où le logiciel s'arrête

Commencez ici

Choisissez le pays où vous exercez

L'essentiel de ce qui suit est le même partout — le chiffrement, le contrôle d'accès, le journal d'audit, le durcissement du serveur. Ce qui change d'un pays à l'autre, c'est la machinerie des droits et de la gouvernance posée par-dessus, et elle a sa propre page. Si vous menez une vérification diligente, commencez par votre pays et revenez ensuite au matériel commun.

États-Unis USA HIPAA · HITECH · 42 CFR Part 2 · droit des États La plus grande des trois. Chaque règle américaine qui atteint un cabinet de santé mentale, ce qui a été construit pour chacune, et — à la fin — sept parcours pas à pas de ce qui se passe réellement dans le logiciel.

Privacy Rule : chaque droit du patient, y compris les parties que la plupart des systèmes laissent de côté
Security Rule : les huit garanties techniques, plus les registres administratifs et physiques
Notification des atteintes : quatre facteurs, 60 jours, seuils par État, les deux horloges du fournisseur
42 CFR Part 2, y compris la règle de 2024
Sept enchaînements — une demande de dossier, une correction refusée, une communication, une atteinte, un nouveau patient, un écran inactif, et l'année de conformité

Union européenne GDPR Règlement (UE) 2016/679 Fondement licite au titre de l'article 9(2)(h) plutôt que le consentement, effacement réalisé en détruisant la clé de chiffrement, portabilité comme export journalisé, et les deux échéances d'atteinte avec l'exemption qu'il faut mériter.

Pourquoi les dossiers de traitement ne doivent pas reposer sur le consentement
Un effacement qui honore le droit sans détruire la preuve
L'horloge de 72 heures et la question des clés compromises
Registre des traitements et analyse d'impact comme documents vivants

Deutschland Allemagne § 203 StGB · § 630f BGB · NIS2 · SGB V Les règles européennes s'appliquent ici telles quelles — puis l'Allemagne ajoute sa propre couche, dont une pièce relève du droit pénal et décide si un cabinet peut légalement acheter chez nous.

§ 203 StGB : pourquoi le choix du fournisseur est le risque juridique du thérapeute
Ce que dit une Verpflichtungserklärung § 203, clause par clause
Dix ans à compter de la fin du traitement, pas de la date du dossier
NIS2 pour les groupes de cabinets, et le programme déjà construit
Un exposé honnête du rail légal que nous n'avons pas

Royaume-Uni RGPD britannique DPA 2018 · NHS Code of Practice 2021 Ce que le Royaume-Uni ajoute au RGPD : le critère du préjudice grave bâti comme un flux qui expire de lui-même, le calendrier de conservation du NHS livré comme données, et un droit sur les dossiers des personnes décédées.

Une rétention qui exige un professionnel nommé et tombe au bout de six mois
Vingt ans après le dernier contact pour les dossiers de santé mentale
Access to Health Records Act 1990
Le principe Caldicott 7 et pourquoi le bris de glace est une fonctionnalité

Australia Privacy Act 13 APP · régime NDB · droit des États sur la conservation Une loi fédérale sans exemption pour les petites entreprises quand on est prestataire de santé, huit jeux de règles d'État sur la conservation, et — depuis juin 2025 — un patient qui peut poursuivre sans attendre un régulateur.

Les treize Australian Privacy Principles, un par un
APP 8 : pourquoi rien n'a à quitter le pays
Sept ans après la dernière inscription, et jusqu'à 25 ans pour un enfant
L'enchaînement d'atteinte, pas à pas, plus la déclaration de rançongiciel à 72 heures
Essential Eight, ISO 27001, RACGP C6.4 — et pourquoi SOCI ne s'applique pas

Canada PIPEDA et PHIPA 10 principes · lois provinciales · conservation fixée par l'ordre Pas de HIPAA, pas de loi unique : une loi fédérale, une loi santé qui change avec la province, et un ordre professionnel par-dessus les deux qui fixe combien de temps vous gardez un dossier.

Quelle loi et quel commissaire, province par province
Les dix principes de PIPEDA, et la PHIPA custodian par custodian
Le coffre-fort — le seul concept canadien que nous n'avons pas encore
Deux horloges de notification, et le rapport statistique annuel de mars
Le rail de facturation provincial sur lequel nous ne sommes pas, dit à la section 09

Communs aux six Documents sécurisés La machinerie sur laquelle repose chaque page de pays Comment un dossier clinique est chiffré, qui peut en ouvrir un, toute la vie d'un document du dépôt à la destruction — et, à la fin, sept risques qui n'ont aucun correctif technique.

Le chiffrement en enveloppe, et pourquoi il y a deux clés et non une
Un accès qui suit la relation thérapeutique
Une destruction qui détruit une clé plutôt que d'effacer une ligne
Sept risques dits franchement, avec ce qui reste à votre charge

01 — Commencez par la loi

Ce que HIPAA, le RGPD et le RGPD britannique vous demandent vraiment

La plupart des documents de sécurité commencent par la technique et gardent la loi pour la fin. Celui-ci fait l'inverse, parce que c'est à la loi que vous serez comparé. Voici chaque régime en langage simple : ce qu'il est, à qui il s'applique, et les obligations qu'il impose à une clinique. Sous chacun figure la partie de la plateforme qui exécute cette obligation.

États-Unis

HIPAA

HIPAA est le Health Insurance Portability and Accountability Act. Il s'applique aux prestataires de santé aux États-Unis et aux entreprises qui manipulent des données de santé pour leur compte. Il est bâti de deux parties principales. La Privacy Rule dit qui peut voir des renseignements de santé et ce qu'un patient peut demander. La Security Rule dit comment les renseignements de santé électroniques doivent être protégés.

Minimum nécessaire. Le personnel ne peut voir que les renseignements nécessaires au travail qu'il a devant lui. Dans la plateforme, c'est appliqué par les relations de soins : un thérapeute atteint les clients de sa propre charge de travail, pas ceux de toute la clinique.
L'ensemble de dossiers désigné. Un patient peut demander une copie de son dossier, mais pas de tout ce que la clinique détient. Chaque type de document est marqué dedans ou dehors de cet ensemble, et une demande ne peut pas rendre ce qui est dehors.
Les notes de psychothérapie sont à part. HIPAA traite les notes de processus d'un thérapeute différemment du dossier. Dans la plateforme, elles sont chiffrées sous une clé différente, de sorte que la clé qui ouvre le dossier ordinaire ne les ouvre pas.
Reddition des communications. Un patient peut demander avec qui ses renseignements ont été partagés au cours des six dernières années. Le registre des communications y répond à partir d'enregistrements.
Notification des atteintes. Si des renseignements de santé protégés sont exposés, les personnes doivent être prévenues — sauf si les données étaient correctement chiffrées. Cette exemption s'appelle la sphère de sécurité, et c'est la raison pour laquelle le chiffrement est bâti comme il l'est.
42 CFR Part 2 est une règle américaine distincte pour les dossiers de traitement des dépendances. Elle est plus stricte que HIPAA et exige un avertissement de retransmission sur tout ce qui est partagé. La plateforme génère cet avis au lieu de demander au personnel de le taper.

Union européenne

GDPR

Le RGPD est le Règlement général sur la protection des données. Il s'applique à toute organisation qui traite des données personnelles de personnes dans l'Union européenne. Les données de santé sont ce que le RGPD appelle des données de catégorie particulière, ce qui veut dire qu'il est interdit de les traiter sauf si une condition précise s'applique. Là où HIPAA porte surtout sur la protection, le RGPD porte aussi sur les droits de la personne sur ses propres données.

Un fondement licite pour chaque type de document. Pour les dossiers de traitement, la condition correcte est l'article 9(2)(h), la prestation de soins — pas le consentement. Un consentement qu'une personne ne peut pas refuser librement n'est pas un consentement valable, et dans un cadre de soins elle ne peut d'ordinaire pas refuser. La plateforme consigne le fondement au regard du type de document, de sorte que ce n'est jamais une supposition ensuite.
Le droit d'accès (art. 15). Une personne peut demander une copie de ses données, et il y a une échéance légale pour répondre. La demande se déroule comme un flux suivi portant cette horloge.
Le droit à l'effacement (art. 17). Souvent appelé droit à l'oubli. La plateforme l'honore en détruisant la clé de chiffrement plutôt que la ligne de base de données, de sorte que le contenu a disparu mais que la preuve qu'un dossier a existé et a été détruit demeure.
Le droit à la portabilité (art. 20). Une personne peut demander ses données sous une forme qu'elle peut emporter ailleurs. La plateforme construit une archive zip en mémoire et la diffuse, et journalise chaque document qu'elle contient individuellement.
Notification des atteintes (art. 33 et 34). Le régulateur doit être prévenu dans les 72 heures suivant votre prise de connaissance. Les personnes touchées doivent l'être aussi, sauf si les données étaient chiffrées.
Documents de gouvernance (art. 30 et 35). Vous devez tenir un registre de vos activités de traitement, et mener une analyse d'impact relative à la protection des données pour les travaux à haut risque. Les deux vivent dans le système comme documents vivants, pas comme un fichier Word qui se périme.

Royaume-Uni

Le RGPD britannique et la DPA 2018

Après sa sortie de l'Union européenne, le Royaume-Uni a gardé le RGPD presque inchangé et l'appelle RGPD britannique. Le Data Protection Act 2018 l'accompagne et ajoute des règles propres au Royaume-Uni, dont plusieurs comptent beaucoup en santé. Le régulateur est l'Information Commissioner's Office, l'ICO.

Tout ce qu'exige le RGPD s'applique encore. L'accès, l'effacement, la portabilité, la notification des atteintes et les registres de gouvernance sont les mêmes obligations que dans l'UE.
Le critère du préjudice grave. Des données de santé peuvent être retenues face à la demande d'accès de la personne elle-même lorsque leur communication risquerait de lui causer un préjudice grave. Pour un service de santé mentale, c'est l'équivalent de l'exception américaine sur les notes de psychothérapie, et la procédure qui l'entoure est stricte.
Les durées de conservation du NHS. Le NHS Records Management Code of Practice 2021 fixe la durée de conservation des dossiers — pour la santé mentale, 20 ans après le dernier contact. Ce calendrier est livré comme données de départ.
Access to Health Records Act 1990. Les proches d'une personne décédée peuvent dans certains cas demander ses dossiers. Le RGPD ne couvre pas du tout les personnes décédées : c'est donc un droit propre au Royaume-Uni, avec ses propres règles sur qui a le droit de demander.
Le principe Caldicott 7. Les directives britanniques en santé disent que l'obligation de partager des renseignements peut être aussi importante que celle de les protéger. Tout bloquer est une défaillance en soi, et c'est pourquoi l'accès d'urgence existe et est consigné plutôt qu'interdit.

Ce sur quoi les quatre s'accordent

Sous les différences, les quatre régimes veulent les cinq mêmes choses. Protéger les données pour qu'une copie volée soit inutile. Ne laisser que les bonnes personnes les voir. Garder trace de qui les a vues. Ne les garder que le temps nécessaire, puis les détruire correctement. Pouvoir prouver les quatre ensuite. Cette liste commune est ce que la plateforme bâtit une fois dans la couche de stockage, pour chaque déploiement. La machinerie des droits par-dessus est ce qui change d'un pays à l'autre, et elle est livrée comme module distinct que vous installez pour votre juridiction.

Personne n'est certifié pour cela, et quiconque dit le contraire vend quelque chose

Il n'existe pas de produit certifié HIPAA ou certifié RGPD. Aucune autorité ne délivre ce certificat. Ce qui existe, c'est une liste de contrôles techniques et organisationnels. Un logiciel peut mettre en œuvre les techniques et rendre les organisationnels faciles à exécuter et à prouver. Il ne peut pas rendre une organisation conforme à lui seul. La dernière section de cette page dit exactement quelles parts restent à votre charge.

02 — Côte à côte

Le même noyau technique partout. Une machinerie des droits différente par-dessus

Le chiffrement, le contrôle d'accès, le journal d'audit et la conservation sont identiques dans chaque pays. Ils sont bâtis une fois, dans le noyau commun, et chaque déploiement les reçoit. Ce qui change entre les États-Unis, l'Union européenne, le Royaume-Uni, l'Australie et le Canada, c'est le travail de droits et de gouvernance posé sur ce noyau. C'est pourquoi un système bâti aux normes américaines ne satisfait pas automatiquement l'UE, et pourquoi chaque pays arrive comme son propre module installable.

Les deux dernières colonnes portent les marques les plus honnêtes. Les Australian Privacy Principles demandent moins que l'Europe en deux endroits, et il n'y a pas encore de module australien — la machinerie des droits qu'un déploiement australien utilise aujourd'hui, c'est le noyau commun plus des parties des modules européen et britannique. La page Australie nomme chaque couture.

Le Canada est le plus récent, et la seule colonne où le corpus de règles change à l'intérieur du pays. Il n'y a pas non plus de module canadien, et une obligation n'a d'équivalent nulle part ailleurs dans ce tableau — le coffre-fort, une instruction du patient qui clôture une partie de son propre dossier à l'intérieur du cercle de soins. La page Canada dit ce que sa construction suppose, et quelle loi provinciale s'applique où.

Ce qui est exigé	États-Unis HIPAA · 42 CFR Part 2	Union européenne GDPR	Royaume-Uni RGPD britannique · DPA 2018	Australia Privacy Act 1988 · APP	Canada PIPEDA · PHIPA et lois provinciales
Chiffrement, contrôle d'accès, journal d'audit, conservation	✓ noyau commun	✓ noyau commun	✓ noyau commun	✓ noyau commun	✓ noyau commun
Une raison juridique consignée pour détenir chaque type de document	— ce n'est pas ainsi que HIPAA fonctionne	✓ art. 9(2)(h) pour les dossiers de traitement, pas le consentement	✓ pareil, sous le RGPD britannique	✓ APP 3.3 et art. 16B, consigné par type de document	§ finalité et consentement, pas un fondement licite énuméré
Une personne peut demander une copie de son dossier	✓ 45 CFR 164.524, limité à l'ensemble de dossiers désigné	✓ art. 15, avec une échéance légale	✓ art. 15, plus le critère du préjudice grave	✓ APP 12, un délai raisonnable, et sans frais pour demander	✓ principe 9 de PIPEDA et art. 52 de la PHIPA — 30 jours, prorogeables
Une partie peut lui être retenue	✓ les notes de psychothérapie sont hors de l'ensemble de dossiers	§ étroit, et dépend de l'État membre	✓ critère du préjudice grave, mené comme un flux qui expire	◐ les motifs de l'APP 12.3 existent ; le flux est livré avec la liste britannique	◐ les motifs de la PHIPA existent ; le flux est livré avec la liste britannique
Une personne peut demander la suppression de ses données	§ HIPAA ne donne aucun droit général ; c'est la conservation qui décide	✓ art. 17, réalisé en détruisant la clé	✓ pareil, avec les exemptions britanniques	§ aucun droit général à l'effacement ; la destruction de l'APP 11.2 fait le travail	§ aucun droit général ; la conservation et la destruction font le travail
Une personne peut emporter ses données ailleurs	§ par le droit d'accès ; HIPAA n'en a pas de distinct	✓ art. 20, zip diffusé, chaque fichier journalisé	✓ pareil	§ aucun droit à la portabilité ; le droit d'accès le porte	✓ le droit de la Loi 25 du Québec atterrit sur l'export RGPD ; aucun équivalent fédéral
Un registre de ce qui a été partagé, et avec qui	✓ six ans, sur demande	✓ ce qui est sorti, vers qui, sur quel fondement	✓ pareil	✓ APP 6, ce qui est sorti et sur quel fondement	✓ ce qui est sorti, vers qui, sur quel fondement et pourquoi
Prévenir le régulateur et les personnes touchées après une atteinte	✓ évaluation à quatre facteurs, avis à 60 jours, seuils médias et HHS	✓ art. 33 et 34, 72 heures, deux horloges, question des clés consignée	✓ pareil, signalé à l'ICO	✓ régime NDB : 30 jours pour évaluer, puis notifier dès que possible	◐ la trace est complète ; les deux dépôts et le compte de mars ne sont pas produits
Des documents de gouvernance écrits, tenus à jour	✓ registre des politiques, versionné, six ans par version	✓ analyse d'impact (art. 35) et registre des traitements (art. 30)	✓ pareil	✓ APP 1 : registre des politiques, registre de risques, plaintes comme dossiers	✓ registre des politiques, registre de risques, plaintes comme dossiers
Un calendrier de conservation livré prêt à l'emploi	⚙ varie selon l'État, vous fixez donc les durées	⚙ varie selon l'État membre, vous fixez donc les durées	✓ NHS Records Management Code of Practice 2021	◐ les durées sont connues nationalement, et rien n'est ensemencé	⚙ fixées par votre ordre, il n'y a donc aucun calendrier national à ensemencer
Les dossiers des personnes décédées	⚙ HIPAA les protège 50 ans ; règle non ensemencée	— le RGPD ne s'applique pas aux personnes décédées	✓ Access to Health Records Act 1990	§ la loi fédérale s'arrête au décès ; la NSW protège 30 ans après	⚙ les lois continuent après le décès ; la durée est celle de votre ordre
Protection supplémentaire des dossiers de dépendances	✓ 42 CFR Part 2, avec l'avis de retransmission	— aucune règle équivalente	— aucune règle équivalente	— aucune règle équivalente	— aucune règle équivalente

✓ConstruitDans le module de juridiction aujourd'hui, et démontrable. ⚙Construit — la valeur est à vousLe mécanisme est là et le nombre est le vôtre, parce que la loi vous le laisse, ou le laisse à votre État. Ce n'est pas un manque. §Ce régime en demande moinsRien ne manque. La loi de ce pays donne un droit plus étroit, ou arrive au même point par un autre chemin. ◐Partiellement construitQuelque chose manque vraiment. La page du pays nomme exactement quoi. —Absent de ce régimeLa loi ne contient tout simplement pas ce droit.

Les deux marques du milieu n'en faisaient qu'une jusqu'à récemment, ce qui se lisait comme un seul genre de manque alors que seul ◐ en est un. Une durée de conservation que vous fixez parce que votre État la fixe n'est pas une fonctionnalité manquante, et le refus de HIPAA d'accorder un droit que le RGPD accorde non plus.

03 — Ce qui est protégé

Trois sortes de données, et une seule est ordinaire

Tout dans une clinique n'a pas besoin de la même protection. Si vous traitez chaque champ comme le plus sensible qui soit, le système devient lent et pénible et le personnel se met à garder des notes dans un tableur. C'est le vrai risque d'atteinte dans la plupart des cliniques. Si vous ne traitez rien comme sensible, le système est tout simplement dangereux. La plateforme trie donc les données en trois sortes et n'applique la lourde machinerie qu'à celle qui en a besoin.

Sorte de données	Exemples	Comment c'est stocké	Qui peut y accéder
Données d'affaires ordinaires	Coordonnées, commandes, factures, réservations, messages de discussion	Dans la base, protégées par les règles d'accès propres à Odoo	Le personnel dont le travail en a besoin. Le client lui-même, par le portail
Dossiers cliniques et professionnels	Comptes rendus de séance, dossiers d'incident et de protection, pièces d'identité	Comme documents sécurisés : chiffrés une version à la fois, stockés hors de la zone de fichiers normale	Seulement l'équipe de soins de ce client, par une règle explicite. Aucun intitulé de poste ne l'accorde
Dossiers financiers	Factures, versements aux praticiens, versions de contrat, écritures comptables	Dans le grand livre comptable, qui ne peut plus être modifié une fois une écriture émise	Finance et direction. Une correction laisse une trace au lieu d'écraser

Pourquoi la ligne passe au dossier, pas au champ

Chiffrer chaque champ rendrait la recherche impossible. Le personnel garderait alors ses notes de travail hors du système, là où rien n'est journalisé et rien n'est protégé. La plateforme trace donc la ligne à la sorte de dossier plutôt qu'au champ. Le matériel sensible reste dans le système, là où chaque lecture peut être consignée.

04 — Le modèle de dossier

Cinq choses vraies de tout dossier protégé

Ces cinq points sont des propriétés de la façon dont les données sont stockées. Ce ne sont pas des politiques qu'on demande au personnel de suivre. Cette différence est tout l'argument de cette page. Un contrôle qui dépend du bon comportement des gens est un contrôle que vous ne pouvez pas démontrer à un auditeur. Un contrôle bâti dans le stockage, si.

Propriété un

Chaque version est chiffrée à part

La plateforme utilise le chiffrement en enveloppe avec AES-256-GCM. Cela veut dire que chaque version de document reçoit sa propre clé aléatoire, et que cette clé est ensuite verrouillée par une seconde clé appartenant à tout le déploiement. Cette seconde clé n'est jamais stockée dans la base.

Qui vole une copie de la seule base n'a rien de lisible
Les fichiers chiffrés vivent hors du stockage de fichiers ordinaire d'Odoo et ne sont jamais servis par la route de téléchargement normale
Faire tourner la clé du déploiement reverrouille les petites clés sans réécrire un seul fichier chiffré
Le logiciel refuse de démarrer si cette clé est absente, lisible par tous, détenue par le mauvais compte, ou gardée là où elle serait copiée avec les données qu'elle protège

Propriété deux

Fermé sauf si une règle ouvre

Chaque lecture doit trouver une règle qui l'autorise et aucune qui l'interdise. C'est vérifié chaque fois, pas une fois à la connexion. Être administrateur, gestionnaire ou auteur du document n'accorde rien en soi.

Il n'y a aucune dérogation maîtresse ni aucune route de super-utilisateur vers le contenu clinique
L'accès suit l'équipe de soins du client, pas l'organigramme
Quand le personnel dépose un document, la boîte de dialogue lui dit en mots simples qui pourra l'ouvrir, avant l'enregistrement

Propriété trois

Chaque lecture est écrite

Les ouvertures sont journalisées, pas seulement les modifications. Le journal est en ajout seul et chaîné par empreintes, ce qui veut dire que chaque entrée est mathématiquement liée à la précédente. Retirer ou modifier une entrée brise la chaîne et se voit.

L'entrée est écrite avant que le contenu ne soit remis, pas après
Personne ne peut la modifier ou la supprimer, y compris ceux qui administrent le système
Une liste complète de qui a ouvert un dossier peut être produite pour un client, un régulateur ou vos propres avocats
Les lectures du portail sont limitées en débit par utilisateur, comptées depuis ce même journal, de sorte que la limite tient même sur plusieurs processus serveur

Propriété quatre

Les corrections ajoutent, elles n'écrasent jamais

Quand quelque chose est corrigé, une nouvelle version est déposée. La précédente reste exactement telle quelle, métadonnées comprises. Un dossier que l'on peut modifier en douce ne vaut rien comme preuve, et un jour le vôtre devra peut-être valoir quelque chose.

Une demande de modification s'ajoute au dossier au lieu de le remplacer
Chaque version porte sa propre clé, de sorte que la destruction peut se faire version par version
Une altération est donc visible dans l'historique plutôt que quelque chose à déduire

Propriété cinq

La destruction détruit la clé

Quand une durée de conservation expire, la plateforme détruit la clé de chiffrement au lieu de supprimer la ligne. Le contenu devient définitivement illisible. La coquille vide et la piste d'audit demeurent. Cette technique s'appelle le crypto-effacement.

La destruction peut être prouvée plutôt que simplement affirmée
La preuve qu'un dossier a existé, et a été détruit à temps, survit
La conservation est comptée depuis une vraie date d'ancrage : dernier contact, date de naissance ou date de décès

Le manque délibéré

Ce qu'elle ne fera pas, dit ouvertement

La plateforme ne peut pas chercher à l'intérieur de documents chiffrés. C'est une conséquence directe du chiffrement, pas une fonctionnalité manquante. Les documents se trouvent par la personne concernée, par leur type et par leur date de dépôt.

C'est dit ici parce qu'un fournisseur qui promet à la fois un chiffrement fort et la recherche plein texte du même contenu promet faussement l'un des deux
C'est un service de documents sécurisés, pas un dossier de santé électronique : pas de tenue de dossier structurée, pas de messagerie HL7 ou FHIR, pas de prescription électronique
Le noyau ne connaît rien au droit de la santé. Les règles de chaque pays arrivent comme un module distinct par-dessus

05 — Qui peut ouvrir un dossier

L'accès suit la relation de soins, pas l'intitulé de poste

C'est l'idée la plus importante de la page, et la seule chose qu'un gestionnaire de documents ordinaire ne sait pas exprimer. Une relation de soins est un lien consigné entre un clinicien et un client, avec un type, une date de début et une date de fin. Un thérapeute atteint les dossiers des personnes de sa propre charge de travail. Pas celle de la clinique. La sienne. Quand la relation prend fin, l'accès aussi, après un court délai de grâce assez long pour finir les notes en cours.

C'est ce qui transforme le « minimum nécessaire » d'une politique dans un manuel en quelque chose que le logiciel applique vraiment, et que vous pouvez démontrer en audit.

Ce qui arrive à chaque lecture

Cinq étapes, chaque fois, pour chaque document

Qui demande ?Un utilisateur connecté, ramené à une personne précise. Pas un rôle et pas un groupe.
Existe-t-il une règle qui l'autorise ?Parce qu'il est la personne concernée, parce qu'il est dans l'équipe de soins, ou parce que quelqu'un lui a accordé un accès nommé. Pas de règle, pas d'accès.
Existe-t-il une règle qui l'interdit ?Un refus l'emporte toujours sur une permission. Les notes de psychothérapie, les documents scellés et les dossiers retenus refusent sur toutes les routes d'entrée.
Écrire l'entrée de journalAjoutée au journal en ajout seul avant que le moindre contenu ne soit renvoyé.
Déchiffrer en mémoire et diffuserRien n'est écrit sur disque en sortie et rien n'est servi depuis la zone de fichiers ordinaire.

Ce qui ne vous fait pas entrer

Listé explicitement, parce que les acheteurs le demandent toujours

Être administrateurUn compte admin n'ouvre aucun contenu clinique en soi. Il n'y a pas de porte dérobée pour le support ou la maintenance.
L'avoir écrit soi-mêmeLes dossiers d'incident et de protection sont fermés même à la personne qui les a déposés, parce qu'ils sont déposés auprès du directeur de la clinique.
Être haut placéLes rôles cliniques décident des écrans de l'application qu'une personne atteint. Ils ne décident jamais de ce qu'elle peut ouvrir.
Être le clientUn client ne voit un dossier le concernant que lorsqu'une règle l'accorde précisément. C'est une décision clinique et juridique, prise exprès et consignée avec le motif et le nom de qui l'a prise.
Deviner une référence de documentUn document que vous ne pouvez pas voir renvoie « introuvable », jamais « interdit ». Sinon, deviner des références devient un moyen de découvrir qui détient des dossiers.

L'accès d'urgence existe, et il n'est jamais discret

Parfois un clinicien a vraiment besoin d'un dossier avec lequel il n'a aucune relation — une crise, un appel hors des heures, un collègue souffrant. Si votre organisation le permet, une route d'accès d'urgence est disponible. Son usage est consigné comme un événement et revu ensuite par le responsable de la vie privée.

Voilà la conception en une phrase : l'accès est disponible quand quelqu'un en a vraiment besoin, et jamais silencieux. C'est délibéré. Un système qui ne fait que bloquer échoue à sa manière. Les directives britanniques (principe Caldicott 7) disent que l'obligation de partager peut être aussi importante que celle de protéger, et c'est pourquoi l'accès d'urgence est une fonctionnalité conçue du noyau plutôt qu'un trou qu'on y a laissé.

06 — Le noyau d'affaires

Comment Odoo Community décide qui vous êtes, et ce que vous voyez

La machinerie clinique décrite plus haut repose sur Odoo 19 Community, le noyau d'affaires à code ouvert. Odoo apporte son propre modèle de contrôle d'accès, et il vaut la peine de le comprendre, parce que c'est lui qui protège les données d'affaires ordinaires — les réservations, factures, contacts et messages qui forment l'essentiel du système.

Cette section a six parties : les quatre couches de contrôle d'accès qui décident de ce qu'une personne connectée peut atteindre ; la connexion — mots de passe, authentification à deux facteurs, clés d'accès et les politiques autour ; ce que « fondé sur les rôles » veut dire vraiment ici, car l'expression est employée à tort et à travers ; l'isolement des bases; le Top Ten de l'OWASP avec la réponse d'Odoo à chacun ; et ce que le code ouvert vaut réellement.

Tout ce qui suit est livré avec Odoo 19 Community. Rien n'est un module payant, et tout est du code source lisible que votre propre équipe de sécurité peut examiner.

Le modèle d'accès d'Odoo a quatre couches. Chacune répond à une question différente, et une requête doit passer les quatre. Elles sont vérifiées dans la couche de données elle-même, ce qui est l'essentiel : les mêmes vérifications s'appliquent que le dossier soit atteint par l'interface web, par la passerelle de l'application mobile ou par l'API distante d'Odoo. Aucune route ne les contourne.

Couche un

Groupes — quelle partie du système vous atteignez

Un groupe est un rôle. L'appartenance décide des menus, écrans et boutons qu'une personne voit tout court. Les groupes peuvent en impliquer d'autres, de sorte qu'un superviseur détient automatiquement tout ce que détient un clinicien, sans que les permissions soient écrites deux fois.

Les rôles de ce déploiement comprennent clinicien traitant, superviseur, directeur de clinique, dépositaire des dossiers, accueil et responsable de la vie privée
L'accueil, c'est la démographie seulement : aucun contenu clinique et aucun accès aux documents, d'aucune sorte
Un groupe accorde une portée, jamais un contenu. Détenir le rôle de clinicien n'ouvre le dossier d'aucun client en soi — c'est la relation de soins qui le fait

Couche deux

Droits d'accès par modèle — ce que vous pouvez faire à une sorte de dossier

Pour chaque type de dossier et chaque groupe, Odoo stocke quatre permissions distinctes : lire, créer, modifier et supprimer. Elles sont déclarées dans des fichiers texte livrés avec chaque module, et peuvent donc être lues et revues sans rien exécuter.

Ce déploiement déclare 660 entrées d'accès sur 35 modules
Tout ce qui n'est pas listé est refusé. L'accès s'accorde en le nommant, jamais en oubliant de le bloquer
Lire sans modifier est courant à dessein : beaucoup de rôles peuvent voir un dossier qu'ils ne doivent pas changer

Couche trois

Règles d'enregistrement — quels dossiers individuels vous pouvez toucher

Une règle d'enregistrement est un filtre appliqué à chaque requête. C'est ce qui rend « vos propres clients » et « votre propre société » réels plutôt qu'affaire d'écran ouvert. Les règles globales s'appliquent toujours. Les règles attachées à un groupe n'élargissent l'accès que pour ce groupe.

Ce déploiement définit 117 règles d'enregistrement dans les modules cliniques, de réservation, de contrats, de signature électronique et de rapports
Exemples typiques : un clinicien voit les relations de soins où il est le clinicien ; un utilisateur du portail ne voit que les réservations rattachées à sa propre fiche contact
La règle est appliquée par la couche de données, de sorte qu'elle tient pour les listes, les rapports, les exports et l'API distante indifféremment

Couche quatre

Règles de champ et séparation du portail

Des champs individuels peuvent être réservés à certains groupes, de sorte que deux personnes peuvent ouvrir le même dossier et en voir des quantités différentes. Par ailleurs, Odoo garde les utilisateurs du portail dans une classe entièrement distincte du personnel.

Un utilisateur du portail — un client ou un contact externe — n'a aucun accès au back-office, seulement aux pages publiées explicitement pour lui
Les pages web publiques tournent sous un utilisateur anonyme à qui presque rien n'est accordé, de sorte qu'une erreur sur une page publique ne peut pas exposer des données du personnel
Chaque route de contrôleur de ce déploiement déclare si elle exige un utilisateur connecté ou si elle est délibérément publique : 174 routes exigent une connexion, 57 sont publiques à dessein

Protection du cadriciel	Ce que fait Odoo	Ce que cela empêche
Construction des requêtes	Toutes les requêtes de base sont bâties par le cadriciel à partir de filtres structurés. Le code applicatif n'écrit pas de SQL brut pour les lectures et écritures ordinaires	L'injection SQL par les champs de recherche, les filtres et les paramètres d'URL
Échappement des gabarits	Le moteur de gabarits d'Odoo échappe par défaut les valeurs qu'il rend dans une page. La sortie brute doit être demandée explicitement	Le script intersites, où un texte enregistré par un utilisateur s'exécute comme du code dans le navigateur d'un autre
Jetons de formulaire	Les formulaires web qui modifient des données portent un jeton lié à la session de l'utilisateur, et le serveur rejette une soumission sans lui	La falsification de requête intersites, où un autre site soumet silencieusement un formulaire sous votre identité connectée
Sessions	L'état de session est tenu sur le serveur. Le navigateur ne détient qu'un identifiant, dans un témoin marqué de sorte que les scripts de la page ne peuvent pas le lire	Le vol de session par un script exécuté dans la page
Mots de passe	Stockés seulement comme empreinte à sens unique, jamais sous une forme réversible. Le schéma d'empreinte peut être renforcé sans demander à tout le monde de réinitialiser	Qu'une table d'utilisateurs volée devienne une liste de mots de passe utilisables
Gestionnaire de bases	Les écrans qui créent, copient, restaurent et suppriment des bases entières sont fermés en production, et un nom d'hôte est lié à exactement une base	Que quiconque atteint le serveur puisse trouver, copier ou écraser une base
Opérations privilégiées	Le code ne peut contourner les règles d'accès que là où un développeur l'a écrit délibérément, pour une opération définie, à un endroit nommé. Le contenu clinique n'est pas l'un de ces endroits	Une élévation de privilèges large et accidentelle enfouie dans le code applicatif
Code ouvert	Odoo Community est publié sous licence ouverte et les modules de cette plateforme sont lisibles intégralement. Les correctifs de sécurité sont publiés par Odoo et appliqués à votre propre installation	Devoir croire entièrement sur parole les affirmations de sécurité d'un fournisseur

La connexion : mots de passe, seconds facteurs et les politiques autour

Les quatre couches ci-dessus décident de ce qu'une personne connectée peut atteindre. Voici ce qui vient avant — comment Odoo établit que quelqu'un est bien qui il prétend être, et ce qu'il fait quand ce n'est pas le cas. Tout est livré avec Odoo 19 Community ; rien n'est un module payant.

Contrôle	Statut	Ce que cela fait, et ce que vous décidez
Les mots de passe sont hachés, jamais stockés	✓	Stockés comme empreinte PBKDF2-SHA512 avec un sel par mot de passe et un facteur de travail paramétrable. Une empreinte ne peut pas être retransformée en mot de passe : une table d'utilisateurs volée n'est donc pas une liste d'identifiants. Le facteur de travail peut être relevé à mesure que le matériel accélère, et les mots de passe sont réhachés au réglage plus fort à la prochaine connexion de chacun — personne n'a à réinitialiser. Personne ne peut relire un mot de passe, y compris vos propres administrateurs et nous compris : le champ se lit toujours comme vide, quel que soit le demandeur. Si quelqu'un perd son mot de passe, la seule voie est une réinitialisation, et c'est la bonne réponse plutôt qu'une fonctionnalité manquante.
Authentification à deux facteurs	⚙	Construite et livrée dans chaque installation, avec les codes d'application d'authentification standard (TOTP) qui fonctionnent avec Google Authenticator, Authy, 1Password et les autres. Une personne peut inscrire un appareil elle-même, et les appareils de confiance peuvent être mémorisés pour une période. Vous fixez : si elle est facultative ou obligatoire. Un réglage l'active pour tout le monde, un autre pour tous les comptes du personnel — et quiconque n'a pas d'application d'authentification reçoit un code à usage unique par courriel, de sorte que l'imposer ne laisse personne dehors. Dans un déploiement américain, elle devrait être active : elle est attendue sous la Security Rule et devient effectivement obligatoire si la mise à jour proposée est finalisée.
Le deux-facteurs ferme aussi la porte de l'API	✓	Le détail qui la rend précieuse. Dès qu'une personne a un second facteur, son mot de passe cesse de fonctionner pour l'accès de machine à machine — une intégration doit utiliser une clé d'API nommée. Sans cette règle, l'authentification à deux facteurs protège l'écran de connexion et laisse la porte de derrière ouverte, ce qui est la façon dont on la déjoue en pratique.
Clés d'accès	⚙	Odoo 19 prend en charge les clés d'accès — connexion par empreinte digitale, visage ou clé matérielle au lieu d'un mot de passe. Rien d'hameçonnable n'est tapé : cela supprime toute la classe d'attaques où l'on persuade quelqu'un de saisir son mot de passe sur une copie convaincante de votre page de connexion. Vous décidez de l'offrir ou non.
Des clés d'API au lieu de mots de passe pour les intégrations	✓	Chaque intégration reçoit sa propre clé nommée avec sa propre portée, listée au regard de la personne qui l'a créée, révocable une par une. Une clé qui fuit est coupée sans changer le mot de passe de personne et sans casser les autres intégrations.
Politique de mot de passe	⚙	Une longueur minimale imposée au moment où un mot de passe est fixé, avec un indicateur de robustesse affiché à la saisie. Vous fixez le minimum. Il est à zéro à la sortie de la boîte, ce qui veut dire que le décider fait partie de la mise en service plutôt que d'être découvert plus tard. Il n'y a délibérément aucun réglage pour imposer des classes de caractères — une majuscule, un chiffre, un symbole. Ce n'est pas un oubli. La recherche et les directives actuelles du NIST ont toutes deux conclu que ces règles sont contre-productives : elles poussent vers des substitutions prévisibles et vers des mots de passe écrits sur un papier, et elles rapportent moins que la longueur. Longueur plus second facteur, voilà la combinaison qui marche.
Protection contre la force brute	✓	Active par défaut. Après dix tentatives échouées, chaque essai suivant est refusé pendant soixante secondes comptées depuis le dernier échec — une attaque par devinette est donc ramenée à un essai par minute plutôt qu'à des milliers. Les deux nombres sont des réglages qu'un administrateur de base peut changer (ou désactiver, en mettant le premier à zéro). Cela fonctionne sans que personne ait à remarquer l'attaque.
Réauthentification pour les actions sensibles	✓	Changer des réglages de sécurité, inscrire un second facteur ou créer une clé d'API demande à la personne de prouver à nouveau qui elle est, même en pleine session. Un écran laissé sans surveillance ne peut pas servir à affaiblir le compte auquel il est connecté.
Changer un mot de passe met fin à chaque session	✓	La validité de session découle du compte lui-même : changer un mot de passe ou désactiver un compte invalide donc toutes les sessions existantes partout à la fois — chaque navigateur, chaque appareil, immédiatement. C'est ce qui fait de « quelqu'un est parti, coupez-lui l'accès » une seule action plutôt qu'un espoir.
Connexion d'entreprise, si vous l'utilisez	⚙	Odoo peut s'authentifier auprès de votre annuaire existant (LDAP ou Active Directory) ou d'un fournisseur d'identité OAuth2, de sorte que les arrivées et les départs se traitent une seule fois là où votre organisation les traite déjà. Facultatif, et utile seulement si vous en exploitez déjà un.
Documents du portail derrière un second facteur	⚙	Celui-ci est à nous et non à Odoo, et il existe parce que la connexion d'un client est le point le plus faible de tout système clinique. Activez-le et un utilisateur du portail qui n'a pas inscrit de second facteur peut encore se connecter et voir que des documents existent — mais ne peut pas en ouvrir un avant de l'avoir fait. Cela touche des gens qui utilisent déjà le portail : prévenez-les avant de l'activer.

✓Active par défautEn service dès l'installation du système. ⚙Construit — vous l'activezPrésent et pris en charge. L'utiliser ou non, et avec quelle rigueur, est votre décision.

Ce que « fondé sur les rôles » veut dire ici

Presque tous les systèmes se disent fondés sur les rôles. L'expression vaut d'être décortiquée, car dans la plupart des produits cela veut dire que le menu change, et dans Odoo cela veut dire que les données changent.

Un rôle dans Odoo est un groupe. Les groupes peuvent en contenir d'autres, de sorte qu'un superviseur détient automatiquement tout ce que détient un clinicien sans que personne écrive les permissions deux fois — et quand une permission est corrigée, elle l'est une fois pour tous ceux qui en héritent. Ce qu'un groupe accorde n'est pas un écran. Ce sont quatre permissions distinctes (lire, créer, modifier, supprimer) sur chaque sorte de dossier, plus des filtres qui décident quels dossiers de cette sorte, plus la possibilité de masquer des champs individuels.

La conséquence importante : masquer un menu n'est pas une permission. Dans un système où les rôles ne changent que le menu, quiconque apprend une adresse web atteint les données derrière. Dans Odoo, les vérifications vivent dans la couche de données, de sorte que le même refus survient que le dossier soit atteint par un écran, un rapport, un export, une recherche ou l'API distante. Aucune route ne les saute.

01Les rôles portent le nom du métier

Clinicien traitant, superviseur, directeur de clinique, dépositaire des dossiers, accueil, responsable de la vie privée, comptable, gestionnaire de contrats. L'accueil, c'est la démographie seulement — aucun contenu clinique et aucun accès aux documents, d'aucune sorte.

Répond à« Montrez-moi ce qu'un réceptionniste peut voir »

02Les rôles accordent une portée, jamais un contenu

Détenir le rôle de clinicien n'ouvre le dossier d'aucun client en soi. C'est la relation de soins qui le fait. C'est la phrase la plus importante de ce site au sujet de l'accès.

Répond à« Un thérapeute peut-il lire les dossiers de toute la clinique ? »

03Quatre permissions, pas une

Lire, créer, modifier et supprimer sont distinctes pour chaque sorte de dossier. Lire sans modifier est courant à dessein : bien des rôles doivent voir quelque chose qu'ils ne doivent pas changer.

Répond à« Qui peut modifier une facture après son émission ? »

04Des filtres de ligne décident quels dossiers

« Vos propres clients », « votre propre société », « les réservations qui vous appartiennent ». Appliqués à chaque requête, ils tiennent donc pour les listes, les rapports, les exports et l'API indifféremment.

Répond à« Qu'est-ce qui empêche un export de tout tirer ? »

05Les règles globales ne peuvent pas être élargies

Une règle attachée à aucun groupe s'applique à tout le monde et se combine à toutes les autres : elle restreint donc l'accès et ne peut jamais être contournée en ajoutant un rôle. La séparation entre sociétés est bâtie ainsi.

Répond à« Une clinique peut-elle voir les données d'une autre ? »

06Des champs individuels peuvent être masqués

Deux personnes peuvent ouvrir le même dossier et en voir des quantités différentes. Utilisé ici pour les chiffres de coût et de marge, et pour les champs que seul un dépositaire des dossiers devrait lire.

Répond à« Tous ceux qui voient un contrat voient-ils sa marge ? »

07Les clients sont une classe d'utilisateurs à part

Un utilisateur du portail n'a aucun accès au back-office — pas une vue restreinte, rien du tout. Il n'atteint que les pages publiées pour lui. Les pages web publiques tournent sous un utilisateur anonyme à qui presque rien n'est accordé.

Répond à« Quel est le pire cas si une connexion client est volée ? »

08Chaque route déclare son propre accès

Chaque adresse web de ce déploiement indique si elle exige un utilisateur connecté ou si elle est délibérément publique : 174 exigent une connexion, 57 sont publiques à dessein. Rien n'est public par accident.

Répond à« Lesquelles de vos URL fonctionnent sans connexion ? »

09C'est de la configuration lisible

Les permissions sont livrées comme fichiers texte dans chaque module. Votre propre équipe de sécurité peut lire qui obtient quoi sans exécuter le système, et en comparer les versions.

Répond à« Pouvons-nous auditer les permissions nous-mêmes ? »

Une base par clinique, et aucun passage

Vos données vivent dans une base qui leur est propre. Ce n'est pas une table partagée avec une colonne client, l'arrangement où une requête erronée renvoie les dossiers de quelqu'un d'autre.

Odoo impose cette séparation à la connexion : une requête porte un nom d'hôte, le nom d'hôte sélectionne exactement une base, et il n'existe aucun chemin d'une base vers une autre tournant sur le même serveur. Rien dans l'application ne peut adresser une base à laquelle elle n'a pas été connectée. Par-dessus cela, les écrans qui créent, copient, restaurent et suppriment des bases entières sont fermés en production, de sorte que personne parcourant le serveur ne peut énumérer ce qui s'y trouve.

À l'intérieur de votre propre base, une seconde couche fait le même travail entre sociétés : si vous exploitez plus d'une clinique sur une installation, la séparation entre sociétés est écrite comme règles globales — celles qui s'appliquent à tous et ne peuvent jamais être élargies en ajoutant un rôle.

Le Top Ten de l'OWASP, et la position d'Odoo sur chacun

L'Open Web Application Security Project publie la liste des façons les plus courantes dont les applications web sont attaquées. C'est la liste qu'un auditeur en sécurité parcourt, la voici donc avec la réponse d'Odoo à chacune. Le motif à remarquer, c'est que la plupart sont empêchées par la conception du cadriciel plutôt que par le soin que les développeurs pensent à prendre — et c'est le seul genre de prévention qui survive à une échéance.

L'attaque	Statut	Pourquoi elle ne marche pas ici
Injection, en particulier SQLune entrée hostile traitée comme une commande	✓	Le code applicatif n'écrit pas de requêtes à la main. Elles sont bâties par le cadriciel à partir de filtres structurés, chaque valeur étant transmise séparément de la requête elle-même, de sorte qu'un texte saisi ne peut jamais devenir une partie de la commande. Un développeur devrait sortir de son chemin pour écrire une requête brute, et les modules cliniques ne le font pas.
Script intersitesun texte enregistré par une personne s'exécute comme du code pour une autre	✓	Tout ce qui est rendu dans une page est échappé par défaut. Mettre du contenu brut dans une page doit être demandé explicitement et se voit dans le code quand c'est fait. Le défaut est sûr : oublier produit donc quelque chose de laid plutôt que quelque chose de dangereux.
Falsification de requête intersitesun autre site soumet un formulaire sous votre identité connectée	✓	Tout formulaire qui modifie des données doit porter un jeton lié à la session de cette personne, et le serveur refuse une soumission sans lui. Le jeton n'existe que parce que la personne a vraiment chargé votre page, et le site d'un attaquant ne peut pas l'obtenir.
Exécution de fichier malveillantfaire exécuter au serveur du code que vous avez fourni	✓	Il n'existe aucune fonctionnalité qui inclue un fichier distant. Là où des utilisateurs privilégiés peuvent écrire de petites expressions pour adapter le comportement, celles-ci tournent dans un bac à sable qui bloque l'accès au système de fichiers, au réseau, et à tout ce dont le nom commence par un double tiret bas — une liste délibérément courte d'opérations permises plutôt qu'une liste d'interdits.
Référence directe non sécurisée à un objetchanger un nombre dans une URL pour atteindre le dossier de quelqu'un d'autre	✓	C'est celle qui prend la plupart des systèmes, et la réponse d'Odoo est structurelle : le contrôle d'accès n'est pas implémenté dans les écrans. Changer un numéro de dossier dans une adresse web atteint la même vérification de la couche de données que tout le reste, et y est refusé. Il n'y a aucun risque à ce qu'une référence soit visible, parce que ce n'est pas la référence qui accorde l'accès.
Absence de restriction d'accès aux URLatteindre une page en connaissant son adresse	✓	La même réponse, et elle vaut d'être dite deux fois parce que c'est la différence entre un vrai contrôle d'accès et un menu bien rangé. La sécurité ici ne repose pas sur un lien caché. Là où une page doit vraiment fonctionner sans connexion — un client confirmant un rendez-vous depuis un courriel — l'adresse porte un jeton signé unique à ce dossier et à cette personne.
Stockage cryptographique non sécurisédes identifiants faiblement protégés, ou pas du tout	✓	Les mots de passe sont hachés avec PBKDF2-SHA512 et étirement de clé, comme décrit plus haut, et peuvent être évités localement en s'authentifiant auprès de votre propre annuaire ou fournisseur d'identité. Les documents cliniques vont encore plus loin : chiffrés par version sous des clés tenues hors de la base.
Communications non sécuriséesdu trafic envoyé en clair	✓	Connexions chiffrées de bout en bout, avec les requêtes non chiffrées redirigées plutôt que servies, et des en-têtes de navigateur qui refusent un retour en arrière. Comme cette plateforme est auto-hébergée, celui-ci est un contrôle de déploiement plutôt qu'une propriété du logiciel — il est mis en place dans le cadre d'une installation standard et décrit à la section 07.
Atteindre les rouages internes par l'APIappeler quelque chose qui n'était jamais censé être appelé	✓	Pas sur la liste de l'OWASP, mais à ajouter, parce que c'est celui que les gens supposent être une faille. L'API distante refuse d'appeler toute méthode interne — tout ce dont le nom commence par un tiret bas, plus une liste nommée de méthodes dangereuses. Seules les méthodes publiées délibérément sont atteignables depuis l'extérieur, ce qui limite fortement ce qu'une erreur dans le code applicatif peut exposer.

Le code ouvert, et ce qu'il vaut réellement

« Code ouvert » se dit souvent comme si c'était en soi une fonctionnalité de sécurité. Ce n'en est pas une. Ce qu'il vous donne est précis et mérite d'être nommé exactement.

Vous pouvez vérifier au lieu de croire

Chaque ligne d'Odoo Community et chaque ligne des modules cliniques peuvent être lues par votre propre équipe de sécurité ou par des testeurs que vous engagez. Les permissions sont livrées comme fichiers texte. Rien sur cette page n'a à être pris sur parole, ce qui est une position différente de celle d'un produit fermé où les mêmes affirmations ne peuvent qu'être assénées.

C'est une invitation à auditer, pas un substitut à l'audit.

Beaucoup plus de gens le regardent

Odoo est examiné en continu par des utilisateurs, des contributeurs et des chercheurs en sécurité indépendants du monde entier, et les rapports de bogues de la communauté sont une vraie source de retours de sécurité. Odoo exploite un programme de divulgation responsable et publie ses correctifs sous forme d'avis.

Son propre processus de développement comprend une revue de code où la sécurité est l'un des points revus, pour le code nouveau comme pour le code contribué.

Vous décidez quand les correctifs atterrissent

L'auto-hébergement veut dire que les correctifs de sécurité sont appliqués à votre installation à votre calendrier plutôt qu'en surgissant du jour au lendemain. C'est un avantage pour un service clinique qui doit valider les changements — et c'est aussi un devoir, parce qu'un correctif que personne n'applique ne protège personne.

Se tenir à jour figure sur la liste de l'exploitant à la section 07, et c'est la façon la plus courante dont une installation par ailleurs bien bâtie finit compromise.

Une distinction à manier avec soin

Odoo publie sa propre page de sécurité, et une partie décrit le service infonuagique d'Odoo — leurs images serveur durcies, leurs correctifs, le petit nombre de leurs ingénieurs qui peuvent atteindre une machine et seulement par une clé chiffrée depuis un portable chiffré. Ces éléments sont réels, et ils ne sont pas les vôtres, parce que cette plateforme est auto-hébergée sur votre propre infrastructure.

Tout ce qui, sur cette page, se trouve au-dessus de la ligne est une propriété du logiciel et s'applique à vous exactement tel qu'écrit. Les équivalents côté serveur — système d'exploitation durci, correctifs, qui détient l'accès SSH, chiffrement intégral des disques des machines qui l'administrent — sont à vous d'exploiter, et ils sont exposés honnêtement à la section 07, y compris les parts qui reviennent à qui exploite les serveurs. Lire la page infonuagique d'Odoo en supposant qu'elle décrit votre déploiement est l'erreur la plus courante au sujet d'Odoo auto-hébergé, et c'est le genre de chose qui se défait dans une vérification diligente.

Où le modèle d'Odoo s'arrête et où le modèle clinique commence

Les quatre couches d'Odoo sont solides, bien éprouvées et suffisantes pour des données d'affaires ordinaires. Elles ne suffisent pas à elles seules pour un dossier clinique, pour une raison : ce sont des configurations, et une configuration peut être changée par quelqu'un qui a le bon rôle. C'est pourquoi les documents cliniques sont chiffrés en plus sous des clés tenues hors de la base, et pourquoi les notes de psychothérapie utilisent encore une autre clé. Si toutes les règles Odoo du système étaient fausses demain, le contenu chiffré ne s'ouvrirait toujours pas.

07 — Le serveur

Comment la machine elle-même est durcie

La sécurité applicative ne compte que si le serveur en dessous est correctement fermé. La plateforme est auto-hébergée, ce qui veut dire qu'elle tourne sur une infrastructure que vous contrôlez plutôt que sur le nuage d'un fournisseur. C'est un vrai avantage pour un service de santé, et cela vient avec un vrai devoir : le durcissement ci-dessous fait partie de l'installation, et il faut qu'il reste vrai ensuite.

Tout ce qui figure dans le premier tableau est mis en place dans le cadre d'un déploiement standard et documenté dans les guides d'installation. Le second tableau est la part qui revient à qui exploite les serveurs.

Domaine	Comment c'est configuré	Pourquoi c'est fait ainsi
Rien n'est exposé directement	Les services applicatifs n'écoutent que sur la machine elle-même. Tout le trafic extérieur arrive par un proxy inverse nginx, la seule chose sur un port public	Une seule porte d'entrée au lieu de plusieurs. Certificats, en-têtes, limites et journalisation s'appliquent tous au même endroit
Chiffrement en transit	Certificats TLS de Let's Encrypt, émis et renouvelés automatiquement. Le HTTP simple est redirigé vers HTTPS plutôt que servi	Il n'y a aucun chemin non chiffré, même par erreur, et le renouvellement n'est pas une chose qu'une personne doit se rappeler
En-têtes de sécurité du navigateur	Strict-Transport-Security pendant un an, X-Frame-Options réglé sur same-origin, X-Content-Type-Options réglé sur nosniff	Le navigateur refuse de redescendre en HTTP, refuse que le site soit encadré par un autre site, et refuse de deviner les types de fichiers
Pare-feu	Seuls les ports 80 et 443 sont ouverts au monde. Les ports applicatifs, la base et Redis ne sont pas joignables depuis l'extérieur de la machine	La base n'est jamais adressable depuis Internet. Un téléphone est à au moins deux sauts de toute ligne
Limitation de débit	Des limites au proxy sur les requêtes entrantes, plus des seaux à jetons tenus dans Redis à l'intérieur de la passerelle pour les routes publiques et les lectures de documents du portail	Le proxy arrête les déferlements. Les compteurs Redis tiennent sur plusieurs processus serveur, de sorte qu'une limite par utilisateur veut dire ce qu'elle dit
Un nom d'hôte, une base	Odoo est configuré pour que le nom d'hôte de la requête sélectionne exactement une base, et les écrans de gestion des bases sont fermés	Personne parcourant le serveur ne peut lister, copier, restaurer ou supprimer une base
Des services, pas des interpréteurs	La passerelle et Odoo tournent comme services système gérés sous leurs propres comptes, démarrés automatiquement et redémarrés en cas de panne	Rien ne tourne sous un compte d'administrateur, et un redémarrage ne dépend pas de la présence de quelqu'un en session
Les secrets restent sur le serveur	Les clés de signature et les identifiants tiers vivent dans un fichier d'environnement lisible seulement par le compte de service. L'application mobile n'en embarque aucun	L'application peut être décortiquée sans que rien ne soit appris. Un identifiant renouvelé prend effet pour tout le monde d'un coup, sans version d'application
Les documents chiffrés vivent à part	Le texte chiffré est écrit dans son propre répertoire avec ses propres permissions, hors du stockage de fichiers ordinaire d'Odoo, et n'est jamais servi par la route de téléchargement ordinaire	Un serveur web mal configuré ne peut pas publier accidentellement des fichiers cliniques
La clé maîtresse est vérifiée au démarrage	Le module de chiffrement lit la clé à un chemin qui lui est propre et refuse de démarrer si le fichier est absent, lisible par tous, détenu par le mauvais compte, ou placé dans un répertoire sauvegardé avec les données	La défaillance de clé la plus courante dans le monde réel, c'est la clé qui finit dans la même sauvegarde que les données qu'elle protège. Le logiciel le vérifie au lieu de se fier à une procédure
Le WebSocket sur le même canal	La discussion, la présence et la signalisation d'appel passent par le même proxy et le même certificat que tout le reste	Une connexion, une politique, pas de second écouteur à sécuriser séparément
Traçage des requêtes	Chaque requête porte un identifiant à travers la passerelle et le ressort dans les en-têtes de réponse, avec sa durée	Un incident peut être reconstitué d'un service à l'autre au lieu d'être deviné depuis des fichiers de journal séparés

Le durcissement qui revient à qui exploite les serveurs

Ce ne sont pas des manques du logiciel. Ce sont des décisions et des routines que seul l'exploitant peut prendre, et aucun fournisseur ne peut les prendre pour vous. Elles sont listées franchement pour que personne ne les suppose couvertes.

Correctifs du système d'exploitation. Un calendrier de mises à jour de sécurité sur l'hôte, et quelqu'un dont le travail est de confirmer qu'elles ont été appliquées.
Chiffrement du disque de l'hôte. Les documents sont chiffrés individuellement par la plateforme, mais le chiffrement intégral du disque protège tout le reste sur la machine, y compris les journaux et les fichiers temporaires.
Les sauvegardes, et leur chiffrement. Où vont les sauvegardes, comment elles sont chiffrées, qui peut les restaurer, et combien de temps on les garde. Une sauvegarde est une copie complète de vos données sans aucune de vos règles d'accès attachée.
La clé maîtresse est sauvegardée à part. Si la clé est perdue, chaque document chiffré est perdu définitivement — c'est tout l'objet de la conception. Elle doit être sauvegardée, et elle ne doit pas l'être à côté des données.
Accès administratif au serveur. Des clés SSH plutôt que des mots de passe, pas de connexion root directe, une liste de qui détient l'accès, et son retrait le jour où quelqu'un part.
Tests de restauration. Une sauvegarde que personne n'a jamais restaurée est un espoir, pas un contrôle. Testez-la selon un calendrier et écrivez que vous l'avez fait.
Surveillance et alertes. Quelqu'un doit être prévenu quand un service s'arrête, qu'un disque se remplit, qu'un certificat va expirer, ou qu'une tâche de conservation planifiée cesse de tourner.
Authentification multifacteur pour les comptes du personnel. Fortement recommandée pour quiconque atteint du contenu clinique, et effectivement exigée si la mise à jour proposée de la HIPAA Security Rule est finalisée. Confirmez avec votre administrateur qu'elle est active dans votre déploiement.
Placement réseau. Si la base se trouve sur la même machine ou sur une autre, ce qui peut l'atteindre, et si l'administration se fait par un réseau privé ou un VPN.
Tests d'intrusion. Le parc est à code ouvert et auto-hébergé précisément pour que vos propres testeurs puissent l'examiner correctement. C'est une invitation, pas un substitut au fait de le faire.

08 — Défense en profondeur

Quatre couches, et chacune refuse quelque chose que la suivante ne voit jamais

La défense en profondeur, c'est ne dépendre d'aucune protection unique. Une requête doit franchir les quatre couches ci-dessous. La valeur n'est pas qu'aucune d'elles ne soit impossible à briser. C'est qu'elles échouent de façons différentes, de sorte qu'une erreur dans l'une a très peu de chances d'être une erreur dans les quatre.

1 · Appareil et surface Ce qu'une personne tient dans la main Non fiable

Aucun secret sur l'appareilL'application ne porte que des clés publiques. On peut la décortiquer sans rien apprendre.

Connexion biométrique et verrou d'applicationPar-dessus le verrou d'écran du téléphone, pas à sa place.

Jetons en stockage sécuriséTenus dans le trousseau de la plateforme, pas dans des fichiers d'application ordinaires.

La base est inatteignableL'application ne peut pas adresser la base du tout, sur aucun réseau.

HTTPS · jeton de courte durée

2 · Passerelle Le seul back-end que l'application connaisse Détient les secrets

Chaque clé tierce vit iciLes identifiants de paiement, d'IA, de messagerie et de stockage ne quittent jamais le serveur.

Jetons signés de courte duréeChacun porte pour qui il est, quand il a été émis, quand il expire et un identifiant unique. Renouvelés plutôt que de longue durée.

Hachage des mots de passeÀ sens unique, avec un schéma renforçable sans réinitialisation.

Limitation de débitCompteurs tenus dans Redis, partagés par tous les processus serveur.

Validation des entréesLes requêtes malformées sont refusées ici, avant que le noyau d'affaires ne les voie.

Liens signés et expirantsLes médias passent par un proxy. Rien n'est servi depuis une adresse devinable.

compte de service · moindre privilège

3 · Noyau d'affaires Là où les règles vivent vraiment Faisant autorité

Groupes, droits d'accès et règles d'enregistrementLes quatre couches d'Odoo, appliquées quelle que soit la façon dont le dossier est atteint.

Résolution de l'équipe de soinsLe seul endroit qui décide qui peut ouvrir un dossier clinique.

Rôles cliniquesDécident quelle partie de l'application une personne atteint. Jamais ce qu'elle peut ouvrir.

Un grand livre non modifiableUne facture émise est figée. Une correction est un avoir.

Versions de contrat datéesLes conditions ne peuvent pas être antidatées et l'historique demeure.

chiffré au repos · clés tenues à part

4 · Stockage et clés Ce qui survit à un disque volé Cryptographie

Répertoire de texte chiffréHors du magasin de fichiers, hors de la base, avec ses propres permissions.

La clé maîtresseSur disque, détenue par le compte de service, jamais dans la même sauvegarde que les données.

Une seconde clé pour les notes de thérapieLa clé ordinaire ne les ouvre pas, quoi que disent les règles.

Journal d'audit chaîné par empreintesEn ajout seul. L'altération se détecte, elle n'est pas seulement découragée.

09 — Pratique du secteur de la santé

Les contrôles qu'un auditeur clinique demande spécifiquement

Les pare-feu et le chiffrement sont attendus de tout système. Les neuf ci-dessous sont ceux qui reviennent dans une revue de santé mentale en particulier, et qu'un gestionnaire de documents généraliste ne sait pas exprimer du tout. Chacun est écrit avec la question auquel il répond, parce que c'est d'ordinaire sous cette forme qu'il arrive.

01Relations de soins

Un lien consigné entre un clinicien et un client, avec un type, un début et une fin. Quand la relation prend fin, l'accès aussi, après un délai de grâce assez long pour finir les notes en cours.

Répond à« Comment appliquez-vous le minimum nécessaire ? »

02Dépôt auprès du directeur

Les incidents, les plaintes et les signalements de protection vont au directeur de la clinique et sont fermés à la personne qui les a déposés, et à toute personne visée par la plainte.

Répond à« Un membre du personnel peut-il lire la plainte qui le vise ? »

03Les demandes de droits comme flux

Les demandes d'accès portent leur échéance légale. Les demandes de modification ajoutent une version au lieu d'écraser. Les demandes de restriction scellent les documents qu'elles couvrent.

Répond à« Montrez-moi une demande d'accès du début à la fin »

04Registre des communications

Ce qui est sorti du service, vers qui, et sur quel fondement juridique. C'est la trace dont une personne a le droit de demander six ans aux États-Unis.

Répond à« Avec qui avez-vous partagé les données de cette personne ? »

05Ancrages de conservation

Le dernier contact, la date de naissance et la date de décès sont stockés comme dates à compter desquelles compter, parce qu'une règle écrite en années n'a aucun sens sans point de départ.

Répond à« Comment savez-vous quand détruire ceci ? »

06Des relances par statut, jamais par contenu

Les comptes rendus de séance en retard se trouvent par leur échéance et leur état. Un gestionnaire peut voir qu'un compte rendu manque sans en ouvrir un qui ne manque pas.

Répond à« Les gestionnaires lisent-ils des notes cliniques pour faire tourner la clinique ? »

07Vérifications d'identité et d'âge

Une vérification faciale automatique d'abord, puis une file de revue humaine au besoin. Les pièces d'identité sont chiffrées pendant leur détention et supprimées automatiquement une fois la vérification terminée.

Répond à« Qu'advient-il de la pièce d'identité ensuite ? »

08Signature électronique clinique

Attestation de capacité, signature au nom d'un client, contresignature du superviseur, et un consentement qui peut être retiré ensuite plutôt qu'une case cochée une fois pour toutes.

Répond à« Comment le consentement est-il recueilli, et peut-il être retiré ? »

09La signature reste à la maison

Le service de signature tourne sur vos propres serveurs avec sa propre piste chaînée par empreintes. Aucun document n'est envoyé à une entreprise extérieure pour être signé, et il n'y a pas de facture fournisseur par signature.

Répond à« Quels tiers voient nos documents signés ? »

10 — Si quelque chose tourne mal

Deux échéances à partir d'un seul instant, et une exemption qu'il faut mériter

Le chiffrement a la forme qu'il a en grande partie à cause de cette section. Le RGPD comme HIPAA admettent que des données correctement chiffrées sont illisibles, et donc pas vraiment une divulgation. Mais cette exemption ne tient que si vous pouvez montrer que les clés n'ont pas été prises aussi. Toute la conception de la garde des clés existe pour que vous puissiez le montrer.

Heure zéro La prise de connaissance

Les deux échéances ci-dessous courent depuis le moment où vous en prenez connaissance, pas depuis celui où l'incident est survenu. Établir et consigner ce moment est donc la première chose à faire, plutôt que quelque chose à reconstituer plus tard.

Dans les 72 heures · UE et RU Prévenir le régulateur

L'article 33 du RGPD vous donne 72 heures à compter de la prise de connaissance pour notifier l'autorité de contrôle — l'ICO au Royaume-Uni, l'autorité nationale compétente dans l'Union européenne. Cette échéance s'applique que les données aient été chiffrées ou non.

Sans retard injustifié · sauf Prévenir les personnes touchées

L'article 34 exige que vous préveniez aussi les personnes, sauf si les données étaient chiffrées. L'article 34(3)(a) tient des données correctement chiffrées pour illisibles par qui les a prises. HIPAA a la même idée et l'appelle la sphère de sécurité.

La condition de cette exemption Les clés ont-elles été prises aussi ?

L'exemption dépend entièrement de cette seule question : le système la pose donc explicitement, et une question sans réponse compte contre l'exemption. Clore une atteinte comme non notifiable exige la preuve, parce qu'une exemption revendiquée sans preuve est une exemption qui s'effondre à l'examen.

Comment c'est bâti Une trace d'atteinte, commune, avec les règles de chaque pays par-dessus

La trace d'atteinte elle-même est dans le noyau commun : quand vous en avez pris connaissance, ce qui était en cause, qui était touché, si les données étaient chiffrées et si les clés ont été prises. Chaque module de juridiction ajoute ensuite ses propres obligations sur cette unique trace. Le module européen ajoute l'échéance de 72 heures de l'article 33 et la décision de l'article 34. Le module américain ajoute l'évaluation de risque à quatre facteurs, l'échéance individuelle de 60 jours, le seuil médias au-delà de 500 résidents d'un même État, et le signalement au Department of Health and Human Services. Un incident, évalué une fois, au regard des règles qui vous concernent.

Tout du long Le journal d'accès est l'enquête

Parce que chaque lecture a été journalisée avant que le moindre contenu ne soit remis, la question « qu'est-ce qui a réellement été exposé, et à qui ? » a une vraie réponse plutôt qu'une estimation. C'est la différence entre prévenir onze personnes et prévenir tout le monde dans la base.

11 — Contrôles de la plateforme

Les questions ordinaires, répondues au même endroit

Rien dans ce tableau n'est inhabituel. Il est là parce qu'un auditeur posera la question, et parce qu'un fournisseur qui ne sait pas y répondre vite ne sait d'ordinaire pas répondre aux plus difficiles non plus.

Domaine	Ce qui est en place	Pourquoi c'est fait ainsi
Connexion	Mots de passe stockés seulement comme empreintes à sens unique. Jetons signés de courte durée portant qui est l'utilisateur, quand le jeton a été émis, quand il expire et un identifiant unique	Un jeton volé expire de lui-même, et le hachage peut être renforcé sans demander à personne de réinitialiser son mot de passe
Garde des secrets	Chaque identifiant tiers vit sur le serveur. L'application mobile ne porte que des clés publiques	L'application peut être décompilée sans que rien ne soit perdu. Renouveler une clé prend effet pour tous les utilisateurs d'un coup, sans publication sur une boutique d'applications
Transport	HTTPS partout, y compris le WebSocket utilisé pour la discussion, la présence et la signalisation d'appel	Une connexion, une politique, et aucun repli en clair
Limitation de débit	Des limites au proxy, plus des compteurs Redis sur les routes publiques et sur les lectures de documents du portail	Comptés depuis un état partagé, de sorte qu'une limite par utilisateur tient sur tous les processus serveur plutôt que par processus
Médias	Passés par la passerelle avec des liens signés qui expirent. Rien n'est servi depuis un chemin devinable	Le stockage n'est jamais adressé directement par un appareil client
Base de données	Inatteignable depuis tout client. La passerelle se connecte au noyau par un compte de service n'ayant que les droits nécessaires	Deux sauts distincts entre un téléphone et une ligne, chacun avec sa propre occasion de refuser
Formulaires publics	reCAPTCHA sur les formulaires du site, et numéros de téléphone normalisés à la saisie	Le pourriel et les entrées malformées sont refusés avant de devenir des enregistrements que quelqu'un devra nettoyer
Deviner des références	Un document que vous ne pouvez pas voir renvoie « introuvable », jamais « interdit »	Sinon, la différence entre les deux réponses dit à un attaquant quels dossiers existent
Comptes clients	Les utilisateurs du portail n'ont aucun accès au back-office. L'authentification à deux facteurs est livrée avec la plateforme et peut être rendue obligatoire pour tout le personnel, ou pour tout le monde, avec un seul réglage — et l'accès aux documents du portail peut être placé derrière elle	Le pire cas pour une connexion client compromise, ce sont les données de ce seul client, et avec la barrière du portail activée, pas même cela
Exposition aux tiers	Les paiements, l'intelligence artificielle, la messagerie et le stockage sont chacun derrière une interface avec une version simulée de l'autre côté d'un interrupteur	Les fournisseurs peuvent être remplacés. Les démonstrations et les tests tournent sans compte fournisseur réel et sans aucune donnée réelle
Licences et hébergement	Odoo 19 Community et des composants à code ouvert de bout en bout, tournant sur votre propre infrastructure	Votre propre équipe de sécurité peut lire le code au lieu de croire un fournisseur sur parole

12 — Ce que vous pouvez prouver

La différence entre un contrôle et une promesse

Dans un audit, un appel d'offres ou une plainte, ce qui compte n'est pas ce que vous aviez l'intention de faire. C'est ce que vous pouvez démontrer. Voici les six questions qui reviennent le plus souvent, et ce que le système produit en réponse à chacune.

Qui a lu ce dossier ?Journal d'accès

Une liste complète, chaînée par empreintes, que personne n'a pu modifier — y compris vos propres administrateurs

Ce dossier a-t-il été altéré ?Historique des versions

Les corrections sont de nouvelles versions et la précédente est intacte : un changement est donc visible plutôt que déduit

Les données expirées ont-elles été détruites ?Destruction de la clé

La clé a disparu, et la coquille vide du dossier prouve que le fichier a existé et a été détruit dans les temps

Avec qui l'avons-nous partagé ?Registre des communications

Ce qui est sorti du service, vers qui et sur quel fondement juridique — six ans, sur demande

Un administrateur aurait-il pu le voir ?Modèle d'autorisation

Fermé par défaut, sans dérogation maîtresse. Un compte admin n'accorde rien, et l'accès d'urgence est un événement journalisé et revu

Le grand livre est-il digne de confiance ?Contrôles financiers

Les factures émises ne peuvent pas être modifiées, les lignes de paie portent la version de contrat qui les a tarifées, et rien n'est facturé sans qu'une personne le confirme

13 — Où le logiciel s'arrête

Ce qu'aucune plateforme ne peut faire pour vous

Un logiciel ne rend pas une organisation conforme. Il rend la conformité atteignable, et il permet de la prouver. Être franc sur cette limite vaut mieux dans une revue qu'une plus longue liste d'affirmations : voici donc la limite en entier.

Ceci n'est pas un conseil juridique, et aucun produit n'est certifié

Rien sur cette page n'est un conseil juridique. Aucun logiciel n'est certifié HIPAA ni certifié RGPD, parce qu'aucune autorité ne délivre ces certificats pour des produits. Ce qui existe, c'est un ensemble de contrôles techniques et organisationnels. Cette plateforme met en œuvre les techniques et soutient les organisationnels. Le reste revient à votre organisation, et un bon conseiller vous dira exactement la même chose.

Les ententes sont à vous de signer. Les business associate agreements aux États-Unis, les accords de sous-traitance et les conditions de sous-traitance ultérieure dans l'UE et au Royaume-Uni. La plateforme les modélise. Elle ne les conclut pas pour vous.
Vos avocats confirment le libellé. L'avis de retransmission du 42 CFR Part 2 est généré plutôt que tapé, précisément pour qu'il ne dérive pas avec le temps. Mais le règlement en prescrit le contenu, et il exige une relecture juridique avant la mise en service.
Le droit local va plus loin que le socle. Les lois d'État américaines — la CMIA californienne, et des règles à New York et au Texas entre autres — vont au-delà de HIPAA. Dans l'UE, le droit des États membres s'ajoute au RGPD : le § 203 StGB et le § 630f BGB allemands en sont des exemples. Les durées de conservation en particulier doivent être confirmées auprès d'un avocat de votre pays.
Le comportement du personnel n'est pas un contrôle logiciel. La formation, les arrivées et les départs, la procédure disciplinaire, et le choix de qui reçoit une relation de soins sont des décisions que le système consigne mais ne prend pas.
La sécurité physique et d'infrastructure revient à l'exploitant. Où sont les serveurs, qui peut s'en approcher, comment les sauvegardes sont chiffrées et stockées hors site, comment la clé maîtresse est détenue, et le test de reprise que vous faites réellement plutôt que celui qui figure dans le plan.
Les tests d'intrusion et la gestion des vulnérabilités sont un programme, pas une fonctionnalité. Le parc est à code ouvert et auto-hébergé pour que votre propre équipe ou vos propres testeurs puissent l'examiner correctement. C'est une invitation, pas un remplacement.
Les organisations liées au NHS remplissent le Data Security and Protection Toolkit. Cette évaluation porte sur votre organisation et ses gens, et sort du champ de tout logiciel.
Quelqu'un doit surveiller le moteur de conservation. La conservation et la destruction tournent comme tâches planifiées. Une tâche planifiée qui cesse discrètement de tourner est un problème de conformité qui ne se révèle qu'en audit, et c'est pourquoi la vérifier figure à la routine mensuelle.

Toute la page en un paragraphe, pour un auditeur pressé

Les dossiers cliniques sont chiffrés une version à la fois, sous des clés tenues hors de la base. Ils ne s'ouvrent que lorsqu'une règle explicite l'autorise, et cette règle suit la relation de soins plutôt que l'ancienneté. Chaque lecture est écrite dans un journal que personne ne peut modifier. Les corrections s'ajoutent comme nouvelles versions au lieu d'écraser l'ancienne. Quand la conservation expire, la clé est détruite, ce qui rend le contenu illisible tout en laissant la preuve qu'il a existé et a été détruit. Sur ce même noyau, un module de juridiction ajoute la machinerie des droits et de la gouvernance pour les États-Unis, l'Union européenne ou le Royaume-Uni. En dessous, le modèle d'accès à quatre couches d'Odoo Community protège les données d'affaires ordinaires, et le serveur est fermé derrière un proxy unique avec TLS, un pare-feu et des limites de débit.

14 — Où aller ensuite

Le reste du tableau

Cette page est la position de sécurité et de conformité. La vue d'ensemble montre comment les pièces s'emboîtent, le catalogue liste les modules où ces contrôles vivent vraiment, et le plan de l'administrateur couvre la routine qui garde toutes ces preuves vraies mois après mois.

La machineVue d’ensemble du systèmeQuatre couches, et où les secrets et les dossiers se trouvent vraiment. RéférenceCatalogue des modulesLes modules de documents sécurisés, de dossiers cliniques et de signature électronique en entier. PlanAdministrateurLe dossier de conformité, les vérifications de conservation et la revue trimestrielle. PlanClientCe qu'on dit à un client sur ses propres dossiers, et ce qu'il peut demander.