Navegación – Mapa del sitio

InicioNuméros12De la base au réseau. L'apport de...

De la base au réseau. L'apport des bases de données à l'étude des réseaux

De la base de datos a la red. El aporte de las bases de datos a los estudios de redes
From database to network. The application of databases to networks studies
Jean-Pierre Dedieu y Álvaro Chaparro

Resúmenes

El artículo muestra un proceso técnico mediante el cual podemos pasar de la acumulación masiva de información en una base de datos histórica a su explotación a través de un programa informático destinado al análisis de las redes sociales. Para desarrollar el tema, proponemos dos herramientas: la base de datos Fichoz y el software Pajek. El trabajo se reparte en dos partes, la primera donde mostraremos inicialmente un corpus teórico, describiendo la base de datos y la utilización de los diferentes ficheros y la segunda, centrada en un ejemplo práctico, donde detallaremos en su totalidad las etapas del método. El objetivo del artículo es puramente demostrativo.

Inicio de página

Texto completo

1Nous décrivons ici le processus technique qui permet de passer de l'accumulation massive d'information dans une base de données à sa mise en œuvre par un programme informatique destiné à l'analyse des réseaux sociaux. Nous montrerons ainsi le caractère indispensable de l'informatique dans la recherche et décrirons les étapes d'une méthode qui permet d'atteindre des résultats clairs et directs en matière d'étude des réseaux. Nous utiliserons deux outils : la base de données Fichoz et le logiciel Pajek. Notre travail comportera deux parties : en premier lieu un corpus théorique, qui décrira d'abord la base de données, spécialement la manière dont elle traite les relations, ensuite la fonction des fichiers « Pajek_relationship » et « Pajek_vertices_dictionary », qui servent d'interface entre Fichoz et Pajek ; en second lieu un exemple pratique. Notre propos est purement démonstratif, pour ne pas dire terre-à-terre : mener un lecteur peu familier de la question littéralement par la main pour lui faire toucher du doigt à la fois la puissance des bases de données pour la recherche historique, les difficultés pratiques que soulève leur utilisation et les solutions que nous croyons pouvoir y apporter.

1. Introduction

2L'intérêt principal d'une base de données réside dans le stockage pour exploitation postérieure d'un ensemble d'informations. La gestion d'une base de fait par l'intermédiaire d'un Système de Gestion de Base de Données (SGBD), un logiciel qui permet de manipuler de façon claire, simple et ordonnée l'ensemble des données que contient la base. Il forme interface entre l'utilisateur, la base et les applications, c'est-à-dire les programmes qui peuvent être mis en œuvre à partir des données préservées dans la base. Le marché propose de nombreux SGBD. Fichoz utilise FileMaker.pro, actuellement sa version 12.

  • 1 Sur Fichoz, voir en dernier lieu : Jean Pierre Dedieu, «Fichoz 2011. Balance de una base de datos s (...)

3Fichoz constitue une référence en matière de bases de données historiques. Plus qu'un système fermé, il repose sur un ensemble de principes et de modules interchangeables, qui ont servi à créer des bases de données sur des sujets aussi divers que les graffitis de Pompéi, le cinéma français de l'Entre-deux-guerres, les mouvements de navire aux xviiie et xixe siècles, le personnel administratif de la Monarchie espagnole aux xviiie et xixe siècles - le projet à propos duquel il fut primitivement conçu -, le monde de la tapisserie en France du Moyen Age à nos jours ou le personnel de la cour de Chine au xviiie siècle. Autrement dit, il est capable de stocker tout type de données relatives à l'histoire sociale, terme que nous prendrons ici dans son acception la plus large : toute information relative à des interactions entre acteurs, de quelque nature que ce soit, comme par exemple, de personnes à personnes, de personnes à entreprises, d'entreprise à entreprise, de personnes à objets culturels, tels des livres ou des tableaux. C'est précisément l'aspect relationnel que nous décrirons ici, en montrant comment passer de la donnée brute à la représentation graphique des liens entre agents de l'histoire, de quelque nature qu'ils soient1.

  • 2 Sur Pajek : Wouter De Nooy, Andrej Mrvar et Vladimir Batagelj, Exploratory social analysis with Paj (...)

4La représentation visuelle des réseaux se fera en utilisant Pajek, par l'intermédiaire de routines d'interface qui non seulement permettent le passage de la donnée brute à sa représentation, mais qui offrent aussi la possibilité de retravailler les données dans la phase intermédiaire, assouplissant ainsi considérablement le traitement. Pajek est un logiciel gratuit d'usage public (freeware) qui, à partir d'une liste de relations entre paires d'objets, a) dessine le graphe global des dites relations, dans le respect des règles habituelles de la théorie de réseaux ; b) permet d'effectuer sur cet ensemble de relation les opérations et calculs prévus par cette même théorie2.

5Le présent article admet plusieurs niveaux de lecture. Il s'adresse en priorité à des chercheurs dotés de solides connaissances dans l'utilisation des ordinateurs. Certains passages, pour être bien compris, demandent une certaine pratique dans le maniement des bases de données, des feuilles de calcul et des logiciels. Toutefois, le non-spécialiste y trouvera aussi son profit : il ne pourra certes suivre la démonstration dans tous ses détails, mais il comprendra la vue d'ensemble des problèmes et des solutions proposées. De toutes façons, il ne s'agit que d'une introduction. Les auteurs restent à la disposition de quiconque serait intéressé par des explications complémentaires ou une formation individuelle.

2. De la base au réseau

6Outre ses capacités de stockage, une base de données doit fournir à ses utilisateurs la capacité de récupérer et d'exploiter l'information. Elle doit comporter, sous peine d'inutilité, un système complet d'interrogation et un système efficace d'exportation des données à quelque support que ce soit. Fichoz exporte ses données, sans difficulté aucune et sans manipulations particulières, au format tabulé, ce qui permet de les récupérer par la suite et de les retravailler sous forme de feuille de calcul ou tout autre instrument pour une analyse statistique, factorielle, textuelle, réticulaire ou cartographique.

2a. Fichoz : acteurs et relations

7Fichoz est structuré sur la base des actions effectuées par les acteurs. Chaque action forme un enregistrement dans la base. L'action est, en principe, l'élément le plus petit en lequel est atomisée la documentation. L'action est enregistrée munie de tous les éléments nécessaires pour la rendre compréhensible par elle-même, sans nécessité de recourir au contexte fourni par d'autres enregistrements. Elle ne prend toutefois sa pleine valeur qu'intégrée à une série avec laquelle elle entre en résonance, série construite sur la base de l'identité des acteurs concernés, de la thématique abordée ou de la chronologie. L'enregistrement d'une action doit pouvoir répondre aux questions suivantes : qui, quand, où, quoi, avec qui, réponses qui constituent autant de dimensions descriptives et la caractérisent comme unique, impossible à reproduire à l'identique. La mention d'une action est ainsi toujours accompagnée de celle d'un acteur qui l'exécute. Les deux forment un binôme indissociable. De ce point de vue, les actions enregistrées dans Fichoz peuvent être de deux types : tout d'abord des actions « unipersonnelles », qui impliquent un seul acteur et qui constituent le squelette d'une biographie : naissance, décès, nomination à une charge publique, option idéologique, évaluation de fortune, et autres similaires ; les actions relationnelles ensuite, auxquelles prend forcément part un second acteur : la mention d'un achat, d'une aide donnée, d'une amitié, d'une plainte en justice, par exemple.

  • 3 Fichoz est accompagné d'un fichier d'aide qui explicite les concepts sur lesquels il repose. On y t (...)
  • 4 L'acteur tel que nous le concevons correspond à la représentation que donne Bruno Latour de l'acteu (...)
  • 5 Lorsque les données proviennent d'une source primaire, la base donne à l'acteur le nom que mentionn (...)
  • 6 L'identificateur des acteurs collectifs se termine en « C », celui des objets culturels en « L ». E (...)

