Mon Bdx I/O 2026 à moi !

BDX I/O, c’est une conférence qui se tient cette année sur deux jours. Y étant déjà passée en 2022, j’avais hâte d’y revenir. La programmation était, encore cette année, très variée : développement, cloud, intelligence artificielle, UX, architecture, sécurité, mais aussi inclusion, souveraineté numérique et pratiques professionnelles. Et c’est précisément ce mélange qui me plaît. Parce qu’au fond, nos métiers ne se résument pas à des langages, des frameworks ou des infrastructures. Ils parlent aussi de choix, de responsabilités, de collaboration et surtout, des humains qui conçoivent, utilisent et font vivre nos systèmes.

Cette année, j’avais également le plaisir de monter sur scène, dans le grand amphithéâtre, pour partager à mon tour un sujet qui me tient à cœur. Mais avant et après ce moment un peu particulier, j’ai surtout profité de cette journée pour écouter, apprendre, questionner… et remplir frénétiquement les notes de mon téléphone !!!

Au programme : des enfants et leur rapport au numérique, des bruits de toutes les couleurs, du sexisme dans la tech, de la bande dessinée appliquée à l’UX, une alternative à Spotify, des modèles de machine learning qui vieillissent, des environnements de workshop simplifiés, de la souveraineté numérique… et même l’art de recevoir un compliment. Tout ça dans une seule conférence !

Alors, qu’est-ce que je retiens de cette édition ?

“Comment construire des outils numériques qui apprennent et qui protègent ?” par Estelle LANDRY et Emilie GOUBIN

Il y a des keynotes qui nous font réfléchir. D’autres qui nous font sourire. Et puis il y a celles qui provoquent tellement de réactions dans la salle qu’on se demande presque si on assiste encore à une conférence… ou si l’on participe à une grande discussion collective.
Cette keynote d’ouverture appartient clairement à la troisième catégorie. C’était vivant, impactant et, par moments, terriblement révélateur de la manière dont nos enfants utilisent et comprennent le numérique.

Car oui, grandir avec des écrans ne signifie pas nécessairement maîtriser les outils numériques ! C’est notamment ce que vient questionner le projet Pix Junior, conçu autour des usages des enfants, mais également pensé pour les enseignants qui les accompagnent.

L’objectif ? Mieux comprendre les préacquis et les prérequis numériques des élèves pour permettre aux équipes pédagogiques d’adapter leur accompagnement. Et derrière cette problématique éducative se cachent des questions qui dépassent largement le cadre de l’école : comment apprend-on ? Qu’est-ce qui nous donne envie d’essayer ? Pourquoi persévère-t-on face à une difficulté ? Et comment développer progressivement notre autonomie ? Autant de questions qui ont immédiatement fait écho à mon quotidien dans l’accompagnement des équipes produit.

Un premier concept m’a particulièrement intéressée : la motivation ne se décrète pas. Elle se construit notamment autour de l’intérêt que l’on porte à une activité, mais aussi de l’utilité que l’on perçoit dans ce que l’on fait. Autrement dit, difficile de s’engager durablement dans un apprentissage si l’on n’en comprend ni le sens ni la finalité.
Tiens, tiens… ça ne vous rappelle pas certaines situations dans nos organisations ?

On retrouve alors une forme de cercle vertueux :
S’engager → Persévérer → Adapter son comportement.
Chaque expérience peut nourrir la suivante, à condition de créer un environnement suffisamment encourageant pour permettre d’expérimenter, de se tromper et de progresser.

Autre notion passionnante : le sentiment d’auto-efficacité. Une notion proche de la confiance en soi, mais plus précisément liée à la conviction que l’on est capable de réussir une tâche ou de faire face à une situation donnée. Et c’est là que le parallèle avec nos équipes devient particulièrement intéressant.
Quand on accompagne une équipe dans l’adoption de nouvelles pratiques, d’un nouvel outil ou d’une nouvelle organisation, est-ce qu’on cherche simplement à transmettre une méthode ? Ou est-ce qu’on cherche aussi à lui donner les moyens de se sentir capable d’agir par elle-même ? Pour moi, la différence est fondamentale.

On peut fournir les meilleurs outils du monde, si les personnes qui les utilisent ne se sentent ni compétentes, ni autonomes, ni engagées, l’adoption risque de rester superficielle.

Cette keynote m’a rappelé une conviction que je porte depuis longtemps : accompagner, ce n’est pas faire à la place des autres. C’est créer les conditions pour qu’ils puissent apprendre, comprendre et agir. Une belle ouverture de journée, qui nous invite à regarder autrement l’éducation au numérique… mais aussi nos propres pratiques professionnelles.

Pour suivre Estelle sur les réseaux : estelle-landry
Lien vers les slides - à venir
Lien vers la vidéo - à venir

“La couleur des bruits : Retour d’expérience sur la génération de textures sonores” par Sébastien FERRER

Après les sciences de l’apprentissage, direction le monde du son, de ses fréquences et de ses mystères, avec Sébastien Ferrer. Et cette fois, tout commence par une histoire personnelle : celle d’acouphènes installés dans son quotidien, et d’une recherche de solutions pour rendre leur présence plus supportable. Une problématique très concrète qui va progressivement l’emmener vers le traitement du signal et la création de bruits… colorés ! Parce qu’apparemment, le son aussi a droit à sa palette !

Pour comprendre comment tout cela fonctionne, Sébastien commence par nous ramener aux fondamentaux : l’amplitude, la fréquence et la manière dont un signal sonore peut être représenté puis reproduit par un ordinateur. On parle notamment d’échantillonnage, cette opération qui permet de transformer un signal continu en une série de valeurs numériques.
Et puis arrive le fameux bruit blanc. Un signal aléatoire qui, dans son modèle idéal, présente une densité spectrale de puissance constante selon les fréquences. Dit comme ça, ce n’est pas forcément très parlant. Mais l’idée est de comprendre comment répartir l’énergie sonore sur différentes fréquences… et surtout comment notre oreille et notre cerveau vont percevoir le résultat.
Car c’est là que les choses se compliquent : notre perception des fréquences n’est pas linéaire. Les différentes octaves ne sont pas perçues de manière identique, ce qui rend la création d’un son agréable beaucoup moins évidente qu’il n’y paraît.

