🔒

Confidentialité et sécurité

Vos tâches sont chiffrées sur votre appareil, avec des clés que nous ne détenons jamais. L'autorisation est imposée par des signatures, pas par des drapeaux en base de données. Cette page vous dit exactement ce que nos serveurs peuvent et ne peuvent pas voir.

🚃 La frontière de confiance | Ce que nous ne prétendons pas | English 🚃

🗺️

La frontière de confiance

Chaque tâche et chaque commentaire sont chiffrés côté client avant l'envoi. Ce qui traverse le réseau : du texte chiffré, des signatures et des clés scellées. Le rôle du serveur n'est pas de lire vos données — c'est de les vérifier.

Vos appareils

La zone en clair

Tâches, commentaires, étiquettes et règles de grant sont lisibles ici — et seulement ici.
Les clés sont générées sur l'appareil ; les secrets vivent dans un coffre scellé par votre phrase secrète.
Tout le chiffrement et toutes les signatures se font avant que quoi que ce soit ne parte.
texte chiffré →
signatures →
clés scellées →
← journal vérifié
Nos serveurs

La zone chiffrée

Chaque opération arrive signée cryptographiquement. Nous vérifions la signature, l'appartenance de l'auteur et sa chaîne de capacités avant d'accepter le moindre octet dans le journal.
Nous stockons du texte chiffré, des clés scellées et le journal d'opérations signé. Nous ne détenons aucune clé de contenu.
🛑 Le pont de publication
La seule porte balisée hors de la frontière de chiffrement. Partager une voie au-delà de ses membres chiffrés est un acte explicite, voie par voie. Cela n'arrive jamais par effet de bord.

La seconde exception délibérée, ce sont les métadonnées : comme tout système E2EE, nous voyons la forme de votre activité sans pouvoir en voir le contenu. Nous énumérons précisément quoi ci-dessous, plutôt que d'espérer que vous ne poserez pas la question.

Ce que nos serveurs peuvent et ne peuvent pas voir

Ne peuvent pas voir

Le contenu des tâches et des commentaires
La moindre clé de chiffrement de contenu — DEK ou KEK de voie
Les clés secrètes de votre identité — le coffre est scellé par une clé dérivée de votre phrase secrète
Quel dépôt ou quel ticket une automatisation surveille — masqué derrière un HMAC
La règle définissant ce que couvre le grant d'un agent

Peuvent voir

Les identifiants de voies, les clés publiques des membres et les rôles — le graphe d'appartenance
Le nombre d'objets, le nombre de versions, les tailles et les horodatages
Quels membres et quels agents détiennent des clés pour quels objets — mais jamais les clés elles-mêmes
Le journal d'opérations signé lui-même : qui a soumis, quand, et en quel volume
Sur quels identifiants d'éléments le grant d'un agent a été matérialisé

Cette colonne de droite est notre divulgation honnête des métadonnées. Si votre modèle de menace exige de cacher le graphe d'appartenance lui-même, nous n'y sommes pas encore — et nous préférons vous le dire ici plutôt que dans votre rapport de pentest.

🔒

La cryptographie

Chaque invocation AEAD porte des données associées qui épinglent le texte chiffré à sa place exacte dans le système — une clé scellée ne peut pas être rejouée entre voies, destinataires, époques ou usages, car l'AAD ne correspondrait pas.

Chiffrement du contenu
AES-256-GCM · clé aléatoire fraîche de 256 bits par version d'élément · nonces aléatoires de 96 bits · les données associées lient chaque texte chiffré à sa voie, son élément, sa version et son époque de clé
Signatures
Ed25519 en vérification stricte · signatures malléables ou à points d'ordre mixte rejetées
Scellement des clés aux membres
ECIES : X25519 éphémère → HKDF-SHA256 (séparation de domaines, lié aux deux clés publiques) → AES-256-GCM · contrôle du comportement contributif sur le secret partagé
Coffre d'identité (phrase secrète → clé)
Argon2id · 64 Mio de mémoire / 3 itérations · paramètres figés dans le format du coffre
Hachage & intégrité
SHA-256 · blobs chiffrés adressés par contenu, intégrité vérifiée à l'envoi
Encodage canonique
CBOR déterministe (RFC 8949 §4.2.1) pour toute structure signée ou hachée — aucune ambiguïté de signature

La hiérarchie des clés

Clés d'identité — Ed25519 + X25519, par utilisateur
Générées sur l'appareil. Les secrets vivent dans un coffre chiffré sous une clé dérivée par Argon2id ; le serveur stocke le coffre mais ne peut pas l'ouvrir.
↓ scelle
Clés de voie (KEK) — 256 bits, par voie et par époque
Scellées individuellement à la clé de scellement de chaque membre humain. Retirer un membre incrémente l'époque et rescelle dans la même opération — pas de rotation paresseuse.
↓ enveloppe
Clés de contenu (DEK) — fraîches par version d'élément
Une nouvelle clé aléatoire pour chaque version de chaque élément, enveloppée sous la clé de voie courante — et scellée élément par élément aux agents disposant d'un grant.
↓ chiffre
Votre contenu — texte chiffré AES-256-GCM
La seule forme sous laquelle tâches et commentaires atteignent jamais nos serveurs.

