ParisWeb 2015 - Jour 2

Deuxième jour de ParisWeb. La conclusion de mon CR précédent était un peu négative, mais cette deuxième journée m'a redonné la pêche et l'envie de faire de belles choses.

Digital Death and Digital afterlife

On commence par un sujet sérieux, celui de la mort dans le monde digital. Qu'arrive-t'il à notre avatar, notre présence en ligne une fois que nous sommes morts ? Tout le monde ici finira par mourir un jour, pourtant assez peu ont déjà écrit leur testament et encore moins ont pensé à ce qu'il arrivera à tous leurs comptes (Facebook, Google, Dropbox, etc) une fois qu'ils ne seront plus là.

Si on fait un rapide calcul, au vu de l'espérance de vie moyenne et du nombre de personnes sur Facebook, on a 10.000 personnes sur Facebook qui meurent chaque jour. C'est à dire qu'aujourd'hui, un compte sur 30 sur Facebook est un compte d'une personne décédée. Peut-être que dans votre friendlist, vous avez des personnes décédées mais vous ne le savez pas vous-même. Surtout que si on continue sur cette lancée, on devrait avoir sur Facebook plus de morts que de vivants d'ici 2065 ou 2100. Creepy, non ?

La mort peut toucher n'importe qui à n'importe quel age. Un accident, une fausse manœuvre et vous disparaissez, vous laissez derrière vous votre famille et vos amis et votre présence en ligne.

Nous sommes une génération numérique. Notre vie se trouve sur nos smartphones, laptops et dans le cloud. On n'envoie plus de cartes postales, on ne garde plus de photos papier de nous ou de nos amis, tout est dématérialisé. Notre famille ne peut donc pas se rattacher à des éléments matériels pour se souvenir de nous, il leur faut notre présence en ligne. Mais laisser ses comptes actifs alors que nous sommes morts, n'est-ce pas un peu morbide ?

Surtout quand ces comptes continuent d'agir comme s'ils étaient actif. Quand Facebook vous rappelle l'anniversaire d'un proche décédé, ou qu'il apparait toujours dans la liste de vos destinataires.

Certains services ont commencé à gérer ce problème. Facebook permet de transformer la page d'un membre décédé en mémorial, pour qu'elle reste toujours là, mais qu'on comprenne que la personne n'est plus. Il faut pour cela qu'un membre de la famille fasse une demande, avec quelques preuves (carte d'identité et certificat de décès par exemple). Il est aussi possible sur Facebook de faire la configuration de son compte post-mortem de manière pro active. C'est à dire qu'on définit ce qui doit arriver quand on meurt. Est-ce qu'on supprime le compte ? Est-ce qu'on en passe l'ownership à quelqu'un d'autre ? Et si oui, avec quels droits ?

La question est intéressante, car on ne souhaite pas forcément que notre vie privée de notre vivant devienne publique, même à notre famille ou nos amis, une fois mort. Notre historique de mails, nos comptes bancaires, nos messages privés, etc.

Certains services comme FB et Google permettent de prévoir un moyen de vérification de si vous êtes vivant, en vous envoyant un mail tous les 3 mois en vous demandant d'y répondre. Si vous n'y répondez pas, c'est sans doute que vous êtes mort... Sauf qu'il peut y avoir plein de raisons de ne pas pouvoir s'identifier sur Google pendant 3 mois: un voyage dans un pays sans Internet, une hospitalisation longue, un séjour un prison. Et on n'a pas envie de dire au monde que l'on est mort quand ce n'est pas le cas.

Du coup, plusieurs sociétés tentent de résoudre ce problème, comme Eter9 qui dit être en mesure de continuer à faire vivre vos comptes en ligne même après votre mort grâce à une IA qui a réussit à apprendre vos patterns de posts durant votre vie. On commence à toucher à des questions philosophiques: si une machine est en mesure de répliquer de manière invisible notre présence en ligne, sommes-nous réellement mort en ligne ?

D'autres sociétés comme SecureSafe permettent de stocker tous les mots de passe utile de notre vie numérique pour les passer à qui vous le souhaitez une fois mort. Perpetu quand à lui permet d'envoyer un message à des proches ou des réseaux sociaux une fois décédé. Mais toutes ces sociétés sont encore très jeunes, et il y a de fortes chances que ce soit elles qui meurent avant nous.

La question est très intéressante et me fait réfléchir sur le sujet. Je voudrais que mon décès soit quelque chose d'assez simple à gérer par mes proches, mais en même temps je ne me vois pas donner mes mots de passe d'accès à mes services personnels à quiconque, pas même à un coffre-fort numérique. Il va me falloir penser à une solution à ça !

La veille techno pour les vieux croutons

