Kerlok · stockage objet souverain

Nous ne pouvons pas lire vos données.

Kerlok est un stockage objet compatible S3, hébergé et opéré en Europe, dans lequel l'opérateur est cryptographiquement incapable de lire les données de ses clients. Une réquisition, un administrateur corrompu ou un attaquant disposant des droits root ne produisent que du chiffré opaque.

Demander un accès anticipé Voir le modèle de menace

Union européenne Divulgation nulle API S3 native 0 € d'egress Hybridation post-quantique

Votre appareil

Mot de passe: Argon2id · 512 Mio
Clé de compte: reste sur l'appareil
Paire maître: X25519 + ML-KEM-768
Clé de bucket: AES-256

Divulgation nulle Vous seul détenez la clé

Nos serveurs

Objets: fragments chiffrés
Enveloppes: blobs de clés chiffrés
Auth: vérificateur OPAQUE
Clés en clair: aucune

9f2c41ab7d05c318 e6b90a742f8dbb51

Figure 1 La frontière de chiffrement. Tout ce qui la traverse est déjà opaque.

11 nines Durabilité annuelle · modélisée

99,95 % Disponibilité visée · mono-région

< 80 ms GET 1 Mio · p99

0 € Frais de sortie · egress

Objectifs d'architecture, pas de mesures de production. La durabilité est un résultat de modèle : le modèle et ses hypothèses seront publiés avec le service, ainsi que les chiffres réellement observés.

Le différenciateur

« Cloud souverain » est déjà une case à cocher.

La localisation européenne répond à la question « qui a le droit d'accéder ». Elle ne répond pas à « qui peut accéder ». Quatre propriétés, prises ensemble, n'existent pas encore à l'échelle sur le marché du stockage objet.

Incapacité technique de lire

La souveraineté juridique encadre le droit d'accès. Le chiffrement à divulgation nulle supprime la capacité d'accès. Un employé corrompu, une réquisition ou un attaquant root n'obtiennent que des blocs inexploitables.

Vérifiabilité par le client

La promesse ne vaut rien s'il faut nous croire. Clients open source, builds reproductibles, journal de transparence des versions publiées, audits cryptographiques externes publiés. C'est la partie coûteuse : c'est aussi la seule qui nous distingue d'un concurrent qui affirme la même chose.

Effacement prouvable

Détruire la clé rend les données définitivement illisibles, y compris sur les sauvegardes et les bandes. L'article 17 du RGPD, habituellement une plaie opérationnelle, devient une opération atomique et auditable.

Sortie sans friction

API S3 native, aucun frais de sortie, export en masse outillé. Le verrouillage par la facture d'egress est un modèle économique, pas une contrainte technique : nous ne le reprenons pas.

Deux plans d'accès, un seul moteur

Votre outillage S3 fonctionne. Sans modification.

La divulgation nulle et la compatibilité S3 sont contradictoires par nature : un SDK AWS envoie des octets en clair et attend du serveur qu'il calcule des ETags. Nous ne choisissons pas — nous déplaçons la frontière de chiffrement.

Mode compatible

Le serveur chiffre Clé présente en mémoire

Le SDK AWS, rclone ou Veeam pointent directement sur l'edge Kerlok, qui chiffre à la réception. Toutes les opérations serveur restent disponibles.

Outillage: Non modifié
Copie serveur: Disponible
ETag = MD5: Oui
Clé en clair: Présente sur l'edge

Mode divulgation nulle

La passerelle chiffre La clé ne sort pas de chez vous

Le même outillage, pointé sur localhost. La passerelle kerlok-gw détient la clé et chiffre avant l'envoi. L'edge ne voit que du chiffré.

Outillage: Non modifié
Copie serveur: Impossible
ETag = MD5: Non
Clé en clair: Jamais côté serveur

Le mode compatible n'est pas à divulgation nulle.

Nous le nommons ainsi sans ambiguïté dans le produit, dans la facturation et dans la documentation. Confondre les deux serait un mensonge commercial — et un risque juridique pour vous comme pour nous.

Mode divulgation nulle · aws-cli inchangé

# 1. La passerelle locale détient la clé.
kerlok-gw up --bucket patients --listen 127.0.0.1:9000

