Fil d'ariane

Icône

Se retrouver dans le dédale du savoir et de l'information – Pour une gestion structurée de l'information

Principe de séparation contenu, structure et présentation et autres irritants concernant SharePoint et autres systèmes d’entreprise

Ce principe de base connu depuis au moins une bonne décennie n’est toujours pas respecté par SharePoint, pas même SharePoint 2010, et autres grands joueurs de l’industrie. L’industrie, que ce soit Oracle, IBM ou autre ne semble pas accorder une grande importance à ce principe, ni celui de l’usage de la codification UTF8 ou autre codification étendue de chaînes de caratères ne se limitant pas à la langue anglaise.

Illustration

  • Au niveau fondation, les bases d’information servant de colonne vertébrale entre différents systèmes ou applications comme l’AD (Active Directory) ne supportent toujours pas les caractères accentués. Et, bien qu’il serve de plus en plus et en grande partie à être le dépôt d’informations de contact et de réseautage entre utilisateurs, le principe de base spécifiant qu’il faut séparer contenu, structure et sa présentation n’est toujours pas respecté : on ne peut utiliser qu’une seule langue d’affichage à la fois, donc si l’on veut supporter plusieurs langues, il est nécessaire de tout mettre dans un seul champ, des champs de libellé supplémentaires pour des langues alternatives n’étant toujours pas disponibles. Et si jamais par miracle, cela se produirait, svp, n’oubliez pas d’ajouter l’attribut de langue…
  • Les colonnes de SharePoint, toute version confondue,
    • l’identifiant de la colonne = son libellé : au mieux, il est possible de revenir en arrière pour renommer le champs selon un libellé plus humain si
      • on voulait avoir des url propres et constantes : ex. Intuitivement quand on crée une colonne, comme un seul champ apparaît, l’utilisateur a le réflexe d’écrire dans sa langue. Donc, si l’on veut par exemple créer la colonne « élément d’application », on se retrouve avec un champ qui renvoie %C3%A9l%C3%A9ment%5Fx0020%5Fd%5Fx0027%5Fapplication dans l’url, ce qui est très explicite quand on veut : référérer au lien ou au champs dans un code ou pour indexation
      • pourtant d’autres systèmes supportent depuis un moment la modification des espaces en _ ou en – au choix de l’administrateur de système, pour éviter cette prolifération de %20 illisibles et incompréhensibles pour les utilisateurs. Et proposent même de remplacer automatiquement les caractères ou signes diacritiques comme les é ou les ‘, le premier par le é sans accent et le second par, encore une fois, _ ou -, au lieu de %C3%A9 et %5Fx0027%5F, qu’il faudra retraduire dans une autre chaîne de caractères (même code) pour usage dans un autre système.
      • Il est même dans certains cas impossible de séparer l’identifiant unique d’un champ de son libellé, nous nous retrouvons donc prisonnier de ce charabia même en étant discipliné.
    • SharePoint n’utilise pas correctement et ni par défaut les métadonnées Titre, Keywords ou Description, par défaut, c’est le nom de fichier qui est utilisé et le champ titre n’est pas utilisé. 
      • Les métadonnées ne sont pas inscrites dans des tags xhtml, ce qui nuit à la trouvabilité et à l’optimisation du référencement. Cela crée par conséquent une surcharge de travail qui serait facilement épargnée sans ce comportement incompréhensible du point de vue de la gestion de l’information et des recommandations connues du W3C.
    • Dans SharePoint 2010, certes, je ne vais pas me plaindre de l’arrivée du Term Store, donc de la disponibilité de base d’un outil de gestion d’une ou plusieurs taxonomies.
      • Par contre, ce dernier même s’il permet de rendre disponible quelques fonctionnalités de thésaurus et peut faciliter, sans le garantir, une certaine cohérence dans  l’étiquetage des contenus à travers les sites, n’est pas connecté au moteur de recherche, que ce soit Microsoft Search, Fast ou un tiers outil. Il est nécessaire de maintenir les synonymies à deux endroits différents. Encore une fois, une surcharge de travail pour aider les utilisateurs à retrouver le contenu
      • Mais, ouf, les libellés multilingues sont supportés… C’est donc possible chez Microsoft quand ils veulent bien!!!