Pour illustrer tout cela, Sébastien nous fait découvrir le spectrogramme, en analysant une chanson : une manière ludique de visualiser les fréquences présentes dans un signal et leur évolution dans le temps. Et progressivement, on comprend que le bruit que l’on cherche à obtenir n’est pas nécessairement blanc… mais plutôt rose.
Le bruit rose possède une énergie qui diminue lorsque la fréquence augmente, avec une répartition plus équilibrée entre les octaves. Il peut ainsi être perçu comme plus doux que le bruit blanc.

Sébastien nous présente notamment une méthode de génération combinant plusieurs sources ou composantes de bruit pour obtenir ce résultat. Dans mes notes, j’ai griffonné une histoire de seize bruits blancs combinés, avec des fréquences progressivement ralenties. Je préfère rester prudente sur les détails mathématiques : mon téléphone et moi n’avons visiblement pas réussi à tout capturer ! Mais le principe est passionnant : on part d’un signal aléatoire et, par différentes transformations, on cherche à construire une expérience sonore plus confortable.

On peut ensuite améliorer le résultat grâce au smoothing, autrement dit au lissage (personnellement, j’aurais appelé ça du blush… mais bon, chacun son vocabulaire !).
L’utilisation d’un filtre passe-bas permet notamment d’atténuer certaines fréquences élevées pour adoucir le signal. Et parce qu’une palette ne serait pas complète avec seulement deux couleurs, nous découvrons également :
• Le bruit bleu, qui accentue les hautes fréquences et peut être particulièrement désagréable à écouter.
• Le bruit rouge, ou bruit brownien, beaucoup plus riche en basses fréquences, qui peut évoquer un grondement lointain.

Et les casques antibruit dans tout ça ? Ils reposent sur un principe différent : l’annulation active du bruit, qui consiste à produire un signal destiné à réduire certaines ondes sonores extérieures par interférence destructive. Autrement dit, plutôt que de masquer un bruit par un autre, on cherche à l’annuler.

Pour terminer, Sébastien nous réserve une petite démonstration de stéganographie. Le principe ? Dissimuler une information dans un autre contenu, ici un signal sonore. Et voilà qu’un message « BDX I/O » et un QR code permettant de recueillir des feedbacks se retrouvent cachés dans le son. Une conclusion aussi ludique que technique.

Ce que je retiens surtout de cette session, c’est la manière dont une problématique personnelle peut devenir un formidable terrain d’exploration. On part d’un besoin concret, on explore, on expérimente, on apprend… et on finit par partager le résultat avec toute une salle. Finalement, une belle illustration de ce qui fait aussi la richesse de notre métier : la curiosité au service d’un usage.

Pour suivre Sébastien sur les réseaux : sebferrer
Lien vers les slides - https://blog.kimi.ovh/p/color-of-noises/
Lien vers la vidéo - à venir

“Une femme sur deux quitte la tech, alors qu’est-ce que je fais encore là ?” par Anaïs HUET

Je suis ressortie de cette conférence avec une certaine colère, voire une certaine tristesse, mais aussi une envie très forte de faire bouger les choses.
Le témoignage d’Anaïs Huet appartient clairement à cette seconde catégorie. À 36 ans, elle est toujours dans la tech. Développeuse, agile, passionnée par son métier… et pourtant confrontée, tout au long de son parcours, à une accumulation de situations qui auraient pu lui donner envie de partir.

Son talk prend la forme d’une rétrospective personnelle sur le sexisme ordinaire, les microagressions et les obstacles rencontrés par les femmes dans notre industrie. Et ce qui frappe, c’est que tout commence très tôt : dès les études… Les premières remarques déplacées. Le mansplaining. Les situations gênantes imposées. Puis les stages, avec leurs blagues parfois violentes, trop souvent excusées au nom de l’humour.
« Mais enfin, c’était pour rire ! » Une phrase qui revient souvent dans ce type de situations. Sauf que lorsque l’humour repose systématiquement sur les mêmes personnes, il finit par ressembler à tout autre chose.

Puis vient l’entrée dans la vie professionnelle. Les premières négociations salariales, les écarts qui apparaissent dès l’embauche et qui, année après année, peuvent continuer à se creuser.

Et puis la maternité : ce moment où certaines femmes découvrent qu’une absence pourtant parfaitement légitime peut être interprétée comme une perte de compétences ou de crédibilité. Anaïs raconte notamment cette nécessité de « remise à niveau » évoquée à son retour de congé maternité, venant remettre en question son positionnement professionnel. Comme si quelques mois d’absence suffisaient à effacer des années d’expérience.
Mais au-delà des événements les plus visibles, il y a aussi l’usure quotidienne : être trop affirmée ou pas assez, trop directe ou trop discrète, trop émotive ou pas suffisamment chaleureuse… une injonction permanente à trouver le bon équilibre, dans un espace où les règles semblent parfois changer selon la personne qui les applique.
Et lorsque l’on ose exprimer un désaccord, le risque est encore de se voir décrédibilisée : l’hystérie supposée des femmes reste malheureusement un cliché bien ancré.

Ce qui m’a particulièrement marquée, c’est cette accumulation : une remarque isolée peut parfois sembler anodine à celles et ceux qui ne la subissent pas. Mais lorsqu’elle s’ajoute à des dizaines, des centaines d’autres, elle finit par peser lourd. D’autant que toutes les agressions ne relèvent pas de la maladresse : certaines sont volontaires, verbales, parfois physiques. Et sous couvert de plaisanterie, leurs auteurs peuvent continuer à agir sans être réellement inquiétés.

