Pas de PM dans l

J'ai récemment passé ma période d'essai, et lors d'un 1-on-1, mon manager m'a dit : « J'aimerais que tu sois plus proactif dans l'exploration des problèmes produit. »

Ça m'a pris de court. J'écrivais du code tous les jours, je corrigeais des issues, je faisais avancer les projets. Comment ça n'était pas assez proactif ? Il m'a fallu un moment pour comprendre ce qu'il voulait vraiment dire.

Tout tourne en même temps

Passer la période d'essai ne signifiait pas moins de pression. Au contraire, ça signifiait jongler avec encore plus de choses en même temps :

Élément	Nature	Ce que je peux contrôler
Corrections d'issues	Travail quotidien, avec un output mesuré en partie par le volume	Maintenir un rythme régulier
Projet A	Un projet officiel, mais le côté utilisateur tarde à confirmer les exigences	Limité — principalement en attente de réponses
Recherche produit	Chercher proactivement des moyens d'améliorer le produit	Quand livrer, comment le présenter, comment le rapporter

Quand on passe d'une chose à l'autre trois fois ou plus dans une seule journée, ce qui est épuisant, ce n'est pas les heures. C'est le context switching constant.

Puis j'ai réalisé : on n'a pas de PM

Je le savais depuis le premier jour, mais je n'avais jamais vraiment réfléchi à ce que ça impliquait.

On a un BA (Business Analyst) qui gère l'analyse des besoins, mais personne ne s'occupe vraiment de questions comme : Où en est-on ? Qui est bloqué ? Faut-il reprioriser ?

Dans mon entreprise précédente, le PM ou le Tech Lead gérait tout ça. Je n'avais qu'à vérifier le backlog, confirmer les priorités, clarifier les exigences produit et me concentrer sur l'écriture de code. Le spec arrivait, je construisais. Si j'étais bloqué, je le disais au PM, et il gérait le reste.

Maintenant ce rôle n'existe plus. Alors qui prend le relais ?

Le Senior.

Senior n'est pas PM, mais il faut de l'Ownership

Au début, je ne comprenais pas. Je suis ingénieur — pourquoi devrais-je courir après les utilisateurs pour des réponses, reporter proactivement des blocker ou aligner les priorités avec mon manager ? C'est pas du travail de PM, ça ?

Mais ça ne veut pas dire qu'un Senior est censé remplacer un PM en prenant en charge le roadmap de l'équipe, la coordination transversale ou le suivi de la progression de tout le monde. Le vrai point est plus simple : tu ne peux pas traiter les blocker dans ton propre travail comme si c'était le problème de quelqu'un d'autre.

Quand j'ai comparé les deux, la différence est devenue plus claire :

	PM	Senior
La progression de qui gérer	Toute l'équipe	Tes propres lignes de travail
Décider quoi construire	Roadmap, priorités	Ne décide pas, mais s'aligne
Poursuivre les stakeholder	Toutes les personnes impliquées	Tes propres blocker
Responsable envers	Les objectifs business	Les fonctionnalités dont tu es responsable

Un Senior n'a pas besoin de gérer d'autres personnes. Tu dois juste garder tes trois ou quatre lignes sans les laisser tomber. Reporter les blocker proactivement au lieu d'attendre en silence. Avoir des opinions sur les fonctionnalités dont tu es responsable au lieu d'attendre simplement les instructions.

Ça s'appelle de l'ownership, pas du PM.

Ce n'est pas que mon ancien job était trop facile

Pendant un moment, je me suis demandé si mon ancienne entreprise avait simplement des attentes plus basses pour les Seniors. Mais plus j'y réfléchissais, plus je réalisais que ce n'était pas le problème. Les environnements étaient juste différents.

Mon ancienne entreprise avait un PM qui me protégeait du travail de coordination, et la ligne de produit était plus simple. Là-bas, « Senior » se définissait plus en termes techniques : si tu pouvais résoudre des problèmes difficiles, c'était suffisant. Dans mon environnement actuel, une partie du travail consiste aussi à faire avancer le produit, parce que personne d'autre ne va le faire à ta place.

Dans une équipe lean, c'est normal. Ce n'est pas déraisonnable. Je n'y suis juste pas encore habitué.

Ce que j'ai concrètement fait

Une fois que j'ai compris ça, j'ai fait quelques changements :

Prioriser et s'aligner avec le manager. J'ai listé tout par priorité et demandé : « Cet ordre te convient ? » C'est juste un message, mais ça change la posture : de l'attente passive d'instructions à la gestion active de mon propre travail.

Quand tu es bloqué, change de ligne, mais laisse une trace. Si l'utilisateur du Projet A ne répond pas, je fais un ping une fois par semaine et je laisse une trace écrite. Mon manager sait que le blocker n'est pas de mon côté, et je peux utiliser le temps libéré pour pousser la recherche produit.

Ne fais pas trop de context switching. Utilise les priorités pour décider sur quoi travailler aujourd'hui au lieu de toucher à tout un peu. Note les lignes bloquées, mets-les de côté et reviens quand elles se débloquent.

Réflexion finale

Tout ça a l'air basique, mais pour un ingénieur habitué à ce qu'un PM gère la coordination, ça prend du temps de s'adapter. Sous pression, on peut avoir l'impression de faire du travail qui n'est pas le sien. Mais au moins dans une équipe sans PM, ça fait partie de ce que signifie être Senior.

En passant, j'ai d'abord trié les réflexions derrière cet article à travers des conversations avec l'AI, puis je les ai suivies via un système personnel que j'ai construit pour le suivi quotidien et le feedback — je l'appelle Pasiv. Le Vibe coding, ce n'est pas juste utiliser l'AI pour construire des projets. Ça inclut aussi l'utiliser pour démêler où on en est actuellement.