# Formats de données pour la préservation à long terme :
## la politique de la BnF

Bertrand Caron

► To cite this version:

Bertrand Caron. Formats de données pour la préservation à long terme: la politique de la BnF. [Rapport Technique] Bibliothèque Nationale de France (Paris). 2021. hal-03374030v2

HAL Id: hal-03374030

https://bnf.hal.science/hal-03374030v2

Submitted on 27 May 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Bibliothèque nationale de France

Formats de données pour la
préservation à long terme : la
politique de la BnF - version 2

Bibliothèque nationale
de France

direction des Services et des réseaux

département de la Conservation
service Numérisation

version 2

émetteur : Bertrand CARON

affaire suivie par : Bertrand CARON

référence : BnF-ADM-2018-021638-04
<figure><img src="image_2.png" /></figure>

Table des mises à jour du document

<table><thead><tr><td>Version</td><td>Auteur</td><td>Date</td><td>Objet de la mise à jour</td></tr></thead><tbody><tr><td>0.1</td><td>Groupe Formats de la BnF</td><td>12/04/2021</td><td>Publication de la première version du document pour appel à commentaire.</td></tr><tr><td>1</td><td>B. Caron</td><td>08/10/2021</td><td>Publication de la première version révisée stable sur la plateforme HAL.</td></tr><tr><td>2</td><td>Groupe Formats de la BnF</td><td></td><td>Validation de la version 2. Changements majeurs :<br/>1. Ajout des sections 2.3 « Qu'est-ce qu'un format ? », 2.4 « Compression avec ou sans perte », 2.5 « Propriétés des contenus numériques » et 2.6 « Étapes du cycle de vie des contenus numériques »<br/>2. Abandon du terme « migration » au profit de celui plus générique de « transformation » ou de celui plus concret de conversion de format<br/>3. Ajout du critère « Qualité et caractéristiques du flux » dans les critères d'évaluation d'un format<br/>4. Ajout de « Intervention minimale » et « Mode d'entrée ou de production » dans les critères de transformation<br/>5. Modification de la structure des sections sur les « Métadonnées pertinentes », renommées « Propriétés des contenus ».<br/>6. Modification des catégories de formats : suppression des catégories « Préférées » et « Acceptées »;<br/>7. Ajout de nouveaux types de contenus : musique notée, correspondance, contenus cartographiques, texte synchronisé à une ressource temporelle.<br/>8. Nouvelles fiches Formats : AAC, APK, ASCII Grid, BWF, DOCX, DSD, EBU-STL, EBU-TT, Fichiers système, FFV1, GeoJP2, GeoPackage, GeoTIFF, MBOX, MKV, MPEG-4 TT, MUS/MUSX, PDF, PST, Shapefile, S-57, SRT, UDF, WebVTT, ZIP.<br/>9. Fiches Formats mises à jour.</td></tr></tbody></table>
<figure><img src="image_3.png" /></figure>

TABLE DES MATIERES

<table><tr><td>1. INTRODUCTION</td><td>6</td></tr><tr><td>1.1. OBJET</td><td>6</td></tr><tr><td>1.2. GESTION ET EVOLUTION</td><td>6</td></tr><tr><td>1.3. DOCUMENTS APPLICABLES ET DE REFERENCE</td><td>6</td></tr><tr><td>1.4. GLOSSAIRE</td><td>7</td></tr><tr><td>1.5. ABREVIATIONS</td><td>11</td></tr><tr><td>2. PRINCIPES DIRECTEURS DE LA POLITIQUE</td><td>11</td></tr><tr><td>2.1. CONTEXTE</td><td>12</td></tr><tr><td>2.2. OBJET DU DOCUMENT ET LECTORAT ATTENDU</td><td>12</td></tr><tr><td>2.3. LE « FORMAT », UNE NOTION EQUIVOQUE</td><td>13</td></tr><tr><td>2.4. COMPRESSION AVEC OU SANS PERTE</td><td>14</td></tr><tr><td>2.5. PROPRIETES DES CONTENUS NUMERIQUES</td><td>14</td></tr><tr><td>2.6. ÉTAPES DU CYCLE DE PRODUCTION DES CONTENUS NUMERIQUES</td><td>15</td></tr><tr><td>2.7. UNE POLITIQUE, DES PRATIQUES</td><td>16</td></tr><tr><td>2.8. CRITERES DE PERENNITE POUR L'EVALUATION D'UN FORMAT DE DONNEES</td><td>17</td></tr><tr><td>2.8.1. Critères objectifs</td><td>17</td></tr><tr><td>2.8.2. Critères subjectifs</td><td>20</td></tr><tr><td>2.9. ANALYSE DES FICHIERS</td><td>21</td></tr><tr><td>2.9.1. Identification du format</td><td>22</td></tr><tr><td>2.9.2. Caractérisation du fichier</td><td>22</td></tr><tr><td>2.9.3. Validation du fichier</td><td>24</td></tr><tr><td>2.9.4. Contrôle de conformité à un profil d'application</td><td>24</td></tr><tr><td>2.10. STRATEGIES DE PRESERVATION</td><td>25</td></tr><tr><td>2.10.1. Opérations préalables au versement</td><td>26</td></tr><tr><td>2.10.2. Opérations postérieures au versement</td><td>30</td></tr><tr><td>2.10.3. Exemple d'opération de virtualisation et d'émulation</td><td>30</td></tr><tr><td>3. LISTE DES FORMATS CONNUS</td><td>32</td></tr><tr><td>3.1. IMAGES FIXES</td><td>33</td></tr><tr><td>3.1.1. Images issues de la numérisation</td><td>33</td></tr><tr><td>3.1.2. Photographies nativement numériques</td><td>34</td></tr><tr><td>3.1.3. Œuvres graphiques</td><td>34</td></tr><tr><td>3.2. CONTENUS TEXTUELS</td><td>35</td></tr><tr><td>3.2.1. Texte brut ou semi-structuré</td><td>35</td></tr><tr><td>3.2.2. Documents textuels / texte formaté</td><td>36</td></tr><tr><td>3.3. CONTENUS SONORES</td><td>37</td></tr><tr><td>3.3.1. Propriétés des contenus sonores</td><td>37</td></tr><tr><td>3.3.2. Formats</td><td>38</td></tr><tr><td>3.4. IMAGES ANIMEES</td><td>39</td></tr><tr><td>3.4.1. Propriétés des images animées</td><td>39</td></tr></table>
<figure><img src="image_4.png" /></figure>

<table>
  <tbody>
    <tr>
      <td>3.4.2.</td>
      <td>Formats</td>
      <td>39</td>
    </tr>
    <tr>
      <td>3.4.3.</td>
      <td>DVD vidéo</td>
      <td>39</td>
    </tr>
    <tr>
      <td>3.4.4.</td>
      <td>Texte synchronisé à un contenu vidéo</td>
      <td>40</td>
    </tr>
    <tr>
      <td>3.5.</td>
      <td>CONTENUS WEB</td>
      <td>40</td>
    </tr>
    <tr>
      <td>3.5.1.</td>
      <td>Métadonnées techniques de caractérisation produites par la BnF</td>
      <td>40</td>
    </tr>
    <tr>
      <td>3.5.2.</td>
      <td>Formats</td>
      <td>40</td>
    </tr>
    <tr>
      <td>3.6.</td>
      <td>CONTENUS CARTOGRAPHIQUES</td>
      <td>41</td>
    </tr>
    <tr>
      <td>3.6.1.</td>
      <td>Propriétés communes à tous les contenus cartographiques</td>
      <td>41</td>
    </tr>
    <tr>
      <td>3.6.2.</td>
      <td>Cartes statiques et orthophotographies géoréférencées</td>
      <td>41</td>
    </tr>
    <tr>
      <td>3.6.3.</td>
      <td>Bases de données géographiques et cartes interactives</td>
      <td>42</td>
    </tr>
    <tr>
      <td>3.7.</td>
      <td>NOTATION MUSICALE</td>
      <td>43</td>
    </tr>
    <tr>
      <td>3.7.1.</td>
      <td>Propriétés des contenus de notation musicale</td>
      <td>43</td>
    </tr>
    <tr>
      <td>3.7.2.</td>
      <td>Étape de création</td>
      <td>43</td>
    </tr>
    <tr>
      <td>3.7.3.</td>
      <td>Étape de diffusion</td>
      <td>43</td>
    </tr>
    <tr>
      <td>3.8.</td>
      <td>CORRESPONDANCE</td>
      <td>43</td>
    </tr>
    <tr>
      <td>3.8.1.</td>
      <td>Messageries électroniques</td>
      <td>44</td>
    </tr>
    <tr>
      <td>3.9.</td>
      <td>DOCUMENTS MULTIMEDIA</td>
      <td>44</td>
    </tr>
    <tr>
      <td>3.9.1.</td>
      <td>Propriétés des documents multimédia</td>
      <td>44</td>
    </tr>
    <tr>
      <td>4.</td>
      <td>FICHES FORMAT</td>
      <td>46</td>
    </tr>
    <tr>
      <td>4.1.</td>
      <td>STRUCTURE DES FICHES</td>
      <td>46</td>
    </tr>
    <tr>
      <td>4.2.</td>
      <td>ANDROID PACKAGE (APK)</td>
      <td>48</td>
    </tr>
    <tr>
      <td>4.3.</td>
      <td>ASCII GRID</td>
      <td>51</td>
    </tr>
    <tr>
      <td>4.4.</td>
      <td>BROADCAST WAVE FORMAT (BWF) / MBWF (MULTI-CHANNEL BWF)</td>
      <td>54</td>
    </tr>
    <tr>
      <td>4.5.</td>
      <td>DAISY DIGITAL TALKING BOOK</td>
      <td>57</td>
    </tr>
    <tr>
      <td>4.6.</td>
      <td>DSD</td>
      <td>59</td>
    </tr>
    <tr>
      <td>4.7.</td>
      <td>EBU-STL</td>
      <td>62</td>
    </tr>
    <tr>
      <td>4.8.</td>
      <td>EBU-TT</td>
      <td>64</td>
    </tr>
    <tr>
      <td>4.9.</td>
      <td>FORMAT TEXTUEL OFFICE OPEN XML (DOCX)</td>
      <td>66</td>
    </tr>
    <tr>
      <td>4.10.</td>
      <td>EPUB</td>
      <td>70</td>
    </tr>
    <tr>
      <td>4.11.</td>
      <td>FFMPEG VIDEO CODEC VERSION 1 (FFV1) (CODEC)</td>
      <td>73</td>
    </tr>
    <tr>
      <td>4.12.</td>
      <td>GEOJP2</td>
      <td>76</td>
    </tr>
    <tr>
      <td>4.13.</td>
      <td>GEOPACKAGE (GPKG)</td>
      <td>78</td>
    </tr>
    <tr>
      <td>4.14.</td>
      <td>GEOTIFF</td>
      <td>81</td>
    </tr>
    <tr>
      <td>4.15.</td>
      <td>H.264 (CODEC)</td>
      <td>84</td>
    </tr>
    <tr>
      <td>4.16.</td>
      <td>JPEG FILE INTERCHANGE FORMAT (JPEG)</td>
      <td>88</td>
    </tr>
    <tr>
      <td>4.17.</td>
      <td>JPEG 2000</td>
      <td>90</td>
    </tr>
    <tr>
      <td>4.18.</td>
      <td>MATROSKA (MKV) (CONTENEUR)</td>
      <td>92</td>
    </tr>
    <tr>
      <td>4.19.</td>
      <td>MBOX</td>
      <td>95</td>
    </tr>
    <tr>
      <td>4.20.</td>
      <td>MICROSOFT PST</td>
      <td>97</td>
    </tr>
    <tr>
      <td>4.21.</td>
      <td>MPEG-1/2 AUDIO LAYER III (MP3)</td>
      <td>99</td>
    </tr>
    <tr>
      <td>4.22.</td>
      <td>MPEG-PS (CONTENEUR) H.262 (CODEC VIDEO) MPEG-2 LAYER II (CODEC AUDIO)</td>
      <td>101</td>
    </tr>
  </tbody>
</table>
<figure><img src="image_5.png" /></figure>

<table><tr><td>4.23.</td><td>MPEG-2/4 AUDIO (AAC) (CODEC)</td><td>104</td></tr><tr><td>4.24.</td><td>MPEG-4 TT (CODEC)</td><td>107</td></tr><tr><td>4.25.</td><td>MP4 (CONTENEUR)</td><td>109</td></tr><tr><td>4.26.</td><td>MUS / MUSX</td><td>112</td></tr><tr><td>4.27.</td><td>NATIVE FLAC</td><td>115</td></tr><tr><td>4.28.</td><td>OPENDOCUMENT TEXT (ODT)</td><td>117</td></tr><tr><td>4.29.</td><td>PDF</td><td>120</td></tr><tr><td>4.30.</td><td>PDF/A</td><td>125</td></tr><tr><td>4.31.</td><td>PRORES (CODEC)</td><td>128</td></tr><tr><td>4.32.</td><td>QUICKTIME FILE FORMAT (MOV) (CONTENEUR)</td><td>130</td></tr><tr><td>4.33.</td><td>SHAPEFILE (SHP)</td><td>133</td></tr><tr><td>4.34.</td><td>S-57 (ENC)</td><td>136</td></tr><tr><td>4.35.</td><td>SRT</td><td>141</td></tr><tr><td>4.36.</td><td>TIFF</td><td>143</td></tr><tr><td>4.37.</td><td>UNIVERSAL DISK FORMAT (UDF)</td><td>146</td></tr><tr><td>4.38.</td><td>WARC</td><td>150</td></tr><tr><td>4.39.</td><td>WAVE / WAVE RF64</td><td>152</td></tr><tr><td>4.40.</td><td>WEBVTT</td><td>155</td></tr><tr><td>4.41.</td><td>XML-ALTO</td><td>157</td></tr><tr><td>4.42.</td><td>XML-METS</td><td>159</td></tr><tr><td>4.43.</td><td>XML-TDMNUM</td><td>162</td></tr><tr><td>4.44.</td><td>ZIP (CONTENEUR GENERIQUE)</td><td>163</td></tr><tr><td>4.45.</td><td>FICHIERS SYSTEME</td><td>166</td></tr><tr><td>5.</td><td>POUR ALLER PLUS LOIN</td><td>169</td></tr></table>

5.1. SOURCES D'INFORMATION SUR LES FORMATS DE DONNEES DANS UNE PERSPECTIVE DE PRESERVATION 169

5.2. DOCUMENTS DE POLITIQUE FORMATS PUBLIES PAR LES INSTITUTIONS DE CONSERVATION 169
<figure><img src="image_6.png" /></figure>

# 1. Introduction

## 1.1. Objet

Ce document décrit la politique globale de la BnF vis-à-vis des formats de données dans la perspective de la préservation à long terme de l'information numérique.

Il détaille en particulier :

- Les principes que la BnF a adoptés pour sa politique (section 2) ;

- La liste des formats qu'elle connait et qui ont par conséquent sa préférence (section 3) ;

- Une description de la plupart de ces formats (section 4) ;

- Des informations sur les fichiers système pour lesquels elle est susceptible d'appliquer une politique de collecte différente que pour les fichiers de données (section 4.45) ;

- Une liste de ressources complémentaires et de politiques de formats établies par d'autres institutions de conservation (section 5).

## 1.2. Gestion et évolution

Ce document est publié en mars 2025 dans une version 2.

Il est généré par le groupe de travail BnF « Formats de données pour la préservation numérique ». Il reflète l'état de la connaissance et du savoir-faire de la BnF en matière de formats de données pour la préservation à une date donnée. Dans la mesure où l'activité du groupe de travail est continue, ce document a vocation à être périodiquement révisé – une fois tous les trois ans environ, mais cette périodicité est actuellement indicative – pour refléter l'évolution de ses connaissances et compétences. Les changements suivants sont attendus.

- De nouveaux types de contenu seront traités.

- De nouveaux formats seront ajoutés, voire retranchés si nécessaire.

## 1.3. Documents applicables et de référence

Certaines restrictions peuvent être appliquées selon le mode d'entrée des collections. Lorsqu'ils seront publiés, les documents incluant des recommandations sur les formats spécifiques à une filière seront référencés dans cette section.

<table><thead><tr><td>Intitulé</td><td>Description</td><td>Référence</td></tr></thead><tbody><tr><td>Norme OAIS</td><td>Norme CCSDS 650.0-M-2 (F) « Modèle de référence pour un système ouvert d'archivage d'information (OAIS) », version française</td><td>https://public.ccsds.org/Pubs/650x0m2%28F%29.pdf</td></tr><tr><td>Référentiel OCR - version 2</td><td>Référentiel décrivant le profil d'application BnF du format XML-ALTO</td><td>https://www.bnf.fr/sites/default/files/2018-11/ref_num_ocr_v2.pdf</td></tr><tr><td>Référentiel d'enrichissement des textes</td><td>Référentiel décrivant le profil d'application BnF du format METS enregistrant le résultat d'opérations de reconnaissance optique de la mise en page</td><td>https://www.bnf.fr/sites/default/files/2018-11/ref_num_enr_texte.pdf</td></tr><tr><td>Référentiel ePub 3</td><td>Référentiel présentant le profil d'application BnF pour le format EPUB 3 de numérisation</td><td>https://www.bnf.fr/sites/default/files/2018-11/referentiels_num_epub3.pdf</td></tr></tbody></table>
<figure><img src="image_7.png" /></figure>

<table><tr><td>Référentiel DAISY</td><td>Référentiel présentant le profil d'application BnF pour les fichiers DTBook 2005-3 de numérisation</td><td>https://www.bnf.fr/sites/default/files/2018-11/ref_num_daisy.pdf</td></tr><tr><td>Référentiel de numérisation des documents opaques</td><td>Référentiel décrivant le profil d'application BnF pour les fichiers TIFF de numérisation</td><td>https://www.bnf.fr/sites/default/files/2018-11/ref_num_doc_opaques_v2.pdf</td></tr><tr><td>Référentiel de format de fichier image, version 2</td><td>Référentiel décrivant le profil d'application BnF pour le format JPEG 2000 de numérisation</td><td>https://www.bnf.fr/sites/default/files/2018-11/ref_num_fichier_image_v2.pdf</td></tr><tr><td>Référentiel de traitement des tables</td><td>Référentiel décrivant le format tdmNum de la BnF</td><td>https://www.bnf.fr/sites/default/files/2018-11/referentiels_num_tdm.pdf</td></tr><tr><td>Référentiel de format de fichier audio, version 1</td><td>Référentiel décrivant le profil d'application BnF pour les formats FLAC, BWF et DSD de numérisation</td><td>https://www.bnf.fr/sites/default/files/2022-09/referentiel_format_fichier_audio_V1.pdf</td></tr><tr><td>Référentiel de format de fichier vidéo, version 1</td><td>Référentiel décrivant le profil d'application BnF pour les formats MP4 AVC AAC et MKV FFV1 FLAC de numérisation</td><td>https://www.bnf.fr/sites/default/files/2024-09/Referentiel_format_fichierVideo.pdf</td></tr></table>

## 1.4. Glossaire

Les termes listés ci-dessous sont entendus dans leur acceptation communément admise au sein de la communauté internationale de la préservation numérique.

Certains d'entre eux proviennent de la norme OAIS citée en section 1.3 « Documents applicables et de référence » ci-dessus. La forme de leur définition diffère parfois légèrement de celle donnée dans la norme. Comme dans cette dernière, les termes OAIS sont identifiés dans le corps du document par une majuscule initiale (ex. : « le Paquet d'informations »). Une connaissance des notions de base (section 2) et du modèle fonctionnel de la norme OAIS (section 4.1) est conseillée mais non indispensable pour la compréhension du présent document.

<table><thead><tr><td>Libellé</td><td>Terme anglais correspondant, le cas échéant</td><td>Définition</td></tr></thead><tbody><tr><td>Analyse (du fichier)</td><td>/</td><td>Ensemble des opérations de préservation (identification, caractérisation, validation) visant à extraire et/ou calculer des métadonnées à partir d'un fichier.</td></tr><tr><td>Caractérisation (du fichier)</td><td>Characterisation</td><td>Opération de préservation consistant à analyser le contenu d'un fichier afin d'obtenir, par simple lecture ou par calcul, des informations sur le contenu, la forme et/ou l'historique du fichier. Cette opération englobe celle d'extraction de métadonnées.</td></tr></tbody></table>
<figure><img src="image_8.png" /></figure>

<table><tr><td>Codec</td><td>Codec</td><td>Dispositif matériel ou logiciel permettant de mettre en œuvre l'encodage ou le décodage d'un flux de données numériques. Autrement dit un codec prend en entrée des Données encodées dans un Format A et donne en sortie des Données encodées dans un Format B. Appliqué dans un sens on parle d'encodage ; dans l'autre on parle de décodage.<br/>Si une opération d'encodage suivie d'une opération de décodage sur des Données X reproduit exactement ces Données X, on parle d'un codec sans perte ; sinon on parle d'un codec avec pertes.<br/>Par commodité, on utilisera parfois le terme de « codec » (par opposition à celui de « format conteneur ») pour désigner les règles d'encodage d'un flux de données à l'intérieur d'un fichier.</td></tr><tr><td>Communauté d'utilisateurs cible</td><td>Designated community</td><td>[Terme provenant de la norme OAIS] groupe(s) d'utilisateurs identifié(s) par l'institution de conservation pour le(s)quel(s) celle-ci effectue son activité de préservation.</td></tr><tr><td>Contenu numérique</td><td>Digital content</td><td>Ensemble de données présentant une cohérence intellectuelle et/ou technique suffisante pour justifier un traitement individualisé et/ou pour satisfaire le besoin d'un e utilisateur ice.<br/>L'usage de « contenu » s'est développé au cours des dernières décennies pour signifier, avec un terme distinct, le « document » dans sa forme propre au numérique (support, structure, médiation, diffusion). Il est employé ici de manière équivalente à « document numérique »<fnref n="1" />.</td></tr><tr><td>Dérivation</td><td>Derivation</td><td>Opération consistant à produire une copie des données modifiée pour satisfaire les besoins d'un usage particulier.</td></tr><tr><td>Document numérique</td><td>Digital document</td><td>Voir : Contenu numérique</td></tr><tr><td>Données</td><td>Data</td><td>[Terme défini par la norme OAIS] « Représentation réinterprétable formalisée de l'information, adaptée à la communication, à l'interprétation ou au traitement. Exemple : une séquence de bits, un tableau de nombres, les caractères d'une page, un enregistrement de paroles ou un échantillon de roche lunaire ».</td></tr></table>

<footnote n="1">¹ France Terme définit ainsi « l'édition de contenu » comme « l'activité qui consiste à sélectionner, organiser et publier en ligne des documents textuels, iconographiques et audiovisuels sur un thème donné. »</footnote>
<figure><img src="image_9.png" /></figure>

