1Le programme « Ports et technologies de l’information et la communication » de l’Agence nationale de la recherche (ANR Portic, 2019-2023)1 promeut une meilleure compréhension des logiques de navigation en France et de la structuration des marchés au xviiie siècle. Pour ce faire, l’équipe de recherche mobilise deux corpus de données, l’un issu de la balance du commerce française2, l’autre issu de plusieurs sources sur la navigation des ports français, dont il sera plus spécifiquement question dans cet article, qui sont collectées dans la base de données Navigocorpus, depuis le programme « Navigocorpus : corpus des itinéraires des navires de commerce, xviie-xixe s. » (ANR Navigocorpus, 2007-2011)3. Ce corpus nous permet de connaître (avec des lacunes) les entrées ou les sorties de navires d’environ une centaine de ports le long des côtes françaises, du Ponant au Levant, notamment en 1787. « Portic » vise la mise à disposition des données, qui engage la responsabilité des historiens de l’équipe pour produire :
- une transcription des informations livrées par les sources manuscrites avec une marge d’erreur minimale ;
- des métadonnées permettant de comprendre finement le sens des sources retranscrites ;
- des méta-catégories facilitant la mise en œuvre de croisement et de visualisations des données.
2L’ambition principale de « Portic » vise à la reconstitution des trajectoires de chacun de ces navires au fil de leurs déplacements dans le temps et dans l’espace. L’apport en termes d’analyse est considérable – par exemple pour déterminer les aires de navigation en fonction du tonnage ou encore la durée des rotations, à la condition de lever ou d’expliciter les incertitudes inhérentes à cette reconstitution. Afin de proposer une visualisation expressive et en particulier cartographique des données sur la navigation, l’équipe interdisciplinaire a fait le choix de donner à voir cette incertitude, ce qui requiert un travail complexe de curation des données, et de qualification des degrés d’incertitude des principales variables.
- 4 URL : https://www.ouvrirlascience.fr/decliner-la-science-ouverte/.
- 5 S. Marzagalli & C. Plumejeaud-Perreau, 2022.
- 6 C. Gruson-Daniel & Groupe projet Réussir l’appropriation de la science ouverte, 2022.
- 7 Tout comme dans la recherche historique, les faits ne sont pas « tout faits », mai (...)
- 8 C. Plumejeaud-Perreau, L. Nahassia & J. Gravier, 2022.
- 9 Voir en ce sens les remarques de J. Drucker, 2011.
3Sur le plan épistémologique, les chercheurs de « Portic » refusent en effet l’injonction à la perfection dans le domaine des données, qui amène à cacher leur épaisseur ou masquer ce qui est « sale » : nous nous inscrivons dans le courant de la science ouverte4 auquel nous participons aussi dans une démarche réflexive5, qui a donné récemment lieu à une synthèse6. Célya Gruson-Daniel y développe ce qu’est l’épaisseur de la donnée, atome de connaissance élémentaire, comme pour nous, par exemple, le tonnage d’un navire sur un registre, soit une cellule dans un tableau de 130 000 lignes et 100 colonnes : un élément qui paraît simple à première vue, mais qui en réalité n’a rien d’évident. Il n’y a en effet rien de « donné » dans la donnée7 : les corpus historiques sont un construit reposant sur de multiples hypothèses et questionnements. Des métadonnées extrêmement fines explicitant les méthodes de construction et de sélection des données historiques8 sont essentielles à la science ouverte. Cet article fournit une explication de la qualification de l’incertitude des données collectées dans Navigocorpus, base enrichie par « Portic ». Cette explicitation se veut ainsi une contribution à tout programme de recherche qui s’inscrit dans les mêmes préoccupations : livrer une donnée sans pour autant masquer ce qui fait d’elle un construit9. Il s’agit ici pour nous surtout d’insister sur les écueils rencontrés dans ce travail en interdisciplinarité, et d’expliciter le travail de curation qui a été réalisé, pour mettre en exergue quelques leçons tirées de cette expérience.
- 10 R. Devillers & R. Jeansoulin, 2006.
4En effet, la mise en évidence de véritables incertitudes au plan historique sur les trafics commerciaux maritimes à la veille de la Révolution française ne peut se faire sans une formalisation des différentes sortes d’« imperfection » dans les données – l’imperfection étant une notion propre aux informaticiens, les historiens n’y voyant quant à eux que la nature intrinsèque de toute trace du passé livrée par une source. Dans le domaine des sciences de l’information géographique10, l’imperfection à laquelle nous faisons face relève de trois aspects : le manque de précision (recours à des termes génériques : un départ pour « la Baltique ») ; les informations incomplètes (en raison des lacunes des sources ou de l’absence de l’information d’une variable dans la source); et enfin les données incertaines parce que apparaissant comme incohérentes à l’analyse (tonnages qui divergent, ou itinéraire incompatible avec ce qu’on sait de la durée des trajets, pour un « même » navire). Or nous savions que Navigocorpus recelait certaines incohérences qui relevaient non pas d’erreurs ou d’omissions dans les sources historiques mêmes qui nous intéressent, mais plutôt du processus de transcription. Nous avons développé des méthodes de recherche d’incohérences pour nettoyer au maximum la base des coquilles de transcription, pour pouvoir in fine mettre en évidence la part d’incertitude inhérente aux sources historiques.
5Cette contribution est structurée en deux parties. D’abord, partant de la description de la situation existante au début du projet, nous montrons la nécessité d’une migration constante d’une base de données (Navigocorpus) vers une autre (Portic) pour produire une standardisation et un enrichissement des données en vue de proposer des exploitations et des croisements intéressants. Ensuite, nous revenons sur la notion d’incertitude, qui a nécessité d’abord de corriger les données existantes, puis de définir ce qui relevait à proprement parler de l’incertitude historique. Cela permet ainsi de reconstituer des trajectoires de navigation complètement qualifiées pour ce qui est de leur incertitude.
6La base de données Navigocorpus accueille plus de jeux de données sur l’histoire maritime que ceux mobilisés dans le programme « Portic ». Le périmètre des sources du programme « Portic » est défini dans le Tableau 1, et montre que le nombre d’unités documentaires (soit une entrée relative à un mouvement d’un navire dans un registre) saisies depuis 2019 a fortement augmenté.
7Ces données ont été saisies dans Navigocorpus selon les mêmes modalités que lors du programme « Navigocorpus », avec en particulier une saisie libre de tous les champs sans contrôle sur leur valeur de code ni sur leur type, ce qui offre une grande souplesse au modèle de Navigocorpus. Cette continuité offrait deux avantages notables : d’une part, l’économie d’un nouveau développement et, d’autre part, la facilité pour les chercheurs qui, déjà habitués à cette interface, ne furent pas obligés d’apprendre un nouveau langage de requêtes ni une autre interface. Toutefois, pour à la fois offrir des interfaces de requêtes et de visualisation sur ces données, pour permettre une véritable analyse spatio-temporelle approfondie, pour croiser avec des jeux de données issus d’autres programmes de recherche, et enfin pour que l’accès à ces données soit véritablement direct et libre, il était nécessaire de copier et restructurer un peu les informations de Navigocorpus dans une nouvelle base de données, Portic.
Tableau 1. Liste des sources saisies dans Navigocorpus et migrées dans Portic depuis 2019
| Titre de la composante |
Années |
Nombre
de documents |
Saisi
après 2019 |
| Expéditions coloniales depuis Marseille |
1789 |
119 |
Oui |
Congés de l’Amirauté, sous-série G5
Archives nationales et archives départementales |
1787 |
24 547 |
Non |
Congés de l’Amirauté, sous-série G5
Archives nationales |
1789 |
9 830 |
Oui |
| La Santé registre de patentes de Marseille |
1749 |
2 291 |
Oui |
| La Santé registre de patentes de Marseille |
1759 |
1 926 |
Oui |
| La Santé registre de patentes de Marseille |
1769 |
2 320 |
Oui |
| La Santé registre de patentes de Marseille |
1779 |
2 329 |
Oui |
| La Santé registre de patentes de Marseille |
1787 |
3 296 |
Non |
| La Santé registre de patentes de Marseille |
1789 |
3 203 |
Oui |
| La Santé registre de patentes de Marseille |
1799 |
2 629 |
Oui |
| Registres du petit cabotage de Marseille |
1787 |
2 526 |
Oui |
| Registres du petit cabotage de Marseille |
1789 |
2 416 |
Oui |
Note. Les « Expéditions coloniales depuis Marseille » consistent en la liste des manifestes des navires expédiés en 1789 pour les colonies et les mondes extra-européens, conservés par la Société des Amis du Vieux Toulon, MA_11. Les congés délivrés dans les ports français sont conservés sous plusieurs cotes dans la sous-série G5 aux Archives nationales, ainsi qu’aux Archives départementales du Var, 7B 10 (Saint-Tropez), et aux Archives départementales du Morbihan, 10B 19 (Lorient). La composante « La Santé registre des patentes » recouvre les dépositions des capitaines auprès du bureau de la Santé de Marseille, conservées aux Archives départementales des Bouches-du-Rhône sous les cotes 200E 515, 525, 535, 543, 545, 554, 555. Quant aux « Registres du petit cabotage », il s’agit des cahiers du petit cabotage, tenus par le même Bureau, et conservés sous les cotes200E 606 à 608.
- 11 J.-P. Dedieu et al., 2011 ; id., 2012.
8La Figure 1 présente sous la forme d’un schéma UML la structure de Navigocorpus, implémentée sur le logiciel FileMaker (version Pro 18 Advanced) mais présentée ici de façon simplifiée par rapport à l’existant, qui contient quantité d’attributs non renseignés, ou en doublons, ou non utiles pour le propos de la recherche de « Portic ». Nous reviendrons par la suite en détail sur le sens de tous les attributs du modèle de Navigocorpus, qui est bien documenté par ailleurs11.
9La classe Pointcall modélise un événement se déroulant en un lieu à un instant donné. Cet événement est le plus souvent une des escales effectuées par un navire telles que livrées par une unité documentaire, à laquelle Navigocorpus attribue un identifiant documentary_unit_id. Ainsi, pour l’unité documentaire « 00188143 » issue d’un registre d’entrées à Marseille, et décrivant le trajet d’un navire du Havre à Marseille passant par le détroit de Gibraltar, il y aura trois instances de pointcalls. L’ordre de visite de l’escale pour le navire dans ce document est renseigné manuellement dans un attribut pointcall_rank, qui ordonne les escales dans l’ordre chronologique.
- 12 J. P. Dedieu & S. Marzagalli, 2015.
10Les classes Taxes et Cargo permettent de spécifier respectivement les taxes qui ont été payées lors de la délivrance du congé (document délivré par les bureaux de l’Amirauté et nécessaire à tout départ d’un port français) et la nature des produits (ainsi que, selon les sources, leur quantité) qui sont chargés ou déchargés à chaque escale de navire. Il y a donc une relation de cardinalité multiple entre une escale et les produits ou taxes afférents. L’attribut commodity_purpose correspond soit au produit transporté dans l’orthographe de la source, soit à l’objet du voyage dans le cas des sorties pour pêche par exemple. Le lien avec Commodity renvoie vers une description standardisée de la nature du produit identifiée par commodity_id, et une première tentative de classification publiée (dictionary_commodities_permanent_coding)12, mais seulement une minorité des instances de Cargo bénéficiait de ce travail au démarrage du projet. Par ailleurs, la façon dont les cargaisons (Cargo) sont rattachées aux escales n’est pas celle de la logique de l’action qui rattacherait via link_to_pointcall au record_id du Pointcall où la cargaison a été chargée ou déchargée, logique qui a été développée dans le modèle de Portic. Dans Navigocorpus, le lien n’est établi qu’avec le Pointcall de l’itinéraire où s’effectue le déchargement si la source est « la Santé », ou bien le chargement si la source fait partie des congés. Et si jamais des cargaisons ont été chargées ou déchargées ailleurs, alors le champ cargo_item_sending_place est renseigné et renvoie à une des variantes toponymiques (et non pas au code UHGS_id) du port où s’est réalisée l’opération. Afin de bien distinguer ce qui relève des entrées initiales de Navigocorpus, un attribut data_lineage ajouté à Cargo est renseigné avec le code « ADDED_PORTIC » (voir le modèle UML de Portic de la Figure 2) lorsque l’entrée correspond à une action de chargement ou déchargement sur un point intermédiaire de l’itinéraire décrit dans un document.
11Tout toponyme présent dans Navigocorpus, quelle que soit sa variante toponymique, est pourvu d’un identifiant unique (UHGS_id) lié à la classe GeoGeneral commune à plusieurs programmes de recherche et qui a été enrichie pour inclure par exemple aussi les lieux d’un naufrage ou d’une prise corsaire en pleine mer. GeoGeneral fournit, entre autres, les coordonnées géographiques (latitude et longitude). Cependant, la structure de la table correspondant à ce modèle ne convient pas aux besoins de nos analyses. Cette table qui contient six millions d’entités duplique l’entrée (uhgs_id, longitude, latitude) autant de fois qu’il y a de variantes toponymiques trouvées dans les sources (avec leurs variantes orthographiques) ce qui rend très peu performante la jointure par la chaîne de caractères pointcall_uhgs_id avec le Pointcall. De plus, parfois pour un même pointcall_uhgs_id, nous avons trouvé des longitudes ou latitudes qui différaient, ou bien qui n’étaient pas valides. Pour travailler avec la dimension géographique de façon efficace, nous avons restructuré cette table en une table correspondant à la classe Port_points (présentée dans la Figure 2) sans doublons, résumant l’ensemble des variantes toponymiques dans un champs unique toustopos, et décrivant la fréquence d’apparition de ces variantes dans un champ JSON topofreq.
12La classe Stage, révisée en profondeur en 2023, décrit la distance en miles nautiques entre deux escales : fruit d’une expertise humaine, les distances calculées à la main ne sont pas symétriques d’un point à un autre, suivant en cela les logiques de navigation maritime à la voile de l’époque, dépendantes des courants marins et des vents dominants.
13La classe Source fournit la référence archivistique du document transcrit dans la base, selon la structure hiérarchique suivante : la cote d’archive (attribut source) d’une documentary_unit (cote abrégée, suivie par exemple du numéro de congé) fait partie d’une série (component_source, tel le registre G5-50 correspondant au registre des congés délivrés à Bordeaux en 1787) qui elle-même fait partie d’une suite documentaire (component_suite) (par exemple, la sous-série G5 aux Archives nationales) dont la base fournit une description. Cependant, la jointure avec Pointcall n’est pas du tout directe, et nécessite des corrections manuelles ou des appariements par comparaison de chaînes de caractères. Or nous avons l’ambition de bien comprendre comment chaque série a pu être enregistrée et si elle présente des défauts caractéristiques (telle que par exemple une sur-évaluation du tonnage systématique). Nous avons donc corrigé dans la nouvelle structure présentée en Figure 2 le lien avec Source, classe qui renvoie également au port principal de cette série (par le champ main_port_uhgs_id), ce qui permet de localiser géographiquement les sources.
14Par ailleurs, une dimension géographique et temporelle explicite est fondamentalement nécessaire dans cette nouvelle version de Portic. Les ports sont donc tous au maximum (sauf 7 sur 1 777 actuellement) localisés par un point en coordonnées géographiques avec l’attribut geom, ou un point projeté dans le système pseudo-mercator avec l’attribut point3857, et les escales sont toutes datées avec un attribut (outdate_fixed ou indate_fixed, et data_fixed) de type Date au format ISO 8006 qui permet de raisonner à travers l’ensemble de tous les documents (identifiés par le champ source_doc_id) pour étudier la trajectoire d’un même navire décrit par le code ship_id. En effet, si Navigocorpus a pris soin d’ordonner les escales dans un même document avec le champ pointcall_rank, notre recherche consiste maintenant à recouper toutes les informations liées au même navire ou au même capitaine, et donc nous avons calculé un champ pointcall_rankfull qui représente l’ordonnancement des escales à travers tous les documents mentionnant la même entité. Cette ambition analytique et cartographique du projet est portée par un système de gestion de base de données libre (i. e. open-source) avec des capacités spatiales : PostgreSQL avec sa cartouche spatiale Postgis.
Figure 1. Modèle UML de Navigocorpus
Note 1. Jusqu’en 2019, documentary_unit_id était l’unique identifiant d’un document, contenant tout l’enregistrement d’un capitaine dans un port. Après 2019, cet attribut a été dupliqué dans data_block_local_id, toujours renseigné depuis.
Note 2. Plusieurs latitudes et longitudes différentes (voire aucune) pouvaient être associées à un même identifiant UHGS_id dans GeoGeneral, qui dupliquait en effet l’enregistrement des coordonnées pour les variantes toponymiques.
Note 3. La cargaison référençait un des pointcall de l’itinéraire par son record_id, mais uniquement celui où se faisait l’enregistrement du capitaine (lieu de chargement ou de déchargement) ; cette cargaison pouvait avoir été chargée ou déchargée ailleurs, ce qu’indiquait le champ carto_item_sending_place, renseigné, dans ce cas, par la variante toponymique du pointcall.
Note 4. Faire la jointure entre link_to_source01 et component_source n’est pas évident : beaucoup d’exceptions doivent être traitées manuellement. Par exemple, il faut remplacer « ANF, G5-125 » par « ANF, G5-125-1 ».
Figure 2. Modèle UML de Portic
Note 1. record_id est unique et permet de faire la liaison avec l’entrée correspondante dans Navigocorpus sur la table pointcall.
Note 2. source_doc_id correspond exactement à data_block_local_id, il identifie chaque document.
Note 3. La jointure est faite avec le record_id du pointcall où l’action de chargement/déchargement (cargo_item_action) a été réalisée pour la cargaison.
Note 4. data_lineage est un marqueur signalant si l’information (et l’action associée) a été ajoutée par Portic, ou faisait partie des données originelles de la base Navigocorpus.
Note 5. Les dates d’appartenance n’ont été renseignées que pour les unités de la nomenclature « Etat_de_Portic ».
Note 6. Un tonneau (tx) vaut 24 quintaux.
Note 7. Après la conversion en unités « tonneaux ».
15La migration entre Navigocorpus et Portic, qui a permis de mettre en place les éléments nécessaires à une analyse et une visualisation de données incertaines, a été automatisée dans un programme d’Extraction-Transformation-Chargement (ETL) sous licence libre et dont les sources sont archivées sur un gestionnaire de sources ouvert de l’Infrastructure de Recherche (IR) Huma-Num. Dans son organisation, le programme copie d’abord les données à partir de plusieurs extractions de Navigocorpus qui prennent la forme de fichiers Excel. Ce chargement recrée une table sans aucun a priori ni sur le type, ni sur le nombre, ni sur le nom des champs récupérés depuis Navigocorpus afin d’être le plus résilient possible face à d’éventuels changements de structure de FileMaker.
16En effet, la base Navigocorpus partage plusieurs entités avec d’autres bases de données conçues par Jean-Pierre Dedieu, qui a continué à faire évoluer son système. Cela a induit des modifications de quelques identifiants dans certaines entités communes comme GeoGeneral, mais aussi des modifications de la structure de la base de données Navigocorpus au cours du projet. Par exemple, documentary_unit_id a été dupliqué dans un nouveau champ, data_block_local_id, qui est devenu le nouvel identifiant d’un document source, renseigné pour les nouvelles saisies, laissant l’autre vide. Ces transformations obligent à modifier souvent le code source de l’ETL.
17La saisie des champs dans Navigocorpus n’est pas restreinte à des listes de valeurs prédéfinies afin, (I) de rester le plus proche de la source, et (II) de favoriser son évolutivité par une saisie libre. Or, disposer d’une version standardisée de ces champs est une nécessité pour des fins analytiques et pour proposer des interfaces d’exploration et d’interrogation utilisables. Comment par exemple analyser les flottes regroupées par pavillon (attribut flag de Pointcall) fréquentant un port sans avoir au préalable une liste normée de pavillons ? Également, pointcall_status, dont la valeur est essentielle pour comprendre le niveau d’incertitude d’une escale, prend encore en juillet 2023 des valeurs fausses comme « FC-TT » ou « FPC-RS ». La nouvelle structure enrichie au fil des itérations du projet s’est donc employée à standardiser et corriger les codes faux, et tous les champs codifiés et standardisés apparaissent sur fond jaune comme des types énumérés dans la Figure 2 : StatusCode, ActionCode, NetRouteMarkerCode, FunctionCode, TonnageUnit et ShipClass. D’autres catégories, traduites en français et en anglais, ont été ajoutées ou complétées pour faciliter la recherche : Flags pour les noms des pavillons tels que génois, hollandais, napolitain, etc. (identifiés par ship_flag_id) ou l’appartenance étatique des capitaines (identifiée par captain_citizenship_id), Commodity pour les types de produits, SuiteCode pour les sous-ensembles de sources, PortStatusCode pour le statut des ports vis-à-vis de l’Amirauté. Ainsi tous les noms de lieux ont été traduits en français (toponymes_standard_fr) et en anglais (toponyme_standard_en), et sont identifiés par le code UHGS_id de Ports qui permet de retrouver les noms des ports d’escale (pointcall_uhgs_id), les ports d’attache (homeport_uhgs_id), les lieux d’origine des capitaines (captain_birthplace_id).
18Ce travail est quantifiable, car les ports sont nombreux (1 777 ports distincts en juillet 2023), tout comme les produits (1 069 produits distincts en janvier 2023), identifiés par commodity_id. Ainsi, en janvier 2020, sur 35 356 instances de produits renseignés dans le périmètre de Portic, 2 078, soit 6 % environ, n’avaient pas encore d’identifiant alors qu’en janvier 2023, presque 100 % des 77 882 instances de produits sont pourvues d’un code. Quant à l’attribut ship_class documentant la classe du navire, aucun identifiant n’avait été prévu au départ. Il s’appelle désormais ship_class_standardized.
19Les nouvelles informations sont fournies dans des fichiers Excel par les historiens de l’équipe, habitués au format tabulaire. Cependant, ce format est source de nombreux problèmes de saisie : encodages incohérents entre la base (UTF8) et les fichiers (les historiens sauvent en Windows 1252 ou Latin-1), espaces et signes de retour à la ligne insérés par mégarde dans les cellules. Parfois aussi l’équipe de « Portic » a fait les frais d’un dialogue par courriels interposés qui ne permet pas de tout expliciter, et l’historien corrige une colonne qui n’est là que pour l’aider à organiser son travail et qui ne sert à rien d’autre, tel le pays d’appartenance actuel.
20Plus généralement, le calendrier de notre recherche laisse peu de place à un rythme de travail et de négociation serein. Les trois rendez-vous interdisciplinaires qui visent à croiser les données de la balance du commerce français avec celles de Navigocorpus ont introduit à leur tour de nouvelles exigences concernant le contenu et la forme des informations présentes dans Navigocorpus. Ce qui pénalise le processus de migration, un nouveau champ à standardiser venant s’ajouter chaque fois aux précédents. Ce processus est aussi pénalisé par le fait que la liste de ces items évolue constamment, Navigocorpus étant enrichi continuellement de nouvelles sources et/ou de corrections sur d’anciennes, il faut alors revérifier et rajouter des éléments standardisés à chaque nouvelle itération. Il y a eu jusqu’à présent (i. e. août 2023) dix versions de Portic entre novembre 2018 et juillet 2023.
- 13 D’après la définition de la CNIL, « une API (application programing interface ou “interface (...)
21Toutefois, cette centralisation des modifications par ce programme de migration permet avantageusement d’assurer la diffusion des mêmes données versionnées sur une API13 en ligne utilisée par les différents partenaires et leurs outils de visualisation et d’analyse, ainsi qu’un téléchargement direct des données par le Web.
22Ces nombreux échanges par fichiers interposés apportent d’autres avantages. Premièrement, l’historienne qui coordonne le programme garde le contrôle de la correction et peut à son tour relever des anomalies dans les retours des programmes. Deuxièmement, cela permet aussi aux informaticiens de comprendre en finesse le sens de certains champs ou de leur combinaison pour corriger les algorithmes, car la saisie dans Navigocorpus comprend nombre de subtilités. Par exemple, il n’est pas évident à la première lecture de comprendre comment et où le chargement et le déchargement des marchandises se fait le long d’un itinéraire de navire. Troisièmement, nous apprenons aussi comment restituer efficacement une erreur relevée dans un champ de la base de données pour faciliter le dialogue interdisciplinaire. L’historienne valide en effet ou pas le caractère de l’« erreur » signalée, puis corrige si nécessaire la base Navigocorpus après avoir éventuellement vérifié la source manuscrite.
- 14 J. Cohen et al., 2013 [2002].
- 15 P. Cerda, G. Varoquaux & B. Kégl, 2018.
23La standardisation du type de navire (ship_class) illustre bien la confrontation des pratiques informaticiennes et historiennes. Cet attribut pourrait être un bon indice du tonnage des navires, mesure absente sur une partie du corpus, et dont nous nous sommes aperçus qu’elle peut varier en fonction des greffiers et des pratiques fiscales de chaque bureau d’Amirauté. Dans tous les cas, il est intéressant de normaliser une nomenclature trop riche, avec de nombreuses occurrences uniques ou presque. L’informaticien est très tenté, au vu des valeurs très diverses mais ressemblantes au plan lexicographique de certains champs, comme l’est en particulier ship_class, d’utiliser K-means, une méthode très pratiquée14 pour automatiser le regroupement des valeurs dans une même classe (ou cluster en anglais). Sa mise en œuvre est recommandée15 face à un jeu de données avec des attributs dont l’ensemble des valeurs varie trop (380 valeurs distinctes de types de navires) : il s’agit de définir un sous-ensemble de catégories (31 classes de navire différentes) et d’analyser la ressemblance lexicographique (par la distance de Jaro-Winkler) à ces catégories pour chacun des éléments de l’ensemble. La Figure 3 présente un extrait des résultats de ce regroupement automatique : à gauche, chaque valeur de ship_class est associée à un numéro de cluster, correspondant à une des 31 catégories normalisées choisie par les informaticiens en fonction de leur fréquence d’apparition dans le corpus. La partie droite illustre la distribution des classes identifiées, avec une majorité de tartanes, bateaux et barques. Cependant ce résultat questionne puisque dans le détail, à gauche, le canot se retrouve avec les corvettes dans le même cluster, alors que les deux types d’embarcations n’ont rien à voir.
Figure 3. Extrait du résultat de la classification automatique par KMeans de l’attribut ship_class en vue de sa normalisation
24Ce détail a plutôt conforté la méfiance instinctive des historiens du projet vis-à-vis des méthodes de correction ou de classification automatique. L’analyse de la ressemblance des navires et du tonnage étant un enjeu assez fort dans le projet, ils ont préféré réaliser cette normalisation à la main, aboutissant à 55 catégories. Réalisée en cinq jours de travail, cette normalisation est donc le fruit d’une négociation interdisciplinaire entre le temps dévolu à une tâche et la qualité souhaitée du résultat. Elle renvoie également à des modes de gestion de l’incertitude très différents parmi les stratégies possibles face à l’incertitude d’une valeur, qui peuvent être (I) de retirer la valeur, (II) de proposer une fourchette de valeurs, ou (III) d’en proposer une estimation. Plutôt que de classer par exemple une valeur avec une probabilité égale dans deux catégories (deuxième stratégie, classique en informatique), Portic propose une estimation très fortement influencée par l’expertise historienne. La consultation des documents sources a ainsi éclairci le cas de « bateau pinque » qui a été classé « pinque » alors qu’il existe aussi une classe « bateau ».
- 16 Voir S. Marzagalli et al., 2023. L’étude de cas dont il s’agit est disponible en ligne (...)
25Outre la standardisation des champs de Navigocorpus, Portic intègre plusieurs nouvelles nomenclatures qui permettent de trier et regrouper entre elles des entrées, communes par exemple dans leur dimension géographique ou administrative, ou dans la nature des cargaisons (avec category_portic_fr et category_portic_en ou category_toflit18_revolution_empire et category_toflit18_revolution_empire_aggregate dans Commodity). Dans le troisième article du présent dossier16 qui reprend et commente de nombreux éléments publiés en ligne, nous soulignons comment ces métadonnées ont pu être utilement exploitées pour révéler le potentiel de Navigocorpus pour la recherche historique maritime. Simplement, il s’agit ici de lever le voile sur la « magie » qui s’opère en ligne, pour révéler les difficultés masquées en arrière-cuisine.
26L’inscription des ports dans la géographie des circonscriptions administratives ou étatiques du xviiie siècle est essentielle pour comprendre les logiques de navigation commerciale nationale et internationale, notamment dès lors qu’on envisage de les croiser avec des données agrégées qui mobilisent des catégories d’époque, comme c’est le cas de la balance du commerce. Or, cela requiert un travail considérable, et la plupart des bases de données qui font référence en histoire maritime (Slavevoyages17, Sound Toll Registers Online18) ne s’y sont pas attaquées, se limitant à classer les ports en fonction des pays d’appartenance actuels, ou des régions géographiques plus ou moins larges. Chaque localité mentionnée dans les sources mobilisées par Portic a été rattachée à quatre types de Nomenclature, avec la description de son niveau dans cette nomenclature (UnitLevel) et la période d’appartenance à telle ou telle entité administrative (Belongs) quand elle concernait les appartenances étatiques, et, systématiquement, le niveau de certitude que nous avions de cette information d’appartenance (uncertainty).
- 19 Archives nationales de France, G1 63, État des directions et bureaux de la ferme génér (...)
- 20 J. D. Singer, 1987 ; URL : https://correlatesofwar.org.
- 21 URL : https://medialab.github.io/GeoPolHist/#/ ; B. Dedinger & P. Girard, 2021.
- 22 C. Plumejeaud-Perreau et al., 2021.
- 23 URL : http://maps.portic.fr.
27La nomenclature des Amirautés se subdivise ainsi en bureaux d’Amirauté et plusieurs Amirautés constituent une province du royaume de France d’avant 1789. Afin d’être en mesure de croiser les données de la navigation avec la valeur des exportations maritimes connues via les relevés des bureaux des Fermes en 178919, les ports français mentionnés par Navigocorpus ont été rapprochés du bureau et de la direction des Fermes dont ils devaient a priori dépendre (nomenclature Ferme), tandis que les ports étrangers ont été rattachés aux partenaires commerciaux correspondants dans la nomenclature Etat_de_Toflit18. Cette dernière considère plutôt des partenaires commerciaux que des entités politiques, et comporte par exemple une catégorie de partenaires nommée « Quatre Villes hanséatiques » qui associe trois villes libres du Saint-Empire romain germanique et le port de Dantzig, donc quatre entités étatiques différentes. En effet, il n’existe pas de nomenclature géographique des États proposant un code standardisé et partageable entre sources historiques pour cette époque. Le résultat le plus connu dans le domaine est celui du projet « Correlates of War »20 ; le projet « GeoPolHist »21 a aussi très récemment publié un travail considérable de standardisation qui remonte jusqu’à 1815 mais ne couvre pas la période précédente qui nous intéresse. Pour ce qui est de la nomenclature Etats_de_Portic, elle rattache les ports aux entités politiques étatiques de la période 1749-1789, ainsi que l’année 1799. Tout ceci a permis de réaliser une cartographie fine du maillage portuaire du royaume de France, mais aussi des ports étrangers mentionnés par les sources, publiée22 et accessible sur une carte interactive23.
- 24 Archives nationales de France, G1 63, État des directions et bureaux de la Ferme génér (...)
- 25 E. Athimon et al., 2021.
28Ceci a nécessité une étroite collaboration entre historiens, historiens économistes, géomaticiens et informaticiens, et ces dialogues par téléphone, visioconférences et mails interposés ont révélé de réelles incertitudes historiques : par exemple, fallait-il rattacher les ports de Noirmoutier et l’île de Bouin au bureau de la Ferme des Sables-d’Olonne lorsque nous savons que les « petites îles » étaient considérées comme étrangères au royaume de France en 1789 ? Notre réponse a été d’abord de proposer une modélisation de l’incertitude par niveau de confiance dans notre décision pour chaque attribut, comme ici celui du bureau de Ferme dont dépend un port. Ces niveaux forment une variable catégorielle ordinale uncertainty qui s’échelonne de 0, lorsque la confiance est totale, à −1 ou à −2, voire moins, lorsque la fiabilité de la valeur diminue. Ainsi, lorsqu’une source archivistique (ici un document listant les bureaux de la Direction de la Ferme la Rochelle en 178924) atteste nommément de la présence d’un bureau de Ferme dans un port, sans contradiction par ailleurs, l’attribut uncertainty dans Belongs vaut 0. Cette méthodologie est inspirée de récents travaux dans le domaine de l’étude des submersions historiques qui modélisent la fiabilité de l’information historique en fonction d’une critique approfondie des sources qui les avalisent25. Dans notre exemple, Noirmoutier et l’île de Bouin sont rattachées au bureau des Sables-d’Olonne mais avec une valeur de certitude négative.
29À partir de ces données enrichies, il est possible de trouver dans Portic la substantifique moelle nécessaire à la recherche en histoire pour reconstruire des flux maritimes et leurs acteurs, analyser la géographie du commerce, étudier l’impact des guerres sur la navigation, découvrir des mensonges (tels que la déclaration de « Lisbonne » pour masquer la contrebande appelée « smogglage » avec l’Angleterre au départ de Dunkerque). L’analyse critique et le croisement des sources permettent aussi de mesurer et de comprendre les stratégies des acteurs du domaine maritime de l’époque face à une administration étatique, représentée par l’Amirauté ou semi-privée, telle la Ferme. Cependant l’analyse doit, pour être bien établie, écarter au maximum l’hypothèse d’une erreur de transcription ou d’interprétation de la source. Or, le très libre processus de transcription de Navigocorpus laisse la place à de nombreuses possibilités d’erreurs, dont nous disséquons la nature en vue de montrer les règles de correction élaborées.
30Il faut se pencher d’abord sur la façon dont les pointcalls sont renseignés dans la base. Dans une même unité documentaire, on trouve un même navire et plusieurs escales. Pour renseigner ces données, la saisie des informations communes se fait au point d’observation (codé « O » dans pointcall_function), celui où est enregistrée la déclaration dans le document source. Trois identifiants relevant d’un travail d’interprétation sont ensuite renseignés, a posteriori, en prenant en compte l’ensemble des informations présentes : l’identification du lieu d’escale (pointcall_UHGS_id), du capitaine (captain_id), et du navire (ship_id).
- 26 Pour prendre la mesure du degré de complétude de variables, selon des « fa (...)
31Pour économiser le travail de saisie, toutes les informations descriptives du capitaine et du navire de ce document source sont copiées sur les lignes correspondant aux autres escales qui peuvent précéder ou suivre le pointcall d’observation, mais mises entre parenthèses pour signaler que ces informations ne sont pas stricto sensu fournies par la source. Une fois un identifiant de capitaine ou de navire attribué, les attributs descriptifs de ce capitaine (comme sa « nationalité » – attribut citizenship) ou du navire (comme son port d’attache – attribut ship_homeport) sont recopiés et mis entre crochets sur d’autres documents sources contenant le même identifiant mais dont la description est moins complète. Les crochets indiquent que, sous réserve que l’identification du capitaine ou du navire ait été correcte, il est probable que les attributs soient ceux-là. Par exemple, le port d’attache est renseigné de manière systématique dans seulement 29 des 86 registres exploités en 178726. Ceux du Havre et de Rouen ne l’indiquent presque jamais. Par le biais de ces reports d’information entre navires identifiés, pour ce qui est du port d’attache, nous avons désormais renseigné la variable de manière marginale pour certains ports d’escale (3,5 % en Corse) et plus substantielle pour d’autres (25 % au Havre, 31 % à Rouen, 93 % à Beauvoir-sur-Mer). Cependant, la faille de cette approche vient de ce que les corrections ne sont pas systématiquement reportées lorsque l’édition initiale est modifiée. Il s’ensuit qu’on peut trouver des informations divergentes dans des pointcalls rattachés à une même unité documentaire, ou pour les mêmes entités (capitaine, navire) dans plusieurs unités documentaires. Dans tous les cas, la seule information sûre qui doit faire foi est celle saisie au point d’observation.
32Le programme de migration recherche systématiquement ces incohérences. Il repère ainsi rapidement l’erreur présentée dans le Tableau 2, où le registre du document (component_source), diverge pour Abbeville et Le Havre, alors qu’il concerne deux pointcalls tirés d’un même document identifié par sa cote « ANF, G5-39B-1/6079 » mais aussi l’identifiant data_block_local_id (« 00104863 »). Nous sommes certains de devoir remplacer « ANF, G5-115A/La Hougue » par « ANF, G5-39B-1/Abbeville » parce que nous nous appuyons aussi sur la logique des sources analysées. Or dans la série fiscale du G5, il n’y a de registre que pour les points d’observation, puisque les navires prennent leur congé au départ. De plus, la saisie au point d’observation (function = « O »), donc à Abbeville, doit faire foi pour la correction.
Tableau 2. Exemple d’incohérences repérables dans les pointcalls de Navigocorpus
| data_block_ local_id |
name |
rank |
function |
source |
component_ source |
| 104863 |
Abbeville |
1 |
O |
ANF, G5-39B-1/6079 |
ANF, G5-39B-1/Abbeville |
| 104863 |
Le Havre |
2 |
T |
ANF, G5-39B-1/6079 |
ANF, G5-115A/La Hougue |
- 27 Archives départementales des Bouches-du-Rhône, 200 E 543, 4 avril 1787.
33Les règles de contrôle sont élaborées en concertation entre les acteurs du projet. Le fait que ces erreurs soient ensuite listées dans des fichiers Excel, qui rendent compte par divers codes couleur du contexte et de la logique de l’erreur, est important. Ainsi cette phase de détection d’incohérences a abouti au format de rendu tabulaire présenté dans la Figure 4 pour ce qui est de la vérification de la cohérence des pavillons. L’analyse vise à comparer le pavillon indiqué sur les points d’observation (ligne en surligné gris dans le fichier Excel) avec ceux de tous les pointcalls du même navire (même ship_id). En cas de divergence, le programme surligne les attributs flag et ship_flag_id qui en découlent (en rouge : divergence majeure ; en jaune : divergence mineure). Le pavillon doit par ailleurs être cohérent avec le port d’attache éventuellement renseigné, rattaché à l’État d’appartenance de ce port (colonne homeport_state_1789). Par ailleurs, les sources mobilisées indiquent très rarement le pavillon. Celui-ci a été le plus souvent déduit du port d’attache ou de la nature du congé délivré, qui peut être « français » ou « étranger », sauf indication contraire dans la source (par exemple : Antoine Mathieu Salaro, génois, commandant « sous pavillon de Jérusalem », c’est-à-dire sous le pavillon de l’ordre de Malte27). Ainsi, dans l’extrait de la Figure 4, sur la première ligne, le navire 0000165N a explicitement un pavillon britannique, et son port d’attache (Dublin) est bien en Grande-Bretagne à l’époque ; mais à la troisième et la quatrième escale de l’itinéraire reconstruit grâce au ship_id, le pavillon renseigné est « Danish/Norwegian », et le flag_uncertainty à −2 indique que l’information était entre crochets, donc rapportée, et non issue du document source. Or, il se trouve que dans cet autre enregistrement, le navire est indiqué avoir Bergen comme port d’attache, ce qui a amené à déduire (en le plaçant donc entre crochets) son pavillon danois/norvégien. L’algorithme signale donc une possible erreur. Les historiens vérifient sur les originaux et vérifient aussi si l’attribution d’un même ship_id pourrait être une erreur, puis ils tranchent. S’ils corrigent Navigocorpus, ils vérifient aussi le port d’attache et leurs identifiants. Dans ce cas précis, le navire a le même nom (Fortune), un capitaine avec un nom fort proche (Petter Mollers et Peter Moller), un itinéraire cohérent (Lorient à île de Ré ; Ars-en-Ré à Bergen). La décision prise est de laisser les choses en l’état, car il y a une forte présomption que ce bâtiment navigue avec un double jeu de papiers, la destination « Bergen » servant au demeurant fréquemment pour masquer de la contrebande à destination des îles Britanniques.
Figure 4. Présentation de l’analyse de cohérence des champs associés au pavillon d’un navire (flag) dans le fichier Excel
34Même si le report manuel de la correction dans Navigocorpus peut sembler de prime abord très chronophage, l’opération assure un meilleur niveau de fiabilité, et permet aussi de prendre conscience de l’ampleur des marges possibles d’erreurs sur telle ou telle variable. L’exemple du Tableau 2 est un cas fort rare dans l’ensemble des congés, alors que les vérifications des identifiants des lieux ont permis de moissonner un nombre plus élevé d’erreurs, dues au fait que la vérification de l’exactitude des saisies, réalisée par la responsable scientifique du projet à partir des manuscrits, a été en partie effectuée après l’attribution des identifiants : cela ne devrait jamais arriver dans un monde idéal, mais devient inévitable dans le monde réel en raison du contexte de production (ici, l’absence des fonds pendant plusieurs années pour procéder à ces vérifications, par deux personnes travaillant simultanément sur trois écrans d’ordinateur). En conséquence, la correction d’un toponyme qui avait été mal lu, n’a pas été immédiatement associée à la correction de son identifiant. La création d’algorithmes de contrôle nous permet de rejouer les règles de détection d’erreurs, et de les affiner au fur et à mesure. Par ailleurs, certaines de ces règles sont suffisamment complexes pour aboutir à l’utilisation des programmes qui manipulent des règles statistiques : c’est le cas des tonnages.
- 28 G. Buti, 2008 ; S. D. Behrendt et al., 2020. Pierrick Pourchasse a démontr (...)
- 29 La perception du droit de congé et d’autres droits par les bureaux d’Amirauté varie se (...)
35Les historiens sont conscients du caractère douteux des mesures du tonnage indiquées par les sources28. Sans savoir comment les greffiers s’y prennent pour évaluer le tonnage du navire indiqué lors de la délivrance d’un congé, nous avons constaté que celui-ci peut sensiblement varier suivant les Amirautés et les ports visités. Nous avons donc cherché une sur- ou sous-estimation majeure dans tel ou tel port29. Pour cela, en nous appuyant sur l’ensemble des saisies pour lesquelles l’identification des navires est faite, nous avons évalué la variation du tonnage de chaque navire dans chacun des points d’observation où il prend un congé (donc les ports pourvus d’un greffier de l’Amirauté), puis analysé la distribution statistique du rapport entre le tonnage de ce navire dans ce port et le tonnage moyen que nous avons calculé. Si le ratio est supérieur à 1, c’est que le tonnage du navire est surévalué dans ce port. La Figure 5 présente les résultats de l’analyse de la distribution de ce ratio par port (avec greffier) sur l’ensemble de Navigocorpus, avec en rouge la valeur moyenne du ratio par port. Les ports sans anomalies ne sont pas représentés. Cette analyse montre que les tonnages à Marennes sont 20 % plus élevés en moyenne que partout ailleurs ; sa lecture indique aussi qu’au-delà de 50 % de plus qu’ailleurs, un navire dont le ratio excède le neuvième décile est décrit par un sur-tonnage exceptionnel, ce que l’indicateur de certitude attaché (tonnage_uncertainty) décrit comme douteux (−2). En général, la règle est que pour les navires au tonnage supérieur à 20 tonneaux, nous vérifions que la dispersion du tonnage observé ne dépasse pas 20 %. En effet, pour les petits tonnages, la confusion entre les chiffres est facile, mais cela reste du détail du point de vue de l’analyse historique car un navire de 5 ou 8 tonneaux reste un très petit navire (catégorie définie par les historiens à moins de 20 tonneaux), même si la dispersion est forte.
Figure 5. Analyse de la distribution des écarts au tonnage moyen d’un navire dans les congés de l’Amirauté en 1787, tous registres confondus
36Ces allers-retours et discussions fréquentes autour de la logique des données saisies ont permis de faire surgir des questions importantes et de mesurer l’apport d’une approche automatisée par rapport à un travail entièrement manuel. Pour expliquer la forte surestimation de Marennes, port où les capitaines sont très nombreux à charger du sel, nous faisons l’hypothèse que le marché étant captif, le greffier, qui encaisse une partie des droits perçus pour l’Amiral, a pu être tenté de surévaluer les tonnages.
37Les repérages des erreurs et des anomalies nous permettent de comprendre au plus près les données dont nous disposons et de s’assurer de disposer d’une base la plus propre possible s’agissant des données saisies et des métadonnées ajoutées.
38En analysant la nature des sources mobilisées dans Navigocorpus, il est possible de qualifier le niveau de certitude des trajectoires reconstituées grâce au suivi du même navire ou du même capitaine identifié à travers différents documents. En effet, toutes les sources ne présentent pas le même statut du point de vue de la temporalité des faits énoncés, et donc de leur statut avéré ou pas.
39Dans Navigocorpus, l’attribut pointcall_status (navigo_status dans Portic) explicite si, d’après le document, l’événement a eu lieu dans le passé par rapport au moment où le fait est relaté (il a un statut « PC »), ou s’il s’agit d’une intention annoncée (statut « FC ») ou bien d’une intention qui n’a pas pu être réalisée (statut « PU »). Le croisement de sources peut-il confirmer qu’une intention (statut « FC ») s’est réalisée ultérieurement ?
40Les sources marseillaises concernent des arrivées, donc des événements passés au moment du récit aux intendants du Bureau de la Santé (pointcall_status = PC) : le registre mentionne le lieu et la date exacte d’où le navire a appareillé, ainsi que tous les endroits où il a fait escale au cours du voyage. Tous ces lieux sont qualifiés de certains car « observés » dans la variable pointcall_uncertainty. Il n’y a pas non plus d’incertitude dans le cas d’une déclaration de la destination initiale prévue qui n’a pas été atteinte : le Ville d’Yverdon, par exemple, a appareillé de Marseille pour Smyrne le 28 décembre 1787 mais son mât a été gravement endommagé par le mauvais temps aux îles du Frioul, de sorte que le capitaine est entré à nouveau à Marseille le 31 décembre pour faire réparer le navire. Smyrne a le statut de « PU » (intention passée non réalisée) : nous sommes certains que le navire n’a pas atteint Smyrne. Dans quelques cas, les registres de Marseille mentionnent la destination suivante prévue. Comme pour tous les événements futurs (pointcall_status = FC), il est possible que cette intention n’ait pas été réalisée et le pointcall est alors qualifié de « déclaré » ; la date d’arrivée est évidemment absente.
- 30 Sur la législation relative à l’obligation de prendre un congé, voir S. Marzagalli (...)
41Ce dernier cas est similaire aux congés de l’Amirauté (sources de la sous-série G5), qui constituent une partie importante (67 %) de notre base de données. Tous les navires quittant un port français devaient payer une taxe pour obtenir leur congé. Quelques exceptions existaient : un aller-retour dans le ressort du même bureau d’Amirauté ne nécessitait qu’un seul congé. Comme il y avait 50 bureaux d’Amirauté différents le long des côtes françaises, cette exception ne concerne que le commerce local sur de courtes distances, soit 3 257 trajets intra-Amirautés sur un ensemble de 42 262 trajets reconstitués à partir des congés. Les autres exceptions ne sont pas pertinentes30. La majorité (62 %) des navires français se rendent dans un autre port français. Le lieu d’achat du congé est « observé », donc certain, et les destinations annoncées sont qualifiées comme « déclarées ».
42La reconstitution de l’itinéraire se fait en ordonnant chronologiquement les escales d’un même navire. Ainsi, la Fidèle Mariane (Tableau 3) peut être suivie à travers six documents. Les déclarations sont parfaitement cohérentes : pointcall_uncertainty prend alors la valeur de « confirmé » pour les destinations déclarées ici en vert (statut « FC »), car elles sont confirmées par l’observation suivante.
Tableau 3. Ordonnancement des escales de la Fidèle Marianne, et confirmation de ses déclarations d’intention
| data_ block_ local_ id |
ship_id |
ship_ name |
pointcall |
out_date |
rank |
net_ route_ marker |
function |
status |
| 62213 |
0002931N |
Fidèle Mariane |
Les Sables-d’Olonne |
1787=01=05 |
1 |
A |
O |
PC |
| 62213 |
0002931N |
Fidèle Mariane |
Bayonne |
|
2 |
Z |
T |
FC |
| 140197 |
0002931N |
Fidèle Mariane |
Bayonne |
1787=03=16 |
1 |
A |
O |
PC |
| 140197 |
0002931N |
Fidèle Mariane |
Dunkerque |
|
2 |
Z |
T |
FC |
| 110541 |
0002931N |
Fidèle Mariane |
Dunkerque |
1787=05=10 |
1 |
A |
O |
PC |
| 110541 |
0002931N |
Fidèle Mariane |
Les Sables-d’Olonne |
|
2 |
Z |
T |
FC |
| 102845 |
0002931N |
Fidèle Mariane |
Les Sables-d’Olonne |
1787=06=18 |
1 |
A |
O |
PC |
| 102845 |
0002931N |
Fidèle Mariane |
Bayonne |
|
2 |
Z |
T |
FC |
| 140566 |
0002931N |
Fidèle Mariane |
Bayonne |
1787=09=04 |
1 |
A |
O |
PC |
| 140566 |
0002931N |
Fidèle Mariane |
Saint-Malo |
|
2 |
Z |
T |
FC |
| 142100 |
0002931N |
Fidèle Mariane |
Saint-Malo |
1787=10=08 |
1 |
A |
O |
PC |
| 142100 |
0002931N |
Fidèle Mariane |
Saint-Brieuc |
1787<10<10! |
2 |
A |
|
FC |
| 142100 |
0002931N |
Fidèle Mariane |
Côtes de Bretagne |
|
3 |
A |
T |
FC |
43Quand les dires sont concordants, il y a un toponyme doublon au point de départ et d’arrivée. Pour reconstituer l’itinéraire, il faut alors simplement éliminer un des doublons, en gardant l’escale précisément datée (celle avec pointcall_function à « O »). C’est un des rôles dévolus à la variable net_route_marker introduite par les historiens, lorsqu’elle prend la valeur « A » (pour conserver l’escale), ou « Z » (pour éliminer le doublon).
44Mais parfois la sous-série G5 indique aussi d’où vient le navire qui a pris le congé au point d’observation. Par ailleurs, à Marseille on voit arriver des navires qui ont pris congé dans un port de l’Atlantique en déclarant se rendre à Marseille. Cela donne une séquence comme celle de la Suzanne (Tableau 4) : parti du Havre le 6 août 1787 d’après la source marseillaise, alors qu’il a pris son congé le 4 août, le navire a passé le détroit de Gibraltar le 24 août avant d’arriver à Marseille le 14 septembre. Ainsi, dans l’ordre chronologique, les intentions d’escales s’intercalent entre les escales avérées et pourraient faire accroire à la réalisation de tronçons qui n’ont pas eu lieu : la Suzanne n’a pas navigué du Havre à Marseille puis au Havre en deux jours. L’insertion de la valeur Z dans la variable net_route_marker dans ces escales « intentionnelles » (déclarées comme FC dans pointcall_status) permet d’éviter une reconstitution de trajectoire fausse.
Tableau 4. Ordonnancement des escales de la Suzanne, avec croisement des sources de Marseille et des congés de l’Amirauté
| data_ block_ local_ id |
ship_id |
ship_ name |
pointcall |
out_date |
in_date |
rank |
function |
net_ route_ marker |
status |
| 294615 |
0012925N |
Suzanne |
La Rochelle |
1787=06=01 |
None |
1 |
O |
A |
PC |
| 294615 |
0012925N |
Suzanne |
Seudre |
None |
1787>06>01! |
2 |
T |
A |
FC |
| 149798 |
0012925N |
Suzanne |
La Tremblade |
None |
1787=06=05 |
1 |
O |
A |
PC |
| 151273 |
0012925N |
Suzanne |
Marennes |
1787=06=19 |
None |
1 |
O |
A |
PC |
| 151273 |
0012925N |
Suzanne |
Le Havre |
None |
1787>06>19! |
2 |
T |
Z |
FC |
| 162284 |
0012925N |
Suzanne |
Le Havre |
1787=08=04 |
None |
1 |
O |
A |
PC |
| 162284 |
0012925N |
Suzanne |
Marseille |
None |
1787>08>04! |
2 |
T |
Z |
FC |
| 188143 |
0012925N |
Suzanne |
Le Havre |
1787=08=06 |
None |
1 |
A |
Z |
PC |
| 188143 |
0012925N |
Suzanne |
Détroit de Gibraltar |
None |
1787=08=24 |
2 |
None |
Algorithme : A Historien : Z |
PC |
| 188143 |
0012925N |
Suzanne |
Marseille |
None |
1787=09=14 |
3 |
O |
A |
PC |
- 31 pointcall_uncertainty vaut alors « invalidé ».
45Le Z du net_route_marker permet également de discréditer l’intention annoncée qui n’a pas pu se réaliser suivant le point de vue des historiens. Cela recouvre plusieurs cas de figure, les deux principaux sont les suivants. (I) L’intervalle de temps entre les escales ne permet pas la réalisation matérielle des tronçons. C’est le cas par exemple du Turgot, 0021517N, qui quitte Brest le 4 juillet 1787 pour aller en Amérique, mais qu’on retrouve à Bordeaux le 12 octobre 1787 lorsqu’il déclare partir pour la Guadeloupe. Sachant qu’à l’époque, un voyage aux Antilles comporte une longue escale aux îles, cela semble impossible : depuis Brest, le navire est passé par Bordeaux avant de filer vers la Guadeloupe. Ici, il faut souligner que cette analyse fait appel à une expertise humaine (l’historienne qui coordonne le programme), car les statistiques que nous avons produites sur la durée moyenne d’un trajet sont extrêmement variables, autant que la météo et les conditions de navigation de l’époque, rendant théoriquement possible deux voyages à la Guadeloupe. (II) On démontre que c’est une fausse déclaration31 parce qu’on ne voit pas le navire ressortir de la destination mentionnée, alors qu’on dispose du registre des sorties de cette destination annoncée, et que le même navire est observé ultérieurement ailleurs.
46Enfin, les pointcalls postérieurs chronologiquement au dernier point d’observation d’une suite de documents restent « invérifiables » car aucune observation ultérieure ne permet de s’assurer que les navires ont bien fait ce qu’ils avaient annoncé ; ainsi des destinations vers Saint-Brieuc et « Côtes de Bretagne » pour l’exemple de la Fidèle Mariane (Tableau 3). C’est également le cas de navires qui n’apparaissent que dans un seul document source, ou bien celui partant vers l’étranger ou des localités dont nous n’avons pas les registres (comme la Guadeloupe visitée par le Turgot).
47Sur la base des règles énoncées, un algorithme programmé met à jour la valeur de net_route_marker et pointcall_uncertainty. Comme la règle (I) concernant l’intervalle de temps est réellement impossible à évaluer, l’algorithme indique généralement « A » pour garder le point. Si la valeur de net_route_marker diffère de la proposition que les historiens de « Navigocorpus » avaient proposée, alors le pointcall est qualifié de « controversé ». Cela signifie qu’il faut se pencher attentivement sur le cas pour vérifier la faisabilité du tronçon dont une des extrémités est controversée.
- 32 S. Marzagalli & C. Pfister, 2014.
48La contre-vérification d’une déclaration (II) nécessite des informations supplémentaires qui n’ont pas toujours été disponibles au moment de la pose du marqueur par l’historien, ce qui justifie amplement cette comparaison avec les résultats de l’algorithme. Par exemple, lorsqu’on ne voit pas ressortir un navire de sa destination, mais que celle-ci est dans la même Amirauté que le port de départ, c’est normal puisqu’un aller-retour dans le ressort du même bureau d’Amirauté ne nécessite qu’un seul congé. Pour vérifier cette règle (II), nous avons pu nous servir, d’une part, d’une liste des sources saisies32, année par année retranscrites dans Portic, et, d’autre part, de notre liste d’appartenances étatiques à l’époque : une destination vers un port d’un État étranger ne peut être vérifiée. Par ailleurs, nous avons formalisé une autre information, celle des inclusions géographiques (la relation is_part_of qui relie deux Ports) qui permet de contourner l’imprécision des destinations déclarées par les capitaines. Par exemple, La Tremblade fait partie de l’estuaire de la Seudre : les capitaines peuvent annoncer un départ pour « Seudre », et si le navire ressort ensuite du port de La Tremblade, le trajet sera confirmé.
49Diverses itérations autour de la programmation de ces règles ont été nécessaires en raison des nombreuses pratiques maritimes particulières ou des emplacements portuaires complexes. Les premiers essais de l’algorithme sur un sous-ensemble de cas diversifiés sélectionnés ont mis en évidence l’existence de nouvelles instances qui n’étaient pas correctement évaluées par l’algorithme : certaines d’entre elles pouvaient enrichir les règles. Par exemple, concernant les contrôles de cohérence entre une destination annoncée et l’observation suivante, suivant la règle (II), il est apparu qu’il existait deux ports très proches (Port-Bail et Carteret) avec un seul bureau d’Amirauté, où l’officier ne notait pas sur le registre des congés le port exact de départ. Pour que l’algorithme les considère comme équivalents, ils ont été ajoutés à la liste des inclusions géographiques, l’un étant inclus dans l’autre et vice versa. Ces ajustements de l’algorithme ont impliqué de longues discussions entre historiens et informaticiens, afin de rester fidèle à la compréhension qu’ont les historiens des informations fournies par les sources. Nous avions besoin d’échanger nos points de vue et nos perceptions sur la base de faits, c’est-à-dire sur les résultats de l’algorithme sur un échantillon représentatif permettant de relever toutes les difficultés potentielles. Chaque fois qu’un cas spécifique a suscité un débat, nous l’avons ajouté au sous-ensemble des cas de test.
50Pour ce processus itératif, nous avons utilisé une sortie du programme assez lisible pour les historiens dans des fichiers Excel, regroupant les pointcalls dans l’ordre chronologique et par identifiants de navires. Des couleurs automatisées ont facilité la vérification manuelle : les lignes en surbrillance jaune indiquent les différences concernant la valeur de net_route_marker, celles en surbrillance grise indiquent que l’algorithme ne peut pas se prononcer, car il s’agit de la dernière étape de l’année pour ce navire. Toutes les variables pertinentes facilitant la décision finale de l’expert ont été ajoutées : les valeurs de pointcall_function et pointcall_status, les références aux sources (source_suite, source_doc_id), les dates de départ (pointcall_outdate) ou d’arrivée (pointcall_indate), le rang de l’escale (pointcall_rankfull), ainsi que des variables issues de l’enrichissement de Portic, telles la disponibilité du registre, le nom de l’Amirauté d’appartenance et la liste des multiples inclusions géographiques de ce pointcall.
51L’historienne qui coordonne « Portic » a contre-expertisé manuellement 10 000 lignes sur les 140 000 lignes – ce qui lui a pris 7 heures de travail –, permettant ainsi de produire la matrice de confusion associée (Tableau 5). Cela nous permet de calculer la précision (80 %) et le rappel (98 %) de l’algorithme. Bien que les cas de test ont permis de couvrir le plus grand nombre de situations possibles, certains faux positifs peuvent encore ne pas être détectés (net_route_marker est valide pour l’algorithme, mais en fait faux pour l’expert).
Tableau 5. Précision et rappel de l’algorithme vérifiant net_route_marker
| |
Résultats de l’algorithme |
| Contre-expertise de l’historien |
Z ok |
Z not ok |
| Valide les dires de l’algorithme |
8 531 |
345 |
| Rejette les dires de l’algorithme |
4 |
85 |
52Il est possible que la visualisation des trajectoires des navires dévoile d’autres corrections nécessaires de l’algorithme. Nous pensons cependant avoir qualifié de façon réfutable et fiable l’incertitude liée à chaque escale dans une grande majorité de cas. L’algorithme attribue donc un niveau d’incertitude à chaque pointcall (exprimée par la variable pointcall_uncertainty, avec six niveaux différents, à savoir : observé, confirmé, déclaré, controversé, invérifiable, invalidé), et vérifie la variable net_point_marker décrivant si le pointcall doit être conservé ou non pour construire l’itinéraire.
53Afin de construire l’itinéraire d’un navire donné, l’algorithme joint les escales de départ aux arrivées ordonnées chronologiquement par navire identifié, en éliminant les ports dont le net_route_marker est Z, sauf ceux controversés, et ce résultat est modélisé par l’entité Built_Travels (Figure 2). Il reconstruit à la fois les tronçons déclarés dans les sources, reconnus comme tels lorsque l’attribut direct prend la valeur vrai, ainsi que les retours implicites déduits (direct vaut faux) qui ont dû se faire, comme le trajet de La Tremblade à Marennes de la Suzanne entre le 5 juin 1787 et le 19 juin 1787 (Tableau 4). Ces tronçons reconstruits représentent 21 % des 70 990 tronçons qualifiés par notre approche. Chaque tronçon est lui-même qualifié par une valeur ordonnée d’incertitude (travel_uncertainty), qui se déduit à partir de l’incertitude de chaque extrémité, sachant que les valeurs d’incertitude plus forte sont prioritaires (Tableau 6). Par défaut un tronçon prend la valeur « déclaré », sauf si les deux extrémités sont au moins confirmées ou observées (il est alors confirmé) et sauf si une des deux extrémités est controversée (il est alors controversé) ou invalidée (il est alors invalidé). Si une des extrémités est controversée, et l’autre invalidée, le tronçon est invalidé dans son ensemble.
Tableau 6. Vue synthétique sur les niveaux de certitude qualifiée de chaque tronçon de navigation dans Portic
Travel_
uncertainty |
Signification |
pointcall_uncertainty
sur le départ et/ou l’arrivée |
Nombre de tronçons |
| 0 |
Confirmé |
Confirmé ou observé, aux deux extrémités |
35 355 |
| −1 |
Déclaré |
Déclaré, invérifiable à l’une des extrémités |
28 768 |
| −2 |
Controversé |
Controversé à l’une des extrémités |
1 323 |
| −3 |
Contredit |
Invalidé à l’une des extrémités |
5 544 |
54Chaque tronçon est donc qualifié par une valeur ordonnée d’incertitude, à laquelle on peut associer une sémiologie simple (avec des couleurs dans l’attribut déduit uncertainty_color) pour la représentation cartographique. Ceci, ainsi qu’un travail publié33 de calcul de trajectoire maritime n’intersectant jamais la côte et conservé dans l’attribut pointpath (liste des points en mer entre deux escales) et geom4326 (ligne incurvée reliant ces points en coordonnées géographiques) permet de produire la carte de la Figure 6, extraite de la visualisation interactive des trajectoires reconstituées34 qui favorise notamment la contre-vérification. Par exemple, l’algorithme confirme le passage du détroit de Gibraltar avec une valeur de net_route_marker à « A » alors qu’initialement il est marqué par un « Z » dans Navigocorpus (Tableau 4). Dans ce cas précis, il faudra corriger la base de données en conséquence. Cette controverse est mise en évidence ici par la couleur orange associée à ce niveau d’incertitude du tronçon.
Figure 6. Escale controversée au détroit de Gibraltar pour la Suzanne (0012925N) partie du Havre vers Marseille
Source. Image exportée de l’interface de visualisation de Portic (http://shiproutes.portic.fr/index.html?by_captain=false&captain_id_1=00012850&ship_id_1=0012925N&filter_red_steps=true&filter_orange_steps=false).
- 35 C. Lemercier & C. Ollivier, 2011.
55La reconstitution de trajectoires de navires identifiés à travers les différentes sources insérées dans Navigocorpus constitue l’aboutissement de nos travaux sur l’incertitude, dont les bases sémantiques ont été formalisées suivant un système de niveaux qui sont démontrables, donc réfutables. Ce travail, qui ouvre la voie à de nouvelles analyses historiques, a nécessité de distinguer l’incertitude historique de l’erreur de transcription : le corpus a été nettoyé au préalable de ces erreurs par une approche semi-automatisée de curation, dans un contexte de réalisation exigeant, voire épuisant35. Nous montrons en effet que si Navigocorpus est une base qui répond bien à l’ambition d’accueillir des corpus de navigation maritime assez différents, il fut absolument nécessaire de revisiter son modèle et de migrer ses données dans une base telle que Portic afin de développer une exploitation analytique automatisée satisfaisante, en dépit d’un contexte de saisie continue concomitante.
- 36 V. Bretagnolle et al., 2018.
56Il nous semble qu’il y a une leçon à tirer de cette expérience : les historiens, ou en général les non-informaticiens, ont besoin d’autonomie pour créer leurs données, les saisir et s’adapter en souplesse aux particularités de leurs différentes sources ou observations – nous avons déjà remarqué cette nécessité chez des biologistes, des écologues36. Ce qui les conduit automatiquement à produire ces bases de données non standardisées, comme Navigocorpus (parfois même non normalisées), qui agacent les spécialistes de bases de données et ceux qui doivent ensuite analyser ou produire des visualisations de ces corpus. Ces besoins contradictoires doivent être pris en compte et notre solution était celle d’une migration.
57Ce que nous avons également illustré, c’est qu’il est illusoire d’avancer que la standardisation pourrait se faire totalement automatiquement, sans l’intervention d’une expertise humaine. La mise en œuvre de différentes approches statistiques et logiques a montré l’utilité de ces dernières pour la curation de données, c’est-à-dire ici la standardisation de la base de données et la correction des erreurs. Parfois, les algorithmes se trompent, et c’est l’analyse fine de leur résultat qui le montre. Il est alors nécessaire que ces résultats soient présentés dans un format ergonomique, tel que nous l’avons fait, permettant de comprendre la logique de l’erreur (au sens inconsistance/incohérence) via une sélection pertinente d’attributs et de données, avec des codes couleurs améliorant leur lisibilité, pour rendre plus efficaces les échanges interdisciplinaires nécessaires à la curation.
58Notre approche s’inscrivant dans la science ouverte peut faciliter l’interaction avec des experts en intelligence artificielle ou en statistiques, afin de développer une méthode adaptée à l’identification des capitaines ou des navires. En effet, leur exactitude est questionnée et reste une perspective d’amélioration majeure.
59Plus largement, notre approche de contrôle de Navigocorpus, fondée sur la formalisation de règles expertes, interroge notre capacité à expliciter totalement la connaissance experte. L’expertise historienne a été sollicitée plusieurs fois sur des questions incertaines, et cela soulève une question de confiance entre les chercheurs et leurs pairs ou leur public. À plusieurs reprises, les résultats d’un algorithme se sont avérés différents de ceux des historiens, et notre décision a été de le montrer, notamment avec les tronçons qualifiés de controversés dans la reconstitution des trajectoires de navires. Cet article a tenté d’illustrer à quel point les données sont issues d’un processus de construction qui n’a rien de fluide ni de totalement rationnel : il vient aussi de contingences, d’hypothèses et d’un travail très proche de la source, et des conditions matérielles de leur production.
60Les données sont mises à la disposition de la communauté scientifique et de tout utilisateur via une API, qui donne librement accès aux données à tous les acteurs externes ou internes au projet. Elle s’est révélée fort utile lors des ateliers d’étude de cas, par exemple. Cet objet informatique a nécessité un effort de médiation, via un manuel pour les utilisateurs37 et un démonstrateur38 qui documente les champs accessibles en ligne. Grâce à cette concrétisation de l’ouverture des données, d’autres historiens extérieurs au projet, comme Jacques Boucard, s’attaquent à l’analyse de la fraude au sel sur l’Aunis en recoupant avec les données du Sound Toll Registers Online. En utilisant les données diffusées via l’API, nous avons développé différents outils d’interrogation et de visualisation Web à visée analytique, en particulier celui permettant de rechercher et visualiser le parcours reconstitué et qualifié des capitaines ou des navires39. Cet outil sous licence libre peut facilement être adapté à d’autres bases de données ou visualisations. Par exemple, le futur musée d’histoire maritime des Sables-d’Olonne est intéressé par la représentation interactive de la biographie d’un capitaine sablais du xviiie siècle.
Flux RSS
