LA BASE DE DONNEES CAROLUS.

DONNEES ECONOMIQUES ET DEMOGRAPHIQUES

SUR L'EDUCATION EN FRANCE AUX XIXe et XXe SIECLES.

par Nicolas DAURES (LAMETA)

I- Tableaux statistiques et bases de données

Toute analyse cliométrique ou économétrique s'appuie sur des données stockées dans des fichiers informatisés. Il peut s'agir de fichiers traditionnels, le plus souvent des feuilles de tableur, ou d'un support plus élaboré tel qu'une base de données. Pour l'utilisateur, la première méthode est en apparence plus simple, la seconde est plus lourde en investissement mais elle offre en contrepartie d'importants avantages. Il faut en outre, dans tous les cas, disposer d'outils adaptés pour sélectionner et préparer les données à étudier, ou les mettre à disposition de plusieurs utilisateurs.

I-1 Une pratique usuelle : les feuilles de calcul

•  L'usage du tableur est une pratique fréquemment observée. La plupart des chercheurs y ont spontanément recours, car il offre de grandes facilités pour la saisie de données, leur correction, l'impression, les calculs et transformations de variables. Des données existantes, d'origine institutionnelle ou téléchargées par internet, sont souvent présentées sous cette forme. Les données peuvent être facilement transférés de ou vers des applications de calcul (tables SAS par exemple). Enfin, l'interface (écran) permet de reproduire l'aspect visuel habituel des tableaux statistiques à une ou deux dimensions, et d'y adjoindre aisément les titres et annotations utiles.

•  Mais cette approche n'est pas sans inconvénients.

a. Les données sont organisées en tableaux de « structure plate », à une ou deux dimensions, à l'image des tableaux statistiques sur papier. Les données plus complexes (multidimensionnelles ou hiérarchisées) doivent être éclatées en tableaux distincts plus simples. Si elle est visuellement habituelle et confortable, cette dissociation en séries élémentaires entraîne d'une part des redondances de certaines données et d'autre part une multiplication des fichiers (à la limite, autant de fichiers ou de feuilles de tableur que de séries). Elle rend aussi plus difficile la recherche sélective, le regroupement ou l'agrégation de données hiérarchisées.

b. La multiplication de séries distinctes faisant référence aux mêmes nomenclatures oblige à répliquer ces nomenclatures. Par exemple, pour stocker 150 variables annuelles concernant l'éducation depuis 1830 ventilées par départements (France) ou par Pays – soit environ 100 zones géographiques sur 170 ans - il faut prévoir au minimum 150 tableaux croisés de taille 170 x 100 (en l'occurrence, images des documents-papier recueillis). La liste des départements, comme celle des années, est alors nécessairement reportée (copiée) dans chacun des 150 tableaux.

c. Cette duplication de données est naturellement source d'erreurs. Par exemple, le nombre des départements français n'est pas constant dans le temps, ni certaines dénominations. Des « erreurs humaines » s'y ajoutent, notamment si la saisie est effectuée par des personnes différentes (Haute-Garonne, Hte-Garonne, Haute Garonne, etc.). La sélection automatisée de données sera alors impossible.

d. On pourrait aussi évoquer les difficultés de création et de mise à jour du catalogue, l'absence de contrôle de l'intégrité et de la cohérence logique, une sécurité très insuffisante, les difficultés dans la fouille des données - sélection, regroupements, réorganisation des données.

•  La construction de bases de données offre des solutions plus satisfaisantes. On réservera les supports traditionnels à certains contextes :

- travail individuel, hors réseau, pour des données non partagées, à usage ponctuel.
- séries en volumes limités, de structure peu complexe, peu évolutifs
- tableaux de structures analogues, facilement consolidables
- saisie initiale de données (‘fichiers primaires') en vue d'une intégration ultérieure vers une base de données
- récupération de données depuis une base de données, et préparation intermédiaire en vue d'une exploitation statistique avec des logiciels spécialisés.

En règle générale, les fichiers simples ou les feuilles de calcul devraient être considérés comme des compléments, en aval ou en amont, d'une véritable base de données gérée à l'aide d'un logiciel adéquat.

I-2 Une pratique recommandée : les bases de données

La constitution d'une véritable ‘Base de Données, gérée à l'aide d'un logiciel de type SGBD (Système de Gestion de Bases de Données), permet en principe de combler les lacunes du système traditionnel .

Elle ne supprime pas l'usage du tableur, mais lui assigne un rôle complémentaire et subordonné.

•  Cette approche offre de nombreux avantages :

- possibilité de gérer de gros volumes de données (plusieurs milliards de lignes)
- sécurisation du contenu (intégrité référentielle, contrôles de cohérence, sauvegardes)
- partage en réseau, avec sécurisation des accès à divers niveaux
- échanges aisés avec un tableur ou d'autres systèmes de gestion de bases de données
- publication en ligne facilitée au format html
- recours à des compétences humaines (administrateur) et des ressources matérielles (serveur, réseau) en principe plus performantes
- confort pour l'utilisateur (automatisations, paramétrages)
- procédures élaborées de recherche-sélection, mises à jour de données (requêtes)
- structure « physique » générale assez simple (fichiers peu nombreux)
- possibilité de modéliser et d'exploiter des relations logiques complexes entre données
- maintenance et réorganisation plus aisées.

•  Principes d'organisation

L'architecture d'un système de gestion de données comporte trois éléments logiques fondamentaux :

- les données , organisées selon un modèle cohérent
- les vues ou requêtes , pour chercher et sélectionner des données, les regrouper, voire les mettre à jour et effectuer des calculs simples
- l' interface utilisateur (écrans, états à imprimer, procédures d'automatisation)

