Archive

Articles taggués ‘Annonces Wikimedia Foundation’
un commentaire 10/12/2012

Créer un éditeur visuel pour MediaWiki : en quoi est-ce complexe ?

Ce billet, Inventing as we go: building a visual editor for MediaWiki, a été écrit par James Forrester et publié sur le blog de la Wikimedia Foundation sous licence CC-BY, et a été traduit en français par Jean-Frédéric, Ælfgar, Emeric, R et Cha_Matou.


Logo du VisualEditorLa Wikimedia Foundation et Wikia, travaillent sur un Éditeur visuel (VisualEditor), pour Wikipédia et tous les autres sites utilisant le logiciel MediaWiki. Cela prend beaucoup de temps, et on nous demande souvent ce que le travail implique, si c’est difficile, et pourquoi c’est aussi long. Il nous semble donc utile d’expliquer quelques-unes des subtilités du projet de développement logiciel le plus ambitieux de la Wikimedia Foundation.

Qu’essayons-nous de faire ?

Nous créons un logiciel qui permettra aux utilisateurs de charger, de modifier et d’enregistrer les articles Wikipédia en mode visuel, en remplacement du système actuel qui requiert l’apprentissage d’une syntaxe wiki compliquée. Avec le nouveau système, les articles qu’ils éditeront se présenteront de la même manière que ceux qu’ils lisent : les modifications qu’ils feront seront visibles avant même de sauvegarder, à la manière de l’édition d’un document dans un traitement de texte.

Personne n’avait fait cela avant ?

Oui et non. De nombreux éditeurs de texte en mode visuel existent, certains d’entre eux sont même open source et capables d’éditer de manière assez satisfaisante des pages web. Mais ils demeurent insuffisants par rapport à nos besoins, pour plusieurs raisons.

Il est particulièrement important que notre éditeur puisse fonctionner dans de nombreuses langues. Il ne s’agit pas simplement d’intégrer les langues qui s’écrivent de droite à gauche, ou avec des idéogrammes, mais bien d’être compatible avec chacune des 290 langues que nous proposons actuellement. Nous voulons également permettre l’utilisation de plusieurs langues dans un même document, de manière entièrement transparente, pour mieux servir nos communautés multilingues. Certaines des langues que nous nous sommes engagés à proposer ont un support logiciel très faible, et nous sommes souvent l’une des plus importantes, sinon l’une des seules, sources de contenu écrit pour elles.

Le développement de la syntaxe wiki au cours des douze dernières années constitue un autre problème : elle intègre désormais de nombreuses fonctionnalités riches et complexes, qui ne sont pas « du HTML simplifié ». Nous pensions que la plupart ne seraient utilisées que de manière ponctuelle, mais elles ont souvent évolué pour se retrouver au cœur de la façon dont les pages MediaWiki sont maintenant écrites, par des utilisateurs toujours plus nombreux.

Parmi ces fonctionnalités avancées : la transclusion de contenu (insérer une copie en temps réel d’une page dans une autre), les modèles (transclusion dont certaines parties sont définies dans la page de destination plutôt qu’à la source), et les parser functions (pages affichant différentes choses en fonction de centaines d’options, comme le jour de la semaine ou l’existence d’une autre page). Essayer d’adapter un éditeur existant à ces fonctionnalités aurait été extrêmement difficile, et plus compliqué que de partir de rien.

Comment l’éditeur visuel et le Parsoid fonctionnent ensemble

Qu’est-ce que le parseur ?

Au bout du compte, il ne s’agit pas seulement de modifier les pages, mais de lire et sauvegarder les pages wiki existantes dans l’ancien wikitexte, et de continuer à travailler avec en parallèle du nouvel éditeur. Nous ne pouvons mettre à la poubelle l’immense travail accompli par nos communautés durant ces douze dernières années, aussi nous faut-il réécrire ce « traducteur ». Ce qui veut dire réaliser un « parseur » (ou analyseur syntaxique) à double sens : un logiciel qui convertit le wikitexte en HTML et inversement. Jusqu’à présent, nous n’avions qu’un parseur à sens unique ; la deuxième étape, convertir ce que l’on souhaite écrire en wikitexte, c’était aux contributeurs de le faire dans leur tête.

