Manifeste Pour Des Outils Collaboratifs

Ce manifeste est une traduction de l'article original d'Eugene Eric Kim (de Blue Oxen?, qui héberge le Purple Wiki). Publié en mai 2004 - Dr. Dobb's Journal.

Le présent texte est un manifeste traitant des logiciels collaboratifs. Traitant de pourquoi notre avenir en dépend, de pourquoi la dernière floraison d'outils de ce type ne saurait nous satisfaire, et de ce en quoi enfin les programmeurs peuvent, et doivent, contribuer. @#

Il est tout à fait justifié d'ouvrir ce manifeste avec l'histoire de Douglas Engelbart. Dans les années 60 (XXe siècle), Engelbart et son laboratoire (le Stanford Research Institute, SRI) inventèrent les éléments fondamentaux que l'on peut aujourd'hui trouver dans absolument tous les logiciels collaboratifs. Tout, depuis les structures des données (hypertextes) et les interfaces utilisateurs (systèmes de fenêtrage) jusqu'aux applications (collecticiel) et aux interfaces physiques (souris) @#

C'est là une liste impressionnante et, sans qu'il faille s'en surprendre, Engelbart reçut un grand nombre de prix prestigieux en récompense de toutes ces inventions, -- au nombre de ceux-ci le "AMC Turing Award" en 1997 et la "National Medal of Technology" en 2000. Mais ce qui surprend, en revanche, c'est que, si célébrés qu'aient été les travaux d'Engelbart, nous ne les avons toujours pas compris. @#

Les travaux d'Engelbart furent guidés par quelques observations désespérément simples, qu'il établit dans un article de 1962, "Augmenting Human Intellect: A Conceptual Framework". Sa thèse était la suivante : que les problèmes de la société augmentent à un rythme sans précédent, et que par conséquent les solutions à y apporter doivent suivre le même rythme. C'est notre survie même qui dépend de notre capacité à travailler ensemble de manière plus efficace, à faire preuve d'intelligence collective. Les ordinateurs -- si on les utilise correctement -- peuvent nous y aider. @#

Aujourd'hui, nous célébrons le talent d'Engelbart, mais nous passons à côté de sa motivation. Les ordinateurs devraient nous aider à faire preuve de plus d'intelligence, à mieux travailler ensemble... Au lieu de cela, les concepteurs d'outils logiciels tournent en rond, brassant des concepts éculés au lieu de partir pour d'autres horizons. @#

C'EST SUFFISANT MAIS PAS ASSEZ@#

Une des raisons de cette stagnation ? il semble que nous pensions avoir atteint les limites de ce que peut nous apporter le logiciel, de ce que nous pouvons faire avec lui. Rien ne saurait être plus loin de la vérité. Nos outils logiciels -- particulièrement en espaces de collaboration -- ne sont en aucun cas près de leurs limites. @#

Considérons une tâche de collaboration basique : le partage de documents. Un certain nombre d'applications (tant commerciales qu'open source) prétendent résoudre le problème du partage de documents, et cependant leur méthode prédominante consiste à réaliser ce partage au moyen d'échanges bidirectionnels de courrier électronique. C'est l'équivalent informatique du sneakernet (le réseau basket). Si les outils qui prétendent résoudre ce problème sont vraiment si bons, pourquoi nous ne les utilisons pas ? @#

Problèmes similaires en ce qui concerne d'autres domaines fondamentaux. Je peux m'introduire au sein de n'importe quelle réunion où que ce soit avec rien d'autre qu'un morceau de papier et de quoi écrire, et être sûr ce faisant que chacun pourra le lire, l'annoter, le faire circuler, l'archiver... Peut-on en dire autant des documents électroniques ? Je ne peux pas annoter une page Web ou utiliser le même système d'archivage à la fois pour mon e-mail et mes documents Word, en tout cas pas d'une manière qui me garantisse l'interopérabilité entre ces applications sur ma propre machine et sur celles des autres. -- Pourquoi ? @#

