Treize ans séparent mes débuts de développeuse junior de mon rôle actuel de lead developer (autant dire que ça ne me rajeunit pas !). Ces années passées dans des contextes variés - de l’édition de logiciel à la gestion multi-projets au sein d’une agence Web - m’ont formé sur bien plus que des langages de programmation. Ce parcours m’a appris à voir au-delà du code : la dynamique d’une équipe, les besoins réels d’un projet, les enjeux humains derrière la technique, ...
Dans cet article, je partage mon retour d’expérience. Ce que ce parcours, à la base technique, m’a appris sur l’organisation des développements, l’importance de l’apprentissage continu, et surtout la place essentielle de l’humain dans un projet.
À mes débuts, la mode était à la création de frameworks maison, plutôt qu’à l’utilisation de frameworks populaires, connus et maintenus par une communauté. Ces frameworks maison étaient peu ou pas documentés et il était impossible de chercher des réponses sur Stack Overflow. Le code était notre meilleur allié pour comprendre le fonctionnement.
Ne pas avoir débuté dans un environnement bien cadré, m’a permis d’acquérir très vite de l’autonomie et de l’expérience dans la « débrouille ». Alors oui, il y a eu du code spaghetti, les livraisons bancales, mais on dit que c’est en commettant des erreurs que l’on apprend ! (Petite pensée aux développeurs qui me souhaitent de marcher pied nu sur un Lego en voyant mon nom s’afficher lorsqu’ils lancent un « git blame » 🙃).
13 ans plus tard, nous voici en 2025 et une nouvelle génération de développeurs a émergé, avec une forte culture de l’architecture et de la qualité. Cette évolution a permis de professionnaliser les pratiques en apportant une meilleure lisibilité du code, des pratiques de tests renforcées et une attention accrue à la maintenabilité. Mais comme avec toute évolution, certains peuvent basculer dans l’excès : vouloir tout sur-structurer, abstraire à l’extrême, théoriser chaque ligne de code.
Mon expérience m’amène à penser que l’utilisation d’une technologie parfaite sur le papier ne garantit pas le succès. Acceptons l’imperfection, tout en restant exigeants. Trouvons l’équilibre entre robustesse et simplicité. C’est la mise en place et le respect de bonnes pratiques, ainsi que le choix d’une solution adaptée au contexte, qui fait qu’un projet est maintenable.
Confronté à des échéances à respecter, mais aussi à la nécessité de satisfaire les utilisateurs finaux, le lead developer est souvent tiraillé entre la précipitation et l’over-engenering. D’un côté, aller trop vite au détriment de la qualité. De l’autre, une tendance à concevoir des solutions inutilement complexes, en anticipant des besoins futurs incertains, ou en ajoutant une sophistication qui dépasse largement le besoin réel. Or, aucune de ces deux approches n’est viable pour délivrer un projet dans les temps et avec une qualité suffisante. Ce qu’il faut, c’est un savant mélange !
D’abord, ne jamais perdre de vue le lien entre la technique et les enjeux métiers auxquels elle doit répondre. Cela passe par la clarification des besoins client, afin de faire les choix techniques adaptés.
Ensuite, avoir une vision globale et long terme du projet. Cela permet de prendre du recul, d’avoir une vision critique, de recentrer les priorités. Il ne faut pas craindre de reculer pour mieux avancer.
Enfin, communiquer ! Le lead developer joue un rôle de passerelle. Il aide les chefs de projet à traduire les besoins métiers en besoins techniques, soutient l’équipe de développeurs au quotidien, et contribue à rassurer les clients sur l’avancement du projet. Il fait le lien entre la stratégie, le métier et la technique… un rôle à la fois de facilitateur, de traducteur et de guide.
Être lead developer, ce n’est pas avoir toutes les réponses, c’est savoir poser les bonnes questions pour permettre à l’équipe d’avancer ensemble dans la bonne direction.
Avec l’expérience, on a tendance à dire qu’on « sait ». Pourtant, c’est un piège dans lequel il est dangereux de tomber.
En effet, chaque projet doit casser ses certitudes et pousser à la remise en question. Ce qui a fonctionné la dernière fois est peut-être une mauvaise idée dans le contexte du projet suivant. Dans notre métier, il n’est jamais bon de se reposer sur ses acquis. Il est important de tester de nouvelles choses et de faire de la veille.
De plus, il ne faut pas négliger les idées des développeurs plus juniors ! Du fait de leurs interrogations, leurs suggestions, ils te poussent à remettre en question tes habitudes, mais aussi à étayer et justifier tes propos.
Avec le temps, j’ai appris que l’humilité technique est une compétence. Dire « je ne sais pas » ou « tu as raison » est une posture saine.
En tant que lead, on ne peut pas se limiter à la conception technique d’un projet. Il faut aussi accompagner les personnes qui le font vivre, car le facteur humain est un élément central de la réussite d’un projet.
Sur des projets au long terme, la lassitude peut progressivement s’installer avec l’éloignement des enjeux, l’accumulation de la charge mentale et l’érosion de la motivation. Il faut être attentif au moral des troupes, détecter les signaux faibles (baisse d’engagement, tensions, irritabilité, ...), et intervenir au bon moment, afin de redonner du sens à ce que l’on construit ensemble. Cela peut passer par des rituels d’équipe réguliers, des temps d’échanges ouverts, ou des rétrospectives permettant de prendre du recul sur le projet.
La gestion de l’ego technique fait aussi partie du quotidien. En tant que lead, il est de notre responsabilité de trancher entre de bonnes propositions techniques, mais il est indispensable d’arbitrer avec clarté et respect. Il faut expliquer ses choix, les ancrer dans le contexte, et rappeler que la qualité d’un développeur ne se mesure pas au nombre de débats gagnés.
Enfin, la clarté dans l’expression des besoins fonctionnels et des attendus techniques est cruciale. Quand les objectifs sont flous, les développeurs avancent dans le brouillard. Le lead doit clarifier et reformuler le besoin, valider l’attendu, afin de permettre à chacun de travailler avec sérénité et efficacité.
En réalité, être lead c’est aussi être un guide, un tampon, un facilitateur. C’est quelqu’un qui fait le lien entre les membres de l’équipe, qui rassure, qui écoute. Un médiateur discret des tensions d’équipe, un traducteur entre les besoins métier et les solutions techniques.
Avec le temps, j’ai compris qu’avoir raison n’est pas la solution. Il faut convaincre sans imposer, écouter pour mieux arbitrer, faire grandir l’équipe.
En fin de compte, 13 ans de PHP m’ont formé techniquement, mais c’est le rôle de lead developer qui m’a fait mûrir. Le code ce n’est pas « juste du code », car il comporte aussi une facette humaine, faite de compromis, de communication, de partage et parfois de psychologie.
Avec le temps, j’en suis arrivée à la conclusion que la technologie n’est qu’un paramètre parmi d’autres. Ce qui fait la différence, ce sont les personnes, les interactions, la capacité à travailler ensemble et à faire avancer un projet dans une direction commune.
Comprendre cela, c’est sortir du mythe du développeur solitaire. C’est embrasser une aventure collective où l’humain compte autant que la solution technique. C’est justement ça qui rend le métier vivant, exigeant et passionnant.
Crédit photo : gorodenkoff