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

Traduction Framalang : satanas_g, Sphinx, Sky, Julius22, peupleLà, lamessen, goofy

Du débutant au professionnel

Jonathan Riddell

Jonathan Riddell est développeur KDE et Kubuntu, actuellement employé par Canonical. Quand il n’est pas devant un ordinateur, il fait du canoë sur les rivières d’Écosse.

Il y avait un bogue dans le code. Un bien méchant en plus : un plantage sans enregistrement des données. C’est bien là le problème dès qu’on regarde le code, on trouve des trucs à réparer. C’est facile de s’impliquer dans le logiciel libre ; le plus dur est d’en sortir. Après le premier bogue réparé, il y en a d’autres, et de plus en plus, tous à portée de main. Les corrections de bogues mènent à l’ajout de fonctionnalités, ce qui mène à la maintenance de projet, ce qui mène à faire fonctionner une communauté.

Tout a commencé en lisant Slashdot, cette masse d’actualité geek et technique peu filtrée avec des commentaires de quiconque peut recharger assez vite pour être en haut de liste. Chaque actualité était intéressante et excitante, apportait un éclairage nouveau sur le monde de la technologie qui finissait par me fasciner. Je n’avais plus à accepter ce qui m’était donné par de grandes entreprises de logiciels, je pouvais voir là, dans la communauté du logiciel libre, le code se développer devant moi.

En tant qu’étudiant, il était possible de finir les exercices donnés par les professeurs très rapidement. Mais les exercices ne sont pas des programmes terminés. Je voulais savoir comment appliquer les compétences basiques qu’ils m’avaient données dans le monde réel en écrivant des programmes résolvant des problèmes réels pour les gens. J’ai donc recherché du code, qui n’était pas difficile à trouver, il se trouvait là, sur Internet, en fait. En regardant le code des programmes que j’utilisais de plus près, j’y ai décelé de la beauté. Non pas parce que le code était parfaitement soigné ou bien structuré, mais parce que je pouvais le comprendre avec les concepts que j’avais déjà appris. Ces classes, méthodes et variables étaient bien en place, me permettant de résoudre les problèmes pertinents. Le logiciel libre est le meilleur moyen de franchir le pas entre savoir comment finir ses exercices de cours et comprendre comment de vrais programmes sont écrits.

Tous les étudiants en informatique devraient travailler sur du logiciel libre comme sujet de leur mémoire. Sinon, vous avez de grandes chances d’y passer six mois à un an pour qu’il finisse au sous-sol d’une bibliothèque sans être jamais plus consulté. Seul le logiciel libre permet d’exceller en faisant ce qui va de soi : vouloir apprendre comment résoudre des problèmes intéressants. À la fin de mon projet, des programmeurs de la NASA utilisaient mon outil de création de diagrammes en UML (NdT : langage de modélisation unifié) et il reçut des prix au cours de réceptions somptueuses. Avec le logiciel libre, on peut résoudre de vrais problèmes pour de vrais utilisateurs.

La communauté des développeurs est remplie de personnes formidables, passionnées et dévouées à leur travail, sans espoir autre de récompense qu’un programme d’ordinateur couronné de succès. La communauté des utilisateurs est également incroyable. Il est satisfaisant de savoir qu’on a aidé quelqu’un à résoudre un problème. Et j’apprécie les messages de remerciement que je reçois.

Après avoir écrit un logiciel utile, il faut le mettre à la disposition du plus grand nombre. Le code source ne va pas fonctionner pour la plupart des gens, il doit être compilé. Avant d’être impliqué, je trouvais que le fait de compiler était une manière un peu paresseuse de contribuer au logiciel libre. Vous vous attirez la plus grande partie de la reconnaissance sans rien avoir à coder. C’est, quelque part, quelque chose d’injuste. De même, la gestion de la communauté nécessaire pour porter un projet de logiciel libre peut aussi être vue comme une façon de s’attirer la reconnaissance sans faire de code.

