Sécurité & protection des données

1. Chaque cabinet ne voit que ses données

Cemopta est une plateforme multi-tenant : plusieurs cabinets partagent la même infrastructure. L'isolation est appliquée au niveau de l'accès aux données — pas dans l'interface. Chaque requête métier est filtrée par le cabinet et le dossier concernés, et une requête hors session authentifiée ne retourne rien plutôt que trop : le cloisonnement est fermé par défaut, y compris en cas d'erreur de développement.

Les comptes utilisateurs sont rattachés aux dossiers auxquels ils ont droit, avec un rôle explicite (lecture, saisie, validation, administration). Un utilisateur retiré d'un dossier perd l'accès immédiatement, sans conservation de droits résiduels.

2. Piste d'audit inviolable (SHA-256)

Chaque écriture comptable est scellée par une empreinte SHA-256 chaînée à l'enregistrement précédent, par cabinet. Modifier ou supprimer une écriture après coup casse la chaîne et devient détectable — ce n'est pas seulement refusé par l'application, c'est mathématiquement visible. Les tables d'audit sont en écriture seule : la modification et la suppression y sont bloquées au niveau de la base de données elle-même, y compris pour un accès direct hors application.

3. Chiffrement et en-têtes de sécurité

• • TLS 1.3 sur toutes les communications, avec HSTS pré-chargé — la connexion ne peut pas retomber en clair après une première visite.
• • Content-Security-Policy stricte : aucun script inline non autorisé ne peut s'exécuter (nonce aléatoire par requête). Une injection de code dans une page n'a pas de point d'exécution.
• • Protection anti-CSRF sur toutes les actions, en-têtes frame-ancestors: none (le site ne peut pas être intégré dans une page tierce pour piéger une saisie).
• • Mots de passe stockés sous forme de hachage à coût élevé — jamais en clair, jamais réversible.

4. Double authentification (2FA)

La double authentification par application mobile (TOTP) est disponible pour tous les comptes et imposable aux rôles sensibles. Elle ajoute un facteur que le vol d'un mot de passe ne suffit pas à contourner. Les tentatives de connexion et les opérations sensibles sont journalisées.

5. Sauvegardes et reprise d'activité

Les bases de données font l'objet de sauvegardes chiffrées et régulières, conservées hors du serveur applicatif. Le plan de reprise (RPO/RTO) et sa procédure de restauration sont documentés et testés par des exercices de restauration réels : une sauvegarde jamais restaurée n'est pas une sauvegarde.

6. Hébergement et exploitation

L'application s'exécute dans des conteneurs isolés, avec des services séparés pour l'application web, les traitements de fond (files d'attente) et la base de données. Les mises à jour passent par une chaîne de vérification continue (tests automatisés, analyse statique) avant déploiement, et chaque version déployée est identifiable et réversible.

7. Mesure d'audience sans surveillance

Si la mesure d'audience est activée, elle utilise une solution auto-hébergée, sans cookie, respectant le signal Do Not Track et anonymisant les adresses IP. Aucun profil publicitaire n'est constitué et aucune donnée de visite n'est revendue. Le détail figure dans la politique de confidentialité.