Conception d'un système d'information des applications thématiques réalisées à partir de bases de données cartographiques sur les sols

HAL Id: hal-02811339

https://hal.inrae.fr/hal-02811339

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

cartographiques sur les sols

Florent Millet

To cite this version:

Florent Millet. Conception d’un système d’information des applications thématiques réalisées à partir de bases de données cartographiques sur les sols. [Stage] Université d’Orléans (UO), FRA. 2011, 49 p. + dictionnaire de données de 78 p. �hal-02811339�

UNIVERSITE D’ORLEANS

Observatoire des Sciences de l’Univers en région Centre

Master Sciences de la Terre et de l’Environnement

Spécialité Géomatique appliquée aux Géosciences (Géo²)

2010-2011

Rapport de stage en entreprise

Conception d’un système d’information des

applications thématiques réalisées à partir de bases

de données cartographiques sur les sols

Par Florent MILLET

Encadrement

Nathalie SCHNEBELEN, Olivier SCHEURER

INRA – Centre de Recherche d’Orléans

2163, Avenue de la Pomme de Pin

CS 40001 Ardon

Remerciements

Je tiens à remercier Nathalie Schnebelen et Olivier Scheurer, mes maîtres de stage, pour leur confiance et leur soutien tout au long de ce travail. Je suis très heureux d’avoir pu intégrer une équipe de travail aussi dynamique et conviviale qu’InfoSol.

Je voudrais aussi exprimer ma gratitude à Bertrand Laroche pour m’avoir accueilli dans son bureau pendant ces quelques mois. Ses conseils et réponses à toutes mes questions m’ont beaucoup servi. J’ai apprécié sa grande disponibilité et les suggestions qu’il m’a proposé tout au long du projet. Mes remerciements s’adressent également à Jean-Philippe et Benoît qui ont eu la patience de m’aider et m’éclairer par leurs compétences, pour leurs conseils lors du développement de la base de données et leur aide en langage SQL.

Merci à Florence qui a bien voulu nettoyer ce rapport des fautes d’orthographes et pour son aide lors de la saisie dans la base de données. Ainsi qu’à Olivier, Nathalie et Benoît pour leur lecture avisée et leurs remarques.

Enfin, je tiens aussi à remercier Dominique Arrouays, directeur de l’unité InfoSol, pour l’agréable accueil au sein de son unité ainsi que toutes les personnes qui ont facilité mon intégration au sein de l’unité InfoSol de l’INRA d’Orléans.

- 1 -

Remerciements ... 2

Introduction ... 3

Chapitre I : Cadre du stage et objectif opérationnel ... 4

1- Présentation de la structure d’accueil ... 5

1.1- L’Institut National de la Recherche Agronomique (INRA) ... 5

1.2- L’unité de Service InfoSol ... 6

2- Contexte du projet ... 7

2.1- Des demandes grandissantes de connaissances sur les sols ... 7

2.2- Des programmes d’acquisition et de capitalisation de la connaissance sur les sols ... 7

2.3- Une nécessité de diffusion et de valorisation ... 8

3- Objectif opérationnel ... 9

Chapitre II : Analyses préliminaires pour la conception du système d’information ...10

1- Définition des besoins ... 10

1.1- Intérêt d’une base de données ... 10

1.2- Détermination des usages potentiels de la base de données ... 11

1.3- Enquête : attentes des utilisateurs vis-à-vis du futur système d’information ... 13

2- Analyse de l’existant ... 14

2.1- En région, dans les organismes concernés ... 14

2.2- A l’INRA, Unité InfoSol ... 14

3- Cahier des charges du système d’information ... 16

3.1- Choix techniques ... 16

3.2- Aide à l’utilisation d’ApplicaSol ... 19

Chapitre III : Etapes de conception du système d’information ...20

1- Recherche d’une structure en adéquation avec les usages ... 20

2- Conception de la base de données ApplicaSol selon la méthode Merise ... 21

2.1- Le Modèle Conceptuel de Données (MCD) de la base de données ApplicaSol ... 21

2.2- Passage du Modèle Conceptuel de Donnée au Modèle Logique de Données (MLD) ... 22

2.3- Implémentation du Modèle Logique de Données dans le SGBD Access ... 22

3- Conception des interfaces de saisie et d’administration ... 23

3.1- Interface de saisie des données ... 23

3.2- Interface d’administration de la base de données ... 24

Chapitre IV : Saisie et évaluation de la base de données ...25

1- Saisie dans la base de données : choix et état de la saisie actuelle ... 26

2- Exploitation du contenu de la base de données ApplicaSol ... 26

2.1- Recherche de méthodes de traitement des données ... 27

2.2- Partage et transfert de résultats d’application ... 28

2.3- Connaissance de l’évolution d’utilisation des bases de données sols ... 29

Conclusion et perspectives ...32

Liste des figures ...33

Annexes ...35 Annexe n°1 : Liste des thématiques possibles pour une application (contexte d’utilisation d’une application) ... 35 Annexe n°2 : Questionnaire diffusé dans le cadre de l’enquête sur les attentes des utilisateurs vis-à-vis de la future base de données ... 35 Annexe n°3 : Dépouillement des réponses de l’enquête sur les attentes des utilisateurs vis-à vis du futur système d’information ... 39 Annexe n°4 : Extraits du code VBA du formulaire de saisie d’une application dans la base de

données : sélection et enregistrement de la localisation ... 43 Annexe n°5 : Exemples d’exploitation du contenu de la base de données : requêtes SQL...44 Annexe n° 6 : Exemple de fiche récapitulative d’une méthode de mise en œuvre d’une application ... 48

- 3 -

Introduction

Depuis plusieurs années l’importance du rôle des sols dans l’environnement et la nécessité de leur protection sont de plus en plus reconnues. La grande variabilité spatiale des sols nécessite une connaissance spatialisée (Boiffin et Stengel, 2000), ce qui entraîne la constitution de nombreuses bases de données spatialisées sur les sols et témoigne d’un effort certain pour l’acquisition de ces données (King et al., 1999 ; Arrouays et al., 2004).

La majorité des régions françaises dispose actuellement de bases de données cartographiques sur les sols (Référentiels Régionaux Pédologique notamment), gérées sous SIG et SGBD. Les données géographiques sur les sols combinées à d’autres informations (climat, relief, occupation du sol, pratiques agricoles, hydrologie, hydrogéologie, etc.) offrent une gamme d’applications thématiques 1 très étendue (Le Bas et al., 2004 ; Le Bas et Schnebelen, 2006) : gestion et protection des sols, gestion du territoire, aménagement, zonages, préservation de la biodiversité, etc.

De nombreux maîtres d’ouvrages régionaux ont ainsi réalisé de telles applications, en réponse à des enjeux et des demandes exprimées localement. La complexité des méthodes de traitement mises en œuvre est variable, allant, entre autres, de la simple extraction et traitement de données sols en passant par l’élaboration de règles de pédotransfert, et jusqu’à la mise en place de modèles plus ou moins complexes intégrant des variables non-sol. De ce fait, l’investissement méthodologique est souvent lourd pour l’organisme chargé d’étude.

