les systèmes de gestion de contenu : description

CONSERVATOIRE NATIONAL DES ARTS ET METIERS

PARIS

---------------------------

MEMOIRE

présenté en vue d’obtenir

le DIPLOME D’INGENIEUR C.N.A.M.

en

informatique

par

Philippe LAHAYE

---------------------------

Les systèmes de gestion de contenu : description, classification et évaluation

Soutenu le 14 mai 2004

---------------------------

JURY

PRESIDENT : Michel SCHOLL

MEMBRES : Bernd AMANN Xavier BLONDEL Laurent DE RAMBUTEAU Laurent LETOURMY

RESUME ET MOTS CLES Les systèmes de gestion de contenu : description, classification et évaluation.

Mémoire d’Ingénieur C.N.A.M. Paris, 2004 _________________________________________________________________________________ Les systèmes de gestion de contenus (CMS) sont des applications classiques telles que la gestion des bibliothèques, la GED, la gestion de la documentation technique, la gestion de site web et les portails d’entreprise. Ces applications partagent des fonctionnalités communes qui réunies peuvent former un système de gestion de contenu unifié. Le contenu est obtenu en structurant les documents sous forme de données. Le contenu doit être séparé de la présentation. Est alors possible l’intégration de la partie documentaire des systèmes d’informations avec leur partie déjà structurée, la réutilisation des composants documentaires et la publication multi-canal. De plus, la gestion de contenu implique l’utilisation des méta données : celles de l’initiative du groupe de Dublin Core sont les plus abouties dans l’optique de la gestion de contenu. La découverte, la récupération, l’accessibilité, la diffusion et le partage des informations sont maximisés avec la gestion de contenu unifiée. Ce rapport décrit les fonctionnalités des trois sous-systèmes fondant l’architecture d’un CMS : le système de collecte (acquisition et édition), le système de gestion de contenu (référentiel et fichiers de configuration) et le système de publication (transformation, recherche d’informations). Les technologies associées à XML illustrent et permettent de mettre en œuvre les principes de la gestion de contenu. Un système de classification des CMS par domaine d’application en fonction de leurs fonctionnalités est proposé et permet de rapidement voir quelles applications peuvent être mises en œuvre par les logiciels, de les rapprocher des besoins des utilisateurs et de les comparer. L’évaluation détaillée réalisée nous amène à dire que la couverture fonctionnelle des logiciels du marché est toujours partielle dans le cadre d’une gestion unifiée du contenu d’une organisation. De nombreuses améliorations et intégrations doivent être réalisées avant que la gestion de contenu unifiée, concept théorique exploré, puisse commencer à être développée. _________________________________________________________________________________ Mots clés :

Gestion de contenu – Systèmes de gestion de contenu – CMS – Gestion de contenu unifiée – méta données – XML – RDF - GED

Keywords :

Content management – Content Management System – CMS – Unified Content Strategy – metadata – XML – RDF - EDM

CONSERVATOIRE NATIONAL DES ARTS ET METIERS

PARIS

---------------------------

MEMOIRE

présenté en vue d’obtenir

le DIPLOME D’INGENIEUR C.N.A.M.

en

informatique

par

Philippe LAHAYE

---------------------------

Les systèmes de gestion de contenu : description, classification et évaluation

--------------------------- Les travaux relatifs au présent mémoire ont été effectués au sein de la Société de Services et d’Ingénierie Informatique Cross Systems Integration Paris sous la direction de Laurent LETOURMY (directeur technique) et du professeur Michel SCHOLL (CNAM Paris) et sous la responsabilité de Bernd AMANN (CNAM Paris – Laboratoire CEDRIC « bases de données »).

SOMMAIRE REMERCIEMENTS............................................................................................................................ 1INTRODUCTION................................................................................................................................ 2CONTEXTE, OBJECTIFS ET APPROCHE ........................................................................................ 4A. LES SYSTEMES DE GESTION DE CONTENU (CMS) .................................................................. 71 Cas d’utilisations........................................................................................................................ 7

1.1. Gestion des bibliothèques physiques................................................................................. 71.2. Edition de document composite ......................................................................................... 81.3. Gestion documentaire (référentiel d’entreprise)................................................................ 101.4. Gestion de site web ......................................................................................................... 131.5. Portail informatif .............................................................................................................. 141.6. Intégration au système d’information................................................................................ 151.7. Conclusion : système de collecte / système de gestion de contenu / système de publication 16

2. Concepts de gestion de contenu .............................................................................................. 182.1. Concept clé numéro 1 : Structuration des documents ...................................................... 18

2.1.1. Décomposition en composants documentaires : méthode et objectifs...................... 182.1.2. Modèles formels de structuration de contenu........................................................... 192.1.3. Réutilisation ............................................................................................................ 21

2.2. Concept clé numéro 2 : gestion des références et identification des composants documentaires ............................................................................................................................. 22

2.2.1. Gestion des références (internes et externes).......................................................... 222.2.2. Uniform Resource Indicator (URI)............................................................................ 23

2.3. Concept clé numéro 3 : les méta données ....................................................................... 232.3.1. Méta données : définition et utilisation ..................................................................... 242.3.2. Dublin Core Metadata Initiative (DCMI).................................................................... 292.3.3. Resource Description Framework (RDF) ................................................................. 29

3. Architecture d’un système de gestion de contenu..................................................................... 353.1. Système de collecte ........................................................................................................ 36

3.1.1. Edition de documents.............................................................................................. 363.1.2. Edition des méta données ....................................................................................... 383.1.3. Enregistrement (stockage) ...................................................................................... 393.1.4. EDI et syndication ................................................................................................... 403.1.5. RDF Site Summary (RSS)....................................................................................... 413.1.6. Droits d’accès et travail collaboratif.......................................................................... 46

3.2. Système de gestion de contenu....................................................................................... 483.2.1. Administration d’un CMS......................................................................................... 493.2.2. Référentiel .............................................................................................................. 523.2.3. Conclusion .............................................................................................................. 54

3.3. Système de publication.................................................................................................... 543.3.1. Mise en forme ......................................................................................................... 543.3.2. Publication versus document................................................................................... 573.3.3. Personnalisation...................................................................................................... 583.3.4. Recherche et récupération de document ................................................................. 593.3.5. Navigation............................................................................................................... 613.3.6. Récapitulation ......................................................................................................... 62

B. EVALUATION D’UN SYSTEME DE GESTION DE CONTENU..................................................... 631. Classification des systèmes de gestion de contenu .................................................................. 63

1.1. Domaines d’application.................................................................................................... 641.1.1. Introduction ............................................................................................................. 641.1.2. Domaines................................................................................................................ 651.1.3. Fonctionnalités des sous-domaines......................................................................... 681.1.4. Conclusion .............................................................................................................. 73

1.2. Méthode de classification................................................................................................. 741.2.1. Enregistrement des fonctionnalités déclarées et classement.................................... 741.2.2. Exemples................................................................................................................ 751.2.3. Conclusion .............................................................................................................. 78

2. Evaluation détaillée.................................................................................................................. 792.1. Grille d’évaluation............................................................................................................ 80

2.1.1. Critères ................................................................................................................... 802.1.2. Notation .................................................................................................................. 80

2.2. Exemples ........................................................................................................................ 812.2.1. Jeu d’essai .............................................................................................................. 812.2.2. Adaptation au logiciel de gestion de contenu et évaluation détaillée......................... 822.2.3. Note finale (adéquation du CMS aux exigences initiales) ......................................... 96

CONCLUSION................................................................................................................................. 99ANNEXES...................................................................................................................................... 1011. Schémas de classes de documents ....................................................................................... 101

1.1. Exemple du QCM .......................................................................................................... 1011.2. Exemple du contrat de commande de QCM................................................................... 101

2. Définition de Type de Document (XML).................................................................................. 1032.1. Exemple de DTD du QCM (QCM.dtd) ............................................................................ 1032.2. Exemple du Schéma XML du QCM (QCM.xsd).............................................................. 1032.3. Exemple de DTD du contrat (contrat.dtd) ....................................................................... 1052.4. Exemple de QCM simple conforme au schéma QCM.xsd .............................................. 106

3. Méta données de Dublin Core................................................................................................ 1094. Ressource Description Framework......................................................................................... 112

4.1. Récapitulatif du vocabulaire utilisé dans RDF ................................................................ 1124.2. Exemple d’extension de Schéma RDFS......................................................................... 1134.3. Exemple d’utilisation du schéma : méta données au format RDF ................................... 114

5. RDF Site Summary (RSS)...................................................................................................... 1145.1. Schéma RDF des documents RSS ................................................................................ 1145.2. Exemple de fichier RSS de syndication.......................................................................... 116

6. Indicateurs des processus principaux de Microsoft SharePoint Portal Server 2001................. 1176.1. Indicateurs de gestion des documents ........................................................................... 1176.2. Indicateurs de souscriptions (abonnements aux alertes) ................................................ 1186.3. Indicateurs de recherches.............................................................................................. 1196.4. Indicateurs de fonctionnement du moteur de recherche ................................................. 119

7. Exemples de fichiers de transformation pour la publication..................................................... 1207.1. « presentation template » de Interwoven TeamSite Templating...................................... 1207.2. Squelette du Système de Publication pour l’Internet (SPIP) ........................................... 123

7.2.1. Contenu du fichier groupe_mot.html ...................................................................... 1237.2.2. Exemple de feuille de style CSS............................................................................ 1247.2.3. Copie d’écran de la page html de publication correspondante................................ 125

8. Modèle de données général d’un système de gestion de contenu .......................................... 125BIBLIOGRAPHIE ........................................................................................................................... 127

1

REMERCIEMENTS Je tiens à remercier toutes les personnes autour de moi qui m’ont accompagné tout au long de cette longue période ( septembre 2002 – mars 2004) de stage puis de rédaction de mémoire de fin d’études d’Ingénieur Informatique du CNAM. Tout d’abord, merci à Laurent Letourmy, directeur technique de Cross Systems Integration à l’époque où nous nous sommes rencontrés la première fois (avril 2002) et qui a mis en place ce stage, très adapté à ma situation personnelle, dans le cadre du projet « mise en place d’une offre en gestion de contenu ». Je remercie tous les autres collaborateurs de Cross Systems Integration Paris qui ont participé d’une manière ou d’une autre à mon travail : Rémy Poulachon, directeur technique qui a pris le relais de Laurent Letourmy, Christophe Blondel (qui m’a donné des retours de détail sur les travaux que j’ai réalisé, à savoir les prototypes), Loïc Cotonea avec qui j’ai échangé de nombreuses fois sur des problématiques de gestion de contenu avec lesquelles il était lui aussi confronté au sein de Cross Systems, Marcel Matton (Ingénieur informatique CNAM) de Cross Systems Genève qui m’a fait part de l’avancée des travaux sur le projet « gestion de contenu » à Genève et Antoine Griffon, à qui j’ai transféré le savoir-faire acquis et les archives de mon travail. Merci aux consultants du « bureau des consultants » de Cross Systems Paris avec qui j’ai partagé des moments chaleureux dans ce fameux bureau. Je remercie aussi tout particulièrement Bernd Amann (Maître de conférences), responsable de mon mémoire au sein du CNAM, et qui m’a consacré de nombreuses entrevues et à enrichi mon travail depuis le début de mon stage en septembre 2002 jusqu’à la fin de la rédaction en mars 2004. Je remercie aussi Michel Scholl (Professeur des Universités) d’avoir accepté ma candidature pour soutenir mon mémoire de fin d’études d’Ingénieur Informatique CNAM avec l’équipe « Bases de données » du laboratoire CEDRIC (Centre de Recherche en Informatique de CNAM). Enfin je remercie les membres du Jury de soutenance orale de mon mémoire en portant une attention particulière à Xavier Blondel et avec qui j’ai travaillé sur le projet Answork (place de marché électronique) chez Cap Gemini Ernst & Young. En effet, Xavier Blondel m’a donné de nombreux retours détaillés sur mon travail de rédaction en y apportant tout son savoir-faire d’Ingénieur Informatique et de Docteur en Informatique issu du CNAM Paris.

2

INTRODUCTION La gestion de contenu est un concept récent qui a vite pris beaucoup d’importance dans les discours, notamment marketing. Pourtant, comme le laisse entendre le terme, très générique, la gestion de contenu, ou du moins, plusieurs de ses domaines d’applications (gestion des bibliothèques, gestion électronique de document – GED), existe depuis plusieurs décennies. Le concept a été remis au goût du jour avec Internet et la gestion de site web et un de ses dérivés, les portails d’entreprise. Les systèmes de gestion de contenu peuvent donc recouper un ou plusieurs domaines d’application informatique. A ce titre, l’intégration entre ces applications est à l’ordre du jour puisqu’elles exploitent de nombreuses fonctionnalités communes. Quid du contenu ? Le contenu représente la convergence des documents avec les données. Le contenu est donc le résultat de la gestion des documents sous forme de données. Où s’arrête la notion de composant documentaire ? Et où commence celle de donnée ? La frontière devient floue avec la gestion de contenu et est certainement propre à chacun en fonction de sa culture métier (documentaliste, web master ou web designer, rédacteur…). L’informatique remet en cause la définition du document, notamment le langage XML (eXtended Markup Language). Dans notre cas, la gestion de contenu est l’informatique centrée sur le document, ou encore sur le contenu ; ce qui donne les termes « document-centric » ou « content-centric » en anglais. Le contenu peut être considéré comme l’information contenue dans un document. Toutefois, les documents peuvent être non structurés (auquel cas la présentation est mêlée au contenu – le texte – et le document la plupart du temps assimilé au support physique comme c’est le cas dans les systèmes de GED classiques) ou structurés (où le document est composé de sous-éléments, dits « composants documentaires », « éléments » ou « sous-documents » selon un schéma pré-établi). Dans le cas des documents structurés, le contenu peut-être séparé de la présentation, il peut alors être assimilé à une donnée (de type texte généralement, mais pas uniquement). La gestion de documents structurés peut s’effectuer conjointement avec celles des données, nous dirons alors qu’il s’agit de gestion de contenu à proprement parler. Un système de gestion de contenu doit comprendre un système de GED mais inversement, un système de GED, avec la définition que nous en donnons, ne peut comprendre un système de gestion de contenu. De même, un système de gestion de contenu doit comprendre un système de gestion de données, mais ne peut évidemment se suffire de cela : de nombreuses fonctionnalités, relatives à la collecte et la publication, devant être fournies nativement avec un système de gestion de contenu. La gestion de contenu est un concept transversal qui concerne tous les secteurs d’activités et tous les métiers de l’entreprise. Ils sont tous en effet utilisateurs et producteurs de contenu. Leur activité utilise et produit des documents, soit de manière directe (c’est l’objet de leur activité), soit de manière indirecte (les documents accompagnent la production elle-même, typiquement la documentation « produit »). La numérisation (digitalisation) des documents et de manière générale, la convergence vers le numérique des médias quels qu’ils soient (textes, images, sons), ajoute une importance toute particulière à la gestion de contenu qui a l’ambition de permettre la gestion de l’ensemble des médias dit non structurés. Il est communément admis que l’information, dans une organisation, est constituée à 20 % par des données structurées dans les applications informatiques et à 80 % par des données inclues dans des documents non structurés, électroniques ou non. L’enjeu est de tenter d’intégrer une part importante des 80 % restant de l’information dans les systèmes d’informations informatisés des organisations. La gestion de contenu pose aujourd’hui le problème de l’hétérogénéité des sources de contenus et de leur intégration et sa démarche propose une solution pour les unifier et permettre leur convergence. Les concepts majeurs de la gestion de contenu sont la modularisation des documents en composants documentaires et la séparation du contenu (des données) de la présentation ainsi que les méta données. Les autres concepts associés ne sont pas spécifiques de la gestion de contenu mais sont pleinement utilisés par les systèmes de gestion de contenu (CMS – pour Content Management System) : il s’agit principalement de la gestion des droits d’accès, des outils de travail collaboratif, workflow principalement, du versioning, de l’archivage et du stockage, de la personnalisation, de l’indexation, de la recherche et de la récupération de données.

3

Fruits d’un travail de recherche et d’expérimentation d’abord théorique puis pratique lors d’un stage pratique de fin d’étude d’Ingénieur Informatique, ce sont ces concepts qui vont être abordés à travers la première partie de ce rapport ; d’abord sous la forme de la description de l’utilisation de ces applications de gestion de contenu, puis en fonction de l’architecture et des fonctionnalités des systèmes de gestion de contenu. Chacune des domaines d’applications de gestion de contenu met en évidence des fonctionnalités clés de la gestion de contenu. Ces fonctionnalités sont à reprendre dans un système de gestion de contenu qui permettrait une stratégie de contenu unifié. Tous les contenus sont potentiellement gérables dans un seul et même système ! C’est ce que rapport va tenter de mettre en lumière en abordant chacune des fonctionnalités nécessaires et la manière dont elles doivent être organisées. De même, ce rapport tente d’identifier les avantages qui pourraient être attendus d’une intégration des données et des documents, mais aussi des documents entre eux, ce que permet la gestion de contenu. Des normes, des protocoles ou des langages sont présentés afin d’illustrer la possibilité de mettre en œuvre les concepts qui sont présentés. XML, langage promu et développé par le World Wide Web Consortium (W3C) est conçu en partie pour supporter les concepts de la gestion de contenu. Dans la deuxième partie, qui valorise le travail effectué au sein de la SSII Cross Systems Integration, on montrera une grille de classification fonctionnelle des logiciels de gestion de contenu (CMS), puis une évaluation détaillée de trois solutions de CMS d’éditeurs informatiques. Cette évaluation a permis de montrer qu’aucun des produits ne peut couvrir l’ensemble des fonctionnalités attendues au départ, tout en permettant de répondre à des besoins particuliers et en les dépassant parfois. L’objectif du stage était l’élaboration d’une offre de service dans ce domaine. A cette fin, il a été prévu et réalisé trois prototypes de solution de gestion de contenu sur la base d’un jeu d’essai commun (production de QCM – questionnaires à choix multiples), créé pour l’occasion. Ces prototypes peuvent servir de base pour une offre de mise en œuvre d’un certain type d’application de gestion de contenu (gestion de site web, intranet documentaire, portail associatif). Enfin, ce stage a aussi permis l’élaboration d’une méthodologie d’analyse et de conception d’un système de gestion de contenu pour l’entreprise. Ce qui est présenté dans ce mémoire peut permettre une implantation du système de gestion de contenu pour des documents au format électronique depuis leur création jusqu’à leur publication. La dématérialisation, autre concept associé, n’est par contre pas abordée. L’intégration des domaines d’applications de la gestion de contenu dans une logique unifiée permet de faire bénéficier des fonctionnalités communes d’un des logiciels d’un domaine à celui d’un autre. Il est ainsi possible d’unifier la base d’informations documentaires afin de faciliter leur découverte, leur récupération, leur accessibilité, leur diffusion et leur partage. Elle permet aussi une meilleure réutilisation. Ce mémoire est une contribution pédagogique constituant un préliminaire pour passer de la théorie à la pratique de la gestion de contenu. Il s’agit donc d’une présentation des concepts et des techniques du domaine de la gestion de contenu, domaine encore en cours d’évolution et d’élaboration. A priori, adopter une application informatique de gestion de contenu s’adresse à un besoin spécifique et limité dans l’entreprise qui peut bénéficier d’une industrialisation. C’est d’ailleurs pourquoi la plupart des logiciels ne proposent qu’un sous-ensemble des fonctions de gestion de contenu ciblé sur un domaine. Cependant, les besoins d’une organisation en matière de gestion de contenu peuvent évoluer vers un ou plusieurs autres domaines. Or comme nous l’avons déjà dit dans cette introduction, tous les métiers et tous les secteurs d’activité sont théoriquement concernés. Une organisation soucieuse de l’homogénéité de son système d’information préférera donc une solution technique unique. On préférera donc là encore choisir un logiciel dit « évolutif » offrant les nouvelles fonctionnalités désirées pour pouvoir l’étendre sans remettre en cause l’existant. Les concepts qui sont présentés dans ce rapport permettent d’adapter la solution de gestion de contenu aux besoins concrets et immédiats d’une organisation tout en laissant l’opportunité de gérer tous les documents de tous les services d’une organisation, c’est à dire l’opportunité d’une gestion de contenu « universelle » et « unifiée ».

4

CONTEXTE, OBJECTIFS ET APPROCHE Ce rapport s’appuie sur un stage réalisé en entreprise et devant servir de support au présent mémoire de fin d’études d’Ingénieur Informatique du Conservatoire National des Arts et Métiers. L’entreprise avec laquelle j’ai réalisé ce stage est l’agence parisienne de Cross Systems Integration, membre du groupe Cross Systems ayant des implantations en Suisse (Genève) et en France (Paris, Lyon, Annecy) et comptant environ 400 salariés. Le groupe compte comme autres sociétés Cross Institute (agence de formation) et Cross Agency (agence spécialisée dans le graphisme, entre autre pour les sites web). Cette société de services et d’Ingénierie informatique (SSII) a comme stratégie l’application des nouvelles technologies (Internet, mobiles et serveurs JEE et .Net) dans les systèmes d’informations. Ses principaux partenaires éditeurs informatiques sont Borland, IBM et Microsoft. L’objectif et l’intitulé du stage étaient « développement d’une offre de service « Content Management » pour les entreprises ». Ce travail était inclu dans les objectifs d’un groupe de travail ayant le même objectif et le même intitulé. Le groupe de travail était initialement constitué d’un directeur technique, du responsable marketing et d’un consultant pour l’agence de Paris. D’autres équipes en Suisse et à Lyon travaillaient parallèlement. Les travaux du groupe de travail ont fait l’objet de réunions, de retours et de comptes rendus réguliers. Deux sous-objectifs majeurs étaient poursuivis : premièrement, connaître le domaine (périmètre fonctionnel et marché), savoir évaluer les outils du domaine et deuxièmement, batir des prototypes d’application avec les outils retenus afin de dégager des références dans la mise en œuvre de projet avec ces outils. Nous répondions alors à une politique de développement et de croissance interne. Les difficultés que nous avons rencontrées ont été les suivantes : difficulté de cibler les clients potentiels, chute du marché des services informatiques ayant occasionné des réorganisations, une réduction des effectifs et une redéfinition des priorités de l’agence et enfin, en partie à cause de cela, difficulté de coordonner les efforts dans le domaine de la gestion de contenu entre les différentes agences, sachant que l’agence de Genève disposait de quelques références dans le domaine de la GED et des portails. Toutefois, les résultats de nos travaux étaient échangés régulièrement. La difficulté de cibler la clientèle est une des raisons principales pour laquelle notre approche est assez générale. 1. Les travaux préliminaires ont concerné l’établissement du périmètre fonctionnel et du marché de la gestion de contenu et l’analyse des fonctionnalités proposées par des éditeurs des logiciels de gestion de contenu. J’ai pour cela réalisé une étude bibliographique et consulté des ressources disponibles sur Internet. Un des premiers travaux a consisté à constituer une liste de mots clés relatifs à la gestion de contenu. Ces mots clés ont fait l’objet ensuite d’une recherche sur différents moteurs et annuaires (Google, WebCrawler et Voila) en anglais et en français. On a aussi effectué cette recherche sur les librairies en ligne (Lavoisier, Eyrolles et Fnac) et la presse informatique en ligne (ZdNet, 01net, « Le Monde Informatique »). Les résultats des recherches de livres ont fourni les références des ouvrages écrits mais aussi la plupart du temps leur sommaire et leur résumé permettant d’avoir une vue synthétique de la littérature du domaine, de découvrir les mots clés récurrents et associés ainsi que les concepts communs. Un des objectifs était de recenser et d’identifier les principaux acteurs et les normes du domaine. Concernant les acteurs, on a cherché à identifier les institutions nationales et internationales, les éditeurs de logiciels ainsi que les sites et la presse spécialisés, généralement édités par des consultants indépendants intervenants dans le domaine mais aussi les universités et grandes écoles intéressées, à travers notamment des conférences internationales existantes sur le sujet. Dans un deuxième temps, les sites Web des acteurs du domaine ont été visités. La littérature ayant servi ainsi à construire une image du domaine a été du type des « livres blancs », « data sheets », « success stories » commerciales, rapports de mémoires et extraits de livres. De plus, les sites ayant souvent une rubrique présentant les ressources d’Internet du type « liens intéressants », on a pu ainsi découvrir de nouvelles ressources restées cachées dans les moteurs de recherche généraux. On a pu aussi consolider les premiers résultats en notant des renvois vers des ressources déjà repérées. Ce dernier point est fondamental, car c’est ainsi que l’on peut conclure que l’essentiel des ressources a été identifié. J’ai pu aussi rencontrer les acteurs du domaine en allant visiter des salons professionnels (Forum de la GEIDE, Documation, i-expo). On peut noter que ce qui est le plus difficile à obtenir est le retour d’expériences concrètes dans le domaine.

5

Les sites des institutions faisant mention des normes qu’ils préconisent, voire promeuvent, nous sommes ensuite allés récupérer des ressources traitant de ces normes (spécifications et tutoriaux). Les normes sont aussi mentionnées dans les descriptions accompagnant les ouvrages écrits distribués par les librairies électroniques. Finalement, cette recherche a été maintenue actualisée par des abonnements : abonnements à des alertes sur le sujet auprès des librairies et de « syndicateur » (fédérateur) de littérature sur l’information technologique du domaine, ou abonnement à des « lettres » mensuelles d’éditeurs informatiques ou de sites spécialisés de consultants. Par ailleurs, j’ai pu participer à une formation partenaire « Stellent Certified Consultant » de cinq jours sur les produits Stellent Content Server et Stellent Content Publisher. Cette première partie du stage a donc permis de réaliser un panorama du domaine de la gestion de contenu et de ses sous-domaines d’applications, présentant pour chacun ses domaines d'application secondaire, ses fonctionnalités transverses, ses méthodes, modèles et langages informatiques associés, ses normes associées, ses logiciels typiques évalués ou aperçus, les informations cibles, les clients typiques, les projets phares, les organisations (institutions) phares et enfin une définition simple. Finalement ce premier travail a surtout permis d’élaborer une grille de classification fonctionnelle des logiciels de gestion de contenu par sous-domaine d’application. Dans le même temps, j’ai réalisé une liste des besoins (exigences) auxquels répondent les logiciels de gestion de contenu. 14 logiciels ont été évalués fonctionnellement de cette manière. Cela a permis de retenir les logiciels devant faire l’objet d’une évaluation technique à travers la mise en œuvre d’un prototype. D’autres logiciels de gestion de contenu peuvent faire l’objet de cette grille d’évaluation fonctionnelle. La première partie du stage fut théorique, la seconde pratique. 2. La deuxième partie du stage a consisté à élaborer un jeu d’essai afin d’évaluer de manière homogène les logiciels faisant l’objet d’une évaluation technique détaillée sur la base de la réalisation d’un prototype dans chaque cas. 3 logiciels ont été ainsi installés, paramétrés et testés. Le type de document retenu pour l’évaluation a été le questionnaire à choix multiple (QCM). Le QCM est dans sa nature un document pouvant être fortement structuré et le groupe de travail l’a retenu comme représentatif pour éprouver les concepts de la gestion de contenu. L’évaluation technique des produits a donné lieu à la rédaction d’un cahier des charges précisant les objectifs, la méthode et les livrables. La mise en œuvre du jeu d’essai pour la réalisation des prototypes a donné lieu à la rédaction d’une offre de marché et d’un document de spécifications fonctionnelles du projet de gestion de contenu, objet des prototypes. Il a fallu récupérer aussi du matériel (des QCM) sous des formats multiples, afin d’approcher la problématique réelle des entreprises. Ce matériel a été retouché afin d’être publiable sous une forme réaliste et utilisable. Les logiciels ont été installés sur des serveurs dédiés. Ils ont été paramétrés conformément aux spécifications fonctionnelles. Ce paramétrage a pu parfois revêtir l’aspect d’un développement de code informatique. La lecture des manuels d’utilisation (de l’administrateur et de l’utilisateur) des logiciels a aussi été une source d’information non négligeable. L’installation constituait un critère d’évaluation. La facilité, la souplesse et la richesse du paramétrage ont pu aussi être évaluées. Deux phases principales se sont déroulées à chaque fois. Premièrement, il s’agissait de voir comment récupérer et intégrer les documents existants dans l’entreprise dans le nouveau système de gestion de contenu (CMS). Deuxièmement, il fallait tester à chaque fois, la capacité à assurer la production (collecte, gestion, publication) des QCM suite à la mise en œuvre du CMS. La gestion de contenu, qui peut impacter le système de collecte (éditeurs de documents principalement) et le système de publication, pose largement le problème de la gestion de l’héritage des applications pré-existantes assurant une partie des fonctionnalités de la gestion de contenu. La mise en œuvre d’un CMS débouche soit sur une migration complète (très difficile et coûteuse à mettre en œuvre), soit sur le maintien temporaire mais durable de deux architectures logicielles concurrentes sur certains aspects. Des critères d’administration du système (importation, exportation de données et de documents) ont été ajoutés aux critères ne touchant que les fonctionnalités de gestion de contenu.

6

Chaque CMS testé étant spécifique à un sous-domaine d’application (gestion de site web, intranet documentaire sans utilisation de modèle de document, portail associatif), on a tout de même cherché à exploiter au maximum ses possibilités. Cependant, des fonctionnalités identifiées comme requises dans les spécifications et l’offre de marché n’ont pas pu être mises en œuvre dans certains cas. Les tests ont donc permis de noter à la fois la couverture fonctionnelle des CMS et la qualité de cette couverture le cas échéant. Une grille de notation a été remplie, avec notamment la possibilité d’intégrer des coefficients de pondération pour chaque note attribuée à chaque fonctionnalité afin d’évaluer le CMS en fonction de l’importance du besoin de ces fonctionnalités, permettant dans certains cas à un CMS de se placer devant un autre et dans d’autre cas, se placer derrière. Cette grille de notation a été appuyée par un document reprenant des commentaires et des observations pour chaque fonctionnalité et la notation globale. La méthode et les spécifications peuvent être utilisées pour évaluer et comparer d’autres CMS. Une limitation importante est à noter dans l’expérience réalisée. On ne disposait que d’un type de document pour tester les CMS. Il aurait été intéressant de tester les CMS avec d’autres types de documents. L’intégration dans les CMS d’un autre type de document (les contrats de commandes de QCM) a été envisagée théoriquement mais pas mis en œuvre pratiquement. 3. La troisième partie du stage a valorisé le travail d’analyse effectué préalablement. Il s’est agit principalement d’un travail de capitalisation des deux premières parties. On a donc pu élaborer une méthodologie d’analyse et de conception de système de gestion de contenu pour l’entreprise. Cette méthodologie a fait l’objet d’un document spécifique. Elle peut être utilisée dans le cadre d’une offre de service de conseil et d’assistance à maîtrise d’ouvrage dans un projet de gestion de contenu. La méthodologie a été construite de manière à répondre à des besoins plus ou moins importants en matière de gestion de contenu : elle peut s’appliquer à un petit projet de gestion de site web, comme elle peut être utilisée pour un projet de gestion de l’ensemble des documents d’une entreprise ; chaque partie n’étant pas à appliquer dans le premier cas, tout étant à appliquer dans le second cas. L’idée directrice de la méthodologie est que le travail réalisé dans le cadre d’une application départementale de gestion de contenu doit pouvoir être ensuite intégré dans un projet plus large de gestion de contenu. Par ailleurs, on a déterminé quelle pouvait être l’utilisation raisonnable, dans le cadre d’une offre de service technologique, des trois différents logiciels de gestion de contenu testés. On a capitalisé sur ce qui est commun aux différents domaines d’application de la gestion de contenu. Cependant, certains aspects avancés ou très spécifiques de chaque type d’application de gestion de contenu n’ont pas été abordés. Par exemple, la gestion des plans de classement physique d’une bibliothèque n’est pas mentionnée. Elle nécessite cependant une prise en compte en cas de gestion d’une documentation physique (papier, matériel audio-visuel). Autre exemple, la lecture automatique de document (LAD), technique associée traditionnellement à la GED, nécessite une étude sérieuse sur sa mise en œuvre : choix du matériel de numérisation, automatisation éventuelle de certaines taches spécifiques (Reconnaissance Optique des Caractères) jusqu’à un processus complet de traitement (intégration des documents papiers scannés à une base de données par exemple). Mon travail n’aborde pas ces aspects qui peuvent se révéler fondamentaux dans un projet de gestion de contenu. L’adaptation du système de gestion de contenu en système de gestion de la connaissance (knowledge management - KM) est aussi un point important des fonctionnalités de la gestion de contenu qui sert ensuite dans un autre système. Pourtant on peut dire que la base documentaire est un élément d’un système de gestion de la connaissance (KM). La liste des fonctions supplémentaires est importante. Elle est reprise dans le panorama des domaines d’applications de la gestion de contenu fournie lors de la première phase du stage et dans le premier chapitre de la première partie de cet ouvrage sous forme d’évocation, ainsi que dans le premier chapitre de la partie B.

7

A. LES SYSTEMES DE GESTION DE CONTENU (CMS)

1 Cas d’utilisations Ce chapitre est une présentation générale et synthétique des domaines de la gestion de contenu. Il permet une familiarisation avec les utilisations concrètes qui sont faites des concepts de la gestion de contenu. De même, il aborde les grandes fonctionnalités de chaque domaine.

1.1. Gestion des bibliothèques physiques Une des premières grandes applications traditionnelles de la gestion de contenu est la gestion physique des bibliothèques. Les deux grands acteurs des bibliothèques sont les documentalistes (bibliothécaires) et les membres (utilisateurs). Traditionnellement, l’objet géré est le livre au format papier et s’étend aujourd’hui à l’ensemble des médias disponibles sur un support physique : périodiques (journaux), disques de musiques (CD audio), vidéos (cassettes VHS, DVD). La bibliothèque s’appelle désormais médiathèque. L’activité principale de la bibliothèque est la mise à la disposition de ses ressources à l’usager pour l’emprunt (ou réciproquement le prêt). Cependant, afin d’offrir un service attrayant, elle va chercher à proposer le plus de « titres », c’est à dire des références, à ses membres abonnés. Une fonction centrale est donc l’acquisition de ressources. Le volume d’objets gérés dans une bibliothèque dépasse en général plusieurs milliers. Face à ce volume, le besoin d’une gestion informatisée de ces références s’est fait sentir. Aussi, les SIGB (Systèmes Intégrés de Gestion des Bibliothèques) ont-ils été parmi les premières applications informatiques professionnelles. Le plan de classement est donc un des outils fondamentaux d’une bibliothèque. La référence d’un ouvrage reprend les informations de l’emplacement de l’objet dans le bâtiment et les étagères. Afin de mettre en valeur leur offre, les bibliothèques proposent un catalogue de leur fonds bibliographique. Le fonds bibliographique est l’ensemble des œuvres et de leur description que possède la bibliothèque. Chaque œuvre fait donc l’objet d’une notice (terme professionnel du monde de la documentation) qui reprend l’ensemble des informations décrivant une œuvre. Cette notice fait l’objet d’une norme internationale qui est UNIMARC [1] (MARC - Machine Readable Catalogue - ISO 2709) décrivant le fonds et la forme d’une notice [2] [3]. La bibliographie est donc rédigée et gérée sous forme de notice et peut contenir avec le format UNIMARC jusqu’à 400 champs descriptifs environ. Les champs les plus importants sont le titre, l’auteur, les mots clés et la catégorie de l’ouvrage. La catégorisation, dont les synonymes sont taxonomie, classification, est le « rangement » logique de l’œuvre par domaine, ou encore par sujet. Confronté à l’objectif de classer l’ensemble des ressources bibliographiques existantes, les bibliothécaires ont créé plusieurs classifications universelles dont l’Universal Decimal Classification (UDC1) et la Dewey Decimal Classification (DDC2). Un des travaux les plus importants des documentalistes est la rédaction de bibliographies sur les ouvrages. Ce sont aujourd’hui les champions des méta données. Ils favorisent ainsi, en « digérant » l’information, l’accès aux ressources. A ce titre, ils ont été les premiers à mettre en œuvre concrètement la notion de méta donnée. Ils jouent donc un rôle important dans la gestion de la connaissance (knowledge management) en permettant l’accès aux ressources documentaires,

1 Universal Decimal Classification Consortium : http://www.udcc.org/ 2 Dewey Decimal Classification Home Page (OCLC Forest Press) : http://www.oclc.org/dewey/

8

notamment aux apprenants, mais aussi aux chercheurs, grands utilisateurs des bibliothèques, notamment celles à vocation professionnelle. Toujours dans l’optique de proposer un service qui permette d’accéder à l’ensemble des ressources existantes dans le monde, c’est à dire un service universel, les bibliothèques ont conclu des alliances afin de mutualiser leurs fonds bibliographiques. Ainsi un membre d’une bibliothèque est membre des bibliothèques associées. On parle alors de prêt inter-bibliothèques. Ou encore, elle propose à l’usager d’interroger le fonds d’autres bibliothèques ; charge à lui d’emprunter la ressource auprès de la bibliothèque la possédant. Une norme permettant l’interrogation inter-catalogue et la récupération des informations bibliographiques est la norme ISO 23950 [4] mise en œuvre dans les serveurs Z39.503 [4] [5]. Aujourd’hui, les bibliothèques sont confrontées à la numérisation [6] des ressources qu’elles gèrent [7]. On pourrait imaginer, avec la tendance actuelle, qu’elles disparaissent au fur et à mesure de la numérisation des œuvres pour être remplacées par des systèmes de gestion électronique de document (GED). Ou encore, certains nouveaux documents n’existent maintenant qu’uniquement sur format numérique et sont en tout cas crées au format numérique. Dans ce nouveau monde, la notion de prêt n’a plus cours, le coût de la duplication et de la distribution de l’œuvre étant négligeable. La gestion des droits numériques (DRM – Digital Rights Management), notion afférente au droit d’auteur (copyright) prend le relais. C’est d’ailleurs la gestion des emprunts (de livre) qui fait l’objet de l’autre activité majeure des bibliothèques. On parle de bibliothéconomie (l'ensemble des techniques de gestion du livre dans les bibliothèques : conservation, rangement, communication...). Inversement, on continuera certainement à utiliser et gérer des documents (notamment les livres) sous des formats physiques pendant un temps non négligeable. Chaque entreprise possède de manière formelle ou informelle une bibliothèque. L’utilisation d’un système de gestion intégré des bibliothèques peut donc être une des applications de la gestion de contenu dans les entreprises. L’édition et l’utilisation des méta données pour accéder à des ressources physiques est la fonctionnalité majeure que l’on peut retenir de la gestion des bibliothèques.

1.2. Edition de document composite L’édition de documents composites (« compound documents » en anglais) est aussi une technique éprouvée depuis maintenant plus d’une décennie. Les entreprises souvent citées sont celles de l’industrie aéronautique [8] ou pharmaceutique et médicale [9]. En fait la problématique de l’édition de document composite, à travers l’édition de la documentation technique, s’étend là encore à tous les secteurs d’activité, même si l’édition (secteur du livre) est plus particulièrement visée [10]. Il s’agit premièrement de créer (mettre à jour) un document qui se décompose en parties rédigées par des rédacteurs multiples. On aborde là un élément majeur de la gestion de contenu : le document « final » est décomposé en sous-éléments fils, ou encore sous-composants. Autrement dit, il s’agit de structurer les documents autant que possible selon un modèle spécifique à chaque type de document. Un autre élément qui se déduit de cette définition est le travail collaboratif : plusieurs auteurs interviennent ensemble sur le même document, en parallèle ou séquentiellement, parfois avec des rôles différents, notamment d’écriture ou de validation [11]. Une documentation technique en vient à être considérée ainsi comme un projet et gérée avec des outils communs. La décomposition des documents ouvre la porte à leur recomposition et donc à des formats de sortie variés, tant sur la forme que sur le fond. La réutilisation des composants documentaires est rendue possible. Pratiquement chaque produit ou service requiert une documentation associée. Les entreprises pionnières dans ce domaine considèrent la documentation technique comme un produit « manufacturé » qui doit satisfaire des contraintes de planification. Ces compagnies planifient en tandem le cycle de vie d’un produit et sa documentation associée. La distribution de la documentation

3 ANSI/NISO Z39.50-1995 Information Retrieval / Maintenance Agency for Z39.50 is the US Library of Congress

9

technique [12] présente aussi plusieurs problèmes. Les manuels au format « papier » sont appropriés pour un grand nombre d’applications, mais sont chers à produire et distribuer et ne peuvent pas être mis à jour facilement. Les attentes des utilisateurs, notamment les clients, pour accéder à l’information technique croissent. Les clients veulent une documentation imprimée (ou imprimable), une aide en ligne et un accès via Internet à l’information adéquate. Les clients du support technique ont aussi besoin de ressources techniques écrites, alors que les services de formation utilisent la même information de manière différente. Un défi de taille est d’éditer cette information de manière efficace afin qu’elle soit distribuée à une grande variété de publics dans des formats différents. Dans l’industrie automobile, le cycle de vie de l’information commence généralement avec les données d’ingénierie (notes, cahier des charges, spécifications, résultats de tests et plans). Ensuite viennent les informations comme celles nécessaires à la maintenance et l’utilisation des véhicules, au support de fabrication et au matériel de formation des agents. L’entreprise doit pouvoir facilement collecter, réorganiser et maintenir cette information tout en maintenant une cohérence irréprochable entre ces documents qui peuvent parfois concerner différentes lignes de produits. Considérons les opportunités de réutilisation pour seulement un type de document, le manuel du conducteur, fourni avec chaque nouveau véhicule. La procédure pour changer un pneu, par exemple, doit être la même pour tous les modèles de véhicule d’un fabricant donné ! Comparez la gestion unifiée du contenu avec le fait de devoir écrire et mettre à jour cette documentation séparément pour chaque modèle de véhicule. Sachant que distribuer dans une forme utilisable et à jour la documentation pour chaque utilisateur, du mécanicien débutant au gestionnaire de flotte, est compliquée par des changements fréquents et réguliers dans la fabrication des véhicules : un modèle de voiture standard est re-conçu chaque trois-cinq ans alors que des changements de fabrication de moindre importance sont introduits tous les six mois ! Au total, ce sont des centaines de procédures qui sont reproduites à tous les niveaux alors que quelques-unes uniquement changent mais pas systématiquement pour les dizaines de modèles de véhicules que produit la société automobile. Quand il s’agit de l’industrie aéronautique ou nucléaire [13], les contraintes de sécurité (par rapport au risque d’accident mais aussi de piratage) sont telles que les processus d’écriture et de mise à jour doivent être soumis à des schémas de validation et d’approbation complexes et lourds, amplifiés par le fait que l’accès à ces mêmes informations doit être strictement réglementé. Une des principales difficultés que rencontrent les industries qui favorisent la gestion de contenu appliquée à leur documentation technique est la variété des sources de contenu : schémas et dessins (plans) issus d’outils de CAO et DAO (conception et dessin assistés par ordinateur), textes sous de multiples formats. Par ailleurs, la mise en forme des « sorties » des documents doit répondre à des exigences fortes de présentation (ergonomie) en fonction des utilisateurs. L’intégration entre le CMS et les autres applications d’édition de documents (ou de données) est indispensable pour maintenir la cohérence des données. Les systèmes de gestion de contenu utilisés mettent donc en oeuvre la séparation du contenu et de leur mise en forme. Ainsi l’auteur ne travaille plus sur une mise en forme fine (application de taille, de typographie, de style : police, couleur…) lors de la rédaction mais sur l’association d’étiquettes (tags) avec les différents éléments de son document. La mise en forme est ensuite appliquée aux éléments en fonction des étiquettes, automatiquement, après développement d’un fichier (script) de transformation, en fonction du format de sortie désiré. Les documents doivent alors être rédigés à partir de gabarits (template) ou autrement dit sur la base de modèles de document. Les applications d’édition de documents peuvent aussi appliquer des contrôles en fonction de la structure du document : si un élément n’est pas renseigné, l’auteur, par exemple, ne peut pas enregistrer le document créé ou mis à jour ou tout du moins, ne peut pas soumettre son document dans le processus de mise à jour. Cela réduit le risque d’erreur grâce à un contrôle a posteriori de la structure du document avec celle du modèle. Grâce à la séparation du contenu et de la mise en forme, non seulement la mise en forme peut être choisie ultérieurement, et être multiple alors que le contenu reste unique. Mais on peut aussi rajouter des fonctions de traitement automatique telles que la réalisation d’un sommaire, d’index, de liste des illustrations ou autres qui aident l’utilisateur final (le lecteur) dans sa navigation dans le document. D’autres fonctions concernent la finition des livres (document volumineux) comme la mise à jour des références croisées internes, la synthèse de hauts et de pieds de page. De même, la traduction des documents peut être assistée par ordinateur et rendue plus pertinente grâce à ces étiquettes, que l’on peut assimiler à des méta données dans la plupart des cas.

10

Les pages html des sites web sont aussi des documents composites puisqu’elles peuvent contenir des fichiers associés : images, sons, vidéos… Parfois, certaines images, par exemple, sont partagées entre plusieurs pages et donc réutilisées. Aujourd’hui, sur certains sites web (presse, portails grand-public), ces pages sont de véritables assemblages de composants de sources multiples, dont les contenus sont mis à jour par des entreprises différentes à des fréquences très rapides (météo, cours de la bourse, nouvelles d’agence de presse, alertes diverses). Nous aborderons leur utilisation dans les chapitres 1.4. et 1.5..

1.3. Gestion documentaire (référentiel d’entreprise ) La gestion documentaire est un domaine traditionnel dans la gestion de l’entreprise au sens large. Toutes les entreprises y sont confrontées indirectement (administration et finance, notamment le courrier entrant et sortant, documentation technique), et certaines directement (productions intellectuelles – presse, édition, conseil…). De même, la numérisation des ressources y joue un rôle majeur. Si l’on regarde la définition [14] du mot document : « n. masc. Écrit, objet ayant valeur de preuve, de témoignage ou d'information. Document historique, scientifique, photographique. Cet enregistrement est un document rare. Document humain : scène (vue ou filmée) qui fournit des renseignements sur les mœurs d'une société, d'un groupe. COMM. Titre accompagnant une marchandise dans son transport (connaissement, police d'assurance, facture). Document comptable : pièce servant de base à une écriture comptable », on comprend le cœur de la seconde génération de système de gestion de contenu regroupée sous l’acronyme GED. Il s’agit de fiabiliser ou permettre, en cas de volumes important (chèques bancaires par exemples), l’archivage des documents afin de restituer la preuve le cas échéant. D’où aussi, les normes du domaine (NF Z 42-013 et ISO 15489-1) qui garantissent le système et donnent une valeur légale aux documents électroniques. D’où là encore l’intégration des normes concernant l’authentification des documents à l’aide de certificats numériques (signature électronique). Cette évolution est très importante pour l’administration et la gestion (comptabilité) puisque les factures, justificatifs jusque là archivés et stockés sous format papier vont pouvoir être archivés sous format électronique. Ainsi, sur le site de l’APROGED (Association des Professionnels de la Gestion Electronique de Documents), on donne l’exemple du comptable. Celui ci aujourd’hui retrouve une ligne comptable (une écriture) en 1 à 2 secondes en moyenne dans son système informatique. Par contre, il lui faut entre 5 et 15 minutes pour trouver le justificatif correspondant. Il y a donc un gain de productivité important à attendre de la numérisation des documents administratifs et comptables dans un système compatible ISO 15489-1 [15]. L’association internationale regroupant les acteurs de la GED est l’AIIM, « l’Enterprise Content Management Association », anciennement « Association for Information and Image Management »4. La GED est aussi appelée GEIDE pour Gestion Electronique d’Informations et de Documents Existants. Pour échanger des documents issus ou à destination de système de GED, on utilise l’EIDE (Echange d’Informations ou de Documents Electronique) qui tend à être normalisée avec un format compatible XML. Toutefois, cette norme n’a pas encore de reconnaissance internationale [16] [17]. La GEIDE a pour vocation de fédérer et de gérer tous les types de documents, y compris ceux qui se trouvent déjà sous une forme électronique. En plus des documents papier, les types de document les plus fréquemment rencontrés sont les suivants : télécopies, documents bureautiques issus de logiciels de traitement de texte, de tableurs, graphiques et plans, courriers électroniques, fichiers informatiques et en particulier les fichiers sons, images animées... La numérisation des documents est au centre des techniques mises en œuvre dans les systèmes de GED. La lecture automatique de document (LAD) est une partie un peu restrictive de l’acquisition des documents dans le système de GED. Elle utilise le scanner pour numériser les documents papiers et les transférer sur un support électronique. Les autres documents sont sous format électronique. Il faut toutefois les traiter pour les inclure de manière correcte dans le système de GED. A chaque forme de

4 Enterprise Content Management Association : http://www.aiim.org/

11

document correspond un type d'appareil ou un dispositif logiciel : scanner, carte fax, logiciel de transfert de fichier. L'acquisition peut comporter plusieurs étapes : par exemple l'interprétation ou la conversion de format du document, l'adaptation de sa structure et de sa composition, sa récupération par un dispositif de stockage ou de traitement. En même temps que l'on saisit les documents, il faut procéder à l'acquisition des index qui serviront au classement et à la recherche ultérieure des documents. L'indexation est une étape essentielle et indispensable au bon fonctionnement d'un système de GEIDE. Du choix d'une méthode pertinente d'indexation jusqu'à la conception soigneusement étudiée des index, rien ne doit être laissé au hasard. Les index, dans la terminologie de la GED, correspondent aux méta données dans la terminologie de la gestion de contenu. De ces index et du système d'indexation dépendent la performance du système de GEIDE et son adéquation aux besoins de l'entreprise. Pour acquérir des index, on a le choix entre plusieurs techniques, dont la plus simple mais aussi la plus adéquate dans de nombreux cas, est l'acquisition manuelle par remplissage d'un formulaire associé au document. On est confronté là à un des points noirs de la GEIDE car l'acquisition des index est une étape fastidieuse qui peut nuire à la rentabilité du système et entamer la motivation des utilisateurs. On peut acquérir ces index par d'autres méthodes qui dépendent des documents traités et des applications mises en oeuvre. Citons l'extraction automatique de mots-clefs par programme pour les documents électroniques formalisés du genre états informatiques (Intelligent Mark Recognition – IMR), l'analyse full-text (texte intégral) des documents, la reconnaissance optique de caractères (OCR) pour des textes dactylographiés ou manuscrits, l'utilisation de codes à barres ou toute combinaison de ces différentes techniques. L'indexation des documents est l'opération qui consiste à décrire les documents en vue de leur exploitation ultérieure. La description d'un document va porter sur deux plans distincts mais complémentaires : - une description externe contenant des informations sur le type de document, son origine, la date de sa prise en charge ou de sa création, pour les activités administratives ou techniques, le rattachement aux objets de base de l'entreprise (client, fournisseur, produit, etc., ...), - une description du contenu ; les enjeux de l'indexation et les difficultés se situent à ce niveau. L’autre partie centrale de la gestion électronique de documents est l’archivage. Elle met en œuvre l’ensemble des techniques existantes dans ce domaine du moment qu’elles sont compatibles avec la norme NF Z 42-013 : SAN (Storage Area Network), disques RAID, support magnétique DAT, Compact Disc (Juke Box)… L’archivage nécessite impérativement de définir des règles pour le cycle de vie du document afin de pouvoir gérer sa destruction ou son enregistrement sur des supports inertes. Il est illusoire dans l’état de nos connaissances de garder l’ensemble des documents produits au cours de l’histoire d’une organisation. Il faut citer maintenant une des fonctionnalités importantes des systèmes de gestion de contenu favorisée par la GED. Il s’agit de la gestion des versions de documents. La plupart des CMS propose aujourd’hui cette fonctionnalité qui permet d’accéder aux versions anciennes d’un document. Certains y ajoutent des extensions logicielles qui permettent de comparer les versions et de gérer les conflits de versions, notamment lors de mises à jour distribuées. L’intervention humaine en fin de traitement reste indispensable si le conflit nécessite un choix entre deux versions concurrentes. On introduit ici une nouvelle dimension de la GED (mais pas spécifique) relative aux documents produits initialement sur support informatique. En plus du versioning, on va trouver la partie groupware et notamment la gestion des processus d’édition et de publication à travers ce qui est appelé communément le workflow. Dans de nombreuses situations, la transmission et l'échange de documents entre plusieurs utilisateurs seront facilités ou organisés avec des outils tels qu'un logiciel de workflow ou un outil de groupware (groupe de travail). Ces situations sont celles où plusieurs personnes travaillent en groupes organisés sur la base de règles et de procédures pour effectuer des travaux d'ordre administratif ou technique: gestion de courrier, traitement des commandes, traitement des sinistres en assurance, instruction des demandes de prêts dans les banques, etc.

12

Les finalités principales d'un logiciel de workflow sont l'ordonnancement et le suivi des travaux au sein d'unités de travail selon des procédures et des règles préétablies. Ce type de logiciel prend en charge de nombreuses tâches ; en particulier, il régule les enchaînements d'opérations, assure la circulation des dossiers à traiter sur les différents postes de travail, surveille les priorités de travaux, gère les délais, assure les synchronisations et déclenche les alertes. Pour toutes ces actions, on établit des liens directs entre les logiciels de workflow et les documents électroniques : ces derniers sont pris en charge par le logiciel de workflow qui, en fonction de règles définies, en assure la distribution sur les postes de travail dans des corbeilles individuelles ou collectives, et prend en charge l'ensemble des déplacements tout au long de la chaîne de travail. La mise en oeuvre de solution de workflow conduit naturellement à une forte intégration du système de GEIDE au système d'information de l'entreprise. En effet, pour faciliter l'exécution des travaux sur les postes de travail à l'arrivée des documents, on établit des enchaînements automatiques permettant l'accès direct aux applications informatiques, aux outils de production bureautique ; en retour, on facilite la recherche de dossiers électroniques à partir des bases de données de gestion. On est ainsi conduit à définir et à réaliser des postes de travail sur lesquels les différents outils sont intégrés en fonction du métier de l'utilisateur ; l'objectif recherché est l'efficacité de l'utilisateur et la banalisation de l'emploi des différentes techniques, GEIDE en particulier. Les liens entre documents et outils de groupware sont de même nature, avec comme idée directrice la mise en commun d'un ensemble de dossiers et de documents. Une mention particulière doit être faite des outils de communication tels que les messageries : elles constituent fréquemment le cadre dans lequel les utilisateurs effectuent entre eux des communications non structurées de documents. Autre élément indispensable, les logiciels de GED permettent de gérer les accès aux documents en création, mise à jour, lecture et destruction. Ces différents droits sont définis dans les modèles de sécurité propres à chaque entreprise. C’est une des fonctionnalités majeures de l’ensemble des CMS. Les utilisateurs dans les CMS ont un rôle central et multiple et interviennent dans : - l’accès au document (lecture, mise à jour, destruction), - les droits d’auteur (cf. Digital Rights Management – DRM), - le profil utilisateur (cf. Personnalisation dans les portails d’entreprise) et la personnalisation, - les compétences, les expertises qui sont rattachées notamment à des personnes, utilisateurs et auteurs, dans les systèmes de gestion de la compétence. Cette remarque, valable pour l’ensemble de la gestion des applications informatiques, requiert une gestion centralisée et unique des utilisateurs dans des annuaires de type LDAP auxquels doivent pourvoir se connecter les applications de CMS. Il faut envisager par la suite une gestion plus fine et poussée des utilisateurs dans les annuaires de type LDAP pour y faire apparaître l’ensemble des informations importantes concernant l’utilisateur. In fine, les EIP (portails d’entreprise) doivent pouvoir proposer dans leur interface de recherche, une recherche sur les informations utilisateurs contenues dans le(s) annuaire(s) LDAP. On rejoint un peu ici la tentative de Microsoft à travers son « Passeport ». A ce niveau, sont aussi inclues les fonctionnalités d’authentification (signature électronique, certificats). L’auteur d’un document fait partie des données descriptives d’un document ou encore des méta données d’un document mais est aussi relatif à l’utilisateur. Les rôles les plus fréquemment retenus dans les flux de travail et d’édition de document sont l’auteur, le correcteur (facultatif) et le validateur (« directeur de publication ») qui autorise ou rejette la publication officielle d’un document. Certains projets nécessitent des flux de travail plus complexes (mise à jour distribuée et/ou parallèlisation des mises à jour et de la validation), notamment pour des projets comprenant plusieurs documents liés les uns aux autres et objets d’organisation et de droits différents. Ces flux sont gérés dans les logiciels de workflow intégrés aux CMS. Ce chapitre sur la GED nous a permis ainsi d’introduire les fonctionnalités concernant les processus d’édition des documents (workflows), le cycle de vie et l’archivage des documents et les droits d’accès aux documents. Elles sont indispensables aux systèmes de gestion de contenu. On a aussi pu constater l’utilisation obligatoire des méta données dans un système de GED. Une fonctionnalité, mise

13

en avant par la GED et souvent attendue, est le versioning. Les autres fonctionnalités sont plus spécifiques de la numérisation ou de la sécurité des données.

1.4. Gestion de site web Cette partie sur la gestion de site web va illustrer les fonctionnalités vues auparavant sous un autre angle pour finir en mettant l’accent sur les aspects de publications. Le « Web » est un réseau informatique très populaire et aujourd’hui le plus grand du monde. Il permet théoriquement à toute personne ou organisation désireuse de le faire, de mettre à disposition du plus grand nombre une ressource informatique et de les interconnecter. Le plus souvent, cette ressource est une page web de type html (Hyper Text Markup Language) visible à partir d’un navigateur Internet (browser). Avec ce qui a été dit précédemment, chacun s’aperçoit qu’énormément d’informations de tout type peuvent être mises à disposition du public et que la communication s’enrichit. Or certaines organisations ont un volume d’information très important à mettre à disposition de leurs différents publics avec une fréquence de mise à jour dans certains cas très forte, une contrainte souvent élevée de validité de l’information nécessitant un contrôle adapté et parfois une ergonomie, incluant le graphisme, sophistiquée. De même, ces organisations ont vu le nombre de leur site web atteindre des chiffres importants (plusieurs centaines dans les cas extrêmes), notamment pour les entreprises transnationales devant gérer des sites dans plusieurs langues différentes. Ces sites web ont vocation dans certains cas d’intranet, c’est à dire qu’ils ne s’adressent qu’à un public appartenant à l’organisation éditrice. L’organisation, pour faire face à ces trois contraintes (mises à jour fréquente, contrôle éditorial et haute qualité de la présentation), a nécessité la mise au point de systèmes de gestion de site web. Ces systèmes reposent sur le principe de la séparation du contenu et de la présentation (la mise en forme). A cette fin, le W3C (World Wide Web Consortium) a promu le langage XML5 (Extended Markup Language) qui impose la séparation du contenu et de la mise en forme. La mise à jour du contenu n’affecte pas la mise en forme et inversement le changement de charte graphique se fait indépendamment du contenu. Le responsable éditorial n’est plus dépendant des équipes informatiques (webmaster entre autres) et inversement le changement de graphisme n’affecte pas le contenu. Les acteurs de la gestion de site web sont donc d’un côté les responsables éditoriaux, au profil fonctionnel et de l’autre les graphistes qui créent et maintiennent le code informatique de mise en forme des « pages web ». Ce code appelé parfois code de transformation s’illustre avec le langage XSL (Extensible StyleSheet Language) qui comprend la sélection du contenu, les données de mise en forme, ajoute éventuellement de l’interactivité aux documents et fabrique le fichier nécessaire à la diffusion sur le terminal désiré. Les graphistes dans ce contexte doivent donc ajouter des compétences de développeur à leurs compétences initiales, à moins d’envisager une séparation des tâches. Ils interviennent plutôt à la création et lors de la maintenance évolutive du site web. Ce code informatique est un autre type de contenu, et qui comme tel, peut être géré comme un document (archivage, versioning, description) et éventuellement réutilisé. Concrètement, l’édition du contenu nécessite de structurer le document, de la même manière que les documents composites. C’est à dire, que le document est alors édité selon un modèle invariable défini préalablement lors du développement du site. Le modèle peut bien sûr évoluer mais nécessite un nouveau développement, ou bien encore un nouveau paramétrage de l’application de gestion de contenu. Sur la base de ce modèle, un formulaire, éventuellement interactif, permet de saisir un nouveau document ou bien de mettre à jour un document existant. Par exemple, l’article (de magazine) est un formulaire constitué des champs suivants : titre, sous-titre, introduction, chapeaux et paragraphes. Ensuite, la mise en forme est appliquée automatiquement lors de la publication en fin de processus d’édition lors de la validation. La mise en forme s’applique de manière particulière à chaque élément de l’article. Le titre est par exemple mis en majuscules et en gras, les chapeaux en italique et en couleur bleue… Ainsi tous les articles d’une même rubrique auront tous la même mise en forme et seront présentés de manière homogène conformément à la charte graphique élaborée par l’organisation. De plus, une page spécifique pourra permettre de dresser une liste de tous les articles

5 http://www.w3.org/XML/

14

reprenant uniquement les titres par exemple et l’introduction rapide. Si un article est supprimé ou modifié, la liste est mise à jour automatiquement. La séparation du contenu et de la présentation est d’autant plus importante qu’elle permet in fine la distribution et la mise à jour de l’information via de multiples canaux de diffusions de manière « immédiate ». La diffusion multi-canal est une fonctionnalité spécifique qui s’est développée avec les systèmes de gestion de site web. Ainsi un même contenu est distribué de manière dynamique sur plusieurs support de distribution ou terminaux : télévision interactive, PDA – Portable Digital Assistant, Terminal WAP, Minitel, Site web, CD-ROM. Le staging est une fonctionnalité souvent indispensable dès que le site web est mis à jour avec du contenu provenant d’une tierce partie (le catalogue d’un fournisseur sur un site de commerce électronique par exemple) et que l’on veut voir le rendu final tel que l’utilisateur final le verra. Si l’on sépare la mise en forme du contenu, on ne pourra effectivement voir le résultat final que lors de la distribution de l’information. Or la mise en forme bien évidemment joue sur le rendu. Le staging est donc utile lorsque l’on veut vérifier le contenu final avant la publication sur le site de « production ». Le staging rend les mêmes services qu’une plate-forme d’intégration dans des projets logiciels classiques. Certains voudraient voir les systèmes de gestion de site web régler la problématique des sites web multilingues où le contenu serait indépendant de la langue. C’est possible jusqu’à un certain point, notamment si dans les processus de mise à jour de la publication, la traduction automatique du contenu est incluse dans le flux de travail et que tout de suite après dans le processus intervient un validateur humain pour la traduction. On s’aperçoit dans ce cas que l’édition du contenu d’un site web fait appel à de multiples intervenants et que de ce point de vue, elle nécessite les mêmes outils que pour la GED : workflows, édition distribuée, gestion des droits. Une application de gestion de site web digne de ce nom doit pouvoir proposer cette dernière fonctionnalité aussi sur le site de publication finale en fonction des utilisateurs. De plus, on l’a vu précédemment, une page web (html) peut être assimilée à un document composite. A ce titre, la gestion de site web reprend de nombreuses fonctionnalités des systèmes de gestion électronique de documents. Mais dans la problématique de la gestion de site web la publication (la diffusion) prend une part plus importante que dans la gestion électronique de documents où classiquement la mise en forme et le contenu sont mêlés dans le document et où finalement on se contente de restituer le document initial sans traitement intermédiaire.

1.5. Portail informatif Le domaine du portail informatif regroupe les mêmes fonctionnalités que celui de la gestion de site web, mais il comprend quelques fonctionnalités importantes supplémentaires : la recherche et la récupération de documents, la personnalisation et la fédération (syndication) des contenus. Le portail, comme veut le signifier son nom, peut être vu comme une application de démarrage d’une session de travail sur Internet, un point central vers lequel l’utilisateur revient après avoir terminé une tâche. Avec l’évolution des architectures informatiques vers Internet, particulièrement avec les intranets professionnels, le portail tend à être l’application de démarrage d’une session sur un poste de travail informatique. A ce titre, quatre grandes finalités du portail déterminent quatre types de portail [18]. Le portail décisionnel regroupe les informations nécessaires à la prise de décision dans le cadre de son travail. Ces informations sont des indicateurs sur l’activité du métier et des centres d’intérêt de l’utilisateur. Le portail décisionnel est en lien avec les applications de data warehousing, data mining et des applications d’intelligence économique (BI- Business Intelligence). Le deuxième type de portail est le portail de publication ou institutionnel. Il est en lien direct avec les applications de gestion de contenu. Une autre partie du portail ouvre un accès aux applications professionnelles de l’organisation (administration, production) : c’est le portail opérationnel. Enfin, le dernier type de portail réunit les applications de groupware , appelées alternativement applications de travail collaboratif (courrier électronique, forum de discussion, conférence électronique). Finalement, un portail généraliste est un portail comprenant les quatre types de base du portail : le décisionnel, le collaboratif, l’opérationnel et la publication.

15

Les portails d’entreprises ont donc plusieurs vocations, plus ou moins affirmées dans la réalité. Ce sont des intranets et ils gèrent l’information interne à l’entreprise. Ils deviennent des extranets lorsqu’il s’agit d’intégrer des services et des informations à l’attention des fournisseurs et des clients de l’entreprise et un accès aux ressources internes de l’organisation pour un collaborateur à l’extérieur. Théoriquement, ils permettent à « l’entreprise étendue » de fonctionner : n’importe qui, n’importe quand, depuis n’importe où, n’importe comment doit pouvoir accéder aux ressources de l’entreprise en fonction de ses données d'utilisateur [19] [20]. Le portail est donc est un « lieu » de convergence où toutes les applications et toutes les informations sont accessibles. La fédération des contenus est la clé des portails. Un utilisateur doit pouvoir théoriquement accéder à l’information désirée que celle-ci se trouve dans une base de données, une base de courrier, une base de document (un système de gestion de fichier par exemple), un serveur web (interne ou externe). Le moteur de recherche est par conséquent une fonction centrale du portail. L’utilisateur doit théoriquement pouvoir formuler sa requête une seule fois et le moteur de recherche se charge de traduire cette requête, de la transmettre à toutes les sources de données connectées, de récupérer les réponses et de les agréger. Il s’agit d’une recherche dite fédérée. Le terme de « webcrawling » est parfois utilisé pour parler de l’interrogation de plusieurs sources de données sur le web. Un autre type de fédération est la syndication. Des documents publiés sur un autre site sont alors accessibles depuis le site portail qui les syndique. En général, ce sont les brèves d’une rubrique d’un site web qui sont ainsi publiées sur un autre site sous une rubrique similaire. La norme concernant ces aspects, outre l’utilisation des portlets dans les serveurs d’applications, semble être RSS - RDF Site Summary. Enfin, toutes les ressources informatiques étant théoriquement accessibles, celles ci ne le sont, et sont conséquemment révélées, que si les droits de l’utilisateur le lui permettent. C’est une première forme de personnalisation. Cependant, la personnalisation concerne d’autres aspects : adaptation du contenu et de la mise en forme à l’utilisateur, enregistrement des préférences de l’utilisateur sur la présentation et le classement logique des « applications », la gestion des abonnements aux diverses alertes proposées [21] [22]. Le portail est ainsi une application centrale qui prend en charge les fonctionnalités de fédération, la recherche puis la récupération et enfin la personnalisation des contenus.

1.6. Intégration au système d’information Aujourd’hui, les documents sont généralement gérés séparément des données qu’ils concernent. Dans le cycle d’une activité, diverses applications d’un système d’information sont utilisées. De la même manière, ce sont divers services d’une organisation qui sont mis en jeu. Or la « dématérialisation » des documents, c’est à dire, leur transfert sur des supports informatiques, offre la possibilité d’intégrer les applications et les documents. Un exemple est le dossier de sinistre d’une compagnie d’assurance. Il est constitué des données de l’application de gestion des sinistres. Mais il comprend aussi par exemple le rapport d’expert avec peut-être des photos à l’appui, un constat amiable rédigé sur un formulaire. Par ailleurs, le client de la compagnie d’assurance a passé un contrat avec celle-ci. Peut-être faudra-t-il le produire en cas de contentieux ? Des courriers ont été échangés à l’occasion du traitement de ce sinistre : peut-on récupérer la lettre d’explication accompagnant la déclaration du client, mais qui mentionne aussi sa demande d’information sur un autre produit d’assurance ? Le garage chargé de la réparation a envoyé une facture qui ne correspond pas du tout au devis : peut-on les comparer facilement ? Peut-on récupérer aisément toutes les pièces concernant le garage lors du renouvellement de son agrément par la compagnie d’assurance ? L’application de production de la société d’assurance fait ainsi appel à des données mais aussi à des documents qui leurs sont liés. Il est dans certains cas intéressant de pouvoir relier ces données et ces documents, mais aussi de relier les documents entre eux, c’est à dire les associer.

16

L’exemple le plus caractéristique de la réutilisation de composants documentaires dans un autre type de document est le catalogue de produits. Celui ci doit synthétiser l’information sur les produits afin de les présenter aux éventuels consommateurs. Une mise à jour du produit affecte donc le catalogue. Lorsque le catalogue est un catalogue en ligne, désormais indépendant des dates de parution, il doit répercuter les changements dans le même temps. Un autre exemple caractéristique est celui des projets informatiques où sont reliés des cahiers des charges, la conception, le code informatique et les tests, les contrats et les documents de réception. Le référentiel des organisations concernées doit permettre d’établir un lien entre ces documents. On rejoint là ce que l’on a pu aborder dans le chapitre 1.2. sur les documents composites. De manière générale, la chaîne de production (de la commande à la livraison et facturation en passant bien entendu par la production) génère un certain nombre de documents (bon de commande, contrat, cahier des charges, spécifications, livrables, facture, paiement). Idéalement, on doit pouvoir envisager une traçabilité permettant de lier l’ensemble des documents d’un même projet afin de faciliter l’analyse de l’activité de l’entreprise, de capitaliser l’information et d’améliorer sa reproductibilité. On aborde là des notions relatives à la gestion de la connaissance (knowledge management) [23]. De plus, les documents partagent dans certains cas des sous-éléments communs : plan, image, résultats... Il y a une cohérence entre ces documents. Le plus souvent, le document suivant dans un cycle d’activité (ou encore un processus d’affaire) reprend un résumé du document précédent, à savoir une méta donnée caractéristique de la gestion documentaire. Un dernier point sur l’intégration des documents au système d’information est leur exploitation à des fins d’analyse technique et / ou économique. Ce sont à ce niveau surtout les services d’études et de développement des organisations, parfois leur service marketing ou qualité, qui sont intéressés. Combien de photos accompagnent les rapports des experts d’assurance ? Quels sont donc les experts qui n’étayent pas leur rapport avec des preuves ? Les photos du précédent sinistre peuvent-elles être facilement reliées à celle d’une récidive ? Comment sont testées les intégrations de projet concernant les applications de commerce en ligne développées par l’entreprise ? Ne peut-on bâtir une méthodologie standard à partir des expériences passées ? Un commercial va rencontrer un nouveau client potentiel d’une entreprise du même secteur d’activité qu’une référence existante de l’entreprise : il faut qu’il récupère facilement les différents livrables existants pour pouvoir s’en inspirer, voir les présenter. Peut-il facilement créer un dossier de démonstration ? Combien d’articles a rédigé un auteur cette année ? En a-t-il rédigé plus que les années précédentes ? L’automatisation du traitement de l’ensemble des informations est toujours envisageable, mais à quel coût et avec quelle rentabilité, à partir de quel volume d’activité pour l’entreprise ? Ce sont là des questions dont les réponses nécessitent une étude approfondie mais nécessaire pour une organisation qui désire s’améliorer [24] [25]. Il s’agit donc de retenir les critères d’intégrations les plus pertinents, à savoir les liens à maintenir entre la production et les autres activités de l’entreprise (commercialisation, gestion, administration, qualité, études). Concernant l’intégration des documents entre eux, le modèle conceptuel de document, qui vise à structurer un type de document et que nous aborderons plus loin dans ce rapport, doit mettre en valeur quelles sont et comment sont partagées les parties entre les différents types de document. On aborde ici une vision novatrice qu’offre la gestion de contenu. Celle-ci a peu été mise en œuvre, et partiellement. Il faut donc envisager une mise en œuvre prudente de ces concepts. En effet, la gestion électronique de documents n’a que trente ans environ, la gestion de site web dix ans [26] [27]. XML, qui est un langage qui permet de bien formaliser la démarche de la gestion de contenu et qui, a travers les architectures informatiques ouvertes qu’il propose, est encore plus récent. Cependant, pour pouvoir être opérée, cette intégration nécessite la mise en œuvre préalable de l’intégralité des concepts de gestion de contenu : à savoir structuration des documents, séparation des données et de la présentation, utilisation des méta données. De même, elle nécessite la mise en œuvre d’un système de collecte et de publication adapté. C’est ce qui fait l’objet de la gestion de contenu en général.

1.7. Conclusion : système de collecte / système de gestion de contenu / système de publication

Cet aperçu de différentes applications de gestion de contenu met en avant la grande diversité des sources de contenu et des publications, tant dans leur format que dans leur nature.

17

Le contenu peut provenir de documents au format papier numérisés ou de télécopies. Il peut s’agir de fichiers informatiques spécifiques de l’application d’édition (typiquement des fichiers Microsoft Office). Il peut provenir aussi de formulaires du web ou de base de données aussi bien que de pages html. Aujourd’hui, il peut provenir d’un fichier XML. Enfin, le contenu peut être du son, des images ou une combinaison des deux, c’est à dire une vidéo ou mieux, un document multimédia. De l’autre côté, la publication peut être une impression, gravée sur un support numérique comme un CD-ROM, être un assemblage de documents, se faire sur un site web (et plus loin un site wap, une chaîne de télévision interactive), distribuée sous la forme d’un fichier pdf (Portable Document File). C’est le domaine particulier de l’éditique [28]. Traditionnellement, les données d’édition et de publication sont souvent mêlées. Il faut disposer du logiciel d’édition pour visualiser le document. Dans un système de gestion de contenu, elles sont séparées. Une publication n’est alors plus assimilée à un document. Elle devient seulement dépendante du terminal utilisé pour la visualiser. Toutefois, la publication garde une valeur car c’est elle qui contient le sens et exprime la finalité d’un document. On peut imaginer d’un côté des publications éphémères qui n’ont de sens que dans le contexte particulier où elles ont été générées et de l’autre côté des publications officielles qui doivent absolument pouvoir être reproduites. On met là en évidence une limite conceptuelle de la gestion de contenu : la frontière entre document et publication n’est pas formellement établie et laisse place à des interprétations, et donc, des implémentations divergentes. L’objectif d’un système de gestion de contenu est de fédérer ces sources et ces publications et plus loin, de fédérer ces systèmes de « collecte » de contenu et de publication. Ces sources, lorsqu’elles sont externes (celles d’un fournisseur par exemple, une facture typiquement), peuvent être intégrées automatiquement si un format d’échange a été mis au point. Ceci afin d’unifier l’accès aux informations et leur traitement, les valoriser et éviter les redondances et les incohérences. Un système de gestion de contenu doit permettre d’intégrer des données et des documents et les documents entre eux. La valorisation vient aussi de la possibilité de réutiliser les composants documentaires et de les distribuer sur des canaux multiples en maintenant une source pivot et unique. Le système de gestion de contenu (CMS – Content Management System), englobe donc les systèmes de collecte et de publication, mais est plus spécifiquement le référentiel central où idéalement est stocké l’ensemble du contenu dans un format unifié et où en tout cas l’unicité et la cohérence du contenu sont garanties, c’est à dire où sont stockées les méta données (information sur l’information). Le système de gestion de contenu contient donc les méta données mais aussi les fichiers de configuration des utilisateurs, de leurs droits et leurs éventuelles données de personnalisation, des modèles de documents, des processus d’édition (paramétrage des workflows) [29] [30]. Cette approche que nous avons retenue a été mise en avant et décrite par Bob Boïko, auteur de l’ouvrage « The content management bible6 ». Par ailleurs, nous avons été aussi influencés dans notre approche par Ann Rockley, auteur de « Managing Enterprise Content: A Unified Content Strategy»7. Tous deux participent aux travaux du laboratoire d’évaluation des systèmes de gestion de contenu de l’université de Washington (Washington Information School)8. L’architecture fonctionnelle de la première génération de CMS délègue le stockage des documents au système de collecte. Elle tient compte de l’adaptation à l’existant. La deuxième génération délègue véritablement le stockage des composants documentaires au CMS et doit être bâtie sur une architecture logicielle unique. Car dans la première génération, il faut concevoir des systèmes complexes et hétérogènes pour gérer autant de formats de stockage de données (systèmes de gestion de bases de données, bases de courriers électroniques, fichiers au format multiple (doc, pdf, ppt, xml, html, xls, txt pour les plus courant) sur des systèmes de gestion de fichiers éventuellement multiples, sites web, annuaires LDAP). L’adoption de la norme XML, avec l’utilisation de DTD (Document Type Definition) normalisée est un exemple de format d’échange unifié de documents dans les CMS de seconde génération. La mise en œuvre d’un CMS nécessite de profonds changements dans l’organisation de l’entreprise, tant au niveau des métiers (principalement pour le rédacteur qui ne s’occupe plus de la mise en forme

6 CONTENT MANAGEMENT BIBLE / de Boiko Bib / Broché / 15 décembre 2001 / ISBN: 0-7645-4862-X 7 "Managing Enterprise Content: A Unified Content Strategy" by Ann Rockley with Pamela Kostur and Steve Manning (ISBN 0735713065) - 14 octobre 2002. Voir aussi le site du groupe de Rockley : http://www.rockley.com 8 The Rockley Bulletin / Newsletter / January 2003 / [email protected]

18

du document) que de l’organisation générale. La collecte s’effectue certes toujours sur la base des domaines fonctionnels mais la publication se voit déléguée vers des équipes spécifiques pour chaque support [31]. De plus, un effort supplémentaire doit être fait pour décrire les documents (éditer les méta données) afin de les inclure de la manière adéquate dans le système de gestion de contenu et maximiser leur utilisation finale. En retour, les processus d’édition et de publication sont ainsi fiabilisés. La mise en œuvre d’un CMS doit donc se faire sur la base de buts explicites et hiérarchisés. Les sections suivantes présentent l’ensemble des concepts et des fonctionnalités nécessaires à la mise en œuvre d’un système de gestion de contenu. Une fois définis, le CMS doit pouvoir être paramétré en conséquence pour ensuite être utilisé. Les normes et langages présentés sont une illustration des modèles conceptuels. De même, des exemples concrets sont donnés en annexe.

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 docum ents 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.

19

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

20

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 / DMWare – 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

21

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

22

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.

2.2. Concept clé numéro 2 : gestion des références et identification des composants documentaires

2.2.1. Gestion des références (internes et externes ) De ce qui vient d’être dit précédemment à propos des modèles d’informations (composition des documents, réutilisation) découle la nécessité de pouvoir lier les composants entre eux. Un document est toujours un assemblage de composants sous la forme d’un maillage et que l’on peut représenter comme un arbre. Chaque composant est relié aux autres par un lien dans cet assemblage : c’est la référence qui joue le rôle de lien. Une référence peut être aussi un pointeur explicite contenu dans le contenu lui-même. Le lien hypertexte en est la meilleure illustration. La référence est interne quand il s’agit d’un lien d’un composant pointant vers un autre composant du même document. Elle est externe quand le document contient un lien qui pointe vers un composant d’un autre document. Lorsqu’un document est modifié, déplacé ou détruit, les liens qui pointent vers lui doivent être mis à jour en conséquence. S’agissant d’une modification générant une nouvelle version du document, les pointeurs doivent permettre de résoudre si le lien pointe vers la nouvelle version ou s’il pointe définitivement vers la version ancienne. L’alternative est d’affecter au composant documentaire et à sa version, un identifiant unique, invariable et persistant, indépendant de son emplacement. Les systèmes de gestion de contenu doivent donc proposer des mécanismes pour gérer ces références et leur maintenance. Le système le plus courant est bien d’affecter un identifiant unique à chaque document et ses fragments. La gestion des liens internes et externes, mais concernant seulement des documents gérés par la même application de gestion de contenu, est possible. Cependant, lorsqu’il s’agit de lien vers des documents gérés dans des systèmes externes (typiquement des documents disponibles sur Internet mais édités par d’autres organisations), la persistance n’est plus garantie. Le W3C (World Wide Web Consortium) et l’IETF (Internet Engineering Task Force) propose une solution à cette problématique avec la spécification des URI [34] [35] (Uniform Resource Identifier) et des espaces de noms (name spaces) dans la gestion des documents XML. De même, les propositions de normes XLink, XPath et XQuery du W3C donnent une idée de la manière dont les documents peuvent être pointés, atteints, trouvés et recomposés grâce à la structuration des documents et l’URI.

23

2.2.2. Uniform Resource Indicator (URI) Un URI est en fait l’ensemble générique de tous les noms ou adresses que sont de courtes chaînes de caractères qui font référence à des ressources. Le concept d’URI englobe celui d’URN (Uniform Resource Name) et d’URL (Uniform Resource Locator). Laconiquement, une URL est un terme informel associé aux URI populaires tels que « ftp, http, mailto,… » [36]. En fait, une URL est une forme d’URI qui exprime une adresse, qui, à travers un algorithme associé à un protocole de réseau informatique, permet d’accéder à une ressource. Les URI qui font référence à des objets accessibles avec des protocoles réseau existants sont connus comme des URL [37]. L’URL ne permet pas de garantir l’accès à la ressource si celle ci a été déplacée, renommée, voire modifiée et a fortiori détruite. Un URN est un URI qui dispose d’un engagement institutionnel pour garantir sa persistance et sa validité. En d’autres termes, la ressource est enregistrée auprès d’une institution publique ou para-publique. Le numéro ISBN d’un livre en est une illustration. Une autre initiative permet de rendre une ressource persistante et valide à partir d’une URL : il s’agit de PURL (« Persistent Uniform Resource Locator ») [38]. Ce système associe à l’enregistrement d’une URL, une URL persistante : c’est à celle ci qu’un lien fait référence indépendamment de l’emplacement de la ressource sur Internet. Cette dernière peut donc être déplacée. C’est une sorte de système de résolution d’adresse ou encore un système d’annuaire des documents. La syntaxe d’une URI est constituée en premier lieu par un domaine nominal (« naming scheme ») puis par une chaîne de caractères représentant l’adresse de la ressource. A l’intérieur de l’URI d’un objet, le premier élément est donc le nom du schéma, séparé du reste de l’objet par le caractère « : ». Le reste de l’URI suit les « deux points » dans un format dépendant du schéma. Le chemin (adresse) est interprété en fonction du protocole d’accès du réseau utilisé. Cependant, s’il contient des « / » (« slash »), cela implique une structure hiérarchique. Un URN est un schéma, ou encore un système de nommage qui permet d’identifier des ressources de manière persistante et indépendante de l’emplacement. Il permet aussi, une fois la ressource identifiée, d’y accéder si le système informatique le permet. Ce qu’il faut retenir de ces deux derniers chapitres est que toutes les références des documents doivent être uniques et invariables ; la charge revient au système de gestion de contenu de maintenir les liens en cas de modification et de déplacement des ressources. Dans des systèmes coopératifs plus ouverts et mettant en jeu plusieurs organisations (plusieurs CMS), un système commun d’annuaires de documents doit être mis en œuvre ou bien des règles de dénomination doivent être respectées par les opérateurs, éventuellement contrôlées par les systèmes de gestion de contenu en relation avec une institution qui en garantit la persistance et l’unicité en proposant un système d’enregistrement de la référence des documents. Les URI sont parties intégrante de la recommandation RDF (Resource Description Framework) du W3C, qui propose un cadre pour représenter les méta données, objet de la section suivante.

2.3. Concept clé numéro 3 : les méta données Les méta données sont des données sur les données. A partir de cette définition, on peut imaginer tout type et toute nature de données pour mieux comprendre et utiliser les données, que cela soit pour un opérateur humain ou une machine. Les méta données sont généralement d’abord utilisées pour décrire une ressource, documentaire ou non. Elles sont utilisées aussi par les applications qui utilisent ces ressources en tant que propriétés. Un des exemples importants qui concerne les systèmes de gestion de contenu sont les méta données d’application relatives à la gestion documentaires. Ce chapitre aborde aussi un autre exemple de méta données d’application pour la personnalisation du contenu et de la publication en fonction de l’utilisateur. Enfin, nous verrons un exemple de tentative d’harmonisation des méta données avec une proposition du groupe de Dublin Core qui récapitule les méta données présentées dans cette section. En fait, les méta données de Dublin Core ont largement influencé notre approche concernant les méta données. En effet, les travaux de ce groupe, réunissant à la fois des experts du monde la bibliothèque

24

et des données (de l’Informatique), ont permis d’élaborer une synthèse des méta données les plus courantes et nécessaires à la gestion de contenu. Comme pour toutes données, il n’y a pas de format de méta données particulier. Elles peuvent être modélisées de différentes manières. De même, elles peuvent être organisées logiquement selon la convenance des systèmes. Nous aborderons toutefois un modèle et une syntaxe de représentation des méta données avec Resource Description Framework (RDF) qui peut permettre une exploitation importante des méta données grâce à leur extensibilité, l’intégration des schémas de méta données et l’échange de méta données.

2.3.1. Méta données : définition et utilisation Les méta données, information sur l’information, peuvent être regroupées dans deux ensembles principaux : les données descriptives, les données d’application. Dans les méta données d’application, deux sous-ensembles nous intéressent plus particulièrement du point de vue des systèmes de gestion de contenu : les données de gestion documentaires et les données de personnalisation. Ce sont ces différents groupes de méta données que nous allons aborder dans cette section.

2.3.1.1. Données descriptives

Les données descriptives classiques sont le titre, l’auteur et le sujet. Tout le monde est familier, d’une manière ou d’une autre, de ces méta données. Cependant d’autres méta données descriptives peuvent être ajoutées. Il s’agit par exemple d’une description du composant, de la table des matières, d’un résumé, d’une ou plusieurs sources, du type du composant, de la couverture spatiale et temporelle, de la langue et de la date. Approfondissons les notions relatives aux méta données descriptives. Si aucun commentaire n’est fait dans ce chapitre à propos d’une méta donnée, le lecteur pourra en trouver un dans le tableau 5 : « méta données de l’initiative de Dublin Core p 109 ». Par ailleurs, ce tableau développe aussi des informations sur les standards qui peuvent être associés à ces méta données. 1. Voyons tout d’abord l’auteur d’un composant documentaire. Si cette appellation convient bien pour des documents écrits classiques, elle convient moins bien à certains contenus : par exemple une œuvre musicale ou un film. On pourra donc lui préférer la dénomination de « créateur ». On rajoute à cette méta donnée celles concernant l’éditeur (dans ce contexte, l’organisme qui publie et diffuse) et le(s) contributeur(s). 2. Le contenu du sujet demande à être précisé. Car il recoupe une des informations les plus importantes que représentent les méta données : la classification. Là encore, le terme de classification demande à être développé. Certains lui préfèrent le terme de taxonomie. D’autres encore utilisent le terme de catégorisation et par-là, le sujet peut représenter une catégorie. Le sujet peut donc représenter un domaine défini dans une classification de domaines. Le sujet peut être aussi illustré par l’utilisation de mots clés. Là encore, la liste des mots clés doit être choisie minutieusement dans le sens où ce paramètre des méta données (e.g. le sujet) va servir pour rechercher logiquement et récupérer le composant documentaire concerné. Le mot clé doit donc préférablement appartenir à une liste prédéfinie. De même, le choix des mots clés doit être contrôlé à l’aide d’un dictionnaire. Il doit se faire à partir d’un vocabulaire contrôlé ou bien encore un thésaurus. Une des illustrations les plus simples de ce besoin de vocabulaire contrôlé dans le contenu des méta données est le nom d’une ressource. Certains utiliseront un acronyme quand d’autres écriront le nom complet d’une organisation ou encore certains parleront d’une personne en ne citant que son nom alors que d’autres rechercheront des informations sur la même personne en donnant le nom mais aussi le prénom, empêchant de retrouver le document écrit pour informer sur cette personne. 3. La notion de table des matières ne soulève pas trop d’ambiguïté. Cependant, si elle est utile pour décrire des documents volumineux comme les documents de type rapport ou livre, elle ne l’est pas

25

pour les composants du type des nouvelles (news) sur un site web informatif qui sont des documents courts. Les méta données ne s’appliquent donc pas uniformément à tous les types de documents. Certaines comme le titre s’appliquent à tous, d’autres comme nous l’avons vu sont spécifiques à certains documents. 4. Cela introduit la notion de type dans les méta données. Il ne s’agit pas, d’après le groupe du Dublin Core, de reprendre l’information sur le document qui est donné dans la référence à la DTD (Document Type Définition) dans les documents XML mais d’un type beaucoup plus général (voir type dans le tableau 5). Cependant, une autre « architecture » de CMS n’utilisant pas XML pourrait là nécessiter d’avoir une référence au modèle (e.g. template) auquel obéit le document. Par ailleurs, il est possible de suivre la notation de Dublin Core pour les méta données tout en les enrichissant notamment en utilisant l’héritage12. RDF par exemple permet de sous-classer des propriétés ou encore des types de ressources qui sont définies dans le modèle comme des classes12. 5. La couverture peut être spatiale et / ou temporelle. C’est à dire que la portée de l’œuvre concerne une époque (pour la couverture temporelle) et / ou une zone géographique. Il peut paraître évident de chercher un texte qui s’applique à un pays. Cependant si la base de documents contient un texte sur le même sujet mais qui est différent en fonction du pays auquel il se rapporte, il vaut mieux disposer de cette méta donnée. Là aussi, l’utilisation de vocabulaire contrôlé est indispensable. Ainsi, le groupe de Dublin qui s’intéresse aux méta données n’a pas son siège en Irlande mais dans l’Etat de l’Ohio aux Etats-Unis (d’Amérique…) où se trouve aussi le siège de l’OCLC13. 6. La date enfin est une donnée conventionnelle. Sa définition est la suivante : « une date associée avec un événement dans le cycle de vie de la ressource. Typiquement, une date sera associée à la création ou à la publication d'une ressource » (voir tableau 5). Toutefois, de multiples dates sont associées au méta données. Nous les étudierons dans le chapitre intitulé « Cycle de vie du document (dates, statuts et versions) » page 28. Ces données descriptives sont donc des données qui permettent de présenter et sélectionner une ressource sans y accéder dans un premier temps. Elles sont notamment reprises dans des catalogues décrivant des composants documentaires ou encore comme éléments d’une liste des résultats à une requête sur un « moteur de recherche ». Les méta données, pour être efficaces, doivent être normalisées ainsi que leurs contenus. De même, elles doivent être extensibles pour répondre aux besoins spécifiques associés à chaque type de document en fonction des utilisateurs. Ces informations s’adressent principalement à des opérateurs humains, contrairement aux données d’applications qui s’adressent principalement aux programmes informatiques et que nous allons maintenant aborder.

2.3.1.2. Données d’application

Les méta données utiles aux applications peuvent être multiples et dépendent de la nature et du domaine de l’application. Les données d’applications sont souvent appelées et assimilées à des propriétés. Certains parlent même d’attributs de fichier. Aussi, il vaut mieux introduire ce genre de méta données par un exemple. Une application informatique qui permet de visualiser et d’éditer des images a besoin d’information sur le fichier et l’image. Le format du fichier est une information générale nécessaire à un système informatique pour déterminer quelle peut être l’application à associer à la lecture ou à l’édition du fichier. D’ailleurs, face à l’importance de cette information, même le groupe de Dublin Core propose une méta donnée. Il s’agit de la données intitulée « format » (voir tableau 5 page 109). La taille du fichier peut être une information générale utile. Un fichier GIF (Graphic Interchange Format), un des formats d’image les mieux supportés, a les propriétés de base suivantes : largeur (en pixel), hauteur (pixel), nombre de bit (valeur exemple : ‘6’), représentation (valeur exemple : ‘Palette’) et enfin compression (valeur exemple : ‘Lempel-Ziv’) qui donne l’algorithme de compression utilisé pour compresser la taille du fichier. Un fichier JPEG (Joint Photographic Experts Group) lui propose les méta données d’application suivantes : largeur, hauteur,

12 Concept associé à la programmation orientée objet. 13 OCLC : Online Computer Library Center.

26

résolution verticale, résolution horizontale (en pixels par pouce), nombre de bits (valeur exemple : ‘24’), représentation des couleurs (valeur exemple : ‘Couleurs vraies RVB’), compression (valeur exemple : ‘non compressé’). Des attributs sont donc communs, d’autres spécifiques au type de fichier et aux applications capables de les traiter. Ces informations sont indispensables aux applications afin de permettre un certain nombre d’automatisations. Dans le cas des images, on peut les afficher directement sur un écran à la taille voulue (dont la taille et la résolution sont définies) sans à avoir à « scruter » le fichier afin de calculer ses propriétés. Les méta données d’applications sont donc des données qui décrivent une ressource et qui sont couramment utilisées pour automatiser leur traitement. Lors de l’édition de ressources informatiques ou numériques, un grand nombre de paramètres est utilisé par les applications d’édition et le système. Par exemple, les polices de caractère d’un texte peuvent être reprises dans les méta données. Si cette donnée d’application est nécessaire pour une intégration d’applications par exemple, l’application d’édition peut enregistrer automatiquement ces données en tant que méta données. En fait, il s’agit d’une définition, les méta données d’applications peuvent et doivent être renseignées automatiquement. C’est un fait important sur lequel nous reviendrons dans le chapitre 3.1.2 intitulé « Edition des méta données » et qui s’étend à toutes les méta données, particulièrement les données de gestion documentaire que nous allons maintenant aborder ci-dessous.

2.3.1.3. Données de gestion documentaire

Les méta données de gestion documentaire sont d’un genre particulier car ce sont des données d’applications de manière générale mais qui sont relatives à la gestion de contenu et donc aux CMS en particulier. Ces méta données assurent la traçabilité entre les composants d’un système. Ces données sont les sous propriétés des éléments des méta données de Dublin Core « relations » et « date ». Gestion des références explicites Nous avons déjà abordé ce sujet dans le chapitre 2.2.1. Nous avons vu notamment que les références peuvent être explicites et mentionnées dans le contenu d’un composant ou implicites dans le cas des liens de composition que nous abordons ci-dessous. Ces liens explicites sont par exemples des liens hypertextes ou encore des renvois à d’autres éléments d’un document. Mais les liens peuvent être encore les références reprises dans la section concernant la bibliographie d’une œuvre. Ces références sont parfois des sources du document contenant ces références. De même, dans certains documents de travail, ces méta données sont reprise dans des préambules. Par exemple, classiquement, le document des spécifications fonctionnelles d’un programme informatique fait références aux documents préalables que sont les cahiers des charges et l’offre de marché si elle existe. Et il peut en être ainsi de suite sur toute la chaîne des documents accompagnant le cycle d’une activité. Il faut donc noter ici que des méta données peuvent en fait être les données mêmes de composants documentaires spécifiques comme ceux que nous venons de mentionner dans le paragraphe précédent. Pour rester en phase avec XML, on peut citer ici la norme Xlink14 qui peut être utilisée pour mettre en œuvre la gestion des liens explicites. La mise en œuvre de Xlink permet en particulier une navigation intéressante dans les informations d’un système pour ceux qui sont en phase d’apprentissage et/ou de réflexion. Les termes ou les éléments correspondants définis par l’agence DCMI sont les suivants : Source, hasVersion, isVersionOf, Replaces, isReplacedBy, hasFormat, isFormatOf, references, isReferencedBy et conformsTo (voir tableau 5 page 109). Rappelons ici que s’il s’agit de ressources

14 XML Linking Language (XLink) Version 1.0 : W3C Recommendation 27 June 2001. http://www.w3.org/TR/xlink/

27

externes au CMS, l’utilisation d’un URI (voir chapitre 2.2.2) sera judicieuse. On peut noter aussi que les propriétés possèdent chacune le cas échéant leur propriété inverse s’appliquant au document lié. Relations implicites (liens de composition) Restent donc les termes de l’élément « relation » suivants : hasPart, isPartOf, requires, isRequiredBy. Ils décrivent donc les liens de composition dans les documents composites (cf. section 1.2 « Edition de document composite »). La première relation (i.e. hasPart/isPartOf) est définie ainsi : « la ressource décrite inclut la ressource référencée soit physiquement, soit logiquement ». Cette notion est fondamentale pour la gestion des composants. Si le composant n’est inclus que dans un seul document, il n’y pas de problème particulier lors d’un changement s’appliquant au document. Par contre, s’il est partagé, il faut à tout prix gérer les conflits éventuels relevant du partage. L’exemple typique est le logo d’une organisation qui est repris dans de multiples documents : lorsqu’un document est détruit, il s’agit de ne pas détruire le fichier image correspondant et qui continue d’avoir une « vie » dans les documents toujours valides. Inversement, lorsque le logo est changé, ce changement ne doit être répercuté que dans les documents faisant référence à la version la plus récente. Ainsi la gestion des composants documentaires ne peut se faire que si la relation « hasPart » est soigneusement renseignée. La définition de la relation requires/isRequiredBY est la suivante : « la ressource décrite requiert la ressource référencée pour fonctionner, être utilisée ou pour sa cohérence de contenu ». Il y a ici une référence au logiciel éventuel nécessaire pour exploiter le composant mais surtout et c’est ce qui nous intéresse ici, les composants sont liés de telle sorte que l’un ne peut se comprendre sans l’accès éventuel à l’autre ou aux autres composants « requis ». On peut illustrer cela par un composant faisant partie d’une œuvre (un rapport par exemple), qui traite d’un sujet particulier, mais qui ne saura être compris dans son intégralité sans une référence au document dont il fait partie et notamment l’introduction. Ainsi extrait de son contexte, le composant qui requiert un autre composant n’est pas forcément cohérent. Ce lien est aussi important pour le CMS afin de maintenir un statut « valide » à un composant qui serait réutilisé par un autre valide et dont le contexte « requis » pour sa compréhension serait invalidé et archivé ou détruit. Ces données de gestion documentaires ne sont utiles que dans le cas de partage de composant. Autrement, ils imposent une lourdeur et une rigidité au système de gestion de contenu qui n’est pas souhaitable. Xlink14 peut être utilisé dans ce cas là car ils sont alors explicites. Avec XML et les DTD (ou les schémas XML), le lien de composition est défini dans la structure du modèle. Quand un document référençant le modèle est édité, des liens de compositions implicites sont établis. Ce sont ces liens qui sont l’objet de la norme Xpath15 et qui permettent de parcourir et d’établir des références entre des éléments d’un même document. De même, ces références internes aux composants d’un document permettent d’effectuer des requêtes sur des portions de documents et sont utilisées par le langage de requête XML (XQuery16 parfois nommé XQL16). Il s’agit là juste de mentions qui sont toutefois intéressantes dans le sens où par la suite XQuery peut être utilisé par exemple comme technologie sous-jacente des moteurs de recherche (cf. 3.3.4. « Recherche et récupération de document ») et qu’il permet la recherche fédérée sur différents types de stockage de données (fichiers plats XML et bases de données). De même, Xlink peut être utilisé pour la navigation (cf. 3.3.5 « Navigation »). Enfin XSLT17 utilise aussi la norme Xpath pour sélectionner des composants documentaires (éléments XML) pour effectuer des transformations sur la structure d’un document afin de créer un nouveau document, notamment une publication. XSLT est dérivé du langage XSL (Extensible Stylesheet Language) qui, lui, permet d’associer une mise en forme aux éléments d’un document XML publié en tant que page web sur un navigateur (terminal du Web). Tous ces éléments sont abordés dans les chapitres de la section 3.3 « Système de publication ». Ces normes et ces langages illustrent l’importance des applications qui découlent de l’utilisation des méta données, mais aussi des concepts de structuration de document et de séparation des données

15 XML Path Language (XPath) Version 1.0 : W3C Recommendation 16 November 1999. http://www.w3.org/TR/xpath 16 XQuery 1.0: An XML Query Language : W3C Working Draft 22 August 2003. http://www.w3.org/TR/xquery/ 17 XSL Transformations (XSLT) Version 1.0 : W3C Recommendation 16 November 1999.

28

du contenu. Il existe bien sûr des alternatives à ces langages, mais rappelons le ici, XML permet d’avoir une vision complète de l’architecture nécessaire à la gestion de contenu. L’analyse des liens de composition montre aussi qu’un composant documentaire n’a de raison d’être que par rapport à sa publication. Cependant, la gestion de contenu que nous envisageons dans ce rapport (intégrant la réutilisation, la publication sur de multiples supports, la personnalisation), révèle une nouvelle forme de considération du composant documentaire qui commence à prendre une « vie » qui lui est propre (voir 3.3.2 « Publication versus document »). D’où toute l’importance des méta données abordées dans cette section sur les données de gestion documentaire, qui, rappelons le, permettent d’assurer la traçabilité des informations. Cycle de vie du document (dates, statuts et versio ns) Nous avons vu (cf. section 1.3 « Gestion documentaire (référentiel d’entreprise) ») le caractère parfois officiel des documents. Il y a été aussi évoqué l’état d’un document dans une chaîne d’édition et de validation de document. Ainsi un document, de sa création (naissance) à sa destruction (mort) obéit à un cycle de vie. Ce cycle est marqué par des étapes auxquelles est associé un statut pour le document. Ces étapes sont les suivantes : création, soumission (pour approbation), validation (approbation), publication, archivage et destruction. Le cycle peut être rejoué partiellement en cas de modification générant une nouvelle version du document. Ce cycle peut être affiné pour des processus d’édition plus complexes. Avant d’être approuvé, un document aura souvent le statut de brouillon (« draft » en anglais). Les termes des dates associées aux méta données du DCMI sont les suivants : Created, Modified, DateSubmitted, DateAccepted, DateCopyrighted, Issued, Available, Valid (voir tableau 5 page 109). La dernière méta donnée (« valid ») est importante puisqu’elle permet de savoir si la version du document accédée est toujours valable et si les informations qu’on y trouve s’appliquent toujours. Elle est impérative pour des documents présentant des textes réglementaires. Si une nouvelle version d’un document est approuvée et publiée, alors la version précédente voit sa validité terminée à moins qu’il ne faille continuer à soutenir les versions précédentes. La gestion des versions est utile dans ce dernier cas. Par exemple, pour les logiciels, certains utilisateurs continuent d’utiliser des versions anciennes d’un programme. Il faut donc pouvoir continuer à accéder à la ressource et à la documentation associée malgré l’existence de versions ultérieures. Ces données d’application de gestion de contenu sont tout aussi indispensables que celles présentées précédemment notamment pour pouvoir automatiser certains processus comme l’archivage et la destruction. En effet, sur la base de règles associées à certains types de documents, les CMS vont pouvoir, par exemple, retirer de la publication certains éléments de site web, transférer de fichiers de disques magnétiques vers des disques optiques afin de libérer le système d’exploitation primaire pour de nouvelles ressources.

2.3.1.4. Données de personnalisation

D’autres méta données d’un genre particulier utiles pour les applications de personnalisation de la publication sont les données de personnalisation. A ce titre, ce sont encore des méta données d’application. Le DCMI propose là encore des méta données. Mais ce ne sont que des termes concernant la notion de public d’un document. Ce sont les termes suivants : audience, mediator, educationLevel. Si ces méta données sont renseignées, le système de publication pourra distribuer ou non, en fonction des données de l’utilisateur, la ressource documentaire. Mais il faut que le système permette aussi d’identifier l’utilisateur et que ces données le concernant soient renseignées. Ceci en utilisant des valeurs pour ces propriétés aussi normalisées que possible. DCMI ne propose pas de classification

29

normative pour ces sujets. Elles sont donc spécifiques pour le moment aux applications qui les utilisent. Par contre, un élément normalisé pour gérer les droits d’accès est l’élément « Rights ». On peut y inclure les données ACL (Access Control List). Mais on peut y trouver aussi les éléments de droits d’auteur (copy rights) le cas échéant. Les fichiers ACL spécifient quel utilisateur ou quel groupe d’utilisateur a accès à la ressource et ce qu’il peut faire avec (lecture, écriture, exécution, destruction). Le droit sur et au sujet d’une ressource est très important puisque l’on a vu que pour toute donnée numérisée, la notion de prêt n’a plus cours (cf. 1.1 « Gestion des bibliothèques physiques »). On parle ici de personnalisation du contenu et non pas de la mise en forme. Tous ces aspects seront abordés dans le chapitre 3.3.3 "Personnalisation ». Ainsi les données de personnalisation autorisent la révélation et la distribution d’une ressource en fonction de l’utilisateur. Les données retenues par le DCMI montrent que c’est le domaine de la formation et de l’éducation qui est principalement intéressé. Le champ des méta données a donc été présenté dans son ensemble. Nous allons donc pouvoir voir une initiative, celle du groupe de Dublin Core, qui les intègrent dans un ensemble à vocation normative.

2.3.2. Dublin Core Metadata Initiative (DCMI) Lors d’une conférence tenue à Dublin, Ohio, à l’OCLC (Online Cataloging Library Center) un groupe de travail a commencé à se pencher sur la problématique des méta données. Un groupe de méta données ressenties comme communes à la majeure partie des types de documents y a été élaboré. C’est d’ailleurs pour cela que je les ai présentés au cours de cette section 2.3 traitant des méta données. C’est l’ensemble des éléments de Dublin Core (Dublin Core Element Set –DCES) qui est aujourd’hui l’objet d’une tentative de normalisation18 à l’ISO (International Standard Organisation). Cependant, le DCMI va plus loin en définissant une liste de termes qui peuvent être des méta données. Cette liste des termes (qualificatif, soit « qualifier » en anglais) est accessible pour la dernière version à l’adresse URL http://purl.org/dc/terms/ au format RDF / XML. De plus, il définit aussi des listes de valeurs standard pouvant être utilisées pour renseigner ces méta données (« encoding schemes »). Le tableau en annexe 3 fait la synthèse des éléments, des termes et des domaines de valeurs normalisés préconisées pour ces méta données. Il est basé sur la version 1.1. du DCES du 24/03/2003 [39] [40]. Ce tableau reprend les méta données qui ont déjà été largement abordées dans les sections précédentes.

2.3.3. Resource Description Framework (RDF) Nous allons décrire dans cette section le modèle et la syntaxe de RDF, ainsi que le schéma de RDF, RDFS, qui définissent RDF. L’objectif de cette description est de permettre l’utilisation de RDF et RDFS au lecteur afin d’exprimer un modèle de méta données propre à son organisation tout en bénéficiant des propriétés générales de RDF. Ces propriétés générales sont abordées en introduction.

2.3.3.1. Introduction

RDF19 est un modèle, associé à une syntaxe, dont le but est de permettre à une communauté d’utilisateurs de partager les mêmes méta données pour des ressources partagées. Il a été conçu

18 Information and documentation — The Dublin Core metadata element set. (ISO TC 46/SC 4). ISO 15836:2003(E). Draft International Standard. The Dublin Core Metadata Initiative (DCMI) is the maintenance agency. http://dublincore.org/

30

initialement par le W3C pour permettre de structurer l’information accessible sur le web et de l’indexer efficacement. RDF n’est pas particulièrement conçu pour permettre de stocker les méta données de documents mais plutôt pour permettre leur échange et leur traitement par des opérateurs humains ou artificiels. Un des gros avantages de RDF est son extensibilité, à travers l’utilisation des schémas20 RDF qui peuvent s’intégrer et ne s’excluent pas mutuellement grâce à l’utilisation du concept d’espace de nom (« namespace ») [41]. RDF est par ailleurs un des modèles de base et de syntaxe sur laquelle le web sémantique se construit avec l’ajout de couches (« layers ») au-dessus de RDF comme OIL (Ontology Inference Layer) et DAML (DARPA21 Agent Markup Language). OIL est utilisé pour définir des ontologies22 et DAML ajoute un petit nombre de caractéristiques au schéma RDF afin de rendre plus facile la définition de nouveaux langages permettant la communication entre agents intelligents (cf. Intelligence Artificielle) [42]. Les méta données du DCMI sont exprimées de manière normative avec la syntaxe RDF23. Lorsque les méta données d’un document sont exprimées en RDF en concordance avec le DCMI, elles font référence à l’espace de nom (domaine nominal ou « namespace » en anglais) des schémas RDF des méta données de Dublin Core. Conjointement avec RDF, l’initiative de Dublin Core vise à résoudre les problèmes d’ambiguïté sur la dénomination des ressources, et parmi elle surtout celles des propriétés24. Toutes les personnes désirant coopérer en échangeant de l’information ont là les moyens de le faire efficacement en résolvant les problèmes classiques auxquels ils peuvent être confrontés. Enfin, les méta données en RDF peuvent être localisées en différents endroits. Tout d’abord, les méta données peuvent être imbriquées à l’intérieur d’un document lui-même (bloc de commentaire d’un fichier informatique ou à l’intérieur d’une balise <meta> de l’entête d’un fichier html) ou peuvent se situer sur une ressource externe (un autre document ou encore une base de donnée). Elles peuvent être distribuées (exemple de RSS – RDF Site Summary) ou centralisées dans un référentiel (exemple d’un répertoire UDDI – Universal Description, Discovery and Integration) [42]. RDF ne présuppose rien par rapport l’architecture des méta données et laisse une entière liberté par rapport à cela.

2.3.3.2. Modèle et syntaxe RDF

Eléments de base La construction de base en RDF est le triplet {propriété, ressource, valeur}. Le langage de balise XML est utilisé pour le spécifier. On parle ainsi parfois de RDF / XML car d’autres formalismes peuvent être finalement retenus. Nous ne nous étendrons pas sur les deux syntaxes possibles de RDF : la syntaxe sérielle et la syntaxe abrégée ou encore simplifiée. De même, les propriétés peuvent être des éléments XML ou bien des attributs XML. Les exemples retiendront l’une ou l’autre forme sans autre distinction que celle imposée par XML, à savoir qu’un attribut ne peut contenir d’éléments fils et est forcément un élément terminal s’il est transposé en élément. Tout ce qui est exprimé avec RDF est appelé une ressource . La ressource est toute entité d’information pouvant être référencée en un bloc, par un nom symbolique (littéral) ou un identificateur. L’identificateur est obligatoirement un URI (voir chapitre 2.2.2 « Uniform Resource Indicator (URI) »).

19 Resource Description Framework (RDF) Model and Syntax Specification. W3C Recommendation 22 February 1999. Newest Version: http://www.w3.org/TR/REC-rdf-syntax 20 RDF Vocabulary Description Language 1.0: RDF Schema. W3C Working Draft 05 September 2003. Latest Version: http://www.w3.org/TR/rdf-schema/ 21 DARPA : Defence Advanced Research Projects Agency - US Department of Defence. 22 Une ontologie établit une terminologie commune, plus un consensus sur son interprétation entre des membres d’une communauté de communication. Ces membres peuvent être humains ou des agents artificiels. Les ontologies représentent un champ de recherche bien établi en philosophie et intelligence artificielle… 23 DCMI term declarations represented in RDF schema language : http://dublincore.org/schemas/rdfs/ 24 Synonyme dans notre contexte de méta données , avec le mot attribut . Cette note est un exemple d’ambiguïté possible de synonymie, une autre ambiguïté courante étant l’homonymie.

31

Une propriété est un aspect spécifique, une caractéristique, un attribut ou une relation utilisé pour décrire une ressource. Chaque propriété a une signification spécifique, des valeurs autorisées, des types de ressources qu’elle peut décrire et des relations avec d’autres propriétés. Une ressource spécifique associée à une propriété et sa valeur correspondante est une expression ou déclaration (« statement ») RDF. Ces trois parties (ressource, propriété, valeur) sont appelées respectivement sujet, prédicat et objet. L’objet d’une déclaration (i.e. la valeur de la propriété associée à une ressource) peu être une autre déclaration RDF (réification) ou un littéral, c’est à dire ou une ressource (spécifiée par un URI), ou une chaîne de caractères simple (ou encore un autre type de donnée primaire défini par XML). En langage RDF, un littéral (« literal ») peut avoir un contenu XML bien formé mais qui n’est plus pris en compte par un processeur (ou encore un analyseur syntaxique) RDF. Illustrons cela tout de suite avec un exemple utilisant les méta données du DCMI [43]. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-synta x-ns#" xmlns:dc="http://purl.org/metadata/dublin_core#"> <rdf:Description about="http://www.dlib.org" dc:Title="D-Lib Program - Research in Digital L ibraries" dc:Description="The D-Lib program supports the community of people with research interests in digital libraries a nd electronic publishing." dc:Publisher="Corporation For National Research Initiatives" dc:Date="1995-01-07"/> </rdf:RDF> Quelques commentaires s’imposent. L’élément racine rdf:RDF permet à un processeur RDF de repérer le début d’un bloc de déclaration RDF. L’utilisation des domaines nominaux (déclarations « xmlns ») permet d’utiliser deux schémas RDF différents. Concrètement un seul est utilisé ici : celui du Dublin Core, l’autre déclaration de schéma, celui de RDF, étant obligatoire pour toute utilisation de RDF. La notion de domaine nominal est une notion fondamentale puisque c’est grâce à lui que l’on peut étendre les schémas de méta données sans avoir à en recréer un nouveau, reprenant l’ancien. De plus, la déclaration des domaines nominaux permet ensuite d’utiliser le préfixe abrégé de substitution pour référencer les propriétés décrites (c’est à dire par exemple dc:publisher au lieu de http://purl.org/metadata/dublin_core#publisher, la première forme dc:publisher étant bien plus lisible). Maintenant, considérons la déclaration <rdf:Description about="http://www.dlib.org"> . Il s’agit de la déclaration type en RDF des propriétés (c’est à dire des méta données) de la ressource dans laquelle nous placerons les valeurs. La ressource est mentionnée dans l’attribut rdf:about de l’élément <description> . Enfin la propriété et sa valeur sont déclarées ici comme attribut XML, soit dc:Title="D-Lib Program - Research in Digital Libraries" pour le titre de la ressource. Une fois les déclarations préliminaires faites pour un document RDF, nous pourrons donc rencontrer des exemples basiques d’assertion comme celui ci : <rdf:Description about="http://www.w3.org/Home/Lassila" > < dc:Creator>Ora Lassila</ s:Creator> </ rdf:Description> Il sera l’expression du triplet : - Sujet (Resource) : http://www.w3.org/Home/Lassila - Predicat (Property) : Creator - Objet (literal) : "Ora Lassila" Cette assertion peut aussi être représentée par un graphe étiqueté orienté, système formel aux propriétés mathématiques bien définies sur lequel est basé RDF.

32

Figure 1 : Graphe simple avec un nœud et un arc

Précisions sur les ressources, les propriétés et le urs valeurs : raffinements. L’élément <description> peut contenir plusieurs attributs. Nous avons l’attribut rdf:about , mais il existe aussi les attributs rdf:ID (pour pouvoir donner un identifiant à une déclaration RDF) , rdf:type (pour pouvoir donner un type prédéfini dans un schéma à une ressource). De plus, les éléments <description> peuvent être emboîtés (nested). Différentes formes de valeurs peuvent être données à une propriété : une chaîne de caractères littérale, une URI qui fait référence à une ressource, du langage XML bien formé ce qui a été dit déjà plus haut mais aussi une ressource anonyme avec ses propres propriétés, une ressource typée avec ses propriétés propres en plus de son URI. RDF permet aussi l’utilisation de containeurs de ressource : collection (<rdf:bag> ), séquence (<rdf:seq> ) ou alternative (<rdf:alt> ). L’utilisation de l’attribut rdf:aboutEach dans l’élément <description> permet ensuite d’affecter des propriétés avec la même valeur à un ensemble de ressources. L’utilisation de l’attribut bagID dans un élément <description> permet lui de réifier les propriétés contenues dans la déclaration RDF. L’exemple [42] suivant permettra de comprendre cette dernière caractéristique du langage RDF. <rdf :RDF> <rdf:Description rdf:about="http://www.epolitix.com/Articles/00000 5a4787.htm" bagID="classement" > <dc:Subject rdf:resource="http://iptc.org/Subje ctCode#10101011" /> <dc:Subject rdf:resource="http://iptc.org/Subje ctCode#10101012" /> <dc:Subject rdf:resource="http://iptc.org/Subje ctCode#10101013" /> </rdf:Description> <rdf:Description aboutEach="classement"> <dc:Creator>Craig Hoy</dc:Creator> </rdf:Description> </rdf:RDF> Dans cet exemple, il est dit en fait que Craig Hoy est l’auteur du classement de l’article référencé par son URL ("000005a4787.htm ") dans les trois catégories (code 11, 12 et 13 définis par l’organisation IPTC). L’utilisation de l’attribut bagID permet de faire la description qui nous intéresse de façon « classique », ici la catégorisation d’un article, puis son utilisation dans la deuxième description permet de faire une déclaration à propos de cette première déclaration : c’est Craig Hoy qui est l’auteur de chacun de ces classements de l’article dans les catégories sus-mentionnées. Le langage RDF, grâce à la réification, a la puissance nécessaire pour décrire un système de connaissance. Récapitulation 25 Nous avons ainsi vu comment RDF est un modèle logique pouvant représenter les méta données, en utilisant le concept clé de triplet {ressource, propriété, valeur}, déclarations (« statement ») qui

25 « summary » en anglais.

Creator http://www.w3.org/Home/Lassila

Ora Lassila

33

décrivent des ressources (i.e. des composants documentaires). Nous avons aussi vu comment RDF fournit une syntaxe pour représenter ce modèle avec le langage XML.

2.3.3.3. Schémas RDF

Les déclarations RDF définissent des relations entre des objets (nœud d’un graphe) qui appartiennent à un univers sémantique. A chacun de ces univers sémantiques correspond un domaine nominal, identifié par un préfixe particulier. Un tel domaine, pour lesquels sont définies des propriétés spécifiques et des catégories conceptuelles, est appelé un schéma. Tout utilisateur a la possibilité de créer un nouveau schéma, de modifier, et notamment d’enrichir et d’affiner un schéma existant, de créer ce faisant un nouveau schéma personnalisé, et d’utiliser un schéma pour décrire les propriétés d’objets ayant une existence dans ce schéma. RDFS (pour « RDF Schema ») offre les moyens de définir un modèle (ou bien encore un schéma) de méta données qui permet de : - donner du sens aux propriétés associées à une ressource ; - formuler des contraintes sur les valeurs associées à une propriété afin de lui assurer aussi une signification. Par exemple, si l’on a une propriété qui représente un auteur26, on peut exiger que les valeurs de cette propriété soient une référence à une personne (et non pas une voiture ou une maison). On peut aussi vouloir restreindre quelles sont les propriétés s’appliquant à une ressource. Cela n’a probablement aucun sens d’autoriser une propriété « date de naissance » à être appliquée à un morceau de musique. Déclaration d’une propriété dans un schéma RDFS Une propriété est spécifiée dans un schéma RDFS en déclarant une URI qui identifie la ressource qui représente la propriété et où le type rdf:type de la ressource est rdf:property . Nous donnons ci-dessous un exemple extrait du schéma des méta données de Dublin Core qui définit le public (“audience“) comme étant une propriété RDF mais aussi comme étant une instance de la classe element du schéma de Dublin Core. <rdf:Property rdf:about="http://purl.org/dc/terms/a udience"> <dc:type rdf:resource="http://dublincore.org/usage/documents /principles/#element"/> </rdf:Property> Restriction du domaine de valeur des propriétés Pour indiquer qu’une propriété peut prendre seulement certaines valeurs, on utilise le prédicat (la propriété) rdfs:range . Par exemple, pour exprimer qu’un créateur ne peut avoir que des ressources de type Personne (person) pour valeur, on a l’exemple suivant. <rdf:property rdf:about=”http://purl.org/dc/element s/1.1/creator”> <rdfs:range rdf:resource=”http://www.schema.org/T R/rdf-schema#Person> </rdf:property> Si l’on veut indiquer que les valeurs que peut prendre le type Personne (Person) sont uniquement des chaînes de caractères littérales, on rajoutera la ligne suivante à l’exemple précédent. <rdfs:range rdf:resource=”http://www.w3.org/2000/ 01/rdf-schema#Literal"> On obtiendra la déclaration suivante : <rdf:property rdf:about=”http://purl.org/dc/element s/1.1/creator”>

26 Autrement dit, si on a la propriété « auteur »

34

<rdfs:range rdf:resource=”http://www.schema.org/T R/rdf-schema#Person> <rdfs:range rdf:resource=”http://www.w3.org/2000/ 01/rdf-schema#Literal"> </rdf:property> Restriction du domaine d’application des propriétés La propriété rdfs:domain est utilisée pour indiquer quel type de ressource peut être associé avec le sujet (la ressource) d’une propriété particulière. Dans l’exemple suivant, on précise qu’une date de naissance ne s’applique qu’à une ressource de type personne tout en rappelant que la valeur possible d’une date de naissance est un littéral. <rdf:property rdf:about=”http://www.schema.org/TR/r df-schema#birthDay”> <rdfs:domain rdf:resource=”http://www.schema.org/ TR/rdf-schema#person> <rdfs:range rdf:resource=”http://www.w3.org/2000/ 01/rdf-schema#Literal"> </rdf:property> Déclaration d’une classe de ressource Nous avons vu dans le chapitre précédent sur RDF que nous pouvons typer une ressource déclarée avec RDF en utilisant l’attribut rdf:type dans l’élément <description> et de ce fait ajouter de l’information à propos de la ressource. Continuons avec l’exemple précédent. Pour pouvoir considérer la ressource Personne comme une classe, il faut la déclarer ainsi dans un schéma RDF avec rdfs:class : <rdf:Description rdf:about=”http://www.schema.org/T R/rdf-schema#Person”> <rdf:type resource=”http://www.w3.org/2000/01/rdf -schema#Class"> </rdf:Description> Cela peut aussi s’écrire de la manière suivante : <rdfs:Class rdf:about=”http://www.schema.org/TR/rdf -schema#Person” /> On peut sous-classer des types de ressources, par exemple la classe personne en fonction d’un métier. Ainsi la classe Compositeur (de musique) et la classe Réalisateur sont des sous-classes de la classe Créateur qui elle-même peut être une sous-classe de la classe Personne. On utilisera pour cela la propriété rdfs:subClassOf . Exemple d’utilisation du schéma RDFS issu des exemp les de cette section Nous pouvons maintenant déclarer à titre d’exemple final des méta données concernant un cas fictif approchant la réalité et reprenant le schéma de nos exemples. La date de naissance qui s’applique à John Smith, qui est une personne, est bien une valeur littérale. John Smith, une personne, est par ailleurs le créateur de la ressource dont le titre est « Utilisation des méta données dans notre organisation ». <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-synta x-ns#" xmlns:dc="http://purl.org/metadata/dublin_core#" xmlns:s="http://www.schema.org/TR/rdf-schema#"> <rdf:Description about="http://www.ourorg.net/met adatause.html"> <dc:title>Utilisation des méta données dans not re organisation </dc:title> <dc:Creator> <rdf:Description about="http://www.ourorg.net /member/JohnSmith"> <rdf:type rdf:resource=”http://www.schema.org/TR/rdf- schema#Person” /> <s:birthDay>1954-06-23</s:birthday> </rdf:Description> </dc:Creator> </rdf:RDF>

35

Précisions et raffinements sur les schémas RDFS 1. D’autres éléments du schéma RDFS existent : rdfs:Label , rdfs:comment , rdfs:seeAlso , rdfs:isDefinedBy . Leur description est reprise dans le Tableau 7 en annexe 4.1. Un exemple issu du schéma RDFS des méta données de Dublin Core reprend ces éléments. <rdf:Property rdf:about="http://purl.org/dc/terms/e ducationLevel"> <rdfs:label xml:lang="en-US">Audience Education Lev el</rdfs:label> <rdfs:comment xml:lang="en-US"> A general statement describing the education or tra ining context. Alternatively, a more specific statement of the loc ation of the audience in terms of its progression through an education or tr aining context. </rdfs:comment> <rdfs:isDefinedBy rdf:resource="http://purl.org/dc/ terms/"/> <rdfs:subPropertyOf rdf:resource="http://purl.org/d c/terms/audience"/> </rdf:Property> 2. De même, le schéma RDFS définit et déclare les éléments de RDF. Par exemple, l’attribut ressource est définit comme une classe. <rdfs:class rdf:ID=”Ressource” /> 27 Mais cela outrepasse notre propos qui est de voir comment un schéma de méta données peut être créé afin de constituer un vocabulaire de méta données spécifiques de documents propres à une organisation et non pas d’étendre le modèle de schéma RDFS, comme peuvent le faire DAML ou OIL. On trouvera en annexe 4.1 deux tableaux récapitulatifs du vocabulaire utilisé dans RDF. En annexe 4.2, on trouvera un exemple de schéma RDFS qui est une extension de schéma RDFS utilisant le schéma RDFS de Dublin Core. Enfin, l’annexe 4.3 reprendra un exemple de méta données au format RDF issu de ces schémas et s’appliquant à l’exemple de l’annexe 2.4. On aura ainsi vu à travers cette section traitant des méta données quel peut être le champ que recouvre les méta données (méta données descriptives et d’applications) et comment les représenter (Dublin Core et RDF). Le chapitre suivant, premier chapitre sur l’architecture des systèmes de gestion de contenu, aborde le système de collecte, qui concerne l’acquisition de documents et de leurs méta données dans un système de gestion de contenu.

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.

27 Cela nous donne par conséquence le type RDF rdf:type : « http://www.w3.org/TR/rdf-schema#ressource ».

36

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

37

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 dictionnaires 30. 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

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.

38

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. 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.

39

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

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.

40

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. 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à. 35 - HTTP Extensions for Distributed Authoring - WebDAV 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 WEBDAV Working Group / http://www.ics.uci.edu/~ejw/authoring/ / Jim Whitehead <[email protected]> / Department of Information and Computer Science / University of California, Irvine / Last modified: 03 July 2003

41

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. 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é.

3.1.5. RDF Site Summary (RSS) Cette section présente le modèle et la syntaxe de RSS de telle sorte que le lecteur puisse s’approprier ce cadre38 et l’utiliser dans un système de gestion de contenu et en particulier un système de gestion de site web. Elle est aussi une illustration de l’utilisation de RDF (cf. section 2.3.3) et des méta données de Dublin Core (cf. section 2.3.2) et constitue une suite logique à ce rapport. C’est aussi un exemple concret d’illustration de la section précédente (3.1.4 « EDI et syndication »).


L’objectif de RSS est de permettre l’alimentation d’un site Web avec des composants documentaires provenant d’un autre site web. Il a été initialement mis en œuvre pour afficher les entêtes de nouvelles39 de sites Web d’informations et notamment pour les agréger. Ainsi sur une même page, à propos d’un thème particulier, sont regroupées des entêtes de nouvelles provenant de plusieurs sites web distincts. Chaque site source nourrit le site fédérateur40. Simple en apparence et dans ses spécifications, RSS est très puissant et est utilisé dans de nombreux portails. Un des fondements de RSS à partir de la version 1.0, comme son nom développé nous l’indique (RDF Site Summary), est la mise en œuvre de RDF pour réaliser un document RSS. RSS s’appuie donc aussi sur la notion de domaines nominaux (namespaces – cf. section 2.3.3.1). RSS est un exemple d’application et de l’extensibilité de RDF à travers l’utilisation des schémas RDF (voir annexe 5.1 « Schéma RDF des documents RSS »). La version actuelle de la norme RSS est 1.0. Elle est compatible avec les versions précédentes (0.91 et 0.9 qui n’utilisait pas RDF). RSS est un format de syndication à vocation normative développé par

36 système source : système d’origine où sont créés et maintenus les documents. 37 Syndication : terme d’origine anglo-saxonne. Certains parlent parfois de fédération ou d’agrégation. 38 Cadre : référence au terme anglo-saxon « framework », qui est aussi traduit par ossature, squelette... 39 Nouvelles : news, annonces, brèves… 40 D’où le terme anglais “RSS feed”, utilisé comme concept RSS.

42

un groupe indépendant : le groupe de travail RSS41. Elle ne devrait plus évoluer, seuls de nouveaux modules permettent de l’étendre. RSS n’est donc pas prévu initialement pour échanger des documents, mais plutôt les méta données des documents. Cependant, avec la version 1.0 et son mécanisme d’extension à travers l’utilisation et le rajout possible de modules, il est théoriquement possible d’échanger des documents. Un module est un schéma RDF complémentaire. En tant qu’application de RDF, RSS montre bien que ce premier convient bien à l’échange de méta données, comme cela est son objectif (cf. section 2.3.3.1). Concrètement, dans le CMS important les composants documentaires, seul le fichier RSS et donc les méta données sont intégrées. Le document n’est relié que par un lien (un URI) permettant d’accéder au document dans le système source. Le format RSS est concrètement un document XML qui obéit à une structure de base. Les modules permettent d’enrichir la structure de base [44] [45]. Nous allons maintenant aborder ces éléments du format de syndication RSS.

3.1.5.2. Structure de base

La structure de base d’un document RSS est la suivante [46], dans l’ordre : - déclaration XML, - le conteneur , - description du canal, - description de l’image (optionnelle), - description du ou des articles, - description du champ de saisie (optionnelle). Cette structure est toujours la même dans les documents RSS. Elle est conforme au schéma RDF des données RSS (annexe 5.1 « Schéma RDF des documents RSS »). Aussi, un exemple [44] permet d’aborder chaque élément de la structure. <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-synta x-ns#" xmlns="http://purl.org/rss/1.0/" > <channel rdf:about="http://www.xml.com/xml/news.r ss"> <title>XML.com</title> <link>http://xml.com/pub</link> <description> XML.com features a rich mix of information an d services for the XML community. </description> <image rdf:resource="http://xml.com/universal/i mages/xml_tiny.gif" /> <items> <rdf:Seq> <rdf:li resource="http://xml.com/pub/2000/0 8/09/xslt/xslt.html" /> <rdf:li resource="http://xml.com/pub/2000/0 8/09/rdfdb/index.html" /> </rdf:Seq> </items> <textinput rdf:resource="http://search.xml.com" /> </channel>

41 RSS Working Group : http://web.resource.org/rss

43

<image rdf:about="http://xml.com/universal/images /xml_tiny.gif"> <title>XML.com</title> <link>http://www.xml.com</link> <url>http://xml.com/universal/images/xml_tiny.g if</url> </image> <item rdf:about="http://xml.com/pub/2000/08/09/xs lt/xslt.html"> <title>Processing Inclusions with XSLT</title> <link>http://xml.com/pub/2000/08/09/xslt/xslt.h tml</link> <description> Processing document inclusions with general XM L tools can be problematic. This article proposes a way of pr eserving inclusion information through SAX-based processing. </description> </item> <item rdf:about="http://xml.com/pub/2000/08/09/rd fdb/index.html"> <title>Putting RDF to Work</title> <link>http://xml.com/pub/2000/08/09/rdfdb/index .html</link> <description> Tool and API support for the Resource Descript ion Framework is slowly coming of age. Edd Dumbill takes a l ook at RDFDB, one of the most exciting new RDF toolkits. </description> </item> <textinput rdf:about="http://search.xml.com"> <title>Search XML.com</title> <description>Search XML.com's XML collection</d escription> <name>s</name> <link>http://search.xml.com</link> </textinput> </rdf:RDF> Cet exemple requiert bien sûr des commentaires supplémentaires. Notons déjà que chaque élément est décrit par des propriétés title , link , description . La propriété link contient une URL pointant vers l’élément décrit. La propriété description est optionnelle (pour l’élément item ), absente pour l’élément image ou obligatoire pour les autres éléments (channel et textinput ). L’élément channel définit le site ou la page web (la ressource) syndiquée. Un fichier RSS décrit un « canal » RSS. L’élément channel contient une référence aux éléments associés : image , items , textinput . On peut penser qu’il s’agit d’une redondance puisqu’on les trouve dans la suite du document RSS de l’exemple, mais c’est surtout une facilité pour des traitements complémentaires. L’élément image permet d’associer une image au canal RSS dans le site Web fédérateur. L’image doit être normalement d’une dimension de 88x33 pixels. L’élément item définit le composant documentaire recherché pour la syndication. Il peut être répété 15 fois au maximum dans les versions 0.9x de RSS. C’est le cœur du document RSS. Enfin l’élément textinput permet d’associer un champ de saisie à une URL qui reçoit via la méthode HTTP GET la valeur de la variable de requête saisie. Cet élément est l’objet de controverses dans le groupe de travail RSS41. Il est utilisé traditionnellement comme boîte de recherche ou comme champ de formulaire. Comme cela a été dit. Cela paraît simple et çà l’est. Mais cela offre déjà des mécanismes d’agrégation (fédération) puissant. Cependant, il est possible de les étendre encore via l’utilisation des modules RSS, objet du chapitre suivant.

44

3.1.5.3. Modules

La structure de base d’un document RSS peut être enrichie grâce à l’utilisation des modules RSS [47]. La modularisation est basée sur la capacité d’extension de RDF (cf. 2.3.3.3 « Schémas RDF ») et offre à RSS la capacité d’être étendu. Les modules reconnus comme normes associées à RSS 1.0 par ses auteurs sont les suivants : - Dublin Core, - Syndication, - Content. Cependant, le module « Content » n’est pas inclus par défaut dans RSS 1.0 alors que les modules « Dublin Core » et « Syndication » le sont. Un exemple d’enrichissement de la structure d’un « canal » RSS par l’utilisation des modules est donné en annexe 5.2 intitulée Exemple de fichier RSS de syndication, sauf pour le module « Content » qui ne sera pas illustré. Le module Dublin Core RSS adopte le schéma de méta données de Dublin Core pour définir un ensemble de méta données normalisées associé à RSS 1.0 [48]. Tous les éléments pour comprendre son utilisation sont contenus dans les sections 2.3.2 « Dublin Core Metadata Initiative (DCMI) » et 2.3.3 « Resource Description Framework (RDF) ». Le module Syndication Ce module [49] est conçu pour fournir un exemple de variables de fréquence de mise à jour à ceux qui utilisent RSS pour agréger des informations. Il contient 3 éléments : updatePeriod , updateFrequency et updateBase . L’élément updatePeriod définit la période au delà de laquelle le « canal » est mis à jour. C’est à dire qu’il définit la période de rafraîchissement du fichier RSS importé par le CMS "agrégateur". Les valeurs acceptées sont hourly, daily, weekly, monthly, yearly, soit en français, toutes les heures, quotidiennement, hebdomadairement, mensuellement et annuellement. L’élément updateFrequency est utilisé pour décrire la fréquence des mises à jour en relation avec la valeur définie pour la période de mise à jour. Un entier positif indique combien de fois dans cette période le « canal » est mis à jour. Par exemple, une période quotidienne et une fréquence de mise à jour de « 2 » indiquent que le canal RSS est mis à jour deux fois par jour. Enfin, l’élément updateBase définit, en concert avec les deux éléments précédent, la date et l’horaire de la mise à jour de la publication. L’élément updateBase permet de calculer cette date. On s’aperçoit ici que RSS a bien été conçu et utilisé pour la gestion de site web. Le format de date se conforme au format de date42 définit par le W3C. Ces éléments montrent que RSS est prévu pour que cela soit le site fédérateur qui interroge le site d’origine du document. Cela a cependant un coût important au regard de ce qu’il serait si, à l’inverse, il était prévu que cela soit le site d’origine qui mette à jour le site "syndicateur" uniquement en cas de mise à jour du composant documentaire original. Le module « content » C’est un module qui permet de répliquer le contenu effectif du site web fédéré et qui permet de définir les formats du contenu. La partie concernant les contenus encodés (content:encoded ) n’est pas « normalisée » par le groupe de travail RSS [50].

42 W3CDTF - W3C Date Time Format : http://www.w3.org/TR/NOTE-datetime

45

Aussi ce module définit un seul élément central : item . que nous écrivons content:item afin de le diffrencier de l’élément item de la structure de base de RSS (cf. section 3.1.5.2 « Structure de base »). Les éléments content:item sont inclus dans un élément englobant content:items qui est lui-même un sous-élément de l’élément item ou de l’élément channel de RSS. Un élément content:item peut inclure les sous-éléments suivants : content:format , content:encoding , rdf:value (voir Tableau 7 : Propriétés RDF page 112 pour la définition de rdf:value ). L’élément content:format est obligatoire. C’est un élément vide (au sens XML) contenant un attribut rdf:resource qui pointe vers une URI représentant le format de l’élément content:item . La meilleure pratique suggérée est d’utiliser la liste des « natures » RDDL43 (Resource Directory Description Language). RDDL définit les valeurs possibles de la nature d’une ressource référencée de la manière suivante44 : « Quand une ressource référencée est un document XML et que sa nature peut-être déduite de l’URI du domaine nominal de l’élément racine du document XML, l’URI de domaine nominal est la nature de la ressource référencée. Quand une ressource référencée n’est pas un document XML et que sa nature peut être déduite de son type MIME45, la nature de la ressource référencée est obtenue en attachant le type de contenu46 au préfixe http://www.isi.edu/in-notes/iana/assignments/media-types/ » . Cette référence à tout type de document XML et aux types de contenu MIME offre une couverture largement acceptable et presque universelle des types de documents existants dans le monde. Il semble cependant qu’il y ait là une ambiguïté entre le « type de document » et le « format » tel qu’ils sont décrit par le DCES47. L’élément rdf:value est obligatoire si aucune URI n’est définie dans l’attribut rdf:about de l’élément content:item . L’élément contient le contenu du composant documentaire. C’est donc le cœur du module et en tout cas son objet. Il est encodé comme spécifié dans l’élément content:encoding . Si le contenu est en XML et que l’élément content:encoding ne précise rien, alors l’attribut rdf:parseType doit avoir la valeur "Literal" (rdf:parseType="Literal" ) afin de respecter la syntaxe RDF. content:encoding est un élément optionnel vide (au sens de XML) avec un attribut rdf:resource pointant vers une URI qui doit représenter l’encodage du contenu de content:item . A travers les exemples des spécifications du module « content » [50] et la préférence affichée pour l’utilisation de valeurs contenues dans la liste RDDL des natures44, on s’aperçoit avec ce dernier élément (content:encoding ) que le module « content » est surtout prévu pour échanger des documents de type XML ou HTML, c’est à dire des formats de documents contenus dans des serveurs web.

3.1.5.4. conclusion

RSS est un exemple de format de syndication de documents issu et utilisé principalement pour la gestion de site web et par extension dans les portails. La structure de base de RSS permet la réplication des méta données des composants documentaires. Ces méta données peuvent être étendues de manière non-limitative grâce aux modules. RSS est aussi assez complet pour pouvoir autoriser la réplication des documents eux-mêmes grâce au module « Content ». RSS est donc un exemple intéressant de protocole d’EDI pour la gestion de contenu qui illustre l’échange de méta données et de composants documentaires. Le respect de XML et de RDF par RSS fait qu’il est par ailleurs largement substituable par un format propriétaire offrant les mêmes services.

43 Resource Directory Description Language : http://www.rddl.org/ 44 URIs For Common Natures of Resources : http://www.rddl.org/natures/ 45 MIME - Internet Media Types. http://www.isi.edu/in-notes/iana/assignments/media-types/media-types 46 Type de contenu : MIME content-type. 47 DCES : Dublin Core Element Set (voir tableau 5: « méta données de l’initiative de Dublin Core », page 109).

46

3.1.6. Droits d’accès et travail collaboratif Ce sujet fait partie de la section sur le « Système de collecte » car il est une des composantes indispensables des systèmes de collecte. Concernant les droits d’accès, Il est aussi relié à la publication des documents, notamment dans les systèmes où le contenu n’est pas séparé de la présentation et donc de la publication.

3.1.6.1. Droits d’accès

Les droits d’accès de base à un document sont simples : lecture (R), écriture (W), suppression (D)48. En lecture, un utilisateur a accès à un composant documentaire mais ne peut pas le modifier ou encore le mettre à jour, ce qu’il peut faire s’il a les droits d’écriture. Le droit de suppression est assez explicite. Les droits d’accès peuvent être spécifiés dans une matrice ad hoc dite matrice des droits d’accès . Il s’agit d’un tableau reprenant les variables utilisateurs, groupe de travail et droits d’accès. On doit donc introduire ici la notion de groupe de travail . Un groupe de travail est composé d’utilisateurs. Les droits peuvent être affectés à un utilisateur ou à un groupe de travail. Si un utilisateur fait partie d’un groupe de travail, il hérite des droits du groupe. Les droits d’accès peuvent être définis document par document. Mais il est beaucoup moins complexe de définir les droits en fonction des types de documents (cf. 2.1.2.2 « Type de document : DTD / XML schema / Template »). La traduction logique d’une matrice des droits peut être représentée par une liste ACL (Access Control List). Par ailleurs, une acceptation commune et la meilleure pratique sont de centraliser les données des utilisateurs et des groupes de travail dans des annuaires LDAP (Lightweight Directory Access Protocol). La plupart des logiciels de CMS propose une connexion aux annuaires LDAP afin de gérer les utilisateurs dans l’application de gestion de contenu.

3.1.6.2. Travail collaboratif : workflow

Le travail collaboratif, et plus précisément le workflow, est un sujet à part entière de la gestion de contenu, et en l’étendant, qui s’applique à la gestion des processus d’affaire (Business Process Management – BPM). Concernant la gestion de contenu, le travail collaboratif est défini par les chaînes d’édition . Il s’agit du processus qui va de la création à la publication d’un document. Un workflow est défini par des étapes : du démarrage du processus à sa terminaison. Chaque étape est déterminée par le passage d’un état de l’objet du workflow à un autre. Une tâche consiste à faire passer l’objet (en clair, le document) d’un état à un autre. La tâche est réalisée par un utilisateur ayant le rôle adéquat. Le processus d’édition le plus simple et le plus fréquent est le suivant. L’auteur crée (ou met à jour) un document, l’éditeur le valide (ou le refuse) puis le document est publié automatiquement. Certains documents réclament toutefois une organisation plus complexe (notamment les documents composites). Les états de base d’un document dans une chaîne éditoriale est : crée ou mis à jour, soumis (à la validation de l’éditeur), validé ou refusé et publié. Un document validé est souvent publié automatiquement suite à sa validation, mais peut parfois être publié ultérieurement. Un workflow peut être exécuté séquentiellement (les tâches sont effectuées les unes après les autres) ou en parallèle (les tâches sont effectuées en même temps, indépendamment l’une de l’autre). Une tâche peut être affectée à plusieurs utilisateurs et ne nécessiter que l’intervention de l’un d’entre eux.

48 R, W, D : Read, Write, Delete.

47

Par exemple, un document peut être soumis à validation à plusieurs éditeurs et seule une validation par un des éditeurs suffira pour que le document passe à l’étape suivante. Il faut introduire ici une nouvelle notion : celle de rôle . On affecte dans un workflow une tâche à un rôle. On affecte aussi à un utilisateur un rôle dans un groupe de travail. Donc finalement, un utilisateur hérite de ses droits dans un groupe de travail à travers l’affectation d’un rôle. Ce rôle basiquement consiste en une opération équivalente aux droits mentionnés ci-dessus, à savoir la lecture, l’écriture et / ou la suppression d’un document. Mais ce rôle peut être plus complexe, à savoir que s’il requiert un droit de base, il peut effectuer des opérations spécifiques. Dans ce contexte, l’utilisateur peut-être aussi un programme informatique. Par exemple, c’est peut-être un automate qui va effectuer certains pré-traitements comme la catégorisation du document, sa traduction en langue étrangère, sa correction orthographique. Le rôle peut ne concerner aussi qu’uniquement les méta données. C’est à dire, par exemple, qu’un utilisateur, typiquement un documentaliste, peut n’avoir le droit d’écriture que sur plusieurs méta données et que le droit d’écriture sur le composant documentaire. Dans le cadre d’une application de gestion de contenu, les rôles les plus fréquemment rencontrés de manière basique sont l’auteur (aussi appelé rédacteur), l’éditeur (qui valide les documents avant publication, encore appelé approbateur) et bien sûr l’administrateur. Le rôle de l’administrateur (parfois appelé coordinateur) a trait à la gestion des groupes de travail et contrôle un certain nombre de paramètres à ce niveau là. Il ne faut bien sûr pas le confondre avec l’administrateur de l’application. L’administrateur ne rentre pas dans les processus Un autre rôle, souvent implicite, est celui de lecteur . Le rôle doit être théoriquement défini au niveau de chaque composant documentaire. La définition du rôle peut être une méta donnée d’application (cf. sections 2.3.1.2 « Données d’application » et 2.3.1.4 « Données de personnalisation »). Le rôle est repris aussi dans les spécifications de la chaîne d’édition. On peut spécifier une chaîne d’édition à l’aide d’un graphe ou encore d’un diagramme état-transition . La figure suivante illustre cela.

48

Figure 2 : exemple de diagramme état-transition de spécification d’une chaîne d’édition

Auteur : Création /Mise à jour du

document

Auteur assisté par lelogiciel :

Indexation,catégorisation,

correctionorthographique

Editeur : Validation etcorrection du

document

document rédigé

document indexé, catégorisé, orthographié

Document à améliorer

Document publié

Document validé

Les autres composantes du travail collaboratif sont le courrier électronique, les forums de discussion, la conférence électronique (vocale ou vidéo), le tableau blanc partagé, les outils d’annotation de documents… Voyons ensuite, sans transition, maintenant que le système de collecte d’un CMS a été vu, en quoi consiste un système de gestion de contenu.

3.2. Système de gestion de contenu Il y a un paradoxe à appeler système de gestion de contenu la partie centrale d’un système de gestion de contenu qui peut contenir par ailleurs un système de collecte, comme nous l’avons vu, et un système de publication comme nous le verrons après. Le système de gestion de contenu (CMS), englobe donc les systèmes de collecte et de publication, mais est plus spécifiquement le référentiel central où idéalement est stocké l’ensemble du contenu dans un format unifié et où en tout cas l’unicité et la cohérence du contenu sont garanties, c’est à dire où sont stockées les méta données. Le système de gestion de contenu contient donc les méta données mais aussi les fichiers de configuration des utilisateurs, de leurs droits et leurs éventuelles données de personnalisation, des modèles de documents, des processus d’édition (paramétrage des workflows). Théoriquement un système de gestion de contenu peut-être indépendant des systèmes de collecte et de publication. Idéalement, ils sont complètement intégrés ensemble dans un système prenant le même nom de « système de gestion de contenu ». Dans la pratique, aujourd’hui, les CMS se situent à un endroit entre ces deux extrêmes. Nous abordons dans ce chapitre l’administration d’un système de gestion de contenu car cela illustre concrètement les concepts théoriques que nous avons abordés ou qui restent à aborder dans cette

49

première partie A du rapport. Nous verrons ensuite en quoi consiste un référentiel de composants documentaires.

3.2.1. Administration d’un CMS Nous ne pourrons dans cette section qu’évoquer l’administration d’un CMS qui est une tâche complexe. Ceci bien que, si les concepts que nous avons abordés jusqu’à maintenant et qui seront abordés dans les sections suivantes sont bien assimilés, cela peut s’avérer une tâche simple [51] [52] [53] [54] [55] [56] [57] [58] [59]. Cette section résulte de l’expérience que nous avons pu acquérir en installant le jeu d’essai nécessaire à l’évaluation détaillée des systèmes de gestion de contenu retenus pour notre étude et objet de la section 2 de la partie B de ce rapport. Elle offre une vue complémentaire des systèmes de gestion de contenu à celle que nous proposons tout au long de cette première partie d’ouvrage.

3.2.1.1. Paramétrage

Le paramétrage d’un CMS doit être complet avant que celui ci puisse être mis en œuvre, voire testé car ils sont interdépendants. Il faut donc que chacun des points suivants soit défini. Utilisateurs, rôle, groupe de travail et droits Section théorique associée : 3.1.6 « Droits d’accès et travail collaboratif ». 1. Un des premiers travaux de paramétrage d’un système de gestion de contenu consiste à renseigner qui sont les utilisateurs de l’application. Les variables utilisateurs impératives sont le login (identifiant utilisateur) et le mot de passe associé afin d’authentifier l’utilisateur lors du démarrage de sa session de travail avec le CMS. On y rajoute la plupart du temps les variables nom et prénom. 2. Il faut ensuite définir et enregistrer les groupes de travail. A ce stade, comme les mécanismes utilisés sont les mêmes, on peut aussi définir et enregistrer les rôles. Les rôles peuvent être assimilés aux « alias ». Il y a identité entre un groupe de travail et un répertoire du système de gestion de fichier ou une rubrique d’un site Web jusqu’à parfois trouver un nom identique pour le groupe de travail et le répertoire ou la rubrique. 3. Le paramétrage des utilisateurs, des groupes de travail et des rôles effectués, on peut alors affecter les rôles aux utilisateurs et les rôles dans les groupes de travail. Affecter les rôles aux utilisateurs n’est pas obligatoire mais constitue vraiment la meilleure pratique dans ce domaine lors de la phase de maintenance d’un CMS. En effet, lors du changement d’affectation (arrivée, départ, mutation) d’un collaborateur, il y a changement de rôle ; il suffit alors de retirer le rôle à l’utilisateur et de lui en affecter de nouveau. Il n’y a pas à revoir à ce moment toutes les affectations aux groupes de travail qui peuvent être très nombreuses. 4. Pour chaque groupe de travail sont défini à ce stade les droits associés. Ainsi, classiquement, pour un répertoire (ou une rubrique) recoupant un domaine fonctionnel de l’organisation, on trouve un groupe de travail avec les droits en lecture (le groupe des utilisateurs), un second avec les droits en mise à jour (le groupe des auteurs) et enfin un dernier avec les droits de suppression en sus (le groupe des éditeurs). Les droits de suppression sont souvent assimilés à des droits d’administration du groupe de travail. D’autres droits sont nécessaires pour pouvoir gérer un groupe de travail : droit de gestion des utilisateurs, droit de paramétrage des workflows. De manière générale, il faut pouvoir définir les droits pour l’ensemble des activités du groupe de travail. On pourrait penser que ces droits sont ceux de l’administrateur général du CMS. Mais l’activité d’un CMS, vu qu’elle recoupe de multiples activités de l’organisation (cf. « INTRODUCTION » page 2), peut devenir si foisonnante qu’une délégation des tâches (et donc des droits) d’administration peut s’avérer vitale.

50

Les droits ainsi définis au niveau du groupe de travail seront hérités par défaut pour les documents issus du groupe de travail, à moins de préciser des modalités particulières pour chaque document si nécessaire. 5. L’ensemble des informations mentionnées dans cette section jusqu’à maintenant peut se gérer à partir du répertoire général des utilisateurs de l’entreprise, c’est à dire Active Directory pour les systèmes Microsoft NT ou LDAP pour n’importe quel système. Les éléments d’administration concernant les utilisateurs, les rôles et les groupes de travail peuvent donc être gérés à l’extérieur du CMS, charge à lui de récupérer et utiliser ces informations indispensables à son fonctionnement. Enfin, l’authentification et la sécurité dans les CMS peuvent faire appel à un mécanisme supplémentaire : l’authentification à base de certificat49, l’utilisateur étant authentifié par le CMS grâce à un certificat. Workflows Section théorique associée : 3.1.6.2 « Travail collaboratif : workflow ». A chaque type de document édité par un groupe de travail, on associe et doit définir un workflow. Des mécanismes inhérents au logiciel de CMS peuvent permettre d’affecter des workflows pré-définis à l’édition d’un type de document par un groupe de travail. Il faut donc décrire le workflow et notamment les rôles qui y participent. La définition d’un workflow consiste en un véritable développement informatique. Le paramétrage du workflow, c’est à dire l’affectation d’un utilisateur à une tâche, est une tâche d’administration. Règles de publication et d’archivage : définition d u cycle de vie d’un document Section théorique associée : « Cycle de vie du document (dates, statuts et versions) » page 28. La définition et le paramétrage de ces règles permettent d’automatiser le cycle de vie des documents. Les règles sont définies par type de document. On doit aussi pouvoir appliquer des règles spécifiques à un document particulier si nécessaire. L’exemple le plus typique est la définition de la date de publication d’un document valide, par exemple tous les lundis. Le retrait de la publication est aussi une règle typique : « retirer tous les documents de type "nouvelle" un mois après leur publication ». Autre exemple de règle : « notifier automatiquement l’éditeur des documents refusés non re-soumis à validation après 10 jours ». De la même manière, on peut définir les règles d’archivage et de purge des documents : « archiver les pièces comptables des exercices antérieurs à trois années conformément à la législation en vigueur », « détruire ces mêmes pièces 20 ans après leur création », etc.. On associe donc une règle aux dates et aux statuts des documents. Fichiers de contrôles et de configuration Sections théoriques associées : 2.1.2.2 « Type de document : DTD / XML schema / Template », 2.3 « Concept clé numéro 3 : les méta données », 3.1.1 « Edition de documents », 3.3.1 « Mise en forme ». 1. Rappelons le, un des éléments fondamentaux d’un système de gestion de contenu est le type de document. On doit donc renseigner dans le CMS les données de configuration des types de document , par exemple le schéma XML ou la DTD d’un type de document. On doit aussi intégrer le fichier de contrôle correspondant, c’est à dire le formulaire de saisie correspondant à la notion de template ou encore de modèle de document . 49 Les certificats permettent de gérer, entre autre, les aspects légaux de la signature électronique si nécessaire.

51

2. A chaque type de document, sont associées les méta données nécessaires. Il faut donc aussi les définir, par type de document, afin de permettre leur saisie ultérieure dans le CMS lors de l’édition d’un document. Les dictionnaires (thésaurus) qui permettent de contrôler le vocabulaire utilisé doivent être intégrés dans le système. On établit les relations entre le dictionnaire et les données (composants documentaires) concernées. De même, on intègre aussi (importation ou saisie) les schémas de classification (taxonomies). 3. Les règles de personnalisation peuvent donner lieu aussi à un fichier de configuration (voir section 3.3.3). 4. Enfin, on intègre aussi dans le CMS les fichiers de transformations : ces fichiers gèrent la publication des documents par type de document. Ils contiennent le code de sélection des composants documentaires à publier en fonction du format de publication, le code d’ajout de comportement (gestion des événements) pour les publications interactives électroniques et enfin le code de mise en forme de la publication. Ces fichiers de transformation peuvent être assimilés à des fichiers de configuration de la publication. Moteur de recherche Section théorique associée : 3.3.4 « Recherche et récupération de document ». La fonction de recherche et de récupération de document est une des fonctionnalités majeures attendue des CMS. Son paramétrage est nécessaire et dépend du logiciel CMS utilisé. Certaines options et paramètres du fonctionnement du moteur de recherche peuvent être précisés et notamment : la liste de « mots stop »50, thésaurus comprenant les règles d’expansion51 des requêtes, règles de lemmatisation, tolérance aux fautes d’orthographe, paramètres de recherche multilingue. Il s’agit là d’un domaine à part entière, nécessitant aujourd’hui une expertise propre. De plus, si le moteur de recherche propose des recherches fédérées sur plusieurs ressources (plusieurs systèmes), il va falloir les renseigner et définir éventuellement des domaines de recherche dans lesquels les utilisateurs vont circonscrire leurs requêtes. Connexions, intégration au système d’information Le paramétrage des systèmes fédérés pour la recherche de documents nécessite par ailleurs de régler les variables de connexion aux systèmes fédérés le cas échéant (type de connexion, driver, URL, directory, dataBaseName, port, userName, password, etc..). Dans le même registre, si l’on opère une syndication (cf. 3.1.4 « EDI et syndication »), il faut la paramétrer (URL du site Web syndiqué par exemple ou du fichier de syndication). L’intégration au système d’information nécessite de prendre en compte aussi certains aspects comme la présence d’un serveur Proxy ou d’un fireWall. Si les données de certains composants documentaires sont synchronisées (cf. 3.1.1.2 « Synchronisation des sources de données ») avec celles d’autres applications du système d’information, il faut aussi paramétrer les connexions aux bases de données. Tous ces aspects de connexion sont largement l’objet du savoir-faire dit « système », ou encore de l’équipe « système », dans le jargon informatique. Ce savoir-faire relève aussi de la problématique générale dite EAI (Enterprise Application Integration), afin de faire communiquer entre elles les applications.

50 Stop words en anglais. 51 prise en compte des synonymes par exemple, sujets approchants…

52

3.2.1.2. Reporting, suivi

Ce chapitre a pour objectif de mettre de donner un aperçu général du suivi (monitoring) d’un CMS et de mettre en évidence les éléments de suivi (compteurs et indicateurs) spécifiques à une application de gestion de contenu. La tâche de l’administrateur système du CMS consiste classiquement à connaître la reprise sur panne, les performances de son système, à effectuer les sauvegardes. Il s’agit là encore d’une compétence dite « système » où les temps de réponse des fonctions appelées, l’activité du (ou des) processeur(s), l’espace disque, l’utilisation de la zone mémoire (vive et virtuelle) doivent être contrôlés afin d’éviter des baisses de qualité de service notables, voire des pannes. Comme les CMS sont des systèmes qui le plus souvent sont bâtis sur une architecture logicielle incluant un serveur web, un système de gestion de base de données et un serveur de courrier électronique, les compétences de l’administrateur doivent être complètes. Si le moteur de recherche est sophistiqué, sa gestion requiert une connaissance précise sur des compteurs et des indicateurs mesurant l’indexation des ressources fédérées. Si le CMS propose des abonnements à des alertes (par exemple : nouveautés d’une rubrique ou d’un groupe de travail, enregistrement d’une recherche d’un utilisateur et alerte pour une nouvelle « trouvaille »…), le temps de propagation des alertes doit être contrôlé. Enfin, un suivi particulier des fils (forums) de discussion doit être effectué si le CMS propose cette fonctionnalité car non seulement ils peuvent s’avérer consommateur de ressources, mais surtout leur contenu doit être souvent modéré. Les indicateurs et les alertes doivent être établis avant le déploiement d’un CMS et se retrouvent grâce à l’observateur d’événements et aux journaux et alertes de performances divers que proposent à la fois le système d’exploitation et le CMS, voire un logiciel spécialisé de suivi du système. Contrôler l’activité du CMS doit permettre [60] : - d’avoir un aperçu global et synthétique du bon fonctionnement du système, - de détecter et de prévoir les tendances, - de détecter les erreurs de fonctionnement, - d’assurer de bonnes sauvegardes des données des serveurs. De ces objectifs du suivi d’un CMS, la détection des tendances est une des plus importantes afin d’adapter le CMS aux attentes des utilisateurs et d’augmenter sa popularité. Des exemples d’indicateurs des fonctions spécifiques d’un logiciel de gestion de contenu sont donnés en annexe 6. Cependant les indicateurs les plus populaires, issus de la gestion de sites Web sont les suivants : - nombre d’utilisateurs (de lecteurs), - nombre de pages (ou de documents) visités, - pages (documents) les plus visités par période, - pour les documents téléchargeables, nombre et documents téléchargés, - durée des sessions des utilisateurs (durée moyenne, durée maximum, fréquence des sessions…), - rubriques les plus visitées (lues, accédées), - contenu des recherches les plus fréquentes (mots les plus recherchés), - nombre de nouveaux documents par rubrique, - nombre de documents mis à jour par rubrique. Finalement, suivre et mesurer l’activité d’une application de gestion de contenu est une pratique de bonne gestion à impérativement prendre en compte dans la phase de maintenance d’une application de CMS.

3.2.2. Référentiel Le référentiel est l’ensemble des bases de données, systèmes de gestion de fichiers et des autres structures du système (e.g., bases de courriers, la base de registres et les variables

53

d’environnements, etc.) qui stockent52 le contenu du CMS, aussi bien que n’importe quelle autre donnée associée avec le système de gestion de contenu, notamment et surtout les méta données. Les composants documentaires et les autres ressources du CMS sont apportés dans le référentiel par le système de collecte et sont extraits par le système de publication [29]. Le système de gestion de contenu, à proprement parler, peut fournir une interface d’administration du référentiel. La figure 3 ci-dessous intitulée « Modèle simple de référentiel » illustre cela.

figure 3 Modèle simple de référentiel de gestion de contenu

Référentiel

Composant DocumentaireCatalogue

Méta données Corps

1..*1

1..* 11

Le référentiel peut correspondre à une application informatique comme il peut simplement représenter une entité théorique ou virtuelle qui n’a d’existence que dans l’esprit de ses utilisateurs. Il est évidemment souhaitable que le référentiel soit une entité logicielle unique stockant des composants au format unique (cf. section 1.7). Concrètement, les méta données, par exemple, peuvent être inclues dans le composant documentaire ou dans le référentiel (voir section 2.3.3.1). Pratiquement, les référentiels que l’on peut rencontrer ne sont le plus souvent constitués que des méta données avec un lien vers la ressource afin de la localiser. On retient donc comme définition du référentiel pour un CMS qu’il s’agit de l’entité qui stocke les identifiants des composants documentaires et tous les liens existants entre les documents. Cette définition s’approche du sens premier du mot référentiel contenu dans son étymologie. La notion de catalogue rejoint celle qui a été abordée dans la section 1.1 « Gestion des bibliothèques physiques ». D’ailleurs, certains acteurs parlent de bibliothèque pour parler de référentiel. Le catalogue est une notion fondamentale dans le sens où il peut servir à découvrir et sert à récupérer les composants documentaires constituants le référentiel documentaire de l’organisation. Le schéma de la figure 3 peut d’ailleurs se transposer au schéma général d’une bibliothèque (si l’on remplace le terme de composant documentaire par celui de ressource bibliographique qui serait alors constitué de sa partie physique – le livre par exemple – et de sa notice). De même, ce schéma peut se transposer jusqu’à une certaine limite à ce que serait un référentiel de gestion de configuration des programmes informatiques d’une organisation [61].

52 Voir section 3.1.3 « Enregistrement (stockage) »

54

3.2.3. Conclusion On pourrait dire en guise de conclusion pour cette section que toute entreprise est dotée d’un système de gestion de contenu, le terme étant considéré au sens large. Cependant soit sa réalité est virtuelle : inorganisation au regard d’un système de gestion de contenu tel que nous l’avons défini jusqu’à maintenant, ce qui revient à une utilisation brute des outils bureautiques, sans définition de type de document, sans utilisation des méta données, sans politique de stockage, sans droits d’accès, sans définition de processus d’édition, etc.. Et finalement sans référentiel documentaire. Soit la réalité du système de gestion de contenu est concrète dans le sens où l’organisation utilise bien un logiciel de CMS, doté d’un référentiel qui établit les liens indispensables entre tous les documents de l’organisation et qui constituent sa base documentaire. Et le principe de séparation du contenu de la mise en forme, les méta données sont bien mis en œuvre. Dans le prochain chapitre, décrivant les éléments d’un système de publication, nous allons pouvoir voir quels sont les liens entre le système de gestion de contenu et le système de publication, et notamment jusqu’où le premier peut englober le second.

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

55

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.

53 Nouvelle : news, brève.

56

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

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 W3C 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

57

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.

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/ .

58

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


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.

59

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.

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 W3C® / 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/

60

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.

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.

61

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. 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,

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/

62

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. 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/

63

B. EVALUATION D’UN SYSTEME DE GESTION DE CONTENU Après avoir abordé les systèmes de gestion de contenu de manière théorique, cette deuxième partie du rapport va nous permettre dans un premier temps de connaître les domaines d’applications de la gestion de contenu, quels en sont les domaines transverses ou les sous-domaines qui y sont mis en œuvre et les fonctionnalités qui leur sont liées. Grâce à cela, nous proposons une grille de classification des logiciels de gestion de contenu par domaine en fonction de leurs fonctionnalités et nous en fournissons un exemple d’utilisation. Sur la base de cette classification fonctionnelle, les systèmes de gestion de contenu peuvent être évalués de manière détaillée. Nous proposons là encore un exemple pratique d’évaluation détaillée, développé dans la section 2. Les éléments de cette deuxième partie du rapport sont issus du travail mené lors de l’étude préalable au développement d’une offre de service en gestion de contenu pour une société de service, objet de notre stage de fin d’études d’Ingénieur Informatique. 14 logiciels ont été ainsi évalués fonctionnellement et classifiés. 3 d’entre eux ont été retenus pour une évaluation détaillée, basée sur la mise en œuvre d’un jeu d’essai, faisant l’objet d’un prototype. Sur la base de ce travail, nous pouvons ainsi dresser un état des lieux de la gestion de contenu et choisir un CMS adapté aux besoins des utilisateurs.

1. Classification des systèmes de gestion de conten u L’objectif de cette classification est de déterminer quelles sont les fonctionnalités attachées à chaque domaine d’application de la gestion de contenu. De cette manière, il est ensuite possible de caractériser les applications logicielles en les classant comme opérant dans un ou plusieurs domaines à partir des fonctionnalités qu’ils proposent. Cette classification peut ensuite permettre de rapprocher rapidement les besoins des utilisateurs des applications y répondant en utilisant l’intermédiaire des domaines d’application. Une analyse détaillée point par point est ensuite nécessaire pour établir la correspondance définitive entre un outil logiciel éditeur, ses fonctionnalités et les besoins des utilisateurs. Les fonctionnalités de base sont, elles aussi, abordées dans ce chapitre. Enfin, l’étude des fonctionnalités détaillées des logiciels de gestion de contenu permet aussi leur évaluation détaillée. C’est l’objet du chapitre 272 de cette deuxième partie de ce rapport. Notons aussi que l’étude des fonctionnalités en vue de la classification des applications de gestion de contenu permet aussi une comparaison des logiciels, et finalement de les choisir sur la base la plus rationnelle possible en vue de leur utilisation. Cet exercice a aussi comme objectif de résoudre l’ambiguïté qui existe à propos de la gestion de contenu, domaine récent dans le cas de la gestion de site web, qui recouvre en fait plusieurs types d’application. Cette ambiguïté, tant au niveau du vocabulaire employé par les acteurs du domaine que des concepts manipulés73, est anhilée par la description des fonctionnalités et des domaines de la gestion de contenu. La grande diversité, en matière de systèmes de gestion de contenu, est liée actuellement à la grande diversité des formats de contenus gérés en informatique (cf. 1.7 page 16).

72 Lorsqu’une référence de la partie B peut paraître ambiguë, elle s’applique par défaut à une section de la même partie. Dans le cas contraire, elle est normalement précisée (référence de page ou de la partie du rapport). 73 Face à la popularité actuelle du concept de gestion de contenu, les éditeurs de logiciel tentent d’accroître leur clientèle par de simples effets d’annonce.

64

1.1. Domaines d’application

1.1.1. Introduction Tout d’abord, les domaines d’application ont déjà été abordés de manière informelle dans le chapitre 1 de la partie A de ce rapport, intitulé «Cas d’utilisations ». Nous ne pourrons donc pas éviter un certain nombre de redondance. Il nous faut cependant tenter de définir la manière dont un domaine doit être abordé pour être caractérisé. Nous avons retenu un certain nombre de critères (nom, définition, domaines d’application secondaire, fonctionnalités transverses, méthodes et modèles associés, normes associées, logiciels typiques évalués ou aperçus, Informations cibles, clients typiques, projets phares, organisations phares - institutions) qui sont ceux qui ont été retenus lors de notre étude préliminaire (cf. section « CONTEXTE, OBJECTIFS ET APPROCHE » p 4). Ce sont ces éléments que nous allons maintenant aborder. Les informations recueillies pour chaque critère sont partielles, ne peuvent prétendre à l’exhaustivité et sont données à titre d’exemples afin d’approcher la couverture de chaque domaine et leur donner une consistance. D’autres exemples pourraient donc certainement compléter notre approche. Les frontières de chaque domaine ne sont pas non plus nécessairement figées et donnent lieu à des interprétations divergentes en fonction du contexte dans lequel se place l’utilisateur. Notamment les fonctionnalités transverses sont des fonctionnalités que l’on retrouve dans plusieurs domaines de la gestion de contenu mais aussi dans d’autres domaines informatiques. Nous les avons retenues comme s’appliquant principalement à un domaine selon qu’elles aient été initialement conçues dans le domaine, qu’elles y soient utilisées massivement voir selon qu’elles soient obligatoires pour pouvoir caractériser le domaine. Toutefois, ces fonctionnalités transverses apparaissent bien comme autonomes dans la section 1.1.3 relative aux sous-domaines. Cela est vrai aussi pour notre approche d’autres critères comme les méthodes et modèles associés. Notre approche des domaines est d’abord fonctionnelle, notamment d’un point de vue informatique, mais elle est aussi sociologique et économique (institutions, projet phare, client typique, logiciels typiques). Afin de rendre l’information plus synthétique, nous présentons les informations du domaine sous forme de tableau. Nous pourrions nommer les sous-domaines « modules ». Nous aurions alors une approche de l’architecture fonctionnelle des systèmes de gestion de contenu de type « domaine / module / fonctions » (DMF). Notre approche n’est cependant pas aussi rigoureuse. Les sous-domaines pourraient aussi être assimilés à des domaines et les fonctionnalités à des modules ; car en fait, derrière les fonctionnalités que nous présentons, certaines sont suffisamment générales pour comprendre concrètement tout un ensemble de fonctions. Notre approche est donc une approche fonctionnelle à quatre niveaux, avec un recoupement possible des niveaux (les domaines et sous-domaines) et une description formelle du dernier niveau (les fonctions) peu détaillée ou développée. Il s’agit donc d’une approche pragmatique dont l’objectif est d’être suffisamment synthétique pour pouvoir être appréhendée. Elle présente aussi l’avantage de rendre comparable des logiciels éditeurs de gestion de contenu qui affichent des fonctionnalités dans leur présentation en cachant toutefois les détails précis de mise en oeuvre. Les fonctionnalités permettant de caractériser et classifier les systèmes de gestion de contenu présentées ci-dessous sont au nombre de 80 fonctionnalités environ. La section 1.1, outre cette introduction, présente donc les domaines d’applications de la gestion de contenu, les diverses fonctionnalités de la gestion de contenu et enfin offre en guise de conclusion une proposition de grille de classification des logiciels de gestion de contenu par domaine d’application.

65

1.1.2. Domaines Les domaines principaux de la gestion de contenu que nous avons abordés sont la GED, la gestion de contenu à proprement parler, la gestion de site web et les portails d’entreprises. Sont aussi présentés dans cette section la gestion des bibliothèques physiques ainsi que la gestion de la connaissance (knowledge management – KM) pour leur possibilité de valorisation et d’intégration potentielle aux autres systèmes de gestion de contenu. Cependant, ce ne sont pas là véritablement des systèmes de gestion de contenu électronique pris en compte par notre étude (cf. « INTRODUCTION » page 2) et nous ne présenterons pas leurs fonctionnalités spécifiques. Notons aussi que les logiciels de commerce électronique, à travers leurs outils de gestion des catalogues de produits peuvent aussi être intégrables aux systèmes de gestion de contenu. De même, la gestion de configurations (logicielles) utilise de multiples fonctionnalités utilisées aussi en gestion de contenu (authoring, versioning, groupware, gestion des méta données et du référentiel – cf. section 3.2.2 partie A). Si l’on imagine par la suite de permettre la recherche et la récupération, et éventuellement de vendre74, les composants logiciels ou documentaires, on effectue ainsi une boucle vertueuse valorisant le Web. Mais il s’agit là d’une digression par rapport à notre travail.

1.1.2.1. Gestion électronique de la documentation (GED)

Domaine d'application principal Gestion électronique de documentation (GED) Domaine d'application secondaire LAD : Lecture Automatique de Document ; COLD : Computer

Output on Laser Disc; O.C.R : Optical Character Recognition, archivage électronique, systemes de stockages électroniques, DAM : Digital Asset Management.

Fonctionnalités transverses Groupware (travail collaboratif), authoring, versioning, gestion de la propriété intellectuelle, modèle(s) de sécurités (droits d'accès).

Méthodes et modèles associés Document Management Reference Model, DMA - Document Management Alliance Specifications, Access Control Lists (ACL), webDAV

Normes associées NF Z 42-013 et ISO 15489-1 Logiciels typiques évalués ou aperçus

IBM Content manager server v8 (Lotus Domino.doc), Microsoft SPPS, FileNet (Panagon)

Informations cibles Fichiers informatiques et méta données associées Clients typiques Auteurs - rédacteurs, producteur de documents notamment

techniques (manuels utilisation, livrables projets...), secteur de l'édition - presse, livres, services juridiques et commerciaux (contrats), notaires, archivistes, banques, assurances

Projets phares FILLER Organisations phares - Institutions AIIM, Aproged Définition Organisation des fichiers informatiques (gestion de fichiers),

numérisation, accès et stockage

1.1.2.2. Gestion de contenu : Content Management Systems (CMS)

Domaine d'application principal Gestion de contenu : Content Management Systems (CM S) Domaine d'application secondaire Gestion de documents semi-structurés et / ou modulaires,

enrichissement de l'information : méta données, classifications (taxonomies, catégorisation, ontologies), séparation du contenu et de la présentation, gestion de la documentation technique (GEDT), gestion de configuration logicielle

Fonctionnalités transverses Syndication, indexation des données, réutilisation, systèmes d'alerte (abonnement)

74 Ou tout simplement de distribuer

66

Domaine d'application principal Gestion de contenu : Content Management Systems (CM S) Méthodes et modèles associés XML (SGML), Digital Object Identifier, DOM, RDF (Resource

Description Framework), RSS (RDF Site Summary), Traitement Automatique des Langues (TAL), URI (Unified Resource Identifiers), Unified Content Strategy

Normes associées Logiciels typiques évalués ou aperçus

IBM Content manager server v8 (Lotus Domino.doc), Documentum

Informations cibles Objets de contenu (sous-niveau de document ou encore composant de document), fichiers informatiques et données relationnelles

Clients typiques Editeurs, presse, industriels avec produits complexes, développement logiciel - Gestion des documents volumineux

Projets phares Organisations phares - Institutions World Wide Web Consortium – W3C Définition Organisation, accès et édition de l'information non ou semi-

structurée en composants discrets ou encore atomiques

1.1.2.3. Gestion de sites web : Web Content Management (WCM)

Domaine d'application principal Gestion de sites web : Web Content Management (WCM) Domaine d'application secondaire Staging, publication automatique de contenu, systèmes d'alerte Fonctionnalités transverses Publication multi-canal Méthodes et modèles associés XML (HTML) Normes associées Logiciels typiques évalués ou aperçus

Microsoft Content Management Server, IBM Content manager server v8, Documentum, Stellent, Interwoven

Informations cibles Liens hypermédias, objets de contenu Clients typiques Entreprise avec des sites web multiples et/ou volumineux,

contributeurs multiples et nombreux Projets phares FILLER Organisations phares - Institutions World Wide Web Consortium – W3C Définition Contrôle de la publication des composants documentaires au

niveau de l'utilisateur final, notamment les clients navigateurs Internet

1.1.2.4. Portail d'Entreprise : Entreprise Information Portal (EIP)

Domaine d'application principal Portail d'Entreprise : Entreprise Information Porta l (EIP) Domaine d'application secondaire Business Intelligence - DataWareHouse, moteurs de recherche

(traitement du langage naturel) Fonctionnalités transverses Personnalisation, fédération de contenus, gestion de la relation

client (U-CRM), forums de discussions, listes de diffusion Méthodes et modèles associés CWM (Commun Warehouse Metamodel) de l'OMG (Object

Management Group) Normes associées Logiciels typiques évalués ou aperçus

Microsoft SPPS, IBM Information Enterprise Portal, Zope, Tridion

Informations cibles Tous les formats Clients typiques Grande entreprise, administrations, services communautaires,

services de conseil et de veille technologique Projets phares FILLER Organisations phares - Institutions Editeurs logiciels : offres commerciales et cabinets consultants Définition Regroupement de l'information de tout type dans une même

application - intégration de l'information interne et externe à l'entreprise en fonction de l'utilisateur ou qu'il soit, quel que soit

67

Domaine d'application principal Portail d'Entreprise : Entreprise Information Porta l (EIP) son terminal, à n'importe quel moment

1.1.2.5. Gestion de la connaissance (KM)

Domaine d'application principal Gestion de la connaissance : Knowledge Management

(KM) Domaine d'application secondaire Systèmes à base de connaissances; modélisation de

connaissances, d'expertise, de processus; production, acquisition, diffusion de connaissances ; gestion des compétences, eLearning, OnLine Communitiy, mémoires organisationnelles (organisational memories), découverte de connaissance

Fonctionnalités transverses Web sémantique, récupération d'informations avancée Méthodes et modèles associés REX (acronyme de Retour d’EXpérience), KADS (Knowledge

Acquisition and Design System), MKSM (Methodology for Knowledge System Management) = MASK (Method for Analysing and Structuring Knowledge), CBR (Case Based Reasoning), Ontology Inference Layer (OIL), Knowledge Interchange Format (KIF), DIPA Model (Diagnostic, Interpretation, Proposition, Approval)

Normes associées ISO 17024 (Certification de compétences), ISO 13250: Topic Maps, UDC (Universal Decimal Classification)

Logiciels typiques évalués ou aperçus

InstraNet, Microsoft SPPS, IBM Information Enterprise Portal

Informations cibles Ontologies (taxonomies, classifications), diagrammes, objets de contenu, fichiers informatiques

Clients typiques Organismes de formation professionnelle, services du personnel (DRH), services communautaires, services qualité, services de conseil et de veille technologique

Projets phares ESPRIT, IMS Global Learning Consortium (EDUCAUSE) Organisations phares - Institutions Gouvernements, OCDE, Communauté européenne, UDC

(Universal Decimal Classification) : classification multilingue de la connaissance

Définition Structuration des savoirs de l'entreprise (outils, méthodes, processus) en vue de leur partage, de leur utilisation et de leur réutilisation dans les processus d'amélioration (qualité) et d'innovation.

1.1.2.6. Systèmes intégrés de gestion de bibliothèques physiques (SIGB)

Domaine d'application principal systèmes intégrés d e gestion de bibliothèques Domaine d'application secondaire Gestion du catalogage et du prêt, interface de recherche pour

le public, importation de notices bibliographiques en UNIMARC/ISO 2709

Fonctionnalités transverses Outils de catalogage Méthodes et modèles associés CONSER : cooperative online serials, MARC : Machine

Readable Catalogue Normes associées UNIMARC/ISO 2709, ANSI Z39-50 Logiciels typiques évalués ou aperçus

FILLER

Informations cibles Livres format papier, documents papiers et méta données associées

Clients typiques Service de la documentation et des archives, bibliothèques Projets phares Dmoz (Open Directory Project - Definitive Catalog of the Web),

Catalogue en Ligne d'OCLC (ON LINE COMPUTER LIBRARY CENTER) : WorldCat, US Library of Congress, PROMETEUS

68

Domaine d'application principal systèmes intégrés d e gestion de bibliothèques Organisations phares - Institutions Comité français UNIMARC : format d'échange de données

d'archives des bibliothèques, Association des bibliothécaires de France - ABF, AMERICAN LIBRARY ASSOCIATION, International Federation of Library Associations and Institutions - IFLA, International Federation for Information and Documentation (IFID)

Définition Acquisition de documents (monographies et / ou périodiques) et mise à disposition des usagers

1.1.3. Fonctionnalités des sous-domaines Les sous-domaines de la gestion de contenu sont les suivants : authoring, versioning, groupware (et workflow), édition de documents, gestion des modèles de documents (template), gestion des méta données et des liens, transformation des composants documentaires (pour la publication), gestion automatisée de la publication, publication multi-canal, moteur de recherche et d’indexation, personnalisation. Ces sous-domaines fonctionnels ont été mentionnés comme domaine d’application secondaire ou comme fonctionnalité transverse dans la section ci-dessus. D’autres domaines sont aussi abordés, mais ne sont pas spécifiques de la gestion de contenu et plutôt des applications informatiques en général. Elles sont cependant indispensables à la gestion de contenu. Il s’agit de l’administration, de la sécurité, de la gestion des utilisateurs, de l’échange de données (import / export) et de l’internationalisation du logiciel (support multilingue et localisation de l’interface dans la langue de l’utilisateur). Ces fonctionnalités ont généralement été abordées, décrites et / ou illustrées, soit plus ou moins développées, tout au long de la première partie (section 2 « Concepts de gestion de contenu » et section 3 « Architecture d’un système de gestion de contenu ») de ce rapport dans les différentes sections concernées, ceci de manière plutôt théorique et à des fins didactiques. Elles sont ici listées de manière exhaustive et brièvement décrites, de manière pratique et afin de classifier et comparer les CMS offerts par les éditeurs de logiciels du marché ou encore afin de juger de la richesse de leur offre et d’en réaliser l’évaluation détaillée (section 2 page 79). Nous avons considéré les fonctionnalités présentées ici parce qu’elles sont, entre autres, mises en avant par les éditeurs de logiciels de gestion de contenu comme faisant parties de leur système [21] [67] [68] [69].[70] [20] [71] [72] [73] [74] [75] [76] [77]. Un exemple de classification à partir des fonctionnalités listées dans les sous-paragraphes suivants est repris dans le Tableau 2 intitulé « : comparatif et récapitulatif des fonctionnalités déclarées des logiciels Interwoven ECM, MS SharePoint et SPIP » page 75.

1.1.3.1. Versioning

Les fonctionnalités principales en sont les suivantes : - Gestion des versions (historisation) - Gestion de configuration et du code applicatif du site web - Gestion des conflits de versions en mise à jour et comparaison de versions La gestion des versions des composants documentaires doit permettre globalement de faire référence à un document de manière générique et de récupérer sa dernière version ou alors, lorsque le logiciel le permet, de faire référence à une de ses versions et, de même, le récupérer. L’historisation des versions permet au CMS de garder actives et d’accéder aux différentes versions des documents. La gestion des versions est particulièrement importante lorsque plusieurs versions d’un composant documentaire sont valides simultanément (cf. « date » et « Valid » dans le tableau 5 : « méta données de l’initiative de Dublin Core » page 109) ; par exemple, lorsque plusieurs versions d’un même produit associé à la documentation sont toujours utilisées, ou encore, lorsqu’une loi s’applique sans effet rétroactif…

69

Enfin, et particulièrement dans le cadre de la gestion de code informatique, la comparaison des versions des documents et les outils de fusion (gestion des conflits de mise à jour en édition distribuée et des versions concurrentes) qui les accompagnent sont des outils complémentaires importants du versioning. Nous sommes là à la croisée du versioning et de l’édition des documents (cf. section 1.1.3.4).

1.1.3.2. Authoring

Les fonctionnalités que nous classons dans ce sous-domaine sont les suivantes : - authentification (authentification à base de certificat), - gestion des droits numériques (ou droits d’auteur) : Digital Rights Management (DRM). L’authoring est ce qui est partagé par une grande majorité d’applications informatiques et tous les domaines de la gestion de contenu. Il s’agit de permettre la gestion des droits d’accès dans un premier temps, et notamment les droits en écriture. Cela doit permettre ensuite d’enregistrer et d’associer le ou les auteurs au document. Cela passe par l’authentification, notamment en relation avec le système d’exploitation, en se basant sur les informations de login (identifiant utilisateur et mot de passe). L’authoring est aussi ce qui permet à des utilisateurs, informaticiens ou non, de créer et mettre à jour des documents. Nous n’abordons pas cet aspect là de l’authoring, qui est repris partiellement dans la section 1.1.3.4 « Application d'édition de documents intégrée ». Une gestion avancée de l’authoring met en œuvre des mécanismes de sécurité et d’authentification. Une des plus répandue actuellement, parce qu’aussi associée à l’encryption (cf. section 1.1.3.11), est l’authentification à base de certificat numérique. Comme autre utilisation avancée de l’authoring, nous retrouvons la gestion des droits d’auteurs (DRM). Cela concerne principalement aujourd’hui le DAM (cf. section 1.1.2.1).

1.1.3.3. Groupware (Workflow)

Le groupware est un domaine transversal à part entière. C’est un ensemble de programmes qui permet le travail de groupe, ou encore travail collaboratif. Une des composantes principales du groupware est le workflow. Il est indispensable à la gestion des processus d’affaire (Business Process Management – BPM). Les chaînes d’édition numérique étant une sous-catégorie des processus d’affaire, il doit être aussi largement utilisé dans la gestion de contenu et ses domaines d’application (GED, CMS, WCM et EIP). Les caractéristiques ou fonctionnalités du groupware sont les suivantes : - mise en oeuvre de workflow prédéfini(s), - mise en oeuvre de workflow paramétrable(s), - Workflow avancé : Parallélisation des flux, - gestion des transactions (verrouillage), - héritage des modèles de sécurité et workflow par type de document, - automatisation (envoi de message eMail pour intervention ou pour rappel d’intervention), - outil d'annotation, - forums de discussion, liste de diffusion, - administration distribuée utilisateurs/groupes/projets, - gestion de projets. Les CMS offrent plus ou moins de souplesse et de richesse pour gérer les workflows, d’où un nombre de fonctionnalité relativement élevé pour les discriminer. Les workflows proposés peuvent être uniquement prédéfinis. Dans d’autres cas, on peut les paramétrer pour les adapter aux besoins spécifiques des utilisateurs. De même, ce paramétrage peut être plus ou moins riche et permettre ou non de spécifier des flux parallèles. Normalement, les workflows sont assortis d’une gestion des transactions avec verrouillage des ressources en cours d’édition (souvent dénommée « checkin / checkout »). Cependant, certains logiciels ne le gèrent pas.

70

Ce paramétrage peut être aussi plus ou moins souple. Les workflows peuvent s’appliquer aux groupes de travail uniquement ou alors être spécifiques à chaque type de document dans un même groupe de travail. Dans ce dernier cas, le modèle de sécurité et de workflow, est hérité ou non du groupe de travail dans lequel le type de document peut être édité, facilitant ou non la tâche de paramétrage. De plus, le paramétrage peut être opéré sous la supervision unique d’un administrateur de l’application de CMS ou délégué par responsable de groupe de travail. Cette possibilité de déléguer une partie de l’administration des groupes de travail n’est pas superflue dans les applications gérant de nombreux types de document. Ensuite, un des principaux avantages de la gestion des processus de travail est de pouvoir automatiser certaines tâches dévolues autrement aux utilisateurs. La notification par email de l’accomplissement d’une phase dans un workflow aux utilisateurs suivants dans la chaîne d’édition fait partie de ces avantages dans certains logiciels de CMS. Enfin, d’autres outils de groupware peuvent être utiles dans le cadre de la gestion de contenu. Il s’agit de la possibilité d’annoter des documents dans le cadre de leur édition ou encore d’offrir des forums de discussion pour les groupes de travail. Certains considèrent les fonctionnalités de gestion des groupes de travail comme relevant du domaine de la gestion de projet. D’autres outils de gestion de projet (agendas principalement) sont parfois offerts dans les suites de gestion de contenu, sans jamais être suffisamment complets pour que la fonctionnalité mérite d’être appelée application de gestion de projet. L’intégration est cependant dans certains cas d’utilisation tentante.

1.1.3.4. Application d'édition de documents intégrée

Les applications d’édition intégrée aux CMS peuvent être les suivantes : - éditeur XML, - éditeur HTML, - applications compatibles ODMA (Open Document Management API - voir page 20), - édition distribuée (Interface web -client navigateur ou autre application cliente). Certains logiciels de CMS proposent leurs propres applications d’édition de documents alors que d’autres se limitent à la mise en œuvre du mécanisme de checkin / checkout (gestion des transactions) lors de l’édition des fichiers. Si les CMS sont compatibles avec l’édition de documents structurés (et la prise en compte du type de document), ils proposent généralement un éditeur XML, celui ci étant toutefois souvent limité à la mise en œuvre d’un formulaire HTML pour saisir les différents composants d’un document. Certains CMS proposent, pour s’adapter à la popularité des applications de bureautique de Microsoft, des éditeurs compatibles ODMA. Dans le même ordre d’idée, certaines applications de WCM proposent des éditeurs HTML pour générer du contenu qui est ensuite publié uniquement sur le Web. Enfin, les CMS proposent le plus souvent une interface Web pour accéder à l’application de gestion de contenu, et notamment l’édition. Cependant, il y a encore des CMS qui nécessitent l’installation de clients spécifiques sur le poste de travail de l’utilisateur. D’autres encore proposent les deux configurations.

1.1.3.5. Gestion des méta données

On aborde ici les fonctionnalités qui sont au cœur de la gestion de contenu. Mais il faut cependant dire que la gestion des méta données est plus ou moins développée selon les logiciels, voir dans certains cas quasiment absente, et sinon jamais complète. Les éléments des CMS permettant la prise en compte des méta données sont les suivants : - type de document, - conteneur multimédia, - catégorisation (simple ou multiple), - utilisation de thésaurus / dictionnaire,

71

- extraction automatique de méta données, - catégorisation automatique des documents, - fonction de résumé automatique de document, - support de création et maintenance de catalogues (dictionnaires, taxonomies, thésaurus, ontologies), - gestion des liens interne, - gestion des liens hypertextes. Certaines applications de gestion de contenu, limitée donc, ne permettent pas de prendre en compte la notion de type de document, soit pour pouvoir y appliquer un modèle de document (cf. section 1.1.3.4), soit pour pouvoir y associer des méta données spécifiques. Le conteneur multimédia n’est qu’une adaptation spécifique des méta données à la gestion des documents multimédia (images, sons, vidéos…). Un des points clés de la mise en œuvre des méta données est la possibilité que les CMS offrent de classer les ressources documentaires dans des schémas de catégories. Cela peut être un ou plusieurs schémas selon les cas. Ces schémas peuvent ou non être reliés à l’utilisation de dictionnaires, thésaurus ou autres taxonomies, tout comme les autres méta données qui peuvent alors ou non prendre aussi leurs valeurs dans des dictionnaires afin de contrôler le vocabulaire utilisé. Les CMS peuvent aussi proposer des outils de productivité pour renseigner les méta données en automatisant la génération de leurs valeurs, ou tout du moins en assistant l’utilisateur dans leur renseignement : il s’agit de l’extraction automatique de méta données, de la catégorisation automatique des documents et enfin parfois de la fonction de résumé automatique des textes. Finalement, vu l’importance qu’ont les méta données dans la gestion de contenu, les CMS peuvent proposer des outils de création et de maintenance des ontologies utilisées. Enfin dans le même domaine, mais sur un autre plan, la gestion des références entre documents est cruciale. Il s’agit de la gestion des références internes ou externes (liens hypertextes). Cependant, malheureusement, cette gestion est parfois laissée au soin unique des utilisateurs. Certains logiciels de WCM ne proposent même pas de validation des liens hypertextes !

1.1.3.6. Transformation

Après avoir vu jusqu’ici dans cette section concernant les fonctionnalités des CMS, les fonctionnalités nécessaires à l’édition des documents (collecte), voyons à partir de maintenant plutôt les fonctionnalités relatives à la publication et plus loin l’administration. Les fonctionnalités de transformation sont celles qui permettent de générer les documents édités au format de publication. Les éléments clés de ces fonctionnalités sont : - les templates, - les transformations de formats spécifiques, - les formats de fichiers de sortie supportés par défaut. L’utilisation des templates est déjà prise en compte pour les applications de gestion de contenu proposant des éditeurs XML (cf. section 1.1.3.4). Elle est indispensable pour les applications de WCM afin de gérer la mise en forme graphique des documents et de séparer la présentation du contenu. Elle est aussi indispensable pour générer des documents aux formats multiples dans le cadre de la publication multi-canal. Il peut y avoir des outils de transformation ad hoc permettant de passer d’un format de publication à un autre, sans forcément passer par un pivot unique, spécifié avec le template (par exemple, d’un format MS Word à un format PDF). Enfin les suites de gestion de contenu permettent de générer des fichiers dans des formats de sortie plus ou moins nombreux.

72

1.1.3.7. Gestion automatisée de la publication

La gestion automatisée de la publication est surtout liée au domaine de la gestion de site web (WCM). Mais elle n’en est pas exclusive, notamment pour ce qui concerne l’archivage, qui là, est une fonctionnalité plus développée dans la GED. La syndication et la fédération relèvent eux plus de la problématique des portails (EIP). Les éléments fonctionnels de la publication automatique des documents sont : - conversion automatique de document / de contenu, - date de parution et / ou date d'expiration, - archivage, - staging, - syndication, - fédération de contenu. La conversion automatique de contenu est consécutive à la mise en œuvre des templates. A chaque appel d’un client, la publication peut être générée dynamiquement à partir du contenu actualisé et en fonction des fichiers de transformation. Dans le cadre de la gestion automatisée de la publication, notamment associée aux workflows d’édition, des documents validés peuvent être publiés à une date prédéterminée si le CMS le permet. De la même manière, un document peut être retiré de la publication en fonction de sa validité ou de la date d’expiration qui aura été spécifiée, soit en fonction d’une règle, soit d’un paramétrage particulier. A ce moment là, on peut imaginer que le CMS gère aussi l’archivage du document de manière automatisée. Certains systèmes de GED le proposent. Le staging est une fonctionnalité propre au WCM et en fait peut s’assimiler à la mise en œuvre d’une plate-forme d’intégration, élément commun d’une informatique professionnelle d’entreprise (voir « staging » page 14). Pour finir, la syndication de contenu, et sa réciproque, la fédération, consiste à générer des fichiers de syndication pour permettre à d’autres CMS de reprendre une partie du contenu du CMS d’origine. Certains logiciels proposent donc de générer des fichiers de syndication automatiquement et / ou de publier des informations syndiquées par d’autres CMS.

1.1.3.8. Publication multi-canal

La publication multi-canal, nécessite, en sus de la fonctionnalité de conversion automatique de contenu vue ci-dessus, des fonctionnalités complémentaires spécifiques du canal de diffusion et permettant la distribution sur les canaux et / ou dans les formats suivants : - télévision interactive diTV, - terminal WAP, - PDA, - serveur Web, - serveur de streaming audio-video, - distribution sur CDRom.

1.1.3.9. Moteurs de recherche et d'indexation

Voyons encore d’autres sous-domaines des systèmes de publication, et en particulier ici les fonctionnalités que peuvent offrir les moteurs de recherche. Il s’agit de : - la recherche « plein texte », - la lemmatisation, - la recherche sémantique : gestion de règles d’expansion, - la recherche sur les attributs de méta données, - la recherche hiérarchique, - la recherche sur attributs / éléments XML, - autre(s) système(s) de raffinement des résultats,

73

- la recherche fédérée (sur plusieurs sources de contenu) / Webcrawling, - Recherche fédérée : intranet, extranet, web, - Recherche fédérée : bases de données relationnelles, - Recherche fédérée : systèmes de fichier, - Recherche fédérée : eMail,

- formats de fichiers supportés pour l'indexation. Les fonctionnalités offertes par les moteurs de recherche intégrés aux CMS varient en fonction de la richesse fonctionnelle des CMS. Cela va de la recherche basée sur une indexation « plein texte » des documents, jusqu’à une exploitation intensive des méta données, en particulier les catégories dans la recherche hiérarchique, voir les attributs ou élément (XML) des composants documentaires. Les recherches peuvent être améliorées grâce à la lemmatisation, appuyées aussi par la gestion des règles d’expansion. Par ailleurs, les capacités des moteurs de recherche sont liées aussi aux formats de fichiers qu’ils sont capables d’indexer dans le cas de la recherche « plein texte ». Certains ne peuvent indexer que des ressources au format texte alors que d’autres peuvent traiter des fichiers aux formats plus « propriétaires » (MS Word par exemple). Ces capacités sont aussi liées aux systèmes de stockage des composants documentaires qui peuvent être indexés. Les moteurs les plus riches peuvent permettre d’interroger des ressources dans des systèmes variés (du serveur Web à la base de courrier électronique en passant par la base de donnée).

1.1.3.10. Personnalisation

Autre domaine de la gestion de contenu lié au système de publication, la personnalisation peut donner lieu là encore à un nombre de fonctionnalités non négligeables. Parmi celle-ci, nous trouvons : - la gestion des abonnements (subscription), - la gestion des droits d'accès sur le(s) site(s) de publication, - le suivi des accès aux documents, - des API de personnalisation, - la gestion des préférences utilisateurs, - le profiling (catégorisation des utilisateurs). Pour avoir un aperçu de ces fonctionnalités, nous pouvons nous référer à la section 3.3.3 page 58 traitant de la personnalisation.

1.1.3.11. Administration, gestion des utilisateurs et sécurité, export / Import de données, internationalisation

Les fonctionnalités qui vont suivre ont plus trait au domaine de l’administration générale des CMS. Elles sont discriminantes dans le choix d’un CMS mais pas dans notre classification. Un CMS peut offrir : - la connexion aux annuaires LDAP afin de gérer les utilisateurs du système, - une base interne des utilisateurs, - la gestion SSL, - l’encryption à base de certificat. - l’import de données, - l’export de données, - le support de multiples encodages (unicode), - le support multilingue, - la localisation (version française) de l’application.

1.1.4. Conclusion Nous pouvons donc maintenant retenir une grille de classification générale des outils de gestion de contenu par domaine en fonction des sous-domaine fonctionnels qu’ils prennent en compte.

74

Tableau 1 : Fonctionnalités principales des domaine s de la gestion de contenu

GED CMS WCM EIP

Versioning X Authoring X X X X Workflow X X X X Edition de documents X X Gestion des méta données X X Transformation X X X Publication automatisée X X Publication multi-canal (X) (X) Moteur de recherche X Personnalisation X

Toutefois, certaines fonctionnalités de base peuvent amener éventuellement à classer certains outils dans un domaine, même si celui ci n’est pas couvert intégralement. Notamment, la GED est ici une GED que nous pourrions qualifier de « GED légère », car nous ne prenons pas en compte les fonctionnalités de la GED « lourde » que sont les techniques de numérisation et d’archivage (LAD, OCR, COLD, gestionnaire de spool). Il nous est désormais possible de classifier les outils de gestion de contenu que l’on peut rencontrer sur le marché, ce que nous allons faire dans la section ci-dessous.

1.2. Méthode de classification Comme nous l’avons déjà mentionné en introduction (page 63 en chapeau de la section 1), le but de cet exercice est de rapprocher en fin de compte les exigences (besoins) des utilisateurs de l’offre d’un logiciel de gestion de contenu afin d’en évaluer l’adéquation, ceci de manière simple. C’est une démarche très pratique qui passe d’abord par l’enregistrement des fonctionnalités déclarées dans la documentation de l’éditeur de CMS, puis par le classement de l’outil. Nous verrons dans un troisième temps des exemples pour illustrer cela. Ces exemples sont issus du travail réalisé au cour de la mission sur laquelle est basé ce rapport.

1.2.1. Enregistrement des fonctionnalités déclarées et classement La méthode consiste dans un premier temps à récupérer les informations de l’éditeur de logiciel de gestion de contenu et à les enregistrer. Cet enregistrement des fonctionnalités déclarées des logiciels permet de voir quels sont les sous-domaines fonctionnels couverts par le logiciel. Dans un deuxième temps, les sous-domaines fonctionnels déterminés comme couverts sont comparés à ceux nécessaires aux applications d’un domaine de la gestion de contenu (c’est à dire GED, CMS, WCM et EIP). 1. Ces informations se trouvent classiquement dans les brochures commerciales présentant les produits. Dans ce cas, les informations sont souvent succinctes. Cependant, très souvent, on trouve plus d’informations sur les produits dans des livres blancs qui abordent de manière plus développée les avantages et les inconvénients d’un produit. Ce sont souvent des présentations techniques. Dans d’autres cas, les documents sont plus explicites et portent le titre de « caractéristiques (« features ») du logiciel » ou encore mentionnent le terme « fonctionnalités » dans leur titre. Tout document permettant d’obtenir une description du logiciel de CMS est utile afin d’en découvrir les fonctionnalités. Si le logiciel fait l’objet d’une attention plus précise, d’autres informations doivent être récupérées afin des les recouper. Il est alors nécessaire de fouiller le site web du produit logiciel, voir de prendre contact avec des représentants de l’éditeur.

75

A chaque fois qu’une fonctionnalité est déclarée comme étant mise en œuvre par le logiciel, il s’agit de l’enregistrer dans un tableau récapitulatif. Ce tableau récapitulatif peut être repris dans un tableau comparatif lorsque plusieurs logiciels sont étudiés, comme cela a été le cas lors de l’étude. Les fonctionnalités à renseigner sont celles qui ont été mentionnées dans la section 1.1.3. Il y a une certaine difficulté à faire ce travail, lorsque l’éditeur logiciel propose plusieurs produits de gestion de contenu ; en fait, un produit relatif à un ou deux domaines de la gestion de contenu. Ces logiciels sont souvent prévus pour pouvoir être intégrés ensemble et présentent alors des caractéristiques supplémentaires. La solution consiste à ne traiter les informations ne concernant le logiciel que lorsqu’il est mis en œuvre séparément. L’intégration de deux logiciels d’un même constructeur doit être considérée comme un produit spécifique et à analyser à part entière. 2. Le classement est ensuite une opération triviale. Il consiste simplement à se référer au Tableau 1 : Fonctionnalités principales des domaines de la gestion de contenu » et voir s’il s’agit d’une application de GED, de CMS, de WCM ou de EIP, ou bien encore d’une combinaison de ces applications, ceci sur la base des sous-domaines fonctionnels enregistrés comme traités par le logiciel. Voyons quelques exemples pour illustrer la méthode de classification que nous avons retenue.

1.2.2. Exemples Les exemples que nous allons voir concernent les logiciels de gestion de contenu qui font aussi l’objet de notre évaluation détaillée (section 2). Il s’agit des logiciels suivants : la suite « Enterprise Content Management » [78] [52] d’Interwoven, le logiciel « SharePoint Portal Server » de Microsoft [79] et « SPIP » (Système de Publication pour l’Internet) [80], un logiciel avec une licence GPL75. 1. Voyons tout d’abord simplement un tableau comparatif et récapitulatif des fonctionnalités déclarées des logiciels.

Tableau 2 : comparatif et récapitulatif des fonctio nnalités déclarées des logiciels Interwoven ECM, MS SharePoint et SPIP

Fonctionnalités Microsoft

Share Point Portal Server

Interwoven - ECM SPIP

Versioning X X Gestion des versions (historisation) X X Gestion des conflits de versions en mise à jour X Authoring X X X Authentification login X X X Authentification à base de certificat X Digital Rights Management Groupware (Workflow) X X X Workflow prédéfini(s) X X X Workflow paramétrable(s) Edition distribuée X X Parallélisation des flux X Gestion des transactions (verrouillage) X X Héritage des modèles de sécurité et workflow par type de document X X

Automatisation : Envoi de message eMail pour intervention et rappel X X

Outil d'annotation X Gestion de projets

75 GPL : General Public Licence

76




Forums de discussion, liste de diffusion X X Administration distribuée utilisateurs/groupes/projets X X X

Gestion de projets Application d'édition de documents (XML, Word, …) intégrée X

Editeur XML X Editeur HTML Application compatible ODMA Interface web (client navigateur) X X X Autre application cliente X Gestion des méta données X X Type de document X X Conteneur multimédia X Catégorisation simple X X Catégorisation multiple X X Utilisation de thésaurus / dictionnaire X Extraction automatique de méta données X Catégorisation automatique des documents X X Fonction de résumé automatique de document X Support de création et maintenance de catalogues (taxonomies) X

gestion des liens interne gestion des liens hypertextes Transformation X X Templates X X Formats de fichiers de sortie / client universel X Html Publication automatisée X X X Conversion automatique de document / de contenu X X

Date de parution X X X Date d'expiration X Archivage Staging X Syndication X X Fédération de contenu X X Publication multi-canal Télévision interactive diTV WAP PDA Serveur Web X X X Serveur de streaming audio-video Distribution sur CDRom Moteurs de recherche et d'indexation

X X X

Outil de recherche X Inktomi X Recherche plein texte X X X Lemmatisation Recherche sémantique X Recherche sur les attributs de méta données X X Recherche hiérarchique X X Recherche sur attributs / éléments XML X Autre(s) système(s) de raffinement des résultats

77




Recherche fédérée (sur plusieurs sources de contenu) / Webcrawling X

Recherche fédérée : intranet, extranet, web X Recherche fédérée : bases de données relationnelles X

Recherche fédérée : systèmes de fichier X Windows NTFS, Oracle IFS

Recherche fédérée : eMail X Lotus Notes Recherche fédérée (sur plusieurs sources de contenu) / agrégation des résultats

(Software Development

Kit)

Formats de fichiers supportés pour l'indexation Microsoft Office, texte, Images

MS Office, texte, PDF Texte, Html

Personnalisation X X Gestion des abonnements (subscription) X X Gestion des droits d'accès sur le(s) site(s) de publication X X X

Suivi des accès aux documents X X API de personnalisation Gestion des préférences utilisateurs X Rédacteurs Profiling (personnalisation) Export / Import de données

X X X

Import X X X Export X X Internationalisation X X X Support du format Unicode X X Support multilingue X Localisation (version française) X X X Gestion des utilisateurs X X X Connexion à LDAP

Active Directory X X

Base utilisateur interne X Architecture Serveurs répartis X Serveurs centralisés X X Compatibilité Systèmes d'exploitation Windows NT Sun Solaris,

Windows NT Windows,

Unix Sécurité X X Gestion SSL X Encryption à base de certificat X

Le tableau ci-dessus donne une vision synthétique des fonctionnalités que propose chaque logiciel de gestion de contenu étudié et permet de voir quels sont les sous-domaines fonctionnels qu’il couvre. On peut donc désormais comparer les domaines fonctionnels couverts par les logiciels et ceux théoriquement couverts par les logiciels d’un domaine d’application de la gestion de contenu. 2. Nous pouvons donc classifier chaque logiciel étudié dans notre exemple. Faisons le explicitement dans un nouveau tableau. La première et les quatre dernières colonnes du tableau sont identiques à celles du Tableau 1 page 74 afin de faciliter la comparaison et la classification.

78

Tableau 3 : classification de logiciels de gestion de contenu Interwoven ECM, MS SPPS et SPIP

Sous-domaine fonctionnel

Interwoven - ECM

Microsoft Share Point

Portal Server

SPIP GED CMS WCM EIP

Versioning X X X Authoring X X X X X X X Workflow X X X X X X X Edition de documents X X X Gestion des méta données X X X X

Transformation X X X X X Publication automatisée X X X X X Publication multi-canal (X) (X) (X) Moteurs de recherche et d'indexation X X X X

Personnalisation X X X Classification GED, CMS,

WCM GED, EIP EIP

Nous constatons donc que Interwoven ECM est un logiciel de GED légère grâce à sa prise en compte du versioning, un logiciel de CMS grâce à ses fonctionnalités de gestion des méta données et de transformation, et enfin de WCM grâce à sa gestion de la publication automatisée. Interwoven propose donc une suite de gestion de contenu très complète, mais en fait, il s’agit de l’intégration de nombreux composants, dont on utilise qu’une partie afin d’adapter la suite au besoin réel de l’utilisateur. La suite complète correspond à une architecture très lourde. Nous n’avons utilisé que les deux composants de base (TeamSite et TeamSite Templating) pour l’évaluation détaillée du CMS d’Interwoven. Ils permettent seulement alors de ne faire véritablement que de la gestion de contenu (CMS) dans le but de la gestion de site Web (WCM). De son côté, Microsoft SharePoint Portal Server (SPPS) est un logiciel de GED légère et un EIP. Le fait qu’il ne soit pas un logiciel de CMS et de WCM vient du fait qu’il ne gère pas la transformation des composants documentaires. C’est à dire qu’en fait, MS SPPS ne permet pas la structuration des documents en composants. Microsoft, en 2002, propose un logiciel complémentaire pour ce faire. Il s’agit de MS « Content Management Server ». SPIP se situe comme un EIP uniquement, même s’il contribue largement à faire de la gestion de site web (WCM). En effet, nous avons considéré qu’il ne permet pas de faire de WCM car il ne propose (avec la version 1.5.2) qu’un seul type de document : l’article (composé de sept éléments) et ne permet pas d’éditer d’autre type de document structuré. De même, SPIP propose uniquement un seul type de méta données limité (mots clés et groupe de mots clés) permettant de gérer des catégories, aussi nous avons considéré qu’il ne propose pas de gestion des méta données. Cependant, pour l’article, SPIP propose bien une interface d’édition de document.

1.2.3. Conclusion Il est nécessaire d’étudier les fonctionnalités des systèmes de gestion de contenu proposés par les éditeurs de logiciel afin de pouvoir les comparer et les choisir, ainsi que pour pouvoir juger de l’adéquation entre l’offre fonctionnelle du logiciel et les besoins des utilisateurs, exprimés notamment dans les cahiers des charges et les offres de marché. En effet, la grande majorité des éditeurs de logiciels disent que leur produit fait de la gestion de contenu. Il faut savoir en fait quelle est réellement l’application de gestion de contenu en question. Cependant, le choix pour retenir un logiciel de gestion de contenu n’est pas uniquement basé sur ces considérations. L’architecture logicielle est un élément majeur qui détermine la sélection d’un système ou d’un autre. Il faut en effet que la compatibilité ou l’intégration du CMS soit nativement la plus grande possible avec l’architecture existante du système d’information de l’organisation utilisatrice.

79

Par exemple, Microsoft dispose de fait d’un avantage sur ses concurrents par le simple fait que de nombreuses organisations sont aujourd’hui équipées des systèmes d’exploitation Windows

�

, ou encore de la suite bureautique Office

�

qui s’intègre très facilement avec SharePoint Portal Server. Inversement, une entreprise équipée avec le système d’exploitation Unix se détournera dès le début de ce logiciel qui n’a pas de version compatible avec ce système d’exploitation. Dans de nombreux cas, il faudra envisager des développements informatiques complémentaires pour adapter le logiciel au besoin de l’entreprise car une couverture totale des besoins fonctionnels d’un utilisateur est très rare, notamment en terme d’intégration au système d’information. Le langage de développement fourni avec les API de l’éditeur est déterminant de la même manière. On pourra par exemple préférer un logiciel moins riche initialement, mais dont le langage de développement informatique fait partie des compétences que la société peut fournir. Enfin, autre élément non négligeable, voire le plus important, le coût d’un logiciel et de son infrastructure, fait peser la balance dans un sens ou l’autre dans de nombreux cas pour retenir définitivement un logiciel de CMS. Parmi les 1476 logiciels soumis, lors de notre étude, à l’analyse fonctionnelle que nous venons de décrire dans cette section, trois ont été retenus : Interwoven pour sa couverture fonctionnelle presque complète, Microsoft SharePoint pour sa popularité et son coût abordable et SPIP car il s’agit d’un logiciel gratuit à l’acquisition. Ces trois logiciels ont été mis en œuvre dans l’élaboration d’un prototype afin de juger de la possibilité de les inclure dans une offre de service et afin de contrôler le bon fonctionnement des fonctionnalités déclarées grâce à une évaluation détaillée. Ce sont ces derniers éléments qui font l’objet de la deuxième et dernière section de cette partie B du rapport. Cette démarche d’évaluation détaillée est aussi certainement positive lorsqu’il s’agit, pour un utilisateur, de choisir définitivement un logiciel dans une « short list » issue de la présélection que nous venons de décrire.

2. Evaluation détaillée L’évaluation détaillée que nous proposons dans la première sous-section de ce chapitre (section 2.1), repose en partie sur l’ensemble des notions générales (notamment les sous-domaines fonctionnels – cf. section 1.1.3 page 68) que nous avons abordées jusqu’à maintenant. Cependant, elle prend en compte largement aussi les aspects pratiques de la mise en œuvre du système de gestion de contenu dans une application concrète, aspects largement centrés sur l’utilisateur (installation, paramétrage, utilisation, intégration au système d’information). En effet, l’utilisateur est un élément clé de l’adoption d’un logiciel. La comparaison de plusieurs logiciels sur la base de leur évaluation détaillée peut s’effectuer grâce à la notation de type qualitatif, elle-même adossée sur les commentaires qui composent l’évaluation détaillée. L’application concrète des logiciels est réalisée grâce à un prototype qui correspond à un jeu d’essai qui tente de reproduire dans une certaine mesure un exemple d’application du monde réel tout en restant fictif. Trois logiciels de gestion de contenu (Interwoven TeamSite Templating 5.5.2 SP2, Microsoft SharePoint Portal Server 2001, SPIP 1.5.2) ont été confronté à la réalisation de cette application de gestion de contenu de manière à faire ressortir leurs avantages et leurs inconvénients respectifs, et finalement la couverture des besoins de l’organisation. Le fait de confronter chaque CMS à un même jeu d’essai permet une comparaison la plus objective possible. Ces derniers éléments (jeu d’essai, évaluation détaillée des logiciels mis en œuvre dans un prototype et couverture fonctionnelle) sont l’objet de la sous-section 2.2 de ce chapitre.

76 Broadvision One to One Suite, Documentum 4i eBusiness Plateform, IBM Content Manager Server - V8, IBM Information Enterprise Portal, InstraNet, Interwoven - ECM, Microsoft Content Management Server, Microsoft Share Point Portal Server, Ovidentia, Postnuke, SPIP, Stellent Content Manager, Stellent Content Publisher, Tridion, Vignette - V6 Content Suite, Xoops V1.3.8, Zope - Content Management Framework.

80

2.1. Grille d’évaluation

2.1.1. Critères Les critères que l’on a retenus pour l’évaluation détaillée de chaque logiciel de gestion de contenu sont les suivants. L’évaluation détaillée des logiciels soumis à l’étude préalable à la définition d’une offre de service en gestion de contenu, a été spécifiée dans le cahier des charges de l’étude [81]. Installation : - serveur ; - client ; - jeu d’exemples et tutoriaux ; - manuels utilisateurs (administration, développement, utilisation). Paramétrage : - utilisateurs, rôles et groupes de travail ; - workflows ; - type de document (structure) ; - méta données ; - éditions XML ; - éditions avec plugin ; - transformation pour la publication ; - développement et customisation ; - intégration (serveur de mail; serveur web, proxy, base de données, serveur d’application). Utilisation : - administration ; - récupération de documents existants (import) ; - édition de document : création ; - édition de document : mise à jour ; - édition méta données ; - publication ; - workflow ; - versioning ; - recherche de documents ; - interface graphique. Intégration : - intégration des documents dans le système de gestion de contenu lui-même ; - utilisation des composants documentaires stockés et intégration avec d’autres applications informatiques ; - migration vers l’application de gestion de contenu ; - migration de puis l’application de gestion de contenu vers une autre application.

2.1.2. Notation Tout d’abord, chaque produit évalué et prototypé a fait l’objet d’un commentaire détaillé pour chaque critère d’évaluation. Cela a permis d’aboutir à l’attribution d’une note sur 5 (0 = nul, 1 = insuffisant, 2 = médiocre, 3 = moyen, 4 = bon, 5 = excellent, avancé) qui a été elle-même reprise dans un tableau comparatif des logiciels prototypés. Ce tableau comparatif, en fonction d’une pondération liée aux besoins auxquels on cherche à répondre, peut ensuite permettre d’obtenir une note globale par produit et donc de les comparer globalement. Par exemple, si l’accent est porté sur la gestion des workflows, la qualité de l’interface utilisateur : les notes attribuées seront pondérées par un coefficient de 3 pour ces critères et verront leur importance croître vis à vis des autres critères, avantageant le produit bon pour ces critères, et réciproquement.

81

Cette notation, sans coefficient pondérateur, permet aussi d’avoir un indicateur de la couverture des besoins de l’utilisateur. Notamment la note correspondant à la moyenne générale des notes obtenues pour chaque critère. Elle peut être comparée à une note d’appréciation globale, subjective, attribuée par l’évaluateur ou le groupe chargé de l’évaluation. Voyons maintenant cette grille d’évaluation et la notation associée appliquées à des exemples.

2.2. Exemples Une approche la plus scientifique possible aurait requis une segmentation des utilisateurs et des utilisations possibles de la gestion de contenu afin d’élaborer des jeux d’essai représentatifs des situations auxquelles la ou les offres de service de la société informatique désireraient répondre. La démarche aurait été d’autant plus difficile qu’à priori toutes les organisations sont susceptibles d’être confrontées à la gestion de contenu. Notre approche a donc été pragmatique, tenant aussi compte des moyens dont nous disposions pour cette étude et l’expérimentation. Toutefois, le jeu d’essai a été conçu pour éprouver tous les aspects principaux de la gestion de contenu (collecte et édition, structuration de documents, méta données, publication, notamment sur le web, transformation…) en imaginant une organisation soucieuse d’initier une démarche de gestion de contenu « universelle » (cf. introduction générale page 2). Le jeu d’essai est décrit dans la première sous-section (2.2.1) de ce chapitre. De même, le jeu d’essai est suffisamment développé pour pouvoir prétendre imiter une organisation réelle. Ce jeu d’essai a été mis en œuvre dans trois prototypes, un pour chaque logiciel évalué de manière détaillée. Nous discuterons dans la section 2.2.2 de la mise en œuvre pratique de chaque logiciel, tant du point de vue de leur domaine initial d’application (cf. Tableau 3 : classification de logiciels de gestion de contenu Interwoven ECM, MS SPPS et SPIP), que du point de vue de la couverture des besoins exprimés dans notre jeu d’essai. La notation attribuée exprime de manière synthétique la couverture des besoins fonctionnels initiaux.

2.2.1. Jeu d’essai Le jeu d’essai qui a été développé fait l’objet de deux documents : une offre de marché [82], qui décrit les exigences initiales de l’organisation en matière de gestion de contenu et les spécifications fonctionnelles [83] qui développent les éléments de l’analyse résultante en vue de la mise en œuvre de l’application avec un logiciel spécifique. Le principal type de document qui a été pris en compte est le QCM, questionnaire à choix multiples, car il fait l’objet d’une structuration importante. Un autre type de document a été envisagé, mais uniquement de manière théorique : le contrat de commande de QCM, afin notamment d’évaluer l’intégration des documents entre eux. De même, la base documentaire de l’entreprise a été décrite afin d’entrevoir la complexité d’une mise en œuvre de la gestion de contenu complète de l’organisation. Par contre, la simulation de l’intégralité de la gestion de la base de documentaire de l’entreprise aurait résulté en une expérimentation démesurée. Le jeu d’essai fait la part belle à la reprise de contenu pré-existant (migration) dans la nouvelle application de gestion de contenu développée dans le prototype. A cet effet, 31 QCM ont été récupérés et adaptés, ceci dans des formats multiples. Dans un second temps, le jeu d’essai est prévu pour pouvoir gérer l’édition de nouveaux documents dans le système de gestion de contenu. Des valeurs ont donc été fixées pour spécifier : - la structure des QCM et des contrats (développement du schéma de classe, de la DTD et du schéma XML repris dans notre rapport en annexes 1 et 2),

82

- les méta données (méta données du DCMI – cf. section 2.3.2 partie A – et catégories de classement des QCM, - le cycle de vie d’un document, - la gestion des droits d’accès (utilisateurs, groupes de travail, droits d’accès), - les workflows (chaînes d’édition). Le format de publication retenu pour les publications de QCM a été simplement HTML 4.0 pour les publications issues de mécanismes de transformation (cf. section 3.3.1 partie A). Les autres tests des applications prototypées : recherche de document, recherche fédérée, abonnement, groupes de discussion, syndication, notification automatique par courrier électronique, n’ont pas été spécifiées mais réalisées au cas par cas en fonction des fonctionnalités réellement proposées par le logiciel testé. La mise en œuvre des prototypes pour les logiciels testés à fait l’objet d’une évaluation détaillée reprise dans la section 2.2.2 suivante.

2.2.2. Adaptation au logiciel de gestion de contenu et évaluation détaillée

L’adaptation du jeu d’essai au logiciel de gestion de contenu testé est reprise principalement dans les éléments « commentaire général » et « conclusion » de l’évaluation détaillée de chaque logiciel. Pour alléger l’évaluation, nous avons retiré la partie concernant l’installation (cf. section 2.1.1) qui n’a pas d’intérêt direct dans notre rapport.

2.2.2.1. Interwoven TeamSite (gestion de site web)

Commentaire général Le produit est composé de deux composants majeurs : TeamSite et TeamSiteTemplating. Le premier est globalement un gestionnaire de site web permettant la création et l’édition collaborative d’un site web, avec notamment une fonctionnalité de « staging » (ou encore zone de consolidation). Il intègre les fonctions de gestion de fichiers distribuée, de versioning et d’authoring, de gestion des droits sur les documents, d’édition de méta données. Le second permet principalement de séparer les données (le contenu) de la présentation, soit la gestion de documents XML. L’utilisation (optionnelle, pas mise en œuvre dans cette étude) de DataDeploy permet de stocker et récupérer les éléments XML des documents dans une base de données et d’OpenDeploy de publier automatiquement les documents en « multi canal ». Le fait de ne pas utiliser le logiciel DataDeploy empêche l’utilisation de la recherche de document et notamment sur les méta données. Paramétrage - utilisateurs, rôles et groupes de travail Les rôles et groupes de travail sont définis au niveau du système d’exploitation et plus précisément dans la gestion des groupes et des utilisateurs sous Windows 2000 Server. On ne peut donc pas créer d’Alias ou de rôle, car en local au moins, on ne peut affecter un groupe à un autre groupe. Dans le système TeamSite, une limitation majeure semble être l’impossibilité d’éditer de nouveaux rôles (on ne trouve par défaut que les rôles auteur, éditeur, administrateur et maître - super administrateur). De même, un utilisateur extérieur au domaine (NT) ne peut accéder au système, sauf si on crée cet utilisateur, sous NT/2000. Ce qui représente une certaine lourdeur pour l’administration du système d’information général de l’entreprise. Si cela est finalement fait, cet utilisateur doit être auteur ou pire éditeur. Or, on veut parfois laisser juste un accès en lecture à la zone de consolidation (staging) pour des clients, par exemple, pour qu’ils puissent voir le résultat de leur demande avant la publication sur le site web de production. Il manque donc un rôle dit « public » pour l’accès aux documents en dehors de l’application ou encore sans avoir à s’authentifier !

83

Il faut tempérer cette analyse par le fait que l’on peut aussi accéder aux fichiers via l’explorateur de fichiers en montant la partition IFS77 créée à l’installation de TeamSite où les répertoires reprennent les zones de travail, consolidation et éditions. Cependant, attention, les zones de consolidation et d’éditions sont publiques (accès « tout le monde ») par défaut. S’illustre ici encore le fait que TeamSite est avant tout un gestionnaire de site web. Le CMS ne gère donc plus les accès (en fonction des utilisateurs) sur le site web dit « de production ». Peut-être que le produit complémentaire « OpenDeploy » le permet. Note : 2 - workflows Un point majeur, relevé lors de la mise en œuvre de notre prototype a été que, avec l’utilisation des workflows définis par défaut (dans le fichier de configuration des workflows fourni comme exemple – ‘available_templates.cfg’), si l’éditeur n’est pas aussi déclaré comme administrateur (de branche), le menu déroulant permettant d’approuver ou de rejeter un travail (un document soumis par un auteur) n’est pas accessible (NA : non available). Autrement, les fonctionnalités de workflow avancées (par exemple, rajouter à la chaîne d’édition le renseignement des méta données) ne sont possibles que si l’on ajoute au produit de base TeamSite Workflow, logiciel complémentaire. Les fichiers de développement de workflow sont écrits en langage Perl. Nous n’avons pas non plus pu éprouver la notification d’un job (tâche, travail) par courrier électronique, n’ayant pu facilement paramétrer le serveur SMTP (cf - évaluation guide d’administration : aucune information complémentaire sur le paramétrage du serveur SMTP n’étant fournie dans le manuel d’administration de TeamSite). Note : 3 - type de document (structure) Tous les types de documents sont possibles. TeamSite Templating propose un utilitaire permettant de convertir une DTD (Document Type Definition) XML en fichier de capture de DCR (datacapture.cfg). Il s’agit du programme accessible en ligne de commande intitulé : « iwdtd2sym ». Cet outil est très pratique pour initier rapidement un « data capture template » ou encore un modèle de document (« template ») pour la saisie. Cependant, à partir du moment où l’on ne travaille qu’avec la DTD les éléments sont uniquement de type PCDATA, c’est à dire de forme « chaîne de caractères » et donc non contraints. L’outil aurait été plus performant s’il acceptait en entrée des « schémas XML » qui permettent de préciser le type de données et donc de les contraindre (contraintes de valeurs, de domaine, d’intégrité) de manière plus naturelle. Note : 3 - méta données Là encore, beaucoup de choses sont possibles, mais pas nativement. Il faut donc prévoir un certain temps de développement afin de permettre la présentation de formulaires de capture de méta données qui soient spécifiques à différents types de document, de saisir des catégories de documents à plusieurs niveaux (par exemple, sous-catégorie de sous-catégorie de catégorie principale) ou encore intégrant un thésaurus. Notamment, il faut là encore prévoir de rajouter un produit Interwoven additionnel : DataDeploy. Sans lui, la recherche de documents sur les méta données (recherche paramétrique) est impossible. Les méta données ne sont pas récupérables au format RDF (Ressource Description FrameWork) de manière native. Elles sont stockées dans le système de stockage (TeamSite backing store ou encore iw-store) et récupérable via une API en absence de l’utilisation de data deploy. Certaines méta données sont gérées nativement dans TeamSite comme l’auteur, le validateur, la date de création du document, sa date de modification, sa date de validation. Mais sont-elles ensuite regroupées avec les méta données définies dans le paramétrage du système ? Peut-on les extraire pour les regrouper avec les méta données « utilisateur » (par opposition à méta données 77 Sécurité d’Interwoven et de SharePoint Portal Serve r et pilote IFS du Web Storage System : Le modèle de sécurité basé sur les rôles de SharePoint Portal Server et d’Interwoven n’est applicable que lorsque l’accès au Web Storage System (système de stockage Web) sous-jacent s’effectue via les modèles objet ADO et CDO ou via le protocole Internet WebDAV. L’accès au Web Storage System via son pilote IFS (Installable File System), qui présente généralement la banque d’informations de dossier hiérarchique comme un fichier hiérarchique monté comme le lecteur M:, annule les mécanismes de sécurité basés sur les rôles de SharePoint Portal Server ou d’Interwoven. Aussi, le serveur doit-il être sécurisé au niveau des accès physiques locaux et des accès aux services de réseau et de terminal.

84

« système ») ? Peut-on renseigner des méta données utilisateurs avec des méta données systèmes de manière automatique ? Il semble que non ! Enfin, il n’est pas proposé par défaut de classification, taxonomie, dictionnaire ou encore thésaurus visant à enrichir les méta données. Il faut utiliser Interwoven MetaTagger qui propose ces fonctionnalités (dictionnaire des régions et pays, dictionnaire des métiers (« business ») , annuaire des entreprises cotées au New York Stock Exchange). Note : 3 - éditions XML L’édition XML des documents est laborieuse si l’on ne rajoute pas de développements sérieux sur les formulaires (html) de capture de données. L’interface « Java Templating UI » (ou l’autre « web templating UI ») est décevante. Par exemple, les champs de saisie des éléments XML sont de type « textArea » et il n’y a pas de retour à la ligne lorsque l’on dépasse la largeur de la « textArea ». Il faut pour se relire retourner au début de la ligne… sans oublier ce que l’on a écrit à la fin ! On ne peut pas non plus, en conséquence, utiliser la touche de tabulation pour passer d’un champ à un autre. C’est à ce niveau que l’on précise les contraintes sur les champs (format, valeurs possibles). Enfin, on ne peut pas préciser en début d’édition d’un fichier XML (DCR) le nombre d’éléments (et sous-éléments) que l’on désire. Par défaut, dans notre prototype, on a un formulaire de saisie d’un QCM avec une question contenant une réponse ! Il faut ensuite rajouter un par un chaque élément supplémentaire et supprimer ensuite un par un chaque élément optionnel non désiré ! L’édition est donc très peu productive dans ce contexte. Note : 3 - éditions avec plugin Elle est possible. Il s’agit d’un mécanisme de checkin / checkout. On utilise là l’utilitaire client LaunchPad. L’utilisation est ambiguë par rapport au mécanisme de download/upload offert en complément. Note : 3 - transformation pour la publication Elle est possible. On peut générer tout type de format de publication. On peut donc théoriquement générer des pages « asp » ou « jsp », mais alors leur test à l’intérieur de TeamSite (dans les zones de travail et de consolidation) nécessite le paramétrage du serveur web en conséquence. Il faut éditer les fichiers de transformation (presentation template): ces fichiers sont basés sur une DTD d’Interwoven et requièrent l’utilisation de Perl (standard Perl 5.00503 compiler). Note : 4 - développement et customisation Les développements et la customisation nécessitent la connaissance du langage Perl (surtout pour les fichiers de mécanismes de workflow et les fichiers de transformations - presentation template). Au moins, il faut connaître les paramètres (balises correspondant aux éléments XML) des fichiers de configuration générale (iw.cfg), de configuration des workflows (available_templates.cfg), de configuration des règles s’appliquant aux méta données (metadata-rules.cfg), de définition des méta données (datacapture.cfg). Il faut noter que par défaut, le paramétrage des règles d’encodage est basé sur le jeu de caractères UTF-8 et n’est pas compatible avec des sources encodées différemment., Il serait nécessaire d’utiliser par défaut le jeu de caractères ISO-8859-1. Le fichier « file_encoding.cfg » doit être édité en conséquence. Cela veut dire qu’il n’y a pas à proprement parler de version de TeamSite française pour MS Windows. On peut dire à ce niveau que se lancer dans la mise en œuvre des produits Interwoven, c’est se lancer dans une approche propriétaire… même si le produit est relativement ouvert et bien intégré à MS Windows. En guise de conclusion, on peut dire que l’appropriation des concepts et des techniques nécessaires au développement (en fait une mise en œuvre réaliste) de TeamSite et à sa customisation, le développement en lui-même, et ensuite la maintenance des règles établies est lourde en ressources humaines (temps et compétences). On tomberait donc les revers d’une application « maison », alors qu’au départ, on cherche à s’appuyer sur un progiciel ! Toutefois, la puissance de l’application TeamSite n’est pas remise en cause.

85

Note : 3 - intégration (serveur de mail; serveur web, proxy, base de données, serveur d’application) L’intégration à un système de gestion de base de données n’a pas été testée. L’intégration au serveur de mail s’est avérée décevante même si elle doit être à priori assez simple. Il est nécessaire de bien maîtriser l’utilisation et le paramétrage des serveurs web et proxy. Des compétences en administration réseau et serveurs web/proxy sont nécessaires dans le lancement d’un projet avec TeamSite (pour le mapping, la re-direction, l’utilisation de la zone d’édition comme répertoire racine du serveur web de production). Le programme chargé de l’envoi des notifications par mail au serveur SMTP relais semble être « BLAT 1.5 ». Pour l’intégration avec un serveur d’application, il faut rajouter un composant additionnel : TeamTurbo qui permet la virtualisation dans TeamSite des fonctionnalités du serveur d’application (de type java). Il semble que tout le travail se fasse à partir du serveur d’application pour utiliser les éléments stockés et gérés dans TeamSite. Pour intégrer, l’application TeamSite à un portail, il faut utiliser TeamPortal. L’intégration avec des serveurs d’application de l’architecture « .NET » doit pouvoir s’envisager. Note : 3 Utilisation - administration Il n’y a pas d’interface d’administration homogène et unique de l’application. La tentative proposée pour cela est l’interface web d’administration (TeamSite Admin). Son utilisation semble générer une instabilité du système qui nécessite à chaque utilisation un redémarrage de la machine. Elle a en conséquence rapidement été abandonnée au profit des utilitaires en ligne de commande (CLT : command line tools) sur lesquels l’interface web est basée. Les fichiers de configuration ont été directement édités en mode texte à l’aide d’éditeurs de texte… L’interface d’administration est de toutes les manières trop légère, puisque les paramètres de configuration sont loin d’être tous gérables depuis l’interface graphique : il faut donc éditer les fichiers de configuration en mode texte. La gestion des utilisateurs se fait depuis le système d’exploitation Windows 2000 (utilisateurs et groupes) et celle des rôles dans des fichiers textes (autor.uid, editor.uid, adminstrator.uid et master.uid). La maintenance est donc lourde et source de problèmes. Les adresses de courrier électronique, si elles sont différentes d’une règle simple (du genre [email protected]), doivent être maintenues dans un fichier complémentaire (email_map.cfg), ce qui ajoute en lourdeur. La gestion des accès (droits en lecture, écriture, suppression, appropriation, etc…) se fait là aussi en fonction des règles d’accès établies au niveau des répertoires de la partition IFS créée à l’installation (cf. installation) depuis le système d’exploitation. Le concept d’alias n’existant pas explicitement sous Windows 2000, là encore, la gestion des droits et des accès est lourde. Note : 1 - récupération de documents existants (import) Il y a bien une fonction (import) de récupération de fichiers. Note : 4 - édition de document : création La création de document ne pose pas de problème particulier. Note : 4 - édition de document : mise à jour La mise à jour de document est plus lourde. La gestion des verrous est peu intuitive. Il faut paramétrer LaunchPad pour activer l’éditeur de document voulu en fonction du type de fichier. Il peut y avoir confusion avec la fonction upload/download. Toutefois, si l’on modifie les modèles de présentation (fichiers de transformation .tpl), on peut utiliser la fonction de génération en lot des formats de sortie (ou encore format de publication). On trouve là la puissance qu’accorde un système de gestion de contenu.

86

L’appel du client pour la modification d’un fichier pose systématiquement un verrou (qu’il faut ensuite explicitement enlever) sur le fichier même si aucune modification n’y a été apportée. Il faut donc systématiquement, si l’on ne veut pas verrouiller un fichier, ouvrir le fichier en lecture uniquement, même si par la suite, il faudra l’ouvrir en édition, si nécessaire. Note : 3 - édition méta données Elle est possible. On peut regretter le manque d’automatisme de renseignement par défaut de certaines méta données (cf. méta données). Note : 3 - publication TeamSite est doté d’une zone de consolidation (staging) et d’une zone d’édition permettant une « sauvegarde » (snapshot) de la zone de consolidation quand celle ci est considérée comme bonne pour son transfert sur le site de production. Chaque nouvelle édition est sauvegardée et permet d’avoir une sauvegarde des versions du site web. La soumission des fichiers des zones de travail vers la zone de consolidation est accompagnée d’un mécanisme de comparaison de fichiers (dif), de fusion (merge). En pratique, nous avons été confrontés à un problème d’écrasement des zones de travail consolidées à chaque nouvelle consolidation d’une zone de travail. Il manque un accès avec un rôle « invité » avec des droits en lecture uniquement sans accès à TeamSite (accès public) pour visualiser des parties du site web ou d’un document dans la zone de consolidation pour des utilisateurs tiers (client, sous-traitants, etc.). Pour les mécanismes de publication automatisée, il faut installer en sus le produit OpenDeploy. Note : 3 - workflow TeamSite gère les chaînes d’édition en incluant éventuellement des traitements automatiques. Toutefois dès que l’on a besoin d’un workflow avec trois étapes de traitement (incluant la création ou mise et à jour et la validation), il faut développer soi-même un nouveau mécanisme de workflow. Note : 4 - versioning L’accès aux différentes versions d’un document est possible. Leur comparaison et une éventuelle fusion sont envisageables. Note : 4 - recherche de documents Elle s’effectue uniquement sur les méta données, c’est à dire les données descriptives des documents. Elle nécessite l’installation du composant additionnel DataDeploy ainsi qu’une base de données afférente à l’aide d’un SGBD tiers. Ou bien, il faut installer TeamSite FrontOffice, qui permet une recherche sur les méta données depuis le gestionnaire de fichier de Windows. Il n’y a pas de recherche « full text » ni aucune autre fonction d’indexation et de recherche avancée. Note : 2. - interface graphique Un auteur peut disposer de quatre interfaces graphiques différentes : WebDesk, WebDeskPro, Java Templating UI ou web Templating UI et SmartContextEditor. L’accès aux documents peut encore se faire via LaunchPad, la fonction Download/upload ou bien directement depuis le gestionnaire de fichier fourni par Windows, si la partition IFS créée par TeamSite est montée sur la machine du client. Enfin, si l’on installe TeamSite FrontOffice, on peut travailler avec TeamSite directement depuis la suite MS Office (dont Word principalement). Il n’y a donc pas d’interface unifiée, bien au contraire, et chacune est limitée. L’interface graphique est gérée à partir de mécanismes offerts par Java (applet) et ceux du navigateur (html et javascript) et on

87

a l’impression que les développements se sont limités à l’utilisation de AWT (en négligeant Swing). Il en résulte une interface graphique décevante. Il n’y a pas d’aide contextuelle et encore moins de menu contextuel. On peut rappeler ici (cf. évaluation de l’administration) la pauvreté de l’interface graphique d’administration. Note : 2 Intégration Elle se fait grâce aux modules d’Interwoven : DataDeploy, TeamTurbo et TeamPortal - intégration des documents dans le système de gest ion de contenu lui-même Cette intégration n’est pas possible par défaut. Il faut voir les possibilités offertes via DataDeploy. Note : 2 - utilisation des composants documentaires stockés et intégration avec d’autres applications informatiques Elle sera différente selon que l’on utilise DataDeploy on non. On peut dire que le logiciel offre, dans l’alternative négative, un dépôt (repository) XML, c’est à dire des fichiers plats de type texte structurés avec XML. L’accès aux méta données n’est pas mentionné en dehors de la mise en œuvre de DataDeploy, auquel cas, on imagine qu’on maîtrise l’accès aux tables de stockage des méta données dans la base de données synchronisée. Il faut en fait, en absence de DataDeploy, utiliser une API (proposant des fonctions get et set_extended_attribute) en Java ou Perl. On peut déplorer que TeamSite ne propose pas un mécanisme de gestion des droits, suite à authentification pour la gestion des accès aux différentes parties du site web (abonnés avec différents types d’abonnement, utilisateurs internes sur un intranet…). Note : 2 - migration vers l’application de gestion de conten u Il y a un mécanisme d’import qui permet d’introduire les documents résultant de l’éventuel passé documentaire de l’entreprise. Ils peuvent ensuite être gérés avec les fonctions offertes par TeamSite (authoring, versioning, workflow, etc…). En revanche, il n’y a pas d’assistant (wizard) de transformation des fichiers importés vers le format XML (DCR), format unique de stockage et de gestion des documents. Il faut donc prévoir en cas de documents nombreux et homogènes une moulinette de transformation par lot (batch). Sinon, après avoir développé les formulaires de capture (dataCapture.cfg) des types de documents concernés et les modèles de présentation afférents (fichiers .tpl), il faut re-saisir les données… Note : 3 - migration depuis l’application de gestion de cont enu vers une autre application N’utilisant pas des formats normalisés, notamment ceux du W3C, par exemple, RDF pour les méta données, BPML (ou encore Xlang) pour les workflows, une migration vers une autre application demandera un travail de grande ampleur qu’il s’agit de ne pas négliger si l’on s’engage dans l’ensemble de la gestion de la documentation de l’entreprise avec Interwoven TeamSite. Le fait que les fichiers modèles de présentation (.tpl) contiennent en plus du code imbriqué en langage Perl, langage peu utilisé par ailleurs, ne fait que renforcer cette appréciation. Note : 2 Conclusion Interwoven TeamSite et TeamSite Templating est avant tout un gestionnaire de site web et son utilisation comme système de gestion de contenu détourne la suite logicielle de sa vocation initiale. En effet, la structure fonctionnelle de base avec des branches contenant des zones de travail, une zone de consolidation (staging) et une zone d’éditions (équivalente à l’image du site web de production) induit une gestion des droits et des accès complexe et limitante. Globalement, avant une utilisation globale dans une entreprise, le produit demande de lourds et nombreux développements complémentaires (customisation) qui augmente d’autant le coût de la solution.

88

Cependant, il est certain qu’Interwoven offre une bonne richesse fonctionnelle pour faire de la gestion de contenu, notamment la gestion de site web. Surtout, il permet une gestion effective des documents au format XML, même si la gestion des méta données n’est pas naturellement riche dans un premier temps et demande, comme déjà dit précédemment, une importante customisation. La fourniture de TeamSite FrontOffice par défaut pour la version Windows NT/2000 du produit améliorerait certainement une mise en œuvre ad minima du produit. En fait, il semble impératif d’utiliser MetaTagger, DataDeploy, OpenDeploy et TeamSite workflow dès le démarrage d’un projet. Pour compléter un projet en envisageant une intégration aux autres applications de l’entreprise, il faudra rajouter les composants TeamTurbo et TeamPortal. Note d’appréciation globale : 3 Note moyenne (des critères d’évaluation avec un coefficient de 1 pour chacun) : 2,88

2.2.2.2. Microsoft Share Point Portal (intranet documentaire)

Commentaire général Share Point Portal Server (SPPS) est un logiciel proposant la gestion d’un portail et des documents de l’entreprise. Il se positionne de manière idéale pour la mise en œuvre d’un intranet pour PME / PMI. A ce titre, il décline par défaut les fonctionnalités de news, annonces, une rubrique « liens rapides », une interface de recherche (au-dessus d’un module de recherche fédérée), la bibliothèque de documents et des catégories de documents. On trouve aussi une fonctionnalité de fil de discussion sur les documents et d’abonnement (envoi de mail en cas de publication de nouveaux dans une catégorie de document ou d’un dossier particulier). Concernant la gestion documentaire, l’authoring, le versioning, le travail collaboratif sont gérés via le protocole WebDav qui est implémenté. Les méta données sont prises en compte à travers le concept de profil de document. Son architecture est basée sur les espaces de travail auquel on assigne des utilisateurs et/ou groupes de travail enregistrés dans le domaine NT / 2000. On peut au niveau des répertoires gérer des groupes de travail et des droits d’accès spécifiques, alors que les nouvelles et les annonces (en fait toutes les autres rubriques) sont communes à l’espace de travail. Il faudra l’intégrer à Content Management Server (CMS) pour le voir s’élargir en gestionnaire de site web (et commencer à envisager la séparation du contenu – des données – et de la présentation). Autrement, pour pouvoir utiliser des modèles de documents normalisés (les documents à l’extension .dot pour les modèles de document pour Word), il faudra utiliser SPPS 2001 avec Microsoft Office XP (client). En aucun cas, on ne peut envisager un traitement à la XML (modularisation) de composant documentaire. Paramétrage - utilisateurs, rôles et groupes de travail Les rôles et groupes de travail sont définis au niveau du système d’exploitation et plus précisément dans la gestion des groupes et des utilisateurs sous Windows 2000 Server. On ne peut donc pas créer d’Alias ou de rôle, car en local au moins, on ne peut affecter un groupe à un autre groupe. Les rôles existants sont : administrateur au niveau de l’application (SPPS), coordinateur au niveau d’un espace de travail ou au niveau d’un dossier (et ses sous-dossiers), auteur, lecteur et approbateur au niveau des dossiers. Il faut rajouter un rôle annexe qui est le rôle de contact. Ces rôles et leur mise en œuvre offrent la réponse à l’ensemble des attentes que l’on peut attendre pour la gestion collaborative en matière de publication de documents sur un intranet. Note : 4 - workflows Les workflows offerts sont simples et on ne peut pas en créer de nouveaux. On ne peut pas assigner de tâches à un auteur. On ne peut pas prévoir la succession de plusieurs auteurs pour élaborer un document. Les différents états d’un document sont « extrait » (checked out), « archivé », « publié », « en attente d’approbation ». Un auteur soumet donc un document à l’approbation si un processus de workflow a été spécifié pour les documents du dossier (répertoire) concerné. La spécification d’un workflow peut comprendre un ou plusieurs approbateur, avec approbation d’un seul ou de l’ensemble des approbateurs.

89

Un mail de notification est envoyé à chaque approbateur. Il contient un lien vers une page de SPPS (page d’inspection) permettant de voir, d’approuver ou de rejeter le document. Le seul défaut du lien est d’être inopérant si le document contient une accentuation (« é », « è », etc… soit un caractère non compatible avec UTF-8 s’il est encodé différemment à la source) si on ne décoche pas l’option dans l’onglet des propriétés avancées d’Internet Explorer « toujours envoyer les URL en tant qu’UTF-8 ». Par contre, il n’y pas de mail de retour à l’auteur pour lui signifier que le document a été approuvé ou rejeté. Il faut rajouter un « web part » intitulé « doc_status » ou encore « Personnalized Document Status Report » pour que chaque utilisateur puisse voir au sein de SPPS une page récapitulant les documents sur lesquels il a une action en cours. On peut établir un fil de discussion sur un document pour compenser l’impossibilité d’ajouter des commentaires à une décision concernant l’approbation ou le rejet d’un document ou de ses méta données. Note : 3 - type de document (structure) Nativement, SPPS ne permet pas de spécifier des types de documents. On ne trouve que la notion de profil de documents qui en fait ne concerne que les méta données et non pas la structure du document. On pourrait utiliser les modèles de documents (par exemple, les .dot de word), mais cela nécessite pour cela que les clients soit équipées avec la suite office XP et qu’on rajoute à SPPS le « web part » appelé « document template » ou encore « Create document from office XP ». Ensuite, on peut envisager une utilisation des propriétés des documents office avec une intégration pour gérer une partie de la structure des documents. Mais cela paraît compliqué et ce n’est pas du tout natif. De même, une intégration de SPPS avec CMS permet d’envisager l’utilisation des « resource templates » à cette fin sans que cela prévu vraiment pour cela. Notons ici, qu’alors, CMS enregistre les éléments (composants) du document, appelés « place holder », dans une base de données de MS SQL server. Note : 1 - méta données A travers le concept de profil de document, SPPS permet une gestion (saisie, collecte, valorisation pour la recherche) effective des méta données. Notamment, SPPS met l’accent sur l’utilisation des catégories de documents avec en sus un module de catégorisation automatique. Toutefois, on doit noter qu’au-delà de 500 catégories le système ne fonctionne plus de manière performante et que de même, le choix de la catégorie via l’interface de saisie des méta données est difficile, ceci étant dû à une interface graphique insuffisante pour cela. Il faudrait un assistant (wizard) à la catégorisation, permettant d’afficher notamment un arbre (comme cela est fait au niveau de la partition IFS, disponible au niveau du client). Les catégories sont finalement présentées triées par ordre alphabétique et si l’on utilise une taxonomie avec une codification, cela ne sera pas géré. Il n’y a pas de fonction d’importation de classification. A part les catégories, on ne peut pas gérer de méta données sur plusieurs niveaux, même si SPPS offre six types de données pour les contraindre (texte, nombre, liste, liste à plusieurs valeurs, zone de commentaire, date). On ne sait pas ensuite où sont regroupées ces méta données dans le système. Note : 3 - éditions XML SPPS ne permet pas l’édition de document XML ni leur gestion. SPPS ne gère pas non plus les documents composites. Notamment, il génère un message d’alerte à chaque fois que l’on veut archiver un document html dans un dossier de documents de SPPS. Note : 0 - éditions avec plugin Intégré à MS Windows, l’édition avec un logiciel plugin est naturelle. Note : 4

90

- transformation pour la publication La séparation des données de la présentation n’étant pas prévue avec SPPS, cette fonctionnalité n’a pas lieu d’être évaluée. Toutefois, la publication multi-canal est possible si on utilise conjointement Content Management Server (CMS). Note : 0 - développement et customisation Microsoft propose avec SPPS, un kit de ressource contenant des outils additionnels que l’on intègre à SPPS, notamment les web parts. L’intégration des outils MS Office permet d’envisager de publier et mettre à jour des documents Excel par exemple. Les web parts sont ensuite inclus dans des tableaux de bord (« dash board ») facilement depuis le module de gestion de l’administrateur de SPPS, qui peut aussi créer une nouvelle section web (un nouvel onglet en quelque sorte, ou encore une rubrique de niveau supérieur). Les web parts sont facilement développés avec l’outil « Microsoft Office XP Developer ». Autrement, pour la mise en forme des pages dans SPPS, il est proposé par défaut plusieurs feuilles de styles. On peut bien évidemment développer sa propre feuille de style. Le contenu et la disposition de l’application avec SPPS sont donc facilement customisables, mais si on travaille avec Office XP, soit des versions récentes des outils microsoft. Note : 4 - intégration (serveur de mail; serveur web, proxy, base de données, serveur d’application) L’intégration au serveur de mail ne pose pas de souci, ainsi que celle du serveur web et proxy… Tant que l’on reste dans le cadre d’un intranet ! Autrement, il faut faire appel bien évidemment aux ressources idoines. L’intégration à un système de gestion de base de données n’est jamais directement envisagée avec SPPS. L’intégration avec des serveurs d’application de l’architecture « .NET » doit pouvoir s’envisager. Sortir de l’univers Microsoft pour intégrer d’autres applications est une autre histoire… Toutefois, par exemple, Siebel et SAP proposent des web parts (s’interfacant à leur application) que l’on peut intégrer à SPPS. SPPS peut dialoguer avec des applications à travers des composants COM+. Note : 3 Utilisation - administration La délégation des tâches d’administration au niveau des coordinateurs permet une bonne répartition de celles ci. La gestion des performances s’effectue au niveau de l’analyseur de performances des outils d’administration du serveur NT / 2000. Toutes les autres taches, à part quelques unes à l’installation de SPPS qui s’effectuent aussi à partir des outils d’administration du serveur dans le module « administration de Share Point Portal Server », se font à partir de la partition IFS (dans l’explorateur de fichier) qui est montée automatiquement dans les favoris réseaux sur le serveur où est installé SPPS et que l’on peut ajouter aux favoris réseaux sur n’importe quel poste client où est installé le client SPPS. La création des structures de dossier est identique à celle que l’on peut faire sur un système de gestion de fichier classique. La création et l’édition de profil de document sont correctes. L’assignation des rôles et des droits est pointilleuse et se fait d’abord au niveau de l’espace de travail puis au niveau des dossiers en fonction des besoins. C’est là aussi que l’on précise les itinéraires d’approbation avec les approbateurs associés et leur adresse de courrier électronique si elle ne se déduit pas de la règle « [email protected] », ainsi que les contacts. On peut imaginer des lourdeurs de maintenance à ce niveau, bien qu’avec une bonne délégation des tâches, on puisse imaginer que chacun réagisse rapidement à des changements de personnes. C’est là qu’on peut déplorer la non-utilisation d’alias ou d’une liste centrale des approbateurs et des contacts (comme pour les abonnements ou les discussions – voir plus bas). L’édition des catégories est laborieuse. Une autre partie de l’administration : gestion des abonnements, gestion des discussions, customisation du portail se fait à partir du portail fourni par SPPS (soit encore depuis le navigateur internet explorer).

91

Note : 3 - récupération de documents existants (import) Il y a bien une fonction (import) de récupération de fichiers. Il faut ensuite éditer les méta données (choisir un profil de document) et publier les documents, dossier par dossier. Cela peut donc être une opération assez longue en fonction de la qualité des renseignements sur les documents attendus. Note : 3 - édition de document : création La création de document ne pose pas de problème particulier. Note : 4 - édition de document : mise à jour On utilise pour cela le mécanisme de check in / check out. Le processus est sobre. On édite ensuite le document avec son logiciel habituel. Note : 4 - édition méta données Elle est possible. On peut regretter le manque d’automatisme de renseignement par défaut de certaines méta données (cf. méta données). Note : 3 - publication SPPS n’étant pas un gestionnaire de site web (web content manager - WCM), cette fonctionnalité est exclue de l’évaluation. Toutefois, s’agissant de la publication pour l’accès aux autres lecteurs d’un dossier, SPPS est pourvu d’un mécanisme efficace et sobre. Note : 3 - workflow Les workflows ne peuvent pas être programmés. Ils sont proposés par défaut (voir installation/workflows). Par défaut, il n’y a qu’un seul mécanisme à la soumission pour la publication qui avertit l’approbateur. Les retours ne sont pas pris en compte de manière native. Aucune chaîne d’édition complexe ne peut être prise en compte. Note : 3 - versioning L’accès aux différentes versions d’un document est possible si l’on a choisi l’option « dossier amélioré » pour le dossier dans lequel les documents sont complets. Il n’y a pas de fonction de comparaison proposée par défaut, ni de fusion de document. Il faut faire cela à l’extérieur de l’application SPPS. Note : 3 - recherche de documents La fonction de recherche est un des points forts de SPPS. On peut facilement opérer des recherches fédérées sur plusieurs sources de contenu en ajoutant des « ressources externes » (site web, répertoire partagé d’un système de gestion de fichier, Dossiers publics Exchange Server 5.5., Dossiers publics Exchange 2000, Bases de données Lotus Notes, Autres espaces de travail). Celle ci opère en s’appuyant sur une indexation plein texte, une utilisation effective des profils de documents (méta données de SPPS), notamment la catégorisation, la prise en compte de mot stop (« stop word » ou encore mots parasites, qui sont des mots trop fréquents pour être significatifs comme le, la, les…) et enfin un thésaurus comprenant des règles d’expansion (prise en compte des synonymes) mais qu’il faut renseigner car il est vide au départ. Les résultats sont très satisfaisants si le volume de document n’excède pas une certaine taille, ceci pour les fichiers MS Office et textes (les fichiers PDF ne sont pas indexables).

92

Note : 4 - interface graphique Les interfaces sont à la hauteur de ce que l’on connaît de l’éditeur… Note : 4 Intégration SPPS prévoit des mécanismes d’intégration. - intégration des documents dans le système de gest ion de contenu lui-même Il n’y a pas de gestion des documents composites ni des documents XML. Il n’y a pas d’interfaçage avec un système de gestion de base de données. SPPS n’est pas conçu pour cela. Note : 1 - utilisation des composants documentaires stockés et intégration avec d’autres applications informatiques Il n’y a pas de gestion des documents composites ni des documents XML. Il n’y a pas d’interfaçage avec un système de gestion de base de données. SPPS n’est pas conçu pour cela. On pourrait envisager une utilisation des méta données et des traitements complémentaires pour associer les documents entre eux. Note : 2 - migration vers l’application de gestion de conten u Il y a un mécanisme d’import qui permet d’introduire par petit volume les documents résultant de l’éventuel passé documentaire de l’entreprise. Ils peuvent ensuite être gérés avec les fonctions offertes par SPPS (authoring, versioning, workflows, etc…). Il faut développer sinon un outil ad hoc. Note : 3 - migration depuis l’application de gestion de cont enu vers une autre application Notons ici la présence dans le kit de ressources pour SPPS 2001 d’un outil intitulé SPPSIMEX (Share Point Server XML Import and Export tool) qui permet d’importer ou d’exporter de manière « native » un espace de travail SPPS vers un autre serveur SPPS. Cet outil génère un fichier XML décrivant l’espace de travail avec une structure et des éléments propres à une DTD de Microsoft. Autrement, il faut développer un outil ad hoc. Note : 3 Conclusion SPPS est à la fois un outil de portail et de gestion documentaire. Il se cantonne strictement à ces deux domaines. On l’évalue ici surtout pour ses fonctions de gestion de contenu ce qui explique une note moyenne puisque SPPS fait de la GED et non de la gestion de contenu au sens strict (pas de séparation des données et de la présentation, pas de structuration des documents…). Cependant son approche de la gestion documentaire paraît être pragmatique, sobre et s’adapte finalement bien à une première approche de la GED pour une entreprise. Or indéniablement, cumulant deux domaines de la gestion de contenu, Microsoft propose avec SPPS une application très performante pour gérer un intranet pour le marché des PME / PMI. Sa fonction de recherche est excellente du fait qu’elle intègre gestion documentaire et portail. Les fonctionnalités semblent donc volontairement limitées pour une excellente acceptation utilisateur. Mais cette force est aussi sa faiblesse car ensuite, en cas de volonté d’extension de la prise en compte de la gestion de contenu, on ne pourra qu’envisager une intégration de Content Management Server (CMS) à SPPS pour faire du Web Content Management (gestion de site web). On ne fera toujours pas de la gestion de contenu. Il faudrait donc envisager des développements pour cela pour un coup assez lourd puisque rien n’est proposé par défaut pour cela. Note d’appréciation globale : 3 Note moyenne (des critères d’évaluation avec un coefficient de 1 pour chacun) : 2,93

93

2.2.2.3. SPIP (portail communautaire)

Commentaire général SPIP, Système de Présentation pour l’Internet, est un logiciel GPL (General Public Licence) de type Portail Communautaire, avec une spécialisation thématique pour la gestion de magazine sur l’internet (webzine). A ce titre, il est surtout adapté pour la gestion de site web associatif ou des sites de news. C’est un logiciel qui évolue peu et reste adossé à sa philosophie de base. Cela lui permet de fournir un fonctionnement robuste. De plus, développé initialement par une équipe française, toute sa documentation et son interface sont en langue française. Il propose des fonctionnalités intéressantes, qui si elles correspondent aux spécifications du projet, justifient son adoption. Ces fonctionnalités sont : gestion des rubriques du site, gestion des droits minimale, travail coopératif, gestion de mots clés (catégories), syndication, recherche de documents sur le site, la gestion de forum (fils) de discussion (voire de pétitions), rapports de base (statistiques) sur la fréquentation du site et l’accès aux articles (documents), la notification par mail (minimale) de quelques événements de l’application. L’édition des données (via un formulaire html) est séparée de la mise en forme pour la publication automatique (via les squelettes – « fichiers de transformations »). A noter que SPIP fonctionne avec un système de cache et permet ainsi de gérer un site web avec de nombreux accès. Sa limitation majeure est qu’il ne permet de gérer qu’un seul type de document (en dehors des brèves -news) : l’article, constitué des éléments titre, surtitre, sous-titre, descriptif, chapeau, texte principal, post-scriptum. De même, un seul type de workflow peut être mis en œuvre. Basé sur une architecture logicielle Apache, MySql et PHP, on peut étendre ses fonctionnalités sur cette base, indépendamment de SPIP. Paramétrage - utilisateurs, rôles et groupes de travail Une connexion à un annuaire LDAP est possible avec SPIP. Nativement, cependant on utilise la base interne à SPIP des utilisateurs. Il n’y a que deux rôles principaux (en dehors du rôle d’administrateur de l’application) : l’auteur (rédacteur) et administrateur restreint (responsable de la publication d’une ou plusieurs rubriques). La notion de groupe de travail est donc réduite uniquement au niveau des administrateurs restreints et ne s’applique pas aux rédacteurs qui peuvent participer de ce fait à toutes les rubriques (et non uniquement à celles auxquelles ils participent concrètement). Tous les utilisateurs internes (rédacteurs et administrateurs) ont accès (lecture et modification) à l’intégralité des contenus du site. Note : 2,5 - workflows Il n’y qu’un seul type de workflow. L’auteur soumet un article au gestionnaire de rubrique qui valide ou refuse l’article pour la publication. On ne peut pas réinitialiser ce workflow si l’auteur initial modifie cet article. Seule la messagerie interne (au site privé) permet de maintenir le processus actif. Note : 2 - type de document (structure) On ne peut gérer avec SPIP que deux types de documents : les brèves et les articles. On ne peut pas créer de nouveau type de document. Note : 2 - méta données SPIP n’intègre pas au sens propres la gestion des méta-données, et notamment des catégories de documents. Cependant, on peut détourner un ou deux éléments de l’article pour y associer une ou deux méta-données à un niveau. De même, SPIP gère les mots-clés, qui de facto, peuvent être considérés et gérés comme des catégories. On ne peut toutefois que gérer les mots clés sur deux niveaux (groupe de mots clé et mot clé à proprement parler). Note : 2

94

- éditions XML Les articles sont stockés dans une base de données (mySql) et non sous forme de documents XML. Mais cela offre les mêmes fonctionnalités. Note : 3 - éditions avec plugin On ne gère que des articles et des brèves avec SPIP. La notion de plugin est donc superflue et ne s’applique pas ici. Note : 0 - transformation pour la publication Elle se fait via les squelettes. On peut ainsi publier les articles (et les brèves) sous toutes les formes désirées (listes, page, aperçu…). Cela nécessite uniquement la connaissance d’html et du langage de boucle de SPIP. La connaissance de PHP facilite aussi peut-être cette tâche mais n’est pas indispensable. Note : 3 - développement et customisation On peut personnaliser le graphisme du site à volonté via les squelettes et les feuilles de style. Le comportement par contre est limité aux fonctions proposées par SPIP. Note : 3 - intégration (serveur de mail; serveur web, proxy, base de données, serveur d’application) Elle correspond aux possibilités offertes par l’architecture logicielle sur laquelle est construit SPIP, à savoir Apache + MySql + PHP et dépend aussi du système d’exploitation. Pour la notification automatique par mail du suivi éditorial, le serveur de mail doit être paramétré pour cela. De même, le proxy et le firewall doivent permettre à la syndication (récupération du fichier « backend ») de s’effectuer sans entrave. L’intégration de langage de script (type javaScript) est possible mais nécessite de tâtonner avant qu’elle ne puisse fonctionner correctement. Note : 3,5 Utilisation - administration L’administration est centralisée au niveau de l’interface graphique offerte via l’accès à l’espace privé du site avec son browser. Elle fonctionne parfaitement et est complète. Elle est cependant adaptée à des sites offrant une complexité moyenne à faible car il faut renseigner les paramètres un par un, sans possibilité d’automatisation. Pour les fonctions proposées, toutes sont paramétrables à souhait et cela s’effectue simplement. Le remodelage d’un site web géré par SPIP n’est pas bien prévu et il faudra re-ventiler les articles par rubrique un par un. A moins évidemment, d’utiliser un script adéquat pour directement modifier les données dans la base de données de SPIP (mySql). Concernant la maintenance technique, on peut effectuer via l’interface du site privé un « dump » de la base de données mySql. De même, on peut ensuite effectuer une restauration du site. De plus, SPIP fonctionne avec un système de cache que l’on peut gérer aussi via le module d’administration principale. Note : 3,5 - récupération de documents existants (import) Aucune possibilité native n’est proposée pour récupérer des volumes importants de documents. L’insertion de document existant se fait donc de manière unitaire !

95

Cependant, on peut bien sûr envisager de créer des scripts afin de compléter la base de données mySql sur laquelle SPIP est construit. Note : 2 - édition de document : création Elle est simple et se fait via un formulaire html dans le site privé avec son browser. La mise en forme de base (tableau, lien hypertexte, …) se fait à l’aide d’une syntaxe spécifique à SPIP et est à acquérir par l’utilisateur. Des notions d’html ne sont donc pas requises mais améliorent les possibilités du système. On peut effectivement permettre aux responsables de contenus de publier sur le site web sans avoir de notion d’informatique. Note : 3 - édition de document : mise à jour La mise à jour est bien sûr possible mais n’est pas réellement un besoin adressé par SPIP, car les articles une fois publiés n’ont pas vocation à être modifiés pour une nouvelle publication. C’est le détournement de SPIP pour gérer un site web un peu différent de ceux visés par la philosophie d’origine (voir commentaire général) qui amène à avoir besoin de modifier un article. Une illustration est l’absence de versioning dans SPIP. Une fois l’article publié, seul l’administrateur (gestionnaire de rubrique) peut modifier l’article ! Ou bien alors on retire cet article du site en modifiant son statut qui doit retourner à « en cours de rédaction », pour que l’auteur puisse reprendre la main. Note : 2 - édition méta données Nous avons vu qu’il n’y pas, à proprement parler, de prise en charge des méta-données. Cependant, on peut associer plusieurs mots clé à un article, une rubrique, une brève ou même des ressources syndiquées. C’est le gestionnaire de rubrique (administrateur restreint) qui a la charge de renseigner et maintenir ces informations. Une ressource peut être associée à une ou plusieurs catégories. Note : 2 - publication SPIP n’offre pas de fonctionnalité de staging. En fait, l’éditeur (administrateur restreint) peut choisir de publier ou non l’article et si oui, à quelle date cela sera effectué : le système prenant ensuite en charge la publication. Note : 3 - workflow SPIP ne gère en fait que la validation des articles avant la publication, soit un seul type de workflow. Note : 2 - versioning N’existe pas dans SPIP. Note : 0 - recherche de documents La fonction de recherche s’effectue via l’accès à toutes les colonnes de la base de donnée SPIP. SPIP indexe ainsi tous les articles, tous les auteurs, toutes les rubriques, tous les mots clés, tous les sites référencés ainsi que les ressources syndiquées. Note : 3

96

- interface graphique L’interface graphique est bonne. Elle est légèrement personnalisable en permettant le choix de la couleur (thème de couleurs) dans l’espace privé. L’accès aux différentes fonctions de l’application est assez aisé. Note : 3 Intégration - intégration des documents dans le système de gest ion de contenu lui-même Hors de propos avec SPIP qui ne gère que des articles (et des brèves). Note : 0 - utilisation des composants documentaires stockés et intégration avec d’autres applications informatiques On peut imaginer de coupler la base de données avec d’autres applications… Note : 2 - migration vers l’application de gestion de conten u Rien n’est proposé en natif. Il faudra tout développer. Note : 2 - migration depuis l’application de gestion de cont enu vers une autre application Là non plus, rien n’est proposé en natif. Il faudra tout développer. Note : 2 Conclusion SPIP fait très bien ce pour quoi il est prévu et semble prévu pour ne rien faire d’autre. Il faut donc l’utiliser dans le contexte pour lequel il est prévu. Il est très peu évolutif mais par contre son architecture logicielle est ouverte et peut être complétée par d’autres applications. Note d’appréciation globale : 3,5 Note moyenne (des critères d’évaluation avec un coefficient de 1 pour chacun) : 2,45

2.2.3. Note finale (adéquation du CMS aux exigences initiales) Voyons, après cette évaluation détaillée ci-dessus des logiciels Interwoven TeamSite Templating 5.5.2 SP2, Microsoft SharePoint Portal Server 2001 et SPIP 1.5.2, un tableau synthétique comparant leurs performances en reprenant la note attribuée pour chaque critère.

Tableau 4 : synthèse de l’évaluation détaillée : no tation et comparaison de trois CMS

Critère d’évaluation Interwoven Microsoft SPPS SPIP

� � � � � � � � � � � � �3,25 3,63 3,63

� � � 4 4 4 � � � � � 3 4 4 � � � � � � � � � � � � � � � 3 3 3 � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 3 3,5 3,5 � � � ! " � � # $ �

3,00 2,44 2,33 � � � � � � � � � % � � & � � � � � � � � � � � 2 4 2,5 ' � � ( ) � � ' 3 3 2

97

Critère d’évaluation Interwoven Microsoft SPPS SPIP

� � � � � � � � � � � � � � � � � � � � � � 3 1 2 � � � � � � � � �3 3 2 � � � � � � � � � �3 0 3 � � � � � � � � � � � � � � � � 3 4 0 � � � � � � � � � � � � � � � � � � � � � � � � � � � � 4 0 3 � � � � � � � � � � � � � � � � � � � � � � � � � � 3 4 3 � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

� � � � � � � � � � � � � � � � � � � � � � � � � 3 3 3,5 � � ! " # � $ % &

3,00 3,40 2,35 � � � � � � � � � � � � 1 3 3,5 � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 4 3 2 ' � � � � � � � � � � � � � � ( � � � � � � � 4 4 3 ' � � � � � � � � � � � � � � ( � � � � ) * � � �3 4 2 ' � � � � � � � � � � � � � �3 3 2 + � � � � � � � � � 3 3 3 , � � - � � � �4 3 2 . � � � � � � �4 3 0 � � � / � � � / � � � � � � � � � � �2 4 3 � � � � � � � � � � � � / � 0 � �2 4 3 1 % � 2 3 4 # � $ % &

2,25 2,25 1,50 � � � � � � � � � � � � � � � � � � � � � � � � � � � � � 5 � � � � � � � � � � � �� 6 � 7 � � 2 1 0 � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � - � � � �� 0 � � � 2 2 2 � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

3 3 2 � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� 2 3 2 8 9 9 4 2 : # � $ % 3 ! $ ; # ! <

3,00 3,00 3,50 = $ > < % % < 3 2 % 2 4 # ! < ? @ 9 4 $ ? @ �2,88 2,93 2,45

Rappelons tout d’abord que la notation a été définie au niveau de la section 2.1.2 page 80. Globalement, une note inférieure à trois signifie que la fonctionnalité attendue n’est pas ou peu développée et que si ce n’est pas le cas, elle n’est pas du niveau attendu par une organisation professionnelle, notamment en terme de productivité, d’ergonomie ou de qualité de l’interface graphique. Une note de trois signifie que la fonctionnalité est présente et a permis de mettre en œuvre les exigences définies au niveau du jeu d’essai. Cependant, cette mise en œuvre n’a pas été aisée et a demandé un travail important, le paramétrage du logiciel pour la fonctionnalité et sa maintenance sont lourds ou encore il a fallu détourner les concepts d’origine. Autrement dit, la mise en œuvre demande un travail de développement et de customisation non négligeable. Finalement une note de 4 signifie que la fonctionnalité est complète, facile à mettre en œuvre et / ou à maintenir. La note de 5 n’a jamais été attribuée ! Comme mentionné dans la section 2.1.2, cette note est un indicateur de la couverture fonctionnelle des besoins. Il s’agit d’une notation de 0 à 5, et si on a la ramène à 100, on obtient un pourcentage de couverture fonctionnelle. Les notes moyennes vont alors d’une couverture de 49 % pour SPIP 1.5.2 a une couverture de 59 % pour MS SharePoint Portal Server 2001. Cela est cohérent avec la première analyse qui consiste à classifier les logiciels de gestion de contenu par domaine d’application (cf. section 1.2.3 et Tableau 3 page 78). Toutefois, le logiciel de la société éditrice Interwoven, qui part au départ avec une couverture fonctionnelle plus grande théoriquement est pénalisé finalement, suite à l’évaluation détaillée (couverture de 58 %), par rapport à MS SPPS à cause d’une mise en œuvre a

98

minima, notamment du point de vue de l’interface graphique et de la stabilité, alors que les fonctionnalités offertes par SPPS sont robustes, fiables et intuitives. L’évaluation détaillée grâce à la mise en œuvre d’un prototype prend alors tout son sens pour valider le choix définitif d’un logiciel dans le cas du logiciel d’Interwoven. On s’aperçoit donc que les résultats de notre évaluation détaillée étaient prévisibles, sauf dans le cas du CMS d’Interwoven, puisque nous avons évalué ces logiciels sur la base d’un jeu d’essai conçu pour éprouver un CMS complet. Un « benchmark » fonctionnel aurait eu plus de sens si chaque logiciel avait été évalué et comparé avec d’autres faisant partie du même domaine d’application de la gestion de contenu sur la base d’un jeu d’essai spécifique à chaque domaine. Les logiciels évalués auraient alors bénéficiés d’une meilleure note, puisque centrée sur les fonctionnalités du domaine qu’il couvre. D’une certaine manière, nous pouvons dire que nous avons comparé des systèmes qui ne sont pas intégralement comparables. Toutefois, l’intérêt de notre démarche a été de mettre en évidence les mécanismes communs à l’ensemble des systèmes de gestion de contenu, que cela soit un logiciel de GED ou un logiciel de Portail d’Information d’Entreprise (EIP). Ces mécanismes doivent tous être mis en œuvre dans le cadre d’une gestion de contenu unifiée. C’était aussi un des buts de l’étude, qui était d’appréhender les différentes facettes de la gestion de contenu et de les maîtriser. De même, cela a permis de voir quelle peut être la richesse offerte par chaque fonctionnalité en terme de prise en compte des différentes situations auxquelles une organisation peut être confrontée. En effet, lorsqu’une fonctionnalité est proposée par au moins deux des logiciels étudiés, nous avons largement pu apprécier le degré d’implémentation de la fonctionnalité, à la fois au niveau du paramétrage et celui de l’utilisation. Les sous-domaines des logiciels finalement les mieux éprouvés ont été ceux qui concernent l’authoring, le groupware (workflow), la gestion des méta données et dans une moindre mesure la transformation et la publication. Enfin d’autres sous-domaines mériteraient une évaluation du même type à part entière. Il s’agit particulièrement de l’édition (intégrée au CMS) de documents et la publication.

99

CONCLUSION Notre travail a permis de faire un tour d’horizon détaillé du domaine de la gestion de contenu. La gestion de contenu est à la fois un terme générique qui recoupe plusieurs domaines d’applications bien déterminés : la Gestion Electronique de Documents (GED), la gestion de site Web (Web Content Management – WCM) et les portails d’information d’entreprise (EIP), voir la gestion des bibliothèques physiques (SIGB – Systèmes de Gestion Intégrés des Bibliothèques) avec les bibliothèques numériques (Digital Libraries). La gestion de contenu est aussi un domaine d’application bien déterminé. On la retrouve sous l’acronyme CMS pour « Content Management System ». Les systèmes de gestion de contenu (CMS) ont pour caractéristique principale de mettre en œuvre le principe de la séparation des données de la mise en forme, impliquant la structuration des documents par type de document (modèle, template), et d’utiliser de manière intensive les méta données, notamment dans les systèmes de gestion de la documentation technique (GEDT), qui ont déjà un historique à leur actif. La généralisation du principe de la séparation du contenu de la mise en forme a été réalisée avec les logiciels de gestion de site web et rend la publication multi-canal possible, c’est à dire la publication sur des supports et des formats variés en maintenant une source de données unique. Cependant, pratiquement, les systèmes de WCM négligent l’utilisation des méta données. L’architecture qui résulte de la prise en compte des différents domaines de la gestion de contenu afin de permettre la gestion unifiée des contenus dans un seul et même système repose sur trois sous-systèmes, le système de collecte, le système de gestion de contenu et le système de publication. Dans cet angle de considération, le système de gestion de contenu est alors principalement un référentiel permettant de gérer toutes les références des documents (principalement les identifiants des documents et les méta données). Concrètement, il est constitué de tous les systèmes de stockage de documents d’une organisation. Cependant, de manière réaliste et dans un but d’efficacité, il est nécessaire d’intégrer les trois sous-systèmes (collecte, référentiel, publication) dans un système homogène, voir unique, afin de pratiquer une gestion de contenu unifiée. La gestion de contenu unifiée prétend pouvoir permettre une gestion des contenus universelle, c’est à dire de gérer tous les contenus d’une organisation dans tous les formats existants en assurant la cohérence et la persistance de l’information. Ce type de gestion de contenu rend possible la réutilisation des composants documentaires et leur intégration dans le système d’information des organisations. Unifier la base d’informations documentaires permet aussi de faciliter la récupération, l’accessibilité, la diffusion, la découverte et le partage des informations. L’ensemble des sous-domaines de la gestion de contenu unifiée a été décrit et illustré dans ce rapport : les concepts, l’architecture, les fonctionnalités et les sous-domaines. Le World Wide Web Consortium est véritablement précurseur dans ce domaine et met à la disposition des utilisateurs des langages et des outils normatifs nécessaires à une mise en œuvre pratique de ces concepts. Notre rapport les a abordés à travers XML, et plus précisément les DTD, les URI mais aussi RDF. Il s’agit toutefois d’un domaine complexe puisqu’il recoupe de nombreux sous-domaines de notre point de vue, mais qui sont par ailleurs des domaines à part entière d’autres points de vue : édition de documents, stockage et archivage, travail collaboratif, gestion documentaire, techniques de publication, personnalisation et recherche d’information (RI). La prise en compte de la sécurité et des obligations légales concernant certains types de document n’est pas triviale non plus. De même, avant de pouvoir gérer tous les documents (notamment ceux édités avant la mise en place d’un CMS unifié) à travers un format pivot unique, il faut prendre en compte une grande diversité de systèmes de gestion de contenu « primitifs » tant dans la dimension des formats d’éditions et de publication (texte, html, pdf, MS Office, flash, données…) que des systèmes (système de gestion de fichier, système de gestion de bases de données, serveurs web, bases de courrier électronique…) mis en œuvre : les compétences nécessaires en intégration de systèmes sont alors importantes. Il y a donc une phase de transition critique entre les modes de gestion de contenus actuels et une gestion de contenu unifiée. Le concept théorique de la gestion de contenu tel que nous le présentons dans notre rapport, à travers notamment la gestion de contenu unifiée, semble complet. Il introduit toutefois une pratique de l’écriture nouvelle et implique un changement profond des organisations dans leurs chaînes d’édition

100

numérique. Aussi pratiquement, on peut dire qu’aujourd’hui, il n’est pas mis en œuvre dans son ensemble. La gestion de contenu unifiée est mise en œuvre partiellement dans les différents domaines d’application de la gestion de contenu que nous avons décrits. La classification des logiciels du marché de la gestion de contenu que nous avons réalisée le montre. De même, notre évaluation détaillée des logiciels met en évidence une couverture fonctionnelle partielle de la gestion de contenu unifiée. Celle-ci montre que dans le meilleur des cas, les logiciels ne permettent de mettre en œuvre que moins des deux tiers des fonctionnalités qui seraient nécessaires. Dans le même ordre d’idée, on peut dire que la gestion des méta données, qui est centrale, dans le concept de gestion de contenu, est toujours partielle. Nous avons vu quelles sont les méta données nécessaires et les mécanismes (dénomination unique et partagée, vocabulaire contrôlé à partir de thésaurus ou de dictionnaires) à mettre en œuvre pour que les méta données puissent rendre le service intégral que l’utilisateur peut attendre d’elles. Ces principes ne peuvent pas actuellement être mis en œuvre dans la plupart des logiciels. De plus, l’édition des méta données est un des freins à leur adoption et plus loin à l’adoption des CMS dans le sens où cela peut représenter un travail rédhibitoire. Aussi, il manque aussi aux logiciels de gestion de contenu contemporains l’intégration d’outils de productivité dans ce domaine. Des traitements automatiques de génération de méta données existent : extraction automatique de méta données (mots clés), catégorisation automatique de documents, résumé automatiques. Mais leurs résultats ne sont le plus souvent pas entièrement fiables. Il faut donc qu’ils soient associés à une partie humaine. Or ils sont très rarement associés à une validation humaine dans une chaîne d’édition numérique. Les méta données (relations) associées à la réutilisation des composants documentaires ne sont pas non plus prises en compte de manière automatique. Peu, sinon aucune, de fonctionnalités liées à la réutilisation sont proposées par les logiciels de gestion de contenu. Enfin, la plupart du temps, les méta données sont disséminées dans des référentiels différents : les méta données d’application et une partie des méta données de gestion documentaires comme variables systèmes, d’une part, et les autres, comme méta données « utilisateurs », c’est à dire accessible par l’utilisateur, d’autre part. Les éditeurs de documents, intégrés aux suites logicielles de gestion de contenu, proposant toutes les fonctionnalités que nous avons décrites dans la section sur ce sujet, sont aussi rares. Nous pouvons donc raisonnablement dire que les éditeurs de logiciels ont encore à fournir un certain travail avant de proposer des logiciels de CMS plus complets et plus productifs. Il s’agit là très certainement de la prochaine étape avant une application plus large de la théorie de la gestion de contenu unifiée. L’attitude la meilleure des utilisateurs et des organisations face à cette situation est l’attentisme. Si un besoin spécifique et départemental existe, alors un logiciel du domaine de la gestion de contenu en question peut être choisi. La grille de classification fonctionnelle que nous proposons peut alors être utile. Cependant, l’attention devra être portée sur l’évolutivité de la solution pour qu’elle puisse ensuite éventuellement être étendue à une gestion de contenu universelle sans coût d’adaptation (migration) excessif.

101

ANNEXES

1. Schémas de classes de documents

1.1. Exemple du QCM

-question : String-commentaire : String

Question

-reponse : String-commentaire : String-estCorrecte : bool-note : Integer

Reponse

-EstComposeDe 1

-RepondA 2..10

-titre : String-catégorie : String

Chapitre

-Contient 1

-Compose 1..*

+derniereVersion() : QCM

-titre : String-enTeteModeEmploi : String-enTeteDescription : String-piedQCMModeEmploi : String-piedQCMCommentaire : String-dateCreation : Date-dateDerniereModification : Date-version : Integer-auteur : String-valideePar : String-categorie : String

QCM

-Contient 1

-Compose 1..*

-titre : String-description : String-piedDeGrille : String

GrilleEvaluation

-titre : String-corpsDeTexte : String

SectionGrille

-Contient

1

-Compose 0..1

-Contient 1

-Compose 1..*

1.2. Exemple du contrat de commande de QCM

102

-titre : String-description : String-categorie : String-type : String-audience : String-langue : String-couvertureSpatiale : String-couvertureTemporelle : String-sujetMotsCle : String-lancementDate : Date-expirationDate : Date

MetaDonnee

-enTeteObjet : String-objet : Specification-beneficiaire : Client-maitriseOeuvre : String-signatureDate : Date-livraisonDate : Date-paiementDate : Date-paiementMontant : int-paiementTypeReglement : String-clause : String

Contrats

QCM

+insereTitre() : String+nbChapitreOK() : bool+nbSectionGrilleOK() : bool+nbQuestionOK() : bool+nbReponseOK() : bool

Specification

+selectionnerThemeDefini() : SpecificationPublication+definirPoliceCaractereElementQCM()+definirCouleurElementQCM()

-formatPublication : String-logo : String-images : String-couleurs : String-policesCaractere : String

SpecificationPublication

+insereTitre() : String

-nbQuestion : int-nbReponse : int

SpecificationChapitre

+insereTitre() : String+insereDescription() : String+inserePiedDeGrille() : String

SpecificationSectionGrille

-nom : String-raisonSociale : String-adresse : String

Client

-metaDonnees : MetaDonnee

specificationMetaDonnee

-estSignePar1

-signe1..*

-compose1

-contient

1..*

-contient1

-compose1

-contient 1

-compose 1 -compose1

-contient1..*

-1

-contient0..*

-definit

1

-estDefiniPar1

-estDecritPar1

-decrit1

-

1

-specifie

1

Le format de publication contenu dans les spécifications de la publication peut prendre les valeurs suivantes : html, pdf, wap, pda, papier.Noter que les méta données décrivent tous les types de documents ; ici : les contrats et les QCM.Rappel - le type dans les méta données peut prendre les valeurs suivantes :- "boutons radios", "cases à cocher", "boutons radios avec grille evaluation", "cases à cocher avec grille evaluation" pour les QCM,- "creation et publication sur mesure", "creation sur mesure et publication standard (theme graphique pre-defini)","creation standard (données catalogues) et publication sur mesure", "QCM catalogue" pour les contrats.

-nombresExemplaires : int-qualitePapier : String

SpecificationPublicationPapier

-decrit

1

-estDecritPar

1

103

2. Définition de Type de Document (XML)

2.1. Exemple de DTD du QCM (QCM.dtd) <?xml version="1.0" encoding="UTF-8"?>  <!ELEMENT QCM (titre, enTeteModeEmploi?, enTeteDesc ription?, piedQCMModeEmploi?, piedQCMCommentaire?, dateCreation, dateDerniereModi fication, version, auteur+, valideePar+, categorie*, chapitre+, grilleEvaluatio n?)> <!ELEMENT titre (#PCDATA)> <!ELEMENT enTeteModeEmploi (#PCDATA)> <!ELEMENT enTeteDescription (#PCDATA)> <!ELEMENT piedQCMModeEmploi (#PCDATA)> <!ELEMENT piedQCMCommentaire (#PCDATA)> <!ELEMENT dateCreation (#PCDATA)> <!ELEMENT dateDerniereModification (#PCDATA)> <!ELEMENT version (#PCDATA)> <!ELEMENT auteur (#PCDATA)> <!ELEMENT valideePar (#PCDATA)> <!ELEMENT categorie (#PCDATA)> <!ELEMENT chapitre (titre?, categorie*, question+)> <!ELEMENT question (questionLibelle, questionCommen taire?, reponse+)> <!ELEMENT questionLibelle (#PCDATA)> <!ELEMENT questionCommentaire (#PCDATA)> <!ELEMENT reponse (reponseLibelle, reponseCommentai re?)> <!ELEMENT reponseLibelle (#PCDATA)> <!ELEMENT reponseCommentaire (#PCDATA)> <!ATTLIST reponse estCorrecte (vrai | faux) #REQUIRED note NMTOKEN #IMPLIED > <!ATTLIST categorie code NMTOKEN #IMPLIED > <!ELEMENT grilleEvaluation (titre, grilleDescriptio n?, piedDeGrille?, sectionGrille+)> <!ELEMENT grilleDescription (#PCDATA)> <!ELEMENT piedDeGrille (#PCDATA)> <!ELEMENT sectionGrille (titre?, corpsDeTexte)> <!ELEMENT corpsDeTexte (#PCDATA)>

2.2. Exemple du Schéma XML du QCM (QCM.xsd) <?xml version="1.0" encoding="UTF-8"?>  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSche ma" elementFormDefault="qualified"> <xs:element name="QCM"> <xs:complexType> <xs:sequence> <xs:element ref="titre"/> <xs:element ref="enTeteModeEmploi" minOccurs="0 "/> <xs:element ref="enTeteDescription" minOccurs=" 0"/> <xs:element ref="piedQCMModeEmploi" minOccurs=" 0"/> <xs:element ref="piedQCMCommentaire" minOccurs= "0"/>

104

<xs:element ref="dateCreation"/> <xs:element ref="dateDerniereModification"/> <xs:element ref="version"/> <xs:element ref="auteur" maxOccurs="unbounded"/ > <xs:element ref="valideePar" maxOccurs="unbound ed"/> <xs:element ref="categorie" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="chapitre" type="chapitreType" maxOccurs="unbounded"/> <xs:element name="grilleEvaluation" type="grilleEvaluationType" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="auteur" type="xs:string"/> <xs:element name="categorie"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="code" type="xs:integer" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:complexType name="chapitreType"> <xs:sequence> <xs:element ref="titre" minOccurs="0"/> <xs:element ref="categorie" minOccurs="0" maxOcc urs="unbounded"/> <xs:element name="question" type="questionType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:element name="corpsDeTexte" type="xs:string"/> <xs:element name="dateCreation" type="xs:dateTime" /> <xs:element name="dateDerniereModification" type=" xs:dateTime"/> <xs:element name="enTeteDescription" type="xs:stri ng"/> <xs:element name="enTeteModeEmploi" type="xs:strin g"/> <xs:element name="grilleDescription" type="xs:stri ng"/> <xs:complexType name="grilleEvaluationType"> <xs:sequence> <xs:element ref="titre"/> <xs:element ref="grilleDescription" minOccurs="0 "/> <xs:element ref="piedDeGrille" minOccurs="0"/> <xs:element name="sectionGrille" type="sectionGr illeType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:element name="piedDeGrille" type="xs:string"/> <xs:element name="piedQCMCommentaire" type="xs:str ing"/> <xs:element name="piedQCMModeEmploi" type="xs:stri ng"/> <xs:complexType name="questionType"> <xs:sequence> <xs:element ref="questionLibelle"/> <xs:element ref="questionCommentaire" minOccurs= "0"/> <xs:element name="reponse" type="reponseType" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:element name="questionCommentaire" type="xs:st ring"/> <xs:element name="questionLibelle" type="xs:string "/> <xs:complexType name="reponseType"> <xs:sequence>

105

<xs:element ref="reponseLibelle"/> <xs:element ref="reponseCommentaire" minOccurs=" 0"/> </xs:sequence> <xs:attribute name="estCorrecte" type="xs:boolean " use="required"/> <xs:attribute name="note" type="xs:positiveIntege r" use="optional"/> </xs:complexType> <xs:element name="reponseCommentaire" type="xs:str ing"/> <xs:element name="reponseLibelle" type="xs:string" /> <xs:complexType name="sectionGrilleType"> <xs:sequence> <xs:element ref="titre"/> <xs:element ref="corpsDeTexte"/> </xs:sequence> </xs:complexType> <xs:element name="titre" type="xs:string"/> <xs:element name="valideePar" type="xs:string"/> <xs:element name="version" type="xs:positiveIntege r"/> </xs:schema>

2.3. Exemple de DTD du contrat (contrat.dtd) <?xml version="1.0" encoding="UTF-8"?>  <!ELEMENT contrat (enTeteObjet, objet+, beneficiair e, maitriseOeuvre, signatureDate, livraisonDate, paiementDate, paiementMontant, paiem entTypeReglement, clause*)> <!ELEMENT enTeteObjet (#PCDATA)> <!ELEMENT objet (specificationMetaDonnee, specifica tionChapitre+, specificationSectionGrille*, specificationPublicati on)> <!ATTLIST objet idSpecification ID #REQUIRED idQCM IDREF #IMPLIED > <!ELEMENT specificationMetaDonnee (titre, descripti on, categorie, type, audience?, langue, couvertureSpatiale?, couvertureTemporelle?, sujetMotsCle?, lancementDate?, expirationDate?)> <!ATTLIST specificationMetaDonnee idMetaDonnee ID #REQUIRED > <!ELEMENT titre (#PCDATA)> <!ELEMENT description (#PCDATA)> <!ELEMENT categorie (#PCDATA)> <!ATTLIST categorie idCategorie IDREFS #REQUIRED > <!ELEMENT type (#PCDATA)> <!ELEMENT audience (#PCDATA)> <!ELEMENT langue (#PCDATA)> <!ELEMENT couvertureSpatiale (#PCDATA)> <!ELEMENT couvertureTemporelle (#PCDATA)> <!ELEMENT sujetMotsCle (#PCDATA)> <!ELEMENT lancementDate (#PCDATA)> <!ELEMENT expirationDate (#PCDATA)> <!ELEMENT specificationChapitre (nbQuestion, nbRepo nse)> <!ELEMENT nbQuestion (#PCDATA)> <!ELEMENT nbReponse (#PCDATA)> <!ELEMENT specificationSectionGrille (titre, descri ption, piedDeGrille)> <!ELEMENT piedDeGrille (#PCDATA)> <!ELEMENT specificationPublication (formatPublicati on, logo?, images*, couleurs, policesCaractere, nombreExemplaires, qualitePapier) > <!ELEMENT formatPublication (#PCDATA)> <!ELEMENT logo (#PCDATA)>

106

<!ELEMENT images (#PCDATA)> <!ELEMENT couleurs (#PCDATA)> <!ELEMENT policesCaractere (#PCDATA)> <!ELEMENT nombreExemplaires (#PCDATA)> <!ELEMENT qualitePapier (#PCDATA)> <!ELEMENT beneficiaire (nom, raisonSociale?, adress e)> <!ATTLIST beneficiaire idClient IDREF #REQUIRED > <!ELEMENT nom (#PCDATA)> <!ELEMENT raisonSociale (#PCDATA)> <!ELEMENT adresse (#PCDATA)> <!ELEMENT maitriseOeuvre (#PCDATA)> <!ELEMENT signatureDate (#PCDATA)> <!ELEMENT livraisonDate (#PCDATA)> <!ELEMENT paiementDate (#PCDATA)> <!ELEMENT paiementMontant (#PCDATA)> <!ELEMENT paiementTypeReglement (#PCDATA)> <!ELEMENT clause (#PCDATA)>

2.4. Exemple de QCM simple conforme au schéma QCM.x sd <?xml version="1.0" encoding="UTF-8"?>  <QCM xmlns:xsi="http://www.w3.org/2001/XMLSchema-in stance" xsi:noNamespaceSchemaLocation="D:\Stage\Benchmark\Q CM.xsd"> <titre>Le hardware du PC</titre> <enTeteModeEmploi>Ce QCM est composÃ© de 10 questi ons avec Ã chaque fois trois rÃ©ponses possibles dont une seule est la bon ne</enTeteModeEmploi> <enTeteDescription>Bon courage</enTeteDescription> <piedQCMModeEmploi>VÃ©rifiez maintenant quelles so nt les bonnes rÃ©ponses aux questions et calculez vous mÃªme votre score !</pie dQCMModeEmploi> <dateCreation>2001-12-17T09:30:47-05:00</dateCreat ion> <dateDerniereModification>2001-12-17T09:30:47-05:0 0</dateDerniereModification> <version>2</version> <auteur>Formateur informatique personnelle</auteur > <auteur>Responsable pÃ´le formation</auteur> <valideePar>Responsable pÃ´le formation</valideePa r> <categorie code="6130">Ordinateur</categorie> <chapitre> <titre>Le hardware du PC</titre> <categorie code="6130">Ordinateur</categorie> <question> <questionLibelle>Quel est l'Ã©lement princi pal d'un PC</questionLibelle> <reponse estCorrecte="false"> <reponseLibelle>La carte graphique</reponseLibe lle> </reponse> <reponse estCorrecte="false"> <reponseLibelle>La carte son</reponseLibelle> </reponse> <reponse estCorrecte="true"> <reponseLibelle>Le processeur</reponseLibelle> </reponse> </question> <question> <questionLibelle>Quel est l'Ã©lement princi pal d'un PC</questionLibelle> <reponse estCorrecte="false"> <reponseLibelle>La carte graphique</reponseLibe lle> </reponse>

107

<reponse estCorrecte="false"> <reponseLibelle>La carte son</reponseLibelle> </reponse> <reponse estCorrecte="true"> <reponseLibelle>Le processeur</reponseLibelle> </reponse> </question> <question> <questionLibelle>Quel est le pÃ©riphÃ©rique d'entrÃ©e</questionLibelle> <reponse estCorrecte="true"> <reponseLibelle>Webcam</reponseLibelle> </reponse> <reponse estCorrecte="false"> <reponseLibelle>Modem</reponseLibelle> </reponse> <reponse estCorrecte="false"> <reponseLibelle>Imprimante</reponseLibelle> </reponse> </question> <question> <questionLibelle>Quel composant ne trouve t&apos ;on plus sur une carte mÃ¨re rÃ©cente</questionLibelle> <reponse estCorrecte="false"> <reponseLibelle>SRAM</reponseLibelle> </reponse> <reponse estCorrecte="false"> <reponseLibelle>DRAM</reponseLibelle> </reponse> <reponse estCorrecte="true"> <reponseLibelle>EPROM</reponseLibelle> </reponse> </question> <question> <questionLibelle>Quel phÃ©nomÃ¨ne peut amener au dÃ©cÃ¨s prÃ©maturÃ© d'un processeur suite Ã un overcl ocking</questionLibelle> <reponse estCorrecte="true"> <reponseLibelle>Migration Ã©lectronique</repons eLibelle> </reponse> <reponse estCorrecte="false"> <reponseLibelle>Fixation Ã©lectronique</reponse Libelle> </reponse> <reponse estCorrecte="false"> <reponseLibelle>Divergence Ã©lectronique</repon seLibelle> </reponse> </question> <question> <questionLibelle>A quoi correspond le nombre de megahertz de l'ordinateur ?</questionLibelle> <reponse estCorrecte="true"> <reponseLibelle>La vitesse du processeur</repon seLibelle> </reponse> <reponse estCorrecte="false"> <reponseLibelle>La quantitÃ© de mÃ©moire</repon seLibelle> </reponse> <reponse estCorrecte="false"> <reponseLibelle>La vitesse de connexion internet</reponseLibelle> </reponse>

108

</question> <question> <questionLibelle>De quel type d'alimentation les PC sont-ils gÃ©nÃ©ralement Ã©quipÃ©</questionLibelle> <questionCommentaire>L'alimentation Ã dÃ©coupag e offre les avantages du poids, de la taille, de la puissance e t du prix. Elles sont cependant gÃ©nÃ©ralement source de parasites plus importants que les alimentations traditionnelles ?</questionCommentaire> <reponse estCorrecte="false"> <reponseLibelle>A doubleurs de tension</reponse Libelle> </reponse> <reponse estCorrecte="false"> <reponseLibelle>A point de diodes</reponseLibel le> </reponse> <reponse estCorrecte="true"> <reponseLibelle>A dÃ©coupage</reponseLibelle> </reponse> </question> <question> <questionLibelle>Quel niveau de tension peut-on trouver sur les connecteurs d'alimentation continue Ã l'intÃ© rieur d'un PC ?</questionLibelle> <questionCommentaire>Les deux tensions disponibl es sont 5 V et 12 V</questionCommentaire> <reponse estCorrecte="false"> <reponseLibelle>5 V et 10 V</reponseLibelle> </reponse> <reponse estCorrecte="true"> <reponseLibelle>5 V et 12 V</reponseLibelle> </reponse> <reponse estCorrecte="false"> <reponseLibelle>12 V et 20 V</reponseLibelle> </reponse> </question> <question> <questionLibelle>Quels sont les niveaux de tensi on d'une interface rs232 ?</questionLibelle> <questionCommentaire>Les niveaux de tensions rs2 32 sont +12V/-12 V</questionCommentaire> <reponse estCorrecte="false"> <reponseLibelle>0V/+5V</reponseLibelle> </reponse> <reponse estCorrecte="false"> <reponseLibelle>+5V/-5V</reponseLibelle> </reponse> <reponse estCorrecte="true"> <reponseLibelle>12V/-12V</reponseLibelle> </reponse> </question> <question> <questionLibelle>Quelle tension est prÃ©sente au x broches d'entree/sortie du processeur Pentium III TM ? </questionLibelle> <reponse estCorrecte="false"> <reponseLibelle>1.1 volt</reponseLibelle> </reponse> <reponse estCorrecte="true"> <reponseLibelle>3.3 volt</reponseLibelle> </reponse> <reponse estCorrecte="false"> <reponseLibelle>5.5 volt</reponseLibelle>

109

</reponse> </question> <question> <questionLibelle>De quelle puissance Ã©lectrique un PC traditionnel a-t-il besoin ?</questionLibelle> <reponse estCorrecte="true"> <reponseLibelle>300 watt</reponseLibelle> </reponse> <reponse estCorrecte="false"> <reponseLibelle>2200 watt</reponseLibelle> </reponse> <reponse estCorrecte="false"> <reponseLibelle>6000 watt</reponseLibelle> </reponse> </question> </chapitre> </QCM>

3. Méta données de Dublin Core

tableau 5 : « méta données de l’initiative de Dubli n Core »

Elément Sous-

propriété de (Sous-

élément de)

Définition / Commentaire 78 Identifiant élément 79

Titre Le nom donné à la ressource Title Alternative Titre Substitut, alternative (traduction, sous-titre…) au

nom donné à la ressource alternative

Sujet et mots-clefs

Le sujet du contenu de la ressource. La meilleure pratique est de retenir le sujet provenant d’une classification formelle (ex.UDC).

Subject

Source Une référence à une ressource à partir de laquelle la ressource actuelle a été dérivée

Source

Description Une description du contenu de la ressource description Table des matières

Description TOC tableOfContents

Résumé Description Résumé du contenu de la resource Abstract Type La nature ou le genre du contenu de la resource

(valeurs possibles - DCMI type80 - : InteractiveResource, Event, Service, Image, Text, Software, Sound, PhysicalObject, Dataset, Collection).

Type

Couverture La portée ou la couverture spatio-temporelle de la ressource. La couverture typiquement inclut une position géographique (le nom d'un lieu ou ses coordonnées), une période de temps (un nom de période, une date, ou un intervalle de temps) ou une juridiction (telle que le nom d'une entité administrative). Il est recommandé de choisir la valeur de Couverture dans un vocabulaire contrôlé

Coverage

78 La description et le commentaire sont en anglais (en-US) lorsqu’il n’y pas de traduction reconnue par le DCMI. 79 L’identifiant n’est pas repris lorsque le nom de l’élément correspondant est identique. 80 http://dublincore.org/schemas/xmls/qdc/2003/04/02/dcmitype.xsd ou http://purl.org/dc/dcmitype/

110

Elément Sous-propriété de

(Sous-élément de)


(par exemple, un thésaurus de noms géographiques, comme[TGN81]) et, quand cela est approprié, des noms de lieux ou de périodes plutôt que des identifiants numériques tels que des coordonnées ou des intervalles de dates.

Spatial Couverture Position géographique… Spatial Temporel Couverture Période concernée… Temporal Relation Une référence à une autre ressource qui a un

rapport avec cette ressource Relation

HasVersion Relation The described resource has a version, edition, or adaptation, namely, the referenced resource

IsVersionOf Relation The described resource is a version, edition, or adaptation of the referenced resource. Changes in version imply substantive changes in content rather than differences in format

HasPart Relation The described resource includes the referenced resource either physically or logically

IsPartOf Relation The described resource is a physical or logical part of the referenced resource

Replaces Relation The described resource supplants, displaces, or supersedes the referenced resource

IsReplacedBy Relation The described resource is supplanted, displaced, or superseded by the referenced resource

Requires Relation The described resource requires the referenced resource to support its function, delivery, or coherence of content

IsRequiredBy Relation The described resource is required by the referenced resource, either physically or logically

HasFormat Relation The described resource pre-existed the referenced resource, which is essentially the same intellectual content presented in another format

IsFormatOf Relation The described resource is the same intellectual content of the referenced resource, but presented in another format

References Relation The described resource references, cites, or otherwise points to the referenced resource

isReferencedBy

Relation The described resource is referenced, cited, or otherwise pointed to by the referenced resource

ConformsTo Relation A reference to an established standard to which the resource conforms

Créateur L’entité principalement responsable de la création du contenu de la ressource (une personne, une organisation, un service)

Creator

Editeur L'entité responsable de la diffusion de la ressource, dans sa forme actuelle, tels, un département universitaire, une entreprise

publisher

Contributeur Une entité qui a contribué à la création du contenu de la ressource

Contributor

Gestion des droits

Information sur les droits sur et au sujet de la ressource…

Rights

Date Une date associée avec un événement dans le cycle de vie de la ressource. Typiquement, une date sera associée à la création ou à la publication d'une ressource. Il est fortement recommandé d'encoder la valeur de la date en utilisant le format défini par l'ISO 8601 [W3CDTF] sous la forme AAAA-MM-JJ

81 TGN : Getty Thesaurus of Geographic Names (http://www.getty.edu/research/tools/vocabulary/tgn/)

111


(Sous-élément de)


Created Date Date of creation of the resource Modified Date Date on which the resource was changed DateSubmitted Date In approval process, date of submission for approval DateAccepted Date In approval process, date of acceptation DateCopyrighted Date Date (often a range) that the resource will become or

did become copyrighted

Issued Date Date of formal issuance (e.g., publication) of the resource

Available Date Date (often a range) that the resource will become or did become available

Valid Date Date (often a range) of validity of a resource Format La matérialisation physique ou digitale de la

ressource. Typiquement, Format peut inclure le media ou les dimensions de la ressource. Format peut être utilisé pour préciser le logiciel, le matériel ou autre équipement nécessaire pour afficher ou faire fonctionner la ressource. Exemples de dimensions incluent la taille et la durée. Il est recommandé de choisir la valeur du format dans une liste de vocabulaire contrôlé (par exemple, la liste des types de media définis sur Internet [MIME]82).

Extent Format The size or duration of the resource Medium format The material or physical carrier of the resource Identifiant Identifiant de la ressource : une référence non

ambiguë à la ressource dans un contexte donné. Il est recommandé d'identifier la ressource par une chaîne de caractère ou un nombre conforme à un système formel d'identification. Exemples de systemes formels d'identification incluent le "Uniform Resource Identifier" (URI) (qui inclut le "Uniform Resource Locator" (URL)), le "Digital Object Identifier"(DOI) et le "International Standard Book Number"(ISBN).

Identifier

Citation bibliographique

Identifier A bibliographic reference for the resource. Recommended practice is to include sufficient bibliographic detail to identify the resource as unambiguously as possible, whether or not the citation is in a standard form.

bibliographicCitation

Langue La langue du contenu intellectuel de la ressource. Il est recommandé d'utiliser comme valeur de l'élément Langue celles definies par la RFC 1766 [RFC1766] qui comprend un code de langage � deux caract� res(venant du standard ISO 639 [ISO639]), éventuellement suivi d'un code � deux lettres pour le pays (venant du standard ISO 3166 [ISO3166] ou en français [ISO3166]). Par exemple, 'en' pour l'anglais, 'fr' pour le français, ou 'en-uk' pour l'anglais utilisé au Royaume-Uni.

Language

Public A class of entity for whom the resource is intended or useful. A class of entity may be determined by the creator or the publisher or by a third party.

Audience

Médiateur Audience A class of entity that mediates access to the resource and for whom the resource is intended or useful. The audiences for a resource are of two basic classes: (1) an ultimate beneficiary of the resource, and (2) frequently, an entity that mediates

Mediator

82 MIME Internet Media Types : http://www.isi.edu/in-notes/iana/assignments/media-types/media-types

112


(Sous-élément de)


access to the resource. The mediator element refinement represents the second of these two classes.

Niveau académique

Audience A general statement describing the education or training context. Alternatively, a more specific statement of the location of the audience in terms of its progression through an education or training context.

educationLevel

4. Ressource Description Framework

4.1. Récapitulatif du vocabulaire utilisé dans RDF Ci-dessous sont présentés deux tableaux qui donnent une vue générale du vocabulaire de RDF, reliant le vocabulaire originellement défini dans la spécification de la syntaxe et du modèle RDF avec les classes et les propriétés qui ont leur origine dans le schéma RDF [84].

Tableau 6 : Classes RDF

Nom de la classe Commentaire

rdfs:Resource La classe Resource, tout.rdfs:Literal La classe des valeurs littérales, c’est à dire des chaînes

caractères et les entiers.rdf:XMLLiteral La classe des valeurs littérales permises par XML.rdfs:Class La classe des classes.rdf:Property La classe des propriétés RDFrdfs:Datatype La classe des types de données RDF.rdf:Statement La classe des déclarations RDF.rdf:Bag La classe des containeurs non ordonnés.rdf:Seq La classe des containeurs ordonnés.rdf:Alt La classe des containeurs d’alternatives.rdfs:Container La super classe des containeurs.rdfs:ContainerMembershipProperty La classe des propriétés des membres des containeurs , rdf:_1,

rdf:_2, ..., dont tous sont des sous-propriétés de ‘member’.rdf:List La classe des listes RDF.

Tableau 7 : Propriétés RDF

Nom de la propriétés

Commentaire domain range

rdf:type Le sujet (la ressource) est une instance d’une classe

rdfs:Resource rdfs:Class

rdfs:subClassOf Le sujet est une sous-classe d’une classe. rdfs:Class rdfs:Classrdfs:subPropertyOf Le sujet est une sous-propriétés d’une propriété. rdf:Property rdf:Propertyrdfs:domain Le domaine des ressources s’appliquant à une

ressource. (A domain of the subject property.)rdf:Property rdfs:Class

rdfs:range Le domaine des ressources s’appliquant à une propriété. (A range of the subject property.)

rdf:Property rdfs:Class

rdfs:label Le nom lisible par un humain du sujet (la rdfs:Resource rdfs:Literal

113

Nom de la propriétés

Commentaire domain range

ressource).rdfs:comment Une description du sujet (ressource). rdfs:Resource rdfs:Literalrdfs:member Un membre de la ressource. (A member of the

subject resource.)rdfs:Resource rdfs:Resource

rdf:first Le premier article d’une liste RDF de sujet. (The first item in the subject RDF list.)

rdf:List rdfs:Resource

rdf:rest Le reste des articles d’une liste RDF de sujet après le premier article. (The rest of the subject RDF list after the first item.)

rdf:List rdf:List

rdfs:seeAlso Information complémentaire sur le sujet. rdfs:Resource rdfs:Resourcerdfs:isDefinedBy La definition du sujet. rdfs:Resource rdfs:Resourcerdf:value Propriété idiomatique utilisée pour déclarer des

valeurs structurées (i.e. typées).rdfs:Resource rdfs:Resource

rdf:subject Le sujet d’une déclaration (statement) RDF rdf:Statement rdfs:Resourcerdf:predicate Le prédicat d’une déclaration (statement) RDF rdf:Statement rdf:Propertyrdf:object L’objet d’une déclaration (statement) RDF rdf:Statement rdfs:Resource En addition à ces classes et propriétés, RDF utilise aussi les propriétés nommées rdf:_1, rdf:_2, rdf:_3... etc., chacune d’elle étant une sous-propriétés de rdfs:member et une instance de la classe rdfs:ContainerMembershipProperty. Il y a aussi une instance de la classe rdf:List appelée rdf:nil qui est une liste rdf:List vide.

4.2. Exemple d’extension de Schéma RDFS L’exemple ci-dessous déclare principalement une méta données supplémentaire (le type de QCM) spécifique aux QCM de l’entreprise MCQ. <?xml version="1.0" encoding="ISO-8859-1"?> <rdf:RDF xmlns:dcterms="http://purl.org/dc/terms/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax- ns#" xmlns:mcq="http://www.mcq.com/rdf-schema#> <rdf:Description rdf:about="http://www.mcq.com/rdf- schema"> <dc:title xml:lang="fr-FR">Le domaine nominal et le contenu du schéma de méta données RDF de l'entreprise MCQ.</dc:title> <dc:publisher xml:lang="fr-FR">MCQ</dc:publisher> <dc:description xml:lang="fr-FR">Les méta données M CQ s'adossent sur celle définies par le groupe de Dublin Core. Toutefois, certaines méta données sont spécifiques à nos applications de QCM</dc:description> <dc:language xml:lang="fr-FR">Français</dc:language > <dcterms:issued>2003-07-11</dcterms:issued> <dcterms:modified>2003-10-24</dcterms:modified> </rdf:Description> <rdf:Property rdf:about="http://www.mcq.com/rdf-sch ema#typeDeQCM"> <rdfs:label xml:lang="fr-FR">Type de QCM</rdfs:labe l> <dc:description xml:lang="fr- FR">Les QCM ont plusieurs formes : réponse vraie un ique (bouton radio), réponse vraie multiple (cases à coc her), avec une grille d'évaluation associée à la note obtenue ou non</dc: description> <rdfs:subPropertyOf rdf:resource="http://purl.org/d c/elements/1.1/type"/> <rdfs:range rdf:resource="http://purl.org/dc/dcmity pe/Text> <dcterms:issued>2003-07-11</dcterms:issued> <dcterms:modified>2003-10-24</dcterms:modified> </rdf:property>

114

<dcterms:SubjectScheme rdf:about="http://www.mcq.co m/rdf-schema#classement"> <rdfs:label xml:lang="fr-FR">Catégorie</rdfs:label> <rdfs:comment xml:lang="fr- FR">Système de classification de la documentation i nterne de MCQ</rdfs:comment> <rdf:type rdf:resource="http://www.w3.org/2000/01/r df-schema#Class"/> <dc:source rdf:resource="http://www.mcq.com/specifi cations"/> <dcterms:issued>2003-07-11</dcterms:issued> <dcterms:modified>2003-10-24</dcterms:modified> <dc:type rdf:resource="http://dublincore.org/usage/ documents/principles/#encoding-scheme"/> </dcterms:SubjectScheme> </rdf:RDF>

4.3. Exemple d’utilisation du schéma : méta données au format RDF Ces méta données s’appliquent au fichier qcm139746.xml dont le contenu est repris dans l’annexe 2.4. <?xml version='1.0' encoding='ISO-8859-1'?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22- rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/"" xmlns:mcq="http://www.mcq.com/rdf-schema#"> <rdf:Description rdf:about="http://www.mcq.com/ QCM/qcm139746.xml"> <dc:creator>Formateur informatique personnell e</dc:creator> <dc:subject><mcq:classement>6130</mcq:classem ent></dc:subject> <dc:contributor>Responsable pole formation</d c:contributor> <dc:title>Le hardware du PC</dc:title> <dc:language>fr-FR</dc:language> <dc:type>text</dc:type> <mcq:typeDeQCM>bouton radio simple<mcq:typeDe QCM> <dc:description>QCM simple de dix questions p ortant sur le hardware du PC</dc:description> <dc:date>20011217</dc:date> <dc:publisher>MCQ</dc:publisher> <dc:rights>copyrights MCQ</dc:rights> <dc:format>text/application</dc:format> </rdf:Description> </rdf:RDF>

5. RDF Site Summary (RSS)

5.1. Schéma RDF des documents RSS <?xml version="1.0" ?> <!-- RDF Schema declaration for Rich Site Summary (RSS) 1.0 <http://purl.org/rss/1.0/> note: This schema currently is defining RSS-specifi c constructs (resource and relationship types) only. No contrain ts have been introduced. Note: this schema is represented in the RDF M&S abb reviated syntax <http://www.w3.org/TR/REC-rdf-syntax/#abbrev iatedSyntax> for syntactic inclusion in an HTML/XHTML document

115

--> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rd f-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:dc="http://purl.org/dc/elements/1.1/">  <rdfs:Class rdf:about="http://purl.org/rss/1.0/chan nel" rdfs:label="Channel" rdfs:comment="An RSS information channel."> <rdfs:isDefinedBy rdf:resource="http://purl.org/r ss/1.0/" /> </rdfs:Class> <rdfs:Class rdf:about="http://purl.org/rss/1.0/imag e" rdfs:label="Image" rdfs:comment="An RSS image."> <rdfs:isDefinedBy rdf:resource="http://purl.org/r ss/1.0/" /> </rdfs:Class> <rdfs:Class rdf:about="http://purl.org/rss/1.0/item " rdfs:label="Item" rdfs:comment="An RSS item."> <rdfs:isDefinedBy rdf:resource="http://purl.org/r ss/1.0/" /> </rdfs:Class> <rdfs:Class rdf:about="http://purl.org/rss/1.0/text input" rdfs:label="Text Input" rdfs:comment="An RSS text input."> <rdfs:isDefinedBy rdf:resource="http://purl.org/r ss/1.0/" /> </rdfs:Class>  <rdf:Property rdf:about="http://purl.org/rss/1.0/it ems" rdfs:label="Items" rdfs:comment="Points to a list of rss:item elements that are members of the subject channel."> <rdfs:isDefinedBy rdf:resource="http://purl.org/r ss/1.0/" /> </rdf:Property> <rdf:Property rdf:about="http://purl.org/rss/1.0/ti tle" rdfs:label="Title" rdfs:comment="A descriptive title for the channel." > <rdfs:subPropertyOf rdf:resource="http://purl.org /dc/elements/1.1/title" /> <rdfs:isDefinedBy rdf:resource="http://purl.org/r ss/1.0/" /> </rdf:Property> <rdf:Property rdf:about="http://purl.org/rss/1.0/li nk" rdfs:label="Link" rdfs:comment="The URL to which an HTML rendering of the subject will link."> <rdfs:subPropertyOf rdf:resource="http://purl.org /dc/elements/1.1/identifier" /> <rdfs:isDefinedBy rdf:resource="http://purl.org/r ss/1.0/" /> </rdf:Property> <rdf:Property rdf:about="http://purl.org/rss/1.0/ur l" rdfs:label="URL" rdfs:comment="The URL of the image to used in the ' src' attribute of the channel's image tag when rendered as HTML."> <rdfs:subPropertyOf rdf:resource="http://purl.org /dc/elements/1.1/identifier" /> <rdfs:isDefinedBy rdf:resource="http://purl.org/r ss/1.0/" /> </rdf:Property> <rdf:Property rdf:about="http://purl.org/rss/1.0/de scription" rdfs:label="Description" rdfs:comment="A short text description of the subject."> <rdfs:subPropertyOf rdf:resource="http://purl.org /dc/elements/1.1/description" /> <rdfs:isDefinedBy rdf:resource="http://purl.org/r ss/1.0/" /> </rdf:Property> <rdf:Property rdf:about="http://purl.org/rss/1.0/na me" rdfs:label="Name" rdfs:comment="The text input field's (variable) nam e."> <rdfs:isDefinedBy rdf:resource="http://purl.org/r ss/1.0/" /> </rdf:Property> </rdf:RDF> Source : http://purl.org/rss/1.0/schema.rdf

116

5.2. Exemple de fichier RSS de syndication <?xml version="1.0" encoding="utf-8"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-synta x-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:sy="http://purl.org/rss/1.0/modules/syndica tion/" xmlns:co="http://purl.org/rss/1.0/modules/company /" xmlns:ti="http://purl.org/rss/1.0/modules/textinp ut/" xmlns="http://purl.org/rss/1.0/" > <channel rdf:about="http://meerkat.oreillynet.com /?_fl=rss1.0"> <title>Meerkat</title> <link>http://meerkat.oreillynet.com</link> <description>Meerkat: An Open Wire Service</des cription> <dc:publisher>The O'Reilly Network</dc:publishe r> <dc:creator>Rael Dornfest (mailto:rael@oreilly. com)</dc:creator> <dc:rights>Copyright © 2000 O'Reilly & Associates, Inc.</dc:rights> <dc:date>2000-01-01T12:00+00:00</dc:date> <sy:updatePeriod>hourly</sy:updatePeriod> <sy:updateFrequency>2</sy:updateFrequency> <sy:updateBase>2000-01-01T12:00+00:00</sy:updat eBase> <image rdf:resource="http://meerkat.oreillynet. com/icons/meerkat-powered.jpg" /> <items> <rdf:Seq> <rdf:li resource="http://c.moreover.com/cli ck/here.pl?r123" /> </rdf:Seq> </items> <textinput rdf:resource="http://meerkat.oreilly net.com" /> </channel> <image rdf:about="http://meerkat.oreillynet.com/i cons/meerkat-powered.jpg"> <title>Meerkat Powered!</title> <url>http://meerkat.oreillynet.com/icons/meerka t-powered.jpg</url> <link>http://meerkat.oreillynet.com</link> </image> <item rdf:about="http://c.moreover.com/click/here .pl?r123"> <title>XML: A Disruptive Technology</title> <link>http://c.moreover.com/click/here.pl?r123< /link> <dc:description> XML is placing increasingly heavy loads on th e existing technical infrastructure of the Internet. </dc:description> <dc:publisher>The O'Reilly Network</dc:publishe r> <dc:creator>Simon St.Laurent (mailto:simonstl@s imonstl.com)</dc:creator> <dc:rights>Copyright © 2000 O'Reilly & Associates, Inc.</dc:rights> <dc:subject>XML</dc:subject> <co:name>XML.com</co:name> <co:market>NASDAQ</co:market> <co:symbol>XML</co:symbol> </item> <textinput rdf:about="http://meerkat.oreillynet.c om"> <title>Search Meerkat</title> <description>Search Meerkat's RSS Database...</ description> <name>s</name>

117

<link>http://meerkat.oreillynet.com/</link> <ti:function>search</ti:function> <ti:inputType>regex</ti:inputType> </textinput> </rdf:RDF> Source : [44]

6. Indicateurs des processus principaux de Microsof t SharePoint Portal Server 2001

Source, extraits de : [60].

6.1. Indicateurs de gestion des documents

Tableau 8 : indicateurs de gestion des documents

Counter Description Failed Approves Total number of failed approve requests Failed Approves Latency Average latency at which failed approve requests are

processed Failed Checkins Total number of failed check-in requests Failed Checkins Latency Average latency at which failed check-in requests are

processed Failed Checkouts Total number of failed check-out requests Failed Checkouts Latency Average latency at which failed check-out requests are

processed Failed Copies Total number of failed copy requests Failed Copies Latency Average latency at which failed copy requests are processed Failed Deletes Total number of failed delete requests Failed Deletes Latency Average latency at which failed delete requests are processed Failed Enum Folders Total number of failed enumerate folders requests Failed Enum Folders Latency Average latency at which failed enumerate folders requests are

processed Failed Moves Total number of failed move requests Failed Moves Latency Average latency at which failed move requests are processed Failed Publishes Total number of failed publish requests Failed Publishes Latency Average latency at which failed publish requests are processed Failed Rejects Total number of failed reject requests Failed Rejects Latency Average latency at which failed reject requests are processed Failed Undo Checkouts Total number of failed undo check-out requests Failed Undo Checkouts Latency Average latency at which failed undo check-out requests are

processed Failed Version Histories Total number of failed version history requests Failed Version Histories Latency Average latency at which failed version history requests are

processed Successful Approves Total number of successful approve requests Successful Approves Latency Average latency at which successful approve requests are

processed Successful Checkins Total number of successful check-in requests Successful Checkins Latency Average latency at which successful check-in requests are

processed Successful Checkouts Total number of successful check-out requests Successful Checkouts Latency Average latency at which successful check-out requests are

118

Counter Description processed

Successful Copies Total number of successful copy requests Successful Copies Latency Average latency at which successful copy requests are

processed Successful Deletes Total number of successful delete requests Successful Deletes Latency Average latency at which successful delete requests are

processed Successful Enum Folders Total number of successful enumerate folders requests Successful Enum Folders Latency Average latency at which successful enumerate folders

requests are processed Successful Moves Total number of successful move requests Successful Moves Latency Average latency at which successful move requests are

processed Successful Publishes Total number of successful publish requests Successful Publishes Latency Average latency at which successful publish requests are

processed Successful Rejects Total number of successful reject requests Successful Rejects Latency Average latency at which successful reject requests are

processed Successful Undo Checkouts Total number of successful undo check-out requests Successful Undo Checkouts Latency Average latency at which successful undo check-out requests

are processed Successful Version Histories Total number of successful version history requests Successful Version Histories Latency Average latency at which successful version history requests

are processed

6.2. Indicateurs de souscriptions (abonnements aux alertes)

Tableau 9 : Indicateurs du programme de souscriptio ns (abonnements aux alertes)

Counter Description Errors Access Denied Total number of access-denied errors received

during access check Total Access Checks Total number of access checks that the

subscriptions engine does Total Discarded Hits Total number of hits that the subscriptions engine

discards Total Documents Processed Total number of documents that the subscriptions

engine processes Total Documents Processed/sec. Rate at which the subscriptions engine processes

documents Total Duplicate Hits Total number of duplicate hits that the

subscriptions engine processes Total Full Access Checks Total number of access checks done by

contacting the domain controller Total Hits Received Total number of hits that the subscriptions engine

processes Total Hits Received/sec. Rate at which the subscriptions engine receives

hits Total Notifications Sent Total number of e-mail subscription notifications

that the system sends Total Notifications Sent/sec. Rate at which the subscriptions engine sends e-

mail notifications Total Subscriptions Total number of subscriptions defined in the

system

119

6.3. Indicateurs de recherches

Tableau 10 : indicateurs de recherches

Counter Description Active Threads Total number of threads currently servicing

queries Current Connections Number of currently established connections

between MSSearch and all clients Failed Queries Number of queries that fail Failed Query Rate Number of failed queries per second Queries Cumulative number of queries posted to the

server Query Rate Number of queries posted to the server per

second Result Rate Number of results returned to the client per

second Results Cumulative number of results returned to clients Succeeded Queries Number of queries that produce successful

searches Succeeded Query Rate Number of queries per second that produce

successful searches Threads Total number of threads available for servicing

queries

6.4. Indicateurs de fonctionnement du moteur de rec herche

Tableau 11 : Indicateurs de fonctionnement du moteu r de recherche

Counter Description Catalog Size (MB) Size of catalog data in megabytes Failed Queries Number of queries that fail Failed Queries Rate Number of failed queries per second Number Of Documents Total number of documents in the catalog Persistent Indexes Number of persistent indexes Queries Cumulative number of queries posted to the

catalog Queries Rate Number of queries posted to the catalog per

second Results Cumulative number of results returned to clients Results Rate Number of results returned to the client per

second Successful Queries Number of queries that produce successful

searches Successful Queries Rate Number of queries per second that produce

successful searches Unique Keys Number of unique words and properties in the

catalog Les autres indicateurs du fonctionnement du moteur de recherche ne sont pas repris ici car trop spécifiques.

120

7. Exemples de fichiers de transformation pour la p ublication 7.1 « presentation template » de Interwoven TeamSite Templating page 120 7.2 Squelette du Système de Publication pour l’Internet (SPIP) page 123

7.1. « presentation template » de Interwoven TeamSi te Templating Il s’agit d’un langage de script Perl, gérant les éléments XML d’un fichier XML et produisant un fichier « Html » en sortie. L’intérêt de cet exemple est qu’il peut s’appliquer à l’exemple de fichier XML vu en annexe 2.4 « Exemple de QCM simple conforme au schéma QCM.xsd ». On y trouve à la fois du code de sélection, de mise en forme et d’ajout de comportement (javascript). <?xml version="1.0" encoding="ISO-8859-1"?> <iw_pt>  <html> <head><title> <iw_iterate var='element' list='dcr.*' > <iw_value name='element.titre'/> </iw_iterate> </title> <![CDATA[ <script language="JavaScript"> <!-- // hide if (self != top) top.location.href = self.location. href; this.name="principale"; function affiche2(lien) { newwin=window.open(lien,'autre','width=130,height=1 10,directories=no,location=no,menubar=no,resizable=yes,status=no,toolbar=no,titlebar =no,fullscreen=no'); } var browser = navigator.appName; var version = navigator.appVersion.charAt(0); /* GameQuiz v1.0 by MCQ. Copyright (c) of MCQ, 2003. */ var rep = new Array; var faite = new Array; var score = 0; //changez les reponses ci-dessous (a, b, c, ou d) p our chacune des 10 questions function Engine(question, reponse, estCorrecte) { if (estCorrecte != "vrai") { if (!faite[question]) { faite[question] = -1; alert("Faux ! Ton score est de : " + score + " "); } else {

121

alert("Encore cette questio n ? Vois la suivante !"); } } else { if (!faite[question]) { faite[question] = -1; score++; alert("Bien ! Ton score est de : " + score); } else { alert("Encore cette questio n ? Vois la suivante !"); } } } function NextLevel (nombreQuestion) { if (score > nombreQuestion) { alert("Tricheur !"); } if (score >= nombreQuestion && score <= nom breQuestion) { alert(score + "/" + nombreQuestion + ". Fort bien !"); } if (score >= (nombreQuestion - ((nombreQues tion * 20)/100)) && score < nombreQuestion) { alert(score + "/" + nombreQuestion + ". Bien, mais... pas parfait."); } if (score >= (nombreQuestion - ((nombreQues tion * 50)/100)) && score < (nombreQuestion -((nombreQuestion * 20)/100)) ) { alert(score + "/" + nombreQuestion + ". Assez bien, mais des erreurs..."); } if (score < (nombreQuestion / 2)) { alert(score + "/" + nombreQuestion + ". Pas terrible... un autre essai ?"); } // ================================================ ====== // lignes qui suivent pour vider le formulaire: faite = new Array; score = 0; //================================================= ====== // pour IE4 ou Nettcape 3 et + if(browser == "Microsoft Internet Explorer" && ver sion >= 4 || browser == "Netscape" && version >= 3) { document.quest.reset(); } } // --> </script> ]]> </head> <body> <h1><center><font color="green"> <iw_iterate var='element' list='dcr.*'>

122

<iw_value name='element.titre'/> </iw_iterate> </font></center></h1> <![CDATA[  ]]> <hr></hr> <p><font color="red" size="+1"><bold> <iw_iterate var='element' list='dcr.*'> <iw_value name='element.enTeteModeEmploi'/> </iw_iterate> </bold></font></p> <p><font color="blue" size="+1"><bold> <iw_iterate var='element' list='dcr.*'> <iw_value name='element.enTeteDescription'/ > </iw_iterate> </bold></font></p> <hr></hr> <p><NOSCRIPT>JavaScript est désactivé. Utilisez un autre navigateur plus récent...</NOSCRIPT> </p> <form name="quest"> <iw_perl><![CDATA[ use TeamSite::DCRnode; my $compteur1 = '1'; foreach my $question ( iwpt_dcr_list( 'dcr.QCM.chapitre.ques tion' ) ) { my $compteur2 = '1'; my $compteur3 = 0; my $questionLibelle = iwpt_dcr_value('qu estion.questionLibelle' ) ; iwpt_output( " <li> <font color='black' si ze='+1'><bold> $questionLibelle ? </bold></font> </li> <br> " ); my @alist = $question->get_node_list('reponse') ; foreach my $reponse ( iwpt_dcr_list('question.repo nse') ) { my $reponseLibelle = iwpt_dcr_value('reponse.repo nseLibelle') ; # print $alist[$compteur3]->get_attrib('estCorrect e'), "\n"; my $estCorrecte = $alist[$compteur3]->get_attrib( 'estCorrecte'); iwpt_output ( " <input type='radio' name =$compteur1 value=$compteur2 onclick='Engine($compteu r1, this.value, this.estCorrecte)' estCorrecte=$estCorrecte>

123

<font color='#FF0000'>&n bsp;$compteur2 </font> $reponseLibelle<br> "); $compteur2 = $compteur2+1; $compteur3 = $compteur3+1; } $compteur1= $compteur1 + 1; } $compteur1= $compteur1 - 1; iwpt_output (" <p> </p> <p><input type='button' name='Resultats' value='resultats' nombreQuestion='$compteur1' onclick='NextLevel(this.nombreQuestion)'> </p> "); ]]></iw_perl> <p> </p> <p> </p> </form> </body> </html> </iw_pt>

7.2. Squelette du Système de Publication pour l’Int ernet (SPIP) Cet exemple de fichier de transformation est utilisé dans le système de gestion de site web SPIP. SPIP impose l’utilisation d’un langage « propriétaire » dit « langage de boucle ». Le contenu du fichier « groupe_mots.html » (cf. 7.2.1), dit fichier squelette, effectue la sélection de méta données des documents de type « article » et affiche les catégories principales et, à l’intérieur d’elles même, les sous-catégories dans lesquelles sont classés les documents, sous forme de lien hypertexte permettant d’accéder à une page concernant la sous-catégorie. Ce fichier inclut une référence à un autre fichier de transformation (entete.php3 ) du système SPIP qui contient lui aussi du code de présentation et d’autres inclusions, dont un fichier squelette qui affiche les éléments communs à toutes les pages du site web (menu des rubriques, champ de saisie de recherche et logo du site web). Une feuille de style associée donne le code de mise en forme (couleur, police de caractère, taille, épaisseur, etc.) du texte de la publication (voir annexe 7.2.2). Le résultat de la publication du code de l’exemple est repris en annexe 7.2.3 sous forme d’image de copie d’écran.

7.2.1. Contenu du fichier groupe_mot.html <INCLURE(entete.php3)> <div class="titre">Recherche d'articles par catégor ie</div><br><br> <BOUCLE_groupes(GROUPES_MOTS){par titre}> <h1 class="structure">#TITRE</h1> <BOUCLE_mots(MOTS){id_groupe}{par titre}{" - "}> <a href="#URL_MOT">#TITRE</a></BOUCLE_mots> </BOUCLE_groupes>

124

<INCLURE(fin.htm)>

7.2.2. Exemple de feuille de style CSS Cette feuille de style s’applique au fichier html généré. Il s’agit de code contenu dans le fichier html mais généré par le système à partir de feuille de style. <STYLE type="text/css"> A:link {color: #ffffff;text-decoration:none;} A:visited {color: #D7DBEF;text-decoration:none;} A:hover {color: #D7DBEF;text-decoration:underline;} a.spip_out {color: #ffdddd;text-decoration:none;} body { scrollbar-3d-light-color: #000000;; scrollba r-arrow-color: #AA99C7;; scrollbar-base-color: #D7DBEF; scrollbar-dark-shado w-color: #001122;; scrollbar-face-color: #D7DBEF;; scrollbar-highlight -color: #AA99C7;; scrollbar-shadow-color: #223344; } td {color: black; font-variant: normal; font-size: 11px; font-family: Verdana, Arial, Helvetica } .titre {text-align: center;color: #990000; font-siz e: 20px; font-family: Verdana, Arial, Helvetica ; font-weight: bold} .structure {text-align: left;color: #880000; font-s ize: 14px; font-family: Verdana, Arial, Helvetica ; font-weight: bold} .chapo {text-align: justify; color: #111111; font-s ize: 11px; font-family: Verdana, Arial, Helvetica ; font-weight: bold} .spip_surligne { background-color: #FFFF66; } b { font-weight: bold } .forum-titre{font-weight: bold} .forum-texte{color: #222222;} </STYLE>

125

7.2.3. Copie d’écran de la page html de publication correspondante

8. Modèle de données général d’un système de gestio n de contenu

126

+estDocument() : boolean+createDTD()+createXmlSchema()+derniereVersion()+propageMetaDonnees()

-nomCDoc-contenuCDoc-attributsCDoc-typeCDoc

ComposantDocumentaire

-nomMetaDonnee-typeMetaDonnee

MetaDonnee

+authentification()

-login-certificatUtilisateur

utilisateur

-nomGroupeTravail-descriptionGroupeTravail

GroupeTravail

-Compose

1..*

-EstComposeDe

0..*

-decrit

0..*

-estDecritPar

1..*

-Compose 1..*

-EstComposeDe

0..*

nomRoledescriptionRoledroitscommentaireRole

Role

1..*

-joueUnRoleDans

1..*

-roleJouePar

-nomWorkflow-numeroTache-descriptionTache-retourTache-suiteTache

Workflow

-execute

*

-estExecutePar

*

-nomPublication-datePublication-droitsPublications

Publication

creeFeuilleDeStyle()fichierDeTransformation()

nomTransformationcoordonneesPublicationmiseEnForme

Transformation*-estExposeDans

*-expose

createFormulaireEdition()acquisitionCDoc()

nomEditionapplicationEditiontemplateEdition

Edition1..*-edite

1..*-estEditePar

-nomPersonne-prenomPersonne-adresse-departement-entreprise

Personne

-nomApplication-descriptionApplication

Application

-Compose

1..*

-EstComposeDe 0..*

-decrit

0..*

-estDecritPar

1..*

127

BIBLIOGRAPHIE 1 ABF : Normalisation / Association des bibliothécaires français – ABF / dernière mise à jour du mardi 6 août 2002 / http://www.abf.asso.fr/liens/normalisation.html /

2 Bibliographic Formats and Standards: Introduction / OCLC - Online Computer Library Center, Inc / ©2002 OCLC / http://www.oclc.org/bibformats/en/introduction/

3 FORMAT UNIMARC BIBLIOGRAPHIQUE ABREGE / UNIMARC : format abrégé pour le WEB / BNF – Bibliothèque Nationale de France / 2ème mise à jour de 1998 du format UNIMARC /

4 Catalogue des normes ISO - IT applications in information, documentation and publishing / ISO - International Organization for Standardization / http://www.iso.org/iso/en/CatalogueListPage.CatalogueList?ICS1=35&ICS2=240&ICS3=30 /

5 Logiciels de gestion de bibliothèques / Christian Rogel / ADBDP – Association des Directeurs des Bibliothèques Départementales de Prêt / mise à jour du 3 septembre 2002 / http://www.adbdp.asso.fr/outils/infogestion/logicielsbiblio.htm /

6 The Digital Library Toolkit / Dr. Peter Noerr / Sun Microsystems / Second Edition / March, 2000 /

7 Vers une révolution dans la conception des catalogues... et bien au-delà ? / par Pierre-Yves Duchemin ([email protected]) Bibliothèque Nationale de France et Dominique Lahary ([email protected]) Bibliothèque départementale du Val d'Oise / in « Bulletin d'informations no188 » / 3e trimestre 2000 / Association des bibliothécaires français / http://www.abf.asso.fr/publications/bulletin/188/article1.html /

8 ADOBE CUSTOMER SPOTLIGHT : McDonnell Douglas - Adobe® FrameMaker® +SGML / © 1997 Adobe Systems Incorporated. All rights reserved. / 3 pages

9 Life Sciences: Documentum Solution Brief / © 2003 Documentum, Inc. All rights reserved. / 4 pages

10 Adobe FrameMaker 7.0. solutions guide / Adobe corporation / Sections 2, 3, et 4 / © 2002 Adobe Systems Incorporated. All rights reserved.

11 IBM Customer Success Story : Hertz / © Copyright IBM Corporation 2003 : Lotus Software / 4 pages

12 Adobe FrameMaker 7.0 in Technical Publishing / © 2002 Adobe Systems Incorporated. All rights reserved. / 4 pages

13 Framatome ANP – success story / © 2003 Documentum, Inc. All rights reserved. / 3 pages

14 Encyclopédie en ligne Hachette : définition du mot document / http://encyclo.voila.fr/cgi-bin/frame?str=document&ft=0&fd=1&fm=0&fa=0&multi=1&nbe=3 ./

15 Introduction à la GED ou GEIDE / ©2000 APROGED - Tous droits réservés / http://www.aproged.org /

16 EIDE : un format d’échange pour les applications GED / p 24-33 / MOS Magazine n° 180 de février 2000 / Dossier.

17 EIDE (Echange d’Informations et Documents Existants) : Projet final / version 1.05 du 24 novembre 1999 / M. Biezunski, J.P. Blanger, B. Olivier / ©2000 APROGED et auteurs / APROGED / 18 pages.

18 Comment mettre en place un portail qui réponde aux véritables enjeux de votre entreprise? / Jacques Laventure / Cross Systems / support de présentation PowerPoint / 75 pages / 14 Mai 2003 / fichier : Présentation portails_V12.ppt

19 Enterprise Information Portals : Enabling Knowledge Management in Today’s Knowledge Economy / A Hummingbird Whitepaper / Octobre 2001 / 19 pages / www.hummingbird.com .

20 IBM Enterprise Information Portal, Version 8 / ©Copyright IBM Corporation 2002 / 5 pages.

21 BroadVision One-To-One® Por tal™ / Broadvision / © 2002, BroadVision, Inc / Part No. 20483-0502 / 6 pages /http://www.broadvision.com.

128

22 Info Exchange Portal Business White Paper - Unifying the Extended Enterprise with Personalized Self-Service Portals / © 2001 BroadVision, Inc. / 16 pages / www.broadvision.com

23 Panorama des solutions de gestion de la connaissance / livre blanc version 3 / Business Interactif / http://www.businessinteractif.com / © BUSINESS INTERACTIF 2002 / 150 pages

24 Generating return on information with an IBM enterprise content management infrastructure / Data Management Software Solutions / June 2002 / © Copyright IBM Corporation 2002 / 20 pages.

25 A guide to evaluating Enterprise Content Management software / © 2003 Documentum, Inc. / 29 pages / page 23 : “Enterprise Integrations”.

26 Information Management Software Product Landscape / © Copyright, CMSWorks, Inc. / http://www.cmswatch.com / Autumn, 2001 / tableau synthétique d’une page.

27 Solutions de Web Content Management (WCM) en vue de la création d'une offre Cross Systems / Eric Cardoso, Géraldine Exertier, Jacques Laventure, Marcel Matton, Jean-Luc Mondino / Document de travail interne – draft / Cross Systems / 14 pages / version 2.2. du 16/07/2002.

28 Editique – Offre Cross Systems / Cross Systems Integration / version 1.0 / 25 avril 2003 / 17 pages

29 Content Management Possibilities - The Chase Bobko, Inc. Content Management Model / Keith McMahon / 2000 / Chase Bobko, Inc. / présentation PowerPoint / 18 pages.

30 The wheel of content management : a CM domain white paper / Bob Boiko / http://www.metatorial.com / 18 pages / © 2002 Metatorial Services, inc. & HungryMinds, inc.

31 Working within the organization : a CM domain white paper / Bob Boiko / http://www.metatorial.com / 21 pages / © 2002 Metatorial Services, inc. & HungryMinds, inc.

32 Tour d’horizon des systèmes centrés documents / Présentation / O. BEAUDOUX <[email protected]> / ALF / 23 avril 2001 / 21 pages / www.eseo.fr/~obeaudoux/beaudoux-alf01.pdf

33 Managing Enterprise Content : The Basis of a Unified Content Strategy. /The first in a five-part series of internet presentation / Ann Rockley – President / The Rockley Group Inc. / 11 juin 2003 / 49 pages. / pages 22-32 : “types of reuse”.

34 Uniform Resource Identifiers (URI): Generic Syntax / T. Berners-Lee, R. Fielding, U.C. Irvine, L. Masinter / Request for Comments: 2396 / IETF / August 1998.

35 URN Syntax / R. Moats - AT&T/ Request for Comments: 2141/ IETF / May 1997.

36 Naming and Addressing: URIs, URLs, ... / Dan Connolly / World Wide Web Consortium / Created 1993 by Tim Berners-Lee / last revised 2002/07/09 14:31:42 / ©1997 W3C (MIT, INRIA, Keio) / http://www.w3c.org/Addressing/

37 Universal Resource Identifiers in WWW : A Unifying Syntax for the Expression of names and Addresses of Objects on the Network as used in the World-Wide Web / working draft / Tim Berners-Lee / CERN / 12 March 1994 / http://www.w3.org/hypertext/WWW/Addressing/URL/URI_Overview.html .

38 Introduction to Persistent Uniform Resource Locators / Keith Shafer, Stuart Weibel, Erik Jul, Jon Fausey / OCLC Online Computer Library Center, Inc. / http://purl.oclc.org/docs/inet96.html /

39 Dublin Core Metadata Initiative / Site web / http://www.dublincore.org

40 Eléments de métadonnées du Dublin Core, Version 1.1: Description de Référence / Traduction de Anne-Marie Vercoustre / INRIA / Date de création: 20 Avril 2000 / Date de Mise à jour: 26 mars 2002.

41 XML : langage et applications / Alain Michard / Eyrolles / 1999 / ISBN 2-212-09052-8

42 Professional XML Meta Data / Kal Ahmed, Danny Ayers, Mark Birbeck, Jay Cousins, David Dodds, Josh Lubbel, Miloslav Nic, Daniel Rivers-Moore, Andrew Watt, Robert Worden, Ann Wrightson/ Collection « Programmer to programmer »/ Wrox Team / Wrox Press / 08-2001 / 600 pages / ISBN: 1-861004-51-6

43 Resource Description Framework (RDF) Model and Syntax Specification. / Ora Lassila <[email protected]>, Nokia Research Center, Ralph R. Swick <[email protected]> / World Wide Web Consortium W3C Recommendation 22 February 1999 / W3C / http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/#examples

129

44 RDF Site Summary (RSS) 1.0 / specifications / The members of the RSS-DEV Working Group / version 1.3.4 / 2001-05-30 / URL de la Dernière version : http://purl.org/rss/1.0/spec

45 Writing RSS 1.0 / Rael Dornfest / 08-25-2000 / Published on The O'Reilly Network (http://www.oreillynet.com/) / URL d’origine : http://www.oreillynet.com/pub/a/network/2000/08/25/magazine/rss_tut.html

46 RSS Tutorial for Content Publishers and Webmasters / ©2002 Mark Nottingham <[email protected]> / Version 0.72 / September 4, 2002 / URL dernière version : http://www.mnot.net/rss/tutorial/

47 RDF Site Summary 1.0 Modules / The members of the RSS-DEV Working Group / version 1.3.2 / 2001-03-20 / URL de la dernière version : http://purl.org/rss/1.0/modules/

48 RDF Site Summary 1.0 Modules: Dublin Core / The members of the RSS-DEV Working Group / version 1.4.1 / 2000-12-20 / URL de la dernière version : http://purl.org/rss/1.0/modules/dc/

49 RDF Site Summary 1.0 Modules: Syndication / The members of the RSS-DEV Working Group / version 1.4.1 / 2000-12-20 / URL de la dernière version : http://purl.org/rss/1.0/modules/syndication/

50 RDF Site Summary 1.0 Modules: Content / Gabe Beged-Dov - JFinity Systems LLC, Aaron Swartz - AaronSw.com, Eric van der Vlist – Dyomedea / version 1.02 / 2001-04-05 / URL de la dernière version http://purl.org/rss/1.0/modules/content/

51 Interwoven TeamSite® Administration Guide Release 5.5.2 for Windows NT® and Windows ® 2000 / © 1999-2002 / Interwoven, Inc. All rights reserved. / Printed in the United States of America Release 5.5.2 Part # 10-00-10-11-00-552-300

52 Interwoven TeamSite® Templating Developer’s Guide Release 5.5.2 / © 1999-2002 / Interwoven, Inc. All rights reserved. / Printed in the United States of America Version 5.5.2 Part # 40-00-10-12-00-552-200

53 SharePoint Portal Server 2001 Managing Content / Microsoft Corporation / http://www.microsoft.com/technet/prodtechnol/sppt/sharepoint/deploy/depovg/mangcont.asp

54 Microsoft® SharePoint™ Portal Server 2001 Resource Kit / Microsoft Corporation / 2001-31-10 / ISBN 0-7356-1562-4 / 640 pages et CDRom / accessible à l’URL http://www.microsoft.com/technet/prodtechnol/sppt/sharepoint/reskit/default.asp

55 SPIP Système de publication pour l’Internet : Guide de l’utilisateur / Copyright 2001-2002 Arnaud Martin, Antoine Pitrou et Philippe Rivière / VERSION 20021217 / SPIP / Site officiel de SPIP : http://www.uzine.net/rubrique91.html

56 SPIP Système de publication pour l’Internet : le manuel de référence / Copyright 2001-2002 Arnaud Martin, Antoine Pitrou et Philippe Rivière / VERSION 20021214 / SPIP / Site officiel de SPIP : http://www.uzine.net/rubrique91.html

57 SPIP Système de publication pour l’Internet : squelettes / Guide du webmestre / Copyright 2001-2002 Arnaud Martin, Antoine Pitrou et Philippe Rivière / VERSION 20021217 / SPIP / Site officiel de SPIP : http://www.uzine.net/rubrique91.html

58 Content Management / Course Workbook / © 2001 Stellent, Inc. / Revision November 12, 2001 / Printed in the United States of America /Stellent website http://www.stellent.com

59 Content Server administration / Course Workbook / © 2001,2002 Stellent, Inc. / Revision November 1, 2001 / Printed in the United States of America /Stellent website http://www.stellent.com

60 The Administrator's Guide to SharePoint Portal Server 2001 / paperback / Chapitre 12 : Monitoring SharePoint Portal Server 2001/ Auteur(s) : ENGLISH Bill / Date de parution: 09-2002 ./ Addison Wesley / Langue : ANGLAIS / 440p / disponible à l’url : http://www.microsoft.com/technet/prodtechnol/sppt/sharepoint/maintain/monitor/awsps12.asp

61 Réutilisation logicielle : guide pratique et retours d’expériences / chapitre 3 : le référentiel d’entreprise, p 69-89 / Michel Ezran, Maurizio Morisio, Colin Tully / Editions Eyrolles Collection Informatiques / 1999 / 260 pages / ISBN 2-212-09066-8

62 XML, Web Services, and the Data Revolution / Frank P. Coyle / Information Technology Series / Addison-Wesley / copyright 2002 / ISBN 0-201-77641-3

130

63 Enterprise Content Integration with the digital object identifier / A business case for information publisher / Bill Rosenblatt / Giantsteps Media Technology Strategies : http://www.giantstepsmts.com / 2002-06-20 / DOI : http://dx.doi.org/10.1220/withepaper5

64 Everything You Need to Know About Personalization / Chris Payne / WDVL – Web Developer’s Virtual Library / 2000-11-22 / http://www.wdvl.com/Authoring/ASP/Personalization/index.html

65 Le référencement sur Internet / Frédéric Hami-Sultan, Phlippe Lahaye, Frédéric Rousselon / Rapport d’études : Projet Systèmes d’Information / CNAM - Conservatoire National des Arts et Métiers / 2000.

66 A framework for dynamic exploration in semantic portals / Jean-Marc Saglio (ENST, Paris), Tuan-Anh Ta (HUT, Hanoï) / 2000 / http://cweb.inria.fr/Projects/semzoom-KR2002.pdf

67 BroadVision One-To-One Content / Broadvision / © 2001, BroadVision, Inc / Part No. 20413-1001 / 5 pages / http://www.broadvision.com

68 BroadVision One-To-One® Enterprise™ / Broadvision / © 2001, BroadVision, Inc / Part No. 20270-0502 / 4 pages / http://www.broadvision.com

69 Documentum 4i eBusiness Platform / © 2001 Documentum, Inc. / Printed in the U.S.A. 22800701V3 / 4 pages / http://www.documentum.com

70 Documentum 5: The Next Generation in Enterprise Content Management / product datasheet / © 2002 Documentum, Inc. / Printed in the U.S.A. 23120802V1 / 4 pages / http://www.documentum.com

71 IBM Content Manager, Version 8 / ©Copyright IBM Corporation 2002 / 4 pages / http://www.ibm.com/fr .

72 Proposition technique relative à la solution Instranet V2b / document de travail : réponse type à appel d’offre / Patrice Lavirotte / Instranet / 45 pages / avril 2002

73 Instranet V2 : synthèse des fonctionnalités / document tableur MS Excel / Patrice Lavirotte / Instranet / Octobre 2001

74 Stellent Content Management System / © 2002 Stellent, Inc. All rights reserved. / v610062002 / 4 pages / http://www.stellent.com

75 Tridion Web Content Management / document présentation powerpoint / fichier Tridion_FRNEW06_2002.ppt / auteur : maliekl / Tridion B. V. / 74 pages / 2002 / http://www.tridion.com

76 Vignette® V6 Content Suite / Copyright 2002 Vignette Corporation. / 4 pages / http://www.vignette.com

77 The Zope Book / Covers Zope 2.5 / Introduction and Chapter 1 : introducing Zope / By Amos Latteier and Michel Pelletier / Copyright © 2000 by New Riders Publishing

78 Enterprise Content Management Catalog / Interwoven / Copyright 2002 Interwoven, Inc. / http://www.interwoven.com

79 Microsoft SharePoint Portal Server 2001 : presentation / Microsoft / Copyright 2000 Microsoft Corporation / 27 pages / http://www.microsoft.com/servers/sharepoint

80 Caractéristiques completes / Equipe de SPIP / 1er juin 2001 / http://www.spip.org

81 ETUDE DE 3 SYSTEMES DE GESTION DE CONTENUS : Microsoft CMS et SPPS, Interwoven ECM Suite et SPIP / dossier de cadrage / statut : draft / version 0.2 / Philippe LAHAYE / Cross Systems Integration / fevrier 2003 / 8 pages

82 OFFRE DE MARCHE : enterprise MCQ / Philippe LAHAYE / Cross Systems Integration / novembre 2002 / 4 pages

83 SPECIFICATIONS FONCTIONNELLES DE LA GESTION DES CONTENUS DE L'ENTREPRISE MCQ : Base documentaire : contrat, QCM / statut : draft / version 1.0 / Philippe LAHAYE / Cross Systems Integration / fevrier 2003 / 24 pages

84 RDF Vocabulary Description Language 1.0: RDF Schema / Editors : Dan Brickley, W3C <[email protected]>, R.V. Guha, IBM <[email protected]> / W3C / Working Draft 05 September 2003 / W3C / http://www.w3.org/TR/2003/WD-rdf-schema-20030905/