Tuto Claude Code : cadrer, tester et publier votre première app pas à pas

Je veux créer un outil interne pour {{description_courte_de_l_outil}}.
Voici les utilisateurs que j'envisage et leur problème actuel :
{{liste_utilisateurs_et_problemes}}

Pose-moi une question à la fois pour vérifier, pour chaque utilisateur : son vrai problème, ce que l'outil lui ferait gagner, et s'il en a réellement besoin. À la fin, rédige une fiche besoin d'une page : utilisateurs retenus, problème de chacun, 3 fonctionnalités maximum qui y répondent.

À partir de la fiche besoin ci-dessus, rédige un PRD (product requirement document) en Markdown avec ces sections :
1. Objectif de l'outil en une phrase
2. Utilisateurs et leur problème
3. Fonctionnalités de la version 1 (3 maximum), chacune avec un critère de réussite vérifiable
4. Hors cadre : tout ce qui ne sera pas fait en version 1, même si c'est tentant
5. Données manipulées et qui a le droit de voir quoi
6. Niveau d'ambition (à compléter à l'étape suivante)
Écris simplement, pour une personne qui ne code pas.

Crée un fichier CLAUDE.md à la racine du projet avec cette règle :

## Règle de périmètre
Le fichier PRD.md fait foi. Tu ne développes aucune fonctionnalité absente de sa section "Fonctionnalités de la version 1". Si je te demande autre chose, tu ne le codes pas : tu l'ajoutes au fichier BACKLOG.md avec la date, tu me le dis en une phrase, et tu attends que je lève l'interdiction explicitement en écrivant "j'autorise : {{nom_de_la_fonction}}".

## Niveau d'ambition
- Utilisateurs : {{nombre_utilisateurs}}
- Usage : {{local_ou_en_ligne}}
- Connexion par compte : {{oui_ou_non}}
- Perte des données : {{acceptable_ou_grave}}
Consigne : choisis l'architecture la plus simple qui répond à ce niveau. Avant d'ajouter un serveur, une base de données, un service payant ou un déploiement automatique, explique-moi pourquoi et attends mon accord.

Lis PRD.md et CLAUDE.md. Découpe la version 1 en étapes courtes, chacune avec ce que je pourrai vérifier moi-même à l'écran. Réalise uniquement l'étape 1, puis arrête-toi et dis-moi comment la tester. Pour toute partie invisible (base de données, gestion des erreurs, accès), explique en deux phrases ce que tu as fait et ce qui pourrait mal tourner.

Fais un audit de sécurité simple de ce projet, en langage non technique, sur quatre points :
1. Droits d'accès : un utilisateur peut-il lire des données qui ne le concernent pas en contournant l'interface (adresse directe, appel à l'API) ? Si une base Supabase est utilisée, la sécurité par ligne (Row Level Security) est-elle activée sur chaque table ?
2. Clés secrètes : y a-t-il une clé, un mot de passe ou un jeton écrit dans le code ou dans un fichier envoyé sur GitHub ?
3. Pannes : que se passe-t-il si le réseau coupe, si un formulaire est mal rempli, si un service externe ne répond pas ? Des données peuvent-elles être perdues ?
4. Dépendances : liste les bibliothèques ajoutées et dis lesquelles pourraient casser le projet lors d'une mise à jour.
Pour chaque point : OK ou à corriger, et pourquoi.

Rédige un plan de test pour la version 1, sous forme de tableau : action, résultat attendu, résultat obtenu (vide). Inclus : champs vides, fautes de frappe, coupure réseau au milieu d'une action, {{volume_realiste}} enregistrements chargés, et un test par rôle d'utilisateur pour vérifier qu'il ne voit que ses données. Ajoute des données de test fictives pour ce volume.

Avant de publier, mets en place deux environnements séparés : test et production, avec deux bases de données distinctes et un nom visible "TEST" sur la version de test. Explique-moi comment faire une sauvegarde des données de production et comment la restaurer. Propose l'hébergement le plus simple adapté au niveau d'ambition du PRD, avec son coût mensuel.