Zendaoui Drici

Mémoire de fin d’études
Pour l’obtention du diplôme d’Ingénieur d’Etat en Informatique

Option : Systèmes d'information
Thème
Conception et réalisation d’une application web pour
la gestion du prêt entre bibliothèques
Rapport final
Réalisé par Encadrées par

- ZENDAOUI FAIROUZ - W. K. HIDOUCI
- DRICI CHERIFA - A. LADGHAM
Soutenu le : 30 septembre 2010

Devant le jury composé de :
- BENHOUHOU AMAR
- HAMIDI BAYA
- LADGHAM AMINA
- SAID L'HADJ LYNDA
Promotion : 2009/2010
1
Résumé
Aucune bibliothèque ne peut se prétendre aujourd‟hui à l‟autosuffisance et proposer au

niveau local l‟exhaustivité des collections, pour remédier à cela, les bibliothèques se sont
dirigées vers un travail coopératif complémentaire, qui consiste à permettre à une bibliothèque
de faire profiter ses lecteurs du fond documentaire d‟une autre bibliothèque. Un des moyens
pouvant permettre ce service est la mise en œuvre d‟un réseau de bibliothèques qui possède
un site internet dynamique permettant aux lecteurs d‟exploiter un fond documentaire plus
riche regroupant toutes les collections des bibliothèques participantes.
Dans ce contexte, notre travail consiste à concevoir une application web qui permet aux
adhérents des bibliothèques membres du réseau de rechercher une ressource à travers le
catalogue collectif des bibliothèques, consulter sa fiche descriptive, réserver un exemplaire, et
d‟annuler une réservation… etc.
Cette application permet aussi la gestion du prêt entre bibliothèques : les prêts et
restitutions, les transitions de ressources entre bibliothèques… etc.
Les bibliothèques sont distantes, autonomes et dotées de systèmes de gestion différents.

Notre application web va s‟adapter à ces conditions en s‟inspirant de la « Médiation » qui est
une approche d‟intégration de sources de données hétérogènes et distribuées.
Mots clés
Prêt entre bibliothèques, réseaux de bibliothèques, bases de données réparties, architecture de

médiation, application web.
2
Remerciements
Nous souhaitons manifester nos sincères remerciements à Dieu le tout puissant

qui nous a donné la foi, la force et la patience pour aller jusqu‟au bout de ce
travail,
Nous exprimons toute notre gratitude pour Nos Promoteurs, Monsieur

W.K.Hidouci et Madame A.Ladgham pour leurs précieux conseils, leur
disponibilité, la confiance qu‟ils nous ont toujours témoignée et la sollicitude
dont ils nous ont entourées.
Nous n‟oublions pas non plus Nos Enseignants, depuis l‟école primaire aux
études supérieures pour toutes les connaissances qu‟ils nous ont transmises.
Nous adressons une pensée affective à Nos Amis de l‟ESI qui ont rendu
agréables nos années d‟études.
Nous remercions tout particulièrement Les Membres du Jury, pour avoir accepté
de participer en tant qu'Examinateurs à notre soutenance.
Nous tenons enfin à remercier tous ceux qui ont collaborés de près ou de loin à
l‟élaboration de ce travail. Qu‟ils acceptent nos humbles remerciements.
Fairouz & Cherifa
3
Dédicaces
A mes très chers et adorables parents Hassina et Zoubir qui n’ont jamais cessé
de m’encourager et de me soutenir. Je ne saurais exprimer ma gratitude et ma
reconnaissance. Je vous souhaite une longue et heureuse vie, que dieu vous
garde pour moi,
A mon fiancé Adnane qui m’a beaucoup aidée et soutenue et qui a toujours cru
en moi,
A mes gentilles et sympathiques sœurs Nesrine et Yasmine,
A toute ma famille et à ma belle famille,
A toutes mes amies Cherifa, Islam, Manel.H, Manel.K, Sara et aux moments
inoubliables qu’on avait passés ensemble,
A tous ceux que j’aime et qui m’aiment
Je dédie ce modeste travail.
Fairouz
4
Dédicaces
Merci à Allah le genreux, qui a éclairé les nuits difficiles passées loin de ma
demeure,
A mon camarade, ami, professeur et père Farid qui m’a continuellement

encouragé et soutenu,
A ma mère, douce Dounia Zed, qui a veillée à ce que je devienne ce que je suis,
A mon cher frère Fayçal et ma merveilleuse sœur Imèn,
A ma perle bleue,
A toute ma famille,
A Islam, Fairouz, Nadia, Saadia, Fadhila, Zora, Zahra, Meriem, Fatiha et aux
souvenirs de nos aventures,
Aux professeurs qui m’ont enseigné et encadré depuis mes premiers pas à
l’école jusqu’à l’université,
A mes collègues et amis qui m’on accompagné ces cinq ans passées à l’INI,
A ceux qui me connaissent et croient en moi et que je n’ai pas cité
A tous ceux-là je dédie ce modeste travail.
Cherifa
5
Sommaire
Introduction générale 13
1. Contexte 14
2. Problématique 14
3. Objectifs 14
4. Organisation du mémoire 15
Partie 1 : Etat de l’art 17
Chapitre 1 : Le prêt entre bibliothèques (PEB) 18

1. Introduction 19
2. Définition 19
3. Gestion de la demande de prêt 20
3.1. Les acteurs 20
3.2. Les outils 22
4. Transmission du document 23
4.1. Support de transmission 23
4.2. Mode de transmission 23
5. Tarification et statistiques 24
6. Services 24
6.1. Impala 24
6.2. Subito 24
6.3. Catalogue Collectif Suisse 25
6.4. LinkUK 26
7. Les répertoires de bibliothèque 26
8. Les catalogues collectifs 28
8.1. Avantages et inconvénients des catalogues collectifs 29
8.2.Typologie des catalogues collectifs 30
8.3. Exemples de catalogues collectifs 30
9. Conclusion 35
Chapitre 2 : Bases de données réparties et médiation 37

1. Introduction 38
2. Bases de données reparties (BDDR) 38
6
2.1. Définition 38
2.2. Buts et objectifs de la répartition 39
2.3. Approches de conception d‟une BDD repartie 40
3. Intégration de données : Approche de médiation 42
3.1. Architecture de médiation de base 44
3.2. Types de médiation 46
3.3. Intégration de schéma 47
3.4. Processus de médiation 49
4. Conclusion 49
Partie 2 : Conception et mise en œuvre 50
Méthode d‟analyse et de conception 51

1. Le langage UML 52
2. Le processus 2TUP 53
Chapitre 3 : Proposition de la solution 56

1. Présentation du projet à réaliser 57
2. Proposition de la solution 57
3. Besoins de l‟application auprès des bibliothèques 58
4. Propriétés du système 59
5. Architecture de médiation 60
5.1. Schéma global 61
5.2. Langage commun à base de méthodes 62
5.3. Médiateur 62
5.4. Adaptateurs 63
6. Fonctionnement de la médiation 65
6.1. Recherche fédérée de ressource 65
Chapitre 4 : Etude préliminaire 68

1. Recueil des besoins fonctionnels 69
2. Recueil des besoins opérationnels 75
3. Fonctionnalités du système 77
4. Architecture fonctionnelle en paquets 79
5. Identification des acteurs 80
6. Identification des messages 81
7
7. Modélisation du contexte 82
Chapitre 5 : Capture des besoins fonctionnels 84

1. Identification des cas d‟utilisation 85
2. Description détaillée des cas d‟utilisation 93
3. Identification des classes candidates 108
Chapitre 6 : Capture des besoins techniques 113

1. Capture des spécifications techniques : Configuration matérielle 114
1.1. Architecture 3 tiers 114
1.2. Architecture de l‟application web 115
1.3. Déploiement 118
2. Capture des spécifications logicielles 119
2.1. Identification des exploitants du système 119
2.2. Les cas d‟utilisation techniques 120
Chapitre 7 : Analyse 121

1. Découpage en catégories 122
1.1. Répartition des classes candidates en catégories 122
1.2. Elaboration des diagrammes de classes préliminaires par catégorie 123
1.3. Elaboration du diagramme de packages (catégories) 126
2. Développement du modèle statique 126
3. Développement du modèle dynamique 127
3.1. Formaliser les scénarios 128
3.2. Construction des diagrammes d‟état-transition 134
Chapitre 8 : Conception 136

1. Conception générique 137
1.1. Elaboration du modèle logique de conception technique 137
2. Conception préliminaire 138
2.1. Développement du modèle de déploiement 139
2.2. Développement du modèle d‟exploitation 140
3. Conception détaillée 140
3.1. Concevoir les classes et les attributs 141
3.2. Concevoir les opérations 145
3.3. Passage au modèle relationnel 148
8
Chapitre 9 : Réalisation du prototype 150
1. Introduction 151
2. Présentation des outils utilisés 151
2.1. Apache http Server 2.2.11 151
2.2. Langage PHP 5.3.0 152
2.3. La base de données MySQL 5.1.36 153
3. Sécurité du système 153
3.1. Facteurs de risque et mesures de sécurité 154
3.2. Qualités sécuritaires du nouveau système 156
4. Présentation du prototype réalisé 158
Conclusion générale 170

1. Conclusion 170
2. Perspectives 171
Bibliographie 173
Webographie 175
Annexes 176
1. Diagrammes de séquences 176
2. Description des noyaux 178
3. Diagramme des classes des bases de données des bibliothèques 181
4. Exemples d‟adaptateurs 183
5. Le dublin Core 184
9
Liste des figures :
Figure 1 : Exemple de base de données réparties 39

Figure 2 : Les deux méthodes de conception d‟une B.D.R 42
Figure 3 : Architecture DARPA I3 45
Figure 4 : L‟approche Global As View 48
Figure 5 : L‟approche Local As View 48
Figure 6 : Le système d‟information soumis à deux types de contraintes 54
Figure 7 : Le processus de développement en Y 55
Figure 8 : Diagramme de classe du schéma global 61
Figure 9 : Architecture de notre système, inspirée de la médiation. 64
Figure 10 : Classification des fonctionnalités par ordre de priorité 78
Figure 11 : Les fonctionnalités du système en paquets 79
Figure 12 : Diagramme du cas d‟utilisation « S‟authentifier » 86
Figure 13 : Diagramme des cas d‟utilisation du paquet « Gestion des adhésions » 87
Figure 14 : Diagramme des CU du paquet « PEB en ligne » 88
Figure 15 : Diagramme des CU du paquet « Monitoring et suivi » 90
Figure 16 : Diagramme des CU du paquet « Espaces personnels » 91
Figure 17 : Diagramme des CU du paquet « Diffusions » 92
Figure 18 : Diagramme d‟activité du CU « S‟authentifier » 94
Figure 19 : Diagramme d‟activité du CU « Gérer les bibliothèques » 95
Figure 20 : Diagramme d‟activité du CU « Gérer les bibliothécaires » 96
Figure 21 : Diagramme d‟activité du CU « Gérer les adhérents PEB » 97
Figure 22 : Diagramme d‟activité du CU « Rechercher une ressource » 98
Figure 23 : Diagramme d‟activité du CU « Réserver une ressource » 99
Figure 24 : Diagramme d‟activité du CU « Annuler une réservation » 100
Figure 25 : Diagramme d‟activité du CU « Prolonger un emprunt » 101
Figure 26 : Diagramme d‟activité du CU « Enregistrer un prêt » 102
Figure 27 : Diagramme d‟activité du CU « Restituer un prêt » 103
Figure 28 : Diagramme d‟activité du CU « Enregistrer une transition de ressource » 104
Figure 29 : Diagramme d‟activité du CU « Gérer les adaptateurs » 105
Figure 30 : Diagramme d‟activité du CU « Gérer la liste noire » 106
Figure 31 : Diagramme d‟activité du CU « Gérer son panier » 107
Figure 32 : Diagramme d‟activité du CU « Consulter sa boite de réception » 108
Figure 33 : Diagramme des classes participantes du CU « S‟authentifier » 109
Figure 34 : Diagramme des classes participantes du paquet « Gestion des adhésions » 109
Figure 35 : Diagramme des classes participantes du paquet « PEB en ligne » 110
Figure 36 : Diagramme des classes participantes du paquet « Monitoring et suivi » 111
Figure 37 : Diagramme des classes participantes du paquet « Espaces personnels» 112
10
Figure 38 : Diagramme des classes participantes du paquet « Diffusions » 112
Figure 39 : La répartition des différentes couches de l‟architecture 3-tiers 115
Figure 40 : Schéma des composants matériels du nouveau système 117
Figure 41 : Configuration matérielle du système 119
Figure 42 : Représentation graphique d‟une catégorie 122
Figure 43 : Schéma représentatif des catégories de classe candidate 123
Figure 44 : Diagramme des classes de la catégorie « Utilisateur » 123
Figure 45 : Diagramme des classes de la catégorie « Prêt » 124
Figure 46 : Diagramme des classes de la catégorie « Bibliothèque » 125
Figure 47 : Diagramme des classes de la catégorie « Service » 125
Figure 48 : Diagramme de packages d‟analyse. 126
Figure 49 : Diagramme de classes 127
Figure 50 : Diagramme de séquence du CU « Rechercher une ressource » 129
Figure 51 : Diagramme de séquence du CU « Réserver une ressource » 130
Figure 52 : Diagramme de séquence du CU « Enregistrer un prêt » 131
Figure 53 : Diagramme de séquence du CU « Restituer un prêt » 132
Figure 54 : Diagramme de séquence du CU « Gérer les adaptateurs » 133
Figure 55 : Diagramme d‟état-transition de la classe « Réservation_prêt » 134
Figure 56 : Organisation du modèle logique de notre système 138
Figure 57 : Modèle de déploiement du système 139
Figure 58 : Identification des composants métier du système 140
Figure 59 : Page d‟accueil du site web 159
Figure 60 : Recherche simple 160
Figure 61 : Résultats d‟une recherche de ressource 161
Figure 62 : Espace visiteur « Fiche descriptive d‟une notice bibliographique » 162
Figure 63 : Espace adhérent « Fiche descriptive d‟une notice bibliographique » 162
Figure 64: Demande de prêt PEB 163
Figure 65 : Page d‟accueil après authentification de l‟administrateur 163
Figure 66 : Espace Administrateur 164
Figure 67 : Espace Administrateur « Gestion des bibliothèques » 164
Figure 68 : Espace Administrateur « Gestion des bibliothécaires » 165
Figure 69 : Espace Administrateur « Gestion des adhérents du PEB » 165
Figure 70 : Page d‟accueil après authentification du bibliothécaire 166
Figure 71 : Espace Bibliothécaire 166
Figure 72 : Espace Bibliothécaire « Liste des réservations d‟un adhérent » 167
Figure 73 : Espace Bibliothécaire « Enregistrer un prêt » 167
Figure 74 : Espace Bibliothécaire « Liste des prêts en cours d‟un adhérent » 168
Figure 75 : Espace Bibliothécaire « enregistrer une entrée de ressource » 168
Figure 76 : Espace Bibliothécaire « enregistrer une sortie de ressource » 169
11
Figure 77 : Diagramme de séquence du CU « S‟authentifier » 176
Figure 78 : Diagramme de séquence du CU « Gérer les bibliothèques» 177
Figure 79 : Diagramme de séquence du CU « Enregistrer une transition de ressource » 178
Figure 80 : Diagramme de classes du noyau « Présentation » 179
Figure 81 : Diagramme de classes du noyau « Applicatif » 179
Figure 82 : Diagramme de classes du noyau « Sécurité » 180
Figure 83 : Diagramme de classes du noyau « Accès aux données » 180
Figure 84 : Diagramme de classes du noyau « Authentification » 180
Figure 85 : Diagramme des classes « base de données BIB_1 » 181
Figure 86 : Diagramme des classes « base de données BIB_2 » 182
Liste des tableaux :
Tableau 1 : Comparaison de l‟approche objet et l‟approche fonctionnelle 51

Tableau 2 : Modélisation du contexte de l‟application 82
Tableau 3 : Liste des cas d‟utilisation du paquet « Gestion des adhésions » 86
Tableau 4 : Liste des cas d‟utilisation du paquet « PEB en ligne » 87
Tableau 5 : Liste des cas d‟utilisation du paquet « Monitoring et suivi » 89
Tableau 6 : Liste des cas d‟utilisation du paquet « Espaces personnels » 91
Tableau 7 : Liste des cas d‟utilisation du paquet « Diffusions » 92
Tableau 8 : Description détaillée des classes d‟objets 141
Tableau 9 : Liste et description des opérations 146
Tableau 10 : Les attributs du Dublin Core 186
12
Introduction
Générale
13
Introduction générale
Introduction générale :
1. Contexte :
On assiste depuis quelques années à l‟émergence de nouvelles applications qui ont

besoin de partager des informations entre différents systèmes. . C‟est le cas entre autre, du
« e-Gouvernement », du « e-Learning », du « e-Commerce », de la bioinformatique et du prêt
entre bibliothèque.
Le prêt entre bibliothèques est lié à l‟impossibilité pour une bibliothèque de posséder
l‟intégralité des ressources documentaires correspondant à ses missions. De là découle
l‟absolue nécessité d‟intégrer dans son plan de fonctionnement et de développement un
important volet de coopération pour devenir « une bibliothèque universelle », qui ne conserve
et ne communique plus seulement les collections qu‟elle acquiert, mais qui donne la
possibilité à ses lecteurs de profiter du fond documentaire des autres bibliothèques. Ceci lui
permet d‟augmenter considérablement la gamme des ressources disponibles aux utilisateurs.
Le regroupement en réseaux et la constitution des catalogues collectifs, ont conduit au

développement important de cette activité entre les bibliothèques universitaires.
2. Problématique :
Dans ce contexte, les systèmes d‟informations des bibliothèques, conçus et développés

par des organisations différentes, constituent généralement des sources de données autonomes
et hétérogènes. L‟hétérogénéité est non seulement due aux différents formats de structuration
des systèmes d‟information mais également aux multiples interprétations que des systèmes
autonomes peuvent avoir de la même donnée. De ce fait, l‟interopérabilité entre ces systèmes
d‟information est complexe puisque les applications doivent être adaptées pour pouvoir
déterminer, pour chaque requête, les sources de données pertinentes, la syntaxe requise pour
l‟interrogation, la terminologie propre à la source.
3. Objectifs :
Dans le cadre de ce mémoire, nous nous sommes fixés comme objectifs l'élaboration
d'une solution informatique permettant à un groupe de bibliothèques de faire bénéficier leurs
adhérents du service de « prêt entre bibliothèques ».
14
Il s‟agit d‟une application web offrant une interface de recherche unique, homogénéisée
et adaptable en ligne à travers le fond documentaire collectif des bibliothèques où les
adhérents du PEB peuvent rechercher en ligne une ressource et découvrir sa fiche descriptive,
vérifier sa disponibilité, procéder à une réservation… . Elle permet aussi la gestion du prêt par
les bibliothécaires : Les prêts et restitutions, les transitions de ressources entre bibliothèque…
Cette application devra s‟adapter pour permettre aux bibliothèques d‟inter-opérer. Elle
sera basée sur une approche d‟intégration virtuelle des sources de données hétérogènes,
autonomes et réparties qui est la « Médiation ».
Nous visons aussi une automatisation maximale, c'est-à-dire que la plupart des
procédures de gestion du prêt seront automatisées (traitement automatique des réservations de
ressources).
4. Organisation du mémoire :
Afin d‟atteindre les objectifs sollicités auparavant, nous avons organisé ce mémoire en deux
parties :
Partie 1 : Etat de l‟art
Cette partie constitue l‟aspect théorique du mémoire. Elle inclut 2 chapitres :
Chapitre 1 : Il est consacré à des généralités sur le service de prêt entre bibliothèque. On
verra des aspects théoriques concernant le PEB, les catalogues collectifs et les répertoires de
bibliothèques, on abordera aussi quelques systèmes existants pour s‟acquitter du service de
prêt entre bibliothèques.
Chapitre 2 : Vu que notre système va interagir avec des bibliothèques distantes et autonomes
dotées de systèmes de gestion différents, il s‟avère indispensable de connaître quelques
notions sur les bases de données réparties. On présentera aussi l‟approche de médiation, en
commençant par ces caractéristiques et types jusqu'à son architecture et son processus.
Partie 2 : Conception et mise en œuvre
Cette partie représente l‟aspect pratique du mémoire. Nous présenterons en premier la

méthode d‟analyse et de conception adopté, puis vont se succéder les chapitres suivants :
15
Chapitre 3 : Ce chapitre est consacré à la présentation générale de la solution proposée. A

savoir, l‟architecture inspirée de la médiation, les composants de cette méthode et son
fonctionnement.
Chapitre 4 : Ce chapitre constitue une étude préliminaire du système à réaliser. Nous allons
déterminer les besoins fonctionnels et opérationnels, identifier les acteurs qui interagiront
avec le système, puis nous allons développer un premier modèle UML de niveau contexte.
Chapitre 5 : Ce chapitre traite du rôle que tient UML pour compléter la capture des besoins
fonctionnels ébauchée durant l‟étude préliminaire par la technique des cas d‟utilisation. Nous
allons ensuite préparer l‟analyse orientée objet en identifiant les classes candidates du modèle
statique d‟analyse.
Chapitre 6 : Dans ce chapitre nous arrivons à la capture des spécifications techniques liées à
la configuration matérielle : le modèle logique de l‟architecture applicative, les composants de
l‟application web. Puis nous aborderons la capture des spécifications logicielles dans laquelle
nous identifierons les cas d‟utilisation techniques.
Chapitre 7 : Dans ce chapitre nous analysons le système, nous procèderons à un découpage
en catégories des classes participantes, au développement du modèle statique et celui du
modèle dynamique.
Chapitre 8 : Nous arrivons dans ce chapitre à la conception du système qui inclut : La
conception générique qui développe le squelette technique du projet, la conception
préliminaire qui effectue la fusion des études fonctionnelles et techniques, et la conception
détaillée vient construire et documenter précisément les classes et les méthodes qui
constituent le codage de la solution.
Chapitre 9 : C‟est la réalisation de notre application web. On fait appel à un ensemble d‟outils
et langages de développement. Ensuite nous décrirons les mécanismes utilisés pour sécuriser
le système contre d‟éventuelles menaces. Et enfin, nous utiliserons des prises d‟écrans pour
illustrer les principales fonctionnalités offertes par le système.
Et enfin nous terminerons par une conclusion générale, qui résume l‟apport essentiel de
notre travail, qui tente de s‟ouvrir sur de nouveaux éléments de réflexions et propose quelques
perspectives de recherche. Deux annexes sont ajoutées à la fin pour éclaircir les notions non
approfondies dans les chapitres.
16
Partie 1 :
Etat de l‟art
17
Chapitre 1:
Le prêt entre bibliothèques
18
Chapitre 1 : Le prêt entre bibliothèques
1. Introduction :
Le prêt entre bibliothèques (PEB) est lié à l'impossibilité pour un établissement donné
de posséder l'intégralité des ressources documentaires correspondant à ses missions. Ce
constat, vrai de tout temps, est devenu d'une particulière acuité depuis que l'explosion des
publications de tous types a répondu une stagnation des budgets documentaires.
A cet accroissement des ressources heureusement correspond un accroissement de leur

signalement et de leur localisation. Les catalogues collectifs sur fiches, si utiles qu'ils puissent
l‟être, sont désormais révolus, et la mise à disposition de catalogues en ligne semble prendre
la relève.
Le PEB est rendu possible grâce à deux outils :
- les catalogues collectifs qui signalent, pour chaque bibliothèque concernée, leurs
collections de documents et leurs conditions d'accès (prêt du document, consultation
sur place, photocopie...);
- et les répertoires de bibliothèques qui identifient celles-ci et présentent leurs

collections et services.
Dans ce présent chapitre, on verra des aspects théoriques concernant le PEB, les
catalogues collectifs et les répertoires de bibliothèques, on abordera aussi quelques systèmes
existants pour s‟acquitter du service de prêt entre bibliothèques.
2. Définition :
Le Prêt Entre Bibliothèques désigne un système d‟échange des documents qui permet à
chaque bibliothèque de donner accès à ses lecteurs à des documents qu‟elle ne possède pas en
propre. [FEN, 08]
Jambert Sandrine [JAM, 98] le définit comme suit : « Le Prêt entre bibliothèques ou
PEB est un processus par lequel un organisme documentaire obtient d'un autre un document
demandé par ses usagers et non disponible dans son fonds. Le PEB témoigne de la nécessité
pour les organismes documentaires de coopérer pour faciliter l'accès à tous à la
documentation. Quels que soient les crédits d'acquisition, aucune bibliothèque ne peut
19
prétendre aujourd'hui à l'autosuffisance et proposer au niveau local l'exhaustivité des

collections. Le système de PEB permet donc à une bibliothèque de se procurer un document
qu'elle ne possède pas. Le regroupement en réseaux, les systèmes de messagerie et la
constitution des catalogues collectifs, ont conduit au développement important de cette
activité entre les bibliothèques universitaires. »
3. Gestion de la demande de prêt :

3.1. Les acteurs : [DES, 05]
IL existe trois principaux éléments qui permettent l‟organisation et la gestion du PEB. :
A. Le demandeur :
L‟identification du demandeur ainsi que la collecte d‟information au sujet de ce dernier

sont nécessaires pour le traitement de sa demande (adresse d'envoi des documents, adresse et
service de facturation…).
L'inscription directe des utilisateurs finaux est une solution rarement pratiquée dans le
cadre du prêt entre bibliothèques. Ce dernier fonctionne généralement sur deux niveaux :
chaque demandeur est inscrit dans une bibliothèque, qui elle-même fait partie d'un réseau, et
assure l'intermédiaire entre les deux : vérification de la demande avant son envoi, vérification
du document demandé à son arrivée comme à son renvoi, relances, facturation…
L‟autorisation d'émission directe dans le système de demandes émanant d'usagers

enregistrés dans une des bibliothèques-membres est une solution rarement acceptée sans
réticence par les professionnels.
Dans le cas où c‟est l‟usager final qui émet ses propres demandes de prêt, le paiement
par avance est d‟usage, sous forme de « bons » correspondant à des tranches de photocopies,
etc. Dans le cas où ce sont des institutions, sont souvent mis en place, pour éviter la gestion
fastidieuse de facturations interinstitutionnelles, des systèmes de compensation entre les
établissements qui, la plupart du temps, sont à la fois demandeurs et fournisseurs de
documents.
Il est à noter que l‟envoi d‟un document sous forme originale par le biais du prêt entre
bibliothèques n‟oblige pas forcément l‟établissement demandeur de prêter à l‟extérieur de
20
l‟établissement : soit parce que la bibliothèque prêteuse s‟y oppose, soit parce que la
bibliothèque demandeuse ne le souhaite pas.
B. Le document :
Le principe du prêt entre bibliothèques veut qu'une demande de document se fasse vers
une bibliothèque où le document recherché a été précisément localisé.
Cependant, dans la mesure où les catalogues en ligne ne sont pas encore totalement
exhaustifs des fonds conservés dans les bibliothèques, on peut adresser une demande
concernant un document non parce qu'il a été localisé dans la bibliothèque sollicitée, mais
parce que les probabilités qu'il s'y trouve (sujet du document, type de document…) sont fortes
en prenant en compte la nature des fonds de la bibliothèque concernée, ses domaines
d‟excellence, etc. On notera que, s'agissant de documents récents, la probabilité devient plus
faible, puisqu'un document récemment acquis doit de facto faire l'objet d'une notice
informatisée dans le catalogue consulté.
Pour le bon fonctionnement du PEB, il importe que le document demandé soit

