Face à la base de données. Le décalogue du chercheur

 

Face à la base de données
Le décalogue du chercheur

 

Dans la création d'une base de données, la partie informatique, celle qui obnubile l'utilisateur potentiel, ne constitue en réalité qu'une part réduite d'un ensemble plus vaste, qui consiste pour l'essentiel en une réflexion sur les données et l'utilisation que l'on veut en faire. Nous avons couché ces observation sous la forme d'un décalogue à l'issue d'une rencontre récente où les travaux présentés – dont certains comptent cependant parmi les plus remarquables exemples d'histoire numérique – témoignaient tous de la difficulté de cette mise en perspective.

 

I. L'ordinateur tu exploreras.

 

Si tu projettes de bâtir une base de données, commence par te familiariser avec l'ordinateur. Il te faudra assimiler les notions de champs, de table, de fichier, de lien, d'exportation, de requête, de tri, et quelques autres. On ne te demande pas de savoir programmer (ce serait souhaitable, mais restons réaliste). On te demande en revanche d'avoir conscience des possibilités et des limites des différentes technologies disponibles. Savoir par exemple qu'il est difficile à un néophyte de formuler une requête en SQL, ce qui limite fortement l'utilité de celles-ci pour la recherche. Savoir qu'il existe différents types de logiciels, chacun plus efficace dans un domaine particulier, mais ne devant pas être utilisé hors de cette enveloppe: Excel est un excellent tableur, mais une très mauvaise base de données. Connaître bien entendu ces différents types de logiciels, bien faire la différence entre une base de données, un tableur et un traitement de texte. Savoir passer des données de l'un à l'autre, sous format tabulé ou csv (ce point est fondamental)1.

Ce sont là les connaissances de base qui te permettront de dialoguer utilement avec les ingénieurs auxquels tu auras affaire, d'assimiler les informations qu'ils te transmettront, de progresser vers plus d'autonomie, de dessiner toi-même les lignes générales des manoeuvres que tu prévoiras d'exécuter.

Cette connaissance, tu l'acquerras en quelques jours dans des stages spécialisés, ou tu l'auras reçue au cours de tes études à l'université. Ne te lance pas sans la posséder. Tu perdrais beaucoup de temps pour un résultat au mieux médiocre.

 

II. Ton projet tu définiras et à une classe assigneras.

 

Une base de données n'est pas une fin en soi. Elle n'est qu'un instrument pour une finalité qui la dépasse. Il n'est rien de plus irritant pour un technicien qui a consacré des semaines à un travail que de s'entendre dire: "Et maintenant, à quoi ça sert?". Sic. Je parle d'expérience, et je ne suis pas le seul à l'avoir entendu. Tu éclairciras dans un premier temps tes objectifs et l'usage que tu penses faire de l'instrument que tu entends créer.

De cette finalité dépendront nécessairement ses caractéristiques. On peut distinguer quatre classes de bases de données2.

. Les bases de données brutes. Elle prennent un document brut, elles le numérisent et le livrent accompagné des éléments de description extérieurs qui permettent de le localiser parmi d'autres, et éventuellement d'un regeste qui donne une idée de son contenu. C'est à l'utilisateur de mobiliser le contenu pour en faire ce dont il a besoin. Ces bases contiennent généralement des séries constituées en dehors d'elles, dont elle reprennent la structure: les collections de la BNF, les fonds des Archives d'Etat espagnoles, par exemple. Gallica (BNF) ou PARES (Archives espagnoles), issus de ces fonds, en sont des exemples typiques.

