Les 13 et 14 octobre dernier marquait la toute première édition physique de Volcamp, la première conférence tech auvergnate ! Cet événement a rassemblé 400 personnes.

Voici quelques résumés des talks auxquels j’ai pu assister. Je précise tout de suite que prendre des notes en live, ce n’est pas un exercice simple et que j’ai pu commettre des erreurs ou imprécisions en retranscrivant. D’autant plus que pour beaucoup, ce sont des sujets que je maitrise peu voir pas du tout. Alors ne prenez pas tout ce qui est écrit pour vérité absolue, mais allez voir les retransmissions sur la chaine Youtube de Volcamp si le sujet vous intéresse !

Keynote - (et si on apprenait à) Apprendre et partager autrement

Par Aurélie Vache

Aurélie a commencé par raconter quelques bribes de son histoire personnelle avec des mots forts : “une petite terrifiée à l’idée de dire son prénom en public”. Puis elle a parlé de passions que l’on met de côté voir que l’on oublie avec le temps. Pourtant, ces passions ne sont pas futiles, et celles-ci peuvent être une force et nous permettre de nous différencier dans notre travail. Par exemple, Aurélie qui aimait dessiner, a commencé à représenter des concepts de k8s de façon très simplifiée lors du premier confinement. Cette passion pour le dessin l’a amenée à faire quelques tweets, puis des vidéos et finalement proposer des conférences en live devant public.

Elle a par la suite parlé de comment on enseigne / appends / partage de façon assez semble à des gens qui sont tous différents. Le partage, c’est parler, mais également écouter.

Son conseil : s’aérer la tête au moins 30 min ou 1h par semaine et laisser courir son imagination pour découvrir comment remettre ses passions au centre de son projet professionnel.

Elle évoque des personnes qui l’ont inspirée (sur leur approche originale d’aborder leur métier) comme Julia Evans, Priyanka Vergadia, Pierre Tibule, Noël Macé et d’autres …

En conclusion : restez vous-même, ne copiez pas les autres, mais trouvez ce qui vous différencie et surtout ne vous mettez pas de limite.

Mon avis

Cette keynote était sympa. Beau parcours pour cette “petite fille” 😃.

Pause fraîcheur - Elixir au menu !

Par Jonathan Hervault et Emilien Mottet

Jonathan et Emilien nous ont présentés Elixir, un langage de programmation fonctionnelle qui s’appuie sur la VM d’Erlang. Ce dernier est par exemple très utilisé dans les infra réseaux (90% des routeurs). Lors d’une session de live coding, ils ont créé un bot de suggestion de films consommant l’API de IMDB. Ils ont commencé par parler du “pattern matching” qui permet de faire du polymorphisme en utilisant la valeur d’un paramètre. Grâce à la VM d’Erlang, il est possible de recompiler en live (hotreload). Elixir permet d’avoir une syntaxe plus concise que d’autres langages (c’est un avantage de la programmation fonctionnelle). Quelques exemples de sucres syntaxiques ou feature montrés :

• affectation de variable à la volée
• l’opérateur pipe |> qui permet de passer l’expression de gauche en paramètre de l’expression de droite
• pas de return en Elixir
• les streams
• parallélisme avec Task.async_stream Le framework web #1 en Elixir c’est Phoenix : permet de faire une app web dynamique sans écrire de JS. KBRW est une société qui a une forte expertise en Elixir.

Les forces principales d’Elixir :

• mise en place sur un système distribué / haute disponibilité
• des process ultra légers par design

Mon avis

Très bonne présentation (une des meilleures de ces 2 jours pour moi) : les deux speakers étaient à l’aise et on sent que c’était bien préparé. En plus, ils ont fait un gros taf pour rendre ça interactif et vivant avec du live coding et la demo de leur app (on pouvait interagir nous même depuis nos smartphone). Moi qui ne connais quasiment rien à Elixir et à la programmation fonctionnelle, je n’étais pas perdu et j’étais intéressé du début à la fin. Top !

Comment j’ai développé le détecteur de deepfakes le plus puissant du monde pour 100€

Par Mathis Hammel

