Du vibe coding avec de la rigueur produit

Le développement assisté par IA a rendu la transformation d'une idée en logiciel fonctionnel considérablement plus rapide. Mais la vitesse crée un nouveau problème : un prototype peut être construit en quelques heures pendant que la réflexion qui le sous-tend (problème client, exigences, règles métier, validation, décisions techniques) reste éparpillée entre les prompts, les conversations, les documents et la mémoire de quelqu'un. Cela crée un écart dangereux entre « j'ai construit quelque chose » et « nous avons un produit ». Process OS était mon exploration d'une question simple : à quoi ressemblerait le processus de développement produit si l'IA aidait à maintenir la structure autour du produit, pas seulement à générer le code ?

Le développement produit traditionnel crée des artefacts de façon délibérée : recherche, exigences, briefs, critères d'acceptation, décisions d'architecture. Le développement par IA inverse souvent ce processus. Un créateur décrit une idée, l'IA génère une interface, le créateur réagit, un autre prompt change le workflow, un autre change le modèle de données. Après quelques itérations, un produit étonnamment sophistiqué existe, mais la documentation expliquant pourquoi il fonctionne ainsi fait souvent défaut.

• Les décisions produit finissent enterrées dans l'historique des prompts.
• Les exigences évoluent sans source de vérité claire.
• La validation se fait de façon informelle plutôt que systématique.
• Les équipes d'ingénierie héritent de prototypes sans contexte suffisant.
• Le code généré par IA peut avancer plus vite que la compréhension organisationnelle.
• Les équipes peinent à distinguer un comportement expérimental d'une exigence produit intentionnelle.

Chef de produit, designer produit et créateur. J'ai conçu le cadre, construit le produit fonctionnel avec Lovable, Claude Code, Codex et Supabase, et créé chaque artefact que le système prescrit.

1. 1.

   Problème de vibe coding et produit en direct

   Le point de départ capture le problème à résoudre en même temps que l'application fonctionnelle. Cela établit une distinction importante : le prototype démontre une solution possible, mais la définition du problème reste l'ancrage.

2. 2.

   Brief de validation

   Un examen structuré des hypothèses derrière le produit : client cible, points de douleur, proposition de valeur, hypothèses, risques, preuves, et questions encore à valider. L'objectif est d'éviter de confondre la vitesse du prototype avec une validation produit-marché.

3. 3.

   PRD vivant

   Plutôt qu'un document d'exigences statique écrit avant le début du développement, le PRD évolue avec le logiciel. Il reste la source de vérité durable pour les objectifs produit, les problèmes utilisateurs, les workflows, les exigences fonctionnelles, les règles métier, les cas limites, les critères de succès et les pistes futures, ce qui permet d'expérimenter rapidement sans abandonner la rigueur produit.

4. 4.

   Bibliothèque de prompts et logique

   Les prompts font de plus en plus partie de l'environnement de développement, donc Process OS les traite comme tels. Les prompts importants, la logique système, les décisions d'implémentation et les règles comportementales sont capturés pour que les futurs créateurs comprennent comment le produit a été construit et puissent le continuer sans reconstituer son histoire.

5. 5.

   Une documentation qui émerge du travail

   Mon principe directeur : la documentation devrait émerger du travail plutôt que devenir un travail supplémentaire. Chaque artefact informe le suivant : définir le problème, tester les hypothèses, construire le produit, capturer ce qui a changé, préparer le transfert. Le prototype lui-même est devenu partie du processus de recherche, Lovable, Claude Code, Codex et Supabase me permettant de passer rapidement entre design d'interface, logique produit, implémentation et itération tout en affinant continuellement la définition du produit.

6. 6.

   Du prototype au transfert à l'ingénierie

   La dernière étape répondait à une question de plus en plus importante : de quoi un autre ingénieur aurait-il besoin pour reprendre ce produit avec confiance dès demain ? Le transfert documentait l'architecture du produit, les workflows majeurs, la logique applicative, les considérations liées aux données, les dépendances, les limitations connues, les hypothèses d'implémentation et les opportunités futures. L'objectif n'était pas simplement de faire fonctionner l'application ; c'était de rendre le produit transférable.

• Le goulot d'étranglement se déplace de la construction du logiciel au maintien de la clarté. L'IA peut de plus en plus produire des interfaces, des workflows, du code et de la documentation. Mais les équipes doivent toujours répondre : pour qui est-ce, quel problème résolvons-nous, quelles hypothèses sont réellement validées, pourquoi le produit se comporte-t-il ainsi, et de quoi une autre équipe aurait-elle besoin pour continuer le travail ?
• Une réflexion produit solide compte davantage, pas moins. L'IA réduit considérablement le coût de l'expérimentation. Cela fait du jugement le facteur différenciant.
• Une documentation vivante vaut mieux qu'une documentation statique. Un PRD écrit des mois avant l'implémentation devient obsolète. Les exigences devraient évoluer avec le produit comme une représentation continuellement mise à jour de l'intention actuelle.
• Décisions humaines, accélération par l'IA. L'IA peut synthétiser l'information, générer des spécifications et accélérer l'implémentation, mais le jugement produit reste humain. Le système a été conçu pour rendre les décisions produit plus visibles, pas pour les cacher derrière l'automatisation.
• Concevez pour le transfert. Un prototype réussi ne devrait pas dépendre indéfiniment de la personne qui l'a initialement fait naître par un prompt. Le transfert est un résultat produit de premier plan, pas une réflexion après coup.