React Summit 2025 : retour d’expérience de conférencier

Le 14 mars 2025, je recevais la confirmation que j’allais être conférencier au React Summit à Amsterdam. Le plus grand congrès sur React au monde! Qu’est-ce qui m’a mené à me lancer dans l’aventure qu’est une conférence internationale? Et que pouvais-je bien avoir à dire pour aller en parler sur un autre continent?

En 2024, j’ai eu l’occasion de donner mes toutes premières conférences au Web à Québec (maintenant Interface) ainsi qu’à l’Agile Tour Québec. 

Martin Nadeau, gestionnaire de l’ingénierie chez Nexapp, m’avait donné le truc de soumettre mes conférences à plusieurs endroits, afin de ne pas avoir à recommencer au début chaque fois. Depuis, j’applique cette façon de faire constamment, entre autres en utilisant mes articles de blogues pour créer de nouvelles présentations. C’est ce que j’ai décidé de faire aussi au courant de l’année 2025 pour poser ma candidature à d’autres événements avec les mêmes présentations que j’avais déjà faites. 

J’ai ainsi appliqué à des conférences à Montréal, Paris, Amsterdam et Berlin. Toutes étaient pour ma conférence « Prioriser l’architecture sur le framework, la clé d’une application Web solide ». Finalement, seul le React Summit a accepté ma candidature. Je devais m’y attendre. Les événements en informatique reçoivent énormément de candidatures ; il est donc normal de ne pas être pris à tout coup.

Adapter la présentation

Ce n’est qu’après la sélection de ma candidature que le gros du trajet était à faire. En effet, je devais amener plusieurs changements à ma présentation dans sa forme actuelle. 

Premièrement, je devais adapter le contenu pour mettre l’accent davantage sur ReactJS. À la base, j’ai structuré ma présentation pour qu’elle s’applique à tous les projets informatiques, indépendamment des technologies et des langages utilisés. Malgré cela, le comité de programmation m’a demandé de ramener davantage React dans les exemples, en partageant des expériences vécues qui mettent en valeur ce que j’explique. 

Le deuxième point à changer dans la présentation que j’ai donnée au WAQ pour qu’elle soit présentable au React Summit était de la traduire en anglais…

Ce changement s’est avéré le plus grand défi que j’ai vécu depuis que je donne des conférences. Effectivement, faire une présentation devant un gros public, c’est une chose. De le faire dans une autre langue que ma langue natale est une tout autre chose. Même si mon texte est bien traduit et que je comprends parfaitement l’anglais, exposer ses idées en direct dans sa seconde langue est beaucoup plus difficile.

Un troisième défi que j’avais à relever était de n’avoir que 20 minutes pour parler de mon sujet. Lorsque j’ai fait cette présentation au WAQ, j’avais 40 minutes. Avec la moitié moins de temps, j’ai donc dû condenser énormément le contenu tout en gardant la ligne directrice de mon sujet intacte.

Le dernier défi que j’ai eu avec cette présentation était que celle-ci devait être enregistrée d’avance. Bien que cela m’a enlevé énormément de stress lorsque j’étais à Amsterdam, j’avais beaucoup moins de temps pour me préparer et pratiquer. De plus, un gros avantage de présenter devant un public est d’avoir des points de repère dans la salle. Je trouve ça pertinent de regarder la réaction des gens lors d’une présentation pour adapter l’intonation, le débit, etc. Alors qu’à distance, je ne pouvais que regarder la caméra.

Malgré tous ces points, j’ai retroussé mes manches et j’ai donné une performance dont j’étais satisfait. Il ne restait plus que le voyage!

12 juin

Le premier point marquant de mon voyage a été lors de cette première journée en arrivant à Amsterdam. J’ai été surpris de voir à quel point la ville d’Amsterdam est facile à marcher. J’avais déjà écouté des vidéos sur le sujet, mais c’est bien différent de le vivre. De pouvoir marcher à travers le quartier industriel et même de gros boulevards sans se sentir en danger une seule fois est quelque chose que je n’ai jamais vécu en Amérique. Là où il y a une piste cyclable, il y a une piste marchable à côté. Et pour ceux et celles qui ne savaient pas, tu peux aller PARTOUT en vélo!

J’avais oublié qu’il y avait le JSNation aujourd’hui. Je n’ai pas pu assister aux conférences, faute d’arriver trop tard. Cependant, je suis tout de même allé au Circa Amsterdam pour discuter avec les gens présents. C’était le point de rencontre des conférenciers et conférencières pour aller à un souper organisé par l’événement. 

