3. Architecture d’un système de gestion de contenu
A partir de maintenant dans ce rapport, et après avoir vu les concepts théoriques, nous allons aborder des notions plus concrètes des systèmes de gestion de contenu, à travers les fonctionnalités nécessaires à leur mise en œuvre.
L’architecture que nous avons retenue pour parler des systèmes de gestion de contenu est basée sur celle que nous avons introduite dans la section 1.7 intitulée « Conclusion : système de collecte / système de gestion de contenu / système de publication » page 16. Cette architecture nous permet d’introduire les fonctionnalités de la gestion de contenu. Dans certains cas, le classement d’une fonctionnalité (notamment le stockage, les droits d’accès, la personnalisation) dans un des trois sous- systèmes peut paraître arbitraire, s’agissant de fonctionnalités que l’on peut rencontrer et mettre en œuvre dans plus d’un des trois sous-systèmes, soit autrement dit, de fonctionnalités orthogonales. Nous avons retenu ce classement car proche de la mise en œuvre actuelle de la gestion de contenu.

3.1. Système de collecte

Si la fin d’un système de gestion de contenu est la publication de contenus, c’est à dire sa distribution aux destinataires, il faut bien prendre en considération l’acquisition de ces contenus. Il s’agit d’un domaine très large, puisqu’il concerne tous les médias : textes, image, sons et vidéos. Avec les images, on retrouve tous types de dessins, dont les plans et les cartes. Nous avons brièvement mentionné (dernier paragraphe du chapitre « CONTEXTE, OBJECTIFS ET APPROCHE ») les techniques de numérisation de ressources physiques. Nous ne développerons pas ces aspects.
Toutes ces ressources peuvent s’assimiler à des composants documentaires. Les applications d’édition permettent leur création sur un support informatique mais doivent aussi permettre la saisie de leurs méta données. Si un composant documentaire doit être obtenu à partir d’un autre système de gestion de contenu (pour être dupliqué puis géré de manière autonome dans le système), on parlera d’importation ou encore d’échange de données informatisées (EDI). L’importation peut s’effectuer à travers la syndication, mais il s’agit plus d’un mécanisme de publication.

3.1.1. Edition de documents

3.1.1.1. Généralités : applications d’édition

Editer des documents consiste principalement à écrire. L’édition de documents sous forme de composant documentaire structurée consiste ainsi à utiliser une application de traitement de texte. A la différence importante que l’on n’y trouvera plus de commande de mise en forme graphique, les données étant séparées de la présentation28. On y trouvera par contre les autres fonctionnalités que nous ne développerons pas mais dont on peut citer l’exemple de la correction orthographique.
Cependant, pour que le document soit conforme à son modèle (template), il faut déjà qu’une application d’édition29 compatible avec un système de collecte puisse à tout moment contrôler la validité des données saisies avec la définition des éléments du modèle. C’est la première condition. Si l’on se réfère à l’architecture XML de gestion de contenu, il faut que l’éditeur de document puisse valider le document par rapport à sa DTD (Document Type Definition) ou son schéma XML pour le valider. S’il s’agit d’un modèle précisant le type de données que contient un élément, le type de donnée de l’élément doit donc être contrôlé après la saisie. Une des premières fonctions qui doit être disponible au lancement d’un éditeur doit donc être aussi le choix du modèle à utiliser avec le nouveau document.
Une valorisation intéressante d’ailleurs d’une DTD (ou mieux d’un schéma XML) est de l’utiliser pour générer automatiquement à l’aide d’un programme ad hoc un template (gabarit, modèle) de saisie de document conforme. Ce gabarit se présentera sous la forme d’un formulaire où chaque champ est constitué par un élément (composant documentaire) du document composite.
Une fonctionnalité intéressante d’un éditeur de document est son aptitude à modifier le formulaire en fonction des caractéristiques propres d’un document qui ne sont pas définies dans le modèle. Il s’agit en particulier des éléments optionnels ou définis comme pouvant être multiples, en ne présupposant pas à l’avance le nombre. Pour le cas des QCM (Questionnaires à Choix Multiples), on ne présuppose pas du nombre de question d’une section d’un QCM, ni du nombre de réponses par question. C’est l’auteur au moment de la rédaction, et en fonction des spécifications dont il dispose, qui va fixer ces critères et donc la forme du gabarit. De même, si l’on se réfère au modèle des QCM (annexe 2.1 Exemple de DTD du QCM (QCM.dtd)), on doit pouvoir choisir en début de création s’il est nécessaire de disposer des champs concernant la grille d’évaluation. La création d’un document commence donc parfois par des précisions sur le type de document à créer.
Mais là où réside la puissance d’une application d’édition intégrée à un CMS, c’est dans la synchronisation de la saisie des données d’un composant documentaire avec le système d’information de l’entreprise et en général une ou plusieurs bases de données.

