Mémoire Vive Numéro 2

EDITORIAL

Nous voici presque en Février et ce numéro de Décembre part seulement pour l'imprimerie. Nous vous prions d'excuser ce retard bien indépendant de notre volonté. Mais " A quelque chose malheur est bon " dit le dicton et ce délai nous permet, après l'assemblée générale qui a eu lieu le Samedi 27 Janvier, de nous en faire l'écho notamment en ce qui concerne MEMOIRE VIVE.

Nous avons accepté, voici plus d'un an, de lancer ce bulletin. Nous en assumons volontiers l'organisation mais il ne nous semble ni raisonnable, ni souhaitable de continuer d'en assumer seuls tous les aspects. En effet pour que MEMOIRE VIVE réponde pleinement à sa vocation pédagogique et assume son rôle d'information technique et pratique, et si le bulletin a l'ambition d'être le lieu d'une réflexion méthodologique sur les apports de l'informatique à notre pratique quotidienne dans tous les domaines de l'histoire, il est nécessaire d'élargir le cercle de ceux qui contribuent à son élaboration. Sur notre proposition, l'assemblée générale du 27 Janvier a approuvé la création d'un comité de rédaction reflétant les différentes composantes de l'association et comprenant notamment des représentants des groupes de réflexion et de travail mis en place à cette même assemblée (p. 24). A ce nouveau comité de rédaction participeront désormais, outre nous-même, E. Brian, L. Citterio, J.-Ph. Genet, D. Letouzey, et G. Verroust. Nous espérons ainsi pouvoir étoffer dans les numéros suivants la rubrique " savoir-faire " qui, il faut bien l'avouer, le mériterait. Dans ce numéro de Mémoire Vive, Jean Marc Wolff poursuit sa réflexion sur l'informatique et l'histoire dans l'enseignement secondaire (p. 3). Après le bilan dressé dans le numéro 1, il étudie les perspectives. André Zysberg, quant à lui, poursuit son feuilleton sur l'élaboration d'une base de données historique (p. 10). Le logiciel que nous vous proposons aujourd'hui est DEMOBASE présenté dans ces pages par Claude Dumont (p. 20). Enfin dans la rubrique savoir faire Michèle Champagne inaugure dans ce numéro une série de " fiches " sur la conduite de projets informatiques MERISE (p.7). Enfin Le courrier des lecteurs, dont nous souhaiterions qu'il soit beaucoup plus fourni, s'ouvre dans ce numéro.

Caroline BOURLET, Jean-Marc WOLFF

SAVOIR-FAIRE

INFORMATIQUE ET HISTOIRE DANS L'ENSEIGNEMENT SECONDAIRE : BILAN ET PERSPECTIVES (2e PARTIE)

L'informatique appliquée à l'enseignement de l'histoire joue actuellement un faible r ôle dans le système éducatif français : la première partie de cet article tentait d'expliquer pourquoi.

La " pause " actuelle dans l'informatisation, qui est par bien des côtés un peu la retombée d'un " soufflé informatique " artificiel, doit permettre de réfléchir sur les finalités spécifiques de l'informatique en Histoire et en Géographie.

1 - Utiliser les logiciels commerciaux

La fin du contrat qui liait l'éducation nationale à la firme THOMSON, et l'alignement progressif sur les standards dominant le marché privé des micros, PC mais aussi APPLE-MACINTOSH (qui opère une percée dans les établissements privés), nécessitent de repenser les usages de l'ordinateur au collège ou au lycée pour leur donner un nouveau souffle. La baisse des prix de beaucoup de logiciels commerciaux, qu'accompagne la politique des licences mixtes permettant aux établissements scolaires de les acquérir à moindre prix, ne peut pas ne pas avoir de répercussions sur l'utilisation des matériels. Elle contribue à combler le fossé qui sépare le monde de l'éducation du reste de la société.

La commodité d'emploi de ces logiciels, conçus par des spécialistes, constamment améliorés, et dont la manipulation requiert de moins en moins la lecture d'indigestes et volumineux modes d'emploi du fait d'une certaine standardisation de l'environnement, rend obsolète la plupart des logiciels " maison " de l'éducation nationale, qui ne sont destinés qu'à un usage spécifique, et dont le coût est prohibitif au regard de leur utilité. Payer ainsi 300 F un logiciel qui ne sert qu'à un niveau de classe pendant une heure au maximum dans l'année est une aberration économique. Autant acheter pour le même prix un petit logiciel de traitement de textes qui pourra servir à tout le monde, ou un logiciel de CAO de 5000 F susceptible de servir à la réalisation de dizaines de séquences.

Il me semble donc que c'est à partir des logiciels commerciaux qu'on devrait fabriquer des produits spécifiques, mais aussi susceptibles d'adaptation et d'usage dans les autres matières.

Un logiciel de simulation graphique devrait ainsi pouvoir être utilisé aussi bien par les professeurs en histoire, en géographie, en mathématiques, en physique ou en chimie. Préciser l'utilité d'un traitement de texte ou d'un logiciel graphique est inutile ici. Il existe désormais d'excellents logiciels dans le commerce, et le travail spécifique du professeur ou d'équipes à créer fonctionnant au sein des CDDP ou des MAFPEN pourrait être de nourrir ces logiciels avec des données actualisées, chiffrées ou non, éventuellement téléchargeables par la communauté des enseignants. On peut penser ainsi à des données statistiques, en particulier locales et régionales, à des actualisations de chronologies, mais aussi à l'élaboration en commun des dictionnaires de définitions.

Mais le principal objectif de l'enseignement de l'histoire-géographie en Collège et en Lycée mis en avant par l'Inspection Générale est de conduire les élèves à une meilleure compréhension du monde contemporain. L'informatisation du secteur tertiaire étant un phénomène majeur de la reprise économique actuelle, l'utilisation en classe des ordinateurs permet de mettre en contact les élèves avec les outils informatiques, en leur montrant en quoi ils révolutionnent les pratiques du travail. L'accès à des banques de données spécialisées (et l'architecture télématique centralisée envisagée permettrait d'en constituer) permettrait l'apprentissage de stratégies de recherches dans un environnement caractérisé par le foisonnement de l'information.

2 - Coordonner les usages en aval et en amont de l'heure d'enseignement.