8Fichoz nomme acteur3 toute entité individualisée qui joue un rôle dans la chaîne des événements qui constituent une biographie. Il repose, comme nous l'avons déjà mentionné, sur une conception large de l'acteur4. Cette ampleur même nous conduit à distinguer plusieurs types d'acteurs, dont trois nous intéressent ici : acteurs individuels, acteurs collectifs et objets culturels. L'acteur individuel, c'est la personne de chair et d'os. L'acteur collectif, formé de plusieurs acteurs individuels, mais qui les transcende, est souvent ce que les anglais nomment « corporation », un collectif doté d'une personnalité reconnaissable, de permanence, et incarnée dans un statut légal (sociétés commerciales, syndicats, assemblées de gouvernement, majorats, par exemple) ; mais il s'agit aussi parfois de simples réunions temporaires qui ne constituent pas par essence des sujets de droit, comme un congrès scientifique ou un salon littéraire. L'objet culturel est une production réalisée par l'inititiave humaine et dotée par les conventions sociales en vigueur d'une personnalité assez forte pour servir de lieu et d'enjeu de regroupement ou de conflit. Les livres sont, à l'heure actuelle, les objets culturels les mieux représentés dans la base. Un acteur est identifié dans Fichoz par son nom, qui varie selon les circonstances5, et par un identificateur formé de six signes alphanumériques (presque toujours un chiffre) qui l'accompagne dans toutes ses apparitions6.

  • 7 Figurent également la référence de la source d'où l'on a tiré la donnée, et une date de fin d'événe (...)

9De sorte que la biographie d'un acteur se présente comme la liste chronologiquement ordonnées des actions auxquelles il a pris part. L'action est liée à l'identificateur, pas au nom. Visuellement, la base présente à l'écran le nom de l'acteur principal responsable de l'action, au centre de l'écran, dans un champ nommé « P2_name » qui voisine immédiatement avec un champ « P2_id », lequel contient l'identificateur correspondant. Á droite du nom se situe la description de l'action en texte libre, « Action_text ». L'entrée est complétée par une date de début d'action, dont la présence est obligatoire, qu'elle soit donnée par la source ou évaluée (Fig. I)7.

Fig. I. Écran principal de Fichoz. Une action

Fig. I. Écran principal de Fichoz. Une action

(N. B. : pour agrandir l’illustration, cliquer sur « original »)

© Fichoz

10Au cas où l'action implique deux acteurs, autrement dit lorsque l'action est une relation (Fig. II), le second acteur est mentionné en position P1, dans les champs « P1_name » et « P1_id ». La nature de la relation est résumée sous forme d'une brève étiquette dans le champ « Relationship », situé entre P1 et P2. Le tout se lit de gauche à droite, en sous-entendant les mots « a pour » : « A créature B » se lira : « A a pour créature B », et non « A est créature de B ». L'étiquette n'indique rien quant à l'intensité ni au contexte de la relation. Ces mentions sont réservées au champ « Action-text » qui en donne une description développée. La liste des termes utilisés par le chercheur comme étiquette n'est pas limitée : tuteur, ami, ennemi, censeur, collègue, directeur, collaborateur, héritier, mandataire, client, agent d'affaire et ainsi ad infinitum. Une certaine cohérence facilite le travail ultérieur, mais ces étiquettes peuvent être modifiées à la demande sans affecter la structure de la base, et peuvent être aisément recodées ou complétées en fonction des besoins d'une recherche particulière, à partir de la description en texte libre, dans les fichiers intermédiaires par où transitent les données entre Fichoz et Pajek.

Fig. II. Écran principal de Fichoz. Actions relationelles

Fig. II. Écran principal de Fichoz. Actions relationelles

(N. B. : pour agrandir l’illustration, cliquer sur « original »)

© Fichoz

  • 8 Ces deux champs n'apparaissent pas sur les écrans les plus courants. L'utilisateur, pour y accéder, (...)

11Une même action peut impliquer plus de deux personnes. Dans ce cas, Fichoz réduit ces relations multiples à une série de paires binomiales dans lesquelles l'un des acteurs apparaît systématiquement répété, servant ainsi de gond au système d'ensemble que Pajek se charge de reconstituer par la suite. Il peut arriver cependant que P1 et P2 agissent comme représentantes d'un autre acteur individuel (cas du tuteur pour son pupille) ou collectif (cas du dirigeant d'entreprise agissant es-qualité). Le fait crée entre représentant et représenté une relation d'équivalence qui rend impossible de les séparer en deux enregistrements différents. En ce cas, les identifiants de l'acteur individuel ou collectif représentés figurent à côté de l'identifiant de l'acteur principal concerné, en deux champs P3 (à côté de P1) et P4 (à côté de P2) (Fig. III)8. Au moment de transférer les données à Pajek, une routine spéciale automatique, contenue dans les fichiers intermédiaires, développera ces relations pour en permettre un traitement adéquat.

Fig. III. Écran « Twin actors » de Fichoz . Actions relationnelles où figurent P3 et P4

Fig. III. Écran « Twin actors » de Fichoz . Actions relationnelles où figurent P3 et P4

(N. B. : pour agrandir l’illustration, cliquer sur « original »)

© Fichoz

12Les relations de parenté, en revanche, à l'exception des mariages et de celles dont on connaît la nature sans pouvoir en préciser la voie (deux personnes présentées comme cousins sans que l'on puisse reconstituer le cheminement du cousinage, par exemple), ne font pas l'objet d'enregistrement sous forme binomiale. La famille forme un système relationnel en elle-même, aux règles extrêmement contraignantes, qui relie de manière dynamique, c'est-à-dire perpétuellement changeante, des centaines d'individus. La représentation binomiale est incapable de rendre compte d'une telle complexité. Pour ce type de données, Fichoz comprend un module de Généalogie qui permet de reconstruire sans limites des tissus de relations familiales avec une souplesse totale. Ce module comprend une routine qui permet d'en extraire, à tout instant, une photographie fixe du réseau de parenté hic et nunc de n'importe quel acteur, et de transcrire celle-ci en relations binomiales pour l'intégrer au système précédent.

2b. L'interface d'exportation à Pajek

  • 9 La purge se fait automatiquement en actionnant un bouton vert intitulé « Purge » qui apparaît dans (...)