Les utilisateurs dépendent beaucoup des packagers (NdT : les « empaqueteurs » qui préparent et maintiennent les paquets logiciels). Il est nécessaire que leur travail soit à la fois rapide, pour satisfaire ceux qui veulent la dernière version, et fiable, pour ceux qui veulent la stabilité (autant dire tout le monde). La partie la plus délicate, c’est que cela implique de travailler avec les logiciels des autres, qui sont toujours « cassés ». Une fois que le logiciel est lâché dans la nature, commencent à emerger des problèmes qui n’étaient pas repérables sur l’ordinateur de l’auteur. Il est possible que le code ne puisse pas être compilé avec une version de compilateur différente, peut-être que la licence n’est pas claire et ne permet pas de le copier, peut-être que la gestion des versions est incohérente et qu’une mise à jour mineure est incompatible, ou encore que la taille de l’écran est différente, les environnements de bureau peuvent aussi l’affecter, quelquefois, des bibliothèques tierces nécessaires ne sont pas encore à jour. De nos jours, le logiciel doit pouvoir tourner sur différentes architectures. Les processeurs 64 bits ont occasionné pas mal de problèmes quand ils sont devenus courants. Aujourd’hui, ce sont les processeurs ARM qui déjouent les calculs des codeurs. Les packagers doivent régler tous ces problèmes pour donner aux utilisateurs quelque chose qui fonctionne de façon fiable.

Nous avons une règle chez Ubuntu selon laquelle les paquets avec des tests unitaires doivent inclure ces mêmes tests dans le processus de la création des paquets. Souvent, ils échouent et l’auteur du logiciel nous dit que les tests sont uniquement à son usage. Malheureusement, quand il s’agit de logiciel, il n’est jamais assez fiable de le tester soi-même, il doit aussi être testé par d’autres. Un test unique est rarement suffisant, il faut une approche à plusieurs niveaux. Les tests unitaires du programme original devraient être le point de départ, ensuite, le packager les teste sur son propre ordinateur, il faut ensuite que d’autres personnes les testent aussi. L’installation automatique et les tests de mise à jour peuvent être scriptés assez correctement sur les services d’informatique dans le nuage. L’envoyer dans la branche de développement d’une distribution permet d’effectuer plus de tests avant de le voir distribué en masse quelques mois après. À chaque étape, des problèmes peuvent être et seront découverts, ils devront être corrigés, puis ces correctifs eux-mêmes devront être testés. Il n’y a donc pas forcément à écrire beaucoup de code, mais il y a pas mal de travail pour passer le logiciel de 95 % à 100 % prêt. Ces 5 % sont la partie la plus difficile, un lent et délicat processus qui demande une grande attention pendant tout son cours.

Vous ne pouvez pas faire de paquets sans une bonne communication avec les développeurs en amont. Quand des bogues se produisent, il est vital de pouvoir trouver la bonne personne à laquelle parler rapidement. Il est important d’apprendre à bien les connaître comme des amis et des collègues. Les conférences sont vitales pour cela, car rencontrer quelqu’un apporte beaucoup plus de contexte à un message sur une liste de diffusion qu’une année entière de messages.

Une des faces cachées du monde du logiciel libre réside dans la communication par les canaux IRC privés utilisés par les principaux membres d’un projet. Tous les grands projets en ont. Quelque part, Linus Torvalds a un moyen de discuter avec Andrew Morton et les autres sur ce qui est bon et sur ce qui est mauvais dans Linux. Ils sont plus sociaux que techniques et, quand on en abuse, ils peuvent être très antisociaux pour la communauté en général. Mais pour les moments où on a besoin d’un canal de communication rapide sans bruit parasite, ils fonctionnent bien.

Tenir un blog est un autre moyen de communication important dans la communauté du logiciel libre. C’est notre principale méthode pour promouvoir à la fois le logiciel que nous produisons et nous-mêmes. Non pas que ce soit utilisé éhontément pour de l’auto-promotion (il est inutile de prétendre que vous sauverez des vies avec votre blog…), mais parler de votre travail sur le logiciel libre aide à construire une communauté. Cela peut même vous valoir de trouver un travail ou d’être reconnu dans la rue.

