Antirez est un développeur de logiciel libre… ou plutôt open source, car c’est l’expression qu’il semble privilégier.

Il nous livre ici le fruit de sa petit réflexion.

Ainsi il préfère les licences permissives à celles copyleft. Ce qui ne l’empêche pas de souhaiter voir plus de rétribution dans le domaine, parce que si l’on est obligé de payer sa facture autrement alors il y aura moins de code utile à disposition de tous.

Quelques réflexions sur le logiciel open source

A few thoughts about Open Source Software

Antirez – janvier 2013 – Blog personnel
(Traduction : FanGio, peupleLà, ehsavoie, Tibo, Sphinx, Penguin + anonymes)

Voilà plus de quinze ans que je contribue régulièrement à l‘open source, et cependant je m’arrête assez rarement pour réfléchir à ce que cela représente pour moi. C’est probablement parce que j’aime écrire du code et que c’est ainsi que je passe mon temps : écrire du code plutôt que réfléchir à ce que cela signifie… Cependant ces derniers temps, je commence à avoir des idées récurrentes sur l‘open source, ses relations avec l’industrie informatique et mon interprétation de ce qu’est le logiciel open source pour moi, en tant que développeur.

Tout d’abord, l‘open source n’est pas pour moi une manière de contribuer au mouvement du logiciel libre, mais de contribuer à l’humanité. Cela veut dire beaucoup de choses, par exemple peu m’importe ce que les autres font avec mon code ou qu’ils ne reversent pas leurs modifications. Je veux tout simplement que des personnes utilisent mon code d’une manière ou d’une autre.

En particulier, je veux que les gens s’amusent, apprennent de nouvelles chose et se « fassent de l’argent » avec mon code. Pour moi, que d’autres se fassent de l’argent avec le code que j’ai écrit n’est pas une perte mais un gain.

1. J’ai beaucoup plus d’impact sur le monde si quelqu’un peut payer ses factures en utilisant mon code ;
2. Si N personnes gagnent de l’argent avec mon code, peut-être qu’elles seront heureuses de m’en faire profiter ou plus disposées à m’engager ;
3. Je peux être moi-même l’une de ces personnes qui gagnent de l’argent avec mon code, et avec celui d’autres logiciels open source.

Pour toutes ces raisons, mon choix se porte sur la licence BSD qui est en ces termes l’incarnation parfaite de la licence « faites ce que vous voulez ».

Cependant, il est clair que tout le monde ne pense pas de même, et nombreux sont les développeurs contribuant à l‘open source qui n’aiment pas l’idée que d’autres puissent prendre le code source et créer une entreprise qui ferait un logiciel commercial sous une autre licence.

Pour moi, les règles que vous devez suivre pour utiliser une licence GPL représentent une barrière qui réduit la liberté de ce que les personnes peuvent faire avec le code source. De plus, j’ai le sentiment qu’obtenir des contributions n’est pas tellement lié à la licence : si quelque chose est utile, des personnes vont contribuer en retour d’une manière ou d’une autre, car maintenir un fork n’est pas simple. La véritable valeur se trouve là où le développement se produit. Du code non corrigé, qui n’évolue pas, ne vaut rien. Si, en tant que développeur open source, vous pouvez apporter de la valeur, des parties tierces seront encouragées à faire intégrer leurs modifications.

Cependant, je suis beaucoup plus heureux quand il y a moins de correctifs à fusionner et plus de liberté du point de vue des utilisateurs, plutôt que l’inverse, il n’y a donc pas grand chose à discuter pour moi.

De mon point de vue, ce que l‘open source ne reçoit pas suffisamment en retour, ce ne sont pas les correctifs mais plutôt l’argent. Le nouveau mouvement des startups, et les faibles coûts opérationnels de nombreuses entreprises IT viennent de l’existence même de tout ce code open source qui fonctionne bien. Les entreprises devraient essayer de partager une petite partie de l’argent qu’elles gagnent avec les personnes qui écrivent les logiciels open source qui sont un facteur clé de leur réussite, et je pense qu’une manière saine de redistribuer cet argent est d’embaucher ces développeurs pour qu’ils écrivent du logiciel open source (comme VMware l’a fait pour moi), ou de faire des dons.

Beaucoup de développeurs travaillent pendant leur temps libre par passion, seul un petit pourcentage parvient à être payé pour leur contribution à l‘open source. Une éventuelle redistribution peut permettre à plus de gens de se concentrer sur le code qu’ils écrivent par passion et qui a peut être « un impact plus important » sur l’économie que le travail qu’ils font pour obtenir leur salaire chaque mois. Et malheureusement, il est impossible de payer les factures avec des PULL REQUESTS, c’est pourquoi je pense qu’apporter de l’aide à un projet sous forme de code est une bonne chose, mais ce n’est pas suffisant.

Vous pouvez avoir un point de vue différent sur tout cela, mais ce que j’observe, c’est que le logiciel open source produit beaucoup de valeur dans l’industrie informatique actuelle, et qu’il est souvent écrit sur son temps libre ou en jonglant entre les différentes tâches pendant son temps de travail, si votre employeur est assez souple pour vous permettre de le faire.

Ce que je pense, c’est que cela est économiquement sous-optimal, beaucoup de codeurs intelligents pourraient donner une impulsion à l’économie s’ils étaient plus libres d’écrire du code qu’ils aiment et que beaucoup de gens utilisent sans doute déjà pour faire de l’argent.

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

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

Traduction Framalang : ga3lig, Fred, peupleLa, LAuX, Goofy, jcr83, purplepsycho, Jej, Jean-Noël AVILA, Julius22, kalupa, 4nti7rust, lamessen, okram + Cédric Corazza

Écrire des correctifs

Kai Blin

Kai Blin est un bio-informaticien qui mène des recherches sur les antibiotiques dans le cadre de ses activités quotidiennes, tant sur ordinateur qu’au labo. Il est très heureux de pouvoir diffuser le logiciel développé dans le cadre de ses activités professionnelles sous licence open source. Vivant dans la charmante ville de Tübingen, dans le sud de l’Allemagne, Kai passe une partie de ses soirées sur l’ordinateur, à programmer pour le projet Samba. Il consacre la majorité de son temps libre restant au théâtre, où il participe aussi bien à la performance scénique qu’à la construction d’accessoires et à la régie technique dans les coulisses.

Écrire des correctifs et les proposer est souvent la première interaction concrète que vous pouvez avoir avec un projet open source. C’est la première impression que vous donnez aux développeurs présents. Proposer de « bons » premiers correctifs, ou tout du moins jugés comme tels par le projet auquel vous contribuez, vous rendra la vie plus facile. Les règles précises d’écriture du correctif, de la façon de le soumettre au projet et tous les autres détails nécessaires vont sans doute varier selon les divers projets auxquels vous voulez contribuer. Mais j’ai trouvé quelques règles générales que l’on retrouve presque à chaque fois. Et c’est ce dont traite cet article.

Comment tout foirer

Le fil rouge de ce livre est « ce que j’aurais aimé savoir avant de commencer », aussi permettez-moi de commencer par l’histoire de mes premiers correctifs. J’ai été impliqué sérieusement dans l’écriture de code pour la première fois pendant le Google Summer of Code™ de 2005. Le projet Wine avait accepté que j’implémente un chiffrement NTLM basé sur des outils connexes à Samba. Wine est un projet à committer unique, ce qui signifie que seul le développeur principal, Alexandre Julliard, possède les autorisations de commit sur le dépôt principal. En 2005, Wine utilisait encore CVS comme système de gestion de versions. Quand le projet a démarré et que j’ai reçu le courriel me disant que j’étais accepté, j’ai contacté mon mentor sur IRC et me suis mis au travail.

J’alignais joyeusement les lignes de code et bientôt j’ai pu implémenter les premières fonctionnalités. J’ai produit un correctif et l’ai soumis à mon mentor pour qu’il fasse une relecture. Au temps du CVS, il fallait renseigner toutes les options de diff(1) manuellement, mais je m’étais particulièrement documenté sur la partie cvs diff -N -u > ntlm.patch. De cette façon, j’avais le fichier que je pouvais envoyer à mon mentor. En fait, c’est quelque chose que j’ai bien fait. Et c’est la première chose que vous devriez prendre en compte quand vous préparez un correctif. Le résultat classique de la commande diff est sans doute plus facile à lire pour un ordinateur, mais je n’ai jamais rencontré un humain préférant le résultat classique au résultat d’un diff unifié. Grâce à l’option -u , diff utilise les notations + + + et - - -

Par exemple, le diff qui suit est le résultat de la réécriture de « Hello, World! » en Python, version suédoise.

diff —git a/hello.py b/hello.py index 59dbef8..6334aa2 100644 --- a/hello.py +++ b/hello.py @@ -1,4 +1,4 @@ #!/usr/bin/env python # vim: set fileencoding=utf-8 -print "Hello, world!" +print "Halla, varlden!" 

