Adaptation au logiciel de gestion de contenu

Adaptation au logiciel de gestion de contenu

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.
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 fonctionnalités déclarées des logiciels Interwoven ECM, MS SharePoint et SPIP

75 GPL : General Public Licence

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.
Tableau 3 : classification de logiciels de gestion de contenu Interwoven ECM, MS SPPS et SPIP

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

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 depuis 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.
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),
– 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 !
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 « 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).

77 Sécurité d’Interwoven et de SharePoint Portal Server 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 W eb Storage System (système de stockage W eb) sous-jacent s’effectue via les modèles objet ADO et CDO ou via le protocole Internet W ebDAV. L’accès au W eb 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

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.

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, administrator.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.
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 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 gestion 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 contenu
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 contenu 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.
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.
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
– 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).

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

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 gestion 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 contenu
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 contenu 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

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

– é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 !
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
– 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 gestion 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 contenu Rien n’est proposé en natif. Il faudra tout développer.
Note : 2
– migration depuis l’application de gestion de contenu 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 : notation et comparaison de trois CMS

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

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 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.
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 DIPLÔME D’INGÉNIEUR C.N.A.M. en informatique
Conservatoire National Des Arts Et Métiers – Paris