Sécurité : ce qui est en place, et comment

Les niveaux Réel Configuré À confirmer Non disponible Planifié sont définis sur la vue d'ensemble.

Protection des données

• RéelAucune donnée de patient, par conception. L'application ne reçoit ni identité, ni constante, ni prescription d'un patient. Les textes libres (idées, planning…) passent côté serveur par un détecteur de données personnelles avant d'être enregistrés.
• RéelHébergement de données de santé sans objet. Faute de donnée de santé de patient, la certification d'hébergeur de données de santé ne s'applique pas ; le raisonnement est détaillé dans les mentions légales.
• RéelL'encadrement ne reçoit que des agrégats anonymes. Les statistiques d'équipe sont calculées par la base et n'en sortent que sous forme de totaux, moyennes et répartitions, avec leur effectif. Aucun effectif minimal n'est imposé : dans une petite équipe, une statistique peut laisser deviner la situation d'une personne, et le contrat interdit à l'établissement d'en tirer une conséquence individuelle.

Chiffrement

• RéelEn transit. Tous les échanges passent en HTTPS (TLS). L'en-tête HSTS impose HTTPS pendant deux ans et le domaine est déclaré pour la liste de préchargement des navigateurs (preload).
• À confirmerAu repos. Le chiffrement des disques de la base est assuré par Supabase et AWS selon leur documentation. Nous ne l'avons pas vérifié nous-mêmes : nous ne le présentons pas comme acquis.
• RéelMots de passe. Le service d'authentification n'en conserve qu'une empreinte (bcrypt) ; le mot de passe n'est jamais stocké en clair.

Authentification

• RéelCourriel et mot de passe. C'est la seule méthode de connexion.
• Non disponibleAuthentification déléguée. Ni SSO, ni SAML, ni OAuth.
• RéelPas d'inscription libre. Un compte se crée sur invitation.
• RéelLongueur minimale. Douze caractères, quatorze pour les comptes à privilèges, règle appliquée dans l'application.
• RéelMot de passe provisoire. Il doit être remplacé avant tout accès ; le contrôle est fait en base, pas seulement à l'écran.
• RéelSecond facteur (TOTP). Disponible, facultatif pour l'utilisateur. Le serveur l'exige pour trois fonctions sensibles, qui couvrent la suppression d'un compte par l'administrateur et les invitations.
• PlanifiéSecond facteur obligatoire pour les administrateurs sur toutes les routes d'administration côté serveur. Aujourd'hui, ces routes ne l'exigent pas.
• RéelInactivité. Déconnexion après trente minutes sans activité. Ce contrôle est fait par le navigateur.
• RéelPKCE. Le flux de connexion utilise PKCE, qui empêche la réutilisation d'un code d'autorisation intercepté.

Autorisations

• RéelLes droits sont contrôlés dans la base PostgreSQL, par des règles d'accès ligne par ligne (Row Level Security). Les modules récents vont plus loin : leurs tables sont fermées, et ne se lisent qu'à travers des fonctions qui vérifient le droit de l'appelant.
• RéelLe rôle est relu en base à chaque appel, jamais déduit du seul jeton de session.
• RéelDonnées personnelles d'usage cloisonnées. Résultats de quiz, bien-être, mémoire d'apprentissage et journaux de connexion d'un agent ne sont lisibles que par son propre compte. Le gestionnaire d'établissement n'a aucun accès aux plannings.
• RéelRejoué à chaque modification de la base. Environ 44 scénarios de sécurité automatisés, soit environ 500 assertions, s'exécutent en intégration continue dès que la base change.
• RéelInterface de programmation. Limitation de débit sur les routes sensibles (Upstash, fenêtres glissantes ; repli plus strict en mémoire si le service est indisponible). Les routes d'interface de programmation de l'application n'acceptent que l'origine app.oncoide.fr (CORS).
• PlanifiéCORS des fonctions Supabase. Elles acceptent aujourd'hui toute origine, mais exigent un jeton valide. La restriction à l'origine de l'application est prévue.
• RéelEn-têtes HTTP. HSTS, politique de sécurité de contenu (CSP) qui n'autorise aucun script tiers hormis la mesure d'audience chargée après consentement, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy, COOP et CORP.

Isolation des établissements

• RéelVérifiée à chaque appel. L'appartenance de l'utilisateur à l'établissement et la validité de la licence sont contrôlées par la base à chaque requête.
• RéelTestée. Un scénario automatisé place deux établissements côte à côte et vérifie qu'aucun ne lit les données de l'autre ; il fait partie des scénarios rejoués en intégration continue.
• RéelIsolation logique, pas physique. OncoIDE est une instance partagée : tous les établissements sont dans la même base, séparés par les règles d'accès. Un déploiement dédié n'est pas au catalogue.