La ligne qui commence par « - » est la ligne supprimée, celle qui commence par « + » est celle qui va être ajoutée. Les autres lignes permettent à l’outil de correction de faire son travail.

J’ai envoyé le diff unifié que je venais de créer à mon mentor qui m’en a fait une review(2) en me signalant beaucoup d’éléments à modifier. J’ai effectué les corrections et lui ai renvoyé un nouveau diff peu de temps après. Le cycle d’analyse du code a continué durant toute la durée du GSoC et mon correctif ne cessait de grossir. Quand la date de livraison est arrivée, je me suis retrouvé avec un correctif monstrueux dans lequel étaient inclus tous mes changements. Naturellement, j’ai eu beaucoup de mal à obtenir une review de mon correctif, sans parler de le faire accepter. Pour finir, Alexandre refusa de regarder plus avant le correctif tant que je ne l’aurais pas scindé. Les règles en usage chez Wine exigent que les correctifs soient de petites étapes logiques ajoutant une fonctionnalité. Chaque correctif doit faire quelque chose d’utile et pouvoir être compilé.

De fait, scinder un énorme correctif existant en différentes parties cohérentes individuellement et qui peuvent être compilées représente beaucoup de travail. C’était même d’autant plus de travail que je ne connaissais qu’une seule manière de le faire : écrire un petit correctif, créer le diff, le proposer à la validation, mettre à jour ma contribution locale et écrire alors le correctif suivant. Peu de temps après que j’ai commencé à envoyer mes premiers petits correctifs, Wine est entré dans une phase de gel des fonctionnalités d’un mois menant à la version 0.9.0 bêta. Je suis resté sur le correctif suivant pendant un mois avant de pouvoir continuer et j’ai finalement envoyé mon dernier correctif en novembre. Complètement frustré par cette expérience, j’ai décidé que je ne voulais plus jamais avoir à faire avec la communauté Wine.

Ma frustration perdura jusqu’à ce que des personnes qui utilisaient réellement mon code commencent à me poser des questions sur celui-ci en février 2006. Mon code était vraiment utile ! Ils voulaient également davantage de fonctionnalités. Quand Google annonça qu’il reconduirait le GSoC en 2006, mes projets pour l’été étaient clairs. Maintenant que Wine avait basculé de diff à git en décembre 2005, je savais que je ne serais pas ennuyé par des gels de fonctionnalités, puisque je pouvais finalement créer tous mes petits correctifs localement. La vie était belle.

Ce n’est que lorsque je suis tombé sur une interface de git (appelée porcelaine dans le langage git) qui émulait le comportement de Quilt que j’ai appris qu’il y avait des outils qui auraient pu rendre ma vie plus facile, même en 2005.

Comment NE PAS tout foirer

Maintenant que je vous ai raconté comment j’ai réussi à me planter avec l’envoi de correctifs, permettez-moi de poursuivre avec quelques conseils pour éviter les pièges.

Règles pour la soumission de correctifs

Mon premier conseil est de lire attentivement toutes les directives de soumission de correctifs que peut avoir le projet auquel vous voulez contribuer. Celles-ci, ainsi que les normes de style de codage, doivent être consultées avant même de commencer à coder.

Des diffs unifiés

Même si ce n’est pas explicitement indiqué dans les directives de soumission des correctifs, vous devez vraiment, vraiment envoyer le résultat d’un diff unifié. Je n’ai encore rencontré aucun projet qui préfère la sortie non unifiée du diff. Les diffs unifiés rendent la révision du correctif beaucoup plus facile. Ce n’est pas par hasard que les programmes de gestion de version modernes utilisent automatiquement ce format dans leurs commandes diff par défaut.

Utilisez un contrôle de version distribué

En ce qui concerne la gestion de versions moderne, vous devriez vraiment utiliser un système de gestion de versions distribué (DVCS) pour travailler localement sur le code. Git et Mercurial sont les choix les plus populaires de nos jours, quoique Bazaar puisse aussi très bien faire l’affaire. Même si le projet auquel vous voulez contribuer utilise toujours un système de gestion de version centralisé, être en mesure d’envoyer vos changements de manière itérative est une très bonne chose. Tous les outils de gestion de versions distribués mentionnés ci-dessus devraient être capables d’importer des changements depuis un SVN ou un CVS. Vous pourrez y aller et apprendre doucement Quilt mais, sérieusement, le futur passe par les systèmes de gestion de versions distribués.

De petits correctifs, pour faire une chose à la fois

Quand je dois examiner des correctifs, les plus ennuyeux à traiter sont ceux qui sont trop gros ou qui tentent de faire de nombreuses choses en même temps. Les correctifs qui ne font qu’une chose à la fois sont plus faciles à traiter. Au final, ils vous faciliteront la vie quand vous devrez déboguer les erreurs qu’auront manquées à la fois l’auteur et le vérificateur.

Suivez votre correctif

Après avoir proposé votre correctif, gardez un œil sur les canaux de communication du projet et sur votre correctif. Si vous n’avez eu aucun retour au bout d’une semaine, vous devriez poliment en demander un. En fonction de la façon dont le projet gère les propositions de correctif, celui-ci pourrait être noyé dans le bruit. N’espérez pas voir votre correctif retenu du premier coup. Il faut, en général, quelques essais pour s’habituer au style d’un nouveau projet. En tant que contributeur néophyte, personne ne vous en voudra pour ça, à condition d’avoir presque tout bon. Assurez-vous seulement de corriger ce que les développeurs vous ont indiqué et envoyez une seconde version du correctif.

Conclusion

Écrire de bons correctifs n’est pas difficile. Il y a deux ou trois choses à prendre en considération. Mais après en avoir écrit quelques-uns vous devriez être au point sur celles-ci. Un système moderne de contrôle de version (distribué) et le workflow (Ndt : flux de production) qui en résulte gèreront de fait la plupart des choses que j’ai mentionnées. Si vous n’avez qu’une chose à retenir, c’est ceci :

• Utilisez un système de contrôle de version distribué pour gérer vos correctifs.
• Écrivez vos correctifs en petites étapes indépendantes.
• Suivez les normes de codage en vigueur.
• Répondez rapidement aux commentaires sur vos correctifs.

Les quelques lignes directrices ci-dessus devraient vous aider à bien faire la plupart des choses, sinon toutes, quand vous soumettrez vos premiers correctifs. Bon codage.

(1) Un diff (abréviation de différence) est un fichier qui affiche le résultat d’une comparaison entre deux éléments (en général, des lignes de code). Pour en savoir plus : http://fr.wikipedia.org/wiki/Diff

(2) Review : révision minutieuse http://fr.wiktionary.org/wiki/review

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

Libres conseils (1/42)

Traduction framalang peupleLa, tibs, Astalaseven, aKa, lerouge, Vilnus Atyx, liu qihao, Cyrille L., Khyvodul, jcr83, jcr83, Goofy, Gatien Bovyn, Antoine, lamessen, AlBahtaar + 2 anonymes

Première Partie, Idées et innovations

1. Du code avant toute chose

Armijn Hemel a utilisé des logiciels libres depuis 1994, lorsque son frère est revenu à la maison avec une pile de disquettes contenant l’une des premières versions de FreeBSD. Un an après, il migrait vers GNU/Linux, et depuis il n’utilise plus que des systèmes de type Unix, que ce soit chez lui, pour ses études à l’université d’Utrecht ou au travail. Depuis 2005, Armijn est membre du noyau dur de l’équipe de gpl-violations.org tout en possédant son propre cabinet de conseil (Tjaldur Software Governance Solutions) spécialisé dans la détection et la résolution de litiges nés de violations de licences GPL.

En 1999, je faisais tout juste mes premiers pas dans l’activisme du logiciel libre et Open Source. J’utilisais déjà Linux et FreeBSD depuis un certain nombre d’années, mais je n’étais encore qu’un simple utilisateur et je souhaitais apporter une contribution en retour. De mon point de vue, la meilleure manière de le faire était d’écrire du code. Étant donné que je ne trouvais aucun projet existant dans lequel j’aurais été à l’aise pour travailler, j’ai décidé de commencer mon propre projet. Avec le recul, je constate que plusieurs raisons m’ont poussé à débuter ce projet. L’une tenait à mes doutes sur le fait que mon code était d’une qualité suffisante pour être accepté dans un projet existant (je n’étais pas un programmeur brillant et d’ailleurs je ne le suis toujours pas), alors que pour un projet personnel, la question ne se pose pas. La seconde raison est certainement l’arrogance de la jeunesse.

Mon idée était de créer un logiciel de présentation, qui pourrait imiter la plupart des fonctionnalités les plus avancées (ou si vous préférez, les plus pénibles) de PowerPoint. À ce moment-là, OpenOffice.org n’existait pas et le choix était relativement limité : LaTeX et MagicPoint, qui sont davantage orientés vers le contenu textuel que sur les effets d’animation. Je voulais créer un logiciel multi-plateforme, et j’ai pensé que pour remplir cet objectif Java serait le meilleur choix.