A quoi il faut ajouter :

- des outils de gestion et de maintenance de la base
- des outils de contrôle et de gestion des autorisations d'accès aux divers contenus
- des modalités d'échange avec l'extérieur (tableurs, SAS, SGBD, html..)

- en amont : outils de préparation et d'intégration des données collectées
- en aval : procédures d'exportation de données vers un tableur par exemple, ou de publication sur un site web.

La gestion de l'ensemble, sous la responsabilité d'un administrateur de base de données, s'appuie sur un ou plusieurs SGBD capable d'utiliser des procédures en langage SQL, reconnu comme standard de communication entre SGBD. Oracle, SQL-Server ou MySQL sont des logiciels de références en ce domaine. Access (MSOffice) est moins performant, mais plus répandu et d'usage confortable pour des utilisateurs peu formés à la gestion des bases, pour un usage personnel ou en petite équipe. Pour un accès aux données par Internet, on peut mettre en place des outils complémentaires (serveur web et pages d'accès aux données ou service ftp) accessibles à l'utilisateur distant via un navigateur courant. Le système ainsi constitué peut être unique ou éclaté, entre une ou plusieurs plates-formes, avec des interfaces adaptables aux besoins finals.

II. Modélisation de la base statistique

La conception d'un modèle d'organisation des données est une question centrale. Il fonde les qualités de la base qui en découle, telles que la robustesse, la cohérence, l'évolutivité ou la facilité d'exploitation. Le modèle, sous différentes formes qui s'enchaînent (conceptuelle, logique, physique) repose sur une analyse préalable menée selon un processus et des principes aujourd'hui bien établis.

• On peut concevoir le modèle en fonction de deux contextes :

