Conception des chaînes éditoriales

Deux critères nous permettent de différencier des catégories de projets de rééditorialisation : la convergence et la portée.

Soit un atelier premier faisant référence par rapport à un atelier second. Nous définissons la portée d'un projet de rééditorialisation comme la partie des fragments exploités par l'atelier premier à rééditorialiser dans l'atelier second. La portée peut donc être partielle ou totale. Une portée totale désigne la rééditorialisation de l'ensemble des fragments de l'atelier premier dans l'atelier second. Une portée partielle désigne la rééditorialisation d'une partie des fragments de l'atelier premier.

Les modifications opérées dans la dérivation d'un fragment peuvent avoir vocation à produire un nouveau fragment (pour produire un contenu dérivé) ou à l'inverse, à réintégrer le fragment d'origine (la dérivation est alors souvent utilisée pour protéger le fragment de l'atelier premier de modifications non terminées). On parlera de rééditorialisation divergente dans le premier cas et de rééditorialisation convergente dans le second.

Nous distinguons ainsi quatre types de projets de rééditorialisation qui varient en fonction de la portée et de la direction :

Un projet de rééditorialisation divergent total est utilisé pour rééditorialiser l'ensemble des fragments issus d'un graphe documentaire dans le but de produire de nouveaux documents.

Soit par exemple un graphe mobilisé pour écrire la documentation technique d'un logiciel (telle que la documentation de la chaîne éditoriale OptimOffice par exemple).

Afin de produire la documentation d'un logiciel dérivé par rapport au logiciel initial (comme par exemple la documentation de la chaîne éditoriale Dokiel par rapport à celle d'OptimOffice), un atelier second instrumentant une fonction de rééditorialisation divergente totale peut être mis en place. Les modifications sont alors rédigées dans l'atelier second sans altérer les fragments de l'atelier premier.

Un projet de rééditorialisation convergent total peut être mis en place pour protéger un graphe documentaire de modifications inopportunes. Les interventions sur le graphe sont rédigées dans un atelier dédié et les fragments sont mis à jour lorsque la modification est jugée suffisante.

Soit un graphe exploité pour la production d'une documentation sensible, comme le site service-public.fr par exemple. À l'état initial, le graphe est exploitable dans un atelier premier comme illustré sur la figure 67.

Plusieurs rédacteurs travaillent à plein temps sur la maintenance du graphe. Si le site service-public.fr contient une coquille importante à corriger sans délai, le fragment concerné est modifié rapidement et le site web est re-publié. Si d'autres rédacteurs travaillent sur des mises à jour de fiches en parallèle, des fiches altérées, encore non terminées, pourraient être publiées. Afin de protéger le graphe de ces fiches encore non terminées, un projet de rééditorialisation convergent et total peut être mis en place. Un atelier second est alors initialisé. Il s'agit ici d'un projet auctorial puisqu'il ne vise pas à produire de nouveaux documents mais à mieux outiller la production de documents existants.

Ainsi, l'ensemble des opérations de maintenance a lieu dans un atelier second. Comme illustré sur la figure 68, les fragments sont modifiés dans un atelier second sans que cela n'altère les fragments de l'atelier premier.

Lorsqu'une modification est reversée, le contenu du fragment surchargé écrase le fragment d'origine et la surcharge, devenue inutile, est supprimée. Sur la figure 69, le fragment B0' est reversé vers l'atelier premier. Son contenu modifié (matérialisé par la couleur violette) est copié dans le fragment B0. Le fragment B0' est ensuite supprimé. Ainsi, quel que soit l'instant auquel le site web est publié, il ne contient jamais de scories issues de fiches en cours de modification.

Un projet de rééditorialisation divergent partiel est utilisé pour réutiliser et surcharger une partie d'un graphe. Soit par exemple un enseignant A et un enseignant B intervenant dans la même discipline mais à des niveaux différents.

L'enseignant B peut demander à l'enseignant A de réutiliser ses contenus afin de les surcharger et de les adapter à son niveau.

Un projet de rééditorialisation convergent partiel est utilisé pour permettre la réutilisation d'une partie d'un graphe dans un autre atelier et donc de lier cette portion du graphe avec d'autres fragments. Ce type de fonction peut être utilisé pour partager des fragments entre deux projets éditoriaux distincts.

Soient par exemple deux enseignants A et B exploitant chacun un graphe distinct pour la rédaction d'un cours (figure 70). Lorsque l'enseignant A veut partager des contenus avec l'enseignant B, une fonction de rééditorialisation convergente partielle peut être utilisée. Ainsi l'enseignant B peut référencer ou surcharger les contenus de l'enseignant A (figure 71).

Si une des surcharges réalisées par l'enseignant B intéresse également l'enseignant A (par exemple, pour récupérer des corrections ou des améliorations dans certains contenus), l'aspect convergent de la fonction de rééditorialisation permet à l'enseignant B de reverser ses modifications au sein de l'atelier de l'enseignant A. Comme pour l'exemple précédent, le contenu de la surcharge écrase le fragment original et la surcharge est supprimée.