J’ai donc eu la chance de discuter avec Philip Chimento, développeur sur l’engin derrière Javascript, qui travaille sur la nouvelle proposition de gestion de temps dans le langage, les Temporals. Cette nouvelle solution, rendue à la phase 3 du développement, devrait rendre l’utilisation de librairie de date beaucoup moins fréquente.

Avant de prendre l’autobus, je suis tombé sur un lead développeur chez Miro, Medhat Dawoud, ainsi que sur Thomas Steiner, ingénieur chez Google qui travaille majoritairement de l’utilisation du WebAssembly (WASM) dans le Web. Il racontait que l’engin de calcul derrière Google Spreadsheet était réalisé en Java, puis compilé en JS avec WASM. Thomas mentionnait également les enjeux de performance lorsque le logiciel doit faire beaucoup de va-et-vient entre le Javascript et le langage compilé par le WebAssembly.

Dans l’autobus en route vers le souper pour les conférenciers et conférencières, j’ai eu la chance de discuter avec Rita Castro, ingénieure logiciel chez Volkswagen au Portugal, ainsi que membre du comité de programmation du React Summit. On parlait du changement d’emploi que l’on pouvait voir souvent chez certains développeurs et certaines développeuses logiciels dans les dernières années. Elle m’a partagé une phrase qui amène à la réflexion : « La sécurité d’emploi est lorsque tu n’es pas inquiet de trouver autre chose si tu décides de changer de travail. » Dans le sens que, si tu sais que tu es pertinent dans ton domaine, ça ne sera pas long à trouver. Donc, la sécurité d’emploi n’est pas limitée à la compagnie pour laquelle tu travailles actuellement. Si l’on regarde la dernière année, où plusieurs entreprises font des réductions de personnel, peut-être que moins de gens qu’on pensait ont cette fameuse sécurité d’emploi.

Le souper se trouvait sur le Kapitan Anna, un vieux bateau à roue. J’y ai soupé en compagnie de Nik Pash, Head of AI chez Cline, avec qui on a discuté de Vibe Coding, de nos façons d’utiliser l’intelligence artificielle dans notre travail et de nos apprentissages. Par exemple, je lui ai expliqué que les IA sont très mauvaises pour générer des scripts Javascript qui manipulent un terminal. Cependant, elles sont excellentes pour rédiger des scripts Bash ; et elles sont excellentes pour convertir des scripts d’un langage à un autre.

Face à moi se trouve Tanner Linsley, créateur de React-Query et de toute la suite de librairies TanStack. Il nous a partagé sa vision sur la répartition des responsabilités entre les bundlers, les librairies et les services d’hébergement.

Le point central de sa proposition : les bundlers devraient définir des APIs précises et standardisées. Ces APIs serviraient de contrat que les librairies et les services d’hébergement devraient respecter chacun de leur côté.

Cette approche créerait une architecture en trois couches indépendantes :

• Les bundlers définissent des interfaces claires et stables
• Les librairies implémentent les APIs des bundlers pour assurer leur compatibilité
• Les services d’hébergement prennent en charge les APIs des différents bundlers pour déployer les applications

Les librairies n’auraient plus besoin de créer des outils spécifiques pour chaque plateforme (Fly.io, Vercel, etc.), et les services d’hébergement n’auraient qu’à prendre en charge les standards définis par les bundlers. Cette standardisation réduirait drastiquement la complexité et la charge de travail pour tous les acteurs de l’écosystème.

J’ai aussi eu une courte discussion avec Zoltan Kochan, créateur et mainteneur principal de pnpm. Il donnait une conférence au JSNation intitulée : « Configurational Dependencies in pnpm ». Il m’a fait remarquer un point quand même intéressant.

Étant conférencier pour la première fois, il n’avait pas l’air d’avoir apprécié son expérience. Il disait que le sujet était peut-être trop niche pour capter l’intérêt des gens au point de créer des discussions par la suite. Ce que je retiens de cette discussion, c’est de toujours garder en tête de parler d’un sujet qui engendre la discussion et l’intérêt général des gens. Que l’auditoire reparte avec une réponse à la question : comment ça pourrait me servir ça?

Lorsque le bateau est retourné à la rive, il y a eu percussion avec le quai et presque une collision avec le bateau d’à côté. De quoi terminer la soirée sur un BAM! 