Cela signifie que nous avons dû créer un projet à part − le Parsoid − capable de traduire dans un sens comme dans l’autre : de la syntaxe wiki aux pages web et inversement. C’est loin d’être une tâche facile : il faut être très prudent lorsque l’on change de parseur, car il est de la plus haute importance de ne rien casser ! Le vieux parseur, et la syntaxe wiki qu’il interprète, se sont développés au fil des idées des contributeurs, sans véritable idée directrice. Il y a près de deux milliards de versions des pages dans les seuls projets Wikimedia, et ce manque de vision d’ensemble a donné naissance à un très grand nombre de petites règles que le Parsoid doit suivre pour éviter des « dirty-diffs » – des cas où la syntaxe wiki ne serait pas interprétée par l’éditeur visuel.

Explication du modèle HTML+RDFa utilisé par le Parsoid

Nous utilisons du test automatique pour transformer en « aller-retour » 100 000 pages prises au hasard dans la Wikipédia en langue anglaise (soit un bon échantillon de contenu wiki en alphabet latin) : prendre le wikitexte, le convertir en HTML, puis à nouveau en wikitexte, et comparer le résultat avec le document original. Cela nous aide à identifier de nombreux problèmes à résoudre pour que l’utilisation du Parsoid ne casse pas les articles. Nous en sommes aujourd’hui à 80% d’articles transformés en « aller-retour » sans aucune différence (au lieu de 65% en octobre), 18 % supplémentaires ne présentent que des différences mineures (espaces, guillemets, etc.), et les 2 % restants présentent des différences qui restent à résoudre (15% en octobre).

En savoir plus

Comme vous pouvez le voir, créer l’éditeur visuel dont ont besoin nos utilisateurs représente beaucoup de travail. Aucune technologie existante ne peut faire ce que nous voulons, nous devons donc travailler très dur pour y arriver. Nous attendons avec impatience les prochains mois pour montrer aux contributeurs comment ils pourront utiliser l’éditeur visuel et Parsoid. Pour leur permettre une meilleure expérience, libre de l’apprentissage des syntaxes compliquées, leur permettant de se concentrer sur le contenu et non sur les outils qu’ils utilisent pour écrire.

Si vous êtes intéressé, nous avons une brève présentation sur la façon dont l’éditeur visuel et le parseur fonctionnent, et ce à quoi ils ressembleront dans Wikipédia.

James Forrester
Product Manager, VisualEditor et Parsoid


Information de droit d’auteur : “VisualEditor-logo” Public Domain, ™Wikimedia Foundation, Inc., “Parsoid HTML-RDFa content model” par Jdforrester (WMF), sous CC-BY-SA 3.0, “VisualEditor-ModuleStack” par Trevor Parscal, sous  CC-BY-SA 3.0

2 commentaires 09/11/2012

Le nouveau lecteur vidéo de Wikipédia

Un nouveau lecteur vidéo a été déployé sur Wikipédia et ses projets frères, et avec lui vient la possibilité d’apporter des vidéos pédagogiques libres à davantage de personnes, sur davantage de plate-formes, dans davantage de langues.

Le lecteur est le même que le lecteur HTML5 utilisé par la plate-forme de vidéo open-souce Kaltura. Il a été intégré à MediaWiki (le logiciel qui propulse les sites Wikimédia dont Wikipédia) via une extension nommée TimedMediaHandler. Il remplace l’ancien lecteur Ogg utilisé depuis 2007.


Le nouveau lecteur vidéo a un support pour les sous-titres en de multiples langues.
(Eben Moglen, CC-BY-SA)

Basé sur HTML5, le nouveau lecteur lit des fichiers audio et vidéo depuis les pages Wiki. Il apporte de nombreuses fonctionnalités, comme le support pour les sous-titres et le Timed Text. En permettant aux contributeurs de transcrire les vidéos, le nouveau lecteur est un pas important vers l’accessibilité aux personnes mal-entendantes. Les sous-titres peuvent être aisément traduits, élargissant ainsi leur public potentiel.

TimedMediaHandler apporte également d’autres fonctionnalités utiles, comme le support du format multimédia ouvert WebM. Le support de WebM permet de téléverser de façon transparente les vidéos encodées dans ce format, comme par exemple toutes les nombreuses vidéos sous licence libre présentes sur YouTube.

Encore davantage “sous le capot”, TimedMediaHandler supporte le transcodage côté serveur, c’est à dire la capacité à convertir une vidéo d’un format à un autre, dans le but de fournir un flux vidéo approprié à l’utilisateur, en fonction de sa bande passante et de la taille du lecteur. Par exemple, le support des formats mobiles est possible, bien qu’il ne soit pas encore activé. La fonctionnalité “Partager” du lecteur fournit un court extrait de code pour insérer directement les vidéos de Wikimedia Commons dans les pages web et les billets de blog.