<table><tr><td>Extraction de métadonnées</td><td>Metadata extraction</td><td>Opération de préservation consistant à extraire, par lecture du fichier, des informations sur le contenu, la forme et/ou l'historique du fichier.</td></tr><tr><td>Fonds</td><td>Fonds</td><td>Ensemble de documents de toute nature constitué de façon organique par un producteur dans l'exercice de ses activités et en fonction de ses attributions<fnref n="2" />.</td></tr><tr><td>Format conteneur</td><td>Container format</td><td>Format de données adapté au stockage et/ou au transfert des Données dans un ordinateur. Un format conteneur est généralement un moyen de combiner plusieurs flux de Données dans un seul flux. Par exemple on peut combiner une piste audio avec une piste vidéo dans un conteneur MP4. Il peut arriver que l'on stocke un flux de données sans l'embarquer dans un format conteneur.</td></tr><tr><td>Format de données</td><td>Data format</td><td>Ensemble des règles d'encodage d'une information sous forme de données binaires interprétables par un ordinateur.</td></tr><tr><td>Identification (du format)</td><td>Identification</td><td>Opération de préservation représentant l'étape préliminaire de l'analyse de fichier. Elle consiste à déterminer le format d'un fichier. On peut considérer qu'il s'agit d'une forme sommaire de caractérisation.</td></tr><tr><td>Information</td><td>Information</td><td>[Terme défini par l'OAIS] « Toute connaissance pouvant être échangée. Lors de l'échange, elle est représentée par des données. Exemple : une séquence de bits (les données) accompagnée d'une description permettant d'interpréter cette séquence de bits comme des nombres représentant des mesures de températures en degrés Celsius. » L'Information est ce que l'on cherche à pérenniser.</td></tr><tr><td>Intention de préservation</td><td>Preservation intent</td><td>Ensemble des propriétés d'un contenu numérique que l'institution de conservation considère, tacitement ou explicitement, comme « signifiantes » et qu'elle s'efforce de préserver sur le long terme.</td></tr><tr><td>Métadonnées de caractérisation</td><td>/</td><td>Métadonnées extraites ou calculées par un outil logiciel à partir d'un fichier. Il peut s'agir de métadonnées descriptives, techniques et/ou de provenance.</td></tr><tr><td>Métadonnées de provenance</td><td>Provenance metadata</td><td>Métadonnées documentant l'historique de production, de transfert et de préservation d'un fichier.</td></tr><tr><td>Métadonnées descriptives</td><td>Descriptive metadata</td><td>Métadonnées documentant le contenu informationnel d'un fichier.</td></tr><tr><td>Métadonnées techniques</td><td>Technical metadata</td><td>Métadonnées documentant la forme et les caractéristiques techniques d'un fichier.</td></tr><tr><td>Mesures techniques de protection</td><td>Digital Rights Management</td><td>Dispositifs visant à contrôler l'usage de contenus numériques.</td></tr></table>

<footnote n="2">² Cette définition est tirée du *Dictionnaire de terminologie archivistique*, Direction des archives de France, 2002, disponible en ligne sur <https://francearchives.fr/file/4f717e37a1befe4b17f58633cbc6bcf54f8199b4/dictionnaire-de-terminologie-archivistique.pdf> (consulté le 22 mars 2021).</footnote>
<figure><img src="image_10.png" /></figure>

<table><tr><td>Norme technique</td><td>Technical standard</td><td>Référentiel établi par un organisme de normalisation officiellement agréé ou reconnu internationalement. Comme l'anglais n'a qu'un seul terme « Standard », on peut aussi utiliser le terme de standard de jure.<br/>Voir aussi « Standard »</td></tr><tr><td>Paquet d'informations</td><td>Information Package</td><td>[Terme provenant de la norme OAIS] Conteneur abstrait réunissant les contenus numériques faisant l'objet de la préservation et l'ensemble des ressources nécessaires à leur compréhension, réutilisation et restitution sur le long terme.</td></tr><tr><td>Préservation du train d'octets</td><td>Bit-level preservation</td><td>Activité consistant pour une institution de conservation à garantir l'intégrité des données, c'est-à-dire la suite fidèle de 0 et de 1. On parle aussi de « stockage sécurisé ».</td></tr><tr><td>Préservation sémantique</td><td>Functional / logical preservation</td><td>Par opposition à la simple préservation du train d'octets, activité consistant pour une institution de conservation à assurer sur le long terme l'accessibilité, l'utilisabilité et la compréhensibilité de l'information que les données véhiculent. La préservation sémantique inclut la préservation du train d'octets. Le terme « préservation (numérique) » renvoie à cette activité.</td></tr><tr><td>Producteur</td><td>Producer</td><td>[Terme provenant de la norme OAIS] Tout agent qui fournit des informations à préserver à l'institution de conservation.</td></tr><tr><td>Profil d'application (d'un format)</td><td>Application profile</td><td>Ensemble des règles spécifiques à une institution déterminant les contraintes additionnelles à la spécification qu'elle applique aux fichiers d'un format donné.</td></tr><tr><td>Propriété significante</td><td>Significant property</td><td>Propriété du contenu numérique que l'institution de conservation souhaite préserver sur le long terme afin de satisfaire les besoins de sa Communauté d'utilisateurs cible. Le caractère signifiant d'une propriété résulte d'un choix subjectif, tacite ou explicite, de l'institution de conservation.<br/>Terme correspondant à la notion OAIS de « Propriété d'information de transformation »</td></tr><tr><td>Référentiel de numérisation</td><td>/</td><td>[Terme spécifique à la BnF] Document qui détaille les attentes de la BnF quant aux livrables d'opérations de numérisation.</td></tr><tr><td>Spécification (d'un format)</td><td>Specification</td><td>Documentation complète décrivant la structure d'un format.</td></tr><tr><td>Standard technique</td><td>Technical standard</td><td>Référentiel établi par un industriel pionnier ou par une association professionnelle. Comme l'anglais n'a qu'un seul terme « Standard », on utilise aussi le terme de standard de fait ou de facto.<br/>Voir aussi « Norme »</td></tr></table>
<figure><img src="image_11.png" /></figure>

<table><tr><td>Stratégie (ou trajectoire) de pérennisation</td><td>Preservation strategy</td><td>Méthode envisagée par l'institution de conservation pour préserver l'information contenue dans un fichier d'un format donné.</td></tr><tr><td>Système ouvert d'archivage d'information</td><td>Open Archival Information System</td><td>Ce terme désigne ici la norme OAIS citée en section 1.3 « Documents applicables et de référence ».</td></tr><tr><td>Transformation</td><td>Transformation</td><td>[Terme provenant de la norme OAIS] Toute opération modifiant les données numériques pour assurer la préservation de la totalité, ou au moins d'une portion conséquente, de l'information qu'elles véhiculent. Elle comprend mais ne se limite pas à ce que l'on nomme dans le langage courant « conversion de format ».<br>On notera que le terme « migration » est souvent utilisé pour évoquer ce type d'opération dans le sens spécifique d'une conversion de format à but de préservation.</td></tr><tr><td>Type de contenu</td><td>Content type</td><td>Catégorie de contenus numériques présentant des propriétés signifiantes communes relatives à leur usage et leur mode de représentation de l'information. Cette catégorisation est issue d'un consensus obtenu au sein de la BnF ; elle peut être plus ou moins précise selon le niveau de connaissance, de maturité et de capacité de l'institution.</td></tr><tr><td>Validation (de fichier)</td><td>Validation</td><td>Opération de préservation consistant à évaluer la conformité d'un fichier au regard de sa spécification.</td></tr></table>

## 1.5. Abréviations

<table><thead><tr><td>Sigle ou abréviation</td><td>Développement</td></tr></thead><tbody><tr><td>BnF</td><td>Bibliothèque nationale de France</td></tr><tr><td>DRM</td><td>Digital Rights Management</td></tr><tr><td>MTP</td><td>Mesures techniques de protection (forme française de DRM)</td></tr><tr><td>OAIS</td><td>Open Archival Information System</td></tr></tbody></table>

## 2. Principes directeurs de la politique

Cette section décrit la logique qui a guidé la rédaction de cette politique. Elle fournit du contexte à la section suivante, justifie les choix qui y sont fait et décrit comment ces derniers sont mis en pratique. Les sous-sections suivantes présentent l'approche de la BnF pour construire sa politique de formats.

- La sous-section 2.1 introduit les **problématiques liées à la préservation numérique** et la place qu'y occupe la connaissance et la veille sur les formats de données.

- La sous-section 2.2 justifie l'élaboration et la publication d'une telle politique, présente **le périmètre de ce document et ses potentiel le s lecteur ice s.**

- La sous-section 2.3 fait état des **différents usages du terme « format »** et de l'impossibilité d'aboutir à une définition complète et consensuelle ; elle décrit les choix des rédacteur ice s sur ces différentes acceptations dans les différentes parties du document.

- Du fait qu'il existe souvent, dans le cas d'images fixes ou animées voire de sons, un rapport direct entre l'algorithme de compression utilisé et une perte d'information et que la soutenabilité financière et environnementale de la préservation numérique est liée à la compacité des données, on dédie la section 2.4 à une présentation des **problématiques liées à la compression**.
<figure><img src="image_12.png" /></figure>

- La BnF a besoin de connaître les **propriétés des contenus numériques** pour réaliser différentes opérations : la sélection, le catalogage, la restitution, etc. La BnF met donc en œuvre des outils pour les extraire automatiquement et les fournir aux agent s impliqué s dans ces tâches. En outre, certaines de ces propriétés ont un statut particulier : elles sont jugées **signifiantes**, et doivent donc être examinées avec une attention particulière car la BnF s'efforce de les maintenir sur le long terme. La question des propriétés est abordée en sous-section 2.5.

- Au sein d'un même type de contenu, les formats peuvent varier considérablement, ainsi que les fonctionnalités et les usages qu'ils permettent, selon l'**étape dans le cycle de production** des contenus. On consacre à cette notion la sous-section 2.6.

- La sous-section 2.7 mentionne quelques cas où la BnF déroge à sa politique et évoque également les **différentes pratiques** en place qui ne sont pas mentionnées dans ce document ;

- La sous-section 2.8 aborde les questions que la BnF se pose lorsqu'il s'agit d'évaluer les risques liés à la préservation de contenus dans l'un ou l'autre des formats. Elle évoque à la fois les **critères objectifs**, pour lesquels l'analyse est valable quel que soit le contexte institutionnel, et les **critères subjectifs** qui dépendent des capacités et des objectifs de l'institution de conservation ;

- Afin de déterminer à quel format des données se conforment et quelles sont leurs propriétés, la BnF applique des **méthodes d'analyse** spécifiques au versement des données : l'identification, la caractérisation et la validation. Ces méthodes sont décrites de manière générale en sous-section 2.9.

- Enfin, la section 2.10 « Stratégies de préservation » envisage les **stratégies de la BnF** lorsque les contenus ne se trouvent pas, ou plus, dans un format correspondant à sa politique.

## 2.1. Contexte

Dans le cadre de ses missions de collecte, conservation, enrichissement et communication du patrimoine documentaire national, la Bibliothèque nationale de France (BnF) a développé des techniques appropriées de conservation curative ou préventive. De même qu'elle surveille l'état de ses collections physiques, elle réalise une veille technologique sur les formats d'encodage des fichiers. La donnée numérique étant stockée sur support sous une forme binaire – une série de « 0 » et de « 1 » –, la préservation numérique consiste à garantir à la fois l'intégrité des données (préservation du train d'octets) et l'accessibilité, la compréhensibilité et l'utilisabilité des données pour une communauté d'utilisateurs cible (préservation « sémantique »). La connaissance du format d'encodage est donc une condition nécessaire si ce n'est suffisante de la transformation des données en information accessible, compréhensible et utilisable par la communauté d'utilisateurs cible – le public cible de l'institution.

Au-delà des quelques dizaines de formats les plus courants, la variété de formats utilisés par les producteurs de données est considérable, particulièrement au sein des communautés scientifiques spécialisées. Une bonne partie d'entre eux est susceptible de se retrouver dans les collections numériques des institutions de conservation. La diversité des formats augmente d'autant les risques pesant sur les capacités de telles institutions à restituer correctement leurs collections. Parmi ces risques multiples, on peut citer :

- l'incapacité à identifier le format et donc l'outil de restitution adapté ;

- la disparition de logiciels de lecture ou leur indisponibilité en raison de leur coût, de la politique de l'entreprise qui les développe ou de leur mode d'achat ;

- l'utilisation d'outils inadaptés ou mal employés donnant lieu à une restitution non fidèle, ou à la perte d'information involontaire à la suite d'une transformation mal maîtrisée.

Afin de réduire ces risques et l'investissement de l'institution (achat et maintenance de matériel, de logiciels, de normes, développement et maintien de compétences, etc.), il est donc souhaitable, autant que faire se peut, de se limiter à une liste de formats maîtrisés, en adoptant les méthodes suivantes :

- en tant qu'institution commanditaire, la BnF veille à choisir avec soin les formats dans lesquels elle demande la production de données.

- lorsque la BnF acquiert des données de producteurs, elle négocie la remise de celles-ci dans un format maîtrisé.

- lorsque la BnF hérite de données dans un format qu'elle ne peut choisir, elle envisage en cas de risque avéré portant sur elles de les convertir dans un format maîtrisé.

## 2.2. Objet du document et lectorat attendu

L'objectif de la BnF dans le présent document est de formaliser les principes de politique de l'institution concernant la forme des données numériques dont elle a la charge. Ces principes s'accompagnent de la liste des formats de données pour lesquels elle s'engage à maintenir la compétence et les outils nécessaires à leur restitution, compréhension et exploitation, et à faire bénéficier ses partenaires de son expertise. Le présent document est donc une composante essentielle de la politique de préservation numérique de la BnF.
<figure><img src="image_13.png" /></figure>

Ce document présente également un intérêt pour :

- les institutions patrimoniales conservant des données numériques qui souhaiteraient développer une politique formats ou comparer la leur à celle de la BnF ;

- les donateurs potentiels soucieux de fournir leurs créations sous une forme maîtrisable par la BnF ;

- plus généralement, tout producteur de données intéressé par leur préservation, qu'il soit susceptible ou non de les confier à la BnF.

Les fiches Format, en section 4, s'adressent à un public plus spécialisé. Elles doivent permettre aux personnels chargés de la production et de la préservation numériques de déterminer l'adéquation des formats décrits aux besoins et aux moyens de leur institution. En outre, elles décrivent les paramètres du profil d'application BnF du format qui semblent essentiels à celle-ci dans une perspective de préservation à long terme afin que les institutions ne disposant pas de personnel compétent puissent connaître et éventuellement adopter les choix de la BnF.

Toute question portant sur ce document pourra être adressée à formats.num@bnf.fr.

## 2.3. Le « format », une notion équivoque

Dans le domaine informatique, on choisira de définir le terme « format » comme l'ensemble des conventions visant à encoder (ou « sérialiser ») une information sous une forme binaire. On préfère ici le terme « format de données », qui permet de caractériser :

- les formats de fichier ;

- les formats de flux (ou « codecs »), lorsque ceux-ci sont embarqués dans un conteneur, notamment audiovisuel, ou transmis via un réseau ;

- les formats consistant en une arborescence et en plusieurs fichiers interdépendants nécessaires à la restitution du contenu (DVD, rushes bruts issus de caméras, etc.).

Néanmoins, les utilisations du terme « format » (informatique) dans d'autres contextes varient, et ce pour plusieurs raisons :

- On l'emploie couramment pour indiquer le format conteneur d'un fichier, sans précision sur le format des flux contenus dans ce conteneur (par exemple, « le format AVI » - les formats de flux audio, vidéo et sous-titres - ou « codecs » - employés dans ce conteneur n'étant alors pas connus) ;

- Dans d'autres cas, on l'utilise pour désigner l'algorithme de compression d'un signal embarqué dans un fichier (par exemple, « le format MP3 » ou « le format JPEG ») ;

- Le nommage des formats correspond parfois à une volonté commerciale ou à des nécessités de communication des concepteur ice s davantage qu'à une réalité technique - ainsi, Apple a nommé « ProRes RAW » un format de capture pour le rapprocher de la famille de formats « ProRes » alors qu'ils sont fondés sur des structures très différentes ;

- Dans certains contextes et pour certains usages, il est nécessaire d'apporter des précisions au nom usuel d'un format conteneur ou d'un format de flux attribué par leurs concepteur ice s ; on citera notamment une version (par exemple : « EPUB 3 ») ou un « profil » spécifique (par exemple : ProRes 422 HQ) ;

- Enfin, une institution donnée peut ajouter des exigences supplémentaires, spécifiques à elle (ainsi, on trouve sous le terme de « format » un ensemble d'exigences telles que « TIFF non compressé RVB 24 bits »).

Par ailleurs, les rapports entre les formats sont variables : certains sont inspirés les uns des autres (ainsi, le format de sous-titres WebVTT est inspiré par le format SRT), d'autres sont des spécialisations d'un autre format, et ajoutent donc des contraintes supplémentaires spécifiques à un format existant dont ils sont également des instances valides (ainsi, un fichier MUSX est également un fichier ZIP valide).

Le niveau de précision est donc très variable, d'où les différences constatées entre les registres de formats tels que PRONOM et les Format descriptions de la Bibliothèque du Congrès. On a, dans ce document, fait les choix suivants :

- On mentionne systématiquement dans la section 3 le format conteneur et le format du (des) flux contenu(s) (codecs) ; en outre, on y ajoute des précisions de nature différente (version, notamment) lorsqu'elles semblent nécessaires à la préservation à long terme (ainsi, on pourra y lire « EPUB 3 sans DRM »).

- Les exigences ou les préférences de la BnF concernant des caractéristiques des données communes à tous les types de contenus, et non à des données dans un format particulier, sont décrites dans les parties introductives de chaque sous-section de la section 3. Ainsi, la préférence de la BnF pour des images dans un espace couleur RVB est mentionnée dans la sous-section 3.1, « Images fixes ».

- Les fiches format correspondent généralement soit à un format conteneur, soit à un format de flux (codec), sauf lorsqu'il existe un rapport évident entre le format conteneur et le format de flux (format conteneur MPEG-2 et format de flux vidéo H.262, par exemple). En outre, les fiches mentionnent dans la section Version les variantes, versions et profils de ce même format, et en section Relation à d'autres
<figure><img src="image_14.png" /></figure>

formats les rapports à d'autres formats – inspirations, prédécesseurs et successeurs, relation de spécialisation à un format plus générique.

- Les exigences spécifiques à la BnF, dans le cas où elle peut se permettre d'en imposer, sont décrites dans la section Usage et présence dans les collections de la BnF. Dans le cas de formats également utilisés pour la numérisation ou dématérialisation, ces exigences forment un **profil d'application** complet qui n'est pas décrit dans les fiches mais dans des référentiels de numérisation dédiés.

## 2.4. Compression avec ou sans perte

La compression, qui permet d'encoder de manière compacte un signal, peut être réalisée avec ou sans pertes d'information. La compression sans perte, qui se borne à éliminer les informations redondantes, est réversible : il est possible d'inverser le processus et d'obtenir strictement la même donnée qu'avant le processus de compression. La compression avec pertes, qui supprime une partie de l'information jugée moins importante en se fondant généralement sur l'étude des capacités sensorielles humaines, est irréversible.

Dans l'évaluation des formats par la BnF, un des critères les plus importants<fnref n="3" /> est la compacité, dans un souci de soutenabilité financière et écologique. Autant que possible, la BnF donne donc la priorité aux formats qui disposent d'une compression efficace. Elle s'oriente vers des algorithmes de compression sans perte pour ses collections les plus riches en informations pertinentes ou de plus grande valeur (originaux précieux, fragiles, etc.) et vers des algorithmes de compression avec pertes pour les collections présentant des risques moindres. La compression implique une suppression de la redondance, ce qui a pour conséquence qu'une altération des données peut avoir un impact plus important sur un contenu compressé que sur son équivalent sans compression. Consciente de ce risque, la BnF en limite l'impact et la probabilité par les mesures suivantes :

1. La multiplication des copies afin de s'assurer de disposer d'une copie intègre en cas d'altérations et le calcul d'empreinte numérique périodique afin de détecter de telles altérations ;

2. La recommandation ou l'exigence de mécanismes de robustesse, tels que les marqueurs internes de resynchronisation.

Il est à noter cependant que la compression avec pertes limite généralement l'usage que la BnF peut avoir des contenus dans le futur. Ainsi, les algorithmes de compression inter-trames généralement employés par le format AVC / H.264 ne permettent pas de réaliser des opérations de post-production ou de restauration. De même, la BnF ne pourrait réaliser, si tant est qu'elle le veuille, d'opération d'édition sur des photographies numériques qu'elle aurait reçu au format JFIF (JPEG).

Il est également utile de signaler que l'utilisation d'algorithmes de compression sans perte (réversibles) ne garantit pas que l'intégralité du contenu du fichier source se retrouve dans le fichier compressé. En effet, les outils de conversion traitent bien souvent le flux principal attendu et omettent les contenus secondaires (métadonnées internes, extensions propriétaires, visuels, etc.). Les institutions de conservation sont donc invitées à porter une attention particulière sur la capacité des outils de conversion vers le format choisi à migrer également les contenus additionnels du fichier d'origine.

Le choix d'un algorithme de compression est fait au cas par cas, en prenant en compte la position des institutions de conservation internationales et en définissant, dans le cas d'algorithmes de compression avec pertes, un paramétrage assurant que la perte reste acceptable vis-à-vis de l'usage prévisible du contenu.

## 2.5. Propriétés des contenus numériques

Le format de fichier est une information nécessaire mais non suffisante pour assurer la préservation à long terme des contenus numériques. D'autres propriétés doivent être obtenues ou calculées afin d'assurer les tâches dévolues à la BnF et à toute institution patrimoniale chargée de préserver des contenus numériques. On distinguera, dans la suite de ce document, deux catégories de propriétés associées :

- Des propriétés du contenu de haut niveau, dites « signifiantes » : ces propriétés ont été considérées par la BnF comme devant être conservées sur le long terme, quelles que soient les interventions à but de préservation qui auront été effectuées sur les données<fnref n="4" /> ;

- Des propriétés concrètes des fichiers représentant ces contenus, qui peuvent généralement être extraites automatiquement et permettent d'évaluer si les propriétés signifiantes du contenu original ont

<footnote n="3">³ Pour la liste complète des critères d'évaluation d'un format, on se reportera à la section 2.8.</footnote>

<footnote n="4">⁴ La littérature professionnelle sur le sujet des « propriétés signifiantes » est importante. Dans leur livre *Le soin des choses : Politique de la maintenance* (Paris : Éd. La Découverte, 2022), Jérôme Denis et David Pontille affirment ainsi le principe suivant : « Faire durer les choses revient à définir en pratique ce qui compte en elle, identifier ce dont il faut concrètement s'occuper si l'on veut s'assurer que c'est bien toujours la **même** chose qui dure. »</footnote>
<figure><img src="image_15.png" /></figure>

effectivement été préservées à la suite d'une intervention. Ces propriétés concrètes peuvent, elles, changer
dans certains cas bien précis.

Ainsi, la propriété « Qualité du signal » est jugée signifiante par la BnF, qui s'engage à la maintenir sur le long
terme. Cette propriété est associée aux propriétés concrètes « Débit », « Profondeur d'échantillonnage » et »
Fréquence d'échantillonnage ». Ces propriétés sont nécessaires pour juger des efforts de l'institution pour
maintenir la propriété de qualité du signal, mais elles peuvent changer. Ainsi, l'institution pourrait décider une
transformation des contenus sonores codés en DSD64 (1 bit et 2.8 MHz) vers un signal PCM 24 bits et 96
kHz. Les propriétés concrètes ont changé, mais l'institution considère que la propriété signifiante de qualité du
signal a été maintenue.

La logique générale d'extraction des propriétés concrètes, également nommée « caractérisation », est décrite à la section 2.9.2 ci-dessous. En outre, dans chaque section décrivant un type de contenu, on trouvera un tableau intitulé « Propriétés du contenu » qui présente les propriétés signifiantes actuellement définies par la BnF et les propriétés concrètes associées.

L'analyse des propriétés de contenus numériques éligibles à la préservation à long terme est nécessaire afin de
satisfaire notamment les objectifs suivants :

- **Sélection** : pour évaluer la qualité et prendre des décisions d'acquisition (acceptation, rejet, sélection d'une version au détriment d'une autre) – pour un fichier MPEG-1/2 layer III (MP3), le débit permet de distinguer des fichiers compressés à 64 kb/s, fortement dégradés, de fichiers compressés à 320 kb/s, dont la dégradation est limitée ;

- **Identification de l'information embarquée** : pour identifier des flux, principaux ou additionnels, embarqués dans les fichiers, que les processus pourraient omettre, restituer fautivement voire supprimer. Ainsi, le nombre d'images présentes dans un fichier TIFF doit être connu afin de prendre des décisions adaptées, qu'il s'agisse de la transformation des contenus ou de l'évolution des environnements de restitution afin de prendre en compte l'éventualité de fichiers multi-images ;

- **Limitation des risques** : pour évaluer le respect d'exigences de préservation – ainsi, dans le cas d'un fichier JPEG 2000, la détection de l'utilisation des marqueurs de début et fin de paquet permet de rejeter des fichiers dont la robustesse serait insuffisante ;

- **Catalogage / rédaction d'inventaires** : pour permettre la production d'une description destinée à l'utilisateur ice final e ;

- **Restitution** : pour assurer un rendu fidèle du contenu, et en particulier pour repérer des dépendances qu'il faudrait collecter – pour un fichier DOCX, par exemple, la référence à des polices dont on ne disposerait pas et dont l'absence affecterait le rendu ;

- **Dérivation** : pour paramétrer une dérivation afin de satisfaire un usage particulier – ainsi, l'information de disposition spatiale de toutes les pistes audio d'un contenu vidéo multicanal est nécessaire afin de produire un fichier multiplexé utilisable ;

- **Contrôle de la transformation** : pour s'assurer, lorsqu'une intervention sur les données est nécessaire, qu'aucune perte d'information jugée importante n'a eu lieu à la suite de l'opération.

## 2.6. Étapes du cycle de production des contenus numériques

Afin de clarifier les usages possibles de données dans un format spécifique, la BnF propose d'envisager chaque
type de contenu selon quatre grandes étapes du cycle de vie de leur production. On distingue ainsi :

1. L'étape de capture, où les éléments constitutifs de l'objet final sont produits ou récupérés ;

2. L'étape de création (correspondant au terme anglais *authoring*), où les éléments sont modifiés, optimisés, agencés ou combinés ;

3. L'étape de finalisation, où une version aboutie de haute qualité et disposant de tous les éléments nécessaires à la production de dérivés est produite<fnref n="5" /> ;

4. L'étape de diffusion, où des versions limitées à un usage donné, sont dérivées pour être distribuées à un e
utilisateur ice final e.

<footnote n="5">⁵ Dans le domaine de la vidéo, on parle généralement de formats « mezzanine ». C'est également à cette étape qu'est produit ce que l'on nomme généralement « master », bien que cette appellation soit équivoque et donc à utiliser avec précautions.</footnote>
<figure><img src="image_16.png" /></figure>

<figure><img src="image_17.png" /><figcaption>Figure 1. Schématisation des étapes du cycle de production</figcaption></figure>

L'intérêt de ce cadre général tient dans le fait que chaque étape peut avoir des formats et des paramétrages spécifiques qui détermineront les usages permis à l'institution de conservation et à son public à l'avenir. Ainsi, une photographie numérique encodée avec une profondeur d'échantillonnage de 16 bits par couche (48 bits par pixel, pour une image dans l'espace couleur RVB) permettrait à l'avenir de corriger l'exposition, à l'inverse d'une photographie encodée en 8 bits par couche. En conséquence, les choix de formats et de paramétrage faits par les institutions de conservation, lorsqu'elles sont en mesure de les faire, doivent être fondés sur des usages qu'elles s'autorisent ou non. Dans la section « Liste des formats » ci-dessous, des sections dédiées par domaine distingueront, lorsque cela est pertinent, les formats spécifiques à l'une ou l'autre de ces étapes.

On signalera également que les institutions de conservation peuvent être plus prescriptives quant aux contenus collectés dans les deux dernières étapes du cycle de production ; à l'inverse, si elles souhaitent collecter des contenus dans les deux premières étapes, elles devront s'adapter aux modes de production adoptés par les créateur ice s.

On peut, pour illustrer ce schéma, l'appliquer aux photographies numériques :

- L'étape de capture correspond à la prise de vue initiale ; les formats de fichier sont alors ceux que l'on trouve en sortie directe de l'appareil (formats dits « *raw* » : .crw, .nef, .dng, etc. – bien que certains appareils grand public produisent exclusivement des images déjà compressées en JPEG) ;

- L'étape de création correspond à l'édition dans un logiciel de retouche photographique ; on trouve alors des formats de projet liés à un logiciel spécifique (PSD pour Photoshop, XCF pour Gimp, etc.) ;

- L'étape de finalisation correspond à l'export dans un format de qualité maximale, adapté à de nombreux usages et transmissible à de potentiels distributeurs ; le format le plus couramment employé est alors le TIFF non compressé ou avec une compression sans perte ;

- L'étape de diffusion correspond à la fourniture de l'image à un e utilisateur ice final e, dans un format compressé, éventuellement avec une définition réduite ; on classe dans cette catégorie les formats tels que JFIF (JPEG), PNG, WEBP, etc.

Ce schéma est donc utile afin d'articuler la politique d'acquisition de contenus de l'institution de conservation et sa politique de formats. Néanmoins, son application variera d'un type de contenu à l'autre.

## 2.7. Une politique, des pratiques

Le présent document vise à formaliser la politique de la BnF concernant les formats de données pour la préservation, c'est-à-dire l'ensemble des choix qu'elle a faits en connaissance de cause et après des études ou l'accumulation d'une expérience de longue durée. Pour autant, les pratiques de la BnF dans ce domaine ne se limitent pas à celles décrites ici. Ainsi, on trouvera en section 2.10.1.2 ci-dessous quelques exemples de pratiques appliquées à des formats qui ne figurent pas dans les listes de ce document. Néanmoins, ces pratiques ont vocation à être progressivement consolidées et à intégrer la politique générale lorsque la BnF jugera qu'elles sont suffisamment étayées.
<figure><img src="image_18.png" /></figure>

Certains autres cas particuliers peuvent amener la BnF à déroger, temporairement ou durablement, à la politique décrite dans le présent document :

* pour les données menacées de perte dans un délai qui ne permet pas à la BnF de mener une instruction suffisamment approfondie, et en attente de cette dernière ;

* pour les données qui n'appartiennent pas à la BnF, en particulier lorsqu'elle fournit un service de préservation pour un tiers<fnref n="6" /> et que ce dernier dispose d'une maîtrise supérieure à celle de la BnF sur les contenus ;

* pour les données qui ne sont pas l'objet principal de la préservation<fnref n="7" />, c'est-à-dire les dérivés, éléments d'accompagnement et documentation diverse

* lorsque la BnF traite globalement un fonds d'archives numériques sans homogénéité dans le type de contenu et le format des données reçues.

Dans certains de ces cas, la stratégie adoptée par la BnF peut se limiter à garantir l'intégrité des données (« préservation du train d'octets »).

## 2.8. Critères de pérennité pour l'évaluation d'un format de données

La capacité des institutions de conservation à restituer fidèlement le patrimoine numérique et à en conserver l'utilisabilité repose sur un certain nombre de facteurs dépendants du format d'encodage dans lequel les données sont enregistrées. Dans le but d'évaluer les formats les mieux adaptés à la conservation à long terme, la BnF a élaboré la liste de critères suivante, à la suite d'autres institutions de conservation à travers le monde<fnref n="8" />. Cette liste n'est pas classée par ordre d'importance.

On distinguera douze critères objectifs et deux critères subjectifs. Ces deux derniers critères sont fondamentaux dans l'évaluation de la capacité de l'organisation à conserver ses données numériques et rappellent que la pérennité n'est pas une caractéristique intrinsèque d'un format mais découle de l'engagement de l'institution qui les utilise à disposer d'outils de lecture, d'analyse, de traitement, et de transformation, ainsi que des compétences nécessaires à leur utilisation.

Afin d'élaborer sa propre politique sur les formats pour la préservation numérique, chaque organisation est invitée à pondérer l'évaluation des critères objectifs à l'aune de ses priorités. Développer une politique sur les formats consiste à expliciter et justifier le compromis entre les objectifs définis par les critères mentionnés ci-dessous. Ainsi, si une organisation dispose déjà d'une forte compétence en interne et d'un outillage adéquat, mais que son budget destiné à l'augmentation de ses capacités de stockage est limité, elle valorisera sans doute la compacité (CPO-COM) du format et réduira l'importance de la complexité (CPO-SIM).

Le présent document résulte donc de la démarche spécifique de la BnF, incluant l'évaluation pondérée des formats selon les deux critères subjectifs. Il présente les formats qui demandent un investissement raisonnable dans une optique de préservation à long terme, et reflète l'état actuel des connaissances, des politiques, des pratiques et des capacités de la BnF. Il ne prétend donc ni à l'exhaustivité ni à l'universalité.

### 2.8.1. Critères objectifs

Afin d'y faire référence plus aisément, ces critères sont identifiés par une série de lettres : « CPO » (pour « Critère de pérennité objectif ») et les trois premières lettres du terme le plus significatif.

<footnote n="6">⁶ Voir sur le site institutionnel de la BnF la page « Prestation d'archivage numérique », disponible sur https://www.bnf.fr/fr/prestation-archivage-numerique, (consulté le 31 mars 2021).</footnote>

<footnote n="7">⁷ Ces données sont nommées « Objets-données de contenu » par l'OAIS.</footnote>

<footnote n="8">⁸ On en trouvera des exemples en section 5.2 du présent document.</footnote>
<figure><img src="image_19.png" /></figure>

<table><thead><tr><td>Identifiant et intitulé(s)</td><td>Définition</td><td>Justification</td></tr></thead><tbody><tr><td>CPO-SOC.<br>Communauté d'utilisateurs / Sociabilité</td><td>Le format est-il largement utilisé dans sa communauté cible ? Par le grand public ? Par les institutions de conservation ?</td><td>L'utilisation d'un format au sein de sa communauté est un indice de son adaptation aux besoins spécifiques de cette communauté. Un format également utilisé au-delà des institutions de conservation fournit des garanties supplémentaires, car les moyens de telles institutions pour maintenir un format sont limités comparés à ceux des industries culturelles.<br>Ce critère est lié à celui des outils disponibles : plus la communauté d'utilisateurs est conséquente, plus elle est susceptible d'avoir développé ou fait développer des outils adaptés.</td></tr><tr><td>CPO-DOC.<br>Documentation</td><td>Les spécifications du format sont-elles publiées ? Si oui, sont-elles maintenues par un organisme de normalisation reconnu ? Quel est leur coût ?</td><td>Si les spécifications du format sont librement accessibles, il est possible à tout un chacun d'en comprendre la structure et, si le format est également libre, de développer des outils qui le prennent en charge.<br>La documentation peut être partielle : ainsi certains industriels publient-ils des documents décrivant seulement la structure générale de leur format. Un processus de normalisation garantit que l'on dispose de spécifications décrivant l'intégralité des caractéristiques significatives d'un format.<br>Les formats maintenus par des organismes de normalisation nationaux (AFNOR) ou internationaux (ISO, W3C, IETF, etc.) offrent de meilleures garanties de maintenance et de disponibilité des spécifications, mais peuvent se révéler payants.<br>On parle de standards de facto lorsqu'une spécification produite par une organisation est majoritairement adoptée dans une communauté bien qu'elle n'ait pas fait l'objet d'un processus de normalisation officiel.</td></tr><tr><td>CPO-LIB. Liberté d'utilisation</td><td>Existe-t-il des obstacles juridiques à l'utilisation du format ?</td><td>Si un format peut être totalement ouvert (documenté et utilisable par quiconque), il arrive également que des limitations d'usage pèsent sur des formats documentés, notamment en raison de brevets accordant des droits de propriété industrielle déposés au profit d'une organisation donnée. Ces brevets peuvent limiter ou interdire le développement d'outils prenant en charge le format.</td></tr><tr><td>CPO-AUT.<br>Indépendance / autonomie</td><td>L'utilisation du format requiert-elle d'autres formats, encodages, environnements logiciels ou matériels ?</td><td>La consultation et l'utilisation d'un fichier numérique sont systématiquement dépendantes d'un environnement technique. Outre la dépendance à un environnement logiciel qui peut être propriétaire, abordée dans le critère « Liberté d'utilisation », l'utilisation de certains formats est tributaire d'environnements matériels, de bibliothèques logicielles, ou d'éléments habituellement non embarqués dans le fichier (par exemple, la dépendance de la plupart des PDF aux polices installées sur le poste de l'utilisateur).</td></tr></tbody></table>
<figure><img src="image_20.png" /></figure>

<table><thead><tr><td>Identifiant et intitulé(s)</td><td>Définition</td><td>Justification</td></tr></thead><tbody><tr><td>CPO-ROB.<br>Robustesse</td><td>Le format dispose-t-il de mécanismes pour repérer, ignorer voire corriger des parties altérées du signal ?</td><td>Ce critère évalue la résistance des fichiers de ce format à l'altération. Cette altération peut provenir d'une dégradation du support ou d'une erreur du matériel de lecture, mais elle est plus souvent encore le fait d'un transfert interrompu, notamment en raison d'une défaillance du réseau ou de la connectique. De ce fait, les formats de fichiers destinés à être échangés sur le réseau par le biais du streaming sont souvent conçus pour être robustes.<br><br>La robustesse inclut les notions de résilience et de résistance à l'erreur. Elle dépend de la structure du format. Elle peut être renforcée par la présence d'empreintes numériques caractérisant chacune des zones d'un fichier, ce qui permet à un outil de validation d'identifier précisément la zone corrompue.<br><br>On notera que certaines méthodes de compression, particulièrement celles s'appliquant à l'ensemble du fichier et non à chacune de ses parties, peuvent avoir un effet négatif sur la robustesse des données. En raison de la réduction de la redondance que ces méthodes impliquent, une altération pourra affecter simultanément plusieurs zones du fichier.</td></tr><tr><td>CPO-COM.<br>Compacité</td><td>Le format exprime-t-il une quantité d'information conséquente dans un espace contraint ? Si cette compacité est liée à une méthode de compression, celle-ci est-elle réversible (sans perte d'information) ou non ?</td><td>Un des risques majeurs pesant sur la pérennité des données est le risque budgétaire. Si les budgets que l'utilisateur peut allouer à l'achat d'espace de stockage sont limités, le critère de compacité peut devenir décisif.<br><br>La compacité peut être liée à la structure d'encodage des données ou, le cas échéant, à la méthode de compression. Une compression sans perte, également dite « réversible », permet généralement une réduction significative du poids du fichier tout en garantissant la possibilité, grâce à la même méthode, de décompresser le fichier et d'obtenir une copie exacte, au bit près, du fichier source.</td></tr><tr><td>CPO-OUT.<br>Disponibilité d'outils de traitement</td><td>Existe-t-il des outils de restitution, de validation, d'analyse, de transformation ? L'organisme de maintenance du format en développe-t-il officiellement ?</td><td>La disponibilité d'outils de traitement est liée à la documentation (plus un format est documenté, plus les chances sont élevées que des outils de traitement l'exploitent avec précision), à la sociabilité (plus sa communauté d'utilisateurs est étendue, plus elle a de chances d'avoir développé des outils de traitement nombreux et efficaces).<br><br>On prêtera une attention particulière au degré de prise en charge native par les navigateurs web comme l'indice de l'adoption du format et la garantie supplémentaire de la diffusion d'outils de lecture auprès du grand public.</td></tr></tbody></table>
<figure><img src="image_21.png" /></figure>

<table><thead><tr><td>Identifiant et intitulé(s)</td><td>Définition</td><td>Justification</td></tr></thead><tbody><tr><td>CPO-ADD.<br>Contenu additionnel embarqué</td><td>Le format permet-il d'embarquer des flux complémentaires nécessaires à l'utilisation, l'identification et la gestion du fichier (métadonnées, documentation, visuels associés, etc.) ?</td><td>Outre le contenu principal du fichier, le format peut être conçu pour permettre d'embarquer du contenu additionnel nécessaire à son utilisation. En l'absence de telles dispositions, l'utilisateur sera amené à transmettre séparément ce contenu, avec les risques de perte que cela implique.<br>Le contenu additionnel peut être constitué de métadonnées permettant l'identification précise du contenu du fichier, des agents ayant contribué à sa création, des droits associés, etc. Il peut également s'agir de flux spécifiques comme un visuel pour un fichier audio MP3, des sources pour un document PDF/A-3 résultant d'une conversion, etc.</td></tr><tr><td>CPO-PRO.<br>Mécanismes de protection</td><td>Le format dispose-t-il de mécanismes de protection de son contenu ?</td><td>Ce critère est ambivalent. Certains mécanismes de protection visant à interdire l'accès ou l'utilisation d'une ou plusieurs des fonctions du fichier, tels que les DRM, peuvent empêcher l'utilisateur de mener à bien des opérations à but de conservation. Ceux à l'inverse qui n'ont pas pour but de limiter l'accès ou l'utilisation, tels les signatures électroniques embarquées comme XMLDSig pour XML, sont un atout pour garantir l'intégrité et l'authenticité du fichier.</td></tr><tr><td>CPO-SIM.<br>Simplicité</td><td>Le format a-t-il une structure simple ou complexe ?</td><td>Maintenir une compétence et des outils sur un format complexe demandera nécessairement un investissement plus lourd que sur un format simple.<br>Une méthode de compression ajoute un niveau de complexité supplémentaire. Selon les méthodes, ce niveau de complexité peut être conséquent (ex. : JPEG 2000) ou plus limité (ex. : MP3).</td></tr><tr><td>CPO-STA.<br>Stabilité / évolutivité</td><td>Le format connaît-il une évolution soutenue et des versions qui se succèdent à une fréquence élevée ?</td><td>Suivre l'évolution d'un format fréquemment mis à jour peut s'avérer complexe et coûteux en investissement ; à l'inverse, un format qui ne connaît plus d'évolutions depuis plusieurs années supposera un effort moindre d'adaptation à son évolution.<br>Plus généralement, ce critère interroge le stade de développement du format : est-il dans sa phase d'expansion initiale ou a-t-il atteint sa maturité, voire est-il toujours maintenu ?</td></tr><tr><td>CPO-TRA.<br>Transparence</td><td>Le format est-il aisément lisible et compréhensible ou sa structure est-elle opaque ?</td><td>En l'absence d'outils spécifiques, un format relativement transparent pourra être plus facilement interprété et compris par un humain à l'aide d'outils génériques tels que des éditeurs de texte, XML ou hexadécimaux.<br>La mise en œuvre d'une compression limite généralement le niveau de transparence d'un format.</td></tr></tbody></table>

### 2.8.2. Critères subjectifs

Ces critères reposent sur une évaluation directement liée aux besoins et aux moyens de l'utilisateur réalisant l'évaluation.
<figure><img src="image_22.png" /></figure>

Afin d'y faire référence plus aisément, ces critères sont identifiés par une série de lettres : « CPS » (pour « Critère de pérennité subjectif ») et les trois premières lettres du terme le plus significatif.

<table><thead><tr><td>Identifiant et intitulé</td><td>Définition</td><td>Justification</td></tr></thead><tbody><tr><td>CPS-EXP. Expressivité</td><td>Le format permet-il d'encoder toute l'information que le producteur souhaite exprimer ?</td><td>Lorsqu'on évalue un format candidat à la création ou à la transformation d'un contenu, on considère sa fidélité à l'intention originelle : toute l'information exprimée par le créateur ou contenue dans le fichier source peut-elle être adéquatement transformée dans les structures de données du fichier cible ? les propriétés du contenu sont-elles compatibles avec la qualité maximale du signal que le format peut embarquer ?<br>Une expressivité excessive au regard du besoin peut se révéler contre-productive à long terme car elle révèle généralement l'inadéquation du format, trop riche pour l'emploi que l'utilisateur souhaite en faire.</td></tr><tr><td>CPS-MAI. Maîtrise</td><td>L'utilisateur dispose-t-il déjà des compétences et des outils nécessaires à une exploitation précise du format ?</td><td>L'enregistrement de fichiers dans un format de données différent de celui d'origine équivaut à une transformation. Si celle-ci n'est pas réalisée en connaissance de cause, elle peut avoir un impact négatif sur la fidélité de la copie à son original.<br>Dans le cas de créateurs confiant leurs données à une institution de conservation, il est important que le format soit maîtrisé par les deux parties.</td></tr></tbody></table>

## 2.9. Analyse des fichiers

L'activité de préservation numérique repose sur la connaissance fine des contenus versés dans le système de préservation et de leurs représentations numériques sous forme de fichiers. Afin d'acquérir cette connaissance, la BnF met successivement en œuvre, préalablement au versement dans le système de préservation, plusieurs opérations à but de préservation : l'**identification** du format du fichier, la **caractérisation** du fichier, c'est-à-dire sa lecture en vue de déterminer les propriétés concrètes des fichiers telles que décrites en section 2.5., et enfin la **validation** du fichier au regard de sa spécification.

Afin de réaliser ces opérations d'analyse, la BnF emploie des outils de validation et de caractérisation du fichier. On indiquera donc, au début de chaque sous-section concernant un type de contenu dans la partie 3, le format de métadonnées de caractérisation, c'est-à-dire la forme dans laquelle la BnF souhaite conserver le rapport de l'outil d'analyse, ainsi que, dans chaque fiche Format en section 4, un ou plusieurs outils permettant de valider et de caractériser les fichiers de ce format.

Outre la connaissance des caractéristiques de chaque fichier<fnref n="9" />, le processus d'analyse a pour objectif immédiat de décider si le fichier est acceptable dans la filière<fnref n="10" />. La BnF définit des politiques de versement, de préservation et d'accès spécifiques à chaque filière. Ainsi, selon sa politique de numérisation de conservation actuelle, elle imposera le format JPEG 2000 BnF 24 bits. La validité du fichier et sa conformité à un profil d'application donné seront, selon la filière, considérées comme des exigences contraignantes ou non. Autrement dit, certaines filières (telle la numérisation de conservation) rejetteront les fichiers invalides tandis que d'autres (telle l'acquisition et le don de documents numériques) pourront les accepter. Dans ce dernier cas, néanmoins, la BnF portera une attention particulière aux fichiers invalides et leur appliquera une politique de préservation spécifique.

<footnote n="9">⁹ Le rapport d'analyse des fichiers, lorsque la BnF a pu en produire un, est enregistré au format XML dans les métadonnées du Paquet d'informations et est indexé pour pouvoir être par la suite interrogé par les experts de préservation.</footnote>

<footnote n="10">¹⁰ Dans ce document, on identifie par le terme « filière » des ensembles documentaires groupés par leur contenu, leur mode d'entrée (dépôt légal, don, acquisition, etc.), leurs conditions juridiques d'utilisation, leur méthode d'obtention (collecte automatique, dépôt à l'unité, etc.) et leurs caractéristiques techniques.</footnote>
<figure><img src="image_23.png" /></figure>

Afin que le processus d'analyse puisse être mené à bien, on veillera à l'absence de **chiffrement**, à la base de toutes les mesures techniques de protection (DRM) de contenu<fnref n="11" />. Il arrive souvent que le chiffrement fasse échouer les processus d'analyse, l'outil ne pouvant accéder au contenu<fnref n="12" />.

Le processus d'analyse des fichiers mis en œuvre par la BnF présente des particularités qui conditionnent les politiques que l'institution appliquera à ses données. Il est décrit dans les sections suivantes.

### 2.9.1. Identification du format<fnref n="13" />

L'identification est une opération de préservation qui initie le processus d'analyse du fichier. Elle vise à donner une première indication, plus ou moins sommaire, sur son format. En pratique, elle correspond à une analyse afin de déterminer à quelle entrée d'un registre de formats le fichier correspond. Le degré de précision de l'information résultante dépendra du niveau de détail des entrées du registre de formats. L'identification s'appuie généralement sur la détection de motifs signifiants dans le code du fichier, appelés « **nombre magique** » ou « **signature** », mais il arrive qu'elle doive se limiter à l'analyse de l'extension du nom du fichier<fnref n="14" />.

À la BnF, cette première étape consiste à obtenir le **type MIME**<fnref n="15" /> du fichier. Par exemple, un fichier communément appelé « **JPEG** » sera identifié comme « **image/jpeg** ». La première partie de ce terme donne une indication du type de contenu (image, texte, audio, etc.), la seconde du format des données qu'il contient<fnref n="16" />. Cette opération est mise en œuvre par l'outil logiciel « **Unix file** ».

Dans certaines institutions de conservation, notamment les archives, l'étape d'identification fournit davantage d'information car elle se fonde sur le registre de formats **PRONOM**. Celui-ci est une base de connaissance collaborative sur les formats maintenue par les archives nationales du Royaume-Uni et enrichie par la communauté internationale de la préservation numérique. Ce registre compte 1899 entrées à la date du 15 février 2021, à un niveau de détail généralement plus fin que le type MIME. Par exemple, l'identification du format d'un fichier dit « **JPEG** » à l'aide du logiciel DROID pourra identifier qu'il correspond plus précisément à l'entrée **JPEG File Interchange Format (JFIF)**, version 1.02 dans la base PRONOM.

Dans le cas où l'outil ne peut déterminer le type MIME du fichier, il sera considéré comme un simple train d'octets et le type MIME retourné sera « **application/octet-stream** ».

### 2.9.2. Caractérisation du fichier<fnref n="17" />

La caractérisation d'un fichier, dans son sens adopté par la communauté de la préservation numérique, est une opération de préservation consistant à analyser le contenu d'un fichier afin d'obtenir, par simple lecture ou par calcul, des informations sur le contenu, la forme et/ou l'historique du fichier.

La BnF ne se contente en effet pas du type MIME comme Information de représentation ; elle complète cette première étape d'analyse par la mise en œuvre d'un outil de caractérisation associé au type MIME ; par exemple,

<footnote n="11">¹¹ Le chiffrement est applicable à tout fichier, mais il est plus couramment employé sur certains contenus que sur d'autres ; en outre, la manière de l'intégrer dans un format est parfois prévue par la spécification elle-même.</footnote>

<footnote n="12">¹² L'opération d'analyse n'est pas la seule à être potentiellement affectée par le chiffrement : toute opération de préservation (copie, migration, etc.) peut également être compromise.</footnote>

<footnote n="13">¹³ Pour un panorama général des problématiques liées à l'identification des formats de fichiers, on se reportera au document **Identification des formats de fichiers**, Programme VITAM, version 2.0, février 2020, disponible sur http://www.programmevitam.fr/ressources/DocCourante/autres/fonctionnel/20200131_NP_Vitam_preservation-identification-format-v2.0.pdf (consulté le 4 septembre 2020).</footnote>

<footnote n="14">¹⁴ C'est ainsi que fonctionnent les systèmes d'exploitation Windows, qui fondent l'identification du format sur la seule extension du nom de fichier.</footnote>

<footnote n="15">¹⁵ La liste officielle des types MIME est maintenue par l'organisation IANA (Internet Assigned Numbers Authority, https://www.iana.org/) sous la forme du standard RFC 6838 (https://www.iana.org/go/rfc6838). On notera que nombre de types MIME effectivement utilisés ne sont pas officiellement enregistrés par l'IANA car cet enregistrement suppose la soumission d'une RFC (« Request for comments », standard du web maintenus par l'IETF, Internet Engineering Task Force) officielle. Ces types MIME officieux sont théoriquement identifiés par un caractère « x » et un tiret précédant la seconde partie du type (par exemple, le format de livre numérique MOBI n'a pas fait l'objet d'une RFC officielle et est donc identifié par le type MIME « application/x-mobipocket-ebook »).</footnote>

<footnote n="16">¹⁶ On omet ici une troisième partie, optionnelle, qui indique des « paramètres ». Ainsi, le type MIME « audio/vnd-wave; codec=1 » identifie un fichier WAVE dont le flux audio n'est pas compressé.</footnote>

<footnote n="17">¹⁷ Pour un panorama général des problématiques liées à la caractérisation des formats de fichiers, on se reportera au document **Extraction des métadonnées techniques**, Programme VITAM, version 2.0, février 2020, disponible sur http://www.programmevitam.fr/ressources/DocCourante/autres/fonctionnel/20200131_NP_Vitam_preservation-extraction-MD-v2.0.pdf (consulté le 4 septembre 2020).</footnote>
<figure><img src="image_24.png" /></figure>

```xml
</mix:ImageColorEncoding>
</mix:ImageAssessmentMetadata>
</mix:mix>
```

On constate la coexistence, dans cette sortie, de métadonnées techniques (l'espace couleur, `//mix:colorSpace`, vaut « 0 », correspondant aux images binarisées ou en niveau de gris) et de métadonnées de provenance (le nom du logiciel de numérisation : « Spi Factory »).

L'adoption d'un format de métadonnées de caractérisation commun permet la comparaison des caractéristiques de tous les fichiers véhiculant un même type de contenu, quel que soit leur format. Elle ouvre également la voie à la comparaison de ces caractéristiques, avant et après une transformation, afin de contrôler que les propriétés considérées comme signifiantes pour l'institution ont été conservées.

### 2.9.3. Validation du fichier<fnref n="18" />

La validation consiste à évaluer la conformité d'un fichier au regard de la spécification de son format. Ainsi, dans le cas d'un fichier TIFF, validé à la BnF à l'aide de l'outil JHOVE<fnref n="19" />, la validation vérifiera dans le rapport d'analyse que le statut a pour valeur « Well-formed and valid », ici dans la sortie XML de JHOVE :

```xml
<jHOVE xmlns="http://schema.openpreservation.org/ois/xml/ns/jhove">
  <date>2021-03-01T11:56:20+01:00</date>
  <repInfo uri="/data/spar-rea/ptools01/tmp/rep2100950133715637140tmp">
    <reportingModule release="1.9.1" date="2019-04-17">TIFF-hul</reportingModule>
    <lastModified>2021-03-01T11:56:20+01:00</lastModified>
    <size>33313830</size>
    <format>TIFF</format>
    <version>5.0</version>
    <status>Well-Formed and valid</status>
  </repInfo>
</JHOVE>
```

La validation peut être réalisée à l'aide du même outil que celui employé pour la caractérisation ou faire appel à un outil distinct, notamment dans le cas où l'outil de caractérisation ne fournit pas de retour, ou pas de retour jugé suffisamment fiable, sur la validité du fichier au regard des spécifications de son format<fnref n="20" />.

On notera que la validation produit une information supplémentaire sur les données dont le but est d'ajouter à la connaissance de celles-ci et d'aider au processus d'acquisition. Il ne s'agit pas d'une opération obligatoire dont le résultat condamnerait au rejet systématique les données invalides. Il est important de noter que le processus de validation remonte, outre des erreurs, des avertissements ; ces derniers permettent de repérer des particularités des données qui passeraient, sans cela, inaperçues. Ainsi, la validation par JHOVE de fichiers WAVE indique la présence de chunks (blocs de données) dont le type est inconnu et dont l'analyse est recommandée avant versement. Par conséquent, certaines filières (numérisation, dépôt légal de masse, etc.) rejeteront et exigeront une relivraison de données valides des fichiers invalides tandis que d'autres les accepteront (acquisitions et dons, etc.). En outre, il est parfois possible de corriger les problèmes de structure repérés dans les données.

La validation est réalisée dans la plupart des filières d'entrée mises en place par la BnF. Dans certains cas, elle peut être omise ou réalisée par échantillonnage pour les raisons suivantes :

- s'il n'existe pas d'outil adapté pour réaliser une telle opération ;

- si le temps et les ressources de calcul pour la mettre en œuvre sont considérés comme excessifs ;

- si dans la suite du processus, des actions de décodage afin de générer des dérivés de diffusion ou de contrôle permettent de repérer d'éventuels problèmes de structure.

### 2.9.4. Contrôle de conformité à un profil d'application

Dans le cas de formats bien maîtrisés par la BnF, en particulier lorsqu'il s'agit de fichiers produits selon ses référentiels, la politique de la BnF va au-delà de la simple conformité aux spécifications du format et définit un profil d'application du format que le fichier doit suivre.

<footnote n="18">¹⁸ Pour un panorama général des problématiques liées à la validation des formats de fichiers, on se reportera au document Validation du format des fichiers, Programme VITAM, version 2.0, février 2020, disponible à l'adresse http://www.programmevitam.fr/ressources/DocCourante/autres/fonctionnel/20200131_NP_Vitam_preservation-validation-format-v2.0.pdf (consulté le 4 septembre 2020).</footnote>

<footnote n="19">¹⁹ Open Preservation Foundation, JHOVE, http://jhove.openpreservation.org/ (consulté le 04 mars 2021).</footnote>

<footnote n="20">²⁰ Ainsi, l'outil JHOVE est un outil de caractérisation et de validation pour de nombreux formats d'images courants. À l'inverse, l'outil MediaInfo ne propose que la caractérisation des fichiers audiovisuels. La BnF juge donc nécessaire de mettre en œuvre un second outil de validation pour certains fichiers audio ou vidéo.</footnote>
<figure><img src="image_25.png" /></figure>

Afin de vérifier que ce profil d'application est bien respecté, un contrôle compare les métadonnées de caractérisation et les propriétés attendues par le profil d'application. Ainsi, l'image TIFF dont le rapport de caractérisation est présenté plus haut sera déclarée conforme au format « TIFF BnF noir et blanc » notamment parce que les éléments suivants présentent la valeur attendue :

- //mix:samplesPerPixel (échantillons par pixel) a pour valeur « 1 », correspondant à des images en niveau de gris ou binarisées ;

- //mix:bitsPerSample (bits par échantillon) a pour valeur « 1 », correspondant à des images binarisées, où la valeur de chaque pixel est codée sur un seul bit ;

- //mix:compressionScheme (mode de compression) a pour valeur « 4 », correspondant au mode de compression attendu pour ces images : CCITT groupe 4.

## 2.10. Stratégies de préservation

Maintenir l'information numérique accessible, compréhensible et utilisable sur le long terme suppose une activité régulière et la mise en place d'actions de préservation pour prévenir des risques budgétaires ou organisationnels autant que techniques. Le choix de formats maîtrisés et adaptés à la préservation ainsi que la limitation du nombre de formats représentés au sein de l'institution de conservation permettent néanmoins de maintenir le coût de cette activité à un niveau acceptable. Traditionnellement, on identifie deux grandes catégories de stratégies de préservation visant à limiter les risques liés au format des données :

1. l'adaptation du contenu à l'environnement : il s'agit des stratégies de transformation ;

2. l'adaptation de l'environnement au contenu, qui comprend notamment les stratégies d'émulation.

**La stratégie de préservation ne dépend pas uniquement du format mais également du type de contenu des données, de leur usage et de l'intention de préservation de l'institution de conservation.** Le présent document évoquera les stratégies de préservation adoptées par la BnF selon les deux modalités suivantes.

- Lorsqu'une transformation n'est pas envisagée à moyen terme, on indiquera les éléments significatifs de l'environnement de restitution choisi par la BnF dans la section « Outils » de chaque fiche Format.

- Lorsqu'une transformation est envisagée à court ou moyen terme, on indiquera la stratégie adoptée par la BnF (format source, format cible et procédure de transformation) dans la section 3 et non dans les fiches Formats en section 4. En effet, de telles stratégies seront appliquées non à tous les fichiers d'un format donné mais prendront en compte outre le format lui-même, et entre autres critères détaillés ci-dessous, le type de contenu et le contexte d'utilisation.

### Stratégie d'adaptation du contenu à l'environnement

La première stratégie, de transformation, présente un risque de perte du contenu informationnel des données<fnref n="21" />. De ce fait, l'étude d'une méthode de transformation adaptée vise à s'assurer qu'elle n'a engendré aucune perte ou à limiter cette perte aux propriétés que l'institution de conservation ne juge pas signifiantes. La BnF peut néanmoins être contrainte d'opérer une transformation dont elle sait par avance que les données résultantes ne contiendront pas l'intégralité de l'information véhiculée par les données originales, en particulier dans le cas de formats propriétaires. La BnF envisage alors la conservation des données originales en complément de leur version migrée dans un format préféré. Un cas de ce type est décrit dans la section 2.10.1.2.5 ci-dessous.

La BnF portera une attention particulière à la méthode de transformation, et en particulier à l'outil, son paramétrage et la compétence des agents qui l'opèrent. Dans le cas de données dans un format propriétaire, on privilégiera généralement le logiciel qui les a produites pour effectuer la transformation. On part en effet du principe que le logiciel propriétaire de création bénéficie de la meilleure connaissance du format source et sera donc capable de conserver la majeure partie du contenu informationnel.

### Stratégie d'adaptation de l'environnement au contenu

La deuxième stratégie évoquée concerne les documents exécutables qui nécessitent un environnement logiciel et matériel particulier. Ces documents recouvrent en particulier les jeux vidéo, documents multimédia, applications mobiles, bases de données, et toutes les formes de logiciels.

La stratégie mise en œuvre s'appuie alors sur la virtualisation des supports - lorsque les documents ont été déposés sous la forme d'un support d'enregistrement informatique - et des équipements de lecture au sens large (console de jeux, tablette/smartphone, ordinateur...). La virtualisation d'un support consiste en l'extraction de toutes les

<footnote n="21">²¹ On considère comme « migration » toute transformation des données, y compris un simple enregistrement dans un format différent de celui dans lequel les données ont été originellement créées.</footnote>
<figure><img src="image_26.png" /></figure>

informations qu'il contient en vue de son stockage au sein d'un fichier dit « image ». Il est parfois nécessaire d'utiliser plusieurs outils et formats de fichiers « image » pour représenter ces informations de manière exhaustive.

La virtualisation des environnements logiciel et matériel requis pour l'exécution des différents types de documents exploite plusieurs technologies, notamment celle de l'émulation, qui permettent de simuler une machine, généralement ancienne, sur une autre, généralement contemporaine. La plupart des émulateurs se contentent de simuler la partie matérielle de l'équipement ciblé. Il convient alors d'installer en leur sein le système d'exploitation adapté à la fois à l'équipement simulé et aux nécessités du document.

Cette stratégie permet de conserver aussi bien les contenus numériques que leur environnement d'exécution, et donc la capacité de restitution sur le moyen ou long terme.

A cette fin, la BnF effectue une veille permanente sur la disponibilité des outils logiciels permettant l'extraction des données enregistrées sur les supports présents dans ses fonds patrimoniaux et sur les émulateurs développés par des communautés de passionnés aussi bien que par des sociétés commerciales.

Le principal défaut de cette stratégie est la dénaturation potentielle d'une partie de l'« expérience utilisateur » puisque l'équipement utilisé pour la consultation des documents concernés n'est pas strictement identique à celui d'origine. Elle constitue cependant un compromis acceptable pour pallier la disparition inéluctable des supports – du moins la capacité à en lire les informations enregistrées – et des appareils de lecture d'origine. Elle doit être associée à une documentation complémentaire permettant d'apprécier les modifications faites par rapport à l'expérience utilisateur originelle (captures vidéo, etc.).

### 2.10.1. Opérations préalables au versement

Avant de prendre la responsabilité de la conservation de données qu'elle n'a pas fait produire, la BnF tente d'engager une discussion avec le Producteur afin d'identifier un ou plusieurs formats satisfaisant les deux parties au regard des critères de pérennité édictés plus haut. En particulier, elle s'assure que le ou les formats choisis sont maîtrisés par le Producteur et par elle-même.

Si une telle négociation avec le Producteur n'a pu avoir lieu et que la BnF a obtenu des données dans un format qui ne fait pas partie de ses formats préférés ou acceptés, elle peut envisager quatre options :

- Le rejet pur et simple du document ;

- La demande d'une relivraison par le Producteur d'une version conforme à ses exigences ;

- L'adaptation de sa politique, de ses compétences et de son environnement logiciel et matériel au format du document ;

- La transformation du contenu.

Le tableau en section ci-dessous liste les critères d'évaluation de la pertinence d'une transformation. Celle-ci peut affecter le format du conteneur ou celui du flux des données. Il peut s'agir d'opérations ciblées : pour une image, une conversion du modèle couleur CMJN destiné à l'impression vers RVB, destiné à l'affichage, par exemple, voire une correction d'un problème de structure ou de métadonnées internes. Comme pour toute autre opération de préservation, les transformations effectuées entre le transfert des données et leur versement seront tracées et enregistrées dans les métadonnées de provenance du Paquet d'informations.

#### 2.10.1.1. Critères de transformation au versement

Pour chaque fonds, la BnF décide du format cible, de la méthode de transformation et de la conservation des fichiers d'origine, en prenant en compte les critères suivants, selon une pondération spécifique à chaque fonds. Les cases notées « N/A » (non applicable) signalent que la BnF considère le critère comme n'influant pas sur la réponse qu'elle apporte à la question, ou qu'elle choisit de ne pas le prendre en compte. Cette liste n'est pas classée par ordre d'importance. Afin d'y faire référence plus aisément, ces critères sont identifiés par une série de lettres : « CT » (pour « Critère de transformation ») et les trois premières lettres du terme le plus significatif.

<table><thead><tr><td>Identifiant et intitulé</td><td>Réalisation ou non d'une opération de migration ?</td><td>Quel format cible ?</td><td>Conservation ou non de l'original ?</td></tr></thead><tbody><tr><td>CT-CAT. Catégorie du format</td><td>Si le format du fichier livré par le Producteur n'est pas dans un format préféré pour son type de contenu et son usage, on envisagera une opération de transformation.</td><td>On choisira pour le format cible un des formats préférés identifiés pour le type de contenu véhiculé par le fichier livré.</td><td>N/A</td></tr></tbody></table>
<figure><img src="image_27.png" /></figure>

<table><tr><td>CT-CHO. Choix artistique ou technique délibéré</td><td>On prendra en compte le caractère délibéré ou non de la livraison des contenus dans un ou plusieurs formats donnés pour déterminer la pertinence d'une opération de transformation, notamment dans le cas d'un fonds de contenus de même nature mais dans des formats hétérogènes.</td><td>Les choix artistiques ou techniques peuvent également influencer le choix du format cible, notamment si le Producteur a spécifié une méthode de transformation vers un format donné ou a réalisé lui-même une représentation numérique alternative dans un format préféré.</td><td>On tendra à conserver le fichier original si le choix de son format est délibéré.</td></tr><tr><td>CT-JUR. Contraintes juridiques</td><td>On doit s'assurer qu'on est en droit d'opérer des transformations (notamment dans le cadre des dons et acquisitions), afin de ne pas contrevenir au droit de la propriété intellectuelle<sup>22</sup>.</td><td>N/A</td><td>Dans certains cas, les contraintes juridiques peuvent obliger à conserver la forme originelle du contenu<sup>23</sup>.</td></tr><tr><td>CT-AUT. Autonomie / dépendances du fichier</td><td>Si le fichier livré n'est pas autonome mais fait partie d'un ensemble requis pour constituer un contenu, on peut envisager une opération globale, par exemple en embarquant les données dans un fichier conteneur.</td><td>Le format cible d'un contenu cohérent sera envisagé globalement et non à l'échelle d'un de ses fichiers composants.</td><td>N/A</td></tr></table>

<footnote n="22">22 L'exception « Bibliothèques » du code de la propriété intellectuelle (Art. L.122-5, alinéa 8, disponible sur https://www.legifrance.gouv.fr/codes/article_1c/LEGIARTI000037388886/) permet à la BnF de réaliser des opérations de copie et de migration à des fins de conservation, dès lors que les documents ont été divulgués, sans autorisation préalable des ayants-droit. Cette exception concerne les documents soumis au dépôt légal et ceux entrant par acquisition ou par don s'ils ont été divulgués. En revanche, tout document non divulgué entrant dans les collections par don ou par acquisition doit faire l'objet d'une cession de droits de la part du ou des titulaires des droits de propriété intellectuelle afin d'autoriser la BnF à réaliser des opérations de copie et de migration à des fins de préservation. Dans la pratique, les dons et acquisitions font l'objet d'une cession de droits même lorsqu'ils portent sur des documents divulgués, afin de clarifier les opérations autorisées.</footnote>

<footnote n="23">23 Selon sa rareté, le document peut être considéré comme étant un document numérique original (si le donateur fournit la seule copie existante ou du moins, la seule dont il dispose). Celui-ci relevant par ailleurs du code général de la propriété des personnes publiques, il ne peut de fait être détruit. La BnF a alors pour mission de le conserver dans son format d'origine. En outre, certains contrats conclus avec les donateurs pourraient conditionner le don du fonds à la conservation et/ou à la diffusion du format d'origine.</footnote>
<figure><img src="image_28.png" /></figure>

<table><tr><td>CT-COH. Cohérence au sein du Paquet d'informations ou du fonds</td><td>Afin de simplifier la préservation et la réutilisation, il est préférable que les fichiers destinés au même Paquet d'informations et ayant le même usage soient conservés dans un format homogène.</td><td>Entre deux formats cibles candidats, on préférera celui qui est représenté au sein du fonds.</td><td>N/A</td></tr><tr><td>CT-SOU. Soutenabilité</td><td>La volumétrie et la complexité des données sources influent sur le choix d'opérer une transformation ou non.</td><td>N/A<sup>24</sup></td><td>Conserver le fichier original, dans le cas d'un fichier très volumineux ou complexe et non maîtrisé, peut représenter une charge importante pour l'institution de conservation.</td></tr><tr><td>CT-EQU. Existence d'un équivalent dans un autre format</td><td>L'existence d'une autre représentation numérique dans un format préféré influe sur le choix de réaliser une transformation ou non<sup>25</sup>.</td><td>N/A<sup>26</sup></td><td>N/A</td></tr><tr><td>CT-SIG. Conservation de propriétés signifiantes</td><td>N/A</td><td>La définition par l'institution de conservation de son intention de préservation, c'est-à-dire de l'ensemble des propriétés d'un objet numérique qu'elle souhaite préserver sur le long terme afin de garantir des usages de ces contenus à sa Communauté d'utilisateurs cible, conditionnera le format cible, la méthode de transformation et la conservation ou non de l'original<sup>27</sup>.</td><td>N/A</td></tr><tr><td>CT-REV. Réversibilité de l'opération<sup>28</sup></td><td>N/A</td><td>Entre deux formats cibles candidats, on préférera celui vers lequel la transformation est réversible.</td><td>Si l'opération est réversible (ajout de métadonnées, compression sans perte, etc.), la conservation de l'original pourra être considérée comme non nécessaire.</td></tr></table>

<footnote n="24">24 Le format cible ayant vocation à être un format déjà connu par la BnF, le critère de soutenabilité correspond à son évaluation au regard des critères de pérennité, entre autres la compacité (CPO-COM) et la simplicité (CPO-SIM).</footnote>

<footnote n="25">25 La solution la plus simple est évidemment de ne prendre en charge que la représentation numérique dans un format préféré par la BnF.</footnote>

<footnote n="26">26 Néanmoins, l'existence dans le fonds d'une version convertie depuis le même format source que le fichier étudié peut amener à préférer le format cible dans la mesure où il a déjà été choisi par le Producteur comme format de conversion.</footnote>

<footnote n="27">27 Dans le cas où la migration est réversible (CT-REV), la perte de fonctionnalités et propriétés signifiantes peut ne pas conduire à la conservation de l'original puisqu'il peut être restauré dans sa version strictement équivalente par une migration inverse.</footnote>

<footnote n="28">28 Attention à certaines conversions qui peuvent être réversibles pour le flux principal de données, mais non réversibles pour les flux secondaires (métadonnées, vignettes, etc.).</footnote>
<figure><img src="image_29.png" /></figure>

<table><tr><td>CT-MOD. Mode de production et d'entrée</td><td>Le mode de production et d'entrée (prestation ou commande, dépôt légal de masse ou à l'unité, acquisition ou don) influe sur la décision d'intervenir ou non<sup>29</sup>.</td><td>N/A</td><td>Dans le cas d'une prestation ou d'une commande, si on intervient sur les données, on aura moins de scrupules à ne conserver que la version transformée que dans le cas d'acquisitions ou dons.</td></tr><tr><td>CT-MIN. Intervention minimale</td><td>N/A</td><td>On préférera l'intervention la plus minimale, donc le format accepté dont la structure est la plus proche du format d'origine.</td><td>Si l'intervention est très limitée, on pourra envisager de ne conserver que les données transformées.</td></tr></table>

### 2.10.1.2. Exemples d'application des critères de transformation

Ces exemples sont inspirés de cas d'usage réels rencontrés par la BnF mais ont pour but essentiel d'illustrer le tableau des critères de transformation ; ils ont été simplifiés et ne reflètent donc pas nécessairement toute la complexité de la situation. Les choix mentionnés reflètent en outre des **pratiques** (voir section 2.3 ci-dessus) qui n'ont pas forcément vocation à être systématisées.

#### 2.10.1.2.1. Conversion de photographies numériques au format PDF en images JPEG

La BnF obtient par don un lot de quinze photographies numériques dans des formats différents (PDF et JFIF JPEG). Le PDF n'étant pas un format préféré pour les photographies numériques (CT-CAT), elle envisage une transformation. Elle s'assure d'abord que le format PDF ne résulte pas d'un choix délibéré du Producteur (CT-CHO). Elle constate par ailleurs que le fichier PDF a pour source une image JPEG de la même série que les autres photographies au format JFIF, et que l'image contenue dans le PDF est compressée selon l'algorithme DCTDecode, également utilisé pour la compression JPEG. Dans la mesure où elle souhaite constituer un unique Paquet d'informations à partir de ce lot pour des raisons documentaires, elle préfère homogénéiser le format des fichiers destinés à ce Paquet (CT-COH) et migrer les fichiers PDF vers le format JFIF (JPEG).

#### 2.10.1.2.2. Dérivation de JPEG depuis un projet PSD

La BnF obtient par don un lot de trois fichiers PSD (format d'enregistrement du logiciel Photoshop). Ce format ne fait pas partie des formats préférés de la BnF, notamment parce qu'il est propriétaire. Elle envisage une transformation vers JFIF (JPEG). Elle constate néanmoins que le fichier PSD comprend deux calques, dont l'un est la version de la photographie avant recadrage. Considérant que la présence de cette seconde image est une propriété signifiante documentant la provenance de la photographie recadrée, et que la transformation vers le format JFIF (JPEG), envisagé comme format cible, fera disparaître cette propriété (CT-SIG), elle décide de réaliser cette transformation tout en conservant le fichier PSD original. Elle emploie pour cela le logiciel Photoshop en sollicitant les compétences de son experte en imagerie numérique.

#### 2.10.1.2.3. Multiplexage d'AIFF vers MP4

Au sein d'un ensemble conséquent de fichiers, la BnF reçoit une série de quatre fichiers AIFF (équivalent du format WAVE développé pour les systèmes Apple pour l'encodage du son non compressé). Après étude, il s'avère que ces quatre fichiers sont les pistes sonores synchrones d'un contenu vidéo (CT-AUT) dont la partie image est enregistrée dans un fichier MXF ; le contenu des fichiers AIFF et du fichier MXF est donc migré dans un unique fichier conteneur au format MP4.

<footnote n="29">29 Ainsi, dans le cas d'une prestation ou d'une commande, on rejettera tout bonnement les données dans un format non conforme ; inversement, dans le cas d'un dépôt légal à l'unité ou d'une acquisition, on tendra plutôt à normaliser avec précaution voire à accepter les données sans intervention.</footnote>
<figure><img src="image_30.png" /></figure>

#### 2.10.1.2.4. Compression d'un flux audio non compressé vers FLAC

La BnF étudie l'opportunité d'une transformation de ses fichiers sonores au format WAVE non compressé vers le format FLAC pour des questions de soutenabilité, le format FLAC étant deux à trois fois plus compact que le format WAVE non compressé (CT-SOU). Elle prend en compte, parmi d'autres critères, la réversibilité intégrale (flux de données audio et métadonnées) de la transformation du format WAVE non compressé vers FLAC (CT-REV), ce qui lui permet d'envisager une transformation sans conservation de l'original.

#### 2.10.1.2.5. Dérivation de FCP vers un format image

Le format FCP est un format utilisé par le logiciel propriétaire Final Cut Pro et développé par Apple pour réaliser le montage de films. Un don d'archives par un cinéaste a mis la BnF en possession des montages successifs d'un même film, sous la forme de « bibliothèques » ou « projets » FCP. Ces fichiers, déjà très volumineux, n'embarquent pas tous les médias utilisés mais y font référence par le biais d'un chemin relatif. La BnF envisage :

- d'opérer une transformation partielle n'épuisant pas le contenu informationnel des projets FCP afin de mettre à disposition des chercheurs un aperçu du contenu de ces projets, notamment la capture écran de la * timeline du projet et l'export du montage final sous forme d'un fichier MP4 ;*

- de conserver le projet FCP, dans la mesure où la transformation mentionnée ne permet pas de conserver les propriétés signifiantes<fnref n="30" /> (CT-SIG), malgré le poids conséquent de ces fichiers (CT-SOU) ;

- de conserver les médias sources référencés par les projets comme des contenus unitaires, et de leur appliquer une transformation spécifique, mais également d'en conserver un état original empaqueté avec le projet lui-même (CT-AUT).

#### 2.10.1.2.6. Traitement de contenus disponibles au format DOCX et PDF

Dans de nombreux fonds donnés à la BnF, on trouve des contenus sous deux formats : l'un au format de production DOCX, format utilisé par le traitement de texte Microsoft Word à partir de sa version 2007, l'autre dans une version de publication au format PDF. La BnF choisit dans ce cas de conserver le contenu sous les deux formats, considérant que la version DOCX est le fichier original, et la version PDF son équivalent dérivé dans un format préservable à long terme.

### 2.10.2. Opérations postérieures au versement

Sur le long terme, il arrive également que la BnF doive effectuer sur les objets numériques dont elle a la charge des transformations. Si une telle opération est prévue à moyen terme par la BnF, elle est indiquée pour un format, un usage et un type de contenus donnés, avec les outils pressentis pour la réaliser. Cette section du document a vocation à être enrichie à mesure que la BnF développe l'expérience de telles opérations.

Comme les transformations préalables au versement, celles postérieures au versement sont tracées et enregistrées dans les métadonnées de provenance du Paquet d'informations.

### 2.10.3. Exemple d'opération de virtualisation et d'émulation

Un cas d'usage réel permet d'illustrer la stratégie d'émulation.

Les documents produits dans les années 1980 pour le Thomson TO7 peuvent avoir été enregistrés sur cartouches propriétaires, cassettes audio ou disquettes 5.25 pouces. Différentes techniques et formats de fichiers ont été inventés afin de procéder à la lecture, l'extraction et l'enregistrement des informations binaires stockées sur ces supports. Plusieurs émulateurs ont été développés par des particuliers afin de simuler le fonctionnement d'un TO7 sur un PC d'aujourd'hui dans l'environnement Microsoft Windows. Pour fonctionner, ces émulateurs nécessitent un fichier contenant les informations enregistrées sur la cartouche adaptée au document considéré. La plupart du temps, il s'agit de la cartouche Basic qui permet au TO7 d'exécuter des programmes écrits en langage Basic.

C'est bien l'association d'un émulateur, de l'image du « système d'exploitation » et de l'image des différents supports qui le constituent qui permet la restitution d'un document TO7.

La perte de l'authenticité de cette technique de restitution se traduit notamment par :

- Le crayon optique du TO7 est remplacé par la souris du PC utilisé ;

<footnote n="30">³⁰ Si la BnF ne considère pas la possibilité de reprendre et modifier le montage comme une « fonctionnalité signifiante » à maintenir, elle a conscience que les projets FCP conservent de nombreuses informations sur le processus de création qui seraient perdues dans une migration vers un autre format. La BnF a également conscience que les limitations liées à ce format propriétaire l'empêcheront sans doute à terme de restituer correctement ces projets, et que les dérivés, si insuffisants soient-ils, deviendront alors la seule représentation du montage.</footnote>
<figure><img src="image_31.png" /></figure>

* Les écrans plats de type LCD utilisés aujourd'hui ont des propriétés visuelles assez différentes de celles procurées par les écrans cathodiques d'origine ;

* La rapidité et la fiabilité de la lecture des supports virtualisés, ainsi que l'exécution proprement dite des logiciels, est sans commune mesure avec celle des équipements d'origine – compte tenu des progrès technologiques réalisés. Il s'agit d'une problématique importante qui peut néanmoins être tempérée par les capacités des émulateurs et le témoignage des utilisateurs historiques. A l'inverse, les capacités offertes par les émulateurs représentent un confort appréciable par rapport à une consultation sur les matériels d'origine, très chronophage, à l'aboutissement aléatoire, et dans un environnement fermé. L'émulation permet ainsi de mettre la machine émulée en pause, de procéder à des saisies d'écran, de parcours vidéo, ou d'accéder à l'état mémoire de cette machine...
<figure><img src="image_32.png" /></figure>

### 3. Liste des formats connus

Ce document organise par type de contenu les formats connus par la BnF, un format pouvant être jugé adapté à un type de contenu et non à un autre. Ainsi le PDF est-il idéal pour l'encodage du texte dont on souhaite préserver la mise en page, mais non à la numérisation patrimoniale (même s'il a pu être utilisé dans ce cadre). La seconde version de ce document détaille la politique de la BnF pour neuf types de contenu (image fixe, texte, son, image animée, contenu web, contenu cartographique, notation musicale, correspondance et multimédia). Les types de contenu que la BnF compte développer dans une prochaine version sont les logiciels, les jeux de données structurées, et les objets (3D). À l'intérieur de chaque section, on a défini des sous-sections correspondant à un usage ou à un mode de production des données conditionnant les propriétés signifiantes à préserver.

À l'intérieur des sections du document, un éventuel classement par préférence est indiqué par une numérotation 1), 2), 3) ; si à l'inverse la liste n'est pas classée par préférence, les formats sont introduits par un tiret (-).

Dans certains cas, sous le titre « **Formats reconnus par la communauté** », on indique les formats non étudiés par la BnF, mais utilisés par la communauté de la préservation numérique, et qui à ce titre présentent un certain nombre de garanties de préservation. On indiquera ainsi les formats recommandés par d'autres institutions patrimoniales reconnues (une liste de documents de politique similaires est disponible en section 5.2 ci-dessous et une comparaison des politiques de formats sous forme d'un tableau a été publiée par l'Open Preservation Foundation sur https://openpreservation.org/resources/member-groups/international-comparison-of-recommended-file-formats/).

Les données dans un format ne figurant pas dans ce document ne seront pas nécessairement refusées par la BnF et leur absence ne signifie pas qu'ils sont jugés impropres à la préservation de l'information. Dans le cas où un producteur disposerait de données dans d'autres formats que ceux mentionnés dans le présent document, et souhaiterait les confier à la BnF, **il est invité à entrer en contact avec la BnF avant de se lancer dans une transformation non maîtrisée** afin d'engager un dialogue sur le format préférable pour un transfert, sous réserve de l'acceptation du don par la BnF. En effet, une transformation opérée avec un outil inconnu ou un enregistrement sous un format différent que celui dans lequel le fichier a été originellement créé présente un risque élevé de perte d'information.
<figure><img src="image_33.png" /></figure>

## 3.1. Images fixes

On entend par « image fixe » une représentation visuelle en deux dimensions, opaque ou translucide et sans mouvement, par opposition à l'image animée. Sa représentation numérique prend la forme d'une grille de pixels ayant une valeur de couleur ou de simple luminance (niveau de gris) <fnref n="31" />. La couleur est exprimée le plus couramment selon les modes RVB ³² ou CMJN <fnref n="33" />. Le premier correspond principalement aux domaines de la production d'images et de la visualisation sur écran. Le second est communément dédié à l'impression en quadrichromie. L'information de couleur peut être encodée avec plus ou moins de précision : sur 8 ou 16 bits par couche pour les cas les plus fréquents. Les images sans information de couleur peuvent être décrites en noir et blanc (binaire) ou en niveaux de gris (on parle également de « nuances de gris »).

La BnF préfère généralement obtenir les documents dans un état finalisé ou diffusé (voir les étapes du cycle de production en section 2.6). De ce fait, elle privilégie les images ayant les propriétés suivantes :

- Une profondeur d'échantillonnage de 8 bits par couche (soit 24 bits pour des images en couleur et 8 bits pour des images en niveaux de gris) ;

- Un modèle couleur RVB ;

- L'absence de calques, tracés ou couches alpha ;

- Un espace colorimétrique embarqué adapté à l'usage. En outre, la BnF déconseille les procédés de sur-échantillonnage (*upsampling*) et d'*interpolation*, ainsi que tout procédé de ré-encodage d'un flux compressé avec pertes dans un format non compressé ou compressé sans perte.

En cas de données ne correspondant pas à ces préférences, les images pourront être transformées par la BnF préalablement à leur versement dans le système de préservation.

Dans certains cas bien précis, la BnF peut collecter des images à une étape antérieure à celles de la finalisation ou de la diffusion. Dans ce cas, elle collectera des documents présentant des propriétés différentes de celles édictées plus haut.

La BnF identifie trois sous-ensembles d'images fixes pour lesquelles elle définit une politique distincte, décrite ci-dessous : images issues de la numérisation, photographies nativement numériques et créations graphiques.

### 3.1.1. Images issues de la numérisation

Cette section concerne les images numériques issues de numérateurs linéaires (scanners) ou matriciels (appareils photo) visant à reproduire en deux dimensions des documents ou des œuvres en deux dimensions. Sont par exemples concernés les documents opaques tels que journaux, livres, cartes, etc., et transparents tels que supports argentiques photographiques ou micrographiques.

#### 3.1.1.1. Propriétés des images issues de la numérisation

<table><thead><tr><td>Propriété signifiante</td><td>Propriété(s) concrète(s)</td></tr></thead><tbody><tr><td>Intégrité du contenu</td><td>Nombre de flux image dans le conteneur</td></tr><tr><td>Qualité du signal</td><td>Résolution de capture, profondeur d'échantillonnage, nombre d'échantillons</td></tr><tr><td>Restitution exacte de la couleur</td><td>Modèle couleur, espace de couleur</td></tr><tr><td>Description embarquée</td><td>Métadonnées descriptives et techniques internes (IPTC, XMP, EXIF)</td></tr></tbody></table>

#### 3.1.1.2. Formats

##### Formats connus par la BnF

1. JPEG 2000 conforme au référentiel BnF
TIFF v6 monopage sans compression

<footnote n="31">³¹ Le cas des images vectorielles n'est pas traité dans cette version de la politique de formats.</footnote>

<footnote n="33">³³ Voir l'article « Quadrichromie » de l'encyclopédie Wikipédia, disponible sur https://fr.wikipedia.org/wiki/Quadrichromie (consulté le 24 mars 2021).</footnote>
<figure><img src="image_34.png" /></figure>

* Trajectoire de préservation envisagée : la BnF étudie la conversion rétrospective de ses images TIFF couleur vers le JPEG 2000 à l'aide de l'outil kakadu.

2. **TIFF** noir et blanc compression CCITT groupe 4
**TIFF** compression LZW

* Trajectoire de préservation : la BnF décompresse les TIFF contenant un flux image LZW avant versement à l'aide de la bibliothèque logicielle libtiff.
**JPEG 2000** compression sans perte
**JFIF (JPEG)**

## Autres formats reconnus par la communauté

- **PDF** multipage embarquant des images JPEG ou JPEG 2000

- **PNG**

- **DJVU**

- **TIFF** 48 bits (16 bits par couche)

### 3.1.2. Photographies nativement numériques

On entend par « photographies numériques » des prises de vue visant à représenter des scènes avec profondeur de champ, par opposition à la numérisation de documents patrimoniaux. Cette section concerne par conséquent les images issues de dispositifs matriciels (appareils photo), visant à enregistrer en deux dimensions des scènes en trois dimensions. Par exemple : photographies de paysages, de personnes, d'objets, etc.

#### 3.1.2.1. Propriétés des photographies numériques

<table><thead><tr><td>Propriété signifiante</td><td>Propriété(s) concrète(s)</td></tr></thead><tbody><tr><td>Qualité du signal</td><td>Définition, profondeur d'échantillonnage, nombre d'échantillons</td></tr><tr><td>Restitution exacte de la couleur</td><td>Modèle couleur, espace de couleur</td></tr><tr><td>Description embarquée</td><td>Métadonnées descriptives et techniques internes (IPTC, XMP, EXIF)</td></tr></tbody></table>

#### 3.1.2.2. Formats

##### Formats connus par la BnF

1. **TIFF** v6 monopage sans compression
**EXIF** JPEG
**JFIF (JPEG)**

2. **TIFF** compressé (sauf compression JPEG)

* Trajectoire de préservation : les flux images contenus dans des fichiers TIFF et compressés selon une méthode réversible sont décompressés avant versement dans le système de préservation.

## Autres formats reconnus par la communauté

- JPEG XT (dont JPEG HDR) (ISO/IEC 18477)

- DNG

### 3.1.3. Œuvres graphiques

Cette section traite de documents nativement numériques produits par combinaison d'éléments divers (photographies, images vectorielles, textes) pour obtenir une image fixe destinée à la communication (affiche, flyer, autocollant, logo, image publicitaire, etc.).

Pour ce type de contenu, la composition et la mise en page sont signifiantes. Il est donc nécessaire d'embarquer dans le fichier (en l'occurrence, au format PDF) les polices utilisées dans les éléments textuels afin que la restitution puisse être fidèle au cas où celles-ci ne se trouveraient pas sur l'équipement de visualisation. Néanmoins, afin d'en éviter la récupération, il est possible de n'embarquer que la partie des caractères effectivement utilisée dans les éléments textuels. La vectorisation de ces éléments est également envisageable.

#### 3.1.3.1. Étape de création

Il s'agit de versions intermédiaires et esquisses préparatoires documentant tout ou partie des étapes successives d'élaboration de l'objet graphique.
<figure><img src="image_35.png" /></figure>

En complément de ces images matricielles témoignant du processus itératif de création, la BnF peut choisir de collecter également les fichiers de projet du logiciel de création ainsi que les fichiers sources (photographies, éléments graphiques, polices).

## Formats connus par la BnF

1. TIFF v6 monopage sans compression

2. JFIF (JPEG).

PDF multipages

### 3.1.3.2. Étape de finalisation

Il s'agit de la version stabilisée destinée à un système d'impression (ou, éventuellement à une publication en ligne), quand on souhaite conserver le fichier ayant servi à l'impression en remplacement ou en supplément d'un tirage sur support physique.

## Formats connus par la BnF

1. PDF/X.

2. PDF

TIFF v6 monopage sans compression

JFIF (JPEG).

## 3.2. Contenus textuels

On entend par « contenus textuels » les représentations du langage naturel sous forme de systèmes d'écriture. Pour l'ensemble des contenus textuels, la BnF préfère l'usage systématique de l'encodage UTF-8, et non ISO Latin-1 par exemple. Aujourd'hui très majoritaire sur Internet, UTF-8 prend en charge l'intégralité du répertoire Unicode. Conséquemment, il permet de gérer des textes dans la quasi-totalité des systèmes d'écriture et alphabets du monde.

### 3.2.1. Texte brut ou semi-structuré

Cette section concerne le texte brut, c'est-à-dire la simple représentation de caractères sans information de structure, d'apparence ou de présentation, et le texte semi-structuré grâce à un langage de balisage. Les formats de cette section sont principalement utilisés, à la BnF, pour la numérisation de documents textuels. La plupart des formats ainsi utilisés présentent des dépendances envers les fichiers image (voire envers certains autres fichiers texte).

#### 3.2.1.1. Propriétés du texte brut ou semi-structuré

<table><thead><tr><td>Propriété signifiante</td><td>Propriété(s) concrète(s)</td></tr></thead><tbody><tr><td>Structuration de l'information</td><td>Syntaxe de balisage, langage de balisage</td></tr><tr><td>Encodage du texte</td><td>Codage des caractères, taille d'un caractère en octets, ordre des bits, codage des fins de ligne</td></tr></tbody></table>

Pour le texte brut ou semi-structuré, le format des métadonnées de caractérisation enregistré par la BnF est le format textMD<fnref n="34" />.

#### 3.2.1.2. Structuration physique

Les formats listés ci-dessous permettent d'encoder le résultat d'un procédé de reconnaissance optique des caractères (OCR) et de décrire la segmentation d'un texte en éléments sémantiques.

## Format connu par la BnF

- XML-ALTO

## Formats reconnus par la communauté

- hOCR

- Plain text TXT, ASCII ou UTF-8

<footnote n="34">³⁴ Bibliothèque du Congrès, Technical Metadata for Text, site web officiel, dernière modification le 10 mars 2021, disponible sur http://www.loc.gov/standards/textMD/ (consulté le 10 mars 2021).</footnote>
<figure><img src="image_36.png" /></figure>

- PAGE XML

### 3.2.1.3. Structuration intellectuelle

Les formats listés ci-dessous permettent notamment d'encoder le résultat d'un procédé de reconnaissance optique de la mise en page (OLR) et de décrire la structure logique d'un texte.

#### Formats connus par la BnF

1. XML-METS

2. XML-tdmNum

#### Formats reconnus par la communauté

- XML-TEI avec fichier ODD correspondant

- TEI lite

### 3.2.2. Documents textuels / texte formaté

On réunit dans cette catégorie les contenus textuels nativement numériques dont la finalité est généralement la publication. Ils peuvent également prendre place dans un processus de recherche ou de création, artistique ou intellectuelle pour lesquels la mise en page et l'apparence formelle sont souvent des propriétés signifiantes. Les formats présentés ci-dessous sont donc généralement des conteneurs capables d'embarquer d'autres types de contenu<fnref n="35" /> (images, voire contenu audiovisuel ou interactif). Les autres types de contenus bureautiques (tableurs, présentations, etc.) seront traités dans une autre section à l'occasion d'une version suivante de cette politique.

Dans le cas où on lui soumettrait un document textuel à une étape antérieure à celle de la finalisation, par exemple afin de documenter la genèse d'une œuvre écrite, la BnF conservera, en plus du (des) fichier(s) dans un des formats de création ci-dessous, une version convertie dans un format de finalisation afin de conserver sa mise en page et limiter les risques de restitution incorrecte, beaucoup plus importants dans le cas des formats de création.

#### 3.2.2.1. Propriétés des documents textuels

<table><thead><tr><td>Propriété signifiante</td><td>Propriété(s) concrète(s)</td></tr></thead><tbody><tr><td>Intégrité des éléments constituants</td><td>Nombre de pages, de paragraphes, de lignes et de caractères<br/>Nombre de composants audiovisuels</td></tr><tr><td>Qualité des éléments non textuels embarqués</td><td>Compression des images et des composants audiovisuels</td></tr><tr><td>Autres contenus embarqués</td><td>Fichiers encapsulés</td></tr><tr><td>Représentation fidèle des éléments textuels</td><td>Polices utilisées, embarquement partiel ou total des polices</td></tr><tr><td>Fonctionnalités additionnelles</td><td>Liens, commentaires, marques de révision, filigrane</td></tr><tr><td>Traces d'usage</td><td>Temps d'édition, nombre d'enregistrements successifs, modifications incrémentales, historique de modification</td></tr><tr><td>Description embarquée</td><td>Métadonnées descriptives internes ( titre, auteur, langue, mots-clés, outil de création)</td></tr></tbody></table>

#### 3.2.2.2. Étape de création

#### Formats connus par la BnF

- OpenDocument Text (ODT)

- Format textuel Office Open XML (DOCX)

<footnote n="35">³⁵ On notera de ce fait que les types MIME des formats de texte brut ou semi-structuré présentent un type « text », (ex. : « text/xml ») alors que ceux des formats de documents présentent un type « application » (ex. : « application/pdf »).</footnote>
<figure><img src="image_37.png" /></figure>

## Formats reconnus par la communauté

- LaTeX

- RTF

### 3.2.2.3. Étape de finalisation

La BnF négocie avec les Producteurs afin que les documents collectés ou reçus par elle au titre du dépôt légal ne comportent aucune mesure technique de protection (DRM) susceptible d'entraver les opérations de préservation qu'elle mettra en œuvre.

#### Formats connus par la BnF

1. EPUB 3

2. PDF/A-1 ou PDF/A-2, toutes variantes

3. PDF

4. EPUB 2

DAISY Digital Talking Book avec texte integral

### 3.3. Contenus sonores

On entend par « contenu sonore » l'enregistrement sous forme numérique d'ondes acoustique <fnref n="36" />. Leur représentation numérique repose sur la mesure par échantillonnage de la fréquence de l'onde sonore (en nombre de cycles par seconde) avec une précision d'encodage utilisant plus ou moins d'espace mémoire (mesurée en nombre de bits par échantillon). Afin d'enregistrer cet ensemble de mesures, la BnF privilégie l'encodage PCM (pulse code modulation, modulation par impulsions et codage), qui constitue la base des flux audio contenus dans les formats préférés par la BnF (WAVE non compressé, FLAC compressé sans perte, MPEG-1/2 layer 3 (MP3) compressé avec pertes). Un encodage du contenu en DSM (delta-sigma modulation), considéré par la BnF comme plus fidèle au signal analogique d'origine, est également demandé pour la numérisation des bandes master de production.

Dans le cas d'un encodage PCM, la BnF numérise les contenus sonores en 24 bits (profondeur d'échantillonnage) et 96 kHz (fréquence d'échantillonnage), ou 48 kHz dans le cas de contenus sonores synchronisés avec de la vidéo. D'autres valeurs sont également acceptées pour des contenus sonores produits par d'autres entités, parmi lesquelles les combinaisons habituelles sont les suivantes :

* 16 bits / 44,1 kHz (qualité dite « CD ») ;

* 16 bits / 48 kHz ;

* 24 bits / 48 kHz ;

* 24 bits / 88,2 kHz ;

* 24 bits / 192 kHz.

De manière générale, on évitera les procédés de sur-échantillonnage (upsampling) et d'interpolation, ainsi que tout procédé de ré-encodage d'un flux compressé avec pertes dans un format non compressé ou compressé sans perte.

#### 3.3.1. Propriétés des contenus sonores

<table><thead><tr><td>Propriété signifiante</td><td>Propriété(s) concrète(s)</td></tr></thead><tbody><tr><td>Durée</td><td>Durée de lecture globale, durée de chaque flux.</td></tr><tr><td>Qualité du signal</td><td>Profondeur d'échantillonnage, fréquence d'échantillonnage, débit</td></tr><tr><td>Représentations alternatives du contenu</td><td>Nombre, langue et usage des pistes</td></tr><tr><td>Représentations complémentaires du contenu</td><td>Nombre et disposition des canaux</td></tr><tr><td>Information de synchronisation</td><td>Timecode de départ</td></tr></tbody></table>

<footnote n="36">³⁶ Pour une présentation plus complète de ce type de contenu, on se reportera au document suivant :</footnote>
<figure><img src="image_38.png" /></figure>

<table><tr><td>Description embarquée</td><td>Métadonnées descriptives internes (RIFF, ID3, APE, BWF, Vorbis, etc.)</td></tr></table>

La BnF extrait ces données pour les contenus sonores, le format des métadonnées de caractérisation enregistré par la BnF est le format MPEG-7³⁷.

### 3.3.2. Formats

La BnF a fait le choix du format FLAC comme format de contenu sonore privilégié en raison de ses caractéristiques favorables à la conservation à long terme, en particulier sa compacité liée à son algorithme de compression sans perte et sa capacité de préserver les éléments additionnels présents dans les conteneurs d'origine (notamment des métadonnées internes ou des blocs de données propriétaires) dans le fichier FLAC compressé. Pour sa fonctionnalité d'embarquement de métadonnées spécialisées, notamment celle du *timecode*, le format BWF, restriction de WAVE, est une alternative que la BnF a également étudiée. De même, le format DSD est choisi pour la numérisation de bandes dites « master » et est de ce fait susceptible d'être accepté s'il est confié à la BnF par des producteurs.

En cas d'absence de contenus dans un format plus qualitatif, la BnF accepte également les formats compressés avec pertes AAC et MPEG-1/2 layer III (MP3), considérant que ces derniers ne posent pas, à l'heure de la rédaction de ce document, de problèmes de préservation à long terme.

Dans le cas de son nativement numérique, d'autres formats peuvent également être pris en charge par la BnF, moyennant éventuellement un ré-empaquetage et/ou transcodage dans des formats maîtrisés par la BnF. **Les producteurs souhaitant confier des contenus sonores dans d'autres formats que ceux cités ci-dessous sont invités à contacter la BnF pour déterminer la démarche à adopter.**

#### 3.3.2.1. Son numérisé

Cette section concerne les contenus issus de la numérisation de phonogrammes analogiques ou de la dématérialisation de phonogrammes numériques.

##### Formats connus par la BnF

1. BWF / MBWF s'il est souhaitable d'enregistrer une information de *timecode* ou du multicanal DSD si le support original est un master de production FLAC dans les autres cas

2. WAVE / WAVE RF64

➤ Trajectoire de préservation envisagée : la BnF étudie actuellement l'opportunité de convertir ses fichiers WAVE en FLAC grâce à l'outil *flac*.

3. MPEG-1/2 layer 3 (MP3)

#### 3.3.2.2. Son nativement numérique

Cette section concerne les contenus produits nativement sous forme numérique.

##### Formats connus par la BnF

1. **FLAC**
   BWF / MBWF
   WAVE / WAVE RF64
   DSD

2. **MPEG-1/2 layer 3 (MP3)**
   MP4 AAC-AIFF

➤ Trajectoire de préservation : la BnF opère un ré-empaquetage et transcodage vers FLAC grâce à l'outil *flac*.

##### Format reconnu par la communauté

- OGG Vorbis

<footnote n="37">³⁷ MPEG-7, sur le site web du Moving Picture Experts Group, disponible sur https://mpeg.chiariglione.org/standards/mpeg-7 (consulté le 31 mars 2021).</footnote>
<figure><img src="image_39.png" /></figure>

## 3.4. Images animées

On entend par image animée une séquence d'images fixes cadencées pour être perçues comme un mouvement continu. Sa représentation numérique résulte de l'acquisition (conversion) d'un signal analogique ou provient d'un flux nativement numérique, et de l'encodage (compressé ou non) dans un format spécifique d'une série d'images à une fréquence régulière exprimée en images par seconde, dans une résolution, avec une profondeur de couleur donné, dans un certain espace colorimétrique et un ratio d'image précis. L'ensemble de ces données, souvent synchronisées avec des pistes sonores et des sous-titres, sont enregistrées dans un fichier conteneur.

La BnF préfère généralement obtenir les documents nativement numériques soit dans un état finalisé (formats dits « mezzanine » ou « pivot ») soit dans un état diffusé (voir les étapes du cycle de production en section 2.6). De ce fait, elle privilégie les images animées compressées avec pertes selon une compression inter-trame (état diffusé) ou intra-trame (état finalisé). Dans le cas de la numérisation, la BnF a également étudié le format FFV1, dans lequel elle peut recevoir des images animées.

La BnF déconseille les procédés de sur-échantillonnage (upsampling) et d'interpolation, ainsi que tout procédé de ré-encodage d'un flux compressé avec pertes dans un format non compressé ou compressé sans perte.

### 3.4.1. Propriétés des images animées

<table><thead><tr><td>Propriété signifiante</td><td>Propriété(s) concrète(s)</td></tr></thead><tbody><tr><td>Durée</td><td>Durée de lecture globale, durée de chaque flux.</td></tr><tr><td>Qualité du signal</td><td>Définition, profondeur d'échantillonnage, débit, sous-échantillonnage de la chrominance, cadence</td></tr><tr><td>Restitution exacte de la couleur</td><td>Modèle couleur, espace de couleur</td></tr><tr><td>Usage (post-production ou diffusion)</td><td>Group of pictures (GOP)</td></tr><tr><td>Représentations alternatives du contenu</td><td>Nombre, langue et usage des pistes vidéo</td></tr><tr><td>Information de synchronisation</td><td>Timecode de départ</td></tr><tr><td>Description embarquée</td><td>Métadonnées descriptives internes</td></tr></tbody></table>

Pour les images animées, le format des métadonnées de caractérisation enregistré par la BnF est le format MPEG-7³⁸. Les métadonnées suivantes sont encodées selon le formalisme suivant.

### 3.4.2. Formats

1. MP4 H.264
   Matroska FFV1

2. MPEG-PS H.262 MPEG-2 layer II

3. MOV ProRes

* Trajectoire de préservation : les fichiers MOV ProRes sont conservés tels quels mais sont complétés au versement par une version au format MP4 H.264 à l'aide de l'outil *ffmpeg*, si cette dernière n'est pas fournie par le Producteur.

### 3.4.3. DVD vidéo

Cette section détaille les choix faits par la BnF pour le traitement de DVD vidéo, définis comme des ensembles de titres vidéo accompagnés la plupart du temps de son et de texte synchronisé. Le contenu des DVD vidéo consistant majoritairement en des images animées, il suit les politiques mentionnées dans les sections dédiées de ce document en matière de métadonnées de caractérisation. Néanmoins, comme il est souhaitable de préserver en plus des images animées le contenu interactif de ces documents (essentiellement constitué des menus), la BnF a défini une politique différente en matière de format de

<footnote n="38">³⁸ MPEG-7, sur le site web du Moving Picture Experts Group, disponible sur https://mpeg.chiariglione.org/standards/mpeg-7 (consulté le 31 mars 2021).</footnote>
<figure><img src="image_40.png" /></figure>

préservation, reposant sur l'empaquetage du système de fichiers DVD dans un conteneur compatible UDF.

### 3.4.3.1. Format

Structure et arborescence d'origine du DVD<fnref n="39" /> empaquetées dans une image disque UDF

* Trajectoire de préservation : copie du contenu du DVD<fnref n="40" /> puis transformation de l'arborescence en une image disque grâce à l'outil MKISOFS.

### 3.4.4. Texte synchronisé à un contenu vidéo

Cette catégorie comprend tous les contenus textuels synchronisés à un contenu vidéo, c'est-à-dire dont les composantes sont associées à une information temporelle en référence à un contenu temporel constitué d'images animées. Entrent dans cette catégorie les sous-titres, les sous-titres pour sourds et malentendants et tout type de description telle que les commentaires du créateur ou de la créatrice. Ces contenus peuvent se trouver soit embarqués dans un conteneur multimédia, soit dans un fichier distinct.

#### 3.4.4.1. Propriétés du texte synchronisé

<table><thead><tr><td>Propriété signifiante</td><td>Propriété(s) concrète(s)</td></tr></thead><tbody><tr><td>Référence au contenu vidéo</td><td>Conventions de nommage des fichiers</td></tr><tr><td>Usage</td><td>Type et langue des sous-titres, caractère forcé ou non</td></tr><tr><td>Complétude des composants textuels</td><td>Nombre de blocs, <i>timecode</i> du premier bloc, <i>timecode</i> du dernier bloc</td></tr><tr><td>Intégrité des composants textuels</td><td>Codage des caractères</td></tr></tbody></table>

#### 3.4.4.2. Formats

- MPEG-4 Timed Text

- SRT

- EBU-STL

- EBU-TT

Autre format reconnu par la communauté :

- WebVTT

### 3.5. Contenus web

Il s'agit ici de fichiers issus de la collecte de contenu web par robots, et empaquetés de sorte à être rendus exploitables par un moteur d'indexation et par un outil de visualisation dans leur contexte.

#### 3.5.1. Métadonnées techniques de caractérisation produites par la BnF

Afin de décrire les caractéristiques du conteneur WARC et d'agréger des informations sur les fichiers contenus (poids maximal et minimal, poids total, etc.) par format, la BnF a créé un format de métadonnées adapté à la description des fichiers conteneurs, containerMD. Pour le moment limité à la description des fichiers ARC et WARC, il pourra être étendu à d'autres formats.

#### 3.5.2. Formats

1. WARC 1.0

2. ARC 1.0, 1.1 et 2.0

<footnote n="39">³⁹ Le document suivant décrit précisément la structure en question : *Inside DVD-Video*, Wikibooks, accessible sur https://en.wikibooks.org/wiki/Inside_DVD-Video (consulté le 10 mars 2025).</footnote>

<footnote n="40">⁴⁰ Il sera porté une attention particulière à la suppression des mesures de protection (CSS en particulier) lors de cette opération de copie.</footnote>
<figure><img src="image_41.png" /></figure>

## 3.6. Contenus cartographiques

Les contenus cartographiques se caractérisent par la représentation géométrique, conventionnelle et en positions relatives de phénomènes localisables dans l'espace à un moment donné. Elle a pour corollaire la modélisation de ces phénomènes comme des objets possédant des caractères géométriques (forme, localisation absolue, éventuellement relations spatiales) et sémantiques (attributs et relations sémantiques) explicitement décrits et liés.

S'y rattachent les images de télédétection dont la sémantique n'est pas explicitement définie mais qui sont construites selon les règles géométriques de la représentation cartographique.

La section a pour noyau les données qui encodent explicitement tout ou partie des propriétés de la représentation cartographique. Elles se caractérisent par l'utilisation de deux modes logiques de représentation des géométries, matriciel et vectoriel, dont les formes sont directement géoréférencées. L'association à ces géométries d'attributs sémantiques explicitement encodés est variable. Ces données sont couramment nommées en français « données géographiques », « données spatiales » ou « données cartographiques »<fnref n="41" />.

La section est potentiellement ouverte aux données qui expriment une représentation cartographique sans encoder explicitement une de ses caractéristiques. A ce stade cependant, la BnF estime qu'elles peuvent être préservées par des dispositions communes à l'ensemble des images fixes (cartes statiques non-géoréférencées), des contenus textuels (atlas homothétiques) ou des documents multimédia (cartes interactives dépendantes d'une plateforme) et les classe dans ces domaines.

Sont exclues de la section les fichiers possédant des métadonnées de géoréférencement mais dont le contenu est étranger à la représentation cartographique (photographies, vidéos, pages HTML ou SMS géotaguées) et les bases de données de statistiques géographiques indirectement géoréférencées, sans géométries décrites.

Toute la section se rapporte pour le moment à des documents à l'étape de la diffusion dans le cycle de production des données.

### 3.6.1. Propriétés communes à tous les contenus cartographiques

<table><thead><tr><td>Propriété signifiante</td><td>Propriété(s) concrète(s)</td></tr></thead><tbody><tr><td>Localisation absolue des objets graphiques</td><td>Système de référence (CRS) en WKT ou EPSG.</td></tr><tr><td>Forme des objets graphiques</td><td>Type de géométrie : vectorielle ou maillée.</td></tr><tr><td>Métadonnées</td><td>Dates, coordonnées du rectangle englobant, généalogie des données, langue et encodage des caractères de la représentation, identifiants, paramètres de qualité.</td></tr></tbody></table>

### 3.6.2. Cartes statiques et orthophotographies géoréférencées

Dans ces documents, une partie de la modélisation cartographique n'est accessible que visuellement, sous forme d'image, mais la localisation absolue des objets graphiques, qui possèdent des valeurs colorimétriques, est explicitement encodée dans les données.

#### 3.6.2.1. Propriétés des cartes statiques et orthophotographies géoréférencées

<table><thead><tr><td>Propriété signifiante</td><td>Propriété(s) concrète(s)</td></tr></thead><tbody><tr><td>Localisation et résolution spatiale des objets graphiques.</td><td>Modèle de transformation entre les objets graphiques de l'image et leurs coordonnées projetées.<br/>Echelle et résolution de la représentation graphique dans une unité connue.</td></tr><tr><td>Formes, relations spatiales et sémantique des objets cartographiques (image).</td><td>Nombre de flux image, nombre d'échantillons, profondeur d'échantillonnage, définition, modèle couleur, espace de couleur.<br/>Découpage et/ou mosaïquage des données, s'il y a lieu.</td></tr></tbody></table>

<footnote n="41">⁴¹ Il n'existe pas de consensus sur les périmètres exacts recouverts par ces termes et le recours à des sous-catégories mieux définies, lorsqu'il est possible, demeure préférable.</footnote>
<figure><img src="image_42.png" /></figure>

<table><tr><td>Règles de la représentation cartographique</td><td>Légende de la sémiologie graphique, si elle n'est pas portée sur la représentation pour les cartes statiques.</td></tr></table>

### 3.6.2.2. Cartes statiques géoréférencées

Représentations cartographiques exprimées sous forme d'images, d'accès visuel unique et d'échelle fixe, par opposition aux cartes interactives. La sémantique est explicitement donnée par la légende et les écritures. Les images, nativement numériques ou numérisées, sont issues de la généralisation de multiples sources d'information géographique. Cette sous-section ne concerne pour le moment que des documents matriciels.

#### 3.6.2.2.1. Formats

- GeoTIFF

#### 3.6.2.3. Orthophotographies géoréférencées

Images issues de la télédétection passive assemblées et rectifiées de sorte qu'elles peuvent se superposer à une carte. La sémantique est implicite, l'interprétation de la photographie fait appel à des connaissances cartographiques externes au document, même si la mise en valeur de la signature spectrale de phénomènes particuliers est possible.

#### 3.6.2.3.1. Formats

- GeoJP2⁴²

### 3.6.3. Bases de données géographiques et cartes interactives

Dans ces documents, les composantes géométriques et sémantiques de la modélisation, ainsi que leurs relations, sont explicitement encodées dans les données.

#### 3.6.3.1. Propriétés des bases de données géographiques et cartes interactives

<table><thead><tr><td>Propriété signifiante</td><td>Propriété(s) concrète(s)</td></tr></thead><tbody><tr><td>Forme, localisation, résolution, relations spatiales, sémantique des entités et leurs liens.</td><td>Intégrité, validité et cohérence des couches d'enregistrements de géométries et attributs.<br/>Styles d'affichage cartographique, s'il y a lieu.</td></tr><tr><td>Fonctionnalités interactives de consultation</td><td>Fonctionnalités définies d'accès à la donnée dans le cas des cartes interactives.</td></tr><tr><td>Règles de la représentation cartographique.</td><td>Spécifications de contenu, dont schéma de données et catalogue des objets.<br/>Légende ou norme d'affichage, s'il y a lieu.</td></tr></tbody></table>

#### 3.6.3.2. Bases de données géographiques

Représentations cartographiques exprimées sous forme de données structurées ou semi-structurées destinées à être analysées et retraitées dans les Systèmes d'Information Géographique (SIG), ou tout logiciel adapté, comme un SGBD géographique.

##### 3.6.3.2.1. Formats de bases de données vectorielles

- GeoPackage (GPKG)

- Shapefile (SHP)

##### 3.6.3.2.2. Format de bases de données matricielles

- GeoTIFF

- ASCII Grid

<footnote n="42">⁴² Il s'agit d'un format embarquant les tags GeoTIFF dans un fichier JPEG 2000 (« GeoTIFF in JPEG2000 »).</footnote>
<figure><img src="image_43.png" /></figure>

### 3.6.3.3. Cartes interactives

Représentations cartographiques exprimées sous forme de données structurées ou semi-structurées destinées à l'interrogation, l'analyse et la visualisation interactive à travers une symbologie définie dans des applications dédiées.

#### 3.6.3.3.1. Formats

- S-57 OHI, pour les cartes nautiques vectorielles au standard de l'Organisation hydrographique internationale (ENC)

## 3.7. Notation musicale

La « notation musicale » correspond à ce que le grand public désigne par « partition » : la transcription selon un système codifié d'instructions visant à reproduire une œuvre musicale. Dans le domaine nativement numérique, elle recouvre l'équivalent dématérialisé d'une partition imprimée, destinée à donner des indications à un agent humain sur l'exécution de l'œuvre, mais également des instructions destinées aux machines, fondées sur des systèmes et codes différents. Dans certains cas, cette version numérique peut être interprétée par des logiciels et restituée sous une forme sonore.

### 3.7.1. Propriétés des contenus de notation musicale

La BnF n'a pas encore adopté de méthode d'analyse automatisée des propriétés concrètes des contenus de notation musicale. La conservation des propriétés signifiantes dépend donc actuellement d'un contrôle manuel réalisé par les agents s de l'institution.

<table><thead><tr><td>Propriété signifiante</td><td>Propriété(s) concrète(s)</td></tr></thead><tbody><tr><td>Intégrité des éléments de notation</td><td>Présence et localisation des éléments de notation</td></tr><tr><td>Description embarquée</td><td>Métadonnées descriptives internes</td></tr></tbody></table>

### 3.7.2. Étape de création

Les formats actuellement traités par la BnF à cette étape sont les suivants :

1. MusicXML

2. MUS / MUSX

Dans le cas où des fichiers MUS / MUSX seraient confiés à la BnF, celle-ci en dériverait une version en MusicXML, également conservée. En complément, du fait de la nécessité de disposer de logiciels spécialisés pour restituer les contenus collectés dans ces formats, la BnF produira une version dans une étape de diffusion dans le format préféré parmi la liste citée dans la section ci-dessous.

### 3.7.3. Étape de diffusion

Les formats actuellement traités par la BnF à cette étape sont les suivants :

1. PDF

2. PNG

JFIF (JPEG)

Note : la BnF ayant remarqué que les dernières versions du logiciel Finale produisaient une version PDF (composée d'éléments vectoriels) moins satisfaisante aux yeux de ses spécialistes de la musique notée qu'une sortie dans un format d'image matricielle, on préfère actuellement obtenir une version PDF produite à partir de la concaténation d'images PNG.

## 3.8. Correspondance

La correspondance intègre tous les documents ayant pour contenu principal un échange entre plusieurs interlocuteur ice s. Cette version 2 de la politique de formats ne traite que des messageries électroniques privées mais la section pourra s'enrichir dans de futures versions de considérations sur les SMS et les conversations de groupe sur des applications de messagerie instantanée.
<figure><img src="image_44.png" /></figure>

### 3.8.1. Messageries électroniques

Les formats de messagerie électronique peuvent contenir des éléments complémentaires tels que des agendas, tâches et contacts. La BnF n'a, dans la version 2 de ce document, pas défini de politique pour ces éléments complémentaires.

#### 3.8.1.1. Propriétés des correspondances

La BnF n'a pas encore adopté de méthode d'analyse automatisée des propriétés concrètes des correspondances. La conservation des propriétés signifiantes dépend donc actuellement d'un contrôle manuel réalisé par les agent s de l'institution.

Les formats de messageries choisis par la BnF étant des formats dont la structure est textuelle, les propriétés du texte brut définies en section 3.2.1.1 s'appliquent. En outre, les propriétés suivantes sont définies.

<table><thead><tr><td>Propriété signifiante</td><td>Propriété(s) concrète(s)</td></tr></thead><tbody><tr><td>Intégrité des éléments constituants</td><td>Nombre de messages composant la messagerie</td></tr><tr><td>Métadonnées de la messagerie</td><td>Attributs personnalisés</td></tr><tr><td>Métadonnées de chaque message</td><td>Métadonnées telles que décrites par la RFC 5322</td></tr></tbody></table>

#### 3.8.1.2. Formats

##### Formats connus par la BnF

- MBOX

##### Formats reconnus par la communauté

- Internet Message Format (EML)

- EA-PDF

- PST

- Maildir

### 3.9. Documents multimédia

On entend par document multimédia tout document nécessitant une plateforme d'exécution informatique particulière comprise comme un environnement matériel et logiciel spécifique<fnref n="43" />. Il peut être composé de plusieurs objets numériques de nature différente, pouvant être encapsulés dans un fichier conteneur, de format standard ou propriétaire, de façon à préserver la structuration d'origine et pouvoir être exécuté. Pour cette raison, la stratégie de préservation adoptée par la BnF ne repose pas sur la transformation des données mais sur la simulation de la plateforme d'exécution d'origine généralement assurée par un logiciel dédié appelé émulateur. Aussi n'est-il pas toujours nécessaire de disposer d'une caractérisation fine des éléments qui composent le document afin d'assurer sa communication sur le long terme.

#### 3.9.1. Propriétés des documents multimédia

Pour les raisons signalées ci-dessus, la BnF ne dispose pas toujours d'outil d'analyse automatisée des propriétés concrètes des contenus. Leur description nécessite généralement un contrôle manuel ou s'appuie sur les informations fournies par l'éditeur.

<footnote n="43">⁴³ A noter qu'une fois le décret d'application de la loi Darcos publié, le code du Patrimoine comportera une nouvelle définition du document multimédia élaborée afin de mieux délimiter son périmètre documentaire : « On entend par document multimédia tout document regroupant des données numériques de nature différente tels que textes, sons, images fixes ou animées et un ou plusieurs programmes informatiques permettant l'utilisation de ce document multimédia de manière interactive et lui conférant une identité propre. »</footnote>
<figure><img src="image_45.png" /></figure>

<table><thead><tr><td>Propriété signifiante</td><td>Propriété(s) concrète(s)</td></tr></thead><tbody><tr><td>Complétude du document et/ou de l'objet</td><td>Taille du fichier / Date / Empreinte MD5 / Format / Type de support</td></tr><tr><td>Plateforme(s) d'exécution</td><td>Constructeur, modèle, version</td></tr><tr><td>Dépendance(s) matérielle(s)</td><td>Processeur, carte graphique, autre(s) périphérique(s), etc.</td></tr><tr><td>Environnement(s) logiciel(s)</td><td>Système d'exploitation/ firmware (microcode), composants logiciels</td></tr><tr><td>Présence de MTP</td><td>MTP physique, MTP d'activation, etc.</td></tr></tbody></table>

### 3.9.1.1. Documents sur support

La conservation d'un document multimédia sur support suppose le déchargement des données stockées par copie ou numérisation. Les modalités de cette étape varient en fonction des types de support et s'inscrivent dans une temporalité dépendant de la disponibilité de solutions techniques pour la réaliser.

### 3.9.1.2. Documents nativement dématérialisés

En fonction de la forme du document multimédia dématérialisé livré à la BnF, celle-ci pourra être amenée à encapsuler les données dans un fichier conteneur.

La BnF privilégie la livraison de versions non protégées mais, n'exclut pas d'accepter les versions avec MTP. Elle peut, si besoin, procéder à leur transformation.

La BnF accepte la réception de documents multimédia dématérialisés dont elle ne maîtriserait pas encore les capacités de mise en consultation. En effet, les solutions permettant cette mise en consultation ne sont généralement disponibles que plusieurs années après l'apparition de nouveaux formats.
<figure><img src="image_46.png" /></figure>

# 4. Fiches Format

Les fiches Format suivantes ont pour objectif de décrire chacun des formats listés comme « préférés » ou « acceptés » dans la liste ci-dessus. Certains d'entre eux ne disposent pas encore d'une fiche validée dans cette version du document. Les fiches sont également consultables sur Github (https://github.com/hackathonBnF/FichesFormat/wiki), dans une version mise à jour au fur et à mesure des études et de la veille des experts formats de la BnF.

## 4.1. Structure des fiches

### Description

Une présentation succincte

- De l'expressivité (CPS-EXP) du format, c'est-à-dire de son usage et de ses fonctionnalités ;

- De sa position dans le cycle de production des contenus (capture, création, finalisation, diffusion) ;

- De son histoire et de son contexte de création (permettant notamment à l'institution de déterminer l'adéquation du format entre ses besoins et l'expressivité du format ;

- Ainsi que de son statut : ouvert, c'est-à-dire **documenté** (CPO-DOC) et **libre d'utilisation** (CPO-LIB), ou propriétaire.

On y détaille également d'éventuels intitulés alternatifs sous lesquels est connu le format.

Enfin, on résume en quelques phrases l'adaptation du format à la préservation à long terme (ex. [pour le format MP3](https://www.w3.org/TR/PNG/)).

### Qualité et caractéristiques du flux

Dans le cas d'un format de flux ou « codec », on mentionne ici les caractéristiques minimales et maximales de qualité permises par le format (profondeur et fréquence d'échantillonnage, nombre de canaux, etc.).

### Sociabilité

La section évalue le niveau d'adoption du format (CPO-SOC) et mentionne sa (ses) **communauté(s)** d'utilisateurs et son niveau de support logiciel et matériel (CPO-OUT).

### Relations à d'autres formats

On précise ici :

- Si le format est une extension, une restriction ou s'inspire simplement d'un autre format ;

- Si le format a des ancêtres et/ou des successeurs officiels.

### Versions

La section détaille les différentes versions successives ayant un impact significatif sur la durabilité des données. On évoquera ici le niveau de **stabilité (CPO-STA)** du format. Si le format définit des profils spécifiques (par exemple, « High profile » pour H.264), en particulier s'ils permettent de déduire l'usage prévu du contenu par le créateur, on les mentionnera ici.

### Contenu (pour un format conteneur) / Conteneur (pour un format de flux ou « codec »)

Pour un format conteneur, on détaille ici la nature des contenus additionnels embarqués (CPO-ADD) et leurs usages. La section en lien *Métadonnées internes* fournit plus de détails sur ce type de contenu précis. On précise les formats ou « codecs » embarqués des différents flux de données.

Dans le cas d'un format de flux (ou « codec »), on précisera dans quels conteneurs il peut être embarqué, et s'il existe un rapport particulier avec l'un d'eux.
<figure><img src="image_47.png" /></figure>

## Organisme de maintenance et documentation de référence

Cette section donne l'identifiant du standard / de la norme décrivant le format ou à défaut son site officiel, ainsi que, le cas échéant, de la documentation additionnelle ou des études exhaustives sur le format dans une perspective de préservation à long terme.

Chaque ressource web doit avoir été collectée par Internet Archive ; la référence doit mentionner à la fois la ressource dans cet entrepôt et l'URL actuelle de la ressource. Ex. :

- Spécification du DSF : DSF File Format Specification, Sony, v. 1.01 URL actuelle, version archivée.

Dans le cas où l'URL n'a pas été collectée par IA, on se rend sur le site et on demande la collecte en entrant l'URL dans la fenêtre de texte en bas à droite, intitulée « Save page now ».

## Identifiants

On indiquera dans cette section le(s) identifiant(s) correspondant au format dans les registres de formats Sustainability of Digital Formats de la Bibliothèque du Congrès, Wikidata, PRONOM de The National Archives et le wiki *Just Solve the File Format Problem*.

Extension(s) : on indique ici la ou les extensions officielles ou fréquemment utilisées.

Type(s) MIME : si la fiche décrit un format de fichiers (et non un format de flux, audio ou vidéo en particulier), on indique ici le(s) types MIME, en signalant leur caractère officiel (inscrit à l'IANA) ou non.

## Caractéristiques techniques

On décrira ici les caractéristiques techniques ayant un impact sur la durabilité des données, en particulier sur les critères de **compacité (CPO-COM)**, notamment le ou les algorithme(s) de compression disponibles), **simplicité (CPO-SIM)**, **mécanismes de protection (CPO-PRO)**, **robustesse (CPO-ROB)**, **transparence (CPO-TRA)** et **indépendance / autonomie (CPO-AUT)**.

## Métadonnées internes

Lorsque le format peut embarquer des métadonnées internes, qu'elles soient descriptives, de provenance ou techniques, on signale dans cette section le type d'information et le formalisme de ces métadonnées.

## Outils connus par la BnF

On cite dans cette section les outils que la BnF considère comme particulièrement utiles pour réaliser :

- la caractérisation ;

- la validation ;

- et, le cas échéant, la production ou la transformation.

On précise si l'une des versions de l'outil est préférable à une autre.

## Usage ou présence dans les collections de la BnF

Cette section décrit le ou les usage(s) majoritaire(s) du format à la BnF, et le cas échéant signale dans quels cas des fichiers de ce format ont intégré les collections de l'établissement.
<figure><img src="image_48.png" /></figure>

## 4.2. Android Package (APK)

### Description

Le format APK est un format conteneur permettant d'embarquer dans un fichier unique, fondé sur ZIP, les ressources nécessaires à l'installation d'une application sur un système Android. Il s'agit d'un format de diffusion à un utilisateur final, contrairement à sa variante APK universel et au format lié Android App Bundle.

Le format APK est maintenu par l'Android Open Source Project, mais l'influence sur ce format de Google via sa plateforme de distribution Google Play est de fait prépondérante. Il ne semble pas y avoir de brevets portant sur les composantes du format.

Du fait de sa structure standardisée, de son adoption très large, d'une documentation satisfaisante et de l'utilisation majoritaire de formats ouverts, ce format semble acceptable à la BnF dans une perspective de préservation à long terme. La Bibliothèque du Congrès le considère comme *un de ses formats préférés pour les logiciels*.

### Sociabilité

Le format APK est géré par le système d'exploitation Android, lui-même utilisé par la quasi-totalité des smartphones actuels, mis à part les iPhones. Ces applications sont largement diffusées par le magasin d'applications Google Play, mais également par d'autres dépôts, légaux (F-Droid, par exemple) ou non.

En juin 2021, Microsoft a annoncé que Windows 11 disposerait de *Windows Subsystem for Android (WSA)*, permettant de faire fonctionner des applications Android disponibles sur l'Amazon Appstore sur un ordinateur de bureau équipé de Windows. Néanmoins, Microsoft a par la suite annoncé que cette solution serait abandonnée dès 2025 pour des raisons de rentabilité.

### Relations à d'autres formats

Les fichiers APK sont une restriction du format conteneur Java Archive (JAR), lui-même une restriction du format conteneur ZIP.

Les plateformes de distribution limitant souvent la taille des applications à télécharger à quelques centaines de mégaoctets, on trouve des fichiers APK distribués avec des données supplémentaires dépendantes portant l'extension `.obb`. Il s'agit en réalité de fichiers de format arbitraire, considéré comme tel par Google, d'où le nom « OBB » signifiant *Opaque Binary Blob*. L'ensemble est parfois diffusé par des plateformes tierces sous forme de paquet XAPK (*Extended APK*) (**CPO-AUT**). Les fichiers XAPK sont des fichiers conteneurs ZIP embarquant un fichier APK et ses données OBB liées.

Les APK sont des modules d'application, mais il est également possible de créer des *modules de bibliothèque* distribués avec une extension `.aar` (pour *Android Archive*). Ces fichiers AAR peuvent être déclarés comme dépendances d'applications. Ils ont une structure très similaire aux fichiers APK mais peuvent être identifiés par le fait que leur fichier *AndroidManifest.xml* est un fichier textuel et non binaire selon le formalisme *Android binary XML*, et que leurs classes Java ne sont pas compilées en Dalvik Executable (on note donc à la racine la présence d'un fichier *classes.jar* et non *classes.dex*).

Depuis 2021, les applications Android ne sont plus versées au magasin d'applications Google Play Store sous forme de fichiers APK mais sous forme de fichiers Android App Bundle (extension `.aab`). Ces paquets comprennent plusieurs APK adaptés chacun à un type d'appareil Android. Le format AAB est un format de projet finalisé, comportant toutes les ressources nécessaires à la distribution d'APK signés à l'utilisateur final sur une plateforme telle que Google Play, mais ne peut être installé sur un système Android.

Selon le site *FileInfo*, le site APK Mirror, qui distribuait également les applications APK, ne pouvant pas faire de même avec les fichiers `.aab`, a créé son propre format de paquet d'application, chiffré, utilisable seulement avec son installeur. Ces paquets « Android App Bundle Mirror » portent l'extension `.apkm`.

### Versions

Les applications sont livrées aux plateformes de distribution sous forme d'APK dits « universels » : ces derniers embarquent dans le même conteneur des contenus adaptés à toutes les tailles d'écran. Ils ont de ce fait un poids conséquent. Les plateformes de distribution se chargent ensuite de délivrer à l'utilisateur final un APK spécifiquement adapté à son équipement.

Le format n'a pas de version à proprement parler ; il est cependant dépendant des évolutions du système d'exploitation Android qui a connu de très nombreuses versions majeures depuis son introduction en 2008. Il s'agit donc d'un format en évolution rapide (**CPO-STA**). Des problèmes de rétrocompatibilité sont donc à anticiper.
<figure><img src="image_49.png" /></figure>

On trouve des fichiers APK avec une extension `.apks`; il s'agit d'un APK fractionné (« split ») adapté à un type d'équipement spécifique.

## Contenu

Les fichiers APK contiennent notamment les fichiers suivants :

- `META-INF/MANIFEST.MF`: liste des fichiers contenus dans le paquet et empreinte numérique ;

- `AndroidManifest.xml`: métadonnées du paquet dans un format XML binaire ;

- `classes.dex`: classes Java compilées ;

- `resources.arsc`: ressources compilées.

En outre, ils comportent les répertoires suivants :

- `META-INF`: outre le manifeste, le répertoire contient la signature du paquet ;

- `lib`: répertoire contenant du code compilé spécifique à certaines plateformes ;

- `res`: répertoire contenant des ressources non compilées (des images, par exemple) ;

- `asset`: répertoire contenant les assets de l'application.

## Organisme de maintenance et documentation de référence

Le format APK est maintenu par l*[Android Open Source Project](https://www Android Open Source Project),* mais l'influence de son utilisateur principal, Google, est prépondérante. De fait, les spécifications complètes du format ne sont pas publiées. Néanmoins, le site officiel d'Android, dans ses Guides du développeur, fournit des informations conséquentes sur la structure du format :

- Concepts de base des applications, Android, mis à jour le 2 avril 2024, [URL actuelle](https://en.wikipedia.org/wiki/Android), [version archivée](https://archivewiki.com/en/Android).

## Identifiants

Extensions : apk, apks.

Type(s) MIME non officiel : application/vnd.android/package-archive.

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q596391</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000592</td></tr><tr><td>Just Solve the File Format Problem</td><td>APK</td></tr></tbody></table>

## Caractéristiques techniques

Un APK versé dans un magasin d'applications (en particulier Google Store) doit être signé par le/la développeur se (CPO-PRO). Cette protection contre la falsification peut empêcher l'installation d'applications qui ne seraient pas distribuées via le magasin d'applications officiel.

Du fait de sa nature de conteneur fondé sur ZIP et de formats ouverts tels qu'XML, le format APK est relativement **transparent (CPO-TRA)** : tous les outils manipulant le format ZIP ou le format JAR sont utilisables.

L'indépendance / autonomie (CPO-AUT) du format est également satisfaisante : l'ensemble des ressources nécessaires à l'installation et au fonctionnement de l'application est empaqueté dans un unique fichier conteneur. On notera à ce sujet les points suivants :

- Les bibliothèques logicielles nécessaires au fonctionnement de l'application (mentionnées dans le manifeste dans l'élément `//uses-library/@android:name`), qui peuvent soit être empaquetées dans le fichier APK ou, à défaut, chargées depuis le système d'exploitation ;

- Les dépendances envers des composants matériels sont déclarées dans le manifeste ;

- Une attention cependant doit être apportée aux fichiers OBB associés (appelés *expansion files*) qui sont nécessaires à l'utilisation de l'application. Ces fichiers sont téléchargés automatiquement à l'installation de l'application et stockés séparément dans l'équipement.
<figure><img src="image_50.png" /></figure>

## Métadonnées internes

Des métadonnées internes sont portées par le fichier `AndroidManifest.xml` situé à la racine du conteneur. Il s'agit notamment de :

- `//uses-sdk/@android:targetSdkVersion`: version cible d'Android pour l'application ;

- `//uses-sdk/@android:min SDKVersion`: version minimale d'Android pour l'application ;

- Attributs de l'élément `//supports-screens` (`@anyDensity`, `@small Screens`, `@normal Screens`, `@large Screens`, `@xlarge Screens`): taille(s) d'écran pour laquelle (lesquelles) l'application est prévue (cet élément figure dans les APK universels mais non dans les APK délivrés à l'utilisateur final) ;

- `//uses-feature/@android:name`: autres dépendances matérielles ou logicielles.

Lorsqu'il s'agit d'un APK dit « universel » (voir la section Relations à d'autres formats plus haut), les attributs de l'élément `supports-screens` cités plus haut ont pour valeur `True` (toutes les tailles d'écran sont donc supportées). Cette situation n'est néanmoins pas systématique car certaines applications sont conçues pour fonctionner sur une taille d'écran précise.

Les deux derniers éléments portent un attribut `android:required` valant `True` ou `False`, permettant ainsi d'identifier si le composant est optionnel ou obligatoire.

Pour plus d'informations sur les informations figurant dans le manifeste, on se reportera à la présentation du manifeste de l'application dans le guide du développeur.

On notera que le fichier `AndroidManifest.xml` est au format AXML (Android XML), une variante d'XML sous forme binaire ; pour extraire le fichier et le décoder, il est possible d'utiliser l'outil Androguard avec la ligne de commande suivante :

```
androguard axml monFichier.apk -o manifesteDecode.xml
```

## Outils connus par la BnF

La production d'un fichier APK repose sur la compilation par les outils Android SDK du code (généralement en Kotlin ou en C++) et des ressources additionnelles de l'application. Une liste d'outils en ligne de commande embarqués dans Android SDK est disponible dans le guide du développeur.

Plusieurs outils sont disponibles pour manipuler les fichiers APK ; on citera parmi d'autres le logiciel Androguard.

Concernant la récupération, on notera que des plateformes tierces et des sites miroirs peuvent diffuser des copies de fichiers APK, mais que leur authenticité et leur sécurité ne sont pas garanties. La récupération des applications par les institutions de conservation par ce biais est donc déconseillée.

L'outil `bundletool` permet de produire des fichiers APK soit spécifiques à un type d'équipement, soit « universels », à partir d'un fichier AAB.

## Usage ou présence dans les collections de la BnF

La BnF a déjà collecté un certain nombre d'applications au format APK et envisage le dépôt légal des applications pour mobile préférentiellement sous la variante du format nommée plus haut « APK universel ».
<figure><img src="image_51.png" /></figure>

## 4.3. ASCII Grid

### Description

ASCII Grid ou Esri ArcInfo ASCII Grid est la variante ASCII du format matriciel Esri grid développé en 1991 pour la version 6.0 du Système d'information géographique ArcInfo d'Esri. Les spécifications sont stables et ouvertes par Esri (CPO-LIB, CPO-DOC, CPO-STA).

Le format vise le transfert de données grâce à l'encodage ASCII. Simple et stable, il décrit une matrice sous forme textuelle. ASCII Grid nécessite néanmoins l'usage de fichiers externes complémentaires pour compenser les limites des métadonnées internes. Il permet de constituer des bases de données géographiques matricielles mais ne peut décrire qu'une seule couche de données (bande), interdisant des valeurs sémantiques multiples pour les cellules (CPS-EXP).

Pour la préservation ses handicaps sont le manque de compacité et de robustesse. Ses avantages sont la simplicité, la stabilité et la transparence.

### Sociabilité

Le format ASCII Grid est utilisé pour la diffusion des modèles numériques de terrain, par exemple ceux de l'IGN français, du Service Hydrographique et Océanographique de la Marine (bathymétrie), d'Ordnance Survey (Royaume-Uni) ou, par le passé, de l'USGS (Etats-Unis). Il est néanmoins de plus en plus éclipsé par l'usage d'autres formats, notamment le GeoTIFF.

En préservation numérique, le format n'est pas cité dans la recension de l'OPF ni dans les formats recommandés par la LoC (qui le documente). Le format d'archivage de l'IGN française pour son MNT est le BIL (Band Interleaved by Line) 32 bits flottant, ASCII Grid étant beaucoup plus volumineux (CPO-SOC).

Le format est pris en charge par les principaux systèmes d'information géographique, notamment QGIS et ARCGIS. Il est lu par la bibliothèque GDAL (CPO-OUT).

### Relations à d'autres formats

Esri Grid possède, à côté d'ASCII Grid, une variante binaire nommée ESRI ArcInfo Grid, Arc/Info GRID ou Arc Grid dont l'extension est .adf.

### Versions

Esri publie une spécification dans la documentation d'ArcMap 10.8 de 2020.

### Contenu

L'en-tête décrit les caractéristiques de base de la grille :

<table><thead><tr><td>Paramètre</td><td>Description</td><td>Conditions requises</td></tr></thead><tbody><tr><td>NCOLS</td><td>Nombre de colonnes de cellules</td><td>Nombre entier supérieur à 0.</td></tr><tr><td>NROWS</td><td>Nombre de lignes de cellules</td><td>Nombre entier supérieur à 0.</td></tr><tr><td>XLLCENTER ou XLLCORNER</td><td>Coordonnées X de l'origine (centre ou coin inférieur gauche de la cellule)</td><td>Correspond au type de coordonnée y.</td></tr><tr><td>YLLCENTER ou YLLCORNER</td><td>Coordonnées Y de l'origine (centre ou coin inférieur gauche de la cellule)</td><td>Correspond au type de coordonnée x.</td></tr><tr><td>CELLSIZE</td><td>Taille de cellule</td><td>Supérieur à 0.</td></tr><tr><td>NODATA_VALUE</td><td>Valeurs en entrée destinées à être des valeurs NoData dans le raster en sortie</td><td>Facultatif. La valeur par défaut est -9999.</td></tr></tbody></table>

Les données de la grille suivent l'ordre des informations données dans l'en-tête.

Exemple :

ncols 480
nrows 450
xllcorner 378923
<figure><img src="image_52.png" /></figure>

yllcorner 4072345
cellsize 30
nodata_value -32768
43 2 45 7 3 56 2 5 23 65 34 6 32 54 57 34 2 2 54 6
35 45 65 34 2 6 78 4 2 6 89 3 2 7 45 23 5 8 4 1 62 ...

Interprétation : la grille contient 480 colonnes, 450 lignes, le coin inférieur gauche a pour coordonnées (378923, 4072345), les cellules mesurent 30 unités et la valeur -32768 dans une cellule représente une absence de valeur.

## Organisme de maintenance et documentation de référence

La spécification est diffusée par Esri sur son site.

La structure très simple du fichier est également décrite sur Wikipedia ou le site de la LoC. Le squelette donné dans la section « contenu » ci-dessus, tiré des spécifications d'Esri, en est un résumé.

## Identifiants

Extension : .asc

Type MIME : text/plain

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q27349828</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000421</td></tr></tbody></table>

## Caractéristiques techniques

ASCII Grid n'est pas un format compact, l'encodage textuel le rend plus volumineux que ses concurrents binaires comme GeoTIFF ou NetCDF. De plus il n'existe pas de mécanisme de compression intégré (CPO-COM).

ASCII Grid est un format simple dans sa structure et sans compression (CPO-SIM). Il est lisible par les humains dans un éditeur de texte (CPO-TRA).

L'utilisation cartographique du format nécessite le recours à des fichiers additionnels pour spécifier la correspondance entre la grille et le système de référence (donc les unités de mesure employées) (CPO-AUT).

ASCII Grid ne dispose d'aucune fonctionnalité native pour protéger les données (CPO-PRO). Le format texte est sensible à l'erreur humaine et ASCII Grid ne prévoit pas de mécanismes pour ignorer les sections corrompues (CPO-ROB).

## Métadonnées internes

La structure des métadonnées internes est décrite dans la section Contenu.

Les métadonnées internes renseignent sur la structuration de la matrice décrite dans un espace géométrique. Elles ne peuvent pas, par exemple, décrire de système de référence ou d'unités associées.

Les métadonnées géographiques peuvent être apportées au SIG par un fichier textuel .prj qui utilise le format WKT (Well-Known Text) pour décrire le système de référence ou un World file. A défaut, le système de référence doit être indiqué manuellement au SIG à partir d'autres métadonnées.

D'autres métadonnées se rapportant à chaque cellule de la grille, comme la source des données, peuvent se trouver dans des fichiers Shapefile ou GeoTIFF formant des maillages superposables au fichier ASCII Grid en SIG.

## Outils connus par la BnF

- **Caractérisation** : GDAL avec la commande `gdalinfo` donne l'en-tête du fichier, qui est également accessible avec un simple éditeur de texte.

- **Validation** : GDAL avec la commande `gdalTranslate` permet de tester la validité d'un fichier mais ne rapporte que la première erreur trouvée.

- **Édition** : l'édition et la production de fichiers ASCII Grid est faite à partir de systèmes d'information géographique. La bibliothèque open source GDAL gère également l'ensemble des formats matriciels ou vectoriels géographiques, dont ASCII Grid. Cependant, un éditeur de texte peut aussi en permettre l'édition.
<figure><img src="image_53.png" /></figure>

## Usage ou présence dans les collections de la BnF

La BnF reçoit par dépôt légal le modèle numérique de terrain de l'IGN au format ASCII Grid (éditions à partir de 2018).
<figure><img src="image_54.png" /></figure>

## 4.4. Broadcast Wave Format (BWF) / MBWF (Multi-channel BWF)

### Description

Le format **BWF (Broadcast Wave Format)** a été mis au point par la *European Broadcast Union (EBU) Project Group P/DAPA (Digital Audio Production and Archiving)*, en étroite collaboration avec l'industrie audio. Il vise à fournir un moyen d'échanger des contenus audio entre différents environnements de radiodiffusion, et entre des équipements basés sur différentes plates-formes et systèmes d'exploitation.

Le format Broadcast Wave Format est une spécialisation du format de fichier audio **WAVE**, lui-même fondé sur la structure de fichier *Resource Interchange File Format*. À moins que des éléments de cette fiche les contredisent explicitement, les informations de la fiche WAVE s'appliquent également au format BWF.

À partir de 2006, une évolution de BWF, le MBWF (*Multi-channel Broadcast Wave Format*), est normalisée. Elle correspond à une spécialisation du WAVE RF64 avec des métadonnées BWF pour gérer les fichiers audio plus volumineux (plus de 4 Gio) à la suite de la généralisation des programmes multicaux - cette variante de BWF est également nommée « BW64 ».

Le format BWF dispose de spécifications publiées (**CPO-DOC**) et diffusées gratuitement, et aucun brevet d'utilisation ne porte sur lui (**CPO-LIB**). Sa simplicité, sa transparence et les métadonnées d'échange avancées qu'il spécifie en font un bon format de préservation, bien que l'absence de compression des flux audio qu'il embarque généralement produise des fichiers volumineux (**CPO-COM**).

### Relations à d'autres formats

BWF est une spécialisation du format **WAVE** ; il se distingue de ce dernier par l'ajout d'un *chunk* bext contenant des métadonnées décrites ci-dessous. Néanmoins, les suppléments à la norme EBU Tech 3285 définissant le BWF intègrent des considérations qui touchent à d'autres *chunks* et qui seraient donc à considérer comme des spécialisations de la norme WAVE. En pratique, BWF et MBWF / BW64 sont considérés comme les formats successeurs de WAVE / WAVE RF64.

Le standard ADM (*Audio Definition Model*) définit un autre ensemble de métadonnées décrivant le positionnement et l'usage des pistes/canaux, qui peut également être embarqué dans un fichier WAVE comportant des métadonnées BWF. Ce standard est décrit dans la norme EBU Tech 3364 / ITU R-BS.2076 et son empaquetage dans un fichier WAVE est décrit dans la norme ITU-R BS.2088-1 (section 8) et dans le supplément 7 à la norme EBU Tech 3285 (voir la section « Organisme de maintenance et documentation de référence » ci-dessous).

### Versions

Trois versions successives ont été publiées :

- Version 0, initiale, en 1997 ;

- Version 1, en 2001, qui ajoute un champ pour exprimer un identifiant UMID ;

- Version 2, en 2011, qui ajoute notamment la mesure de l'intensité sonore.

### Contenu

Le format conteneur BWF était, dans sa version 0, prévu pour embarquer un flux PCM, mais autorisait implicitement d'autres formats de flux audio. Le supplément 1 à la norme la précise et décrit l'embarquement de flux aux formats MPEG-1/2 layer I et II.

Comme les fichiers WAVE, les fichiers RIFF sont constitués de blocs de base appelés *chunks*, qui correspondent à des blocs de données contenant un ou plusieurs types d'informations spécifiques. Chaque fichier BWF est composé d'un en-tête de fichier suivi d'un certain nombre de *chunks* dont certains sont obligatoires comme le *chunk* spécial d'extension « bext », tandis que d'autres sont facultatifs.

### Organisme de maintenance et documentation de référence

Le format BWF a été originellement développé par l'EBU sous l'identifiant EBU Tech 3285, qui comprend en plus du document initial sept suppléments :

- EBU Tech 3285, *Specification of the Broadcast Wave Format (BWF) Version 2* ;

- EBU Tech 3285s1-1997 BWF, Supplement 1 : MPEG audio ;

- EBU Tech 3285s2-2001 BWF, Supplement 2 : Capturing Report ;

- EBU Tech 3285s3-2001 BWF, Supplement 3 : Peak Envelope Chunk ;

- EBU Tech 3285s4-2003 BWF, Supplement 4 : chunk ;
<figure><img src="image_55.png" /></figure>

- EBU Tech 3285s5-2018 BWF, Supplement 5: Storing and transferring metadata as XML - axml Chunk;

- EBU Tech 3285s6-2009 BWF, Supplement 6: Dolby Metadata, - dbmd chunk;

- EBU Tech 3285s7-2009 BWF, Supplement 7: ID references from each track in a BWF ADM - chna Chunk.

L'ITU, équivalent international de l'EBU, a adopté cette norme sous l'identifiant ITU-R BS.1352. La version 4 de cette norme comprend la norme EBU Tech 3285 mentionnée ci-dessous et plusieurs de ses suppléments.

En 2015, l'ITU reprend la norme RF64 de l'EBU (EBU Tech 3306) et l'intègre sous l'identifiant ITU-R BS.2088 (dernière version publiée : ITU-R BS.2088-1 en 2019). Pour des précisions supplémentaires sur l'histoire complexe et parfois concurrentielle entre EBU et ITU et les normes que les deux organisations de normalisation portent, on pourra consulter la référence suivante :

Guyton (David), « History of the RIFF/WAVE File Family », datahacker, 18 mars 2020. URL : https://datahacker.blog/home-theater/media-servers/riff-wave-file-family-history.. Consulté le 21 novembre 2024.

D'autres documents de l'EBU, principalement des recommandations, concernent le BWF :

- EBU Tech 3352: THE CARRIAGE OF IDENTIFIERS IN THE BROADCAST WAVE FORMAT (BWF)

- R97-1999: Exchange of sound programmes as BWF files on CD and DVD;

- R98-1999: Format for the CodingHistory filed in BWF files - reprise dans l'annexe 1 de l'ITU-R BS.1352;

- R085-2004: Use of the Broadcast Wave Format for exchange of audio data;

- R111-2007: Multichannel use of the BWF audio file format (MBWF);

- R099-2011: Unique Source Identifier (USID) for use in the field of the Broadcast Wave Format;

L'évaluation de la British Library sur le format WAVE traite également de BWF.

## Identifiants

Extension : devrait être .wav, mais la norme encourage une certaine tolérance des implémentations envers des extensions erronées telles que .bwf, qui se retrouvent parfois dans les données échangées.

Type MIME : audio/x-wav, mais les variantes citées dans la fiche WAVE peuvent aussi exister.

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q27526426 pour le format de fichier BWF, version 0<br/>Q27526471 pour le format de fichier BWF, version 1<br/>Q27526504 pour le format de fichier BWF, version 2</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000356 pour le format de fichier BWF, version 1<br/>fdd000357 pour le format de fichier BWF, version 2<br/>fdd000003 pour le format de fichier BWF, version 1 avec Audio LPCM<br/>fdd000359 pour le format de fichier BWF, version 2 avec Audio LPCM</td></tr><tr><td>PRONOM</td><td>fmt/1 pour le format de fichier BWF, version 0<br/>fmt/2 pour le format de fichier BWF, version 1<br/>fmt/527 pour le format de fichier BWF, version 2<br/>fmt/703 pour le format de fichier BWF, version 0 avec Audio LPCM<br/>fmt/704 pour le format de fichier BWF, version 1 avec Audio LPCM<br/>fmt/705 pour le format de fichier BWF, version 2 avec Audio LPCM<br/>fmt/706 pour le format de fichier BWF, version 0 avec Audio MPEG<br/>fmt/707 pour le format de fichier BWF, version 1 avec Audio MPEG<br/>fmt/708 pour le format de fichier BWF, version 2 avec Audio MPEG<br/>fmt/709 pour le format de fichier BWF, version 0, variante WAVEFORMATEXTENSIBLE<br/>fmt/710 pour le format de fichier BWF, version 1, variante WAVEFORMATEXTENSIBLE<br/>fmt/711 pour le format de fichier BWF, version 2, variante WAVEFORMATEXTENSIBLE<br/>fmt/713 pour le format de fichier BWF RF64</td></tr><tr><td>Just Solve the File Format Problem</td><td>BWF</td></tr></tbody></table>
<figure><img src="image_56.png" /></figure>

## Métadonnées internes

Dans la Version 2 du BWF, le chunk spécial d'extension « bext » peut contenir les champs suivants :

- Version : version de BWF utilisée ;

- CodingHistory : liste des processus d'encodage appliqués aux données audio ;

- Description : champ de description générale du contenu ;

- Originator : nom de la source (producteur) des données audio ;

- OriginatorReference : identifiant préférentiel attribué par le producteur ;

- OriginationDate et OriginationTime : date et heure de création du contenu ;

- TimeReference : timecode en nombre d'échantillons depuis minuit ;

- SMPTE UMID : identifiant Unique Material Identifier ;

- LoudnessValue, LoudnessRange, MaxTruePeakLevel, MaxMomentaryLoudness et MaxShortTermLoudness afin de décrire l'intensité sonore.

En outre, les normes BWF spécifient l'utilisation d'autres chunks pour des besoins complémentaires :

- Dans le chunk lev1, des informations sur les niveaux de crête des signaux audio dans le fichier ;

- Dans le chunk axml, des métadonnées arbitraires au format XML 1.0 ou ultérieur ;

- Dans le chunk qlty, le champ Quality Report qui contient des informations décrivant tous les événements pertinents affectant la qualité du signal sonore enregistré ;

- Dans le chunk qlty, le champ Cue Sheet est une liste d'événements marqués d'un horodatage exact et d'une description plus poussée du signal sonore afin d'établir une « table des matières » (début d'un discours, chapitrage, etc.) ;

- Dans le chunk chna, l'association entre chaque piste du fichier BWF et ses métadonnées ADM (*Audio Definition Model*).

## Outils connus par la BnF

Le module WAVE de l'outil JHOVE intègre dans son processus de validation des contrôles liés à la spécification EBU de WAVE, versions 0 à 2. Il renvoie notamment, dans son rapport d'analyse, la version de BWF utilisée.

L'outil BWF MetaEdit, développé par MediaArea, permet de visualiser et d'éditer toutes les métadonnées internes RIFF/WAVE et BWF recommandées par la Federal Agencies Digital Guidelines Initiative (FADGI) pour les métadonnées internes des fichiers BWF issus de la numérisation à l'aide d'une interface graphique ou d'une interface en ligne de commande.

## Usage ou présence dans les collections de la BnF

Lors des dernières campagnes de dématérialisation de cassettes DAT, la BnF a utilisé le format BWF afin de récupérer dans un standard reconnu un certain nombre de métadonnées techniques et de provenance. Elle s'inspire des recommandations de la Federal Agencies Digitization Guidelines Initiative (FADGI) et définit les valeurs attendues pour certains champs du format BWF, et du format RIFF (chunk INFO). Ces métadonnées sont listées dans la section 10 « Métadonnées internes » du référentiel de format audio.

Des fichiers au format BWF sont entrés dans les collections de la BnF, généralement par don. Il s'agit d'enregistrements issus d'enregistreurs audio professionnels ou de pistes audio transmises séparément de leur contenu vidéo associé.
<figure><img src="image_57.png" /></figure>

## 4.5. DAISY Digital Talking Book

À ses débuts en Suède en 1994, DAISY (Digital Accessible Information System) était un standard propriétaire. Depuis 1997 c'est une norme ouverte recourant à des formats de fichiers standardisés (XML notamment).

### Description

DAISY Digital Talking Book (ou « DAISY DTB ») est un standard développé et maintenu par le Consortium Daisy pour la production de contenus numériques accessibles pour les personnes en situation de handicap. Il met l'accent sur la description structurelle des contenus, les fonctions de navigation, l'association d'une transcription sonore au texte et la description des éléments visuels.

Un livre numérique produit selon le standard DAISY est appelé « Digital Talking Book » (DTB) dans les spécifications NISO (ANSI/NISO Z39.86-2005 (R2012) Specifications for the Digital Talking Book). On rencontre aussi l'appellation « DAISY XML » ou même « DAISY ».

DTBook (aussi appelé « XML DTBook » ou « DAISY XML ») désigne le formalisme XML défini par le standard pour encoder les contenus textuels des livres numériques produit selon le standard DAISY. Il est défini par une DTD XML (DTBook Element Set, dtbook.dtd), également décrite dans les spécifications ANSI/NISO Z39.86-2005.

DAISY DTB est principalement utilisé selon trois déclinaisons :

- audio avec navigation : le contenu audio est fourni, ainsi qu'une structure de navigation au sein du contenu (peut être appelé « DAISY audio »);

- audio et texte synchronisé, avec navigation : le texte complet est fourni, et il est synchronisé avec sa transcription audio (« full DAISY »);

- texte seul, avec navigation : le texte complet est fourni, sans transcription audio (dans ce cas, il est courant de parler de format « DAISY texte »).

### Sociabilité

Le standard DAISY DTB est largement employé pour la création de contenus numériques accessibles sous la forme de livres audio synchronisés avec le plein texte.

### Relations à d'autres formats

DAISY et EPUB sont historiquement liés.

- Le Consortium DAISY a participé à la création du format EPUB au sein de l'IDPF (désormais au sein du W3C). DTBook est un format de contenu accepté par EPUB 2.0.

- Le Consortium DAISY est fortement impliqué dans la création et la maintenance du format EPUB 3, nativement accessible. Il s'est maintenant engagé à utiliser EPUB 3 comme son format principal de distribution ; le standard DTBook n'a donc pas été inclus dans l'EPUB 3.

### Versions

Le format est utilisé en versions 2 (2002) et 3 (2005). Il n'est pas prévu de version 4.

### Contenu

Le standard DAISY définit un ensemble de composants formant un livre numérique DAISY :

- un manifeste au format OEBPS (Open eBook Publication Structure) 1.2, maintenu par l'IDPF;

- des contenus audio et images;

- des contenus textuels conformes à la DTD XML dtbook.dtd;

- une table de navigation au format NCX (Navigation Control file for XML), format également maintenu par le consortium DAISY. La table est généralement dérivée de façon automatique à partir des contenus XML;

- un mécanisme de synchronisation audio/texte basé sur le langage SMIL (Synchronized Multimedia Integration Language) 2.0.

### Organisme de maintenance et documentation de référence

Le consortium DAISY est l'organisme de maintenance. DAISY DTB est un standard NISO (ANSI/NISO Z39.86-2005 (R2012) Specifications for the Digital Talking Book).
<figure><img src="image_58.png" /></figure>

## Identifiants

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q1155804 (le format XML DTBook), Q1151676 (le livre DAISY)</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000053 (version Digital Talking Book. ANSI/NISO Z39.86-2002), fdd000275 (version Digital Talking Book. ANSI/NISO Z39.86-2005)</td></tr></tbody></table>

## Caractéristiques techniques

Outre les points évoqués supra, mentionnons :

- Le support des formats audio MPEG-4 AAC, MPEG-1/2 Layer III (MP3), Linear PCM ;

- Le support des formats image JPEG, PNG, SVG ;

- Le standard ne prévoit pas de méthode de création d'un paquet numérique (telle la restriction ZIP du format EPUB).

## Métadonnées internes

Des métadonnées descriptives peuvent être embarquées dans l'élément `<metadata>` du manifeste, selon le formalisme Dublin Core.

## Outils connus par la BnF

Les contenus XML au format DTBook sont validés conformément à la DTD dtbook 2005-3.

L'outil Pipeline, via le script `DTBookValidator taskScript`, vérifie la conformité du fichier DTBook à la DTD et sa cohérence (fichiers images, notes non référencées, liens sans cible, etc.).

```
pipeline.bat scripts\verify\DTBookValidator taskScript --
input=fichier_a_valider.xml
```

Pipeline permet également de procéder à des transformations de format (XML DTBook vers HTML ou EPUB).

La caractérisation de Daisy Digital Talking Book, comme celle des autres formats XML, est réalisée par le module XML de l'outil Jhove. L'option `withTextMD` permet de produire une sortie au format textMD.

## Usage ou présence dans les collections de la BnF

La BnF utilise le format DTBook, sans manifeste OEBPS ni table de navigation NCX, pour diffuser sur Gallica, sous une forme accessible, les contenus textuels des livres numériques produits au format EPUB 3. Cette production s'appuie sur un référentiel de numérisation (Référentiel DAISY).

Ces formats sont téléchargeables dans la bibliothèque numérique Gallica, en complément des livres numériques EPUB 3.

Le dispositif PLATON (PLAteforme de Transfert d'Ouvrages Numériques) accueille les fichiers d'œuvres adaptées par les organismes transcripteurs dans le cadre de l'exception handicap au droit d'auteur. Ces fichiers sont destinés à l'usage d'un public empêché de lire. Dans ce cadre, la BnF conserve et communique aux organismes habilités, par le biais de PLATON, des fichiers de type XML DTBook (3 980 en 2020), des fichiers DAISY audio en voix humaine et voix de synthèse (38 en 2020), et des fichiers dits « Full DAISY » (texte et audio, voix humaine ou voix de synthèse, 1 en 2020).
<figure><img src="image_59.png" /></figure>

## 4.6. DSD

### Description

Cette fiche décrit à la fois :

- le format de flux audio DSD (Direct Stream Digital) et sa variante compressée, DST (Direct Stream Transfer);

- le format de fichier conteneur DSDIFF (DSD Interchange File Format);

- le format de fichier conteneur DSF (DSD Stream File).

Le DSD est une marque et un procédé de stockage numérique des signaux audio commercialisé par Philips et Sony à partir de 1999. Il est utilisé sur les Super Audio CD (SA-CD) et dans le monde de la production, de l'archivage et de l'édition audio dématérialisée de très haute qualité. Développé par des entreprises privées, le format est propriétaire (CPO-LIB) mais sa spécification est publiée par Philips (CPO-DOC). Le DSD utilise une méthode d'encodage des signaux analogiques en signaux numériques appelée modulation Sigma Delta (SDM) sur un bit à une fréquence très élevée, concurrente de la méthode PCM (Pulse-code modulation).

Le format conteneur DSDIFF (Direct Stream Digital Interchange File Format, extension : .dff), mis au point par Philips en 2000, est utilisé dans le monde de la production musicale. Le format conteneur DSF (DSD Stream File, extension : .dsf) mis au point par Sony apparaît en 2005. Il est très similaire au précédent mais est optimisé pour l'échange par streaming et inclut des métadonnées au format ID3v2 permettant notamment d'embarquer des visuels.

### Sociabilité

Originellement conçu pour encoder du son sur le Super Audio CD (SA-CD), le DSD était dans la décennie 2000 échangé dans un conteneur DSDIFF exclusivement à l'étape de production. Il est désormais également utilisé pour l'échange de son nativement dématérialisé, souvent embarqué dans un conteneur DSF. Malgré l'élargissement de ces usages, le format reste relativement spécialisé et est destiné aux professionnels ou aux audiophiles.

### Relations à d'autres formats

Les formats conteneurs DSDIFF et DSF sont inspirés du format Interchange File Format, dont ils héritent la structure en chunk mais sans les limites de taille.

Afin de permettre l'édition et le mastering, le signal DSD doit être converti en DXD (Digital eXtreme Definition) pour être traité. Le DXD est un flux audio PCM à une profondeur d'au moins 24 bits et à une fréquence d'échantillonnage de 352,8 kHz, embarqué dans un conteneur FLAC ou WAVE.

### Versions

Les versions actuelles des formats sont les suivantes (CPO-STA) :

- DSD : version 2.0, stabilisée depuis mars 2004;

- DSDIFF : version 1.5, stabilisée depuis 2004 ;

- DSF : version 1.1, stabilisée depuis novembre 2005.

### Contenu

Le DSD utilise une technique de numérisation Sigma-Delta à très haute fréquence d'échantillonnage. Le DSD64 pour 64 fs (« fs » signifiant Frequency Sampling et 1 fs = échantillonnage CD-audio = 44100 Hz). L'échantillonnage du DSD64, quantifié sur un bit unique, est donc de 2 822 400 bits par seconde, ce qui offre une bande passante allant jusqu'à 80 kHz voire 100 kHz et une plage dynamique de 120 dB.

La fréquence d'échantillonnage du DSD peut varier. Le DSD64 est le plus ancien et est utilisé dans le SA-CD, puis est apparu le DSD128 ou double-rate DSD, le DSD256 ou quad-rate DSD, le DSD512 ou octuple-rate DSD et le DSD1024. Leurs noms correspondent respectivement à 64 fois, 128 fois, 256 fois, 512 et 1024 fois la fréquence utilisée pour le CD-audio, avec respectivement des fréquences d'échantillonnage de 2,8 MHz, 5,6 MHz, 11,2 MHz, 22,57 MHz et 45,158 MHz.

Les conteneurs DSDIFF et DSF sont conçus pour embarquer de 1 à 6 canaux (stéréo ou 5.1 le plus souvent).
<figure><img src="image_60.png" /></figure>

Le format de flux audio DSD est non compressé. Une variante compressée sans perte, décrite dans les mêmes spécifications que le DSD sous le nom DST (Direct Stream Transfer), permet de réduire de 50 à 70% la taille du flux.

## Organisme de maintenance et documentation de référence

La documentation de référence sur les formats utilisant DSD est maintenue par les entreprises Philips et Sony. La spécification IFF, développée initialement par Electronic Arts, est diffusée par différentes tierces personnes.

- Spécification du DSD dans un SA-CD : Super Audio CD System Description, part 2: Audio Specification ;

- Spécification du format conteneur générique IFF : "EA IFF 85" Standard for Interchange Format Files ;

- Spécification du DSDIFF : Direct Stream Digital Interchange File Format, DSDIFF Version 1.5 - PHILIPS ;

- Spécification du DSF : DSF File Format Specification, Sony, v. 1.01 ;

- Recommended usage of DSDIFF version 1.5 - PHILIPS.

## Identifiants

Extension : .dsf ou .dff selon la variante.

Type MIME : audio/x-dsf ou audio/x-dff selon la variante.

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q1227499 pour DSD</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000245 pour le format de fichier DSDIFF<br/>fdd000230 pour le format de flux audio DSD</td></tr><tr><td>PRONOM</td><td>fmt/1817 (DSF)<br/>fmt/1818 (DFF)</td></tr><tr><td>Just Solve the File Format Problem</td><td>DSD</td></tr></tbody></table>

## Caractéristiques techniques

Les fichiers DSDIFF sont d'une taille importante, même comparés à leur équivalent en WAVE non compressé « HD ». Le format est donc particulièrement adapté dans les cas où l'espace de stockage n'est pas contraint (CPO-COM) et où l'objectif est de conserver un signal de très haute qualité et très proche d'un éventuel original analogique.

Par ailleurs, il est à noter que le signal DSD est plus difficilement manipulable, en ce qui concerne des traitements audionumériques de postproduction. Ces opérations nécessitent le plus souvent une opération de conversion en PCM dans des formats conteneurs DXD ou WAVE.

Comme la plupart des formats destinés à être échangés, le flux audio DSD compressé (DST) comprend un mécanisme interne de contrôle d'intégrité sous la forme d'une empreinte CRC par frame (CPO-ROB).

Pour permettre l'interopérabilité entre les différents systèmes de fichiers qui peuvent imposer des limites de taille (par exemple les systèmes de fichiers FAT32 ou HFS limitent la taille unitaire de chaque fichier à un maximum de 4 Gio), le format conteneur DSDIFF prévoit un mécanisme de fichiers complémentaires repérables à leur extension qui comprend un numéro séquentiel : le premier aura pour extension .df1, le second .df2, etc. (CPO-AUT)

## Métadonnées internes

Le format conteneur DSDIFF prévoit deux éléments de métadonnées internes (Artist et Title). En outre, la spécification DFF prévoit que les quelques métadonnées internes, en particulier les marqueurs indiquant des points d'attention dans le flux audio (début et fin de plage, par exemple) puissent être échangés séparément du flux audio afin de faciliter la mise à jour. Ces fichiers DFF ne comportant pas de flux audio sont appelés Time Files et identifiés par leur extension .dft (CPO-AUT).

Le format conteneur DSF, en revanche, est conçu pour embarquer des métadonnées internes au format ID3v2.
<figure><img src="image_61.png" /></figure>

## Outils

L'outil d'analyse et d'extraction de métadonnées techniques pour la BnF est MediaInfo, qui dispose d'une sortie native dans le format de métadonnées de caractérisation préféré par la BnF, MPEG-7.

## Usage ou présence dans les collections de la BnF

En 2018, une opération exceptionnelle de numérisation de bandes « master » audio analogiques originales et de très grande qualité ont conduit à l'utilisation du format DSD256. Dans le même temps, une conversion en WAVE (PCM - 24 bits - 96 kHz) a été réalisée pour des besoins de consultation et de facilité de postproduction.

Par ailleurs sont présents dans les collections des supports SA-CD édités et entrés par dépôt légal. Pour le moment, seule la couche « CD » a été recopiée (PCM - 16 bits - 44,1 kHz) et sauvegardée au format WAVE.