13Une fois terminé le processus de chargement des données à Fichoz, l'utilisateur procède à leur transfert aux fichiers intermédiaires que nous avons ci-dessus mentionnés. Là, les données seront transformées et formatées de façon semi-automatique au format que réclame Pajek. Ces fichiers intermédiaires sont deux : « Pajek_relationships » (à partir de maintenant : « PRelations ») et « Pajek_vertices_dictionary » (à partir de maintenant « PPoints »). Tous deux sont des fichiers permanents, créés sous FileMaker.pro et insérés dans le système Fichoz. Ce sont des coquilles vides qui reçoivent par importation les données qu'ils vont traiter et qui sont purgés une fois le traitement effectué9. Ils sont obligatoirement rangés dans un même dossier, car ils sont liés par des liens informatiques qui présupposent ce voisinage. Tous deux sont indispensables : le premier livre une liste de relations, le second un liste d'acteurs, les deux éléments dont se compose un fichier lisible par Pajek.

14L'utilisateur a la possibilité de préserver des fichiers utilisés dans une enquête pour réutilisation postérieure en créant une copie des fichiers terminés, puis en transférant l'original dans un autre dossier et en effectuant la purge sur la copie, après en avoir renommé les fichiers pour leur redonner les noms que nous indiquons ci-dessus, qui sont canoniques, puisque c'est sur eux que sont fondés les liens informatiques entre les deux éléments.

Fig. IV. Écran principal de PRelations

Fig. IV. Écran principal de PRelations

(N. B. : pour agrandir l’illustration, cliquer sur « original »)

© Fichoz

15La procédure comporte les étapes suivantes. Il faut tout d'abord sélectionner dans Fichoz, par les routines d'interrogations adéquates, l'ensemble des enregistrements relationnels qui correspondent au phénomène que l'on s'apprête à étudier. Ceci fait, l'utilisateur ouvre le fichier PRelations, et y importe les données sélectionnées grâce à la commande « Import » de FileMaker. Il dispose alors dans PRelations de toute l'information relationnelle nécessaire. Dans chacun des enregistrements figurent en P1, P2, P3 et P4 les identifiants des acteurs concernés, l'étiquette caractérisant la relation (champ Relationship), la date, le texte libre qui décrit la relation (Action_text). Le nom des acteurs n'est pas transféré. Il sera récupéré automatiquement comme nous le verrons bientôt (Fig. IV).

16L'importation terminée, l'on entre dans une phase de mise au point des données. L'utilisateur dispose pour cela de trois boutons rouges apparents sur les Fig. IV : « Expand data », « Multiplexed relationships » et « Loops ». Il les actionnera dans cet ordre. Le premier crée les entrées relationnelles correspondant aux relations P1-P3 et P2-P4 que nous avons décrites plus haut. Le deuxième recherche la présence, dans l'univers étudié, de relations multiples concernant une même paire d'acteurs et propose à l'utilisateur de les prendre en compte une à une ou de les compter comme une seule. « Loops » recherche les acteur liés à eux-mêmes (le cas peut se présenter en théorie des réseaux) et propose des solutions. Le champ « Relationship class value » permet d'affecter manuellement à la relation une valeur quelconque, positive ou négative ; par exemple « 1 » pour toutes les relations de collaboration positive, à l'exclusion des relations économiques ; « -1 » pour toutes les relations d'affrontement, à l'exclusion des affrontements économiques, « 2 » pour toutes les collaborations économiques, et « -2 » pour les affrontements de nature économique. Ces valeurs permettront à Pajek d'effectuer des calculs. Les champs « Mk P1 » et « Mk P2 » reçoivent un marqueur arbitraire qui indique que la relation doit être prise en compte dans le graphique Pajek qui résultera du travail. Ce marquage est de la plus haute importance. Seuls les acteurs figurant dans les paires sélectionnées apparaîtront dans la liste des acteurs numérotés (voir ci-dessous) que Pajek prendra en compte. Il permet, en outre, d'importer d'un seul coup dans les fichiers intermédiaires les données correspondant à plusieurs opérations, puis de traiter celles-ci séparément. Il donne enfin la souplesse nécessaire à la recherche en cours, en permettant de faire souplement varier la population étudiée au vu des premiers résultats exploratoires.

17En un mot, PRelationspermet de caractériser les relations. Cette étape terminée, l'utilisateur actionne le bouton « Dictionary » qui le fait entrer dans PPoints, le fichier intermédiaire à partir duquel il va caractériser les acteurs (Fig. V).

Fig. V. Écran principal de PPoints

Fig. V. Écran principal de PPoints

(N. B. : pour agrandir l’illustration, cliquer sur « original »)

© Fichoz

18PPoints est le frère de PRelations. Dans sa forme originelle, il comporte une liste de tous les identificateurs utilisés dans Fichoz, donc une entrée pour chacun des acteurs existant dans Fichoz. Cela lui permet à chacun de ses enregistrements d'établir automatiquement un lien avec les entrées de PRelations qui mentionnent les mêmes identificateurs, en P1 ou en P2. On remarque les champs Mark P1 et Mark P2. S'ils ont été remplis dans PRelations, ils apparaissent remplis ici aussi, ce qui nous permet de sélectionner les acteurs concernés par les relations mentionnées dans PRelations. De même PPoints appelle, toujours par un lien fondé sur l'identifiant de l'acteur, un fichier dont nous n'avions pas parlé jusqu'ici, un Dictionnaire des acteurs, qui contient outre leur identifiant, leur nom et un champ de codage (Codification) que nous décrirons dans le prochain paragraphe.

19Chaque entrée du Dictionnaire des acteurs comporte en effet un champ de « codage au vol », qui permet de noter de façon très souple les caractéristiques que présente l'acteur concerné. L'utilisateur peut par exemple, à tout moment, marquer « Collégien » dans toutes les entrées du dictionnaire qui mentionnent un acteur qui est passé par l'un des collèges majeurs des grandes universités espagnoles, et « Non collégien » dans celles de ceux qui n'y ont point étudié. Le champ de codage au vol permet soit de sélectionner des acteurs présentant une caractéristique ou une autre, soit de caractériser les acteurs en fonction de tout trait particulier en portant une notation dans les champs Vecteur 1 et Vecteur 2 ou dans les champs Partition 1, Partition 2, Partition 3, Partition 4, qui permettent de répartir les acteurs en classes à partir desquelles Pajek pourra effectuer des calculs. Ces partitions sont reflétées dans le fichier PRelations, ce qui permet de marquer et de classer les relations en fonction d'elles. Un champ Vertex colour permet de forcer l'attribution d'une couleur spécifique au point sur le graphe.

20Arrivés à ce point, nous pouvons exporter nos données à un fichier texte lisible par Pajek. Pour cela, il suffit de sélectionner l'ensemble des entrées comportant une marque dans les champs Marker P1 ou Marker P2, puis d'actionner le bouton gris « Pajek_id », qui lance un programme lequel, du premier au dernier, numérote les enregistrements sélectionnés de « 1 » au chiffre nécessaire pour les traiter tous. Cette numération doit être continue et sans vide pour que Pajek puisse l'utiliser. Ceci fait, en actionnant le bouton rouge « Export to Pajek », l'utilisateur lance une routine qui exporte les enregistrements numérotés à un fichier texte lisible par Pajek.

2c. Pajek et ses exigences

  • 10 On peut le télécharger à la page web : http://pajek.imfm.si/doku.php?id=download (été 2012). L'util (...)

