Nous ouvrons un design partner program. Voir le programme

Infrastructure de données souveraine

Vos données ne devraient être nulle part.

Nulle part de lisible, nulle part de nouveau : vos données restent dans les services cloud de votre choix, mais vous en reprenez la souveraineté.

Réserver une démo Lire la documentation

Le problème

La responsabilité reste locale. L’accès, non.

Le stockage cloud tel qu’il existe aujourd’hui ne permet pas d’établir qui peut lire les données qu’il héberge. Les fournisseurs chiffrent les fichiers avec des clés qu’ils gardent de leur côté, et leurs systèmes déchiffrent à la demande : pour tout employé habilité, pour toute autorité qui l’exige. La serrure existe. Elle appartient à l’opérateur, comme le journal de ceux qui l’ont ouverte.

L’ordre n’a pas à venir du régulateur dont relèvent les données : un fournisseur dont le siège est à l’étranger répond de sa propre loi où que soient ses serveurs, et l’information vient après coup, quand elle vient. La notification, l’amende et la lettre aux clients concernés restent à la charge de l’organisation qui a collecté les données, quel que soit le détenteur des octets.

Chaque analyse se termine de la même façon : décrire un contrôle qui se trouve chez un tiers.

Lisez pourquoi chiffré au repos ne veut pas dire privé.

Des écrans de code et de données lisibles dans un open space : tout ce qu’un fournisseur ou un initié peut voir aujourd’hui

La solution

Gardez tous vos fournisseurs. Changez ce qu’ils peuvent remettre.

DataPrism est un overlay posé sur l’object storage existant. Les fichiers sont chiffrés côté client avant de quitter le périmètre, découpés en fragments, et dispersés sur des instances et des fournisseurs indépendants. Aucun fournisseur ne détient la clé, si bien qu’une demande présentée chez l’un d’eux ne produit que des fragments que personne ne peut ouvrir, et le nombre d’adresses distinctes qu’une demande devrait atteindre devient un chiffre énoncé plutôt qu’une hypothèse.

Un index scellé du fichier est ancré sur un registre public, de taille constante quelle que soit la taille du fichier : aucun contenu et rien de lisible n’y va jamais, et un auditeur peut récupérer l’enregistrement directement. Il n’y a pas de plateforme vers laquelle migrer : mêmes fournisseurs, mêmes régions, mêmes factures. Les données sont réécrites par le pipeline, dans des comptes déjà à vous.

Voyez comment le chiffrement côté client devient une preuve publique.

Des fils abstraits entrelacés : un fichier découpé en fragments, dont aucun n’a de sens seul

Toutes les échelles

Un document ou tout un parc de données. Mêmes propriétés.

Le déploiement commence là où il vaut la peine de commencer : sur tout ce qui sera écrit désormais, ou sur un périmètre existant repris une fois par le pipeline. Rien n’est à réarchitecturer à mesure que le périmètre s’élargit, et un document décisif se comporte exactement comme des millions d’enregistrements.

Le déploiement n’exige ni programme, ni cycle budgétaire, ni comité de pilotage avant que quoi que ce soit s’améliore : le périmètre le plus exposé est couvert en premier, démontré, puis étendu à partir de là. Et là où des pipelines doivent collecter des données sans pouvoir les lire, la même infrastructure peut être conçue pour l’ingestion aveugle : collecter sans exposer.

Explorer les cas d’usage →

Un vaste champ de blocs de données binaires s’étendant à perte de vue : la même protection quel que soit le volume

Trois propriétés

Illisible. Inarrêtable. Prouvable.

Trois propriétés dont vous héritez de l’architecture, sans avoir à faire confiance à qui que ce soit pour les tenir.

Illisible

Le chiffrement a lieu avant l’envoi. Personne ne peut lire vos données, nous compris. Ainsi, quand on demande qui d’autre peut lire ces données, la réponse est une architecture plutôt qu’une promesse : ni vos fournisseurs, ni nous.

Inarrêtable

Perdre un fournisseur pour une panne, une hausse de prix ou un refus de vous servir cesse d’être un scénario à anticiper : chaque fichier est fragmenté et dispersé sur des fournisseurs indépendants, avec redondance intégrée.

Prouvable

Montrez à un tiers qu’un fichier existe et n’a pas changé, sans l’ouvrir et sans que personne ait à se porter garant : l’intégrité est ancrée dans un registre public sous la forme d’une empreinte de taille constante, quelle que soit la taille du fichier.

Vous chiffrez déjà ?

Le chiffrement règle le premier problème. Pas ceux qui suivent.