précisément décrit (date d'édition, support, numéro et pagination pour un article de revue,
etc.). C'est pour cette raison que, dans la majorité des cas, les bibliothécaires sont réticents à
l'utilisation directe du système par le lecteur, pas forcément conscient de toutes ces contraintes
qui, pourtant, conditionnent absolument la qualité du service fourni.
C. Le fournisseur :
A chaque demande de document correspond un ou plusieurs fournisseurs potentiels,

qu'on peut privilégier en prenant en compte différents critères : politique de prêt, délais de
fourniture du document, durée du prêt du document dans le cas d'un document original, mode
de fourniture du document (envoi postal, fax, fichier électronique...), proximité géographique,
proximité institutionnelle (même statut que la bibliothèque demandeuse, ce qui peut faciliter
les transactions notamment financières), accords spécifiques entre la bibliothèque
demandeuse et la bibliothèque sollicitée, coûts et modalités de facturation ; etc.
Devant l'afflux de demandes, certaines bibliothèques très sollicitées ont mis en place des
systèmes de quotas : dans ces établissements, on ne traite qu'une certaine quantité de
demandes par jour ; cet élément peut être un critère de sélection de la bibliothèque.
21
3.2. Les outils : [DES, 05]
La demande de prêt doit prendre une forme écrite. Si la transmission par voie postale ou
par fax reste possible, elle est de plus en plus délaissée au profit du courrier électronique, ou
d‟outils gérant l‟émission et la transmission des demandes à l‟aide de protocoles propriétaires.
Pour autant, ce qui définit un réseau de prêt entre bibliothèques d'un point de vue
technique, c'est avant tout l'utilisation d'un logiciel spécifique pour le traitement et la
transmission des demandes.
Dans la majorité des cas, ce logiciel s'appuie sur la mise en place d‟outils de gestion des
utilisateurs (pour n‟autoriser l‟accès qu‟aux seuls utilisateurs habilités ou inscrits), de
formulaires de saisie de la demande, d'outils de sélection des bibliothèques prêteuses
(permettant de les classer selon un ordre préférentiel spécifique à la bibliothèque
demandeuse), de gestion de la demande (comme la relance automatique de la demande, la
retransmission de la demande en cas de réponse négative), de gestion des statistiques et de la
facturation, etc. Il s'agit donc d'une gestion type base de données (identification des éléments
de la demande, fichiers de fournisseurs et de clients…), et d'une gestion d'échanges de
données.
Pour cette dernière fonction, une normalisation a été mise au point dans le cadre de
l'Organisation Internationale de Normalisation, l'ISO : les normes ILL (Interlibrary Lending).
Il est à souhaiter qu'on se soucie de l'intégration entre ce corpus de normes et la norme ISO-
239.50 (mieux connue sous le nom de Z39.50), qui devrait permettre la normalisation des
échanges de données d'exemplaire entre systèmes informatiques distincts, éléments de base du
prêt entre bibliothèques.
Dans le souci d'intégration poussée des différentes fonctions, les outils de prêt entre
bibliothèques sont de plus en plus le prolongement automatisé et l'aboutissement d'une
recherche documentaire : l'usager qui, par exemple par le biais d'un catalogue collectif, aura
réussi à identifier dans un autre établissement un document qui l'intéresse peut, à partir des
éléments collectés et sans besoin de ressaisie, établir une demande de prêt entre bibliothèques
qui, ensuite peut être soit automatiquement transmise à la bibliothèque identifiée, soit traitée
et validée par la bibliothèque auprès de laquelle l'usager est inscrit avant envoi.
22
Il est très important aussi de pouvoir suivre la demande de prêt dans toutes ces étapes :
accord de la bibliothèque demandeuse, état de traitement de la demande, envoi du document,
etc. Selon les cas, c‟est la bibliothèque emprunteuse qui sera avertie sinon ce sera directement
l‟usager.
4. Transmission du document : [DES, 05]

4.1. Support de transmission :
Selon les cas, le document sera transmis sur son support d'origine (électronique ou
matériel) ou reproduit. La reproduction concerne les documents dont la bibliothèque prêteuse
ne veut pas ou ne peut pas se défaire sous leur forme originale (documents rares, précieux ou
fragiles ; volumes de périodiques, etc.).
Le support de substitution le plus couramment utilisé jusqu'à présent reste la

photocopie, même si le développement des techniques de numérisation va sans doute rendre
ce type d‟envoi quelque peu archaïque. Les documents microcopiés (microfilm ou
microfiche) sont peu appréciés des usagers, car ils supposent l'utilisation d'un matériel
spécifique et empêchent le prêt à domicile du document.
Là encore, il est évident que, à terme et au moins pour les documents les moins
volumineux, la transmission par voie électronique de documents sera bientôt la règle : soit que
le document d'origine soit d'emblée sous forme électronique, soit qu'on le numérise en
utilisant des équipements que leur généralisation rend de moins en moins coûteux et de plus
en plus performants.
4.2. Mode de Transmission :
Le mode de transmission des documents varie bien sûr suivant la nature du support
utilisé : généralement, la voie postale est privilégiée pour les documents sous forme imprimée
ou autre, tandis que l'utilisation du réseau internet s'impose pour les documents sous forme
électronique, même si l‟envoi par fax reste possible.
23
5. Tarification et statistiques : [DES, 05]
Dans la majorité des systèmes de prêt où le fournisseur est unique face au demandeur, le
paiement à l'avance, soit sous forme de dépôt préalable, soit par l'achat de "coupons" ouvrant
droit à la fourniture d'un certain nombre de documents, est la règle.
L'utilisation du prêt entre bibliothèques permet la mise en œuvre d'une solution plus
souple et plus originale, le clearing house : dans ce système, semblable au système de
compensation entre établissements bancaires, chaque bibliothèque participante est, à l'égard
de chacune des autres bibliothèques membres du réseau de prêt, à la fois créditrice et
débitrice. A intervalles fixes, on fait le compte des lignes de crédit et des lignes de débit :
selon qu'elle est excédentaire (le coût des documents fournis est supérieur à celui des
documents reçus) ou déficitaire, la bibliothèque se fera soit créditée, soit devra payer le
montant du déficit à l'administration coordinatrice du réseau.
On peut noter que ce système ne suppose pas forcément l'existence d'un organisme
régulateur c'est-à-dire que des accords de gré à gré entre établissements (sous réserve de leur
faisabilité comptable) peuvent aussi bien être envisagés.
6. Services : [DES, 05]

6.1. Impala :
Impala (Instant Mailing Procedure for Automated Lending Activities) est le principal
système de prêt entre bibliothèques belges. Créé en 1991, il prend en charge la gestion
automatisée des demandes et des réponses de PEB entre bibliothèques. Impala est un système
ouvert : il n'est pas nécessaire d'être membre d'IMPALA pour bénéficier de ses services, de
même que les bibliothèques-membres peuvent adresser leurs demandes à des bibliothèques
extérieures au réseau. Impala peut être utilisé à partir de quatre catalogues collectifs.
6.2. Subito :
Issu d'une initiative du Ministère allemand de l'éducation et de la recherche et des

Länder eux-mêmes, Subito est un impressionnant système de prêt entre bibliothèques basé sur
l'utilisation de certains des outils bibliographiques collectifs. Par ce biais, 1 million de titres
24
de revues, 20 millions de livres sont accessibles, sans oublier une base d'articles de
périodiques qui permet la recherche dans plus de 20.000 périodiques postérieurs à 1992.
L'une des particularités de Subito est qu'il accepte aussi bien l'inscription de particuliers
que d'institutions, à des conditions bien évidemment différentes. De même, différents modes
d'accès sont possibles selon les besoins en matière de PEB : fourniture de copies d'articles
uniquement, documents originaux, etc. De même, les formats de fourniture des documents
sont extrêmement variés, avec une prééminence de plus en plus importante de la fourniture
directement par voie électronique.
Subito est un système fédérateur et souple, qui s'appuie largement sur les systèmes
existants de fourniture des documents, en apportant des "plus", comme la possibilité pour
l'utilisateur de centraliser par le biais de Subito le paiement de demandes faites auprès de
prestataires différents. En quelque sorte, Subito combine les avantages d'un système centralisé
de fourniture, tel que l'INIST (l'Institut national de l'information scientifique et technique) ou
le BLDSC (British Library Document Supply Centre), et ceux d'un système décentralisé,
comme le réseau des bibliothèques du SUDOC (Le Système universitaire de documentation).
6.3. Catalogue Collectif Suisse :
Le Catalogue Collectif Suisse (CCS) coordonne le prêt entre bibliothèques en Suisse

avec divers groupes de travail et réseaux. Il comprend le catalogue collectif des monographies
et le catalogue collectif des publications en série (RP). Il offre ses services à toutes les
bibliothèques suisses et aux centres d'information et de documentation suisses.
Le catalogue collectif des monographies est un catalogue sur fiches entièrement

microfilmé qui répertorie les publications étrangères ainsi que les publications suisses
antérieures à 1900 annoncées par les bibliothèques du réseau suisse du prêt entre
bibliothèques. Comme la plupart des catalogues de bibliothèques suisses sont consultables en
ligne, le Catalogue collectif des monographies a arrêté l'alimentation du catalogue au début de
2003.
Le Catalogue collectif suisse est la plaque tournante du prêt entre bibliothèques. Les
bibliothèques suisses peuvent adresser leurs demandes de prêt entre bibliothèques au CCS, qui
localise les publications recherchées dans les bibliothèques suisses et fournit une vérification
25
bibliographique si nécessaire. Sur demande, le CCS indique également une adresse de

commande à l‟étranger pour des ouvrages non disponibles en Suisse. Les particuliers doivent
s‟adresser au CCS par l‟intermédiaire d‟une bibliothèque.
Depuis avril 2003, le Réseau des bibliothèques de Suisse occidentale (RERO) propose à
ses usagers un système de prêt entre bibliothèques. Moins d‟un an après son ouverture, ce
système aura traité 70.000 demandes émanant tant des bibliothèques membres du réseau (une
centaine pour le PEB) que de 190 institutions étrangères. Les usagers inscrits dans l‟une des
bibliothèques membres du réseau peuvent l‟utiliser directement
6.4. LinkUK :
LinkUK regroupe près de 80 bibliothèques de Londres et du sud-ouest de l‟Angleterre

pour la prise en charge du prêt entre bibliothèques de ces établissements. Basée sur
l‟utilisation du Web, l‟application donne accès à près de 5 millions de documents pour 40
millions d‟exemplaires, et contient entre autres l‟ensemble de la bibliographie nationale
anglaise depuis 1950, les collections du British Library Document Supply Centre (BLDSC),
et bien sûr les collections des bibliothèques participantes au réseau. Près de 120.000 demande
sont gérées par an.
7. Les répertoires de bibliothèques :
Les bibliothèques ont toujours coopéré pour dresser leur propre inventaire. L'arrivée
d'Internet puis du Web a bouleversé les modes de production et de diffusion de ces
recensements. Bon nombre d'entre eux sont désormais et exclusivement disponibles en ligne,
ce qui permet tout à la fois d'utiliser ces outils, souvent complexes d'utilisation, pour des
recherches très ponctuelles, et d'être assuré de mises à jour régulières.
S'il est relativement facile d'identifier une bibliothèque par le biais des nombreux
répertoires disponibles, il est beaucoup plus difficile de savoir ce qu'elles possèdent, et encore
plus aléatoire d'espérer sélectionner une bibliothèque non par ses spécialités ou par sa
localisation géographique, mais par l'intérêt de ses collections par rapport à ses objectifs de
recherche.
Parmi les nombreux répertoires célèbres existants à travers le monde on cite :
26
 Libweb (Library www servers) recense plus de 7000 sites de bibliothèques dans 125
pays. il ne recense que les bibliothèques présentes sur la Toile. C'est aussi le cas d'un
répertoire comparable, Libdex : the Library index, qui recense tout de même près de
18.000 bibliothèques.
 Bien que s'intéressant majoritairement aux bibliothèques des Etats-Unis, Lib-web-cats

recense un nombre non déterminé de bibliothèques du monde entier. Un certain
nombre d'informations pratiques sur chaque établissement est complété par des liens
avec les sites des bibliothèques concernées. Des recherches par type de bibliothèque,
ou par institution, sont aussi possibles. The WWW library directory, d'une consultation
moins aisée, recense quant à lui 8800 bibliothèques de 130 pays.
 The WWW virtual library n'est pas à proprement parler un répertoire de bibliothèques
sur le Web mais, dans son souci de proposer aux internautes, par le biais du bénévolat,
des ressources de tous types et sur tous sujets, il comporte aussi d'intéressantes listes
d'établissements, comme par exemple l'important Libraries and library resources for
chinese studies, qui s'intéresse tout à la fois aux bibliothèques occidentales
s'intéressant à l'Orient et aux bibliothèques d'Asie du Sud-Est en général, mais ne
semble plus mis à jours depuis décembre 2001.
 L'UNESCO propose l'UNESCO Libraries portal, un annuaire en ligne de

bibliothèques du monde entier (près de 12.000 bibliothèques sont ainsi répertoriées).
S'il n'a pas la prétention d'être exhaustif, cet annuaire a l'avantage de proposer une
courte description des bibliothèques sélectionnées, ainsi que la possibilité de faire des
recherches thématiques. Par contre, il se limite aux bibliothèques disposant elles-
mêmes d'un accès par le Web.
Cependant, il existe tout aussi bien des répertoire spécialisés par type d‟établissement
comme par exemple le site de l'IFLA (International Federation of Library Associations) qui
en offre un certain nombre, comme celui consacré aux bibliothèques nationales (National
libraries of the world : Address list) qui ne propose malheureusement que des informations
extrêmement succinctes sur chaque bibliothèque répertoriée.
27
8. Les catalogues collectifs :
Un catalogue collectif est un catalogue commun à plusieurs bibliothèques. D'une

manière très schématique, les avantages principaux d'un catalogue collectif ressortent des
missions principales d'un établissement [DES, 05].
Un catalogue collectif sert à :
- Localiser : rares sont les bibliothèques pouvant acquérir l'ensemble de la

documentation disponible dans leur domaine de compétence. Dès lors, il importe de
pouvoir trouver dans un autre établissement le document que demande un usager.
- Prêter : cette fonction découle logiquement de la précédente. Nombreux catalogues

collectifs possèdent une fonction de prêt de documents entre les bibliothèques
membres. Le système doit permettre la gestion de la demande, de son émission à son
exécution, de sa facturation à la réalisation de statistiques.
- Cataloguer : l'informatisation très large des catalogues et des tâches de catalogage,

ainsi que la normalisation poussée des pratiques en la matière, permettent d'envisager
un partage des ressources des établissements. La fourniture de notices
bibliographiques n'est pas l'apanage des catalogues collectifs : elle reste, quand elle est
pratiquée, une de leurs principales fonctions.
- Partager : outil d'identification de ce que possède, ou de ce qu'envisage de posséder,

les autres bibliothèques participantes, le catalogue collectif est ou devrait être un outil
fondamental d'aide à la coordination des acquisitions, mais aussi du désherbage et de
la conservation des collections.
- Identifier : la richesse de certains catalogues fait qu'ils peuvent de facto constituer

une base bibliographique nationale ou spécialisée, d'autant plus que la qualité du
catalogue, exigée par le travail collectif, assure aux documents recensés une
description souvent très détaillée.
28
8.1. Avantages et inconvénients des catalogues collectifs : [DES, 05]
A. Avantages :
Si les bibliothèques semblent être condamnées à collaborer, les avantages d'un

catalogue collectif restent indéniables pour certaines fonctions de l'établissement.
La localisation des documents dans un outil collectif permet de dynamiser le prêt ou la

consultation. Cet avantage était décisif quand les bibliothèques n'avaient pas la possibilité de
diffuser leur propre catalogue autrement que sur leur site physique (catalogue sur fiches); il
l'est moins depuis que les catalogues en ligne sont disponibles.
L'argument de réduction des coûts de catalogage, et de l'utilisation d'un catalogue

collectif pour la mise en œuvre d'opérations de conversion rétrospective ¹ garde aussi tout son
intérêt : dans ce cas, le catalogue collectif est, aussi un « réservoir bibliographique », c‟est-à-
dire une base de notices essentiellement bibliographiques qui permet à l‟établissement
membre d‟utiliser des notices déjà créées par d‟autres (ou importées par les responsables du
catalogue collectif à cette fin), diminuant ainsi les importants coûts liés à la gestion du
catalogage dans l‟établissement.
B. Inconvénients :
Partant du principe de collectivité et de partage, le catalogue collectif implique le

respect de règles communes. Cela constitue, souvent, plus un inconvénient qu‟un avantage.
Bon nombre d'établissements y voient une perte d'autonomie, et la contrainte de règles

parfois inadaptées au fonctionnement local - soit trop détaillées, soit trop peu détaillées. Ce
dernier inconvénient, cependant, n'en devient un que quand la cohérence du catalogue
collectif ne répond pas aux critères typologiques qu‟on verra ci-dessous.
¹ La conversion rétrospective est l'opération qui permet de convertir sous forme exploitable par
ordinateur, dans un format standard, un ensemble de notices bibliographiques de documents déjà
catalogués manuellement ou informatiquement dans un autre format [WEB_01].
29
8.2. Typologie des catalogues collectifs : [DES, 05]
En s‟intéressant au contenu du catalogue collectif, quatre critères principaux permettent

d‟en définir le type :
- Type de support ou type de document : catalogue consacré à un seul type de support ou de

document (publications en série, microfiches, thèses, documents en ligne…)
- Domaine : les thèmes traités dans les documents recensés, que ceux-ci soient géographiques (tous
les documents sur un pays ou dans une langue donnée), historiques (tous les documents ou certains
documents d'une époque donnée) ou proprement thématiques (sujets abordés).
- Emprise géographique : il s'agit là de l'aire géographique des institutions impliquées dans

la constitution du catalogue collectif. On distinguera ainsi les catalogues collectifs propres à
une localisation (campus), à un lieu (ville, département, région…) à un pays, ou à plusieurs
pays.
- Type d'institution : bon nombre de catalogues collectifs se construisent sur l'identité

institutionnelle des bibliothèques qui le constituent : bibliothèques dépendant d'un même
organisme essentiellement, que ce soit un ministère, une municipalité, une région, une
entreprise... .
Cela dit, la combinaison des ces critères entraine l‟apparition d‟une diversité de types distincts
de catalogues collectifs.
8.3. Exemples de catalogues collectifs : [DES, 05]
A. OCLC (Online computer library center):
OCLC (Online Computer Library Center) est fondé en 1967 pour le partage de la
gestion de certaines ressources bibliothéconomiques et de réduire les coûts de
fonctionnement, c‟est sans doute la plus grande organisation collective en matière de gestion
de bibliothèques au monde. L'étendue de ses activités excède très largement le strict cadre des
catalogues collectifs, même si on ne peut qu'évoquer ces autres activités.
30
Worldcat
Le cœur du système reste néanmoins constitué par WorldCat, énorme base de données
bibliographiques dont le simple énoncé chiffré donne le vertige : 57 millions de notices
bibliographiques, près de 965 millions de localisations, pour plus de 53.000 bibliothèques
connectées dans près de 90 pays différents. Couvrant 4000 ans d'histoire écrite, la base inclut
des notices de documents dans 400 langues différentes.
Une nouvelle notice est créée dans Worldcat toutes les dix secondes. Par delà la
diversité des pratiques et des langues, Worldcat obéit à un ensemble relativement rigoureux
de règles : l'application des normes américaines de catalogage (AACR2000), l'utilisation d'un
format proche du format MARC21 américain, la présence de vedettes-matières et auteurs
issues des listes de la Bibliothèque du Congrès.
Différentes interfaces de catalogage sont disponibles pour accéder à la base, et la

modifier. On notera enfin que se trouvent inclus dans Worldcat les notices créées par les
bibliothèques membres du réseau CONSER (Cooperative online serials). CONSER est un
programme spécifique de coopération entre bibliothèques pour la création et la gestion des
notices de publications en série, en lien avec le réseau de l'ISSN qu‟on abordera plus en détail
par la suite.
Prêt entre bibliothèques
Introduit en 1979, le prêt entre bibliothèques membres du réseau OCLC concerne

aujourd'hui près de 7000 bibliothèques - soit malgré tout moins de 14 % du réseau potentiel.
OCLC a développé un logiciel spécifique, Illiad, pour la gestion de leurs transactions de prêt
entre bibliothèques.
Autres services
OCLC, dans le souci de diversifier ses activités (et ses revenus), a multiplié les services
aux bibliothèques, dans le souci notamment de valoriser Worldcat.
L'organisation propose ainsi la sous-traitance d'opérations de conversion rétrospective,

la fourniture de notices bibliographiques en même temps que les documents commandés, la
gestion des acquisitions dans certaines langues ou écritures (chinois, arabe…), etc.
31
Le service FirstSearch, créé en 1991 et utilisé par 20.000 bibliothèques, propose quant à
lui l'accès à plus de 70 bases de données différentes, soit de dépouillement, soit de textes
intégraux, représentant plus de dix millions de références Dans le même domaine, Netlibrary
propose l'accès à près de 40.000 livres électroniques.
Enfin, OCLC a racheté la gestion de la classification décimale de Dewey ¹, qu'il propose

sous forme de volumes imprimés et de base de données en ligne.
Bien évidemment, rien de ce qui concerne les métadonnées (OCLC est à l‟origine
du « Dublin Core Initiative ») et la documentation électronique n‟est étranger à OCLC, qui a
développé un nombre important de programmes dans ces domaines. Soucieux d'agrandir son
influence, OCLC a racheté le consortium PICA².
B. RLG :
Fondé en 1974, le Research Libraries Group (RLG) a été conçu dès l'abord comme un
outil de mise en commun de ressources de bibliothèques universitaires, nationales,
historiques, possédant des collections utiles à la recherche. Organisation sans but lucratif,
RLG regroupe aujourd'hui environ 150 établissements. Par l'intermédiaire de différentes
interfaces, RLG donne accès à des millions de notices bibliographiques et autres. On peut y
trouver entre autres l'accès à des bases de données de dépouillement, à des archives, voire à
des documents primaires sous forme numérisée.
RLG Union Catalog
L'essentiel cependant est constitué par le RLG Union Catalog, qui inclut plus de 130 millions
de notices bibliographiques et près de 10 millions de notices d'autorités. En fait, ce catalogue
est lui-même un agrégat de catalogues : CURL Union catalogue, English Short Title
Catalogue, Hand Press Book database… .
¹ La classification décimale de Dewey (CDD) est un système visant à classer l'ensemble du savoir
humain à l'intérieur d'une bibliothèque, développé par Melvil Dewey en 1876.
² le consortium PICA, fondé en 1969, est le principal organisme de coopération entre les
bibliothèques néerlandaises. Il est devenu OCLC PICA en 2002.
32
On y trouve aussi les catalogues de certaines bibliothèques nationales (Deutsche Bibliothek

Database, National Library of Australia Catalogue). Près de 50 % des documents décrits ne
sont pas en anglais, 4 millions correspondent à des documents antérieurs à 1900, et près de
400 langues différentes sont représentées. Près de 3 millions de notices sont rédigées dans les
écritures autres que l‟alphabet latin.
Le RLG Union Catalog proprement dit est cependant le cœur du système, avec 45
millions de notices recensées. Constitué de 8 fichiers distincts par type de documents, mais
pouvant être interrogés d'une manière unique; archives, monographies, cartes, enregistrements
sonores, publications en série,...
Interrogeable par différentes interfaces, utilisant notamment le standard Z39.50, ce

catalogue comporte des fonctionnalités très avancées, entre autres la possibilité d'interroger et
de consulter des notices en caractères natifs de documents publiés dans des écritures
alphabétiques ou autres (chinois, arabe, cyrillique, hébreu, japonais…).
Prêt entre bibliothèques
Le RLG a développé l‟outil ILL Manager, logiciel client spécialisé dans les transactions
de prêt entre bibliothèques. L‟outil ARIEL dont il est question dans la partie spécifique
consacrée au prêt entre bibliothèques est la version commercialisée de ce produit, il permet de
gérer entièrement, par l'intermédiaire d'un poste client, une demande de prêt entre
bibliothèques et l'envoi du document sous forme scannée ou numérisée. Bien sûr, les
bibliothèques demandeuse et prêteuse doivent être équipées du même logiciel pour que
l'ensemble puisse fonctionner.
Autres services
Le RLG propose l‟accès à une vingtaine de bases de données dans les disciplines les
plus diverses, mais relevant essentiellement des sciences humaines : droit, sciences sociales,
histoire, art et architecture, anthropologie, archéologie…
Le RLG a depuis ses débuts été perçu comme une sorte de "rival" d'OCLC, dont il
partage largement les ambitions. Mais, là où OCLC s'est développé dans une optique
mondiale, tant en termes de pays que de types d'établissements, le RLG a constamment
préservé ces missions de départ, privilégiant un nombre restreint de prestigieux et riches (en
33
collections comme en budgets) établissements universitaires ou de recherche, comme on

témoigne le petit nombre des membres.
C. ISSN:
Si les deux catalogues ci-dessous concernent le recensement de tous types de

documents, le catalogue collectif de l'ISSN (pour International standard serial number) ne
recense quant à lui "que" des notices de publications en série - dont on sait combien elles sont
complexes à élaborer, et coûteuses à gérer.
En effet, si la notice bibliographique d'une monographie peut être considérée comme

établie une fois pour toutes, il n'en est pas de même de celles des publications en série. De par
leur nature, les publications en série sont amenées, un jour ou l'autre, à disparaître, ce qui
implique au moins une modification de leur notice descriptive. De plus, ce type de documents
est sujet à de fréquentes évolutions, qu'il faut prendre en compte dans le catalogage :
changement de titre, de périodicité, d'éditeur, de format, absorption d'autres titres, fusion,
scission, etc. Ces modifications conduisent aussi à la gestion de l'historique d'une publication
en série, à travers ses divers avatars.
Créé en 1976, le réseau ISSN, coordonné par le Centre international de l'ISSN (hébergé
par la France) avait pour but de coordonner la description de ces ressources complexes, en
attribuant à chacune d'entre elles (c'est-à-dire à l'ensemble des fascicules partageant des
caractéristiques communes définissant une publication en série) un numéro unique et un titre-
clé, éléments univoques d'identification de chaque publication en série, qui puisse être utilisé
tout à la fois dans un cadre bibliographique et dans un cadre commercial.
Vingt-cinq ans plus tard, cette ambition de départ a été parfaitement remplie. L'ISSN,
utilisé dans la fabrication des codes-barres qui régissent désormais la distribution des
publications dans les grands réseaux de distribution, est aussi le numéro d'identification de
publications en série le plus répandu et le plus fiable dans les grands outils bibliographiques.
La base de données de l'ISSN, connue sous le nom de Registre de l'ISSN, contient plus
de 1,125.000 notices de publication en série. Elle est disponible en ligne, sur abonnement, et
via un CD-ROM édité une fois par an. Environ 50.000 notices nouvelles sont ajoutées tous les
34
ans, et près de 60.000 corrections et modifications sont effectuées sur les notices déjà
présentes dans le Registre.
La base de l'ISSN est bien le fruit d'un travail collaboratif, et en tant que tel a bien sa
place dans notre recensement : la collecte des notices s'appuie sur un réseau de 75 centres
nationaux à compétence géographique, généralement hébergés (quand elles existent) par les
bibliothèques nationales des pays concernés.
Ces centres ont la charge de recenser l'ensemble des publications en série de leur zone
de compétence et de leur attribuer un numéro d'ISSN. Le centre international se chargeant
quant à lui d'assurer la cohérence de la base, par le chargement des mises à jour régulières des
centres nationaux, et du recensement des publications internationales.
La particularité majeure du projet ISSN est sa vocation rétrospective. Si on attribue

