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 oeuvre 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 IFS 77 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 oeuvre 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).
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 oeuvre 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 oeuvre 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, adminstrator.uid et master.uid). La maintenance est donc lourde et source de problèmes. Les adresses de courrier électronique, si elles sont différentes d’une règle simple (du genre [email protected]), doivent être maintenues dans un fichier complémentaire (email_map.cfg), ce qui ajoute en lourdeur.
La gestion des accès (droits en lecture, écriture, suppression, appropriation, etc…) se fait là aussi en fonction des règles d’accès établies au niveau des répertoires de la partition IFS créée à l’installation (cf. installation) depuis le système d’exploitation. Le concept d’alias n’existant pas explicitement sous Windows 2000, là encore, la gestion des droits et des accès est lourde.
Note : 1
- récupération de documents existants (import)
Il y a bien une fonction (import) de récupération de fichiers.
Note : 4
- édition de document : création
La création de document ne pose pas de problème particulier.
Note : 4
- édition de document : mise à jour
La mise à jour de document est plus lourde. La gestion des verrous est peu intuitive. Il faut paramétrer LaunchPad pour activer l’éditeur de document voulu en fonction du type de fichier. Il peut y avoir confusion avec la fonction upload/download. Toutefois, si l’on modifie les modèles de présentation (fichiers de transformation .tpl), on peut utiliser la fonction de génération en lot des formats de sortie (ou encore format de publication). On trouve là la puissance qu’accorde un système de gestion de contenu.
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 oeuvre 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 oeuvre 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
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 Web Storage System
(système de stockage Web) sous-jacent s’effectue via les modèles objet ADO et CDO ou via le protocole Internet WebDAV.
L’accès au Web Storage System via son pilote IFS (Installable File System), qui présente généralement la banque
d’informations de dossier hiérarchique comme un fichier hiérarchique monté comme le lecteur M:, annule les mécanismes de
sécurité basés sur les rôles de SharePoint Portal Server ou d’Interwoven. Aussi, le serveur doit-il être sécurisé au niveau des
accès physiques locaux et des accès aux services de réseau et de terminal.
