Il y a des événements qui rassemblent vraiment la communauté tech
bordelaise, et BDX I/O en fait partie. Pour cette 10ᵉ édition, nous
étions particulièrement heureux d'être présents pour célébrer dix ans
d'innovation, de talks passionnants et de rencontres inspirantes.
Initié en 2014 par l'association Bordeaux Developer Experience,
l'événement valorise autant ses sponsors que les acteurs locaux,
notamment la grappe numérique qui regroupe aujourd'hui 35 communautés
bordelaises.

Thème de l'édition 2025 : IA - entre progrès et préoccupations

Cette année, le thème central de l'édition 2025 est formulé autour de l'IA, abordée entre
progrès et préoccupations. Déjà omniprésente en 2024, la thématique
gagne en maturité : les discussions s'orientent désormais vers les
tendances de fond, les impacts à long terme et les transformations
possibles pour les développeurs, les organisations et l'arrivée des
juniors dans le métier.

Présente dès la keynote d'ouverture, l'IA sert de fil conducteur pour
prendre du recul et interroger ce que pourrait devenir notre pratique
demain. Mais l’IA n’est pas le sujet de toutes les conférences ! Les pratiques, les retours d’expérience et la technique au sens large restent pleinement représentés. Pour celles et ceux saturés d’IA, pas de panique !

Keynote d'ouverture : prédire l'imprévisible : comment penser le futur à l'ère de l'IA

Conférencier : Ludovic Cinquin, WhereWeGo
Rédacteur : Pierre Leroy

L'IA au centre, mais un futur imprévisible

La keynote ouvre sur un constat : l’IA occupe presque tout l’espace médiatique et technologique, mais son avenir reste extrêmement difficile à anticiper. Les promesses de ruptures majeures : batteries, nouveaux matériaux, innovations énergétiques s’opposent à des prédictions souvent contradictoires. Malgré cette incertitude, une idée domine : si ces avancées se concrétisent simultanément, l’impact économique et sociétal serait massif, voire déjà perceptible.

Le mur physique : énergie et métaux

La présentation rappelle que l’essor de l’IA n’est pas immatériel. Il repose sur des infrastructures énergétiques et matérielles très concrètes. La consommation des datacenters pourrait doubler d’ici 2030, tandis que la dépendance au cuivre et aux métaux critiques s’intensifie dans un contexte d’approvisionnement tendu.
Derrière ces chiffres, une question devient inévitable : où décide-t-on d’allouer notre électricité et nos ressources ? À la mobilité électrique, à l’industrie, ou au développement toujours plus massif de l’IA ? Continuer à étendre les capacités sans se poser ces questions exposerait rapidement à un blocage physique.

Penser en scénarios extrêmes

Pour appréhender cette incertitude, le conférencier propose d’abandonner l’idée d’un futur unique et linéaire. Il suggère de raisonner à partir de scénarios extrêmes : une IA omniprésente et très énergivore, une IA fortement limitée par des contraintes environnementales, une rupture technologique bouleversant le rapport puissance/consommation, ou encore des tensions géopolitiques affectant l’accès aux métaux stratégiques.
Même improbables, ces représentations permettent d’identifier les points de rupture possibles, de préparer plusieurs trajectoires d’action et de renforcer la capacité d’adaptation des organisations.

Conclusion

La conclusion est claire : il est impossible de réfléchir sérieusement à l’avenir de l’IA sans intégrer la question de l’énergie et des matières premières. L’IA “takes all” uniquement si la société accepte de lui consacrer une part significative de ressources limitées.

Réécrire le rôle du développeur à l'âge des LLMs

Conférencier : Horacio Gonzalez, Clever Cloud
Rédacteur : Pierre Leroy

Un vieux refrain : "le développement va disparaître"

La conférence rappelle que l’annonce de la fin du métier revient à chaque rupture technologique : Fortran, UML, Java, low-code sans jamais se réaliser. À chaque fois, le métier évolue. Les LLMs suivent très probablement le même schéma : transformation, pas disparition.

