En avril, j'ai écrit sur ce qui a rendu Prova réel : le moteur de sprints, la facturation, les évaluations, le travail opérationnel ennuyeux qui sépare une démo d'un produit.
Ce post était vrai quand je l'ai publié. L'architecture sprint-first que j'ai décrite — des sprints rédigés, des revues par grille d'évaluation, un routage adaptatif, les parcours Operator et Builder — fonctionnait vraiment. C'était le bon moteur.
Ce que je ne savais pas encore, c'est que le cursus superposé par-dessus était encore faux.
Pas faux d'une manière que tu remarquerais dans une démo. Faux de la manière qui n'apparaît qu'après avoir rédigé chaque grille, tracé chaque parcours utilisateur, et posé la question que personne ne m'avait forcé à poser jusqu'à la mi-mai : qu'est-ce qui rend exactement cela difficile à reproduire pour un chatbot gratuit ?
Entre la mi-mai et la fin juin, le cursus a été reconstruit deux fois. Chaque fois, j'ai remplacé quelque chose dont j'étais auparavant convaincu. Voici de quoi chaque réécriture parlait réellement.
L'architecture à 3 voies (26 mai – 1er juin)
Fin mai, le produit avait un problème. Il avait 33 sprints, et trois publics très différents — des opérateurs qui repensent des workflows, des builders qui essaient de livrer une première tranche utile, et des leaders qui essaient de transformer des équipes — partageant 7 sprints sur 9 et appelant les deux restants une « voie ». C'était un menu, pas une colonne vertébrale.
La largeur n'est pas un fossé.
J'ai donc construit ce qui ressemblait à la réponse rigoureuse : une architecture en couches avec une fondation commune Layer 0, puis trois voies par public (Operator, Builder, Leader) avec leurs propres sprints dédiés, tous sourcés depuis les 16 templates du cours et le corpus publié. 38 unités sur 5 types d'unités. Concept, exercice, sprint, projet, checkpoint — chacun avec sa propre sémantique de complétion.
Sur le papier, ça ressemblait à un vrai cursus.
Ce qui a cassé, ce n'était aucun sprint individuel. C'était l'hypothèse structurelle sous-jacente à tout cela : que plus de voies et plus de sprints rendaient le produit plus défendable.
Ce n'est pas le cas.
Le framework 7 Powers de Hamilton Helmer nomme cela explicitement. La puissance vient des barrières — des avantages structurels que les concurrents ne peuvent pas reproduire simplement en le décidant. Ajouter des sprints à un parcours n'est pas une barrière. C'est de la surface opérationnelle. Un chatbot générique égale la largeur instantanément, sans friction.
Le modèle à 3 voies a ajouté de la couverture. Il n'a pas ajouté de profondeur. J'avais construit la mauvaise chose, et je ne l'ai pas vu jusqu'à ce que l'architecture soit déployée et que chaque sprint soit écrit.
J'avais rédigé 24 nouveaux sprints pour le modèle à 3 voies, sourcés depuis les templates du cours et le corpus publié. L'architecture avait l'air rigoureuse sur le papier. J'en étais fier.
Le système de voies a été mis hors service la même semaine où il a été livré.
La seule règle (2 juin – 22 juin)
La deuxième réécriture n'a pas commencé par des sprints. Elle a commencé par une question stratégique.
Je me suis assis et j'ai demandé : si le seul avantage défendable de Prova est quelque chose qu'un outil d'IA horizontal ne peut structurellement pas adopter, quel serait cet avantage ?
La réponse a atterri sur trois couches qui se renforcent mutuellement :
Profondeur verticale (le coin). Un marketeur qui livre un workflow de campagne documenté par brief, avec une vraie mesure et un seuil de décision, selon un standard de niveau publicitaire. Ce n'est pas quelque chose qu'un chatbot peut produire à partir d'un prompt.
Échafaudage (l'activation). La plupart des marketeurs ne savent pas quoi demander. Le produit doit les rencontrer à « je pense que l'IA pourrait aider avec ça mais je ne sais pas par où commencer » et faire le travail de cadrage, de séquençage et d'établissement de standards.
Travail vérifié, livré selon un standard (la preuve). Chaque sprint se termine par une soumission examinée contre une vraie grille d'évaluation. Pas « est-ce que ça a l'air bien ». Pas « est-ce grammaticalement propre ». Mais : cet artefact tient-il face à ce qu'un opérateur d'agence ou un acheteur média utiliserait réellement ?
Depuis ces trois couches, l'architecture s'est simplifiée de façon spectaculaire.
La structure à 3 voies a été remplacée par une seule grammaire en boucle : check de réalité → brief → plan → exécuter/construire → seuil de décision → capstone.
Même grammaire pour les trois parcours. Des artefacts différents par parcours. L'opérateur exécute un pilote de workflow de campagne. Le builder livre une tranche de produit fonctionnelle. Le leader construit un business case pour les parties prenantes et un blueprint de modèle opérationnel.
La profondeur n'a été ajoutée qu'après le capstone : extensions agence, extensions de profondeur produit, extensions de changement organisationnel. Si un utilisateur voulait plus, il le gagnait en passant d'abord par la colonne vertébrale.
La largeur n'a pas disparu. Elle a été rétrogradée en modules de déviation déclenchés par preuve — des sprints courts et assignés qui n'apparaissent que lorsqu'un reviewer détecte une lacune que la colonne vertébrale rédigée ne peut pas actuellement couvrir. L'audit d'infrastructure de données. Les décisions de stack fournisseur. Le diagnostic de mise de base. Ils existent toujours. Ce n'est juste pas la route que tu prends, sauf si le produit a la preuve que tu en as besoin.
Le commit unique qui a formalisé cela était feat!: replace dual curriculum routing with unified path sequences le 11 juin. Le ! dénote un changement cassant. primary_path (operator, builder, leader) a remplacé learning_track comme seul axe de routage. Il y avait un feature flag — DISABLE_BRIEF_DRIVEN_RESET_PATH — qui a isolé la transition jusqu'à ce que le gate QA soit passé. Sept sprints legacy ont été retirés du séquençage mais conservés visibles comme historique.
Le capstone est devenu structurel, pas une fonctionnalité. C'est le mécanisme de coût de changement. Un outil horizontal peut générer un paquet de sprint correct. Il ne peut pas générer un portefeuille d'artefacts vérifiés, livrés, examinés contre des standards de niveau publicitaire avec un historique de reviewer persistant.
Avant de rédiger un nouveau sprint ou parcours, demande-toi : lequel des 7 Powers cela renforce-t-il, et quelle est sa barrière ? Si la réponse honnête est « ça ajoute de la couverture » sans barrière, c'est de la surface opérationnelle qu'un chatbot couvre déjà — ne le construis pas.
— 5 juin 2026, document de stratégie du cursus Prova
Cette règle a tué l'architecture à 3 voies. Elle a tué des sprints qui étaient bien écrits mais structurellement redondants. Elle a transformé le capstone d'une fonctionnalité que je repoussais en une exigence structurelle. Et c'est la question que j'aurais dû me poser depuis mars.
La différence entre avril et juin
Le produit que j'ai livré en avril avait raison sur le moteur. Le produit sur lequel je me suis arrêté en juin avait raison sur la colonne vertébrale.
Le moteur — sprints rédigés, revues par grille, routage adaptatif, cycle de vie de sprint composé — était nécessaire. Une architecture de cursus sans moteur de sprint fonctionnel n'est qu'un syllabus.
Mais un moteur de sprint sans colonne vertébrale défendable n'est qu'une liste de fonctionnalités que les outils gratuits égalent déjà.
La différence entre les deux produits, ce n'était pas plus de code. C'était une meilleure question. « Quel Power cela renforce-t-il ? » m'a forcé à tuer des choses dont j'étais fier, et à élever des choses que j'avais traitées comme optionnelles.
Je ne prétends pas que l'architecture de juin est terminée. Les produits le sont rarement. Mais si tu construis un produit d'apprentissage en ce moment, la question vaut la peine d'être posée avant d'écrire ton prochain sprint. Parce que la largeur est la chose la plus facile à ajouter, et la première qu'une IA générique va commoditiser.
Contexte supplémentaire : Prova est mon produit de coaching pour les marketeurs et les professionnels de la publicité, avec un parcours Operator pour la refonte de workflows et un parcours Builder pour livrer une première tranche utile. Il est disponible sur prova.chandlernguyen.com. Le framework 7 Powers vient du livre 7 Powers: The Foundations of Business Strategy de Hamilton Helmer — ce post référence le framework mais ne l'enseigne pas ; le livre est la source.
Si tu construis un produit structuré sur une couche d'IA qui évolue vite, je suis sincèrement curieux : quelle est la chose dans ton architecture qu'un outil gratuit ne peut pas reproduire juste en ajoutant des prompts ?
C'est tout de ma part pour le moment.
À bientôt, Chandler