Les problèmes institutionnels.

Ces problèmes portent surtout sur les points suivants : qui doit créer ces banques de données et surtout qui doit les suivre ? J.-C. Gardin met en avant la contradiction entre la nécessité du traitement à long terme des données et l’“inévitable brièveté des entreprises personnelles. En d’autres termes, c’est à des institutions moins éphémères que les individus que devrait être confiée la responsabilité de l’entretien des banques de données, sous ses multiples aspects : corrections, suppressions, additions, intégrations, mise en relation avec des entreprises connexes, à l’échelle internationale, etc.”.

Pour l’entreprise que j’ai engagée ici, cette interversion de J.-C. Gardin de 1972 est un état des lieux très intéressant pour pouvoir tirer un bilan de la réalité des bases de données en archéologie aujourd’hui et de son évolution. J.-C. Gardin y soulève les problèmes que les archéologues commençaient à rencontrer et allaient rencontrer dans les années suivantes pour le développement des banques de données ou bases de données. Malheureusement ces remarques n’ont pour la plupart pas été prises en considération et trente ans après J.-C. Gardin pourrait faire à peu près le même constat.

C’est le domaine théorique qui a, en apparence, le plus évolué. Aujourd’hui il n’y a pratiquement plus de problèmes en ce qui concerne le type de données qui sont incluses dans les bases. Ces bases regroupent aussi bien des données naturelles, que j’appellerai dans mon développement des données primaires et des données savantes, que je nommerai données traitées. D’ailleurs au delà de leur type, les données archivées dans les bases sont pratiquement toujours les mêmes, à savoir : le mobilier, les objets, les couches, les liens directs entre ces différents éléments ainsi que les photographies, les minutes de terrain, les journaux de fouille, les fiches de saisie sur le terrain et tout ce qui concerne la topographie du lieu (relevés, cartes, …), ainsi que le résultat d’études menées sur les données primaires (études de mobilier, …), les assemblages de plans, les dessins d’objet ainsi que tout ce qui touche à l’interprétation des données primaires (interprétation des couches archéologiques, …), à la datation et aux regroupements de données comme les associations de couches (faits, structure, entités archéologiques, …) sans oublier la documentation indirecte et l’archivage physique de toutes ces données. De plus les descriptions de ces données se font aussi bien en langage naturel, surtout en ce qui concerne les commentaires, les descriptions documentaires et la rédaction de textes d’analyse, qu’en langage documentaire ou contrôlé par l’intermédiaire de listes de termes qui permettent d’associer une donnée à un nom ou mot.

Par contre du point de vue technique — au-delà biensûr de toute évolution des ordinateurs et des logiciels de gestion — et du point de vue institutionnel peu de changements sont à noter. Les bases de données sont encore pour la plupart développées par des individus et se pose donc toujours le problème de la pérennité de la base lorsque l’individu n’en assure plus le suivi. De plus, on pourrait penser que l’on se trouve toujours dans la phase de test recherche-expérimentation que J.-C. Gardin préconisait en 1972 et que toutes les bases actuelles sont des projets-pilotes. En effet on ne note aucun effort pour mettre en place des bases de données répondant à la demande de liaison entre les données de différentes bases comme les chercheurs aujourd’hui en émettent le souhait et en éprouvent le besoin, essentiellement parce que personne ne veut abandonner le système qu’il a créé. Aujourd’hui, les bases de données ne sont toujours pensées qu’en fonction d’un lieu ou d’un type de recherche sans tenter de devenir évolutives et d’être utilisées par le plus grand nombre.

Devant ce constat, c’est-à-dire le peu d’évolution que l’on peut constater sur une période de trente ans, il m'est apparu qu’il était important aujourd’hui d’aller si possible plus loin que J.-C. Gardin en 1972. En plus de mettre en avant les problèmes qui se posent pour la création, l’usage et le suivi des bases de données en archéologie, je vais tenter de proposer des solutions à ces problèmes. C’est pour cela que j’ai entrepris cette thèse sur : nature, statut et traitements informatisés des données en archéologie : les enjeux des systèmes d’informations archéologiques.

