🛡️ Conformité RGPD & Sécurité

Réactis — Plateforme de gestion de crise — IFclubs SAS

1. Présentation de la plateforme Réactis

1.1 Nature et finalité

Réactis est une plateforme SaaS de gestion de crise conçue pour les établissements de santé. Elle permet d'ouvrir, piloter et clôturer une cellule de crise, de tenir une main courante numérique collaborative en temps réel, de notifier les parties prenantes par e-mail, notification mobile et, si le client les connecte lui-même, WhatsApp, Telegram, Teams et SMS (avec l'abonnement SMS du client), et de générer des rapports de retour d'expérience (RETEX) assistés par intelligence artificielle.

La plateforme est accessible via navigateur web sécurisé (HTTPS). Elle est hébergée sur un VPS mutualisé IONOS situé en France (UE).

1.2 Architecture technique

1.3 Données traitées

• Données des membres de la cellule de crise : prénom, nom, adresse email professionnelle
• Données de contacts d'urgence : nom de service, email institutionnel, téléphone (urgences, ARS, etc.)
• Main courante : messages opérationnels saisis par les membres pendant la crise
• Pièces jointes : documents opérationnels uploadés pendant la crise (PDF, images)
• Logs email : traçabilité des notifications envoyées (destinataires, objet, date)
• Numéros de téléphone mobile (destinataires SMS — canal optionnel, désactivé par défaut)
• Données d'abonnement : email de facturation, référence de paiement
• Données techniques de fonctionnement (depuis le 25/09/2026) : date de dernière connexion de chaque membre (bilan de préparation de l'établissement), journal des envois d'alerte en échec (canal, motif technique, adresses masquées), erreurs techniques rencontrées dans l'application (message technique, fichier et page concernés — jamais les données saisies), empreintes des jetons de session

2. Conformité RGPD

2.1 Base légale des traitements (Article 6 RGPD)

La base légale est déterminée par chaque établissement, responsable de traitement. Le registre des traitements retient : l'obligation légale (Art. 6.1.c ; plan blanc d'établissement, art. L. 3131-7 du Code de la santé publique) pour la gestion des crises ; l'intérêt légitime (Art. 6.1.f) pour les fonctions complémentaires (supervision technique, notifications, marques de lecture) ; l'exécution d'un contrat (Art. 6.1.b) pour les données d'abonnement. Les données de santé nominatives des patients ne sont pas hébergées dans Réactis — la plateforme est un outil de coordination, pas de soins.

2.2 Rôles RGPD

2.3 Contrat de sous-traitance (DPA — Art. 28)

Un Data Processing Agreement (DPA) conforme à l'article 28 du RGPD est accessible à l'URL : crise.ifclubs.fr/dpa.html

Ce contrat précise les finalités de traitement, les mesures de sécurité techniques et organisationnelles, la liste des sous-traitants ultérieurs, les obligations en cas de violation de données, et les conditions de suppression des données en fin de contrat. Il doit être formellement accepté par l'établissement avant toute mise en production ; l'acceptation est enregistrée dans la plateforme.

2.4 Registre des activités de traitement (Art. 30)

Accessible à l'URL : crise.ifclubs.fr/registre-traitements.html. Il recense les activités principales : gestion des cellules de crise (main courante, notifications, RETEX), gestion des membres et contacts de la cellule, traçabilité des communications, administration et facturation.

2.5 Durée de conservation et politique de rétention

• Main courante et archives de crise : 5 ans par défaut après la date de clôture, configurable par l'établissement
• RETEX (retours d'expérience) : non soumis à la purge automatique — conservés indéfiniment, ils ne contiennent pas de données nominatives et constituent la mémoire institutionnelle de l'établissement
• Journal des e-mails envoyés : conservé avec les données de l'espace pendant l'abonnement (pas de purge automatique à ce jour), supprimé sous 90 jours après la résiliation ; journaux du serveur de messagerie : 5 semaines environ
• Données de facturation : 10 ans (obligation comptable)
• Données techniques de fonctionnement : envois en échec et erreurs techniques 30 jours glissants ; sessions jusqu'à leur expiration (8 heures) ; date de dernière connexion tant que le compte existe
• Pièces jointes : supprimées à la clôture de la crise si demandé

Un export RGPD et une fonction de purge manuelle sont disponibles via le panneau administrateur (onglet RGPD).

2.6 Droits des personnes concernées

• Droit d'accès (Art. 15) : export disponible sur demande
• Droit de rectification (Art. 16) : modification possible par l'administrateur
• Droit à l'effacement (Art. 17) : suppression du compte et des données associées
• Droit à la portabilité (Art. 20) : export JSON disponible
• Droit d'opposition (Art. 21) : applicable pour les traitements sur base d'intérêt légitime

Ces droits s'exercent auprès du responsable de traitement (l'établissement abonné). Pour toute question relative à l'infrastructure technique : support@ifclubs.fr.