systématiquement des numéros ISSN aux nouvelles publications, on en attribue aussi
(virtuellement) aux publications disparues, de façon à gérer au mieux l'identification des
filiations évoquées plus haut. De ce fait, et contrairement au programme ISBN, le Registre de
l'ISSN a vocation, au moins théoriquement, à assurer à terme l'identification exhaustive de
l'ensemble des publications en série éditées dans le monde, depuis les débuts jusqu'à nos
jours.
9. Conclusion :
Bien que le prêt entre bibliothèques est une pratique plus que centenaire, son avenir
sous une forme coopérative, surtout quand celle-ci suppose l'existence d'un puissant (donc
coûteux) organisme fédérateur semble être incertain. En effet le renforcement du secteur
privé, le développement de solutions "one to one", ne laissent pas forcément augurer un grand
avenir au prêt entre bibliothèques sous une forme collective.
De plus, l‟arrivée du document électronique a totalement bouleversé le paysage du PEB,

où la fourniture d‟articles de périodiques sous forme de photocopies représente une grande
majorité des transactions. Désormais, les revues sont accessibles en ligne, et les bibliothèques
développent des systèmes d‟information qui permettent à l‟utilisateur final un accès
transparent à ces ressources, pour lesquelles le prêt entre bibliothèques est de moins en moins
nécessaire : d‟autant moins nécessaire que, si l‟on peut objecter que les collections de revues
35
accessibles à distance sont limitées à quelques années de publication, il ne faut pas oublier
que ce sont justement les articles les plus récemment parus qui représentent la majorité des
transactions.
Un tel transfert de technologies, de compétences et de produits semble bien significatif

de l'avenir incertain du prêt entre bibliothèques. Ce constat est pourtant paradoxal, à l'image
de celui fait pour les catalogues collectifs. La dématérialisation rapide des collections, en tout
cas celles qui font l'essentiel du prêt entre bibliothèques, devrait au contraire être une
opportunité majeure de développement d'un service tout entier basé sur l'échange, et la
normalisation des échanges, sur le partage et sur l'intérêt bien compris de chacun à participer à
un réseau. Seul l'avenir dira, cependant, si ce modèle économique est réellement viable face à
la concurrence de l'offre privée.
Enfin, la numérisation en masse d‟ouvrages fait craindre, là encore, une baisse de plus
en plus marquée de l‟activité de PEB : seul l‟avenir dira si une activité qui, dans ses
modalités, a encore recours à des circuits de transmission traditionnels, pourra se pérenniser –
sans qu‟il soit raisonnable de tabler sur son expansion.
Les catalogues collectifs, quant à eux, réduisaient les coûts liés au traitement des
documents, en permettant une meilleure maîtrise des politiques d'acquisition et de
conservation.
Aujourd'hui, où le problème des coûts est plus que jamais à l'ordre du jour face à
l'inflation documentaire, les outils collectifs sont malgré tout remis en cause dans la plupart
des pays. Cette évolution semble pour le moins paradoxale : la mise en place d'Internet et
l'adoption de ses standards favorise plus que jamais l'échange aisé de données ; les réseaux
physiques sur lesquels il s'appuie permettent la mise en œuvre rapide et sans grandes
contraintes de réseaux documentaires étendus, et qui ne sont plus ni temporellement ni
géographiquement limités.
36
Chapitre 2:
Bases de données réparties
et médiation
37
Chapitre 2 : Bases de données réparties et médiation
1. Introduction :
Depuis les débuts de l‟informatique, l‟approche dominante à la gestion de données dans

l‟entreprise a été centralisée et jusqu‟au début des années 1980, le coût élevé des ordinateurs
faisait de cette approche la seule solution économiquement viable. Ce contexte a par ailleurs
favorisé la notion de base de données qui tend à centraliser la définition et l‟administration
des données. Plus récemment, les développements remarquables de domaines aussi divers que
les réseaux de communication, les mini et micro-ordinateurs, et les bases de données
relationnelles ont permis à l‟approche base de données répartie de devenir une solution
alternative à la centralisation [GAR, 91].
D‟autre part, l‟accès transparent aux ressources et de manière plus générale à

l‟information constitue un des challenges actuels majeurs de l‟informatique. L‟avènement du
Web et des réseaux informatiques tout comme l‟accroissement des données et des services
produits font que les utilisateurs finaux se trouvent confrontés à des problèmes de localisation
et d‟accès à l‟information pertinente qu‟ils requièrent. L‟hétérogénéité, la quantité, la
dispersion des ressources constituent autant de verrous que les systèmes d‟intégration doivent
lever. Une des solutions pratiques d‟intégration de données est la médiation.
Dans la suite de ce chapitre nous nous étalerons sur les caractéristiques des bases de
données réparties ainsi que sur la gestion des données distribuées. On abordera aussi
l‟approche de médiation, en commençant par ces caractéristiques et types jusqu'à son
architecture et son processus.
2. Bases de Données Reparties (BDDR) :
2.1. Définition : [GAR, 91]
Une BDD repartie (BDDR) est une base de données logique dont les données sont
stockées sur de différents sites, généralement géographiquement distants, et vues comme un
tout. Ces parités de données réunies forment la BDDR gérée par un SGBD reparti (SGBDR).
Il est à noter que ces sites sont considérés comme égaux (pas de site central) et
bénéficient d‟une autonomie locale.
38
Site 1
Site 4
BDD 4
Réseau
Site 5
d’interconnexion
Site 3
BDD 5
Site 2
BDD 3
BDD 2
Figure 1 : Exemple de base de données répartie
1.2. Buts et objectifs de la répartition :

1.2.1. Buts de la répartition des bases de données ;
Les bases de données réparties ont une architecture plus adaptée à l‟organisation des
entreprises décentralisées [MOU, 07].
- Plus de fiabilité : les BDDR sont souvent répliquées. La panne d‟un site n‟est pas très
importante pour l‟utilisateur, qui s‟adressera à autre site.
- Meilleures performances : réduire le trafic sur le réseau est une possibilité
d‟accroître les performances. Le but de la répartition des données est de les rapprocher
de l‟endroit où elles sont accédées. Répartir une base de données sur plusieurs sites
permet de répartir la charge sur les processeurs et sur les entrées/ sorties.
- Faciliter l’accroissement : l‟accroissement se fait par l‟ajout de machines sur le

réseau.
1.2.2. Objectifs définis par C.J. Date : [DAT, 87]
Les objectifs les plus importants que définit Date sont :
39
1. Autonomie de chaque site : chaque site est responsable de l‟intégrité de ses données, sa
propre sécurité et sa gestion interne. Chaque site doit rester fonctionnel même s‟il ne peut
pas communiquer avec les autres sites (en cas de panne réseau par exemple).
2. Absence de site privilégié : l‟objectif est la décentralisation de l‟information afin d‟éviter
les goulots d‟étranglement.
3. Continuité de service : le système réparti doit être tolérant aux pannes, c'est-à-dire que la
défaillance d‟un site particulier, n‟affecte pas le bon fonctionnement de tout le système.
4. Transparence vis à vis de la localisation des données : les utilisateurs ne connaissent pas le
schéma d‟allocation des données.
5. Transparence vis à vis de la fragmentation : les utilisateurs ne connaissent pas le schéma
de fragmentation des données.
6. Transparence vis à vis de la réplication : les utilisateurs ne connaissent pas si les données
sont répliquées ou pas.
7. Traitement des requêtes distribuées : le support de requêtes distribuées est essentiel, ainsi
que des méthodes d‟optimisation des exécutions de requêtes en milieu réparti.
8. Traitement des transactions distribuées : des méthodes d‟exécutions de transactions en
milieu réparti doivent être garanties.
9. Indépendance vis à vis du matériel : s‟exécute sur différentes architectures matérielles.
10. Indépendance vis à vis du système d‟exploitation : la base de données répartie doit être
indépendante du système d‟exploitation utilisé dans les différents sites.
11. Indépendance vis à vis du réseau : utiliser un protocole réseau permettant de s‟affranchir
des différents types de réseaux.
12. Indépendance vis à vis du logiciel : un système interopérable du point de vue logiciel
possède des interfaces de communication avec d‟autres logiciels.
1.3. Approche de conception d’une BDD repartie : [GAR, 91], [MOU, 07],
[WEB_02]
Il y‟en a deux approches. Si on démarre à partir d‟une BDD centralisée on adoptera

l‟approche descendante mais si au contraire on veut construire une BDD repartie par
agrégation de BDD déjà existantes alors il s‟agira de l‟approche ascendante.
40
1.3.1. L’approche descendante (top down design) :
L‟approche top down est assez peu fréquente et est intéressante quand on part du néant.
Elle n‟est pas forcément utilisée à cause de la répartition géographique mais aussi dans le cas
où on recherche de la performance, c'est-à-dire, lorsqu‟on veut minimiser le temps de
transfert, le nombre de transferts entre les sites, le temps moyen de traitements des requêtes et
le volume de données transférées….
Dans cette approche, on commence par définir le schéma conceptuel global de la base
de données repartie puis on distribue sur les différents sites en des schémas conceptuels
locaux. La répartition se fait donc en deux étapes, en première étape la fragmentation et en
deuxième étape l‟allocation de ces fragments aux sites.
Cette méthode voit son intérêt dans la création de nouvelles bases de données.
Aux niveaux conceptuel et externe la BDD repartie est perçue comme une BDD
centralisée donc le concept de répartition réside dans le niveau interne.
1.3.2. L’approche ascendante (bottom up design) :
L‟approche se base sur le fait que la répartition est déjà faite, mais il faut réussir à
intégrer les différentes BDD existantes ayant des SGBD différents en une seule BDD globale.
En d‟autres termes, les schémas conceptuels locaux existent et il faut réussir à les unifier dans
un schéma conceptuel global.
Donc la conception ascendante, il s‟agit de partir de l‟existant et intégrer les bases

locales dans le schéma global. Ces bases de données peuvent avoir le même modèle (par
exemple réseau) ou des modèle différents (par exemple relationnel et hiérarchique).
Au niveau conceptuel la BDD repartie est définie comme un ensemble de BDD entre
lesquelles peuvent être définies des associations et divers contraintes d‟intégrités, à ce niveau
la localisation des BDD reste inconnue.
Au niveau externe, les vues peuvent faire apparaître ou non la multiplicité des BDD,
selon le souhait de l‟utilisateur. Le niveau interne n‟autorise pas une allocation des données
aussi fine que dans l‟architecture précédente. En effet, les BDD locales étant existantes, seule
est permise la duplication de la totalité d‟une BDD.
41
Conception ascendante Conception descendante
BDD réparties BDD réparties
BDD BDD BDD BDD BDD BDD

locale 1 locale 2 locale 3 locale 1 locale 2 locale 3
Figure 2: Les deux méthodes de conception d‟une B.D.R [FER, 04]
2. Intégration de données : L’approche de médiation
On est souvent amenés à interroger plusieurs sources de données simultanément et de

combiner les résultats obtenus afin de fournir une information non disponible directement aux
utilisateurs du web. La diversité ainsi que l‟hétérogénéité des sources de données distribuées
rendent ces opérations plus complexes. C‟est donc pour cela qu‟un système d‟intégration de
données devient nécessaire.
L‟intégration de données permet aux utilisateurs d‟accéder à travers un schéma global

unifié à plusieurs sources de données autonomes, distribuées et sous forme hétérogène, ayant
chacune un schéma local. L'utilisateur aura alors l'illusion qu'il interroge une seule et unique
source.
Il existe plusieurs méthodes pour l‟intégration de données. On cite l‟approche d‟entrepôt

de données, la méthode P2P et la médiation.
Dans l‟approche de médiation, les sources de données sont encapsulées par un

adaptateur spécifique permettant de pallier l‟hétérogénéité et les limitations des différentes
bases donnant ainsi l‟impression qu‟il n‟existe qu‟une seule source de données et une unique
interface donnant lieu à une réponse utilisateur sous format unique. Les requêtes utilisateurs
sont faites dans un langage unique et leurs traitements sont partagés entre le médiateur et
l‟adaptateur.
42
Le premier, le médiateur est chargé de répondre à des besoins à partir de connaissances

mises à sa disposition. Le médiateur permet de localiser l‟information et de résoudre les
conflits d‟hétérogénéité de données du point de vue sémantique et schématique.
Le second, appelé adaptateur ou Wrapper, sert d‟interface avec les SI composants. Le

Wrapper résout les conflits syntaxiques en présentant les données disparates dans le modèle
globale de médiation.
Médiateur : Un médiateur est défini par [WIE, 92] comme suit : Un médiateur est un
logiciel qui constitue une interface utilisateur permettant l‟accès à différentes ressources de
manière transparente, et ce malgré leurs hétérogénéité et répartition. Pour ce faire, le
médiateur utilise des métadonnées (connaissances) utile pour les divers services.
Il a pour rôle de:
1. Fournir un accès transparent aux données en donnant à l‟utilisateur l‟impression

d‟interroger un système centralisé et homogène.
2. Traiter les requêtes utilisateur en :
- localisant les sources de données pertinentes.
- décomposant les requêtes en sous-requêtes adaptées à chaque source.
- envoyant les requêtes aux sources concernées.
- construisant la réponse finale à partir des réponses partielles des sources.
3. Résoudre les conflits structurels et/ou sémantiques entre les données des différentes
sources.
Globalement un médiateur offre un accès direct aux sources et se caractérise par : [VOD, 03]
- approche "paresseuse", pas de matérialisation.

- migration de requêtes vers les sources.
- avantages: cohérence, données réelles.
- inconvénients: performances, traduction de requêtes, capacités des sources.
Pour accéder aux bases de données locales, le médiateur fait appel à des Wrappers.
43
Wrapper : Un Wrapper de données est un logiciel qui convertit les requêtes exprimées dans
le modèle de médiation provenant d‟un ou de plusieurs médiateurs vers le modèle des bases
de données locales. Il convertit les données, résultats d‟une requête, du modèle des bases de
données locales vers le modèle de médiation. Un Wrapper de données offre une interface
homogène locale d‟accès aux données sources (présentation des données dans le format
syntaxique de la médiation et donc résolution des conflits syntaxiques).
Langage de médiation : le médiateur adopte un langage unique appelé langage de

médiation pour permettre aux différents utilisateurs et applications d‟interroger les différentes
sources de données de la coopération de manière uniforme en leur masquant les détails
d‟hétérogénéité et de localisation. Un standard de langage de médiation est proposé par
[BUN, 97].
3.1. Architecture de médiation de base
Le concept de médiateur dans le domaine des systèmes d'information est apparu pour intégrer
1
des sources d'informations hétérogènes. "Gio Wiederhold" a proposé une architecture
logicielle à trois niveaux et a défini un médiateur de la façon suivante: "un médiateur est un
module logiciel qui exploite la connaissance de certains ensembles ou sous-ensembles de
données pour créer de l'information pour des applications à un niveau supérieur " [GIO, 92].
Cette architecture, qui s'est largement imposée dans les systèmes d'information, repose sur les
trois couches suivantes: sources, médiateurs et clients.
1
Gio Wiederhold : Professeur émérite d'informatique de l'Université Stanford. Sa recherche concerne
principalement la conception de larges systèmes d'information, leur évolution et la protection de leur
contenu.
44
Niveau Application Application Application Interaction

cliente cliente cliente
client
Facilitateur Facilitateur Coordination
Niveau
médiation
Médiateur Médiateur Intégration
Adaptateur Adaptateur Adaptateur Traduction
Niveau Source de Source de Source de

données données données Accès
sources
1
Figure 3 : Architecture « DARPA I3 »
1. Le niveau sources : comporte les différentes sources de données ; à l'aide d'un

adaptateur, il est capable de communiquer avec les médiateurs et facilitateurs du niveau
supérieur, en leur fournissant une vue homogène de la source à laquelle il est associé. Un
adaptateur accepte une requête donnée dans le langage commun du médiateur, la transcrit
dans le langage natif de la source et exécute la requête. Le résultat de la requête transmis sous
forme native est alors transformé suivant le modèle de données global du médiateur et
renvoyé à celui-ci.
Il est à noter qu‟un facilitateur est un outil chargé à la fois de localiser les données pertinentes
et de les mettre en forme pour les applications.
1
DARPA I3 : Une architecture générique des solutions de médiation conçue par l‟ARPA (Advanced
Research Projects Agency) du département de la défense américaine1. Cette architecture baptisée I3
(Intelligent Integration of Information) est proposée par Gio Wiederhold.
45
2. Le niveau médiateur : comporte des médiateurs permettant d'intégrer les données en

provenance de différentes sources afin de répondre aux requêtes des utilisateurs. Ce module
joue un rôle actif dans la couche entre les applications utilisateurs et les sources de données.
Son rôle est de fournir à la couche supérieure une vue centralisée des sources qui sont
hétérogènes et distribuées.
On trouve aussi à ce niveau des facilitateurs permettant d'identifier les sources qui peuvent
être des sources de données ou des médiateurs, et de composer les réponses pour les
utilisateurs.
3. Le niveau clients : comporte les applications clientes (navigateurs, programmes

d'application, interface graphique).
L'intégration d'une nouvelle source se résume à développer un adaptateur pour cette

dernière et le rendre accessible par le médiateur [CLU, 98].
Un langage de requête commun ainsi qu'un modèle de données commun entre les
facilitateurs, le médiateur et les adaptateurs doivent être définis pour toute l'architecture. Le
rôle d'un adaptateur consiste essentiellement à permettre la traduction du langage de requête
commun vers le langage natif de la source qu'il gère, et la traduction du modèle de donnée de
la source en modèle de données commun.
Les sources de données accessibles peuvent être très différentes: certaines sont des
SGBD relationnelles, d'autres des SGBD objets, certains encore sont des systèmes de fichiers
ou des pages Web et d'autres des moteurs de recherche ou encore même des médiateurs.
Ces disparités doivent être prises en compte dans le développement de l'adaptateur

spécifique, mais cela n'est pas toujours évident. En effet, certaines sources (par exemple un
moteur de recherche ou une page Web) offrent des capacités limitées d'interrogation (par
rapport à un SGBD relationnel par exemple). Le médiateur doit pouvoir en tenir compte.
Ensuite, la répartition des sources sur un réseau à l'échelle de l'Internet entraîne
l'accroissement de situations d'indisponibilité des sources dus à des problèmes de
communication ou de serveurs inaccessibles.
3.2. Types de médiation :
46
A. Médiation de schéma :
La médiation de schéma associe au médiateur un ensemble de connaissances qui

localisent et intègrent les informations pertinentes à un contexte d‟utilisation. Les requêtes
sont exécutées sur ces connaissances (préétablies) qui indiquent au médiateur la localisation
physique des données et les correspondances entre les données pour permettre leur
combinaison et transformation afin de restituer des résultats homogènes et exploitables. La
notion de contexte est ici implicite puisqu‟il n‟y a aucune information supplémentaire sur la
source de données locale qui renseigne sur la sémantique des données. Le traitement des
requêtes se fait alors de manière statique. L‟aspect dynamique du médiateur se retrouve dans
sa capacité de gérer la disparition des sources de données incomplètes et de s‟adapter aux
capacités d‟interrogation différentes de chaque site. La médiation de schéma est une extension
directe de l‟approche fédérée avec une meilleure extensibilité.
B. Médiation de contexte :
Cette approche repose sur une intégration dynamique des informations. Chaque
application et chaque source de données locale doivent exprimer leur domaine sous forme de
contexte d‟utilisation des informations et ce pour permettre au médiateur, lors du traitement
d‟une requête, de comparer le contexte de l‟application aux contextes des systèmes participant
à la coopération. Le médiateur est guidé alors par des informations à caractère sémantique
pour résoudre dynamiquement une requête sans connaissance préalable des systèmes
d‟informations participants.
3.3. Intégration de schéma
On peut classifier les systèmes d'intégration de données suivant la relation entre les schémas
des sources locales par rapport au schéma unifié global sur le médiateur. On distingue deux
types de système: un schéma global comme vue sur des schémas locaux GAV ou des vues
locales comme vues du schéma global LAV.
A. L’approche GAV
Elle est assez intuitive et consiste à définir le schéma global comme une vue sur les schémas
locaux. C‟est-à-dire que le schéma global est considéré comme étant une vue sur les schémas
des sources, pour cela les prédicats de ce schéma global, aussi appelés relations globales,
47
sont définis comme des vues sur les prédicats des schémas des sources à intégrer. Si la
conception du schéma dans l‟approche globale est assez simple ainsi que la construction des
résultats qui consiste à remplacer les prédicats du schéma global de la requête par leur
définition, l‟ajout d‟une nouvelle source peut obliger à reconcevoir le schéma global et donc à
reconsidérer l‟ensemble des sources. Ce problème représente une sérieuse limite de cette
approche lorsque le nombre de sources considérées est important.
Schéma global
GAV
Définition des vues
Source Source Source
Figure 4: L‟approche Global As View [ASS, 07]
B. L’approche LAV
Cette méthode consiste à procéder à l‟inverse de l‟approche AV, c‟est-à-dire à définir les
schémas locaux comme des vues sur le schéma global qui est défini indépendamment des
sources de données et supposé existant.
L‟avantage de l‟approche locale est que l‟ajout d‟une nouvelle source est très simple, puisque
cela n‟a aucun effet sur le schéma global, il s‟agit juste de définir une vue sur ce dernier. En
revanche, le traitement des requêtes et la construction des réponses sont complexes car des
algorithmes pour la réécriture de la requête et la recomposition des réponses s‟avèrent
incontournables.
Schéma global
Définition des vues Définition des vues Définition des vues

LAV
Source Source Source
Figure 5: L‟approche Local As View [ASS, 07]: 48

3.4. Processus de médiation :
Comme le suggère [REY, 00], les principales étapes du processus de médiation sont les
suivantes :
 une reformulation de la requête en sous-requêtes applicables aux sources,

 une optimisation du plan d'exécution (méthode d‟exécution de la requête), suivie de
l'exécution,
 et un regroupement des résultats.
Lors de la construction d‟un système médiateur, deux problèmes majeurs se posent et doivent
être résolus [ROU, 02] :
 Le choix du langage utilisé pour modéliser le schéma global, ainsi que le choix des
langages de représentation des vues sur les sources à intégrer et les requêtes des
utilisateurs.
 En fonction de ces choix de modélisation, la conception et la mise en œuvre
d‟algorithmes de réécriture de requêtes en termes de vues.
4. Conclusion :
Nous avons étudié dans ce présent chapitre les bases de donnés réparties ainsi que
l‟approche d‟intégration de données par la médiation. Les BDDR sont venues suite à
l‟évolution des bases de données décentralisées. Elles comptent plusieurs avantages, dont le
principal est sans doute le partage de données hétérogènes et distribuées géographiquement
sur différents sites. Cela dit, il existe certains reproches; on cite la complexité de conception et
un coût de mise en œuvre très important. Mais le problème le plus délicat reste celui de la
sécurité, de nature plus compliquée que celle d‟une base centralisée.
La médiation quant à elle, vise à offrir à l‟utilisateur une vue virtuelle homogène des
sources intégrées tout en gardant leurs autonomies locales. Les données n‟étant pas répliquées
dans une base de données globale, il en découle une absence d‟incidence de mise à jour des
données sur le système intégré. Cela permet d‟éviter le problème de maintenance des données.
Par contre, quelques inconvénients demeurent à citer. L‟accroissement des sources de
données, en nombre et en volume, pose principalement deux problèmes pour cette approche
à savoir la complexité de conception du schéma global et la difficulté d‟optimisation de la
réécriture des requêtes.
49
Partie 2 :
Conception
Et mise en œuvre
50
Méthode d‟analyse et de conception
Méthode d’analyse et de conception :
La conception d'un logiciel passe par l'emploi d'une méthode qui s'appuie sur un
langage de modélisation. La méthode de développement est une succession d'étapes qui
permettent de maîtriser le déroulement du projet et qui donnent aux utilisateurs une meilleure
visibilité de certains résultats produits et garantissent ainsi l‟inadéquation du résultat final.
Chaque étape de la méthode employée est ponctuée par la création d'un modèle du système
étudié. Un modèle est une représentation abstraite selon un certain formalisme de la réalité qui
exclut certains détails du monde réel.
Pour concevoir notre système, nous avons opté pour l‟approche objet et cela en raison de
plusieurs avantages :
 La stabilité de la modélisation par rapport aux entités du monde réel,

 La construction itérative facilitée par le couplage faible entre composants,
 La possibilité de réutiliser des éléments d‟un développement à un autre,
 La simplicité du modèle qui fait appel à seulement cinq concepts fondateurs (les objets, les
messages, les classes, la généralisation et le polymorphisme) pour exprimer d‟une manière
uniforme l‟analyse, la conception et la réalisation d‟une application informatique.
Pour justifier notre choix, nous présenterons ci-dessous une comparaison de l‟approche objet
et de l‟approche fonctionnelle.
Approche objet Approche fonctionnelle
- Rapproche les données et leurs - Privilégie les fonctions comme moyen

traitements associés au sein d‟un même d‟organisation du logiciel.
objet.
- Néglige le concept de l‟évolution des
- Vise à maitriser la production et logiciels dans le temps.
l‟évolution des logiciels.
Tableau 1 : Comparaison de l‟approche objet et l‟approche fonctionnelle
Dans le tableau ci-dessus, on voit bien une différence majeure entre les deux approches
qui est la prise en considération de l‟évolution des besoins des utilisateurs dans le temps. Pour
51
la première approche (approche objet), l‟évolution des besoins aura le plus souvent tendance à
se présenter comme un changement de l‟interaction des objets. S‟il faut apporter une
modification aux données, seul l‟objet incriminé sera modifié. Toutes les fonctions à modifier
sont bien identifiées : elles se trouvent dans ce même objet : ce sont ses méthodes.
Pour la deuxième approche (structurée ou fonctionnelle), l‟évolution des besoins

