Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : peupleLà, SaSha_01, lerouge, Kalupa, lenod, michel, KoS, michel, goofy, HanX, Asta, lamessenJulius22

Mon projet m’a appris à grandir

Runa Bhattacharjee

Depuis 10 ans, Runa Bhattacharjee a traduit et travaillé à la localisation(1) de nombreux projets open source — des interfaces de bureau aux outils de systèmes d’exploitation en passant par beaucoup de choses entre les deux. Elle croit fermement que les dépôts de codes en amont sont les meilleurs endroits pour soumettre toutes les modifications possibles. Elle gère également un portefeuille professionnel spécialisé dans la localisation chez RedHat. Runa traduit et maintient des traductions en Bengali (version indienne) mais est toujours heureuse d’aider quiconque débute dans la localisation.

Introduction

Carburer tard dans la nuit est l’une des formes de rébellion préférée des jeunes partout dans le monde. Que ce soit pour lire un livre avec une lampe de poche sous les couvertures, regarder les rediffusions TV ou (entre autres choses) traîner sur un canal IRC et s’acharner sur un problème agaçant dans son projet open source favori.

Comment tout a commencé

Voici comment tout a commencé pour moi. Permettez-moi d’abord d’écrire quelques lignes sur ma personne. Lorsque j’ai été présentée au groupe d’utilisateurs de Linux de ma ville, je partageais ma vie entre des emplois et mes études de master. Très vite, j’étais devenue contributrice sur quelques projets de localisation et j’avais commencé à traduire des interfaces de bureau (principalement). Nous utilisions des éditeurs de texte personnalisés avec des systèmes intégrés pour l’écriture et les polices. Les moteurs de rendu n’étaient pas assez matures pour afficher le scénario sans erreur sur les interfaces. Mais, malgré tout, nous continuions à traduire. Je me concentrais sur la méthode de travail que j’avais créée pour mon usage. Je récupérais le contenu à traduire des personnes qui savaient comment les choses fonctionnaient, je le traduisais du mieux que je pouvais, j’ajoutais des commentaires pour aider les réviseurs à comprendre comment j’avais appréhendé le texte, je renseignais les informations requises pour les copyrights et les crédits, puis je renvoyais tout ça aux coordinateurs.

Comment je faisais

C’était avant tout une manière simple de faire les choses. Mais, surtout, c’était ma manière à moi de les faire. Je prenais le temps de planifier mon travail sur les traductions. Celles-ci étaient ensuite révisées avant de m’être retournées pour modification. De nouveau, je planifiais quand je pourrais les reprendre en fonction de mon temps libre disponible entre les études et le travail. Lorsque je me mettais finalement au boulot, je m’asseyais pour neuf à dix heures d’un coup, en général jusqu’à l’heure où blanchit la campagne, ressentant alors un grand sentiment d’accomplissement, jusqu’à la fois suivante.

Ce qui comptait

Ce que je ne savais pas, c’est que je jouais un rôle crucial sur un plan plus global. À savoir, la planification des releases(2). Donc, quand j’achevais mes modestes contributions et les envoyais aux autres, je ne prenais pas en compte leur possible inutilité du fait qu’elles arrivaient trop tard pour la version en cours et trop tôt pour la suivante (qui inclurait forcément de nombreux changements qui obligeraient à se remettre au travail). Au-delà de ça, je n’avais aucune idée de l’importance que ça prenait dans le processus de release : intégration, création de paquetages, tests de l’interface, suivi et résolution des bogues.

Comment cela m’a fait grandir

Tout cela a changé radicalement quand je me suis tournée vers un rôle plus professionnel. Subitement, je faisais la même chose mais d’une manière plus structurée. J’ai appris que faire cavalier seul comme j’en avais pris l’habitude n’était pas adapté quand on devait jongler avec deux ou trois versions planifiées. Il fallait être méticuleusement synchronisé avec les feuilles de route des projets. En travaillant sur une traduction d’interface de bureau, je devais aussi vérifier que le calendrier de traduction concordait avec celui du projet principal.

Les travaux devaient idéalement commencer immédiatement après le gel de tous les messages d’origine de l’interface. Les traducteurs pouvaient alors travailler librement jusqu’à l’échéance de la période de traduction, après quoi ils pouvaient marquer la traduction comme stable dans le dépôt principal et, finalement, les paquetages pouvaient être générés. De plus, quelques distributions de systèmes d’exploitation se synchronisaient sur ce calendrier. Les traducteurs avaient donc la responsabilité supplémentaire de s’assurer que les pré-versions des systèmes d’exploitation embarquant ce bureau seraient un minimum testées afin de s’assurer que les traductions de l’interface avaient du sens et ne contenaient pas d’erreur.

Ce que j’aurais dû savoir

La transition ne fut pas aisée. Je fus soudain inondée par un flot d’informations que je devais gérer et par des tâches supplémentaires que je devais réaliser. Ce qui était au départ un passe-temps et plus important encore un anti-stress est devenu tout à coup une affaire sérieuse. En y repensant, je peux dire que cela m’a probablement aidée à comprendre le processus dans son intégralité étant donné que j’ai dû tout apprendre depuis le début. Ainsi armée de cette connaissance, je peux analyser des situations avec une meilleure compréhension de toutes leurs dimensions. Au moment où j’ai commencé à travailler sur les projets open source qui m’intéressaient, il y avait beaucoup moins de professionnels qui travaillaient à plein temps dans ce domaine. La plupart des contributeurs bénévoles travaillaient ailleurs la journée et voyaient ces projets comme un moyen d’alimenter les idées créatives qui s’étiolaient dans leurs tâches quotidiennes. Donc, beaucoup de nouveaux arrivants n’étaient jamais guidés vers une manière plus professionnelle d’organiser leurs projets. Ils ont grandi pour devenir merveilleusement doués dans ce qu’ils faisaient et ont finalement compris comment ils aimeraient équilibrer leur travail avec le reste de leurs activités.

Conclusion

Aujourd’hui, j’encadre les nouveaux arrivants et l’une des premières choses que je leur fais comprendre est comment et dans quelle partie du projet leur travail aura un impact. Élaborer un modèle de travail personnel est essentiel car cela permet de se construire un environnement où il est agréable de travailler. Cependant, avoir conscience de la structure qui est affectée par le travail inculque la discipline nécessaire pour pouvoir tenir bon face aux caprices.

(1) La localisation englobe tout le processus d’adaptation d’un produit logiciel ou documentaire à une région donnée. Cela comprend la traduction dans la langue de la région mais aussi l’adaptation aux normes, à la culture et aux besoins spécifiques de cette région du monde.

(2) Il s’agit de la publication d’un logiciel, sa mise à la disposition du public.

En novembre dernier, Richard Stallman faisait paraître dans le magazine Wired un article important sur l’épineuse et dangereuse question des brevets logiciels (ou plutôt « brevets sur des idées informatiques » comme nous le verrons ci-après).

Un article que nous nous sommes empressés de traduire via notre circuit, désormais classique, compte Twitter + Framapad, et qui a été relu et corrigé par la liste « trad-gnu » de l’April.

Protéger le secteur du logiciel des brevets

Giving the Software Field Protection from Patents

Richard Stallman – version du 02 février 2013 – Gnu.org (CC BY-ND)
(Traduction Framalang : satbadkd, Thérèse, DarthMickey, geecko, Marc, igor, EEva, greygjhart)

Une première version de cet article a été publiée sur Wired en novembre 2012.

Les brevets menacent chaque concepteur de logiciel, et les guerres de brevet que nous avons longtemps craintes ont éclaté. Les développeurs et les utilisateurs – soit, dans notre société, la plupart des gens – ont besoin de logiciels libres de tout brevet.

Les brevets qui nous menacent sont souvent appelés « brevets logiciels », mais ce terme est trompeur. Ces brevets ne concernent aucun programme en particulier. En fait, chaque brevet décrit une idée applicable en pratique, et affirme que quiconque utilise cette idée peut être poursuivi en justice. Il est donc plus clair de les appeler « brevets sur des idées informatiques », ou « brevets sur des algorithmes ».

Le système de brevets américain ne différencie pas les « brevets logiciels » des autres. Seuls les développeurs font la distinction entre les brevets qui nous menacent – ceux qui concernent des idées pouvant être implémentées dans des logiciels – et les autres. Par exemple : si l’idée brevetée est la forme d’une structure physique ou une réaction chimique, aucun programme ne peut implémenter cette idée ; ce brevet ne menace pas le secteur du logiciel. Si par contre l’idée qui est brevetée est un algorithme, alors le canon de ce brevet est braqué sur les développeurs et les utilisateurs.