La fonctionnalité “Partager” du lecteur fournit un extrait de code pour insérer directement des vidéos de Wikimedia Commons dans les pages web, comme ici.
(Vidéo par Frank Vincentz, CC-BY-SA)

Soutenus par Kaltura et Google, les développeurs Michael Dale et Jan Gerver sont les principaux architectes du déploiement réussi du nouveau lecteur. Avec le soutien de l’équipe d’ingénierie de la Wikimedia Foundation et de Kaltura, ils ont procédé à de nombreux cycles de déploiement, révision et test avant de pouvoir enfin publier le fruit d’années de travail.

Les efforts pour mieux intégrer les contenus vidéos sur Wikipédia et les projets frères remontent à 2008, lorsque Kaltura et la Wikimedia Foundation annoncent leur première expérimentation commune en matière de vidéos. Depuis, des améliorations incrémentales ont été publiées, mais le déploiement de TimedMediaHandler est le plus franc succès à ce jour.

Les utilisateurs de Wikimedia Commons avaient déjà accès à certaines des fonctionnalités de TimedMediaHandler durant le développement, sous une forme expérimentale. Les utilisateurs enregistrés pouvaient activer la beta dans leurs préférences pour disposer d’une meilleure interface et pouvoir modifier des sous-titres. Puisque le nouveau lecteur est compatible avec les sous-titres créés durant cette période, nous disposons dès à présent d’un large corpus déjà fonctionnel − par exemple ce montage d’interviews de Wikipédiens.

Wikimedia Commons est la médiathèque de Wikipédia et des projets frères. Elle constitue l’archive de tous leurs contenus multimédia. Même si une vidéo est hébergée ailleurs, les sites Wikimedia ont besoin de leur propre copie pour assurer que la ressource reste disponible même si ces sites venaient à disparaître. Du point de vue de la vie privée, cela assure aussi que les informations personnelles des utilisateurs ne sont pas transmises à des sites tiers. Le nouveau lecteur respecte également les licences libres en affichant les informations sur l’auteur à la fin de la vidéo, quel que soit le site où elle est intégrée.

Cet engagement s’accompagne d’importants défis techniques. Pour de nombreux sites, afficher une vidéo est aussi simple que de l’insérer depuis une plate-forme comme YouTube ou Vimeo. En utilisant un simple code HTML, n’importe-quel blogueur peut insérer une vidéo directement dans leurs pages web, sans se soucier de l’espace disque, des codecs, du support des navigateurs ou de la bande passante.

Bien que les sites Wikimédia soient de bien plus modestes plate-formes d’hébergement vidéo, il leur faut aussi répondre à ces questions difficiles. Par exemple, les ingénieurs de la Wikimedia Foundation se sont lancés dans la longue refonte de l’infrastructure de stockage de vidéos, afin de pouvoir suivre les besoins en stockage pour les contenus multimédia. Plus récemment, ils ont amélioré la performance des serveurs de cache pour servir des vidéos.

Le défi technique de la vidéo sur Wikipedia ne se limite pas à fournir le contenu aux lecteurs : importer ces vidéos est tout aussi important, en raison de la nature participative des sites Wikimedia. Apporter des contenus vidéos originaux de qualité à Wikipédia est plus difficile que de modifier du texte sur une page wiki.

En 2010, l’Open Video Alliance a lancé une campagne appelée « Let’s Get Video on Wikipedia » ( « mettons de la vidéo sur Wikipédia »). Ce projet avait pour but d’inciter les gens à créer du contenu vidéo et le mettre en ligne sur Wikimedia Commons. Il comportait un tutoriel et un assistant expérimental pour insérer des vidéos dans les articles de Wikipédia.

L’“UploadWizard“, un assistant de mise en ligne pas-à-pas développé par la Wikimedia Foundation en 2010-2011, a été crucial pour rendre la participation au multimédia plus accessible et intuitive. Des améliorations sont en cours de développement, qui faciliteront la contribution vidéo, comme le téléversement « par morceaux », actuellement expérimental, qui permet une meilleure fiabilité des transferts de gros fichiers.

Sur Internet, la vidéo est très statique : une fois mise en ligne, elle est rarement modifiée. À l’inverse, le succès de Wikipédia repose sur le grand nombre des bénévoles qui modifient et améliorent constamment les contributions les uns des autres.

