L'effacement attesté — comment ça marche

1. Vous déclarez votre périmètre

Vous nommez vos tables, et dans chacune les champs qui identifient une personne. Votre déclaration est signée et horodatée. C'est exactement ce que l'attestation couvrira — ni plus, ni moins.

2. Vos exports passent par la bibliothèque

Les champs déclarés sont chiffrés par une clé qui n'existe nulle part en entier : une moitié chez vous, une moitié vivante chez Seal. Le reste de la ligne demeure lisible — les montants balancent encore.

3. Vous effacez, et vous recevez une attestation

Seal détruit sa moitié. La personne cesse d'être lisible partout à la fois, y compris dans les fichiers déjà partis et les sauvegardes où vous ne pouvez plus écrire. Vous recevez une référence en douze caractères.

N'importe qui peut vérifier

La personne concernée dicte sa référence à une autorité, qui l'ouvre sans compte, sans contrat et sans nous demander la permission. Une attestation vérifiable seulement par nos clients ne vaudrait rien.

Étape 1 — Déclarez votre périmètre

Ouvrez « Effacement » dans le menu de gauche, puis « Signer ma déclaration ». Écrivez une ligne par table : le nom de la table, deux points, puis les champs qui identifient une personne, séparés par des virgules. Signez. Rien ne fonctionne avant cette étape, et ce que vous déclarez ici est exactement ce que l'attestation couvrira.

Étape 2 — Engendrez votre moitié de clé

Elle ne quitte jamais vos systèmes et Seal ne la verra jamais. Engendrez 32 octets au hasard, conservez-les dans votre coffre ou dans une variable d'environnement, et jamais dans votre dépôt de code. La perdre rend vos exports illisibles pour toujours, y compris pour les personnes n'ayant rien demandé.

node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"
# -> a place dans SEAL_PART_LOCALE, dans ton coffre. Jamais dans le depot.

Étape 3 — Copiez la bibliothèque dans votre projet

Le dossier « client-effacement » n'a aucune dépendance et n'utilise que WebCrypto. Node 18 ou plus récent, ou un navigateur. Il s'exécute chez vous, jamais chez nous.

cp -r client-effacement/ mon-projet/
# puis, dans ton code :
import { Enveloppe } from "./client-effacement/index.mjs";

Étape 4 — Réglez les quatre valeurs

Votre identifiant d'organisation et votre jeton sont dans le portail; la référence du périmètre s'affiche sur l'écran de l'étape 1. Les champs protégés doivent correspondre exactement à ceux que vous avez déclarés : un champ chiffré mais non déclaré ne serait couvert par aucune attestation.

const env = new Enveloppe({
  orgId:          process.env.SEAL_ORG,          // etape 4 — le portail
  jeton:          process.env.SEAL_JETON,        // etape 4 — le portail
  perimetre:      process.env.SEAL_PERIMETRE,    // etape 1 — l'ecran du perimetre
  partLocale:     process.env.SEAL_PART_LOCALE,  // etape 2 — ne sort jamais
  epoque:         1,
  champsProteges: ["nom", "courriel", "telephone"],
  seal:           "https://seal.lifaio.com",
});

Étape 5 — Enveloppez un export

Passez vos lignes à la bibliothèque. Les champs déclarés en ressortent chiffrés, le reste demeure lisible. La fonction que vous fournissez doit rendre votre référence interne de la personne — jamais un nom ni un courriel : Seal ne doit voir aucun identifiant reconnaissable.

const lignes  = await db.query("SELECT * FROM factures");
const fichier = await env.envelopper(lignes, (l) => l.client_id);
fs.writeFileSync("export-2026-09.seal", fichier);

Étape 6 — Ouvrez un export, en ne demandant que ce que vous cherchez

Ne demandez que les personnes dont vous avez besoin. Ce n'est pas une optimisation, c'est le mécanisme de détection : un usage légitime cherche quelqu'un de précis, un voleur déchiffre tout et touche les leurres. Une personne déjà effacée rend un marqueur, pas une erreur, pour que le reste du fichier demeure exploitable.