Dans le bus sur le chemin du retour, un ancien employé de Twitter qui n’a pas été épargné par les vagues de licenciement massif d’Elon Musk nous partageait que, selon lui, au moins la moitié des ingénieurs ne faisait absolument rien ou travaillait sur des projets qui n’apportent rien au produit. Par exemple, la compagnie a décidé de programmer leur propre système de paie à l’interne. On s’entend qu’on est loin de l’objectif de Twitter! L’enjeu majeur dans ce logiciel de paie, en plus d’être rempli de bogues informatiques, c’est qu’il essayait de prendre en charge la paie pour toutes les banques de leur personnel partout dans le monde.

Tout au long de son histoire, je me demandais si Twitter n’aurait pas pu faire affaire avec une compagnie spécialisée dans le domaine pour gérer la paie de son personnel au lieu de développer un produit complexe et remplis de bogues à l’interne…

13 juin

Le vendredi 13 juin était la première journée du React Summit ; la journée en « présentiel ». Ma conférence étant le mardi 17 juin, j’étais présent cette journée en tant que participant. Malgré cela, j’avais accès à la salle des conférenciers et conférencières, où j’avais un accès direct au conférencier de la journée!

React Compiler Internals

L’allocution d’ouverture était donnée par Lydia Hallie, qui présentait les dessous du compilateur React en développement chez Meta. Super intéressant de voir les différentes étapes du compilateur! Dans son fonctionnement, on se rend compte que le compilateur s’occupe aussi de faire la mise en cache du retour de la fonction d’un component : pas seulement les valeurs et les calculs à l’intérieur! Concrètement, j’ai appris qu’il sera toujours possible de conserver des useMemo dans une application qui utilise le compilateur. Cependant, ce dernier analysera son utilisation et fera une optimisation supplémentaire s’il considère une solution plus efficace.

Mon seul regret par rapport à cette conférence est que je n’ai pas eu l’occasion de demander à Lydia l’outil qu’elle utilisait pour faire ses présentations, car c’était très agréable à suivre!

Salle des conférenciers et conférencières 

Par la suite, j’ai pu discuter avec Mark Erikson, développeur principal de Redux depuis 2016, ainsi que créateur de Redux-Toolkit.  Bien que Dan Abramiv soit reconnu comme le créateur de Redux, il n’a travaillé dessus que pendant 7 mois avant d’aller travailler chez Meta. C’est Mark qui a poursuivi le travail depuis.

J’ai partagé avec Mark les défis que je constate chez les personnes qui commencent à utiliser Redux pour la première fois. Comment c’est facile de mal faire ça. C’est d’ailleurs une raison pour laquelle il a ajouté beaucoup de documentation. Il me partageait comment une bonne lib est désignée (to design) de façon à ce que les bonnes pratiques se fassent naturellement. Les gens sont canalisés vers la bonne utilisation de la librairie. 

Je lui ai ensuite demandé quelle était la suite pour Redux-Toolkit. Mark me disait que ça allait peut-être être les infinite queries dans l’API. Peut-être l’ajout de liste de query à passer au hook. On a eu une belle discussion là-dessus où j’amenais le point que ce n’est peut-être pas la responsabilité de la librairie et de React de gérer ça.

import { useQueries } from 'redux-toolkit'

const SomeComponent = () => {

  // Ceci est du pseudo-code de l'implémentation

  const responses = useQueries([fetchA(), fetchB()])

  return <div>...</div>


}

Il parlait aussi de la possibilité de créer ses « entity adapter » personnalisés. Un peu comme les middlewares de Redux.

J’ai eu l’occasion de rediscuter avec Mark Erikson à plusieurs reprises pendant le reste du voyage et je trouve que c’est une personne très réfléchie et sympathique à côtoyer! De plus, il travaille actuellement chez Replay.io, qui est un super produit pour aider à trouver les bogues sur un site Web.

Kiosque Sentry

Entre deux conférences, je suis allé voir le kiosque de Sentry pour voir les nouvelles fonctionnalités du produit. La réponse était évidente : l’IA. Plus précisément le monitoring des agents! Nous avons aussi eu une discussion sur l’intégration de Sentry dans les applications React-Native, plus précisément sur l’intégration des sourcemaps. Avec les derniers outils d’intégration de Sentry ainsi que les outils de déploiement comme EAS d’Expo, ces enjeux semblent réglés.

Je suis aussi reparti avec une tuque!

Building Full Stack Apps with Bun

