Politique de confidentialité — « Carnet »

Cette page reproduit le texte intégral de la politique que l'application fait accepter, et elle est régénérée depuis ce texte à chaque mise en ligne. Version de l'app en ligne : v1.5.1 (déployée le 11.10.2026).

Cette politique décrit ce que le logiciel FAIT réellement, dans son état à la date indiquée ci-dessous. Elle est tenue à jour à chaque évolution du produit : quand le logiciel change, ce texte change dans la même livraison.

Éditeur / responsable de la présente politique David Lambrecht, entreprise individuelle (raison individuelle) non inscrite au registre du commerce, n° IDE CHE-457.668.373, Rue du Bourg 55, 3960 Sierre (canton du Valais), Suisse. Contact protection des données : — téléphone : +41 77 276 96 99. L'éditeur est établi en Suisse : la désignation d'un représentant en Suisse au sens de l'art. 14 LPD, qui ne vise que les responsables dont le siège ou le domicile est à l'étranger, est sans objet.

Responsable de la protection des renseignements personnels (Québec, art. 3.1 de la Loi sur la protection des renseignements personnels dans le secteur privé, RLRQ c. P-39.1) : David Lambrecht, éditeur, personne ayant la plus haute autorité au sein de l'entreprise — , +41 77 276 96 99, Rue du Bourg 55, 3960 Sierre, Suisse.

Vente hors de Suisse. Hors de Suisse, le service géré est vendu par Paddle.com Market Limited, revendeur officiel, dans les pays que la page de prix dit ouverts. Vous payez par carte, dans le formulaire de paiement de Paddle, que le module de paiement de Paddle (Paddle.js) affiche sur la page carnet.health/paiement/ ; Paddle recueille lui-même vos données de paiement ; l'éditeur ne transmet à Paddle que l'identifiant opaque de votre compte de synchronisation (section 5.3). En Suisse, l'éditeur vend lui-même, par facture QR. En France, le service géré n'est pas vendu (5.3).

Version : 2026-10-12, en vigueur depuis le 12 octobre 2026 (remplace les versions antérieures, dont 2026-10-11, 2026-10-10, 2026-10-09, 2026-10-08, 2026-10-03, 2026-09-28, 2026-09-24c, 2026-09-24b, 2026-09-24, 2026-09-23c, 2026-09-23b, 2026-09-23, 2026-09-10, 2026-09-09, 2026-08-20 et 2026-08-07). Droit applicable : droit suisse (LPD RS 235.1, OPDo RS 235.11).

RGPD. L'éditeur est établi en Suisse. Il offre le service géré à des professionnelles qui exercent dans les pays de l'Espace économique européen (Union européenne, Islande, Liechtenstein, Norvège) que la page de prix dit ouverts : le règlement (UE) 2016/679 (RGPD) s'applique donc aux traitements liés à cette offre (art. 3 § 2 let. a RGPD), et, au Royaume-Uni, le RGPD tel que repris en droit britannique. La section 8 bis réunit ce que ces textes exigent de vous dire. L'éditeur n'a pas désigné de représentant dans l'Union au sens de l'art. 27 RGPD (ni au Royaume-Uni) : adressez-vous directement à lui (section 13.1).

Argentine, Chili, Panama, Uruguay. L'éditeur offre aussi le service géré à des professionnelles qui exercent en Argentine, au Chili, au Panama et en Uruguay. Pour les traitements liés à cette offre, il applique, dans la mesure de leur champ, la loi argentine 25.326 sur la protection des données personnelles ; la loi chilienne 19.628, puis, dès son entrée en vigueur, la loi chilienne 21.719, qui s'applique aussi au responsable établi à l'étranger qui offre des services à des personnes qui se trouvent au Chili (art. 1 bis) ; la loi uruguayenne 18.331, qui s'applique notamment au responsable étranger qui offre des services à des habitants de l'Uruguay (loi 19.670, art. 37) ; et la loi panaméenne 81 de 2019. La section 8 ter réunit ce que ces lois exigent de vous dire.

Ce que cette version ajoute : elle précise qu'il n'est plus possible d'ajouter un contact de secours ; un contact déjà désigné reste révocable (section 4.4). Rien d'autre ne change.

Ce que la version du 11 octobre 2026 a ajouté : la facturation au tarif 334, en tiers payant, des soins pris en charge par l'assurance-accidents (LAA), l'assurance-invalidité (AI) ou l'assurance militaire (AM) : la facture part à l'assureur du cas avec le n° de sinistre ou le n° de décision AI, chacune sur sa base légale, et le patient en reçoit une copie en AI, comme en LAMal (sections 2.1, 3, 4.3, 5.1 et 5.2) ; elle précise que la transmission de la facture à MediData est régie par les conditions d'utilisation de MediData (section 5.2). Elle ne changeait rien d'autre.

Ce que la version du 9 octobre 2026 a ajouté : la vente du service géré hors de Suisse par Paddle, revendeur officiel (sections 1.5, 2.2, 3 et 5.3), avec la page de paiement carnet.health/paiement/, seule page de Carnet qui charge un script tiers (2.4, 5.3, 12.1) ; les mentions du RGPD pour les professionnelles de l'Espace économique européen et du Royaume-Uni (section 8 bis), et celles des lois de l'Argentine, du Chili, du Panama et de l'Uruguay (section 8 ter) ; la sortie du contrat et l'effacement attesté tels qu'ils sont codés (7.5, 7.6) ; le journal lisible et le fichier des métadonnées de votre compte (8.2). Elle ne changeait rien pour la Suisse.