Des solutions à ces problèmes particuliers existent. Hélas, la plupart de ces solutions ne sont pas franchement attirantes, généralement parce qu'elles n'ont pas été pensées en gardant à l'esprit les attentes des utilisateurs. D'un autre côté, quelques unes d'entre elles sont tout à fait intéressantes. Mais être intéressant ne suffit pas. La vérité est que nos besoins sont énormes et variés. Nous utilisons différents outils pour faire notre travail, et nous le ferons toujours. Afin d'avoir un impact réel au sein de l'espace collaboratif, les outils ne doivent pas seulement être bons -- ils doivent aussi faire preuve d'interopérabilité. @#

Chercher à améliorer les outils collaboratifs nous conduit à penser ceci : que nous devons placer l'utilisateur au centre de la conception des applications, et que nous autres développeurs devons travailler conjointement pour que nos outils soient interopérables. @#

L'HUMAIN AVANT TOUT @#

C'est par l'interface utilisateur qu'il s'agit naturellement de construire des applications focalisées sur l'utilisateur lambda. Il n'y a pas de limites aux améliorations possibles à ce niveau, et le nombre croissant de publications en ce domaine démontre bien que l'on y accorde un intérêt ne se démentant pas. @#

Ce n'est pas d'ailleurs, en ce qui concerne l'utilisation, que l'on manque de bonnes idées; c'est que la plupart de ces idées ne se transforment jamais en de vraies applications. Il y a beaucoup de raisons à cela, depuis le manque de perspective en matière d'organisation jusqu'aux égarements du marché. Si incontrôlables et frustrant que puissent être ces facteurs, la responsabilité du changement incombe autant aux chercheurs développant ces idées qu'aux programmeurs qui les implantent. L'open source nous ouvre une voie royale, à la fois excellente et sous-utilisée, pour disséminer des innovations au niveau de l'interface utilisateur. Les chercheurs devraient écrire des plugins pour les applications open source les plus répandues tel le navigateur web Mozilla, au lieu de développer des prototypes en repartant de zéro. Les développeurs open source devraient chercher des idées dans la masse des publications académiques plutôt que de simplement coller aux interfaces des produits commerciaux. @#

Se focaliser sur les gens, ce n'est certes pas s'en tenir à l'interface utilisateur. C'est toute une attitude -- comment pensons-nous nos applications de manière générale ? Une mauvaise attitude peut éloigner les gens de technologies très utiles. @#

Le Web Sémantique est le parfait exemple illustrant ceci. A la base, le Web Sémantique traite des standards pour la représentation du savoir, ce qui constitue un effort de grand impact et méritant notre attention. Néanmoins, la vision monumentale sur laquelle repose ce projet ne se focalise pas assez sur les gens. Les apôtres du mouvement suggèrent qu'en produisant un savoir humain lisible par les machines, les ordinateurs pourront nous aider de manière plus intelligente. Cela a du sens certes mais cela n'explique pas de quelle manière ce savoir sera capturé et converti en amont. Exprimer des connaissances sous une forme accessible aux autres est déjà fort pénible et complexe... Est-ce réaliste alors de juger qu'un grand nombre de gens seront capables d'exprimer des connaissances que les ordinateurs pourront comprendre sans la moindre ambiguïté ? @#

Tandis que les applications futuristes que nous promet le Web Sémantique ont du mal à voir le jour, quelques autres travaux ont su avoir de l'impact dans différentes directions. Le modèle de données Ressource Description Framework (RDF) s'est avéré un outil extrêmement puissant pour représenter l'information, et plusieurs applications -- tels le format de syndication de résumé de site (RSS), le navigateur web Mozilla et l'outil de gestion d'information personnelle Chandler -- commencent à l'utiliser. Plus important encore, RDF est en train de modifier en douceur la façon dont bon nombre d'entre nous pensons les données. Cette influence se retrouve souvent dans l'architecture de nos outils et ce même si le modèle de données RDF lui-même n'est pas utilisé. Le danger est que le Web Sémantique ne paie ces innovations que de mépris, ce qui serait injuste car, bien que minimes, elles sont tout à fait fonctionnelles. @#

UN CADRE DE TRAVAIL CONCEPTUEL PARTAGE @#

La deuxième étape en vue de l'amélioration de nos outils collaboratifs est d'accroître leur interopérabilité. Qu'il y ait matière à créer de nouveaux standards est l'évidence -- en ce qui concerne les protocoles de messagerie instantanée, par exemple -- et dans beaucoup de cas, ces efforts sont déjà en route. Mais la standardisation recèle moins des occasions moins importantes par la quantité que par la qualité. A fin de les identifier, nous devons établir un cadre conceptuel qui nous permette de penser les outils collaboratifs. @#

