Tag Archives: GED

26Mai/20
Le Mans Métropole - bluexml expert ECM GED BPM Archivage Signature électronique

Retour d’expérience : Le Mans Métropole dématérialise les fiches de synthèse des marchés publics

Afin de faciliter le suivi des marchés publics et donner la possibilité aux différents acteurs de consulter les documents de synthèse des marchés, Le Mans Métropole a développé un outil indépendant des applications métiers.

Le retour d’expérience complet est disponible sur le CLUB.

30Avr/19

(3/3) Analyse d’une politique documentaire : cas client

Etude fonctionnelle : Politique documentaire

A partir des éléments injectés dans ELK, on peut également obtenir un export csv répondant à la requête. On peut ainsi reconstruire pour chaque source un fichier csv avec la liste des 3 premiers niveaux d’arborescence et extraire automatiquement une carte cognitive. Cette dernière facilite la communication et permet une analyse “a priori” puis un travail de reconstruction avec un spécialiste métier.

On a ainsi les images Avant/Après facilitant la conduite du changement et la mise en oeuvre d’un plan d’actions.

L’étude porte ainsi sur les éléments suivants :

  • M: Lecteur réseau organisationnel : contient des répertoires pour chaque service de l’organisation ;
  • N: Lecteur réseau commun : contient des répertoires pour chaque projet ou élément commun à l’organisation ;
  • O: Serveur Alfresco : contient les répertoires pour chaque nouveau projet ou chaque nouvel élément commun qui est basculé sur le serveur Alfresco. Les éléments organisationnels sont aussi peu à peu basculés sur Alfresco.

M: Lecteur Organisationnel

Les premiers niveaux d’arborescence sur un serveur réseau “organisationnel” correspondent généralement aux niveaux suivants :

  • Direction
  • Département
  • Service…

Arborescence

On peut extraire ce genre de carte :

/Users/bxml/Desktop/Tmp/Screenshots/Capture d’écran 2019-04-09 à 11.33.21.png

Eléments communs

On trouve normalement des éléments liés à l’organisation de la direction/service/cellule, à la gestion opérationnelle des personnels associés (RH, formation, règlement intérieur…) :

  • Plannings
  • Congés
  • Compte-rendus
  • Modèles
  • Outils
  • Processus

Conclusion

A la lecture des plans de classement, on constate souvent des anomalies de ce type :

  • Trop d’éléments, rendant la compréhension difficile ;
  • Des références à des personnes (via leur nom, leur prénom) empêchant un stockage mutualisé des informations ;
  • Des références à des événements précis (via la date d’une journée), empêchant le stockage d’éléments ultérieurs ;
  • Des noms mêlant une information et une année, empêchant une déclinaison naturelle sur plusieurs années
  • Des noms correspondants à des types de fichiers, obligeant à parcourir le répertoire pour connaître son contenu

N: Lecteur commun

Désolé, cette section est n’est pas reproduite car les éléments issus d’une réelle étude client sont trop nombreux pour être anonymisés correctement.

O : Serveur Alfresco

Arborescence

/Users/bxml/Desktop/Tmp/Screenshots/Capture d’écran 2019-04-09 à 11.35.07.png

L’arborescence ci-dessus a été construite en regroupant manuellement les éléments. En effet, le concept de site ne supporte pas les hiérarchies qu’on reproduit généralement à l’aide de conventions de nommage.

Bonnes pratiques : les préconisations

On reprend les anomalies précédentes et on liste les solutions possibles :

Trop d’éléments gêne la visibilité

Afin de permettre une navigation fluide et pertinente, il faut respecter les règles suivantes la compréhension, la mémorisation :

  • Eviter plus de 20 éléments par répertoire
  • Créer des sous-répertoires pour regrouper les éléments par thèmes/sous-thèmes
Eviter les références aux éléments susceptibles de changer

Ce sont les personnes qui changent le plus dans les organisations. Ainsi, il faut éviter les noms et/ou prénoms dans les noms de répertoires (Michel, Stéphanie…) car lorsque la personne s’en va, il est difficile de savoir si les données sont privées, quels sont les thèmes concernés, ce qu’il faut garder, jeter… C’est le genre de répertoire qu’on retrouve plusieurs années après le départ de la personne…