28 A l’exception éventuelle des listes à puces et des tableaux lorsque le composant documentaire le permet.
29 Nous utiliserons aussi le terme d’éditeur de document

3.1.1.2. Synchronisation des sources de données avec les méta données

Commençons par un exemple. Le rédacteur d’un guide touristique saisit un nom de lieu. Le correcteur orthographique peut intervenir s’il possède un dictionnaire des noms de lieu. Mais il est encore plus souhaitable que le nom soit considéré comme un élément (i.e. un composant documentaire) auquel on puisse rattacher une propriété et surtout qu’il soit sans ambiguïté en cas d’homonymie. Pareillement, s’il s’agit de nom de personnes ou d’organisations, il est souhaitable d’identifier sans ambiguïté le terme utilisé. Si la personne ou l’organisation n’existe pas dans le thésaurus associé au système de gestion de contenu utilisé, celle ci peut alors être ajoutée (ou faire l’objet d’une proposition d’ajout) dans le thésaurus de l’entreprise. Le logiciel d’édition doit donc proposer des interfaces qui permettent au créateur de compléter les informations nécessaires lorsqu’il rédige un document. On parle dans ce cas d’utilisation de vocabulaire contrôlé à l’aide de dictionnaires30.
Mais concernant par exemple les personnes, le dictionnaire peut tout simplement être une base de données servant à d’autres applications informatiques de l’entreprise.
Voyons un autre exemple, un conseiller juridique édite un contrat pour un client. Le nom du client figure dans le paragraphe concernant les « parties » du contrat. Le client existe déjà dans le sens où le cabinet de conseil juridique a déjà travaillé pour lui. Il est référencé dans le système d’information du cabinet. Il s’agit alors de relier le contrat en cours de rédaction avec le client dans le système d’information. Derrière le nom du client, on aura par exemple un attribut identifiant (ID) le client de manière unique. Il s’agira là de gestion de contenu adapté à la gestion de clientèle (CRM –Customer Relationship Management). Si le client est nouveau et n’existe pas, il devra être crée dans l’application ad hoc afin de pouvoir être référencé. Cet exemple peut être poursuivi avec la facturation : la facture reprendra le numéro (ID) du contrat avec d’autres éléments identifiant plus explicites. Ces éléments sont définis dans le contrat (titre, auteur, date, nom du client, etc…) et repris dans la facture.
L’éditeur de document devient ainsi un formulaire interactif qui réagit aux événements de saisie de manière contextuelle en proposant des choix et des fenêtres de saisie (liste de choix, nouveau formulaire lié) qui permettent au rédacteur de préciser de quoi il parle, sans trop alourdir sa tâche.
Le formulaire est donc lié aux applications de base de données de l’entreprise, c’est pour cela que nous parlons de synchronisation des éditeurs aux systèmes de gestion de bases de données (SGBD).
Par rapport à l’exemple des contrats, il s’agit là de documents appliquant une forte réutilisation des composants documentaires. L’éditeur de texte va donc proposer dans le formulaire interactif une fonction permettant d’éventuellement inclure une clause par défaut (valeur par défaut d’un composant documentaire d’un type de document, réutilisation systématique) ou une clause connue, recherchée et incorporée par le rédacteur (réutilisation opportuniste). De même, s’agissant de réutilisation, l’éditeur devra appliquer les règles de réutilisation associées au composant en question : contenu réutilisé éditable ou verrouillé (voir chapitre 2.1.3.1 « Partage de composant »).

