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

Traduction Framasoft : Miki, peupleLà, dabou, Asta, elquan, Goofy, Julius22, okram, lamessen, Jej, lerouge, SaSha_01, Lycoris, meumeul, vvision

Ne soyez pas timide

Máirín Duffy Strode

Máirín Duffy Strode utilise des logiciels libres et open source depuis le lycée et y contribue depuis huit ans. Elle contribue aux communautés Fedora et GNOME et a travaillé sur l’identité visuelle des interactions, l’image de marque ou l’iconographie de plusieurs applications libres et open source importantes telles que Spacewalk, Anaconda, virt-manager, SELinux et SSSD. Elle s’est également engagée dans des activités de sensibilisation en enseignant les techniques de design à des enfants à l’aide d’outils libres et open source tels que GIMP et Inkscape qu’elle défend ardemment. Elle est à la tête de l’équipe de conception graphique de Fedora et designer d’interaction senior chez Red Hat, Inc.

Je connaissais et utilisais des logiciels libres et open source bien avant de devenir contributrice. Ce n’est pas faute d’avoir essayé — il y a eu quelques faux départs auxquels je n’ai pas donné suite principalement parce que j’étais trop timide et que j’ai eu peur d’aller plus loin. Sur la base de ces tentatives avortées et de ce que m’ont rapporté d’autres designers qui se sont embarqués dans des projets libres et open source, j’ai cinq astuces à vous offrir si vous êtes un designer aspirant au statut de contributeur au logiciel libre et open source.

1. Sachez que l’on a besoin de vous et qu’on vous veut (très fort !)

Mon premier faux départ s’est produit alors que j’étais étudiante en première année d’informatique au Rensselaer Polytechnic Institute. Il y avait un projet particulier que j’utilisais beaucoup et auquel je voulais participer. Je ne connaissais personne au sein du projet (ni qui que ce soit investi dans le logiciel libre). J’ai donc fait une tentative à froid. Le site web du projet signalait que les contributeurs voulaient de l’aide et qu’ils avaient un canal IRC. J’y ai alors traîné pendant une semaine ou deux. Un jour, après une pause dans la conversation, j’ai osé élever la voix. J’ai dit que j’étais une étudiante en informatique intéressée par l’ergonomie et que j’adorerais participer.

On m’a répondu : « Dégage ! ». Qui plus est, on m’a fait comprendre que mon aide n’était ni nécessaire ni désirée.

Cela a retardé mon engagement de quelques années — il avait suffi de quelques mots un peu rudes sur IRC pour me dissuader de réessayer pendant près de cinq ans. Je ne découvris que bien plus tard que la personne qui m’avait plus ou moins expulsée du canal IRC de ce projet était en marge du projet, qu’elle avait un lourd passif de ce genre et que je n’avais vraiment rien fait de mal. Si seulement j’avais persévéré dans mes tentatives d’approche et conversé avec d’autres personnes, j’aurais pu commencer à ce moment-là.

Si vous souhaitez contribuer au logiciel libre et open source, je vous garantis qu’il y a un projet quelque part qui a vraiment besoin de votre aide, en particulier si vous êtes orienté design ! Faites-vous du design web ? De l’iconographie ? De l’ergonomie ? De l’habillage ? Des maquettes d’interface utilisateur ? J’ai parlé à de nombreux développeurs de logiciels libres et open source qui non seulement sont désespérément à la recherche d’aide dans ce domaine, mais qui en plus l’apprécieraient vraiment et vous vénéreraient pour l’avoir apportée.

Si vous rencontrez des résistances la première fois que vous essayez de participer dans un projet, apprenez de mon expérience et n’abandonnez pas tout de suite. Si, en définitive, le projet n’est pas fait pour vous, ne vous inquiétez pas et passez votre chemin. Il y a des chances pour que vous trouviez un projet que vous adorerez et qui vous adorera en retour.

2. Aidez le projet pour qu’il vous aide à aider les autres

Bien des projets libres et open source sont aujourd’hui dominés par les programmeurs et les ingénieurs. Et si certains ont la chance qu’une ou deux personnes créatives s’investissent, dans la plupart des projets, un designer, un artiste ou une autre présence créative représente un rêve souvent-caressé-mais-jamais-réalisé. En d’autres termes, même s’ils comprennent qu’ils ont besoin de vos compétences, ils peuvent ne pas savoir quelle sorte d’aide ils peuvent vous demander, quelle information ils doivent vous donner pour que vous puissiez être productif ni même les bases pour travailler avec vous efficacement.

Quand j’ai commencé à m’investir dans différents projets libres et open source, j’ai rencontré beaucoup de développeurs qui n’avaient jamais travaillé directement avec un designer auparavant. Au début, je me suis sentie un peu inutile. Je ne pouvais pas suivre toutes leurs conversations sur IRC parce qu’ils parlaient de leur cuisine interne et de détails techniques qui ne m’étaient pas familiers. Quand ils se sont donné la peine de me prêter attention, ils m’ont posé des questions comme « Quelle couleur dois-je mettre ici ? » ou « Quelle police dois-je utiliser ?  ». Ce que je voulais vraiment en tant que designer d’interactions, c’était d’être associée à la prise de décision lorsqu’on abordait les contraintes spécifiques du projet. Si un utilisateur voulait une fonctionnalité particulière, je voulais avoir mon mot à dire sur le design — mais je ne savais pas où ni quand ces décisions se prenaient et je me sentais exclue.

Le design couvre une gamme assez large de compétences : l’illustration, la typographie, la conception des interactions, la conception visuelle, la conception d’icônes, la conception graphique, la rédaction, etc. et il y a peu de chances qu’un seul concepteur les possède toutes. Il est alors compréhensible qu’un développeur ne soit pas sûr de ce qu’il peut vous demander. Ce n’est pas qu’ils essaient de vous faire obstacle — c’est seulement qu’ils ne savent pas dans quelle mesure vous avez besoin de vous investir ou le désirez.

Aidez-les à vous aider. Montrez-leur clairement le type de contributions que vous pouvez apporter en fournissant des exemples de contributions antérieures. Faites-leur comprendre vos besoins de sorte qu’ils comprennent mieux comment vous aider à vous engager dans leur projet. Par exemple, lorsque vous vous impliquez pour la première fois dans une initiative spécifique pour le projet, prenez le temps de présenter les grandes lignes de son processus de conception et postez cela dans la liste de développement principale afin que les autres contributeurs puissent vous accompagner. Si vous avez besoin d’idées sur des points particuliers, soulignez-les dans votre présentation. Si vous n’êtes pas certain de la façon dont certaines choses se produisent — comme le processus de développement d’une nouvelle fonctionnalité — entrez en contact avec quelqu’un en parallèle et demandez-lui de vous l’expliquer pas à pas. Si quelqu’un vous demande de faire quelque chose au-delà de vos capacités techniques — travailler sur de la gestion de versions, par exemple — et que vous n’êtes pas à l’aise avec ça, dites-le.

Communiquer sur votre processus et vos besoins vous évitera de jouer aux devinettes dans le projet et ses membres seront au contraire capables d’utiliser au mieux vos talents.

3. Posez des questions, beaucoup de questions ; il n’y a pas de question idiote

Nous avons parfois remarqué chez Fedora que, lorsque de nouveaux designers arrivaient à bord, ils avaient peur de poser des questions techniques, par crainte de paraître stupides.

Ce qu’on ne vous dit pas, c’est que les développeurs peuvent être tellement spécialisés qu’il y a beaucoup de détails techniques qui sortent de leur domaine de compétence et qu’ils ne comprennent pas non plus — cela se produit même au sein du même projet. La différence, c’est qu’ils n’ont pas peur de demander — donc vous ne devriez pas avoir peur non plus ! Dans mon travail de design des interactions, par exemple, j’ai dû contacter de nombreuses personnes du même projet pour comprendre comment un processus se déroulait dans leur logiciel, car ce dernier comportait plusieurs sous-systèmes et tous les participants du projet ne comprenaient pas forcément comment chaque sous-système fonctionnait.

Si vous ne savez pas sur quoi travailler, que vous ne savez pas par quoi commencer ou que vous ne comprenez pas pourquoi ce que quelqu’un a dit sur le chat est si drôle — demandez. Vous avez des chances que quelqu’un vous réponde qu’il ne sait pas non plus et peu de risques de passer pour stupide. Dans la plupart des cas, vous allez apprendre quelque chose de nouveau qui vous aidera à devenir un meilleur contributeur. Il peut être particulièrement efficace de chercher un tuteur — certains projets ont même un programme de tutorat — et de lui demander s’il veut bien être votre référent quand vous avez des questions.

4. Partagez et partagez souvent, même si ce n’est pas encore prêt, surtout si ce n’est pas encore prêt

Nous avons aussi remarqué que de nouveaux designers pour Fedora et d’autres projets libres et open source sont un peu timides lorsqu’il est question de montrer leur travail. Je comprends qu’on ne veuille pas ruiner sa réputation en publiant quelque chose qui n’est pas ce qu’on peut faire de mieux ni même fini ; mais une grande partie du travail sur des projets libres et open source est de partager souvent et ouvertement.

Plus vous aurez avancé sur un élément avant de le partager, plus il sera difficile à d’autres de vous apporter un retour utilisable, de se lancer et de s’investir. Il est aussi plus difficile pour autrui de collaborer à votre travail et d’avoir un sentiment d’appartenance au projet, de le soutenir et de le pousser jusqu’à l’implémentation. Dans certains projets libres et open source, ne pas être communicatif avec vos ébauches, compositions et idées est même considéré comme offensant !

Publiez vos idées, maquettes ou compositions sur le Web plutôt que par courriel, afin qu’il soit plus aisé pour les autres collaborateurs de faire référence à votre contribution en faisant un copier-coller de l’URL — c’est particulièrement pratique au cours d’une discussion. Plus vos éléments de design seront faciles à trouver, plus il est probable qu’ils seront utilisés.

Essayez ce conseil et gardez l’esprit ouvert. Partagez votre travail tôt et souvent. Rendez disponibles vos fichiers sources. Vous serez peut-être agréablement surpris par ce qui va se passer !

5. Soyez aussi visible que possible au sein de la communauté du projet