Pour organiser ce travail, je vais me fonder directement sur les termes contenus dans le sujet ci-dessus. Il faut avant tout revenir sur des principes théoriques et replacer dans son contexte archéologique cette notion de donnée. Pour cela je déterminerai sa nature c’est à dire son apparition dans le domaine de l’archéologie, ce qu’elle regroupe comme informations, comment on peut associer des données, sans oublier bien sûr d’en fournir une définition. Je présenterai aussi les définitions de termes associés qui reviendront de manière récurrente dans mon développement et qu’il me semble important de présenter. Je proposerai aussi un développement sur le statut de la donnée, son état de donnée du présent puisque l’on ne retrouve jamais ce que l’homme du passé a laissé mais quelque chose qui a été modifié par la transmission sur des millénaires. Ensuite je qualifierai le traitement informatique des données. Je commencerai par faire un historique de l’utilisation des mathématiques et de l’informatique en archéologie. Je poursuivrai par quelques définitions et l’analyse des différentes bases de données que l’on peut rencontrer dans le domaine.

Toujours dans le traitement informatisé des données, je reviendrai sur les enjeux de ces bases de données qui sont d’ailleurs ceux que J.-C. Gardin avaient établis à savoir “[…] des liaisons de l’une à l’autre [d’une base de données à une autre], de telle sorte que les utilisateurs puissent aisément consulter plusieurs d’entre elles, pour une même recherche”, ainsi qu’une pérennité de ces données par un suivi et un développement dans le temps au sein d’une institution. En fait ce problème pourrait être réglé facilement par l’emploi dans chaque base d’éléments homogénéisés, communs à toutes. Ces éléments clefs sont l’unité documentaire, les codes d’inventaires, les champs de description minimaux nécessaires pour identifier une donnée et le langage utilisé pour l’enregistrement dans ces champs. Autour de ces éléments, on pourra ensuite développer la base comme on le souhaite. De plus lorsqu’une base n’est plus exploitée et développée, on pourra sans difficulté incorporer ses données dans une autre base encore exploitée et permettre ainsi une sauvegarde durable. Pour montrer la nécessité d’homogénéiser ces quatre éléments clefs, je propose d’effectuer une étude de compatibilité des codes d’inventaires et des champs de saisie entre deux bases de données utilisées aujourd’hui (bdB et ArchéoDATA) en vue d’une mise en commun des données. Ce passage est dangereux puisqu’il implique l’usage de tables de conversion de codes d'inventaires qui peuvent entraîner à long terme une perte de données suite à l’altération de ces conversions.

Enfin je proposerai quelques exemples de normes disponibles aujourd’hui, comme le projet de norme documentaire internationale pour les sites archéologiques du Comité international pour la documentation, le CIDOC, ou celle qui a été mise au point pour l’inventaire archéologique de la France, exploité par l’application PATRIARCHE, et qui est un élément important dans cette entreprise d’homogénéité. Je reviendrai aussi sur l’action thématique programmée “archéologie métropolitaine”-Appel d’offre “archives de fouilles”, qui fut lancée en 1988. Cette ATP marque l’intérêt des institutions pour “la constitution d’archives du matériel de fouille, non imprimées mais communicables” et a été le moteur de développement d’une dizaine des bases encore utilisées aujourd’hui. Ces notions théoriques et ces développements sur les problèmes techniques des bases de données sont rassemblés dans la Partie A du présent travail.

Dans la Partie B, je présenterai une étude de cas de bases de données utilisées actuellement en France pour essayer de voir si tout de même il n’existe pas des similitudes de traitement dans ces bases, de voir ce qui a déjà été fait et comment cela a été fait afin d’en tirer des éléments permettant de proposer une solution à ces problèmes techniques. Quels sont les différents composants d’une base de données ? Que mettre dans une base de données ? dans quel ordre ? Sous quel nom ou identifiant ? Comment le décrire ? De quoi a besoin un archéologue pour archiver ses données sur ordinateur ? Ces bases sont au nombre de cinq et couvrent un corpus cohérent des actions actuelles en archéologie, en allant de la fouille de sauvetage à la fouille programmée sur un grand site disposant de tout le confort de travail nécessaire. Ces bases sont les suivantes :