Des outils adaptés vont heureusement réduire cette dissonance, comme le séquenceur de Kaltura, qui permet aux utilisateurs de directement remixer des vidéos en ligne. Le succès de l’adaptation de sa nature coopérative aux contenus multimédia sera crucial pour le passage de Wikipédia à l’ère de la vidéo.

Guillaume Paumier.
Technical communications manager


Ce billet, Introducing Wikipedia’s new HTML5 video player, a été écrit par Guillaume Paumier et publié sur le blog de la Wikimedia Foundation sous licence CC-BY, et a été traduit en français par Jean-Frédéric et El Caro avec l’aide de Pleclown, Mathilde et Moyg.

Aucun commentaire 10/08/2012

Panne des sites Wikimedia du 6 août

L’ensemble des sites Wikimedia a connu une panne mondiale lundi dernier qui a commencé à environ 13h15 heure française. Les sites étaient de nouveau accessibles, à 15h18 (à l’exception du site pour les mobiles qui n’a été rétabli qu’à 16h35). La panne a donc duré un peu plus de 2 heures, sans accès à Wikipédia et aux autres projets Wikimedia (Wikimedia Commons, Wiktionnaire, Wikisource, etc.).

Les équipes techniques de la Wikimedia Foundation ont détecté une perte de connectivité réseau entre leurs deux centres de données qui hébergent les sites. La panne a été provoquée par une rupture accidentelle, provoquée par un tiers, d’un câble de fibre optique reliant ces deux centres. Ils sont tous deux situés du coté Est des États-Unis, l’un à Ashburn en Virgine et l’autre à Tampa en Floride (la fondation a elle ses bureaux à San Francisco). Le centre de Ashburn assure la majeure partie du trafic mais il doit communiquer avec celui de Tampa, le centre historique, pour tout ce qui concerne les services de backend (les bases de données par exemple). Aussi sont-ils reliés entre eux par deux liaisons distinctes en fibre optique afin d’assurer une redondance. La rupture d’un câble n’aurait donc pas du provoquer cette panne puisque le second câble est justement là pour éviter cela.

Quelques-uns des serveurs Wikimedia…
(Victor Grigas, CC by SA)

Pour assurer aussi cette redondance, la fondation s’était assuré auprès du fournisseur réseau qu’il fournisse deux systèmes indépendants et distincts de multiplexage en longueur d’onde (DWDM) afin que Wikipédia et les autres sites Wikimedia soient toujours accessibles. Chacun de ces DWDM est acheminé par diverses fibres en utilisant les deux entrées du point de présence (POP) du centre de Tampa, rendant le système capable de délivrer deux flux de 10 Gio/s différemment routés tant que le segment métropolitain et le segment longue distance de l’onde nº1 sont sur la même route.

Le fournisseur réseau a effectué le diagnostic initial du trafic Wikimedia et a trouvé l’origine du problème : il se situait dans une section d’un segment de fibre pliée au travers duquel passent les flux Wikimedia. Le dommage sur le câble de fibre optique s’est produit dans ce segment de fibre pliée entraînant la perte de service. Entre temps l’équipe technique de la fondation avait redirigé le trafic vers le centre de Tampa. Bien que les deux liaisons soient ensuite redevenues opérationnelles, le trafic n’a volontairement pas été redirigé vers Ashburn tant que les causes de cette panne de service n’étaient pas précisément connues.

L’enquête qui a suivi a montré que le segment d’accès métropolitain de l’onde nº1 était mal acheminé, du même côté que le segment longue distance de l’onde nº2. La combinaison de la coupure du câble et de ce routage incorrect ont entraîné la perte des deux connexions réseau entre les deux centres de données.

Depuis, la fondation a demandé au fournisseur de vérifier le cheminement du trafic pour s’assurer qu’un tel point unique de défaillance ne subsiste plus sur leur réseau (qu’en cas de défaillance en un point donné, la connexion reste assurée).

(Victor Grigas, CC by SA)

La fondation est également en train de répliquer et de migrer le reste de ses services backend à eqiad (site d’Ashburn), créant ainsi une redondance complète du service entre les deux centres de données. L’objectif est que cela soit achevé au dernier trimestre 2012.

Bien que cette panne se soit produite en plein mois d’août, les réactions en France et à l’étranger tant sur les réseaux sociaux que dans les médias ont montré à tel point Wikipédia était devenu un service usuel pour beaucoup. Wikipédia est consultée chaque mois par plus de 20 millions de visiteurs uniques en France et par près de 470 millions dans le monde.

