La plupart des conseils sur le changement de stack le traitent comme un problème technique : apprendre la nouvelle syntaxe, les nouvelles API, le nouvel outillage. C'est la partie facile. La partie difficile, c'est de savoir quand un changement de stack vaut l'investissement en temps, comment s'engager pleinement pour aller vraiment en profondeur au lieu d'enjamber, et ce sur quoi vous pouvez compter comme transférable même quand le renouvellement de frameworks semble total. Plus de dix ans et trois changements de stack majeurs plus tard (de jQuery et AngularJS à React, de React à Angular, et d'Angular à son ère des signals avec des back-ends Python), voici le modèle de décision que j'utilise.
J'ai commencé avec jQuery, Bootstrap, du JavaScript vanilla et AngularJS. Plus de dix ans plus tard, j'écris des composants TypeScript pour la plateforme Angular d'une grande banque d'entreprise et je construis mon propre SaaS sur un Angular basé sur les signals. La distance entre ces deux points est énorme, pas seulement techniquement, mais professionnellement et philosophiquement. Je veux parler de comment j'ai navigué cette distance, ce que j'ai mal fait en chemin, et ce que l'expérience m'a appris sur l'apprentissage de nouvelles technologies sans perdre pied.
L'évolution du stack, honnêtement
Voici une carte approximative de comment mon stack a évolué :
- 2014-2015 : HTML/CSS, JavaScript, jQuery et Bootstrap. Des sites responsive pour une plateforme d'emploi avec des millions de CV. C'est là que j'ai appris à construire des choses qui fonctionnaient vraiment, et là que j'ai donné ma première conférence sur le HTML sémantique et le responsive design.
- 2015-2017 : React a émergé comme le gagnant clair de l'industrie et j'ai pris la décision délibérée de l'apprendre, en construisant une plateforme de voyages de groupe avec. Ça entrait en conflit avec mon cerveau de designer (JSX me semblait faux au début) mais j'ai appris à apprécier sa composabilité.
- 2017-2019 : Angular 2+ a pris le dessus, poussé par les projets devant moi : une plateforme de bilans de santé, des tableaux de bord de trading en temps réel avec D3.js et WebSockets, des applications jQuery legacy migrées vers Angular, et un portail d'activation d'assurance. TypeScript est venu avec et n'est jamais reparti.
- 2020-2021 : Une période très orientée design. Des tableaux de bord de données pendant un diplôme en analyse de données et le stage qui l'accompagnait, puis la direction de la refonte d'une plateforme de santé mentale comme UX lead. Angular est resté à jour en parallèle, pas en production.
- 2022-présent : Angular à grande échelle. Une PWA de cartes de crédit migrée d'Angular 13 à 15 dans un monorepo, la plateforme de demande de prêt d'une banque bâtie sur des micro-frontends que je viens de rejoindre, et mon propre SaaS avec un front-end Angular basé sur les signals et un back-end Python. C'est là où j'en suis maintenant.
Cette progression semble propre rétrospectivement. Sur le moment c'était plus désordonné. Il y a eu des années où j'enjambais deux ou trois stacks simultanément, expert dans aucun d'entre eux, essayant de rester employable tout en restant sain d'esprit.
Ce qui change avec chaque stack
Quand vous changez de stack, évidemment la syntaxe change. L'outillage change. Les idiomes et patterns changent. Si vous passez de React à Angular, vous n'apprenez pas juste des noms de fonctions différents, vous apprenez un modèle mental différent de comment une application est organisée. Angular est centré sur les modules (ou les composants avec standalone), opinioné, chargé de conventions. React est sans opinion, flexible, laisse les décisions d'architecture à vous.
L'écosystème change. La communauté change. Le langage du marché de l'emploi change. Les développeurs Angular et les développeurs React pêchent dans des viviers partiellement qui se chevauchent mais significativement différents quand il s'agit d'emplois, d'équipes et de conversations.
La charge cognitive du changement est réelle et sous-estimée. Je me souviens de mes premiers mois à faire du Angular sérieux après React. Je continuais à chercher les patterns React instinctivement puis je me heurtais à un mur. La tentation d'écrire du code style React en Angular est forte et produit du mauvais Angular. Il faut s'engager à apprendre le nouveau paradigme selon ses propres termes, pas comme une traduction de l'ancien.
Ce qui reste pareil
C'est la liste la plus importante. Voici ce qui a été vrai dans chaque stack avec lequel j'ai travaillé, sur plus d'une décennie :
- La pensée en composants, découper une UI en morceaux avec des responsabilités claires, est universelle. La syntaxe diffère, les noms de méthodes de cycle de vie diffèrent, mais la compétence de décomposition se transfère complètement.
- La pensée en gestion d'état : local vs partagé, synchrone vs asynchrone, dérivé vs source de vérité, est identique entre les frameworks. NgRx et Redux sont philosophiquement la même chose en habits différents.
- L'intuition de performance : comprendre les reflows et repaints, le coût du sur-rendu, la valeur de la mémorisation, s'applique partout et ne fait que s'approfondir.
- TypeScript et la pensée en types. Une fois que vous développez un véritable état d'esprit type-first, il vous suit partout.
- Les principes de test : isolation, assertions significatives, tester le comportement pas l'implémentation, ne changent pas.
- Lire la documentation et lire le code source. Cette compétence se compose massivement. Après plus de dix ans je peux naviguer le code source d'un framework inconnu plus vite que la plupart des développeurs juniors lisent sa documentation.
- La communication. Comment écrire une description de PR claire. Comment expliquer une décision technique à un stakeholder non technique. Comment contester une spec sans créer de conflit. Ça ne se déprécie jamais.
Comment évaluer s'il faut investir dans une nouvelle technologie
C'est la question que les développeurs en milieu de carrière me posent le plus souvent : comment décider quand faire un investissement majeur dans quelque chose de nouveau ? Voici mon cadre honnête :
1. Est-ce adopté par des organisations comme celles où vous voulez travailler ?
C'est le filtre le plus pratique. L'adoption technologique suit des patterns d'industrie. Si vous voulez travailler en finance d'entreprise, certaines technologies (Angular, Java, .NET) ont des racines profondes. Si vous voulez travailler dans des startups produit, le stack est différent. Recherchez ce que les vraies offres d'emploi dans votre segment cible demandent. Ce qui est demandé systématiquement ? C'est là que le ROI d'apprentissage est le plus élevé.
2. Est-ce que ça résout un vrai problème que vous avez, ou c'est juste nouveau ?
Il y a toujours un nouveau framework. Svelte, Solid, Qwik, Astro : tous sont réellement intéressants. Certains résolvent de vrais problèmes. Mais si vous travaillez en Angular et qu'Angular résout bien votre problème, le ROI de passer à Svelte est bas. J'investis dans une nouvelle technologie quand elle résout quelque chose avec lequel je lutte réellement. Sinon j'en apprends superficiellement pour rester informé et je passe à autre chose.
3. Quel est le coût d'opportunité ?
Apprendre un nouveau framework prend du temps réel. Le temps passé à apprendre Svelte est du temps non passé à aller plus profond en Angular, qui est ce pour quoi je suis payé. Je suis ça consciemment. Mon budget d'apprentissage n'est pas infini, et il y a des rendements décroissants à la largeur une fois qu'on est déjà généraliste.
4. Y a-t-il un signal de communauté et de longévité ?
J'ai été brûlé tôt dans ma carrière en investissant dans des technologies qui se sont estompées rapidement. J'attends maintenant une deuxième vague d'adoption avant de m'engager pleinement. La deuxième vague est quand les early adopters ont trouvé et documenté les points douloureux, quand l'écosystème a assez mûri pour supporter l'utilisation en production, et quand les organisations commencent à poster des emplois pour ça. Surfer la première vague est excitant ; surfer la deuxième vague est plus productif.
L'état d'esprit du spécialiste généraliste
Le terme que j'utilise pour ce que je suis est 'spécialiste généraliste.' J'ai une profondeur réelle dans des domaines spécifiques, Angular, TypeScript, architecture front-end, UX/UI, et j'ai une littéracie fonctionnelle dans un éventail plus large de technologies. Cette combinaison est différente d'être un pur généraliste (superficiel dans beaucoup de choses) ou un pur spécialiste (profond dans une chose).
Le spécialiste généraliste est le plus précieux quand les problèmes sont complexes et transfonctionnels : quand bien résoudre quelque chose nécessite de tirer sur plusieurs compétences simultanément. Dans une équipe d'entreprise construisant une interface bancaire complexe, être capable de penser à l'architecture TypeScript, au système de design tokens SCSS, et au design d'interaction utilisateur simultanément est plus précieux que n'importe quelle spécialité unique.
Le risque du spécialiste généraliste est l'identité. Au début de ma carrière je ne savais pas comment me décrire et cette incertitude se voyait en entrevue. Maintenant je suis clair : je suis un développeur front-end senior avec un bagage UX. Commencer par la compétence primaire et nommer la seconde comme un bagage positionne la compétence secondaire comme un amplificateur de la primaire, pas un diluant.
Ce que je dirais à quelqu'un en année 5 de carrière
Cinq ans dans une carrière est généralement le moment où les développeurs commencent à remettre sérieusement en question leurs choix de stack. Vous en savez assez pour voir les limites de ce que vous utilisez, et vous êtes conscient que le domaine avance vite. Voici mon conseil honnête :
Ne changez pas de stack par anxiété. Changez quand vous avez une raison claire : un nouveau rôle, un problème réel résolu par le nouvel outil, une expansion délibérée de votre valeur sur le marché. Le changement de stack motivé par l'anxiété produit une expertise superficielle partout et profonde nulle part.
Quand vous changez, engagez-vous pleinement. N'écrivez pas votre nouveau stack dans les idiomes de votre ancien stack. Apprenez comment la nouvelle communauté pense, pas juste la syntaxe. Lisez le guide de style officiel. Étudiez de vrais codebases de production dans la nouvelle technologie. Le chemin le plus rapide vers la profondeur est l'immersion délibérée, pas le tâtonnement prudent.
Chaque changement de stack donne l'impression de repartir de zéro. Ce n'est pas le cas. Vous apportez tout ce qui n'a pas de nom.
Références
- Stack Overflow Developer Survey, latest edition. https://survey.stackoverflow.co/
- Angular documentation. https://angular.dev/