Un outil qui — de manière totalement involontaire — a fini par m’aider énormément à démarrer en tant que contributeur de logiciels libres et open source a été mon blog. J’avais commencé à entretenir un blog, simplement pour moi, à l’image d’un portfolio grossier des choses sur lesquelles j’avais travaillé par le passé. Mon blog est un énorme atout pour moi, parce que :

• En tant qu’enregistrement de l’historique des décisions de projet, il représente un moyen pratique pour rechercher d’anciennes décisions de design — comprendre pourquoi nous avons décidé de laisser tomber tel ou tel visuel à nouveau ou pourquoi une approche particulière, précédemment essayée, n’a pas fonctionné, par exemple ;
• En tant que dispositif de communication, il aide les autres contributeurs associés à votre projet et même les utilisateurs à être au courant des travaux en cours et des changements à venir pour le projet. De nombreuses fois, j’ai omis quelque chose d’essentiel dans un design et ces personnes ont très rapidement posté un commentaire pour m’en informer !
• Il m’a aidé à construire ma réputation en tant que designer de logiciels libres et open source, ce qui m’a aidé à gagner la confiance des autres envers mes choix de design avec le temps.

Vous bloguez ? Trouvez quels agrégateurs de blogs lisent les membres du projet auquel vous participez et demandez à ce que votre blog y soit ajouté (il y a en général un lien pour cela dans la barre latérale). Par exemple, l’agrégateur de blogs que vous devrez rejoindre pour faire partie de la communauté Fedora se nomme Planet Fedora. Écrivez un premier billet pour vous présenter aux autres et leur faire savoir ce que vous aimez une fois que vous y aurez été ajouté — des informations du genre de celles listées dans la première astuce.

Le projet aura certainement une liste de diffusion ou un forum où les discussions ont lieu. Rejoignez-les et présentez-vous là aussi. Quand vous apportez une contribution au projet — peu importe qu’elle soit petite ou loin d’être aboutie — postez des billets sur ce que vous faites, téléchargez-le vers le wiki du projet, tweetez à ce sujet et envoyez des liens aux membres importants de la communauté via IRC afin d’avoir leur retour.

Rendez votre travail visible et les gens commenceront à vous associer à votre travail et à vous proposer des projets sympas ou d’autres opportunités, simplement grâce à ça. C’est tout ce que j’aurais aimé savoir quand j’ai essayé de m’investir pour la première fois dans le logiciel libre et open source comme designer. Si vous ne deviez retenir qu’un message de tout cela, c’est que vous ne devriez pas être timide — faites-vous entendre haut et fort, faites connaître vos besoins, faites savoir aux autres quels sont vos capacités et ils vous aideront à les utiliser pour que le logiciel libre envoie du lourd.

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

Traduction Framalang : peupleLà, lerouge, goofy, alpha, Sky, Julius22, vvision, okram, lamessen

Les transformations qui préservent la structure

Le deuxième tome de The Nature of Order décrit comment chacune de ces propriétés définit également une transformation. En voici des exemples.

• Des frontières solides. Vous pouvez parfois transformer quelque chose positivement en lui adjoignant une frontière. Vous installez une palissade autour d’un jardin qui sert alors d’ornement, de coupe-vent afin que des vents forts ne viennent pas endommager le jardin, mais elle existe aussi comme structure en soi. Dans une interface graphique utilisateur, des boîtes à ascenseurs sans cadre sont difficiles à distinguer de l’arrière-plan de la fenêtre (pensez à toutes ces pages web blanches dont les formulaires d’entrée de texte n’ont pas de cadre). Vous placez une corniche sur le toit d’un immeuble afin que la transition entre l’immeuble et le ciel ne soit pas abrupte.
• Des symétries locales. Il est plus facile de construire de petites parties de manière symétrique : parce qu’elles sont fabriquées sur un tour, parce qu’on doit y accéder des deux côtés, parce qu’elles se plient comme un livre. Faire des choses asymétriques, seulement pour l’intérêt de la chose, demande un travail supplémentaire et il est plus difficile d’obtenir quelque chose qui fonctionne bien.
• Un espace positif. Vous vous sentez trop exposé quand vous êtes au bureau ? Ajoutez une étagère à mi-hauteur à côté de vous pour délimiter votre espace mais ne vous enfermez pas complètement. Est-ce que votre interface utilisateur donne l’impression qu’il y a beaucoup d’espace restant une fois que vous avez mis les contrôles en place ? Faites plutôt en sorte que les contrôles entourent l’espace utilisable.

Chacun des points qui précèdent est une transformation qui préserve la structure. Vous effectuez un changement dans la structure existante non pas en la démolissant et en la refaisant, mais en ajustant une chose après l’autre selon ces propriétés comme transformations.

En termes de logiciel, il s’avère que c’est ce en quoi le « Refactoring » consiste surtout, quand vous traduisez les concepts en code. Réorganiser, c’est seulement appliquer des transformations qui préservent la structure ou, comme Martin Fowler — l’auteur de Refactoring — l’aurait présenté, des transformations qui préservent le comportement. Vous ne changez pas ce que fait le programme ; vous changez seulement la manière dont il est construit à l’intérieur, morceau par morceau.

En extrayant un morceau de code et en l’insérant dans une fonction nommée, vous ajoutez essentiellement une frontière solide autour du code et créez un noyau robuste. En enlevant une variable globale et en ajoutant des variables de classe, vous permettez la robustesse, car chaque instance peut maintenant avoir une valeur différente dans cette variable, comme nécessaire. En ayant un producteur/consommateur, ou un émetteur/récepteur, vous avez des symétries locales, des imbrications fortes et ambiguës, et une bonne forme.

Richard Gabriel, l’une des principales personnalités du Common Lisp , a étudié comment appliquer les théories d’Alexander au logiciel (et aussi à la poésie ; le code n’est-il pas similaire à la poésie après tout ?). Il donne l’exemple suivant :

1. Imaginez que vous créez la classe AppelTelephonique. C’est un objet central implicite, qui pourrait être beaucoup plus puissant.



2. Gerard Meszaros dans le modèle DemiObjet + Protocole suggérait de séparer l’objet en deux demi-appels, liés par un protocole. On obtient ainsi une symétrie locale, un centre fort et un effet d’échelle.
3. Maintenant, dessinons cela sous forme de diagramme. On obtient alors de la symétrie locale, de l’effet

   

   

   d’échelle, des frontières, une imbrication forte et de l’ambiguïté. C’est ici que Meszaros a arrêté sa démarche.

4. Richard Gabriel suggère alors de renforcer les centres existants en appliquant d’autres transformations qui préservent la structure. Que faire de l’objet central implicite au milieu ? Vous lui ajoutez une frontière explicite (Appel) qui lie les demiAppels entre eux. Cela améliore les symétries locales, maintient l’imbrication forte et l’ambiguïté, et c’est composable.

   

5. Oui, c’est composable. Des appels multidirectionnels, des conférences téléphoniques, tout cela s’effectue 

   

   grâce à la mise en œuvre de transformations qui préservent la structure.

Chaque développeur garde probablement une image mentale du programme qu’il est en train de créer ou de modifier. La partie la plus difficile dans la modification d’un code que vous n’avez pas écrit est de commencer par visualiser cette image mentale. Quand vous travaillez pour que le code affiche une image plus jolie, il s’améliore — et Alexander nous propose une bonne façon de le faire.

Le processus fondamental

Alexander argumente longuement pour expliquer l’intérêt de suivre ce processus : appliquer des transformations qui préservent la structure est la seule manière de réussir une conception de qualité et fonctionnelle. Cela ne vaut pas seulement pour les immeubles, mais pour tout ce que nous construisons. Peu importe que vous partiez de l’existant — un programme, un bâtiment ou une ville — ou que vous partiez de zéro. Nous imitons la nature dans ses processus d’évolution et de régénération, mais nous allons plus vite.

1. Commencez avec ce que vous avez : un espace vide, un immeuble déjà construit ou bien un programme qui ne ressemble à rien et difficile à utiliser.
2. Identifiez les centres existant dans cet espace. Trouvez le centre le plus faible ou le moins cohérent.
3. Voyez comment appliquer l’une au moins des quinze transformations qui préservent la structure afin de renforcer ce centre faible. A-t-il besoin d’être délimité ? A-t-il besoin de se confondre avec son entourage ? A-t-il besoin de plus de détails ? A-t-il besoin d’être dégagé ?
4. Trouvez les nouveaux centres qui sont apparus quand vous avez appliqué les transformations à l’ancien centre. Cette nouvelle combinaison rend-elle les choses plus fortes ? Les rend-elle plus jolies ? Les rend-elle plus fonctionnelles ?
5. Assurez-vous que vous avez fait la chose la plus simple possible.
6. Retournez au début pour l’étape suivante.

Un résumé extrêmement simple pourrait être : trouvez les mauvaises parties, améliorez-les de la façon la plus simple possible, testez les résultats, réitérez.

Alexander ne tient pas à détruire les choses juste pour les reconstruire de façon différente. Il ne s’agit pas de pas démolir des quartiers d’une ville pour les reconstruire mais de les améliorer progressivement. Pour les logiciels, il est bien connu que vous n’allez pas réécrire quelque chose juste parce que vous ne le comprenez plus. Démolir quelque chose, c’est perdre toutes les connaissances qui avaient été incorporées à cette chose en train d’être détruite, même si elle semble étrange dans son état actuel.

De même, Alexander s’oppose à la création de modèles détaillés au préalable. Il donne un bon argument montrant pourquoi les modèles pré-établis ne peuvent pas fonctionner en fin de compte : parce qu’on ne peut pas prévoir de manière absolue tout ce qui va se passer lors de la construction et de l’implémentation ; parce qu’on oubliera forcément une partie des détails de l’environnement au sein duquel notre création évoluera ; parce que la nature en elle-même n’est pas pré-ordonnée et croît plutôt de manière libre et pousse sans pitié à l’évolution jusqu’à ce que les éléments qui la constituent survivent d’eux-mêmes.

De cette façon, vous ne concevez pas l’interface utilisateur en entier ou la structure complète, pour un grand programme, en une seule étape. Vous allez du grand au petit ou du petit au grand (niveaux d’échelle) ; vous testez chaque partie individuellement jusqu’à ce que ce soit bon (des centres solides) ; vous vous assurez que les parties ne sont pas trop déconnectées les unes des autres (interdépendance). Vous déplacez quelques widgets là où ils sont plus accessibles ou plus proches des données auxquelles ils se réfèrent. Vous enlevez quelques cadres et séparateurs pour réduire le désordre. Par dessus tout, vous évaluez continuellement ce que vous avez créé avec de vrais utilisateurs et des cas d’usage réels pour confronter les choses à la réalité, et non à votre imagination.

