Recherche et récupération de document – les CMS

By 24 July 2013

3.3.4. Recherche et récupération de document

Pour trouver ou retrouver une publication, les CMS proposent une fonctionnalité de recherche de documents, bien souvent appelée « moteur de recherche ». Le moteur de recherche permet à un utilisateur de saisir les termes d’une requête, de les comparer aux valeurs dont il dispose concernant les documents et de retourner une liste de résultats pour les documents ayant des valeurs répondant aux termes de la requête.

Deux stratégies pour la recherche et la récupération de documents s’opposent : la recherche sur les méta données des documents ou sur les mots contenus dans un document. Elles sont en fait dans la plupart des cas complémentaires car l’utilisation des méta données n’est jamais suffisamment contrôlée et cohérente.

60 Platform for Privacy Preferences Project (P3P) / Copyright © 1994-2003 W 3C® / dernière revision le 2003-10-21 / http://www.w3.org/P3P/61 An RDF Schema for P3P : http://www.w3.org/TR/p3p-rdfschema/

3.3.4.1. Indexation et recherche plein texte

Un moteur de recherche est en général constitué de deux grands modules fonctionnels. Le « collecteur »62 recherche les documents sur le domaine63, et en extrait certains composants textuels. Il communique ces informations extraites des différents documents à un « distributeur64 ». Celui ci construit un index « plein texte » des documents collectés. Dans cet index figure tous les mots des textes extraits, à l’exception de ce ceux figurant dans un grand nombre de documents différents et n’ayant dès lors aucun pouvoir discriminant utile. Le distributeur comporte aussi un gestionnaire de requêtes, qui va traiter les requêtes émises par les utilisateurs, et en exploitant l’index, va lui fournir la liste des documents contenant les termes de la requête, présentés sous une forme plus ou moins laconique [41].

Le gestionnaire de requête offre des fonctionnalités permettant de spécifier des requêtes relativement complexes : opérateur de requêtes (‘ET’, ‘OU’, ‘SAUF’) [65], recherche sur des mots isolés ou sur des expressions composées de plusieurs mots, recherche sur mot entier ou sur partie de mot, utilisation de caractère de troncature65, insensibilité à la casse66, voire acceptation de fautes d’orthographe dans un terme de requête : peuvent être trouvés les mots de l’index ne différant de ceux de la requête que par une ou deux lettres (voir aussi : 3.2.1.1 Paramétrage > Moteur de recherche).

La principale limitation des moteurs de recherche « plein texte » est que l’indexation et la recherche se font sur des entités purement lexicales. Une des conséquences est la génération d’un « taux de bruit »67 souvent très important dans la réponse, c’est à dire la génération de résultats ne correspondant pas à la requête. C’est à cette contrainte que peut répondre la recherche sur les méta données.

3.3.4.2. Recherche sur les méta données

Sur des domaines63 de recherche communs, les valeurs des méta données doivent être toujours associées avec des vocabulaires contrôlés (c’est à dire des valeurs contenues dans des dictionnaires ou bien encore des thésaurus). De même, les termes des méta données doivent être déterminés de manière non ambiguë ; c’est l’objet de l’initiative du groupe de Dublin Core (cf. section 2.3.2) et de l’adoption de schémas de méta données.

Une recherche basée sur des méta données est plus précise qu’une recherche plein texte et permet une localisation plus rapide des ressources recherchées. Par exemple, une recherche exprimée, grâce aux méta données, de la manière suivante : « trouve tous les documents créés par ‘Jean Dupont’ » permet de récupérer un ensemble de résultats plus petit et plus ciblé que qu’une recherche exprimée ainsi : « trouve tous les documents contenant la chaîne de caractères ‘Jean Dupont’ ».

Pour effectuer la requête ci-dessus, chaque document écrit par ‘Jean Dupont’ doit être identifié comme tel par une propriété (« créateur ») que reconnaît l’application chargée de l’exécuter. Cependant, l’application devrait aussi être capable de reconnaître ‘Dupont, Jean’ ou ‘J. Dupont’ comme résultat possible. Si en plus, l’utilisateur effectuant la requête a à l’esprit une personne bien particulière s’appelant Jean Dupont, le nom seulement du créateur n’est pas un identifiant unique suffisant dans certains cas comme le serait un URI [42].

L’utilisation des méta données dans un CMS vise à résoudre toutes ces ambiguïtés qui diminuent la pertinence d’une recherche de documents et des résultats retournés. Cependant, rappelons le, l’utilisation des méta données seules n’est pas suffisante, même si elle améliore grandement la pertinence des requêtes. Il faut aussi qu’elles obéissent à un schéma reconnu et que les valeurs des méta données soient cohérentes (intégrité référentielle, utilisation de dictionnaires et de modèles).

