Bonjour Céline, peux-tu nous expliquer comment tu en es venue à utiliser le système d’exploitation Free BSD ? Tu l’as attrapé tout d’un coup ou bien c’est l’effet d’une lente incubation ?

Je suis arrivée sur FreeBSD un peu par hasard. En fait, quand j’ai décidé de passer à Linux (en 1999, je sais ça remonte), j’ai testé plusieurs distributions dont La Lycoris Desktop LX, Debian et Ubuntu 6.06. J’ai utilisé Ubuntu et Debian en parallèle pendant énormément de temps jusqu’à ce que je décide de tester OpenBSD (réputé pour sa sécurité) pour l’utiliser sur un serveur de développement. À cause de l’absence de Java et comme je suis développeuse C/Java, j’ai éprouvé de la frustration de ne pas pouvoir tout faire sur ma machine nouvellement acquise. J’ai donc cherché une alternative la plus proche possible : FreeBSD s’est avéré être mon choix final. Une installation sans fioriture, simple et qui n’installait que ce dont j’avais besoin sur mon serveur (seul ArchLinux m’avait satisfaite au même degré jusque-là), je ne demandais rien de plus. Donc pour en revenir à l’usage de ce système d’exploitation, c’est bien l’effet d’une incubation d’une bonne dizaine d’années.

Bon c’est bien joli FreeBSD mais son installation et son usage réclament un certain niveau de compétence technique, non ? est-ce que tu le conseillerais vraiment à des usagers qui comme moi choisissent Ubuntu parce que c’est la distribution la plus abordable ? Il n’existe pas une version plus simple avec une interface graphique qui simplifie la vie ?

C’est vrai que quand on arrive sur FreeBSD, il ne faut pas avoir peur de la console. C’est pareil pour certaines distributions Linux, il faut s’armer de patience, lire la documentation (très bien réalisée) et parfois galérer dans les pages man. L’installation ne se fait pas en quelques clics, une fois l’installation finie, on ne dispose vraiment que des outils de base. Mais c’est ce que j’adore sur OpenBSD et FreeBSD (bon et aussi ArchLinux), c’est que je sais ce qu’il y a sur mon poste, ce qui démarre quand j’allume mon ordinateur, alors qu’au fil de temps je trouve que le fonctionnement des distributions Linux, pour se rendre facile d’accès au grand public, devient de plus en plus opaque. Il suffit de taper un petit ps aux sur Ubuntu pour voir tout ce qui peut tourner (des fois pour rien)… Pour ce qui est d’une version plus facile d’accès, j’ai entendu parler de PC-BSD qui a justement pour objectif de rendre FreeBSD accessible à tous : installation aisée en quelques clics, KDE est fourni en bureau par défaut… Je testerai peut-être un jour sur un autre PC ou avec VirtualBox 😉

Tu en fais un usage dans ta vie professionnelle ou bien c’est choix de passionnée pour ton usage personnel ?

Dans ma vie professionnelle, je travaille sur RedHat, Debian et Solaris, hélas pas encore de FreeBSD en vue, mais ça viendra ! 😉

Merci, je te laisse le soin de présenter l’article…

Il y a de cela 20 ans, le 19 juin 1993, David Greenman, Jordan Hubbard et Rod Grimes annonçaient la création d’un nouveau logiciel basé sur le code source de BSD (Berkeley Software Distribution, voyez cette page Wikipédia) : FreeBSD était né. Peu connu du grand public, ce système d’exploitation est pourtant utilisé partout : en tant que solution d’hébergement pour des sociétés telles que Yahoo!, ou comme solution de sécurité pour la mise en place de firewall. Deux systèmes d’exploitation reposent sur son noyau : FreeNAS et MacOS. FreeNAS est une solution libre grand public pour héberger du contenu à travers un réseau, tandis que MacOS est le système d’exploitation propriétaire que nous connaissons tous au moins de nom. Pour fêter ce cap des 20 ans, voici un petit article qui vous fera découvrir une partie du monde BSD.

— Céline

FreeBSD fête ses 20 ans et met toute sa puissance à votre service.

Traduction Framalang : lamessen, Céline, Garburst, Asta, audionuma d’après l’article original de Lawrence Latif

Le système d’exploitation open source FreeBSD vient de fêter son vingtième anniversaire.

FreeBSD a vu au fil des années sa popularité auprès du grand public diminuer alors que le noyau Linux et les nombreuses distributions qui l’utilisent ont connu un développement rapide. Cependant, FreeBSD a eu 20 ans le 19 juin et continue de faire fonctionner des infrastructures réseaux vitales.

FreeBSD a introduit de nombreuses innovations qui ont été adoptées par certaines distributions Linux. Par exemple, la collection de ports FreeBSD, qui compile des logiciels à partir du code source plutôt qu’à partir de binaires pré-assemblés, a été copiée par Gentoo Linux pour son système Portage.

FreeBSD est également connu pour avoir l’une des piles réseau les plus robustes. Il est fréquemment utilisé par les chercheurs et les industriels comme base pour la simulation et les systèmes de production. Monowall et Pfsense sont des distributions populaires basées sur FreeBSD destinées à être utilisées sur des périphériques réseaux qui embarquent tous les types de fonctionnalités, des firewalls aux réseaux privés virtuels en passant par les liaisons ADSL, sur un système facile à utiliser.

Alors que FreeBSD n’est pas la seule variante libre et largement distribuée de BSD Unix, il est différent de OpenBSD qui essaie d’être le système d’exploitation le plus sécurisé et de NetBSD qui tente de fonctionner sur n’importe quel appareil possédant un microprocesseur. Il est devenu la référence pour une utilisation générale de BSD.

Cependant, FreeBSD n’est pas que réseau et démons, puisque durant ces dernières années les distributions de bureau BSD Unix reposant sur FreeBSD sont apparues, notamment avec PC-BSD qui est la plus célèbre.

FreeBSD, grâce à ses performances et sa licence, est utilisé par des sociétés commerciales comme Citrix, Netapp et Juniper.

Ces dernières années, même la communauté Linux a commencé à reprendre des parties de FreeBSD, avec Debian qui propose une version de sa distribution utilisant le kernel FreeBSD. Malgré la blague récurrente sur le fait que BSD soit mort ou non, étant donné son support à l’industrie, il est probable qu’il continuera son combat dans les décennies à venir.

Qu’il s’agisse de son code ou de son utilisation, la faiblesse de la documentation d’un logiciel libre est souvent montrée du doigt.

Voici, selon Andy Lester, 13 défauts ou lacunes communément rencontrés, qui sont autant d’écueils que l’on peut contourner avec un minimum d’efforts aujourd’hui pour gagner demain un temps précieux.

13 choses que les gens détestent sur vos documentations open source

13 Things People Hate about Your Open Source Docs

Andy Lester – 10 janvier 2013 – SmartBear Blog
(Traduction : Lamessen, calou, Shanx, sinma, Asta + anonymes)

La plupart des développeurs open source aiment penser à la qualité du logiciel qu’ils développent, mais la qualité de la documentation est souvent laissée de côté. Il est rare de voir vanter la documentation d’un projet, et pourtant elle a un impact direct sur sa réussite. Sans une bonne documentation, les utilisateurs n’utiliseront pas votre projet, ou ils n’y prendront pas de plaisir. Les utilisateurs comblés sont ceux qui diffusent des infos à propos de votre projet – ce qu’ils ne font qu’après avoir compris comment il fonctionne. Et ils apprennent cela à partir de la documentation du projet.

Malgré tout, de trop nombreux projets ont une documentation décevante. Et cela peut être décevant de plusieurs manières.

Les exemples que je donne ci-dessous sont purement arbitraires, je ne veux pas cibler un projet en particulier. Ce sont seulement ceux que j’ai utilisés récemment, cela ne veut pas dire qu’ils représentent les pires atrocités. Chaque projet a commis au moins quelques-uns de ces péchés. Que vous soyez utilisateur ou développeur, à vous d’évaluer à quel point votre logiciel préféré est ou non coupable, et comment vous pouvez aider à y remédier le cas échéant.

1. Le manque d’une bonne introduction ou d’un README/LISEZ-MOI

Le README/LISEZ-MOI est la première impression que les utilisateurs potentiels ont de votre projet. Si le projet est sur GitHub, le README/LISEZ-MOI est automatiquement affiché sur la page d’accueil du projet. Si vous l’avez mal rédigé, ils peuvent ne jamais revenir.

Vous voulez capter l’attention du lecteur et l’encourager à continuer la découverte de votre projet ? Le README/LISEZ-MOI devrait alors au moins expliquer :

• ce que le projet fait
• pour qui il est fait
• sur quel matériel ou plateforme il tourne
• toutes les dépendances majeures, comme « Requiert Python 2.6 et libxml »
• comment l’installer, ou un accompagnement de chaque étape à la suivante.

