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

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

Protéger le secteur du logiciel des brevets

Giving the Software Field Protection from Patents

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

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

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

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

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

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

Le problème particulier du logiciel

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ne vous inquiétez pas, faites confiance

Shaun McCance

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

La documentation et moi, avant et après

Anne Gentle

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

De L’importance des bonnes manières

Rich Bowen

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

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

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

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

La paresse

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

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

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

La patience

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

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

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

L’humilité

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

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

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

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

La Politesse et le Respect

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

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

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

J’aurais aimé…

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

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

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

Traduction Framalang : lamessen, Sputnik, lerouge, RavageJo, Sky, Astalaseven, goofy, KoS, peupleLa + Julius22

Une bonne documentation change la vie des débutants

Atul Jha

Atul Jha utilise des logiciels libres depuis 2002. Il travaille en tant que spécialiste des applications au CSS Corp, à Chennai en Inde. Il aime parcourir les universités, rencontrer des étudiants et propager la bonne parole du logiciel libre.

En 2002, on naviguait sur Internet dans des cybercafés en raison du coût important des accès par lignes commutées. À l’époque, la messagerie instantanée de Yahoo était très populaire et j’avais pris l’habitude de discuter sur le canal #hackers. Il y avait quelques fous furieux là-dedans qui prétendaient qu’ils pouvaient pirater mon mot de passe. J’étais très impatient d’en savoir plus sur le piratage et de devenir l’un d’eux. Le lendemain, je suis retourné au cybercafé et j’ai tapé « comment devenir un hacker » sur le moteur de recherche Yahoo. La toute première URL dirigeait sur le livre d’Eric S. Raymond. J’étais fou de joie à l’idée d’entrer dans le cercle des initiés.

J’ai commencé à lire le livre et à ma grande surprise la définition de hacker était « quelqu’un qui aime résoudre les problèmes et dépasser les limites ». Il y est également écrit : « les hackers construisent des choses, les casseurs les brisent »(1). Hélas, je cherchais le côté obscur, celui des crackers, et ce livre m’a mené de l’autre côté de la force, celui des hackers. J’ai continué à lire le livre et à rencontrer divers termes nouveaux tels que GNU/Linux, liste de diffusion, groupe d’utilisateur Linux, IRC, Python et bien d’autres encore.

En poursuivant mes recherches, j’ai pu trouver un groupe d’utilisateurs de Linux à Delhi et j’ai eu l’opportunité de rencontrer de vrais hackers. J’avais l’impression d’être dans un autre monde quand ils parlaient de Perl, RMS, du noyau, des pilotes de périphériques, de compilation et d’autres choses qui me passaient bien au-dessus de la tête.

J’étais dans un autre monde. J’ai préféré rentrer à la maison et trouver une distribution Linux quelque part. J’avais bien trop peur pour leur en demander une. J’étais loin de leur niveau, un débutant totalement idiot. J’ai réussi à en obtenir une en payant 1 000 Roupies indiennes [NdT : environ 13,92 €] à un gars qui en faisait le commerce. J’en ai essayé beaucoup mais je n’arrivais pas à faire fonctionner le son. Cette fois-là, je décidai de consulter un canal IRC depuis le cybercafé. Je trouvai #linux-india et lançai : « g ok1 son ». Des injonctions fusèrent alors : « pas de langage SMS » et « RTFM ». Ça m’a fait encore plus peur et j’ai mis du temps à faire la relation entre « RTFM » et « read the fucking manual » [NdT : « lis le putain de manuel » dans la langue de Molière].

J’étais terrifié et j’ai préféré rester à l’écart de l’IRC pendant quelques semaines.

Un beau jour, j’ai reçu un courriel qui annonçait une réunion mensuelle de groupes d’utilisateurs Linux. J’avais besoin de réponses à mes nombreuses questions. C’est là que j’ai rencontré Karunakar. Il m’a demandé d’apporter mon ordinateur à son bureau, où il avait l’intégralité du dépôt de Debian. C’était nouveau pour moi, mais j’étais satisfait à l’idée de pouvoir enfin écouter de la musique sur Linux. Le lendemain, j’étais dans son bureau après avoir fait le trajet avec mon ordinateur dans un bus bondé, c’était génial. En quelques heures, Debian était opérationnel sur mon système. Il m’a aussi donné quelques livres pour débutants et une liste des commandes de base.