3.1.1.3. Gestion des contraintes (intégrité référentielle, domaine, types de données, valeurs)

L’application d’édition de documents a donc de nombreuses responsabilités. Elle doit assurer l’intégrité référentielle (exemple du client, du numéro de contrat) lors du partage de données du système d’information avec les documents. La pose de verrous (lecture seule, écriture) sur les données est donc du ressort de l’éditeur en lien avec le SGBD.
L’éditeur, en lien avec le paramétrage concernant le type de document, assure aussi l’application des contraintes de type de données31 associées aux composants documentaires, de domaine32 (pour des sous-ensembles de types de données) et de valeurs. La contrainte de valeur précise la liste des valeurs possibles que peut prendre un composant documentaire.

30 Certains parlent également de thésaurus.
31 Entier, chaîne de caractères, date, etc…
32 Par exemple, pour la date de naissance, l’année doit être postérieure à 1890.

Finalement, l’éditeur de document pourra être un formulaire de base de données, un formulaire html ou bien un logiciel spécifique disposant de mécanismes de couplage avec les SGBD et les dictionnaires du CMS.
Parmi les taches qui doivent relever de l’éditeur figure aussi l’édition des méta données, dont nous avons abordé déjà certains aspects dans la section 3.1.1.2.

3.1.2. Edition des méta données

Cette section fait l’objet d’un chapitre afin de bien marquer l’importance de la prise en compte de l’édition des méta données dans un système de collecte intégré à un système de gestion de contenu. Cependant, les méta données peuvent faire partie d’un document ou être à l’extérieur du document. Il s’agit en fait de définir comment intégrer le processus de création de contenu avec le processus de description de contenu. En effet, il peut s’agir d’une même tâche (avec un même opérateur) dans certains cas ou de tâches différenciées dans d’autres cas (avec éventuellement plusieurs opérateurs).
L’édition des méta données est fondamentale pour assurer la cohérence, la richesse et finalement la productivité d’un système de gestion de contenu.
Parmi les clés de la productivité du CMS, il y a l’automatisation de la « saisie » des méta données. Revenons sur l’exemple de la saisie d’un nom de lieu dans un document (voir chapitre 3.1.1.2). Il n’y pas forcément lieu de considérer dans le texte le nom de lieu comme un composant documentaire, stocké et géré par le système. Contrôler le vocabulaire pour le récupérer et l’indexer efficacement est suffisant. Par contre, si un nom de lieu est cité dans un texte, il peut être utile de renseigner une propriété du document descriptive concernant la couverture spatiale (voir 2.3.1.1 « Données descriptives »). L’éditeur, réagissant à l’événement de saisie d’un nom de lieu, grâce à son thésaurus associé, provoque une action : par exemple, une liste déroulante à la suite du nom dans laquelle le rédacteur choisit la valeur adéquate. Suite à ce choix, la méta donnée couverture spatiale33 pour le document peut-être renseignée avec la valeur du thésaurus de nom de lieu. Le rédacteur, ou une autre personne désignée pour cette tâche dans une chaîne d’édition, validera cette valeur lors de l’édition des méta données. Il s’agit là d’aide à l’édition de méta données et non pas d’une automatisation complète. Mais dans 95 % des cas, cette aide sera exacte et n’aura pas à être corrigée ou reprise.
Considérons maintenant l’auteur d’un document. Lorsqu’un utilisateur informatique accède à une ressource, c’est généralement parce qu’il en a le droit et qu’il s’est préalablement authentifié (logué) dans le système. Son identification (son nom notamment) dès lors peut être accessible par l’éditeur de document. Il faut dans ce cas automatiser la valeur de la saisie de la propriété « créateur », comme cela se fait d’ailleurs avec MS Word Edition Professionnelle. Le renseignement des dates est aussi du ressort de l’éditeur et du système de gestion de contenu. Quand un document est soumis pour approbation, la propriété dateSubmitted peut être renseignée automatiquement. Quand un utilisateur détermine les droits d’accès d’un document, le fichier ACL (Access Control List) correspondant peut être intégré à l’élément « Rights ».
Il y a le cas aussi des méta données inclues dans le document. Nous avons abordé cela déjà dans le chapitre intitulé « Gestion des références explicites » page 26 pour ce qui concerne les références explicites. Concernant les liens de composition, ils sont automatisables lors de la composition du document original. Par exemple, si une image est incluse dans un document html, on peut déduire la valeur de la propriété isPartOf (et celle de son inverse hasPart) pour l’image et le document html. On a aussi postulé (section 2.3.1.2 « Données d’application ») qu’a priori toutes les méta données d’applications peuvent être automatiquement saisies.

