Skip to main content

Cool, rejoint les utilisateurs de !

L'alarmisme de Korben

8 min read

Je réagis ici au dernier article de Kroben sur la stratégie de Samsung en matière d'objets connectés.

Globalement, je suis d'accord avec ce qui y est dit, dans le sens où je m'inquiète également des questions que posent cette sur-connexion à venir de notre quotidien. Mais ce que je trouve malheureux dans cette article, c'est son aspect exclusivement alarmiste.

Mettre en évidence un problème, c'est bien. Ça permet de sensibiliser les gens, et c'est une première étape nécessaire. Mais c'est loin d'être la seule : il y a beaucoup de questions que l'on peut se poser.

On a répondu à « Que ce passe-t-il ? » et « De quel futur sont-ce les prémisses ? ». Qu'en est-il de « Pourquoi en est-on ici ? » ou encore « Comment exploiter à notre avantage cette évolution nécessaire ? », « Que peut-on faire pour ou contre ? », « Quelles sont les différentes réactions que l'on va probablement observer ? ». Et le pluriel est important ici : Korben ne parle que de la réaction ovine probable d'une certaine majorité de gens, mais il s'adresse justement à une autre communauté : celle des hackeurs et activistes.

Il énonce ces fait dans le but de faire réagir, mais ne suggère aucune façon de réagir. C'est dommage. Je suis même attristé de voir des phrases comme celles-ci :

On ne pourra pas y échapper. Et je suis certain qu'on fera les mêmes erreurs qu'on a faites avec Facebook, Gmail, le cloud...

Et quitte à être pessimiste quant à nos chances de changer ces choses, autant relativiser les problèmes que cela pose. Je reprends certains exemples qui ne me semblent pas si dramatiques.

Si votre maison consomme trop, peut être serez-vous plus taxé par le gouvernement. Si votre bracelet connecté montre que vous pétez le feu alors que vous êtes en arrêt maladie, peut être que la SECU viendra vous contrôler.

N'est-ce pas une bonne chose que, par l'intermédiaire de « taxes carbone », l'État incite à l'entretien et au renouvellement des infrastructures du pays ? Son application en devient plus aisée car automatisée, mais l'esprit de la loi reste inchangé. Et n'est-il pas important pour la bonne marche de notre cher système de santé de faire la chasse aux abus ? Que l'on défende ou non ce système n'est pas la question, mais l'outil numérique offre un moyen de le rendre plus cohérent vis à vis de son objectif originel.

Là encore, l'article ne pose pas assez de questions. On peut se demander « Comment la fraude va-t-elle évoluer ? », car elle ne va pas disparaître comme ça. Ou encore « Quels sont les risques de mauvais emploi et d'abus de ces outils, que ce soit par les utilisateurs ou par les institutions ? », puis « Comment les éviter ? ».

Et si l'effet wow a si bien fonctionné lors de la présentation de Samsung, c'est qu'il y a tout de même des aspects souhaitables à cet avenir proposé. Une nouvelle question est donc « Comment obtenir ces mêmes aspects souhaitables sans permettre les mauvais usages crains ? ». On peut se demander « Quelle alternative proposer à ceux qui veulent ces outils ? » et donc « À quel besoin répondent ces produits ? »

Reprenons les exemples :

On peut par exemple supposer qu'une assurance santé vous fasse payer un supplément parce que vous ne faites pas assez de sport.

Est-ce que pousser les gens à faire du sport est un mal en soi ? D'autant plus que c'est une action motivée par la volonté d'améliorer la santé des gens, même si cette volonté est, elle, motivée par les considérations purement financières de boîtes privées.

Ou on peut imaginer une assurance auto qui vous fera cracher plus d'argent parce qu'avant d'avoir eu cet accrochage en voiture, vous avez regardé un film super tard la veille ce qui a joué sur votre capacité d'attention ou tout simplement parce que vous conduisez comme une brute.