Alors oui, on peut aimer profondément son métier… et avoir malgré tout envie de quitter un environnement qui nous épuise.
Alors qu’est-ce qui fait tenir ? La réponse d’Anaïs tient notamment en un mot : la communauté. Les réseaux extérieurs, comme Duchess France, Women in Tech ou Yeeso, peuvent devenir de véritables espaces de soutien. Des endroits où l’on peut partager ses expériences, se sentir écoutée, trouver des ressources et réaliser que l’on n’est pas seule.
Mais le soutien ne devrait pas reposer uniquement sur celles qui subissent. Il concerne aussi toutes les personnes qui assistent à ces situations : ne pas rire à une blague sexiste, ne pas minimiser une remarque, laisser la place à la parole, soutenir une personne qui ose objecter…. Parce que prendre la parole demande de l’énergie. Se défendre demande de l’énergie. Et devoir le faire systématiquement, seule, en demande encore davantage. Le simple fait de savoir que quelqu’un d’autre est prêt à intervenir peut faire une énorme différence.

Observer. Prendre conscience. Soutenir : Trois actions qui paraissent simples, mais qui peuvent profondément transformer un environnement professionnel.
Anaïs évoque également des outils permettant de travailler sa répartie. Je connaissais déjà « Muscle ta répartie » de Michèle Ruffaut, mais je repars avec une nouvelle envie : découvrir le jeu Takattak. Parce qu’apprendre à répondre, à poser ses limites et à identifier les mécanismes d’une agression peut aussi aider à reprendre du pouvoir sur certaines situations.

Cette conférence m’a rappelé que l’inclusion ne se mesure pas uniquement à travers des engagements affichés ou des statistiques RH. Elle se construit dans les comportements du quotidien, dans ce que l’on accepte, dans ce que l’on refuse et surtout, dans la place que l’on fait réellement aux autres.

Pour suivre Anaïs sur les réseaux : https://www.linkedin.com/in/anais-huet-coach-agile/
Lien vers les slides - à venir
Lien vers la vidéo - à venir

“TechLeads : arrêtez de répondre. Commencez à questionner !” par Fanny KLAUK, votre dévouée serviteuse

A mon tour de monter sur scène, dans le grand amphithéâtre de BDX I/O !

Cette fois, j’ai choisi de m’attaquer à un paradoxe que l’on retrouve dans beaucoup d’équipes techniques : plus un TechLead est compétent, plus il devient indispensable… et plus il risque de s’épuiser.
Parce qu’on attend du TechLead qu’il sache !

Une question sur une architecture ? On va voir le TechLead.
Une code review un peu complexe ? Le TechLead.
Un arbitrage produit ? Encore lui.
Un bug incompréhensible, une décision technique délicate, une tension dans l’équipe ? Devinez qui on appelle ? Bingo : toujours le TechLead !

Et finalement, à force de devenir la personne qui sait, qui tranche, qui rassure et qui débloque toutes les situations, le TechLead finit parfois par devenir lui-même… le principal goulot d’étranglement de son équipe. Un paradoxe assez cruel : sa valeur crée sa surcharge.
C’est là que je propose de déplacer un peu le regard. Parce qu’au fond, est-ce que le rôle d’un TechLead est vraiment d’avoir toutes les réponses ? Ou est-ce qu’il ne serait pas plutôt de permettre à son équipe de trouver les siennes ?

Et pour cela, je suis allée chercher du côté d’une pratique que je connais bien dans l’accompagnement des équipes : le questionnement puissant. Une compétence centrale dans le coaching, mais encore trop peu présente dans nos réflexes techniques.
Car face à une difficulté, notre premier réflexe est souvent de proposer une solution : c’est rapide, c’est rassurant. Et quand on a de l’expérience, c’est même assez naturel. Mais à force de répondre systématiquement, que transmet-on réellement ? Une solution… ou une dépendance ?

Prenons un exemple : un développeur vient demander : « Tu ferais comment pour résoudre ce problème ? » Le réflexe classique serait de lui expliquer immédiatement l’approche à adopter.
Mais pourquoi ne pas commencer par lui demander : « Qu’est-ce que tu as déjà essayé ? » « Quelles options as-tu envisagées ? » « Qu’est-ce qui te fait hésiter entre ces solutions ? » « De quoi aurais-tu besoin pour prendre cette décision ? »
Le problème technique n’a pas changé, mais la posture, elle, est complètement différente : on ne cherche plus uniquement à résoudre une difficulté ponctuelle. On cherche aussi à développer la capacité de la personne à raisonner, décider et agir par elle-même.
Et c’est là que le questionnement devient particulièrement intéressant.

Parce qu’en posant les bonnes questions, le TechLead peut progressivement :
• Réduire sa propre charge cognitive en évitant de porter toutes les décisions.
• Faire émerger des solutions parfois plus pertinentes que celles qu’il aurait proposées spontanément.
• Responsabiliser les membres de son équipe sans leur imposer systématiquement une direction.
• Limiter les dépendances invisibles qui se créent lorsqu’une seule personne devient le passage obligé de toutes les décisions.

Attention, l’idée n’est évidemment pas de transformer chaque échange technique en séance de coaching !
Il y a des moments où il faut décider, expliquer, transmettre son expertise ou intervenir rapidement (coucou les incidents de production !).

Mais il y a aussi beaucoup de situations où prendre quelques instants pour questionner plutôt que répondre peut changer durablement la dynamique d’une équipe. Et c’est précisément ce changement de posture que j’avais envie de partager. Ce sujet fait particulièrement écho à mes convictions autour de l’accompagnement, de l’autonomie et de l’amélioration continue : parce qu’on associe encore trop souvent la valeur d’un expert à sa capacité à résoudre les problèmes des autres, alors qu’on pourrait aussi la mesurer à sa capacité à rendre les autres progressivement moins dépendants de lui. Et quelque part, c’est peut-être ça, le véritable changement de perspective : un TechLead qui ne répond pas immédiatement n’est pas nécessairement un TechLead qui ne sait pas. C’est parfois un TechLead qui choisit délibérément de laisser la place à la réflexion, à l’expérimentation et à l’apprentissage.

