La gestion électronique de documents

Comme nous l’avons vu lors de nos trois premiers volets, les solutions Open Source concurrent aujourd’hui les solutions propriétaires sur les secteurs des serveurs d’applications JEE, les outils de gestion de contenus et les portails d’intégration.

En se basant sur une série d’études menée dans les domaines les plus représentatifs de l’informatique d’entreprise, Clever Age propose un décryptage des principales tendances du marché, des retours d’expériences significatifs, une présentation d’architectures types, ainsi qu’une sélection de critères permettant de se poser les bonnes questions au moment de choisir une solution.

Aujourd’hui, le quatrième volet de notre analyse se penchera sur la gestion électronique de documents. Le prochain volet sera consacré aux outils de suivi de projet.

Les tendances du marché

Le terme GED est utilisé en français comme synonyme d’ECM, terme plus évocateur du périmètre et des ambitions propres à ce domaine. Il correspond à la gestion de tous les contenus de l’entreprise (documentation métier, procédures, formulaires, etc.). La référence en la matière aujourd’hui est sans aucun doute EMC Documentum, solution propriétaire riche mais complexe et coûteuse à mettre en œuvre. Parmi les challengers historiques, on trouve Filenet (racheté par IBM en 2006), OpenText ou encore Stellent (racheté par Oracle en 2006).

Pendant longtemps, la GED Open Source s’est limitée à des applications PHP sans réelle ambition, plutôt destinées à offrir des espaces de stockage de documents à des utilisateurs sur le Web (Horde Gollem, KnowledgeTree, etc.) qu’à fournir une infrastructure pour le stockage, la diffusion et l’archivage de tous les contenus de l’entreprise.

Mais une fois encore, l’arrivée de normes telles que WebDAV (accès à un dépôt de documents via le protocole HTTP) ou JSR 170 (appelée aussi JCR, pour Java Content Repository : une API d’entrepôt documentaire en Java) ont favorisé l’émergence d’acteurs issus de l’Open Source. Apache Jackrabbit, l’implémentation de référence de JSR 170, est utilisée par de nombreux projets Open Source, au premier rang desquels Alfresco. Cette solution d’ECM est sans doute la plus prometteuse dans le domaine : lancée en 2005 par l’ancienne équipe technique de Documentum UK avec pour objectif avoué de concurrencer directement son aînée, elle s’appuie sur une base technique solide alliée à un rythme de sortie des versions successives très soutenu.

L’autre solution de GED en vogue à l’heure actuelle est Nuxeo, de l’éditeur français du même nom. Initialement développée en Python (serveur d’application Zope) sous le nom de CPS, Nuxeo a été complètement réécrite en Java à partir de 2006.

Notons enfin que les outils de gestion de contenus se tournent de plus en plus vers la gestion électronique de documents (que ce soit par une utilisation détournée de l’usage principal, comme pour eZ publish, ou bien via un module dédié, comme c’est le cas pour Magnolia).

Exemples de projets réussis

Un service du ministère de la Défense choisit Nuxeo pour gérer ses ressources numériques

Le service en question a choisi Nuxeo en janvier 2007 gérer l’ensemble de ses ressources numériques. L’application de gestion de ressources multimédia et de gestion documentaire mise en œuvre est critique pour cette organisation car elle impacte directement sa mission première.

La chaîne de traitement mise en place comprend les étapes suivantes :

• Acquisition depuis différentes sources et imports de données par batch (documents textuels, images, vidéos, audio) ;
• Reprise automatique dans la GED des métadonnées des fichiers importés ;
• Client riche pour gérer les imports de données et la catégorisation ;
• Intégration de processus de workflow ;
• Gestion de l’annotation d’images au travers de l’interface web ;
• Navigation virtuelle dans la base documentaire basée sur les métadonnées & plan de classement multidimensionnel ;
• Tableaux de bord pour que les utilisateurs puissent rapidement accéder à leur liste de tâches.

L’application est utilisée quotidiennement par plus de 200 utilisateurs qui accèdent à plus d’1 To de données.

Lefebvre Software base son atelier de production de documents techniques sur Alfresco

Lefebvre Software est un éditeur de logiciels ERP employant environ 250 personnes. Les services R&D, technique et développement sont de gros producteurs de documentation (technique, fonctionnelle, utilisateur). Pour améliorer la chaîne de production documentaire (suppression des saisies multiples et des incohérences, publication multi-supports, etc.), Lefebvre Software a choisi de mettre en place une solution collaborative basée sur Alfresco (GED) et eXist (base de données XML).

Avec l’aide de deux sociétés spécialisées dans la production documentaire (Tetralogyx et NeoDoc), une architecture full XML a été définie, allant de la saisie des contenus (via l’éditeur XXE d’XML Mind) à leur publication multi-support (PDF, HTML, Wiki), après être passés par des workflows spécifiques. Outre un gain de productivité pour les rédacteurs, l’avantage de cette solution est qu’elle assure une cohérence maximale entre les informations (les contributeurs travaillent sur les mêmes sources) ainsi qu’un stockage dans un format pérenne et standard (XML).

Au niveau de l’infrastructure, un serveur de type Intel Xéon Quadri-Processeur disposant de 16 GO de RAM a été choisi, permettant une utilisation intensive par une trentaine de personnes travaillant sur plusieurs milliers de documents modulaires.

Architectures types

Architecture fonctionnelle

