Voir la source de CIDE (2007) Parfouru

{{Titre page article|titre=Analyse de la construction de documents de capitalisation de connaissances au travers de documents structurés : vers le développement d’un atelier sémiotique de composition de documents}}

{{CIDE boîte bibliographique|texte=
;Titre:[[A pour titre:: Analyse de la construction de documents de capitalisation de connaissances au travers de documents structurés : vers le développement d’un atelier sémiotique de composition de documents]]
;Auteurs:[[A pour premier auteur:: Samuel Parfouru]], [[A pour auteur:: Philippe Haïk]], [[A pour auteur:: Sylvain Mahé]] et [[A pour auteur:: Manuel Zacklad]].
:: samuel.parfouru@utt.fr
:: philippe.haik@edf.fr
:: sylvain.mahe@edf.fr
:: manuel.zacklad@utt.fr
;Affiliation:[[A pour affiliation auteur:: Laboratoire Tech-Cico|Laboratoire Tech-Cico]],[[A pour affiliation auteur::Institut Charles Delaunay|Institut Charles Delaunay ]] ,[[A pour affiliation auteur::ticri.fr:Université de Technologie de Troyes|Université de Technologie de Troyes]]  12 Rue Marie Curie 10010 TROYES, France.[[A pour affiliation auteur:: EDF Recherche & Développement| EDF Recherche & Développement]], 6 quai Watier 78400 CHATOU, France
;In: [[Est dans les actes::CIDE 10 Nancy |CIDE'10]] (Nancy 2007)
;En ligne: http://lodel.irevues.inist.fr/cide/index.php?id=161;Mots-clés: Document, Document Structuré, XML, Document pour l’Action, Coopération Médiatisée, Gestion des connaissances, Sémiotique, Architexte, Construction du Document
}}
__TOC__
;Résumé : 

Dans cet article, nous nous intéressons à la production de documents dans le cadre de projets de gestion de connaissances. Notre étude se concentre sur un type particulier de document que sont les documents de capitalisation. À travers la production de ces documents, les personnes en charge des démarches de gestion des connaissances, définissent des langages spécifiques de structuration de l’information. Faute de réelles solutions « tout en un » pour la construction de ces documents, ils sont le plus souvent créés au travers de logiciels communément déployés. Les documents produits mêlent fond et forme et ne permettent donc pas une indexation déterministe des informations qu'ils renferment. Nous décrivons ici une expérimentation d'instrumentation de l'activité de capitalisation de connaissances via la rédaction de documents structurés. Nous précisons notre retour d’expérience au regard de leur utilisation par un non informaticien. Cette étude nous a ainsi conduit à initier le développement d’un atelier sémiotique de composition de documents structurés.


{{boîte déroulante
   |titre=English description
   |contenu=
;Abstract :During knowledge management projects, lots of documents are produced. In this paper, we are considering the design of specific documents: capitalization documents. We can observe the use of the MS Office software suite for information structuring of theirs documents by knowledge engineers. Unfortunately, it is very difficult to re-use the content of these documents because they don't allow determinist indexation of information. Thus we describe a case study in which we used structured document in order to support a knowledge capitalization process. The structured document thus became a conception and we describe experience feedback of the case study. Finally, we introduce a semiotic workbench for document composition that we design at the moment.
}}

{{CIDE début corps}}
==Introduction==
Depuis maintenant une quinzaine d’année, entreprises et organisations ont largement pris conscience de l’enjeu crucial que représente la pérennisation des savoirs et savoirs faire qui représentent un capital immatériel de premier plan. On a alors assisté à l’émergence et au développement de la gestion des connaissances [{{CIDE lien citation|1}}][{{CIDE lien citation|2}}] qui a donné lieu à la conception de méthodes et d’outils [{{CIDE lien citation|3}}] et a débouché sur de multiples produits (livres de connaissances [{{CIDE lien citation|1}}], mémoire d’entreprise [{{CIDE lien citation|2}}], mémoire de projet [{{CIDE lien citation|4}}] ; ces « productions » se matérialisent sous différentes formes et l’on observe en particulier la production de nombreux documents.

Ce volume de documents produits au sein des entreprises et organisations ne cesse de croître. Le document constitue un moyen de coordination [{{CIDE lien citation|5}}] entre les acteurs et prend une importance énorme dans l’activité de l’entreprise. La production des documents se trouve d’ailleurs augmentée et accélérée de part les processus qualité et les démarches de normalisation intégrés aux entreprises ainsi que l’ensemble des systèmes de workflow et de gestion documentaire. Le numérique et le déploiement de l’informatique bureautique ont bien évidemment participé à cette évolution en facilitant la production de documents qui touchent aujourd’hui l’ensemble des membres de l’entreprise, sur l’ensemble de leur activité. Cette masse informationnelle qui est de plus en plus importante devient alors difficile à valoriser.

Dans ce papier, nous nous intéressons à l’activité documentaire introduite dans un contexte particulier : la gestion des connaissances dans un milieu industriel. Avant d’aborder notre analyse, nous évoquons quelques éléments en relation avec la notion de document, son passage au numérique et la définition de la notion de Document pour l’Action (DopA). Ainsi, nous introduisons le contexte lié à un projet de gestion des connaissances en décrivant les difficultés liées à ce type de projet. Nous poursuivons par une analyse de la pratique de construction de documents de capitalisation. Nous décrivons ensuite une expérience d’instrumentation de l’activité de structuration d’information sur la base de documents numériques structurés qui sont alors devenus un réel espace de structuration d’information par un analyste non informaticien. Nous nous attarderons particulièrement sur les outils exploités pour produire ces documents structurés en soulignant l’importance de rester en adéquation avec les infrastructures logicielles déployées. Nous terminons par décrire un atelier sémiotique que nous développons actuellement, permettant de composer la visualisation de documents structurés en adéquation avec les architextes auxquels nous sommes confrontés.
==De la numérisation du document au Document pour l’Action==

La numérisation a eu un impact important sur la notion de document [{{CIDE lien citation|7}}]. Ainsi, le document numérique peut être « défini comme une représentation numérique d'une preuve, qui doit pouvoir être réutilisée (reused) dans un autre processus de traitement » [{{CIDE lien citation|7}}]. Le caractère réutilisable des documents numériques, de leur contenu, est essentiel. Cependant, il ne peut être dissociée des logiciels auteur, des architextes informatiques [{{CIDE lien citation|8}}], qui ont permis de les créer. Un architexte peut être défini comme un « logiciel considéré dans sa capacité à mettre en forme et conditionner l’écriture. L’architexte (traitement de texte, navigateur, logiciel de présentation, etc.) procède à une écriture de l’écriture : il relève de la production de formes qui se situent en amont de l’acte d’écriture-lecture et en détermine les conditions de possibilité (du grec, origine et pouvoir) » [{{CIDE lien citation|8}}]. Ces architextes influencent largement la construction du document puisqu’ils possèdent des capacités en termes de définition de forme (la forme renvoie à la visualisation de l’information qui est produite) mais également des limites. Ainsi, ces architextes qui peuvent être des logiciels Wysiwyg (« What you see is what you get ») - concept associé au fait que la visualisation du document sur écran correspond à ce que l’on va obtenir lors de sa diffusion électronique ou papier - vont parfois être exploités comme des logiciels Wysywym (« What you see is what you mean »). Au travers des possibilités de l’architexte qui est exploité, les auteurs construisent leur propre langage de représentation de l’information qui va être plus ou moins explicités. Au travers de la définition de ces langages spécifiques, conçus par les auteurs, ce sont le contrat de lecture et d’écriture qui sont définis. Les auteurs possèdent alors une grande autonomie dans la construction des documents au regard du fond et de la forme.

Mais au travers du caractère réutilisable qui accompagne le document numérique, on s’éloigne sensiblement de la notion de « tout » que constitue le document. Le document n’est plus nécessairement un « objet unique inscrit dans le temps et l’espace » [{{CIDE lien citation|7}}] puisqu’il peut subir de nombreuse modification de sa création à sa diffusion aux lecteurs cibles : il peut alors perdre sa propriété de légitimité [{{CIDE lien citation|7}}]. Ainsi, « le numérique déconstruit un document en : une ressource enregistrée + une reconstruction calculée dynamiquement » [{{CIDE lien citation|9}}]. « La déconstruction conduit à une perte d'objectivité et à une dilution du document » [{{CIDE lien citation|9}}]. Cette dilution est particulièrement présente dans un contexte de calcul dynamique du document et donc à la définition des algorithmes de transformation des documents. Ces algorithmes constituent de réels processus de réécriture, pouvant impacter tout aussi bien sur la forme que sur le fond. De là, la notion de ressource enregistrée réutilisable et la facilité de recomposition des contenus – que cela soit sur la dimension signe ou forme ainsi que la facilité de produire le document pour différents supports pose le problème de voir le document comme un « lego » point de vue dont une analyse est proposée dans [{{CIDE lien citation|10}}]. Ces algorithmes qui transforment le document, prennent alors une importance et une responsabilité énormes dans la production et la diffusion de l’information mettant les personnes en charges de leur définition, et en particulier les informaticiens, au cœur de cette responsabilité. Dans cette situation où les documents sont calculés dynamiquement, les auteurs perdent alors une certaine autonomie au regard de la définition de la forme particulièrement et du fond, autonomie qu’ils avaient gagné à travers l’exploitation de logiciel « Wysiwyg ».

La réalisation d’un document correspond le plus souvent à une activité collective de rédaction mettant en jeu un réseau d’acteurs qui vont plus ou moins contribuer à sa définition que cela soit en termes de forme (travail éditorial) ou en terme de signe (travail auctorial) à travers l’intervention de nombreuses compétences et de nombreux métiers [{{CIDE lien citation|11}}]. Ainsi, un document, avant de constituer un « tout », va passer par un ensemble d’états (ou versions) et constituer un objet relativement instable prenant déjà un rôle important dans les activités et les organisations qu’il instrumente car il véhicule déjà une forme de représentation aux acteurs qui va avoir un impact sur ces derniers. A ce stade, nous définissons ces documents, comme des Documents pour l’Action.

Le document pour l’action (DopA) [5] permet de redéfinir le concept de document et d’appréhender autrement leurs contenus qui relèvent de moins en moins de la catégorie du texte classique. En insistant sur la dimension collective de l’activité rédactionnelle, il permet d’analyser les documents comme relevant de processus de communication pour partie différés, au sens des processus asynchrones décrits dans le champ du CSCW (Computer Supported Cooperative Work), entre des producteurs et des récepteurs liés par des intérêts communs. Alors que la conceptualisation en termes d’hypermédia [{{CIDE lien citation|12}}] visait surtout à rendre compte des nouvelles pratiques de lecture associées aux hypertextes, le DopA vise à rendre compte des processus « d’hyper-rédaction » associés aux documents numérisés. Le DopA se définit alors comme un  ensemble de fragments portés par des auteurs divers dont le contenu final reste largement indéterminé alors même que sa circulation rapide lui fait déjà jouer un rôle majeur d'information, d'aide à la décision et de preuve [{{CIDE lien citation|5}}].
==Activité de gestion des connaissances et production de documents==

L’activité de gestion des connaissances ne peut être analysée en dehors de sa dimension sociale et donc du réseau d’acteurs dans laquelle elle s’insère. Classiquement celui-ci sera composé d’analyste(s), expert(s), opérationnel(s), commanditaire(s) et informaticien(s). L’analyste (cogniticien) mène la démarche de gestion des connaissances – initiée par un commanditaire – et particulièrement l’activité de capitalisation. Elle correspond à identifier et structurer des informations relatives à un savoir ou savoir faire. Ces informations pourront être issues d’entretiens d’experts menés par l’analyste, ou encore de données de retour d’expérience. La démarche de gestion des connaissances doit permettre d’aboutir le plus souvent à la collecte et à la structuration d’informations permettant de constituer une ressource (document, base de données…).

Ce réseau d’acteurs, dans lequel s’insère l’activité de gestion des connaissances, conduit à plusieurs difficultés. En effet, dès que l’on cherche à appréhender un système ou un processus complexe, on est confronté à une problématique multi domaines. Chacun des domaines d’expertise considérés apporte alors des connaissances différentes, complémentaires, parfois clivagées ou contradictoires, portées par des vocabulaires et des points de vue différents sur l’objet ou encore l’ouvrage auquel on s’intéresse. L’objectif est alors de construire une représentation des informations reflétant un consensus, à l’intersection des domaines, et issue des interactions entre les acteurs, tout en conservant une représentation où chacun puisse reconnaître l’objet de son métier et se positionner par rapport aux autres. Cette multiplicité de points de vue se fait également ressentir sur la ressource ou le système que l’on cherche à développer. En effet, les différents acteurs vont avoir leur propre vision sur les finalités de l’activité de gestion des connaissances. Cela peut renvoyer à l’objectif ou l’usage relatif d’un système ou encore la façon dont il doit s’insérer dans les activités métier. Ces différentes visions sont bien évidemment changeantes et évolutives tout au long du projet, car influencées par les résultats présentés aux acteurs. Ces résultats peuvent tout aussi bien faire référence aux informations capitalisées, représentant le plus souvent un savoir tacite qui réinterroge chaque acteur sur sa propre pratique, ou aux moyens, technologiques ou non, exploités pour concevoir et développer un artefact, leur permettant de mieux appréhender ce qui est effectivement réalisable.

Ces démarches de capitalisation tendent alors vers des contextes de conception collective où l’échange entre les acteurs est fondamental pour aboutir à une solution « consensuelle ». Ces activités de conception se font au travers de l’échange des documents qui gravitent autour du projet : documents relatifs à la gestion du projet lui-même, à la capitalisation des informations ou encore à la conception de la ressource ou du système auquel on souhaite aboutir. L’ensemble de ces documents constituent autant de moyen de coordination  entre les acteurs qui participent au processus de négociation qui débouchera sur la conception d’une œuvre commune. Lorsque cette œuvre commune correspond à un document, qu’il soit numérique ou non, la notion de DopA prend toute son importance. Le document va évoluer au fil de la capitalisation passant par tout un ensemble de versions qui vont réinterroger chacun des acteurs sur leur savoir au regard des connaissances explicitées ou encore de leurs attentes. Ces documents que nous nommons document de capitalisation sont d’un registre particulier. Le contexte technique dans lequel nous nous insérons influence leur rédaction qui laisse apparaître une forte structuration. Ils doivent véhiculer au lecteur une représentation des connaissances, une modélisation, qui doit être correctement interprétée et donc être rédigée selon un langage, un système sémiotique, aussi monosémique que possible pour pérenniser une représentation des savoirs et savoirs faire. Nous proposons maintenant de nous intéresser à la définition et au mode de construction de ces documents de capitalisation.
==Pratique d’utilisation de l’informatique bureautique dans la construction de documents de capitalisation==

Nous proposons de nous intéresser ici à la production des documents de capitalisation. La production de ces documents s’appuie largement sur les environnements informatiques pré-installés par les directions informatiques. Il s’agit alors d’une vaste utilisation de l’informatique bureautique introduisant le triplet classique de la suite Microsoft Office : Word, Excel, Powerpoint. On constate, en fait, que rarement la présence de logiciels plus « exotiques » ou spécifiques<ref> En dehors des outils bureautiques, on retrouve d’autres logiciels communément déployés qui correspondent à des standards dans des domaines d’activité plus ou moins spécifiques (Matlab, outils de CAO, de PAO, …).</ref> ; en effet, ils introduiraient nécessairement des problèmes d’interopérabilité (formats d’échange) entre les personnels, ce qui aurait tendance à nuire à la coopération. Nous proposons maintenant de nous attarder sur l’utilisation du tableur Microsoft Excel pour la production de documents de capitalisation, dans notre contexte de gestion des connaissances en milieu industriel.

==Excel au cœur d’une pratique de structuration de l’information==

Le tableur Microsoft Excel est omniprésent dans les pratiques. Analystes, experts et informaticiens en font une utilisation massive et, même si chacun l’utilise à sa manière, il est possible de dégager quelques propriétés récurrentes dans son utilisation. Précisons tout d’abord que ce ne sont pas vraiment les fonctionnalités de tableur qui sont, le plus souvent, valorisées mais plutôt son espace de représentation ainsi que le mode de saisie qu’il introduit. L’espace de représentation se présente sous la forme d’un classeur composé d’autant de feuilles de calcul que l’on souhaite (espace infini de représentation). Chaque feuille de calcul représente un espace matriciel de saisie constitué de cellules. Les cellules peuvent être colorées, redimensionnées et fusionnées. L’observation de plusieurs documents produits sous Excel, nous permet de dégager un mode d’écriture reflétant une structuration hiérarchique des informations. Il s’agit d’un phénomène tout à fait récurrent qui, en fait, se traduit en terme de représentation par une fusion de cellule. Ainsi, une feuille de calcul telle que présentée sur la figure 1, dont le contenu est majoritairement textuel, reflète une structuration hiérarchique de l’information. Sur cette figure, on a introduit une racine virtuelle qui est reliée aux différentes feuilles de calcul qui composent le classeur : c’est le premier niveau de hiérarchie. Le deuxième niveau de hiérarchie est introduit par les différentes lignes. Le suivant est introduit lorsque les lignes se divisent et ainsi de suite.

[[Fichier:CIDE 10 Parfouru.jpg|600px|thumb|center|'''Figure 1'''. ''Fichier Excel exploité comme espace de structuration d’information'']]

A travers ce mode de saisie, on identifie bien que l’usage qui est fait ici du tableur Excel est très différent de ce pourquoi il a été conçu. Ceci est tout à fait caractéristique du passage de l’outil à l’instrument défini par Rabardel [{{CIDE lien citation|13}}] lorsqu’un outil est intégré dans une activité et particulièrement une pratique utilisateur. En effet, un outil, un artefact, quelqu’il soit pourra avoir une utilisation très différente de ce pourquoi il a été conçu et ce, en fonction de l’improvisation et de l’inventivité des utilisateurs. Dans la situation présente, le tableur Excel devient un moyen de modéliser et de structurer l’information au travers d’une représentation matricielle et un mode de saisie tabulaire. La brique de base, l’entité élémentaire, de ce mode de structuration est alors la cellule.

Chacun des utilisateurs d’Excel qui prend un statut d’auteur va alors à partir de cette brique élémentaire que constitue la cellule, ainsi que les capacités d’édition de l’architexte, dans le cas présent Excel, construire son propre langage de visualisation de l’information. La feuille de calcul du tableur constitue alors l’espace de modélisation pour l’analyste, à l’image du diagramme par exemple en conception logicielle [{{CIDE lien citation|14}}]. Chaque analyste exploite alors la feuille de calcul qui propose un plan à 2 dimensions et des variables visuelles (couleur, taille…) au niveau des cellules pour produire une image au sens de Bertin [{{CIDE lien citation|15}}]. Cette image tendra à mettre en relation la sémantique des informations avec les variables visuelles disponibles dans l’espace d’édition, l’architexte utilisé.

==Du « WYSIWYG » au « WYSIWYM » : au-delà de la capitalisation du fond, capitaliser la forme==

La pratique d’utilisation d’Excel que nous venons de présenter est bien entendu influencée par notre contexte d’étude. L’information capitalisée par les analystes est très structurée du fait du milieu technique dans lequel nous évoluons. En plus du caractère assez technique des informations, les documents produits sont d’un type particulier. L’analyste produit des documents par exemple de capitalisation qui doivent expliciter savoir et savoir faire et ce de la manière la plus claire possible. Le niveau de discours exploité dans ces documents est alors assez « simple » - on exploite peu les subtilités du langage naturel contrairement au récit par exemple -  bien qu’intégrant un vocabulaire propre aux différents métiers. Par contre, les dispositifs représentationnels offerts par l’architexte utilisé sont exploités de manière à bien véhiculer la sémantique de la modélisation produite par l’analyste. C’est le cas dans Excel où l’espace matriciel de saisie est exploité pour faire transiter une information hiérarchique.

Bien évidemment chaque auteur introduit une part d’improvisation dans l’utilisation des architextes exploités pour construire les documents. Cependant, l’exemple d’utilisation d’Excel comme outil de structuration hiérarchique de l’information est réellement un phénomène qui dépasse le cadre isolé d’une entreprise donnée. Au-delà de cet exemple, les architextes, majoritairement Wysiwyg ( What you see is what you get), offrent un espace d’édition infini et libre de représentation : l’exemple des feuilles de calcul Excel est caractéristique. Il est possible de combiner modalités textuelle et graphique (diagrammes, schémas, images…) dans le document. Enfin, ces architextes offrent de larges possibilités de « copier – coller » que cela soit dans un document, ou au besoin entre différents documents produits par les différents logiciels.

Ainsi, l’analyste, ou plus généralement l’auteur d’un document, face à un architexte va définir son propre langage de représentation de l’information et ce, en fonction des possibilités de cet architexte. En intégrant l’architexte dans son activité, il le fait passer du statut d’outil à celui d’instrument [{{CIDE lien citation|13}}] : il transforme l’architexte choisi en instrument de modélisation de connaissances. L’utilisation d’un architexte aussi commun que Word ou Excel par exemple, permet à l’auteur, l’analyste, de conserver une autonomie dans la création du document (création du document qui correspond à la modélisation dans notre contexte de gestion des connaissances) en y définissant son propre système sémiotique ; il met en relation la sémantique des informations qu’il souhaite représenter avec les variables visuelles mais également interactives disponibles. C’est à partir de ce travail que se définit le contrat de lecture et d’écriture dans le document.

L’auteur modélise à travers la création de différentes instances de document. Au fil des versions, le système sémiotique, le langage de représentation des informations va se stabiliser, permettant de dégager un modèle de document qui constitue dans cette activité de gestion des connaissances quasiment un modèle de connaissances. C’est bien le travail de construction des différentes instances, mêlant fond et forme, qui permet de définir à la fois la structure logique du document mais également la sémantique qui va transiter par la visualisation produite. Notons bien qu’en pratique, il est très difficile de définir un modèle de connaissances à priori. L’activité de capitalisation est une activité peu déterministe. Il est difficile de réellement déterminer les informations qui seront identifiées de même que leur structuration ou encore l’utilisation qui en sera faite. De là le modèle se construit le plus souvent au fil de l’activité de capitalisation. Cette situation est d’ailleurs renforcée par le fait que l’explicitation de certaines informations va réinterroger chaque expert sur son propre savoir. Ce travail n’est pas uniquement le fruit de l’analyste puisque l’ensemble des versions produites sont autant de documents pour l’action qui vont être présentés aux différents acteurs impliqués dans le projet et donc avoir un impact sur eux tout en subissant les évolutions relatives aux retours de ces différents acteurs.

En définitive, l’analyste qui conduit la construction du document va exploiter un architexte qui bien souvent correspond à un logiciel Wysiwyg puisqu’il construit une visualisation de l’information telle qu’elle sera reproduite sur l’écran ou à l’impression. Ceci étant, notre analyse nous amène au constat que l’analyste dans son activité exploite le logiciel en Wysiwym (« What you see is what you mean ») puisqu’il définit des langages. Ces langages sont alors construits à partir des capacités de l’architexte en termes de visualisation (mise en forme) mais également d’interaction (liens hypertexte, affichage dynamique…). Ce mode d’utilisation des architextes par les analystes pose alors le problème d’une dilution possible de la sémantique du document si le langage défini n’est pas identifiable « naturellement » ou explicité. En effet, les auteurs n’explicitent pas nécessairement ce que représente sémantiquement la mise en forme exploitée. On ne capte pas au niveau de la saisie l’intention de l’auteur [{{CIDE lien citation|16}}], ce qui représenterait pourtant une information essentielle par exemple dans la rédaction coopérative [{{CIDE lien citation|17}}] mais également dans la pérennisation des informations capitalisées (conservation du contrat de lecture et d’écriture). De plus, étant donné le volume de document produit aujourd’hui, il est important que ces derniers puissent être analysés par la machine et notamment dans l’activité de gestion des connaissances afin que l’ordinateur soit capable d’identifier les briques élémentaires qui constituent une modélisation produite sous la forme d’un document. Le langage défini par l’analyste n’étant pas nécessairement sous une forme appréhendable par la machine, ceci peut être rendu difficile. Ainsi, au travers de l’exploitation de ce logiciel Wysiwyg, même s’ils sont exploités en Wysiwym, on a une dilution de la sémantique du document, au regard d’une exploitation par la machine due à un manque d’indexation (au sens identifiable par la machine) des systèmes sémiotiques mis en œuvre. Il est bien évidemment possible de mettre en œuvre une indexation full texte, ou encore des analyses de text-mining pour dégager une indexation « pertinente », mais ces indexations automatiques ne seront jamais aussi précises qu’une indexation manuelle. Nous ne remettons néanmoins pas en cause ces approches, mais avec l’accélération produite par le numérique, il nous semble important de mettre à disposition des utilisateurs des outils permettant de construire cette indexation à la création des documents, plutôt que d’analyser a posteriori leurs structurations. Lorsque nous parlons d’indexation ici, il s’agit d’être capable de conserver une image des systèmes sémiotiques mis en place par les auteurs ainsi que l’ensemble des acteurs qui contribuent à la construction du document que cela soit au niveau de la forme ou du fond. Ces systèmes sémiotiques doivent être vus au niveau des contenus textuels, des balises ainsi que de la mise en forme ; chacun de ces niveaux introduit une part de sémantique dans le « tout » que constitue le document et doit donc faire l’objet d’une conservation, d’une capitalisation.

Dans cette orientation, et dans le cadre d’une démarche de gestion des connaissances, nous avons démarré une expérience d’instrumentation du travail de capitalisation via des documents structurés. Nous avons ainsi initié un analyste, non informaticien, à la rédaction de documents structurés sur la base du standard XML. L’expérience a consisté à substituer Excel tout d’abord par un éditeur de code source XML dans le cadre d’un travail de capitalisation des connaissances. Le document structuré constitue alors l’espace de modélisation qui a fait l’objet, nous le verrons, de différentes formes de visualisation. Avant d’aborder le retour d’expérience relatif à cette étude, la section suivante précise la notion de document structuré, son lien avec XML et les intérêts que nous voyons au travers de ce standard.
==Document structuré, technologie XML et activité de gestion des connaissances==

Le document structuré ne peut être réduit à la simple évocation de l’utilisation des technologies XML. Nous reprenons les éléments de définition proposés par [{{CIDE lien citation|18}}] : « les entités élémentaires sont des éléments structuraux (ou logiques) dont la signification est paramétrable. Les règles d’organisation logique sont explicites et modifiables séparément des instances documentaires (schémas documentaires). La validité structurelle d’un document par rapport à un schéma peut être vérifié via des algorithmes génériques ».

Le document structuré peut ainsi être appréhendé comme une structure dont les entités élémentaires, définies par la présence d’éléments structuraux, vont stocker des contenus textuels. Cette structure est classiquement hiérarchique et est soumise à une règle d’organisation qui introduit une réelle syntaxe dans l’organisation logique du document. Ainsi, les différents éléments structuraux qui définissent les entités élémentaires d’un document associées à leurs règles d’organisation constituent un réel langage. En fonction de la technologie utilisée, les mots du langage de structuration sont plus ou moins imposés. Ainsi, HTML (Hypertext Markup Language) définit un langage de structuration de l’information dont les balises sont prédéterminées et répondent à une mise en forme standard. A contrario, XML (eXtended Markup Language), qui ne constitue pas en soi un langage « mais plus exactement un ensemble de règles permettant la création de langage de balisage » [{{CIDE lien citation|19}}], permet de construire son propre langage de structuration. Ainsi, en s’appuyant sur XML, il est possible d’offrir un espace de structuration de l’information relativement libre dont la seule contrainte est de produire des documents bien formés, c’est-à-dire en se conformant aux règles du XML. De plus, nous avons mis l’accent sur l’importance des règles d’organisation logiques des entités élémentaires et le fait qu’elles doivent pouvoir être validées de manière algorithmique. Cela introduit la notion de document valide. Un fichier XML constituera un document valide si son organisation structurelle répond à un modèle de document. Ces modèles de document sont typiquement implémentés sous la forme d’une DTD (Document Type Definition) ou d’un Xschema (XML schema). Ils représentent des sources d’informations essentielles puisqu’ils définissent un contrat de lecture, d’écriture et de validation sur les documents produits.

L’utilisation de XML dans le domaine de la gestion des connaissances n’est pas à démontrer puisqu’elle a déjà été largement dissertée dans les domaines de la structuration d’informations ou de la restitution de l’information ; en effet, la séparation fond/forme qu’elle introduit permet de produire, à partir d’une même structure, différents modes de restitution . Nous avons d’ailleurs largement exploité les technologies XML et le document structuré dans des projets relatifs à la gestion des connaissances [{{CIDE lien citation|20}}, {{CIDE lien citation|21}}]. L’introduction d’XML dans notre dispositif de capitalisation doit permettre, au moins pour partie, de pallier les inconvénients de l’informatique bureautique telle que présentée précédemment. En effet, nous avons souligné l’importance de l’indexation des informations (au niveau du fond et de la forme). Plus cette indexation sera fine, plus on pourra imaginer des traitements complexes par la machine. La production de documents au travers des outils de bureautique clairement centrés sur le concept de Wysiwyg produit une information qui n’est pas dénuée de structuration mais celle-ci repose sur un système sémiotique qui n’est pas nécessairement identifiable par la machine. Il y a alors autant de formes de documents que d’utilisateurs, celui-ci profitant d’une autonomie importante au regard de la définition de la forme. La saisie des informations directement dans un langage structuré permettrait de grandement améliorer la situation puisque la gestion de documents déjà structurés, même en masse, est grandement facilitée. Ces documents constitueraient ainsi des ressources plus facilement exploitables et valorisables.

L’activité de capitalisation qui correspond à une tâche d’identification et de structuration d’information, constitue une tâche peu déterministe. Il est alors difficile d’anticiper sur la définition du modèle de structuration en la décorrélant de l’activité de capitalisation elle-même. Notre orientation, dans cette expérience, est alors d’exploiter le langage structuré XML pour instrumenter l’activité de modélisation. Au travers de l’écriture de document bien formé, il s’agit de fournir un espace de modélisation qui permette de faire évoluer le modèle de structuration et le contenu informationnel de concert. L’activité de modélisation correspond alors à l’écriture d’un document bien formé : le modèle de structuration d’information correspondant alors au modèle de document en cours d’écriture. Cette démarche doit permettre d’éviter à avoir à anticiper sur le langage de structuration de l’information et doit également permettre de construire celui-ci au fur et à mesure de la capitalisation : le modèle se dégage au travers de la construction d’une instance de document structuré. Notre tentative est de s’écarter d’une approche qui définirait le modèle à priori (devenant plutôt une contrainte dans le processus de capitalisation) qui conduit, en général, à des interfaces de modélisation trop cadrées qui tendent à une utilisation « taylorisée ». On pense notamment aux systèmes informatiques dont l’accès est basé sur la mise en œuvre de formulaires. Le formulaire constitue sans doute, actuellement, le moyen le plus efficace « pour encadrer les auteurs » et les pousser à se conformer à un langage formel [{{CIDE lien citation|22}}]. Il est particulièrement pertinent pour gérer la cohérence des informations, mais constitue également une contrainte dans le processus d’écriture.

Au travers du document structuré, nous souhaitons modifier ce mode de saisie qui ne nous parait pas très propice à l’activité créative que constitue la modélisation, introduisant une difficulté dans la définition a priori (i.e. l’anticipation) du modèle. Ainsi, le document structuré peut offrir un espace de saisie tout à fait cadré par un modèle de document mais dans lequel il sera possible d’écrire les informations selon sa convenance en terme d’ordre par exemple, voir même de laisser de manière temporaire des informations incomplètes. Dans la partie suivante, nous proposons une description de la démarche d’instrumentation d’un processus de capitalisation des connaissances au travers de documents structurés. Cette partie synthétise notre retour d’expérience en tentant de dégager avantages et difficultés du document structuré dans l’activité de capitalisation.
==Le document structuré comme espace de conception==

L’expérience que nous avons mise en place a consisté à mettre un analyste non informaticien, en l’occurrence un sociologue, dans un premier temps face à un éditeur de code source XML. Le choix de l’éditeur s’est porté vers Oxygen (http://www.oxygenxml.com/). Il offre un espace tout à fait classique d’édition, c’est-à-dire un espace infini d’écriture avec des fonctions de « copier-coller » relativement importantes. Certaines fonctions sont plus liées au langage balisé puisqu’elles implémentent des mécanismes de complétion du balisage qui accompagnent l’activité de saisie (ex : support contextuel de fermeture de balises). Il offre également une vérification permanente du caractère bien formé et valide (si un modèle de document est spécifié) du document en cours d’édition.
==Document structuré et formalisation par un non informaticien==

La prise en main de l’éditeur et l’apprentissage des bases du langage XML, par l’analyste, se sont faits assez rapidement. La possibilité de définir son propre langage de structuration a représenté une réelle souplesse dans le processus de structuration (indexation des informations capitalisées). L’analyste a ainsi largement apprécié cette manière de structurer ses contenus évoquant même que l’écriture au travers de l’éditeur de code source XML n’était pas très différente de l’écriture dans un traitement de texte. La formalisation des connaissances se fait alors en extension, c’est-à-dire de manière constructiviste en créant les balises nécessaires au gré des besoins. La visualisation pour l’auteur, l’analyste, correspond alors à un code source colorisé et dont l’indentation traduit l’arborescence. Structure et contenu évoluent ainsi de concert. Le document structuré prend alors une dimension d’espace de conception jusqu’à ce qu’il se stabilise. Cette stabilisation du document permet alors d’identifier le modèle de document – ceci se limite à exploiter les fonctionnalités de l’éditeur qui permettent de calculer la DTD ou le Xschema du document courant - correspondant à sa structure canonique. Ce modèle de document répertorie alors l’ensemble des éléments structuraux, les balises, qui correspondent au langage de représentation et de structuration de l’information.

Cette démarche et cette instrumentation de la capitalisation ne sont toutefois pas sans poser de problèmes. Il est bien évident qu’une formalisation déclarative en extension risque d’introduire des problèmes de cohérence et de « duplication » du contenu (on ne répond plus à la propriété d’unicité des données chère aux informaticiens notamment au regard de la gestion de la cohérence). C’est en effet un phénomène que nous observons dans nos expérimentations. Ceci ne constitue toutefois pas, de notre point de vue, un écueil. En effet, nous pensons que ce travail préliminaire de l’analyste - qui débouche sur un tel contenu - est essentiel, car il est toujours difficile d’avoir, a priori, une vue d’ensemble sur les éventuelles redondances que l’on aura à traiter. Dans la rédaction d’un tel document, l’analyste introduit un point de vue relatif à l’organisation de l’information qui l’aide dans son activité et sa réflexion : il crée son propre langage de structuration. Par contre, l’intégralité du contenu étant sous une forme très structurée ces problèmes pourront êtres traités, de manière plus ou moins complexe, à minima de manière semi-supervisée, a posteriori en collaboration avec l’informaticien.

Le fait de travailler sans définir de modèle de document (DTD, Xschema) a priori offre une grande autonomie à l’analyste dans la création de son langage de structuration. Le modèle de document qui constitue alors notre modèle de connaissances résulte alors de la création d’une instance de document structuré. Ce positionnement est en fait lié au fait que nous exploitons le document structuré comme un réel espace de conception. Le document produit n’a pas vocation à être directement une version cohérente et optimale. Il est un réel instrument de capitalisation et de structuration de l’information. Il constitue ainsi un réel Document pour l’Action passant d’une version à une autre. Ce statut de DopA que prend ainsi le document est également lié au fait qu’il constitue un réel objet de coopération alliant une souplesse de structuration pour répondre aux besoins de l’analyste et une indexation formelle (au sens informatique) des entités élémentaires assez importantes pour être retravaillées et exploitées par l’informaticien.
==Edition de documents structurés==

Au-delà des problématiques liées à la structuration de l’information, notamment au vu de la gestion de cohérence, la saisie déclarative dans un langage structuré ne se fait pas sans difficulté. En effet, l’écriture structurée en extension tend à produire des documents qui peuvent représenter un volume important difficilement appréhendable lorsqu’il est affiché sur un écran. De même, la profusion des balises peut en rendre la lecture difficile. Bien que nous ayons évoqué le fait que l’analyste ait pu exploiter l’éditeur de code source, il n’en reste pas moins que la visualisation des contenus sous forme balisée a introduit des phénomènes de désorientation. Le système de représentation (code balisé) qui était appréhendable par le non informaticien quand le contenu était réduit et devenu problématique quand celui-ci s’est étendu. La visualisation en code source indenté ne constituait alors plus une métaphore efficace au sens où le système sémiotique ne permet plus d’appréhender toutes les composantes de l’information en cours de représentation. De ce fait, nous avons été conduit à modifier l’infrastructure logicielle de formalisation.
==Editeur Wysiwyg XML : donner une forme aux balises==

Nous avons alors introduit dans le dispositif logiciel un éditeur XML que l’on peut qualifier de « Wysiwym ». Il s’agit de l’éditeur Morphon (Cet éditeur n’est aujourd’hui plus disponible du fait de l’arrêt de son maintien, aussi nous nous tournerons vers Amaya [{{CIDE lien citation|23}}] dans la poursuite de cette étude). Cet éditeur permet en effet de traduire les éléments structuraux composant le document (les balises) en une mise en forme particulière. Ce mécanisme est basé sur la définition d’une CSS (Cascading Style Sheets) paramétrable via une interface ne nécessitant pas une connaissance de ce langage.

Cette liberté, dans la définition de la forme de représentation de l’information, a permis à l’analyste, sans connaissance particulière au regard de la technologie CSS, de produire la visualisation qu’il souhaitait. Par exemple, il lui était possible d’adapter cette forme à son activité et de mettre en valeur les parties du document sur lesquelles il souhaitait se concentrer durant une révision du contenu. Bien évidemment, cette nécessité de mettre en place un éditeur « Wysiwym » illustre bien les limites d’une approche où des utilisateurs non informaticiens devraient éditer directement en code source leurs documents. Ceci met l’accent sur la problématique de la forme et le manque évident d’outils efficaces et adaptés à la conception et la construction de documents structurés. L’éditeur Morphon s’est révélé particulièrement adapté à traiter le contenu des briques élémentaires, mais pas nécessairement adapté à des modifications de structures importantes. Initialement, la structure a bien été construite au travers de la saisie déclarative dans l’éditeur de code source Oxygen permettant la création d’éléments structuraux et de contenu de concert. Toutefois, nous avons évoqué la difficulté d’utiliser cet éditeur dès lors que le contenu prend de l’ampleur. Nous avons alors étendu notre dispositif de formalisation en introduisant la modalité graphique comme mode de saisie.
==Saisie structurelle de l’information : éditeur de carte conceptuelle pour une écriture graphique==

Au travers de la modalité graphique, il s’agit bien entendu d’offrir une représentation de l’information permettant une meilleure appréciation de l’organisation structurelle et topologique de l’information, et permettant d’obtenir une vision globale du document. Le document structuré correspondant à une information organisée hiérarchiquement, c’est bien évidemment l’arbre qui s’impose. Nous nous sommes alors appuyé sur l’éditeur de carte conceptuelle Freemind (http://freemind.sourceforge.net). Cet éditeur offre un espace de représentation de l’information sous la forme d’une carte conceptuelle : il s’agit d’informations liées hiérarchiquement selon un nœud racine. Cet éditeur met à disposition de nombreux dispositifs qui permettent de modifier la mise en forme matérielle de l’arbre (coloriage, représentation iconique des nœuds ou des liens par exemple). Dans notre exploitation de Freemind, nous avons défini un algorithme standard (sous la forme d’une feuille de transformation XSL) permettant de transformer un document structuré sous la forme d’une carte conceptuelle. Cet algorithme permet également de faire la transformation inverse. Nous produisons ainsi une carte conceptuelle selon un format tout à fait standardisé qui permet de travailler aisément sur la structure du document au travers d’une représentation graphique plus adaptée à la saisie structurelle de l’information.

[[Fichier:CIDE 10 Parfouru1.png|600px|thumb|center|'''Figure 2'''. '' Carte conceptuelle Freemind calculée sur la base d’un fichier XML'']]


A travers l’exemple de l’utilisation de Freemind, on voit toute la souplesse offerte par le passage dans un codage XML des informations. Il est alors possible de transformer les documents structurés afin de les adapter par exemple à divers architextes pour peu que leur format de fichier soit ouvert. Cette souplesse se fait tout de même au détriment d’un acteur. L’analyste qui n’est pas nécessairement un informaticien subit une perte d’autonomie pour ce qui est de la production de la forme du document. Il est alors dans l’obligation de faire appel à un informaticien maîtrisant des technologies XML par exemple pour produire une forme de visualisation de l’information adaptée à son activité ou à l’activité des futurs utilisateurs (lecteurs) du document.

==Vers le développement d’un atelier sémiotique de composition de documents valorisables par des architextes déployés==

L’expérience présentée permet assez bien d’identifier l’intérêt de l’exploitation de documents structurés dans l’activité de capitalisation des connaissances. Se pose tout de même le problème de la forme de ces documents structurés. Leur visualisation sous la forme de code balisé reste plutôt réservée à un public d’informaticien. Nous avons donc complété l’éditeur de code source par différentes solutions qui montrent le besoin d’avoir à sa disposition une multiplicité de formes de visualisation adaptées à différents contextes. On constate surtout qu’il n’existe pas de réelle solution « tout en un » efficace pour la conception et la construction de documents structurés ce qui oblige à se tourner vers une multiplicité d’outils. Il est d’ailleurs peu probable qu’il soit réellement possible de développer un tel outil, ce qui peut expliquer le recours à cette multiplicité d’outils ainsi qu’au développement de stratégies d’utilisation inédites par des utilisateurs inventifs. Cette situation amène à une perte d’autonomie des auteurs face à la définition de la forme du document contrairement à la situation où ils exploitaient des logiciels Wysiwyg.

Nous avions déjà mis l’accent sur l’importance de produire une forme adaptée dans la collaboration entre les acteurs dans [{{CIDE lien citation|24}}]. Dans , nous avions introduit une première infrastructure permettant de produire différentes formes, mais également de produire des contenus dans un format compatible avec par exemple des logiciels bureautiques communément déployés. Nous ne voyons pas la conservation de ces outils bureautiques, souvent propriétaires, comme une limite ; il faut néanmoins que les dispositifs représentationnels qu’ils offrent soient utilisés de telle sorte qu’ils permettent d’identifier les briques élémentaires de la structuration de l’information et que celles-ci soient également identifiables par la machine. Nous évoquerons ici toute l’importance et l’enjeu des démarches actuelles de standardisation par exemple des formats OpenDocument porté par la communauté libre et OpenXML promu par Microsoft. Cette logique d’ouverture facilitera nécessairement l’interfaçage avec ces logiciels. Aussi, en prolongement des infrastructures et maquettes introduites dans , nous avons initié le développement d’un atelier sémiotique de composition de documents exploitables par différents architextes. Ainsi, plutôt que de tenter de développer un système de visualisation et de manipulation de documents « tout en un », nous préférons nous appuyer sur tout un ensemble d’outils existants et déjà déployés qui constituent un ensemble d’architextes. Ces architextes n’ont pas été nécessairement conçus et ne sont pas toujours adaptés à notre activité de gestion des connaissances. Ils sont par contre parfaitement adaptés à l’utilisation des moyens de visualisation et d’interaction qu’ils proposent pour la construction du document et c’est sur cela que nous souhaitons nous appuyer.

Notre atelier sémiotique a alors comme fonction d’une part de permettre de produire une visualisation d’un document structuré selon un système sémiotique bien défini (déterministe et monosémique) en accord avec les possibilités de différents architextes. Les mécanismes de transformation mis en œuvre doivent être réversibles afin de pouvoir transformer un document pour qu’il puisse passer d’un architexte à un autre ; chaque architexte se transforme en réel espace de construction et d’enrichissement du document, adapté à différentes activités et différents publics, mais également en interface de diffusion et de lecture pour les utilisateurs, lecteurs, de ces documents. La figure 3 illustre le processus dans lequel s’insère notre atelier sémiotique dans les conditions où l’on part d’un document structuré produit par un analyste. Il s’agit d’extraire à partir de ce document structuré le modèle de document (DTD, Xschema) correspondant qui va recenser l’ensemble des informations identifiables (les briques élémentaires) directement par la machine. A partir de cette liste d’information, il s’agit de définir au sein de l’atelier sémiotique un système sémiotique pour chaque architexte cible du document structuré. Ce système sémiotique, langage de représentation peut ensuite être appliqué sur une instance de document, au travers de feuilles de transformation XSL, pour produire une visualisation du document adapté à une interface, un architexte, cible.

[[Fichier:CIDE 10 Parfouru2.jpg|600px|thumb|center|'''Figure 3'''. ''Description du processus dans lequel s’insère l’atelier sémiotique de composition de documents'']]

Le scénario illustré sur la figure 3 part d’un document structuré en XML. La mise en forme qui en est faite correspond à une transformation de ce document. Nous développons ces transformations avec le souci de conserver l’ensemble des informations impliquant qu’elles sont inversibles. Il est donc envisageable que l’analyste travaille initialement dans n’importe quel architexte pour peu que son format soit ouvert. Pour dissocier les briques élémentaires constituant sa modélisation, il s’agira alors de capitaliser la sémantique relative à la mise en forme exploitée qui permettra de produire un document structuré  en XML par exemple.

[[Fichier:CIDE 10 Parfouru3.jpg|600px|thumb|center|'''Figure 4'''. ''De la capitalisation des moyens de visualisation et d’interaction des architextes à la définition de systèmes sémiotiques'']]


La définition du système sémiotique renvoie à une analyse des architextes et des interfaces de lecture cibles que l’on souhaite exploiter. Pour le moment nous nous focalisons sur la production de documents HTML (Navigateur Internet) et PDF, la production de cartes conceptuelles (Freemind), la génération de graphe en s’appuyant sur GraphViz (http://www.graphviz.org/) ainsi que les suites bureautiques en premier lieu Open Office qui nous offre un pont vers Microsoft Office. Ainsi, pour chaque architexte ou interface, il est possible de recenser d’une part des moyens de visualisation et des moyens d’interaction. Ces moyens peuvent être combinés pour aboutir à des dispositifs disponibles au travers de la définition de bibliothèque de patrons XSL paramétrables. La définition du système sémiotique tel que présenté sur la figure 4 va consister à associer chaque information à représenter à un dispositif (ex : un nœud dans un graphe) ou à la « personnalisation » de ce dispositif (ex : la couleur, la forme d’un nœud dans un graphe). Pour définir ces associations nous nous appuyons et nous inspirons largement de la Sémiologie graphique de Bertin [{{CIDE lien citation|15}}]. En particulier, notre démarche nous conduit à abstraire les informations à représenter pour les rapprocher des niveaux de perception proposés par Bertin. Nous ne détaillons pas ce point ici. Ces associations qui constituent alors le langage, sont alors traduites dans un document structuré qui va capitaliser ce langage. Ainsi, dans la dynamique de transformation des documents, les feuilles XSL ne contiennent pas d’éléments du langage défini par l’auteur, ce qui pallie pour partie la dilution du document évoquée par Bachimont , dans les algorithmes de transformation. Le document qui trace ce langage peut alors faire l’objet d’une visualisation par exemple pour l’expliciter et produire une légende définissant le contrat de lecture et d’écriture dans le document.

L’implémentation de cet atelier sémiotique s’appuie sur la plateforme de développement Web Cocoon (http://cocoon.apache.org/) qui offre un environnement souple de génération, manipulation et diffusion sous différents formats de documents structurés en XML. Une description plus détaillée de l’architecture déployée ainsi que des outils associés fera l’objet d’un article dédié. Si pour le moment il est prématuré de réellement penser fournir cet atelier directement à des non informaticiens, il est tout de même développé en ce sens. L’objectif à terme est de fournir à nos analystes un environnement leur permettant de composer une visualisation de leur document, avec une indexation de leur sémantique, sur le plan de la forme ainsi que du signe, sans connaissance avancée sur les technologies exploitées.

==Discussion==

Dans ce papier, nous nous sommes intéressés à la forte activité documentaire qui accompagne l’activité de gestion des connaissances. L’analyse de documents réels issus d’une démarche de gestion des connaissances a permis de mettre en évidence l’importance qu’ils prennent dans les processus de formalisation et de structuration de l’information. Ainsi, le tableur Excel représente un cas typique de logiciel dont l’usage a été détourné par les utilisateurs pour le transformer en instrument, au sens de Rabardel [{{CIDE lien citation|13}}], adapté à leur activité : il devient espace de modélisation. Plus globalement, on observe qu’une panoplie d’outils est exploitée pour saisir et structurer de l’information. Nombres de logiciels Wysiwyg (« What you see is what you get ») sont exploités par les auteurs en Wywiwym (« What you see is what you mean »), les analystes en gestion des connaissances procédant à la définition de systèmes sémiotiques, de langages de représentation, sur les bases des moyens de visualisation et d’interaction disponibles dans l’architexte exploité.

Ce caractère Wysiwyg permet une structuration de l’information, mais au travers de la mise en forme matérielle. Fond et forme se confondent ainsi introduisant une dilution de la structure qui, lorsqu’elle subsiste, n’est identifiable que par un humain au prix d’une attention particulière (ou reste sinon tacite). Ces Documents pour l’Action contiennent pourtant, nous l’avons mentionné, de nombreuses informations et leur valorisation représente un fort enjeu. Dans un contexte de valorisation de ces informations, une identification, par la machine, de ces briques élémentaires et de leur organisation et leur indexation permettraient de mieux les valoriser au travers de traitements plus ou moins automatiques. Pour répondre à cela, on peut songer à définir la correspondance entre les dispositifs de mise en forme utilisés et les entités élémentaires qu’elles définissent (définition sémantique de la forme).

Notre positionnement est donc de travailler en amont de la construction des documents et pas sur une analyse a posteriori de ce dernier. Plutôt que de subir un corpus documentaire de plus en plus grand, il s’agit d’offrir les moyens à nos utilisateurs, nos auteurs, de créer l’indexation dès la création de ces documents. Notre expérience de formalisation au travers de documents structurés va en ce sens. L’objectif était bien de mettre l’analyste dans une position d’indexation fine de l’information. Ceci est passé par une sensibilisation de l’analyste aux techniques en relation avec la production des documents structurés afin de lui montrer les possibilités offertes à l’issue de la rédaction de tels documents. L’expérience aura permis de montrer l’intérêt d’exploiter le document structuré dans la démarche même de capitalisation des connaissances. Il constitue un instrument souple de structuration de l’information permettant de faire évoluer, de concert, structure et contenu et sous un mode déclaratif et de faire émerger un modèle, un langage, de structuration de l’information. Il n’est alors plus nécessaire d’anticiper sur le langage de structuration de l’information. Ceci est rendu possible par une démarche ne définissant pas de modèle de document (DTD , Xschema) a priori, ce modèle étant calculé a posteriori.

Le document structuré est ainsi devenu un réel espace de conception pour la définition d’un langage de structuration et cela au fur et à mesure de l’identification des informations résultant du processus de capitalisation. L’analyste a d’ailleurs reconnu qu’avec sa montée en expertise sur les technologies XML et sa compréhension du document structuré, il modifierait aujourd’hui ses approches de capitalisation et notamment ses techniques d’entretien. Malgré la grande liberté que nous avons laissé à l’analyste, le document constitue tout de même un mode de représentation de l’information permettant une importante manipulation par les informaticiens. En cela, il constitue un réel support de coopération dans la conception de cette ressource et entre tout à fait dans la catégorie des documents pour l’action. Ainsi, dans notre expérimentation alors même que le document structuré n’était pas stabilisé (en termes de structure et de contenu), il jouait déjà un rôle dans le réseau d’acteurs ; en effet, les experts l’utilisaient – sous une forme qui occultait le balisage – pour analyser et valider le travail de formalisation et de capitalisation réalisé par l’analyste.

La saisie des documents structurés reste toutefois une tâche difficile. Même si nous avons pu initier un non informaticien à la saisie de code XML directement via un éditeur de code source, il est très vite apparu que cette solution ne pouvait répondre totalement à l’activité de gestion des connaissances. Plus généralement, on constate un réel manque de solutions efficaces pour la conception et la construction de documents structurés. On assiste alors à un artisanat de la part des auteurs qui détournent un certain nombre d’outils déployés pour répondre à leurs besoins. Pour appuyer ces auteurs, et particulièrement nos analystes dans le travail de capitalisation des connaissances, notre orientation n’est pas de chercher à développer une solution « tout en un » pour la construction des documents structurés. Nous préférons nous appuyer sur les architextes existants, déployés et déjà exploités par les auteurs. En ce sens, nous avons initié le développement d’un atelier sémiotique de composition de documents permettant de produire une visualisation des documents structurés compatibles avec différents architextes. Cette atelier permet le passage des documents d’un architexte à un autre et capitalise les systèmes sémiotiques définis par les auteur pour pérenniser au mieux les contenus produits par nos analystes.

==Références bibliographiques==
{{CIDE biblio
 |id=1
 |auteur=Jean-Louis Ermine{{!}}J. L. Ermine
 |texte=La gestion des connaissances: Hermès science publications, 2003.
}}

{{CIDE biblio
 |id=2
 |auteur=Michel Grundstein {{!}}M. Grunstein
 |auteur 2=Jean-Paul Barthès {{!}}J. P. Barthès
 |texte="An Industrial View of the process of Capitalizing Knowledge," presented at Fourth International ISMICK Symposium Proceedings, Rotterdam, Netherlands, 1996.
}}

{{CIDE biblio
 |id=3
 |auteur=Rose Dieng-Kuntz {{!}} R. Dieng-Kuntz
 |auteur 2=Olivier Corby{{!}}O. Corby
 |auteur 3=Fabien Gandon {{!}}F. Gandon
 |auteur 4=Alain Giboin{{!}} A. Giboin
 |auteur 5= Joanna Golebiowska{{!}}J. Golebiowska
 |auteur  6=Nada Matta{{!}}N. Matta
 |auteur 7= Myriam Ribière {{!}}M. Ribière
 |texte= Méthodes et outils pour la gestion des connaissances : Une approche pluridisciplinaire du Knowledge Management (2ème édition):Dunod, 2001.
}}

{{CIDE biblio
 |id=4
 |auteur= Nada Matta{{!}}N. Matta
 |texte="Ingénierie des connaissances en conception pour la mémoire de projets," Habilitation à diriger  des Recherches, Ed.: Université de technologie de Compiègne, 2004.
}}

{{CIDE biblio
 |id=5
 |auteur=Manuel Zacklad{{!}} M. Zacklad
 |texte="Processus de documentation dans les Documents pour l'Action (DopA) : statut des annotations et technologies de la coopération associées," presented at Le numérique  : Impact sur le cycle de vie du document pour une analyse interdisciplinaire, ENSSIB, Montréal, 2004.
}}
{{CIDE biblio
 |id=6
 |auteur=Roger T. Pédauque{{!}} R. T. Pédauque
 |texte=Le document à la lumière du numérique. Caen: C&F Editions, 2006.
 
}}
{{CIDE biblio
 |id=7
 |auteur=Marie-Anne Chabin{{!}}M.-A. Chabin
 |texte="Document trace et document source. La technologie numérique change-t-elle la notion de document ?," Information-Interaction-Intelligence, vol. 4, 2004.
}}

{{CIDE biblio
 |id=8
 |auteur=Yves Jeanneret{{!}}Y. Jeanneret
 |auteur 2=Cécile Tardy{{!}}C. Tardy
 |texte="Métamorphoses médiatiques, pratiques d'écriture et médiation des savoirs." Rapport de recherche, Paris: LaLICC - Paris 4, 2007.
}}

{{CIDE biblio
 |id=9
 |auteur=Bruno Bachimont {{!}}B. Bachimont
 |auteur2=Crozat. S{{!}}S. Crozat
 |texte= "Instrumentation numérique des documents : pour une séparation fond forme," I3, vol. 4, 2004.
}}

{{CIDE biblio
 |id=10
 |auteur=:Dominique Cotte{{!}}D. Cotte
 |auteur 2=Marie Després-Lonnet{{!} M. Desprès-Lonnet
 |texte="Le document numérique comme " lego " ou La dialectique peut-elle casser des briques ?," Information-Interaction-Intelligence, vol. 4, 2004.
}}

{{CIDE biblio
 |id=11
 |auteur=Hervé Le Crosnier{{!}} H. L. Crosnier
 |texte="De l'édition de texte à la publication de données," presented at Revue des rencontres internationales de Lure, Lure, 2005.
}}

{{CIDE biblio
 |id=12
 |auteur=Imad Saleh{{!}} I. Saleh
 |texte=Les hypermedias - conception et réalisation Hermes ed, 2005.
}}

{{CIDE biblio
 |id=13
 |auteur= Pascal Béguin{{!}}P. Béguin
 |auteur 2=Pierre Rabardel{{!}}P. Rabardel
 |texte="Concevoir pour les activités instrumentées," Interaction Homme-système, perspectives et recherches psycho ergonomiques, Revue IA, pp. 35-54, 2000.
}}

{{CIDE biblio
 |id=14
 |auteur=Bernard Morand{{!}}B. Morand
  |texte=Logique de la conception - Figures de sémiotique générale d'après Charles S. Pierce: L'Harmattan, 2004.

}}

{{CIDE biblio
 |id=15
 |auteur=Jacques Bertin{{!}} J. Bertin
 |texte=Sémiologie graphique - Les diagrammes - Les réseaux - Les cartes: Editions de l'Ecole des Hautes Etudes en Sciences, 1973.
}}
 {{CIDE biblio
 |id=16
 |auteur=Marc Nanard{{!}} M. Nanard
 |auteur 2=Jocelyne Nanard{{!}}J. Nanard
 |texte= "Saphir : un cadre de référence pour une spécification des hypermédias par intention," in Hypertexte et hypermédia (H2PTM) - Créer, Jouer, Echanger. Paris, 2005.
}}
 {{CIDE biblio
 |id=17
 |auteur=Saïd Taz{{!}}S. Tazi
 |auteur 2=Khalil Drira{{!}}K. Drira
 |auteur 3=Kamal Essajidi{{!}} K. Essajidi
 |texte="Maintien de la cohérence des intentions de communication dans la rédaction coopérative," presented at Conférence Internationale sur la Document Electronique (CIDE) Fribourg (Suisse), 2006.
}}
 {{CIDE biblio
 |id=18
 |auteur=Veronika Lux-Pogodalla{{!}}V. Lux-Pogodalla
 |auteur 2=Jean-Yves Vion-Dury{{!}}J.-Y. Vion-Dury
 |texte= "Réflexions sur la modélisation des documents," Information-Interaction-Intelligence, vol. 4, 2004.
}}

}}
 {{CIDE biblio
 |id=19
 |auteur=Erik T. Ray{{!}}E. T. Ray
 |texte=Introduction à XML Paris: O'Reilly, 2001.
}} 

 {{CIDE biblio
 |id=20
 |auteur= Samuel Parfouru{{!}}S. Parfouru
 |auteur 2=Sylvain Mah{{!}}S. Mahé
 |auteur 3= Manuel Zacklad{{!}} M. Zacklad
 |texte="Using Electronic Document as an Interface for Knowledge Based System," in Workshop on  Knowledge Management and Organizational Memories - International Joint Conference on Artificial Intelligence. Hyderabad - India, 2007.
}} 
{{CIDE biblio
 |id=21
 |auteur=Samuel Parfouru{{!}}S. Parfouru
 |auteur 2=Sylvain Mahé{{!}}S. Mahé
 |auteur 3=Manuel Zacklad{{!}}M. Zacklad
 |texte= "Dispositif Documentaire pour la Gestion des Connaissances," in Conception et Innovation (CONFERE). Marakech (Maroc), 2006.
}}
{{CIDE biblio
 |id=22
 |auteur=Bruno Bachimont{{!}}B. Bachimont
 |texte="Réinterroger les structures documentaires : de la numérisation à l'informatisation," Revue I3, vol. 4, pp. 54-74, 2004.
}}  
{{CIDE biblio
 |id=23
 |auteur=Vincent Quint{{!}}V. Quint
 |auteur 2=Irène Vatton{{!}}I. Vatton
 |texte="Techniques for Authoring Complex XML Documents," presented at Document Engineering, Milwaukee 2004.
}} 
{{CIDE biblio
 |id=24
 |auteur=Samuel Parfouru{{!}}S. Parfouru
 |auteur 2=Alain Grassaud{{!}}A. Grassaud
 |auteur 3=Sylvain Mahé {{!}} S. Mahé
 |auteur 4=Manuel Zacklad{{!}}M. Zacklad
 |texte= "Document pour l'Action comme media pour la Gestion des Connaissances " in CIDE 9, Europia, Ed., 2006, pp. 199-215.
}}

==Notes==
<references/>

__SHOWFACTBOX__