Un nom pour la qualité

Tout au long de The Nature of Order, Alexander parvient à montrer que les environnements ou les structures construites selon cette méthode finissent toutes par avoir la Qualité sans Nom. Il appelle cela une structure vivante. Cela peut être mesuré et comparé. Ce n’est plus sans nom ; on peut parler d’environnements ou de programmes qui ont une structure plus ou moins vivante par rapport à d’autres — et nous tendons à développer et à obtenir toujours plus de cette propriété.

J’ai seulement intitulé cet article « Le logiciel comme Qualité sans Nom » parce que ça semblait ainsi plus mystérieux.

Je ne peux prétendre connaître la façon parfaite de concevoir et écrire des logiciels. Mais au moins, j’ai une bonne méthode basée sur ce qui produit de bonnes choses ailleurs. Cela a fonctionné pour ma maison et, jusqu’à présent, ça a très bien marché pour mes logiciels. J’espère que ça fonctionnera bien pour vous aussi !

Références

• Christopher Alexander, A Pattern Language. Version en ligne : http://bit.ly/8n6igg (NdÉ : lien invalide, le 1er février 2013).
• Christopher Alexander, The Nature of Order. Une page web très moche http://www.natureoforder.com (NdÉ : visité le 1er février 2013).
• Photos et dessins des 15 propriétés – http://bit.ly/b82Dxu (NdÉ : visité le 1er février 2013).
• Richard Gabriel, Patterns of Software. Un superbe libre qui traite d’un grand nombre d’aspects du développement des logiciels, en transposant les idées de Christopher Alexander pour atteindre les meilleures techniques possibles en développement de logiciel. Version en ligne : http://bit.ly/dqGUp4 (NdÉ : visité le 1er février 2013).
• Richard Gabriel, Christopher Alexander, the search for beauty. Une excellente présentation des idées de Christopher Alexander et une galerie de modèles dans le domaine du logiciel. http://bit.ly/ztE6cp (NdÉ : visité le 1er février 2013).
• Richard Gabriel, The Nature of Order. Le monde post-modèles. Une autre très bonne présentation, qui fait suite à la précédente, explique les 15 propriétés, le processus fondamental et comment cela peut s’appliquer au logiciel. http://dreamsongs.com/Files/NatureOfOrder.pdf (NdÉ : visité le 1er février 2013).
• Federico Mena Quintero, Software that has the Quality Without A Name. Présentation Desktop Summit de Berlin en 2011. http://bit.ly/oYgJUf (NdÉ : visité le 1er février 2013).

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

Traduction Framalang : Sphinx, peupleLà, lerouge, goofy, alpha, Sky, Julius22, lamessen, vvision, Garburst, okram

Le guichet de billetterie

La thèse de doctorat d’Alexander a servi de base à son livre Notes on the Synthesis of Form (NdT : Remarques sur la synthèse de la forme), paru en 1964. Il essayait de rationaliser le processus de conception en le définissant comme une progression depuis une série de conditions préalables jusqu’à un résultat final, grâce à une analyse des forces qui déterminent le design.

Permettez-moi de citer Richard Gabriel, dont je parlerai plus tard, quand il décrit l’époque où Alexander essayait de concevoir un guichet de billetterie en prenant appui sur ses idées mathématiques :

Alexander dit (à propos de la qualité sans nom) :

Il s’agit d’un type subtil de liberté issu de contradictions internes. (Alexander, 1979)

Cette assertion fait écho aux origines de sa recherche sur la qualité. Elle commença en 1964 alors qu’il était en train de réaliser une étude pour le San Francisco Bay Area Rapid Transit District (BART) basée sur le travail rapporté dans Notes on the Synthesis of Form (Alexander 1964), lui-même basé sur sa thèse de doctorat. L’une des idées-clés de ce livre était qu’avec une bonne conception, il doit y avoir une relation sous-jacente entre la structure du problème et la structure de la solution — les bonnes conceptions passent par la rédaction d’une analyse des besoins, l’analyse de leurs interactions sur les bases d’incompatibilités potentielles, produisant ainsi une décomposition hiérarchisée des différentes parties, et la reconstitution d’une structure dont

la hiérarchie structurelle est l’exact complémentaire de la hiérarchie fonctionnelle établie durant l’analyse du programme. (Alexander, 1964)

Alexander a analysé le système de forces mises en jeu dans la conception d’un guichet. Lui et son groupe avaient rédigé un cahier des charges en 390 points pour couvrir tous les cas de figure d’usage de l’édicule. Certaines spécifications concernaient des choses telles qu’être là pour obtenir des billets, pouvoir faire de la monnaie, pouvoir déplacer les personnes qui font la queue, réduire la durée d’attente pour obtenir des billets. Il a toutefois remarqué que certaines parties du système n’étaient pas concernées par ces spécifications et que le système lui-même pouvait s’enliser parce que ces autres forces — celles qui ne faisaient pas l’objet d’une spécification — agissaient pour arriver à leur propre équilibre au sein du système. Par exemple, si une personne s’arrêtait et qu’une autre s’arrêtait également pour parler avec la première, cela pouvait créer un embouteillage susceptible de mettre en échec les mécanismes mis au point pour maintenir une circulation fluide. Bien sûr, l’absence d’embouteillage faisait partie des spécifications. Mais il n’y avait rien que les concepteurs puissent faire pour l’empêcher par le biais d’un mécanisme adapté.

En tant que programmeur, ça doit vous rappeler quelque chose ? Vous pouvez élaborer une conception magnifique et parfaitement rigoureuse, mais qui s’effondrera quand vous la construirez effectivement parce que des éléments que vous n’aviez pas anticipés apparaitront alors. Ce n’est pas un échec de votre conception, mais de quelque chose d’autre ! Richard Gabriel poursuit :

Alexander disait ceci :

Il devint alors clair que le bon fonctionnement d’un système ne dépendait pas uniquement de la satisfaction d’une série de conditions préalables. Il s’agissait plutôt d’un système qui trouve sa cohérence en lui-même et en équilibre avec les forces internes générées par ledit système que de l’accord avec une série quelconque de conditions préalables que nous aurions arbitrairement définie. Cela m’intriguait beaucoup car l’idée qui prévalait en général à l’époque (en 1964) était que, pour l’essentiel, tout était fondé sur des objectifs. Toute mon analyse des conditions préalables tendait à converger avec le point de vue de la recherche opérationnelle qui pose qu’il faut établir des objectifs, etc. Ce qui m’ennuyait, c’est qu’une analyse correcte du guichet ne pouvait se baser uniquement sur des objectifs quelconques ; il y avait des réalités qui émergeaient du centre du système lui-même et qui, peu importe votre degré de réussite, avaient un rapport avec le fait que vous ayez créé une configuration stable au regard de ces réalités.

Et c’est le cœur du problème : comment créer une configuration stable avec les réalités qui en émergent au fur et à mesure que vous la construisez ?

La nature de l’ordre

Bien que Christopher Alexander ait eu conscience d’avoir produit quelque chose de précieux avec ses recherches et catalogues de modèles, il n’était pas complètement satisfait. D’où venaient les modèles ? Pouvait-on les créer à partir de rien ou devait-on se satisfaire de ce qu’avait produit jusque-là l’architecture traditionnelle ? D’ailleurs, les modèles étaient-ils réellement nécessaires ? Comment pouvait-on mieux définir et évaluer ou mesurer cette « Qualité sans nom » ?

Alexander passa les vingt années suivantes à tenter de répondre à ces questions. En étudiant le processus réel de création par lequel des environnements bien construits avaient vu le jour, il découvrit que certains processus sont indispensables pour créer des villes ou des édifices agréables — ou toute création humaine en fait. Il arriva aux conclusions suivantes :

• La nature crée des choses qui ont toutes une quinzaine de propriétés en commun (je vous expliquerai plus tard). Cela se produit uniquement par des processus naturels — physique et chimie de base — bien que nous ne sachions pas clairement pourquoi des procédés très différents produisent des résultats similaires ;

• On retrouve ces propriétés dans les architectures traditionnelles ou les villes qui ont simplement évolué au cours du temps. Tous les modèles décrits dans A Pattern Language peuvent être obtenus en suivant une méthode fondée sur ces propriétés ;

• Chaque propriété peut également décrire une transformation de l’espace existant ;

• La seule façon de réussir une bonne conception consiste à utiliser ces transformations, une à la fois.

Ceci a été publié en 2003 – 2004 en quatre tomes intitulés The Nature of Order (NdT : « La nature de l’ordre »).

Les quinze propriétés

Le premier tome de La nature de l’ordre traite de quinze propriétés qui apparaissent dans tous les systèmes naturels. Je les résumerai très brièvement (voir les références pour des illustrations et de plus amples explications).