Le lendemain, j’étais à nouveau au cybercafé, et je lisais un autre essai d’Eric S. Raymond, intitulé Comment poser les questions de manière intelligente. Je continuais de fréquenter le canal #hackers sur Yahoo chat où je m’étais fait un très bon ami, Krish, qui m’a suggéré d’acheter le livre intitulé Commandes de références sous Linux. Après avoir passé quelque temps avec ces livres et en utilisant tldp.org (The Linux Documentation Project) comme support, j’étais devenu un utilisateur débutant sous Linux. Je n’ai jamais regardé en arrière. J’ai aussi assisté à une conférence sur Linux où j’ai rencontré quelques hackers de Yahoo ; écouter leurs conférences m’a beaucoup inspiré. Quelques années plus tard, j’ai eu la chance de rencontrer Richard Stallman qui est une sorte de dieu pour beaucoup de gens dans la communauté du logiciel libre.

Je dois reconnaître que la documentation d’Eric S. Raymond a changé ma vie et sûrement celle de beaucoup d’autres. Après toutes ces années passées dans la communauté du logiciel libre, je me suis rendu compte que la documentation est la clé pour amener des débutants à participer à cette extraordinaire communauté open source. Mon conseil à deux balles à tous les développeurs serait : s’il vous plaît, documentez votre travail, même le plus petit, car le monde est plein de débutants qui aimeraient le comprendre. Mon blog propose un large éventail de publications, qui vont des plus simples comme l’activation de la vérification orthographique dans OpenOffice à celles, plus complexes, traitant de l’installation de Django dans un environnement virtuel.

[1] NdT : Un hacker sait où et comment bidouiller un programme pour effectuer des tâches autres que celles prévues par ses concepteurs alors qu’un cracker est un pirate informatique spécialisé dans le cassage des protections dites de sécurité.

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

Traduction Framalang : lamessen, Sky, Kalupa, ga3lig, Wxcafe, goofy, Astalaseven, Slystone, okram, KoS, Lycoris, peupleLa, Julius22

La Voie des tests conduit à la Lumière

Jonathan “Duke” Leto

Jonathan Leto, dit « Le Duc » est un développeur de logiciel, un mathématicien dont les travaux sont publiés, un ninja de Git et un passionné de cyclisme qui vit à Portland, en Oregon. C’est l’un des développeurs principaux de la machine virtuelle Parrot et le fondateur de Leto Labs LLC.

Lorsque j’ai commencé à m’impliquer dans le logiciel libre et open source, je n’avais aucune idée de ce que pouvaient être les tests ni de leur importance. J’avais travaillé sur des projets personnels de programmation auparavant, mais la première fois que j’ai réellement travaillé sur un projet collaboratif (c’est-à-dire en faisant un peu de commit) c’était pour Yacas, acronyme de Yet Another Computer Algebra System, (NdT : encore un autre logiciel de calcul algébrique similaire à Mathematica).

À ce stade de mon parcours, les tests ne venaient qu’après coup. Mon méta-algorithme général était : bidouiller du code > voir si ça fonctionne> écrire (éventuellement) un test simple pour démontrer que ça fonctionne. Un test difficile à écrire n’était généralement jamais écrit.

C’est le premier pas sur la voie qui mène à la Lumière grâce aux tests. Vous savez que les tests sont probablement une bonne idée, mais vous n’en avez pas vu clairement les bénéfices, alors vous vous contentez de les écrire de temps en temps.

Si je pouvais ouvrir un trou de souris dans l’espace-temps et donner à mon moi plus jeune un conseil plein de sagesse sur les tests, ce serait :

« Certains tests sont plus importants, sur le long terme, que le code qu’ils testent. »