. Les bases de publication, qui stockent des données élaborées, mais figées. Il s'agit toujours de corpus artificiels, définis ad hoc par un chercheur. Ce peuvent être des données brutes ou semi-élaborées ayant servi à une recherche. Il peut s'agir de collections documentaires rassemblées autour d'un thème à la manière d'un ouvrage (voire d'un ouvrage d'art) classique, organisées dans un parcours formant récit (Virtual Shanghai de Christian Henriot et Gérald Foliot). La forme numérique leur donne une souplesse infiniment supérieure à la publication papier: l'utilisateur peut en changer l'ordre, constituer des groupes thématiques, trier…, utilisant le matériau proposé comme support de sa propre créativité, ce qui dote ces collections d'un pouvoir de suggestion qu'interdit la rigidité de l'édition en volume, où seul est possible le récit imposé par l'auteur. Mais la base est généralement fermée et, en général, n'est pas faite pour intégrer massivement des données de types nouveaux, les vérifier, les interpréter, les marquer, les décomposer dans leurs éléments constituants, les marquer comme relevant de telle ou telle classe en fonction de telle ou telle recherche particulière, en dehors du parcours prévu par le concepteur. On donnera en exemple la base de données sur la traite atlantique, http://slavevoyages.org/

. Les bases de stockage d'information à usage unique3. C'est l'équivalent des dossiers préparatoires que constituait chaque chercheur pour chaque enquête à l'époque du crayon et du papier. Notes d'archives, reproductions graphiques, clichés de documents originaux, tableaux statistiques plus ou moins élaborés, résultats d'analyses menées sous tel ou tel logiciel… Chaque pièce marquée comme relevant de tel ou tel domaine, au gré du propriétaire, et pouvant être retrouvée de façon presque instantanée grâce à la puissance de l'informatique. Ces bases ne sont pas faites pour analyser systématiquement des données complexes. Bien plutôt pour reprendre les résultats de telles analyses et les mettre rapidement sous les yeux du chercheur. Bases à usage unique, car leur organisation et leur contenu sont hautement personnels. C'est un instrument de travail extrêmement utile. Il existe des logiciels de ce type dans le commerce ou en accès gratuit (Mydata Keeper, Treepad Lite, etc.). Il serait intéressant de vérifier quels sont ceux dont la souplesse répond aux exigences de chercheurs, dont les attentes sont par définition imprévisibles et éventuellement, de les améliorer.

. Les bases de données cumulatives pour la recherche. Ce sont des bases de données destinées à héberger des données brutes à des fins de recherches nouvelles. Elles peuvent être d'usage général ou ne concerner qu'un type particulier de documents. En tout état de cause, elles atomisent l'information, autrement dit la réduisent à ses éléments de plus fine granularité, hors de toute visée à une utilisation spécifique, pour permettre à l'utilisateur de sélectionner les sous-ensembles qui lui agréeront et de les remonter dans l'ordre qui convient à sa recherche avec une totale liberté, quelle que soit l'utilisation qu'il entend en faire. Elles sont donc par définition d'usage collectif. Chaque élément atomisé est relié par un lien explicite à tous les éléments auxquels le lie la documentation. Chaque élément est identifié par un identifiant unique. La base est incrémentielle au sens où il est possible d'insérer indéfiniment des données supplémentaires d'un type existant ou d'un autre type, sans en modifier la structure et sans rien perdre des données nouvelles – ce point est capital pour la recherche -. Elles reposent sur une analyse fine de la nature des documents mis en oeuvre, qui isole leurs composants avec une granularité beaucoup plus fine que leur simple distinction physique, celle qui servait de module aux bases documentaires. Reposant sur la structure interne des éléments mis en oeuvre, elles ont un degré de généralité qui leur permet de traiter dans une même structure les contenus les plus divers. Ce sont des objets complexes, dans leur structure et dans leur contenu, que seuls des spécialistes peuvent manier. Elles permettent de constituer de façon souple n'importe quel sous-ensemble pris dans l'univers qu'elles contiennent. Les données sont bien entendu exportables soit à destination de logiciels d'analyse, soit à destination de bases d'autres types. Fichoz relève de cette classe.

 