• Des niveaux d’échelle. La gamme de tailles est équilibrée, sans changement brutal dans la taille d’objets adjacents. Les éléments ont une échelle fractale ;
• Des centres forts. Les différentes parties de l’espace ou de la structure sont clairement identifiables ;
• Des frontières solides. Les lignes délimitent les choses. Dans les systèmes vivants, les bords sont les environnements les plus productifs (par exemple, toutes les créatures qui vivent au bord de l’eau) ;
• Des répétitions alternées. Haut/bas, épais/fin, forme A et forme B. Les objets oscillent et alternent afin de créer un bon équilibre ;
• Un espace positif. L’espace adopte une belle forme convexe et close. Ce n’est pas de l’espace excédentaire. Pensez à la manière dont les cellules d’un diagramme de Voronoï grandissent vers l’extérieur à partir d’un ensemble de points ou à la manière dont les grains d’un épi de maïs se développent à partir de petits points jusqu’à ce qu’ils touchent les grains adjacents ;
• Une bonne forme. Les voiles d’un bateau, la coquille d’un escargot, le bec d’un oiseau. Ils parviennent à la forme optimale qui sert leur fonction, ce qui est magnifique ;
• Des symétries locales. Le monde n’est pas symétrique dans son ensemble. Cependant, les petites choses tendent à être symétriques parce que, de cette manière, c’est plus facile. Votre maison n’est pas symétrique, mais chaque fenêtre l’est ;
• Une profonde imbrication et de l’ambiguïté. Les rues sinueuses des vieilles villes. Les axones des neurones. Il est difficile de séparer la forme du fond, ou l’avant-plan de l’arrière-plan. Deux centres forts sont renforcés si un troisième est placé entre eux de manière à ce qu’il appartienne aux deux ;
• Du contraste. Vous pouvez distinguer où une chose se termine et où la suivante commence parce qu’elles ne se fondent pas l’une dans l’autre ;
• Des degrés. Les choses se confondent les unes les autres là où c’est nécessaire. Les concentrations dans des solutions, les congères ou les talus, les câbles supportant un pont. La manière dont la bande passante décroît alors que vous vous éloignez de l’antenne ;
• Des aspérités. Le monde n’est ni exempt de frottement, ni doux. Les irrégularités sont bénéfiques car elles permettent à chaque élément de s’adapter à son environnement, plutôt que d’être une copie conforme qui n’irait pas aussi bien ;
• Des échos. Les choses se répètent et se font écho. Elles sont uniques dans la précision de leur forme mais leurs contours généraux se répètent à l’infini ;
• Du vide. Parfois, vous avez un grand espace vide pour la tranquillité de la forme. Un lac, une cour, le cadre d’une image ;
• De la simplicité et du calme intrinsèque. Les choses sont aussi simples que possible, sans être simplistes ;
• De l’interdépendance. Chaque chose est dépendante de tout le reste. On ne peut pas séparer un poisson du bassin et des plantes aquatiques. On ne peut pas séparer une colonne de la base du bâtiment.

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

Traduction Framalang : Sphinx, peupleLà, lerouge, goofy, alpha, Julius22, SaSha_01, vvision, lamessen, Bob, lamessen, Garburst, okram

Le logiciel comme Qualité sans Nom

Federico Mena Quintero

Federico Mena Quintero est l’un des pères fondateurs du projet GNOME et fut auparavant le mainteneur de GIMP. Il travaillait aux Red Hat Advanced Development Labs durant les débuts de GNOME puis fut l’un des premiers à être recruté chez Ximian où il a principalement travaillé sur le calendrier d’Evolution. Il travaille toujours autour de GNOME pour Novell/Suse et vit au Mexique.

Lorsque j’apprenais la programmation, j’ai remarqué que je rencontrais souvent le même problème, encore et encore. J’écrivais souvent un programme qui fonctionnait relativement bien et était même bien structuré. Mais après quelques modifications et améliorations, je ne pouvais plus l’améliorer davantage. Soit sa complexité me surpassait, soit il était écrit de telle manière qu’il ne permettait pas d’évolution, comme une maison que vous ne pouvez pas agrandir à cause d’un toit pentu ou que vous ne pouvez pas étendre sur les côtés à cause des murs qui l’entourent.

À mesure que je progressais, j’ai appris à gérer cette complexité. Nous apprenons tous à le faire avec différents outils et techniques : l’abstraction, l’encapsulation, l’orientation objet, les techniques fonctionnelles, etc. Nous apprenons comment diverses techniques nous permettent d’écrire des programmes plus complexes.

Cependant, le problème d’un programme trop optimisé ou bien trop intimement enchevêtré pour être modifié a persisté. Parfois, je pensais tenir une superbe conception. Mais la modifier d’une façon quelconque l’aurait « amochée » et je ne le souhaitais pas. D’autres fois, j’avais quelque chose avec tellement de parties imbriquées que je ne pouvais plus y connecter quoi que ce soit sans que tout s’effondre sous son propre poids.

Il y a quelques années, la manie de la réécriture a débuté sans que j’y prête trop attention. Je me disais que c’était une façon de nettoyer le code, mais après ? Je sais déjà comment prendre un morceau de code et le transformer en fonction ; je sais déjà comment prendre des morceaux de code similaires et les transformer en classes dérivées. Je sais déjà écrire du code presque entièrement propre. Quel est donc le problème ?

J’ai écarté la refactorisation(1) en la considérant comme destinée aux programmeurs les moins expérimentés ; comme de jolies recettes de nettoyage de code mais rien qui ne puisse être découvert par soi-même.

La même chose s’est produite avec les canevas de conception. Je pensais qu’ils donnaient simplement des noms pompeux tels que Singleton et Strategy à des types de structures de tous les jours qu’on utiliserait naturellement dans un programme. Peut-être mon ego de programmeur était-il trop démesuré pour considérer ces travaux avec sérieux. C’est alors que quelque chose s’est produit.

Le travail de Christopher Alexander

Il y a quelques années, mon épouse et moi avons acheté une petite maison de plain-pied et nous souhaitions l’agrandir. Nous envisagions d’avoir un enfant et avions, par conséquent, besoin de plus d’espace. J’avais besoin d’un vrai bureau à domicile, pas une simple niche inoccupée dans laquelle mon bureau et mes étagères de livres tiendraient à peine. En tant que cuisiniers avides, nous avions tous les deux besoin d’une cuisine plus spacieuse et confortable que celle de notre maison. Mon épouse avait besoin d’une pièce bien à elle.

Nous ne voulions pas payer pour un architecte coûteux et aucun de nous deux n’avait la moindre connaissance en matière de construction. Comment allions-nous concevoir notre maison ?

Par moments, en naviguant sur le Web, je me rappelais que j’avais déjà vu le nom d’un auteur, le titre d’un livre ou quelque chose comme ça. Il se peut que je n’y aie pas vraiment porté attention par le passé mais, d’une manière ou d’une autre, plus je vois la même chose mentionnée, plus il est probable que je finirai par m’y intéresser suffisamment pour aller voir de quoi il s’agissait. « Oh, plusieurs personnes ont déjà mentionné ce nom ou ce livre ; je devrais peut-être y jeter un coup d’œil  »

C’est exactement ce qui s’est passé avec le nom de Christopher Alexander. J’avais lu que c’était un architecte assez spécial (de vrais bâtiments, pas de logiciels), connecté en quelque sorte au monde du logiciel par le biais de techniques orientées objet. J’ai été passionné par son travail dès que j’ai commencé à le découvrir par mes lectures.

Dans les années 1970, Christopher Alexander était un mathématicien et professeur d’architecture à l’université de Californie, Berkeley. Lui et un groupe d’architectes de la même mouvance que lui ont parcouru le monde, essayant de comprendre pourquoi il existait des endroits construits par des humains (cités, villes, parcs, immeubles, maisons) où il était très agréable de vivre, confortables, conviviaux et jolis, tandis que d’autres endroits ne l’étaient pas. Des lieux agréables étaient présents dans toutes les architectures traditionnelles du monde — européennes, africaines, asiatiques et américaines — amenant à l’idée que des facteurs communs étaient sans doute extractibles.

Alexander et son équipe ont réparti leurs découvertes au sein d’une liste de motifs architecturaux cohérents et publié trois livres : The Timeless Way of Building (NdT « L’art de la construction intemporelle » en français), où sont décrites la philosophie et la méthode nécessaires à une bonne construction ; A Pattern Language (NdT : « Un langage de schémas » en français), que je décris ci-après et The Oregon Experiment (NdT « L’expérience de L’Oregon » en français) où sont détaillés la conception et la construction d’un campus universitaire grâce à leur méthode.

Une grammaire de modèles

Un modèle (ou schéma) est un problème récurrent lors de la conception et de la construction d’objets, en lien avec les contraintes qui modèlent le problème et avec une solution connectée, quasi-récursivement à d’autres modèles-pères ou modèles-fils. Par exemple, considérons le GRADIENT D’INTIMITÉ, un modèle important dans le livre (les modèles étant en capitales dans ce livre pour en faciliter l’identification, je ferai donc de même) :

GRADIENT D’INTIMITÉ

<!-- wikipedia : patron de conception *

pour la compréhension : http://www.jacana.plus.com/pattern/P127.htm */ --> Modèles-pères, et préambule : … si vous savez à peu près où vous avez l’intention de placer les ailes du bâtiment, LES AILES DE LUMIÈRE, et combien d’étages elles auront, le NOMBRE D’ÉTAGES, et où L’ENTRÉE PRINCIPALE se trouve, alors il est temps de travailler sur la disposition approximative des zones principales de chaque niveau. Dans tout bâtiment, la relation entre les zones publiques et les zones privées est de la plus haute importance.

Énoncé du problème : à moins que les volumes d’un édifice ne soient disposés dans un ordre correspondant à leur degré d’intimité, les visites des étrangers, amis, invités, clients, famille seront toujours un peu gênantes.

Explication : je ne vais pas tout citer. Prenez, par exemple, un appartement où la seule façon d’atteindre la salle de bain est de passer d’abord par la chambre à coucher. Les visites sont toujours gênantes car vous avez l’impression de devoir d’abord ranger votre chambre si vous voulez que vos visiteurs puissent utiliser les toilettes. Ou bien considérez des bureaux dans lesquels vous ne voulez pas qu’un espace de travail calme soit à côté de la réception, car alors celui-ci ne sera pas calme du tout — vous voulez qu’il soit plus privé, à l’arrière.

Résumé de la solution : disposez les espaces de l’édifice de façon à ce qu’ils créent une suite qui commence avec l’entrée et la partie du bâtiment ouverte au public, puis conduit aux zones un peu plus privées pour finir avec les domaines les plus intimes.

Modèles-fils à consulter : ZONES COMMUNES AU CENTRE. HALL D’ENTRÉE pour les maisons ; UNE PIÈCE PROPRE À CHACUN pour les particuliers. UNE RÉCEPTION VOUS SOUHAITE LA BIENVENUE dans les bureaux avec, BUREAU SEMI-PRIVÉ à l’arrière.

Les modèles deviennent plutôt précis, ils n’imposent cependant jamais un style ou une forme déterminée au résultat. Par exemple, il existe un modèle qui s’appelle « ÉTAGÈRES OUVERTES ». Des placards profonds vous incitent à mettre les choses les unes derrière les autres, ainsi, vous ne pouvez plus voir ni attraper les objets qui sont au fond. Ils prennent aussi beaucoup de place. Les étagères dont la profondeur permet de ne mettre qu’un seul objet restent rangées et vous savez toujours, en un seul coup d’œil, où se trouve chaque chose. Les objets que vous utilisez fréquemment ne devraient pas être derrière une porte.

