Le 5 juin 2025, j’ai assisté à MoscowJS 65 chez T Bank à Moscou. À ce moment-là, je travaillais déjà avec JavaScript depuis six ans. Je n’y allais donc pas pour qu’un meetup me dise quel framework ou quel outil utiliser ensuite. Je cherchais autre chose, plus difficile à obtenir lorsqu’on travaille seul : quelques heures concentrées sur des sujets techniques précis, au milieu de personnes qui s’intéressent aux mêmes problèmes.
Le programme était très orienté IA. D’après le programme officiel de MoscowJS 65, les quatre talks portaient sur un assistant basé sur un LLM, le fonctionnement et les limites de l’IA moderne, l’utilisation de vision-language models pour les tests UI, ainsi que les risques de sécurité liés à l’IA autour de NPM. Le programme était compact, mais il abordait un même thème général sous des angles d’ingénierie très différents.
Ce qui m’est resté
Les talks étaient intéressants techniquement, mais l’atmosphère comptait tout autant pour moi. Les intervenants transmettaient une vraie énergie, et l’événement paraissait vivant plutôt que passif. C’est l’une des raisons pour lesquelles j’aime toujours les meetups locaux de développeurs.
Je peux lire de la documentation, des articles et du code source à tout moment, tout comme regarder des enregistrements de conférences. Tout cela est indispensable. Mais un meetup crée une autre forme de concentration : une soirée, un nombre limité de sujets et une salle remplie de personnes assez intéressées pour venir en parler sur place. Pour les sujets de niche, ce contexte aide à mieux retenir les idées et à les examiner de façon plus critique.
Un talk est un point de départ, pas une preuve
Il y a aussi une limite importante. Un talk de conférence n’est ni une documentation, ni un benchmark, ni la preuve qu’une approche est prête pour mon propre code de production. Une bonne démo peut être utile sans démontrer que la même idée résistera à d’autres contraintes, edge cases, coûts de maintenance ou hypothèses de sécurité.
Avec l’IA, cette distinction est particulièrement importante. La question n’est pas seulement de savoir si la démo fonctionne. Je veux aussi savoir ce qui a réellement été démontré, ce qui a été supposé, si le résultat est reproductible, quels nouveaux modes de défaillance apparaissent et si l’outil réduit réellement la complexité ou ne fait que la déplacer ailleurs.
C’est l’étape d’ingénierie qui vient après le meetup. L’événement peut mettre une idée sur mon radar. La vérification doit encore se faire séparément.
Pourquoi je continue à y aller
JavaScript est suffisamment vaste pour qu’on puisse passer des mois dans la seule partie nécessaire à un projet donné. Un meetup casse brièvement cette routine. À MoscowJS 65, un même thème reliait les outils développeur, le comportement des modèles, les tests et la sécurité des packages. Je n’avais pas besoin d’adopter chaque idée pour que la soirée soit utile.
Ce que l’événement m’a rappelé est beaucoup plus simple : après six ans avec JavaScript, j’aime toujours approfondir des sujets précis et en discuter avec des personnes qui partagent le même intérêt. L’écosystème change, les outils à la mode changent, les sujets des talks changent. Cette partie-là ne change pas.
Pour moi, c’est encore une raison suffisante pour continuer à participer à des événements locaux pour développeurs.