En un paragraphe (l'essentiel)

« Carnet » est une application web progressive (PWA) de tenue du dossier de soins et de facturation pour les professionnel·le·s de santé indépendant·e·s. Elle est conçue selon une architecture « zero-knowledge » (à connaissance nulle) : l'intégralité de votre dossier est chiffrée sur votre appareil, avec des clés dérivées de vos seuls secrets (mot de passe, clé de secours, éventuellement biométrie). L'éditeur n'a aucun accès aux données en clair — il ne peut ni les lire, ni réinitialiser votre mot de passe ; la seule récupération possible passe par VOS secrets (clé de secours, ou Feuille de récupération recombinée sur votre appareil), jamais par l'éditeur seul. Le service de synchronisation, optionnel, ne détient que des blocs chiffrés opaques et un identifiant de compte opaque. Il n'y a ni traçage, ni publicité, ni revente de données ; l'application ne charge aucun script tiers, la vitrine non plus, à la seule exception de la page de paiement carnet.health/paiement/, qui charge le module de paiement de Paddle (section 5.3). C'est le contraire d'une politique de confidentialité habituelle : nous ne « collectons » quasiment rien, parce que techniquement nous ne le pouvons pas. La présente politique décrit néanmoins avec honnêteté ce qui reste visible (des métadonnées techniques), les limites du modèle, et le seul document qui sort de votre appareil en clair parce que la loi l'exige : la facture destinée à l'assureur — l'assureur-maladie (LAMal) ou, au tarif 334 en tiers payant, l'assureur d'un cas d'assurance-accidents, d'assurance-invalidité ou d'assurance militaire (section 5.2).

Hors de Suisse, vous achetez le service géré à Paddle, un revendeur (« merchant of record ») qui encaisse le prix, perçoit la taxe de votre pays et vous remet le reçu. Vos coordonnées de paiement, c'est Paddle qui les recueille, dans son formulaire de paiement (affiché sur la page carnet.health/paiement/ par le module de Paddle) et sous sa propre responsabilité. L'éditeur ne lui transmet que l'identifiant opaque de votre compte, et n'inscrit dans son registre que cet identifiant, la date, le montant, la devise, la période payée, le moyen de paiement, l'identifiant de la transaction ou de l'ajustement de Paddle et, s'il y a lieu, le motif d'un remboursement — jamais votre nom, votre courriel, votre adresse ni votre adresse IP (section 5.3). Paddle ne voit rien de votre dossier.

1. Qui est responsable de quoi — et la nature zero-knowledge

1.1 Vous êtes responsable du traitement de vos données patients. En tant que professionnel·le de santé, c'est vous qui déterminez les finalités et les moyens du traitement des données de vos patient·e·s ; vous en êtes le responsable du traitement au sens de l'art. 5 let. j LPD, et demeurez titulaire du secret professionnel (art. 321 CP). L'éditeur ne définit pas ces finalités et n'accède pas à ces données.

1.2 L'éditeur n'est, au plus, que sous-traitant technique de blocs chiffrés. Pour le seul service de synchronisation et de conservation de sauvegardes, l'éditeur intervient comme sous-traitant (art. 5 let. k et art. 9 LPD), exclusivement sur des blocs chiffrés de bout en bout qu'il ne peut pas déchiffrer. Cette qualification est retenue par précaution : par conception, l'éditeur n'a aucun accès aux données de santé en clair ni à l'identité des patient·e·s. Les modalités de cette sous-traitance sont réglées par le contrat (accord de sous-traitance / DPA intégré au contrat, https://carnet.health/conditions.html, section 9, et annexe « Liste des sous-traitants » — voir section 5).

1.3 L'éditeur est responsable autonome pour ses seules données techniques. Pour les métadonnées qui lui sont propres (voir section 2) et pour la relation contractuelle avec vous, l'éditeur agit en responsable du traitement autonome. Ces traitements sont licites parce qu'ils respectent les principes de la LPD (art. 6 et 8) ; en tant que de besoin, ils sont couverts par les motifs justificatifs de l'art. 31 LPD — traitement en relation directe avec l'exécution du contrat que vous concluez avec l'éditeur, les données traitées étant celles de la cocontractante (art. 31 al. 2 let. a LPD), et intérêt privé prépondérant à la sécurité et à la disponibilité du système (art. 31 al. 1 LPD). Ces données ne comprennent aucune donnée de patient.

1.4 Usage local sans synchronisation. « Carnet » fonctionne hors ligne d'abord : vous pouvez l'utiliser entièrement sur votre appareil, sans activer la synchronisation. Dans ce cas, aucune donnée ne quitte votre appareil vers l'éditeur — à l'exception des factures que vous décidez de transmettre vous-même aux assureurs (section 5.2). L'éditeur ne traite alors, vous concernant, que d'éventuelles coordonnées de facturation d'abonnement (si vous êtes abonné·e).

1.5 Paddle, revendeur hors de Suisse : un responsable indépendant. Quand le service géré vous est vendu hors de Suisse, vous ne l'achetez pas à l'éditeur mais à Paddle, qui le revend en son propre nom (section 5.3). Pour les données que vous lui donnez en payant, Paddle est responsable du traitement, indépendamment de l'éditeur : leurs contrats le prévoient (contrat vendeur de Paddle, clause 14.2, et son accord de partage de données, lus le 23.09.2026). Paddle n'est pas un sous-traitant de l'éditeur : il ne traite rien pour le compte de l'éditeur, et ne reçoit ni bloc chiffré ni donnée de patient. Il n'est pas non plus le vôtre. Ce qu'il fait de vos données, sa propre politique le dit : https://www.paddle.com/legal/privacy.

2. Quelles données sont traitées

2.1 Sur votre appareil (sous votre seul contrôle, chiffrées au repos)

Trois familles de données, toutes créées et détenues par vous sur votre appareil, sont stockées chiffrées dans la base locale du navigateur (IndexedDB « carnet-v2 », via Dexie ; tables ops = journal d'événements, meta = paramètres, medias = photos et pièces chiffrées : documents déposés au classeur du patient et, depuis le 16.09.2026, l'exemplaire de chaque document que vous marquez envoyé) :

• Identité nominative du patient (op interne patient.identite) : prénom, nom, date de naissance, sexe, n° AVS (format 756.xxxx.xxxx.xx, requis pour la facturation à l'assureur), n° de carte d'assuré, n° de sinistre (LAA), de décision AI ou de cas (AM) d'un cas d'assurance, rue du domicile, assureur (GLN + nom), téléphone, courriel et garant du patient. Ces données sont marquées strictement locales dans le code (constante OPS_LOCALES) : elles sont filtrées avant tout envoi et ne sont jamais transportées par la synchronisation courante. Le reste du domicile voyage, chiffré : la commune, le NPA, la localité et le CMS de rattachement (op patient.domicile) partent avec le dossier, chiffrés de bout en bout comme lui, pour que vos autres appareils préparent la tournée et le décompte du résiduel à la charge du canton ; le serveur ne peut pas les lire. Elles ne peuvent sortir de l'appareil que par les canaux limitativement décrits en section 4.3 (quatre canaux scellés, illisibles pour l'éditeur et pour le serveur) et par la facture destinée à l'assureur, qui part en clair (section 5.2).
• Données cliniques : notes et transmissions de soins, plaies (méthode TIME), photos de plaies (chiffrées dans la table medias, hors journal), pièces du classeur du patient (documents déposés et l'exemplaire de chaque document marqué envoyé — déclaration OPAS 7, dossier de transmission, courrier — chiffrés de la même façon), relevés et seuils de mesures, échelles d'évaluation, évaluation du risque suicidaire (RUD), planning et tournée, prescriptions OPAS art. 7.
• Données de facturation : prescriptions OPAS 7, factures AOS (y compris les lignes de matériel LiMA des factures déjà émises), décomptes résiduels CMS, prestations et matériel facturés directement au patient (hors-AOS). Les accusés reçus des assureurs (facturation.accuse, opas7.accuse) sont conservés localement car un accusé peut citer le nom du patient.

Proches et contacts d'urgence. Le dossier d'un·e patient·e peut contenir les coordonnées de proches et de contacts (représentant·e thérapeutique, personne à prévenir, voisin·e qui détient une clé…), enregistrées par la soignante pour la continuité et la sécurité des soins. Ces données vivent dans le dossier chiffré, couvertes par le secret professionnel, et sont supprimées avec lui ; elles ne sont ni synchronisées en clair, ni exportées vers un carnet d'adresses. Les personnes concernées n'en sont pas informées individuellement : la soignante, personne privée liée par une obligation légale de garder le secret (art. 321 CP), est déliée du devoir d'information de l'art. 19 LPD par l'art. 20 al. 1 let. c LPD — la présente mention vaut information générale.

Aucune donnée patient réelle n'est utilisée en démonstration : l'application propose un mode démonstration éphémère à pseudonymes, dont les données ne sont pas conservées.

2.2 Ce que l'éditeur voit réellement (si la synchronisation est activée)

Ce que l'éditeur peut techniquement voir se limite à ce qui suit.

2.3 Ce que l'éditeur ne voit pas (impossible techniquement) : le contenu du dossier, les identités des patient·e·s, les données de santé, les doses, les documents, les plaies, les relevés, les brouillons — rien de tout cela ne parvient à l'éditeur en clair, ni par la synchronisation, ni par les canaux scellés de la section 4.3. La facture destinée à l'assureur fait exception au principe « rien ne sort en clair » : elle contient des données nominatives en clair (section 5.2) ; sa transmission à MediData est régie par les conditions d'utilisation de MediData, que vous avez acceptées.

2.4 Aucun traçage, aucun tiers de mesure d'audience, aucune publicité. « Carnet » ne charge aucun script tiers, aucune police, aucune image ni aucun mouchard externe : une politique de sécurité de contenu (CSP) stricte bloque à l'exécution toute requête vers un hôte tiers : l'application ne peut joindre que le serveur de synchronisation de son édition et, sur votre propre ordinateur, le connecteur d'envoi des factures. Il n'y a ni régie publicitaire, ni analytique comportementale, ni revente de données. Une seule exception, hors de l'application : la page de paiement https://carnet.health/paiement/ de la vitrine, ouverte par le lien de paiement que l'éditeur vous envoie pour un achat hors de Suisse, charge le module de paiement de Paddle (Paddle.js, servi par paddle.com) pour afficher le formulaire de Paddle ; sa politique de sécurité de contenu n'ouvre que les adresses de Paddle. C'est la seule page de Carnet qui charge un script tiers ; l'application n'en charge aucun, et le reste de la vitrine non plus. Ce que vous y saisissez va à Paddle, vendeur, et ce que Paddle dépose ou lit sur votre appareil relève de sa politique (5.3).

3. Finalités et fondement des traitements

Le droit suisse ne subordonne pas un traitement privé à une « base légale », contrairement au règlement européen : un traitement est licite dès lors qu'il respecte les principes de la LPD (licéité, bonne foi, proportionnalité, finalité reconnaissable, exactitude, sécurité — art. 6 et 8 LPD). Un motif justificatif n'entre en jeu que si le traitement porte atteinte à la personnalité de la personne concernée (art. 30 et 31 LPD). Le tableau ci-dessous indique donc, pour chaque traitement, qui le conduit et sur quoi il repose — et, le cas échéant, le motif justificatif réservé.

L'éditeur ne traite aucune donnée de patient pour son propre compte, et ne fait aucun profilage. Quatre décisions sont prises automatiquement, sur une règle publiée : la porte de souscription vous remet un code d'accès ou inscrit votre demande en liste d'attente, selon le pays que vous déclarez ; un abonnement impayé est suspendu à la fin du délai de grâce — hors de Suisse, aussi un abonnement confirmé dont la première période n'a jamais été payée, à l'échéance que fixe le courriel du lien de paiement, au plus tôt vingt jours après son envoi —, sans jamais toucher à votre accès local à vos données (contrat, clause 5.4 ; annexe MONDE, M-2 let. f bis) ; à la fin d'un essai de trente jours que vous n'avez pas confirmé, le service géré se met en pause (synchronisation, sauvegardes gérées, ouverture de nouvelles relèves), sans toucher à votre accès local ni à une relève déjà ouverte, et reprend dès votre confirmation (contrat, clause 5.1bis let. b) ; et, lorsque les conditions changent de façon substantielle, la synchronisation d'un compte qui n'a ni accepté ni refusé la nouvelle version trente jours après sa communication attend votre réponse, sans toucher à l'usage de l'application sur votre appareil (contrat, clause 12.2). Cette quatrième décision ne vise qu'un compte qui a déjà accepté une version du contrat qui la prévoit : elle ne s'applique pas à la version qui l'introduit. Vous en êtes informé·e ici (art. 21 al. 1 LPD). Vous pouvez faire valoir votre point de vue et exiger que la décision soit revue par une personne, l'éditeur : (art. 21 al. 2 LPD). Le limiteur de débit, qui ralentit des requêtes en rafale, ne décide rien à votre égard. À la fin d'un contrat, le passage du compte en période transitoire, en lecture seule puis en attente d'effacement suit les dates que l'éditeur a inscrites à votre demande (7.5) : ce n'est pas une décision automatisée, c'est l'exécution datée de la vôtre ; l'effacement lui-même est un geste de l'éditeur.

4. Vos données de santé : chiffrées et sous votre seul contrôle

4.1 Chiffrement sur l'appareil. Le dossier de soins (journal d'événements) et les photos sont chiffrés sur votre appareil au moyen d'une clé maîtresse aléatoire de 32 octets (la CMK), en ChaCha20-Poly1305-IETF. La CMK n'est jamais écrite en clair : elle ne vit qu'en mémoire vive pendant une session déverrouillée. Sur le disque, elle n'existe que sous forme « enveloppée » (elle-même chiffrée) sous plusieurs secrets indépendants qui ouvrent tous la même clé :

• votre mot de passe (dérivé par Argon2id, coût MODERATE pour les nouveaux comptes ; plancher de 12 caractères + estimateur de robustesse local refusant les mots de passe faibles ; phrase de passe recommandée) ;
• une clé de secours / phrase de récupération (8 mots, ~88 bits d'entropie) ;
• le cas échéant une clé biométrique (la biométrie de l'appareil, visage ou empreinte, via WebAuthn) — cette enveloppe reste liée au matériel de l'appareil et n'est jamais synchronisée ni exportée ;
• le cas échéant un code dépositaire distinct.

Sans l'un de ces secrets, les données locales sont illisibles (les blocs chiffrés seuls ne suffisent pas). L'éditeur ne détient aucune clé lui permettant, seul ou avec le serveur, de déchiffrer vos données — ni mot de passe d'administration, ni porte dérobée.

4.2 Persistance et verrouillage. L'application demande la persistance du stockage (navigator.storage.persist) pour éviter la purge automatique de la base par certains navigateurs, un dossier de soins ayant vocation à être conservé de nombreuses années. Un verrouillage automatique (délai réglable) referme le coffre après inactivité ; les brouillons en cours sont chiffrés.

4.3 Par où sort — et ne sort pas — l'identité nominative des patient·e·s. La synchronisation courante ne transporte JAMAIS les identités nominatives (op patient.identite : nom, prénom, date de naissance, n° AVS, rue du domicile, assureur, n° de sinistre (LAA), de décision AI ou de cas (AM) ; la commune, le NPA et la localité voyagent, eux, chiffrés avec le dossier — section 2.1) : elles sont filtrées avant tout envoi. Elles peuvent sortir de votre appareil par quatre canaux scellés, que vous déclenchez ou activez, et qui restent opaques pour l'éditeur comme pour le serveur :

• ① Transfert d'appareil à appareil que VOUS déclenchez (par ex. lors de l'appairage d'un second appareil) : les identités voyagent dans une boîte aux lettres scellée (crypto_box_seal, libsodium), avec vérification humaine par 4 mots (SAS anti-interception). Le serveur ne relaie que des blocs qu'il ne peut ni lire ni forger (il ne connaît jamais les clés publiques d'appareil).
• ② Enveloppe de récupération SUR-SCELLÉE, déposée sur le serveur si — et seulement si — vous activez la porte de récupération (choix exprès proposé à l'activation de la synchronisation, révocable à tout moment) : les identités sont chiffrées (AEAD sous la CMK) puis re-scellées (box_seal) vers une clé publique de récupération. Elles ne sont ouvrables qu'en réunissant plusieurs secrets détenus séparément, et uniquement côté client, le jour d'une récupération (voir 4.4).
• ③ Relève : la transmission, à une remplaçante que VOUS désignez, du dossier des seul·e·s patient·e·s concerné·e·s — leur dossier entier, historique compris —, identités comprises, tant que l'accès que vous accordez est ouvert (voir 4.5).
• ④ Pli de secours de relève : pour qu'une remplaçante puisse retrouver son accès si elle perd son appareil pendant la relève, les identités des seul·e·s patient·e·s confié·e·s sont déposées sur le serveur chiffrées sous une clé dérivée de sa clé d'accès biométrique (que le serveur ne peut pas dériver). Ce pli est borné à la durée de la relève (plus une courte grâce), et détruit par la révocation, par la clôture de la relève ou par l'extinction automatique à la fin prévue du mandat. L'éditeur ne peut pas le lire.

Séparément, et sans être ni scellée ni opaque : la facture destinée à l'assureur part EN CLAIR. Ce n'est pas une exception technique du même ordre que les quatre canaux ci-dessus : c'est une obligation légale de facturation, assumée comme telle — art. 42 LAMal pour l'assurance-maladie ; pour un cas facturé au tarif 334 en tiers payant, art. 54a LAA (assurance-accidents), art. 27ter al. 1 LAI (assurance-invalidité) et art. 25a LAM (assurance militaire). Son contenu exact est détaillé en section 5.2. Sa transmission à MediData est régie par les conditions d'utilisation de MediData, que vous avez acceptées.

Le reste du dossier, chiffré, est répliqué entre vos propres appareils.

4.4 Service de récupération (miroir du contrat, clauses 9.11 et 10.8). Cette porte ne s'ouvre jamais d'office : à l'activation de la synchronisation, l'application vous pose la question et présente les deux branches — « Activer la porte de récupération » ou « Ne pas l'activer » — sans option pré-cochée et sans rien déposer avant votre choix. Elle vous indique à cet endroit que l'enveloppe déposée contient les identités de vos patient·e·s, sur-scellées : la décision appartient à la professionnelle responsable du traitement, elle ne se déduit ni d'un contrat ni du consentement de tiers. Le refus comme la révocation restent possibles à tout moment dans les Réglages. Si la porte est active, le dispositif repose sur un partage de secret : une part de 8 mots reste sur une Feuille de récupération papier détenue par vous (jamais transmise) ; l'autre part est scellée vers une clé de garde de l'éditeur conservée HORS serveur. Aucune des deux parties seule — ni le serveur, ni l'éditeur — ne peut reconstituer la clé ; la recombinaison a lieu exclusivement côté client, avec vérification par 4 mots. La confidentialité repose sur la robustesse cryptographique de la part de 8 mots, jamais sur un simple compteur d'essais.

Contact de secours. Si vous en aviez désigné un, vous pouvez le révoquer ; il n'est plus possible d'en ajouter un nouveau. Tant qu'il n'est pas révoqué, une seconde feuille, remise à la personne de votre choix, ouvre une troisième porte. Le dispositif devient 2-de-3 — la part de garde de l'éditeur, plus au choix vos 8 mots ou le code de votre contact. Les protections du jour J sont identiques par cette voie (carence, plancher, veto, vérification d'identité) : il n'existe aucun régime accéléré. Le nom de votre contact n'est enregistré nulle part chez l'éditeur : il ne vit que dans votre coffre, sur votre appareil, et le serveur ne révèle jamais si un contact existe.

La procédure de libération suit un parcours protecteur décrit au contrat : un délai de carence de 72 heures par défaut, assorti d'un plancher de 24 heures codé en dur qu'aucune configuration du serveur ne peut abaisser (le paramétrage ne peut qu'allonger la carence) ; la notification de vos appareils actifs, avec droit de veto ; une vérification d'identité. En cas de révocation, l'enveloppe sur-scellée et la part scellée sont détruites (attestation écrite sur demande). Une demande de récupération est par ailleurs la seule opération dont l'éditeur garde une trace durable comportant votre adresse de connexion : toute interaction avec le service de récupération — mise en place, changement du numéro de vérification, ajout ou révocation d'un contact de secours, désactivation du service, demande, veto, livraison — est inscrite avec une empreinte à clé secrète de votre adresse IP (depuis le 23.09.2026 ; auparavant l'adresse elle-même) et la date dans un journal dédié que rien ne peut modifier ni effacer.

4.5 Relève : confier des dossiers à une remplaçante. Lorsque vous vous faites remplacer, vous pouvez ouvrir une relève : une collègue reçoit, sur son appareil et sous forme chiffrée, le dossier des seul·e·s patient·e·s que vous désignez — le dossier lui-même, tel que vous le tenez, et non un résumé —, identités comprises, tant que l'accès que vous leur accordez est ouvert — vous pouvez l'étendre, le borner ou le révoquer à tout moment ; il s'éteint par la clôture de la relève, par sa révocation, ou de lui-même 90 jours après la fin prévue du mandat lorsque cette date a été déposée sur le serveur (voir 2.2) — un filet lointain, pour qu'un mandat oublié ne reste pas ouvert sans limite, jamais un couperet sur un travail en cours ; un mandat sans fin (binôme permanent) n'a pas d'échéance. Cette extinction automatique ferme l'écriture immédiatement et laisse la lecture ouverte trente jours, le temps que vous rapatriiez les soins de la dernière tournée ; passé ce délai, les blocs du compte sont effacés. Cette communication repose sur le consentement de vos patient·e·s au partage de leur dossier avec les soignant·e·s qui interviennent auprès d'eux·elles (art. 321 ch. 2 CP ; art. 36 al. 2 LS/VS ; art. 31 LPD), que vous recueillez et tracez dans l'application. Ce que vous devez savoir :

• Ce que le serveur héberge : un compte de synchronisation dédié à la remplaçante, les amorces chiffrées du compartiment et, si elle a enrôlé une clé d'accès biométrique, le pli de secours décrit en 4.3 ④. L'éditeur ne peut lire ni les identités, ni les dossiers transmis : ils ne sont déchiffrables que sur l'appareil de la remplaçante.
• Un engagement accepté dans l'application, avant tout accès. Avant que le moindre nom ne s'affiche, la remplaçante doit accepter des « Conditions d'utilisation du mode relève » versionnées (version en vigueur : releve-8). L'écran est bloquant au premier accès : sans acceptation, pas d'accès. L'acceptation se fait d'un seul geste, sans case à cocher, le texte complet sous les yeux ; elle est horodatée et tracée, et comprend la déclaration de la remplaçante qu'elle est autorisée à pratiquer. Ces conditions portent sur : le fondement de l'accès — le consentement des patient·e·s au partage, que vous recueillez et tracez ; le maintien du secret professionnel (art. 321 CP) ; un accès limité aux soins des patient·e·s confié·e·s, tant que l'accès que vous accordez est ouvert, et l'engagement de n'y consulter que ce que ses soins demandent ; le fait que chacune de ses écritures est signée par une clé qui reste sur son appareil — ce qu'elle documente lui est attribuable, et personne, pas même vous, ne peut écrire sous son nom ; l'étendue de ce qu'elle tient au dossier des patient·e·s confié·e·s — observations, transmissions ciblées, mesures et seuils, médicaments donnés ou refusés, plaies et stomies (protocoles et clôture compris), traitements, réévaluations, rendez-vous et plan de soins, pièces déposées au classeur, échelles — et ce qui reste à vous : la déclaration de soins à l'assureur (OPAS 7), qu'elle consulte et peut imprimer sans pouvoir la modifier, et la fiche d'admission du patient (identité, assurance, domicile, allergies, volontés, anamnèse d'entrée), qu'elle ne modifie pas depuis un dossier partagé — ce qu'elle constate au chevet, elle le note au dossier, à son nom ; le fait qu'elle n'ouvre ni n'archive aucun dossier et ne retire ni une pièce du classeur ni une fiche de l'annuaire ; l'extinction de l'accès à sa clôture, à sa révocation ou 90 jours après la fin prévue du mandat, et la suppression du compartiment de son appareil ; la responsabilité de sa propre documentation, qui porte son nom ; le caractère personnel de l'accès (une clé et un mot de passe à elle, une signature par écriture) et le caractère commun du dossier du mandat — les autres remplaçant·e·s du même mandat, invité·e·s par vous, lisent et écrivent le même dossier et ne sont pas des tiers ; le signalement sans délai d'une perte, d'un vol ou d'un accès non autorisé ; la non-communication des dossiers à des tiers et l'absence de copie hors de Carnet ; et le rappel que l'information des patient·e·s incombe à la titulaire. Il n'existe aucun document papier à signer : l'engagement est pris dans l'application.
• Vous restez responsable du traitement. C'est à vous, titulaire du dossier, qu'il revient de recueillir et de tracer le consentement des patient·e·s au partage de leur dossier, d'informer les patient·e·s de l'intervention d'une remplaçante, et de tenir compte de toute opposition : l'application vous la signale et la trace dans le dossier du·de la patient·e, mais ne retire aucun dossier à votre place — la décision de confier ou non malgré une opposition, et sa justification (notamment en cas d'urgence), vous appartiennent, sous votre responsabilité. Le choix des patient·e·s confié·e·s est le vôtre, dossier par dossier.

5. Destinataires et sous-traitants

L'éditeur minimise les tiers. « Carnet » n'utilise pas de traqueurs publicitaires ni d'analytics tiers ; l'application (PWA) est auto-contenue (CSP stricte, pas de CDN ni de ressources externes chargées à l'exécution). Deux destinataires de plus peuvent intervenir, qui ne sont pas des sous-traitants et ne figurent donc pas dans la liste de l'art. 9 al. 3 LPD ci-dessous : L'assureur de responsabilité civile de l'Éditeur, s'il en conclut un un jour (à la date de cette version, aucune assurance n'est conclue, contrat 3.5), en cas de réclamation seulement : les données du Client nécessaires à son traitement (identité, contrat, correspondance). Aucune donnée de patient : l'Éditeur n'en détient aucune en clair. Il n'est pas un sous-traitant ; cette politique sera complétée avant tout envoi à un assureur. Paddle.com Market Limited, pour une vente hors de Suisse : revendeur, responsable indépendant des données que vous lui donnez en payant (1.5, 5.3). Il ne reçoit de l'éditeur que l'identifiant opaque de votre compte et les remboursements que l'éditeur décide. Il n'est pas un sous-traitant, et ne figure donc pas dans la liste ci-dessous.

5.1 Annexe — liste des sous-traitants (art. 9 al. 3 LPD)

(Liste tenue à jour et datée. État au 23 septembre 2026, relue le 11 octobre 2026. Elle est aussi celle de l'annexe IV des clauses types de l'annexe de zone, pour les blocs chiffrés : Infomaniak et Proton Drive. Le registre des traitements de l'éditeur la reprend.)

Supervision technique et horodatage. Trois services extérieurs reçoivent, non pas des données de dossier, mais des signaux d'exploitation — ils sont mentionnés ici parce que cette liste se veut exhaustive :

Toute évolution de cette liste (ajout / remplacement d'un sous-traitant) vous est communiquée conformément au contrat, avec possibilité de s'opposer.

5.2 La facture à l'assureur — ce qui part réellement, en clair

C'est le point où le modèle « rien ne sort en clair » cesse de s'appliquer, parce que la loi l'impose : le fournisseur de prestations doit remettre à l'assureur une facture détaillée et lui transmettre les indications nécessaires à son contrôle. C'est l'art. 42 LAMal pour l'assurance-maladie. Pour les soins facturés au tarif 334, en tiers payant, à un cas d'assurance posé au dossier, c'est l'art. 54a LAA pour l'assurance-accidents, l'art. 27ter al. 1 LAI (précisé par l'art. 79ter RAI) pour l'assurance-invalidité et l'art. 25a LAM pour l'assurance militaire. Nous le disons sans détour.

Ce que contient la facture transmise à l'assureur :

• nom, prénom, date de naissance, sexe du/de la patient·e ;
• son n° AVS et son adresse ;
• les prestations facturées (positions tarifaires, dates, quantités) ;
• l'identité et l'adresse du médecin prescripteur ;
• une indication médicale en TEXTE LIBRE, d'une longueur maximale de 350 caractères ;
• pour un cas LAA, AI ou AM : la loi, le n° de sinistre (LAA) ou le n° de décision AI (AI, exigé par l'art. 79ter al. 1 let. d RAI), le n° du cas s'il existe (AM), la date de l'accident (LAA) ou du cas (AM) et le motif du traitement (accident, maladie, infirmité congénitale).

Cette indication médicale est bien une information clinique en clair. Elle figure dans la facture parce que l'assureur en a besoin pour contrôler la prise en charge ; elle est rédigée par vous, sous votre responsabilité, et vous devez la limiter à ce qui est nécessaire au contrôle du décompte. Ce qui ne part pas dans la facture : le dossier de soins lui-même, les notes et transmissions, les photos de plaies, les échelles et évaluations, les documents.

Qui reçoit la facture. La facture LAMal va à l'assureur-maladie du patient ; celle d'un cas LAA, à l'assureur-accidents de ce cas ; celle d'un cas AI, à la Centrale de compensation, à qui le fournisseur de prestations peut l'adresser par transfert électronique de données (art. 79 al. 1 RAI) ; celle d'un cas AM, à la Suva, à qui la gestion de l'assurance militaire a été transférée (art. 81 al. 2 LAM). Vous devez remettre au patient une copie de la facture en tiers payant LAMal (art. 42 al. 3 LAMal) et en AI (art. 27ter al. 1 LAI ; art. 79ter al. 4 RAI). Carnet la prépare à l'impression une fois la facture transmise ; vous la lui remettez ou la lui envoyez vous-même — elle ne passe par aucun serveur de l'éditeur.

Votre dossier de soins reste illisible pour l'éditeur : il est chiffré sur votre appareil. La transmission de la facture à MediData est régie par les conditions d'utilisation de MediData, que vous avez acceptées. Comme vous êtes raccordé(e) « via le partenaire logiciel Carnet », MediData fait connaître à l'éditeur, comme à tout partenaire logiciel, la liste des organisations raccordées par ce partenaire : le nom, le lieu, l'identifiant client et le GLN de votre cabinet — jamais une facture ni une donnée de patient. L'éditeur traite ces données pour son propre compte (accord de sous-traitance, section 2.3).

5.3 Paddle — le revendeur du service hors de Suisse

Qui. Paddle.com Market Limited, société enregistrée en Angleterre et au pays de Galles sous le n° 08172165, 30 Old Bailey, Londres EC4M 7AU, Royaume-Uni (pour les ventes hors du Canada).

Ce qu'il fait. Dans les pays hors de Suisse que la page de prix dit ouverts, Paddle vous vend le service géré en son propre nom : il encaisse le prix, perçoit et déclare la taxe de votre pays, vous remet le reçu, renouvelle l'abonnement, relance un paiement qui échoue et exécute les remboursements que l'éditeur décide. L'éditeur ne vous adresse ni facture ni demande de paiement hors de Suisse. En Suisse, Paddle n'intervient pas.

Son rôle. Pour les données que vous lui donnez en payant, Paddle est responsable du traitement, indépendamment de l'éditeur (1.5). Ce n'est pas un sous-traitant (art. 5 let. k et art. 9 LPD). Sa politique de confidentialité fait foi pour ces données : https://www.paddle.com/legal/privacy. Vos droits sur ces données s'exercent auprès de Paddle (https://preferences.paddle.com) ; l'éditeur vous y aide si vous le lui demandez.

La page de paiement de Carnet. Le lien de paiement ouvre la page https://carnet.health/paiement/, que publie l'éditeur. C'est la seule page de Carnet qui charge un script d'un tiers : le module de paiement de Paddle (Paddle.js), servi par paddle.com. Ce module affiche le formulaire de paiement de Paddle dans un cadre servi par Paddle (buy.paddle.com). La page elle-même ne lit que le numéro de transaction de son adresse, la langue de votre navigateur et, s'ils existent, vos réglages d'affichage de la vitrine (thème clair ou sombre, palette), qui restent dans votre navigateur ; elle n'y écrit rien et n'envoie rien à l'éditeur : elle ouvre la transaction que l'éditeur a préparée, qui ne porte que l'identifiant opaque de votre compte. En la chargeant, votre navigateur se connecte aux serveurs de Paddle, qui reçoivent, comme pour toute page web, votre adresse IP et des informations techniques sur votre navigateur. Ce que la page dépose, mesuré le 9 octobre 2026 (navigateur Chromium, page chargée sans transaction) : une seule requête vers un tiers, le module de Paddle (cdn.paddle.com) ; en réponse, le serveur de ce module, servi par Cloudflare, dépose un cookie technique de protection contre les robots, __cf_bm, sur le domaine paddle.com, illisible par la page (HttpOnly), pour trente minutes ; rien dans le stockage local ni de session de carnet.health, aucun cookie de carnet.health. Ce que le formulaire de paiement de Paddle dépose ou lit ensuite, dans son cadre buy.paddle.com, une fois votre transaction ouverte, n'a pas été mesuré : Paddle le décrit dans sa politique (section J, « Cookies and Similar Technologies », lue le 9 octobre 2026) — ce qui sert au paiement et à la prévention de la fraude. Ces opérations servent le seul paiement que vous avez demandé : fondement, l'exécution du contrat (art. 31 al. 2 let. a LPD ; art. 6 § 1 let. b RGPD) ; un dépôt ou une lecture sur votre appareil strictement nécessaire à ce service que vous avez expressément demandé ne requiert pas votre consentement (art. 5 § 3 de la directive 2002/58/CE) ; en Suisse, la loi sur les télécommunications demande que vous soyez informée de ce traitement et de sa finalité — vous l'êtes ici — et avisée de la possibilité de le refuser, ce que permettent les réglages de votre navigateur, au risque que le paiement n'aboutisse pas (art. 45c let. b LTC, RS 784.10). La page n'est ni indexée ni liée depuis le reste de la vitrine : on n'y arrive que par votre lien de paiement.

Qui répond de cette page. Pour le paiement lui-même et pour tout ce que Paddle fait ensuite de vos données (encaissement, taxe, reçu, renouvellement, prévention de la fraude), Paddle est responsable du traitement, indépendamment de l'éditeur (1.5). Pour le seul chargement du module de Paddle sur la page de l'éditeur et la transmission à Paddle qu'il provoque, l'éditeur, qui a choisi d'intégrer ce module à sa page pour être payé, se tient pour responsable conjoint avec Paddle (art. 26 RGPD ; art. 5 let. j LPD), dans la ligne de l'arrêt Fashion ID de la Cour de justice de l'Union européenne (29 juillet 2019, C-40/17) — pour ces deux opérations seulement, jamais pour ce que Paddle fait ensuite. Pour vous, cela veut dire : l'éditeur vous informe ici de ces opérations ; vous pouvez exercer vos droits à leur sujet auprès de l'éditeur comme de Paddle ; l'éditeur reçoit votre demande, y répond pour ce qui le concerne et la transmet à Paddle pour le reste (art. 26 § 3 RGPD). L'éditeur et Paddle n'ont pas conclu d'accord écrit sur ce point : l'éditeur assume envers vous les obligations décrites ci-dessus et reste, pour ces deux opérations, votre point de contact ; Paddle répond seul de ce qu'il fait ensuite de vos données.

Ce que Paddle recueille, auprès de vous. Dans son formulaire de paiement : votre nom, votre courriel, votre adresse de facturation, votre moyen de paiement (pour une carte, ses données ne sont traitées que par Paddle et ses prestataires de paiement), le cas échéant votre numéro de TVA, votre adresse IP et des informations techniques sur votre appareil, notamment pour prévenir la fraude. C'est vous qui les saisissez : l'éditeur ne les lui transmet pas.

Ce que l'éditeur transmet à Paddle. L'identifiant opaque de votre compte de synchronisation, dans la transaction que porte votre lien de paiement — il relie votre paiement à votre compte — et, s'il y a lieu, le remboursement d'une transaction désignée par son identifiant. Rien d'autre : ni votre nom, ni votre courriel, ni votre dossier, ni un bloc chiffré, ni une donnée de patient. La clé qui permet de parler à Paddle est sur le poste de l'éditeur, en Suisse : le serveur de synchronisation ne parle jamais à Paddle. Paddle sait que vous avez acheté le service géré ; il ne voit rien de ce que vous en faites.

Ce que Paddle montre à l'éditeur, et ce que l'éditeur en garde. Paddle met à la disposition de chaque vendeur, dans son espace vendeur, ce qu'il sait de ses acheteuses (nom, adresse, courriel, historique d'achat). L'éditeur ne peut pas l'empêcher ; il ne consulte ces données que pour exécuter la vente, et n'en recopie rien. Son registre des paiements ne garde que les éléments de la section 2.2 (« Paiement par Paddle ») — jamais votre nom, votre courriel, votre adresse ni votre adresse IP.

Où vont ces données. Paddle.com Market Limited est au Royaume-Uni, État dont la législation assure un niveau de protection adéquat au regard du droit suisse (art. 16 al. 1 LPD ; annexe 1 OPDo). Pour une cliente de l'Espace économique européen, le Royaume-Uni bénéficie d'une décision d'adéquation de la Commission européenne : décision d'exécution (UE) 2021/1772 du 28 juin 2021 (JO L 360 du 11.10.2021, p. 1), modifiée par la décision d'exécution (UE) 2025/2574 du 19 décembre 2025 (JO L, 2025/2574, 23.12.2025), qui la fait expirer le 27 décembre 2031, sauf prorogation. Le module de paiement est servi depuis les serveurs de Paddle (paddle.com), qui recourt, pour le servir, à des prestataires de son choix. Paddle recourt lui-même à des prestataires situés dans le monde entier et encadre ses transferts selon sa politique ; ces transferts relèvent de sa responsabilité.

Pays fermés. Le service géré n'est pas vendu là où Paddle ne vend pas, ni là où la loi du pays interdit à une soignante de confier le dossier de ses patient·e·s à un serveur en Suisse. France : héberger des données de santé pour le compte d'une professionnelle exige un hébergeur certifié, qui stocke dans l'Union européenne ou l'Espace économique européen (code de la santé publique, art. L.1111-8 et R.1111-9-1) ; l'application s'y utilise localement, sans synchronisation, et aucune donnée de paiement n'y est traitée. La page de prix tient la liste des pays fermés et leur motif.

Contrat de sous-traitance hors de Suisse. Pour les blocs chiffrés de vos dossiers, l'éditeur est votre sous-traitant (1.2). Dans l'Espace économique européen, ce rapport est régi par l'annexe de zone MONDE, qui reprend les clauses contractuelles types de la Commission (décision d'exécution (UE) 2021/915), soumises au droit de votre État : c'est le contrat qu'exige l'art. 28 RGPD. Vous l'acceptez avec le contrat, à la souscription.

6. Hébergement et localisation

6.1 Hébergement en Suisse. L'infrastructure serveur est un VPS chez Infomaniak, en Suisse (Debian), servi par Caddy en HTTPS (certificats Let's Encrypt renouvelés automatiquement, en-têtes HSTS). Un seul serveur héberge les sous-domaines du service :

• carnet.health — la vitrine (site de présentation) ;
• app.carnet.health — l'application PWA (fichiers statiques du build) ;
• global.carnet.health — l'édition internationale de l'application, sans brique nationale, en ligne depuis le 21.09.2026 ;
• qc.carnet.health — l'édition québécoise de l'application, en ligne depuis le 25.09.2026 ;
• sync.carnet.health — le serveur de synchronisation « aveugle » (Node.js, base SQLite locale au serveur), qui ne stocke que des blocs chiffrés et exige un code d'invitation pour l'activation d'un compte.

6.2 Aucun transfert de données patients en clair hors de Suisse — pour la raison simple qu'il n'existe aucune donnée patient en clair côté serveur. D'éventuelles sauvegardes chiffrées répliquées hors de Suisse ne le seraient que vers un État à protection adéquate (art. 16 al. 1 LPD) ou sous une garantie de l'art. 16 al. 2 LPD, et resteraient inintelligibles. En fait : le serveur (Infomaniak) et le poste de l'éditeur sont en Suisse ; la copie hors site est chez Proton AG, société suisse établie à Genève, dont les serveurs Drive sont situés « exclusivement en Suisse, en Allemagne ou en Norvège » (politique de Proton Drive du 19.08.2026) — trois États à protection adéquate (art. 16 al. 1 LPD). Cette copie y est chiffrée une seconde fois avant l'envoi. Pour une professionnelle de l'Union européenne, de l'EEE ou du Royaume-Uni, le traitement de ses données de professionnelle en Suisse est un transfert vers un pays reconnu adéquat (décision 2000/518/CE de la Commission, maintenue par l'art. 45 § 9 RGPD ; au Royaume-Uni, Data Protection Act 2018, annexe 21, par. 4 et 5). La vente hors de Suisse n'y ajoute qu'un envoi : l'identifiant opaque de votre compte, vers Paddle, au Royaume-Uni, et, le temps d'un paiement, ce que votre navigateur envoie à Paddle en chargeant la page de paiement (5.3) — jamais une donnée de patient. Pour une professionnelle d'Argentine, du Chili, du Panama ou d'Uruguay, le traitement de ses données de professionnelle en Suisse repose, en Argentine, sur la reconnaissance de la Suisse comme pays adéquat (disposition DNPDP 60-E/2016 ; loi 25.326, art. 12) ; en Uruguay, sur la même reconnaissance (résolution de l'URCDP 23/021 du 08.06.2021 ; loi 18.331, art. 23) ; au Chili, dès l'entrée en vigueur de la loi 21.719, sur les clauses contractuelles de l'annexe MONDE, M-11.4 (art. 27 de cette loi) ; au Panama, sur la nécessité du transfert pour l'exécution du contrat (loi 81 de 2019, art. 33). Les blocs chiffrés de ses patient·e·s y sont hébergés pour son compte, sans que l'éditeur puisse les lire.

6.3 Ce qui est isolé par pays, et ce qui ne l'est pas. L'édition québécoise (qc.carnet.health) est en ligne depuis le 25.09.2026 ; le service géré n'y est pas encore vendu. Deux choses distinctes, et nous préférons les dire séparément :

• Sur votre appareil, l'isolation est totale. Chaque édition vit sur son propre domaine, donc dans un stockage que le navigateur sépare strictement (« origine ») : le coffre chiffré d'une édition est inaccessible à une autre, et aucune donnée ne passe de l'une à l'autre.
• Le serveur de synchronisation, lui, est UNIQUE (sync.carnet.health, Infomaniak, Genève) : il héberge les blocs chiffrés de toutes les éditions dans une même base. Il ne peut pas les lire — il ne détient aucune clé —, il ne relie jamais deux comptes entre eux, et chaque compte n'a accès qu'à ses propres blocs. Mais il n'y a pas de serveur québécois : une donnée synchronisée depuis le Québec est hébergée en Suisse, sous forme chiffrée. Si un pays exigeait un hébergement local, il faudrait une instance dédiée — nous le dirions avant d'y ouvrir le service. Depuis le 21.09.2026, cela ne demande aucune modification du logiciel : l'adresse du serveur est une propriété de l'édition, pas une constante du programme, et chaque édition n'a le droit de joindre que le serveur qu'elle déclare — le navigateur bloque tout autre appel. Une soignante ne peut donc pas brancher son propre serveur de synchronisation sur une édition publiée.

L'édition internationale (global.carnet.health, en ligne depuis le 21.09.2026) suit les mêmes règles : son coffre est isolé sur votre appareil comme celui des autres éditions, et ses blocs chiffrés sont hébergés sur le même serveur, en Suisse.

7. Durée de conservation

7.1 Modèle append-only (event-sourcing). Chaque écriture est un événement ajouté à un journal ; une correction ou une « suppression » métier est elle-même un nouvel événement, les événements antérieurs restant au journal (traçabilité médico-légale). Un dossier de soins a vocation à être conservé de nombreuses années (ordre de 10 à 20 ans).

7.2 Côté appareil (vous) — la conservation est VOTRE responsabilité. Vous contrôlez votre appareil. Une réinitialisation ou un effacement du coffre détruit les données locales ; sans aucun secret (mot de passe, clé de secours, biométrie), les blocs chiffrés sont définitivement irrécupérables.

La conservation du dossier de soins pendant toute la durée légale — elle dépend du canton où vous exercez : au moins 20 ans en Valais (art. 32 LS/VS) ; au moins 10 ans dès la dernière consultation dans le canton de Vaud (LSP VD art. 87) ; au moins 10 ans dès la dernière consultation, destruction au plus tard après 20 ans à Genève (LS GE art. 57) ; au moins 10 ans, destruction au plus tard après 20 ans à Fribourg (LSan FR art. 59) ; au moins 20 ans à Neuchâtel (LS NE art. 64) ; au moins 10 ans dès la fin du traitement dans le Jura (ordonnance JU 811.213 art. 19) ; au moins 20 ans, même après la cessation d'activité dans le canton de Berne (LSP BE art. 26) ; ailleurs, la durée fixée par le droit cantonal ; et 10 ans pour les pièces comptables (art. 958f CO) — incombe à vous, professionnel·le de santé, et à vous seul·e. Ce n'est pas une clause de style : l'éditeur ne la garantit pas et ne peut pas la garantir, puisqu'il ne peut ni lire, ni identifier, ni vérifier l'intégrité d'un contenu qu'il n'est pas en mesure de déchiffrer. Il ne peut donc ni attester qu'un dossier existe encore, ni le restituer si vous perdez vos secrets.

« Carnet » vous fournit les outils de cette conservation (export .carnet vérifié, sauvegardes, dépositaire, synchronisation entre vos appareils) ; la garde durable, les copies de sécurité et leur relecture périodique restent les vôtres. Il vous appartient de mettre en place une pratique de sauvegarde qui survive à la perte, au vol ou à la panne d'un appareil, ainsi qu'à la cessation de votre activité.

7.3 Côté serveur (éditeur). Ne sont conservés que des blocs chiffrés, indexés par un identifiant de compte opaque, aussi longtemps que votre compte de synchronisation existe. Les éléments transitoires sont à usage unique et de validité courte : un sceau d'appairage est valable 10 minutes et effacé dès qu'il est relevé ; une invitation scellée de relève est valable pour la durée que vous choisissez (d'une heure jusqu'au début de la relève, au plus 45 jours) et son pli est effacé dès qu'elle est prise, expirée, retirée, ou dès que la relève est close ; un message de la boîte aux lettres d'identités est valable 7 jours et effacé dès qu'il est relevé, les messages expirés étant purgés au fil de l'eau. Le compte de synchronisation dédié à une relève et ses amorces chiffrées existent le temps de la relève : sa clôture invalide le jeton serveur, et la remplaçante supprime cette relève de son appareil ; ses autres relèves et son coffre local ne sont pas touchés.

7.4 Sauvegardes. Sauvegarde quotidienne de la base du serveur, vérifiée (ouverture, contrôle d'intégrité, présence des données) ; 3 copies quotidiennes sont conservées sur le serveur, les plus anciennes étant supprimées à chaque exécution. Une copie est en outre tirée chaque jour hors du serveur, sur un support détenu par l'éditeur, où elle est purgée au-delà d'un an. Une troisième copie, hors site, est poussée chaque jour depuis le poste de l'éditeur vers Proton Drive (Proton AG, Genève ; serveurs en Suisse, en Allemagne ou en Norvège) — jamais depuis le serveur — dans un dépôt de sauvegarde chiffré (restic), conservé 30 copies quotidiennes, 12 hebdomadaires et 12 mensuelles. La rotation ne garde donc aucune copie de plus d'un an. Une réserve, pour la copie hors site : ce que la rotation retire n'est pas supprimé définitivement chez Proton, mais placé dans la corbeille de Proton Drive, où il peut subsister jusqu'à ce que cette corbeille soit vidée ; Proton garde en outre ses propres sauvegardes jusqu'à 30 jours. Ces restes sont chiffrés deux fois et Proton ne détient aucune clé permettant de les lire. Toutes les sauvegardes ne contiennent que des blocs chiffrés : une sauvegarde volée reste illisible sans les secrets détenus par vous.

Ces sauvegardes servent au rétablissement du service après incident. Elles ne constituent pas une archive de votre dossier et l'éditeur ne garantit, par elles, aucune conservation de longue durée (voir 7.2).

7.5 Fin du contrat, suppression de compte, droit à l'effacement. L'effacement local est immédiat et sous votre contrôle. Côté serveur, rien ne se ferme sur un doute : la fin suit les dates que l'éditeur inscrit à votre demande (date de fin ; période transitoire si vous la demandez ; effacement immédiat si vous le demandez), et l'application vous les montre à l'écran « Synchro & appareils ».

• Jusqu'à la date de fin, et pendant une période transitoire de trente jours si vous l'avez demandée, le service continue tel quel, sans frais.
• Vient ensuite une lecture seule de trente jours au moins : vos blocs chiffrés restent intacts, vos appareils peuvent encore les tirer, plus en envoyer ; aucune nouvelle relève ne s'ouvre ; la boîte d'identités reste ouverte pour qu'un appareil neuf rapatrie les noms. La lecture reste ouverte jusqu'à l'effacement effectif.
• L'effacement est une procédure outillée de l'éditeur, faite en une seule opération : il efface les opérations chiffrées, les médias, la porte de récupération (enveloppe, part de garde, téléphone, identités sur-scellées), les jours d'horodatage, les messages en attente, les plis d'invitation et chaque compartiment de relève que vous aviez ouvert. Le serveur en rend un reçu (nombres, octets, empreintes, dont la tête de la chaîne d'intégrité de votre journal), et l'éditeur vous adresse une attestation datée qui le cite.
• Restent, sans contenu : la ligne de votre compte (identifiant opaque, marque « révoqué » et dates), vos reçus d'acceptation, le registre des paiements, le journal de la porte de récupération et le lien d'invitation des relèves, pour les durées de 7.6.

Une révocation seule, sans fin de contrat, invalide le jeton d'accès sans rien effacer. Les copies chiffrées disparaissent ensuite des sauvegardes au fil des rotations, en un an au plus, sous la réserve de la copie hors site (corbeille de Proton Drive et restes décrits en 7.4) — une sauvegarde ne se modifie pas à l'unité sans perdre sa valeur de sauvegarde. Cet effacement ne vous décharge pas de la conservation légale du dossier (7.2) : exportez-le (.carnet, et si vous le voulez le journal lisible, 8.2) avant la date de fin.

7.6 Durées de conservation des données propres à l'éditeur. Les durées ci-dessous portent sur les seules données que l'éditeur détient en propre (section 2.2). Elles sont communiquées ici parce que la loi impose de les indiquer en réponse à une demande d'accès (art. 25 al. 2 let. d LPD) et de détruire les données dès qu'elles ne sont plus nécessaires (art. 6 al. 4 LPD). Chaque durée est fondée sur ce qui la rend nécessaire ; au-delà, la donnée est détruite.

8. Droits des personnes concernées (art. 25 ss LPD)

8.1 Les patient·e·s exercent leurs droits auprès de vous, le·la soignant·e. Les droits d'accès, de rectification et d'effacement (art. 25 ss LPD) portent sur des données que seul·e le·la soignant·e peut déchiffrer et identifier. C'est donc auprès de vous, responsable du traitement, que ces droits s'exercent. L'éditeur, dépourvu d'accès au contenu, n'est pas en mesure de les traiter et transmet sans délai au responsable toute demande qu'il recevrait par erreur.

8.2 L'éditeur fournit les outils. Pour vous permettre de répondre à ces demandes et de rester maître de vos données, « Carnet » offre notamment :

(a) le « Dossier complet — droit d'accès (art. 25 LPD) » : un document lisible, imprimable et remissible à la personne concernée, reprenant l'intégralité de son dossier — c'est lui, et lui seul, qui répond à une demande d'accès ;

(b) l'export chiffré .carnet : une sauvegarde de l'ensemble de votre cabinet, qui n'est relisible que par « Carnet » et sur le compte qui l'a produite, et qui contient les dossiers de tous vos patient·e·s. Ce n'est ni un outil de portabilité ni un document remissible à un·e patient·e — le lui remettre violerait le secret professionnel à l'égard de tous les autres ;

(c) la révocation du compte de synchronisation : elle coupe définitivement l'accès de vos appareils au serveur ; les blocs chiffrés déjà déposés y subsistent jusqu'à l'effacement attesté, à la fin du contrat ou sur demande (7.5) ;

(d) l'accès local à l'intégralité du dossier, à tout moment et sans intermédiaire ;

(e) le journal lisible (bouton « Exporter le journal lisible », écran Sauvegarde) : le journal de votre carnet, déchiffré sur votre appareil, dans un fichier JSON que d'autres logiciels savent lire, identités comprises, sans les photos. Ce fichier est en clair : rangez-le comme un dossier papier. Il sert à changer d'outil ou à garder une copie lisible sans Carnet ; ce n'est pas un document à remettre à un·e patient·e (il contient tous vos dossiers) ;

(f) les métadonnées de votre compte que détient le serveur, en un fichier JSON : joint automatiquement au journal lisible, ou remis sur demande par courriel. Il ne contient ni l'empreinte de votre jeton, ni la part de garde, ni aucune adresse IP, et nomme ce qu'il ne contient pas.

8.3 Vos droits vis-à-vis de l'éditeur portent sur les seules données que l'éditeur détient en propre (section 2.2) : coordonnées de facturation, registre des paiements, identifiant de compte, données techniques. Vous pouvez les exercer via le contact indiqué en tête de document. Pour les données de paiement que Paddle détient (5.3), adressez-vous à lui (https://preferences.paddle.com) ; l'éditeur vous y aide.

8 bis. Si vous exercez dans l'Union européenne, l'EEE ou au Royaume-Uni (RGPD)

8 bis.1 Qui est responsable. Pour vos données de professionnelle (souscription, compte, reçus, registre des paiements, récupération, sortie), le responsable du traitement est l'éditeur, dont l'identité et les coordonnées figurent en tête de cette politique. Pour les données de paiement que vous donnez à Paddle, c'est Paddle (1.5, 5.3). Pour les données de vos patient·e·s, c'est vous (section 1.1) ; l'éditeur n'est que votre sous-traitant pour les blocs chiffrés, dans les termes de l'annexe de zone MONDE (5.3).

8 bis.2 Représentant. L'éditeur n'a pas désigné de représentant dans l'Union (art. 27 RGPD) ni au Royaume-Uni. Toute demande s'adresse directement à lui (13.1).

8 bis.3 Registre. L'éditeur tient un registre des traitements (art. 30 RGPD), pour ce qu'il traite pour son compte et comme sous-traitant de chaque cliente, et le remet à l'autorité de contrôle qui le demande.

8 bis.4 Fondements. Chaque traitement et son fondement figurent en section 3. Pour le RGPD : l'exécution du contrat ou des mesures prises à votre demande avant sa conclusion (art. 6 § 1 let. b) — souscription, synchronisation, lien et page de paiement, sortie et effacement ; l'intérêt légitime de l'éditeur (art. 6 § 1 let. f) pour la sécurité du service, la lutte contre l'abus — dont la vérification qu'un essai gratuit n'est ouvert qu'une fois par Client (section 3) —, la preuve de votre acceptation, de vos paiements et de l'effacement ; votre consentement (art. 6 § 1 let. a) pour la seule réponse facultative « Comment avez-vous connu Carnet ? », que vous pouvez retirer à tout moment sans effet sur votre souscription.

8 bis.5 Vos droits. Vous avez le droit d'accéder à vos données, de les faire rectifier ou effacer, d'en faire limiter le traitement, de vous opposer à un traitement fondé sur l'intérêt légitime et de recevoir les données que vous avez fournies dans un format structuré (art. 15 à 21 RGPD) — notamment par le fichier des métadonnées de votre compte (8.2 let. f). L'effacement trouve sa limite dans les durées de la section 7.6, quand une donnée doit être gardée pour la preuve ou la comptabilité. L'éditeur répond dans un délai d'un mois (art. 12 § 3 RGPD), dans votre langue s'il s'agit du français, de l'anglais, de l'allemand, de l'italien ou de l'espagnol. Les décisions automatisées que la section 3 énumère sont nécessaires à l'exécution du contrat (art. 22 § 2 let. a RGPD) : vous pouvez exprimer votre point de vue, les contester et obtenir qu'une personne, l'éditeur, les revoie ().

8 bis.6 Transferts. Vos données de professionnelle sont traitées en Suisse, pays reconnu adéquat (6.2) ; l'identifiant opaque de votre compte part chez Paddle, au Royaume-Uni, et, quand vous payez, ce que la page de paiement transmet à Paddle (5.3).

8 bis.7 Réclamation. Vous pouvez introduire une réclamation auprès de l'autorité de contrôle de l'État de votre résidence habituelle, de votre lieu de travail ou du lieu de la violation alléguée (art. 77 RGPD) ; au Royaume-Uni, auprès de l'Information Commissioner's Office. L'éditeur n'ayant aucun établissement dans l'Union, aucune autorité n'est « chef de file ». Le Préposé fédéral à la protection des données et à la transparence (Suisse) reste compétent au titre de la LPD.

8 bis.8 Vos patient·e·s. Leurs droits s'exercent auprès de vous, comme en section 8.1 ; les outils de la section 8.2 vous servent de la même manière.

8 ter. Si vous exercez en Argentine, au Chili, au Panama ou en Uruguay

8 ter.1 Qui est responsable. Pour vos données de professionnelle (souscription, compte, reçus, registre des paiements, récupération, sortie), le responsable est l'éditeur, dont l'identité et les coordonnées figurent en tête de cette politique. Pour les données de paiement que vous donnez à Paddle, c'est Paddle (5.3). Pour les données de vos patient·e·s, c'est vous (section 1.1) : ce sont des données de santé, sensibles au sens de ces lois ; l'éditeur ne les détient que chiffrées, sans pouvoir les lire, et les héberge pour votre compte (annexe MONDE, M-11.3).

8 ter.2 Contact. L'éditeur n'a de représentant dans aucun de ces pays. Vous, vos patient·e·s et les autorités le joignez à , adresse qu'il tient à jour et en service (au Chili, le moyen de contact que la loi 21.719 demande au responsable qui n'y est pas domicilié), ou aux autres coordonnées de la section 13.1.

8 ter.3 Ce que l'éditeur traite, et pourquoi. Les traitements et leurs finalités sont ceux de la section 3 : exécuter le contrat que vous concluez (souscription, synchronisation, lien de paiement, sortie, effacement), assurer la sécurité du service et la règle d'un seul essai gratuit par Client, et garder la preuve de votre acceptation, de vos paiements et de l'effacement. L'éditeur ne traite aucune donnée de santé en clair, ne vend ni ne cède aucune donnée, et ne fait aucun profilage.

8 ter.4 Vos droits, et le délai de réponse. Vous pouvez demander l'accès à vos données, leur rectification ou leur mise à jour, leur suppression et, là où votre loi le prévoit, vous opposer à un traitement ou en obtenir la portabilité — notamment par le fichier des métadonnées de votre compte (8.2 let. f). La suppression trouve sa limite dans les durées de la section 7.6, quand une donnée doit être gardée pour la preuve. L'éditeur répond dans le délai que fixe la loi de votre pays, et dans votre langue si c'est le français, l'anglais, l'allemand, l'italien ou l'espagnol. L'accès est gratuit.

8 ter.5 Transferts. Vos données de professionnelle sont traitées en Suisse (6.2) ; l'identifiant opaque de votre compte part chez Paddle, au Royaume-Uni, pour le seul paiement que vous faites (5.3).

8 ter.6 Réclamation. Vous pouvez saisir l'autorité de votre pays nommée au tableau de 8 ter.4. Le Préposé fédéral à la protection des données et à la transparence (Suisse) reste compétent au titre de la LPD.

8 ter.7 Vos patient·e·s. Leurs droits s'exercent auprès de vous, comme en section 8.1, dans les délais de votre loi ; les outils de la section 8.2 vous servent de la même manière. L'éditeur vous transmet sans délai toute demande qu'il recevrait par erreur.

9. Sécurité des données (art. 8 LPD, OPDo RS 235.11)

L'éditeur met en œuvre une sécurité appropriée au risque, notamment :

• Chiffrement du contenu au moyen de la bibliothèque libsodium (ChaCha20-Poly1305-IETF), clé maîtresse de 32 octets jamais détenue par l'éditeur ;
• Dérivation de clé par Argon2id (coût MODERATE) à partir de votre mot de passe (plancher 12 caractères + estimateur de robustesse local refusant les mots de passe faibles ; phrase de passe recommandée ; pas de rotation imposée — NIST SP 800-63B), résistance aux attaques par force brute ;
• Serveur « aveugle » : la synchronisation ne manipule que des blocs chiffrés opaques, avec un type d'opération neutralisé côté serveur ;
• Scellement de bout en bout (crypto_box_seal) des transferts d'identités, avec vérification humaine (SAS 4 mots) ;
• Chiffrement des transports (TLS/HTTPS, HSTS) entre vos appareils et le serveur ;
• Auto-verrouillage du coffre local et brouillons chiffrés ;
• Journaux d'accès désactivés : les serveurs ne journalisent aucune requête. L'adresse IP n'est utilisée qu'en mémoire vive, le temps d'appliquer le limiteur de débit, et n'est jamais enregistrée — hors service de récupération, compte et adresse IP ne peuvent donc pas être reliés a posteriori. Seule exception : une demande de récupération de compte, dont l'empreinte de l'adresse (à clé secrète) et la date sont conservées comme preuve contre une demande frauduleuse (4.4) ;
• pare-feu, fail2ban, accès SSH par clé uniquement (compte root désactivé), sauvegardes chiffrées, hébergement en Suisse.

La robustesse de cette protection repose de manière déterminante sur la confidentialité de vos secrets (mot de passe, clé de secours), que vous êtes seul·e à détenir : gardez-les de manière sûre, distincte et durable.

Vérifiabilité. Le code de « Carnet » est libre (AGPLv3) et destiné à être publiquement auditable à l'adresse https://carnet.health/source/, où l'archive de chaque version publiée est déposée et vérifiée à chaque mise en ligne. Ces propriétés sont vérifiables par vous ou par tout tiers de votre choix.

10. Limites honnêtes du modèle zero-knowledge (métadonnées)

Le modèle « le serveur ne peut pas lire » est réel et vérifié par les tests : le serveur de synchro ne déchiffre rien ; il stocke et rend des blocs chiffrés. La clé (CMK) ne quitte jamais l'appareil ; le mot de passe, la clé de secours et la biométrie ne transitent jamais par le serveur. L'éditeur non plus ne peut pas lire les dossiers (il n'a pas la CMK).

Par honnêteté, et sans surpromesse : le zero-knowledge protège le contenu, pas toutes les métadonnées. Un opérateur qui observerait le serveur en fonctionnement pourrait voir : l'identifiant de compte (un pseudonyme opaque, non dérivé de données patient, mais présent dans les chemins d'URL), la taille des blocs (par ex. distinguer une photo d'une note), la cadence d'activité et le graphe des appareils reliés — jamais le contenu médical, jamais les noms. Le modèle de menace retenu est « opérateur curieux » : c'est pourquoi les journaux d'accès du serveur sont désactivés — rien n'est écrit, l'adresse IP ne vit qu'en mémoire vive pour le limiteur de débit : hors service de récupération, compte et adresse IP ne peuvent pas être reliés a posteriori. Ces métadonnées ne sont observables qu'en direct par qui exploite le serveur, et ne se reconstituent pas après coup à partir d'un journal — à une exception près : pour l'horodatage d'intégrité, le serveur garde, par compte, les jours où le journal a changé (table des ancres), sans rien de leur contenu. Le rembourrage (padding) des blobs n'est délibérément pas mis en œuvre (hors modèle pour un hébergement maîtrisé). Enfin, la facture transmise à l'assureur sort, elle, du modèle zero-knowledge : elle est en clair, par obligation légale (section 5.2).

11. Violations de la sécurité des données (art. 24 LPD)

11.1 Un bloc chiffré qui fuit est inexploitable. En cas d'incident affectant le serveur de synchronisation, ce qui pourrait être exposé se limite à des blocs chiffrés inintelligibles et à des identifiants opaques : aucune donnée patient en clair n'est exposée. Une telle violation n'est donc, en principe, pas de nature à entraîner un risque élevé pour les personnes concernées (art. 24 al. 1 LPD). Il s'agit d'une mention honnête, non d'une garantie que rien ne peut jamais arriver.

11.2 Qui annonce quoi. L'éditeur annonce sans délai au responsable du traitement (vous) toute violation affectant les données confiées. L'appréciation de la nécessité d'annoncer au PFPDT/EDÖB et aux personnes concernées incombe en dernier ressort à vous (responsable), l'éditeur vous prêtant l'assistance raisonnable. Pour les données que l'éditeur détient en propre, il assume ses propres obligations d'annonce. Une violation chez Paddle relève de Paddle, qui l'annonce lorsque la loi l'exige ; l'éditeur vous en informe dès qu'il en a connaissance.

12. Cookies et stockage local

12.1 Aucun cookie tiers, aucun traceur publicitaire. « Carnet » n'utilise aucun cookie de suivi, aucun pixel, aucune balise tierce — ni dans l'application, ni sur la vitrine, page de prix comprise. Seule la page de paiement carnet.health/paiement/ charge le module de paiement de Paddle : au chargement, il dépose un seul cookie technique de protection contre les robots (__cf_bm, domaine paddle.com, trente minutes, mesuré le 9 octobre 2026, page chargée sans transaction) ; ce que le formulaire de paiement de Paddle dépose ou lit ensuite sert au paiement et à la prévention de la fraude, et relève de sa politique (5.3). L'application recourt uniquement à du stockage local technique sur votre appareil (IndexedDB), nécessaire à son fonctionnement hors ligne et à la conservation chiffrée de votre coffre. Ces données restent sur votre appareil et ne sont pas transmises à l'éditeur en clair.

13. Contact, modifications, date

13.1 Contact. Pour toute question relative à la présente politique ou à l'exercice de vos droits sur les données détenues par l'éditeur : , par téléphone au +41 77 276 96 99, ou par courrier à David Lambrecht, Rue du Bourg 55, 3960 Sierre (VS), Suisse. Une adresse électronique seule ne suffirait pas pour l'exercice formel d'un droit d'accès : l'adresse postale est donc indiquée, et non plus communiquée sur demande.

13.2 Modifications. L'éditeur peut adapter la présente politique pour tenir compte d'évolutions techniques, légales ou du service. Toute modification est communiquée par affichage dans l'application ou par voie électronique. La version applicable est celle en vigueur au moment de votre utilisation ; la date et le numéro de version figurent en tête de document.

13.3 Droit applicable. La présente politique et les traitements qu'elle décrit sont soumis au droit suisse, en particulier la LPD (RS 235.1) et l'OPDo (RS 235.11). Pour les traitements liés à l'offre du service géré dans l'Espace économique européen, le RGPD s'applique en outre (art. 3 § 2 let. a), et, au Royaume-Uni, le RGPD tel que repris en droit britannique : la section 8 bis en réunit les mentions.