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

Traduction Framablog : Sphinx, purplepsycho, Cyrille L., lamessen

Ce que je suis contente de ne pas avoir su

Alexandra Leisse

Alexendra Leisse a quitté une scène pour en rejoindre une autre. Elle a transformé son autre passion (les logiciels et le Web) en un métier. Après une période de transition de douze mois en freelance dans le logiciel et l’opéra — et noyée par de nombreuses heures d’activités dédiées à KDE, elle a rejoint Nokia et le développement de la plateforme Qt en tant que gestionnaire de la communauté Web. C’est la femme derrière le réseau de développement Qt et les activités de sa communauté sur la toile. Bien qu’elle soit diplômée en art lyrique, elle refuse la plupart du temps de chanter en public.

Introduction

Quand Lydia m’a demandé de rejoindre son projet de livre sous-titré « les choses que j’aurais voulu savoir », mon esprit est resté vide. Les choses que j’aurais voulu savoir mais que je ne savais pas ? Rien ne me venait à l’esprit.

Je ne dis pas que je n’aie pas eu besoin de savoir quoi que ce soit, au contraire. J’ai eu beaucoup à apprendre et j’ai fait un nombre incalculable d’erreurs. Mais les situations ou les erreurs que j’aurais voulu éviter ? Je n’arrive pas à y penser.

Nous avons tous cette fâcheuse tendance à regarder les choses que nous pourrions mieux faire, les choses que nous ne savons pas, et nous les voyons comme des faiblesses. Mais que dire des faiblesses qui sont des atouts ?

Voici ma propre histoire sur l’ignorance, la naïveté, les mauvaises impressions et comme je suis heureuse de ne pas en avoir eu la moindre idée.

Les noms

Je n’avais aucune idée de qui était ce gars que j’avais rencontré lors de mon premier jour de travail. Il est entré dans la pièce, s’est présenté et a commencé à poser des questions me donnant l’impression que tout ce que je penserais serait insensé. Il était apparemment bien renseigné sur ce que je faisais sur KDE et les personnes que je côtoyais. Cependant, nos points de vue sur le sujet semblaient différents. À un moment, ses provocations ont fini par me fatiguer et j’ai perdu patience. Je lui ai alors dit qu’avec les personnes, ce n’était pas toujours aussi facile que les ingénieurs l’imaginent.

Juste après son départ après une heure de discussion, j’ai cherché son nom sur Google : Matthias Ettrich. Ce que j’ai lu m’a expliqué pourquoi il avait posé ces questions. Si j’avais su avant qu’il était un des fondateurs du projet KDE, j’aurais débattu avec lui d’une manière bien différente, voire pas du tout.

Ces dernières années, j’ai dû chercher quelques noms et à chaque fois, j’ai été heureuse de le faire après le premier contact.

C’est probablement mon idée la plus importante. Lorsque j’ai rencontré toutes ces personnalités du Libre et de l’open source pour la première fois, je n’avais jamais entendu leurs noms auparavant. Je ne savais rien de leurs histoires, mérites ou échecs. J’ai approché tout le monde de la même façon : le contact visuel. En étant ignorante (ou naïve selon certains), je ne me sentais pas inférieure par rapport aux personnes que je rencontrais lorsque j’ai commencé mon aventure au sein du Libre et de l’open source. Je savais que j’avais beaucoup à apprendre mais je n’ai jamais eu l’impression d’avoir un rang inférieur aux autres en tant qu’individu.

« Projet de grande envergure »

Je n’avais pas suivi religieusement dot.kde.org ni PlanetKDE et encore moins ces innombrables publications liées au Libre et à l’open source, avant de commencer à m’intéresser à ce qui se passait sur les listes de diffusion KDE. Je voyais ces canaux avant tout comme moyen de communiquer avec un public choisi, principalement des utilisateurs et des contributeurs du projet en tant que tel.

Pendant un certain temps, je n’avais pas conscience que les articles que je publiais sur The Dot pourraient être repris par des journalistes. Je m’appliquais à les écrire parce que je voulais faire du bon boulot et non pas parce que j’avais peur de passer pour folle auprès du reste du monde. La liste de presse était maintenue par d’autres personnes et ce que j’écrivais ne me paraissait pas important non plus. Je voulais toucher certaines personnes. Pour cela les canaux officiels et mon propre blog me semblaient être les moyens les plus efficaces.

Être citée sur ReadWriteWeb après avoir annoncé sur mon blog que je commencerai un nouveau boulot fut un choc pour moi. Non pas parce que j’ignorais que des gens lisaient ce que j’écrivais (j’espérais bien qu’ils le lisent !) mais je ne m’attendais pas à ce que ça soit un sujet d’une telle importance. Ce n’était même pas pendant les vacances d’été. Encore heureux que personne ne me l’ait dit, je n’aurais pas été capable de publier ne serait-ce qu’une seule ligne.

L’œil étranger

Il y a quelque temps, quand j’ai assisté à ma première conférence, j’avais la ferme conviction que j’étais différente des autres participants. je me voyais comme une étrangère parce que je n’avais pas grand-chose en commun avec qui que ce soit à part un vague intérêt pour la technologie : je travaillais en freelance depuis quelques années déjà, après mon diplôme universitaire ; je n’avais aucune éducation pertinente dans le domaine, et j’étais mère d’un enfant de 10 ans. Sur le papier en tout cas, il ne pouvait pas y avoir plus éloignée des suspects habituels qu’on rencontre dans les projets FOSS.

En 2008 j’ai assisté à un sprint (NdT : phase de développement, généralement perçue comme intense, aboutissant à un produit fonctionnel) KOffice au sein de l’équipe promotion et marketing de KDE pour préparer la sortie de la version 2.0. L’idée initiale était d’esquisser une série d’activités promotionnelles autour de cette sortie afin de développer à la fois le support développeur et utilisateur. Pour celui-ci, nous étions trois à suivre un chemin parallèle à celui concernant les développeurs.

Nous avons essayé de comprendre comment nous pourrions positionner KOffice et adapter la communication au public ciblé. Très tôt dans le processus, nous avons découvert que nous devions faire marche arrière : à ce stade, le manque de maturité de la suite rendait impossible son positionnement comme option pour les utilisateurs non avertis. Nous devions nous en tenir aux développeurs et aux précurseurs. C’était difficile à vendre à certains développeurs, mais en tant qu’étrangers nous avions la chance de regarder le logiciel sans penser à tout le sang, la sueur et les larmes versés dans le code.

Pour beaucoup de projets, de n’importe quelle sorte, jeter un œil objectif à la situation donne du fil à retordre aux contributeurs principaux. Nous avons tendance à ne pas voir les grands succès quand nous sommes très concentrés sur des problèmes de détails et réciproquement. Parfois, nous manquons une occasion parce que nous pensons que ça n’a rien à voir avec ce que nous faisons (ou, pour commencer, parce que personne ne voudrait que ça ait quelque chose à voir).

Dans tous ces cas, les contributeurs extérieurs au projet ont le potentiel pour apporter des points de vue différents à la discussion, particulièrement quand il s’agit de déterminer un ordre de priorité. C’est encore plus utile quand ce ne sont pas des développeurs : ils poseront différentes questions, sans ressentir de pression face à la connaissance et à la compréhension de tous les détails techniques ; ils peuvent aussi aider pour les décisions ou la communication sur un plan moins technique.

