Du 20 au 22 avril, Devoxx France revenait en grande pompe après une session 2020 repoussée en fin 2021 et fortement restreinte pour cause de Covid. La conférence des développeurs est devenue une référence depuis son lancement en 2012. Quelques chiffres pour mesurer l’importance de l'événement : 3 200 personnes, 261 speakers, plus de 200 slots. WeScale y était pour suivre des conférences et partager notre savoir-faire.

Les grandes tendances de DevoxxFR

  • L’écologie est au cœur des préoccupations, mais force est de constater que dans l’IT le sujet en est encore à ses balbutiements. Une seule solution : consommer moins et mieux.
  • L’inclusion, homme, femme ou non-binaire, la communauté cherche à s’ouvrir et à combattre l’entre-soi de mâle alpha.
  • SRE, DevOps et management 3.0 sont incontournables et attirent les techs. Nous y voyons le souhait de liberté, d’autonomie et de sentir l’impact de son travail.

Côté technique, Kotlin, Kubernetes et l’usage de la data pour améliorer les produits ont le vent en poupe. Il n'y a toujours pas de consensus autour des architectures micro-services. Pour certains c'est la solution idéale, pour d'autres c'est de l'over engineering. Doctolib a d’ailleurs fait le choix de la “boring architecture''. Ajoutons ici, que les framework Quarkus et Micronaut font le buzz.
Dernier point, le NoCode ne fait pas partie de l’équation contrairement à l’amélioration de l’expérience de développement.

Notre sélection de slots

Dans les coulisses du Cloud

Cécile MORANGE est venue parler des briques de base du Cloud et de leur assemblage. Ce bidule qu'on consomme tous les jours en tant que développeur ou opérateur a été démystifié. Cécile a détaillé méthodiquement les contraintes électriques et le câblage pratiqué chez Aquaray.

La partie la plus intéressante du slot a porté sur la structure du réseau. Cela a commencé par un court rappel sur l'organisation d'Internet et le protocole BGP. Puis, nous avons pu comprendre à quel niveau les Cloud providers se branchent et étudier des cas récents de grosses pannes réseau. Une randonnée rafraîchissante dans les couches les plus basses du modèle OSI.

Parmi toutes les personnes qui animent la communauté tech française, combien auraient eu les tripes de monter sur la scène de Devoxx à 21 ans ? C'est une joie de voir cette relève (tiens, j'ai mal au genou, il va pleuvoir…) se prêter à l'exercice du partage de connaissance.

Kotlin, Java 4..18, Code coverage and their best friend – bytecode: scandales, intrigues, investigations

Evgeny Mandrikov, contributeur majeur de JaCoCo et employé de SonarSource, nous a emmené dans le monde merveilleux de l’analyse de bytecode JVM avec une mission simple : différencier le bytecode issu du code écrit par un humain de celui généré par les différentes versions des compilateurs Java et Kotlin dans le but de mesurer la proportion de code couverte par des tests automatisés.

De prime abord, le travail de JaCoCo pour analyser le bytecode produit semble simple par la détection du flag ACC_SYNTHETIC apposé par les compilateurs sur le code qu’ils ont fabriqué de toutes pièces. Cependant, ce flag n’est applicable que sur des classes ou des méthodes, pas sur des bouts de code au sein d’une méthode… Evgeny nous a alors guidé dans la jungle de la gestion de la compatibilité ascendante et descendante des énumérations. Les heuristiques y rivalisent d’ingéniosité pour différencier le code humain du code compilateur. Enfin, un petit tour par la case “fonctionnalités du langage implémentées par une astuce syntaxique” a achevé de nous convaincre que la tâche apparemment simple de JaCoCo est en réalité un travail de longue haleine reposant sur le défrichage des versions de nos langages préférés.

Cette présentation a retenue notre attention, notamment parce qu'elle ouvre une voie vers la maîtrise des outils que nous utilisons au quotidien. Les puzzles proposés par Evgeny rendent le discours dynamique et incitent à dépasser le cadre de notre code du quotidien.

Ciel ! Mon Kubernetes mine des bitcoins !

Denis Germain (Zwindler), lead-tech SRE chez Deezer, nous a livré un état des lieux de la sécurité sur Kubernetes. Mais pas seulement !

En effet, nous avons eu également un tour d’horizon des outils et moyens à disposition pour renforcer la sécurité au sein d’un cluster Kubernetes, de conseils également sur la manière de gérer cela. Le tout sentant la bonne odeur du retour d’expérience, sans fioriture.
Il est évoqué par ailleurs l’importance de la gestion de la conformité et comment appliquer une politique de conformité.

Si je devais résumer en une phrase ce talk : C’est le couteau suisse de la sécurité et de la conformité pour Kubernetes !
Que l’on connaisse déjà les outils proposés, les méthodes ou bonnes pratiques, c’est une bonne piqûre de rappel.
La présentation est disponible ici.

S’affranchir de la Pyramide des Tests

Jonathan Boccara de chez Doctolib nous a invités à remettre en cause le principe de Pyramide des Tests. Il a rappelé ce qu’est la Pyramide de Tests, en revenant à ses origines et pourquoi elle existe.
Ensuite, en se basant sur les pratiques de Doctolib il nous a expliqué pourquoi certaines règles de la Pyramide peuvent ne plus avoir de sens dans leur contexte. Du coup Doctolib s’est éloigné de ce précepte de Pyramide et a établi d’autres principes fondateurs pour leur stratégie de test.