Il est évidemment capital que tu saches, lecteur, quel type de base tu veux réaliser. Pour ce faire, tu t'entoureras de conseils. Consulte quelque historien connu pour avoir réalisé une base de données du type que tu recherches, et une base qui a marché, qui lui a réellement servi à la production de résultats. Un historien, pas un technicien, pas encore. Ce qui t'intéresse ici, ce n'est pas la technique, mais une vue d'ensemble du processus, utilisation finale comprise.

 

III. Tes données analyseras, atomiseras et en tables rangeras

 

Toutes les bases de données, quel que soit le système technique sur lequel elles s'appuient, reposent sur le découpage de leur matière en blocs manipulables, semblables à autant de containers identiques, à l'intérieur desquels se trouve une information qui elle est variable. Ces containers sont munis d'étiquettes en indiquant le contenu, ce qui permet de sélectionner ceux qui intéressent à un moment donné, et de poignées qui permettent de les saisir, de la déplacer, de les lier les uns aux autres en chaînes d'informations.

La construction d'une base de données repose avant tout sur une analyse des données qu'elle doit contenir, à la lumière des objectifs poursuivis. La question de leur adaptation aux outils informatiques choisis doit être subordonnée, donc postérieure, à cette analyse et à ses conclusions. Les considérations techniques ne doivent jamais guider les choix scientifiques. Tout au plus en limiter la réalisation ou imposer des voies particulières à leur réalisation.

La première question que tu dois te poser est celle de la nature et de la taille des containers. Quel est l'atome d'information minimal dont tu as besoin? Prenons par exemple un projet sur les films occidentaux projetés en Chine dans les années 1920-19304. Il apparaît très vite, en écoutant l'auteur, que l'atome minimal n'est pas le film, comme elle l'affirme. Elle souhaite savoir en effet dans quelle condition et combien de fois le film a été projeté dans chaque ville. L'atome de base est donc la séance de projection. Séance qu'elle souhaite décrire à l'aide d'un certain nombre de descripteurs qui seront autant d'étiquettes pour manier cette information: sonorisation, description et localisation de la salle lors de cette séance, nombre et nature des spectateurs, date, heure, tarifs de la séance, etc. L'ensemble de ces containers, dont chacun décrit une séance, sera stocké dans un même espace, sous l'étiquette "Séance".

Mais deux des descripteurs qui définissent la séance, la salle et le films, doivent faire eux-même l'objet de descriptions précises pour être utilisés dans cette recherche. Chaque salle devra être stockée dans un container muni d'étiquettes telles que localisation, capacité, propriétaire, exploitant, etc. Tous ces containers seront stockés dans un espace différent du premier. Nous l'intitulerons "Salles". De même chaque film sera stocké dans un container particulier, muni d'étiquettes telles que sa durée, des caractéristiques techniques, son générique, etc…

A vrai dire, l'analyse ici nous révèle rapidement que le film n'est pas le niveau d'atomisation pertinent. L'auteur sait qu'un film peut se présenter en de nombreuses versions, sous des titres différents, avec des montages différents, en des langues différentes, et que ce que voit le spectateur n'est pas le film en soi, mais une version particulière. Le but de la recherche étant d'évaluer l'impact sur le spectateur, c'est donc la version, le seul élément avec lequel il est en interacton, qui devra servir de base d'atomisation pour décrire ce que l'on projette en séance. Nous créerons autant de containers que de versions, nous les munirons d'étiquettes telles que leur titre, leur durée, une description des différences qu'ils présentent avec l'original, la langue, etc. Nous stockerons tous les containers décrivant chacun une version dans un espace que nous nommerons "Versions".

Mais toutes les versions d'un même film remontent à un même original, qui lui-même doit être stocké dans un container dont les étiquettes descriptives seront son scénario, son générique et autres éléments habituels dans la description d'un film qui restent communs à toutes les versions. Tous ces containers seront stockés dans un espace propre que nous avons dénommerons "Films".

Nous arrêterons là, car à ce point nous couvrons les besoins de la recherche projetée (Schéma I), mais nous pourrions envisager un espace Acteurs, où nous décririons la carrière de chacune des personnes impliqués dans la fabrication du film, et ainsi de suite ad infinitum.