La recherche peut s’effectuer aussi par le déploiement d’une classification (des sujets) proposée à l’utilisateur.

Grâce aux méta données, les résultats68 d’une recherche sont moins laconiques et peuvent être personnalisés par un utilisateur qui peut, par exemple, les classer par date de création, par auteur, par sujet, par langue, etc., améliorant ainsi la navigation de l’utilisateur dans sa recherche.

62 Gatherer, en anglais.
63 Domaine de recherche : ensemble des CMS dans lesquels est éffectuée une recherche, et souvent objet d’un même index.
64 Broker, en anglais.
65 Joker. Souvent le caractère ‘?’ ou ‘%’.
66 Casse : majuscule, minuscule.
67 Bruit : résultat non pertinent par rapport à la requête.

Finalement, on peut dire qu’une recherche effectuée sur des champs de méta données correspond à une requête paramétrée. Une requête paramétrée est bien plus efficace qu’une requête générale sur toutes les valeurs possibles de toutes les propriétés d’un document, ce que propose implicitement une recherche plein texte. Autrement dit, les résultats des recherches des utilisateurs sont meilleurs dans un système dans lequel les documents sont systématiquement indexés et référencés à priori selon une procédure générale. Encore faut-il que tous les utilisateurs d’un même domaine de recherche respectent cette procédure générale.

3.3.5. Navigation

Pour la plupart des utilisateurs de l’informatique, la navigation autour des ressources disponibles sur un ordinateur signifie l’une des trois choses suivantes : utiliser un système de gestion de fichier en dépliant et repliant l’arborescence des répertoires, utiliser une classification en développant là encore l’arborescence des sujets (ou autre paramètre de la classification) et enfin suivre les références imbriquées avec le contenu [42], tels que les liens hypertextes sur une page web.

Les méta données peuvent être utilisées de manière générale comme information support d’une classification personnalisée ou comme type de lien hypertexte, accroissant la facilité d’aller d’une ressource à une autre en permettant des requêtes dynamiques, ou vu autrement une exploration dynamique [66] du système de gestion de contenu. Cette exploration dynamique, cette navigation peut être synthétisée par la phrase “Overview, zoom and filter, details on demand”69, soit « vue générale, agrandissement ou réduction, détails sur demande » en français. La visualisation de l’information est une composante fondamentale de la navigation.

Par exemple, des règles peuvent être appliquées aux méta données de telle sorte que, un document, contenant une liste de mot clé pour le décrire, pourrait être associé à d’autres documents (partageant par exemple les mêmes mots clés). Une fenêtre complémentaire du navigateur pourrait alors suggérer à l’utilisateur ces documents comme pouvant l’intéresser ou bien quand l’utilisateur le désirerait, il pourrait cliquer sur un bouton ouvrant cette même fenêtre pour visualiser les références des documents ayant les mêmes mots clés.

Une autre application des méta données à la navigation pourrait être de montrer à l’utilisateur quand une ressource est dépendante d’une autre. Par exemple, des méta données pour un composant documentaire peuvent indiquer qu’il s’agit d’un commentaire sur une autre ressource (comme une critique d’un film, d’une pièce de théâtre ou d’une musique). Les méta données décrivant les « relations » (voir éléments et sous propriétés de « Relation » dans le tableau 5 : « méta données de l’initiative de Dublin Core »), « identifiant » et « source » d’un document sont les méta données potentiellement candidates à ce type de lien. Le service du site de crossref.org70 est un exemple de l’utilisation des citations bibliographiques en tant que lien de navigation pour accéder à la ressource citée.

Mais, il existe des cas où n’importe quelle méta donnée peut être sujet à l’établissement de liens pour accéder à des documents « voisins ». Par exemple, on peut vouloir accéder à une fiche descriptive ou tout autre document permettant de connaître l’auteur d’un document que l’on est en train de consulter ; on peut vouloir connaître tous les documents produits par le même auteur. C’est ce que l’on présente parfois comme la rubrique « du même auteur » ou dans un autre registre, la rubrique « dans la même collection ». Il reste que c’est la possibilité d’accéder aux documents portant « sur le même sujet » qui serait certainement la plus recherchée. Cependant, les méta données du DCMI « couverture » pourrait aussi évoquer des informations importantes à certains utilisateurs dans certains cas : « dans la même période », « sur la même zone géographique » pourrait ouvrir une petite fenêtre donnant les commerces, les accommodations, les associations, les activités sportives,

