Vibe coding : organiser vos projets et side projects dans Notion
Vibe coding et Notion : garder la mémoire de vos projets d’app, des idées au journal de build, pour ne plus jamais perdre la version qui marchait.
Pour suivre un projet vibe codé dans Notion, il faut garder hors de l’outil qui code ce que l’IA oublie d’une session à l’autre : les idées triées, les fonctionnalités avec leurs critères et leur prompt, les décisions prises, un journal de chaque session de build et les bugs jusqu’à leur cause. Cinq bases reliées suffisent pour un développeur solo.
Le vibe coding, terme lancé par Andrej Karpathy en février 2025, consiste à construire une application en décrivant ce qu’on veut à une IA, dans Lovable, Bolt, Cursor ou Claude Code, plutôt qu’en écrivant le code soi-même. Les premières heures sont grisantes. Puis l’application grossit, et le projet commence à vous échapper.
Ce guide montre comment reprendre la main avec Notion, à partir de la structure que j’ai construite pour VibecodingOS.
Pourquoi un projet vibe codé finit par déraper
Un outil de vibe coding garde le code, pas le projet. D’une session à l’autre, il ne se souvient pas toujours de ce qui a été décidé, de ce qui a été testé, ni de la version qui marchait avant la dernière modification. Ce contexte, c’est à vous de le tenir.
Les symptômes sont toujours les mêmes :
- Une fonctionnalité qui en casse une autre, sans qu’on sache depuis quand.
- Des décisions refaites : l’IA propose de changer la base de données que vous aviez choisie pour une bonne raison, oubliée depuis.
- Des idées partout : dans les notes du téléphone, dans le chat de l’outil, dans un fichier texte.
- Aucune version de repli : quand tout casse, impossible de dire quelle était la dernière version stable.
Notion ne code pas à votre place. Il garde la mémoire du projet, celle que vous recopiez ensuite dans vos prompts.
Les 5 bases d’un suivi de projet vibe codé
Pour un projet solo, cinq bases font l’essentiel. Elles sont reliées à une page par application, qui porte son contexte.
1. Idées et irritants
Tout ce que vous voulez construire, et surtout ce dont vos utilisateurs se plaignent, noté avec leurs mots. C’est la réserve du projet, pas la liste des choses à faire.
2. Fonctionnalités, avec leur prompt
Une page par fonctionnalité, avec ses critères d’acceptation (ce qui doit marcher pour qu’elle soit finie) et le prompt qui la décrit à l’IA. Écrire le prompt dans Notion, et non directement dans l’outil, permet de le relire, de l’améliorer et de le réutiliser si la session part de travers.
3. Décisions
Les choix qui engagent la suite : la base de données, le mode de connexion, le prestataire de paiement. Une ligne par décision, avec sa raison. Quand l’IA propose de tout changer, vous avez la réponse sous la main, et vous pouvez la coller dans le prompt.
4. Journal de build
Une entrée par session avec votre outil : ce qui a été demandé, ce qui a changé, et si la version obtenue est stable. C’est la base qui manque à presque tout le monde, détaillée plus bas.
5. Recette et retours
Un scénario de test par critère d’acceptation, coché à chaque version, et les bugs signalés, suivis jusqu’à leur cause. Une fonctionnalité n’est finie que quand sa recette passe.
Le journal de build : la base qui manque à tout le monde
Le journal de build est l’information que l’outil de vibe coding ne vous donne pas de façon lisible : l’historique du projet, session par session. En construisant VibecodingOS, je l’ai jugée indispensable, parce que c’est elle qui permet de revenir en arrière.
Chaque entrée tient en quelques propriétés :
- La date et l’outil utilisé : Lovable, Bolt, Cursor, Claude Code.
- La fonctionnalité travaillée, en relation.
- Ce qui a changé, en deux ou trois lignes.
- Une case « Version stable », cochée seulement si la recette passe.
Le jour où une modification casse tout, une vue filtrée sur « Version stable » vous dit où revenir. Et quand vous changez d’outil, de Lovable vers Cursor par exemple, le journal suit le projet : il ne dépend d’aucun outil.
Trier ses idées de side projects
Quand construire une application ne prend plus que quelques soirées, le risque change : ce n’est plus de ne rien lancer, c’est d’en lancer trop. Un tracker d’idées évite de commencer un nouveau projet chaque semaine.
Une base « Idées » avec trois notes suffit :
- La valeur : à quel point le problème est réel, pour vous ou pour d’autres.
- L’effort : le temps estimé avant une première version utilisable.
- L’envie : un side project tient sur la durée parce qu’il vous plaît.
Une formule combine les trois, la vue se trie dessus. Règle simple : un seul projet en cours à la fois, les autres attendent dans la base. Pour des projets plus structurés, le score RICE est expliqué dans le backlog produit dans Notion.
Une roadmap pour un développeur solo
Un développeur solo n’a pas besoin d’une roadmap de grande équipe. Trois colonnes suffisent : Maintenant, ce qui est en cours ; Ensuite, les deux ou trois prochaines fonctionnalités ; Plus tard, tout le reste. Dans Notion, c’est une vue Kanban de la base des fonctionnalités, groupée par horizon.
Ce découpage évite le piège classique du projet solo : travailler sur la fonctionnalité amusante plutôt que sur celle qui rend l’application utilisable. Le principe du Kanban dans Notion s’applique tel quel.
Les bons réflexes pour garder la main
- Une fonctionnalité par session. Demander trois changements d’un coup rend impossible de savoir lequel a cassé quoi.
- Le prompt avant la session. Écrit dans la page de la fonctionnalité, avec les critères et les décisions qui la concernent.
- La recette après chaque session. Pas à la fin du projet : à chaque version, sur les fonctionnalités déjà finies.
- Le contexte du projet en un endroit. Une page par application qui résume la pile technique, le modèle de données et les règles, à coller en début de session.
Partir d’un template
Si vous voulez cette structure sans la construire, VibecodingOS l’installe dans Notion : une fiche par application avec son contexte pour l’IA, les irritants, les chantiers classés par score RICE, le modèle de données, les décisions, les stories avec leur prompt, le journal de build, la recette, les retours et incidents, et les indicateurs. Il vous suit de Lovable à Cursor ou Claude Code.
Questions fréquentes
Qu’est-ce que le vibe coding ?
C’est le fait de construire une application en décrivant ce que l’on veut à une IA, plutôt qu’en écrivant le code soi-même. Le terme a été lancé par Andrej Karpathy en février 2025. Des outils comme Lovable, Bolt, Cursor ou Claude Code génèrent et modifient le code à partir de ces descriptions.
Pourquoi utiliser Notion quand on vibe code ?
Parce que l’outil de vibe coding garde le code, pas le projet. Notion garde ce qui doit survivre d’une session à l’autre : les décisions, les critères de chaque fonctionnalité, les prompts, l’historique des versions stables et les bugs. Ce contexte se recopie ensuite dans les prompts.
Comment suivre un side project dans Notion ?
Avec une base d’idées triées par valeur, effort et envie, une base de fonctionnalités avec leurs critères, et une vue Kanban en trois colonnes : maintenant, ensuite, plus tard. Un seul projet en cours à la fois, les autres attendent dans la base d’idées.
Qu’est-ce qu’un journal de build ?
C’est une base où chaque session de travail avec l’outil de vibe coding laisse une entrée : la date, l’outil, la fonctionnalité travaillée, ce qui a changé et si la version obtenue est stable. Quand une modification casse l’application, il indique la dernière version à laquelle revenir.
Existe-t-il un template Notion pour le vibe coding ?
VibecodingOS est un template Notion conçu pour les applications vibe codées : contexte de chaque application pour l’IA, stories avec leur prompt, décisions, journal de build, recette, retours et indicateurs. Il fonctionne quel que soit l’outil qui code, de Lovable à Claude Code.