Les petites cases

Quelles sont les éléments d'une architecture documentaire ?

Dans une organisation, on crée et on échange de l'information. Mais on n'y accède pas de manière uniforme : selon les personnes qui veulent y accéder ou utiliser ces informations, selon leurs différentes fonctions dans l'organisation, ils auront besoin d'y accéder de manière différente, pour des besoins différents. Toutefois, l'information, elle, reste toujours la même : c'est sa présentation et son usage qui change, ce sont les différents services que l'on construit au-dessus de cette information qui doivent changer suivant les besoins.

Comme l'information ne change pas - seuls les usages qu'on en fait changent - on a intérêt à la modéliser correctement. Pour cela, en fonction des différents besoins identifiés, on va définir des types d'information et étudier leur structure de façon à pouvoir les encoder dans la syntaxe la plus appropriée, celle-ci étant indépendante des applications logicielles (au hasard, XML). Toutefois, cette information même structurée ne se suffit pas à elle-même : on a besoin de savoir comment la représenter, et pour cela on a besoin de savoir différentes choses : comment elle a été techniquement structurée, où elle est stockée, qui a le droit d'y accéder, quand et pourquoi, quel est son contenu, quelle est sa relation avec l'information voisine, etc. Tout ce contexte est indispensable à la compréhension et à la représentation de l'information et peut être englobé sous le terme de « description » ou « métadonnées » et on utilise un modèle approprié pour le structurer et l'encoder (au hasard, RDF). L'information, accompagnée de sa description, devient une ressource et il ne nous manque plus qu'un ingrédient pour pouvoir la manipuler dans le système : quelque chose qui va permettre de relier facilement l'information à sa description, des informations entre elles, des descriptions entre elles. Pour cela elles ont besoin de s'interpeller mutuellement, de se nommer, de s'adresser. Bref, il nous faut des identifiants, des URI.

Maintenant il faut bien que cette ressource serve à quelque chose. On va l'utiliser pour répondre aux besoins qu'on avait identifié au début. Ce qui nous importe ici, c'est le message qui circule entre l'utilisateur et les informations elles-mêmes. Ce message doit aussi être exprimé dans une syntaxe indépendante des applications (au hasard, XML) et être véhiculé par un protocole indépendant des applications (au hasard, HTTP). Des services ou plutôt des Web-services (qu'ils suivent le principe de SOAP ou de REST) vont ainsi être créés et, ainsi, alimentés des interfaces pour répondre aux besoins des utilisateurs

Autour de cette architecture, il est à présent possible de déployer des solutions et des interfaces. Mais, en maîtrisant le socle informationnel, vous possédez une indépendance par rapport à la solution implémentée, vous n'êtes pas contraint et si vous devez la modifier, vous garderez la maîtrise de vos données. Par ailleurs, dans ces conditions, un moteur de recherche ou un outil de text-mining s'intégreront beaucoup mieux à cet écosystème informationnel, ils profiteront de la structuration et de la description de l'information et ne seront plus des outils "verrues" et magiques, mais donneront tout leur potentiel.

Finalement, cette logique amène à se poser la question suivante : « dans un système d'information, où se situe la valeur de l'organisation, dans l'information qui le compose ou dans l'application qui manipule l'information ? »

PS : Merci à Manue qui m'a permis "d'accoucher" sans douleur de ce billet, en mettant par écrit une partie de ces quelques idées qui sont autant les miennes que les siennes.

Management de l'information RDF XML Système d'information Causeries Moteur de recherche Web services — 

Commentaires

Je pense que le succès de Google répond en partie à la dernière question... du moins pour le moment :-).
La réponse est dans le développement de vos idées. La valeur de l'organisation repose sur le programme qui présentera l'information car le service s'adapte aux besoins. Mais l'architecture documentaire, le noyau de toute bureaucratie; n'est pas assez appuyée sur votre billet. Sans vouloir refaire l'empirio criticisme de lenine, toute bureaucratie nécessite d'une ligne de conduite, d'un guide pour l'organisation de ses documents. Sinon c'est l'état dans l'état (ou l'anarchie).