Commençons par un exemple. Le rédacteur d’un guide touristique saisit un nom de lieu. Le correcteur orthographique peut intervenir s’il possède un dictionnaire des noms de lieu. Mais il est encore plus souhaitable que le nom soit considéré comme un élément (i.e. un composant documentaire) auquel on puisse rattacher une propriété et surtout qu’il soit sans ambiguïté en cas d’homonymie. Pareillement, s’il s’agit de nom de personnes ou d’organisations, il est souhaitable d’identifier sans ambiguïté le terme utilisé. Si la personne ou l’organisation n’existe pas dans le thésaurus associé au système de gestion de contenu utilisé, celle ci peut alors être ajoutée (ou faire l’objet d’une proposition d’ajout) dans le thésaurus de l’entreprise. Le logiciel d’édition doit donc proposer des interfaces qui permettent au créateur de compléter les informations nécessaires lorsqu’il rédige un document. On parle dans ce cas d’utilisation de vocabulaire contrôlé à l’aide de dictionnaires 30.
Mais concernant par exemple les personnes, le dictionnaire peut tout simplement être une base de données servant à d’autres applications informatiques de l’entreprise.
Voyons un autre exemple, un conseiller juridique édite un contrat pour un client. Le nom du client figure dans le paragraphe concernant les « parties » du contrat. Le client existe déjà dans le sens où le cabinet de conseil juridique a déjà travaillé pour lui. Il est référencé dans le système d’information du cabinet. Il s’agit alors de relier le contrat en cours de rédaction avec le client dans le système d’information. Derrière le nom du client, on aura par exemple un attribut identifiant (ID) le client de manière unique. Il s’agira là de gestion de contenu adapté à la gestion de clientèle (CRM –Customer Relationship Management). Si le client est nouveau et n’existe pas, il devra être crée dans l’application ad hoc afin de pouvoir être référencé. Cet exemple peut être poursuivi avec la facturation : la facture reprendra le numéro (ID) du contrat avec d’autres éléments identifiant plus explicites. Ces éléments sont définis dans le contrat (titre, auteur, date, nom du client, etc…) et repris dans la facture.
L’éditeur de document devient ainsi un formulaire interactif qui réagit aux événements de saisie de manière contextuelle en proposant des choix et des fenêtres de saisie (liste de choix, nouveau formulaire lié) qui permettent au rédacteur de préciser de quoi il parle, sans trop alourdir sa tâche.
Le formulaire est donc lié aux applications de base de données de l’entreprise, c’est pour cela que nous parlons de synchronisation des éditeurs aux systèmes de gestion de bases de données (SGBD).
Par rapport à l’exemple des contrats, il s’agit là de documents appliquant une forte réutilisation des composants documentaires. L’éditeur de texte va donc proposer dans le formulaire interactif une fonction permettant d’éventuellement inclure une clause par défaut (valeur par défaut d’un composant documentaire d’un type de document, réutilisation systématique) ou une clause connue, recherchée et incorporée par le rédacteur (réutilisation opportuniste). De même, s’agissant de réutilisation, l’éditeur devra appliquer les règles de réutilisation associées au composant en question : contenu réutilisé éditable ou verrouillé (voir chapitre 2.1.3.1 « Partage de composant »).
30 Certains parlent également de thésaurus
