Par le plus grand des hasards, une table ronde “design et open source” était organisée dans le hackerspace “le Reset” quelques jours après mon billet sur le sujet. La discussion s’est ensuite poursuivie de manière plus informelle dans un bar.

Comme le sujet a pas mal intéressé et que j’ai eu des demandes, voici un rapide compte rendu (table ronde + bar ensuite) qui sera complété peu à peu selon mes souvenirs (ouais j’ai pas pris de note et alors kestuvafaire ?).

D’autres personnes ont fait les choses sérieusement et ont prévu un vrai compte rendu, je le mettrai en lien dès qu’ils seront disponibles.

Liste des présents (à compléter)

Note : dans le compte-rendu ci dessous, j’utilise le “nous” qui ne reflète pas forcément une unanimité de point de vue des personnes listées ci-dessus. Également, certaines réflexions ont été exprimées après la table ronde, en petit groupe.

Les designers parlent aux designers

Première constatation : les designers étaient au rendez-vous, mais hélas pas les développeurs. Marc Jeanmougin, un contributeur de Inkscape a fait le déplacement, et je le remercie pour ça, la discussion a bien été enrichie par son point de vue.

Forcément, tous les designers présents partageaient le constat initial, il n’y a donc pas eu trop de débat sur ce point. Pour autant, nous n’avons pas tourné en rond car nous avons pu mettre notre expérience en commun et essayer d’identifier les points de blocages plus facilement, avant d’envisager quelques solutions.

Encore beaucoup d’UX

À mon grand regret, nous avons beaucoup parlé d’UX et toute la partie identité/branding a été laissée de coté. Pour moi ça n’est qu’un des aspects du design, et même si c’est intéressant le débat va toujours s’enliser sur des questions de bouton ou d’interface de tel ou tel logiciel, alors que ça ne représente qu’une partie (même si importante) du problème global.

Comme je le disais dans mon billet précédent, je pense qu’on est à un stade où à part quelques irréductibles, on est quand même arrivé à un consensus sur le fait qu’une bonne ergonomie est incontournable et mesurable, et on pourrait pousser maintenant la nécessité d’une identité.

Une certaine impuissance devant un défi actuel

Si tous les présents voulaient contribuer au libre, c’est entre autre car ce mode de diffusion nous est cher, et qu’il nous semblait que dans un contexte actuel ou les entreprises privées prennent de plus en plus l’ascendant sur l’utilisateur, couplé à l’émergence de régimes totalitaires dans des démocraties jusque là épargnées, il est donc plus que jamais nécessaire que les utilisateurs s’approprient ces logiciels à la philosophie ouverte et avantageuse pour eux.

Or, nous sommes convaincus que l’adoption massive de ces outils passe par la facilité d’utilisation et la communication par rapport aux mastodontes privés qui les concurrencent. L’impuissance à faire reconnaître ce point de vue par la communauté libre génère une certaine frustration.

L’argent n’est pas le seul facteur en cause, et il nous semble que la communauté libre est armée pour une large diffusion (comme c’est le cas dans l’infrastructure d’internet par exemple).

Une histoire de compétences

Nous partageons majoritairement le constat de la négation de la compétence du designer dans le libre. Quel que soit notre degré de compétence ou notre expérience, le design est encore beaucoup vu comme un à-coté, et peut être discuté et disqualifié par n’importe qui et n’importe comment.

Il était d’ailleurs impressionnant de voir le niveau des designers présents dans des métiers qui n’étaient pas les leurs, pour justement pouvoir contribuer au logiciel libre et parler aux développeurs. Quasiment tous les designers présents savaient se servir des outils de développement, coder un minimum, intégrer en html/css… À leur niveau bien sûr, mais qui était déjà bien supérieur à une simple sensibilisation.

On aurait tous aimé que les développeurs aient des compétences équivalentes en design.

Remise en cause de la méritocratie dans le libre