Ces histoires venant de Slashdot, à propos de développements de nouvelles technologies, ne concernent pas des personnalités éloignées que vous ne rencontrerez jamais comme dans la presse people. Elles concernent des personnes qui ont trouvé un problème et qui l’ont résolu en utilisant l’ordinateur qu’elles avaient en face d’elles. Pendant quelques années, j’ai édité le site d’informations de KDE, trouvant les personnes qui résolvaient des problèmes, créaient des idées novatrices, s’acharnaient longuement à améliorer un logiciel jusqu’à ce qu’il soit d’une qualité suffisante, et j’en parlais au monde entier. Je n’ai jamais été à court d’histoires à raconter ni de personnes à présenter à tout le monde.

Mon dernier conseil est de conserver de la diversité. Il existe une telle richesse de projets intéressants à explorer, qui vous permettent d’apprendre et de progresser. Mais une fois que vous avez atteint une position de responsabilité, il peut être tentant d’y rester. Après avoir aidé à créer une communauté pour Kubuntu, je repars temporairement vers un travail sur Bazaar, un projet très différent, orienté sur les développeurs plutôt que sur des utilisateurs novices en technologies. Je peux à nouveau apprendre comment le code devient une réalité utile, comment une communauté communique, comment la qualité est maintenue. Ce sera un défi amusant et j’ai hâte de m’y attaquer.

Google Glass c’est le projet Google de lunettes révolutionnaires à réalité augmentée. On nous promet leur commercialisation avant la fin de l’année. Une vidéo spectaculaire a été publiée récemment. Si vous ne l’avez pas encore vue, nous vous invitons à le faire car vous allez mieux comprendre la traduction qui suit.

Bientôt donc vous retrouverez quelque part avec des gens qui porteront ces lunettes. À tout moment, ceux-ci peuvent vous filmer à votre insu et mettre en ligne en temps réel la vidéo sur YouTube, non sans qu’un système automatisé de reconnaissance faciale et de tags vous ait peut-être identifié au passage !

Ce n’est plus de la science-fiction et comme Google n’est pas une entreprise philanthropique, on imagine sans peine l’impact majeur d’une telle innovation sur notre vie privée et le devenir de nos données personnelles.

Gare aux Google Glasses !

Watch Out for Google Glasses

Anton Wahlman – 25 février 2013 – TheStreet.com
(Traduction : jtanguy, 3wen, Benoît, Jeanba88, misterk, goofy + anonymes)

D’ici la fin de cette année, notre société va subir un changement très particulier, qui va susciter beaucoup de controverses. La cause ? Les Google Glasses.

Les Google Glasses vont impacter les comportements sociaux dès leur mise en circulation. Au moment où vous les apercevez, vous savez que vous pouvez être filmé. Et les gens n’aiment pas être filmés.

Bien sûr, tous les smartphones peuvent enregistrer des vidéos et prendre des photos. Mais vous savez quand ça arrive. Vous n’avez pas constamment l’impression que tout le monde autour de vous est en train de vous filmer sous tous les angles. Vous les voyez faire quand ils le font.

Les Google Glasses sont différentes. Au-delà des photos et des vidéos, qu’advient-il de ces données ?

Imaginons que je sois derrière le guichet d’une entreprise : banque, restauration rapide, guichet d’enregistrement à l’aéroport, peu importe. Mes Google Glasses pourraient afficher le numéro de sécurité sociale, le casier judiciaire, la présence sur les réseaux sociaux, etc. de la personne en face de moi.

C’est peut-être un progrès pour certains mais d’autres trouveront cela terrifiant. Pouvez-vous imaginer la scène dans un bar où les gens commencent à porter des Google Glasses ? En l’espace d’une seconde ou deux, vous aurez toutes les informations disponibles à propos de la personne en face de vous. Et certaines de ces informations pourraient ne pas être flatteuses.

Les lieux publics devront élaborer de nouvelles politiques. Hôtels, aéroports, restaurants, salles de sport et écoles voudront avoir leur mot à dire concernant le port des Google Glasses dans leurs locaux. Vous pourrez entendre les tollés dès que les premières images de gens trichant dans les écoles, ou filmant dans les vestiaires seront publiées sur YouTube. De futurs conflits vont certainement très mal tourner.

