Le code était la partie facile pour sortir Prova

Prova a commencé à me sembler réel au moment où le produit a cessé de me laisser me raconter des histoires.

Une homepage peut rester aspirational très longtemps.

Un produit live, non.

Dès que des gens peuvent s'inscrire, confirmer leur email, atterrir au mauvais endroit, tomber sur un billing state, envoyer du travail et s'attendre à ce que le système se souvienne de ce qui s'est passé, le bottleneck change.

Le produit commence à faire de vraies promesses. Et le travail invisible devient soudain très visible.

Si vous avez lu les trois posts que j'ai publiés en mars et au début d'avril sur mon passage de Claude Max à Codex, cette expérience est toujours en cours. J'ai déjà promis un vrai follow-up pour le May 2, 2026, et j'ai l'intention de tenir cette promesse. Ce post n'est pas celui-là.

Mais Prova m'a forcé à voir plus tôt que prévu quelque chose de plus utile :

Dès qu'une chose cesse d'être une idée nommée et commence à devenir un vrai produit, le bottleneck change.

En tout cas, c'est comme ça que je l'ai ressenti sur ce build.

La partie difficile n'était pas d'obtenir d'un LLM qu'il génère du code.

La partie difficile, dans cette poussée du moins, c'était tout ce qu'il y avait autour du code.

Si vous êtes en train de construire avec l'AI en ce moment, surtout quelque chose qui implique de vrais utilisateurs, de vrais paiements ou un vrai product state, je pense que c'est probablement la partie dont personne ne vous parle assez.

La leçon la plus utile, c'est plutôt ce qui commence à compter quand un produit cesse d'être juste une demo.

Le nom, c'était la partie facile

Je dois l'admettre : nommer Prova a été l'une des décisions les plus faciles de tout le processus.

Le nom a tout de suite collé, parce qu'il collait vraiment au produit.

Prova veut dire quelque chose comme preuve ou test. Et c'est, au fond, le job du produit. Il n'est pas là pour flatter les gens et leur donner l'impression qu'ils sont déjà builders. Il est là pour les obliger à prouver le travail. C'est clair, utile, searchable. Bref, c'était la partie facile.

La partie plus dure a commencé juste après. Parce qu'au moment où Prova n'était plus seulement un nom et une landing page, il s'est mis à exiger toutes les choses peu glamour qu'exigent les vrais produits :

assessment logic
onboarding state
authored progression
review visibility
billing flows
auth hardening
content publishing
release gates

Ça a changé ma façon de penser aux AI tools, et aussi au product building.

Ce que Prova devait vraiment devenir

Prova est maintenant un programme structuré pour AI builders, pensé pour des marketers et des professionnels de la publicité qui veulent passer de "j'utilise des AI tools" à "je construis de vrais workflows, pilots et operating systems". Dans la pratique, cela voulait dire assessment et onboarding, un produit sprint-first plutôt que chat-first, une progression guidée par la review, un product state durable, et une couche mentor qui ressemble davantage à des office hours autour du sprint en cours qu'à une AI chat box générique.

Pour être clair, je ne suis pas en train de dire que Prova est "terminé". J'aimerais bien pouvoir dire ça et passer à autre chose, mais ce serait un peu trop pratique, et probablement faux. Le bon cadrage aujourd'hui, c'est soft launch : le core production system est live et il fonctionne, mais il reste encore du travail volontaire de launch readiness, notamment du cleanup sur le return path du billing portal et une couverture plus complète de l'automatisation MFA. Je pense même que ça rend la leçon plus utile, pas moins. C'est à ça que ressemble la construction d'un produit dans la vraie vie. Pas terminé. Pas fake. Juste assez réel pour que la prochaine erreur ait un coût.

Le travail que je ne pouvais pas simplement générer

La version la plus facile d'un AI product, c'est la version demo.

On peut très vite lui donner l'air d'être vivant :

une homepage
une chat box
quelques screenshots bien lisses
une phrase produit convaincante

Ça sert pour un teaser de lancement.

