Le site était écrit. Sept pages en Next.js, une API Laravel derrière, un back-office. Restait à le mettre en ligne — et c'est là que le projet a commencé pour de bon.
La contrainte arrive après le code
L'hébergement retenu était une formule mutualisée : PHP, MySQL, un accès FTP, un panneau d'administration. Pas de SSH selon la formule, pas de serveur Node.js permanent, aucune configuration de serveur web globale.
Ce n'est pas une contrainte exotique. C'est ce que paie une petite entreprise qui met son premier site en ligne, et c'est ce qu'on découvre souvent après avoir choisi sa pile technique.
Ce que Next.js suppose
Next.js rend ses pages avec un serveur Node. Sur un hébergement qui n'en exécute pas, l'application ne démarre pas. Deux issues :
- Changer d'hébergeur — un serveur virtuel, une facture mensuelle, et une administration système que personne ne tiendra chez le client.
- Retirer le besoin de serveur.
La première n'était pas au budget. Elle avait aussi un défaut moins visible : elle déplaçait une charge d'exploitation sur quelqu'un qui n'en voulait pas.
Trois briques, trois sous-domaines
Le site est passé en export statique. Next.js sait produire un dossier de fichiers HTML, CSS et JavaScript qu'un serveur web ordinaire sert tels quels — et un hébergement mutualisé sait faire exactement cela.
Le reste s'est réparti :
| Brique | Où | Comment |
|---|---|---|
| Site public | domaine principal | fichiers statiques déposés par FTP |
| API | sous-domaine | Laravel, déploiement PHP classique |
| Back-office | sous-domaine | Filament, servi par le même PHP |
Les trois partagent la base MySQL, et l'accès à l'API est tenu par Sanctum. Le site interroge l'API depuis le navigateur : le dynamique passe côté client, exactement là où le serveur ne peut plus rien faire.
Ce que l'export statique coûte
Il faut le dire, sinon la solution passe pour gratuite.
- Plus de rendu serveur. Les données qui changent arrivent après le premier affichage, pas avec lui.
- Plus de route calculée à la volée. Toute page doit être connue au moment de la construction.
- Le référencement change de nature. Le contenu statique est indexable ; celui qui arrive par l'API ne l'est pas de la même façon.
Pour une vitrine de sept pages dont le contenu bouge rarement, ces trois coûts sont acceptables. Pour un catalogue de dix mille références, ils ne le seraient pas. La solution n'est pas bonne en soi — elle est bonne ici.
Ce que j'en retiens
La contrainte d'hébergement fait partie de l'architecture, au même titre que le choix du framework. La découvrir au déploiement, c'est la découvrir trop tard.
Et une contrainte n'est pas toujours un obstacle à contourner. Celle-ci a produit un site plus rapide qu'il ne l'aurait été avec un serveur Node sur une machine partagée, et une exploitation que le client peut tenir seul.