Il y a sans doute quelques personnes qui pensent en ce moment même que je mets mon casque de protection psychique (NdT : il s’agit d’un chapeau pour se protéger contre la manipulation à distance du cerveau) quand je m’assois pour écrire du code. Comment les tests pourraient-ils être plus importants que le code qu’ils testent ? Les tests sont la preuve que votre code marche réellement ; ils vous montrent le chemin vers l’écriture d’un code propre et vous apportent aussi la souplesse qui vous permettra de modifier le code tout en sachant que les fonctionnalités seront toujours là. En effet, plus votre code source grossit, plus vos tests sont importants, car ils vous permettent de changer une partie dudit code en sachant que le reste fonctionnera.

Une autre raison essentielle qui justifie l’écriture de tests est la possibilité de spécifier que quelque chose est un souhait explicite et non une conséquence imprévue ou un oubli. Si vous avez un cahier des charges, vous pouvez utiliser des tests pour vérifier qu’il est respecté, ce qui est très important, voire indispensable dans certaines industries. Un test, c’est comme quand on raconte une histoire : l’histoire de votre conception du code et de la façon dont il devrait fonctionner. Soit le code change et évolue, soit il mute en code infectieux (1).

Très souvent, vous écrirez des tests une première fois pour ensuite remettre totalement en cause votre réalisation voire la réécrire à partir de zéro. Les tests survivent souvent au code pour lesquels ils ont été conçus à l’origine. Par exemple, un jeu de tests peut être utilisé quel que soit le nombre de fois où votre code est transformé. Les tests sont en fait l’examen de passage qui vous permettra de jeter une ancienne réalisation et de dire « cette nouvelle version a une bien meilleure structure et passe notre jeu de tests ». J’ai vu cela se produire bien des fois dans les communautés Perl et Parrot, où vous pouvez souvent me voir traîner. Les tests vous permettent de changer les choses rapidement et de savoir si quelque chose est cassé. Ils sont comme des propulseurs pour les développeurs.

Les charpentiers ont un adage qui dit quelque chose comme ça :

« Mesurer deux fois, couper une fois. »

Le code serait la coupe, le test serait la mesure.

La méthode de développement basée sur les tests fait économiser beaucoup de temps, parce qu’au lieu de vous prendre la tête à bricoler le code sans but défini, les tests précisent votre objectif.

Les tests sont aussi un très bon retour d’expérience. Chaque fois que vous faites une nouvelle passe de test, vous savez que votre code s’améliore et qu’il a une fonctionnalité de plus ou un bogue de moins.

Il est facile de se dire « je veux ajouter 50 fonctionnalités » et de passer toute la journée à bricoler le code tout en jonglant en permanence entre différents travaux. La plupart du temps, peu de choses aboutiront. La méthode de développement basée sur les tests aide à se concentrer sur la réussite d’un seul test à la fois.

Si votre code échoue devant ne serait-ce qu’un seul test, vous avez pour mission de le faire réussir. Votre cerveau se concentre alors sur quelque chose de très spécifique, et dans la plupart des cas cela produit de meilleurs résultats que passer constamment d’une tâche à une autre.

La plupart des informations relatives au développement basé sur les tests sont très spécifiques à un langage ou à une situation, mais ce n’est pas une obligation. Voilà comment aborder l’ajout d’une nouvelle fonctionnalité ou la correction d’un bogue dans n’importe quel langage :

1. Écrivez un test qui fait échouer votre code, mais qui, selon vous, sera passé quand la fonctionnalité sera implémentée ou que le bogue sera corrigé. Mode expert : pendant l’écriture du test, pensez à l’exécuter de temps en temps, même s’il n’est pas encore fini, et tentez de deviner le message d’erreur effectif que le test renverra. À force d’écrire des tests et de les faire tourner, cela devient plus facile ;
2. Bidouillez le code ;
3. Exécutez le test. S’il marche, passez au point 4, sinon retournez au point 2 ;
4. C’est fini ! Dansez le sirtaki.

Cette méthode fonctionne pour n’importe quel type de test et n’importe quel langage. Si vous ne deviez retenir qu’une seule chose de ce texte, souvenez-vous des étapes ci-dessus.

Voici maintenant quelques directives plus générales de conduite de tests qui vous serviront bien et fonctionneront dans n’importe quelle situation :