Conclusion

L’ignorance est une bénédiction. Ce n’est pas seulement vrai pour les individus qui profitent de l’insouciance qui en résulte mais aussi pour les projets que ces individus rejoignent. Ils apportent différents points de vues et expériences.

Et maintenant, filez et trouvez vous-même un projet qui vous intéresse, indépendamment de ce que vous pensez savoir.

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

Traduction Framalang : Lycoris, grosfar, merlin8282, Sky, Julius22, _noskill, Nyx, lenod, KoS, lerouge, alexb, Ex0artefact, name?, SaSha_01, peupleLà, lamessen

Prendre de la distance pour atteindre l’excellence

Jono Bacon

Jono Bacon est gestionnaire de communauté, directeur technique, consultant et auteur. Il travaille actuellement comme gestionnaire de la communauté Ubuntu chez Canonical. Il dirige une équipe afin de faire croître, de stimuler et d’enthousiasmer l’ensemble de la communauté Ubuntu. Il est l’auteur d’Art of Community, le fondateur du Community Leadership Summit et le cofondateur du populaire podcast LugRadio.

Jono Bacon au tableau blanc

La première fois que j’ai entendu parler de Linux et d’open source remonte à 1998. La technologie était alors horriblement compliquée et il fallait fournir de gros efforts pour obtenir un système qui tourne correctement ; pourtant, le concept d’une communauté collaborative globale me subjugua. À l’époque, je ne possédais aucune connaissance, mes compétences techniques étaient limitées et j’avais des boutons.

J’étais un adolescent typique : tourmenté, cheveux longs, T-shirt Iron Maiden. Mon chemin était déjà tout tracé, au sens le plus traditionnel ; j’irais à l’école, puis au lycée, puis à l’université, puis je trouverais un travail.

Quatorze ans plus tard, le chemin que j’ai finalement suivi n’a rien de conventionnel. Cette fascination personnelle envers le communautaire m’a conduit partout dans le monde et m’a lancé des défis captivants. C’est intéressant de prendre du recul et d’analyser cette période. Enfin, ça pourrait être intéressant pour moi… Vous préférerez peut-être passer au chapitre suivant…

… Toujours avec moi ? OK, allons-y.

La science contre l’art

J’ai toujours cru que la gestion d’une communauté était moins une science qu’un art. Je définis la science comme l’exploration de méthodes permettant de reproduire des phénomènes à travers des étapes établies et clairement comprises. Dans le monde de la science, si vous connaissez la théorie et la recette pour un résultat donné, vous pouvez souvent reproduire ce résultat comme tout un chacun.

L’art est différent. Il n’y a pas de recette pour produire une chanson populaire, pour créer une peinture exceptionnelle ou pour sculpter une statue magnifique. De même, il n’y a pas vraiment d’ensemble d’étapes reproductibles pour créer une communauté prospère. Bien sûr, il y a des astuces et des techniques pour parvenir à réunir certaines composantes du succès, mais c’est la même chose pour les autres formes d’art : nous pouvons tous apprendre les notes et les accords d’une guitare, mais cela ne veut pas dire que nous allons écrire la prochaine Bohemian Rhapsody. La formule qui donne naissance à un titre comme Bohemian Rhapsody, c’est une dose de compétence acquise et une dose de magie.

Je ne suggère cependant pas que la gestion de communauté soit une forme d’art désespérément branchée et introvertie que seuls quelques bienheureux élus très talentueux peuvent accomplir. Ce dont je me plains est qu’il n’y ait pas de manuel sur la façon de créer une communauté magnifique et enthousiasmante ; il s’agit toujours d’une dose d’apprentissage et d’une dose de magie mais la part de magie ne vous sera pas insufflée par la grâce des dieux ; il vous faudra plutôt la chercher en essayant de nouvelles voies, en restant à l’écoute des retours et en évaluant ce qui fonctionne et ce qui ne fonctionne pas.

C’est plutôt frustrant car cela veut dire que cette « magie » ne s’obtient pas en suivant une recette unique. Mais il reste la possibilité de partager les compétences acquises, comme j’ai cherché à le faire avec The Art of Community 1 et la conférence annuelle Community Leadership Summit 2.  

Avant de commencer mon introspection, et pour ceux que ma carrière n’ennuie pas mortellement, je vais résumer rapidement les communautés avec lesquelles j’ai travaillé afin de poser le contexte. En bref, j’ai commencé dans mes jeunes années chevelues par la création de l’un des premiers sites web communautaires britanniques sur Linux, appellé Linux UK, et j’ai intégré la communauté des Groupes d’utilisateurs de Linux (Gul). Je me suis ensuite lancé dans la création de mon propre Gul à Wolverhampton, au Royaume-Uni, et j’ai fondé le projet Infopoint pour encourager les Gul à prêcher Linux sur les salons informatiques du Royaume-Uni. J’ai ensuite poursuivi en contribuant à la communauté KDE et en fondant le site KDE::Enterprise ; j’ai établi le KDE Usability Study et contribué de-ci, de-là à diverses petites applications. J’ai ensuite fondé le groupe d’utilisateurs PHP des West Midlands. J’ai aussi commencé à m’intéresser à GNOME. J’ai développé quelques applications (GNOME iRiver, XAMPP Control panel, Lernid, Acire) et également participé à la conception et un peu au code d’une nouvelle application audio simplifiée appelée Jokosher. C’est à peu près à cette époque que j’ai co-fondé le podcast LugRadio qui fonctionna pendant quatre ans avec plus de deux millions de téléchargements, ce qui a entraîné la mise en place de cinq événements en direct au Royaume-Uni et aux États-Unis. À cette époque, j’ai également commencé à travailler comme consultant open source pour l’initiative publique OpenAdvantage. Là, j’ai vraiment eu l’occasion de me faire les dents sur le communautaire en aidant des organisations à travers tout les West Midlands à passer à l’open source. Après quelques années passées chez OpenAdvantage, je suis parti rejoindre Canonical comme gestionnaire de la communauté Ubuntu où j’ai mis en place une équipe de quatre personnes. Ensemble, nous nous investissons dans des projets très variés chez Ubuntu et Canonical. Vous êtes toujours là ?

Ouah, vous êtes tenace. Ou assommé d’ennui. Probablement assommé. Il y aura interro à la fin, ça vous apprendra…

Réfléchir

Ceci m’amène donc à l’objet de cet article : la curieuse question de savoir ce que je me dirais si je savais ce que je sais aujourd’hui. À ce jour, je pense que ce que j’ai appris au cours de ma carrière peut se diviser en deux grosses catégories :

Pratique — les trucs et astuces du métier, par exemple, les différentes approches des moyens de communication, les différentes façons d’utiliser la technologie, la gestion du temps, les différentes approches de la gestion de projet, etc.

Personnel — les leçons de vie et apprentissages qui modifient l’approche que nous avons de notre monde.

