BDX I/O 2024 : Innover et Réfléchir aux Enjeux Sociaux des Technologies de Demain 2/2

Ce second article vient compléter les retours autour de la conférence BDX I/O 2024.

Si vous avez manqué la première partie, elle est accessible depuis ce lien

Karpenter, le futur de la gestion des noeuds Kubernetes

Mahieu Corbin, Komodo

Rédacteur : Manuel PAYET

Cette présentation est un REX de la mise en place de Karpenter chez Qonto.

Mathieu Corbin commence par nous rappeler comment gérer la scalabilité d’un cluster EKS sur AWS avec les “solutions classiques” kubernetes, avec un cluster autoscaler sur kubernetes. Cela nécessite de créer autant d’autoscaler groupe aws que de typologie de node kubernetes que l’on veut avoir, multiplié par autant d’AZ.

De plus, la répartition des pods sur les nodes n’est pas optimale, et on se retrouve systématiquement avec des noeuds sous-utilisés.

Karpenter a une approche différente, qui va tout au long de la vie du cluster, créer des noeuds, en supprimer d’autres, arrêter des pods pour les scheduler sur d’autres nodes afin d’optimiser le nombre de nodes nécessaires. Cela simplifie également les montées de versions et les mises à jour des OS sous-jacents.

Le speaker arrive à nous convaincre que Karpenter est le futur de Kubernetes en terme de scalabilité, aussi bien sur AWS, Azure, ainsi que sur les autres providers, et même on premise (Karpenter est désormais géré par la CNCF, et n’est plus un projet gouverné par AWS)

Comment utiliser le NoCode comme un microservice dans une architecture logicielle complexe

Benjamin Buléon

Rédacteur : Arthur Berthiaux

J’aurais plutôt nommé cette conférence “Comment amener nos standards de développement dans le NoCode”, mais reste que le fond du sujet est intéressant.

Au travers de ce lightning, Benjamin nous propose de ne plus subir l’intégration de solutions NoCode dans nos architectures mais plutôt d’y amener nos bonnes pratiques de développement afin de gagner en stabilité et en confiance dans nos réalisations.

A ce titre, Benjamin nous a présenté la façon dont il a réussi à harmoniser les communications avec la solution NoCode “Make” sous forme événementielle pour se conformer à leur Architecture du Système d’Information et utiliser les outils déjà en place.

Ce sujet me tient particulièrement à coeur ayant déjà pu mener ce débat et ces évaluations par le passé. Dans cette veine, Benjamin nous dresse ainsi une liste de considérations non fonctionnelles (gestion des environnements, versioning, déploiement) qu’ils ont solutionnées dans ces outils parfois assez cadenassés en exploitant certains paramétrages (utilisation de paramètres d’entrées globaux, exports, etc).Le travail est toujours en cours chez eux afin de poursuivre l’harmonisation des pratiques alors, “Stay tuned for the next episode”. 

Les 20 minutes Typescript les plus rentables de votre vie !

Aurélien LOYER, Software engineer @ QIMA et Delphin AUBIN, Expert Javascript & Tech lead @ Zenika

Rédactrice : Khadija Abdelouali

Ce Lightning talk présente un nombre de tips utiles pour éviter d'avoir des erreurs au runtime liées au typage TypeScript :

  • Typescript Strict plugin : passer le strict à false dans la config TypeScript permet certes d’ignorer les problèmes de compilation mais en même temps on perd 80% des features Ts. Le plugin Strict permet une strictness progressive et une détection plus facile des erreurs strict 
  • asserts signature : indique qu’une condition est respectée dans la valeur de retour de la méthode. Mais il faut l’utiliser avec précaution 😉
  • Type Guards : permet de vérifier le type d’une variable en utilisant typeof afin d’assurer la sécurité du type de variable (type safety), améliorer l’autocomplétion des IDEs et surtout éviter les erreurs lors du runtime
  • Discriminated Union Type : utilise une propriété commune pour différencier les types, ce qui permet de gérer chaque cas en toute sécurité et d'éviter les erreurs.
  • Duck typing : signifie qu’un objet est accepté comme d’un certain type s’il possède les bonnes propriétés, peu importe son type déclaré.
  • Flavouring : permet de créer des types uniques à partir de types primitifs, afin de les distinguer facilement et éviter les erreurs, sans modifier leur structure de base.
  • Function overloading : permet à une fonction d'avoir plusieurs signatures avec des types d'arguments et des types de retour différents. TypeScript détermine quelle version de la fonction appeler en fonction des arguments fournis.
  • Template literal : permet de créer des chaînes avec des expressions grâce aux backticks et ${}. Il permet aussi d’écrire des chaînes sur plusieurs lignes.

