Je viens du code.
J'ai été DevOps, même si à l'époque on n'appelait pas forcément ça comme ça. J'ai été développeur. J'ai été architecte logiciel. Puis, progressivement, je me suis éloigné de ces métiers pour basculer vers la gestion d'équipes de dev, le projet, l'agilité, le product management.
Je n'ai pas arrêté totalement de coder du jour au lendemain. Au départ, j'écrivais encore moi-même quelques scripts Python pour automatiser une tâche, trier des fichiers, transformer un format, faire un petit outil. Puis j'ai commencé à déléguer une partie de ce développement à ChatGPT, en mode chat. Ensuite, j'ai basculé progressivement vers Claude Code. Mais dans tous les cas, cela restait de petits bouts de code pour faire des outils, pas du développement produit au sens plein.
Jusqu'ici, c'était très cadré. Un script Python, une fonction. Une tâche précise. Une sorte de délégation propre : au lieu de demander au LLM de trier lui-même des fichiers dans son contexte, on lui faisait écrire un script. Il exécutait une opération, on vérifiait, on avançait.
Mais depuis quelques jours, ce n'est plus ça.
Depuis quatre jours, je me suis remis à développer. Ou plutôt : je fais développer Claude Code. Et cette fois, je ne parle pas d'un script utilitaire. Je parle d'un vrai produit, parti de zéro, avec des écrans, des API internes, des comportements avancés, des modifications de données, des choix d'architecture, des tests, de la documentation générée depuis le code.
Ce texte n'est pas une conclusion sur le vibe coding. Je n'ai pas assez de recul pour ça. Quatre jours, c'est trop court pour fabriquer une doctrine. C'est même peut-être le point le plus important : je suis encore dedans. Je documente une traversée.
La lune de miel
La première chose qui frappe, c'est la vitesse.
En quatre jours, j'ai produit quelque chose qui, à l'époque où je développais, m'aurait probablement demandé un mois. Peut-être deux. Et je ne dis pas ça pour faire joli. Je suis parti de zéro. J'ai fait plus de 180 commits. J'ai construit, cassé, corrigé, réorganisé, testé, ajouté des comportements, présenté le produit, reçu des demandes d'évolution, continué.
C'est grisant.
Il y a un moment où l'on se dit : c'est incroyable. Je peux avoir une idée, la formuler, demander à Claude de l'implémenter, tester, ajuster, recommencer. Je ne suis plus en train d'écrire une spec en imaginant ce que donnera le produit plus tard. Je suis déjà dedans.
Et ça change beaucoup de choses.
Avec une maquette, on peut déjà itérer. On voit un écran, un parcours, une intention. On se dit : finalement, le bouton n'est pas au bon endroit, ce cas d'usage n'est pas clair, il manque une information. Mais avec un produit qui fonctionne, même imparfait, l'itération devient encore plus directe. On utilise vraiment. On voit vraiment. On ressent les frottements.
Dans mon cas, le basculement est arrivé assez naturellement. Au départ, ça ressemblait à une maquette. Puis la maquette a commencé à fonctionner. Puis je l'ai présentée. Puis on m'a demandé des évolutions. Puis on m'a demandé quand on pourrait l'utiliser.
C'est souvent là que le danger commence : quand le jetable devient utile.
La douche froide
La deuxième chose qui frappe, c'est que Claude Code, si on le laisse seul, peut faire absolument n'importe quoi.
Pas n'importe quoi au sens où rien ne marche. C'est presque l'inverse. Souvent, ça marche. L'écran s'affiche. Les données remontent. Le bouton fait quelque chose. La démo passe. Et c'est justement pour ça que c'est dangereux.
Claude a une tendance naturelle à foncer. Il code. Il ajoute. Il grossit. Il commence avec un fichier raisonnable, puis ce fichier gonfle, gonfle, gonfle, jusqu'à devenir un bloc qui fait un peu tout. Quand il faut le modifier, il perd du temps. Quand il faut comprendre l'intention, c'est plus difficile. Quand un bug apparaît, on ne sait plus exactement où regarder.
Un développeur expérimenté pense assez vite à la séparation des responsabilités. Il se demande où placer la logique métier, où isoler le transport, où mettre le rendu, comment nommer les concepts, comment éviter que tout soit couplé à tout. Claude peut le faire, mais il ne le fait pas spontanément avec constance. Il faut le guider.
Même chose sur la volumétrie.
Dans mon projet, certaines API peuvent retourner quelques centaines d'éléments. D'autres peuvent en retourner des dizaines de milliers. Ce n'est pas du tout le même monde. Charger 200 éléments pour les afficher dans une page, ce n'est pas charger 20 000 ou 30 000 éléments, puis espérer que le navigateur, l'utilisateur et le backend vont rester de bonne humeur.
Mais si on ne lui dit rien, Claude peut très bien tout charger, tout passer à la page web, tout filtrer côté front, et considérer que le problème est réglé. En test, avec peu de données, ça peut donner l'impression de marcher. En usage réel, ça explose. Ou pire : ça ne casse pas franchement, ça devient lent, figé, incompréhensible.
Un bug, ce n'est pas toujours une erreur rouge dans la console. Parfois, c'est juste un produit qui ne répond plus parce qu'on a chargé 5 000 éléments de manière silencieuse, sans log, sans pagination, sans stratégie claire. Et là, un PM non technique peut ne pas comprendre ce qui se passe.
Piloter un développeur junior très rapide
La relation avec Claude Code m'a beaucoup fait penser au pilotage d'un développeur junior extrêmement rapide.
Il peut produire énormément. Il peut aussi prendre des libertés absurdes. On lui donne une capture d'écran d'un composant, il ne fait pas exactement ce qui est demandé. Il interprète. Il simplifie. Il part dans une direction. Parfois, il faut lui réexpliquer des choses de base : pourquoi ce fichier ne doit pas tout contenir, pourquoi cette couche ne doit pas connaître cette autre couche, pourquoi on ne charge pas toute la donnée, pourquoi il faut écrire les tests, pourquoi il faut relancer les tests.
Et parfois, il ne comprend pas tout de suite.
Ce n'est pas grave en soi. Des développeurs humains font aussi des erreurs. Des choses développées par des développeurs passent parfois en production et ne tiennent pas la charge. La dette technique n'est pas née avec les PM qui font du vibe coding.
Mais l'IA ajoute une vitesse qui change le problème. Elle permet de produire très vite beaucoup de code moyen. Si le cadre n'est pas bon, la dette arrive vite. Très vite.
De mon côté, mon passé technique m'aide. Je comprends les grandes lignes de l'architecture. Je vois quand un fichier commence à devenir trop gros. Je vois quand les couches se mélangent. Je sens quand quelque chose va poser un problème de volumétrie ou de maintenabilité.
Mais je ne maîtrise pas tout. Il y a des parties du code que je ne serais pas capable d'expliquer immédiatement. Si je prends le temps, je peux les comprendre. Mais je ne peux pas prétendre avoir la même maîtrise que si j'avais écrit chaque ligne moi-même.
Sur ce produit-là, je l'accepte. Sur d'autres produits, je ne l'accepterais pas.
Et cette nuance est essentielle.
Le vrai sujet : compétence multipliée par risque
On pourrait poser la question comme ça : est-ce que tous les PM peuvent désormais développer des logiciels avec l'IA ?
Ma réponse spontanée serait : non.
Ou plutôt : ça dépend.
Mais le « ça dépend » n'est pas une pirouette. Ce n'est pas seulement une question de compétence individuelle. C'est un rapport entre le niveau de compétence et le niveau de risque du produit.
C'est exactement comme pour un développeur junior. Est-ce qu'on ouvre immédiatement à un junior le dépôt le plus complexe, le plus critique, le plus impactant pour le business ? Pas forcément. Est-ce qu'on lui donne accès à tous les dépôts, à toutes les données, à tous les droits ? Non plus.
Pour un PM qui vibe-code, c'est pareil.
Il ne s'agit pas de dire : les PM ont le droit ou n'ont pas le droit. Il s'agit de définir ce qu'ils peuvent faire, dans quel périmètre, avec quelles limites, selon leur niveau et selon le risque.
J'aime bien l'analogie du permis de conduire. On ne conduit pas n'importe quel véhicule sans permis, parce qu'on peut devenir dangereux. Et même avec un permis, on ne conduit pas tout. Peut-être qu'un PM rouillé peut conduire une 125 cm³. Ça ne veut pas dire qu'il doit monter sur une grosse cylindrée et partir sur autoroute sous la pluie.
Le « code de PM », dans ma bouche, ce n'est pas une insulte. Ce n'est pas dire que le code d'un PM est forcément mauvais. C'est dire que c'est du code produit par quelqu'un qui ne maîtrise pas très bien, ou plus très bien, le code. Il faut donc accepter des limitations. Et surtout, il faut accepter de les définir.
Vert, orange, rouge
Je ne crois pas à une grille universelle.
Chaque entreprise devra définir sa politique. Mais le principe me semble assez clair : plus le produit touche à des données sensibles, à de l'écriture, à des workflows critiques, à la sécurité, à la facturation, aux droits, plus les exigences doivent monter.
Un petit outil interne, personnel, à durée de vie courte, avec un impact limité, peut probablement vivre avec peu de formalisme. Si ça casse, ce n'est pas grave. On le jette, on le corrige, on passe à autre chose.
Un outil interne partagé, avec des comportements avancés, des écritures limitées, des dépendances métier, devient déjà autre chose. Là, il faut se poser plus de questions.
Et dès qu'on touche à de la production critique, à des données client sensibles, à des permissions, à des écritures irréversibles, à des workflows qui ont un impact client ou business fort, on change encore de catégorie.
La sécurité, par exemple, me semble non négociable. On peut discuter du niveau de tests nécessaire pour un petit outil jetable. On peut discuter de la review. On peut discuter du niveau de documentation. Mais la sécurité ne devrait pas dépendre de l'humeur du moment.
Heureusement, les développeurs ont déjà beaucoup d'outillage pour ça : intégration continue, scanners, règles, pratiques, compétences, parfois même des prompts ou des skills internes. Le sujet n'est donc pas de tout réinventer pour les PM. C'est de raccorder les PM augmentés à l'outillage déjà existant.
Non, je ne crois pas à la review systématique
On pourrait répondre : il suffit que tout soit relu par des développeurs.
Je suis assez méfiant avec cette réponse.
La review systématique est devenue un réflexe, mais elle mérite d'être discutée. Elle vient notamment du monde open source, pour des raisons multiples : qualité, sécurité, transmission, gouvernance, confiance entre contributeurs. Mais dans une entreprise, pour tous les types de code, dans tous les contextes, je ne suis pas convaincu qu'il faille tout revoir systématiquement.
Si un PM se fabrique un outil personnel, jetable, à faible risque, faut-il vraiment mobiliser un développeur pour relire ? Peut-être pas. Sinon on recrée exactement la dépendance que l'on essayait de réduire.
En revanche, la review peut avoir un rôle au début, pour aider les PM à prendre de bonnes pratiques. Elle peut aussi être nécessaire selon l'enjeu. Encore une fois, ce n'est pas oui ou non. C'est une question de risque.
À un moment, il faut aussi accepter la responsabilité. Si je décide de me fabriquer un outil, il faut accepter de manger ma propre nourriture. Si ça bug, c'est aussi à moi de me débrouiller. Et c'est là que ça peut faire mal, parce que beaucoup de PM ne savent pas forcément résoudre les bugs qu'ils viennent de créer avec l'IA.
Les tests comme levier de contrôle
Dans cette expérience, les tests sont devenus centraux.
Pas seulement parce que « les tests, c'est bien ». Mais parce qu'ils sont l'un des rares moyens de garder le contrôle sur un code qu'on n'a pas entièrement écrit soi-même.
Claude n'écrit pas spontanément les bons tests si on ne lui demande pas. Il peut oublier. Il peut écrire les tests après coup. Il peut écrire des tests qui valident son implémentation plutôt que l'intention métier. Il peut donner l'impression que le produit est sécurisé parce qu'il y a des tests, alors qu'il manque une vraie stratégie de test.
Un PM ne connaît pas forcément le TDD. Il ne connaît pas forcément la différence entre un test unitaire, un test d'intégration, un test end-to-end. Il ne connaît pas forcément la pyramide de tests. Il ne sait pas toujours quand il faut tester un comportement avant de le coder, ni comment exprimer une règle métier sous forme de test.
Et pourtant, dans un projet de vibe coding, c'est peut-être l'un des points les plus importants.
Dans mon projet, il y a plus de 500 tests. C'est beaucoup pour un projet de cette taille. La plupart du temps, ça ne casse pas, justement parce que Claude relance les tests très souvent. Quand ça casse, les tests donnent un point d'appui. Ils permettent de comprendre où le comportement attendu n'est plus respecté.
Je ne dis pas que tout doit être testé avec le même niveau d'exigence. Un petit outil interne très simple, à faible risque, n'a pas forcément besoin d'une stratégie de test complète. Là encore, c'est une question d'ampleur.
Mais dès que le produit devient plus sérieux, les tests ne sont pas un bonus. Ils deviennent une partie du volant.
Les rails accélèrent autant qu'ils protègent
Quand je parle de rails, je ne parle pas seulement de garde-fous qui empêchent les PM de faire des bêtises.
Les rails servent aussi à aller plus vite.
Si on laisse un PM et Claude Code seuls face au code source, l'IA peut très bien ne pas prendre les bonnes API internes. Elle peut utiliser le mauvais point d'entrée. Elle peut reconstruire quelque chose qui existe déjà. Elle peut produire un outil qui marche mal, ou qui ne marche pas du tout, ou qui perd un temps fou à contourner l'architecture existante.
En revanche, si les développeurs fournissent des rails, le PM et l'IA savent où aller.
Ces rails peuvent prendre plusieurs formes : un catalogue des API internes utilisables, une documentation fonctionnelle générée depuis le code, un mapping entre les concepts métier et les points d'entrée techniques, des exemples de requêtes, des composants d'interface réutilisables, des conventions, des accès cadrés, de la CI sécurité, des fichiers Claude, des prompts, des skills.
On peut imaginer, par exemple, un environnement où un PM peut créer des écrans internes, des requêteurs, des listes, des graphiques, ou des scénarios métier, en s'appuyant sur des API documentées et validées. Toute la tuyauterie est construite par les devs. Le PM ne part pas d'une page blanche. Il compose dans un cadre.
C'est déjà ce que font certains outils depuis longtemps avec des langages de requête, des tableaux de bord ou des plateformes internes. L'IA rend simplement cette logique plus puissante.
Le point important est là : les rails ne ralentissent pas seulement. Ils accélèrent, parce qu'ils évitent à l'IA de se tromper de chemin.
Du petit outil interne au product builder
Il y a peut-être un palier supplémentaire.
Jusqu'ici, on pourrait croire que je parle seulement de petits outils internes : un écran de consultation, un export, un tableau de bord, un requêteur, une interface temporaire pour aider le product. Ce cas existe, et il est déjà intéressant. Il peut soulager les développeurs, accélérer le quotidien, permettre à une équipe produit de répondre elle-même à certains besoins.
Mais ce n'est pas forcément le seul horizon.
Si la codebase de l'entreprise est bien cadrée, si les API internes sont documentées, si les concepts métier sont lisibles, si les composants et les conventions sont stables, alors le PM peut peut-être dépasser le simple outil interne. Il peut devenir une sorte de product builder.
Pas un développeur autonome sur n'importe quel sujet. Pas quelqu'un à qui l'on confie sans limite les zones critiques du produit. Mais quelqu'un capable de créer un module, un écran, un parcours ou une variation fonctionnelle en s'appuyant sur la codebase existante.
La différence est importante.
Dans le cas du petit outil interne, le PM construit souvent à côté du produit. Il consomme des API, agrège des informations, produit une interface utile pour lui ou pour son équipe.
Dans le cas du product builder, il construit davantage dans le prolongement du produit. Il utilise les briques existantes, le langage métier du code, les composants de l'entreprise, les rails posés par les développeurs. Il ne part pas d'une page blanche. Il compose avec une matière déjà structurée.
Et c'est précisément là que la qualité de la codebase devient décisive. Une codebase mal cadrée enferme le PM et l'IA dans le bricolage. Une codebase lisible, documentée, orientée métier et outillée peut au contraire ouvrir un espace de contribution plus large.
Le vibe coding ne transforme donc pas automatiquement un PM en product builder. Il ne suffit pas de lui donner Claude Code et un dépôt Git. Il faut un terrain praticable.
Si ce terrain existe, alors le sujet devient beaucoup plus intéressant que « les PM peuvent-ils se faire leurs petits outils ? ». La vraie question devient : jusqu'où une organisation peut-elle permettre à des profils produit de construire directement certaines parties du produit, sans perdre la maîtrise technique, la cohérence et la sécurité ?
Et les specs dans tout ça ?
Cette expérience m'a aussi fait reposer une question presque provocatrice : faut-il encore écrire des specs ?
Je ne dis pas que les specs vont disparaître partout. Pour beaucoup de produits, de contextes, de sujets réglementaires, de décisions structurantes, il faudra toujours écrire, cadrer, discuter, documenter le pourquoi.
Mais pour certains outils internes, je me demande si la spec n'est pas en train de changer de statut.
Dans mon cas, je n'ai pas écrit de spec. Je me suis lancé. J'ai construit. J'ai montré. On m'a dit : il manque ça, il faudrait ça, pour telle et telle raison. J'ai ajouté. J'ai itéré.
Pourquoi faire une maquette si je peux construire directement une première version utilisable ? Pourquoi écrire une spec descriptive si je peux faire émerger le comportement dans le produit, puis générer ensuite la documentation fonctionnelle depuis le code ?
J'avais écrit récemment que la question produit devait partir du code source. Cette expérience va dans le même sens, mais depuis l'autre côté. Si le code devient la vérité du comportement, alors une partie de la documentation peut être régénérée depuis lui. La spec ne disparaît pas forcément, mais elle ne peut plus prétendre être durablement la vérité du produit.
Pour certains périmètres, on pourrait presque dire : on n'écrit plus la spec avant. On construit, on valide, puis on génère le métier depuis ce qui tourne.
Je force un peu le trait, évidemment. Mais pas tant que ça.
Le risque organisationnel
Il y a aussi un risque moins technique, plus organisationnel.
Si tout le monde commence à fabriquer ses petits outils dans son coin, ça peut vite partir dans tous les sens. Des outils internes non maintenus peuvent devenir importants. Des scripts jetables peuvent finir utilisés toutes les semaines. Un écran bricolé pour une équipe peut devenir un passage obligé. Un outil sans gouvernance peut devenir critique sans que personne ne l'ait décidé.
Mais ce risque n'est pas propre au vibe coding. Les entreprises connaissent déjà ça avec les fichiers Excel, les macros, les scripts, les outils no-code, les dashboards construits dans un coin. Le vibe coding ne crée pas le problème. Il l'accélère, parce qu'il rend la production d'outils plus facile.
Là encore, la réponse n'est pas d'interdire. C'est de définir les zones, les droits, les responsabilités, les limites, les rails.
Ce que ça change pour les développeurs
Je ne crois pas que les PM vont remplacer les développeurs.
En revanche, je pense que certains petits outils internes que l'on demandait aux développeurs pourront être produits directement par les équipes produit, support, ops ou métier, à condition d'être bien cadrés. Et ça peut soulager les développeurs.
Combien de fois demande-t-on à une équipe dev de quitter le cœur du produit pour faire un petit outil interne, un export, un écran de consultation, un tableau de bord, une interface temporaire ? Si une partie de ces demandes peut être absorbée ailleurs, ce n'est pas forcément une mauvaise nouvelle.
Mais cela ne fait pas disparaître le rôle des devs. Au contraire, cela peut le déplacer. Ils deviennent aussi ceux qui construisent les rails, les plateformes, les API propres, les conventions, les environnements sûrs dans lesquels d'autres peuvent produire sans tout casser.
Ce n'est pas moins technique. C'est peut-être même plus architectural.
La fatigue
Je ne veux pas vendre cette expérience comme un moment uniquement euphorique.
C'est fatigant.
Faire plus de 180 commits en quatre jours, même avec une IA, ce n'est pas neutre. On ne tape pas tout le code, mais on pilote, on relit, on teste, on corrige, on décide, on reprend, on surveille, on réexplique. On avance très vite, mais il faut suivre la vitesse.
Le vibe coding donne une sensation de puissance, mais ce n'est pas une puissance gratuite. Le PM devient une sorte de pilote, d'architecte de proximité, de testeur, de reviewer, de donneur d'intention, de garde-fou. Et s'il n'a pas assez de culture technique, il peut se retrouver à piloter quelque chose qu'il ne comprend pas vraiment.
C'est là que l'illusion de compétence est dangereuse.
On a déjà connu ça avec le no-code. Des personnes pensaient ne plus avoir besoin de développeurs, puis découvraient trois jours plus tard qu'un site sans sécurité, sans protection contre les attaques par force brute, sans circuit breaker, pouvait très vite devenir un problème. Ce n'était pas que l'outil était mauvais. C'est qu'il donnait accès à une puissance sans transmettre automatiquement la culture de sécurité et d'architecture qui va avec.
Le vibe coding pose le même genre de question.
Je documente une traversée
Je n'ai pas de conclusion définitive.
Et c'est peut-être la seule conclusion sérieuse possible après quatre jours.
Je suis encore en train de vibe-coder. Je continue à apprendre. Je continue à voir ce qui marche, ce qui casse, ce qui m'échappe, ce que les tests rattrapent, ce que les rails accélèrent, ce que mon ancien bagage technique me permet encore de sentir.
Je ne veux pas me fabriquer une opinion depuis la tribune. Je veux me la construire par la pratique.
Pour l'instant, ce que je vois, c'est une capacité nouvelle, très puissante, mais qui ne supprime pas les questions anciennes du logiciel. Elle les rend parfois plus visibles. Elle les accélère. Elle les déplace.
Le vibe coding permet d'aller très vite. Mais aller vite n'est pas la même chose que savoir où l'on va, ni savoir ce que l'on risque de casser.
Alors je continue.
Je documente une traversée.
Pour en savoir plus
La question produit doit partir du code source En 8 jours, j'ai compris que le métier de Product Manager allait changer du tout au tout L'IA ne devrait pas seulement servir à produire dix fois plus. Elle devrait aussi nous obliger à comprendre dix fois mieux ce que nous produisons Code centric