Politique de sécurité

Cette page décrit, en termes accessibles, les mesures de sécurité réellement mises en œuvre. Elle ne prétend pas à une sécurité absolue : aucune plateforme ne peut l'affirmer honnêtement. Elle décrit des mesures vérifiables et nomme aussi les limites connues.

1. Accès et authentification

• L'inscription libre n'existe pas : tout compte résulte d'une demande examinée par un administrateur.
• Les mots de passe sont stockés sous forme d'empreinte cryptographique, jamais en clair ni sous une forme réversible.
• Une limitation du nombre de tentatives protège les formulaires de connexion, de réinitialisation et de demande d'accès.
• Les messages d'erreur ne permettent pas de déterminer si une adresse est connue de la plateforme.
• Une authentification à deux facteurs est disponible, avec des codes de récupération.
• Les liens de réinitialisation et d'invitation sont à usage unique et expirent.

2. Sessions

• Une seule session active par utilisateur : une nouvelle connexion invalide la précédente.
• Expiration absolue et expiration après inactivité, vérifiées côté serveur à chaque requête.
• Changement de mot de passe, révocation ou désactivation invalident immédiatement les sessions en cours.
• L'identifiant de session est renouvelé à la connexion, pour empêcher la réutilisation d'un identifiant obtenu avant authentification.

3. Cloisonnement entre organisations

Chaque compte est rattaché à une organisation. Les données, fichiers, opérations, exports et statistiques sont filtrés côté serveur selon ce rattachement. Les autorisations sont vérifiées sur le serveur à chaque requête, jamais uniquement par le masquage d'un élément d'interface.

Le principe appliqué est le refus par défaut : une permission qui n'est pas explicitement accordée est refusée.

4. Fichiers téléversés

• Contrôle du type réel du fichier, au-delà de son extension.
• Limites de taille, de nombre de lignes et de cellules, protégeant contre les fichiers compressés anormalement volumineux.
• Refus des fichiers contenant des macros déguisées.
• Traitement XML sans résolution d'entités externes ni accès réseau.
• Neutralisation des formules lors des exports, pour qu'un contenu importé ne puisse pas s'exécuter dans un tableur.
• Stockage hors de l'espace servi par le serveur web, sous un nom généré côté serveur, avec téléchargement contrôlé par les permissions.
• Analyse antivirus avant écriture. Si l'antivirus ne rend pas de verdict fiable, le fichier est refusé — jamais accepté par défaut.

5. Journalisation

Trois flux distincts sont tenus : technique, sécurité et audit métier. Ils enregistrent l'action, son résultat, l'organisation concernée et un identifiant permettant de relier les étapes d'une même opération.

Ne sont jamais enregistrés : mots de passe, jetons, cookies, clés, secrets, en-têtes d'autorisation, ni le contenu complet d'un fichier. Dans les journaux techniques et de sécurité, les utilisateurs sont identifiés par un pseudonyme non réversible plutôt que par leur adresse e-mail.

6. Transport et en-têtes

En production, le service est servi exclusivement en HTTPS, avec des cookies marqués Secure et des en-têtes de sécurité restreignant le chargement de contenus tiers, l'inclusion dans un cadre et la détection automatique de type.

7. Limites connues

Nommées ici plutôt que passées sous silence :

• La politique de contenu autorise encore les scripts et styles en ligne : son durcissement complet reste un chantier à part entière.
• Aucun test d'intrusion indépendant n'a encore été réalisé.
• Certaines règles de détection comptent les événements par processus applicatif ; leur exactitude en configuration multi-processus suppose un stockage partagé.
• La plateforme n'est pas qualifiée pour l'hébergement de données de santé, et la bêta l'interdit explicitement.

8. Signaler une vulnérabilité

Si vous pensez avoir découvert une faille, utilisez le formulaire de contact public avec les éléments permettant de la reproduire, sans y joindre de données patient ni de secret.

Nous nous engageons à accuser réception, à examiner le signalement et à vous tenir informé. Merci de ne pas divulguer publiquement la faille avant qu'un correctif ait pu être déployé, et de ne pas accéder aux données d'autres utilisateurs pendant vos vérifications.

Les signalements sont examinés selon leur criticité. Aucun délai contractuel de réponse ou de résolution n'est promis pendant la bêta.