Ça ne sert pas vraiment à comprendre où se trouve le vrai travail.

Pour moi, ce vrai travail a commencé à apparaître à six endroits.

1. Le système de sprints devait arrêter de faire semblant

Je ne voulais pas que Prova devienne un produit qui a l'air structuré sur la landing page et qui devient générique dès qu'un utilisateur entre dedans.

Les fixed authored sprints ont été utiles jusqu'au moment où ils ne l'étaient plus.

Le vrai problème est apparu lorsqu'un learner validait un sprint, mais que son vrai gap suivant n'était pas le prochain sprint authored du catalogue.

La réponse paresseuse aurait été :

"Laissons simplement le modèle inventer le sprint suivant : title, rubric, review criteria, tout."

Je ne faisais pas confiance à ça.

Le système a donc dû devenir plus strict.

Aujourd'hui, le reviewer peut toujours recommander le canonical next sprint quand le chemin authored est le bon. Il peut assigner un adaptive detour, c'est-à-dire un sprint temporaire qui aide le learner à corriger une foundation gap avant de revenir sur le chemin principal. Et quand le prochain vrai gap se trouve hors du catalogue authored, il peut demander un composed sprint.

Dit dans un blog post, ça paraît petit.

Dans un produit, ce n'est pas petit du tout.

Parce qu'un composed sprint n'est pas juste du "texte dynamique".

Il faut créer un sprint placeholder, persister l'assignation, conserver le return path vers la roadmap canonique, remplir le sprint packet, puis laisser le reste du système traiter ce sprint comme un vrai product state.

La contrainte qui a rendu ça digne de confiance était assez simple :

le modèle n'a pas le droit d'inventer le standard.

Le composed sprint ne remplit que le packet : title, summary, context, assignment, example.

Le submission schema et la review rubric continuent de venir d'un authored template sprint.

C'était l'une des plus grosses leçons de tout ce build.

Si vous voulez qu'une chose dynamique reste fiable, gardez le contrat fixe et laissez le modèle opérer à l'intérieur.

C'est aussi un endroit où Codex m'a beaucoup aidé. Pas de façon flashy, du genre "regardez ce qu'il a généré". D'une façon bien plus utile : migrations, router logic, placeholder lifecycle, request state, integration tests, tout ce travail de contrats un peu ennuyeux qui rend un produit dynamique moins fake.

Et je dois aussi admettre que la version paresseuse m'a attiré un instant. Laisser le modèle être clever. Laisser le système paraître magique. Nettoyer plus tard. L'idée sonne très bien jusqu'au moment où on s'imagine devoir expliquer une mauvaise assignation de sprint à un utilisateur qui paie.

2. Retrieval devait devenir curriculaire, pas seulement semantic

Dès que j'ai laissé le système composer des sprints, la qualité de retrieval a cessé d'être un détail de backend.

Elle est devenue une question de qualité du curriculum.

Si le produit devait composer un sprint sur le tooling, la measurement ou la competitive intelligence, il ne pouvait pas juste tirer des chunks "à peu près liés" depuis la knowledge base et espérer que le packet paraisse coherent.

La knowledge base elle-même devait devenir plus intelligente.

Nous l'avons reconstruite à partir du vrai corpus : blog posts, course modules, transcripts, companions, templates et ressources plus approfondies.

Puis nous avons adapté le chunking selon la nature de chaque source.

Les blog posts narratifs pouvaient rester plus larges.

Les instructional modules avaient besoin de chunks guidés par les headings.

Les templates et reference assets avaient besoin d'un chunking plus structuré pour conserver tables, checklists, slide references et quick-reference sections, au lieu d'aplatir tout ça en paragraphes génériques.

Ensuite, le tagging est devenu crucial.

Pas seulement "de quoi parle ce morceau ?" mais aussi :

quel type de chunk c'est
quels topic tags lui correspondent
pour quelle audience il convient
à quel difficulty level il appartient

Ça a transformé retrieval. On n'était plus dans "nearest vector wins", mais dans quelque chose de plus proche d'un curricular matching.

