La disponibilité de bases de données vastes, harmonisées, de qualité et pérennes ouvre de nouvelles perspectives de recherche en sciences humaines et sociales (SHS). La collaboration entre les SHS et les sciences et technologies de l’information et de la communication (STIC) crée les conditions pour la réalisation d’une big data revolutionCette collaboration doit s’appuyer aussi sur un dialogue avec les archivistes chargés de la conservation des sources, mais ce thème ne peut être développé ici, par souci de brièveté. Voir l’article de Pascal Gallien et Angelo Riva, « Valoriser les “actifs” archivistiques détenus par le CAEF : le projet de l’EQUIPEX “Données financières historiques” (DFIH) », texte soumis au Comité scientifique du colloque de l’Association des archivistes français, Meta/morphoses. Les archives, bouillons de culture numérique (30 mars-1er avril 2016).↩︎ (Manning 2013 ; Casson et Hashimzade 2013 ; Kitchin 2014).

L’équipement d’excellence « Données financières historiques » (EQUIPEX DFIH.) se propose de construire une base de données contenant les informations relatives aux actifs cotés à la Bourse de Paris (titres, taux de change, matières précieuses) et à leurs émetteurs de 1795 à 1976La première cote officielle de la Bourse de Paris retrouvée dans les archives de la Compagnie des agents de change remonte au 23 septembre 1795. La base s’arrête au 31 décembre 1976, car à partir du 2 janvier 1977, la base Eurofidai (Institut Européen des données financières) contient les prix des actifs cotées à la Bourse de Paris.↩︎. L’équipement contient les prix bimensuels (comptant, terme, reports et options), les dividendes et les autres informations (comme les opérations sur titres) nécessaires à l’établissement de séries de prix homogènes dans le tempsLes prix bruts doivent être corrigés à l’occasion d’opérations sur titres tels que le paiement de dividendes, les augmentations de capital ou encore la division et le regroupement de titres, pour éliminer l’effet mécanique de ces opérations sur les prix et assurer ainsi leur comparabilité dans le temps.↩︎. Il recense en outre l’historique juridique de la société (date de fondation et évolution du statut juridique), les principales règles de gouvernance, le siège, les administrateurs, des bilans simplifiés, etc. ainsi que des informations sur les émetteurs publics (par exemple la situation budgétaire et les garanties éventuelles). Les données seront mises gratuitement à la disposition des chercheurs en 2020 via la très grande infrastructure de recherche (TGIR) PROGEDO.

Pourtant, l’ambition de ce projet est plus large. L’équipement DFIH est une base de données « ouverte ». Il vise initialement à inclure les autres bourses françaisesIl s’agit du marché non officiel de Paris, qu’il est d’usage d’appeler la Coulisse, et des bourses régionales (Bordeaux, Lille, Lyon, Marseille, Nancy, Nantes et Toulouse).↩︎, mais pendant la phase de conception du modèle de données, tous les efforts ont été faits pour prévoir des évolutions possibles de la base. La flexibilité des bases de données relationnelles permet d’espérer que des évolutions non anticipées (par exemple l’intégration de données prosopographiques sur les salariés d’une entreprise) puissent trouver leur place au sein de l’équipement.

La construction de la base se fonde sur deux sources sérielles principales :

• les cotes officielles de la Bourse de Paris publiant les informations sur les actifs ;
• les annuaires boursiers officiels et privés publiant les renseignements sur les émetteursCes collections appartiennent aux archives de la Compagnie des agents de change près la Bourse de Paris, conservées au CAEF (Lagneau-Ymonet et Riva 2010 ; Lagneau-Ymonet, Rezaee, et Riva 2014). Une collection des cotes officielles est conservée à la Banque de France. Des informations publiées sur d’autres sources telles que les décisions et avis de la Chambre syndicale de la Compagnie des agents de change complètent la base.↩︎.

