Mixit 2018 : le rendez-vous des belles découvertes

Chaque année, c'est la loterie chez Wanadev. Un système obscur complètement random doit désigner l'heureux élu qui ira à la mixit. Cette année, c'est moi, Manuel, qui ai la chance d'avoir mon ticket d'entrée. Victime de son succès, cet événement atypique réunit un public très divers gravitant autour de l'IT. Sa programmation est hétéroclite ce qui lui donne un intérêt particulier à cette rencontre incontournable du printemps. Impossible pour nous de tout résumer mais voici 3 talks qui selon nous sont sorties du lot et qui vous permettront d'éveiller votre curiosité !

Cessons les estimations (par Frédéric Leguedois)

Pour le coup, ce fut une découverte détonante ! Il n'y a pas à dire Monsieur Frédéric Leguédois a loupé sa carrière dans le one man show.

Le ton est donné dès le début du talk avec un rythme soutenu, de sorties verbales tranchantes et un humour très taquin envers les chefs de projet. Accrochez vous le voyage ne va épargner personne !

Premier constat : des années de méthodes de gestion de projet n'ont rien changé, les estimations sont rarement justes.

Plusieurs raisons à cela :

• Les clients changent toujours d'avis
• On ne maîtrise pas tout l'environnement client et technique
• Personne n'est capable d’estimer un travail sur le long terme

Une maxime pour résumer cela : "Le retard est la différence entre le rêve et la réalité."

Le chef de projet a beau avoir changé de nom en devenant Scrum master ou PO, les estimations sont toujours fausses quelques soit les méthodes utilisées (planning poker, méthode de similitude..).

@ Au même titre que les voyants et les marabouts, les chefs de projets sont des mediums qui arrivent à prévoir l'avenir en fixant des dates précises !

Vous l'aurez compris, pour Frédéric, le mode forfait semble incompatible à bonne marche d'un projet. L'agilité est à la mode et propose un panel d'outils méthodologiques intéressants qui sont relativement mal exploités. Il recommande la méthode Kaizen qui promue l'amélioration d'une entreprise / d'un projet en apportant chaque jour de petits changements.

Dernier coup de "gueule" dans cette conf pour la méthode Scrum et ses itérations appelés "SPRINT". Frédéric nous rappelle que courir n'est pas un rythme normal et supportable dans le temps. L'homme est fait pour marcher.

Encore une fois, on mets en avant la notion de temps avant la qualité.

@ En résumé, dans ce talk, il faudrait se tourner vers des solutions alternatives qui prennent en compte les véritables contraintes techniques et humaines. Le cœur du projet reste la qualité et la pertinence des fonctionnalités. À l'inverse, se concentrer sur les délais est contre productif et impose aux équipes de "bâcler" leurs développements.

Serverless is the new black par Gérôme Egron et Jérémy Pinsolle

cf : @jpinsolle & @GeromeEgron

Cette conférence met le focus sur les solutions Amazon permettant de faire du serverless. Véritable petite révolution, elle chamboule l’équilibre entre les sysadmin et les développeurs. En effet, toute la gestion et le paramétrage de vos services sont déportés chez votre provider. En échange de cette grosse dépendance, beaucoup de flexibilité, aucun paramétrage, une scalabilité exemplaire et enfin un coût qui s'adapte à la consommation.

Le serverless est la continuité de l'évolution des systèmes. Du serveur dédié vers la virtualisation (ec2, vps..) en passant par les services managés pour enfin aboutir aux serverless.

La présentation s'est ensuite centrée autour du service lambda AWS. Lambda permet l'exécution d'une fonction. Cette fonction est un événement qui pourra être appelé en http (via API gateway). Au premier appel, une instance est créée qui pourra être jouée autant de fois que désirée.

@ À noter que ces instances peuvent être détruites pour différentes raisons (inactivité, mise à jour…). Il faut donc considérer que votre fonction est stateless et nécessite rapidement l'utilisation de stockage (S3). Et oui, bienvenue dans l'écosystème propriétaire d’Amazon !

En résumé, hormis une dépendance énorme à Amazon et certaines contraintes techniques, il peut être intéressant de mettre en place ce genre d'architecture pour des actions coûteuses en ressources (en mode micro service) et qui sont cloisonnées. Par exemple : la création de vignettes d'images.

Dernier point avant de vous engager, vérifiez bien les limitations techniques de la plateforme au niveau des timeouts d’exécution des fonctions et de la taille du payload.

La sécurité dans l’IOT par Alexis Duque

cf @alexis0duque

Les objets connectés sont de plus en plus présents dans notre quotidien. Au plus proche de nos activités ils sont entrés chez nous sans que l'on se soucie des conséquences en terme de vie privée et de sécurité.

Premier constat, l'IOT facilite les failles : faible puissance de calcul, des mises à jour de firmware non-automatisées, un fonctionnement dans des réseaux non protégés et une simplification à l’extrême de contraintes pour les utilisateurs (plug and play).

@ Ce qui est surprenant, c'est que la majorité des failles actuelles sont connues depuis 15 à 20 ans. Les contraintes commerciales et la faiblesse techniques de certains développeurs sont à l'origine de la majorité des failles.

Alexis a ensuite fait un focus sur le bluetooth LE (low energy). Ce protocole, majoritairement utilisé dans l'IOT, permet de transférer des petites données à moindre coût énergétique.

Il faut considérer qu'avant la version 4 du protocole, la sécurité était quasiment nulle. Il y a eu ensuite la mise au format AES-128 (4), un système de comparaison numérique (ECDH) en 4.2 et enfin la version 5.

Aujourd'hui, un développeur de produits Bluetooth a le choix du mode de connexion entre l'utilisateur et l'objet :

• Just works (pas d'identification)
• 6-digit
• Numeric Comparison
• OOB (utiliser un moyen tiers NFC)

Malheureusement, certains de ces modes de sécurisation de sont pas toujours implémentés en raisons des contraintes qui existent. Par exemple, la comparaison de chiffres (ECDH) nécessite des objets avec écran et le système OOB, un appareil NFC. Autre frein, le besoin de rendre toujours plus rapide et simple la connexion entre les objets et donc la suppression de toute intervention de la part de l'utilisateur. L'ergonomie au détriment de la sécurité !

Mais quels sont les types d'attaques possibles ?

La première concerne les failles de connexions entre l'utilisateur final et l'objet avec l'interception des données ("man on the middle" ). Par exemple, un dongle bluetooth peut s'intercaler entre l'objet et l'utilisateur. L'attaquant pourra ainsi récupérer les données échangées.

La seconde typologie d'attaque concerne des failles indirectes sur les systèmes de sécurité ("canal auxiliaire"). Un script qui résout la mot de passe d’authentification.

En résumé, ce talk a mis en lumière des problèmes de sécurité sur des éléments en amont des API ou solutions web que nous avons l'habitude de développer.

Mixit, on fait le bilan calmement.

les petits plus

• Les crêpes évidemment ;-)
• Moment majeur pendant ces deux jours, l'intervention de Juergen Hoeller (co-createur de Spring). Oui oui Spring, le framework java… Toutefois il était intéressant de voir les parallèles entre l'évolution de SPRING avec certains framework PHP !
• Des découvertes et des sujets qui varient
• “Testing testing a testament”, un random talk hilarant.

les petits moins

• Pas de bol, il faisait chaud sur Lyon pendant ces deux jours. Grosses chaleurs dans les salles sans clim.
• Certains talks qui paraissaient improvisés et/ou mals préparés

@ Les vidéos des talks seront à retrouver dans les prochains jours sur le compte Vimeo du mixit. Merci, à l'année prochaine !