TL;DR
SealTask chiffre le contenu lisible de l’espace de travail sur votre appareil avec ChaCha20-Poly1305 avant la synchronisation. Le service ne détient pas les clés nécessaires pour déchiffrer ce contenu, mais traite toujours des métadonnées de compte, facturation, sécurité, audit, service et espace de travail. Une clé de secours que vous conservez peut rétablir l’accès une fois après la perte du mot de passe. Cette conception favorise la minimisation des données ; un usage réglementé exige toujours les accords et contrôles appropriés.
Un terme de sécurité doit décrire une frontière, pas décorer une affirmation.
Le vocabulaire utilisé dans les pages sécurité, guides, comparaisons et incidents de SealTask. Les termes disposant d’une explication complète renvoient vers leur page canonique.
Parcourir tout le centre de connaissancesNotre principe fondamental.
Le contenu lisible de l’espace de travail est chiffré sur votre appareil avant d’atteindre nos serveurs. SealTask est conçu pour que l’entreprise ne puisse pas déchiffrer le texte en clair des tâches, notes, commentaires, listes de contrôle, titres de liste ou pièces jointes. Le service traite toujours les métadonnées indiquées ci-dessous. Cette limite appliquée au contenu s’appelle zero-knowledge.
Ce qui rend SealTask différent.
Gestionnaires de tâches classiques.
Ce que fait la concurrence
- • Stockent vos données en clair sur leurs serveurs
- • Peuvent lire chaque tâche, commentaire et fichier que vous créez
- • Peuvent analyser votre contenu pour la publicité, l’entraînement IA ou des « fonctionnalités »
- • Une compromission ou une voie d’accès autorisée peut exposer le contenu lisible et les métadonnées
SealTask (zero-knowledge).
Ce que nous faisons
- • Chiffre sur votre appareil avant l’envoi vers nos serveurs
- • Nous ne pouvons pas déchiffrer vos tâches, même si nous le voulions
- • Aucune analyse, aucun entraînement IA sur votre travail privé
- • Une compromission de la base peut exposer le texte chiffré et les métadonnées, mais pas le contenu lisible sans les clés détenues côté client
Comment fonctionne le chiffrement zero-knowledge.
Vous créez votre compte.
À l’inscription, votre mot de passe ne quitte jamais le navigateur en clair. À la place :
- Nous utilisons le protocole OPAQUE PAKE, de sorte que nos serveurs ne voient jamais votre mot de passe en clair
- Après une inscription ou connexion réussie, OPAQUE donne à votre navigateur une clé d’export secrète que nous ne recevons jamais
- Une « clé de données » aléatoire de 32 octets est générée sur votre appareil
- Cette clé de données est chiffrée localement avec une clé d’enveloppe dérivée de cette clé d’export OPAQUE
- La clé de données chiffrée est stockée sur nos serveurs — mais nous ne pouvons pas la déchiffrer sans le matériel de déverrouillage côté client
- Vous pouvez télécharger une clé de secours à usage unique. Elle enveloppe la même clé de données dans votre navigateur, et nous ne stockons qu’une enveloppe de récupération chiffrée
Point clé : la clé de déverrouillage et la clé de données sont traitées dans votre navigateur. Nous ne stockons que des enveloppes chiffrées, jamais de mots de passe en clair ni de clés d’espace de travail.
Pourquoi stocker la clé de données chiffrée ?
Pour vous permettre de vous connecter depuis n’importe quel appareil. Lorsque vous changez d’ordinateur ou utilisez votre téléphone, nous envoyons le blob chiffré, votre navigateur le déverrouille localement après une connexion sécurisée et vous voilà reconnecté. Sans ce stockage, il faudrait recopier manuellement une clé de 32 octets entre appareils — UX désastreuse pour la même sécurité.
Vous créez une liste de travail ou une tâche.
Le contenu lisible de l’espace de travail est chiffré sur votre appareil ; les métadonnées d’exploitation restent visibles côté serveur :
- Titres et descriptions des listes de travail
- Titres, contenus, checklists et commentaires des tâches
- Le contenu du modèle de tâche récurrente est chiffré ; la planification cron, le fuseau horaire, l’état actif, l’itération et les horodatages de matérialisation restent visibles côté serveur
- Tout est chiffré avec ChaCha20-Poly1305 AEAD (un chiffrement moderne et audité)
- Chaque liste de travail a sa propre clé de chiffrement dérivée de votre clé de données
Le serveur stocke les charges utiles chiffrées de l’espace de travail et les métadonnées d’exploitation déclarées ; sans les clés détenues côté client, il ne peut pas lire le texte en clair chiffré.
Vous invitez vos coéquipiers.
Lors du partage de listes de travail :
- Chaque membre reçoit sa propre copie chiffrée de la clé de la liste
- Les clés sont échangées via HPKE (Hybrid Public Key Encryption)
- Les clés publiques d’invitation sont inscrites dans un journal de transparence Merkle. Un point de contrôle précédemment approuvé peut révéler une divergence pendant la vérification, mais le client actuel ne reste pas en échec fermé et ne conserve pas cette détection : il peut écarter le point de contrôle et reprendre depuis l’origine
- Retirer un collaborateur révoque son accès à la liste autorisé par le serveur. Le serveur qui valide le changement signale ses flux actifs après le commit ; les changements provenant d’un autre serveur, groupés ou non signalés sont revérifiés sous 30 secondes au plus. Les données déjà livrées ou mises en tampon par le transport ne peuvent pas être rappelées. La version actuelle ne renouvelle pas automatiquement la clé de liste, ne rechiffre pas la liste et n’efface pas les contenus ou clés obtenus pendant un accès autorisé. Pour une nouvelle frontière cryptographique, créez une nouvelle liste réservée aux membres actuels.
Le serveur contrôle la cohérence HMAC sans déchiffrer la charge utile.
L’état de la session et de l’adhésion active en base autorise l’accès. Séparément, le navigateur dérive de la clé de liste, avec HKDF et une constante de protocole fixe, une clé de liaison de charge utile propre à la liste ; cette même clé est copiée pour chaque adhésion et stockée par le serveur.
Le serveur utilise cette clé pour vérifier un HMAC sur le texte chiffré. La preuve indique seulement que le HMAC correspond aux octets de ce texte chiffré, sans les déchiffrer.
- Votre navigateur dérive de la clé de liste la clé de liaison propre à la liste avec HKDF ; ce n’est pas une clé de déchiffrement du contenu
- Le serveur vérifie la session authentifiée et l’adhésion active avant d’autoriser la requête
- Le serveur stocke la clé de liaison copiée et peut vérifier ou calculer des HMAC correspondants sur le texte chiffré
- Le HMAC n’établit ni la fraîcheur, ni une protection contre le rejeu, ni une liaison à une entité ou un membre, ni l’authenticité vis-à-vis du serveur
Ce que nos serveurs voient (ou non).
Nous NE voyons PAS
- × Titres de tâche lisibles
- × Corps de tâche et notes lisibles
- × Contenu lisible des modèles de tâches récurrentes
- × Corps de commentaire lisibles
- × Contenu lisible des listes de contrôle
- × Titres et descriptions de liste lisibles
- × Contenu en clair des pièces jointes
- × Mots de passe de compte en clair
- × Clés de déchiffrement du contenu de l’espace de travail
Exemples non exhaustifs de métadonnées d’espace de travail visibles
- ✓ E-mail du compte (pour la connexion)
- ✓ Relations d’adhésion (qui est dans quelle liste)
- ✓ Statut des tâches (ouvert/fermé) et priorité
- ✓ Échéances et horodatages
- ✓ Affectations de délégation (uniquement des IDs)
- ✓ Métadonnées nécessaires aux requêtes (IDs, dates de création)
- ✓ Sels et preuves propres à chaque adhésion, ainsi que la clé de liaison de charge utile propre à la liste, stockée par le serveur pour vérifier ou calculer des HMAC correspondants ; ce n’est pas une clé de déchiffrement du contenu
- ✓ Planification des récurrences, fuseau horaire, état actif, itération et dates de matérialisation
- ✓ Relations des pièces jointes, identifiants de stockage, taille du texte chiffré, état et horodatages
- ✓ Types d’événements en temps réel, identifiants d’acteur et d’entité, noms des champs modifiés, horodatages et nombres d’événements manqués
Portée et sensibilité : La liste affichée donne des exemples non exhaustifs de métadonnées d’espace de travail visibles côté serveur ; elle ne constitue pas l’inventaire complet des modèles actuels de persistance, des réponses API ou des événements SSE. Elle ne constitue pas non plus un inventaire complet des données personnelles : l’authentification du compte, la facturation, la sécurité et l’audit, la prévention des abus et la télémétrie du service sont des domaines distincts décrits de façon non exhaustive dans la politique de confidentialité. Les métadonnées peuvent elles-mêmes être sensibles. La taille du texte chiffré d’une pièce jointe donne généralement une approximation de la taille du fichier d’origine.
Garanties de sécurité.
Déverrouillage authentifié par mot de passe (côté client uniquement).
Votre mot de passe ne quitte jamais l’appareil en clair. Une authentification OPAQUE réussie donne à votre navigateur une clé d’export qui déverrouille localement votre clé de données. Cette clé est ensuite étendue avec HKDF pour dériver des clés distinctes par liste de travail.
Le serveur ne peut pas déchiffrer les charges utiles chiffrées de l’espace de travail.
Le backend ne déchiffre pas les charges utiles chiffrées. Les contrôles de session et d’adhésion en base autorisent les requêtes. Avec sa clé de liaison propre à la liste, le serveur peut vérifier ou calculer un HMAC correspondant au texte chiffré ; cela prouve la cohérence du texte chiffré, pas la fraîcheur, la protection contre le rejeu, la liaison à une entité ou un membre, ni l’authenticité vis-à-vis du serveur.
Le retrait d’accès est limité et non rétroactif.
Retirer un collaborateur révoque son accès à la liste autorisé par le serveur. Le serveur qui valide le changement signale ses flux actifs après le commit ; les changements provenant d’un autre serveur, groupés ou non signalés sont revérifiés sous 30 secondes au plus. Les données déjà livrées ou mises en tampon par le transport ne peuvent pas être rappelées. La version actuelle ne renouvelle pas automatiquement la clé de liste, ne rechiffre pas la liste et n’efface pas les contenus ou clés obtenus pendant un accès autorisé. Pour une nouvelle frontière cryptographique, créez une nouvelle liste réservée aux membres actuels.
Transparence des clés d’invitation.
Les clés publiques d’invitation sont inscrites dans un arbre Merkle en ajout seul. Un point de contrôle précédemment approuvé peut révéler une divergence, mais le client actuel peut l’écarter et reprendre depuis l’origine ; cette reprise et le premier usage restent des frontières de confiance, pas des garanties inconditionnelles de continuité.
Les clés de secours restent zero-knowledge.
Une clé de secours est générée dans votre navigateur et doit être enregistrée par vous. Elle crée une enveloppe chiffrée séparée pour la même clé de données ; nous ne stockons que le fichier d’identifiants de récupération et l’enveloppe chiffrée, donc nous ne pouvons ni réinitialiser votre mot de passe ni lire vos données sans cette clé enregistrée.
Cryptographie open source.
Nous utilisons des bibliothèques éprouvées : strong-box (ChaCha20-Poly1305), OPAQUE (authentification par mot de passe), HKDF (dérivation de clés), Argon2id (durcissement des mots de passe OPAQUE et migration legacy) et HPKE (échange de clés). Tout notre code cryptographique est open source et auditable.
Comment nous vérifions notre sécurité.
Nos affirmations de sécurité sont vérifiables, pas du simple marketing. Voici comment nous nous assurons que l’architecture zero-knowledge fonctionne comme promis :
- Code cryptographique open source disponible sur GitHub pour audit public par les chercheurs en sécurité
- Bibliothèques éprouvées incluant ChaCha20-Poly1305 (RFC 8439), Argon2id, OPAQUE PAKE (RFC 9807) et HPKE
- La clé de liaison propre à la liste et stockée par le serveur lui permet de vérifier ou calculer un HMAC correspondant au texte chiffré ; la session et l’adhésion en base autorisent l’accès, tandis que le HMAC ne prouve ni la fraîcheur, ni la protection contre le rejeu, ni la liaison à une entité ou un membre, ni l’authenticité vis-à-vis du serveur
- Les preuves Merkle peuvent révéler une divergence par rapport à un point de contrôle approuvé, mais le client actuel peut l’écarter et reprendre depuis l’origine
- Déverrouillage côté client à partir des clés d’export OPAQUE : nous ne voyons jamais votre mot de passe ni vos clés
- Les clés de secours à usage unique sont générées et conservées par l’utilisateur, jamais par SealTask
Compromis du zero-knowledge.
Une clé de secours peut restaurer l’accès après la perte du mot de passe.
Enregistrez une clé de secours une fois et gardez-la privée. Si vous perdez votre mot de passe, cette clé vous permet de le réinitialiser et de conserver l’accès aux données chiffrées. Comme SealTask n’en conserve pas de copie, les comptes sans clé de secours enregistrée restent irrécupérables.
Pas de recherche côté serveur.
Comme le contenu de vos tâches est chiffré, nous ne pouvons pas proposer de recherche full-text serveur sur toutes vos tâches. La recherche s’effectue dans votre navigateur après déchiffrement.
Atténuation : nous optimisons la recherche côté client avec des index et un déchiffrement rapide pour rester performants.
Spécifications techniques.
| Chiffrement symétrique | ChaCha20-Poly1305 AEAD (via la bibliothèque strong-box) |
| Déverrouillage de la clé de données | Clé d’export OPAQUE + HKDF-SHA256 — dérive les clés d’enveloppe locales pour la clé de données chiffrée |
| Hiérarchie de clés | HKDF-SHA256 — dérive les clés de liste et d’adhésion depuis la clé de données |
| Authentification par mot de passe | OPAQUE PAKE (courbe Ristretto255) |
| Authentification à deux facteurs | TOTP par application d’authentification (RFC 6238) avec codes de secours à usage unique ; facultative par compte |
| Clés de secours | Une clé de secours active à usage unique par utilisateur ; générée côté client et conservée par l’utilisateur |
| Échange de clés (invitations) | HPKE (Hybrid Public Key Encryption) avec X25519 |
| Contrôles de cohérence de charge utile | HMAC-SHA256 |
| Sérialisation | CBOR (Concise Binary Object Representation) |
| Taille des clés | 256 bits (32 octets) pour toutes les clés symétriques |
Toutes les opérations cryptographiques se déroulent dans votre navigateur via les API WebCrypto et des modules WASM audités compilés depuis Rust.
Audits & transparence.
Pile cryptographique open source.
Toute notre implémentation cryptographique est open source et disponible sur GitHub. Nous invitons les chercheurs en sécurité à auditer notre code.
Voir sur GitHubConformité.
Notre architecture zero-knowledge soutient la minimisation des données du RGPD et peut contribuer aux garanties techniques. SealTask doit donner son accord écrit exprès avant toute utilisation de PHI. Lorsque HIPAA s’applique, les parties doivent conclure un BAA conforme à HIPAA avant utilisation. Le chiffrement n’est qu’une garantie ; votre programme de conformité doit assurer les contrôles opérationnels et l’évaluation du fournisseur requis.
Questions fréquentes.
Que se passe-t-il si vous êtes piratés ?
Un attaquant ayant accès à la base pourrait obtenir le texte chiffré ainsi que les métadonnées de compte, de routage, d’audit et d’espace de travail. Le contenu stocké n’est pas lisible sans les clés de déchiffrement détenues côté client, sous réserve de la sécurité de la cryptographie, des clients et de la gestion des clés.
Les autorités peuvent-elles vous obliger à déchiffrer mes données ?
Une demande légale peut nous obliger à fournir le texte chiffré et les métadonnées visibles de compte, facturation, sécurité, audit, service et espace de travail. Nous ne détenons pas les clés nécessaires pour déchiffrer le contenu lisible de l’espace de travail.
Que se passe-t-il si j’oublie mon mot de passe ?
Si vous avez enregistré une clé de secours, vous pouvez l’utiliser une seule fois pour réinitialiser votre mot de passe et conserver l’accès à vos données chiffrées. Sans clé de secours enregistrée, SealTask ne peut pas restaurer les données pour vous.
Quelle différence avec le « chiffré au repos » ?
« Chiffré au repos » signifie que les données sont chiffrées sur les disques du serveur, mais le serveur possède les clés. Le chiffrement de bout en bout signifie que seuls les terminaux possèdent les clés — le serveur n’a jamais accès au texte en clair.
Les employés de SealTask peuvent-ils voir mes données ?
Le personnel de SealTask et les administrateurs de base ne détiennent pas les clés côté client nécessaires pour déchiffrer les charges utiles de l’espace de travail. Les systèmes et personnes autorisés peuvent toutefois accéder aux métadonnées visibles décrites sur cette page.
Si je veux exporter mes données ?
Vous pouvez exporter vos données déchiffrées à tout moment depuis l’app. Comme le déchiffrement a lieu dans votre navigateur, vous obtenez des fichiers JSON/CSV lisibles — pas des blocs chiffrés.
SealTask prend-il en charge l’authentification à deux facteurs ?
Oui. Vous pouvez activer dans les paramètres de sécurité une authentification à deux facteurs par application d’authentification (RFC 6238 TOTP) et enregistrer des codes de secours à usage unique. La connexion exige alors votre mot de passe et un code actuel. Cette protection concerne la connexion au compte ; elle est distincte du chiffrement côté client qui protège le contenu de l’espace de travail.
Références et standards.
Nos choix cryptographiques suivent des standards industriels et des spécifications relues par les pairs.
- 01 RFC 8439: ChaCha20 and Poly1305 for IETF Protocols — Notre standard de chiffrement symétrique
- 02 RFC 9807: The OPAQUE Augmented PAKE Protocol — Authentification par mot de passe zero-knowledge
- 03 RFC 9180: Hybrid Public Key Encryption (HPKE) — Échange de clés pour les invitations d’équipe
- 04 RFC 9106: Argon2 Memory-Hard Function — Dérivation de clés basée sur le mot de passe
- 05 NIST SP 800-175B: Guideline for Using Cryptographic Standards — Recommandations cryptographiques fédérales
- 06 GDPR Article 32: Security of Processing — Exigences européennes de protection des données
- 07 RFC 6238 — TOTP — Authentification à deux facteurs
Prêt pour une vraie confidentialité ?
Rejoignez les équipes qui font confiance à SealTask pour garder leur travail véritablement privé. Commencez sur Free — sans carte bancaire.
Commencer gratuitementDes questions de sécurité ? Écrivez-nous à security@sealtask.com