Nous imaginant technophiles béats, les gens sont souvent surpris de la prise de position de la grande majorité des partisans du logiciel libre en défaveur du vote électronique (quand bien même on ait accès au code source qui pilote la machine et le processus, ce qui semble être du bon sens mais non partagé).

Ce n’est pas l’expérience ci-dessous, au moment même où se déroulent les élections présidentielles américaines, qui risque de nous faire changer d’avis.

Comment j’ai hacké une machine de vote électronique

Roger Johnston (raconté par Suzanne LaBarre) – 5 novembre 2012 – PopSci.com
(Traduction : Zii, ehsavoie, plink, KoS, aKa, lgodard, MF, Ag3m, greygjhart)

How I Hacked An Electronic Voting Machine

De quoi avez-vous besoin pour truquer une élection ? Des connaissances basiques en électronique et 30 dollars d’équipement de RadioShack suffisent, révèle le hackeur professionnel Roger Johnston. La bonne nouvelle : nous pouvons empêcher cela.

Roger Johnston est à la tête de la « Vulnerability Assessment Team » au Laboratoire National d’Argonne. Récemment, lui et ses collègues ont lancé une attaque de sécurité sur des machines de vote électronique pour montrer la facilité déconcertante avec laquelle quelqu’un peut trafiquer les votes. Encore plus surprenant : les versions de ces ordinateurs seront présentes dans les bureaux de vote de toute l’Amérique ce mardi. Le magazine Harper a rapporté recemment que l’écran tactile Diebold Accuvote-TSX va être utilisé par plus de vingt-six millions de votants dans ving États et que l’ordinateur de vote à bouton pressoirs Sequoia AVC va être utilisée par presque neuf millions de votants dans quatre États. Dans cet article, Johnston révèle comment il a hacké ces machines — et que c’est à la portée du premier venu, du lycéen à la grand-mère de 80 ans.

La Vulnerability Assessment Team du Laboratoire National d’Argonne scrute une large variété d’équipements électroniques — serrures, sceaux, tags, contrôle d’accès, biometrie, sécurité des cargaisons, sécurité nucléaire — pour tenter de trouver des vulnérabilités et repérer des solutions potentielles. Malheureusement, on n’alloue pas assez de budget à l’analyse de la sécurité des élections dans ce pays. Alors nous nous sommes penchés dessus, histoire de nous occuper, un samedi après-midi.

On appelle cela une attaque de l’homme du milieu. C’est une attaque classique sur les appareils de sécurité. On implante un microprocesseur ou un autre appareil électronique dans la machine de vote, et cela vous permet de contrôler le vote et de tricher ou non. Basiquement, on interfère avec la transmission de l’intention du votant.

Nous avons utilisé un analyseur logique. La communication digitale est une série de zéros et de uns. Le voltage augmente, diminue. Un analyseur logique rassemble les voltages oscillants entre haut et bas et vous présentera ensuite les données digitales dans une variété de formats. Mais il y a plein de manières de faire. Vous pouvez utiliser un analyseur logique, un microprocesseur, un ordinateur — en gros, n’importe quoi qui vous permette de voir l’information qui est échangée et ensuite vous laisse comprendre ce qu’il faut faire pour imiter l’information.

Nous avons donc espionné les communications entre le votant et la machine. Dans un cas, le votant appuie sur des boutons (c’est une machine à voter avec des boutons poussoirs) et dans l’autre, il interagit avec un écran tactile. Puis, nous avons écouté les communications entre le logiciel de la machine et le votant. Disons que je veux que Jones gagne l’élection, et que vous votez pour Smith. Alors, mon microprocesseur va dire à la machine de voter pour Jones si vous essayez de voter pour Smith. Mais si vous votez pour Jones, je n’interviendrai pas dans les communications. Parfois on bloque les communications, parfois on les déforme, parfois on ne fait que les regarder et les laisser passer. C’est ça l’idée. Deviner quels sont les échanges en cours, puis les modifier si besoin est, y compris ce qui sera présenté au votant.

Nous pouvons faire ceci car la plupart des machines, autant que je sache, ne sont pas chiffrées. C’est simplement un format de communication standard. Il est donc très simple de deviner les informations échangées. N’importe quelle personne qui fait de l’électronique numérique — un amateur ou un fan d’électronique — peut le deviner.

Le dispositif que nous avons intégré dans la machine à écran tactile valait en gros 10 $. Si vous voulez une version de luxe où vous pouvez le contrôler à distance jusqu’à environ 800 mètres, il vous en coutera 26 $. Ce n’est pas très cher. Vous pouvez trouver ça chez RadioShack. Je suis allé à des salons scientifiques dans des lycées où les gosses avait des projets avec des processeurs plus sophistiqués que ceux nécessaires pour truquer ces machines.

Parce qu’il n’y a pas de financements pour ce genre de tests de sécurité, il faut compter sur des gens qui achètent des machines d’occasion sur eBay (dans ce cas l’écran tactile Diebold Accuvote TS Electronic Voting Machine et la machine à boutons Sequoia AVC Advantage Voting Machine). Ces deux machines étaient un peu vieilles, et nous n’avions pas de manuel ou de schéma de circuits. Mais, dans le cas du Sequoia AVC, nous avons deviné comment elle marchait en moins de deux heures. En deux heures nous avions une attaque viable. L’autre machine nous a pris un peu plus de temps car nous ne comprenions pas comment l’affichage sur un écran tactile fonctionnait. Nous avons dû donc apprendre, mais ce n’était qu’une question de jours. C’est un peu comme un tour de magie, vous devez le pratiquer beaucoup. Si nous avions pratiqué longtemps, voir mieux, si quelqu’un de très bon avait pratiqué pendant deux semaines, nous aurions mis 15 à 60 secondes pour exécuter ces attaques.

Les attaques nécessitent un accès physique à la machine. C’est facile pour les personnes en interne qui les programment pour une election ou les installent. Et nous pouvons supposer que ce n’est pas si difficile pour des personnes extérieures. Beaucoup de machines à voter gisent dans la cave de l’église, le gymnase ou le préau de l’école élémentaire, sans surveillance pendant une semaine ou deux avant l’election. Généralement elles ont des serrures très bon marché que n’importe qui peut ouvrir ; quelquefois elles n’en ont même aucune. Personne ne s’identifie auprès des machines quand il prend son poste. Personne n’est chargé de les surveiller. Leurs scellés ne sont pas si différents des dispositifs anti-fraude sur les paquets de nourriture et les médicaments en libre service. Falsifier un produit alimentaire ou un médicament, vous pensez que c’est difficile ? Ça ne l’est vraiment pas. Et un grand nombre de nos juges d’élections sont de petites vieilles à la retraite, et, Dieu les garde, c’est grâce à elles que les élections marchent, mais elles ne sont pas forcement fabuleusement efficaces pour détecter des attaques subtiles de sécurité.

Formez les personnels chargés de la vérification des scellés, et ils auront une chance de détecter une attaque raisonnablement sophistiquée. Faites des vérifications sur les personnes en interne et cette menace sera bien moins sérieuse. Dans l’ensemble il manque une bonne culture de la sécurité. Nous avons beau avoir des machines de vote avec des défauts, avec une bonne culture de la sécurité nous pouvons avoir des élections sans fraude. D’un autre côté, on peut avoir des machines fabuleuses, mais sans une culture de la sécurité à la hauteur, cela ne servira à rien. Il faut vraiment prendre du recul. Notre point de vue est qu’il sera toujours difficile d’arrêter un James Bond. Mais je veux faire avancer les choses jusqu’à un niveau où au moins ma grand-mère ne puisse pas truquer les élections, et nous en sommes encore loin.

Crédit photo : Steve Jurvetson (Creative Commons By)

