Comme il est dit sur le site d’April^[1] : Le 27 septembre 1983, Richard Stallman diffusait l’annonce initiale du projet GNU, projet fondateur du mouvement du logiciel libre.

Nous avons donc fêté récemment les 30 ans du projet GNU.

Pour participer nous aussi à l’hommage, nous vous proposons un court extrait de notre framabook Richard Stallman et la révolution du logiciel libre, une biographie autorisée qui est une excellente ressource pour aller plus loin dans la genèse et l’historique du mouvement 😉

Pour rappel ce livre est sous licence libre, vous pouvez librement (et gratuitement) le télécharger dans son intégralité sur le site Framabook mais vous pouvez aussi l’acheter dans notre boutique EnVenteLibre.

Extrait de « Richard Stallman et la révolution du logiciel libre. Une biographie autorisée »

Chapitre 7 : Une morale à l’épreuve (pages 119 à 121)
Auteurs : R. Stallman, S. Williams, C. Masutti
Licence : GNU Free Documentation License

Le 27 septembre 1983, les programmeurs se connectant au groupe de discussion Usenet net.unix-wizards reçurent un message peu habituel. Posté aux premières heures du jour, à minuit et demi exactement, et signé rms@mit-oz, l’objet du message était laconique mais attirait l’attention. « Nouvelle implémentation d’Unix », pouvait-on lire.

Pourtant, au lieu de présenter une version fraîchement disponible d’Unix, le premier paragraphe du message était en fait un appel à contribution :

Dès le Thanksgiving prochain, je commencerai à écrire un système logiciel complet, compatible Unix, appelé GNU (pour GNU N’est pas Unix), et le distribuer librement à tous ceux qui souhaitent l’utiliser. Je fais appel à toute contribution en temps, en argent, en programmes et en matériel pour faire avancer ce projet.

Pour un développeur Unix expérimenté, le message traduisait un mélange d’idéalisme et d’orgueil démesuré. Non content de s’engager à repartir de zéro dans la reconstruction du système d’exploitation Unix déjà abouti, l’auteur proposait en plus de l’améliorer par endroits. Le nouveau système GNU, prédisait-il, intégrerait tous les composants essentiels : un éditeur de texte, un shell pour lancer des applications compatibles Unix, un compilateur, « et diverses autres choses ». À cela s’ajouteraient de nombreuses fonctions particulièrement séduisantes, pas encore disponibles dans les autres systèmes Unix : une interface graphique basée sur le langage de programmation Lisp, un système de fichiers résistant aux pannes et des protocoles réseaux prenant modèle sur ceux du MIT.

« GNU sera capable d’exécuter des programmes Unix, mais ne sera pas identique à Unix, écrivait l’auteur. Nous ferons toutes les améliorations utiles, d’après notre expérience au contact d’autres systèmes d’exploitation. »

Prévoyant une réaction sceptique de la part de certains lecteurs, l’auteur poursuivait l’exposé de son ébauche de système d’exploitation avec une brève note biographique intitulée « Qui suis-je ? » :

Je suis Richard Stallman, l’inventeur de l’éditeur Emacs si souvent imité, et je travaille actuellement au Laboratoire d’intelligence artificielle du MIT. J’ai beaucoup travaillé sur des compilateurs, des éditeurs, des débogueurs, des interpréteurs de commandes, ainsi que sur l’ITS et le système d’exploitation des machines Lisp. J’ai été le premier à mettre au point un affichage indépendant du terminal pour ITS. De plus, j’ai mis en place un système de fichiers résistant aux pannes et deux systèmes de fenêtrage pour machines Lisp.

Le destin a finalement voulu que le projet fou de Stallman…

La suite sur Framabook 😉

Sources :

• GNU celebrating 30 years et Le système GNU et le logiciel libre célèbrent leurs 30 ans
• Ne ratez pas la vidéo de la Quadrature qui lui fait des bisous.

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)

