Comment j'optimise mes appels API en React

Quand on débute en React, on apprend à faire un appel API, attendre la réponse, et afficher le résultat. Ça marche. Mais dès qu'on travaille sur une vraie application avec de vrais utilisateurs, on découvre vite que "ça marche" ne suffit pas.

Cet article explique les techniques que j'utilise au quotidien sur mes projets — iValid, HollyFork, Oyko — pour rendre l'interface fluide et réactive. Pas besoin d'être un expert : je pars du problème concret, j'explique l'idée avec une analogie, et je montre comment ça s'applique dans un vrai projet.

C'est quoi le problème, au juste ?

Imaginons un scénario simple. Vous êtes technicien terrain chez iValid. Vous ouvrez l'app, vous regardez votre planning du jour, vous cliquez sur un rendez-vous pour voir les détails du client, puis vous revenez au planning.

Voici ce qui se passe avec une approche classique :

Le planning se recharge à chaque fois, même si rien n'a changé depuis 30 secondes. L'utilisateur attend. Il attend souvent. Il finit par trouver l'app lente.

Maintenant, voici le même scénario avec les optimisations qu'on va voir :

Même nombre d'appels API. Même serveur. Mais l'expérience est radicalement différente.

La stack que j'utilise (et pourquoi)

Avant de plonger dans les techniques, voici les outils que j'utilise sur tous mes projets :

TanStack Query (aussi appelé React Query) remplace le classique fetch + useState + useEffect. Pourquoi ? Parce qu'il gère automatiquement le cache, les retry, la déduplication, et toutes les techniques qu'on va voir. Sans lui, il faudrait coder tout ça à la main.

Zod vérifie que les données qu'on reçoit sont bien au format attendu. TypeScript vérifie les types quand on écrit le code, mais Zod les vérifie quand l'app tourne — essentiel quand on dépend d'APIs externes.

Technique 1 : le cache intelligent (Stale-While-Revalidate)

L'analogie

Imaginez un tableau d'affichage dans un restaurant. Le chef affiche les réservations du jour chaque matin. Quand un serveur passe devant, il lit le tableau instantanément — pas besoin d'aller en cuisine demander.

Mais les réservations peuvent changer en cours de journée. Alors de temps en temps, le chef met à jour le tableau en arrière-plan, sans que les serveurs n'aient à attendre.

C'est exactement le principe du stale-while-revalidate :

En pratique sur HollyFork

Le dashboard du restaurateur affiche 4 métriques : CA du jour, marge brute, couverts, alertes stock. Sans cache, à chaque navigation vers le dashboard, 4 loaders tournent pendant que les données se chargent.

Avec le stale-while-revalidate, le restaurateur voit ses chiffres instantanément dès la deuxième visite. En arrière-plan, l'app vérifie si les chiffres ont changé et met à jour silencieusement si c'est le cas.

Résultat : 90% des visites au dashboard n'ont aucun loader.

Technique 2 : le prefetching (charger avant le clic)

L'analogie

Vous êtes dans un restaurant. Un bon serveur ne vous apporte pas la carte quand vous la demandez — il la dépose sur la table quand il vous installe. Quand vous êtes prêt à commander, la carte est déjà là.

Le prefetching, c'est la même idée : charger les données avant que l'utilisateur n'en ait besoin.

En pratique sur iValid

Le module de réservation fonctionne avec un scroll horizontal de dates. L'utilisateur regarde les créneaux du vendredi 20 mars. Pendant ce temps, l'app charge déjà les créneaux du lundi 23 en arrière-plan. Le schéma ci-dessus montre exactement ce mécanisme : le jour affiché est en bleu, le jour suivant se précharge en arrière-plan (bordure pointillée), et quand l'utilisateur swipe, tout s'affiche instantanément.

L'utilisateur a l'impression que tout est chargé depuis le début. En réalité, l'app a toujours un coup d'avance.

Technique 3 : les optimistic updates (agir avant la réponse)

L'analogie

Vous êtes au comptoir d'une boulangerie. Vous demandez un croissant. Le boulanger ne va pas attendre que la caisse enregistre la vente pour vous tendre le croissant — il vous le donne tout de suite, et encaisse après. Dans 99% des cas, tout se passe bien. Si la carte est refusée, il reprend le croissant.

L'optimistic update, c'est la même idée : on met à jour l'interface immédiatement, et le serveur confirme en arrière-plan.

