La logique derrière le choix d'un stack n'est pas la même. Voici comment j'aborde ça en tant que dev freelance, avec des exemples concrets et mon stack de référence.
Un projet client et un projet perso, c'est pas le même sport.
J'ai longtemps appliqué la même logique aux deux. J'utilisais ce qui m'intéressait, ce qui était hype, ce que j'avais envie de tester. Et j'ai vite appris à mes dépens que ça ne marche pas comme ça. Choisir un stack, c'est avant tout une question de contexte, d'objectif et de risque.
Dans cet article, je te partage mon avis perso sur comment j'aborde le choix du stack selon que je travaille pour un client ou sur mes propres projets. Tu vas voir que la logique derrière est vraiment différente, et que confondre les deux peut te coûter cher.
Avant de parler d'outils, il faut qu'on soit d'accord sur un truc : un projet client et un projet perso n'ont pas les mêmes contraintes.
Un projet client, c'est :
Un projet perso, c'est :
Ces deux mondes ont des règles totalement différentes. Et le stack que tu choisis doit refléter ça.
Sur un projet client, mon premier critère c'est la prévisibilité. Je veux savoir ce qui va se passer à chaque étape.
Ce n'est pas le moment de découvrir un nouveau framework. Si tu es à l'aise avec Next.js + Prisma + base de données postgres, c'est ça que tu utilises. Point.
Tu vas aller plus vite, faire moins d'erreurs et livrer quelque chose que tu peux défendre.
Règle d'or : Un projet client n'est pas un terrain d'entraînement. Tu utilises ce que tu connais, pas ce qui te fait envie.
Voici ce que j'utilise par défaut sur la grande majorité de mes missions :
| Couche | Choix |
|---|---|
| Frontend | Next.js (App Router) |
| UI | Tailwind CSS + shadcn/ui |
| Base de données | PostgreSQL + Prisma |
| Auth | BetterAuth |
| Déploiement | Vercel ou VPS |
| Paiement | Stripe |
Ce stack, je le connais par coeur. Je sais où ça coince, je sais comment déboguer, je sais comment déployer. Et surtout, je sais livrer dans les temps.
Chaque année, un nouveau méta-framework sort et tout le monde s'emballe. Remix, SvelteKit, Qwik... Ces outils peuvent être excellents, mais si tu les découvres sur un projet client, tu vas passer plus de temps à lire la doc qu'à coder.
Attention : ça ne veut pas dire qu'il faut rester figé. Ça veut dire que tu testes d'abord sur tes projets perso, et que tu intègres ensuite progressivement sur les clients une fois que tu es à l'aise.
Là c'est l'inverse total. Mes projets perso, c'est mon terrain de jeu. Je teste des trucs qui me font envie, même si c'est pas encore stable.
Je ne lis pas des tutos pour apprendre. Je construis quelque chose. Et les projets perso sont l'endroit parfait pour ça.
C'est comme ça que j'ai appris à utiliser n8n pour l'automatisation, que j'ai expérimenté avec les LLMs en local, que j'ai bossé sur des architectures de type AI agent... Aucun client ne m'aurait laissé faire ça directement en prod.
Deux outils que mes projets perso m'ont vraiment permis de creuser : Convex et Supabase.
Convex, c'est un backend as a service "full-stack" pensé pour les devs JS/TS. Tu définis tes fonctions directement en TypeScript, et Convex gère la base de données, les queries en temps réel, les mutations et même les jobs en arrière-plan. Pas de REST à écrire, pas d'ORM à configurer, pas de serveur à gérer.
Ce qui m'a accroché sur Convex :
Supabase, c'est une autre bête. C'est l'alternative open-source à Firebase, construite sur PostgreSQL. Tu as la base de données, l'auth, le storage et même des edge functions, tout dans une seule interface.
Ce qui m'a convaincu sur Supabase :
Les deux répondent à des besoins différents. Convex brille sur les apps temps réel. Pour Supabase : PostgreSQL et SQL standard, tout le monde connaît, tout le monde peut maintenir. Aujourd'hui je sais exactement lequel sortir selon le projet, et c'est uniquement parce que je les ai testés sur mes propres trucs d'abord.
Ce que j'ai mis en place personnellement, c'est un flux assez simple :
1. Je repère un outil intéressant
Je lis un article, je vois une démo, un collègue m'en parle. Je note.
2. Je l'intègre dans un projet perso
Je construis quelque chose de petit mais de concret avec. Un side project, un outil interne, n'importe quoi qui me force à vraiment l'utiliser.
3. J'évalue après quelques semaines
Est-ce que c'est stable ? Est-ce que la DX est bonne ? Est-ce que je pourrais l'expliquer à un junior ? Si oui, il rentre dans mon stack "client" potentiel.
4. Je l'introduis progressivement chez les clients
D'abord sur un projet peu critique, avec un client tech-friendly. Puis de façon plus large une fois que j'ai du recul.
Ce cycle prend du temps, mais il évite de se planter sur des missions importantes.
| Critère | Projet client | Projet perso |
|---|---|---|
| Priorité | Fiabilité, délai, maintenabilité | Apprentissage, expérimentation |
| Stack | Maîtrisé, éprouvé | Nouveau, en cours d'exploration |
| Tolérance au bug | Faible | Haute |
| Objectif | Livrer ce qui a été promis | Comprendre, tester, construire |
| Innovation | Après validation perso | Oui, librement |
Choisir un stack, c'est avant tout choisir selon le contexte. Ni trop conservateur pour ne jamais progresser, ni trop aventureux pour ne jamais livrer.
Mes projets perso m'ont permis de construire un stack client solide et différenciant. Et mon stack client me permet de financer les projets perso où j'expérimente sans filet.
Les deux se nourrissent mutuellement. C'est ça le vrai game.
Si tu veux challenger tes choix techniques avant de les sortir sur un projet critique, viens m'en parler directement sur LinkedIn. Je suis toujours curieux de découvrir de nouveaux workflows et d'échanger sur ce qui marche (ou pas).