Je ne vais pas m’étendre sur la catégorie pratique — vous devriez lire mon livre si vous souhaitez en savoir plus sur ce sujet (le livre couvre aussi l’aspect personnel). Aujourd’hui, je vais plutôt m’intéresser aux leçons de vie. Les approches et les pratiques changeront toujours, mais les leçons que l’on en tire ne changent pas tant que ça : elles évoluent plutôt au fur et à mesure que votre sagesse grandit.

L’importance des convictions

Les communautés sont fondamentalement des réseaux de personnes poussées par leurs convictions. Chaque communauté possède son propre état d’esprit et un domaine d’expertise propre. Cela peut être une idée aussi grandiose que de rassembler l’intégralité des savoirs de l’humanité, changer la face du monde avec le logiciel libre ou, plus simplement, animer un « club » pour que les gens puissent échanger autour de leurs livres préférés. Que ce soit pour changer le monde ou simplement pour s’amuser, chaque communauté fait valoir son propre système de valeurs ; l’humble club de lecture accorde beaucoup de valeur au fait de fournir un environnement amusant, sécurisé et libre afin de pouvoir partager des avis et des conseils de lecture. Cela ne change pas le monde, mais cela reste toujours une bonne chose à laquelle n’importe qui peut se rallier.

La règle, souvent tacite, d’une communauté est que chaque contribution d’un membre de la communauté doit bénéficier à l’ensemble de celle-ci. C’est pourquoi il est amusant d’écrire un correctif pour un bogue d’un logiciel libre, de contribuer à la documentation ou d’organiser un événement gratuit. Mais il est rare que quiconque veuille contribuer de façon bénévole si sa contribution ne bénéficie qu’à une seule personne ou entreprise.

Bien sûr, je suis certain que vous tous, enfoirés cyniques que vous êtes, allez chercher et trouver une exception. Mais souvenez-vous que cette décision est profondément personnelle : les membres de la communauté décident par eux-mêmes si leur contribution doit bénéficier à tous. Par exemple, certains vont arguer que n’importe quelle contribution à Mono va seulement bénéficier à Microsoft et à l’ubiquité de leur infrastructure .NET. Mais des centaines de contributeurs participent à Mono parce qu’ils ne le voient pas de cette manière : ils voient leurs contributions comme un moyen utile et amusant de permettre aux développeurs d’écrire des logiciels libres plus facilement.

Si je devais parler au Jono de 1998, j’insisterais sur l’importance de cette conviction. J’avais alors une intuition à ce propos, mais je ne compte plus les exemples qui m’ont prouvé depuis que cette conviction incite réellement les gens à participer. J’ai souvent parlé de l’histoire du gamin d’Afrique qui m’a envoyé un courriel pour me dire qu’il devait marcher trois heures aller-retour jusqu’au cybercafé le plus proche pour contribuer à Ubuntu. Il le faisait car il était convaincu par notre mission d’apporter le logiciel libre aux masses. On pourrait aussi citer l’énorme croissance de Wikipédia, l’incroyable réunion de la communauté GNOME autour de GNOME 3, le succès d’OpenStreetMap et bien d’autres exemples.

Ceci dit, la conviction n’est pas juste un artifice pour les relations publiques. Il faut qu’elle soit réelle. Bien que nous ayons tous des convictions différentes — certains ont des convictions sur le logiciel, sur l’éducation, sur le savoir, sur la transparence ou sur n’importe quoi d’autre — vous ne pouvez pas fabriquer un système de convictions à moins qu’il n’ait un but valide, auquel un groupe puisse s’intéresser. Certes, il peut être obscur, mais il doit être réel. Avec le succès du mouvement open source, nous avons vu des exemples d’entreprises qui tentaient de jouer cette approche et ce registre sémantique autour de la conviction, mais dans le but de servir leurs propres besoins. Je pourrais essayer de vous faire adhérer à cette idée : « Travaillons tous ensemble pour aider Jono à devenir riche » et fabriquer de toutes pièces quelques sophismes pour justifier de cette acte de foi (par exemple, si j’étais riche, je pourrais me concentrer sur d’autres travaux, au bénéfice d’autres communautés ; mes enfants seraient élevés et éduqués dans de bien meilleures conditions, ce qui profiterait à tout le monde), mais ce serait n’importe quoi.

En tant que telle, la conviction est un puissant moteur pour la contribution comme pour la collaboration, mais il est important de l’utiliser de manière équilibrée et de l’associer au respect. Alors qu’elle peut déclencher d’incroyables changements, elle peut être terriblement dévastatrice (comme c’est le cas avec certains prédicateurs à la TV qui utilisent la religion comme un moyen de vous soustraire de l’argent, ou encore les faux médiums qui utilisent la lecture à froid et s’accrochent à votre besoin désespéré de croire que vous pouvez à nouveau vous connecter à un être cher disparu).

Votre rôle

Aujourd’hui, les gestionnaires de communauté ont un rôle intéressant. Par le passé, j’avais parlé de deux types de gestionnaires de communauté ; ceux qui sortent, font des conférences et s’agitent en parlant d’un produit ou d’un service et ceux qui travaillent avec une communauté de volontaires pour les aider à connaître une expérience collaborative, productive et amusante. Le second type m’intéresse plus — je pense que c’est ce que fait un vrai gestionnaire de communauté. Le premier de ces positionnements est tout à fait sympa et respectable mais cela convient mieux dans le domaine de la promotion et des relations publiques et cela nécessite d’autres compétences. J’ai quelques conseils que je pense être assez intéressants pour être partagés.

La première et probablement la plus importante des leçons est d’accepter que vous pouvez et allez parfois avoir tort. Jusqu’ici, dans ma carrière, j’ai fait certaines choses correctement et j’ai commis des erreurs. Bien que je croie être généralement sur le bon chemin et que l’essentiel de mon travail soit couronné de succès, il y a eu quelques flops ici ou là. Ces loupés, accidents et faux pas n’ont jamais été dus à de la malveillance ou de la négligence ; ils ont plutôt été causés par une sous-estimation de la difficulté de mon objectif.

Ça a l’air assez évident, mais ça l’est moins quand vous avez une fonction relativement publique. En gros, les gestionnaires de communautés sont souvents vus comme les représentants d’une communauté donnée. Par exemple, je sais qu’à titre personnel, on me considère comme l’une des figures publiques d’Ubuntu et cette responsabilité, s’accompagne d’une certaine pression publique quant à la manière dont les gens vous perçoivent.

Avoir les projecteurs braqués sur soi en se retrouvant à la tête d’une communauté déclenche chez certains un mécanisme défensif. Ils reculent à l’idée de faire des erreurs en public, comme si les masses dans leurs bavardages s’attendaient à une prestation parfaite. C’est dangereux, et on a déjà vu, par le passé, des personnages publics qui ne reconnaissent jamais avoir fait une erreur par crainte d’être ridicules en public. Non seulement, c’est une idée fausse (nous faisons tous des erreurs), mais cela ne donne pas non plus à la communauté un bon exemple de chef de file honnête et transparent tant dans les choses qu’ils font bien que dans celles qu’ils font moins bien. Il est important de se rappeler que nous gagnons souvent le respect d’autrui par leur acceptation de nos erreurs : c’est la caractéristique d’un individu honnête et accompli.