# 2. Votre outillage habituel, sur localhost.
aws s3 cp ./irm-2026-08.dcm s3://patients/ \
    --endpoint-url http://127.0.0.1:9000

# 3. Vérifiable côté client, sans nous croire.
kerlok verify s3://patients/irm-2026-08.dcm
#  racine de Merkle  9f2c41ab 7d05c318
#  journal chaîné    ok · pas de bifurcation
#  contenu serveur   opaque

Critère de recette de la compatibilité

La compatibilité S3 est une propriété testée, pas une intention : une suite de conformité automatisée s'exécute à chaque commit. Ces clients doivent fonctionner sans indicateur de contournement.

aws-clircloneTerraform VeeamSDK MinIOboto3

S3 cœur: GET par plages, multipart, URL pré-signées, SigV4
S3 étendu: Versionnage, cycle de vie, Object Lock, politiques
API native: Envoi reprenable, arbre de Merkle par plages, événements
Identité: Politiques de type IAM, OIDC/SAML, SCIM

Le chemin d'un objet

Découper, compresser, chiffrer, coder. Dans cet ordre.

L'ordre des opérations n'est pas négociable : inversé, chaque étape annule la précédente. Le chiffrement précède tout traitement serveur, ce qui interdit définitivement les optimisations serveur classiques. C'est le prix de la promesse, et nous l'assumons plutôt que de le contourner.

01 — clair Découpe FastCDC · 1 Mio moyen

02 — clair, réduit Compresse Zstandard · adaptatif

03 — chiffré Chiffre AES-256-GCM · AAD

04 — chiffré Remplit paliers de taille

05 — chiffré Code Reed-Solomon 8+4

06 — chiffré Place 12 domaines de panne

Figure 2 Les étapes 01 et 02 ont lieu sur votre appareil. Ce qui traverse la frontière à l'étape 03 est déjà opaque.

Fragments · code d'effacement 8+4

8 fragments de données, 4 de parité, ×1,5 de surcoût. Quatre pertes simultanées restent réparables ; le nettoyage continu et la réparation proactive font le reste.

Déduplication · intra-tenant uniquement

La déduplication inter-clients est incompatible avec la divulgation nulle : le chiffrement convergent permet de tester la présence d'un fichier qu'on possède déjà.

Empreinte de fragment en BLAKE3 à clé, la clé étant propre au tenant : deux clients ayant le même fichier produisent des empreintes différentes. Le gain — de 3 à 10× sur des jeux de sauvegarde — reste intégralement acquis à l'intérieur du tenant.

Modèle de menace

Contre qui, exactement.

Un système à divulgation nulle vaut exactement ce que vaut l'honnêteté de son modèle de menace. Voici les adversaires que l'architecture prend au sérieux, et ce qui leur est opposé.

Administrateur interne malveillant

Accès root aux serveurs, aux bases de métadonnées et aux disques.

Cible principale de la divulgation nulle. Aucun accès en clair possible ; aucun SSH en production, double validation, journal inaltérable.

Réquisition ou pression étatique

Contrainte légale de produire les données d'un client.

Nous produisons ce que nous détenons : des blocs chiffrés inexploitables. Structure capitalistique et gouvernance européennes.

Serveur malveillant actif

Sert d'anciennes versions, omet des objets, présente des vues divergentes à deux clients.

Journal chaîné signé par bucket, ancré périodiquement dans un journal append-only, avec détection de bifurcation côté client. C'est l'attaque réaliste contre un service à divulgation nulle, et celle qu'on oublie.

Adversaire quantique futur

Collecte aujourd'hui, déchiffre plus tard.

Hybridation X25519 + ML-KEM-768 sur tous les échanges de clés, dès la v1 : un rétrofit est impossible sur des données déjà exfiltrées.

Invariants de sécurité · non négociables

Aucun secret permettant de déchiffrer des données client ne transite jamais par nos serveurs, ni en mémoire, ni en journal, ni en trace.

Aucune action d'administration sur un système de production n'est possible sans être authentifiée, autorisée par capacité, journalisée de façon inaltérable et, pour les actions sensibles, validée par une seconde personne.

