La semaine dernière Jérôme était au Riviera Dev ! Voici le compte-rendu des différents conférences !

09h00 Keynote organisateurs

Les organisateurs ont retracé l’histoire de la RivieraDEV, ses succès, ses échecs, au travers

d’une timeline gorgée de souvenirs et de passion.

09h20 The Hitchhiker’s Guide to Diversity (Don’t panic!)

C’est en abordant le sujet du féminisme et du sexisme au travail qu’Audrey a capté tout l’auditoire pendant presque 1 heure. Avec l’appui d’exemples aussi simples que pertinents, elle a su avec brio illustrer ses propos et faire passer les messages qui lui étaient chers. Blagues graveleuses, réduction permanentes à la condition de femme, clichés répétitifs sont autant de chemins qu’elle a eu a traverser au cours de sa carrière et dont elle a voulu nous restituer le point de vue. Elle a très largement insisté sur la notion d’empathie que nous devons tous nous efforcer d’entrainer et d’utiliser auprès des autres. Sa conclusion sera que l’homme blanc hétérosexuel à la trentaine qui est aujourd’hui majoritairement représenté dans notre milieu dispose d’un « super pouvoir naturel » qu’il se doit d’utiliser auprès de ses pairs qui feront preuve de sexisme : une voix qui porte plus que celle d’une femme, d’une personne d’une autre ethnie, ou encore d’une personne handicapée pour faire entendre et taire les clichés oppressants sur les femmes.

Audrey Neveu

10h20 Tensorflow, there is no spoon

Tiffany a abordé le vaste thème de la reconnaissance d’images. Les nouveaux algorithmes en charge de ces procédés sont au coeur de ce que l’on appelle le machine learning : on dispose d’un jeu d’images que l’on sait catégoriser et l’on entraine notre algorithme avec ces images. En suite on demande à notre algorithme de catégoriser dans l’une ou l’autre des catégorie chacune des nouvelles images qu’il reçoit en entrée. Si cette analyse peut sembler triviale, Tiffany a su nous donner un aperçu de la complexité qui pouvait résider en amont, et surtout à quel point il était simple de « hacker » le système et de faire prédire à un réseau de neurones un résultat fondamentalement faux. Les réseaux de neurones qui prédisent ces résultats basés sur des modèles dits fiables se retrouvent dans les applications pratiques extrêmement sensibles tels que celles que l’on retrouve par exemple dans les voitures autonomes, ou dans nos téléphones. Heureusement, son talk est conclu par la façon dont on peut se prémunir de telles agissements 🙂 sauvés !

Tiffany Souterre

11h30 La révolution dans vos apps, c’est la gestion de l’état!

Cette conférence plutôt orientée webapps exposait les bienfaits d’une architecture « réactive » et de l’utilisation de composants dont leur gestion se ferait par états. Le début du talk était très théorique et assez accessible à tous. Yohan a parlé du patron de développement Redux et de ses 3 principes clés. Très vite, la théorie a été illustrée par des exemples dont je ne maitrise personnellement ni la syntaxe de code ni les concepts. Comme a pu l’expliquer Yohan, le développement d’une app à gestion d’états apporte de nombreux bénéfices et peu de méfaits, même si la montée en compétence sera potentiellement plus longue et les premiers résultats arriveront avec le temps.

Yohan Lasorsa

13h40 Devenez accessible !

Conférence complètement orientée Web / HTML, Delphine nous a montré quelles étaient les erreurs que les développeurs web pouvaient faire en terme d’accessibilité et comment les corriger. Elle a commencé par expliquer tous les types de handicaps (moteur, visuel, auditif, mental) et quelles étaient les astuces simples pour palier ces problématiques. L’objectif de Delphine était surtout de nous sensibiliser à l’existence d’une cible trop souvent mise de côté et pour laquelle il existe des techniques pourtant faciles à mettre en oeuvre. J’ignorais personnellement que certaines personnes pouvaient ne pas utiliser de souris et comprend aujourd’hui mieux les enjeux d’une bonne gestion de la navigation au clavier sur un site internet. Cet exemple fait partie d’un lot très complet d’autres exemple que Delphine nous a donné : on pourra retrouver aussi le focus trap, la restitution du focus, l’utilisation des aria-labels, l’utilisation pour les images de différents alt (descriptifs pour une image, sémantique pour un bouton avec une icône), ou encore l’attention donnée aux contrastes de couleurs et aux tailles relatives… et j’en passe, la liste est loooongue !

Delphine Millet

16h00 Authentification/Autorisation, le grand battle

Au travers d’une timeline, Valeriane a retracé l’histoire des différentes librairies d’authentification ou d’autorisation qui existent ou ont pu exister, pour finalement confronter leurs avantages et / ou inconvénients. La plupart des librairies qui ont été abordées sont encore en place dans de nombreuses grosses entreprises de part leur efficacité déjà prouvée (Kerberos), ou sont en cours de déploiement de part leur attrait par les GAFA (OpenID Connect). Chacune de ces solutions propose une approche systématiquement différente. Valeriane a aussi parlé des autres systèmes d’authentification plus connus dont nous disposons aujourd’hui, mais sans trop s’y épancher (mot de passe, biométrique…)

Valeriane Venance

17h00 Architecture Decision Records : enfin une documentation qui vous ressemble !

Session plutôt courte sur la façon dont historiser les décisions techniques qui ont pu être prises au cours du développement d’un projet en Agile. En illustrant d’un exemple super simple, Olivier a pu nous confronter a une situation que nous avons tous déjà vécu : « Il fout quoi là ce bout de code ? Il sert à quoi ? Je ne comprends pas. ». Il nous a également mené vers les 2 chemins habituels s’ouvrants devant nous devant ce type de situation : dois-je corriger au risque de tout casser ou dois-je laisser en l’état au risque de rendre le truc encore moins compréhensible ? Pour palier ce problème, ils nous a donné une technique simple pour donner de l’historique à toutes les décisions techniques prises dans un projet : les ADR. Il s’agit d’un petite fiche qui explicite un choix technique. On y écrit simplement un titre, une date, un contexte, une décision et les conséquences qui en découlent, et on stocke sans jamais plus y toucher. Ainsi, on conserve une trace de toutes les décisions techniques. Le jour ou une solution technique vient en invalider une autre, on écrit un nouvel ADR, et on vient y faire le lien avec celui qui vient d’être invalidé, pour faciliter la parcours de l’historique. À mettre en place d’urgence sur tout projet ! 😉

Olivier Revial