entraîne souvent une dégénérescence, ou une profonde remise en question de la
décomposition en fonctions. D‟autre part, une modification des données entraîne
généralement une modification d‟un nombre important de fonctions éparpillées et difficiles à
identifier dans la hiérarchie de la décomposition.
Comme la maîtrise de l‟évolution des besoins des utilisateurs est une préoccupation
majeure de n‟importe quel concepteur de logiciels, nous avons le souci de maintenir notre
système à long terme, ce qui justifie et explique le choix de l‟approche objet.
Pour ce faire nous avons choisi UML comme langage de modélisation et le processus
2TUP comme méthode de développement.
1. Le langage UML : [DIG, 01]
UML ou Unified Modeling Language, est un langage de modélisation qui est né au

milieu des années 90 de la fusion de trois méthodes objets: OMT (Object Modeling
Technique), BOOCH1 (GRADY BOOCH le concepteur de la méthode) et OOSE (Object
Oriented Software Engineering). L'idée de cette fusion est partie du constat qu'à l'époque ils
existaient plusieurs méthodes objets liées par un consensus autour d'idées communes: objets,
classes, sous-systèmes etc.
C'est à partir de 1997 que l'OMG2 (Object Management Group) qui standardise les
technologies de l'objet, s'est attachée à la définition d'un langage commun unique, utilisable
par toutes les méthodes objets dans toutes les phases du cycle de vie et compatible avec les
techniques de réalisation du moment. D'où la naissance d‟UML. UML offre des éléments
pour décrire les différents aspects d'un système: les diagrammes.
Ses points forts sont les suivants :
52
 C‟est un langage formel et normalisé : il permet un gain de précision, de stabilité et

encourage l‟utilisation d‟outils.
 C‟est un support de communication performant : il cadre l‟analyse et facilite la
compréhension de représentations abstraites complexes. De plus, son caractère
polyvalent et sa souplesse en font un langage universel.
Les diagrammes utilisés dans l'ensemble de notre analyse sont:
 Le diagramme des cas d'utilisation

 Le diagramme d‟activité
 Le diagramme de classes
 Le diagramme de package
 Le diagramme de séquences
 Le diagramme d‟état-transition
Pour établir les diagrammes, nous allons utiliser Visual Paradigm For UML (version7.0), qui
est un outil du professionnel UML qui soutient le cycle de vie complet de logiciel - analyse
orientée objectivement, conception orientée objectivement, construction, essai et déploiement.
Il permet de dessiner tous les types de diagrammes de classe, renverser le code, produire du
code des diagrammes et produire de la documentation [WEB_03]
UML n‟est, toutefois, qu‟un langage de modélisation et il doit être accompagné d‟un
processus qui devra guider la modélisation, étape par étape, jusqu‟à la réalisation.
2. Le processus 2TUP : [ROQ, 07]
Un processus définit une séquence d‟étapes, en partie ordonnées, qui concourent à

l‟obtention d‟un système logiciel ou à l‟évolution d‟un système existant. L‟objet d‟un
processus de développement est de produire des logiciels de qualité qui répondent aux besoins
de leurs utilisateurs dans des temps et des coûts prévisibles.
Le Processus Unifié :
C‟est une méthode de développement logiciel construite sur UML :
 itérative et incrémentale : la méthode est itérative dans le sens où elle propose de faire des
itérations lors de ses différentes phases, ceci garantit que le modèle construit à chaque
53
phase ou étape soit affiné et amélioré. Chaque itération peut servir aussi à ajouter de
nouveaux incréments.
 conduite par les cas d‟utilisation : elle est orientée utilisateur pour répondre aux besoins de
celui-ci.
 centrée sur l‟architecture : les modèles définis tout au long du processus de développement
vont contribuer à établir une architecture cohérente et solide.
 pilotée par les risques : en définissant des priorités pour chaque fonctionnalité, on peut
minimiser les risques d‟échec du projet.
Le processus 2TUP :
On dit de la méthode UP qu‟elle est générique c.à.d. qu‟elle définit un certain nombre
de critères de développement, que chaque société peut par la suite personnaliser afin de créer
son propre processus plus adapté à ses besoins.
C‟est dans ce cadre que la société Valtech a crée la méthode 2TUP. 2TUP signifie « 2
Track Unified Process» .C‟est un processus qui répond aux caractéristiques du Processus
Unifié. Le processus 2TUP apporte une réponse aux contraintes de changement continuel
imposées aux systèmes d‟information de l‟entreprise. En ce sens, il renforce le contrôle sur les
capacités d‟évolution et de correction de tels systèmes. « 2 Track» signifient littéralement que
le processus suit deux chemins. Il s‟agit des « chemins fonctionnels » et « d‟architecture
technique », qui correspondent aux deux axes de changement imposés au système
d‟information.
Figure 6 : Le système d‟information soumis à deux types de contraintes
La branche gauche (fonctionnelle) : Capitalise la connaissance du métier de l‟entreprise. Elle

constitue généralement un investissement pour le moyen et le long terme. Les fonctions du
système d‟information sont en effet indépendantes des technologies utilisées. Cette branche
comporte les étapes suivantes :
54
 La capture des besoins fonctionnels, qui produit un modèle des besoins focalisé sur le
métier des utilisateurs.
 L‟analyse.
La branche droite (architecture technique) : Capitalise un savoir-faire technique. Elle

constitue un investissement pour le court et moyen terme. Les techniques développées pour le
système peuvent l‟être en effet indépendamment des fonctions à réaliser. Cette branche
comporte les étapes suivantes :
 La capture des besoins techniques.

 La conception générique.
La branche du milieu : A l‟issue des évolutions du modèle fonctionnel et de l’architecture

technique, la réalisation du système consiste à fusionner les résultats des 2 branches. Cette
fusion conduit à l‟obtention d‟un processus en forme de Y. Cette branche comporte les étapes
suivantes :
 La conception préliminaire.
 La conception détaillée.
 Le codage.
 L‟intégration.
Figure 7: Le processus de développement en Y
55
Chapitre 3 :
Proposition de la solution
56
Chapitre 3 : Proposition de la solution
1. Présentation du projet à réaliser :
Un ensemble de bibliothèques distantes ont décidé de coopérer et de collaborer entre

elles dans le but de permettre à leurs lecteurs de profiter d‟un fond documentaire plus riche.
Il s‟agit d‟offrir un service de prêt inter bibliothèques. C'est-à-dire qu‟un lecteur d‟une
bibliothèque peut consulter et emprunter un ouvrage d‟une autre bibliothèque. Les
bibliothèques sont distantes et dotées de systèmes de gestion distincts.
Le travail à faire consiste à mettre sur pied ce service de prêt. Le système à réaliser
permettra la gestion du prêt interbibliothèques.
2. Proposition de la solution :
Dans les chapitres précédents nous avons présenté un état de l‟art sur le prêt
interbibliothèques et les systèmes existants, ainsi que sur les approches d‟intégration de
sources de données hétérogènes et distribuées. A priori, concevoir un système dans cette
même logique est l‟objectif de notre travail.
Notre travail consiste à réaliser un logiciel qui interagit avec plusieurs bibliothèques de
ressources documentaires pour gérer le prêt entre ces bibliothèques. Nous arrivons dans le
présent chapitre à la proposition de notre solution.
Nous proposons de réaliser une application web qui va regrouper les bibliothèques
participantes. C‟est un logiciel applicatif se manipule à l‟aide d'un navigateur web via un
réseau informatique internet.
La futur application permettra à l‟adhérent d‟une bibliothèque membre du réseau, de

rechercher un ouvrage dans le fond documentaire des bibliothèques, de consulter sa fiche
descriptive, vérifier sa disponibilité, le réserver, prolonger un emprunt, annuler une
réservation… etc. L‟internaute visiteur non adhérent pourra seulement faire la recherche et la
consultation des ressources.
Cette application permettra aussi la gestion du prêt inter bibliothèques par les gérants,
c'est-à-dire que toute la gestion du PEB se fait aussi à partir du site.
57
3. Besoins de l’application auprès des bibliothèques :
Notre application va exploiter les bases de données des systèmes de gestion des
bibliothèques (Voir annexe page 181) pour pouvoir faire fonctionner le service de prêt
interbibliothèques. Nous devons accéder avec transparence à ces bases sans causer des
incohérences ou anomalies dans les systèmes de gestion des bibliothèques. Pour cela nous
allons minimiser les mises à jour des données dans les bases locales des bibliothèques et nous
allons plutôt utiliser la base de données centrale celle de notre application web. Tout ce qui
concerne le prêt interbibliothèques sera sauvegarder dans la base du site, nous nous servons
principalement des bases locales des bibliothèques seulement pour lancer des recherches sur
les ressources documentaires et récupérer les résultats ou bien pour vérifier la disponibilité
des ressources.
3.1. En consultation :
1. La première chose à faire sur le site est de lancer une recherche de ressource selon des
critères choisis (titre, auteur, édition…). La recherche consiste à interroger simultanément
en temps réel et d‟une manière équitable les bases de données des bibliothèques.
2. Ensuite, nous devrons consulter aisément la fiche descriptive d‟une ressource
documentaire, choisie parmi les résultats, à partir de la base de données de sa bibliothèque
de possession.
3. Vérifier la disponibilité de la ressource localement chez la bibliothèque de possession,
c'est-à-dire l‟existence d‟exemplaire libre qui est ni réservé localement ni en prêt local.
3.2. En mise à jour :

Puisque les informations concernant le prêt interbibliothèques seront enregistrées dans
la base centrale, ce qui reste est de proposer une solution pour justifier l‟absence d‟un ouvrage
dans la base de données locale de la bibliothèque de possession lorsque ce dernier sera en prêt
PEB. Nous devons éviter la situation où le système de gestion de la bibliothèque indique
qu‟une ressource donnée est disponible pour le prêt (local) alors que celle-ci est absente en
raison du PEB.
Nous proposons de signaler l‟ouvrage comme étant « hors service » dans la base locale
de la bibliothèque de possession. Nous utilisons par exemple le champ de la base locale qui
58
décrit un exemplaire (en service, hors service, en réparation) et mettre l‟exemplaire en « hors
service » lorsqu‟il est en prêt PEB ou lorsqu‟il est réservé.
Nous allons procéder à cela de la même manière que le fait le système de gestion de la
base de données de la bibliothèque ainsi ce dernier ne sera pas en face d‟une incohérence ou
d‟une anomalie.
4. Propriétés du système :
Notre travail consiste à réaliser une application web qui permet la gestion du prêt
interbibliothèques (les réservations de ressources, les prêts et restitutions, les transitions de
ressources entre bibliothèques) et qui fédère plusieurs bibliothèques distantes indépendantes
dotées de systèmes de gestion différents.
Donc il s‟agit de concevoir un système interopérable dont les propriétés fondamentales

nécessaires sont :
 La distribution :
Parmi les données que manipule notre application les ressources bibliographiques qui
proviennent de plusieurs bibliothèques distantes et indépendantes. Chaque bibliothèque met
une partie de ses ressources à disposition de notre application.
Donc les bibliothèques doivent permettre à notre application un accès libre et à distance
à leurs bases de données pour pouvoir récupérer les informations et faire les mises à jour
nécessaires pour le déroulement du PEB.
 L’autonomie :
L‟autonomie locale vise à garder une administration locale séparée et indépendante pour
chaque bibliothèque participant à la fédération de bibliothèques. Une bibliothèque participant
à notre système interopérable doit fonctionner comme avant sa participation.
59
 L’hétérogénéité :
Chaque bibliothèque est dotée d‟une informatisation choisie et conçue indépendamment

des autres bibliothèques, des systèmes de gestion différents (hétérogénéité des schémas,
langages).
Les bibliothèques peuvent garder leurs outils préexistants. Notre application web va
s‟adapter à cette hétérogénéité et inter opérer avec les bibliothèques telles quelles sont sans
leur exiger de migrer vers un système de gestion précis ou utiliser des outils particuliers.
Une même fonctionnalité requise aux bibliothèques, par notre système, est exprimée
différemment pour chaque bibliothèque en s‟adaptant à son système de gestion.
5. Architecture de médiation :
Afin d‟exploiter au mieux les ressources des bibliothèques et permettre ainsi une
recherche efficace dans leur fond documentaire, notre système envisage un mécanisme qui
s‟occupera de l‟intégration de plusieurs entrepôts (bases de données des bibliothèques) ayant
une structure définie au préalable.
Nous avons opté, dans la solution proposée, pour l‟approche « Médiation », qui a été étudié
dans le chapitre 2 de l‟état de l‟art, pour les motifs suivants :
 La médiation est une approche souple et elle fournit le plus d‟autonomie aux
bibliothèques distantes.
 l‟absence d‟incidence de mise à jour des données sur le système intégré. Cela permet
d‟éviter le problème de maintenance des données. En effet la médiation permet de
construire un système d‟interrogation de sources de données sans toucher aux données
qui restent stockées dans leurs sources d‟origine.
 Transparence à la localisation des données pour les applications.
 Disponibilité accrue des données en cas de pannes des serveurs.
 Support de l‟hétérogénéité des sources.
L‟approche médiation est conçue pour intégrer des sources de données hétérogènes en
vue de lecture seulement. Nous allons proposer une solution qui est inspirée de l‟approche
« Médiation de schéma » et nous allons l‟étendre pour couvrir l‟écriture aussi.
60
Notre système personnalisé de médiation est fondé sur les composants suivants :
5.1. Schéma global :
La présence d‟un schéma global est nécessaire puisqu‟il fournit un vocabulaire unique
servant à exprimer les requêtes des utilisateurs. Ce schéma unifie les schémas hétérogènes des
bibliothèques à intégrer en se basant sur une description homogène, uniforme et abstraite du
contenu des sources par des vues.
Notre schéma global est constitué des vues qui vont contenir les résultats d‟une
recherche sur le site. C'est-à-dire les notices bibliographiques résultant d‟une recherche.
Nous allons construire le schéma global par l‟approche GAV (Global as View), c'est-à-
dire que le schéma global est considéré comme étant une vue sur les schémas des sources.
Nous proposons un format commun qui va décrire ces notices. Ce format est basé sur le
standard « Dublin Core » (Voir annexe page 184), nous allons utiliser un sous ensemble
d‟attributs de ce standard (titre, auteur, mots-clés, description, éditeur, date, type, format,
langage, identificateur).
Voici le modèle conceptuel des données des vues du schéma global :
Ressource Auteur
0..n Ecrite_par 1..1
Code_bibliothèque Nom_auteur
Code_ressource
Prénom_auteur
Titre
Edition
Date
Type
Langage
Format
Mots_cles
Description
Figure 8 : Modèle conceptuel du schéma global
61
5.2. Langage commun à base de méthodes :
C‟est le langage commun dans lequel le médiateur interrogera les adaptateurs. Les
requêtes des utilisateurs sont exprimées dans un langage commun qui est basé sur l‟appel de
méthodes d‟exécution de requêtes.
Nous définissons des méthodes génériques qui répondent aux besoins de notre application
auprès d‟une bibliothèque donnée :
- Connexion à une base de données d‟une bibliothèque : une méthode qui établit la
connexion entre notre application et la base de données de la bibliothèque.
- Recherche par titre : une méthode qui recherche une ressource selon un titre donné.
- Recherche par auteur : une méthode qui recherche des ressources écrites par un auteur
donné
- Recherche par édition : une méthode qui recherche les ressources éditées par une maison
d‟édition donnée
- Recherche par année : une méthode qui recherche les ressources éditées en une année
donnée
- Recherche des auteurs d‟une ressource : une méthode qui permet de récupérer les noms et
prénoms des auteurs qui ont écrit une ressource donnée.
- Vérification de disponibilité : une méthode qui vérifie la disponibilité d‟une ressource en
local.
- Exemplaire libre : une méthode qui permet de récupérer le code d‟un exemplaire libre
d‟une ressource donnée
- Signaler « hors service » : une méthode qui permet de rendre un exemplaire en état « hors
service ».
- Signaler « en service » : une méthode qui permet de remettre un exemplaire en « en
service ».
5.3. Médiateur :
Le médiateur est un composant logiciel qui s‟occupe de la distribution des sources de
données (bibliothèques). Pour bien répondre aux besoins du système, le médiateur doit :
- Accepter les requêtes des utilisateurs.

62
- Envoyer les plans d‟exécution à faire exécuter par les adaptateurs des différentes
bibliothèques.
- Recomposer les résultats des adaptateurs.
5.4. Adaptateur :
L‟adaptateur (Wrapper) cache l‟hétérogénéité au médiateur. Un adaptateur est associé à

une seule bibliothèque et joue le rôle d‟intermédiaire entre cette bibliothèque et le médiateur.
C‟est un “traducteur”.
- Traduction du langage de requête commun du médiateur en langage de requête natif

propre à la bibliothèque.
- Traduction des résultats natifs en résultats au format commun du médiateur.
L‟adaptateur est une méthode qui se charge d‟adapter une méthode générale selon le
langage et le schéma utilisés dans le système de gestion d‟une bibliothèque
Nous allons regrouper les déclarations des méthodes adaptatrices de chaque

bibliothèque dans un fichier spécifique propre à elle.
Les méthodes adaptatrices portent le même nom que la méthode générale qu‟ils
interprètent. Ainsi pour appeler une méthode adaptatrice propre à une bibliothèque, nous
utilisons le même nom général seulement nous devons précéder ceci par l‟inclusion du fichier
de configuration qui contient la déclaration des méthodes adaptatrices spécifiques à cette
bibliothèque. Voir annexe page 183.
Nous présentons ci-dessous la schématisation de notre solution.
63
Bibliothèque Bibliothèque Bibliothèque

1 2 3
BDD BDD BDD
SGBD SGBD SGBD
Adaptateur Adaptateur Adaptateur
Médiateur
Applications
Base de données
PEB
Figure 9 : Architecture de notre système, inspirée de la médiation.
64
6. Fonctionnement de la médiation :
6.1. Recherche fédérée de ressources :

La recherche fédérée consiste à interroger plusieurs entrepôts de ressources
documentaires hétérogènes distants et présentant les résultats dans une interface unique,
homogénéisée et adaptable. On devra donner l‟impression d‟interroger une bibliothèque
unique en présentant une interface de recherche commune et en regroupant les résultats
obtenus après l‟exécution de chacune des requêtes propres aux bibliothèques.
Exemple : Considérons la requête de reche
rche simple suivante: « Quelles sont les ressources documentaires dont le nom de l‟auteur est
"Carnegie" ? »
Notre système de médiation dans le cas de cette requête fonctionnera selon l‟algorithme
suivant :
65
Algorithme :
A. Pour chaque bibliothèque participante faire :

1. Inclure les fichiers de configuration contenant les déclarations des méthodes
adaptatrices nécessaire relatives à cette bibliothèque
Méthode 1 : Connexion vers la base de données de la bibliothèque.
Méthode 2 : Recherche par auteur.
Méthode 3 : Recherche des auteurs d‟une ressource.
2. Etablir la connexion vers la base de données de la bibliothèque :
 Appel de la méthode 1
3. Lancer la recherche vers la base de données de la bibliothèque
 Appel de la méthode 2 « Recherche par auteur » :
Elle a en entrée le nom de l‟auteur « Carnegie » et en sortie elle rend un tableau à 2

dimensions :
- Les colonnes : Titre, auteur, mots-clés, description, éditeur, date, type,

format, langage, identificateur.
- Les lignes : les ressources résultantes de la requête
4. Insérer les résultats contenus dans le tableau dans la vue « Ressource ».
5. Pour chaque ressource de la vue des résultats :
5.1. Lancer la recherche de tous les auteurs de la ressource (pour récupérer les
autres auteurs de la ressource)
 Appel de la méthode 3 « Recherche des auteurs d‟une ressource »
Elle récupère les noms et prénoms des auteurs de cette ressource dans un tableau
à 2 dimensions :
- Les colonnes : identificateur de la ressource, nom et prénom de l‟auteur.

- Les lignes : Les auteurs résultants de la requête.
5.2. Insérer les résultats contenus dans ce tableau dans la vue « Auteur », ainsi
nous attribuions à chaque ressources ses auteurs.
Fin pour
66
{A la fin nous obtiendrons le total des résultats de toutes les requêtes vers toutes les
bibliothèques dans les vues « Ressource » et « Auteur ».}
B. Afficher les résultats contenus dans les vues. (On permet à l‟utilisateur de personnaliser
l‟affichage selon ses préférences en triant les résultats selon des critères qu‟il choisit).
67
Chapitre 4 :
Etude Préliminaire
68
Chapitre 4 : Etude préliminaire
Objectifs du chapitre :
Ce chapitre va nous servir à poser les bases de la capture des besoins du système à
réaliser. Nous allons déterminer les besoins fonctionnels en considérant le système comme
une boîte noire, afin d‟étudier sa place dans le système métier plus global de l‟entreprise.
Après avoir identifié les acteurs qui interagiront avec le système, nous développerons un
premier modèle UML de niveau contexte, pour pouvoir établir précisément les frontières
fonctionnelles du système.
1. Recueil des besoins fonctionnels :
Il s'agit des fonctionnalités du système. Ce sont les besoins spécifiant un comportement

d'entrée / sortie du système. Les besoins fonctionnels déduits à partir de notre étude se
résument ci-dessous :
Gestion des adhésions :
A travers l‟application web on devra gérer (ajouter, modifier, supprimer) les bibliothèques
participantes, les bibliothécaires représentant des bibliothèques et les adhérents du PEB.
Gestion des adaptateurs :
La gestion des adaptateurs devra pouvoir être effectué à partir de l‟application : l‟ajout d‟un
adaptateur, la modification et la suppression. Lorsqu‟une nouvelle bibliothèque veut participer
au réseau elle devra compléter un formulaire pour récupérer toutes les informations
nécessaires pour la création des adaptateurs correspondants et les intégrer dans notre
application.
Recherche de ressource :
La première étape pour l‟internaute consiste à rechercher une ressource. Il peut rechercher
directement dans un catalogue d‟une bibliothèque choisie, comme il peut lancer une recherche
fédérée ciblées et rapide à travers le catalogue collectif de l‟ensemble des bibliothèques.
Les références de l‟ouvrage recherché pouvant être plus ou moins précises, il faut lui fournir
plusieurs méthodes de recherche. L‟internaute pourra ainsi saisir un critère (titre, auteur,
édition, etc.) (Recherche simple) ou même plusieurs critères à la fois (Recherche avancée).
69
Les résultats de la recherche seront disponibles sur une page particulière, et devront pouvoir
être facilement parcourus et reclassés.
Toutefois, s‟il n‟a pas d‟idée bien précise, il faut également lui fournir le moyen de flâner
comme il le ferait dans les rayons d‟une vraie bibliothèque : pour cela, il pourra accéder
directement à une classification thématique, aux nouveautés, aux ressources les plus
empruntées et aux acquisitions récentes etc.
L‟adhérent peut consulter l‟historique de ses recherches effectuées précédemment, cela lui
donnera un point de reppert pour ses anciennes recherches et aidera les bibliothèques à
connaitre les centres d‟intérêt de leurs lecteurs et orientera leurs choix d‟acquisition.
Découverte des ressources :
Une fois la liste des ouvrages correspondants à la recherche est dressée, l‟usager devra
identifier aisément chaque ouvrage et ceci grâce à sa fiche technique qui est présentée en
détail sur sa propre page. On y trouvera en particulier :
- Le nom complet de l‟ouvrage, noms des auteurs de l‟ouvrage, maison d‟édition, année
d‟édition, un résumé clair de l‟ouvrage,
- La bibliothèque de possession de l‟ouvrage,
- La disponibilité d‟un exemplaire de l‟ouvrage et en cas de non disponibilité (date de
changement d‟état en « disponible » pour une réservation) ; Etc.
Sélection :
L‟usager peut sélectionner un ouvrage et l‟enregistrer dans un panier virtuel, ainsi il va

pouvoir garder les titres intéressants et les ré-consulter ultérieurement.
Réserver une ressource :
Après avoir visualisé la fiche descriptive d‟un ouvrage, si celle là indique qu‟il est disponible
ou bien non disponible et il y a une possibilité de le réserver alors l‟adhérent peut effectuer
une réservation, le système lui réserve un exemplaire. Cependant, la bibliothèque a le droit
d'exclure certains ouvrages du prêt, comme elle peut les restreindre à des conditions
déterminées (statut du demandeur, décharge).
70
Sur le formulaire prédéfinit de réservation, l‟adhérent choisit la bibliothèque où il veut

récupérer l‟ouvrage.
Si un ouvrage trouvé lors de la recherche est indisponible momentanément et la réservation

est permise par le système, l'adhérent pourra toujours effectuer une réservation. L‟adhérent
sera prévenu de la date de sa disponibilité pour le récupérer dans un délai limité.
L‟adhérent ne peut pas emprunter deux exemplaires du même ouvrage de la même

bibliothèque, ni les réserver.
Le nombre total de prêts et de réservations possibles par un adhérent à un moment donné est
fixé à trois (3).
Annuler une réservation :
L‟adhérent dispose d‟une interface lui permettant de visualiser toutes ses réservations. Il peut
cependant annuler une réservation s‟il a changé d‟avis concernant cet emprunt. L‟annulation
peut se faire durant un délai déterminé qui correspond au délai de récupération de l‟ouvrage,
donc s‟il ne se présente pas pour le récupérer et s‟il n‟annule pas sa réservation, elle sera
annulée automatiquement par le système après la fin du délai.
Traitement des réservations :
Le traitement des réservations se fera automatiquement par le système, c'est-à-dire que ça ne

nécessite pas l‟intervention des bibliothécaires à ce niveau, ni l‟administrateur.
Le prêt PEB :
Lorsqu‟un adhérent se présente chez la bibliothèque pour emprunter une ressource, au nom du
système PEB, il doit ramener sa carte d‟adhérence au PEB. Le bibliothécaire lui demande s‟il
a effectué une réservation, si oui, le bibliothécaire saisie le code de l‟adhérent, lance une
recherche des réservations de ce dernier et vérifie l‟existence d‟une réservation pouvant la
traiter. La réservation est décrite par un numéro, le code de l‟adhérent, son nom et prénom, la
ressource réservée (bibliothèque de possession et code de l‟exemplaire dans celle-ci, date
prévue de récupération, bibliothèque de récupération, localisation de l‟exemplaire). Après
vérification, Le bibliothécaire livre la ressource à l‟adhérent et enregistre le prêt.
L‟adhérent récupère la ressource auprès de la bibliothèque choisie lors de la réservation.

