Ma Stack

Ma page /about liste ce que j’utilise. Cette page explique pourquoi. Je privilégie la simplicité, les surfaces réduites, et les outils qui me laissent livrer sans me battre contre le framework. Je préfère utiliser une technologie ennuyeuse qui marche plutôt que courir après la nouveauté tous les trimestres.

Langage : TypeScript

TypeScript partout : front-end, back-end, scripts, outillage. Partager les types de la base de données jusqu’à l’UI élimine toute une catégorie de bugs avant la mise en production.

Et TypeScript 7, le port natif du compilateur en Go, vient de sortir : mêmes sémantiques de type-checking, des builds environ 10× plus rapides.

Framework : Next.js, TanStack Start, Hono

Next.js est mon choix par défaut depuis des années. L’App Router, les server components, et l’écosystème Vercel font que c’est difficile à battre pour les sites riches en contenu et les produits SaaS. Ce site tourne dessus.

Pour les nouveaux projets qui ne sont pas statiques, je m’oriente vers TanStack Start. Du TypeScript full-stack sans les opinions que Next.js impose. C’est plus récent, plus brut de décoffrage, mais les primitives sont solides et la direction me semble être la bonne.

Hono pour les API et les services légers. Rapide, tourne partout (Cloudflare Workers, Bun, Node), et le système de middleware est propre.

Vous remarquerez que TanStack revient souvent sur cette page (Start, Query, Form). Il y a très peu de gens dans l’écosystème que je respecte autant que Tanner Linsley, Dominik Dorfmeister et Jack Herrington. La qualité et la régularité de ce qu’ils produisent alliée à la pédagogie avec laquelle ils partagent leur savoir est rare.

Styling : Tailwind + shadcn/ui

J’ai longtemps été un adepte de Styled-components, et j’ai même co-créé une librairie compatible avec styled-system. Mais Tailwind m’a convaincu. Le compilateur JIT, l’universalité entre frameworks, et pour les workflows de composants avancés, CVA (Class Variance Authority) font qu’on ne revient pas en arrière. La vitesse d’itération est d’un autre niveau, et le système de contraintes empêche le CSS de pourrir avec le temps.

shadcn/ui par-dessus me donne des composants accessibles et bien construits que je possède et que je peux modifier. Pas de dépendance à mettre à jour, pas de breaking changes à suivre. Copier, coller, adapter.

Design : Figma

J’ai toujours eu tendance à designer directement en CSS, et les LLM n’ont fait qu’empirer les choses. Ou les améliorer ? Mais pour tout ce qui demande un vrai travail de craft (espacement, rythme visuel, ajustement des détails), c’est quand même plus simple de travailler dans un vrai outil de design. Figma, c’est cet outil.

Hébergement : Vercel, Netlify, Railway

L’essentiel de ce que je livre est hébergé sur Vercel. La DX est la meilleure que j’ai utilisée pour des projets Next.js, et je mentirais si je disais le contraire. Je ne suis pas entièrement à l’aise, cela dit, avec certaines positions politiques prises et affichées par ses dirigeants, que ce soit via des tweets ou des selfies. Ce n’est pas une question de vendor lock-in ou de Next.js bashing, c’est juste un sentiment qui ne passe pas.

Netlify a une place particulière pour moi. Mathias Biilmann et son équipe ont porté le Jamstack, qui a été mon cheval de bataille pendant des années. Je n’y ai rien déployé depuis un moment, mais j’aimerais trouver une raison d’y revenir.

Railway pour tout ce qui a besoin d’un serveur persistant : bots Discord, workers en arrière-plan, ou orchestration de plusieurs services interdépendants.

Pour les bases de données : Neon quand j’ai besoin de Postgres, Turso sinon. Turso est construit sur libSQL, un fork open-source de SQLite avec réplication native sur les edge locations.

ORM : Prisma, Drizzle

Prisma a été mon choix par défaut pendant des années. Des migrations solides, un bon workflow schema-first. Mais lourd. Le client généré est volumineux et les cold starts en serverless m’agacent.

Drizzle, c’est là où je me dirige. Plus proche du SQL, plus léger, et si vous démarrez quelque chose de nouveau aujourd’hui, utilisez Drizzle.

Auth : Better Auth

L’auth, c’est un de ces trucs qu’on ne devrait presque jamais construire from scratch.

Better Auth est la meilleure chose qui soit arrivée à l’auth depuis Auth.js : meilleure documentation, meilleures fonctionnalités, et vous possédez toujours les données de vos utilisateurs. Ce dernier point, c’est la raison pour laquelle je n’arrive pas à me résoudre à utiliser des solutions managées comme Clerk ou WorkOS pour le SAML/SSO. Je comprends pourquoi les gens le font, et la DX est bonne. Mais ne pas posséder ma table utilisateurs, c’est un compromis que je refuse de faire.

Validation : Zod, TanStack Form

Zod partout. Inputs d’API, variables d’environnement, validation de formulaires. Il se branche sur tout ce que j’utilise (tRPC, TanStack Form, Payload) et l’inférence TypeScript fonctionne sans effort. Pas grand-chose d’autre à dire.

TanStack Form pour les formulaires. J’ai utilisé React Hook Form pendant des années, je passe à autre chose. TanStack Form est contrôlé par design : état prévisible, fonctionne en dehors du DOM (React Native, Three.js), plus facile à tester. L’approche non-contrôlée de RHF était maline, mais le contrôlé gagne quand on a besoin de vraiment comprendre ce qu’il se passe.

Data flow : tRPC, server actions

TanStack Query pour le data fetching côté client. Il prend en charge le cache, le refetching et le stale-while-revalidate, toute cette plomberie que personne ne devrait écrire à la main (à part ses contributeurs, bien sûr).

tRPC pour la type safety entre client et serveur. Renommer un champ dans un router, et le front-end passe au rouge immédiatement, sans étape de codegen ni fichier de schema à synchroniser.

Les server actions pour les mutations plus simples où tRPC serait overkill. J’ai moins confiance qu’avant. L’écosystème ne semble pas se rallier pleinement derrière elles, et la vulnérabilité React2Shell (CVE-2025-55182, CVSS 10.0 RCE) n’a pas aidé. Les divulgations suivantes ont aggravé les choses. Elles réduisent toujours le boilerplate, mais je n’ai encore rien sorti en production qui les utilise.

Email : Resend

Resend. Construire des templates d’email en JSX avec React Email au lieu de se battre avec du HTML à base de tableaux datant de 2003. Ils traitent aussi les agents comme des citoyens de première classe avec un serveur MCP et la gestion des emails entrants. Fait une chose, la fait bien.

CMS : Payload

Payload. Code-first, tourne sur Next.js, panel d’admin généré depuis la config. Drizzle sous le capot, Zod pour la validation. Ça s’emboîte dans tout le reste de cette page.

Gestion de tâches

Je déteste Jira du plus profond de mon être. J’adore Linear de tout mon cœur, mais en solo, c’est parfois un peu much. Ces temps-ci, mon backlog vit dans beads, un issue tracker stocké dans git et pensé pour les agents de code. Un candidat naturel pour la boucle Ralph Wiggum.

AI SDK

AI SDK est d’une évidence à chaque fois que je m’en sers. J’aurais aimé essayer TanStack AI (vous l’aviez deviné), mais AI SDK 7 rend le choix plus dur à justifier : durabilité, tool approvals, sandboxes… sans le moindre vendor lock-in jusqu’ici.

Plus sur mon utilisation de l’IA sur la page /ai, et mon outillage LLM sur /uses.