1. Comprendre la différence entre ce qu’on teste et ce qu’on utilise comme un outil pour tester autre chose ;
2. Les tests sont fragiles. Vous pouvez toujours écrire un test qui contrôle la validité d’un message d’erreur. Mais que se passera-t-il si le message d’erreur change ? Que se passera-t-il quand quelqu’un traduira votre code en catalan ? Que se passera-t-il lorsque quelqu’un exécutera votre code sur un système d’exploitation dont vous n’avez jamais entendu parler ? Plus votre test est résistant, plus il aura de valeur.

Pensez à cela quand vous écrivez des tests. Vous voulez qu’ils soient résistants, c’est-à-dire que les tests, dans la plupart des cas, ne devraient avoir à changer que quand les fonctionnalités changent. Si vous devez modifier vos tests régulièrement, sans que les fonctionnalités aient changé, c’est que vous faites une erreur quelque part.

Types de tests

Bien des personnes sont perdues quand on leur parle de tests d’intégration, tests unitaires, tests d’acceptation et autres tests à toutes les sauces. Il ne faut pas trop se soucier de ces termes. Plus vous écrirez de tests, mieux vous en distinguerez les nuances et les différences entre les tests deviendront plus apparentes. Tout le monde n’a pas la même définition de ce que sont les tests, mais c’est utile d’avoir des termes pour décrire les types de tests.

Tests unitaires contre tests d’intégration

Les tests unitaires et les tests d’intégration couvrent un large spectre. Les tests unitaires testent de petits segments de code et les tests d’intégration vérifient comment ces segments se combinent. Il revient à l’auteur du test de décider ce que comprend une unité, mais c’est le plus souvent au niveau d’une fonction ou d’une méthode, même si certains langages appellent ces choses différemment.

Pour rendre cela un peu plus concret, nous établirons une analogie sommaire en utilisant des fonctions. Imaginez que f(x) et g(x) soient deux fonctions qui représentent deux unités de code. Pour l’aspect concret, supposons qu’elles représentent deux fonctions spécifiques du code de base de votre projet libre et open source.

Un test d’intégration affirme quelque chose comme la composition de la fonction, par exemple f(g(a)) = b. Un test d’intégration consiste à tester la façon dont plusieurs choses s’intègrent ou travaillent ensemble, plutôt que la façon dont chaque partie fonctionne individuellement. Si l’algèbre n’est pas votre truc, une autre façon de comprendre est de considérer que les tests unitaires ne testent qu’une partie de la machine à la fois, tandis que les tests d’intégration s’assurent que la plupart des parties fonctionnent à l’unisson. Un bel exemple de test d’intégration est le test de conduite d’une voiture. Vous ne vérifiez pas la pression atmosphérique, ni ne mesurez le voltage des bougies d’allumage. Vous vous assurez que le véhicule fonctionne globalement.

La plupart du temps, il est préférable d’avoir les deux. Je commence souvent avec les tests unitaires puis j’ajoute les tests d’intégration au besoin puisqu’on a besoin d’éliminer d’abord les bogues les plus basiques, puis de trouver les bogues plus subtils issus d’un emboitement imparfait des morceaux, à l’opposé de pièces qui ne fonctionnent pas individuellement. Beaucoup de gens écrivent d’abord des tests d’intégration puis se plongent dans les tests unitaires. Le plus important n’est pas de savoir lequel vous écrirez en premier, mais d’écrire les deux types de tests.

Vers la Lumière

La méthode de développement basée sur les tests est un chemin, pas un aboutissement. Sachez apprécier le voyage et assurez-vous de faire une pause pour respirer les fleurs si vous êtes égaré. 

(1) Équivalent approché du terme bitrot qui en argot de codeur désigne ce fait quasi-universel : si un bout de code ne change pas mais que tout repose sur lui, il « pourrit ». Il y a alors habituellement très peu de chances pour qu’il fonctionne tant qu’aucune modification ne sera apportée pour l’adapter à de nouveaux logiciels ou nouveaux matériels.

Comic strip réalisé avec le Face-O-Matic de Nina Paley et Margot Burns