Le concept était de faire un logiciel de présentation, écrit en Java, qui aurait intégré tous ces effets animés. Je me suis décidé et j’ai commencé le projet.

Toute l’infrastructure nécessaire était déjà disponible : une liste de diffusion, un site web, un système de gestion de versions (CVS). Mais il n’existait aucun code source qui aurait permis à des contributeurs potentiels de travailler directement . La seule chose en ma possession, c’était quelques idées de ce que je voulais faire, une démangeaison à soulager, et des slogans publicitaires séduisants. Je voulais en fait que beaucoup de gens rejoignent le projet pour que celui-ci devienne réellement un projet collaboratif.

J’ai commencé par faire des plans (avec mes nouvelles connaissances en UML) et à les faire circuler. Rien ne s’est passé. J’ai essayé d’impliquer des contributeurs, mais créer une architecture de manière collaborative est très difficile (sans compter qu’a priori, ce n’est sûrement pas le meilleur moyen de créer un logiciel). Après un certain temps, j’ai laissé tomber et le projet est mort en silence, sans qu’une seule ligne de code ait été écrite. Chaque mois je recevais des messages par la liste de diffusion qui me rappelaient que ce projet avait un jour existé, j’ai donc demandé sa mise hors-ligne.

J’en ai tiré une leçon précieuse, quoiqu’un peu douloureuse : dès lors que vous annoncez quelque chose et que vous souhaitez que les gens s’impliquent dans votre projet, assurez-vous au moins qu’il y ait un minimum de code disponible. Peu importe qu’il ne soit pas complètement terminé ; il est acceptable même s’il est mal dégrossi (au début en tout cas). Mais au moins cela démontre l’existence d’une base sur laquelle des contributeurs peuvent travailler et ainsi l’améliorer. Dans le cas contraire, votre projet finira de la même manière que tant d’autres, dont le mien : aux oubliettes.

Finalement, j’ai trouvé mon créneau pour contribuer au progrès du logiciel libre et open source, en m’assurant que les fondements légaux de ceux-ci restent protégés par l’intermédiaire du projet gpl-violations.org. Rétrospectivement, je n’ai jamais utilisé — sans en éprouver de frustration d’ailleurs — les effets animés dans les logiciels de présentation. En fait, je les trouve de plus en plus irritants, ils nous distraient trop du contenu. Pour faire mes présentations, je suis un utilisateur heureux de LaTeX Beamer et occasionnellement — mais avec moins de plaisir — d’OpenOffice.org/LibreOffice.

Crédit photo vampir 42 (CC-BY-SA)

Au fait, les libristes ont aussi un corps.

Et ils apprennent parfois à leurs dépens que dans le monde médical, le code propriétaire et les formats fermés peuvent empêcher d’avoir de meilleures chances de se soigner. Souvenez-vous de Salvatore Iaconesi, dont nous avions traduit les déclarations, qui voulait avoir accès à ses données médicales dans un format ouvert.

C’est une histoire personnelle comparable que raconte Karen Sandler au cours d’une conférence que nous vous proposons ici. Karen Sandler est loin d’être une inconnue dans le monde du Libre notamment par son militantisme et ses responsabilités au sein de la Gnome Foundation.

Découvrir qu’un problème cardiaque menace d’un jour à l’autre votre vie même est une épreuve que vous pouvez surmonter en faisant appel à un appareillage de haute technologie (pacemaker, défibrillateur…). Mais découvrir que cette technologie repose sur un code auquel on n’a pas accès, c’est comme le fait Karen prendre conscience que sa vie est à la merci d’un bug dans un code inaccessible…

Non seulement Karen livre ici avec humour le récit de ses déboires, mais elle évoque également d’autres domaines de la vie quotidienne où l’accès au code est désormais crucial. La vidéo qui suit, dont la transcription, la traduction et le sous-titrage ont été assurés par : FredB, Pandark, peupleLa, ga3lig, KoS, Mnyo, Lamessen, goofy, est relativement longue (54 minutes). Ceux qui ne disposent pas d’un long temps de lecture pourront découvrir de larges extraits de la conférence dans le texte sous la vidéo.

Note : je vois d’ici venir dans les commentaires tous ceux qui ne pourront résister au plaisir de faire un jeu de mots recyclant une des deux cent cinquante expressions comprenant le mot cœur. Eh bien, ils auront un gage ! À chaque astuce publiée en commentaire ils devront faire un petit don à Framasoft qui ne vit que de etc. voir le mantra automnal de notre campagne en cours.

La liberté dans mon cœur et partout ailleurs

Cliquer sur l’image pour accéder à la vidéo de la conférence

Je suis vraiment, vraiment contente d’être ici. Ma conférence s’appelle La liberté dans mon cœur et partout ailleurs. Comme dit précédemment, je fais partie de la communauté Libre et Open Source depuis un moment. Je suis directrice exécutive de la fondation GNOME. Nous en reparlerons un peu plus tard, c’est vraiment cool. Et j’ai longtemps été avocate au Software Freedom Law Center, pour finir par en devenir la directrice juridique. Donc j’ai eu l’occasion de faire la connaissance de plein de gens dans la communauté du logiciel Libre et Open Source en les aidant avec tous les emmerdements dont ils ne voulaient pas s’occuper. Vraiment, vraiment amusant ! Je suis une passionnée du Libre et de l’Open Source, je dirais, depuis les années quatre-vingt-dix.
Et je suis aussi une patiente.

Un très gros risque de mourir subitement

J’ai un cœur vraiment, vraiment très grand. En fait, j’ai un cœur énorme.
Vous pensez sûrement à mon travail pour des associations, mais en fait, j’ai une hypertrophie du cœur. J’ai une maladie appelée cardiomyopathie hypertrophique. Je suis toujours un peu nerveuse quand je parle de ça parce que ça revient à dire que mon cœur est un petit peu cassé. Ce n’est pas vraiment ça. Mon cœur est très épais et ça veut dire qu’il a du mal à battre. Il est un peu raide. Mais au final, tout va bien. Pour l’instant, je n’ai aucun symptôme. J’ai seulement un très gros risque de mourir subitement. Le terme est littéralement mort subite. C’est ce que les docteurs vous expliquent quand vous avez cette maladie et que vous devez suivre un traitement à vie. Ils disent que vous avez un risque élevé de mort subite.
Ce qui, en tant que patiente, est vraiment terrifiant. Deux ou trois fois par an je risque de mourir subitement. Et ça se cumule, donc j’ai découvert ça à 31 ans, soit de 20% à 30% environ de risque de mort subite pour la décennie suivante. C’est vraiment, vraiment une chose terrible à entendre… mais il existe maintenant une solution ! C’est de se faire poser un défibrillateur.
Le principe d’un défibrillateur, c’est qu’il est installé dans votre cœur. D’ailleurs j’en ai un, il est juste ici. Il a l’air vraiment énorme là mais c’est environ gros comme ça et c’est juste ici. Il a des câbles qui se glissent dans mes vaisseaux sanguins et qui s’enfoncent dans mon cœur, et en gros, il me surveille constamment.
C’est comme avoir des gens qui vous suivent partout avec un défibrillateur électrique et si je tombe raide morte tout à coup, il m’enverra une décharge et je serai remise sur pieds — Et je ne mourrai pas ! C’est formidable.

Qu’est-ce qui tourne dessus ?

Donc, tout ça est merveilleux, parfait. L’électrophysiologiste que j’ai rencontré et qui m’a expliqué ça en avait quelques-uns dans le tiroir de son bureau afin de pouvoir les montrer à tous ses patients parce qu’en voyant à quel point cet appareil est petit, ça parait nettement moins inquiétant. Il l’a poussé vers moi sur le bureau, j’étais assise là, avec ma mère. Je l’ai pris…
Et il disait : « Prenez-le, voyez comme c’est léger… » Alors je l’ai pris et j’ai demandé : « Cool ! Qu’est-ce qui tourne dessus ? ». En réponse, j’ai eu droit à un regard médusé. Ma mère semblait elle aussi perplexe.
Le chirurgien m’a demandé « Mais de quoi parlez-vous ? » et j’ai répondu « Eh bien, de toute évidence cet appareil ne vaut que ce que vaut son logiciel, c’est-à-dire qu’il se base sur le logiciel pour savoir quand je risque une mort subite, que ce soit quand je traverse une rue alors que je n’aurais pas dû, ou que je décide de courir un marathon, ou pour n’importe quelle autre raison. Je suis dépendante de ce logiciel pour savoir quand il est approprié de m’envoyer une décharge et quand ça ne l’est pas. Quand mon cœur a besoin d’être stimulé ou pas. Et l’électrophysiologiste, bien sûr, n’avait pas de réponse à me donner. Il m’a dit « Personne ne m’a jamais demandé ça. Je n’avais jamais pensé au logiciel sur cet appareil. Ne bougez pas, il y a un représentant de Medtronic dans nos bureaux aujourd’hui. Je vais aller lui demander, c’est lui le fabricant, et ils auront sûrement déjà pensé à ça ».
Donc, le représentant arrive et j’essaie de lui expliquer « Je suis avocate au Software Freedom Law Center. Je m’intéresse au logiciel sur mon appareil. Je veux juste savoir comment ça marche, sous quoi ça tourne ? Est-ce que vous pouvez me le dire ? ». Il a répondu : « Personne ne m’a jamais demandé ça auparavant ». Donc, on a eu une conversation très intéressante, et il a conclu par :
« Je comprends, c’est une question très importante, voici mon numéro, appelez moi, et je vous mettrai en contact avec des gens qui pourront vous parler de ça ». Enhardie par cet échange, je l’ai appelé à Medtronic. Il m’a passé le service technique et j’ai commencé à laisser des messages… Mais au final, je me faisais continuellement refouler. Personne ne voulait me parler de ça.