Lorsque vous parcourez un article de l’encyclopédie libre Wikipédia, vous pouvez bien évidemment le lire, mais aussi écrire (le fameux bouton « Modifier ») et consulter tout son historique, sans oublier converser autour avec les autres contributeurs (lien « Discussion »). Il en va de même avec tout logiciel libre déposé sur une plateforme collaborative comme celle de GitHub par exemple (dont l’approche et les fonctionnalités sociales ont donné un coup de vieux à Sourceforge).

Il y a là une manière bien spécifique de fonctionner et une invitation à s’impliquer.

Dans la mesure ou Wikipédia ou GNU/Linux sont d’incontestables réussites, l’un des plus célèbres penseurs du Net, Clay Shirky, s’est récemment demandé, au cours d’une brillante intervention TED, si on ne pouvait pas fortement s’en inspirer pour faire évoluer la politique en générale et l’élaboration de nos lois en particulier.

Ce que l’on pourrait résumer également ainsi : est-ce que le logiciel libre a des choses à dire, voire à enseigner, à la démocratie ?

Peut-on améliorer la politique avec les outils du logiciel libre ?

Could we use open-source tools to improve politics?

Mathew Ingram – 29 septembre 2012 – Gigaom.com
(Traduction : Lamessen, Barbidule, Evpok, David, peupleLa)

Les principes du logiciel libre ont contribué à créer de nombreux logiciels efficients et utiles, y compris le système d’exploitation GNU/Linux et la surpuissante ressource que représente Wikipédia. Cette même approche pourrait-elle être utilisée pour ouvrir le processus de création des lois ? Clay Shirky assure que c’est possible.

La philosophie du logiciel libre a permis entre autres de construire un système d’exploitation et une encyclopédie collaborative de grande qualité. Pourrait-on en faire de même avec la législation et la politique ? C’est ce que le théoricien de la communication Clay Shirky a proposé dans une récente et remarquée conférence TED (Technologie Entertainment Design) à Edimbourg. L’idée est alléchante, employer les méthodes de GNU/Linux et Wikipédia pour rendre les gouvernements plus ouverts et impliquer davantage les concitoyens, mais est-ce véritablement transposable ? L’écriture de logiciels et de services Web est très différente de celle des lois, et l’histoire du logiciel libre a connu son lot de guerres quasi-religieuses. Mais c’est peut-être notre meilleur espoir.

Après avoir fait une sorte de tour d’horizon du mouvement open source, en accordant la part belle à GNU/Linux, Shirky a consacré une grande partie de son discours à Github, plateforme collaborative et sociale de dépôt de logiciels qui permet à n’importe qui d’éditer, de « forker » en créant sa propre version, et de suivre les changement que font les autres. De GitHub à l’idée de législation collaborative, il n’y a qu’un pas. Et c’est ce que Shirky semble avoir à l’esprit. Il y a déjà eu quelques tentatives de réalisation directement via GitHub. Ainsi un développeur allemand a, par exemple, déposé l’intégralité des lois allemandes sur la plateforme. De cette façon, les citoyens peuvent recommander et suivre les changements.

C’est séduisant sur le papier : une simple plateforme logicielle dédiée à la collaboration pourrait changer la façon dont on développe et met en oeuvre les lois. Mais est-ce réaliste ?

Beaucoup de sceptiques disaient au départ que Wikipédia n’avait aucune chance de marcher. Pourtant elle est bel et bien là et sa réputation et fiabilité sont excellentes, malgré quelques ratés comme l’incident récent impliquant l’auteur Philip Roth. Il est vrai cependant que de nombreux critiques pensent que la « cabale » des éditeurs qui contrôlent l’encyclopédie collaborative a trop de pouvoir.

Force est de reconnaître que le fonctionnement des gouvernements reste de toutes les façons trop opaque à l’ère d’Internet, et donc que Github ne peut pas faire empirer les choses. D’ailleurs Shirky n’est pas le seul à le penser : le développeur Abe Voelker a proposé un « Github pour lois » qui propose exactement la même approche pour concevoir des lois collaborativement. D’autres expériences basées sur ces mêmes idées d’ouverture ont déjà eu lieu en Finlande, Irlande et surtout en Islande avec la rédaction collective de sa nouvelle Constitution (NdT : lire à ce sujet L’Islande, la crise, la révolution et moi et on notera en France l’initiative d’Étienne Chouard avec sa Constitution nationale d’origine citoyenne sur un wiki).

Un des problèmes posés par la transposition d’une solution technique comme Github à un processus culturel et politique de grande ampleur, c’est que créer des lois, même mineures, est très différent de bidouiller un bout de code afin que GNU/Linux puisse reproduire les styles de polices de caractères Windows, ou encore modifier l’article sur George Bush dans Wikipédia (sachant que ces deux exemples en apparence inoffensifs ont donné lieu à de vives polémiques au sein de leur communauté respective). Comment peut-on dès lors espérer que des politiciens puissent, dans les faits, se servir d’un processus similaire pour changer la manière dont fonctionne le gouvernement, le parlement et ses lois ? Comme le suggère Shirky dans sa conférence, il y a une bureaucratie bien installée qui n’a probablement aucun intérêt à renoncer à ce contrôle au profit du bon peuple.

Dans son livre « Here comes Everybody », Shirky a montré l’impact positif d’Internet sur la dynamiques des groupes. Son admiration pour Github semble prendre place dans une recherche d’outils collaboratifs et ouverts axée sur l’humain. Il est clair que nous en avons besoin, et même si Github n’est peut-être pas la bonne réponse, à ce stade, tout peut valoir la peine d’être tenté.

Crédit photo : Fabricio Zuardi (Creative Commons By)

Connaissiez-vous les « bots » de Wikipédia ?

Le mieux est de commencer tout d’abord par demander à Wikipédia :

« Les bots sont des agents automatiques ou semi-automatiques qui interagissent avec Wikipédia comme le fait un utilisateur, mais pour des tâches répétitives et fastidieuses pour un humain. Les bots peuvent être utilisés pour créer des articles. D’autres peuvent être utilisés pour éditer ou même détruire des articles. Certains bots sont spécialisés dans la gestion des liens d’interlangue, la résolution des homonymies, les annulations de certains vandalismes ou encore les opérations sur les catégories. Des bots bien conçus peuvent apporter un bénéfice concret à Wikipédia. Cependant, parce que le système n’a pas été conçu pour supporter des bots, même un bon bot peut avoir des effets secondaires non souhaitables. »

C’est donc de ces satanés bots dont il est question dans la traduction ci-dessous. Bien moins pour glorifier l’intelligence artificielle que pour rendre hommage à ceux bien humains qui les programment dans les coulisses.

Remarque : Les wikipédiens francophones ont quant à eux souvent à faire avec le bot Salebot (Attention, bot méchant ! nous prévient-on sur sa page « Utilisateur »), un article spécialement dédié lui avait été consacré par Camille Gévaudan sur le site Écrans en août 2008.

Meet the ‘bots’ that edit Wikipedia

Daniel Nasaw – 25 juillet 2012 – BBC News
(Traduction : elfabixx, Pwetosaurus, Gatitac, Jose, ProgVal, Kaya, fck)

Rencontrez les « bots » qui éditent Wikipédia

Wikipedia est écrit et maintenu par des dizaines de milliers de volontaires bénévoles dans le monde, qui sont eux-mêmes assistés par des centaines de « bots » — des programmes informatiques autonomes — qui aident à garder l’encyclopédie fonctionnelle.

« Le pénis est l’organe mâle de copulation et de miction chez les mammifères. » dit la page Wikipédia en question.

Cette affirmation est indéniablement vraie, et donc mérite d’être dans Wikipédia, mais elle n’a assurément rien à faire dans l’article du site consacré à la Cour suprême !

C’est un facétieux lecteur anonyme de Wikipédia vivant en Caroline du Sud a proposé cette contribution à l’encyclopédie mondiale en ligne la semaine dernière, et il a suffi de quelques secondes pour que cette erreur soit détectée et supprimée.