2.7 Gestion des violations de données (Art. 33-34)

En cas de violation de données à caractère personnel, l'éditeur s'engage à alerter sans délai le responsable de traitement dès la prise de connaissance de l'incident, à documenter la violation dans un registre des incidents, à évaluer le risque pour les droits et libertés des personnes concernées, et à assister le responsable de traitement, qui notifie la CNIL dans les 72 heures si nécessaire (art. 33 RGPD).

3. Sécurité réseau et infrastructure

3.1 Chiffrement des communications

• HTTPS obligatoire : TLS 1.2 minimum, TLS 1.3 préféré — certificat Let's Encrypt renouvelé automatiquement
• HSTS activé : force le HTTPS pour tous les navigateurs (Strict-Transport-Security)
• Toutes les API communiquent exclusivement via HTTPS — aucun HTTP en production
• Certificat wildcard unique (19/09/2026) : un seul certificat (*.crise.ifclubs.fr) couvre tous les établissements, au lieu d'un certificat individuel par établissement — empêche la divulgation de la liste des clients via les journaux publics de transparence des certificats (Certificate Transparency), un registre permanent et consultable par quiconque, indépendant de la sécurité applicative

3.2 Authentification et contrôle d'accès

Chaque personne dispose d'un compte individuel (plus de mot de passe partagé entre plusieurs utilisateurs d'un même rôle). État au 04/10/2026 :

• Établissements : chaque personne se connecte avec son adresse e-mail et un mot de passe personnel (12 caractères minimum, lettre + chiffre + caractère spécial, haché bcrypt). Double authentification en production depuis le 04/10/2026 (code TOTP à 6 chiffres, RFC 6238, demandé après le mot de passe ; graine chiffrée AES-256-GCM, anti-rejeu, essais limités) : facultative, chacun l'active pour son propre compte (bouton « 📱 Double authentification ») ; l'administrateur de l'espace peut la rendre obligatoire pour tous les membres. « Mot de passe oublié » ne contourne pas le code ; la désactiver exige le mot de passe et un code ; téléphone perdu : un coordinateur la retire au membre. Seule exception : le lien d'ouverture de crise envoyé aux membres (usage unique, valable 2 h, accès Membre limité) reste sans code. L'ancien mode où le code remplaçait le mot de passe (facteur unique, jamais utilisé en production) a été retiré.
• Territoire et national : comptes individuels (10 caractères minimum, lettres et chiffres, haché bcrypt) ; double authentification facultative (code TOTP demandé en plus du mot de passe), activée par chacun pour son compte ; un responsable peut la retirer en cas de perte du téléphone, pas l'imposer ; la désactiver exige le mot de passe puis un code (code seul refusé), comme dans les établissements — en place depuis le 04/10/2026.
• Accès de l'éditeur : compte support (désactivé par défaut, activé par l'établissement) et console d'administration : mot de passe et code TOTP obligatoires.

Séparation stricte des rôles (admin / membre / invité) appliquée côté serveur sur chaque route, jamais côté client uniquement — le rôle est désormais déduit automatiquement du compte reconnu (email ou identité), sans déclaration manuelle par l'utilisateur. Limiteur de tentatives de connexion (fenêtre glissante de 15 minutes) sur l'ensemble des routes d'authentification, prévention brute force. Isolation stricte par tenant : chaque établissement n'accède qu'à ses propres données, y compris via la passerelle générale d'accès multi-établissements (crise.ifclubs.fr), qui ne conserve que des empreintes non réversibles des adresses (HMAC-SHA256) — aucun mot de passe, aucune donnée de crise — et ne transmet le mot de passe qu'aux espaces qui connaissent l'adresse saisie. Identifiants de sous-domaine opaques (non porteurs du nom du client) pour tout établissement, réduisant l'exposition résiduelle par indication de nom de serveur (SNI) lors de l'établissement d'une connexion HTTPS. Rappel RGPD affiché avant tout accès à la main courante, acquitté explicitement par l'utilisateur ("J'ai compris") — mesure organisationnelle de prévention contre la saisie de données de santé nominatives.

