Skip to content

Étape 25 — Choisir un mode de publication

Fiche théorique

Pas de code dans cette étape. Vous allez comprendre les modes de publication d'une application web pour pouvoir choisir celui qui convient à votre projet. Les étapes suivantes mettent ces concepts en pratique sur le Pokédex.

Temps estimé

Environ 30 minutes de lecture + réflexion.

Objectif

Votre Pokédex Vuetify fonctionne en local. Pour le publier (le rendre accessible aux utilisateurs), vous devez choisir un mode de rendu et une stratégie de déploiement. Ces choix conditionnent :

  • La performance perçue (vitesse de chargement)
  • Le référencement Google (SEO)
  • Le coût d'hébergement
  • La capacité à fonctionner hors ligne
  • La possibilité d'être installé comme une vraie app

Les 6 modes de publication

Tableau récapitulatif

ModeRenduSEOHors ligneCoût hébergementCas d'usage typique
SPA (Single Page App)Navigateur (JS)FaibleNonTrès bas (statique)Tableau de bord, app interne
PWA (Progressive Web App)Navigateur + Service WorkerFaibleOuiTrès bas (statique)App web installable, hors ligne
SSG (Static Site Generation)Pré-rendu au buildExcellentNonTrès bas (CDN)Blog, documentation, e-commerce vitrine
SSR (Server-Side Rendering)Serveur à chaque requêteExcellentNonMoyen (serveur Node)Site contenu dynamique + SEO critique
ISR (Incremental Static Regen)Pré-rendu + revalidationExcellentNonBas (Vercel/Netlify)E-commerce, news, mix statique/dynamique
Native (Capacitor / React Native)App native iOS/AndroidOuiStores (99 USD/an Apple)App mobile distribuée sur stores

Détail des modes

SPA (Single Page Application) — le mode actuel du Pokédex

C'est ce que vous avez créé jusqu'à présent avec Vue + Vite. Le navigateur télécharge un seul fichier HTML quasi vide + un gros bundle JavaScript. Vue prend ensuite la main et génère tout le contenu côté client.

Avantages :

  • Hébergement gratuit ou très peu cher (Vercel, Netlify, GitHub Pages, Infomaniak)
  • Navigation interne ultra rapide après le premier chargement
  • Pas besoin de serveur Node — un simple serveur statique suffit

Inconvénients :

  • Premier chargement long : il faut télécharger TOUT le JS avant que la page s'affiche
  • SEO faible : Google voit <div id="app"></div> vide, l'indexation des contenus dépend du JS
  • Pas de hors ligne sans ajout du Service Worker (= PWA)
  • Mauvais pour les contenus à indexer (blog, e-commerce SEO)

Frameworks : Vue + Vite (votre Pokédex), React + Vite, Angular, Svelte.

PWA (Progressive Web App) — bonus de la SPA

Une PWA, c'est une SPA améliorée avec :

  • Un manifest : permet l'installation sur écran d'accueil (mobile + desktop)
  • Un service worker : cache les ressources pour le hors ligne et accélère le rechargement
  • HTTPS obligatoire

Avantages :

  • Tout ceux de la SPA + hors ligne + installable comme une app native
  • Notifications push possibles (avec config supplémentaire)
  • Une seule base de code pour web + "app installable"

Inconvénients :

  • Pas dans l'App Store (sauf iOS via PWABuilder)
  • Accès limité aux API natives (caméra, contacts) par rapport à Capacitor
  • Service worker complexe à débugger

Sur ce Pokédex

L'étape E26 transforme votre Pokédex en PWA en moins de 10 minutes avec vite-plugin-pwa.

SSG (Static Site Generation) — pré-rendu au build

Le serveur (au moment du npm run build) génère un fichier HTML pour chaque page avec le contenu déjà rendu. Le navigateur reçoit du HTML complet, puis Vue "s'hydrate" pour rendre la page interactive.

Avantages :

  • SEO excellent : Google voit le contenu immédiat
  • Premier chargement très rapide : HTML servi direct
  • Hébergement statique (CDN)
  • Sécurité : pas de serveur exposé

Inconvénients :

  • Le contenu est figé au build : pour publier un nouvel article, il faut rebuilder + redéployer
  • Long à builder pour les sites de milliers de pages
  • Difficile pour les contenus utilisateur (commentaires, paniers)

Frameworks : Nuxt 3 (Vue), Next.js (React), Astro, Hugo, VitePress (utilisé par devjs.ch !).

Pourquoi pas SSG sur ce Pokédex ?