Aujourd'hui l'informatique, quand elle est utilisée par les professeurs, l'est avant ou après les cours. L'utilisation des traitements de texte, par leur souplesse d'adaptation, permet des économies de temps importantes, pour la conception des cours et des contrôles, pour la confection de documents pour les cours. L'imprimante de l'ordinateur couplée avec la photocopieuse de l'établissement - quand elle existe et est accessible aux enseignants, ce qui n'est pas le cas partout - permet une amélioration notable de l'efficacité de l'enseignement. Que de temps perdu jusque là à recopier à la main des exercices sur des stencils, à copier des tableaux de chiffres pour en faire de laborieuses représentations graphiques au tableau ! Si la gestion par le professeur des notes des élèves par ordinateur me semble, à l'usage, plus une perte de temps qu'un gain, l'utilisation des traitements de texte, des logiciels graphiques, et la circulation des documents informatiques ainsi élaborés, au sein de l'établissement par l'entremise du responsable du cabinet, ou grâce à des structures à mettre en place au niveau local, départemental, académique, ou national - et à ce propos il faut signaler qu'existent déjà des rubriques spécialisées dans la revue de l'APHG " Historiens et Géographes " - permettrait de se passer du truchement papier et d'éviter la ressaisie.

3 - Réfléchir à l'utilisation en classe, en attendant la prochaine vague d'équipements

En ce qui concerne les séquences en classe, avec manipulation des ordinateurs, je crois qu'il faut y renoncer pour l'instant quand les machines ne sont pas en nombre suffisant, et obtenir que les salles d'informatique comprennent au moins une machine performante pour deux élèves.

En attendant il ne faut pas négliger le fait que beaucoup d'élèves possèdent des minitels chez eux, et que de nombreux services minitel permettent la recherche d'informations utiles et cohérentes avec les programmes, dans le cadre d'exercices à la maison (annuaire électronique, services statistiques de l'INSEE, informations sur les entreprises des services de l'INPI-EURIDILE). Il ne faut pas oublier non plus le fait que quelques élèves possèdent des micros, et favoriser leur usage pour des devoirs, des exposés, des expositions, etc... Il faut obtenir que les élèves aient un accès libre aux machines ou au minitel pendant les heures de permanence. Pourquoi ne pas en installer en accès libre dans les Médiathèques ? C'est, je crois, par ces actions modestes que l'on peut banaliser l'emploi de l'informatique dans nos matières.

Mais il faut aussi nous préparer à être présents lorsque les machines seront plus nombreuses, afin que les professeurs de sciences ne soient pas les seuls à les utiliser. Il existe des outils relativement simples d'emploi pour fabriquer des séquences d'E.A.O., permettant de combiner texte et documents graphiques en provenance de logiciels divers : sur MACINTOSH par exemple HYPERCARD permet d'enchaîner facilement ces documents après les avoir ou non modifiés, de gérer des arbres de choix à partir de la connaissance d'un nombre réduit d'instructions. Des scénarios sont commercialisés en histoire, comme " Grandes découvertes " qui tourne sur HYPERCARD mais ne semblent pas répondre aux exigences du secondaire. Il faudrait réfléchir à des séquences où l'ordinateur serait irremplaçable pour atteindre des objectifs pédagogiques précis. Je pense par exemple à des simulations, à des exercices d'analyse de sujets de dissertation, à des exercices de localisation cartographique. J'ai à titre expérimental monté avec des collègues, dans le cadre d'un stage MAFPEN d'une journée, une petite séquence de la Cinquième République, centrée sur le problème du passage d'un texte institutionnel à l'organigramme. Des didacticiels plus complexes existent, comme COURSE BUILDER ou DR. LEO d'APIGRAPH pour MACINTOSH. Les possibilités de pilotage par un logiciel de banques d'images stockées sur vidéodisques sont aussi une source d'inspiration possible. Ainsi, le CDDP de Créteil fait-il des démonstrations de détournement d'un vidéodisque touristique édité par la région Centre pour un cours portant sur l'architecture renaissante, piloté par un PC. Un vidéodisque spécifique couvrirait largement les besoins iconographiques des cours de Collèges et de Lycées, et pourrait fournir la base d'un travail personnel de recherche par les élèves.

L'essentiel est de penser des applications où l'ordinateur est à la fois irremplaçable et indispensable pour atteindre un objectif pédagogique précis. Tout autre emploi fait perdre à l'outil sa crédibilité, en en faisant un " gadget " budgétivore.

Ces applications irremplaçables et indispensables, c'est à nous de les concevoir. MEMOIRE VIVE appelle donc tous les collègues à mettre sur la place publique leurs projets, leurs souhaits, leurs critiques. La " pause " actuelle devrait permettre aux idées de précéder les matériels. Faire le contraire serait une fois de plus aller à l'échec.

Jean-Marc WOLFF
Lycée franco-allemand de Buc

INTRODUCTION A LA CONDUITE DE PROJETS INFORMATIQUES PAR LA METHODE MERISE

La facilité de mise en oeuvre des bases de données encourage la multiplication des projets documentaires et accroît ainsi le risque d'incohérence. En effet, les multiples applications documentaires réalisées sur des architectures différentes, au lieu de faciliter les communications entre les équipes de recherche, peuvent être un obstacle à véhiculer l'information. Cette nécessité de cohérence entre les bases de données résulte d'une part des contraintes liées à l'évolution des technologies de l'information, et d'autre part des besoins des historiens, usagers de l'informatique, qui sont plus complexes et plus évolutifs. Ceci implique de respecter complètement les besoins en informatique documentaire (pris au sens de bases de données documentaires classiques ou encore de système de gestion de base de données relationnelle), pour éviter une pure automatisation des habitudes " papier ".

C'est dans cet état d'esprit que le Ministère de l'Industrie, en relation avec sept sociétés de services et de conseils en informatique, a mis au point en 1977 une méthode de conception et de réalisation de projets informatiques. Mieux connue sous le nom de MERISE, cette méthodologie fournit une trame directive pour l'amélioration des applications existantes et le développement des applications nouvelles. Nous vous proposons d'animer une série d'articles dans MEMOIRE VIVE sur le processus de construction d'un projet informatique à l'aide de la démarche MERISE dans le cycle de vie d'un projet (voir le schéma ci-dessous). Chacune de ces phases sera étudiée sous la forme de feuilles de référence, une sorte de guide indicatif, dont le but sera de recenser les problèmes à résoudre et les tâches à entreprendre à tous les stades de l'avancement d'un projet. Dans nos prochaines publications nous étudierons les sujets suivants :