Chiffrer avant l’envoi empêche le fournisseur de lire les données. C’est le plus dur, cela vaut la peine, et c’est aussi là que commence ce pipeline. C’est aussi là que s’arrêtent la plupart des architectures, ce qui laisse trois expositions ouvertes.

  1. 01

    Une copie complète reste à une seule adresse.

    Ce qui atteint cette adresse atteint le tout, en une seule opération. Des données chiffrées prises aujourd’hui peuvent être conservées indéfiniment, et une cryptographie qui tient aujourd’hui n’est pas une cryptographie qui tient toujours. La collecte de masse repose exactement sur ce principe : tout prendre, tout garder, lire plus tard.

  2. 02

    Le chiffrement n’est pas la disponibilité.

    Un compte suspendu, une panne, un changement de conditions ou une rançon emporte les données avec lui, clés ou pas. Celui qui détient chaque octet est aussi celui qui peut cesser de les rendre.

  3. 03

    La garde des clés ne se démontre pas.

    C’est une affirmation sur une configuration interne, et la seule preuve est la parole de l’opérateur. Rien n’y est vérifiable par celui qui doit valider.

La dispersion sur des fournisseurs indépendants change le nombre d’adresses distinctes qu’une opération doit atteindre, la redondance absorbe la perte de l’un d’eux, et une empreinte ancrée est vérifiable par celui qui pose la question. Le chiffrement reste la première étape. Il cesse d’être la seule.

Pourquoi maintenant

La question vous arrive de vos clients avant votre régulateur.

Les acheteurs grands comptes inscrivent désormais la souveraineté dans leurs achats, et la réponse qu’ils attendent n’est pas une promesse sur qui détient les octets. Questionnaires, audits, analyses d’impact des transferts : tous posent la même chose avec d’autres mots, et l’essentiel des heures part à redire ce que vous ne pouvez pas démontrer. Les sanctions sont passées de la théorie à la pratique, et la responsabilité reste la vôtre, quel que soit celui qui détenait les octets. Le même règlement nomme la sortie : quand les données exposées sont inintelligibles, une violation cesse d’être une lettre à chacun de vos clients. L’infrastructure de données souveraine est la réponse vers laquelle convergent les obligations, et ce qui manque est une architecture qui la produit sur les clouds que vous exploitez déjà.

485 M€

déjà prononcés, pour avoir atteint des données européennes depuis l’extérieur de l’UE. Six mois pour corriger, sinon les transferts s’arrêtent. L’endroit où étaient les serveurs n’était pas la question

Art. 34

pas d’obligation d’informer chaque personne concernée lorsque les données exposées étaient inintelligibles. La notification au régulateur, elle, demeure

Cas d’usage

Trois façons dont cela atterrit sur votre bureau. Une seule chose à régler.

Obligations différentes, équipes différentes, périmètres différents. Dans chacun, le travail que vous cessez de faire est le même : argumenter que vos données sont protégées, au lieu de le montrer.

Explorez les cas d’usage de la protection des données sensibles

Développeurs

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

Installez le SDK, pointez-le vers les fournisseurs que vous payez déjà, livrez : rien au-dessus ni en dessous n’a à changer.

Lire la documentation La page développeurs montre le code 
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 });
await pipeline.upload("contract.pdf", bytes, {
  chunkSize: 65_536,
  dataShards: 7,
  parityShards: 3,
});

Prouvé, pas promis

Laissez vos auditeurs vérifier, dès le premier jour.

Chiffré, fragmenté, dispersé : rien de tout cela ne demande votre confiance, ni la nôtre. Les modèles de fiabilité ci-dessous montrent ce que l’architecture garantit, et le registre qui l’applique est public : un auditeur peut le parcourir sans un appel avec nos ingénieurs ni une clause dans votre contrat. La différence avec tous les fournisseurs sur lesquels vous vous êtes appuyé jusqu’ici : cette fois, c’est vous qui tenez les clés.

Lire la documentation

Chiffrement côté client

Ce qui sort de chez vous est déjà illisible, où que cela atterrisse.

Aucun nouveau verrouillage fournisseur

Vos fournisseurs restent les vôtres, remplaçables, et sous vos contrats.

Un seul SDK à intégrer

Un SDK TypeScript, aucune cryptographie à réussir pour votre équipe.

Ouvert par conception

Docs publiques, code vérifiable, recherche encore à venir.

Commencer

Ayez la réponse prête avant la prochaine revue.

Apportez un stockage souverain, illisible, inarrêtable et prouvable aux buckets que vous avez déjà, sans changer un seul fournisseur. Nous le projetterons sur votre architecture avec vous.

Réserver une démo Échanger avec nous

30 minutes. Votre système ou votre questionnaire, sans slides.