3.3. Système de publication
Le système de collecte d’un système de gestion de contenu permet de créer et d’acquérir du contenu et le système de gestion gère les références des documents. Le système de publication rend ce contenu accessible, voire le distribue, sous une forme graphique adaptée au support de publication et au public.
La principale fonctionnalité d’un système de publication est donc la mise en forme automatisée des composants documentaires en y ajoutant du comportement (interactivité) pour les documents électroniques et du style, ceci dans un but d’ergonomie de la publication. L’emploi du mot document dans le même sens que celui de publication montre l’ambiguïté qui existe entre les deux termes dans la gestion de contenu. Or cette ambiguïté doit être levée afin de pouvoir gérer les aspects juridiques du document : les droits d’auteur, la fourniture de preuve légale en sont les exemples principaux.
La recherche d’ergonomie, mais aussi d’adaptation du contenu au public, fait des techniques de personnalisation une composante à part entière des systèmes de publication.
Enfin, rendre une publication accessible, c’est à dire permettre sa recherche et sa récupération, est la dernière composante principale d’un système de publication, notamment à travers ce que l’on appelle communément le moteur de recherche. Dans la même optique, la navigation entre les documents est aussi une composante du système de publication.
Tels sont les sujets que nous allons maintenant aborder dans cette section.
3.3.1. Mise en forme
Séparer la mise en forme du contenu peut paraître coûteux de prime abord, si l’on se réfère à la pratique traditionnelle d’édition des documents grâce à laquelle un auteur crée aussi bien le contenu que la mise en forme d’un document. Il y a une part de réalisme dans cette affirmation. Cependant, quand un type de document donne lieu à l’édition de nombreux documents, par exemple quand une facture est éditée des centaines de fois, la productivité est plus forte avec la mise en forme automatique des documents. La fréquence des mises à jour, lorsqu’elle s’accroît, milite aussi en faveur de la publication automatisée.
De plus, lorsqu’il s’agit de publication électronique, notamment sur un serveur Web, les compétences nécessaires s’accroissent, justifiant la séparation de la mise en forme avec le contenu. Enfin, si le document doit être publié sous de multiples formats et canaux de distribution, alors la séparation de la mise en forme du contenu devient fondamentale si les documents doivent être maintenus (voir sections 1.4 « Gestion de site web » et 1.5 « Portail informatif »).
Nous allons voir dans cette section comment permettre la publication automatisée de documents, comme c’est le cas particulièrement dans les systèmes de gestion de site web. La publication d’un document est possible grâce à un fichier dit de transformation qui assure et contient le code de trois opérations : la sélection de composants documentaires, l’ajout de comportement et l’application de styles. Pour bien comprendre ce mécanisme, on peut rajouter qu’un fichier de transformation est associé de manière unique à un type de document et à un format de publication.
Nous donnons en annexe 7 deux exemples de fichiers de transformation issus d’applications de gestion de contenu.
3.3.1.1. Sélection de composants documentaires
Un fichier de transformation, parfois directement appelé avec en variable l’identifiant de la publication, pour accéder à un document publiable, contient d’abord une ou plusieurs requêtes de sélection des composants documentaires constituant la publication conformément au type de document.
C’est à dire, par exemple pour un document de type nouvelle53, que vont être sélectionnés pour une nouvelle, son titre, son chapeau introductif et son corps. On pourra aussi sélectionner une ou plusieurs méta données associées, comme l’auteur et l’éditeur pour l’exemple de la brève.
La forme de la requête de sélection va dépendre de l’architecture logicielle du CMS et notamment de la manière dont sont stockés les composants documentaires. S’il s’agit d’éléments inclus dans un fichier XML, la sélection va consister à ouvrir le fichier XML, parcourir ses éléments et les extraire. S’il s’agit d’une base de données, on aura classiquement une requête SQL afin de récupérer les éléments constitutifs d’une publication.
La sélection des composants documentaires sera plus ou moins sophistiquée en fonction du type de document publié. Nous venons de voir un exemple simple, avec la nouvelle, correspondant à la sélection d’un enregistrement de base de données ou des éléments d’un seul fichier XML. A l’inverse, la publication d’un catalogue, par exemple, est légèrement plus complexe en fonction du nombre d’articles et du nombre de types d’article. Le catalogue est certainement composé de parties propres (comme un éditorial pour présenter une collection, une page de garde), des extraits des documents présentés par le catalogue et peut-être enfin d’un sommaire (rubriques) et / ou d’un index des articles, des auteurs. La constitution d’un catalogue contient donc des requêtes multiples et éventuellement imbriquées.
Lorsque les éléments d’une publication sont sélectionnés, il faut ensuite les mettre en forme en les ordonnant et en y appliquant un style. L’ordonnancement des composants documentaires peut éventuellement déjà être inclus dans la logique de la DTD ou du modèle de document utilisé pour éditer le document à publier.
3.3.1.2. Application de styles
L’application de styles relève typiquement du savoir des graphistes et des typographes.
Il s’agit, une fois que les composants sont ordonnés, de les placer dans la publication et de leur donner des propriétés graphiques comme la police de caractères, la couleur, des bordures, l’épaisseur des traits, etc.. Le placement des éléments peut se faire parfois dans des tableaux, des listes à puce, en définissant des marges, des retraits, l’alignement et la pagination. Un graphisme général de la publication peut être aussi défini comme, principalement, la couleur de fond.
Il faut noter ici toutefois que le format de publication s’il est visuel dans l’écrasante majorité des cas pourrait être vocal. Le savoir-faire requis n’est plus alors celui des graphistes et des typographes, mais il emploie les mêmes techniques de transformations présentées ici.
Ces éléments de graphisme doivent idéalement obéir à une charte graphique de l’organisation qui définit les propriétés de mise en forme communes à toutes ses publications.
La mise en forme peut se trouver dans le fichier de transformation ou ne s’appliquer qu’au moment de l’affichage du document sur l’application cliente. Autrement dit, le code du graphisme peut être inclus dans le fichier de publication ou dans un fichier annexe, typiquement une feuille de style pour les pages Web de format « html ».
Une feuille de style est un fichier contenant des spécifications de mise en forme des éléments de publication. La principale norme qui s’applique aux feuilles de style est la norme CSS (Cascading Style Sheet)54, mais on peut aussi utiliser XSL (Extensible Stylesheet Language)55. Ces deux normes56 sont produites par le W3C. La principale différence fonctionnelle entre les deux langages est que XSL permet de ré-ordonner les éléments de fichiers XML alors que CSS ne concerne en rien l’ordre des éléments [41] [62].
Cependant, n’importe quel langage informatique (cf. annexe 7 « Exemples de fichiers de transformation pour la publication ») convient pour effectuer ce travail de formatage puisqu’il s’agit de sélectionner des variables, d’y appliquer un certain nombre de règles et surtout de générer un fichier de sortie au format de publication, compatible avec celui utilisé par le client de visualisation.
3.3.1.3. Ajout de comportement
Dans les publications électroniques, un des avantages les plus significatifs, est que l’on peut ajouter de l’interactivité. Par exemple, si l’on publie un sommaire, on peut intégrer un lien au titre du sommaire vers le titre dans le document. Lorsque ce lien est cliqué par l’utilisateur par exemple, le titre et le corps du chapitre sont accédés. Toutefois, l’ajout de comportement n’est pas obligatoire pour obtenir une publication.
On peut donc rajouter au document du code informatique de gestion des événements (pointage, clic simple, clic double, etc.) qui provoque des actions (réactions) appropriées (déplacement dans le ou les documents, ouverture ou fermeture d’une fenêtre, d’une boîte de dialogue, etc.). Il s’agit dans les pages html des sites web de code en langage de script dont le plus populaire est Javascript57. Ces langages de script sont compréhensibles par les logiciels des terminaux utilisés pour visualiser les documents.
Le travail d’un fichier de transformation consiste donc aussi éventuellement à rajouter du comportement à une publication. Ce comportement ajoute énormément d’information à la logique de la publication elle-même. Par exemple, dans notre exemple du QCM, c’est lui qui détient la logique de notation générale du QCM (voir exemple en annexe 7.1).
Cette section n’a pas d’autre objet que de rappeler que l’ajout de script à une publication, dépendant de l’application cliente utilisée, se fait via le fichier de transformation qui doit contenir ce script ou une référence au fichier contenant ce script. L’ajout de comportement est surtout lié à la gestion de site web.
Ainsi un fichier de transformation contient trois aspects fonctionnels : sélection des composants documentaires, mise en forme (formatage) et ajout de comportement (optionnel). Il permet la publication d’un document qui autrement n’est accessible qu’à travers le système de collecte (édition) ou le système de gestion de contenu (administration). Cette publication peut, grâce à cela, être dynamique et générée uniquement au moment de la demande de consultation. C’est aussi un des avantages de l’automatisation de la publication.
54 Voir Cascading Style Sheets home page : http://www.w3.org/Style/CSS/
55 Voir The Extensible Stylesheet Language Family (XSL) : http://www.w3.org/Style/XSL/
56 Il s’agit en fait de recommandations du W 3C et non pas de normes au sens strict du terme.
57 Core JavaScript Reference / spécifications version 1.5 disponibles à l’URL http://devedge.netscape.com/library/manuals/2000/javascript/1.5/reference/ / Copyright © 2000 Netscape Communications Corp. All rights reserved / Last Updated September 28, 2000
3.3.2. Publication versus document
L’utilisateur final, traditionnellement, ne fait référence à un document qu’en mentionnant sa publication, soit sa sortie au format papier ou encore électronique, d’où l’ambiguïté dans les CMS entre le document et la publication. Générées dynamiquement, le CMS ne garde pas forcément trace des publications.
3.3.2.1. Droits d’auteur et autres obligations légales
1. Pourtant, un utilisateur pourra faire valoir des droits éventuellement sur la base du « document » duquel il est en possession qui est en fait de notre point de vue une publication.
Le CMS doit donc pouvoir, en fonction des références de la publication, reproduire le document pour pouvoir en fournir la preuve légale, si cela est nécessaire, bien entendu. Pour savoir s’il existe une obligation légale liée à un type de document, cela doit être identifié lors de l’étude préalable à la mise en œuvre d’un CMS.
Une publication doit donc contenir des références permettant, en appliquant le code de transformations aux composants documentaires gérés par le CMS, de la reconstituer, le système n’en gardant pas obligatoirement la copie identique. Le code de transformation doit donc pouvoir être géré en fonction des versions et archivé le cas échéant en cas de modification.
2. La diffusion de certains documents est par ailleurs soumise à des droits d’auteur. Un document est la propriété intellectuelle de son auteur ou de son éditeur.
Or comme nous l’avons abordé vers la fin de la section 1.1 « Gestion des bibliothèques physiques », la diffusion électronique des documents est largement facilitée, donnant libre à cours à la copie et au pillage, selon les termes des éditeurs ou autres groupes de médias.
Le droit d’auteur s’applique-t-il à la publication, de laquelle vous êtes en possession, ou au document ? Sans répondre à la question, un CMS doit pouvoir être en mesure de répercuter les règles de droits d’auteur pour les publications. Par exemple, si vous syndiquez des nouvelles d’un fournisseur d’information (agence de presse, agence d’intelligence économique ou autre), à chaque fois qu’un utilisateur du CMS accède à la ressource, son auteur ou son représentant, doit en être averti d’une manière ou d’une autre. Autrement dit, un bon logiciel de CMS doit à l’avenir pouvoir appliquer les règles de droits d’auteur. L’utilisation du DOI58 (Digital Object Identifier) peut être une réponse technologique à cela [63].
3.3.2.2. Le code de transformation : composant documentaire ?
Nous venons de voir dans la section 3.3.2.1 ci-dessus que le code de transformation doit être géré comme un composant documentaire dans le CMS :
– dans le cas de raisons légales afin de pouvoir reproduire une publication référencée,
– si le droit d’auteur est donné aux auteurs de la mise en forme (graphisme) d’une publication en tant que co-auteur, afin de gérer les règles du copyright.
Par ailleurs, un CMS peut théoriquement, grâce aux fonctionnalités que nous avons abordées dans cette section (cf. section 3 « Architecture d’un système de gestion de contenu »), gérer tout type de code informatique, et donc les fichiers de transformation.
58 Syntax for the Digital Object Identifier / ANSI/NISO Z39.84-2000 / Copyright ©2000 by the National Information Standards Organization / Printed in the United States of America / ISSN: 1041-5653 National Information Standard Series / ISBN: 1-880124-47-5 / The maintenance agency is International DOI Foundation : http://www.doi.org/
Il ne s’agit cependant pas d’une pratique encore courante. Des aspects d’intégration aux logiciels de gestion de configuration doivent d’abord être pris en compte. Ces aspects, avec ceux énoncés dans ce chapitre 3.3.2, sont des utilisations avancées d’un CMS, et demandent encore d’être étudiées plus avant afin de pouvoir être mises en œuvre à grande échelle. Seuls quelques rares logiciels de CMS proposent ces fonctionnalités et plutôt dans le sens de gérer le code (pages ASP, JSP, javaBeans) des pages des sites Web gérés par le système de gestion de contenu orienté gestion de site Web.
La plupart des fonctions de personnalisation que nous allons voir ci-dessous sont aussi des fonctions avancées qui ne sont mises en œuvre que dans de rares cas aujourd’hui et que ne proposent que quelques logiciels de gestion de contenu.
3.3.3. Personnalisation
3.3.3.1. Introduction
Les techniques qu’offre l’informatique, notamment celles que nous présentons dans ce rapport avec XML et le Web, laissent penser que tout se fait automatiquement et qu’à force d’utilisation, le système de gestion de contenu va connaître l’utilisateur à tel point qu’il pourrait devancer ses attentes. Beaucoup de choses sont possibles afin d’adapter le contenu et la mise en forme à l’utilisateur, encore faut-il que cette adaptation soit spécifiée. Les méta données du groupe de Dublin Core définissent les éléments « public », « médiateur » et « niveau académique » (cf. tableau 5 : « méta données de l’initiative de Dublin Core » page 109) afin de placer des informations de personnalisation à propos des documents. Cependant les règles de personnalisation dans un système de gestion de contenu peuvent être beaucoup plus complexes et lourdes à gérer. De plus, la personnalisation peut aussi être envisagée dans les systèmes de collecte : c’est une fonction générique. Cependant, elle est actuellement plus traitée au niveau de la publication, car peu mise en œuvre, que de la collecte où lorsque cela est nécessaire le besoin est traité.
De manière générale, il faut donc d’un côté définir des profils d’utilisateurs, définir les adaptations qui leurs sont utiles et de l’autre classer les utilisateurs dans ces profils.
Une première forme de personnalisation, cependant conçue pour des motifs de sécurité avant tout, est opérée avec la gestion des droits d’accès. En effet, les utilisateurs n’ayant pas de droits de lecture sur des documents ne voient pas ces documents. Même lors d’une recherche, un logiciel de CMS ne doit pas fournir les références des documents pour lesquels l’utilisateur n’a pas les droits de lecture.
Il s’agit donc là d’un moyen pour adapter le contenu à l’utilisateur. Cependant, il est conçu à la base pour protéger le contenu de sa découverte par des personnes non autorisées alors que la personnalisation est une technique qui vise à rendre la communication du contenu la plus effective possible.
S’agissant de la mise en forme, on peut laisser l’utilisateur définir ses préférences (couleurs, polices de caractères, fond de page). De la même manière, l’utilisateur définit ses rubriques préférées (c’est à dire celles qui l’intéressent le plus) et donne des informations qui permettent de filtrer les documents mis à jour qui l’intéressent (l’exemple le plus typique est le choix des rubriques de nouvelles qui l’intéressent). C’est aussi l’objet des abonnements qui permet à l’utilisateur de recevoir des alertes (en cas de nouveautés ou mises à jour) sur des documents ou des sujets59 qui l’intéressent.
Dans d’autres cas, on tente de définir le profil de l’utilisateur, notamment en observant son cheminement dans le système de gestion de contenu et le contenu de ses requêtes de recherche de documents. On peut aussi tenir compte du contexte de l’utilisateur. Les règles peuvent parfois se déduire du comportement des utilisateurs qui ont effectué un parcours similaire auparavant. Certains parlent de filtrage collaboratif. Cela s’avère aussi compliqué car il faut définir là encore des règles, bien que, dans ce cas, l’utilisation des probabilités soit utilisée et détermine la partie personnalisée de l’application [64].
59 Le sujet est une méta donnée des documents. Les abonnements aux alertes ne peuvent se faire que sur la base du choix d’une ou plusieurs valeurs de méta données.
Attention cependant, un utilisateur évolue ainsi que ses attentes. S’il se comporte généralement de la même manière, à certains moment il est amené à faire d’autres choses que ce qu’il a l’habitude de faire. Il faut qu’à ce moment là, il puisse accéder à une information qui ne présuppose pas de ce qu’il est ou de ce qu’il veut faire, afin de lui permettre de trouver ce qu’il cherche car sinon, il ne trouvera pas : ce qui est le contraire de ce qui est recherché avec les techniques de personnalisation. La meilleure personnalisation est sans doute celle qui laisse à l’utilisateur la liberté de fixer ses propres règles de personnalisation en prenant en compte ses préférences.
3.3.3.2. Profil et contexte utilisateur
Le profil d’un utilisateur peut se baser d’abord sur des informations que celui peut fournir volontairement et explicitement. Le système de gestion de contenu peut par exemple soumettre un questionnaire lors de l’inscription de l’utilisateur dans le système. Le W3C propose une recommandation : P3P60, afin de permettre à l’utilisateur de définir quelles sont ses données personnelles et ce qu’il désire voir (ou ne pas voir) sur les sites Web. Les préférences utilisateurs P3P sont considérées comme des méta données et peuvent être exprimées en RDF61 (cf. section 2.3.3 « Resource Description Framework (RDF) ») [42].
Le profil peut aussi être déterminé sur la base de l’historique des actions des utilisateurs (contexte de tâche et de ressource). Les cookies, par exemple, sont des fichiers qui permettent d’enregistrer des actions utilisateurs sur le système d’exploitation du client et qui sont utilisés à chaque nouvelle session pour savoir qui utilise l’application de CMS et ce qu’il y a fait précédemment. Le profil peut aussi se déterminer sur la base de l’historique de la session de l’utilisateur, c’est à dire l’historique de ses actions (par exemple, liens cliqués depuis l’accès sur le site web, mots des requêtes de recherche) depuis le démarrage de sa session de travail.
Le profil de l’utilisateur peut être marqué aussi par le terminal client (contexte de terminal) qu’il utilise pour se connecter au système : plate-forme matérielle, plate-forme logicielle et environnement du navigateur utilisé peuvent influer sur les publications qui seront accessibles. Les variables d’environnement du système d’exploitation peuvent aussi influer sur la personnalisation d’une application de CMS. La langue par défaut de l’utilisateur peut-être celle qui est définie au niveau du système d’exploitation utilisé par exemple. L’emplacement géographique où il se situe peut être aussi déduit des propriétés de connexion du terminal dans de nombreux cas.
La personnalisation sera d’autant mieux définie qu’elle se base sur des méta données spécifiées. Il en est de même pour la recherche de documents, qui est le sujet de la section suivante.
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