Encore une fois, si on nous oblige à être assuré pour rouler, c'est justement pour éviter que les gens roulent mal. Le but profond est préventif. Il ne s'agit pas seulement de permettre d'être remboursé en cas de pépin. Donc oui, je suis pour le fait que les gens conduisant comme des brutes paient plus. Après, ils pèsent le pour et le contre et décident de conduire quand même comme des brutes s'ils le veulent, mais je ne vois pas de problème majeur au fait de vouloir influencer le choix vers une conduite calme.

Peut être que si vous restez trop longtemps sous la douche ou que vous laissez la lumière allumée quand vous n'êtes pas là, vous serez classé dans la catégorie des pollueurs-payeurs et vos impôts augmenteront...

Je ne vais pas refaire le même commentaire que pour les citations précédentes…

Plus subtile :

Ou peut être qu'on vous dira "Non, tu restes chez toi et tu prends le bus suivant car ton travail est moins important que celui des autres gens qui eux doivent arriver à l'heure".

Déjà, l'accès aux transports en commun ne peut pas être uniforme. Les lignes sont tracées par rapport à une certaines demande et certains en sont donc isolés. La position géographique est un critère, alors pourquoi pas un autre ? Ok, le risque là est de discriminer par classe sociale, et je trouve ça plus dangereux, quoi que ça reste un avis très personnel, mais ce n'est pas une nécessité.

D'autre part, j'insiste encore une fois sur le fait que les données sont un outil. Recueillir des données ne peut rien interdire. Ce peut être utilisé pour savoir si la personne fait quelque chose d'interdit, mais pas imposer de contrainte physique, ni changer la nature de ce qui est interdit. Donc si on ne pratique pas ce type de discrimination sociale aujourd'hui, il n'y a pas, a priori, de raison pour qu'on le fasse avec des objets connectés.

En fait, ces mauvais exemples desservent la cause d'origine, noyant les bons exemples.

Peut être que si vous acceptez de vous faire couper automatiquement le courant par EDF lors des pics de consommation, vous serez dans le noir mais vous aurez une réduction sur la facture.

Là c'est plus embêtant, et je suppose que c'est une référence au compteur Linky. Mais ce qui est plus embêtant n'a en fait rien à voir avec le fait d'avoir un compteur connecté. C'est la position de contrôle total dans laquelle se situe E(R)DF qui est en cause et la connexion ou non du compteur n'y change rien. Encore une fois, il serait intéressant de parler des possibles alternatives, de ce que la communauté fait de ces faits. Dans ce cas précis, je pense à CitizenWatt, compteur à la réalisation duquel je participe personnellement, mais je suppose que dans les autres cas on peut également trouver des projets allant dans le sens d'une connexion sans pour autant être accompagné par des situations d'égémonie de certains intérêts privés.

En fait, le seul réel danger mis en avant dans l'article est celui du bubbling. Il faut effectivement, je pense, faire attention à conserver une certaine diversité dans les idées auxquelles nous commes confrontés afins de se faire une opinion suffisemment objective et les mécanismes de suggestion automatique ont des effets pervers de ce point de vue. Mais ce n'est pas le fait de suggérer sur la base de données personnelles qui pose problème. C'est plutôt la façon dont sont faite les suggestions. On peut très bien imaginer un algorithme de suggestion dont le but serait justement de présenter de la façon le plus égale possible les différents point de vue, corrigeant automatiquement les tendances naturelles de l'utilisateur au bubbling.

Bref, au mieux, c'est de la démagogie maladroite ; au pire c'est un manque de combativité un peu décevant.


PS : Je ne savais pas ou le mettre, mais je trouve le climat de diabolisation assez systématique des entreprises et de l'État contestable. Je suis bien d'accord : les intérêts financiers et la centralisation, publique ou privée, posent un nombre incalculable de problèmes. Mais ce sont lesdits problèmes qu'il faut signaler, et non une de leurs causes.

AngularJS vs Ember - Evil Trout's Blog

Une défense d'Ember face à Angular mettant en évidence des points assez subtiles à prendre en compte dans le choix d'un tel framework.