Dans ce contexte, le Réseau Mixte Technologique2 (RMT) « Sols et Territoires » s’est donné pour objectif de mettre en commun les expériences d’applications thématiques élaborées sur différents territoires français et de les rendre accessibles à tous les utilisateurs de bases de données sols. Ce RMT a en effet vocation, non seulement à développer des bases de données relatives aux sols, mais surtout à favoriser leur utilisation par les acteurs des territoires, afin de répondre à aux enjeux agricoles, ruraux, environnementaux, économiques et sociaux

Ce présent projet a plusieurs objectifs. Dans un premier temps il s’agit, d’une part, d’effectuer l’inventaire des applications réalisées à partir des bases de données cartographiques sur les sols dans les régions en disposant. Cet inventaire sera notamment réalisé en exploitant les informations disponibles à la suite de plusieurs enquêtes successives réalisées par l’Unité InfoSol de l’INRA d’Orléans en 2004, 2006 et 2008. D’autre part, en réalisant une enquête auprès des utilisateurs potentiels d’une future base de données sur ces applications, afin d’en définir clairement les spécifications.

Dans un second temps, il s’agit de concevoir une base de données facilitant la mise en commun des méthodes mises en œuvre et des résultats obtenus dans ces applications. Cette base de données devra répondre aux spécifications définies suite à l’enquête, tant en terme technique (structure de la base, choix du système de gestion de base de données, modalités de saisie et d’interrogation, administration des données) que scientifique (logique scientifique dans la structure et les relations de la base, validité scientifique du contenu de la base de données).

Enfin, les objectifs finaux de ce travail sont, d’une part, de diffuser cette base de données via le site internet du RMT « Sols et Territoires » afin que les utilisateurs puissent l’interroger de manière efficace et, d’autre part, d’organiser sa mise à jour permanente par les futurs administrateurs de la base.

1 On entend par application thématique une étude utilisant une base de données cartographique sur les sols appliquée au traitement d’une problématique sur un thème donné.

2 Les Réseaux Mixtes Technologiques (RMT) mis en place par le Ministère en charge de l’Agriculture en 2007 visent à créer et renforcer les liens entre organismes de recherche, de développement et de formation autour d’une thématique commune.

Le présent mémoire s’organise en quatre parties. La première est consacrée au cadre dans lequel j’ai effectué mon stage de fin d’étude ainsi qu’à ses objectifs opérationnels. Les analyses préliminaires nécessaires à la conception du système d’information seront exposées dans la seconde partie. Dans une troisième partie seront décrites les étapes de conception du système d’information, de la modélisation de la base de données jusqu’à la conception des interfaces utilisateur et administrateur. Puis dans une dernière partie, les choix opérés lors de la saisie des données seront détaillés et quelques résultats d’exploitation de cette base de données seront présentés afin de tester sa pertinence face à la problématique générale. Enfin, en conclusion, un bilan sur les objectifs et sur les perspectives d’évolution du système d’information sera réalisé.

Chapitre I : Cadre du stage et objectif

opérationnel

1- Présentation de la structure d’accueil

Mon stage de fin d’étude s’est déroulé au sein du Centre de recherche de l’INRA d’Orléans et plus particulièrement dans l’Unité de Service InfoSol, sur une durée de six mois, du 1er avril au 30 septembre 2011.

1.1- L’Institut National de la Recherche Agronomique (INRA)

Fondé en 1946, l’Institut National de la Recherche Agronomique (INRA) est un organisme de recherche scientifique publique finalisée. Il est placé sous la double tutelle du Ministère de l’Enseignement supérieur et de la Recherche et du Ministère de l’Agriculture, de l’Alimentation, de la Pêche, de la Ruralité et de l’Aménagement du Territoire (MAAPRAT). Premier institut de recherche agronomique en Europe, deuxième dans le monde, l’INRA mène des recherches au service d’enjeux de société majeurs : l’alimentation, l’agriculture, l’environnement et la gestion du territoire, avec une perspective de développement durable.

En France, l’INRA possède une délégation régionale dans chaque région et 19 centres régionaux. Il est composé de 381 unités de recherche, d’expérimentation, d’appui à la recherche ou de service. Le Centre de recherche de l’INRA d’Orléans travaille sur quatre domaines de recherche :

- conservation et valorisation des ressources génétiques des arbres forestiers pour la production de bois d’œuvre et de biomasse,

- compréhension des mécanismes régissant les populations d’insectes en expansion sous l’effet des activités humaines et des changements environnementaux,

- observation, modélisation et protection des ressources en sols,

- amélioration génétique de l’adaptation des ruminants domestiques et de la qualité de leurs produits.

Ce Centre est constitué de cinq unités sur le site d’Ardon ainsi que du domaine expérimental de Bourges (Figure 1).

Figure 1 : Les unités du centre de Recherche d'Orléans et leurs départements de rattachement

