Devenir PM à l'ère de l'IA 02 | Ne pas maîtriser la technique, pourquoi c'est au contraire un avantage

Commençons par regarder ce qu’a fabriqué quelqu’un qui ne sait pas écrire de code.

Marcus Rush dirige une agence immobilière résidentielle ; lui-même n’est pas programmeur. Avec Claude et Zapier, il s’est bricolé un agent IA baptisé Russ : chaque matin, il note les leads à partir de plus de 11 000 contacts, rédige pour chacun de ses agents le plan de relance de la journée, et gère au passage son agenda. Un patron d’agence a sorti tout un système interne qui fait tourner ses opérations quotidiennes, sans écrire une seule ligne de code à la main.

Ce n’est pas un cas isolé. Une statistique de 2026 indique que 63 % des utilisateurs actifs du vibe coding ne sont pas des développeurs. Un designer sans aucun bagage en programmation a lancé son produit tout seul, avec Replit et l’IA, jusqu’à atteindre 20 000 $/mois, soit plus du double de son ancien salaire.

En mettant tout ça côte à côte, on voit une chose contre-intuitive : sur le chemin qui mène d’une idée à quelque chose qui tourne, ceux qui ne maîtrisent pas la technique avancent parfois plus facilement que les ingénieurs.

L’ingénieur doit d’abord se défaire d’une chose

Certains ont observé comment des ingénieurs chevronnés travaillent avec l’IA. Ils ont l’habitude de pinailler sur chaque détail d’implémentation, ils rétorquent « pourquoi ne pas utiliser X », « as-tu pensé à Y », et la réaction par défaut du modèle, c’est « d’accord, alors on l’ajoute ». Cet instinct forgé en vingt ans, celui de répondre de chaque ligne de code, il faut commencer par s’en défaire quand on collabore avec l’IA.

Et c’est très difficile pour eux. Ce qu’il faut lâcher, c’est cette petite obsession du « chaque ligne, il faut que ce soit moi qui l’écrive de mes mains et que je la relise de mes yeux ». Dans cette fameuse expérience de METR, 16 programmeurs chevronnés travaillaient avec l’IA sur des projets qu’ils maintenaient depuis des années ; ils ont en réalité été 19 % plus lents, tout en croyant avoir été 20 % plus rapides. Plus on est expérimenté, plus on a tendance à se braquer contre l’outil.

Celui qui ne maîtrise pas la technique n’a pas ce fardeau. Il n’a rien à se défaire.

« C’est trop dur », celui qui ne connaît pas la technique ne sait pas le dire

Autrefois, une partie du jugement du product manager venait de « à quel point cette fonctionnalité est difficile à réaliser ». Ce savoir a un effet secondaire : plus vous savez précisément combien de choses il faut modifier derrière une idée, combien d’écueils il faut traverser, plus vous risquez de la tuer dans l’œuf avant même de l’avoir formulée. Ceux qui s’y connaissent sont ceux qui s’autocensurent le plus durement.

Celui qui ne maîtrise pas la technique ne se fixe pas cette barrière. Il ne sait pas que c’est dur, alors il commence par dire clairement ce qu’il veut, et il laisse l’IA encaisser cette part de difficulté d’implémentation. C’est exactement ce dont parle doaipm avec le 言出法随 : dis-le clairement, et l’IA te le construit. Marcus ne savait pas « à quel point ça devait être dur » d’écrire une logique de scoring sur 11 000 contacts ; il savait seulement ce qu’il voulait, et il l’a dit.

Ce qui est rare, c’est de savoir énoncer clairement une idée, pas de savoir écrire du code

Si l’agent Russ tourne, ce n’est pas parce que Marcus sait écrire du Python, c’est parce qu’il connaît son métier : selon quels critères noter un lead, quels points faire figurer dans le plan de relance, quels contacts placer en tête. Tout ça, c’est du jugement, pas de la technique.

L’IA n’infère rien à partir des omissions. Si vous ne dites pas clairement, elle vous sort une version par défaut, qui la plupart du temps n’est pas celle que vous vouliez. Celui qui sait expliciter les règles, les limites et les états produit une qualité d’un ordre de grandeur supérieure à celle des autres. Et cette capacité-là n’a rien à voir avec le fait de savoir programmer. Parmi les conseils d’a16z aux product managers, il y en a un : le pur gestionnaire de processus sera éliminé, seuls ceux qui ont un « état d’esprit de bâtisseur » auront du levier. Cet état d’esprit de bâtisseur, c’est la volonté de mettre soi-même les mains dedans pour concrétiser une idée et aller la valider — savoir écrire du code ou non n’en fait pas partie.

L’avantage ne tombe pas du ciel

Ne pas maîtriser la technique ne veut pas dire qu’il n’y a rien à maîtriser. Le Zapier qu’utilise Marcus, le Replit qu’utilise ce designer, cachent chacun un savoir-faire qu’il faut apprivoiser : comment découper un besoin en petites étapes que l’IA peut encaisser d’une bouchée, comment juger si ce qu’elle rend est correct, où il faut s’arrêter pour laisser un humain reprendre la main.

Ce que celui qui ne maîtrise pas la technique oublie le plus facilement, c’est le filet de sécurité. Dans un prototype, ne mettez pas de vraies données clients ; les boutons qu’on ne peut pas annuler une fois pressés — publier, supprimer, payer — laissez-les à un humain. Le Russ de Marcus « rédige » les plans de relance pour les agents, mais il ne les « envoie » à la place de personne — ce clic-là, c’est encore un humain qui le fait.

Une chose à faire dès aujourd’hui : choisissez une petite idée pour laquelle vous vous êtes toujours dit « il faut un ingénieur pour ça », ne commencez pas par vous demander si c’est dur, écrivez point par point ce que vous voulez, et confiez-le à l’IA pour qu’elle en fasse une première version. Voyez d’abord jusqu’où elle peut aller, puis jugez.

Pour aller plus loin

• Zapier, « Vibe coding examples: Real projects from non-developers » (cas Marcus Rush / Rush Home) : https://zapier.com/blog/vibe-coding-examples/
• a16z, « 5 Principles for PMs in the AI Era » (état d’esprit de bâtisseur vs gestionnaire de processus) : https://a16z.com/stay-relevant-in-ai/
• Le premier article de cette série, « Quelles tâches du product manager l’IA a-t-elle reprises, et lesquelles valent au contraire plus cher » : /fr/blog/ai-pm-what-changed/