Chercher la solution là où elle se trouve, pas là où je sais chercher

Quand mon tuteur m’a demandé de concevoir une plateforme SaaS, je m’y suis mis avec sérieux et avec la mauvaise méthode. J’ai cherché mes solutions dans les endroits que je connaissais déjà. Le résultat n’a pas été un blocage, il a été plus insidieux : j’avançais trop lentement pour l’échéance qu’on m’avait donnée.

Le tâtonnement

Mon terrain d’origine, c’était le backend pur : bases de données, API, logique métier, systèmes. Devant un problème neuf, mon réflexe me ramenait vers ces territoires familiers. Je m’enlisais dans la comparaison d’ORM alors que le vrai arbitrage se jouait ailleurs. Je passais des heures sur une configuration de VPS pour finir sans décision. Chaque question méritait qu’on s’y penche, mais aucune ne faisait avancer l’application, et je manquais de recul pour trancher vite. Je m’épuisais dans des demi-choix au lieu de construire.

Face à un besoin que je n’avais jamais rencontré, je continuais à chercher des réponses là où j’avais l’habitude d’en trouver, alors qu’elles étaient ailleurs. Ma carte mentale me limitait plus que mon niveau technique.

Le déclic

Deux conversations ont changé ma manière de voir.

La première, avec mes formateurs, m’a fait comprendre qu’une stack technique en entreprise se choisit pour livrer une plateforme utilisable dans un délai donné. La meilleure décision est celle qui permet à cette plateforme d’exister assez tôt pour rendre service. Mon envie de tout construire moi-même relevait de la satisfaction personnelle avant de servir le projet.

La seconde, avec mon tuteur, m’a fait comprendre autre chose. Il m’a parlé du monde opérationnel, celui qui livre. Un informaticien qui reste dans le confort de ses outils préférés reste un informaticien lambda. Celui qui apprend à choisir ses outils en fonction du problème posé devient un ingénieur qui compte. La phrase m’a piqué. Elle avait raison.

Le déplacement

Ce que ces choix m’ont appris tient moins dans les outils adoptés que dans le changement de posture qu’ils ont provoqué.

Mes garde-fous sont restés opérants quand j’ai changé de couche. Comprendre où mes données sont rangées, versionner mes changements, savoir revenir en arrière : ces exigences restent valables sur une plateforme managée comme sur un serveur nu. Elles s’appliquent à un autre niveau, avec un vocabulaire différent. La rigueur que je m’imposais sur le backend a changé d’échelle sans perdre en substance.

La leçon la plus utile vient d’ailleurs : trouver la bonne solution est moins un problème de manque d’options qu’un problème de carte mentale trop étroite. Élargir cette carte prend du temps au début et fait gagner beaucoup ensuite.

Ce que j’en garde

Ce projet m’a moins appris sur la technique que sur la manière de l’aborder. Je sais désormais reconnaître les moments où je m’accroche à un chemin familier alors que la réponse est ailleurs. Explorer un vocabulaire technique nouveau se rentabilise vite quand c’est le bon vocabulaire pour le problème posé. Un projet d’entreprise se mesure à ce qui atteint les utilisateurs. Le reste vient après.

Ce sont trois évidences quand on les lit. Elles ne le sont pas quand on les vit. Ces mois d’alternance m’ont fait passer d’un côté à l’autre de ce décalage.