(Source : http://www.orleans.inra.fr/le_centre_de_recherche)

Ces thématiques de recherche, au travers des unités présentes notamment sur le site d’Ardon, donnent au Centre de l’Inra d’Orléans une orientation marquée en matière d’environnement et de développement durable. Le centre a par ailleurs développé une politique d’accueil et de partenariat avec d’autres organismes (ONF, ArboCentre, SOeS, AFES) favorisant les liens entre la recherche, le développement, la communication et l’aide à la décision publique.

- 6 -

1.2- L’unité de Service InfoSol

La grande variabilité des sols et de leurs propriétés rend nécessaire une connaissance systématique des caractéristiques du sol pour évaluer ses aptitudes aux différents usages, ses contributions à la qualité de l'environnement et aussi proposer les modalités de gestion les plus appropriées. Cependant, le sol est rarement pris en compte dans les décisions environnementales et territoriales, en raison de l'insuffisance des sources de données disponibles pour caractériser la nature des sols et quantifier l'évolution de leur qualité.

Face à ce constat, la mission générale de l'Unité de Service InfoSol d'Orléans est de constituer et de gérer un système d'information à vocation nationale sur les sols, par rapport à leur distribution spatiale, leurs propriétés et l'évolution de leurs qualités.

Cette Unité relève du Département de recherche Environnement et Agronomie de l'INRA. L'activité de l'Unité s'exerce dans le cadre de la participation de l'INRA à un Groupement d'Intérêt Scientifique sur le Sol (GIS Sol) qui propose un ensemble de programmes nationaux pour faciliter et encourager une gestion patrimoniale et durable des sols.

L'unité InfoSol travaille également en relation avec le Réseau du Bureau Européen des Sols de la Commission Européenne et l'Agence Européenne de l'Environnement, qui mènent des programmes européens de même nature.

Les activités de l’Unité InfoSol sont organisées en trois thématiques : - inventaire des sols,

- suivi temporel des sols (surveillance), - bases de données spécialisées.

Chacune de ces thématiques est subdivisée en plusieurs programmes définis par le GIS Sol (Figure 2).

2- Contexte du projet

2.1- Des demandes grandissantes de connaissances sur les sols

Les demandes de connaissance sur les sols provenant des territoires sont de plus en plus importantes. Par exemple, entre avril 2008 et novembre 2009, 440 demandes de connaissances sur les sols ont été enregistrées au niveau national, sans compter les demandes effectuées au niveau régional ou départemental (Richer de Forges et Arrouays, 2010).

Ces demandes concernent de nombreux enjeux agricoles, ruraux, économiques, environnementaux et sociaux. On peut ainsi citer : le développement de nouvelles filières de production, la valorisation des matières organiques, la protection des ressources en eau, la protection contre l’aléa érosif, la réalisation de zonages réglementaires ou la définition d’outils destinées à leur mise en œuvre (zones humides, zones défavorisées simples, trame verte et bleu, etc.), la préservation de la biodiversité, la lutte contre le changement climatique, la consommation de l’espace agricole par l’urbanisation. Les demandes proviennent de territoires de tailles très différentes : du bassin versant de quelques dizaines ou centaines d’hectares à la grande région administrative voire au-delà. La diversité des demandeurs est elle aussi très importante : services de l’Etat, collectivités, organisations professionnelles agricoles, bureaux d’études, etc.

Le traitement de ces nombreuses questions nécessite de plus en plus de disposer de bases de données structurées ainsi que de méthodes et modèles éprouvés et reconnus. Des programmes d’envergure ont donc été mis en place afin d’accroître la connaissance des sols ainsi que la production et la capitalisation de données sol.

2.2- Des programmes d’acquisition et de capitalisation de la connaissance sur les sols

Ainsi, le Groupement d’Intérêt Scientifique Sol (GIS Sol) a été créé en 2001. Il regroupe le Ministère de l’Agriculture, de l’Alimentation, de la Pêche, de la Ruralité et de l’Aménagement du Territoire (MAAPRAT), le Ministère de l’Écologie, du Développement Durable, des Transports et du Logement (MEDDTL) représenté par le Service de l’Observation et des Statistiques (SOeS), l’Institut National de la Recherche Agronomique (INRA), l’Agence de l’Environnement et de la Maîtrise de l’Énergie (ADEME), l’Institut de Recherche pour le Développement (IRD) et l’Inventaire Forestier National (IFN).

Son objectif est de constituer et de gérer la constitution d’un système d’information sur les sols de France et sur l’évolution de leurs qualités. Le GIS Sol mène ainsi plusieurs programmes d’acquisition de données sur les sols, dont la mise en œuvre est coordonnée par l’unité Infosol de l’INRA. L’un des programmes principaux est le programme IGCS3, initié dans les années 90 par le Ministère en charge de l’agriculture et l’INRA, qui définit une méthode de capitalisation des données sols, des procédures normalisées et met à disposition un outil (DoneSol) permettant de construire des bases de données quelle que soit l’échelle du territoire considéré. De nombreuses régions disposent ainsi de Référentiels Régionaux Pédologiques (RRP) compatibles avec une restitution cartographique à l’échelle de 1/250 000 avec des bases de données homogènes (format DoneSol).

Désormais des travaux d’exploitation des bases de données sont entrepris dans chaque région mais ceux-ci sont rarement valorisés en dehors du contexte régional, alors que les investissements méthodologiques et les savoir-faire acquis pourraient être plus largement partagés par la communauté des utilisateurs de données sur les sols.

- 8 -

2.3- Une nécessité de diffusion et de valorisation

Il est nécessaire de mutualiser les moyens, les compétences et les expériences en matière de connaissance sur les sols et ainsi de faire progresser les différentes régions dans leurs projets d’utilisation des bases de données sol pour répondre aux différentes demandes de connaissance sur les sols.

Dans le domaine des sols, un réseau informel existait depuis plusieurs années autour des maîtres d’ouvrages régionaux du programme IGCS et de l’unité InfoSol de l’INRA d’Orléans. Ils avaient comme but commun de mieux faire connaitre les données sur les sols, de favoriser leurs utilisations et de répondre ainsi à divers enjeux territoriaux. Mais ce groupe « projet » ne disposait cependant pas de moyens suffisants pour pérenniser son action et conduire des projets propres.

Le Réseau Mixte Technologique4 « Sols et Territoires » s’est construit à partir de ce noyau. Il est animé par la Chambre Régionale d’Agriculture de Poitou-Charente et l’INRA d’Orléans, et associe 26 partenaires qui élargissent et renforcent le cercle initial. Il s’inscrit donc dans la complémentarité avec les actions du GIS Sol et propose de répondre à deux enjeux auxquels sont associés cinq axes de travail (Figure 3).

Figure 3 : Les axes de travail du RMT "Sols et Territoires"

Ce Réseau Mixte Technologique a donc pour vocation de favoriser la prise en compte des sols dans diverses thématiques, en privilégiant l’approche cartographique et territoriale. C’est dans ce contexte de valorisation des connaissances des sols pour différents territoires et de leur diffusion à tous les utilisateurs (de bases de données-sol) que j’ai effectué mon stage de fin d’étude. Ce stage s’inscrit plus particulièrement dans le cadre de l’Axe n°3 « Concevoir, partager et transférer des méthodes de traitement des données pour répondre à des problématiques connues ou émergeantes ».

4 Les Réseaux Mixtes Technologiques (RMT) mis en place par le Ministère en charge de l’Agriculture en 2007 visent à créer et renforcer des liens entre organismes de recherche, de développement et de formation autour d’une thématique commune.

3- Objectif opérationnel

L’objectif de ce stage est de concevoir un système d’information référençant et facilitant la mise en commun de l’ensemble des applications thématiques réalisées à partir de bases de données sol, ainsi que de leurs méthodes de traitement, dans les régions disposant de bases de données cartographiques sur les sols. Pour répondre à cet objectif, le travail réalisé s’est décomposé en plusieurs étapes décrites dans la figure ci-dessous (Figure 4).

Chapitre II : Analyses préliminaires

pour la conception du système

1- Définition des besoins

1.1- Intérêt d’une base de données

Un état des lieux sur l’utilisation des données sols en France a été effectué (dans le cadre de l’utilisation des données IGCS par les maîtres d’ouvrage régionaux) au travers de deux enquêtes, en 2004 et 2006 (Le Bas et al., 2004; Le Bas et Schnebelen, 2006). Suite à ces enquêtes il est apparu que les maîtres d’ouvrages doivent faire face à une demande accrue en données sols et que le traitement des données nécessaires à la mise en place d’application thématique revêt des niveaux de complexité très variable. De plus, l’investissement méthodologique pour la conception des applications les plus complexes est long et coûteux, c’est pourquoi il est important de valoriser ces applications à l’ensemble des régions utilisant des bases de données cartographiques sur les sols afin de mettre en commun toutes les expériences sur le sujet.

Une nouvelle enquête a été réalisée en 2008 par l’Unité InfoSol dans le cadre de sa mission de coordination et de centralisation de l’information relative aux sols de France. Il était demandé à l’ensemble des maîtres d’ouvrages de référencer leur production sur les sols français. Suite à cette enquête, il est apparu que chaque région référence ses applications selon sa propre méthode de classement et son propre support. La multitude de supports employés pour le référencement des applications entraine, d’une part, un manque d’harmonisation des données, et d’autre part, un manque d’accessibilité à ces données du fait de leur développement en interne, sans réel objectif de diffusion ultérieure. De plus, les méthodes de conception de ces applications ne sont jamais détaillées lors de leur référencement. Ce constat ne correspond donc pas à l’objectif de mise en commun des expériences sur l’utilisation des données sols.

L’ensemble de ces considérations implique donc de référencer sur un support unique un grand nombre de caractéristiques pour une multitude d’applications et leurs méthodes de traitement associées. Ces caractéristiques étant liées les unes aux autres (une méthode de traitement est liées à une ou plusieurs applications, elles même liées à une localisation, un organisme, etc.). Le support employé doit donc être capable de gérer les problèmes de relations entre données. De plus, l’aspect de mise à disposition des informations à un maximum d’utilisateurs est primordial.

Le support le plus approprié à employer pour le référencement des applications thématiques et de leur méthode de traitement est une base de données relationnelle. En effet, l’utilisation d’une base de données relationnelle permet de gérer une grande quantité d’informations et de prendre en compte les relations entre les données. En outre, la conception d’une base de données relationnelle s’appuie sur des méthodes standardisées, ce qui permet de concevoir une base dont la structure est facilement diffusable. En France la méthode la plus répandue est la méthode MERISE5. C’est cette méthode qui sera utilisée pour la conception de la base de données.

5 MERISE est une méthode d’analyse, de conception et de gestion de système d’information. Elle propose une méthodologie pour la réalisation et la conduite de projets informatiques. C’est une méthode très utilisée en France pour la conception de base de données.

- 11 -

1.2- Détermination des usages potentiels de la base de données

Pour concevoir une base de données et favoriser son utilisation, il faut être en mesure d’identifier les attentes des futurs utilisateurs afin de définir clairement les spécifications auxquelles la future base de données devra répondre.

Cette identification passe par la définition des usages potentiels de la future base de données. Un usage peut être défini par différents points :

- les usagers (qui),

- les objectifs visés (qu’est ce que l’on recherche), - le contexte d’utilisation (thématique),

- les contraintes (temporelles, organisationnelles, etc.).

Pour déterminer ces usages il faut être en mesures d’identifier les points cités précédemment. Une phase de prospection des usages potentiels a été réalisée en s’appuyant sur la base de données DemandInfo présente à InfoSol. Cette base de données, sous forme d’un tableur Excel, répertorie l’ensemble des demandes faite à InfoSol (plus de 1100 demandes à ce jour), tant en termes de renseignements sur une thématique en lien avec les sols, que de demandes de données/études sur les sols ou d’autorisation d’accès à la base de données DoneSol.

Dans la structure de DemandInfo on retrouve, entre autres, la demande littérale (permettant de définir l’objectif visé et le contexte), le type de demande (apportant des détails sur l’objectif visé), le type de demandeur (permettant de définir les usagers). Deux enquêtes menées dans le cadre des programmes « WebSol6 » et « GS Soil 7» ont aussi été utilisées pour confirmer et compléter les différents usages potentiels définis grâce à la base de données DemandInfo. Suite à cette phase de prospection j’ai pu proposer des typologies pour chacun des points caractérisant les usages.

Les usagers potentiels qui peuvent être classés correspondent aux organismes demandeurs et concepteurs d’applications thématiques que l’on peut classer selon la liste suivante :

- bureau d’étude / société privée, - organisme d’enseignement, - organisme de recherche, - organisme public,

- organisation professionnelle agricole / forestière, - association,

- particulier / grand public.

Les objectifs d’utilisation sont les questions auxquelles la base de données et son contenu devront pouvoir répondre (la structure de la base de données (tables, champs, relations) devra donc pouvoir répondre à ce genre de problématiques).

Un usager peut rechercher :

 Une méthode de traitement de données :

- pour traiter une thématique sur une localisation donnée, - pour agréger des données sols entre elles,

- pour agréger des données sols et non sols entre elles.

6 _{Le programme WebSol a pour but de favoriser et stimuler l’utilisation du référentiel pédologique (IGCS) dans les régions en développant} un outil de base de données unique pour saisir les données DoneSol et que ces données soient complétées par des bases locales. 7

Le programme GS Soil a pour but d’harmoniser les données sur les sols dans l’Union Européenne afin de les rendre plus accessibles et exploitables dans le cadre des politiques environnementales.

 Des résultats d’applications :

- recherche d’applications disponibles selon différents critères (thématique, échelle, localisation, documents produits, etc.),

- recherche de documents produits à travers une application pour une thématique, sur une localisation.

 Les organismes/personnes ayant des informations détaillées sur telle ou telle application thématique.

 Connaissance de l’évolution des usages des bases de données sols en région :

- qualitatif : identifier les thématiques et problématiques déjà traitées et émergeantes en région,

- quantitatif : montrer l’utilité des bases de données sols à différents publics/acteurs et l’ampleur de leur utilisation.

Les contextes d’utilisation de la future base de données peuvent se résumer, d’une part, aux thématiques de l’application (la typologie complète est présentée en Annexe 1) :

- Gestion des sols/Préservation de la ressource sol,

- Gestion du territoire/Préservation de ressources ou d’écosystèmes, - Gestion du territoire/Durabilité d’activités,

- Connaissance de la ressource en sol, - Autres.

D’autre part, aux domaines d’utilisation de la base de données : - recherche,

- enseignement et formation,

- étude / ingénierie / conseil/ animation territoriale, - communication grand public,

- communication institutionnelle.

Enfin, il est important de bien intégrer les contraintes que les utilisateurs du système d’information pourraient rencontrer et proposer des solutions en adéquation :

- accès à la base de données : modalités de diffusion de la base aux utilisateurs,

- condition d’utilisation de la base de données : modalités d’accès à la base de données, - condition d’administration de la base de données : modalités d’administration de la base, - saisie et interrogation dans la base de données : modalités de saisie et d’interrogation, - simplicité et intuitivité des interfaces de la base : caractéristiques de l’interface à adopter, - compréhension de la structure de la base : besoin d’un support d’aide à l’utilisateur.

Cette détermination des usages potentiels de la base de données a ensuite été complétée par une enquête auprès d’un panel de futurs usagers.

- 13 -

1.3- Enquête : attentes des utilisateurs vis-à-vis du futur système d’information

Une enquête sous la forme d’un court questionnaire a été réalisée (Annexe 2) puis envoyée par mail à l’ensemble des participants du séminaire d’ouverture du RMT « Sols et Territoires », c'est-à-dire à environ 200 personnes. En plus du questionnaire, un fichier permettant aux destinataires de renseigner les applications thématiques qu’ils avaient en leur possession a aussi été envoyé. A la fin de la période de collecte des réponses, nous avons comptabilisé 44 questionnaires retournés, sur les 204 envoyés : nous avons donc eu un taux de retour d’environ 21,5 % ce qui est suffisant pour valider les résultats de cette enquête. Une fois l’ensemble des réponses collectées le traitement des résultats de cette enquête a pu être réalisé afin de faire l’état des lieux sur les attentes des futurs utilisateurs et ainsi valider ou non les usages définis précédemment (dépouillement détaillé des

réponses présenté en Annexe 3).