Les vendeurs comme Microsoft, IBM, Oracle et d’autres s’en sauvent en informant maintenant leurs clients qu’il existe une règle du 80/20, soit :

Pour implanter et configurer un système d’information, particulièrement un ECM (Enterprise Content Management), il faut répartir les efforts de la manière suivante:

  • 20% d’effort sur l’implantation technologique
  • 80% d’effort sur la gestion et la gouvernance de l’information

Or, cette pseudo règle de Paretto ne fonctionne pas puisque si le 20% dépend bien des TI, le reste est de la responsabilité, à tout le moins devrait être, sous le leadership autre que les TI, or la réalité est bien souvent la suivante : 100% du budget est dépensé sur la technologie et rien n’est prévu pour rendre les ressources disponibles du point de vue de la gouvernance et de la qualité de l’information. Plus souvent qu’autrement, les entreprises dépensent dans les technologies sans mettre l’effort utile pour rentabiliser leur investissement en espérant que cela se fasse comme par magie. Pour illustrer, c’est comme implanter une infrastructure d’écoulement des eaux usées, des égoûts et une robinetterie de la meilleure qualité qui soit tout en allant pomper l’eau dans une source polluée sans prendre la peine de filtrer l’eau, ni même de mettre en place une réglementation et des standards de qualité, avec mesures de conformité. Il en résulterait alors que l’eau ne sera pas potable et serait de la même qualité que celle des égoûts… C’est exactement ce qu’il se passe. Les gens d’affaire ne comprennent pas le rôle actifs qu’ils doivent jouer et la responsabilité qu’ils ont pour obtenir le retour sur investissement tant attendu.

Or, le 80% d’investissement dans l’information : aider à la rendre disponible tout en s’assurant que le système engendre le moins de distorsion possible, sa qualité et encadrer sa gestion (les différents flux et usages) n’est ni effectué durant l’élaboration de systèmes, ni durant leur livraison. Comment donc s’étonner que la productivité tant promise ne se réalise pas? Et cela n’est pas manque d’effort de la part des services des TI dans les entreprises.

Publicités

Classé dans:Ère du numérique

Données, transactions, documents… Cycle de vie de l’information

En échos à la réflexion que Jean-Daniel Zeller a commencé ici, je me propose de partager mes propres réflexions et observations par rapport à mon expérience. Il s’agit en effet de concepts avec lesquels nous devons jongler tous les jours dans le contexte du numérique.

Quand j’ai lu la 1ere fois l’article de M. Zeller, je ne pensais pas avoir quoi que ce soit à apporter comme commentaire aux postulats énoncés. J’y ai même trouvé d’éventuelles confirmations dans l’ouvrage suivant : Enterprise Ontology : Theory and Methodology de Jan Dietz. 

En effet, les systèmes d’information des entreprises doivent coller aux processus de création (invention, design, etc.), production et distribution de produits ou services. Le travail des informaticiens est de commencer par modéliser des processus. Les processus les plus « faciles » à modéliser, parce qu’ils sont découpables en actions simples et automatisables, sont les transactions. Un système est donc calibré pour gérer certaines transactions. Quand il s’agit d’échange de données discrètes, l’opération reste simple. La nécessité d’une intervention humaine reste limitée. Le système peut « interpréter » en fonction des possibilités prédéterminées identifiées lors de l’analyse des processus. L’informatique maîtrise ce type d’échange qui reste au niveau applicatif.

Par contre, cela devient beaucoup plus complexe au niveau du document (- rappelons que nous sommes le monde dématérialisé du numérique – un ou plusieurs fichiers, de format différents et/ou des informations composites de sources différentes). L’application ne sait plus alors qu’est-ce qui est quoi à moins qu’on l’explicite via des métadonnées, par exemple. L’être humain devient alors la véritable interface d’interprétation et de rétroaction (autre que de prendre connaissance). C’est là que l’interaction humain-machine prend son importance.