D’autre dimensions du problème apparaissent aussitôt. Que se passera-t-il si les versions futures des Google Glass deviennent très difficiles à distinguer des lunettes traditionnelles ?

Aujourd’hui, que se passe-il si vous pénétrez dans un établissement en tenant une caméra qui filme les visages des gens, dans un restaurant, une banque ou une salle de sport ? On vous demandera d’éteindre votre caméra, et si vous n’obéissez pas rapidement, on vous jettera dehors.

Les Google Glasses vont rendre les interactions publiques et sociales très délicates car vous prenez le risque potentiel d’être sur YouTube quel que soit l’endroit où vous allez. Quelques mois après leur arrivée sur le marché, les Google Glasses pourraient être déjà si répandues que vous serez filmé dès que vous pointerez le nez dehors.

Défenseurs de la vie privée, en avant !

Les données photos et vidéos des Google Glasses ne vont pas être utilisées seulement par la personne qui porte les lunettes. La personne qui prend ces images voudra peut-être « taguer automatiquement » ces médias avec l’identité des personnes dans la photo ou vidéo.

Il y a des gens qui préfèrent passer sous les radars. Ils payent en liquide, n’utilisent pas de GPS en voiture, n’ont pas de téléphone, et ne sont membres d’aucun réseau social en ligne. Ils ont réussi à rester en-dehors de la plupart des bases de données disponibles publiquement.

Une fois qu’une partie significative de la population aura commencé à déambuler dans les rues avec des Google Glasses, ils ne le pourront plus vraiment. Il n’y aura plus de place pour se cacher, à moins que les gouvernements ne légifèrent sur ces Google Glasses, ou que les établissements privés décident de les interdire.

Qu’en est-il de Google lui-même ?

Les Google Glasses deviendront une arme décisive dans la guerre imminente pour les données personnelles. Si d’autres personnes les utilisent, pourquoi pas moi ? Je prédis que toutes les personnes avec suffisamment de moyens vont se ruer pour en obtenir, surtout si le prix baisse de 1 500$ à 1 000$, puis à 500$ et finalement en-dessous, lors des deux premières années de commercialisation.

Si Google arrive à sortir ce genre de lunettes avant ses concurrents directs, non seulement Apple, mais aussi Microsoft, son avance pourrait bien être décisive. Google possède déjà 70% des parts de marché des smartphones avec Android, donc il est plutôt bien parti, mais n’oublions pas que la part de marché des PC de Microsoft atteignait 95% il y a seulement quelques années.

Comme Google va probablement inventer un lien fort entre les Google Glasses et les smartphones Android, les Google Glasses vont être une véritable aubaine pour Android. N’importe qui regardera son iPhone et devra sérieusement envisager de passer à Android.

Les Google Glasses risquent de causer un chaos social, mais elles vont être très bénéfiques pour les finances de Google.

Crédit photo : Max Braun (Creative Commons By-Sa)

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.

Libre ou propriétaire, open source ou sources closes, voilà des lignes de fracture radicales qui sont familières dans le monde du logiciel. Les choses sont moins tranchées peut-être du côté des entreprises qui se définissent non sans arrière-pensées comme plus ou moins « ouvertes ».

Tim Wu nous invite à prendre un peu de recul par rapport à notre conception commune suivant laquelle les modèles ouverts sont destinés à l’emporter. La réussite ou non des grandes entreprises de technologies informatiques ces dernières années montre que la question n’est pas si simple et la partition pas si flagrante.

En adoptant une perspective bien étatsunienne, celle du pragmatisme qui consiste à comparer les résultats, l’auteur tend à évaluer l’ouverture en termes de degrés. À vous de dire si les valeurs du libre ne sont pas écornées au passage.

Une entreprise fermée comme Apple peut-elle réussir sans le talent d’un Steve Jobs ?

par Tim Wu dans cet article du New Yorker

Traduction Framasoft : Texmix, Sphinx, Garburst, Husi10, lamessen, Paul-Arthur, ehsavoie, goofy

