Le 19 juin 2025, j’ai participé à PiterJS #79 à Saint-Pétersbourg. La soirée avait un thème assez peu glamour, ce qui la rendait justement intéressante : non pas comment livrer la prochaine fonctionnalité, mais comment maintenir ce qui existe déjà — monitoring, déploiement et refactoring.
Le programme suivait cette idée de près. Pavel Shlykov a parlé de l’amélioration d’un ancien monolithe, Alexander Panfilov de FrontOps, et Igor Antonov des métriques de performance des applications web. Je suis reparti avec des notes concrètes sur les trois sujets.
La surprise est venue des Q&A. J’ai fini par gagner deux prix pour les meilleures questions posées pendant les sessions. C’est un petit détail, mais il est devenu le souvenir le plus marquant de la soirée parce qu’il résume bien pourquoi je continue à apprécier les meetups techniques en présentiel : on ne fait pas que consommer une présentation préparée. On peut tester sa compréhension pendant que les personnes qui viennent d’exposer le sujet sont encore dans la salle.
Le thème utile était la maintenance, pas la nouveauté
Les événements frontend peuvent vite devenir une succession de nouveaux frameworks, de nouvelles API et de nouvelles abstractions. PiterJS #79 était plus terre à terre. Le thème annoncé concernait le logiciel qui existe déjà et qu’il faut continuer à faire fonctionner.
C’est important, car une grande partie du travail d’ingénierie commence après la première mise en production réussie. Un monolithe legacy n’est pas automatiquement un mauvais système, et « moderniser » ne signifie pas automatiquement tout réécrire. La question pratique est souvent plus étroite : quelle contrainte pénalise réellement le système aujourd’hui, et quel changement réduit ce problème sans créer davantage de risque qu’il n’en élimine ?
C’est aussi pour cela que les trois présentations se répondaient bien. Le refactoring modifie le code. FrontOps modifie la façon dont le frontend est construit, empaqueté, livré et exploité. Le travail sur la performance modifie la façon dont on mesure le résultat. Ce sont plusieurs couches d’un même problème : garder un système réel compréhensible et maîtrisable à mesure qu’il grandit.
FrontOps ne se résume pas à un Dockerfile
Une de mes notes du meetup concernait la mise en place de FrontOps avec Docker. La distinction importante est simple : Docker est un outil, pas la définition de FrontOps.
La responsabilité frontend ne s’arrête pas forcément au moment où npm run build réussit. En production, quelqu’un doit encore penser aux builds reproductibles, au packaging des artefacts, à la configuration, au rollback des versions, au comportement du cache et à l’observation des pannes. Les conteneurs peuvent rendre une partie de ce travail plus prévisible, mais ils ne remplacent pas les décisions opérationnelles.
Cela corrige un modèle mental fréquent : un build réussi prouve qu’un build s’est terminé. Il ne prouve pas que l’application sera correctement déployée, qu’elle se comportera correctement en production ou qu’elle sera facile à restaurer lorsqu’un problème surviendra.
La performance commence par définir ce que « lent » veut dire
La présentation sur la performance était particulièrement pratique dans sa manière de cadrer la mesure. Son programme annoncé couvrait les facteurs qui influencent la vitesse de chargement, différentes métriques de performance frontend, les moyens de quantifier ce qui est « lent », et même la question de savoir pourquoi une optimisation n’est pas toujours nécessaire.
Ce dernier point est facile à sous-estimer. « Rends-le plus rapide » paraît objectif, mais sans métrique ni problème visible pour l’utilisateur, cela peut devenir une forme coûteuse de devinette. Un processus de performance utile commence par définir ce qui est réellement lent, le mesurer, identifier le goulot d’étranglement, modifier un élément pertinent, puis mesurer à nouveau.
Une métrique n’est pas l’expérience utilisateur à elle seule, mais elle donne une unité commune à la discussion. Sans mesure, le travail de performance peut devenir une série de changements techniquement impressionnants sans preuve claire qu’ils ont amélioré le problème qui comptait réellement.
Le Q&A a changé la valeur du meetup pour moi
J’aurais pu regarder les enregistrements et récupérer les liens plus tard. Ce que j’aurais eu plus de mal à reproduire, c’est l’interaction autour des présentations. Poser une bonne question oblige à condenser son incertitude en quelque chose d’assez précis pour qu’un autre ingénieur puisse y répondre.
Gagner deux prix était amusant, mais la leçon la plus utile était plus simple : venir préparé à participer donne beaucoup plus de valeur à un meetup en présentiel que le traiter comme une playlist YouTube en direct.
Une bonne question technique contient généralement du contexte et une contrainte. Au lieu de demander « Quelle est la meilleure architecture ? », il peut être plus utile de demander quel compromis change lorsqu’une équipe ne peut pas réécrire un système legacy, lorsqu’un déploiement doit rester rétrocompatible ou lorsqu’une métrique s’améliore sans bénéfice équivalent perceptible pour l’utilisateur.
Toutes les questions n’ont pas besoin d’être brillantes. Elles doivent surtout aider à faire apparaître des hypothèses, des limites ou des modes d’échec.
Ce que j’emporterais au prochain meetup technique
- Savoir pourquoi une présentation m’intéresse. Noter avant qu’elle commence un vrai problème ou une incertitude liée au sujet.
- Séparer l’expérience du speaker de mon propre système. Une bonne étude de cas est une preuve utile, pas une recette universelle.
- Poser des questions sur les compromis. « Dans quel cas ne l’utiliserais-tu pas ? » révèle souvent davantage que « Quel outil est le meilleur ? »
- Conserver une action de suivi. Une note devient plus utile si elle pointe vers quelque chose à vérifier, tester ou lire après le meetup.
- Ne pas confondre une présentation convaincante avec une preuve en production. Les décisions d’architecture, de déploiement et de performance doivent toujours être validées dans son propre environnement.
Ce qui m’est resté
Je ne veux pas exagérer ce qu’un seul meetup peut changer. Je ne suis pas reparti de PiterJS avec une recette d’architecture universelle, et une bonne présentation ne remplace ni la documentation, ni le profiling, ni les tests, ni les données de production.
Ce que j’ai réellement emporté est plus concret : de bonnes notes sur la modernisation d’un monolithe legacy, FrontOps avec Docker et la mesure de la performance web ; deux prix gagnés pendant les Q&A ; et un nouveau rappel qu’il vaut la peine de se déplacer pour les communautés locales de développeurs.
Les enregistrements peuvent conserver la présentation. Ce qu’il est le plus difficile d’archiver, c’est la conversation autour.