Inertia.js v3 (beta) : adieu Axios, SSR plus simple, et des updates optimistes

Inertia v3 (beta) n’est pas une “petite” release. Elle remet à plat trois points qui impactent ton quotidien sur une stack Laravel + Vue/React/Svelte : les requêtes HTTP (bye Axios), le SSR (plus plug-and-play) et les optimistic updates (UX plus réactive, mais avec de nouvelles responsabilités).

Dans cet article, je ne vais pas te refaire la doc. Je vais te donner un plan de migration pragmatique, les diffs à anticiper et une checklist pour upgrader sans transformer ton app en chantier.

Ce qui change vraiment dans Inertia v3 (et pourquoi ça compte)

1) Fin d’Axios “par défaut” : tu récupères une stack plus légère

Historiquement, beaucoup de projets Inertia traînaient Axios dans le bundle juste parce que “c’est comme ça qu’Inertia envoie ses visites”. En v3, Inertia ne dépend plus d’Axios : il s’appuie sur des primitives web modernes (Fetch) et son propre mécanisme.

Impact concret :

• Bundle plus simple : moins de dépendances et moins de surface de maintenance.
• Plus d’interceptors Axios pour gérer auth, CSRF, logging, refresh token, etc. Il faut déplacer cette logique (soit dans ton propre client fetch, soit via les hooks/events Inertia, soit côté backend).
• Les requêtes “hors Inertia” restent ton sujet : si tu utilises Axios pour tes endpoints API (autocomplete, polling, upload chunk, etc.), tu peux continuer. Inertia v3 ne t’empêche pas d’avoir Axios… il ne l’impose plus.

2) SSR via un plugin Vite : moins de colle, moins de “magic scripts”

Le SSR Inertia a longtemps été le truc “que tu actives, puis que tu oublies jusqu’au jour où ça casse”. La v3 introduit un plugin Vite dédié au SSR Inertia, pour automatiser et standardiser une partie du setup.

Impact concret :

• Setup SSR plus lisible (surtout dans un projet Laravel où Vite est déjà central).
• Moins de configuration artisanale pour la build SSR et le wiring côté Node.
• Moins de divergence entre projets : tu as plus de chances de retrouver la même structure d’un repo à l’autre.

3) Optimistic updates “built-in” : UX plus rapide, mais attention à la cohérence

Les optimistic updates, c’est l’idée de mettre à jour l’UI avant la réponse serveur, puis de confirmer (ou rollback) quand le backend répond. En v3, c’est mieux intégré : tu n’es plus obligé de bricoler ton propre state local pour simuler une interaction instantanée.

Impact concret :

• UX : likes, toggles, “mark as read”, drag-and-drop, todo-check… deviennent instantanés.
• Complexité : tu dois penser “rollback” et “source of truth”. Si le serveur refuse, tu ne peux pas faire semblant.
• Observabilité : tu veux tracer les échecs (réseau, 422, 403) pour ne pas créer de bugs fantômes côté produit.

Plan de migration (Laravel) : la version qui ne te fait pas perdre 2 jours

La bonne stratégie, c’est de migrer en couches : d’abord faire passer la build, ensuite faire passer les flows, et seulement après activer/adapter SSR + optimistic selon ton besoin.

Étape 0 : Pré-check avant l’upgrade

• Tu es sur une base Laravel + Vite propre (pas un mix Vite + anciens scripts).
• Tu sais si tu utilises Inertia en SSR ou non aujourd’hui.
• Tu listes les usages d’Axios : Inertia only ? ou Axios partout (API, interceptors, refresh token) ?
• Tu identifies les écrans critiques : login, paiement, onboarding, CRUD principal.

Étape 1 : Mettre à jour les packages (sans “optimiser” en même temps)

Upgrade Inertia côté frontend (core + adapter Vue/React/Svelte) et le côté Laravel (middleware, etc.) en suivant le guide officiel. L’objectif ici : ça compile, ça navigue.

Astuce de survie : crée une branche dédiée et active des logs plus verbeux en environnement de staging, pas en prod.

Étape 2 : “Adieu Axios” : ce qui casse vraiment dans les apps existantes

Le piège n°1, ce n’est pas Inertia. Ce sont les projets qui avaient branché des comportements globaux dans Axios :

• Headers custom (ex: X-Tenant, X-Feature-Flag, X-Request-Id)
• Gestion centralisée des 401 (logout, refresh token, redirect)
• Instrumentation (Sentry breadcrumbs, timing, logs)

Avec v3, tu as deux voies propres :

