Le nom de vos patients
ne quitte jamais votre appareil.

KinéScribe a été conçu pour qu'il soit techniquement impossible à nos serveurs — et au modèle d'IA derrière — de voir le nom, le téléphone ou l'adresse d'un de vos patients. Pas par promesse, par architecture. Cette page explique exactement comment.

Le principe en 30 secondes

Avant qu'une requête ne parte de votre navigateur vers le modèle d'IA, KinéScribe remplace localement chaque identifiant (nom, prénom, téléphone, numéro de sécu, dates de naissance, adresse, email) par un marqueur neutre du type [[PRENOM]]. L'IA reçoit une saisie clinique cohérente mais désidentifiée. À la réception du texte généré, votre navigateur restitue les vraies données dans le document final, qui n'existe en clair que sur votre machine.

Les étapes 1 et 4 se passent dans votre navigateur. L'étape 2 voyage chiffrée en TLS. L'étape 3 voit du texte cliniquement utile, mais identitairement vide.

Ce que l'IA voit. Ce qu'elle ne voit jamais.

Comparaison précise du payload reçu par le modèle d'IA pour un compte-rendu type :

✓ Ce que l'IA reçoit	✗ Ce qu'elle ne reçoit jamais
[[PRENOM]] [[NOM]], 58 ans, M	M. Jean Dupont
Diagnostic : lombalgie chronique L4-L5	Adresse du patient
EVA douleur : 4/10 vs 7/10 à J0	Code postal et ville
Schober : +4,5 cm	Numéro de sécurité sociale
Techniques : renforcement, gainage transverse	Téléphone du patient
Notes anonymisées : « bonne adhésion »	Email du patient
Type de document : compte-rendu	Date de naissance complète
Vocabulaire MKDE FR à utiliser	N° RPPS / ADELI du prescripteur

La colonne de gauche est cliniquement complète. La colonne de droite est tout ce qui pourrait identifier un patient — et qui ne quitte jamais votre navigateur.

Les 4 couches de protection

La sécurité de KinéScribe ne tient pas à un seul mécanisme mais à quatre couches indépendantes. Pour qu'une donnée patient fuite, il faudrait que les quatre échouent simultanément.

Et concrètement, en cas de…

Quatre scénarios réalistes, et ce qui se passe vraiment :

Vol de votre ordinateur ou téléphone

Le voleur trouve l'application KinéScribe ouverte ou cachée. Toutes les données locales sont chiffrées par votre master_key. Sans votre mot de passe (ou sans votre phrase), le contenu reste un bruit binaire.

Verdict : données illisibles tant que mot de passe et phrase ne sont pas compromis.

Faille chez Supabase (notre hébergeur cloud)

Un attaquant exfiltre la base. Il récupère des blobs chiffrés AES-256-GCM. La master_key qui les déchiffre n'a jamais été stockée chez Supabase — elle est dérivée de votre mot de passe via PBKDF2 dans votre navigateur uniquement.

Verdict : données patient inutilisables sans les mots de passe individuels.

Demande judiciaire à KinéScribe

Une autorité requiert l'accès aux dossiers patient d'un kiné précis. Sur le périmètre identifiant patient (noms, adresses), nous ne pouvons techniquement pas les livrer — nous ne les avons pas en clair. Sur le périmètre compte utilisateur (email, facturation), nous appliquons la procédure légale habituelle.

Verdict : coopération limitée par l'architecture, pas par bonne volonté.

Vous oubliez votre mot de passe

Vous utilisez votre phrase de récupération 24 mots. Elle déverrouille la master_key via une seconde clé dérivée (recovery_key). Vous définissez ensuite un nouveau mot de passe. Sans la phrase et sans le mot de passe, en revanche, aucune récupération n'est possible — c'est précisément ce qui garantit que personne d'autre n'y accède non plus.

Verdict : récupération possible si phrase conservée. Pas de bypass administrateur côté KinéScribe.

Comparaison d'architecture : Markus Santé vs KinéScribe

Markus Santé est un acteur sérieux du marché. La différence n'est pas une question de qualité, mais d'architecture. Voici les choix de conception comparés, à plat.

Critère	Markus Santé	KinéScribe
Identifiants patient envoyés à l'IA	Données patient transmises aux serveurs Markus, qui les passent au modèle	Anonymisation locale avant envoi — l'IA ne voit jamais le nom en clair
Hébergement	Serveurs certifiés HDS (Hébergeur de Données de Santé)	Supabase (UE) avec données chiffrées E2E côté client
Données stockées en clair côté éditeur	Oui, sous protection HDS	Non — chiffrement AES-256-GCM côté navigateur
Modèle de chiffrement	Chiffrement at-rest et in-transit selon protocole HDS	End-to-End : la clé de déchiffrement reste sur votre poste
Récupération de compte	Réinitialisation par email standard	Mot de passe ou phrase BIP39 24 mots
Certification HDS	Oui	Non — architecture rend l'HDS partiellement hors périmètre côté identifiants patient
En cas de fuite serveur	Données protégées par les contrôles HDS de l'hébergeur	Blobs chiffrés inexploitables sans le mot de passe de chaque utilisateur

Questions fréquentes sur la sécurité

Comment puis-je vérifier que les données patient ne quittent pas mon navigateur ?

Ouvrez l'onglet « Réseau » des outils développeur de votre navigateur (Chrome : F12, puis « Network »). Saisissez une fiche patient avec le nom « Jean Dupont », générez un compte-rendu, puis filtrez les requêtes envoyées à l'API. Vous verrez le payload sortant : le nom est déjà remplacé par [[PRENOM]] [[NOM]] avant que la requête ne quitte votre poste. C'est observable, pas une promesse.

Si vos serveurs sont piratés, qu'est-ce qui fuite ?

Les blobs chiffrés stockés sur Supabase. Comme la master_key qui les déchiffre est dérivée de votre mot de passe par PBKDF2 600 000 itérations et n'est jamais transmise à nos serveurs, un attaquant qui exfiltrerait la base obtiendrait des données inexploitables sans votre mot de passe. Les identifiants patient en clair n'ont jamais été chez nous.

Et si je perds mon mot de passe ?

Vous avez une seconde clé de secours : votre phrase de récupération BIP39 (24 mots) générée à l'inscription. Elle est dérivée par PBKDF2 et permet de déverrouiller votre master_key indépendamment du mot de passe. Conservez-la hors-ligne (papier, coffre, gestionnaire de mots de passe). Sans mot de passe et sans phrase, les données sont définitivement irrécupérables — c'est le prix à payer pour qu'elles soient inaccessibles à un tiers.

Une phrase de 24 mots, c'est vraiment sûr ?

Oui. BIP39 est le standard utilisé par Bitcoin et les portefeuilles cryptographiques pour sécuriser des sommes importantes. Une phrase de 24 mots représente 256 bits d'entropie — soit un nombre de combinaisons supérieur au nombre d'atomes dans l'univers observable. Une attaque par force brute est mathématiquement impossible avec les ressources informatiques actuelles ou prévisibles.

KinéScribe est-il certifié HDS ou ISO 27001 ?

Pas à ce jour. Notre architecture Zero-Knowledge réduit le périmètre concerné par ces certifications : les données patient identifiantes n'étant jamais transmises à nos serveurs, l'hébergement HDS — pensé pour protéger les données de santé stockées chez l'hébergeur — devient partiellement non-applicable à notre périmètre. Nous étudions une certification pour la partie comptes utilisateurs et facturation. Nous refusons en revanche de prétendre à des certifications que nous n'avons pas.