Graphique I

 

capture-decran-2016-10-14-a-09-35-37

 

Chacun des containers contenu dans chacun de ces espaces doit être muni d'une poignée qui permette de le saisir. Cette poignée prend la forme d'un identifiant unique, formé par exemple d'une chaîne de huit chiffres, dont la seule fonction est de l'identifier. Il est alors possible de définir dans la base de donnée des "liens" joignant deux à deux ces poignées (Graphique II).

 

Graphique II

capture-decran-2016-10-14-a-09-36-26

 

On définit ainsi des objets complexes formées de chaînes de containers appartenant à des espaces différents, qu'il est possible de lier avec souplesse. Il est possible d'appeler chaque container à partir de ceux qui leur sont liés, et inversement. Tout se passe comme si chaque chaîne constituait un objet indépendant qu'il serait possible de traiter avec souplesse en la saisissant à partir de l'un quelconque de ses maillons.

Cette analyse, tu me pardonneras d'insister, lecteur, est indispensable et préalable au choix du logiciel ou du système d'information que tu vas utiliser. Du choix correct de l'atome d'informatisation et des différents espaces, tout le reste dépend. Tu te feras conseiller sur ce point par un chercheur, si possible expérimenté en bases de données, mais un chercheur. Un informaticien risque de ne pas savoir déployer ta demande dans toutes ses dimensions, car il est à parier que ton expression sera balbutiante et que toi-même tu ne saisiras pas d'emblée l'ampleur de ce que tu désires. L'auteure de l'exemple sur lequel nous nous appuyons en a fait la cruelle expérience.

 

IV. Tes outils après cela choisiras.

 

Cette étape capitale franchie tu seras en mesure de choisir les outils adaptés à ton projet. Ici il te faudra consulter un ingénieur. Ou plusieurs, pour avoir plusieurs avis, car logiciels et applications sont si nombreux qu'il est difficile à une seule personne d'en prendre une vue d'ensemble.

Il existe plusieurs manières de numériser la structure de nous avons décrite au commandement précédent. Nous préférons de loin, personnellement, celles qui reprennent tel quel le schéma que nous avons donné (Schéma II) en le transcrivant en enregistrements (les containers), champs (les étiquettes) et tables (les espaces communs). Cette manière de faire rend beaucoup plus aisé le maniement de la base.

Tu choisiras soit de te rallier à une base de données existante, à laquelle tu agrégeras tes données, ou dont tu reprendras la structure dans une base vide; soit de créer un modèle nouveau.

De ce choix tu déduiras celui du logiciel.

Dans toute cette opération tu garderas présente à l'esprit que la structure que tu élaboreras:

. doit impérativement remplir toutes les conditions de la classe de base de données que tu as en vue;

. doit posséder la meilleure ergonomie possible, car constituer et utiliser une base de données exige de nombreuses opérations, tout gain de temps sur chacune signifiant une économie appréciable en bout de piste; en ne perdant jamais de vue que l'oeil du chercheur est toujours le dernier maillon de la chaîne d'information que tu manies, ce qui signifie que la capacité à offrir une présentation visuellement soignée est un élément essentiel du choix;

. doit présenter la plus grande souplesse possible pour te permettre de revenir sur tes décisions et ne pas exiger de toi des choix irréversibles à un stade précoce de ton travail.

 

Tu veilleras également à la pérennité du système. Lorsque tu crées une base de données, tu travailles sur le long terme. Le logiciel que tu utilises doit être suffisamment courant pour que tu aies la certitude de sa propre continuité et de la continuité d'une communauté d'utilisateurs capables de le mettre en oeuvre. Tu éviteras les applications ad hoc, écrites pour ton usage personnel. Tu veilleras à ce que les données soient facilement exportables sans pertes, à des formats standards, sous une forme aisément compréhensible. L'apprentissage que tu auras effectué sous le premier commandement te sera ici de la plus grande utilité.