La liste des usagers potentiels établie dans la première phase de prospection semble correcte et exhaustive, les personnes enquêtées se sont retrouvées dans la liste des usages. En effet, l’ensemble des types d’usagers sont représentés dans les réponses, bien que certains le soit plus (organisations professionnelles agricoles et forestières (36%), organismes publics (23%)) que d’autres (organismes d’enseignement (9%), associations (5%)). On constate néanmoins qu’il n’y a eu aucune réponse de la part de particuliers. Toutefois, le type d’usager « Particulier / Grand public » est conservé car la base de données devra pouvoir référencer des applications provenant de n’importe quel type d’usager. Les contextes d’utilisation possibles de la base ont été divisés en domaine d’utilisation d’une part et en thématique de l’application d’autre part. Pour ce qui est des domaines d’utilisation, cette fois encore la liste semble exhaustive ; la répartition des domaines d’utilisation semble cohérente avec celle des types d’usagers étant amenés à utiliser la base de données. En effet, les domaines majoritaires « étude / ingénierie / conseil / administration territoriale » (39%) semblent bien correspondre aux problématiques que peuvent avoir à traiter les organisations professionnelles agricoles et forestières ainsi que les organismes publics.

Les thématiques semblent aussi correctes et complètes. En effet, toutes les thématiques de la liste ont été cochée au moins 5 fois, ceci s’explique par le fait que l’ensemble des usagers concernés par les bases de données cartographiques sur les sols peuvent avoir à traiter un vaste panel de thématiques selon les enjeux considérés : agricoles, ruraux, économiques, environnementaux et sociaux. En outre, aucune thématique supplémentaire n’a été proposée par les personnes enquêtées. Il faut toutefois noter que lors de la phase de saisie des données plusieurs thématiques ont été ajoutées. La typologie des thématiques a donc quelque peu évolué au fur et à mesure de l’avancée du projet.