On dit depuis un bon moment dans le milieu techno que « le modèle ouvert l’emporte sur le modèle fermé ». En d’autres termes, les systèmes technologiques ouverts, ou bien ceux qui permettent l’interopérabilité, finissent toujours par surpasser leurs concurrents fermés. C’est une véritable profession de foi chez certains ingénieurs. C’est aussi la leçon qu’on peut tirer de l’échec de MacIntosh face à Windows dans les années 90, du triomphe de Google au début des années 2000 et plus largement, de la victoire d’Internet sur ses rivaux au modèle fermé (vous souvenez-vous d’AOL ?). Mais est-ce encore justifié ?

Depuis quelques années, cet adage a été remis en question, principalement à cause d’Apple. Cette entreprise, ignorant les idéaux des ingénieurs et les prêches des experts techno, s’est rapidement cloisonnée dans une une stratégie semi-fermée — ou « intégrée » comme elle aime à le dire — et a défié la règle. Sur le plan structurel, Apple pratique l’intégration bien mieux que ses rivales. Elle possède le matériel, le logiciel et le circuit de distribution. Elle bloque et dessert également beaucoup plus ses concurrents. Eh oui, de cette manière, elle est devenue l’entreprise la plus rentable la planète. Au dernier trimestre, Apple a enregistré plus de bénéfices qu’Amazon n’en a réalisé depuis sa création.

Mais maintenant, depuis les six derniers mois, de manière plus ou moins flagrante, Apple a commencé à trébucher. Vous allez dire que j’exagère, mais je propose une révision du vieil adage « le modèle fermé peut l’emporter, mais vous devez être un génie ». Dans des conditions normales, dans une industrie imprévisible, et étant donné le niveau normal d’erreurs humaines, le libre continue à surpasser le fermé. Pour le dire autrement, une entreprise doit être fermée dans l’exacte proportion de ses talents de visionnaire et de conception.

Pour m’expliquer, je vais d’abord devoir soigneusement exposer ce que j’entends par « ouvert » et « fermé », des mots qui sont largement employés dans le monde de l’informatique, mais avec de multiples sens. La vérité c’est qu’aucune des entreprises n’est complètement ouverte ou fermée ; elles se répartissent sur un spectre, un peu comme celui qu’utilisait Alfred Kinsey pour décrire la sexualité humaine. Pour moi, ici, cela signifie la combinaison de trois éléments.

Tout d’abord, « ouvert » et « fermé » peuvent faire référence à la permissivité de l’entreprise technologique vis-à-vis des partenariats et des interconnexions qu’elle peut créer pour que ses produits arrivent jusqu’aux utilisateurs. Nous disons qu’un système d’exploitation comme GNU/Linux est « ouvert » parce que n’importe qui peut concevoir un produit sur lequel faire tourner GNU/Linux. En revanche, Apple est très exclusif : il ne laissera jamais iOS s’exécuter sur un téléphone Samsung ni vendre des Kindle dans un Apple store.

En second lieu, l’ouverture peut décrire l’impartialité avec laquelle une entreprise technologique traite les autres entreprises par rapport la manière dont elle se traite elle-même. Firefox, le navigateur, traite tous les sites internet de la même manière. En revanche, Apple se traite mieux que les autres (essayez donc de désinstaller iTunes de votre iPhone).

Troisièmement, et pour conclure, cela décrit le niveau de transparence et d’ouverture d’une entreprise selon la manière dont ses produits fonctionnent et peuvent être employés. Les produits open source, ou ceux qui dépendent de standards ouverts, rendent leur code largement accessible. En attendant, une compagnie comme Google peut être ouverte sur bien des points mais garder jalousement le secret sur certaines choses, comme le code de son moteur de recherche. Dans le monde des technologies, la métaphore classique utilisée pour décrire cette dernière différence est la cathédrale contre le bazar.