ETAPES D'AUTOMATISATION

I - L'étude d'opportunité et de faisabilité

Rédaction d'un dossier d'étude exprimant qualitativement les éléments d'information à intégrer au projet :

II - La rédaction du cahier des charges

L'élaboration du cahier des charges consiste en la rédaction d'un bilan (charges, délais, calendrier, coûts). Par cette procédure, l'informaticien ou les responsables de la réalisation du projet s'engage(nt) à réaliser le projet en respectant le contenu et le délai, tels que définis dans le cahier des charges.

III - La conception détaillée et la réalisation

L'équipe de recherche conjointement avec l'informaticien-conseil définit l'architecture des divers éléments du système informatique (données, fichiers, traitements...) en respectant les spécifications telles que décrites dans le cahier des charges.
Cette étape regroupe la conception des programmes et leur mise au point. Les tests confirment la validité des travaux informatiques.

IV - Le lancement et la mise en oeuvre

Cette étape a pour objet d'expertiser le comportement du système d'information dans les conditions réelles de fonctionnement et sur des périodes significatives.

V - L'exploitation et l'entretien

Cette phase met fin à la réalisation de l'application. Elle consiste à évaluer le niveau technique et les performances de l'application.

Michèle CHAMPAGNE

Bibliographie sur MERISE

Il existe plusieurs ouvrages publiés sur MERISE mais de qualités très diverses. Nous vous proposons deux ouvrages qui recensent de manière exhaustive les principes de MERISE.

H. TARDIEU, A. ROCHFELD, R. COLLETTI, La méthode Merise : Principes et outils. Paris, Ed. d'organisation, 1986.

Yves TABOURIER, De l'autre coté de Merise : système d'information et modèles d'entreprise. Paris, ed. d'organisation, 1986.

FORMATION

LE FEUILLETON DE MEMOIRE VIVE :
TOUT CE QUE VOUS AVEZ TOUJOURS VOULU SAVOIR SUR L'EXPLOITATION INFORMATIQUE DES CORPUS PAR LES HISTORIENS SANS AVOIR JAMAIS OSE LE DEMANDER...
Premier épisode : Et l'historien créa sa base de données

Vous disposez d'un micro-ordinateur de la famillle IBM PC et d'un logiciel de gestion de base de données tel que DBASE III ou FOXBASE. Vous voulez vous servir de ces outils pour exploiter un gisement documentaire... Je suppose également que vous avez fait l'apprentissage des commandes élémentaires de MSDOS.
L'on a déjà exposé l'importance de la réflexion sur les sources documentaires et leur mise en oeuvre informatique. Cette étape précède la constitution et l'exploitation des données. Elle représentente l'indispensable préambule. Il s'agit de fixer ses objectifs. Il s'agit d'analyser et de critiquer les sources disponibles. Sans ordinateur, cette première étape apparait déjà comme une nécessité du métier d'historien. Avec l'emploi de l'informatique, qui ne supporte pas l'ambiguité ou le " flou ", quant au choix et à la formalisation de l'information, cette démarche devient une obligation.

L'historien aux champs

Ce travail de décorticage ne suffit pas. Il vous faut aussi bien connaître les possibilités du logiciel que vous utiliserez. Une base de données créée avec DBASE III ou FOXBASE peut contenir jusqu'à un milliard d'enregistrements (un enregistrement équivaut à une " fiche " informatique), du moins si le support (disquette ou disque dur) dont vous vous servez en permet le stockage. Ceci dit, mieux vaut éviter de constituer de trop gros fichiers, dont la gestion devient nécessairement fastidieuse et aussi délicate, notamment quand on opère des mises à jour, des corrections, des copies de sauvegarde, etc. Il est tellement facile de fragmenter un corpus documentaire en plusieurs fichiers, puis de les regrouper éventuellement au fur et à mesure des besoins de l'exploitation informatique, qu'il serait stupide de s'en priver. A l'intérieur de chaque enregistrement, les informations, sont rangées ou réparties en rubriques ou champs. Chaque enregistrement d'un même fichier possède exactement la même structure, c'est à dire les mêmes champs, avec des caractéristiques identiques. Une fiche DBASE admet un maximum de 128 champs, ce qui n'est pas toujours suffisant. En outre, le nombre total de caractères ou octets compris dans un seul enregistrement ne doit pas excéder 4. 000 (les noms des champs ne sont évidemment pas compris dans la longueur d'un enregistrement), ce qui apparaît parfois un peu juste...

Créer un fichier de données, c'est définir la structure ou le modèle de ses enregistrements, autrement dit déclarer au logiciel quels sont les champs qui représenteront l'ossature de votre ensemble d'informations. Les concepteurs de DBASE ont prévu 5 sortes de champ pour constituer un fichier de données.

LE CHAMP DE TYPE caractère admet tous les caractères du clavier: lettres, chiffres et signes. Pour ce qui concerne les caractères alphabétiques, il faut savoir d'emblée, quand il s'agit de données, que la même lettre, en majuscule et en minuscule, ne représente pas le même caractère pour le micro-ordinateur. La longueur maximale d'un champ de type caractère a été fixée à 256 positions. Un champ caractère, même s'il n'est pas rempli, n'est jamais vide. Dans ce cas, Il contiendra un nombre de " blancs " ou d'espaces égal à sa longueur de déclaration... Ainsi, la chaîne de caractère " Albert de Follempré " exigera un champ contenant au moins 19 positions. Si le champ n'est pas complètement occupé par les caractères que vous avez entrés, DBASE le complètera avec des blancs placés sur la droite.

