Au terme de cette étude, il est important de revenir sur le constat fait par J.-C. Gardin dans la scéance d’ouverture du colloque national du CNRS de 1972 sur les “banques de données archéologiques” (Gardin, 1974-1, p. 15 à 26) et qui m’a servi de point de départ. J.-C. Gardin a soulevé lors de ce colloque les problèmes rencontrés par les archéologues pour créer une base de données. Ces problèmes sont de plusieurs ordres. Ce sont d’abord des problèmes théoriques qui portent sur les données à intégrer dans la base de données, les descriptions de celles-ci et le langage qu’il faut utiliser pour les décrire. J.-C. Gardin souligne que sans un langage approprié et une gestion cohérente de la description, les informations saisies dans la base ne peuvent être exploitées. Le deuxième groupe de problèmes évoqués concerne les questions techniques en particulier celles qui touchent à la base de données. J.-C. Gardin a rappelé la nécessité de construire des bases de données librement conçues mais fondées sur une homogénéité commune à chaque base permettant des liaisons de l’une à l’autre et une exploitation conjointe. Ensuite J.-C. Gardin a évoqué les problèmes institutionnels pour rappeler la nécessité de d'assurer la pérennité de toutes ces données informatisées. J.-C. Gardin synthétisait alors les enjeux des bases de données résultant de la résolution de ces problèmes en deux points : offrir aux chercheurs la possibilité d’une recherche croisée de données possible dans plusieurs bases en même temps et assurer la pérennité de ces données par un suivi et un développement dans le temps. L’important n’est pas de faire des bases de données parce que c’est la mode et qu’il faut utiliser cet outil informatique pour donner un semblant d’esprit scientifique à sa recherche, mais parce qu’il est indispensable de permettre un croisement des données pour une exploitation plus large et plus riche et pour préserver au mieux ces données pour les recherches futures.
Dans sa présentation de 1972, J.-C. Gardin ne proposait pas de solutions pour résoudre les problèmes qu’il avait mis en évidence et d’ailleurs ce colloque lui-même n’y répondait pas plus, comme J.-C. Gardin le constatait dans la séance de clôture. “Dans un autre ordre d’idées, enfin, M. Gardin fait observer que les problèmes institutionnels [entre autres] évoqués dans la séance d’ouverture (voir p. 20) n’ont pas fait l’objet des discussions qu’il escomptait.” (colloque de 1972, p. 316). Il me paraissait donc nécessaire et très tentant, mais sans doute très ambitieux aussi, d’engager une recherche visant à trouver des solutions à ces problèmes, puisque l’on constate aujourd’hui que ceux-ci ne sont toujours pas résolus. L’objectif reste encore et inlassablement le même : pouvoir enfin répondre aux enjeux définis il y a déjà trente ans. C’est le sujet de ce travail sur la nature, le statut et les traitements informatisés des données en archéologie.
Pour cela, j’ai commencé par revenir sur des points de définition afin de fixer une terminologie aussi claire que possible. Ces points portent sur la définition de ce qu’est une donnée, sa position dans l’histoire de l’archéologie, son statut d’élément du présent, les différents types de données archéologiques, leur description, … J’ai suivi la même démarche en ce qui concerne les bases de données. Je me suis ensuite intéressée au fondement d’une base de données c’est-à-dire au fait que certains éléments doivent être homogènes pour pouvoir référencer, décrire et ensuite exploiter ces données. De plus ces éléments devraient être homogènes entre toutes les bases de données pour qu’on puisse assurer une recherche croisée et une pérennité des données par la possibilité de transfert d’une base à une autre. Ces éléments sont l’unité documentaire, les codes d'inventaires, les descriptions et le langage. Je reviendrai sur ces éléments un peu plus loin.
Une fois que toutes les terminologies ont été mises en place, je me devais d’effectuer un état des lieux des bases de données existantes. J.-C. Gardin préconisait une période d’essais de développement de bases de données diversement conçues avant de se lancer dans une standardisation plus ou moins poussée. Estimant que nous sommes toujours dans cette phase d’essais, j’ai donc considéré les bases retenues pour l’étude comme des “projets pilotes” et j’en ai tiré des informations essentielles pour constituer et étayer une solution répondant aux problèmes posés. Ces problèmes, pour les rappeler, sont avant tout un cloisonnement entre les bases qui restreint à presque rien la possibilité d'échange entre celles-ci. Cette situation a une conséquence majeure : la réflexion actuelle sur l’informatisation des données archéologiques va à l’encontre des enjeux des bases de données : assurer recherches croisées et pérennité.
Ces problèmes peuvent être en partie réglés de deux manières différentes. La première peut consister à créer une base de données nationale unique qui permettrait de faire la saisie sur tous les sites, dans toutes les périodes et sur tous types de fouille. Pour se donner une idée des obstacles à surmonter pour construire une base de ce type, il suffit de revenir sur les problèmes rencontrés par l’application PATRIARCHE (voir sous-section 5.2 – l’inventaire archéologique de la France et l’application PATRIARCHE, chapitre II, Partie A, p. 55). Cette application n’est pas une base de données d’archivage des données de fouille, il s’agit de la version informatique de l’inventaire archéologique de la France, mais c’est une base de données unique permettant de traiter 1) des entités archéologiques diverses caractérisées par un ensemble cohérent de vestiges présentant une unité chronologique et/ou fonctionnelle sur un espace donné ou caractérisées par un lieu contenant des vestiges indéterminés ou par un lieu contenant peut-être des vestiges ou par un lieu dont on sait qu’il est susceptible de contenir des vestiges archéologiques ou enfin par un objet ou un ensemble d’objets déplacés, 2) des opérations de nature tout aussi différente, elles aussi (fouilles, études, prospections, relevés, …), 3) des prospections, des sources et des répertoires. Tous ces éléments nombreux, divers et variés, reliés entre eux par des liens multiples, aboutissent à réaliser une expérience de base de données à caractère d’exception, parce qu’elle est à la limite du réalisable et surtout, ce qui est encore plus grave, parce qu’elle risque d’être en fin de compte inexploitable, tout simplement dans la mesure où dans chaque ensemble les données sont trop diversifiées. D’ailleurs J.-C. Gardin éliminait déjà cette solution de base de données unique en 1972. “Le projet d’un découpage à la fois univoque et universellement tenu pour le plus fécond est une utopie. Une constatation simple suffit à le montrer : le même objet pourra être enregistré tout d’abord dans une banque de données dont le champ est la fouille elle-même, avec ses dizaines ou centaines de milliers de “données” […], puis dans une autre regroupant l’ensemble des documents du même genre, dans certaines limites géographiques et chronologiques […], puis dans une troisième, correspondant à un inventaire régional […], etc”. (Gardin, 1974-1, p. 21-22)
La seconde manière de régler ces problèmes, est celle que j’ai tenté de construire et que je viens de développer dans le présent travail. Il s’agit d’homogénéiser certains éléments clefs de l’archivage de données pour pouvoir mettre en place une norme suivie par tous et qui permet d’édifier des liens et des passerelles entre les différentes bases développées. Ces éléments clefs (développés dans la partie A, chapitre II, sous-section 4 - le problème de l’homogénéité, p. 38) sont au nombre de quatre. Le premier est l’unité documentaire, l’unité stratigraphique ou plutôt l’unité de fouille comme j’ai choisi de l’appeler, unité de lieu et de moment. Le second concerne les codes d’inventaires qui permettent de retrouver chaque donnée et de l’identifier. S’il n’y a pas d’homogénéité des codes d'inventaires, il ne peut y avoir de dialogue entre bases, ni de sauvegarde les unes vers les autres. Dans la solution que je propose les codes d’inventaires s’organisent de la manière suivante :
[numéro de l’entité archéologique 94 /numéro du chantier/numéro d’ordre]
et
[numéro de l’entité archéologique/numéro du chantier/numéro d’UF/numéro d’ordre].
La description homogène d’un type de donnée est le troisième élément clef. En effet pour pouvoir exploiter une base, il faut que toutes les données d’un même type (couches, objet céramique, objet métal, photographies, …), soient décrites de la même manière et suivant toujours le même protocole au travers de champs de saisie identiques. C’est grâce à ces champs que l’on pourra faire des recherches concluantes dans plusieurs bases, champs auxquels on aura associé le quatrième élément, le langage. Il est en effet capital, pour s’y retrouver, de décrire des données identiques avec les mêmes mots ou termes. Il faut pour cela mettre en place des listes de termes de vocabulaire par types de données, par disciplines, par catégories d’objets, par époques fouillées, …
Cette homogénéisation est couplée à un tronc commun, traité comme la base de données nécessaire lorsque l’on commence l’archivage des données sur une fouille. Ce tronc commun contient les fichiers, rubriques et liens minimaux à la bonne gestion des données. Il répond aux objectifs mis en avant par l’étude des bases de données existantes à savoir :
D’autres données traitées pourront par la suite être associées à ce tronc commun en fonction des besoins divers de chacun.
Cette association éléments homogènes/tronc commun permet de répondre aux enjeux posés par les bases de données en archéologie. Les éléments clefs homogènes fournissent une identification, un protocole de description et un langage de description normalisés qui permettent des recherches croisées entre bases sans bruits ni silences et des études comparées d’objets provenant de fouilles diverses. Le tronc commun, quant à lui, instaure un protocole de sauvegarde des données puisqu’il sera toujours possible lorsqu’une base ne sera plus exploitée de transférer ses données vers une base encore en fonctionnement, et ceci grâce à une même structuration des codes d’inventaires, une même unité documentaire, des rubriques identiques et des listes de termes de vocabulaire définis pour chacune. Pour obtenir une pérennité complète des données, il faut adjoindre à cette association éléments homogènes/tronc commun un traitement des données numérisées, images et textes (comme des rapports par exemple) par un langage universel, comme le langage XML (voir note 82, p. 210) et la mise en place d’un protocole raisonné de recopie des supports de stockage (CD Rom, …) lié à des contrôles de qualité des informations recopiées (voir partie C, chapitre III, sous-section 3.4 – L’archivage physique des données et la pérennité des données numériques, p. 210).
On pourrait assimiler cette solution à ce qui existe actuellement avec les bases de données bibliographiques : même si les inventaires sont différents, on peut rechercher, via le Web, un ouvrage, à partir de la bibliothèque de Karlsruhe en Allemagne par exemple, dans toutes les bibliothèques universitaires allemandes ainsi que dans les principales bibliothèques françaises, anglaises et américaines en une seule requête. Cette performance peut être réalisée grâce à la mise en place pour les sources documentaires (livres, articles, rapports, …) d’un ISBD (International Standard Book Description) qui est commun, unique et donc échangeable. Cet ISBD est un regroupement de plusieurs champs de saisie dont les noms d’auteur, le titre, … Cet ISBD suit les prescriptions des protocoles Z 44050 et Z 44063 95 de la norme Unimarc, qui comprennent plus de 200 pages !! Mais au-delà de la lourdeur qu’impose cette administration de références, cet échange entre bases de données bibliographiques européennes a le mérite d’avoir été mis en place et de fonctionner.
Cette solution consistant à mettre en œuvre des bases structurellement identiques mais matériellement différentes, permettrait d’avoir une visibilité commune des données et de pouvoir mener une recherche croisée, élément premier des enjeux des bases de données. Cette consultation est maintenant à envisager via le Web. Il est très simple d’imaginer le bénéfice que cela peut apporter à un chercheur. Celui-ci disposera d’un outil lui permettant de faire une première recherche à distance sur différentes bases pour savoir si les objets qui l’intéressent ont été trouvés dans tel ou tel site, sans avoir à se déplacer. Après une sélection à distance, le chercheur pourra se déplacer pour les observer. De plus, comme au Centre archéologique européen du Mont Beuvray par exemple, cela permettrait aux chercheurs qui ne “résident” pas dans le centre ou le laboratoire où se trouve centralisée la base, de pouvoir la consulter à distance sans avoir à en demander une copie à chaque fin de mission. Cela pourrait aussi permettre la saisie de données complémentaires comme une étude chronologique, … Néanmoins, cette possibilité de mise en ligne des bases soulève trois difficultés. La première concerne le choix puis le suivi d’un serveur d’accueil, sur lequel les chercheurs pourront se connecter et effectuer directement des recherches sur plusieurs bases en même temps. La seconde est de définir les utilisateurs et leurs besoins pour pouvoir mettre en place des systèmes de gestion par mots de passe. La troisième concerne le respect de la confidentialité des données surtout dans le cas des fouilles non publiées. On ne peut se dispenser d’utiliser des contrôles d’accès puisque l’on se trouve confronté aux problèmes juridiques de droit de propriété intellectuelle et de protection du travail en cours. Par exemple, ces mots de passe seraient fournis sur demande et donneraient accès à une catégorie restreinte d’informations en fonction du sujet de la recherche, pour éviter le piratage de données.
Cependant ces enjeux, tels que définis plus haut, peuvent être atteints uniquement si les données saisies dans des bases de données répondent aux critères de l’association éléments homogènes/tronc commun. Pour permettre une exploitation, les bases ne correspondant pas à ces normes devront être reprises. Ceci concerne toutes les bases existantes. Pour cela, il va donc falloir récupérer ces données pour qu’elles rentrent dans les normes mises en place. Cela va demander un énorme travail puisqu’il va falloir traiter chaque donnée, changer des codes, … et donc mettre en place des tables de conversions avec tous les problèmes que cela peut poser (pour ces problèmes posés par les tables de conversion, voir Partie I, chapitre II, sous-section 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 et surtout la sous-section 4.6.4 – Synthèse, p. 51). Cette manière de faire n’est pas satisfaisante mais c’est pour l’instant la seule possibilité que nous avons pour convertir ces données afin de les rendre visibles facilement et afin de les rendre pérennes. En effet une fois que l’archivage de ces données répondra aux normes instaurées, ces données pourront être importées dans n’importe quelle base construite à partir du tronc commun.
D’ailleurs, pourquoi ne pas songer, comme c’est le cas pour les bibliothèques avec la norme Unimarc, à une norme européenne qui permettrait d’interroger des bases de données de tous les pays européens. Dans l’absolu, une réflexion sur l’archivage des données en archéologie devrait être menée conjointement avec d’autres pays puisque les limites géographiques des pays aujourd’hui ne sont plus les mêmes “qu’avant” et que des objets identiques de l’époque celtique, par exemple, peuvent aussi bien être trouvés sur l’oppidum du Mont Beuvray que sur l’oppidum de Stradonitz en République Tchèque (Déchelette 1927). C’est d’ailleurs ce qu’avait essayé de faire le comité international pour la documentation (CIDOC) dans son projet de norme documentaire pour les sites archéologiques (voir partie A, sous-section 5.1 - Projet de norme documentaire internationale pour les sites archéologiques du Comité International pour la Documentation (CIDOC), p. 52). Ce projet de norme avait pour but de “faciliter la communication entre les organismes nationaux et internationaux responsables de l’inventaire et de la protection du patrimoine archéologique et d’aider les pays qui commencent à développer un système d’enregistrement pour l’inventaire et la protection du patrimoine archéologique”. Mais si l’on consulte le site internet de l’ICOM (conseil international des musées, http://cidoc.natmus.dk) on se rend compte que cette norme n’est plus disponible en ligne. On peut donc considérer que le projet est arrêté. Maintenant le CIDOC se concentre sur l’établissement de normes documentaires relatives à l’inventaire des objets archéologiques dans les musées. Cette entreprise est sans doute plus aisée à réaliser que celle qui portait sur l’inventaire des sites archéologiques pour des raisons bien compréhensibles : homogénéité des collections ou parties de collections, personnel spécialisé dans la maîtrise des traitements documentaires, absence de contraintes de temps, …
La deuxième orientation de l’évolution à donner aux bases de données concerne les outils de visualisation des recherches pour aider à l’interprétation des données. Une fois que l’archivage à l’intérieur du tronc commun est réalisé correctement, l’archéologue peut enfin exploiter les données indépendamment de leur origine : recherche, regroupement, association, recoupement, comparaison, réalisation de typologies, … Ces résultats devraient pouvoir être traités sous différentes formes et non pas seulement sous la forme d’une liste de données comme c’est encore le cas le plus souvent dans les bases de données actuelles. Des graphiques, des courbes, des cartes de répartition, ou des traitements par l’intermédiaire d’un SIG, système d’information géographique (voir partie B, Chapitre IV, sous-section 12.4 – La présentation des résultats, p. 168) sont autant d’outils de présentation qui devraient être à disposition de l’archéologue. À lui ensuite de choisir le plus pertinent.
Mais pour y parvenir, il faut encore explorer ces outils et donc laisser chacun faire ses propres découvertes et en faire émerger les points les plus importants, comme d’ailleurs J.-C. Gardin le préconisait en 1972 pour les bases de données : “L’argument principal en faveur de cette thèse [le développement de bases de données diversement conçues] est en effet que nous n’en sommes en ce qui concerne les bases de données archéologiques qu’au stade des “projets-pilotes” et des essais d’application, et qu’il serait par conséquent dangereux de vouloir s’arrêter dès maintenant à un système d’exploitation unique, quel qu’il soit, au nom des bienfaits attendus de la standardisation”. (Gardin, 1974-1, p. 23). Cependant j’espère qu’il ne faudra pas attendre trente ans pour réfléchir ensemble aux résultats obtenus. C’est à cette condition, la mise en oeuvre d’outils de présentation et donc d’aide à l’interprétation, que les bases de données pourront aspirer à la qualification tant convoitée aujourd’hui de Système d’Information Archéologique, SIA.
selon PATRIARCHE c'est-à-dire numéro de l'entité archéologique = numéro de département/numéro de la commune principale/code EA (numéro d’ordre dans la région, géré par le système)
Formation des bibliothècaires et documentalistes : normes pour l'épreuve de cataloguage, Paris, AFNOR, 1999