Tout cela doit pouvoir être compris par quelqu’un qui n’a jamais entendu parler de votre projet, et peut-être même jamais imaginé un projet pouvant s’en rapprocher. Si le projet possède un module calculant la distance de Levenshtein, ne partez pas du principe que n’importe qui lisant votre README/LISEZ-MOI sait ce que c’est. Expliquez que la distance de Levenshtein est utilisée pour comparer deux chaînes de caractères, et ajoutez quelques renvois vers des explications plus poussées pour celui qui aimerait approfondir le sujet.

Ne décrivez pas votre projet par rapport à un autre projet, comme « NumberDoodle est comme BongoCalc, mais meilleur ! » Ça n’est d’aucune aide pour quelqu’un qui n’a jamais entendu parlé de BongoCalc.

2. La documentation non disponible en ligne

Bien que je n’ai pas lu d’études à ce sujet, je serais prêt à parier que 90% des recherches de documentation sont faites avec Google et un navigateur sur Internet. La documentation de votre projet doit être en ligne, et disponible. Partant de là, il serait embarrassant que la documentation de mon propre projet, ack, ne soit pas disponible à l’endroit où la majorité des gens vont la chercher. Mon hypothèse est basée sur ma propre expérience, à savoir que si je veux connaître le fonctionnement d’un outil en ligne de commande, je vais vérifier sa page man.

Comment je m’en suis aperçu ? Les utilisateurs m’écrivaient pour me poser des questions dont les réponses se trouvaient dans la FAQ. Ce qui m’a ennuyé : ils ne lisaient pas ma FAQ. Il se trouve qu’ils avaient cherché sur le site internet, mais je n’avais pas mis la FAQ à cet endroit. C’est une erreur facile à faire. Je suis proche du projet et je n’ai jamais eu besoin d’utiliser moi-même la FAQ, je n’avais donc pas remarqué qu’elle n’était pas présente en ligne. Beaucoup de problèmes sont dus à ce piège : les auteurs ne se mettent pas à la place des utilisateurs.

3. La documentation disponible uniquement en ligne

Le revers de ce problème est d’avoir la documentation disponible uniquement en ligne. Certains projets ne distribuent pas la documentation avec les livrables du projet, ou incluent une version médiocre de la documentation.

Le moteur de recherche Solr, par exemple, a un excellent wiki qui sert à la documentation du projet. Malheureusement, la documentation liée au téléchargement comporte 2200 pages de Javadoc d’API auto-générées. Au final, la seule documentation pour l’utilisateur est une unique page de tutoriel.

Le langage PHP n’est distribué avec aucune documentation. Si vous voulez la documentation, vous devez aller sur une page séparée pour les obtenir. Pire, seule la documentation du cœur est disponible au téléchargement, sans les annotations utiles des utilisateurs (voir « Ne pas accepter les remarques des utilisateurs » plus bas), et ce n’est pas le même format facile à parcourir que celui qui est disponible en ligne.

Les projets open source ne peuvent pas supposer que les utilisateurs ont accès à Internet quand ils ont besoin de la documentation. Le mode avion existe toujours. De toute façon, vous ne souhaitez pas que l’utilisateur dépende uniquement du fait que votre site web est disponible ou non. Au moins à deux reprises durant les derniers mois, le wiki de Solr était indisponible au beau milieu de ma journée de travail alors que je recherchais des informations sur un problème de configuration épineux.

Un projet qui fait les choses bien est Perl et son dépôt de module CPAN. La documentation pour chaque module est disponible soit à search.cpan.org ou metacpan.org dans un format hypertexte facile à lire. Pour la consultation hors-ligne, la documentation de chaque module est intégrée dans le code lui-même, et quand le module est installé sur le système d’un utilisateur, la documentation locale est créée sous forme de pages man. Les utilisateurs peuvent aussi utiliser « perldoc Module::Name » pour obtenir la documentation depuis le shell. En ligne ou hors-ligne : c’est votre choix.

4. La documentation non installée avec le paquet

Ce problème est généralement une erreur des paquageurs, pas des auteurs du projet. Par exemple, sur Ubuntu Linux, la documentation du langage Perl est séparée, ce sont des paquets optionnels pour le langage lui-même. L’utilisateur doit savoir qu’il doit explicitement installer la documentation de la même façon que le langage principal ou il n’y aura pas accès quand il en aura besoin. Ce compromis de quelques mégabites d’espace disque au détriment de la documentation à portée de main de l’utilisateur dessert tout le monde.

5. Le manque de captures d’écran

Il n’y a pas de meilleur moyen d’obtenir l’attention potentielle d’un utilisateur, ou d’illustrer un usage correct, qu’avec des captures d’écran judicieuses. Une image vaut mieux qu’un long discours, c’est encore plus important sur Internet parce que vous ne pouvez obtenir d’un lecteur de lire plus de quelques centaines de mots en tout.

Les captures d’écran accompagnant le texte sont inestimables pour guider l’utilisateur voulant faire les choses au mieux. Une capture d’écran lui permet de comparer visuellement ses résultats à ceux de la documentation et va le rassurer d’avoir exécutée la tâche correctement ou l’aidera à trouver facilement ce qui ne va pas.

Il est de plus en plus commun de trouver des vidéos sur le site internet d’un projet pour en donner un aperçu, et c’est génial. Tout autant que le fait d’avoir une vidéo pour chaque étape d’un processus complexe. Le projet Plone, par exemple, a un site entier dédié aux tutoriels vidéos. Cependant, les vidéos ne peuvent pas remplacer les captures d’écran. Un utilisateur veut voir rapidement l’allure des captures d’écran sans s’arrêter devant une vidéo. Les vidéos n’apparaissent également pas dans une recherche Google Image, à l’inverse des captures d’écran.

6. Le manque d’exemples réalistes

Pour les projets basés sur du code, l’analogue des captures d’écran sont de bons et solides exemples du code en action. Ces exemples ne devraient pas être abstraits, mais directement issus du monde réel. Ne créez pas d’exemples bateaux plein de « nom de la démo ici » et lorem ipsum. Prenez le temps de créer des exemples signifiants avec une histoire d’utilisateur qui représente la façon dont votre logiciel résout un problème.

Il y a de bonnes raisons de vous embêter avec des problèmes de maths en classe. Ils permettent d’appliquer ce que vous avez appris.

Disons que j’ai écrit un module d’un robot Web, et que j’explique la méthode follow_link. Je pourrais montrer la définition de la méthode ainsi :

$mech->follow_link( text_regex => $regex_object, n => $link_index );

Mais admirez à quel point cela devient évident en ajoutant de la réalité dans l’exemple.

# Suit le 2e lien où la chaîne de caractères « download » apparait
$mech->follow_link( text_regex => qr/download/, n => 2 );

Les noms des variables $regex_object et $link_index sont maintenant compréhensibles par le lecteur.

Bien entendu, vos exemples ne doivent pas être aussi brefs. Comme Rich Bowen du projet Apache le souligne, « Un exemple correct, fonctionnel, testé et commenté l’emporte sur une page de prose, à chaque fois. »

Montrez autant que possible. L’espace n’est pas cher. Créez une section dédiée aux exemples dans la documentation, ou même un livre de cuisine. Demandez aux utilisateurs d’envoyer du code qui fonctionne, et publiez leurs meilleurs exemples.

7. Liens et références inadéquats

Vous avez les hyperliens. Utilisez-les.

Ne pensez pas, parce que quelque chose est expliquée dans une certaine partie de la documentation, que le lecteur a déjà lu cette partie, ou bien qu’il sait où elle se trouve. Ne vous contentez pas de signaler que cette partie du code manipule des objets frobbitz. Expliquez brièvement lors du premier usage de ce terme ce qu’est un objet frobbitz, ou donnez le lien vers la section du manuel l’expliquant. Encore mieux, faites les deux !

8. Oublier les nouveaux utilisateurs

Il arrive trop souvent que l’écriture de la documentation soit rédigée à partir du point de vue de son auteur, alors que es nouveaux utilisateurs ont besoin de documentation d’introduction pour les aider.

L’introduction devrait être une page séparée de la documentation, idéalement avec des exemples qui permettent à l’utilisateur de réussir quelques manipulations avec le logiciel. Pensez à l’excitation que vous ressentez quand vous commencez à jouer avec un nouveau logiciel et qu’il vous permet de faire quelque chose de cool. Faites que ça arrive aux nouveaux utilisateurs également.

Par exemple, un package graphique pourrait présenter une série de captures d’écran qui montrent comment ajouter des données dans un fichier, comment faire intervenir le grapheur, et ensuite montrer les graphes obtenus. Une bibliothèque de codes pourrait montrer quelques exemples d’appels à la bibliothèque, et montrer le résultat obtenu. Pensez simplicité. Offrez une victoire facile. Le texte devrait introduire les termes aux endroits appropriés, avec des liens vers une documentation plus détaillée sur le long terme.

Un document de démarrage séparé donne à l’utilisateur une compréhension rapide du logiciel. Il garde aussi les explications d’introduction en dehors de la partie principale de votre documentation.

9. Ne pas écouter les utilisateurs