Mon point de vue s’est nuancé – ou plutôt complexifié – quand j’ai reçu le mandat d’aider l’équipe à retrouver, mieux partager et gérer ses documents de travail, à savoir tous ces fichiers qui sont le support de nos réflexions, de nos interactions, prises de position, modèles d’informations mais qui ne sont pas encore ou ne serons jamais des produits finis ou destinés à être utilisés tels quels. Ce rôle m’a permis de (re)prendre conscience de quelque chose qui ne semble pas pris en compte dans l’article de Jean-Daniel Zeller : dans le monde moderne, un document/fichier n’est pas nécessairement le résultat d’une transaction ou une trace officielle de quelque décision. Il contient de l’information pour mémoire, des notes pour plus tard, l’embryon de nouvelles idées, d’idées reformulées, etc. Cela ne veut pas dire que les postulats énoncés sont erronés, il s’agirait en fait  d’expliciter le cadre de validité qui semble implicite: quand les documents sont des preuves/traces de transaction, l’arrêt sur image de données, de sources différentes ou identiques,  mises ensemble  à un temps t, et contextualisées pour un événement X. Le « records » management s’intéresse à ce qui a valeur administrative, financière ou légale, mais le monde numérique a cette particularité que les brouillons ne sont plus des feuilles volantes que l’on jette au bac à recyclage, mais bien du matériel qu’on recycle intellectuellement et techniquement parlant, et qui nous évite de recommencer un modèle, un texte, une présentation de zéro. D’où une meilleure productivité. Par contre, plus personne ne veut jeter ces fichiers qui prolifèrent, si faciles à manipuler, mais si difficiles à retrouver, puisqu’on n’a pas pris la peine de mettre un titre, de les classer ou les trier… et que leur quantité croît à une vitesse phénoménale.

Donc, le document est plus que la trace de données ou de transactions, et le document n’a pas seulement valeur de preuve ou n’est pas nécessairement une publication mais est une sorte support pour connaissance explicitée que l’on veut garder pour soi ou pour partager, maintenant ou plus tard, pour ne pas recommencer de zéro, pour pouvoir le réutiliser.

Le records et le document management sont des outils qui peuvent aider à gérer les documents qui sont identifiés et identifiables avec  une valeur explicitée, ces derniers restent donc associés à une typologie assez traditionnelle et identique à ce qui existe dans le monde analogique. Par contre, les « work in progress » (wip) ne sont que très rarement gérés et encore moins catégorisables selon une typologie. Or il s’agit de la partie invisible de l’iceberg informationnel parce que les usagers s’attendent à ce que ces fichiers/documents soient trouvables – donc indexés – mais il ne sont que rarement correctement repérables parce que :

  • non définis et encore moins décrits : quel type de document ? quel type d’information ? combien de temps est-ce valide, est-ce seulement valide ?
  • et surtout non structurés, et
  • incroyablement nombreux et dupliqués ou avec très, très peu d’éléments de différenciation.

Donc, de nos jours, un document ne peut plus se définir seulement en tant que trace dans le sens de preuve, ni même en tant que publication. Et un fichier  informatique qui porte de l’information, n’est sans doute techniquement pas un document, mais reste néammoins un dépôt d’information structurée ou non qui peut avoir une valeur informationnelle en soi et avoir une utilité qui dépasse les raisons originales de sa création, à tout le moins au regard des utilisateurs.

On aura remarqué que j’ai beaucoup utilisé les termes document/fichier. C’est un fait que dans la vie de tous les jours, le langage courant confond fichier et document.  Ce n’est que lorsque l’on a besoin de définir qu’est-ce qui est quoi pour fin de modélisation ou de conceptualisation que l’on y réfléchit, et encore… Bref, il y a encore du pain sur la planche pour arriver à « apprivoiser » tous ces fichiers dont la durée de vie n’est pas statuée ou difficile à établir quand on n’est pas capable de qualifier vraiment de quel type d’information il s’agit. Mais le plus gros du travail reste l’éducation et la sensibilisation : réussir à faire comprendre qu’on a davantage un problème de sur disponibilité de l’information, ce qui nous freine dans la prise de décision, qu’un problème de non disponiblité de l’information.

Classé dans:Cycle de vie, Documents (accès, organisation, structuration), Documents numériques, Gestion de l'information

Architecture de l’information en marche

Il y a longtemps que je n’ai plus écrit sur ce blogue pour plusieurs raisons : dont l’apprentissage d’un métier et du fonctionnement d’une organisation assez complexe et particulière.