LA vraie évolution : moins de syntaxe, plus de jugement

Les LLMs déplacent la valeur du code brut vers l’architecture logicielle, la formulation précise, la lecture critique, la vérification et la gestion des erreurs. L’analyse, l’éthique et le discernement deviennent centraux. Les compétences les plus utiles sont donc modifiées

Le développeur-orchestrateur

Le rôle glisse vers davantage de structure, de cohérence et de vision d’ensemble, plus proche de l’architecture que de la simple écriture de code (demain tous architectes ?). Le développeur coordonne désormais humains, outils et IA.

Défi : former les juniors

Les tâches simples disparaissent, privant les débutants d’un terrain d’apprentissage naturel. Il faut réinventer complètement la formation :

• mob programming avec seniors et LLM,
• focus sur craft, revue de code et prompts,
• senior en rôle de mentor,
• évaluation centrée sur le raisonnement, plus sur la syntaxe.

Nous ne pouvons pas être plus d’accord avec ce constat ! Nous allons publier très prochainement un article spécifiquement à ce sujet … restez connectés !

Les coulisses de JavaScript : ce qu'on utilise sans comprendre

Conférenciers : Etienne Idoux, Mickael Alves (Zenika)
Rédacteur : Sébastien Oddo

J'ai assisté à une conférence sur le moteur JavaScript, qui tourne dans Node et les navigateurs Web. Le langage JavaScript a été créé en 1995 et révolutionné en 2015 par ES6.
La conférence met en lumière le fonctionnement interne du runtime, centré autour de deux structures principales : le heap, qui gère la mémoire des objets, et la call stack, qui organise l'exécution des instructions de façon monothread. Le moteur compile le code JavaScript en langage machine et exécute les fonctions une à une sur la call stack.
Le modèle d'exécution repose sur l’event loop, qui coordonne la gestion des tâches asynchrones via des files d'attente : la task queue pour les callbacks classiques d'un setTimetout et la microtask queue, prioritaire, notamment utilisée pour les Promises ou fetch. La conférence était très bien illustrée par des schémas expliquant l'enchaînement des opérations par le moteur.

Mais qu'est-ce qu'il se passe réellement dans la call stack ? Il y a un contexte d'exécution ! Il contient un realm (l’environnement global JS et les Web APIs), des variables d’environnement (pour les fonctions) et un environnement lexical (pour les variables), avec une gestion fine de leur portée et de leur initialisation en mémoire. Car en réalité, JS passe 2 fois sur notre code : une 1ère fois (allocation mémoire) pour déclarer les variables sans les initialiser et les fonctions pour les initialiser, une 2e fois pour exécuter le code.
Cette architecture explique la puissance et la souplesse de JavaScript malgré son exécution single-threaded. Cette conférence éclaire ainsi les mécanismes qui rendent possible l’asynchronisme efficace et la réactivité des applications web modernes.

Onboarding 2.0 : Réinventer l'intégration des devs

Conférencière : Hafsa Elmaizi
Rédactrice : Pauline Poivey

L’onboarding d’un développeur ne doit jamais être traité comme une formalité : c’est ce qui conditionne son intégration, sa montée en compétences et sa fidélisation. Quand il est bien préparé, la personne trouve rapidement sa place. Quand il est négligé, le risque de départ augmente fortement.
Un bon onboarding commence avant l’arrivée, avec le matériel prêt, les accès configurés et une documentation claire (installation du poste, architecture, trombinoscope, guides, glossaire). Il faut aussi mettre à jour la matrice de compétences pour anticiper la montée en compétences.
Le premier jour, l’accueil doit se faire en personne, avec une présentation de l’équipe, du projet, du contexte fonctionnel, des outils et des pratiques techniques. Il est essentiel de désigner un mentor, pas forcément le plus expert, mais quelqu’un de pédagogue, disponible, empathique et capable d’accompagner progressivement vers l’autonomie.
Les premières semaines doivent mélanger tâches simples, pair/mob programming, feedback régulier et montée en complexité graduelle. Le rapport d’étonnement permet de détecter incompréhensions, surprises et irritants avant qu’ils ne deviennent des problèmes.
Pendant les trois premiers mois : accompagnement continu, mise à jour de la matrice de compétences, formation aux outils, feedback bilatéral et tâches de plus en plus complexes.
Un onboarding structuré augmente de 42 % les chances de fidéliser la personne et réduit le temps avant qu’elle devienne autonome.

