Autrement dit, dans la langue fleurie que j’adopte volontiers : foutez la paix aux fichiers. Pourquoi cette injonction ? Parce que, dans la vulgate préservationniste, largement fondée sur des idées préconçues et élaborée dans les années 2000, l’interventionnisme était de mise, et nous a sans doute amenés à faire des bêtises. Inspirés par les politiques de numérisation, nous avons par exemple abusé de stratégies de normalisation. La tête de mes fichiers ne me revient pas ? Qu’à cela ne tienne, je convertis tout dans un seul format, et tant pis si ce lit de Procuste est trop petit et qu’on doit pour l’y faire rentrer sabrer de précieuses métadonnées internes, descriptives ou techniques, voire des morceaux inattendus (vignettes dans une piste audio, commentaire audio dans une photographie numérique, etc.).
Aimez-les comme ils sont, avec leurs défauts, leurs irrégularités. N’essayez pas de les changer. Ce sont des données patrimoniales, que diable, et c’est donc nos outils d’accès qui doivent s’y adapter, pas le contraire.
Après une entrée en matière aussi subtile, il faut quand même que je revienne à du concret, à de la précision. Mais il n’est pas inutile de marteler, tout simplement parce que la peur de mal faire nous a tou·te·s empéché·e·s de collecter des données tout à fait légitimes sous prétexte qu’elles n’étaient pas dans le « bon » format ou qu’un outil quelconque nous renvoyait une erreur absconse. Si ça vaut la peine, prenez. On trouvera bien le moyen de régler la question plus tard.
Venons-en donc au cas qui m’a amené à faire ce billet, qui présentera un tout petit cas d’usage pour illustrer cette grande vérité. Il faut pour cela aborder la question de la « validation » du fichier au regard de ses spécifications. Cette opération fait partie de la triade consacrée de la préservation numérique : identifier, caractériser, valider. La validation consiste à vérifier, à l’aide d’un outil qu’on espère le plus exhaustif possible, que la structure du fichier est correcte, puisqu’un fichier mal formé a plus de chances d’être mal restitué par un outil de lecture à l’avenir. C’est une opération classique pour la numérisation – si mes images sont mal formées, il m’est facile de demander à mon prestataire de les relivrer. Mais est-elle pertinente pour le nativement numérique1 ?
La réponse est évidemment : ça dépend. Concernant la BnF, si je schématise, on a la politique suivante :
- Si c’est du dépôt légal massif et normalisé, on valide et on rejette les fichiers invalides en demandant une relivraison.
- S’il s’agit de dons ou d’acquisitions, on valide aussi mais on analyse le résultat et on peut soit accepter tel quel, soit intervenir pour tenter de corriger le problème. Avec précaution, comme on va le voir.
D’autres institutions choisissent de ne pas tenter une telle procédure : les archives nationales françaises, par exemple, se limitent à la vérification que le fichier s’ouvre.
Un des outils incontournables pour réaliser cette opération est JHOVE. Développé à l’origine par Harvard (d’où le « H » dans son nom), il est actuellement maintenu par l’Open Preservation Foundation. Il est capable de valider et caractériser (analyser et renvoyer des propriétés) les fichiers d’une quinzaine de formats différents. Chaque format dispose de sa liste d’erreurs possibles, que la communauté tente de documenter dans le wiki de JHOVE, avec une évaluation de leur gravité et des moyens de les résoudre. Un groupe de travail, initié par Micky Lindlar, vient d’ailleurs de se créer dans ce but.
Or mes collègues Laurence Moreau, gestionnaire de collections iconographiques au département des Arts du spectacle et Alix Bruys, responsable de processus dons numériques, m’ont récemment sollicité pour un TIFF mal formé, au milieu de très nombreux autres qui ne posaient pas de problème, dans le fond Christophe Raynaud de Lage. La BnF a acquis la production du photographe officiel du festival d’Avignon depuis 2005 et y donne accès sur Gallica.
Pour cette image, JHOVE renvoyait l’erreur nommée TIFF-HUL-66 : « <Tag> value out of range: <value>. » – en français, « Valeur <tag> en dehors des limites : ».
La question qui se pose, si on tombe sur une erreur, et celle à laquelle le groupe de travail mentionné plus haut tente de répondre, c’est : faut-il intervenir ou pas ?
Vous savez sans doute que le « T » de TIFF signifie tagged : le format TIFF est un format d’image qui gère des métadonnées internes de nature différente par des tags, des étiquettes qui associent un nombre (correspondant à un libellé anglais) à une valeur. Les tags peuvent être définis par la spécification TIFF elle-même, par un document de référence complémentaire (par exemple, le tag 33550, qui correspond au Model pixel scale tag – les traductions françaises ne sont pas normalisées, donc peuvent varier – et est défini par la spécification GeoTIFF) ou par des implémentations spécifiques à des produits logiciels (ainsi, le tag 34908 « FaxRecvParams » a été défini pour les besoins du logiciel de fax HylaFax).
Ici, le message exact était :
Comprendre donc : la valeur du tag ExposureProgram, qui identifie le mode d’exposition choisi pour la photographie, a une valeur inattendue (car ce tag attend une liste fermée de valeurs), « 9 en l’occurrence. Il existe un document très pratique, maintenu par la Bibliothèque du Congrès, qui liste les tags TIFF, y compris ceux propriétaires, et fait un lien vers le site qui servait de référence jusqu’à avril dernier : awaresystems.be. Depuis, ce site personnel a annoncé sa fin d’activité, son goût pour la randonnée (on lui souhaite de s’y épanouir) puis est tombé, et la communauté de la préservation numérique en est réduite à consulter le site archivé sur Internet Archive. Sic transit gloria mundi.
Pour le tag ExposureProgram, la page de description est celle-ci. On y voit donc des valeurs attendues de 0 à 8, mais pas de 9. La valeur est donc effectivement inattendue. Premier réflexe : très bien, on change la valeur pour « 0 » (unknown), et JHOVE sera content !
Minute papillon.
Si XnView (un outil libre de visualisation d’images) ignore également cette valeur…
… en revanche, ExifTool la connaît !
Et en effet, il s’agit bien d’une pose longue adaptée aux prises de vue de nuit (en saxophone : bulb mode). La photographie est prise lors de la représentation de la pièce Outside, de Kirill Serebrennikov, au moment où des néons diffusent une lumière noire. Dans la bande-annonce de la pièce, ce moment est visible à 0’19 :
Je ne sais pas si, dans la dernière version d’EXIF (3.0), cette valeur est désormais acceptée : la norme coûte près de 190 €. Toujours est-il qu’il n’est selon toute apparence, pas légitime de « corriger » cette photographie puisque la valeur a un sens consensuel, connu d’au moins un outil, et que nous souhaitons garder l’information du fait que la photographie a été prise avec un mode de pose longue.
Faut-il également modifier le comportement de JHOVE pour qu’il accepte cette valeur ? Sans doute. Les cas où c’est l’outil de validation qui est fautif, et non le fichier, se multiplient ces derniers temps. Bref, si vous n’avez ni le temps ni le savoir nécessaires pour analyser les résultats de JHOVE, ne refusez pas les fichiers, et ne vous embarquez pas dans des modifications hasardeuses.
Je mettrai à jour ce billet avec le lien vers la photographie dès que mes collègues l’auront traitée. Toutefois, Gallica ne vous donnera qu’une version de consultation, très appauvrie. Vous devrez me croire sur parole concernant la présence des métadonnées dans l’image…
- Sur les effets secondaires nocifs d’une validation systématique, on lira le billet suivant :
Wheatley, Paul. “A Valediction for Validation?” Digital Preservation Coalition, 11 Nov. 2018, https://www.dpconline.org/blog/a-valediction-for-validation. ↩︎
1 Pingback