Tu as décrit ton idée à une IA, elle a écrit le code, et l'app fonctionne. Sauf qu'elle fonctionne uniquement sur ton ordinateur, à une adresse que personne d'autre ne peut ouvrir : localhost:3000. Tant que tu restes là, tu ne peux ni montrer ton travail, ni le vendre, ni même le tester depuis ton téléphone.
Le déploiement, c'est l'étape qui transforme ce dossier posé sur ton disque dur en site accessible depuis n'importe quel navigateur. Avec Vercel, cette étape prend une vingtaine de minutes la première fois, et moins de deux minutes les fois suivantes. Pas de serveur à louer, pas de configuration réseau, pas de carte bancaire pour un projet personnel.
Tu vas voir ici la préparation minimale (5 minutes), les trois façons de déployer selon ton niveau, le déroulé minute par minute, la gestion de tes clés d'API sans les exposer au monde entier, et les cinq erreurs qui bloquent la plupart des premiers déploiements.
Vercel, c'est quoi et pourquoi tout le monde l'utilise en vibe coding ?
Vercel est un hébergeur qui met ton application en ligne à partir de ton code, sans que tu aies à configurer le moindre serveur. Tu lui donnes ton projet, il l'installe, le compile, puis lui attribue une adresse publique sécurisée du type mon-app.vercel.app.
Le vibe coding, c'est décrire en français ce que tu veux obtenir et laisser un assistant comme Claude Code écrire le code à ta place. Dans la très grande majorité des cas, ces assistants produisent un projet Next.js ou React. Or Next.js est développé par Vercel : c'est le même éditeur. La compatibilité est donc totale, et c'est la raison pour laquelle presque tous les projets de vibe coding atterrissent là plutôt qu'ailleurs.
Ce que Vercel te retire des mains :
- la location et l'administration d'un serveur
- l'installation de Node.js et des dépendances sur ce serveur
- le certificat HTTPS (le cadenas dans la barre d'adresse), généré automatiquement
- le redéploiement manuel : un simple envoi de code suffit à mettre le site à jour
- la montée en charge si 500 personnes arrivent en même temps
Le plan Hobby est gratuit pour les projets personnels et non commerciaux, avec un sous-domaine en .vercel.app offert. Les quotas exacts et la frontière entre usage personnel et usage commercial sont détaillés dans la documentation officielle de Vercel. Dès que ton app génère du chiffre d'affaires, il faut basculer sur un plan payant : c'est la règle, et mieux vaut la connaître avant de lancer une boutique.
Ce qu'il te faut avant de cliquer sur Deploy (5 minutes)
Trois choses suffisent : un compte GitHub, un compte Vercel, et un projet qui démarre sans erreur sur ton ordinateur.
- Un compte GitHub gratuit. GitHub est l'endroit où ton code va vivre en ligne. C'est aussi ce qui permettra à Vercel de détecter tes modifications et de republier ton app toute seule.
- Un compte Vercel. Tu le crées en te connectant avec ton compte GitHub, en trente secondes, sans carte bancaire pour le plan gratuit.
- Un projet qui se lance en local. Si la commande npm run dev ouvre bien ton app dans le navigateur, la base est saine.
Ensuite, deux vérifications qui évitent la grande majorité des échecs.
Vérification 1 : le fichier .gitignore. Ce fichier liste ce qui ne doit jamais partir sur GitHub. Il doit contenir au minimum les lignes .env, .env.local et node_modules. Si ton assistant IA ne l'a pas créé, demande-lui de le faire avant tout envoi de code.
Vérification 2 : la commande npm run build passe sans erreur. C'est exactement la commande que Vercel va exécuter sur ses machines. Si elle échoue chez toi, elle échouera chez eux. Si elle affiche des erreurs, copie le message complet et colle-le à ton assistant en lui demandant de corriger, puis relance. Deux ou trois allers-retours suffisent en général.
Si tu découvres encore l'outil, le tutoriel complet Claude Code pour débutants et les 20 commandes Claude Code à connaître te feront gagner beaucoup de temps sur cette phase de nettoyage.
Les trois méthodes pour déployer ton app sur Vercel
Trois chemins mènent au même résultat : un parcours accompagné, l'import depuis GitHub, ou la ligne de commande. Ils donnent tous une URL publique ; ils diffèrent surtout par ce que tu fais quand quelque chose coince.
Méthode 1 : te faire accompagner de bout en bout
La difficulté du premier déploiement n'est presque jamais technique. Elle tient au fait que tu ne sais pas ce que tu ne sais pas : quel dossier envoyer, pourquoi le build casse, où mettre une clé, à quoi sert une branche. Un parcours structuré supprime ces trous.
Le programme Claude Code pour créer et publier ton app déroule le chemin complet, de l'idée de départ jusqu'à l'app en ligne, avec les cas d'erreur réels montrés à l'écran plutôt qu'un projet parfait qui marche du premier coup. Le Lab IA intégré te donne accès aux vrais outils avec les crédits inclus, ce qui t'évite d'empiler trois ou quatre abonnements avant même d'avoir publié quoi que ce soit.
À noter si tu veux financer ta montée en compétences : Skilzy propose deux certifications enregistrées par l'État, dont la certification RS7439 en marketing de contenus assistés par IA, consultable sur le répertoire de France Compétences.
Méthode 2 : l'import depuis GitHub
C'est la voie la plus utilisée, et elle est gratuite. Tu envoies ton code sur un dépôt GitHub, tu cliques sur Add New Project dans Vercel, tu sélectionnes le dépôt, tu valides. Vercel reconnaît seul le type de projet et remplit les réglages. Gros avantage : chaque fois que tu envoies une modification, ton site se met à jour tout seul en une à deux minutes.
Méthode 3 : la ligne de commande Vercel
Si ton terminal est déjà ouvert, tu installes l'outil avec npm install -g vercel, tu te connectes avec vercel login, tu lances vercel dans le dossier du projet pour une version de test, puis vercel --prod pour la version publique définitive. C'est la méthode la plus rapide une fois qu'on a l'habitude, mais tu perds la mise à jour automatique si tu ne connectes pas GitHub derrière.
| Méthode | Temps la première fois | Prérequis | Pour qui |
|---|---|---|---|
| 1. Parcours accompagné | 20 min, sans blocage | Un compte Skilzy | Débutant complet qui veut aller au bout |
| 2. Import GitHub | 20 à 30 min | Compte GitHub | Tout le monde, c'est le standard |
| 3. Ligne de commande | 10 min | Terminal, Node.js installé | Ceux qui sont déjà à l'aise |
Le déploiement minute par minute
Compte environ vingt minutes réparties en six étapes, dont la moitié se passe à attendre que les machines travaillent.
Minutes 0 à 6 : envoyer le code sur GitHub. Crée un dépôt vide sur GitHub, en privé si tu préfères (Vercel y accède quand même). Puis demande à ton assistant de préparer l'envoi : il exécutera les commandes d'initialisation, d'ajout des fichiers, de premier commit et de liaison au dépôt. Vérifie ensuite sur GitHub que le fichier .env n'apparaît nulle part dans la liste. S'il y est, arrête tout et corrige avant de continuer.
Minutes 6 à 9 : créer le projet dans Vercel. Connecte-toi avec GitHub, clique sur Add New puis Project, autorise l'accès au dépôt, sélectionne-le.
Minutes 9 à 12 : vérifier les réglages. Vercel affiche un Framework Preset (Next.js, Vite, Astro selon ton projet), un Root Directory et une Build Command. Dans 9 cas sur 10, tu ne touches à rien. Le seul réglage à surveiller est le Root Directory : si ton code est dans un sous-dossier comme app ou frontend, indique-le ici, sinon le build ne trouvera rien.
Minutes 12 à 16 : ajouter les variables d'environnement. Ouvre la section Environment Variables et recopie chaque ligne de ton fichier .env local : le nom à gauche, la valeur à droite. C'est l'étape la plus souvent oubliée, et celle qui provoque le plus de pages blanches après déploiement.
Minutes 16 à 18 : lancer le build. Clique sur Deploy. Le journal défile en direct. Tu vois l'installation des dépendances, la compilation, puis le résultat. Un échec à ce stade est normal et se lit : le message d'erreur exact est affiché en rouge dans le journal.
Minutes 18 à 20 : tester pour de vrai. Ouvre l'URL fournie, puis rouvre-la depuis ton téléphone en 4G, hors de ton réseau maison. Clique sur chaque bouton, envoie un formulaire, teste une action qui appelle une IA. C'est là que les variables manquantes se révèlent.
Tes clés d'API ne doivent jamais partir sur GitHub
Une clé d'API publiée sur un dépôt public peut être trouvée et utilisée par n'importe qui en quelques minutes, et c'est toi qui reçois la facture. Des robots scannent GitHub en permanence à la recherche de ces chaînes de caractères.
Les trois règles à retenir :
- Les clés vivent dans le fichier .env.local sur ton ordinateur, et ce fichier est listé dans .gitignore. Il ne part donc jamais en ligne.
- Sur Vercel, les clés se saisissent dans Environment Variables, jamais dans le code. Tu peux définir des valeurs différentes pour la production et pour les versions de test.
- Le préfixe NEXT_PUBLIC_ change tout. Une variable nommée NEXT_PUBLIC_QUELQUECHOSE est envoyée au navigateur du visiteur, donc visible par tous. Une clé d'API ne doit jamais porter ce préfixe. Réserve-le à ce qui est réellement public, comme une URL de site.
Si une clé a déjà été envoyée sur GitHub, supprimer le fichier ne suffit pas : l'historique la conserve. Il faut révoquer la clé chez le fournisseur et en générer une nouvelle. C'est long de dix secondes et ça évite une très mauvaise surprise.
Dernier point souvent mal compris : les appels vers une IA doivent partir du serveur, pas du navigateur. Concrètement, ton app appelle une route interne, et c'est cette route qui contacte l'API avec la clé. Le principe est détaillé dans notre article sur la création d'un chatbot d'entreprise avec Claude, où la même logique s'applique.
Les cinq erreurs qui font échouer un premier déploiement
Presque tous les échecs se ramènent à cinq causes, toutes lisibles dans le journal de build.
1. Ça marche en local mais pas sur Vercel. Les serveurs de Vercel tournent sous Linux, qui distingue les majuscules des minuscules dans les noms de fichiers. Un import de Button alors que le fichier s'appelle button passe sur Mac et Windows, et casse sur Vercel. Corrige la casse et le problème disparaît.
2. Page blanche ou erreur 500 après un build réussi. Presque toujours une variable d'environnement absente. Retourne dans Settings, ajoute-la, puis relance un déploiement : les variables ne sont pas prises en compte rétroactivement.
3. Le build ne trouve aucun fichier. Root Directory mal renseigné. Indique le sous-dossier qui contient le package.json.
4. Module not found alors que le paquet est installé chez toi. Le fichier package-lock.json n'a pas été envoyé, ou la dépendance a été rangée dans devDependencies alors qu'elle est nécessaire au build. Réinstalle proprement et renvoie le code.
5. La base de données ne répond pas. Si ton assistant a créé une base SQLite sous forme de fichier local, elle n'existe pas sur Vercel. Il faut une base hébergée en ligne. Demande à ton assistant de migrer vers une base distante avant le déploiement plutôt qu'après.
Dans les cinq cas, la méthode est la même : copie le journal d'erreur complet, colle-le à ton assistant avec la phrase « voici l'erreur de build Vercel, corrige le projet », et relance. Si tu veux comprendre le format d'un projet Next.js déployé, la documentation Next.js reste la référence.
Ce que tu fais une fois l'app en ligne
Tu as une URL publique, en HTTPS, que tu peux envoyer à qui tu veux. À partir de là, deux gestes utiles : brancher un nom de domaine personnalisé dans l'onglet Domains si tu en possèdes un, et prendre l'habitude d'envoyer tes modifications sur GitHub, puisque chaque envoi republie le site automatiquement.
Le premier déploiement est le seul qui prend vingt minutes. Le suivant en prendra deux, et tu passeras enfin ton temps sur ce qui compte : ce que ton app fait réellement pour les gens qui l'utilisent.