J’ai ensuite assisté à une partie de la conférence de Jarred Sumner, créateur de Bun. Il présentait la nouvelle possibilité de Bun : bâtir un projet Javascript full-stack. Donc de créer un serveur qui retourne du JSX. La commande bun build peut compiler le frontend ainsi que le backend en même temps. Cette compilation est faite sur demande pendant le développement et doit donc être très rapide. Cette solution contient déjà certaines extensions pour des librairies populaires, telles que TailwindCSS.

À la fin de la présentation, on lui a demandé pourquoi Bun était si rapide à installer des dépendances. C’est que Bun essaie de passer le moins de temps possible à analyser du JSON : il convertit ce dernier en binaire. Une seconde question a soulevé un point important dans l’écosystème de React : Bun ne prend pas encore totalement en charge le compilateur React. 

En discutant avec Jared après sa présentation, il m’a avoué qu’il ne se considère pas comme un conférencier. Il se fait inviter pour parler de son produit, mais son focus est vraiment sur le développement logiciel. Un autre exemple que même les gens les plus techniques peuvent donner de bonnes conférences.

Lynx : Unlock Native for More

Après une petite pause café, ce fut au tour de Xuan Huang de donner sa conférence sur Lynx. Xuan a travaillé sur des gros projets chez Meta, dont : 

• ReasonML (maintenant ReScript), qui permet de faire des composants React dans une approche plus fonctionnelle
• L’optimisation de HermesJS, qui est devenu l’engin par défaut derrière React-Native
• Tech Lead de l’équipe du compilateur React

Xuan a présenté la vision derrière Lynx, un engin pour faire du développement mobile native tout en utilisant les pratiques et outils de développement Web. Lynx est plus un engin qu’un framework, dans le sens qu’il n’est pas possible de développer du mobile uniquement avec ça. Les développeurs et les développeuses devront utiliser une implémentation spécifique de Lynx pour transformer le code écrit vers le mobile. Par exemple, TikTok utilise Lynx-React pour développer toutes leurs applications mobiles. Lynx gagne en popularité et des gens dans la communauté ont commencé à faire leur propre extension en Svelte et même en Haskell.

Deux éléments en particulier rendent Lynx super intéressant pour le développement : 

1. Le style fonctionne avec du CSS. Il est donc possible d’utiliser toute la puissance des styles du Web, en mobile. Il a donné comme exemple le Liquid Glass d’Apple, qui s’implémente facilement en trois lignes de code CSS. Il y a donc moyen d’utiliser des librairies comme Tailwinds avec quelques configurations supplémentaires.

2. Lynx est composé de deux threads Javascript : le Main Thread et le Background Thread. Par défaut, tout le code est exécuté sur le Background Thread. Il est possible, à l’aide de décorateur dans le code, d’exécuter du code dans le thread principal. L’objectif est d’avoir un thread dédié à l’affichage d’éléments sur l’écran le plus rapide possible.

SPA to SSR and Everything in Between

Cette conférence, donnée par Tanner, créateur de React-Query ainsi que la suite TanStack, parlait de la tendance du développement Web à aller vers le Service Side Rendering (SSR). Cependant, il amenait un peu de relativité dans les tendances Web. 

En effet, il mentionne que, selon le State of React 2024, 85% des développeurs et des développeuses travaillent dans des Single Page Application (SPA). Donc, si seulement 1 personne sur 5 peut réellement utiliser les React Server Component (RSC), est-ce que la popularité d’un sujet sur les médias sociaux est si importante? Il a renchéri en précisant qu’il croit que les SPA sont là pour rester, et qu’il est important de continuer de créer des outils pertinents pour ces projets, en référençant les différentes librairies de la TanStack. Il a cependant terminé en mentionnant que les RSC étaient en route pour TanStack Router.

How to Become a Staff Engineer

Shruti Kapoor, Staff Engineer (SE) chez Slack et précédemment chez Paypal, a donné une présentation sur comment devenir un SE. Selon elle, un SE doit avoir un impact sur l’organisation, que ce soit techniquement, sur les produits développés ou encore sur les gens autour de soi. Cela peut se faire à l’aide d’initiatives ou simplement du mentorat.

Elle a ensuite partagé comment « NE PAS » devenir un Staff Engineer :

• Tu attends qu’on te dise quoi faire
• Ton syndrome de l’imposteur est trop fort. Il faut apprendre à le faire taire, car il ne s’arrêtera jamais. Il faut juste apprendre à l’ignorer davantage.
• Attendre de devenir un ou une spécialiste technique approfondi.
• Ne pas jouer à la game de la politique interne. C’est quelque chose qui va toujours arriver.
• Tu n’aimes pas le réseautage.