Le produit pouvait demander quelque chose comme :

"Donne-moi du material grounded pour ce topic, pour cette audience, autour de ce niveau."

C'est un système beaucoup plus sérieux que de simplement coller du RAG sur une demo.

3. Les evals devaient tester la pipeline, pas seulement le modèle

C'est peut-être la leçon la plus importante de toutes.

Je ne voulais pas déclarer victoire juste parce qu'un composed sprint avait l'air correct dans l'UI.

Le système d'evals a donc dû grandir avec le produit.

Au début, il y avait le sprint review eval harness.

Ensuite, composition a ajouté un retrieval gate, essentiellement un pass/fail check pour vérifier si le tagged retrieval améliorait vraiment le grounded material par rapport à la baseline non taggée.

Puis composition a ajouté un vrai harness end-to-end :

composer le sprint packet
générer des synthetic submissions compatibles avec le schema
faire tourner le vrai reviewer sur ces submissions
juger les résultats selon grounding, audience differentiation, difficulty gradient, curriculum coherence, review quality et comparaison avec authored work

Ça, c'était la vraie boucle d'apprentissage.

En français simple, l'objectif était d'empêcher la "personalized progression" de basculer vers une fake personalization. Si le système allait dire "ce prochain sprint est vraiment pour toi", il lui fallait plus qu'un packet qui avait l'air correct. Il lui fallait des preuves que ce sprint était grounded, adapté au niveau, et toujours reviewable selon les mêmes standards que le curriculum authored.

Pas "est-ce que le modèle renvoie du JSON ?"

Mais plutôt :

est-ce que le packet restait grounded
est-ce que le track framing changeait vraiment le work product
est-ce que level 2 et level 5 se distinguaient réellement
est-ce que le reviewer prenait encore la bonne décision pass/revise
est-ce que le composed sprint avait toujours l'air d'appartenir au curriculum, au lieu de flotter à côté

Cette boucle a révélé de vrais problèmes.

Des revise submissions faibles qui restaient encore trop fortes.

Des framings d'audience qui s'effondraient d'un track à l'autre.

Des packets sur la measurement qui sonnaient bien mais qui ne répondaient pas vraiment à des questions de confiance différentes selon les learners.

Un des moments les plus humbles pour moi a été de réaliser à quel point quelque chose pouvait avoir l'air "plutôt bon" dans l'UI et pourtant s'effondrer dès qu'on lui posait une question plus stricte. Un packet pouvait bien se lire et rester trop générique. Un revise case pouvait sembler plausible et être quand même trop facile. C'était plutôt utile pour mon ego, je pense.

Et c'est pour ça que cette partie a autant compté.

Le système ne s'est pas amélioré parce que j'avais trouvé un bon prompt.

Il s'est amélioré parce que le produit pouvait échouer devant moi, dans une eval harness, avant d'échouer devant les utilisateurs.

Une grande partie de l'apprentissage réel a eu lieu dans une boucle très serrée entre le 8 et le 10 avril :

schema groundwork
composed sprint lifecycle
tagged knowledge rebuild
retrieval gate
composition calibration
full eval pass
integration coverage
browser QA sur le flux live

Cette séquence compte.

Ce n'était pas un miracle. C'était une boucle contrôlée.

4. Les endroits où la confiance se joue devaient être réels

Là encore, c'est là que les vrais produits se séparent des demos.

Personne ne se soucie de l'élégance de votre couche AI si :

email confirmation casse
Google sign-in est bancal
l'utilisateur reste bloqué dans une auth loop
les abuse controls manquent
le hardening du compte ressemble à une pensée de dernière minute

Pour Prova, cette couche de crédibilité a fini par inclure :

une email confirmation qui renvoie les gens vers le bon flux produit
Google SSO
une authentification à deux facteurs optionnelle via app (TOTP MFA)
une protection Turnstile sur auth et assessment

C'est exactement le type de travail dont on se vante rarement, parce que ça sonne opérationnel et ennuyeux.

Je pense que c'est une erreur.