21Nous avons vu que l'analyse des réseaux était un point fondamental de Fichoz. La représentation graphique est nécessaire pour saisir synthétiquement un réseau. Pour ce faire, Pajek présente quelques avantages. Il est tout d'abord gratuit et d'accès public10 ; il construit efficacement des graphiques qui permettent de synthétiser un grand nombre de relations ; il réalise tout aussi efficacement les calculs les plus usuels dans le domaine ; il est relativement simple à mettre en œuvre. Son maniement requiert cependant une formation spécifique, étant donné l'extension de son potentiel analytique et l'ampleur de ses possibilités techniques.

22Pajek peut traiter les données de trois manières : a) en mode-1, dans lequel il étudie la proximité des acteurs les uns avec les autres en fonction des relations qu'ils entretiennent directement entre eux sur un unique plan relationnel, d'acteur à acteur (exemple : les auteurs qui se citent les uns les autres) ; b) en mode-2, dans lequel il calcule la proximité des acteurs en fonction des rapports qu'ils entretiennent avec une classe d'entités différente (exemple : la proximité des auteurs les uns avec les autres en fonction de leurs éditeurs ; ou la proximité des éditeurs les uns avec les autres en fonction des auteurs qu'ils publient) ; c) l'analyse des relations généalogiques entre acteurs, fondée sur l'ascendance, non sur l'union. Ce qui suit concerne exclusivement le mode-1, le seul dont nous nous soyons jusqu'à présent occupé sérieusement.

  • 11 L'étiquette d'identification est automatiquement calculée par la routine d'exportation des données (...)

23Nous avons déjà signalé que Pajek exige que les données lui soient fournies dans des fichiers texte (.txt) ou tabulés (.tab), et qu'elles soient formatées d'une manière précise. D'abord la liste des points, chacun sur une ligne, défini par un numéro Pajek séquentiel croissant d'une unité à chaque nouveau point, sans interruption de la série. En tête de la liste, le mot : « *Vertices » suivi du nombre total de points mentionnés. Chaque ligne, outre le numéro Pajek, peut comprendre une étiquette qui permet d'identifier l'acteur présenté sur le graphique final (exemple : 000015-ALBURQUERQ)11, la mention de la couleur que doit avoir le point dans le graphique (exemple : ic Blue), et quelques autres paramètres pour la description desquels nous renvoyons au fichier d'aide de Fichoz. Á la suite de cette séquence, doit apparaître une seconde partie qui décrit les segments qui joignent les points. Cette seconde séquence est introduite par les mots « *Arcs » ou « *Edges », selon que les segments prendront ou non la forme de flèches orientées du premier point vers le second. Chacune des lignes qui suivent décrit un segment. Elle comporte deux identificateurs Pajek, celui du premier point, origine du segment, et du second, sa terminaison. Seules les paires objets d'une relation sont bien entendu décrites. Chaque relation est suivie d'une valeur qui lui est affectée et qui détermine la largeur et éventuellement la couleur du segment qui les unit (Fig. VI).

24Il est clair qu'une telle mise en forme ne peut être réalisée manuellement que sur des populations très réduites. D'où la nécessité de routines automatiques.

Fig VI. Échantillon d'un fichier .txt lisible par Pajek

Fig VI. Échantillon d'un fichier .txt lisible par Pajek

(N. B. : pour agrandir l’illustration, cliquer sur « original »)

© Fichoz

25Chaque utilisateur est libre de nommer le fichier texte qui en résulte de la façon qui lui convient et de le conserver dans le dossier qu'il veut. La dernière opération consiste à lancer Pajek. Ceci fait, le programme dessine le réseau dont nous venons de lui communiquer les données. Il nous reste maintenant à présenter un exemple pratique, dont nous décrirons tous les pas depuis le début, à savoir la sélection des données dans Fichoz et leur première exportation.

3. Un exemple pratique

26L'opération vise à isoler l'ensemble des personnes qui ont appartenu à plus d'une des trois principales académies royales espagnoles aux xviiie siècle, l'Académie royale de la Langue, l'Académie royale d'Histoire et l'Académie royale des Beaux arts de San Fernando. On part de l'hypothèse que les individus qui présentent cette caractéristique ont joué un rôle de coordination entre les trois institutions. Or des recherches récentes confirment ce que l'on soupçonnait depuis longtemps, à savoir que les trois académies ont eu un rôle essentiel dans la domestication des intellectuels espagnols au service de la monarchie. Il est donc probable que les agents de coordination que nous cherchons à identifier ont géré cette mise en tutelle. Nous faisons l'hypothèse qu'ils appartenaient à la cour et étaient proches du souverain. Dans la pratique, nous cherchons à visualiser les liens qui unissent chaque académicien à la ou aux académies auxquelles il appartient, de façon à isoler visuellement le groupe de multi-appartenance et à en identifier les membres grâce à l'identifiant Pajek dont chaque point sera affecté sur le graphique. Il n'y aura plus ensuite qu'à rechercher dans Fichoz les éléments de carrière caractérisant chacun d'eux. Nous ne décrivons ici que les étapes principales du processus.

3a. Tâches réalisées à l'intérieur de Fichoz

27Pour chaque académie, l'une après l'autre, il faut d'abord localiser les enregistrements qui indiquent la condition d'académicien. Ce n'est pas si facile. On ne peut se fier sans plus au texte qui décrit l'événement : le nom de l'institution peut changer au fil du temps, les mots qui la désignent peuvent apparaître dans des contextes trompeurs. Interroger sur les mots « Directeur de l'Académie royale d'Histoire » renverrait les entrées qui concernent les directeurs en question, qui sont celles que l'on recherche effectivement, mais aussi « Laquais du Directeur de l'Académie royale d'Histoire », dont on n'a que faire. Pour obvier à cet inconvénient, chaque enregistrement est doté d'un champ de codage permanent (Action permanent coding) qui décrit de manière univoque son contenu (Fig. VII).

Fig. VII. Un enregistrement de Fichoz, format long, montrant le champ de codage permanent

Fig. VII. Un enregistrement de Fichoz, format long, montrant le champ de codage permanent

(N. B. : pour agrandir l’illustration, cliquer sur « original »)

© Fichoz

28Ce code est structuré de gauche à droite. La partie la plus à gauche indique les traits les plus généraux, la partie à droite les plus particuliers. L'information qui nous intéresse présentement figure dans les deux premiers segments du code (le troisième et le quatrième indiquent le lieu et la situation administrative de l'intéressé). « FFEAx-VB » dénote les académies royales ; « FFEAx-VBB » l'Académie royale d'Histoire ; « FFEAx-VBBxxA » le président de celle-ci ; « FFEAx-VBBxxD » un académicien (Fig. VIII). A ce point de l'opération, nous supposons que ce code a été introduit dans tous les enregistrements où il devait l'être. Seul un spécialiste du domaine scientifique concerné peut procéder à cette opération, tant les formulations fournies par les sources peuvent être variées et contenir de pièges. L'écriture des codes s'appuie sur un Dictionnaire général des Institutions de l'Espagne Moderne (DIEM) que réalise l'ensemble du groupe qui gravite autour de Fichoz et qui situe chaque institution, chaque organisation, dans son contexte propre. Nous pouvons ainsi, par le biais du code, localiser toutes les nominations d'académiciens.

