Dynacase Platform, une autre solution de gestion de documents et bien plus...

Linux Pratique

n°

septembre 2010

Par

Charpentier Claude

Bureautique

Tag(s)

documentation

travail collaboratif

Dans Linux Pratique n°58, vous avez découvert Alfresco. Je vous propose aujourd'hui de découvrir un autre outil de gestion de documents au sein de l'entreprise. Il serait plus juste de parler de boîte à outils car Dynacase Platform permet bien plus qu'une simple gestion de documents. Dynacase Platform est un atelier de développement permettant de créer des applications collaboratives basées sur la production, la circulation et la recherche d'information.

1. Introduction

Un peu comme dans l'article précité en introduction, j'ai moi-même utilisé Microsoft Sharepoint auparavant. La description ayant déjà été faite dans l'article cité, je ne reviendrai pas dessus. Sharepoint nous a déçus sur certains points, comme la gestion des droits, la difficulté de développement et de personnalisation. Face à cette problématique, le changement de l'outil s'est imposé pour aller vers une solution plus simple, plus souple, mais puissante.

Un point était sûr, la prochaine solution serait open source. Après une étude des solutions sur le marché répondant à ce critère, j'ai choisi Dynacase Platform (à l'époque, le logiciel s'appelait Freedom-ECM) pour plusieurs raisons :

sa puissance ;
sa souplesse ;
sa facilité de prise en main ;
sa gestion des droits ;
son évolutivité.

En effet, ne connaissant pas Java et étant en charge de l'outil, les développements futurs risquaient d'être un peu compliqués et il n'était pas à l'ordre du jour de sous-traiter les évolutions suite aux futurs besoins utilisateurs.

Dynacase Platform version 3 est distribué sous licence AGPLV3. Il est développé par la société française Anakeen [1].

2. Architecture

2.1 Architecture logicielle

Dynacase Platform est basé sur PHP, Ext JS et PostgreSQL. Son installation est aisée et s'effectue via un installateur web basé sur Ext JS (appelé WIFF), il suffit de choisir les modules voulus et de lancer l'installation (Fig. 1).

Fig. 1 : Voici le DYP Installer qui permet l'installation et l'exploitation de Dynacase Platform et des modules complémentaires.

Grâce à ce système, Dynacase Platform pourra être installé sur n'importe quelle distribution, du moment que les prérequis seront installés [2]. On pourra ainsi facilement installer les modules nécessaires à notre besoin et enrichir le périmètre par la suite.

Dynacase Platform ne nécessite aucune installation sur le poste client, il est full web, il suffit d'un navigateur web comme Firefox pour accéder aux documents.

2.2 Architecture logicielle

Au sein de Dynacase Platform, tout est considéré comme document. Un document est un assemblage d'informations plus ou moins structurées. Cela permet d'importer des documents via fichier CSV, que ce soit des familles, des documents, des utilisateurs, ...

Dynacase Platform est, comme je l'ai dit plus haut, composé de modules qui constituent en général une application. Ces applications une fois développées donneront lieu à des paquetages que l'on pourra importer directement dans le système via le DYP, comme on installerait un paquet Debian ou autre...

3. Couverture fonctionnelle

Je parlerai ici de la problématique que j'ai vécue au sein de l'entreprise lors du déploiement de Dynacase Platform. Il s'agissait de reprendre les documents classés en catégories :

Mode opératoire ;
Plan de prévention ;
Produits dangereux ;
Protocoles sécurité ;
[ … ].

Chacune de ces catégories a donné lieu à une famille.

3.1 Reprise des documents existants

Il est souvent plus facile de démarrer ce type de projet quand rien n'existe, mais ce n'était pas le cas. Il fallait donc tourner à son avantage tous les inconvénients relevés avec l'ancienne GED pour que la nouvelle solution soit accueillie avec enthousiasme.

Il a donc fallu reprendre tous les documents existants pour les intégrer dans Dynacase Platform. Cela représentait environ 1000 documents (au format MS Word, MS Excel, images, fichiers PDF, ...). Il était hors de question de reprendre un à un les documents et de les enregistrer au sein du système. Dynacase Platform permet l'import « en masse » via un fichier OpenOffice.org Calc au format CSV (Fig. 2). Il suffit d'y renseigner certains attributs [3] pour que les documents soient injectés au sein du système, comme on le ferait avec un nouveau document.

Fig. 2 : Voici un exemple de fichier CSV d'import de documents.

Sur la figure 2, vous pouvez visualiser un exemple de fichier d'import qui comporte :

IMPFAM : le nom de notre famille ;
<specid> : cette colonne contient le nom des documents ;
<fldid> : cette colonne contient le nom du répertoire lié à la famille ;
Titre : est le titre de notre document ;
Commentaire : est un champ de métadonnée.

Terminologie

Les propriétés sont les données propres aux fichiers (dans OpenOffice.org : Fichier > Propriétés), comme la date de création, l'auteur, le type de document.

Les métadonnées sont des champs qui permettent d'enrichir les propriétés pour faciliter les recherches futures, comme des mots-clés.

Les attributs sont propres à des documents structurés (formulaire, par exemple) et permettent de spécifier le sens du document.

3.2 Définition des familles

Une famille dans Dynacase Platform constitue la gestion d'un type de document. Par exemple, nous avons créé une famille pour notre besoin, appelée « Procédure ». Cette famille va donc regrouper toutes les procédures. Au niveau de cette famille seront définis :

les attributs ;
les droits d'accès ;
le cycle de vie.