Je me rappelle mes débuts en tant que responsable chez Canonical. À l’époque, Colin Watson et Scott James Remnant, deux vieux briscards des tous débuts de Canonical et d’Ubuntu, faisaient aussi partie des responsables de l’équipe d’ingénierie d’Ubuntu. Nous avions des réunions hebdomadaires avec notre directeur technique, Matt Zimmerman, et j’y entendais régulièrement Colin et Scott avouer ouvertement qu’ils étaient mauvais dans ceci ou avaient fait une erreur dans cela ; ils étaient étonnamment humbles et acceptaient leurs forces et leurs faiblesses. En tant que responsable débutant, je l’ouvrais moins souvent, mais cela m’a appris que ce genre d’ouverture d’esprit et d’honnêteté est important non seulement en tant que responsable, mais en tant que leader d’une communauté. Depuis, je n’hésite plus à admettre publiquement mes erreurs ou à m’excuser si je foire quelque chose.

Écouter

De même qu’être ouvert aux erreurs est primordial, il est tout aussi important d’être à l’écoute et d’apprendre de ses pairs. Dans de nombreux cas, nos communautés perçoivent les responsables et les leaders de communauté comme des personnes qui devraient toujours fournir des orientations et des directions, mener activement le projet et réaliser ses objectifs. C’est sans aucun doute une responsabilité. Mais tout autant qu’être la voix qui montre la voie, il est important de prêter l’oreille pour écouter, guider quand c’est opportun et apprendre de nouvelles leçons et idées.

Les membres de nos communautés ne sont pas juste des mécaniques froides et insensibles qui font leur travail. Ce sont des humains qui vivent, respirent, ont des opinions, des sentiments et des idées. J’ai vu de nombreux exemples — et j’en ai déjà moi-même provoqué —, de ces situations où quelqu’un est tellement habitué à donner des instructions et des conseils qu’il oublie parfois de simplement s’asseoir, écouter et apprendre de l’expérience de quelqu’un d’autre. Toute industrie possède ses maîtres-à-penser et ses experts… des gens célèbres et reconnus pour leur sagesse. Mais, d’après mon expérience, certaines des leçons de vie les plus révolutionnaires que j’ai apprises sont venues de membres tout à fait anonymes, ordinaires. Savoir écouter les gens n’est pas seulement important pour nous aider à apprendre et à nous améliorer dans ce que nous faisons, c’est également essentiel pour gagner le respect et avoir de bonnes relations avec sa communauté.

Temps de travail contre temps libre

Pendant que je parle de la façon dont nous collaborons avec notre communité, il y a un autre résultat de mon expérience que je n’ai vraiment assimilé qu’assez récemment. Comme beaucoup de gens, de nombreux centres d’intérêts remplissent mes journées. À part être marié et essayer d’être le meilleur mari possible, et à part mon travail quotidien en tant que gestionnaire de la communauté d’Ubuntu, je participe aussi à des projets tels que Severed Fifth, le Community Leadership Summit et quelques autres choses. Comme on pourrait s’y attendre, je consacre mes journées à mon travail rémunéré : au boulot, je ne passe pas de temps à travailler sur ces autres projets. Et, comme on pourrait s’y attendre, lorsque ma journée de travail se termine, je me mets à travailler sur ces autres projets. La leçon qu’il faut retenir ici, c’est qu’il n’est pas toujours clair pour votre communauté de savoir où tracer les limites.

Au fil des années, j’ai développé toute une série de services en ligne que j’utilise tant dans mon travail qu’à titre personnel. Mes comptes Twitter, identi.ca et Facebook, mon blog et d’autres ressources sont les endroits où je parle de ce que je fais. Le problème est que si l’on tient compte de leur caractère public, du fait que je suis un représentant officiel du projet Ubuntu et de tous les fuseaux horaires autour du globe, même Einstein aurait du mal à faire la différence entre ce que j’écris en tant que Jono et ce que j’écris pour le compte de Canonical.

Ce qui a pu causer de la confusion. Par exemple, malgré mes clarifications répétées, OpenRespect n’est pas et n’a jamais été une initiative de Canonical. Bien sûr, quelques idiots ont choisi d’ignorer mes explications à ce sujet mais je comprends néanmoins comment la confusion a pu arriver. La même chose s’est produite pour d’autres projets tels que Severed Fifth, The Art of Community et le Community Leadership Summit, qui ne font pas et n’ont jamais fait partie de mon travail chez Canonical.

C’est une leçon pour moi car j’ai moi-même partagé un moment, cette vision des choses et disais : « Évidemment que c’est activité de loisirs, j’ai posté ça à 20 h. » tout en haussant les épaules à propos de la confusion entre travail et projets personnels. Quand votre travail vous met dans une position relativement publique, vous ne pouvez pas vous offrir le luxe de voir les choses comme ça. Au contraire, vous devez considérer que les gens vont avoir tendance à faire la confusion et que vous allez devoir travailler plus dur pour bien clarifier les choses.

Ne voyagez pas trop

À propos du travail pour une société qui vous a recruté pour être à la tête d’une communauté, vous devriez toujours avoir conscience des risques comme des bénéfices des voyages. C’est une chose que j’ai apprise assez tôt dans ma carrière chez Canonical. Je voyais toujours les mêmes têtes dans les conférences, et il était évident que ces personnes avaient très bien communiqué sur les bénéfices des voyages auprès de leurs employeurs, tout comme je l’avais fait, sauf que j’en ai aussi appris les dangers.

Je voyageais et ce n’était pas seulement un travail fatigant et épuisant psychologiquement, mais j’étais aussi plus loin de mes courriels, moins présent sur IRC, j’étais dans l’impossibilité d’assister à de nombreuses réunions et j’avais moins de temps à consacrer à mes engagements professionnels. Ainsi, mon rôle était principalement devenu de sortir et d’aller assister à des événements et, même si c’était amusant, cela ne rendait pas autant service à ma communauté qu’il l’aurait fallu. Aussi ai-je drastiquement réduit mes déplacements — pour tout dire, je suis allé au Linux Collab Summit il y a quelques jours, et hormis quelques événements d’Ubuntu auxquels je devais assister, je n’ai assisté à aucune conférence depuis près d’un an. J’ai l’impression à présent d’être allé un peu trop loin dans l’autre direction. Tout est donc une question d’équilibre. Mais j’ai aussi le sentiment de mieux servir ma communauté quand je peux prendre le temps d’être au bureau et d’être en ligne et disponible.

La planification

Pour certains, être à la tête d’une communauté, ou simplement l’animer, est un rôle qui tient moins de la structure pré-établie que du fait d’être réactif. À mes débuts, c’est également ce que je pensais. Bien qu’il n’y ait absolument aucun doute sur la nécessité de se montrer réactif et de pouvoir répondre aux choses qui se présentent, il est également essentiel de planifier suffisamment son travail sur une période donnée.

Cette planification devrait être effectuée de manière ouverte quand c’est possible et remplit plusieurs objectifs :

Partager la feuille de route — ça aide la communauté à comprendre sur quoi vous travaillez et lui offre souvent des opportunités de vous aider.

