5.2.2. Histoire de l’inventaire archéologique

C’est dans la deuxième moitié du XIXe siècle que le premier inventaire des ressources archéologiques sur le territoire de la France est mis en œuvre. Ils [ces inventaires] se présentaient sous la forme de catalogues raisonnés, concernant soit un secteur géographique particulier, soit un type de structure ou d’objet (Dorion 1981). La notion de “carte archéologique” fait son apparition assez tôt puisque dans le décret numéro 45-2098 du 13 septembre 1945, les directions des Antiquités avaient pour mission la mise à jour de la “carte des gisements et des fouilles”. Celle-ci est associée à la première codification permettant l’inventaire de tous les sites archéologiques. Mais la gestion sous forme de fiches papier d’un tel nombre d’informations devient vite vaine et c’est pour cela que lors de l’informatisation du ministère en charge de l’archéologie en 1975, le bureau des Fouilles et Antiquités fait la demande du matériel et du personnel nécessaires à la mise au point d’un instrument pour ficher les sites archéologiques. SIGAL 1, la première base de données d’inventaire des sites archéologiques, voit le jour en 1978.

SIGAL était un fichier de sites, l’unité documentaire, dans lequel on trouve directement des données liées au site. Le site est ici une aire géographique sur laquelle se trouve ou est supposée se trouvent ou sont supposés se trouver des vestiges archéologiques. Ces vestiges n’ont pas forcément de lien entre eux (périodes d’occupation différentes, …). Le principe voulait que les services régionaux des antiquités remplissent des fiches papier d’identification des sites. Ces fiches étaient ensuite envoyées au service central où elles étaient saisies sur informatique et stockées dans une machine. Malheureusement aucune information ne revenait dans les services régionaux sous quelque forme que ce soit. La base ne pouvait être interrogée qu’au service central. Grâce à l’arrivée des micro-ordinateurs dans les années quatre-vingt, les services régionaux vont être dotés de terminaux qui vont leur permettre d’interroger la base directement. À cet effet, SIGAL 2 est mise au point en 1988. Néanmoins cette nouvelle version du logiciel ne répond pas pleinement aux besoins des services régionaux puisque les archéologues ont beaucoup de mal à récupérer les informations qui les intéressent surtout à cause de la lenteur du système (pour afficher un mot de recherche il fallait entre plusieurs secondes et deux à trois minutes). Les buts recherches par cette informatisation étaient tout de même de pouvoir répondre à une question plus rapidement que par une recherche manuelle. Pour pallier à ces problèmes on voit se développer en parallèle d’autres bases de données développées sur micro-ordinateur.

En 1991, une nouvelle base de données, DRACAR (acronyme de Direction Régionale des Affaires Culturelles et d’ARchéologie) est proposée aux régions. DRACAR reprend le système de site de SIGAL en y associant deux nouveaux fichiers : le fichier opérations et le fichier intervenants. DRACAR est là aussi une structure centralisée que les services régionaux de l’archéologie pouvaient interroger par l’intermédiaire de terminaux reliés par réseau au site central. Cette base avait pour fonctions la :

• Gestion des sites archéologiques.
• Gestion des dossiers d’aménagement du sol.
• Tenue à jour d’un fichier des intervenants et des aménageurs. (Duhamel 1992)

Figure 1 : fiche papier d’inventaire de site pour saisie dans SIGAL Un patrimoine à enrichir ... prospection et inventaire archéologiques, journées d'études à Epône, samedi 27 mai 1989. Versailles, Service Archéologique Départemental, 1990 (Archéologie en Yvelines, document de travail ; 2)

De plus par l’intermédiaire de l’application SCALA — à partir de 1993 —, DRACAR permettait d’accéder à la représentation cartographique des données.

Néanmoins, malgré les demandes répétées de création d’un véritable groupe de travail et de pilotage, le nouveau système (DRACAR) a été conçu sans tenir réellement compte ni des expériences antérieures, ni des avis de divers responsables, ni des réalités vécues au quotidien dans les régions. ¹⁸ Au fur et à mesure de son utilisation, DRACAR soulève donc des critiques de plus en plus insistantes. Ces critiques portaient sur les points suivants :