71
Dans le cas où l‟adhérent n‟a pas de réservation, il s‟agit du cas du PEB directe.
Le PEB directe :
Si un adhérent du PEB se présente à une bibliothèque du réseau pour demander un prêt PEB
(sans réservation préalable) le bibliothécaire effectue une recherche sur site et vérifie la
disponibilité de l‟ouvrage. Si l‟ouvrage est disponible et se trouve dans cette bibliothèque
alors le bibliothécaire enregistre directement le prêt PEB et lui livre le document,
Si L‟ouvrage est disponible mais n‟est pas dans cette bibliothèque ou bien n‟est pas
disponible alors le bibliothécaire lui crée une réservation (l‟adhérent choisit la bibliothèque de
récupération).
Prolongation de prêt :
L‟adhérent peut consulter tous ses emprunts en cours, et prolonger un emprunt (si la ressource
qu‟il détient n‟est pas réservée). Il pourra le faire tout en sachant qu‟une seule prolongation
est possible sur un même prêt.
La restitution :
Lorsqu‟un adhérent se présente chez une bibliothèque pour remettre une ressource il doit
ramener sa carte d‟adhérence au PEB. Le bibliothécaire recherche le prêt concernée soit à
l‟aide de l‟identifiant de la ressource (bibliothèque de possession et code exemplaire), soit à
l‟aide du code de l‟adhérent, soit le numéro du prêt si l‟adhérent le connait (c‟est le même
numéro que celui de la réservation). S‟il vérifie qu‟il y a un prêt qui concerne bien cette
ressource, alors il retient la ressource et enregistre la restitution.
L‟adhérent peut rendre la ressource empruntée dans n‟importe quelle bibliothèque du réseau.
Entrés/sorties de ressource :
Le bibliothécaire représentant d‟une bibliothèque devra signaler toutes les transitions de

ressources entre sa bibliothèque et les autres bibliothèques. Il doit enregistrer les
entrées/sorties de ressources provenant ou à destination des autres bibliothèques.
Suivi du PEB par l’administrateur :
72
Tout le suivi d‟une opération de PEB pourra s‟effectuer en ligne (il faudra néanmoins
indiquer la réservation, le prêt et le retour du document). Pour chaque opération de PEB, il
faut pouvoir savoir à tout moment où se trouve le document (réservé, en attente de transition,
en attente de prêt, dans telle ou telle bibliothèque…). L‟administrateur peut intervenir pour
annuler une réservation dans le cas de détection d‟erreur.
Suivi du PEB par les bibliothécaires :
De la même manière que pour l‟administrateur, les bibliothécaires peuvent suivre les
opérations du PEB qui concernent les ouvrages propres à leurs bibliothèques. Le système doit
aussi avertir les bibliothécaires de toutes les entrées/sorties qui sont programmées et qui sont
dues aux prêts et restitutions et aux transitions de ressources entre bibliothèques.
Relance et avertissements :
Notre système doit être en mesure d‟aviser l‟adhérent pour qu‟il vienne récupérer l‟ouvrage
réservé en lui envoyant un mail de relance. De même un mail d‟avertissement lui est envoyé
dans le cas où il dépasse les délais.
Le système doit aussi s‟assurer que les délais sont tenus de la part des bibliothèques. Par
exemple, si une bibliothèque se tarde à récupérer un ouvrage ou à le remettre, le système lui
enverra un mail de relance, et dans le cas où elle dépasse carrément le délai le système
enverra un mail d‟avertissement.
La liste noire :
C‟est la liste des adhérents PEB signalés comme étant mauvais emprunteurs (retard de remise
ou de retrait), c‟est le système qui accomplira cette tache mais l‟administrateur peut ajouter un
adhérent à la liste, ou bien en retirer un, cela est fait pour une question de privilège et de
fiabilité du système (au cas d‟une défaillance système, l‟intervention manuelle reste une
option).
Proposition d’ouvrage par adhérent :
L‟adhérent peut toute fois si un livre l‟intéresse et qu‟il ne le retrouve pas dans le fond
documentaire de l‟ensemble des bibliothèques du réseau, de proposer de l‟acquérir.
Annuaire des bibliothèques :

73
On devra mettre à la disposition des adhérents un annuaire qui va contenir les fiches
signalétiques des bibliothèques, ainsi il pourra consulter l‟adresse ou le numéro de téléphone
pour contacter une bibliothèque.
Le livre d’or :
Permet à l‟adhérent de laisser une appréciation ou bien un commentaire témoignant ce qu‟il

pense du site de PEB.
Paiement :
Dans notre travail nous n‟allons pas traiter le paiement du service de prêt entre bibliothèques,
nous nous concentrons principalement dans la gestion de ce dernier.
Les transitions de ressources entre bibliothèques :
Le support de transmission d‟un document est matériel, c'est-à-dire qu‟il sera transmis sur son
support d‟origine « matériel ». La nature du support de transmission implique que le mode de
transmission soit à voie routière. Nous n‟allons pas parler du moyen ni des règles de transport.
Réglementation du PEB :
Une bibliothèque voulant intégrer notre système doit se plier aux règlements généraux du
système PEB :
 Une bibliothèque doit réaliser son adaptateur pour ingérer notre système.
 Un adhérent s‟inscrivant au PEB doit payer un prix déterminé, ainsi il aura une carte
approprié plus un login et un mot de passe.
 Le prêt d‟une ressource dans le cadre du PEB, ne doit pas dépassé dix jours.
 A un moment donné, il ne peut y avoir que deux réservations sur le même exemplaire
de ressource.
 Après trois jours d‟arrivée de la ressource, si l‟adhèrent ne vient pas récupérer la
ressource demandée, le système annule automatiquement sa réservation et lui envoie
un message de pénalité.
 Pour chaque jour de retard, l‟adhèrent sera privé de prêt durant trois jours.
 L‟adhèrent possède une boite de réception dans laquelle il va recevoir toute les
informations concernant l‟état de sa demande.
74
 Si l‟adhérent ne rend pas une ressource après six mois, il sera pénalisé : il devra
rembourser la ressource et aura pour chaque jour de retard trois jours d‟interdiction de
prêt.
 Quand une réservation est passée en ligne, l‟adhérent devra choisir la bibliothèque de
récupération alors une sortie sera programmée dans la bibliothèque ou se trouve la
réservation et une entrée sera programmée dans la bibliothèque de récupération de
l‟adhérent.
 Le bibliothécaire enregistre les entrées et sorties des ressource.
2. Recueil des besoins opérationnels :

Les besoins opérationnels qui orientent la conception architecturale du système. Il s'agit des
besoins qui caractérisent le système. Ce sont des besoins en matière de qualité, de
performance, de sécurité, fiabilité et évolutivité.
2.1. Exigences de qualité :
Pour attirer un client sur un site et ensuite le fidéliser, il est important de répondre aux
exigences de qualité suivantes :
 Ergonomie sobre et efficace
Réserver un livre sur le Web ne doit pas prendre beaucoup de temps ou demander une
maîtrise de mathématiques. La mise en page du site facilitera au maximum la démarche à
l‟aide d‟une présentation claire et intuitive. Les sites trop riches et trop complexes
n‟incitent pas à les fréquenter, car ils demandent un effort intellectuel important et non
souhaité.
 Formulaire de demande simple
Très souvent, l‟internaute cale au moment de demander un prêt, car l‟effort le plus
important à fournir est le renseignement du prêt. La conception et la présentation de la
75
réservation de ressource seront donc particulièrement soignées pour ne pas rebuter

l‟emprunteur.
 Aide en ligne puissante
À tout moment, l‟internaute peut consulter des pages d‟aide contextuelle, ainsi que lancer
une recherche dans l‟ensemble des pages d‟aide. Une visite guidée sera également
proposée aux nouveaux visiteurs. Une aide est aussi proposée à l‟administrateur et au
bibliothécaire pour pouvoir se familiariser avec l‟application et pouvoir par la suite la
maitriser.
2.2. Exigences de performance :
N‟oublions pas non plus les exigences quantitatives suivantes, très importantes également
pour les utilisateurs :
 Le système de prêt inter bibliothèques doit pouvoir gérer les comptes de tous les
lecteurs des bibliothèques.
 Le site web doit supporter un nombre important de connexions simultanées.
 La recherche de ressource ne doit prendre beaucoup de temps.
2.3. Exigences de disponibilité et de fiabilité :
Il est souhaitable que le système soit disponible 24 heures sur 24. Cependant il faut prévoir
une heure d‟indisponibilité en moyenne par semaine pour cause de maintenance et de mise à
jour logicielle.
2.4. Exigences de sécurité :
IL faudra noter que l'application devra être hautement sécurisée car les informations ne
devront pas être accessibles à tout le monde.
 L‟administrateur doit être reconnu par un identifiant et un mot de passe, ainsi que le
bibliothécaire.
 L‟adhérent pour accéder à son compte doit être reconnu par un identifiant et un mot de
passe.
76
3. Fonctionnalités du système :
Les spécifications fonctionnelles sont toujours une projection de ce qui est censé être
construit, ces spécifications décrivent ce que la solution DOIT (MUST) être, PEUT (MAY)
être, POURRAIT (SHOULD) fournir [FRE, 05].
 La partie obligatoire (MUST) : Elle est l‟expression des éléments incontournables du

cahier des charges, ces fonctionnalités doivent être intégrées en premier.
 La partie optionnelle (MAY) : Partie des fonctionnalités qui ne sont pas absolument
nécessaire à l‟accomplissement du cahier des charges, elles peuvent être intégrées en
second temps.
 La partie indicative (SHOULD) : C‟est une partie des fonctionnalités qui très vivement
sollicitées, mais pas nécessairement sous la forme spécifiée, en d‟autres termes
facultatives.
Selon cette classification nous allons structurer les fonctionnalités de notre application
déduites à partir du recueil des besoins.
77
La partie obligatoire :
 Gestion des adaptateurs.

 Gestion des adhésions (bibliothèques, bibliothécaires,
adhérents).
 Recherche d‟ouvrage.
 Réservation d‟ouvrage, annulation de réservation.
 Gestion des entrées/sorties de ressources (prêt et restitution
de ressources, transitions de ressources entre
bibliothèques).
 Prolongation de prêt.
 Suivi des opérations du PEB.
 Gestion des relances et des avertissements.
 Gestion de la liste noire.
La partie optionnelle :
 L‟historique des recherches.

 Boites de réception.
 Propositions d‟ouvrages.
 Livre d‟or.
 Paniers de notices.
 Statistiques sur le PEB.
La partie indicative :
 Aide en ligne.
 Annuaire des bibliothèques.
 Nouvelles acquisitions.
 Evènements récents.
Figure 10 : Classification des fonctionnalités par ordre de priorité
78
4. Architecture fonctionnelle en paquets :
Le schéma ci-dessous représente les différents paquets qui regroupent les fonctionnalités de
notre système.
Paquet 1 : Gestion des adhésions
 Gestion des bibliothèques.

 Gestion des bibliothécaires.
 Gestion des adhérents PEB.
Paquet 2 : PEB en ligne
 Recherche d‟ouvrage.
 Réservation d‟ouvrage et annulation de réservation.
 Prêt et restitution
 Prolongation de prêt.
 Transitions de ressources entre bibliothèques.
Paquet 3 : Monitoring et suivi
 Gestion des adaptateurs

 Le contrôle d‟accès.
 Suivi des opérations du PEB.
 Gestion des relances et des avertissements.
 Les statistiques.
 Gestion des paniers.
 Gestion de la liste noire.
 Gestion du livre d‟or.
 Gestion des propositions d‟acquisitions.
79
Paquet 4 : Espaces personnels
 Panier en cours.
 Proposition d‟ouvrage.
 Historique des recherches.
 Boites de réception.
 Signature du livre d‟or.
Paquet 5 : Diffusions
 Aide en ligne.
 Annuaire des bibliothèques.
 Nouvelles acquisitions.
 Evènements récents.
Figure 11 : Les fonctionnalités du système en

paquets
5. Identification des acteurs :
Un acteur représente l'abstraction d'un rôle joué par une entité externe (utilisateur
humain, dispositif matériel ou autre système) qui interagit directement avec le système étudié.
Un acteur peut consulter et/ou modifier directement l‟état du système, en émettant et/ou en
recevant des messages susceptibles d‟être porteurs de données. [ROQ, 07]
Suivant cette définition, nous avons identifié ces acteurs :
 L’administrateur : Il a pour rôle d‟administrer le système de PEB, de suivre le

déroulement du prêt inter bibliothèques et de veiller sur son bon fonctionnement.
 Le bibliothécaire : Rôle des employés des bibliothèques membres du réseau qui sont
responsables de représenter ces dernières (suivre les opérations de prêt qui concernent les
ouvrages de leurs bibliothèques) et de compléter le fonctionnement des prêts-inter (ex.
signaler le prêt et la restitution d‟ouvrage lors d‟une opération de PEB).
80
 L’internaute visiteur : Toute personne qui tombe par hasard sur notre site ou qui utilise
notre application comme source d‟information. Elle peut effectuer des recherches sur les
ouvrages des bibliothèques du réseau.
 L’internaute adhérent : toute personne inscrite au système de PEB, c‟est-à-dire possédant

un compte validé. Il peut profiter des services du prêt entre bibliothèques.
6. Identification des messages :
On va détailler les différents messages échangés entre le système et l‟extérieur.

Définition : [ROQ, 07]
Un message représente la spécification d‟une communication unidirectionnelle entre les
objets qui transporte de l‟information avec l‟intention de déclencher une activité chez le
récepteur.
Le système émet les messages suivants :
 Les fiches des bibliothèques, des bibliothécaires et des adhérent PEB.

 Les adaptateurs du système.
 Les résultats des recherches de ressources
 Les fiches descriptives des ressources
 Les paniers en cours
 Les confirmations des réservations de ressources, d‟annulations de réservations et des
prolongations d‟emprunts.
 Le suivi des opérations de PEB.
 Messages de relance ou d‟avertissement
 Signaux d‟erreurs ou d‟incohérence
 Les statistiques décrivant le déroulement du PEB
 La liste noire
 La liste des propositions
 L‟annuaire des bibliothèques
 Le contenu du livre d‟or
 L‟historique des actions des bibliothécaires
 Les entrées/sorties des ressources programmées
 Les boites de réception
 L‟aide en ligne
81
Le système reçoit les messages suivants :
 Créations, modifications et suppressions des fiches des bibliothèques, celles des

bibliothécaires, et celles des adhérents PEB.
 Créations, modifications et suppressions d‟adaptateurs.
 Lancement de recherches sur les ressources des bibliothèques
 Demandes de prêt de ressources
 L‟annulation des réservations
 Demandes de prolongation d‟emprunts
 Les alimentations des paniers
 Entrées/sorties des ressources (prêt, restitution, transition)
 Les ajouts et suppressions des lecteurs de la liste noire
 Les propositions d‟acquisition de ressources
 Les commentaire et appréciations des lecteurs (livre d‟or)
7. Modélisation du contexte :
Nous allons maintenant modéliser le contexte de notre application. Ceci va nous permettre
dans un premier temps, de définir le rôle de chaque acteur dans le système :
Utilisateur final Description des besoins fonctionnels
Internaute visiteur L‟application doit permettre à un internaute visiteur de :
 Lancer une recherche de ressources dans le catalogue

collectif des bibliothèques et voir les résultats.
 Visualiser la fiche descriptive d‟une ressource donnée.
 Consulter l‟annuaire des bibliothèques.
 Se renseigner sur les modalités de prêt et les informations
pratiques.
 Consulter les évènements récents des bibliothèques du réseau
et les nouvelles acquisitions.
Internaute adhérent L‟application doit permettre à un internaute Adhérent de :
 S‟authentifier et accéder à son espace personnel

 Lancer une recherche sur une ressource dans les catalogues
des bibliothèques selon des critères choisis et voir les
résultats
 Consulter la fiche descriptive de ressource
 Vérifier la disponibilité d‟une ressource
 Réserver une ressource
82
 Suivre l‟état de sa réservation

 Demander de prolonger son emprunt
 Annuler une réservation de ressource
 Gérer son panier de notices (alimentation, suppression)
 Consulter sa boite de réception qui contient les messages de
relance et d‟avertissement
 Visualiser l‟historique de ses recherches
 Proposer une ressource pour acquisition
 Laisser un commentaire dans le livre d‟or
 Consulter l‟annuaire des bibliothèques
 Se renseigner sur les modalités de prêt et les informations
pratiques
 Consulter l‟aide en ligne
 Consulter les évènements récents des bibliothèques du réseau
et les nouvelles acquisitions
Bibliothécaire L‟application doit permettre au bibliothécaire de :

 Signaler l‟inscription des lecteurs des bibliothèques du
réseau dans ce service de PEB
 Signaler un prêt ou une restitution PEB se déroulant au
niveau de sa bibliothèque
 Signaler toutes les entrées/sorties de ressources provenant ou
à destination d‟une autre bibliothèque
 Suivre les opérations de PEB qui concernent les ressources
de sa bibliothèque
Administrateur L‟application doit permettre à l‟administrateur de :

 Ajouter, modifier ou supprimer les fiches des bibliothèques,
des bibliothécaires, et adhérents PEB
 Gérer les adaptateurs du système (ajout, modification ou
suppression)
 Visualiser les opérations de PEB
 Consulter les erreurs et incohérences détectés par le système
 Consulter le module des statistiques
 Gérer la liste noire (ajout ou suppression d‟adhérent)
 Consulter les propositions d‟acquisition
 Consulter le livre d‟or
 Suivre les actions des bibliothécaires
Tableau 2 : Modélisation du contexte de l‟application
83
Chapitre 5 :
Capture des besoins

fonctionnels
84
Chapitre 5 : Capture des besoins fonctionnels
Ce chapitre traite du rôle que tient UML pour compléter la capture des besoins
fonctionnels ébauchée durant l‟étude préliminaire. La technique des cas d‟utilisation est la
pierre angulaire de cette étape. Elle va nous permettre de préciser l‟étude du contexte
fonctionnel du système, en décrivant les différentes façons qu‟auront les acteurs d‟utiliser le
futur système. Nous allons ensuite préparer l‟analyse orientée objet en identifiant les classes
candidates du modèle statique d‟analyse.
1. Identification des cas d’utilisation :
Un cas d‟utilisation (use case) représente un ensemble de séquences d‟actions qui sont
réalisées par le système et qui produisent un résultat observable intéressant pour un acteur
particulier. Un cas d‟utilisation modélise un service rendu par le système. Il exprime les
interactions acteurs/système et apporte une valeur ajoutée « notable » à l‟acteur concerné.
[ROQ, 07]
Il nous faut plusieurs itérations pour arriver à constituer des cas d‟utilisation complets.
Pour constituer les cas d‟utilisation, il faut considérer l'intention fonctionnelle de l'acteur par
rapport au système dans le cadre de l'émission ou de la réception de chaque message. En
regroupant les intentions fonctionnelles en unités cohérentes, on obtient les cas d'utilisations.
On a recensé les cas d‟utilisation présentés ci-dessous.
Cas d’utilisation : « S‟authentifier »
Acteurs : Administrateur, bibliothécaires, internaute adhérent.
But : Permettre à l‟utilisateur de s‟authentifier pour ouvrir sa session et accéder à ses

privilèges.
85
Figure 12 : Diagramme du cas d‟utilisation « S‟authentifier »
A partir de maintenant les cas d‟utilisation seront présentés en paquets. Nous avons
isolé ce cas précédent car son but ne correspond à aucun paquet, cependant la plupart des cas
d‟utilisation des paquets nécessitent le déroulement avec succès de ce cas pour qu‟ils puissent
se déclencher (cela sera détaillé dans la description détaillée des cas d‟utilisation).
Gestion des adhésions

Paquet
1
Cas d’utilisation Acteurs But
Gérer les bibliothèques Administrateur Ce cas permet la gestion des bibliothèques
(ajout, modification, suppression)
Gérer les bibliothécaires Administrateur Ce cas permet la gestion des bibliothécaires

Gérer les adhérents PEB Administrateur Ce cas permet la gestion des adhérents du
Bibliothécaire PEB (ajout, modification, suppression)
Tableau 3 : Liste des cas d‟utilisation du paquet « Gestion des adhésions »
86
Figure 13 : Diagramme des cas d‟utilisation du paquet « Gestion des adhésions »
PEB en ligne
Paquet
2 nitoring et suivi
Rechercher une Visiteur Ce cas permet de rechercher une ressource

ressource Adhérent dans le fond documentaire du réseau des
bibliothèques et de visualiser sa fiche
descriptive
Réserver une ressource Adhérent Ce cas permet de réserver une ressource qui
existe dans le fond documentaire du réseau
des bibliothèques afin de l‟emprunter
Annuler une réservation Adhérent Ce cas permet de visualiser ses réservations

en cours et en annuler
Prolonger un emprunt Adhérent Ce cas permet de prolonger un emprunt en

cours
Enregistrer un prêt Bibliothécaire Ce cas permet d‟enregistrer un prêt

lorsqu‟un adhérent emprunte une ressource
Restituer un prêt Bibliothécaire Ce cas permet de restituer un prêt lorsqu‟un

adhérent remet une ressource après emprunt
87
Enregistrer une transition Bibliothécaire Ce cas permet d‟enregistrer une transition

de ressource de ressource entre bibliothèques (envoi de
ressource vers une bibliothèque, réception
d‟une ressource provenant d‟une
bibliothèque)
Tableau 4 : Liste des cas d‟utilisation du paquet « PEB en ligne »
Figure 14 : Diagramme des CU du paquet « PEB en ligne »
88
Monitoring et suivi
Paquet
3 nitoring et suivi
Gérer les adaptateurs Administrateur Ce cas permet La gestion des adaptateurs

Gérer la liste noire Administrateur Ce cas permet la gestion de la liste noire

(consulter la liste noire, ajout d‟adhérent PEB
à la liste, supprimer un adhérent de la lise)
Suivre les opérations Administrateur Permet de suivre les opérations de PEB (les
de PEB Bibliothécaire réservations, les prêts et remises d‟ouvrages)
Contacter un adhérent Administrateur Ce cas permet d‟envoyer message à un

adhérent PEB
Consulter le modules Administrateur Ce cas permet de consulter les problèmes ou

des erreurs et imprévus détectés automatiquement par le
imprévus système
Consulter l‟historique Administrateur Ce cas permet de visualiser toutes les actions

des actions des des bibliothécaires auprès du système de PEB
bibliothécaires
Consulter le livre d‟or Administrateur Ce cas permet de consulter les commentaires
des adhérents laissés dans le livre d‟or
Consulter les Administrateur Ce cas permet de visualiser les statistiques

statistiques calculer par le système et qui décrivent le
déroulement du PEB
Consulter les Administrateur Ce cas permet de consulter les propositions

propositions Bibliothécaire d‟acquisition
d‟acquisition
Consulter la trace Administrateur Ce cas permet de consulter la trace d‟une
d‟une ressource Bibliothécaire ressource
Tableau 5 : Liste des cas d‟utilisation du paquet « Monitoring et suivi »
89
Figure 15 : Diagramme des CU du paquet « Monitoring et suivi »
Espaces personnels
Paquet
4
90
Consulter l‟historique de Adhérent Ce cas permet à l‟adhérent de consulter les

ses recherches recherches qu‟il a effectuées auparavant
Proposer une ressource Adhérent Ce cas permet à l‟adhérent de proposer des

pour acquisition ouvrages qu‟il trouve intéressants et qui
n‟existent pas dans le fond documentaire du
réseau
Signer le livre d‟or Adhérent Ce cas permet à l‟adhérent de laisser une

appréciation ou bien un commentaire témoignant
ce qu‟il pense du site de PEB
Gérer son panier Adhérent Ce cas permet à l‟adhérent de consulter son

panier de notices précédemment créé, supprimer
une notice, ajouter une notice
Consulter sa boite de Adhérent Permettre à l‟utilisateur de consulter les

réception messages qu‟il a reçus dans sa boite
Tableau 6 : Liste des cas d‟utilisation du paquet « Espaces personnels »
Figure 16 : Diagramme des CU du paquet « Espaces personnels »
91
Diffusions
Paquet
5
Consulter l‟annuaire Visiteur Ce cas permet de voir les informations sur

des bibliothèques Adhérent les bibliothèques du réseau.
Consulter l‟aide en Visiteur, Ce cas permet de voir le manuel d‟utilisation

ligne adhèrent, de l‟application
administrateur,
bibliothécaire
Consulter les nouvelles Visiteur Ce cas permet de consulter les nouvelles
acquisitions Adhérent acquisitions des bibliothèques du réseau.
Signaler les nouvelles Administrateur Ce cas permet de signaler les nouvelles

acquisitions acquisitions des bibliothèques
Gérer les évènements Administrateur Ce cas permet de gérer les événements se

déroulant dans les bibliothèques du réseau
(ajout, suppression)
Tableau 7 : Liste des cas d‟utilisation du paquet « Diffusions »
Figure 17 : Diagramme des CU du paquet « Diffusions »
92
2. Description détaillée des cas d’utilisation
Nous proposons dans ce qui suit une description textuelle des principaux cas d‟utilisation
complétée par les diagrammes d‟activités.
Le diagramme d’activité est un diagramme dynamique qui permet de consolider les

enchaînements de la fiche textuelle. Ce diagramme est également utile en cas d‟actions
parallèles. De plus, les utilisateurs le comprennent aisément, car il ressemble à un
organigramme traditionnel. Il permet enfin d‟identifier d‟un seul coup d‟œil la famille des
scénarios d‟un cas d‟utilisation qui décrivent toutes les réactions du système. [ROQ, 07]
Cas d’utilisation : « S’authentifier »
Description sommaire :
Acteurs : Administrateur, internaute adhérent, bibliothécaire.
Objectif : S‟authentifier pour pouvoir accéder à ses privilèges au niveau du système.
Description des enchaînements :
Pré conditions : L‟utilisateur doit avoir un compte.
Post conditions : Ouverture de la session de l‟utilisateur.
Scénario nominal :
 L‟utilisateur introduit son login et son mot de passe (PW)
Exceptions :
 Le login ou le mot de passe (voir les deux) est erroné donc l‟accès au système sera
refusé ; le système demande alors à l‟utilisateur d‟introduire à nouveau son login et son
mot de passe.
93
Figure 18 : Diagramme d‟activité du CU « S‟authentifier »
Cas d’utilisation : « Gérer les bibliothèques»
Acteurs : Administrateur.
Objectif : Gérer les bibliothèques (ajout, modification, suppression)
Pré conditions : L‟administrateur doit s‟authentifier.
Post conditions : Mise à jour de la base de données.
Scénario nominal :
 Saisie des informations relatives à la nouvelle bibliothèque, en cas de création,
 Dans le cas de modification, l‟administrateur choisit la bibliothèque à modifier, puis
effectue les modifications souhaitées sur la fiche de cette bibliothèque,
 Dans le cas de suppression, l‟administrateur choisit la bibliothèque à supprimer, alors le
