Si votre responsable conformité entend "blockchain" et imagine des données clients dans un registre public à jamais, ce n'est pas de la paranoïa — c'est la réponse à une décennie de cadrage crypto-grand-public. Mais ce n'est pas ainsi que fonctionne l'ancrage d'enregistrements durables, et la différence compte pour HIPAA, RGPD et tout régulateur soucieux de la résidence des données. Cet article parcourt exactement ce qui est écrit sur Polygon, ce qui ne l'est pas, et pourquoi l'architecture est compatible avec les régimes de confidentialité les plus stricts.
Ce que les gens pensent qu'il se passe
Le modèle mental avec lequel arrive la plupart des évaluateurs est quelque chose comme : "le fournisseur prend une copie de chaque enregistrement, l'écrit sur une blockchain publique, et maintenant n'importe qui avec un explorateur de blocs peut le lire". C'est le modèle qui vient des cryptomonnaies, où les détails de transaction — émetteur, destinataire, montant — sont vraiment publics.
C'est aussi le modèle derrière chaque objection "nous ne mettrons pas de PHI sur une blockchain" dans les pipelines santé et chaque objection de résidence RGPD dans les pipelines européens. Les deux objections sont correctes sous ce modèle mental. La solution n'est pas de discuter avec l'objection. La solution est de remplacer le modèle mental par ce qui se passe vraiment.
Ce qui va réellement on-chain
Pour chaque lot d'enregistrements accumulés, exactement une chose est écrite sur Polygon : une racine Merkle de 32 octets. C'est un condensé cryptographique de longueur fixe calculé sur les hachages des enregistrements du lot. Ce ne sont pas les enregistrements, ni leurs identifiants, ni leurs métadonnées, ni un pointeur réversible vers les enregistrements. C'est mathématiquement à sens unique.
- Les enregistrements, en entier, ne quittent jamais votre environnement. Les déploiements auto-hébergés ancrent depuis l'intérieur de votre VPC ; les déploiements gérés ancrent depuis un namespace single-tenant qui vous est dédié. Les enregistrements eux-mêmes restent dans la base de données que vous contrôlez déjà.
- L'ancre on-chain ne contient aucun contenu d'enregistrement, aucun identifiant d'enregistrement, aucun identifiant de tenant, aucun nom de champ, aucun schéma. Seulement la racine Merkle et les métadonnées de lot nécessaires à la vérification (horodatage, taille du lot, adresse du contrat).
- Le chemin de vérification s'exécute en sens inverse. Pour prouver qu'un enregistrement a été ancré, vous fournissez l'enregistrement, la plateforme recalcule son hash et le chemin Merkle, et la racine on-chain confirme l'inclusion. La preuve fonctionne dans une direction ; vous ne pouvez pas partir de la chaîne pour reconstruire les enregistrements.
Pourquoi cela compte pour le RGPD et HIPAA
Les deux réglementations se soucient d'une question spécifique : les données que vous traitez sont-elles identifiables ? Un hash de 32 octets d'un lot d'enregistrements n'est pas identifiable. Vous ne pouvez pas en dériver les enregistrements. Vous ne pouvez pas en dériver même l'identifiant d'un seul enregistrement. Selon les directives du Comité européen de la protection des données sur le hachage, un hash qui ne permet pas la ré-identification n'est généralement pas une donnée personnelle — et même traité de façon conservatrice, l'artefact on-chain dans la conception de Certyo ne contient pas de hash par enregistrement, seulement la racine par lot.
Les normes de dé-identification HIPAA sont plus strictes, mais elles s'appliquent aux ensembles de données qui pourraient être liés à un individu. La racine Merkle on-chain ne peut être liée à un enregistrement sans accès à l'enregistrement complet, qui vit dans votre environnement sous vos contrôles d'accès. Si le régulateur peut voir la chaîne et que vous supprimez l'enregistrement, l'enregistrement est parti. L'ancre prouve qu'un enregistrement a existé à un moment précis ; elle ne préserve pas l'enregistrement.
À quoi ressemble le droit à l'effacement en pratique
L'article 17 du RGPD accorde aux individus le droit de faire effacer leurs données personnelles. La crainte avec les architectures à chaîne publique est qu'un registre immuable entre en conflit avec ce droit. Dans l'architecture de Certyo, le conflit n'existe pas, parce qu'aucune donnée personnelle n'est ancrée. Le flux ressemble à ceci :
Après l'effacement, la racine on-chain prouve toujours qu'un lot a existé à l'horodatage ancré, mais elle ne peut pas être utilisée pour reconstruire, identifier ou récupérer l'enregistrement supprimé. L'ancre demeure comme un fait historique sur l'existence d'un lot ; l'enregistrement lui-même est parti. C'est la raison architecturale pour laquelle la conception est compatible avec les régimes de droit à l'effacement où d'autres produits basés sur la blockchain échouent.
Comment cela change trois conversations d'acheteur spécifiques
Si l'architecture est unidirectionnelle et par lot, trois catégories d'objections qui bloquaient historiquement les transactions deviennent résolubles :
- Santé et PHI — Le PHI ne touche jamais la chaîne. L'artefact on-chain est un hash de 32 octets d'un lot de hashes — aucun champ, aucun enregistrement, aucun identifiant patient n'est récupérable. Les environnements alignés HIPAA peuvent ancrer sans changer leur posture de traitement de données.
- Charges de travail UE et réglementées RGPD — Les enregistrements restent dans la résidence que vous avez configurée. L'ancre on-chain est globale mais ne contient aucune donnée personnelle. L'effacement supprime les enregistrements de votre environnement sans laisser de trace dérivable on-chain.
- Défense, secteur public et opérations air-gapped — Les déploiements auto-hébergés ancrent depuis l'intérieur de votre frontière de confiance. La seule chose qui franchit la frontière est la racine Merkle — une valeur qui n'a aucune signification opérationnelle sans les enregistrements.
Le choix architectural que cela reflète
La raison pour laquelle les systèmes concurrents mettent plus on-chain est généralement qu'ils utilisent la chaîne comme base de données. Certyo non. La chaîne est l'ancre ; votre base de données existante est le système d'enregistrement. Cette séparation n'est pas un contournement — c'est ce qui rend la conception compatible avec le droit de la confidentialité en premier lieu. Pour les topologies de déploiement et les garanties d'isolation de tenant, voir /fr/about. Pour l'API de vérification, voir le portail développeur.
La chaîne prouve qu'un enregistrement a existé à un moment dans le temps. L'enregistrement lui-même reste dans votre environnement, sous vos contrôles d'accès, soumis à votre politique d'effacement. Cette séparation est tout l'objet de la conception.