Les objectifs d’utilisation peuvent être considérés comme les usages à proprement parlé de la future base de données. Au final l’ensemble des usages possibles a été validé par les personnes interrogées et les proportions sont à peu prêt identiques. De plus, bien qu’il y ait eu des propositions dans la section « Autres», celles-ci ne semblaient pas compatibles du point de vue des objectifs de départ. Enfin, pour ce qui est des contraintes d’utilisation du système d’information, l’ensemble des personnes interrogées a confirmé qu’Internet, au travers d’une interface web, serait la meilleure des solutions de diffusion de la base de données. Du point de vue des modalités d’interrogation et de saisie dans la base de données les réponses sont moins tranchées. En effet, deux choix ont été proposés aux enquêtés : par requête SQL à réaliser soi-même (en ayant pris connaissance au préalable de la structure de la base de données) ou par recherche sous forme de formulaires. Bien que la majorité des utilisateurs souhaitent une recherche par formulaire, 32% des réponses allaient dans le sens d’une recherche par requête SQL. Du point de vue des modalités de renseignement les utilisateurs sont encore plus partagés. 57% souhaitent que la base de données soit remplie par un

administrateur de données, sachant que l’administrateur reste à définir et que cette méthode nécessite un suivi régulier des applications créées en région. 43% souhaitent remplir eux-mêmes la base de données en passant par une interface web.

2- Analyse de l’existant

2.1- En région, dans les organismes concernés

 Systèmes d’information référençant les applications :

L’enquête réalisée en 2008 par l’Unité InfoSol montre que les supports existants pour le référencement des applications sont multiples : simple fichier texte, tableur de type Excel, base de données Access. De plus, toutes les régions ne référencent pas obligatoirement leurs productions. La majorité des organismes produisant des applications thématiques les référencent à l’aide de tableurs de type Excel. Ce type de support permet de garder une trace des productions mais n’est pas adapté aux usages définis dans l’étude du besoin. En effet, la structure des données contenues dans les tableurs est de type linéaire, il n’y a aucun aspect relationnel entre les données, ce qui empêche de les exploiter par la suite pour répondre à des objectifs tels que ceux souhaités par les utilisateurs de base de données cartographiques sur les sols.

L’utilisation d’un système de gestion de base de données (SGBD) semble être la solution la plus adéquate, pourtant il est très peu usité par les organismes par manque de moyens. De tous les organismes ayant répondu à l’enquête, seule la Bourgogne a fourni une base de données Access. Toutefois, la structure de cette base de données est assez sommaire et son contenu en termes de champs n’est pas adapté à nos objectifs. L’utilisation d’un SGBD pour référencer les applications est donc une bonne initiative mais les structures actuelles développées en région ne permettent pas de répondre aux usages du futur système d’information.

 Informations sur les applications existantes :

L’enquête de 2008 révèle un nombre d’application assez hétérogène par région. Il apparaît tout d’abord que le contenu des réponses est assez inégal. En effet, certains organismes n’ont indiqué qu’une dizaine d’applications en leur possession tandis que d’autres ont fourni des listes beaucoup plus conséquentes (100 à 200 applications). Néanmoins, il y a un nombre important d’applications disponibles en régions (plusieurs centaines), elles peuvent donc être référencées dans la base de données.

Toutefois, les informations sur chacune des applications sont souvent assez succinctes : titre, commanditaires, date, échelle et superficie. Il n’y a aucune information sur les méthodes de traitement, ce qui est un frein à l’utilisation de la méthode ou des résultats de l’application considérée.

2.2- A l’INRA, Unité InfoSol

 Systèmes d’information référençant les applications :

Au sein de l’Unité InfoSol, plusieurs solutions ont été développées pour le référencement des productions utilisant des données sols. Tout d’abord, une base de données Access « inventaire_demandes_igcs » a été conçue et utilisée pour référencer les applications réalisées dans le cadre du programme IGCS. La structure de cette base répond en partie aux usages souhaités par les utilisateurs (recherche de résultats d’application). Il est possible, entre autres, de rechercher des

- 15 -

résultats d’applications par thématiques, par organismes, etc. Cependant, la dénomination des tables et des champs est assez complexe et la structure n’est pas adaptée à l’utilisation souhaitée. En effet, la localisation des applications n’est pas détaillée et il n’y a aucune information sur les références bibliographiques ou documents produits. De plus, la description des organismes intervenants dans la réalisation de l’application est trop complexe : maître d’œuvre, maître d’ouvrage, chargé d’étude, une description par organisme demandeur/concepteur est préférable. Enfin, cette structure ne prévoit pas de renseigner les méthodes de mise en œuvre des applications, il n’est donc pas possible pour un utilisateur de rechercher les méthodes de traitement des données en rapport avec les applications.

InfoSol utilise aussi une base de données bibliographique sous EndNote pour référencer ses productions en format papier (rapports et études). Cette base de données, de type bibliographique, ne sert qu’à référencer les caractéristiques principales des documents (titre, année, auteur(s), type) et ne peut donc pas être utilisée dans le cadre du projet.

 Informations sur les applications existantes :

La base de données « inventaire_demandes_igcs » contient un total de 250 applications renseignées en terme de thématiques, échelle, organismes, etc. Il sera donc nécessaire de les importer dans la base une fois la conception du système d’information achevée. Cependant, pour renseigner les méthodes de traitement de chaque application il sera nécessaire, cette fois encore, de contacter les concepteurs afin de leurs demander des détails sur le sujet. De plus, certaines des applications n’ont que très peu d’informations, il serait intéressant d’en obtenir une version complète (papier ou numérisée) afin de compléter leurs caractéristiques. La base bibliographique sous EndNote contient environ 350 références. Il sera nécessaire de reprendre un à un chacun des documents afin de les enregistrer dans la base. L’avantage d’avoir à disposition la version papier des applications est qu’il est aisé d’en décrire les méthodes de traitement.