C'est dans l'opérationnel et l'ennuyeux que les produits gagnent la confiance, ou la perdent en silence.

5. Billing devait être testable, pas seulement imaginable

Je suis de plus en plus sceptique face aux builders qui parlent de monetization comme si elle était à un screenshot Stripe près d'être réglée.

Billing devient réel très vite.

La question n'est pas seulement :

"Est-ce que quelqu'un peut techniquement payer ?"

La vraie question, c'est aussi :

ce qui se passe pendant le trial state
ce qui se passe quand le webhook state arrive en retard
comment tester de façon sûre sans jouer du théâtre sur sa propre surface de revenu
comment vérifier l'ensemble du flow sans inventer des exceptions one-off qui rendent ensuite le système moins fiable

Prova a maintenant un vrai subscription flow ainsi qu'un internal QA checkout path, justement pour vérifier billing de façon plus sûre. Ça peut paraître mineur. Ce ne l'est pas. Plus le produit devient sérieux, plus il faut de moyens pour tester la logique commerciale sans se mentir sur ce qui a, ou n'a pas, été vérifié.

6. Les operations devaient devenir une partie du produit

L'une des choses qui ont rendu Prova réel à mes yeux, c'est que j'ai dû le traiter comme un système opérationnel à part entière, pas comme une simple feature glissée dans mon site existant.

Separate production system.

Separate Supabase project.

Separate Vercel project.

Separate auth configuration.

Separate billing setup.

Separate release gates.

Cette phrase n'est pas sexy. C'est aussi, probablement, la phrase qui compte le plus.

Parce que les produits ne cassent pas seulement dans la couche UI. Ils cassent là où les systèmes se touchent, là où les hypothèses fuient, là où les environnements dérivent, là où quelqu'un dit "on corrigera ça après le launch", puis où cette version d'après le launch n'arrive jamais vraiment.

Plus je travaillais sur Prova, plus je respectais les phrases opérationnelles ennuyeuses.

Si vous voulez un test de pression rapide pour votre propre AI product, posez-vous ces questions :

quel standard reste fixe quand le modèle devient dynamique
quel retrieval garde l'output grounded
quel eval attrape la fake personalization avant un utilisateur
quelle edge de auth, billing ou state vous embarrasserait demain

Si les réponses restent floues, le produit est probablement encore plus demo que système.

La preuve qui compte vraiment

Je n'ai pas envie de parler de productization seulement en abstrait, parce que sinon tout cela sonne plus philosophique que réel.

La preuve qui compte le plus n'est pas : "combien de migrations ai-je écrites ?"

La vraie question, c'est : qu'est-ce qui fonctionne maintenant pour un vrai utilisateur ?

Dans cette phase de soft launch, le produit peut déjà dire de façon crédible :

email signup et confirmation fonctionnent
Google SSO fonctionne
le TOTP MFA optionnel fonctionne
downloadable resources et signed downloads fonctionnent
sprint submission et AI review fonctionnent en production
le Stripe checkout handoff fonctionne

Ça, c'est la couche de preuve visible pour l'acheteur.

En dessous, il y a aussi de la preuve système dans le repo et dans le rollout :

17 migrations Supabase appliquées dans le bootstrap actuel du schema de production
4,390 knowledge-base rows en production publiées et taggées pour composition retrieval
38 downloadable resources publiées
un tagged retrieval gate qui bat la baseline non taggée
une suite complète de 18-case composition evals qui passe son gate
un internal QA checkout path plus sûr pour vérifier billing

Je ne donne pas ces chiffres pour avoir l'air occupé.

Ce que je n'ai pas encore, c'est une preuve externe large, venant d'un groupe significatif d'utilisateurs qui diraient : "ça a changé mes résultats." Il est trop tôt pour ça, et je n'ai aucune envie de le feindre.

Je les donne parce qu'il est très facile de sous-estimer ce que signifie réellement "transformer une idée en produit" quand on ne parle qu'en langage de launch.

Ce qui compte, ce ne sont pas les chiffres eux-mêmes.