La stratégie de capture des données dépend de plusieurs variables principalement liées aux sources et à l’état de l’art de la technologie. L’accessibilité des sources, la qualité des imprimés, l’organisation graphique des informations et la fréquence des changements de format (donc le type d’information contenue) sont les éléments à prendre en compte. D’autre part, c’est principalement l’état de l’art de la technologie qui détermine les coûts relatifs des différentes solutions de capture possibles. Il faut arbitrer entre deux types de solutions : soit le recours à des techniques éprouvées, mais caractérisées par un « coût unitaire » élevé ; soit des investissements en faveur d’innovations qui soient susceptibles de repousser la frontière technologique afin de pouvoir réduire le prix de revient des données.

Dans le cadre de l’EQUIPEX, les contraintes et les opportunités rencontrées ont conduit à mettre en place deux technologies de capture de données requérant la numérisation des sources. Les sources numérisées constituent un bien public in se et un exceptionnel instrument de documentation de la base. Ces sources ont par conséquent vocation à être mises en ligne via une infrastructure comme la TGIR Huma-Num. Les deux technologies adoptées sont les suivantes : d’une part, la saisie manuelle dans un environnement numérique ad hoc des informations publiées sur les cotes boursières jusqu’en 1950 et d’autre part, le traitement semi-automatique des cotes d’après 1950 et des annuaires par un logiciel spécifique fondé sur la reconnaissance optique des caractères (ROCEn anglais Optical character recognition (OCR), également appelée « océrisation ».↩︎) et sur l’intelligence artificielle. La nécessité de développer un logiciel spécifique a été dictée par trois ordres de besoins : d’abord, l’échec des meilleurs logiciels commerciaux de reconnaissance optique ; ensuite, la nécessité de disposer d’un logiciel capable d’apprendre de ses erreurs ; enfin, le recours au traitement semi-automatique des données pour les ventiler dans la base de données.

L’EQUIPEX a réalisé ce logiciel en partenariat avec un prestataire privé qui proposait par ailleurs une infrastructure robuste et efficace d’analyse et de traitement des données issues de la ROC, deux étapes nécessaires pour la production d’une quantité importante de données. En prenant en compte les coûts directs et indirects, ce logiciel offre des gains par rapport à la saisie manuelle dans un environnement numérique. Pourtant, son fonctionnement demande encore un important travail humain avant et pendant son déploiement. Dans un premier temps, il a été nécessaire de créer, au sein de la base, une structure informationnelle permettant au logiciel de ventiler correctement les données lors de leur versement. Par la suite, le flux des données issues de la ROC doit être validé par des opérateurs. Or, le travail humain requis pour la constitution de bases de données à partir de sources anciennes, et notamment tabulaires, demeure un verrou qui rend la production coûteuse. La recherche qui s’appuie sur les humanités numériques (HN) comme terrain de rencontre entre SHS et STIC (Clavert et Noiret 2013) est ainsi appelée à œuvrer pour réaliser la big data revolution, à savoir le développement d’outils conçus pour produire, à partir de sources historiques, des masses importantes de données à un coût raisonnable.

La construction de l’architecture de la base de données

Organisée suivant le modèle relationnel, la base de données, gérée par le système Oracle, consiste en un ensemble de tables, reliées entre elles par des relations et correspondant chacune à une unité de stockage. À ce jour, la base de données regroupe près de 150 tables. L’information y est stockée en ligne (on parle alors de tuple) et en colonne, appelée attribut. Une relation entre deux tables est définie à partir d’une clé primaire, c’est-à-dire à partir d’un attribut ou d’une combinaison d’attributs. La longue période envisagée ici nécessite de recourir à une base de données non pas statique mais dynamique où toutes les informations sont liées au temps. Chaque information est donc définie et valide à l’intérieur d’une période de temps donnée, avec une date de début et une date de fin. Les relations entre tables ne sont pas toutes gérées de la même manière. Dans certains cas, la clé primaire de l’une des tables est simplement ajoutée dans l’autre. On appelle alors cette clé, clé étrangère. Dans d’autres cas, une table de jointure est créée avec les deux clefs primaires des tables à relier.

Une fois les principales entités définies, plusieurs contraintes fondamentales ont guidé l’élaboration du modèle conceptuel des données.