Voici le troisième volet de l’initiation au chiffrement, initialement destiné aux journalistes sous l’égide de la Press Freedom Foundation, que nous avons traduit pour vous (vous pouvez retrouver le premier épisode et le deuxième).

Des logiciels de confiance

D’après Encryption Works

(Contributeurs : Slystone, Asta, goofy, lamessen, Bookynette)

Quand Snowden emploie les termes « endpoint security », il sous-entend que la sécurité sur les ordinateurs à chaque extrémité de la conversation est assurée par le chiffrement et le déchiffrement, contrairement à la sécurité assurée seulement pendant le transit du message. Si vous envoyez un courriel chiffré à un ami mais que vous avez un enregistreur de frappe sur votre ordinateur qui enregistre aussi bien l’intégralité de votre message que la phrase de passe qui protège votre clé de chiffrement, votre chiffrement n’est plus efficace.

Depuis que Glenn Greenwald et Laura Poitras, deux membres du conseil de la Freedom of the Press Foundation, ont révélé  la surveillance généralisée des réseaux par la NSA, de nombreuses informations concernant les agences de renseignement ont été rendues publiques. Particulièrement Bloomberg, qui a publié des révélations sur des programmes volontaires de partage des informations entre les compagnies et les agences d’espionnage étatsuniennes.

Jusqu’à présent, la révélation la plus choquante au sujet de ces programmes de partage des informations, c’est que Microsoft a une politique de communication des informations sur les vulnérabilités dans son logiciel au gouvernement étatsunien avant de publier les mises à jour de sécurité pour le public. L’article dit :

Microsoft Corporation, la plus grosse entreprise de logiciels du monde, fournit aux agences d’espionnage des informations sur les bogues dans ses logiciels grand public avant d’envoyer un correctif. Ces informations peuvent être utilisées pour protéger les ordinateurs du gouvernement et pour accéder aux ordinateurs de terroristes ou forces militaires ennemies.

Cela signifie que la NSA a en main les clés pour accéder à n’importe quel ordinateur utilisant Windows, Office, Skype ou tout autre logiciel Microsoft. Si vous utilisez ces logiciels sur votre ordinateur, il est très probable que la NSA, avec suffisamment d’efforts, peut compromettre votre ordinateur ainsi que vos communications chiffrées, si vous devenez une de leurs cibles.

Nous avons aussi appris du New York Times que Skype, logiciel qui en dehors de la communauté de la sécurité a longtemps eu la réputation d’être un moyen sécurisé de communiquer, a envoyé des conversations privées au gouvernement étatsunien durant les cinq dernières années.

Skype, le service d’appel sur Internet, a commencé son propre programme secret, intitulé Project Chess, pour explorer les problèmes légaux et techniques afin de mettre les appels via Skype à disposition des agences de renseignements et des forces de l’ordre. Cette information vient de gens informés sur le programme qui ont demandé à ne pas être nommés pour éviter les ennuis avec les agences de renseignement.

Le projet Chess, qui n’avait jamais été mentionné auparavant, était discret et limité à moins d’une douzaines de personnes chez Skype. L’une des personnes informées sur le projet a expliqué qu’il a été développé suite à des entretiens parfois houleux avec le gouvernement sur des questions juridiques. Il a commencé il y a 5 ans, avant que la majorité de la société ne soit vendue par son propriétaire, eBay, à des investisseurs externes en 2009. Microsoft a acquis Skype dans un accord de 8.5 milliards de dollars (environ 6.5 milliards d’euros) qui s’est conclu en octobre 2011.

Un responsable de Skype a nié l’année dernière dans un article de blog que les récents changements dans le fonctionnement de Skype aient été faits à la demande de Microsoft pour faciliter l’application de la loi sur l’espionnage. Cependant, il semble que Skype ait compris comment collaborer avec les agences de renseignements avant même que Microsoft n’en prenne le contrôle, comme le dévoilent les documents divulgués par Edward J. Snowden, un ancien sous-traitant de la C.I.A. L’un des documents sur le programme PRISM qu’il a rendu public indique que Skype a rejoint le programme le 6 février 2011.

