Les preuves CardanoWall fonctionnent-elles hors ligne ?

Oui — pour tout ce qui se trouve déjà sur votre appareil. Une fois qu'un record Label 309, son contenu ou son texte chiffré, et les clés pour l'ouvrir ont été synchronisés, CardanoWall Desktop peut les parcourir, les rechercher, les déchiffrer et les vérifier sans connexion réseau. Ce qu'il ne peut pas faire, c'est inventer des données qu'il n'a jamais vues : une transaction qu'il n'a jamais synchronisée, ou un texte chiffré qu'il n'a jamais téléchargé.

CardanoWall Desktop fonctionne en priorité hors ligne. Sa base de données locale fait foi pour l'écran que vous avez devant vous ; le réseau n'est qu'un synchroniseur d'arrière-plan qui alimente cette base. Le mode « hors ligne » est donc un mode normal, et non une erreur — la machine locale devient une copie de travail de la partie du monde des preuves que vous avez déjà téléchargée.

C'est précisément cette copie de travail qui rend les preuves utiles sur le terrain : en déplacement, lors d'un audit, d'un examen juridique, d'une réponse à incident, ou partout où la connexion n'est pas fiable. Une preuve ne devrait pas devenir illisible simplement parce qu'un onglet n'arrive pas à joindre un serveur. CardanoWall Desktop est open source — développé en Rust avec Tauri, par-dessus le SDK Rust open source, son code étant disponible sur github.com/cardanowall — vous pouvez donc lire exactement comment il se comporte plutôt que de nous croire sur parole.

Que pouvez-vous faire hors ligne avec des preuves synchronisées ?

Beaucoup de choses, tant que les données sont déjà locales. Si c'est le cas, CardanoWall Desktop vous permet de :

parcourir les records publics Label 309 synchronisés ;
rechercher dans le miroir local des records, y compris par empreinte du contenu ;
consulter les records de la boîte de réception déjà découverts par déchiffrement à l'essai ;
ouvrir le texte chiffré mis en cache ;
déchiffrer les fichiers scellés avec vos clés locales ;
vérifier des empreintes par rapport à des fichiers locaux ;
contrôler la structure des records mis en cache ;
consulter l'historique de vos records envoyés ;
préparer des brouillons à publier plus tard.

Ce sont de véritables opérations cryptographiques, et non des captures d'écran mises en cache. La vérification de l'empreinte, la vérification de la signature, le déchiffrement à l'essai — tout s'exécute localement dans le cœur Rust de l'application, à partir d'octets déjà présents sur le disque.

Que ne pouvez-vous pas faire hors ligne ?

Le mode hors ligne a une limite nette, et il est honnête sur l'endroit où se situe cette limite. L'application ne peut pas fabriquer des données qu'elle n'a jamais eues.

Si une transaction n'a jamais été synchronisée, l'application ne peut pas savoir qu'elle existe sans le réseau ou sans une autre copie locale de ses métadonnées.
Si un texte chiffré n'a jamais été téléchargé, l'application ne peut pas le déchiffrer hors ligne.
Si un record pointe vers une URI de stockage et que ces octets n'ont pas été mis en cache, l'application ne peut pas les récupérer sans connexion.
Si vous voulez publier une nouvelle preuve, l'application a besoin d'un gateway et d'un réseau : elle doit établir le prix de la publication, téléverser, soumettre la transaction Cardano et la confirmer. (La publication passe toujours par un gateway — voir pourquoi la publication a un prix.)

La priorité au hors ligne ne prétend pas que l'application peut combler des données manquantes. Elle affirme qu'une fois les données locales, l'application les traite comme des données à part entière.

Que met l'application en cache, et quel est le degré de sensibilité de chaque couche ?

Il existe quatre couches, par ordre croissant de sensibilité.