Dans une première approche, on se limite au domaine statistique concerné – ici des séries annuelles sur l'éducation en France par départements. La base de données sera assez simple dans la mesure où toutes les séries ont une structure analogue. On envisagera ensuite l'intégration d'un tel modèle limité à un domaine dans une structure plus vaste apte à stocker des séries de structures plus hétérogène. On regroupera alors dans une même base plusieurs domaines statistiques, même s'ils n'ont a priori pas de rapport direct entre eux, dès lors que leur structure logique est identique, ou partiellement identique. Ainsi, la base CAROLUS regroupe des séries longues dans les domaines de l'économie de l'éducation, de la démographie, de l'emploi, de la protection sociale, des indices de prix, des brevets, ou des données sur les transports, qui ne sont pas a priori reliées entre elles (mais qui pourraient l'être). On pourra éventuellement prévoir plusieurs interfaces distinctes pour tenir compte des différences de contenu, ou d'intérêt pour les utilisateurs, mais l'organisation des données restera simple et unifiée. On retrouve ici une distinction entre base de données et entrepôt de données, ce dernier permettant de regrouper des données d'origine diverses et de nature hétérogène tout en assurant à l'utilisateur des possibilités d'exploration performantes.

Dans une base (ou un entrepôt), les données sont stockées dans des tables. On évitera de confondre cette notion avec celles de tableaux statistiques, ou de fichiers élémentaires (feuilles Excel par exemple). Une même table peut stocker des données issues de plusieurs tableaux (ou séries) relevant de domaines différents, à condition qu'elles aient une structure en partie commune. L'un des objectifs est de limiter le nombre de ces tables pour simplifier l'organisation de l'ensemble. Ainsi, on placera dans une même table toutes les données (ou ensembles de données) ayant la même structure logique (liste de champs typés) : une table est définie par son organisation et non par son contenu statistique. L'analyse conceptuelle et logique des données doit donc conduire à définir des tables et des relations entre elles autour d'un petit nombre de structures. On peut regrouper par exemple, dans une même table, toutes les données annuelles par département (ou par pays) quel que soit le domaine concerné.

• Avec un tableur, l'organisation des tableaux est calquée sur la présentation des séries primaires sur papier. Le décalage est généralement plus prononcé dans le cas d'une base de données relationnelle : la dimension visuelle devient secondaire, traitée dans un second temps, au niveau de l'interface. Priorité est donnée à la cohérence et à la robustesse de la structure de stockage des informations. La structure de la base doit permettre aux utilisateurs d'accéder aux données par des méthodes ‘presse-bouton', sans avoir besoin de connaître leur organisation et a fortiori sans avoir besoin d'intervenir sur cette structure : l'utilisateur n'est pas informaticien. En particulier, il faudra que la base se prête de manière transparente à des procédures (requêtes) de sélection des données selon diverses combinaisons de critères selon les besoins de l'utilisateur. Enfin, pour limiter la lourdeur des tâches d'administration, et viser l'efficacité, on cherchera à minimiser le nombre d'entités logiques (tables, fichiers..) et à normaliser leurs structures.

II-1 Entités fondamentales : données et séries

Les deux principaux objets statistiques pertinents pour l'utilisateur sont les séries et les données élémentaires qui les composent. Dans une base de données, il convient de distinguer ces deux entités, en identifiant d'une part les attributs propres aux séries, d'autre part les attributs caractéristiques des données. La liste et la nature des ces attributs doivent être définis au préalable, pour l'ensemble de la base, au terme d'une analyse qui peut admettre quelques variantes dans les choix possibles.

L'entité SERIE :

Elle correspond à une variable statistique observée dans le temps.
Les séries forment en quelque sorte une nomenclature des variables statistiques de la base.
Elle possède des propriétés spécifiques, indépendantes des valeurs de cette variable :

Code de la Série (identifiant unique)
Nom de la série
Unité de mesure , unique pour toutes les données de la série

On inclura également deux attributs intéressants pour les utilisateurs :

Code du Thème , renvoyant au thème de rattachement de la série ce qui permettra de travailler sur plusieurs séries simultanément (cf. infra).
Descriptif contenant informations diverses et commentaires éventuels
Source(s) des données primaires ( par exemple Annuaire Statistique…)
Auteur(s) ayant effectué le travail de saisie, correction, estimation, validation.. pour transférer les données primaires vers des fichiers informatiques intermédiaires avant intégration dans la base.

En toute rigueur, une série peut avoir plusieurs sources (pour des périodes, donc des données différentes par exemple) ou plusieurs auteurs. Il faudrait donc considérer auteurs et sources comme des entités particulières, associées aux données plutôt qu'aux séries. Toutefois, l'indication des auteurs et des sources n'ont qu'un caractère informatif, peu structuré, qui n'exige pas le respect de normes strictes. En particulier, on suppose qu'ils ne serviront pas de critères pour sélectionner des données ou des séries dans la base. Pour simplifier, on stockera l'auteur (ou le groupe restreint d'auteurs) et l'énumération des sources directement dans l'entité Série, sous une forme textuelle libre. Tous les attributs de la Série sont de nature textuelle.

L'entité DONNEE :

C'est l'entité statistique minimale, considérée comme indivisible.
Outre son attribut essentiel (la valeur observée ou estimée), chaque donnée est identifiable par un code propre, dotée d'un statut, et doit être repérable dans le domaine couvert.

On distingue ainsi :

Code de la donnée (identifiant unique)
Valeur
Statut
{Coordonnées}

Valeur : il s'agit de la donnée statistique proprement dite, ici un nombre réel jusqu'à 15 chiffres, suffisant pour des données statistiques. L'unité de mesure est définie au niveau de la série.

Code ID : numéro identifiant unique attribué automatiquement à chaque donnée. Utile pour la gestion interne de la base, il n'apparaît pas à l'utilisateur.