Mon rôle chez SNC-Lavalin me passionne. Ce n’est pas une situation « traditionnelle » pour quelqu’un qui a obtenu un diplôme en sciences de l’information, dans le sens de bibliothéconomie et archivistique, mais pas plus traditionnelle non plus, du point de vue des technologies de l’information.
Je suis entrée à l’emploi en tant que taxonomiste sans trop savoir ce que ça impliquait vraiment, pas plus que ceux qui m’ont embauché d’ailleurs. Ces circonstances aurait pu mener nulle part : pourquoi un département d’informatique embauche une taxonomiste alors qu’il n’y même pas encore de projet concret, et qu’en plus, les technologies de l’information gèrent certes les systèmes d’information, mais ne sont pas responsables de la qualité du contenu (l’information en tant que tellle) et en sont encore moins le propriétaire moral, administratif ou même légal.
J’ai d’ailleurs passé un certain temps à :
– essayer de trouver un moyen d’expliquer mon rôle à mes collègues alors même que j’avais moi-même besoin de le comprendre. J’avais saisi l’idée globale que je devais aider à trouver l’information. Là où ça devenait compliqué, c’était de donner un exemple concret et parlant parce qu’il n’y en avait pas encore. Le travail était encore à l’état de concept, d’hypothèses de mise en application, sans garantie d’obtenir les ressources, financières ou technologiques nécessaires pour la mise en pratique puisque, justement, comment obtenir un budget et une approbation pour quelque chose qui semble ésotérique et très peu relié aux affaires (puis ça change quoi dans la livraison de nos services ?). Donc, vous aurez compris que j’aussi dû…
– trouver un moyen d’expliquer mon rôle à des personnes, hors du département d’informatique, pour essayer de leur faire comprendre en quoi mon travail pourrait aider le leur et que j’avais besoin de leur collaboration, notamment m’aider à repérer le vocabulaire, le catégoriser et l’organiser de manière à aider à retrouver leur information et le savoir-faire inscrit, éparpillé et noyé dans une masse énorme d’information (une centaine de sites web de projets, presque une 10aine de millions de documents indexés par un moteur de recherche d’entreprise, dont des duplicatas obsolètes et non contrôlés, des fichiers temporaires non détruits, sans compter les répertoires réseaux de groupes ou personnels, les fichiers attachés dans les courriels, etc.). Si donc, la plupart saisissent l’idée, il leur est difficile de voir comment cela pourrait se concrétiser et surtout de savoir ce que ça implique… Et tant qu’on ne voit pas, on a des doutes. Je savais que ça marcherait potentiellement mais expliciter comment ça fonctionne et pourquoi ça fonctionne, sans pouvoir le démontrer concrètement, c’est autre chose.

Finissant par avoir moi-même besoin de voir concrètement comment cela pourrait se mettre en place, j’ai donc travaillé avec les moyens dont nous disposions, à savoir, en exploitant la technologie existante et les moyens du bord. Mon expérience passée en gestion de systèmes et mes connaissances en gestion de réseau m’ont permis d’avoir la crédibilité nécessaire pour obtenir la permission de faire des expérimentations avec le moteur de recherche, dans un environnement de développement (sans nuire pas au fonctionnement réel de tous les jours). J’ai ainsi pu apprendre à exploiter les fonctionnalités du moteur de recherche et commencer à utiliser, par exemple, la fonction thésaurus et les possibilités d’exploiter les métadonnées des documents pour fournir des résultats de recherche plus parlant et filtrables via des facettes… La taxonomie prenait une forme concrète. Il suffisait de montrer ce qu’il était possible de faire juste en exploitant ce qui existait déjà mais restait invisible.
Je suis ainsi devenue la spécialiste fonctionnelle du moteur de recherche. Le moteur de recherche plus utilisé et mieux perçu, mais ce n’est pas gagné… La masse informationnelle augmente très, très rapidement, donc se limiter à ce qui est fait spontanément n’est pas suffisant, il faut continuer à convaincre, à éduquer et … à faire ce qu’on peut avec les moyens du bord.

De fil en aiguille, le moteur de recherche ont été associé à moi. « On a de la difficulté à retrouver notre information, il paraît que vous pouvez nous aider… » Ces appels ont été de petites victoires qui m’ont aidé à avoir puis entretenir ma crédibilité, à me rassurer sur le fait de ne pas lâcher et que j’étais sur la bonne voie. Le moteur de recherche est devenu le moyen pour démontrer en quoi une information mieux gérée : catégorisée, décrite, filtrée, triée ou détruite quand nécessaire, facilite la trouvabilité.