Les métadonnées des records publics. Le client desktop conserve un miroir local complet des records Label 309 — scellés et publics — provenant du gateway que vous avez configuré. Chaque record est petit (les métadonnées d'une seule transaction, bien en deçà de la limite de métadonnées d'environ 16 Ko de Cardano), de sorte que l'ensemble global reste de l'ordre de quelques centaines de mégaoctets, même après des années d'usage intensif. Ce miroir est le substrat de la recherche, de la découverte dans la boîte de réception, du suivi des records envoyés et de l'inspection hors ligne. Il ne contient que ce qui est déjà public sur la chaîne ; il est donc stocké non chiffré par conception — chiffrer une copie de données publiques n'apporte rien.

Le texte chiffré. Les records scellés référencent des charges utiles chiffrées via un stockage adressé par le contenu (ar:// ou ipfs://). Mettre ce texte chiffré en cache est sûr, car il est déjà chiffré ; il ne peut être ouvert que par le détenteur d'une clé correspondante. Le client desktop le met en cache pour que la réouverture d'un fichier reçu soit instantanée et fonctionne hors ligne.

Le contenu déchiffré. C'est la couche sensible, et l'application la traite avec soin. Par défaut, elle déchiffre à la demande en mémoire et n'écrit jamais de texte en clair sur le disque. Un cache de fichiers déchiffrés, chiffré séparément et optionnel, existe pour les utilisateurs qui souhaitent des aperçus instantanés sans avoir à rouvrir l'enveloppe, mais il est désactivé par défaut, et le texte en clair n'est écrit dans un emplacement ordinaire que lorsque vous choisissez explicitement Enregistrer. Vous devriez toujours savoir quand des fichiers déchiffrés sont conservés, où, et comment ils sont protégés.

Le matériel d'identité. Les graines d'identité résident dans un coffre chiffré et sont déverrouillées localement. Sans l'identité correspondante déverrouillée, un record scellé peut tout de même apparaître dans le miroir en tant que record public — vous ne pouvez simplement pas en ouvrir le contenu. La graine elle-même ne quitte jamais l'appareil et n'atteint jamais aucun gateway. (Pour comprendre pourquoi cette frontière compte, voir pourquoi les clés ne quittent jamais l'appareil.)

Pouvez-vous vérifier une preuve hors ligne ?

Oui — dès lors que vous disposez des éléments dont le contrôle a besoin. La vérification Label 309 est conçue pour s'exécuter à partir des seules données publiques ; les contrôles cryptographiques ne dépendent donc pas des serveurs de CardanoWall. Ce dont chaque contrôle a besoin :

Une preuve par empreinte nécessite le record et les octets d'origine. Le vérificateur recalcule l'empreinte à partir des octets et la compare à l'empreinte engagée dans le record. Entièrement hors ligne.
Une preuve signée nécessite le record et sa signature intégrée. La clé de signature est portée par la structure de signature du record ou résolue à partir d'elle ; la vérification de la signature s'exécute donc hors ligne une fois le record local.
Une preuve scellée nécessite le record, le texte chiffré et la clé du destinataire (ou la phrase secrète) qui l'ouvre. Avec ces éléments en local, l'application déchiffre, recalcule l'empreinte du texte en clair et la compare à l'engagement du record — l'étape qui relie les octets chiffrés à l'affirmation horodatée.
Une preuve Merkle nécessite la racine issue du record ainsi que la preuve d'inclusion (ou la liste de feuilles pour la reconstruire). Le contrôle d'inclusion s'exécute alors hors ligne, sans aucun gateway dans la boucle. Construire un arbre de Merkle et vérifier une inclusion relèvent du pur calcul — voir un seul record pour des milliers de fichiers.

La seule chose qui nécessite normalement le réseau, c'est d'obtenir des données que vous ne possédez pas encore, et de confirmer l'état actuel de la chaîne. Le calcul lui-même s'exécute localement. (Pour le modèle de vérification complet, voir comment vérifier un record Label 309.)

Qu'en est-il de la confirmation sur la blockchain lorsque vous êtes hors ligne ?

