Système de gestion de contenu: administration d’un CMS et référentiel

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

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…

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 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
Modèle simple de référentiel de gestion de contenu
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].
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.
Lire le mémoire complet ==> (Les systèmes de gestion de contenu : description, classification et évaluation)
Mémoire présenté en vue d’obtenir le DIPLOME D’INGENIEUR C.N.A.M. en informatique
Conservatoire National Des Arts Et Métiers – Paris

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

Laisser un commentaire

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

Scroll to Top