Cela ne veut pas dire que les brevets couvrant des algorithmes concernent seulement les logiciels. Ces idées peuvent être aussi implémentées dans du matériel… et beaucoup d’entre elles l’ont été. Chaque brevet couvre typiquement les implémentations matérielles et logicielles de l’idée.

Le problème particulier du logiciel

Toujours est-il que c’est dans le domaine du logiciel que les brevets sur des algorithmes posent un problème particulier. Il est facile de combiner des milliers d’idées dans un seul programme. Si 10% de ces idées sont brevetées, cela signifie que des centaines de brevets le menacent.

Quand Dan Ravicher, de la Public Patent Foundation (Fondation publique des brevets) a étudié en 2004 un programme de taille importante (Linux, qui est le noyau du système d’exploitation GNU/Linux), il a trouvé 283 brevets américains qui semblaient couvrir des algorithmes implémentés dans son code source. Cette année-là, on estimait la part de Linux dans le système GNU/Linux complet à 0,25%. En multipliant 300 par 400, on peut estimer que le nombre de brevets qui menacent le système dans son ensemble est de l’ordre de 100 000.

Si la moitié de ces brevets était supprimée pour cause de « mauvaise qualité » – c’est-à-dire pour cause de ratés du système de brevets – cela ne changerait pas grand chose. Que ce soit 100 000 ou 50 000 brevets, la catastrophe est la même. C’est pourquoi c’est une erreur de limiter nos critiques des brevets logiciels aux seuls patent trolls ou aux brevets de « mauvaise qualité ». En ce sens Apple, qui n’est pas un « troll » selon la définition habituelle, est actuellement l’entreprise la plus dangereuse quand elle se sert de ses brevets pour attaquer les autres. Je ne sais pas si les brevets d’Apple sont de « bonne qualité », mais plus la « qualité » du brevet est élevée, plus la menace est grande.

Nous devons corriger l’ensemble du problème, pas seulement une partie.

Pour corriger le problème sur le plan législatif, on suggère habituellement de changer les critères d’octroi des brevets – par exemple, d’interdire la délivrance de brevets sur les pratiques algorithmiques et les systèmes nécessaires à leur mise en œuvre. Mais cette approche a deux inconvénients.

Premièrement, les avocats reformulent les brevets de manière astucieuse pour qu’ils correspondent à toute règle applicable ; ils transforment toute tentative de limiter un brevet sur le fond en une simple exigence de forme. Par exemple, de nombreux brevets américains sur des algorithmes décrivent un système qui comprend une unité de traitement arithmétique, un séquenceur d’instruction, une mémoire ainsi que des contrôles pour mener à bien un calcul précis. C’est une manière assez particulière de décrire un programme tournant sur un ordinateur pour effectuer un certain calcul ; elle a été élaborée pour que la demande de brevet se conforme aux critères que, pendant quelques temps, l’on a cru être ceux du système américain de brevets.

Deuxièmement, les États-Unis ont déjà plusieurs milliers de brevets sur des algorithmes, et changer les critères pour empêcher d’en créer d’autres ne permettrait pas de se débarrasser de ceux qui existent. Il faudrait attendre pratiquement 20 ans avant que le problème ne soit entièrement résolu du fait de l’expiration des brevets. Et abolir les brevets existants par la loi est probablement anticonstitutionnel (de manière assez perverse, la Cour suprême a insisté pour que le Congrès puisse étendre les privilèges privés au détriment des droits du public mais ne puisse pas aller dans l’autre direction).

Une approche différente : limiter l’effet des brevets, pas la brevetabilité

Ma proposition est de changer l‘effet des brevets. Il faut inscrire dans la loi que développer, distribuer ou exécuter un programme sur des systèmes informatiques polyvalents ne constitue pas une violation de brevet. Cette approche a plusieurs avantages :

• elle n’impose pas de classer les brevets selon qu’ils sont logiciels ou non ;
• elle apporte aux développeurs ainsi qu’aux utilisateurs une protection contre les brevets sur des algorithmes, existants ou futurs ;
• les avocats spécialistes des brevets ne peuvent plus trouver d’échappatoire en changeant la formulation de leurs demandes.

Cette approche n’invalide pas entièrement les brevets existants sur des algorithmes, parce qu’ils continueront à s’appliquer aux implémentations utilisant du matériel dédié. C’est un avantage dans le sens que cela supprime un argument mettant en question la validité de cette proposition du point de vue législatif. Les États-Unis ont légiféré il y a quelques années afin d’immuniser les chirurgiens contre les procès en contrefaçon de brevet, de sorte que même si des procédures chirurgicales sont brevetées, les chirurgiens sont protégés. Cela fournit un précédent pour ce type de solution.

Les développeurs et les utilisateurs de logiciels ont besoin de protection contre les brevets. Cette proposition est la seule solution législative qui apporte une protection totale à tous. Nous pourrions ensuite retourner à notre monde de concurrence ou de coopération… sans craindre qu’un inconnu ne vienne balayer notre travail.

Voir également : Une réforme des brevets n’est pas suffisante

Crédit photo : OpenSourceWay (Creative Commons By-Sa)

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : Nyx, lamessen, Sphinx, peupleLà, lerouge, Sky, Julius22, Astalaseven, Alpha, HgO, michel, Sputnik, goofy, HanX, KoS

Ne vous inquiétez pas, faites confiance

Shaun McCance

Shaun McCance est impliqué dans la documentation de GNOME depuis 2003 en tant que rédacteur, chef de la communauté et développeur d’outils. Il a passé la plupart de ce temps à se demander comment inciter davantage de personnes à écrire une documentation de meilleure qualité, avec un certain succès à long terme. Il propose son expérience de la documentation communautaire à travers sa société de conseil, Syllogist.

Alors que je m’apprêtais à écrire cet article, il s’est passé quelque chose d’énorme : GNOME 3 est sorti. C’était la première version majeure de GNOME depuis neuf ans. Tout était différent et toute la documentation existante devait être réécrite. Au même moment, nous changions notre façon de l’écrire. Nous avions jeté nos vieux manuels et étions repartis sur une nouvelle base, avec un système d’aide dynamique par sujet, en utilisant Mallard.

Quelques semaines avant la sortie, une partie d’entre nous s’est réunie pour élaborer la documentation. Nous passions nos journées à travailler, à planifier, à écrire et à réviser. Nous avons écrit des centaines de pages malgré les changements incessants liés aux ultimes modifications du logiciel. Nous avions des contributeurs en ligne qui proposaient de nouvelles pages et corrigeaient ce qui existait déjà. Je n’avais jamais vu notre équipe de documentation aussi productive.

À quoi avons-nous finalement abouti ? Beaucoup de facteurs sont entrés en jeu, et je pourrais écrire un livre entier sur les nuances de la documentation open source. Mais ce que j’ai fait de plus important a été de m’effacer et de laisser les autres faire le travail. J’ai appris à déléguer ; et à déléguer dans les règles de l’art.

Revenons huit ans en arrière. J’ai commencé à m’impliquer dans la documentation de GNOME en 2003. Je n’avais pas vraiment d’expérience en tant que rédacteur technique à cette époque. Mon emploi m’amenait à travailler sur des outils de publication et j’ai commencé à travailler sur les outils et sur le visualiseur d’aide utilisés par la documentation de GNOME. Peu de temps après, je me suis retrouvé à la rédaction de la documentation.

En ce temps-là, la majeure partie de notre documentation était entre les mains de rédacteurs techniques professionnels de chez Sun. Ils s’occupaient d’un manuel, l’écrivaient, le relisaient et l’envoyaient sur notre dépôt CVS. Après quoi nous pouvions tous le regarder, y apprendre quelque chose et lui apporter des corrections. Mais il n’existait pas d’efforts concertés pour impliquer les gens dans le processus d’écriture.

Ce n’est pas que les rédacteurs de Sun essayaient de protéger ou de cacher quoi que ce soit. Ils étaient avant tout rédacteurs techniques. Ils connaissaient leur travail et le faisaient bien. D’autres personnes auraient pu les remplacer pour d’autres manuels mais ils auraient écrit leurs travaux d’une manière habituelle. Utiliser un groupe de collaborateurs novices, aussi enthousiastes soient-ils, pour chaque page, revient à perdre un temps inimaginable sur des détails. C’est tout simplement contre-productif.

De manière inévitable, le vent a tourné chez Sun et leurs rédacteurs techniques ont été affectés à d’autres projets. Cela nous a laissés sans nos rédacteurs les plus prolifiques, ceux qui disposaient des meilleures connaissances. Pire que cela, nous étions laissés sans communauté et personne n’était là pour ramasser les morceaux.

Il y a des idées et des processus standards dans le monde de l’entreprise. J’ai travaillé dans le monde de l’entreprise. Je ne crois pas que quiconque remette ces idées en cause. Les gens font leur travail. Ils choisissent des missions et les terminent. Ils demandent aux autres de faire une relecture, mais ils n’ouvrent pas leur travail aux nouveaux venus et aux rédacteurs moins expérimentés. Les meilleurs rédacteurs écriront sans doute le plus.

