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.
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.
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.
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.
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).
Rétention par plan
| Plan | Rétention du journal |
|---|---|
| FREE | 30 jours |
| PRO | 365 jours |
| ENTERPRISE | Illimité |
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
- 1Uploadez un zip de sauvegarde via Paramètres → Sauvegardes → Restaurer depuis fichier (ou sélectionnez un snapshot local).
- 2Pulse valide le manifest et la compatibilité de version.
- 3Le répertoire de staging est rempli avec les .mv.db décompactés.
- 4Une bannière « Restauration en attente » apparaît.
- 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é