Un client peut vérifier, sans nous faire confiance, que ce qu'il relit est bien ce qu'il a écrit, et que rien n'a été omis ni ramené à une version antérieure.

Toute proposition d'architecture, toute optimisation et toute demande commerciale qui violerait un invariant est refusée. Les cinq invariants et les sept adversaires sont détaillés dans la documentation d'architecture.

Hors périmètre

Ce que la divulgation nulle ne protège pas.

Aucune de ces limites n'est réparable par de la cryptographie serveur. Les annoncer ici plutôt que dans une note de bas de page fait partie du produit.

Un appareil compromis

Si votre appareil est infecté, la clé y est en clair pendant l'usage. Aucune architecture serveur n'y change quoi que ce soit.

Un mot de passe faible

La clé dérive du mot de passe. Argon2id renchérit l'attaque, il ne l'annule pas. D'où : passphrase longue obligatoire, vérification contre les fuites connues, second facteur matériel.

Les métadonnées

Nous voyons les tailles, les horodatages, le nombre d'objets, les motifs d'accès et les adresses IP. Atténuations : remplissage par paliers, noms de chemins chiffrés, index côté client. Pas suppression.

La perte de la clé

Sans clé, les données sont perdues définitivement — par nous y compris. C'est la conséquence directe de la promesse ; le produit rend la récupération difficile à rater plutôt que de nier le problème.

Le client web est le maillon faible structurel

Sur le web, c'est nous qui livrons le code qui manipule les clés. Un opérateur malveillant — ou contraint — pourrait servir à un utilisateur ciblé une version modifiée qui exfiltre sa clé. Aucun chiffrement côté navigateur ne résout ce problème : il est situé en amont du chiffrement. Atténuations : CSP stricte sans eval, intégrité des sous-ressources, manifeste de version signé, builds reproductibles publiés avec leurs empreintes dans un journal de transparence, et extension de navigateur facultative qui vérifie l'empreinte du code servi avant exécution. Le web est le mode « pratique » ; les applications natives sont le mode « divulgation nulle vérifiable ».

Récupération

Un système sans récupération n'est pas vendable à une entreprise.

Trois mécanismes coexistent, choisis par le client, tous compatibles avec l'invariant I1 — nous ne détenons jamais de quoi remonter la chaîne.

Clé de récupération individuelle

128 bits d'entropie, présentés en mots, générés côté client, affichés une seule fois. Chiffre une seconde enveloppe de la paire maîtresse.

falaise quorum brasier verdict octogone réseau

Perte de la clé et du mot de passe et de tous les appareils = perte des données.

Séquestre à quorum

Partage de secret de Shamir k-parmi-n, distribué entre plusieurs administrateurs de votre organisation. Nous ne détenons jamais de part.

3 / 5 · seuil atteint

La reconstitution exige k administrateurs et produit une entrée dans le journal d'audit, visible de l'utilisateur concerné.

Clé d'organisation

Pour les comptes gérés : chaque clé de bucket est également chiffrée vers la clé publique de l'organisation, détenue par vous. Continuité assurée en cas de départ d'un salarié.

Annoncé de façon non ambiguë aux utilisateurs concernés — sans quoi c'est une porte dérobée déguisée.

Liaison à l'appareil

Chaque appareil génère à l'enrôlement une paire X25519 dans son matériel sécurisé — Secure Enclave, StrongBox, TPM 2.0. La clé privée n'est jamais exportable, même par un attaquant root. L'enrôlement d'un nouvel appareil exige une autorisation depuis un appareil déjà enrôlé, ou la clé de récupération : le serveur ne peut pas s'auto-enrôler.

MacBook Pro · appareil courant Secure Enclave · enrôlé le 12/08/2026 Actif

iPhone 17 Secure Enclave · biométrie Enrôlé

runner-ci-03 TPM 2.0 · clé à portée limitée Enrôlé

Souveraineté & conformité

Une trajectoire, pas une liste de logos.

La divulgation nulle réduit fortement le périmètre de conformité, mais elle ne remplace aucun contrôle organisationnel : un auditeur ne certifie pas une architecture, il certifie un système de management et des preuves. Voici où nous en sommes réellement.

