tRPC : des APIs TypeScript end-to-end sans schéma, sans REST ni GraphQL

Et si votre frontend et votre backend partageaient les mêmes types TypeScript, sans écrire un seul fichier de schéma ni générer de code ? C'est exactement la promesse de tRPC : une bibliothèque légère qui permet de définir vos procédures serveur et de les appeler depuis le client avec une inférence de types complète et automatique. En 2026, tRPC s'est imposé comme l'alternative évidente à REST et GraphQL pour les équipes full-stack travaillant exclusivement en TypeScript.

Le problème que tRPC résout

Avec une API REST classique, la synchronisation des types entre le backend et le frontend est un problème récurrent. Les équipes recourent généralement à OpenAPI avec un générateur de client, ou à GraphQL avec un système de code generation — deux solutions puissantes mais lourdes à mettre en place et à maintenir. Chaque changement de contrat côté serveur demande une étape de génération, une mise à jour du client, et souvent une session de débogage pour retrouver les incohérences. tRPC élimine entièrement ce fossé en exportant directement le type du routeur serveur vers le client, sans aucune génération de code intermédiaire. Le client TypeScript "voit" toutes les procédures disponibles, leurs paramètres d'entrée et leurs types de retour, simplement en important le type du routeur.

Architecture et concepts fondamentaux

tRPC s'articule autour de trois concepts : les procédures, les routeurs et le contexte. Une procédure est l'équivalent d'un endpoint : elle peut être de type query (lecture, comme un GET) ou mutation (écriture, comme un POST/PUT/DELETE). Chaque procédure peut recevoir une entrée validée avec Zod, exécuter de la logique métier, et retourner un résultat typé. Le routeur regroupe ces procédures en arborescence, ce qui permet de les organiser par domaine fonctionnel — exactement comme vous structureriez vos modules Angular ou vos répertoires de services. Le contexte, quant à lui, permet d'injecter des dépendances transversales comme la session utilisateur ou le client Prisma dans chaque procédure, sans les passer explicitement à chaque appel.

Intégration avec Next.js et React Query

L'écosystème tRPC brille particulièrement avec Next.js : le package @trpc/next expose le routeur via une route API Next.js, tandis que @trpc/react-query génère automatiquement des hooks React Query typés pour chaque procédure. Côté client, appeler trpc.user.getById.useQuery({ id: 1 }) retourne un objet avec les propriétés data, isLoading et error entièrement typés, sans une ligne de configuration supplémentaire. Si vous renommez une procédure ou modifiez son type de retour côté serveur, TypeScript signalera immédiatement toutes les utilisations incorrectes dans votre frontend — ce qui transforme les erreurs runtime en erreurs de compilation, bien plus faciles à corriger.

Middlewares, authentification et gestion des erreurs

tRPC propose un système de middlewares composables qui permet d'intercepter les appels de procédures pour ajouter de la logique transversale. Un middleware d'authentification vérifie la session et enrichit le contexte avec l'utilisateur connecté ; les procédures protégées — appelées "protected procedures" — peuvent alors accéder à ctx.user avec la certitude que l'utilisateur est authentifié, car TypeScript le garantit au niveau du type. La gestion des erreurs suit un modèle structuré avec des codes d'erreur prédéfinis (UNAUTHORIZED, NOT_FOUND, BAD_REQUEST…) qui se propagent proprement jusqu'au client et restent exploitables de façon typée. Pour les projets plus ambitieux, tRPC supporte également les subscriptions via WebSocket, ce qui permet de construire des fonctionnalités temps réel avec la même cohérence de types que pour les requêtes HTTP classiques.