Dernière mise à jour du document (v1.1) : 7 avril 2017.
L’association Open Data France a contacté dtc innovation pour prendre connaissance de l’état de l’art des outils collaboratifs de rédaction de contenus.
Pour le moment, leurs équipes fonctionnent avec plusieurs outils indépendants, qui comportent chacune leurs avantages et leurs inconvénients.
Les outils comme Google Docs sont jugés satisfaisants pour collaborer et gérer les permissions (collaboration, partage). Là où ils pêchent ? Le format de stockage et la réutilisation du contenu.
A l’inverse, GitHub ou GitBook sont jugés satisfaisants pour l’ubiquité du stockage et la versatilité des formats de contenus mais peu satisfaisants pour la collaboration (interfaces techniques, pertes de données, difficile de commenter).
Comment répondre à ces problèmes, fluidifier la chaîne de travail tout en préservant des environnements de collaboration faciles à prendre en main ? Comment créer une solution optimale pour exporter le contenu vers des formats divers ?
L’envie exprimée est de pouvoir collaborer et distribuer de la documentation avec plusieurs centaines de collectivités publiques de manière ouverte et transparente.
L’accent est mis sur la réutilisation de plates-formes techniques existantes, leur souplesse de mise en œuvre et de générer le minimum de code spécifique.
Idéalement, le même ensemble d’outils permettra d’organiser des contenus privés, publics et en cours de rédaction de manière transparente. Les documents gérés par ces outils seront distribués vers des destinations différentes (sites web, newsletters etc.) en fonction de leur étiquetage.
Pour résumer, il s’agit de trouver un système optimal pour :
archiver et organiser le contenu
créer du contenu et l’ouvrir à de multiples collaborateurs (éditeur, correcteur, traducteur…)
exporter le contenu souhaité et l’adapter selon son besoin (site, présentation, newsletter…)
Une seule interface web permet de gérer plusieurs collections de contenus à différents stades de complétion :
documents de référence ;
base de connaissance ;
supports de formation ;
guides pratiques ;
contenus annexes.
Les collections de contenus sont organisés dans un ou plusieurs entrepôts au format Markdown. Cela facilite le ciblage de leur publication : site(s) web, espace documentaire public, espace documentaire privé etc.
Les fichiers Markdown sont transformés en fichiers HTML ou PDF lors de leur publication.
Les interfaces de collaboration propriétaires ont une tendance à enfermer les usagers (nous) et les contenus (nos efforts) dans des interfaces et formats propriétaires. Ces interfaces et formats nécessitent des efforts financiers supplémentaires pour rendre le contenu réutilisable.
Rares sont les outils dissociant le processus de création du contenu (modification de fichier) du processus de revue (contribution, suggestion).
Enfin, la sélection d’outils pour des raisons pratiques mène rapidement à leur démultiplication—et à la difficulté de leur interopérabilité de par l’enfermement des données dans des interfaces graphiques.
L'analyse du processus de collaboration permet de mettre l’accent sur les critères d’interopérabilité qui caractérisent ce qui est en réalité une chaine de publication. Nous pouvons ainsi mesurer l’importance de nos choix et de comprendre les surfaces fonctionnelles couvertes par tel ou tel outil, et de les choisir en conséquence.
Les trois surfaces majeures de la collaboration de contenus sont décrites ci-après.
Markdown ou Asciidoc sont des formats textuels riches, des syntaxes, qui contiennent des indicateurs visuels de la structure graphique du document. Ils permettent :
de structurer du contenu textuel et illustré : document de travail privé et public, FAQ, support de formation, présentation, brouillon etc ;
d’agrémenter les contenus de métadonnées ;
de les transformer dans d’autres formats de représentation comme HTML ou PDF.
L’interface de collaboration offre la possibilité de modifier les fichiers, de les organiser et d’attribuer des rôles d’accès/contribution.
Ces outils offrent plusieurs fonctionnalités :
Les contenus textuels, média et autres fichiers peuvent être organisés selon des règles métier ;
Un contenu ou suggestion de changement suit un chemin de validation avant d’être intégré au document de référence puis rendu public ;
Certaines interfaces permettent le travail à plusieurs sur un même document en simultané sans perte de données ;
La visibilité d’un contenu ou d’une arborescence de contenus peut être déterminée à l’attention d’un public libre ou ciblé en fonction d’un profil d’actions (éditeur, correcteur etc.).
L’avantage des documents créés avec Markdown ou Asciidoc est la variété de leurs usages.
La mise à disposition de documents créés avec ces syntaxes permet de générer des supports multiples à partir d’une même base. Ainsi, le contenu d’une FAQ pourra se retrouver intégrée à un site ou disponible à part entière sur un site dédié, sur une présentation équivalente à Powerpoint, un PDF, etc.
Les opérations de transformation sont rendues possibles dès lors que le stockage des contenus est dissocié de l’interface de collaboration.
Les contenus sont accessibles de manière interopérable sous forme de fichiers en lecture seule, pour archivage, transformation et republication.
L’historisation des contenus avec git offre un canal d’accès en écriture pour des power users.
Les contenus sont accessibles de manière programmatique via une interface HTTP.
Des filtres de requêtes permettent de dériver des documents publics sur un ou plusieurs sites web—voire sous forme d’un jeu de données Open Data.
Il y a une distinction critique entre la modification de contenus en temps-réel et la collaboration.
La modification en temps-réel est impressionnante mais tous les usagers modifient la même copie de travail.
La collaboration permet d'organiser les modifications et suggestions de tous les usagers, d’accepter ou de refuser les changements et d’en garder un historique.
Les outils poussant à la collaboration sont à privilégier car ils favorisent le pilotage par la qualité du contenu.
Netlify CMS permet d’organiser des collections et des workflows de contenus entreposés au format Markdown dans des dépôts privés et publics.
Les contributions sont gérées comme suit :
les éditeurs créent et organisent les contenus ;
les contenus sont publiés après validation d’un éditeur ;
les contributeurs connus soumettent des changements dans le CMS ;
les contributeurs inconnus soumettent des changements depuis GitHub.
Les fichiers Markdown et les médias associés sont dérivés à l’aide de Jekyll pour être hébergés sur l’infrastructure de l’éditeur sous forme de documents HTML mis en forme avec CSS et JavaScript—ou encore sur GitHub Pages, GitLab Pages ou GitBook, entres autres.
Marp est employé pour rédiger des présentations de type Powerpoint mais en Markdown.
Toutes les les intégrations associées à GitHub s’intègrent naturellement à la chaine de publication dont la synchronisation vers GitBook.
Draft permet d’organiser des collections et des contributions de contenus entreposés au format Markdown dans des Team Folders.
Les documents peuvent être démarrés en brouillon dans Evernote ou Google Docs puis importés dans Draft afin de les synchroniser sur Dropbox.
Dropbox est installé sur l’infrastructure de l’éditeur pour synchroniser les fichiers Markdown et les médias associés.
Le système reconstruit les sites Jekyll lors d’un changement.
Draft est employé pour rédiger des présentations en Markdown et les exporter en PDF.
Les outils ayant nourri cette réflexion sont décrits de manière synthétique puis en détail.
Pour rappel, les solutions à privilégier entreposent le contenu dans un format ouvert type Markdown ou Asciidoc, gèrent les suggestions et exposent les contenus sous forme de fichiers.
Produit | Format ouvert | Gestion des suggestions | Temps-réel | API git | API HTTP | Contenu sous forme de fichiers | Export vers d’autres formats de fichiers |
---|---|---|---|---|---|---|---|
Contentful |
|||||||
DokuWiki |
|||||||
Draft |
|||||||
Gollum |
|||||||
Google Docs |
|||||||
HackMD |
|||||||
MultiBàO |
|||||||
Netlify CMS |
|||||||
Notion |
|||||||
ProseMirror |
|||||||
Wikispaces |
|||||||
XWiki |
supporté nativement
avec l’aide d’un plugin
pas supporté nativement
Avantages |
|
Inconvénients |
|
Avantages |
|
Inconvénients |
|
Avantages |
|
Inconvénients |
|
Avantages |
|
Inconvénients |
|
Avantages |
|
Inconvénients |
|
Avantages |
|
Inconvénients |
|
Avantages |
|
Inconvénients |
|
Avantages |
|
Inconvénients |
|
Alternatives |
Avantages |
|
Inconvénients |
|
Avantages |
|
Inconvénients |
|
Avantages |
|
Inconvénients |
|
Avantages |
|
Inconvénients |
|
Le papier A Cloud-Based Real-Time Mobile Collaboration Wiki System détaille un mécanisme idéal de collaboration en temps réel pour contenus textuels.
Ce document est mis à disposition sous licence CC0 1.0 Universel.