Copyheart ? 2011 by Margo Burns and Nina Paley. Copying is an act of love. Please copy!

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

Traduction Framalang : lamessen, Sky, Kalupa, ga3lig, goofy, Astalaseven, okram, KoS, Lycoris, 4nti7rust, peupleLa + Julius22

Penser/Classer

Andre Klapper

Dans la vraie vie, Andre Klapper est maître ès débogage. Pendant sa pause déjeuner ou sa sieste, il travaille à divers trucs sur GNOME (bugsquad, équipe de release, traduction, documentation, etc.), ou Maemo, étudie ou mange de la crème glacée.

Au tout début, je n’avais qu’une seule et unique question : comment imprimer seulement une partie du courriel que j’ai reçu dans Evolution, le client de messagerie GNOME ? J’ai donc demandé sur la liste de diffusion.

Ça faisait exactement un an que j’étais passé sous Linux, frustré de ne pouvoir faire fonctionner mon modem après avoir réinstallé un OS propriétaire plutôt populaire à l’époque.

La réponse à ma question fut : « impossible ». Des petits génies auraient parcouru le code, l’auraient compilé, l’auraient bidouillé pour qu’il se comporte comme voulu, puis auraient soumis un correctif joint au rapport de bogue. Bon. Comme vous l’aurez deviné, je n’étais pas un petit génie. Mes talents de programmeur sont plutôt limités, donc sur le moment je suis resté coincé sur une solution de contournement plutôt lourde pour mon impression. La réponse que j’avais reçue sur la liste de diffusion signalait également que cette fonctionnalité était prévue, et qu’on avait complété pour moi un rapport de bogue — sans préciser où, mais je m’en fichais, j’étais content d’apprendre qu’il était prévu de corriger mon problème prochainement.

Il se peut que je sois resté abonné à la liste de diffusion par simple paresse. Certains mentionnaient le rapporteur de bogues de temps en temps, souvent comme une réponse directe aux demandes de fonctionnalités, alors j’y ai finalement jeté un coup d’œil. Mais les rapporteurs de bogue, en particulier Bugzilla, sont d’étranges outils avec beaucoup d’options complexes. Un domaine que vous préférez normalement éviter à moins que vous ne soyez masochiste. Ils contiennent maints tickets décrivant des bogues ou des demandes de fonctionnalités émanant d’utilisateurs et de développeurs. Il semblait également que ces rapports aient été en partie utilisés pour planifier les priorités (appeler cela « gestion de projet » aurait été un euphémisme ; moins d’un quart des problèmes qui étaient planifiés pour être résolus ou implémentés dans une version spécifique étaient réellement corrigés au bout du compte).

Au-delà d’une vision intéressante sur les problèmes du logiciel et sur la popularité de certaines demandes, ce que j’ai découvert, c’est beaucoup de choses incohérentes et pas mal de bruit, comme des doublons ou des rapports de bogues manquant d’éléments pour pouvoir être traités correctement. J’ai eu envie de nettoyer un peu en « triant » les rapports de bogues disponibles. Je ne sais pas bien ce que cela vous dit sur mon état d’esprit — ajouter ici des mots-clés bidon pour une caractérisation aléatoire, comme organisé, persévérant et intelligent. C’est assez ironique quand on pense à mon père qui se plaignait toujours du bordel dans ma chambre. Donc à cette époque lointaine de modems commutés, j’avais pour habitude de rassembler mes questions et de les faire remonter sur IRC une fois par jour afin de mitrailler de questions le responsable des bogues d’Evolution, qui était toujours accueillant, patient et soucieux de partager son expérience. Si jamais à l’époque il y avait un guide de triage qui couvrait les savoirs de base pour la gestion des bogues et qui exposait les bonnes pratiques et les pièges les plus courants, je n’en avais pas entendu parler.

Le nombre de signalements baissa de 20% en quelques mois, bien que ce ne fût bien évidemment pas grâce à une unique personne qui faisait le tri des tickets. Il y avait manifestement du travail en attente, comme diminuer le nombre des tickets attribués aux développeurs pour qu’ils puissent mieux se concentrer, parler avec eux, définir les priorités, et répondre aux commentaires non-traités de certains utilisateurs. L’open source accueille toujours bien les contributions une fois que vous avez trouvé votre créneau.