Statut : origine de la donnée (0 = manquante, 1 = source externe, 2 = corrigée ou estimée par l'auteur, 4 = calculée d'après d'autres données de la base).
Cet indicateur permet notamment de ne pas créer de confusion entre données manquantes et donnés nulles, ou entre données observées et calculées. Il nous paraît d'autant plus pertinent que la base de données regroupe des informations d'origines diverses.

{Coordonnées} :
Elles situent chaque donnée particulière dans l'espace des observations : le temps, l'espace des variables, l'espace géographique.
Date  : un nombre entier pour l'année puisque toutes nos données sont annuelles.
Pour d'autres échelles de temps, il faudra prévoir soit des tables de données distinctes (pour des séries trimestrielles, mensuelles etc.) soit plusieurs attributs de date (année, mois, jour, certains pouvant rester vides) qui seront combinés à la demande.
Code Série : renvoie à la série statistique d'appartenance de cette donnée, donc à la variable économique correspondante. Elle matérialise l'association donnée-série.
Code géographique  : indique le département ou le pays de référence et renvoie à la nomenclature des zones géographiques. Les départements et les pays sont traités ici de la même manière, selon une nomenclature unique pour toutes les zones. Ce principe permet d'intégrer sans difficulté des maillages géographiques différent (Régions, Länder, ..), sans qu'il soit besoin de modifier la structure de la base pour la hiérarchiser.

Cette approche permet de traiter un découpage administratif instable, incluant des départements aujourd'hui disparus (Meurthe, Moselle, réunis en Meurthe & Moselle par exemple). Par son caractère général, cette nomenclature est également utilisable, telle quelle, pour d'autres domaines statistiques (brevets, transports,..) et pour d'autres bases de données [1].

La table des données est donc ainsi composée :

II-2 la structure centrale

Les entités Serie et Donnée étant ainsi définies, la base est structurée autour du modèle suivant (voir détails en annexe) :

On aurait pu associer la dimension géographique, non pas directement aux données, mais aux séries (séries départementales), selon un second modèle :

Cette spatialisation des séries et non plus des données entraîne deux inconvénients :

- La multiplication du nombre de séries, puisqu'il faudra autant définir autant de séries chronologiques distinctes que de départements différents, donc environ 100 fois plus, ce qui alourdit le travail de l'utilisateur, tant pour sélectionner que pour agréger les données.

- La reprise, pour chaque série départementale, de tous les attributs et propriétés spécifiques aux séries, avec les inconvénients liés à de telles redondances.

On peut quantifier facilement la différence entre les deux modèles :

Concernant l'espace de stockage, pour T années, D départements et V variables correspondant à S séries (non spatialisées), le premier modèle que nous avons adopté exige trois tables de taille respective:

T x V x D données spatio-temporelles, S = V pour la liste des séries, et D pour celle des départements, soit au total N = D x S x T + V + T lignes.

Concernant le travail de l'utilisateur, la différence est également sensible, toujours au détriment du second modèle. L'accès aux données s'effectuant par la sélection préalable des séries (variables d'intérêt), l'utilisateur qui désire obtenir l'ensemble des données par départements, pour une variable, devra procéder, avec le second modèle, à D sélections successives parmi V x D séries, suivies d'autant d'exportations vers des feuilles de calcul, puis de la consolidation de la centaine de tableaux obtenus.

Avec le modèle que nous avons adopté, il suffit de sélectionner une seule série parmi V, pour récupérer dans une feuille unique l'ensemble des données désirées, sous la forme d'un tableau à deux dimensions (D x T) directement exploitable : les tâches sont sont cent fois moins nombreuses.

II-3 Le modèle en étoile et ses extensions

Le modèle central obéit à un schéma en étoile :

Ce type de modèle offre une bonne souplesse pour exploiter les données, selon différentes vues fondées sur des combinaisons de critères faciles à définir. Il est toutefois possible de lui apporter des extensions, sans perdre ce caractère étoilé.

L'objectif est double :

D'une part, en prolongeant les branches, on peut définir des entités plus larges, à l'image des nomenclatures hiérarchisées. On permettra ainsi à l'utilisateur d'opérer des regroupements de données, unions ou agrégats de séries ou de zones.

D'autre part, en créant de nouvelles branches , on peut adjoindre d'autres dimensions, pour des données économiques d'une autre nature. On pourra ainsi intégrer, dans une même base (ou un même entrepôt), des séries de données comportant d'autres dimensions (secteurs, institutions..).

•  Regroupements de données

L'analyse cliométrique exige généralement l'exploitation conjointe de plusieurs séries de données. Les regroupements de données peuvent certes toujours s'effectuer a posteriori, après exportation des séries dans différents fichiers (feuilles de calcul , tables SAS..).
CAROLUS permet cependant d'opérer des regroupements avant exportation, en utilisant les outils de requêtes SQL. Le travail de l'utilisateur est alors simplifié.
La notion de regroupement possède plusieurs significations, qui sont traitées différemment.

•  Dans une base de données, une requête peut extraire, afin de les regrouper en une vue unique, des données issues de plusieurs tables liées, pour des champs sélectionnés dans chacune d'entre elles. Il s'agit de l'opération de projection. Dans le cas de CAROLUS, toutes les données observées sont stockées dans une même table DATA, et cette opération de projection n'est donc pas pertinente.