Mathis commence par le constat que beaucoup de compte sur les réseaux sociaux sont des SCAMs et que pour les rendre crédibles, l’utilisation de fausses photos de profils est massivement utilisée. Ces photos peuvent provenir notamment du site https://thispersondoesnotexist.com qui génère des photos de gens ultra réalistes qui n’existent pas. Ces photos sont créées grâce à un algo à réseau de neurones StyleGAN2. Le but de Mathis est de parvenir à détecter les photos qui viennent de ce site pour détecter les comptes fallacieux.

Il commence par nous expliquer comment fonctionne les réseaux de neurones (de façon très simplifiée). En gros, ce sont des boites noires qui font des additions et des multiplications. Il nous parle de deux types différents :

• les générateurs
• les discriminateurs

Le générateur va générer des images (grâce à de l’entropie au début de l’entraînement). Le discriminateur doit dire si l’image générée est vraie ou fausse. Il sert à entrainer le générateur, mais il devient lui aussi de plus en plus performant à mesure que le générateur s’entraine. L’idée, c’est que si le discriminateur trouve la bonne réponse, on le renforce en validant sa réponse, sinon on renforce le générateur en validant son image. Le générateur va apprendre des modèles qui fonctionnent bien.

Attention ce n’est pas si simple en pratique. Il peut y avoir de mauvais entrainements ou des bloqueurs :

• overliffing (connaitre toutes les images par cœur)
• convergence lente (ne pas apprendre des précédentes itérations et faire du “guessing” au hasard)
• il faut une grosse puissance de calcul
• l’effondrement du mode (l’apprentissage d’une seule image)

Maintenant, comment fait-on pour détecter les images générées par StyleGAN2 ? Clairement ce n’est pas possible d’entrainer un réseau de neurones plus performant que celui de Nvidia par nous-même. Donc si on veut faire mieux, il va falloir tricher…

On peut commencer par trouver des indices :

• souvent le fond de l’image est uni, flou, sans détails
• le format de l’image est identique (un carré)
• les yeux sont toujours au même endroit (puisque dans le dataset qui a servi à entrainer le générateur à des photos dont les yeux sont au même endroit)

En analysant le fonctionnement du site web, Mathis a remarqué qu’une nouvelle photo était générée toutes les 1.2s, ce qui veut dire que si on télécharge toutes les images générées, on pourra les comparer aux photos qu’on suspecte d’être des fausses. Il a mis en place un script pour télécharger toutes les images générées donc il fait au moins une requête toutes les 1.2s (en pratique, il en fait plus pour être sûr de ne rien louper). Il en télécharge 72000 par jour. Ensuite il utilise FaceNet, un réseau de neurones qui va transformer une photo en un vecteur (facilement stockable en DB). Il suffira ensuite d’appliquer FaceNet aux photos suspectes, puis de comparer le résultat à ce qu’on a en DB. Il faut préciser que FaceNet retourne est capable de retourner un vecteur très similaire pour deux photos de la même personne, même si le fond est très différent. Avec un ElasticSearch Open Distro, il indexe tous les vecteurs et ça permet de faire des recherches de proximité simplement.

Avec cette petite stack monté sur un genre de raspberry + GPU, il est capable de détecter les deepfakes venant de thipersondoesnotexist avec une très grande précision.

Mon avis

Cette présentation était très intéressante et agréable à suivre. Encore un sujet que je connais très peu, mais Mathis est très bon pour vulgariser donc il n’y a pas réellement de bloqueur qui empêche de suivre. C’était fun et ludique.

Et si on essayait plutôt que de tout lancer par la fenêtre ?

Par Anthony Roux

Ce quickie au titre mystérieux, abordait le sujet de la gestion des erreurs et exceptions en Java. Pour Anthony, la levée d’une exception est une relation de confiance entre deux méthodes : celle qui lève l’exception fait confiance et délègue le traitement de celle-ci à celle qui l’appelle.

Une erreur peut aussi se matérialiser en utilisant le code de retour d’une fonction, mais cela pose plusieurs problèmes :

