Ton app s'arrête quand tu fermes le MacBook
Pimpela tourne sur mon macbook depuis plusieurs semaines. Mon générateur de déco prend une photo de pièce, propose un avant/après, génère un plan d'action. Tout fonctionne. Tant que mon terminal est ouvert.
Le problème est bête : je ferme le MacBook, l'app s'éteint. Personne d'autre que moi ne peut y accéder. Si je veux montrer Pimpela à ma sœur Lili, il faut qu'elle soit assise à côté de moi, devant mon écran. Ce n'est pas un produit, c'est une démo captive.
Pour que l'app existe en dehors de mon ordi, il faut la déployer. Le mot est technique, le geste ne l'est pas tant que ça. Déployer, c'est envoyer ton code quelque part qui le fait tourner en permanence, et qui te donne une URL. Une adresse, comme une adresse postale, sauf qu'elle mène à ton app.
On va faire ça en une session. À la fin, tu auras une URL que tu peux ouvrir sur ton téléphone, envoyer par SMS, coller dans un mail.
Mais avant Vercel, le service qui va héberger l'app, il faut passer par une étape intermédiaire. Pas la plus excitante, mais impossible à sauter.
Git et GitHub : l'infrastructure qu'on ne peut pas sauter
Vercel ne prend pas un dossier depuis ton ordinateur. Il va chercher le code sur GitHub. C'est comme ça que ça marche, et c'est la raison pour laquelle on doit d'abord pousser le projet là-bas.
J'ai mentionné GitHub à l'article 2, en passant, comme un "dossier partagé avec mémoire". C'est le moment de le manipuler pour de vrai.
Git : le carnet de bord de ton code
Git est un outil qui enregistre l'historique de ton projet. Chaque fois que tu fais un changement significatif, tu crées un commit. Un commit, c'est un point de sauvegarde nommé.
Sur Pimpela, mes premiers commits ressemblaient à ça :
formulaire de style qui fonctionne-ajout du générateur avant/après-correction bug sur les photos verticales
Chaque commit dit ce qui a changé. Si dans trois semaines tu ne sais plus pourquoi ton formulaire a changé de tête, tu remontes l'historique et tu retrouves le moment exact.
Et surtout : tu peux revenir en arrière. Si ta dernière modification a tout cassé, tu reviens au commit précédent. Le code retrouve son état d'avant. Pour quelqu'un qui a peur de tout péter en touchant au code, c'est un filet de sécurité réel. Pas une promesse, un mécanisme.
GitHub : le dossier en ligne où ce carnet vit
Git fonctionne sur ta machine. GitHub, c'est le service en ligne où tu envoies ton historique Git. Quand tu fais un push, tu envoies tes commits vers GitHub. (le sacro saint "commit & push" baby 😎, tout ça pour dire "ok je suis d'accord avec ce que tu viens de faire, tu peux aller le copier sur github qui l'enregistre et l'historise proprement) Ton code vit alors à deux endroits : sur ton ordi, et sur GitHub.
Pourquoi c'est utile au-delà du déploiement : si ton disque dur lâche demain, ton code est toujours sur GitHub. Si tu changes d'ordinateur, tu récupères tout en une commande. Et si un jour tu travailles avec quelqu'un d'autre sur le projet, GitHub est l'endroit où vous partagez le code.
Je ne parle pas de branches, de merges, de conflits. Ces concepts existent, ils sont utiles dans des projets plus complexes, et ils ne servent à rien aujourd'hui. On fait, on commit, on push. C'est tout.
Pousser son code sur GitHub avec Claude Code
Tout ce qui suit, je l'ai fait en demandant à Claude Code. Je n'ai pas tapé les commandes Git moi-même. J'ai décrit ce que je voulais faire, et Claude Code a exécuté.
Initialiser Git sur le projet
Dans Claude Code, ouvert sur le dossier de ton projet, tu dis quelque chose comme :
Initialise Git sur ce projet et fais un premier commit avec tout le code actuel.
Claude Code va exécuter git init, puis git add ., puis git commit -m "premier commit". Tu verras les commandes défiler. Tu n'as pas besoin de les retenir. Ce qui compte, c'est de comprendre ce qui vient de se passer : Git surveille maintenant ton dossier, et ton premier point de sauvegarde existe.
Un réflexe à installer : chaque fois que tu fais une modification qui fonctionne, tu demandes à Claude Code de committer.
"Committe ce qu'on vient de faire, avec le message 'ajout de la page résultats'."
Ça prend cinq secondes. Et ça t'évite de perdre une heure de travail si la modification suivante tourne mal. c'est l'équivalent du 'enregistrer'.
Créer le dépôt et envoyer le code
Pour envoyer le code sur GitHub, il faut d'abord créer un dépôt (repository en anglais, repo pour les intimes, à prononcer "ripooo" ). Un dépôt, c'est le nom que GitHub donne à l'espace qui va accueillir ton projet.
Tu peux le créer directement depuis Claude Code. Demande-lui : "Crée un dépôt GitHub pour ce projet et pousse le code." Il va te demander de t'authentifier si c'est la première fois. Tu suis les instructions, tu valides les accès, et le code part.
Précision importante : quand Claude Code te demande si le dépôt doit être public ou privé, choisis privé. Ton code sera visible uniquement par toi. Tu pourras le passer en public plus tard si tu veux, mais au début, privé est le bon réflexe. Personne ne va fouiller dans ton code pendant que tu apprends.
Une fois le push terminé, tu peux aller sur github.com, te connecter, et voir ton projet. Tous tes fichiers sont là. Si tu as fait plusieurs commits, tu vois l'historique. C'est ton code, en ligne, indépendant de ta machine.
Vercel : de GitHub à une vraie URL
Vercel est un service qui prend un projet GitHub et le transforme en site accessible. Il surveille ton dépôt : à chaque push, il redéploie automatiquement. C'est gratuit pour les projets personnels.
Créer le compte et connecter le dépôt
Va sur vercel.com. Crée un compte en te connectant avec ton compte GitHub. Vercel va te demander l'accès à tes dépôts. Tu acceptes.
Dans le dashboard Vercel, tu cliques sur "Add New Project". Vercel te montre la liste de tes dépôts GitHub. Tu sélectionnes celui de ton projet. Pour ce blog, j'ai vu apparaître le nom de mon dépôt, j'ai cliqué dessus, et Vercel m'a proposé de configurer le déploiement.
La plupart du temps, les réglages par défaut fonctionnent. Vercel détecte que c'est un projet Next.js, ou React, ou Vite, et fort heureusement pour moi 😬 il sait quoi faire. Si ton projet a des variables d'environnement, c'est ici qu'il faut les entrer. Vercel a une section "Environment Variables" dans les paramètres du projet. Tu y colles les mêmes clés que celles de ton fichier .env.local, une par une. (ça à l'air technique, mais c'est un banal copier-coller)
Si tu as suivi les articles sur les clés API et les permissions, tu sais déjà ce que sont ces variables. C'est le même principe : les valeurs sensibles ne sont pas dans le code, elles sont dans un coffre. Chez Vercel, le coffre s'appelle "Environment Variables".
Le premier déploiement
Tu cliques sur "Deploy". Vercel lit ton code, l'installe, le compile, le met en ligne. Ça prend entre trente secondes et deux minutes selon la taille du projet. Un écran te montre la progression.
Puis l'URL apparaît.
Elle ressemble à quelque chose comme blogdemathilde-abc123.vercel.app. C'est une adresse générée automatiquement. Pas très élégante, parfaitement fonctionnelle.
J'ai cliqué sur cette URL. Mon blog s'est affiché. Le même que celui qui tournait sur mon macbook, sauf que cette fois il tournait sur un serveur quelque part dans le monde, et n'importe qui avec le lien pouvait y accéder.
L'URL sur le téléphone
J'ai copié l'URL. Je l'ai ouverte sur mon téléphone en 5G, pas en wifi. Le blog s'est chargée. Les articles, la newsletter, tout y etait.
J'ai envoyé le lien à Lili par SMS. Elle a ouvert, depuis chez elle, sur son iPhone, sur son propre réseau. Ça marchait.
C'est un bon test, d'ailleurs : ouvrir l'app depuis un autre appareil, sur une autre connexion. Si ça fonctionne en 5G sur ton téléphone et chez quelqu'un d'autre, c'est vraiment en ligne. Ce n'est pas ton ordi qui fait le travail.
Si l'app ne s'affiche pas correctement, ou si une fonctionnalité plante, Vercel fournit des logs de déploiement. Tu peux copier l'erreur et la donner à Claude Code, ou meme Claude.ai : "Voilà l'erreur que Vercel affiche, qu'est-ce qui ne va pas ?" Claude Code sait lire ces messages. J'ai eu un bug au premier déploiement de ce blog, une variable d'environnement que j'avais oublié d'ajouter dans Vercel. Claude a identifié le problème en lisant le log, je l'ai ajoutée, j'ai redéployé, c'était réglé.
La peur de tout casser en ligne
Une fois l'app déployée, la peur change de nature. En local, la peur c'est "et si je casse mon code". En ligne, c'est "et si je casse l'app que d'autres gens utilisent".
La réponse courte : tu ne peux pas casser de manière irréversible.
Vercel garde chaque déploiement en mémoire. Quand tu fais une modification dans ton code, que tu commites et que tu pushes sur GitHub, Vercel redéploie automatiquement. Si la nouvelle version a un bug, tu vas dans le dashboard Vercel, tu trouves la liste des déploiements précédents, et tu remets en ligne la version d'avant. Deux clics.
C'est le même principe que les commits Git, mais appliqué au site en ligne. Chaque déploiement est un point de sauvegarde. Tu avances, et si ça casse, tu recules d'un cran.
J'ai testé ça volontairement sur ce blog. J'ai poussé une version avec un bug visible, j'ai vu le site cassé en ligne, j'ai fait un retour arrière sur le déploiement précédent. L'app est revenue à son état normal en moins d'une minute. Le temps que quelqu'un remarque le bug, il est déjà corrigé.
Ce filet de sécurité change la façon dont on travaille. On n'a plus besoin que tout soit parfait avant de déployer. On déploie souvent, en petits incréments. Si quelque chose casse, on revient en arrière. C'est le fonctionnement normal, pas un plan de secours.
Et si tu voulais une URL à toi ?
L'URL que Vercel génère fonctionne, elle est partageable, mais blogdemathilde-abc123.vercel.app ne ressemble pas à un nom de produit. Un nom de domaine personnalisé coûte une vingtaine d'euros par an chez Gandi, OVH ou Namecheap. Vercel permet de le brancher depuis les paramètres du projet, dans la section "Domains". Je ne creuse pas le sujet aujourd'hui, mais c'est une manipulation simple, accessible sans compétence technique particulière.