Les exemples précédents montrent une proximité entre les usages des projets de rééditorialisation convergents et divergents. La seule différence sur le plan fonctionnel semble être la possibilité de reverser des modifications pour les projets de rééditorialisation convergents. L'outillage d'un projet de rééditorialisation divergent serait alors un simple sous ensemble de celui d'un projet de rééditorialisation convergent. Outiller un projets de rééditorialisation convergent demande une contrepartie dans la gestion des identifiants du système.

Chaque fragment dispose d'un identifiant par lequel il est référencé lorsqu'il est mobilisé par un autre fragment du graphe. Lors de la surcharge d'un fragment dans un atelier dédié, le fragment d'origine est conservé et un nouveau fragment est créé. Si le nouveau fragment dispose d'un nouvel identifiant, il est alors nécessaire de mettre à jour l'ensemble des fragments le référençant. Cette mise à jour modifie le contenu des fragments en question, qui sont donc dupliqués et surchargés et ainsi de suite.

Par exemple, ce principe de changement des identifiants a été appliqué sur la figure 73. En effectuant une modification sur le fragment B2, un nouveau fragment B2' est créé. Avec ce nouvel identifiant, il est nécessaire de mettre à jour le fragment B1 dans l'atelier dédié, afin de pointer B2' à la place de B2. Cette mise à jour est une surcharge qui crée un nouveau fragment B1'. Il devient alors nécessaire de modifier le fragment B0 afin de référencer B1' dans l'atelier dédié à la place de B1. Une troisième surcharge est donc créée. Dans ce graphe fortement simplifié, une simple modification de B2 entraîne la surcharge de trois fragments.

Afin d'optimiser ce système, nous proposons de distinguer deux identifiants dans la mise en place de fonctions permettant d'isoler un projet de rééditorialisation : un identifiant privé pour le fonctionnement interne de la chaîne éditoriale et un identifiant public associé à un atelier dédié. Ainsi en effectuant une surcharge du fragment B2 dans l'atelier dédié, un nouveau fragment est créé. Son identifiant privé utilisé par la chaîne éditoriale pour manipuler le fragment est B2'. Son identifiant public associé à l'atelier dédié est B2. Ainsi, lors de la résolution des liens dans l'atelier dédié, le fragment B1 référence un fragment nommé B2 qui correspond dans ce contexte au fragment B2'. Les fragments B1 et B0 n'ont plus besoin d'être surchargé.

Ce système est efficace mais il pose un problème lorsque les mêmes contenus sont rééditorialisés dans des ateliers dédiés avant d'être mutualisés dans un même atelier comme dans l'exemple de traduction de la section précédente. Dans cet exemple, les fragments des traductions anglaise, espagnole, chinoise et allemande conservent les mêmes identifiants publics que la documentation initiale. En mutualisant les différentes documentations dans un même atelier dédié, cinq jeux de fragments seraient alors importés avec les mêmes identifiants publics, rendant inutilisable le système d'identifiant public/privé. Pour parer à ce problème, nous proposons de faire varier la gestion des identifiants en fonction de la direction de la rééditorialisation : une rééditorialisation convergente dispose d’identifiants publics et privés ; une rééditorialisation divergente met systématiquement en place de nouveaux identifiants. Avec un tel fonctionnement, les risques de conflits sont minimisés et la création de fragments surchargés pour un simple renommage des identifiants est réduite.

Pour améliorer la lisibilité des représentations de graphe, nous considérons systématiquement les projets de rééditorialisation comme convergents du point de vue de la gestion des identifiants. Ainsi, contrairement à la figure 73, nous n'indiquons pas les surcharges automatiques des fragments référençant un fragment surchargé par un rédacteur.

Les conflits d'identifiants entre fragments sont identifiables selon l'architecture des ateliers mis en place. Un conflit survient lorsqu'un fragment est importé avec le même identifiant depuis deux ateliers différents. Deux ateliers partagent les mêmes identifiants pour un fragment s'ils sont reliés par une fonction convergente. La fonction convergente peut être directe (les deux ateliers sont directement reliés) ou indirecte (les deux ateliers sont reliés par une chaîne d'ateliers et de liens de rééditorialisation convergente).

Pour détecter les conflits, nous recommandons d'utiliser un graphe de contrôle sur lequel chaque atelier correspond à un sommet et chaque lien convergent à une arête. Un conflit est alors détecté par la présence de cycles. Reprenons l'exemple de la section précédente. Comme en atteste la figure 74, en maintenant uniquement des fonctions convergentes, on y décèle de nombreux cycles désignant autant de conflits d'identifiants.

Dans cet exemple, les traductions correspondent à des réécritures du contenu. Les fragments sont modifiés et ces modifications n'ont pas vocation à être réintroduites dans la version française. Par conséquent, il n'est pas logique de maintenir des liens convergents entre la version française et les traductions. En devenant divergents, ces liens disparaissent du graphe de contrôle. Plus aucun cycle n'est visible sur la figure 75, il n'y a donc plus de conflits d'identifiants au sein des différents ateliers.