système affiche une fenêtre pour confirmer la suppression.
94
Figure 19 : Diagramme d‟activité du CU « Gérer les bibliothèques »
Cas d’utilisation : « Gérer les bibliothécaires»
Objectif : Gérer les bibliothécaires (ajout, modification, suppression).
Scénario nominal :
 Saisie des informations relatives au nouvel bibliothécaire, en cas de création,
 Dans le cas de modification, l‟administrateur choisit le bibliothécaire à modifier, puis
effectue les modifications souhaitées sur la fiche de ce bibliothécaire,
 Dans le cas de suppression, l‟administrateur choisit le bibliothécaire à supprimer, alors le
système affiche une fenêtre pour confirmer la suppression.
95
Figure : Diagramme d‟activité du CU « Gérer les bibliothèques »
Figure 20 : Diagramme d‟activité du CU « Gérer les bibliothécaires »
Cas d’utilisation : « Gérer les adhérents PEB»
Acteurs : Bibliothécaire, administrateur.
Objectif : Gérer les adhérents PEB (ajout, modification, suppression).
Pré conditions : L‟utilisateur doit s‟authentifier.
Scénario nominal :
 Saisie des informations relatives au nouvel adhérent PEB, en cas de création,
 Dans le cas de modification, l‟utilisateur choisit l‟adhérent à modifier, puis effectue les
modifications souhaitées sur la fiche de cet adhérent,
 Dans le cas de suppression, l‟utilisateur choisit l‟adhérent à supprimer, alors le système
affiche une fenêtre pour confirmer la suppression.
96
Figure 21 : Diagramme d‟activité du CU « Gérer les adhérents PEB »
Paquet 2 : PEB en ligne
Cas d’utilisation : « Rechercher une ressource »
Acteurs : L‟Internaute (qu‟il soit adhérent, ou simple visiteur).
Objectif : Lancer une recherche de ressource à travers le fond documentaire du réseau.
Pré conditions : Néant.
Post conditions : L‟Internaute a trouvé l‟ouvrage précis qu‟il cherchait, ou un ouvrage qui
l‟intéresse, voire plusieurs.
Scénario nominal :
 L‟Internaute lance une recherche simple à partir d‟un mot-clé : titre, nom de l‟auteur,
année…, ou une recherche avancée à partir d‟une combinaison de ces critères.
97
 Le système affiche une page de résultat.

 L‟internaute sélectionne un ouvrage, alors le système lui présente sa fiche descriptive
détaillée (titre, auteurs, éditeur, date de parution, sa disponibilité.).
Figure 22 : Diagramme d‟activité du CU « Rechercher une ressource »
Cas d’utilisation : « Réserver une ressource »
Acteurs : Internaute adhérent.
Objectif : Réserver une ressource pour pouvoir l‟emprunter.
Pré conditions :
 L‟adhérent doit s‟authentifier.
 L‟adhérent doit faire une recherche au préalable et visualiser la fiche technique de la
ressource qu‟il désir réserver.
98
Post conditions : Mise à jour de la base de données
Scénario nominal :
 L‟adhérent complète le formulaire de réservation avec la bibliothèque de récupération et
lance la demande.
 Le système vérifie que l‟adhérent a le droit au prêt (nombre max de prêt non atteint, aucun
prêt en cours ou réservation concernant la même ressource) et affiche sa réponse :
- Demande acceptée, Réservation crée (n° de la réservation, date et bibliothèque de
récupération, délai de récupération)
- Demande refusé, avec la raison du refus.
Figure 23 : Diagramme d‟activité du CU « Réserver une ressource »
Cas d’utilisation : « Annuler une réservation »
Acteurs : Adhérent PEB.
Objectif : Visualiser ses réservations de ressources et pouvoir annulé une réservation.
Pré conditions :
 L‟adhérent s‟est authentifié
99
 L‟adhérent a au moins une réservation active
Scénario nominal :
 L‟adhérent demande d‟annuler une réservation.
 Le système affiche à l‟adhérent toutes ses réservations actives.
 L‟adhérent sélectionne une réservation et l‟annule.
Figure 24 : Diagramme d‟activité du CU « Annuler une réservation »
Cas d’utilisation : « Prolonger un emprunt »
Acteurs : Adhérent PEB.
Objectif : Prolonger un prêt en cours.
Pré conditions :
 L‟adhérent s‟est authentifié.
 L‟adhérent a au moins un emprunt en cours
Scénario nominal :
100
 L‟adhérent demande de prolonger un prêt.

 Le système lui affiche tous ses prêts en cours.
 L‟adhérent sélectionne un prêt et demander sa prolongation.
 Le système vérifie la possibilité de prolongation et lui confirme.
Figure 25 : Diagramme d‟activité du CU « Prolonger un emprunt »
Cas d’utilisation : « Enregistrer un prêt »
Acteurs : Bibliothécaire.
Objectif : Ce cas permet d‟enregistrer un prêt lorsqu‟un adhérent emprunte une ressource.
Pré conditions :
 Le bibliothécaire s‟est authentifié.
 L‟adhérent s‟est présenté avec la carte d‟adhérence de PEB et souhaite récupérer une
ressource.
101
Scénario nominal :
 Le bibliothécaire saisie le code de l‟adhérent à partir de la carte.
 Le système lui affiche toutes les réservations actives de cet adhérent.
 Le bibliothécaire sélectionne une réservation possible d‟être traitée (ressource concernée,
sa localisation, date et bibliothèque prévues de récupération),
 Le bibliothécaire enregistre le prêt pour cette réservation (saisie le n° de l‟exemplaire).
 Le bibliothécaire livre la ressource à l‟adhérent.
Figure 26 : Diagramme d‟activité du CU « Enregistrer un prêt »
Cas d’utilisation : « Restituer un prêt »
Objectif : Restituer un prêt lorsqu‟un adhérent remet une ressource après emprunt
Pré conditions :
 L‟adhérent s‟est présenté avec la carte d‟adhérence de PEB et une ressource à remettre.
102
Scénario nominal :
 Le bibliothécaire saisie le code de l‟adhérent à partir de la carte.
 Le système lui affiche tous les prêts en cours de cet adhérent.
 Le bibliothécaire vérifie l‟existence d‟un prêt concernant la ressource à remettre.
 Le bibliothécaire restitue le prêt
Figure 27: Diagramme d‟activité du CU « Restituer un prêt »
Cas d’utilisation : « Enregistrer une transition de ressource »
Objectif : Enregistrer une transition de ressource entre bibliothèques (envoi de ressource vers
une bibliothèque, réception d‟une ressource provenant d‟une bibliothèque)
Pré conditions :
Scénario nominal :
103
 Dans le cas d‟un envoi de ressource vers une bibliothèque, le bibliothécaire saisie
l‟identifiant de la ressource (sa bibliothèque de possession et son code dans celle-ci), la
bibliothèque de destination et enregistre la sortie
 Dans le cas d‟une réception, le bibliothécaire saisie l‟identifiant de la ressource (sa
bibliothèque de possession et son code dans celle-ci), la bibliothèque d‟envoi et enregistre
l‟entrée.
Figure 28 : Diagramme d‟activité du CU « Enregistrer une transition de ressource »
Cas d’utilisation : « Gérer les adaptateurs»
Objectif : Gérer les adaptateurs (ajout, modification, suppression)
Scénario nominal :
104
 Choisir une bibliothèque

 Choisir une fonction
 Saisir le code source de l‟adaptateur correspondant à la fonction, en cas de création,
 Dans le cas de modification, l‟administrateur choisit de modifier, puis modifie le code
source existant,
 Dans le cas de suppression, l‟administrateur choisit de supprimer alors le système affiche
une fenêtre pour confirmer la suppression.
Figure 29 : Diagramme d‟activité du CU « Gérer les adaptateurs »
Cas d’utilisation : « Gérer la liste noire»
Objectifs : Signaler un adhérent comme étant mauvais emprunteur en l‟ajoutant à la liste

noire ou bien en retirer un adhérent.
Scénario nominal :
105
 L‟administrateur choisit un adhérent (dans la liste ou le recherche) puis l‟ajoute à la liste

noire
 Dans le cas d‟une suppression, le système affiche la liste noire, l‟administrateur sélectionne
un adhérent et le supprime de la liste.
Figure 30: Diagramme d‟activité du CU « Gérer la liste noire »
Cas d’utilisation : « Gérer son panier»
Acteurs : Adhérent.
Objectifs : Ce cas permet à l‟adhérent de consulter le panier de notices précédemment créé,