En pratique sur iValid et HollyFork

Sur iValid, quand un client réserve un créneau, l'interface réagit instantanément. Le créneau se colore, le bouton change, le message de confirmation apparaît — tout ça avant que le serveur ait répondu. Le taux de succès est de 98%, donc dans l'énorme majorité des cas, l'utilisateur gagne 500ms de fluidité.

Sur HollyFork, c'est le plan de salle qui en bénéficie le plus. Le restaurateur déplace une table, change son statut (libre → occupée), modifie les couverts — chaque action est visuelle et instantanée. Le serveur synchronise en arrière-plan.

Attention : je n'utilise jamais d'optimistic update pour les paiements ou les suppressions définitives. Pour ces actions, un loader de confirmation est préférable — l'utilisateur doit savoir que c'est vraiment fait.

Technique 4 : la validation Zod (ne jamais faire confiance)

L'analogie

Imaginez que vous recevez un colis. L'étiquette dit "lampe de bureau". Vous pourriez le ranger directement dans votre salon. Ou vous pourriez l'ouvrir et vérifier que c'est bien une lampe et pas un vase.

Zod, c'est le moment où vous ouvrez le colis. On vérifie que les données reçues correspondent bien à ce qu'on attend avant de les utiliser dans l'application.

En pratique sur mes projets

Sur iValid, on intègre 15 APIs externes (Zoho CRM, Google Calendar, Stripe, Microsoft 365...). Chaque API a ses propres formats et ses propres manières de casser sans prévenir.

Un jour, Zoho CRM a changé le format d'un champ date dans sa réponse. Sans validation, l'app aurait planté chez tous les utilisateurs en affichant un écran blanc. Avec Zod, l'erreur a été attrapée à l'entrée, loggée proprement, et l'utilisateur a vu un message explicite au lieu d'un crash.

Sur Oyko, la validation est encore plus critique : on manipule des données bancaires. Un montant qui arrive comme texte au lieu d'un nombre, un IBAN mal formaté — Zod vérifie chaque champ avant qu'il n'entre dans l'application. En finance, une erreur de format peut avoir des conséquences réelles.

La règle : faire confiance à son propre code, jamais aux données externes.

Technique 5 : le debouncing (ne pas mitrailler le serveur)

L'analogie

Vous tapez un message à un ami. Vous n'envoyez pas une lettre à chaque mot — vous attendez d'avoir fini votre phrase. Le debouncing, c'est pareil : on attend que l'utilisateur ait fini de taper avant d'envoyer la requête.

En pratique

Sur iValid, la recherche d'adresses utilise Google Places Autocomplete — une API facturée à l'usage. Sans debounce, taper "12 rue de la Paix Paris" générerait 25 appels. Avec un debounce de 300ms, on tombe à 3-4 appels. Même expérience pour l'utilisateur, 80% de coûts en moins.

Sur HollyFork, même logique pour la recherche dans le catalogue fournisseurs et la recherche de recettes.

Technique 6 : l'invalidation granulaire (ne pas tout recharger)

L'analogie

Quand vous changez l'ampoule du salon, vous ne coupez pas le courant de toute la maison. Vous coupez juste l'interrupteur du salon.

Quand une donnée change dans l'app, on ne recharge pas tout le cache — on invalide uniquement ce qui a changé.

Ça paraît simple, mais ça demande de bien structurer ses données dès le départ. Chaque type de donnée a une "clé" organisée du général au spécifique. Quand on invalide, on peut cibler précisément ce qui doit être mis à jour.

Récap : par où commencer ?

Si vous débutez et que vous voulez améliorer l'UX de votre app, voici l'ordre que je recommande — du plus gros impact au plus fin :

Ce que je retiens

Après avoir appliqué ces techniques sur iValid (15 APIs, rendez-vous terrain), HollyFork (dashboard restaurant, plan de salle) et Oyko (données bancaires), voici ma conviction :

L'optimisation des appels API, c'est pas un sujet "performance". C'est un sujet UX.

Un utilisateur ne sait pas ce qu'est un cache ou un prefetch. Mais il sait quand une app est rapide. Il sait quand un clic répond immédiatement. Il sait quand il n'attend pas.

L'objectif n'est pas d'avoir zéro appel réseau. C'est que l'utilisateur ne sente jamais le réseau.