Vous pouvez ainsi entrevoir l’essence même des modèles de conceptions : de bonnes recettes éprouvées qui n’imposent pas de contraintes inutiles à votre implémentation

Les modèles ne demandent pas un style particulier ou des décorations superflues : le livre ne vous dit pas : « appliquez ces motifs floraux sur les rampes », mais plutôt : « les pièces d’une maison devraient être orientées de telle sorte que le soleil les éclaire harmonieusement, au moment de la journée où elles sont le plus utilisées — à l’est pour les chambres le matin, à l’ouest pour le salon l’après-midi ».

J’avais acquis un exemplaire de A Pattern Language peu avant de commencer à agrandir notre maison. Le livre fut une révélation : c’était le moyen d’aborder la conception de notre maison et nous pouvions alors la réaliser par nous-mêmes au lieu de payer très cher une solution inadaptée. Nous étions capables de faire un plan sommaire de notre maison et ensuite d’imaginer des détails plus fins au fur et à mesure de la construction. C’est le genre de livres qui, pendant que vous le lisez, parvient à confirmer les intuitions que vous éprouviez confusément — le genre de livres qui vous fait dire en permanence : « Bien sûr, c’est exactement à ça que je pensais  »

Design Patterns, le fameux livre publié par Gamma et autres, puise directement son inspiration dans les schémas architecturaux d’Alexander. Ils voulaient faire la même chose : dresser une liste de problèmes apparaissant fréquemment lorsque l’on programme et présenter de bonnes solutions qui n’imposeront pas de contraintes inutiles à votre implémentation.

Une chose dont j’ai pris conscience en lisant A Pattern Language, c’est une chose importante que l’on retrouve à la fois dans les modèles architecturaux et logiciels) : ils nous fournissent un vocabulaire pour discuter de la façon dont les objets sont construits. Il est beaucoup plus pratique de dire : « Les propriétés de cet objet ont des observateurs » plutôt que : « il est possible de lui attribuer des fonctions de rappel qui sont appelées lorsque ses propriétés changent ». Ce que je pensais être uniquement des termes pompeux ne sont, en fait, qu’une manière d’exprimer la connaissance de manière compacte.

La Qualité Sans Nom

La plus grande partie de l’explication d’Alexander sur les modèles de conception et leur philosophie se rapporte à quelque chose qu’il appelle « La qualité sans nom ». Vous connaissez des endroits qui ont cette qualité sans nom. Elle est présente dans le café où vous aimez aller lire car la lumière de l’après-midi entre avec exactement la bonne intensité. Et il y a là-bas des chaises et des tables, c’est toujours plus ou moins rempli de gens sans pour autant que vous vous sentiez oppressé. Elle est présente au coin d’un parc où un arbre ombrage un banc. Il y a peut-être un peu d’eau vive, et il importe peu qu’il pleuve ou bien que le temps soit ensoleillé, cela semble toujours être un plaisir d’y être. Pensez à une maison de hobbit où tout est à portée de main, où tout est confortable et où tout est fait élégamment.

Un objet ou un endroit possède la qualité sans nom s’il est convivial, s’il a évolué dans le temps selon sa logique propre, s’il ne recèle pas de contradiction interne, n’essaie pas d’attirer l’attention et semble réunir toutes les qualités archétypales — comme s’il avait suivi tout naturellement la voie optimale pour aboutir à sa conception. Plus important, Alexander affirme que c’est une qualité objective et non subjective, et qu’elle peut être mesurée et comparée. Bien que cela semble être une définition floue, c’est l’état le plus abouti dans lequel Alexander a pu l’amener lors de la première phase de son travail. La vraie révélation n’apparaitrait que plus tard.

En tant que développeurs, nous avons tous vu de beaux programmes à un moment donné. Ce sont peut-être les exemples de Programming Pearls, un beau livre que tout hacker devrait lire. Peut-être avez-vous vu un algorithme bien implémenté qui regorge de justesse. Vous vous souvenez peut-être d’un morceau de code très compact, très lisible, très fonctionnel et très correct. Ce logiciel possède la qualité sans nom. Il était devenu évident pour moi que je devais apprendre à écrire des logiciels qui atteignent le niveau de la qualité sans nom et que la méthode d’Alexander était le bon point de départ pour y parvenir.

(à suivre…)

(1) Refactorisation : bien que critiqué, cet anglicisme (voir http://fr.wikipedia.org/wiki/Refactorisation) semble d’un emploi courant chez les développeurs. On pourrait parler plus simplement de remaniement

Les lobbys ont toujours tenté d’influencer les politiques. Mais lorsqu’il s’agit de lobbyistes américains qui arrivent à faire passer mot pour mot certains textes de loi en Europe avec la complicité de nos députés, il y a d’autant plus de quoi s’interroger que cela va dans le sens des entreprises US et non du citoyen européen.

Un article traduit du chroniqueur anglais Glyn Moody, souvent traduit sur le Framablog)

Heureusement que nous avons désormais des sites qui permettent de mieux connaître le comportement individuel des députés et leurs éventuelles « sources d’inspiration ». Heureusement aussi que nous avons des structures comme la Quadrature du Net qui tente tant bien que mal d’agir et veiller au grain. Mais la vigilance reste de mise.

Protection des données dans l’Union Européenne : Les amendements proposés, écrits par des lobbyistes américains

EU Data Protection: Proposed Amendments Written by US Lobbyists

Glyn Moody – 11 février 2013 – ComputerWorld.uk
(Traduction : Fly, Alpha + anonymes)

Il devient évident que le lobby autour des directives européennes sur la protection des données est l’un des plus intenses lobbys jamais rencontrés, certains activistes ont déclaré que le phénomène était même pire que durant le projet de loi ACTA, alors que du côté des États-Unis, le bruit court qu’une guerre commerciale est sur le point d’être lancée si la loi est voté sous sa forme actuelle.

Etant donné la pression exercée pour affaiblir la protection de notre vie privée, une question-clé est : qui défend nos intérêts ?. La réponse évidente serait les députés européens, puisqu’il s’agit de nos représentants élus au Parlement Européen. Leur travail consiste précisément à nous représenter et dans ces circonstances particulières et à nous défendre. Et certains, tel le député européen Vert, Jan Albrecht, font probablement de leur mieux, comme j’ai pu l’écrire dans un billet précédent. Mais qu’en est-il du reste ? Que font-ils exactement ?

Dans le passé il était impossible de répondre à cette question, mais grâce aux miracles de la technologie moderne, et à l’avènement de l’ouverture des données qui permettent l’accès à toutes sortes d’informations. Il est désormais possible d’obtenir une vision claire de ce que font nos représentants européens.

Un nouveau site a été créé, il porte le nom plutôt lourd de LobbyPlag (NdT : Association des mots lobby et plagiat). Aussi disgracieux, que son nom puisse être, ce site ne décrit pas moins une vérité choquante : les députés européens proposent des amendements sur le projet de loi sur la protection des données qui reprennent mot pour mot les propositions des lobbyistes. En tout état de cause, ce qui est inquiétant ici n’est pas le plagiat, mais plutôt le fait que les mesures destinées à protéger les populations européennes soient supprimées ou altérées par les mêmes personnes que nous avons élues pour nous défendre.

Voici par exemple, un paragraphe important sur le fichage. On peut lire, sur la version originale :

Chaque personne physique (NdT : every natural person) doit avoir le droit de ne pas être soumis à une mesure entraînant des effets juridiques relatifs à cette personne physique particulière ou l’atteignant de manière significative, dès lors qu’elle se base uniquement sur un traitement automatisé ayant pour but l’analyse ou la prédiction de certains aspects personnels en lien avec cette personne physique, en particulier, l’efficacité au travail, la situation financière, la localisation, la santé, les préférences personnelles, la fiabilité, ou le comportement de cette personne physique.

Mais la Chambre de Commerce américaine, cette célèbre organisation européenne, n’aimait pas cette version et a souhaité la changer en :

Une personne concernée par la collecte des données (NdT : a data subject) ne doit pas faire l’objet d’une décision injuste ou discriminatoire uniquement basée sur le traitement automatisé ayant pour but l’évaluation de certains aspects personnels liés à cette personne.

Ce qui est sensiblement différent car on supprime ici un droit important.

Or quel texte a été proposé par des députés européens dans pas moins de trois commissions ? Le voici :

Une personne concernée par la collecte des données ne doit pas faire l’objet d’une décision injuste ou discriminatoire uniquement basée sur le traitement automatisé ayant pour but l’évaluation de certains aspects personnels liés à cette personne.

Ce qui correspond donc mot pour mot à la demande de la Chambre de Commerce américaine.

Voici un exemple explicite, issu d’une section extrêmement récente, rédigée par des députés européens, on peut y lire ce qui suit :

La personne responsable est supposée avoir accompli les obligations en exergue dans le paragraphe 1,lorsqu’il s’agit de choisir un organisme certifié de manière autonome ou ayant obtenu une certification, un sceau ou marqué comme étant conforme aux articles 38 ou 39 de ce Réglement, démontrant l’implémentation de normes techniques et de mesures organisationnelles appropriées en réponse aux exigences mises en exergue dans ce Règlement.

Ce qui rend la certification autonome quasiment suffisante pour les services de cloud computing. Alors, d’où vient ce texte sinon d’une modification précise suggérée par Amazon ?

La personne responsable est supposée avoir accompli les obligations en exergue dans le paragraphe 1,lorsqu’il s’agît de choisir un organisme certifié de manière autonome ou ayant obtenu une certification, un sceau ou marqué, démontrant l’implémentation de normes techniques et de mesures organisationnelles appropriées en réponse aux exigences mises en exergue dans ce Règlement.

Ce qui donc, par une autre extraordinaire coïncidence, est quasiment identique à ce que des députés européens ont choisi comme une très bonne idée.

LobbyPlag fournit une analyse intéressante sur le pourcentage d’amendements proposés avec du contenu repris des lobbyistes. Ci-dessous les chiffres pour les députés anglais calculés par le site :