supprimer une notice, ajouter une notice
Pré conditions : L‟adhérent doit s‟authentifier.
106
Scénario nominal :
 L‟adhérent demande de gérer son panier
 Le système affiche la liste des ouvrages contenus dans le panier
 L‟adhérent sélectionne une notice pour la visualiser
 L‟adhérent sélectionne une notice et la supprime du panier
 L‟adhérent enregistre les ouvrages qui l‟intéressent dans un panier virtuel (voir le CU
« Rechercher une ressource »
Figure 31 : Diagramme d‟activité du CU « Gérer son panier »
Cas d’utilisation : « Consulter sa boite de réception»
Acteurs : Adhérent.
Objectifs : Consulter les messages qu‟il a reçus dans sa boite
107
Pré conditions : L‟adhérent doit s‟authentifier.
Scénario nominal :
 L‟adhérent ouvre sa boite de réception
 Le système affiche les messages reçus.
 L‟utilisateur sélectionne un message pour pouvoir le visualiser.
 L‟utilisateur peut sélectionner un message ou plusieurs et puis les supprimer de la boite.
Figure 32 : Diagramme d‟activité du CU « Consulter sa boite de réception »
3. Identification des classes candidates :
Cette phase va préparer la modélisation orientée objet en aidant à trouver les classes
principales du futur modèle statique d‟analyse.
On formalise les concepts métier sous forme de classes et d‟associations rassemblées dans un
diagramme statique, appelé « diagramme de classes participantes ».
Cas d’utilisation « S’authentifier » :
108
Figure 33 : Diagramme des classes participantes du CU « S‟authentifier »
Figure 34 : Diagramme des classes participantes du paquet « Gestion des adhésions »
109
Paquet 2: PEB en ligne
Figure 35 : Diagramme des classes participantes du paquet « PEB en ligne »
110
Figure 36: Diagramme des classes participantes du paquet « Monitoring et suivi »
111
Figure 37 : Diagramme des classes participantes du paquet « Espaces personnels »
Paquet 5 : Diffusions
Figure 38: Diagramme des classes participantes du paquet « Diffusions »
112
Chapitre 6 :
Capture des besoins

techniques
113
Chapitre 6 : Capture des besoins techniques
La capture des besoins techniques couvre, par complémentarité avec celle des besoins
fonctionnels, toutes les contraintes qui ne traitent ni de la description du métier des
utilisateurs, ni de la description applicative et elle se présente comme suit :
- Capture des spécifications techniques liées à la configuration matérielle.

- Capture des spécifications logicielles.
1. Capture des spécifications techniques : Configuration matérielle
Les besoins opérationnels et les choix stratégiques de développement impliquent des

contraintes relatives à la configuration du réseau matériel. Elles sont de nature géographique,
organisationnelle, et technique. La configuration géographique du système de PEB et le
nombre important d‟utilisateurs nécessite une architecture trois tiers déployée sur le réseau
internet.
1.1. Architecture 3-tiers :
Le style d‟architecture en niveaux spécifie le nombre de niveaux géographiques et

organisationnels où vont se situer les environnements d‟exécution du système.
L'architecture 3-tiers est un modèle logique d'architecture applicative qui vise à séparer très
nettement trois couches logicielles au sein d'une même application :
 Couche Présentation (premier niveau)
Elle correspond à la partie de l'application visible et interactive avec les utilisateurs. On parle
d'Interface Homme Machine. Elle est exploitée par un navigateur web. La couche présentation
relaie les requêtes de l'utilisateur à destination de la couche métier, et en retour lui présente les
informations renvoyées par les traitements de cette couche.
 Couche Métier / Business (second niveau)
Elle correspond à la partie fonctionnelle de l'application, celle qui implémente la « logique »,

et qui décrit les opérations que l'application opère sur les données en fonction des requêtes des
utilisateurs, effectuées au travers de la couche présentation. Les différentes règles de gestion
114
et de contrôle du système sont mises en œuvre dans cette couche. La couche métier offre des
services applicatifs et métier à la couche présentation. Pour fournir ces services, elle s'appuie,
le cas échéant, sur les données du système, accessibles au travers des services de la couche
inférieure.
 Couche Accès aux données (troisième niveau)
Elle consiste en la partie gérant l'accès aux gisements de données du système. Ces données
peuvent être propres au système ou gérées par un autre système.
Ce modèle d‟architecture a pour objectif d‟alléger le poste de travail client et de prendre en

compte l‟hétérogénéité des plates-formes (serveurs, clients, langage, etc.)
Le schéma suivant illustre la répartition des couches dans une architecture trois tiers.
Présentation
Métier
Accès aux données
Figure 39 : La répartition des différentes couches de l‟architecture 3-tiers
1.2. Architecture de l’application web :
Le nombre impressionnant de produits et de technologies liés à Internet disponibles

actuellement a suscité des architectures d‟application web multiples et variées. Cependant,
une application web digne de ce nom implique l‟existence d‟au moins quatre composants
d‟architecture significatifs :
115
 Le navigateur client,
 Le serveur web,
 Le serveur d‟applications,
 Le serveur de données.
À un haut niveau, on peut identifier dans les applications web d‟aujourd‟hui plusieurs patterns
architecturaux. Nous avons opté pour le pattern du client web léger.
Le client web léger :
Le client web léger est le pattern architectural le plus classique aujourd‟hui, il

correspond aux applications internet/intranet pour lesquelles la configuration du client n‟est
pas maîtrisable, à ceci près que l‟on requiert côté client un navigateur web assez récent (par
exemple comprenant le langage JavaScript). L‟utilisation du client web léger simplifie le
travail en éliminant le besoin de diffuser, puis d'installer un logiciel client sur les machines
des utilisateurs.
Les composants majeurs de ce pattern se trouvent sur le serveur. Cette architecture est
effectivement celle d‟une application web minimale.
 Le navigateur client est un navigateur HTML standard compatible avec les formulaires et
DHTML. Il agit comme un dispositif universel d‟interface utilisateur. Son unique fonction
est d‟accepter et de renvoyer des cookies. L‟utilisateur de l‟application requiert des pages
HTML auprès du serveur à travers le navigateur.
 Le serveur web est le point d‟accès principal pour tous les navigateurs clients. C‟est un
logiciel chargé de transmettre au client en ayant fait la demande via l‟URL, les fichiers
statiques demandés, présents sur la machine serveur. Néanmoins le rôle d‟un serveur web
est limité sur le plan applicatif ; dès que l‟URL porte sur une page dynamique, nécessitant
un traitement, le serveur web aiguille cette demande vers le brique « serveur
d‟application ». une fois le traitement effectué, le serveur d‟application renvoie la page
html au serveur web qui se charge de la diriger vers le bon destinataire.
 Le serveur d’application est le principal exécuteur de la logique « métier » du côté du

serveur. Il rend accessible les données de l‟application : il doit pouvoir accéder à de
116
nombreuses sources de données. Il prend également en charge l‟ensemble des

fonctionnalités qui permettent à plusieurs clients d‟utiliser la même application. Les
moteurs JSP/Servlets, Microsoft, cold Fusion, PHP…, sont à ce titre des serveurs
d‟application.
 Le serveur de données permet de gérer la persistance des objets métier. Par exemple dans
une base de données relationnelle, pour la connecter au système, le moyen le plus simple
est d‟autoriser les scripts des pages serveur à accéder directement au composant de
persistance. Cet accès direct passera néanmoins par l‟utilisation de bibliothèques standards
d‟accès aux données, telles que RDO, ADO, ODBC, JDBC, etc. Pour des systèmes plus
complexes et plus robustes, on préfère mettre en œuvre une couche objet métier complète.
C‟est l‟optique que nous avons choisie pour notre étude de cas.
Serveur
Serveur web
Client léger d’application
Serveurs de données
distants
(bibliothèques)
Serveur de données
central
Figure 40 : Schéma des composants matériels du nouveau système
117
1.3. Déploiement :
 Les trois couches seront déployées sur une seule machine (un seul serveur physique
contenant les trois serveurs logiques : serveur web, serveur d‟application et serveur de
base de donnée central).
 Les serveurs de bases de données des bibliothèques sont pré existants et sont déployés
sur d‟autres machines distantes mais nous ignorons leur configuration matérielle (déployés
sur combien de machines).
 Les postes clients (PC1, PC2, PC3,…, PCn) accèdent au système via un navigateur web.
Avantages de la solution :
 Elle facilite la mise à jour et la maintenance,

 Son déploiement est simplifié sur les postes clients (clients légers),
 La sécurité est accrue car les données sont centralisées,
 Des meilleures performances grâce au partage de tâches,
 Le temps des transactions entre les différentes couches est relativement petit car elles
sont déployées sur la même machine
Inconvénients de la solution :
 Le serveur est un point de défaillance (maillon faible),

 Elle exploite peu la puissance des postes clients.
Dans ce qui suit nous allons présenter La configuration matérielle schématisée par un
diagramme de déploiement UML.
118
Figure 41 : Configuration matérielle du système
2. Capture des spécifications logicielles :
Une fois que les spécifications techniques architecturales sont exprimées, on s‟intéresse
aux fonctionnalités propres du système technique, en procédant à une spécification logicielle.
Dans ce cadre on utilise les cas d‟utilisation d‟une manière différente que pour la spécification
fonctionnelle, car le cas d‟utilisation technique produit une valeur ajoutée opérationnelle ou
purement technique.
2.1. Identification des exploitants du système :
– Utilisateur, qui utilise une des fonctionnalités du système.
– Ingénieur d’exploitation, chargé de déployer et de dépanner le système.
119
2.2. Les cas d’utilisation techniques :
 Utilisation de l‟aide. Chaque utilisateur doit disposer d‟une aide contextuelle pour
pouvoir exploiter le système d‟une manière efficace.
 Manipulation des objets. L‟utilisateur manipule des entités sous forme d‟objets, ce qui
implique la mise en œuvre des mécanismes de persistance et de gestion de cycle de vie
des objets.
 Gestion de l‟intégrité. C‟est le mécanisme qui empêche la mise à jour simultanée

d‟une même entité par deux utilisateurs différents.
 l‟utilisateur doit se connecter et être reconnu du système pour pouvoir y travailler.

L‟authentification est le mécanisme qui protège le système des intrusions externes.
 Gestion de la distribution. Chaque utilisateur bénéficie d‟une gestion des charges au

niveau du serveur. Ainsi le temps de réponse du système ne s‟en trouve pas dégradé en
fonction du nombre d‟utilisateurs connectés.
 Gestion des erreurs. Il faut que le système soit en mesure de générer des traces et des
alertes pour faciliter sa maintenance.
 Gestion de la sécurité. L‟ingénieur d‟exploitation ainsi que l‟utilisateur sont soumis à

des règles de sécurité.
120
Chapitre 7 : Analyse
121
1. Découpage en catégories :
Cette phase marque le démarrage de l‟analyse objet du système à réaliser. Elle utilise la
notion de package pour définir des catégories de classes d‟analyse et découper le modèle
UML en blocs logiques les plus indépendants possibles.
Pour passer à l‟analyse, il faut se baser sur les principes de l’Approche Orientée Objet,
notamment celle de l‟encapsulation. À cet effet, il faut passer d‟une structuration
fonctionnelle via les cas d‟utilisations et les packages des cas d‟utilisation, à une structuration
objet via les classes et les catégories.
Qu’est-ce qu’une catégorie ?
Une catégorie consiste en un regroupement logique de classes à forte cohérence interne et

faible couplage externe. [ROQ, 07]
Nom de la catégorie
Classes de la catégorie
Figure 42 : Représentation graphique d‟une catégorie
1.1. Répartition des classes candidates en catégories :
Le découpage en catégories de notre projet a donné le résultat suivant :
122
Figure 43 : Schéma représentatif des catégories de classe candidate
1.2. Elaboration des diagrammes de classes préliminaires par catégorie :
Catégorie « Utilisateur »
Classe de la catégorie « Bibliothèque »
Figure 44 : Diagramme des classes de la catégorie « Utilisateur »
123
Catégorie « Prêt »
Catégorie
« Bibliothèque »
Catégorie
« Utilisateur »
Figure 45: Diagramme des classes de la catégorie « Prêt »
124
Catégorie « Bibliothèque »
Figure 46 : Diagramme des classes de la catégorie « Bibliothèque »
Catégorie « Service »
Catégorie
« Utilisateur »
Figure 47 : Diagramme des classes de la catégorie « Service »
125
1.3. Elaboration du diagramme de packages (catégories) :
Le schéma suivant représente l‟état préliminaire des dépendances souhaitées entre les
catégories au début de la phase d‟analyse.
Utilisateur Bibliothèque
Service Prêt
Figure 48 : Diagramme de packages d‟analyse.
2. Développement du modèle statique :
Le développement du modèle statique constitue la deuxième activité de l‟étape de

l‟analyse. Elle se situe sur la branche gauche du cycle en Y et succède au découpage en
catégories.
Dans cette étape nous allons détailler, compléter et optimiser les classes préliminaires
obtenues lors du découpage, et nous allons identifier leurs attributs, leurs méthodes ainsi que
leurs identifiants.
126
Figure 49 : Diagramme de classes
3. Développement du modèle Dynamique :
Le développement du modèle dynamique constitue la troisième activité de l‟étape de

l‟analyse. Elle se situe sur la branche gauche du cycle en Y. Il s‟agit d‟une activité itérative
fortement couplée avec l‟activité de modélisation statique.
127
Nous allons commencer par décrire la dynamique de chaque cas d‟utilisation à l‟aide
des diagrammes de séquence, ensuite nous allons détailler le cycle de vie d‟objets de classes
particulières au fil de ses interactions et de son évolution propre en utilisant le diagramme
d‟état-transition.
3.1. Formaliser les scénarios :
Un scénario représente un ensemble ordonné de messages échangés par des objets.

L‟objet est évoqué ici au sens large : instance de classes d‟analyse ou instance d‟acteur.
[ROQ, 07]
Les échanges de messages entre objet peuvent être présentés en UML dans deux sortes
de diagrammes :
 Le diagramme de séquence met l‟accent sur la chronologie des envoies de

messages.
 Le diagramme de collaboration met l‟accent sur les relations structurelles entre
objets qui échangent le message.
Dans ce qui suit nous allons présenter les diagrammes de séquence afin de formaliser les
scénarios des cas d‟utilisation vus précédemment. Nous allons voir le système comme un
ensemble d‟objets en interaction. Ces objets appartiennent à 3 types de classes, à savoir les
dialogues « D », les contrôles « C », et les entités « E ».
Nous respecterons également les règles d‟interaction entre ces trois types d‟objets.
Ainsi :
- Les acteurs ne peuvent interagir qu‟avec les dialogues ;

- Les dialogues peuvent interagir avec les contrôles ;
- Les contrôles peuvent interagir avec les dialogues, les entités ou d‟autres contrôles.
Cas d’utilisation : « Rechercher une ressource »
128
Figure 50: Diagramme de séquence du CU « Rechercher une ressource »
129
Cas d’utilisation : « Réserver une ressource »
Figure 51 : Diagramme de séquence du CU « Réserver une ressource »
130
Cas d’utilisation : « Enregistrer un prêt »
Figure 52 : Diagramme de séquence du CU « Enregistrer un prêt »
131
Cas d’utilisation : « Restituer un prêt »
Figure 53 : Diagramme de séquence du CU « Restituer un prêt »
132
Cas d’utilisation : « Gérer les adaptateurs »
Figure 54 : Diagramme de séquence du CU « Gérer les adaptateurs »
Voir le Développement du modèle Dynamique en annexe page 176.
133
Voir d‟autres diagrammes de séquence en annexe « Diagrammes de séquences»
3.2. Construction des diagrammes d’état-transition :
Les diagrammes d‟états-transitions d‟UML décrivent le comportement d‟un objet à

l‟aide d‟un automate à états finis. Ils présentent les séquences possibles d‟états et d‟actions
qu‟une instance de classe peut traiter au cours de son cycle de vie en réaction à des
événements discrets.
[AUD, 08]
Dans la partie qui suit nous allons présenter les diagrammes d‟états-transitions de la classe
« Reservation_pret »
Figure 55: Diagramme d‟état-transition de la classe « Reservation_pret »
134
Commentaires :
Un objet de la classe « reservation_pret » passe par une succession d‟états durant son
existence. Voici la séquence d‟états représentant son comportement :
 Réservation active, document non prêt pour récupération :

Une réservation est crée mais la ressource n‟est pas encore prête, soit parce qu‟elle est
empruntée par un autre adhérent PEB, soit parce qu‟elle n‟est pas encore arrivée à la
bibliothèque de récupération choisie lors de la réservation (ressource en transition).
 Réservation active, document prêt pour récupération

Une réservation est crée et la ressource est prête pour être empruntée. L‟adhérent
concerné doit se présenter pour récupérer la ressource dans un délai limité sinon le
système va annuler automatiquement cette réservation.
 Réservation annulée
L‟adhérent a demandé d‟annuler sa réservation ou bien le système l‟a annulée
automatiquement à cause du dépassement du délai de récupération.
 Prêt en cours
Un adhérent s‟est présenté pour consommer une réservation, le bibliothécaire lui a
livré la ressource et a enregistré le prêt.
 Prêt terminé, document non remis

Le délai du prêt est terminé main l‟adhérent n‟a pas encore remis la ressource.
 Prêt terminé, document remis

L‟adhérent s‟est présenté pour remette la ressource alors le bibliothécaire restitue le
prêt.
135
Chapitre 8 : Conception
136
1. Conception générique :
La conception générique consiste à développer la solution qui répond aux spécifications

techniques que nous avons présentées au chapitre 4. Elle développe le squelette technique du
projet.
Cette conception est qualifiée de générique car elle est entièrement indépendante des
aspects fonctionnels spécifiés en branche gauche. Elle de formaliser, sous la forme de classes
techniques réutilisables, les règles de conception pour l‟ensemble d‟un système à développer.
1.1. Elaboration du modèle logique de conception technique :
Dans la partie analyse nous avons regroupé les classes en catégories afin de concevoir le
modèle statique, dans cette partie les classes technique seront regroupées dans des Framework
techniques afin de concevoir le modèle logique de conception technique.
Un Framework technique est un réseau de classes qui collaborent à la réalisation d‟une

responsabilité qui dépasse celle de chacune des classes qui y participent. Il ne concerne que
les responsabilités de la branche droite (technique) du processus. [ROQ, 07]
Le modèle de conception technique est organisé par packages de classes qui

représentent les Framework développés pour résoudre les problèmes purement techniques -
cet aspect purement technique fait que la conception, à ce niveau, est qualifiée de générique.
Le modèle logique est donc organisé suivant les dépendances qui s‟établissent entre
Framework techniques.
Pour la conception de notre système, nous avons pris en compte les parties présentées
dans la figure ci-après :
137
« Framework technique »
Noyau Présentation
Noyau Applicatif
« Framework technique » « Framework technique »
Noyau Accès aux données Noyau Sécurité
Noyau Authentification
Figure 56 : Organisation du modèle logique de notre système
Voir plus en détail dans l‟annexe « description des noyaux » page 17
La conception générique définit les composants nécessaires à la conception de l‟architecture

technique. Elle a pour objectif d‟uniformiser et de réutiliser les mêmes mécanismes pour tout
un système informatique et écarte la majorité des risques techniques.
2. Conception préliminaire :
La conception préliminaire est certainement l‟étape la plus délicate du processus 2TUP

car elle en représente le cœur. C‟est en effet à cette occasion que s‟effectue la fusion des
études fonctionnelles et techniques. En conséquence, plusieurs activités doivent coexister.
138
La conception préliminaire est avant tout une affaire d‟organisation ; elle s‟appuie sur
les points de vue de spécification fonctionnelle et structurelle de l‟analyse, mais également sur
les Framework de la conception technique. Elle se termine lorsque la conception est organisée
suivant son déploiement cible, son modèle d‟exploitation et son modèle logique.
2.1. Développement du modèle de déploiement :
Le déploiement d‟une solution client léger se construit sur la définition des postes de travail.
Poste de travail
Le poste de travail représente un ou plusieurs acteurs pouvant être localisés sur une machine
d‟un type particulier et remplissant une fonction identifiée dans l‟entreprise. Le poste de
travail ne représente pas forcément une machine physique, mais peut consister en plusieurs
machines, à condition qu‟elles donnent lieu au même type de déploiement. [ROQ, 07]
Figure 57 : Modèle de déploiement du système
Pour des raisons de sécurité, nous allons déployer l‟application sur le même serveur.
139
2.2. Développement du modèle d’exploitation :
Le modèle d‟exploitation va définir les applications installées sur les postes de travail, les
composants métiers déployés sur les serveurs et les instances de base de données
implémentées sur les serveurs également. [ROQ, 07]
Définition des applications :
Nous allons concevoir une seule application « Site_peb » qui réalise tous les cas d‟utilisation.
C‟est une application web qui s‟exécute à l‟aide d‟un navigateur web.
De la même façon que le diagramme des classes décrit l‟organisation de l‟architecture

logicielle d‟un système, le diagramme de composants en décrit l‟implémentation physique. Le
diagramme de composants a le rôle de définir les modules logiciels et leurs relations.
Dans notre système, la seule application citée ci-dessus donne lieu à un seul composant
métier.
« Category »
Site_peb
Figure 58 : Identification des composants métier du système
3. Conception détaillée :
La conception détaillée est la dernière phase de la modélisation avec UML. Après la

modélisation des besoins et l‟organisation de la structure de la solution, la conception
détaillée vient construire et documenter précisément les classes, les interfaces, les tables et les
méthodes qui constituent le codage de la solution. [ROQ, 07]
140
Dans ce chapitre nous allons concevoir les classes, les associations, les attributs, et les
opérations,
3.1. Concevoir les classes et les attributs :
Classe Information Code Type
Adhérent_PEB Identifiant Id_lect Char(7)

Nom Nom_lect Varchar(50)
Prénom Prenom_lect Varchar(50)
Civilité Civil_lect Enum (Mr, Mme,
Mlle)
Adresse Adr_lect Varchar(100)
Ville Ville_lect Varchar(50)
Code postal Cp_lect Int
Date de naissance Date_naiss_lect Date
Lieu de naissance Lieu_naiss_lect Varchar(50)
Numéro de téléphone Tel_lect Varchar(20)
L‟adresse email Mail_lect Varchar(80)
Date d‟inscription Date_inscrip Date
La bibliothèque mère Id_bib Char(7)
Identifiant dans la Code_lect_bib Varchar(10)
bibliothèque mère
Statut Statut_lect Enum(Etudiant,
enseignant,
employé)
Appartenance à la liste Liste_noire Enum (Oui, Non)
noire
Bibliothécaire Identifiant Id_biblio Char(7)
Nom Nom_biblio Varchar(50)
Prénom Prenom_bibio Varchar(50)
Civilité Civil_biblio Enum(Mr, Mme,
Mlle)
141
Adresse Adr_biblio Varchar(100)

Ville Ville_biblio Varchar(50)
Code postal Cp_biblio Int
Numéro de téléphone Tel_biblio Varchar(20)
Identifiant de la Id_bib Char(7)
bibliothèque mère
Utilisateur Login Login_user Varchar(50)
Mot de passe Passowrd_user Varchar(50)
Fonction Fonction_user Enum( Lecteur,
Biblio, Admin)
Identifiant selon la Identifiant_user Int
fonction
Bibliothèque Identifiant Id_bib Char(7)
Nom Nom_bib Varchar(50)
Adresse Adr_bib Varchar(100)
Ville Ville_bib Varchar(50)
Code postal Cp_bib Int
N° de téléphone Tel_bib Varchar(20)
Site web Web_bib Varchar(80)
Adresse email Mail_bib Varchar(80)
Date d‟inscription Date_inscrip_bib Date
Responsable de la Responsable Varchar(50)
bibliothèque
Informatisation Informatisation Varchar(200)
SGBD bibliothèque SBGD Varchar(50)
Format des notices Format Varchar(50)
Autorisation au prêt Autorisation Enum(Autorise,
Interdit)
Informations sur les Pret_information Texte
modalités du PEB
Nom ou adresse IP du Nom_serveur Varchar(50)
serveur
Nom de l‟utilisateur Nom_utilisateur Varchar(50)
142
Mot de passe Mot_passe Varchar(50)

Nom de la base de Base_donnees Varchar(50)
données
Prêt_réservation Code prêt Code_pret Séquentiel
Etat du prêt Etat_pret Int
Date prévue de Date_prevu_recup Date
récupération
Date réelle de Date_reelle_recup Date
récupération
Date prévue de remise Date_prevu_remise Date
Date réelle de remise Date_reelle_remise Date
Identifiant lecteur Id_lect Char(7)
bibliothèque de la Id_bib_doc Char(7)
ressource
Code de la ressource dans Code_doc_bib Varchar(20)
la bibliothèque de
possession
Code de l‟exemplaire dans Code_exp Varchar(20)
la bibliothèque de
possession
Titre ressource Titre Varchar(100)
bibliothécaire signalant le Id_sign_recup Varchar(7)
prêt
bibliothécaire signalant la Id_sign_remise Varchar(7)
remise
Transition_resso Code de la transition Code_trans Séquentiel
urce
Type de la transition Type_trans Enum(Entree,
Sortie)
bibliothèque de possession Id_bib_doc Char(7)
de la ressource
Identifiant de la ressource Id_doc Varchar(20)
dans la bibliothèque de
possession
Identifiant de l‟exemplaire Code_exp Varchar(20)
dans la bibliothèque de
possession
bibliothèque de destination Id_bib_destin Char(7)
bibliothèque d‟envoi Id_bib_source Char(7)
Date transition Date_trans Date
143
Heure transition Heure_trans Time

bibliothécaire signalant la Id_biblio Char(7)
transition
Adaptateur Identifiant id_adapt Char(7)
Code source Code_source Texte
Bibliothèque Id_bib Char(7)
Code de la fonction qu‟il Code_fonction Char(7)
interprète
Fonction Code Code_fonction Char(7)
Nom Nom_fonction Char(50)
Acquisition Code acquisition Id_acq Séquentiel
Titre ressource Titre_acq Varchar(100)
Descriptif acquisition Descriptif_acq Texte
Type acquisition Type_acq Varchar(50)
Date acquisition Date_acq Date
bibliothèque concernée Id_bib Char(7)
Evènement Code de l‟évènement Id_eve Séquentiel
Titre évènement Titre_eve Varchar(100)
Descriptif évènement Descriptif_eve Texte
Type évènement Type_eve Varchar(50)
Date évènement Date_eve DAte
Bibliothèque concernée Id_bib Char(7)
Proposition Code proposition Code_pro Séquentiel
Date proposition Date_pro Date
Texte proposition Proposition Texte
Adhérent Id_lect Char(7)
Message Code message id_msg Séquentiel
Date message date_msg Date
Heure message Heure_msg Time
144
Objet message Objet_msg Texte

Texte message Msg Texte
Etat message Etat_msg Enum( lu, non_lu)
Affichage du message Affich_msg Int
Notices_panier Code notice Code_notice Séquentiel

Titre notice Titre Varchar(100)
Date d‟ajout au panier Date_ajout Date
Bibliothèque de possession Id_bib Char(7)
Code de la ressource dans Identifiant_ds_bib Varchar(20)
la bibliothèque de
possession
Recherche Code recherche Code_rech Séquentiel
Date recherche Date_rech Date
Heure recherche Heure_rech Time
Ressource recherchée Ressource_rech Varchar(50)
Livre_dor Code signature Code_sign Séquentiel

Date signature Date_sign Date
Heure signature Heure_sign Time
Texte signature commentaire Texte
Tableau 8 : Description détaillée des classes d‟objets
3.2. Concevoir les opérations :

Le développement du modèle dynamique nous a permis d‟extraire les méthodes qui seront
ajoutées aux classes définies ci-dessus. A ce niveau, nous allons donner une image assez
145
précise du contenu des méthodes de notre projet, le tableau ci-dessous regroupe la description
des différentes méthodes.
Classe Méthode Description
Adhérent PEB Ajouter_adherent () Ajoute un adhérent

Modifier_adherent () Modifie la fiche d‟un adhérent
Supprimer_adherent () Supprime un adhérent
Rechercher_adherent () Recherche un adhérent
Lister_adherent () Liste les adhérents
Bibliothécaire Ajouter_bibliothecaire() Ajoute un bibliothécaire
Modifier_ bibliothecaire () Modifie la fiche d‟un
bibliothécaire
Supprimer_ bibliothecaire () Supprime un bibliothécaire
Rechercher_ bibliothecaire () Recherche un bibliothécaire
Lister_ bibliothecaire () Liste les bibliothécaires
Bbiliothèque Ajouter_bibliotheque () Ajoute une bibliothèque
Modifier_ bibliotheque () Modifie la fiche d‟une
bibliothèque
Supprimer_ bibliotheque () Supprime une bibliothèque
Rechercher_ bibliotheque () Recherche une bibliothèque
Lister_ bibliotheque () Liste les bibliothèques
Prêt_reservation Reserver () Réserve une ressource
Annuler_reservation () Annule une réservation
Enregistrer_pret () Enregistre un prêt
Prolonger_pret () Prolonge un prêt
Restituer_pret () Restitue un prêt
Transaction_ressource Entree_ressource () Signaler une entrée de ressource
Sortie_ressource () Signaler une sortie de ressource
Adaptateur Ajouter_adaptateur () Ajoute un adaptateur
Modifier_ adaptateur () Modifie un adaptateur
146
Supprimer_ adaptateur () Supprime un adaptateur

Rechercher_ adaptateur () Recherche un adaptateur
Lister_ adaptateur () Liste les adaptateurs
Fonction Lister_ Fonction () Affiche les fonctions adaptatrices
Acquisition Ajouter_acq () Ajoute une acquisition
Modifier_ acq () Modifie une acquisition
Supprimer_ acq () Supprime une acquisition
Evènement Ajouter_eve () Ajoute un évènement
Modifier_ eve () Modifie un évènement
Supprimer_ eve() Supprime un évènement
Lister_eve () Liste les évènements
Afficher_eve () Affiche un évènement
Proposition Ajouter_pro () Ajoute une proposition
Supprimer_pro () Supprime une proposition
Lister_pro () Liste les propositions
Afficher_pro() Affiche une proposition
Message Envoyer_message () Envoie un message
Lister_message () Liste des messages
Afficher_message () Afficher un message
Supprimer_message () Supprimer un message
Afficher_panier () Affiche le contenu du panier
Notices_panier
Ajout_notice_panier () Ajoute une notice au panier
Supprimer_notice () Supprimer une notice du panier
Vider_panier () Vider le panier
Recherche Afficher_historiq_rech () Affiche l‟historique des
recherches
Supprimer_historiq_rech () Supprimer l‟historique des
recherches
Livre_dor Signer_livre_dor () Signer le livre d‟or
147
Lister_signature () Afficher la liste des signatures

Afficher_signature () Afficher une signature
Supprimer_signature () Supprimer une signature
Vider_livre_dor () Vider le livre d‟or
Tableau 9 : Liste et description des opérations
3.3. Passage au modèle relationnel :
Nous présenterons dans ce qui suit la conception du schéma relationnel de la base de données
à partir du diagramme de classes. Pour ce faire, nous adoptons les règles de passage proposés
1
par J.RUMBAUGH .
Conversion des classes d’objets en tables : Chaque classe est représentée par une table.
Conversion des associations en tables : Elle répond par deux règles :
- Chaque association « plusieurs à plusieurs » est représentée par une table distincte,
dont la clé primaire est la concaténation des deux clés primaires des classes
concernées par l‟association.
- Pour les associations « un à plusieurs » on dispose de l‟option supplémentaire qui
consiste à ranger la clé primaire de la table père dans la table fils ; cette clé est appelée
clé étrangère.
En appliquant les règles de passage du diagramme de classes aux tables relationnelles, nous
obtenons le schéma relationnel suivant :
1
James Rumbaugh est le créateur du langage de modélisation objet OMT. Il est également l'un des
trois pères du langage UML, avec Grady Booch (fondateur du langage Booch) et Ivar Jacobson
(fondateur du langage OOSE).
148
Adhérent_PEB (Id_lect, Nom_lect, Prenom_lect, Civil_lect, Adr_lect, Ville_lect, Cp_lect,

Date_naiss_lect, Lieu_naiss_lect, Tel_lect, Mail_lect, Date_inscrip, Id_bib,
Code_lect_bib, Statut_lect, Liste_noire)
Bibliothécaire (Id_biblio, Nom_biblio, Prenom_bibio, Civil_biblio, Adr_biblio, Ville_biblio,

Cp_biblio, Tel_biblio, Id_bib)
Utilisateur (Login_user, Passowrd_user, Fonction_user, Identifiant_user)
Bibliothèque (Id_bib, Nom_bib, Adr_bib, Ville_bib, Cp_bib, Tel_bib, Web_bib, Mail_bib,

Date_inscrip_bib, Responsable, Informatisation, SBGD, Format, Autorisation,
Affichage, Pret_information, Nb_notices, Nb_exemplaires, Nom_serveur,
Nom_utilisateur, Mot_passe, Base_donnees)
Prêt_réservation (Code_pret, Etat_pret, Date_prevu_recup, Date_reelle_recup,

Date_prevu_remise, Date_reelle_remise, Id_lect, Id_bib_doc,
Code_doc_bib, Code_exp, Titre, Id_sign_recup, Id_sign_remise)
Transition_ressource (Code_trans, Type_trans, Id_bib_doc, Id_doc, Code_exp,

Id_bib_destin, Id_bib_source, Date_trans, Heure_trans, Id_biblio)
Adaptateur (id_adapt, Code_source, Id_bib, Code_fonction)
Fonction (Code_fonction, Nom_fonction)
Acquisition (Id_acq, Titre_acq, Descriptif_acq, Type_acq, Date_acq, Id_bib)
Evènement (Id_eve, Titre_eve, Descriptif_eve, Type_eve, Date_eve, Id_bib)
Proposition (Code_pro, Date_pro, Proposition, Id_lect)
Message (id_msg, date_msg, Heure_msg, Objet_msg, Msg, Etat_msg, Affich_msg, Id_lect)
Notices_panier (Code_notice, Titre, Date_ajout, Id_bib, Identifiant_ds_bib, Id_lect)
Recherche (Code_rech, Date_rech, Heure_rech, Ressource_rech, Id_lect)
Livre_dor(Code_sign, Date_sign, Heure_sign, commentaire, Id_lect)
149
Chapitre 9 : Réalisation du
prototype
150
Chapitre 9 : Réalisation du prototype
1. Introduction :
Dans la réalisation de notre application web nous avons fait appel à un ensemble d‟outils et
langages de développement. Dans ce qui suit nous tenons à présenter et argumenter nos choix.
Ensuite nous décrirons les mécanismes utilisés pour sécuriser le système contre d‟éventuelles
menaces. Et enfin, nous présenterons les différentes fonctionnalités offertes par le système
impliquant différents utilisateurs (internaute visiteur, internaute adhérent, administrateur,
bibliothécaire). Cela sera illustré par la présentation des différentes interfaces utilisateurs.
Notre choix s‟est porté sur le couple PHP/MySQL sous un serveur Apache. L‟outil développé
est présenté aux utilisateurs sous une interface web. De ce fait, tout l‟environnement de notre
application est orienté web.
2. Présentation des outils utilisés :

2.1. Apache HTTP Server 2.2.11 :
Apache http Server, souvent appelé Apache, est un logiciel de serveur HTTP produit par
l‟Apache Software Foundation. C‟est le serveur HTTP le plus populaire du web. C‟est un
logiciel libre avec un type spécifique de licence, nommée licence Apache. [Web_04]
Apache fonctionne principalement sur les systèmes d‟exploitation Windows et UNIX (Linux,
Mac OS X, Solaris, BSD et UNIX).
151
Apache est connu pour sa robustesse, pour sa rapidité à délivrer les pages web, mais la
fonctionnalité phare d‟Apache est sa facilité de configuration, il repose, en effet sur une
hiérarchie de fichiers de configuration, qui peuvent être gérés indépendamment. C‟est
notamment utile aux hébergeurs Web qui peuvent ainsi servir les sites de plusieurs clients à
l‟aide d‟un serveur http.
2.2. Langage PHP 5.3.0 :
PHP (Hypertext Preprocessor) c‟est un langage de script HTML, exécuté côté serveur. Sa
syntaxe est empruntée aux langages C, JAVA et Perl. [WEB_05], et comme tout langage
interprété, PHP requiert un interpréteur (intégré dans le serveur d‟application) nommé Zend
Engine, qui fournit toute l‟infrastructure nécessaire au fonctionnement du langage. Avant
d‟être renvoyée vers le client, la page PHP doit passer par l‟interpréteur. C‟est le serveur qui
transmet tous les fichiers avec extension « .php » vers celui-ci [WEB_06].
Les différentes raison qui ont motivé notre choix sont :
- PHP est disponible pour l‟ensemble des systèmes d‟exploitation courants : Windows
toutes versions, Linux et Unix toutes versions, IBM ISeries (AS/400), SGI IRIX 6.5.x,
RISC OS, Novell Netware, Mac OS X, Amiga OS, etc.) ; [WEB_07]
- En plus d‟être un langage complet, PHP présente un très bon support pour un
ensemble de bases de données (Oracle, Sybase, Microsoft, MySQL, Postgres, ODBC,
etc.) ;
- Support d‟un grand nombre de fonctions Web (cookies, authentification, sessions,
redirection….) ;
- Support d‟un grand nombre de librairies (LDAP, PDF, XML, GIF…) ;
- PHP est disponible sous une licence GNU/GPL, et en Open Source ;
- PHP est utilisé sur plus d‟un site Web sur trois dans le monde ce qui représente plus de
20 millions de domaines et 1 300 000 adresses IP (Source Netcraft- Novembre 2006).
Près de la moitié des serveurs Apache (40 % au 1 er Janvier 2007) fonctionnent avec
PHP [WEB_07].
152
Un langage de programmation nécessite forcément un environnement dans lequel on

désire développer une application.
Dreameaver CS4 édité par la société Adobe Systems, est l'outil leader pour le
développement web et permet de concevoir, de développer et de maintenir des applications et
des sites web du plus simple au plus sophistiqué, intégrant les technologies les plus récentes.
[WEB_08]
Dreamweaver CS4, allié au couple PHP/MySQL, est la réponse à toutes les attentes. En
effet, l‟éditeur est compatible avec les technologies serveur les plus utilisées, dont le célèbre
PHP qui est actuellement le langage de script serveur le plus employé par le Web. [WEB_09]
Nous avons utilisé Dreamweaver CS4 (septembre 2008) qui est la dernière version existante
lors du début de développement de notre solution.
2.3. La base de données MySQL 5.1.36 :
MySQL fait partie des logiciels de gestion de base de données les plus utilisés au monde,
autant par le grand public (application Web principalement) que par les professionnels, en
concurrence avec Oracle ou Microsoft SQL Server. Multi-thread et multiutilisateurs, c‟est un
logiciel libre développé sous double licence. Selon le type d‟utilisation, il fonctionne sur de
nombreux systèmes d‟exploitation différents, incluant Linux, Mac OS X, Solaris, Windows
9x, NT, XP et Vista [WEB_10]
3. Sécurité du système :
La télécommunication est un domaine qui utilise des moyens technologiques avancés
assurant une disponibilité quasi-permanente, ce qui intensifie la vulnérabilité de n‟importe
quel système d‟information en relation avec, et là, ce dernier se voie face à différents risques
qui peuvent lui porter atteintes et diverses menaces qui peuvent nuire à son bon
fonctionnement et aux intérêts de ses utilisateurs, surtout dans le cas où ce système traite des
informations de la plus grande importance et la plus majeure sensibilité.
153
A l‟instar de tout système baignant dans ces conditions, notre système est dans
l‟obligation de prendre des précautions et des mesures qui le permettront de faire face à toutes
ses menaces.
Pour assurer ces tâches indispensables en matière de sécurité, on a besoin de dénombrer

ces risques et de les classifier pour tracer un plan pour les changements à faire, les solutions à
préconiser et les dispositifs à mettre en œuvre
3.1. Facteurs de risque et mesures de sécurité :
On peut classer les différents facteurs de risque qui représente un danger pour notre système
en trois principales catégories.
3.1.1. Les accidents :
Ce sont les risques qui ne peuvent être totalement prédis et qui résultent des facteurs
d‟environnement du système et se présentant hors son utilisation causant des dommages
physiques et/ou logiques :
 Les catastrophes naturelles (séisme, incendies, …etc.)

 Défaillance des installations (câblage, matériel, … etc.)
 Pannes d‟électricité.
 Problème de disponibilité d‟internet, surtout quand il s‟agit de panne qui dépasse les
limites d‟interventions et d‟actions (au niveau des câbles internationaux par exemple).
Les mesures à prendre se résument à quelques dispositifs de prévision pour protéger le

système de ces accidents et de réduire, le plus possible, leurs dommages potentiels :
 Installer la machine serveur dans des bâtisses construites selon les normes mondiales
anti-séisme.
 Des bâtisses dotées de systèmes anti-incendie (alarmes, détecteurs de flammes et
dispositifs d‟extinction automatiques et manuels à la fois).
 Disposer de groupes électromoteurs.
 Définir une politique de sauvegarde d‟urgence (environnement logiciel interne du
système et des bases de données) se déclenchant automatiquement en cas de
catastrophe.
154
 Définir une conduite à tenir pour le personnel pour éviter les accidents, ainsi que les
étapes d‟intervention pour la protection des installations en cas de catastrophe.
 Louer les services de spécialistes en la sécurité des installations (entreprises
spécialisées, experts, conseillers, …etc.)qui peuvent préconiser et/ou effectuer la mise
en place de ses dispositifs.
3.1.2. Les erreurs :
Ce sont des risques qui peuvent survenir lors de l‟utilisation du système. Généralement
émanant des utilisateurs mêmes, elles causent essentiellement des dommages touchant
l‟intégrité des données et leur exactitude :
 Erreurs de saisie commises par les utilisateurs et faites par manque d‟attention ou
causées par des problèmes d‟ergonomie, de fatigue des bibliothécaires, d‟incommodité
des conditions de travail, …etc.
 Erreurs de manipulation et d‟exploitation par les utilisateurs comme dans
l‟accomplissement de tâches (Gestion des transitions de ressources). Celles là pouvant
être causées par l„incompréhension des notions et règles en vigueur ou manque de
maîtrise du système.
Afin d‟éviter ce genre d‟erreurs et fautes, et après prise en compte de leurs causes, on peut
adopter les recommandations suivantes :
 Entamer une période d‟essai ou une sorte de mise à l‟épreuve avant la mise en service
qui permettra d‟évaluer le système et sa stabilité et aussi de voir et détecter
d‟éventuelles défaillances ou anomalies.
 Améliorer l‟ergonomie et assurer la continuité de son évolution pour toujours. Fournir
aux utilisateurs un système qui peut être considérer comme facile à exploiter.
 Suivie permanent des connexions et de la bonne marche des transmissions nécessaires
pour le fonctionnement du système.
 Pourvoir les utilisateurs de manuels d‟aide et de support disponibles constamment
pour les accompagner durant leur exploitation du système.
 Suivie des opérations exécutées par les bibliothécaires pour diminuer le nombre
d‟erreurs commises par inadvertance ou même par manque de maîtrise.
155
 Politique de sauvegarde quotidienne.
3.1.3. Les malveillances :
Ce sont les menaces les plus dangereuses et les plus destructrices (relativement), parce
qu‟elles émanent des intentions hostiles de malveillants qui veulent volontairement nuire à la
bonne marche du système, on cite les malveillances suivantes :
 Fautes dolosives lors de l‟utilisation du système afin de compromettre l‟intégrité et

l‟exactitude des informations traitées (changer le mot de passe d‟un adhérent).
 Sabotage du matériel et des installations utilisés hébergeant l‟application et la base de
données.
 Attaques de piraterie et hacking, dirigées vers le système pour introduire des
programmes malicieux et malveillants (Ver, cheval de Troie, virus, …etc). Ces
attaques sont beaucoup probables à cause de l‟utilisation d‟internet.
Et pour prévenir de tels actes, les stopper et diminuer les dégâts qu‟ils peuvent causer, il faut
s‟orienter vers une politique de protection efficace pour le système entier :
 Restreindre l‟accès aux lieux d‟installation des serveurs et les doter de protections
contre la destruction (des codes d‟accès, portes blindées, Vidéosurveillance, …etc.).
 Restreindre l‟accès aux différentes fonctionnalités du système et tracer toutes les
opérations accomplies lors de son utilisation (profils d‟accès et système de privilèges,
système de traçabilité, historiques, …etc.).
 Munir les serveurs de Firewall et Antivirus professionnels performants.
 Suivre l‟évolution en termes de sécurité et menaces (études, veille technologique,
…etc.)
3.2. Qualités sécuritaires du nouveau système :
Le système comprend, pour assurer confidentialité, intégrité et disponibilité, les aspects

suivants pour faire face aux différentes menaces :
156
3.2.1. Confidentialité :
Etant un aspect capital du système, la confidentialité rassemble toutes les procédures qui
limitent le nombre des personnes pouvant accéder au système :
Restriction des accès : Les accès au système et ses différentes parties sont limités selon la
fonction de l‟utilisateur, ce qui est réalisé au moyen d‟un système de gestion de profils. Ces
derniers sont assignés à chaque compte utilisateur pour en déterminer les opérations lui étant
permises et les sections lui étant accessibles dans l‟application. Seul un administrateur peut
créer, modifier, suspendre un compte utilisateur. Ainsi, quand l‟utilisateur se connecte au
système, il a affaire à un nombre réduit de liens et de pages correspondant à son profil
d‟accès.
Sécurité des données : Nous citons quelques diapositifs pour la protection des données :
 la