UN CHAMP numérique ne peut être saisi qu'avec des chiffres ou avec le signe point séparant la partie entière de la partie décimale. Un champ numérique possède au plus 19 positions (attention, le point décimal compte toujours pour une position). La dimension de la partie décimale est comprise entre 0 et 15 et doit être au moins inférieure de deux positions à la dimension totale. Par exemple, le nombre 4.789 nécessitera une déclaration d'au moins 5 positions pour la dimension totale et de trois pour la partie décimale. Un champ numérique non rempli contient la valeur 0 par défaut. Si la longueur effective d'un nombre est inférieure à celle de la définition du champ, le logiciel complète avec des blancs sur la gauche. Si un champ a été déclaré comme numérique, toute tentative pour entrer des caractères autres que le point et les chiffres de 0 à 9 entraînera un refus et un message d'erreur.

DBASE admet aussi des CHAMPS DE TYPE logique. Il n'y a pas besoin de déclarer leur longueur, qui est toujours égale à une position. La valeur obligée d'un champ logique est la lettre T (pour " true ") ou la lettre F (pour " false "). Il est indifférent de taper une lettre majuscule ou une lettre minuscule. Les champs logiques sont très utiles, car ils prennent peu de place et leur exploitation s'avère particulièrement commode quand il faut extraire ou sélectionnner les enregistrements répondant à tel et/ou tel critère. Une question complexe peut parfois correspondre à une réponse simple : vrai ou faux, oui ou non. Un champ logique non rempli prend la valeur F par défaut. Le logiciel refuse tout caractère différent de T, t, f ou F.

DBASE reconnaît aussi des CHAMPS DE TYPE date, ce qui est bien sûr très utile pour des historiens... Pas tous les historiens cependant, car ce logiciel ne peut traiter comme des dates que les événements postérieurs à la fin de l'année 1582 (exactement à partir du 15 octobre 1582), depuis la réforme du calendrier qui se produisit sous le pontificat de Grégoire XIII. Un champ de type date est saisi sous une forme numérique. C'est au niveau du traitement des données que réside l'intérêt de ce type de champ, car il devient alors très facile, comme nous le verrons, de commander diverses opérations arithmétiques et logiques sur des dates, par exemple de calculer des durées. Attention : un champ de type " date " doit être complètement rempli ou laissé entièrement vierge. Ceci signifie que pour saisir une date, il faut connaître obligatoirement ses trois éléments, jour, mois et année. Si vous avez affaire à des dates comportant parfois des informations manquantes, il vaudra mieux recourir à des champs de type caractère ou de type numérique.

Nous avons vu que la dimension d'un champ de type caractère est limitée à 256 positions. C'est suffisant pour la plupart des applications. Toutefois, on peut avoir besoin de saisir beaucoup plus de caractères, par exemple pour entrer le résumé d'un livre, l'analyse d'un acte ou une notice biographique. Dans ce cas, nous aurons recours à un ou plusieurs CHAMPS DE TYPE memo. Lors de la saisie des données, DBASE se comportera comme un logiciel de traitement de texte. Pour chaque rubrique déclarée en mémo, vous pourrez entrer jusqu'à 5.000 caractères. Quelles sont les différences entre un champ caractère et un champ mémo. Le champ caractère peut faire très aisément l'objet de tris et de recherches conditionnelles, tandis qu'un champ mémo n'est pas directement interrogeable. On peut seulement afficher ou imprimer son contenu. L'avantage du champ memo tient à son encombrement variable, qui correspondra à sa longueur réelle, tandis qu'un champ de type caractère, qu'il ait été rempli ou non, occupera toujours le même espace, celui correspondant à sa déclaration initiale. Par ailleurs, les champs de type mémo constituent des fichiers particuliers qui sont reliés au fichier principal par le moyen du numéro d'enregistrement.

L'on entrevoit ici l'un des inconvénients majeurs de ce logiciel. Contrairement à d'autres systèmes de gestion de base de données tels que TEXTO, les enregistrements créés sous DBASE sont nécessairement de longueur fixe (saufs les champs memo traités à part). Que l'information prévue pour chaque rubrique soit présente ou non, il faudra toujours le même espace sur le support informatique... Il y a donc un certain gaspillage, qui est difficilement évitable, surtout lorsque des champs sont remplis peu fréquemment. Dans ce cas, un fichier ressemblera à un morceau de gruyère...

Des vaisseaux et des hommes

Nous développerons une application réelle en suivant pas à pas, d'un épisode de notre feuilleton à l'autre, les étapes successives de son exploitation informatique. C'est la façon la plus concrète de vous montrer les avantages et aussi les limites de la gestion de base de données sur un micro-ordinateur. Notre base de données sera constituée à partir du " Répertoire des expéditions négrières françaises du XVIIIe siècle ". Cet ouvrage est dû aux remarquables travaux d'un chercheur prématurément disparu en 1975, Jean METTAS, dont les milliers de fiches accumulées en vue d'une thèse, ont été publiées par Serge et Mireille DAGET. Ces fiches représentent un gros travail de dépouillement, qui a été effectué à partir de sources variées et originales, dont les références sont toujours citées à la fin de chaque notice. Propriété des négociants, les navires négriers appareillaient de Nantes, Bordeaux, Le-Havre, Marseille et de bien d'autres ports. Leurs cales contenaient des marchandises variées (armes, alcool, quincaillerie, verroterie et tissus) qui étaient troquées à la côte d'Afrique contre des esclaves. Les sites de traite s'échelonnaient de l'actuel Sénégal à l'Angola et même, au-delà du cap de Bonne-Espérance jusqu'au Mozambique. Lorsque les navires avaient fait leur plein de " bois d'ébène ", ils traversaient l'océan afin de gagner les Antilles, où les captifs étaient vendus aux planteurs, qui réglaient une partie de leurs achats en produits tropicaux. Chargés de sucre, de café et d'indigo, les navires retournaient à leur port d'attache : la dernière étape de ce trafic triangulaire était ainsi bouclée au terme d'une campagne qui durait 12 à 18 mois.

Voici une fiche extraite du " Répertoire " de Jean METTAS :

L'Amériquain     1735/7     294
 1  -	150 tx.
 2  -	38 hommes, 7 morts.
 3  -	René Brée du Viviers.
 4  -	Vve Montaudouin et fils.
 6  -	Nantes, 10 nov. 1735.
 7  -	Cap de Mesurade, 18-26 déc. 1735.
 8  -	Traite jusqu'à Apa, 360 noirs; départ 4 mais 1736;
		Ile de Prince, 19 mai-5 juin 1736.
 9  -	57 morts au total