Le problème vient à mon avis du système de permission proposé. Comme l'article le signale, le plus embêtant est que les développeurs piochent dans les permissions juste parce qu'elles sont là, devant eux, et que personne ne regarde s'ils en mangent. Il n'ont donc aucune raison d'avoir des scrupules.

Et si personne ne les regarde, c'est parce que les gens n'ont pas le choix : ou bien ils acceptent toutes les conditions, ou bien ils se privent de l'application. Il n'y a aucun débat, aucune possibilité de compromis.

Ce serait pourtant très simple, techniquement, d'inclure dans le système la possibilité à l'utilisateur de fournir à loisir de fausses données (position approximative, répertoire vide, etc.), lui laissant le choix de sacrifier certaines fonctionnalités de l'application au profit de sa vie priver. Ou plutôt, dans les cas cités ici, de ne rien sacrifier du tout, mais de protéger sa vie privée…

Des nouvelles de Freeder

7 min read

Initialement annoncé par Phyks suite à un état des lieux des lecteurs web de flux existant, il vit une première phase de développement assez rapide consistant à reproduire les fonctionalités de base de tout lecteur de flux qui se respecte : comprendre les formats Atom/RSS, gérer une liste de flux, lire confortablement les articles.

Les trois développeurs — Phyks, tmos et moi-même — utilisaient tous Leed, avec le thème Greeder de tmos et les premiers pas de Freeder sont donc naturellement fait en suivant Leed. Le thème par défaut alors utilisé n'est d'ailleurs autre qu'une version revisitée de Greeder par son auteur.

La répartition des tâches s'est faite assez naturellement : tmos adaptait et faisait évoluer Greeder, Phyks travaillait sur les fonctions les plus algorithmiques ou les plus fondamentales et j'organisais l'ensemble du code et réfléchissait au design du projet. Les frontières n'étaient bien sûr pas hermétiques mais c'était une bonne façon de séparer le travail.

Le projet bénéficie également dès ses débuts de la sympathie et des conseils de Marien Fressinaud, développeur de FreshRSS, nous aidant notamment dans notre recherche d'efficacité en général, point tenant particulièrement à cœur à Phyks.

Le premier objectif, chronologiquement, était d'assurer les fonctions de base afin de pouvoir utiliser Freeder au quotidien pour notre usage personnel. Cet usage personnel est en effet la principale source d'objectifs dans le projet, puisque c'est lui qui révèle les problèmes, les limitations, les manques ressentis.

Il est cependant important de noter que l'un des objectifs phares est de créer un programme accessible à un maximum de personnes, aussi bien à l'usage qu'à l'installation, notamment pour un administrateur débutant ou ne bénéficiant que d'un hébergement limité. Donc bien que le choix des fonctionnalités soient motivés par nos besoins personnels, leur mise en place doit toujours être compatible avec un maximum de configurations.

C'est pour cette raison que le projet utilise PHP et que l'on soigne la procédure d'installation pour la rendre la plus simple possible, bien que nous ne l'exécutions quasiment jamais pour nous. Wordpress est un bon exemple de ce que l'on entend par simple à installer.

C'est ainsi que dans le courant du mois de septembre, nous avons tous les trois migré définitivement vers Freeder. En fait, les deux mois de développement précédents n'ont pas été uniquement consacrés aux fonctions de base, c'est pourquoi lesdites fonctions ont été jugées finies un peu plus tard que prévu. Nous n'avons pas pu nous empêcher — et ce n'est pas une mauvaise chose, si ce n'est pour les gens qui atendent une version étiquetée 1.0 — de commencer en parallèle à penser à la suite.

Cette adoption a été suivie de peu par une stabilisation de la branche master et la migration du développement actif et potentiellement cassant sur la branche dev. À défaut de sortir une version 1.0 que l'on souhaite suffisemment complète, nous souhaitions tout de même pouvoir proposer aux gens nous suivant une version relativement stable et dont la mise à jour serait assurée proprement.

En pratique, on a tout simplement arrêté de développer quoi que ce soit d'autre que des bugs vraiment handicapants sur master. Ce n'était pas un mauvais choix, mais selon moi on ne l'a pas suffisemment suivi : on a continué de travailler exactement comme avant, mais sur la branche dev, avec pour seule conséquence que plus aucune activité ne s'affiche dans les stats de GitHub

