🔒 Politique de Sécurité des Systèmes d'Information

Réactis — Logiciel SaaS de gestion de crise — IFclubs SAS

1. Périmètre et objectifs

La présente PSSI s'applique à l'ensemble du système d'information de la plateforme Réactis, incluant :

• L'infrastructure d'hébergement (serveurs, réseau, sauvegardes)
• Le code source et les applications (backend Node.js, interface web HTML/JavaScript, application mobile)
• Les données traitées pour le compte des clients (journaux de crise, contacts, documents)
• Les sous-traitants techniques (hébergeur, fournisseurs IA)

Les objectifs de sécurité poursuivis sont : confidentialité (les données d'un client ne sont pas accessibles à un autre), intégrité (les données ne peuvent être altérées de façon non tracée), disponibilité (la plateforme est accessible lors des crises).

2. Hébergement et infrastructure

Localisation des données

L'ensemble des données client de production est hébergé sur un serveur virtuel (VPS) situé en France, chez IONOS SE (anciennement 1&1 IONOS), hébergeur européen certifié ISO 27001. Aucune donnée client n'est répliquée hors de l'Union européenne.

Note : Réactis ne traitant aucune donnée de santé à caractère personnel (données médicales, dossiers patients), la certification HDS (Hébergeur de Données de Santé) n'est pas requise. Elle constitue néanmoins un engagement qualité que nous visons dans le cadre de la migration planifiée chez AZ Network (hébergeur certifié HDS — calendrier : premier semestre 2027).

Infrastructure matérielle

Isolation des tenants

Chaque établissement client (tenant) dispose d'une instance logicielle indépendante, avec :

• Un processus Node.js dédié (port unique, espace mémoire isolé)
• Un répertoire de données distinct sur le système de fichiers (/opt/crise-tenants/[slug]/)
• Des identifiants d'accès propres (mots de passe hashés bcrypt, jamais partagés entre tenants)
• Un compte système dédié (depuis le 24/09/2026) : chaque instance s'exécute sous son propre compte Linux, sans privilège administrateur ; ses données et sa configuration ne sont lisibles que par ce compte — une faille exploitée dans une instance ne donne pas accès aux fichiers des autres
• Des secrets de configuration propres à chaque tenant (aucun héritage d'un tenant à l'autre), et une clé d'échange propre à chaque établissement pour les niveaux régional et groupe

Un espace ne peut pas lire les données d'un autre : processus, compte système et fichiers sont séparés, et ce cloisonnement a été contrôlé le 03/10/2026 avec les comptes réels (pièce 2 du dossier RSSI). Le territoire ne reçoit que les établissements qui lui sont rattachés (rattachement effectué par l'éditeur) ; le national ne reçoit que des nombres agrégés par territoire, sans nom d'établissement ; aucune adresse e-mail du personnel ne quitte l'établissement.

Accès éditeur aux données client

3. Chiffrement et transport

4. Authentification et contrôle d'accès

Modèle d'accès actuel

