Créez des sites web et des applications Vue avec routage, logique serveur et rendu flexible
Nuxt est un framework gratuit et open source permettant de créer des sites web et des applications full-stack avec Vue. Il fournit le routage, le rendu, des fonctionnalités serveur, des conventions de gestion des données, des outils de développement et une prise en charge du déploiement afin qu’une équipe n’ait pas à assembler séparément ces fondations.
Le sujet principal ici est Nuxt, le framework. nuxt.com est son site officiel et son portail de documentation, où les développeurs peuvent étudier le framework, les modules, l’équipe et les ressources communautaires.
De quoi s’agit-il avec Nuxt ?
Nuxt vise à transformer des composants Vue en une application structurée pouvant s’exécuter sur le serveur et dans le navigateur. Un projet Nuxt peut fournir du HTML rendu côté serveur, se comporter comme une application côté client, générer des pages statiques ou appliquer différentes règles de rendu et de mise en cache selon les routes.
Sa portée dépasse la génération de sites statiques. Nuxt peut prendre en charge un site de contenu, une application authentifiée, des points de terminaison serveur ou un produit réunissant les trois.
Nuxt en une minute
- Vue fournit le modèle d’interface. Les développeurs continuent d’écrire des composants Vue, des modèles, des composables et des états réactifs.
- Nuxt fournit la structure de l’application. Des fichiers et répertoires reconnus définissent les pages, les mises en page, les middlewares, les plugins, les utilitaires et les gestionnaires serveur.
- Le rendu universel est utilisé par défaut. Le serveur peut produire la première réponse HTML avant que Vue n’active le comportement interactif dans le navigateur.
- Le rendu peut changer selon la route. Des sections statiques, mises en cache, rendues côté serveur et réservées au client peuvent coexister.
- Nitro alimente la couche serveur. Il gère le rendu côté serveur, les points de terminaison d’API, les middlewares et les sorties orientées vers le déploiement.
- Nuxt Content est facultatif. Les équipes peuvent ajouter un système de contenu basé sur des fichiers sans en faire une exigence pour tous les projets Nuxt.
Quel est le lien entre Nuxt et Vue ?
Vue est le framework d’interface utilisateur sur lequel repose Nuxt. Nuxt conserve le modèle de composants de Vue et ajoute les décisions environnantes nécessaires pour transformer les composants en un site web ou une application avec routage et prêt au déploiement.
Un développeur travaillant avec Nuxt utilise toujours des concepts Vue tels que les composants monofichiers, les props, les événements, les composables et la réactivité. Nuxt ajoute des conventions définissant l’emplacement de ces composants, la façon dont les URL y accèdent, le moment où les données sont récupérées et si le code s’exécute sur le serveur, dans le navigateur ou aux deux endroits.
| Aspect | Rôle de Vue | Rôle de Nuxt |
|---|---|---|
| Interface | Composants, modèles et réactivité | Organise les composants en pages et mises en page |
| Navigation | S’intègre aux outils de routage | Crée des routes à partir des fichiers dans app/pages/ |
| HTML initial | Fournit les primitives de rendu | Configure le rendu côté serveur et le prérendu |
| Logique serveur | Hors du périmètre de la bibliothèque d’interface principale | Ajoute les points de terminaison, middlewares et utilitaires serveur Nitro |
| Déploiement | Choisi par l’application | Produit une sortie au moyen des préréglages de déploiement Nitro |
Cette structure intégrée réduit la configuration initiale et donne aux contributeurs un vocabulaire commun pour le projet. En contrepartie, les développeurs doivent comprendre les comportements propres à Nuxt, notamment les importations automatiques, l’analyse des répertoires, l’hydratation et les limites entre serveur et client.
Comment les fichiers deviennent-ils des routes et des fonctionnalités de l’application ?
Nuxt utilise des conventions pour relier le système de fichiers au comportement de l’application. Un fichier Vue situé dans app/pages/ devient une route, tandis que les noms contenant des crochets peuvent représenter des paramètres d’URL dynamiques.
La même approche s’étend au-delà des pages. Les mises en page enveloppent les vues associées, les middlewares de route s’exécutent autour de la navigation, les plugins configurent l’application Vue et les composables contiennent une logique avec état réutilisable. Nuxt peut importer automatiquement les composants, composables et utilitaires pris en charge depuis des emplacements reconnus.
Répertoires courants et leurs fonctions
| Répertoire | Fonction publique |
|---|---|
app/pages/ |
Crée les routes de l’application à partir de fichiers Vue |
app/layouts/ |
Définit des structures de page réutilisables |
app/components/ |
Stocke les composants d’interface Vue réutilisables |
app/composables/ |
Contient la logique de composition Vue réutilisable |
app/middleware/ |
Exécute une logique pendant la navigation entre les routes |
server/api/ |
Crée des points de terminaison serveur sous /api |
server/routes/ |
Crée des routes serveur sans le préfixe /api |
shared/ |
Contient le code destiné à la fois à l’application Vue et au serveur Nitro |
Le routage par fichiers évite aux équipes de maintenir un registre de routes distinct pour les pages ordinaires. Cela signifie également que déplacer ou renommer un fichier peut modifier une URL publique ; la structure des routes mérite donc le même niveau de vérification que le code de l’application.
Les importations automatiques suppriment les déclarations répétitives, mais leur origine peut manquer de clarté pour un nouveau contributeur. Des noms explicites, la prise en charge par l’éditeur et une brève documentation du projet peuvent rendre cette commodité plus facile à comprendre.
Quels modes de rendu Nuxt prend-il en charge ?
Nuxt prend en charge le rendu universel, le rendu côté client, le prérendu et le rendu hybride. Ces modes décrivent le moment où le HTML est produit et la quantité de travail restant au serveur ou au navigateur.
Le rendu universel est le modèle documenté par défaut. Nuxt effectue le rendu du HTML initial sur le serveur, l’envoie au visiteur, puis hydrate la page afin que Vue puisse gérer les interactions dans le navigateur.
| Mode | Ce qui se passe | Exemples adaptés | Compromis important |
|---|---|---|---|
| Universel | Le HTML est produit pour la requête initiale, puis hydraté | Pages produit publiques ou applications reposant sur des données | Le code serveur et le code du navigateur doivent se comporter de manière cohérente |
| Côté client | Le navigateur effectue le rendu de la structure et de l’interface de l’application | Outils privés principalement régis par l’état du navigateur | Le HTML initial peut contenir moins de contenu utile |
| Prérendu | Le HTML est généré avant les requêtes | Documentation, guides et pages marketing stables | Les builds doivent découvrir ou recevoir chaque route prévue |
| Hybride | Différents chemins reçoivent des règles différentes | Une publication statique dotée d’un espace de compte dynamique | Davantage de comportements propres aux routes doivent être testés et maintenus |
Le HTML rendu côté serveur peut accélérer la disponibilité du contenu utile, mais il ne garantit ni des pages rapides, ni une bonne visibilité dans les moteurs de recherche, ni de petits bundles JavaScript. Le poids des composants, l’accès aux données, la mise en cache, l’hébergement et la qualité de l’implémentation déterminent toujours le résultat.
La sortie statique présente des limites similaires. Le prérendu supprime le rendu au moment de la requête pour certaines pages, mais de vastes ensembles de routes peuvent allonger les builds, et toute modification du contenu peut nécessiter une nouvelle génération, sauf si une autre stratégie prise en charge est configurée.
Que sont les règles de route et le rendu hybride ?
Les règles de route permettent à un projet Nuxt d’attribuer un comportement aux motifs d’URL correspondants. Elles rendent le rendu hybride possible, car une section peut être prérendue tandis qu’une autre reste dynamique ou rendue côté client.
Les règles documentées comprennent le prérendu, les redirections, la désactivation du rendu côté serveur pour certains chemins, la mise en cache, le comportement stale-while-revalidate et la régénération incrémentielle sur les plateformes prises en charge. Certaines fonctionnalités dépendent du préréglage de déploiement et de l’environnement d’hébergement.
Un plan de routes pratique
- Une section de documentation peut utiliser le prérendu, car ses pages changent au fil des publications éditoriales.
- Un catalogue de produits peut utiliser une règle de cache ou stale-while-revalidate lorsque ses données changent plus fréquemment.
- Un tableau de bord de compte peut utiliser le rendu côté client, car son contenu est privé et hautement interactif.
- Un chemin d’API peut recevoir des règles de mise en cache ou d’origine croisée indépendamment des routes de pages.
- Une URL retirée peut être redirigée vers son remplacement.
Les règles de route sont puissantes lorsqu’elles expriment un petit nombre de catégories claires de contenu et d’application. Une collection croissante d’exceptions peut rendre difficiles à prévoir la fraîcheur des données, l’invalidation et le comportement à l’exécution.
La régénération incrémentielle mérite une vérification du déploiement. Nuxt documente des règles de route orientées ISR, mais leur comportement exact dépend de l’intégration à la plateforme choisie et n’est pas identique sur tous les hébergeurs.
Que fournit Nitro ?
Nitro est le moteur serveur de Nuxt. Il prend en charge le rendu côté serveur, le prérendu, les gestionnaires d’API, les middlewares, les plugins serveur et les sorties destinées à différents environnements serveur ou edge.
Les fichiers dans server/api/ deviennent des points de terminaison dotés du préfixe /api. Les fichiers dans server/routes/ créent des routes sans ce préfixe, tandis que les middlewares serveur peuvent inspecter ou étendre le contexte de la requête avant l’exécution des gestionnaires.
Gardez ces limites d’exécution visibles
- Le code réservé au serveur peut fonctionner avec des identifiants privés et des services de confiance, mais les secrets ne doivent jamais intégrer les bundles du navigateur.
- Le code réservé au client peut utiliser les API du navigateur, mais les visiteurs peuvent inspecter tout ce qui est transmis à leurs appareils.
- Le code partagé doit être sûr et compatible dans chaque environnement d’exécution où Nuxt l’exécute.
- Les systèmes externes tels que les bases de données, les files d’attente, les fournisseurs d’identité et les API indépendantes conservent leurs propres exigences de sécurité et d’exploitation.
Le fait de conserver l’interface et de petits gestionnaires serveur dans un même projet peut simplifier le développement. Cela ne signifie pas que chaque backend doit se trouver dans Nuxt, et Nitro ne supprime pas la nécessité de concevoir l’authentification, la validation, le stockage, l’observabilité ou la gestion des défaillances.
Les préréglages de déploiement adaptent la sortie Nitro aux environnements pris en charge. Les équipes doivent tester la cible réelle, car les environnements d’exécution diffèrent quant aux API disponibles, à la durée de vie des processus, à l’intégration de la mise en cache et aux contraintes opérationnelles.
Nuxt convient-il aux sites de contenu ?
Oui. Nuxt est utile pour la documentation, la publication, le marketing et d’autres sites web riches en contenu, en particulier lorsque ces pages doivent partager des composants Vue avec des fonctionnalités produit interactives.
Une équipe peut obtenir du contenu depuis une API, un système de gestion de contenu distinct ou des fichiers locaux. Nuxt Content est un module facultatif destiné à l’approche par fichiers locaux.
La documentation de Nuxt Content indique une prise en charge des sources Markdown, YAML, CSV et JSON. Il peut organiser le contenu en collections typées, interroger le contenu, générer des données de navigation et utiliser MDC pour insérer des composants Vue dans le Markdown.
Cas où cette combinaison est utile
- Une documentation produit comportant des exemples de code interactifs ou des calculateurs.
- Une publication qui partage sa navigation et ses composants de conception avec une application Vue.
- Un site marketing comprenant des fonctionnalités de compte, de recherche ou de personnalisation.
- Une base de connaissances interne créée à partir de collections de contenu structurées.
- Une propriété comportant plusieurs sections et nécessitant des règles de rendu différentes pour les routes éditoriales et celles de l’application.
Nuxt Content n’est pas en soi un service éditorial hébergé. Les équipes doivent toujours évaluer les autorisations des auteurs, les workflows de validation, la gestion des médias, la localisation, les aperçus et les contrôles de publication lorsque le contenu est géré par des personnes qui ne sont pas développeuses.
Pour un site de documentation modeste, des fichiers Markdown locaux peuvent suffire. Une grande organisation éditoriale peut préférer une plateforme de contenu externe tout en continuant d’utiliser Nuxt pour la présentation et le rendu.
Qui assure la maintenance de Nuxt et où sa communauté se réunit-elle ?
Selon la page officielle de l’équipe consultée le 27 août 2026, le développement de Nuxt et de son écosystème est dirigé par une équipe internationale. La page répertorie les équipes principales et celles de l’écosystème ; cette attribution au niveau de l’équipe est plus fiable que de déduire l’existence d’un unique fondateur à partir de l’historique du dépôt ou de profils individuels.
Le dépôt GitHub nuxt/nuxt maintenu contient le code source du framework, le système de suivi des problèmes, les ressources de contribution et l’historique des versions. L’activité du dépôt peut aider les développeurs à examiner l’implémentation et la maintenance, mais elle ne doit pas être considérée comme une promesse concernant les calendriers futurs.
La page officielle d’aide communautaire indique deux voies d’assistance pertinentes :
- Discord est la voie officielle pour les conversations et l’aide communautaires en temps réel.
- GitHub Discussions est la voie officielle pour les questions qui bénéficient d’un fil consultable et asynchrone.
Nuxt précise que les membres de la communauté proposent leur aide bénévolement. Les projets nécessitant des délais de réponse garantis, un travail d’architecture privé ou une assistance contractuelle doivent évaluer séparément les offres d’assistance professionnelle.
Quand Nuxt constitue-t-il un bon choix ?
Nuxt est un candidat solide lorsque Vue est déjà le modèle de composants privilégié et que le projet nécessite davantage qu’une simple interface dans le navigateur. Ses conventions sont particulièrement utiles lorsque des pages publiques, des fonctionnalités interactives et des gestionnaires serveur doivent partager une même structure d’application.
Envisagez Nuxt lorsque
- L’équipe travaille déjà efficacement avec Vue.
- Les routes publiques bénéficient d’un HTML produit par le serveur ou prérendu.
- Les pages d’interface et les points de terminaison serveur de taille modeste doivent cohabiter.
- Les sections de contenu et d’application ont besoin de mises en page et de composants partagés.
- Différents groupes de routes nécessitent différentes politiques de rendu ou de mise en cache.
- Les contributeurs préfèrent une convention documentée à l’assemblage de nombreux outils distincts.
Comparez d’autres approches lorsque
- Le site est presque entièrement statique et nécessite peu d’interactivité Vue.
- L’équipe souhaite une couche côté client plus légère au-dessus d’un backend indépendant bien établi.
- Les développeurs ont besoin d’une structure très personnalisée comportant peu de conventions imposées par le framework.
- L’environnement d’exécution prévu ne peut pas fournir le comportement serveur ou de cache requis.
- L’expertise principale du projet en matière d’applications appartient à un autre écosystème de composants.
L’étendue de Nuxt n’est utile que lorsque le projet en a besoin. Un petit site vitrine peut utiliser Nuxt, mais cela ne démontre pas que son moteur serveur et ses conventions d’application constituent le choix le plus simple.
Que doit tester une équipe avant de choisir Nuxt ?
Créez une tranche verticale représentative et déployez-la dans l’environnement prévu. Incluez du contenu réel, un composant interactif pertinent, une requête serveur ainsi que la limite d’authentification ou de données attendue.
Suivez cette séquence d’évaluation :
- Classez les routes. Séparez les chemins éditoriaux, publics dynamiques, privés et ceux des points de terminaison serveur.
- Attribuez délibérément le rendu. Consignez pourquoi chaque catégorie utilise un rendu universel, côté client, prérendu ou hybride.
- Testez la charge utile du navigateur. Le rendu côté serveur ne contrôle pas à lui seul l’hydratation ou le coût JavaScript.
- Utilisez un volume de contenu réaliste. Mesurez les builds et les requêtes avec un nombre crédible de pages et de collections.
- Vérifiez les fonctionnalités de déploiement. Confirmez que le préréglage choisi prend en charge la sémantique requise de mise en cache et de régénération.
- Examinez les limites d’exécution. Vérifiez que les valeurs réservées au serveur ne peuvent pas intégrer le code client.
- Testez la compréhension des contributeurs. Demandez à un nouveau développeur de suivre les routes, les importations automatiques, le flux de données et les gestionnaires serveur.
La question pratique n’est pas de savoir si Nuxt peut créer le projet. Il faut déterminer si l’intégration de Vue, les conventions, la couche serveur et les contrôles au niveau des routes de Nuxt simplifient suffisamment le travail dominant du projet pour justifier les concepts supplémentaires qu’ils introduisent.
Une réponse valide ne garantit pas la sécurité. Les mesures décrivent une observation ponctuelle.