Fullstack, c’est quelqu’un qui est expert en rien ?

Vous avez sûrement déjà entendu cette phrase :

« Un développeur fullstack est expert en rien. »

Il y a quelques années, je le pensais moi aussi.

À cette époque, j’étais développeur backend et j’investissais énormément de temps à approfondir mes connaissances techniques. Dans ce contexte, imaginer qu’un développeur puisse maîtriser à la fois le front et le back me semblait irréaliste.

Pour moi, recruter un développeur fullstack signifiait chercher un « couteau suisse », capable de bricoler un peu partout, mais sans réelle expertise.

Mais avec le temps, mon point de vue a évolué.

Qu’est-ce qu’un développeur fullstack ?

Un développeur fullstack est un profil capable de comprendre et d’intervenir sur l’ensemble de la stack technique : du frontend au backend, en passant par l’intégration continue ou même l’infrastructure.

Contrairement aux idées reçues, il ne s’agit pas nécessairement d’un expert dans chaque domaine, mais plutôt d’une personne suffisamment polyvalente pour comprendre comment les différentes parties du système s’articulent.

On entend parfois un autre terme pour désigner ce type de profil : un T-shaped developer.
C’est une personne qui possède une expertise approfondie dans un domaine précis, combinée à une bonne compréhension générale des autres aspects techniques.

C’est progressivement ce type de profil que je suis devenu.

Pourquoi j’ai élargi mon champ d’action

Au début de ma carrière, je travaillais principalement sur le backend.

Lorsque j’ai rejoint un éditeur de logiciels, j’ai commencé à réaliser que livrer une fonctionnalité ne se résumait pas simplement à écrire du code.

Il fallait aussi réfléchir au déploiement, à la scalabilité, au monitoring ou encore à la manière dont le système allait évoluer dans le temps.

Progressivement, j’ai commencé à creuser des sujets comme Docker, les architectures stateless, l’intégration continue ou l’hébergement.

Plus tard, en tant que Tech Lead, mes responsabilités sont devenues plus transverses : accompagnement des développeurs, relectures de code, qualité globale du système.

Pour mieux accompagner les équipes, j’ai aussi commencé à m’intéresser davantage au frontend : architecture d’applications front, mise en place de tests, prise en compte de l’expérience utilisateur.

J’ai également passé de plus en plus de temps à échanger avec les équipes produit et les utilisateurs, à analyser les métriques d’usage.

Comprendre le besoin avant de coder est devenu une étape essentielle dans ma démarche.

Quand la spécialisation crée des silos

Avec le temps, j’ai aussi observé un autre phénomène.

Dans certaines équipes très spécialisées, chacun finit par se concentrer sur une partie précise du système : frontend, backend, infrastructure, CI, etc.

Au début d’un projet, cela fonctionne très bien. Le système reste simple, les équipes sont petites et tout le monde comprend encore assez bien l’ensemble du produit.

Mais à mesure que le logiciel grandit, la complexité augmente. Et lorsque chacun travaille dans son coin, la compréhension globale se réduit peu à peu.

Les développeurs spécialisés deviennent alors dépendants les uns des autres pour terminer une fonctionnalité : quelqu’un doit intervenir sur le front, un autre sur le back, un autre encore sur l’infrastructure.

Le travail se fait davantage en séquence qu’en collaboration. Chacun attend qu’une autre personne termine sa partie et, en attendant, rien n’arrive en production.

Petit à petit, les équipes livrent moins vite et les délais s’allongent. Non pas parce que les développeurs sont moins efficaces, mais parce que la capacité collective de l’équipe à faire évoluer le système diminue.

La valeur d’une vision globale

Être développeur fullstack, ce n’est pas être expert partout.

C’est surtout être capable de comprendre le système dans son ensemble.

Cette vision globale permet de créer du lien entre les différentes parties d’un produit, mais aussi entre les équipes.

Un développeur fullstack peut plus facilement collaborer avec le frontend, le backend ou l’infrastructure. Il comprend les contraintes des autres et peut aider à réduire certaines frictions.

Dans une équipe, ce type de profil peut contribuer à casser les silos et faciliter la collaboration.

De développeur fullstack à Product Engineer

Mais l’aspect technique ne suffit pas.

Pour construire un bon logiciel, il faut aussi comprendre le métier et les besoins des utilisateurs.

Développer une solution techniquement parfaite mais qui ne répond pas à un vrai problème n’a pas beaucoup de valeur.

Depuis plusieurs années, j’essaie donc d’aller plus loin que la technique en travaillant davantage avec les équipes produit et les utilisateurs.

Des approches comme l’Event Storming permettent par exemple de rapprocher les équipes techniques et métier pour mieux comprendre les problématiques à résoudre.

Aujourd’hui, on parle parfois de Product Engineer pour décrire ce type de profil.

Un Product Engineer ne se contente pas d’écrire du code. Il cherche avant tout à comprendre les besoins, à mesurer l’impact des fonctionnalités livrées et à s’assurer que les solutions techniques restent alignées avec la stratégie du produit.

En conclusion

Être expert dans une seule discipline technique est une chose précieuse.

Mais dans des systèmes complexes, la capacité à comprendre l’ensemble du système devient tout aussi importante.

Les profils fullstack ne sont pas une solution miracle.

Mais ils apportent souvent quelque chose de précieux : une vision globale qui permet de relier les différentes parties du système.

Avec le temps, la complexité technique et organisationnelle s’accumule.
Et lorsqu’une équipe perd cette vision d’ensemble, livrer devient progressivement plus difficile.

C’est souvent à ce moment-là que les équipes commencent à ralentir.

C’est un phénomène que j’observe régulièrement dans les équipes avec lesquelles je travaille.