Le paramétrage d’un CMS doit être complet avant que celui ci puisse être mis en oeuvre, 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 certificat 49, 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.
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.
49 Les certificats permettent de gérer, entre autre, les aspects légaux de la signature électronique si nécessaire.
50 Stop words en anglais.
51 prise en compte des synonymes par exemple, sujets approchants…
