BDX I/O 2024 : on y était !

Une semaine après l'Agile Tour Bordeaux, la conférence BDX I/O ouvrait ses portes pour une journée de talks. Cette année était placée sous le signe de l'IA et des LLMs.

Christophe, Jérémie et Laurent y ont représenté Wanteeed et vous font ici un récapitulatif de quelques conférences.

LLM : entre fantasmes et réalités

par Marie-Alice Blete

Dans cette keynote d'ouverture, on va parler notamment des promesses liées à l'apport des LLM dans nos métiers avec la réalité des études à posteriori. Et de la prudence à adopter dans l'interprétation des chiffres avancés.

Productivité :

• Etudes à priori évoquent une vitesse de codage 2 fois plus rapide, un coût du développement qui baisserait de 20 à 45%
• Constat à posteriori : 26% d'augmentation de productivité (en se basant sur le nombre de pull requests)
• Mais : cette augmentation quantitative s'accompagne d'une baisse qualitative, avec davantage d'échecs de build

Augmentation de quantité de code généré par l'IA

On parle de "25% du code google généré par l'IA". Est-ce 1 feature sur 4 qui est développée par une IA ? Ou est-ce que l'IA contribue à 25% du code de l'ensemble (par exemple avec de l'hyper auto-complete) ?

Enquêtes sur l'adoption de l'IA par les devs

L'enquête StackOverFlow de cette année évoque 63% de devs utilisant des outils d'IA dans leur process de développement... et montre aussi une plus grande déception vis-à-vis des attentes.

L'utilisation de l'IA est corrélée avec une forte baisse de fréquentation de SOF. 2 conséquences :

• moins de partage dans la communauté tech
• l'IA va avoir moins de contenu pour s'entraîner => baisse de qualité des futures réponses de l'IA ?

Facilité d'adoption des LLM dans les projets de dev ?

Certains outils promettent une facilité d'utilisation, avec juste quelques lignes de code, démo avec effet Wahou à l'appui. En pratique, pour avoir quelque chose d'exploitable en production, besoin d'ajuster énormément de paramètres avec une courbe d'apprentissage longue.

Exemple de Komodo Health qui a construit un produit complexe qui orchestre plusieurs petits LLM spécialisés, combinés à des requêtes en base de données et autres sources d'informations.

Retour d'expérience d'une scale-up : impacts du passage à l'échelle

par Charles Bouttaz et Guillaume Ehret

Objectif : multiplier par 30 les effectifs d'une entreprise en 10 ans !

Problématiques et solutions rencontrées :

• ops deviennent un goulet d'étranglement
  • migration vers le cloud et automatisation
  • shift left ops pour autonomiser les devs sur ces sujets. Ops prennent un rôle de support DEX
• pénurie de devs (contexte post-covid) et difficulté à trouver les bonnes personnes
  • amélioration du process d'onboarding
  • focus sur les soft skills
  • travail sur le career path
• Grossissement du périmètre fonctionnel avec forte charge mentale et difficile montée en compétence
  • split fonctionnel. Réflexion sur les Bounded Contexts.
  • Enjeu de gouvernance avec nécessité de bien séparer les responsabilités d'équipes sur les périmètres
  • split des équipes (loi de Miller, "pizza rule")
  • garder une proximité entre les domaines qui ont le plus d'interactions
• Déséquilibre entre la technique et le métier
  • constitution d'équipes transverses avec dev, PM, ops, QA
• Baisse de qualité, augmentation des bugs
  • mieux caler les tests avec le métier
  • stabilisation de tests flaky
  • réduction de taille du System Under Test
  • mise en place d'une communauté de pratique
• problématiques de sécurité et droits d'accès
  • utilisation des github code owners
  • éclatement du monorepo en projets distincts

Simplifiez la conteneurisation de vos idées

par Thomas Da Rocha

Constat : la syntaxe des Dockerfile est aride et il n'y a pas vraiment de bonnes pratiques de référence.

Proposition de solution : Dofigen (pour DOcker FIle GENerator), un projet open-source développé par le speaker pour se faciliter le travail. Dofigen utilise une syntaxe en YAML ou en JSON avec un système de Descripteur qui va permettre de générer le Dockerfile.

/e/OS : mon smartphone Android sans Google

par Benoît Masson

L'OS Android nativement installé sur la plupart des smartphones se base notamment sur les "services google" pour fonctionner, ce qui constitue une fuite de données personnelles et une centralisation de ces données par un acteur unique.

/e/OS est un écosystème Android "dégooglisé" :

• n'utilise pas les serveurs Google
• permet l'accès à un store alternatif d'applications
• donne accès à davantage d'options sur la protection de la vie privée. Par exemple la falsification de position pour les applications qui nécessiteraient inutilement l'activation de cette fonctionnalité.
• lutte contre l'obsolescence
  • allège la consommation de mémoire par l'OS
  • améliore l'autonomie de batterie
  • prolonge l'accès aux mises à jour (exemple d'un Samsung Galaxy S4 de 2013 utilisé et mis à jour jusqu'en 2023)

The 20 most profitable TS minutes of your life

par Aurélien Loyer et Delphin Aubin

Quelques conseils pour tirer le meilleur parti de TypeScript !

• utiliser le strict mode pour maximiser l'intérêt
  • mais difficile dans le cas de la migration d'une ancienne codebase JS => typescript-strict-plugin facilite cette migration en permettant une adoption progressive
• utiliser les type predicates avec le mot clé is pour aider TS à mieux typer
• utiliser le type never en fin de switch case, pour s'assurer qu'un code est inatteignable
• flavoring pour contrer le duck typing intempestif (par exemple si on veut distinguer les alias de type IdA et IdB qui sont tous deux des alias de string)
• overload de méthode pour créer différentes signatures possibles
• template litteral types
  • permet de générer des combinaisons de types très facilement
  • permet de typer des strings devant respecter un pattern spécifique

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

par Gaëtan Eleouet

Constat : 72% des failles de sécurité proviennent du code applicatif. Nécessité pour les développeurs d'être sensibilisés aux différentes failles.

Le projet OWASP recense ces failles et présente chaque année un classement des failles les plus fréquentes.

Parmi elles :

• révélation à l'utilisateur d'informations internes
• injections SQL
• attaques CSRF
• attaques SSRF
• accès à des données d'un autre utilisateur, par ex. en changeant un id dans un endpoint
• attaques XSS
• hash trop faibles

Quelques conseils supplémentaires :

• validation dans le frontend est insuffisante, toujours valider aussi dans le backend
• white lister les propriétés transmises par l'utilisateur. Les DTO ne doivent pas (ou pas nécessairement) coïncider avec la structure des entités en BDD
• garder ses dépendances à jour (par ex. avec dependabot)
• ne pas avoir ses pages admin accessibles depuis un réseau public

"Pull Request" professionnel : promouvoir son travail en interne

par Vanessa Perillat

A l'école, on est en principe récompensé quand on fait bien son travail, sans avoir à le demander. En entreprise, c'est différent : il faut savoir mettre en valeur ses réalisations.

3 piliers :

• visibilité : dans le monde de la recherche "si tu ne communiques pas, tu n'existes pas".
  • savoir quand dire "je" et pas "on"
  • participer à des projets stratégiques : "de loin, on ne voit que des cathédrales"
  • poser des questions !
• initiative :
  • demander, ne pas attendre qu'on vous propose
  • proposer de l'aide à son équipe pour résoudre des poblèmes
  • changement de mindset : se placer du côté de l'action
• réseau professionnel
  • l'entreprise n'est pas seulement un pourvoyeur de salaire. Constitue aussi une banque de ressources : conseils, collaboration... l'entreprise n'est pas qu'une fin, c'est aussi un moyen !
  • repérer les personnes d'intérêt
  • miser sur les personnes qu'on apprécie
  • entretenir le lien

Conseils / références supplémentaires :

• mindset de gratuité : on donne avant de recevoir
• question de timing : les plats ne repassent pas ! saisir les opportunités quand elles passent !
• savoir s'attribuer ses succès
• livre Les règles du jeu de Clara Molay

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

par Alexis "Horgix" Chotard

Définition proposée du terme "incident" : ce qui éloigne du travail planifié avec un certain degré d'urgence".

Il y aura toujours des incidents, il faut se préparer à les traiter. Quelques conseils :

• identification et mesure de sévérité
  • si quelqu'un pense qu'il y a un incident, c'est probablement le cas : ne pas sous-estimer les alertes, notamment des utilisateurs
  • ne pas essayer de trop définir le niveau d'urgence. Les matrices de calcul sont des usines à gaz qui n'apportent pas grand chose.
  • exemple de Payfit : 4 niveaux d'urgence. On estime au jugé et en cas d'opinions différentes, on favorise la sévérité à la hausse
• humain et organisation
  • définir un rôle de "incident commander"
    • communique sur l'incident
    • orchestre l'enquête
    • se concentre sur l'impact et prend du recul
    • qui ? souvent, celui qui a déclaré l'incident, ou l'engineering manager de l'équipe la + proche du domaine de l'incident
    • attention à donner le bon niveau d'info (pas trop technique), de la visibilité sur la suite
    • reste réaliste et transparent
    • fait preuve d'empathie !
  • canaux de communication
    • avoir 1 canal de communication (par ex. channel slack) dédié par incident où ont lieu tous les échanges
• avoir 1 canal générique pour tous les incidents, avec un thread unique pour chaque incident, qui récapitule les updates "officielles", synthétiques
• astreintes
  • ne pas sous-estimer le coût en argent et en organisation !
• outils et pratiques tech
  • alerting : monitorer ses métriques métier. Outils comme Datadog, Honeycomb, Prometheus & AlertManager
  • escalade: outils comme slack et PagerDuty
• communication sur l'incident
  • selon le besoin de l'entreprise : avoir une status page avec un système de souscription pour être tenu informé
  • challenge est de garder cette communication à jour : risques d'oubli, problématiques de traduction, enjeux juridiques de formulation...
  • communication peut être intégrée dans l'app, par ex. une bannière, des notifs...
• résolution :
  • stabiliser l'incident !
  • limiter l'impact, par ex. avec un mode dégradé
• s'améliorer en continu !
  • mesurer ! par ex. indicateurs MTBF, MTTR, MTTA, MTTF. Identifier le moyen de détection, la fréquence, le temps passé...
  • faire un post-mortem
  • garder un registre centralisé des post-mortems
  • ne pas blâmer individuellement !

HTMX, ou le retour de l'AJAX dans le développement Web

par Stéphane Trebel

Et si on revenait aux fondamentaux du Web plutôt qu'utiliser (et migrer) vers le dernier framework à la mode ?

C'est l'ambition de la lib HTMX qui utilise la base du Web pour fonctionner : HTML et HTTP (via AJAX).

Le principe ? Des attributs dans le code HTML permettant de communiquer en AJAX avec un serveur qui retourne des fragments d'HTML afin modifier le contenu de la page en fonction des actions utilisateurs.

Entre autre démo très impressionnante d'un "infinite scroll" fait en quelques lignes de HTML.

Causalité et Statistiques, un amour pas si impossible que ça

par Denis Maurel

L'orateur aborde comment la méthode scientifique peut aider à mieux comprendre les relations de cause à effet dans les données. Il explique d’abord que, si les statistiques révèlent des corrélations, elles ne suffisent pas pour établir la causalité (avec un exemple classique : est-ce que faire du vélo réduit le taux de cholestérol ? - facteur tiers : l'âge). Il modélise les interactions existantes sous la forme d'un graphe dirigé.

C’est ici qu’intervient le do-calculus, une méthode permettant d’analyser l’effet d’une action en "simulant" ce qui se passerait si cette action était réalisée, tout en isolant les autres facteurs influents.

Pour illustrer cette approche, il présente l’utilisation de la librairie DoWhy, un outil de machine learning conçu pour tester des hypothèses causales directement dans les données.

En combinant ces techniques, il montre comment construire des modèles plus interprétables et précis, qui permettent de prendre des décisions mieux informées dans des contextes complexes.