Des modèles de prompts pour créer de meilleures apps avec Coderblock

Un bon prompt pour Coderblock n’a pas besoin de ressembler à une spécification technique. Inutile de parler de frameworks, de bases de données, d’API ou d’architecture. Vous pouvez simplement décrire ce que vous souhaitez créer et laisser les agents IA transformer votre idée en une véritable app fullstack utilisant React, TypeScript, Tailwind CSS, l’authentification et, si nécessaire, une base de données Postgres.

Cela ne signifie pas pour autant que tous les prompts se valent.

Plus le contexte fourni est clair, plus l’agent peut prendre des décisions pertinentes à votre place. Un bon prompt ne décrit pas chaque détail de l’implémentation : il précise ce que vous créez, pour qui, comment le produit doit fonctionner et quelles règles doivent être respectées.

Vous pouvez ensuite laisser Coderblock faire le reste. Voici quelques modèles à utiliser pour obtenir de meilleurs résultats et rendre vos itérations plus efficaces.

Commencez par le produit, l’utilisateur et le résultat

Un prompt comme « Crée une dashboard » ou « Crée une app de réservation » peut suffire pour commencer, mais il laisse de nombreuses questions sans réponse. Qui utilisera l’app ? Que doit pouvoir faire cette personne ? Quel est le résultat le plus important que vous souhaitez obtenir ?

Pour donner facilement le bon contexte à l’agent, partez de trois éléments :

• Produit : quel type d’app créez-vous ?
• Utilisateur : qui va l’utiliser ?
• Résultat : que doit-il pouvoir accomplir ?

Par exemple :

Crée une plateforme de réservation pour des coachs sportifs indépendants. Les coachs doivent pouvoir publier leurs séances disponibles, tandis que les clients doivent pouvoir consulter les horaires, créer un compte et réserver un créneau. Ajoute une dashboard permettant aux coachs de gérer leurs prochaines réservations.

Avec ces informations, l’agent dispose déjà d’un modèle concret du produit. Il peut déduire les écrans principaux, les rôles, les entités de la base de données et la navigation sans que vous ayez à préciser les routes ou le schéma.

Si vous partez de l’un des templates de Coderblock, vous pouvez utiliser la même approche pour expliquer ce que vous souhaitez modifier ou ajouter. Le template constitue le point de départ : votre idée vient se construire sur cette structure.

Décrivez des parcours, pas des fonctionnalités isolées

Une liste de fonctionnalités indique ce qui doit être présent. Un parcours explique comment tous ces éléments doivent fonctionner ensemble. Au lieu d’écrire « ajoute l’authentification, les profils, les réservations et les e-mails », décrivez ce qui se passe lorsqu’une personne utilise le produit.

Essayez plutôt ceci :

Un nouveau visiteur doit pouvoir consulter les profils des coachs sans se connecter. Lorsqu’il choisit une séance, demande-lui de s’inscrire ou de se connecter, de confirmer sa réservation, puis affiche-la dans la section Mes réservations. Les coachs doivent uniquement voir les réservations associées à leurs propres séances.

L’agent connaît désormais le parcours de l’utilisateur : ce qui est public, à quel moment l’authentification est nécessaire, ce qui se passe après la réservation et quelles données sont visibles par chaque rôle.

À partir de ces indications, il peut configurer Supabase Auth, les routes protégées, les sessions, les tables et la Row Level Security en fonction du comportement décrit. Il n’est donc pas nécessaire de demander une logique JWT personnalisée, le hachage des mots de passe ou une table distincte pour ceux-ci. Il est plus utile d’indiquer qui doit pouvoir accéder à quoi et de laisser Coderblock choisir l’implémentation appropriée.

Distinguez les exigences essentielles des préférences

Toutes les décisions n’ont pas la même importance. Un bon prompt distingue clairement ce que l’app doit impérativement faire de ce que l’agent peut interpréter librement.

Par exemple :

Exigences essentielles : connexion des clients, profils des coachs, disponibilités, réservations et vues distinctes pour les clients et les coachs. Préférences visuelles : design éditorial et apaisant, couleurs neutres et chaleureuses, espaces généreux et animations réduites au minimum. L’agent UX peut décider de la mise en page exacte des cartes.

Ainsi, les fonctionnalités fondamentales restent obligatoires, tandis que vous laissez aux agents de l’Agent Team la liberté de prendre des décisions en matière de design et d’UX.

Les contraintes peuvent également être très utiles. Par exemple :

• Approche mobile-first ou desktop-first
• Pages publiques ou accessibles uniquement après authentification
• Rôles utilisateur nécessaires
• Devise et périodicité de facturation
• Données qui doivent rester privées pour chaque utilisateur
• Actions réservées aux administrateurs

La règle est simple : précisez le comportement attendu, pas nécessairement la manière de l’implémenter.

Décrivez les données à travers leurs relations

Lorsque vous créez une app, vous n’avez pas nécessairement besoin de raisonner en termes de tables et de migrations.

Il est beaucoup plus naturel de décrire les relations qui existent dans le monde réel.

Coderblock attribue à chaque app web standard un projet Supabase dédié, avec Postgres et la Row Level Security. Vous pouvez donc expliquer comment les données doivent être organisées sans écrire manuellement le schéma de la base de données.

Par exemple :

Chaque coach peut créer plusieurs types de séances. Un type de séance comprend une durée, un prix et une description. Les créneaux disponibles appartiennent à un coach et ne peuvent avoir qu’une seule réservation confirmée au maximum. Les clients doivent uniquement voir leurs propres réservations, tandis que les coachs doivent voir celles qui concernent leurs créneaux.

Comparée à un simple « ajoute une table de réservations », cette description fournit beaucoup plus d’informations à l’agent : les entités existantes, leurs relations, les contraintes à respecter et les personnes autorisées à accéder aux données.

