Quand j'ai rejoint BMO après des années de travail en startups et cabinets de conseil, je pensais savoir à quoi m'attendre. J'avais construit des applications Angular complexes, été la référence technique d'une équipe front-end, et livré des produits sous des délais serrés. La banque enterprise, je supposais, serait plus lente mais pas fondamentalement différente. J'avais tort, et il m'a fallu plusieurs mois pour recalibrer mes instincts.
Ce n'est pas un article sur quel monde est meilleur. Les deux ont de vrais compromis. Mais si vous êtes un développeur qui envisage de passer d'un parcours startup ou agence à une grande institution financière, je veux vous donner l'image honnête de ce qui change : techniquement, culturellement, et professionnellement.
Devriez-vous faire ce saut ? Trois signaux
Avant d'accepter une offre d'une grande banque, vérifiez si ces trois signaux correspondent à vos préférences réelles. Si deux ou plus sont un non catégorique, la transition vous frustrera peu importe le titre ou la rémunération.
- Vous pouvez tolérer le processus comme élément porteur, pas comme gaspillage. Les chaînes d'approbation en banque existent parce que le rayon d'impact d'une erreur est énorme. Si vous lisez chaque comité comme un frein plutôt que comme de la gestion de risque, vous combattrez l'environnement chaque jour.
- Vous valorisez la profondeur plutôt que la vitesse. Le front-end bancaire récompense la connaissance approfondie de votre système plutôt que la livraison rapide. Si votre motivation vient du travail greenfield fréquent et des boucles d'itération rapides, la banque enterprise vous donnera l'impression de traîner dans la boue.
- Vous êtes prêt à devenir un expert du domaine. Les produits financiers sont spécifiques et réglementés. Les meilleurs développeurs front-end en banque lisent la documentation produit volontairement. Si ça ressemble à un coût plutôt qu'à une opportunité, reconsidérez.
Le processus d'approbation n'est pas de la bureaucratie pour le plaisir
En startup, vous poussez une fonctionnalité et elle est en production en quelques heures. Parfois en minutes. La boucle de feedback est serrée, et la vitesse d'itération est le principal avantage compétitif. Dans la banque d'entreprise, un seul changement d'interface peut prendre des semaines pour atteindre la production. Si vous venez de la startup, votre première réaction est la frustration. Ça ressemble à du poids mort organisationnel, des comités qui ralentissent le progrès sans raison.
Puis on regarde ce que les couches d'approbation dans une banque servent à attraper. Un changement d'interface sur un portail bancaire peut affecter les rapports réglementaires. Un raccourci d'accessibilité pourrait entrer en conflit avec le comportement des lecteurs d'écran sur une technologie d'assistance spécifique utilisée par un segment de clients. Un nouveau patron d'appel API pourrait avoir des implications pour les systèmes de détection de fraude qui opèrent en arrière-plan. Les couches d'approbation existent parce que le rayon d'impact d'une erreur est énorme : on parle de l'argent des gens, de leurs hypothèques, de leurs économies de retraite.
Je n'ai pas cessé de souhaiter que le processus soit plus rapide. Mais je ne pense plus que le processus soit arbitraire. Ce changement de perspective compte beaucoup pour votre santé mentale quotidienne dans cet environnement.
Les cycles de revue de sécurité font pleinement partie du calendrier de développement
En startup, la sécurité est souvent quelque chose qu'on ajoute après coup. On met du HTTPS, on hashe les mots de passe, et on livre. Les revues de sécurité, quand elles existent, sont légères. Dans le secteur bancaire, la revue de sécurité est typiquement une phase obligatoire que les fonctionnalités doivent traverser, et elle a de vraies dents.
Ce que ça signifie concrètement : je dois penser aux headers Content Security Policy dès la première ligne de code d'un composant. Je dois penser à comment les données sont stockées dans la mémoire du navigateur, combien de temps les tokens vivent, ce qui se passe si un utilisateur quitte sa session. Dans un environnement comme celui-là, chaque librairie tierce est scrutée. Vous ne pouvez pas simplement faire un npm install parce que quelque chose a beaucoup d'étoiles sur GitHub. Attendez-vous à un processus de vérification qui peut inclure une revue de licence, un scan de vulnérabilités, et parfois une approbation architecturale.
Ça change ma façon d'écrire du code Angular. Je suis plus délibéré sur ce que je mets dans l'état du composant versus ce que je passe à travers les services. Je réfléchis à si des données sensibles devraient toucher le localStorage du tout. Je structure les interceptors différemment parce que ce sont des chemins critiques pour la sécurité, pas juste des wrappers de commodité.
Le Design System est non négociable, et c'est plutôt une bonne chose
Les startups adorent le design personnalisé. Chaque startup avec laquelle j'ai travaillé voulait son propre look and feel unique, sa propre librairie de composants, son propre langage d'animation. Chez BMO, j'ai travaillé avec le design system de la banque, détenu par une autre équipe. Dans une grande banque, s'écarter du design system n'est pas une décision qu'un développeur de fonctionnalités prend tout seul.
Mon premier instinct a été de résister. Je suis aussi designer UX/UI, alors avoir des contraintes imposées sur les décisions front-end me semblait limitant. Mais j'en suis venu à voir la valeur. Le design system signifie que je ne passe presque pas de temps en bikeshedding visuel. Je ne débats pas des border radius des boutons ni de si un modal devrait faire un fade ou un slide. Ces décisions sont déjà prises, documentées, et accessibles à tous. Je peux me concentrer sur ce qui compte vraiment à mon niveau : la logique d'interaction, le flux de données, l'implémentation de l'accessibilité, les caractéristiques de performance.
Un design system mature impose aussi des standards d'accessibilité de manière cohérente sur toute la surface du produit. Quand ses composants ont été testés avec des lecteurs d'écran, arrivent avec les rôles ARIA appropriés et respectent WCAG 2.1 AA, vous héritez de l'essentiel de cette conformité rien qu'en les utilisant. L'essentiel, pas la totalité : la façon dont vous les composez peut encore la casser. C'est un avantage significatif en termes d'ingénierie et juridique.
Le code legacy est la réalité technique principale
Personne ne me l'a dit explicitement avant que je rejoigne, mais le front-end bancaire est en grande partie de la gestion de legacy. Les banques font tourner des systèmes construits sur des décennies. Dans toute l'industrie, vous trouverez des applications Angular qui ont commencé sur AngularJS et ont été migrées progressivement, avec des parties du codebase qui portent encore les cicatrices de cette migration. C'est un constat sur les banques en général, pas sur le codebase dans lequel j'ai travaillé. Vous trouverez des patterns qui avaient parfaitement du sens en 2015 mais créent de vrais problèmes quand vous essayez de les composer avec des approches modernes.
En startup, le greenfield est commun. On repart de zéro tous les un à trois ans quand le produit pivote ou est reconstruit. En banque, on ne repart presque jamais de zéro. On hérite. Mon travail là-bas consistait rarement à construire quelque chose de nouveau de A à Z. C'était plus souvent d'étendre, refactoriser, ou stabiliser quelque chose qui existait déjà et dont les clients dépendaient.
Ça nécessite un ensemble de compétences différent du développement en startup. Il faut de la patience et de l'humilité. Il faut être capable de lire du code écrit par quelqu'un qui n'est plus dans l'entreprise, comprendre pourquoi ils ont fait les choix qu'ils ont faits, et décider s'il faut préserver ou refactoriser ces choix. Et il faut prendre cette décision non pas seulement sur la qualité du code mais sur le risque, parce que toucher certaines parties du codebase peut avoir des effets en cascade qui sont véritablement difficiles à prédire.
La structure d'équipe a des couches qu'il m'a fallu du temps à naviguer
En startup, la structure d'équipe est plate et fluide. On parle directement à qui on a besoin de parler, et les décisions se prennent vite. Dans une grande banque, la structure a plus de couches : architectes, équipes plateforme, équipes sécurité, gouvernance du design, product owners, business analysts, et plus encore. Chacun de ces groupes a un rôle dans ce qui est construit et comment.
Le code front-end dans une banque n'existe pas isolément. Le mien s'intègre à des services Java et Node.js à l'intérieur d'une architecture micro-frontend, et dans une configuration comme celle-là votre code se connecte à des systèmes détenus par d'autres équipes, consomme des API conçues ailleurs, et tourne sur une infrastructure que quelqu'un d'autre maintient. Apprendre à travailler au sein de cette structure, et plus important encore à construire des relations à travers elle, a pris du temps réel et un effort intentionnel.
Les développeurs qui réussissent en banque enterprise ne sont pas ceux qui sont les meilleurs codeurs en isolation. Ce sont ceux qui peuvent communiquer clairement au-delà des frontières organisationnelles, qui documentent leurs décisions, et qui construisent la confiance avec les équipes adjacentes. C'est une compétence interpersonnelle que j'ai dû développer beaucoup plus consciemment ici que je ne l'ai jamais fait en startup.
Ce qui m'a vraiment choqué
La demande de profondeur de domaine dans le front-end bancaire est plus grande que dans tout autre environnement où j'ai travaillé. En startup, vous pouvez construire ce que le product manager spécifie, livrer, itérer. En banque, vous ne pouvez pas construire de bonnes interfaces pour des produits financiers sans comprendre ces produits à un niveau qui surprend souvent les développeurs venant du logiciel grand public.
Quelle est la différence entre un CPG et un dépôt à terme dans la façon dont un client y pense mentalement ? Comment un calendrier d'amortissement hypothécaire change-t-il l'information dont un utilisateur a besoin à chaque étape d'un flux de demande ? Quelles exigences de divulgation réglementaire s'appliquent à cette transaction précise ? Je n'ai pas été embauché comme expert du domaine, mais apprendre le domaine m'a rendu nettement meilleur dans mon vrai travail d'ingénieur. Si vous rejoignez la banque en espérant ne résoudre que des problèmes techniques, vous plafonnerez plus vite que prévu.
Les bénéfices inattendus
Je veux être honnête sur ce que j'apprécie véritablement dans le développement en banque enterprise, parce qu'il y a de vrais bénéfices que je n'avais pas anticipés.
- Stabilité : personne dans une grande banque ne s'inquiète de la survie de l'entreprise, et pour les employés à temps plein, ça s'étend jusqu'à leur salaire. Ce poids mental est réel en startup et j'avais sous-estimé à quel point ça m'affectait.
- Profondeur plutôt qu'étendue : En startup, on change de contexte constamment. Là-bas, je travaillais sur moins de produits mais je travaillais dessus en profondeur. Cette profondeur produit de meilleurs résultats et une meilleure ingénierie.
- Mentorat et pollinisation croisée : Les grandes banques ont des personnes avec des décennies d'expertise dans le domaine. Les connaissances accessibles dans des conversations informelles là-bas dépassaient tout ce à quoi j'avais accès dans la plupart des environnements startup.
- Développement de carrière structuré : les grandes banques donnent typiquement aux employés à temps plein des parcours formels, des cycles de feedback et des budgets de formation. Rien de tout ça n'était fiable dans les startups où j'ai travaillé.
- Maturité en accessibilité : Le niveau d'investissement en accessibilité dans le secteur bancaire a fait de moi un développeur front-end significativement meilleur. Je connais ARIA, je connais les patterns de lecteurs d'écran, et je teste avec de vraies technologies d'assistance. C'est une compétence que j'emporte avec moi pour le reste de ma carrière.
Le verdict honnête
Le front-end en banque n'est pas fait pour tout le monde. Si vous avez besoin de boucles de feedback rapides et de travail greenfield fréquent pour rester motivé, vous trouverez la banque enterprise difficile à tenir. Si vous êtes motivé par la stabilité, la profondeur, la complexité du domaine, et la certitude que le logiciel que vous construisez est utilisé par des millions de personnes pour gérer leur vie financière, cet environnement a beaucoup à offrir.
Pour moi personnellement, la transition a nécessité une véritable recalibration. J'ai dû lâcher les réflexes de startup : la mentalité du mouvement rapide, le scepticisme envers les processus, la préférence pour l'autonomie individuelle plutôt que l'alignement organisationnel. En échange, j'ai développé la patience, la précision, et une appréciation beaucoup plus profonde pour la pensée systémique que le logiciel à grande échelle exige véritablement.
Les meilleurs développeurs front-end en banque ne sont pas ceux qui s'irritent des contraintes. Ce sont ceux qui ont appris à travailler brillamment en leur sein.
Si vous envisagez ce saut : arrivez avec de la curiosité, pas du jugement. Les choses qui ressemblent à des obstacles sont généralement porteuses. Comprendre pourquoi quelque chose fonctionne comme ça ici est presque toujours plus utile que de le critiquer de l'extérieur. Les développeurs qui s'épanouissent ont fait ce basculement explicitement. Ceux qui ne le font pas finissent soit par partir en six mois, soit par passer des années à ressentir de l'amertume envers l'environnement.
Références
- OSFI Technology and Cyber Risk. https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/technology-cyber-risk-management
- WCAG 2.1 guidelines. https://www.w3.org/WAI/WCAG21/Understanding/