Aller au contenu

Société

Sécurité et confidentialité

La sécurité d'HARCH CENTRAL ne commence pas par le chiffrement : elle commence par l'intégrité du raisonnement. Un système qui calcule des décisions de gestion doit être auditable jusqu'à l'os — puis protégé comme ce que cela vaut.

  • MFA TOTP — RFC 6238

    Vérification en deux étapes conforme à la RFC — les six vecteurs officiels du §B sont des tests. Obligatoire pour les administrateurs.

  • Sessions signées HMAC-SHA256

    Cookie HttpOnly signé, rotation périodique, révocation immédiate — le client ne peut rien forger.

  • Fail-closed par principe

    Secret absent ou trop court en production : le serveur refuse de signer — et refuse toute session existante.

  • Permissions vérifiées serveur

    Matrice explicite de cinq rôles et cinq permissions, vérifiée à chaque requête — cacher un bouton n'est pas une sécurité.

  • Isolation des organisations

    Le contexte client accompagne chaque donnée dès la première table : l'organisation A ne voit jamais l'organisation B.

  • Zéro donnée cliente dans Git

    Les données des PME vivent uniquement en base — jamais dans les fixtures, les tests, les captures ni les issues.

Intégrité du raisonnement

Provenance remontable (PROV-1)

Propriété n°1 du système : d'une recommandation, on remonte au pourquoi, à la relation causale, à la variable, à la donnée d'entrée, jusqu'à la source. Rien n'apparaît magiquement à l'écran.

Contrats versionnés

Les structures de données sont définies une seule fois, partagées entre le moteur, l'API et la console, versionnées en sémantique stricte avec revue croisée à chaque évolution.

Reproductibilité

Chaque GraphDocument porte l'empreinte de ses entrées : mêmes entrées, même document. Les snapshots sont conservés pour l'audit temporel — revoir l'état d'hier reste possible.

Moteur sans I/O

Le moteur de calcul est du TypeScript pur, isolé du réseau et des bases : il ne peut ni fuiter, ni être influencé par autre chose que ses entrées déclarées.

Comptes et authentification

Comptes par invitation
Pas d'inscription publique libre : chaque compte naît d'une invitation émise par un administrateur, vers une adresse email précise, avec un rôle proposé.
MFA disponible, obligatoire pour les admins
La vérification en deux étapes (code à six chiffres ou code de récupération) est proposée à tous et imposée aux comptes administrateurs — les plus puissants sont les mieux protégés.
Vérification d'email
Un compte n'est actif qu'après vérification de son adresse — l'invitation part uniquement vers l'adresse invitée.
Limitation des tentatives
Connexion, MFA et réinitialisation sont limités en nombre de tentatives — le forçage est bloqué, pas découragé.
Récupération protégée
Les liens de réinitialisation sont à usage unique, expirent vite, et la réponse ne révèle jamais si une adresse correspond à un compte (protection anti-énumération).

Sessions

Cookies HttpOnly
Le cookie de session est inaccessible au JavaScript de la page — une faille d'extension ou de script ne permet pas de le voler.
Secure + SameSite
Transmission exclusivement en HTTPS, et restriction de l'envoi du cookie aux requêtes de notre domaine (protection CSRF).
Rotation
Les identifiants de session sont renouvelés périodiquement — un jeton ancien cesse d'être accepté.
Révocation
Un changement de mot de passe, un administrateur ou un appareil signalé perdu peut fermer les sessions à distance, immédiatement.

Quand une session expire, la page de session expirée explique pourquoi — c'est une protection, pas une punition.

Invitations

  • Jetons expirables — une invitation non acceptée dans le délai devient inutilisable ; il faut en émettre une nouvelle.
  • Usage unique — le jeton est consommé à l'acceptation ; un lien déjà utilisé est refusé, même s'il a été transmis.
  • Liés au titulaire — l'invitation ne peut être acceptée que par le titulaire de l'adresse email invitée.
  • Traçées — émission, acceptation, refus et expiration sont journalisés.

Rôles et permissions

Cinq rôles structurent l'accès, puis des permissions plus fines s'ajoutent : par entreprise suivie, fonctionnalité, action et niveau de confidentialité.

Owner
Accès complet — propriété de l'organisation, transfert, dissolution.
Admin
Membres, rôles, configuration, sécurité — hors propriété. MFA obligatoire.
Analyst
Graphes, diagnostics, simulations, données — lecture et analyse.
Manager
Décisions, séquences de travail, suivi d'exécution.
Viewer
Consultation seule — aucun changement, aucun export sensible.

Règle non négociable : cacher un bouton n'est pas une sécurité. Chaque requête vérifie les permissions côté serveur et le contexte de l'organisation — l'interface ne décide de rien.

Isolation des données

Les données d'une organisation ne sont visibles que de cette organisation. Le contexte client accompagne chaque donnée dès la première table, et chaque requête est filtrée par ce contexte côté serveur — un membre de l'organisation A ne peut pas voir l'organisation B, même en forgeant une URL.

Journalisation

Les événements sensibles sont journalisés avec acteur, date et contexte : connexions et échecs, tentatives MFA, émission et acceptation des invitations, changements de rôles, exports de données, décisions de transformation. Les administrateurs de l'organisation peuvent en prendre connaissance.

Données, code et sauvegardes

  • Aucune donnée cliente dans Git — les données des PME clientes vivent uniquement en base. Ni fixtures, ni tests, ni captures, ni issues.
  • Secrets hors dépôt — les secrets de production vivent dans les gestionnaires de secrets des plateformes, jamais dans le code.
  • Sauvegardes chiffrées — quotidiennes, conservées hors site ; objectifs RPO 24 h / RTO 4 h, test de restauration mensuel consigné.

État réel du déploiement

Le système est en construction, par phases auditées : contrats de données (S1), moteur (S2), API (S3), console (S4), déploiement (S5). Les parcours d'authentification existent aujourd'hui en maquettes complètes et honnêtement étiquetées ; les mécanismes décrits sur cette page (vérification serveur, cookies de session, MFA, isolation effective) sont livrés et documentés avec l'API et le déploiement. Nous décrivons ce qui existe et ce qui vient — rien d'autre.