Isoler les années

Il faut éviter de nommer un répertoire en ajoutant une année, caractéristique des événements, car cela bloque les regroupements automatiques. Si l’événement est amené à se reproduire, alors faire un répertoire du nom de l’événement puis un répertoire avec les années. Le fait d’isoler l’année permettra de consolider les données au niveau tranverse.

Ne pas utiliser de répertoires explicitant le type des fichiers

Cette information peut être obtenue automatiquement par la GED en se basant (en partie) sur le suffixe du fichier, il n’est donc pas nécessaire de l’expliciter et lui préférer un répertoire porteur de sens.

Donner du sens

Il est plus facile de mémoriser une arborescence porteuse d’une logique métier, que l’utilisateur manipule tous les jours de manière implicite, plutôt qu’une succession de tâches qui peuvent être très variées. L’arborescence devient du coup dure à comprendre et à suivre avec le risque que des répertoires redondants soient créés.

Conclusions

Revoir les PDC en fonction des règles ci-dessus et faire des préconisations pour chaque service département, service, mission, projet… Attention, le traitement de répertoires correspondant à des unités organisationnelles complexes (avec plusieurs centaines de milliers de fichiers) sera plus long que les répertoires d’une simple unité organisationnelle (avec quelques centaines voire milliers de fichiers au maximum).

Conclusion

L’utilisation d’un système d’indexation est fondamentale pour vous aider à connaître votre système documentaire, pour l’améliorer et vous aider à la conduite du changement en identifiant les sources de gaspillage et les pistes d’amélioration.

Afin d’avoir un véritable système outil de supervision et de pilotage de votre SI documentaire, il est nécessaire de mettre en place une collecte continue des informations seul moyen qui permettra d’obtenir un outil de supervision en temps réel de votre SI documentaire.

 

Suivez bluexml sur les réseaux sociaux

24Avr/19

(2/3) Analyse d’une politique documentaire : cas client

Etude technique : indicateurs

Généralement, les indicateurs attendus sont les suivants :

  • Répartition et évolution des documents en nombre et volume
  • Comprendre les pics de création de documents
  • Répartition des documents en fonction de l’organisation (DGA/Pôle/Département ou Service…)
  • Répartition des documents par type de fichiers (extension)

L’indicateur supplémentaire suivant, plus complexe à calculer, est souvent attendu :

  • Recherche de doublons

Phase1 : répartition et évolution

Evolution du nombre total de documents et de leur volume par serveur

Le stockage est actuellement réalisé sur 3 composants :

  • Lecteur réseau M : (Organisationnel)
  • Lecteur réseau N : (Commun)
  • Lecteur 0 : (Serveur Alfresco)

Le nombre de documents augmente constamment sur chaque composant alors qu’on pourrait s’attendre à voir diminuer ce nombre sur les serveurs réseaux au profit du serveur Alfresco. Au contraire, on constate même que le nombre de documents augmente plus vite sur le lecteur réseau « Organisationnel ».

Alfresco est vraisemblablement utilisé pour répondre à d’autres besoins, notamment des besoins collaboratifs.

Répartition des documents en nombre et en volume entre les différents serveurs

Evolution mensuelle du nombre de création de documents et de leur taille moyenne quelle que soit l’origine des documents

En cliquant sur un point précis, on peut avoir l’explication de sa valeur avec le détail des éléments ayant permis son calcul, comme la liste des documents comptabilités. On s’aperçoit ainsi que les pics de création de documents correspondent à des imports en grand nombre d’éléments de taille importante venant par exemple de la direction technique ou de la communication.

Répartition du nombre de documents par Niv1 (DGA) x Niv2 (Pôle) x Niv3 (Direction…)

Répartition des documents en fonction du nombre et du volume selon leur extension

 

Phase 2 : Recherche des doublons