Ce vandalisme n’a pas été trouvé par un autre contributeur, mais simplement par un programme d’intelligence artificielle appelé « bot », qui est une aphérèse de « robot ».

Virtuellement invisible

ClueBot NG, car tel est son nom, réside dans un ordinateur à partir duquel il intervient sur la vaste encyclopédie pour détecter et nettoyer le vandalisme, quasiment dès que celui-ci apparaît.

Il fait partie des quelques centaines de bots qui patrouillent sur Wikipedia à tout moment. Son rôle dans la restauration immédiate de l’article sur la Cour suprême illustre comment les bots sont devenus une partie indispensable — même si virtuellement invisible — du projet Wikipédia.

« Wikipedia serait une belle pagaille sans les bots », écrivait dans un courriel un administrateur de Wikipédia, connu sur le site sous le nom de Herfold.

À elle seule, la version anglaise de Wikipedia dépasse les quatre millions d’articles ce mois-ci. Elle contient autour de 2.5 milliards de mots, équivalent à des millions de pages, et est 50 fois plus grosse que l’Encyclopædia Britannica.

Wikipedia est maintenue dans toutes les langues par des dizaines de milliers de contributeurs — dont environ 77 000 font plus de cinq éditions par mois.

Le projet est devenu avec le temps tellement vaste et sa maintenance un tel travail intensif que cela défie les capacités de ses administrateurs et simples contributeurs humains de le maintenir en ordre.

Intervenir contre les vandales

C’est là que les (ro)bots interviennent.

« On s’amuse à penser au jour où les robots se mettront en grève juste pour que tout monde se rende compte de la quantité de travail qu’ils abattent », dit Chris Grant un étudiant de 19 ans à Perth en Australie, qui fait partie du comité de Wikipédia qui supervise les robots.

« Le site demanderait beaucoup plus de travail de notre part et épuiserait davantage les contributeurs ».

Les bots effectuent ainsi de nombreuses tâches éditoriales et administratives qui sont fastidieuses, répétitives et chronophages mais néanmoins vitales.

Ils suppriment le vandalisme et les grossièretés, organisent et cataloguent les entrées, et gèrent les coulisses de l’encyclopédie, ce qui lui permet de fonctionner efficacement et de garder son apparence soignée et uniforme dans le style.

En des termes plus concrets, les bots sont comme des étudiants qui veillent sur les livres, déplacent des piles d’un étage à un autre, corrigent les codes-barres au dos des livres, et effectuent d’autres tâches ingrates, qui permettent aux bibliothécaires qualifiés de se concentrer sur les acquisitions et la politique du lieu.

Les bots peuvent-ils écrire ?

« Wikipédia s’est tellement développée que je ne sais pas comment les gens pourraient bien la gérer si tous les bots s’en allaient » nous dit Brad Jorsch, un programmeur informatique en Caroline du Nord qui gère un bot qui traque les bandeaux rappelant aux rédacteurs d’ajouter des sources aux articles.

Les bots sont présents depuis presque aussi longtemps que Wikipédia elle-même.

Le site a été fondé en 2001 et l’année suivante, un bot appelé Rambot a créé environ 30 000 articles — à un rythme du millier par jour — sur les villes individuelles des États-Unis. Le bot a puisé ses données directement à partir de tabeaux de recensement américain. Et les articles se lisaient bien comme s’ils avaient été écrit par un robot. Ils étaient courts et convenus, et contenaient à peine plus que des séries de statistiques démographiques.

Mais, une fois qu’ils avaient été créés, des rédacteurs humains prenaient le relais et remplissaient les entrées avec des détails historiques, des informations sur la politique locale et les sites touristiques.

En 2008, un autre bot a créé des milliers de courts articles sur des astéroïdes, renseignants quelques lignes de données pour chacun à partir des bases de données de la NASA.

Aujourd’hui, la communauté Wikipédia demeure divisée quant à l’apport des bots aux articles. Certains administrateurs trouvent que de petits articles composés de quelques données n’ont que peu de valeur, d’autres trouvent que tout nouveau contenu est bon à prendre.

La peur des bots malicieux

Le résultat du débat a été que les bots ne sont désormais plus autorisés à écrire des articles entiers. Cependant, leur capacité à effectuer le plus gros de la maintenance libère les vrais contributeurs humains qui disposent alors de plus de temps pour effectuer une recherche, créer ou modifier un article et vérifier l’exactitude du travail des autres.

« Je ne pense pas que les gens réalisent quelle quantité de maintenance et de travail annexe sont nécessaires sur Wikipédia » dit Grant.

Certains administrateurs craignent les dégâts qu’un bot renégat pourrait un jour occasionner à l’encyclopédie. Pensez à Skynet dans les films Terminator.

Ces peurs sont infondées, d’après Grant.

Déjà, un robot n’est pas comme une automobile : si une partie d’une opération échoue, il s’arrêtera plutôt que de se fracasser quelque part.

« Il faudrait déjà que quelqu’un demande à un programmeur de rendre le bot fou et qu’il efface tout », dit Grant.

« Les bots avec les droits de supprimer des pages, bloquer des éditeurs, et prendre d’autres décisions drastiques ne peuvent être utilisés que par des contributeurs de confiance disposant de hauts privilèges administratifs », dit Grant.

Cependant, les bots aussi font des erreurs lorsqu’ils font face à des situations pour lesquelles ils n’ont pas été conçus. ClueBot NG, le bot anti-vandlisme, a cependant un très faible taux de faux positifs (lorsqu’il confond des articles légitimes avec du vandalisme). Étant donné que Wikipédia garde une trace des éditions, les erreurs peuvent être réparées presque aussi vite qu’elles surgissent, disent les administrateurs.

Les contributeurs humains ne craignent pas d’être un jour remplacés par les bots, disent les maîtres de bots. « Ecrire un article, citer ses sources, ou encore améliorer sa grammaire et son orthographe nécessiteront toujours le concours d’une personne », conclut Jorsch.

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

Il y a une semaine on nous a annoncé que Diaspora serait désormais livré à la communauté.

Pour rappel Diaspora est le projet d’alternative libre à Facebook mené par des étudiants newyorkais et qui avaient créé le buzz et amassé beaucoup d’argent sur Kickstarter au moment du lancement en 2010.

Il y avait énormément d’attentes autour de ce projet car réussir à se sortir des griffes de Facebook ça n’est pas rien !

Plusieurs versions de l’application ont bien vu le jour, plusieurs dizaines de milliers d’utilisateurs se sont inscrits, mais c’est globalement la déception qui a prévalu. Ils n’ont pas réussi (et englouti l’argent), alors changement de gouvernance, plus de transparence, on donne le tout à la communauté (et qu’elle se débrouille si elle pense que le projet vaut la peine d’être poursuivi). Cela ressemble plus à un renoncement plein d’amertume qu’à un cadeau bienveillant, mais les optimistes répliqueront que c’est la force du libre que de pouvoir continuer l’aventure d’un projet même lorsqu’il se trouve bloqué.

Le billet ci-dessous tente de tirer les leçons de cette histoire et de cet échec.

Échec temporaire ou définitif ? Cela va dépendre justement de la communauté.

Diaspora : un nouveau départ ou une mise en garde du financement participatif ?

Diaspora: A New Beginning or a Crowdfunding Cautionary Tale?

By Paul M. Davis – 29 août 2012 – Shareable.net
(Traduction : boubou, Ward, imada, Gatitac, moedium, xaccrocheur, Penguin, aKa, sheldon, martinien)

Il y a deux ans, quatre étudiants de l’université de New York surfèrent sur le sentiment anti-Facebook et ont récolté via le site Kickstarter plus de 200 000 $ pour créer Diaspora, un réseau social open source.