• La première était de conserver les caractéristiques des sources historiques, afin d’en rendre compte le plus fidèlement possible et de suivre leur évolution au cours des deux siècles ;
• La deuxième était de permettre aux utilisateurs d’exploiter la base de façon efficace et d’effectuer facilement des requêtes SQL (Structured Query LanguageLes requêtes SQL permettent d’insérer, de modifier et de sélectionner des données dans une base de données relationnelle grâce au langage de programmation éponyme.↩︎) couvrant la période étudiée ;
• Il était également important que la base de données finale puisse être compatible avec d’autres bases de données déjà existantes ou futures, notamment en Europe, par exemple les bases SCOB (Studiecentrum voor Onderneming en Beurs) en Belgique ou Eurofidai en France. En effet, la fusion de ces bases de données est envisagée à terme ;
• Enfin, il a fallu adapter la base de données aux contraintes découlant des techniques de capture des données.

Une fois le modèle conceptuel de la base défini, il a été possible de concevoir le modèle logique des données. Pour cela, nous avons eu recours à l’expertise du centre de recherches SCOB à Anvers qui maintient une base de données contenant les données historiques des Bourses de Bruxelles et d’Anvers. L’une des tâches les plus importantes a alors été d’adapter la base SCOB au cas spécifique français et aux contraintes de production des données. Ainsi, avant de commencer à importer des données dans la base, l’ensemble des possibilités rencontrées dans les sources historiques françaises devait être envisagé afin de ne pas être bloqué ultérieurement. Par exemple, l’une des spécificités de la base de données SCOB est de ne prendre en compte que les prix au comptant et de laisser hors du champ de la base les informations concernant les opérations à terme. Étant donné l’ampleur et l’importance de ces opérations dans le cas français – même pour un marché régional comme la Bourse des valeurs mobilières de Lyon, les opérations à terme représentent jusqu’à 90% du volume total des transactions au cours de la période traitée –, nous avons décidé de les inclure dans la base de données française. Sans entrer dans le détail de ces opérations financières, signalons simplement qu’elles peuvent être de deux types, fermes ou à option, et être effectuées à plusieurs échéances, ce qui engendre par conséquent un grand nombre de cas possibles. Nous avons donc opté pour la création de nouvelles tables et de nouvelles relations pour pouvoir en tenir compte. La base de données comporte également des tables qui facilitent le processus de production de données. C’est le cas par exemple de celles créées dans le but de permettre une double saisie.

Court extrait du modèle conceptuel de la base de données

Il s’agit des relations entre les tables destinées à générer une reproduction fidèle de la cote officielle pour une date déterminée par l’utilisateur, étape indispensable pour l’insertion des données journalières, comme nous le verrons plus loin.

Les trois tables « Sector », « Sector_Child » et « Sector_Next » permettent de lier les secteurs d’activités (tels que « Banques », « Électricité », etc.) entre eux et donc de reproduire la structure de la cote officielle. La table « Notation » permet, quant à elle, d’associer à chaque instant un titre de la base à un secteur particulier de la cote officielle. Par exemple, c’est dans cette table « Notation » que les actions émises par la Compagnie des Chemins de fer de la Drôme sont tout d’abord liées au secteur « Valeurs Françaises - Actions », avant de l’être à « Chemins de Fer » lorsque cette rubrique apparaît sur la cote officielle.

fr modèle conceptuel, base de données

Afin de minimiser le coût, deux technologies de capture de données ont été mises en place. D’une part, la saisie manuelle dans un environnement numérique ad hoc construit sur la base de masques de saisie ; d’autre part, le traitement des sources par un logiciel spécifique.

La saisie manuelle dans un environnement numérique ad hoc

Schématiquement, elle a été impérative pour :

• les données nécessaires à la construction de la structure informationnelle (types d’objets manipulés, listes fermées de secteurs et de valeurs, relations entre objets, notamment entre les titres et leurs émetteurs) ;
• les données publiées sur les cotes officielles jusqu’en 1950, dont la qualité et l’organisation fluctuantes rendent l’automatisation inefficace ou non rentable.