Ce corpus, pour des raisons que je détaillerai dans la Partie B, chapitre I, sous-section 1 – Choix de bases métropolitaines, p. 76, ne prend pas en compte les bases de données de fouilles françaises à l’étranger, ni les bases de données d’autres pays. J’ai réuni un corpus qui me permet de toucher à des bases ayant un développement différent, des zones d’interventions plus ou moins grandes, concernant toutes les périodes de la préhistoire à nos jours et surtout s’adressant soit à des utilisateurs uniques, soit à des utilisateurs multiples, ce qui est un facteur déterminant dans le fonctionnement d’une base de données en archéologie. Chaque base sélectionnée a fait l’objet d’une étude technique complète qui a donné lieu à la rédaction d’un rapport. Le rapport est conçu selon le plan suivant : une présentation de la base (nom, concepteur, lieu d’utilisation et logiciel support), un historique de sa conception, le matériel fourni pour l’étude, les principes de la base ainsi que les codes utilisés, l’étude générale de la base avec la structure, les fichiers d’accès, l’ergonomie générale des écrans, les protections, modes de saisie, de recherche, de consultation, modèles d’impression, et lien avec le fonctionnement de la fouille puis une étude spécifique, fichiers par fichiers, écrans par écrans et presque je pourrais dire, rubrique par rubrique. Ce rapport se conclut par l’état des problèmes que j’ai pu mettre en évidence dans le fonctionnement de la base et une ou plusieurs propositions pour les résoudre. Je ne reprends dans ce volume que des extraits des études pour en faire des synthèses. Les rapports complets, ainsi que d’autres documents d’études dont il me semblait important de présenter la totalité dans ma thèse, sont rassemblés dans le Tome II : RAPPORTS. Ces synthèses vont me permettre de proposer une solution pour surmonter le problème actuel de l’inexistence de liaisons possibles entre les bases de données, de compatibilité, de l’impossibilité de faire des recherches croisées et de régler le problème de la pérennité des bases de données et donc par là des données recueillies.

Dans la Partie C, je vais proposer avant tout un protocole de création de bases de données. Ce protocole est constitué de onze étapes hiérarchisées et chronologiques qu’il est indispensable de suivre pour créer une base de données logique et structurée. Il se base sur le long parcours suivi par les concepteurs des bases précitées qui se sont plus ou moins tous heurtés aux mêmes impasses et aux mêmes problèmes. Ce protocole, s’il est suivi à la lettre, devrait permettre d’éviter ces impasses, de limiter les écueils, les retards et les dysfonctionnements d’une base. Avant de proposer ce protocole, je l’ai bien sûr testé lors de la conception de la base de données LILA, destinée à l’étude des cycles narratifs en Inde du Sud, programme de recherche lancé par le Centre de Pondichéry de l’École française d’Extrême-Orient.

Ce protocole va me permettre de mettre en place ma réflexion sur un tronc commun permettant de régler ces problèmes d’homogénéité, de visibilité, d’exploitation et de pérennité des données. Ce tronc commun regroupe 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 vue de leurs sauvegardes et de leurs études. Les bases seraient donc semblables, puisqu’elles utiliseraient les mêmes éléments de fondation mais aussi indépendantes puisqu’elles évolueraient à partir de ce tronc commun en fonction des besoins de la fouille. Cette proposition va dans le sens de l’avis de J.-C. Gardin selon lequel l’objectif commun de chaque banque de données serait “[…] le respect d’une certaine diversité des systèmes documentaires, et le souci d’aménager néanmoins ceux-ci pour rendre possible les communications, voire les inter-connections automatiques de l’un à l’autre”. Cette proposition veut être une synthèse de toutes les remarques, les constatations, les observations, les mûrissements, …, que j’ai pu faire au cours de ces quatre années de travail. Je ne veux pas fournir ici un énième système d’archivage — d’ailleurs cette proposition se limite à une structure papier. Mais, pour aller au-delà de ce que proposait J.-C. Gardin en 1972, je veux présenter une solution, une parmi sûrement d’autres, pour surmonter les problèmes que l’on rencontre depuis longtemps et encore aujourd’hui sur le sujet des bases de données en archéologie. Ce tronc commun serait une sorte de base minimale nécessaire à tout archivage de données.