Export Consentr : vérification indépendante d'un échantillon

Ce que nous avons vérifié

L'échantillon public consentr-export-v1 exporté le 2026-10-04T06:43:49Z, et son CSV, conservés pour reproduire cette vérification.

Source : échantillon JSON de Consentr.

Cette note porte sur cet échantillon daté, pas sur tous les exports de Consentr.

Comment

Nous avons écrit nos propres scripts Python, sans lire le vérificateur de Consentr, à partir des règles documentées dans l'export. Les scripts et l'échantillon sont publiés avec la note.

Résultat

• Première passe : 27 contrôles réussis, aucun échec. Empreintes du contenu, des payloads et des événements recalculées ; chaînage vérifié ; horodatages de signature comparés ; CSV comparé au JSON.
• Passe stricte complémentaire : 9 contrôles réussis, aucun échec. Normalisation des e-mails et signatures vérifiée ; deux modifications de l'échantillon détectées.

Les passes se recoupent : 36 contrôles exécutés, pas 36 garanties distinctes.

Ce que cela établit

Un tiers peut recalculer les empreintes et vérifier la cohérence interne de cet échantillon sans utiliser le vérificateur de Consentr. Les deux modifications testées sont détectées lorsque les empreintes sont conservées.

Ce que cela ne prouve pas

• Que le dépositaire n'a pas réécrit toute la chaîne puis recalculé toutes ses empreintes. Aucun ancrage externe quotidien n'est couvert par cette vérification. La publication quotidienne du dernier event_hash ou un horodatage RFC 3161 restent des évolutions envisagées, non livrées.
• La règle des empreintes de trace salées : ip_hash, user_agent_hash et trace_hash valent « exemple » dans cet échantillon. La règle n'y est donc pas observable.
• L'identité des signataires, leur liberté de consentir, ni la conformité RGPD d'un usage donné. Le RGPD, article 7(1), impose de pouvoir démontrer le consentement ; ce contrôle d'intégrité ne suffit pas à le démontrer.