Ces idées sont d’une plate évidence, mais elles échouent lamentablement dans un projet communautaire. Vous ne développerez jamais une communauté de contributeurs si vous faites tout vous-même. Dans un projet de logiciel, vous pouvez avoir des contributeurs compétents et suffisamment impliqués pour contribuer régulièrement. Dans la documentation, cela n’arrive presque jamais.

La plupart des gens qui s’essayent à la documentation ne le font pas parce qu’ils veulent être rédacteur technique ni même parce qu’ils aiment écrire. Ils le font parce qu’ils veulent contribuer. Et la documentation est la seule manière qu’ils trouvent accessible. Ils ne savent pas coder. Ils ne sont artistiquement pas doués. Ils ne maîtrisent pas assez une autre langue pour faire de la traduction. Mais ils savent écrire.

C’est là que les rédacteurs professionnels lèvent les yeux au ciel. Le fait que vous soyez instruit ne signifie pas que vous puissiez écrire une bonne documentation pour l’utilisateur. Il ne s’agit pas simplement de poser des mots sur le papier. Vous devez comprendre vos utilisateurs, ce qu’ils savent, ce qu’ils veulent, les endroits où ils cherchent. Vous avez besoin de savoir comment présenter l’information de façon compréhensible et savoir où la mettre pour qu’ils puissent la trouver.

Les rédacteurs techniques vous diront que la rédaction technique n’est pas à la portée de tous. Ils ont raison. Et c’est exactement pourquoi la chose la plus importante que les rédacteurs professionnels puissent faire pour la communauté est de ne pas écrire.

La clé pour construire une communauté efficace autour de la documentation, c’est de laisser les autres prendre les décisions, faire le travail et en récolter eux-mêmes les fruits. Il ne suffit pas de leur donner du travail en continu. La seule solution pour qu’ils s’intéressent suffisamment et s’accrochent au projet, c’est qu’ils se sentent investis personnellement. Le sentiment de faire partie intégrante d’un projet est une source puissante de motivation.

Mais si vous ne travaillez qu’avec des rédacteurs débutants et que vous leur donnez tout le travail à faire, comment pouvez-vous avoir l’assurance que la documentation ainsi créée sera de qualité ? Une participation massive mais incontrôlée n’aboutit pas à de bons résultats. Le rôle d’un rédacteur expérimenté au sein de la communauté est d’être un professeur et un mentor. Vous devez leur apprendre comment rédiger.

Commencez par impliquer les gens tôt dans le planning. Planifiez toujours du bas vers le haut. La planification du haut vers le bas n’incite pas à la collaboration. Il est difficile d’impliquer les gens dans la réalisation d’une vue d’ensemble de haut niveau si tous n’ont pas la même perception de cette vue d’ensemble. Mais les gens sont capables de travailler sur des segments. Ils peuvent réfléchir à des sujets particuliers d’écriture, à des tâches que les gens réalisent, à des questions que les gens peuvent se poser. Ils peuvent regarder les forums de discussion et les listes de diffusion afin de voir ce que les utilisateurs demandent.

Écrivez vous-même quelques pages. Cela donne un exemple à imiter. Il faut ensuite répartir tout le reste du travail. Laissez à d’autres la responsabilité de rubriques ou de chapitres entiers. Précisez-leur clairement quelles informations ils doivent fournir, mais laissez-les écrire. C’est en forgeant qu’on devient forgeron.

Soyez constamment disponible pour les aider ou répondre aux questions. Au moins la moitié de mon temps consacré à la documentation est passée à répondre à des questions afin que les autres puissent effectuer leur travail. Quand des brouillons sont soumis, relisez-les et discutez des critiques et des corrections avec leurs auteurs. Ne vous contentez pas de corriger vous-même.

Cela vous laisse tout de même le gros du travail à faire. Les gens complètent les pièces du puzzle, mais c’est toujours vous qui les assemblez. Au fur et à mesure qu’ils acquièrent de l’expérience, les gens s’occuperont de pièces de plus en plus grandes. Encouragez-les à s’impliquer davantage. Donnez-leur davantage de travail. Faites en sorte qu’ils vous aident à aider plus de rédacteurs. La communauté fonctionnera toute seule.

Huit ans plus tard, GNOME a réussi à créer une équipe de documentation qui se gère elle-même, résout les problèmes, prend des décisions, produit une bonne documentation et accueille constamment de nouveaux contributeurs. N’importe qui peut la rejoindre et y jouer un rôle. Telle est la clé du succès pour une communauté open source.

Et si nous faisions en sorte qu’Internet nous permette de payer en toute liberté ?

Que nous sortions du double carcan de la somme fixe et unique pour tout le monde et du poids moral négatif induit par l’usage (de la copie) sans rétribution ?

Si c’est possible de le copier, alors vous le trouverez gratuitement sur Internet. Ceci n’est pas un slogan publicitaire mais une constatation. Nous vivons dans un monde où le contenu s’est affranchi de son support matériel et des limites inhérentes. Dans ce monde, les barrières de l’accès à la connaissance sont tombées. Tout le monde peut partager une réflexion philosophique, une analyse d’une œuvre de Monet. Ou une vidéo de chatons et le dernier clip d’un chanteur à la mode.

Au fond, c’est merveilleux. Cela devrait nous émerveiller tous les matins. Aucun auteur de Science-Fiction n’avait osé en rêver. C’est génial ! Sauf si on gagne sa vie à vendre du contenu sur un support physique. Auquel cas, la perspective est un peu inquiétante.

Alors que le support physique n’était jamais qu’un moyen comme un autre de diffuser de l’information, les vendeurs ont tout d’abord tenté de lier irrémédiablement le contenu avec son contenant. Voire de distribuer le contenu de manière virtuelle mais en ajoutant artificiellement les contraintes du matériel, quand bien même ce matériel n’existait plus.

Après cet échec prévisible, les industries du contenu cherchèrent d’autres méthodes de rentabilisation. Après tout, il existe des journaux gratuits, des chaînes de télévision gratuites. Le dénominateur commun étant le financement par l’ajout de publicité.

Outre les questions qu’elle pose, la publicité a le problème de dégrader l’expérience du contenu. Apprécierez-vous d’être interrompu au milieu d’une fugue de Bach par un slogan ventant des croquettes pour chat ? Pire : tout comme il est possible de tout trouver gratuitement, il est également possible de bloquer la publicité.

Un monde virtuel qui ne vivrait que de la publicité serait fortement limité. En effet, la publicité devrait forcément faire référence aux produits du monde réel, celui au grand plafond bleu, produits limités en quantité par le monde réel lui-même. À l’heure où l’on parle de décroissance, on ne peut imaginer augmenter à l’infini les publicités.

Lorsqu’il n’est physiquement plus possible de forcer quelqu’un à vous donner de l’argent, la seule solution est de faire appel à son sens moral. De le convaincre. Deux choix s’offrent au vendeur : la voie positive « C’est bien de donner » et celle négative « Ne pas donner, c’est mal ! ».

Devinez laquelle a été choisie ? Nous vivons dans un monde merveilleux où le partage est possible instantanément à travers la planète et nous avons réussi à transformer cette utopie futuriste, cette réalisation extraordinaire en un péché moral : « Ne pas payer, c’est mal ! », « Ne pas payer est illégal », « Si vous ne payez pas, vous serez poursuivi en justice », « Si vous ne payez pas, vos artistes préférés vont mourir de faim ».

Mais toute cette rhétorique négative se fonde sur une série de postulats.

1. Un artiste doit être payé pour ses réalisations.

FAUX. Cette vision se base sur une séparation nette entre les artistes d’un côté et les consommateurs de l’autre. Internet a démontré que nous sommes tous, à différents degrés, des artistes. Comme le dit Rick Falkvinge, un artiste c’est quelqu’un qui produit de l’art. À partir du moment où cette personne cherche à en tirer du profit, elle devient un entrepreneur. Et, à ce titre, c’est à elle de mettre en place un business model. On pourrait également appliquer cet argument au logiciel libre et dire que tout codeur doit être payé pour ses contributions. Pourtant, le logiciel libre prouve que c’est loin d’être le cas.

2. Tout travail mérite salaire.

FAUX. Le client paie généralement le produit d’un travail, pas le travail lui-même. Creuser un trou dans votre jardin est un travail dur. Le reboucher l’est tout autant. Pourtant, personne ne vous paiera pour cela. Le travail n’est donc rémunéré que lorsque quelqu’un estime intéressant de le faire, quelle que soit sa raison.

3. Il faut payer avant de consommer.