Plusieurs solutions sont possibles :

  • lister les fichiers avec le même nom et regarder par la suite si les documents sont identiques (même taille et même md5). Le hash md5 peut être long à calculer sur des millions de fichiers, cette approche n’est pas toujours envisagée ;
  • lister les fichiers avec le même nom et la même taille en une seule passe et vérifier par la suite s’ils ont la même taille.

Cette seconde approche est souvent plus simple et plus rapide à mettre en oeuvre.

Script

La requête suivante sur ELK permet de récupérer tous les fichiers de plus de 10K dont le nom et la taille sont identiques. Pour garantir qu’il s’agit de doublons, il faudrait utiliser un hash md5 mais à défaut de celui-ci cela permet d’avoir une forte présomption de doublon.

 

Sur cette base, on peut obtenir un fichier json, qui peut être converti en csv, avec finalement les résultats suivants :

  • Nombre de fichiers > 10 Ko étudiés avec le même nom et la même taille : 10 000 fichiers
  • Nombre de résultats : 309 173
  • Nombre de répétitions : 16 à 2432 (situation.xls)
  • Place occupée : 1 835 Mo
  • Place optimale : 115 Mo

La taille est multipliée par 15, le nombre de fichiers par 35, ce qui entraîne un gaspillage de ressources, de temps et de maintenance et risque de se traduire par la conservation ‘ad vitam’ de centaines de milliers (pour ne pas dire plusieurs millions) de fichiers redondants…

Les 25 plus grandes répétitions quelle que soit la source

Dans notre cas d’utilisation, on ne connaît que les noms de fichiers, mais pas la source. Pour cela, il faudrait faire une requête supplémentaire sur chaque nom afin de savoir comment il se répartit sur chaque racine.

Le nom des fichiers répétés permet de se faire une idée des fichiers redondants.

Les 25 plus grands gaspillages

Conclusion

L’analyse des doublons est un peu “laborieuse” (données à nettoyer). Un indicateur intéressant serait de calculer la répartition des doublons d’un même fichier sur différentes sources afin de mieux comprendre le mécanisme de propagation et mettre en place des actions pour modifier les comportements.

16Avr/19
/Users/bxml/Desktop/Tmp/Screenshots/Capture d’écran 2019-04-09 à 11.49.26.png

(1/3) Analyse d’une politique documentaire : cas client

Préambule

Ce billet de blog présente le travail réalisé pour un client institutionnel dans le cadre d’une mission d’analyse de leur politique documentaire.

Ce billet se décompose en 3 parties :

  • Présentation de l’objectif, du contexte et de la démarche
  • Présentation de l’étude technique avec une partie des indicateurs obtenus
  • Présentation de l’étude fonctionnelle avec une partie des arborescences

/Users/bxml/Desktop/Tmp/Screenshots/Capture d’écran 2019-04-09 à 11.49.26.png

 

Introduction

L’objectif de l’audit est de réaliser une analyse des contenus stockés dans leur fonds documentaire dans leur totalité (environ 20 To) :

  • un serveur de fichiers Windows, organisationnel (avec les contenus de chaque direction) ;
  • un serveur de fichiers Windows, communs (avec les contenus transverses) ;
  • un serveur de GED Alfresco (avec les contenus collaboratifs).

Cette analyse s’effectue généralement en collaboration avec la DSI et se décompose en 2 parties :

  • une étude technique des contenus stockés sur les différents composants ;
  • une étude fonctionnelle de ces contenus.

Démarche

L’objectif est de lister tous les fichiers contenus dans les systèmes ci-dessus, en récupérant les métadonnées disponibles dans un fichier au format csv. Le nombre de fichiers étant considérable, cette collecte est découpée en plusieurs sous-ensembles afin de ne pas surcharger le système lors de la récupération de ce listing. En outre, afin de pouvoir analyser les contenus extrêmement nombreux (plusieurs millions de ligne), un tableur n’est pas suffisant, il est ainsi prévu d’indexer et rechercher les contenus à l’aide de l’outil spécialisé Elasticsearch (ELK) de la société éponyme.

 

Listing au format csv

Liste des fichiers

