Pourquoi votre créateur d'applis avec IA vous montre d'abord des données fictives (et pourquoi c'est la bonne approche)
Si votre créateur d'applis avec IA remplit vos écrans d'utilisateurs inventés et de commandes d'exemple avant de toucher à la base de données, ce n'est pas un raccourci — c'est la bonne façon de construire. Voici pourquoi.
Vous décrivez une appli à votre créateur d’applis avec IA. Une minute plus tard, vous regardez une interface qui fonctionne — des pages, des boutons, un tableau d’utilisateurs portant des noms comme « Alex Rivera » et « Priya Shah », des prix qui n’ont aucun sens, une « Offre Pro » que vous n’avez pas demandée. Rien n’est enregistré. Si vous actualisez, les données sont toujours là. Si vous ajoutez un nouvel utilisateur, il disparaît.
On dirait un tour de magie sur le point de s’effondrer. Ce n’en est pas un. C’est la bonne partie de la construction. Les données fictives à l’écran sont une première étape délibérée, et c’est la raison pour laquelle la base de données qui suit collera réellement à l’appli que vous vouliez.
Ce que « données fictives d’abord » veut vraiment dire
Quand un créateur d’applis avec IA prend votre brief, il ne fonce pas droit sur la base de données. Un bon créateur écrit d’abord les écrans, les remplit de données fictives plausibles, et seulement ensuite — et seulement à ce moment-là — conçoit la base de données pour qu’elle corresponde.
Les données fictives ne sont pas de la décoration. C’est un contrat. Une fois que votre appli dit « chaque commande a un nom de client, trois lignes d’articles, un total et un statut », la base de données qui se construit ensuite doit avoir exactement ces éléments, dans exactement ces formes. Ce sont les écrans qui décident à quoi ressemble la donnée, pas l’inverse.
C’est à l’envers de la façon dont un développeur humain commencerait habituellement. Un développeur traditionnel conçoit d’abord la base de données, puis construit les écrans dessus. Les créateurs avec IA ont inversé ça, et la plupart des gens ne le remarquent pas — ils voient juste les faux utilisateurs et supposent que le créateur fait semblant.
Pourquoi cet ordre fonctionne mieux avec l’IA
Nous avons essayé de construire la base de données et les écrans en même temps. Ça n’a pas marché. Voici la version courte du pourquoi.
Quand deux agents IA travaillent sur des parties différentes d’une appli sans voir le résultat l’un de l’autre, ils font des suppositions incompatibles. L’agent de l’interface décide que les utilisateurs ont un champ « name ». L’agent de la base de données décide que les utilisateurs ont un champ « fullName ». Les deux semblent corrects. Ensemble, rien ne fonctionne. Un troisième agent est appelé pour rapiécer l’incohérence. Lui aussi devine. Maintenant il y a trois suppositions dans la nature, et l’appli que vous prévisualisez est un Frankenstein de toutes les trois.
La solution est presque gênante : faire une chose d’abord, puis l’autre. L’interface est construite. Elle consigne les données dont elle a besoin sous la forme d’un seul fichier de faux utilisateurs, fausses commandes, faux peu importe le sujet de votre appli. L’agent de la base de données lit ce fichier et le fait correspondre champ par champ. Aucune supposition. Aucune négociation. Aucune incohérence.
C’est pour ça que votre créateur d’applis avec IA peut vous montrer une appli d’apparence finie en une minute. Il n’a pas truqué la construction. Il a fait un quart de la construction — la partie qui décide de tout le reste — et la base de données, ce sont les dix secondes de travail suivantes, pas les dix heures suivantes.
Quoi regarder quand les données fictives sont à l’écran
C’est le moment que la plupart des gens survolent. Ils voient les données fictives et se mettent à demander des changements de couleur. Mais les données fictives sont une question qui vous est posée. Lisez-les.
Quelques exemples de ce à quoi prêter attention :
- Mauvais vocabulaire. L’appli que vous vouliez suit des « expéditions ». Les données fictives les appellent des « commandes ». Dites-le au créateur. Si vous laissez passer maintenant, chaque écran, chaque champ de base de données, chaque rapport utilisera le mauvais mot — et renommer plus tard n’est pas une opération en un clic, dans aucun outil, quoi qu’en dise le marketing.
- Champs manquants. La fausse facture a un total et une date. Il vous faut aussi un numéro de bon de commande. Mieux vaut l’ajouter maintenant, quand il y a cinq fausses factures sur un écran, qu’une fois la base de données construite et alimentée avec de vraies données clients.
- Mauvaises formes. Les données fictives montrent « 1 client, 1 adresse ». Vos vrais clients ont plusieurs adresses. Le créateur ne peut pas le déduire de votre brief. Dites-le-lui maintenant, tant que changer la forme ne coûte rien.
- Entités surprises. Le créateur a inventé un concept d’« équipe » que vous n’avez pas demandé, parce qu’il a supposé une appli multi-utilisateurs. Peut-être que vous le vouliez. Peut-être pas. Dans tous les cas, décidez avant que la base de données ne soit construite autour.
Une règle utile : si votre appli comporte un nom qui n’est pas représenté dans les données fictives à l’écran, le créateur n’en a pas encore connaissance. Mentionnez-le avant de cliquer sur « enregistrer » lors de la première prévisualisation.
Pourquoi l’ordre compte pour ce qui vient ensuite
Une fois que les données fictives sont justes, la construction de la base de données est mécanique. Le créateur lit vos fausses données, génère un schéma qui correspond, écrit les requêtes que les écrans essaient déjà d’appeler, et remplace enfin les imports fictifs par de vrais. Les mêmes écrans qui affichaient de faux utilisateurs affichent maintenant ce que vous y mettez réellement.
Vous pouvez généralement voir le basculement se produire en temps réel. Une page qui se chargeait instantanément parce qu’elle lisait un fichier local affiche maintenant un état de chargement d’une demi-seconde — c’est l’écran qui parle à une vraie base de données pour la première fois. La plupart des gens passent à côté de ça et ne réalisent pas que l’appli vient de franchir la ligne entre « démo » et « truc capable de stocker de vraies données ».
La raison pour laquelle ça fonctionne, c’est que tout ce qui vient en aval — la conception de la base de données, les requêtes, les états de chargement, les états vides — a été décidé par ce que vous avez vu à l’écran pendant la phase des données fictives. Si vous avez validé trois colonnes, vous obtenez trois colonnes. Si vous avez validé un champ « statut » avec les valeurs « brouillon » et « envoyé », c’est exactement ce que la base de données accepte. Il n’y a pas de deuxième étape de traduction où une passation entre designer et développeur déforme tout.
Un petit test que vous pouvez faire
La prochaine fois que vous construisez quelque chose, essayez ceci : quand les données fictives apparaissent, changez une seule chose avant de demander quoi que ce soit d’autre. Renommez un champ. Ajoutez une colonne. Remplacez « utilisateurs » par « membres ». Puis observez ce qui se passe quand la base de données se construit.
Vous verrez le changement apparaître partout — dans la conception de la base de données, dans les requêtes, dans les données d’amorçage que le créateur insère quand l’appli est terminée. Un seul mot au stade des données fictives s’est propagé dans toute l’appli. C’est le levier que vous avez pendant cette phase, et c’est la raison pour laquelle « données fictives d’abord » n’est pas une combine pour rogner sur les coins. C’est là que l’appli se décide réellement.
Si vous voulez aller plus loin, notre dernier article sur ce qu’il y a vraiment dans une appli créée avec l’IA parcourt les autres rouages que vous ne voyez pas au premier coup d’œil. Le schéma est le même : l’essentiel du levier se trouve dans les parties qui ont l’air de ne pas compter.