• Compte individuel par personne (Coordinateur, Membre ou Invité) : identifiant = adresse email professionnelle, mot de passe personnel hashé bcrypt (12 caractères minimum, lettre + chiffre + caractère spécial) — plus aucun mot de passe partagé entre plusieurs personnes d'un même rôle
• Écran de connexion unique : le rôle et les droits associés sont déduits automatiquement du compte reconnu, sans sélection manuelle préalable par l'utilisateur (élimine tout risque de déclaration erronée du rôle)
• Panneau Admin : accessible sans mot de passe supplémentaire aux utilisateurs dont la session authentifiée porte le rôle Coordinateur — aucun repli sur un secret partagé
• Compte support éditeur : identifiant fixe, actif uniquement si explicitement activé par l'établissement (case à cocher, jamais par défaut), double authentification obligatoire (mot de passe + code TOTP à usage unique ; le mot de passe seul ne donne accès à rien) — utilisé exclusivement pour du dépannage à la demande du client ; chaque connexion est tracée dans le journal de l'établissement ; mot de passe renouvelable à tout moment par l'éditeur ; ne compte jamais dans les licences
• Niveaux régional et groupe (depuis le 24/09/2026) : comptes individuels (email + mot de passe personnel de 10 caractères minimum, lettres et chiffres, « mot de passe oublié » par code à 8 chiffres envoyé par email ; double authentification facultative depuis le 01/10/2026, code demandé en plus du mot de passe) — plus aucun mot de passe partagé ; création des accès par le responsable du client ; écrans d'affichage TV par clé en lecture seule, révocable
• Jetons de session générés aléatoirement, expiration après 8 heures ; la déconnexion ferme la session côté serveur ; changer son mot de passe ferme ses autres sessions ; un lien invité ne donne accès qu'à sa crise et expire à sa clôture
• Continuité des sessions (depuis le 25/09/2026) : une maintenance ou un redémarrage ne déconnecte plus les utilisateurs. Seule l'empreinte (SHA-256) de chaque jeton est enregistrée sur le serveur, jamais le jeton lui-même : la copie de ce fichier ne permettrait pas d'ouvrir une session
• Application mobile (depuis le 26/09/2026) : une session ouverte dans l'application peut être prolongée une seule fois, jusqu'à 30 jours après la connexion au plus ; la déconnexion, le changement ou la réinitialisation du mot de passe et la suppression du compte désinscrivent le téléphone des notifications ; 5 téléphones au plus par compte
• Déconnexion générale : depuis la passerelle, la déconnexion ferme côté serveur toutes les sessions ouvertes dans les différents espaces de l'utilisateur ; un lien apportant une autre session que celle déjà ouverte n'est accepté qu'après confirmation affichant le compte concerné
• Réponses en temps constant : la durée de réponse ne permet pas de savoir si une adresse possède un compte
• Aucune réponse de l'API n'est conservée dans le cache du téléphone ou du navigateur (Cache-Control: no-store) ; l'application mobile fonctionne sans cache
• Intégrité du journal de crise entre appareils : chaque entrée est horodatée par le serveur, un poste en retard ne peut ni annuler ni supprimer une modification plus récente ; la suppression passe uniquement par la corbeille
• Limitation des tentatives de connexion (par adresse IP réelle, y compris via la passerelle) sur tous les écrans d'authentification

Modes de connexion et double authentification (é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.

Récupération en cas d'oubli par code temporaire à usage unique, envoyé à la personne elle-même ; l'administrateur peut révoquer un facteur mais ne peut jamais le consulter ni le réassigner à sa place.

Passerelle générale multi-établissements (19/09/2026)

Les établissements sont accessibles individuellement (URL propre à chacun) ou via un point d'entrée unique, crise.ifclubs.fr, qui identifie l'établissement de l'utilisateur à partir de son email et de son mot de passe.

Un utilisateur disposant de comptes dans plusieurs espaces avec le même mot de passe se voit proposer la liste de ses espaces ; le bouton « ⇄ Changer d'espace » y ramène sans ressaisie (liste conservée 12 h au plus dans l'onglet, jamais sur le serveur).

Confidentialité des noms d'établissements sur le réseau (19/09/2026)

Jusqu'au 19/09/2026, chaque établissement disposait d'un sous-domaine portant son propre nom (ex. <nom-client>.crise.ifclubs.fr), avec un certificat HTTPS individuel. Or l'émission d'un certificat HTTPS inscrit son nom de façon publique et permanente dans les journaux de transparence des certificats (Certificate Transparency), un registre public consultable par quiconque, indépendamment de la sécurité de l'application elle-même. Deux mesures correctives ont été appliquées :