Deux scripts ont été écrits en powershell 2 afin de permettre la récupération de ces éléments sur Windows :

  1. Un premier script liste les éléments principaux de premier niveau (c’est à dire les sous-répertoires) du répertoire passé en paramètre et appelle un deuxième script pour chacun des sous-répertoires principaux identifiés ;
  2. Le deuxième script liste tous les fichiers contenus dans le répertoire principal ou un de ses sous-répertoires.

Le premier script pilote le deuxième script. Le premier script a été lancé à la main à des moments propices (soirée, veille de we) pour éviter de trop surcharger le système pendant l’exploitation quotidienne.

Le fichier csv ressemble à ceci :

En parallèle du lancement des scripts de comptage, il faut également lancer la fonction de Windows permettant de compter le nombre et le volume des fichiers et répertoires pour un répertoire donné.

Erreurs

Certaines erreurs apparaissent :

  • répertoires inaccessibles, pour des raisons de droits ;
  • répertoires ou fichiers avec un nom trop long ;
  • répertoires ou fichiers avec des caractères interdits.

Dans l’absolu, il faudrait traiter ces erreurs. Cependant, un comptage a été fait en parallèle par le système Windows et comparé au nombre de répertoires et fichiers trouvés via les scripts ci-dessus. La différence n’est pas significative et on peut simplement ignorer ces erreur.

 

Injection dans le système d’indexation ELK

Le système d’indexation ELK facilite le comptage et le regroupement des données en fonction des indicateurs souhaités afin de faciliter le calcul des éléments techniques mais aussi l’étude du fonds documentaire.

ELK est un système d’indexation de contenus basé sur 3 composants :

  • Logstash pour la récupération et l’analyse des données en amont, en l’occurrence les fichiers csv générés par les scripts précédents ;
  • Elasticsearch, pour l’indexation des données ;
  • Kibana, pour la navigation dans les données.

Traitement et import des données

Logstash permet le traitement et l’import des données afin d’extraire toutes les informations souhaitées. Par exemple, l’extraction de la source de données (Lecteur M: dans notre cas) ou la conversion de la taille des documents en Ko afin de faciliter la lecture. Attention à bien conserver toutes les données afin de pouvoir les réutiliser si nécessaire.

Requête et comptage

Elasticsearch permet la création de requêtes pour extraire et compter le nombre de fichiers comme par exemple compter le nombre de documents par source ou leur taille.

La requête suivante permet par exemple de ne compter que les documents respectant certaines contraintes :

 

Tableaux de bord

Kibana permet la création de tableaux de bords, notamment avec la fonctionnalité TimeLion permettant de calculer et afficher des indicateurs sur le même graphique afin, par exemple, de comparer l’évolution du nombre de documents dans le temps en fonction de leur source.

/Users/bxml/Desktop/Tmp/Screenshots/Capture d’écran 2019-04-08 à 16.48.56.png

 

Comptages des répertoires et fichiers par source

Lorsque tous les éléments ont été injectés dans le moteur d’indexation, on compare alors les éléments obtenus entre le comptage Windows et le comptage ELK afin de vérifier que les erreurs ne sont pas significatives.

 

M:\Organisationnel

Les comptages sont les suivants :

Répertoire principal Nb de répertoires Nb de fichiers Volume
Total comptage listing via le calcul de Windows 1 309 910 10 798 669 16,1 To
Total comptage index 1 305 950 10 171 949 17,1 To

 

N:\Commun

Les comptages sont les suivants :

Répertoire principal Nb de répertoires Nb de fichiers Volume
Total comptage listing via le calcul de Windows 581 770 3 402 133 3,45 To
Total comptage index 564 576 3 089 141 3,64 To

O:\Alfresco

Un lecteur réseau a été monté sur le serveur Alfresco afin de pouvoir lister les fichiers stockés à la racine et dans les sites. Dans notre étude de cas, du fait du faible stockage et du faible nombre des éléments stockés en dehors des sites, qui représentent à peine 10 Go et quelques milliers de fichiers, ils n’ont pas été importés et ont été ignorés dans l’analyse.

Répertoire principal Nb de répertoires Nb de fichiers Volume Remarques
Total comptage index 50 113 295 702 781 Go 115 sites

 

 

Suivez bluexml sur les réseaux sociaux