Quand on parle d'intenter React à un backend Laravel, la réponse automatique est souvent : "tu construis une API REST". Inertia.js propose une troisième voie — et elle mérite qu'on s'y attarde.
Le problème qu'Inertia résout
Imagine un formulaire de création de projet. En mode API classique, voilà ce qui se passe :
- Le frontend soumet les données en JSON
- Le backend valide et retourne les erreurs ou un objet créé
- Le frontend intercepte la réponse, met à jour le state, gère les erreurs de validation champ par champ, redirige si succès
Ça fonctionne. Mais c'est du code que tu dois écrire, maintenir et tester des deux côtés — souvent pour reproduire quelque chose que Laravel fait nativement.
Inertia résout ça en gardant le backend comme source unique de vérité pour les données et la navigation, tout en laissant React gérer le rendu de l'interface.
Comment ça fonctionne concrètement
Inertia intercepte les clics sur les liens et les soumissions de formulaires. Au lieu de recharger la page, il envoie une requête XHR avec un header spécial. Le serveur reconnaît cet header et retourne uniquement les données du composant, pas le HTML complet.
Le client reçoit ces données et re-rend uniquement le composant concerné. Visuellement, c'est une SPA. Techniquement, c'est du rendu serveur classique sans les compromis.
import { useForm } from '@inertiajs/react';
export default function CreateProject() {
const { data, setData, post, processing, errors } = useForm({
name: '',
description: '',
});
const submit = (e: React.FormEvent) => {
e.preventDefault();
post('/projects'); // Inertia gère la requête et les erreurs
};
return (
<form onSubmit={submit} className="space-y-4">
<input
value={data.name}
onChange={e => setData('name', e.target.value)}
className="w-full rounded border p-2"
/>
{errors.name && <p className="text-red-500 text-sm">{errors.name}</p>}
<button disabled={processing} className="bg-indigo-600 text-white px-4 py-2 rounded">
Créer
</button>
</form>
);
}Les erreurs de validation Laravel arrivent directement dans errors, sans mapping manuel. La redirection côté serveur (return Redirect::route('projects.index')) est respectée côté client. Le state local (scroll position, modals ouverts) est préservé entre les navigations.
Ce qu'on gagne réellement
Source unique d'authentification
Plus de tokens JWT à gérer côté frontend, plus de synchronisation de sessions complexe. Laravel Sanctum ou les cookies standards fonctionnent directement.
Form Requests Laravel centraux
Ta validation reste dans un seul endroit. Les règles complexes (accès BDD, limites d'utilisateurs) restent côté serveur là où elles ont le plus de sens.
Réduction drastique du code de plomberie
Sur un projet moyen, supprimer la couche API élimine facilement 30 à 40% du code : controllers API redondants, JSON Resources et duplication de types.
Expérience utilisateur fluide
Le client navigue instantanément sans recharger la page complète, offrant le feeling et la réactivité d'une SPA rédigée à la main.
Ce qu'on perd
Il faut être honnête sur les compromis.
Attention aux limites architecturales :
- Pas d'API publique par défaut : Si ton projet doit exposer ses données à des applications mobiles natives ou des partenaires tiers, tu devras quand même construire des endpoints API séparés.
- SSR plus complexe : Le Server-Side Rendering avec Inertia existe mais demande un serveur Node séparé et une configuration supplémentaire par rapport à Next.js.
- Couplage fort : Le frontend et le backend vivent dans le même dépôt. Pour de grandes équipes avec des devs uniquement front et d'autres uniquement back, cela peut créer de la friction organisationnelle.
Mon verdict
En résumé :
Inertia.js est le meilleur choix pour les produits web développés par des équipes resserrées ou des développeurs full-stack. Il élimine une catégorie entière de problèmes de plomberie réseau sans introduire de contraintes techniques majeures.
Si tu construis un SaaS, un outil interne, ou une application métier avec Laravel et React, Inertia mérite sérieusement ta considération.