Aucune entreprise privée n’est entièrement ouverte, bien que quelques fondations à but non-lucratif, comme Mozilla, s’en approchent. De la même manière, aucune entreprise ne peut se permettre d’être entièrement fermée. Un exploitant de plateforme gagne à avoir de bonnes applications disponibles (pensons à ce que serait, hum, l’iPhone sans Google Maps), et trop bloquer détruira ce qui donne sa valeur au produit. Même Apple a besoin d’être assez ouvert pour ne pas trop déranger les consommateurs. Vous ne pouvez pas lancer le Flash d’Adobe sur un IPad, mais vous pouvez brancher presque n’importe quel type d’écouteur dessus.

L’idée que « le modèle ouvert l’emporte sur le modèle fermé » est historiquement assez récente. Dans la majeure partie du XX^e siècle, l’intégration était considérée comme la forme d’organisation commerciale supérieure. Les modèles fermés ou intégrés arrivent avec des avantages reconnus depuis longtemps et même proclamés haut et fort par les économistes. La coordination est un avantage-clé : en théorie, avec une entreprise qui coordonne tous les aspects et caractéristiques d’un produit donné, le résultat peut mieux fonctionner que celui d’un rival non-coordonné. L’économiste Joseph Farell a appelé ceci « internalisation des économies complémentaires ». Si cela ne vous dit rien, considérez l’effet Disneyland. Disney contrôle tout avec une poigne de fer ou presque, et le parc d’attractions fonctionne sans anicroches, avec une réussite impressionnante bien supérieure par exemple à une fête foraine classique.

Andrew Carnegie s’est appuyé sur une logique similaire à celle d’Apple lorsqu’il a intégré l’extraction minière avec la production d’acier au sein de U.S. Steel. Les vieux studios Hollywood des années trente et quarante ont intégré le jeu, les scénarios, la production et les cinémas dans une seule et même entreprise. Elle a ainsi chassé tous les autres de son industrie. I.B.M. avait un modèle fermé et le vieux monopole de A.T. & T. était le système fermé par excellence : vous n’aviez pas le droit de posséder votre propre téléphone mais seulement d’en utiliser un produit par quelqu’un d’autre.

La sagesse populaire commença à changer dans les années soixante-dix. Sur le marché des technologies, des années quatre-vingt au milieu des années deux mille, les systèmes ouverts ont vaincu à plusieurs reprises leurs concurrents fermés. Windows de Microsoft a battu ses rivaux en adoptant un modèle plus ouvert. À la différence du système d’exploitation d’Apple qui était supérieur sur le plan technique, Windows fonctionnait sur n’importe quel matériel et faisait marcher presque tous les logiciels. Au même moment, Microsoft surpassa I.B.M. et son modèle intégré verticalement (qui se souvient de Warp O.S. ?), Google était audacieusement ouvert dès sa conception originale et passa devant Yahoo et son système sélectif de publicité au placement. La plupart des vainqueurs, entre quatre-vingt et deux mille, tels que Microsoft, Dell, Palm, Google et Netscape, suivaient un modèle ouvert. Internet même, basé sur un projet financé par le gouvernement, était à la fois incroyablement ouvert et incroyablement réussi. Un mouvement était né et avec lui la règle selon laquelle : « le modèle ouvert l’emporte sur le modèle fermé ».

Le triomphe des systèmes ouverts a révélé un défaut majeur dans les conceptions fermées. Selon la théorie économique, dans un état d’information parfaite, un concepteur central devrait être capable de produire un meilleur produit. Mais c’est seulement vrai si le futur est prévisible, et si on ignore la tendance des êtres humains à commettre des erreurs bêtes. Dans un système fermé, avec un seul décideur, les erreurs coûtent très cher. Les décisions stupides, ou qui compromettent le produit pour des profits à court terme, ne vont pas rendre les produits seulement un peu moins bons mais vraiment pires que ceux du concurrent direct. Par exemple, la politique de chasse gardée d’AOL des années 90 consistait à essayer de deviner ce que les utilisateurs allaient vouloir, mais AOL a fait un tas d’erreurs, et finalement ça ne correspondait pas à un Web ouvert.