Tu pèseras soigneusement les aspects financiers. Outre les contraintes évidentes qu'ils introduisent dans tes choix immédiats, ils ont des incidences sur la pérennité de ta base. Fuis comme la peste les hébergeurs payants, si tu as des prétentions à la durée. Souviens-toi que rien n'est jamais gratuit sauf ce que tu fais toi-même. Le travail d'un ingénieur CNRS ou de l'Université coûte à la collectivité plus cher que la plupart des logiciels du commerce pour une tâche équivalente, et introduit un risque nettement plus fort pour la continuité de ton travail: les mutations, congés, suppressions de crédits et fermetures de laboratoire sont monnaies courantes dans l'administration, pour ne rien dire des départs à la retraite5.

 

V. Une maquette tu créeras.

 

Tout cela réglé, tu ne lanceras pas sans précautions de vastes opérations de recherche. Une fois créée ta base de données comme expliqué ci-dessus, tu la feras tourner sous une quantité limitée de données. Une base de données est un objet d'ingénierie unique. Il n'est pas d'exemple d'objet d'ingénierie nouveau qui n'ait exigé une période de mise au point, laquelle signifie souvent une révision déchirante des fondements sur lesquels il reposait. Souviens-toi des Comet de De Havilland. Premiers avions de ligne à réaction, fierté de l'industrie britannique, ils avaient une fâcheuse propension à exploser en vol. La faute en était aux rivets de leurs fenêtres carrées dont les coins présentaient autant de points faibles dans la structure. Redessinés, ils ont connu une longue carrière. Veille à ce que ta base n'explose pas en vol après que tu as obtenu sur ses promesses un gros projet de recherche. Fais-la tourner avant, toujours sur les cas les plus complexes que tu penses rencontrer. Quand elle aura fait la preuve qu'elle encaisse toute la complexité de tes données, lance-toi.

Je ne te cache pas, lecteur, que lorsque je participe à une évaluation, sur la base d'une longue expérience, je refuse systématiquement tout projet de recherche qui annonce la constitution d'une base de données sans avoir fait ces essais préalables. Le coût d'une maquette informatique est faible. C'est à ton laboratoire de la financer.

 

Les cinq commandements ci-dessus s'appliquent à toutes les bases de données. Les commandements suivants s'appliquent plus spécialement aux base de données cumulatives pour la recherche. Nous utiliserons en ce qui les concerne le vocabulaire dont nous avons dit qu'il avait notre préférence: enregistrements, champs et tables, dans le sens que nous donnons ci-dessus à ces termes.

 

VI. Traitement et stockage tu sépareras.

 

Les données de toute base de données sont destinées à une exploitation ultérieures par des instruments de traitement et d'analyse. La tentation est grande de procéder à cette analyse à l'intérieur de la base de données, surtout que toute application de base de données contient des instruments de calcul et d'analyse. Procéder ainsi est une erreur. En matière de recherche, la nature des traitements auxquels il faudra soumettre les données n'est pas prévisible. Les instruments de traitements fournis par l'application base de données sont souvent puissants, mais parfois inadaptés au problème posé, et toujours insérés qu'il sont au milieu d'une structure qui leur est étrangère, par nature incommodes à manier.

La base de données doit donc être réservée au stockage des données. Stockage organisé de telle manière qu'il soit possible de constituer à la demande, sans difficulté et avec précision n'importe quel sous-ensemble de données. Ces sous-ensembles, exportés sous forme de texte tabulé ou tout autre format standard, seront transmis à des logiciels d'exploitation spécialisés qui les traiteront en fonction des besoins de l'utilisateur. Celui-ci conservera ainsi, dans ce traitement, toute sa liberté et ne sera pas limité par des contraintes techniques propres à la base. La préservation de cette liberté est une condition indispensable à toute collaboration, les besoins d'un chercheur coïncidant rarement avec les besoins d'un autre. Il est évident que ces logiciels de traitement, le chercheur devra savoir les manier lui-même.

 

