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.
Société
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.
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.
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.
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.
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.
Quand une session expire, la page de session expirée explique pourquoi — c'est une protection, pas une punition.
Cinq rôles structurent l'accès, puis des permissions plus fines s'ajoutent : par entreprise suivie, fonctionnalité, action et niveau de confidentialité.
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.
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.
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.
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.