Le journal d'audit de returnEasier est un registre en ajout seul de tout ce qui se passe avec vos demandes : chaque fois qu'une demande est créée, approuvée, marquée comme reçue ou remboursée, une nouvelle ligne y est ajoutée, et l'application n'offre aucun moyen de la modifier ni de la supprimer. Chaque événement est scellé par un hachage SHA-256 chaîné avec le précédent, que vous pouvez comparer à ceux de vos exportations antérieures ; le PDF d'accusé de réception porte en outre le hachage de sa demande. Quand vous devez fournir des preuves — à un auditeur, à l'administration ou à votre conseiller — vous allez dans Conformité → Exporter l'audit et téléchargez un ZIP contenant tout l'historique et un fichier d'intégrité pour le vérifier.
Pourquoi le registre est-il en ajout seul ?
La table des événements est en ajout seul : on ne fait qu'y ajouter des lignes. Par la voie normale de l'application, un déclencheur PostgreSQL rejette les UPDATE et DELETE sur celle-ci, et l'application n'offre aucun moyen de modifier ni de supprimer un événement.
Sur cette base se construit la chaîne de hachages :
- Le contenu de chaque événement (
payload) est converti en un JSON canonique (clés ordonnées, sans ambiguïté) et on lui calcule un SHA-256. - Ce hachage est calculé en incluant le hachage de l'événement précédent (
hash_anterior). Le premier événement de chaque chaîne est le « génésis ». - Si quelqu'un modifiait une seule donnée du contenu (
payload) d'un événement passé, son hachage changerait et ne concorderait plus avec lehash_anteriorde l'événement suivant : une modification isolée du contenu rompt la chaîne. La date de chaque événement est enregistrée à part et ne fait pas partie du hachage. Pour confronter l'historique à une réécriture complète, conservez vos exportations antérieures.
Les demandes (return_requests) portent aussi leur propre hachage et hachage précédent, inclus dans l'exportation afin de pouvoir être vérifiés hors de l'application.
Comment exporter mon historique vérifiable ?
L'exportation se trouve dans Conformité → Exporter l'audit (chemin /app/settings/compliance/export) au sein de l'application, dans l'Admin Shopify.
- Ouvrez Conformité dans le menu latéral ; l'exportation est le bloc Exporter l'audit.
- Indiquez une plage de dates : « du » et « au » (au format date). Vous pouvez laisser les deux vides pour exporter tout votre historique. Les dates sont interprétées dans le fuseau horaire de votre boutique (par défaut Europe/Madrid).
- Cliquez sur Générer l'export. Selon le nombre de demandes de la plage, returnEasier fait l'une de deux choses (voir plus bas).
Téléchargement sur le moment ou par email, selon le volume
returnEasier génère le ZIP dans les deux cas ; ce qui change avec le volume, c'est s'il vous l'envoie en plus par email :
| Demandes dans la plage | Ce qui se passe |
|---|---|
| 1 – 100 | Le ZIP est généré et vous avez le lien de téléchargement à l'écran. |
| 101 – 1200 | Il est généré de la même façon : vous avez le lien de téléchargement à l'écran et, en plus, nous vous l'envoyons par email (si votre boutique n'a pas d'adresse email dans Shopify, seulement à l'écran). |
| Plus de 1200 | L'exportation est refusée : restreignez la plage de dates. |
Dans les deux cas, le lien expire au bout de 7 jours. S'il n'y a aucune demande dans la plage, l'application vous le signale et ne génère rien.
La limite stricte est de 1200 demandes par exportation. Si votre historique est plus important, divisez-le en plusieurs plages de dates (par exemple, trimestre par trimestre) et exportez chacune.
Une fois l'exportation terminée, l'écran vous montre le décompte des demandes, des événements et des PDF, si la chaîne d'événements est « Vérifiée » et combien de PDF n'étaient pas disponibles. Sur la même page, vous pouvez générer le DPA.
Que contient le ZIP ?
Le fichier s'appelle returneasier-auditoria-<votre-boutique>-<date>.zip et contient :
LISEZMOI.txt— guide en langage clair : ce qu'est chaque fichier et comment vérifier l'intégrité.solicitudes.csv— une ligne par demande, avec des colonnes commepublic_id,tipo,estado,creada_en_utc,resuelta_en_utc,pedido,cliente_email,cliente_nombre,importe,moneda,motivo,resolucion_preferida,notas_cliente,hash,hash_anterioretrefund_id.eventos.csv— le registre complet en ajout seul :public_id,return_request_id,evento,actor,actor_id,fecha_utc,hash,hash_anterioretpayload_json.pdfs/— les PDF d'accusé de réception de chaque rétractation, un par demande.INTEGRITY.json— le fichier d'intégrité : algorithme (SHA-256), décomptes, le hachage de chaque fichier du ZIP et la vérification de chaque chaîne d'événements.
Comment vérifier l'intégrité de l'exportation ?
Le INTEGRITY.json est la pièce maîtresse pour vérifier que les fichiers du ZIP n'ont pas changé depuis la génération de l'exportation —à condition de le comparer à une copie du manifeste conservée à part, car il voyage sans signature dans le même ZIP—, et il contient le résultat du recalcul de la chaîne d'événements de chaque demande :
- Il apporte le hachage SHA-256 de chaque fichier du ZIP. Recalculez le hachage de, par exemple,
eventos.csvavec n'importe quel outil standard et comparez-le à celui qui y figure. - Il inclut la vérification de chaque chaîne d'événements : pour chaque demande, il indique si sa chaîne est
okoubroken(à l'écran de l'application : « Vérifiée » ou « N chaîne(s) avec des problèmes ») et, le cas échéant, le motif (chaîne bifurquée, cycle, hachage qui ne se recompose pas…). - Si un PDF n'a pas pu être récupéré (par exemple, parce qu'il a été supprimé suite à une demande RGPD, ou parce que l'accusé de réception d'une rétractation n'a jamais été généré), cela est noté dans la liste des PDF non disponibles avec son motif, au lieu de faire échouer toute l'exportation.
Le INTEGRITY.json lui-même ne peut pas contenir son propre hachage : c'est donc le seul fichier qui ne s'auto-vérifie pas ; tout le reste, si.
Lien avec d'autres fonctions
Le journal d'audit est la base des modèles légaux et du PDF d'accusé de réception (voir « Que contient le PDF d'accusé de réception de la rétractation ? ») : chaque confirmation de rétractation envoyée au client est ancrée à la chaîne de hachages. Pour comprendre quels emails génèrent ces événements, consultez « Quels emails envoie returnEasier et à qui ? ». Et avant de désinstaller ou d'annuler, il convient d'exporter l'historique : c'est expliqué dans « Que deviennent mes données si je désinstalle ou annule returnEasier ? ».