• Ergonomie désuète : la saisie d’un site s’effectue généralement sur quatre écrans différents. Il y a beaucoup de problèmes pour passer facilement d’une rubrique à une autre sans suivre un chemin imposé, ainsi que pour passer d’un écran à l’autre. Les 3/4 des écrans sont occupés par les noms de rubriques et non pas par les données, …
• Centralisation des données
• Dysfonctionnement de l’application : lenteur du système, délais d’accès à l’information important, parasitage, impossibilité d’accès aux données pendant plusieurs jours d’affilée, …
• Possibilités de recherche incomplètes : temps de réponse souvent très long, processus souvent malaisé et incomplet (absence de relation “OU” entre critères), un langage abscons : “#in ('PAL','NEO')” pour demander que la chronologie contienne paléolithique ou néolithique, …
• Données essentielles absentes : sources documentaires et données sur le mobilier (supprimé lors du passage de SIGAL 2 à DRACAR et donc perte d’informations)
• Manque de souplesse des éditions : seules les copies d’écrans permettent une sortie imprimée rapide, les formats sont mal présentés, ils ne peuvent être ni conçus, ni adaptés aux besoins, …
• Problèmes de formation : absence d’un manuel d’utilisation mis à jour qui implique une formation expérimentale sur le tas.
• Utilisation d’un vocabulaire fermé, non univoque, pas suffisamment hiérarchisé et inadapté.

Cet état des lieux explique le nombre important de bases de données parallèles qui se sont développées au sein des SRA pour pallier ces manques et pour avoir un système d’inventaire complet et utilisable dans de bonnes conditions. En effet il était essentiel de pouvoir donner une réponse immédiate aux dossiers à instruire. Ceci entraînait soit une double saisie (saisie DRACAR et saisie base SRA), soit un arrêt complet de l’alimentation de la base DRACAR.

Figure 2 : fiche papier d’inventaire de site avant sa saisie dans DRACAR

En 1994, la Sous Direction de l’archéologie prend la décision de lancer un audit sur l’application DRACAR. Cet audit était destiné à la fois à expertise de l’application DRACAR, à l'identifier des raisons de sa sous-utilisation et à l'évaluation des applications régionales complémentaires ou parallèles, en vue d'établir des propositions d’aménagement ou d’évolution permettant de mieux répondre aux besoins des utilisateurs, tout en respectant les contraintes techniques du ministère.

DRACAR avait vécu puisque son évolution n'aurait pas permis de répondre aux besoins des utilisateurs. L’audit proposait donc les options suivantes pour l’installation d’un nouveau système : localisation en région des bases de données et des applications, intégration des bases documentaires, préservation des acquis des “systèmes maisons” et intégration des produits pré-existants de représentation cartographique par exemple.

À la suite de cet audit, un comité de pilotage a été nommé pour pouvoir étudier les possibilités d’un remplacement de l’application DRACAR par un système plus proche des besoins des utilisateurs régionaux. Ce comité devait pour cela établir un cahier des charges des besoins des utilisateurs. Un second cahier des charges portant sur les sources documentaires devait aussi être conçu. Ce comité, constitué en décembre 1994, regroupait des représentants de l’administration centrale (direction de l’administration générale (notamment le DOSI : département de l’organisation et des systèmes d’information) et direction du patrimoine (notamment la SDA)) et des services déconcentrés du ministère (services régionaux de l’archéologie).

En juillet 1995, les cinq orientations majeures de la future application étaient entérinées. Elles s’organisaient de la manière suivante :