Être un bon TechLead, ce n’est pas forcément être celui qui a les meilleures réponses. C’est aussi être celui qui sait poser les meilleures questions. Et si cette posture permettait à la fois de construire des équipes plus autonomes, de faire émerger de meilleures décisions et de préserver l’énergie de celles et ceux qui les accompagnent ?

Alors peut-être qu’il est temps de reconsidérer ce que signifie réellement « être le référent technique ». Finalement, mon message tient en une idée : faire grandir son impact ne devrait pas signifier faire grandir sa charge de travail.

Et si, pour devenir un TechLead encore plus efficace, il fallait parfois apprendre… à moins répondre ?

Pour me suivre sur les réseaux : fanny-klauk
Lien vers les slides - https://noti.st/klaukf/mkkKnm Lien vers la vidéo - à venir

“Ce que la BD m’a appris sur l’UX 🗯️” par Seb CARNELOS

Sébastien Carnelos, ancien designer et développeur, aujourd’hui Scrum Master chez Aubay, nous propose de regarder les interfaces numériques à travers les mécanismes de compréhension propres à la bande dessinée. Et très vite, on réalise que les deux univers ont beaucoup plus en commun qu’on pourrait le penser.

Pour commencer, encore faut-il définir ce qu’est une bande dessinée. BD, manga, comics, roman graphique… autant de formats qui partagent une logique de narration par séquences d’images.
Une seule vignette ne suffit généralement pas à créer cette succession narrative. À l’inverse, un storyboard ou une bobine de film ne produisent pas nécessairement la même expérience de lecture. Et le webtoon ? Il vient justement bousculer certaines frontières, notamment par son format de lecture vertical.

Mais au-delà des supports, ce qui nous intéresse ici, c’est la manière dont notre cerveau construit du sens à partir d’informations partielles.

1. L’ellipse : notre cerveau complète les trous

Entre deux cases d’une bande dessinée, il manque souvent beaucoup de choses. Un personnage lève le bras dans une case. Dans la suivante, un objet est au sol. Et pourtant, nous comprenons immédiatement ce qui s’est passé. Notre cerveau reconstitue naturellement les événements manquants. C’est le principe de l’ellipse.

En UX, on retrouve exactement ce mécanisme : un rectangle avec du texte n’est, techniquement, qu’une forme graphique. Mais grâce à nos habitudes et aux conventions que nous avons apprises, nous savons reconnaître un bouton. Nous comprenons qu’il est probablement cliquable. Nous n’avons pas besoin de réapprendre le fonctionnement d’une interface à chaque visite. Et heureusement !

2. Le contenu : less is more

Autre évolution intéressante : au fil du temps, la quantité de texte présente dans certaines bandes dessinées a diminué. Les images racontent davantage par elles-mêmes. Il n’est plus toujours nécessaire de décrire ce que le lecteur peut déjà comprendre visuellement.

Et côté UX ? Même combat. Une interface efficace n’est pas celle qui explique absolument tout. C’est celle qui fournit suffisamment d’informations pour permettre à l’utilisateur de comprendre et d’agir.
Attention toutefois : simplifier ne signifie pas supprimer aveuglément du contenu. Il s’agit surtout de retirer ce qui n’apporte pas de valeur à la compréhension.

3. La contextualisation : ne perdons pas notre lecteur

Dans une bande dessinée, si deux cases sont trop éloignées narrativement, le lecteur peut avoir du mal à comprendre ce qui s’est passé entre les deux. Le contexte ne suffit plus à reconstruire l’histoire.

Dans une interface, c’est exactement la même chose : si un bouton change de place à chaque page, si les informations importantes ne suivent aucune logique ou si les conventions visuelles varient constamment, l’utilisateur doit fournir un effort supplémentaire.

On touche ici à une notion fondamentale du design : la cohérence. Conserver des repères, maintenir une hiérarchie visuelle, utiliser des comportements prévisibles et parfois, au contraire, jouer volontairement sur une rupture de style pour signaler un changement de contexte.
Par exemple, passer de la galerie d’un artiste à sa boutique de merchandising peut justifier une ambiance visuelle différente. À condition que cette rupture soit compréhensible et intentionnelle.

4. Le sens de lecture : guider sans contraindre

Une BD et un manga ne se lisent pas nécessairement dans le même sens. Et parfois, la composition même des images peut entrer en contradiction avec le sens de lecture attendu. Résultat : le lecteur hésite, revient en arrière, cherche le bon chemin.

En UX, on essaie précisément d’éviter cela. La disposition des éléments, les contrastes, les alignements et la hiérarchie visuelle doivent guider naturellement le regard. L’objectif n’est pas de forcer un parcours, mais de rendre le chemin évident.

5. L’environnement de lecture : accepter de ne pas tout contrôler

Dernier parallèle, et pas des moindres : un auteur de bande dessinée ne contrôle pas les conditions dans lesquelles son œuvre sera lue. Dans un canapé, dans un train, sur un téléphone, en pleine lumière ou dans un environnement bruyant… Chaque lecteur vit une expérience différente !

Et c’est encore plus vrai pour nos produits numériques ! Nous ne maîtrisons ni le contexte d’utilisation, ni l’attention disponible, ni les contraintes matérielles, ni les capacités de chaque utilisateur. Concevoir une bonne expérience, c’est aussi accepter cette diversité.

