Par Thomas Cohen, fondateur de Maestro
v0 en français : créer une application qui conserve ses données
Construisez un carnet de demandes par étapes : formulaire, enregistrement durable, accès, publication et ajout d’un champ. Un protocole documenté pour savoir ce qui fonctionne vraiment.
Une demande ajoutée dans un écran v0 doit rester disponible après fermeture du navigateur, depuis un autre appareil autorisé et après une nouvelle publication. C'est ce comportement qu'il faut construire et vérifier. Un formulaire qui affiche immédiatement ce que vous venez de saisir peut encore fonctionner seulement avec la mémoire de la page.
Ce guide propose le carnet fictif de Léa, responsable d'un espace de travail partagé. Elle note les demandes de ses membres et leur état de traitement. Il s'agit d'un parcours à reproduire à partir de la documentation officielle consultée le 2 octobre 2026, accompagné d'un document réutilisable. Nous ne présentons pas une application v0 construite, publiée ou testée dans le cadre de cet article.
Comprendre ce que v0 peut construire
v0 peut générer une application complète, avec interface, traitements et connexion à des services de données. Sa documentation sur les applications full-stack décrit notamment la persistance des données et la logique côté serveur. Le réduire à un outil de maquettes ou de composants d'interface donnerait une image incomplète de son périmètre actuel.
Pour Léa, ces différentes parties correspondent à des objets simples. Le formulaire est l'endroit où elle saisit une demande. Le traitement décide si cette demande est valide et autorisée. La base la conserve. L'écran de liste relit ensuite cette base pour afficher les dossiers. Une erreur peut survenir à chacune de ces étapes, même si la première page paraît terminée.
L'objectif initial doit rester petit : créer une demande, la retrouver et changer son statut. N'ajoutez pas simultanément messagerie, facturation et génération de réponses. Chaque connexion supplémentaire introduit un compte, une configuration et des comportements à vérifier. Vous apprendrez davantage d'un petit parcours complet que d'une dizaine de boutons dont le fonctionnement reste incertain.
Écrire le carnet avant de demander sa génération
Décrivez les champs avec leur sens métier. Une demande possède une référence stable, un titre, une description, une date de création et un statut parmi « à traiter », « en cours » et « terminé ». Son titre est obligatoire. Une description peut rester vide. La référence ne change pas lorsque Léa corrige une faute dans le titre.
Précisez qui utilise la première version. Ici, Léa et son collègue Hugo gèrent un carnet interne partagé ; un visiteur non connecté ne doit ni lire ni modifier les demandes. L'exercice n'ouvre pas de portail aux membres. Ce périmètre évite de mélanger un carnet d'équipe et un système où chaque client ne devrait voir que ses propres données.
Préparez trois entrées fictives : une ampoule à remplacer, une réservation à déplacer et une chaise à réparer. La réservation est terminée, les autres restent à traiter. Ajoutez une demande au titre long, puis une tentative sans titre. Vous obtenez des exemples assez variés pour discuter les écrans et les messages avant toute donnée réelle.
La fiche de construction v0 contient le brief, les messages à adapter et les observations à renseigner. Elle sert de mémoire du projet : conservez-y les décisions quand vous changez d'écran ou de conversation.
Demander une première version dont les limites sont visibles
Commencez par le formulaire, la liste et les états vides. Demandez explicitement que les exemples soient présentés comme des données fictives et qu'un enregistrement simulé ne soit pas décrit comme une sauvegarde durable. Ce point permet de relire l'interface sans confondre son apparence avec son fonctionnement.
Vous pouvez formuler la demande ainsi : « Crée un carnet interne de demandes avec le formulaire et la liste décrits dans mon brief. Affiche les erreurs près des champs concernés. Prévois un état sans demande, un chargement et un échec d'enregistrement. Indique ce qui reste à connecter avant de conserver réellement les données. » Cette formulation décrit un résultat et demande d'identifier les éléments manquants.
Relisez ensuite le parcours comme Léa. Après un clic sur Enregistrer, le bouton empêche-t-il les doubles clics accidentels ? Si l'opération échoue, le texte saisi reste-t-il disponible ? Si une description est longue, peut-on encore atteindre le bouton sur téléphone ? Ces questions portent sur votre application, pas sur une qualité garantie de l'outil.
Gardez la première version sobre. Une couleur de statut ne remplace pas son libellé, et une animation de réussite ne constitue pas une confirmation provenant de la base. Faites corriger ces ambiguïtés avant de brancher le stockage.
Relier le carnet à un stockage durable
La documentation des bases de données de v0 présente plusieurs intégrations, dont Supabase et Neon. Le service choisi doit correspondre aux besoins du projet et aux accès disponibles. Vous devrez identifier le compte propriétaire, le projet de données et les conditions de son utilisation. Une intégration visible ne signifie pas que toute consommation est comprise dans un abonnement unique.
Demandez maintenant de remplacer les exemples par une lecture et une écriture dans la base retenue. Précisez que les données d'essai doivent être séparées de celles d'un éventuel usage réel. Demandez une explication simple : où la demande est-elle enregistrée, quelle action la lit et quel réglage indique à l'application quelle base utiliser ?
Léa doit pouvoir retrouver la même référence dans son écran et dans un export autorisé de la base. Si une demande apparaît seulement dans le navigateur, l'essai n'établit pas encore la persistance attendue. Inversement, une ligne présente dans la base mais absente de l'écran peut signaler une erreur de lecture, de filtre ou de permission.
Conservez les noms des paramètres nécessaires dans votre fiche, sans leurs valeurs secrètes. Les mots de passe et clés donnant des droits importants doivent rester dans l'emplacement prévu pour leur configuration, pas dans un texte partagé avec l'équipe ni dans une capture de démonstration.
Séparer enregistrement durable et accès autorisé
Une donnée peut être conservée durablement et rester accessible à la mauvaise personne. L'ajout d'une base ne suffit donc pas à protéger le carnet. Décrivez les droits indépendamment des écrans : Léa et Hugo peuvent consulter et modifier les demandes de leur carnet ; une personne non connectée ne le peut pas.
Demandez où cette règle est appliquée. Elle doit être vérifiée au niveau qui autorise l'accès aux données, et pas seulement par le fait de cacher la page. Faites contrôler la lecture et la modification sur vos données fictives avec des sessions distinctes. Si votre équipe ne sait pas vérifier cette partie, faites intervenir une personne compétente avant d'introduire des informations confidentielles.
La documentation de sécurité de v0 constitue un point de départ pour comprendre le cadre de la plateforme. Elle ne valide pas les règles de votre carnet particulier. Les choix de connexion, de stockage et d'autorisation doivent être examinés dans le projet effectivement généré.
Pour un premier essai, gardez un journal factuel : compte utilisé, opération demandée, résultat attendu, résultat obtenu. « Impossible de lire sans connexion » et « impossible de modifier sans connexion » sont deux observations distinctes. Ne résumez pas leur vérification par un simple cadenas dessiné sur l'écran.
Prouver la persistance par plusieurs essais
Créez une demande nommée « Essai de persistance A » et relevez sa référence. Rechargez la page, fermez l'onglet, puis reconnectez-vous. Retrouvez la demande et sa description. Un seul rechargement peut laisser croire à une sauvegarde alors que le navigateur conserve localement les données ; il faut aller plus loin.
Ouvrez le même carnet depuis un autre navigateur ou appareil avec un compte autorisé. Si le dossier est absent, examinez la base utilisée et les droits avant de conclure à une perte. Deux versions de l'application peuvent pointer vers des environnements différents. Votre fiche doit permettre d'identifier chaque adresse et chaque service de données.
Modifiez ensuite la description avec Hugo, puis relisez-la avec Léa. Vérifiez le comportement prévu lorsque deux personnes travaillent sur la même demande. Pour ce petit carnet, vous pouvez décider que la dernière modification est conservée et rendre cette limite explicite ; si ce choix est inacceptable, il faut prévoir une protection contre l'écrasement d'un travail concurrent.
- Réussite attendue : la même référence et le même contenu sont retrouvés après reconnexion.
- Réussite attendue : un second compte autorisé accède au carnet partagé.
- Refus attendu : une personne non connectée ne consulte pas les dossiers.
- Incident à essayer : une erreur d'enregistrement conserve la saisie et explique comment réessayer.
Ces essais apportent des preuves sur des comportements précis. Ils ne constituent ni un audit complet ni une garantie que toute panne future sera sans conséquence.
Préparer la publication comme une nouvelle étape
La documentation de publication de v0 décrit le lien avec Vercel. Avant de publier, identifiez le compte qui hébergera le projet, l'adresse visée, la base utilisée et les paramètres nécessaires. Relisez les conditions et dépenses possibles des services impliqués ; la génération du code et son fonctionnement accessible aux utilisateurs sont deux activités différentes.
Sur l'adresse publiée, répétez la création d'une demande, la reconnexion et l'essai avec Hugo. Ne déduisez pas le résultat public de celui de l'aperçu. Une configuration peut être présente dans l'environnement de construction et absente de l'environnement publié. Une adresse de retour après connexion peut également devoir être adaptée.
Conservez l'heure de l'essai, la version publiée et la référence créée. Si un problème survient, ces informations permettent de distinguer une ancienne version encore ouverte d'une erreur introduite par la publication. Sur téléphone, ouvrez directement une fiche puis rechargez la page : l'adresse doit rester utilisable, pas seulement le chemin parcouru depuis l'accueil.
L'article n'effectue pas cette publication à votre place. Les cases du document restent vides tant que vous n'avez pas réalisé les opérations dans votre projet. C'est cette trace qui transformera un parcours documenté en résultat constaté.
Ajouter un champ sans perdre les anciennes demandes
Léa souhaite ensuite indiquer une priorité : normale ou urgente. Demandez ce changement en précisant que les demandes existantes doivent être conservées. Décidez de la valeur applicable aux anciens dossiers, par exemple « normale », et expliquez ce que l'équipe doit faire si elle ne peut pas choisir automatiquement.
Le changement touche au moins le stockage, le formulaire et la liste. Demandez à v0 de présenter les étapes et les conséquences avant l'application aux données utilisées réellement. Faites l'essai sur une copie : retrouvez les anciennes références, leurs descriptions et leurs statuts, puis créez une nouvelle demande urgente.
Vérifiez aussi le cas d'un ancien onglet resté ouvert pendant la mise à jour. Peut-il encore envoyer une demande sans priorité ? Le comportement doit être prévu, soit avec une valeur par défaut cohérente, soit avec un message demandant de recharger. Ce petit détail peut expliquer des données incomplètes après une évolution pourtant réussie dans un onglet neuf.
Un retour à l'ancien code ne remet pas automatiquement la base dans son état précédent. Préparez donc la copie des données et la stratégie de reprise avant la modification. Le guide sur les risques d'une application construite avec l'IA aide à situer ces responsabilités dans un projet plus large.
Garder un projet que vous saurez reprendre
La connexion GitHub de v0 permet de travailler avec un dépôt de code. Ce dépôt conserve les fichiers et leur historique selon la configuration retenue. Il ne constitue pas automatiquement une sauvegarde des demandes, des documents importés ou des comptes de votre application.
Établissez une fiche avec cinq emplacements : code, données, fichiers, paramètres sensibles et gestion des utilisateurs. Ajoutez le propriétaire de chaque compte et la personne capable de publier une correction. Si un collègue reprend le carnet, il doit pouvoir comprendre cette carte sans remonter toutes vos conversations avec l'IA.
Nous éditons Maestro ; ce guide reste utilisable intégralement avec v0. Pour Léa, le résultat recherché est simple : une demande créée reste accessible aux personnes prévues après reconnexion, publication et évolution du carnet. Remplissez la fiche de vérification au fil du projet, et traitez les cases non vérifiées comme du travail restant à faire.