Déployer en ligne

Mettre en ligne : ce que ça veut dire

Jusqu'ici, ton app vit dans ton outil ou sur ton ordinateur : toi seul peux l'utiliser. Déployer, c'est copier ton app sur un serveur accessible depuis Internet, qui la sert à quiconque ouvre la bonne adresse. Le résultat concret : une URL du type mon-app.vercel.app que Tom peut écrire au tableau, et que chaque élève ouvre sur son téléphone.

Bonne nouvelle pour une app comme la tienne : c'est gratuit, rapide, et largement automatisé. Les apps « statiques » (HTML, CSS, JavaScript, sans serveur à toi) sont les plus simples du monde à héberger — c'est exactement pour ça qu'on a choisi cette base technique au chapitre 3. Les choix simples du début paient maintenant.

Les plateformes gratuites

Trois grands noms dominent l'hébergement gratuit d'apps web, et tu ne peux pas vraiment te tromper : ils sont tous fiables, rapides et utilisés par des millions de projets. Voici comment choisir :

Cas particulier : si tu as construit ton app sur Lovable, v0, Bolt ou Replit, ces plateformes proposent un bouton « Publish » ou « Deploy » intégré qui fait tout en un clic. C'est la voie la plus simple — utilise-la pour ta première mise en ligne, tu exploreras Vercel ou Netlify quand tu en auras besoin.

La méthode la plus simple : sans ligne de commande

Si Git et le terminal t'intimident encore, il existe un chemin sans aucune commande : le glisser-déposer Netlify. Tu demandes à ton outil d'exporter ou de télécharger les fichiers de ton app (un dossier avec ton index.html et le reste), tu ouvres la page de dépôt de Netlify, et tu fais glisser le dossier dans la zone prévue. Trente secondes plus tard, ton app a une URL publique.

Cette méthode a une limite : à chaque modification de ton app, tu dois re-glisser le dossier à la main. C'est très bien pour une première mise en ligne ou une app qui bouge peu. Dès que tu modifies souvent, le chemin Git devient plus confortable — chaque commit poussé met automatiquement le site à jour.

Le chemin complet avec Git et Vercel

Le déploiement « professionnel » suit toujours la même logique : ton code vit dans un dépôt Git hébergé sur GitHub, et la plateforme (Vercel ou Netlify) surveille ce dépôt. À chaque fois que tu pousses une mise à jour, elle reconstruit et republie ton site automatiquement. C'est le fameux « push to deploy » — tu ne t'occupes plus jamais de la mise en ligne, elle suit ton travail.

Tu n'as pas besoin de mémoriser la procédure : demande à l'IA de te guider, étape par étape, en précisant ton niveau. Voici le prompt que Tom utilise :

Guide-moi pour déployer cette app sur Vercel, étape par étape, en partant de zéro.
Je n'ai jamais utilisé Git ni Vercel. J'ai un compte GitHub tout neuf.
Pour chaque étape : dis-moi où cliquer ou quelle commande taper, et explique en une phrase à quoi elle sert.
Attends ma confirmation avant de passer à l'étape suivante.

La dernière ligne est une astuce précieuse : en demandant à l'IA d'avancer une étape à la fois, tu transformes une procédure intimidante en une conversation tranquille où tu peux signaler le moindre blocage au moment où il survient. Pour référence, les commandes que tu verras passer ressemblent à ceci :

# Lier ton projet local au dépôt créé sur GitHub :
git remote add origin https://github.com/ton-compte/mon-app.git

# Envoyer ton code sur GitHub :
git push -u origin main

# Ensuite, sur vercel.com : « Add New Project » → importer le dépôt → Deploy.

flowchart LR
  L["App sur ton ordinateur"] --> G["Dépôt Git"]
  G --> V["Vercel / Netlify"]
  V --> U["URL publique"]
  U --> F["Retours utilisateurs"]
  F -.->|"Améliorations"| L

Vérifier ton app en ligne

Le déploiement réussi ne signifie pas que tout marche : l'environnement en ligne diffère légèrement de ton aperçu local. Prends cinq minutes pour une vérification sérieuse. Ouvre l'URL publique dans un navigateur en navigation privée (pour partir de zéro, sans données locales), refais le parcours complet d'un utilisateur, puis ouvre l'URL sur ton téléphone — c'est là que tes utilisateurs seront.

• L'app se charge-t-elle, sans page blanche ni erreur 404 ?
• Le parcours principal marche-t-il de bout en bout (ajouter, cocher, voir le streak) ?
• Les données persistent-elles après rechargement de la page ?
• L'affichage est-il correct sur téléphone : textes lisibles, boutons cliquables au pouce ?

Si quelque chose casse en ligne alors que ça marchait en local, pas de panique : c'est un grand classique. Copie l'erreur de la console (F12, même en ligne) et décris à l'IA la différence : « en local ça marche, en ligne sur Vercel j'obtiens cette erreur : … ». Les causes habituelles — un chemin de fichier incorrect, une majuscule dans un nom de fichier — se corrigent en un message.

Partager et recueillir des retours

Une fois en ligne, partage l'URL. Le feedback réel est le meilleur carburant pour progresser : Tom donne le lien à quelques élèves et observe comment ils l'utilisent. Et là, surprise garantie — les utilisateurs ne font jamais ce qu'on attend. Un élève essaie d'ajouter vingt habitudes, un autre cherche un bouton « annuler » qui n'existe pas, un troisième demande pourquoi ses données ne sont pas sur l'ordi de la maison (souviens-toi : localStorage = données par appareil).

Recueille ces retours simplement : regarde les gens utiliser l'app sans les aider, note ce qui les bloque, et pose deux questions — « qu'est-ce qui t'a gêné ? » et « qu'est-ce qui te manque le plus ? ». Trois utilisateurs suffisent à repérer 80 % des problèmes évidents. Ajoute leurs réponses à ta liste « plus tard », et trie : ce qui revient plusieurs fois passe en haut.

Et après ?

Tu as une vraie app en ligne. Itère : pioche dans ta liste « plus tard » enrichie des retours utilisateurs, ajoute une fonctionnalité par session en suivant la méthode du chapitre 4, et republie — avec le « push to deploy », chaque amélioration validée part en ligne toute seule. Les chantiers classiques d'une v2 : un meilleur design, un nom de domaine personnalisé, l'export des données, ou la synchronisation entre appareils (le fameux compte utilisateur, maintenant que tu sais ce qu'il coûte).

Et surtout, recommence. Choisis un deuxième projet, un peu plus ambitieux, et refais le parcours complet : mini-PRD, construction itérative, débogage méthodique, déploiement. Chaque projet te rend plus à l'aise pour piloter l'IA, plus rapide à diagnostiquer, plus précis dans tes descriptions. C'est exactement comme ça qu'on apprend à construire aujourd'hui — et tu viens de faire le tour complet une première fois. Bienvenue dans le club.