Il a été évoqué le fait que la “méritocratie” qui régit les contributions libres était fortement biaisée en faveur des développeurs, car ce sont les développeurs qui in fine décident d’intégrer (en la codant) ou non une contribution de designer. En plus de leur travail, et indépendamment de sa qualité, les designers doivent donc toujours faire le double du boulot en faisant non seulement le design, mais en plus en devant convaincre des personnes dont ça n’est pas le métier de la pertinence de leur proposition, personnes qui auront de fait droit de vie ou de mort sur le patch, quel que soit leur niveau en design.

Nous avons bien sûr évoqué le surplus de pédagogie requis pour faire accepter nos modifications, mais c’est bien au delà de la pédagogie. Certains participants ont fait état de patch design moisissant depuis plus de 5 ans dans des repos, aucun dev ne voulant se donner la peine de les valider ou de les coder, et ce indépendamment des éléments objectifs apportés pour implémenter cette amélioration (études utilisateurs – qui ne conviennent jamais, prototypes – qui ne sont jamais assez codés même s’ils sont fonctionnels, visuels – qui ne sont jamais assez bons ou ne “font pas l’unanimité”).

Bref la croyance qu’un projet n’est rien sans développeur mais passe très bien sans designer est encore bien ancrée.

Déséquilibre des forces

Historiquement initié par des développeurs, les projets open source n’intègrent de fait pas de designers à même de juger les contributions design. Pourtant, de plus en plus de projets open source sont initié par des créatifs (comme la fonderie Velvetyne par exemple), ou orienté sur la création, peut être que ce phénomène va donc s’équilibrer. Il a été évoqué le fait de créer et concevoir des projets, puis de payer des développeurs pour les rendre fonctionnel, pour ensuite libérer le tout.

Une nécessité de pédagogie

Le sujet a été souvent remis sur la table, cette nécessité d’expliquer notre métier sans cesse pour le faire accepter. Le constat est que nous le faisions tous à notre échelle (une créa ne se faisant jamais sans démarche et justification de toute manière), avec des participants qui allaient très loin dans la pédagogie, avec exposition de leur travail au fil de sa réalisation par exemple.

Personnellement, je trouve que la pédagogie est absolument nécessaire, mais qu’il y a un moment où on bascule complètement dans la formation et que ça vient manger tout le temps imparti pour faire un travail donné. Imaginez un designer campé dans le dos d’un développeur, qui poserait des questions simples et ferait des remarques non-éduquées toutes les 15 minutes, même avec toute la pédagogie du monde, à un moment le développeur va devoir se concentrer sur son travail et avancer. C’est la même chose pour les designers. Si nous devons former complètement les gens avec qui nous travaillons, ce serait en dehors de la production, en cours séparés.

Une question d’outils

Il est ressorti des discussions suite à mon billet original que certains libristes voulaient que les contributions apportées à un logiciel libre soient réalisées à l’aide d’un logiciel libre, ce qui est assez problématique en l’absence d’outils graphique de niveau professionnels libres (en plus de la question de l’habitude, il manque des fonctionnalités incontournables).

le non design n’est pas neutre

Nous avons également constaté que beaucoup de projets libres pensent que si le projet n’est pas designé, il va être perçu comme “neutre”, ou “sans design” sans réaliser que toute image présentée au public génère un ressenti, et que dans le cas de quelque chose “non-designé”, cette image peut être négative. Le manque de captures d’écran sur les sites des projets libres a été mis en avant, soulignant que la fonctionnalité prime, sans réaliser que le design est également une fonctionnalité.

Forker comme si demain n’existait pas

La solution du Fork a été évoquée (forker = reprendre le logiciel existant et en faire un projet parallèle, une pratique courante dans le libre), mais ça n’est pas une piste privilégiée , l’idée étant de ne pas faire un truc chacun dans son coin, mais d’aider et de faire avancer les projets qu’on aime bien. Cependant il semble que parfois ce soit la seule solution valable pour avancer sur certains points : installer une identité et une ergonomie, voir si celle-ci est adoptée, et si c’est le cas, que ce fork soit réintégré à l’original.

Conclusion

Une discussion à suivre donc, je pense que malgré la réticence de certains, de plus en plus d’acteurs du libre sont convaincu de la nécessité d’inclure des designers dans leurs projets (comme finalement dans tous les autres secteurs qui nous entourent), reste à gommer les principaux obstacles pour que les designers puissent apporter leur expertise.