Bien plus tard, j’ai pris conscience qu’il y avait de la documentation à consulter. Luis Villa, qui fut probablement le premier des experts en bogues, a écrit un essai titré « Pourquoi tout le monde à besoin d’un expert en bogue » et la majorité des équipes anti-bogues sur les projets open source ont publié au même moment des guides sur le triage qui ont aidé les débutants à s’impliquer dans la communauté. De nombreux développeurs ont débuté leur fantastique carrière dans l’open source en triant les bogues et ont ainsi acquis une première expérience de gestion de projet logiciel.

Il y a aussi de nos jours des outils qui peuvent vous épargner beaucoup de temps quand arrive l’abrutissant travail de triage. Du côté serveur, l’extension « stock answers » de GNOME fournit les commentaires courants et fréquemment usités afin de les ajouter aux tickets en un clic pendant que, du côté client, vous pouvez faire tourner votre propre script  GreaseMonkey ou l’extension Jetpack de Matej Cepl, appelée  « bugzilla-triage-scripts » [2].

Si vous êtes un musicien moyen ou médiocre mais que vous aimez tout de même la musique par-dessus tout, vous pouvez toujours y travailler en tant que journaliste. Le développement de logiciels possède également ce genre de niches qui peuvent vous donner satisfaction, au-delà de l’idée première d’écrire du code. Cela vous prendra un peu de temps pour les trouver, mais ça vaut la peine d’y consacrer vos efforts, votre expérience et vos  contacts. Avec un peu de chance et de talent, cela peut même vous permettre de gagner votre vie dans le domaine qui vous intéresse personnellement… et vous éviter de finir pisse-code.

[1] http://tieguy.org/talks-files/LCA-2005-paper-html/index.html

[2] https://fedorahosted.org/bugzilla-triage-scripts

Crédit photo : Doug DuCap Food and Travel (CC BY-NC-SA 2.0)

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

Traduction Framalang : Floxy, ga3lig, goofy, Astalaseven, Slystone, okram, KoS, Lycoris, 4nti7rust, peupleLa, Luc Didry, + Julius22

Même en multipliant les regards, les bogues ne sautent pas aux yeux.

Ara Pulido

Ara Pulido est ingénieure d’essais pour Canonical, d’abord comme membre de l’équipe assurance qualité d’Ubuntu (QA team), et maintenant dans le cadre de l’équipe de certification du matériel. Même si elle a commencé sa carrière en tant que développeuse, elle a vite découvert que ce qu’elle aimait vraiment, c’était tester les logiciels. Elle est très intéressée par les nouvelles techniques d’analyse et tente d’utiliser son savoir-faire pour améliorer Ubuntu.

Les tests maison ne suffisent pas

Je me suis impliquée dans le logiciel libre dès le début de mes études à l’Université de Grenade. Là-bas, avec des amis, nous avons fondé un groupe local d’utilisateurs de Linux et organisé plusieurs actions pour promouvoir le logiciel libre. Mais, depuis que j’ai quitté l’université, et jusqu’à ce que je commence à travailler chez Canonical, ma carrière professionnelle s’est déroulée dans l’industrie du logiciel propriétaire, d’abord comme développeuse puis comme testeuse.

Lorsque l’on travaille au sein d’un projet de logiciel propriétaire, les ressources pour tester sont très limitées. Une petite équipe reprend le travail initié par les développeurs avec les tests unitaires, utilisant leur expérience pour trouver autant de bogues que possible afin de mettre à disposition de l’utilisateur final un produit aussi abouti que possible. Dans le monde du logiciel libre, en revanche, tout est différent.

Lors de mon embauche chez Canonical, hormis la réalisation de mon rêve d’avoir un travail rémunéré au sein d’un projet de logiciel libre, j’ai été émerveillée par les possibilités des activités de test dans le cadre d’un tel projet. Le développement du produit s’effectue de manière ouverte, et les utilisateurs ont accès au logiciel dès son commencement, ils le testent et font des rapports de bogues dès que c’est nécessaire. C’est un nouveau monde rempli de beaucoup de possibilités pour une personne passionnée par les tests. Je voulais en profiter au maximum.

