MiXiT 2026 : La conférence qui allie Tech et Crêpes

Indy et les conférences

En tant que développeurs chez Indy, on a la possibilité de participer pendant notre temps de travail à des conférences tout au long de l'année et partout en France. À l'issue, il est de coutume de partager avec le reste de l'équipe ce qu'on a apprécié ou appris lors du Goûter du code, rituel de partage et de discussion des équipes Tech organisé tous les vendredis après-midi.

Après quelques mois d'accalmie, nous avons décidé de relancer l'activité du blog. C'est donc une bonne occasion pour nous de tenter une nouvelle expérience ici en vous partageant notre retour d'expérience de la conférence sous la forme de cet article.

Au cœur d'une pipeline : démystifions Vite et ses plugins

Speaker : Estéban Soubiran

Vite a discrètement détrôné Webpack en téléchargements mi-2025 et s'est imposé comme socle commun du frontend moderne. Estéban Soubiran nous a proposé une session participative pour explorer la mécanique des plugins, qui sont le seul moyen d'étendre Vite, et dont relèvent même ses fonctionnalités natives.

Un plugin Vite, c'est une fonction qui retourne un objet exposant quelques hooks principaux :

export default function myPlugin() {
  return {
    name: "my-plugin",
    // 1. Résout un identifiant de module (ex: 'virtual:config' → un id interne)
    resolveId(id) {
      if (id === "virtual:config") return "\0virtual:config";
    },
    // 2. Charge le contenu d'un module à partir de son id
    load(id) {
      if (id === "\0virtual:config") return `export const env = "prod"`;
    },
    // 3. Transforme le code source d'un fichier
    transform(code, id) {
      if (id.endsWith(".js")) {
        return code.replace(/__VERSION__/g, '"1.0.0"');
      }
    },
  };
}

On a construit ensemble un petit transform plugin et découvert vite-plugin-inspect qui permet de visualiser l'avant/après de chaque plugin dans la pipeline. Estéban a aussi montré les modules virtuels (générer du code à la volée, exposer des données externes comme un module classique) et rappelé que Vite va bien au-delà du bundling : rechargement à chaud des modules (HMR) via WebSocket, des middlewares, des macros, et même potentiellement un framework serveur…

Cette chouette conférence donnait les clés pour mieux comprendre l'écosystème Vite et pour créer son premier plugin, avec un bon compromis entre théorie et exemples pratiques basés sur de vrais modules (dont le choix était laissé aux participants) qu'on décortiquait ensemble.

Wikipédia à 25 ans : de l'utopie numérique au pilier du savoir commun

Speaker : Rémy Gerbet

En quelques chiffres, Wikipédia c'est 200 millions de pages comptabilisées, plus de 24 milliards de pages vues par mois et 40 millions de contributions par mois. En France, c'est le 10ᵉ site le plus visité, et le seul du classement qui n'émane pas d'un géant de la tech.

Malgré ces chiffres impressionnants, Wikipédia fait face à un nouveau défi avec l'avènement récent de l'IA :

• une baisse de fréquentation, à mesure que l'usage des LLM progresse.
• une baisse des contributions et de la visibilité, et donc des dons.
• de nombreux contenus générés par IA, souvent de mauvaise qualité, qui ajoutent du bruit à modérer.