Un point important qu’elle mentionne est que toutes les compagnies sont différentes. Il est donc important d’adapter sa stratégie à la réalité de son entreprise. Pour y arriver, on peut se poser quelques questions :

• Par rapport à quoi êtes-vous évalué? (What are you evaluated against?)
• Où sont tes lacunes? (Where are your gaps?)
• Quel projet pouvez-vous impacter? (Which project can you impact?)
• Où est votre équipe de soutien? (Who is your support squad?)

State of the React Community in 2025

Mark Erikson a ensuite donné une conférence sur l’état de la communauté React en 2025. La raison pour laquelle il voulait parler de ce sujet initialement était la dichotomie par rapport à l’état de React à l’heure actuelle. D’un côté, React a beaucoup de succès depuis plusieurs années (c’est la librairie la plus populaire actuellement pour le développement Web). De l’autre côté, la communauté n’a jamais été aussi insatisfaite d’où la librairie est rendue. 

Beaucoup de frustrations viennent de fausses idées sur l’état de la situation dans la relation entre Meta et Vercel. Mark a pris un moment dans la présentation pour expliquer que toutes les fonctionnalités de React sont développées à l’interne pour répondre à un besoin de Meta. C’est déployé quand ils sont sûrs que c’est une bonne solution.

Bien que le tiers de l’équipe React ait quitté Meta pour aller chez Vercel, les React Server Components (RSC) restent une idée de Meta. Étant donné que cette solution demande une certaine implémentation supplémentaire, ils ont poussé Vercel à développer cette implémentation pour leur produit. Et non l’inverse!

Une autre grande source de frustration vient dans la stratégie de communication de l’équipe de React, notamment les problèmes de documentation absente sur l’approche de Single Page Application (SPA) par rapport à l’approche Server Side Rendering (SSR) et le temps qui a été pris pour que le changement se fasse. En effet, la communauté a ressenti une vraie montée de bouclier de la part de l’équipe de React par rapport à la documentation et la justification de leur décision. Un autre exemple est l’absence de documentation détaillée sur les RSC, autant dans la documentation de React que celle de Vercel.

Finalement, la vision de l’équipe de React était de créer une documentation destinée aux personnes qui débutent et que les nouveaux développeurs et les nouvelles développeuses ont avantage à commencer dans un écosystème qui prend déjà en charge les RSC (Next.JS). D’où l’absence de documentation sur la façon de débuter un projet SPA sur le site. Mark termine la conférence en disant que c’était une fausse hypothèse : la documentation n’est pas juste pour les juniors. Par expérience, je considère la nouvelle documentation de React comme une mine d’or d’informations. Plusieurs articles me servent comme référence pour partager des concepts avancés ou encore des façons de penser pour certains concepts.

Mark a écrit un article plus complet sur le sujet.

16 juin

Le 16 juin marquait la deuxième journée du JSNation, événement frère du React Summit. Cette journée uniquement en ligne présentait un ensemble de conférences axées sur Javascript.

2025 State of Javascript Testing

Daniel Afonso a exploré l’utilisation des stratégies de tests en entreprise. Les dernières approches semblent suivre la même ligne de pensée que Kent C. Dodds avec la librairie Testing-Library : créer des tests plus proches de la réalité. C’est ce que Vitest propose avec leur nouvel outil, Vitest Browser Mode. L’objectif est donc d’avoir des tests UI le plus proche du navigateur Web, car c’est celui-ci qui exécute nos applications. Cet outil de test remplacerait Testing-Library, tout en gardant le même API. Un point que je trouve intéressant sur le sujet est que Kent C. Dodds est 100% partant pour déclarer la fin de vie de sa librairie, si elle permet d’amener les librairies alternatives plus loin!

Personnellement, je reste attentif à ce qui s'en vient avec ce type d'outil de test. De plus en plus de librairies adoptent cette approche : Cypress Components, Playwright Components, Vitest Browser Mode. Si ces types de test sont rapides à exécuter, cela pourrait favoriser leur utilisation fréquente et ainsi renforcer la robustesse de nos suites de tests. Sinon, l'expérience de développement (DX) risque d'être grandement réduite, comme avec l'utilisation de Karma dans les projets Angular.

17 juin

Le 17 juin se voulait la seconde et dernière journée du React Summit. La journée de ma présentation!