Le développement ne s'en est pas moins arrêté, mais était cependant un peu ralenti par la reprise des cours et autres de chacun et consistait principalement à résoudre localement les problèmes que l'on trouvait ou à arrondir les coins en vue de fournir une version, sinon contenant toutes les fonctionalités que l'on ambitionne à terme pour Freeder, n'ayant pas de manque explicite, de lien mort ou autre. Bref, un truc pouvant prétendre être fini.

Une fois encore, nous avons été impatients de nous lancer dans une nouvelle voie, dans un refactoring vers une version 2 avant même d'avoir une version 1. N'ayant que peu d'utilisateurs, nous pouvons nous permettre ce genre de choix et ce serait finalement un frein inutile que de s'interdire d'en profiter.

C'est pourquoi, après avoir créé un nouveau thème alternatif à Greeder, nous travaillons désormais sur une version techniquement très nouvelle, basée sur un modèle Webapp + API.

L'API est indispensable pour pouvoir faire communiquer Freeder avec d'autres programmes. C'est loin d'être suite à une quelconque réaction à un effet de mode que l'on a choisi ce modèle : c'est encore une fois car nos usages ont montré dans le cas de d'autres programmes comme Known, pour n'en citer qu'un, que cet outil de dialogue de programme à programme s'avère très pratique !

Techniquement, nous avons troqué RainTPL, moteur de template très simple qui était jusqu'ici notre seule dépendance, pour un jeu plus étendu de bibliothèques :

  • slim, pour gérer le routage des URLs depuis PHP directement (en non via Apache) et donc les rendre plus dynamique. C'est surtout utilisé pour l'API.

  • Redbean, un ORM en PHP pour bases de données SQL. Il permet de manipuler les objets venant de la base de données directement sous la forme d'objets PHP, ce qui facilite grandement la maintenance du code, au prix de (très lègères) pertes de performances.

    Phyks l'a comparé à FluentPDO, NotORM, Propel et Doctrine. Redbeam a été choisi pour sa souplesse, sa simplicité d'utilisation et la réactivité de son auteur.

  • mf2, pour parser des flux au format h-feed et s'intégrer avec ce que développe IndieWebCamp.

  • zebra_curl, qui permet de faire des requêtes HTTP en parallèle et de manière asynchrone. Il remplace notre wrapper fait maison de cURL. Phyks a aussi testé guzzle mais l'a trouvé surdimensionné pour notre utilisation.

Note de Phyks :

Je ne suis cependant pas satisfait pleinement par zebra_cURL et ça risque d'évoluer dans le futur. L'auteur ne la maintient plus vraiment, et elle ne gère pas tout ce dont on a besoin (par exemple le fallback sur un téléchargement séquentiel, sans cURL, si celui-ci n'est pas activé sur l'hébergement considéré). Un autre grave problème qu'elle a est qu'elle ne gère pas les problèmes de CURL_FOLLOW_LOCATION avec open_basedir activé, cf http://slopjong.de/2012/03/31/curl-follow-locations-with-safe_mode-enabled-or-open_basedir-set/.

On a donc deux choix pour le futur : la forker, ou en prendre une autre. Le code de Known a l'air pas mal sur ce point, à regarder.

Ces briques sont assemblées pour déjà fournir le gros de l'API, et nous allons donc commencer à adapter le thème pour en faire une vraie webapp. Nous ne sommes cependant pas complètement fixé sur la façon de la faire. La question qui se pose en ce moment est de savoir comment servir la webapp. Une page unique contenant absolument toute l'application ? Ça permet une utilisation hors connexion, mais ça rend tout de même le premier chargement lourd. Et une webapp oblige l'usage du JS : on ne peut pas envisager de lire ses flux, même dans une version dégradée, avec links par exemple.

Voilà pour le premier point sur Freeder, je tâcherai d'en faire d'autres régulièrement !

Demander à un ami ou à Wikipedia

