Vers la migration des formats de fichiers
Si les objets numériques doivent être conservés à long terme, maintenus utilisables et, si nécessaire, convertis dans d’autres formats, ils doivent être transférés dans un format d’archivage standardisé. Un nombre raisonnable de formats de fichiers dans les archives numériques permet de les surveiller activement et de prendre des mesures de conservation si nécessaire.
L’aperçu suivant montre quels formats nous recommandons pour l’archivage et où une migration automatique est possible lors de l’ingest. Il convient de noter qu’il s’agit de recommandations et non de prescriptions d’une validité absolue. La décision de procéder à une conversion et le choix du format cible approprié dépendent toujours des caractéristiques d’un fichier et de son utilisation future : Les fichiers doivent-ils conserver leur fonctionnalité et pouvoir être modifiés ultérieurement, ou l’aspect visuel actuel doit-il être « figé » ? La question de savoir si les originaux doivent être conservés avec les fichiers migrés influe également sur la procédure choisie.
Les recommandations reflètent nos considérations actuelles et sont révisées à intervalles réguliers. De manière générale, nous renvoyons à la fiche d’information sur les formats de fichiers adaptés à l’archivage des Archives fédérales suisses et au catalogue des formats de fichiers archivés du CECO. Pour les médias audiovisuels, les recommandations de Memoriav sont également utiles.
Type de données | Format d’archivage recommandé | Provisoirement accepté | Migration lors de l’ingest ? | Commentaires |
---|---|---|---|---|
Traitement de texte (Office-Formate, RTF) | PDF/A-2 (de préférence), PDF/A-1 |
DOCX, ODT, PPTX, ODP | oui, vers PDF/A | Les contenus particuliers tels que les macros ou les animations sont perdus lors de la migration. |
Texte (non structuré) | TXT (Plain Text) | Non | Pas de migration nécessaire | |
Tableaux (texte structuré) | CSV | Non | Pas de migration nécessaire | |
Tableur | PDF/A-2 (de préférence), PDF/A-1 |
XLSX, ODS | Oui, vers PDF/A |
Une conversion en PDF/A n’est recommandée que si l’aspect de la mise en page est au premier plan. Les fonctions et les formules sont perdues lors de la migration. |
PDF/A-2 (de préférence), PDF/A-1 |
Oui, vers PDF/A | Les signatures numériques sont perdues lors de la migration. | ||
Images matricielles | TIFF, JPEG2000 | JPEG | Possible, mais pas obligatoire |
En raison de la forte diffusion du format JPEG, une conversion n’est actuellement pas nécessaire. Pour les fichiers RAW, il est recommandé de les convertir en DNG avant l’acquisition. |
Graphiques vectoriels | SVG | EPS | Non | La conversion d’EPS en PDF/A est possible lors de l’acquisition. |
Audio | WAVE | MP3, AIFF, FLAC, ALAC | Possible, mais pas obligatoire |
Une migration n’est pour l’instant pas nécessaire pour les fichiers MP3, AIFF, FLAC ou ALAC existants. Les métadonnées sont perdues lors de la conversion en WAVE. |
Video | FFV1 (.mkv) | MPEG-4 | Possible, mais pas obligatoire | Pour les formats gourmands en mémoire tels que AVI ou MOV, une migration vers FFV1/MKV peut s’avérer judicieuse. Pour les numérisations à partir de DVD, une conversion en MPEG-4 suffit. Dans tous les cas, une migration devrait être effectuée avant l’ingest. |
Extensible Markup Language (XML) | XML | HTML | Possible, mais pas obligatoire | La conversion de HTML en PDF/A lors de l’ingestion est possible, mais les contenus interactifs ou multimédias sont perdus. |
EML oder PDF/A | MSG | Oui, vers PDF/A | Le traitement des pièces jointes dépend de leurs formats et doit être examiné dans le cas d’application concret. | |
Sites web | WARC | Non |
WARC est un format conteneur qui regroupe les ressources numériques d’un site web, mais ne fait pas de conversion de format. Pour certaines pages, une conversion en PDF/A peut également être utile (voir HTML). Pour la conservation des pages web interactives, il est recommandé de créer des captures d’écran. |
|
Bases de données (relationnelles) | SIARD | Non | Une éventuelle migration devrait avoir lieu avant l’ingest. | |
Geodaten (GIS) | INTERLIS 1 (données vectorielles), TIFF avec EWF (données raster) |
GeoPackage | Non |
Une éventuelle migration devrait avoir lieu avant l’ingest. Les cartes et les plans peuvent être exportés en PDF à partir de programmes SIG et convertis en PDF/A lors de l’ingestion. |
CAD/CAM | DWG, IFC | Non |
Une éventuelle migration devrait être effectuée avant l’ingest. Les cartes ou les plans peuvent être exportés en PDF à partir de programmes de CAO et convertis en PDF/A lors de l’ingest. |
Formats de fichiers inappropriés
Nous renonçons à énumérer ici les formats qui ne se prêtent pas à un archivage électronique à long terme, car cette liste ne pourrait jamais être exhaustive. Quelques indications découlent implicitement de la liste ci-dessus : les formats binaires Microsoft Office antérieurs à Office 2007 (.doc, .ppt, .xls) ne doivent pas être considérés comme dignes pour l’archivage électronique à long terme. En revanche, les formats Office plus récents, basés sur XML, peuvent être acceptés car lisibles sans les applications Office.
Les formats propriétaires, qui ne peuvent être utilisés qu’avec des logiciels spéciaux, qui ont une faible diffusion et qui ne sont pas spécifiés de manière ouverte, sont en principe inappropriés. Les données issues d’applications spécialisées devraient, si le logiciel le permet, être exportées dans un format adapté à l’archivage électronique à long terme ou pouvant être migré lors de l’ingest, comme le PDF. Toutefois, la conversion dans un format d’archivage s’accompagne souvent d’une perte de fonctionnalité.
Les fichiers Zip sont également inadaptés à l’archivage, car lors de l’ingest avec docuteam feeder, il n’est pas possible d’analyser et de migrer les formats de fichiers qu’ils contiennent. Le format zip n’est autorisé que pour les SIP entiers qui sont décompressés lors de l’ingest.
Configuration standard pour les migrations de formats dans docuteam feeder
La configuration pour les migrations de format, qui s’effectuent automatiquement lors de l’ingest avec docuteam feeder, est définie dans le fichier migration-config.xml. Les règles de migration se basent sur différents critères d’identification des formats, qui sont traités dans un ordre précis :
- Migration de format sur la base de PRONOM-PUID (1ère priorité)
- Migration de format sur la base du type MIME (2e priorité)
- Migration de format sur la base de l’extension de fichier (3ème priorité).
Vous trouverez des informations détaillées sur la configuration des règles de migration dans notre documentation.
Une représentation sous forme de tableau de la configuration standard actuelle pour les migrations de format sur la base du PRONOM-PUID, du MIMEType et de l’extension de fichier suivra ultérieurement.