Pour illustrer cette idée, un des principes de la Pyramide est : “les tests End To End sont lents à exécuter”. C’est vrai unitairement, un test End to End est plus long à s’exécuter qu’un test Unitaire. Mais à notre époque nous avons la possibilité de mettre à l’échelle le nombre de machines pour exécuter des tests plus rapidement. Donc c’est finalement plus un paramètre de coût qui doit entrer en compte. Jonathan parcourt comme ça plusieurs principes en les challengeant et en proposant des alternatives. La conférence se termine sur l’impact que vous pouvez avoir sur vos tests selon les choix que vous faites. À nouveau un exemple, choisir d’exécuter tous ces tests sur une seule machine vous permet de rester simple, d’avoir un coût d’exécution moindre, mais ils vont par contre s’exécuter lentement.

J’ai apprécié ce slot par rapport à la réflexion menée. Elle permet de se rappeler que quel que soit le précepte que l’on suit, ici la Pyramide des Tests, le plus important est de comprendre le pourquoi. Car dans notre métier dont les contraintes évoluent sans cesse, les solutions peuvent également changer.

Github Co-Pilot : Addictif ou Efficace ?

Github Co-Pilot est présenté par Johan et Simon comme un AI pair programmer.
À la base, il y a un modèle GPT-3 issu d’OpenAI et un moteur CODEX de Github qui ont permis de créer ce nouveau service.
La promesse est de pouvoir écrire son code plus rapidement grâce à des suggestions de code pour des lignes ou des fonctions entières directement dans votre éditeur.

Johan et Simon nous racontent qu’après plusieurs mois d’utilisation, ce service leur a permis d’avoir une meilleure efficacité au quotidien grâce aux propositions, à la découverte de nouvelles bibliothèques ou en découvrant des paramètres de fonctions.
Néanmoins, ils nous expliquent que le service a ses limites et ne propose pas toujours les meilleures implémentations possibles (voire des propositions erronées en utilisant des bibliothèques peu connues).

De mon point de vue, le point le plus limitant étant le fait qu’il ne prend pas en compte les autres fichiers du projet.
Cela peut paraître contre-intuitif, mais c’est un service qui n’améliorera pas la productivité des juniors mais qui pourrait s’avérer utile entre les mains de développeurs confirmés, capables d’avoir un regard critique sur les propositions.
J’ai hâte de voir ce que cela pourrait donner dans le futur.

Comprendre les enjeux de consommation de ressource et d’énergie dans le secteur numérique

Quentin Adam et Pierre Beyssac animaient une conférence autour des enjeux de la transition écologique dans le secteur du numérique.
Au cours de celle-ci, ils nous ont tout d’abord donné un aperçu du cadre général de la consommation de ressources informatiques en définissant quelles sont ces ressources et à quels moments elles interviennent dans le cycle de vie de nos composants.

Ensuite, différents sujets ont été abordés :

  • Les différentes phases de consommation (construction, utilisation, fin de vie) et l’impact du numérique au travers de celles-ci
  • L’importance des variations de mesure (“si on vous présente une étude avec des mesures sans marge d’erreur, fuyez !”).
  • L’importance du pilotage des consommations
  • Les impacts provoqués par le code ou la consommation réseau

Ce slot m’a particulièrement plu, car il a permis de démystifier une bonne quantité d’idées reçues que la plupart des gens ont concernant l’impact écologique du numérique. Quentin et Pierre nous ont par exemple démontré que cela n’avait aucun sens de quantifier l’équivalent carbone de l’envoi d’un mail, car c’est quelque chose qui n’est simplement pas mesurable. On se retrouve alors avec des résultats qui sont des approximations d’approximations ce qui leur fait perdre toute pertinence.

J’ai également apprécié les conseils donnés par les deux orateurs en fin de présentation pour pouvoir agir à notre niveau en fonction de notre poste et de la politique de notre entreprise à ce sujet. Par exemple, une action toute simple et pourtant très efficace est de revendre son ancien appareil lors de son remplacement plutôt que de ne pas s’en servir et de le jeter. Il pourra être utilisé par une autre personne et évitera la consommation supplémentaire de matières primaires pour en fabriquer un nouveau.

La scale-up, l’autonomie et le sous-marin nucléaire

Thomas Pierrain et Pauline Jamin, nous raconte comment, chez Agicap, ils adressent la croissance d’une entreprise qui passe d’une phase startup à une phase ScaleUp.

Leur réponse s’inspire du livre de David Marquet “Turn the ship around” pour responsabiliser et donner de l’autonomie aux équipes techniques.
Les 4 règles qu’ils appliquent sont :

  1. Donner des responsabilités et, pour le management, lâcher prise.
  2. Donner des objectifs clairs, pas des processus
  3. Par défaut, c'est oui !
  4. Créer de l’espace pour penser par soi-même

Ils ont adopté une démarche en Test and Learn pour expérimenter sur ce chemin d’autonomie. Quelques exemples : Un mois de refactoring hors équipe, création de Guilds pour suivre et animer ces sujets hors du backlog des squads, test des OKR. Un slot rondement mené qui décrit une démarche reproductible à voir en replay quand il sera disponible.

En conclusion

Devoxx est une communauté ouverte et heureuse de se retrouver après l’éloignement physique subi pendant la crise Covid. Toujours en recherche d'interactions et de partage pour nourrir sa veille et progresser tant sur les hard que sur les soft skills. Mais c’est aussi une organisation parfaite en termes d’accueil, de tenue des slots, bref une mécanique bien huilée, assurée par les gilets rouges.

Un grand merci aux organisateurs bénévoles qui donnent tant pour faire vivre cette communauté. L’ensemble des slots sera bientôt disponible en replay sur la chaîne youtube de DevoxxFR.