J'ai commence a developer en 2012, formation de developpeur concepteur, puis BTS, puis bac+4. Pendant ces annees de formation et les premieres annees en poste, le debat revenait souvent : specialiste ou generaliste. Symfony contre Laravel, Angular contre Vue, React contre tout le reste. Il y avait clairement deux camps, et j'ai toujours ete du cote de ceux qui pensaient qu'il fallait s'adapter plutot que se specifier sur une seule techno.
Ca m'a cote en entretien plus d'une fois. Ne pas connaitre par coeur une librairie ca peut suffire a mettre un recruteur dans le doute. Et objectivement, il y a des technos qui demandent du temps avant d'etre vraiment operationnel dessus. NestJS par exemple, ca ne s'improvise pas si tu debarques sans les bons reflexes. Mais j'ai tenu cette ligne quand meme.
Ce qui compte, c'est pas la techno
Ce que j'ai compris au fil des annees en freelance, puis en tant que CTO, c'est que la techno c'est rarement le sujet. Le sujet c'est le besoin. Ce qui fait vraiment la difference c'est d'etre l'interlocuteur qui s'interesse au metier du client, qui comprend pourquoi une fonctionnalite est demandee avant de se demander comment la coder.
Un dev qui recoit un spec et execute sans poser de questions va livrer exactement ce qui etait ecrit. Et souvent ce qui etait ecrit n'est pas ce dont le client avait besoin. Ca parait evident dit comme ca, mais en pratique c'est rare que quelqu'un prenne vraiment le temps de comprendre le metier avant d'ouvrir son editeur.
J'en etais convaincu depuis longtemps. Ce que je n'avais pas anticipe, c'est que l'IA allait rendre ca encore plus vrai et beaucoup plus vite que prevu.
Copilot d'abord, sans grande conviction
J'ai commence a utiliser Copilot autour de 2022-2023. D'abord comme autocompletion, parfois pour laisser l'outil generer des blocs de code que je retouchais. Honnêtement, a l'epoque ca ne changeait pas vraiment mon rythme de travail. Le gain existait mais il etait marginal. Je corrigeais autant que je gagnais.
Il y a environ cinq mois, j'ai change d'approche. Je me suis mis serieusement sur les outils d'IA, Claude en particulier, et ca a ete une autre experience.
Ce que ca change vraiment
En travaillant quotidiennement avec ces outils, je me suis rendu compte que la valeur du developpeur se deplace. Le code lui-meme devient presque secondaire. Ce qui compte, c'est la facon dont on exprime un besoin, la capacite a identifier quand la machine se trompe, a reorienter quand elle part dans la mauvaise direction.
Et pour faire ca, il faut quand meme des bases. Pas pour coder a la place de l'outil, mais pour comprendre quand son output est faux, incomplet ou qu'il passe a cote du probleme. Les machines interpretent mal certains problemes qui nous paraissent evidents. Pour nous ils sont evidents parce qu'on a des annees de contexte derriere. Enleve ce contexte et l'IA livre quelque chose de techniquement correct qui ne resout rien.
J'avais un ancien collegue qui avait passe des annees a devenir vraiment expert sur une techno precise. Ce niveau d'expertise lui donnait une valeur claire sur le marche. Depuis quelques mois, cette valeur s'est fortement errodee, pas parce qu'il est devenu mauvais, mais parce que ce qu'il savait faire est maintenant accessible via un prompt. Le generaliste qui a toujours raisonne au niveau du besoin, lui, n'a pas ce probleme.
Le choix du Product Management
Depuis 2026, je travaille a valider un master en Product Management. C'est la suite logique de tout ce que je viens de decrire.
Comprendre les utilisateurs, traduire leur besoin en fonctionnalites qui ont du sens, arbitrer entre ce qui est urgent et ce qui est important : c'est exactement ce que j'ai appris a faire pendant 12 ans sans le formaliser. L'IA accelere la production de code. Mais quelqu'un doit decider quoi construire, pourquoi, et pour qui. C'est le travail du PM. Et c'est la ou je veux etre.