Une histoire de migration NestJS → Spring Boot, d'un doute, et de ce que ça m'a appris sur ce qui compte vraiment dans ce métier.
Je veux te raconter une histoire. Pas une success story lissée. Une vraie — avec le doute, la question inconfortable, et la réponse que j'aurais aimé entendre plus tôt.
On travaillait sur un projet sérieux. Comme souvent, ça avait commencé en MVP — tu lances, tu testes le marché, tu vois s'il se passe quelque chose. Et il s'est passé quelque chose. Les signaux étaient là. Les utilisateurs aussi.
Alors est venue la vraie question : on fait évoluer ce qu'on a, ou on repart sur des bases solides pour tenir dans le temps ? Pas la question la plus fun à poser. Mais la plus honnête.
La stack initiale : JavaScript, NestJS. Ça avait fait le job pour valider. Mais pour scaler proprement, tenir sous charge, structurer une vraie architecture — on avait besoin d'autre chose. La décision : réécrire l'API en Java, Spring Boot.
Réécrire une API, ce n'est pas juste changer de syntaxe. Tu touches à tout : la logique métier à ne pas casser, les risques de régression, le temps de développement, la dette qu'on ne veut pas simplement déplacer d'un langage à l'autre.
Et là, le Suricate… tu te retrouves avec ce qu’on pourrait appeler le syndrome de l’imposteur.Tu reçois un ticket sur un langage que tu as déjà utilisé… mais ça fait quelques mois. Même si tu sais théoriquement ce que tu fais, tu te demandes si tu vas réussir à livrer correctement. Presque tout le monde dans la tech connaît ce sentiment.
Alors tu te poses la question — honnêtement, sans te mentir : "Est-ce que je suis vraiment capable de faire ça ?"
Si on te donne un ticket dans un langage que tu n’avais pas pratiqué depuis quelques mois, même si tu l’avais déjà utilisé, ta première réaction est souvent : ‘non, je ne suis pas sûr d’y arriver.’ Et c’est honnête. Mais ce n’est pas la vraie question.
La logique métier n'a pas changé. Les entités, les règles, les flux, les cas limites — tout ça existait déjà, compris, modélisé, testé. Ce qui avait changé, c'était uniquement la façon de l'exprimer.
Hier : un service NestJS avec ses decorators, ses modules, son injection de dépendances à la façon Angular. Aujourd'hui : un @Service Spring Boot avec son contexte, son IoC container, ses annotations. Le problème ? Identique. La façon de le découper ? Identique. La solution ? Identique.
Ce que j'avais pris pour un blocage technique était en réalité un blocage de confiance. Et ce n'est pas pareil.
Ce ticket m'a forcé à voir quelque chose que je n'avais pas formulé clairement avant : ma valeur, ce n'est pas Java. Ce n'est pas NestJS. Ce n'est pas Spring Boot ou n'importe quelle autre techno que j'ai sur mon CV.
Ma valeur, c'est dans la capacité à prendre un problème, le décomposer en morceaux, comprendre les dépendances entre eux, et construire une solution étape par étape — peu importe l'outil.
Et ce que j'ai réalisé juste après, c'est que cette expérience n'a rien d'exceptionnel. Tu la vis toi aussi. Probablement à chaque sprint. À chaque ticket un peu en dehors de ta zone de confort. À chaque fois qu'on te demande de toucher un service que tu n'as jamais vu.
La vraie question que tu devrais te poser face à un ticket inconnu n'est pas "est-ce que je connais cette techno ?" — c'est "est-ce que je comprends ce problème ?". Si la réponse est oui, tu peux y aller. Le reste, tu l'apprends en chemin.
Il faut qu'on parle de l'éléphant dans la pièce. En 2026, avec les outils qu'on a — LLMs, documentation instantanée, exemples générés en secondes — la connaissance d'un langage ou d'un framework n'est plus une barrière comme elle l'était il y a dix ans.
Ce n'est pas dire que les fondamentaux ne comptent pas. Ils comptent toujours — et même plus qu'avant, justement parce que l'IA peut générer du code plausible mais faux, élégant mais inadapté au contexte. Il faut encore comprendre ce qu'on lit.
Mais si ton seul avantage en tant qu'ingénieur, c'est de connaître la syntaxe d'un framework — cette valeur s'érode vite. Ce qui ne s'érode pas, c'est la capacité à penser.
Ce n'est pas "est-ce que tu connais tel framework ?" La bonne question, c'est ce qui se passe quand tu n'as pas la réponse.
Un bon engineer ne sait pas tout. Mais il sait comment chercher, comment raisonner, et comment construire quelque chose qui tient — même quand le contexte n'est pas familier.
Il y a un signe qui ne trompe jamais. Si tu n'arrives pas à expliquer un problème et sa solution de façon simple — vraiment simple, sans jargon, sans abbréviation — c'est que tu n'as pas encore vraiment compris.
Ce n'est pas une question d'intelligence. C'est une question de profondeur de compréhension. Quand tu comprends vraiment quelque chose, tu peux l'expliquer à quelqu'un qui ne sait rien du sujet. Quand tu ne comprends qu'en surface, tu as besoin du jargon pour masquer les zones floues.
Avant chaque code review, j'essaie de me poser une question : est-ce que je pourrais expliquer ce choix technique à quelqu'un qui ne code pas ? Si non, je creuse encore un peu.
Si tu recrutes : arrête de filtrer uniquement sur la maîtrise de la stack. Donne un problème que le candidat ne connaît pas. Observe comment il réagit, pas ce qu'il produit en 30 minutes.
Si tu es en train de progresser : arrête de te rassurer en accumulant des technologies sur ton CV. Creuse plutôt. Prends un problème difficile, résous-le vraiment, et entraîne-toi à l'expliquer.
Et si on te donne un ticket dans une techno que tu ne maîtrises pas encore — rappelle-toi que la vraie question n'est pas "est-ce que je connais ce langage ?". C'est "est-ce que je comprends ce problème ?"
Si oui, tu as déjà fait le plus dur.
Ce post reflète mon point de vue personnel, construit à partir d'expériences concrètes. Pas une vérité absolue — une façon de voir les choses. Les désaccords sont les bienvenus.
Ces articles reflètent mes choix d'architecture sur des projets réels. Les retours et axes d'amélioration sont les bienvenus.