les entreprises et tout type de documents portant sur la même zone géographique. Mais il ne s’agit que d’une facilité de navigation. L’utilisateur peut aussi faire une recherche paramétrée sur la méta donnée « zone géographique » (couverture spatiale) pour découvrir les ressources concernant la zone qui l’intéresse.

68 Les résultats délivrent des méta données associées à l’identifiant du document.
69 de B.Shneiderman (1996)
70 crossref.org : http://www.crossref.org/

Dans cet exemple juste cité, l’utilisateur fait le choix non seulement d’une méta donnée pour ordonner sa navigation, mais aussi d’une valeur (ou d’un domaine de valeur) de la méta donnée pour filtrer sa recherche d’informations. Le système de navigation utilisé pour découvrir les ressources doit donc offrir aussi la possibilité de restreindre (filtrer) les critères de sélection des composants documentaires. Un utilisateur, dans ce système de navigation doit pouvoir passer d’une dimension d’une méta donnée à une autre. Dans notre exemple, ne trouvant pas ce qu’il cherche au niveau d’une ville, l’utilisateur sélectionne un filtre de dimension supérieure, soit l’arrondissement ou le département ou inversement ayant une liste de ressource trop large, l’utilisateur filtre au niveau d’une dimension inférieure de la zone géographique considérée.

Ces facilités de navigation (classification personnalisée, fenêtre de liens complémentaires, exploration dynamique) sont d’autant plus importantes si nous rappelons la possibilité d’étendre les méta données d’un document, d’un type de document ou du système de gestion de contenu avec des méta données propres à l’utilisateur ou à l’organisation. Le système de navigation s’étend alors avec l’extension des méta données, proposant une nouvelle vue, ou encore une nouvelle structure de navigation, pour chaque nouvelle méta donnée. Potentiellement, cela permet à l’utilisateur de réorganiser et re- classifier le contenu pour répondre à ses besoins et ses exigences et de partager ces nouvelles organisations et classifications avec d’autres.

3.3.6. Récapitulation

Le système de publication que nous avons présenté à travers les sous-chapitres de cette section illustre ce que permet la gestion de contenu telle qu’elle est présentée à travers les concepts de structuration des documents (section 2.1) et de méta données (section 2.3) et telle qu’elle est organisée pour les mettre en œuvre dans les systèmes de collecte (section 3.1) et de gestion de contenu (section 3.2) correspondants.

La mise en forme automatisée avec l’utilisation des fichiers de transformations est surtout le fait des sites web et des sites de publications multi-canaux, ces derniers exigeant l’application du principe de séparation de la mise en forme et du contenu. Les autres aspects que nous avons présentés : la personnalisation, la gestion des droits d’auteurs et la navigation, sont des éléments avancés des techniques de publications et sont aujourd’hui peu mis en œuvre de manière générale et surtout de manière conjointe. Cependant ce sont ces éléments qui valorisent les systèmes de gestion de contenu. Seule la recherche de documents est massivement mise en œuvre dans les systèmes de gestion de contenus actuels et encore s’agit-il principalement de la recherche « plein texte », le plus souvent non fédérée avec plusieurs CMS sources. Il y a donc là une marge de progrès.

Un système de gestion de contenu n’est pas tenu de proposer toutes ces fonctionnalités pour mériter le nom de CMS (cf. 3.2.3 Conclusion de la section intitulée « Système de gestion de contenu ») mais il est souhaitable qu’il puisse les proposer en cas de besoin affirmé. Nous présentons en annexe 8 un modèle de données (schéma de classes UML) de gestion de contenu synthétique. Ce modèle touche surtout les aspects de collecte et dans une moindre mesure les aspects de publication (transformation automatisée du contenu en publication). Il ne développe pas les méta données : pour cela, on peut se référer au schéma RDF71 des méta données de Dublin Core ou encore au tableau 5 : « méta données de l’initiative de Dublin Core ».

La deuxième partie de ce rapport propose une évaluation fonctionnelle basée sur l’ensemble des fonctionnalités qui ont été abordées dans cette première partie, en tenant compte aussi des domaines d’applications de la gestion de contenu (section 1 « Cas d’utilisations »).

71 DCMI term declarations represented in RDF schema language : http://dublincore.org/schemas/rdfs/

Lire le mémoire complet ==> (Les systèmes de gestion de contenu : description, classification et évaluation)
Mémoire présenté en vue d’obtenir le DIPLOME D’INGENIEUR C.N.A.M. en informatique
Conservatoire National Des Arts Et Métiers – Paris