Syspirit 
Le point de départ
Depuis que j’ai fini mon blog, Claude Code m’aide aussi à rédiger mes articles. Mais j’avais envie de pousser l’outil beaucoup plus loin. Et ça tombait bien : j’avais un problème que je traînais depuis un moment. Quand je suis sur l’ordi, j’ai souvent besoin de noter rapidement une idée ou une info, sans forcément ouvrir Google Keep ou Apple Notes. J’utilise Obsidian au quotidien mais je le saturais de petites notes éphémères qui n’avaient pas leur place dedans.
Ce que je reproche à la plupart des apps de notes ? Trop de friction. Des tonnes de menus, de features dont je ne me servirai jamais. Moi je voulais un truc simple, rapide, qui fait ce que je lui demande et rien de plus.
C’est comme ça qu’est né assez naturellement Onyka. Une app de notes parmi tant d’autres, mais construite pour répondre exactement à mes besoins. Le twist : je ne suis pas développeur et je n’ai jamais fait ça. Tout a été construit en vibe coding, 100% avec l’IA.
Le vibe coding, c’est quoi ?
Le terme a été popularisé par Andrej Karpathy (cofondateur d’OpenAI) début 2025. L’idée est simple : on décrit ce qu’on veut en langage naturel, et l’IA écrit le code. On ne code pas, on pilote. On donne une direction, on valide le résultat, on corrige le tir si besoin.
Concrètement, ça veut dire que quelqu’un qui n’a jamais touché une ligne de code peut construire une application fonctionnelle. Ce n’est pas de la magie : il faut quand même comprendre ce qu’on demande, savoir formuler ses besoins et être capable de tester ce que l’IA produit. Mais la barrière technique est incomparablement plus basse qu’avant.
Dans mon cas, j’ai utilisé Claude Code pour tout le développement. Je lui décris une feature, il code, je teste, on itère. Le tout dans le terminal, commit par commit.
La méthode
Le plus gros piège quand on ne sait pas dev, c’est de foncer tête baissée. J’ai d’abord passé du temps à poser mon idée à plat : ce que je voulais, comment je le voyais, les features essentielles. Un brouillon complet en langage naturel, rien de technique.
Ensuite j’ai utilisé le skill project-planner que j’ai intégré dans Claude Code. C’est un outil qui génère automatiquement un plan de projet structuré : specs, design technique, découpage en tâches. Ça m’a donné une vraie feuille de route. Claude Code s’est ensuite chargé de chaque tâche, une par une, proprement et en gardant le contexte du projet grâce au plan généré.
Pour l’interface, j’ai ajouté le skill frontend-design qui pousse Claude Code à produire des composants UI plus soignés et moins génériques. Ça change vraiment la donne pour éviter le côté “app générée par une IA” qu’on reconnaît au premier coup d’œil. Pour le logo, j’ai mis les mains dans Figma en fin de projet pour essayer de sortir quelque chose de correct.
Le workflow au quotidien était simple : je lance Claude Code, je décris ce que je veux, il propose, j’ajuste, on commit. Debug après debug, feature après feature.
Onyka, c’est quoi ?
Une application de prise de notes open-source et self-hostable. L’idée c’est d’héberger ses propres données, pas de cloud tiers. Voici les features principales :
Les Sparks : c’est la feature qui change tout pour moi. On tape, on valide, c’est capturé. Pas de titre, pas de dossier. On définit une expiration (1h à 30 jours) ou on garde la note en permanence. On peut en épingler jusqu’à 5 et convertir un spark en note complète quand c’est pertinent. Le reste disparaît tout seul.
L’éditeur riche : basé sur TipTap, avec blocs de code, tableaux, colonnes, images, un slash menu (/) pour tout insérer rapidement, sauvegarde auto et collage Markdown. Chaque note peut contenir plusieurs pages sous forme d’onglets.
La collaboration en temps réel : co-édition via WebSocket à la Google Docs, avec indicateurs de présence, commentaires et trois niveaux de permissions.
Le mode Focus : timer Pomodoro configurable, compteur de mots, suivi des streaks d’écriture et récapitulatif hebdomadaire. La sidebar se masque pour zéro distraction.
La customisation : j’aime beaucoup personnaliser mes outils, donc j’ai poussé ce point. 9 thèmes de base (Dracula, Nord, Tokyo Night, Catppuccin…), 15 couleurs d’accent, 12 polices pour l’éditeur, mode clair/sombre. L’app est aussi bilingue FR/EN et compatible PWA, donc installable et utilisable sur téléphone sans passer par un store.
La stack technique
Je ne suis pas dev, donc le choix de la stack a été en grande partie fait par l’IA. Voici ce qui tourne sous le capot :
| Couche | Technologies |
|---|---|
| Frontend | React 19, Vite 6, Tailwind CSS, Zustand, TipTap 3.19, Framer Motion |
| Backend | Express, Drizzle ORM, SQLite, Socket.io, Zod |
| Sécurité | Argon2 (mots de passe), JWT, chiffrement AES-256-GCM, 2FA TOTP, rate limiting |
| Infra | Docker multi-stage, GitHub Actions, image Alpine non-root |
Pour ne pas avoir une app qui ressemble à toutes les autres, j’ai aussi poussé l’utilisation de librairies qui apportent du caractère : Framer Motion pour les animations fluides, dnd-kit pour le drag & drop dans la sidebar, un hook useSmoothCaret pour un curseur animé dans l’éditeur, et 12 polices @fontsource (Fira Code, Crimson Pro, Space Grotesk…) pour varier les styles.
Les galères et la sécurité
Même avec Claude Code, j’ai galéré sur certaines features. Le drag & drop dans la sidebar a été un enfer à rendre fluide et naturel. L’éditeur aussi : obtenir un rendu agréable avec TipTap demande beaucoup d’ajustements. Et surtout les Sparks, la feature centrale, qui a nécessité énormément d’itérations pour que le comportement soit vraiment celui que j’avais en tête.
La sécurité, c’est le gros point sensible du vibe coding. Quand on ne sait pas dev, on ne sait pas non plus repérer une faille. J’ai essayé d’être le plus strict possible : plusieurs audits de sécurité avec Claude, analyse des CVE des dépendances, chiffrement AES-256-GCM au repos, hachage Argon2 pour les mots de passe, 2FA avec TOTP, rate limiting etc… Est-ce que c’est suffisant ? Honnêtement, je ne sais pas. C’est clairement le point faible de laisser les rênes à l’IA quand on n’a pas le recul d’un dev expérimenté.
Mise en prod
J’ai push en prod via une image Docker publiée sur GitHub Container Registry, avec un docker-compose.yml prêt à l’emploi. J’ai essayé de faciliter l’installation au maximum en respectant les standards de la communauté GitHub et open-source. L’app est hébergée sur mon VPS et je m’en sers au quotidien. On verra vite si elle tient la route. De mon côté, j’ai sécurisé le VPS, ça c’est un peu plus mon domaine !
Mes erreurs et ce que j’en retiens
Soyons honnêtes, j’ai fait pas mal d’erreurs de débutant :
- Perdre du temps sur l’UI/UX alors que les fonctionnalités de base n’étaient pas terminées proprement. Le joli peut attendre, le fonctionnel non.
- Vouloir un outil parfait dès le début au lieu d’oser sortir un MVP, même imparfait.
- Vouloir trop de features dans tous les sens alors que c’est exactement ce que je voulais éviter. J’ai dû en enlever en cours de route.
- Laisser l’IA choisir la stack par défaut sans me renseigner moi-même. Il vaut mieux comprendre un minimum ce qu’on utilise et pourquoi.
Côté positif, ce projet m’a appris pas mal de choses quand même : des notions de dev, une bien meilleure maîtrise de GitHub et de son écosystème, et un peu de design sur Figma. L’exercice était vraiment stimulant.
Conclusion
Il reste sûrement quelques bugs, il faudra que j’utilise l’app plus longuement pour les trouver. Mais le résultat me plaît et me correspond, c’est tout ce que je demandais.
Si ça vous intéresse, Onyka est disponible ici : github.com/karl-cta/onyka. L’app est responsive et compatible PWA, donc utilisable correctement sur téléphone aussi !
Liens utiles :