Apporter des garanties — ça prouve qu’un responsable de communauté fait quelque chose. Votre communauté peut constater votre travail effectif à l’œuvre. C’est très important puisque la majeure partie du travail d’un responsable de communauté s’effectue souvent sans que la communauté au sens large en ait connaissance (par exemple, avoir une conversation en tête à tête avec un des membres de la communauté). Et ce manque de visibilité peut parfois générer des inquiétudes sur le fait que peu de choses se produisent dans des domaines-clé alors qu’en fait, beaucoup de choses se produisent en coulisses.

Communiquer les progrès vers le haut et vers le bas de l’organisation — c’est pertinent si vous travaillez dans une entreprise. Avoir établi de bons processus de planification montre votre travail effectif à votre hiérarchie ; ça rassure votre équipe sur le fait que vous saurez toujours sur quoi travailler et ça donne beaucoup de valeur ajoutée à la communauté.

Au fil des années, j’ai attaché de plus en plus d’importance à la planification. Mais je garde suffisamment de temps et de flexibilité pour rester réactif. Quand j’ai débuté comme gestionnaire de la communauté Ubuntu, mon planning était plutôt personnel et je le gérais au coup par coup : je prenais le pouls de la communauté et je consacrais temps et moyens à m’occuper des domaines que je jugeais adéquats.

À présent, je répartis les objectifs dans un ensemble de projets qui couvrent chacun un cycle d’Ubuntu, je rassemble des informations avec les parties prenantes, je compose une feuille de route, je fais le suivi du travail dans des schémas directeurs. J’estime également les progrès effectués en utilisant toute une gamme d’outils et de processus tels que mon diagramme des tâches réalisées, des réunions régulières et d’autres encore. Bien que la méthode actuelle nécessite plus de planification, elle est d’une aide significative en termes de bénéfices sur les points cités ci-dessus.

Perception et conflit

Dans le monde de la gestion et de la gouvernance de communautés, j’entends souvent s’exprimer l’avis selon lequel tout serait affaire de perception. En règle générale, quand j’entends ça, c’est en réponse à quelqu’un qui se trouve du mauvais côté du bâton, le plus souvent au cours d’une période de conflit.

Bien sûr, la perception joue un rôle important dans nos vies, c’est vrai ; mais ce qui peut alimenter des perceptions erronées ou inadéquates, c’est le manque d’information, de mauvaises informations et, dans certains cas, des tensions et des tempéraments échauffés. Cela peut être une des tâches les plus complexes pour celui qui est à la tête de la communauté. Et j’en suis ressorti en tirant quelques leçons dans ce domaine également.

Les communautés sont des groupes de personnes et, dans chaque groupe, on trouve souvent des rôles stéréotypés dans lesquels les gens se glissent. On y trouve, en général, quelqu’un que l’on considère comme une rockstar ou un héros, quelqu’un de compréhensif pour les préoccupations et les soucis et qui prêtera son épaule pour pleurer, quelqu’un qui a son franc-parler et souvent quelqu’un qui est… disons… intentionnellement pénible. Les héros, les oreilles compatissantes et les grandes gueules ne posent pas particulièrement de problèmes, mais les personnes qui créent délibérément des difficultés peuvent être pénibles ; lorsqu’il devient carrément difficile de gérer une personne, cela peut provoquer des tensions avec les autres membres et amener du conflit dans une communauté qui, sinon, est heureuse. Il faut étouffer ce genre de problèmes dans l’œuf.

Une partie du défi, ici, c’est que les gens sont des gens, que les groupes sont des groupes et qu’il n’est pas rare qu’une personne (ou un petit nombre de personnes) se fasse connaître et soit critiquée derrière son dos et passe pour quelqu’un avec qui il est difficile de travailler. En plus de cela, la plupart des gens n’ont pas envie d’être impliqués dans un quelconque conflit et, du coup, la personne dont on se plaint ne peut pas toujours se rendre compte de la façon dont les gens la perçoivent, étant donné que personne ne veut la confronter à ce sujet. Il en résulte une des situations les plus dangereuses pour les membres d’une communauté — une réputation se propage, sans même que la personne concernée ne s’en rende compte. Et du coup, puisqu’elle ne le sait pas, elle n’a jamais l’occasion de changer de comportement. C’est une situation plutôt inconfortable.

Une réponse habituelle à cette conclusion consiste à dire : « ils sont si difficiles à gérer qu’essayer de les raisonner c’est peine perdue, de toute façon ». Même si cela se produit certainement de temps à autres, ne supposez pas trop vite que ce sera l’issue ; j’ai quelquefois eu la désagréable expérience de sentir que je devais faire savoir à certaines personnes, la réputation qu’elles avaient développée. Et, dans la plupart des cas, cela a été une réelle surprise pour elles. Et elles ont quasiment toutes modifié leur comportement après ce retour.

Sur un sujet lié, bien que ça n’est pas si courant dans la routine quotidienne d’un leader de communauté, un conflit va souvent se pointer ici ou là. Je voudrais juste partager deux éléments à ce propos.

La première chose, c’est de comprendre comment les conflits naissent. Pour expliquer cela, permettez-moi de vous raconter une anecdote. La semaine dernière, un de mes amis est venu en avion dans la baie de San Fransisco pour une conférence. Il est arrivé le soir, je suis donc allé le chercher à l’aéroport et nous sommes allés au pub pour discuter des dernières nouvelles. Là-bas, il commença à me raconter à quel point il était déçu d’Obama et de son administration. Il a cité des exemples : la réforme de la sécurité sociale, la réforme de Wall Street, les droits du numérique et d’autres choses. Ce qui l’embêtait n’était pas la politique menée en elle-même, mais il trouvait qu’Obama n’en faisait pas assez. Ma vision des choses était légèrement différente.

Je ne suis ni Démocrate, ni Républicain ; je prends ma décision sur chaque problème, sans m’aligner sur l’une ou l’autre des parties. Là où je diffère de mon ami, cependant, c’est que je suis un peu plus favorable à Obama et son travail quotidien. C’est parce que je crois que lui, et que n’importe qui dans un poste en relation avec le public — qu’il soit internationalement reconnu comme le président ou qu’il soit obscur et spécifique comme un gestionnaire de communauté — a conscience que l’histoire lue et comprise par le public est souvent un simple fragment de l’histoire complète. Il y a eu des cas, par le passé, où quelque chose de controversé a démarré dans les communautés auxquelles j’appartenais. De nombreux commentateurs et spectateurs n’avaient pas l’entière connaissance des faits, soit parce qu’ils n’avaient pas compris les nuances et les détails du sujet, soit parce que certains éléments de l’histoire n’avaient pas été partagés.

Bon, je sais ce que vous allez dire — , quoi, certains éléments n’avaient pas été partagés !? Il vaudrait mieux être transparent, n’est-ce pas ? Bien sûr que c’est nécessaire. Et nous devrions toujours nous attacher à être ouverts et honnêtes. Mais il y a des cas où il serait inapproprié de partager certaines parties de l’histoire. Cela pourrait être en raison de fragments de conversations privées avec des gens qui ne souhaitent pas partager leurs commentaires ou tout simplement faire son boulot bien comme il faut sans éclabousser les réputations. Par exemple, j’ai toujours eu comme pratique de ne pas faire de coups bas à des concurrents, peu importe la situation. Par le passé, il y a eu des comportements critiquables de la part de certains concurrents dans les coulisses. Mais je ne vais pas me mettre à salir leurs réputations car cela n’aurait pas vraiment d’intérêt. Je dois cependant accepter que des critiques de la communauté peuvent ne pas connaître toute la situation avec toutes les magouilles ayant eu lieu dans les coulisses.