Pourtant, ce site représente, grâce à sa transparence (tout le monde peut voir qui a modifié quoi) et sa liberté (tout le monde peut contribuer, même s'il y a des mécanismes de protection sur certaines pages sensibles), un refuge face à la fausse information, si essentiel en ces temps !

D'où l'importance de contribuer à notre tour à cette œuvre collective : on peut le faire directement sur les articles, mais aussi sur les outils. D'ailleurs, la fondation Wikimédia organise régulièrement des hackatons pour les plus motivés : Wikimedia Hackathon 2026.

Qui décide ce qu'est du bon code ?

Speaker : Romain Tellier

Romain a vécu le passage d'une équipe de 8 devs à 5 équipes et 30 devs : les décisions historiquement discutées et actées par l'ensemble de l'équipe étaient ensuite prises par un socle de 4 personnes "sachantes". Cette situation entraînait plusieurs risques selon lui, comme notamment :

• des biais de préférence (untel préfère faire comme si ou comme ça).
• des "on a toujours fait comme ça" hérités d'anciennes habitudes.
• des règles implicites, actées et gardées dans la tête de chacun.
• de moins en moins de décideurs au fur et à mesure que les gens quittent la boîte.

Sa question initiale de "qui décide ce qu'est du bon code ?" est devenue "pourquoi en est-on arrivé à si peu de décideurs ?" et il nous a proposé un top 3 de ses pratiques pour repartager la connaissance plus largement et stimuler les interactions :

1. Limiter le name-dropping : inspiré d'un article sur Bourdieu et les coding dojos, il proposait deux règles : ne pas parler d'un langage sans rapport avec ce qu'on fait, et vulgariser tout concept mentionné plutôt que de balancer un lien Wikipédia ou un nom de concept obscur.
2. Réduire le gatekeeping en donnant du contexte, en explicitant les problèmes anticipés, et en documentant les décisions dans des Architecture Decision Records.
3. Faire du mob reviewing : ils allouaient 1 h par semaine à faire de la revue de code ensemble. L'effet principal : démystifier ce qui se joue au moment des décisions et que chacun ose donner son avis.

Sa conclusion : le code est avant tout un système de communication entre personnes, et comme tout système de communication, il est traversé par des schémas de domination. L'exemple junior/senior, le processus de recrutement, la revue de code.

En bref, c'était une super conférence qui reliait des concepts sociologiques avec le quotidien dans les équipes de devs.

Ça résonne beaucoup avec nos pratiques chez Indy : les ADR documentent les décisions techniques et permettent le débat, les guildes rassemblent les volontaires sur des sujets transverses, l'utilisation des Conventional Comments clarifie les retours en review, et le Goûter du code ainsi que le blog permettent de repartager le savoir.

JavaScript fait du bruit… mais en rythme !

Speaker : Baptiste Lyet

Baptiste, développeur et musicien, avait besoin de générer des rythmes de batterie pour pouvoir s'entraîner. Plutôt que d'utiliser les outils existants, compliqués et peu accessibles, il s'est lancé le défi de construire une boîte à rythme avec des presets de différents genres musicaux : c'est comme ça qu'est né DrumBeatRepo.

Après un bref retour sur les définitions de la musique et du rythme, et quelques démos de rythmiques typiquement lyonnaises qui ont ambiancé notre amphi (apparemment on serait la capitale de la trap !), il nous a expliqué ce qu'il avait appris à travers ce projet.

Sa première version, naïve, reposait sur un simple setTimeout récursif :

const pattern = ["X", "", "", "", "X", "", "", "", "X", "", "", "", "X", "", "", ""];
const audioSample = new Audio("sounds/kick.wav");

let index = 0;

function scheduler(): void {
  if (pattern[index] === "X") {
    audioSample.currentTime = 0;
    audioSample.play();
    console.log(index);
  }

  index = (index + 1) % pattern.length;
  setTimeout(scheduler, 85); // 85 ms
}

Mais le résultat était peu concluant : le délai d'un setTimeout n'est jamais garanti (le thread principal est occupé par le rendu, le nettoyage de la mémoire, le reste de la page…), et au final les déclenchements dérivaient peu à peu de l'horloge, et devenaient irréguliers, c'est pas ouf pour une boîte à rythme.

Après s'être creusé les méninges et lu l'article Le récit de deux horloges de Chris Wilson, il a trouvé une approche plus fiable (avec un nom un peu barbare) : le lookahead scheduler. Au lieu de compter sur l'horloge JavaScript pour jouer le son au bon moment, on l'utilise seulement pour se réveiller régulièrement et planifier à l'avance les samples à jouer dans une fenêtre temporelle proche, en se basant sur l'horloge contenue dans la Web Audio API qui elle a l'avantage de s'exécuter sur un thread distinct et est en prime (de l'ordre de 40.000x) plus précise. Les sons sont maintenant joués de manière déterministe !

Une chouette conférence qui a été l'occasion pour nous de découvrir un aspect de JavaScript que nous n'avions jamais eu l'occasion de creuser jusque-là. Pour vous amuser avec DrumBeatRepo, c'est ici.

Quelques autres sujets que nous avons appréciés

Il y avait tout un tas d'autres conférences intéressantes, on ne va pas les détailler ici mais voici quand même quelques recommandations de visionnage.

• L'indépendance des médias... indés (David Dufresne) : Une plongée dans les coulisses des médias indépendants et les batailles qu'ils mènent pour rester libres face aux pressions économiques et politiques.
• Le futur du développeur : IA, compétences et obsolescence (Julie Mouveroux & Estéban Soubiran) : Une réflexion sur la manière dont l'IA redéfinit notre métier et sur les compétences à cultiver.
• Pourquoi la Tech tient plus de la pop culture que de l'ingénierie ? (Julien Topçu) : Un talk qui montre à quel point nos choix techniques suivent souvent les modes et les tendances plutôt qu'une véritable démarche d'ingénierie.

À l'année prochaine, MiXiT ?

Même si tous les talks sont enregistrés et visionnables en ligne, aller à la rencontre de nouveaux sujets et de nouvelles personnes, sortir de son quotidien pour assister à ce genre d'événements est un super moyen de nourrir notre curiosité (et de manger les fameuses "crêpes de Raph").

En plus, MiXiT est une conférence à taille humaine fidèle à son nom depuis 15 ans avec sa grande diversité de sujets, de la tech, mais pas que, et son ambiance bienveillante.

Bref, c'était top. Merci à celles et ceux qui font MiXiT !

Ressources utiles :

• Site officiel MiXiT 2026
• Chaîne youtube pour revoir les talks
• Programme complet