Conserver un programme ne suffit pas à le rendre utilisable

Une archive ne promet pas l’exécution

Le mot « conserver » peut laisser penser qu’un ancien programme restera disponible à l’usage. Pourtant, sauvegarder quelque chose et le faire fonctionner ne sont pas la même opération. L’article de RetroPause sur les musées du logiciel ancien pose explicitement cette différence : WinWorld et Virtual OS Museum montrent comment le logiciel peut être présenté comme un patrimoine consultable, sans que cela suffise à réunir toutes les conditions nécessaires à son exécution. La distinction compte, car une archive peut être accessible pour l’étude sans offrir une expérience fonctionnelle sur n’importe quel ordinateur.

Il n’est pas nécessaire d’exagérer ce que prouvent ces exemples. Les informations disponibles les désignent comme des initiatives qui rendent visible une transformation culturelle : le logiciel peut être consulté comme patrimoine. En revanche, elles ne fournissent ni inventaire des formats, ni description des méthodes techniques, ni évaluation comparative de la compatibilité. L’idée utile est plus limitée : l’accès documentaire et l’exécution sont des résultats différents.

Le code source comme élément de mémoire

Software Heritage décrit son travail comme la collecte et la préservation du code source, et présente le logiciel comme une partie du savoir technique et scientifique de l’humanité. Cette approche permet de penser la conservation au-delà de l’écran : préserver du code rend une source disponible pour être examinée comme artefact technique. Cela ne signifie pas automatiquement que chaque programme est conservé dans un état exécutable ou que toutes ses conditions d’utilisation d’origine sont reconstituées.

La différence entre le code et un programme en fonctionnement n’est pas une objection aux archives de code. Elle permet de préciser ce que conserve chaque initiative et quelles questions restent ouvertes pour les chercheurs. Un dépôt peut être une pièce importante de l’histoire du logiciel, tandis que d’autres questions — sa distribution, la documentation qui l’accompagnait ou l’environnement dont il avait besoin — demandent des preuves supplémentaires. La source de Software Heritage étaye son objectif déclaré de préserver le code ; elle ne suffit pas, à elle seule, à répondre à toutes ces questions pour chaque œuvre.

Une histoire aussi faite de distribution

La page consacrée au logiciel du Museo de Informática 2.0 de l’Universitat Politècnica de València apporte une remarque historique précise : dans les années 1970, les entreprises informatiques développaient à la fois le matériel et les applications, et les distribuaient ensemble. Cette observation est circonscrite, mais elle invite à ne pas isoler le programme des objets et pratiques qui l’entouraient.

Si une application arrivait avec une machine, conserver uniquement le fichier ne décrit pas nécessairement toute l’expérience. Le support, le système requis et la documentation peuvent faire partie des questions à poser dans une recherche. Cela ne permet pas d’affirmer que tous les produits de cette décennie étaient distribués de la même manière : la page citée donne une caractérisation générale, pas un catalogue exhaustif. Elle montre néanmoins pourquoi l’histoire du logiciel peut concerner aussi bien des objets physiques que des informations numériques.

De la pièce conservée à l’expérience possible

La description de la vidéo du Museo de la Informática Histórica de l’Université de Saragosse offre un autre point de départ : elle évoque un musée d’informatique classique dont l’origine se trouve à l’université et dont le développement a été progressif. Les informations fournies ne permettent pas de reconstituer sa collection ni de décrire ses méthodes de conservation. L’exemple rappelle malgré tout que le patrimoine informatique peut aussi être organisé dans des lieux où objets et contexte sont présentés ensemble.

Il est utile de distinguer trois questions : quelles preuves sont conservées, quel contexte aide à les interpréter et que peut-on effectivement exécuter ? Une institution peut fournir du contexte ; une archive de code peut préserver des matériaux techniques ; une collection de logiciels consultables peut faciliter l’accès à certains programmes. Ces fonctions peuvent se compléter, mais il ne faut pas les tenir pour interchangeables sans éléments précis.

Ce que l’on peut affirmer et ce qui reste ouvert

Les éléments disponibles étayent une conclusion prudente. Il existe des initiatives consacrées à la préservation du code source, des musées qui présentent le logiciel comme patrimoine et une référence institutionnelle décrivant la distribution conjointe du matériel et des applications dans les années 1970. Ils permettent aussi d’affirmer que conservation et exécution ne sont pas synonymes. Ils ne permettent pas d’établir des taux de réussite, de comparer des méthodes d’émulation ou de dire quels programmes précis peuvent fonctionner aujourd’hui.

Cette prudence ne diminue pas l’intérêt du logiciel ancien. Elle aide plutôt à mieux définir ce que signifie le conserver. Un programme peut avoir une valeur documentaire même s’il ne fonctionne pas ; une expérience fonctionnelle peut donner un autre type d’accès, mais ne remplace pas la préservation de son contexte et de ses matériaux. Une conservation utile commence par nommer précisément ce qui a été sauvegardé et ce qui manque encore pour le faire fonctionner à nouveau.