Le rapport original de la panne (en anglais) se trouve sur wikitech.wikimedia.org/.

Aucun commentaire 08/08/2012

Projet Athena : le futur design de Wikipédia

Traduction de l’article « The Athena Project: being bold » de Brandon Harris, Senior Designer à la Wikimedia Foundation, publié le 6 août 2012 dans The Signpost (hebdomadaire d’information de la communauté Wikimedia)


Maquette d’Athena, telle que présentée à Wikimania 2012

En tant que Senior Designer de la Wikimedia Foundation, mon travail consiste notamment à animer le débat sur l’avenir de l’expérience utilisateur dans les projets Wikimédia. Cette tribune s’inscrit précisément dans cette optique, même si il ne s’agit pas d’une feuille de route stricte avec des étapes et des délais déterminés. Si vous voulez prendre connaissance de nos objectifs pour cette année, vous pouvez jeter un coup d’œil à nos objectifs 2012–2013.

Dans le cadre de la dernière Wikimania, j’ai donné une conférence intitulée Le projet Athena : Wikipédia en 2015 (transparents). Elle mettait en évidence plusieurs idées émises par la fondation concernant l’interface de publication et les modalités du travail encyclopédique. Nous nous attendons à ce que certains de ces changements soient bien accueillis. D’autres seront sans doute plus controversés.

Au cours de la session de questions, on m’a demandé si Athena devait être considéré comme un habillage (skin), un projet ou quelque chose d’autre. J’ai répondu : Vous devrez considérer Athena comme un coup de pied dans la fourmilière — car c’est exactement de cela qu’il s’agit : une remise en cause radicale et audacieuse de nos sacro-saints principes sur l’interface des projets Wikimedia.

Pourquoi nous devons évoluer

Maquette d’Athena, avec le système de notifications Echo, telle que présentée à Wikimania 2012

Je suis certain que beaucoup se demandent « Pourquoi devrions-nous changer ? En quoi est-ce important ? ». Pour dire les choses simplement : le logiciel est une barrière, et cet état de fait vous handicape.

Inutile de brandir des graphiques sur le déclin des contributeurs ou des chiffres sur la participation et le déséquilibre des genres − soit vous les avez vus et pensez qu’il faut faire quelque chose, soit vous les avez ignorés. Évitons ce débat et parlons de pourquoi ces changements profiteront à la communauté des contributeurs dans son ensemble, et pas simplement à un hypothétique groupe de nouveaux venus.

Davantage de contributeurs signifie moins de travail

Si nous pouvons attirer et conserver de nouveaux contributeurs, nous réduirons la charge de travail globale pour tout le monde. À quelle vitesse le travail en retard sera-t-il absorbé si nous avons ne serait-ce que 5000 nouveaux contributeurs ?

Un meilleur outil de travail signifie moins de travail

Maquette du système de discussion Flow, telle que présentée à Wikimania 2012

Au cours de l’année j’ai étudié les nombreuses façons de travailler sur Wikipédia, me suis entretenu avec des centaines de Wikipédiens. J’ai visionné des vidéos de contributeurs patrouillant sur les nouvelles pages, spectacle affreux qui m’a rempli de compassion envers ceux qui font ce travail. J’ai vu tant de personnes − qui pourraient être de bons Wikipédiens − abandonner le projet par frustration, simplement parce qu’utiliser Wikipédia est trop difficile.

Que conclure de tout cela ? Le support logiciel (ou son absence) est un frein. Il ne fait pas les choses correctement, il rend difficile des choses simples, et il cache des fonctionnalités et des informations qui devraient être au premier plan. Saviez-vous qu’il n’existe pas deux patrouilleurs qui travaillent de la même manière ? C’est parce que le logiciel est tellement mauvais que chacun doit arriver à se débrouiller avec pour travailler.

Nous devons repenser ces processus de travail. Nous devons faciliter la lecture, la contribution et la maintenance. De meilleurs outils permettent d’optimiser les processus, la façon de travailler, et donc d’avoir moins de travail.

Davantage de monde signifie de meilleurs articles

