Le problème : la confiance ne passe pas à l'échelle
Une rétractation est un acte juridiquement contraignant. Qui affirme s'être rétracté a besoin d'une preuve. Qui affirme avoir reçu une rétractation aussi. Dans la configuration classique, vous enregistrez les entrées dans votre base de données, plus un fichier journal, en espérant que personne ne prétende que vous avez modifié quelque chose.
Le problème : l'exploitant de la base de données, c'est-à-dire nous, pourrait en théorie tout éditer après coup. Un avocat qui conteste votre preuve a la tâche facile. « Comment savoir si cet enregistrement date vraiment du moment de la réception ? »
La solution en une phrase
Chaque rétractation reçoit une empreinte. À la fin de la journée, nous regroupons toutes les empreintes en un arbre. Nous publions la racine de cet arbre. Chacun peut vérifier plus tard si sa rétractation figurait bien dans l'arbre, sans accéder aux autres rétractations.
Qui ne lit pas la suite de cet article en a déjà compris l'essentiel.
L'empreinte : SHA-256
SHA-256 est une fonction de hachage cryptographique. Vous y mettez n'importe quelle quantité de texte, vous obtenez 64 caractères. Ces 64 caractères sont uniques pour ce texte. Modifiez une seule virgule et l'empreinte entière change. Il est pratiquement impossible de trouver deux textes différents produisant la même empreinte.
Chez nous, chaque rétractation est sérialisée à la réception en un bloc de texte défini : nom, contact, référence de commande, texte libre, horodatage à la milliseconde près, identifiant de la boutique. Ce bloc passe par SHA-256. Résultat : une empreinte de 64 caractères.
L'empreinte est comme la preuve d'une enveloppe scellée. Si nous montrons plus tard le contenu et que quelqu'un recalcule l'empreinte, elle doit correspondre exactement à nouveau. Si un seul caractère diffère, par exemple parce que nous avons raccourci le nom après coup, l'empreinte ne correspond plus. La manipulation devient visible.
L'arbre : arbre de Merkle
Une empreinte par rétractation, c'est bien, mais pas encore suffisant. Il faudrait publier chaque empreinte individuellement pour les rendre vérifiables. Ce serait un cauchemar pour la protection des données, car les empreintes assorties de l'information « cette empreinte se trouvait sur le serveur à l'instant X » permettraient des déductions.
Les arbres de Merkle résolvent cela élégamment. Vous prenez deux empreintes, vous les combinez et vous hachez de nouveau le résultat. Vous reprenez cette nouvelle paire d'empreintes avec la paire suivante, jusqu'à ce qu'il ne reste qu'une seule empreinte à la fin : la racine de l'arbre.
Rétractation A → hash_A ─┬───── hash_AB ─┬──────────┐
Rétractation B → hash_B ─┘ │ │
│ Racine
Rétractation C → hash_C ─┬───── hash_CD ─┘
Rétractation D → hash_D ─┘La racine n'est exactement identique que si chaque rétractation située en dessous reste inchangée. Une seule lettre modifiée dans une seule rétractation ferait basculer son empreinte, puis l'empreinte de la paire au-dessus, puis la suivante, jusqu'à la racine. La racine ne correspondrait plus.
L'analogie du notaire
Imaginez un notaire. Chaque jour à minuit, il rassemble toutes les rétractations de la journée, les inscrit dans un registre, scelle le registre et le place dans un coffre. Le lendemain matin, il affiche sur un panneau devant sa maison un code court qui ne correspond qu'à ce registre.
Si quelqu'un vient plus tard prétendre que sa rétractation figure dans le registre, le notaire peut le lui montrer : « Oui, regardez, ici page 47, ligne 12. Le code sur le panneau correspond exactement à ce registre. Si j'avais modifié quoi que ce soit, le code ne correspondrait plus, et tout le monde le verrait sur le panneau. »
Le registre, c'est la base de données. Le sceau, c'est l'empreinte SHA-256. Le panneau d'affichage, c'est notre point d'accès public. Le code, c'est la racine de Merkle.
La racine publique : /proof
Chaque jour à minuit, nous calculons l'arbre de Merkle de toutes les rétractations reçues ce jour-là. Nous inscrivons la racine dans un point d'accès public sous /proof/root/YYYY-MM-DD.
Chaque exploitant de boutique reçoit un proof_token pour chaque rétractation. C'est le chemin complet à travers l'arbre, de sa propre rétractation jusqu'à la racine. Avec ce jeton, tout tiers, un juge également, le client lui-même également, peut en vérifier l'authenticité.
GET /proof/{token}
Response 200:
{
"revocationHash": "9f86d081884c7d659a2feaa0c55ad015...",
"merkleProof": ["a3f5...", "b2e8...", "c1d4..."],
"merkleRoot": "5d41402abc4b2a76b9719d911017c592...",
"publishedAt": "2026-04-13T00:00:00Z",
"verifiable": true
}Qui veut vérifier la logique prend le revocationHash, le combine selon les règles des arbres de Merkle avec les éléments de merkleProof, et devrait obtenir au final exactement le merkleRoot. Cela se recalcule en dix lignes de code dans n'importe quel langage de programmation.
Protection des données : pourquoi cela reste conforme au RGPD
L'astuce de l'arbre de Merkle, c'est que la racine ne permet aucune déduction sur les rétractations individuelles. Nous ne publions ni les noms, ni les e-mails, ni même les empreintes individuelles. Uniquement la racine et, par rétractation, la preuve de chemin individuelle.
La preuve de chemin n'est accessible qu'à qui connaît le proof_token. Et seuls l'exploitant de la boutique, le client, et quiconque se voit remettre le jeton par l'un des deux l'obtiennent. Il n'existe aucune liste publique.
Ainsi, la construction satisfait simultanément deux exigences en apparence contradictoires : la vérifiabilité publique et la protection des données conforme au RGPD des opérations individuelles.
Pourquoi cela tient en justice
Un juge n'a pas besoin de comprendre le fonctionnement de SHA-256 pour accepter une expertise fondée sur SHA-256. La fonction est normalisée depuis 2001, utilisée dans le monde entier par les banques, les gouvernements et les blockchains, et n'a jamais été cassée sur le plan cryptographique.
L'important, c'est que la racine de Merkle ait été publiée à un moment où personne ne pouvait plus l'influencer après coup. D'où l'écriture à minuit, et d'où le stockage immuable. Qui prétend que nous avons ajouté un enregistrement après coup devrait expliquer comment nous avons simultanément modifié la racine déjà rendue publique le lendemain. Cette explication n'existe pas tant que SHA-256 n'est pas cassé.
En pratique : ce que vous voyez dans le tableau de bord
Dans le tableau de bord chaque rétractation reçoit un lien vers /proof/{token}. Vous pouvez transmettre ce lien à un avocat ou le vérifier vous-même. Dans un éventuel litige, c'est votre vérification techniquement neutre, indépendante de nous.
Et comme nous-mêmes ne pouvons pas intervenir dans l'arbre sans détruire la racine publique, nous sommes nous aussi liés par la preuve. Ce n'est pas une promesse marketing, mais une limite structurelle du système.
Pourquoi les autres prestataires n'ont pas cela
La plupart des fournisseurs de bouton de rétractation écrivent simplement l'entrée dans leur base de données et s'en remettent aux sauvegardes et à leur bonne conscience. Cela suffit jusqu'à ce que le premier litige dégénère. Vous vous retrouvez alors avec une ligne de base de données qu'un expert technique classe comme manipulable en dix secondes.
Nous avons choisi cet effort supplémentaire parce que l'obligation issue de la directive (UE) 2023/2673 (article L221-21 du Code de la consommation, applicable au 19 juin 2026) est trop récente pour s'en remettre à l'habitude. Les premières décisions de justice sont encore à venir. Quand elles viendront, vous voudrez être du côté où se trouvent les mathématiques.
Détails de la mise en œuvre dans notre guide ou sur la page produit.