Pendant des années, ma journée idéale ressemblait à ça : un problème technique difficile, un éditeur de code, et le moins de réunions possible.
Début 2026, j'ai accepté un rôle qui est à peu près l'inverse : accompagner les clients grands comptes d'une plateforme SaaS. Des points hebdomadaires. Des incidents de production à gérer en direct. Des roadmaps de déploiement à tenir. Des gens, tout le temps.
Plusieurs personnes autour de moi ont eu la même réaction polie : « Ah, tu ne codes plus ? » Avec, en sous-texte, quelque chose entre la curiosité et la condoléance.
Six mois plus tard, voilà ce que j'ai vraiment appris.
Ce que je croyais quitter
Je croyais quitter la technique. C'est faux. Je n'ai jamais autant utilisé mes années d'ingénierie que depuis que je ne suis plus « que » ingénieur.
Quand un client signale un problème de données, je ne transmets pas un ticket : j'ouvre MongoDB et ClickHouse, je diagnostique, et j'arrive côté engineering avec une analyse, pas une plainte. Quand un incident de production tombe pendant une campagne client, ma valeur n'est pas de rassurer avec des éléments de langage — c'est de comprendre ce qui se passe assez vite pour dire la vérité avec précision.
La technique n'a pas disparu de mon travail. Elle a changé de rôle : avant c'était le produit final, maintenant c'est ma crédibilité.
Ce que je ne savais pas
En revanche, personne ne m'avait prévenu pour le reste.
Annoncer à un client que son lancement doit glisser d'une semaine, c'est un exercice plus difficile que n'importe quel bug de concurrence. Un bug, ça se reproduit, ça s'isole, ça se corrige. Une déception, ça se gère en direct, sans stack trace, et chaque mot compte.
J'ai aussi découvert le poids des rituels. Le point hebdomadaire avec un client, vu de loin, ressemble à une réunion de plus. En réalité, c'est là que la confiance se construit ou s'érode — dans la régularité, dans le fait d'arriver préparé, dans les petites choses dites et tenues. Le code se compile ou ne compile pas. La confiance, elle, se compile lentement et se casse vite.
Ce n'est pas une sortie de route
On parle souvent de reconversion comme d'un virage : on quitte une voie pour une autre. Je crois que c'est une mauvaise image, en tout cas pour moi.
Je n'ai pas quitté l'ingénierie. J'ai élargi la zone où elle sert. Comprendre un système technique ET être capable de l'expliquer à un directeur non technique, tenir un diagnostic ET une relation — cette combinaison est plus rare que chacune des deux compétences séparément. C'est précisément là que je voulais aller.
Et il y a une chose que ce rôle m'a rendue, que j'avais un peu perdue derrière mon écran : voir des gens utiliser, réussir, ou galérer avec ce qu'on construit. Le feedback le plus utile de ma carrière ne vient plus d'un code review. Il vient d'un client qui me dit, en visio, pourquoi son équipe n'utilise pas la fonctionnalité qu'on a mis trois mois à livrer.
Si vous hésitez à faire un pas de côté similaire — vers le produit, le client, le business — je ne vous dirai pas que c'est facile. Je vous dirai que ce que vous savez déjà vaut plus loin de votre clavier que vous ne l'imaginez.