Il y a en cela de nombreux antécédents logiciels. Nous comptons de nos jours comme acquis des choses tels que les systèmes de fichiers et la gestion de la mémoire, mais il fut un temps où les systèmes d'exploitation n'existaient pas. Maintenant, nous attendons de chaque ordinateur qu'il ait un système d'exploitation, et quoiqu'il y ait des différences, les correspondances élémentaires entre tous ces différents systèmes sont parfaitement opératoires. @#

De même, bien qu'il y ait bien des systèmes de base de données relationnels différents, tous s'appuient sur le même modèle conceptuel -- l'algèbre relationnelle -- et tous parlent le SQL. La création d'un tel modèle partagé pour les bases de données fut l'un des développements majeurs de l'histoire des systèmes d'information. @#

Un cadre conceptuel partagé pour le logiciel collaboratif fournirait un vocabulaire commun pour penser et discuter ces outils, et révélerait aussi des occasions d'en préciser les standards. Pour créer ce cadre, il nous faut identifier les points communs entre les différentes applications collaboratives. C'est peut-être plus facile à dire qu'à faire mais nous pouvons bien partir des idées d'Engelbart. @#

L'EXEMPLE DES RETROLIENS @#

Prenons les Rétro Liens, par exemple. C'est un concept issu des systèmes hypertextuels originaux d'Engelbart. Les rétroliens sont des liens provenant d'autres documents, et pointant vers le document courant. Si par exemple quelqu'un crée un lien à partir de son site web vers l'article que vous êtes en train de lire, ce lien sera un des rétroliens du présent article. @#

Les rétroliens sont-ils une fonctionnalité commune à tous les systèmes collaboratifs ? Deux cas me viennent immédiatement à l'esprit. Le premier c'est Google, le moteur de recherche web qui détermine la pertinence des documents en se basant sur le nombre de rétroliens de chaque page. La théorie est que le nombre de liens vers un document indique son importance relative. Afin de déterminer quels sont ces rétroliens, Google balaie le Web, construisant essentiellement la plus grande base de données de rétroliens du monde. @#

Le second exemple est le Wiki Wiki Web -- ou "Wiki" pour faire court. Les Wikis sont des sites Web que quiconque peut éditer via son navigateur. Du fait de leur simplicité, les Wikis ont rapidement gagné en popularité, en tant que systèmes hypertextuels de publication collaborative. Un des sites wikis les plus connus est Wikipedia, une encyclopédie ouverte permettant à tout internaute de contribuer, et qui est devenue plus fréquentée en nombre d'accès que la vénérable Encyclopedia Britannica Online. Il existe un bon nombre d'implantations de Wikis dans un grand nombre de langues et la plupart d'entre eux font usage des rétroliens. @#

Une fonctionnalité que l'on trouve dans deux applications seulement peut certes ne paraître guère fondée à participer à notre grande construction unifiée -- même si ses applications sont répandues et reconnues. Et pourtant, si l'on examine de plus près les autres outils, des fonctionnalités très similaires aux rétroliens semblent surgir en maint endroit. @#

Les weblogs (aussi connus sous les noms de "carnets web", ou "blogs") sont des journaux en ligne composés de multiples entrées triées par ordre chronologique. Les blogs sont communément utilisés pour commenter d'autres contenus tels que l'actualité... et les autres blogs. Dans la pratique, les blogueurs conversent les uns avec les autres en s'hyperliant fréquemment, chacun commentant ainsi les entrées de tous les autres. Naturellement, les blogueurs tiennent à savoir quels sites pointent leurs entrées. A cette fin, Ben Trott (créateur de l'outil de blog populaire Movable Type) a inventé le Track Back, une spécification ouverte servant à informer automatiquement les blogueurs des liens pointant vers leurs entrées. Les Track Backs sont des rétroliens. @#