Les logiciels propriétaires, comme la majorité de ceux proposés par Microsoft, Apple et Google, ont une autre faille. Il est beaucoup plus difficile pour les utilisateurs de vérifier de façon indépendante qu’il n’existe pas de portes dérobées secrètes à la demande clandestine de la surveillance d’état. Bien que des rapports récents aient montré que de nombreuses sociétés ont remis une quantité inconnue d’informations en réponse aux requêtes FISA, aucune de ces entreprises ne s’est avérée avoir directement de portes dérobées dans leurs systèmes.

Il existe un autre type de logiciel qui est plus fiable à cet égard. Les logiciels libres et open source ne sont pas forcément ergonomiques ? et ne sont pas nécessairement sans risques ? Cependant quand ils sont développés de façon ouverte, avec un logiciel de suivi de bogue ouvert, des listes de diffusion ouvertes, une architecture ouverte et un code open source, il est plus difficile pour ces projets d’avoir une politique de trahison de leurs utilisateurs comme celle de Microsoft.

GNU/Linux est un système d’exploitation qui est entièrement composé de logiciels libres et open source. On peut prendre l’exemple de distributions GNU/Linux comme Ubuntu, Debian ou Fedora, qui sont les alternatives à Windows et Mac OS X les plus courantes. Bien que les projets de logiciels libres puissent toujours intégrer du code malveillant (voir le concours C Underhanded), la personne qui écrit ce code doit le cacher proprement et espérer qu’aucun des autres développeurs ou en aval des packagers GNU/Linux qui préparent et compilent le code source du projet pour l’intégrer à leur distribution ne le détectent.

Dans les années 1990, quand le chiffrement public est devenu populaire et que le gouvernement étatsunien faisait tout ce qu’il pouvait pour l’empêcher, le mouvement « cypherpunk » est né. De nombreux logiciels permettant aux gens de chiffrer sont nés de ce mouvement.

Les cypherpunks écrivent du code. Nous savons que quelqu’un doit développer des logiciels pour défendre notre vie privée. Et comme nous ne pouvons pas avoir de vie privée tant que nous ne le feront pas tous, nous allons les développer. Nous publions notre code pour que nos compatriotes cypherpunks puissent s’entrainer et jouer avec. Notre code est utilisable librement par n’importe qui dans le monde. Nous n’en avons rien à faire que vous n’approuviez pas le logiciel que nous développons. Nous savons que le logiciel ne peut être détruit et qu’un système largement dispersé ne peut être stoppé.

— Eric Hughes, dans son Manifeste du Cypherpunk de 1993

Ce code, qui est ouvert et public de façon à ce que d’autres cypherpunks puissent s’entraîner et jouer avec, que n’importe qui dans le monde peut utiliser librement, est à l’origine des logiciels et protocoles dans lesquels nous pouvons avoir confiance : LUKS (le chiffrement de disque intégré à GNU/Linux), OpenPGP, Off-the-Record et Tor.

[mise à jour] Écartons TLS, le chiffrement à l’origine du HTTPS qui selon les dernières révélations semblerait perméable à l’espionnage par la NSA.

Le collectif de technologie tactique a conçu un très bon guide sur les logiciels de sécurité open source dans lesquels on peut avoir confiance pour préserver notre vie privée de toute surveillance. Il est important de rappeler que la simple utilisation de ces logiciels, même à la perfection, ne peut pas garantir la sécurité de votre chiffrement. Nous ne savons pas, par exemple, si Apple a transmis des failles 0-day de iOS à la NSA comme a pu le faire Microsoft. ChatSecure, qui permet d’avoir des discussions chiffrées sur les terminaux iOS, n’est pas plus sécurisé que le système d’exploitation sur lequel il fonctionne.