La saisie des données et l’établissement de la structure informationnelle demandent un niveau élevé d’interprétation, donc d’expertise et de connaissance des sources. Il s’agit notamment de créer le système permettant à la base de reproduire, pour chaque jour de cotation, la cote officielle telle qu’elle figure sur la source. La reproduction de la cote officielle, aussi banale qu’elle puisse paraître, est en réalité une opération complexe. Elle demande non seulement de suivre les titres dans le temps malgré les changements des noms, des secteurs de cotations (dont le nombre et l’intitulé varient fréquemment) et des caractères techniquesPar exemple, une « conversion », à savoir une réduction du taux d’intérêt sur un emprunt obligataire. La réduction est associée au rachat, de la part de l’émetteur, des titres détenus par les investisseurs refusant la réduction du taux.↩︎, mais aussi de relier le titre au bon émetteur en dépit d’évolutions parfois radicales, comme la disparition d’un État, la fusion entre deux entreprises ou encore le rachat de l’une par l’autre. La mise en place de masques de saisie avancés facilite la saisie de ces informations qu’on a confiée à des opérateurs experts comme des doctorants et des postdoctorants. Ces masques, codés en Java, permettent à l’opérateur expert d’interagir facilement avec la base.

En revanche, une fois la structure informationnelle achevée, la saisie des données publiées sur les cotes requiert un niveau d’interprétation moindre. Des assistants de recherche peuvent l’organiser et la réaliser en interne ou la déléguer à une entreprise spécialisée dans la saisie de données. Les contraintes relatives à l’espace nécessaire pour l’installation et l’encadrement de nombreux opérateurs de saisie nous ont conduit à déléguer le travail à une entreprise spécialisée. La collaboration avec cette entreprise a commencé par une adaptation du modèle logique des données, afin de prendre en compte les spécificités de leurs procédés de production, dont la plus importante est la double saisie. Afin de minimiser les erreurs de saisie, deux opérateurs saisissent en parallèle les mêmes données. En cas de divergence entre ces deux saisies, un troisième opérateur tranche. Pour assurer une productivité satisfaisante, on a conçu des masques de saisie simplifiés. On a spécialisé les équipes d’opérateurs par type de données (prix au comptant, prix à terme, dividendes), et affecté à chaque type un masque de saisie ne reportant que les champs utiles. Par exemple, les taxes payées par les investisseurs sur les intérêts et les dividendes apparaissent sur la cote officielle au cours de l’entre-deux-guerres. En conséquence, on a créé un masque ne reportant que le champ « dividende brut » pour la période antérieure à 1920 tandis qu’un masque comportant la distinction entre « dividende brut », « dividende net » et « taxe » a été implémenté pour la période suivante.

L’opérateur pouvait ainsi sélectionner, au sein du masque, le titre auquel associer les données saisies, en comparant l’image de la cote insérée directement dans le masque et l’arborescence graphique traduisant la structure informationnelle de la base. Cette possibilité, jointe à la spécialisation des équipes d’opérateurs, réduit le niveau d’interprétation des sources nécessaire à la saisie, mais elle ne l’élimine pas. C’est pourquoi les opérateurs ont bénéficié d’une formation de trois semaines par des opérateurs experts (le superviseur scientifique du projet et un doctorant en histoire financière) et pouvaient s’appuyer sur un manuel de guide à la saisie et des tutoriels vidéo. Ces derniers présentent les règles générales de saisie. Le manuel détaille, quant à lui, les cas particuliers, très nombreux, que les opérateurs peuvent retrouver sur la cote. Il s’agit par exemple de cas rares, d’exceptions, ou de données susceptibles d’être interprétées différemment selon les époques ou selon la partie du texte où elles sont publiées. Ainsi, un prix de « 20 » peut être lu comme 20 centimes, 20 francs ou encore 20%, selon la période de publication et le type de titre échangé. Malgré tous les efforts accomplis, l’entreprise spécialisée avait parfois besoin d’une assistance dans l’interprétation des données. Pour cette raison, nous avons mis en place une interface en ligne de questions/réponses permettant de charger des images ou toute autre documentation nécessaire pour accompagner les réponses aux questions.