const { lignes } = await env.ouvrir(fichier, ["CLI-4471"]);
// une personne effacee rend { efface: true } — pas une erreur.

Étape 7 — Effacez, et remettez la référence

Sur l'écran « Effacement », entrez la référence interne de la personne et confirmez. C'est irréversible. Vous recevez une référence d'attestation en douze caractères : remettez-la à la personne concernée. Elle pourra la faire vérifier par une autorité sur une page publique, sans compte et sans nous demander la permission.

Ce que la personne concernée peut faire avec sa référence

Elle la dicte à qui elle veut — une autorité, un avocat, elle-même. La page s'ouvre sans compte et sans contrat, et affiche l'attestation avec sa portée et ses limites écrites dessus.

Quand la personne revient

Une personne effacée peut redevenir cliente. Voici le mécanisme exact, et il est prévu.

La destruction est définitive pour la référence et l'époque visées : la graine passe à NULL, et aucune route ni aucun bouton d'administration ne peut la ressusciter.

Les enveloppes sont rangées par organisation, référence et ÉPOQUE. En passant à l'époque suivante, une graine neuve est créée : le nouveau dossier fonctionne, et les anciennes données restent illisibles pour toujours.

// LE RETOUR. On passe a l'epoque suivante ; rien d'autre ne change.
const env2 = new Enveloppe({ ...memesReglages, epoque: 2 });

// CLI-1 en epoque 1  -> detruite pour toujours
// CLI-1 en epoque 2  -> graine neuve, le nouveau dossier fonctionne
//
// RECOMMANDE : donner une reference neuve plutot que reutiliser l'ancienne.
const env2b = new Enveloppe({ ...memesReglages, epoque: 2 });
await env2b.envelopper(lignes, (l) => l.id);   // l.id = 'CLI-8891'

Nous recommandons d'attribuer une nouvelle référence interne plutôt que de réutiliser l'ancienne : votre attestation continue ainsi de désigner sans ambiguïté ce qui a été détruit.

Ce que vous perdez, et c'est voulu : vous ne pouvez plus reconnaître qu'un dossier effacé était la même personne. Un identifiant qui survivrait à l'effacement ne serait pas un effacement.

Les contraintes d'unicité de votre base

Un index unique sur un champ identifiant ne provoque pas de collision : après enveloppage, ce champ vaut NULL ou du texte chiffré, jamais la valeur en clair. SQLite, PostgreSQL et MySQL acceptent plusieurs NULL dans un index unique.

Installer à côté de la base, sans changer vos colonnes

Vous n'êtes pas obligé de modifier vos colonnes existantes. Mettez à NULL les champs déclarés dans votre table d'origine et rangez le bloc chiffré dans une table séparée, indexée par référence et par époque. Aucune migration de type, et vos index existants tiennent.

-- LA TABLE A COTE. Aucune colonne existante n'est modifiee.
CREATE TABLE clients_enveloppes (
  sujet_ref TEXT NOT NULL,
  epoque    INTEGER NOT NULL,
  p         TEXT NOT NULL,          -- le bloc chiffre
  PRIMARY KEY (sujet_ref, epoque)
);

-- L'enveloppage met a NULL les champs declares, et rien d'autre.
UPDATE clients SET nom = NULL, courriel = NULL WHERE id = 'CLI-1';
-- vos index UNIQUE tiennent : plusieurs NULL sont acceptes.

Pourquoi la clé se calcule chez vous

Pour lire une donnée, il faut qu'elle existe en mémoire à un instant — chez vous, qui la détenez légitimement. Si Seal calculait à votre place, il recevrait le texte chiffré et la clé complète : il détiendrait la donnée et ne pourrait plus dire qu'il n'y a pas accès. La clé est non extractible et n'est écrite nulle part.