FAUX. Imaginez que vous puissiez entrer dans un restaurant, manger et que le prix soit laissé à votre appréciation. Si vous avez aimé, vous payez beaucoup. Sinon, vous payez moins ou juste assez pour couvrir le prix des produits. Utopiques ? C’est pourtant dans ce monde que nous vivons de plus en plus. La musique en est l’exemple le plus marquant : il n’est pas rare de rencontrer des audiophiles qui achètent un album qu’ils ont téléchargé depuis six mois sous prétexte : « C’est vraiment un bon CD, je l’adore, je l’écoute en boucle. Du coup, je l’achète pour soutenir l’artiste. ».

4. Il est obligatoire de payer.

FAUX. Contrairement à l’exemple du restaurant, la reproduction de l’information à un coût tout à fait nul. Il n’y a donc aucune raison particulière de payer pour consommer du contenu. Nous écoutons de la musique chez des amis, nous lisons un livre trouvé sur un banc, nous entendons un voisin expliquer le sens de la vie par dessus sa haie : nous consommons en permanence du contenu sans le payer. Pire, un même contenu peut être consommé gratuitement à titre promotionnel puis rendu payant par après. Les distributeurs de contenu sont donc dans la position schizophrénique de devoir diffuser le contenu autant que possible tout en empêchant… qu’il soit trop diffusé.

Pourtant, cet argument de l’obligation de payer est tellement tenace qu’il en est devenu « Si c’est gratuit, c’est nul » jusqu’à un extrème « Si c’est cher, c’est bien » exploité par les grandes marques.

5. Chacun doit payer le même prix pour accéder au même contenu.

FAUX. De nouveau, aucune loi naturelle n’oblige à ce que chacun paie la même chose pour le même service. Nous sommes pourtant habitués à ce genre de choses : les militaires, les jeunes et les pensionnés ont des réductions dans les transports en commun. Les journalistes et les professeurs ont des entrées gratuites dans certains musées.

Quand on y pense, payer le même prix est foncièrement injuste. Une personne qui adore un contenu paiera autant que quelqu’un qui n’a agit que par réflexe suite à une publicité et ne le consommera qu’une ou deux fois.

Si nous arrivons à remettre en question ces postulats, alors peut-être arriverons-nous à sortir de cette pernicieuse morale négative. Peut-être pourrons-nous enfin être fiers de cet accomplissement humain : le partage du savoir à tous les niveaux.

Et des solutions commencent à se mettre en place. Ma préférée étant Flattr qui, justement, permet de donner une petite somme d’argent aux contenus que l’on apprécie et ce parfois automatiquement. Avec la subtilité que la somme donnée par mois est fixe, quelque soit la quantité de contenu consommé. Framasoft est sur Flattr et je milite activement pour qu’on puisse Flattrer les billets individuels ! Certes, Flattr est centralisé mais tout service gérant des transferts d’argent le restera tant que Bitcoin ne sera pas généralisé !

Les artistes eux-mêmes commencent à bouger. Après l’expérience de Radiohead en 2007, c’est au tour d’Amanda Palmer de voir dans le « Payez ce que vous voulez » l’avenir des artistes. Et pour ceux qui souhaitent vraiment s’investir dans la réussite d’un artiste, les plateformes de « crowdsourcing » comme Kickstarter sont en train de contourner de plus en plus le rôle des gros producteurs, de décentraliser les industries du contenu.

À ce genre de discours, il est courant d’objecter que, si ils ont le choix, les consommateurs vont éviter de payer. Pourtant, le choix est déjà là. La majorité des consommateurs choisit de payer pour des raisons morales le plus souvent négatives. Il existe également des domaines où le fait de donner volontairement est considéré comme normal : c’est le principe du pourboire. Je vous propose de tester le web payant pour vous faire votre propre idée.

Transformer Internet en une économie du « Payez ce que vous voulez » ne serait donc que transformer les raisons morales afin de les rendre positives. Et, à ce titre, rendre complètement obsolètes tous les fichages, les surveillances et autre HADOPI. Un retour à la liberté.

Flattr ne différencie pas les consommateurs des producteurs de contenu. Nous sommes tous des producteurs de contenu, nous somme tous des artistes. Et nous sommes tous également avides de nouveautés, d’art et d’idées. Finalement, n’est-ce pas un des fondement de l’égalité ?

Contrairement à un achat, où je me sens toujours extorqué de mon argent durement gagné, faire un micro don me réchauffe le cœur, me donne le sentiment d’être, à mon échelle, un contributeur. Un sentiment de fraternité.

Liberté, égalité, fraternité. C’est peut-être la définition du web et de l’art de demain.

Crédit photo : Flattr (Creative Commons By)

Nous vous proposons ci-dessous la traduction d’un récent article de Richard Stallman sur l’usage des licences Creative Commons dans l’éducation.

Et c’est bien le pluriel de ces licences Creative Commons qui pose problème. Le choix majoritaire de la fameuse clause non commerciale NC serait contre-productive voire toxique dans le champ considéré ici.

« J’exhorte Creative Commons à prendre position et à déclarer que les œuvres censées être utilisés en pratique, y compris la documentation pédagogique et les œuvres de référence soient, comme les logiciels, diffusés uniquement sous des licences libres… Les licences CC BY-NC et CC BY-NC-SA, telles qu’elles existent aujourd’hui, doivent être évitées. »

L’occasion également pour Stallman de rappeler que cohabitent au sein des Creative Commons des licences libres et d’autres non libres, et que ces dernières sont tout à fait acceptables voire légitimes lorsqu’il s’agit d’œuvres artistiques ou d’opinion (ce qui n’est donc pas le cas pour l’éducation).

Un article à confronter avec celui de Calimaq sur Owni : Le non commercial, avenir de la culture libre.

L’éducation en ligne utilise une licence Creative Commons défectueuse

On-line education is using a flawed Creative Commons license

Richard Stallman – version du 14 janvier 2013 – Site personnel
(Traduction du 28 janvier 2013 : albahtaar, Vrinse, goofy, MdM, aKa, KoS, FirePowi, Thérèse, Penguin, revue et corrigée par Richard Stallman)

Des universités de premier plan utilisent une licence non-libre pour leurs ressources d’enseignement numérique. C’est déjà une mauvaise chose en soi, mais pire encore, la licence utilisée a un sérieux problème intrinsèque.

Lorsqu’une œuvre doit servir à effectuer une tâche pratique, il faut que les utilisateurs aient le contrôle de cette tâche, donc ils ont besoin de contrôler l’œuvre elle-même. Cela s’applique aussi bien à l’enseignement qu’au logiciel. Pour que les utilisateurs puissent avoir ce contrôle, ils ont besoin de certaines libertés (lisez gnu.org), et l’on dit que l’œuvre est libre. Pour les œuvres qui pourraient être utiles dans un cadre commercial, les libertés requises incluent l’utilisation commerciale, la redistribution et la modification.

Creative Commons publie six licences principales. Deux sont des licences libres : la licence « Partage dans les mêmes conditions » CC BY-SA est une licence libre avec gauche d’auteur (en anglais, « copyleft ») forçant l’utilisation de la même licence pour les œuvres dérivés, et la licence « Attribution » (CC BY) qui est une licence libre sans gauche d’auteur. Les quatre autres ne sont pas libres, soit parce qu’elles ne permettent pas de modification (ND) soit parce qu’elles ne permettent pas d’utilisation commerciale (NC).

Selon moi, les licences non libres qui permettent le partage sont légitimes pour des œuvres artistiques ou de divertissement. Elle le sont également pour des œuvres qui expriment un point de vue (comme cet article lui-même). Ces œuvres ne sont pas dédiés à une utilisation pratique, donc l’argument concernant le contrôle par l’utilisateur ne s’y applique pas. Ainsi, je ne vois pas d’objection à ce qu’elles soient publiées sous licence CC BY-NC-ND, qui ne permet que la redistribution non commerciale de copies identiques à l’original.

L’utilisation de cette licence pour une œuvre ne signifie pas qu’il soit totalement impossible de la publier commercialement ou avec des modifications. La licence n’en donne pas la permission, mais vous pouvez toujours demander la permission au détenteur du droit d’auteur, peut-être avec un contrepartie, et il se peut qu’il vous l’accorde. Ce n’est pas obligé, mais c’est possible.

Cependant, deux des licences non libres CC mènent à la création d’œuvres qui, en pratique, ne peuvent pas être publiées à des fins commerciales, car il n’existe aucun moyen d’en demander l’autorisation. Ce sont les licences CC BY-NC et CC BY-NC-SA, les deux licences CC qui autorisent les modifications mais pas l’utilisation de manière commerciale.

Le problème survient parce que, avec Internet, les gens peuvent facilement (et légalement) empiler les modifications non-commerciales les unes sur les autres. Sur des décennies, il en résultera des œuvres avec des centaines, voire des milliers de contributeurs.

