Nous ouvrons un design partner program. Voir le programme

DÉVELOPPEURS

Livrez du stockage souverain par architecture. Sans écrire une ligne de cryptographie.

Un seul SDK de chiffrement côté client, en TypeScript : installez-le, pointez-le vers l’object storage que vous exploitez déjà, livrez. Le chiffrement, la dispersion et l’ancrage public se produisent derrière une API propre : rien de tout cela n’est du code que vous écrivez, possédez ou défendez en revue de sécurité. Vos utilisateurs ne voient que des fichiers.

Lire la documentation Voir les exemples

DÉMARRAGE RAPIDE

Installer, pointer, livrer.

Initialisez un client, créez un projet, envoyez un fichier, relisez-le. Tout ce qui se trouve sous la ligne de l’API, dérivation de clé, découpage, redondance, ancrage, est du code que vous n’écrivez, ne testez et ne maintenez jamais. Et quand votre revue de sécurité demandera ce qu’il y a réellement dans ces appels, la section suivante est la réponse.

import { readFile } from "node:fs/promises";

import { DataPrismKey, DEFAULT_ENCRYPTION } from "@dataprism/sdk/crypto";
import { CloudStandard } from "@dataprism/sdk/standard";
import { FilePipeline } from "@dataprism/sdk/files";

// Client, providers, project and key secret, one config file in your project:
// docs.dataprism.co/sdk/client
import { client, providers, project, secret } from "./dataprism";

// Create a project: an encrypted namespace you control
const key = DataPrismKey.fromSecret(secret, DEFAULT_ENCRYPTION);
const standard = new CloudStandard(key);
const { cloudId } = await client.prism(standard).create(project);

// Upload: encrypted on this machine, dispersed with redundancy,
// integrity anchored on a public registry
const bytes = await readFile("contract.pdf");
const pipeline = new FilePipeline({
  standard,
  execution: client.execution,
  cloudId,
  providers,
});
const { index } = await pipeline.upload("contract.pdf", bytes, {
  chunkSize: 65_536,
  dataShards: 7,
  parityShards: 3,
});

// Download: shards fetched in parallel, reconstructed from any
// quorum, decrypted locally
const restored = await pipeline.download(index);

SOUS LE CAPOT

Quatre étapes. Aucune magie.

Avant de livrer une couche de chiffrement, quelqu’un de votre côté demandera exactement ce qui quitte la machine, et ce qui se passe quand un fournisseur tombe. Voici le pipeline derrière upload(), étape par étape, avec un lien vers la page de documentation qui porte le détail complet de chacune. De quoi répondre à cette revue sans lire notre source.

  1. 01. DÉCOUPAGE

    Découpage défini par le contenu

    Modifiez un gros fichier et renvoyez-le : seules les parties qui ont réellement changé repartent. Les fichiers sont coupés aux frontières naturelles du contenu, pas à des décalages fixes, si bien qu’une insertion ne redécoupe pas tout ce qui suit. Vous obtenez des renvois de la taille du delta sans maintenir votre propre format de diff.

    Le découpage, dans la documentation du pipeline de fichiers
  2. 02. CHIFFREMENT

    Chiffrement convergent, sur votre machine

    Chaque bloc est chiffré sur votre machine avant que quoi que ce soit n’en sorte : aucun service de clés à monter, rien à mettre sous séquestre. La dérivation est déterministe, donc un contenu inchangé est reconnu comme déjà stocké : un renvoi ne déplace que ce qui a réellement changé, et un contenu identique occupe votre stockage une seule fois, et non une fois par copie.

    Le chiffrement convergent, dans la documentation du pipeline de fichiers
  3. 03. DISPERSION

    Redondance chez des fournisseurs indépendants

    Les blocs chiffrés sont étendus avec la redondance que vous choisissez et dispersés chez les fournisseurs indépendants que vous avez configurés : la panne d’un fournisseur, ou un fournisseur qui coupe votre compte, reste un non-événement jusqu’à cette redondance. Aucun chemin de bascule à écrire, à répéter et à tenir à jour.

    La redondance, dans la documentation du pipeline de fichiers
  4. 04. ANCRAGE

    Un index scellé, ancré sur un registre public

    Ce qui est ancré est un index chiffré de taille constante, quelle que soit la taille du fichier, et son intégrité ne repose sur aucun opérateur, nous compris : les lectures reconstituent vos données à partir de n’importe quel quorum de fragments et déchiffrent localement. Montrer qu’un fichier n’a pas été altéré devient alors une vérification que celui qui demande exécute, pas un point d’accès que vous devez construire et maintenir.

    Prisms et ancrage, dans la documentation