VII. Données et interprétation soigneusement tu distingueras.

 

A l'exclusion des bases de données documentaires, qui utilisent comme atomes d'information des blocs de données définis par la source qu'elles reproduisent, toute base de données exige une transformation des données d'origine. Diviser des données en enregistrements (atomisation), sélectionner à l'intérieur du flux d'information qu'elles délivrent des marqueurs qui vont fournir les étiquettes qui décriront l'enregistrement (champs), sont des opérations qui rompent de manière irréversible l'unité de l'objet livré par la source. En un mot comme en cent, la mise d'un objet en base de données revient à le détruire pour le remonter sous une autre forme. Or la base de données est par définition destinée à se substituer à l'objet dans l'utilisation qu'en fait le chercheur. Ce dernier n'accède donc plus à l'objet, mais à l'objet réinterprété par la base. Si le découpage de l'objet original est mal fait, ou le remontage erroné, l'objet est perdu pour lui. Pire, il semble toujours être là, mais il n'est plus le même, et rien n'en prévient l'utilisateur. Toute conclusion fondée sur lui en devient erronée. Le problème n'est pas spécifique à l'ère informatique. Nos prédécesseurs rencontraient la même difficulté lorsqu'ils extrayaient leur matière de la source sous forme de notes ou de fiches bristol.

 

C'est pourquoi:

. La déconstruction et transformation de l'objet original doit se faire à l'intérieur des limites fixées par l'herméneutique documentaire de la discipline concernée.

. Toute transformation nécessaire de la source allant au-delà de ces limites est à proscrire au moment de la saisie, moment où le chercheur n'a pas encore une vision d'ensemble de sa matière, et où son esprit est en outre divisé entre des tâches diverses. Si elle est nécessaire, cette transformation doit faire l'objet de procédures particulières postérieures à la saisie.

. La saisie des données, du moment qu'elle exige un démontage/remontage, doit être confiée à des opérateurs possédant une connaissance suffisante de l'herméneutique de la discipline. Ceci exclut des vacataires non formés6.

 

Exemple:

Soit une entrée d'un registre de la Chambre de Castille, organisme chargé de nommer, entre autres, les magistrats dans l'Espagne d'Ancien Régime:

25 janvier 1674, Juan de la Mesa alcalde de la cuadra de Sevilla.

Etant donné le contexte du document, il est évident qu'il s'agit d'une nomination. Cette ligne formera donc dans la base un enregistrement.

 

Il est fréquent cependant qu'il soit nécessaire d'aller au-delà de ces évidences. Soit les quatre entrées suivantes:

25 janvier 1674, Juan de la Mesa alcalde de la cuadra de Sevilla.

28 janvier 1674, Pablo de Alzaola alcalde del crimen de Sevilla.

15 mars 1674, José Fuentes oidor de Sevilla.

28 mai 1674, Jerónimo Bastos alcalde mayor segundo de Sevilla

 

Tout spécialiste sait qu'alcalde de la cuadra et alcalde del crimen sont deux manières de désigner un même poste de juge criminel à l'Audience de Séville; qu'un oidor est un juge civil de l'Audience, qu'un alcalde mayor, en revanche, n'appartient pas à l'Audience, mais seconde le corregidor. Cette explicitation est indispensable à la correcte interprétation des données. Tout calcul statistique sur la base qui ne la prendrait pas en compte et se fonderait exclusivement sur le vocabulaire, donnerait des résultats absurdes. Faut-il pour autant transformer l'intitulé des entrées en introduisant dans leur énoncé ces éléments d'explicitation? Pas dans un premier temps. Au premier chargement des données toute transformation erronée serait irrécupérable7. Il faut charger comme ça vient. Prévoir ensuite un autre champ où l'on transformera, tout en conservant l'original pour contrôle. L'exploitation se fera évidement dans le nouveau champ, dont le contenu sera seul réellement structuré.