Un système de gestion électronique de documents est organisé autour d’un entrepôt documentaire (document repository), qui représente le cœur du système. Cet entrepôt s’appuie généralement sur une couche de persistance distincte (base de données et / ou système de fichiers) pour le stockage physique des documents.

L’entrepôt assure l’essentiel des fonctions de bases : versionning, verrouillage, indexation, gestion des métadonnées, etc., ainsi que des fonctions plus évoluées, comme la gestion des droits d’accès, les workflows ou les transformations de documents (génération de PDF par exemple). Les contenus sont mis à disposition des applications consommatrices via des API, qui peuvent être normées (JCR) ou non, et des protocoles d’échange de fichiers (WedDAV, FTP, CIFS, etc.).

Une des particularités des outils de gestion de documents est qu’ils sont généralement accessibles (avec plus ou moins de restrictions) depuis des environnements très différents : navigateur Web, explorateur de fichiers Windows, clients lourds.

Exemples d’architectures en production

L’architecture présentée ici est classique : il s’agit d’un déploiement de la solution Nuxeo (sur des serveurs JBoss load-balancés) qui s’appuie sur l’entrepôt JackRabbit (également sur des serveurs JBoss). Un serveur est dédié à l’indexation des documents (opération très coûteuse en matière de CPU), qui s’effectue de façon asynchrone (en tâche de fond). La persistance des méta-données est assurée quant à elle par des bases de données MySQL load-balancées.

Enfin, le repository est interrogé directement par des applications métier au moyen de l’API JSR 170 utilisant le protocole RMI.

Les critères de choix

Deux types de critères sont à prévoir pour le choix d’une solution de gestion électronique de documents : les critères fonctionnels (quelles sont les fonctionnalités disponibles nativement dans la solution ? Quel est le coût de développement de nouvelles fonctionnalités ?) et les critères de montée en charge.

Pour les critères fonctionnels, on s’attachera particulièrement aux éléments suivants :

• Normes implémentées (JSR 170, WebDAV, FTP, CIFS…), avec le niveau associé (en effet, certaines normes, comme WebDAV ou JSR 170, comportent différents niveaux)
• Workflow : Quels sont les types de workflows applicables (linéaire, parallèle, avec délégation, …) ? Comment peut-on définir un nouveau workflow (opération technique, via une interface graphique…) ? Sur quoi peuvent s’appliquer les workflows (auteur, profil, métadonnées, contenu d’un document, …) ? Etc.
• Versioning : Peut-on versionner les documents ? Le versioning est-il débrayable (par type de contenu, profil, espace…) ? Peut-on créer des version majeures et mineures ? Peut-on ajouter un commentaire ? Peut-on rendre la saisie d’un commentaire obligatoire ? Peut-on appliquer le versioning aux métadonnées ? Etc.
• Métadonnées : Peut-on saisir des métadonnées ? Peut-on extraire automatiquement des métadonnées dans les documents ? Peut-on ajouter des métadonnées personnalisées par paramétrage ou développement léger ? Peut-on rendre obligatoire la saisie des métadonnées ? Est-il possible de gérer des catégories ? Peut-on autoriser la création de nouvelles catégories par un utilisateur ? Etc.
• Transformation : Quels sont les formats reconnus par la solution ? Est-il possible de faire des conversions automatiques d’un format vers un autre ? Peut-on extraire des données automatiquement (via des transformations XSL par exemple) ? Etc.
• Partage : Est-il possible de partager des documents ? Comment gère-t-on les droits d’accès (au niveau global / par groupe / individuel) ? Peut-on commenter les documents ? Initier des forums de discussion ? Etc.
• Indexation et de recherche : La solution inclue-t-elle un moteur d’indexation et de recherche ? L’indexation prend-elle en compte les métadonnées ? Quels sont les types de documents reconnus et indexés ? Les droits d’accès sont-ils pris en compte dans les résultats de la recherche ? La solution permet-elle d’intégrer des sources de données externes ? Est-il possible de brancher un moteur de recherche externe ? Etc.
• Interface Web : L’interface Web est-elle ergonomique ? Peut-on la personnaliser (mise aux couleurs de l’organisation, choix des modules qui doivent apparaître…) ? Etc.
• Intégration dans l’environnement de travail : Comment l’intégration dans l’environnement de travail de l’utilisateur se fait-elle (CIFS, WebDAV, client lourd…) ? Est-il nécessaire d’installer une application sur chaque poste client ? Cette intégration fonctionne-t-elle avec des outils tiers (bureautique par exemple) ? Etc.
• Extensibilité : Est-il possible d’étendre la solution (ajout de modules, de fonctions, de types de documents supportés…) ? Cela peut-il se faire de façon non intrusive (mécanisme d’extensions, utilisation de hooks…) ? Etc.

Outre les aspects fonctionnels, il est impératif de prendre en compte les aspects de volumétrie et de montée en charge : en effet, les besoins en matière de documents gérés électroniquement sont amenés à évoluer rapidement (dématérialisation de procédures papier, archivage légal…) et la solution doit apporter suffisamment de souplesse pour évoluer dans le même sens. Ainsi, il doit être possible d’augmenter la volumétrie sans que cela ait d’impact notoire sur les fonctionnalités d’indexation et de recherche ; on doit pouvoir remplacer la couche de persistance (base de données, système de fichiers…) sans remettre en cause toute l’architecture ; éventuellement, il doit même être envisageable de changer l’entrepôt de documents tout en conservant les mêmes fonctionnalités utilisateurs.