Concepts de gestion de contenu : Structuration des documents

By 24 July 2013

2. Concepts de gestion de contenu

Ici, nous allons aborder les concepts théoriques qui permettent la mise en œuvre de la gestion de contenu : la structuration des documents, la gestion des références des documents et enfin les méta données.

2.1. Concept clé numéro 1 : Structuration des documents

SGML (Standard Generalized Markup Language) a été le premier langage principal pour structurer les documents. SGML est le précurseur de XML (eXtended Markup Language). Ce sont, comme leur nom l’indique, des langages de balises qui sont interprétables à la fois par les machines et les humains. XML est en fait une technologie, adossée sur Internet et plus précisément, le plus souvent, http (HyperText Transfer Protocol), qui permet une bonne intégration des systèmes informatiques. Ses applications sont la gestion de contenu, l’échange de données informatisées (EDI) et aujourd’hui les « web services » qui permet la communication entre les programmes informatiques distribués. Les normes, langages et autres protocoles associés à XML vont servir d’illustration des techniques pour la gestion de contenu. Ces technologies seront parfois présentées, comme RDF (Resource Description Framework) dans le chapitre consacré aux méta données.

Nous abordons dans cette section 2.1 comment il est possible de structurer un document et pourquoi, quels modèles formels (schémas de classe UML et / ou DTD) peuvent être utilisés pour cela et la réutilisation des composants documentaires, qui est une des valorisations de la structuration des documents, tout comme le sont la séparation du contenu de la présentation et l’intégration possible aux autres applications du système d’information.

2.1.1. Décomposition en composants documentaires : méthode et objectifs

On commence ici par présenter l’objectif avant de présenter par la suite les moyens. Le but, on l’a vu, est d’offrir est d’offrir une grande souplesse de l’utilisation des documents et de permettre l’automatisation et d’accroître les utilisations des documents.

Le document contient des données qu’il s’agit de ne pas saisir une deuxième fois et qu’ensuite il faut maintenir pour en préserver la cohérence et l’intégrité.

Un document est souvent un assemblage d’autres documents. Le magazine de presse est une illustration de ce fait, le dossier en est une autre. On trouve aussi les rapports de toutes natures. Cependant, il faut noter que de prime abord, ce n’est pas évident pour tous les utilisateurs de documents. On peut convenir facilement qu’un document peut être un assemblage de composants, mais concevoir ce composant comme un document est moins facile.

Une grande difficulté est d’identifier les données (du système d’information) et les « sous- documents9 » d’un document. Sur la base d’une étude préalable de la base documentaire d’une organisation, en vue de la mise en œuvre d’un système de gestion de contenu, il s’agit de repérer les parties qui sont communes entre les documents. Il faut répondre à la question « quelle partie d’un document retrouve-t-on dans un autre document ? ». Plus prosaïquement, dans quelles situations fait-on usage régulier du « copier-coller » ? On systématise ensuite en répondant à la question « quelle partie d’un type de document retrouve-t-on dans un autre type de document ». On aborde dans la section suivante la notion de type de document.

Un composant documentaire fait l’objet d’un processus particulier : qui l’écrit, qui le tient à jour, qui le valide, qui le met en forme, qui l’utilise et comment. On peut penser que s’il y a unité de traitement pour un document, celui-ci n’est pas décomposable ou encore l’intérêt de sa décomposition est marginal.

Une autre façon de repérer des sous-éléments d’un document, c’est de voir quelle est la mise en forme habituelle et conventionnelle de cette partie de document dans les publications. Un titre par exemple, a très généralement une typographie différente et qui, par convention dans les documents institutionnels, est toujours la même pour un type de document.

Une partie d’un document fait aussi parfois référence à une autre partie du même ou d’un autre document. Typiquement il s’agit d’une note de référence ou encore d’un lien hypertexte dans un document électronique. La référence est en fait considérée comme une méta donnée d’un composant documentaire.

Si on récapitule un composant documentaire peut être une donnée du système d’information reprise dans d’autres applications, une sous-partie d’un document traditionnel qui est partagée entre plusieurs documents, qui a une mise en forme particulière et conventionnelle, qui fait référence à un autre composant documentaire et bien sûr une combinaison de cela…

On voit ainsi qu’en dehors de ces objectifs (réutilisation du composant, mise en forme automatique pour la gestion de site web et la publication multi-canal), la décomposition d’un document en sous- composants n’a pas de raison d’être.

Les méta données s’appliquent au niveau du composant documentaire. On vérifie la pertinence d’une décomposition en déterminant les méta données qui s’appliquent au composant et comment celles ci vont être maintenues. Si on n’entrevoit pas de méta donnée intéressante à appliquer au composant documentaire, il y a une forte probabilité pour que la décomposition n’ait pas de sens.

