Les officiers des territoires angevins à la fin du Moyen Âge
Résumés
Les officiers des territoires angevins à la fin du Moyen Âge. Conception d’une base de données prosopographique
La présente contribution éclaire les enjeux et les difficultés de la mise en œuvre d’une base de données prosopographique collaborative et les solutions méthodologiques qui ont été apportées. L’acception de l’individu comme acteur de l’histoire est une voie dans laquelle les historiens se sont beaucoup investis depuis une trentaine d’années, et ces études ont montré que la prosopographie est une méthode appropriée pour cerner les contours sociologiques d’un groupe déterminé à travers les trajectoires individuelles de ses membres. C’est à la lumière de cette technique d’analyse que le corpus documentaire dont nous disposons a été, en partie, interrogé. Le programme ANR Europange (2014-2018) a permis à une équipe internationale de chercheurs de s’intéresser aux processus de rassemblements politiques à travers l’exemple de l’Europe angevine et d’une population spécifique : les officiers au service des princes angevins. Concrètement, il s’est agi de circonscrire le profil de ces hommes et de travailler sur les réseaux les liant les uns aux autres ainsi qu’aux instances du pouvoir entendu dans un sens large (princier, royal, ecclésiastique). Pour ce faire, une partie du programme a été consacrée à la conception d’une base de données prosopographique. Les propositions informatiques qui ont été trouvées se sont nourries d’une collaboration réussie entre historiens et informaticiens qui a abouti à l’application Prosopange aujourd’hui mise en ligne, avec bien d’autres ressources, sur un portail internet consacré plus largement aux études angevines. Dans cet article, nous proposons d’aborder toutes les étapes nécessaires à l’élaboration d’une base de données prosopographique en montrant le travail conjoint mené par les historiens et les informaticiens. Nous présenterons les principes fondamentaux de la modélisation d’une base de données en nous appuyant sur l’expérience acquise lors du projet Europange.
Plan
Haut de pageTexte intégral
- 1 Pour une approche synthétique de la question, voir C. Zalc, C. Lemercier, Méthodes quantitatives p (...)
- 2 Quelques titres (classés par ordre chronologique) rendent compte de tout le travail qui a été fait (...)
1La présente contribution éclaire les enjeux et les difficultés de la mise en œuvre d’une base de données prosopographique collaborative et les solutions méthodologiques qui ont été apportées. La conception d’une base de données pour les historiens ne peut se réduire à la résolution de problèmes techniques ou se limiter à de la simple recension d’informations. Elle doit s’accompagner d’un questionnement épistémologique, à toutes les étapes de sa construction, de son alimentation puis de son utilisation. Seule l’articulation fine entre la problématique de recherche, la méthode historique et la démarche technique garantit la pertinence du recours à cet outil dans l’ensemble de la démarche de recherche1. De manière générale, l’acception de l’individu comme acteur de l’histoire est une voie dans laquelle les historiens se sont beaucoup investis depuis une trentaine d’années, et ces études ont montré que la prosopographie est une méthode appropriée pour cerner les contours sociologiques d’un groupe déterminé à travers les trajectoires individuelles de ses membres. C’est donc à la lumière de cette technique d’analyse – qui consiste à compter pour tenter de dessiner un « portrait » le plus fin possible de nos officiers angevins et à éviter d’ériger un exemple en généralité – que le corpus documentaire dont nous disposons a été, en partie, interrogé2.
- 3 Partenaires du projet : laboratoire LEM-CERCOR (Saint-Étienne), laboratoire TEMOS (Angers), labora (...)
- 4 [https://angevine-europe.huma-num.fr/ea/]
2Le programme ANR Europange qui s’est déroulé entre 2014 et 2018 a permis à une équipe internationale de chercheurs de s’intéresser aux processus de rassemblements politiques à travers l’exemple de l’Europe angevine et d’une population spécifique : les officiers au service des princes angevins3. En effet, entre les xiiie et xve siècles, les maisons princières angevines sont parvenues, à différents moments de leur histoire, à gouverner divers territoires (Anjou, Maine, duchés de Bar et de Lorraine, Provence, royaume de Pologne, Albanie, royaume de Hongrie, Italie communale, royaume de Sicile, Morée), dotés de traditions administratives propres. Le programme de recherche Europange a pour objectif d’étudier les pratiques de gouvernement déployées par ces princes angevins à travers la figure de l’officier. Concrètement, il s’est agi de circonscrire le profil de ces hommes (formation, culture, fonctions occupées, vie privée…) et de travailler sur les réseaux les liant les uns aux autres ainsi qu’aux instances du pouvoir entendues dans un sens large (princier, royal, ecclésiastique). Pour ce faire, une partie du programme a été consacrée à la conception d’une base de données prosopographique en partenariat avec un laboratoire d’informatique, le LIRIS. Les propositions informatiques qui ont été trouvées se sont nourries d’une collaboration réussie entre historiens et informaticiens qui a abouti à l’application Prosopange aujourd’hui mise en ligne, avec bien d’autres ressources, sur un portail internet consacré plus largement aux études angevines4. L’application Prosopange est une suite logicielle incluant une interface de saisie collaborative et de restitution de fiches d’officiers, et une interface d’analyse de populations reposant toutes deux sur la base de données partagée.
3Dans cet article, nous proposons d’aborder toutes les étapes nécessaires à l’élaboration d’une base de données prosopographique en montrant le travail conjoint mené par les historiens et les informaticiens. Nous présenterons les principes fondamentaux de la modélisation d’une base de données en nous appuyant sur l’expérience acquise lors du projet Europange.
Définition du périmètre
4Une base de données prosopographique est centrée sur des individus. Sa finalité est le recueil d’informations caractérisant une population identifiée dans le temps et dans l’espace et la consolidation de ces informations en vue d’analyses. Une telle base de données peut être alimentée et exploitée par un chercheur ou par un collectif de chercheurs partageant le même objet d’étude. Dans le cadre du programme Europange, cet objet d’étude est l’officier angevin.
- 5 G. Dupont-Ferrier, Gallia Regia ou état des officiers royaux des bailliages et des sénéchaussées d (...)
5En premier lieu, il a donc fallu trouver une définition du terme officier qui puisse fonctionner pour l’ensemble des territoires angevins et qui nous permette de circonscrire de la façon la plus claire possible la population cible de notre étude et, in fine, de notre base de données prosopographique. Cette définition a été élaborée en tenant compte de l’importante littérature sur le sujet5. En effet, nombreux sont les historiens à s’être penchés sur cette question de la définition, qui ne va pas de soi pour le Moyen Âge, de l’officier, sachant que les travaux mobilisent également souvent des notions propres à la définition de ceux que l’on se plait à dénommer « serviteur », « familier » ou bien encore « auxiliaire ». Il y a des points communs entre ces différents protagonistes qui invitent naturellement à les mettre en relation. Finalement, dans le cadre du programme Europange, nous avons fait le choix d’appeler « officier angevin » tout individu exerçant effectivement ou nominalement des activités de gouvernement (décision) ou d’administration (exécution) et occupant une fonction déterminée, caractérisée par un titre et le plus souvent rétribuée par des gages ou émoluments, ou bien affermant une charge ou un droit, au service et au nom d’un prince appartenant aux dynasties angevines ayant régné sur les territoires et durant les périodes suivantes : comtés de Provence et de Forcalquier (1246-1481), comté puis duché d’Anjou et comté du Maine (1246-1290 et 1356-1481), Italie communale (1259-1275 et 1303-1343), royaume de Sicile (1266-1442), royaume de Hongrie ([1292] 1301-1395), royaume de Pologne (1370-1385), royaume d’Albanie (1266-1285), principauté de Morée (1267-1383), duchés de Bar et de Lorraine (1431-1508). Appréhender l’officier dans son milieu nécessite de le considérer sous différents angles. Ainsi, pour nous, un grand officier exerce plutôt ses fonctions auprès du souverain, de son lieutenant, de sa cour, de son hôtel, de sa chapelle. Un officier local ou périphérique prend place quant à lui dans le cadre d’une circonscription ou d’une localité. Si un officier sédentaire occupe une charge stable au sein d’une structure administrative et dispose le plus souvent d’un siège d’exercice et d’un ressort (sa fonction est définie par des statuts ou ce qui en tient lieu), en revanche, un officier itinérant exerce sa charge en fonction d’une lettre de commission spéciale stipulant son déplacement et sa durée, qui peut comprendre ou non un ressort géographique ou une aire d’action.
6Une fois l’objet d’étude défini, le travail des historiens a consisté à faire collectivement un recensement des données potentiellement disponibles et des objectifs en termes d’analyse, en pointant en particulier les spécificités des territoires ou de certaines périodes chronologiques, sachant que selon le degré d’avancement des travaux des chercheurs investis dans ce projet, les attentes et les besoins étaient parfois très différents. Par ailleurs, l’appréhension fine des corpus documentaires (les sources brutes) à partir desquels les chercheurs travailleraient s’est avérée cruciale pour circonscrire par la suite un certain nombre de contraintes en terme de modélisation : nature de la documentation (sources narratives, administratives, financières, notariales…), sources de première ou seconde main, actes en latin ou en langue vernaculaire, manière variée de dénommer les officiers, appréhension des différents types de juridictions, cartographie des territoires. Il est à noter qu’à l’exception de quelques sources sérielles, l’essentiel des corpus renfermait des informations non structurées dans des sources de données hétérogènes. Il a donc fallu rapidement réfléchir à la manière de sélectionner et représenter ces informations afin d’en faire des données stéréotypées prêtes à être saisies dans une base de données et susceptibles de faire l’objet par la suite d’analyses, via l’expression de requêtes, simples et complexes.
7Ces étapes ont été un passage obligé essentiel au cours duquel les historiens ont décrit les données qu’ils souhaitaient modéliser, ce qui a traduit in fine des choix de représentation de la réalité historique ainsi saisie.
Stockage de données prosopographiques
8Pour l’historien, le choix d’un outil de gestion pour les données prosopographiques va s’opérer entre tableur et base de données. Il serait faux de penser que ce choix n’est qu’un simple parti pris technologique ; il détermine de fait la façon dont les données vont être décrites et structurées et vont par là même peser sur le sens qu’on leur donne et sur les interprétations possibles.
9Les tableurs, comme Excel de Microsoft ou Calc d’OpenOffice, permettent de saisir et d’enregistrer des informations textuelles ou numériques dans des feuilles de calcul. La saisie se fait de façon libre, sans contrainte de syntaxe ou de contenu, la structure des informations se limitant au seul nommage des colonnes. L’utilisateur peut utiliser indifféremment une ou plusieurs feuilles de calcul, syntaxiquement liées ou non. Les traitements qui peuvent être réalisés sur les données consistent principalement en des mises en forme, des tris, ou des calculs réalisés sur le contenu des cellules à l’aide de formules ou de macros. Les lignes et les colonnes forment un espace ordonné sur lequel repose le système d’adressage utilisé dans les formules. Pour l’historien, le tableur est une solution rapide qui permettra une saisie de l’information en langage naturel, sans contrainte et au plus près des sources. Les contreparties de cette liberté sont la faible expressivité des modèles, la tolérance aux anomalies de saisie et les éventuelles incohérences dues à des erreurs d’adressage dans les formules. Malgré tout, les tableurs restent des outils bureautiques puissants, dont l’utilisation est relativement facile et qui sont très largement diffusés.
Les bases de données et les SGBD
10La mise en œuvre d’une base de données est bien plus complexe, plus longue et plus technique que celle d’un tableur. Elle mobilise à la fois les savoirs dans le domaine d’étude, des capacités d’abstraction et de modélisation, ainsi que des compétences techniques en informatique.
- 6 E. F. Codd, A Relational Model of Data for Large Shared Data Banks, New York, 1970.
11Les bases de données dites relationnelles représentent la très grande majorité des bases de données utilisées. Les données y sont stockées dans des « tables » respectant un certain nombre de règles et de contraintes qui ont été définies et formalisées dans les années 1970 par E. F. Codd sous le nom de « modèle relationnel »6. Dans la théorie mathématique de Codd, le terme de « relation » est employé pour désigner ce que nous appelons communément les tables, les « tuples » (ou n-uplets) désignent les lignes ou enregistrements de la table, et les « attributs » de la relation désignent les colonnes. Les attributs puisent leurs valeurs dans des « domaines » qui contraignent les saisies et les opérations de comparaison, par exemple l’ensemble des entiers, l’ensemble des caractères. Un domaine peut aussi être défini comme l’ensemble des valeurs d’un attribut d’une autre relation. Les domaines permettent alors de lier les relations entre elles : on parle de « contrainte d’intégrité référentielle ». Le modèle de Codd impose aux relations de satisfaire les propriétés suivantes :
- les relations ne contiennent pas de tuples dupliqués ;
- les tuples ne sont pas ordonnés ;
- les attributs ne sont pas ordonnés ;
- les valeurs des attributs sont atomiques (i.e. les attributs sont monovalués).
12Les concepts et propriétés des modèles relationnels ainsi définis ont pour objectifs d’imposer des normes assurant la qualité des données, d’éliminer totalement ou partiellement la redondance d’information, d’éviter les incohérences, et d’optimiser leur manipulation (saisies, requêtages et calculs). La description de l’ensemble des tables, de leurs domaines et de leurs contraintes est appelée le « schéma de la base de données ».
13Les tables créées conformément au schéma sont prises en charge par un Système de Gestion de Bases de Données (SGBD) qui assure le stockage, la consultation, la mise à jour, ou encore le partage des informations de la base de données. Une autre de ses tâches essentielles consiste à s’assurer de la qualité et de la cohérence des données en se basant sur les informations exprimées dans le schéma de la base de données. L’utilisateur interagit avec le SGBD grâce à un langage informatique appelé SQL (Structured Query Language), utilisé pour créer et structurer les tables puis pour insérer, mettre à jour, retrouver ou supprimer des données dans ces tables. SQL est un langage puissant qui permet d’exprimer toutes sortes de requêtes pour sélectionner, filtrer, croiser, dénombrer ou formater des données. La majorité des SGBD offre des outils graphiques et interactifs qui masquent la complexité syntaxique et permettent à un utilisateur novice en informatique de réaliser la plupart des tâches nécessaires.
Modèles et schéma de base de données
14En informatique, et plus particulièrement lorsqu’il s’agit de systèmes d’information, il est habituel de distinguer modèles conceptuels, modèles logiques et modèles physiques. Pour créer une base de données, il est recommandé de passer successivement par ces trois étapes de modélisation. Un modèle conceptuel, aussi appelé schéma conceptuel, est obtenu grâce à un processus d’abstraction qui vise à décomposer le problème afin d’en réduire la complexité et de simuler son comportement. Un modèle est donc une abstraction de la réalité, abstraction tout à la fois subjective et pertinente. Dans le domaine de la gestion des données, le modèle conceptuel que l’on souhaite concevoir est la représentation de l’ensemble des données mémorisables du domaine, sans tenir compte des contraintes techniques du stockage et de l’accès qui ne seront abordés que lors de l’élaboration des schémas logiques et physiques. Dans la phase conceptuelle, il s’agira d’identifier les objets d’intérêt, que l’on appelle des « entités », leurs caractéristiques ou « propriétés », et leurs liens avec d’autres entités ou « associations ». Les associations sont caractérisées à leurs deux bouts par une paire (min, max) de cardinalités représentant le nombre de fois minimum et le nombre de fois maximum où l’entité participe à l’association. Le modèle conceptuel de données est généralement exprimé grâce à un formalisme tel qu’UML ou Entité-Association. Le modèle conceptuel est ensuite dérivé en un modèle logique. Le modèle logique décrit les tables qui serviront au stockage des données et il doit se conformer aux principes du modèle relationnel. Les entités du modèle conceptuel sont traduites en tables, les propriétés en colonnes et les associations en tables et/ou en colonnes selon leurs cardinalités. C’est ce modèle que l’on appelle communément le schéma de la base de données. Enfin, le modèle logique est traduit en un modèle physique qui consiste en l’expression des tables dans le langage SQL. Ce schéma physique s’exprime sous la forme d’un script de commandes interprétables par le SGBD cible. Notons que la génération des modèles logique et physique représente des tâches automatisables, et qu’il existe des logiciels capables de dériver ces modèles directement depuis l’expression du modèle conceptuel. Ces trois modèles sont donc trois expressions différentes d’une même abstraction.
15Le modèle conceptuel de Prosopange comporte une quarantaine d’entités, le modèle logique une cinquantaine de tables. Selon l’ampleur et la complexité du projet, l’historien désirant construire une base de données prosopographique devra débuter par une modélisation conceptuelle ou, dans les cas les plus simples, écrire directement le modèle logique avant de le dériver en commandes SQL (Fig. 1).
Architectures applicatives
- 7 CMS : Content Management System, ou système de gestion de contenu ; outil destiné à la conception (...)
16Le choix de l’architecture applicative d’un projet de base de données prosopographique est fonction du niveau d’expertise en informatique du concepteur et des besoins en termes de diffusion des données. Dans le cas le plus simple, il s’agit de construire une base de données pour son usage personnel. L’architecture cible sera alors qualifiée d’« architecture 1 tiers », autrement dit ne comportant qu’un seul niveau logiciel, par exemple à l’aide d’un SGBD comme Microsoft Access ou OpenOffice Base. Si l’on souhaite partager la base de données avec des collaborateurs, comme c’est le cas dans le programme Europange, une architecture serveur s’impose. On pourra utiliser un SGBD relationnel comme Oracle, SQL server, MySQL ou Postgrès. L’accès aux données peut alors s’opérer via des applications spécifiques installées sur les postes clients (« architectures 2 tiers ») ou via des interfaces web au sein d’un simple navigateur (« architectures 3 et n tiers »). La diffusion des données et/ou leur saisie collaborative via le web a l’avantage, d’une part de s’adresser à un public plus large ou plus dispersé, et d’autre part de ne nécessiter aucune installation logicielle sur le poste client. Une interface web de saisie et de restitution simple des données pourra être presque entièrement automatisée grâce à l’usage d’un CMS7. Si des interfaces plus complexes sont requises, incluant par exemple des outils d’analyse et de visualisation avancées, alors elles nécessiteront un travail d’étude et d’ingénierie spécifique. Ainsi, dans le cadre d’Europange, nous avons conçu une architecture 3 tiers (Fig. 2), avec MySQL comme SGBD et une interface web développée spécifiquement pour la saisie, l’interrogation et l’analyse des données prosopographiques. Les interfaces web de saisie et d’analyse sont accessibles via le portail web du projet pour les utilisateurs disposant d’un compte ; la liste et le dictionnaire biographique de certains officiers sont accessibles au public [http://base.angevine-europe.huma-num.fr/prosopange].
Les étapes de la mise en œuvre
Expression des besoins
17Pour un historien, la conception d’une base de données prosopographique a pour objectif de constituer des fiches individuelles regroupant le plus d’informations possible sur chaque individu. Le recueil des informations peut être individuel ou collaboratif. L’exploitation des données peut prendre différentes formes : la constitution d’un dictionnaire regroupant des fiches biographiques, la diffusion des informations via un portail web, l’analyse et l’étude statistique des données. Il est évident que les objectifs d’exploitation de la base de données ont des conséquences sur l’architecture applicative déployée. En génie logiciel, l’étape d’expression des besoins distingue les besoins fonctionnels (que doit faire l’application, vue par l’utilisateur ?) et les besoins non fonctionnels (quelles sont les contraintes, les exigences ou choix techniques ?) et aboutit à un cahier des charges spécifiant les besoins fonctionnels et non fonctionnels en décrivant les cas d’utilisation. Pour la conception d’une base de données prosopographique, il s’agit donc, dans un premier temps, d’identifier l’objet d’étude et son périmètre, à savoir quelle est la population étudiée (dans notre cas, il s’agit des officiers angevins) et quelles sont les limites temporelles et spatiales d’intérêt (les xiiie-xve siècles, l’espace angevin qui s’apparente à un agrégat de territoires répartis globalement à l’échelle de l’Europe). Il faut ensuite déterminer ce qui permet de caractériser la population étudiée et les besoins d’information pour l’étude à mener et des sources de données disponibles.
18Dès le début du projet, les historiens ont formulé des besoins d’analyse qui par la suite ont évolué et se sont affinés, au gré notamment des discussions nourries qu’ils ont eues avec les informaticiens qui ont su, d’un point de vue technique, ouvrir le champ des possibles en termes de requêtes et d’analyses. Ces analyses autocentrées sur les officiers devaient permettre d’étudier leur carrière (en tant que telle mais également dans une optique de comparaison), leurs liens familiaux, les réseaux dans lesquels ils évoluaient, ou encore l’existence de liens de subordination entre officiers mais également avec le pouvoir auprès duquel ils étaient investis. La définition de ces besoins d’analyse nécessitait aussi de s’interroger sur la modélisation la plus pertinente des résultats : tableaux, graphiques, cartes, généalogies… De longues phases de test ont été utiles afin d’arrêter la base de données telle qu’elle existe aujourd’hui, ainsi que les modèles de représentation qui convenaient le mieux à l’équipe de chercheurs.
Le recueil des données
19Le recueil de données ne pose pas en soi de difficultés particulières ; c’est la tâche quotidienne de l’historien qui décide d’engager une recherche. En revanche, la mise en commun de ces données ainsi que leur modélisation ont nécessité de la part des chercheurs qu’ils s’accordent entre eux pour choisir et définir des concepts, du vocabulaire, des cadres dans lesquels les officiers puissent être décrits, qu’ils soient angevins, lorrains, provençaux, italiens, hongrois ou moréotes ; en somme un environnement qui leur soit a minima globalement commun. Cela a constitué le premier défi de taille à relever. En effet, les espaces d’étude ne partagent pas forcément la même langue (pour l’essentiel le latin et l’ancien français, mais également le grec) et encore moins les mêmes traditions institutionnelles.
20La diversité des sources est telle qu’il n’est pas envisageable d’en dresser une liste exhaustive. Il est toutefois possible de dire que, selon les espaces géographiques et la chronologie, les chercheurs ont tantôt dépouillé des sources primaires (chroniques, chartes, ordonnances, archives administratives, judiciaires, comptabilités, mémoires…), tantôt des sources de seconde main, à savoir, pour l’essentiel, des travaux réalisés par les érudits d’Ancien Régime, du xixe siècle, voire plus récents.
- 8 G.-L. Borghese, « Les registres de la chancellerie angevine de Naples. Un exemple de destruction e (...)
- 9 Voir les bibliographies consacrées aux différents territoires angevins présentes sur le site consa (...)
21Il y a aussi parfois des situations documentaires particulièrement singulières avec lesquelles les chercheurs doivent composer. Les historiens travaillant sur le royaume de Naples doivent, par exemple, s’accommoder d’un fonds documentaire très riche – les registres de la Chancellerie angevine – qui a été presque entièrement détruit durant la seconde Guerre Mondiale, mais patiemment reconstitué par la suite8. L’utilisation d’un tel fonds nécessite, de fait, quelques précautions. Europange a permis de faire converger et de structurer dans un projet collectif des travaux portant sur les officiers restés jusqu’alors isolés. En somme, avant même la naissance de la base de données prosopographique, de nombreuses sources avaient déjà été minutieusement dépouillées, analysées et fait l’objet de publications. Citons à titre d’exemples les travaux de Serena Morelli sur les giustizieri du royaume de Sicile au temps de Charles Ier et Charles II d’Anjou, ceux de Riccardo Rao sur les officiers de l’Italie du Nord, ceux de Jean-Luc Bonnaud et Thierry Pécout sur les officiers provençaux aux xiiie-xive siècles, ceux d’Enikő Csukovits sur le personnel du royaume de Hongrie ou ceux d’Isabelle Ortega sur les officiers angevins dans la Morée latine9.
- 10 J. Moreno, « Les officiers de la Chambre des comptes d’Angers (1397-1424). Étude prosopographique (...)
- 11 C.-J. Beautemps-Baupré, Coutumes et institutions de l’Anjou et du Maine antérieures au xvie siècle(...)
22Le programme de recherche Europange a également permis d’engager des travaux tout à fait neufs sur le sujet. En effet, grâce au financement de la numérisation des registres de la Chambre des comptes d’Anjou conservés aux Archives nationales à Paris, Justine Moreno a pu engager une recherche doctorale qui a pour ambition de livrer une étude prosopographique du personnel de cette institution ayant servi les ducs d’Anjou à la fin du Moyen Âge10. Ce travail permet de revisiter et de compléter de manière précise les premiers travaux qui avaient été produits au xixe siècle, par exemple, par Charles-Jean Beautemps-Baupré et Albert Lecoy de La Marche11.
23Si les historiens avaient dès le départ une idée précise des données à collecter, ils ont également tous évoqué le souhait de prévoir un espace au sein de la base de données qui offre la possibilité d’insérer des commentaires de façon totalement libre. Ce champ permet ainsi d’inscrire toute information dont on pense qu’elle peut apporter matière à enrichir les analyses qualitatives portant sur les officiers.
La conception des modèles de données
24La conception d’un modèle de données est souvent un travail long et complexe, mais il est fondamental dans la réussite du projet. C’est une réflexion qui ne nécessite aucun outil informatique et qui est tout à fait indépendante de la technologie qui sera utilisée par la suite pour la mise en œuvre. Grâce au modèle de données, on peut identifier et décrire les tables nécessaires au stockage des informations.
- 12 Se reporter à J. Bradley, H. Short, Texts into databases : The Evolving Field of Newstyle Prosopog (...)
- 13 Dans le cas d’officiers juifs ou musulmans.
25Les objets d’étude centraux d’un modèle conceptuel de données prosopographiques sont bien sûr les individus. Les objets qui leur sont liés modélisent des événements, des lieux, des dates, etc. Certains auteurs préconisent une approche dite « factoïde » afin de représenter au mieux la dimension narrative des données prosopographiques12. Dans cette approche, les seules entités modélisées sont les sources, les faits et les sujets, toute information étant alors exprimée sous la forme « la source S croit que le fait F peut être énoncé à propos de la personne P ». Cette solution a pour avantage d’être indépendante du domaine étudié. Dans le programme Europange, nous adoptons une solution plus classique, qui consiste à définir un modèle spécifique à notre sujet d’étude, les officiers angevins, et nous gagnons ainsi en expressivité ce que nous perdons en généricité. L’entité principale est l’« officier ». Son identité est définie par son « nom de baptême (ou équivalent13) » et éventuellement par plusieurs « noms » de différents types, patronyme, nom historiographique, alias... Il a une « confession », un « lieu d’origine »… Il obtient des « grades universitaires » et noue des « relations » avec son entourage… Sa carrière est composée de « charges » qui ont des « lieux d’exercice », des « dates de nomination »… Lors de cette phase de modélisation, il conviendra de réfléchir aux cardinalités des associations entre entités. Par exemple, un nom de baptême est-il exigé (cardinalité min=1) ? Peut-on saisir plusieurs noms pour un officier (cardinalité max=n) ? Peut-on ne pas saisir de nom (cardinalité min=0) ?
26Au-delà de l’identification des entités principales, il est difficile pour l’historien de dissocier la sélection des informations à stocker et le recueil des données issues des sources. En effet, le modèle de données doit décrire une réalité qui est souvent à découvrir dans le travail d’étude des sources. Les historiens se sont donc attachés à définir un cahier des charges permettant de structurer les données à saisir. Il a fallu réfléchir précisément aux notions de charge, d’office, de fonction afin d’établir des champs clairs pour qu’il n’y ait pas de confusion au moment de la saisie collaborative des informations, puis dans un second temps, du traitement et de la modélisation des données.
La saisie des informations dans la base de données
27La saisie des données s’effectue traditionnellement au sein d’un ou plusieurs écrans se présentant sous forme de formulaires. Certains SGBD comme Access de Microsoft ou Base d’OpenOffice proposent des assistants permettant d’automatiser la production des écrans de saisie les plus simples. La conception de ces formulaires doit, d’une part, faciliter le travail de saisie, et, d’autre part, diminuer le risque d’erreurs. Pour ce faire, des contrôles sont programmés dans l’interface et les saisies de texte libre sont limitées autant que possible. Ainsi, les données de référentiels sont présentées sous la forme de cases à cocher ou de listes déroulantes qui permettront à l’historien de sélectionner sa donnée plutôt que la saisir (Fig. 3). En plus de toutes les précautions prises dans les écrans pour éviter les erreurs de saisie, rappelons qu’en bout de processus, toute insertion ou modification de données violant les contraintes définies dans le schéma de la base sera rejetée par le SGBD.
Fig. 3. Liste déroulante pour la saisie de la confession et cases à cocher pour la saisie de la charge

Exploitation de la base
- 14 A. Tchounikine, M. Miquel, T. Pécout, J.-L. Bonnaud, « Prosopographical Data Analysis. Application (...)
28Les potentialités d’exploitation de la base prosopographique sont innombrables. Naturellement, il est possible de retrouver de façon très simple et rapide toutes les informations concernant un individu grâce au langage d’interrogation SQL. On peut tout aussi facilement procéder à des comptages ou des calculs statistiques. SQL permet aussi de constituer des populations en sélectionnant des individus à l’aide de requêtes multicritères (par période, par type de charge, par confession, etc.) ; des tris et regroupements multicritères peuvent aussi être appliqués (tri alphabétique, chronologique, tri par nombre de charges, regroupement géographique, etc.). Les résultats de ces requêtes peuvent être visualisés dans le SGBD, dans des interfaces dédiées ou sous forme documentaire. Moyennant l’utilisation d’outils complémentaires, on peut réaliser des cartes, construire des réseaux, déduire des motifs fréquents, générer des classifications ou découvrir des données d’exceptions14.
Conception du schéma de la base de données
29Nous souhaitons revenir ici sur l’étape cruciale de la modélisation des données prosopographiques. Rappelons qu’une base de données est un ensemble de tables, elles-mêmes constituées d’un ensemble de colonnes (nommés aussi « attributs », « champs » ou « propriétés »). Les colonnes servent à enregistrer les valeurs des propriétés descriptives des entités identifiées lors de l’analyse des besoins et de la modélisation conceptuelle. La description de l’ensemble des tables et des colonnes s’appelle le schéma de la base de données, et peut être déduit automatiquement du schéma conceptuel des données. Nous allons voir comment les règles du modèle relationnel et les contraintes imposées par l’usage d’un SGBD permettent d’améliorer la qualité syntaxique et l’usage des données de l’historien sur des exemples simplifiés des données de la base Prosopange.
Typage des colonnes
- 15 Variable à deux états, « vrai » ou « faux ».
30Lors de la définition d’une table, il est indispensable de déclarer et de typer les colonnes qui la constituent, autrement dit d’identifier le domaine des attributs de la relation. Les types les plus utilisés sont les valeurs numériques (entier, réel…), les chaînes de caractères ou texte court, les dates, les booléens15, et, dans une moindre mesure, le texte long (CLOB), les images, son ou vidéo (BLOB). Chaque table doit définir une colonne particulière permettant de stocker une valeur, généralement de type entier, qui identifie sans ambigüité les tuples. Ce numéro est très important, il est appelé « clé primaire » et est généralement calculé par incrément et attribué automatiquement par le SGBD. Dans une table, les colonnes peuvent être qualifiées de différentes manières : obligatoire, optionnelle, unique. On peut aussi leur affecter une valeur par défaut. La clé primaire est obligatoire et unique. Toute donnée insérée dans la base ne répondant pas à ces contraintes déclaratives ou à la contrainte de type générera une erreur et sera rejetée par le SGBD. Il sera donc impossible pour l’utilisateur, par exemple, de saisir du texte dans une colonne « année » si elle a été déclarée comme une date, ou de saisir plusieurs fois un même intitulé s’il a été déclaré comme unique, ou bien encore de ne rien saisir dans la colonne « nom de baptême » si elle a été déclarée obligatoire. On peut percevoir dès à présent comment le typage des colonnes et les contraintes exprimées sur ces colonnes fournissent une première façon de contrôler les erreurs de saisie et contribuent à une solution pour s’assurer de l’intégrité des données stockées dans la base.
La normalisation et les données multivaluées
31Considérons qu’un officier est décrit par son « nom de baptême (ou équivalent) », plusieurs noms, sa confession religieuse, plusieurs grades universitaires. Si nous utilisons un tableur pour stocker ces données, nous allons évidement multiplier les colonnes pour enregistrer les informations multivaluées comme illustré dans la figure 4. Les cellules vides peuvent ici signifier soit que l’information est manquante (aucune source ne mentionne le nom de Isnardus en ligne 3), soit qu’elle est vide (Patappi en ligne 5 n’a pas de grade universitaire).
32On voit bien que prévoir une colonne Nom 1, Nom 2, Nom 3, Grade 1, puis Grade 2, puis Grade 3, etc., mène à une impasse : quand s’arrête-t-on ? Comment faire cohabiter au sein de la même table l’officier ayant eu un seul grade et celui qui en a dix ? La numérotation utilisée dans le titre des colonnes entend-elle exprimer une succession chronologique ? Sinon, quel est son sens ? Comment faire si l’on décide d’enregistrer la date d’obtention des grades ? Va-t-on ajouter une colonne dateGrade1, puis dateGrade2, etc. ? Enfin comment maîtriser les conséquences d’une simple faute de frappe (par exemple « bachelier » à la ligne 4) ou d’une traduction (« doctor » ligne 2 et « docteur » ligne 4) lors des comptages, des tris ou des filtres ?
- 16 « Once we make the decision not to normalize, we’ve embarked on a very slippery slope. […] In choo (...)
33L’application du principe de normalisation, au cœur de la théorie relationnelle, apporte une solution à ces problèmes. La normalisation évite les répétitions, interdit de dupliquer des colonnes pour saisir des données multivaluées, et par là même prévient les anomalies de lecture, les anomalies d’écriture et la contre-performance. La théorie relationnelle définit plusieurs niveaux de normalisation (première forme normale, deuxième forme normale… jusqu’à cinquième forme normale, forme normale de Boyce-Codd…). Par abus de langage, on appelle souvent « modèle normalisé » un modèle qui est en réalité en troisième forme normale. Seuls les modèles normalisés permettent d’assurer les propriétés d’intégrité et de cohérence des données. C’est pourquoi la phase de normalisation est si importante16.
- 17 Ce n’est pas tout à fait vrai : un nom peut bien sûr être porté par plusieurs officiers. Nous choi (...)
34L’application du principe de normalisation sur l’exemple des officiers nous amène à créer différentes tables pour enregistrer les noms, titres universitaires ou intitulés de charge, puis à relier ces informations entre elles grâce à leur clé. Ainsi, dans la figure 5, la table OFFICIER ne contient que les propriétés atomiques et non redondantes, soit la clé primaire (obligatoire et par convention nommée « _id ») et le nom de baptême. Les tables NOM, CONFESSION et GRADE listent les différentes valeurs possibles pour les noms, les confessions et les grades universitaires des officiers. Le lien entre les officiers et leurs noms se fait simplement en reportant les valeurs de clés primaires des officiers dans la colonne « officier_id » dans la table NOM. Cette colonne est appelée « clé étrangère ». Nous retrouvons ici la notion de domaine de la théorie relationnelle : la colonne « officier_id » de la table NOM a pour domaine le contenu de la colonne « officier_id » de la table OFFICIER. La table OFFICIER-GRADE et ses colonnes de clés étrangères « officier_id » et « grade_id » permettent de lier les officiers à leurs différents grades universitaires. Ces deux solutions correspondent à deux situations différentes : (a) un officier peut avoir plusieurs noms, un nom appartient à un seul officier, qui traduit une association de cardinalité (1-n) entre officiers et noms17 ; (b) un officier peut avoir plusieurs grades, un grade peut qualifier plusieurs officiers, c’est une association (n-n). La table CONFESSION est créée de façon à éliminer la redondance des libellés « chrétien grec » et « chrétien latin » et traduit une association (n-1) entre officiers et confessions. La création de la table OFFICIER-GRADE nous permet en outre d’ajouter des informations temporelles sur l’obtention des grades universitaires (colonne « date ») ; la table NOM, des informations pour qualifier la sémantique du nom (colonne « type ») ; la table GRADE, un support multilingue aux intitulés utilisés (colonnes « nom latin » et « nom fr »).
35Pour reconstituer l’information sur un officier, il suffit maintenant de suivre le chemin tracé par les clés étrangères et les clés primaires : ainsi, Emericus est l’officier portant le numéro 1 (sa clé primaire, en gras) ; nous le retrouvons deux fois dans la colonne de clé étrangère « officier_id » de la table NOM, ce qui nous permet de retrouver son patronyme « Bubeek » et son nom historiographique « Bebek ». La colonne « officier_id » de la table OFFICIER_GRADE nous fournit, dans la colonne « grade_id », les clés (en gris) et les dates de ses deux titres universitaires, dont nous pouvons trouver les libellés en latin et en français dans la table GRADE. Sa confession est « chrétien latin » (en gris*).
36Il résulte de cette modélisation qu’il n’y a plus de limite théorique au nombre de noms ou de grades que l’on souhaite saisir pour un officier. Nous nous sommes aussi assurés que les intitulés des grades universitaires et des confessions pouvaient être réutilisés pour qualifier différents officiers, sans risque d’erreur de saisie.
Tables ou colonnes
37Le choix de stocker une information dans une colonne, ou dans plusieurs colonnes, ou bien encore dans une table est loin d’être trivial et les conséquences sont importantes. Prenons par exemple l’information représentant les sources manuscrites du corpus documentaire. Cette information peut être stockée tout simplement dans une colonne de type texte de la table où est enregistrée la donnée qu’elle a permis de saisir, ici les noms des officiers, entraînant éventuellement la répétition de la référence comme on peut le voir en gras et en gris dans la figure 6.
38On peut aussi choisir de stocker les sources dans une table à part, évitant ainsi les fautes typographiques ou la variabilité des mises en forme constatées dans la première solution. Dans cette solution, illustrée par la figure 7, la colonne « source_id » de la table NOM référence la clé primaire « source_id » de la table SOURCE et permet de relier chaque ligne stockant un officier à une ligne stockant sa source.
39On peut enfin adopter une troisième solution, illustrée par la figure 8, qui détaille la représentation des sources et améliore leur gestion en autorisant un certain nombre de traitements sur les colonnes de la table SOURCE (typage des colonnes, tris, contrôle de saisie des différentes colonnes…), la mise en forme de la référence étant entièrement déléguée à l’outil utilisé pour l’IHM.
40Dans cette solution, la colonne « 2de main » peut être utilisée pour qualifier la qualité des informations liées à cette source. On pourra bien sûr ajouter une colonne source dans toutes les tables dont on souhaite tracer l’origine de l’information, par exemple dans la table OFFICIER-GRADE. On voit bien ici que ces solutions sont de plus en plus complexes à mettre en œuvre, elles demandent de plus en plus de tables, de colonnes dans ces tables, elles sont de moins en moins « naturellement » lisibles. En contrepartie, elles gagnent en efficacité : on ne duplique plus les données, on évite les erreurs, on contrôle les saisies et on permet les calculs. C’est le SGBD, à travers le langage de requête, qui sera chargé de reconstituer l’information en suivant les liens constitués par les clés primaires.
Données incomplètes et données imprécises
41L’information recueillie dans les sources est souvent imparfaite : une date peut être entièrement renseignée (jour, mois, année) ou pas (on ne connaît par exemple que l’année) ; la source peut indiquer avec précision le lieu d’exercice d’une charge, par exemple en mentionnant la localité, ou bien n’indiquer que le royaume ou la principauté. Dans le premier cas, celui de la date, nous sommes confrontés à une donnée incomplète ; dans le deuxième cas, il s’agit d’une information, le lieu, qui peut être renseignée par des données de précisions différentes.
42Pour pouvoir stocker une donnée incomplète, il faudra déclarer certaines colonnes « non obligatoires ». Ainsi, comme dans la figure 9, on pourra préférer stocker une date dans trois colonnes plutôt que dans une seule, aucune des trois colonnes n’étant obligatoire. À ces colonnes, on pourra en ajouter une quatrième pour saisir un élément de positionnement temporel (ante, post, circa…). L’utilisateur pourra saisir à sa guise tout ou partie de la date.
43Dans la base Prosopange, nous avons ajouté au stockage des dates deux colonnes évaluées automatiquement par des algorithmes calculant les bornes inférieure et supérieure de la date saisie, nous permettant de réaliser ensuite des tris chronologiques et autres opérations temporelles.
44Le problème de la précision variable de l’information peut être résolu informatiquement grâce au concept d’héritage. L’héritage permet d’exprimer un lien de généralisation ou de spécialisation entre deux données. Une donnée spécialisée (ou « fille ») héritera alors des caractéristiques de sa donnée générique (ou « mère »). Lorsque l’on manipule une donnée, on peut l’envisager sous l’une de ses deux facettes, en tant que donnée générique ou en tant que donnée spécifique. On se permet alors de raisonner à des niveaux d’abstraction différents selon les besoins. Le modèle relationnel ne supporte pas nativement la notion d’héritage, mais il peut cependant être simulé assez facilement. Ainsi, dans le modèle conçu pour Prosopange, nous avons défini une table LIEU, dont héritent les tables LOCALITE, SUBDIVISION et ESPACE POLITIQUE illustrées dans la figure 10. Toute information associée à une localisation (origine de l’officier, lieux d’habitation, affectation de la charge, lieux d’action…) est reliée à une table générique LIEU qui spécifie dans la colonne « type » le niveau de détail exprimé. Les tables spécifiques fournissent ensuite les propriétés particulières sur ce lieu, au niveau où ils existent.
45Les données ainsi modélisées permettent d’exprimer que l’officier Isnardus est originaire d’Aix-en-Provence, dans la viguerie d’Aix située dans les comtés de Provence et de Forcalquier ; Emericus Bubeek est originaire du royaume de Hongrie, sans plus de détail ; Petrus Abello est originaire de la Viguerie d’Aix, dans les comtés de Provence et de Forcalquier.
46L’héritage peut aussi être utilisé pour modéliser les relations interpersonnelles entre individus (liens familiaux, liens hiérarchiques…). En effet, des liens peuvent unir des officiers entre eux, mais aussi des officiers avec des souverains, ce que rend possible l’héritage illustré ci-dessous dans la figure 11. Officiers et souverains sont définis comme des entités filles de l’entité Individu et les liens de la table INDIVIDU_RELATION sont modélisés entre individus quel que soit leur type. Enfin, les différents types de sources (manuscrits, articles…) pourront avantageusement être modélisés avec de l’héritage.
Traçabilité, données incertaines et données inattendues
47Dans la Figure 8, nous avons vu comment rattacher la donnée portant sur le nom d’un officier à la source dans laquelle l’historien a trouvé cette information. Il est important de généraliser ce principe à l’ensemble des données de la base prosopographique et de prévoir systématiquement une colonne dans toutes les tables permettant de la lier à la source. En plus de cette colonne destinée à la traçabilité de l’information, on pourra ajouter une colonne pour qualifier la qualité de la donnée. Dans le cas le plus simple, il suffira d’ajouter une variable booléenne permettant de savoir si la donnée est sûre ou déduite, mais on peut aussi imaginer d’autres qualificatifs s’il en est besoin. Enfin, il est important de toujours prévoir une ou plusieurs colonnes supplémentaires permettant une saisie libre. Cela offre la possibilité aux chercheurs d’enregistrer toute information imprévue ou atypique dont le sens ou l’utilité n’est peut-être pas immédiat, mais peut s’avérer intéressant et permettre d’envisager d’étendre notre base de données. En effet, rien n’empêche de penser que notre base de données initiale ne puisse pas connaître des extensions/développements permettant de traiter de nouveaux pans des vies et des carrières des officiers étudiés.
Synthèse sur le modèle de la base de données
48Cet exemple montre comment une conception judicieuse d’un schéma de base de données permet de traduire la complexité des données en assurant au mieux la qualité et la cohérence de l’information et en facilitant les traitements à venir. La relative simplicité de l’exemple nous a permis de construire le schéma directement à partir des besoins exprimés, sans passer par l’étape d’abstraction. Dans un cas plus complexe, cette étape ne peut être évitée et doit aboutir à la définition d’un modèle conceptuel des données, exprimé par exemple en UML (Fig. 12), duquel sera dérivé le schéma de la base de données. La production d’un schéma relationnel normalisé dépendra de la qualité du modèle conceptuel.
49Rappelons cependant qu’un modèle conceptuel est une vue subjective des données souvent griffonnée à la main dans un premier temps (Fig. 12). Il ne représente que ce que le concepteur souhaite retenir de la réalité dans un contexte et un objectif particuliers. On ne peut prétendre « modéliser entièrement et parfaitement les officiers angevins du Moyen Âge » car chaque choix d’entité, d’association ou de cardinalité est discutable et peut-être remis en question.
*
50En dépit de toutes les possibilités qu’elle offre, la base de données ne saurait tenir lieu de support unique à une analyse. Il s’agit d’un outil parmi d’autres dont dispose l’historien, sachant que celui-ci devra, autant que faire se peut, croiser les différentes sources d’information. Il s’agit néanmoins d’un outil très efficace pour représenter des informations, vérifier ou faire émerger des hypothèses, clarifier des pistes de recherche, voire répondre à des questions précises. Mais cet outil doit être systématiquement accompagné en amont et en aval d’une réflexion et d’un questionnement qui seuls permettent de bâtir une vraie démonstration (il faut justifier la démarche, les choix, les classements...). De temps en temps, il faut aussi savoir laisser de côté les tris et les comptages pour descendre au niveau des réalités individuelles.
51Enfin, il ne faut jamais perdre de vue qu’en histoire, et plus largement en sciences humaines, la conceptualisation comme la modélisation de nos objets d’étude émergent rarement du premier coup. Les bases de données n’échappent pas à la règle. Nous l’avons vu, il existe plusieurs possibilités pour décrire la réalité et sa complexité. Il faut accepter de tâtonner, faire plusieurs essais, mais c’est au prix de ces tentatives que l’on parvient le plus souvent à comprendre en profondeur son corpus documentaire et la réalité historique que l’on souhaite saisir. Dans le cadre du programme Europange, cette phase a permis de nourrir des échanges collectifs très intéressants, de confronter différentes histoires de ces territoires angevins, avec leurs particularités, leurs silences et leurs incertitudes. En fin de compte, cela a été l’occasion de donner vie à une recherche promise, nous l’espérons, à un bel avenir.
Notes
1 Pour une approche synthétique de la question, voir C. Zalc, C. Lemercier, Méthodes quantitatives pour l’historien, Paris, 2008. Michel Cassan constate, à propos de la prosopographie, qu’il s’agit « d’un outil méthodologique éprouvé. Sa valeur heuristique demeure et les remarques critiques formulées à l’égard de certaines manipulations qu’elle a subies, sont de nature à enrichir et affiner son usage » (M. Cassan, Les Officiers « moyens » à l’époque moderne : pouvoir, culture, identité, Actes du colloque organisé par l’équipe de recherches « Territoires et Sociétés » de l’Université de Limoges, le CESURB de l’Université Michel de Montaigne Bordeaux III et le Centre de recherches de l’Histoire du Monde atlantique de l’Université de Nantes, Limoges, 11-12 avril 1997, Limoges, 1998, p. ix.
2 Quelques titres (classés par ordre chronologique) rendent compte de tout le travail qui a été fait en la matière : J. Bartier, Légistes et gens de finances au xve siècle. Les conseillers des ducs de Bourgogne Philippe le Bon et Charles le Téméraire, Bruxelles, 1955 ; B. Guenée, Tribunaux et gens de justice dans le bailliage de Senlis à la fin du Moyen Âge (vers 1380-vers 1550), Strasbourg, 1963 ; R. Fédou, Les Hommes de loi lyonnais à la fin du Moyen Âge. Étude sur les origines de la classe de robe, Paris, 1964 ; F. Autrand, « Offices et officiers royaux en France sous Charles VI », Revue historique, 242 (1969), p. 285-338 ; J.-R. Strayer, Les Gens de justice du Languedoc sous Philippe le Bel, Toulouse, 1970 ; C. Charle, J. Nagle, M. Perrichet, M. Richard, D. Woronoff éd., Pour une prosopographie des élites françaises. xvie-xxe siècles. Guide de recherches, Paris, 1980 ; B. Guenée « Catalogue des gens de justice de Senlis et de leurs familles (1380-1550) », Comptes rendus et mémoires de la Société d’histoire et d’archéologie de Senlis, 1979-1980, p. 20-84, et 1981-1982, p. 3-96 ; H. Millet éd., Informatique et prosopographie, Paris, 1985 ; F Autrand éd., Prosopographie et genèse de l’État moderne. Actes de la table ronde organisée par le CNRS et l’ENS, Paris, 22-23 octobre 1984, Paris, 1986 ; J. Verger, « Prosopographie et cursus universitaires », dans N. Bulst et J.-P. Genet éd., Medieval Lives and the Historian. Studies in Medieval Prosopography, Kalamazoo, 1986, p. 313-332 ; J. Kerhervé, L’État breton aux xive et xve siècles. Les ducs, l’argent et les hommes, 2 vol., Paris, 1987 ; J. Verger, « Peut-on faire une prosopographie des professeurs des universités françaises à la fin du Moyen Âge ? », Mélanges de l’École française de Rome. Moyen Âge, 100 (1988), p. 55-62 ; P. Maurice, « Les officiers royaux du bailliage de Marvejols à la fin du Moyen Âge », Revue historique, 582 (1992), p. 283-309 ; N. Bulst, « Objet et méthode de la prosopographie », dans J.-P. Genet et G. Lottes éd. L’État moderne et les élites, xiiie-xviiie siècles. Apports et limites de la méthode prosopographique, Paris, 1996, p. 367-482 ; C. Gauvard, « La prosopographie des criminels en France à la fin du Moyen Âge : méthode et résultats », ibid., p. 445-452 ; J. Verger, « Prosopographie des élites et montée des gradués : l’apport de la documentation universitaire médiévale », ibid., p. 363-372 ; J.-P. Dedieu, « Une approche “fine” de la prosopographie », dans R. Descimon, J. F. Schaub, B. Vincent éd., Les Figures de l’administrateur. Institutions, réseaux, pouvoirs en Espagne, en France et au Portugal xvie-xixe siècles, Paris, 1997, p. 235-242 ; M. Cassan éd., Les Officiers « moyens » à l’époque moderne … ; Id., Offices et officiers « moyens » en France à l’époque moderne. Profession, culture, Limoges, 2004 ; B. Bober, Exercer le fait de la justice : les officiers de justice au travail dans la sénéchaussée de Toulouse à la fin du Moyen Âge, thèse d’histoire médiévale, École Nationale Supérieure des Sciences de l’Information et des Bibliothèques, 2005 ; C. Dolan éd., Entre justice et justiciables. Les auxiliaires de la justice du Moyen Âge au xxe siècle, Québec, 2005 ; S. Hamel, La Justice d’une ville : Saint-Quentin au Moyen Âge, thèse d’histoire médiévale, Université Paris I-Panthéon-Sorbonne, 2005 ; R. Telliez, « Per potentiam officii ». Les officiers devant la justice dans le royaume de France au xive siècle, Paris, 2005 ; P. Soleilhavoup éd., Gens de robe et gibier de potence en France du Moyen Âge à nos jours. Actes du colloque d’Aix-en-Provence (14-16 octobre 2004), Marseille, 2007 ; P. Prétou, Justice et société en Gascogne à la fin du Moyen Âge, Rennes, 2010 ; I. Mathieu, Les Justices seigneuriales en Anjou et dans le Maine à la fin du Moyen Âge : institutions, acteurs et pratiques, Rennes, 2011. La prosopographie continue d’intéresser, puisqu’en 2018-2019 un séminaire du LAMOP a eu pour thème « La prosopographie : objets et méthode ». À cette occasion, la base de données prosopographique consacrée aux officiers angevins a d’ailleurs été présentée par Thierry Pécout, porteur du projet Europange [cf. son étude « Les enquêtes générales en Provence angevine (1297-1299 et 1331-1334). De la liste à la carte » dans ce numéro de Médiévales].
3 Partenaires du projet : laboratoire LEM-CERCOR (Saint-Étienne), laboratoire TEMOS (Angers), laboratoire TELEMME (Aix-en-Provence), laboratoire CEMMM (Nîmes), laboratoire LIRIS (Lyon), École française de Rome (Italie), Centre de Recherches en Sciences Humaines de l’Académie des Sciences de Hongrie (Hongrie), Université della Campania Luigi Vanvitelli (Italie), Université de Salerne (Italie), Université de Bergame (Italie), Université de Moncton (Canada).
4 [https://angevine-europe.huma-num.fr/ea/]
5 G. Dupont-Ferrier, Gallia Regia ou état des officiers royaux des bailliages et des sénéchaussées de 1328 à 1515, Paris, 1954 ; F. Autrand, « Offices et officiers royaux en France sous Charles VI », Revue historique, 242 (1969), p. 285-338 ; G. Dupont-Ferrier, Les Officiers royaux des bailliages et sénéchaussées et les institutions monarchiques locales en France à la fin du Moyen Âge, Genève, 1974 ; M Pinet éd., Histoire de la fonction publique en France. Tome 1 : Des origines au xve siècle, Paris, 1993 ; M. Cassan éd., Les Officiers « moyens » à l’époque moderne : pouvoir, culture, identité, Actes du colloque de Limoges, 11-12 avril 1997, Limoges, 1998 ; F. Olivier-Martin, Histoire du droit français, des origines à la Révolution, Paris, 1998 ; Les Serviteurs de l’État au Moyen Âge, Actes du 29e congrès de la Société des historiens médiévistes de l’enseignement supérieur public (Pau, mai 1998), Paris, 1999 ; Officiers « moyens » (I). Actes de la table ronde organisée les 28 et 29 mai 1999 à Paris par C. Blanquie, M. Cassan, R. Descimon, Cahiers du Centre de recherches historiques-EHESS, Paris, 23 (1999), en ligne [https://journals.openedition.org/ccrh/2122] ; Officiers « moyens » (II). Officiers royaux et officiers seigneuriaux. Actes de la table ronde organisée les 16 et 17 mars 2001 à Paris par C. Blanquie, M. Cassan, R. Descimon, Cahiers du Centre de Recherches historiques-EHESS, Paris, 27 (2001) ; R. Robaye éd., Les Acteurs de la justice. Magistrats, ministère public, avocats, huissiers et greffiers (xiie-xixe siècle), Namur, 2002 ; M. Cassan, Offices et officiers « moyens » en France… ; É. Gonzales, Un prince en son hôtel. Les serviteurs des ducs d’Orléans au xve siècle, Paris, 2004 ; A. Beauchamp éd., Les Entourages princiers à la fin du Moyen Âge, Madrid, 2013.
6 E. F. Codd, A Relational Model of Data for Large Shared Data Banks, New York, 1970.
7 CMS : Content Management System, ou système de gestion de contenu ; outil destiné à la conception et au développement de sites web utilisant une base de données.
8 G.-L. Borghese, « Les registres de la chancellerie angevine de Naples. Un exemple de destruction et reconstruction de sources archivistiques à travers les siècles », Médiévales, 69 (2015), p. 171-182.
9 Voir les bibliographies consacrées aux différents territoires angevins présentes sur le site consacré au projet Europange et à la base de données Prosopange : [https://angevine-europe.huma-num.fr/ea/fr/l-europe-angevine].
10 J. Moreno, « Les officiers de la Chambre des comptes d’Angers (1397-1424). Étude prosopographique d’après le premier “Journal” de l’institution », Annales de Bretagne et des pays de l’Ouest, 123/1 (2016), p. 55-84.
11 C.-J. Beautemps-Baupré, Coutumes et institutions de l’Anjou et du Maine antérieures au xvie siècle, Juridictions, 4 vol., Paris/Angers, 1877-1883 ; A. Lecoy de La Marche, Le Roi René, sa vie, son administration, ses travaux artistiques et littéraires, d’après les documents inédits des archives de France et d’Italie, Paris, 1875 (2 vol.).
12 Se reporter à J. Bradley, H. Short, Texts into databases : The Evolving Field of Newstyle Prosopography, ACH/ALLC conference, Athens (Georgia), 2003 ; M. Pasin, J. Bradley, « Factoid-based Prosopography and Computer Ontologies : Towards an Integrated Approach », Digital Scholarship in the Humanities, 30/1 (2015).
13 Dans le cas d’officiers juifs ou musulmans.
14 A. Tchounikine, M. Miquel, T. Pécout, J.-L. Bonnaud, « Prosopographical Data Analysis. Application to the Angevin officers (13th-15th Centuries) », Journal of Data Mining and Digital Humanities, Épisciences.org, sous presse.
15 Variable à deux états, « vrai » ou « faux ».
16 « Once we make the decision not to normalize, we’ve embarked on a very slippery slope. […] In choosing to denormalize, we’ve backed off from a position that does at least have solid science and logical theory behind it, and replace it by one that’s purely pragmatic in nature » (C. J. Date’s Database Design and Relational Theory : Normal Forms and All That Jazz, Sebastopol (California), 2012).
17 Ce n’est pas tout à fait vrai : un nom peut bien sûr être porté par plusieurs officiers. Nous choisissons cependant de ne pas traiter des homonymies dans cet exemple simplifié et de dupliquer simplement les valeurs. Notons que nous avons opéré de la même façon pour les noms de baptême.
Haut de pageTable des illustrations
![]() |
|
---|---|
Titre | Fig. 1. Les différents types de modèles de données |
URL | http://journals.openedition.org/medievales/docannexe/image/10863/img-1.jpg |
Fichier | image/jpeg, 139k |
![]() |
|
Titre | Fig. 2. Architecture applicative de la suite Prosopange |
URL | http://journals.openedition.org/medievales/docannexe/image/10863/img-2.jpg |
Fichier | image/jpeg, 80k |
![]() |
|
Titre | Fig. 3. Liste déroulante pour la saisie de la confession et cases à cocher pour la saisie de la charge |
URL | http://journals.openedition.org/medievales/docannexe/image/10863/img-3.jpg |
Fichier | image/jpeg, 37k |
![]() |
|
Titre | Fig. 4. Exemple de saisie de données multivaluées dans un tableur |
URL | http://journals.openedition.org/medievales/docannexe/image/10863/img-4.jpg |
Fichier | image/jpeg, 52k |
![]() |
|
Titre | Fig. 5. Normalisation du schéma de la base de données |
URL | http://journals.openedition.org/medievales/docannexe/image/10863/img-5.jpg |
Fichier | image/jpeg, 359k |
![]() |
|
Titre | Fig. 6. Les sources représentées dans une colonne additionnelle |
URL | http://journals.openedition.org/medievales/docannexe/image/10863/img-6.jpg |
Fichier | image/jpeg, 166k |
![]() |
|
Titre | Fig. 7. Les sources représentées dans une table |
URL | http://journals.openedition.org/medievales/docannexe/image/10863/img-7.jpg |
Fichier | image/jpeg, 129k |
![]() |
|
Titre | Fig. 8. La table source détaillée |
URL | http://journals.openedition.org/medievales/docannexe/image/10863/img-8.jpg |
Fichier | image/jpeg, 97k |
![]() |
|
Titre | Fig. 9. La gestion des dates incomplètes |
URL | http://journals.openedition.org/medievales/docannexe/image/10863/img-9.jpg |
Fichier | image/jpeg, 70k |
![]() |
|
Titre | Fig. 10. L’héritage utilisé pour les données imprécises de localisation |
URL | http://journals.openedition.org/medievales/docannexe/image/10863/img-10.jpg |
Fichier | image/jpeg, 289k |
![]() |
|
Titre | Fig. 11. L’héritage utilisé pour les relations interpersonnelles |
URL | http://journals.openedition.org/medievales/docannexe/image/10863/img-11.jpg |
Fichier | image/jpeg, 218k |
![]() |
|
Titre | Fig. 12. Modèle conceptuel UML de l’exemple développé dans cet article |
URL | http://journals.openedition.org/medievales/docannexe/image/10863/img-12.jpg |
Fichier | image/jpeg, 60k |
Pour citer cet article
Référence papier
Isabelle Mathieu, Maryvonne Miquel et Anne Tchounikine, « Les officiers des territoires angevins à la fin du Moyen Âge », Médiévales, 78 | 2020, 169-192.
Référence électronique
Isabelle Mathieu, Maryvonne Miquel et Anne Tchounikine, « Les officiers des territoires angevins à la fin du Moyen Âge », Médiévales [En ligne], 78 | printemps 2020, mis en ligne le 02 janvier 2022, consulté le 23 avril 2025. URL : http://journals.openedition.org/medievales/10863 ; DOI : https://doi.org/10.4000/medievales.10863
Haut de pageDroits d’auteur
Le texte et les autres éléments (illustrations, fichiers annexes importés), sont « Tous droits réservés », sauf mention contraire.
Haut de page