Qu’arrive-t-il si vous voulez utiliser commercialement l’une de ces œuvres ? Comment pouvez-vous en obtenir l’autorisation ? Il vous faut demander aux principaux titulaires de droits. Peut-être que certains d’entre eux ont apporté leur contribution des années auparavant et sont impossibles à retrouver. D’autres peuvent avoir contribué des décennies plus tôt, ou même sont décédés, mais leurs droits d’auteur n’ont pas disparu avec eux. Il vous faut alors retrouver leurs descendants pour demander cette autorisation, à supposer qu’il soit possible de les identifier. En général, il sera impossible de se mettre en conformité avec les droits d’auteur sur les œuvres que ces licences incitent à créer.

C’est une variante du problème bien connu des « œuvres orphelines », mais en pire, et ce de manière exponentielle ; lorsque l’on combine les œuvres de très nombreux contributeurs, le résultat final peut se trouver orphelin un nombre incalculable de fois avant même d’être né.

Pour éliminer ce problème, il faudrait un mécanisme impliquant de demander l’autorisation à quelqu’un (faute de quoi la condition NC devient sans objet) mais pas de demander l’autorisation à tous les contributeurs. Il est aisé d’imaginer de tels mécanismes ; ce qui est difficile, c’est de convaincre la communauté qu’un de ces mécanismes est juste et d’obtenir un consensus pour l’accepter.

Je souhaite que cela puisse se faire, mais les licences CC BY-NC et CC BY-NC-SA, telles qu’elles existent aujourd’hui, doivent être évitées.

Malheureusement, l’une d’entre elle est très utilisée. La CC BY-NC-SA, qui autorise la publication non commerciale de versions modifiées sous la même licence, est devenue à la mode dans le milieu de la formation en ligne. Les Open Courseware (didacticiels « ouverts ») du Massachusetts Institute of Technology (MIT) l’ont lancée, et de nombreux autres établissements d’enseignement ont suivi le MIT dans cette mauvaise direction. Alors que, pour les logiciels, « open source » signifie « probablement libre mais je n’ose pas communiquer à ce sujet donc tu dois vérifier toi-même », dans la plupart des projets d’enseignement en ligne « open » veut dire « non libre, sans aucun doute ».

Quand bien même le problème posé par les CC BY-NC-SA et BY-NC serait résolu, elles continueront de ne pas être la bonne façon de publier des œuvres pédagogiques censées servir à des tâches pratiques. Les utilisateurs de ces œuvres, enseignants et étudiants, doivent avoir le contrôle de leur travail, et cela requiert de les rendre libres. J’exhorte Creative Commons à prendre position et à déclarer que les œuvres censées être utilisés en pratique, y compris la documentation pédagogique et les œuvres de référence doivent être, comme les logiciels, diffusés uniquement sous des licences libres.

Éducateurs, enseignants, et tous ceux qui souhaitent contribuer aux œuvres de formation en ligne : s’il vous plaît, veillez à ce que votre travail ne devienne pas non libre. Offrez votre aide et vos textes à des œuvres pédagogiques qui utilisent des licences libres, de préférence des licences de gauche d’auteur de façon à ce que toutes les versions de l’œuvre respectent la liberté des enseignants et des étudiants. Ensuite, invitez les projets éducatifs à utiliser et redistribuer ces œuvres sur ces bases de respect de la liberté, s’ils le souhaitent. Ensemble, nous pouvons faire de l’éducation un champ de liberté.

Copyright 2012 Richard Stallman
Publié sous licence Creative Commons Attribution – Pas de Modification 3.0 (CC BY-ND 3.0)

Crédit photo : Preliminares 2013 (Creative Commons By-Sa)

Fin 2010, François Hollande annonçait (sans cacher sa fierté pour son département) que la Corrèze avait décidé de mettre un iPad entre les mains de tous les élèves de Sixième dans le cadre du projet Ordicollège.

On peut voir ici en vidéo l’intégralité de son allocution. On y parle d’« égalité », de « meilleur outil pour réussir », on y parle aussi d’un « coût de 1,5 million d’euros ».

Cette opération ayant été reconduite cette année, l’association P.U.L.L.CO (Promotion de l’Utilisation des Logiciels Libres en COrrèze) a décidé de réagir en convoquant la presse et surtout en publiant une lettre ouverte au président du Conseil Général. Ce dernier y a répondu en apportant ses propres arguments.

Cet échange nous a semblé suffisamment intéressant et révélateur pour que nous décidions de le reproduire ci-dessous.

iPads au collège : lettre ouverte au président du Conseil Général

URL d’origine du document

Association P.U.L.L.CO – 26 janvier 2013

Lettre ouverte adressée au Président du Conseil Général de la Corrèze Gérard Bonnet.

Monsieur le Président,

C’est avec une grande déception et une pointe de colère que nous apprenons que le Conseil Général a reconduit la distribution d’iPad aux collégiens corréziens dans le cadre de l’opération Ordicollège.

Lors de son lancement en 2008, l’opération Ordicollège avait fait le choix courageux et intelligent d’équiper les collégiens en matériel informatique fonctionnant grâce à des logiciels libres. Ce choix est depuis 3 ans remis en cause par l’arrivée des iPads, un produit sans clavier, dont les qualités pédagogiques restent à démontrer.

Les logiciels libres reposent sur les libertés que confère la licence d’un logiciel à ses utilisateurs. Ils sont alors libres de les utiliser, de les copier, de les étudier, de les adapter et de les redistribuer, en version originale ou modifiée. Les logiciels libres mettent le plus souvent en œuvre des standards ouverts qui garantissent l’accessibilité aux données et leur réutilisation à des fins d’interopérabilité entre systèmes et logiciels actuels et futurs.

Ce modèle revêt de nombreux intérêts. Tout d’abord il permet une libre circulation des logiciels et le partage du savoir. Chacun peut ainsi s’approprier la connaissance accumulée et l’enrichir de son propre savoir, faisant du logiciel libre un bien commun. Ce modèle rend de fait la distribution de logiciels gratuits possible, ce qui permet leur diffusion au plus grand nombre. Ainsi, avec le modèle du logiciel libre, nul ne peut être exclu de l’accès au savoir, ni de l’accès aux ressources numériques.

Par ailleurs, ce modèle favorise la relocalisation du développement du logiciel au plus près des utilisateurs finaux. Ainsi, l’investissement dans l’économie du logiciel libre permet des retombées économiques locales au lieu de les transférer vers les principaux éditeurs propriétaires, souvent installés aux États-Unis. ll existe des solutions libres à la plupart des usages informatiques. Si elles n’existent pas encore, il suffit d’en financer le développement pour que chacun en profite. Il est donc possible de remettre en cause les positions dominantes d’éditeurs propriétaires à l’origine de situation de dépendance technologique. Pour un investisseur institutionnel tel qu’une collectivité territoriale comme le Conseil Général, ces préoccupations nous semblent prioritaires.

C’est d’ailleurs en ce sens que va la récente réponse du Ministère des PME, de l’innovation et de l’Économie numérique, à une question écrite du député Jean-Jacques Candelier. Cette dernière rappelle les principaux avantages du logiciel libre. D’abord pour les individus, car « chacun peut s’approprier la connaissance » et « nul ne peut être exclu de l’accès au savoir » avec le logiciel libre ; mais aussi pour l’État, pour lequel le logiciel libre « constitue une opportunité qu’il convient de saisir », et pour les industries européennes enfin, notamment en raison de l’indépendance technologique qu’il permet. La position du ministère de Fleur Pellerin fait d’ailleurs suite à la circulaire de Jean-Marc Ayrault sur l’usage des logiciels libres dans les administrations allant dans le même sens.

En choisissant d’équiper les collégiens d’iPad, en plus d’enrichir une entreprise privée américaine avec nos impôts, le Conseil Général de la Corrèze se rend coupable d’enfermer l’ensemble des collégiens corréziens dans le carcan d’Apple. Les usages sont ainsi limités à ce que l’entreprise a décidé ou permis. L’utilisateur n’a pas la possibilité d’explorer l’outil pour le comprendre, ni de l’adapter à ses besoins. Il est contraint d’adapter ses besoins à l’outil. Par exemple le choix volontaire d’Apple d’interdire l’usage de certaines technologies comme Flash et Java sur ses tablettes rend impossible l’accès à certaines ressources éducatives mises à disposition sur les sites web de Sesamath (en Flash) et de Geogebra (en Java).

Par ailleurs, Apple utilise des Mesures Techniques de Protection (MTP ou DRM) pour restreindre les libertés des utilisateurs de diverses manières. Pour ne citer que deux exemples, il est impossible d’installer un logiciel ne provenant pas de l’AppStore officiel, qui n’est contrôlé que par l’intérêt commercial de la firme, et l’usage des films achetés sur iTunes est surveillé. De plus, le contournement de ces restrictions est interdit et considéré par Apple comme un acte criminel.