10 -	Cap, 9 août-10 déc. 1736.
11 -	Nantes, 12 février 1737.
12 -	15 mois.

	Le navire relâche au cap de Mesurade " pour y faire des vivres sans
y avoir rien autre chose traîté ". 1 marin mort à la côte; 1 en mer, 5 à
Saint-Domingue.

Source : Nantes, B 4587.
      

Après l'énoncé du nom du navire, les auteurs de ce répertoire ont découpé en 12 rubriques les informations relatives à une campagne. Une rubrique vide n'est pas désignée. En tête de la fiche, la mention " 1735/7 " veut dire qu'il s'agit de la septième expédition nantaise pour l'année 1735; le nombre " 294 " désigne la 294ième sur l'ensemble des départs du port de Nantes au XVIIIe siècle. La rubrique 1 donne la capacité d'emport du navire exprimée en tonneaux de jauge. L'effectif de l'équipage, suivi éventuellement par le nombre de morts (parmi l'équipage et y compris le capitaine) figure dans la rubrique 2. La troisième rubrique comporte le nom et les prénoms du capitaine et, le cas échéant, ceux de son remplaçant si le commandant meurt en cours de route ou reste aux Antilles pour percevoir des créances. Les armateurs figurent à la rubrique suivante. Il peut s'agir d'individus, de familles ou de sociétés en nom collectif, dont le nombre varie d'une expédition à l'autre, même s'il atteint rarement plus de deux ou trois associés, ce qui posera un problème pour la structure de la " fiche " informatique. La rubrique 5 (absente ici) donne le port d'armement du navire quand celui-ci n'a pas été préparé dans son port d'attache. La date de départ est mentionnée à la rubrique 6. Les rubriques suivantes, qui décrivent les étapes successives du trafic, sont beaucoup plus complexes.

La septième contient des informations relatives aux escales avant le début des opérations de traite (lieux et dates). La huitième s'applique au troc des captifs : nom du ou des sites de traite avec, pour chacun d'entre eux, la durée des opérations et le nombre de Noirs échangés... L'on y trouve aussi la mention de l'escale dite de " rafraîchissement " avant le départ pour les îles d'Amérique. La neuvième rubrique nous renseigne sur le nombre de morts parmi les Noirs. Son niveau de précision est très variable. Il s'agit le plus souvent du nombre total des décès, tandis que leur répartition par phase (traite, escales avant la traversée, voyage, vente en Amérique) n'est connue que pour un petit nombre de fiches. La dixième rubrique concerne les ventes aux Antilles : lieux, dates, nombre de captifs débarqués et vendus. La destination finale du navire apparaît à la onzième rubrique. Si la campagne s'achève ordinairement, la fiche indique le port et la date de retour, ainsi que la durée de l'ensemble du voyage (douzième et dernière rubrique). Si ce n'est pas le cas (prise, naufrage, vente du navire), l'évènement est mentionné avec éventuellement un lieu et une date. Au bas de chaque notice figurent les références des sources, ainsi que des informations complémentaires sur la campagne.

Le passage des sources aux données

Votre modèle de fiche doit tenir compte à la fois des caractéristiques de vos sources, des types de résultats que vous attendez et aussi des capacités du logiciel que vous avez choisi. Ce modèle sera un compromis. Il faut d'abord concevoir " sur le papier " (comme une sorte de plan) la structure d'enregistrement (la " fiche " informatique). Ne craignez pas d'y passer beaucoup de temps...A partir de ce " Répertoire des expéditions négrières au XVIIIe siècle ", je voudrais développer une base de données qui soit interrogeable sur un micro-ordinateur. Pourquoi faire ? Pour rechercher rapidement et facilement des informations dispersées d'une fiche à l'autre, par exemple pour suivre les différents voyages effectués par un même navire ou par un même capitaine... Ou encore pour retrouver toutes les campagnes préparées par tel ou tel armateur entre telle et telle date ... Et ainsi de suite jusqu'au plus compliqué. Une autre visée complémentaire consisterait à dresser des tables par ordre alphabétique ou par ordre chronologique de toutes les informations nominatives, des tables simples ou des tables de références croisées qui comparent le contenu de plusieurs rubriques... Ces investigations obéissent à des finalités documentaires. Je voudrais aussi opérer un certain nombre de comptages : sur la mortalité de l'équipage et sur celle des captifs, sur les lieux de traite et sur les lieux de vente... Ces statistiques peuvent porter sur une seule rubrique ou sur plusieurs et dans ce cas, il s'agira de confectionner des tableaux à double entrée. Ce projet devrait donc permettre deux types d'exploitation : d'une part, la recherche ponctuelle ou systématique d'informations (nominatives ou non) qui répondent à un ou plusieurs critères; d'autre part, la production de résultats quantitatifs. ces deux stratégies ne sont pas antagonistes. Il faudra néanmoins, en tenant compte des possibilités du logiciel, concevoir un modèle d'enregistrement qui s'adapte aux objectifs que j'ai énoncés plus haut. Comment y parvenir ?

La solution ne consiste pas à reproduire telle quelle, sur un support informatique, la fiche imprimée, comme s'il s'agissait d'un traitement de texte... Il est vrai que les renseignements du " Répertoire " sont ventilés en un nombre déterminé de rubriques, et que l'on retrouve les mêmes rubriques, toujours dans le même ordre, d'une fiche à l'autre. Autrement dit, il existe déjà, au niveau de la source documentaire, une structure répétitive, ce qui nous facilite la tâche. Malgré cela, l'architecture de la fiche imprimée ne convient pas pour la réalisation de la " fiche " informatique. On observe que la plupart des rubriques du " Répertoire " possèdent chacune plusieurs informations. C'est ainsi que la rubrique 2 contient à la fois l'effectif de l'équipage et le nombre de morts parmi celui-ci; ou encore, la rubrique 6 indique à la fois le port de départ et la date de départ. Certes, on peut parfaitement loger plusieurs données de signification ou de nature différentes dans un même champ de type caractère ou de type numérique. Il suffira que la longueur et le type du champ soient adéquats... Mais il faudra aussi que le logiciel puisse repérer infailliblement les différentes informations, afin d'opérer des recherches, des tris, des calculs... Et c'est bien là que le bât blesse... Avec DBASE, une information doit correspondre à un seul champ si on veut l'atteindre directement, au moyen des commandes ordinaires du logiciel (donc sans programmation spécifique), afin d'obtenir des résulats documentaires ou statistiques. Cet obstacle s'avère aisément franchissable quand la séquence est assez simple ou limitée à quelques renseignements qui reviennent toujours de la même façon. Dans le cas de la rubrique 2 du " Répertoire ", par exemple, il suffira de définir deux champs, l'un correspondant à l'effectif de l'équipage, l'autre au nombre de morts. Même tactique pour la rubrique 6 : nous aurons un champ pour le port de départ et un champ (de type date) pour la date de départ du navire.

