Vault ne dit « vérifié » que lorsqu’il a prouvé que les octets sont les bons. Ne pas avoir pu regarder n’est jamais une bonne nouvelle, ni une mauvaise : c’est une troisième réponse, qu’il garde à part. Ce chapitre explique chaque réponse et ce qu’il faut en faire.
Les quatre états d’un fichier
Chaque fichier de la bibliothèque est dans l’un de ces quatre états, selon son dernier contrôle :
| État | Ce que Vault a constaté | Ce que cela prouve | Que faire |
|---|---|---|---|
| Vérifié | Le fichier a été relu en entier ; son empreinte SHA-256 est celle de l’import. | Le fichier est intact à la date du contrôle. | Rien. |
| Altéré | Le fichier a été relu en entier ; son empreinte a changé. | Le fichier n’est plus celui de l’import : il a été modifié ou corrompu. | Restaurer depuis une copie saine, ou le traiter comme un nouvel original s’il a été modifié volontairement. |
| Non vérifiable | Le fichier est introuvable (disque débranché, fichier déplacé ou supprimé) ou illisible (droits, erreur de lecture, lecture interrompue). | Rien, ni bon ni mauvais. | Rendre le fichier accessible et relancer l’audit. |
| Jamais vérifié | Aucun contrôle enregistré pour ce fichier. | Rien encore. | Lancer un audit. |
Les quatre nombres font toujours le total des fichiers : un fichier n’est jamais compté « vérifié » parce que personne ne l’a regardé.
Dans Fichiers à examiner, le résultat précis du dernier contrôle est affiché : Empreinte différente, Introuvable ou Illisible.
Pourquoi « non vérifiable » n’est pas « vérifié » : un disque débranché ne prouve pas que les fichiers qu’il porte sont intacts. Le compter comme bon masquerait exactement la situation où l’on perd des fichiers sans le savoir.
Pourquoi « non vérifiable » n’est pas « altéré » : un fichier introuvable n’est pas forcément abîmé. Le compter comme corrompu ferait restaurer des fichiers qui vont bien et noierait les vraies altérations.
Les verdicts d’une archive
Vérifier une archive (dans Archives, ou lors de l’envoi hors site) donne l’un de ces trois verdicts :
| Verdict | Libellé dans Archives | Ce que cela veut dire |
|---|---|---|
| Vérifiée | « Vérifiée le … », bandeau Archive vérifiée | La signature correspond au manifeste et l’empreinte du contenu est celle annoncée. |
| Échec | « Non conforme (…) », bandeau Archive non conforme | L’archive a été lue et quelque chose ne va pas (détail ci-dessous). Ne vous y fiez pas. |
| Non vérifiable | « Non vérifiable (…) », bandeau Archive non vérifiable | Le dossier de l’archive est introuvable (déplacé, ou sur un disque débranché), ou l’archive est signée par une clé que Vault ne connaît pas. Rien n’est prouvé, ni dans un sens ni dans l’autre. |
| — | Jamais vérifiée | Aucune vérification enregistrée. |
Le détail d’un échec dit ce qui a été trouvé :
- « Le manifeste (manifest.json) est absent. »
- « La signature (signature.ed25519) est absente. »
- « La signature ne correspond pas au manifeste : l’archive a pu être modifiée. »
- « Le manifeste est signé mais illisible. »
- « Le fichier de contenu de l’archive est absent. »
- « L’empreinte du contenu ne correspond pas : l’archive est altérée. »
- « L’annexe d’inventaire (inventory.json) ne correspond pas à cette archive : l’archive est altérée. » (voir L’annexe d’inventaire)
Une archive signée par une clé que Vault ne connaît pas (une archive d’Obscura Flow avant l’import de sa clé, ou celle d’un autre Mac) est non vérifiable, pas en échec : « Cette archive a été signée par une clé que Vault ne connaît pas (empreinte …) : elle n’a pas pu être vérifiée, ce qui ne veut pas dire qu’elle est abîmée. » Importez la clé de signature de l’installation qui l’a créée, puis vérifiez-la à nouveau. Voir Clés et sécurité.
Chaque verdict est enregistré avec sa date : l’écran Intégrité montre le dernier verdict de chaque archive, le Tableau de bord en fait le compte.
Vérifier une révision incrémentale vérifie ce paquet seul, comme toute archive : son verdict ne dit rien de la révision dont elle part.
« Non restaurable »
Une révision incrémentale ne se restaure qu’avec toute sa chaîne. Elle est donc restaurable à un endroit (le dossier des archives, un support, une destination hors site) seulement si chaque révision de sa chaîne y a pour dernier verdict « vérifiée ». Si son propre paquet est intact mais qu’une révision dont elle dépend ne l’est pas, ou n’a jamais été vérifiée à cet endroit, elle est marquée Non restaurable : dans la liste des Archives, sur l’écran Intégrité et sur le Tableau de bord (« N révisions incrémentales non restaurables »). Survolez la marque pour savoir quelle révision de la chaîne l’en empêche.
Une telle révision ne compte pas comme une copie : ni parmi les archives vérifiées du tableau de bord, ni dans les copies d’un support (chapitre 6), ni parmi les copies hors site, où toute sa chaîne doit être envoyée à la même destination.
Quand la vérification trouve une révision altérée, son verdict nomme les révisions qui en dépendent : « Les révisions qui en dépendent ne sont plus restaurables à partir de cet endroit : 2, 3. » Le journal le note aussi. Remettez une copie saine de la révision altérée (depuis un autre support ou le hors site), puis vérifiez-la à nouveau.
Une révision introuvable (son dossier supprimé dans le Finder, ou déplacé) n’est plus comptée comme intacte à cet endroit, même si sa dernière vérification l’était : Vault la note « Archive introuvable » (non vérifiable, pas altérée), contre sa propre révision, dès qu’il relit la liste des Archives ou qu’il la vérifie, sur un support comme dans le dossier des archives. Son verdict nomme lui aussi les révisions qui en dépendent, qui deviennent Non restaurable à cet endroit, et seulement là : une destination hors site ou un support qui garde toute la chaîne la restaure toujours. Remettez la révision à sa place, puis vérifiez-la à nouveau. Si le dossier des archives lui-même est absent (un disque débranché), Vault ne note rien : il le signale en haut de l’écran.
Retirer une révision dont d’autres dépendent
Pour la même raison, Vault refuse de retirer une révision d’un endroit (le dossier des archives, un support, une destination hors site) tant qu’une révision incrémentale gardée au même endroit en dépend. Le message nomme ces révisions, par exemple : « La révision 1 ne peut pas être retirée de la destination « NAS » : les révisions 2, 3, à cette destination, en dépendent. » Pour lever le refus :
- retirez d’abord ces révisions de cet endroit, de la plus récente à la plus ancienne ;
- ou gardez à cet endroit une révision complète plus récente : faite dans le dossier des archives, vérifiée sur le support, ou envoyée à la destination. La révision retirée ensuite, celles qui en dépendaient deviennent Non restaurables à cet endroit, et seulement là.
Une révision gardée ailleurs ne compte pas : c’est à chaque endroit que la chaîne doit être entière. Vault ne retire jamais de révision de lui-même. Aujourd’hui, seul l’écran Hors site retire une copie, avec Supprimer la copie… (chapitre 7), et c’est là que ce refus s’affiche. Si vous supprimez un paquet à la main dans le Finder, Vault ne peut pas vous en empêcher, mais il s’en aperçoit (voir plus haut) : ne supprimez pas une révision dont d’autres dépendent.
Vérifier une archive contrôle l’empreinte de son contenu dans son ensemble. Le contrôle fichier par fichier a lieu à la restauration : chaque fichier restauré est relu et comparé au manifeste.
Les verdicts d’une copie hors site
Vérifier une copie hors site (chapitre 7) télécharge son contenu et le compare au manifeste. La copie est vérifiée, ou endommagée : absente, manifeste absent, contenu absent ou empreinte différente.
Les verdicts d’un certificat
Vérifier un certificat PDF (chapitre 9) donne un verdict sur sa signature, un statut de révocation et un état d’horodatage. Seul Signature valide, clé reconnue est un succès complet ; Intact, mais signé par une clé non reconnue veut dire que le document n’a pas été modifié mais que son origine n’est pas vérifiée.