3.3 Headers de sécurité HTTP

• Intégration en cadre (clickjacking) : frame-ancestors 'self' https://*.ifclubs.fr dans la politique de contenu ; X-Frame-Options: DENY sur la console de l'éditeur, SAMEORIGIN sur certains espaces
• X-Content-Type-Options: nosniff — prévention du MIME sniffing
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy : micro autorisé pour les seules pages de Réactis (microphone=(self), utile à la dictée et à l'enregistrement des réunions) ; caméra et géolocalisation selon les espaces (() ou (self)) ; paiement, USB, Bluetooth et capteurs bloqués
• Content-Security-Policy stricte, appliquée sur toutes les interfaces depuis le 24/09/2026 : default-src 'self', script-src 'self', script-src-attr 'none', object-src 'none', base-uri, form-action, frame-ancestors — aucun script ni gestionnaire d'événement intégré aux pages (actions exécutées par un interpréteur sans eval, limité à une liste blanche)

3.4 Protection de l'infrastructure et des données au repos

3.5 Validation et contrôle des entrées

• Validation du type MIME et de la signature binaire réelle des fichiers uploadés (PDF, images, documents)
• Limites de taille de l'application : 20 Mo (pièces jointes), 50 Mo (relevés PDF), 2 Mo par requête JSON (15 Mo pour l'enregistrement d'une crise, les transcriptions, RETEX et imports) ; sur la plupart des espaces, le serveur web frontal applique une limite plus basse (1 Mo, valeur par défaut) : harmonisation prévue
• Protection contre l'injection de commande : appels de processus sans interprétation shell (execFileSync) pour les scripts d'import
• Validation JSON stricte sur toutes les routes API
• Protection CORS : whitelist limitée à *.crise.ifclubs.fr
• Scanner de risques à l'intégration (20/07/2026) : tout PDF déposé dans le plan blanc ou la base documentaire est analysé localement, sans aucun appel IA (expressions déterministes) à la recherche de marqueurs de classification restreinte/interne, mobiles personnels et emails nominatifs — comportement bloquant par défaut (paramétrable en avertissement par établissement) ; s'ajoute une validation humaine obligatoire par un Valideur dans la base documentaire avant tout traitement IA — cette validation conditionne aussi l'usage du plan blanc et des fiches réflexes par l'IA, via un document au nom correspondant approuvé par un Valideur
• Scanner de risques sur texte libre (20/07/2026) : même principe, appliqué localement, sans aucun appel IA, au journal de crise (à chaque saisie), aux transcriptions de réunion (à l'import) et aux messages externes soumis au résumé IA — recherche de mobiles personnels, emails nominatifs et numéros de sécurité sociale (NIR), comportement bloquant par défaut, paramétrable en avertissement par établissement, indépendamment pour chaque flux
• Dictée vocale désactivable (20/07/2026) : la reconnaissance vocale du navigateur fait transiter l'audio par un service tiers (ex. Google sur Chrome) avant que le texte ne nous parvienne — une caractéristique normale, inhérente à cette technologie ; le texte reconnu est ensuite soumis au même scan de pré-envoi que toute entrée du journal, dictée ou tapée. Un établissement peut désactiver entièrement la dictée depuis son panneau admin pour ne conserver que la saisie clavier

3.6 Disponibilité et continuité de service

• Monitoring automatique toutes les 5 minutes (services, sites, ressources, bande passante, certificats, sauvegardes, liaisons WhatsApp de chaque établissement), redémarrage automatique en cas d'indisponibilité, alerte immédiate du support de l'éditeur
• Support proactif : l'éditeur est prévenu automatiquement si une alerte de crise n'a pas pu être délivrée (en urgence pendant une crise), si un utilisateur rencontre une erreur technique, ou si le contrôle automatique nocturne détecte une anomalie — les emails reçus par l'éditeur ne contiennent aucune information identifiant le client
• Continuité des sessions : une maintenance ne déconnecte pas les utilisateurs
• Bilan de santé consultable par l'établissement dans son administration (liaisons d'alerte, équipe, exercices, retours d'expérience, abonnement), avec conseils
• Log d'audit append-only traçant toutes les ouvertures/fermetures/suppressions de crise
• Processus Node.js géré par systemd (redémarrage automatique au boot)
• RPO (perte de données maximale) : 24h · RTO (délai de restauration) : 4h ouvrées maximum

3.7 Gestion des sous-traitants ultérieurs

Note WhatsApp : l'intégration WhatsApp utilise actuellement une librairie d'automatisation non officielle. Elle est mentionnée dans les CGV comme fonctionnalité "best-effort" — susceptible d'être interrompue sans préavis par Meta. Une migration vers l'API officielle WhatsApp Business Cloud est prévue à l'entrée du premier client nécessitant une garantie contractuelle sur ce canal. Les établissements souhaitant une conformité stricte peuvent désactiver cette fonctionnalité.

Surveillance du service : contrôle du serveur toutes les 5 minutes, alertes automatiques sur les espaces clients et remontée des erreurs techniques — détail dans la PSSI, section 7.

4. Cadre légal et contractuel

4.1 Documents légaux disponibles sur la plateforme

• Conditions Générales de Vente (CGV) : /cgv.html
• Conditions Générales d'Utilisation (CGU) : /cgu.html
• Data Processing Agreement (DPA) : /dpa.html
• Politique de confidentialité (RGPD) : /rgpd.html
• Registre des traitements Art. 30 : /registre-traitements.html
• Politique de Sécurité des Systèmes d'Information (PSSI) : /pssi.html
• Accord commercial : acceptation tracée par horodatage dans la plateforme

4.2 Gestion des crises — Finalité des données traitées

La plateforme Réactis traite des données opérationnelles de gestion de crise : informations sur les ressources disponibles (lits, effectifs, matériel — données non nominatives), messages de coordination entre membres de la cellule (données nominatives des professionnels), notifications à des contacts institutionnels (ARS, SAMU, partenaires — coordonnées professionnelles).

La plateforme ne traite pas de données de santé nominatives des patients. Afin de prévenir toute saisie involontaire, un message d'alerte est affiché à chaque connexion : les utilisateurs reconnaissent explicitement, par un clic sur « J'ai compris », que la main courante est un outil de coordination et ne doit pas contenir d'informations médicales nominatives sur les patients. Cette acceptation est tracée à chaque session.

4.3 Hébergement des données de santé (HDS)

La plateforme Réactis n'est pas un hébergeur de données de santé à caractère personnel (HDS) au sens de l'article L. 1111-8 du Code de la Santé Publique, dans la mesure où elle ne stocke pas de données de santé nominatives des patients. Si un établissement venait à inclure de telles données dans la main courante malgré le rappel affiché à la connexion, l'éditeur devrait être certifié HDS.

5. Réponse aux exigences HAS — Gestion de crise numérique

5.1 Référence aux critères HAS 3.1-09 (Continuité du SI)

Réactis constitue un élément de preuve pour les éléments évaluables suivants : existence d'un outil de coordination de crise opérationnel et testé, traçabilité horodatée des actions et décisions pendant la crise (main courante), capacité à notifier les parties prenantes internes et externes en temps réel, génération de rapports de RETEX documentant les leçons apprises.

5.2 Exercices réalisés

La plateforme est utilisée par des établissements clients pour des exercices (plans blancs, canicule, incidents techniques), avec la traçabilité horodatée de la main courante, la notification multicanale et la production de rapports de retour d'expérience. Les données propres aux établissements restent confidentielles.

5.3 Sécurité des données de crise

Chaque crise est archivée avec son identifiant unique, sa date d'ouverture/fermeture, ses membres actifs. Les archives sont conservées 5 ans par défaut et peuvent être exportées ou purgées à la demande. Un log d'audit indépendant trace toutes les actions administratives. Les sauvegardes chiffrées garantissent la pérennité des archives de crise.

6. Contacts et responsabilités

Éditeur et propriétaire de la plateforme : IFclubs SAS, représentée par Frédéric T. — support@ifclubs.fr

Responsable de traitement : l'établissement client utilisateur de la plateforme (responsable de traitement au sens du RGPD Art. 4), identifié dans son contrat d'abonnement.

Délégué à la Protection des Données (DPO) : support@ifclubs.fr. Pour les demandes d'exercice de droits relatives aux données de crise, les personnes concernées doivent s'adresser au DPO de leur établissement (responsable de traitement).