Tout comme la deuxième journée du JSNation, celle-ci était à distance. Étant donné que ma présentation était déjà enregistrée, ma seule responsabilité était d’être présent sur le Discord de l’événement pour répondre aux questions… Du moins, c’est ce que je pensais. La semaine avant de prendre l’avion, j’ai su que j’allais participer à deux groupes de discussion ayant pour sujet : 

• Growing Senior & Tech Lead
• Future of Fullstack Development

Lors des préparatifs de l’événement, on m’avait posé la question si certains sujets parmi une liste m’intéressaient. Cependant, je ne m’attendais pas à devoir participer en tant qu’invité!

Growing to Senior & Tech Lead

Ce sujet a été le plus intéressant des deux! Principalement parce que plusieurs membres de l’auditoire posaient des questions concrètes sur comment s’y rendre, les enjeux associés, etc. 

Un point clé qui a été mentionné pendant la discussion a été le syndrome de l’imposteur. Que ce dernier ne disparaîtra jamais ! Il est donc important d’apprendre à vivre avec et à l’ignorer le plus souvent possible.

Prendre de la bonne expérience sur le terrain est un autre point important qui est ressorti. Car ce n'est pas toutes les expériences qui ont la même valeur. Est-ce qu'une personne qui a 10 fois un an d'expérience a le vécu nécessaire pour développer les réflexes d'un ou une senior? Il ne s'agit pas de rester longtemps au même endroit, mais d'avoir des expériences suffisamment approfondies pour voir les conséquences de ses décisions, comprendre les enjeux de maintenance à long terme, et développer une vision systémique des projets.

Thinking Like an Architect

Lucca Mezzalira a commencé à nous parler de quelques enjeux que l’on peut retrouver dans certains rôles d’architecture :

• Le désir de faire une architecture « moderne » et décentralisée inutilement
• Avoir une approche « technology-first »

• Ignorer le contexte du projet (besoin d’affaires, compétences techniques, structure organisationnelle, etc.)

Pour éviter de tomber dans l’un de ces rôles, il a partagé 11 trucs à retenir : 

1. Comprendre de quoi ton entreprise/produit a réellement besoin

2. Commencer avec les limites/frontières du produit

3. Identifier les caractéristiques de ton architecture : sécurité, résilience, disponibilité, souveraineté des données, latence, coût

4. Savoir comment modulariser la charge de travail

5. Être pragmatique plutôt que dogmatique

6. Les deux seules constantes dans les architectures logicielles sont les changements et les compromis

7. La priorité? Vos utilisateurs!

8. L’exercice d’équilibre (vision long-terme vs besoin immédiat)

9. Maîtriser votre domaine et comprendre le système

10. Communiquer, inclure et documenter

11. Concentrez-vous sur ce qui compte vraiment

Il a terminé sa présentation avec une citation courte, mais inspirante : « Architecture isn’t a title; it’s a mindset. »

Réflexions et apprentissages

Cette expérience au React Summit m’a apporté bien plus que ce que j’anticipais. Au-delà de la fierté de présenter sur une scène internationale, cette aventure m’a permis de réaliser bien des choses :

• Rencontrer des créateurs comme Mark Erikson, Tanner Linsley ou Jared Sumner m’a rappelé que même les plus grands spécialistes restent accessibles et curieux d’apprendre des autres.
• Il n’est pas nécessaire d’être maître orateur pour monter sur une scène et présenter un sujet dont vous êtes maître! Il suffit d’être passionné et d’avoir le désir de partager ses connaissances et ses expériences vécues.
• Chaque équipe, chaque entreprise a ses propres défis. Il n’y a pas une seule « bonne » façon de faire, mais plutôt des solutions adaptées à des contextes spécifiques.

Remerciements

Un immense merci à l’équipe du React Summit pour cette opportunité, à Martin Nadeau pour ses conseils avisés, et à Nexapp qui a rendu possible ma participation sur place à Amsterdam. Sans ce soutien, cette expérience n’aurait pas été la même.

Merci aussi à tous les développeurs et à toutes les développeuses qui ont enrichi cette expérience par leurs échanges et leurs perspectives.

Pour les personnes qui hésitent à se lancer dans l’aventure des conférences : n’attendez pas d’être « expert ». Votre perspective unique et vos expériences du terrain ont de la valeur. La communauté tech a besoin de diversité dans les voix qui s’expriment.

Prochaine étape : continuer à écrire, à partager, et peut-être se croiser lors d’une conférence future?