Pas sage en Seine, j’y étais passée il y a un paquet d’années, à un moment où c’était en plein coeur de Paris et où Owni existait encore (ça date un peu). Ca m’avait eu l’air plein de gens hyper intéressants mais incompréhensibles.

J’ai gagné quelques niveaux en technique entre temps, et quand j’ai vu le programme, je me suis dit que ça avait l’air bigrement intéressant. Alors j’ai retenté le coup.

Récit d’une moitié de Pas sage en Seine / Hacker Space Festival : Jour 1 (pour moi) - Samedi 2 juillet

NdA : comme ce post est vachement trop long et déroge à toutes les règles les plus élémentaires de la lecture sur Internet, je l’ai scindé en deux. La suite ici.

Avec ethereum, privilégier les dumb contracts ?

Développer un contrat/programme sur Ethereum

Stéphane Bortzmeyer

J’arrive direct en début d’après-midi sur une conférence de @bortzmeyer, sur un des sujets que j’ai le plus vu abordé dans les milieux tech cette année : « Développer un contrat/programme sur Ethereum ».

Je fais justement encore un blocage cognitif sur la blockchain, j’ai donc peur de pas panner grand chose et me dis que c’est idéal pour ne pas me dépayser des sensations ressenties lors de mon premier Pas sage en Seine (sic).

En fait, même si ça a été en partie le cas, j’ai tout de même retiré un paquet d’infos et d’enseignements assez inspirants de cette conférence ; plus particulièrement en matière de bonnes pratiques de développement et de sécurité.

« Vouloir résoudre des bogues en traitant du logiciel, c’est pas toujours une bonne idée. »

Bortzmeyer analyse l’erreur du DAO (bug entrainant la perte de quelque chose comme 50 millions euros) comme étant dû à une trop forte anticipation de problèmes potentiels. En prévoyant trop de cas critiques éventuels et en les corrigeant, les développeurs ont créé malgré eux de nouvelles fragilités dans leur programme.

« Le problème avec le DAO, c’est qu’on a utilisé les mêmes méthodes de productivité que le web », c’est à dire coder vite, beaucoup, en se disant que tant que ça marche dans les grandes lignes, c’est bon. Dans les milieux ultrasécurisés, on écrit au contraire du code hyper simple, hyper lentement. Il aurait selon lui fallu coder, non comme pour un site web, mais comme pour une centrale nucléaire.

C’est aussi peut être lié au côté parfois « cowboy » des devs (et je ne suis pas la dernière à y succomber) : les programmeurs ont tendance à aimer faire du code compliqué, du code d’esthète beau comme du lettrage à la main à la peinture émail, à se la raconter quoi. Or, c’est dans les contrats les plus simples et triviaux qu’il est le plus compliqué d’introduire des bugs.

Quelques éléments de bilan :

  • les contrats sont des programmes informatiques, donc évidemment ils ont des bugs. Réfléchissez toujours avant d’y mettre de l’argent.
  • ce n’est pas pour autant qu’il ne faut pas utiliser les contrats. On utilise bien du javascript ou du PHP, on utilise bien le web (mais le web n’est pas bugué, n’est-ce pas). Il faut juste avoir conscience que les contrats ne sont pas infaillibles
  • ne pas vérifier les condensats peut etre considéré comme une bonne pratique, car trop coûteux en éther
  • Par contre, faut pas pour autant oublier de tester ses codes de retour, hein.

En définitive, pour Bortzmeyer, l’appellation « smart contracts » devrait très avantageusement être remplacée par celle de « dumb contracts ».

Ce n’est pas la première fois que j’entends parler des avantages à coder simple, limite un peu grossier. Plus le temps passe et plus je comprends qu’il n’y a vraiment pas de honte à coder façon « gros sabots » (un peu rustique, mais c’est du solide), et c’est une façon de faire dans laquelle je me retrouve de plus en plus.

Source : http://www.bortzmeyer.org/pas-sage-en-seine-ethereum.html

L’ergonomie, c’est pas que pour les autres

L’ergonomie, indispensable à l’adoption massive du libre

m4dz (Matthias Dugué) / Luc Chaffard

L’intitulé de la conférence qui suit est une affirmation à laquelle j’adhère massivement : « L’ergonomie, indispensable à l’adoption massive du libre ». L’intéret pour moi était donc plutot d’avoir des éléments de diagnostic (pourquoi est-ce que le design peche, dans le libre ?), des pistes de résolution, et voir un peu comment la communauté « hacker / libriste / engagée » (comment on définit la « communauté » de ces festivals, en fait ?) recevait ce genre de discours.

Qu’est-ce que ça donne ?

 » Pour une adoption de masse, il faut rendre le produit accessible au maximum « 

Là-dessus, les deux intervenants, venus de Cozy, prêchent une convaincue. Mais ils enfoncent le clou et insistent, en parlant au sujet du développement de produits open source de « relation egosexuelle », travers par lequel on se retrouve à réaliser un produit pour soi, ses usages, sa communauté. Une manière de rappeler que, lorsqu’on bosse pour de l’open source et qu’on essaye de se positionner en alternative aux GAFA, on a tout intérêt à être accessible au plus grand nombre.

 » Si tout ce qu’on arrive a libérer, c’est que de la ligne de code, et bien on aura perdu. « 

Comment fait-on ? Les méthodes décrites et appliquées par l’équipe de Cozy sont finalement relativement connues, mais c’est souvent pas inutile de rappeler les bonnes pratiques : connaître ses utilisateurs, savoir à qui on s’adresse, et avoir conscience qu’on n’est « qu’un utilisateur parmi d’autres » (et même pas un utilisateur représentatif, vu qu’on connait son produit dans les moindres détails).