Fig. VIII. Exemples de codes permanents concernant des académiciens

Fig. VIII. Exemples de codes permanents concernant des académiciens

(N. B. : pour agrandir l’illustration, cliquer sur « original »)

© Fichoz

29Dans le cas présent, opérer à partir des codes permanents ne suffit pas. Une même personne peut accumuler plusieurs nominations académiques : comme académicien correspondant, comme académicien titulaire, comme secrétaire ou directeur. Un simple comptage des entrées nous exposerait à des doubles comptes. Il faut en fait que nous marquions non pas l'événement, mais la personne, comme membre de l'Académie. C'est le rôle de la « codification au vol », déjà mentionnée. Nous sélectionnons, pour la première académie, toutes les entrées portant nomination à des postes de secrétaire, de directeur ou d'académicien titulaire, l'ensemble concerné par notre étude. Une fois cette sélection opérée, nous actionnons un petit programme nommé « P2 coding ». Celui-ci demande à l'opérateur quel code il veut affecter à l'ensemble des individus sélectionnés (Fig. IX). Dans le cas de l'Académie d'Histoire, nous porterons, par exemple : « AcaHis », mais nous aurions pu choisir n'importe quelle autre formulation.

Fig. IX. Écran pour le choix du code dans la routine de codage au vol

Fig. IX. Écran pour le choix du code dans la routine de codage au vol

(N. B. : pour agrandir l’illustration, cliquer sur « original »)

© Fichoz

30Nous répétons l'opération pour les deux autres académies avec les étiquettes « AcaBel » (Académie des Beaux-arts) et « AcaLen » (Académie de la Langue). Chaque acteur, et non plus seulement chaque événement, est alors marqué du signe de la ou des académies auxquelles il appartient (Fig. X).

Fig X. Enregistrement d'un événement, format étendu montrant les codes au vol

Fig X. Enregistrement d'un événement, format étendu montrant les codes au vol

(N. B. : pour agrandir l’illustration, cliquer sur « original »)

© Fichoz

31Rappelons que le champ de codification au vol (C. vuelo dans la figure X), pour être précis, n'appartient pas au fichier qui contient les actions, mais au Dictionnaire des acteurs annexe où chaque acteur ne figure qu'une fois (Fig. XI). La codification au vol est automatiquement appelée sur chaque enregistrement des actions auxquelles prend part l'acteur qui en est l'objet. Si un acteur appartient à plusieurs académies, le Dictionnaire des acteurs contiendra, l'un après l'autre, des codes qui les dénoteront toutes : « AcaHis AcaFer AcaLen », par exemple, pour qui serait membre des trois.

Fig. XI. Écran principal du Dictionnaire des acteurs

Fig. XI. Écran principal du Dictionnaire des acteurs

(N. B. : pour agrandir l’illustration, cliquer sur « original »)

© Fichoz

3b. Tâches réalisées dans les fichiers intermédiaires

32Ceci fait, on sélectionne, académie par académie, dans le Dictionnaire des acteurs, toutes les entrées comportant mention d'appartenance, et on importe les identifiants d'acteurs correspondants dans PRelations. L'un des termes de la relation, l'institution académique, reste implicite, simplement dénoté par une mention dans le Dictionnaire des acteurs. Il faut donc, pour chaque académie, reporter en position P1 (champ P1 id) de PRelations l'identifiant Fichoz de l'institution (Fig. XII), de façon à donner à chaque entrée la forme binomiale qui la rendra lisible.

Fig. XII. Identifiants Fichoz des Académies

Fig. XII. Identifiants Fichoz des Académies

(N. B. : pour agrandir l’illustration, cliquer sur « original »)

© Fichoz

33Optionnellement, la valeur du champ « Relationship class » peut être mise à « Membre ». Obligatoirement, la valeur du champ « Relationship class value » est mise à « 1 », puisque chaque ligne correspond à une seule relation et que celle-ci est positive (Fig. XIII).

Fig. XIII. PRelations

Fig. XIII. PRelations

(N. B. : pour agrandir l’illustration, cliquer sur « original »)

© Fichoz

34On effectue alors les opérations que nous avons décrites dans la première partie de ce travail (expansion des données, détermination des relations multiplexes et des boucles). On crée les identifiants Pajek et on exporte le tout à un fichier tabulé au format Pajek. La première ligne de la seconde partie de celui-ci est mise à la valeur « *Arcs », pour orienter les segments, étant donné que la relations d'appartenance est orientée. L'identifiant de l'académie figurant en P1 constitue le premier terme de la relation. La flèche ira donc de l'académie à l'académicien. Il conviendra de s'en souvenir.

3c. Tâches réalisées dans Pajek

35L'utilisateur lance Pajek. Depuis Pajek, il ouvre le fichier tabulé qu'il vient de créer (commande : File / Network / Read / [Chemin et nom du fichier tabulé]). Il obtient l'écran représenté à la figure XIV.

Fig. XIV. Écran principal de Pajek

Fig. XIV. Écran principal de Pajek

(N. B. : pour agrandir l’illustration, cliquer sur « original »)

© Fichoz

36Il sélectionne alors la première ligne, celle qui porte la référence du fichier tabulé, et il actionne la commande Draw / Draw. Il obtient un graphe assez confus, que nous ne reproduisons pas. Il l'ordonne en passant de façon itérative une routine contenue dans Pajek qui maximise la distance entre les points et minimise le chevauchement des segments (commande : Layout / Energy / Kamada Kawai / Free). Éventuellement, il termine le travail à la main, car il est possible de déplacer manuellement les points. Jusqu'à obtenir quelque chose de semblable à la Fig. XV.

Fig. XV. Premier graphe de Pajek, une fois ordonné par la routine Kamada Kawai

Fig. XV. Premier graphe de Pajek, une fois ordonné par la routine Kamada Kawai

(N. B. : pour agrandir l’illustration, cliquer sur « original »)

© Fichoz

37On commence à distinguer sur ce premier graphe des ensembles distincts, dont la répartition permet d'ores et déjà d'avancer quelques conclusions. Les académies sont les trois points d'où rayonnent des lignes en couronne. Les académiciens appartenant à deux académies figurent à mi-chemin de leurs académies d'appartenance. Le groupe de triple appartenance, celui que nous cherchions à isoler, est effectivement situé au centre. Quelques manœuvres supplémentaires donneront plus de clarté à l'ensemble.

38La première consiste à classer les points qui représentent les académiciens en trois classes, selon le nombre d'académies auxquelles ils appartiennent. On le fait depuis l'écran principal de Pajek, en actionnant la commande Net / Partitions / Degree / Input, qui calcule le nombre de segments qui débouchent sur le point et attribue au point la classe correspondante. Cette division en classes s'appelle une partition. Le nom de la partition créée apparaît sur l'écran principal de Pajek, dans le deuxième paragraphe (Fig. XIV). On sélectionne la ligne contenant ce nom, et l'on dessine à nouveau le graphe en utilisant la commande « Draw / Draw-Partition-Vector ». Chaque point prend une couleur qui correspond à la partition à laquelle il appartient, couleur que Pajek attribue automatiquement, mais que l'utilisateur peut modifier s'il le désire (Fig. XVI).