La conclusion de Sébastien résume parfaitement l’ensemble : se faire comprendre est plus important que faire beau. Et j’ajouterais volontiers : une belle interface qui ne permet pas de comprendre ce que l’on doit faire reste une mauvaise expérience.
Une conférence originale qui rappelle que l’UX ne se nourrit pas uniquement de design systems, de personas ou de tests utilisateurs. Elle se nourrit aussi de narration, de psychologie, de culture… et de notre manière très humaine de donner du sens à ce que nous voyons.

Pour suivre Seb sur les réseaux : sebcarnelos
Lien vers les slides - à venir Lien vers la vidéo - à venir

“Comment s’échapper de Spotify 🎵” par Nicolas FOCQUEU

Dix-sept ans d’abonnement à Spotify. C’est par ce constat que Nicolas Focqueu nous embarque dans une réflexion sur notre rapport à la musique, aux abonnements et à la propriété numérique.
Parce qu’un abonnement, c’est pratique ! On paie quelques euros chaque mois, on accède à une bibliothèque gigantesque, on retrouve ses playlists partout…

Mais à la fin, qu’est-ce qu’on possède réellement ? Pas grand-chose.

Nicolas revient sur l’évolution du coût de son abonnement, passé d’une dizaine d’euros mensuels à une formule familiale autour de 21 euros. Et lorsqu’on additionne les sommes dépensées au fil des années, la facture devient nettement moins anecdotique. Dans son exemple, on arrive à plus de 2 000 euros investis sans avoir constitué de bibliothèque musicale personnelle.
De quoi se poser quelques questions… D’autant que les motivations pour quitter Spotify ne sont pas uniquement économiques. Nicolas évoque plusieurs sujets qui l’interrogent : la rémunération des artistes, la place des contenus générés par IA, les choix d’investissement de l’entreprise, l’évolution de la page d’accueil et les recommandations pilotées par les algorithmes.

Une question revient finalement : est-ce encore moi qui choisis ce que j’écoute ? Ou est-ce que je me contente de consommer ce qu’une plateforme décide de me proposer ? Et si on reprenait possession de notre musique ?
Première piste : acheter directement ses albums et ses titres. Nicolas évoque notamment Qobuz, qui permet l’achat de musique numérique et propose une autre approche de la rémunération des artistes.

Mais acheter sa musique ne suffit pas : encore faut-il pouvoir la retrouver, l’organiser et l’écouter facilement sur ses différents appareils… Et c’est là que la conférence devient particulièrement intéressante techniquement.
La solution présentée repose sur une infrastructure relativement simple : un mini-PC ou un serveur VPS, des outils de conteneurisation comme Docker ou Podman, et un serveur musical compatible avec le protocole OpenSubsonic. Parmi les solutions possibles, Nicolas présente Navidrome, une application open source développée en Go. D’autres alternatives existent, comme Jellyfin, Gonic ou Plex.

L’idée est de retrouver une expérience proche d’une plateforme de streaming… mais avec sa propre bibliothèque musicale. Et quoi de mieux qu’une démo pour rendre tout cela concret ? Nicolas nous montre l’achat d’un album d’Orelsan sur Qobuz, pour environ 18 euros. Puis les fichiers téléchargés sont ajoutés à la bibliothèque musicale. Sans avoir besoin de passer des heures à organiser manuellement chaque dossier, l’interface permet de retrouver les titres, les pochettes et même les paroles, le tout accessible à distance, depuis un serveur personnel. Avec, en prime, la possibilité de gérer plusieurs utilisateurs.

Finalement, on retrouve une bonne partie du confort de Spotify… sans dépendre entièrement de son catalogue ou de ses recommandations. Évidemment, l’autohébergement implique aussi de nouvelles responsabilités : maintenance, sauvegardes, disponibilité du serveur, sécurité… Mais c’est justement tout l’intérêt de la démarche.
On échange une partie de la simplicité d’un service centralisé contre davantage de contrôle. Et ce sujet dépasse largement la musique. Il pose une question que l’on retrouve de plus en plus dans nos usages numériques : préférons-nous la commodité immédiate ou la maîtrise à long terme ?

Un choix qui n’a pas de réponse unique, mais qui mérite au moins d’être conscient.

Pour suivre Nicolas sur les réseaux : ikki_nico
Lien vers les slides - à venir Lien vers la vidéo - à venir

“MLOps - Comprendre et répondre à la dégradation des modèles de machine learning en production” par Simon POULET

Simon Poulet, d’AWS, nous emmène dans les coulisses du machine learning en production. Et avec une question qui peut sembler surprenante lorsqu’on découvre le sujet : pourquoi un modèle qui fonctionne très bien aujourd’hui pourrait-il devenir moins performant demain ?

Pour comprendre, Simon commence par rappeler les fondamentaux. Le machine learning est un domaine de l’intelligence artificielle qui s’appuie notamment sur des méthodes statistiques et mathématiques pour construire des modèles capables de produire des prédictions. On entraîne un modèle à partir de données, on ajuste ses paramètres, puis on l’utilise pour réaliser des inférences sur de nouvelles entrées. Cela peut aller d’une simple régression linéaire à des modèles beaucoup plus complexes, comme les LLM.

Mais construire un modèle ne représente qu’une partie du travail : encore faut-il le faire vivre. Si vous connaissez le DevOps, le parallèle est assez naturel : le MLOps regroupe un ensemble de pratiques destinées à industrialiser le cycle de vie des modèles de machine learning.

On retrouve plusieurs étapes :

1. Collecter les données.
2. Valider leur qualité.
3. Préparer et construire les caractéristiques pertinentes (feature engineering).
4. Entraîner le modèle.
5. Évaluer ses performances.
6. Le déployer.
7. Continuer à le surveiller et à l’évaluer.

Et c’est justement cette dernière étape qui constitue le cœur de la conférence. Car un modèle est entraîné à partir de données représentatives d’un contexte donné, à un instant donné.