En revanche, un produit ouvert est mieux protégé des erreurs humaines car ce n’est pas une unique entité qui prend une décision susceptible de détruire le produit. Les économistes Tim Bresnahan et Shane Greenstein, dans les années 90, ont décrit ce phénomène sous le terme « direction technique partagée », et ils lui donnaient un sens mélioratif. Le produit est le résultat collectif de plusieurs, voire parfois de milliers de décideurs. Un produit ouvert peut aussi profiter des contributions volontaires et collectives des masses, un point mis en avant par Yochai Benkler. Ainsi, une entrée sur Wikipédia peut être vague et contenir des erreurs, mais le corpus dans son ensemble restera impressionnant. Au milieu des années 90, Windows n’était pas aussi intuitif que Macintosh, mais tous les accessoires et les applications en firent collectivement un produit supérieur.

Ce qui nous amène aux années 2000 et au magnifique parcours d’Apple. Pendant presque douze années, Apple a battu la mesure avec succès. Mais c’est parce qu’il avait le meilleur des systèmes possibles, à savoir, un dictateur disposant d’un contrôle absolu, qui était aussi un génie. Steve Jobs était la version entreprise de l’idéal de Platon : le roi-philosophe nettement plus efficace que toute forme de démocratie. L’entreprise dépendait d’un unique esprit central, mais il a fait très peu d’erreurs. Dans un monde sans erreurs, le fermé bat l’ouvert. En conséquence, pour un temps, Apple triompha de ses rivaux.

Alors que doit faire une entreprise technologique ?

Chacun est confronté à cette question du modèle ouvert ou fermé, et voici comment y répondre. Premièrement, il existera toujours un compromis difficile entre systèmes ouverts et fermés, et il est donc inutile de trop s’enfermer dans l’une ou l’autre des options. Il est facile de sous-estimer les projets ouverts (personne ne pensait que Wikipédia fonctionnerait), mais même les projets ouverts ont besoin de contrôle à certains niveaux. Finalement, plus votre vision et vos compétences de créateur sont bonnes, plus vous pouvez essayer d’être fermé. Si vous pensez que vos concepteurs de produits peuvent égaler le quasi sans-faute de Jobs ces vingt dernières années, allez-y. Mais si de simples mortels font tourner votre entreprise, ou si vous êtes face à un futur très imprévisible, les analyses économiques suggèrent qu’un système ouvert est plus sûr. Vous pourriez peut-être vous fier à ce test : en vous levant le matin, regardez dans le miroir et demandez-vous : suis-je Steve Jobs ?

Crédit image : the opensourceway CC-BY-SA

Il fut un temps ou débuter dans « le Libre » se résumait avant tout à coder ou plus modestement installer une distribution GNU/Linux. Aujourd’hui les choses ont bien changé et il existe de multiples autres façons d’y entrer. Framasoft est d’ailleurs là pour en témoigner 😉

Une invitation à venir nous rejoindre en somme…

Remarque : Il s’agit d’une traduction et donc les liens renvoient vers des ressources anglophones. Si vous avez des liens plus locaux à proposer, surtout ne pas hésiter.

10 façons de commencer dans l‘open source

10 ways to get started with open source

Jason Hibbets – 29 janvier 2013 – OpenSource.com
(Traduction : goofy, Tibo_R, XeO2, Steph, Alpha, Sylvie, jtanguy, aKa, Liaz, Norore + anonymes)

Par expérience, je sais qu’un grand nombre de personnes veulent découvrir et participer à l‘open source, mais ne savent pas par où commencer ; et l’idée que l’on est obligé d’écrire du code pour contribuer à un projet open source constitue une véritable barrière. J’ai donc esquissé 10 façons de commencer avec l‘open source et ce sans jamais écrire une seule ligne de code.

Je suis ouvert à toutes idées et ajouts ; il y a sans doute beaucoup plus que 10 façons de contribuer.

10 façons de commencer à utiliser l‘open source

1. Utiliser de l‘open source dans votre travail quotidien. Téléchargez et installez un navigateur web, un client de messagerie, ou une suite bureautique libres — peu importe le système que vous utilisez. C’est l’une des façons les plus simples de commencer à utiliser des logiciels libres. Je conseillerai Firefox pour la navigation internet et Thunderbird pour les emails. Utilisez LibreOffice pour votre traitement de texte, vos tableurs et vos diaporamas, vous aurez un équivalent de Microsoft Office gratuit ! J’appelle ces logiciels des applications porte d’entrée, parce qu’une fois que vous commencez à les utiliser, vous allez découvrir d’autres outils open source (et vous n’aurez pas envie de revenir en arrière !)