Kafka 4, fantastique ?

Conférencier : Damien Lucas, Mirakl
Rédacteur : Marc Lasfargues

Petite review des nouveautés dans Kafka 4 : entre les petits changements de configuration, le remplacement de Zookeeper par KRaft et le rework du rebalancing pour le simplifier et retirer les "stop-the-world" (on arrête la consommation sur toutes les partitions du topic), la grosse nouveauté pour les développeurs sera l'arrivée des queues (en early access sur la 4.0) qui vont révolutionner la gestion de comment consommer les messages d'un topic.
Avec les queues, plus de last offset consommé et de partitions qui limite le nombre de consumers, chaque message aura son statut pour savoir s'il peut être consommé, est entrain d'être consommé (avec un timeout), a été rejeté ou a été traité. Ceci permet donc de gérer la consommation message par message et évite la fameuse DLQ pour gérer les messages qu'il faut consommer car tombé en erreur.

Live-Coding : algorithmes de génération de labyrinthes

Conférencier : Fabien Lamarque
Rédacteur : Cédric Boutin

Pas d’IA, pas de joli IDE, pas de tests, juste un terminal et des scripts, devant 60 personnes, pendant 40 minutes. Fabien Lamarque réalise une session de live coding sur des algorithmes de génération de labyrinthes. Attention, pas n'importe quels labyrinthes, des labyrinthes dits “parfaits”, c’est-à-dire que chaque cellule est reliée à toutes les autres de manière unique et où il ne peut donc pas y avoir de boucles.
Fabien présente une série de trois algorithmes montrant les différences de manière très visuelle avec des petits scripts outils afin de voir graphiquement comment sont générés ces labyrinthes pas à pas ou calculer combien de temps en moyenne chaque algorithme met pour créer un labyrinthe. Fabien a également pu mettre en place un algorithme de Dijkstra pour résoudre en direct tous les labyrinthes générés.
Bien que la génération de labyrinthe ne soit pas utile en tant que tel dans la vie de tous les jours (sauf si vous avez besoin de créer des jeux pour un quotidien papier), la conférence est restée très intéressante grâce à un public qui a pu aider Fabien au fur et à mesure des bugs et grâce aux scripts d’outillage préparés en amont pour donner un réel impact visuel à cette conférence.

Diviser par 50 les coûts de traduction grâce à l'IA générative

Conférencier : Pietro Fodra, Peaksys
Rédacteur : Pierre Leroy

Un volume colossal, des coûts difficiles à soutenir

Peaksys travaille sur un flux massif de traduction : 500 000 à 1 million de fiches produits traduites chaque mois. Avec un coût historique avoisinant 80 $/million de tokens, la facture devient rapidement ingérable. L’objectif du projet est donc clair : réduire drastiquement les coûts tout en conservant une qualité équivalente en utilisant les LLMs.

L’apport et les limites des LLMs

Les modèles de langage ouvrent des perspectives intéressantes, notamment grâce au **finetuning **(réajustement partiel des paramètres du LLM, par entraînement), potentiellement bien moins coûteux que les solutions SaaS traditionnelles. Mais ils introduisent aussi des risques classiques : hallucinations, verbosité, troncage sur les textes longs, et parfois une latence difficile à absorber sur de forts volumes.

