Ce que signifie la vérification
La vérification est volontairement simple et déterministe : elle contrôle si la preuve est identique octet pour octet à l’enregistrement capturé d’origine, et si les ancrages temporels cryptographiques sont toujours valides. Elle ne juge pas la véracité ni qui a raison — elle vérifie l’ intégrité.
En interne, chaque preuve GPA est ancrée dans quatre couches d’intégrité indépendantes — empreintes de fichiers, une chaîne d’empreintes en ajout seul, un ancrage Bitcoin OpenTimestamps, et un horodatage qualifié eIDAS. La vérification les contrôle. Falsifier l’une d’elles — même reformater un espace JSON — fait échouer le contrôle.
Méthode 1 — Vérifier un Proof ID (en ligne)
Un Proof ID est un identifiant permanent d’un enregistrement capturé. Quiconque dispose du Proof ID (ou du lien de preuve) peut le vérifier en ligne via le vérificateur public — sans compte, sans installation, sans configuration.
- Ouvrez la page du vérificateur.
- Collez le Proof ID, ou ouvrez directement le lien de preuve.
- Examinez le résultat — artefacts capturés plus statut d’intégrité des quatre couches.
Le vérificateur affiche les artefacts capturés côte à côte avec leur statut d’intégrité :
- la capture d’écran capturée, le texte extrait et l’URL source/finale
- l’horodatage de capture et les empreintes de contenu (SHA-256)
- le statut de l’ancrage Bitcoin (bloc ancré + transaction, si confirmé)
- le statut de l’horodatage qualifié eIDAS (nom de la TSA, heure, validité de la signature)
Utilisez le vérificateur public pour contrôler un Proof ID, ou téléversez un ZIP de preuve pour une vérification multicouche complète.
Méthode 2 — Vérifier un ZIP de preuve
La vérification du ZIP est conçue pour le partage et l’archivage à long terme. Elle peut être effectuée de deux façons : en ligne via le vérificateur (téléversement direct, rapport instantané) ou entièrement hors ligne en utilisant le README bilingue à l’intérieur du ZIP et des outils open source standard.
En ligne — téléversement direct
Si vous avez un accès à internet et voulez simplement une réponse rapide, le vérificateur gère l’ensemble du processus pour vous :
- Ouvrez la page du vérificateur.
- Déposez le ZIP de preuve sur la zone de téléversement (pas besoin de l’extraire).
- Obtenez un rapport par couche — intégrité des fichiers, chaîne d’empreintes, horodatage eIDAS, ancrage Bitcoin — chacun marqué RÉUSSI ou ÉCHEC.
Hors ligne — sans GPA, sans internet, sans compte
Chaque dépendance externe dont la vérification a besoin est incluse dans le ZIP lui-même : le manifeste, les entrées de chaîne d’empreintes, le reçu Bitcoin OpenTimestamps, la chaîne complète de certificats de la TSA qualifiée, et un instantané figé de l’EU Trusted List. Le README.md bilingue (anglais + tchèque) à l’intérieur du ZIP est la référence canonique pour la vérification hors ligne. Vous avez deux options :
Une seule commande exécute les quatre couches hors ligne plus trois contrôles structurels supplémentaires (structure du reçu OTS, liaison du certificat feuille TLS, liaison des actifs eIDAS). En pur Python, sans aucun serveur GetProofAnchor.
Installez-le une fois avec pip, puis pointez-le vers n’importe quel ZIP de preuve. Code de sortie 0 = toutes les couches ont réussi ; non nul avec une ventilation par couche sinon.
Procédure manuelle — une étape par couche
Vous préférez exécuter chaque étape vous-même ? Le README bilingue à l’intérieur du ZIP documente la procédure canonique en quatre étapes avec des commandes à copier-coller — une étape par couche d’intégrité :
- Étape 1 — Intégrité des fichiers — Un script python3 lit manifest.json, recalcule le SHA-256 de chaque fichier du paquet, et compare. RÉUSSI = rien n’a été ajouté, supprimé ou modifié.
- Étape 2 — Horodatage qualifié eIDAS — openssl ts -verify contrôle le jeton RFC 3161 par rapport au contenu horodaté en utilisant la chaîne de certificats TSA incluse. (Une alternative en pur Python est incluse pour les environnements sans openssl.) RÉUSSI = les données existaient à l’instant horodaté, signées par la TSA qualifiée inscrite sur l’EU Trusted List.
- Étape 3 — Ancrage Bitcoin OpenTimestamps — Le client ots vérifie le reçu par rapport à la blockchain Bitcoin (ou téléversez-le sur opentimestamps.org, ou contrôlez la transaction sur un explorateur de blocs public comme mempool.space). RÉUSSI = la tête de chaîne a été inscrite dans un bloc Bitcoin spécifique.
- Étape 4 — Chaîne d’empreintes — Un script python3 parcourt chain/proof_chain.jsonl, recalcule l’empreinte de chaque entrée à partir de prev_hash, du type d’événement, du Proof ID et de l’empreinte des données, et confirme le lien avec chain_head.json. RÉUSSI = le journal d’événements interne est intact.
Les 4 RÉUSSISSENT → le paquet est cryptographiquement intact. L’étape Bitcoin est la seule qui nécessite un accès réseau (ou vous pouvez vérifier l’ID de transaction sur un explorateur public à la place). Les étapes 1, 2 et 4 fonctionnent entièrement hors ligne.
Trois outils open source couvrent l’ensemble de la procédure hors ligne :
python3— tout fonctionne sur Linux, macOS et Windows. Utilisé pour les étapes 1, 2 (voie alternative) et 4.openssl— standard sur Linux/macOS ; sur Windows, utilisez Git Bash ou WSL. Utilisé pour la vérification eIDAS canonique (étape 2).ots(depuis pip install opentimestamps-client) — pour l’ancrage Bitcoin (étape 3). Optionnel — vous pouvez aussi vérifier en téléversant le reçu sur opentimestamps.org ou en contrôlant la transaction Bitcoin sur un explorateur de blocs.
Vous voulez savoir exactement quel fichier du ZIP est consommé par chaque étape ? Voir le tutoriel ZIP de preuve — chaque fichier à l’intérieur.
Comment interpréter les résultats
Les résultats sont déterministes. Correspond signifie que la preuve est identique octet pour octet à l’enregistrement d’origine et que toutes les couches d’intégrité réussissent. Modifié signifie qu’au moins une couche a échoué — la preuve ne peut pas être considérée comme l’original.
Lorsque vous voyez Modifié, le rapport par couche vous indique exactement quelle couche a échoué — c’est généralement suffisant pour démontrer que le paquet n’est pas la preuve exportée d’origine.
- le SHA-256 d’un fichier diffère du manifeste → ce fichier a été modifié (p. ex. un pixel de capture d’écran changé, du texte remplacé, ou un fichier JSON reformaté)
- une non-correspondance d’empreinte d’entrée de chaîne → quelqu’un a tenté d’insérer, de supprimer ou de modifier un événement dans l’historique de la preuve
- signature eIDAS invalide ou non-correspondance de l’empreinte → le contenu horodaté a été altéré, ou le TSR a été substitué
- la vérification de l’ancrage Bitcoin échoue → le reçu OpenTimestamps ne s’engage plus sur la même tête de chaîne (ou le reçu lui-même a été falsifié)
Ce que la vérification ne fait pas
- Elle n’évalue pas la véracité — seulement si le contenu capturé est intact et si les ancrages temporels sont valides.
- Elle ne remplace pas un avocat.
- Elle ne décide pas de la recevabilité — celle-ci est déterminée par les autorités et la juridiction.
- Elle ne corrige pas un résultat Modifié. Une fois qu’un ZIP est falsifié, seul le ZIP d’origine (non falsifié) se vérifiera.
La vérification répond seulement à : « Cette preuve est-elle originale et inchangée, et son ancrage temporel est-il cryptographiquement valide ? »
Continuez avec : ZIP de preuve — chaque fichier à l’intérieur, vérifiable hors ligne.
Pas un conseil juridique. La recevabilité dépend de la juridiction et des circonstances.