Vous devez nous faire confiance…

J’ai appelé les deux autres principaux fabricants d’appareil médicaux, Boston Scientific et St Jude, et aucun n’a su me donner une vraie réponse non plus. À la fin, j’ai commencé à appeler en disant : « Écoutez, si quelqu’un me laissait voir le logiciel… Je signerai un accord de confidentialité », C’est contre mes principes en tant que militante d’un organisme à but non-lucratif dans un domaine technique. Je n’ai pas envie de signer un contrat qui m’empêcherait de partager ce que je découvre avec le reste du monde. Mais j’ai pensé :
« Au moins, moi, je pourrai voir le code source et j’aurai davantage confiance dans ce qu’on installe dans mon corps ». Mais, malheureusement, on m’a envoyé balader. On m’a dit non. J’ai parlé avec des gens très compréhensifs à Medtronic. J’ai rencontré d’excellents docteurs. Et ces gens me disaient « Oh, vous savez, nous sommes Medtronic, nous avons à cœur de nous assurer de l’absence de bogue dans les logiciels que nous installons sur ces appareils. Évidement, nous ne le vendrions pas si nous ne pensions pas qu’il est sûr. Pour toutes ces raisons, vous devez nous faire confiance».
Le docteur a ajouté que la FDA, l’Agence fédérale américaine des produits alimentaires et médicamenteux, approuve ces appareils. Donc votre réaction est clairement disproportionnée ». Et quand j’en parlais avec mon électrophysiologiste au téléphone, je disais que j’étais vraiment gênée par tout ça, parce que je pensais à tous ces gens qui portent ces appareils. Certains sont relativement puissants, Dick Cheney en avait un à l’époque. Il en a un encore plus impressionnant aujourd’hui, qui fait continuellement circuler son sang alors techniquement, il n’a pas de pouls. C’est un appareil vraiment fascinant !

Est-ce que je vais vraiment avoir un logiciel propriétaire à l’intérieur de mon corps ?

Les populations qui bénéficient de ces appareils sont souvent dans des positions de pouvoir. Donc on peut facilement imaginer une situation où quelqu’un voudrait éteindre ces appareils. Et l’électrophysiologiste à qui je parlais au téléphone était tellement contrarié, tellement contrarié…qu’il m’a raccroché au nez. Il m’a dit « Je pense que vous préparez quelque chose… je ne comprends pas.. ; je ne sais pas pourquoi ça vous dérange tellement. Si vous voulez un appareil, je vous aiderai mais je ne… Je pense que vous êtes… vous… »
Et il a raccroché.
C’est vraiment terrifiant parce qu’il m’avait précisé au début de la conversation qu’il installait ces appareils tout le temps. Il en installe parfois plusieurs par jour. Alors l’idée qu’il ait pu ne même pas s’être posé de question à propos du logiciel installé sur ces appareils le terrifiait. J’ai donc remis à plus tard et je me suis dit, il faut que j’arrête de penser à ça. C’est trop terrifiant.
Est-ce que je vais vraiment avoir un logiciel propriétaire à l’intérieur de mon corps ? Je ne sais pas. Ajoutez à ça cette histoire de « mort subite » et le fait d’avoir un équipement cousu à l’intérieur de mon corps. Ça fait beaucoup à gérer. Alors j’ai continué à remettre ça à plus tard jusqu’à ce que je ne puisse plus différer parce que mes amis et ma famille continuaient à m’en parler et à me dire « Nous nous inquiétons tellement pour toi, nous savons que tu peux mourir à tout instant » Ma mère… vous savez, évidemment je n’ai pas de ligne fixe et mon mobile ne capte pas bien dans mon appartement Et ma mère, si je ne la rappelais pas dans l’heure commençait à appeler tous mes amis en demandant « Vous avez parlé à Karen aujourd’hui ? Vous savez si elle va bien ? » Je suis allée déjeuner avec une amie, et elle m’a demandé où en était cette histoire. Et j’ai répondu « Eh bien, les compagnies médicales ne me rappellent pas. Et tu sais, je suis sûre que je vais me débrouiller. Et elle a fondu en larmes et dit :
« Tu sais, tu pourrais mourir. Aujourd’hui. Et je ne peux pas le supporter. Si tu ne règles pas cette histoire, je ne sais pas si je peux encore être ton amie. C’est une chose très grave et tu l’ignores juste pour… » ce qu’elle considérait comme un problème ésotérique.
J’ai vraiment compris ça et j’ai compris que je n’avais pas le choix. Alors j’ai eu un appareil. Je me le suis fait implanter et ça a pris un peu de temps pour me remettre de l’opération et aussi pour réfléchir à propos de ma propre situation, prendre un peu de recul, faire quelques recherches. Mais je me suis juré que si j’acceptais cet appareil, j’allais faire des recherches, écrire un article et parler des problèmes que j’avais rencontrés et auxquels la profession médicale, ou du moins, les professionnels de la médecine que j’avais interrogés n’avaient pas de réponse.

Un bogue pour cent lignes de code

Donc, j’ai découvert des choses en écrivant cet article, certaines peuvent sembler normales, mais d’autres vous surprendront. Les logiciels ont des bogues. (…) Et les appareils médicaux, comme l’a dit Matthew Garret, auront des bogues, parce que l’institut d’ingénierie logicielle estime qu’il y a environ un bogue pour chaque centaine de lignes de code. Donc même si la majorité des bogues était interceptés par les tests, même si les trois quarts des bogues étaient interceptés lors des tests, ça fait toujours un sacré nombre de bogues.
J’ai lu une étude qui observait les rappels d’appareils publiés par la FDA. Fondamentalement, l’étude portait sur l’ensemble des rappels et a déterminé ceux qui venaient vraisemblablement de pannes logicielles puis ils les ont évalués. Parmi ceux qu’ils ont pu étudier suffisamment et dont ils ont pu déterminer précisément les failles logicielles : 98% d’entre elles auraient pu être détectées de simples tests par paires.
Donc, pour les tests basiques que vous êtes en droit d’attendre sur n’importe équipement technologique — oui, la FDA les soumet à quelques tests. Mais si les entreprises ne font pas de tests basiques qu’est ce qu’on peut faire ?
Donc, les logiciels ont des bogues. Ici dans cette pièce, tout le monde le sait. Une autre chose que la plupart d’entre nous savons c’est que la sécurité par l’obscurité ça ne marche pas. Même si ça peut sembler contre-intuitif pour ceux qui ne sont pas dans cette pièce. Toutes les personnes à qui j’ai expliqué cette idée dans le corps médical m’ont répondu : « Mais je ne comprends pas… pourquoi voulez vous que les gens puissent voir le logiciel ? Si tout le monde peut voir le code source, il sera beaucoup plus facile de le pirater ! ».
Mais nous savons tous que ce n’est pas le cas. En fait, en publiant le code source, tout le monde peut le voir, et il est plus sûr. Mais c’est une question capitale en réalité. J’en parle dans mon article : Tués par le code qui cite un certain nombre d’études montrant que les professionnels de la sécurité approuvent cette idée.
Donc pour le moment, on a le pire des deux mondes : un code fermé qui ne profite pas d’une relecture et d’une correction par le plus grand nombre. Mais on manque également de sécurité sur ces appareils. Beaucoup d’entre eux émettent des informations en sans fil. C’est le standard aujourd’hui. Quand j’ai découvert cela, j’étais choquée. Vous êtes en train de me dire que mon appareil cardiaque va émettre en continu ? Considérant les conférences auxquelles j’assiste, les gens que je fréquente, je n’ai vraiment pas envie de voir mes informations diffusées.

algorithmes