• le code est pollué par la propagation de l’erreur
• si on retourne une erreur, on ne retourne rien d’autre (Golang permet de faire des retours multiples ce qui permet de gérer ça facilement)

Deux questions : comment gérer les erreurs sans polluer le code ? Comment les traiter au bon niveau (ni trop tôt, ni trop tard) ?

Les exceptions justement permettent de faire ça. Elles n’interfèrent pas avec le code de retour des fonctions, et on peut choisir de les traiter quand on le veut. En revanche, la lisibilité n’est pas améliorée : ce n’est pas simple de savoir/prévoir le chemin que prend un appel (effet GOTO). De plus, le revers de la médaille, c’est qu’on déresponsabilise la méthode appelante dans le sens où elle n’est pas obligé de traiter l’erreur.

Anthony nous présente Vavr, une lib Java de gestion d’erreur (entre autres) qui utilise une monade pour ça : Try. Try va permettre de chainer des appels, sans se soucier de gérer les erreurs, ce qui découple totalement celles-ci du code métier.

Attention à l’utiliser avec parcimonie, en effet, ça peut vite devenir trop central dans le code, et ce n’est pas adapté à tous les cas d’erreurs. De plus, l’intégration avec l’API native n’est pas complétement aboutie.

Mon avis

Très bonne présentation, le speaker était bon (c’est un pote, mais j’essaye d’être objectif :p). Même si je ne fais plus de Java depuis un moment, les explications étaient claires et bien structurées.

Le voyage du héros de l’IT

Par Olivier Beautier

Olivier nous a raconté le parcours initiatique d’un héros de roman après avoir fait une introduction sur l’improvisation et ses débuts en tant que speaker. Le voyage du héros de roman est un cycle classique repris dans beaucoup d’œuvres, fait d’étapes successives.

À partir de ceci, Olivier a tenté un parallèle entre le héros de roman et un speaker, qui va devoir passer une étape de sélection, préparer du contenu, suciter de l’empathie, apporter ses valeurs, …

Mon avis

Le sujet était intriguant, et j’aime bien aller voir un sujet un peu original de temps en temps. Finalement, je n’ai pas accroché. La quasi totalité du talk était sur le voyage du héros dans les romans, et j’ai trouvé que le parallèle avec l’IT était vraiment trop tardif.

Dernier motif de frustration pour moi, c’est la gestion du temps : faire 25 min sur un slot de 45 min, c’est trop peu (à mon gout). Heureusement il y a eu pas mal de questions pour compléter un peu ce talk.

La grande démission - est-ce qu’on va tous changer de job en 2022 ?

Par Damien Cavaillès

Damien a commencé par évoquer le “Big quit” aux Etats-Unis : beaucoup de gens ont démissionné pour gagner plus d’argent (notamment en devant livreur pour Amazon). Les départs en préretraite sont aussi une des raisons de cette tendance.

La pandémie a fait revoir les attentes des salariés : le contrat psychologique (tout ce qui ne relève pas du contrat légal) est devenu aussi important que le contrat légal.

La confiance envers l’employeur a changé, perdu notamment à cause du management à distance qui n’est pas le même que sur site.

En plus, jusqu’il y a peu, il était vraiment facile de démissionner puisqu’on pouvait trouver très facilement du travail ailleurs.

Damien nous parle aussi de la notion de “quiet quitting” : on ne démissionne pas, mais on ne fait plus grand-chose.

Puis vient ce qui a causé un peu d’émoi dans la salle :D : Damien dit qu’il ne faut pas attendre que tout aille mal pour partir, mais qu’il faut le faire justement quand tout va bien. Chose que pas mal de gens n’ont pas vraiment compris il me semble. C’est vrai que ça peut paraitre étonnant, mais moi je l’interprète plutôt comme ça : c’est quand tout va bien qu’on est en position de force pour choisir sereinement sa nouvelle destination. On est attractif pour les entreprises qu’on prospecte, et on n’est pas à l’abri d’être retenue par une super offre de sa boite actuelle.

Règle d’or de Damien : on ne critique jamais ses anciens collègues auprès de recruteurs. Ils n’ont pas vraiment envie d’être critiqués à leur tour lorsqu’on partira.