UN CYCLE DE VIE DE LA SUPPRESSION QUE VOUS POUVEZ MONTRER

Effacé veut dire énuméré, puis effacé

Quand un client ou un régulateur demande si effacé veut vraiment dire effacé, vous pouvez pointer un cycle de vie documenté plutôt qu’une case à cocher dans un tableau de bord : la suppression est spécifiée dans la référence du SDK pour énumérer chaque fragment qu’un fichier a laissé derrière lui, retirer chacun d’eux chez son fournisseur, et signaler tout ce qui a échoué, fournisseur par fournisseur. C’est un travail de réconciliation que vous n’avez ni à écrire ni à porter.

Le cycle de vie de la suppression, dans la référence du SDK

COMMENT LE SDK RAISONNE

Un seul SDK de chiffrement côté client, trois garanties.

LES CLÉS RESTENT CHEZ VOUS

Tout ce qui sort est du texte chiffré

Les clés de bloc sont dérivées du contenu lui-même, ce qui rend le renvoi de données inchangées peu coûteux. L’index qui les assemble est scellé avec une clé dérivée d’un secret que vous contrôlez, et aucune des deux ne nous est jamais transmise : tout ce que le SDK envoie est déjà chiffré. Ajouter un fournisseur n’élargit jamais ce que quiconque peut lire.

Ce que chaque acteur peut voir et ne peut pas voir est exposé dans notre architecture de sécurité vérifiable.

INVISIBLE POUR LES UTILISATEURS

Aucune cryptographie exposée aux utilisateurs finaux

Aucune plomberie cryptographique n’est jamais exposée à vos utilisateurs. Les clés et l’exécution restent derrière l’authentification et l’interface de votre propre produit : aucune nouvelle étape dans votre onboarding et rien de plus à traiter pour votre support. Pour eux, c’est juste du stockage qui se trouve être illisible pour tous les autres.

DOCUMENTÉ DE BOUT EN BOUT

Une documentation complète et publique

Chaque couche est documentée à découvert sur docs.dataprism.co : la référence du SDK, le pipeline de fichiers, les contrats, des exemples Node.js et Next.js exécutables. Si vous savez lire un README, vous pouvez nous évaluer avant même de parler à un commercial.

CIBLES D’INTÉGRATION

Pointez-le vers le stockage que vous exploitez déjà.

Aucun nouveau fournisseur de stockage à intégrer, aucune migration d’infrastructure, aucun protocole à apprendre : où que les fragments atterrissent, le pipeline derrière le SDK reste le même. Ajouter ou retirer un fournisseur est un changement de configuration, pas un projet.

  • AWS S3

    Les buckets que vous exploitez déjà deviennent des cibles de dispersion pour des fragments chiffrés.

  • CLOUDFLARE R2

    Un fournisseur indépendant qui élargit l’ensemble de dispersion.

  • SCALEWAY

    De l’object storage européen comme cible de dispersion indépendante.

  • ON-PREM

    L’object storage que vous exploitez vous-même rejoint le même ensemble.

Commencez par la documentation.

Cette page montre la forme du système. La documentation descend jusqu’en bas : la référence complète du SDK, les rouages du pipeline, et des exemples Node.js et Next.js exécutables.

Lire la référence du SDK Parler à un ingénieur