Aucune certification n'est annoncée comme acquise.

Les jalons ci-dessous sont des cibles internes comptées depuis le démarrage du projet, sous réserve de vérification contre les référentiels publiés. Aucune date n'est contractuelle : les verrous les plus difficiles — actionnariat, siège, localisation des équipes, chaîne de sous-traitance — sont juridiques et organisationnels, pas techniques.

RGPD Permanent · dès M0

NIS2 En cours · visé M12

ISO/IEC 27001 Planifié · visé M18

SOC 2 type II Planifié · visé M24

HDS Planifié · visé M26

SecNumCloud Planifié · M36 – M48

Ce que l'architecture apporte déjà

RGPD art. 17: Effacement cryptographique prouvable, atomique et auditable
RGPD art. 32: Chiffrement de bout en bout, périmètre de sous-traitance réduit
Partage de resp.: Structurellement clair : vous détenez les clés, donc les données
Minimisation: Nous ne pouvons pas traiter ce que nous ne pouvons pas lire
NIS2 / chaîne: SBOM, provenance des artefacts, journal d'audit, gestion des correctifs
Data Act: API S3 standard, egress gratuit, export en masse outillé

Souveraineté opérationnelle

Données · UE Traitements · UE Administration · UE Gouvernance · UE

Le piège que nous refusons

« Nous sommes à divulgation nulle, donc conformes » est faux, et un auditeur le relève immédiatement. Le travail de conformité est à 70 % organisationnel : politiques écrites, analyse de risque tenue à jour, revues de direction, continuité testée. La cryptographie ne couvre qu'une poignée de contrôles techniques.

Pour qui

Un moteur, quatre surfaces.

Les quatre segments visés n'achètent pas le même produit. Ils partagent le moteur, pas la surface — et chacun a une exigence sans laquelle rien d'autre ne compte.

Segments visés, ce qu'ils achètent et leur exigence bloquante
Segment	Ce qu'ils achètent	Exigence bloquante	Priorité
Développeurs & startups	API S3, tarif à l'usage, self-service, egress gratuit	Compatibilité `rclone`, Terraform, SDK AWS. Si ça ne marche pas au premier essai, ils partent.	P0
PME / ETI	Remplacement de Drive ou OneDrive : sync, partage, versionnage	Clients desktop et mobile irréprochables, et récupération de compte. Sans récupération, le support est ingérable.	P1
Entreprises régulées	Conformité opposable : santé, finance, secteur public	Certifications, WORM / Object Lock, journal d'audit inaltérable, séquestre de clés à quorum.	P1
Grands comptes	Réplication multi-sites, SLA contractuel, machines dédiées	Politiques de placement explicites, isolation mono-tenant, RPO/RTO engagés, revue de sécurité fournisseur.	P2

Tarification

Trois principes. La grille suivra.

Le service n'est pas ouvert : publier une grille détaillée aujourd'hui serait un chiffre inventé. En revanche, les principes qui la produiront sont déjà arrêtés, et ils ne changeront pas.

À l'usage, sans engagement de volume

Stockage facturé au tébioctet-mois, requêtes à l'appel. Pas de palier minimum, pas de réservation obligatoire pour obtenir un tarif décent.

Aucun frais de sortie

L'egress est gratuit, en volume comme en API. Partir doit coûter le temps d'un rclone sync, pas une facture de sortie.

Le coût de la confidentialité est visible

Un bucket sensitive désactive la compression et remplit chaque fragment au palier supérieur : jusqu'à ~30 % de surcoût de stockage. C'est votre choix, et il est tarifé comme tel — pas caché dans une moyenne.

Kerlok
Divulgation
nulle

Alpha privée · développeurs d'abord.

La première étape est une alpha mono-région pour développeurs : API S3 cœur, client CLI, passerelle à divulgation nulle. Nous cherchons des utilisateurs qui casseront la compatibilité S3 avant nos clients payants.

Une seule adresse, conservée pour vous répondre et rien d'autre. Pas de traqueur sur cette page, pas de régie publicitaire, aucun tiers.

M0 – M6 · alpha privée M6 – M12 · bêta publique M12 – M24 · offre entreprise