Qui peut déchiffrer quoi

Une arête est une clé que vous détenez. Une arête absente, c'est du texte chiffré illisible. Trois voies, trois humains, un agent — suivez vous-même n'importe quel chemin.

APPAREILS DES MEMBRES — le seul endroit où existent le clair et les clés descellées
NOS SERVEURS — clés scellées et texte chiffré uniquement
deploy-bot · service
sa propre paire de clés · jamais de KEK
Alice · admin
signature Ed25519 · scellement X25519
Bob · membre
signature Ed25519 · scellement X25519
Charlie · membre
signature Ed25519 · scellement X25519
Lancement — KEK de voie
scellée à Alice + Bob
Conformité — KEK de voie
scellée à Bob + Charlie
Alice / Privé — KEK
scellée à Alice seule
Lancement · tâche 2
DEK2 enveloppée par la KEK · aussi scellée à deploy-bot
Lancement · tâche 1
DEK1 enveloppée par la KEK de Lancement
Conformité · tâche
DEK3 enveloppée par la KEK de Conformité
Privé · tâche
DEK4 enveloppée par la KEK privée
descelle — X25519 → HKDF → AES-GCM
désenveloppe la DEK
grant de DEK par élément et par version uniquement
une clé que vous détenez
grant par élément
pas de trait — du chiffré illisible
🛑 Charlie n'a aucune arête vers Lancement — pour lui, c'est du texte chiffré.
🛑 Bob n'a aucune arête vers Alice / Privé.
🤖 deploy-bot atteint une seule tâche — jamais une clé de voie.
🤖

Conçu pour les agents — à vos conditions

Pour les équipes qui déploient déjà des agents IA sur de vrais systèmes. Vous choisissez ce qu'un agent voit — un siège complet à vos côtés ou une seule tâche — et dans les deux cas, le révoquer est une opération, pas une cérémonie de rotation de clés.

Un siège complet
Concevoir et construire avec vous
Via la CLI, un agent peut détenir les mêmes accès en lecture et en écriture qu'un membre a sur ses voies dans le navigateur. Les membres tirent pleinement parti de leurs agents. Le RBAC granulaire de l'organisation définit dans quelles voies le membre et ses agents travaillent.
Une seule tâche
Restreint par grant
Ou donnez aux agents des permissions fines. Une paire de clés désignée, des opérations précises sur des éléments précis, un accès lecture/écriture ou lecture seule. Les clés de contenu sont scellées élément par élément, et le serveur rejette tout commit qui les sous-partage ou les sur-partage.
Contrôle administrateur
Votre organisation, vos exigences
Les administrateurs de l'organisation fixent le plafond : désactiver entièrement l'accès CLI, configurer un RBAC granulaire par voie, et superposer des contrôles d'entreprise comme des listes d'autorisation pour l'automatisation du navigateur, afin d'atteindre votre niveau de conformité. La révocation reste une seule opération, sans rotation de clés.

Chaque chaîne se termine par un humain

Admin humain
rôles complets sur la voie, racine auto-émise
→ délègue →
Agent
un grant, des éléments listés, une capacité qui expire

Les jetons de capacité ne peuvent que se restreindre ou rester identiques à chaque saut — jamais s'élargir — et sont vérifiés côté serveur à chaque opération. La racine doit être signée par un humain — l'autorité d'un agent est toujours auditable jusqu'à une personne.

🚉

Deux façons de monter à bord

Un membre humain et un agent de service montent par des portes différentes. L'un reçoit la clé de voie ; l'autre jamais — suivez chaque protocole pas à pas.

Ajouter un humain

member.add.v1 · Dana rejoint, la clé de voie lui est scellée
Dana → Dana
Génère son identité Ed25519 + X25519 sur son propre appareil.
Dana → Server
Dépose un coffre de clés chiffré par phrase secrète — opaque pour nous.
Alice → Alice
Descelle la KEK courante (époque n) et la scelle à la clé publique de Dana. Les époques antérieures sont optionnelles — les inclure est la décision explicite « reçoit-elle l'historique d'avant son arrivée ? ».
Alice → Server
Commit signé : member.add — ligne de roster, KEK scellées, sa capacité.
Le serveur vérifie
Signature de l'enveloppe · Alice est une admin active · la chaîne de capacités est enracinée et ne fait que se restreindre · la KEK d'époque courante de Dana est présente, aucune époque future · compare-and-swap sur la racine d'état.
Dana → Server
Signe un défi HMAC avec sa clé Ed25519 → un jeton de session de 24 heures, puis récupère ses KEK scellées et les objets chiffrés.
Dana → Dana
Descelle la KEK → désenveloppe les DEK → lit la voie. Le clair n'existe qu'ici.