L'horodatage d'une preuve et son statut de confirmation proviennent de Cardano ; ce sont des faits que l'application lit sur la chaîne — elle ne les invente jamais.

Si l'application a déjà synchronisé une transaction et sa profondeur de confirmation, elle peut afficher cet état mis en cache hors ligne. Ce qu'elle ne peut pas faire hors ligne, c'est apprendre l'existence de nouvelles confirmations, d'une réorganisation de la chaîne ou de tout contexte mis à jour, car cela exige d'interroger un explorateur Cardano.

Un client soigneux maintient donc ces états distincts :

les données de record mises en cache et vérifiées localement ;
la date de dernière synchronisation de chaque élément ;
la profondeur de confirmation à la dernière synchronisation ;
les records encore en attente ou en dessous du seuil de confirmation ;
les records qui nécessitent une nouvelle vérification en ligne.

L'affichage hors ligne doit être honnête quant à la fraîcheur des données. Il ne doit jamais présenter la profondeur de confirmation de la semaine dernière comme si elle était à jour.

Comment fonctionne la découverte de la boîte de réception hors ligne ?

Votre boîte de réception est calculée localement à partir de deux éléments : le miroir des records et vos identités déverrouillées. Le gateway est délibérément aveugle au destinataire — il n'a aucune idée des records scellés qui sont « les vôtres » — de sorte que retrouver votre courrier est, par conception, une tâche locale.

Si l'application a synchronisé des records scellés, elle tente le déchiffrement à l'essai de ceux-ci par rapport à vos identités, directement sur l'appareil. Pour chaque emplacement scellé, elle tente un déchiffrement ; ceux que vos clés peuvent ouvrir sont vos messages. Aucun serveur ne se voit demander qui vous êtes.