Il est important de rappeler que le simple fait d’utiliser du logiciel libre ne veut pas dire que l’on ne peut pas s’introduire dans vos systèmes. Des gens trouvent tout le temps des failles 0-day pour du logiciel libre, et parfois les vendent à des gouvernements ou d’autres attaquants malveillants. Des utilisateurs de logiciels libres téléchargent toujours des pièces jointes malveillantes avec leurs courriels, et ils ont souvent mal configuré des services simples sur leurs ordinateurs. Pire encore, les malwares sont souvent très bons pour se dissimuler. Si un utilisateur de logiciel libre attrape sur son ordinateur un malware, ce dernier peut y demeurer jusqu’à ce que l’utilisateur formate ses disques durs.

Tails, qui est une distribution GNU/Linux bootable sur live USB et live CD et dont je vais parler plus loin, résout beaucoup de ces problèmes.

(à suivre…)

Copyright: Encryption Works: How to Protect Your Privacy in the Age of NSA Surveillance est publié sous licence Creative Commons Attribution 3.0 Unported License.

Léo Marius vient à peine de sortir diplômé de l’École supérieure d’art et design de Saint Etienne. Son projet de recherche consistait à créer de toutes pièces (l’expression est bien trouvée) rien moins qu’un appareil photo en impression 3D !

Nom de code du projet : O3DPC (Open 3D Printed Camera). Nom de code de l’appareil : OR-01 (OpenReflex 01).

Le plus simple est encore d’illustrer tout de suite cela par une image explicite.

Il ne s’agit donc pas de photo numérique mais argentique, avec de vieilles pellicules dedans, et il reste le coût (non négligeable) des objectifs. Il n’empêche que le résultat est saisissant, fonctionnel et surtout mis à disposition de tous grâce au choix du Libre.

Nous avons évidemment eu envie d’en savoir plus en interviewant ci-dessous ce jeune créateur.

On voit ici, une nouvelle fois, combien le Libre peut être utile en situation d’étude et d’apprentissage. Combiné avec une accessibilité croissante des nouvelles technologies, il permet à tout un chacun, ayant un peu d’imagination, de réaliser puis partager des choses formidables.

On voit également se dessiner une nouvelle génération de makers/hackers, qui n’a pas eu à batailler (comme nous) pour faire connaître et exister le Libre, et qui l’adopte presque naturellement. Une génération qui donne, somme toute, espoir et confiance en l’avenir 😉

Entretien avec Léo Marius

Léo Marius, bonjour, peux-tu te présenter succinctement ?

Je suis un jeune designer tout juste diplômé de l’École supérieure d’art et design de Saint Etienne. Passionné par les nouvelles technologies et en particulier l’impression 3D dans laquelle je vois des opportunités de créations incroyables souvent sous-exploitées (je milite contre les têtes de Yoda et les coques pour smartphone imprimés !).

Libriste et actif dans le milieu associatif depuis quelques années. J’apprécie beaucoup la photographie mais je ne suis pas moi-même photographe.

Qu’est-ce donc que le projet O3DPC ? Comment est-il né ? Et en quoi est-il relié à tes études ?

Le projet O3DPC (pour Open 3D Printed Camera) est un travail de recherche que j’ai mené en rapprochant l’impression 3D libre et la photographie, il rassemble plusieurs projets sur lesquels j’ai travaillé, dont plusieurs sténopés et dernièrement le reflex imprimé.

J’ai mené ce travail en tant que projet personnel tout au long de mes études en design, c’était l’occasion pour moi de rapprocher deux domaines qui m’intéressent : l’impression 3D et la photographie.

De ce projet est donc sorti le prototype OR-01, quelles sont ces principales caractéristiques ? ces atouts ? ces améliorations futures (j’ai cru lire un projet avec la carte Arduino) ?

C’est un reflex argentique classique avec une visée directe (on peut voir directement ce que l’ont vise sur le petit rectangle dessus et un obturateur manuel qui fonctionne à environ 1/60° de seconde).

Son atout principal c’est que l’ensemble de ses sources sont libres, et donc adaptable, il est ainsi facile de le modifier pour l’adapter si certaines choses fonctionnement mal ou si on souhaite l’adapter pour des usages particuliers.

Dans sa forme actuelle je retiendrai deux éléments particulièrement intéressants :