Accorder un grant à un agent

grant.create.v1 · deploy-bot entre — jamais de KEK
Alice → Server
Commit signé : grant.create — la clé publique du bot, les types d'opérations autorisés, un drapeau de lecture. La règle de sélection du grant reste chiffrée ; nous n'apprenons jamais ce qu'il couvre.
Alice → Bot
Délègue une capacité restreinte au grant — chaînée depuis sa capacité d'admin, atténuation seule, TTL d'un jour.
Règle serveur
Désormais, tout commit touchant un élément couvert doit sceller une DEK au bot — et à personne d'autre. Sous-partage ou sur-partage : rejet.
Alice → Server
Sa prochaine écriture sur un élément couvert : DEK fraîche, enveloppée par la KEK et scellée au bot.
Bot → Server
Défi/réponse → jeton de session ; récupère l'élément et sa DEK scellée.
Bot → Bot
Descelle la DEK → déchiffre ce seul élément. Il n'a de chemin vers rien d'autre.
Bot → Server
Écrit en retour : chiffre sous une DEK fraîche, la scelle à chaque humain actif — il ne détient aucune KEK pour envelopper. Le serveur vérifie la chaîne de capacités, la vitalité du grant, le périmètre des types d'opérations, et que l'ensemble des DEK scellées est complet.
Alice → Server
Révocation : un seul commit grant.revoke. La prochaine requête du bot échoue à la revérification de vitalité — coupure immédiate, sans rotation de clés.
🛑 Le retrait est le miroir
Retirer un humain fait avancer la voie d'une époque : une KEK toute neuve est scellée à chaque membre restant, et le serveur vérifie que ce lot de rescellement est complet avant d'accepter le retrait — le partant ne lit rien de ce qui s'écrit ensuite. Retirer un agent ne fait tourner aucune clé, car il ne l'a jamais détenue.
🇪🇺

La plateforme

Une petite surface, sûre en mémoire, servie depuis une infrastructure européenne — l'API, le cœur cryptographique et le client navigateur partagent une même base de code sûre en mémoire.

Aucun sous-traitant, aucun cookie
Aucun sous-traitant tiers ne touche vos données, et nous ne posons aucun cookie — pas d'analytics, pas de traceurs. Les revues de conformité sont rapides et simples.
Une API petite et contenue
Un service compact, un plafond dur de 4 Mio par requête, des quotas par téléverseur avec ramasse-miettes, et des blobs adressés par contenu vérifiés à l'envoi. Les lectures de blobs non autorisées renvoient 404 — sans jamais confirmer l'existence.
Des sorties sous garde
Les webhooks sortants passent un filtre SSRF : HTTPS uniquement, avec blocage des plages loopback, privées, link-local, CGNAT et réservées, en IPv4, IPv6 et formes IPv4-mappées — à l'enregistrement comme à l'envoi.
Une politique navigateur stricte
Une Content-Security-Policy dont la liste d'autorisation de scripts est 'self' plus les empreintes SHA-256 des ressources exactes livrées — pas d'unsafe-inline, pas d'unsafe-eval — aux côtés de HSTS, nosniff, du framing refusé et d'une politique de référent stricte.
Analyse de la chaîne d'approvisionnement en CI
Chaque changement est confronté en CI à une base d'avis de sécurité, avec des lints stricts (avertissements refusés) et la suite de tests complète.
Sûr en mémoire, de haut en bas
Un langage sûr en mémoire partout — le client navigateur est compilé en WebAssembly depuis la même base de code. La classe des CVE de corruption mémoire derrière la plupart des exploits d'infrastructure est hors jeu.
🛑

Ce que nous ne prétendons pas

One Track est un outil de gestion de projet, pas un produit de sécurité dédié — voici le registre honnête des affirmations de confidentialité et de sécurité ci-dessus, à jour en juillet 2026.

Pas encore d'audit tiers ni de certification. Pas de SOC 2, pas d'ISO 27001, pas de revue cryptographique externe, et nous ne signons pas de BAA. S'il vous les faut aujourd'hui, nous ne sommes pas encore prêts pour vous — parlons calendrier.
Les métadonnées sont visibles. Les graphes d'appartenance, la chronologie d'activité et le nombre d'objets ne nous sont pas cachés — voir le tableau de divulgation ci-dessus.
La rotation ne va que vers l'avant. Le retrait d'un membre protège le futur, pas le passé.
Vous avez trouvé quelque chose ? Voir /.well-known/security.txt. Nous répondons aux chercheurs.

🚃 Parlons calendrier | Relire la frontière 🚃