Cette façon de procéder ne convient pas pour les rubriques 7, 8 et 10, où l'on trouve non seulement des informations de nature différente (des noms géographiques, des valeurs numériques concernant le nombre de captifs, des dates de séjour ou d'escale), mais aussi une succession d'informations en nombre indéterminé. Ainsi, à la rubrique 8, les opérations de traite peuvent se circonscrire à un seul lieu ou au contraire s'échelonner sur plusieurs sites. La rubrique mentionnant " le " nom de l'armateur pose également un problème analogue, car il peut y avoir plusieurs armateurs... DBASE n'offre pas, comme d'autres logiciels plus tournés vers les applications documentaires, la possibilité de créer des sous-champs qui se rattachent logiquement à un champ principal. Il sera illusoire de définir des champs " ARMATEUR1 ", " ARMATEUR2 ", " ARMATEUR3 ", " ARMATEUR4 ", etc. Et de procéder de même pour les lieux de traite, les dates de traite... D'une part, une telle multiplication des champs entraîne un beau gaspillage de l'espace disque; d'autre part, vous ne pourrez pas aisément faire porter une commande sur l'ensemble des champs relatifs aux armateurs ou aux lieux de traite. Si vous espérez trouver les navires armés par " DUPOND et Cie ", il vous faudra interroger simultanément ou successivement les différents champs " ARMATEUR1 ", " ARMATEUR2 ", " ARMATEUR ", etc., où la chaîne de caractères " DUPOND et Cie " risque de se trouver... Pire encore, en procédant de cette manière, il vous sera impossible d'imprimer une seule liste de " tous " les armateurs, mais seulement une liste du champ " ARMATEUR1 ", puis une liste du champ " ARMATEUR2 ", etc...

La programmation permet de régler ce problème de façon à peu près satisfaisante. Soulignons d'abord que vous pouvez aisément confectionner des programmes sans " sortir " de DBASE. Un épisode de notre feuilleton sera spécifiquement consacré à la programmation " sous " DBASE. Au niveau de la saisie ou de l'entrée des données, il faudra néanmoins préparer l'étape de programmation. Cette préparation consiste à " baliser " le contenu d'un champ qui comportera plusieurs informations (de même nature), au moyen d'un signe servant de séparateur. Tout cela vous apparaît peut-être un peu nébuleux... Prenons un exemple. Nous définirons un seul champ ARMATEURS, auquel nous attribuerons une longueur de 100 caractères. Lorsqu'il y aura plusieurs armateurs, leurs noms respectifs se suivront au sein du même champ, mais ils seront séparés les uns des autres par le signe " / ". Nous aurions pu choisir une virgule ou un point comme " séparateur ", c'est-à-dire nécessairement un caractère qui n'est jamais employé dans un nom de personne. Le programme, qui sera conçu et expérimenté " après " la saisie des données, se servira de ce séparateur pour distinguer les différents noms, du moins si le navire a été armé par plusieurs personnes ou sociétés. Cette méthode revient en fait à créer (par programmation) des sous-champs...

Je voudrais aussi évoquer un autre type de difficulté, assez voisin du précédent, qui ne s'est pas présenté pour le fichier des expéditions négrières, mais que vous risquez fort de rencontrer en traitant vos applications. Nous avons vu qu'une rubrique " source " peut comporter des réponses multiples, qui ne s'excluent pas les unes par rapport aux autres. Dans ce cas, les spécialistes de dépouillement d'enquête disent qu'il s'agit de questions dont les modalités de réponses ne sont pas exclusives. Si le nombre des réponses possibles est très élevé et surtout si leur éventail n'est pas déjà connu à l'avance, il faudra recourir à la solution précédente, c'est à dire créer des sous-champs avec un séparateur, puis analyser le contenu du champ à l'aide d'un programme. Quand l'ensemble des réponses possibles se circonscrit à un vocabulaire assez restreint, il existe une autre façon de procéder moins lourde et plus directe, qui ne nécessite pas de programmation : Il suffira de convertir chaque modalité de réponse en un champ de type logique. L'usage intensif des champs de type logique ne présente aucun inconvénient, car ceux-ci ne " mangent " pas beaucoup de place : seulement un caractère par champ. Il faut aussi savoir que les commandes de recherche sur un champ logique sont les plus simples à écrire. N'oublions pas néanmoins que le nombre de champs est limité (trop limité) à 128...

La préparation de la structure d'enregistrement représente donc une opération très délicate. Il n'y a pas de " recette ". Tout dépend des résultats que vous souhaitez obtenir et aussi de la complexité des sources. Dans certains cas, on ne pourra pas se contenter de développer une seule base de données. Il faudra alors générer plusieurs fichiers et prévoir des liens ou des relations entre ces fichiers, bref entreprendre un véritable système d'information. Nous traiterons des bases de données " multi-fichiers " dans un autre feuilleton. A chaque étape suffit sa peine...