Plus grave : les données personnelles de tous les collégiens sont menacées. En effet, l’usage de l’iPad contraint ses utilisateurs à enregistrer des données personnelles dans des bases de données détenues par Apple aux États-Unis, c’est-à-dire en dehors du pouvoir de contrôle de la CNIL, censée protéger les données personnelles des citoyens français. De plus, l’usage de ces tablettes, de par leur manque de capacité de stockage, contraint les utilisateurs à enregistrer leurs données ailleurs, souvent dans le « Cloud », en utilisant des services comme Dropbox. Là encore, les données des utilisateurs échappent à leur contrôle au profit d’intérêts commerciaux étrangers et soumises à des lois qu’ils ne connaissent pas.

En outre, la société Apple exerce un filtrage arbitraire sur les logiciels (les « apps ») téléchargeables sur les dispositifs sans clavier qu’elle commercialise (tablettes, téléphones, baladeurs numériques…). La gestion des mises à jour des-dits logiciels est elle aussi particulièrement problématique : les anciennes versions des logiciels ne sont pas accessibles au téléchargement, ce qui a pour conséquence de provoquer une obsolescence artificiellement accélérée des dispositifs qui les accueillent. Ainsi, alors qu’un ordinateur sous GNU/Linux n’est limité dans le temps que par la durée de vie du matériel, un iPad deviendra obsolète lorsque les applications seront déclarées comme n’étant plus installables.

Enfin, ce contrôle monopolistique forcément intéressé est déjà un problème pour les consommateurs de technologies aisés, mais c’est un désastre pour les moins nantis. Le fossé se creuse entre ceux qui ont les moyens d’acheter des applications sur le magasin en ligne d’Apple et ceux qui ne les ont pas. Est-ce le rôle de l’école que d’exacerber les inégalités économiques et sociales des familles ? Est-ce le rôle du Conseil Général de financer ce choix discriminant ? Est-ce le rôle du Conseil Général d’apprendre aux élèves à être les consommateurs d’Apple ?

L’objectif est-il de mettre un appareil connecté dans les mains de chaque collégien, quel qu’en soit le prix et en dépit de leur liberté ? Ou devrions-nous plutôt fournir des outils qui encouragent les élèves et les enseignants au partage de la connaissance en mettant à leurs disposition un environnement dans lequel ils ont la possibilité de résoudre eux-mêmes leurs problèmes ? Pour nous, l’éducation c’est de la créativité, de l’ingéniosité et du partage ; toutes ces caractéristiques étant bien plus puissantes dans le monde du libre que dans celui, verrouillé et rigide, de la tablette numérique du géant américain.

En choisissant de distribuer des iPad aux collégiens, le Conseil Général de la Corrèze a fait le choix politique de suivre un effet de mode, en privilégiant le paraître au bon sens. Ce choix démagogique a un prix, celui de l’aliénation des élèves et des enseignants ainsi que l’évaporation de l’investissement public au seul profit des intérêts d’une entreprise commerciale étrangère.

Ce choix aurait pu être différent, il aurait pu être celui de la liberté, de l’égalité et de la fraternité en choisissant un autre modèle de société, celui, globalisé du nord au sud, du bien commun et du logiciel libre. Les moyens investis depuis de nombreuses années l’auraient été de façon bien plus pérenne en aidant à concevoir une tablette et des ressources numériques libres. De nombreux projets existent déjà et sauraient profiter de l’aide des collectivités territoriales et de la puissance publique pour le bénéfice de tous.

Nous restons à votre entière disposition pour vous apporter plus de précisions sur nos positions et vous faire part de nos propositions pour l’avenir de l’opération Ordicollège.

Librement.

L’association Pullco

Réponse à l’association Pullco

URL d’origine du document

OrdiCollège – 30 janvier 2013

Mettre en avant que la tablette est un produit sans clavier tout en argumentant sur la nécessité de faire le choix de tablettes françaises comme le fait l’association Pullco (« il existe des tablettes françaises compétitives », La Montagne, 29/01/13), (« Pourquoi utiliser des tablettes Apple alors que nous avons des tablettes françaises, Archos », L’Echo de la Corrèze, 28/10/13) interroge : la tablette Apple serait donc un produit de moindre qualité que la tablette Archos (également fabriquée en Chine), alors qu’aucune des deux n’a de clavier physique ?

Les collectivités locales sont soumises à une réglementation précise et contraignante dans le cadre des marchés publics. Pour Ordicollège, il s’agit d’un appel d’offres européen, qui a été remporté par une société française et non par Apple. Aucune offre de matériel « français » n’a été déposée, pas plus que d’offres sous environnement « libre ».

Le budget engagé par le Conseil général n’est pas uniquement destiné à l’acquisition du matériel, il revient pour une bonne part à la société française qui a remporté le marché. La chaîne de préparation, la logistique, la gestion administrative, représentent des emplois. La fabrication de la coque de protection a été confiée à une société française, les équipes techniques du constructeur le sont également.

L’association Pullco défend le logiciel libre selon quatre principes : la liberté d’exécuter le programme sans restrictions, la liberté d’étudier le fonctionnement du programme, la liberté de redistribuer des copies du programme, la liberté d’améliorer le programme et de publier ses améliorations. Cette approche, parfaitement recevable, ne répond pas pour autant aux objectifs fixés dans le cadre d’Ordicollège.

Le Conseil général de la Corrèze a fait le choix, depuis 2008, d’équiper les collégiens dans le but de favoriser les apprentissages et la réussite scolaire, notamment pour les élèves en difficulté, et de réduire la fracture numérique. Sans conditions de ressources, ni contraintes liées à la nécessité d’un abonnement internet au domicile. Objectif atteint, comme en atteste le rapport réalisé par la mission d’évaluation de l’Inspection générale de l’Education nationale. Rapport qui souligne également le choix judicieux de la tablette.

Pédagogiquement, cette opération s’inscrit dans la mise œuvre au Collège des compétences définies par le référentiel Education nationale B2i (brevet informatique et internet, mis à jour en décembre 2011).

Le B2i porte sur les pratiques, « les évolutions d’Internet et le développement des usages pédagogiques du numérique afin de mieux préparer les élèves à un usage responsable de ces technologies » ; les objectifs sont les suivants : acquérir, stocker et traiter des informations pour produire des résultats, être un utilisateur averti des règles et des usages de l’informatique et de l’internet, composer un document numérique, chercher et sélectionner l’information demandée, communiquer, échanger.

L’informatique n’est pas une matière enseignée au collège. Ce sont ses usages qui sont au programme et le logiciel (ou application) ne représente qu’une infime part dans ce contexte. Il convient au passage de ne pas faire d’amalgame entre logiciels et ressources pédagogiques, ces dernières pouvant fonctionner avec un logiciel ou de façon autonome.

A partir de ce constat, il est facile de comprendre que les objectifs défendus par l’association Pullco sont éloignés du contexte d’Ordicollège.

L’exclusion de l’accès au savoir n’est pas un argument recevable, chaque collégien étant destinataire du même matériel, des mêmes logiciels. Pas plus que l’idée d’un « enfermement dans le carcan » d’un constructeur. Les fonctionnalités d’un navigateur internet, d’un traitement de texte ou d’un tableur sont identiques, quel que soit l’environnement système.

Au collège, ce sont les bases nécessaires à l’utilisation et à la compréhension de ces outils qui sont enseignées, sachant que plus tard, l’utilisateur sera libre de faire le choix de son environnement personnel, mais qu’il devra aussi s’adapter à l’environnement mis en œuvre dans son cadre professionnel.

L’association Pullco met en avant l’impossibilité d’utiliser les ressources en Flash, en oubliant qu’il ne s’agit pas d’une technologie libre et que celle-ci est aujourd’hui en voie de remplacement par le HTML5. Elle avance également des arguments erronés concernant les données personnelles des élèves : les informations nécessaires sont gérées via des adresses génériques (ex. : tab2019@ordicollege), un alias nominatif étant uniquement ajouté sur le compte de messagerie.

Concernant le téléchargement de logiciels (apps) sur les tablettes, bon nombre sont gratuites et utilisées dans le cadre d’Ordicollège. Par contre, il n’a jamais été question de faire payer des apps aux parents, l’utilisation de cartes bancaires étant interdite dans le cadre de la mise à disposition des tablettes.

Face aux arguments développés par l’association Pullco, il y a la réalité du monde des technologies. Qu’un matériel soit davantage plébiscité qu’un autre ne relève pas uniquement de la communication mise en œuvre par son fabricant. Les utilisateurs savent également faire preuve de discernement.