Or le monde, lui, continue d’évoluer : les comportements changent, les usages évoluent, les populations se transforment… et un modèle qui ne tient pas compte de ces évolutions risque progressivement de perdre en pertinence.

Simon nous présente alors deux grandes familles de dérives : le data drift et le concept drift.
Le data drift est un changement dans la distribution des données que reçoit le modèle par rapport à celles utilisées lors de son entraînement. Imaginons un service de recommandation de contenus : si les habitudes des utilisateurs changent fortement, les données reçues aujourd’hui peuvent ne plus ressembler à celles sur lesquelles le modèle a appris.
Le concept drift c’est la relation entre ces entrées et le résultat attendu. Autrement dit, ce qui permettait de faire une bonne prédiction hier ne fonctionne plus nécessairement aujourd’hui.

À travers des cas d’usage autour de Streamflix, Simon nous montre comment ces dérives peuvent apparaître et pourquoi il est essentiel de les détecter. Et monitorer un modèle, ça ne s’improvise pas. Heureusement, il existe des outils pour surveiller tout cela.
On peut notamment utiliser des tests statistiques, comme celui de Kolmogorov-Smirnov, pour comparer certaines distributions de données. L’objectif est de repérer les écarts significatifs et d’identifier les situations qui nécessitent une investigation.
Mais la surveillance ne doit pas se limiter aux données d’entrée : il faut également mesurer les performances réelles du modèle, notamment lorsque des retours utilisateurs ou des résultats observés permettent d’évaluer la qualité des prédictions.

Simon évoque également Evidently, un outil open source permettant de suivre la qualité des données et des modèles, et de détecter certaines dérives. Et lorsqu’une anomalie est identifiée ? On commence par comprendre sa cause. Puis, si nécessaire, on réentraîne le modèle avec des données plus récentes ou plus représentatives. Enfin, on redéploie progressivement, avec des stratégies comme le shadow testing ou l’A/B testing pour limiter les risques.
Ce que je retiens de cette session, c’est surtout un principe qui dépasse largement le machine learning : Un système qui fonctionne aujourd’hui n’est pas un système qui fonctionnera nécessairement demain. Et cela me rappelle beaucoup de problématiques que l’on rencontre dans les produits numériques : on lance une fonctionnalité, on valide une hypothèse, on mesure des résultats.
Mais si l’on ne revient jamais questionner les usages, les besoins ou les comportements, on risque de continuer à optimiser une solution qui ne répond plus au problème initial.

Finalement, le monitoring n’est pas seulement une préoccupation technique. C’est aussi une démarche d’amélioration continue. Et ça, forcément, ça me parle !

Pour suivre Simon sur les réseaux : simonpoulet2
Lien vers les slides - à venir
Lien vers la vidéo - à venir

“Adieu le “Ça marche pas sur ma machine”, welcome EasyLab !” par Matthieu VINCENT

Ah, les workshops techniques en conférence… Ces moments uniques où l’on a prévu un atelier passionnant, une démonstration bien huilée, des exercices progressifs… Et où l’on passe finalement les vingt premières minutes à résoudre des problèmes d’installation, grrrr… Le JDK qui n’est pas à la bonne version, Node qui refuse de coopérer, une image Docker impossible à télécharger sur le réseau de la conférence, et bien sûr, ce participant qui préfère ne pas installer quinze dépendances supplémentaires sur son ordinateur professionnel (franchement, on peut le comprendre).

C’est précisément à ce problème que Matthieu Vincent, de Sopra, s’attaque avec EasyLab.
L’objectif est simple : permettre aux organisateurs et animateurs de workshops de proposer des environnements techniques prêts à l’emploi, sans imposer à chaque participant une longue phase de configuration.

EasyLab repose sur un ensemble de technologies open source, avec une place importante donnée à Go. La solution peut s’appuyer sur différents environnements d’hébergement, notamment OVHcloud, Azure ou plus généralement une infrastructure Kubernetes accessible via une kubeconfig. Elle peut aussi être utilisée dans différents contextes : localement, sur une plateforme mutualisée ou dans un environnement dédié.

Matthieu nous présente d’abord l’interface d’administration. Et premier détail amusant : une partie de la configuration peut même être préparée depuis son téléphone ! L’administrateur peut définir les paramètres communs à l’ensemble des participants, tout en conservant la possibilité de personnaliser certains environnements. On peut également configurer les accès DNS, préparer les ressources nécessaires et définir une date de fin pour éviter que des environnements inutilisés ne continuent de consommer des ressources.

Parce que découvrir un mois après un workshop qu’on a oublié de supprimer ses clusters… ce n’est pas forcément le meilleur souvenir à ramener d’une conférence.

Et côté participants ? L’expérience devient beaucoup plus simple : on accède à son environnement de travail, qu’il s’agisse d’un workspace ou d’un conteneur, sans avoir à reconstruire toute la configuration sur son poste. La solution permet également de partager les accès, de transmettre des notifications dans l’environnement de développement et de consulter les logs. Autre point appréciable : fermer accidentellement son navigateur ne signifie pas nécessairement perdre son travail.

Et pour les personnes qui animent des ateliers, c’est un vrai gain de sérénité : moins de temps passé à dépanner les environnements, plus de temps consacré au contenu, à la pratique et aux échanges.

Finalement, cette session m’a immédiatement rappelé une question que je pose régulièrement dans mes missions : Pourquoi demandons-nous aux utilisateurs de s’adapter à nos contraintes techniques, plutôt que de concevoir des outils qui facilitent réellement leur travail ?

EasyLab illustre assez bien ce que peut apporter une approche centrée sur l’expérience des développeurs et des participants. On réduit les irritants, on anticipe les difficultés, on simplifie l’accès à la valeur et tout le monde peut se concentrer sur ce pour quoi il est venu.
Un bel exemple de Developer Experience appliquée à l’univers des conférences et de la formation.

Pour suivre Matthieu sur les réseaux : yodamad03
Lien vers les slides - à venir
Lien vers la vidéo - à venir