Toutes les informations du " Répertoire des expéditions négrières " figureront-elles dans le fichier des " données " ? On refusera tout d'abord de se borner au seul prélèvement des informations " utiles ", à concevoir une " fiche informatique " dont les champs correspondraient uniquement à nos objectifs de recherche. D'abord, parce que cette stratégie n'est pas toujours la plus " payante ". Certains renseignements, qui ne nous intéressent pas d'emblée, se révèleront peut-être significatifs. On ne peut pas non plus exclure l'idée d'une communication des données. Cette perspective nécessite donc un modèle qui respecte autant que possible la richesse de la documentation originale. Je propose une structure, dont la finalité est avant tout pédagogique, qui s'efforce néanmoins d'appliquer les règles exposées plus haut. Une structure qui n'apparaît pas complètement exhaustive, car elle a nécessité des choix. Certaines informations, dont le contenu s'avère trop ambigu ou présenté, d'une fiche imprimée à l'autre, sous des formes trop irrégulières, ne seront pas comprises dans la base de données (ou alors il faudrait les inclure dans un champ de type memo). C'est le cas pour la rubrique 8 (relative aux escales qui précèdent la traite), ainsi que pour plusieurs informations quantitatives des rubriques 8 et 9 sur la traite elle-même et sur la vente des captifs aux Antilles. On sait que les déclarations des capitaines et des armateurs sur le commerce du " bois d'ébène " ne respiraient pas la franchise et l'honnêteté, et que la fraude, à divers niveaux était monnaie courante.

" CREATE ", répéta-t-elle, en pianotant distraitement sur son clavier, " vous avez bien dit CREATE "...

