Le prototype est arrivé avant que le produit soit fini

L'IA a changé qui peut construire un logiciel et la vitesse à laquelle une première version apparaît. Un fondateur peut passer d'une idée à une URL fonctionnelle en une journée avec Cursor, Claude Code, Lovable, Bolt ou un autre builder. C'est un vrai changement. Il rend aussi un problème produit familier plus visible : un logiciel qui marche n'est pas automatiquement un produit fini.

Le travail inachevé traverse plusieurs disciplines. Le message peut rester vague. L'action principale peut disparaître sur mobile. Un formulaire peut marcher à la souris et échouer au clavier. Les moteurs de recherche et les aperçus sociaux peuvent ne recevoir presque aucun contexte utile. Aucun de ces problèmes ne demande une nouvelle fonctionnalité ambitieuse. Ils demandent du jugement, des preuves et une dernière passe disciplinée.

Les outils disponibles traitaient ces écarts séparément. La critique design vivait à un endroit, l'accessibilité à un autre, le SEO ailleurs, et les conseils IA génériques produisaient de longues listes sans ordre. J'ai fondé FixFlags pour faire de cette dernière passe un seul produit. L'entrée serait l'URL live, car c'est ce que le client rencontre. La sortie serait un plan de finition qu'un builder peut appliquer tout de suite.

Définir le Product QA autour de trois questions

J'ai appelé la catégorie Product QA parce que le problème dépassait l'audit visuel et devait rester plus pratique qu'une revue stratégique. Il fallait répondre à trois questions sur le produit devant nous. La page s'explique-t-elle ? Les gens peuvent-ils accomplir l'action importante ? Les bonnes personnes peuvent-elles trouver et partager le produit ?

Ces questions sont devenues Message, Experience et Reach. Message couvre le positionnement, la hiérarchie, la confiance et la clarté de l'étape suivante. Experience couvre l'interaction, le mobile, l'accessibilité et les parcours essentiels. Reach couvre la recherche, les métadonnées, les données structurées et les aperçus qui transportent le produit au-delà de ses pages.

La contrainte comptait autant que la couverture. Chaque contrôle devait appartenir à l'une des trois grilles et produire une preuve depuis le produit live. Sans élément observable, il n'entrait pas dans le rapport. Cela empêchait le Product QA de devenir une note de goût et donnait au système un langage stable pour les landing pages, SaaS, portfolios et sites clients, avec des revues de parcours plus profondes quand la passe rapide ne suffit pas.

Définir la revue

La marque reste compacte tandis que le rapport rend Message, Experience et Reach visibles comme du travail produit.

• Logo FixFlags, F orange et mot-symbole sur fond blanc: Identité FixFlags
• Vue d'ensemble FixFlags avec les Flags ouverts classés: Vue d'ensemble du rapport
• Preuves FixFlags organisées selon Message, Experience et Reach: Preuves par grille

Transformer le rapport en plan de finition

Une note unique aurait été facile à vendre et faible à utiliser. Elle écrase des problèmes différents dans un seul chiffre, récompense les vérifications répétées pour la mauvaise raison, puis laisse le builder se demander par quoi commencer. J'ai donc conçu le rapport autour de Flags classés.

Chaque Flag nomme le problème, le situe dans l'expérience live, montre la preuve, explique pourquoi il compte et porte un prompt de correction. La sévérité et la confiance ordonnent la file, mais le rapport reste concret : corriger ce message, réparer cette interaction, ajouter ce signal de Reach. La vue d'ensemble montre la forme du travail sans prétendre résumer le produit par une note de vanité.

Le prompt n'est pas une demande générique d'amélioration. Il contient le contexte utile, un périmètre serré, le changement attendu et une étape de vérification. Cette structure compte quand un agent peut modifier le code. Un prompt large peut réécrire un système qui fonctionne. Un prompt borné peut effacer un Flag en préservant le reste. Le rapport est ainsi devenu la surface de travail partagée entre le fondateur, les preuves produit et le builder qui effectue le changement.

Des preuves à un correctif borné

Chaque Flag porte le contexte et le prompt nécessaires pour corriger un problème sans réécrire le produit autour.

• Détail d'un Flag FixFlags avec sévérité, preuves et explication: Détail du Flag
• Prompt de correction FixFlags prêt à copier dans un builder IA: Prompt de correction

Mettre le correctif dans le builder

Trouver le problème ne représentait que la moitié du travail. Les builders travaillent déjà dans Cursor, Claude Code, des agents en terminal et des outils visuels. Leur demander de traduire le rapport à la main aurait recréé l'écart que FixFlags devait fermer.

Le premier pont fut le prompt copiable. Il donne à n'importe quel builder le contexte nécessaire pour effectuer un changement borné. Le suivant fut MCP, qui permet à un agent compatible de lire le rapport, d'inspecter les Flags ouverts et de récupérer le contexte exact sans changer de fenêtre. Le CLI apporte le même workflow au terminal.

Cette décision a façonné le produit. FixFlags ne devait pas concurrencer le builder ni devenir un éditeur de plus. Il devait fournir le jugement produit et les preuves qui lui manquaient. La marque suit la même idée : un F orange, un wordmark compact et des surfaces qui ressemblent à une file de travail, pas à une présentation de cabinet.

Fermer la boucle dans le même rapport

Une revue est utile une fois. Une pratique produit a besoin d'une boucle. Quand le builder a traité les premiers Flags, une revue de mise à jour relance l'URL live et enregistre ce qui est résolu, ce qui reste et ce qui a changé. L'avant et l'après restent liés au même rapport, donc les progrès sont visibles sans reprendre le diagnostic de zéro.

Pour les parcours importants, les revues profondes dépassent la passe produit rapide. Elles suivent les chemins clés, capturent ce qui s'est passé et renvoient des preuves de l'expérience, pas seulement de la surface de la page. Les deux types de revue répondent à deux questions de fondateur : qu'est-ce qui paraît inachevé, et où le parcours réel casse-t-il ?

La confidentialité devait faire partie du modèle produit. Les rapports sont privés par défaut, et le partage public est explicite et révocable. Les builders peuvent garder le travail en cours contenu et partager un rapport quand la collaboration le demande.

FixFlags est actuellement en bêta ouverte sur fixflags.com. Le produit est aujourd'hui la boucle que je voulais construire : revoir le produit live, classer les Flags, envoyer un correctif borné dans le builder et revenir aux mêmes preuves pour vérifier ce qui a changé.

La boucle continue dans le builder

Les prompts, MCP et CLI amènent le travail dans l'éditeur. La revue de mise à jour revient au même rapport pour montrer ce qui est résolu.

• Revue de mise à jour FixFlags montrant les Flags résolus et restants: Revue de mise à jour
• Workflow MCP et CLI de FixFlags pour transmettre le contexte du rapport à un agent de code: Workflow MCP et CLI