J'ai dirigé des équipes frontend de 3 et des équipes de 13 personnes. J'ai géré des développeurs dans une agence startup à Bergame, des ingénieurs senior chez AXA Suisse, et des squads cross-fonctionnelles chez Migros et UBS. Les tailles d'équipe, les stacks techniques et les industries étaient différents à chaque fois. Mais les patterns qui font réussir les équipes ? Ils sont remarquablement constants.
Ce n'est pas un article sur les cérémonies Agile ou les OKRs. C'est sur ce que j'ai réellement vu fonctionner quand votre mission est de rendre un groupe de développeurs frontend plus efficace que la somme de ses parties.
Vision technique sans dictature
Le plus grand piège pour les tech leads est de devenir le goulot d'étranglement. Vous avez des opinions, de l'expérience, et vous pouvez probablement architecturer la solution plus vite que quiconque dans votre équipe. Mais si chaque décision passe par vous, vous avez créé un point de défaillance unique — et vous avez privé votre équipe de la croissance qui vient de prendre ses propres décisions.
Chez AXA, quand j'ai fondé l'équipe Style Guide et construit une bibliothèque de composants cross-framework avec Web Components, je n'ai pas conçu chaque composant moi-même. J'ai défini la direction architecturale — Web Components pour l'agnosticisme de framework, un pattern clair de contrat d'API, l'accessibilité comme non-négociable — puis j'ai laissé les ingénieurs posséder leurs composants de bout en bout. Le résultat était meilleur que ce que j'aurais construit seul, parce que différents développeurs ont apporté des perspectives que je n'avais pas envisagées.
Mon approche : définir clairement les limites et contraintes, puis donner un maximum de liberté à l'intérieur. Chez UBS, où je gère 13 développeurs frontend dans différents domaines, je définis les patterns pour la structure de nos applications, le flux d'état et la gestion des préoccupations partagées. Mais dans ces garde-fous, chaque squad prend ses propres décisions d'implémentation.
La code review comme mentorat
La code review est l'activité à plus fort effet de levier d'un tech lead. Non pas parce qu'elle attrape des bugs — vos tests devraient le faire — mais parce que c'est un moment d'enseignement individuel avec un contexte immédiat et concret.
Je revois le code différemment selon qui l'a écrit. Un développeur junior reçoit des retours détaillés sur les patterns et principes. Un développeur mid-level reçoit des questions qui le poussent à réfléchir aux edge cases qu'il a manqués. Un développeur senior a des discussions architecturales sur les compromis.
La clé est de ne jamais juste dire « change ça ». Toujours expliquer pourquoi. « Ça crée un re-render à chaque changement d'état parce que la référence d'objet change — considère useMemo ici » enseigne quelque chose de transférable. « Utilise useMemo » n'enseigne rien.
J'encourageais parfois les reviewers à laisser un « commentaire d'apprentissage » en plus de leur feedback — pas une demande de changement, juste une observation sur quelque chose d'intéressant dans le code, un pattern à connaître, ou une amélioration potentielle pour la prochaine fois. Ça a aidé à faire évoluer les reviews d'un pur exercice de gatekeeping vers du partage de connaissances.
Recrutement et onboarding
L'équipe que vous construisez détermine le logiciel que vous livrez. J'ai recruté et intégré des développeurs dans plusieurs pays, et le trait le plus important que je recherche n'est pas la connaissance d'un framework — c'est la capacité de penser comme un ingénieur.
Qu'est-ce que ça signifie concrètement ? Je veux des gens qui ne sont pas des fanboys d'une technologie particulière. React, Angular, Vue, Svelte — ce sont tous des outils, et un bon ingénieur choisit le bon outil pour la bonne tâche. Quand quelqu'un me dit que sa stack est « la meilleure » sans préciser pour quoi, c'est un signal d'alerte. Quand quelqu'un peut expliquer pourquoi il choisirait une approche plutôt qu'une autre selon les contraintes — taille de l'équipe, délais, infrastructure existante, maintenabilité à long terme — c'est cette personne que je veux dans mon équipe.
Je peux enseigner React à quelqu'un en un mois. Je ne peux pas lui enseigner à évaluer si une bibliothèque vaut la peine d'être ajoutée, si un pattern va scaler, ou si une abstraction sert l'équipe ou juste son ego. Ce sont des jugements qui viennent de l'expérience et de l'honnêteté intellectuelle.
Pour l'onboarding, j'utilise une approche graduée : semaine un, c'est lire du code et poser des questions, semaine deux, de petits bugfixes avec review en binôme, semaine trois, une petite feature. Dès la quatrième semaine, la plupart des développeurs contribuent de manière significative. La clé est de rendre sûr de poser des questions « stupides » — parce que dans mon expérience, la question « stupide » pointe généralement vers quelque chose que l'équipe a ignoré.
La dette technique est une conversation, pas un backlog
Chaque équipe que j'ai rejointe avait un backlog « dette technique » que personne ne touchait. Des tickets « refactorer X » ou « upgrader Y » perpétuellement déprioritisés parce qu'ils ne livraient pas de valeur business visible.
Mon approche est différente : la dette technique est traitée en parallèle du travail de features, pas à la place. Si vous construisez une feature dans un module endetté, vous nettoyez ce module dans le cadre du travail de feature. La règle du Boy Scout au niveau du module.
Chez Vontobel, en construisant la plateforme markets, nous avions une intégration CMS legacy pénible. Plutôt que de créer un epic « refactorer la couche CMS » qui ne serait jamais staffé, nous avons amélioré l'intégration de manière incrémentale — chaque feature qui touchait les données CMS laissait cette couche un peu plus propre. En deux trimestres, l'intégration était solide, et nous n'avons jamais eu à justifier un « sprint dette technique » au business.
Cela demande de la discipline du tech lead : il faut scoper le travail de feature pour inclure le nettoyage et défendre ce scope en sprint planning. « Cette feature fait 5 points, pas 3, parce qu'on doit corriger le data layer dont elle dépend » est une conversation que j'ai eue des centaines de fois.
Le côté humain
La partie la plus difficile du leadership de développeurs n'est pas la technologie — ce sont les gens. Les développeurs ont des egos (moi inclus). Ils ont des semaines difficiles. Ils sont en désaccord entre eux et avec vous. Ils partent vers d'autres entreprises. Ils font du burnout.
Ce que j'ai appris : la transparence construit la confiance plus vite que tout. Partagez le raisonnement derrière les décisions, même les inconfortables. Si un projet est en retard, dites-le et expliquez le plan. Si vous avez fait un mauvais choix, assumez-le publiquement. Votre équipe suivra le standard que vous établissez.
Chez UBS, je mets fortement l'accent sur ce que j'appelle la « cohésion inter-domaines » — s'assurer que les développeurs travaillant sur différentes parties du produit se sentent comme une seule équipe, pas des squads isolées qui partagent un repo par hasard. Des code reviews inter-équipes régulières, des ADR partagés, et du pair programming rotatif entre les domaines y contribuent.
Diriger une équipe frontend, c'est créer un environnement où les bonnes décisions émergent naturellement — où les développeurs ont le contexte, les outils et la sécurité psychologique pour faire leur meilleur travail. La partie technique est importante, mais c'est la moitié la plus facile.