Une fois les données importées, l’entreprise les a envoyées à une équipe chargée d’en vérifier la qualité. Cette vérification était à la fois informatique et manuelle. La vérification informatique reposait sur des règles de validation. Tout d’abord, nous avons établi un ensemble de paramètres que les données se devaient de respecter selon la connaissance acquise du comportement des actifs cotés. Les paramètres étaient principalement fondés sur les volatilités intrajournalières et interjournalières des prix et étaient adaptés à chaque période analysée.

Ensuite, ces paramètres ont été traduits en scripts SQL qui analysaient automatiquement les données et effectuaient l’extraction des prix violant les règles établies. Ces prix « aberrants » ne provenaient pas nécessairement d’erreurs des opérateurs de saisie, mais pouvaient résulter de périodes de haute volatilité ou de coquilles présentes sur les cotes officielles. Les assistants de recherche les ont systématiquement vérifiés. Des vérifications supplémentaires ont enfin eu lieu sur des échantillons aléatoires représentant entre 10% et 20% des données.

Pour procéder à ces vérifications manuelles, on a développé des applications ad hoc en java directement installées sur la base Oracle. Ces applications fournissent deux avantages principaux :

• premièrement, elles permettent d’explorer les données facilement grâce aux mêmes principes que les masques de saisie Java pour les utilisateurs experts ;
• deuxièmement, l’application prend directement en compte les corrections faites, et facilite ainsi leur importation dans la base avec les autres données à la fin du travail de vérification.

Le processus de saisie de données a demandé des temps de traitement différents selon les périodes traitées et le type de données insérées. Ainsi, la quantité d’informations à saisir pour la première partie du XIX^e siècle était relativement réduite, mais nécessitait davantage d’interprétation du fait de la moins grande standardisation des sources. À l’inverse, à la suite du développement du marché boursier et de l’augmentation du nombre de titres cotés au cours de la Belle Époque, les données demandaient davantage de temps de saisie, alors que l’homogénéisation des sources facilitait l’interprétation. En général, on peut estimer que la saisie d’un « paquet de données » – une dizaine d’années environ en début de période, contre une seule année en fin de période – a exigé environ une semaine de travail pour un groupe de cinq personnes en ce qui concerne le début de la période, pour arriver à deux semaines quant aux données portant sur le début du XX^e siècle. La vérification de ces mêmes données a demandé un jour-homme pour le début du XIX^e siècle et deux jours-hommes pour le début du XX^e siècle.

L’évolution de la qualité et du contenu des sources – avec notamment l’apparition des codes SICOVAM (Société Interprofessionnelle pour la Compensation des Valeurs MobilièresCette société est créée à la fin de l’année 1949 pour prendre la suite de la Caisse Centrale de Dépôts. Le code attribué par la SICOVAM à chaque titre est composé de 4 à 6 chiffres et l’identifie de façon unique.↩︎) – a permis d’abandonner la saisie manuelle à partir des cotes publiées en 1950 et d’utiliser une technologie fondée sur la ROC et l’intelligence artificielle.

Conception et déploiement du logiciel spécifique

La saisie semi-automatique concerne donc l’exploitation de deux types de sources : les cotes officielles à partir de 1950 et les annuaires des valeurs négociées en Bourse. Les principes du traitement semi-automatique des données sont les mêmes quel que soit le type de source. Pour pouvoir appliquer la technologie de ROC au traitement de ces deux sources, nous avons procédé en plusieurs étapes. Après la numérisation des sources, nous avons développé un logiciel spécifique qui utilise la ROC pour repérer et reconnaître l’information sur la source numérisée et un système d’intelligence artificielle pour la relier à l’entité correspondante (par exemple l’émetteur ou le titre) déjà stockée dans la base et finalement l’insérer dans la table dédiée. Un tel procédé nécessite un important travail en amont pour concevoir et développer le logiciel. En effet, l’éditeur du logiciel a besoin de deux types d’information pour écrire son code : d’une part, une description fine de la source, afin de savoir où sont physiquement situées les informations sur celle-ci ; d’autre part, les tables de la base où on doit insérer ces informations et les liens qu’on doit créer entre les données.

