1. Pourquoi une base de données minimale

Il était important, trente ans après les prises de position de J.-C. Gardin, de ne pas se contenter de mettre à nouveau en évidence les mêmes problèmes qui se posent encore dans l’usage de l’informatique en archéologie. Il fallait essayer d’aller au delà en proposant une solution. La première étape vise à la mise en place d’un protocole de création de bases de données permettant aux futurs aventuriers de l’archivage d’avoir une base de réflexion et une ligne de conduite leur assurant un chemin de création moins chaotique que leurs aînés. La deuxième étape est une réflexion sur un tronc commun qui pourrait être dégagé de l'étude des bases que j’ai effectuées. Ce tronc commun regrouperait en fait les données et systèmes d’archivage minimaux nécessaires à la gestion des données issues d’une fouille archéologique en vu de leurs sauvegardes et de leur étude. Il serait le “prolongement” de PATRIARCHE, l'échelon suivant qui intégrerait toutes les données issues de la fouille. Mais il ne s'agit pas, bien sûr, de faire une base nationale unique comme PATRIARCHE mais d'avoir des éléments communs de travail. Il est toutefois important de prendre en compte les référents nationaux existants, fonctionnants et utilisés.

Ce tronc commun, auquel chaque nouvelle base créée pourrait se référer, permettrait de régler les problèmes mis en évidence dans la première partie de ce travail, à savoir : homogénéité, lisibilité, exploitation et pérennité. Les bases seraient donc semblables, puisqu’elles utiliseraient les mêmes éléments de fondation, mais aussi indépendantes puisqu’elles pourraient évoluer à partir de ce tronc commun en fonction des besoins de chaque fouille. Les éléments clefs non modifiables de ces bases seraient avant tout le système de code d'inventaires ainsi que les fichiers, les rubriques et les listes de termes de vocabulaires définis comme fondamentaux et minimaux pour la description des données.

J’ai décidé de traiter ce tronc commun comme la base de données de départ indispensable lorsque l’on commence l’archivage des données sur une fouille. Elle contient les fichiers, rubriques et liens minimaux à la bonne gestion des données. Au fur et à mesure que des besoins spécifiques apparaîtront, ceux-ci seront traités, soit par l’intermédiaire de nouvelles rubriques au sein d’un fichier existant, soit par l’ajout d’un ou de plusieurs nouveaux fichiers à la structure de la base de départ. L’archivage de ces nouvelles données devra se référer au système de code d'inventaires mis en place. Je pourrais définir cette base comme une base minimale : les données qu’elle gère font partie des données primaires issues de la fouille et les données pouvant y être associées par la suite font partie le plus souvent des données traitées.

Je vais traiter cette base minimale suivant le protocole de création que j’ai mis en place. Je m’arrêterais simplement dans ce processus à la présentation de la structure de la base. En effet ce n’est pas au niveau de la mise sur informatique, du choix du logiciel, de la présentation des écrans, du choix des couleurs, … que se fait l’homogénéité des bases de données mais dans l’usage d’un même code d'inventaires et de rubriques de description minimales et de listes de termes utilisées, comme nous avons pu le constater dans l’essai “douloureux” d’un passage de bdB dans la structure d’ArchéoDATA (voir, partie A, chapitre 4.6 -Exemple : étude de compatibilité des codes d'inventaires et des champs de saisie entre bdB et ArchéoDATA en vue d’une mise en commun des données, p. 42).

Je commencerai par définir les objectifs de cette base. Ensuite je mettrai en avant les données indispensables qui devront être gérées par la base ainsi que le système de code d'inventaires à leur appliquer selon leurs statuts. La phase suivante sera plus technique puisqu’elle présentera les fichiers issus de cette réflexion ainsi que les rubriques, les référentiels et la structure qui en découlent.