33 S’il s’agit évidemment d’une méta donnée associée au type de document en cours de rédaction.

Mais il y en a d’autres que nous n’avons pas mentionnées : par exemple, le titre, la version34, l’auteur, etc.. L’éditeur doit proposer un moyen de ne pas avoir à ressaisir ces méta données. Il peut, par exemple, proposer un formulaire de propriétés accessible par un menu dans laquelle sont saisies ces informations et qui sont ensuite reprises automatiquement, via la programmation du modèle, dans le document.
Le renseignement de la plupart des méta données est automatisable. Dans certains cas, il peut faire l’objet d’une génération automatique (résumé automatique, catégorisation automatique) et être ensuite validée par un opérateur humain. On parle alors de saisie assistée par ordinateur ou d’aide à la saisie des méta données. Le sujet, le résumé, la couverture ; la langue peuvent en être l’objet. Ce sont là des fonctionnalités avancées de la gestion de contenu. Par contre, nombreux sont les traitements de texte qui propose une génération automatique de table des matières et autres listes des éléments d’un document (figures, tableaux, index). Il doit être possible ensuite d’inclure par exemple la table des matières dans la propriété « Table des matières ».
Si l’édition des documents est incluse dans un processus d’affaire (cf. BPM – Business Process Management ou encore cycle d’activité), la valeur des méta données et des composants documentaires liés peut être pré-remplie. Nous avons vu ci-dessus l’exemple du contrat et de la facturation. Nous avons aussi mentionné dans l’exemple de modèle d’information (voir section 2.1.2.1 « Modèle conceptuel et modèles logiques de données » p 19), le lien qu’il y a entre les spécifications d’un QCM, élément du contrat, et le QCM lui-même. Si la validation du contrat est le déclencheur (trigger), le titre du QCM et des sections du QCM peut être pré-rempli à partir des spécifications pour le créateur du QCM lié au contrat. La source du QCM est aussi connue : il s’agit du contrat et plus précisément des spécifications contenues dans le contrat.
En fin de compte, on peut, en sophistiquant le système de gestion de contenu et les éditeurs de documents, renseigner de manière automatique la plus grande partie des méta données. Cela est d’ailleurs indispensable en terme de productivité, la principale critique adressée aux CMS étant la lourdeur de la saisie et du renseignement des méta données. La saisie des méta données se fait de manière traditionnelle avec l’aide d’un formulaire, là encore. Si l’on admet qu’il faut renseigner des méta données au niveau de chaque composant documentaire, la granularité des composants étant déterminée par les objectifs assignés au système (cf. section 2.1.1 « Décomposition en composants documentaires » p 18), il est impératif de prévoir le maximum d’automatismes pour cette tâche.
Dans ce contexte, le stockage et le versioning des documents prend une dimension importante.