Donc c’est une des choses que j’ai abordées avec les différents docteurs que j’ai pu rencontrer. Comme vous l’imaginez, j’ai abandonné cet électrophysiologiste qui m’avait raccroché au nez. Et je suis allée de cardiologue en cardiologue pour trouver quelqu’un qui puisse comprendre ces problèmes ou qui puisse au moins comprendre pourquoi cela m’inquiétait. Et j’ai fini par trouver un excellent cardiologue et excellent électrophysiologiste qui m’a dit « Je n’avais jamais pensé à cette question, mais je comprends que ça puisse poser problème. Vous avez besoin de cet appareil, vous ne pouvez plus attendre. Mais je vais travailler avec vous, et on va trouver un moyen de résoudre au moins certains des problèmes qui vous inquiètent ».
Donc, l’une des choses que mon électrophysiologiste a faites c’est qu’il a appelé les hôpitaux, l’un après l’autre jusqu’à ce qu’il trouve un ancien pacemaker.
Il m’a expliqué que, ma défaillance cardiaque étant simple, j’avais seulement besoin d’un appareil qui surveillait les rythmes dangereux et qui m’enverrait une décharge en cas d’alerte. C’est un algorithme bien plus simple que celui des nouveaux appareils. Beaucoup des nouveaux appareils ont un algorithme complexe de stimulation pour des patients ayant une grande variété de problèmes. On peut tout à fait comprendre les raisons des compagnies médicales. Ces appareils sont très difficiles à faire. Ils fabriquent des produits de haute précision. Et s’ils peuvent utiliser ces appareils dans des cas plus variés alors tout est pour le mieux.
De plus vous ne pouvez pas savoir quels genres de complications les patients vont éventuellement développer. Donc, pour le moment, je n’ai aucun symptôme mais je pourrais en développer et c’est génial d’avoir cette technologie de stimulation. Mais mon cardiologue électrophysiologiste m’a dit : « Bon maintenant on voit que vous avez besoin de quelque chose de simple. Alors pourquoi ne pas vous trouver un ancien modèle d’appareil ? »
Donc j’ai actuellement un ancien appareil qui communique par couplage magnétique et non par technologie sans fil. Mais mon père a ce type de pacemaker et quand il entre dans une pièce du bureau des techniciens ils changent son pouls. Donc, avant même qu’il ne soit assis ils savent énormément de choses sur lui et ils ont la capacité de vraiment l’affecter. C’est incroyable. Mais comme vous pouvez le voir sur le dernier point de cette diapo ces appareils ont été hackés. En fait, un groupe de réflexion de plusieurs universités travaillant ensemble a montré qu’en utilisant du matériel disponible dans le commerce vous pouvez hacker ces appareils et en prendre le contrôle. Non seulement, Ils sont parvenus à déclencher des décharges ce qui est déjà terrifiant en soi…
— Une fois, mon pacemaker s’est déclenché par erreur et je peux vous dire, que c’est comparable à un coup de pied dans la poitrine. Ça vous met au tapis au moins pour quelques minutes. J’ai été forcée de m’asseoir, c’était si épuisant, la surprise et l’inquiétude m’ont forcée à dormir quelques heures pour m’en remettre. C’est très éprouvant.
… donc non seulement ils sont parvenus à envoyer une décharge mais ils ont également pu arrêter le traitement. Si l’appareil stimulait le pouls, ils pouvaient l’arrêter et beaucoup de gens ont besoin de stimulation pour rester en vie. Beaucoup de gens ne peuvent monter les escaliers sans cette stimulation. Mon père en fait partie. Ils ont également pu récupérer des informations clefs à partir de ces appareils comme les numéros d’identifications médicaux, les noms des médecins, les numéros de série… Beaucoup d’informations personnelles sont diffusées et il n’y a aucun chiffrement sur ces appareils. C’est plutôt inquiétant. Ils sont également parvenus à mettre les appareils en mode test ce qui a pour effet de consommer la batterie. Euh, la batterie s’épuise à un rythme bien plus rapide que dans des circonstances normales et ces appareils n’ont d’intérêt que s’ils ont de la batterie. Donc si la batterie lâche sur mon pacemaker il me faudra un nouvel appareil, ce qui signifie une opération.

…au bout du compte, personne à la FDA n’a vu le code source.

Donc ces appareils ont été hackés. Ces conclusions sont arrivées bien après mon diagnostic. Les médecins s’appuient beaucoup sur le fait que ces appareils ont l’agrément de la FDA aux États-Unis, et d’institutions similaires dans d’autres pays. En bonne avocate, j’ai fait des recherches sur la FDA et leur processus d’approbation des logiciels. Ce que j’ai découvert, c’est que la FDA ne vérifie pas systématiquement le code source des appareils sauf en cas d’erreur particulièrement visible en lien avec le logiciel, ils ne demandent généralement pas à le vérifier.
Il n’y a même pas de cahier des charges clair pour le logiciel et il y a des raisons pour ces décisions de la FDA, mais nous croyons que celle-ci devrait faire beaucoup plus qu’elle ne fait en réalité. L’absence de cahier des charges clair est lié au fait, d’après eux, que ces sociétés conçoivent des appareils très spécialisés avec des particularités propres à chaque fabricant. Il y a donc probablement des tests spécifiques à ces appareils et les mieux placés pour les réaliser sont ceux qui connaissent le mieux ces machines, c’est à dire leurs fabricants. Et il y a des allers-retours pour savoir s’ils ont fait les bons tests ou non, mais en vérité, au bout du compte, personne à la FDA n’a vu le code source.
Puisqu’ils ne le demandent pas, ils n’en ont même pas de dépôt. Donc si une panne catastrophique se produit chez Medtronic, par exemple, je ne sais pas s’il y a un dépôt canonique pour le logiciel auquel je pourrais avoir accès… et sans possibilité de mise à jour du logiciel sur mon appareil, je devrais être opérée pour en avoir un nouveau.

Pas de liberté vis-à-vis de mon propre corps

J’ai parlé lors d’un débat, avec un type dans la cyber-sécurité à la FDA et j’étais vraiment, vraiment nerveuse parce que j’ai fait tout ce que je pouvais en tant qu’avocate, j’ai fait toutes les recherches que j’ai pu sur la FDA mais je n’étais pas sûre que c’était vraiment le cas en pratique, donc j’ai projeté mes diapos et dit :
« John, dis-moi si je me trompe, mais voilà ce que je pense. Je pense que ça se passe comme ça… » Et j’ai continué avec une diapo sur le logiciel Libre et Open Source et pourquoi c’est tellement mieux et plus sûr. Dès qu’il a eu la parole, il a dit :
« Tout le monde pense que la FDA devrait faire comme ci, comme ça, mais nous n’avons pas les ressources et la FDA n’est pas là pour ça ».
Puis il a fait une pause, m’a regardée et juste quand j’allais… vous savez. Et il a dit: « Mais vous parlez d’autre chose. Vous parlez de laisser tous les autres passer en revue le code source, c’est quelque chose de très intéressant. Donc, s’assurer que les logiciels de nos appareils seront publiés revient à dire que tout le monde pourrait les relire. Mon père, qui a un pacemaker, est également ingénieur et un heureux programmeur. Il l’aurait probablement examiné.
Beaucoup ici connaissent des gens avec des pacemakers nous aurions fouillé dans ce code, assurément ! Une autre chose que j’ai découverte qui est un peu étrange c’est qu’aux États-Unis, comme ces appareils ont l’agrément d’une agence fédérale, les patients ne peuvent pas recourir à la State True Law. Il y a donc tout un éventail de recours auxquels ont normalement accès les patients, dont les fabricants n’ont même pas à s’inquiéter. Bon maintenant je ne dirais pas que les entreprises de matériel médical se moquent de savoir si les malades meurent, évidemment que non. Mais il y a toute une série de recours légaux qui ne sont pas disponibles. Vraiment étonnante cette étude, et j’ai tout résumé dans l’article que j’ai écrit : il est disponible sur le site web du centre juridique pour le logiciel libre.
Au bout du compte je n’ai pas de liberté vis-à-vis de mon propre corps. Je n’ai pas l’autorisation d’analyser le logiciel qui est implanté en moi. Il est littéralement connecté et vissé à mon cœur et je ne peux pas l’examiner. Ça me semble incroyable. Je n’en reviens toujours pas du fait que ça me soit arrivé. C’est un peu bizarre que moi, avocate au Software Freedom Law Center j’aie cette maladie cardiaque étrange, je l’admets. Mais c’est toujours hallucinant que je n’aie pas eu le choix. Le seul choix était entre une grande probabilité de mourir, ou se faire implanter cet appareil à l’intérieur du corps. J’espère que personne ici n’aura à faire ce choix, mais c’était vraiment, vraiment effrayant.

Voitures