Les fondateurs ont annoncé lundi qu’ils livraient leur projet à la communauté open source, ce qui va peut-être relancer le développement d’une plate-forme de réseau social au-delà de ce qu’ils ont réussi à créer jusqu’à maintenant. Dans le cas contraire, nous aurions à faire avec un échec patent d’un projet issu du financement participatif (NdT Crowdfunding).

D’une certaine manière, l’histoire de Diaspora est le reflet de la jeunesse de ses créateurs : optimisme sans limite et promesses sans fins ont laissé place au scepticisme, à la déception, aux réactions négatives et même à des tragédies personnelles. Après que la campagne KickStarter a atteint 20 fois son objectif initial, les développeurs furent mis sous une pression extrême de produire un résultat. Les sorties furent repoussées, les messages et la communication devinrent confus. En moins d’un an, le sentiment négatif qui était né durant la campagne de levée de fonds semblait se retourner contre le projet lui-même.

Au milieu de tout le tapage qui a entouré le lancement et le succès de la campagne de Diaspora, un sentiment de scepticisme a commencé à apparaître. Au plus fort de la campagne, des voix importantes comme celle de Clay Shirky ont amplifié les doutes sur la possibilité que Diaspora puisse atteindre son ambitieux objectif d’une livraison de la version alpha à la fin de l’été. La sortie privée de la version alpha eut lieu en novembre 2010 et a reçu un accueil modérément optimiste parmi les donateurs et la presse spécialisée, mais ce délai et les fonctionnalités limitées ont renforcé les arguments de ceux qui doutaient. A partir de mai 2011, des blogs techniques de haut niveau comme TechCrunch commençaient à critiquer le projet comme des vieilles nouvelles et à le qualifier de vaporware.

Confirmant les soupçons des sceptiques, les fondateurs annoncèrent en juillet 2011 qu’après avoir levé 20 fois leur objectif, Diaspora était déficitaire de 238 $ (PDF). En octobre 2011, les fondateurs essayèrent de faire taire les mauvaises rumeurs avec un post sur leur blog intitulé Diaspora : ni vaporware, ni prince Nigérian”. Malheureusement, s’ensuivit rapidement le suicide de Ilya Zhitomirskiy, co-fondateur du projet. En avril dernier, l’équipe Diaspora déclara que « les choses commencent à changer » en partageant des copies d’écrans d’une campagne de hashtag ayant une ressemblance frappante avec le site makr.io, un autre projet récemment annoncé par les mêmes fondateurs de Diaspora.

Puisque le but de Diaspora a toujours été de devenir un véritable projet open source, il est trop tôt pour voir l’annonce de lundi dernier comme un échec. Mais ce transfert open source ressemble plus un renoncement qu’à un cadeau à la communauté.

Alors, à quoi ressemblera le futur de Diaspora ? Dans une interview à BetaBeat, le co-fondateur Max Salzberg a déclaré que « beaucoup de projets open source exploitent la communauté », citant Mozilla et WordPress en exemple. Même s’il est vrai que Mozilla et WordPress s’appuient sur une large communauté de contributeurs, la comparaison de Salzberg ne tient pas car les deux projets cités sont également soutenus par de gros apports financiers, qu’il s’agisse d’argent provenant du Kickbacks de Google (Mozilla) ou des services premium pour les entreprises (WordPress).

Pour envisager ce que pourrait être le futur de Diaspora, il vaut la peine de prendre en considération un projet récent inspiré par un mécontentement similaire des utilisateurs. La plateforme qui suscite actuellement la colère des geeks est Twitter, qui ne cesse de serrer la vis sur l’écosystème du développement en limitant l’accès aux API et en mettant en place une stratégie commerciale qui le fera ressembler beaucoup plus à Facebook qu’à un simple flux de messages de 140 caractères. Ceci a poussé récemment au financement réussi de app.net, un service alternatif lancé d’une manière très différente. Au lieu de construire une plateforme ouverte et décentralisée, ce que les étudiants derrière Diaspora visaient, app.net développe une plateforme sociale centralisée financée par les abonnements des utilisateurs plutôt que par la publicité. Le projet a récemment atteint son objectif de campagne de 500 000 $ par des inscriptions de membres à 50 $, en grande partie grâce à l’approbation tacite des blogueurs influents et des développeurs qui ont été parmi les détracteurs les plus virulents de Twitter ces dernières semaines.

Pour qui est fait Diaspora ?

Malgré les différences fondamentales entre Diaspora et app.net, ils partagent le même problème de base : atteindre l’effet de réseau. Le succès d’un réseau social dépend d’un certain nombre de facteurs : des utilisateurs de la première heure qui sont aussi de vrais partisans, du buzz médiatique, une nouvelle solution à un problème existant, ou, à défaut d’autre chose, de la nouveauté.

Qu’en est-il pour Diaspora ? Cela fait longtemps que le buzz s’est estompé. Et, comme Google l’a découvert avec Plus, ce n’est pas parce que les gens sont « agacés par Facebook » qu’il vont avoir le temps ou l’envie de changer de réseau social, surtout si leur amis ne le font pas.

Lancer un nouveau service social en direction de la geekratie peut sembler pertinent au démarrage à fortiori lorsque le projet est open source. Mais pour que la sauce prenne, il faut aller au-delà des geeks et être aussi rapidement adopté par la masse. Diaspora ne s’adresse-t-il pas avant tout à ceux qui ne sont pas intimidés par les commits Git ou monter une instance Heroku, à ceux, pas assez nombreux, qui ont bien conscience qu’ils vont offrir leurs données personnelles à une société contre un service Web gratuit ? Et dans ce cas, quelles différences fondamentales avec des sites déjà existants comme Slashdot, Github ou Stack Overflow ? De plus, et bien que les caractéristiques sociales de ces services soient souvent limitées, il existe déjà de nombreuses plates-formes de réseaux sociaux open source sur le marché : Drupal, Elgg, Buddypress, Pligg, Mahara, pour en nommer quelques-unes.

Le potentiel de la fédération

La dernière carte à jouer pour Diaspora peut être son architecture fédérée. Dans une époque de services centralisés et financés par la publicité, tels Facebook,Twitter et Google, il y a un attrait certain pour une plateforme sociale fonctionnant sur une architecture décentralisée.

Une telle approche devient plus impérieuse si l’on considère la facilité avec laquelle le gouvernement américain a fermé des sites prétendument coupables d’infraction ces dernières années et comment il peut accéder aux données personnelles d’activistes sur les médias sociaux, comme Malcom Harris de Shareable s’en est aperçu au cours d’un long procès concernant son activité sur Twitter. En théorie, les nœuds d’une plate-forme sociale, qui forment un réseau p2p, pourraient être tissés dans un garage ou un placard et être déconnectés facilement, avec un faible impact sur le réseau.

Mais alors on en revient au problème des effets du réseau : la valeur de Twitter pour le mouvement Occupy ne relevait pas simplement de la communication et de l’organisation mais aussi de la diffusion. Les personnes sur le terrain étaient capables de diffuser des scènes de violence policière en temps réel, non seulement aux autres membres du mouvement sur un quelconque réseau social partagé, mais également au monde entier.

Des réseaux sociaux fédérés existent déjà, tel StatusNet sur lequel repose le rival largement oublié de Twitter, identi.ca. Mais même avec la pleine connaissance des risques de confidentialité de l’utilisation de Twitter ou Facebook, la plupart des activistes d’Occupy ne diffusaient pas vers la poignée de geeks qui postent encore des conseils pour Drupal sur identi.ca. Ils se sont plutôt dirigés là ou l’audience la plus vaste et diversifiée verrait leurs message : Twitter, Facebook et Youtube.

Rien de ceci ne permet de dire qu’une solution fédérée ne peut fonctionner, seulement que les défis sont très grands. Maintenant que Diaspora a été remis entre les mains de la communauté, il est trop tôt pour le déclarer mort. Comme les fondateurs l’ont noté dans leur annonce, le compte Github de Diaspora est actif (tout comme son projet sur Pivotal Tracker).