• Giles Chichester (giles.chichester@europarl.europa.eu): amendements repris des lobbys : 10 sur 44 (22.73%)
• Malcolm Harbour (malcolm.harbour@europarl.europa.eu): amendements repris des lobbys : 14 sur 55 (25.45%)
• Sajjid Karim (sajjad.karim@europarl.europa.eu): amendements repris des lobbys : 13 sur 55 (23.64%)
• Emma McClarkin (emma.mcclarkin@europarl.europa.eu): amendements repris des lobbys : 1 sur 8 (12.50%)

Malheureusement, à l’heure actuelle, aucun de ces députés européens ne me représente donc je ne pourrais pas les contacter. Mais si l’un de vos députés apparaît, ils ont le devoir de vous répondre donc peut-être que vous devriez leur envoyer un courriel et leur demander pourquoi ils ont proposé ces amendements qui sont repris mot-à-mot ou presque d’entreprises américaines et de lobbyistes et que cela nuira à la population européenne tout en bénéficient à ces mêmes entreprises américaines.

Vous pourriez leur demander qui ils pensent représenter réellement : vous et 500 millions citoyens européens dont les impôts paient leurs salaire, qui s’élève actuellement à 80.000 £ par an (NdT : 93 000 € environ) ou alors, une poignée d’entreprises américaines ayant pour but de nous spolier notre vie privée pour pouvoir devenir encore plus riche ?

Si jamais vous recevez un réponse intéressante, merci de me l’envoyer à glyn.moody(AT)gmail.com que je puisse la partager avec mes lecteurs. Je suis certain que les explications seront passionnantes.

Crédit photo : European People’s Party (Creative Commons By)

Et si le navigateur disparaissait ?

Par Tristan Nitot, Mozilla Principal Evangelist

(Adaptation d’un article en anglais publié sur le blog officiel Mozilla, Beyond the Code, sous le titre What if the browser disappeared?. Sky, Slystone, goofy pour la traduction).

L’autre jour, je lisais un article provocateur intitulé The end of the browser? (NDT : « La fin du navigateur ? »). Cet article soutient fondamentalement que tout le monde utilisant de plus en plus d’appareils nomades, les applications mobiles remplacent les navigateurs Web pour diverses raisons, la principale étant qu’elles sont plus pratiques que les pages Web affichées dans les navigateurs.

Bien qu’en désaccord avec l’auteur, je pense qu’il s’agit d’une question très intéressante qui soulève deux problèmes :

1. Et si le Web était remplacé par les applications mobiles ? En quoi serait-il dommageable de perdre les navigateurs Web en tant que canal principal d’accès à l’information et aux services ?
2. Que pouvons-nous faire pour nous assurer que le navigateur Web ne devienne pas une relique du passé pendant que le monde devient mobile ?

Et si le Web était remplacé par les applications mobiles ?

— Je pense que le monde y perdrait énormément. Il y perdrait tellement que je ne sais même pas par où commencer…

Liberté d’expression

Le Web n’est pas seulement fait de contenu commercial. Avoir la possibilité de s’exprimer est fondamental. Le Web permet cela, et avoir une structure décentralisée sur laquelle publier des trucs est nécessaire. Les magasins d’applications centralisés, comme les Appstores, ont montré une certaine tendance à censurer agressivement les contenus pour éviter les litiges, qu’il s’agisse d’art, de politique, de liberté de la presse ou simplement de mauvais goût.

Liberté de façonner mon expérience

Les navigateurs Web modernes sont équipés d’un système d’extensions qui permet aux utilisateurs de personnaliser leur expérience. Mais même avant que Firefox ne rende les extensions si populaires, il était possible d’utiliser des feuilles de styles alternatives ou même les feuilles de style de l’utilisateur pour modifier la présentation du contenu d’un site. Il ne s’agit pas seulement des goûts et des couleurs, mais également de l’importance pour le contenu du Web d’être accessible aux personnes handicapées.

N’oublions pas que chaque plateforme majeure propose un navigateur Web, de Windows à MacOS en passant par GNU/Linux et tous les smartphones : les utilisateurs n’ont pas à acheter un matériel ou un logiciel spécifique pour accéder au Web. Tout ce dont ils ont besoin c’est un ordinateur qui puisse faire tourner un navigateur Web.

Liberté d’apprendre, de bricoler et de créer

Ce qui rend le Web différent des autres médias est la possibilité pour chacun de participer. Contrairement à la télévision, vous n’avez pas besoin de posséder une chaîne de télé pour partager votre point de vue avec un public. Tout le monde peut publier un billet de blog qui renvoie vers d’autres pages, partager des photos ou des vidéos, et c’est un progrès fantastique pour la démocratie, comparé aux temps de la télé, de la radio et des journaux.

Mais l’Internet et le Web ne sont pas seulement des médias. Ce sont des plateformes d’innovation. Comme tout le monde peut apprendre comment le Web fonctionne en regardant le code source, le Web permet à chacun de créer une application Web, ce qui conduit à plus d’innovations, provenant d’encore plus de gens.

Que pouvons-nous faire pour nous assurer que le navigateur Web ne devienne pas une relique du passé pendant que le monde devient mobile ?

La réponse à cette question est plus courte que la précédente, je vais vous présenter ce que fait Mozilla à ce sujet :

1. Continuer de faire un super navigateur pour le bureau : Firefox ;
2. Continuer de faire un super navigateur pour les mobiles : Firefox pour Android ;
3. Travailler sur un système d’exploitation mobile ouvert pour faire du Web la plateforme mobile de choix : Firefox OS (bientôt sur les téléphones portables près de chez vous !).

La nature ouverte du Web donne à chacun toutes sortes de libertés, et c’est pourquoi Mozilla s’investit dans Firefox OS : c’est le meilleur moyen de s’assurer que le Web a un futur dans un monde où la plupart des gens utilisent Internet sur leur téléphone portable.

Que pensez-vous que le monde perdrait si le navigateur Web disparaissait ? Vous pouvez nous le dire dans les commentaires là-dessous.

21/42 ! Tiens, nous voilà déjà à mi-chemin de la traduction d’Open Advice.

Deux ou trois articles petits ou grands chaque jeudi, traduits en un temps record par une bande de furieux, ceux qui sont là depuis le début et ceux qui débarquent et demandent s’ils peuvent participer, ceux qui travaillent d’arrache-clavier et ceux qui en profitent pour déconner échanger des propos sur le chat du pad, ceux qui choisissent un pseudo et ceux qui restent anonymous, ceux qui négligent tranquillement l’orthographe et les grammar nazis qui rectifient, ceux qui traduisent avec Google translate et ceux qui se battraient pour une majuscule à Libre… on rencontre tout un peuple là, et jusqu’à présent tout se passe dans l’enthousiasme et la bonne humeur, l’échange et l’entraide devant un passage un peu ardu sur lequel on s’amuse à chinoiser…

Mais cette fois-ci c’est l’auteur de l’article lui-même qui nous a fait le plaisir de nous rejoindre pour contribuer à la traduction, ce qui est tout de même assez confortable. Merci Guillaume !

Malgré nos relectures croisées, nul doute que des coquilles auront échappé à notre vigilance et que nous trouverons des lecteurs pour les signaler, ce qui nous est précieux car la révision avant l’édition du framabook en sera d’autant facilitée.

D’ici là, en avant pour la deuxième moitié : chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : Nyx, Sphinx, peupleLà, Kalupa, Guillaume Paumier, Husi10, lenod, Sky, Julius22, Alpha, RavageJo, KoS, Sputnik, goofy, lamessen

Apprenez de vos utilisateurs

Guillaume Paumier

Guillaume Paumier est photographe et physicien, il habite à Toulouse. Wikipédien depuis longtemps, il travaille actuellement pour la Wikimedia Foundation, l’organisation à but non lucratif qui héberge Wikipédia. En tant que responsable de l’ergonomie multimédia, il a notamment étudié le comportement des utilisateurs afin de créer un nouveau système d’import de fichiers pour Wikimedia Commons, la médiathèque libre associée à Wikipédia.

Vous connaissez Wikipédia, l’encyclopédie libre et gratuite que tout le monde peut modifier ? Elle a été créée en 2001 et a récemment fêté son dixième anniversaire. Bien qu’elle soit l’un des dix sites les plus visités au monde, son interface reste très « 1.0 » quand on la compare aux possibilités qu’offrent les technologies web modernes. Certains peuvent trouver ça bien : Wikipédia est un « truc sérieux » et les utilisateurs n’ont pas à être distraits par des « paillettes » dans l’interface. Pourtant, si Wikipédia a eu du mal à recruter de nouveaux contributeurs ces dernières années, c’est en partie à cause de son interface que certains considèrent comme archaïque. Ceci explique peut-être pourquoi les enquêtes sur les participants à Wikipédia ont montré à maintes reprises qu’il s’agit principalement d’une population d’hommes jeunes, attirés par la technologie, la plupart ayant une formation en informatique et en ingénierie. En dehors du fait que la connaissance libre et les licences libres sont issues du terreau fertile du logiciel libre et open source, l’interface compliquée a découragé beaucoup de contributeurs éventuels.

En 2011, alors que la majorité des plates-formes de publication collaboratives en ligne (comme WordPress, Etherpad et Google Documents) offrent un éditeur graphique, même rudimentaire, Wikipédia utilise toujours, par défaut, un ancien éditeur de texte wiki qui utilise des guillemets (“”) et des crochets ([[]]) pour la mise en forme. Des efforts sont en cours afin de passer à un éditeur graphique par défaut en 2012, mais ce n’est pas un défi facile à relever.

Mais laissons l’éditeur de côté un moment. L’interface de Wikipédia demeure assez compliquée. Et de nombreuses fonctionnalités utiles sont difficiles à découvrir. Savez-vous que Wikipédia possède un système de contrôle de versions intégré ? Et que vous pouvez voir toutes les anciennes versions d’une page ? Savez-vous que vous pouvez voir la liste de toutes les modifications effectuées par un contributeur ? Savez-vous que vous pouvez créer un lien vers une version donnée d’une page ? Savez-vous que vous pouvez exporter une page en PDF ? Savez-vous que vous pouvez créer un vrai livre personnalisé à partir du contenu de Wikipédia ? Et que vous pouvez le faire livrer chez vous ?

Le modèle d’implémentation