Finalement, structurer un document revient à déterminer sa granularité qui dépend du contexte de l’utilisation du document.

La décomposition d’un document est l’étape préalable de la structuration des documents dans un CMS. Une fois, ce travail exécuté, il doit être possible de concevoir le modèle de document dont une expression peut être la DTD (Définition de Type de Document – Document Type Definition en anglais).

2.1.2. Modèles formels de structuration de contenu
2.1.2.1. Modèle conceptuel et modèles logiques de données

La décomposition d’un document en composants permet de le concevoir sous la forme d’une composition de sous-éléments que l’on va traiter comme des données et d’en élaborer le modèle conceptuel. Une manière de représenter un modèle conceptuel de données (MCD) en informatique est le schéma entités-associations. Pour représenter le Modèle Logique de Données (MLD), on peut utiliser un schéma de classes UML10 ou bien une DTD.

9 Par convention , nous appellerons toujours les « sous-documents » des composants documentaires. De plus, nous n’établissons pas dans notre rapport de différence formelle entre document, composant documentaire, donnée et information.
10 UML : Unified Modeling Language

On présente en annexe 1 les schémas de classes d’un questionnaire à choix multiple et d’un contrat spécifiant la commande de QCM. On met notamment en évidence dans ce dernier schéma le lien entre les données de spécification du contrat et les méta données d’un QCM. En effet, les spécifications du QCM contiennent des données descriptives du QCM. De plus, les titres du QCM, des chapitres et des diverses sections définies dans les spécifications du contrat sont reprises éventuellement dans les QCM.

Dans ces schémas, les liens d’agrégation sont nombreux et montrent la nature caractéristique des composants documentaires qui est la plupart du temps hiérarchique. Une classe est un composant documentaire. L’association d’agrégation est composite si le composant n’est pas partagé entre plusieurs types de document, partagée sinon.

Le second schéma en faisant apparaître les liens entre les contrats, les QCM et les méta données donne une idée du modèle conceptuel de la base documentaire qui doit faire apparaître les associations entre les données (exemple de la classe client, typique d’un système d’information) et les associations entre les documents entre eux. Les méta données précisent la nature des liens.

Le modèle conceptuel de la base documentaire est parfois appelé aussi modèle d’informations. Il reprend l’ensemble des définitions de documents que peut gérer un système de gestion de contenu.

2.1.2.2. Type de document : DTD / XML schema / Template

Comme on l’a dit dans le chapitre précédent sur le modèle conceptuel de contenu, la DTD peut être assimilée au modèle logique de données d’un type de document. On peut imaginer d’ailleurs d’automatiser la transformation du modèle conceptuel en modèle logique conforme au standard DTD ou au standard du schéma XML. Ces normes font partie du langage XML défini par le World Wide Web Consortium (W3C). En fait, XML est très approprié pour donner corps aux concepts de la gestion de contenu, c’est pourquoi, dans ce rapport, chaque concept sera appuyé par une norme ou un langage relatif au langage XML. Toutefois, d’autres langages ou systèmes (par exemple HotDoc,

Open Object, Embedding (OOE), Object Linking and Embedding (OLE), OpenDoc [32] ou encore ODMA – Open Document Management API11) peuvent bien sûr être utilisés pour définir et gérer un modèle de document. Ils sont cependant moins simples et moins inter opérables que XML.

La DTD accompagne chaque document XML. La DTD (ou le schéma XML) va permettre de définir la structure d’un type de document. La différence majeure que l’on trouve entre une DTD et un schéma XML concerne la possibilité de typer les données que contiennent les éléments XML d’un document. Un schéma XML va permettre de mieux contraindre (ou typer) les données que peuvent contenir les documents qu’une DTD.

L’objectif principal de la DTD est de préciser quels sont les éléments et attributs d’éléments pouvant apparaître dans un document conforme à cette DTD.

On présente en annexe 2 la DTD du QCM et son schéma XML correspondant ainsi qu’une ébauche de la DTD du contrat.

Définir le modèle de document permet par la suite de générer un gabarit, appelé aussi template, de document. Ce template peut être par exemple un formulaire informatique de saisie du document. Ce formulaire peut intégrer tous les contrôles de cohérence et d’intégrité désirés. Chaque fois qu’un utilisateur veut créer ou mettre à jour un document d’un certain type, il va le saisir dans ce formulaire pré-établi en ne se concentrant donc que sur le contenu en faisant totalement abstraction de la forme. Une autre illustration des templates est le fichier de modèle de document de type MS Word dont l’extension est « .dot ». Certains programmes permettent de générer des templates de documents (par exemple des formulaires html) à partir de fichier DTD ou de fichier « XML Schema ». Ces formulaires sont plus ou moins élaborés, plus ou moins ergonomiques en fonction de l’application d’édition de document.

