Annexe aux conditions d’utilisation
Sécurité et protection des données
Version : securite-2026-09-14-v1 · Mise à jour le 14 septembre 2026
A1. Objet, portée et valeur contractuelle
La présente annexe décrit les mesures techniques et organisationnelles que CabIMed met en œuvre pour protéger les données traitées par la plateforme. Elle fait partie intégrante des conditions d’utilisation et complète la politique de confidentialité.
Elle couvre la plateforme hébergée : agenda, prise de rendez-vous, espace patient, espace professionnel, secrétariat et sites professionnels. Les logiciels installés sur le poste du professionnel relèvent d’une documentation distincte, leur modèle de sécurité étant différent.
Engagement de niveau, non de réglage. Les valeurs chiffrées mentionnées ci-après (seuils, durées, fréquences) décrivent la configuration en vigueur à la date de cette annexe. Elles peuvent être ajustées à tout moment pour maintenir ou renforcer le niveau de protection décrit, sans que cet ajustement constitue une modification du contrat. L’engagement porte sur les mesures et leur finalité, non sur la valeur exacte d’un paramètre d’exploitation.
Obligation de moyens renforcée. CabIMed met en œuvre les mesures décrites avec la diligence attendue d’un professionnel du secteur. Aucun système d’information ne permettant d’exclure tout risque, la présente annexe ne constitue pas une garantie d’absence d’incident.
A2. Hébergement et localisation des données
La plateforme est hébergée chez OVHcloud (OVH SAS, société de droit français, siège à Roubaix), sur un serveur privé dédié à CabIMed, à l’exclusion de tout hébergement mutualisé partagé avec des tiers.
Le bloc d’adresses du serveur est enregistré auprès du registre européen RIPE au nom d’OVH SAS en France. Le traitement a lieu dans l’Union européenne, sous le régime du règlement (UE) 2016/679.
La sécurité physique des installations relève de l’hébergeur : contrôle d’accès aux centres de données, redondance électrique et réseau, surveillance permanente.
L’API applicative et la base de données ne sont pas exposées sur le réseau public : elles ne sont joignables que depuis le serveur lui-même. Un serveur frontal constitue l’unique point d’entrée, et n’accepte que des connexions chiffrées.
A3. Chiffrement des données
En circulation. Toutes les communications sont chiffrées par TLS. Les accès non chiffrés sont redirigés de façon permanente. Une directive de transport strict est transmise au navigateur, qui refuse ensuite de lui-même toute connexion en clair. Les cookies de session ne circulent que sur canal chiffré.
Au repos. Les données sensibles sont chiffrées par l’application avant écriture en base de données, au moyen d’un chiffrement authentifié de niveau AES-256-GCM. Sont couverts :
- le numéro d’identification au registre national (NISS) ;
- le texte clinique libre : notes de consultation, observations, notes attachées à un rendez-vous ;
- les messages échangés avec le patient, les demandes, les renouvellements et les discussions d’équipe ;
- le contenu des pièces jointes : ordonnances, résultats, documents déposés ;
- les secrets techniques : jetons d’agendas externes, identifiants de messagerie, secrets de double authentification, clés d’intégration.
Il en résulte qu’une copie brute de la base de données ne restitue ni contenu clinique, ni message, ni pièce jointe, ni numéro national lisibles.
Recherche sans exposition. La recherche d’un patient par numéro national et la détection des doublons reposent sur une empreinte cryptographique à clé dérivée, et non sur une conservation en clair du numéro.
Refus de fonctionnement dégradé. En production, l’application refuse de démarrer si la clé de chiffrement est absente ou invalide. Il n’existe aucun mode de repli dans lequel des données de santé seraient écrites en clair.
A4. Authentification et gestion des accès
Mots de passe. Aucun mot de passe n’est conservé en clair ni sous forme réversible. Les empreintes sont produites par une fonction de dérivation lente à sel unique, paramétrée pour rendre une attaque hors ligne économiquement dissuasive. Il en va de même des codes de récupération.
Double authentification. Une double authentification par application (TOTP) est disponible pour les professionnels et les opérateurs de secrétariat, assortie de codes de récupération à usage unique. Le secret correspondant est chiffré en base. Son activation relève de l’utilisateur ou de la politique interne du cabinet.
Sessions. Les jetons de session sont transportés par des témoins de connexion inaccessibles au code exécuté dans la page, limités à l’hôte exact et restreints par chemin. Les sessions sont révocables, les jetons expirés purgés automatiquement, et le professionnel peut consulter et révoquer la liste de ses postes connectés.
Jetons à usage restreint. Un jeton émis pour une finalité déterminée — étape de double authentification, réinitialisation de mot de passe, élévation temporaire — ne peut en aucun cas servir de jeton d’accès aux données.
Accès d’exploitation. L’accès à la console d’administration du service est soumis à une chaîne de contrôles cumulatifs : restriction réseau, session valide, appartenance à une liste nominative d’administrateurs, puis ré-authentification à durée courte avant toute opération sensible. Chaque tentative, aboutie ou non, est journalisée.
Accès système. L’accès au système d’exploitation s’effectue par clé cryptographique, l’authentification par mot de passe et la connexion directe au compte d’administration étant désactivées. Un dispositif de bannissement automatique écarte les adresses présentant un comportement de recherche d’identifiants. Les correctifs de sécurité du système sont appliqués automatiquement.
Obligations de l’utilisateur. Conformément à l’article 4 des conditions d’utilisation, chaque utilisateur conserve ses identifiants confidentiels, configure les droits de son équipe et signale sans délai tout usage suspect. Les mesures décrites ici ne couvrent pas la divulgation d’identifiants par leur titulaire.
A5. Protection contre l’intrusion et l’usage abusif
La plateforme applique une défense par couches superposées. Sont notamment en place :
- Verrouillage temporaire du compte au-delà d’un nombre limité d’échecs rapprochés, indépendamment de l’adresse réseau d’origine — une tentative répartie sur de nombreuses adresses se heurte au même compteur ;
- limitation de débit générale par adresse, renforcée par des limitations dédiées sur les routes sensibles ou facturables ;
- requêtes de base de données systématiquement paramétrées, excluant la construction de requêtes par assemblage de texte ;
- validation stricte des données entrantes : les champs non prévus sont retirés de la requête avant traitement ;
- protection contre l’exécution d’actions depuis un site tiers : toute modification issue d’une session par témoin exige une origine autorisée ;
- politique d’origines croisées fermée par défaut en production ;
- contrôle des envois volumineux : authentification vérifiée avant toute allocation de mémoire ;
- vérification par signature cryptographique des événements transmis par les opérateurs tiers ;
- en-têtes de sécurité sur les écrans applicatifs, écrans authentifiés exclus du cache et de l’indexation ;
- documentation technique de l’interface de programmation désactivée en production.
Absence de donnée de santé dans les adresses web. Aucun identifiant de patient, numéro national ou motif de consultation n’est placé dans une adresse web, un outil de mesure d’audience, une carte publique ou un plan de site.
A6. Cloisonnement entre cabinets et entre rôles
Chaque requête portant sur des données privées est rattachée à un cabinet et soumise à un contrôle d’autorisation exécuté côté serveur, avant toute lecture. Ce contrôle ne relève pas de l’affichage : une requête formée manuellement est soumise aux mêmes vérifications.
Les ensembles de fonctions sensibles sont fermés par défaut : une fonction nouvelle est réservée au professionnel tant qu’une ouverture n’a pas été déclarée explicitement.
Délégation nominative. Un membre du secrétariat agit sous un compte nominatif, et son accès à un professionnel déterminé résulte d’une délégation explicite, de niveau réglable et révocable. Cette délégation est vérifiée en base à chaque requête : son retrait, la révocation d’une session ou la désactivation du compte prennent effet immédiatement, sans attendre l’expiration d’une session en cours.
Certaines opérations ne sont jamais délégables, notamment les réglages personnels du professionnel, le changement de mot de passe, la gestion des clés d’intégration, la clôture de compte et la suppression définitive d’un rendez-vous.
Relations entre professionnels. L’existence d’un lien confraternel n’emporte par elle-même aucun droit d’accès. Les autorisations résultent exclusivement d’un partage accepté, dans le sens du titulaire vers le destinataire, l’accès à la patientèle supposant un droit distinct accordé expressément.
Intervention d’assistance. Une intervention de CabIMed sur un compte, à la demande ou avec l’accord du professionnel, s’effectue par une session dédiée, de courte durée, non renouvelable et journalisée.
A7. Journalisation et traçabilité des accès
CabIMed tient un journal d’audit applicatif, distinct des journaux techniques d’exploitation, destiné à satisfaire l’obligation de démonstration prévue aux articles 5.2, 30 et 32 du règlement général sur la protection des données.
Chaque entrée comporte l’horodatage, le type et l’identité de l’auteur de l’action dans sa propre série d’identifiants, la nature de l’opération, l’objet concerné et l’adresse réseau d’origine.
Les consultations sont journalisées, et non les seules modifications. L’ouverture d’un dossier individuel — fiche patient, rendez-vous, demande, message, renouvellement — donne lieu à une entrée, de même que les opérations métier sensibles.
L’écriture du journal n’interrompt pas le traitement de la requête ; un échec d’écriture est lui-même enregistré avec l’action tentée, afin de permettre sa reconstitution.
Journaux techniques. Les journaux d’exploitation sont expurgés automatiquement des identifiants directs — numéro national, adresse électronique, numéro de téléphone mobile — avant écriture.
A8. Sauvegardes, continuité et restitution
Sauvegardes. Une sauvegarde complète de référence est réalisée quotidiennement, complétée par des sauvegardes intermédiaires en journée. Chaque sauvegarde est un instantané cohérent de la base et est chiffrée avant écriture.
Conservation de la clé hors du serveur. Le secret permettant de déchiffrer les sauvegardes n’est pas conservé sur le serveur sauvegardé. L’obtention du serveur ne donne donc pas accès au contenu des archives.
Copie hors site. Les sauvegardes sont recopiées sur une machine distincte, avec vérification de la bonne réception.
Restauration. La procédure de restauration est documentée et fait l’objet de scripts de test exécutables. La fraîcheur des sauvegardes est contrôlée automatiquement.
Continuité. Chaque version du service est déployée de façon réversible : le retour à la version précédente s’effectue sans perte de données. Une sauvegarde vérifiée conditionne toute mise en production.
Restitution et réversibilité. Le patient dispose d’un export en libre-service de ses données. Pour le professionnel, le périmètre, le format et le délai de restitution sont précisés par l’offre acceptée et par l’article 12 des conditions d’utilisation.
A9. Exploitation et maintien en condition de sécurité
Durcissement reproductible. La configuration de sécurité du serveur est décrite par un script reproductible et non par une intervention manuelle : un serveur remis en service repart avec la même configuration.
Contrôle continu. La plateforme vérifie automatiquement et en permanence l’état effectif de sa configuration de sécurité : désactivation de l’authentification par mot de passe, interdiction de la connexion directe en administration, bannissement automatique, pare-feu, mises à jour automatiques, permissions des fichiers de secrets, chiffrement du support, validité des certificats, journalisation et fraîcheur des sauvegardes. Un contrôle dont l’état ne peut être établi est signalé comme indéterminé et n’est jamais compté comme satisfait.
Secrets. Les clés et identifiants techniques ne figurent ni dans le code source ni dans son historique. Ils résident dans des fichiers à permissions restreintes, dont les droits sont eux-mêmes contrôlés automatiquement.
Qualité logicielle. Le code est intégralement écrit en typage strict. Une campagne de tests automatisés — plusieurs milliers de cas, dont des tests consacrés spécifiquement aux contrôles d’accès et à l’effectivité des révocations — s’exécute avant chaque mise en production et la bloque en cas d’échec.
Programme d’audit. La plateforme fait l’objet d’audits de sécurité internes documentés, menés de manière adverse sur l’état exact du code publié. Les constats sont suivis jusqu’à correction, chaque correction étant préalablement reproduite par un test qui échoue sur la version antérieure. Aucun constat n’est clos sans preuve d’exécution. À la date de la présente annexe, CabIMed ne détient pas de certification ISO 27001 ni d’agrément d’hébergeur de données de santé, et n’en revendique aucune.
A10. Traitements assistés par intelligence artificielle
Lorsqu’une fonction assistée par intelligence artificielle est activée, les règles suivantes s’appliquent.
Pseudonymisation préalable. Avant toute transmission à un service d’intelligence artificielle, les éléments identifiants du texte — adresses électroniques, numéros de téléphone, dates complètes, noms des personnes citées — sont remplacés par des jetons opaques. La correspondance entre jeton et valeur réelle existe le temps d’une requête et n’est pas conservée. La pseudonymisation constitue une mesure de sécurité au sens de l’article 32 du règlement.
Frontière géographique fermée par défaut. Un flux vocal ne pouvant être pseudonymisé, la transcription n’est transmise qu’à un prestataire dont le traitement dans l’Union européenne a été vérifié, selon une liste fermée. Toute autre destination est refusée et la fonction s’interrompt en le signalant. Une transmission hors de l’Union européenne suppose une décision expresse et documentée de l’exploitant.
Absence de réutilisation. Les données transmises le sont aux seules fins du traitement demandé. Elles ne sont pas utilisées pour entraîner des modèles.
Caractère facultatif. Ces fonctions sont désactivables. Certaines peuvent en outre s’exécuter localement, sans transmission externe.
A11. Violation de données et gestion des incidents
Tout incident de sécurité fait l’objet d’une qualification selon sa nature et le risque qu’il présente pour les droits et libertés des personnes concernées.
Lorsque le règlement l’exige, la violation est notifiée à l’autorité de contrôle dans les meilleurs délais et, si possible, dans les soixante-douze heures après en avoir pris connaissance. Les personnes concernées en sont informées sans délai indu lorsqu’un risque élevé le requiert.
Agissant en qualité de sous-traitant, CabIMed informe le responsable du traitement concerné dans les meilleurs délais après avoir pris connaissance de la violation, et lui apporte l’assistance raisonnable nécessaire à l’accomplissement de ses propres obligations.
L’autorité compétente est l’Autorité de protection des données (Belgique).
A12. Sous-traitance, contrôle et évolution de l’annexe
Répartition des rôles. Le professionnel de santé est responsable du traitement pour les données de prise en charge de ses patients. CabIMed intervient en qualité de sous-traitant pour les fonctions hébergées et agit sur instruction du responsable du traitement. CabIMed est responsable du traitement pour ses propres données de compte, d’annuaire et de relation commerciale.
Sous-traitants ultérieurs. Des prestataires n’interviennent que pour les fonctions effectivement activées — hébergement, messagerie, envoi de messages courts, téléphonie, paiement, intégration d’agenda. Leur identité, leur rôle, leur lieu de traitement et les garanties applicables sont documentés dans le registre des traitements et communiqués sur demande.
Droit de contrôle. Sur demande motivée d’un responsable du traitement, et sous réserve d’un accord de confidentialité, CabIMed communique à un correspondant identifié les éléments permettant de vérifier le respect de la présente annexe. Le détail des constats d’audit encore en cours de traitement n’est pas diffusé publiquement, conformément aux usages du secteur.
Évolution. La présente annexe peut être modifiée pour tenir compte de l’évolution des mesures, des services activés ou du cadre réglementaire. Chaque version porte une date. Une modification qui réduirait le niveau de protection décrit fait l’objet d’une information préalable des professionnels concernés.
Contact. Pour toute question relative à la sécurité ou à la protection des données, ou pour obtenir les éléments mentionnés ci-dessus : info@cabimed.be.
Aucun système d’information ne permet d’exclure tout risque. La présente annexe décrit des mesures et leur finalité ; elle ne constitue pas une garantie d’absence d’incident.