Gestion des secrets

• RéelLa clé de service de la base n'existe que côté serveur. Le navigateur ne détient que la clé publique, dont les droits sont bornés par les règles d'accès.
• RéelTâches planifiées protégées par un secret partagé : une tâche appelée sans lui est refusée.
• RéelWebhooks signés. Chaque appel entrant porte une signature HMAC, vérifiée par une comparaison à temps constant.
• Non disponibleDétection automatique de secrets dans le dépôt de code. Elle n'est pas en place ; elle figure aux améliorations.

Journaux

• RéelJournaux de connexion. Date, type d'appareil, navigateur, système. L'application n'y envoie pas d'adresse IP. Supprimés au-delà de douze mois par une purge mensuelle, elle-même tracée.
• RéelConsultations nominatives par l'administrateur. Un motif est obligatoire ; chaque consultation est enregistrée (identifiant de l'administrateur, horodatage, périmètre).
• RéelPurges tracées. Chaque purge inscrit sa date, le seuil appliqué et le nombre de lignes supprimées : une durée de conservation se prouve.
• RéelErreurs techniques. Remontées à Sentry, stockage dans l'Union européenne. Adresse IP, adresse électronique, nom d'utilisateur et en-têtes d'authentification sont retirés dans le navigateur avant l'envoi.
• À confirmerJournaux de l'hébergeur. Les journaux techniques de Vercel enregistrent l'adresse IP de connexion. Leur durée de conservation n'a pas été obtenue par écrit du fournisseur.

Surveillance

• PlanifiéSonde de disponibilité. Toutes les cinq minutes depuis Paris, elle vérifie l'application, le site, l'interface de programmation, la base, l'authentification, les fonctions, l'envoi de courriels et les données publiques — pas seulement une réponse HTTP. Une veille indépendante tourne aussi depuis la base, à Francfort. Le dispositif est écrit et testé ; sa mise en service en production est en cours. Tant qu'elle n'est pas faite, la page de statut le dit.
• PlanifiéParcours synthétique (connexion, accès, contenu), tous les quarts d'heure, avec un compte de surveillance dédié qui reste à créer.
• ConfiguréAlerte par courriel à l'éditeur lors d'une panne confirmée d'un composant critique, puis au rétablissement. Limite connue : l'alerte part de l'hébergeur de l'application ; si celui-ci tombe, la panne est écrite par la veille de la base, mais aucun courriel ne part.
• Non disponibleSurveillance externe indépendante des hébergeurs. Elle est à décider.
• RéelRemontée des erreurs de l'application vers Sentry (voir Journaux).

Sauvegardes

• ConfiguréSauvegarde quotidienne de la base, conservée sept jours. Le projet est sur l'offre Pro de Supabase (vérifié le 8 octobre 2026) ; la documentation de Supabase indique que cette offre sauvegarde chaque jour et conserve sept jours.
• À confirmerPrésence effective des sauvegardes, à vérifier dans le tableau de bord du fournisseur, et localisation des sauvegardes, à confirmer auprès de Supabase. Nous n'affirmons rien d'autre.
• Non disponibleRestauration à la seconde près (PITR). Option non activée.
• Non disponibleTest de restauration. Aucune restauration n'a été éprouvée.
• RéelFichiers. Sans objet : aucun fichier d'utilisateur n'est stocké.

Gestion des vulnérabilités

• RéelSignaler une vulnérabilité : écrire à support@oncoide.fr, en décrivant le problème et la manière de le reproduire. C'est la seule adresse à utiliser.
• ConfiguréFichier security.txt (/.well-known/security.txt) publié sur www.oncoide.fr avec cette version du site ; pas encore sur app.oncoide.fr.
• Non disponibleAnalyse automatique des dépendances (Dependabot, npm audit en intégration continue) et analyse statique du code (CodeQL). Elles figurent aux améliorations.
• PlanifiéPoints relevés par l'analyse de sécurité de la base (configuration de fonctions SQL) : correction en cours.

Gestion des incidents