Il en ira de même des individus, corporations, noms de lieux et autres acteurs mentionnés dans la documentation. Ils seront chargés sous le nom que la documentation leur donne, d'autant que les variations de cette formulation sont souvent en elles-mêmes une donnée historique. Ils seront accompagnés d'un identifiant unique qui les identifiera comme une même personne ou des personnes différentes selon les cas, et qui serviront à accrocher les liens qui les uniront. Mais ces identifiants figureront dans un autre champ que le nom proprement dit, de sorte d'une affectation puisse aisément être changée sans incidence sur le reste des données.

 

VIII. En chaque champ une seule information tu stockeras.

 

Les étiquettes (champs) qui marquent chaque container (enregistrement) permettent de le retrouver parmi tous les autres en rendant visible un de ses caractères. Chaque étiquette ne doit idéalement contenir qu'une seule valeur. Au cas où il serait inévitable d'une stocker deux, elles doivent décrire conjointement le même caractère (Exemple: couleur, jaune et vert; jamais: vert et vertical).

De façon plus absolue encore, un enregistrement ne doit concerner qu'un seul et même élément d'information.

 

Exemple:

L'entrée du registre de la Chambre de Castille:

15 mars 1674, José Fuentes auditeur de Seville et juge protecteur de la Confrérie de la Macarena

doit générer deux enregistrements:

15 mars 1674, José Fuentes est auditeur de Seville

15 mars 1674, José Fuentes est juge protecteur de la Confrérie de la Macarena

 

Ceci est une règle absolue. Si la structure de la base rend impossible cette unicité d'information, c'est la structure de la base qui doit être modifiée, non la règle changée.

 

IX. L'intégrité des données tu respecteras.

 

Si pour respecter la règle d'unicité la base exige un choix, t'obligeant à entrer l'une des deux informations et à laisser l'autre de coté, la base doit être absolument modifiée, pas les données. Cette règle ne souffre pas d'exception. La base ne doit en aucun cas obliger à mutiler les données. Tu fais de la recherche. Pas de la littérature ni de l'administration, et le fait qu'un acteur puisse être représenté sous plusieurs angles est un élément fondamental de l'analyse.

 

Exemple:

José Huidobro est échevin de son village et laboureur. Deux étiquettes.

 

Il faut donc que la structure de la base de données fournisse autant d'emplacements vides pour les étiquettes que nécessaire pour stocker toutes les caractéristiques de l'individu. Dans l'exemple de José Huidobro nous pourrions concevoir la présence de deux champs, que nous intitulerions "Position sociale" et "Fonction politique". Imaginons maintenant que l'intitulé soit:

 

José Huidobro, échevin, laboureur et tisserand, procureur des mineurs

 

Il nous faudrait deux champs pour la fonction politique et deux autres pour la position sociale. Or il est fréquent de trouver des enchaînements beaucoup plus long. La seule liste des titres du duc d'Albe, à la fin du XVIIIe siècle, comprend plus de cinquante entrées. Ce n'est pas ici le lieu d'exposer les stratégies à suivre pour prendre en compte de telles informations en respectant la règle d'intégrité que nous sommes en train de formuler. Contentons-nous de retenir que toute base de données qui impose des choix au sein de l'information est vicieuse de vice rédhibitoire.

 

X. Ton temps largement tu calculeras

 

La création d'une base de données est un processus dont on sous-évalue toujours la durée. La mise au point de sa structure peut prendre du temps et nécessiter une dépense d'énergie mentale considérable pour peu que l'on rencontre des problèmes ou qu'il faille remettre sur le chantier un travail que l'on croyait avoir terminé. Le chargement des données est un processus répétitif et particulièrement lassant. Une fois les données chargées, il faut les vérifier, toute erreur risquant de fausser gravement les résultats. Un bon système fournit la possibilité de créer des index d'occurrences et de ranger les données dans des ordres différents, qui facilitent les opérations. Ces dernières n'en restent pas moins fastidieuses. Les données brutes mises en forme, il te restera à procéder à leur indexation, qui va réellement permettre leur mise en oeuvre, et à la pose des identifiants, ce qui n'est ni simple ni rapide. Seule la phase d'exploitation et donnera une sensation de vitesse.