Je reste d’un optimisme prudent quant à la capacité de la communauté open source à créer quelque chose de grand à partir du code que les fondateurs ont lâché dans la nature. Peut-être que le code existant sera forké et deviendra la base d’un nouveau projet allant bien au delà du Diaspora actuel. Mais quoi qu’il advienne, son développement tumultueux restera comme un récit de mise en garde vis-à-vis du crowdfunding, sur les dangers des promesses qu’on ne peut pas tenir.

Ah, les fameux App Stores et leurs effets pernicieux à plus d’un titre !

Ce système multiplie les coûts, les contraintes et les délais alors que la même application écrite dans le langage du Web et proposée directement aux visiteurs d’un site Web évite tous ces écueils.

En effet : non seulement le principe des App Stores autorise une entreprise privée à décider arbitrairement des seuls contenus auxquels les utilisateurs du monde entier auront le droit d’accéder, non seulement il permet d’enchaîner ces mêmes utilisateurs à un système d’exploitation donné (iOS, Android…)^[1], mais surtout, si l’on en croit David Murphy — qui commercialise un outil d’aide à la création d’applications Web — dans le texte ci-après traduit, il est tout à fait contre-productif pour les entreprises désirant proposer une application à l’appui de leur business.

Si les arguments techniques et économiques permettent aux applications Web de triompher des applications natives servies dans les App Stores fermés, ne nous privons pas de les relayer car, au final, tout cela permettra de rendre un peu de liberté à l’utilisateur !

Voici pourquoi HTML5 est génial pour les mobiles

Why HTML5 Rocks For Mobile

David Murphy – août 2012 – Mobile Marketing
(Traduction Framalang : antistress, Goofy, Amine Brikci-N, ZeHiro)

HTML5 est partout cette année ! Google encourage son usage. Facebook est à fond dessus. Il est évident que HTML5 est l’avenir sur les mobiles. OK c’est super. Mais c’est quoi au juste HTML5, et que peut-il faire pour les mobiles ?

HTML5 est la dernière version de HTML — le standard de présentation et de structuration des contenus sur le World Wide Web. Un des grands progrès apportés par HTML5 est qu’il permet à des sites web de fonctionner comme des applications mobiles, en donnant aux développeurs des moyens de conception adaptés aux appareils mobiles et plus seulement aux ordinateurs de bureau ou portables. Cela signifie que les sites web peuvent être conçus pour s’adapter aux écrans des appareils mobiles et avoir une interface utilisateur facile à maîtriser et très fonctionnelle avec les écrans tactiles. Le terme utilisé pour cette technologie est « appli web » (web app).

Sur un plan pratique, il existe deux façons d’implémenter une appli web. La première consiste à concevoir des sites web pour qu’ils s’adaptent et s’affichent aussi bien sur un écran d’ordinateur que sur un écran de smartphone. La seconde revient à créer une appli spécifique qui s’ouvrira lorsqu’on accède au site web avec un appareil mobile.

Cette nouvelle approche dans la présentation des contenus pour mobiles abat certaines barrières — y compris celles du temps, de l’argent et de l’omniprésent App Store. Les portes sont maintenant largement ouvertes pour les individus et les petites entreprises. Les poids lourds de la profession sont aussi attirés par cette alternative, à mesure qu’ils prennent conscience de ses avantages.

Qui n’a pas son smartphone

Voici des données chiffrées sur le marché des mobiles : 50% de toutes les recherches locales sont effectuées aujourd’hui sur des appareils mobiles. Ceci est largement dû au fait que les possesseurs de smartphones sont plus nombreux que ceux qui ont des téléphones basiques aux États-Unis et dans d’autres pays.

Et malgré cela, la plupart des entreprises n’ont aucune solution à proposer pour le mobile — sans compter les bénéfices substantiels qu’ils pourraient en tirer. Malheureusement, le développement d’applications classiques est tout simplement bien trop coûteux en temps et en argent et trop technique. Alors sans plus tarder, voyons cinq bonnes raisons qui nous font penser que HTML5 va poursuivre sa forte croissance :

Ça n’est pas seulement pour les iPhones, mais pour TOUS les smartphones

Malgré tout le buzz que génère l’iPhone, il ne représente que 25% des parts de marché. Android domine le marché avec 50% des smartphones en Amérique du Nord et Blackberry s’en sort étonnamment bien du côté des tablettes. Les appli web fonctionnent sur tous les téléphones et tablettes tactiles populaires — vous permettant d’atteindre la quasi-totalité des clients. Ce n’est pas qu’une chose positive, c’est surtout crucial pour les affaires.

C’est abordable

Les applis web HTML5 sont développées pour un prix et un temps moitié moindres que les applications natives (basées sur du code machine). Développer des applications natives peut aussi être un cauchemar. Je répète : un cauchemar coûteux en temps et en argent. Développer pour une plateforme spécifique (iPhone, Android, Blackberry, Windows Mobile, iPad et la liste est encore longue…) n’est tout simplement pas une solution viable pour la plupart des entreprise, et ceci empire car…

Les choses changent. Votre entreprise changera.

Imaginez que vous possédez une entreprise et que votre nouvelle application native a été lancée il y a six mois de cela ; votre entreprise et vos clients ont changé ne serait-ce qu’un petit peu et vous devez faire une mise à jour. Bonne chance ! Commencez par trouver l’équipe de développeurs, impliquez à nouveau vos équipes marketing et vente, et apprêtez-vous à tous les payer encore une fois. Ensuite re-soumettez l’application à (aux) app store(s) concernés… et attendez.

Les applis web permettent une mise à jour rapide, au rythme de votre entreprise. Comme pour un site web, les modifications peuvent être mises en œuvre instantanément. Aucune autre solution pour mobile ne peut rivaliser lorsqu’il s’agit de permettre à une entreprise d’être réactive aux priorités et aux besoins en temps réel.

Localisation, localisation, localisation

La proximité est l’un des meilleurs moyens de susciter l’intérêt, d’être pertinent et finalement de déclencher l’acte d’achat. Les applis web ont la possibilité de fournir des services géolocalisés, comme d’informer les utilisateurs de la proximité de lieux pouvant les intéresser ou de leur permettre d’associer des contenus (par exemple des photos ou des notes) à des lieux particuliers.

Votre marque est sur le Web et sociale, pourquoi pas votre appli aussi ?

Qu’est-ce qu’un site web en fait ? C’est l’endroit où votre entreprise/marque/personne existe en ligne. Sauf que ce n’est plus uniquement cela avec le Web moderne. Les marques, les gens, les produits existent à travers l’ensemble du web – sur Twitter, Facebook, Yelp, Tumblr et des centaines (si ce n’est des milliers) d’autres services. Aujourd’hui c’est là que les connexions se font, que l’on trouve les produits et les gens, que les nouvelles idées grandissent.

Les applis web sont faites pour fonctionner et vivre avec les autres éléments de votre marque sur le Web — ce qui vous permet de rester en contact avec vos clients actuels, d’en trouver de nouveaux, ou simplement de partager des idées de toutes les manières possibles. Les applis web excellent, et pour cause, à fonctionner avec d’autres applications du Web.

Et ce n’est que le début, les gars ; attendez de voir la suite !

Crédit photo : Toni Hermoso Pulido (Creative Commons By-Sa)

Nous avons consacré un billet à la (merveilleuse) histoire du libre circuit imprimé Arduino.

Puis, tout récemment, nous avons mis en exergue une conférence TED de l’un de ses créateurs qui s’enthousiasmait de la diversité et originalité des projets dérivés d’Arduino.

Il aurait pu ajouter celui-ci…

PS : Alors, Ritz ou Carlton cet été pour les vacances ?

Un hacker « black hat » peut ouvrir 4 millions de chambres d’hôtel grâce à un microcontrolleur Arduino