Puis j’ai commencé à y réfléchir, et vous voyez, ce n’est pas seulement une question d’appareils cardiaques. Ça concerne tout ce dont dépendent nos vies dans notre société. Alors que j’y réfléchissais, j’ai pris conscience que cela concernait beaucoup plus de domaines de nos vies que je ne le pensais. Par exemple, les voitures. Comme ce groupe de réflexion universitaire qui a travaillé sur les appareils médicaux, soit dit en passant, si vous avez du temps, vous devriez lire cette étude. C’est fascinant, ils ont implanté cet appareil dans un sac de bacon ou de viande quelconque pour le stimuler et ils ont montré tout l’équipement facilement trouvable qu’ils ont utilisé pour modifier l’appareil.
Et la même procédure à été appliquée aux voitures. Et un autre groupe a montré qu’ils sont parvenus à pirater deux marques différentes, deux fabricants différents de voitures. Donc l’IEEE affirme qu’une voiture haut de gamme compte près de 100 millions de lignes de code. Donc si on revient à ce que le Software Engineering Institute a dit : « environ un bogue toutes les 100 lignes de code » ça fait un paquet de bogues, juste dans votre voiture. Et ce ce groupe a réussi à faire, tout ce que vous pouvez imaginer. Ils sont capable de faire accélérer, freiner la voiture. Ils ont réussi à contrôler chaque roue individuellement. Et ma partie préférée, juste pour s’amuser, je ne sais pas si vous pouvez voir, mais ils peuvent mettre des messages sur le tableau de bord et ils ont écrit pwnd et mis une petite émoticône avec un X pour les yeux. L’idée qu’ils aient pu prendre contrôle de deux marques différentes de voitures haut de gamme est vraiment incroyable pour moi.

La sécurité par l’obscurité ne fonctionne pas

Les machines à voter sont un autre domaine très sensible et nous en avons déjà parlé.
Beaucoup d’experts en sécurité ont parlé des problèmes avec leurs machines à voter. Aux États-Unis, nous comptons sur Diebold et beaucoup de fabricants privés. Nous avons eu des problèmes avec l’étalonnage. Je ne sais pas si vous avez vu ce dessin animé hilarant dans lequel des gens essayent de voter pour le bon candidat et le nom du candidat pour qui ils veulent voter se dérobe sur l’écran tandis que vous essayez d’appuyer dessus et à la fin, quel que soit votre choix, ça dit : « Vous vouliez voter pour l’autre candidat, n’est-ce pas ? N’est-ce pas ? »
Il est très difficile de le savoir parce que parfois nous n’avons pas de reçu pour vérifier, on ne sait même pas si notre vote a bien été enregistré et si on a pu voter pour notre candidat au final.
Vraiment bizarre car c’est la base de notre société et le pilier de notre démocratie. J’adore ce qu’ils ont fait au Brésil. Je ne sais pas si vous en avez entendu parler, mais le Brésil a dit : « On sait que ces logiciels ont des failles et des bogues ; alors on invite les équipes de hackers à venir, on vous donnera le code source et on donnera un prix à quiconque trouvera un moyen de trouver une faille pour s’introduire dans le système ». Sur toutes ces équipes, deux ont trouvé des bogues. Aucun d’eux ne pouvait affecter une élection, mais ils ont pu les corriger. Et ces hackers ont reçu une récompense. La démocratie est plus sûre. La sécurité par l’obscurité ne fonctionne pas. Je ne sais pas quand nous allons enfin le comprendre mais le Brésil a su le faire. Donc c’est possible.
Nos institutions financières, ouais c’est passionnant, les institutions financières sont un autre domaine dont nous avons récemment pu observer les déboires quand elles déclinent. De nombreuses institutions utilisent des logiciels et les marchés boursiers et le fonctionnement de nos banques. Toutes ces choses sont critiques vis-à-vis de la manière dont nous vivons. C’est plus sociétal, mais nous avons déjà vu qu’il y a des vulnérabilités de ce côté. Tout cela pour dire, et j’insiste : mon appareillage médical peut être contrôlé !

Nous avons atteint le point où le logiciel doit être utilisable par tous.

Nos voitures peuvent être contrôlées et détraquées et nos institutions financières compromises. Nous sommes tous d’accord, les logiciels socialement et vitalement critiques doivent être sûrs. Mais nous sommes à une période très intéressante. Car comment savoir quel logiciel est d’un intérêt vital ou socialement critique ? La manière d’utiliser les ordinateurs a changé si rapidement et récemment… Je suis ébahie par la quantité de gens qui se sont mis à utiliser des ordinateurs comme ils ne l’avaient jamais fait.
Ce ne sont plus seulement des personnes à l’aise avec la technologie. C’est tout le monde, nos grands-parents, tout le monde. Et nous utilisons les logiciels pour tout, c’est devenu notre manière de tout faire. Comment nous communiquons. Comment nous parlons au téléphone. Comment nous écrivons, faisons de l’art. Comment nous gérons les institutions scolaires et comment nous gérons nos vies. Nous construisons cette infrastructure et nous n’y réfléchissons même pas.
Beaucoup de personnes utilisent leurs téléphones pour suivre des choses comme leur entraînement ou leur régime. C’est très pratique parce qu’on peut suivre ce qu’on a mangé au fur et à mesure, ce qu’on a fait. Certains téléphones ont des podomètres, et c’est assez basique mais il existe déjà un logiciel pour l’iPhone qui peut communiquer avec une pompe à insuline et évaluer l’exercice et le régime en fonction du niveau de sucres dans le sang.
Et nous voilà revenus à l’appareillage médical. Vous avez un iPhone sur lequel vous comptez pour votre vie. Nous créons tout cette infrastructure, et nous avons envie d’y réfléchir voilà pourquoi l’ordinateur personnel est si important. C’est en quelque sorte là où tout prend son sens dans mon histoire personnelle et les raisons pour lesquelles j’ai quitté le Software Freedom Law Center que j’aimais et me rendait très heureuse d’y être avocate pour pouvoir travailler et être à la Fondation Gnome que j’ai également quittée.
Et je parle d’ordinateur entre guillemets parce que ça va des manières d’interagir avec nos ordinateurs à la façon dont nous gérons nos vies à travers des logiciels. Nous avons atteint le point où le logiciel doit être utilisable par tous. Je pense que tout le monde ici doit connaître une personne plus âgée qui, il y a quelque années, n’avait probablement jamais rien fait avec son ordinateur.
Ma mère était l’une de ces personnes. Je me rappelle qu’étant enfant, je lui répétais :
« Mais maman, regarde ces super jeux ! — m’intéressent pas »
Et je me rappelle qu’au collège, je lui disais :
« Maman, si nous pouvions parler par courriel, ça serait tellement mieux ! — (Rien)…
Je me rappelle à l’école de droit, je disais :
« Maman, je peux effectuer toutes ces recherches sur mon ordinateur, sans avoir à rester toute la journée à la bibliothèque, c’est génial ! — (Rien)…
Plus tard, j’ai essayé de lui dire « Maman, j’organise mon voyage avec mon ordinateur ». Soudain, elle était un peu intéressée et maintenant, avec tout ce qui est arrivé elle ne peut plus rien faire sans son ordinateur. Maintenant, son ordinateur est devenu… Premièrement, elle envoie des courriels et des messages à ses amis, elle gère ses voyages et ses finances. C’est spectaculaire pour moi parce que je n’ai pas utilisé ici mon père qui est ingénieur, mais ma mère était vraiment un peu technophobe. Et maintenant, elle aime Apple. ELLE AIME APPLE. Elle peut utiliser son ordinateur pour… elle n’a pas à y penser.
C’est super, et c’est très frustrant pour moi. Mais je suis contente qu’elle puisse maintenant utiliser un ordinateur et c’est quelque chose qu’elle possède maintenant. Elle ne me pose pas de questions, enfin si, elle le fait… Mais elle ne voit pas de raison pour laquelle ces appareils ne lui seraient pas destinés et elle est très représentative de la majorité de notre société. Et ces gens n’auraient pas été aussi capables il y a quelques années, de faire autant avec leurs ordinateurs. Nous devons séduire des gens parce que ce sont ceux qui choisissent d’adopter l’iPhone pour mettre en relation leur exercice et leur régime avec leur pompe à insuline.
C’est le genre de chose dont nous devons nous préoccuper parce que si nous ne rendons pas nos logiciels simple pour tout le monde, personne ne voudra les utiliser. Et nous avons aujourd’hui une opportunité, une fenêtre qui se referme lentement parce que nous faisons maintenant des choix avec lesquels nous allons devoir vivre longtemps. Nous créons des habitudes, nous créons des attentes et nous établissons la mesure de notre société concernant ce qui est ou non acceptable pour un logiciel.
Vous êtes ici, à LinuxConfAu, vous connaissez les raisons pour lesquelles vous devriez utiliser des logiciels Libres et Open Source. Vous êtes ici pour toutes ces raisons y compris parce que c’est vraiment amusant. Nous avons passé un bon moment ici, et appris toutes sortes de choses vraiment cool mais derrière tout ça, la source d’où proviennent toutes ces raisons, c’est la Liberté.
Le logiciel Libre et Open Source n’est pas juste un marché profitable c’est aussi la bonne chose à faire. Donc lorsque nous parlons de nos appareils cardiaques, nous parlons de nos machines à voter et ensuite de la manière de vivre nos vies et de l’infrastructure par laquelle nous communiquons.
Nous voyons que le logiciel Libre et Open Source est exactement ce qu’il faut à notre société et pour l’apporter aux autres gens nous devons nous assurer que c’est facile et simple à utiliser pour eux.
(…)
Nous devons franchir la barrière, nous devons fournir des logiciels utilisables par des gens qui sinon ne pourraient pas s’en servir. Nous devons nous assurer que nos ordinateurs sont accessibles à tous parce que nous ne pourrons pas créer la bonne infrastructure pour toute la société si nous n’embarquons pas ces gens avec nous. (…)
Vous savez, nous avons la technologie, c’est bien agréable. Je n’ai plus vraiment besoin de bidouiller mon bureau. Je suis passée sur Gnome-Shell, et c’est brillant et très bien fait, j’ai à peine besoin de lignes de commande pour les choses en lien avec mon environnement de travail et uniquement quand je me sens bloquée. Ce n’est pas pour tout le monde, mais nous devons faire le choix du libre et des plateformes ouvertes, nous avons besoin de développer là-dessus parce que c’est le seul moyen que nous ayons de créer des sociétés meilleures et plus sûres. C’est le seul moyen de créer un monde où nous saurons que nos logiciels seront revus et qu’ils auront leur intégrité. Nous devons construire nos communautés dans l’espace non lucratif car nous devons établir ce très haut degré de confiance. Nous devons réinvestir notre idéologie dans le logiciel libre. Pour aller un peu plus loin je dirais : il ne s’agit pas de terminologie, mais d’idéologie. Nous devons vraiment penser à rendre le monde meilleur car nous le pouvons et nous le devons. Choisissons les logiciels libres et ouverts pour nous-mêmes et pour notre société.

