🔒 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, frontend React)
• 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 vers OVH (serveur dédié 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)

Il est techniquement impossible pour un tenant d'accéder aux données d'un autre tenant.

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 Admin : mot de passe individuel hashé bcrypt — accès complet à la crise et à la configuration
• Compte Membre : mot de passe partagé hashé bcrypt — accès opérationnel (journal, alertes) sans accès à la configuration
• Panneau Admin : protégé par un second mot de passe administrateur distinct
• Sessions limitées à l'onglet navigateur — la fermeture de l'onglet déconnecte automatiquement

Trois modes de connexion, au choix de l'établissement

Chaque établissement choisit son mode de connexion depuis sa console d'administration — les trois coexistent dans le logiciel, un seul est actif par tenant à la fois :

• Mode 1 — Mot de passe partagé par rôle (défaut) : décrit ci-dessus. Conçu pour ne jamais bloquer l'accès pendant une crise réelle, sans dépendance à un identifiant individuel.
• Mode 2 — Identité + code PIN personnel : chaque membre se connecte avec son nom (liste filtrée par rôle) et un code à 4 chiffres qui lui est propre, vérifié côté serveur. Renforce la traçabilité individuelle (l'identité de l'auteur d'une validation ou d'un message est garantie par la session, plus par une simple déclaration).
• Mode 3 — Identité + code TOTP (Google Authenticator, Microsoft Authenticator) : même principe que le mode 2, mais le code à 6 chiffres est rotatif toutes les 30 secondes (norme RFC 6238) au lieu d'un PIN fixe. Secret d'enrôlement chiffré au repos (AES-256-GCM), jamais stocké en clair sur le serveur.

Dans les deux modes 2 et 3, la réinitialisation (PIN oublié, téléphone perdu) exige un nouvel enrôlement — l'administrateur peut révoquer un facteur mais ne peut jamais le consulter ni le réassigner lui-même.

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
• Fréquence : sauvegarde quotidienne automatique de l'intégralité des données tenant
• Rétention : 30 jours glissants
• Chiffrement : archives chiffrées AES-256 (OpenSSL, clé dédiée par tenant), 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 des logs serveur, alertes automatiques en cas d'erreurs répétées ou d'accès anormaux
• Notification : en cas de violation de données susceptible d'engendrer un risque pour les droits et libertés, IFClubs SAS notifie l'établissement concerné dans les 72 heures conformément à l'article 33 du RGPD
• Contact : contact@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

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 à contact@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 :

• Analyse de code statique : effectuée en continu lors des développements
• Test de pénétration (pentest) : prévu dans un délai de 3 mois — réalisé par un prestataire externe accrédité PASSI (ANSSI)
• Les rapports de pentest 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