base de données de façon quotidienne.
 Cryptage des données transmises sur internet entre l‟application et la base de données
(algorithme asymétrique SHA-256).
Sécurité de l’application : Afin de protéger le système on se tient aux indications suivantes :
 Contrôle des données et informations introduites au système lors de son exploitation

pour contrer toute tentative de sabotage ou faute dolosive ou non intensionnelle
(formes régulières, injections SQL, …etc.), cela grâce aux différentes classes de
contrôle déjà présentées.
 Munir les serveurs d‟Antivirus professionnel (mis à jour automatiquement via
internet) tel celui proposé (Kaspersky Internet Security).
3.2.2. Intégrité :
Un aspect qui ne manque pas d‟importance de la confidentialité, assurant l‟exactitude des

informations et donc par la suite des résultats justes, optimaux et lucratifs.
Gestion de la concurrence : Garantie par les différentes classes de persistance et transaction

permises au niveau de la base de données.
157
Redondance justifiée et réfléchie : Les redondances et les répétitions des données ont été
faites en se basant sur les besoins qui se sont présentés afin d‟optimiser l‟exploitation de ces
données et du système entier à la fois.
Contrôles de champs : Les champs sont contrôlés pour diminuer les fautes commises lors de
la saisie par les utilisateurs.
3.2.3. Disponibilité :
Grâce aux recommandations pour la protection des serveurs et installations en cas d‟incidents
de tout genre, données auparavant, en plus des précautions prises pour assurer la connexion à
internet (seul moyen d‟exploitation du système), on peut maintenir une disponibilité continue
et sans interruption du système.
4. Présentation du prototype réalisé :
La réalisation vient couronner les phases précédentes, donnant un aspect tangible aux objectifs
visés et une forme concrète à la conception.
Afin de présenter le prototype réalisé, on utilise des prises d‟écrans (Imp. Ecr.) pour figurer le
travail fait et illustrer les grandes et principales fonctionnalités du système.
158
Page d’accueil :
L‟utilisateur lance l‟application via un navigateur web,en tapant son URL. Une fenêtre
s‟affiche contenant la page d‟accueil du site. Elle est commune à tous les utilisateurs quelque
soit leur profil (Internaute visiteur, internaute adhérent, administrateur, bibliothécaire).
Figure 59 : Page d‟accueil du site web

159
Dans cette page, il y un petit formulaire où l‟utilisateur peut s‟identifier pour pouvoir accéder
à ses privilèges. Pour chaque type d‟utilisateur, nous allons montrer quelques maquettes qui
présentent les fonctionnalités offertes par l‟application.
1. Internaute visiteur :
L‟internaute visiteur n‟a pas à s‟identifier auprès de l‟application. Les fonctionnalités qui lui
sont offertes se restreignent dans la recherche de ressources (recherche simple et avancée) et
la découverte des notices bibliographiques. Il ne peut pas profiter du service de prêt.
Figure 60 : Recherche simple
160
Figure 61 : Résultats d‟une recherche de ressource
161
Figure 62 : Espace visiteur « Fiche descriptive d‟une notice bibliographique »
2. Internaute adhérent :
L‟internaute adhérent, en plus de la recherche et la consultation des ressources, peut profiter

du service de prêt entre bibliothèques.
Figure 63 : Espace adhérent « Fiche descriptive d‟une notice bibliographique »

162
Figure 64 : Demande de prêt PEB
3. Administrateur
Lorsque l‟administrateur s‟identifie dans le formulaire qui se trouve dans la page d‟accueil, le
module d‟administration apparaît à droite toujours dans la même page. En cliquant sur
« Administrateur » le système lui affiche le module de gestion.
Figure 65 : Page d‟accueil après authentification de l‟administrateur
163
Figure 66 : Espace Administrateur
Figure 67 : Espace Administrateur « Gestion des bibliothèques »
164
Figure 68 : Espace Administrateur « Gestion des bibliothécaires »
Figure 69 : Espace Administrateur « Gestion des adhérents du PEB »
4. Bibliothécaire :
De même que pour l‟administrateur, le bibliothécaire s‟identifie alors le système lui affiche un
lien qui lui envoie vers son espace de gestion. Le bibliothécaire a comme fonctions
principales : enregistrer les prêts et restitutions et signaler les transitions de ressources entre
bibliothèques.
165
Figure 70 : Page d‟accueil après authentification du bibliothécaire
Figure 71 : Espace Bibliothécaire
166
Figure 72 : Espace Bibliothécaire « Liste des réservations d‟un adhérent »
Figure 73 : Espace Bibliothécaire « Enregistrer un prêt »
167
Figure 74 : Espace Bibliothécaire « Liste des prêts en cours d‟un adhérent »
Figure 75: Espace Bibliothécaire « enregistrer une entrée de ressource »
168
Figure 76 : Espace Bibliothécaire « enregistrer une sortie de ressource »
169
Conclusion générale
Conclusion générale :
1. Conclusion :
Notre travail avait pour principal objectif l‟automatisation du service PEB dans un
réseau de bibliothèques, via l‟automatisation du traitement des réservations. La bibliothèque
initiale de l‟adhérent PEB n‟aura pas à jouer le rôle de l‟intermédiaire entre ce dernier et la
bibliothèque prêteuse en traitant la demande ou en l‟envoyant, sous forme écrite ou autre, à la
bibliothèque concernée pour que cette dernière, à son tour, étudie la possibilité de l‟emprunt.
Tout cela sera traité par notre système qui s‟occupera de vérifier l‟état de la ressource
demandée (disponibilité ou non disponibilité) ainsi que l‟acceptation de l‟adhèrent (adhèrent
n‟appartenant pas à la liste noire ou n‟ayant pas dépassé le nombre permis de réservation…).
Pour réaliser un tel travail, nous avons développé un site web muni d‟un catalogue
collectif en temps réel, où n‟importe quel internaute peut effectuer une recherche (simple ou
avancée) d‟un document donné et visualiser la notice bibliographique correspondante. Seuls
les adhérents inscrits au préalable, au service PEB peuvent profiter du fond documentaire du
catalogue PEB, en faisant une réservation en ligne de n‟importe quelle ressource PEB
disponible. Ceci étant complété par d‟autres services permettant d‟améliorer l‟utilisation du
site (Proposer une ressource pour acquisition, signer le livre d‟or, l‟aide en ligne, l‟annuaire
des bibliothèques…). Et pour un plus grand partage et bénéfice du fond documentaire des
bibliothèques du réseau, nous avons proposé les rubriques « Les acquisitions récentes » et
« Les événements » pour encourager les lecteurs à participer aux propositions de ressources et
à assister aux activités des bibliothèques ouvertes au grand public.
Notre site web n‟est pas adressé uniquement aux adhérent PEB mais aussi aux
bibliothécaires. En effet, en ouvrant leurs sessions (login/ mot de passe), ils accèdent à un
menu principal pour la gestion du service PEB : Inscrire des adhérent PEB, signaler les
entrées/ sorties des ressources, effectuer une réservation PEB, sur place, à la demande de
l‟adhérent…). Ils bénéficient aussi d‟une aide en ligne pour une meilleure utilisation du site.
170
L‟administrateur, à son tour, après s‟être connecté en tant que tel, peut gérer son site web:
- Ajouter ou éliminer une bibliothèque du réseau PEB et, par conséquent, ajouter ou
supprimer l‟adaptateur correspondant.
- Suivre n‟importe quelle opération PEB et garder traces des mains réceptrices et
émettrices des colis de ressources errants à travers le réseau.
- Consulter les erreurs et imprévus détectés et les traiter.
- Gérer les diffusions du site.
- Prévenir les bibliothèques des résultats des statistiques PEB et des propositions de
leurs adhérents et donc, orienter leurs choix par rapport aux exigences des lecteurs…
Nous avons opté pour une architecture de médiation. Cette méthode est utilisée, uniquement,
pour une lecture dans les bases de données intégrées. Nous avons donc proposé une solution
personnalisée qui, bénéficiant des avantages de médiation, offre en plus la possibilité de mise
à jour en temps réel, autrement dit, permettre aussi l‟écriture.
2. Perspectives :
 Certes, nous avons automatisé les réservations PEB mais le passage des ressources par les
mains de fonctionnaire (bibliothécaire, facteur, agent de transport…) est obligatoire avant
d‟atterrir enfin entre les mains du demandeur. Ainsi, le temps écoulé entre une réservation
et la réception effective du document par l‟adhérent peut varier par rapport au trajet que
fait la ressource en voyageant à travers quelques rues ou quelques villes pour arriver à
destination avec, toutefois, des risques de retard inacceptables par un lecteur voulant avoir
une information donnée dans un temps limité. On peut éviter cela en proposant la
documentation électronique comme une option de choix pour le demandeur lors de sa
réservation si, toutefois, ceci reste possible. De la sorte, l‟opération sera à cent pour cent
automatisée et fera gagner un temps précieux pour un adhérent ne préférant pas une
version matérielle du document.
 Nous n‟avons parlé que brièvement de la norme Z39.50 qui est une norme dédiée à la
recherche en lecture. En effet, elle permet de faire une recherche simultanée dans
171
différentes bases de données pour, enfin, afficher les résultats. Dans notre travail, on a
réalisé la recherche en lecture plus l‟écriture (mise à jour) sur les bases de données des
bibliothèques du réseau. Il serait intéressant d‟intégrer une telle norme dans notre
application, ceci pouvant même être un projet de fin d‟études pour ingénieurs.
 Dans un environnement PEB, nous nous sommes penchés sur l‟automatisation de la

réservation. On n‟a pas traité le transport ou les modalités de paiement. Dans ce cadre ci,
nous proposons une gestion des paiements en ligne des adhérents demandeurs d‟une
ressource donnée. On peut aussi imaginer un service gérable de transport PEB.
 Dans notre solution nous avons aussi supposé qu‟une bibliothèque, voulant adhérer à notre
service PEB, devra réaliser son propre adaptateur que nous intégrerons, par la suite, dans
notre application.
On peut imaginer aussi un logiciel qui s‟occupera de cette tâche : il aura, en entrée, le
schéma de la base de données de la bibliothèque à intégrer plus le schéma global de
médiation (que nous avons proposé) et, en sortie, il élaborera un adaptateur prêt à être
utiliser.
 Dans un service PEB, ou accèdentà divers BDDR d‟innombrables adhérents, dont la
plupart consultent la disponibilité des ressources et procède à des réservations en accédant,
une gestion des concurrences et des transactions s‟avère nécessaire. La gestion de la
répartition des données est une importante perspèctive
172
Bibliographie
Bibliographie :
[ASS, 07]: Asselgou Mouloud, Semaoune Nabil « Interrogation des entrepôts de ressources
pédagogiques hétérogènes » ,2007 :2008
[AUD, 08] : L.Audibert « UML2 », Institut universitaire de technologie de Villetaneuse

édition 2008
[BUN, 97]: P.Buneman, L.Raschid et J.D.Ulman, «Mediators Languages – a Proposal for a

Standard ». SIGMOD Record 1997
[CLU, 98]: Sophie Cluet , Claude Delobel, Jérôme Siméon et Katarzyna Smaga, «Your
Mediators need Data Conversion! », In International Conference on
Management of Data ACM SIGMOD, Seattle, 1998.
[DAT, 87]: C. J. Date, « Twelve Rules for a distributed Database », Computer World 2 (23)
p.77-81 1987.
[DES, 05] : Y. Desrichard, « Cours sur les outils collectifs des bibliothèques françaises et
étrangères», Médiadix, Mai 2005
[DIG, 01] : Frédéric Di Gallo « Méthodologie des systèmes d‟information-UML », 2001
[FEN, 08] : Pierre Fénart, « Le PEB en France et à l‟UNS », Janvier 2008.
[FER, 04] : Ferrara, « Introduction aux bases de données réparties », Résumé du cours «
Bases de données distribuées » donné dans le cadre du module « Base de
données II », University of applied sciences of western switzerland, school of
business administration Neuchâtel, 2004.
[FRE, 05] : Valéry-Guilhem Fremaux « Le projet informatique de A à Z ». Ed : Ellipse 2005,

1ère édition
[GAR, 91] : Georges Gardarin et P.Valduriez « SGBD avancés « base de données objet,
déductives, réparties », EYROLLES, 1991 (2ème édition).
173
Bibliographie
[GIO, 92]: Wiederhold Gio. « Mediators in the Architecture of Future Information Systems »
IEEE Computer, 25(3):38-49, March 1992.
[JAM, 98] : Jambert Sandrine, « Réorganisation du service du PEB avec l'implantation du

logiciel Pebnet à la bibliothèque interuniversitaire des langues orientales ».
Villeurbanne : Institut de formation des bibliothécaires, 1998.
[MOU, 07] : Moussa Rim, « Systèmes de Gestion de Bases de Données Réparties &
Mécanismes de Répartition avec Oracle », Ecole Supérieure de Technologie et
d‟Informatique à Carthage, Année Universitaire, 2006-2007.
[REY, 00] : Christophe Rey. « Interopérabilité de sources d‟informations hétérogènes,

Approche par médiation ». 2000.
[ROQ, 07] : Pascal Roques et Franck Vallée « UML 2 en action, De l‟analyse des besoins à
la conception » EYROLLES 4e édition, 2007
[ROU, 02] : M.-C. Rousset, A. Bidault, C. Froidevaux, H. Gagliardi, F. Goasdoué, C.

Reynaud, B. Safar. «Construction de médiateurs pour intégrer des sources
d‟informations multiples et hétérogènes : le projet PICSEL », Université de
Paris-Sud. 2002.
[VOD, 03] : Dan Vodislav, «Intégration de données et XML », 2003.
[WIE, 92]: G.Wiederhold, « Mediators in the architecture of future information systems »

IEEE computers, 25(3), p 38-49, March 1992.
174
Webographie
Webographie :
[WEB_01] : http://bbf.enssib.fr/consulter/bbf-1991-01-0025-004.pdf
[WEB_02] : http://libd.isnetne.ch/cours/DistributionReplication/Ferrara/Base de donnees

II.htm
[WEB_03]: http://www.gtdownload.com/fr/libre-telechargez/Developpement-
categorie/Outils-D-Aide-souscategorie/Visual-Paradigm-for-UML-Professional-
Edition-for-Windows-details-de-vue.html
[Web_04] : http://fr.wikipedia.org/wiki/Apache_HTTP_Server
[WEB_05] : http://www.php.net/manual/fr/preface.php
[WEB_06] : http://fr.wikipedia.org/wiki/Php
[WEB_07] : www.afup.org
[WEB_08] : http://www.str.fr/UNIVERS-ADOBE-MACROMEDIA-
DREAMWEAVER.aspx
[WEB_09] : http://www.numilog.com/package/extraits_pdf/e270474.pdf
[WEB_10] : http://fr.wikipedia.org/wiki/Mysql
[WEB_11] : http://fr.wikipedia.org/wiki/Dublin_Core
175
Annexes
Annexes :
1. Diagrammes de séquences :
Cas d’utilisation : « S’authentifier »
Figure 77 : Diagramme de séquence du CU « S‟authentifier »
Cas d’utilisation : « Gérer les bibliothèques »
176
Annexes
Figure 78 : Diagramme de séquence du CU « Gérer les bibliothèques »
Cas d’utilisation : « Enregistrer une transition de ressource »
177
Annexes
Figure 79 : Diagramme de séquence du CU « Enregistrer une transition de ressource »
2. Description des noyaux :
Noyau Présentation : Il définit les classes, les interfaces et les mécanismes de base pour
réaliser l‟affichage des objets manipulés par les utilisateurs.
178
Annexes
Figure 80 : Diagramme de classes du noyau « Présentation »
Noyau Applicatif : Il charge les modèles de fonctionnement et contrôle les commandes de

l‟application.
Figure 81 : Diagramme de classes du noyau « Applicatif »
Noyau Sécurité : Se sont les stratégies de contrôle et d‟authentification nécessaires pour la

protection du système. Il est composé de deux niveaux.
 La sécurité côté SGBD apporte une meilleure gestion du système ; chaque utilisateur
reçoit un ensemble de privilèges se rapportant à l‟exploitation du système.
 La sécurité côté applicatif est assurée par la définition de comptes (login/password)

pour tous les utilisateurs du système.
179
Annexes
Figure 82 : Diagramme de classes du noyau « Sécurité »
Noyau Accès aux données : Ce noyau regroupe les mécanismes de stockage, de

chargement, de mise à jour et de recherche des objets dans la base de données. Dans notre
système, chaque utilisateur possède sa propre session.
Figure 83 : Diagramme de classes du noyau « Accès aux données »
Noyau Authentification : Il permet de vérifier les coordonnées d‟un utilisateur désirant

se connecter au système. Selon le profil et le statut d‟un utilisateur, ce dernier est orienté vers
la page d‟accueil correspondante.
Figure 84 : Diagramme de classes du noyau « Authentification »
180
Annexes
3. Diagramme des classes des bases de données des

bibliothèques :
Nous proposons dans ce qui suit le schéma logique de deux bibliothèques différentes sur
lesquelles notre application va inter opérer.
Base de données « BIB_1 »
Figure 85 : Diagramme des classes « base de données BIB_1 »
181
Annexes
Base de données « BIB_2»
Figure 86 : Diagramme des classes « base de données BIB_2 »
182
Annexes
4. Eemples d’adaptateurs :
Les scripts ci-dessous représentent la fonction qui vérifie la disponibilité de
la ressource, dans les deux schémas précédents :
Adaptateur de la bibliothèque 1:
<?php
function dispo1($id_doc) {
$query_exp= sprintf("SELECT COUNT(code_ouvrage) FROM exemplaire
WHERE exemplaire.code_ouvrage='".$id_doc."' and etat_exemp='en
service' ");
$exp= mysql_query($query_exp) or die(mysql_error());
$row_exp= mysql_fetch_assoc($exp);
$nb_exp=$row_exp['COUNT(code_ouvrage)'];
$query_reserv= sprintf("SELECT count(code_ouvrage) FROM reserve
WHERE code_ouvrage='".$id_doc."' and etat_reserv='1' " );
$reserv= mysql_query($query_reserv) or die(mysql_error());
$row_reserv= mysql_fetch_assoc($reserv);
$nb_reserv=$row_reserv['count(code_ouvrage)'];
$query_pret= sprintf("SELECT COUNT(exemplaire.code_ouvrage) FROM
emprunte,exemplaire WHERE exemplaire.code_ouvrage='".$id_doc."' AND
emprunte.etat_pret='encours' and
exemplaire.code_exemp=emprunte.code_exemp" );
$pret= mysql_query($query_pret) or die(mysql_error());
$row_pret= mysql_fetch_assoc($pret);
$nb_pret=$row_pret['COUNT(exemplaire.code_ouvrage)'];
$nb_utilise=$nb_reserv+$nb_pret;
183
Annexes
if ($nb_exp <= $nb_utilise) { $disp='false' ; }

else {$disp='true' ;}
return $disp;}
$dispo='dispo1';
?>
Adaptateur de la bibliothèque 2 :
<?php
function dispo2($id_doc) {
$query_exp= sprintf("SELECT COUNT(exemplaire.code_ouv) FROM
exemplaire,ouvrage WHERE exemplaire.code_ouv='".$id_doc."' and
exemplaire.code_ouv=ouvrage.code_ouv and exemplaire.disponible='oui' ");
$exp= mysql_query($query_exp) or die(mysql_error());
$row_exp= mysql_fetch_assoc($exp);
$nb_exp=$row_exp['COUNT(exemplaire.code_ouv)'];
if ($nb_exp > 0) { $disp='true' ; }
else {$disp='false' ;}
return $disp;}
$dispo='dispo2';
?>
5. Le dublin Core : [WEB_11] :
Le Dublin Core est un schéma de métadonnées générique qui permet de décrire des
ressources numériques ou physiques et d‟établir des relations avec d'autres ressources. Il
comprend officiellement 15 éléments de description formels (titre, créateur, éditeur),
intellectuels (sujet, description, langue, …) et relatifs à la propriété intellectuelle.
Le Dublin Core fait l'objet de la norme internationale ISO 15836, disponible en anglais
et en français depuis 2003. Il est employé par l'Organisation mondiale de la santé, ainsi que
d'autres organisations intergouvernementales.
184
Annexes
Le Dublin Core tire son nom d'un groupe de travail qui s'est réuni en 1995, dans la ville
de Dublin, dans l'État américain de l'Ohio, pour définir un tronc commun d'éléments utilisable
par le gouvernement américain pour la description des ressources numériques dans les
registres de métadonnées officiels (défense, justice…)
Le groupe de travail de mars 1995 a été commandité par l'Online Computer Library
Center (OCLC) et le National Center for Supercomputing Applications (NCSA). Il a
rassemblé 52 chercheurs et professionnels des bibliothèques, de l'informatique, de l'encodage
de textes, pour faire avancer l'état de l'art dans le développement des enregistrements de
description de ressources (ou métadonnées) pour les objets informatiques en réseau.
Les éléments sémantiques du Dublin Core ont été et sont encore discutés et maintenus
par un groupe de travail international, pluri disciplinaire, et réunissant des bibliothécaires, des
informaticiens, des spécialistes de l‟édition ou des musées, chercheurs ou praticiens issus
d‟organisations publiques ou privées.
Le tableau suivant regroupe les 15 éléments du Dublin Core
185
Annexes
Elément Description
1. Titre Titre principal du document
2. Créateur Nom de la personne, de l'organisation ou du service à l'origine de la
rédaction du document
3. Sujet ou mots Mots-clefs, phrases de résumé, ou codes de classement

clés
4. Description Résumé, table des matières, ou texte libre. Raffinements : table des
matières, résumé
5. Éditeur Nom de la personne, de l'organisation ou du service à l'origine de la
publication du document
6. Contributeur Nom d'une personne, d'une organisation ou d'un service qui

contribue ou a contribué à l'élaboration du document. Chaque
contributeur fait l'objet d'un élément Contributor séparé
7. Date Date d'un évènement dans le cycle de vie du document
8. Type de Genre du contenu

ressource
9. Format Type MIME, ou format physique du document
10. Identifiant de la Identificateur non ambigu : il est recommandé d'utiliser un système

ressource de référencement précis, afin que l'identifiant soit unique au sein du
site, par exemple les URI ou les numéros ISBN.
11. Source Ressource dont dérive le document : le document peut découler en

totalité ou en partie de la ressource en question. Il est recommandé
d'utiliser une dénomination formelle des ressources, par exemple
leur URI
12. Langue langage de la ressource
13. Relation Lien avec d'autres ressources. De nombreux raffinements permettent

d'établir des liens précis, par exemple de version, de chapitres, de
standard, etc.
14. Couverture Couverture spatiale (point géographique, pays, régions, noms de

lieux) ou temporelle
15. Droits Droits de propriété intellectuelle, Copyright, droits de propriété

divers
Tableau 10: Les attributs du Dublin Core

186

Zendaoui Drici

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Zendaoui Drici

Cargado por

Copyright:

Formatos disponibles

Mémoire de fin d’études

Pour l’obtention du diplôme d’Ingénieur d’Etat en Informatique

Réalisé par Encadrées par

Soutenu le : 30 septembre 2010

Aucune bibliothèque ne peut se prétendre aujourd‟hui à l‟autosuffisance et proposer au

Les bibliothèques sont distantes, autonomes et dotées de systèmes de gestion différents.

Prêt entre bibliothèques, réseaux de bibliothèques, bases de données réparties, architecture de

Nous souhaitons manifester nos sincères remerciements à Dieu le tout puissant

Nous exprimons toute notre gratitude pour Nos Promoteurs, Monsieur

Fairouz & Cherifa

A mes gentilles et sympathiques sœurs Nesrine et Yasmine,

A toute ma famille et à ma belle famille,

A tous ceux que j’aime et qui m’aiment

Je dédie ce modeste travail.

A mon camarade, ami, professeur et père Farid qui m’a continuellement

A mon cher frère Fayçal et ma merveilleuse sœur Imèn,

A ceux qui me connaissent et croient en moi et que je n’ai pas cité

A tous ceux-là je dédie ce modeste travail.

Partie 1 : Etat de l’art 17

Chapitre 1 : Le prêt entre bibliothèques (PEB) 18

Chapitre 2 : Bases de données réparties et médiation 37

Partie 2 : Conception et mise en œuvre 50

Méthode d‟analyse et de conception 51

Chapitre 3 : Proposition de la solution 56

Chapitre 4 : Etude préliminaire 68

Chapitre 5 : Capture des besoins fonctionnels 84

Chapitre 6 : Capture des besoins techniques 113

Chapitre 7 : Analyse 121

Chapitre 8 : Conception 136

Conclusion générale 170

Figure 1 : Exemple de base de données réparties 39

Liste des tableaux :

Tableau 1 : Comparaison de l‟approche objet et l‟approche fonctionnelle 51

On assiste depuis quelques années à l‟émergence de nouvelles applications qui ont

Le regroupement en réseaux et la constitution des catalogues collectifs, ont conduit au

Dans ce contexte, les systèmes d‟informations des bibliothèques, conçus et développés

Partie 1 : Etat de l‟art

Cette partie constitue l‟aspect théorique du mémoire. Elle inclut 2 chapitres :

Partie 2 : Conception et mise en œuvre

Cette partie représente l‟aspect pratique du mémoire. Nous présenterons en premier la

Chapitre 3 : Ce chapitre est consacré à la présentation générale de la solution proposée. A

Le prêt entre bibliothèques

A cet accroissement des ressources heureusement correspond un accroissement de leur

Le PEB est rendu possible grâce à deux outils :

- et les répertoires de bibliothèques qui identifient celles-ci et présentent leurs

prétendre aujourd'hui à l'autosuffisance et proposer au niveau local l'exhaustivité des

3. Gestion de la demande de prêt :

IL existe trois principaux éléments qui permettent l‟organisation et la gestion du PEB. :

L‟identification du demandeur ainsi que la collecte d‟information au sujet de ce dernier

L‟autorisation d'émission directe dans le système de demandes émanant d'usagers

Pour le bon fonctionnement du PEB, il importe que le document demandé soit

A chaque demande de document correspond un ou plusieurs fournisseurs potentiels,

3.2. Les outils : [DES, 05]

4. Transmission du document : [DES, 05]

Le support de substitution le plus couramment utilisé jusqu'à présent reste la

4.2. Mode de Transmission :

5. Tarification et statistiques : [DES, 05]

6. Services : [DES, 05]

Issu d'une initiative du Ministère allemand de l'éducation et de la recherche et des

6.3. Catalogue Collectif Suisse :

Le Catalogue Collectif Suisse (CCS) coordonne le prêt entre bibliothèques en Suisse

Le catalogue collectif des monographies est un catalogue sur fiches entièrement

bibliographique si nécessaire. Sur demande, le CCS indique également une adresse de