Des kids, du code et du cake…

Le 29 septembre dernier je me suis rendu avec Adrienne Alix (Wikimédia France), Frédéric Couchet (April, de dos sur la première photo) et nos enfants respectifs à un « Coding Goûter » parisien.

Jugeant l’expérience tout à fait intéressante, et ma fille aussi (au tableau sur la seconde photo, présentant son travail sur Scratch), j’ai proposé aux organisateurs Julien Dorra, Jonathan Perret et Raphaël Pierquin un entretien pour en savoir plus et donner éventuellement envie d’essaimer.

Bonjour, pouvez-vous vous présenter succinctement ?

Julien : J’anime des communautés techno-créatives 🙂 C’est à dire que je crée les bonnes conditions pour que des personnes d’horizons différents créent avec les technologies d’aujourd’hui. Dans des universités, pour des institutions, et bien sûr avec Dorkbot Paris, Museomix, ArtGame weekend… et Coding Goûter !

Jonathan et Raphaël : Nous sommes tous les deux papas et développeurs. Nous travaillons chez /ut7, une coopérative d’agilistes. Notre métier, c’est d’aider d’autres développeurs à travailler en équipe. Nous animons aussi des ateliers de co-apprentissage avec des enfants de plus de 25 ans : nos formations, mais aussi Dojo de Développement, Agile Open, Dojo Lean Startup, soirées Cambouis…

Alors un « Coding Goûter » c’est quoi ?

Raphaël : Un Coding Goûter, c’est un rendez-vous festif avec des gâteaux, où petits et grands apprennent à programmer, ensemble.

Julien : C’est aussi un moment pour partager le plaisir de créer des choses avec du code, et d’expérimenter. Et pour les adultes qui, comme moi, ont programmé quand ils étaient enfants mais ont ensuite arrêté d’écrire des programmes – c’est une manière de réveiller une pratique qui était passé au second plan. Il y a des peintres du dimanche, je me revendique comme codeur du dimanche !

Comment l’idée est-elle donc née ?

Julien : J’ai rencontré Jonathan lorsqu’il a participé au premier – et au second ! – ArtGame weekend. Après ça, on a beaucoup discuté de ce que pouvait signifier l’éducation au code, de l’impact des nouveaux outils, à quoi pouvait ressembler un jeu de programmation.

Jonathan : Je cherchais à partager avec mes filles mon métier de développeur, mon plaisir d’écrire des programmes. J’étais frustré de ne pas trouver les moments « à la maison ». D’où l’idée d’un goûter avec des enfants, où l’on programmerait.

Julien : J’ai lancé de mon côté une petite enquête pour mieux comprendre ce que les parents (non tech inclus) pensaient du sujet. Les dizaines de réactions extrêmement diverses nous ont assez étonnés. Cela allait de l’évidence, au dégoût de l’idée même d’apprendre aux enfants à programmer !

Jonathan : Finalement, un matin de décembre 2011, j’ai réalisé que nous avions déjà toutes les cartes en main. Il suffisait de choisir une date, lancer des invitations et ouvrir les bureaux de /ut7 un samedi après-midi.

Raphaël : Quand Jonathan a évoqué son idée, j’étais enthousiaste. Ma motivation première, était de montrer à mes enfants ce qu’était mon métier. Après plusieurs séances, ce qui persiste, c’est le même plaisir que celui de jouer aux LEGO avec mon fils : s’amuser en construisant des choses ensemble.

Vous en êtes désormais à huit Coding Goûters, quel retour d’expérience en faites-vous ? Qu’est-ce qui a bien fonctionné ? Qu’est-ce qui peut être amélioré ?

Julien : On sait qu’il ne faut pas trop d’enfants, 12 c’est bien. On sait aussi que à la maison, ça marche moins bien, on est pas assez hors-contexte. Il y a plein de sollicitations, y compris pour les grands !

Raphaël : Une leçon essentielle que j’ai apprise : quand il s’agit d’apprendre, les adultes sont des enfants comme les autres. Une autre encore : c’est important de ponctuer les goûters avec des pauses où l’on prend le temps de célébrer les réalisations des participants. Une piste d’amélioration : publier un petit manuel pour aider de potentiels organisateurs de Coding Goûters à se lancer.

Est-ce facile de gérer en même temps différentes classes d’âge (quant on sait par exemple les écarts qu’il peut y avoir entre un enfant de 6 ans et de 12 ans) ?

Julien : Cela ne se pose pas dans ces termes. On vient avec nos enfants. Chacun fait.

Raphaël : Nous utilisons le même principe que dans les formations pour adultes de /ut7 : une grande variété d’activités, et la liberté pour chacun de choisir ce dont il a besoin pour apprendre. Ça marche très bien, encore mieux qu’avec des groupes sans enfant.

Julien : Séparer les classes d’âge peut sembler plus facile, mais c’est une homogénéité fictive. Les enfants d’un même âge n’ont ni le même niveau, ni les mêmes envies. Par exemple un enfant de 10 ans avait envie de créer des applications iPad, ce qui l’a motivé pendant tout un goûter pour explorer Xcode et Objective-C. Un grand de 14 ans pendant ce temps-là faisait du RoboZZle.

Plutôt que des séances « one shot » envisagez-vous d’organiser à terme des « Coding Goûter » plus réguliers tout au long de l’année avec le même groupe d’enfants-parents ? Et de ce fait pouvoir alors proposer quelque chose de plus structuré et progressif ?

Julien : Ce ne sont déjà plus des séances uniques, puisque nous avons organisé près d’un Coding Goûter par mois tout au long de 2012. Selon leurs disponibilités, les enfants et les adultes reviennent d’un goûter à l’autre. Mais derrière cette régularité, il n’y a pas de volonté de structurer l’apprentissage, ni d’introduire de la progressivité. C’est un moment d’exploration, de découverte. Le but n’est pas d’enseigner. Le but n’est pas l’acquisition de compétence en soi. De la même manière que l’on ne fait pas faire du dessin aux enfants pour qu’ils acquièrent une compétence technique précise.

Raphaël : Pour moi, le Coding Goûter est avant tout un loisir créatif, famillial et social. De fait, les familles qui participent, ponctuellement ou régulièrement forment une communauté qui crée une continuité entre chaque séance. Néanmoins, nous ne suivons pas de plan d’une séance sur l’autre, et ce n’est pas prévu.
Je me lancerai peut-être un jour dans la construction d’un programme structuré, mais ça sera en plus du Coding Goûter.

Ne pensez-vous pas que les « Coding Goûter » viennent combler une lacune, un vide de l’Education nationale ? Un déficit aussi bien dans le fond (inviter à coder, à créer) que dans la forme (le dispositif pédagogique assez novateur que vous proposez). A moins que vous jugiez que tout va bien et que chacun est à sa place ?

Raphaël : La pauvreté du programme informatique de l’école m’attriste, et le potentiel de progression est énorme. Attention néanmoins : la recette des Coding Goûters n’est pas nécessairement adaptée au contexte de l’école.

Jonathan : Je regrette également de voir que l’école ne donne plus aux enfants l’occasion de découvrir la magie de la programmation, comme nous en avons eu la chance à l’époque du plan « Informatique pour tous », mais elle ne peut peut-être pas tout faire non plus…

