Le calendrier de livraison. En semaine 2, les leçons 5.4 et 5.5 correspondent aux étapes construites la même semaine : l'avance de sécurité disparaît. Décale d'un cran, la semaine 2 livre 5.1 à 5.3, la semaine 3 livre 5.4 à 5.6, et ainsi de suite.
Le statut juridique du produit. À l'étape 13, avec un vrai domaine et Stripe en conditions réelles, de vrais inscrits te rendent responsable d'un service de mise en relation : conditions d'utilisation, âge minimum, modération active, données sensibles. Soit c'est un démonstrateur fermé en mode test, soit c'est un vrai produit et le cadre se prépare dès maintenant.
Le module 4 peut être livré dès l'inscription, comme les modules 0 à 3, puisqu'il ne dépend d'aucune étape construite. Ça t'offre une semaine d'avance supplémentaire.
Document de production interne. Objectif : construire l'application fil rouge dans un ordre qui alimente directement le tournage d'IA Blueprint, sans jamais se retrouver à devoir filmer une étape qui n'est pas encore construite.
Trois calendriers avancent en parallèle et ne doivent pas être confondus.
| Calendrier | Rythme | Contrainte |
|---|---|---|
| Construction | En continu | C'est le goulot d'étranglement, tout dépend de lui |
| Tournage | Juste après chaque étape construite | Se filme à chaud, pendant que les décisions sont fraîches |
| Livraison aux élèves | Une semaine après le tournage | L'avance de sécurité, voir ci-dessous |
La règle de l'avance de sécurité. Ne jamais livrer ce qui vient d'être construit la veille. Une semaine complète d'écart entre la construction et la livraison. Si une étape casse et prend trois jours de plus, les élèves ne s'en aperçoivent pas. Sans cette avance, le premier imprévu devient un retard public.
L'ordre de construction n'est pas l'ordre pédagogique. Les modules 0 à 4 enseignent la méthode et sont livrables immédiatement, ils ne dépendent pas de l'application. Les modules 6, 7 et 8 ne sont pas des phases de construction séparées : ils prélèvent des morceaux déjà construits pendant le module 5 et les remettent en perspective. Concrètement, tu construis une seule fois, tu filmes trois fois sous trois angles différents.
Le point qui rend tout cohérent. Les prompts de cette feuille de route sont eux-mêmes la démonstration de ce qu'enseigne le module 4. Chacun suit la même structure : contexte, objectif d'étape, contraintes, hors périmètre, critère de fin. Les élèves ne recevront pas une liste de prompts magiques, ils verront la même grille appliquée quatorze fois de suite. C'est ça qui fait passer la méthode.
Ces choix conditionnent tout le reste. Les trancher maintenant évite de reconstruire au milieu du tournage.
Arrêtés (cohérents avec ton stack existant)
À arrêter avec toi
Sept semaines, à partir de la semaine du 1er septembre. Chaque semaine : on construit, on filme, on livre ce qui a été filmé la semaine précédente.
| Semaine | On construit | On livre |
|---|---|---|
| S1 | Étapes 1 à 3 | Module 4 |
| S2 | Étapes 4 à 6 | Module 5, partie 1 (leçons 5.1 à 5.5) |
| S3 | Étapes 7 à 9 | Module 5, partie 2 (5.6 à 5.10) |
| S4 | Étapes 10 à 12 | Module 5, partie 3 (5.11 à 5.14) |
| S5 | Étapes 13 et 14 | Module 6 |
| S6 | Reprises et mécaniques vivantes | Module 7 |
| S7 | Coûts, sauvegardes, bilan | Module 8 |
Les modules 0 à 3 sont livrés dès l'inscription, ils ne figurent pas dans ce tableau.
Chaque étape suit le même format : ce qu'on construit, ce qui se filme, le prompt de départ, le critère de fin, et le piège pédagogique à ne pas rater au montage.
Leçon 5.1 | Aucune ligne de code
On construit : le document de cadrage. À qui s'adresse Entre Nous, ce qu'il promet, ce qu'il refuse de faire.
On filme : la décision de ce qu'on ne fera pas. C'est la leçon la plus utile du module et la plus rare dans les formations.
Prompt de départ
Contexte : je conçois "Entre Nous", une application de rencontre par tirage quotidien. Cinq profils par jour, pas de défilement infini. Un studio photo IA permet d'améliorer sa photo de profil. Les profils sont vérifiés par la communauté, pas par reconnaissance faciale. Objectif de cette étape : produire un document de cadrage d'une page. Pour qui, quelle promesse, quelles trois règles non négociables du produit. Contraintes : je construis seul, avec toi, en quelques semaines. Le produit doit pouvoir vivre avec un budget mensuel modeste. Hors périmètre pour l'instant : la technique, les outils, le code. Ne me propose aucune solution technique à ce stade. Critère de fin : je dois pouvoir expliquer le produit à quelqu'un en trente secondes, et savoir dire non à trois fonctionnalités qu'on va me réclamer.
Critère de fin : le document tient sur une page et tu peux le lire à voix haute sans hésiter.
Piège à filmer : le moment où tu es tenté d'ajouter la messagerie instantanée, et où tu y renonces. C'est exactement le réflexe qui tue les projets des élèves.
Leçon 5.2 | Aucune ligne de code
On construit : le plan en une page du module 3, appliqué à Entre Nous. La liste des briques, le chemin des données, ce qui vit côté navigateur et ce qui vit côté serveur.
On filme : l'application en direct de l'arbre de décision du module 2. Les élèves ont appris la grille au module 2, ils la voient fonctionner ici sur un cas réel.
Prompt de départ
Contexte : [coller le document de cadrage de l'étape 1] Objectif de cette étape : établir le plan technique en une page. Liste des briques nécessaires, ce que chacune fait, et le chemin complet d'une donnée depuis l'écran jusqu'au stockage et retour. Contraintes : Supabase pour la base, les comptes et le stockage. Netlify pour l'hébergement. Toute clé secrète doit rester côté serveur. Hors périmètre : le code, le schéma de base de données détaillé, le choix du fournisseur d'images IA. Critère de fin : je peux dessiner ce plan de mémoire sur une feuille, et pour chaque brique je sais dire pourquoi elle est là.
Critère de fin : chaque brique de la liste a une justification en une phrase. Une brique sans justification sort du plan.
Piège à filmer : la brique dont tu te rends compte qu'elle est inutile. Retirer vaut mieux qu'ajouter.
Leçon 5.3 | Comptes, profils, base de données
On construit : création de compte, connexion, table des profils, règles d'accès aux données.
On filme : pourquoi les règles d'accès se posent maintenant et pas plus tard. C'est le genre de décision qu'on ne peut pas rattraper une fois que des données réelles existent.
Prompt de départ
Contexte : [plan de l'étape 2] Objectif de cette étape : mettre en place les comptes et le profil utilisateur. Inscription, connexion, déconnexion, et une table profils reliée au compte. Contraintes : Supabase. Les règles d'accès doivent être posées dès la création des tables, pas après. Un utilisateur ne doit jamais pouvoir lire ou modifier le profil d'un autre. Hors périmètre : les photos, le tirage quotidien, le paiement, le design. Une interface minimale suffit à cette étape. Critère de fin : je peux créer deux comptes de test, me connecter avec chacun, et vérifier qu'aucun des deux ne voit les données de l'autre.
Critère de fin : le test des deux comptes passe. Tant qu'il ne passe pas, on n'avance pas.
Piège à filmer : la tentation de désactiver les règles d'accès pour aller plus vite. Montre-la, puis refuse-la.
Leçon 5.4 | Stockage, formats, affichage
On construit : envoi d'une photo, stockage, redimensionnement, affichage dans le profil.
On filme : ce que coûte une photo mal gérée. Un fichier de huit mégaoctets affiché en vignette, c'est la facture et la lenteur assurées.
Prompt de départ
Contexte : [plan de l'étape 2, socle de l'étape 3 en place] Objectif de cette étape : permettre à un utilisateur d'envoyer une photo de profil, la stocker, et l'afficher. Contraintes : Supabase Storage. Limiter la taille acceptée et les formats. Les photos d'un utilisateur ne doivent pas être accessibles publiquement par simple devinette d'URL. Hors périmètre : le studio photo IA, la vérification communautaire, la modération. Critère de fin : j'envoie une photo depuis deux comptes différents, chacune s'affiche au bon endroit, et je vérifie qu'une URL devinée ne donne rien.
Critère de fin : le test de l'URL devinée échoue proprement.
Piège à filmer : la première photo qui casse l'affichage parce qu'elle est en portrait alors que tout est pensé en carré.
Leçon 5.5 | La règle métier centrale
On construit : la règle des cinq cartes par jour, remise à zéro quotidienne, impossibilité de contourner.
On filme : la différence entre une règle métier posée côté serveur et une règle posée côté navigateur. C'est le cœur de la leçon : une contrainte qui vit dans l'interface n'est pas une contrainte.
Prompt de départ
Contexte : [plan de l'étape 2, socle et photos en place] Objectif de cette étape : implémenter le tirage quotidien. Chaque utilisateur reçoit cinq profils par jour, pas un de plus, avec remise à zéro chaque jour. Contraintes : la règle doit être imposée côté serveur. Un utilisateur qui recharge la page, vide son cache ou modifie ce qu'il voit dans son navigateur ne doit jamais obtenir une sixième carte. Hors périmètre : l'animation des cartes, le design, les crédits. Critère de fin : j'essaie activement de tricher depuis le navigateur et je n'y arrive pas.
Critère de fin : la tentative de triche échoue. Filme cette tentative, elle vaut mille explications.
Piège à filmer : le fuseau horaire. "Chaque jour" à quelle heure, et pour qui.
Leçon 5.6 | Cartes, retournement, révélation
On construit : l'écran de tirage, les cartes face cachée, l'animation de retournement et de développement du portrait.
On filme : comment on obtient une interface soignée avec l'IA sans savoir dessiner. C'est le module qui rassure les élèves qui se croient nuls en design.
Prompt de départ
Contexte : [tirage quotidien fonctionnel] Objectif de cette étape : construire l'écran du tirage du jour. Cinq cartes face cachée, retournement au clic, le portrait apparaît comme une photo qui se développe. Contraintes : l'animation doit rester fluide sur mobile. Elle doit se désactiver pour les personnes qui ont demandé à réduire les animations dans leur système. Hors périmètre : le studio IA, le paiement, la vérification. Critère de fin : l'écran est agréable sur un téléphone, et le retournement ne fait pas ramer l'appareil.
Critère de fin : testé sur un vrai téléphone, pas seulement en fenêtre réduite.
Piège à filmer : la première version qui est jolie sur ordinateur et illisible sur mobile.
Leçon 5.7 | Appeler un modèle depuis son produit
On construit : l'amélioration de photo par IA, avec la clé d'API protégée côté serveur.
On filme : où vivent les secrets. C'est la leçon de sécurité la plus concrète de toute la formation, et celle qui distingue un prototype d'un produit.
Prompt de départ
Contexte : [photos et interface en place] Fournisseur d'images retenu : [à compléter après la décision] Objectif de cette étape : permettre à un utilisateur d'améliorer sa photo de profil via un modèle d'IA, et de conserver le résultat. Contraintes : la clé d'API ne doit jamais se trouver dans le navigateur. L'appel passe par une fonction serveur. L'utilisateur doit voir clairement qu'un traitement est en cours et pouvoir comparer avant et après. Hors périmètre : le débit de crédits, le paiement. Critère de fin : j'inspecte le code reçu par le navigateur et je ne trouve aucune trace de la clé.
Critère de fin : l'inspection du navigateur ne révèle rien. Montre cette inspection à l'écran.
Piège à filmer : la première proposition de l'IA qui met la clé côté navigateur parce que c'est plus simple. Elle arrivera. Montre que tu la refuses et pourquoi.
Leçon 5.8 | Compter, débiter, maîtriser les coûts
On construit : le solde de crédits, le débit à chaque génération, le blocage à zéro.
On filme : le raisonnement économique. Chaque génération coûte de l'argent réel, donc le produit doit compter avant de dépenser.
Prompt de départ
Contexte : [studio photo IA fonctionnel] Objectif de cette étape : mettre en place un solde de crédits par utilisateur. Chaque génération d'image débite un crédit. À zéro crédit, la génération est refusée avec un message clair. Contraintes : le débit doit se faire côté serveur, au même endroit que l'appel au modèle, et de façon à ce qu'un appel échoué ne débite pas. Chaque mouvement de crédit doit être tracé. Hors périmètre : l'achat de crédits, qui vient à l'étape suivante. Critère de fin : je descends à zéro crédit et je vérifie qu'aucune génération ne passe. Je provoque une erreur volontaire et je vérifie que le crédit n'est pas perdu.
Critère de fin : les deux tests passent, dont celui de l'erreur volontaire.
Piège à filmer : le cas où l'appel réussit mais le débit échoue. C'est le bug le plus coûteux d'un système de crédits.
Leçon 5.9 | Encaisser vraiment
On construit : l'achat de crédits, le retour de paiement, le crédit du compte.
On filme : pourquoi on ne fait jamais confiance au navigateur pour confirmer un paiement.
Prompt de départ
Contexte : [système de crédits fonctionnel] Objectif de cette étape : permettre l'achat d'un lot de crédits par carte, et créditer le compte une fois le paiement confirmé. Contraintes : Stripe. Le compte ne doit être crédité que sur confirmation reçue côté serveur, jamais sur simple retour de l'utilisateur dans le navigateur. Un même paiement ne doit jamais créditer deux fois. Hors périmètre : les abonnements, les remboursements automatiques, la facturation. Critère de fin : j'achète en mode test, je vérifie le crédit. Je ferme le navigateur juste après le paiement et je vérifie que le compte est quand même crédité.
Critère de fin : le test de la fermeture brutale du navigateur passe.
Piège à filmer : ce test précisément. C'est spectaculaire et ça marque durablement.
Leçon 5.10 | File d'attente, votes, réputation
On construit : la soumission d'un profil à vérification, la file d'attente, le vote des autres membres, le badge vérifié, les garde-fous anti abus.
On filme : pourquoi tu as choisi la vérification humaine plutôt que la reconnaissance faciale. C'est aussi la matière du module 6.
Prompt de départ
Contexte : [profils, photos et tirage fonctionnels] Objectif de cette étape : un profil peut être soumis à vérification. D'autres membres votent. Au-delà d'un seuil de votes concordants, le profil obtient un badge vérifié. Contraintes : un membre ne vote qu'une fois sur un profil donné. Un membre ne vote pas sur son propre profil. Prévoir le cas d'un groupe qui s'auto-valide, et le cas d'un membre qui refuse tout par principe. Hors périmètre : le signalement de contenu et la modération, traités au module 6. Critère de fin : je simule un vote de complaisance et un vote malveillant, et le système ne se laisse pas piéger dans les deux cas.
Critère de fin : les deux simulations d'abus échouent.
Piège à filmer : la conception des garde-fous. C'est le passage qui distingue un produit pensé d'un produit naïf.
Leçon 5.11 | Ne se planifie pas, se capture
On construit : rien de prévu. Cette étape n'a pas de contenu propre, elle a un dispositif.
Le dispositif : enregistre ton écran en continu à partir de l'étape 3. Le vrai blocage arrivera, probablement pendant l'étape 7, 8 ou 9. Quand il arrive, tu ne coupes pas, tu ne recommences pas proprement le lendemain. Tu gardes la séquence entière : l'incompréhension, les mauvaises pistes, la méthode qui reprend le dessus, la résolution.
Pourquoi c'est la leçon la plus précieuse : toutes les formations montrent des projets qui marchent du premier coup. Aucune ne montre le moment de panique. Tes élèves ont vécu ce moment, ils ont abandonné là. Leur montrer comment on en sort vaut plus que les treize autres étapes réunies.
Ce qui se filme en plus, à chaud : la méthode anti blocage du module 4 appliquée pour de vrai. Isoler, réduire, vérifier une hypothèse à la fois, et savoir repartir proprement plutôt qu'empiler des rustines.
Critère de fin : tu as une séquence brute d'au moins vingt minutes, non retouchée, où l'on voit la difficulté et la sortie.
Leçon 5.12 | Mobile, messages d'erreur, mentions légales
On construit : la relecture mobile complète, les messages d'erreur compréhensibles, les pages légales, la suppression de compte.
On filme : la différence entre "ça marche chez moi" et "c'est utilisable par quelqu'un d'autre".
Prompt de départ
Contexte : [application complète en local] Objectif de cette étape : rendre l'application présentable et utilisable par quelqu'un qui n'est pas moi. Contraintes : chaque message d'erreur doit dire ce qui s'est passé et quoi faire. Aucun message technique visible par l'utilisateur. Parcours complet vérifié sur téléphone. Suppression de compte fonctionnelle et effective. Hors périmètre : les nouvelles fonctionnalités. Aucune addition à ce stade. Critère de fin : je fais tester le parcours complet par quelqu'un qui ne connaît pas le projet, sans lui donner d'explication, et j'observe où il bloque.
Critère de fin : le test par un tiers, réellement effectué. Filme ses hésitations, pas seulement ses succès.
Piège à filmer : la tentation d'ajouter une dernière fonctionnalité juste avant la mise en ligne.
Leçon 5.13 | Une vraie adresse
On construit : le déploiement, le nom de domaine, les variables d'environnement, la vérification en conditions réelles.
On filme : le moment où l'adresse s'ouvre pour la première fois. C'est la promesse de la formation qui se réalise à l'écran, garde ce plan.
Prompt de départ
Contexte : [application finie et testée] Objectif de cette étape : mettre l'application en ligne sur son propre nom de domaine. Contraintes : Netlify. Aucune clé secrète dans le dépôt de code. Les variables d'environnement de production doivent être distinctes de celles de test. Vérifier que le paiement fonctionne en conditions réelles avant d'annoncer quoi que ce soit. Hors périmètre : l'optimisation des performances, la mesure d'audience. Critère de fin : je fais un parcours complet, inscription jusqu'à achat, sur l'adresse publique, depuis un téléphone qui n'est pas le mien.
Critère de fin : le parcours complet passe depuis un appareil extérieur.
Piège à filmer : la première mise en ligne qui échoue à cause d'une variable oubliée. Elle arrive presque toujours.
Leçon 5.14 | À reproduire chez soi
On construit : rien. On documente.
On filme : le parcours inverse. On repart du produit fini et on remonte jusqu'au plan de l'étape 2, en montrant que chaque brique du plan correspond à quelque chose de visible dans l'application.
Ce qui se produit ici : la checklist de mise en ligne, le modèle de plan en une page vierge, et le code source complet livré aux élèves.
Critère de fin : un élève qui a suivi les quatorze étapes peut refaire le même chemin sur son propre projet sans revenir te poser de question.
Rien à reconstruire, tout est déjà là. Il s'agit de refilmer sous un autre angle.
Module 6, confiance et cadre légal
Module 7, rendre le produit vivant
Module 8, vivre avec son projet
Quatre prompts qui reviennent à toutes les étapes. Ils constituent la bibliothèque anti blocage promise dans l'offre.
Le prompt de revue avant de valider une étape
Voici ce que tu viens de produire pour l'étape en cours. Avant que je valide, réponds à ces questions : 1. Qu'est-ce qui peut casser dans ce que tu as écrit ? 2. Qu'est-ce qui se passe si l'utilisateur fait la chose la plus bête possible à cet endroit ? 3. Y a-t-il une donnée sensible qui traîne quelque part où elle ne devrait pas ? 4. Qu'est-ce que tu as ajouté que je ne t'ai pas demandé ?
Le prompt de déblocage, premier niveau
Ça ne fonctionne pas. Avant de proposer une correction, aide-moi à isoler. Dis-moi quelle est la plus petite vérification que je peux faire pour savoir si le problème vient de [brique A] ou de [brique B]. Une seule vérification, la plus discriminante. Ne corrige rien tant que je ne t'ai pas donné le résultat.
Le prompt de déblocage, quand on tourne en rond
On a essayé trois fois et on revient au même point. Arrête de corriger. Reprends depuis le début : quelle hypothèse avons-nous acceptée sans la vérifier ? Liste les trois hypothèses implicites derrière notre approche actuelle, et dis-moi laquelle est la plus douteuse.
Le prompt de repartir proprement
Cette partie est devenue un empilement de rustines et je ne la comprends plus. Je préfère la refaire que la réparer. Reprends uniquement [la partie concernée], depuis zéro, avec ce que nous avons appris des échecs précédents. Ne réutilise pas le code existant. Dis-moi d'abord ton approche en trois phrases, avant d'écrire quoi que ce soit.
Quand on passera à la production du code, les règles habituelles s'appliquent : les fichiers arrivent en patch numéroté séquentiellement, jamais en projet complet sauf première livraison, et le SQL s'affiche dans la conversation, jamais dans une archive. Les migrations Supabase utilisent gen_random_uuid().