Accroître la taille de la communauté recentrera naturellement le point de vue, la voix de la communauté. Je ne crois pas que quiconque pense que nous devrions écrire depuis un ou deux points de vue seulement − nos articles de qualité le sont justement car ils ont eu de nombreux contributeurs. Attirer davantage de contributeurs créera une meilleure encyclopédie. Cela signifie que la voix de Wikipédia est plus forte de par sa diversité. La somme des parties est plus grande que le tout.

Les changements auxquels vous devez vous attendre

Regardons les choses en face : on croirait notre interface tout droit sortie de 2002. Or, nous serons bientôt en 2013. Nos contributeurs et lecteurs méritent une interface moderne avec des outils modernes. L’Éditeur visuel (Visual Editor) est un projet pour faire de cela une réalité. En voici d’autres :

Agora
Un projet pour créer un langage visuel unique pour tous les projets à venir de la Foundation. Cela est nécessaire car notre équipe de designers a beaucoup grandi, et nous avons tous notre propre style. Agora inclut une palette de couleurs commune, un jeu d’icônes commun, et des modèles de design communs, pour que nous puissions parler à l’unisson. Nous espérons que la communauté au sens large voudra utiliser cette voix commune.


Echo
Donnons aux projets un système moderne de notifications en temps réel. Echo est conçu pour coordonner les interactions entre tous les wikis et toutes les langues. Si quelqu’un vous laisse un message sur votre page de discussion sur Commons, vous en serez notifié sur la Wikipédia en anglais (ou tout autre projet sur lequel vous êtes en train de travailler). Un prototype d’Echo est d’ores et déjà disponible sur mediawiki.org.


Flow
Il s’agit d’un substitut aux pages de discussions utilisateur. Nos recherches montrent que la communication d’utilisateur à utilisateur est l’un des principaux obstacles à la participation pour les nouveaux contributeurs. Flow réglera de nombreuses questions : lorsque quelqu’un poste sur ma page de discussion, dois-je répondre sur la mienne ou la sienne ? Comment en seront-ils informés ?


L’habillage Athena
Cet habillage (skin) vise à laisser les gens faire ce qu’ils cherchent à faire. Il met en avant le contenu (ce que la plupart de nos utilisateurs veulent voir), et intègre le concept de « modes » distincts d’interaction. Athena sera le résultat final de nombreuses itérations d’un design centré sur l’utilisateur. Je dois préciser que les diverses maquettes existantes ne sont pas le produit final, mais visent à donner matière à l’imagination et à la discussion : nous voulons que ce soit un projet dynamique.


Mobile (tablettes comprises)
L’expérience utilisateur sur mobile s’améliore vraiment pour les lecteurs. En fait, c’est en travaillant sur l’ajout de fonctionnalités pour contribuer au site mobile que nombre de nos problèmes de conception sont apparus au grand jour. Le mobile nous force à réduire la complexité, ce dont nous avons terriblement besoin.


Global Profile
Des informations structurées sur vous, vos compétences et vos contributions vont élever votre « graphe d’intérêt ». Cela comprend repérer et partager vos compétences, ainsi que votre appartenance à des groupes et wikiprojets. Il se concentre sur vos contributions et comment vous vous êtes impliqués dans les projets.


Modes de travail
Si l’on prend un peu de recul, il devient clair que les gens interagissent avec Wikipédia dans l’un de ces « modes » : lecture, contribution/rédaction & maintenance/patrouille. Nous allons en faire des modes à part entière. Vous pouvez en voir les prémices avec notre nouvelle fonctionnalité de Page Curation, qui se concentre dans un premier temps, sur la patrouille dans les nouvelles pages mais deviendra à terme un éventail d’outils plus larges.

Wikipédia n’est pas et ne deviendra pas Facebook

Maquette d’Athena et de GlobalProfile, telle que présentée à Wikimania 2012

J’entends très souvent des gens exprimer leur crainte que Wikipédia devienne un « réseau social ». Pourtant, je ne vois pas cela comme une menace réelle : il y a une différence entre devenir un réseau social et avoir un logiciel moderne permettant la construction d’une encyclopédie.

Les Wikis sont des logiciels permettant la collaboration, ce qui en fait des logiciels sociaux (et même, des réseaux sociaux), par définition. Ce qui nous rend différent des autres réseaux sociaux, c’est notre but. Les sites comme Facebook et Twitter servent à créer des liens entre les gens, mais nous, nous voulons produire quelque chose : la meilleure encyclopédie du monde. Pour faire cela, nous avons besoin de relier des personnes aux tâches qui les intéressent.