Comme beaucoup de personnes, je pensais que les tests « maison », c’est-à-dire l’utilisation par soi-même du logiciel que l’on envisage de mettre à disposition, était l’activité de test la plus importante qu’on puisse mener dans le logiciel libre. Mais si, selon la formule de Raymond dans La cathédrale et le bazar « avec suffisamment d’observateurs, tous les bogues sautent aux yeux », alors comment se fait-il qu’avec ses millions d’utilisateurs Ubuntu comporte encore des bogues sérieux à chaque nouvelle version ?

La première chose dont je me suis aperçue quand j’ai commencé à travailler chez Canonical c’est que les activités de test organisées étaient rares ou inexistantes. Les seules sessions de test qui étaient d’une certaine façon organisées se présentaient sous la forme de messages électroniques envoyés à une liste de diffusion, manière de battre le rappel pour tester un paquetage dans la version de développement d’Ubuntu. Je ne pense pas que cela puisse être considéré comme une vraie procédure de test, mais simplement comme une autre forme de « test maison ». Cette sorte de test génère beaucoup de doublons, car un bogue facile à débusquer sera documenté par des centaines de personnes. Malheureusement le bogue potentiellement critique, vraiment difficile à trouver, a de bonnes chances de passer inaperçu en raison du bruit créé par les autres bogues, et ce même si quelqu’un l’a documenté.

En progrès

La situation s’améliore-t-elle ? Sommes-nous devenus plus efficaces pour les tests au sein des projets de développement libre ? Oui, j’en suis convaincue.

Pendant les derniers cycles de développement d’Ubuntu, nous avons commencé bon nombre de sessions de test. La gamme des objectifs pour ces sessions est large, elle comprend des domaines comme de nouvelles fonctionnalités de bureau, des tests de régression, des tests de pilotes X.org ou des tests de matériel d’ordinateur portable. Les résultats sont toujours suivis et ils s’avèrent vraiment utiles pour les développeurs, car ils leur permettent de savoir si les nouveautés fonctionnent correctement, au lieu de supposer qu’elles fonctionnent correctement à cause de l’absence de bogues.

En ce qui concerne les outils d’assistance aux tests, beaucoup d’améliorations ont été apportées :

• Apport(1) a contribué à augmenter le niveau de détail des bogues signalés concernant Ubuntu : les rapports de plantage incluent toutes les informations de débogage et leurs doublons sont débusqués puis marqués comme tels ; les utilisateurs peuvent signaler des bogues sur base de symptômes, etc.
• Le Launchpad(2), avec ses connexions en amont, a permis d’avoir une vue complète des bogues – sachant que les bogues qui se produisent dans Ubuntu se situent généralement dans les projets en amont, et permet aux développeurs de savoir si les bogues sont en cours de résolution.
• Firefox, grâce à son programme et à son extension Test Pilot, mène des tests sans qu’on ait à quitter le navigateur(3). C’est, à mon sens, une bien meilleure façon de rallier des testeurs qu’une liste de diffusion ou un canal IRC.
• L’équipe Assurance Qualité d’Ubuntu teste le bureau en mode automatique et rend compte des résultats toutes les semaines(4), ce qui permet aux développeurs de vérifier très rapidement qu’il n’y a pas eu de régression majeure pendant le développement.

Cependant, malgré l’amélioration des tests dans les projets de logiciel libre il reste encore beaucoup à faire.

Pour aller plus loin

Les tests nécessitent une grande expertise, mais sont encore considérés au sein de la communauté du le logiciel libre comme une tâche ne demandant pas beaucoup d’efforts. L’une des raisons pourrait être que la manière dont on les réalise est vraiment dépassée et ne rend pas compte de la complexité croissante du monde du logiciel libre durant la dernière décennie. Comment est-il possible que, malgré la quantité d’innovations amenées par les communautés du logiciel libre, les tests soient encore réalisés comme dans les années 80 ? Il faut nous rendre à l’évidence, les scénarios de tests sont ennuyeux et vite obsolètes. Comment faire grandir une communauté de testeurs supposée trouver des bogues avérés si sa tâche principale est de mettre à jour les scénarios de test ?