La création du fichier de données fait appel à la commande CREATE. Des messages (sur la dernière ligne de l'écran) vous aident et vous informent suffisamment d'un bout à l'autre de la procédure. Lisez-les et ne tapez pas sur votre clavier sans prendre la peine d'observer attentivement ce qui se passe sur l'écran. L'envoi de la commande CREATE, suivie par le nom du fichier à créer (ce nom obéit aux conventions MSDOS) déclenche l'affichage d'un questionnaire, qui permettra de définir, champ par champ, la structure de votre fichier de données. Il s'agit de déclarer la liste des différents champs en spécifiant pour chacun d'entre eux son nom, son type et éventuellement sa longueur. Le nom d'un champ (distinct de son contenu) peut comprendre jusqu'à 10 lettres ou chiffres et le seul signe permis, qui est le souligné (" _ "). Il est indifférent que le nom d'un champ soit tapé avec des majuscules ou des minuscules, mais il doit commencer par une lettre. Le type du champ est désigné par une lettre : C (pour caractère), N (pour numérique), D (pour date), L (pour Logique), M (pour mémo). Le logiciel considére par défaut qu'un champ est de type caractère. Il faudra aussi donner la dimension ou la longueur des champs de type caractère ou de type numérique; et pour ces derniers préciser le cas échéant le nombre de chiffres décimaux. Quand les spécifications du dernier champ ont été tapées, on valide l'ensemble de la structure, qui est enregistrée sur le disque dur ou sur une disquette. Cette validation s'effectue en appuyant sur la touche " ENTREE " lorsque le curseur est positionné sur le prochain champ encore vierge ou non rempli. On peut aussi, à n'importe quel moment, même si le travail de définition des champs n'est pas achevé, conserver une structure d'enregistrement en appuyant sur " CTRL FIN ". Il sera possible de reprendre le travail en recourant à la commande MODIFY STRUCTURE... Comme son nom l'indique, cette commande permet de reprendre et de modifier une structure de données (à voir au prochain épisode).

Voici la structure d'enregistrement du fichier NEGRIERS :

Les 22 champs que nous avons définis s'appliquent aux informations suivantes :

1.  Le numéro d'ordre que le répertoire attribue à l'expédition par
      rapport à l'ensemble des campagnes négrières d'un port français
     (de 1 à X....).
2.   Le nom du navire.
3.   Le tonnage du navire. Si deux tonnages sont proposés
      (cas de sources contradictoires), on choisira la première
       valeur plutôt que celle se trouvant entre parenthèses.     
 4.  Nombre d'hommes d'équipage.
 5.  Nombre de décès parmi l'équipage.
 6.  Le nombre d'hommes d'équipage décédés en mer.
 7.  Le nombre d'hommes d'équipage décédés durant les escales
       européennes.
 8.  Le nombre d'hommes d'équipage décédés durant les
       escales africaines.
 9.  Le nombre d'hommes d'équipage décédés durant les
       escales antillaises.
10. Nom et prénoms du capitaine. 
11. Le capitaine est-il décédé en cours de campagne?
12. Nom et prénoms du remplaçant éventuel du capitaine.
13. Noms des armateurs.
14. Port d'armement.
15. Date de départ 
16. Nombre total de noirs embarqués pour l'Amérique 
17. Nombre total de décès jusqu'à la vente des captifs.
18. Le navire n'est pas revenu en France? 
19. Si le navire n'est pas revenu, pour cause de naufrage, 
       de vente aux Antilles, de prise par les corsaires, 
       etc., on indique pourquoi. 
20. Le lieu du naufrage, de la vente, de la prise...
21. Date de retour au port de désarmement
22. Mention complète des sources.   
      

Le plus dur est fait. Si votre structure a été bien agencée, la suite des opérations sera aisée. Vous pourrez bien sûr modifier cette structure en cours de route, mais les améliorations ou les rectifications ne seront que ponctuelles. Les erreurs de conception ne s'avèrent pas réparables, à moins de tout recommencer... Une base de données ressemble à une maison dont vous seriez l'architecte... Son plan, c'est la structure de l'information. Le second épisode de ce passionnant feuilleton sera voué à la saisie et à la mise à jour des données....

André ZYSBERG

LOGICIELS

DEMOBASE, Logiciel de démographie historique

La rencontre d'une pratique pédagogique et de l'informatique

Depuis le début des années soixante dix, instituteurs et professeurs persuadés des vertus de la pédagogie active, ont fait effectuer à leurs élèves des recherches sur les registres paroissiaux et les registres d'Etat civil en s'inspirant des travaux des spécialistes. Le contact avec le document, la rigueur de la démarche proposée, la richesse des interprétations ont passionné des générations d'adolescents qui réalisaient manuellement graphiques et reconstitutions de quelques familles.

L'équipement des lycées en ordinateurs compatibles IBM PC et l'apparition sur le marché de puissants gestionnaires de données ont ouvert de nouvelles perspectives à ce type de travaux au moment où la démographie historique et ses méthodes se voyaient confirmer dans les programmes, en particulier dans les classes de " seconde ".

DEMOBASE naquit ainsi de la rencontre d'une expérience pédagogique déjà ancienne et des possibilités nouvelles qu'offrait la micro-informatique.

En 1986 un scénario fut rédigé et une première version du logiciel réalisée sous DBASE II. Saisie des données par les élèves, traitements statistiques, possibilités de reconstituer les familles furent testés et l'intérêt de l'informatique rapidement validé à tous les niveaux. Le travail sur clavier et écran ajoutait à l'intérêt des élèves et permettait une exploitation quasi exhaustive des données dans un temps compatible avec les programmes. Les reconstitutions de familles étaient possibles malgré les problèmes liés à l'orthographe mouvante des noms de famille.

Le scénario obtint un prix spécial au concours organisé en 1988 par le Ministère de l'Education nationale. A l'initiative du Centre Académique de Ressources et de Formation Informatique de l'Académie de Versailles, la réalisation définitive du produit fut confiée à la société Jeriko qui commercialise le logiciel sous " licence mixte ".

La structure et les performances du logiciel

DEMOBASE offre dans son menu principal trois grandes options:

1 - Gestion des données

La phase de gestion comprend:

2 - Exploitation des données

Ici sont regroupées les options:

a - Reconstitution de familles.

Ce programme opère des recoupements entre actes de mariages, de naissances et de décès, et propose, à partir d'un couple de retrouver les informations concernant le décès des parents, la naissance et le décès des enfants d'une même famille.

Le logiciel propose donc, à partir du nom et du prénom d'un homme et du nom et prénom de sa femme :

La confrontation des trois listes, et la possibilité de rechercher des mots dont la composition est voisine de celui qui nous importe permet de résoudre pratiquement tous les problèmes d'orthographe.

Le logiciel conserve ou ignore à la demande, les actes ainsi repérés; il analyse ensuite le fichier " décès " pour y déceler la trace des personnes de la famille.

Une page écran réunissant toutes les informations sur la famille s'affiche, elle peut être tirée sur imprimante.

b - Analyse statistique

Cette option permet d'obtenir à l'écran ou à l'imprimante des tableaux chiffrés ou des graphiques (histogrammes, courbes, diagrammes circulaires) correspondant à différents modes d'interrogation statistique sur chaque type d'actes.

Vingt deux traitements statistiques sont ainsi proposés

A partir du fichier " naissances "

A partir du fichier " mariages "

A partir du fichier " décès "

3 - Utilitaires

DEMOBASE fonctionne sur tous les compatibles IBM/PC-XT-AT. La taille de la mémoire vive requise est de 512 K, le système d'exploitation MS-DOS version 2.10 et versions suivantes.

Les " préférences " permettent d'adapter le logiciel à toutes les cartes graphiques et à toutes les imprimantes.

La " vérification du support de stockage " sera utilisée pour réparer les dommages dûs à une interruption du logiciel ou pour supprimer définitivement tous les actes d'un support de stockage.

Le public visé

Outil pédagogique destiné en priorité aux élèves du second cycle des Lycées, DEMOBASE présente toutes les garanties qu'un étudiant chercheur peut souhaiter quand à la fiabilité des résultats obtenus. L'investissement temps dans la saisie est largement rentabilisé par la vitesse de traitement des données, par la qualité des sorties écran ou imprimante des graphiques, tableaux ou fiches de familles.

Pour éviter au maximum les erreurs de manipulation que pourraient commettre des élèves, il n'est pas possible d'ajouter ou de modifier l'intitulé des champs ou d'en ajouter (les possibilités de travaux dans un cadre scolaire sont limitées et la convivialité du produit a été privilégiée) mais un chercheur, utilisateur individuel, peut détourner certains champs, par exemple la rubrique " nom et prénom du conjoint " dans la fiche décès peut être affectée au " nom et prénom de la mère " pour les enfants de moins de 15 ans, des fiches " naissances " comprenant les noms et prénoms des parrains et marraines peuvent être ajoutées et une étude utilisant le module reconstitution de familles ou, plus simplement l'édition de " listes triées ", en découler.

Le support de stockage créé sur disque fixe permet de saisir 5000 actes de naissances, 5000 actes de décès et 2500 actes de mariages c'est à dire le mouvement de la population d'une paroisse de 2500 habitants pendant 50 ans. Dans le cas d'effectifs plus importants les possibilités de reconstitution de familles à partir d'un couple dont on ne connaît pas l'acte de mariage permettent d'utiliser successivement deux ou trois fichiers, là encore le gain de temps restera considérable.

L'exemple de la population de Juvisy de 1737 à 1776 puis de 1836 à 1866 a pour but de faciliter la prise de contact avec le logiciel. Les résultats obtenus n'ont aucune valeur de démonstration, car l'échantillon est beaucoup trop faible mais les résultats correspondent à ce qu'on sait des moeurs, des activités, des rythmes des habitants du sud de Paris au XVIIIe puis au XIXe siècle. Ils permettent une initiation à la démographie historique dans ses contenus comme dans ses méthodes.

DEMOBASE a l'ambition d'être à la fois un outil pédagogique pour l'enseignement secondaire et un outil d'initiation et de travail pour étudiants.
La démarche proposée, la nature des traitements subis par les informations sont parfaitement claires, l'ordinateur apparaît comme un outil très performant mais l'utilisateur doit analyser à tout moment les opérations effectuées par la machine pour interpréter ses résultats, mener à bien son travail de recherche. Ici l'ordinateur ne détient pas la vérité, la bonne réponse, ne se substitue pas au maître, le rapport des adolescents à une technique de pointe, souvent magique, s'en trouve remis en cause.

Claude DUMOND

SOMMAIRE
Numéro 2, décembre 1989

SAVOIR-FAIRE

• Jean-Marc WOLFF
  Informatique et Histoire dans l'enseignement secondaire : bilan et perspectives (2e partie).

• Michèle CHAMPAGNE
  Introduction à la conduite de projets informatiques par la méthode MERISE

FORMATION

• André ZYSBERG
  Le feuilleton de Mémoire Vive : Tout ce que vous avez toujours voulu savoir sur l'exploitation informatique des corpus par les historiens sans avoir osé le demander... (Prologue)

LOGICIELS

• Claude DUMONT
  DEMOBASE, logiciel de démographie historique