Aujourdh'ui, on va construire une app ensemble. Une vraie, avec une URL, que tu pourras envoyer à quelqu'un d'autre. Et pendant qu'on la construit, les trois couches à connaitre quand on crée une application vont apparaître d'elles-mêmes à l'écran.
Avant de commencer : ce qu'on va construire
J'ai hésité entre plusieurs options pour cet exercice. Un formulaire de contact avec page de confirmation, c'est trop simple. Un mini-CRM à deux tables, c'est trop ambitieux pour une première fois. J'ai choisi le tracker de candidatures quand tu cherches du boulot.
Voici ce que ça fait : tu entres une candidature (poste, entreprise, date d'envoi), tu lui donnes un statut (envoyée, relancée, entretien, refus), et tu vois toutes tes candidatures sur une page. C'est tout.
Pourquoi ce cas précis ? Parce qu'il est concret pour quelqu'un qui recrute autant que pour quelqu'un qui cherche un poste. Parce qu'il a exactement ce qu'il faut pour voir les trois couches sans en avoir trop. Et parce que c'est un outil que j'aurais voulu avoir quand je cherchais mon premier poste, avant de comprendre qu'on pouvait le construire soi-même en une heure.
À la fin de cet article, tu as un outil qui tourne, accessible par une URL, que tu peux partager ou garder pour toi.
Ouvrir Lovable et taper la première phrase
Lovable, c'est un outil qui transforme du texte en application. Tu lui décris ce que tu veux, il génère le code et te montre le résultat en direct. Pas besoin de savoir ce que signifie ce code. Pas besoin de l'installer. Ça tourne dans le navigateur.
Tu crées un compte sur lovable.dev, tu cliques sur "New project", et tu te retrouves face à un champ vide.
C'est là que beaucoup de gens bloquent. Qu'est-ce qu'on écrit ?
Ce qu'on écrit exactement
Voici le prompt que j'ai utilisé, mot pour mot :
Crée un tracker de candidatures simple. L'utilisateur peut ajouter une candidature avec : le nom du poste, l'entreprise, la date d'envoi, et un statut parmi : Envoyée, Relancée, Entretien, Refus. Toutes les candidatures s'affichent sur une page sous forme de tableau. On peut changer le statut directement dans le tableau.
C'est tout. Une description de ce qu'on veut voir, de ce qu'on peut y entrer, et de ce qu'on peut y faire. Pas de jargon technique. Pas de "je veux un composant React avec un state management". Une description fonctionnelle, comme si tu l'expliquais à un stagiaire.
Lovable réfléchit pendant quelques secondes. Parfois vingt, parfois une minute. Et puis quelque chose apparaît.
Ce qui apparaît : la première couche
À droite de l'écran, une interface. Un formulaire avec quatre champs. Un bouton "Ajouter". Un tableau vide en dessous, avec des colonnes : Poste, Entreprise, Date, Statut.
C'est propre. C'est cliquable. C'est une vraie app.
Ce que tu vois là, c'est la première couche. Les boutons, les champs, les colonnes, les couleurs : tout ça s'appelle l'interface. C'est la partie visible, celle avec laquelle tu interagis directement. Celle que tu vois, que tu touches, que tu montres à quelqu'un en disant "voilà ce que ça fait".
Je n'ai pas dessiné cette interface. Je n'ai pas choisi les couleurs, ni la police, ni la disposition du formulaire. Lovable a pris ma description et a généré une interface qui correspond. Ce n'est pas toujours parfait du premier coup, mais c'est toujours utilisable.
La première couche est là. On continue.
Ajouter une vraie donnée : là où ça devient intéressant
Une interface vide, c'est joli. Mais ce qui rend une app utile, c'est ce qu'elle retient.
Remplir le formulaire pour la première fois
Je tape dans le formulaire : "Responsable RH", "Entreprise X", date d'aujourd'hui, statut "Envoyée". Je clique sur "Ajouter".
La ligne apparaît dans le tableau.
Je ferme l'onglet. Je rouvre l'URL. La ligne est encore là.
La deuxième couche apparaît
Derrière l'écran, ce que je viens de taper est rangé dans une table. Pense à un tableau Excel que tu n'as pas eu à créer : des colonnes (Poste, Entreprise, Date, Statut), des lignes (une par candidature), et les valeurs à l'intérieur. C'est ça, les données. La deuxième couche.
Cette couche est invisible quand tu utilises l'app. Tu ne la vois jamais directement. Mais c'est elle qui fait que ton tracker a une mémoire. Que les candidatures ne disparaissent pas quand tu fermes le navigateur. Que tu peux en avoir dix, cinquante, deux cents, et les retrouver.
Savoir nommer ça m'a économisé des heures de débogage.
Faire faire quelque chose à l'app
On a une interface. On a des données. Mais une app, c'est aussi ce qui se passe quand tu agis.
Un exemple : changer le statut d'une candidature
Dans le tableau, je clique sur le statut "Envoyée" de ma candidature. Un menu déroulant apparaît. Je choisis "Entretien".
Le statut change. La ligne se met à jour. Si j'avais configuré des couleurs par statut (et on pourrait le faire, en une phrase supplémentaire à Lovable), la ligne changerait de couleur.
Quelque chose a décidé de ce qui devait se passer quand j'ai cliqué. Ce quelque chose a reçu mon clic, a compris que je voulais modifier le statut, a trouvé la bonne ligne dans les données, l'a mise à jour, et a rafraîchi l'affichage.
Je n'ai pas écrit cette séquence. Lovable l'a générée.
La troisième couche, enfin
Ce mécanisme s'appelle la logique. C'est la troisième couche. Elle est invisible elle aussi, mais pour une raison différente : c'est du code. Des instructions. "Si l'utilisateur clique ici, alors fais ça. Si cette condition est vraie, affiche ceci. Si ce champ est vide, bloque l'envoi."
La logique, c'est ce qui fait que les deux premières couches se parlent. L'interface reçoit une action. La logique décide quoi en faire. Les données sont mises à jour. L'interface se rafraîchit.
Trois couches, une app : ce que ça change de le savoir
Je ne t'apprends pas à coder. Ce n'est pas l'objectif, et ce n'est pas ce que Lovable demande.
Mais cette grille de lecture, interface, données, logique, change quelque chose de concret dans la façon dont on travaille avec ces outils.
Quand une app ne fait pas ce qu'on veut, la question n'est plus "qu'est-ce qui ne marche pas". Elle devient "dans quelle couche est le problème". Et les trois options réduisent l'espace de recherche de façon radicale.
Le bouton ne s'affiche pas correctement ? Interface. La donnée disparaît au rechargement ? Données. L'action ne produit pas le bon résultat ? Logique.
Ce n'est pas une méthode de débogage pour développeurs. C'est un outil de diagnostic pour quelqu'un qui décrit ce qu'elle veut à Lovable et qui veut comprendre pourquoi ça ne marche pas encore. Pour pouvoir reformuler. Préciser. Corriger.
J'ai construit mes derniers outils en sachant à peine ce que signifie "compiler du code". Mais je savais, à chaque bug, dans quelle couche chercher. Et je savais décrire le problème à Lovable (ou à Claude, selon ce que je faisais) avec assez de précision pour qu'il comprenne ce que je voulais corriger.
C'est ça, le vrai bénéfice de nommer les choses.
L'app est en ligne. Vraiment.
Dans Lovable, en haut à droite, il y a un bouton "Publish".
Je clique dessus.
Lovable génère une URL. Quelque chose comme tracker-candidatures-xyz.lovable.app. Je la copie. Je l'ouvre dans un autre onglet.
L'app est là. Mes candidatures sont là. Le formulaire fonctionne. Les statuts se changent.
Je copie l'URL et je l'envoie à une amie qui cherche un poste en ce moment. Elle ouvre le lien sur son téléphone. Elle voit l'app. Elle peut l'utiliser.
Il ne s'est pas passé trente minutes depuis que j'ai ouvert Lovable.
Ce que tu viens de construire n'est pas une maquette, pas une démo, pas un prototype en carton. C'est une app. Elle a une interface (ce que tu vois), des données (ce qu'elle retient), et une logique (ce qu'elle fait quand tu agis). Elle a une adresse. Elle tourne sans toi.