“Souveraineté numérique, quelles solutions pour quels enjeux ?” par Ambre PERSON

Souveraineté numérique : on en parle de plus en plus sans forcément maîtriser ce qu’il y a derrière. C’est la question qu’Ambre Person nous propose d’explorer. Et très rapidement, on comprend que le sujet est beaucoup plus complexe qu’un simple choix d’hébergeur : être souverain, ça veut dire quoi ?

Ambre commence par revenir à la notion même de souveraineté. L’idée centrale est de conserver la maîtrise de ses décisions, de préserver son autonomie et de pouvoir exercer sa liberté de choix sans subir de contraintes imposées par des tiers. Appliquée au numérique, cette définition ouvre immédiatement de nombreuses questions : qui détient nos données ? Qui peut y accéder ? Qui exploite les infrastructures ? De quelles technologies dépendons-nous ? Et surtout, quelles lois s’appliquent réellement aux différents acteurs impliqués ?

Parce que choisir un datacenter situé en France ne suffit pas nécessairement à garantir une indépendance complète.
Évidemment, la question des données occupe une place centrale mais n’est qu’une partie du problème. Ambre évoque plusieurs cadres réglementaires qui influencent leur traitement et leur accès : le RGPD en Europe, le CLOUD Act et la section 702 du FISA aux États-Unis, ou encore la National Intelligence Law en Chine. Des textes aux objectifs et aux mécanismes différents, mais qui rappellent que les enjeux juridiques dépassent les frontières physiques des infrastructures.

Et puis il y a la dimension opérationnelle : qui administre les systèmes ? Qui peut interrompre le service ? De qui dépend la maintenance ? Quelles seraient les conséquences si un fournisseur décidait de modifier ses conditions d’accès ?
La souveraineté concerne donc autant la détention des données que leur exploitation, les opérations et les règles juridiques applicables.

Le sujet ne s’arrête pas au logiciel. Il concerne également le matériel, les chaînes d’approvisionnement, les éditeurs et les droits d’usage : qui fabrique les composants ? Qui maintient les solutions ? Qui contrôle les licences ? Peut-on changer de fournisseur sans devoir reconstruire entièrement son système ?
Autant de questions qui nous ramènent à une problématique très concrète : la dépendance technologique.

Ambre aborde également SecNumCloud, le référentiel de qualification de l’ANSSI qui couvre notamment des exigences techniques, organisationnelles et juridiques pour certains services cloud. Un dispositif important, mais qui ne signifie pas pour autant l’absence totale de dépendance. Et c’est probablement l’un des messages essentiels de cette session.

Attention au sovereign washing ! Comme pour le greenwashing, il est tentant de transformer une démarche complexe en argument marketing.
Une étiquette « souverain » ne suffit pas à démontrer qu’une solution répond réellement à tous les enjeux d’autonomie, de maîtrise ou de résilience. Ambre nous invite donc à identifier plusieurs catégories de risques :
• Les lois extraterritoriales.
• Les interruptions ou coupures opérationnelles.
• Les dépendances technologiques.
Et surtout, à intégrer ces questions dès le début des projets ! Parce qu’une fois qu’une architecture est construite autour d’un fournisseur, que les données sont installées et que les équipes ont développé leurs pratiques, changer de trajectoire peut devenir extrêmement coûteux.

La conclusion est particulièrement intéressante : Il n’existe pas de souveraineté absolue. La souveraineté est une démarche. Une démarche qui consiste à comprendre ses dépendances, à évaluer ses risques et à faire des choix éclairés.
Et finalement, cela rejoint une conviction que l’on retrouve dans beaucoup de pratiques produit et d’architecture : on ne peut pas supprimer toutes les contraintes, mais on peut choisir consciemment celles que l’on accepte.

Pour suivre Ambre sur les réseaux : ambre-person
Lien vers les slides - à venir
Lien vers la vidéo - à venir

« Merci pour ton aide ! » - « Oh, de rien, je fais juste mon travail. » par Anaïs MOULIN

Une dernière Keynote pour clore la journée. Anaïs Moulin se lance dans un exercice que je trouve particulièrement courageux : une conférence sans slides. Pas de support visuel pour guider le discours. Pas de schéma pour illustrer les concepts. Juste une personne, une salle et une réflexion qui nous concerne probablement toutes et tous.
Car Anaïs nous parle d’un geste en apparence très simple : recevoir un compliment. Et finalement, ce n’est pas si évident.

Pourquoi est-ce si difficile de recevoir un compliment ? Dans nos métiers, nous passons beaucoup de temps à donner du feedback. En code review, en rétrospective, en entretien, dans les échanges du quotidien…. Nous savons commenter, proposer des améliorations, identifier des axes de progression. Mais lorsqu’une personne nous dit simplement « bravo » ou « merci », notre réaction est parfois étonnante : « Oh, ce n’était rien. » « J’ai juste fait mon travail. » « Tu exagères ! » « Oui, enfin, j’aurais pu faire mieux. »
Pourquoi avons-nous autant de mal à accepter quelque chose de positif ? Anaïs nous propose de regarder du côté de l’image que nous avons de nous-mêmes. Lorsque le compliment reçu est cohérent avec cette image, nous pouvons généralement l’accueillir assez facilement.

Mais lorsqu’il s’en éloigne trop, il peut provoquer une forme d’inconfort. Accepter le compliment reviendrait alors à remettre en question la perception que nous avons construite de nous-mêmes. Et parfois, il est plus facile de rejeter quelques mots positifs que de réexaminer une croyance installée depuis des années.

