Retour à Pulse
    Confidentialité & Sécurité

    Confidentialité et Sécurité

    Pulse est auto-hébergé. Cette page explique exactement quelles données vivent où, ce qui se connecte à Internet, et comment la posture de sécurité est construite pour que particuliers et entreprises régulées puissent tous deux y faire confiance.

    Le résumé en une ligne

    Pulse tourne sur votre matériel. Vos données ne quittent jamais votre matériel sauf si vous les envoyez explicitement quelque part via un agent configuré.

    Où vivent vos données

    À l'installation, un seul répertoire de données est créé (par défaut : ~/pulse-data sur Linux/macOS, %USERPROFILE%\pulse-data sur Windows). Tout ce que Pulse persiste vit dans ce dossier unique :

    pulse-data/
    ├── pulse.mv.db              ← users, orgs, sessions
    ├── pulse-audit.mv.db        ← audit log
    ├── pulse-events.mv.db       ← event bus + topics
    ├── pulse-agents.mv.db       ← agent definitions
    ├── pulse-chat.mv.db         ← chat history
    ├── pulse-knowledge.mv.db    ← learning + RAG
    ├── pulse-config-store.mv.db
    ├── pulse-guardian-rules.mv.db
    ├── pulse-dlq.mv.db          ← blocked events
    ├── pulse-pipelines.mv.db
    ├── pulse-uploads.mv.db      ← files you uploaded
    ├── .jwt-secret              ← session-signing key
    ├── .vrf-secret              ← PVSC consensus key
    ├── .encryption-key          ← master key for credentials
    ├── .license.jwt             ← Pulse license token
    ├── logs/                    ← rotating application logs
    ├── backups/                 ← automatic snapshots
    └── user-templates/          ← your custom templates

    Sauvegardez le dossier, vous sauvegardez Pulse. Supprimez-le, vous effacez toute trace. Rien en dehors de ce dossier n'est jamais touché, ni votre trousseau système, ni le registre, ni le cloud.

    Ce qui se connecte à Internet

    Pulse effectue des appels sortants pour quatre raisons. Vous pouvez désactiver chacun pour un fonctionnement totalement hors ligne.

    1

    Appels d'API LLM

    Uniquement si VOUS configurez un fournisseur cloud. Choisissez un runtime local et Pulse ne contacte aucun vendor. Les prompts cloud transitent directement entre Pulse et le fournisseur ; le serveur de licence ne les voit jamais.

    2

    Appels de plugins MCP

    Lorsqu'un agent utilise un outil que vous avez câblé (Slack, SMTP, une API…). Les destinations sont celles que vous avez choisies.

    3

    Vérification quotidienne des mises à jour (optionnel)

    Une fois par jour Pulse interroge le flux public des releases GitHub. N'envoie qu'un User-Agent. Désactivez avec update.checkEnabled: false.

    4

    Rafraîchissement hebdomadaire de licence (optionnel)

    Une fois par semaine Pulse appelle license.streamflowmesh.io/refresh?licenseId=X. N'envoie que votre ID de licence, pas d'email, pas de données, pas de signal d'usage. Désactivez en vidant license.serverUrl.

    Ce sont les quatre seuls. Pas de télémétrie, pas d'analytics, pas de ping-home au démarrage. Nous ignorons combien d'installations Pulse existent. Et c'est très bien.

    Fonctionnement air-gap

    Pulse peut fonctionner sans aucun accès Internet :

    • Installez le binaire depuis une clé USB, aucun réseau requis.
    • Configurez le LLM sur un runtime local (téléchargement du modèle initial une seule fois ; puis hors ligne).
    • Mettez update.checkEnabled: false pour couper le polling de mise à jour.
    • Mettez license.serverUrl: "" pour couper le rafraîchissement de licence. Collez un token une fois ; il dure sa période de validité.

    Dans ce mode Pulse n'émet aucun appel sortant. Idéal pour la recherche clinique, le gouvernement classifié et le contrôle industriel.

    Exposition réseau

    Par défaut Pulse écoute sur 127.0.0.1:9090, loopback uniquement. Seuls les logiciels de la même machine peuvent l'atteindre. Aucun autre ordinateur du réseau ne le voit sauf changement de binding.

    Ouvrir au LAN

    Éditez pulse-config.yaml :

    server:
      host: 0.0.0.0     # accept from any interface
      port: 9090

    Ne le faites que si vous comprenez les implications. Quiconque sur votre LAN atteint le port 9090 voit la page de connexion Pulse. L'authentification Pulse (utilisateur + mot de passe, 2FA optionnel) est votre seule défense.

    Reverse proxy avec TLS (recommandé)

    Pour toute exposition au-delà de localhost, placez Pulse derrière un reverse proxy gérant TLS :

    [external] --HTTPS--> [Caddy / nginx / Cloudflare] --HTTP (loopback)--> [Pulse]

    Exemple Caddy (Caddyfile) :

    pulse.yourdomain.com {
      reverse_proxy localhost:9090
    }

    Caddy gère Let's Encrypt automatiquement. Pulse reste sur loopback ; le proxy est la surface exposée à Internet.

    Chiffrement des identifiants au repos

    Pulse stocke pour vous beaucoup d'identifiants sensibles : mots de passe SMTP, clés d'API, tokens OAuth, chaînes de connexion. Tous sont chiffrés sur disque en AES-256-GCM avec une clé maître dérivée de .encryption-key (générée une fois au premier démarrage, stockée en 0600).

    • Si quelqu'un récupère vos fichiers de base mais PAS .encryption-key, les identifiants sont opaques.
    • S'il récupère les deux, il a tout. Protégez la clé maître, sauvegardez-la avec les données, ou séparez les sauvegardes (clés dans un vault, données dans un autre).
    • La clé maître ne quitte jamais votre machine. Elle n'est dérivée ni de votre mot de passe, ni de rien de révélable.

    Authentification & sessions

    Stockage des mots de passe

    Argon2id (64 Mo mémoire, 3 itérations, 1 parallélisme, bien au-dessus de la baseline OWASP 2025). Les hashes ne se renversent pas ; le brute force coûte ~1 s par essai.

    Sessions

    Tokens JWT signés HMAC-SHA256 via .jwt-secret (256 bits). Accès expire en 15 min ; refresh jusqu'à 7 jours. La déconnexion invalide le refresh côté serveur.

    2FA / TOTP

    TOTP optionnel par utilisateur (Google Authenticator, 1Password, Authy…). Activable dans Paramètres → Sécurité. Le secret est chiffré avec la clé maître.

    Rate limiting

    Login : 5 tentatives / 15 min par IP. Appels API par utilisateur + rôle, seuils configurables. Appliqué in-process, suffisant pour Pulse mono-nœud.

    Protection CSRF

    Les endpoints qui modifient l'état exigent un double-submit CSRF. Les tokens tournent par session et sont liés à l'user ID.

    Journal d'audit

    Chaque action sensible est journalisée. Le journal est append-only (écritures sans modifications).

    Login / logout / login échoué / validation 2FA
    Changements de rôle
    Déploiement / démarrage / arrêt / suppression d'agent
    Déploiement / suppression de pipeline
    Création / mise à jour / suppression d'identifiants
    Activation / retour / mise à niveau de licence
    Événements de sauvegarde / restauration
    Installation / désinstallation de plugin
    Accès aux endpoints admin

    Rétention par plan

    PlanRétention du journal
    FREE30 jours
    PRO365 jours
    ENTERPRISEIllimité

    Les admins cherchent, filtrent et exportent (CSV/JSON) via Paramètres → Audit. Utile pour la forensic d'incident, la conformité et la détection d'anomalies.

    Sauvegardes & reprise après incident

    Snapshots automatiques

    Pulse prend un snapshot cohérent de chaque base H2 sur un planning (par défaut : quotidien, 7 conservés). Chaque snapshot est téléchargeable en un seul zip.

    Inclus dans les sauvegardes

    • • Comptes utilisateurs (mots de passe hashés + état 2FA)
    • • Définitions d'agents
    • • Définitions de pipelines
    • • Historique de chat
    • • Historique d'événements (selon les règles de rétention)
    • • Journal d'audit

    PAS dans la sauvegarde

    .jwt-secret, .vrf-secret, .encryption-key, ce sont des secrets, PAS des données. Vous DEVEZ les sauvegarder séparément vers une autre destination (gestionnaire de mots de passe, HSM, stockage hors site chiffré). Sans eux, une restauration ne fonctionne pas.

    Restauration, stage-puis-apply-au-démarrage

    1. 1Uploadez un zip de sauvegarde via Paramètres → Sauvegardes → Restaurer depuis fichier (ou sélectionnez un snapshot local).
    2. 2Pulse valide le manifest et la compatibilité de version.
    3. 3Le répertoire de staging est rempli avec les .mv.db décompactés.
    4. 4Une bannière « Restauration en attente » apparaît.
    5. 5Redémarrez Pulse. Au démarrage, avant toute connexion JDBC, les fichiers stagés remplacent les fichiers actifs.

    Pourquoi stage-puis-apply ? H2 fait du memory-map sur ses fichiers ; un hot-swap corrompt le cache de pages. Stage-et-redémarrage est la seule approche sûre.

    Garde-fous d'exécution

    Garde mono-instance

    Verrou fichier OS (.pulse.lock) empêche deux Pulse de corrompre le même répertoire. Le second sort avec le code 75 (EX_TEMPFAIL) et les superviseurs ne bouclent pas.

    Arrêt gracieux

    Sur SIGTERM Pulse cesse d'accepter, draine l'in-flight, annule les schedulers, flush les subscribers, émet SHUTDOWN sur chaque connexion H2, libère le verrou. Chaque étape a un timeout de 10 s.

    Watchdog

    Toutes les 5 minutes un daemon compare « agents que la DB dit en cours » vs « agents réellement abonnés ». En cas de dérive, il réabonne et journalise. autoRecover: false disponible pour un change-control strict.

    Posture supply-chain

    • Pulse est distribué comme un binaire unique signé, un checksum SHA-256 accompagne chaque release. Vérifiez avant d'installer.
    • Le binaire est construit dans un environnement reproductible (Maven + Eclipse Temurin JDK 25). Même source, même binaire.
    • Nous n'embarquons aucun SDK d'analytics, aucune lib de télémétrie, aucun tiers qui « phone home ».
    • Les dépendances (Jackson, Logback, H2, Jetty, Jakarta Mail) sont fixées à des versions known-good et bundlées, pas téléchargées à l'exécution.

    Notes de conformité

    Pulse n'est formellement certifié pour aucun régime (HIPAA, SOC 2, PCI-DSS, RGPD). Ce que nous fournissons à la place :

    • Un support architectural pour des workloads conformes : auto-hébergé, journal d'audit, chiffrement des identifiants, capacité air-gap, rétention granulaire.
    • Une documentation à remettre à votre équipe sécurité / conformité.
    • Une configurabilité pour ajuster aux exigences de votre régime.

    RGPD

    Droit à l'oubli : construisez un pipeline qui supprime un user_id sur tous les topics. Résidence des données : Pulse tourne là où vous le faites tourner. Consentement : le template premium consent-tracker s'en occupe.

    HIPAA

    Déployable HIPAA-compliant avec LLM 100% local, guardian rules pour bloquer la sortie de PHI, rétention du journal d'audit et contrôles d'accès. Voir medical-xray-triage comme référence. Vous êtes le Covered Entity ; Pulse est le logiciel.

    SOC 2

    Journal d'audit, identifiants chiffrés au repos, multi-utilisateurs avec rôles et 2FA couvrent la plupart des contrôles. ENTERPRISE ajoute typiquement SSO + ACL granulaires.

    Les clients ENTERPRISE peuvent demander des termes contractuels personnalisés (DPA, lettres de sécurité). Le modèle auto-hébergé fait que Pulse n'est pas processeur de vos données au sens RGPD.

    Signaler une vulnérabilité

    Vous avez trouvé une vulnérabilité ? Écrivez à security@streamflowmesh.io avec :

    • Description du problème
    • Étapes de reproduction
    • Version Pulse affectée
    • Vos coordonnées

    Nos engagements

    • Accusé de réception en 48 heures.
    • Plan de remédiation en 7 jours pour les problèmes haute sévérité.
    • Crédit du chercheur dans les release notes (s'il le souhaite).

    Nous n'avons pas de bug bounty aujourd'hui, mais les découvertes haut-impact sur des chemins de code touchant la production sont compensées, contactez-nous.

    Écrire à l'équipe sécurité

    À lire ensuite