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.

Le célèbre (et libre) langage de programmation Python est en danger en Europe pour une sombre histoire de droit des marques.

Nous avons traduit ci-dessous l’appel à soutien de Van Lindberg, président de la Python Software Foundation.

La marque Python en péril en Europe : Nous avons besoin de votre aide !

Python trademark at risk in Europe: We need your help!

Van Lindberg - 14 février 2013 - Python Software Foundation
(Traduction : Moosh, lgodard, Alpha, QuébecTroll, jtanguy, Penguin, Uflex, ProgVal, goofy, maz, Nodel, Norore + anonymes)

Vous qui travaillez dans une entreprise qui a un bureau dans un pays membre de l’Union Européenne, nous avons besoin de votre aide.

Une entreprise au Royaume-Uni essaye de faire reconnaître le terme « Python » comme marque commerciale pour tout logiciel, service ou serveur, à peu près tout ce qui a quelque chose à voir avec un ordinateur. Plus précisément, c’est l’entreprise qui a acquis le domaine python.co.uk il y a treize ans. À cette époque, nous nous souciions peu des problèmes de marque et nous n’avions pas acquis ce domaine.

Ce n’était pas un problème jusqu’à présent car le domaine python.co.uk, la plupart du temps, se contentait de transférer son trafic vers les sociétés-mères, veber.co.uk et pobox.co.uk. Malheureusement, Veber a décidé qu’ils voulaient commencer à utiliser le nom « Python » pour leurs logiciels serveurs.

Nous avons contacté les propriétaires de python.co.uk à plusieurs reprises et essayé d’en discuter avec eux. Leur seule réponse a été de déposer une demande de marque communautaire réclamant les droits exclusifs d’utiliser le terme « Python » pour des logiciels, serveurs, et services web – et ce partout en Europe.

Nous avons fait appel à un conseiller juridique au Royaume Uni et nous, la Python Software Foundation (NdT :. la Fondation Python), opposons à cette demande une demande de dépôt de marque communautaire, mais notre propre demande n’est pas suffisamment mûre. Dans cette dernière, nous exposons les droits de propriété de la marque résultants de l’utilisation de “Python” au cours de ces 20 dernières années.

D’après notre avocat londonien, les meilleures preuves que nous puissions transmettre au bureau européen des marques déposées sont les lettres d’entreprises connues « utilisant le logiciel de marque PYTHON dans divers pays de l’Union Européenne » de telle sorte que nous puissions « obtenir des témoignages indépendants de leur part, prouvant l’origine de la signification de la marque PYTHON, en relation avec le logiciel et les produits/services associés ». Nous avons aussi besoin de preuves d’utilisation de Python à travers toute l’Union Européenne.

Que pouvez-vous faire ?

1- Vous travaillez pour une entreprise qui utilise Python ? Vous êtes basés en Europe, vous y embauchez ou vous y possédez un bureau ? Pourriez-vous écrire une lettre avec l’en-tête de votre entreprise que nous pourrions réutiliser par la suite ?

Nous aurions besoin des élements suivants :

1. Une brève description de l’utilisation de Python dans votre entreprise :
2. Comment votre entreprise associe le terme Python uniquement à la PSF ;
3. Votre opinion sur le fait qu’une autre entreprise utilisant le terme Python dans ses services, logiciels et serveurs pourrait âtre source de confusion.

La lettre n’a pas besoin d’être très longue —- quelques paragraphes suffisent, mais nous apprécierions toute forme de description de votre utilisation de Python dans vos logiciels, votre hébergement internet, vos serveurs, vos VPN, dans le développement de logiciel ou de matériel ou encore dans l’utilisation de services de sauvegarde. Pour ceux qui sont intéressés par les classes descriptives légales, elles figurent au bas de ce message^[1][2].

Vous pouvez envoyer une copie PDF de votre lettre à psf-trademarks@python.org

2. Connaissez-vous ou possédez-vous quoi que ce soit qui ait été publié au sein de l’UE et qui utilise “Python” pour faire référence au langage Python? Pouvez-vous nous transmettre des numérisations, photos ou copies? Cela comprend :

• Des livres ;
• Des brochures ;
• Des programmes de conférences ou présentations ;
• Des offres d’emploi ;
• Des magazines ou autres publications ;
• Des prospectus.

Vous pouvez envoyer un scan PDF de ces documents à psf-trademarks@python.org.

3. Vous pouvez également aider à protéger la propriété intellectuelle de Python en nous soutenant financièrement.

Comme le coût d’opposition d’une marque commerciale est de l’ordre de dizaines de milliers de dollars, nous aurons besoin de trouver un moyen de financer les coûts de procédure de l’opposition.

Merci d’envisager une donation à la Python Software Foundation ou de me contacter.

C’est la première fois que la PSF doit prendre des mesures juridiques pour protéger la propriété intellectuelle de Python. S’il vous plait, aidez Python comme vous le pouvez. La menace est réelle et elle est susceptible de nuire à votre entreprise en Europe, surtout si vous êtes dans le domaine de l’hébergement et que Python fait partie de l’offre que vous proposez.

S’il vous plaît, faites-moi savoir si vous avez des questions auxquelles je peux répondre. Si vous connaissez quelqu’un qui devrait avoir l’information, libre à vous de la partager.

Thanks, Merci,

Van Lindberg, Président
van@python.org
Python Software Foundation

« Googlelisez-moi, Googlelisez-moi. Oui, mais pas tout de suite, pas trop vite. Sachez me convoiter, me désirer, me captiver. » (Juliette Gréco)

Sources :

• L’accord Google-presse ou l’arnaque intellectuelle du Gouvernement (Numerama)
• Aurélie Filippetti rappelle à Google ses obligations fiscales (Numerama)
• Qwant : un concurrent de Google « made in France » (Numerama)

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