Anaïs aborde également le syndrome de l’imposteur, les différences de socialisation entre les genres et les nombreux facteurs qui influencent notre manière de recevoir un compliment : qui nous le fait ? Dans quel contexte ? Est-ce une habitude ? Est-ce perçu comme sincère ? Est-ce un véritable cadeau ou une formule automatique ? Autant d’éléments qui peuvent modifier notre réaction.
Et pourtant, recevoir un compliment devrait, en théorie, être agréable. Anaïs évoque notamment les mécanismes cérébraux liés à la récompense et à la reconnaissance. Mais si les paroles reçues entrent trop fortement en contradiction avec notre représentation de nous-mêmes, nous pouvons préférer les réfuter.

Alors comment sortir de ce mécanisme ? Anaïs nous propose trois pistes concrètes :

1. Dire simplement merci. Sans justification. Sans minimisation. Sans chercher immédiatement à renvoyer le compliment. Juste : merci. Et finalement, c’est peut-être l’exercice le plus difficile !
2. Rendre le compliment plus concret. Si quelqu’un nous dit « tu es vraiment douée », on peut demander : « Merci ! Qu’est-ce que j’ai fait précisément qui te fait dire ça ? » L’objectif n’est pas de mettre la personne en difficulté, mais de comprendre ce qu’elle a observé. Un compliment précis devient plus facile à intégrer, parce qu’il repose sur des faits concrets plutôt que sur une appréciation générale.
3. Garder une trace des retours positifs. Noter les compliments reçus, avec leur contexte et les détails qui les accompagnent, pour pouvoir y revenir plus tard et pour soi, mais aussi pour mieux comprendre ce que les autres reconnaissent dans notre travail. Une sorte de carnet de reconnaissance, finalement.

Et dans nos équipes ? C’est évidemment là que la conférence a particulièrement résonné pour moi. Parce qu’on touche directement à deux sujets qui m’intéressent énormément en ce moment : le feedback constructif et la sécurité psychologique (chouette, mes dadas du moment !). On parle beaucoup de la nécessité de donner du feedback pour progresser. Mais on oublie parfois que le feedback ne doit pas être uniquement correctif.

Reconnaître ce qui fonctionne, valoriser une contribution, remercier sincèrement une personne pour son aide… ce sont aussi des leviers essentiels de collaboration. La reconnaissance peut contribuer à créer un environnement dans lequel les personnes se sentent considérées, encouragées et davantage en confiance. Et cela participe à la qualité des relations au sein d’une équipe.
Encore faut-il savoir donner ces retours et aussi apprendre à les recevoir.

Ce que j’ai particulièrement aimé dans la proposition d’Anaïs, c’est cette distinction : accepter un compliment ne signifie pas être obligé d’y croire immédiatement. On peut simplement le recevoir, dire merci, le laisser exister et décider plus tard de la place qu’on souhaite lui donner.
Une conclusion toute en simplicité, mais qui résonne particulièrement après une journée de conférences, de partages et de rencontres.

Alors la prochaine fois que quelqu’un vous fait un compliment… Essayez : dites juste merci ^^

Pour suivre Anaïs sur les réseaux : anaismoulin
Lien vers les slides - à venir
Lien vers la vidéo - à venir

Bilan de cette édition Bdx I/O 2026

Et voilà, une nouvelle édition de BDX I/O qui s’achève. Une journée dense, variée, parfois technique, parfois émouvante, souvent stimulante. Et surtout, une journée qui rappelle pourquoi j’aime autant ces rendez-vous.
Parce qu’en quelques heures, on peut passer du traitement du signal à la souveraineté numérique, du machine learning à la bande dessinée, de l’expérience développeur à l’éducation des enfants, du sexisme ordinaire à la reconnaissance au travail. Des sujets qui semblent parfois n’avoir aucun rapport.
Et pourtant, en prenant un peu de recul, je retrouve un fil conducteur dans presque toutes les conférences auxquelles j’ai assisté : la place de l’humain dans nos choix technologiques.

Que l’on parle de produit, de développement, d’infrastructure ou de collaboration, une même question revient : est-ce que ce que nous construisons rend réellement la vie des personnes concernées meilleure ? Et je crois que c’est précisément ce qui me plaît dans ces conférences : elles nous obligent à sortir de nos habitudes, à confronter nos convictions et à regarder nos métiers sous d’autres angles.

Un immense merci à l’équipe d’organisation de BDX I/O pour cette journée et pour tout le travail nécessaire à la rendre possible.

Merci également aux speakers pour leurs partages, leurs démonstrations, leurs témoignages et parfois leur vulnérabilité. Merci à CGI de m’avoir permis de participer à cette édition 2026.

Et bien sûr, merci à toutes celles et ceux avec qui j’ai pu échanger au détour d’un couloir, d’une chicorée, d’une pause ou d’une session : revoir des visages chaleureux m’a particulièrement touchée. Ces discussions improvisées sont souvent aussi précieuses que les conférences elles-mêmes. Petit coucou particulier à Anaïs, Frédéric, Stéphane, Khadija, Horacio, Jérôme, Nicolas, Annabelle, Louis, Stanley, Mathieu, Mickaël, Esteban, Seb, Noémie, Olivier, Julien, Yann, Charline, Mehdi, Johanna, Nicolas, Sébastien, Guillaume, Ambre, Chloé, Matthieu et mon ourson.

Un merci particulier également aux personnes venues assister à mon talk dans le grand amphithéâtre. Partager une expérience sur scène reste toujours un moment singulier, et votre présence contribue énormément à lui donner du sens. Je repars avec des idées plein la tête, quelques outils supplémentaires à explorer, des réflexions à approfondir… et probablement plusieurs onglets de navigateur à ouvrir dans les prochains jours ^^

Merci, merci, merci ! 🙏.

PS : Comme toujours, j’ai peut-être fait des fautes, mal compris certaines explications ou retranscrit quelques bêtises, notamment sur les sujets les plus techniques. Mes notes ayant été prises sur le vif, je vous invite à me faire part de vos corrections ou compléments, par PR ou par mail. C’est aussi comme ça qu’on apprend et qu’on améliore le partage de connaissances !