Comment un PM peut monter en compétences techniques avec l'IA et construire un vrai SaaS

Un product manager sans bagage technique en séance de grooming, c'est une histoire éternelle : silences gênés et hochements de tête à contretemps. Un guide publié sur Habr propose une recette concrète : prendre l'IA comme outil et construire un vrai SaaS de zéro, non pour le lancer en production, mais pour comprendre de l'intérieur comment fonctionne un produit.

Pourquoi un SaaS précisément

Il y a 90 % de chances qu'un product manager travaille, ou travaille un jour, sur des produits SaaS. Authentification, paiement, abonnements, API, tableaux de bord, multilocation : on y trouve presque tout l'éventail des problèmes techniques qu'il faut comprendre pour bien travailler avec une équipe de développement. Ce n'est pas un modèle pédagogique, mais l'architecture vivante d'un vrai produit avec lequel le PM compose chaque jour.

Dès le premier paragraphe, l'auteur pose un filtre strict : si vous ne savez pas installer un VPN ou si vous rechignez à dépenser 20 $ en outils, l'article n'est pas pour vous. Ce n'est pas du snobisme, mais un filtre d'intention. Le guide s'adresse à ceux qui sont prêts à y consacrer du temps et à entrer dans les détails, pas à ceux qui veulent seulement regarder la magie de l'IA de loin.

Le Vibe Coding contrôlé

Le Vibe Coding consiste à programmer avec un assistant IA : on décrit la tâche avec des mots et le modèle génère le code. Le schéma habituel : écrire un prompt, recevoir du code, l'exécuter. Ici, l'approche est différente. Le product manager n'accepte pas le code à l'aveugle : il décortique chaque bloc. L'IA joue le rôle de mentor : elle explique une décision d'architecture, analyse une erreur, propose une alternative. C'est le sens du mot « contrôlé » :

• Il demande « pourquoi ainsi et pas autrement » et obtient une réponse au niveau du concept, pas de la syntaxe
• Il examine chaque dépendance que l'IA ajoute au projet
• Il comprend quelle dette technique naît de chaque raccourci
• Il sent la différence entre « faire vite » et « faire bien »
• Il voit pourquoi une décision d'architecture prise aujourd'hui pèse sur la vitesse de développement dans trois mois

Le but n'est pas d'apprendre à coder comme un junior, mais de comprendre comment est construit ce que l'on met dans le backlog. L'empathie technique commence ici.

Ce que cela change dans le travail du PM

En grooming : quand un développeur dit « il faut réécrire la couche d'accès aux données », le PM comprend pourquoi. Il ne se contente pas de hocher la tête et d'ajouter une tâche sans contexte : il peut discuter sérieusement de la priorité, des délais et du coût réel du report de cette décision.

En planification : « ajouter OAuth2 » cesse de sonner comme « juste un bouton ». Le PM voit l'intégration avec un service externe, la gestion des cas limites (edge cases) et la mise à jour de la documentation. Les estimations des développeurs ne ressemblent plus à des nombres tirés au hasard et deviennent des compromis compréhensibles entre vitesse et qualité.

En postmortem : à la place du silence dans un coin, une vraie participation. Comprendre ce qui s'est cassé exactement, et à quel niveau, donne du sens à l'analyse de l'incident pour les deux parties.

« L'empathie technique, ce n'est pas savoir écrire du code, mais

savoir comprendre pourquoi quelque chose coûte exactement ce prix » — l'essence de l'approche en une phrase.

Ce que cela signifie

L'IA a abaissé la barrière d'entrée de la culture technique au point qu'un PM qui ne code pas n'a plus besoin que d'un vrai projet perso et d'un modèle de langage en guise de mentor. Le Vibe Coding contrôlé passe du statut de tendance survendue à celui d'outil pratique pour ceux qui veulent parler la même langue que l'équipe de développement, sans cursus de programmation de cinq ans et sans syndrome de l'imposteur en revue technique.