•  Par regroupement, on peut aussi entendre « consolidation », agrégation, et plus généralement toute construction d'une nouvelle série de valeurs issue de calculs appliqués aux données initiales. Par exemple : population (Hommes) + population (Femmes) à population (Ensemble) ; ou encore : effectif enseignant / Effectif scolarisé à taux moyen d'encadrement, etc. Ces calculs sont légitimes mais risqués. Cette opération n'a de sens que s'il s'agit des mêmes années, mêmes secteurs , mêmes zones géographiques, et surtout s'il n'y a pas de données manquantes. Par prudence, ce type de regroupement n'est pas pris en charge par CAROLUS, l'utilisateur pouvant effectuer cette tâche cas par cas après exportation des séries concernées.

•  On peut enfin regrouper des données en juxtaposant des séries.
Il s'agit plus précisément d'une opération d'union entre des ensembles de données qu'il est pertinent de visualiser ou traiter simultanément.

•  Regroupements de séries en thèmes

Sur l'axe des séries économiques , on rapprochera par exemple (sans calcul) des populations (hommes, femmes), ou des séries d'une même variable à des périodes différentes, ou encore des séries analogues mais de sources différentes. Dans le cas particulier de CAROLUS ou les données sont dans la même table, l'opération d'union s'effectue simplement par une sélection de séries, fondée sur la valeur d'un champ (‘sel') logique :

DATA X SERIE / SERIE.sel = true.

L'utilisateur n'a donc pas besoin d'intervenir dans la structure de la requête, il lui suffit de cocher les séries désirées, dans un formulaire construit à cette fin. La vue résultante fournira les données ‘empilées' des séries sélectionnées, qui peuvent être présentées dans un tableau à deux dimensions pour une meilleure lisibilité.
Certains regroupements de ce type paraissent naturels, et peuvent sont définis de manière permanente. Les regroupements de séries peuvent être prédéfinis, car ils se fondent sur une pertinence intrinsèque.

Un Thème correspond ainsi à un regroupement prédéfini de séries apparentées par leur contenu (par exemple : le thème « Dépenses pour l'enseignement primaire en France » contient plusieurs séries correspondant aux différentes origines ou destinations des dépenses).

Champs :
Code Thème (identifiant unique, cf. supra)
Nom du Thème
Rem (commentaires libres)

Cette entité THEME n'est pas indispensable à l'organisation logique fondamentale de la base. Sa fonction essentielle est de clarifier l'espace de travail des utilisateurs, en simplifiant leurs modalités d'accès à des données statistiques regroupées. Elle prolonge la branche DATA-SERIE, en introduisant en amont un niveau supplémentaire plus général.

•  Regroupements de zones géographiques

Sur l'axe géographique , l'utilisateur doit pouvoir construire à discrétion des zones (régions, groupes de pays..) par regroupement de zones élémentaires. On prévoira alors un niveau supplémentaire permettant de construire des espaces dont le contenu sera librement défini par l'utilisateur selon ses besoins. Selon le même principe que dans le regroupement de séries, il suffira de réunir toutes les données après avoir sélectionné et marqué les zones géographiques élémentaires : DATA X ZONE / Zone.sel = true.

III Intégration dans la base cliométrique CAROLUS

III-1 autres dimensions (nouvelles branches)

On introduit, selon les besoins, une ou plusieurs dimensions institutionnelles (entreprises, agents), comptables (catégories de la comptabilité nationale), sectorielles, technologiques, etc. Il suffira d'ajouter des champs supplémentaires, à usage optionnel, dans la table des données. L'axe du temps peut faire lui-même l'objet de ce traitement, en prévoyant les champs Jour et Mois. On appliquera à chacune de ces branches la règle précédente d'extension permettant des regroupements.

III-2 domaines

On définit également, en amont des Thèmes et donc de leurs séries, des Domaines, qui s'avèreront des compléments utiles pour cataloguer et accéder aux données. Un Domaine regroupe plusieurs thèmes connexes (Education, ou Emploi, etc.). Il se caractérise par un ensemble particulier de tables, localisées dans la même base. Le principal intérêt de ce regroupement est de permettre la définition d'une « porte d'accès » (interface) unique et cohérente pour l'ensemble des données du domaine, ce qui simplifie les opérations de recherche et de sélection par les utilisateurs, et les tâches de gestion par l'administrateur. Ainsi, les données utilisées ici relèvent toutes de la même base (CAROLUS), du même Domaine (Education) et de plusieurs des thèmes de ce domaine (Dépenses de l'enseignement primaire en France, Populations scolaires, Classes en fonctionnement, Personnels..).
La base héberge aussi d'autres domaines que l'éducation, avec leur propre organisation.

L'organisation générale de la base est donc ainsi schématisée :

III-3 Interface. Vues et Requêtes

La base Carolus est gérée sous SQL-Server™, mais seul l'Administrateur intervient à ce niveau.
Afin de simplifier le travail des utilisateurs, des interfaces ont été développées sous Access™, accessibles directement en réseau par tous les chercheurs autorisés. L'utilisation en est du type ‘presse-bouton', et aucune formation préalable n'est donc nécessaire. Il y a au moins une interface par domaine, pour la consultation, l'export vers des feuilles Excel, et des recherches usuelles.

Le point d'entrée est un «  catalogue du domaine », listant les thèmes et les séries disponibles. L'utilisateur sélectionne Thèmes puis Séries, pour en consulter les données détaillées à l'écran et les exporter automatiquement vers Excel en vue d'une exploitation statistique.
Toutes les vues se présentent sous la forme de tableaux croisés (Données par Année x Zones géographiques, incluant le cas particulier des séries nationales à zone unique).
Des versions particulières de l'interface peuvent être élaborées pour des besoins spécifiques. On peut également autoriser certains utilisateurs à exécuter certaines tâches interdites à d'autres, par exemple la construction de requêtes personnalisées. Néanmoins, la procédure standard d'exportation des données vers des fichiers Excel, non verrouillés, permet de satisfaire la plupart des besoins des utilisateurs.

IV Des sources à la base de données

IV-1 Les sources primaires

La majeure partie des données cliométriques sont issues du dépouillement de Recueils, Annuaires, statistiques administratives diverses.
Concernant l'Education en France aux 19e et 20e siècles, nous avons utilisé divers tableaux issus de la « Statistique de l'Enseignement Primaire », tome 2, Ministère de l'Instruction Publique et des Beaux-Arts. Paris. Imprimerie Nationale.1880.

Les données concernent :

- les dépenses pour l'enseignement primaire, selon diverses sources et destinations
- le nombre d'écoles
- les populations d'âge scolaire et scolarisées
- les effectifs enseignants.

Toutes les données sont ventilées par départements, entre 1833 et 1876. Le catalogue complet et détaillé des séries, avec leurs propriétés particulières, est présenté en annexe. Le passage des données primaires, telles qu'elles ont été publiées en 1880, aux données finales informatisées stockées dans la base Carolus s'est effectué en plusieurs phases.

IV-2 Des sources primaires aux fichiers primaires

S'agissant de données anciennes, publiées il y a plus d'un siècle, la première étape consiste à les transférer dans des fichiers informatiques (les fichiers primaires ). Plusieurs méthodes ont été envisagées et testées.

Le processus [Photocopie [2] /Scanner(image)/Reconnaissance de caractères/Corrections et mise en forme] peut être intéressant pour des volumes importants de données textuelles . Ayant expérimenté cette méthode, dans des travaux précédents, pour des tableaux statistiques, nous en avons conclu à son inadéquation au cas des données numériques , surtout pour des données anciennes. Outre les problèmes de typographie, les difficultés de reconnaissance des caractères sont accrues par l'impossibilité de corriger automatiquement des erreurs sur les chiffres en s'appuyant sur leur contexte.

Nous avons également testé la reconnaissance vocale , mais la frappe au clavier s'est révélée plus rapide pour des valeurs numériques.

La saisie manuelle (recopie) est donc obligatoire en l'état actuel des techniques. L'usage du tableur a été retenu pour son confort. Les fichiers primaires ainsi constitués sont à l'image des tableaux d'origine, sous la forme de feuilles Excel™. On a conservé la présentation d'origine des tableaux, pour faciliter les premiers contrôles et corrections. Les utilisateurs individuels s'arrêtent souvent à ce stade, en stockant d'innombrables feuilles de calcul. Comme on l'a vu, cette approche est rarement optimale.

IV-3 Contrôles, corrections d'erreurs, données manquantes

Le tableur offre quelques moyens simples pour aider à la détection d'erreurs et à leur correction.

Une première détection d'erreurs (incohérences) est facilitée par le calcul automatique de sommes en lignes ou en colonnes, à comparer avec les totaux présentés dans la source (France entière, séries regroupées). Une distorsion peut révéler une erreur lors de la saisie informatique ; un contrôle visuel détaillé de la ligne ou de la colonne concernée permet de localiser l'erreur et de la corriger. La distorsion peut aussi provenir d'une totalisation erronée (peu fréquente) dans la source primaire. Dans ce cas, les données élémentaires sont conservées, mais leur somme est rectifiée.

Dans un second temps, les valeurs manquantes (recherche des cellules vides dans la feuille Excel) sont examinées en tenant compte de « l'inexistence administrative » de certains départements (Alpes Maritimes, Savoie, Meurthe, etc.) à plusieurs périodes. On note à ce propos que le tableur ne permet pas un traitement statistique systématique et fiable des valeurs manquantes, qu'il distingue mal des valeurs nulles. C'est pourquoi nous avons introduit dans la base Carolus une variable indicative du statut de chaque valeur (ici, statut = 0, indice d'une donnée manquante).

