Et si une Product Manager pouvait, seule, transformer une idée en prototype visible, crédible et testable ?
Depuis quelque temps, l’IA s’invite dans tous les métiers, et particulièrement dans les nôtres, dans le digital.
Elle promet d’accélérer la conception, la documentation, le prototypage, le développement ou encore les tests, pour nous permettre de nous concentrer sur des sujets à plus forte valeur.
Pour une Product Manager ou Product Owner sans background technique, comme moi, et qui intervient régulièrement en avant-vente sur des projets clients, cela soulève une question très concrète : jusqu’où puis-je aller seule, avec l’aide de l’IA, pour rendre une idée visible et testable ?
C’est ce que j’ai voulu expérimenter.
En une douzaine d’heures, réparties sur quatre demi-journées, visionnage de tutoriels et prise en main des outils inclus, j’ai construit un prototype autour d’un assistant bien-être conversationnel.
Le sujet de l’application n’était pas le point central. Il servait surtout de terrain de jeu : un cas suffisamment concret pour imaginer des parcours, des écrans, des données et des interactions. Bref, un cas simple, qui me parlait, pour me concentrer sur la méthode.
Le vrai sujet, c’était ma capacité à adopter une posture plus “builder” : passer de l’intention produit à une première matérialisation concrète, sans compétence technique de départ.
Spoiler : oui, j’ai réussi à produire un prototype crédible.
Mais non, je n’ai pas construit un produit, ni même un MVP. D’ailleurs, ce n’était pas l’objectif.
Pourquoi tester une posture de Product Builder ?
Depuis plusieurs mois, un signal devient difficile à ignorer : les métiers Produit changent.
Le Product Manager n’est plus seulement attendu sur sa capacité à comprendre un besoin, rédiger une roadmap, prioriser un backlog ou coordonner les équipes.
Il est de plus en plus attendu sur sa capacité à matérialiser rapidement une idée, à rendre une vision concrète, à tester une hypothèse sans attendre un cycle complet de design et de développement.
C’est ce que plusieurs acteurs appellent désormais le mouvement des Product Builders : des profils qui pensent comme des PM, mais qui savent aussi construire, prototyper, tester et itérer grâce aux outils d’IA.
Converteo résume cette évolution en parlant d’un profil qui “pense comme un Product Manager et agit comme un builder”, avec un rôle clé dans la transformation IA des organisations.
Le média Le Ticket, dans sa synthèse de la Product Builder Night, met en lumière le même constat : chez Ornikar, Converteo ou Alan, les équipes Produit utilisent l’IA pour gagner en autonomie, prototyper plus vite et augmenter d’autres fonctions de l’entreprise.
Chez Proxym, ce sujet résonne particulièrement.
Parce que notre métier consiste à accompagner nos clients dans la conception et la réalisation de produits digitaux utiles, fiables, maintenables. Si l’IA permet de rendre les idées plus tangibles plus tôt, alors elle peut devenir un vrai levier : en discovery, en cadrage, en avant-vente, en atelier, ou dans les premières phases de validation.
Mais pour moi, toute la question était là : comprendre jusqu’où je pouvais réellement aller seule avec l’IA. Et surtout, à quel moment la magie s’arrêtait.
Ce que j’ai fait concrètement
Je ne cherchais pas à comparer des outils entre eux, ni à produire un MVP. Mais j’avais quand même envie de pousser l’expérimentation un peu plus loin qu’une simple maquette intéractive.
J’ai avancé avec Google Stitch, Visual Studio Code, Codex et Specify / Spec Kit, sans chercher à tout maîtriser dès le départ. L’idée était plutôt de les utiliser comme des partenaires d’itération : proposer, observer, challenger, corriger, recommencer.
En quelques sessions, j’ai obtenu une première direction visuelle, des écrans mobiles, des parcours, des composants, une structure de projet et une documentation de départ.
Et honnêtement, à ce moment-là, j’ai été bluffée.
Il y a un vrai effet waouh quand on voit une idée prendre forme aussi vite. On part d’une intention, on formule quelques prompts, on ajuste, et très rapidement on se retrouve avec quelque chose qui ressemble à une application. Ce n’est pas parfait, mais c’est visible, manipulable, presque crédible.
Pendant un moment, j’ai vraiment eu l’impression que “ça y est, c’était possible”.
Que l’IA allait m’accompagner partout, même lorsque je ne savais pas exactement quelle devait être l’étape suivante. C’était fluide, guidé, presque confortable. Et, soyons honnêtes, un peu grisant.
Puis assez vite, le réel est revenu dans la boucle.
Parce qu’un écran qui donne envie, une structure de projet qui semble cohérente ou une documentation bien formulée ne suffisent pas à faire un produit. C’est là que l’expérience est devenue intéressante : non pas parce que tout fonctionnait parfaitement, mais parce qu’elle m’a obligée à comprendre ce que je pouvais réellement piloter… et ce que je ne pouvais pas garantir seule.
Une posture plus qu’un résultat
Je n’ai pas avancé de manière linéaire. J’ai beaucoup tâtonné. J’ai reformulé, relancé, corrigé, demandé des alternatives, puis parfois repris la main parce que la proposition ne correspondait pas à mon intention.
Et parfois, j’ai tout simplement recommencé depuis le départ, parce que j’avais mal cadré.
L’IA donne vite une réponse. Mais ce n’est pas parce qu’elle répond vite qu’elle répond juste.
Mon rôle a donc été de garder le cap produit : questionner ce qui était proposé, challenger les choix, demander de simplifier, revenir à l’usage, préciser les contraintes, accepter parfois de repartir en arrière.
J’ai appris à avancer en avançant. Et cela demande paradoxalement beaucoup de rigueur. Plus l’outil va vite, plus il faut être clair sur ce que l’on cherche à obtenir. On en revient finalement à un sujet qui me tient à cœur : la qualité de la conception en amont. Mais c’est un autre sujet.
Les limites rencontrées
L’expérience a confirmé une limite importante : faire un produit, ce n’est pas simple.
L’IA est très efficace pour donner forme à une idée, générer des écrans, proposer du code, structurer une documentation ou débloquer certains sujets. Mais dès que l’on se rapproche de la vraie vie d’un produit — déploiement, base de données, sécurité, performance, maintenabilité, architecture — les choses changent.
À ce stade, mon manque de bagage technique est redevenu très visible. Et je ne pouvais plus le camoufler !
Je pouvais comprendre certaines propositions, les orienter, les questionner. Mais je ne pouvais pas garantir seule que les choix étaient robustes, cohérents ou pérennes.
C’est là que je suis redescendue d’un cran.
Pas dans le sens “ça ne marche pas”, mais plutôt dans le sens : “OK, c’est puissant, mais il faut savoir ce qu’on est en train de faire.”
Le binôme PM/PO et tech reste donc essentiel.
L’IA ne supprime pas le besoin d’expertise. Elle rend peut-être même cette expertise encore plus importante, parce qu’elle permet de produire vite beaucoup de choses qui doivent ensuite être relues, cadrées et sécurisées.
Ce que cela change pour les PM (comme moi)
Pour les PM et PO, notamment sans background technique, l’IA ouvre une zone intéressante entre la spécification et le développement.
Elle ne transforme pas un PM en développeur.
Elle ne remplace pas un designer.
Elle ne garantit pas qu’une idée est pertinente.
Elle ne valide pas la faisabilité technique d’un produit.
En revanche, elle peut aider à passer plus vite de l’idée à une première forme concrète.
Cela peut changer plusieurs moments du travail produit : en discovery, pour tester rapidement une piste ; en atelier, pour alimenter la discussion avec des supports plus tangibles ; en cadrage, pour mieux exprimer une intention, un parcours ou une logique fonctionnelle ; en avant-vente, pour aider un client à se projeter plus rapidement.
Cela peut aussi enrichir la collaboration avec les équipes techniques. Un PM ou un PO peut arriver avec une matière plus structurée, plus visuelle, parfois plus précise qu’une simple expression de besoin.
Mais cette évolution demande une vraie montée en compétence.
Un PM augmenté par l’IA doit apprendre à mieux formuler, mieux contraindre, mieux challenger et mieux documenter. Il doit comprendre suffisamment pour dialoguer avec la tech, sans prétendre remplacer l’expertise technique.
La valeur ne se situe pas dans le fait de “faire à la place de”.
Elle se situe dans le fait de mieux préparer, mieux clarifier et mieux accélérer les premiers apprentissages.
Conclusion : un prototype, pas un produit
Cette expérimentation m’a permis de valider une conviction : l’IA peut réellement augmenter la capacité d’un PM ou PO non tech à matérialiser une idée.
Et oui, il y a un vrai effet waouh.
Oui, c’est grisant.
Oui, on peut avoir l’impression, pendant quelques heures, que la magie opère.
Mais elle m’a aussi rappelé une limite essentielle : construire un prototype ne veut pas dire construire un produit.
Le Product Builder n’est pas un PM qui remplace les développeurs. C’est un profil qui sait utiliser l’IA pour réduire la distance entre une idée et sa première forme tangible, tout en gardant suffisamment de recul pour savoir quand passer le relais, quand challenger et quand sécuriser avec les bonnes expertises.
Pour moi, c’est là que se trouve la vraie opportunité : non pas dans le fantasme du “tout construire seule”, mais dans une nouvelle manière de collaborer, plus rapide, plus concrète, plus augmentée… et toujours avec l’humain dans la boucle.