2. Rejoindre un projet open source. Je sais que rejoindre un projet open source peut faire peur, mais les contributeurs de tous niveaux sont les bienvenus. Les communautés open source utilisent des chefs de projets, des graphistes, des communicants, des commerciaux et beaucoup d’autres compétences dans leurs travaux. Si vous souhaitez présenter l’open source aux étudiants, voilà une très bonne façon de commencer. On ne sait jamais, s’impliquer et participer activement à un projet open source peut améliorer un CV et mener à un emploi.

3. Lire un livre à propos de l‘open source. Voici un choix de quelques titres auxquels vous pouvez jeter un coup d’oeil : Open Advice (NdT : que nous sommes en train de traduire), Coding Freedom, The Power of Open, ou l’un de nos livres numériques. (NdT : En français il y a évidemment tous les titres de la collection Framabook)

4. Apprendre à créer et nourrir des communautés de contributeurs. Parcourez le livre en ligne The Open Source Way, et partagez vos nouvelles connaissances en créant une communauté ou en en rejoignant une existante.

5. Commencer à utiliser les licences Creative Commons. Avant de créer votre nouvelle œuvre d’art, photographie, écrit ou musique, utilisez un copyleft au lieu d’un copyright. En utilisant des licences Creative Commons, vous pouvez partager votre travail avec le monde entier. Vous devrez d’abord choisir celle qui vous correspond, vous pourrez ensuite trouver intéressant de découvrir comment les Creative Commons sont utilisées dans des environnements aussi variés que les gouvernements, les entreprises ou le journalisme. (NdT : Voir aussi L’éducation utilise une licence Creative Commons défectueuse, par R. Stallman sur le Framablog)

6. Commencer l’exploration. Regardez le projet OpenROV et explorez l’océan ou un lac local. Si vous ne voulez pas être mouillé, enfilez une combinaison spatiale et regardez ce que ça fait d’explorer Mars.

7. Bricoler par soi-même et créer quelque chose. Les petites cartes Linux, comme la Raspberry Pi, font des choses incroyables. Découvrez les autres cartes électroniques de création comme les « Makey Makey » (cf cette vidéo) ou une variété de produits électroniques de « SparkFUN ». Si vous êtes dans l’impression 3D, assurez-vous de savoir comment vous pourriez utiliser Inkscape.

8. Devenir créatif. Remplacez Photoshop par GNU Image Manipulation Program (GIMP), InDesign par Scribus, ou utilisez d’autres outils comme MyPaint, Inskape, Audacity et Blender. Si cela vous intéresse, regardez notre présentation en 7 minutes des outils créatifs open source. Puis découvrez l’étendue des outils de design en 2012. Assurez-vous d’avoir pris connaissance de nos autres outils tels que Dream Studio, TuxPaint et KDEnlive pour vos besoins créatifs.

9. Apprendre la programmation. Remarquez que je n’ai pas dit « Apprendre à coder ». Différents outils sont pré-installés sur certains Raspberry Pi et sont utilisés pour apprendre aux enfants à programmer. J’aurais aimé avoir ce genre de choses quand j’ai appris la programmation au lycée.

10. Suivre un cours en ligne. Le mouvement OpenCourseWare, mené par MITOCW, est en train de changer notre mode d’apprentissage. Commencez par regarder ce Webcast sur le MIT OpenCourseWare. Il y a tellement d’événements open source dans le champ éducatif: « Moodle » et « School management software for teachers and students » sont deux de ces nombreuses ressources fantastiques. (NdT : Exemple en France la présentation du MOOC ITyPA)

Le fait est qu’il y a énormément de manières de commencer dans l‘open source. Vous souvenez-vous de la façon dont vous avez débuté ? Partagez l’histoire de votre première expérience avec l‘open source ou comment vous l’avez présentée à quelqu’un d’autre.

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 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).