Un développeur a passé deux semaines à remplacer une API REST par tRPC dans un outil interne.

Pourquoi ce changement était important

L'ancienne pile technologique nous obligeait à maintenir un DTO, un validateur et un ensemble distinct de types TypeScript pour le frontend. Renommez un champ côté backend, et l'API renvoyait toujours un code 200, l'interface utilisateur continuait de s'afficher, et le bug ne se manifestait que par des valeurs « undefined ». Un client a détecté le problème avant n'importe qui dans l'équipe. Les contrats REST masquaient le problème, et les fichiers supplémentaires ajoutaient une maintenance qui n'en valait jamais la peine.

À quoi ressemblait la configuration REST

  • Spécification OpenAPI – un fichier statique qui décrivait les points de terminaison (endpoints) mais ne servait jamais de source de vérité.
  • Étape de génération du SDK client – un job CI qui produisait un wrapper JavaScript.
  • Collection Postman – un artefact de test partagé que personne n'utilisait.
  • Interfaces TypeScript manuelles – des types écrits à la main qui devaient rester synchronisés avec le serveur.

Chaque modification de l'API touchait au moins trois de ces artefacts, en plus du validateur et de tous les appels fetch en aval. Le processus était lent et sujet aux erreurs.

Comment tRPC a allégé la base de code

tRPC élimine le fichier de contrat séparé. Le serveur exporte un type de routeur ; le client importe ce même type. Renommez un champ côté backend, et l'éditeur signale instantanément l'incohérence — sans exécuter le code, sans avoir besoin d'une requête échouée. Le développeur a supprimé :

  • Le fichier de spécification OpenAPI.
  • L'étape de génération du SDK client.
  • La collection Postman inutilisée.
  • Le dossier des interfaces TypeScript manuelles.

Le dépôt est devenu plus léger, et le feedback est arrivé pendant le développement plutôt qu'après le déploiement.

Limites de tRPC

tRPC ne fonctionne que lorsque les deux extrémités parlent TypeScript. Il montre ses limites si :

  • Une équipe mobile utilise Swift ou Kotlin.
  • L'API doit être consommée par des partenaires externes.
  • Vous avez besoin d'une interface publique et indépendante du langage.

Ce que la migration a réellement nécessité

L'effort de deux semaines était bien plus qu'un simple copier-coller. Le développeur a dû :

  • Réécrire chaque appel fetch pour utiliser les fonctions client de tRPC.
  • Ajuster la logique de gestion des erreurs.
  • Mettre à jour les composants UI qui dépendaient d'états de chargement et de tentatives de reconnexion (retry) liés aux réponses HTTP brutes.

Questions à se poser avant de se lancer

  • Est-ce que le frontend et le backend utilisent tous deux TypeScript ? Sans un système de types partagé, tRPC perd son principal avantage.
  • La même équipe est-elle responsable des deux côtés ? Des lacunes en matière de propriété peuvent réintroduire un décalage des contrats.
  • Réglez-vous un bug concret ou suivez-vous une tendance ? Le gain de productivité est réel, mais il doit résoudre un problème existant.

Une approche hybride pour 2025

De nombreuses équipes trouvent le juste équilibre en utilisant les deux piles :

  • tRPC pour les couches applicatives internes où la base de code est entièrement en TypeScript et où la même équipe possède le serveur et le client.
  • REST pour les webhooks, les API publiques et les intégrations de partenaires où un accès indépendant du langage est requis.

L'utilisation du bon outil pour chaque surface permet de maintenir la rapidité du développement interne tout en préservant l'ouverture nécessaire aux consommateurs externes.

À retenir : Remplacer REST par tRPC peut éliminer la duplication des artefacts de contrat et faire apparaître les bugs dès la phase d'édition, mais les gains ne se concrétisent que lorsque l'ensemble de la pile partage TypeScript et que l'équipe peut absorber le coût de la migration. Une stratégie mixte vous permet de récolter les bénéfices sans exclure les consommateurs n'utilisant pas TypeScript.