SSG nécessite une refonte avec Nuxt (Vite seul ne fait que du pre-render limité). Sortir du scope de ce cours.

SSR (Server-Side Rendering) — rendu à chaque requête

Un serveur Node.js génère le HTML à chaque visite en fonction des données du moment. Le navigateur reçoit du HTML déjà rempli, puis hydratation Vue.

Avantages :

  • SEO excellent ET contenu dynamique (parfait pour e-commerce, news)
  • Premier chargement rapide
  • Personnalisable par utilisateur (HTML adapté)

Inconvénients :

  • Coût : un serveur Node tourne en permanence (Vercel, Render, Heroku...)
  • Plus complexe à débugger (logique serveur + client)
  • Latence : chaque requête déclenche un rendu serveur

Frameworks : Nuxt 3 (mode SSR), Next.js (mode SSR), SvelteKit.

ISR (Incremental Static Regeneration) — le compromis moderne

Pré-rendu statique au build (comme SSG), mais le serveur régénère une page dans le cache dès qu'une période expire (par exemple toutes les 60 secondes). Le visiteur suivant voit la version fraîche.

Avantages :

  • SEO excellent + perfs statiques + données quasi temps-réel
  • Hébergement bas coût (Vercel, Netlify gèrent l'ISR)
  • Pas de re-deploy pour mettre à jour les données

Inconvénients :

  • Spécifique aux hébergeurs qui le supportent (Vercel, Netlify, Cloudflare)
  • Configuration revalidation à bien penser
  • Premier visiteur après expiration voit la vieille version (puis trigger le rebuild)

Frameworks : Next.js (origine du concept), Nuxt 3 (depuis v3.10), Astro.

Native (Capacitor, React Native, Flutter)

Votre code web est emballé dans une vraie app mobile publiable sur les stores Apple et Google. Sur Capacitor, le code Vue/Vuetify est exécuté dans une WebView native.

Avantages :

  • Publication officielle sur App Store et Play Store
  • Accès aux API natives (caméra, contacts, GPS, notifications push)
  • Installable comme une vraie app mobile
  • Pour Capacitor : réutilise 100% du code web (pas de réécriture)

Inconvénients :

  • Comptes développeur payants : 99 USD/an Apple, 25 USD une fois Google
  • Processus de validation Apple peut prendre des jours
  • Mises à jour passent par le store (sauf hot updates via Capacitor Live Updates)
  • Performances natives moindres que React Native ou Flutter (qui compilent vers du natif)

Frameworks : Capacitor (web → native), React Native (JS → natif), Flutter (Dart → natif), Tauri (Rust + web pour desktop).

Sur ce Pokédex

Les étapes E27 à E29 transforment votre Pokédex en application mobile native iOS et Android via Capacitor.

Matrice de décision

Si votre projet est...Mode recommandé
Une app interne sans SEO (dashboard, back-office)SPA
Une app web qui doit aussi marcher hors lignePWA
Un blog, une doc, un site vitrineSSG (Nuxt, Astro, VitePress)
Un e-commerce avec catalogue dynamique + SEOISR ou SSR
Une news ou une plateforme de contenusSSR ou ISR
Une app à publier sur App Store / Play StoreNative (Capacitor)
Un mix : web + mobile + hors lignePWA puis Capacitor (le code est le même)

Et notre Pokédex Vuetify ?

Votre Pokédex est aujourd'hui une SPA pure. C'est le bon choix pour un projet de cours, mais les modes suivants sont accessibles :

  • PWA : possible en ajoutant vite-plugin-pwa (étape E26)
  • Native mobile : possible avec Capacitor (étapes E27 à E29)
  • SSG / SSR / ISR : nécessiterait une migration vers Nuxt 3 — hors scope de ce cours, mais le concept est important à connaître

Tests à effectuer (compréhension)

  • Vous pouvez expliquer la différence entre SPA et SSG en 2 phrases
  • Vous savez pourquoi un blog choisit SSG plutôt que SPA
  • Vous savez pourquoi un e-commerce choisit SSR/ISR plutôt que SSG
  • Vous savez quel framework Vue permet le SSR (réponse : Nuxt 3)
  • Vous pouvez nommer 2 avantages d'une PWA par rapport à une SPA classique

Suite

Vous avez maintenant la vue d'ensemble. Choisissez votre parcours :

Recommandation

Faites E26 (PWA) avant E27 si vous voulez voir le résultat tout de suite dans votre navigateur sans installer Android Studio. Les deux sont indépendants.

Documentation pour les cours de développement web