De plus, l’INRA est adhérente à l’Association Française d’Etude des Sols (AFES), qui publie quatre fois par an la revue Etude et Gestion des Sols (EGS), ce périodique se présente comme un recueil d’articles sur le sujet des sols. Une grande partie de ces articles peuvent être considérés comme des applications thématiques à part entière, il sera intéressant de les référencer dans la future base de données avec leur méthode de traitement correspondante, lorsque l’article le permet.

3- Cahier des charges du système d’information

3.1- Choix techniques

3.1.1- Choix logiciel

Avant de commencer à concevoir le système d’information, et donc la base de données il faut tout d’abord choisir le système de gestion de base de données à adopter, il m’a paru logique que le choix du SGBD se fasse parmi ceux utilisés au sein de l’unité. L’Unité InfoSol gère depuis plusieurs années de nombreuses bases de données et le SGBD le plus fréquemment utilisé pour cette gestion est PostgreSQL. C’est un système de gestion de bases de données relationnelle et objet (SGBDRO), il est libre et disponible selon les termes d’une licence de type BSD8. PostgreSQL et ses extensions sont utilisés, entre autres, pour la conception et la gestion de la base de données nationale sur les sols DoneSol.

L’utilisation du SGBD PostgreSQL pour l’ensemble du projet semble être la meilleure solution. D’une part en termes de pérennité du système d’information, car ce logiciel étant utilisé régulièrement au sein de l’unité par les administrateurs de base de données et les développeurs, un support technique est toujours disponible et l’évolution du système d’information créé sera possible. D’autre part, le contenu de la base de données devrait être accessible directement sur internet. La solution idéale est de développer les formulaires de saisie et d’interrogation de la base de données en PHP afin qu’ils puissent être diffusés sur le site Web du RMT « Sols et Territoires ».

De par ses caractéristiques et son passé d’utilisation dans l’unité, PostgreSQL semble être la solution la plus adaptée pour le développement du système d’information. Toutefois, la maîtrise du PHP nécessite un investissement trop important pour la durée du stage. C’est pourquoi, il a été décidé que la conception du système d’information se fasse en deux temps et en utilisant deux logiciels distincts.

Dans un premier temps, se feront la conception de la base de données sous SGBD Access et le développement des interfaces utilisateurs en langage de programmation VB9. Puis, au delà du stage, l’export de la base en format Access sera réalisé vers le format PostgreSQL à l’aide de l’extension DataPump (extension du logiciel SQLManager for PostgreSQL) pour ensuite pouvoir développer les formulaires d’interrogation Web en PHP. Les objectifs principaux du stage pourront ainsi être atteints, à savoir : la conception d’une base de données opérationnelle et de son interface de saisie ainsi que l’inventaire des applications et leur saisie dans la base de données.

3.1.2- Architecture réseau de la base de données

Une base de données peut fonctionner sur une machine autonome (base de données bureautique), pour un utilisateur individuel. Mais elle devient plus intéressante en réseau, car elle est capable de gérer les accès concurrents, ainsi plusieurs personnes peuvent y travailler simultanément, les données restant centralisées. Bien que l’utilisation du SGBD Access ne soit que temporaire dans le projet de conception du système d’information il faut que la base de données en format Access soit enregistrée sur le serveur de l’unité par mesure de sécurité et de sauvegarde des données. De plus, afin de diminuer le temps de saisie des applications il faut que plusieurs utilisateurs puissent accéder en même temps à la base de données. Or, dans les versions récentes

8

La licence BSD (Berkeley Software Distribution) est une licence libre utilisée pour la distribution de logiciels. Elle permet de réutiliser tout ou partir du logiciel sans restriction, qu’il soit intégré dans un logiciel libre ou propriétaire.

9

Le Visual Basic (VB) est un langage de programmation événementielle dérivé du BASIC qui permet le développement rapide d’applications, la création d’interface utilisateurs graphiques, l’accès aux bases de données ainsi que la création de contrôles ou objets ActiveX.

- 17 -

d’Access, tout passage en mode création (construction ou modification d’un formulaire, modification d’une table, d’une requête, etc.) verrouille la base de données en mode exclusif. Il en résulte que dès qu’une modification, même mineure, est effectuée sur la base de données, tout accès est bloqué pour les autres utilisateurs. Il m’a donc paru nécessaire de trouver une solution permettant d’accéder à la base de données en mode « multi-utilisateurs ».

La solution retenue est de scinder la base de données en deux parties : dorsale et frontale (deux fichiers .mdb distincts). Le principe des bases dorsales/frontales ressemble à celui du client/serveur : d’un côté les données et de l’autre l’interface utilisateurs ou IHM10. L’architecture serveur sera la suivante : la base dorsale (ou back-end) contenant uniquement les tables et les relations (donc les règles d’intégrité) du système d’information sera placée sur le serveur et donc accessible à tous les utilisateurs. La base frontale (ou front-end), contenant tout le reste du système d’information (requêtes, formulaires, états, macros, modules et tables temporaires) sera placée sur chacun des postes utilisateurs, connectés au même réseau que le serveur (Figure 5).

Figure 5 : Architecture réseau du système d'information

Ensuite, à l’aide d’un outil fourni avec Access il suffit de lier les tables de la base dorsale à la base frontale en indiquant le chemin d’accès de la base dorsale sur le serveur. La base frontale ne contient donc pas les tables d’enregistrement des données, mais simplement des vues sur les tables réelles de la base dorsale. De cette manière les performances d’utilisation de la base sont améliorées ; lorsqu’un utilisateur se connecte à la base, il ne rapatrie plus sur sa machine que les données. Les autres éléments (l’interface notamment) sont chargés directement depuis sa propre machine. De plus, la mise à jour du système d’information est plus aisée, si un objet est ouvert en mode création, seule la base frontale est verrouillée (la majorité des mises à jours se faisant du côté applicatif et moins souvent du côté tables). Il est donc possible d’améliorer l’interface de saisie pendant que d’autres utilisateurs continuent de travailler sur leur base frontale. Lorsque les modifications sont terminées, il suffit de recopier la base frontale sur les machines des utilisateurs (en écrasant leur ancienne frontale) pour la mettre à jour.

10

Interface Homme-Machine (IHM) : Terme désignant l'ergonomie du logiciel. Il désigne communément l'interface graphique du logiciel mais ne se limitant pas à elle, l'IHM regroupe tous les moyens physiques et virtuels permettant une interaction entre le logiciel et ses utilisateurs humains.

3.1.3- Sécurité de la base de données

La mise en réseau de la base de données Access sur le serveur de l’unité permet une meilleure centralisation des données et l’accès simultané de plusieurs utilisateurs. Toutefois, si l’on ne configure pas correctement l’application Microsoft Access, cette solution augmente les risques du point de vue de la sécurité. En effet, n’importe quel utilisateur ayant accès au serveur peut, volontairement ou non, ouvrir et modifier le contenu et la structure de la base de données.