Black Hat hacker gains access to 4 million hotel rooms with Arduino microcontroller

Sebastian Anthony – 25 juillet 2012 – ExtremeTech
(Traduction Framalang : esperolinuxien, ZeHiro, Martin)

Mauvaise nouvelle: Pour moins de 50$ de matériel et un petit peu de programmation, un hacker peut ouvrir, instantanément et sans laisser de trace, des millions de chambres d’hôtel protégées par une carte-clé.

Ce hack a été présenté par Cody Brocious, un développeur de chez Mozilla, à la « Black Hat Security Conference » de Los Angeles. 4 millions de chambres d’hôtel sécurisées par les serrures programmables à carte vendues par Onity sont menacées. Selon Bocious, que l’on devrait réprimander pour ne pas avoir divulgué le hack à Onity avant de le rendre public, il n’y a pas de correction facile par une mise à jour du firmware. Si les hôtels veulent sécuriser les chambres de leurs clients, chaque serrure devra être changée.

Le hack est entièrement détaillé sur le site internet de Borcious, mais en quelques mots : à la base de chaque serrure Onity se trouve un petit port alimentation DC (simplement identique à celui de votre vieux téléphone Nokia). Ce port est utilisé pour recharger la batterie de la serrure, et pour programmer cette dernière avec le « sitecode » de l’hôtel – une clé 32-bit identifiant celui-ci. En connectant un microcontrolleur Arduino dans le port DC, Brocious a trouvé qu’il pouvait simplement extraire cette clé 32-bit de la mémoire de la serrure. Aucune authentification n’est requise – et la clé est enregistrée à la même place dans chaque serrure Onity.

Le meilleur : en introduisant ce code 32-bit dans la serrure… elle s’ouvre ! D’après Brocious, 200 millisecondes sont simplement nécessaires pour lire le “sitecode” et ouvrir la serrure. « Je le branche, l’allume, et la serrure s’ouvre » confie Brocious. Sa mise en œuvre actuelle ne fonctionne pas avec toutes les serrures, et il ne compte pas mener plus loin ses investigations, mais ses documents de recherche prouvent de manière très claire que les serrures Onity, assez ironiquement, ne disposent même pas de la sécurité la plus élémentaire.

J’aimerais pouvoir dire que Brocious a consacré des mois à ce hack, pratiquant une rétro-ingénierie minutieuse du protocole des serrures Onity, mais la vérité est bien plus triste. « Avec cette simplicité enfantine, je ne serais pas surpris si un millier d’autres personnes avait trouvé la même vulnérabilité et l’avais vendue à d’autres gouvernements » déclare Brocious, dans une interview accordée à Forbes. « Un stagiaire à la NSA pourrait trouver cela en cinq minutes. »

C’est de cette manière qu’il justifie la divulgation au public de la vulnérabilité : si les agences de sécurité et les milices privées ont déjà accès à des millions de chambres d’hôtel, alors de cette manière Brocious contraint Onity a corriger son erreur. Informer le public signifie aussi que nous pouvons trouver d’autres méthodes pour sécuriser nos chambres – avec des chaînes ou des verrous blindés à l’intérieur des chambres par exemple.

Concernant la justification d’Onity pour un tel manquement à la sécurité, personne ne sait. Généralement, tant que les affaires roulent, sécuriser un système est une dépense inutile – jusqu’à ce que celui-ci soit hacké. Ce genre de vulnérabilité n’a rien d’extraordinaire venant d’une entreprise traditionnelle – en général, une entreprise n’embauche un spécialiste de la sécurité qu’après avoir connu un hack surmédiatisé. Pour une entreprise dont le rôle est de sécuriser le sommeil de millions de personnes chaque nuit, Onity aurait pu faire preuve d’un peu plus de précautions.

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

La technologie a fait faire à la santé d’extraordinaires progrès. Mais libre ou propriétaire ? Dans le domaine des appareils médicaux pilotés par des logiciels ce choix peut avoir de très lourdes conséquences.

Ici plus qu’ailleurs, sacrifier l’humain sur l’autel du business model ne peut plus être une solution durable dans le temps^[1].

Lorsque le code peut tuer ou guérir

When code can kill or cure

Technology Quarterly – 2 juin 2012 – The Economist
(Traduction : balsamic, moala, Isammoc, Otourly, Mnyo, HgO, elquan)

Appliquer le modèle open source à la conception d’appareils médicaux permet d’accroitre la sécurité et stimule l’innovation.

Les pompes SMART délivrent des médicaments parfaitements dosés pour chaque patient. Des défibrilateurs faciles à utiliser peuvent ramener des victimes d’attaque cardiaque d’entre les morts. Les pacemakers et coeurs artificiels maintiennent les gens en vie en s’assurant que la circulation sanguine se déroule sans problème. Les appareils médicaux sont une merveille du monde moderne.

Alors que ces appareils sont devenus de plus en plus efficients, ils deviennent cependant de plus en plus complexes. Plus de la moitié des appareils médicaux vendus aux Etats-Unis (le plus grand marché de la santé) s’appuient sur du logiciel, et souvent en grande quantité. Ainsi le logiciel dans un pacemaker peut nécessiter plus de 80.000 lignes de code, une pompe à perfusion 170.000 lignes et un scanner à IRM (Imagerie à Résonance Magnétique) plus de 7 millions de lignes.

Cette dépendance grandissante vis à vis du logiciel cause des problèmes bien connus de tous ceux qui ont déjà utilisé un ordinateur : bugs, plantages, et vulnérabilités face aux attaques. Les chercheurs de l’université de Patras en Grèce ont découvert qu’un appareil médical sur trois vendu aux États-Unis entre 1995 et 2005 a été rappelé pour défaillance du logiciel. Kevin Fu, professeur d’informatique à l’université du Massachusetts, estime que ce phénomène a affecté plus de 1,5 millions d’appareils individuels depuis 2002. En avril, les chercheurs de la firme de sécurité informatique McAfee ont annoncé avoir découvert un moyen pour détourner une pompe à insuline installée dans le corps d’un patient en injectant l’équivalent de 45 jours de traitement d’un seul coup. Enfin, en 2008, Dr Fu et ses collègues ont publié un article détaillant la reprogrammation à distance d’un défibrillateur implanté.

Or le disfonctionnement du logiciel d’un appareil médical a des conséquences beaucoup plus désastreuses que d’avoir seulement à faire redémarrer votre ordinateur. Durant les années 1980, un bug dans le logiciel des machines de radiothérapie Therac-25 a provoqué une overdose de radiations administrées à plusieurs patients, en tuant au moins cinq. L’Organisation américaine de l’alimentation et des médicaments, l’America’s Food and Drug Administration (FDA), s’est penchée sur le cas des pompes à perfusion qui ont causé près de 20.000 blessures graves et plus de 700 morts entre 2005 et 2009. Les erreurs logicielles étaient le problème le plus fréquemment cité. Si, par exemple, le programme buggé interprète plusieurs fois le même appui sur une touche, il peut administrer une surdose.

En plus des dysfonctionnements accidentels, les appareils médicaux sans fils ou connectés sont également vulnérables aux attaques de hackers malveillants. Dans le document de 2008 du Dr Fu et de ses collègues, il est prouvé qu’un défibrillateur automatique sous-cutané peut être reprogrammé à distance, bloquer une thérapie en cours, ou bien délivrer des chocs non attendus. Le Dr Fu explique que lors des phases de test de leur logiciel, les fabricants d’appareils manquent de culture de la sécurité, culture que l’on peut trouver dans d’autres industries à haut risque, telle que l’aéronautique. Insup Lee, professeur d’Informatique à l’Université de Pennsylvanie, confirme : « Beaucoup de fabricants n’ont pas l’expertise ou la volonté d’utiliser les mises à jour ou les nouveaux outils offerts par l’informatique ».