Puis, environ six après mon embauche, le fonctionnement du département d’informatique a été revu et je me suis retrouvée dans une nouvelle équipe : l’architecture globale d’entreprise. Je ne me serais jamais trouvée au sein de cette équipe si je n’avais pas obtenu ces petites victoires, et, encore moins, si mon supérieur ne m’avait pas laissé faire, n’avait pas compris ce que j’essayais de faire et utilisé ces exemples lui-même dès qu’il en avait l’occasion pour démontrer qu’il était possible d’agir et que ce n’était pas seulement théorique.

De taxonomiste, je suis devenue spécialiste en architecture et je travaille en collaboration avec des architectes technologiques (ce que j’appelle la tuyauterie, la logistique de transport et de communication : le réseau de circulation des données et des informations), des architectes systèmes (la vue micro des systèmes : quels sont les processus pour réaliser une transaction, une action, quels sont les intrants et les extrants) et des architectes de données/information (comment les données passent d’un système à l’autre?, sont produites, par qui, quoi? contrôlées par qui, comment? y’en-a-t-elles qui sont communes entre les systèmes, ont-elles la même définition? etc.).

L’aventure est donc devenue collective et ensemble, particulièrement avec les architectes de système et de données, nous essayons de développer une pratique d’architecture de l’information d’entreprise, à savoir une architecture informatique qui intègre les données structurées (les bases de données, notamment) et les informations non structurées (les contenus web, les fichiers bureautiques, les dessins industriels – qui peuvent être des fichiers CAD mais sont de plus en plus des bases de données -).

Le travail du taxonomiste ou de l’architecte de l’information (pas dans le sens d’ergonome web) ne se limite donc pas au web mais pourrait trouver sa place en collaboration avec les architectes de données et de système. L’autre voie possible est d’aider à rendre les technologies sémantiques plus performantes : à titre d’analyste de résultats ou pour le développement de tels outils.
Le paradigme binaire 0-1 ou vrai-faux qu’offre l’informatique n’est plus suffisant. Les décideurs ne disposent que de peu de temps de réaction pour décider sur la base d’une masse d’information qui n’est humainement pas appréhendable aussi rapidement. L’environnement est complexe et change très vite, arriver avec un nombre limité d’options entre lesquelles il faut trancher n’est pas si évident, la réalité est bien plus dans les nuances que dans le noir et blanc. Les outils sémantiques sont donc une voie possible pour assister les prises de décisions et pour compléter les solutions traditionnelles de BI (business intelligence) qui fouillent des données structurées. Or ces outils sémantiques sont basés sur des modèles statistiques articulés sur des ontologies, des moyens qui restent donc mécaniques. Or rien n’est pertinent ou non pertinent en soi. Tout dépend du contexte et du sens. Une machine peut déterminer selon un modèle que cela est le plus probable, sans juger du résultat, mais cela ne veut pas dire que cela a du sens et est vrai… . L’humain reste l’élément capable de juger si cela est possible ou non. L’humain seul peut réintérroger le résultat et déterminer s’il est satisfaisant ou non. Ainsi, les taxonomistes qu’ils viennent de la linguistique, de l’informatique, l’ingénierie, des sciences pures ou de la bibliothéconomie ont donc une belle voie d’avenir devant eux.

Personnellement, j’aime mon travail parce que justement il n’y a pas de réponse toute prête et qu’il faut inventer. Les tâches que j’exécute se formulent au fur et à mesure que des besoins émergent ou des possibilités/obstacles se présentent.

Classé dans:Classification, Documents (accès, organisation, structuration), Métadonnées, Taxonomie, Web sémantique,

Karin Michel, M.S.I.
Architecte d’information et de données, Gouvernance de l’information et des données

M.S.I obtenue à l'École de bibliothéconomie et des sciences de l'information
Université de Montréal
Québec - Canada

Les propos tenus sur ce blogue sont des réflexions personnelles et n'engagent en rien mon employeur ou quelque personne que ce soit avec laquelle je travaille.

Intérêt en
gouvernance des données, architecture d'entreprise, modélisation de données, knowledge management, RIM, GID / GED, architecture de l'information et de données, ..., analyses de besoins, etc.
Logo AIIM SharePoint Practioner

Pages