Enfin, à propos de conflits, je crois que j’ai appris une vraie leçon de vie au sujet de l’approche idéale à propos des critiques et des issues heureuses. Bien que les billets de blogs aient eu un impact très positif sur la manière dont les gens peuvent exposer leur pensée et partager leurs opinions et visions des choses, ils présentent une facette bien plus sombre. Les blogs sont aussi devenus un moyen d’exprimer parfois un peu trop rapidement des opinions excessivement zélées. Malheureusement, j’ai un exemple plutôt embarrassant de quelqu’un qui est tombé dans ce piège : c’est votre serviteur.

Pour commencer, quelques éléments de contexte. Il existait une entreprise appelée Lindows qui distribuait une version de Linux qui présentait beaucoup de similarités visuelles et fonctionnelles avec Windows. Microsoft voulout interdire l’emploi du nom « Lindows » et une bataille s’engagea pour changer le nom. D’abord, Lindows résista. Mais après que la pression eut monté, l’entreprise se rebaptisa Linspire.

Maintenant, le problème. Je prends la liberté de l’expliquer dans les termes de l’article lui-même :

Il y a peu de temps, un type nommé Andrew Betts a décidé de retirer les éléments non-libres de Linspire et de publier les parties libres dans une distribution dérivée de Linspire qu’il a appelée Freespire. Le fait de rediffuser des distributions ou du code n’a certainement rien de nouveau et s’inscrit parfaitement dans la culture de l’open source. À vrai dire, bien des distributions que nous utilisons aujourd’hui ont été dérivées d’outils existants.

Malheureusement, Linspire a considéré que c’était un problème et a demandé à Freespire de changer de nom. En lisant l’annonce du changement, son langage et son style, j’ai l’impression que tout ça pue le pur marketing. Loin de moi l’idée d’insinuer que Betts a été contraint d’écrire cette page ou que les drones marketing de Linspire l’ont écrite et annexée en son nom, mais cela ne me semble pas sonner très juste. Je me serais attendu à trouver des lignes du style « Le nom de Freespire a été changé pour Squiggle afin d’éviter toute confusion avec le produit Linspire. », mais ce n’est pas le cas. Au lieu de cela, on a droit à des morceaux choisis de marketing comme « Afin de prévenir toute confusion, j’ai contacté Linspire qui m’a fait une offre extrêmement généreuse pour nous tous. » La vache ! Quelle peut bien être cette offre-exclusive-qu’on-ne-rencontre-qu’une-fois-dans-sa-vie-et-qu’on-ne-trouve-pas-dans-les-magasins ? Fort heureusement, il poursuit : « Ils souhaitent que tous ceux qui ont suivi mon projet puissent faire l’expérience du vrai Linspire, ET GRATUITEMENT !!! ». Maintenant, dites-nous, je vous prie, comment nous pouvons obtenir cette vraie version du logiciel « ET GRATUITEMENT » ?

« Pour une période limitée de temps, ils mettent à disposition un code de réduction dénommé FREESPIRE qui vous donnera une copie numérique gratuite de Linspire ! Veuillez visiter http://linspire.com/ pour les détails. » Ho… merci.

Dans un billet de mon blog, J’ai décoché à Linspire un bon coup de genou dans les bijoux de famille. J’ai raconté l’histoire, protesté contre ce que je considérais comme de l’hypocrisie considérant leur propre bataille dans des histoires similaires de marques déposées, et j’ai fulminé. J’aurais aimé que Guitar Hero existe à cette époque, cela aurait été un bien meilleur moyen d’utiliser mon temps.

Je me suis trompé. Mon article n’allait jamais servir à quoi que ce soit. Peu de temps après la publication de l’article, le PDG d’alors, Kevin Carmony, m’envoya un courriel. Il n’avait pas l’air satisfait de ma prestation. Son objection, et elle était valable, visait l’absence de concertation mutuelle préalable. Ma première réaction fut de répondre sur mon blog. La réalité de l’histoire était beaucoup moins noire. Et les gens de Linspire n’était pas les ogres que j’avais dépeints. J’ai présenté mes excuses à Kevin et me suis senti idiot.

Beaucoup de conflits sont résolus par des discussions privées où les gens peuvent être ouverts et concentrés sur les solutions sans être dérangés. Au fil des années, j’ai vu beaucoup d’exemples d’une guerre publique houleuse par blogs interposés continuant, alors que, dans les coulisses, il y avait un échange calme et une recherche de solutions.

Jono Bacon a appris à communiquer avec toutes les communautés

Pour conclure

Lorsque j’ai commencé à écrire cet article, il était bien plus court. Mais j’ai continué à ajouter des éléments un par un. Il est sûrement déjà assez long pour que je puisse compter le nombre de personnes lisant cette partie sur les doigts d’une main. Je vais donc l’arrêter ici. Je pourrais continuer éternellement avec des anecdotes croustillantes et des expériences dans lesquelles j’ai été suffisamment chanceux pour être impliqué et pour étendre mes horizons. Mais je finirais par écrire L’art de la communauté II : cette fois-ci, c’est personnel.

La vie est une expérimentation permanente. Et j’espère que votre investissement dans la lecture de cet article vous a apporté un peu d’expérience.

1 http://artofcommunityonline.org

2 http://communityleadershipsummit.com

Crédit photos : gidgetkitchen  (CC-BY-SA) et Ubuntu-news.ru

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

Traduction Framasoft : Miki, Vilnus Atyx, Sphinx, peupleLà, Goofy, tcit, Julius22, Garburst, Cyrille L., lerouge, Lycoris, vvision, lamessen

Comment ne pas lancer une communauté

Robert Kaye

Robert Kaye associe son amour de la musique et de l’open source dans l’encyclopédie de musique ouverte MusicBrainz. Robert a créé et dirige la MetaBrainz Foundation, une organisation à but non-lucratif basée en Californie, dans la continuité d’un travail de longue haleine pour améliorer l’expérience de la musique numérique. Au-delà du hack pour MusicBrainz, Robert recherche des festivals intéressants comme le Burning Man et des projets périphériques tels que bidouiller des robots pour préparer des cocktails. Comme il est invariablement couronné d’une chevelure aux vives couleurs, vous n’aurez aucun mal à le reconnaître dans une foule.

En 1998, je travaillais pour Xing Technology à San Luis Obispo et j’étais à fond sur notre nouveau projet AudioCatalyst. C’était l’un des premiers programmes d’extraction de MP3 intégré utilisant la base de données CDDB. Il s’agit de la base de données de CD qui permet à chaque lecteur de trouver le titre et la composition de tout CD. Si le CD n’est pas enregistré, on peut saisir les données afin que la prochaine personne qui en a besoin puisse s’en servir. J’adorais ce projet collaboratif en ligne et j’y ai enregistré des centaines de CD en quelques années.