Thibault Jouannic nous a parlé, dans une conférence très drôle, de la veille technologique. Le sujet m'intéressait énormément, surtout sur la manière de continuer à faire de la veille dans le temps dans un milieu qui évolue aussi rapidement que le notre.

On voit souvent des directeurs techniques qui étaient sans doute très bons à l'époque où ils ont été nommés à ce poste, mais qui ne se sont pas tenus à jour depuis et qui sont simplement dépassés aujourd'hui. Le monde du développement web évolue extrêmement rapidement. J'ai même l'impression qu'il évolue aujourd'hui encore plus vite que quand j'ai commencé, mais c'est peut-être simplement moi qui vieillit, ou qui m'intéresse à plus de choses.

Pour rester à jour, il faut apprendre à changer, ne pas avoir peur d'apprendre de nouveaux outils, de changer ses habitudes ou ses méthodologies. Parfois, cela nous fait culpabiliser parce qu'on voit des tas de gens plus doués que nous, qui donnent des conférences sur des sujets à la pointe comme si ça paraissait naturel (oui, je pense à toi Christophe.

La clé numéro une à une bonne veille technologique durable dans le temps c'est de commencer par ne pas avoir honte de ne pas tout connaitre. Certes, au début quand une nouvelle techno sortait, on avait envie de la tester tout de suite le soir ou le week-end et cela nous amusait. Aujourd'hui avec un nouveau framework JS par semaine et un nouveau task runner tous les mois, c'est difficile de rester enthousiaste à l'idée de tout apprendre à chaque fois.

Si on commence à se forcer dans cet état d'esprit, on fini par en être dégouté et la veille techno devient une corvée, chronophage et pénible. Pour éviter de tomber dans ce travers, il suffit de moins culpabiliser. Inutile de tout apprendre, on peut filtrer ce qui est nécessaire, laisser quelques mois à une techno pour savoir si elle vaut le coup qu'on s'y investisse, discuter avec d'autres personnes qui l'ont utilisée réellement sur des projets, prendre des feedbacks et en discuter.

Inutile de continuer à faire des side projects tous les soirs et week-ends, ce ne sont pas des conditions réelles de vrai projet qu'on mènera à bien. Il peut être plus intéressant simplement de discuter avec d'autres personnes pour savoir quel framework est utile dans quel contexte.

Good Robot, Bad Robot

François Hodierne, qui bosse à EyeEm à Berlin nous a ensuite parlé des robots (ceux qui viennent faire des hits sur vos sites de manière automatique). Il existe en ce sens plusieurs types de robots.

On a les bons robots, ceux de Google, Yahoo et compagnie qui scannent votre site pour l'indexer. Idem, on a Twitter qui vient chopper un aperçu de la page quand on partage un lien, ou encore les lecteurs de flux RSS, Pingdom, Pocket, etc. Tout ces services ont besoin de venir faire des hits sur votre serveur, et vous avez besoin de ces services, donc vous devez les laisser passer.

Coté Bad Robots, on a tous les robots qui cherchent à poster des commentaires de spam, de bruteforcer l'entrée à votre interface d'admin, de scrapper vos pages pour les afficher ailleurs ou encore de scanner les vulnérabilités de la version de votre CMS. On a aussi un gros nombre de bots d'arnaque à la publicité, de robots qui viennent scanner vos pages pour simuler des affichages de publicité.

Après, on a des robots bizarres. On ne sait pas trop ce qu'ils font là. Ils n'ont pas de User-Agent, ou des valeurs étranges (comme "Library foo v0.12"), des robots qui semblent être des bots de Google, mais qui indexent toujours les mêmes pages. Certains sont des restes de scripts buggués, ou oubliés.

D'après le speaker, la proportion de hits sur un serveur est entre 60 et 80% d'origine automatique, ce qui me semble énorme. L'avantage c'est que les bons robots suivent les robots.txt, les metatags et les sitemaps. Les autres font un peu n'importe quoi.

Histoire de les trier facilement, on peut regarder son IP et tester l'IP avec des API qui existent pour voir si elle est déjà enregistrée sur Spamhaus, ou sur le Project Honey Pot. Il existe des listes blanches officielles des IP des Google bots par exemple.

Il semble aussi possible de checker la cohérence des headers entre eux, vérifier que telle version de browser envoie bien, (avec les bonnes virgules au bon endroit) les bons headers, et si non considérer que c'est suspicieux.

Content Security Policy

Troisième mini conférence de la matinée, cette fois-ci Nicolas Hoffman nous parle des CSP, Content Security Policy qui permettent au serveur d'envoyer des directives dans les headers, indiquant au browser ce qu'il a le droit de charger et depuis où.

Ça fonctionne selon un principe de whitelist, où, pour les scripts et les CSS on indique la liste exhaustive des serveurs source autorisés (il est possible d'utiliser des wildcards). Selon les types il est aussi possible d'autoriser certaines notations ou pas. Par exemple interdire les styles inline en CSS ou les onclick en JavaScript.

Ce sont en fait tous les vecteurs qui peuvent être utilisés pour trouver des failles de sécurité, que le serveur envoie au browser pour lui dire de les bloquer. Si jamais le browser les trouve, il bloque complètement le téléchargement ou l'exécution. Cela permet d'avoir un genre de linter hardcore qui bloque complètement si jamais les règles ne sont pas suivies.

Les erreurs sont affichées dans la console, mais il est aussi possible d'indiquer une url sur le serveur vers laquelle elles peuvent être envoyées. Il est aussi possible de l'activer en mode report only, où rien n'est bloqué mais où les erreurs sont encore envoyées.

ES6

Matthieu Lux, alias @Swiip, nous parle de ES6 en nous expliquant les nouveautés de cette nouvelle version, et surtout qu'on peut commencer à l'utiliser dès maintenant grâce à Babel (anciennement 6to5, un extraordinaire outil d'à peine 1 an).

Tout d'abord, on oublie les var en ES6. On a à la place les const, qui sont des var en read-only (et on se rends compte en les utilisant qu'on a vraiment rarement besoin de modifier la valeur d'une variable). Mais aussi les let, qui sont comme des var, mais scopées au block (if, for, ...) au lieu de n'être scopée qu'à la fonction.

Niveau strings, on a maintenant le backtick comme délimiteur, qui permet de faire du multiline et de l'interpolation de variable avec la syntaxe ${foo}. C'est tout con, mais ça va nous éviter de rajouter des + partout tout le temps pour faire du multiline et ajouter des variables dans nos textes.

Tout ça c'est surtout du sucre syntaxique, et dans le même genre on a aussi les keyword class et extends qui font leur entrée et permettent de définir des classes de manière nettement plus lisible. En terme de feature, ça n'apporte rien aux classes qu'on utilisait déjà, mais ça nous évite de devoir définir une fonction pour ensuite modifier son prototype.

Hérité de CoffeeScript on récupère aussi les fat arrows (=>) qui permettent de simplifier l'écriture d'un fonction tout en gardant le scope de this dans l'affaire. Plus besoin de mettre des .bind(this) partout.

On attaque ensuite les features un peu plus poussées et aussi beaucoup plus utiles, comme import et export. ES6 fournit un moyen natif de faire des exports depuis ses modules. Autre sucre syntaxique déjà bien connu des rubyistes, on peut définir plusieurs retours et les attribuer en une seule fois:

let [a, b] = [1, 2]; // a === 1; b === 2
let {user: x} = {user: 3} // x === 3

On a aussi l'arrivée des générateurs, qui sont des fonctions définies avec un * à la fin, dont l'exécution peut être stoppée avec yield, puis reprise avec next. Il est même possible de passer une valeur à next pour reprendre l'exécution avec de nouvelles entrées. La structure étant encore jeune dans ma tête, les cas d'usages ne me sautent pas encore bien aux yeux mais cela semble quand même très puisant, surtout cumulé à des promesses pour pouvoir écrire de manière linéaire un ensemble de calls asynchrones.

Vendez votre méthodologie

Retour dans le grand amphi ensuite où j'ai assisté à une présentation d'un designer. Même si nous n'avons pas le même cœur de métier, les propos étaient néanmoins intéressants et tout à fait applicables à d'autres professions.

Celui-ci nous explique que même si on fait du très bon travail, il arrive que notre client ne soit pas satisfait, qu'il ait l'impression qu'on ne se soit pas foulé et qu'on lui demande beaucoup d'argent pour pas grand chose.

Là dessus, il insiste sur le fait que nous ne vendons pas une réalisation finale, mais surtout une méthodologie qui nous amène à ce résultat. Par définition notre client ne connait pas notre métier (s'il le connaissait, il le ferait lui-même et ne ferait pas appel à nous), nous nous devons donc d'être pédagogue et de lui expliquer ce que nous faisons.

Dans beaucoup d'industries, la formule de fabrication du produit fini est cachée (Nutella, Coca-Cola), alors que dans notre métier, nous nous devons de montrer comment les choses fonctionnent. La curiosité de savoir comment les choses sont fabriquées est quasi-universelle, on aime tous regarder les making-of, presque plus que regarder l'œuvre elle-même. Nous avons envie de savoir quels ont été les obstacles, les solutions, les moments forts de la création. Et c'est cela que nous nous devons de retranscrire à nos clients.

Si nous ne le faisons pas, nous risquons de nous heurter à des jugements purement subjectifs du type j'aime bien, j'aime pas (sans doute beaucoup plus vrai en design qu'en dev), alors qu'en leur donnant des clés pour comprendre le parcours qui nous a amené à notre objectif, à la fois nous les éduquons, et nous les faisons jouer selon nos règles.

Les clients aiment être guidés, mais ils aiment aussi savoir qu'ils en ont pour leur argent. Instinctivement ils préfèreront quelque chose qui leur semble avoir demandé plus de travail que quelque chose qui leur semble trop simple. Un design rempli d'effets photoshop (glossy, lens flare, etc) pourrait sembler à ces yeux non avertis comme quelque chose de riche, alors qu'un design sombre et épuré, ne gardant que l'essentiel leur semblera bâclé. Il est donc important de leur montrer à quel point le travail de simplification est loin d'être facile, mais surtout qu'il va dans le sens de leur demande.

Si nous parvenons à être assez pédagogue le client ressortira en ayant appris un morceau de notre métier. À nous d'aller à son rythme, en lui expliquant ce qu'il ne comprends pas, en lui montrant les différentes étapes. Il appréciera d'autant plus le résultat final s'il voit les différentes étapes de conception et qu'il s'approprie les contraintes et les solutions trouvées.

Nous ne sommes pas des magiciens, qui faisons des choses extraordinaires sans expliquer comment. Nous faisons des choses qui semblent simple, en expliquant à quel point cela est complexe.

Le designer qui murmurait à l'oreille des ordinateurs

Thierry Michel, de EPIC, nous a ensuite fait un petit cours de ligne de commande à destination des designers. À en croire ses exemples, tous les designers sont sous Mac d'ailleurs.

Il a montré certaines des commandes de base (cd, pwd, ls, rm), mais en mettant surtout l'accent sur le plus haut degré de configuration que permet l'édition de fichiers textes que les GUI. Il a aussi précisé que certaines taches sont bien plus rapides en ligne de commande qu'avec un GUI (le téléchargement de gros fichiers avec wget ou le déploiement avec ssh par exemple).

J'étais clairement pas la cible de ce talk, mais je me disais que je pourrais peut-être comprendre ce qui faisait peur aux designers dans la ligne de commande. J'en sors pas avec beaucoup plus d'arguments qu'avant (mais en même temps, je ne cherchais pas à convaincre des designers de passer à la ligne de commande).

Découper son application, pourquoi, comment?

On a ensuite eu un REX de Blablacar dans leur passage d'une appli monolithique à un ensemble de microservices. Les REX, c'est toujours intéressant.

Benjamin et Olivier, l'un dev et l'autre ops nous racontent ça vu depuis l'intérieur. Ils sont passés d'une grosse appli Symfony (qui est déjà la v3) en mode spaghetti (400.000 LOC, 30.000 commits) à un ensemble de microservices.

Enfin, pas vraiment en fait, ils sont en train de le faire. Ils ont réussi à développer l'une des nouvelles features (les avis), dans un service à part, avec une équipe pluri-disciplinaire dédiée. Celle-ci travaille à la fois avec l'ancienne codebase et la nouvelle (ce qui évite que des gens se sentent "punis" en travaillant sur le legacy alors que d'autres s'amusent avec un environnement neuf).

Ils ne crachent pas sur le monolithique pour autant, celui-ci à ses avantages. Notamment parce qu'on est obligé de passer par là quand on débute. Il n'y a aucun intéret à tout découper en petits services quand la société démarre, vu qu'on ne sait pas encore où on va, tout découpage que l'on fera sera sans doute très mal découpé. Une seule appli est aussi plus facile à comprendre pour un nouveau membre de l'équipe, et plus simple à déployer.

Néanmoins, une grosse codebase créé aussi des conflits git incessants, des MEP longues (et par conséquent des hotfix longs à déployer). La maintenabilité est mauvaise et ne fait qu'empirer avec le temps. Le code mort prolifère, mais est virtuellement indétectable (les effets de bord d'une simple ligne de code dans une feature à un extrême peut avoir des implications sur une feature de l'autre coté, sans que cela soit détectable). Au final, coté équipe, on se retrouve aussi avec des gens qui touchent à toutes les features, mais sans qu'il n'y ait réellement d'expert sur quelque chose.

Avec leur passage à l'international récent, le passage à des microservices est devenu une question capitale pour Blablacar. Pouvoir déployer des bouts d'appli séparément et donc réduire les temps de MEP était un de leurs objectifs. Pour les équipes, le fonctionnement en micro-startup leur permet de posséder un ownership de la partie où ils travaillent. L'isolation de leur service les rends aussi maitre des choix techniques et leur permet de changer le système de stockage (d'un système de DB vers un autre par exemple), sans impacter le reste du système.

D'un point de vu ops, cela nécessite plus de travail. Chaque micro service pouvant être développé avec une stack différente, cela nécessite de faire communiquer des pièces hétérogènes ensemble et donc un plus grand temps de bootstrap pour chaque projet. Néanmoins, au final le gain est grand pour les ops aussi, qui, si jamais quelque chose tourne mal, peuvent identifier facilement, sans avoir besoin de devs, quelle partie est en feu.

En REX final, ils nous indiquent que ce passage était nécessaire pour eux, et semble nécessaire pour tout système à partir d'un moment, mais que cela ne va pas régler tous les problèmes. C'est un choix qui doit être réfléchi, et qui ne se fait pas du jour au lendemain.

Design de soi

J'ai ensuite enchainé avec une conférence beaucoup moins technique, mais beaucoup plus personnelle, sur le design de soi, ou comment valoriser son identité sur le net. La salle était pleine, plusieurs personnes ont même du quitter la salle faute de place. À en croire le tonnerre d'applaudissement au démarrage, il semblait que Marie Guillaumet, la speakeuse, était déjà bien connue d'une partie de la salle.

Du coup, elle nous a partagé des conseils pour gérer son image personnelle en ligne. La limite est floue entre entre personnal branding et le personnal branling. L'idée du talk est d'appuyer sur le fait que nous possédons tous une identité en ligne, professionnelle et personnelle, mais nous n'en sommes pas forcément conscient, et ne la maitrisons pas forcément correctement. Le talk était essentiellement tourné vers notre identité pro ici, sur la manière de nous valoriser sans en faire trop.

L'idée principale est que je dois partager qui je suis, ce que je fais, sans chercher à me faire mousser. Je pense que la conférence eu un certain écho avec ses spectateurs car j'ai vu beaucoup plus de résumés de ParisWeb sur Twitter que les autres années, ce dont je suis très content. Tout ce que l'on poste individuellement sur le net et qu'on partage fait partie de notre présence en ligne et nous définit. Cela doit être fait sans arrière-pensée d'auto promotion, mais il est important d'en avoir conscience afin de pouvoir s'en servir comme d'un atout professionnel (ce qui est particulièrement important pour les free-lances).

Je me permets une digression par rapport au message de Marie. Je suis complètement raccord avec elle sur le fait que l'image que nous renvoyons (en ligne et hors ligne) possède un impact réel et très important sur notre vie professionnelle. C'est d'autant plus vrai quand on exerce en tant que freelance, mais aussi pour des postes de salariés plus classique (et se ressent alors fortement quand on cherche un nouveau poste). Écrire des articles de blog sur un sujet qui nous passionne fait ressortir notre coté humain, qui peut parfois être masqué sous la pile de retweet technique que l'on poste. Il ne faut pas avoir peur d'évoquer ses idées, coup de cœurs et coups de gueule, même si tout le monde ne sera pas d'accord avec nous (ce qui est de toutes façons impossible). Au pire on se ferme des contacts avec des gens gênés par nos propos, mais nous n'aurions pas aimé travailler avec eux de toutes façons. Au mieux on se fait contacter par des gens qui partagent nos valeurs, ce qui est un vrai bonheur.

Bref, revenons au propos de la conférence, et aux freins psychologiques que l'ont peut avoir. À ce propos, je vous renvoie à la conférence de Kyan et Navo qui soulève à peu près les mêmes points.

Le frein principal qui nous empêche de prendre la parole (par écrit ou par oral), et que l'on se dit que plein d'autre personnes pourrait le faire mieux que nous. On se dit que l'on n'est pas assez expert, que ce que l'on va dire à déjà été dit ou n'est pas intéressant, bref, on est frappé du syndrome de l'imposteur. Et bien cela se soigne, il vous suffit de savoir que vous êtes légitime, que vous avez quelque chose à dire. Quelque soit votre degré d'expertise, ce que vous avez à dire est important car il est unique et il vous est personnel. Et les histoires personnelles sont importantes à partager, elles ont beaucoup plus de portée que de simples articles techniques.

Il ne faut pas non plus avoir peur de s'exprimer à titre personnel, on n'en devient pas plus vulnérable pour autant, au contraire, on en devient plus facile d'accès. En partageant vos idées personnelles, comme je le disais plus haut, vous aller toucher vos lecteurs sur le plan personnel. Tout le monde ne sera peut-être pas d'accord, mais cela n'a pas d'importance, et n'ayez pas peur d'être jugé, c'est très libérateur de pouvoir parler sans crainte. Par contre, quelque chose de très important est d'être le même sur le web et dans la vie. Si vous vous créez un personnage sur le web, il sera très rapidement mis à nu pour ce qu'il est vraiment lors de rencontres réelles. À l'inverse, si vous avez des choses passionnantes à partager de visu, partagez-les aussi en ligne.

Si vous ne savez pas sur quel sujet poster, dites-vous que tout le monde a besoin de contenu original et intéressant. Un retour d'expérience, un partage de connaissance, un making of d'une de vos réalisations, la liste de vos influences, tout ça c'est personnel et donc par définition c'est original. Allez y, partagez. Parlez du travail des autres, faites des CR des meetups et conférences où vous allez, faites un bilan des projets que vous venez de terminer, contribuer à des projets open-source.

Si vous ne savez pas quel ton adopter, faites comme si vous écriviez pour votre meilleur ami, ne vous mettez pas de barrière sur le style, le fond est plus important que la forme. Dans le doute, dites-vous que la personne qui vous lira ne connait rien au sujet, donc n'hésitez pas à détailler les éléments qui peuvent sembler complexes.

Une remarque qui semble évidente, c'est que vous ne risquez pas de dévaloriser votre travail en en parlant, au contraire. Vous n'êtes pas fait d'une sorte de "potion magique" qui vous donne vos pouvoirs, et vous ne risquez pas de perdre ces pouvoirs en partageant la recette de la potion magique. Au contraire, à écrire sur ce que vous savez vous consoliderez vos connaissances, vous irez plus loin mais surtout vous les partagerez. La connaissance ne vaut rien si elle n'est pas partagée.

N'en faites pas trop non plus. Soyez vous-même, ne vous forcez pas à faire ou dire des choses qui ne vous ressemblent pas, mais vous n'êtes pas non plus obligé de partager toute votre intimité. Les détails de votre vie privée n'ont sans doute pas leur place sur votre timeline Twitter professionnelle, vos peines de cœur et vos coups de gueule dans les embouteillages n'apportent rien. Levez aussi la pédale sur les retweets de compliments, sur le name dropping et l'auto congratulation.

Finalement, un point sur la forme qui peut vous permettre de regrouper l'ensemble de vos comptes en ligne sous une même identité c'est d'utiliser une couleur qui vous est spécifique et en tartiner toutes vos pages de profils. Utiliser un favicon représentatif et utiliser la même photo de profil partout. Tout ce qui permet de faire le lien entre toutes vos identités pour vous identifier comme une seule et même personne (ou au contraire pour faire la séparation entre votre avatar professionnel et votre avatar privé) est bon à prendre.

Finalement, si vous êtes convaincu mais pensez que vous n'avez pas le temps de faire tout ça, pas de panique. Vous n'avez pas besoin de tout faire d'un coup, la démarche est progressive. Faites petit à petit, rien ne presse. Mais surtout, n'ayez pas honte de ne pas tout faire. Si vous n'avez pas de compétence en développement, prenez un Wordpress tout fait. Si vous n'avez pas de compétences en design, prenez un thème tout fait.

C'est ce genre de conférence que j'aime à ParisWeb, j'en ressors avec un boost de motivation et une grande liste de choses à faire, que j'ai envie de faire.

CozyCloud

La dernière conférence officielle de la journée (on enchainera sur une conférence surprise sur la LSF juste après) était présentée par Tristan Nitot, ex-Mozilla.

Tristan nous fait un état des lieux du net depuis ses début. Il parle du net comme d'un pharmakon, quelque chose qui peut être aussi bien un poison qu'un médicament, selon les doses et selon les cibles. Il nous parle de la mort de Netscape et de l'émergence des standards pour éviter que le web ne stagne, entre les mains de quelques monopoles.

Il nous rappelle qu'aujourd'hui en 2015 le web est complètement différent de ce que l'on aurait pu imaginer. Tout le monde possède un smartphone, les GAFAs sont les mastodontes du réseau, des tas de sites fonctionnent selon un système de SaaS gratuit pour les utilisateurs.

Le grand public englobe ça sous le nom de cloud, mais il est vrai que dans les fait, c'est du SaaS. Rien à installer, le site web fonctionne comme une appli, qui peut être mise à jour pour tout le monde en même temps, et la plupart du temps les utilisateurs n'ont même pas un centime à débourser (Facebook, Gmail, etc).

Sauf que les clients, ce n'est pas nous. Tout comme les cochons dans un abattoir ne sont pas les clients. Ils ont beau avoir un toit sur la tête et être bien nourris, tout cela au final n'est pas construit pour eux. Les vrais clients sont en bout de chaine et eux ne sont que la matière première. Aujourd'hui, nous ne sommes pas les clients, nous sommes (ou plutôt les données que nous produisons), le véritable pétrole du XXIe siècle.

Ces données sont ensuite revendues, essentiellement à des régies publicitaires, mais tout simplement à quiconque souhaite les acheter (et qui possède les fonds suffisants). Mais d'autres organismes sont aussi intéressés par ces informations, comme les révélations Snowden nous l'ont bien montré, des états entiers cherchent à obtenir ces informations. S'ils ne peuvent les obtenir par des moyens légaux, le fait que ces données soient centralisées chez quelques acteurs principaux rends leur espionnage et leur siphonnage plus facile.

On peut répondre qu'on s'en moque, car on n'a rien à cacher. C'est peut-être vrai en temps qu'individu, mais en tant qu'organisation commerciale vous avez sans doute des choses à cacher, des choses que vous n'aimeriez pas voir rendues visibles par vos concurrents. Et même en temps qu'individu, même si vous ne faites rien d'illégal, vous avez quand même sans doute des choses que vous ne souhaiteriez pas rendre publiques. Tristan donne l'exemple du verrou qu'il ferme dans ses toilettes, non pas qu'il fasse quelque chose d'illégal ou de répréhensible dans ses toilettes, mais simplement qu'il y fait quelque chose de privé.

Il donne ensuite l'exemple de sa douche, sous laquelle il chante (mal) tous les matins. Mais il sait aussi qu'il arrête de chanter sitôt qu'il sait que sa femme est rentrée à la maison. Par honte ou par peur on ne sait pas, mais il ne souhaite pas que sa femme l'entende chanter (mal), alors il se tait. Ce simple exemple montre qu'un individu qui se sait épié modifie son comportement (même si cet exemple n'a rien de très scientifique, je pense que vous en voyez le sens).

Pour lutter contre tout ça, Tristan propose quelques règles à suivre. Déjà, se débarrasser du mythe qui voudrait que la publicité soit un mal nécessaire. La publicité nous donne la sensation d'obtenir un service gratuitement. Vu qu'on donne une grosse partie de nos données en échange, ce n'est déjà clairement pas gratuit. Ensuite, il nous faudrait nous reposer sur du matériel que nous possédons, plutôt que d'utiliser un système distant contrôlé par un autre organisme. Il est possible de faire des serveurs peu consommateurs et assez puissants pour 35€ avec un Raspberry Pi aujourd'hui.

Sur ces machines, on y mets évidemment du logiciel libre plutôt que des softs fermés. On chiffre nos échanges de manière a rendre illisible pour toute source extérieur le contenu de nos échanges. Pour ça, il semblerait que Let's Encrypt soit une solution intéressante. On utilise des standards pour rendre tout ça interopérable, et on saupoudre le tout d'une UI simple qui ne laisse personne dehors.

Jusqu'ici, je suis à fond avec Tristan, ses arguments me paraissent solides, je pense que je les réutiliserait. Je suis son chemin de pensée et j'attends avec impatience sa solution.

Et là, c'est le drame.

La présentation tourne à la présentation commerciale pour Cozy, la nouvelle boite de Tristan. Cozy par-ci, Cozy par-là, même quand il n'y a aucun rapport avec le sujet. Si encore Cozy résolvait les problèmes soulevés avant pourquoi pas, mais là, même pas.

En quelques mots, Cozy est un système open-source qui permet de synchroniser toutes ses données au même endroit, sur un device qu'on contrôle, afin d'en rester maitre. Sauf que, à part créer un nouveau silo qui amalgame encore plus de données de plusieurs sources, je vois pas trop ce que ça change avec la situation actuelle. Certes, je peux le stocker chez moi sur mes devices, mais Tristan mettait quand même en avant que Cozy fournissait "gratuitement" l'hébergement sur leurs serveurs. Donc à part un nouveau silo à aller siphonner, je vois vraiment pas ce que ça apporte.

Plus ça allait plus le discours était commercial et complètement orthogonal avec les valeurs énoncées au démarrage. On liste toutes les features de Cozy, on nous montre que le design est responsive (bravo) mais on oublie complètement le sujet de fond. On nous montre que Cozy récupère les mails depuis Gmail, les contacts de notre téléphone et nos données bancaires.

Mais l'apothéose c'était quand même l'exemple de la facture détaillée de SFR, où Tristan nous dit qu'avec Cozy il serait possible de lier les numéros de téléphone de la facture avec notre liste de contact pour savoir quels sont les destinataires qui nous coutent le plus cher. Sérieux ? À croire que posséder de la donnée corrompt tout le monde. Ce n'est pas parce que l'on peut croiser toutes les données que l'on possède qu'on doit le faire. À commencer comme ça on cherche à obtenir encore plus de data pour faire encore plus de liaisons, exactement comme les GAFAs contre qui on luttait au début de la présentation.

Parce que faut pas oublier que dans ces exemples, le Cozy ne contient qu'une copie des données qui ont été récupérées chez notre banque, chez Google ou chez SFR. On a juste ajouté un nouveau nœud qui possède une nouvelle copie des données, tout bien rangé au même endroit, et tout bien lié.

Il nous incite à essayer Cozy, qui est gratuit, en nous disant "Allez-y, mettez-y plein de données, pour qu'on améliore nos systèmes. Bien sur on ne regarde pas la data hein, c'est juste pour qu'on s'améliore". Après tout le speech qu'il a donné avant, comment peut on avoir envie d'essayer Cozy ?

Dans la session de questions/réponses qui a suivi, il a même dit qu'il espérait que des sociétés fassent des applications pour Cozy, en donnant l'exemple de EDF qui pourrait "faire une appli Cozy qui, en échange de vos données, vous donne 2 mois gratuits". Sérieux, je ne vois absolument pas la différence avec le modèle des GAFAs actuel.

Au final, soit j'ai vraiment rien compris, soit le discours était vraiment pas rodé. Je n'ai pas été le seul à avoir trouvé cette présentation bien trop commerciale (même les talks sponsorisés étaient moins commerciaux).

LSF

Bon, on a quand même pu finir la conférence sur une note plus gaie, avec l'une des meilleures conférences de cette session. Pour ceux qui ne sont jamais venus à ParisWeb, il faut savoir que toutes les conférences sont traduites en Langue des Signes Française en live par une interprète, sur scène. Le grand amphi a aussi le droit à une retranscription textuelle en vélotypie.

Cette année on a donc eu le droit à une présentation de l'une des interprètes LSF pour nous en apprendre plus sur cette langue. Oui, car on dit langue des signes et pas langage des signes. Et oui, ce sont des signes et pas ni des gestes ni des mimes.

La LSF n'est pas une langue internationale, même si la grammaire de base est la même il y a des différences culturelles entre différents pays. Certains pays ont même plusieurs langues des signes officielles, et différents pays francophones n'utilisent pas la même langue des signes non plus.

On se pose souvent la question de mais comment diable font-elles pour réussir à traduire ce speaker qui parle super vite, avec des termes techniques ?. La réponse est ben, elles y arrivent pas. Elles se renseignent avant l'évènement sur le sujet des conférences pour savoir un peu de quoi on va parler et de quels mots barbares vont être utilisés, mais tous n'ont pas encore de transcription en LSF, du coup il faut parfois faire des périphrases. Et quand le speaker enchaine les acronymes, avec un débit continu, c'est bien difficile de réussir à tout attraper. Encore pire quand ils y casent des blagues !

Le métier d'interprète est difficile et il y a 4 écoles en France qui peuvent y former. Là bas on y apprends, outre les signes eux-mêmes, à faire une gymnastique du cerveau particulière pour être en mesure d'entendre, de comprendre, d'analyser, de se représenter et de signer ce que vient de dire l'orateur, tout en faisant la même chose pour la phrase suivante, le tout sans jamais s'arrêter. On dit que les femmes sont généralement plus douées pour faire plusieurs choses en même temps et c'est vrai que je n'ai vu que des femmes interprètes LSF cette année (il me semble qu'il y avait un homme il y a deux ans).

Elles font normalement des shifts de 15mn sur scène, mais le débit à ParisWeb était tellement rapide et les mots tellement complexes qu'elles réduisent à 10mn pour pouvoir tenir les deux jours. D'ailleurs, dans le monde des interprètes en France, il y a celles qui ont fait ParisWeb et celles qui ne l'ont pas fait. Certaines adorent et veulent revenir tous les ans (pour l'ambiance, pour l'accueil) et d'autres trouvent cela trop dur et on ne les revoit jamais.

Au final, un grand grand merci pour nous avoir fait partager ce métier que nous côtoyons chaque année pendant deux jours sans se douter de tout ce qu'il implique réellement derrière. C'était très agréable et très instructif de nous avoir montré l'envers du décor.

Ateliers

J'ai continué le lendemain sur les ateliers, très intéressants aussi, remplis de discussions passionnantes sur ES6, sur l'avenir de notre métier (et sur notre vie après la mort) et où j'ai fait de jolis petits dessins. Je n'ai pas de résumé détaillé à écrire cette fois-ci par contre.

Conclusion

Même si la première journée m'avait laissé sur ma faim, les deux suivantes m'ont reboosté. ParisWeb c'est quand même un moment magique entouré de passionnés, dans une ambiance bienveillante de partage. Quand je me suis levé dimanche matin j'étais déçu de ne pas commencer une nouvelle journée de ParisWeb.

Le futur de ParisWeb est incertain par contre, une grande partie du staff quitte le navire après cette 10e année et une nouvelle génération va devoir se lever pour faire durer l'aventure. Demain soir a lieu un AperoWeb où on discutera de tout cela, et j'irai y faire un tour. J'aimerai aider à ce que ParisWeb continue, mais je ne suis pas certain d'avoir le temps nécessaire pour cela. On verra demain.

Tags : #parisweb

Want to add something ? Feel free to get in touch on Twitter : @pixelastic