La sécurité choisie pour la base de données ApplicaSol est une sécurité utilisateur. Elle est de type « applicative », c'est-à-dire que la sécurisation se fait directement au niveau de la configuration de l’application. La protection se fait par droit d’accès et met en œuvre des concepts de groupes, d’utilisateurs et de droits, une bonne étude du fonctionnement de l’application et des tâches des utilisateurs est obligatoire.

Dans le cas de ma base de données le nombre d’utilisateur est assez restreint, toutefois il est intéressant de les classer dans différents groupes faisant eux-mêmes parti d’un même groupe de travail, La figure ci-dessous (Figure 6) résume l’organisation de la sécurité de la base de données ApplicaSol.

Figure 6 : Schéma d'organisation de la sécurité de la base de données ApplicaSol

Trois groupes d’utilisateurs distincts ont été créés afin de mieux limiter les droits d’accès selon l’utilisation de la base, l’ensemble de ces groupes est enregistré dans le groupe de travail « ApplicaSol_system ». Tout d’abord le groupe « Admin_ApplicaSol », il ne contient qu’un compte utilisateur : « SuperUser », c’est en fait l’administrateur de l’ensemble du système d’information (bases dorsales et frontales). Il est le seul à pouvoir administrer les droits des autres utilisateurs. Le groupe « Dev_ApplicaSol » est réservé aux utilisateurs s’occupant du développement du système d’information. En plus du droit de lire et modifier les données ils possèdent le droit de modifier la structure des objets de la base (tables, formulaires, macro…).

Enfin, le groupe « Saisie_ApplicaSol » est réservé aux utilisateurs s’occupant de saisir des applications et leurs méthodes de mise en œuvre dans la base de données. Ils possèdent le droit de lire, modifier, supprimer et ajouter des données dans les tables. Par contre ils n’ont aucun droit de modification de structure des objets du système d’information.

- 19 -

3.2- Aide à l’utilisation d’ApplicaSol

Afin d’améliorer et de faciliter l’utilisation du système d’information, un support d’aide est disponible avec la base de données. Il présente différents documents (pour plus de détails, voir le

document papier joint à ce mémoire) :

 Le dictionnaire de données de la base de données ApplicaSol, qui recense l’ensemble des informations gérées par le Système de Gestion de Base de Données. Il permet de savoir quelles sont les données contenues dans la base, et de connaître leur structure. On y trouve, pour chaque table de la base de données, le nom informatique (mnémonique) utilisé pour chaque donnée, son type (texte, numérique, booléen…), sa dimension en nombre de caractères et une description textuelle de la donnée en question.

 Une aide pour l’utilisation des interfaces de saisies et d’interrogation de la base de données. Chaque étape d’enregistrement d’une application et de sa méthode est décrite en détail avec les captures d’écran correspondantes afin de guider l’utilisateur tout au long de la saisie d’une application dans la base.

 Un guide pour l’administration du système d’information est disponible pour l’administrateur de la base. Il peut y trouver des explications pour l’installation du système d’information sur le serveur (base frontale et dorsale) et sa sécurisation, mais aussi un guide d’utilisation de l’interface d’administration permettant de gérer les connections des utilisateurs à la base de données ApplicaSol.

Chapitre III : Etapes de conception du

système d’information

- 20 -

1- Recherche d’une structure en adéquation avec les usages

L’étude du besoin menée en début de projet a permis de cerner les attentes des utilisateurs vis-à-vis de la future base de données. Afin qu’elles soient satisfaites, il est nécessaire que la structure de la base (tables, champs, clefs étrangères) puisse répondre aux usages validés suite à l’enquête. En premier lieu, l’ensemble des tables et champs nécessaires à chaque usage a été déterminé. Voici, ci-dessous, un exemple pour l’usage «objectif visé » :

 Recherche de méthode de traitement de données - pour agréger des données sols entre elles :

 Recherche de résultats d’applications :

- recherche d’applications disponibles selon différents critères (thématique, échelle, localisation, documents produits, etc.) :

Une fois cette recherche effectuée pour chaque usage, j’ai finalement défini comme entités (ou regroupement d’informations communes à une même classe d’objet) les tables suivantes (Figure 7

page suivante) :