La plupart des lecteurs de Wikipédia y arrivent via des moteurs de recherche. Les statistiques montrent qu’ils passent peu de temps sur Wikipédia une fois qu’ils ont trouvé l’information qu’ils cherchaient. Un petit nombre seulement s’attarde et explore les outils que propose l’interface. Par exemple, on critique régulièrement Wikipédia sur sa qualité et sur sa fiabilité. Nombre de ces outils rarement explorés et presque cachés pourraient s’avérer bien utiles aux lecteurs pour les aider à vérifier la fiabilité de l’information, telles que les « pages de discussion » qui témoignent des discussions (passées et en cours) entre les différents contributeurs de chaque article ayant abouti à son contenu actuel.

Wikipédia et ses projets frères (tels que Wikisource et Wikimedia Commons) sont propulsés par le moteur de wiki MediaWiki — et sont soutenus par la Wikimedia Foundation ; rien que ces noms, dans leur confusion, sont un péché contre l’ergonomie. Pendant longtemps, le développement de MediaWiki a été conduit par des développeurs de logiciels. La communauté MediaWiki est forte de nombreux développeurs ; à vrai dire, la communauté est presque exclusivement composée de développeurs. Ce n’est que récemment que des designers ont rejoint la communauté, et ils ont été recrutés par la Wikimedia Foundation pour ce rôle. Il n’y a quasiment aucun designer bénévole dans la communauté. De ce fait, l’application a été construite et « maquettée » exclusivement par des développeurs. Par conséquent, la forme de l’interface a naturellement suivi de très près le « modèle d’implémentation », c’est-à-dire la manière dont le logiciel est implémenté dans le code et les structures de données. Le modèle d’implémentation ne correspond que rarement au « modèle utilisateur », c’est-à-dire à la manière dont l’utilisateur imagine que le logiciel fonctionne.

Il serait injuste de dire que les développeurs ne se soucient pas des utilisateurs. Quand on crée un logiciel, le but — outre le plaisir d’apprendre des choses, d’écrire du code et de résoudre des problèmes — c’est de le publier afin qu’il puisse être utilisé. Ceci est particulièrement vrai dans le monde du logiciel libre et open source, où la plupart des développeurs donnent bénévolement de leur temps et de leurs connaissances. On pourrait avancer que les développeurs sont, de fait, des utilisateurs de leurs propres produits, notamment dans le monde du logiciel libre et open source. Après tout, ils les ont créés ou ont rejoint leurs équipes pour une bonne raison, et c’est rarement l’argent. Par conséquent, les développeurs de ce type de logiciels devraient être dans une position idéale pour savoir ce que veulent leurs utilisateurs.

Mais soyons honnêtes : si vous êtes en train de lire ceci, c’est que vous n’êtes pas votre utilisateur lambda.

Le point de vue du développeur

Si vous êtes développeur, il vous est particulièrement difficile de vous mettre à la place de l’utilisateur. Tout d’abord, votre connaissance du code et de l’implémentation du logiciel vous force à observer ses fonctionnalités et son interface à travers un prisme très particulier. Vous connaissez chacune des fonctionnalités de l’application que vous avez créée. Vous savez où trouver chaque menu. Si quelque chose paraît légèrement bizarre dans l’interface, il est possible que vous l’ignoriez sans le vouloir, parce que vous savez inconsciemment que c’est lié à la façon dont la fonctionnalité est implémentée.

Imaginons que vous soyez en train de créer une application qui enregistre des données sous forme de tableau (par exemple, dans une base de données). Quand vous devrez ensuite afficher ces données pour les montrer à l’utilisateur, il est très probable que vous les représentiez comme un tableau, car c’est la façon dont vous avez implémenté leur stockage. Il vous paraîtra logique d’afficher les données dans un format qui est cohérent avec le format de stockage. Vous aurez probablement le même réflexe pour tout autre type de structure de données séquentielles : vous aurez tendance à l’afficher sous forme de séquence dans l’interface, peut-être comme une liste. Et pourtant, un autre format d’affichage aurait peut-être été plus pertinent et facile d’utilisation pour les utilisateurs, par exemple sous forme d’une série de phrases, d’un graphique ou d’une autre représentation visuelle.

Un autre défi est votre niveau d’expertise. Comme vous souhaitez que votre application soit extraordinaire, vous allez probablement vous documenter sur le sujet pour la concevoir. En fin de compte, vous n’allez pas seulement connaître votre application sur le bout des doigts, vous allez également devenir un expert dans le domaine lui-même. Un grand nombre de vos utilisateurs n’auront pas ce niveau d’expertise — ou n’en auront pas besoin. Ils pourraient être perdus par le niveau de détail de certaines fonctionnalités ou ne pas être familiers avec des termes inconnus des profanes.

Alors, que pouvez-vous faire pour arranger cela ?

Observez les utilisateurs. Vraiment

Observer les utilisateurs à l’œuvre avec votre application est une expérience réellement révélatrice.

Bon, pour observer comment les gens utilisent votre application, vous pouvez faire appel à une société de conseil en ergonomie ; cette société va alors recruter des volontaires avec des profils différents au sein d’un vivier de plusieurs milliers de testeurs, elle va mettre au point une grille d’entretien, louer une salle dédiée aux tests d’ergonomie qui comprendra un dispositif pour enregistrer ce qui se passe sur l’écran et une caméra pointée vers le testeur, et vous serez derrière une vitre sans tain, dans une salle d’observation, à vous taper la tête contre les murs et à jurer à chaque fois que l’utilisateur fait quelque chose qui, selon vous, n’a aucun sens. Si vous avez les moyens de le faire, alors n’hésitez pas, foncez. Ce que vous y apprendrez vous permettra de complètement changer votre point de vue. Si vous n’avez pas les moyens de recourir à une procédure de test professionnelle, tout n’est pas perdu ; vous allez juste devoir le faire par vous-même. Asseyez-vous derrière un utilisateur pendant qu’il vous montre comment il effectue ses tâches et les intègre à son mode de travail. Soyez un observateur silencieux : votre but est d’observer et de noter tout ce qui se passe. Beaucoup de choses vont vous surprendre. Une fois que l’utilisateur a terminé, vous pouvez relire vos notes et lui poser des questions afin de mieux comprendre comment il fonctionne.

Pour vous aider à conduire ces tests vous-même, il existe d’excellents ouvrages comme Don’t Make Me Think: A Common Sense Approach to Web Usability [NdT: Traduit en français : Je ne veux pas chercher: Optimisez la navigation de vos sites et menez vos internautes à bon port], écrit par Steve Krug, About Face 3: The Essentials of Interaction Design, d’Alan Cooper, Robert Reimann et David Cronin, et le projet OpenUsability. Être observé peut être un peu intimidant pour les utilisateurs, mais je parie qu’ils seront nombreux à se porter volontaires pour vous aider à améliorer votre application. Les utilisateurs qui ne peuvent pas contribuer au code sont généralement heureux de trouver d’autres façons de contribuer au logiciel libre : vous montrer comment ils utilisent le logiciel est une manière simple de le faire. Les utilisateurs sont reconnaissants du temps que vous avez donné pour développer le logiciel et veulent vous rendre la pareille.

Vous devrez garder un esprit critique et ne pas forcément accepter toutes les modifications demandées par vos utilisateurs. Écoutez attentivement leurs histoires : elles vous donneront l’occasion d’identifier des problèmes. Mais ce n’est pas parce qu’un utilisateur réclame une fonctionnalité qu’il en a absolument besoin ; peut-être que le meilleur moyen de résoudre le problème sous-jacent est de mettre en place une fonctionnalité complètement différente. Gardez du recul par rapport aux commentaires de vos utilisateurs. Mais cela, vous le saviez probablement déjà.

Et au passage, ne faites pas non plus appel à votre famille.

Je ne dis pas ça méchamment, je suis sûr que vos parents, frères et sœurs sont des gens très bien. Mais si vous créez une application comptable et que votre sœur n’a jamais tenu la moindre comptabilité, elle sera sans doute perdue. Vous perdrez plus de temps à lui expliquer ce qu’est la comptabilité en partie double qu’à tester votre logiciel. Par contre, votre mère, qui s’est acheté un appareil photo numérique l’année dernière, pourrait être un cobaye idéal si vous travaillez sur une application de gestion de photos numériques ou d’envoi sur un site de partage en ligne populaire. Pour votre application de comptabilité, il vaut mieux demander à l’un de vos collègues ou amis qui a déjà quelques notions de comptabilité.

Variez vos cobayes

Pour des raisons qui resteront éternellement mystérieuses, les gens trouveront toujours d’innombrables façons d’utiliser et de maltraiter votre application. Ils trouveront des manières de la casser que vous n’auriez même pas imaginées dans vos pires cauchemars. Certains mettront en place des processus et des méthodes de travail avec votre application qui n’ont absolument aucun sens à vos yeux. Et, de désespoir, vous vous cognerez la tête contre les murs. D’autres utiliseront votre application avec tellement d’intelligence que vous vous en sentirez idiot. Essayez de rencontrer des gens qui utilisent votre application avec des objectifs différents.

Les utilisateurs sont de drôles d’oiseaux. Mais ils sont de votre côté. Apprenez d’eux.

Si vous ne retenez rien d’autre…

… alors retenez ceci :

• Vous serez tenté de modeler l’apparence et le comportement de votre interface sur la façon dont le logiciel fonctionne en coulisses. Vos utilisateurs peuvent vous aider à éviter ce piège.
• Les utilisateurs sont des oiseaux capricieux. Ils vont casser, maltraiter et optimiser votre application à un point que vous ne pouvez pas même pas imaginer.
• Apprenez de vos utilisateurs. Améliorez votre application en fonction de ce que vous avez appris. Vous avez tout à y gagner.

Gabriella Coleman est une anthropologiste spécialisée dans la « culture hacker ». Elle a ainsi récemment publié le très remarqué livre Coding Freedom: The Ethics and Aesthetics of Hacking (PDF intégral Creative Commons By-Nc-Nd).

Elle nous livre ici le fruit de sa réflexion suite à la triste disparition d’Aaron Swartz.

Puisque le code devient pouvoir et que les geeks maîtrisent le code, on assiste en effet à l’émergence d’un nouveau mouvement…

Les geeks sont les nouveaux défenseurs des libertés publiques

Geeks are the New Guardians of Our Civil Liberties