• Option A : tu gardes Axios pour tes appels API “hors Inertia”, mais tu n’en dépends plus pour la navigation Inertia. C’est souvent le meilleur compromis en migration.
• Option B : tu centralises sur Fetch (si tu veux vraiment supprimer Axios), et tu remontes tes besoins (headers, 401, logs) via un wrapper fetch interne + hooks Inertia.

Dans tous les cas, arrête de compter sur “les interceptors magiques” pour corriger des problèmes de logique produit. Si ton backend renvoie 401/403/422, traite-le proprement (redirection, toast, invalidation de session) là où ça fait sens.

Étape 3 — SSR : passer à un setup Vite plus standard

Si tu fais du SSR (SEO, perf perçue, partage social, first paint), la v3 te simplifie la vie avec le plugin Vite. Ton objectif : une entrée client + une entrée SSR, et une config Vite lisible.

Exemple de structure (à adapter à ton stack). En beta, les noms exacts de packages/options peuvent évoluer : vérifie le guide officiel avant de copier-coller.

// vite.config.js (exemple de structure)
import { defineConfig } from 'vite'
import laravel from 'laravel-vite-plugin'
// Le plugin Inertia v3 pour SSR est annoncé côté Vite.
// Réfère-toi au guide officiel pour le nom exact et les options.
import inertia from '@inertiajs/vite-plugin'

export default defineConfig({
  plugins: [
    laravel({
      input: ['resources/js/app.js'],
      ssr: 'resources/js/ssr.js',
      refresh: true,
    }),
    inertia(),
  ],
})

Pièges classiques SSR (indépendants de v3, mais qui ressortent pendant une migration) :

• Code non isomorphe : accès à window/document sans guard côté SSR.
• Dépendances UI qui cassent en SSR (certains composants riches, éditeurs, charting).
• Données sensibles : attention à ce que tu sérialises dans les props (SSR rend tout visible dans le HTML).

Étape 4 : Optimistic updates : où les utiliser (et où c’est une mauvaise idée)

Oui, c’est tentant de tout rendre “instant”. Non, ce n’est pas une bonne idée partout.

Excellent cas d’usage :

• Like / favorite / pin
• Toggle (actif/inactif)
• “Mark as read”
• Ajout/suppression dans une liste où le backend valide facilement

Mauvais cas d’usage :

• Actions irréversibles (paiement, suppression définitive)
• Actions à règles métiers complexes (risque élevé de rollback)
• Écrans où la cohérence stricte est obligatoire (stocks, compta, permissions)

Le principe à respecter : tu optimises l’UI, pas la vérité. La vérité reste le serveur. Donc il te faut un plan de rollback visible (et testable).

// Pseudo-exemple : optimistic update (API exacte susceptible d'évoluer en beta)
// Objectif : UI instantanée + rollback si le serveur refuse.

import { router } from '@inertiajs/core'

function toggleStar(project) {
  const previous = project.starred

  // 1) Mise à jour UI immédiate (state local)
  project.starred = !previous

  // 2) Envoi serveur
  router.post(`/projects/${project.id}/star`, {}, {
    preserveScroll: true,
    onError: () => {
      // 3) Rollback si erreur (réseau, 403, 422, ...)
      project.starred = previous
    },
  })
}

Si tu veux quelque chose de “propre produit”, ajoute un feedback léger (toast “Impossible de mettre à jour”) et loggue l’échec (Sentry, logs backend) : c’est la différence entre une UX premium et un bug intermittent.

Checklist de migration (rapide et sans drama)

• Mettre à jour les dépendances Inertia (front + Laravel) selon le guide v3.
• Identifier les usages d’Axios : navigation Inertia vs appels API séparés.
• Remplacer les interceptors Axios “critiques” par une stratégie explicite (hooks/events Inertia, middleware backend, wrapper fetch, etc.).
• Si SSR : passer par le plugin Vite, vérifier l’isomorphisme et les libs non-SSR-friendly.
• Introduire les optimistic updates uniquement sur 1 ou 2 interactions à faible risque.
• Ajouter des tests E2E sur les flows critiques (auth, paiement, CRUD principal).
• Préparer un rollback : tag git + déploiement réversible.

Mon avis : v3 est une bonne direction (mais fais-le en mode “changement contrôlé”)

Supprimer Axios du chemin critique, standardiser le SSR via Vite et intégrer correctement les optimistic updates : c’est exactement le genre d’évolution qui rend Inertia plus durable. Mais comme ça touche aux fondations, la migration mérite une approche sérieuse : pas un vendredi soir, pas un “on verra en prod”.

Fais passer la compilation, sécurise la navigation, verrouille SSR si tu l’as, puis ajoute les optimistic updates là où elles font vraiment gagner du produit. Le reste, c’est du folklore.

Sources

• Laravel — Inertia.js v3 Is Now in Beta
• GitHub — inertiajs/inertia