L’association Pullco comprend parmi ses adhérents des spécialistes des programmes informatiques et c’est tout à son honneur. Mais l’immense majorité des usagers du numérique ne sont pas des passionnés des systèmes ou des entrailles des matériels et des logiciels, ce qui ne signifie pas pour autant que l’on puisse parler pour eux d’alinéation. Cela dit, il est dommage que Pullco n’ait jamais engagé la moindre démarche envers Ordicollège ou pris contact avec ses animateurs pour se renseigner à la source sur l’opération.

Les dirigeants de l’association auraient pu recueillir des informations vraies et précises, notamment sur le travail de recherche et de développement effectué dans le cadre d’Ordicollège. Ainsi, les responsables d’Unowhy, société française ayant remporté l’appel à projets du Ministère de l’Education, qui développent une tablette française (pour l’assemblage seulement) sur la base d’un environnement Linux, étaient en Corrèze le 28/01/2013 pour une réunion de travail sur Ordicollège. Pour eux, la Corrèze est le département le plus en avance dans les usages pédagogiques du numérique et même loin devant les opérations engagées ailleurs en France.

Crédit photos : Brad Flickinger et Devon Christopher Adams (Creative Commons By)

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : lamessen, lerouge, Kalupa, Sky, Astalaseven, Alpha, LuD-up, CoudCoud, peupleLa, goofy

La documentation et moi, avant et après

Anne Gentle

Anne Gentle est une rédactrice technique acharnée et la coordinatrice de la documentation communautaire à Rackspace pour OpenStack, un projet open source d’informatique dans le nuage. Avant de rejoindre OpenStack, Anne travaillait en tant que consultante de publication communautaire, en donnant une direction stratégique aux rédacteurs professionnels qui veulent produire du contenu en ligne sur des wikis contenant des pages et des commentaires générés par les utilisateurs. Sa passion pour les méthodes communautaires de documentation l’a amenée à écrire un livre sur les techniques de publication collaborative pour la documentation technique intitulé Conversation et communauté : la documentation dans le web social. Elle s’occupe aussi bénévolement de la maintenance de la documentation pour les manuels FLOSS qui proposent de la documentation open source pour les projets open source.

Voilà une prémisse bien étrange : vider mes tripes sur ce que j’aurais voulu savoir de l’open source et de la documentation. Plutôt que de vous dire ce que je veux que vous sachiez sur l’open source et la documentation, je dois vous dire ce que j’aurais aimé que mon moi antérieur sache. Cette demande suscite un sentiment de nostalgie ou de remords voire cette horrible énigme : « à quoi pouvais-je bien penser ? ».

En ce qui me concerne, avec juste cinq ans de moins, mon moi antérieur était une trentenaire bien installée dans sa vie professionnelle. D’autres, au contraire, se souviennent qu’ils n’étaient qu’adolescents lors de leurs premières expériences open source. Jono Bacon dans son livre L’art de la Communauté, raconte comment il s’est tenu devant la porte d’un appartement, le cœur battant, alors qu’il était sur le point de rencontrer quelqu’un à qui il n’avait jamais parlé que sur le réseau, par le biais d’une communauté open source. J’ai moi aussi fait cette expérience de la première rencontre physique de gens que j’avais découverts en ligne, mais ma première incursion dans le monde de la documentation open source s’est produite lorsque j’ai répondu à une demande d’aide par courriel.

Le courriel provenait d’un ancien collègue qui me demandait de l’aide pour la documentation de l’ordinateur portable XO, le projet fondateur de l’organisation One Laptop Per Child (un portable pour chaque enfant). J’ai réfléchi à ce que je pensais être une proposition intéressante, j’en ai parlé à mes amis et à mon époux en me demandant si ce n’était pas une bonne occasion d’expérimenter de nouvelles techniques de documentation et d’essayer une chose que je n’avais jamais faite auparavant : une documentation basée sur un wiki. Depuis cette première expérience, j’ai rejoint OpenStack, un projet open source sur une solution d’informatique dans le nuage, et je travaille à plein temps sur la documentation et le support communautaires.

Je pense immédiatement aux nombreuses contradictions que j’ai rencontrées tout au long de la route. J’ai découvert que pour chaque observation il existe des champs et contre-champs surprenants. Par exemple, la documentation est absolument indispensable pour l’aide aux utilisateurs, l’éducation, la possibilité de choisir ou bien la documentation promotionnelle qui amène à adopter un logiciel. Pourtant, une communauté open source pourra continuer d’avancer malgré le manque de documentation ou de la doc complètement défectueuse. Voici une autre collision apparente de valeurs : la documentation pourrait être une très bonne tâche pour démarrer, un point de départ pour les nouveaux volontaires, pourtant les nouveaux membres de la communauté savent si peu de choses qu’il ne leur est pas possible d’écrire ni même d’éditer de manière efficace. En outre les petits nouveaux ne sont pas bien familiers des différents publics auxquels doit servir la documentation.

Ces derniers temps on entend dire un peu partout : « les développeurs devraient écrire la doc de développement » parce qu’ils connaissent bien ce public et par conséquent cela lui serait aussi utile qu’à eux-mêmes. D’après mon expérience, un regard frais et neuf est toujours le bienvenu sur un projet et certaines personnes ont la capacité d’écrire et de partager avec d’autres ce regard frais et empathique. Mais vous n’allez sûrement pas vous mettre à créer une culture « réservée aux novices » autour de la doc parce qu’il est important que des membres essentiels de la communauté technique apportent leur contribution aux efforts de documentation, et qu’ils encouragent aussi les autres à y participer.

Une partie du vilain petit secret sur la documentation des projets open source est qu’il n’existe qu’une frontière pour le moins floue entre leur documentation officielle et leur documentation officieuse. Si seulement j’avais su que les efforts de documentation devraient être sans cesse renouvelés et que de nouveaux sites web pourraient apparaître là où il n’y en avait pas… Une documentation extensive n’est pas le moyen le plus efficace pour s’initier à des projets ou des logiciels mais un parcours sinueux dans les méandres de la documentation sur le Web peut s’avérer plus instructif pour ceux qui veulent lire entre les lignes et avoir ainsi une idée de ce qui se passe dans la communauté grâce à la documentation. Avoir beaucoup de forks(1) et des publics variés peut indiquer que le produit est complexe et qu’il est très suivi. Cela peut aussi signifier que la communauté n’a mis en place aucune pratique quant à la documentation de référence ou que les efforts désorganisés sont la norme.

À mes débuts, j’aurais aimé avoir la capacité de ressentir la « température conviviale » d’une communauté en ligne. Quand vous entrez dans un restaurant rempli de tables nappées de blanc, de couples qui dînent et de conversations feutrées, l’information visuelle et auditive que vous recevez détermine l’ambiance et vous donne quelques indices sur ce que vous vous apprêtez à vivre lors de votre repas. Vous pouvez tout à fait transposer ce concept de température conviviale à une communauté en ligne.

Une communauté open source vous donne quelques indices dans ses listes de discussion, par exemple. Une page de présentation de la liste qui commence par de nombreuses règles et conventions sur la manière de poster indique une gouvernance très stricte. Une liste de discussion qui contient de nombreuses publications mettant l’accent sur le fait qu’il « n’y a pas de question bête » est plus accueillante pour de nouveaux rédacteurs de documentation.

J’aurais aussi aimé connaître un moyen de faire non seulement de l’audit de contenu, c’est-à-dire lister le contenu à disposition pour le projet open source, mais aussi de l’audit de communauté, donc lister les membres influents de la communauté open source, qu’il s’agisse ou non de contributeurs.

Pour terminer, une observation à propos de l’open source et de la documentation que j’ai pu vérifier avec plaisir, c’est l’idée que la rédaction de la documentation peut s’effectuer via des « sprints » — grâce à des de brusques dépenses d’énergie avec un public ciblé et un but précis, pour aboutir à un ensemble documentaire de référence.

J’ai été très contente d’entendre lors d’une conférence à SXSW Interactive que les sprints sont tout à fait acceptables pour la collaboration en ligne, qu’il faut s’attendre à des fluctuations du niveau d’énergie de chacun et que c’est OK. La documentation des logiciels est souvent faite à l’arrache dans les moments d’accalmie d’un cycle de release(2) et ça ne pose aucun problème dans la documentation open source qui est basée sur la communauté. Vous pouvez adopter une approche stratégique et coordonnée et continuer tout de même de proposer des évènements de grande intensité autour de la documentation. Ce sont des moments exaltants dans l’open source et mon ancien moi les a pleinement ressentis. C’est une bonne chose que vous continuiez à passer de votre moi antérieur à votre moi actuel avec un paquet de conseils en poche.

(1) Un fork est un nouveau logiciel créé à partir du code source d’un logiciel existant.