Les rétroliens apparaissent même dans la messagerie électronique, -- un outil collaboratif assurément, mais pas franchement quelque chose de pensé en termes d'hypertexte. Quand vous répondez à un e-mail, la plupart des applications enregistrent l'ID de l'e-mail auquel vous répondez. Cet ID équivaut à un lien. Si vous voulez voir toutes les réponses à un e-mail (pour suivre le fil de la discussion, par exemple), ce que vous voulez est essentiellement voir les rétroliens qui pointent vers cet email. @#

Chacune de ces implémentations de rétroliens fut inventée indépendamment pour la même raison : le désir de voir les personnes qui répondent au travail de quelqu'un. En tant que fonctionnalité commune destinée à faciliter ce type de comportement, les rétroliens sont aussi un bon candidat pour le standard. Un système tel Track Back pourrait bien être utilisé pour un site web entier, et non simplement un blog. Le même moteur de rétrolien que l'on trouve sur certains wikis pourrait tout aussi bien être utilisé par d'autres applications. @#

Normaliser les bases de données de rétroliens pourrait en fin de compte créer plus de systèmes de forums ouverts. Beaucoup de sites web de publication incorporent un logiciel de forum permettant aux lecteurs d'en commenter les articles. Cependant, les URL vers les articles intéressants se trouvent souvent dans d'autres forums. Comme ce serait plus aisé et intéressant, si les sites de publication Web pouvaient afficher les liens vers les commentaires dans tous les forums quels qu'ils soient ! @#

Mais la bonne parole ne se limite pas, je crois, qu'à prêcher les rétroliens (même si je pense que c'est un concept de premier plan) ni à égréner le chapelet de leurs applications, lesquelles pourraient potentiellement émerger de leur normalisation (et je suis certain qu'il y en a un paquet). Ce que je crois, c'est que tous nos outils collaboratifs se ressemblent plus que nous ne nous l'imaginons. En développant un cadre conceptuel commun, nous découvrirons ces points communs, ce qui à leur tour créera des occasions de rendre nos outils plus interopérables, et de ce fait plus utiles. @#

UN LANGAGE PARTAGE POUR MODELISER LES DOCUMENTS @#

Un cadre conceptuel commun comprendra naturellement de multiples composants -- et pas un seul qui n'ait priorité sur un autre. Améliorer l'interopérabilité de n'importe lequel de ces composants -- même si cela joue de manière mineure ou imparfaite en un premier temps -- aura pour effet d'améliorer nos outils de manière significative. Par conséquent, nous ne devons pas nous entendre tout de suite sur la structure globale. Collaborons en parallèle sur les composants qui nous intéressent individuellement, et progressons simultanément sur plusieurs fronts à la fois. @#

Cela dit, un point sur lequel nous concentrer, et qui serait d'un impact notable, ce serait de normaliser la manière dont nous regardons, exprimons et manipulons les données structurées, -- les documents en particulier. En d'autres termes, faisons pour les documents ce que l'algèbre relationnelle SQL a fait pour des bases de données ! @#

Tous les outils de collaboration produisent des données -- habituellement sous forme de document structuré. Au niveau le plus fondamental, tous les outils nous permettent de faire les mêmes choses avec ces données : savoir de les créer, de les regarder, parfois même de les éditer. Aujourd'hui, il est clair que d'autres tâches de base seraient souhaitables dans toutes nos applications. @#

Créer des liens, par exemple, serait une caractéristique normale et souhaitable dans tout outil collaboratif. Plusieurs développeurs ont déjà pris conscience de cela et accordent un certain statut aux hyperliens à l'intérieur de leurs outils. Cependant, le fait d'hyperlier est beaucoup plus intéressant si c'est implémenté de façon interopérable entre différentes applications. Votre application de PIM vous permet déjà de relier le nom d'une personne, dans votre calendrier, au contact de cette personne, dans la même application. Que ne vous permet-elle également de lier le contact de cette personne, dans une autre application, vers son e-mail, avec la donnée du lieu de la réunion, de l'ordre du jour, du script de la messagerie instantanée où vous avez convenu de vous voir, etc. ? -- tous les outils étant indépendants et utilisant les formats de fichiers les plus divers. @#

Une autre caractéristique de base qui serait utile dans tous les outils est l'ancre permanente de haute granularité. Un document unique contient souvent beaucoup de "pépites de connaissance" pratique et utile. C'est bien dommage de limiter le lien au document entier plutôt qu'aux portions qui sont réellement pertinentes. Plus important encore, le niveau de granularité devrait être configurable pour chaque type de document. Cela a du sens de penser un article en termes de paragraphes, phrases et mots. Cependant, ces constructions granulaires ne s'appliquent pas au code source du logiciel, tandis que les classes, les méthodes, les variables et les fonctions le font. @#

La première idée qui vienne à l'esprit pour servir cette exigence d'interopérabilité est de tout convertir en XML. Après tout, XML est suffisamment flexible pour représenter toutes ces sortes d'information et il y a déjà des standards de granularité pour adresser des documents formatés en XML. Cependant cette approche est à la fois contingente et erronée. La syntaxe utilisée pour formuler un document n'est pas, en fin de compte, ce qui est en jeu. Ce qui est en jeu, c'est une façon standard de formuler et de manipuler les constructions fondamentales d'un document et ce, indépendamment de toute syntaxe. @#

Cette leçon du XML s'applique aussi bien à tous les prédécesseurs --SGML et Hy Time?. Elle nous apprend que nous pouvons bien exprimer toutes sortes de données en graphes; mais s'il existait un langage standard pour exprimer des modèles de données en graphes (tels que RDF) et des API standards pour manipuler ces modèles de données, la syntaxe réelle des données générées ne serait pas pour autant le facteur principal. Qu'elle nous permette de faire des choses tel que créer un lien à partir d'un document de traitement de texte vers une fonction en code source, sans devoir traduire l'un ou l'autre des documents en un format intermédiaire... @#

EN ROUTE POUR LE FUTUR @#

Toutes les idées que j'ai exposées dans cet article, aussi bien du point de vue des concepts que de celui des techniques, ont une chose en commun : elles ne produiront rien de neuf à moins que tout le monde (les développeurs d'outils) ne travaille ensemble. Créer un cadre conceptuel commun est un véritable problème de collaboration. Il ne sera pas résolu par une personne unique isolée dans quelque tour d'ivoire, et ne se verra pas imposé au reste de la communauté. Il exigera un dialogue constructif et passionné, des esprits ouverts et beaucoup d'expérimentation. Il exigera le respect pour le travail et les idées des autres. Et, cela est primordial, il exigera un désir partagé de faire du monde un endroit meilleur, afin d'améliorer la manière dont nous travaillons ensemble. @#