• En premier la bague d’adaptation pour les optiques est démontable, on peut donc facilement s’imprimer des baïonnettes différentes pour s’adapter a plusieurs types d’objectifs sans avoir à changer de boîtier.
• Il y a également le dos autonome et démontable que j’apprécie, la partie où l’on met sa pellicule. Lorsque j’utilise le mien j’ai deux dos prêts avec deux pellicules différentes et je peux les changer rapidement pour m’adapter à la luminosité (ou switcher entre une pellicule noir et blanc et couleur, tout cela en plein milieu du rouleau d’une pellicule)

Le choix de l’open source, c’est un choix pragmatique, éthique ou les deux mon général ? Je lis (avec joie) une licence CC by-sa pour tes pièces, pourquoi n’as-tu pas retenu la clause non commerciale NC ?

Un peu des deux. À mon arrivée à l’école, j’ai intégré l’association Le_Garage (dont j’ai été président pendant deux ans) qui fait de la sensibilisation dans l’école aux questions du libre en art et design. Ça a donc été assez naturel pour moi de redistribuer ce travail sous licence libre.

L’idée principale derrière l’OR-01 c’est la réappropriation et la compréhension des nos appareils quotidiens, fermer les sources aurait interdit et contredit cet objectif

Pour ce qui est des la clause NC je préfère ne pas l’utiliser car je la trouve trop floue et contraignante dans la pratique. Si on souhaite qu’un projet se diffuse il ne faut pas lui mettre des bâtons dans les roues. Je n’ai aucune raison de m opposer à ce que quelqu’un souhaite se rapproprier le projet, l’améliorer et le vendre, s’il a lui même fourni un travail et qu’il respecte les conditions de redistribution de la licence copyleft.

Quelle imprimante 3D utilises-tu ? La « full libre » RepRap ou la « moins libre » MakerBot^[1] ?

J’ai commencé le projet O3DPC il y a un peu plus de trois ans avec une Makerbot de 1ere génération (la numéro 660 ! une pièce de collection) que nous avions acquis avec notre association libriste et qui était encore libre à l’époque. Le reflex a été réalisé avec une Makerbot de dernière génération, la Replicator 2X qui a été achetée par notre école en complément d’une imprimante 3D haut de gamme que nous avions déjà.

L’utilisation de la Makerbot est un moindre mal, les technologies utilisées sont les même que sur les RepRaps traditionnels et les pièces qu’il est possible d’imprimer avec une Makerbot le seront aussi sur une RepRap bien calibrée. Je souhaitais, pour aider à sa diffusion, que le boîtier soit imprimable sur une imprimante de type RepRap. Si j’avais pu choisir je pense que j’aurais opté pour une Lulzbot. 😉

Au niveau logiciel, quels sont ceux que tu utilises et pourquoi ? Sont-ils tous libres ?

J’ai essentiellement utilisé Blender, c’est un logiciel que je connais bien et que je trouve extrêmement polyvalent et flexible. Les formes produites avec ce logiciel sont souvent très souples, et on déplace avec aisance les points pour adapter nos formes et nos courbes. Souvent en design on nous fait utiliser l’application propriétaire Rhino qui est beaucoup plus stricte dans son utilisation (« un tout petit peu plus haut » sur Blender correspond à un « Z+0,23mm » sur un Rhino mais il faut alors redessiner toute sa courbe avant de refaire sa révolution). Avec Blender on peut se permettre des approximations, ce qui est bien pratique dans une démarche de recherche.

J’ai également utilisé le libre OpenScad pour certaines pièces qui nécessitaient des formes et des distances très précises. Le fait de pouvoir coder ses pièces s’est avéré très utile. La pièce ne correspond pas ? Il suffit de changer quelques lignes de code pour tout modifier ! L’ensemble est libre 😉

Ce qui était particulièrement pratique c’est que, n’ayant pas d’ordinateur portable performant, je me déplaçais avec mon disque dur et les versions mobiles de toutes mes application pour les principaux OS dessus et je pouvais alors travailler où je le souhaitais.