Fig. XVI. Graphe de partition

Fig. XVI. Graphe de partition

(N. B. : pour agrandir l’illustration, cliquer sur « original »)

© Fichoz

39Pajek nomme « vecteur » un quotient qui mesure le poids de la classe dans l'ensemble. Sa valeur varie de 0 à 1. Il est possible de redessiner le graphe XVI en faisant varier la taille des points en fonction de la valeur du vecteur auquel il appartient. Ces valeurs étant par construction des décimales de l'unité, les points sont minuscules. On en change l'échelle à l'aide de la commande Size / Vector / 50, qui donne à l'unité (valeur 1) une taille de cinquante pixels. Les académiciens qui n'appartiennent qu'à une académie ne nous intéressent pas pour le moment. Nous les éliminons du graphe à l'aide de la commande Net / Transform / Reduction / Degree / Input / 2, qui exige que deux segments au moins confluent vers un point pour prendre celui-ci en compte. Nous ajoutons manuellement en texte libre quelques commentaires, et nous obtenons la Fig. XVII.

Fig. XVII. Académies et académiciens. Résultat final

Fig. XVII. Académies et académiciens. Résultat final

(N. B. : pour agrandir l’illustration, cliquer sur « original »)

© Fichoz

40En cliquant dans l'écran correspondant avec le bouton droit de la souris sur chaque point, on fait apparaître son identifiant Pajek, qui contient, entre autres, son identifiant Fichoz. Il n'y a plus qu'à consulter Fichoz pour connaître la carrière de l'individu. Cette opération effectuée sur la grosse douzaine des triple-appartenances a totalement confirmé notre hypothèse de départ. Il s'agit de personnage qui sont tous connus pour être des hommes de confiance du roi, auquel les lient des sentiments de fidélité et d'amitié personnelle.

4. Conclusions

41Le cas que nous avons exposé n'est pas des plus complexes. De fait, un utilisateur qui domine la mécanique de l'exportation depuis Fichoz et qui travaille sur un univers de données où les identifiants des acteurs ont été correctement portés, autrement dit dans les conditions normales d'utilisation de la base, obtient un graphique relationnel brut en moins de cinq minutes. En dépit de sa simplicité, le cas permet des observations instructives sur le maniement des grandes bases de données historiques.

  • 12 François López, « Les livres des espagnols à l'époque moderne », Bulletin Hispanique, 1997, 99, 1, (...)

42La première souligne l'utilité des grandes bases généralistes, du type de Fichoz. Les données sur les académiciens n'ont pas été chargées spécifiquement pour vérifier l'hypothèse de travail que nous avons exposée. Nous nous sommes contenté dans ce cadre de vérifier qu'elles étaient exhaustives et d'apporter quelques compléments. L'essentiel avait été chargé au cours d'une recherche menée à Bordeaux plusieurs années auparavant sur les populations d'auteurs dans l'Espagne du xviiie siècle par le regretté François Lopez12. Nous avons pu utiliser cette matière telle quelle, de même que le font, pour d'autres fins et dans un autre contexte, Victor Pampliega y Alba de la Cruz, deux doctorants madrilènes. Correctement atomisées, équipées de façon permanente de codes pertinents, les données peuvent être immédiatement mobilisées pour les usages les plus variés. La masse devient dès lors qualité, au sens où elle permet au chercheur de formuler librement ses hypothèses en conservant la possibilité de les tester sur le champ.

  • 13 Eva Velasco Moreno, La Real Academia de la Historia en el siglo xviii. Una institución de sociabili (...)
  • 14 D'autres exemples de bénéfices induits dans : Willard Mac Carty, Humanities Computing, Basingstoke, (...)

43La seconde met en relief le fait que cette mobilisation des données exige un gros effort préalable de préparation. Non seulement a-t-il fallu dépouiller les listes d'académiciens13, mais encore insérer dans chaque entrée un élément de codification permanente pour rappeler aisément les enregistrements concernés. Encore qu'insérer des codes ne soit pas ce qui a demandé le plus d'efforts... Il avait fallu au préalable les élaborer, de façon à disposer d'une codification qui permette de retrouver sans équivoque des actions de plus ou moins grande extension : tous les académiciens si nécessaire, mais aussi tous les académiciens de chaque académie, tous les officiers de chacune d'elle, par exemple. Il fallait insérer ces codes dans une codification générale des actions, ce qui nous a obligé, entre autre, à réfléchir au fait de savoir si les académies devaient être considérées plutôt comme des institutions d’État ou comme des associations privées. Il nous a fallu en fin de compte élaborer une vision panoramique de toutes les institutions sociales de l'Espagne du xviiie siècle. Sera-t-il nécessaire de préciser que lorsque nous avons entrepris cette tâche, il n'existait rien de semblable ? Et que l'effort que nous avons dû fournir pour obtenir, à coup de tâtonnements et de repentirs, un schéma général fonctionnel justifiait à lui seul l'effort investi dans l'élaboration de la base ; avec, en prime, la certitude d'avoir réussi - chose rare en sciences sociales – car, en informatique, l'adéquation de la structure des données à la réalité de ce qu'elles représentent est un excellent critère d'exactitude. Le résultat est un schéma général qui occupe 400 pages de texte, sans les commentaires qui nécessairement l'accompagnent. On a là un bel exemple des bénéfices induits par l'informatisation, en dehors des avantages tirés d'un maniement souple de données massives14 : la base, par la nécessité de résoudre les problèmes que posait sa consultation, a fourni l'incitation à une entreprise que personne n'avait osé jusqu'alors affronter ; elle en a donné la possibilité en concédant accès à une vue d'ensemble de ce qu'étaient les institutions publiques et privées de l'époque ; elle en a fourni la validation finale par l'efficacité démontrée du produit final pour résoudre le problème de départ.

  • 15 La complexité inhérente aux bases de données scientifique me fait envisager avec la plus grande rés (...)

44La troisième conclusion porte sur le fait que le maniement d'une base de données, même parfaitement structurée et équipée de toutes les annexes nécessaires, exige de l'utilisateur une forte préparation personnelle. Préparation scientifique dans le champ couvert, avant tout : on ne peut utiliser utilement un tel instrument sans disposer d'une hypothèse de travail à vérifier. Le champ des possibilités ouvertes par l'instrument est si vaste que l'exigence d'une forte problématique de départ est plus rigoureuse encore qu'à l'ère du stylo-bille. Préparation informatique, ensuite. Nous avons pu apprécier la complexité de l'enchaînement d'opérations que rend nécessaire l'exécution d'un travail relativement simple. Il est impossible de réaliser une telle suite d'actions en ayant pour seul appui les instructions d'un manuel, pour détaillées qu'elles soient. Il est indispensable de posséder une vision d'ensemble de l'organisation de la base et des possibilités offertes par les instruments mis en jeu. Il faut adapter au but poursuivi la stratégie d'ensemble que décrivent les instructions livrées avec le produit, ne serait-ce que pour choisir les données qui doivent être exportées à l'un ou l'autre des fichiers intermédiaires. En dépit de ce que l'exemple présenté se range parmi les plus simples possibles, l'algorithme ne laisse pas d'en être complexe. Il est impossible de le simplifier. Il est impossible de l'automatiser entièrement sans le rendre inutile. Recherche signifie imprévisibilité. Tout au plus peut-on offrir au chercheur l'automatisation de brèves routines, d'outils de portée limitée, choisis en fonction de l'expérience comme constituant les points de passage les plus fréquemment utilisés. C'est au chercheur, non au programmeur, de construire la carte d'ensemble et d'ouvrir son propre chemin15.

  • 16 Jean Pierre Dedieu, « Los gobernadores de Lérida, Barcelona y Gerona en el siglo xviii », Pedralbes(...)

