Trois articles. Une poignée de sessions de travail. Et maintenant tu as devant toi un bureau encombré d'outils dont tu ne sais plus très bien ce que chacun fait là.
C'est normal. C'est même exactement ce qu'il fallait faire : toucher avant de comprendre, installer avant de cartographier. Mais à un moment, il faut lever la tête.
Voilà ce que tu as devant toi.
Ce que tu as installé sans vraiment le choisir
Si tu fais l'inventaire de ce que tu as manipulé depuis le début de cette série, ça ressemble à ça : Lovable, Cursor, Claude Code, Node.js. Plus quelques comptes créés, quelques fichiers ouverts, quelques commandes tapées dans un terminal en te demandant si tu faisais juste.
Quand je me suis retrouvée dans cet état, à peu près trois semaines après avoir commencé à bricoler sérieusement avec ces outils, j'ai eu un moment de flottement. Pas de panique, mais une sensation d'éparpillement. J'avais installé ce qu'on m'avait dit d'installer. J'avais avancé. Et je n'aurais pas pu expliquer à quelqu'un pourquoi j'utilisais tel outil plutôt qu'un autre, ni même ce que chacun faisait exactement dans la chaîne.
Le problème avec l'apprentissage par manipulation, c'est qu'il fonctionne très bien pour acquérir des réflexes, et très mal pour construire une représentation d'ensemble. Tu sais faire des choses. Tu ne sais pas encore ce que tu fais.
Cet article ne t'apprend rien de nouveau. Il te donne la carte de ce que tu as déjà.
Lovable : la marche d'éveil, déjà derrière toi
Lovable, c'est l'outil avec lequel tu as commencé. Et si tu lis cet article dans l'ordre de la série, tu l'as déjà mis de côté.
C'est voulu. Lovable est un outil de prototypage rapide : tu décris ce que tu veux construire en langage naturel, il génère une interface fonctionnelle en quelques minutes. Pas besoin de comprendre le code qu'il produit. Pas besoin de savoir ce qui se passe dessous. Tu vois quelque chose à l'écran, tu peux cliquer dessus, tu peux montrer ça à quelqu'un.
J'ai utilisé Lovable pour la première version de Pimpela. Littéralement la première : une interface qui ressemblait à ce que j'avais en tête, avec des boutons qui faisaient des choses, générée en une après-midi. Ça m'a permis de vérifier que l'idée tenait debout avant d'investir du temps dans quelque chose de plus solide. C'est exactement pour ça qu'il existe.
Mais Lovable a une limite claire : tu ne contrôles pas ce qu'il produit. Le code généré t'appartient, mais tu ne l'as pas écrit, tu ne le comprends pas vraiment, et quand tu veux modifier quelque chose de précis, tu te retrouves à négocier avec l'outil plutôt qu'à travailler directement. Pour prototyper, c'est parfait. Pour construire quelque chose qu'on va faire évoluer dans le temps, ça devient vite inconfortable.
Lovable a rempli son rôle. Il t'a donné le premier geste, la première victoire. On passe à autre chose.
Cursor : l'endroit où tu vis avec ton code
Cursor est un éditeur de code. C'est là que le code existe, que tu le lis, que tu le modifies, que tu comprends ce qui se passe.
Dis-le comme ça, ça semble simple. En pratique, la première fois qu'on ouvre Cursor sur un projet réel, on voit une arborescence de fichiers sur la gauche, du code au centre, et on se demande par où commencer. J'ai eu cette sensation plusieurs fois, y compris sur des projets que j'avais moi-même commencé à construire. Le code qu'on écrit (ou qu'on fait écrire) s'accumule vite, et naviguer dedans demande de l'habitude.
Ce qui distingue Cursor d'un éditeur classique, c'est qu'il intègre une assistance IA directement dans l'interface. Tu peux sélectionner un bloc de code, poser une question dessus, demander une modification. L'IA répond dans le contexte de ce que tu regardes, pas dans le vide. C'est la différence entre appeler quelqu'un qui voit ton écran et appeler quelqu'un à qui tu dois tout décrire par téléphone.
Mais Cursor reste un outil de navigation et d'édition. Tu y passes du temps parce que c'est là que le travail se fait, pas parce qu'il génère quelque chose à ta place. Quand je travaille sur Ask Aurelia, je passe la majorité de mes sessions dans Cursor : j'ouvre les fichiers, je lis ce qui existe, je fais des modifications, je vérifie que ça tient. C'est mon poste de travail.
Claude Code : le collègue qu'on appelle quand on bloque
Claude Code, c'est différent. On ne l'ouvre pas pour travailler. On l'appelle pour réfléchir.
La distinction est importante. Il y a quelques semaines, je bloquais sur un problème de logique dans Ask Aurelia : une fonction qui devait comparer deux listes de données et renvoyer uniquement les éléments qui correspondaient à certains critères. Je savais ce que je voulais obtenir. Je ne savais pas comment l'écrire. J'avais essayé deux approches dans Cursor, les deux ne donnaient pas ce que j'attendais.
J'ai ouvert Claude Code dans le terminal, j'ai décrit le problème, j'ai collé le code qui ne marchait pas, et on a travaillé dessus ensemble. Pas une fois : plusieurs échanges, avec des reformulations de ma part, des suggestions de sa part, des tests, des corrections. À la fin, j'avais une solution que je comprenais, pas juste du code qui marchait.
C'est ça, Claude Code : un dialogue. Tu poses un problème, il propose une piste, tu testes, tu reviens avec ce que tu as observé, il ajuste. Le mode conversationnel est au coeur de son utilité. Ce n'est pas un générateur de code, c'est un interlocuteur.
Node.js, lui, n'est pas un outil que tu utilises directement. C'est ce qui fait tourner Claude Code en coulisse, l'environnement d'exécution qui lui permet de fonctionner sur ton ordinateur. Tu l'as installé parce qu'il le fallait, et tu n'as probablement pas besoin d'y penser davantage pour l'instant.
Ce que tu n'as pas encore mais qui arrive
Tu as la base. Mais une application qui fonctionne vraiment dans le monde réel a besoin de deux choses supplémentaires que tu n'as pas encore touchées.
Supabase : là où les données vivront
Quand une application fait quelque chose d'utile, elle stocke des données. Les préférences d'un utilisateur, les résultats d'une recherche, l'historique d'une conversation. Ces données doivent vivre quelque part, dans une base de données, accessible en permanence, pas seulement sur ton ordinateur.
Supabase est la solution qu'on va utiliser pour ça. C'est un service de base de données en ligne, avec une interface qui permet de voir et de gérer les données sans avoir à écrire des requêtes complexes. Tu n'as pas encore besoin de comprendre comment ça fonctionne. Juste de savoir que ça arrive, et à quoi ça sert.
Git et GitHub : la mémoire de ce que tu construis
Quand tu travailles sur un projet qui évolue dans le temps, tu as besoin d'une mémoire. Pas juste la dernière version de ton code : l'historique de toutes les versions, avec la possibilité de revenir en arrière si tu casses quelque chose.
Git est le système qui gère cet historique sur ton ordinateur. GitHub est le service en ligne qui le stocke et te permet d'y accéder depuis n'importe où. Ensemble, ils font office de filet de sécurité : tu peux avancer sans avoir peur de perdre ce qui marchait avant.
C'est l'article suivant. Et après ça, on parlera de mise en ligne.
La stack, ou comment des outils deviennent un système
Il y a un moment, dans le développement d'un projet, où tu arrêtes de voir une liste d'outils et tu commences à voir quelque chose qui s'articule. Les outils se passent le relais. L'un génère, l'autre édite, le troisième dialogue, le quatrième stocke. Chacun a une place, et la place de chacun a du sens par rapport aux autres.
C'est ce qu'on appelle une stack. Pas un terme technique compliqué : juste un mot pour dire que ces outils ne sont pas indépendants, qu'ils forment un système.
Pour moi, ce moment a eu lieu un dimanche après-midi, sur Ask Aurelia. Je travaillais dans Cursor, je bloquais sur quelque chose, j'ai ouvert Claude Code pour débloquer, j'ai testé la solution, ça marchait, j'ai sauvegardé. Et j'ai réalisé que je venais de faire quelque chose de fluide : passer d'un outil à l'autre sans friction, parce que je savais ce que chacun faisait là.
Tu n'en es peut-être pas encore là. C'est normal. La carte que tu as maintenant, c'est déjà beaucoup. Lovable pour prototyper vite et vérifier une idée. Cursor pour vivre dans le code et le modifier. Claude Code pour débloquer les moments où on ne sait plus quoi faire. Supabase et Git qui arrivent pour que ce que tu construis puisse exister dans le monde réel.
Ce ne sont pas des outils que tu as choisis un par un après une analyse comparative. Tu les as rencontrés parce que c'était le bon moment pour les rencontrer. Et maintenant que tu sais ce qu'ils font, tu peux commencer à les utiliser avec intention.