Un autre groupe d'erreurs (anomalies) est en partie détecté par l'observation de l'évolution de chaque série départementale au cours du temps (calcul des différences premières et recherche des variations jugées a priori aberrantes). Il s'agit alors d'erreurs probables d'écriture à la source. Dans ce cas, il est procédé à une estimation de la donnée (par interpolation ou recoupement avec d'autres informations) pour obtenir une valeur plus vraisemblable. L'observation ainsi rectifiée est marquée par son statut de ‘valeur estimée'.

Enfin, une procédure de contrôle consiste à consolider certains tableaux (regroupement de variables) pour comparer les tableaux ainsi obtenus aux données primaires correspondantes, lorsqu'elles sont disponibles. Par exemple, on vérifiera que la somme des données départementales d'une variable est égale à la donnée primaire ‘France entière' pour cette variable, si elle est disponible dans le document source. De même, les données détaillées du tableau ‘Ressources Ordinaires des Communes' (tableau T5 de la source) doivent être équivalentes aux totaux des tableaux (tableaux T2 + T3 + T4) des Legs & Dons + Subventions Communales + Contributions de familles. Ou bien encore : Ressources ordinaires totales = R.O. des Communes + R.O. Départementales + R.O. de l'Etat. (cf. infra). Il n'est pas indispensable de stocker dans la base les séries agrégées (par exemple France entière), alors que l'on pourra toujours les recalculer à partir des données détaillées.

Ces procédés de vérification n'évitent pas toutes les erreurs de saisie, mais la plupart d'entre elles. Elles permettent en outre de corriger certaines erreurs dans les données d'origine (saisies de valeurs aberrantes, erreurs de sommations). Dans tous les cas, elles assurent la cohérence des données , propriété plus importante encore que leur exactitude.

A la fin de ce processus, chaque donnée est assortie d'un indicateur de son statut  :

0 = donnée manquante,
1 = donnée d'origine,
2 = donnée estimée ou rectifiée
3 = donnée calculée (sommes ou différences d'autres données de la base)

Il sera ainsi possible à l'utilisateur d'avoir une information sur la qualité des données qu'il exploite.

IV-4 Organisation des séries et sélection des tableaux primaires à saisir

Les données primaires (document initial) sont organisées en tableaux croisés, avec les données ventilées par départements et année. Ainsi, pour les dépenses d'enseignement primaire, la source dispose de plus de quinze tableaux croisant années et départements.

Chacun correspond à une double référence budgétaire :

- selon l'origine des ressources financières
(Legs et dons, Contributions des familles, Subventions publiques, qui constituent les ressources ordinaires ; les ressources extraordinaires ; l'ensemble des ressources)

- selon le « niveau institutionnel »
(communes, départements, état, ensemble)

Plusieurs de ces séries peuvent se déduire les unes des autres, si bien qu'il n'est pas nécessaire de les saisir en totalité. Nous avons calculé certaines d'entre eux par agrégation ou par différence, en vérifiant que les résultats obtenus sont égaux aux données primaires correspondantes. Cette opération a permis de réduire la saisie à 7 tableaux sur un maximum théorique de 24 , selon le schéma suivant (les tableaux saisis sont indiqués en gras italique) :

Un principe de sélection analogue a été adopté, lorsque cela était possible, pour les séries des autres domaines (démographie, établissements, personnels), afin de restreindre les tâches de saisie, et les erreurs qu'elles génèrent.

IV-5 Migration des données, des fichiers primaires vers la base Carolus

Une fois les fichiers primaires (feuilles Excel) ainsi construits par saisie ou par calcul, complétés et validés, leur contenu doit être transféré dans les différentes tables de la base de données Carolus. La structure de celle-ci est établie au préalable, avec toutes les relations et contraintes de validité et d'intégrité nécessaires, de manière à bloquer toute importation invalide. Les définitions complètes des Thèmes et Séries ont été renseignées manuellement, directement dans les tables de la base, à commencer par leurs identifiant. Les codes identifiant des séries ont été ensuite reportés dans les fichiers Excel pour l'ensemble des données correspondantes. On a complété également toutes les données des feuilles Excel par les références adéquates aux zones géographiques (ici : codes des départements) et par l'indication du statut (0 à 4) selon le principe indiqué précédemment.

Le processus de transfert des données statistiques s'effectue alors en plusieurs étapes et met en œuvre d'une part des « macros » Excel programmées en VBA (Visual Basic for Applications), d'autre part des requêtes écrites en langage SQL pour SQL-Server. Les procédures VBA assurent une restructuration et une mise en forme des tableaux Excel en les adaptant à la structure de la base de destination. Les requêtes SQL de création et de mise à jour de tables permettent de récupérer les données ainsi formatées, et de les intégrer dans la base.

Ces deux outils constituent les deux volets complémentaires, « push » et « pull », de l'outil de migration [3] .

D'autres requêtes permettent des contrôles supplémentaires sur les données finales ainsi intégrées, et portent notamment sur les sommes, les données manquantes, les intervalles de valeurs. Il ne nous paraît pas utile de décrire ici plus en détail l'ensemble de ce processus.

V Droits et responsabilités des contributeurs

Sans trop compliquer les choses, il convient de distinguer trois catégories de contributeurs, selon leurs fonctions, impliquant droits et intellectuels et moraux différents. Dans chaque catégorie, certains contributeurs peuvent éventuellement être signalés comme principaux ou secondaires. Ils sont tous explicitement référencés dans la base de données, et devraient l'être dans les travaux des utilisateurs de cette base. L'ensemble des auteurs (personnes ou institutions) des deux premières catégories est précisé pour chacune des séries statistiques de la base. Les auteurs de la dernière catégorie ne sont référencés qu'au niveau plus global de la base de données.

A. Contributeurs des Source(s) primaire(s) :

Il s'agit des Auteurs ou Editeurs ou Institution émettrice du document d'origine .

Ex. : INSEE- Ann. Stat de la France …
Ministère de l'Instruction Publique…
Données privées (ou personnelles) de M…….
Données issues de calculs effectués par ….

Ces auteurs peuvent détenir une propriété intellectuelle (juridiquement active) sur le contenu de leur document.
Dans certains cas, leur accord est requis pour que les données soient intégrées dans une base. Mais ils ne sont pas responsables des erreurs que nous aurions pu faire par la suite. Ils doivent être cités comme sources, selon la procédure habituelle de référence.

B. Auteur(s) du Recueil (fichier primaire) :

Il s'agit des personnes (chercheurs...) qui se sont chargées de :

- réunir les sources primaires,
- constituer ou reconstituer les fichiers (généralement des feuilles Excel)
- les vérifier, corriger, compléter

Si des séries sont calculées à ce stade (sommes, tendances, etc..), elles deviennent sources primaires (cf. cas précédent). Ces auteurs ont les droits sur ces séries et fichiers, et contrôlent notamment leur diffusion. Ils sont référencés comme Auteurs des séries statistiques dans leur usage ultérieur, et d'abord dans la base de données.

Ex : la plupart des séries sur les dépenses d'éducation en France 1833.. ont pour auteur Cl.Diebolt (Lameta) qui en a assuré la saisie et un premier contrôle. D'autres auteurs apparaissent parfois, à titre secondaire, pour leurs tâches de contrôle et de restructuration.

C. Auteur(s) de la Base (administrateur) :

Il s'agit de la personne qui :

- a conçu la structure de la base de données, organisé les tables, les requêtes, l'interface pour les utilisateurs,

- a regroupé les fichiers de séries statistiques, conçu et mis en oeuvre les procédures de migration et de contrôle des données, mis en place les procédures de diffusion, etc.

- administre la base.

Cet auteur n'a pas la propriété intellectuelle sur le contenu des séries, mais dispose de la propriété de l'application logicielle, c'est à dire de la structure, des méthodes et des modalités d'accès. La définition des droits d'accès demeure contrôlée par les auteurs des séries recueillies. L'usage de la base de données, par exemple par un chercheur, suppose que soient cités les auteurs des séries et les auteurs de la base. Ce principe ne se limite pas aux données ‘en ligne', mais aussi aux données publiées sous forme imprimée, telles qu'elles figurent notamment dans le présent ouvrage.

Ex : Une étude cliométrique utilisant la base de données CAROLUS citera le Ministère de l'Instruction Publique comme source des données, et par exemple Claude Diebolt (Lameta) comme auteur de séries contenues dans cette base et Nicolas Daures (Lameta) comme auteur de la base.

D. Collaborations diverses :

Les personnes qui sont intervenues ponctuellement mais significativement à un stade ou un autre seront signalées comme telles selon l'usage (coll… ou avec l'aide de.. ).

Annexe : diagramme partiel de la BASE

Notes :

[1] Cette approche efface toute hiérarchie a priori entre les zones géographiques. Dans le cas d'espèce, avec les seuls niveaux départemental et national, cet inconvénient est mineur. La solution consistera à établir une structure hiérarchisée de la nomenclature géographique, permettant à l'utilisateur de moduler la granularité spatiale de ses vues.

[2] Le recours à la photo numérisée s'est avéré encore plus décevant, du fait des déformations accrues de l'image.

[3] Voir par exemple : Bouzeghoub 2002, qui parle plutôt de LVA et GVA à ce propos.