45La quatrième et dernière conclusion sera que tout cela en valait la peine. Cinq minutes... Imaginons le temps qu'il aurait fallu pour réaliser à la main un travail semblable. Une base de données bien rodée change totalement le rythme et par conséquent la nature de la recherche. Elle permet de vérifier en quelques minutes la validité des hypothèses les plus vastes. Nous prendrons en exemple la question du statut des Indes dans la Monarchie espagnole. On a écrit à ce propos des volumes entiers, sans trancher la question. Partons du principe que le statut d'un territoire se mesure par sa capacité d'auto-gouvernement, exprimée par sa capacité à produire ses propres élites gouvernementales, une conclusion, soit dit en passant, issue de la vue d'ensemble sur la Monarchie que permet l'ampleur des données contenues dans la base. Deux instances concentrent, au moins sur un plan symbolique, les fonctions de gouvernement : le conseil territorial en matière civile, l'épiscopat en matière ecclésiastique. Nous savons par ailleurs que ce fut une politique constante de la monarchie que de faire administrer chaque territoire par des personnes qui n'en étaient pas natives, pour brasser les élites : castillans pour administrer l'Italie, originaires des Pays-Bas pour gouverner la Catalogne, Basques et Navarrais pour régir la Castille16. Question : au xviiie siècle, combien d'évêques originaires des Indes en Espagne ? Combien de conseillers originaires des Indes au Conseil du même nom ? Réponse : aucun dans le premier cas, presque aucun dans le second. Temps nécessaire pour obtenir la réponse : quelques minutes pour une première idée, deux heures pour obtenir des chiffres précis et certifiés, toutes vérifications faites. Soit un faible effort pour obtenir avec précision une conclusion que certes l'on soupçonnait, mais par une évaluation incertaine de connaisseur à vue, stratégie qui nous a valu en histoire un nombre impressionnant d'erreurs pieusement transmises de génération en génération. Une bonne base de données rend les mêmes services à l'historien que le microscope au biologiste. Au prix d'un certain effort. Mais il n'est pas simple non plus de préparer une coupe histologique pour la glisser sous l'objectif. Et le biologiste n'en a pas pour autant renoncé à son instrument.

Inicio de página

Notas

1 Sur Fichoz, voir en dernier lieu : Jean Pierre Dedieu, «Fichoz 2011. Balance de una base de datos sobre la España moderna», Homenaje a Juan Luis Castellanos, Granada, 2012, sous presse. Nous joignons au présent travail un appendice indiquant comment accéder à Fichoz en ligne.

2 Sur Pajek : Wouter De Nooy, Andrej Mrvar et Vladimir Batagelj, Exploratory social analysis with Pajek, Cambridge, Cambridge University Press, 2005, p. 334 qui, outre une description du logiciel, explicite les concepts fondamentaux de la théorie des réseaux. On trouvera une introduction classique à celle-ci dans : Stanley Wasserman, Katherine Faust, Social network analysis: methods and applications, Cambridge, Cambridge University Press, 1994, XXXI, p. 825 ; en français, on renverra à : Alain Degenne, Michel Forsé, Les réseaux sociaux. Une analyse structurale en sociologie, Paris, Armand Colin, 1994, p. 288.

3 Fichoz est accompagné d'un fichier d'aide qui explicite les concepts sur lesquels il repose. On y trouvera des compléments à la présentation, nécessairement succincte, que nous en donnons ici.

4 L'acteur tel que nous le concevons correspond à la représentation que donne Bruno Latour de l'acteur-réseau. Les « actants » qu'il insère dans les réseaux qui configurent le social peuvent être des humains, des objets ou des discours. Une synthèse de la pensée de cet auteur dans : Bruno Latour, Reassembling the social. An introduction to actor-network-theory, Oxford, Oxford University Press, 2005, X, p. 301.

5 Lorsque les données proviennent d'une source primaire, la base donne à l'acteur le nom que mentionne celle-ci. Les noms de personne changent selon les circonstances, bien au-delà de variations orthographiques mineures : telle est la pratique des femmes mariées en France, des religieux lors de leurs vœux, des membres de la noblesse titrée dont la dénomination varie en fonction des titres qu'ils accumulent. Ces variations ont une valeur sociale, aussi la base permet-elle d'en conserver mention.

6 L'identificateur des acteurs collectifs se termine en « C », celui des objets culturels en « L ». Exemples : 00001C y 00001L.

7 Figurent également la référence de la source d'où l'on a tiré la donnée, et une date de fin d'événement.

8 Ces deux champs n'apparaissent pas sur les écrans les plus courants. L'utilisateur, pour y accéder, doit passer à un format d'écran spécifique.

9 La purge se fait automatiquement en actionnant un bouton vert intitulé « Purge » qui apparaît dans les deux fichiers intermédiaires (Fig. IV, en haut à gauche).

10 On peut le télécharger à la page web : http://pajek.imfm.si/doku.php?id=download (été 2012). L'utilisation d'un autre logiciel de traitement des réseaux modifierait évidemment ce qui suit, mais tout ce qui précède, ainsi que notre conclusion, resterait substantiellement identique. La présence de fichiers intermédiaires entre la base de données proprement dite, quelle qu'elle soit, et le logiciel de traitement, quel qu'il soit, nous paraît, en ce qui concerne le traitement des relations interindividuelles, une nécessité absolue.

11 L'étiquette d'identification est automatiquement calculée par la routine d'exportation des données des fichiers intermédiaires au fichier texte lisible par Pajek. Elle se compose de l'identificateur Fichoz de l'acteur, suivi des dix premières lettres de son nom.

12 François López, « Les livres des espagnols à l'époque moderne », Bulletin Hispanique, 1997, 99, 1, numéro monographique, p. 337.

13 Eva Velasco Moreno, La Real Academia de la Historia en el siglo xviii. Una institución de sociabilidad, Madrid, Centro de Estudios políticos y constitucionales, 2000 ; Enrique Pardo Canalís, Los registros de matrícula de la Academia de San Fernando de 1752 a 1815, Madrid, CSIC, 1967 ; Alonso Zamora Vicente, Historia de la Real Academia Española, Madrid, Espasa Calpe, 1999.

14 D'autres exemples de bénéfices induits dans : Willard Mac Carty, Humanities Computing, Basingstoke, Palgrave MacMillan, 2005, p. 73-113.