Si le produit évolue, continuez à décrire les changements du point de vue du comportement :

Ajoute aux réservations le motif ainsi que la date et l’heure de l’annulation. Les clients peuvent annuler jusqu’à 24 heures avant une séance, mais seuls les coachs peuvent marquer une réservation comme terminée.

L’agent peut alors mettre à jour la structure existante sans devoir recréer l’app à partir de zéro.

Une modification à la fois. Et toujours observable.

L’un des principaux atouts de l’aperçu en direct de Coderblock est la possibilité de voir rapidement l’effet de chaque modification. Après la première génération, mieux vaut donc formuler des demandes ciblées et successives plutôt que de réécrire l’intégralité du brief à chaque fois.

Par exemple :

Fixe la barre de navigation sur ordinateur, mais conserve un en-tête compact sur mobile.

Dans la dashboard du coach, affiche les séances du jour avant le calendrier de la semaine.

Ajoute un état vide à la section Mes réservations, avec un bouton permettant de revenir à la recherche de coachs.

Chaque demande produit un résultat concret que vous pouvez immédiatement vérifier dans l’aperçu. Il devient ainsi plus facile de comprendre ce qui a fonctionné, ce qui doit être corrigé et quelle devrait être l’étape suivante.

Pour les modifications plus importantes, vous pouvez également demander à l’agent de procéder par étapes :

Commence par ajouter les rôles des coachs et les routes protégées qui leur sont destinées. Crée ensuite l’éditeur de disponibilités. Enfin, relie les créneaux disponibles au parcours de réservation des clients.

Même une fonctionnalité complexe devient alors une suite d’étapes faciles à vérifier.

N’oubliez pas les états et les cas limites

Une app ne se résume pas à son parcours nominal. Que voit un utilisateur qui n’a encore aucune réservation ? Que se passe-t-il si un paiement échoue ? Et si un créneau n’est plus disponible ? Que voit une personne qui tente d’accéder à une section réservée ?

Vous pouvez décrire directement ces scénarios dans vos prompts :

• « Affiche un état vide utile lorsque l’utilisateur n’a aucune réservation. »
• « Désactive les créneaux indisponibles et explique pourquoi ils ne peuvent pas être sélectionnés. »
• « Affiche un indicateur de chargement pendant l’envoi de la réservation. »
• « Si un utilisateur qui n’est pas administrateur ouvre la route d’administration, redirige-le de manière sécurisée. »
• « Rédige des messages de validation précis et place-les à côté des champs concernés. »

Ce sont de petits détails, mais ils font toute la différence entre un prototype fonctionnel et un produit qui semble réellement prêt à être utilisé. Vous pouvez également demander aux agents spécialisés dans l’UX ou la sécurité d’analyser un parcours existant et de suggérer ou d’appliquer des améliorations.

Lorsque vous ajoutez des paiements, décrivez la règle commerciale

Pour intégrer des paiements, vous n’avez pas besoin d’expliquer le fonctionnement de Stripe. Vous devez expliquer ce que vous vendez et ce qui se passe après le paiement. Indiquez au minimum :

• produit ou service
• prix
• devise
• modèle de facturation
• fonctionnalités accessibles après l’achat

Par exemple :

Permets aux clients de s’abonner pour 9,99 € par mois. Les abonnés peuvent réserver des séances premium, gérer leur abonnement depuis leur compte et consulter l’état actuel de leur facturation. Commence en mode test Stripe.

Dans le mode géré par défaut, l’agent peut créer un compte Stripe géré après vous avoir demandé quelques informations de base, comme votre pays et le nom de votre entreprise. Il peut ensuite configurer les produits, les prix, le checkout et les webhooks. La configuration nécessaire pour recevoir les paiements peut être finalisée ultérieurement grâce au lien d’onboarding hébergé par Stripe.

Si vous préférez utiliser votre propre compte Stripe, vous pouvez demander le mode BYOK. L’agent demandera STRIPE_SECRET_KEY via une invite sécurisée dédiée aux variables d’environnement et configurera automatiquement le webhook.

Les secrets restent sur le serveur et ne sont ajoutés ni à la conversation ni au code généré.

Terminez par un prompt de révision

Avant de publier, vous pouvez demander aux agents d’effectuer une dernière vérification de l’ensemble de l’expérience. Par exemple :

Examine l’app du point de vue d’un nouveau client, d’un coach et d’un administrateur. Vérifie la navigation, l’ergonomie sur mobile, les autorisations, les états vides et l’intégralité du parcours de réservation. Corrige les problèmes évidents sans modifier la direction visuelle.

Ce type de prompt fonctionne, car il définit les profils à simuler, les éléments à vérifier et les limites à respecter. Après avoir vérifié l’aperçu, vous pouvez utiliser Publier pour déployer l’app à son adresse coderblock.app ou connecter un domaine personnalisé depuis Paramètres → Domaines.

Le meilleur prompt est celui qui laisse de la place à l’IA

Il n’est pas nécessaire d’écrire des prompts interminables pour obtenir de bons résultats avec Coderblock. Vous devez surtout fournir à l’agent les informations qui comptent réellement : qui utilisera le produit, ce que cette personne doit pouvoir faire, comment les parcours doivent fonctionner, quelles données doivent être reliées, quelles règles ne peuvent pas être enfreintes et ce qui doit se produire dans chaque scénario.

Le reste peut être construit par itérations. Commencez par un brief clair. Observez ce qui est généré. Testez l’app. Poursuivez ensuite avec des demandes courtes, concrètes et vérifiables.

C’est là tout l’intérêt de travailler avec un agent de codage IA : vous n’avez pas besoin de savoir à l’avance comment créer le produit. Vous devez savoir ce que vous voulez créer.