L’évaluation automatisée avec un LLM-as-judge, appliquée à 10 langues, permet de mesurer les résultats à grande échelle. Elle révèle notamment une information clé : la traduction champ par champ dégrade la qualité, faute de contexte suffisant.C’est la force des LLMs, plus les contextes sont importants, meilleure est la qualité de la réponse du LLM.

Cas particulier de l’Estonien

Un exemple révélateur concerne l’estonien : les résultats étaient incohérents, non pas à cause du modèle, mais d’un mauvais code ISO transmis en entrée

L’architecture finale s’appuie sur un ensemble éprouvé :

• vLLM pour la performance,
• LoRA pour réduire le coût d’adaptation,
• quantization en 4 à 8 bits pour alléger les modèles.

Le finetuning apporte des gains mesurables (5 à 10 %), mais au prix d’une complexité technique significative.

Cette conférence montre qu’optimiser la traduction massive avec des LLMs exige une combinaison d’ingénierie, de mesure fine et de rigueur opérationnelle mais permet d’obtenir des gains significatifs par rapport aux méthodes traditionnelles (Google traduction). Le gain est réel, mais il se mérite.

Parlons d'entretiens techniques

Conférencier : Ane Diaz De Tuesta, Datadog
Rédacteur : Pierre Leroy

Datadog et les standards des géants de la tech

Datadog ne conçoit pas ses entretiens techniques au hasard : l’entreprise s’appuie explicitement sur les pratiques des géants de la tech pour structurer ses évaluations. Le format, la durée, les outils et les critères de jugement sont alignés avec ceux utilisés par les leaders du secteur. Résultat : un entretien exigeant, méthodique, pensé pour évaluer non seulement la capacité à coder, mais aussi la rigueur, la communication et la qualité d’un raisonnement complet. Passer un entretien chez Datadog, c’est donc se mesurer à des standards élevés, comparables aux meilleurs benchmarks de l’industrie et en anglais !

Un entretien technique, ça se prépare comme une course

La conférence insiste sur une idée forte : réussir un entretien technique ne relève jamais de l’improvisation. C’est une épreuve qu’il faut aborder comme une course. Connaître le parcours, comprendre les règles, s’entraîner sur les bons exercices, répéter en conditions réelles : tout cela fait partie du travail. La préparation conditionne directement la performance le jour J. Plus on consolide les fondamentaux, plus on s’exerce à résoudre des problèmes dans un temps limité, plus on se familiarise avec l’outillage attendu, et plus on maximise ses chances de réussir. En clair : un entretien technique, ça se gagne à l’entraînement.

La réactivité et les signaux : démystifions la magie du frontend

Conférencier : Estéban Soubiran, MaiaSpace
Rédacteur : Thomas Lambert

Spoiler alert : c’est une synthèse vulgarisée. La présentation étant technique, bien illustrée, méritant un article à elle seule, je vous invite à approfondir le sujet et à retrouver Estéban sur ses réseaux :)

L'équation ui = F(state) est devenue la définition universelle de nos interfaces modernes; quand on modifie l'état, l'interface se met à jour : c’est la réactivité. Pourtant, cette fonction F opère comme une véritable boîte noire au sein de nos frameworks; elle offre une API déclarative simple qui nous dispense de gérer le DOM manuellement. Cependant, cette simplicité de surface masque des mécanismes de propagation complexes que seuls les plus curieux des développeurs prennent le temps d'explorer.

C'est précisément cette mécanique que la conférence d'Estéban Soubiran se propose de déconstruire en s'appuyant sur l'étude de la librairie Alien Signals. \

Au-delà de la syntaxe, les Signaux transforment l’état de l’application en un graphe de dépendances vivant. Ce graphe acyclique est le cœur de l’architecture : il garantit une cohérence topologique pour que chaque mise à jour soit "Glitch-Free", sans état intermédiaire incohérent. Concrètement, chaque nœud du graphe est interconnecté via des listes doublement chaînées. Ce choix de structure de données est crucial : il permet de naviguer dans le graphe et surtout de gérer les abonnements dynamiquement (ajout/suppression de dépendances).