Il est nécessaire de clarifier ces éléments dans un document unique avant de commencer l’écriture du code logiciel. Les chercheurs chargés de rédiger un tel document doivent donc avoir une bonne connaissance des sources et du modèle conceptuel de la base. Ils doivent ensuite s’assurer de la bonne compréhension du document de la part des informaticiens chargés du développement et continuer à dialoguer avec ces derniers pendant toute la phase de développement et de test du logiciel. L’ensemble de ce processus, de la rédaction des spécifications à l’utilisation du logiciel, est un travail de longue haleine : étant donné la complexité des sources et leur évolution dans le temps, il a fallu prévoir une année de travail en amont de la production pour s’assurer d’une saisie correcte des informations et de leur bonne ventilation dans la base de données.

Des opérateurs doivent néanmoins valider et éventuellement corriger, à chaque étape du processus, le flux de données, une fois capturé par le logiciel, avant sa ventilation dans la base. Cette validation/correction se fait par des inter-faces conçues ad hoc dans le but d’optimiser le traitement.

Les cotes officielles

Les cotes officielles sont traitées par ce logiciel spécifique à partir de 1950. En effet, jusqu’à cette date, les caractéristiques des sources rendent l’usage de cette technologie peu efficace. Tout d’abord, la qualité initiale de l’impression des sources ne permet pas une reconnaissance optimale des caractères. Ensuite, à partir de 1950, on associe le code SICOVAM, un identifiant unique, à chaque titre admis à la cote. Inséré manuellement, il facilite l’association des informations capturées à celles déjà présentes dans la base et permet de résoudre dans une certaine mesure le casse-tête des nombreux changements de désignation des titres. Enfin, la structure de la source se stabilise après la Deuxième Guerre mondiale. Chaque nouveau format de la source implique un travail de spécification et de développement informatique ad hoc ; les changements fréquents rendent donc l’utilisation du logiciel peu économique.

La capture et la ventilation automatisées des données dans la base passent par plusieurs étapes. Tout d’abord le logiciel lit la source pour reconnaître la structure tabulaire contenant les données et pour reconstruire les lignes de cotation : c’est pourquoi tout changement dans cette structure demande une adaptation du logiciel. Une fois qu’un opérateur a validé la structure et l’alignement, le logiciel associe le titre détecté sur la source au même titre déjà existant dans la base en se fondant sur un algorithme d’appariement des noms et sur le code SICOVAM, utilisé comme variable de contrôle. Cette association requiert néanmoins l’intervention d’un opérateur pour lever les ambiguïtés signalées par le logiciel. On calcule la fiabilité de l’appariement sur la base de la similarité entre les chaînes de caractères (nom et code) lues sur la source et celles déjà présentes dans la base. Si le taux de fiabilité ne dépasse pas un seuil paramétrable par l’utilisateur, le logiciel soumet une question à l’opérateur en lui présentant une liste de candidats à l’appariement tirés de la base et classés par ordre décroissant de similarité. L’opérateur peut :

• 1. valider l’association avec le premier titre de la liste, proposée par défaut par le logiciel ;
• 2. créer une association avec un autre titre de la liste ;
• 3. créer une association avec un titre absent de la liste mais présent dans la base ou avec un titre nouvellement créé en cas d’erreur ou d’omission.

Enfin, le logiciel importe et ventile dans la base, en créant automatiquement les relations opportunes, les données qui se trouvent sur la même ligne du titre apparié.

Les annuaires

La qualité et la structure des annuaires permettent d’en traiter la série complète à l’aide d’un logiciel spécifique. Deux types d’annuaires sont disponibles : les annuaires dits officiels, car publiés par la Compagnie des agents de change de Paris et les annuaires d’éditeurs privés, dont le plus connu est l’Annuaire Desfossés. Ces annuaires, officiels et privés, étaient publiés sous forme de livres reliés et imprimés sur un papier d’assez bonne qualité, contrairement aux cotes. La structure, c’est-à-dire la disposition de l’information sur la source, est très stable dans le temps. Pourtant, le travail de spécification des informations publiées, préalable au développement logiciel, s’avère ardu car ces informations sont de nature différente. Les annuaires sont organisés par émetteur : chaque entité, publique ou privée, ayant émis des titres sur le marché officiel de la Bourse de Paris y fait l’objet d’une description détaillée. Toutes les informations considérées comme utiles pour les investisseurs y figurent. Il faut donc prévoir un traitement spécifique pour chacune d’entre elles. Il convient, tout d’abord, de trouver des repères codables pour délimiter la zone de texte, de déterminer des séparateurs permettant à l’outil d’extraire de la zone les informations utiles et de repérer les modalités récurrentes de ces informations pour les insérer préalablement dans la base et les associer à un identifiant. Il s’agit de fournir au logiciel de ROC un dictionnaire de référence et de lui permettre d’établir les relations utiles, une fois qu’on a créé l’association entre la modalité lue et celle présente dans la base.