Les développeurs doivent écouter les utilisateurs de la documentation. La chose évidente est d’écouter les suggestions et requêtes des personne qui utilisent activement votre logiciel. Quand un utilisateur prend le temps d’écrire un mail ou de poster quelque chose comme « ça aurait pu m’aider à mieux installer le programme s’il y avait eu une explication ou des liens au sujet des pilotes de la base de données », prenez ce message au sérieux. Pour chaque utilisateur vous envoyant un mail pour un problème, vous devez vous attendre à ce que dix utilisateurs silencieux aient le même problème.

Il est important d’écouter les problèmes des utilisateurs et d’en chercher les causes. S’ils ont souvent des problèmes pour effectuer des mises à jour groupées de bases de données, la première chose à faire est d’ajouter une question à la FAQ (vous avez bien une FAQ, n’est-ce pas ?) qui traite de ces questions-là. Cependant, la question peut aussi indiquer que la section traitant des mises à jour de base de données n’est pas assez claire. Ou peut-être qu’il n’y a pas de référence à cette section depuis la vue d’ensemble introductive du document, avec pour conséquence que vos utilisateurs ne pensent jamais à lire le reste du manuel.

En plus d’aider plus de gens à découvrir à quel point votre projet est utile, ça diminuera aussi la frustration de la communauté déjà existante. Si votre liste de diffusion, forum ou canal IRC est remplie de personnes qui posent toutes les mêmes questions idiotes (ou pas si idiotes) au point que tout le monde devient lassé d’y répondre, sachez reconnaître que ce sont des questions récurrents pour la FAQ, et mettre les réponses à un endroit facile à trouver aidera tout le monde à se concentrer sur des choses plus amusantes.

Gardez aussi un œil sur les questions des forums externes. Consultez les sites comme StackOverflow régulièrement, et placez une Google Alert sur votre nom de projet pour être maintenu au courant des discussions concernant votre projet sur Internet.

10. Ne pas accepter les entrées des utilisateurs

Si votre projet a une base d’utilisateur assez grande, il peut être judicieux d’incorporer les commentaires des utilisateurs directement dans la documentation. Le meilleur exemple que j’ai pu voir est celui donné par PHP. Chaque page de la documentation permet aux utilisateurs authentifiés d’ajouter des commentaires sur la page, aidant ainsi à clarifier certains points ou ajoutant des exemples qui ne sont pas dans la documentation principale. L’équipe PHP laisse aussi le choix au lecteur de lire la doc avec ou sans les commentaires des autres utilisateurs.

Aussi pratique cela soit-il, cela nécessite de la maintenance. Les commentaires doivent être éliminés de temps en temps pour éviter la prolifération. Par exemple, la page de la documentation PHP sur comment lancer PHP depuis la ligne de commande inclut 43 commentaires d’utilisateurs qui remontent à 2001. Les commentaires écrasent la documentation principale. Les commentaires devraient être archivés ou supprimés, tout en incluant les points les plus importants dans la documentation principale.

Un wiki est également une bonne approche. Cependant, si votre wiki ne permet pas à l’utilisateur de télécharger toutes les pages en une seule grosse archive (cs. point n°3 ci-dessus), alors vos utilisateurs sont à la merci de votre connexion internet et du serveur hébergeant le projet.

11. Impossibilité de voir ce que fait le logiciel sans l’installer

Au minimum, chaque projet de logiciel nécessite une liste de fonctionnalités et une page de captures d’écran pour permettre au potentiel utilisateur intéressé de savoir pourquoi il devrait l’essayer. Aidez l’utilisateur, comparant les différents paquets à utiliser, à voir pourquoi cela vaut la peine de prendre le temps de le télécharger et de l’installer.

Les images sont un bon moyen de faire cela. Votre projet devrait avoir une page « Captures d’écran » qui montre des exemples de l’outil en action (cf. point n°5 ci-dessus). Si votre projet se résume uniquement à du code, comme une librairie, alors il devrait y avoir une page d’exemples montrant ce code utilisant le projet.

12. S’appuyer sur la technologie pour votre rédaction

Trop souvent, les auteurs de logiciels utilisent des systèmes de documentation automatisés pour faire leur travail. Ce système automatisé rend les choses plus facile à maintenir, mais il ne supprime pas la nécessité d’un travail d’écriture humain.

Le pire des cas concerne le changelog, qui n’est rien de plus qu’un dump des messages de commit du système de gestion de version, mais sans un résumé qui l’explique. Un changelog devrait lister les nouvelles fonctionnalités, les problèmes résolus et les incompatibilités potentielles. Sa cible est l’utilisateur final. Un log de commit est pratique et simple à générer pour les personnes travaillant sur le projet, mais ce n’est pas ce dont l’utilisateur a besoin.

Jetez un œil à cette page de la documentation de Solarium, une interface PHP pour le moteur de recherche Solr. Tout d’abord, l’avertisemment prend la moitié supérieure de l’écran, ne donnant aucune information au lecteur. Ensuite, il n’y a vraiment rien de véritablement descriptif sur la page que la liste des noms de fonctions. Il n’y a aucune explication sur les différentes méthodes, ni de liens indiquant où trouver l’explication. Les pages générées automatiquement sont jolies, et elles pourraient ressembler à de la documentation, mais elles n’en sont pas.

13. Arrogance et hostilité vis-à-vis de l’utilisateur

L’attitude du type RTFM (Read The Freaking Manual) est mauvaise pour votre projet et votre documentation.

C’est le summum de l’arrogance que de croire que tous les problèmes qui ont trait au fait que quelqu’un ne sache pas utiliser votre logiciel sont de la faute de l’utilisateur.