C'est aussi pourquoi l'importation d'une ancienne graine d'identité fonctionne sans accroc hors ligne. Parce que seule la clé du destinataire décide d'une correspondance, l'application réanalyse le miroir local déjà présent pour cette identité et fait remonter les records scellés plus anciens qui lui étaient adressés — un balayage local, sans nouveau téléchargement. (Votre identité, c'est précisément cette graine ; voir votre identité est une graine.)

Si le miroir est incomplet, la boîte de réception peut l'être aussi. Au retour du réseau, l'application synchronise les records manquants et poursuit la découverte.

Pourquoi ne pas tout garder uniquement dans le cloud ?

Parce que le cloud ne devrait pas être la racine de confiance. Un service hébergé est pratique — il peut publier des records, servir le flux, gérer la tarification et rendre l'interface facile. Mais une preuve devrait survivre à n'importe quel compte de service, et tout l'intérêt de Label 309 est que la vérification n'a besoin que d'une infrastructure publique : les métadonnées de la transaction, éventuellement les octets du contenu, et un explorateur Cardano public. Une copie de travail locale des records qui vous importent est l'expression concrète de cette indépendance.

Cette copie locale fait ses preuves précisément dans les situations où une simple session web est trop fragile : audits, réponse à incident, conservation de pièces, examen de preuves, journalisme, archives de recherche, processus réglementés et préservation à long terme.

Comment une équipe doit-elle utiliser les preuves hors ligne ?

Décidez à l'avance de ce que vous pourriez avoir besoin de prouver sans réseau — puis synchronisez et mettez en cache le matériel de vérification avant que le réseau ne disparaisse.

La forme de « ce qu'il faut mettre en cache » découle du travail :

Une équipe juridique peut vouloir des paquets de preuves chiffrés mis en cache sur une machine approuvée.
Une équipe de conformité peut vouloir disposer, pendant un audit, des records de preuve et des preuves d'inclusion de chaque journée.
Une équipe de release ou de DevSecOps peut vouloir mettre en cache les preuves de build et les manifestes de version aux côtés de l'archive de version.
Une équipe d'IA peut vouloir mettre en miroir localement les manifestes de jeux de données et les engagements sur les sorties de modèle.

La règle est simple : si vous pourriez avoir besoin de le prouver hors ligne, synchronisez-le et mettez en cache le matériel qui le prouve avant que la connexion ne disparaisse. Pour le contenu scellé, confirmez également que la graine d'identité concernée est sauvegardée et disponible pour les bonnes personnes ou les bons appareils selon votre politique — sans elle, le texte chiffré reste fermé.

Quels sont les risques liés à la conservation locale des preuves ?

L'accès hors ligne fait reposer une partie de la responsabilité sur l'appareil, et il vaut la peine d'être clair à ce sujet.

Il y a un risque lié au stockage local. Si un appareil est volé, ses caches comptent. Le texte chiffré mis en cache est chiffré et ne peut pas être ouvert sans clé, mais tous les fichiers déchiffrés que vous avez choisi de conserver sont sensibles, et le coffre d'identité doit être protégé. Le système d'exploitation, le chiffrement du disque, le compte utilisateur, la phrase secrète et la sécurité générale de l'appareil deviennent tous partie intégrante du modèle de confiance. CardanoWall Desktop réduit l'exposition grâce à un coffre chiffré, au verrouillage automatique et à un effacement au mieux des clés en mémoire, mais il ne peut pas défendre une machine entièrement compromise et déverrouillée — et il le dit clairement.

Il y a aussi un risque de fraîcheur. Une preuve mise en cache est valide à la date de sa dernière synchronisation, mais l'application ne peut pas connaître l'état actuel de la chaîne tant qu'elle ne s'est pas reconnectée.

Un bon logiciel rend ces limites visibles : il affiche la date de la dernière synchronisation, distingue une vérification mise en cache d'un contrôle en ligne récent, et évite d'écrire silencieusement du texte en clair déchiffré dans des emplacements non sûrs.

Que faut-il conserver pour une preuve à long terme ?

Pour les preuves qui comptent sur plusieurs années, conservez plus que l'empreinte de la transaction. Selon le type de preuve, cela signifie :

la référence de la transaction ;
les octets du record Label 309 (ou un export vérifié) ;
le fichier original ou le texte en clair ;
le texte chiffré, pour les records scellés ;
la graine d'identité ou le secret du destinataire nécessaire au déchiffrement ;
la liste de feuilles Merkle ou les preuves d'inclusion ;
toute signature ou clé publique nécessaire à l'attribution ;
une brève note sur la manière dont la preuve a été créée et le processus auquel elle appartient.

La blockchain fournit l'ancrage public — le fait que ces octets exacts existaient avant une heure de bloc publique. Votre archive locale préserve le contexte qui rend cet ancrage utile par la suite. (Et rappelez-vous ce que l'ancrage affirme et n'affirme pas : voir ce qu'une preuve ne prouve pas.)

En bref

La preuve hors ligne n'est pas de la magie ; c'est de la préparation. Si le record, le contenu, le texte chiffré, les clés et toutes les preuves d'inclusion sont en local, les contrôles cryptographiques s'exécutent tous localement. Si quelque chose n'a jamais été synchronisé ni mis en cache, l'application a besoin du réseau pour le récupérer — et elle vous le dit plutôt que de faire semblant.

CardanoWall Desktop normalise cette copie de travail locale : il synchronise les records, découvre sur l'appareil les éléments scellés de la boîte de réception, met en cache les fichiers chiffrés, vérifie les preuves et maintient utiles les pièces déjà synchronisées, même lorsque le réseau a disparu.

Pour aller plus loin

CardanoWall Desktop — le client desktop open source décrit dans cet article.
Comment vérifier un record Label 309 — le modèle de vérification dans son intégralité.
Un seul record pour des milliers de fichiers — le regroupement Merkle, entièrement hors ligne sauf la publication.
Ce qu'une preuve ne prouve pas — les limites d'une preuve d'existence horodatée.
Le code open source, la CLI et les SDK : github.com/cardanowall.