• PlanifiéIncident publié sur la page de statut dès la confirmation, avec ce que l'on sait des services touchés et depuis quand ; statuts successifs Investigation, Problème identifié, Surveillance, Résolu ; chaque mise à jour horodatée. Un incident publié ne peut pas masquer une panne mesurée : l'état affiché est le pire des deux. Opérationnel avec la mise en service de la page de statut.
• PlanifiéPost-mortem publié pour tout incident majeur. Objectif interne : sous cinq jours ouvrés.
• RéelEngagement contractuel. Anomalie empêchant l'accès : prise en compte sous un jour ouvré, information de l'établissement tous les deux jours ouvrés jusqu'au rétablissement (engagement de disponibilité).
• RéelViolation de données. L'accord de sous-traitance prévoit la notification de l'établissement sans délai injustifié et au plus tard sous quarante-huit heures, avec les éléments de l'article 33.3 du RGPD.

Sécurité du développement

• RéelIntégration continue à chaque modification : analyse du code (lint), tests, construction, scénarios de sécurité de la base, contrôle des sources du contenu.
• RéelÉcart entre le dépôt et la production : les migrations de la base sont comparées entre les deux, pour qu'aucune modification n'existe d'un seul côté.
• RéelDéploiement des fonctions depuis l'intégration continue, avec vérification de la version servie.
• RéelDonnées de test fictives. Le code et l'intégration continue sont hébergés sur GitHub, sans aucune donnée d'utilisateur. La démonstration de l'application porte sur des données fictives et ne touche jamais la base réelle.

Accès internes

• RéelUne seule personne. L'éditeur est une personne seule : il n'y a pas d'équipe de support distincte. La personne qui répond au support est celle qui administre la plateforme.
• RéelRôle administrateur porté en base, contrôlé comme les autres rôles.
• RéelCe que la journalisation ne fait pas. L'éditeur détient les clés de la base ; aucune mesure logicielle n'empêche un accès direct à celle-ci. Ce que la journalisation garantit, c'est qu'une consultation nominative par l'outil normal est datée et attribuée.

Sécurité des fournisseurs

• RéelUn accord de traitement par fournisseur de l'application, relevé avec sa date et sa version (sous-traitants).
• RéelLeurs certifications sont les leurs. L'infrastructure des fournisseurs s'audite au moyen de leurs propres certifications et rapports, transmis sur demande. Elles ne valent pas certification d'OncoIDE.
• PlanifiéSuivi des pages de statut des fournisseurs (Vercel, Supabase, Resend, Gandi, Sentry, Upstash), affiché sur la page de statut avec la mise en service de la surveillance.

Continuité d'activité

• Non disponiblePlan de continuité d'activité formalisé. Le contrat de licence le dit.
• Non disponibleRedondance multi-hébergeur et astreinte.
• RéelSi l'éditeur est indisponible, le service continue de fonctionner puisqu'il est hébergé, mais aucune correction n'est apportée.
• RéelCessation d'activité. Le contrat prévoit un préavis d'au moins soixante jours aux établissements sous licence, sauf si la procédure retire cette maîtrise à l'éditeur, et un remboursement au prorata des mois non entamés. Ce n'est ni une garantie bancaire, ni un séquestre de code.

Reprise après incident

• Non disponiblePlan de reprise formalisé. En conséquence, aucun délai de reprise ni aucune perte de données maximale n'est engagé.
• RéelApplication sans état. Les fichiers de l'application et les fonctions serveur ne conservent aucune donnée ; le code est versionné et redéployable.
• ConfiguréBase de données : la reprise reposerait sur les sauvegardes quotidiennes décrites plus haut, dont la présence et la restauration restent à vérifier.

Améliorations de sécurité en cours

Prévues, non déployées à la date de cette page. Elles passeront au niveau Réel ici quand elles le seront.

• PlanifiéMise en service de la surveillance et de la page de statut en production, puis création du compte de surveillance pour le parcours synthétique.
• PlanifiéVérification, dans le tableau de bord du fournisseur, de la présence et de la localisation des sauvegardes ; test de restauration documenté.
• PlanifiéSecond facteur obligatoire pour les administrateurs sur toutes les routes d'administration.
• PlanifiéCorrection des points de configuration relevés par l'analyse de sécurité de la base.
• PlanifiéRestriction de l'origine acceptée par les fonctions Supabase.
• PlanifiéAnalyse automatique des dépendances, analyse statique du code, détection de secrets dans le dépôt.
• PlanifiéFichier security.txt sur app.oncoide.fr.
• PlanifiéSurveillance externe indépendante des hébergeurs, avec alerte (décision de coût à prendre).
• PlanifiéAbonnement par courriel aux incidents.

Cette page décrit l'état au 8 octobre 2026. Elle ne remplace ni le contrat de licence ni l'accord de sous-traitance : en cas de différence, le contrat signé fait foi.