Comment briefer et vérifier une application de demandes clients créée par IA
Spécifiez un formulaire de demande, un stockage en base de données et une vue pour le personnel pour Leina, puis vérifiez la persistance, la validation et les contrôles d'accès avant de publier.
Une application de demandes clients commence par une idée simple : laissez les gens vous dire ce dont ils ont besoin, puis donnez à votre équipe un seul endroit pour examiner les demandes.
Pour que cela soit utile, le formulaire doit enregistrer les soumissions, expliquer les champs manquants et garder la vue du personnel accessible aux bonnes personnes.
Avec l’App Builder de Leina, vous pouvez créer des applications web full-stack—avec logique backend et stockage en base de données—par conversation. Utilisez le brief d’exemple ci-dessous pour demander une première version, puis vérifiez son comportement réel avant de la partager avec de vrais utilisateurs.
Délimitez une première version minimale
Lorsque vous générez des applications avec l’IA, résistez à l’envie de tout demander d’un coup (par exemple, notifications, synchronisation CRM, pièces jointes et étiquettes de priorité). Commencez par une base légère et vérifiable :
| Composant | Exigences essentielles de la v1 | À laisser de côté pour l’instant |
|---|---|---|
| Formulaire public | Nom du client et détails de la demande ; validation des champs obligatoires | Pièces jointes et assistants multi-étapes |
| Base de données | Stockage persistant des enregistrements avec horodatages de soumission automatiques | Notation automatique de priorité ou étiquettes de sentiment par IA |
| Tableau de bord du personnel | Liste en lecture seule des enregistrements soumis, par ordre chronologique inverse | Synchronisation bidirectionnelle CRM, e-mails de réponse client automatisés |
| Retour d’information | Bannière de confirmation explicite uniquement après réussite de l’écriture en base de données | États de succès spéculatifs avant confirmation de la base de données |
Décidez qui doit pouvoir voir chaque vue. Pour cet exemple, les visiteurs soumettent des demandes et le personnel autorisé les lit. Demandez à Leina comment elle peut mettre en œuvre cette séparation ; ce sont des exigences à vérifier, pas une liste de contrôles intégrés.
Donnez à Leina un brief avec des spécifications observables
Copiez et adaptez ce brief de départ dans Leina App Builder :
Créez une application web de demandes clients avec deux vues distinctes :
- Formulaire de demande public :
- Champs : « Nom du client » et « Détails de la demande » (les deux champs sont obligatoires).
- Validation côté client et serveur : rejetez les soumissions vides ou les entrées composées uniquement d’espaces avec un message d’erreur en ligne.
- Affichez une bannière de confirmation de succès uniquement après que l’enregistrement a été confirmé dans la base de données.
- Tableau de bord du personnel :
- Affichez toutes les demandes soumises dans un tableau ou une liste claire, classées de la plus récente à la plus ancienne.
- Affichez le nom du client, l’horodatage de soumission et le texte complet de la demande.
- Contrôle d’accès :
- Le formulaire de soumission doit être accessible à tous les visiteurs publics.
- Le tableau de bord du personnel doit être réservé aux membres authentifiés de l’équipe.
Expliquez les contrôles d’accès disponibles pour ces deux vues et signalez toute exigence que vous ne pouvez pas mettre en œuvre. Utilisez des enregistrements de test fictifs pendant le développement. Préparez l’application pour examen avant de la publier.
Exécutez quatre tests d’acceptation essentiels
Exécutez ces quatre vérifications sur l’application de test. Elles détectent des problèmes utiles dès la première exécution ; l’accès et le traitement des données nécessitent encore un examen pour votre usage prévu.
1. Suivez une soumission jusqu’au stockage
Soumettez une demande distinctive telle que « Test : fonctionnalité de résumé hebdomadaire ». Vérifiez ses valeurs dans la vue du personnel, rechargez la page, puis recherchez le même enregistrement dans le stockage backend ou via une session de navigateur autorisée distincte.
Le rechargement est une première vérification, pas une preuve d’écriture en base de données : le stockage du navigateur comme localStorage survit aussi aux rechargements. Inspectez l’enregistrement stocké pour vérifier où les données ont atterri. Si vous ne pouvez pas l’inspecter, notez cette partie de la vérification comme non résolue. Ajoutez une deuxième demande et confirmez que la première reste inchangée.
2. Le test de soumission vide (Validation)
Essayez de soumettre le formulaire avec des champs vides, ou avec uniquement des espaces.
Comportement attendu : Le formulaire doit mettre en évidence les champs manquants, bloquer la soumission et ne créer aucun enregistrement vide dans la base de données.
3. Le test multiligne et caractères spéciaux (Formatage)
Soumettez une demande contenant des sauts de ligne, des puces, des guillemets et des symboles (&, <, #). Inspectez la vue du personnel pour vérifier que le formatage est préservé sans caractères déformés ni bugs d’échappement.
4. Le test en navigation privée (Contrôle d’accès)
Copiez l’URL du tableau de bord du personnel et ouvrez-la dans une fenêtre de navigation privée / incognito où vous n’êtes pas connecté.
Comportement attendu : L’application doit demander une authentification ou refuser l’accès. Testez également un compte connecté qui ne devrait pas avoir accès au personnel. Une page cachée ou un écran de connexion seul ne prouve pas que les requêtes de données sous-jacentes sont protégées. Si la restriction requise n’est pas disponible, gardez l’application sur des données fictives jusqu’à ce que cela soit résolu.
Suivez vos observations à l’aide de la liste de vérification pour l’examen de l’application de demandes clients.
Révisez un comportement à la fois
Lorsque vous rencontrez un problème, ne demandez pas au builder de « tout corriger ». Donnez des instructions concrètes portant sur un seul comportement :
Lorsque je soumets une demande vide, le formulaire affiche un message de succès alors qu’aucun enregistrement n’est sauvegardé. Veuillez plutôt afficher une erreur en ligne pour le champ obligatoire, continuer à faire fonctionner les soumissions réussies et préserver les enregistrements de test existants.
Après chaque correction, vérifiez à la fois le chemin d’erreur corrigé et une soumission normale pour vous assurer que la correction n’a pas introduit de régressions.
Publiez et déployez
Une fois que vous avez résolu les vérifications et confirmé que l’application convient à son public cible :
- Examinez les données de test : Identifiez et supprimez uniquement les enregistrements fictifs que vous avez créés pour les tests.
- Examinez l’accès : Vérifiez qui peut soumettre des demandes et qui peut lire les enregistrements sauvegardés en utilisant les contrôles réellement disponibles dans l’application.
- Publiez et vérifiez : Trouvez l’application dans My Apps et suivez le flux de publication disponible. Répétez une soumission et les vérifications d’accès sur la version publiée avant de partager son lien de formulaire.
Choisissez une personne pour examiner les demandes entrantes et conservez une trace des limitations non résolues. Ajoutez des fonctionnalités une fois que l’équipe a utilisé la petite version et sait ce dont elle a besoin ensuite.