Le travail de saisie semi-automatique s’effectue alors en trois étapes. La première consiste simplement à exclure toutes les pages de l’annuaire numérisé qui ne sont pas directement utiles à la constitution de la base de données (par exemple la publicité ou la table des matières). La deuxième étape, commune à tout type de travail avec ROC, est plus longue : il s’agit, d’une part, de s’assurer que le logiciel a bien pris en considération toutes les zones du texte et les tableaux nécessaires et, d’autre part, a « typé » correctement les blocs et les tableaux puisque chacun fait l’objet d’un traitement spécifique. Par exemple, on a saisi toutes les modalités possibles de statut juridique d’une société (société anonyme, société en nom collectif, etc.) dans une table de la base afin de fournir un dictionnaire de référence à la ROC, et on a attribué des identifiants uniques à ces modalités pour permettre au logiciel de créer automatiquement les relations nécessaires. Si la zone de texte concernant l’évolution du statut juridique de la société est typée « administrateurs », le logiciel cherchera à associer les formes juridiques prises par l’entreprise avec les modalités relatives aux postes des administrateurs (président, directeur général, etc.) stockées dans une autre table. Un code couleur est généralement utilisé pour distinguer rapidement les blocs et pouvoir les corriger si nécessaire. L’étape suivante, celle des corrections et des validations, est la plus longue du traitement. Ici, l’objectif est double. Il faut d’abord valider l’association entre l’entité lue par le logiciel sur la source et son correspondant dans la base. Comme pour les cotes officielles, l’association est fondée sur un algorithme de distance similaire à celui appliqué aux titres des cotes. Le but est de permettre au logiciel de ventiler de façon adéquate dans la base les informations capturées sur la source. Il s’agit ensuite de corriger éventuellement les informations mal ou non lues par l’outil de ROC et de les rattacher à l’émetteur. L’opérateur vérifie notamment les informations sur lesquelles le logiciel a émis un doute quant à la reconnaissance. Lorsque l’opérateur a validé les différentes zones, le traitement de l’émetteur en question est terminé et les données sont automatiquement insérées dans la base. Le processus de saisie semi-automatique, qu’une équipe constituée en moyenne par deux doctorants et trois assistants de recherche effectue, nous a demandé environ un mois pour chaque annuaire.

Tant pour le traitement de la cote officielle que pour celui des annuaires, un certain nombre de règles de validation sont implémentées dans le logiciel afin de procéder à une première vérification des données avant insertion. Ainsi, on effectue des contrôles dans le but de corriger les résultats bruts de la ROC, à l’aide d’une application qui regroupe les ambiguïtés trouvées dans le texte pour pouvoir le corriger en une seule fois. On met également en place des contrôles après insertion. Les requêtes SQL servent ainsi à faire ressortir les écarts d’information entre la source et les données insérées dans la base. Pour la cote officielle, il s’agit, comme pour la saisie manuelle, de repérer les données « aberrantes ». Concernant les annuaires, nous tirons parti du fait que certains émetteurs sont décrits dans plusieurs volumes (quand ils ont des titres cotés en réalité). Il est alors possible de contrôler que les informations constantes, comme la date de constitution de la société, sont bien identiques dans chacun des annuaires.


La construction de bases de données est l’un des faits massifs du courant des HN. Les avancées technologiques permettent d’aborder la construction de bases de données d’envergure. L’EQUIPEX DFIH a eu les moyens d’investir dans cette recherche et de mettre en place des outils innovants de capture de données. Pourtant, l’important et indispensable travail humain à fournir pour la constitution de bases de données à partir de sources anciennes, et notamment tabulaires, rend la production coûteuse.