Je malmène ta prod en direct avec 15 failles de sécu

Rédacteur : Gaëtan Bremond

Saviez-vous que 72 % des failles d'applications web sont liées à des problèmes dans le code applicatif, bien plus que dans l’infrastructure ou le réseau ? Cette conférence ludique et percutante vous emmène dans un scénario où Marie-Antoinette affronte Napoléon sur KimQoa, révélant 15 vulnérabilités, illustrées avec humour et pédagogie.

Au programme, découverte des erreurs courantes comme :

  • des champs sensibles non masqués (CWE-549), 
  • des injections SQL (CWE-89), 
  • la notion d’authentification VS authorisation (CWE-639),
  • la faiblesse de la mécanique de récupération de mot de passe (CWE-640)
  • ou encore des failles CSRF et XSS,
  • et bien d’autres encore…

Cette conférence nous amène à réfléchir sur notre responsabilité en tant que dev, sans solution miracle, mais avec une culture nécessaire pour éviter de tomber dans ces pièges classiques (top 10 OWASP, CWE, etc.). Venez découvrir comment protéger vos applications... et éviter que votre prod ne soit "malmenée" ! 🚀

Game over pour le design

Jules Mahé

Rédacteur : Arthur Berthiaux

Si j’ai déjà les idées bien arrêtées (et des réponses bien senties) lorsqu’on me dit que l’IA va remplacer mon travail de développeur, cette conférence s’adressant au monde du Design m’a de suite interpelé. 

Les atouts de l’IA appliqués au travail de production sont indéniables et peuvent permettre d’accélérer et de gagner en qualité sur certains travaux voire en se projetant de fournir des outils de mise à jour automatique de Design Systems en fonction d’évolutions contraintes règlementaires ou d’accessibilité par exemple.

Filant la métaphore avec la révolution de la photographie qui a bouleversé en son temps le monde de la peinture, Jules nous invite à ne pas avoir peur d’une IA remplaçant le métier de designer mais de l’utiliser comme une opportunité pour réinventer ce métier et booster la créativité dans un univers Digital où  la standardisation et l’uniformisation sont de plus en plus présentes. Là où l’IA propose de la génération de résultats très “lisses” voire “trop” parfaits, que ce soit sur de la génération de textes ou d’images par exemple, de plus en plus de designers et artistes prennent le contrepied en proposant des résultats “imparfaits” et donc humains.

Enfin, en analysant quelques signaux faibles et en poussant le curseur (avec des exemples allant de Snapchat Pixy à Lena situations), Jules va même jusqu’à imaginer un monde où les interfaces se feront de plus en plus rares et où la question du “AI generated or not?” ne sera plus qu’un ancien débat.

En bref, un appel à la reconnexion au réel et ça fait du bien.

Pull Request Professionnelle : Comment promouvoir son travail en interne

Vanessa Perillat

Rédacteur : Arthur Berthiaux

Au travers de cette conférence, Vanessa tente de nous faire réfléchir à ce que représente la réussite au travail, et comment elle se matérialise pour chacun d’entre nous.