Un jour, il nous a été annoncé que CDDB avait été achetée par Escient, une société qui deviendrait GraceNote par la suite. La base de données CDDB avait été privatisée, de sorte que plus personne ne pouvait la télécharger dans son intégralité ! Pour parachever le tout, Escient ne dédommagea aucun des contributeurs pour leurs efforts. En manœuvrant ainsi, ils arnaquaient le grand public. J’étais plutôt furieux de cette décision et je le suis encore aujourd’hui.

Plus tard dans la semaine, lors d’une fête avec des amis, je me plaignais de ce qui était en train de se passer et expliquais à quel point j’étais mécontent. Mon ami Kevin Murphy me dit : « Pourquoi tu ne démarrerais pas ton propre projet open source pour faire concurrence à ces enfoirés ? »

Quelques semaines plus tard, je finissais de travailler pour Xing et j’avais quelques semaines de temps libre avant de commencer chez EMusic. Je décidai d’apprendre le Perl et la programmation web en autodidacte et de démarrer la création de CD Index, un projet sans compatibilité et sans infraction avec CDDB. J’ai bidouillé le projet pendant cette pause mais l’ai rapidement oublié lorsque je suis devenu membre du projet FreeAmp chez EMusic.

C’est alors que Slashdot demanda, en mars 1999, quelle solution open source allait remplacer CDDB. J’ai passé le reste de la journée et la majeure partie de la nuit à finir CD Index et à le déployer. J’ai soumis un billet sur Slashdot parlant de mon projet (1) et il fut mis en ligne rapidement. Comme prévu, des centaines de geeks se manifestèrent en quelques minutes si bien que mon serveur tomba et rendit l’âme.

Les masses de gens qui arrivèrent commencèrent immédiatement à gueuler pour que les choses se fassent. Il n’y avait même pas encore de liste de diffusion ou de logiciel de suivi de problèmes ; ils insistèrent pour en avoir tout de suite. Comme j’étais novice dans l’open source, je ne savais pas vraiment ce qui était nécessaire ou non pour lancer un tel projet, j’ai fait comme les gens le demandaient. Les protestations reprirent de plus belle et davantage de gens encore insistèrent pour que je ferme le service étant donné qu’il n’était pas parfait. Mais même au milieu de ce vaste bazar, nous avons reçu plus de 3 000 soumissions de CD au cours des premières 24 heures.

Une fois que les choses furent calmées, il y avait encore beaucoup de gens qui rouspétaient. Greg Stein déclara qu’il allait écrire une meilleure version immédiatement. Mike Oliphant, l’auteur de Grip, annonça qu’il allait également travailler à une nouvelle version. Alan Cox vint et proclama que les bases de données SQL n’y suffiraient pas et que je devais utiliser DNS pour créer un meilleur service de recherche de CD. — Hein, quoi ? J’étais très mécontent de la communauté qui grandissait autour du billet publié sur Slashdot. Je ne voulais pas d’un lieu où les gens se manquent de respect et où certains se croient permis de gueuler encore plus fort pour obtenir ce qu’ils veulent. Je perdis rapidement tout intérêt pour le projet et CD Index déclina. Les autres projets que des personnes avaient promis de commencer (à l’exception de FreeDB) ne prirent jamais forme.

Alors, quand la bulle du point com a éclaté, j’ai eu besoin de réfléchir à ce que j’allais faire ensuite. Il était clair que mon boulot chez EMusic n’avait rien de sûr ; je continuais à conduire un roadster Honda S2000, ma voiture trophée de l’époque point com. Avec les traites de la voiture qui doublaient mon loyer, je devais décider : soit mener ma propre entreprise et vendre ma voiture de rêve, soit déménager à Bay Area (San Francisco) et travailler sur le rêve de quelqu’un d’autre, si jamais je parvenais à y trouver un travail. Je décidai que le plus intéressant serait de travailler sur une encyclopédie musicale complète construite par les utilisateurs. Je vendis la S2000 et me concentrai pour commencer à travailler sur une nouvelle mouture de CD Index.

Au cours d’une autre soirée, le nom MusicBrainz me vint et j’enregistrai le nom de domaine pendant la fête. Le jour suivant, motivé par le nouveau nom du projet, je commençai à bidouiller sérieusement et, à l’automne 2000, je lançai musicbrainz.org. Lancer n’est pas le bon mot, ici — je mis le site en place et me demandai alors comment éviter une nouvelle communauté de gosses hystériques venant de Slashdot. Je n’importai jamais de données depuis CD Index, ni ne mentionnai MusicBrainz sur les listes de diffusion de CD Index. Je me suis simplement éloigné du projet CD Index ; je ne voulais plus rien avoir à faire avec celui-ci. À la fin, j’ai décidé d’ajouter un simple bouton à la page web de FreeAmp qui mentionnait MusicBrainz.

Et une chose très étonnante s’est produite : des gens sont venus jeter un coup d’œil au projet. C’était seulement quelques personnes au début, mais quand quelqu’un me signalait quelque chose, je commençais une conversation et recueillais autant de retours d’informations que possible. J’améliorais le logiciel grâce à ces retours. J’ai aussi imposé un ton de respect sur les listes de discussion et, à chaque fois que quelqu’un était irrespectueux, j’intervenais et haussais le ton.

Mes efforts concentrèrent le projet vers son amélioration. Je l’ai fait pendant trois ans avant qu’il ne devienne clair que cette approche était efficace. La base de données croissait régulièrement et la qualité des données passa d’exécrable à bonne en quelques années.

Les bénévoles, ça va ça vient, mais je suis la colonne vertébrale du projet, c’est toujours moi qui donne le la et sa direction à l’ensemble. Aujourd’hui, nous avons une association à but non-lucratif avec 3,25 employés dans quatre pays, Google, la BBC et Amazon comme clients et notre bilan financier est bon. Je ne pense pas que cela aurait pu se produire avec la communauté CD Index.

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

Traduction Framasoft :peupleLà, elquan, tcit, Julius22, Garburst, okram, Jej, Cyrille L., lerouge, Lycoris, Goofy, CoudCoud, vvision, lamessen

Du bon usage de la couleur et des images dans le design

Eugene Trounev

Membre actif du logiciel libre et de KDE depuis près de six ans, Eugene Trounev a commencé chez KDEGames et a poursuivi pendant l’ensemble de la transition de KDE3 à KDE4. Il a participé à toute la transition de KDE3 vers KDE4. Actuellement, il s’occupe principalement de la présence de KDE sur le Web et de l’apparence du bureau principal.

Depuis la nuit des temps, les hommes ont utilisé la puissance des images et de la couleur pour transmettre des informations, attirer l’attention ou la détourner. Un célèbre dicton dit « une image vaut mille mots » et on ne saurait mieux dire. Depuis la façon dont nous nous habillons jusqu’aux néons criards des magasins de centre-ville dans le monde entier, chaque couleur, chaque forme et chaque courbe joue un rôle.

Connaître ce rôle n’est cependant pas si difficile, puisque toutes ces variations de teintes et de lignes sont assemblées pour être lues et ressenties par chacun de nous. Il est donc vrai qu’un design génial doit venir droit du cœur, étant donné qu’il est censé parler d’abord au cœur. Néanmoins, le cœur seul ne pourrait pas produire un design génial si quelques règles n’étaient pas d’abord définies et respectées.