Cela compris, voici les étapes à suivre pour améliorer les outils de collaboration :@#

  • Être orienté "utilisateur". Ceci s'applique aussi bien à notre manière de concevoir nos outils qu'à notre manière de les mettre sur le marché. @#
  • Désirer collaborer sincèrement. Nous appartenons tous à une communauté de développeurs d'outils partageant le même état d'esprit -- que nous en soyions conscients ou non. Travailler ensemble renforcera cette communauté et améliorera nos outils.@#
  • Créer un langage commun. Nos outils se ressemblent plus que nous le croyons. Converser entre confrères développeurs révélera sans nul doute cette similitude ; créer un langage commun rendra ces similitudes manifestes. Au fur et à mesure qu'un langage commun évoluera, un cadre conceptuel commun pour des outils collaboratifs émergera, révélant bien des occasions d'améliorer l'interopérabilité de nos outils.@#
  • Améliorer encore et toujours. L'amélioration est un processus continu. Introduire de nouvelles fonctionnalités plus efficaces modifiera notre manière de collaborer et créera à son tour de nouvelles occasions d'améliorer ces mêmes outils.@#

En guise de conclusion, n'oublions jamais la doctrine fondamentale de Douglas Engelbart : "les ordinateurs devraient nous aider à devenir plus intelligents et à mieux travailler ensemble.". Gardons cela en mémoire, et nous resterons toujours sur la bonne voie.@#

Remerciements #

Un grand merci à Danny Ayers?, Chris Dent?, Doug Engelbart, Johannes Ernst?, Richard Gabriel?, H.Jessica Kim?, et Justin Lin? pour avoir corrigé les premiers brouillons de cet article. #

Architecture Information Collaborative? Category Travail Collaboratif

Dernière modification le lundi 20 juin 2005 0:25:26

Éditer HistoriqueDeLaPage Diff  InfosSurLaPage