- La table APPLICATION décrit l’application de façon générale : titre, année de réalisation, finalité etc. Elle décrit également la résolution et l’étendue de l’application (à savoir l’échelle d’un point de vu cartographique ainsi que la surface cartographique sur laquelle s’étend l’application.

- La table THEMATIQUE décrit la thématique de l’application. Cette table se compose de groupes de thématiques eux-même décomposés en thématiques. Pour certaines thématiques un troisième niveau est utilisé, les sous-thématiques.

- La table LOCALISATION permet de connaître le ou les départements sur le(s)quel(s) l’application a eu lieu ainsi que leur région correspondante.

- La table ORGANISME répertorie les organismes demandeurs et concepteurs intervenant dans une application et donne leurs principales caractéristiques (sigle, nom, coordonnées, site web, etc.).

- La table METHODE_GENERALE décrit la méthode générale de mise en œuvre de l’application : description, libellé, approche employée, facilité de mise en place, et validation de la méthode.

- La table ETAPE_TRAITEMENT décrit la ou les étapes de traitement utilisée dans la méthode générale de mise en œuvre de l’application. On y retrouve le numéro et le nom de l’étape de traitement ainsi que le type de méthode de traitement employé et une brève description de cette dernière.

- La table AUTEURS répertorie les auteurs ayant réalisé une référence bibliographique ou les personnes source de l’information sur l’application, qu’elles soient auteurs de l’application ou non.

- La table REFERENCES_BIBLIO réunit l’ensemble des références bibliographiques et documents en rapport avec l’application ainsi qu’avec les différentes méthodes ou étapes de traitements mises en œuvre pour créer cette application.

2- Conception de la base de données ApplicaSol selon la méthode Merise

Les entités principales de la base de données étant déterminées, j’ai pu m’atteler à la conception de la structure de la base de données ApplicaSol. Cette conception suit les étapes préconisées dans la méthode Merise (méthode d’analyse, de conception et de réalisation de systèmes d’informations informatisés).

2.1- Le Modèle Conceptuel de Données (MCD) de la base de données ApplicaSol

La réflexion menée précédemment, sur l’ensemble des usages, permet d’avoir une meilleure vision du contenu de la base de données ApplicaSol et d’établir le Modèle Conceptuel de Données (MCD). Il résume non seulement les associations (ou liaisons logiques) entre chaque entité de la base, mais aussi les cardinalités11 de ces associations (Figure 7).

Figure 7 : Modèle Conceptuel de Données (MCD) de la base de données ApplicaSol Le modèle conceptuel comporte trois grandes parties :

- En rouge, la partie spécifique aux applications thématiques. Cette partie permet de décrire de manière complète une application : caractéristiques générales (titre, année, finalité,

11 La cardinalité d’un lien entre une entité et une association précise le minimum et le maximum de fois qu’un individu de l’entité peut être concerné par l’association.

- 22 -

résolution, étendue, etc.), organisme demandeur/concepteur, localisation (région(s), département(s)), thématique(s), etc.

- En vert, la partie spécifique à la méthode de mise en œuvre de l’application. On retrouve dans cette partie les caractéristiques de la méthode générale de mise en œuvre (libellé, approche, résolution, etc.), mais aussi un résumé des différentes étapes de traitement avec les données utilisées dans chacune d’elle.

- En bleu, la partie spécifique aux références bibliographiques. On retrouve dans cette partie l’ensemble des références bibliographiques et documents disponibles pour une application ainsi que pour une méthode de traitement des données.

2.2- Passage du Modèle Conceptuel de Donnée au Modèle Logique de Données (MLD)

Les cardinalités étant définies pour chacune des associations, il est possible de déterminer le Modèle Logique de Données (Figure 8). On retrouve dans ce modèle les mêmes parties que dans le MCD.

Figure 8 : Modèle Logique de Données (MLD) de la base de données ApplicaSol

Pour traduire un MDC en MLD il suffit d’appliquer un certain nombre de règles. Ces règles permettent de transformer les entités en table dans laquelle les attributs deviennent des champs, l’identifiant de l’entité constitue alors la clé primaire de la table. De plus, ces règles permettent de transformer les associations et leurs cardinalités en relations, ou en table de jonction supplémentaire dans le cas de deux cardinalités 1 : n (tables « affect…»).

2.3- Implémentation du Modèle Logique de Données dans le SGBD Access

Enfin, dans la dernière étape de conception de la base de données, le Modèle Logique de Données est implémenté dans le Système de Gestion de Base de Données (SGBD) Access. On passe alors au Modèle Physique de Données (MPD). Cette traduction d’un MLD en MPD précise notamment le stockage de chaque donnée à travers son type et sa taille. Les détails sur les caractéristiques des champs de chaque table, sont donnés dans le dictionnaire de données de la base de données ApplicaSol.

3- Conception des interfaces de saisie et d’administration

3.1- Interface de saisie des données

L’interface de saisie va permettre à l’utilisateur de saisir de nouvelles données dans la base ApplicaSol simplement et rapidement en passant directement par des formulaires. Ce choix permet d’éviter à l’utilisateur d’avoir à remplir les tables de la base une à une, ce qui est long et fastidieux. L’accès aux différents formulaires se fait par le biais d’une application Access (« ApplicaSol_user ») développée en Visual Basic for Application (extrait du code VBA présenté en Annexe n°4). La saisie d’une application se fait en deux étapes, matérialisées par deux formulaires principaux bien distincts : l’enregistrement des caractéristiques d’une application puis l’enregistrement de sa méthode de mise en œuvre si elle est disponible. Ces deux choix sont proposés dans le menu général, après le démarrage de l’application (Figure 9).

Figure 9 : Menu général de l'interface de saisie d'ApplicaSol  Formulaire de saisie des caractéristiques d’une application :

Le formulaire de saisie d’une application comprend 7 parties qui permettent de renseigner l’ensemble des tables de la section « Application » de la base de données, ainsi que les références bibliographiques et documents produits (section « Référence Bibliographique »). Chacune des ces parties correspond à la vue d’une table à remplir, avec ses champs correspondants. La saisie de la partie 1 (données générales sur l’application) est obligatoire pour pouvoir passer aux autres ; en effet c’est dans cette partie que l’on crée l’application dans la base de données (Figure 10).

Figure 10 : Formulaire de saisie d'une nouvelle application dans la table "application"

Les autres parties du formulaire servent à compléter les caractéristiques de l’application : localisation (région et département), organismes demandeur/concepteur, thématiques, personnes source de l’information (Figure 11 page suivante).

- 24 -

Figure 11 : Suite du formulaire de saisie permettant d’indiquer les renseignements complémentaires d’une application, Lors de l’encodage d’une nouvelle application, les données telles que les thématiques, la localisation, etc. existent déjà dans la base de données. C’est pourquoi la sélection directement dans les tables correspondantes est possible grâce aux différents formulaires de sélection (le détail de ces formulaires est visible dans le support d’aide à l’utilisation d’ApplicaSol). Par contre, si par exemple un auteur n’existe pas dans la base, il est possible de l’ajouter ou même de le modifier via ces formulaires.

 Formulaire de saisie d’une méthode de mise en œuvre d’application :

La saisie d’une méthode de mise en œuvre est basée sur le même fonctionnement que celle d’une application. La seule différence est qu’une méthode ne peut-être encodée dans la base que si au moins une application dont la méthode peut-être décrite existe. Les étapes de saisie sont les suivantes : choix de l’application dont on veut renseigner la méthode de mise en œuvre, renseignement des caractéristiques de la méthode générale, description des étapes de traitement et des données utilisées. Les formulaires ayant un fonctionnement et un design identique aux précédents, ils ne sont pas présentés dans ce mémoire mais sont disponibles dans le support d’aide à l’utilisation.

3.2- Interface d’administration de la base de données

Comme plusieurs utilisateurs peuvent se connecter simultanément à la base de données ApplicaSol il est important de pouvoir gérer ces connections. Une interface d’administration sous forme de formulaires Access a donc été développée, toujours en langage VBA, en plus de l’interface de saisie. Cette interface d’administration est utilisable seulement par les membres du groupe de travail « Admin_ApplicaSol », c'est-à-dire par l’administrateur du système d’information (compte utilisateur : SuperUser). Pour l’utiliser il suffit de démarrer l’application « ApplicaSol_administration » et de se connecter avec les identifiants du compte « SuperUser ». Dans le menu général (Figure 12),

deux choix s’offrent à l’administrateur : soit gérer les connections à la base de données ou gérer le contenu de la table des index ainsi que des tables thématique et organisme.

Figure 12 : Menu général de l'application "ApplicaSol_administration" permettant d'administrer la base de données Le formulaire de gestion de connexion permet de rechercher le chemin de la base dorsale sur le serveur de l’unité (base « ApplicaSol_principale). Une fois la base de données sélectionnée il est possible de lancer un scan permettant d’afficher l’ensemble des utilisateurs connectés à la base de données (Figure 13).

Figure 13 : Formulaire de gestion des connexions à la base de données ApplicaSol

(Ici, l’utilisateur « F. Helies » est connecté à partir de l’ordinateur « ALABASTER »).

Ce formulaire permet aussi de mettre la base de données en mode maintenance. Ce mode empêche tout nouvel utilisateur de se connecter à la base de données. Ainsi, il est possible pour l’administrateur de bloquer l’accès à la base à tout moment afin d’y faire des modifications. Les utilisateurs déjà connectés à la base peuvent être prévenus de la maintenance par l’envoi d’un message grâce à la fonction « Net Send »12. L’administrateur peut ainsi leur demander de se déconnecter de la base, le temps de la maintenance. Les autres fonctionnalités de l’interface administration permettent de modifier le contenu des tables « thematique », « organisme » et de la table « index_code_num ». Ces fonctionnalités sont détaillées dans le support d’aide.

La conception de la base de données et de ses interfaces étant finalisée, la prochaine étape est de saisir des applications dans la base de données afin d’évaluer son bon fonctionnement.

12 NET est un service qui dispose de nombreux outils pour gérer les réseaux Microsoft. Un de ses composants, SEND, permet d’envoyer des messages à des utilisateurs sur le réseau. Ces messages qui apparaissent instamment sur l’écran sous la forme d’une fenêtre Service Messagerie sont surnommés des « net send ».

Chapitre IV : Saisie et évaluation de la

base de données