Personne ne peut évaluer avec certitude l’étendue réelle des dégâts. Les logiciels utilisés dans la majorité des appareils médicaux sont propriétaires et fermés. Cela empêche les firmes rivales de copier le code d’une autre entreprise, ou simplement de vérifier des infractions à la propriété intellectuelle. Mais cela rend aussi la tâche plus ardue pour les experts en sécurité. La FDA, qui a le pouvoir de demander à voir le code source de chaque appareil qu’elle autorise sur le marché, ne le vérifie pas systématiquement, laissant aux constructeurs la liberté de valider leurs propres logiciels. Il y a deux ans, la FDA offrait gratuitement un logiciel « d’analyse statique » aux constructeurs de pompes à perfusion, dans l’espoir de réduire le nombre de morts et de blessés. Mais aucun constructeur n’a encore accepté l’offre de la FDA.

Ouvert à l’étude

Frustrés par le manque de coopération de la part des fabricants, certains chercheurs veulent maintenant rebooter l’industrie des appareils médicaux en utilisant les techniques et modèles open source. Dans les systèmes libres, le code source est librement partagé et peut être visionné et modifié par quiconque souhaitant savoir comment il fonctionne pour éventuellement en proposer une version améliorée. En exposant la conception à plusieurs mains et à plusieurs paires de yeux, la théorie veut que cela conduise à des produits plus sûrs. Ce qui semble bien être le cas pour les logiciels bureautiques, où les bugs et les failles de sécurité dans les applications open source sont bien souvent corrigés beaucoup plus rapidement que dans les programmes commerciaux propriétaires.

Le projet d’une pompe à perfusion générique et ouverte (Generic Infusion Pump), un effort conjoint de l’Université de Pennsylvanie et de la FDA, reconsidère ces appareils à problèmes depuis la base. Les chercheurs commencent non pas par construire l’appareil ou écrire du code, mais par imaginer tout ce qui peut potentiellement mal fonctionner dans une pompe à perfusion. Les fabricants sont appelés à participer, et ils sont plusieurs à le faire, notamment vTitan, une start-up basée aux Etats-Unis et en Inde « Pour un nouveau fabricant, c’est un bon départ » dit Peri Kasthuri, l’un de ses co-fondateurs. En travaillant ensemble sur une plateforme open source, les fabricants peuvent construire des produits plus sûrs pour tout le monde, tout en gardant la possibilité d’ajouter des fonctionnalités pour se différencier de leur concurrents.

Des modèles mathématiques de designs de pompes à perfusion (existantes ou originales) ont été testés vis à vis des dangers possibles, et les plus performantes ont été utilisées pour générer du code, qui a été installé dans une pompe à perfusion de seconde main achetée en ligne pour 20$. « Mon rêve, dit Dave Arnez, un chercheur participant à ce projet, est qu’un hôpital puisse finalement imprimer une pompe à perfusion utilisant une machine à prototypage rapide, qu’il y télécharge le logiciel open source et que l’appareil fonctionne en quelques heures ».

L’initiative Open Source Medical Device de l’université Wisconsin-Madison est d’ambition comparable. Deux physiciens médicaux (NdT: appelés radiophysiciens ou physiciens d’hôpital), Rock Mackie et Surendra Prajapati, conçoivent ainsi une machine combinant la radiothérapie avec la tomographie haute résolution par ordinateur, et la tomographie par émission de positron. Le but est de fournir, à faible coût, tout le nécessaire pour construire l’appareil à partir de zéro, en incluant les spécifications matérielles, le code source, les instructions d’assemblages, les pièces suggérées — et même des recommandations sur les lieux d’achat et les prix indicatifs. La machine devrait coûter environ le quart d’un scanner commercial, la rendant attractive pour les pays en voie de développement, déclare le Dr Prajapati. « Les appareils existants sont coûteux, autant à l’achat qu’à la maintenance » rappelle-t-il, là ou les modèles libres sont plus durables. « Si vous pouvez le construire vous-même, vous pouvez le réparer vous-même. »

Les appareils open source sont littéralement à la pointe de la science médicale. Un robot chirurgien open source nommé Raven, conçu à l’Université de Washington à Seattle fournit une plateforme d’expérimentation abordable aux chercheurs du monde entier en proposant de nouvelles techniques et technologies pour la chirurgie robotique.

Tous ces systèmes open source travaillent sur des problématiques diverses et variées de la médecine, mais ils ont tous un point commun : ils sont encore tous interdit à l’utilisation sur des patients humains vivants. En effet, pour être utilisés dans des centres cliniques, les appareils open source doivent suivre les mêmes longues et coûteuses procédures d’approbation de la FDA que n’importe quel autre appareil médical. Les réglementations de la FDA n’imposent pas encore que les logiciels soient analysés contre les bugs, mais elles insistent sur le présence d’une documentation rigoureuse détaillant leur développement. Ce n’est pas toujours en adéquation avec la nature collaborative et souvent informelle du développement open source.

Le coût élevé de la certification a forcé quelques projets open source à but non lucratif à modifier leur business model. « Dans les années 90, nous développions un excellent système de planning des traitements de radiothérapie et avions essayé de le donner aux autres cliniques, explique le Dr Mackie, mais lorsque la FDA nous a suggéré de faire approuver notre logiciel, l’hôpital n’a pas voulu nous financer. » Il a fondé une société dérivée uniquement pour obtenir l’approbation de la FDA. Cela a pris quatre ans et a couté des millions de dollars. En conséquence, le logiciel a été vendu en tant qu’un traditionnel produit propriétaire fermé.

D’autres tentent de contourner totalement le système de régulation américain. Le robot chirurgical Raven (Corbeau) est destiné à la recherche sur les animaux et les cadavres, quant au scanner de l’Open Source Medical Device, il est conçu pour supporter des animaux de la taille des rats et des lapins. « Néanmoins, déclare le Dr Mackie, rien n’empêche de reprendre le design et de lui faire passer les procédures de certification dans un autre pays. Il est tout à fait envisageable que l’appareil soit utilisé sur des humains dans d’autres parties du monde où la régulation est moins stricte, avance-t-il. Nous espérons que dans un tel cas de figure, il sera suffisamment bien conçu pour ne blesser personne. »

Changer les règles

La FDA accepte progressivement l’ouverture. Le Programme d’interopérabilité des appareils médicaux Plug-and-Play, une initiative de 10 millions de dollars financé par le NIH (l’Institut National de la Santé) avec le support de la FDA, travaille à établir des standards ouverts pour interconnecter les appareils provenant de différents fabricants. Cela signifierait, par exemple, qu’un brassard de pression artérielle d’un certain fabricant pourrait commander à une pompe à perfusion d’un autre fabricant d’arrêter la délivrance de médicament s’il détecte que le patient souffre d’un effet indésirable.

Le framework de coordination des appareils médicaux (Medical Device Coordination Framework), en cours de développement par John Hatcliff à l’Université de l’État du Kansas, est plus intrigant encore. Il a pour but de construire une plateforme matérielle open source comprenant des éléments communs à beaucoup d’appareils médicaux, tels que les écrans, les boutons, les processeurs, les interfaces réseaux ainsi que les logiciels pour les piloter. En connectant différents capteurs ou actionneurs, ce cœur générique pourrait être transformé en des dizaines d’appareils médicaux différents, avec les fonctionnalités pertinentes programmées en tant qu’applications (ou apps) téléchargeables.

À terme, les appareils médicaux devraient évoluer vers des ensembles d’accessoires spécialisés (libres ou propriétaires), dont les composants primaires et les fonctionnalités de sécurité seraient gérés par une plateforme open source. La FDA travaille avec le Dr Hatcliff pour développer des processus de création et de validation des applications médicales critiques.

Dans le même temps, on tend à améliorer la sécurité globale et la fiabilité des logiciels dans les appareils médicaux. Le NIST (Institut national des États-Unis des normes et de la technologie) vient juste de recommander qu’une seule agence, probablement la FDA, soit responsable de l’approbation et de la vérification de la cyber-sécurité des appareils médicaux, et la FDA est en train de réévaluer ses capacités à gérer l’utilisation croissante de logiciels.