(2) La release est la publication d’un logiciel.

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : peupleLa, goofy, lamessen, SaSha_01, lerouge, Kalupa, RavageJo, lenod, Sky, Astalaseven, Alpha, KoS, purplepsycho +tala

De L’importance des bonnes manières

Rich Bowen

Rich Bowen a travaillé dans le domaine du logiciel libre et open source pendant près de quinze ans. La majeure partie de son travail a porté sur le serveur HTTP Apache ; il a également travaillé sur Perl, PHP et diverses applications web. Il est l’auteur de Apache Cookbook, The Definitive Guide to Apache et divers autres livres. Il fait également de fréquentes apparitions dans diverses conférences sur les technologies.

J’ai commencé à travailler sur le projet de documentation du serveur HTTP Apache en septembre 2000. Du moins, c’est à ce moment-là que j’ai réalisé mon premier commit dans les docs. Auparavant, j’avais présenté quelques corrections par courriel, et quelqu’un d’autre les avait appliquées.

Depuis cette période, j’ai réalisé un peu plus d’un millier de modifications de la documentation du serveur HTTP Apache, ainsi qu’une poignée de modifications du code lui-même. Ceux qui s’impliquent dans les logiciels libres et open source le font pour tout un tas de raisons différentes. Certains tentent de se faire un nom. La plupart essaient de « gratter là où ça les démange » comme ils disent, s’efforçant d’ajouter une fonctionnalité, ou de créer une nouvelle brique logicielle pour satisfaire un de leurs besoins.

Je me suis impliqué dans l’écriture de la documentation sur des logiciels parce que j’avais été enrôlé pour aider à l’écriture d’un livre et que la documentation existante était vraiment horrible. Donc, pour rendre le livre cohérent, j’ai dû discuter avec différentes personnes du projet afin qu’elles contribuent à donner du sens à la documentation. Lors de la rédaction de l’ouvrage, j’ai amélioré la documentation, avant tout pour me faciliter la tâche. À peu près à la même époque, Larry Wall, le créateur du langage de programmation Perl, promouvait l’idée selon laquelle les trois principales qualités d’un programmeur étaient la paresse, l’impatience et l’arrogance. Selon moi, Larry avançait des arguments fondés et avec un sens de l’humour certain. Néanmoins, une partie non négligeable de la communauté des programmeurs a pris ses paroles comme un permis de connerie.

La paresse

Nous écrivons de la documentation pour ne pas avoir à répondre aux mêmes questions tous les jours pour le restant de notre vie. Si la documentation est insuffisante, les gens auront des difficultés à utiliser le logiciel. Bien que cela puisse être la source d’une activité lucrative de consultant, il s’agit aussi du meilleur moyen de faire avorter un projet, car les gens abandonneront, frustrés, et se tourneront alors vers d’autres choses qu’ils n’auront pas à passer des heures pour comprendre.

Ainsi, la paresse est la première vertu d’un rédacteur de documentation. Quand un client pose une question, nous devrions répondre à cette question en profondeur. Et même, de la façon la plus complète possible. Nous devrions alors enregistrer cette réponse pour la postérité. Nous devrions l’enrichir avec des exemples et si possible des diagrammes et des illustrations. Nous devrions nous assurer que le texte est clair, grammaticalement correct et éloquent. Nous devrions alors l’ajouter à la documentation existante dans un endroit facile à trouver et largement référencé partout où quelqu’un pourrait le chercher.

La prochaine fois que quelqu’un posera la même question, nous pourrons lui répondre avec un lien vers la réponse. Et les questions que l’on pourrait poser après l’avoir lue devraient être la source d’améliorations et d’annotations à ce qui a déjà été écrit. C’est la vraie paresse. La paresse ne signifie pas simplement se dérober au travail. Cela veut aussi dire faire le travail si bien qu’il n’aura pas à être refait.

La patience

ll existe une tendance dans le monde de la documentation technique à être impatient et querelleur. Les sources de cette impatience sont nombreuses. Certaines personnes pensent que, comme elles ont dû travailler dur pour comprendre ces choses, vous le devez aussi. Beaucoup d’entre nous dans le monde du technique sommes des autodidactes et nous avons peu de patience pour ceux qui viennent après nous et veulent accéder rapidement au succès. J’aime appeler ça le comportement du « tire-toi de mon chemin ». Ce n’est pas vraiment constructif.

Si vous ne parvenez pas à être patient avec le client, alors vous ne devriez pas être impliqué dans le service clientèle. Si vous vous mettez en colère quand quelqu’un ne comprend pas, vous devriez peut-être laisser quelqu’un d’autre gérer la question.

Bien sûr, c’est très facile à dire, mais beaucoup plus difficile à faire. Si vous êtes un expert sur un sujet particulier, les gens vont inévitablement venir à vous avec leurs questions. Vous êtes obligé d’être patient, mais comment allez-vous y parvenir ? Cela vient avec l’humilité.

L’humilité

J’ai fait de l’assistance technique, en particulier par liste de diffusion, pendant à peu près deux ans, quand j’ai commencé à suivre des conférences techniques. Ces premières années ont été très amusantes. Des idiots venaient sur une liste de diffusion et posaient des questions stupides que des milliers d’autres perdants avaient posées avant eux. Et si seulement ils avaient regardé, ils auraient trouvé toutes les réponses déjà données auparavant. Mais ils étaient trop paresseux et trop bêtes pour le faire.

Ensuite, j’ai assisté à une conférence, et j’ai constaté plusieurs choses. Tout d’abord, j’ai découvert que les personnes qui posaient ces questions étaient des êtres humains. Ils n’étaient pas simplement un bloc de texte écrit noir sur blanc, à espacement fixe. Il s’agissait d’individus. Ils avaient des enfants. Ils avaient des loisirs. Ils connaissaient beaucoup plus de choses que moi sur une grande variété de sujets. J’ai rencontré des gens brillants pour qui la technologie était un outil qui servait à accomplir des choses non techniques. Ils souhaitaient partager leurs recettes avec d’autres cuisiniers. Ils souhaitaient aider les enfants d’Afrique de l’Ouest à apprendre à lire. Ils étaient passionnés de vin et voulaient en apprendre davantage. Ils étaient, en bref, plus intelligents que moi, et mon orgueil était le seul obstacle sur la route de leur succès.

Quand je suis revenu de cette première conférence, j’ai regardé les utilisateurs de listes de diffusion sous un tout autre jour. Ce n’étaient plus des idiots posant des questions stupides, simplement des gens qui avaient besoin d’un peu de mon aide pour pouvoir accomplir une tâche. Pour la plupart, la technologie n’était pas une passion. La technologie était seulement un outil. Il était donc compréhensible qu’ils n’aient pas passé des heures à lire les archives de la liste de diffusion de l’année passée et choisissent plutôt de reposer des questions.

Bien entendu, si un jour les aider devient pénible, la chose la plus polie à faire est de prendre du recul et de laisser quelqu’un d’autre répondre à la question plutôt que de leur dire que ce sont des imbéciles. Mais il faut aussi se rappeler toutes les fois où j’ai eu à poser des questions stupides.

La Politesse et le Respect

En fin de compte, tout cela se résume à la politesse et au respect. J’ai principalement abordé la question de l’assistance technique, mais la documentation n’est rien d’autre qu’une forme statique d’assistance technique. Elle répond aux questions que vous attendez des gens et elle offre des réponses dans une forme semi-permanente à titre de référence.

Lorsque vous écrivez cette documentation, vous devriez essayer de trouver le juste équilibre entre penser que votre lecteur est un idiot et penser qu’il devrait déjà tout savoir. D’un côté, vous lui demandez de s’assurer que l’ordinateur est branché, de l’autre, vous utilisez des mots comme « simplement » et « juste » pour faire comme si chaque tâche était triviale, laissant au lecteur l’impression qu’il n’est pas tout à fait à la hauteur.

Cela implique d’avoir beaucoup de respect et d’empathie pour votre lecteur, en essayant de vous rappeler ce que c’est que de débuter ou d’avoir un niveau intermédiaire dans l’apprentissage d’un nouveau logiciel. Cependant, les exemples de mauvaise documentation sont si répandus qu’il ne doit pas être difficile de s’en souvenir. Il y a des chances que vous en ayez fait l’expérience au cours de la dernière semaine.

J’aurais aimé…

J’aurais aimé être moins arrogant quand j’ai commencé à travailler sur la documentation open source. Quand je relis ce que j’ai pu écrire sur des listes de diffusion archivées publiquement, gravées à jamais dans le marbre d’Internet, j’ai honte d’avoir été aussi grossier.

La plus grande vertu humaine est la politesse. Toutes les autres vertus en découlent. Si vous ne pouvez pas être poli, tout ce que vous accomplirez importera peu.