3.1.3. Enregistrement (stockage)

L’enregistrement et le stockage peuvent être délégués au système de collecte, c’est pourquoi ils sont traités dans cette section 3.1, ou idéalement au système de gestion de contenu (voir section 1.7 « Conclusion : système de collecte / système de gestion de contenu / système de publication » ). Cela dépend de l’architecture du logiciel ou du CMS mis en œuvre.
L’enregistrement et le stockage des documents avec leurs méta données est un sujet à part entière. C’est pour cela que nous y dédions un chapitre alors que nous ne le développerons pas. Il prend pourtant toute son importance avec la norme de GED NF Z 42-013 et ISO 15489-1 (voir section 1.3 « Gestion documentaire (référentiel d’entreprise) » page 10) qui garantit entre autre le stockage afin de pouvoir restituer le document à des fins de preuve légale.
Toutefois, mentionnons les trois systèmes de stockage possibles : en fichiers à plat, en fichiers de tout format sur un système de gestion de fichier et enfin en système de gestion de bases de données.
Les fichiers, quand il s’agit de texte, peuvent être stockés sous forme de fichier plat, c’est à dire sous forme de fichier texte. XML, avec RDF, fournit la structure nécessaire pour représenter et stocker à plat les documents textes. Les autres formats de fichiers, et notamment les courriers électroniques (emails), peuvent être stockés aussi sur tout système de gestion de fichier et notamment les systèmes de fichiers virtuels ou Internet (Internet File System et Virtual File System). Mentionnons WebDAV35 (Web Distributing, Authoring and Versioning) comme protocole à vocation normative pour gérer les fichiers de manières distribuées tout en fournissant des fonctionnalités pour contrôler l’accès des fichiers (tous les systèmes de fichiers le propose) et le versioning. Enfin, les composants documentaires et leurs méta données peuvent être stockés intégralement dans une base de données.

34 Attention ! La version peut être parfois générée automatiquement par le CMS. Dans ce cas, il s’agit d’une donnée d’application qui doit être renseignée automatiquement.

Signalons ici qu’une combinaison des trois systèmes peut être mise en œuvre.
Cependant, les SGBD et leurs extensions sont mieux à même de gérer l’intégralité du référentiel d’une application de gestion de contenu (voir chapitres 1.7 « Conclusion : système de collecte / système de gestion de contenu / système de publication » (avant dernier paragraphe) et 3.2.2 « Référentiel »). Ceci est dit en sachant que la structure des documents XML peut avoir une correspondance intégrale avec un schéma de base de données (cf. « mapping »). Mais ces considérations qui concernent plus l’architecture logicielle d’un CMS, voire son architecture physique, sont hors du propos de ce présent ouvrage.
L’enregistrement des versions des documents doit répondre à une politique de gestion des versions, ou encore obéir à des règles d’attribution des versions. C’est aussi un sujet à part entière que nous n’abordons pas ici mais que nous mentionnons afin qu’il ne soit pas négligé dans un projet de CMS. Les logiciels CMS intègrent souvent une politique de gestion des versions, sans qu’elle soit paramétrable.
Le format d’enregistrement et de stockage des données n’est pas neutre sur les capacités du système à constituer un référentiel (cf. section 3.2.2) et à échanger des données, ce qui est le sujet de notre prochain chapitre.

3.1.4. EDI et syndication