En bout de compte, la durée totale de l'opération de recherche aura été infiniment plus courte que si tu l'avais réalisée à la main; mais l'informatique est fondée sur la répétition: la multiplication des taches répétitives sera pour toi une déception, et peut-être une cause de l'échec de ton projet. Car obnubilé par la vitesse de l'exploitation, tu oublieras l'énorme travail de préparation qui la conditionne en amont. Quand tu présentes un projet, ne soit donc pas trop ambitieux. Tu penses faire deux, déclare un. Tu n'auras que de bonnes surprises, tes évaluateurs aussi.

 

———-

 

Assimile enfin ce commandement nouveau, qui résume à lui seul la Loi et les Prophètes:

 

Seule compte l'efficacité du résultat.

 

D'aucuns essaieront de te vendre une supposée orthodoxie de la programmation, te vanteront l'élégance d'une méthode. Oublie-les. Leurs arguments ne doivent pas de détourner d'une seule vérité: tu dois avoir accès, avec le minimum de rugosité, à l'ensemble de tes données et aux liens qui les unissent. A toutes. Et si tu es branché sur un bon réseau, de façon quasi instantanée. Tu dois pouvoir les travailler souplement. Toute solution qui ne remplit pas ces critères doit être écartée, quels que soient les avantages qu'elle présente par ailleurs. Le prix que tu aurais à payer en temps perdu, et pire encore en biais introduits dans ta recherche, est prohibitif. Et parmi tous les instruments qui répondent à ces exigences, choisis le plus efficace selon ces critères. Le reste est littérature.

 

Jean Pierre Dedieu
CNRS / Framespa / ENS-IAO

 

1S'il est dans ce paragraphe des mots que tu ne comprends pas, suis une formation avant de passer outre dans ton projet.

2Trois de ces types ont été présentés au cours d'une journée d'étude sur les bases de données à l'Université d'Aix-en-Provence, organisée par Christian Henriot. Nous en ajoutons une quatrième pour être complet.

3Un exemple présenté par Cecile Armand aux journées d'Aix citées à la note précédente.

4Présenté à la Journée d'Aix-en-Provence citée n. 2 par Anne Kerlan

5Les universités allemandes sont confrontées au problème des grosses bases de données, entreprises dans les années 1970 avec l'aide de jeunes ingénieurs, aujourd'hui atteints l'un après l'autre par l'age de la retraite. Laissant derrière eux des bases que plus personne ne sait actionner.

6Ce point est malheureusement méconnu par la plupart des décideurs. Il me revient qu'un projet européen millionnaire, qui avait externalisé le chargement de documents médiévaux complexes auprès d'une entreprise privée, recherche maintenant des volontaires susceptibles de corriger les données chargées. Il aurait mieux valu y réfléchir avant.

7En informatisant un fichier manuel d'agents de la Monarchie espagnole au XVIIIe siècle, nous avons trouvé un nombre étonnant de ministres. Résultat d'une correction malheureuse. Les équivalents de nos ministres avaient alors titre de Secrétaire d'Etat aux…, suivait le nom de leur portefeuille. Or les secrétaire des Conseil, subordonnés chargés de la paperasse, étaient notés, en style administratif, "Secrétaire de…. ". Un secrétaire du Conseil des finances devient ainsi dans la documentation "Secrétaire des finances"; titre que pouvait porter aussi l'équivalent de notre ministre. La personne qui avait pris les notes sur lesquelles nous travaillions avait interprété prématurément.

Ce contenu a été publié dans Contribution. Vous pouvez le mettre en favoris avec ce permalien.