Pour nous, des fonctionnalités telles qu’Echo, Flow, et Global Profile vont être utilisées afin de rendre le travail collaboratif plus facile et plus rapide. Elles le feront en reliant des graphes d’intérêt entre eux. Imaginez que le logiciel soit capable de détecter un {{Référence nécessaire}} sur l’article de la seconde guerre mondiale, et que les membres du projet Histoire Militaire en soient notifiés en temps réel à volonté, sans avoir besoin de consulter leur liste de suivi ?

En quoi cela sert-il la Cause

Imaginez un monde dans lequel chaque personne pourrait partager librement l’ensemble des connaissances humaines.

Quel puissant idéal. La Cause (et je lui mettrai toujours une majuscule) est l’important ici. Nous sommes ici pour instruire, pour ouvrir les esprits, pour rendre le monde meilleur. J’y crois tellement que je l’ai tatoué sur mon bras.

Indirectement, notre travail accomplira de grandes choses. En instruisant les personnes nous inaugurons le développement d’une nouvelle ère de la pensée. Nous nous adressons à des génies qui n’ont pas accès à l’instruction traditionnelle. Peut-être que l’un d’entre eux guérira le cancer, ou inventera le voyage à vitesse supraluminique, ou développera de nouvelles pensées philosophiques qui changeront le monde ? Nous pouvons changer le cours de l’histoire. Ici. Maintenant.

Nous le faisons en mettant nos contenus en avant. En les enrichissant, en les corrigeant, en les transformant. En en étant fier.

Pour cela, nous devons rendre le logiciel plus simple à utiliser. Nous devons faciliter la collaboration, la lecture, la contribution, la rédaction.

Ce qui veut dire que nous devons changer. Hélas, le changement est difficile et souvent douloureux. La bonne nouvelle, c’est que nos sortirons grandis de cette phase de cocon.

Il est temps de devenir un papillon.


  • Traduction par Alexander Doria, Jean-Frédéric, Léna et Cha Matou avec la contribution de AM 23, Auregann, Cantons-de-l’Est, Erdrokan, Goodshort, Lgd, et Warp3
  • Illustrations par Brandon Harris (Jorm) sous licence CC BY-SA 3.0

19 commentaires 23/01/2012

Des œuvres du domaine public de nouveau soumises au copyright aux États-Unis

Mercredi, alors que la protestation d’internet contre le projet de loi SOPA battait son plein, la Cour Suprême des États-Unis a rendu son verdict dans l’affaire Golan v. Holder, une décision lourde de conséquence faisant retomber des œuvres sous la protection des droits d’auteurs alors qu’elles étaient précédemment considérées comme étant dans le domaine public.

Rythme - Robert Delaunay

Rythme - 1932 - Robert Delaunay (1885 - 1941). Cette œuvre quitte le domaine public aux États-Unis.

 

Si depuis deux siècles la durée du droit d’auteur n’a cessé d’augmenter, passant de quelques années après la création de l’œuvre à ces 70 ans après la mort de l’auteur (qui font que viennent tout juste de passer dans le domaine public les œuvres des auteurs morts en 1941), une constante demeurait : une œuvre entrée dans le domaine public le restait. Elle devenait alors libre de réutilisation, d’adaptation, de diffusion. Elle entre dans le bien commun de l’humanité.
Cette décision de justice vient contredire ce point, faisant repasser sous copyright des milliers d’œuvres considérées comme étant dans le domaine public, au regret de nombreux artistes et défenseurs du domaine public.

Quelques explications :

 

La Convention de Berne et l’Uruguay Round Agreements Act

 

La Convention de Berne est un traité régissant la protection des œuvres au niveau international. En 1989, les États-Unis ont rejoint la Convention de Berne par l’entrée en vigueur du Berne Convention Implementation Act of 1988. Cette convention fixait l’entrée dans le domaine public à 50 ans minimum après la mort de l’auteur.

En 1994, suite au cycle d’Uruguay (Uruguay Round, dernier des cycles de négociations internationales ayant eu lieu dans le cadre de l’Accord général sur les tarifs douaniers et le commerce [GATT]), entrait en vigueur aux États-Unis le Uruguay Round Agreements Act (URAA). Cette loi apportait les dernières modifications au Copyright Act, nécessaires pour l’entrée au sein de la Convention de Berne, essentiellement sur la protection des œuvres originaires d’autres pays.