11 Open Document Management API Specification / Version 2.0 / DMW are – AIIM Enterprise Content Management Association (http://www.aiim.org/) / September 19, 1997 / HTML Edition 2.0-2 Updated 2002-10-31 / http://www.infonuovo.com/odma/downloads/odma2095.doc

2.1.3. Réutilisation

La structuration des documents permet la réutilisation maîtrisée des composants documentaires dans un système d’information, et plus spécifiquement dans les systèmes de gestion de contenu, c’est pourquoi nous abordons ce thème ici.

Nous présentons dans ce chapitre les différents types et propriétés de la réutilisation de composants documentaires que l’on peut rencontrer et que l’on doit observer pour rendre la réutilisation effective. De fait, la réutilisation rend cruciales l’identification et la gestion des références, objet de la section 2.2.

2.1.3.1. Partage de composant

Comme on a pu le voir dans l’exemple repris dans le chapitre abordant le modèle conceptuel de contenu, les contrats peuvent spécifier les différents titres que contient un QCM et, de fait, que peuvent reprendre les QCM. Différents documents peuvent ainsi partager un même composant.

Toutefois le partage peut avoir plusieurs formes, c’est à dire, avoir des propriétés différentes selon les cas [33].

La réutilisation peut être opportuniste si l’auteur doit chercher le contenu de l’élément lié et l’insérer, ou systématique, si l’insertion est automatique. Alors le contenu est inséré à l’endroit approprié du gabarit (« template ») de saisie du nouveau document.

Ensuite, le contenu peut être dérivé, si l’auteur s’inspire du contenu original de l’élément partagé comme d’une source d’information mais ne le reprend pas strictement. Un autre exemple de contenu dérivé est une traduction du contenu d’origine. De fait, le contenu réutilisé peut être éditable. Si le contenu réutilisé n’est pas éditable, il est au contraire dit « verrouillé » et reproduit à l’identique.

Un type de réutilisation supplémentaire est l’emboîtement. Il s’agit de la réutilisation de plusieurs éléments dans un élément unique. On parle de réutilisation emboîtée (« nested » en anglais). La somme de tous les éléments crée un élément et des sous-ensembles de l’élément peuvent être utilisés dans des présentations alternatives.

Dans tous les cas, en cas de réutilisation, un lien (une relation) doit être établi entre le composant d’origine, le contenu et le composant réutilisant le contenu. Ce lien est fondamental si le contenu doit être mis à jour dans le composant le réutilisant si le contenu d’origine est modifié. De même, lors de la suppression (ou l’archivage) d’un document, on doit savoir si un de ses composants est réutilisé dans un document toujours valide afin de ne pas provoquer d’erreur dans le système. On doit donc préciser si on réutilise une version du contenu d’un composant ou son contenu actif. De même, si le contenu est dérivé, en cas de modification de la source, l’élément réutilisant doit être identifié comme nécessitant une mise à jour.

L’exemple de la suppression en cascade d’un enregistrement dans une base de données relationnelle respectant la troisième forme normale illustre la problématique de la maintenance dans un système de gestion de contenu. Généralement, ce lien est une méta donnée associé au document. Il s’agit des attributs « isPartOf » et réciproquement « hasPart », « isVersion Of » et « hasVersion », « Replaces », « IsReplacedBy », « Requires », « IsRequiredBy », « HasFormat », « IsFormatOf », « References », « IsReferencedBy », « ConformsTo » de la classe (super élément) des méta données « relation » du DCMI (voir chapitre intitulé « Relations implicites (liens de composition) » page 27 et chapitre 2.3.2).

2.1.3.2. Synthèse

Il s’agit de la réutilisation de composants de documents d’un même type dans un document de synthèse les présentant. Typiquement, un catalogue de produit reprend des éléments de la documentation produit. D’autres exemples sont des rapports d’analyse où l’on fait état des documents

d’un même type. « Le département commercial a signé 14 projets dont le montant annuel dépasse 1 million d’euros. Ci-dessous, vous trouverez une liste de ces projets avec leur titre, une description courte, le nom du client et son secteur d’activité » est un exemple d’un extrait d’un rapport de synthèse que l’on peut élaborer à partir des documents originaux de chaque projet. On peut rajouter aux champs extraits un champ supplémentaire de commentaire original qui est issu du document de synthèse.

Les sommaires peuvent être ainsi générés automatiquement, mais aussi les tables d’index, les tables des illustrations…

La création des documents de synthèse peut être largement automatisée grâce à la réutilisation systématique des éléments des documents de base et constitue une des justifications majeures militant en faveur d’une gestion de contenu plutôt qu’une gestion documentaire. La productivité est largement accrue puisqu’une seule modification peut ensuite être répercutée automatiquement dans les documents de synthèse.

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