Politique de confidentialité — « Carnet »
Éditeur / responsable de la présente politique David Lambrecht, éditeur du logiciel « Carnet », Sierre (canton du Valais), Suisse. Contact protection des données : .
Version : v0.470.0 — 27.08.2026. Droit applicable : droit 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 votre seul mot de passe et de votre clé de secours. 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, et il ne peut rien restaurer à lui seul. Une porte de secours existe, la Feuille de récupération (section 3.1) : elle n'est ouverte que si vous l'avez activée, et seulement en réunissant vos huit mots et une part conservée par l'éditeur, dont aucune ne vaut sans l'autre. Le serveur de synchronisation 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 partage avec des tiers. C'est le contraire d'une politique de confidentialité habituelle : nous ne « collectons » quasiment rien, parce que techniquement nous ne le pouvons pas.
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 nLPD, 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 nLPD), 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 (DPA intégré, contrat-lien.md section 9).
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 (base légale : exécution du contrat et sécurité du système, art. 31 nLPD). Ces données ne comprennent aucune donnée de patient.
2. Quelles données l'éditeur voit réellement
Ce que l'éditeur peut techniquement voir se limite à ce qui suit.
| Donnée | Ce que c'est | Ce que l'éditeur en voit |
|---|---|---|
| Identifiant de compte de synchro | Un jeton opaque, non nominatif | Un identifiant sans lien avec un nom de patient ni de soignant en clair |
| Blocs chiffrés | Le journal du dossier, chiffré de bout en bout | Des octets inintelligibles ; aucune donnée en clair |
| Métadonnées de synchro | Horodatages, volumes, compteurs, données d'appairage | Le fait qu'une synchro a eu lieu, sa taille — pas son contenu |
| Données techniques serveur | Journaux d'accès désactivés. Aucune adresse IP n'est enregistrée : elle ne sert qu'en mémoire vive à limiter le débit des requêtes, puis disparaît | Rien n'est conservé. Deux exceptions : ① le service de récupération de compte — chacune de ses étapes, y compris sa mise en place et sa désactivation, est consignée avec l'adresse et la date, dans un journal en ajout seul, où toute altération serait détectable. C'est ce qui vous protège d'une demande frauduleuse ; pour qui utilise ce service, compte et adresse peuvent donc être reliés. ② Le journal des remises du certificat MediData (voir plus bas) : compte, date, issue — sans adresse IP, purgé à un an |
| Données de facturation du service | Coordonnées de facturation de l'abonnement | Vos coordonnées à vous (le soignant), jamais celles d'un patient |
| Quotas du compte | Deux compteurs : nombre d'opérations poussées, volume d'octets stockés | Ces deux nombres, en clair — ils font respecter les plafonds anti-abus. Jamais le détail de ce qui a été poussé |
| Reçu d'acceptation des conditions | La version des conditions que vous avez acceptée, les horodatages de vos accusés de lecture, et la date de réception par le serveur | Ces éléments, en clair. Aucune donnée de patient : c'est la preuve que l'éditeur doit pouvoir produire, et qu'il ne saurait tirer de votre coffre, qu'il ne peut pas ouvrir |
| Origine du compte et graphe des invitations | Le code d'invitation qui a servi à créer votre compte, son type (« standard » ou « relève »), le compte qui l'a émis, et l'état de révocation | En clair : l'éditeur voit quel compte a invité quel autre compte, et si ce lien est une relève. Ce sont des données de professionnel·le·s, jamais de patient·e·s ; elles reconstituent, à ce titre, un réseau professionnel |
| Raccordement MediData (si l'envoi électronique des factures est ouvert sur votre compte) | Votre numéro de raccordement MediData, le droit d'utiliser le certificat de l'éditeur, et un journal des remises de ce certificat : compte, date, issue | Ces éléments, en clair — mais aucune facture, aucun nom, aucun n° AVS, aucune réponse d'assureur : le connecteur installé sur votre poste parle directement à MediData. Le seul fait appris ici est « ce compte a démarré son connecteur à telle heure ». Ce journal est purgé à un an |
| Enveloppe de récupération (déposée uniquement si vous activez la porte — choix exprès, révocable) | Part scellée inutilisable seule + enveloppe sur-scellée (identités comprises) | Des blocs inertes, ouvrables seulement en réunissant vos 8 mots et la part conservée séparément — ni l'éditeur ni le serveur ne peuvent rien en lire |
| Téléphone de vérification (récupération) | Le numéro que vous enregistrez pour la vérification d'identité du jour J | Ce numéro, à vous — utilisé uniquement pour la procédure de libération |
| Compartiment de relève (si vous confiez une tournée à une remplaçante) | Un compte de synchronisation dédié à la remplaçante et les amorces chiffrées du compartiment | Un compte supplémentaire et des blocs chiffrés ; ni les identités, ni les dossiers transmis, qui ne sont lisibles que sur l'appareil de la remplaçante |
2.1 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 — rien de tout cela ne quitte votre appareil en clair.
2.2 Aucun traçage, aucun tiers, 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 n'autorise, hors de l'application elle-même, que les serveurs de synchronisation de « Carnet » et, sur votre propre ordinateur, le connecteur qui transmet vos factures aux assureurs — aucun autre hôte. Il n'y a ni régie publicitaire, ni analytique comportementale, ni revente de données. L'application fonctionne localement (hors ligne d'abord).
3. Vos données de santé : chiffrées et sous votre seul contrôle
3.1 Chiffrement sur l'appareil. Le dossier de soins (journal d'événements chiffré) est chiffré sur votre appareil, au moyen de clés dérivées de votre mot de passe et de votre clé de secours, que vous êtes seul·e à détenir. L'éditeur ne détient aucune clé qui ouvre un dossier et aucune porte dérobée. Il dispose d'un jeton d'administration pour exploiter le serveur : il n'ouvre aucun dossier, et il ne le pourrait pas — le serveur n'héberge que des blocs chiffrés. Il conserve par ailleurs, pour les seuls comptes qui ont activé la Feuille de récupération (section 2), une part inutilisable seule, qui n'a de sens qu'assemblée à vos huit mots, sur votre appareil. Le code étant libre (AGPLv3) et publiquement auditable, cette absence de porte dérobée est vérifiable par vous ou par tout tiers de votre choix.
3.2 L'identité nominative ne circule jamais avec la synchronisation courante. Nom, prénom, date de naissance, sexe, n° AVS, n° de carte, rue, téléphone, e-mail et assureur sont filtrés avant tout envoi au serveur : la réplication entre vos appareils ne les transporte pas. Seuls la commune, le NPA et la localité voyagent, chiffrés, avec le reste du dossier.
3.3 Trois canaux scellés, que vous déclenchez. L'identité ne sort de votre appareil que par les trois voies suivantes, toutes opaques pour l'éditeur comme pour le serveur :
① Transfert d'appareil à appareil. Lors de l'appairage d'un second appareil, les identités voyagent dans une boîte scellée vers le seul appareil destinataire, la correspondance étant vérifiée par la confrontation humaine de quatre mots. Le serveur ne relaie que des blocs qu'il ne peut ni lire ni forger.
② Enveloppe de récupération. Pour vous permettre de retrouver vos dossiers en cas de perte de votre mot de passe, une enveloppe scellée est déposée sur le serveur — uniquement si vous activez cette porte, choix exprès et révocable, jamais fait à votre place. Elle est chiffrée deux fois et ne peut être ouverte qu'en réunissant plusieurs secrets détenus séparément, dont l'un est le vôtre. Le serveur, à lui seul, en est incapable.
③ Relève par un·e remplaçant·e. Lorsque vous confiez des patient·e·s à un·e collègue, l'identité et le dossier des seul·e·s patient·e·s désigné·e·s lui sont transmis, scellés vers sa clé. C'est la seule voie par laquelle ces données parviennent à une autre personne — vous en informez vos patient·e·s, qui peuvent s'y opposer, et la·le remplaçant·e signe un engagement de confidentialité.
3.4 La facture à l'assureur, elle, part en clair. Ce n'est pas un canal scellé et nous ne le présentons pas comme tel : la loi (art. 42 LAMal) impose de transmettre à l'assureur une facture nominative. Elle contient le nom, le prénom, la date de naissance, le sexe, le n° AVS et l'adresse du·de la patient·e, les prestations facturées, ainsi que l'identité du médecin prescripteur et l'indication médicale justifiant les soins. Cette transmission est une obligation légale, non un choix de conception.
4. Hébergement et localisation
4.1 Hébergement en Suisse. Les blocs chiffrés confiés au service de synchronisation sont hébergés sur des infrastructures situées en Suisse chez Infomaniak (Genève, Suisse), qui indique exploiter des centres de données certifiés ISO 27001. Une copie de sauvegarde quotidienne est tirée hors de cet hébergement, sur un support détenu par l'éditeur, en Suisse également, et sans aucun hébergeur tiers (section 7).
4.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 nLPD) ou sous une garantie de l'art. 16 al. 2 nLPD, et resteraient inintelligibles. Vous en seriez informé au préalable.
5. Durée de conservation
5.1 Côté éditeur : quasiment rien, et rien d'exploitable. L'éditeur conserve les blocs chiffrés aussi longtemps que votre compte de synchronisation existe. À la résiliation, la révocation coupe l'accès immédiatement ; l'effacement des blocs sur le serveur est ensuite une opération manuelle de l'éditeur, qu'aucune procédure automatique ne déclenche. Nous préférons vous le dire plutôt que de vous promettre l'inverse : les copies de sauvegarde ne sont pas purgées. Elles sont tirées chaque jour hors du serveur et conservées comme historique ; un effacement fait sur le serveur ne s'y propage pas. Ces copies contiennent les mêmes blocs chiffrés et les mêmes données de compte (section 2) — aucune donnée de patient en clair, et rien que l'éditeur puisse lire, faute de vos clés. Ni leur conservation ni leur effacement n'affectent votre propre accès à vos données, qui sont sur votre appareil. Aucun journal d'accès n'est conservé et aucune adresse IP n'est enregistrée (section 2). Font exception les étapes du service de récupération, consignées avec l'adresse et la date, et le journal des remises du certificat MediData, purgé à un an.
5.2 Côté vous : la conservation légale du dossier vous incombe. La conservation du dossier de soins pendant la durée légale — jusqu'à 20 ans selon les cas (10 ans pour les pièces de facturation) — relève de votre seule responsabilité, car l'éditeur ne peut ni lire ni conserver pour vous un contenu chiffré. Les modalités et le fondement de cette obligation sont détaillés dans le contrat (contrat-lien.md, section 10). « Carnet » vous fournit les outils (export .carnet, sauvegardes, dépositaire) ; la garde durable reste la vôtre.
6. Droits des personnes concernées (art. 25 ss nLPD)
6.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 nLPD) 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.
6.2 L'éditeur fournit les outils — deux exports, à ne pas confondre. (a) L'export chiffré .carnet est votre sauvegarde intégrale : chiffré sous votre clé, il ne se restaure que sur votre propre compte et contient les dossiers de tou·te·s vos patient·e·s — il ne se remet donc jamais à un·e patient·e (il ne pourrait pas l'ouvrir, et le lui donner porterait atteinte au secret dû aux autres). Il vaut restitution complète à l'égard de l'éditeur, qui n'a rien d'autre à restituer qu'il puisse lire. (b) Pour une personne qui exerce ses droits, l'outil est l'export « Dossier complet du patient — droit d'accès (art. 25 LPD) » : un document lisible, produit par patient·e (PDF, ODT ou DOCX), avec l'historique entier et, sur option, les photos de plaies les plus récentes (le document indique ce qu'il ne reprend pas). S'y ajoutent la révocation du compte de synchronisation — elle coupe l'accès immédiatement, mais l'effacement des blocs chiffrés est une opération manuelle de l'éditeur — et l'accès local à l'intégralité du dossier.
6.2bis Vous restez tenu·e de répondre, même si l'éditeur ne peut pas lire. Le responsable du traitement qui recourt à un sous-traitant demeure tenu de fournir les renseignements demandés (art. 25 al. 4 LPD) : l'architecture ne crée aucune lacune, l'obligation n'a jamais quitté le·la soignant·e. Nul ne peut renoncer par avance au droit d'accès (art. 25 al. 5 LPD) ; les renseignements sont en principe gratuits et donnés dans les 30 jours (art. 25 al. 6 et 7 LPD) ; et des données de santé peuvent, avec l'accord de la personne, lui être communiquées par l'intermédiaire d'un·e professionnel·le de la santé qu'elle désigne (art. 25 al. 3 LPD).
6.3 Vos droits vis-à-vis de l'éditeur portent sur les seules données que l'éditeur détient en propre (section 2) : coordonnées de facturation, identifiant de compte, journaux techniques. Vous pouvez les exercer via le contact indiqué en tête de document.
7. Sécurité des données (art. 8 nLPD, OPDo RS 235.11)
L'éditeur assure une sécurité appropriée au risque, notamment :
- Chiffrement de bout en bout au moyen de la bibliothèque libsodium, sans que l'éditeur ne détienne de clé de déchiffrement ;
- Dérivation de clé par Argon2id à partir de votre mot de passe (résistance aux attaques par force brute) ;
- Serveur « aveugle » : la synchronisation ne manipule que des blocs chiffrés opaques ;
- Chiffrement des transports (TLS) entre vos appareils et le serveur ;
- Auto-verrouillage du coffre local et brouillons chiffrés ;
- Cloisonnement des accès, journal en ajout seul des étapes du service de récupération, où toute altération serait détectable, copie de sauvegarde tirée quotidiennement hors du serveur, sur un support détenu par l'éditeur (aucun hébergeur tiers) : elle contient exactement ce que contient le serveur — les mêmes blocs chiffrés et les mêmes données de compte (section 2), donc aucune donnée de patient en clair. Hébergement en Suisse.
La robustesse de cette protection repose de manière déterminante sur la confidentialité de votre mot de passe et de votre clé de secours, que vous êtes seul·e à détenir : gardez-les de manière sûre, distincte et durable.
8. Violations de la sécurité des données (art. 24 nLPD)
8.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 nLPD). Il s'agit d'une mention honnête, non d'une garantie que rien ne peut jamais arriver.
8.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.
9. Cookies et traceurs
9.1 Aucun cookie tiers, aucun traceur publicitaire. « Carnet » n'utilise aucun cookie de suivi, aucun pixel, aucune balise tierce. L'application recourt uniquement à du stockage local technique sur votre appareil (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.
10. Contact, modifications, date
10.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 : , David Lambrecht, Sierre (VS), Suisse.
10.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.
10.3 Droit applicable. La présente politique et les traitements qu'elle décrit sont soumis au droit suisse, en particulier la nLPD (RS 235.1) et l'OPDo (RS 235.11).