Conserver un logiciel ne garantit pas qu’on pourra le réutiliser

L’archive n’est pas l’expérience

Un programme peut survivre sous forme de fichier et pourtant ne plus être utilisable. Cette distinction — formulée explicitement dans l’article de RetroPause consacré aux musées du logiciel — impose de séparer deux questions : un objet numérique a-t-il été conservé, et peut-on le réexécuter dans des conditions permettant de comprendre son fonctionnement ? Une réponse positive à la première ne prouve pas la seconde.

Cette différence compte, car un logiciel n’est pas seulement une image à l’écran. Son utilisation dépend d’une machine et d’un système capables d’interpréter les données et d’exécuter le programme. Or les éléments fournis ne désignent aucun produit, format, plateforme ou procédé précis. Ils ne permettent donc ni de proposer un guide technique ni d’affirmer qu’un programme donné peut être récupéré. Le point de départ est ici la frontière entre conserver une information et conserver une expérience opérationnelle.

Que signifie conserver ?

L’entrée consacrée à la préservation numérique décrit son objectif comme le maintien de l’intégrité, de l’authenticité, de la fiabilité, de la lisibilité et des fonctionnalités de l’information malgré les changements technologiques. Cette formulation est générale, mais utile pour réfléchir au logiciel : garder une copie répond à la continuité du contenu ; préserver la possibilité d’usage ajoute une exigence différente.

Il ne faut pas transformer cette distinction en opposition artificielle. Une copie conservée peut avoir de la valeur même si elle ne s’exécute pas. Elle peut documenter l’existence d’un programme ou faire partie d’un ensemble de documents. Inversement, réussir à ouvrir un fichier ne prouve pas à lui seul qu’il est intact, authentique ou représentatif de son état d’origine. Les sources disponibles ne proposent pas d’études techniques de cas permettant d’évaluer ces conditions pour un programme particulier.

L’importance de la documentation

Les archives institutionnelles donnent un cadre pour réfléchir au travail qui accompagne les objets conservés. Le Musée archéologique national présente ses archives historiques comme une ressource de recherche pour ses départements et pour les chercheurs extérieurs. Une synthèse sur les archives de musée énumère notamment l’évaluation, l’acquisition, le classement, la description, la conservation et la mise à disposition des documents. Ce ne sont pas des consignes spécifiques au logiciel, mais elles étayent une idée importante : conserver, c’est aussi laisser des informations qui permettent d’identifier, de comprendre et de consulter ce qui a été gardé.

Appliquée avec prudence aux anciens logiciels, cette idée conduit à documenter ce qui a été reçu, la façon dont l’objet est identifié et ce qui est — ou n’est pas — connu de son utilisation. Une étiquette « ancien programme » ne suffit pas. Une description utile distinguerait les faits vérifiables des hypothèses et préciserait si l’on conserve un fichier, un support matériel, une documentation associée ou un moyen vérifiable d’exécution. Les éléments rassemblés ici ne décrivent aucun protocole normalisé pour établir cette notice ; il serait donc imprudent de présenter une suite d’étapes comme obligatoire.

L’exécution comme question, pas comme promesse

La possibilité d’exécuter un programme peut sembler le moyen le plus direct d’approcher son fonctionnement, mais le mot « fonctionner » demande à être contextualisé. Le fichier s’ouvre-t-il ? Le programme se comporte-t-il comme prévu ? Une condition d’utilisation documentée a-t-elle été préservée ? Sans informations sur un produit et son environnement, ces questions ne peuvent être résolues dans l’abstrait.

Une exposition ou un article peut donc expliquer cette différence sans mettre en scène une démonstration. Il est légitime d’évoquer les problèmes d’accès et de contexte posés par le logiciel ; il ne l’est pas d’inventer une expérience utilisateur, un souvenir collectif ou une compatibilité précise. Le titre de l’article de RetroPause sur les musées du logiciel résume la nuance : conserver n’équivaut pas à pouvoir exécuter. L’extrait fourni ajoute que le logiciel ne se conserve pas comme une console, un magazine ou une cartouche, et que le copier ne revient pas à préserver son support d’origine. Les informations disponibles ne permettent pas de prolonger cette comparaison par des exemples de formats ou de technologies.

Ce que les archives peuvent prouver — ou non

Les ressources sur les archives de musée et les archives institutionnelles étayent l’intérêt du classement des documents et de leur mise à disposition. Elles ne prouvent pas, à elles seules, qu’une institution donnée conserve des logiciels anciens, ni ne décrivent des pratiques d’émulation, de migration ou d’accès. De même, une définition générale de la préservation numérique ne prouve pas qu’un programme particulier reste lisible ou authentique.

Cette prudence n’affaiblit pas l’histoire du logiciel ; elle la rend plus fiable. Une recherche peut identifier son objet et distinguer les preuves matérielles des affirmations portant sur son fonctionnement. Si les sources attestent seulement la conservation d’un fichier, la conclusion doit s’arrêter là. Si elles décrivent une exécution, il faut attribuer et contextualiser cette affirmation. Les éléments disponibles ne suffisent pas à reconstituer l’histoire d’un produit précis ni à recommander des procédures techniques.

Conserver, c’est aussi reconnaître les limites

Les anciens logiciels mettent en évidence une question parfois dissimulée derrière le mot « archive » : que voulons-nous garder accessible pour l’avenir ? Les documents, les données et la possibilité d’exécuter un programme ne sont pas équivalents, même s’ils peuvent être liés. Le travail archivistique décrit par les sources aide à comprendre l’importance d’identifier, de décrire et de rendre les documents accessibles ; la définition de la préservation numérique rappelle que l’objectif dépasse le stockage.

La conclusion la plus solide est aussi la plus mesurée : garder un programme est un commencement, pas une garantie qu’il fonctionnera de nouveau. Pour aller plus loin, il faut des preuves précises sur l’objet, sa documentation et ses conditions d’utilisation. Tant qu’elles manquent, reconnaître cette incertitude fait partie d’une conservation rigoureuse.