• Une application en région, répondant aux différents besoins quotidiens des services, dont la fonctionnalité devait s’accompagner d’une simplicité d’utilisation (ergonomie) ;
• Cinq objectifs majeurs : l’inventaire archéologique, le traitement des dossiers d’aménagement et de protection, la gestion documentaire, l’administration de la recherche, l’aide et l’orientation des recherches ;
• La nécessité d’un réseau interne dans les DRAC puisque l’application serait destinée aux diverses taches d’un SRA ;
• L’importance des références spatiales constituant un point d’entrée majeur et commun à la majorité de l’information ;
• L’existence d’un “tronc commun”, indispensable à l’homogénéité nationale et à la maintenance de l’application, complété par la possibilité de créer, importer et exporter localement des fichiers spécifiques.

Petit à petit tous ces éléments vont se mettre en place, la réflexion va se concrétiser, toujours en prenant en compte les demandes et besoins des utilisateurs : des logiciels de SIG sont testés, des listages et caractéristiques de champs sont précisés, les grands ensembles d’informations sont dégagés, un groupe de travail “thesaurus” est mis en place, …

Cette application serait donc composée d’une structure de base de données commune à tous les SRA qui pourrait ensuite évoluer en fonction des besoins de chaque service. Ce tronc commun est indispensable puisqu’il va permettre une unification de certains éléments communs à chaque SRA et nécessaires aux échanges entre bases. L’unité documentaire ne sera plus le site mais l’information archéologique localisée. Cette information peut être soit une entité archéologique, caractérisée par un ensemble cohérent de vestiges ¹⁹ présentant une unité chronologique et/ou fonctionnelle sur un espace donné, soit un lieu contenant des vestiges indéterminés (mobilier mal caractérisé ou peu caractéristique …), soit un lieu contenant peut-être des vestiges (anomalie phytologique …), soit un lieu dont on sait, par des sources d’informations extra-archéologiques (archives, géomorphologie …), qu’il est susceptible de contenir des vestiges archéologiques (toponyme, zone alluviale …), soit enfin un objet ou un ensemble d’objets déplacés (collection hors contexte …).

Le tronc commun est en fait composé de trois ensembles géoréférencés :

• Les entités archéologiques
• Les opérations archéologiques
• Les protections

Ils sont complétés par trois tables (c’est-à-dire de fichiers contenant des données qui permettent de compléter les données saisies dans les trois ensembles auxquels ils sont liés. Par exemple, il suffit dans l’ensemble opération de saisir le nom du responsable de l’opération pour qu’automatiquement ses coordonnées apparaissent) :

• Les données géo-administratives qui sont géoréférencées,
• • Les sources documentaires
  • Le répertoire d’adresses ou annuaire.

Ce tronc commun est associé à un SIG. Après des tests c’est le logiciel Arcview© qui a été choisi. Le géoréférencement des ensembles et des tables se feront directement par l’intermédiaire des plans et cartes constituant le SIG. Plus simplement, la géométrie (les coordonnées) de l’information archéologique localisée n’est pas renseignée dans la base mais dépend directement du SIG. En fait ce système va demander des échanges permanents entre bases nationales (PATRIARCHE) et bases régionales (les fonds de cartes qui servent de supports au SIG) avec tous les problèmes que cela peut amener (variation de la qualité de la connexion, coupures, …)

Durant l’été 1996, la transcription technique du cahier des charges met en évidence une difficile conciliation avec les impératifs techniques et économiques. Le DOSI exprime son souhait d’une architecture centralisée où application et données sont accessibles via le réseau, choix justifié en termes d’économie, de simplicité technique et de maintenance. Ceci en opposition totale avec les recommandations du comité et la validation du projet global.

À partir de la traduction concrète par un système informatique de solutions formulées, les problèmes se sont multipliés. Ils portaient surtout sur la recentralisation, l’abandon de potentialités et l’obligation d’utiliser des programmes lourds. Le calendrier prévisionnel de 1997 présentait les premières mises en service et formations pour le premier semestre 1999 (Au départ du programme, PATRIARCHE devait être livrée durant l’année 1997). PATRIARCHE a en fait été livré dans les régions à la fin de l’année 2002. Six ans de retard pour une application qui pose déjà des problèmes puisqu’un travail sur la version 2 de PATRIARCHE est déjà en cours pour pouvoir corriger les imperfections majeures de l’application.