Mémoire de projet 3I
Gestion documentaire & moteurs de recherches
version 1.1
Marc DEXET & Olivier GOSSE-GARDET
Table des matières
Présentation et analyse
1. Introduction
L'information est une matière première. C'est un fait. Elle
est devenue une ressource vitale au même titre que le charbon lors de
la révolution industrielle. Les systèmes d'information ont de
nos jours une importance incontournable. Nous manipulons aujourd'hui de telle
quantités d'informations qu'eux seuls peuvent traiter, croiser et enregistrer.
L'information est pourtant une notion difficile à cerner. Selon Shannon,
elle peut se résumer à une mesure de probabilité de transmettre
un événement sans s'intéresser à sa signification.
Cette définition est toutefois trop spécialisée. Une
information est une chose immatérielle, dont la qualité peut
s'évaluer sur de multiples échelles : la rareté, l'intérêt,
la pertinence... . Elle se décompose néanmoins à minima
en deux parties : son contenu et son contenant.
Le contenu est une connaissance, plus ou moins sémantiquement définie,
allant d'une valeur numérique comme une mesure physique à l'expression
d'une idée comme un article de loi pénale. Il possède
une valeur, dépendant notamment de la confiance que l'on y place, et
une durée de vie, qui va de l'ordre de l'heure pour une cotation boursière
a celui d'une génération pour un article de la constitution
d'un état. Le contenant est un support dont la stabilité, l'identification
et la pérennité sont très variables. Cela va de la parole
à un stockage sur disque magnétique. Cela comprend aussi la
mise en forme et la structuration. Contenu et contenant sont relativement
indépendant dans la mesure où un contenu peut être placé
sur plusieurs supports sous divers aspects, et un contenant supporter plusieurs
type de contenus différents.
La combinaison des deux représente un coût pour la compréhension
et la manipulation de l'information. Un contenant inadapté peut gêner
l'appréhension de son contenu: Des données démographiques
s'assimilent plus aisément sous forme graphique que textuelle. La perception
d'une information dépend aussi de l'acteur qui va en prendre connaissance
et de la motivation qui l'a amené à chercher et obtenir cette
information. Suivant l'histoire de l'individu, son approche et la signification
qu'il va y trouver seront différentes. Une information s'adresse en
effet à quelqu'un qui possède les moyens de la saisir et peut
avoir un intérêt à l'obtenir. Sa motivation est aussi
très importante. S'agit il d'une information stratégique ou
d'une simple connaissance glanée au passage ? Les besoins en détails
sur la source et la confiance que l'on peut y associer ne sont pas les mêmes.
Enfin la mise en forme et le choix du support peuvent optimiser ou au contraire
rendre difficile l'accès et la compréhension de l'information.
Mais aussi son expression, gênant sa génération ou nuisant
à sa qualité. Si l'auteur utilise ses disponibilités
à gérer le contenant plutôt que le contenu, l'acuité
avec laquelle il peut le produire est dégradé. La conséquence
est que nombre d'informations issues d'un processus mental, d'une réflexion
ou d'une observation ne peuvent être aisément produites et consultées
dans un cadre rigoureux et figé.
Les hommes n'ont pas attendu l'avènement de l'informatique pour stocker,
transmettre ou partager de l'information. Depuis que l'écriture existe,
elle est mise sous forme de documents, placés sur des supports minéraux
ou végétaux et dernièrement électroniques dans
des formats variés. Cette information, à la structure libre
et arbitraire possède l'avantage d'être facilement et rapidement
interprétable par l'être humain, car générée
et formalisée par un autre humain. C'est la manière la plus
rapide à mettre en place et exploiter. Dans les faits, la principale
partie de l'information à haute valeur d'une structure économique
ou sociale est faite de documents : rapports, notes et circulaires, propositions
commerciales ou manuels... Ils représentent souvent une synthèse
de connaissances ou un état de réflexion qui serait extrêmement
difficile et laborieux de formaliser. Cette somme de documents possède
pourtant l'inconvénient de noyer l'information. Difficile et rigide
est sa classification, sa localisation et son accès. Il suffit de constater
le lourd travail des documentalistes et des archivistes pour s'en rendre compte.
L'inertie des systèmes de classification , tel celui de Dewey ou la
Classification Décimale Universelle est handicapante et ils reposent
de plus sur une hiérarchie à priori nécessitant régulièrement
une reconsidération de l'ensemble documentaire sous peine de devenir
obsolète et inefficace.
Désormais la gestion des ensembles documentaires prend une place stratégique
dans les entreprises. Les "Knowledge management", "Documentation
Management" et autres "Information Management" sont de plus
en plus perçus comme des nécessités incontournables.
Les spécialistes et les professionnels s'aident désormais de
systèmes d'informations. Les capacités des outils informatiques
actuels imposent presque un nouvel élément qui révolutionne
l'accès au document : c'est le "moteur de recherche". La
recherche de l'information est en quelque sorte le nerf de la guerre. Tout
les efforts des documentalistes et des archivistes tendent à faciliter
cet accès à l'information. Et les technologie des moteurs de
recherche font naître en eux les plus grands espoirs et s'avèrent
devenir à la fois un champ de recherche prometteur et stratégique.
Le projet que nous allons vous présenter dans ce mémoire
s'articule autour de ces deux concepts: gestion documentaire et moteur de
recherches. Comment, avec quels moyens, en interaction avec qui et selon quelles
règles ? C'est ce que nous allons tenter de comprendre et d'élaborer.
Nous nous intéresserons principalement à son accès, sa
génération et sa maintenance.
2. Gestion de l'information : le modèle de
l'OIT (Office of Information Technology)
Une source intéressante sur la gestion des documents est le guide
de la gestion et des technologies de l'information des agences gouvernementales
australiennes.
L'OIT a défini un Cadre de travail de Gestion de l'information (Information
Management Framework) auquel les agences gouvernementales doivent se plier
. Nous pouvons en extrapoler des caractéristiques qui s'appliquent
à toute entité collective ou économiques.
2.1 Cycle de vie d'un document
Le cycle de vie d'un document décrit est le suivant :
On distingue cinq phases :
- La collecte des informations (COLLECTION)
- Le stockage des informations (STORAGE)
- L'accès aux informations (ACCESS)
- l'utilisation des informations (USE)
- la mise à disposition , conservation ou destruction des informations
(DISPOSAL)
2.1.1 La collecte
Cette phase correspond à la création, l'acquisition ou la saisie
d'information dans le but d'aider aux processus de l'entité.
Les documents sont créés par le travail de l'entité,
les bibliothèques acquièrent des documents qu'elles ajoutent
à leur collection, des données sont saisies et stockées
par des systèmes d'informations et les acteurs de l'entités,
des articles sont soumis pour publication.
Cette phase est un passage obligé pour toute information et n'est pas
définitive : les documents peuvent être modifiés, les
base de données mises à jour et publications revues et corrigées.
2.1.2 Le stockage
Le stockage est la phase qui vise à sauvegarder l'information sur
un support et la catégoriser. Le document doit être classé,
évalué, et catalogué. Remarquons que les documents au
format électroniques doivent bénéficier d'une politique
de sauvegarde de façon à être restaurés en cas
de problème.
2.1.3 L'accès
L'accès implique trois activités : la recherche de l'information
, la localisation du contenant et sa remise au demandeur.
2.1.4 L'utilisation
Les possibilités d'utilisation sont vastes : cela va de la prise de
décision basée sur le contenu d'un document au traitement et
à l'analyse des informations du document. Elle est propre à
la volonté de l'utilisateur.
2.1.5 La mise à disposition, conservation
ou destruction des informations
Les informations viennent à un moment ou un autre à ne plus
être utiles à leurs utilisateurs. Leur temps de vie est écoulé.
Plusieurs voies sont alors possibles : la destruction pure et simple ou l'archivage.
Remarquons que l'archivage est une question cruciale pour certaines entités
notamment gouvernementales. Il peut y avoir des obligations légales
sous jacentes.
2.2 Répartition des responsabilités
associées selon l'OIT.
La gestion réelle de l'information repose sur un ensemble de responsabilité
et d'actions associées.
Ce graphique les résume :
Au niveau des responsabilité nous pouvons en distinguer cinq.
- La gestion de la définition (ou évaluation) des informations
- La gestion de la propriété de l'information
- La gestion de la sensibilité de l'information
- la gestion de l'accessibilité de l'information
- la gestion de la qualité de l'information
2.2.1 La gestion de la
définition
Cette responsabilité porte sur la définition, la classification
et la description de l'information et de son support.
Elle est en charge de maintenir l'inventaire afin de savoir exactement quelles
informations sont en possession de l'entité.
Elle procède à la classification des documents afin de les évaluer
et permettre leur regroupement dans le but d'améliorer en temps et
en aisance l'accès à l'information et faciliter les analyses.
2.2.2 la gestion de la
propriété
Trois domaines d'actions sont regroupés : le gardiennage, la propriété
intellectuelle, les obligations en cas de dommages.
Il faut désigner à l'intérieur de l'entité qui
est responsable du gardiennage des documents. Définir exactement la
portée de ses droits et devoirs sur les informations vis à vis
des propriétaires ou auteurs de l'information. Peut'il se permettre
de les modifier, les détruire avec ou sans l'accord des propriétaires
? C'est une question vitale dans le cas de documents à valeur légale
ou contractuels.
Il faut gérer la propriété intellectuelle et son respect.
Enfin il faut établir quelles sont les responsabilités en cas
de dommage liés à la perte ou l'endommagement d'information
subis par les utilisateurs des documents. De même, ce dernier point
est d'une importance cruciale dans le cas de documents légaux ou débouchant
sur des actions en justice. Entre parenthèses, nous pouvons avoir une
idée des conséquences en observant le débat juridique
en France cherchant à déterminer la responsabilité des
hébergeurs de site par rapport aux informations hébergées.
2.2.3 La gestion de
la sensibilité de l'information.
Son objectif est de protéger la vie privée et la confidentialité.
Il faut déterminer quelle information présente un caractère
sensible, et gérer des habilitations d'accès. C'est particulièrement
important dans le modèle de l'OTI puisque qu'il s'adresse à
des agences gouvernementales, par définition occupées à
administrer les citoyens. Nous pensons notamment aux services de justices
et de santé. Mais cela peut tout à fait s'étendre au
cas d'une entreprise privée dont par exemple les ressources humaines
ont des obligations de non-divulgation d'informations ou pour des documents
stratégiques comme des résultats de recherche et des dépôts
de futurs brevets.
2.2.4 La gestion de la qualité
de l'information
Déterminer si une information est valide, digne de confiance , pertinente
et complète afin qu'elle puisse répondre aux besoins de ses
utilisateurs.
Il faut aussi veiller à son intégrité. Cela signifie
qu'il faut pouvoir savoir si l'information obtenue a été dégradée,
altérée par divers processus ou si elle est fidèle à
son état d'origine. Le fait d'être en possession d'une information
sans pouvoir juger de sa qualité est pénalisant, surtout si
une décision stratégique doit en découler.
2.2.5 La gestion de l'accessibilité
Sa responsabilité est de mettre en oeuvre les moyens d'accèder
à l'information et s'assurer que toute information utilisée
est couverte par une licence. Cela repose sur l'indexation des informations
disponibles par contenu ou sujet. Une indexation adéquate et consistante
assure que seule la partie d'information demandée sera retournée
suite à une demande, évitant la surcharge de sources documentaires.
La partie droit d'utilisation comprend la mise en place d'une politique systématique
de stipulation pour chaque information des droits et devoirs, notamment royalties,
dont est redevable toute utilisateur.
2.3 Conclusion sur le modèle de l'OTI.
Ce modèle, bien que construit dans un objectif assez précis,
nous permet de bien distinguer les phases et les responsabilités qui
incombent à toute mise en place d'un système de gestion documentaire.
Il est évident que dans le cadre de ce projet son application complète
est aussi irréaliste que superflue. Néanmoins un certain nombre
de points présentés seront repris et adaptés à
notre vision des choses. Nous ne retiendrons pas par contre la gestion de
la propriété qui nous ferait rentrer dans des considérations
légales. Par contre les questions de définition, sensibilité,
qualité et accessibilité doivent être au coeur de notre
conception.
3. L'utilisation et la gestion des document
Chacun fait l'expérience tous les jours de la recherche d'information
dans un ensemble documentaire : un étudiant pour faire un mémoire,
un responsable de service pour faire sa synthèse annuelle, un chef
de projet pour se défendre lors d'une réunion. Ce que nous pouvons
constater est la chose suivante :
une documentation n'a d'intérêt que si au
moins trois conditions sont remplies :
1. elle est pertinente,
2. elle est maintenue
à jour,
3. elle est rapidement
accessible.
Nous ne pouvons guère agir sur le premier point qu'en tant que producteur
du document, il est inhérent au travail des auteurs. Toutefois une
politique inspirée du modèle OTI permettrait d'y remédier.
Les deux points suivants sont plus accessibles à la mise en place d'un
système. Il faut remarquer que ces trois propriétés sont
valables autant du point de vue de l'utilisation que de la création.
3.1 Maintenance et gestion des documents
La documentation est dans bien des activités un support d'information
obligatoire ou même le résultat direct du travail effectué.
Pourtant, nous avons pu constater dans des professions où elle ne représente
pas le cœur du métier, comme la production de logiciels, que sa
génération et sa maintenance représentent un travail
indispensable mais perçu comme étant ingrat, peu valorisant
ou difficile. Outre le fait qu'elle est plus ou moins facilitée par
le contexte et les moyens réellement dédiés, une approche
méthodologique de sa gestion et la mise à disposition d'outils
est à notre avis un facteur important.
La normalisation documentaire fait partie des taches facilitées dans
la pratique pas un système informatique.
Tôt ou tard , quand le volume de documents devient important, il n'est
plus raisonnablement possible de s'en passer et son application manuelle n'apporte
souvent que peu de résultats probants.
Soit il n'y en a aucune et rapidement il devient pénible de donner
des identifiants de document pertinents ou de les situer dans des emplacements
significatifs. Soit au contraire la norme est très précise,
et perd toute signification sans une attention constante des auteurs qui doivent
maintenir manuellement les identifiants documentaires, le contrôle de
versionnage. Si cette contrainte devient trop lourde, cela aboutit à
des aberrations comme des évolutions parallèles ou à
des documents non-validés rendus publics.
Ce que l'être humain peine à réaliser, un système
informatique peut le faire, ou du moins offrir des facilités en ce
sens. Nous pensons qu'il doit reposer sur des règles de gestions réalistes,
simples et utilisables.
Voyons quelles sont les techniques de classifications de documents utilisées.
3.1.1 Classification de l'information.
Définition de la classification (selon l'OTI)
"La classification de l'information est l'acte de
regrouper des informations liées, déterminer la valeur que ce
regroupement peut avoir et assigner des descriptions standardisées
à cette valeur pour un stockage, un accès et une analyse possible"
Les classifications peuvent être formelles et informelles. La classification
informelle est basée sur une description à posteriori, une description
ou un résumé. C'est le principe de la constitution de dossiers
au fur et à mesure de l'arrivée de documents. Elle est très
efficace et facile à exploiter pour de petits volumes. L'approche formelle
est prescriptive et constituée à priori.
La classification formelle est obligatoire pour les traitements automatisés.
Elle repose sur un schéma conçu sur une gamme de regroupements
hypothétique. La technique consiste à assigner un code (chiffres
ou lettres) désignant le regroupement. Par exemple la classification
Dewey associe à chaque thème un chiffre : 800 pour la littérature,
810 la littérature américaine (Dewey était un bibliothécaire
américain), 811 la poésie américaine, 820 la littérature
anglaise et ainsi de suite...
Le degré de précision lui par contre évolue avec le temps
: initialement, le système Dewey possédait peu d'entrées
pour l'ingénierie, mais avec les progrès technologiques, il
a fallu créer des subdivisions pour l'électronique ou l'aéronautique.
Actuellement, cette section est reconnue par les gens du métier comme
encombrée et donne lieu à des codes d'une longueur absurde.
L'approche formelle possède l'avantage de figer exactement un contenu
documentaire dans un regroupement précis. C'est hélas aussi
son inconvénient. Elle ne permet pas à un document d'appartenir
à plusieurs regroupements. En fait elle est inspirée de la réalité
physique d'une bibliothèque constituée de rayonnages et d'étagères.
Un ouvrage ne peut avoir le don d'ubiquité et être à deux
emplacements différents en même temps. Qu'en est il alors d'un
récit de la guerre de sécession en vers ? Une part d'arbitraire
est nécessaire. Il n'est pas certain que deux personnes classent le
même document au même endroit. La méthode actuelle au quotidien
est de demander à un opérateur de classer un document et de
lui proposer par raffinements successifs le code le plus adapté.
La classification à un coût. Mis à part certaines informations
à faible valeur, seul un être humain peut classer un document
à sa place logique. Obligation rendue aussi peu intéressante
par la subjectivité résidante de cette action. Mais son coût
existe aussi pour l'utilisateur de l'information. Il se doit d'apprendre le
principe du système et à l'utiliser. C'est la raison pour laquelle
il est souhaitable de maintenir des correspondances, quand elles sont possibles,
entre classifications.
De plus un système formel peut s'avérer lourd de conséquences
dans l'utilisation future des informations. Mal conçu, il défavorise
son accès.
Son développement et sa logique sont donc capitales.
Alors quelles sont les propriétés d'un bon système de
classification formelle ? :
- Le principe de codage doit pouvoir être radicalement bouleversé
par un simple mécanisme. Il ne doit pas être radicalement figé.
- les regroupements associés à des codes placés au
même niveau ne doivent pas se recouvrir, sinon il y aurait ambiguïté.
- Le code doit être extensible.
- le code doit être séquentiel (arborescent)
- Il doit comporter une valeur nulle, une sorte de valeur indéfinie
ou "en attente" , pour permettre de ne pas figer en cas de doute
un document dans une catégorie inadaptée.
Une des formes les plus praticables et ergonomiques d'utilisation d'une classification
formelle est le thesaurus. Le Thesaurus est un dictionnaire hiérarchisé comprenant
les termes génériques, des termes associés et "employés pour". Il permet une
homogénéité de vocabulaire lors de l'analyse de documents et de la saisie
de références et une aide à la recherche et à l'interrogation. Il demande
par contre un travail onéreux, délicat et son établissement
est souvent limité à un domaine, ne serait ce pour des raison
de limitation à un vocabulaire bien délimité. C'est un
outil très efficace dans les secteurs techniques dotés de jargons
précis.
En conclusion, la classification est vitale pour permettre une gestion
documentaire efficace, mais elle demande une étude et une réflexion
approfondie. Dans le cas du système de gestion documentaire que nous
envisageons, nous avons décidé de n'imposer aucune classification
à priori. Ce que nous pouvons retenir, c'est que l'existence d'un unique
système de classification est préjudiciable. Libre à
chaque administrateur d'en mettre un ou plusieurs en place. Il faut permettre
la coexistence des documents dans plusieurs classifications, le danger étant
bien sur d'obtenir des classements incohérents. C'est au responsable
de la collecte (selon l'OTI) de veiller à ce que ce ne soit pas le
cas. Nous avons donc décidé de ne proposer qu'un squelette de
classification basé sur une arborescence, modulable à souhait.
3.2 Evolution d'un document.
Un document est une forme d'informationsqui évolue. Résultat
d'un travail intellectuel, il est possible qu'il connaisse dans le temps des
modifications dues à la prise en compte de nouveaux éléments
ou d'une nouvelle approche. Il ne doit pas être considéré
comme statique. Il existe sous différents formes appelées versions
: "Chacun des états d'un texte qui a subi des modifications"
(Petit Robert 1973). Il peut aussi être asservi à un processus
d'évaluation et validation. C'est par exemple le cas des textes littéraires
qui sont soumis pour publication, renvoyer pour correction, ressoumis et ainsi
de suite jusqu'à un état de compromis où ils sont jugés
bon pour édition. On retrouve le même phénomène
pour un documents engageants deux parties avec des intérêts divergents.
Pourtant la conservation des états successifs du document est nécessaire,
ne serait ce que pour connaitre son histoire, ou par soucie de tracabilité
et de contrôle qualité.
Pour cette raison, il ne faut pas considérer un document uniquement
sous l'angle de sa classification, mais tenir compte de ses versions.
3.3 Accessibilité, moteurs
de recherche et intérêt des documents
Quelle est la destination d'un document ? Supporter des informations, mais dans
quel objectif ? Étymologiquement, document vient de documentum "ce
qui sert à instruire". Dans la vie réelle il a plusieurs
fonctions : instruire en effet, mais aussi affirmer, prouver, répondre,
témoigner...
Mais une seule destination : être utilisé !
Pour cela il faut que certaines conditions soient réunies :
1. la conscience
de l'existence du document,
2. l'accession
au document,
3. la localisation
de l'information dans le document.
Beaucoup de techniques ont été utilisées : indexations,
nomenclature, thesaurus, table des matières, index de fin d'ouvrage,
...
Pourtant il est un outil qui en apparence a fait éclater ces repères
: le moteur de recherche.
Le moteur de recherche permet à priori de se passer d'un accès
séquentiel à l'information. Prenons un exemple.
Comment faisions nous pour trouver l'information sur l'impact des pluies
acides sur la peinture des
automobiles allemandes ?
Nous commencions par aller à la bibliothèque, cherchions dans
les index tout ce qui avait rapport aux pluies acides, parcourions les livres
trouvés, fouillant leur tables des matières, parcourant des
multitude de pages en diagonale à la recherche des mots-clefs.
Puis nous nous tournions vers le bibliothécaire qui malheureusement
n'avait pas lu de telles choses et nous renvoyait à une autre bibliothèque.
Nous y recommencions la démarche, jusqu'à trouver une référence
dans l'ouvrage "écologie et économie" nous renvoyant
à un article sur "l'industrie allemande face aux exigences écologiques
de 1983 à 1986" qui ne parlait même pas des retombées
sur les véhicules, et ainsi de suite...
En fait nous effectuons un accès séquentiel à l'information,
partant d'une piste pour aller d'une information qui révélait
une autre information jusqu'à aboutir à une impasse en constatant
qu'il n'y avait qu'une partie de la réponse: oui il y a bien eu des
pluies acides entre 1983 et 1986 que Wolkswagen a dû prendre en compte...
pour ses usines !
Le moteur de recherche permet d'accèder à l'information de
façon plus directe : il va vous rapporter tous les documents en sa
connaissance qui parlent ET de pluies acides ET de voitures ET de peinture
ET d'Allemagne. Bien sur il ne permet pas encore de s'affranchir d'une sélection
sur le contenu des documents (par exemple un article sur les "dégâts
de la pluie sur les composant acides
de la peinture du peintre allemand
K. L. représentant une voiture abandonnée").
C'est un domaine de recherche très actif mais difficile à mettre
en oeuvre. Néanmoins, dans la limite des documents connus du moteur
de recherche, vous avez conscience que le document existe, vous savez y accèder
(sauf l'éternel ERROR 404) et avec les moteurs modernes retrouver l'information
dans le document.
Les trois points précédemment cités !
Le concept de moteur de recherche semble donc être une solution utile
pour accèder à une information et donner toute sa signification
à la destination d'un document. C'est pour cette raison que le moteur
de recherche est un outil incontournable pour un système de gestion
documentaire.
4. Introduction aux différentes techniques
utilisées par les moteurs de recherche
Le terme Moteur de Recherche est une expression qui recouvre un certain
nombre de notions complexes.
En effet, au sens propre, un moteur de recherche effectue une recherche de
mots clé dans une série de documents. C'est ce que fait Windows dans sa fonction
Rechercher. Le programme balaye tous les documents correspondants aux critères
(dossier, filtre..). Si le mot clé ou l'expression est trouvé dans un de ceux-ci,
le document est affiché dans les résultats de la recherche.
En fait, on peut considérer qu'un moteur de recherche a deux fonctionnalités
distinctes:
- Pré analyse des documents, c'est la phase dite d'indexation.
- Recherche d'informations : C'est en général à cette partie que l'expression
'moteur de recherche' fait allusion.
Elle se déroule en 3 étapes. ·
- Soumission par l'utilisateur d'une requête au moteur de recherche
- Recherche des documents répondant à la requête
- Le moteur de recherche fournit une série de résultats.
Ces deux fonctionnalités sont distinctes du point de vue de l'utilisateur
final, mais sont en fait très liées.. En effet, la nature de la requête conditionne
l'indexation et le travail de pré analyse des documents.
4.1. L'indexation des documents
Les méthodes d'indexation sont le sujet de nombreuses recherches. En effet,
compte tenu de la masse d'informations brutes fournies par le Web, l'absence
totale de structure et le multilinguisme, les outils, ainsi que les méthodes
actuelles atteignent leurs limites. Il y a donc une recherche florissante
autour de ce thème.
Remarque : Les recherches semblent menées principalement par des laboratoires
américains ou anglais.
Voici un résumé succinct des différentes approches de l'indexation des documents
:
4.1.1. Approche Lexicale
(Statistique)
Historiquement la première utilisée, actuellement, c'est aussi la plus évoluée.
Cette approche a atteint le niveau industriel avec des outils comme Google,
Altavista ou bien d'autres moteurs de recherche sur le web.
4.1.2. Approche syntaxique
C'est la prochaine évolution des systèmes de recherche d'informations. Le
document n'est plus alors considéré comme une série de mots mais comme une
série de phrases, chacune des phrases ayant une structure propre.
4.1.3. Approche Sémantique
C'est le futur de la recherche d'information. Elle est entièrement dépendante
des recherches en intelligence artificielle. En effet, elle suppose que la
fonction d'indexation puisse donner un sens aux documents et puisse ainsi
les classer par thèmes … comme pourrait le faire un être humain.
4.2. Requête
C'est ce terme qui définit le mode de communication entre l'utilisateur et
le moteur de recherche.
Une requête peut être une liste de mots à rechercher, une expression exacte
ou même une expression complexe qui fait appel à des fonctions booléennes
(ET OU NON) définissant l'exclusion ou la prise en compte de certains résultats.
Des évolutions récentes permettent aussi de faire des requêtes en langage
naturel (Aide intuitive de la famille Microsoft Office) mais avec des résultats
peu satisfaisants.
La phase d'interprétation de la requête permet d'imaginer un certain nombre
d'améliorations :
- Recherche multilingue en traduisant la requête en plusieurs langues
- Evitement de la polysémie, en proposant de rapprocher les mots clé des
notions voulues
4.3. Recherche de document
C'est la fonction qui effectue la correspondance entre la requête et l'ensemble
des documents. Elle est intrinsèquement liée à la méthode d'indexation des
documents. Elle fournit pour chaque document une 'note' qui indique le niveau
d'adéquation entre la requête et chaque document.
4.4. Résultats
Les résultats sont présentés à l'utilisateur en réponse à sa requête. Pour
les moteurs de recherche classique, ces résultats sont présenté sous la forme
d'une liste. Celle ci ordonne les documents selon la note attribuée précédemment
à chacun.. Ces documents sont en général triés par note décroissante. Par
contre, dans le domaine de la veille stratégique ou de l'intelligence économique,
les résultats peuvent être présentés de manière radicalement différente :
Ainsi, on trouve des représentations de type Cartographique. Par exemple,
UMAP Web de trivium présente une carte en 2 dimensions en regroupant les mots
clé par et autour de notion. Ceci permet d'illustrer visuellement une notion
ainsi que les concepts qui y sont attachés.
5. Réalisation de l'indexation
de document par approche lexicale
L'indexation des documents reste le premier travail à effectuer mais elle
conditionne entièrement les 3 étapes à savoir Requête, recherche de document,
résultat. C'est la partie la plus importante dans un moteur de recherche car
elle influe sur :
- La pertinence des résultats de la recherche
- Le temps de réponse à la recherche.
L'approche lexicale considère un document comme un ensemble de mot. C'est
ce postulat qui est à la base des différentes approche décrite ci-dessous.
C'est actuellement la famille de méthodes la plus usitée. Elle est utilisée
par les moteurs de recherche du web comme Google.
Cette approche s'est diversifiée en différentes méthodes et techniques. On
dénombre aujourd'hui 4 grandes familles de moteur de recherche statistique.
5.1. Approche Booléenne simple
Dans ce modèle, l'indexation des documents a pour unique but d'accèlérer
les recherches, en éliminant la nécessité de parcourir tous les documents
à chaque requête. Les documents ne sont indexés qu'une fois, c'est à dire
qu'ils sont mis sous une forme spécifique. La requête se présente sous la
forme d'une requête booléenne, c'est à dire une liste de mots séparés par
des mots clefs tel que ET, OU, NON et parfois PRES.
Exemple : Soient m1 et m2 deux mots :
- m1 ET m2 présentera tous les documents possédant à la fois le mot m1 et
le mot m2.
- m1 OU m2 présentera tous les documents contenant m1 et aussi tous les
documents contenant m2.
- NON m1 présentera tous les documents ne contenant pas m1
- m1 PRES m2 présentera tous les documents où m1 apparaîtra prés de m2.
La notion de PRES étant floue, c'est en général une distance inférieure
ou égale à 4 mots.
Les inconvénients majeurs de cette méthode sont :
- Difficulté d'utilisation pour des non-mathématiciens ou des non informaticiens.
- La requête est booléenne ; donc si elle est mal définie, on aura, soit
aucun document, soit (en exagérant ) tous les documents.
- Impossibilité de classer les résultats. Ils sont, du point de vue de l'évaluation,
tous égaux.
5.2. Approche Booléenne améliorée
Cette approche constitue une amélioration du modèle précédent et tente d'en
pallier les défauts.
Chaque mot de chaque document est pondéré, c'est à dire qu'on y associe une
valeur, un poids. Ce poids peut se déterminer de différentes manières.
Une manière simple est de considérer que le poids d'un mot est le nombre d'occurrence
du mot dans le document. La recherche booléenne améliorée introduit la notion
de similarité. En fait, le principe de base est de déterminer à quel point
une requête est similaire à un document. Pour ce faire, un calcul mathématique
est effectué :il prend en compte le poids des mots de la requête, à la fois,
dans la requête elle même et dans le document. Ce calcul se fait suivant les
opérateurs choisis. En général, le calcul est constitué de telle sorte que
le résultat soit compris entre 0 et 1. Ainsi, un résultat proche de 1 pour
un couple requête/document indique une forte similarité tandis qu'un résultat
proche de 0 indique peu ou pas de similarité.
Il n'y a plus la restriction du tout ou rien de la première méthode. A présent,
on peut avoir du presque tout ou du presque rien.
Cette méthode là permet d'avoir une liste de résultats classés par similarité.
5.3. Approche Vectorielle
Comme dans la méthode précédente, un texte est considéré comme un ensemble
de mots pondérés. Mais c'est une approche plus rationnelle, plus mathématique
que les précédentes. Elle tente de formaliser les concepts employés :
5.3.1. Quelques concepts
- Terme : mot pondéré d'un document. (Les mots de pondération 0 ne sont
pas des termes)
- Document : ensemble de termes
- Espace de document : Dans un espace de document, les coordonnées d'un
document sont données par le poids des termes qui le composent. Un document
est un point dans cet espace.
- Espace de terme : C'est l'espace de tous les termes. Dans cette espace
un document est donc une dimension.
- Vecteur de document : Un document dans un espace de document peut être
considéré comme un vecteur allant de l'origine de l'espace de document aux
coordonnées du document dans l'espace.
5.3.2. Calcul de la pondération
Le choix de la méthode de calcul de la pondération revêt une importance cruciale
dans cette approche. En effet c'est elle qui va déterminer la structure de
l'espace de document.
Pour déterminer la pondération d'un terme, il existe 3 grandes familles de
calcul :
- Pondération basée sur la fréquence du mot au travers du document.
- Pondération basée sur le nombre de documents utilisant le mot
- Pondération normalisée, c'est à dire que la taille du document n'influe
plus sur la pondération.
Pour une discussion approfondie sur ce thème se référer à 'Information Retrieval:
A Survey' .
5.3.3. Principe
Une fois ces préceptes posés, la structure générale de l'approche vectorielle
est simple. Tout d'abord tous les documents sont indexés (donc ici placé dans
l'espace des documents). La recherche d'un document dans cet espace se fait
par une requête. Celle-ci est assimilée à un document dans cette espace et
donc il est possible d'un déduire un vecteur. La correspondance entre la requête
et les documents se fait alors grâce à une fonction de similarité.
De nombreuses études sont d'ailleurs menées à ce sujet.
La méthode la plus simple et la plus intuitive consiste à faire le produit
scalaire du vecteur requête et des vecteurs documents. La fonction de similarité
définit ainsi pour chaque couple requête/document une note. Plus cette note
est élevée, plus la correspondance entre la requête et le document est grande.
0 indique aucune correspondance.
5.3.4. Approches dérivées
L'approche vectorielle n'est pas figée. D'autres approches utilisant les
mêmes concepts existent.
- Approche LSI (Latent Semantic indexing) : Dans cette approche, on part
du constat que l'espace de document précédent est mal défini. En effet,
plusieurs termes peuvent représenter le même concept : ce sont des synonymes.
Un document contient donc une information sémantique latente qui pourrait
être exploitée. On définit alors un espace de document formé par des synonymes
; un synonyme est le représentant de plusieurs termes à la fois. On utilise
un dictionnaire de synonymes afin de ne plus prendre en compte les termes
mais uniquement leurs synonymes. Cette approche permet de réduire sensiblement
le nombre de dimension de l'espace de document.
- Approche n-Gram : Cette approche est purement statistique. Un document
n'est plus considéré comme un ensemble de mots. Un document est un ensemble
de chaînes de taille n.
6. Objectifs du site
6.1. Hypothèse de départ
Le système envisagé est vu sous un angle interne. Il ne s'agit
pas d'un logiciel de gestion de bibliothèque, mais de documents dont
l'auteur est actif. Il est existe de très bon logiciel de gestion de
bibliothèques, mais ce n'est pas notre objectif de les reproduire et
de les singer. Nous avons préférer envisager en effet un système
qui répond à une série de besoins rencontrés dans
nos vies professionnelles : la gestion de notre propre documentation. Nous
ne reviendrons pas sur la valeur d'une bonne documentation, mais rappelons
quelques situations où un tel outil nous a particulièrement
manqué :
Un client vous affirme le contraire de ce qui a présidé à
l'élaboration d'un livrable et il vous est impossible de remettre la
main sur le compte rendu de réunion.
Vous recherchez pour la vingtieme fois l'organigramme d'une société.
Impossible de savoir quels sont les statuts actuels d'une association , la
charte existant sous plusieurs versions non datées et identifiées.
Vous vous rendez compte avec horreur que vous avez apporté des modifications
importantes sur une version de document obsolète.
Vous avez rendu public un document censé être un brouillon.
Chacun d'entre nous pourrait allonger cette liste sans difficulté.
Les principales caratéristiques du système de gestion documentaire
envisagé sont les suivantes :
- Il doit tenir compte du cycle de vie de l'information :
- Etape d'acquisition, description et de classification,
- Etape de stockage, qui se doit d'être transparente aux yeux
de l'utilisateur. Rappelons en en effet qu'un utilisateur doit consacrer
ses capacités à rédiger son document plutôt
qu'à se battre contre une solution informatisée.
- Etape de mise en place d'une politique d'accès : notamment
au niveau des droits d'accès et de la soumission à l'indexation
d'un moteur de recherche.
- Etape d'utilisation : nous considérons qu'elle reste à
la discrétion de l'utilisateur. Quelques outils pourraient toutefois
lui être fournis. Ils restent à déterminer.
- Etape d'archivage ou de destruction : Nous n'en avons pas tenu compte
dans l'immédiat, mais cela constituerait une évolution
souhaitable de notre solution.
- Il doit mettre en place les responsabilités
- La gestion de la définition : elle est attribué à
l'auteur du document. Dans un contexte réel d'utilisation et
de création d'une documentation interne, il est peut être
préférable d'alléger les processus de gestion et
de faire confiance à l'auteur. Mais elle est aussi attribué
à un responsable de groupe. En effet, si nous distinguons deux
univers, l'univers interne et l'univers externe au groupe, il peut être
souhaitable que l'interface vers l'extérieur soit placée
sous la responsabilité d'un acteur représentatif et habilité
à décider quelle est la meilleure classification d'un
document. Enfin elle est bien sur attribuée aux administrateurs.
Elle s'effectue par le placement volontaire d'un document dans une ou
plusieurs branches de l'arborescence. Il n'y a pas de classifications
foigée, rapelons le.
- La gestion de la sensibilité : Elle est attribuée aux
mêmes acteurs que précedemment par un système de
droits explicités ultérieurement.
- La gestion de la qualité de la documentation : nous n'avons
pas figé son attribution. Cela rentre dans des considérations
organisationnelles trop fortes pour prendre le risque de voir notre
solution inadapté à certaines situations. Tout au plus
nous fournissons un outils de versionnage et d'historique.
- La gestion de l'accèssibilité : tout comme la gestion
de la sensibilité, elle est attribuée aux auteurs, chef
de groupe et administrateur par un jeu de droit. Toutefois, l'administrateur
du moteur de recherche prend une part importante de cette responsabilité,
puisque il gère le moyen le plus puissant d'accès.
6.2. Ergonomie et performance
Il est bien sur souhaitable d'obtenir une interface ergonomique. Il s'agit
d'un outil, or un un outil n'est utilisé que si il est plaisant et
fournisseur de services pertinents (ou si il soit obligatoire) . Nous avons
donc travailler dans cette direction. Mais il faut tenir compte qu'il ne s'agit
que d'un projet d'étude, et que les moyens fournis par une solution
de type intranet ne permettent pas toujours de fournir un bon compromis entre
ergonomie et performance sans un travail très poussé et relevant
d'une compétence professionelle et à plein temps.
6.3 fonctionnalités attendues
en gestion documentaire
La liste des fonctionnalités à réaliser est assez longue,
non-exhaustive et surtout prétentieuse dans le cadre d'un projet d'étude.
Nos objectifs sont axés autour de la gestion documentaire et le moteur
de recherche.
Avant d'aborder la liste des fonctionnalités souhaitées, précisons
les termes que nous emploierons :
6.3.1 Définitions
- le contenu documentaire
: Le contenu documentaire est l'ensemble des informations contenues dans
un texte. La liste des numéros de téléphone est le
contenu documentaire d'un annuaire, bien qu'il ne soit pas l'annuaire en
soi.
- Le répertoire
: un répertoire est un espace qui contient soit des documents, soit
des sous-répertoires. Il ne possède pas de contenu documentaire
en soi. Il peut correspondre à une cote de classification et contenir
des sous-divisions.
- le fichier : le fichier
est la forme physique d'un contenu documentaire. Nous pouvons par exemple
avoir un fichier ASCII, un fichier HTML, un fichier PDF qui représentent
trois formes physique différentes, mais qui peuvent avoir
le même contenu documentaire. L'article sur "l'impact des
pluies acides sur la peinture des automobiles allemandes" peut
être stocké sous forme ASCII, HTML, ou PDF bien qu'il s'agisse
du même contenu documentaire.
- le document : un document
est un ensemble de versions de contenus documentaires. Si nous prenons comme
exemple de document "norme http" il y a plusieurs versions
possibles (1.1, 1.3, ...) pourtant il s'agit toujours du document sur les
normes http. Mais si on considère les normes http du point de vue
historique, il s'agit bien de plusieurs documents ? Nous ferons la distinctions
en précisant la notion de version et de visibilité de la version.
Il faut retenir qu'un document est un ensemble de versions de contenus documentaires
et la description commune de ces versions de contenus documentaires comme
par exemple le titre, le type (thèse, doc technique, etc...)
- La version : Une version
est un état d'un contenu documentaire, associé à un
indice d'évolution plus ou moins significatif. Nous associons la
notion de visibilité à cet état.
Il n'est pas opportun que tous soient accessibles. Imaginons que vous fassiez
un ouvrage juridique dont la source est le Journal Officiel. Vous faites
une nouvelle version de votre ouvrage tous les 3 mois. Vous pouvez estimer
que seule la version annuelle présente un réel intérêt.
Vous associez donc une visibilité publique aux versions annuelles
et une visibilité privée aux versions intermédiaires.
Vous pouvez également considérer que seule la dernière
version doit être visible, les autres présentant une obsolescence
dangereuse.
Si nous reprenons la liste de toutes ces définitions, nous pouvons
dire qu'un répertoire contient des documents
associés à différentes versions
d'un contenu documentaire stocké dans des
fichiers.
Les définitions propres au moteur de recherche sont moins sujettes
à ambiguïté et sont donc plus simples
- le moteur de recherche : Il permet de faire
une recherche par mot(s) clef sur l'ensemble de la base de document.
- l'index : l'index est l'association entre des
termes et des documents. Il facilite la recherche du document à partir
des termes.
- l'indexeur : c'est l'outil qui établit
la relation entre les termes et les documents.
- L'analyseur syntaxique : c'est l'outil qui
va extraire le contenu d'un fichier de la structure du fichier tout en s'appuyant
sur elle. Par exemple les fichiers HTML sont structurés avec des
balises qui n'ont pas de contenu en soi (contrairement à XML), bien
que riche d'information (un mot dans un titre n'a pas la même signification
que un mot dans une zone de texte).
- le lexicon : le lexicon comporte la liste des
mots communs à éviter (classiquement les 'le','la,'les').
6.3.2 Fonctionnalités en gestion de document
6.3.2.a Gestion des documents
- Créer , décrire, détruire la description d'un document.
- Enregistrer, remplacer, détruire un fichier,
(au sens de faire un "upload").
- Associer un fichier à une version
d'un document.
- Placer un document dans un répertoire
par défaut.
- Avoir une aide à l'indicage des versions.
6.3.2.b Organisation des documents
- Ajouter ou retirer un lien vers un fichier dans
n'importe quel répertoire ou un regroupement
de classification donné.
- Afficher l'arborescence des répertoires
ou l'ensemble de la classification.
- Localiser un document par parcours d'arborescence de répertoire
ou de classification.
- Créer des répertoires virtuels de documents ou permettre
de classer des documents suivant différents schémas.
- Lier des documents entre eux ou permettre une bibliographie interne
au système.
6.3.2.c Protéger un document, un répertoire, une version de
document
- Des accès
- De la modification
- De l'ajout ou retrait d'éléments (respectivement version,
document, fichier)
6.3.2.d Présenter un document.
- Présenter la description du document.
- Présenter l'historique d'un document.
- Présenter l'historique de chaque version.
- Ne laisser qu'une version accessible (version publique).
- Présenter les documents contenus dans un répertoire ou
une classification.
6.3.2.e Prévoir les défaillances.
- Pouvoir récupérer un fichier en cas de défaillance
du système.
- Maintenir un fichier qui permet de reconstruire le système en
cas de défaillance (logs, scripts de "recovert")
6.3.2.f Travailler en groupe.
- Avoir un responsable de groupe.
- Avoir un circuit de validation des documents.
- Partager l'accès, la modification sur un document.
- Partager l'accès, la modification sur un répertoire virtuel.
6.3.2.g Auditer
- Avoir des statistiques concernant un document ( accès, taille,
mots-clefs...)
- Avoir des statistiques concernant un ensemble documentaire ou l'ensemble
des documents.
- Enregistrer les tentatives frauduleuses d'accès.
6.3.2.h Personnaliser
- Conserver un profil utilisateur.
- Conserver la localisation des documents ("bookmark")
- Être tenu au courant de la modification ou/et l'apparition d'une
nouvelle version d'un document en s'incrivant dans une mailing-list associée.
6.3.2.g Rendre convivial
- Offrir une aide en ligne
- Offrir la possibilité de contacter l'administrateur
- Joindre un module de "news"
6.3.3 Fonctionnalités
du moteur de recherche
6.3.3.a Analyser et indexer
- Il analyse les contenus documentaires et met à jour son index.
- Il ne prend pas en compte les mots communs enregistrés dans le
lexicon et inférieurs à une taille critique (typiquement
en langue française 2 lettres)
- Il peut le faire de façon synchrone. C'est à dire s'effectuer
dès l'enregistrement du fichier (à la volée) par
l'auteur.
- Il peut le faire en asynchrone. C'est à dire en dehors de la
soumission de fichier. En mode batch ou en mode mise à jour.
- Il peut déterminer la méthode à employer en fonction
de critères d'exploitation (charge du système, ressources
accordées)
- Il peut sur demande réanalyser l'ensemble des contenus et reconstruire
entièrement son index.
- Il tient compte des destructions de documents et de versions pour la
maintenance de son index.
6.3.3.b Rechercher
- Il permet de faire une recherche par mot(s) clef sur l'ensemble de la
base de document.
- Il n'affiche que les résultats concernant les documents accessibles
à l'utilisateur.
- Il permet l'accès direct aux documents correspondants.
- Il affiche un exemple du texte où les mots clefs ont été
situés.
- Il peut rechercher par catégorie ou par rapport à une
branche d'arborescence.
6.3.3.c Qualifier
- Il qualifie la pertinence d'un résultat par rapport au nombre
d'occurrences des mots recherchés.
- Il pondère la qualification d'un résultat par la mise
en valeur des occurrences de mots, comme ceux mis dans un titre, dans
un méta tag, etc...
- Il peut à la demande privilégier certains mots par domaine
de recherche thématique.
6.4 Gestion des droits
& gestion des utilisateurs
Un système informatique multi-utilisateurs ne peut se concevoir sans
une gestion des utilisateurs et de leur droit. Cela contribue à la politique
de gestion des accès et de la sensibilité.
6.4.1. gestion des droits
Nous nous sommes inspiré de la notion de droit utilisé sous
unix (système V).
Chaque objet (répertoire, document, version, fichier) est associé
à trois domaines de droits:
- propriétaire
- groupe
- public
Chaque domaine est associé à un niveau de droit (en UNIX, droit
de "lecture", droit "d'exécution", droit "d'écriture").
Les fameuses petites lettres associés à un fichier ou un répertoire
r,x,w
Ces droits diffèrent selon la nature de l'entité considérée
:
Pour un "contenu" (version, fichier) :
- lecture : le "contenu" est
visible
- écriture : le "contenu"
peut être modifié , mais pas supprimé (propriété
du répertoire)
- exécution : le "contenu"
est exécutable, ce qui dans notre cas n'a pas de signification,
néanmoins nous le conserverons dans l'hypothèse d'une utilisation
postérieure ( comme par exemple le droit de lancer une procédure
?)
Pour un "contenant" (répertoire, document)
- lecture : les éléments du "contenant"
sont visibles (listables)
- écriture : la liste d'éléments
du "contenant" est modifiable.
(on peut supprimer ou ajouter des éléments. C'est indépendant
des droits
sur les "contenus").
- exécution : le "contenant"
est accessible, sinon le "contenant" et ses "contenus"
sont inaccessibles et verrouillés.
- Reste un niveau de droit supplémentaire : le "sticky
bit" qui implique que l'on ne peut pas supprimer des "contenus"
du "contenant" , juste en ajouter. Très utile
dans la vision d'un travail de groupe.
Cette gestion des droits va directement déterminer la gestion des
utilisateurs.
6.4.2. gestion des utilisateurs
Nous avons défini quatre profils types d'utilisateur
se distinguant par des niveaux de droits croissants.
- le lecteur : c'est
l'utilisateur, anonyme ou enregistré, qui ne peut que consulter
ce qui est ouvert à tous.
il ne possède que les droits du domaine public.
- l'auteur : utilisateur
créateur de documents. Il possède les droits du lecteur
plus ceux des domaines propriétaire et groupes.
- le chef de groupe
: responsable d'un groupe, il a le pouvoir d'agir sur les droits du domaine
public de toutes les entités qui sont affiliées à
son groupe. Il est en fait le responsable de ce que les membres extérieurs
au groupe peuvent percevoir du groupe.
- l'administrateur
: c'est simple, il a tous les droits, tous les pouvoirs. Il est responsable
du comportement du système, de sa maintenance et de son évolution.
Remarque sur la notion de chef de groupe :
Cette notion n'existe pas sous UNIX. Néanmoins, de part la nature même
du document et de ce qu'il peut symboliser pour l'ensemble d'un groupe (un
engagement, une crédibilité, ...), il nous a semblé nécessaire
de créer ce profil.
Ces profils utilisateurs se complètent mutuellement :
un chef de groupe peut être juste un auteur dans un autre groupe voir
un lecteur pour un dernier groupe. Seul le profil administrateur ne peut s'employer
que pour sa fonction, par mesure élémentaire de sécurité.
6.5. Remarque sur la liste des fonctionnalités
Ces fonctionnalités sont en évolution permanente. Du fait d'une
spécification sans utilisateurs de référence, certaines
apparaîtront inutiles, d'autres risquent de manquer. Nous nous sommes
mis à la fois dans le rôle du concepteur et dans celui de l'utilisateur,
ce qui n'est pas très judicieux dans la vie réelle. Comme un
joueur d'échec qui joue contre lui même.
De plus, il faut aussi garder en tête que outre le projet 3I du CNAM,
ce système est le résultat d'une certaine frustration des auteurs
face à ce qui leur a manqué, donc certaines fonctionnalités
correspondent à des souhaits que nous n'aurons pas le temps dans le
cadre du projet de réaliser. Néanmoins ces réflexions
continueront leurs vies au delà du projet, certaines seront revues
à la lumière de la mise en production, d'autres ajoutées.
Il ne faudra pas s'attendre par conséquent à retrouver chacune
d'entre elles dans le plan du site qui suit, bien que nous nous soyons efforcés
d'avoir un système aussi proche que le réalisme nous y autorise
de nos spécifications.
Plan du site
7. Choix techniques
Le site est construit sur une base PHP/MySQL. Ce choix s'est imposé
pour plusieurs raisons :
- Généralisation de ces moyens sur l'ensemble des hébergeurs
et au CNAM,
- Maîtrise de la part du réalisateur de cette partie de ce
couplage,
- Communauté importante et abondance de scripts comme source d'inspiration
Pour le moteur de recherche, la logique diverge un peu : l'indexeur a été
réalisé en java.
- Avantage de la solution par rapport à PHP
- Connaissance du langage : la maîtrise du langage était déjà acquise.
- Maturité du langage : Le langage est stable et agréable.
- Facilité de déploiement :A un programme Java, il est possible de donner
une IHM, une interface HTML..
- Outils de développement intégrés disponibles (Jbuilder 5). Ces outils
facilitent le développement d'application complexe
- Inconvénient de la solution Java par rapport à PHP
- Défaut de performance : Java étant semi interprété, ce n'est pas un
langage très performant. Cette remarque est aussi valable pour PHP.
Remarquons que cette nuisance disparait de plus en plus au fur et à
mesure des évolutions de ces languages puisque l'on s'oriente
vers des solutions de pré-compilation optimisant grandement leur
capacité.
- Hétérogène : il n'y a pas besoin d'avoir un couplage rigide entre
l'indexeur et le reste de l'application. En effet, l'indexation est
un traitement coûteux du point de vue ressource. Il n'est pas nécessaire
(et pas souhaitable) qu'un document soit indexé à chaque modification
sous peine de pénaliser fortement tous les autres utilisateurs du site.
Il est préférable que l'indexation soit lancée de nuit pour tous les documents
modifiés. Ceux ci seront donc accessibles via le moteur de recherche dès
le lendemain d'une modification. Une procédure d'indexation urgente pourra
être prévue pour les cas urgent. Si une indexation rapide est exigée, il est
possible d'utiliser une machine dédiée qui traitera les documents au fur et
à mesure de leurs mises à disposition
8. structure du site
Chaque fonctionnalité correspond donc à
un script dans lequel les profils utilisateurs différencient
les possibilités offertes. Le contrôle des droits à
l'exécution permet de mutualiser nombre de scripts.
Nous allons lister les différentes pages visibles des utilisateurs.
Chaque page comporte toutefois les possibilités communes :
- s'identifier.
- se déconnecter.
- afficher l'aide en ligne.
- afficher l'arborescence des répertoires et documents.
- accèder au moteur de recherche.
8.1. Acceuil
La page d'arbre documentaire a une fonction de présentation générale
du système. Seront visibles les informations comme les évolutions,
les dates de maintenance, la liste des derniers documents ajoutés,
etc...
8.2. Arborescence / liste des documents / Classification
La page "liste des documents" est visible sous forme d'arborescence
déployable.
Cela permet de catégoriser de façon hiérarchique les
documents.
Les répertoires consultables peuvent aussi bien être des répertoires
au sens classique du terme ("groupe rouge","groupe vert","groupe
bleu") que des catégories ("écologie", "histoire","informatique").
Cela est au choix des administrateurs des répertoires.
Voici un exemple de présentation :
Des informations complémentaires sont disponibles tout en conservant
une certaine simplicité à l'aspect. Pour les découvrir,
nous vous invitons à passer votre souris sur les icônes devant
chaque nom de répertoire/rubrique et document.
Fonctionnellement il s'agit de la description succincte d'un objet, permettant
ainsi de rendre plus pertinente l'information sur le contenu.
Techniquement il s'agit du texte de l'attribut "alt"
de la balise IMG.
Cette arborescence diffère suivant les droits des utilisateurs. Elle
n'est constituée que des éléments auxquels les utilisateurs
ont droit. Les autres sont ignorés. Cette vérification est faite
lors de la construction de la structure arborescente. (cf. schéma de
la base)
les possibilités de navigation sont :
- l'ouverture de la fiche du document.
- déployer ou condenser l'arborescence.
- ouvrir la fiche du répertoire.
8.3. Fiche du document
L'affichage du document contient les informations suivantes :
- nom du document
- description du document
- identifiant de version publique
- résumé
- Auteur au sens de créateur.
- date de création
- date de mise à jour
en plus de ces informations, si l'utilisateur en a le droit, il pourra voir
- le numéro de la dernière version
- l'historique des versions
- la liste des versions
Les actions possibles sont suivant les droits:
- créer un document.
- gérer les versions du document.
- modifier la fiche du document.
- changer les droits sur le document.
- détruire définitivement le document (action soumise à
conditions à préciser ultérieurement)
- gérer la mailing-liste associée.
les possibilités de navigation sont :
- afficher le contenu d'une version
- s'inscrire à la mailing liste
8.4. Fiche du répertoire
La fiche du répertoire liste l'ensemble des éléments
contenus. Elle permet d'ajouter, retirer ou déplacer des éléments.
8.5. Gestion des versions
une version se compose des informations suivantes :
- indicatif de version classique : V.v.c où V = version majeure,
v= version mineure, et c = correctif,
- liste des auteurs de la version
- historique de la version
- date de création
La gestion des versions comprend :
- créer une version
- modifier les caractéristiques (liste des auteurs, historique, indicatif)
de la version.
- enregistrer un fichier et l'associer à une version.
- changer les droits d'une version
- détruire définitivement une version
- accèder à l'analyse syntaxique de la version générée
par le moteur de recherche.
Les possibilités de navigation sont :
- remonter à la description du document
8.6. Affichage du contenu documentaire
L'affichage du contenu documentaire se résume à l'ouverture
du fichier correspondant à la version dans une autre fenêtre.
Si il s'agit d'un document en HTML, il s'affichera directement dans le navigateur,
de même si il s'agit d'un texte. Si il s'agit d'un PDF, Acrobat Reader
sera nécessaire.
Le choix d'une autre fenêtre s'impose pour
- régler le problème de la barre de navigation permettant
le retour vers d'autres choix
- pouvoir ouvrir plusieurs fichiers pour pouvoir les comparer
- s'affranchir du format
il n'y a aucune possibilité de navigation.
8.7. Aide en ligne
L'aide en ligne est un ensemble de pages représentant le manuel utilisateur.
Une autre forme est l'aide contextuelle pointée dans les pages par
des mots clefs.
8.8. Identification
La page d'identification se présente sous la forme d'une mire où
login et mot de passe sont demandés.
Si ceux-ci sont validés, les informations personnelles sont accessibles
et modifiables dans la limite des droits.
Par exemple on ne peut se rajouter à un groupe , par contre on peut
rejeter un groupe.
8.9. Mailing Liste
Cet écran permet de gérer les mailing-listes. Une mailing-liste
se définit comme une liste d'adresse électronique associées
à des documents ou des répertoire. Les messages envoyé
par mailing-liste sont consultables. La visualisation est comme tout objet
dans le système modulé par les doits de l'utilisateur. Toutefois
la définition exacte de la mailing-liste et des modalités reste
à faire. Notons qu'elle peut servir à établir un circuit
de validation...
8.10. Administration des groupes
C'est la seule partie administrative qu'un utilisateur autre que l'administrateur
puisse gérer.
Le chef de groupe peut en effet y ajouter ou retirer des membres de son groupe.
8.11. Administration de la partie documentaire
Le choix d'utiliser les même scripts et d'en modifier les possibilités
suivant les profils de droits simplifie beaucoup cette partie.
L'administration se limite principalement à avoir accès à
tout et à l'administration du SGBD en particulier.
Cette page comprendra un tableau de bord de l'état général
du système qui reste à définir avec précision.
Nous y trouverons des informations telles que : nombre de documents enregistrés,
nombres d'utilisateurs, nombre de documents par utilisateurs, etc...
8.12. Administration des utilisateurs
L'administrateur y décide des profils à attribuer aux utilisateurs,
à leur révocation éventuelle, de leur groupe primaire d'appartenance.
8.13. Administration du moteur de recherche
La partie administration du moteur de recherche permet
- de programmer des périodes d'analyse et indexage en mode asynchrone,
- de fixer les critères de traitement synchrone,
- de maintenir l'index,
- d'ordonner une mise à jour de l'index,
- d'auditer l'index
8.14 Remarque
Au même titre que les fonctionnalités de base, les différentes
pages verront leurs contenus et leurs possibilité s'affirmer dès
que nous passerons à un prototype plus avancé.
Réalisation
9. Orientation objet
Nous avons décidé de prendre partie des avantages de la conception
objet permise par PHP : factoriser des fonctions et clarifier le code. En
ce qui concerne la structure des documents, nous avons actuellement 4 classes
:
La classe de base est la classe "inode". Ensuite nous avons deux type de
classes qui en héritent.
La classe fileElement (le mot file est un mot clef en PHP !) qui corresponde
aux fichiers stockés.
La classe "container". Elle n'est qu'un conteneur d'inodes (répertoires,
dossier, catégories).
Après viennent deux autres classes : "version" et "document". version
hérite de "fileElement", et porte un attribut de numéro de version.
Document hérite de "container", et contient principalement des versions.
Le schéma est le suivant :
--
hérite-- [container]<-- hérite-- [Document]
/
[ Inode ]
\
--
hérite-- [fileElement]<-- hérite-- [version]
Ces relations d'héritage ont un impact sur le schéma de la
base de données.
D'autres classes ont été créées parmis lesquelles
les classe arborescence, utilisateur, sécurité et d'autres disponibles
dans le répertoire des sources.
10. L'arborescence/Classification
L'une des parties les plus délicates a été la réalisation
d'une structure arborescente à partir d'enregistrements contenus dans
une table de la base de données.
La partie interface graphique a été résolue en partie
en prenant appui sur un code source sous licence GPL appelé "treemenu".
Toutefois, ce code ne convenait qu'à une structure statique puisque
enregistrée définitivement dans un fichier. La première
tache a donc été de remplacer ce fichier par une détermination
dynamique des relations d'arborescence.
Une arborescence peut se décrire en terme de branche, de noeud et
de feuille. La feuille est la version d'un document, la branche la relation
qui lie un niveau n à un niveau n-1 de la hiérarchie ( on dit
aussi un fils à son père) et un noeud comme la partie de l'arborescence
d'où une ou plusieurs branches partent. L'arborescence utilisée
ne pouvait être cet objet particulièrement bien connu qu'est
l'arbre binaire, il a fallu donc développer un algorithme de parcours
de la table (détaillée ci dessous) des relations père-fils.
Cet algorithme ( cf. fonction build de la classe tree.class.php) utilise la
récursivité. Son principe est de vérifier à un
noeud de niveau n si il existe une branche de niveau n+1. Si c'est le cas,
alors par appel récursif, il effectue cette même détermination
au niveau suivant. A chaque niveau il établi une chaine de relation
du noeud racine de niveau 1 à l'extrémité de niveau p.
En terme de noeuds nous obtenons alors une suite de relation
NOEUD_niveau_0 -> NOEUD_niveau_1 ->NOEUD_niveau_2->...->NOEUDniveauP.
A noter que le parcours tiens déjà compte des notions de droits,
puisque seuls les noeuds autorisés à l'utilisateurs sont visibles
par la fonction.
Une fois l'arborescence entièrement balayée, elle est mise
sous forme de tableau exploitable par l'algorithme de présentation
de l'arborescence (fonction display de la classe tree.class.php) et enregistrée
dans la base de données.
Cette arborescence contient aussi toutes les informations nécesaires
à l'applications des autres fonctionnalités du système
: niveau de droit de l'inode, propriétaire, groupe, type d'inode, information,
etc...
Le corrolaire est qu'une fois constituée, la construction coûteuse
en ressource de l'arborescence n'est plus nécessaire, sauf si un flag
d'avertissement est positionné suite à la modification d'un
constituant par un utilisateur tiers, auquel cas l'utilisateur aura la possibilité
de rafraichir son arborescence en relancant sa construction.
L'arborescence est associé à l'identifiant de session (cf. plus
bas)
Ensuite il a fallu améliorer considérablement l'interface en
soi.
- Conserver le deploiement de l'arborescence au fil des pages. En effet,
initialement prévu pour fonctionner dans un frame HTML, l'algorithme
ne prévoyait pas de reconstruction à l'identique puisque l'arborescence
demeurait assignée à une page unique. Il a fallu construire
une paramétrisation adéquate passée en URL.
- Permettre le deploiement de toute l'arborescence ou de sa contraction
complète.
- Le détachement d'une partie de l'arborescence : Donner la posibilité
de n'en regarder qu'une partie pour éviter dans l'hypothèse
d'un volume important de se perdre dedans.
- Mettre en place une possibilité de formulaire en arborescence,
afin d'autoriser des opération de déplacement ou de destruction
groupées d'éléments. Cela permet d'avoir une ergonomie
assez intuitive.
- Ne pas figer le type de paramètre de chaque lien hypertexte de
chaque noeud. Les faire évoluer en fonction de la fonctionnalité
de la page utilisée.
11. Gestion de la sécurité
La sécurité a été une préoccupation importante
tout au long de la conception. Pour la mettre en place, nous avons tiré
partie des possibilité de sessions offertes par PHP à partir
de la version 4. Les sessions avec PHP sont un moyen de sauver des informations
entre deux accès. Chaque visiteur qui accède au site se voit assigner un numéro
d'identifiant, appelé "identifiant de session". Celui-ci est enregistré soit
dans un cookie, chez le client, soit dans l'URL. Il est aussi enregistré
dans une table de données. Des informations côté serveur
sont associées à cet identifiant de session. Les sessions vous
permettent d'enregistrer ces informaions pour les préserver et les réutiliser
tout au long de la visite du site. Lorsqu'un utilisateur accède au site, PHP
vérifie automatiquement, explicitement ou implicitement si une session a déjà
été ouverte. Si une telle session existe déjà, l'environnement précédent sera
recréé.
Il y a deux modes de propagation de l'identifiant de session : Cookies et
paramètre URL .
La méthode par cookies est optimale, mais étant donné son peu de fiabilité
(les clients peuvent refuser ou effacer les cookies), on ne peut pas se contenter
de cette technique. La deuxième méthode place l'identifiant de session directement
dans l'URL.
Si un utiliateur demande à s'identifier, le système de gestion
de la sécurité va dans un premier temps vérifier que
les logins et mot de passe existent bien dans la base des utilisateurs. Ensuite
il va attribuer un identifiant de session pour une durée donnée,
actuellement deux heures. Cet identifiant de session servira par la suite
à identifier tout au long des pages l'utilisateur et donc en déduire
les droits accordés et l'arborescence affichée. Chaque page
comprend donc une vérification de l'existence de la session.
A noter qu'il n'existe que trois possibilités d'echec d'identification.
Au delà, le profil est désactivé, les tentatives historisées
et l'administrateur prévenu.
A la fin du temps accordé ou à la demande de déconnexion,
l'identifiant de session est détruit, l'environnement effacé
et la table purgée.
Tous les paramètres passés en URL qui pourraient être
malhonnetement exploités sont vérifiés. Toutes les variables
utilisées dans les scripts et retournées par des appels de fonctions
sont initialisées dès le début pour ne pas être
placées dans une URL et être utilisées. Par exemple la
variable $isAdmin qui signifi que l'utilisateur est un administrateur est
initialisée à FALSE dès le début. Le fait de passer
le parametre en URL comme "http://www.monsite.fr/edit.php?isAdmin=1"
serait inefficace.
12.Gestion des droits d'accès
Les droits d'accès sont gérés à chaque action
de modification ou de visualisation d'un objet. Sa gestion est basée
sur la philosophie précedemment décrite. Chaque fonction membre
d'une classe de ce type va appeler une fonction de vérification qui
retournera la valeur VRAIE si le droit est accordé ou FAUSSE dans le
cas contraire. Elle vérifiera si l'utilisateur est administrateur,
puis ses droits privés, ses droits de groupe et ses droits publics
sur l'objet.
Cette conception est assez onéreuse en ressource, mais à l'avantage
ne laisser aucun trou de sécurité qui pourrait être exploité.
13.Développement du moteur
de recherche
La difficulté majeure rencontrée pour réaliser l'étude sur les moteurs de
recherche et la réalisation , est liée à la grande variété de document
à ce sujet. Etant donné que la recherche dans ce domaine est en constante
évolution, de très nombreux sites existent à ce sujet. Ce sont en général
des sites universitaire ou de laboratoire de recherche. Or ces sites sont
très spécialisés. En fait chacun est à la pointe d'une méthode de recherche
ou d'indexation précise. Ainsi, ils ont tendance à promouvoir certaines méthodes
au dépend d'autres. Il n'existe pas ou peu (je n'en ai pas trouvé) de site
généraliste présentant une synthèse des évolutions en cours. De plus, il semble
que la majeure partie des recherches dans ce domaine se passe aux états unis.
Il y a très peu de documents francophones sur ces sujets.
Les grands principes et algorithmes utilisés proviennent de l'observation
du moteur de recherche sous licence GPL "PhpDig".
14.Interface entre le moteur de recherche
et le système de gestion documentaire
14.1. Indexation
La difficulté de l'intégration d'un moteur de recherche dans
notre solution résidait dans l'exigence en ressource de la phase d'indexation..
Nous avons constaté dans PhpDig une utilisation de fonctions d'expressions
régulières très couteuses, pouvant amener à un
crash machine et un gel du parseur PHP et d'Apache. Particulièrement
génant...
Nous avons donc reécrit l'indexeur en Java avec les motivations précemment
citées.
L'interfacage entre les deux système s'effectue de la façon
suivante :
Lorsqu'un document est délivré dans le système de gestion documentaire, une
inscription est faite dans la table Site.
- Si le document existait déjà, l'enregistrement dans la table Site correspondant
est modifié pour indiquer que le document doit être ré indexé..
- Si le document n'existait pas, un enregistrement est créé dans la table
Site.
Lorsque le traitement d'indexation est lancé, il recherche dans la table
Site tous les documents devant être indexé et les traite.
L'architecture technique d'interfacage entre le logiciel java et les scripts
PHP n'est pas encore tout à fait clairement figée. Nous expérimentons
des solutions à partir d'appels système, et la cohabitation
d'un JSP avec PHP pourrait voir le jour.
14.2. Recherche d'informations
Le lancement d'une recherche se fait de manière classique, c'est à dire
à la mode web. L'utilisateur saisit une requête, lance la recherche et obtient
une liste de résultat.
14.3. Liste de résultats :
Elle contient l'ensemble des documents correspondants à la requête avec toutefois
les limitations suivantes :
- Seules les dernières versions de documents peuvent faire l'objet d'une
recherche.
- La liste ne présente que les documents pour lesquelles l'utilisateur est
habilité.
Une requête bien formulée se basant les tables du moteur de
recherche, la table des inode et les droits utiilsateurs permet de tels résultats.
De plus, chaque élément de la liste de résultats contient les informations
suivantes :
- Nom du document
- Date de dernière mise à jour.
- Localisation
- Nom du rédacteur.
Pour augmenter le confort d'utilisation, la liste est active. Ainsi, le fait
de cliquer sur le nom d'un document dans la liste ouvre celui-ci.
15. Administration de l'indexeur de
document
L'indexeur de document ne nécessite pas beaucoup d'administration. En effet,
l'ensemble des données qu'il utilise, sont calculées à partir de documents.
Il est donc possible, dans le pire des cas (Perte de la base, fichier corrompu
…), de régénérer l'ensemble de la base. Le code de l'indexeur contient une
classe Java (Restore.class) qui recrée les tables de travail (Spider, engine,
keyword ) et qui relance le traitement d'indexation pour tous les documents
contenus dans la table Site. Il n'y a pas de fonction prévue actuellement
pour régénérer la table site à partir de la liste des documents du système
de gestion documentaire.
16. Impact du choix Programmation
Orientée Objet sur la base.
Pour bien comprendre le schéma de base, il faut prendre en compte
que nous avons utiliser les fonctionnalités objet de PHP en ce qui
concerne la gestion documentaire. Nous avons privilégié les
performances et l'héritage d'attributs communs aux Formes Normales
usuelles. Ainsi toutes les propriétés élémentaires
mutualisables sont réunies dans une seule table.
Cela permet de connaître des valeurs d'attributs généraux
avant d'entreprendre des actions plus avancés. Notamment vérifier
les niveaux de droits, ou par exemple afficher les nom de document sans avoir
avoir à effectuer des requêtes coûteuses dans les tables
spécifiques qui seraient inutiles au niveau de l'affichage de l'arborescence.
17. Schéma de base de données
Vous avez la possibilité de suivre les relations entre table en cliquant
sur les noms des attributs des relations.
17.1 Partie gestion documentaire, gestion des utilisateur et gestion de
la sécurité
Table i_node
| Attribut |
Type |
Signification |
en relation avec |
| id_node |
INT |
Clef primaire |
(1) - (*) arbo_id_previous,
arbo_id_next
(1)-(0,*) id_doc, id_version |
| node_name |
varchar(100) |
Nom du fichier |
|
| node_type |
char |
Type de l'inode |
|
| node_id_owner |
INT |
Propriétaire |
(1) - (1) id_user |
| node_id_group |
INT |
Groupe |
(1) - (1) id_group |
| node_owner_right |
INT |
Droit du propriétaire |
|
| node_group_right |
INT |
Droit du groupe |
|
| node_public_right |
INT |
Droit publique |
|
| node_creationDate |
timestamp |
Date de création |
|
| node_desc |
varchar(255) |
Description succincte de l'inode |
|
Les document sont définis dans la table document
| Attribut |
Type |
Signification |
en relation avec |
| id_doc |
INT |
Clef primaire |
(0,*)-(1) id_node |
| doc_id_owner |
INT |
Créateur du doc (différent du propriétaire) |
(1)-(1) id_user |
| doc_summup |
TEXT |
Description/ résumé du document |
|
| doc_id_location |
INT |
Répertoire par défaut |
(0,*)-(1) id_node |
| doc_publicVersion |
INT |
Version publique |
(0,*)-(0,1) id_node |
| doc_currentVersion |
INT |
Version actuelle |
(0,*)-(0,1) id_node |
| doc_kind |
varchar(30) |
Type |
|
Les versions sont définies dans la table version
| Attribut |
Type |
Signification |
en relation avec |
| id_version |
INT |
cCef primaire |
(0,*)-(1) id_node |
| version_rule |
XXX |
Règle de versionnage |
Non encore défini |
| version_indice |
char(8) |
Indice de version |
|
| version_history |
TEXT |
Historique |
|
| version parent_id |
INT |
Document liée |
(1)-(1) id_doc |
| version_creation |
timestamp |
Date de création de la version |
|
La liste des auteurs est contenue dans la table collaboration
| Attribut |
Type |
Signification |
En relation avec |
| coll_id_version |
INT |
Id du group |
(1)-(1) id_version |
| coll_id_user |
INT |
Id user |
(0,*)-(0,*) id_user |
La listre des fichiers est dans la table file
| Attribut |
Type |
Signification |
En relation avec |
| id_file |
INT |
Id du fichier |
(0,1)-(0,*) file_parent_id |
| file_sys_name |
varchar(255) |
Nom du fichier dans le système |
|
| file_orig_name |
varchar(255) |
Nom original du fichier |
|
| file_size |
INT |
Taille du fichier |
|
| file_encodage |
varchar(50) |
Encodage du fichier |
|
| file_id_version |
INT |
Identifiant de l'inode de la version associée |
(1,*)-(1) id_version |
| file_parent_id |
INT |
Id du fichier d'origine si celui ci en est une conversion
|
(0,*)-(0,1) id_file |
L'arborescence, ou relation de filiation entre inode est stocké dans
la table arborescence, que ce soit d'un répertoire à ses document
que d'un document à ses version.
Arborescence
| Attribut |
Type |
Signification |
en relation avec |
| id_arbo |
INT |
Clef primaire |
|
| arbo_id_previous |
INT |
Id de l'inode père |
(*) - (1) id_node |
| arbo_id_next |
INT |
Id de l'inode fils |
(*) - (1) id_node |
| arbo_type |
CHAR(1) |
Type de l'inode next (document, version...) |
|
| arbo_creation |
timestamp |
Date de création de l'arborescence |
|
Les menus générés par parcours des relations d'arborescence
sont stockés à la connexion et détruites à la
déconnexion (sauf utilisateur anonyme) dans la table menu
| Attribut |
Type |
Signification |
en relation avec |
| menu_id_user |
INT |
Clef primaire |
(0,1) - (1) id_user |
| menu_string |
TEXT |
Structure d'arborescence |
|
| menu_creation |
timestamp |
Date de création |
|
| menu_flag |
CHAR(1) |
Flag ordonnant une mise à jour obligatoire. |
|
Les utilisateurs sont définis dans la table user
| Attribut |
Type |
Signification |
En relation avec |
| id_user |
INT |
Clef primaire |
(1)-(0,*) node_id_owner, (1)
- (0,1) menu_id_user,
(0,*)-(0,*) grouplist_id_user |
| user_name |
varchar(30) |
Nom |
|
| user_surname |
varchar(30) |
Prénom |
|
| user_login |
varchar(20) |
Login |
|
| user_password |
varchar(32) |
Mot de passe, crypté MD5 |
|
| user_role |
INT |
(lecteur , auteur, administrateur) |
|
| user_group |
INT |
Groupe par défaut |
(1)-(1) id_group |
| user_email |
varchar(60) |
Email |
|
| user_creation |
timestamp |
Date de création |
|
| user_start_inode |
INT |
Inode racine |
|
les groupes sont définis dans la table group
| Attribut |
Type |
Signification |
En relation avec |
| id_group |
INT |
Clef primaire |
(1)-(1,*) id_grouplist, (1)-(0,*)
user_group |
| group_name |
varchar(30) |
Nom |
|
| group_desc |
varchar(255) |
Description |
|
| group_creation |
timestamp |
Date de création |
|
Les membres des groupes sont définis dans la table grouplist
| Attribut |
Type |
Signification |
En relation avec |
| id_grouplist |
INT |
Id du group |
(1,*)-(1) id_group |
| grouplist_id_user |
INT |
Id user |
(0,*)-(0,*) id_user |
| grouplist_role |
INT |
Rôle de l'utilisateur dans le groupe |
|
| grouplist_creation |
timestamp |
Date de création |
|
Schéma de relation :
1 : structure de fichier et d'arborescence à partir de la table inode
2: structure de document et de version
3 : sessions
17.2 moteur de recherche
Comme nous nous sommes inspirés du moteur phpDig, les noms des tables
demeurent.
Les informations sur les documents analysés et indexés sont
dans la table spider
| Attribut |
Type |
Signification |
En relation avec |
| id_spider |
INT |
Clef primaire |
(*)-(*) eng_id_spider |
| spider_node_id |
INT |
Identifiant du contenu documentaire |
(1,*)-(1) id_node |
| spider_first_words |
TEXT |
Liste des mots (hors balise) trouvés |
|
| spider_num_words |
INT |
Nombre de mots |
|
| site_update |
timestamp |
Date de dernière mise à jour |
|
La liste des mots-clefs est dans la table keywords
| Attribut |
Type |
Signification |
En relation avec |
| id_key |
INT |
Clef primaire |
(*)-(*) eng_id_key |
| key_twoLetters |
char(2) |
Deux premieres lettre du mot |
|
| key_word |
varchar(64) |
Le mot |
|
L'index est maintenue dans la table engine
| Attribut |
Type |
Signification |
En relation avec |
| eng_id_spider |
INT |
Lien avec le document |
(*)-(*) id_spider |
| eng_id_key |
INT |
Lien avec le mot clefs |
(*)-(*) id_key |
| eng_weight |
INT |
Pondération du mot |
|
4: Schéma :
5: interfacage du moteur de recherche et du système de gestion documentaire
Perspectives et conclusion
Que pouvons nous dire de ce travail ? Actuellement le système est
à considérer comme un prototype, une étude de faisabilité.
Il reste encore loin d'une mise en production effective. Il fallait s'y attendre,
les objectifs sont ambitieux. Nous avons découvert et approfondis des
domaines jusqu'alors superficiellement connus.
La découverte du monde de la gestion de l'information au sens général
est une réelle surprise. Nous pensions la connaître, mais bien
des aspects nous étaient inconnus. De même pour les moteurs de
recherche. Derrière cet outil utilisé quotidiennement se dissimulent
des batailles théoriques et commerciales féroces et d'une complexité
conceptuelle insoupsonnées.
En ce qui concerne le système de gestion documentaire, une mise en
place réelle de toutes les fonctionnalités prévues serait
un réel atout pour le rendre plus convivial et finalement faire en
sorte que les utilisateurs trouvent un véritable intérêt
à l'utiliser. De même la prise en considération plus poussée
d'une gestion globale, comprenant la prise en charge des documents externes,
serait souhaitable. Il est des lacunes que nous n'avons pas pris en compte,
comme notamment les mini-sites HTML, forme intéressante par sa capacité
à relier intrinséquement des documents. Mais comment gérer
en termes d'architecture techniques de tels objets ? Comment les stocker autrement
qu'en recréant l'arborescence de répertoire associée
? Par une lecture et modification dynamique du code HTML ? Nous y avons pensé.
C'est une possibilité. Mais comment aussi faire en sorte que l'utiilsateur
puisse le remonter dans un espace commun sans remonter péniblement
chaque élément de son mini-site : texte HTML, images, etc...
?
Reflechir à des solutions d'archivage est aussi à inscrire
à l'ordre du jour. Le système ne peut être efficace que
jusqu'à un certain volume encore indéterminé.
Offrir d'office des classifications prètes à l'emploi ferait
certainement gagner un aspect plus professionnel au système.
Le moteur de recherche réalisé n'a pas pour prétention d'être un vrai moteur
de recherche à usage commerciale tel un Google. C'est plutôt un sujet d'étude
relativement ouvert, qui permet de tester différentes techniques d'indexation
et de recherche. Ainsi, le choix du langage Java limite les performances de
celui-ci. Un développement en C en prenant en compte les aspects systèmes
(Accès disque, multi-threading, taille de la mémoire vive) aurait été plus
approprié. Sans aller jusque-là, il reste quand même possible d'améliorer
les performances. Un axe d'amélioration consiste en une refonte du code. Le
programme utilise des collections natives Java pour stocker le dictionnaire
ou bien des documents Il est possible de les remplacer par des collections
dédiées minimisant les accès mémoire et les temps de traitement. Un deuxième
axe d'amélioration est basée sur l'optimisation des accès base. En effet,
en condition d'utilisation courante, le moteur de recherche et l'indexeur
devront faire face à un volume de donnée très important L'utilisation d'une
base professionnelle tel qu'Oracle permettra d'avoir un gain de temps appréciable.
Ses différentes options de déploiement (multi disque, Cluster, Segment de
table) permettront probablement d'accèlérer le moteur de recherche. Le déploiement
optimal pour le système serait celui-ci :
- - Un serveur dédié pour le site de gestion documentaire, faisant fonctionner
la base de donnée ainsi que le serveur Web.
- - Un serveur dédié à l'indexation des documents
- - Un serveur dédié à la base de données de l'indexeur.
Un tel déploiement reste bien sur totalement théorique !
En fait pour réaliser ce qu'il faudrait faire évoluer, modifier
ou transformer, une campagne de tests soigneusement préparée
serait nécessaire, ainsi qu'une mise en production réelle sur
un site pilote. Nous avons exploré le terrain, fais les premières
routes et poser lespremières pierres. Il ne reste qu'à construire
solidement pour peut être un jour aboutir à une solution réellement
efficace et utilisée.
Bibliographie.
- "Information Retrieval on the Web : selected topics" , Mei
Kobayashi & Koichi Takeda, IBM Tokyo Research Laboratory 16/12/99
- "The Anatomy of a Large-Scale Hypertextual Web Search Engine"
- Description du moteur Google dans ses premières heures - Sergey Brin &
Lawrence Page, computer Science Departement Standford
http://www7.scu.edu.au/programme/fullpapers/1921/com1921.html
- "Information Retrieval" C.J van RIJSBERGEN , Department of Computing
Science, Univ. of glasgow
http://www.dcs.gla.ac.uk/Keith/Preface.html
- "la recherche d'informations" Clifford Lynch, Pour la science
http://www.pourlascience.com/numeros.pls-235/internet.lynch.htm
- "Information et orgnaisation" Brigitte Guyot,
Maître de conférence au CERSI/ENSSIB
Selon Brigitte Guyot , l'information se définit
par une triade homme / action / contenue
http://www.cnam.fr/instituts/INTD/guyot/comm.html
- Office of Information Technology of New South Wales
http://www.oit.nsw.gov.au/index.htm
Les sites
- Search Tools for Web Sites and Intranets
http://www.searchtools.com
- Special Interest Group on Information Retrieval
http://www.acm.org/sigir/
- Computer Science Student Resource Site
http://williamstallings.com/StudentSupport.html
- Computer Science Research Paper Search Engine
http://cora.whizbang.com/
- Dictionary of Algorithms, Data Structures, and Problems
http://www.nist.gov/dads/
php/mysql
- www.phpindex.com
- www.phpbuilder.com
- fr.comp.lang.php