Même s’il est probablement vrai que les utilisateurs peuvent trouver leurs réponses dans votre documentation mais ne le font pas, il est stupide de penser que c’est la faute de l’utilisateur. Peut-être votre documentation est-elle mal écrite, ou difficile à lire, ou présente mal à l’écran. Peut-être avez-vous besoin d’améliorer la section « Mise en route » (lien #8 ci-dessus) qui explique ce que le logiciel a pour but de faire. Peut-être que certaines parties d’information nécessitent d’être répétées à de multiples endroits de la documentation.

N’oubliez pas que les nouveaux utilisateurs de votre logiciel peuvent arriver sur votre projet sans rien n’en savoir. Votre documentation doit faire de son mieux pour s’assurer que cette ignorance soit facilement résolue.

Synthèse

Je suis sûr que vous avez déjà eu affaire à quelques-uns de ces problèmes listés ci-dessous, et peut-être que pour d’autres vous n’y avez pas pensé. Faites-nous connaître les problèmes que vous avez rencontrés dans les commentaires ci-dessous, sachant qu’il ne s’agit pas de pointer du doigt certains projets en particulier.

Surtout, j’espère que si vous reconnaissez un problème dans la documentation de vos projets, vous prendrez la peine d’améliorer la situation. Heureusement, améliorer la documentation est une manière idéale de faire participer les nouveaux arrivants dans votre projet. On me demande souvent : « Comment puis-je commencer dans l’open source », et je recommande des améliorations dans la documentation comme une bonne manière de commencer.

Faites-en sorte que ce soit aussi facile que possible, pour les novices comme les plus anciens, de savoir où il est nécessaire de travailler la documentation. Créez une liste des tâches, par exemple dans votre système de suivi des bogues, qui explique ce qui a besoin d’être amélioré. Soyez précis dans ce que sont vos besoins. Ne vous contentez pas de dire que vous avez besoin d’exemples, sans plus de précision. Créez des tâches spécifiques, comme « ajoutez un code d’exemple sur le fonctionnement de la tâche X », « ajouter une capture d’écran du générateur de rapports » ou « ajouter des informations de dépendances au fichier README/LISEZ-MOI ». Les contributeurs souhaitent aider mais trop souvent ils ne savent pas par où commencer.

La documentation n’est pas la partie la plus glamour d’un projet open source, et pour la plupart d’entre nous ce n’est pas amusant. Mais sans une bonne documentation, les utilisateurs ne sont pas servis comme ils pourraient l’être, et votre projet en souffrira sur le long terme.

Crédit photo : Rosalux Stiftung (Creative Commons By)

Vous connaissiez la suite bureautique libre Joeffice ?

Nous, non ! Et quand nous avons appris qu’elle avait été conçue en 30 jours par un développeur (qui plus est français), nous avons évidemment eu envie d’en savoir plus…

Bonjour Anthony, peux-tu te présenter succinctement ? Quel a été ton parcours de développeur ?

Bonjour, je m’appelle Anthony Goubard, j’ai 40 ans et j’habite à Amsterdam. J’ai commencé Java durant ma dernière année d’ingénieur avec la version 1.0 alpha puis j’ai fait du détachement sur la région parisienne. Il y a 14 ans je suis allé travailler pour une start-up aux Pays-Bas puis pour Wanadoo Pays-Bas et il y a 5 ans je me suis mis à mon compte.

Alors Joeffice c’est quoi exactement ? Comment et pourquoi est né le projet ?

Joeffice est une suite bureautique open source écrite en Java. L’idée m’est venue il y a environ 2 ans lorsque je me suis aperçu que c’était galère d’avoir 10 documents d’ouverts avec Microsoft Office ou Libre Office alors que ce n’est pas un problème d’avoir 30 documents ouverts dans Eclipse ou NetBeans.

Dans quel sens évoques-tu une version « online » et « offline » ?

Les logiciels Java peuvent être installés sur un ordinateur comme un logiciel classique ou bien être lancé en ligne dans le navigateur avec l’aide du plugin Java. C’est ce qu’on appelle le mode Applet. Il suffit donc d’aller à l’URL et le logiciel s’installe et se lance dans le navigateur automatiquement. J’ai donc décidé d’offrir les deux possibilités. La version « online » est soumise à un abonnement.

Pourquoi le choix Java ?

Java offre beaucoup d’avantages. Il est portable sur plusieurs OS, il est relativement facile à lire, beaucoup d’étudiants apprennent Java et il est très utilisé dans le monde de l’entreprise. Beaucoup de projets open source utilisent Java. Joeffice offre aux étudiants et développeurs Java la possibilité de travailler sur un projet assez visuel et utile.

Pourquoi le choix de la licence libre ?

L’union fait la force.Tous les développeurs Java que je connais se servent de temps en temps d’une suite bureautique. Avoir un projet bien mené par un grand groupe de contributeurs permettra à long terme de créer un bien meilleur logiciel qu’avec une petite équipe. En plus, beaucoup d’entreprises et de pays en voix de développement sont attirés par l’open source et mon but est de toucher le plus de personnes possible.. Le premier groupe d’utilisateurs pour Joeffice est donc l’entreprise. Dans ce cas la licence Apache 2.0 donne beaucoup de liberté, plus que GPL et LGPL. Cette licence est par exemple utilisée pour le framework Spring.

Comment se positionne Joeffice, aujourd’hui et demain, par rapport à des « monstres » comme Google Docs, Microsoft Office ou LibreOffice ?

Joeffice est moins complet que ces autres offices mais il a aussi des atouts que d’autres n’ont pas. Il est donc open source sous licence Apache. Il est développé entièrement en Java. Il peut s’installer « offline » ou « online ». Il est facilement portable. Il n’a pas une fenêtre par document mais un système d’onglet et d’amarrage ou les documents peuvent être l’un à côté de l’autre ou détachés en groupe. Les mises à jour et plugins, même si pour l’instant non utilisés, peuvent se faire en ligne. Toutes les librairies Java peuvent être facilement utilisées pour créer des actions spéciales, afin par exemple de remplir un document.

La légende dit que tu l’aurais codé tout seul en moins d’un mois ? La légende dit vrai ?

Je l’ai codé en 30 jours. Mais ce sont 30 jours non consécutifs. Pour chaque journée j’ai fait une vidéo que j’ai postée sur YouTube. Il a fallu que je sois efficace sur le code et pragmatique sur certains choix.

En France, on vient d’introduire cette année l’informatique comme discipline à part entière au lycée (pour le moment en option de Terminale S). Bonne ou mauvaise idée ?

Bien sûr, je trouve ça une bonne idée. Même en n’étant pas informaticien, les gens ont de plus en plus besoin de savoir développer. Par exemple un plug-in, une macro ou un site Web.

Joeffice se présente en version alpha. Que lui manque-t-il exactement pour une première version ?

Je me sers de la librairie open source Apache POI pour lire les documents malheureusement il manque encore certaines parties. Chaque partie du logiciel doit être améliorée pour avoir quelque chose de plus utilisable pour l’utilisateur final. Cette version alpha est plus destinée aux développeurs et aux entreprises qui ont des besoins spécifiques. Le but pour la version 1.0 est de s’approcher de ce que peut faire Google Docs.

Et comment vois-tu le futur du projet ? Un appel à lancer ?

Tous les développeurs qui veulent participer à ce projet ou à une des librairies dont Joeffice se sert sont les bienvenus. Le code se trouve sur BitBucket.

Edit : en fait c’était un bug (mais un bug troublant quand même). Fausse alerte donc, le contenu du billet ci-dessous n’est plus pertinent.

Quand on saute d’une version 5.5.30 à la 5.5.31, il ne se passe généralement pas grand chose mis à part quelques bugs fixés.

Sauf qu’ici on a décidé en catimini de changer la licence des pages man de MySQL et ce n’est pas très fair-play de la part de son propriétaire Oracle.

Heureusement qu’on a le fork MariaDB, d’où est d’ailleurs issue cette traduction.

Les pages man de MySQL changent discrètement de licence pour ne plus être sous GPL

MySQL man pages silently relicensed away from GPL

Colin Charles – 18 juin 2013 – MariaDB Blog
(Traduction : Lgodard, ehsavoie, Asta, rou, BastienLQ)

On nous a récemment rapporté que la licence des pages man de MySQL a été modifiée. Le changement a été fait en douce lors du passage de MySQL 5.5.30 à MySQL 5.5.31. Cela affecte toutes les pages du répertoire man/ du code source.

On peut voir que ces changements sont intervenus durant cette courte période (5.5.30->5.5.31). Les anciennes pages du manuel étaient publiées sous la licence suivante :

Cette documentation est un logiciel libre : vous pouvez la redistribuer et/ou la modifier uniquement sous les termes de la licence GNU GPLv2 telle que publiée par la Free Software Foundation.

Les nouvelles pages man (5.5.31 et ultérieures — toujours en vigueur pour 5.5.32) sont sous la licence suivante :

Ce logiciel et la documentation rattachée sont soumis à un accord de licence contenant des restrictions sur leur utilisation et leur divulgation et sont protégés par les lois sur la propriété intellectuelle. Sauf autorisation expresse dans cet accord de licence ou par la loi, vous ne pouvez pas utiliser, copier, reproduire, traduire, diffuser, modifier, changer de licence, transmettre, distribuer, exposer, publier ou montrer une quelconque partie, quelque soit sa forme ou les moyens utilisés. Il est interdit de faire de la rétroingénierie, désassembler ou décompiler ce logiciel, sauf si la loi le requiert pour l’interopérabilité…

Ce n’est clairement pas une marque d’affection pour MySQL de la part d’Oracle. La nouvelle licence est également devenue bien plus longue (en clair ce n’est pas sous licence GPL). Tandis que ce qui suit a été récupéré de l’outil resolveip, le copyright est le même pour toutes les pages man. Vous pouvez comparer la page man de la version 5.5.30 et celle de la version 5.5.31.

Vibrante allocution en faveur du logiciel libre, la ministre Fleur Pellerin a prononcé un discours remarqué lors de l’inauguration des nouveaux locaux Mozilla le 13 juin dernier à Paris.

Ira-t-on plus loin que ses belles paroles ? Seront-elles véritablement suivies de faits et d’effets ?

Une vidéo tournée par Roberto Di Cosmo. et éditée par Stéfane Fermigier

Transcript

(Merci à Goofy, aKa, Z, Asta, Peekmo)

Madame la présidente, chère Mitchell, madame la vice-présidente, chère Debbie,

Mesdames et messieurs, il y a vingt ans un grand chercheur a, je le cite, « pris le principe d’hypertexte et l’a relié au principe du TCP et du DNS, et alors boom, ce fut le World Wide Web. »

Et en 1993, donc, le CERN, cet organisme de recherche européen qui avait inventé le Web a décidé de donner cette invention au monde, en la distribuant sous ce qu’on n’appelait pas encore une « licence libre ». Ce choix, anodin en apparence, a changé la face du monde.

Il y a 10 ans, la fondation Mozilla naissait et quelques mois plus tard, cher Tristan Nitot, vous fondiez sa branche européenne. J’imagine combien cela doit vous faire plaisir d’être ici 10 ans après, dans ce magnifique hôtel particulier du XVIII^e siècle, ancienne demeure de l’ambassadeur d’Autriche, m’avez-vous dit tout à l’heure. Mozilla Firefox, construit sur l’ancien Netscape, et œuvrant inlassablement pour promouvoir les standards du Web, a aussi changé le Web et par là la manière dont nous nous informons et dont nous innovons.

Je suis donc très fière d’inaugurer ce soir les nouveaux bureaux de la fondation Mozilla à Paris. Pourquoi être venue inaugurer ces nouveaux locaux ?

D’abord en raison des valeurs de la fondation Mozilla, et du logiciel libre. Ces valeurs, ce sont l’accès à la connaissance pour tous, la confiance ou encore l’amplification des aspects d’intérêt publics d’internet. Ce sont aussi les valeurs sociales qui portent un modèle de société vertueux, ouvert, participatif, où toute donnée est d’abord considérée comme un bien accessible au plus grand nombre, et une source de connaissances que chacun peut utiliser, améliorer, partager. Le logiciel libre, les formats ouverts, c’est enfin une communauté de personnes qui constitue un véritable patrimoine de connaissances qu’est le code, sans cesse inachevé, toujours à enrichir. Au-delà des innovations et des technologies permises par le Web, des acteurs comme Wikimedia ou la fondation Mozilla ont démontré que l’innovation et le progrès peuvent aussi passer par le partage, l’absence de propriété. C’est une victoire essentielle sur les esprits qui nous permet aujourd’hui d’avancer dans d’autres domaines : je pense à l’open innovation ou à l’open data. Je sais que Mozilla n’est pas une formation politique, mais toutes ces valeurs résonnent particulièrement doux à une ministre de gauche comme moi, et je pense que le monde politique a des choses à apprendre de cette réussite.

Par ailleurs le logiciel libre est aussi un atout décisif pour notre économie. À plus d’un titre il permet d’abord de lutter contre les phénomènes de dépendance technologique envers tous ces acteurs qui sont propriétaires de nos outils informatiques quotidiens, et est donc un véritable garant de la souveraineté numérique. De plus comme on le voit aujourd’hui, et contrairement à certaines idées reçues, le libre et l’open source sont créateurs d’emploi. Des modèles d’affaire originaux ont été créés et c’est un facteur important de productivité et de compétitivité pour les entreprises et les administrations. En effet elles peuvent ainsi mieux maîtriser leurs patrimoines respectifs et concentrer leurs efforts sur ce qui représente pour elles la valeur ajoutée. Enfin le logiciel libre remet en cause les rentes de situation, peu favorables à l’innovation, et par là-même aide à l’émergence de nouveaux champions économiques. L’émergence de Firefox et des navigateurs est emblématique de cette capacité.

La France est souvent citée comme un des pays les plus actifs au monde dans le domaine du logiciel libre. La croissance soutenue dans ce secteur le confirme. Les chiffres sont éloquents : ce marché représentait en 2011 plus de 2 milliards d’euros, soit plus de 6% de la demande de logiciels et de services informatiques. Par ailleurs, il y a là un formidable levier d’emplois, environ 10 000 supplémentaires dans les 3 ans à venir, si les estimations de croissance du marché sont confirmées. Bref, ce sont des enjeux extrêmement importants. La décision de Mozilla, un acteur mondial de référence sur le logiciel libre, de s’implanter dans ces locaux, confirme l’attractivité de Paris comme place incontournable du numérique. Elle confirme l’excellence des formations françaises dans le domaine informatique et je suis certaine que les développeurs du monde entier seront attirés par les conditions d’accueil ici, dans ces magnifiques locaux.

Mon objectif est bien sûr de renforcer encore ces atouts avec notamment le projet de quartiers numériques que nous allons créer dans une quinzaine de villes. Enfin, nous avons en France une communauté parmi les plus dynamiques dans le monde pour la conception et l’utilisation des logiciels libres, un atout à évidemment ne pas négliger. Avec les Assises de l’Entreprenariat, nous avons souhaité aller encore plus loin pour renforcer notre attractivité en mobilisant notamment toutes les compétences de France et d’ailleurs. C’est pour accompagner ce mouvement que le gouvernement travaille ardemment à la création d’un visa entrepreneur et d’un visa talent, car il est impératif d’attirer les talents créateurs du monde entier en leur offrant des conditions d’installation très rapides et simplifiées. Je dois aussi rappeler que le gouvernement prête une attention toute particulière à l’utilisation des logiciels libres. Par notre action nous visons à la renforcer. Le recours au logiciel libre est un levier d’action pour moderniser et rationaliser l’action publique.

Le Libre n’est pas toujours la bonne ou la seule solution mais la circulaire du Premier Ministre de septembre 2012 concernant l’utilisation des logiciels libres dans l’administration fixe une ligne claire sur les cas où ces types de logiciels doivent être privilégiés. Les atouts du logiciel libre sont notamment, je cite, « un moindre coût, une souplesse d’utilisation, et un levier de discussion avec les éditeurs ». Il s’agit là d’une avancée majeure pour le logiciel libre dans les systèmes d’information de l’État, qui permet d’engager de véritables politiques publiques en matière de logiciel libre et d’open source.

Pour conclure, je voudrais juste insister sur un point important que j’ai déjà évoqué mais que je tiens à marteler : l’open source est avant tout un vecteur d’innovation et de changement, un véritable gisement de productivité et de compétitivité pour les entreprises, et garantit la pérennité et l’indépendance de l’État. C’est pour cela que je souhaite que la France continue de jouer un rôle moteur dans le développement de ce secteur, et je suis sûre que la présence de Mozilla à Paris nous y aidera. J’ai parlé de 1993, de 2003, quoi de neuf en 2013 ? Cette année Mozilla lance son système d’exploitation pour mobiles et tablettes, Firefox OS, sur le même constat : promouvoir les formats ouverts et empêcher les systèmes fermés de contrôler notre environnement informatique. C’est une ambition un peu folle, mais probablement pas plus folle que de s’attaquer au marché des navigateurs qui était contrôlé à 95% par un seul acteur. Je vous souhaite donc le même succès que Firefox, et comme il sera en partie développé ici, je n’ai pas de doute sur la réussite de ce projet. Merci à tous.

Ce n’est pas Framasoft qui vous dira le contraire, on peut contribuer au logiciel libre et faire ainsi partie de sa communauté sans être nécessairement un développeur de logiciel libre.

Rédiger de la documentation, signaler un bug, traduire, donner, etc. il y a plein de manières de participer, à commencer par les utiliser et le faire savoir.

Comment les non-programmeurs peuvent contribuer aux projets open source

How non-programmers can contribute to open source projects

Duncan McKean – 4 juin 2013 – Blog personnel
(Traduction : « Anonymes », nos excuses car un bug Framapad empêche de citer tous les traducteurs/ices que nous remercions au passage)

Beaucoup de gens intéressés par l’idée d’apporter leur aide à des projets open source mais n’ayant absolument aucune compétence en programmation m’ont demandé ce qu’ils pouvaient faire. Eh bien, voici quelques moyens pour ces non-programmeurs de contribuer à de tels projets.

Il est important de noter qu’il est bon de contribuer aux projets des logiciels que vous utilisez. Ainsi, vous pourrez vous-même bénéficier de vos contributions.

Utilisez le logiciel

Le meilleur moyen de contribuer à des projets open source est d’utiliser les produits eux-mêmes. Écrivez votre livre avec Libre Office Writer. Dessinez vos images avec Krita. Créez des choses à imprimer en 3D avec FreeCAD ou Blender. Réservez vos tickets de concert en ligne via Firefox. Faites vos comptes avec Grisbi. Jouez à Flightgear, Battle for Wesnoth, Vega Strike, UFO : Alien Invasion.

Traquez les bugs

Maintenant que vous utilisez le logiciel, vous pouvez éventuellement rencontrer des bugs quand vous essayez de faire quelque chose. Ou alors, le logiciel peut avoir un comportement autre que celui qui était attendu.

Entrez en contact avec les développeurs et prévenez-les. Les développeurs travaillent sur les retours de leurs utilisateurs, ceci les aide à perfectionner le produit. De plus, les sources étant libres, les bugs sont en général rapidement corrigés.

Chaque projet aura un lien pour signaler un bug. Allez-y, identifiez-vous et décrivez ce bug dans les détails. N’oubliez pas d’indiquer quelle version du logiciel vous utilisez ainsi que les caractéristiques de votre ordinateur.

Écrivez de la documentation

Contribuer à écrire la documentation d’un projet pour le rendre plus clair et plus simple à comprendre.

La plupart du temps, les développeurs sont trop occupés à coder et la documentation a besoin d’un peu d’attention. Vous pouvez la mettre en forme afin qu’elle soit plus claire, ajouter des images ou des tutoriels. Si certaines parties du projet ne sont pas claires, il suffit de demander sur les listes de diffusion. Ainsi, lorsque vous recevrez une réponse, vous pourrez l’ajouter à la documentation. Dès que les personnes qui maintiennent le projet saisiront ce que vous faites, leurs réponses seront encore plus efficaces et utiles.

Traduisez

Il y a beaucoup de personnes dans le monde qui utilisent ce projet et certaines d’entre elles pourraient ne pas parler la langue dans laquelle celui-ci a été distribué. Si vous parlez couramment un langage peu connu, contactez les développeurs/l’équipe de documentation et offrez vos services. Vous pourriez participer à la traduction de l’interface, de la documentation ou encore du site web.

Offrez vos compétences

Regardez les projets individuels et voyez ce dont ils ont besoin. Vous pouvez apporter quelque chose ? Vous êtes designer sonore et pourriez créer quelques sons pour un jeu vidéo open source ? Concepteur d’interface ? Vous pourriez aider en remaniant l’interface utilisateur pour la rendre plus ergonomique. Il est également possible de lancer des entreprises viables utilisant ou formant aux logiciels open source.

Vous pouvez aussi contribuer à la culture du libre en publiant ce que vous créez sous certaines licences Creative Commons. Vos créations peuvent ainsi aider à promouvoir le logiciel pour lequel elles ont été créées. Ceci inclut :

• les images ;
• les programmes ;
• les tutoriels ;
• les manuels d’installation et de documentation ;
• les livres.

Utilisez la licence CC BY-SA pour que chaque réutilisation de votre travail soit elle aussi placée sous licence libre, CC BY si la façon dont il est réutilisé vous importe peu. Vous trouverez plus d’informations à ce sujet sur le site des Creative Commons.

Prêchez la bonne parole

Aider à la prise de conscience des projets open-source est très important. N’agressez pas tout le monde, faites juste savoir quels projets vous utilisez. Créé avec MyPaint sous LinuxMint. Écrit en Sigil sous Ubuntu. Je suis fier d’utiliser WordPress. Toutes ces mentions sont utiles.

Faites des dons

Enfin, leur donner de l’argent. Avec de l’argent, le projet peut embaucher des développeurs supplémentaires qui pourront corriger des bugs plus rapidement, créer de nouveau outils, les améliorer pour vous. Certains projets proposent des dons occasionnels, alors que d’autres vous permettent de payer de petites sommes mensuellement. C’est une meilleure idée car cela aide les développeurs à mieux gérer leurs revenus quand ils savent quelle somme d’argent ils reçoivent de façon sûre.

Soyez professionnel

L’une des principales critiques faites aux logiciels open source est le manque de professionnalisme. Peu importe la manière dont vous contribuez à un projet open source, mettez un point d’honneur à le faire de façon professionnelle. L’élévation du niveau de qualité d’un projet commence avec ses utilisateurs. Assurez-vous que vous agissez de manière professionnelle lorsque vous discutez de projets avec d’autres et créez des contributions de qualité quand vous utilisez des logiciels open source.

Maintenant que vous savez tout ça, lancez-vous et allez aider à rendre les projets open source géniaux.

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

Éric Bruillard est professeur au STEF – ENS Cachan.

L’article ci-dessous reprend une présentation faite le 15 décembre 2012 lors des Rencontres Wikimédia, à l’université Paris Descartes.

Remarque : Vous pouvez également accéder directement à la version ODT et PDF du document.

Wikipédia face aux institutions

Éric Bruillard – décembre 2012

Introduction

Il y a cinq ans, en mars 2007, j’avais écrit un article intitulé « Wikipédia : la rejeter ou la domestiquer ». J’avançais l’idée, qui a souvent été mal comprise, que Wikipédia ne pouvait pas « avoir une présence reconnue dans l’enseignement en France, ses principes mêmes (neutralité) n’étant pas compatibles avec les valeurs de l’école laïque et républicaine française, valeurs qui conduisent à privilégier certains points de vue et à en interdire d’autres ». J’ajoutais que Wikipédia pouvait cependant avoir une place, d’une part comme projet encyclopédique avec des participations actives à ce projet, comme faire écrire des articles à des élèves, et, d’autre part, comme une encyclopédie à laquelle beaucoup auraient recours, dans une posture de consommateur.

Ces deux directions ont été effectivement suivies, et des utilisations constructives sont repérables dans l’enseignement secondaire ou supérieur, quoique la « consommation » est certainement beaucoup plus développée que la participation. Mais Wikipédia aurait-elle maintenant une présence reconnue dans l’éducation ?

Dans un premier temps, nous allons tenter de situer les discours généraux sur Wikipédia, notamment dans l’éducation nationale. Ensuite, nous verrons en quoi Wikipédia est maintenant une véritable institution, statut qui n’est pas sans poser de nouvelles questions. Enfin nous traiterons la question de l’évaluation des articles de cette encyclopédie : une évaluation interne s’est installée alors que l’évaluation externe ne semble pas beaucoup progresser : serait-ce révélateur de relations encore difficiles avec un projet collectif que l’on a toujours du mal à appréhender ?

Wikipédia : quoi de neuf depuis 2007 ?

Le premier constat que l’on peut faire, sans avoir spécialement besoin de l’étayer, est celui de la croissance impressionnante du projet Wikipédia : une présence très importante (notamment via Google), des utilisations qui se multiplient, notamment dans l’éducation, de nouveaux projets associés…

Pourtant, face à ce formidable déploiement, on s’aperçoit, notamment à travers le discours d’étudiants ou d’enseignants, d’une méconnaissance persistante du fonctionnement de Wikipédia, d’idées reçues tenaces, d’utilisations contestées, d’interrogations sur la fiabilité…

Wikipedia nous aide d’ailleurs à cerner ce que qu’est une idée reçue : « une opinion, située entre le stéréotype, le cliché et le lieu commun », précisant qu’elle a « la particularité de s’admettre aisément » parce qu’elle est « très répandue, que celui qui la transmet la considère très souvent comme évidemment démontrée ; elle est agréable à admettre, parce qu’elle répond (le plus souvent simplement) à une question redondante, ou gênante, ou complexe : elle aide à ne plus réfléchir et s’impose insidieusement ». Justement, un peu de réflexion s’impose.

Comme il est possible à n’importe qui de créer ou modifier le contenu d’un article, que ce n’est pas réservé à des spécialistes, il ne semble pas possible qu’il y ait des articles de qualité et on ne peut en aucun cas s’en remettre à Wikipédia. Ce discours de sagesse populaire continue à être très souvent énoncé. Prenons juste un seul exemple : “Wikipedia is a free, web-based, collaborative, multilingual encyclopedia project. Anybody is able to change, add or remove articles on Wikipedia. This of course is prone to many problems as some authors may be: biased, vandalise the article or write incorrect information.”

Les études comparatives qui ont été menées attestent du contraire et l’expérience quotidienne de nombre d’entre nous montre qu’on lui fait malgré tout confiance. Peu d’études nouvelles sont disponibles. La seule étude récente est intitulée Assessing the accuracy and quality of Wikipedia entries compared to popular online encyclopaedias A preliminary comparative study across disciplines in English, Spanish and Arabic. Mais les auteurs remercient la Wikimedia Foundation pour son soutien financier. D’autres institutions ne sont sans doute intéressées à financer une évaluation des articles de Wikipedia, préférant laisser planer le doute et les idées reçues.

Quelle présence officielle dans l’éducation ?

Si la neutralité de l’éducation nationale française l’invite à ne pas citer de marque ou de nom de produit dans ses programmes officiels, sauf exception, elle est conduite à veiller sur ce qui est proposé. Une recherche sur le site officiel Eduscol atteste de la présence de Wikipédia.

On trouve des revues de presse ; un dossier déjà ancien sur les usages pédagogiques ; des recommandations, des définitions issues de Wikipédia, le fait que Wikipedia offre une nouvelle fonctionnalité (l’exportation de pages au format epub, ce qui permet de constituer une sélection d’articles à consulter hors ligne sur une liseuse ou sur smartphone).

On trouve également référence à Wikipedia dans des sujets de bac, des ressources pour la résolution de problèmes, des dossiers pédagogiques… mais avec le plus souvent des modes de citation approximatifs (cf page 2 de ce document). Dans les ressources pour la classe terminale générale et technologique, Physique-chimie, Série S (Eduscol), on trouve 10 références à Wikipédia.

Ce bref tour d’horizon nous en apprend plus sur le système éducatif que sur Wikipédia. Cette dernière apparaît pratique et très utile, mais demeure un motif récurrent de complaintes, attestant des difficultés (ou de l’incapacité ?) du système éducatif à traiter les évolutions en cours sur les savoirs, leur diffusion, leur mise en question… Une utilisation parfois « honteuse », que l’on peut rapprocher des usages des calculatrices en collège il y a quelques années^[1] : une sur utilisation, une maîtrise très diversifiée et un manque de formation des élèves. Au début du collège, utiliser la calculatrice est considéré comme une tricherie, il ne faudrait s’en servir que pour contrôler les résultats des opérations que l’on fait à la main. Mais dès la 4e, la tricherie est quelque sorte légalisée, notamment avec les fonctions trigonométriques, et ceux qui ont acquis une bonne maîtrise des calculatrices, sont alors avantagés. Le système éducatif prend peu en charge, voire pas du tout, la formation des élèves à cette maîtrise.

Wikipédia dans le site Eduscol – 10 décembre 2012

Les objets informatiques spécifiques du système éducatif ne sont pas bien traités par Wikipédia. Ainsi, l’article ENT est encore une ébauche de piètre qualité. On retrouve une même ébauche, non signalée comme telle, sur l’expression « manuel numérique », page modifiée pour la dernière fois le 28 juin 2010^[2]. C’est une version quasi « ministérielle » qui est proposée, la page « discussion » n’est pas ouverte et aucun article dans une autre langue n’est associé. Ce n’est toutefois par mieux en anglais où l’article “digital textbook” est une présentation du programme de ministère de l’éducation de Corée du Sud ! Les exemples sont coréens, avec des liens vers Toshiba et Fujitsu. Il s’agit d’un article sur le projet coréen, et pas sur l’initiative californienne par exemple.

Enfin, pour clore ce rapide tour d’horizon, un site de l’académie de Montpellier propose de « créer un manuel numérique à l’aide de Wikipédia ». Il est écrit : « Wikipédia est une excellente ressource pour construire un livre numérique dans le but d’explorer un sujet ou d’entamer une recherche documentaire. Pour inciter les étudiants à utiliser Wikipédia comme outil de départ plutôt que comme finalité d’une recherche, un enseignant peut facilement fournir à ses étudiants une collection d’articles de références sous la forme d’un livre numérique. Retrouvez les différentes étapes de création d’un livre numérique dans un mode opératoire mis à disposition sur le site “Prof Web”. »

Si on clique sur l’adresse indiquée, on retrouve le même paragraphe à la virgule près, puis un petit mode d’emploi. Tous les éléments sont présents : citation et même copié-collé. Un exemple mais avec la parapluie de la bonne pratique (il faut utiliser simplement comme point de départ). On se sert de Wikipedia mais d’une manière non risquée !!! On ne cherche pas à comprendre, mais à trouver une pratique que l’on considère légitime et que les autres ne pourront pas contester.

Cette méfiance persistante sur un projet maintenant très établi ne cache-t-elle pas des caractéristiques encore mal connues ou mal comprises. Et Wikipedia, s’il est encore regardé de travers par les institutions, ne serait-il pas aussi une institution ?

Wikipédia est une institution

En effet, pour la recherche, une simple interrogation sur Wikipedia dans Google Scholar produit de très nombreux résultats ; depuis 2011 : 45 700 résultats ; depuis 2012 : 23 100 résultats (à titre de comparaison, on obtient pour les mêmes dates concernant Britannica : 13100 / 7320). Dans les travaux auxquels on accède, il y a des études sur le fonctionnement même de Wikipédia : contenus, conflits, participation, etc. ; des outils pour Wikipédia.

Issus de son fonctionnement même, l’encyclopédie fournit des corpus très utiles pour les linguistes, notamment les paraphrases et modifications locales dans l’historique des révisions des articles, conduisant à améliorer les performances d’applications de TAL : traduction automatique, question-réponse, génération…

Encore plus intéressant, dans un processus d’institutionnalisation de Wikipédia, le projet Semanticpedia associe le ministère de la culture, l’INRIA et Wikimedia France. Cette collaboration vise à « réaliser des programmes de recherche et développement appliqués à des corpus ou des projets collaboratifs culturels, utilisant des données extraites des projets Wikimédia ». Il s’agit notamment de fournir des données culturelles accessibles à tous, dans une version Web sémantique structurée ; en gros devenir la référence pour la culture avec des modes d’interrogation très avancés dans des formes de déclaration sémantique.

Wikipédia est même vu comme un nouvel outil d’évaluation : une évaluation de la réputation ponctuelle, la fréquentation de Wikipédia étant considéré comme outil de mesure ; mais aussi, l’influence qu’une personne a sur un pays ou même sur une civilisation, qui pourrait être mesurée en fonction des liens menant à sa page Wikipédia.

Ainsi, Wikipédia est devenu outil de référence, même s’il s’en défend. C’est déjà un attracteur très puissant pour les recherches et, selon Kien Quach Tat^[3] (2011), au Vietnam, Wikipédia est ce qui permet aux lycéens de valider une information trouvée sur un autre site.

Quelle implication du fait que Wikipédia est une institution ? Peut-on être en dehors de Wikipédia ? Comme elle devient la référence, peut-on continuer à l’ignorer, si une information nous concernant est fausse, peut-on encore traiter cela par le mépris ou l’absence de réaction n’est pas une sorte d’acquiescement ? En tous cas, si Wikipedia gère très efficacement les vandalismes, on sait qu’elle est mal armée pour lutter contre des organisations qui cherchent à imposer leur point de vue. Un projet d’émancipation ne s’est-il pas transformé en un instrument de domination ? On n’en est pas (encore) là ! Demeure une question clé : comment évaluer un article de Wikipédia ?

Comment évaluer un article de Wikipédia ?

En 2007, Wikipédia précisait qu’elle n’avait pas les moyens de juger de la crédibilité d’une information et que la fondation cherchait des solutions à cette absence de validation du contenu des articles, notamment « par l’ajout de systèmes de notation, d’identification des versions non vandalisées et par des collaborations avec des chercheurs et des enseignants » (Bruillard, 2007). Des avancées importantes ont été réalisées. Wikipédia évalue elle-même les articles qu’elle produit. Ainsi, l’article Projet :Évaluation est consacré à « déterminer l’état des articles de Wikipédia selon deux critères : leur importance et leur avancement ».

Mais quelle évaluation externe peut-on trouver ?

Quand on lance la requête « évaluation article Wikipédia », via Google, environ 16 900 000 de résultats (0,42 secondes) sont fournis. Mais la grande majorité de ces résultats correspondent à des articles de Wikipedia. La requête « évaluer un article de Wikipédia » -wikipedia.org ne donne aucun résultat. Enlever les guillemets dans la requête conduit à 8 040 000 résultats (0,19 secondes). Que trouve-t-on ?

D’abord des conseils, il s’agit d’évaluer le nombre et la qualité des sources, de consulter l’historique (combien de personnes y ont contribué, et quand), de consulter l’évaluation de l’article et surtout de le comparer à d’autres sources !

Le tutoriel Cerise propose d’autres conseils :

• « Voir si le plan est bien construit et détaillé
• Juger de la qualité de la rédaction : syntaxe, orthographe, synthèse, illustration, …
• Repérer les liens vers les notes et les définitions
• Voir s’il y a une bibliographie récente et mise à jour
• Voir s’il y a un portail sur le thème sélectionné. »

Les guides de la BU de l’université de Rennes 2 dans une page sur « évaluer l’information » consacre un petit encart à Wikipédia en conseillant de regarder les avertissements sur les pages, la date de création (onglet “historique”) et les débats (onglet “discussion”). Cela renvoie à un article du Monde.fr et étrangemenent, aux évaluations internes de Wikipédia.

Sur la Teluq, Marc Couture, dans son cours sur l’évaluation de la crédibilité des documents en ligne, traite du cas particulier de « la crédibilité de Wikipédia ». Il constate que les critères généraux ne s’appliquent qu’imparfaitement aux articles de Wikipédia. Ainsi, ceux reliés à l’insertion dans la littérature spécialisée : « Ce critère prendra donc une valeur toute relative compte tenu à la fois du rôle que joue une encyclopédie dans la littérature scientifique ou savante, et de la difficulté à évaluer le nombre de références à un article de Wikipédia. » Les critères sur l’auteur ne sont pas applicables, les autres (la validation du contenu, forme et la structure du document) sont soit sans garantie soit réfèrent aux classements et processus internes de Wiipédia.

Cherchant dans les sources en anglais, on trouve de nouveau beaucoup de redondances, avec une référence citée, reprise, tronquée dans la Wikipedia anglaise. Un article intitulé Wikipedia:Researching with Wikipedia n’a pas d’équivalent en français avec la recommandation rituelle : “Wikipedia should be a starting place for research, not an end destination and independent confirmation of any fact presented is advised”.

Cet article fournit un lien avec une page sur l’évaluation des articles de Wikipédia, page que l’on retrouve ici (source Phoebe Ayers, en octobre 2006). En fait, ce texte donne tous les éléments pour évaluer un article, les autres sources n’en sont souvent qu’une reprise tronquée. Au bout du compte, c’est une source datée de 2006 (et qui est peut-être antérieure) qui donne les meilleures informations et fait le point le plus complet sur les modes d’évaluation des articles.

Mais est-ce que les procédures d’évaluation préconisées sont opérationnelles ? Autrement dit, peut-on appliquer ces processus dans des utilisations courantes, c’est-à-dire hors situations particulières (notamment scolaires) et de nécessités de vérification. On peut raisonnablement penser que non, si je m’en réfère à mes propres utilisations et ce que peuvent dire les étudiants. Qui confronte systématiquement ce qui est écrit dans un article de Wikipédia à d’autres sources ?

Ce que l’on peut regretter, c’est l’absence de cartographie thématique, alors que l’on imagine qu’il y a des zones de fiabilités différentes, des repérages a priori pourraient guider le lecteurs (les articles dans le domaine X sont plutôt fiables, alors que dans le domaine Y c’est problématique), des marques reconnaissables. Alors que l’on comprend qu’il faut consulter l’historique et les discussions, il y a peu d’outils de visualisation nous donnant une image interprétable ; en conséquence, historique et discussions restent très difficiles à analyser rapidement. En effet, il s’agit de prendre en compte la dynamique collective et temporelle et de pouvoir juger une ressource de par l’histoire de sa construction et des discussions qui l’ont accompagnée. Mais comment le faire rapidement et de manière fiable sans instrumentation. History Flows^[4] proposait des visualisations intéressantes. Mais il ne semble pas que ce travail ait été repris et il demeure mal connu.

Des enjeux de formation : guider des consommateurs via des passeurs outillés

L’évaluation dépend bien évidemment dépend de la finalité, du public visé, etc. et on pourrait refuser une sorte d’évaluation intrinsèque des articles de Wikipédia. Mais le jugement sur cette qualité a des incidences fortes, notamment sur les représentations sociales de ce projet encyclopédique. Chacun a ses propres croyances sur Wikipédia, mais il n’y a pas de « sagesse collective » ou de connaissance collective nous en donnant une image moins naïve. Comment juger de la qualité ? On voit que la question est délicate : qualité proportionnelle ou inversement proportionnelle au nombre de contributeurs ; processus linéaire d’accroissement avec quelques accidents ou des formes de plateau, voire des régressions ? La qualité des collaborations aurait un effet sur la qualité des articles.

Selon une étude récente, les changements apportés pour assurer la qualité des articles, avec de nouveaux contributeurs nombreux, aurait un effet négatif sur le recrutement de ces nouveaux contributeurs découragés par les mécanismes mis en place. Ainsi, incontestablement, un processus de professionnalisation a été organisé, processus qui a un effet dissuasif. D’un autre côté, on s’aperçoit que les « consommateurs », rôle que nous prenons tous à un moment ou à un autre pour Wikipédia, ont du mal à sortir d’une vision très naïve et se satisfont d’une sorte de « bonne pratique » paravent : on n’utiliserait que pour commencer une recherche, on ne s’arrêterait jamais sur un article de Wikipédia. Comportement que très peu de personnes adoptent, sauf dans des contextes très particuliers. Alors que l’on propose des modèles à discuter de perméabilité entre concepteurs et consommateurs, on s’aperçoit que pour Wikipédia, il y a d’un côté des concepteurs très instrumentés et d’un autre côté des consommateurs très peu outillés. Entre les deux, on peut s’interroger sur les connaissances, les instruments pour les « médiateurs » (enseignants, documentalistes, etc.). Ne devraient-ils pas en savoir collectivement beaucoup plus que les « simples » utilisateurs ?

Wikipedia est un excellent analyseur des évolutions éducatives : un discours rituel sur la nécessité de développer des utilisations du « numérique », une présence effective mais comme une espèce de sous culture, acceptable parce qu’elle rend des services, pratique mais décriée. Wikipedia est une mine pour les chercheurs, c’est aussi un projet en avance dans le domaine de la culture et dans celui du Web sémantique. Mais comment maîtriser cette technologie collective ? On ne perçoit pas encore bien toutes les potentialités et limites de l’écriture collective. Une tension apparaît : si on apprend par l’écriture, des contraintes de forme trop fortes découragent, l’exigence de qualité risque de conduire à un élitisme par trop restrictif. Il faudrait professionnaliser les intermédiaires, afin de palier le manque d’instrumentation, notamment permettant de visualiser des processus de construction pour juger une production. La question de l’expertise des éducateurs se pose avec une certaine urgence. Pourquoi n’arrive pas à se développer un regard plus professionnel sur les productions de ce travail collectif ?

Crédit photo : Kalexanderson (Creative Commons By)

La semaine dernière, nous publiions la traduction L’open source n’est pas une zone de guerre, les hommes ne sont pas tous des connards.

Armony Altinier, fondatrice du groupe accessibilité de l’April et l’une des initiatrices de la soirée Libre Diversité, a souhaité réagir à cet article.

Pas de sexisme chez les Libristes ?

Armony Altinier – Mai 2013

Le Framablog a publié récemment une traduction d’un article intitulé « L’open source n’est pas une zone de guerre, les hommes ne sont pas tous des connards ».

Titre éloquent qu’on a immédiatement envie de compléter en disant : « et les femmes ne sont pas toutes des féministes ». Dont acte, merci pour cette évidence.

Cet article était introduit un peu maladroitement^[1] de cette façon : « Un constat sensiblement différent du billet Sexisme chez les geeks : Pourquoi notre communauté est malade, et comment y remédier de MarLard, qui fit couler beaucoup d’encre récemment dans la blogosphère francophone. »

Qu’en est-il exactement ? Le monde du Libre serait-il un doux rêve échappant à un monde structuré en groupes sociaux dominant d’autres groupes ? Malheureusement, point besoin de statistiques complexes pour se rendre compte que la diversité semble une utopie bien lointaine dans tout événement libriste. L’April, dans une enquête interne basée sur leurs adhérent-e-s, avait même révélé que seuls 6% de ses membres étaient des femmes… Cela signifie-t-il que la majorité des libristes (des hommes donc) sont des connards ? Bien sûr que non !

Non, la très grande majorité des libristes n’est pas sexiste, ils se fichent simplement des inégalités qui existent dans leur communauté.

Prenons une analogie simple pour distinguer les différents types de responsabilité.

Quelqu’un commet un vol : c’est un voleur. Quelqu’un voit un vol se commettre et aide la personne à s’enfuir : ce n’est pas un voleur, c’est un complice parce qu’il a agi pour aider le voleur. Quelqu’un voit un vol être commis et ne réagit pas : ce n’est pas un voleur (auteur de l’acte), ce n’est pas un complice (aucune action directe pour aider), c’est juste quelqu’un qui s’en fiche.

Or, si seule une minorité de libristes est sexiste (avec des actes tels que décrits par MarLard), qu’une part un peu plus importante est complice (en relayant des propos qui minimisent de tels actes par exemple ou en en plaisantant ouvertement), la très grande majorité s’en fiche complètement !

Distinguer sexisme et reproduction sociale du patriarcat

Les mots en -isme comme le racisme ont une signification particulière : ils intègrent une dimension idéologique forte. Cela signifie une implication de l’individu derrière cette croyance.

Dans le cas du racisme par exemple, dont le mot sexisme est inspiré selon Wikipédia, il implique que la personne croit que les êtres humains sont divisés en différentes races dont certaines seraient supérieures à d’autres.

On retrouve cette notion de croyance dans le sexisme, où certaines personnes croient que les hommes en tant que groupe social seraient par nature supérieurs au groupe social des femmes. Ainsi, dire que quelqu’un ou qu’une communauté est sexiste a forcément un côté dénonciateur. Ce qui tend à avoir pour effet une réaction pour « défendre » les personnes accusées de sexisme à titre individuel. Or, mettons-nous à la place des femmes de la communauté Perl auteures du billet de blog traduit sur le Framablog : elles ont de bons copains geeks parmi elles, et elles savent très bien qu’ils ne se sentent pas supérieurs à elle parce que ce sont des hommes. Ils ne sont donc pas sexistes et le crier bien fort est un gage d’amitié et de soutien face à ce qui est considéré, à tort, comme une agression.

Pourtant, ce n’est pas parce que des personnes à l’échelle individuelle ne théorisent pas la supériorité des hommes sur les femmes qu’aucune discrimination n’existe de facto dans notre société. Et en n’agissant pas ou en minimisant ces faits, ces personnes reproduisent une société patriarcale qui est non seulement sexiste, mais qui exclut tout individu qui n’entre pas dans le schéma de perfection associé aux attributs de la virilité version XXIe siècle : force physique (et donc absence de faiblesse ou de handicap), accumulation d’argent, jeunisme, diplômes, position sociale dominante…

Ainsi, je me demande en quoi relayer ce message d’amitié individuel sur le Framablog apporterait un éclairage différent aux propos de MarLard comme il a été dit en introduction ? Car les faits sont incontestables : des communautés libres très homogènes dans leur profil c’est-à-dire très masculines, très blanches, valides, technophiles et j’en passe…

Le Libre, un atout pour le féminisme ?

Le féminisme implique deux choses :

1. Accepter d’ouvrir les yeux sur la réalité choquante des discriminations
2. Vouloir prendre une part active pour que les choses changent

Si les mouvements du logiciel et de la culture libres ont bien quelque chose en commun avec les mouvements féministes, c’est leur volonté de modifier l’ordre des choses pour favoriser un écosystème qui libère l’individu. Or, l’ordre établi est celui du patriarcat.

Et si le logiciel libre sortait du pré carré geek pour s’ouvrir à toutes et tous, sans discrimination ? Cela impliquerait de revoir le fonctionnement interne de chaque organisation et de développer un écosystème favorable et ouvert (tiens !) en se souciant de faire de la place à des voix différentes (faire émerger de nouvelles et nouveaux intervenant-e-s par exemple, ce qui suppose de leur faire de la place), à choisir des lieux accessibles à toutes et tous et à investir des lieux différents (pas seulement des repaires de technophiles).

Le slogan du Framablog reprend une phrase du documentaire de Hannu Puttonen Nom de code : Linux : « Ce serait peut-être une des plus grandes opportunités manquées de notre époque si le logiciel libre ne libérait que du code ». Beau défi, n’est-ce pas ? Certain-e-s s’y essaient déjà, et vous ?

Pour aller plus loin, vous pouvez relire un article du Framablog sur les femmes et le logiciel libre.