2 min read

Il m'arrive souvent de poser spontanément une question — qu'elle soit technique, culturelle ou je-ne-sais quoi d'autre — à un ami, ou plus généralement à un être humain, alors qu'un bon moteur de recherche me répondrait plus vite et plus sûrement.

Assez souvent, la réponse est en fait les résultats de sa propre recherche via un robot, donc ça peut donc sembler assez inutile, mais en y réfléchissant, le moteur de recherche est bien loin de remplacer l'humain dans l'accès à l'information.

Demander à une personne permet de lui indiquer ce sur quoi je suis en train de travailler sur le moment. Cela lui permet de savoir que si un jour il a des questions à ce sujet, je m'y suis intéressé et suis donc suceptible d'amener des réponses plus précises qu'un robot.

Cette personne peut également, en rencontrant par la suite une autre personne posant des questions sur le même sujet, nous mettre en relation. Alors qu'à ma connaissance même Google ne cherche pas à rapprocher les gens dont les recherches sont similaires. Ils auraient pu envisager de le faire avec Google+, mais finalement les gens utilisent ce type de réseau social comme extension de leur vie sociale réelle et non pour y rencontrer de nouvelles personnes.

Et enfin, si la personne connaît vraiment bien le domaine sur lequel porte la question, elle peut donner un exposé bien plus vivant et adapté à la personne à laquelle elle le fait que celui d'un page Wikipedia. Là encore, les robots ne le font pas, mais ils pourraient. Il serait intéressant de voir un robot qui explique de façon intéractive un sujet. Ou même un robot qui débat d'un sujet, prenant une position partiale opposée à celle qu'il sait être celle de son interlocuteur.

L'accès à l'information reste donc très humain, d'autant plus que les moteurs de recherche mênent toujours vers des textes écrits par des doigts sur un clavier. On commence cependant à voir des initiatives apparaître, comme Echo (développé par HP Labs) qui peuvent extraire les idées d'un corpus de texte, mais aussi le sentiment de leurs rédacteurs, et ça fait un certain temps que les gens s'échinent à coder des chatbots.

Google se rend petit à petit incontournable avec beaucoup de flegme : Il a besoin du reste du web pour créer du contenu, ce qu'il ne sait pas faire (contrairement à Facebook ou Twitter), mais aimerait que tout soit faisable sans sortir de chez lui…

Importance du contenu dans une interface — Gnome HIG

2 min read

Applications typically present content, whether it is images, text, messages or more complex data. It is this content that your users will be interested in, and too many controls or user interface elements will distract from the focus of their attention.

Ce point des recommandations ergonomiques de Gnome insiste sur le fait que l'élément central d'un programme est le contenu manipulé.

Si dans le cadre du design de page web il est assez clair que le point clef est le contenu, et donc le confort de « lecture » (de texte, d'image, etc.) — expliquant la mode des styles très épurés — c'est moins évident pour les programmes en général.

La force initiale de l'informatique réside dans sa capacité de calcul. A priori, rien ne dit donc qu'un programme doit être centré sur du contenu. Au contraire même, on pourrait voir le contenu comme un exemple, un simple cas particulier de ce que le programme et sa troupe d'algorithmes peuvent faire, et focaliser l'attention de l'utilisateur sur toutes les compétences générales de la machine.

Du point de vue du développeur, la généralité des algorithmes est effetcivement un point capital : ne sachant à quel contenu il sera appliqué, il doit prévoir tous les cas. Chaque fonctionnalités est une nouvelle œuvre et mérite sa place dans les rayonnages de l'interface avec l'utilisateur.

Sauf que l'utilisateur se fiche du cas général. Pour l'utilisateur, le programme est un outil. Il ne l'utilise que dans le but de traiter un certain contenu, que ce soit pour le lire, le construire, l'altérer, le dupliquer, etc. L'utilisateur peut changer de programme, mais pas changer de contenu.

Ce qu'il faut montrer à l'utlisateur, c'est en priorité ce qu'il est en train de manipuler, et non ce avec quoi il est en train de le manipuler.