La façon dont ils parlent des utilisateurs me donne envie de continuer à développer sur des outils et écrans un peu pourris, basiques, pas rétina pour un sou. Une façon de ne pas trop m’éloigner des conditions matérielles du type de personne pour/avec lesquelles j’ai envie de bosser.

Ca a parlé ensuite pas mal de « se focuser », « user experience », « user centric »… Beaucoup de vocables anglo ou franglo-saxons (c’est le domaine qui veut ça, hein), et notamment des mots que j’avais ces derniers temps principalement vu utilisés pour camoufler des concepts fumeux, et faire passer des idées remplies de vent pour des projets innovants. Je découvre donc que ces mots sont aussi utilisés sans chichi dans la communauté open source. Mes repères anti-bullshit s’effondrent.

En fin d’intervention, un retour sur la distinction entre ergonomie et design : tout le monde pouvant contribuer à la première et donner des conseils pour l’améliorer, le design devant rester entre les mains du designer. Malgré tout, rien n’oblige à suivre strictement les conseils et avis des utilisateurs, et l’intuition reste primordiale (suivant la logique d’un Henri Ford qui aurait dit : « Si j’avais demandé aux gens ce qu’ils voulaient, ils auraient répondu des chevaux plus rapides. »).

« On a besoin de la contribution des utilisateurs, mais notre devoir est de les inspirer à aller plus loin »

Pour finir, une question restée sans réponse, mais des initiatives en cours devraient contribuer à en apporter des bribes : « Est-ce que qu’on peut open sourcer du design ? » Mozilla le tente actuellement avec Mozilla Open Design. A suivre.

A la relecture de mes notes, je me demande : les intervenants ont surtout, il me semble, pointé pour expliquer le retard de l’open source en matière de design, un problème d’ordre « culturel » ( l’« égo-sexualité » ;) ). Ce problème n’est-il propre qu’au milieu open source ? Je dirais que non. N’y a-t-il pas aussi un problème de moyens (les études publics demandent du temps et/ou de l’argent) ?

Et pour retrouver les slides, c’est ici.

Un peu de design tangible libre

Vers un design libre

Christophe André

L’association Entropie promeut le design libre : ils créent des productions originales dont ils proposent ensuite les plans et notices librement, afin que tout un chacun puisse les reproduire. Par exemple, ils proposent sur leur site al notice d’une cariole à sérigraphier (ajout no 67 à ma liste de « projets qui ont l’air trop cool que je ferai quand je prendrai le temps »)

Pour parler de design libre, Christophe André parle de ses destinataires, qui sont voués à être ses producteurs. : le « prosommateur ». Prosommater (?), c’est s’impliquer dans la production de l’objet qu’on veut utiliser. Il cite l’exemple d’une amap où il est possible de « régler » les paniers soit en temps de travail, soit en monnaie sonnante et trébuchante.

Ce qui m’intriguait le plus ici (ce qui m’intrigue en fait de base dans l’open source « et son monde ») est le modèle économique : comment se finance ce type de projet où la production intellectuelle est « donnée » ?

Ici, c’est en définitive le temps de Recherche et Développement qui est financé. Des personnes ou associations ayant des besoins spécifiques sollicitent l’association pour qu’elle produise un outil adapté ; la libération des sources une fois la tâche réalisée fait partie du contrat. Entropie part exclusivement des besoins exprimés, ils ne produisent pas de prototypes par avance en espérant qu’il rencontre une demande.

Parmi les projets similaires cités : l’atelier paysan à Grenoble, qui aide les paysans à produire leur propre outillage (note à moi-même : prendre le temps d’interroger leur modèle éco).

Petit moment de pause, je descends au village associatif et en profite pour louper intégralement sans m’en rendre compte l’intervention sur les cafés vie privée.

A la place, je traîne et discute avec…

PSES+HSF Debout ! Le Syndicat d’Initiatives

Discussions sur le syndicalisme en milieu tech, et les moyens de travailler sur des projets militants et en vivre. Cette question se résume aussi à « Où est le fric ? », et c’est une nouvelle fois la solution de partager son temps entre projets rémunérateurs pour des grands comptes, qui payent le temps passé à bosser sur des projets engagés sans moyens.

FFDN

La présence de la FFDN (fédération qui regroupe les Fournisseurs d’Accès à Internet associatifs) me permet d’identifier mon FAI associatif de référence suite à mon passage du Rhône au Vosges. J’ai donc quitté Illyse pour trouver Lorraine Data Network.

C’est l’occasion aussi de découvrir l’un des derniers projets de la FFDN : la Brique internet, avec du YunoHost dedans. Deuxième fois que j’entends parler de YunoHost en peu de temps, le projet monte dans ma liste des trucs à tester.

Communiquer de façon complexe avec son chauffage

Vers un web décentralisé ?
Pierre-Louis

La première conférence à laquelle j’ai vraiment pas panné grand chose (à part que l’orateur a mené une expérience de contrôle de son chauffage via wifi, et que ça fonctionnait bien et c’était chouette, « jusqu’au moment où j’ai plus eu internet et j’ai eu froid »).

Définitivement, il faut encore que je gagne des points d’administration système.

Parmi les infos que j’ai retenu, en vrac :

  • Pourquoi fait-on principalement des services centralisés ? Parce que c’est faciiiiiiile, pas trop cher, etc.
  • Les dht (decentralized hash table), c’est bien.
  • BitTorrent passe maintenant par MainlineDHT, pour éviter la centralisation des trackers.
  • Zeronet est un mix de BitTorrent et de bitcoin.
  • WebRTC, c’est bien aussi.

Pour lire la suite, c’est là que ça se passe.