Avant toute chose se pose la question de la motivation : quels sont les objectifs qui nous animent (je vous invite à essayer l’atelier Moving Motivators qui permet justement de se pencher sur cette question) et quelles sont nos valeurs non négociables. Ce sont ces fondations qui nous permettront de “réussir professionnellement” tout en restant authentiques et en assumant nos opinions en entreprise (sans épuiser notre “capital sympathie” comme le dit très bien Vanessa).

Le maître de mot de l’intervention : le “savoir-faire” est la base de notre travail, afin de le transformer en réussite nous devons travailler le “faire-savoir”. Pour cela, 3 axes principaux à travailler : 

  1. Visibilité - “Si tu ne communiques pas, tu n’existes pas”. Cette phrase tirée du monde de la recherche est particulièrement vraie, et à ce titre il est important de partager sur nos réalisations (réussites comme échecs), en utilisant (à bon escient) le “je” plutôt que le “on”.
  2. Initiative - “Vous aurez rarement ce que vous méritez, plus souvent ce que vous irez chercher”. Il est important de travailler les Softskills autant que les HardSkills : sachez sortir du strict scope de ce qui vous est demandé, proposez des choses. Et surtout, investissez sur vous et misez sur ce que vous aimez : c’est la meilleure façon d’apporter des bénéfices pour vous ET pour votre entreprise.
  3. Créer/Entretenir son réseau - “Renversez les perspectives”. Vous seul n’êtes pas une ressource : l’entreprise est une ressource en personnes inspirantes et expérimentées. Utilisez-la comme un moyen, connectez vous avec des personnes intéressantes et que vous appréciez.

Enfin sachez saisir les opportunités qui arrivent et dans le bon timing : même si nous souffrons pour beaucoup du syndrome de l’imposteur, il est important que nous réussissions à nous sortir du sentiment d'illégitimité et d’une quête de perfection illusoire afin de ne pas laisser l’occasion du siècle !

Sécurité automatisée - Regardez vos failles en face.

Marine du Mesnil

Rédacteur : Paul Anaclet

Lors de cette conférence, Marine du Mesnil met en lumière les défis de la sécurité dans le développement applicatif. Elle commence par un constat inquiétant : près de 50 % des sites web présentent des failles critiques, souvent négligées par manque de connaissances ou de responsabilité. Pour remédier à cette situation, l'automatisation est essentielle, que ce soit avec des outils comme Semgrep et Sonar, des linters ou autres.

De plus, des méthodes inspirées du Lean, comme le QRQC (Quick Response Quality Control) et le « shift left » soit l’intégration de mesures de protection dès la conception sont abordées. Malgré la difficulté de mise en place au début, elles ont une vraie valeur ajoutée et permettent d’automatiser la détection au plus tôt des failles afin de les corriger immédiatement avant le déploiement en production.

En conclusion, elle recommande l'automatisation, une collaboration renforcée entre équipes, et l’usage de la QRQC pour réduire les failles.

Alerte, tout brûle ! Comment gérer des incidents techniques

Présentation par Alexis Chotard de chez Payfit sur l'évolution de la culture de gestion des incidents chez payfit. 

Rédacteur : Adrien Delcourt

Autour d'un cas type (les serveurs sont tombés) et d'un cas fictif (les bouteilles de vin de BDX I/O seraient imbuvables), Alexis nous entraîne sur la définition de ce qu'est un incident (en résumé : tout ce qui entraîne un imprévu lors de la journée planifiée de travail) et son niveau de sévérité (de : on verra ça plus tard, à : code rouge la boite risque de couler). L’accent est mis sur la communication et l’empathie entre tous les acteurs : pour les client·e·s, pour les chargé·e·s de clientèle qui sont en première ligne, pour les collègues qui gèrent une situation stressante. Une deuxième partie est consacrée à la boucle de feedback sur la détection d'incidents jusqu’à leur résolution, avec la mise en place du rôle d’incident commander qui prendra du recul et pilotera la gestion de l'incident. Un point d’attention est mis sur la stabilisation de la plateforme avant de chercher dans le détail le problème et sa correction. Les outils et l'organisation autour de la gestion d'incidents sont à faire évoluer en continu pour répondre au mieux aux besoins de croissance de l'entreprise. Il ne faut pas négliger les post mortem pour comprendre et améliorer la plateforme sur le long terme.

