Il y a deux ans, j’ai fait un choix qui a profondément simplifié mes projets : séparer clairement le frontend de mes backends. Mes interfaces vivent dans Next.js, tandis que mes APIs restent responsables de la logique métier et de l’accès aux données.
Cette séparation n’est pas une obligation pour tous les projets. Pour moi, elle devient particulièrement intéressante dès qu’une application possède plusieurs clients, une logique métier conséquente ou plusieurs équipes qui travaillent sur des couches différentes.
Séparer les responsabilités
Frontend — Next.js
Le frontend se concentre sur l’expérience utilisateur :
- rendu et navigation ;
- composants React ;
- gestion de l’état serveur ;
- formulaires ;
- validation côté interface ;
- loading states et erreurs ;
- accessibilité.
Avec TanStack Query, les données distantes sont traitées comme un état serveur plutôt que comme une collection de useEffect dispersés. React Hook Form et Zod permettent de garder des formulaires typés et prévisibles.
Backend — Laravel, Django, Express ou NestJS
Le backend devient la source d’autorité :
- authentification et autorisation ;
- règles métier ;
- transactions ;
- accès PostgreSQL ;
- intégrations externes ;
- validation serveur ;
- observabilité.
Le frontend ne décide jamais qu’une opération est autorisée simplement parce qu’un bouton est visible.
Un contrat API clair
Le point essentiel du découplage est le contrat entre les deux mondes.
Une requête doit avoir une forme prévisible :
POST /api/orders
Content-Type: application/json
Authorization: Bearer <token>
Et la réponse doit être suffisamment stable pour que le frontend puisse évoluer sans connaître les détails internes de la base de données.
Je préfère exposer des ressources métier plutôt que de reproduire directement mes tables SQL.
Le découplage ne signifie pas duplication
Une erreur fréquente consiste à recopier toute la logique métier dans React.
Le frontend peut effectuer une validation ergonomique pour afficher rapidement une erreur, mais le backend doit toujours revalider la donnée.
La règle est simple :
Le frontend améliore l’expérience. Le backend garantit l’intégrité.
Pourquoi garder plusieurs frameworks backend ?
Je ne considère pas Laravel, Django et NestJS comme des concurrents absolus.
Laravel / Django sont très efficaces lorsque je veux avancer rapidement avec un écosystème mature.
NestJS / Express sont particulièrement intéressants lorsque je veux rester entièrement dans l’écosystème TypeScript.
Le frontend reste alors relativement indépendant du choix effectué derrière l’API.
Quand je préfère cette architecture
Je privilégie ce découplage lorsque :
- plusieurs applications consomment la même API ;
- le domaine métier devient important ;
- je veux faire évoluer frontend et backend indépendamment ;
- je prévois une application mobile ;
- plusieurs équipes doivent travailler sans se bloquer.
Pour un petit projet CRUD interne, une architecture monolithique peut évidemment être plus simple.
Mon architecture hybride
Le meilleur compromis n’est pas forcément « tout découpler ».
Je peux conserver un monolithe côté backend tout en exposant une API propre au frontend. Le découplage devient alors une frontière logique claire, sans transformer le projet en microservices.
C’est cette approche que je préfère : des responsabilités séparées, mais une complexité maîtrisée.