Une fois les données insérées et vérifiées, elles pourront être utilisées pour mener des recherches, non seulement en économie, mais également dans les différents domaines des sciences sociales. Par exemple, trois des auteurs – Elisa Grandi, Raphaël Hekimian et Angelo Riva – travaillent actuellement sur un article visant à évaluer les répercussions des interlocking directorates sur la performance boursière des établissements bancaires cotés à la Bourse de Paris entre 1883 et 1913 (Grandi, Hekimian, et Riva 2016). Pour cela, ils tirent des annuaires des données sur les conseils d’administration des banques, en y appliquant l’analyse des réseaux sociaux, ainsi que les données relatives aux bilans de ces mêmes banques afin d’en évaluer la liquidité et la solvabilité. On teste alors les répercussions de ces variables sur les cours des actions, issus du traitement des cotes officielles, à l’aide de l’économétrie des données de panel, permettant d’exploiter simultanément les dimensions individuelles et temporelles des données DFIH.

La recherche en HN, comme terrain de rencontre entre SHS et STIC, est ainsi appelée à œuvrer pour réaliser la big data revolution, c’est-à-dire le développement d’outils permettant de produire des masses importantes de données à un coût raisonnable. La multiplication des projets visant à construire des bases de données à partir de sources historiques nous amène à penser que la fédération de ces efforts pourrait générer d’importantes économies d’échelle dans la recherche et le développement de ces outils. La création d’une plate-forme nationale consacrée à la question de la production de données à partir de sources anciennes et ralliant chercheurs en STIC et en SHS, pourrait mettre à la disposition de la communauté scientifique des compétences, des moyens et des technologies dont le secteur privé bénéficierait également.

Contenus additionnels

Jérémy Ducros

Jérémy Ducros est ancien élève de l’École normale supérieure de Cachan et prépare une thèse de doctorat en économie à l’EHESS et à l’École d’économie de Paris sous la direction de P.-C. Hautcoeur. Ses recherches portent sur le rôle des marchés boursiers régionaux en France aux XIX^e et XX^e siècles. Il est également assistant d’enseignement au sein de l’Institut Paul Bairoch d’histoire économique à l’Université de Genève.

Elisa Grandi

Elisa Grandi est doctorante en histoire économique et histoire de l’Amérique latine à l’Université Paris Diderot , en cotutelle avec l’Université de Bologne. Ses recherches portent sur les prêts et programmes de développement de la Banque Mondiale en Amérique latine et en Europe, après la Seconde Guerre mondiale. Elle travaille au sein de l’Équipex DFIH depuis 2012.

Pierre-Cyrille Hautcœur

Pierre-Cyrille Hautcoeur est économiste et historien à l’EHESS et à l’École d’économie de Paris (laboratoire Paris-Jourdan Sciences Economiques, UMR 8545) . Ses recherches portent sur l’histoire financière et monétaire contemporaine, en particulier sur les crises financières et monétaires et sur les marchés financiers. Il est le directeur scientifique de l’Équipex DFIH.

Raphaël Hekimian

Raphaël Hekimian est doctorant en histoire financière (Université Nanterre Paris Ouest et École d’économie de Paris), il travaille sur l’impact des crises financières internationales sur la bourse de Paris pendant l’entre-deux-guerres. Il travaille au sein de l’Équipex DFIH depuis 2012.

Angelo Riva

Angelo Riva est enseignant-chercheur qualifié en économie, gestion et histoire contemporaine (laboratoire Paris-Jourdan Sciences Economiques, UMR 8545). Il consacre ses recherches à l’évolution des systèmes financiers en longue période. Il est le coordinateur scientifique de l’Équipex DFIH.

Stefano Ungaro

Stefano Ungaro est actuellement en thèse de doctorat en économie à l’EHESS et à l’École d’économie de Paris, sous la direction de P.-C. Hautcoeur. Ses recherches portent sur les marchés monétaires et financiers en France entre 1870 et 1914. Il collabore avec l’Équipex DFIH depuis 2011.