Suite à nos spécifications, nous nous servirons d'un fichier CSV afin d'importer notre famille au sein de Dynacase Platform.

3.2.1 Les attributs

Pour nos documents procédures, nous allons créer ces attributs :

un titre ;
un trigramme (permettra de calculer une référence de document) ;
une date de création ;
un auteur ;
un identificateur pour l'auteur ;
un chrono (numéro qui servira à la référence également) ;
une date de révision ;
un indice de révision ;
un champ pour les pièces jointes ;
un champ droits de lecture contenant des personnes ;
un champ identificateur lecteur.

Il ne figure pas de valideur car pour le service en question, une seule personne valide tous les documents et ce champ a donc été pré-renseigné.

Les personnes ayant le droit de consulter le document seront spécifiées dans le champ Droits de lecture permettant ainsi pour chaque document d'avoir des personnes différentes sans pour autant donner accès en lecture aux autres documents de la même famille. Les lecteurs ne verront que la version des documents qui auront le statut validé.

3.2.2 Les droits d'accès

Les droits d'accès génériques seront définis au niveau de la famille, ainsi que des documents qui en dépendent. Il s'agira donc de créer des profils permettant de définir quel groupe a le droit de voir/modifier/créer/valider un document (Fig. 3).

Fig. 3 : Définition des droits au niveau d'une famille.

3.2.3 Le cycle de vie

Le cycle de vie est relativement simple (Fig. 4). On peut à chaque transition du cycle de vie exécuter une action particulière :

de l'état Brouillon vers En cours : on notifie par mail au valideur qu'un document est à valider.
de l'état En cours vers Brouillon : si le valideur refuse le document, il le repasse à l'état Brouillon et déclenche une notification par mail qui avertit l'auteur du document que celui-ci est à modifier.
de l'état Validé vers Brouillon : cette action aura pour effet d'archiver la version du document et d'en créer une nouvelle copie. Son indice de révision est incrémenté et la date de révision renseignée.

Chaque étape du cycle de vie peut se voir attribuer des droits différents (Fig. 5). Dans notre exemple, le créateur du document peut éditer son document quand il est au statut Brouillon. Quand il estime que son document est fini, il le soumet à validation en passant son statut à En cours. Le valideur reçoit un mail l'invitant à valider le document avec un lien direct vers celui-ci dans le mail. S'il valide le document, celui-ci peut être vu par les lecteurs, si le valideur le repasse au statut Brouillon, le créateur reçoit un mail lui indiquant que son document est à revoir, accompagné de la justification.

Fig. 4 : Voici le cycle de vie qui sera appliqué aux documents.

Fig. 5 : Voici les droits des transitions du cycle de vie qui est appliqué aux documents.

3.3 Fichier d'importation de notre famille

Après cette étape d'analyse qu'il ne faut surtout pas négliger, on dit que souvent 80% du travail est fait ; la figure 6 présente un extrait du fichier CSV d'importation de notre famille. Ce fichier peut paraître compliqué mais on se fait très vite à sa structure. Pour chaque champ, un paramètre de visualisation est défini pour savoir si ce champ sera caché, visible, accessible en lecture seulement, …

Ces propriétés pourront être redéfinies via des contrôles de vues. Si l'on considère, par exemple, qu'une partie doit être visible en lecture pour le valideur, on définira un masque de saisie pour le rôle valideur et un masque de saisie pour le lecteur.

Les contrôles de vues constituent une sur-couche aux paramètres de visualisation, qui permettent ainsi de créer, selon les différents rôles au sein de la GED, un écran « sur mesure » permettant ainsi de n'afficher que les champs désirés afin de simplifier la saisie, la lecture, ... Pour chaque profil, on définira un masque de saisie qui constituera notre contrôle de vue.

Fig. 6 : Exemple de fichier Open Office d'importation de famille

4. Gestion des utilisateurs

Comme je l'ai dit au début de l'article, tout est document dans Dynacase Platform. Il en est de même pour les utilisateurs qui font partie de la famille « Utilisateurs » ainsi que pour les groupes qui font partie de la famille « Groupes ».

Au même titre que n'importe quel document, les utilisateurs peuvent être importés via un fichier CSV. Pour les possesseurs d'un annuaire OpenLDAP, Dynacase Platform est pourvu d’un connecteur permettant d'utiliser cet annuaire pour l'authentification.

D'autres modes d'authentification sont disponibles, dont l'authentification à partir d'un serveur CAS.

5. Accès au proof of concept

Dynacase Platform est une plate-forme permettant de créer des applications métiers. Ce n'est donc pas une application verticale et c'est à chacun de créer son application en fonction de ses besoins. Pour illustrer cette capacité, l'éditeur Anakeen met à disposition lors de l'installation un module appelé ECM. Ce module qui a été développé pour les besoins internes d'Anakeen est aussi le proof of concept (démonstrateur) de Dynacase Platform.

Fig. 7 : Le démonstrateur de Dynacase Platform

Conclusion

Dynacase Platform est donc déployé au sein de l'entreprise. Ce déploiement va être étendu à tous les services : RH, Commercial, Recherches et développements, ... qui auront tous leurs intérêts à gérer des documents et développer des « applications » au sein de Dynacase Platform. Cela est rendu possible par la souplesse de cette boîte à outils que constitue Dynacase Platform. Son installation a été simplifiée avec l'arrivée du DYP. Son évolution est continue, à l'heure où j'écris cet article, la version 3.0.7 est sortie et la version 3.1 [4] est prévue pour septembre 2010.