En conclusion :

  • l'importance de s'outiller correctement pour avoir les bonnes remontées
  • se faire confiance et faire confiance aux collègues
  • l'astreinte coûte très cher, et plus encore si les outils ne sont pas adaptés
  • avoir de l'empathie et savoir rester zen.

Angular change de logo mais pas que.

Rédacteur : Gaëtan Bremond

Depuis ses débuts en 2009 avec AngularJS, puis sa refonte majeure en 2016, Angular s'est imposé comme un framework incontournable pour le développement front-end. Avec Angular 18 en 2023, une dynamique nouvelle souffle sur le framework grâce à des évolutions pensées pour la performance, l'expressivité et la simplicité.

Les nouveautés marquantes :

  • Standalone Components : une fusion ingénieuse des modules et composants, permettant de créer des éléments indépendants avec leurs propres imports. Cette approche simplifie la structure des applications tout en maintenant les services partagés comme des singletons.
  • Control Flow modernisé : des directives comme @if, @let offrent une lisibilité et une gestion du flux nettement améliorée.
  • Signals : cette innovation révolutionne la détection de changement en mettant à jour uniquement les composants concernés. Fini les re-calculs inutiles grâce à des gains de performance significatifs et une compatibilité avec RXJS via toSignal et toObservable.
  • Lazy Loading optimisé : non seulement les routes, mais aussi les composants, peuvent désormais être chargés de manière différée avec @defer, qui s’adapte à des triggers précis.

La migration simplifiée

Des schematics sont disponibles via la CLI pour guider la transition vers ces nouvelles fonctionnalités, notamment pour les standalone components et les nouvelles structures de contrôle. Attention toutefois : certains aspects comme le routing et le nettoyage des fichiers modules nécessitent encore des ajustements manuels.

En 2024, Angular continue d’évoluer pour répondre aux besoins des développeurs avec des outils puissants, rétrocompatibles et performants. Une conférence à ne pas manquer pour vos projets Angular si vous souhaitez vous tenir à jour ! 🚀

Microservices Kotlin Benchmark : coroutines, virtual threads, grpc, http… le match !

Présentation de Xavier HANIN, Directeur Technique / Associé chez 4SH

Rédacteur : Vincent Colas

Le speaker nous présente sa démarche de benchmark de la performance des serveurs Web dans l’écosystème Kotlin, à la recherche du backend efficace.

Il exécute les tests de performance en live, nous fournit son analyse comparative et prodigue quelques conseils & grands principes. Il revient également sur les concepts clef de la parallélisation des traitements, de Kotlin au Kernel en passant par la JVM.

La conférence est bien rythmée, alternant présentation de concepts, de solutions, sollicitation du public, suivi du déroulement des tests, avec à la clef des résultats inattendus et une subversion des attentes.

En fil rouge, le timing très serré du talk, et l’anxiété croissante du speaker, qui doit lui-même paralléliser et jongler entre ses différents supports - délicieusement méta. 

Protocole de test

L’idée est de tester la performance des backends en utilisant le code le plus simple / le plus standard possible, si possible tout droit sorti de la documentation technique de la solution évaluée, tout en adoptant des configurations out-of-the-box : pas de fine-tuning.