Dans le cadre de ce traité, par la section 514, le Congrès des États-Unis a accordé une protection par copyright aux œuvres étrangères qui relevaient de fait du domaine public, si ces œuvres étaient encore protégées par le droit d’auteur du pays d’origine lors de l’entrée en vigueur de l’URAA, le 1er janvier 1996.

C’est ainsi que des millions d’œuvres ont vu leur protection par copyright restaurée aux États-Unis.

 

Critiques et contestation

 

Cette décision a été vivement critiquée. En 2004, des membres de la société civile qui dépendaient de ce domaine public pour vivre − chefs d’orchestre, enseignants, interprètes, archivistes et distributeurs − l’ont contestée devant les cours, arguant que le Congrès avait outrepassé son pouvoir, et que sa décision allait à l’encontre de la Constitution des États-Unis.

L’affaire a fini par arriver devant la Cour Suprême des États-Unis, avec le soutien de nombreuses parties, notamment la Wikimedia Foundation, hébergeur des projets Wikimédia.

Mercredi, la Cour a rendu son verdict et a confirmé la décision du Congrès, affirmant que celle-ci ne violait ni la Copyright Clause, ni le Premier Amendement.

 

La_Place_Saint-Michel, Eugène Galien-Laloue

La Place Saint Michel - 1941 - Eugène Galien-Laloue (1854–1941). Cette œuvre quitte le domaine public aux États-Unis.

Des implications morales et économiques

 

Au fil des ans, la durée de protection par le droit d’auteur n’a cessé d’augmenter. Aux États-Unis, le Congrès l’a étendue à 19 reprises en deux siècles, ce qui n’est pas l’apanage des États-Unis : l’Union Européenne et les pays qui en font partie ont fait passer diverses lois et directives aux mêmes visées d’allongement de la durée de protection des œuvres.
Chacune de ces lois a fait reculer le domaine public, mais une constante restait : ce qui entre dans le domaine public y reste définitivement. L’URAA est allée plus loin. Pour la première fois de l’histoire des États-Unis, le domaine public a été diminué : des œuvres en ont été arrachées.

Cette décision place également les réutilisateurs d’œuvres dans une situation délicate : si l’exploitation d’œuvres du domaine public n’est soumise à aucune restriction, un domaine public changeant est synonyme d’insécurité juridique. Ainsi, si Lawrence Golan, chef d’orchestre et principal requérant de l’affaire pouvait librement interpréter Pierre et le Loup de Prokofiev, l’URAA est venue changer la donne.

 

Durée de protection et influence sur les projets Wikimedia

 

Avec l’URAA, les États-Unis ont protégé des œuvres étrangères « pour la durée de protection restante dont l’œuvre aurait bénéficié si elle n’était jamais passée dans le domaine public aux États-Unis ». Or, la loi des États-Unis donne aux œuvres publiées entre 1924 et 1978 une protection de 95 ans après la date de publication. Cela provoque des situations absurdes : les États-Unis ne reconnaissant pas la « règle du terme le plus court », ces œuvres ont beau entrer dans le domaine public dans leur pays d’origine, elles restent protégées aux États-Unis.

Or, les projets Wikimedia doivent être en conformité avec la loi des États-Unis, où ils sont hébergés. La communauté des projets, qui a au fil des années développé une connaissance pointue en matière de droit d’auteur, discute de la marche à suivre ; et s’apprête donc à supprimer des milliers d’œuvres pourtant passées dans le domaine public dans leur pays d’origine des différents projets Wikimédia.

Les exemples sont légion. Gandhi étant mort en 1948, ses écrits sont dans le domaine public depuis 2008 (durée de protection de 60 ans après la mort de l’auteur en Inde) ; mais ceux publiés après 1923 restent protégés aux États-Unis, et ne peuvent aller enrichir Wikisource. Il en va de même des dernières œuvres de Gaston Leroux ou de Rudyard Kipling, de Freud ou de Federico Garcia Lorca.

Les projets Wikimedia ont pour vocation de donner accès à l’ensemble des connaissances humaines. Ils constituent certains des plus importants viviers du domaine public : la médiathèque Wikimedia Commons en héberge plus d’un million d’œuvres, Wikisource est largement constituée d’œuvres littéraires sous ce régime, le Wiktionnaire s’est abondamment bâti sur des dictionnaires du domaine public…

Le 26 janvier prochain, Wikimédia France aura à cœur de célébrer la journée du domaine public. Le cœur à la fois en liesse d’accueillir ces nouvelles œuvres, et serré de constater les assauts subis contre cette richesse commune.