Il existe plusieurs façons de classer les couleurs, mais la plupart mettent en avant les propriétés physiques ou chimiques de la lumière ou de l’encre. Bien que cela soit important pour le résultat final, ces propriétés ne vous aideront pas à faire un design attrayant. Ce qui fonctionne le mieux, selon moi, est de séparer entre couleurs chaudes et couleurs froides. Pour faire simple, les couleurs chaudes sont celles qui sont les plus proches de la teinte rouge : le rouge, l’orange et le jaune. Les couleurs froides, à l’opposée du spectre, sont celles qui se rapprochent du bleu : le vert, le bleu et, dans une moindre mesure, le violet. Il est important de se rappeler que « froid » représente aussi le calme et la respiration, tandis que « chaud » est impulsif et dangereux. Ainsi, en fonction des sentiments que vous souhaitez éveiller au sein de votre public, vous devriez utiliser des couleurs plus chaudes ou plus froides. Des couleurs chaudes pour attirer l’attention ; des couleurs froides pour informer. Une utilisation excessive de l’une ou de l’autre aboutira soit à une surchauffe — provoquant des sentiments négatifs chez votre public — soit à un refroidissement — ce qui causera son indifférence.

Il est important de se souvenir que le noir, le blanc et les nuances de gris sont aussi des couleurs. Celles-ci, toutefois, sont neutres. Elles ne provoquent aucun sentiment mais établissent plutôt une atmosphère. Leurs propriétés seront discutées plus loin.

Chaque image est d’abord et avant tout une collection de couleurs et, en tant que telle, suivra les règles de la gestion des couleurs. Déterminer la couleur dominante de votre image est la clé du succès. Essayez d’avoir une vue d’ensemble, sans vous concentrer sur les détails. Une bonne manière de le faire consiste à placer une image sur un fond sombre, puis à se reculer de quelques pas et de l’observer de loin. Quelle couleur percevez-vous le plus ?

Toutefois, toutes les images n’ont pas une couleur dominante. Quelquefois, vous rencontrez un amas de couleurs dont vous ne pouvez déterminer la teinte dominante, quelle que soit l’intensité avec laquelle vous le regardez. Essayez d’éviter de telles illustrations car elles vont inévitablement déconcerter vos utilisateurs. Confrontés à des images de ce type, les gens auront tendance à rapidement regarder ailleurs et cela ne leur laissera pas bonne impression, quel que soit le sujet abordé.

Au delà de la couleur, les images ont aussi une texture car, en fin de compte, elles ne sont rien de plus qu’un ensemble de couleurs texturées. Identifier la texture dominante d’une image n’est pas aussi simple que de percevoir sa couleur car les textures sont rarement évidentes, particulièrement dans les photographies. Il existe néanmoins quelques indicateurs pouvant vous aider. La nature humaine fait que nous sommes attirés par les formes incurvées (aussi appelées formes « naturelles ») tandis que les formes anguleuses et effilées sont considérées comme moins attirantes. C’est pour cela que l’image d’une feuille verte et incurvée sera plus attirante que celle d’un pic en métal. Pour résumer : la clé d’un design réussi et séduisant est une bonne combinaison, correctement équilibrée, entre couleurs et textures au sein des images utilisées.

Un autre aspect aussi important de tout design réussi est la mise en forme du texte et la disposition des espaces autour de celui-ci. Tout comme pour les textures et les couleurs, vous devriez toujours garder à l’esprit que les gens aiment respirer. Cela signifie qu’il devrait y avoir suffisamment d’espace dans et autour du texte pour le rendre plus facilement repérable, lisible et compréhensible.

Imaginez un exemple constitué de deux pages — l’une venant d’un roman d’amour tandis que l’autre est tirée d’un document légal. Vous préféreriez très probablement le roman d’amour par rapport à un document légal quel que soit le moment. Mais savez-vous pourquoi ? La réponse est simplement que vous aimez respirer. Une page de roman d’amour contient vraisemblablement trois éléments importants : des dialogues, des paragraphes et des marges extra-larges, tandis que la plupart des documents légaux ne comportent d’ordinaire aucun des trois. Tous les éléments mentionnés ci-dessus font vivre la page et la rendent dynamique, tandis qu’en leur absence, la page ressemble à un gros pavé de texte. L’œil humain, étant plus habitué à un certain degré de variation de formes, se sent plus à l’aise lorsque les pages bénéficient d’une mise en page aérée et fluide.

Toutefois, cela n’implique pas que chaque texte doive avoir ces trois éléments pour avoir l’air plus attrayant, loin de là. Tout texte peut être rendu facile et agréable à lire en l’aérant suffisamment.

Un peu de respiration ou d’espace peut être injecté au texte de plusieurs manières, telles que l’espacement des lettres, des lignes et des paragraphes ; les marges du contenu, de la section et de la page ; et pour finir, la taille de la police. Essayez de garder une espace d’au moins un caractère de haut entre vos paragraphes et vos lignes ainsi que des espaces de deux caractères de haut entre vos sections. Autorisez-vous des espaces généreux autour du texte sur une page en cadrant assez largement vos marges. Essayez de ne jamais avoir une taille de police inférieure à 10 points pour vos paragraphes tout en gardant les titres assez gros pour les faire ressortir.

Tout comme les animaux, les êtres humains sont souvent attirés par les éclats de couleurs brillantes et les textures inhabituelles. Plus le regard est attiré, plus les personnes ignoreront d’autres points d’intérêt potentiels. Cette simple règle de l’attraction est utilisée indifféremment par les hommes et les femmes pour canaliser l’attention des autres loin de certains éléments qui doivent selon eux passer inaperçus. Le meilleur exemple d’une telle supercherie est celui d’un magicien de rue qui distrait souvent l’attention des spectateurs par l’utilisation de fumée, de flammes ou de tenues tape-à-l’œil.

Il est important, ici, de se rappeler que les mots sont aussi visuels puisqu’ils créent des images et des associations spécifiques. La supercherie qui peut être réalisée avec de la fumée et du feu peut également être accomplie par le biais d’une utilisation créative des mots. Le meilleur exemple de supercherie quotidiennement réalisée grâce aux mots est, de loin, celle des étiquettes de prix. Vous êtes-vous déjà demandé pourquoi les commerçants aimaient autant les 99 et les 95 centimes ? C’est parce que les 9,95€, ou même les 9,99€, semblent plus attractifs que 10€, même si, dans la réalité, ils ont le même impact sur votre porte-monnaie. Ajoutez-y une « vieille » étiquette de prix à 10€ ostensiblement barrée d’une épaisse ligne rouge et vous aurez un bon aimant à clients.

Conclusion

L’obtention d’un design à la fois beau et attractif passe par ces règles de base : soyez judicieux dans vos choix iconographiques ; faites un bon usage des couleurs et des textures pour créer une atmosphère ; donnez à votre lecteur des espaces pour respirer ; détournez l’attention des parties qui comptent le moins pour l’amener sur celles qui sont importantes.

Ce court article n’entend pas couvrir toute l’étendue du spectre des différents styles et techniques de design. Il s’agit plutôt de vous donner à vous lecteur une base sur laquelle vous pourrez vous appuyer pour construire.

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