Le scénario de test vise à retranscrire un use case assez typique de backend applicatif, faisant appel à une base de données et à un service externe, et ce à plusieurs reprises. Ci-après une description technique du contexte de test :

  • Jeu de données de test (qui conditionne le nombre N) : 100K items, 200 matches, limit 2
  • Nombre d’appels à la base de données : N+1
  • Nombre d’appels à un service externe : N
  • Protocole pour appel au service externe : gRPC ou HTTP
  • JVM : Temurin 21 alpine, 4 cores, 7gb RAM
  • MongoDB : large, 8 cores, 8 gb RAM
  • Service externe : stub / mock retournant des données statiques
  • Outils d’exécution des tests de performance : K6, warmup script pour stimuler la JVM
  • Volumétrie des tests : 200 virtual users, 1 minute ininterrompue
  • Cluster K8S : 4 nodes, 8 cores, 8 gb RAM

Plusieurs stacks techniques sont évaluées tour à tour, du grand classique qui domine le marché, au challenger qui promet monts et merveilles. On voit donc s’affronter :

  • SpringBoot vs Ktor vs Armeria
  • HTTP vs gRPC
  • Platform Threads vs Coroutines vs Virtual Threads

C’est bien le même cas de test qui est implémenté plusieurs fois, mais chaque variante apporte son lot de différences non maîtrisées. A mon sens, cela teinte grandement les résultats, d’autant plus que ce qui constitue l’implémentation “type” du scénario de test à l’aide d’une technologie est extrêmement subjectif.

Reste à savoir comment déterminer la stack gagnante, et ce que le speaker choisit de mesurer, c’est avant tout le nombre de requêtes traitées par seconde, mais aussi le délai de réponse médian et sa constance : il vise un 90ème percentile bas, et un faible écart-type.

Résultats

Bruts de décoffrage, incomplets, capturés à la volée sur la sortie standard du terminal du speaker :

  1. http + spring boot + platform threads: 2500 r/s (p90 108ms - max 374ms)
  2. http + ktor + coroutines: 1400 r/s
  3. http + spring boot + virtual threads: 3200 r/s (p90 78ms - max 262ms)
  4. grpc + armeria + platform threads: 340 r/s (p90 600ms)
  5. grpc + armeria + coroutines: 4200 r/s (p90: 57ms)
  6. grpc + armeria + virtual thread: similaire aux coroutines

Une brève analyse met en valeur que les clients gRPC sont plus rapides que les clients HTTP (mis en lumière par l’appel au service externe). Du côté des virtual threads et des coroutines, au-delà du modèle de programmation différent et des divergences dans l’approche conceptuelle, les performances sont très similaires (dans la limite du cas de test couvert par ce benchmark).

Le mot de la fin du speaker, c’est que ce benchmark n’est pas très représentatif - à chacun de produire le sien, d’implémenter un scénario de test adéquat, et d’adapter la configuration de manière itérative afin de trouver la meilleure performance pour un cas d’usage donné.

Keynote de fermeture : Si l'IA peut créer de la musique, à quoi servent les musiciens aujourd'hui ?

Nirina RABESON - Zenika

Rédacteur : Manuel PAYET

Cette keynote de fermeture m’a surpris (dans le bon sens 🙂), 

Entre sudoku, cours de musique, chant et rappel de la différence de perception entre une machine et un humain… l’auteur nous rappelle avec humour ce que ne sait pas faire une machine : comprendre les sentiments humains. 

Il est difficile de décrire cette conférence, alors je vais vous mettre ici la conclusion du conférencier, Nirina RABESON :

L’émotion n’a pas de mots, et c'est pour ça qu'elle se traduit si bien en musique.

Conclusion 

Au travers ces deux articles, la richesse des interventions ainsi que des sujets sont incroyable et nous tenons à remercier l'ensemble des orateurs et oratrices pour la qualité des interventions qui fait de BDX I/O un rendez-vous incontournable de la scène technologique bordelaise.

Cet évènement ne serait pas ce qu'il est sans l’équipe d’organisation qui offre un cadre exceptionnel de bienveillance et nous prenons plaisir chaque année à participer à cet évènement.

Pour revivre l’ensemble de la conférence BDX I/O édition 2024, n’hésitez pas à vous rendre sur la chaine Youtube.

Nous vous donnons rendez-vous l'année prochaine pour l'édition 2025.