Publier la version Web
Exporter l'application en site Web statique, la tester en local, puis la mettre en ligne avec EAS Hosting.
Objectifs de la séance
- comprendre la différence entre le serveur de développement et un export statique ;
- configurer
web.output: "static"et exporter le site dans le dossierdist; - expliquer pourquoi le client Supabase contient une garde pour le rendu côté serveur ;
- créer un compte Expo et publier le site avec EAS Hosting ;
- vérifier la version publiée et connaître les autres hébergeurs possibles.
Petite vérification
Avant de commencer, vérifiez si vous savez...
- lancer
npm run verifieret lire la dernière ligne du résultat des tests - ouvrir
docs/RECETTE.mdet dire combien de tests contient la partie « 3. Robustesse (les tests qui « cassent ») » - citer la commande qui diagnostique la configuration du projet Expo
📌 Réponse attendue
TP pour réfléchir et résoudre des problèmes
Votre mission : obtenir une adresse Web que n'importe qui peut ouvrir pour jouer au Quiz Cyber. Vous restez sur
la branche feature/deploiement. Les étapes 5 et 6 nécessitent un compte Expo (gratuit) : si vous ne souhaitez pas
en créer un, faites les étapes 1 à 4, puis lisez simplement la suite.
Étape 1 — Passer l'application en rendu statique
Le modèle de projet configure le Web en mode "server" : le site a besoin d'un serveur qui exécute du code à
chaque visite. Notre application n'en a pas besoin : elle appelle Supabase directement depuis le navigateur. On la
configure donc en mode "static" : l'export produit des fichiers (HTML, JavaScript, images) qu'on peut héberger
n'importe où. Dans app.json, repérez la section "web" et complétez la ligne du mode de sortie :
Un site statique est moins cher, plus rapide et plus facile à héberger qu'un site avec serveur. On ne
choisit "server" que si l'application a vraiment besoin de code exécuté côté serveur (routes d'API, par exemple).
Étape 2 — Exporter le site
Arrêtez le serveur de développement (Ctrl + C), puis lancez l'export pour la plateforme Web :
npx expo export --platform web
Expo compile l'application et crée un dossier dist : une page HTML par écran, le JavaScript regroupé, les
images et le logo. Ce dossier est votre site. Il est déjà listé dans le .gitignore (dist/) : on ne versionne pas
ce qui peut être recréé par une commande.
Le dossier dist est entièrement généré. Toute modification manuelle sera écrasée au prochain export :
corrigez le code source, puis exportez de nouveau.
Étape 3 — Tester le site exporté en local
Le serveur de développement (expo start) n'exécute pas le même code que le site final. Servez donc le dossier
dist tel qu'il sera publié :
npx expo serve
Ouvrez l'adresse affichée dans le terminal, et déroulez rapidement la recette (parties 2 et 3). Si l'adresse par
défaut est déjà utilisée, ajoutez l'option --port 8098 (ou un autre numéro de port libre).
Un bogue qui n'apparaît que dans la version exportée (variable d'environnement absente, chemin d'image erroné)
est invisible avec expo start. Une minute de test sur dist évite de le découvrir devant vos utilisateurs.
Étape 4 — Comprendre la garde du rendu côté serveur
En mode statique, Expo pré-calcule chaque page en HTML au moment de l'export, en exécutant votre code dans
Node.js. Or Node.js n'a ni navigateur, ni window, ni localStorage. Le fichier src/lib/supabase.ts
(écrit au tutoriel 6) contient la protection qui évite un plantage de l'export. Complétez la ligne qui détecte ce cas :
Un même code s'exécute à trois endroits : le téléphone, le navigateur et Node.js (pendant l'export). Une
fonctionnalité réservée à un seul d'entre eux (localStorage, vibrations...) doit être protégée par une
condition, sinon elle plante dans les deux autres.
Étape 5 — Se connecter à son compte Expo
Créez un compte gratuit sur expo.dev, puis connectez-vous depuis le terminal. Nous utilisons
npx eas-cli@latest : il télécharge la dernière version de l'outil EAS CLI sans l'installer globalement.
npx eas-cli@latest login
npx eas-cli@latest whoami
whoami affiche le compte actif. Sur un poste partagé, vérifiez-le avant de publier : on pourrait publier
sous le compte d'un camarade sans le vouloir.
Étape 6 — Publier avec EAS Hosting
Le dossier dist doit être à jour (relancez npx expo export --platform web en cas de doute). Lancez d'abord un
déploiement de prévisualisation :
npx eas-cli@latest deploy
À la première exécution, l'outil vous demande de relier le dossier à un projet EAS (acceptez : l'identifiant du
projet est ajouté dans app.json), puis de choisir un sous-domaine (par exemple quiz-cyber-votrenom). À la fin, il
affiche l'adresse de prévisualisation. Quand elle vous convient, publiez en production :
L'adresse de production a la forme https://votre-sous-domaine.expo.app.
Les commandes de cette étape et des suivantes viennent de la documentation officielle d'Expo
(docs.expo.dev, rubriques « EAS Hosting » et « Create your first build »). Elles n'ont pas pu être
exécutées pendant la conception de ce cours (elles exigent un compte Expo). Les textes des questions posées par l'outil
(liaison du projet, choix du sous-domaine), l'apparence du tableau de bord et les limites du plan gratuit peuvent donc
différer de ce qui est décrit ici. En cas de doute, lisez les messages de l'outil, consultez la documentation
et signalez à votre enseignant toute différence.
Le déploiement de prévisualisation vous donne une adresse de test qui ne remplace pas le site public. On y
déroule la recette en conditions réelles, puis on promeut en production seulement si tout est OK.
Étape 7 — Tester la version publiée
Ouvrez l'adresse publiée depuis un autre navigateur (ou la fenêtre privée) et déroulez la recette. Trois points demandent une attention particulière :
- Les variables d'environnement : elles sont lues dans
.env.localau moment de l'export et recopiées dans le code. Si l'écran affiche « Configuration Supabase manquante », le fichier.env.localn'était pas présent lors de l'export. - Le rechargement (
F5) sur l'écran de résultat et sur un écran de partie : le site doit répondre sans erreur de page introuvable (recette 3.8). - Les adresses falsifiées (recette 3.7), à tester directement dans l'adresse publiée.
Pour notre application, non : la connexion est anonyme et n'utilise aucune redirection. Le tableau de bord Supabase propose pourtant, dans Authentication > URL Configuration, une adresse de site (Site URL) et une liste de redirections autorisées. Ces réglages deviennent indispensables dès que l'on ajoute une connexion avec un e-mail ou avec un compte tiers (Google, GitHub...). Si votre version publiée ne fonctionne pas alors que la version locale fonctionne, vérifiez-les en priorité.
Les différences entre « ça marche chez moi » et « ça marche chez eux » viennent presque toujours de la configuration : variables absentes, adresses codées en dur, cache du navigateur. Un test dans une fenêtre privée les révèle.
Étape 8 — Enregistrer votre travail
Le seul fichier modifié est app.json (le mode "static" et, après la liaison avec EAS, l'identifiant du projet).
Enregistrez-le :
Faites git status avant git add -A : vous devez voir app.json, et jamais dist/ ni .env.local. Le
dossier dist est ignoré, mais une erreur de .gitignore se paie cher.
📌 Une solution
Notions théoriques
Serveur de développement et export statique
npx expo start | npx expo export --platform web | |
|---|---|---|
| But | développer, avec mise à jour instantanée | produire le site final |
| Résultat | un serveur local qui tourne | un dossier dist de fichiers |
| Code | non optimisé, avec des outils de débogage | compressé et optimisé |
| Hébergement | impossible (il s'arrête avec votre ordinateur) | n'importe quel hébergeur de fichiers |
Un site statique est un ensemble de fichiers qui ne changent pas d'une visite à l'autre : le serveur n'a qu'à les envoyer. Toute la logique (jeu, appels à Supabase) s'exécute dans le navigateur du visiteur. Le serveur de votre application, c'est Supabase : le site Web, lui, n'a besoin d'aucun code serveur.
Le rendu statique (static rendering)
En mode "static", l'export exécute chaque écran dans Node.js pour pré-fabriquer sa page HTML. Le visiteur reçoit donc
déjà une page avec du contenu, puis le JavaScript « reprend la main » dans le navigateur. Conséquence : tout code
exécuté au chargement d'un fichier doit fonctionner sans navigateur (c'est le rôle de estRenduServeur dans le client
Supabase). Une application qui n'a que des écrans fixes (comme la nôtre) s'exporte sans difficulté ; les adresses
dynamiques (/fiche/42) demandent une attention particulière.
Variables d'environnement et secrets dans un site Web
Les variables qui commencent par EXPO_PUBLIC_ sont copiées dans le code au moment de l'export : n'importe quel
visiteur peut les lire en ouvrant les outils de développement du navigateur. C'est sans danger pour la clé publishable
(publique par nature, protégée par la RLS) et pour l'adresse du projet. Ce serait une faille majeure pour une clé
secrète : c'est pourquoi on ne la place jamais dans l'application.
Les hébergeurs possibles
Puisque dist ne contient que des fichiers, tout hébergeur de sites statiques convient :
- EAS Hosting (celui de cette séance), intégré à l'écosystème Expo ;
- Netlify, Vercel, Cloudflare Pages : déposer le dossier
dist, ou relier le dépôt GitHub ; - GitHub Pages : possible, mais l'application est alors servie dans un sous-dossier
(
https://nom.github.io/quiz-cyber-expo/), ce qui demande un réglage du chemin de base (consultez la documentation d'Expo Router).
Test de mémorisation/compréhension
Exercices complémentaires
Exercice A : publier ailleurs
Créez un compte gratuit sur Netlify (ou Vercel) et déposez le dossier dist. Comparez l'adresse obtenue avec celle d'EAS
Hosting, puis déroulez la recette sur chacune. Que constatez-vous ?
Exercice B : l'adresse dans le README
Ajoutez au README.md une section ## Version en ligne avec l'adresse de votre site, puis enregistrez avec un
commit (« Ajouter l'adresse de la version en ligne »).
Ce qu'il faut retenir
| Notion | Résumé |
|---|---|
web.output: "static" | L'export produit des fichiers, hébergeables n'importe où : pas de serveur à gérer. |
npx expo export --platform web | Crée le dossier dist, à régénérer après chaque modification du code. |
npx expo serve | Sert dist en local : on teste ce qui sera réellement publié. |
estRenduServeur | Garde qui évite d'utiliser window et localStorage pendant le pré-calcul sous Node.js. |
EXPO_PUBLIC_... | Copiées dans le code à l'export : lisibles par tous, donc jamais de clé secrète. |
npx eas-cli@latest deploy --prod | Publie dist sur EAS Hosting (adresse en .expo.app) ; sans --prod, simple prévisualisation. |
Aperçu de la prochaine séance
Votre application est en ligne dans un navigateur. Mais un quiz de cybersécurité se joue souvent dans le métro ou entre deux cours, sur un téléphone. Dans la prochaine séance, vous allez configurer EAS Build pour construire un fichier APK : une vraie application Android à installer sur un téléphone, sans passer par Expo Go.