• Certificat wildcard unique (*.crise.ifclubs.fr) pour l'ensemble des établissements — un seul nom apparaît désormais dans les journaux publics, quel que soit le nombre de clients
• Identifiants d'établissement opaques — le sous-domaine de chaque établissement ne porte plus son nom mais un identifiant aléatoire non signifiant, supprimant également l'exposition résiduelle par indication de nom de serveur (SNI, visible en clair lors de l'établissement de toute connexion HTTPS, y compris avec un certificat wildcard)

Ces deux mesures sont appliquées à tous les établissements existants et à tout nouvel établissement dès sa création.

Roadmap authentification

5. Sauvegardes et continuité

• Solution : script de sauvegarde automatisé (cron), exécuté sur le serveur — pas de réplication hors site à ce jour (prévue avec la migration HDS : copie chiffrée quotidienne dans un autre datacenter)
• Fréquence : sauvegarde quotidienne automatique des données et documents déposés de tous les établissements, régionaux et groupes
• Rétention : 30 jours glissants
• Chiffrement : archives chiffrées AES-256 (OpenSSL), une clé de chiffrement propre à chaque client, conservée hors des dossiers applicatifs et accessible uniquement à l'administrateur système — une clé divulguée n'ouvre que les sauvegardes d'un seul client, stockées dans un répertoire distinct du répertoire de production sur le même serveur
• Restitution : restauration à froid possible à tout moment — données restituables en l'état
• RPO (Recovery Point Objective) : 24 heures maximum
• RTO (Recovery Time Objective) : 4 heures ouvrées maximum

6. Intelligence artificielle — Données transmises à des tiers

Principe général : l'IA est optionnelle

Données effectivement transmises

Lorsque les fonctionnalités IA sont activées, les données suivantes peuvent être transmises aux fournisseurs IA :

Recommandation opérationnelle : les équipes de crise sont invitées à ne pas saisir de données médicales nominatives (nom de patient, numéro de dossier) dans le journal — celui-ci doit rester un outil de coordination, non un dossier médical. Cette règle est rappelée à chaque connexion (bandeau "J'ai compris") et repose sur l'engagement de l'utilisateur, pas sur un filtre technique — aucun format universel de numéro de dossier patient ne permettrait une détection automatique fiable.

Scanner de risques documentaires à l'intégration (20/07/2026)

Ce scanner s'ajoute à un contrôle humain indépendant, requis avant tout usage par l'IA sur l'ensemble des documents déposés (bibliothèque, plan blanc et fiches réflexes) : un Valideur doit approuver le document (bouton ✅ Valider dans la bibliothèque documentaire) avant que son contenu ne soit exploité par une fonctionnalité IA — extraction automatique de contacts, conseils IA en cellule de crise, rapport de fin de crise, génération des fiches de mission. Un document déposé par l'administrateur (plan blanc, fiche réflexe) mais jamais approuvé par un Valideur dans la bibliothèque documentaire n'est jamais transmis à l'IA, quel que soit le mode de scan retenu.

Scanner de risques sur texte libre — transcriptions, journal de crise, messages externes (20/07/2026)

• Transcription de réunion Teams : scan à l'import, avant les deux appels IA (filtrage du bruit puis classification) — import refusé si bloquant, la secrétaire de main courante corrige le passage signalé avant de relancer.
• Journal de crise (main courante) : scan à la saisie de chaque nouvelle entrée, avant tout usage IA ultérieur — l'entrée n'est pas enregistrée si bloquant, son auteur la corrige et la ressaisit. Double contrôle : un blocage synchrone côté navigateur pour un retour immédiat à la frappe, et un contrôle côté serveur qui fait foi (non contournable).
• Message externe résumé par l'IA (import WhatsApp/SMS/email) : même scan et même réglage que le journal, appliqué avant l'envoi du contenu collé à l'IA pour résumé.

En mode avertissement, le contenu signalé est transmis tel quel (non expurgé) accompagné d'un signalement destiné à la relecture humaine — ce mode est réservé aux établissements ayant déjà fiabilisé leurs pratiques de saisie, le mode bloquant restant la configuration par défaut recommandée.

Rédaction forcée à la remontée régional/groupe (20/07/2026)

Fournisseurs IA et engagements RGPD

7. Gestion des incidents de sécurité

• Détection : surveillance automatique toutes les 5 minutes, surveillance des journaux, blocage automatique des adresses malveillantes (CrowdSec, fail2ban), alertes immédiates du support de l'éditeur
• Support proactif (depuis le 25/09/2026) : le support de l'éditeur est prévenu automatiquement, sans attendre un signalement du client, lorsque :
  • une liaison WhatsApp d'alerte est déconnectée depuis plus de 10 minutes ;
  • une alerte (email, WhatsApp, SMS, notification) n'a pas pu être délivrée — en urgence si une crise est en cours ;
  • un utilisateur rencontre une erreur technique dans l'application (message technique, fichier et page concernés — jamais les données saisies) ;
  • le contrôle automatique nocturne (parcours complet sur un environnement de test : connexions, boutons, ouverture d'une crise d'exercice, accès support) détecte une anomalie.
  Ces alertes ne contiennent aucune information permettant d'identifier le client ; le détail n'est consultable que dans la console de l'éditeur, protégée par double authentification.
• Information du client : en cas d'incident affectant un établissement, ses responsables sont informés par email (destinataires en copie cachée) avec la nature de l'incident, son impact et sa résolution
• Violation de données : en cas de violation de données, IFclubs SAS alerte sans délai l'établissement concerné, responsable de traitement, et lui fournit les éléments utiles (nature, données concernées, mesures prises) ; c'est l'établissement qui notifie la CNIL dans les 72 heures (art. 33 RGPD), avec l'assistance d'IFclubs SAS
• Contact : support@ifclubs.fr — réponse sous 48h ouvrées
• Traçabilité : les accès SSH à l'infrastructure sont journalisés

8. Gestion des vulnérabilités et mises à jour

• Mises à jour de sécurité des dépendances Node.js appliquées sous 72h après publication d'une CVE critique
• Mises à jour du système d'exploitation appliquées mensuellement
• Veille sécurité sur les composants tiers (Express, multer, jsonwebtoken, bcrypt)
• Tests de non-régression après chaque mise à jour avant déploiement en production : chaque évolution est d'abord installée et testée sur un environnement de test distinct (explorateur automatique qui clique sur chaque bouton, contrôle de la politique de sécurité du navigateur), puis déployée avec retour arrière automatique en cas d'écart
• Environnement d'exécution maintenu : passage à Node.js 24 LTS le 24/09/2026 (Node.js 20 arrivé en fin de support) ; dépendances majeures mises à jour (moteur de navigateur des alertes WhatsApp, notifications) — npm audit : 0 vulnérabilité

9. Réversibilité et portabilité des données

À tout moment et en cas de résiliation, l'établissement peut :

• Exporter l'intégralité de ses données via Admin → RGPD → Exporter toutes les données (ZIP) — format JSON standard, lisible par tout système
• Demander à support@ifclubs.fr une copie brute de l'ensemble de ses fichiers de données (hors export ZIP applicatif ci-dessus)
• Obtenir la suppression définitive de l'ensemble de ses données dans un délai de 90 jours après résiliation

Le format JSON des exports garantit la portabilité — les données peuvent être réintégrées dans tout système de gestion documentaire ou archivage.

10. Liste des sous-traitants

11. Tests de sécurité

IFclubs SAS s'engage à réaliser les évaluations de sécurité suivantes :

• Audit de sécurité complet (23-24/09/2026) : relecture manuelle du code (authentification, sessions, isolation entre clients, API, dépôts de fichiers, secrets), analyse statique (Semgrep), recherche de secrets (gitleaks), analyse des dépendances et du système (npm audit, Trivy) — toutes les vulnérabilités élevées et moyennes identifiées ont été corrigées ; les risques résiduels sont documentés et communicables aux RSSI sous NDA
• Audit de sécurité complet (03/10/2026) : revue des quelque 300 routes d'API, de la configuration du serveur, des droits sur les fichiers, des composants et de l'exposition web ; tests de cloisonnement avec les comptes de service réels — les deux constats élevés ont été corrigés et contrôlés le jour même ; les points restants sont liés à l'hébergement et traités par la migration HDS
• Analyse de code statique : renouvelée à chaque évolution majeure
• Contrôle automatique quotidien (depuis le 25/09/2026) : chaque nuit, un robot rejoue le parcours complet de l'application sur l'environnement de test (connexions des différents rôles, clic sur chaque bouton, crise d'exercice, accès support) et alerte l'éditeur en cas d'anomalie
• Test d'intrusion : proposé à l'équipe sécurité du groupe, sur un environnement dédié à données fictives (trois niveaux), selon des règles d'engagement écrites ; délais de correction : 72 h (critique), 15 jours (élevé), 30 jours (moyen) ; contre-audit des corrections
• Les rapports de test d'intrusion sont communicables aux RSSI des établissements sous NDA
• Test de charge : un rapport de capacité interne (CPU, RAM, bande passante, système de fichiers) a été réalisé pour estimer le nombre d'établissements pouvant se connecter simultanément sans dégradation — disponible sur demande auprès de l'éditeur

12. Partage des responsabilités