15 La complexité inhérente aux bases de données scientifique me fait envisager avec la plus grande réserve l'idée de les ouvrir au public général. Il me semble peu probable, d'une part, qu'un non-spécialiste comprenne suffisamment les données pour en tirer partie. D'autre part, l'exigence de souplesse qui caractérise la recherche exige que la base maintienne ouvertes de nombreuses options qui sont autant de portes par lesquelles des dysfonctionnements peuvent s'introduire. Ceci oblige à restreindre l'accès en écriture à une groupe restreint de spécialistes formés et habilités. La question de l'accès en lecture restant, dans notre esprit, ouverte. Dans un cadre plus vaste que celui que nous nous donnons, sur les nécessité d'adapter constamment l'instrument informatique à chaque recherche, Mac Carty (Willard), op. cit., p. 14-70.

16 Jean Pierre Dedieu, « Los gobernadores de Lérida, Barcelona y Gerona en el siglo xviii », Pedralbes. Revista d'història moderna, 1998, XVIII, 2, p. 491-507.

Inicio de página

Índice de ilustraciones

Título Fig. I. Écran principal de Fichoz. Une action
Leyenda (N. B. : pour agrandir l’illustration, cliquer sur « original »)
Créditos © Fichoz
URL http://journals.openedition.org/framespa/docannexe/image/2173/img-1.jpg
Ficheros image/jpeg, 64k
Título Fig. II. Écran principal de Fichoz. Actions relationelles
Leyenda (N. B. : pour agrandir l’illustration, cliquer sur « original »)
Créditos © Fichoz
URL http://journals.openedition.org/framespa/docannexe/image/2173/img-2.jpg
Ficheros image/jpeg, 56k
Título Fig. III. Écran « Twin actors » de Fichoz . Actions relationnelles où figurent P3 et P4
Leyenda (N. B. : pour agrandir l’illustration, cliquer sur « original »)
Créditos © Fichoz
URL http://journals.openedition.org/framespa/docannexe/image/2173/img-3.jpg
Ficheros image/jpeg, 64k
Título Fig. IV. Écran principal de PRelations
Leyenda (N. B. : pour agrandir l’illustration, cliquer sur « original »)
Créditos © Fichoz
URL http://journals.openedition.org/framespa/docannexe/image/2173/img-4.jpg
Ficheros image/jpeg, 128k
Título Fig. V. Écran principal de PPoints
Leyenda (N. B. : pour agrandir l’illustration, cliquer sur « original »)
Créditos © Fichoz
URL http://journals.openedition.org/framespa/docannexe/image/2173/img-5.jpg
Ficheros image/jpeg, 120k
Título Fig VI. Échantillon d'un fichier .txt lisible par Pajek
Leyenda (N. B. : pour agrandir l’illustration, cliquer sur « original »)
Créditos © Fichoz
URL http://journals.openedition.org/framespa/docannexe/image/2173/img-6.jpg
Ficheros image/jpeg, 40k
Título Fig. VII. Un enregistrement de Fichoz, format long, montrant le champ de codage permanent
Leyenda (N. B. : pour agrandir l’illustration, cliquer sur « original »)
Créditos © Fichoz
URL http://journals.openedition.org/framespa/docannexe/image/2173/img-7.jpg
Ficheros image/jpeg, 48k
Título Fig. VIII. Exemples de codes permanents concernant des académiciens
Leyenda (N. B. : pour agrandir l’illustration, cliquer sur « original »)
Créditos © Fichoz
URL http://journals.openedition.org/framespa/docannexe/image/2173/img-8.jpg
Ficheros image/jpeg, 72k
Título Fig. IX. Écran pour le choix du code dans la routine de codage au vol
Leyenda (N. B. : pour agrandir l’illustration, cliquer sur « original »)
Créditos © Fichoz
URL http://journals.openedition.org/framespa/docannexe/image/2173/img-9.png
Ficheros image/png, 24k
Título Fig X. Enregistrement d'un événement, format étendu montrant les codes au vol
Leyenda (N. B. : pour agrandir l’illustration, cliquer sur « original »)
Créditos © Fichoz
URL http://journals.openedition.org/framespa/docannexe/image/2173/img-10.jpg
Ficheros image/jpeg, 48k
Título Fig. XI. Écran principal du Dictionnaire des acteurs
Leyenda (N. B. : pour agrandir l’illustration, cliquer sur « original »)
Créditos © Fichoz
URL http://journals.openedition.org/framespa/docannexe/image/2173/img-11.jpg
Ficheros image/jpeg, 108k
Título Fig. XII. Identifiants Fichoz des Académies
Leyenda (N. B. : pour agrandir l’illustration, cliquer sur « original »)
Créditos © Fichoz
URL http://journals.openedition.org/framespa/docannexe/image/2173/img-12.jpg
Ficheros image/jpeg, 56k
Título Fig. XIII. PRelations
Leyenda (N. B. : pour agrandir l’illustration, cliquer sur « original »)
Créditos © Fichoz
URL http://journals.openedition.org/framespa/docannexe/image/2173/img-13.jpg
Ficheros image/jpeg, 118k
Título Fig. XIV. Écran principal de Pajek
Leyenda (N. B. : pour agrandir l’illustration, cliquer sur « original »)
Créditos © Fichoz
URL http://journals.openedition.org/framespa/docannexe/image/2173/img-14.png
Ficheros image/png, 56k
Título Fig. XV. Premier graphe de Pajek, une fois ordonné par la routine Kamada Kawai
Leyenda (N. B. : pour agrandir l’illustration, cliquer sur « original »)
Créditos © Fichoz
URL http://journals.openedition.org/framespa/docannexe/image/2173/img-15.png
Ficheros image/png, 180k
Título Fig. XVI. Graphe de partition
Leyenda (N. B. : pour agrandir l’illustration, cliquer sur « original »)
Créditos © Fichoz
URL http://journals.openedition.org/framespa/docannexe/image/2173/img-16.png
Ficheros image/png, 172k
Título Fig. XVII. Académies et académiciens. Résultat final
Leyenda (N. B. : pour agrandir l’illustration, cliquer sur « original »)
Créditos © Fichoz
URL http://journals.openedition.org/framespa/docannexe/image/2173/img-17.png
Ficheros image/png, 124k
Inicio de página

Para citar este artículo

Referencia electrónica

Jean-Pierre Dedieu y Álvaro Chaparro, «De la base au réseau. L'apport des bases de données à l'étude des réseaux»Les Cahiers de Framespa [En línea], 12 | 2013, Publicado el 31 mayo 2018, consultado el 28 marzo 2024. URL: http://journals.openedition.org/framespa/2173; DOI: https://doi.org/10.4000/framespa.2173

Inicio de página

Autores

Jean-Pierre Dedieu

Directeur de Recherches du CNRS, CNRS, Laboratoire de Recherches Historiques Rhônes Alpes – LARHRA.
jean-pierre.dedieu@ish-lyon.cnrs.fr

Artículos del mismo autor

Álvaro Chaparro

Chercheur post-doctorant, Casa de Velázquez, Laboratoire de Recherches Historiques Rhônes Alpes – LARHRA.
achaparrosainz@gmail.com

Inicio de página

Derechos de autor

CC-BY-NC-ND-4.0

Únicamente el texto se puede utilizar bajo licencia CC BY-NC-ND 4.0. Salvo indicación contraria, los demás elementos (ilustraciones, archivos adicionales importados) son "Todos los derechos reservados".

Inicio de página
Buscar en OpenEdition Search

Se le redirigirá a OpenEdition Search