Mais comment améliorer la procédure de test ? Bien sûr, nous ne pouvons pas nous débarrasser des scénarios de test, mais nous devons changer la façon dont nous les créons et les mettons à jour. Nos testeurs et nos utilisateurs sont intelligents, alors pourquoi créer des scripts pas-à-pas ? Ils pourraient aisément être remplacés par une procédure de test automatique. Définissons plutôt une liste de tâches que l’on réalise avec l’application, et certaines caractéristiques qu’elle devrait posséder. Par exemple, « l’ordre des raccourcis dans le lanceur doit pouvoir être modifié », ou « le démarrage de LibreOffice est rapide ». Les testeurs trouveront un moyen de le faire, et créeront des scénarios de test en parallèle des leurs.

Mais ce n’est pas suffisant, nous avons besoin de meilleurs outils pour aider les testeurs à savoir ce qu’ils testent, où et comment. Pourquoi ne pas avoir des API (interfaces de programmation) qui permettent aux développeurs d’envoyer des messages aux testeurs à propos des nouvelles fonctionnalités ou des mises à jour qui doivent être testées ? Pourquoi pas une application qui nous indique quelle partie du système doit être testée ? en fonction des tests en cours ? Dans le cas d’Ubuntu, nous avons les informations dans le Launchpad (il nous faudrait aussi des données sur les tests, mais au moins nous avons des données sur les bogues). Si je veux démarrer une session de test d’un composant en particulier j’apprécierais vraiment de savoir quelles zones n’ont pas encore été testées ainsi qu’une liste des cinq bogues comptant le plus de doublons pour cette version en particulier afin d’éviter de les documenter une fois de plus. J’aimerais avoir toutes ces informations sans avoir à quitter le bureau que je suis en train de tester. C’est quelque chose que Firefox a initié avec Test Pilot, bien qu’actuellement l’équipe rassemble principalement les données sur l’activité du navigateur.

La communication entre l’amont et l’aval et vice-versa doit aussi être améliorée. Pendant le développement d’une distribution, un bon nombre des versions amont sont également en cours de développement, et ont déjà une liste des bogues connus. Si je suis un testeur de Firefox sous Ubuntu, j’aimerais avoir une liste des bogues connus aussitôt que le nouveau paquet est poussé dans le dépôt. Cela pourrait se faire à l’aide d’une syntaxe reconnue pour les notes de versions, syntaxe qui pourrait ensuite être facilement analysée. Les rapports de bogue seraient automatiquement remplis et reliés aux bogues amont. Encore une fois, le testeur devrait avoir facilement accès à ces informations, sans quitter son environnement de travail habituel.

Les tests, s’ils étaient réalisés de cette manière, permettraient au testeur de se concentrer sur les choses qui comptent vraiment et font de la procédure de test une activité qualifiée ; se concentrer sur les bogues cachés qui n’ont pas encore été découverts, sur les configurations et environnements spéciaux, sur la création de nouvelles manières de casser le logiciel. Et, in fine, s’amuser en testant.

Récapitulons

Pour ce que j’en ai vu ces trois dernières années, les tests ont beaucoup progressé au sein d’Ubuntu et des autres projets de logiciels libres dans lesquels je suis plus ou moins impliquée, mais ce n’est pas suffisant. Si nous voulons vraiment améliorer la qualité du logiciel libre, nous devons commencer à investir dans les tests et innover dans la manière de les conduire, de la même façon que nous investissons dans le développement. Nous ne pouvons pas tester le logiciel du XXIe siècle avec les techniques du XXe siècle. Nous devons réagir. Qu’il soit open source ne suffit plus à prouver qu’un logiciel libre est de bonne qualité. Le logiciel libre sera bon parce qu’il est open source et de la meilleure qualité que nous puissions offrir.

1 http://wiki.ubuntu.com/Apport

2 http://launchpad.net

3 http://testpilot.mozillalabs.com

4 http://reports.qa.ubuntu.com/reports/desktop-testing/natty