Tu déposes les fichiers numériques de tes pièces sur Thingiverse et Instructables. Aujourd’hui quand on est développeur et qu’on cherche du boulot, on peut mettre dans son CV ses contributions sur GitHub. Penses-tu qu’il en ira de même demain dans le design sur ce type de dépôts ?

Oui, et de plus en plus. Je prends par exemple le designer Samuel Bernier qui a diffusé une partie de son travail en libre sur Instructables et que j’ai interogé pour mon mémoire (sur les Designers/Makers). Lorsque je lui ai demandé ce que lui avait apporté le libre, il m’a répondu : « des contacts et beaucoup d’opportunités ».

J’ai d’ailleurs mis récemment une note sur mon compte Instructables précisant que je cherchais un emploi, et j’ai reçu une proposition assez intéressante la semaine dernière (rien de défini, mais on verra). Ça fonctionne. Et si cela n’aboutit pas je peux me dire que 95% de mes employeurs potentiels auront vu mon projet de diplôme avant que je les contacte, ce qui est pas mal déjà comme entrée en matière.

25 euros en pièces détachées pour une appareil photo, c’est possible ? Et si oui, ne crains-tu pas pas qu’une société s’en empare et commercialise ton projet sans toi puisque c’est open source (question troll-piège :)) ?

Comme je l’ai mentionné plus haut, tant qu’ils respectent la clause de redistribution à l’identique (SA), cela me va. Je pourrais ainsi à mon tour récupérer leurs sources (que j’espère améliorées) pour mes propres boîtiers 😉

Éprouves-tu une certaine « nostalgie » de la photo argentique ?

Pas vraiment de la nostalgie, mais c’est une sensibilité différente à l’image que l’on ne retrouve pas avec le numérique : l’attente et l’incertitude de la photo, le coût aussi qui limite l’utilisation abusive. On réfléchit avant d’appuyer sur le bouton, on n’en prend pas cinquante à la volée comme cela se fait trop souvent.

Je me souviens du temps où les objectifs étaient obligatoirement reliés à une marque (ceux pour Canon, Nikon, etc.). Avec ton OR-01 et sa bague adaptable, tu donnes en quelque sorte de l’interopérabilité aux appareils photos, non ?

Oui, toujours dans l’idée de se rapproprier la technologies. Si l’appareil avait été dépendant d’un type d’objectifs, cela n’aurait pas fonctionné.

Techniquement, comment réussis-tu avec des pièces à monter à rendre l’appareil totalement opaque ?

Le tout est imprimé avec du plastique opaque et, en mettant des rebords et des emboîtements bien placés, l’étanchéité se fait sans trop de difficultés. Pour certaines zones, un peu plus sensibles, j’ai ajouté de la patafix noire pour combler les trous potentiels.

Toutes les parties étant autonomes c’est surtout le dos dans lequel se trouve la pellicule qu’il faut rendre étanche à la lumière, on peut se permettre des petits jours dans les autres. Ça reste un appareil DIY. 🙂

Un petit mot sur Framasoft que tu sembles connaître ?

Merci ! Continuez ce que vous faites. Le libre l’emportera ! 😉

Un appel à lancer ? Une actualité à annoncer ?

Peut être une nouvelle version plus aboutie de l’OpenReflex qui devrait être disponible en financement participatif en septembre ou octobre (selon mes engagements professionnels). N’hésitez pas à suivre mon blog ou à me poster un message sur le dépôt Instructables pour être tenus au courant.

Et sinon, permettez-moi un petit clin d’oeil hommage à Gilles Roussi, le professeur à l’origine de l’association Le_Garage qui nous lira surement 😉

Photo ci-dessous réalisée avec l’OR-01

On en profite pour remercier tout l’équipe d’organisation.

Rendez-vous l’année prochaine à Montpellier 😉

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)

Quelques-unes des participations de Framasoft au programme :

http://schedule2013.rmll.info/programme/cultures-et-arts-libres/cultures-et-arts-libres-6/

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)

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.