Gabriella Coleman – 4 février 2013 – MIT Technology Review
(Traduction : Moosh, lamessen, heapoverflow, Sky, Pouhiou, KoS, monsieurab, Slystone, goofy, yazid, isinocin, axellemag1, zak, Penguin, Nodel, Vilrax + anonymes)

Les Geeks sont les nouveaux défenseurs des libertés publiques (NdT : « Civil Liberties », que l’on pourrait aussi traduire par libertés individuelles voire citoyenneté).

Des évènements récents ont mis en évidence le fait que les hackers, les développeurs et les geeks sont porteurs d’une culture politique dynamique.

Plus d’une décennie d’étude anthropologique dans leur milieu, a forgé ma conviction, que les hackers ont construit un très dynamique mouvement de défense des libertés individuelles et publiques. C’est une culture engagée à libérer l’information, sans contrôle excessif et sans surveillance par les gouvernements et les partenaires privés, à insister sur le droit au respect de la vie privée, et à combattre la censure, produisant un effet d’entraînement sans précédent pour la vie politique. Et 2012 a été à ce sujet une année faste.

Avant que je ne développe, il serait bon d’expliquer brièvement le mot « hacker ». C’est une source de débats, même parmi les hackers. Par exemple d’un point de vue technique : un hacker peut programmer, administrer un réseau, bidouiller, réparer et améliorer du matériel et du logiciel. D’un point de vue éthique et politique, cette diversité est tout aussi grande. Certains hackers font partie d’une tradition de la transgression et du non respect des lois ; leurs activités sont opaques et indétectables. D’autres hackers sont fiers d’écrire des logiciels open source, libres d’accès et transparents. Alors que certains restent loin de toute activité politique, un nombre croissant d’entre eux se lève pour défendre leur autonomie productive ; ou s’engage plus largement dans des luttes pour la justice sociale et les Droits de l’Homme.

Malgré leurs différences, certains sites web et certaines conférences rassemblent les divers clans de hackers. Comme tout mouvement politique, il y a des divergences internes mais, si les bonnes conditions sont réunies, des individus aux aptitudes distinctes travailleront à l’unisson pour une même cause.

Prenons par exemple la réaction à l’encontre de la loi Stop Online Piracy Act (SOPA), un projet de loi de grande envergure sur le droit d’auteur visant à réduire le piratage en ligne. SOPA a été stoppée avant qu’elle ne puisse être adoptée, et cela, grâce à une réaction massive et élaborée de la dissidence, menée par le mouvement des hackers.

L’élément central a été une journée de boycott dite « Blackout Day », sans précédent à l’échelle du web. Pour exprimer leur opposition à la loi, le 17 janvier 2012, des organisations à but non-lucratifs, quelques grandes entreprises du web, des groupes d’intérêts publics et des milliers d’individus ont décidé de rendre momentanément leurs sites inaccessibles ; des centaines d’autres citoyens ont appelé ou envoyé des courriels aux représentants politiques. Les journalistes ont par la suite beaucoup écrit sur le sujet. Moins d’une semaine plus tard, après ces évènements spectaculaires, le projet SOPA et le projet PIPA, son pendant au Sénat, ont été suspendus.

La victoire repose sur le soutien très large des hackers et des geeks. La participation de très grandes entreprises, comme Google, de personnalités reconnues du monde numérique, comme Jimmy Wales, et de l’organisation de défense des libertés individuelles Electronic Frontier Foundation (EFF) ont été cruciales au succès de l’action. Toutefois, la présence et le soutien constant et indéfectible des hackers et des geeks, fut palpable, y incluant bien sûr Anonymous. Depuis 2008 les activistes se sont ralliés sous cette bannière pour organiser des manifestations ciblées, faire connaître diverses malversations, organiser des fuites de données sensibles, s’engager dans l’action directe numérique et fournir une assistance technique pour les mouvements révolutionnaires.

Durant la protestation contre SOPA, les Anonymous ont publié des vidéos et des posters de propagande, tout en faisant régulièrement le point de la situation sur plusieurs comptes Twitter, dont Anonymous News, qui dispose d’un contingent important de followers. À la fin du blackout, les compagnies s’éloignèrent naturellement du feu des projecteurs, et se remirent au travail. La lutte pour les droits numériques continua, cependant, avec les Anonymous et les autres activistes.

En réalité , le jour suivant, le 18 janvier 2012, les autorités fédérales orchestrèrent le démantèlement du populaire site de partage de fichiers Megaupload. Kim Dotcom, le sympathique et controversé fondateur de la compagnie fut aussi arrêté dans un spectaculaire raid matinal en Nouvelle-Zélande. Le retrait de ce site populaire ne présageait rien de bon pour les Anonymous : il semblait confirmer que si les décrets tels que SOPA devenaient des lois, la censure deviendrait inévitable et commune sur Internet. Bien qu’aucune cour n’ait jugé Kim Dotcom coupable de « piratage », ses possessions sont toujours confisquées et son site web banni d’Internet.

Dès que la nouvelle fut connue, les Anonymous coordonnèrent leur plus grande campagne d’attaques par déni de service (DDOS) à ce jour. Elle mit à mal de nombreux sites web, incluant la page d’accueil d’Universal Music, le FBI, le bureau américain des copyrights (U.S Copyright Office), l’association américaine de l’industrie du disque (Recording Industry Association of America, RIAA) et l’association américaine du cinéma (Motion Picture Association of America, MPAA).

Quelques semaines plus tard, en Europe, les Anonymous firent encore parler d’eux, à l’occasion de mouvements de protestation massifs en ligne et hors-ligne contre ACTA, autre accord international sur le copyright, particulièrement au Danemark et en Pologne (voir Europeans Protest Anti-Piracy Treaty). Après que le gouvernement polonais fut d’avis de ratifier ACTA, les Anonymous mirent hors-service quelques-uns de ses sites officiels, et médiatisèrent les manifestations publiques à Cracovie notamment. Peu de temps après, les députés du parti polonais de gauche, le mouvement Palikot, siégèrent en portant le masque de Guy Fawkes, symbole des Anonymous, en signe de protestation contre ACTA. L’Union européenne a abandonné la proposition de loi en juillet 2012.

Anonymous s’est révélé être un acteur si important durant ces évènements que quelques temps après, j’ai reçu un coup de téléphone d’un investisseur en capital-risque impliqué dans l’organisation des protestations anti-SOPA. Il voulait savoir comment Anonymous opérait et si ses membres pouvaient être mis à contribution de façon plus directe. Ce qui est beau et frustrant à la fois dans le fonctionnement d’Anonymous est l’absence d’organisation et le caractère imprévisible des actions de ses membres. Comme ils aiment à le dire, « Nous ne sommes pas votre armée personnelle ». Mais son intuition qu’ils ont joué un rôle important dans cette histoire était bonne.

L’une des clés du succès de Anonymous réside dans sa nature participative, surtout quand on le compare au monde des hackers où agir demande des compétences techniques (et souvent une réputation). Des hackers doués sont en effet indispensables pour le réseau des Anonymous, ils mettent en place l’infrastructure de communication et décrochent la plupart des gros titres, par exemple quand ils s’introduisent dans des serveurs pour chercher des informations sur la corruption publique ou dans des entreprises. Mais le hacking n’en reste pas moins un outil parmi d’autres (et certains sous-groupes des Anonymous s’opposent au hacking et au défacement). Il y a d’autres choses à faire : des communiqués de presse percutants, des posters à dessiner, des vidéos à éditer. Les geeks et les hackers ont peut-être des compétences différentes, mais ils sont souvent compagnons de voyage sur internet, ils dévorent les mêmes journaux, ils suivent les mêmes cultures geek et ils défendent les libertés numériques même s’ils utilisent des méthodes et des organisations différentes.

L’importance, l’influence, et surtout la diversité de ce mouvement politique geek m’est apparu très récemment. Non pas à l’occasion d’un évènement politique officiel, mais au moment d’une commémoration doublée d’une réunion politique informelle. Plus d’un millier de personnes se sont rassemblées dans le majestueux Cooper Union Hall à New York pour honorer la mémoire d’Aaron Swartz, un hacker et activiste autoproclamé qui s’est suicidé récemment, en raison, selon certains, d’une ingérence du gouvernement dans son procès en rapport avec le téléchargement illégal de millions d’articles universitaires depuis le site de la bibliothèque du MIT (voir l’article « Why Aaron Swartz’s Ideas Matter »).

Ils parlèrent de la vie d’Aaron, de sa forte personnalité, et surtout de ses succès politiques et de ses désirs. Tout comme ses semblables, il détestait la censure, et avait donc naturellement rejoint le combat contre SOPA. Pendant la commémoration, on put entendre des extraits de son célèbre discours à la conférence Freedom to Connect en 2012, quand Swartz affirma que « SOPA a vraiment été stoppée par les gens eux-mêmes ». Il avait joué un rôle clé pour plusieurs raisons notamment en fondant l’association Demand Progress, une association à but non lucratif qui a participé à canaliser le mécontentement des citoyens à travers des pétitions et des campagnes contre SOPA.

Contrairement aux Anonymous qui n’ont pas de mission unique, d’adresse physique, ou de porte-parole officiel, Demand Progress est un organisme ayant un bureau de direction au cœur du pouvoir politique, à Washington. Néanmoins il canalise, de manière assez efficace, des initiatives de la base en faveur de la protection des libertés civiles, un groupe modéré qui peut coordonner des actions avec patience et précision.

De toute évidence, les geeks et les hackers en tout genre font usage d’une large variété de tactiques et de moyens d’expression politique. Demand Progress, ainsi que l’émergence du Parti Pirate en Europe, montrent la volonté des geeks et des hackers de s’exprimer et de travailler au sein des institutions en place. Tous les signes montrent qu’ils ont de plus en plus souvent recours à des modes d’expression politique plus traditionnels. Cependant cela va probablement coexister avec des actes plus ou moins organisés de désobéissance, de défi et de protestations qui sont également devenus plus fréquents et visibles ces dernières années, en grande partie grâce à Anonymous.

Mais en ce samedi après-midi, les différences ont été mises de côté au profit d’une posture unitaire, en commémoration, et avec la conviction que la bataille pour la préservation des libertés publiques individuelles n’en était qu’à ses débuts.

Crédit photo : Frédéric Bisson (Creative Commons By)