L’échange de documents entre CMS est un autre des éléments de productivité que peut proposer un CMS pour rendre réel le concept d’entreprise étendue, cher aux promoteurs des portails d’entreprises (cf. chapitre 1.5 « Portail informatif »).
Le format d’échange des données entre les systèmes est par définition dépendant du format de stockage de ces données. Il est cependant toujours possible de transposer un document d’un format vers un autre, s’il n’y a pas de perte d’information entre les deux formats, c’est à dire si le format d’échange n’est pas moins riche que le format d’origine. Cela a toutefois un coût au développement et pendant l’exploitation du CMS. Or si nous ne rappelons ce qui a déjà été dit en introduction de la section 2.1, XML est un langage complètement approprié à l’échange de données informatisées. On peut donc faire la remarque qu’une architecture native de CMS intégrant XML favorisera la simplicité du système. Nous avons fait référence à la proposition de norme de l’APROGED, l’EIDE, qui est un exemple de format d’échange de documents [17] utilisant XML.
L’échange de données informatisées (EDI) est une fonction fondamentale d’un CMS puisqu’il concerne la capacité du système à importer des ressources et à les exporter dans un second temps. Cette capacité d’importation des systèmes est centrale lors de la première mise en œuvre d’un CMS et qu’il faut importer dans le système « l’héritage » documentaire de l’organisation, c’est à dire tous les documents créés avant l’implantation du CMS et que l’on veut y intégrer.
Il y a une limite à l’échange de documents entre systèmes de gestion de contenu même lorsque les formats d’échange sont harmonisés. Il s’agit du contenu à proprement parler des méta données. Il faut que celui ci soit sémantiquement compatible. Par exemple, le schéma de classification du sujet des documents doit être le même ou transposable. Ou encore certaines méta données présentes dans le système cible et absentes dans le système source devront alors être éditées spécifiquement suite à l’import des documents. Le protocole d’EDI permet donc l’échange de document mais ne suffit pas à garantir l’harmonisation des modèles de chaque méta donnée. Il faut donc aussi veiller à cet aspect là.
La collecte de composants documentaires passe par leur création à partir du système de gestion de contenu (c’est l’objet des sections 3.1.1 et 3.1.2) mais aussi par leur acquisition à partir de systèmes « partenaires » ou encore systèmes tiers. C’est ce type d’acquisition, l’importation, qui fait l’objet de ce chapitre.

35 – HTTP Extensions for Distributed Authoring – W ebDAV RFC2518 bis / Internet-Draft revision 4, July 1, 2003 / L. Dusseault – Xythos, J. Crawford – IBM / IETF – Internet Engineering Task Force. / http://www.ietf.org/rfc/rfc2518.txt?number=2518 pour la première version. – IETF W EBDAV W orking Group / http://www.ics.uci.edu/~ejw/authoring/ / Jim W hitehead <[email protected]> / Department of Information and Computer Science / University of California, Irvine / Last modified: 03 July 2003

Il y a plusieurs formes dans l’acquisition : la duplication (avec appropriation) ou la réplication.
Lorsqu’il y a duplication, le système qui importe le document se l’approprie. C’est à dire qu’il intègre le document et ses méta données à son référentiel. Il aura donc la charge de maintenir le document.
Par contre dans le second cas, le CMS importe les méta données du document « importé », mais pas le document lui-même, qui reste accessible uniquement à partir du système d’origine. Dans certains cas, pour des raisons de performances du système notamment, le document peut être répliqué, mais il est dépendant du système d’origine qui répercute les modifications sur son double. C’est pourquoi on parle de réplication, ou encore de synchronisation. Remarquons encore que la charge de vérifier la cohérence de la copie avec son original peut être sous la responsabilité du système intégrant la copie. Dans tous les cas, les systèmes doivent savoir communiquer entre eux suite à la fédération du document.
Quand un CMS réplique et agrége plusieurs documents de plusieurs sources36, on parle de syndication37. Dans le chapitre ci-dessous intitulé RDF Site Summary (RSS) un exemple de langage permettant de syndiquer des documents publiés sur des sites Web est présenté.
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

Rechercher
Télécharger ce mémoire en ligne PDF (gratuit)

Laisser un commentaire

Votre adresse courriel ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Scroll to Top