Nous pensons que pour les activités qui nous intéressent (en particulier : activités de conception participative et de partage de connaissances en situation d’incertitude) le Wiki Fédéré est un meilleur outil que le Wiki classique (représenté par exemple par le logiciel libre MediaWiki , et les règles à la base de Wikipedia et des applications encyclopédiques de ce type). Pour les mêmes raisons (en tous cas, avec beaucoup d’arguments en commun) le Wiki Fédéré apparaît plus aussi plus intéressant que GoogleDocs et les outils de la famille GoogleDrive.
L’outil Small Federated Wiki développé par Ward Cunningham (utilisé ici) date environ de 2013, mais il est le résultat d’une longue maturation. En fait, W. Cunningham a mûri progressivement les concepts de Wiki Fédéré sont arrivés dans les 15 années précédentes. L’argumentation mise en avant par W.Cunningham (cf. la figure ci-dessous qui remonte à une de ses présentations en 2005) plaide pour un protocole de « fédération » où dans les activités croisées des acteurs concepteurs (qu’elles soient synchrones ou non : coécriture, mais aussi débat, confrontation, mise à l’épreuve, amélioration…) les droits de chacun soient reconnus sur chaque page et fragment qu’il a écrit. Mais ce protocole, qui rend possible que chacun soit « maître et responsable chez soi », rend aussi possible (et encourage) pour chacun d’emprunter et répliquer des pages et fragments venant des autres auteurs, dans le respects des droits de chacun.
Principe de fédération adaptative utilisé dans le Wiki Fédéré (Cunningham, 2005)
Car cela n’empêche pas de profiter, pour ces fragments participant à la conception collective, de toutes les aspects positifs des techniques de gestion de versions dans un cadre de travail en réseau. Ce sont des techniques que le courant du Logiciel Libre a désormais permis de mettre bien au point, pour le développement de logiciel, et qui sont ici réutilisées pour les documents. Dans ces conditions, emprunter et répliquer des fragments dont chaque auteur a besoin (par exemple des fragments reconnus utiles, valables, bien exprimés, etc. ou des fragments que l'on souhaite retravailler, transformer), cela devient des actions licites, et même encouragées par le protocole de fédération. Les solutions d’interface correspondantes dans les outils de Wiki Fédéré permettent dans toute page de réaliser les opérations de bifurcation de version (« fork ») et de tracer et retrouver précisément à quel auteur et à quelle date a été emprunté tout fragment répliqué. (cf. figure )
Techniquement dans le Wiki Fédéré chaque document contient toutes ses révisions (en comparaison, ce n’est pas le cas avec FaceBook). L’interface de Small Federated Wiki permet de comparer visuellement differentes versions du documents d’un même auteur et differents documents d’un même auteur mais aussi d’auteurs différents sans clicks additionels. Ce n’est pas le cas avec GoogleDocs les outils Wiki classiques, où les contributions des différents auteurs sont littéralement « noyées » dans le résultat commun, avec une priorité très forte donnée à la visualisation au plus tôt du "résultat" majoritaire.
Or dans les situations de conception et d’élaboration/partage de connaissance en contexte d’incertitude, il ne s’agit pas seulement de d’avoir un système pour co-écrire et mettre à disposition d’une communauté des notices et des fiches de connaissances synthétisant une connaissance acquise, ce que proposent très bien le Wiki Classique ou GoogleDocs. C’est dans la nécessité de construction (souvent à partir de très peu de certitudes acquises, comme dans les cas d’expérience où on ne peut partir que de l’observation de la réalité) et dans le processus de construction que réside la différence.
En conception comme dans le cas de fortes incertitudes ou de conflit d’interprétation, il n’y a pas « un seul contenu » qui puisse faire rapidement l’unanimité, il faut du temps et une certaine liberté pour que des positions différentes s’élaborent et se confrontent par des dialogues et des lectures croisées. Chaque position nécessite de nombreux documents, tâtonnements et ajustement progressifs dans un contexte où l’autonomie de chaque concepteur doit être préservée, tout en permettant à chacun d’être connecté avec les avancées des autres. Avec le Wiki Fédéré, on a donc affaire aussi à un corpus co-écrit à plusieurs mains, mais qui est de nature différente d’un corpus de textes Wiki classique ou de documents GoogleDocs. Ces derniers outils permettent certes d’accéder via les fonctions de « l’historique » au processus par lequel des fragments d’auteurs différents se sont complétés ou confrontés.
Ces fonctions d’historique, d’ailleurs plutôt performantes, restent inadaptées à une visualisation croisée des contributions et des positions dans chaque version, car il est présupposé dans ces outils qu’un unique résultat doit être atteint, et atteint rapidement. En particulier cela fait du Wiki classique ou de GoogleDocs des outils mal adaptés au travail de conception lorsqu’il y a des métiers différents qui ont chacun des connaissances et des vues différentes sur l’objet à concevoir, il leur faut de nombreux échanges, réunion, confrontation de plans, d’annotation, avant que le position puissent s’aligner dans un design commun.
Le Wiki classique n’est pas bien adapté à la conception participative avec des conflits. La raison de fond en est que l’objectif (et valeur dominante, explicite dans la Charte de la communauté Wikipedia) de Wikipedia en tant qu’encyclopédie est de rendre compte avant tout d’une connaissance « vraie ». En contrepartie cela implique que dans le Wiki Classique l’historique des versions et des débats d’où résulte la notice reste « en coulisses » escamotant les positions antagonistes par une visualisation difficile, et décourageant les positions minoritaires du fait du protocole de construction utilisé.
Il est intéressant de noter pour finir que les recherches de Ward Cunningham, qui l’ont conduit à inventer le Wiki puis le « Federated Wiki », étaient à chaque fois orientées par le souci de supporter des activités de conception (en particulier le design d’artefacts informatisés avec des méthodes agiles).
Cunningham, W., Where From Where To Prehistory and Speculation about Wiki, Wikimania 2005 Frankfurt, Germany, (on line : http://c2.com/doc/wikimania/)
Cunningham, W., “Federation”, realtime conference, 33mn, october 2012, (online:http://video.fed.wiki.org/view/welcome-visitors/view/federated-wiki-videos )