C'est ce qu'ils représentent :

le système de sprints a cessé d'être décoratif
retrieval a cessé d'être flou
evaluation a cessé d'être performative
le product state est devenu assez durable pour qu'on puisse s'y fier

Le travail invisible reste du travail.

Et, la plupart du temps, c'est le travail le plus dur.

Ce que cela a changé dans ma tête

Je pense toujours que les AI tools comptent. Bien sûr qu'elles comptent.

Codex a été utile dans cette phase parce qu'il semblait compétent, soigneux et méthodique. Il m'a aidé à avancer dans le travail d'engineering sans beaucoup de théâtre émotionnel. Claude me semble toujours meilleur quand le travail devient plus affaire de goût, plus créatif.

Mais Prova m'a poussé vers une conclusion plus importante :

Je pense que l'AI peut accélérer l'implementation, mais elle ne supprime pas le besoin de jugement sur les boundaries du produit, le sequencing, la crédibilité et la vérité opérationnelle.

Ce jugement reste le travail.

Une landing page n'est pas un produit.

Un concept avec un nom n'est pas un produit.

Une interface de chat n'est pas un produit.

Un composant généré n'est certainement pas un produit.

Pour moi, ce qui commence à faire sentir qu'une chose est un produit, c'est l'architecture invisible autour de l'expérience visible. Au moment où de vrais utilisateurs peuvent entrer, payer, progresser, se bloquer, récupérer, envoyer du travail et faire confiance au state qu'ils voient, on ne joue plus avec une demo. On fait des promesses.

Et je pense que c'est là que product building devient sérieux.

C'est la leçon d'avril qui me paraît la plus utile

Je vous dois toujours le vrai verdict sur 30 jours avec Codex le May 2, 2026, et j'ai l'intention de le publier ce jour-là.

Ce post sera le bon endroit pour parler de la timeline de coût, de l'histoire des limits, de ce qui m'a manqué chez Claude et de ce qui a changé dans ma façon de travailler au quotidien.

Mais Prova m'a déjà appris quelque chose de plus durable qu'une simple comparaison d'outils :

La partie intéressante de l'AI product building est rarement la demo.

C'est le moment où votre système commence à faire de vraies promesses aux utilisateurs, et où vous réalisez combien de ces promesses vivent en dehors du code généré.

J'ai beaucoup plus de respect pour cette partie maintenant.

Et, honnêtement, je pense que c'est la partie dont bien plus de builders devraient parler.

Questions fréquentes

Qu'est-ce que Prova ?

Prova est un programme structuré pour AI builders, pensé pour des marketers et des professionnels de la publicité qui veulent passer de l'usage d'AI tools à la construction de vrais workflows, pilots et operating systems. En termes de produit, cela veut dire assessment, onboarding, sprint progression, review logic, resources, billing, auth et product state qui fonctionnent ensemble, au lieu d'une seule AI chat box qui fait semblant d'être tout le système.

Qu'est-ce qu'un composed sprint dans Prova ?

Un composed sprint est un sprint packet généré pour un vrai gap chez un learner, quand ce gap se trouve en dehors du catalogue authored actuel. La contrainte importante, c'est que le modèle n'invente pas seul le standard. Le packet est dynamique, mais le submission schema et la review rubric viennent toujours d'un authored template sprint.

Pourquoi AI product building devient-il plus difficile après la demo ?

Parce qu'au moment où de vrais utilisateurs peuvent s'inscrire, payer, se remettre d'erreurs, envoyer du travail et faire confiance au state qu'ils voient, le produit commence à faire des promesses. À ce moment-là, les systèmes invisibles autour de la couche AI, comme auth, la qualité de retrieval, les evals, billing et les operations, comptent davantage que le premier output impressionnant d'une demo.

Si vous êtes en train de construire avec l'AI en ce moment, je serais vraiment curieux de savoir :

quel a été pour vous le premier moment où votre projet vous a semblé inconfortablement réel, le moment où une demo est devenue une promesse ?

C'est tout pour moi.

Cheers, Chandler