Il a ensuite parlé du burn-out, qui peut se manifester par les symptômes suivants :

• perte de sommeil
• stress
• trouble de la concentration
• perte de mémoire
• sentiment d’impuissance dans le travail

En France, la dynamique s’est maintenu un moment. On voit quand même un fléchissement des intentions de recrutements. Les salaires continuent d’augmenter depuis la reprise, notamment grâce à l’injection de fond par des investisseurs dans la tech. C’est normal pour Damien puisque pendant la crise du Covid, le secteur de la tech était un des rares secteurs qui fonctionnaient bien.

En revanche, fin 2022 et encore plus 2023, c’est la fin de la fête. Pendant le Covid, on ne démissionnait pas beaucoup, maintenant beaucoup plus (donc il y a plus de candidats sur le marché).

Il finit sa présentation par ce qui est important comme critères pour “noter” une boite pour lui :

• les salaires en accord avec le marché
• combien de temps vous mettez pour déployer une app
• refuser la culture du blame
• est-ce qu’il y a des “safe places” et des “coupes circuits” : des endroits de non-mixité pour s’exprimer librement
• full remote : le nouvel eldorado des tech : permet de recruter beaucoup plus, mais c’est aussi plus de concurrence

Pour conclure, aujourd’hui et en 2023 on veut tendre vers un contrat psychologique plus solide, essayer de rassembler le plus des critères ci-dessus, et si ce n’est pas le cas dans notre entreprise : changer de job !

Mon avis

C’est toujours intéressant de connaitre les tendances du marché de l’emploi. Ce qui se passe pour nous dans notre entreprise n’est pas forcément représentatif et avoir une vision de ce qu’il se passe ailleurs permet d’analyser notre propre situation pour éventuellement choisir de partir ou pas.

Attention quand même : pour moi, tout ce qui s’est dit est probablement valable pour une bonne partie de la tech, mais ça ne peut pas représenter la totalité des entreprises.

Damien est “cool” à écouter en tout cas 😉.

Les post-mortems ou comment sortir heureux d’un carnage

Par Lise Quesnel

Lorsqu’une MEP, un projet, une réunion se passe mal, il peut être nécessaire de faire comprendre ce qu’il s’est passé pour ne plus reproduire.

Ce qu’il ne faut surtout pas faire :

• ne pas parler des problèmes
• garder les infos pour soi
• blamer les autres
• ne rien changer

Ce qu’il faut faire : un “post mortem”.

Un PM, c’est un échange productif qui fait suite à un (gros) échec, dont l’objectif est de comprendre et de s’améliorer. Il s’applique uniquement lors d’un événement ponctuel. Il faut rassembler tous les acteurs qui ont participés à cet événement.

Comment le mettre en place :

• planifier : pas trop tard mais pas trop tôt non plus
• inviter les personnes pertinentes
• définir les rôles (animateur, time keeper, scribe)
• poser un cadre (rappeler l’objectif, critiquer les process et non les personnes, écoute active => construire un environnement sain)
• revenir sur les faits (datés, objectifs, sans jugement)
• cibler les “pain points” (se concentrer sur l’important)
• analyser

Lors de l’analyse du problème, il faut répondre aux cinq pourquoi jusqu’à remonter aux causes racines. Ensuite, on détermine quelles sont les causes les plus importantes à traiter en priorité et on cherche une solution avec un “brainstorm” par exemple. Enfin, on agit pour s’améliorer, sinon ça ne sert pas à rien : définir des actions claires avec des échéances et des responsables.

Mon avis

Pas de surprise ici, le sujet était clair, on savait ce qu’on allait voir et c’est ce qu’on a eu. Les slides étaient bien faites et allaient droit au but.

Seul bémol (pour moi) : la gestion du temps encore. 26 min (hors questions), c’est trop court sur une conférence de 45 min.

Conclusion

C’est la fin de la première journée. L’organisation est impeccable, les talks sympas et surtout j’ai pu voir quelques collègues et amis !

Un peu “vané” quand même : prendre des notes sur les conférences, c’est clairement plus fatiguant que d’être spectateur passif.