Julien : Au cours des prochaines années, on va à nouveau beaucoup entendre parler de l’enseignement de la programmation. La discussion est actuellement très active au Royaume-Uni, cela va revenir en France.
Et tu peux être sûr que cela sera principalement axé sur le « besoin de développeurs pour l’économie numérique ». On n’est pas du tout sur cet axe. On a envie que nos enfants programment, et oui, c’est vrai qu’ils ne le font pas à l’école et c’est dommage – car ils vont passer beaucoup de temps à l’école. Mais on ne cherche pas à fournir des développeurs aux SSII françaises dans 15 ans ! Probablement même le contraire 🙂
Est-ce qu’on comble un manque ? Avant tout, on comble un manque… pour nous et nos enfants ! Puis les enfants de nos amis, de nos collègues 😉
D’une certaine manière, on a été obligés de reconnaître qu’on répondait à un besoin fort, car nous avons des emails réguliers de parents qui veulent en organiser dans leur ville, ou être avertis du prochain goûter. À peine visibles, nous étions déjà sollicités.
Est-ce qu’on peut-être une part de la réponse aux difficultés de l’école de s’ouvrir aux changements sociaux en cours ? Pour l’instant non : on est en parallèle du système scolaire, et nous n’avons aucun lien avec les instances scolaires.

Si je vous dis que les « Coding Goûter » c’est quand même encore un « truc de bobos », vous pensez que c’est juste un gros troll ou bien une remarque valide ?

Raphaël : Quand j’avais 8 ans, dans ma campagne, il y avait un « club informatique » (MO5 rul3z !). C’était comme un Coding Goûter, mais sans les gâteaux. Ça me passionnait, je n’étais pas le seul, et personne ne s’en étonnait. On ne connaissait pas encore le mot « bobo », ni le mot « troll », d’ailleurs. Cela dit, oui, je suis bobo, et troll-proof, aussi.

Jonathan : La contrainte que nous avons mise pour l’accès au Coding Goûter, à savoir le fait de faire participer parents et enfants ensemble, crée probablement une barrière pour certaines familles où tout simplement les activités partagées ne sont pas la norme. Je ne peux qu’espérer que d’autres formats existeront pour donner à chaque enfant une chance de découvrir la programmation.

Julien : Coding Goûter est issu de parents qui apprécient la culture du code, et qui ont envie de la partager avec leur enfants. Il y a eu des réactions vaguement négatives. La ligne de partage ne semble pas être le niveau d’études, le niveau d’intellectualisme ou le revenu, mais plus la vision de la technologie comme quelque chose de positif, créatif, avec un empowerment possible ou comme un aspect négatif et enfermant de la vie contemporaine.
À ma connaissance, il y a des enfants de tout milieu qui ont envie de coder.
À l’opposé, il y a des parents de milieux aisés qui n’ont aucune motivation pour encourager leurs enfants à programmer, et même au contraire, y sont hostiles.
Maintenant, si la vraie question est « quelle diversité pour les Coding Goûter ? » on peut noter que nous avons déjà une parité fille-garçon des enfants qui est unique pour des sessions de programmation mixte (en fait, on a même toujours eu plus de filles que de garçons…).
C’est un bon signe. Il y a un effet de réseau sur les parents, c’est certain, tout simplement car on est un tout petit groupe qui grandit de proche en proche. Mais du coup, il y a peu de pression de sélection sur les enfants.

Plus concrètement, quels sont, dans le détail, les logiciels que vous proposez ? Quels sont leurs spécificités ? Pourquoi les avoir choisis ?

Julien : On a testé beaucoup de choses, et on continue de tester des nouveaux outils. Il y a des choses incroyables qui se passent du côté des outils web, dans le navigateur. J’ai adoré faire du LiveCodeLab avec des ados, en particulier.
Mais les grands classiques comme Scratch sont toujours aussi intéressants.
Le choix se fait sur la facilité de prise en main, le niveau des enfants (et des adultes !), le but (si un enfant veut faire un jeu sur tablette, on va l’orienter vers GameSalad, par exemple), et les découvertes du moment.

Raphaël : Pour les logiciels : à chaque séance, on en essaye de nouveaux, et on garde ceux qui nous plaisent.
Je choisis les logiciels en fonction du ou des participants qui programment avec moi, par exemple avec un enfant qui ne sait pas encore lire, ou avec un ingénieur, j’aime bien commencer avec RoboZZle, tandis qu’avec des enfants de 5 à 7 ans, on se raconte une histoire, et on construit un jeu petit à petit sur Scratch. Même si ils ne conçoivent qu’une petite partie de l’algo, le plaisir d’avoir créé est bien là ! En général, on arrête de programmer quand ça devient plus amusant de jouer que de créer le jeu.
Scratch est aussi idéal pour la tranche d’âge intermédiaire : souvent, des groupes de deux ou trois enfants de 8 à 50 ans se forment. Ils suffit de les mettre sur la voie, et ils parviennent à créer des programmes, en s’appuyant sur les participants les plus expérimentés (pas nécessairement les plus âgés). Et avec des garçons pré-ados, on a tenté de construire un circuit logique dans un univers virtuel (Minecraft). Pas facile de faire collaborer tous ces avatars !

Comprenez-vous ceux qui (comme nous) souhaitent que les logiciels proposés soient « le plus libre possible » ?

Raphaël : Oui. Et d’ailleurs, goûter au plaisir d’utiliser du code que l’on a écrit soi-même, c’est faire un premier pas dans les traces qui mènent au logiciel libre, non ?

Jonathan : Je trouve cela assez sain. Au quotidien, je n’utilise pas que des logiciels libres, mais quand j’en ai l’occasion j’essaie d’expliquer à mes enfants ce qu’est un logiciel libre afin qu’elles puissent plus tard faire des choix informés.

Julien : Le logiciel libre fonctionne évidemment en harmonie avec les pratiques d’appropriations collectives.
Il y a des raisons idéologiques à ça, mais il y a aussi des raisons pratiques. Un exemple très concret : les enfants français ont besoin que les interfaces, la documentation, les exemples, soient traduits en français. Un outil libre est traduisible dès que la communauté le veut.
Par exemple, j’ai pris l’initiative de traduire LiveCodeLab, les tutoriaux en particulier, car je trouvais que c’était un outil fascinant, et je voulais voir comment les enfants et les ados allaient l’utiliser. Un code ouvert et un développeur amical, et cela a pris quelques heures !
Cela dit, j’aime les contradictions. Tester tous les outils, c’est se confronter, et confronter les enfants les plus grands, aux choix de leurs outils, aux système parfaits mais propriétaires et verticaux, aux possibilités des outils ouverts d’être modifiés, aux rythme d’évolutions des outils qui ne sont pas les mêmes.
De fait, des outils payants et fermés auront bien sûr bien moins de succès dans le contexte des Coding Goûters que des outils libres. La partie grise ce sont les outils propriétaires gratuits ou freemium très bien réalisés, comme GameSalad, qui ont une position unique et intéressante. On aime GameSalad comme on aime Photoshop, ou Google Docs. Un bel outil logiciel reste un bel outil logiciel.

Est-ce que vous avez déposé le nom et le concept de « Coding Goûter » ? Comme j’imagine que non, cela signifie que tout le monde peut en organiser ! Vous connaissant un peu, j’imagine même que c’est quelque chose que vous encouragez. Quels conseils donneriez-vous donc, comment vous contacter et trouver trace des « Coding Goûter » précédents ?

Jonathan : Pas de marque déposée effectivement. L’idéal serait au contraire que le mot devienne aussi banal que « week-end » ou « pique-nique » !

Julien : On encourage tout le monde à organiser des Coding Goûters, bien sûr !
On imagine que dans quelques temps, il y aura des Coding Goûter un peu partout en France, et ailleurs, et que nos enfants pourront y participer où qu’ils soient, se faire de nouvelles copines et de nouveaux copains.
Ce qui ne doit pas arriver, c’est de laisser le concept être avalé par les habitudes antérieures, et devenir trop scolaire ou trop orienté-animateur et donc moins exploratoire et moins dirigé par les désirs créatifs des enfants.
Si vous participez avec vos enfants à un Coding Goûter, vous savez que ça ne sera pas un cours ou un tutoriel, que vous pourrez rester avec vos enfants, qu’il y aura des démo-spectacles par les enfants – et des gâteaux ! Ce sont tous ces petits détails qui comptent pour nous.
Le format est encore en évolution, on teste des choses – mais on tient énormément à l’esprit.

Un dernier mot, un prochain rendez-vous ?

Julien : Il y a des Coding Goûter presque tous les mois. Pour être averti du prochain, il suffit d’envoyer un message à contact AT codinggouter.org, ou de fréquenter notre groupe Facebook.

Raphaël : A ceux qui voudraient organiser leur Coding Goûter : lancez-vous ! Si vous ne savez pas comment vous y prendre, venez nous voir, ou mieux : demandez de l’aide à vos enfants.