TL;DR
Worklist utilise le chiffrement ChaCha20-Poly1305 avec une architecture zero-knowledge. Vos données sont chiffrées sur votre appareil avec une cryptographie de niveau militaire avant d’atteindre nos serveurs. Même avec un accès complet à la base de données, nous ne pouvons physiquement pas lire vos tâches. L’architecture soutient la minimisation des données du RGPD et peut aider avec les garanties techniques HIPAA/SOC 2 lorsqu’elle est accompagnée des accords et contrôles opérationnels requis.
Notre principe fondamental.
Vos données sont chiffrées sur votre appareil avant même d’atteindre nos serveurs. Worklist est conçu pour que nous — l’entreprise — ne puissions pas déchiffrer, lire ni accéder à vos listes de travail, tâches ou commentaires. On appelle cela une architecture zero-knowledge.
Ce qui rend Worklist 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 »
- • Vulnérables à des fuites qui exposent tout
Worklist (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é
- • Les fuites de données ne révèlent rien d’utile — uniquement des blocs chiffrés
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 :
- Votre navigateur utilise Argon2id pour dériver une clé d’enveloppe à partir de votre mot de passe
- 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 avec la clé d’enveloppe dérivée du mot de passe
- La clé de données chiffrée est stockée sur nos serveurs — mais nous ne pouvons pas la déchiffrer sans votre mot de passe
- Nous utilisons le protocole OPAQUE PAKE, de sorte que nos serveurs ne voient jamais votre mot de passe en clair
Point clé : la clé d’enveloppe ne quitte jamais votre appareil. Sans votre mot de passe, la clé de données chiffrée nous est inutile.
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 vous envoyons le blob chiffré, vous saisissez à nouveau votre mot de passe pour le déchiffrer localement 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.
Chaque donnée sensible est chiffrée sur votre appareil :
- Titres, descriptions et paramètres des listes de travail
- Titres, contenus, checklists et commentaires des tâches
- Modèles de tâches récurrentes et planifications
- 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
Nos serveurs ne stockent que le texte chiffré — ils ne peuvent pas lire le texte en clair.
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 sont publiées dans un journal de transparence (arbre de Merkle) pour empêcher les attaques de l’homme du milieu
- Si vous retirez un membre, la clé de la liste est renouvelée et les membres restants reçoivent de nouvelles copies chiffrées
Nos serveurs vérifient sans déchiffrer.
Vous vous demandez peut-être : « Si le serveur ne peut pas déchiffrer, comment applique-t-il les permissions ? »
Nous utilisons des preuves HMAC — signatures cryptographiques qui prouvent votre droit d’accès sans révéler le texte en clair.
- Votre navigateur calcule un HMAC (hachage à clé) sur les données chiffrées avec une clé spécifique au membre
- Le serveur valide le HMAC pour confirmer que vous êtes membre actif
- Toute altération ou rejeu des données d’autrui échoue à la vérification HMAC
- Nous ne déchiffrons jamais la charge utile — nous vérifions seulement intégrité et autorisation
Ce que nos serveurs voient (ou non).
Nous NE voyons PAS
- × Titres et descriptions des listes de travail
- × Titres, contenus et checklists des tâches
- × Commentaires et discussions
- × Modèles de tâches récurrentes
- × Tout contenu placé dans des charges utiles chiffrées
- × Votre mot de passe (même haché)
Nous voyons
- ✓ 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)
Pourquoi certaines métadonnées sont visibles : Certains champs (comme le statut ou les échéances) doivent rester en clair pour que les serveurs puissent filtrer efficacement les requêtes, envoyer les rappels et maintenir les index. Ces champs ne contiennent aucun contenu sensible — uniquement les métadonnées opérationnelles qui font fonctionner l’app.
Garanties de sécurité.
Déverrouillage par mot de passe (côté client uniquement).
Votre mot de passe ne quitte jamais l’appareil en clair. Il est étiré avec Argon2id pour produire une clé d’enveloppe qui déchiffre votre clé de données maîtresse. 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.
Notre code backend n’appelle jamais d’opérations de déchiffrement sur les données utilisateur. Il valide seulement les preuves HMAC pour confirmer l’autorisation.
Rotation des clés au changement d’équipe.
Quand un membre est retiré ou quitte l’équipe, la clé de la liste est renouvelée. Les membres restants reçoivent de nouvelles copies chiffrées, ce qui empêche l’ancien membre de déchiffrer les futurs contenus.
Transparence des clés d’invitation.
Les clés publiques des invitations sont consignées dans un arbre de Merkle append-only. Les clients vérifient les preuves d’inclusion et de cohérence, empêchant le serveur de remplacer silencieusement des clés pour intercepter les données.
Cryptographie open source.
Nous utilisons des bibliothèques éprouvées : strong-box (ChaCha20-Poly1305), Argon2id (dérivation de clés), OPAQUE (authentification par mot de passe) 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 9497) et HPKE
- Preuves cryptographiques (HMAC) qui empêchent mathématiquement le déchiffrement côté serveur
- Journaux de transparence (arbres de Merkle) pour détecter les attaques par substitution de clés
- Dérivation des clés côté client avec Argon2id : nous ne voyons jamais votre mot de passe ni vos clés
Compromis du zero-knowledge.
Pas de récupération de mot de passe.
Si vous oubliez votre mot de passe, nous ne pouvons pas récupérer vos données. Il n’y a pas d’option « réinitialiser et garder vos données » car nous n’avons pas les clés pour les déchiffrer.
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) |
| Étirement du mot de passe | Argon2id (mémoire 64 Mio, 3 itérations, parallélisme 1) — transforme le mot de passe en clé d’enveloppe |
| 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) |
| Échange de clés (invitations) | HPKE (Hybrid Public Key Encryption) avec X25519 |
| Preuves d’intégrité | 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 aider avec des garanties techniques HIPAA ou SOC 2. Les PHI réglementées exigent toujours un accord écrit ou un BAA, ainsi que les contrôles opérationnels et la confirmation fournisseur requis par votre programme de conformité.
Questions fréquentes.
Que se passe-t-il si vous êtes piratés ?
Si un attaquant accède à notre base, il ne verra que des blocs chiffrés — en gros des octets aléatoires. Sans votre mot de passe (que nous ne stockons jamais), il est mathématiquement impossible avec les technologies actuelles de déchiffrer les données.
Les autorités peuvent-elles vous obliger à déchiffrer mes données ?
Non, parce que nous ne le pouvons pas. Nous n’avons pas les clés. Même avec une réquisition judiciaire, nous ne pouvons fournir que les textes chiffrés — inutiles sans votre mot de passe.
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 Worklist peuvent-ils voir mes données ?
Non. Notre code backend est conçu pour ne jamais déchiffrer les charges utiles utilisateur. Même les administrateurs avec un accès complet à nos serveurs ne peuvent pas lire vos listes ou vos tâches.
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.
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 9497: OPAQUE Asymmetric 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
Prêt pour une vraie confidentialité ?
Rejoignez les équipes qui font confiance à Worklist pour garder leur travail véritablement privé. Démarrez votre essai gratuit — sans carte bancaire.
Commencer l’essai gratuitDes questions de sécurité ? Écrivez-nous à security@worklist.app