De tels changements ne peuvent plus attendre. « Quand un avion s’écrase, les gens le remarquent », dit le Dr Fu. « Mais quand une ou deux personnes sont blessées par un appareil médical, ou même si des centaines sont blessées dans des régions différentes du pays, personne n’y fait attention. » Avec des appareils plus complexes, des hackers plus actifs et des patients plus curieux et impliqués, ouvrir le cœur caché de la technologie médicale prend vraiment ici tout son sens.

L’informatique est de plus en plus présente dans nos vies et globalement toujours aussi absente dans l’éducation. Résultat, une sorte de frénésie s’est emparée de la plupart des observateurs : il faut apprendre à la société à coder !

Le Framablog n’est d’ailleurs pas le dernier à participer au mouvement :

• Comment j’ai appris à programmer ou le témoignage qui donnait envie de s’y mettre
• De l’impact politique d’apprendre aux enfants la libre programmation
• Les codeurs sont la nouvelle élite politique
• Le code deviendra-t-il le latin du XXIe siècle ?
• Sortie du manuel Introduction à la science informatique (+ commentaires)

Une voix discordante vient cependant de se faire entendre récemment en suscitant de nombreuses réactions.

Une voix de l’intérieur, puisqu’il s’agit de Jeff Atwood, développeur de renom^[1].

N’apprenez pas à coder, merci.

Please Don’t Learn to Code

Jeff Atwood – 15 mai 2012 – CodingHorror.com
(Traduction Framalang : Goofy)

Le nouveau mantra « tout le monde devrait apprendre à programmer » a pris des proportions tellement incontrôlables ces derniers temps que même le maire de New York a pris cette résolution du nouvel an.

Voilà certes une noble déclaration propre à engranger les suffrages de la communauté techno de NYC, mais si le maire de la ville de New York a vraiment besoin de tricoter du code JavaScript pour faire son travail, c’est un symptôme de grave maladie pour la vie politique de l’état de New York. Même si M. Bloomberg se mettait vraiment à «apprendre à coder », que Adam Vandenberg me pardonne cet emprunt, je crois qu’on aboutirait à quelque chose comme :

10 PRINT "JE SUIS LE MAIRE"
20 GOTO 10

Heureusement, les risques qu’une telle prouesse technologique se produise sont proches de zéro, et pour une bonne et simple raison : le maire de New York passera plutôt son temps à faire le travail pour lequel les contribuables le paient, et c’est tant mieux. Selon la page d’accueil du secrétariat du maire, il s’agit de lutter contre l’absentéisme scolaire, pour l’amélioration des services de transports en commun, pour l’équilibre de budget municipal en 2013 et… dois-je vraiment poursuivre ?

Je m’adresse à ceux qui prétendent que savoir programmer est une compétence essentielle que nous devrions enseigner à nos enfants, au même titre que lire, écrire et compter. Pourriez-vous m’expliquer en quoi Micheal Bloomberg accomplirait mieux sa tâche quotidienne à la tête de la plus grande ville des USA s’il se réveillait un beau matin en étant devenu un petit génie de la programmation en Java ? Il me semble évident qu’être un lecteur averti, un écrivain talentueux, et posséder le minimum requis en mathématiques sont essentiels à l’exécution du travail d’un politicien. Et à n’importe quel autre emploi du reste. Ça l’est beaucoup moins pour ce qui concerne la maîtrise des variables, des fonctions, des pointeurs ou de la récursivité,

Attendez, j’adore programmer. Je suis également convaincu que la programmation c’est important… mais dans le contexte adéquat, et pour certaines personnes. Tout comme un grand nombre de compétences. Je n’inciterais pas tout le monde à apprendre la programmation, pas plus que je ne pousserais tout le monde à apprendre la plomberie. Ce serait ridicule, non ?

La mode du « tout le monde devrait apprendre à coder » n’est pas seulement néfaste parce qu’elle met la programmation sur un pied d’égalité avec d’autres compétences comme la lecture, l’écriture et le calcul. Selon moi, elle est mauvaise pour un grand nombre d’autres raisons.

• Elle part du postulat que le monde entier désire ardemment davantage de code. En trente ans de carrière comme programmeur, j’ai constaté que… ce n’est pas le cas. Devriez-vous apprendre à écrire du code ? Non, je n’en démords pas. Vous devriez apprendre à écrire le moins de code possible. Et même pas de code du tout, idéalement.

• Elle présuppose que la programmation est un but en soi. Les développeurs de logiciels ont tendance à devenir des drogués de la programmation qui croient que leur travail consiste à écrire du code. Ils se trompent. Leur travail consiste à résoudre des problèmes. Ne célébrez pas la création de code, célébrez la mise au point de solutions. Nous avons déjà une pléthore de codeurs complètement accros à l’idée d’ajouter encore une ligne de code.

• Elle met la charrue avant les bœufs. Avant de vous précipiter pour apprendre à coder, analysez soigneusement la nature exacte de votre problème. Avez-vous seulement un problème, au fait ? Êtes-vous capable de l’expliquer à d’autres de manière compréhensible ? Avez-vous mené une recherche approfondie des possibles solutions à ce problème ? La programmation permet-elle de résoudre le problème ? En êtes-vous sûr ?

• Elle suppose qu’adjoindre à la force de travail des codeurs naïfs, inexpérimentés, et même-pas-trop-sûrs-d’aimer-ce-truc-de-programmer serait un gain appréciable pour l’humanité. Je pense que c’est exact si vous considérez qu’un mauvais programmeur peut facilement provoquer deux créations d’emploi nouvelles par an. Et à ce propos, notez que la plupart de ceux qui s’autoproclament programmeurs ne savent même pas coder, vous me pardonnerez donc mon scepticisme sur ce préjugé « tout me monde peut apprendre à coder ».

• Elle suppose qu’il existe une cloison mobile de l’épaisseur d’une feuille à cigarette entre apprendre à programmer et en faire une activité professionnelle rémunérée. Regardez un peu ces nouveaux programmeurs à qui l’on propose des emplois payés sur la base de $79k/an (NdT : environ 62 000 euros) après avoir assisté à une simple session d’entraînement de deux mois et demi ! Vous pouvez même apprendre le Perl par vous-même en 24 heures ! Certes j’adore que la programmation soit un domaine égalitaire dans lequel les diplômes et les certifications sont sans objet en regard de l’expérience, mais il va bien falloir vous y plonger pendant dix mille heures comme nous tous.

Je suppose que je peux accepter l’idée qu’apprendre un peu de programmation vous permet de savoir reconnaître ce qu’est le code, et quand le code peut être un moyen adéquat d’aborder un problème que vous rencontrez. Mais je peux aussi bien repérer des problèmes de plomberie quand j’en vois sans avoir bénéficié d’une formation spécifique dans ce domaine. La population au sens large (et ses dirigeants politiques) tirerait probablement le meilleur profit d’une meilleure compréhension du fonctionnement d’un ordinateur et d’Internet. Être capable de se débrouiller avec Internet est devenu une compétence vitale de base, et c’est ce qui devrait être notre obejctif principal prioritaire, avant de nous jeter à corps perdu dans la programmation.

Merci de ne pas argumenter en faveur de l’apprentissage de la programmation pour le plaisir d’apprendre à programmer. Ou pire encore pour le nombre de zéros sur le bulletin de paie. Je suggère humblement que nous passions plutôt du temps à apprendre à…

• Mener des recherches avec avidité, et comprendre comment fonctionnent les choses autour de nous à un niveau basique.
• Communiquer efficacement avec les autres êtres humains.

Voilà des compétences qui vont bien au-delà de la pure programmation et qui vous aideront dans toutes les circonstances de votre vie.