C'est au travers de ces liens que s'articule la stratégie Hybride Push-Pull. Au lieu de propager les données brutes, le système utilise ces connexions pour propager des "états".

• En phase Push : Lorsqu'un nœud “dépendance” change, il parcourt sa liste d'abonnés pour les marquer (Push) comme "Sales". L'information circule, mais aucun calcul n'est déclenché.
• En phase Pull : C'est seulement lorsque l'interface a besoin d'une valeur que le nœud “abonné” concerné vérifie son état. S'il est marqué "Sale", il demande alors (Pull) les nouvelles données à ses dépendances pour se mettre à jour. \

Ce sont tous ces éléments qui vont permettre, au moment d’un changement de signal, de muter seulement l’élément du DOM concerné, offrant ainsi de meilleures performances.Voilà pourquoi, de SolidJs à Vue, et plus dernièrement Angular, les frameworks front délaissent progressivement le virtual DOM pour cette réactivité chirurgicale, Fine-Grained Reactivity.

De développer à hacker : savoir casser pour protéger

Conférencier : Florian Toulemont, Softeam
Rédacteur : Jérémy Nadal

La conférence montrait comment la culture du hacking éthique peut renforcer la sécurité des applications à l’aide d’exemples concrets. Florian a d’abord posé le décor : la cybersécurité est devenue un enjeu majeur pour les entreprises, les particuliers et les États, avec des pertes chiffrées en milliards et une croissance constante des attaques.

Il a distingué la blue team, chargée de la défense, de la red team, qui adopte la posture de l’attaquant pour dénicher les failles avant les criminels. L’idée centrale : il ne s’agit pas de savoir si l’on sera attaqué, mais quand, et ce qu’il se passera à ce moment‑là. D’où l’importance d’anticiper, plutôt que de tout refondre dans l’urgence après un incident.

La conférence revenait sur les trois grands objectifs des attaques : la confidentialité (vol d’identifiants ou de mots de passe), l’intégrité (modification silencieuse des données) et la disponibilité (rendre un service inutilisable via DDoS, chiffrement de base de données, suppression d’applications, etc.). Au‑delà des outils, Florian insistait sur le rôle clé de la curiosité et de la connaissance côté développeurs et hackers : ce sont les humains qui imaginent les scénarios d’attaque comme de défense.

Côté front, il a illustré les risques de XSS (cross‑site scripting), rappelant l’intérêt des Content Security Policy (CSP) pour limiter l’exécution de scripts aux seules sources de confiance. Côté back, il a abordé les vulnérabilités de type IDOR, où une mauvaise gestion des identifiants ou des contrôles d’accès permet d’accéder à des données qui ne devraient pas être visibles. La bonne pratique : vérifier systématiquement rôles et appartenances à chaque appel, et éviter les identifiants incrémentaux trop prévisibles.

Il a également évoqué les attaques SSRF, où un serveur est manipulé pour appeler d’autres ressources internes pour le compte de l’attaquant. La réponse passe par un filtrage strict des URI autorisées, la sécurisation des services internes, et un monitoring attentif des requêtes suspectes.

Enfin, la couche infrastructure n’est pas épargnée, avec des scénarios d’attaque autour de Docker ou de sockets visant à « sortir du conteneur » pour atteindre l’hôte. En fil rouge, le message est clair : intégrer la sécurité dès la conception et dans la CI, accepter de « penser comme un hacker » et cultiver une vigilance continue sont devenus indispensables pour protéger durablement les systèmes.

Conclusion

Nous quittons cette 10ᵉ édition avec beaucoup d’énergie et de belles discussions en tête. Merci aux organisateurs, aux speakers et à toutes les personnes venues nous voir.
C’était une très belle journée pour célébrer dix ans d’innovation.
Pour revoir les conférences ou prolonger l’expérience, la chaîne YouTube officielle est disponible ici.

Rendez-vous en 2026 pour continuer l’histoire et ouvrir la décennie suivante !